Yesterday's news

UPDATE: About 1.5 years after I wrote this I am a happy user of Vim and ViEmu. Yes, in the end it did win my heart!

Alright, before making decision I actually did some evaluation of ViEmu in context of my typical code editing patterns. As you see from the title the result was negative.

Before I begin trolling Vi let’s review my normal editing habits (w/o ViEmu)

I use left Shift and Ctrl exclusively, with my left thumb usually not far from left Ctrl and my left ring finger near left Shift.

I use numeric keyboard for navigation. I know most people have NumLock On most of the time which I find totally wrong! Numeric keyboard is much better than “normal” arrow keys as it gives you more convenient access to Home and End with your index finger, Insert with you thumb, Delete with ring finger and Enter with your pinky while still keeping PgUp/PgDn at your ring finger’s reach.

If I happen to work with bigger document and I still have my hand on the mouse after opening new file from Solution Explorer I use the mouse to quickly get where I need to be, otherwise I just Page, Home/End and Ctrl+Arrow to make my way to the place of attention. Once I’m there I either End-Enter (using numeric keypad) to add a new line or I edit the current line with Ctrl+Shift+Arrows/Home/End followed by Ctrl+Ins, Shift+Ins and Shift+Del for clipboard operations and Ctrl+Z for Undo.

Sometimes, but not often, I scroll with Ctrl+Up/Down just to keep my working area in the middle of the screen without interrupting the edit burst. I also do Home-Ctrl+Shift+End followed by Ctrl+Left if I want to cut a sequence of words ending closer to the end of the line.

These plus an occasional Alt+Enter to apply Resharper’s suggestion is how I spend most of my (non-typing) editing time. Perhaps you should also know that I’m not a touch-typist. I do blind type but I only use index and middle fingers, plus pinkies for left Shift and Return.

This should make it very clear why I found ViEmu pretty pointless even after I memorized most of commands. Indeed, to draw Vi parallels to my editing habits, the most useful commands would be:

• Ctrl+F/B to page — extra Ctrl
• j and k to move down and up
• w and b to quickly move sidewise — less Ctrl — (using an occasional W or B to skip to the next space — extra Shift)
• x and X to delete
• vwww….w or vbbbb…..b followed by y, c or shift+P to copy, cut or replace a sequence of words — less Ctrl+Shift to begin but extra Shift to Paste before cursor
• u to Undo — less Ctrl
• o to add new line — less End
• zz to center the screen on the current line — much faster as this gets me centered in N(0) time regardless of how far I am from the center
• cc to cut entire line – much faster than Home-Ctrl+Shift+End-Del sequence I sometimes use

Of these only the nice-to-have zz and not-so-frequently-used cc are much faster and most others only eliminate a single Ctrl press, while still requiring me to press Esc to return to the Command mode after each edit. Now these saved Controls don’t actually save much since as I said I’m not a touch typist so my hands still need to move significant distance to press all these Js, Ks and Us.

Truth be told, there are many unique commands in Vi that don’t have “normal” counterparts but I just don’t see a need to use them as often as Vi zealots seem to suggest I’m supposed to. Let’s see.

• cib - cut (text + text = text)
• ci” – cut “text, text; and text!”
• cW - cut to next space
• f( – move to next (
• % - move to the matching bracket
• * - move to next occurance of this word
• . - repeat last edit sequence

These are nice but arguably not worth the effort, especially in comparison with following Resharper shortcuts:

• Ctrl+W – expand selection
• Alt+Up/Down - go to next/previous method
• Ctrl+Shift+Alt+Up/Down - move current block up or down
• Ctrl+] – go to matching bracket
• Ctrl+Shift+F7 to highlight all usages of current identifier followed by Ctrl+Alt+Up/Down to jump the usages
• Ctrl+B – go to declaration

Note that most useful of these are semantic movements. I.e. they rely on background compilation of the text being edited as opposed to simple pattern match. This is not to mention Resharper’s perfect refactorings like F2 to rename etc.

Don’t know about you but I’m sold. Long live Resharper! Goodbye ViEmu!

 

Repeatable command sequences

Generally speaking, commands can be repeated by pressing . (dot).This is useful when you want to apply the same change to multiple lines (assuming it can’t be done with basic find and replace and you don’t feel like writing a RegEx).

Note that standalone moves, like w or t. are repeated using a different command: ; and incremental search is repeated by pressing n. This makes sense as whole point of the repetition is to move to the new place, repeat the command, move again, repeat again — if standalone moves used same repetition buffer as edit commands they would overwrite the last edit command and therefore make this sequence impossible. Enough of this pseudo-deep analysis though. Let’s see some examples:

de — this is same de that we’ve learned last time. Now you can go nuts and delete everything till the end of the word by pressing . at your heart’s desire.

i[Hello][Esc] — types something, for example Hello. Not very exciting but still, repeatable!

A;[Esc] — adds ; at the end of the line. Hope you recognize A command.

I[Tab][Esc] — adds tabulation in front of the line. Repeat this for each line in the block you want to indent. I know I know in normal editors you can select and press Tab to indent the whole block.

ce[Boo][Esc] — this will delete the rest of the word, go to the insert mode, type Boo, and switch back to the Command mode. Pressing . repeats the sequence which is now “replace rest of the word with Boo”.

c%q[Esc] — when standing on an opening bracket of any kind ({[ replaces everything up until and including the closing one with "q" (or any other text). Since c is actually the Cut command, it also places the whole () block in the clipboard.

ci(xyz[Esc] — This is a weird one. Here, i does not mean Insert mode. Instead it means Inside the parenthesis. So this sequence Cuts the text Inside parenthesis you’re standing in and replaces it with “xyz”. It also works inside square and figure brackets — jus do ci[ or ci{ correspondingly. Naturally, you can do di( if you just want to delete all text without typing anything. You can also do a instead of i if you want to delete the parentheses as well and not just text inside them.

ciw – cuts the current word. This works just like the previous one except that ( is replaced with w.

ci” – cuts the text in current quotes

Indentation

Finally, solved this one! Here’s how you do it:

To indent/unindent the current line just press >> or << (with Shift!) — no need to select nor move cursor no nothing!

5>> — indent next 5 lines

To indent entire block, stand anywhere inside the block you’d like to indent, feet at shoulders width. Then press >i{ to indent all text inside the block (exluding the figure brackets) or >a{ to indent everything including the brackets. It’s kind of powerful. My only problem with this is having to press Shift with > and { but not with i. You can do B instead of { (B stands for Block) but that still requires two Shifts.

 

Other cool commands

C – cut the rest of the line and switch to Insert mode.

ZZ — save and close current file (WAY faster than Ctrl-F4 to close the current tab!)

ddp – move current line one row down

xp — move current character one position to the right

U – upercase, so viwU upercases the word

~ – switches case, so viw~ will reverse casing of entire word

The End

Let’s live with these crazy commands for a week and see if they fly.

P.S. Check out the last post in the series.

They say, once you’ve groked Vi, there’s no way back. I’m still nowhere near “grokking” but I’m starting to get the feel of it.

If you have played with commands I listed in the first post, you probably found them pretty limiting. I found myself switching to Insert mode every time I needed to do anything involving copy/paste, identation, and paging up/down. This is not surprising, considering that none of these basic needs were covered in the previous post. Let’s see how we can do them in ViEmu, while having fun with one or two new commands.

Moving around

Ctrl+u / Ctrl+d scroll the page half-a-screen Up or Down. This seems to be more useful than the usual full-screen paging as it makes it easier to see how the two screens relate. For those who still want to scroll entire screen at a time there’s Ctrl+f for Forward and Ctrl+b for Backward. Ctrl+Y and Ctrl+E scroll down or up one line at a time.

Crazy but very useful command is zz — it scrolls the screen to make this line appear in the middle. This is excellent for putting the piece of code you’re working on in the center of your attention. Sibling commands — zt and zb — make this line the top or the bottom one on the sreen which is not quite as useful.

^ and $ are Vi versions of Home and End buttons. They’re real easy to remember as these are same exact symbols used in Regular Expressions to indicate beginning and end of string (I like to think Vi invented them first . Once again, these are most useful on notebooks where Home and End are misplaced at the far upper right. Note that ^ goes to first non-whitespace character. If you want to go to the very beginning of the line, use 0 (stands for “position number zero”) — I use this to fix the horizontal scrolling after looking at the end of the line beyond the screen.

+ and - are used to go to the “soft” beginning of the next or previous line. The only problem with them, minus is a straight keydown while the plus requires the Shift pressed — got to remember this when going back-and-forth. The good news is: you can use Enter instead of the plus.

The “Big Moves”: H, M and L move cursor to the High, Middle or Low row on the current screen and G Goes to the last line in the file.

Finally, to complete the list of moving commands, [number]gg go-goes to the line indicated by the [number] (just gg without any number go-goes to the first line).

Search

f[char], e.g. f followed by any other character, Finds the next occurence of the specified character and moves the cursor onto it.

t[char] is similar to Find, except that it only goes unTill the specified character, placing the cursor just before it.

% finds and jumps to the matching parenthesis.

* and # find next and previous occurances of the word under cursor. Unexpected sideeffect: they also highlight all the occurances in the file. This is very useful if you know how to unhighlight them when you no longer need. I’ll show you how to do this in a second.

The question mark key (actually the wack symbol on it — i.e. /) turns on the incremental search which highlights the first matching word as you type it. Naturally you can press Esc to quit the search operation or Enter to confirm and jump to the found word. From then on you can keep on pressing n to jump to each subsequent occurance of the matching string. This is made simpler by the fact that incremental search also happens to highlight all matching occurances — annoying but informative. To clarify potential confusion the actual question mark ? symbol on the same key as / requires a Shift press, so they decided not to use it for forward search for the sake of typing efficiency and made it search backwards in file instead. As you see, creators of Vi put a lot of effort in making these commands easy to remember AND efficient but sometimes that required sacrificing logical simplicity. Now, to unhighlight the last search result just search for a string that definitely does not exist in the file. I usually smack something random like /gfthhdhj — cool huh?!

Chaining Commands

Perhaps one of the coolest features in Vi (well, definitely the coolest one I know so far) is ability to chain commands.

The first chainable command I discovered was d (Delete the next move). Perhaps I should say d[cmd] where [cmd] is any move command. Examples of chains you can build with d:

de — delete from cursor to the end of the word (you can also do dE to delete until the next space)

bde — delete the current word, from left to right delimiter

df[space] — delete up until and including the next space

dt. — delete until next dot

dd — delete this entire line

this chaining stuff lays the groundwork for exactly where we want to be next… which is:

Copy/Paste

For the fans of the classic Select-Copy-Paste style (using good old Ctrl+Ins / Shift+Ins for clipboard operations of course, not these ugly Ctrl+C / Ctrl+V) let me assure you that in ViEmu you can still do similar thing. Just press v to turn on the so called Visual mode — which is akin to pressing and holding the Shift key in a normal editor, meaning the text will be highlighted as you move over it with hjkl. You can even use e, b, and /-incremental search to move the cursor where you want it and all the text between the point where you pressed v and the current point will be highlighted!

Once the text is highlighted, you can use y to yank it (yank is the Vi slang for Copy To Clipboard) or d to delete it. BTW, it turns out the d command we learned in the last section was actually a clipboard command. It places the text it deletes into clipboard which makes it equivalent to Cut command in normal editors. There’s another variation of Cut command in ViEmu called c (short for Change). It cuts selected text into clipboard and swithes to Insert mode so you can start typing the replacement text.

Pasting in Command mode is done by pressing p. If you find yourself having to paste while in Insert mode, do not despair. You can still do Ctrl+R to paste Right now (the silly mnemonic is mine

Now, if you want to do copy/pasting the native Vi way you should use the sequences y[cmd]. This makes Vi Yank the text from the current cursor location to destination of the move specified by the [cmd]. As you could have guessed, d[cmd] and c[cmd] work in the same fashion.

In the spirit of “easier done than said”, here are few examples:

ye (or yE) — yanks text from here to the end of the word

ce – cuts through the end of the word

bye — copies current word (makes me wonder what “hi” does!)

yy — copies the current line

cc – cuts the current line, you can also do S instead. There’s also lower cap s which cuts current character and switches to insert mode.

viwy or viwc – Yank or Change current word. Hit w multiple times to keep selecting each subsequent word, use b to move backwards

vi{ – select all text in figure brackets. va{ – select all text including {}s

vi(p – highlight everything inside the ()s and replace with the pasted text

Identation

Go to part 3 for identation and more fun stuff.

Don’t remember exactly how, but somehow I stumbled upon ViEmu, a plug-in for Visual Studio that makes its code editor support Vi/Vim-style editing. For uninitiated, the point of Vi is to dramatically reduce the number of hand movements and keystrokes required to move around and change the code. It does this by defining shortcuts that automate typical move and edit operations (sort of like familiar Ctrl+Arrow that moves cursor to the next delimiter or Ctrl+I that starts incremental search but WAY more various and advanced). The presumption is that once one learns all the shortcuts, s/he can edit the code without ever moving hands to the cursor keys or to the mouse. This is especially cool on notebooks, where both the cursor keys and the mouse usually suck.

It’s funny how, as I was taking my first steps in ViEmu, my first thought was “hell, this is cool but once computers know exactly which line and position I’m looking at I’ll no longer need Vi”. We shall see if this is an overstatement or not in the next 50 years.

Anyway, this post is a recap of commands in the sequence that I learned them. Let’s jump right in.

Cursor Keys

hjkl move cursor correspondingly left, down, up, and right. While left and right are easy to remember, up and down seem reversed, mostly because down feels logically similar to right (as it, too, moves cursor towards the end of the document). The mnemonics to remember j for down is “j looks like an arrow pointing down” which of course is a tough analogy to buy. Anyway, I guess I’ll have to struggle with up and down until the motor memory kicks in. According to Vi theory, if you find yourself moving around with hjkl a lot, you’re not using Vi properly. Instead you should learn to use more powerful “moves” — i.e. commands that smartly move the cursor exactly to the location you want it to be at, instead of going there space by space.

Insert/Edit/Replace modes

i switches the editor to the Insert before mode — the newly typed text will appear immediately in front of the character that the cursor was on when i was pressed.

a switches the editor to the Append mode, or insert After mode — which is the Insert mode starting at the position immediately after the current character.

As many other commands in Vi, i and a have their upper case counterparts — I and A — that work in a consistently different way: I goes to Insert at the very left of the current line and A goes to Append at the very end of it. Two slightly more advanced relatives of I/A are o and O which go into Insert/Append after Opening a new line, either before (O) or after (o) the current line.

Esc quits the Insert mode and gets us back to the Command mode, also called Edit mode, which is the mode we should supposedly be in 90% of the time.

In Insert mode there are no commands, the text you type is what gets typed. In Edit mode, all you type gets interpreted as a command, which may or may not change the text.

Somewhat confusing is the fact that Edit mode is indicated by a block cursor which, back in terminal days, used to indicate the write-over mode. In Vi, the write-over mode (also called Replace mode) is turned on by pressing capital R, which does not seem terribly useful except for rare cases where the new text is exactly same length as the old text, which is more likely to happen for very short lexems, 1-2 chars long. Think replacing delimiters, variable names, and array indexes.

Word-by-word moves

b and e move the cursor word-by-word, similarly to how Ctrl+Arrows normally do. The definition of word is a little different though, as several consecutive delmiters are treated as one word. If you start at the middle of a word, pressing b will always get you to the Beginning of the current word, and each consecutive b will jump to the Beginning of the next word. Similarly, and easy to remember, e gets the cursor to the End of the current, and each subsequent, word.

similar to b/e, capital B and E move the cursor word-by-word using only whitespaces as delimiters.

Another word-by-word move is w (and W) which is sort of a hybrid between b and e, in the sense that it moves cursor to the beginning of the next Word, instead of the end of this and each subsequent one, as e does.

Edit operations

x deletes the character next to the cursor, exactly like Delete key does, and X is equivalent to Backspace.

u is Undo, plain and simple.

capital D (take a deep breath) Deletes the rest of the line to the right of the cursor, same as Ctrl+Shift+End/Del in normal editors (notice 2 keypresses — Shift+D — instead of 4)

capital J very effectively Joins the current line with the next one with one space symbol in between. Once done, it places the cursor between the two parts of the combined line, on the newly added space.

That’s it for now, this should jump-start your ViEming experiments, and remember that if you feel frustarted and need something done quickly you can always switch to Insert mode by pressing i which enables normal Ctrl/Shift/Cursor keys and basic clipboard shortcuts. If worse comes to worse you can even turn the Vi mode off by pressing Ctrl+Shift+Alt+V, but I hope it won’t get to that. Instead I recommend creating a cheat sheet and using it for a day or two so you can quickly impress your friends with your new ninja editing skills. Happy Viing!

EDIT — also see second part in this series here: http://zvolkov.com/blog/post/2009/04/18/Learning-Vi-part-2.aspx

Mechanical keyswitches? USB 2.0 port for my flash drive? Thank you, I want it!

MSBuild is an overcomplicated ripoff of NAnt, which is the open source .NET remake of Apache Ant which is a Java successor of Unix’s Make, which is where the basic concepts came from.

Make’s concepts relevant to MSBuild

• command — invokes a command-line tool
• target — named sequence of commands
• dependency — targets can depend on other targets
• Make is invoked on a make file with one or more target specified and it runs all dependencies recursively and then the target’s commands.
• make files can include other make files for robust management of make structure
• make also supports creating named variables that will be substituted for parameters of commands
• also there are so called automatic variables that are assigned by the make itself (like current dir name/path etc.)
• A target will never run twice during a single build. Once run, a target is assumed to have completed its work and will not be run again, even if a subsequent target in the build depends on it.

Simplified example of make file:

target1: sub_target1
    csc.exe a, b
    copy b, c
sub_target1:
    delete xyz

Ant’s concepts relevant to MSBuild

• Basically, Ant is an XML-based successor of Make, so most of Make concepts are still valid.
• The biggest difference (besides XML) is that commands are now called “tasks” and they not just invocations of command line processes, instead they execute actions built into the Ant itself.
• The variables are called “properties” (see NAnt section below for more details and example)
• The root of Ant build.xml file is <project> tag that specifies name and default target, the one executed if no target name was specified.

Simplified example of Ant build.xml file:

<?xml version="1.0"?>
<project name="Hello" default="compile">
    <target name="clean" description="remove intermediate files">
        <delete dir="classes"/>
    </target>
    <target name="clobber" depends="clean" description="remove all artifact files">
        <delete file="hello.jar"/>
    </target>
    <target name="compile" description="compile the Java source code to class files">
        <mkdir dir="classes"/>
        <javac srcdir="." destdir="classes"/>
    </target>
    <target name="jar" depends="compile" description="create a Jar file for the application">
        <jar destfile="hello.jar">
            <fileset dir="classes" includes="**/*.class"/>
            <manifest>
                <attribute name="Main-Class" value="HelloProgram"/>
            </manifest>
        </jar>
    </target>
</project>

NAnt concepts relevant to MSBuild

• NAnt files have .build extension
• Properties are referenced in task arguments like this: ${propertyname}
• Targets can have conditions that control their execution. The conditions are expressions that overlook properties.
• Expressions are formulas to be used in task arguments and conditions. Expressions can access properties  and call built-in or user-defined functions.
• NAnt has global Nant.exe.config file where the global Properties are defined.
• Tasks do not have to be in a target.  Tasks that appear directly in the project are executed in order before any tasks in targets are executed.
• NAnt can log the progress of build execution to a log file.

Sample NAnt .build file:

<?xml version="1.0"?>
<project name="Expression Test" default="test" basedir=".">
    <property name="project.name" value="Expression Test"/>
    <target name="test">
        <echo message="Project name is ${project.name}."/>
    </target>
</project>

Examples of tasks:

• call — explicitly execute another target (different from dependency which only executes targets once and in no particular order)
• copy / delete / mkdir / move — file system operations
• csc — c# compiler
• exec –  executes an external program
• echo — writes message to log

MSBuild concepts

• Main MSBuild file extension is .proj
• MSBuild tasks are similar to NAnt. For complete list look here: http://msdn.microsoft.com/en-us/library/7z253716(VS.80).aspx
• The tasks are actually imported from their CLR assemblies with UsingTask element like so:

  <UsingTask TaskName="TaskName" AssemblyName = "AssemblyName"/>

• For those who feel the built-in tasks are not enough, there’s a community project here: http://msbuildtasks.tigris.org/
• PropertyGroup — allows properties to be defined using human-friendly format like so:

  <PropertyGroup>
          <ProductVersion>9.0.30729</ProductVersion>
  </PropertyGroup>

• Compare this to NAnt syntax:

  <property name="project.name" value="Expression Test"/>

• Item — an object-oriented variant of property. While property is name/value, Item is name/object where object has multiple attributes.
• Properties are still referenced the Ant way, ${project.name} while Items are referenced via @(name)
• ItemGroups are NOT equivalents of Property groups for Items. Instead each ItemGroup is a collection of Items of one type — e.g. it cannot have Items with different names.

  <ItemGroup>
      <Item1 Attribute1 = "file1" AnotherAttribue="x">
          <Subitem1 abc="1"/>
      </Item1>
      <Item1 Attribute1 = "file2" AnotherAttribue="x"/>
  </ItemGroup>

• Typical usage of ItemGroups is to list all files to be compiled. The collection of the file is then passed to CSC task using @{itemname} notation. Read the following link on using Items: http://msdn.microsoft.com/en-us/library/ms171453(VS.80).aspx
• There’s a bunch of built-in properties. See this: http://msdn.microsoft.com/en-us/library/ms164309(VS.80).aspx
• For more conceptual info on MSBuild check this: http://msdn.microsoft.com/en-us/library/ms171451(VS.80).aspx
• For reference info, look here: http://msdn.microsoft.com/en-us/library/0k6kkbsd(VS.80).aspx

VS.NET-related MSBuild concepts

• VS.NET uses MSBuild 2.0 under the hood.
• MSBuild can also run VS .sln file, it generates .proj files from them. Using MSBuild 3.5 you can see that intermediate .proj file
• The C# project files .csproj are actually MSBuild .proj files but they also import Microsoft.CSharp.targets proj file to get most of functionality. (For a list of target files supplied with VS.NET, look here: http://msdn.microsoft.com/en-us/library/ms164312(VS.80).aspx)
• In fact MSBuild.exe recognizes any project file name extension matching the pattern .*proj ! (The .csproj files are also used by VS GUI to render the project items, so they are dual-purposed.)
• Clicking the Build command in Visual Studio will execute the default target in the project. Often, this target is also named Build. Choosing the Rebuild or Clean command will attempt to execute a target of the same name in the project. Clicking Publish will execute a target named PublishOnly in the project.
• To get IntelliSense support in Visual Studio before a build has generated an output assembly there must be a target named Compile w/ CSC task in it.
• When building inside Visual Studio, the property $(BuildingInsideVisualStudio) is set to true.
• Visual Studio attempts to execute targets with certain names when it loads a project. These targets include Compile, ResolveAssemblyReferences, ResolveCOMReferences, GetFrameworkPaths, and CopyRunEnvironmentFiles. Visual Studio runs these targets so that the compiler can be initialized to provide IntelliSense, the debugger can be initialized, and references displayed in Solution Explorer can be resolved. If these targets are not present, the project will load and build correctly but the design-time experience in Visual Studio will not be fully functional.
• Check out this page for more info on VS Integration: http://msdn.microsoft.com/en-us/library/ms171468(VS.80).aspx

TFS-related MSBuild concepts

• TFS uses MSBuild 3.5 under the hood.
• Check out this article on targets, properties and extensibility options: http://msdn.microsoft.com/en-us/library/ms400688(VS.80).aspx
• In TFS complete definition of a build is called “build type” (sort of like what “target” used to be back in Make days but now that it has become so overcomplicated we needed another abstraction that would symbolize one distinct use case)
• For each “build type” the following files control the build (the names are always the same, the differentiation works by pathname):
  • TfsBuild.proj — main MSBuild file
  • TfsBuild.rsp — the Response configuration file. Can be used to define custom loggers or override MSBuild properties.
  • WorkspaceMapping.xml — maps source control locations to local file system locations
• For detailed order in which targets are executed by TFS, check out this link: http://msdn.microsoft.com/en-us/library/aa337604(VS.80).aspx

That’s it for  a quick catch-up, you’re on your own from now on. Happy catchupping!

Compiled the answers from Stackoverflow:

• Will mostly do support / brownfield development
• Will have to be on-call
• No source control or SourceSafe used for source control
• Don’t do branching of code in source control
• Working hours not flexible at all
• Using legacy software / tools
• no TDD / no unit-testing
• Waterfall / no iterative development
• You will be the best dev in the shop
• (Overly strict) dress code
• Obvious monarchy
• Too serious / no joking / stressed out
• No bug tracking system, or bug tracking 100% owned by QA
• Overly restrictive Legal Agreement — they own what you do at off hours
• Blogging is not allowed
• No dual monitors
• Internet access limited
• Disconnected or lethargic or burned out team members
• Overtime expected and not paid for
• Code / db looks ugly
• Yes we’re going to implement that but we’re very busy now
• Too much talk of business priorities / results driven attitude
• Not using resharper / will not buy resharper or something like araxis merge etc.
• No free time to experiment
• Nobody recently went to a software dev conference
• Very many clients that come and go (e.g. a marketing company)
• No books on shelves or books look not read
• “Motivators” posted all over the place
• Dirty bathroom / kitchen
• No code sharing between team members
• No Continuous Integration / no nightly builds
• Lack of or little personal stuff on desks
• Your potential manager gives you a long lecture
• IT is a cost center rather than a production center
• no match on 401k
• Too eager to hire
• Can’t use your notebook at work / can’t connect to their LAN
• No working from home / no remote access
• EDIT — no admin rights on my development box

 

I'm trying to imagine what it would take to craft a delayed indexing mechanism for MS SQL Server.

The basic functionality I'm looking for:

• happens outside of the original transaction that inserts or updates the data and therefore does not slow it down
• has very low priority and therefore only works at idle time
• does not have to support transactions

Quick googling around shows that for some reason such a seemingly trivial feature has never been implemented, not natively anyway.

The easiest way to craft it of course is to use a trigger to capture the data updates and enqueue them into a DataBroker queue (or even to another table) which would then be looked at by a JobScheduler job that would insert/update data to an indexed table. Not sure if such a 2-table scheme allows for transparent selects though (you would have to first look in the indexed table and if not found fallback to the unindexed table), but maybe we can employ some View and/or User Defined Function magic, which may work for certain access patterns, like if we only ever expect maximum one result row returned…

Isn't there a NORMAL solution though?

This funny picture is a real screenshot from my home Mac:

Enjoy a great article by Andriy Podlyesnyy, who doesn’t yet have his own blog. (Credit for the original physical health text goes to Angel Sharum)

How to Create Healthy Software

Creating healthy software is the most important thing software engineer can do for himself. Without health nothing else matters. Software has to be healthy for programmers to enjoy life, provide good service to the client, and do things IT professionals enjoy. Taking care of software health should be programmer’s number one priority. No matter what your age or background you can start creating healthy software. Here are some tips to help get your started.

1. Maintain healthy weight. Programmer need to lose any excess code he is carrying around in the source. It is harming software body in more ways than one. Excess business logic around your User Interface harms UI organs and future redesign, extra weight puts strain on network, memory, hard drive usage and maintenance. Being overweight is the number one cause of performance issues.
2. Use healthy well balanced IT best practices. If you already have a health condition you should follow whatever latest best practices the IT community had found for particular business problem. If your code is not suffering from any ailments yet, then it will be easier to do healthy coding.  Focus on layer separation, Test Driven Development, Domain Driven Development, and lean objects as the staples of your software diet. Don’t go overboard on over-engineering though because the features may prove to be not used and therefore are heavier and harder to refactor.  Following the agile style development is actually healthy for most IT projects. If you are trying to lose weight in the code go by cleaning an unused code as you refactor, Unit Test will help to ensure overall health of the code and bug free environment.
3. Exercise TDD regularly. TDD is imperative to good software health. You can not achieve optimal health without including TDD into your plan. TDD helps your overall code quality and increase confidence during major refactoring. It also helps your code to grow bug free, and allows your boss heart to stay healthy. Form a regular TDD plan and stick to it. Pick Unit Tests that you actually like so you are more apt to continue doing them.
4. Reduce stress. Find ways of coping with stressful events in software lifecycle. Practice story driven development or similar specification definition techniques to help relieve misunderstanding with the users and reduce number of misleading requirements and/or bugs. Use TDD to improve code quality to reduce time spent on production support. Automate routine tasks.  Stress can cause minor and major problems ranging from irritated user phone call to job loss. Learn to relieve stress to live longer.
5. Get adequate learning. Knowledge is very important to your software health. Reading enough of IT blogs and latest industry best practices will give you more energy, keep you and your code healthy, and just make you feel better all around. When mind is deprived of knowledge serious health problems can occur in your code.

Keeping your code healthy isn’t hard. It does require dedication and commitment. Take your code health seriously and do what it takes to reach optimal results. Once you get in a healthy routine you will feel so much better, you’ll wonder how you survived the other way. Coding a healthy software leads to a happy life. Don’t let anything stand in your way.