This is one of the simplest things you need to do for your microIsv, but even this one has a few decisions and a few pitfalls. It's also Step 9 of 25 steps for building a microISV.

I've recently gone through the process of getting email in place to support NimbleText, so I thought I'd document it while it's still fresh in the old mind.

The first thing you need to work out is how you intend to use email in your microIsv, and from this you'll determine what accounts you need.

For example, here's where I'm using it, or planning to use it:

1. When licenses go out
2. When support requests come in
3. potentially for 'mass mailouts'

I ruled out 'mass mailouts' but only for now.

To handle these simple cases I could have a whole bunch of addresses such as 'licensing', 'sales', 'support', 'marketing', 'leon', 'ceo' and so on. But that's exactly the sort of over-engineering you need to avoid. In a microIsv you need to be thoroughly minimalist in everything you do.

The simplest thing that can possibly work is to have exactly one account, 'support', so that's what I've done with NimbleText.

Step 1: Create the account.

I'm hosting my sites at Arvixe these days, so in their control panel I set up a new email account.

I also tell it to forward to my gmail account (this won't be enough to get the forwarding working, we need to tell gmail as well)

I also told it to act as a catch-all address. So if someone writes to 'unknown@...' etc then I should still get it.

Step 2: Set up 'send mail as' at gmail.

In gmail you need to configure another account you can send email from.

I seem to 5 or 6 of these in use by now.

Within gmail, you go into settings in the top right hand corner. Choose the tab called called "Accounts and import". In the 'Send mail as' section, click the button to "Send mail from another address."

Enter sensible values, and pick the defaults. To complete this process, gmail sends an email to your new account, that contains a confirmation code you need to enter back in gmail.

Step 3: Create a filter at gmail.

You want any new support requests, etc, to be highlighted, and grouped together.

So create a filter in gmail that applies a new label, named after your microIsv. Tip: for any label I really care about, such as this one, I pre-pend the name with an underscore so it is alphabetically near the top of my labels. (I have a lot of labels). In this case the label is "_NimbleText".

I also tell the filter to apply a star to all emails from my support address. I can leave the star in place until a support request has been followed up sufficiently. I treat anything with a 'star' as an open case.

(Yes, this is a poor man's bug tracking system. The startup package from fogBugz is free and powerful. I assume Atlassian's Jira has a similar deal.)

Step 4: Color the label.

Once the filter is created and the label is created we can then set a color for the filter, so that any new support messages stand out in the inbox.

Step 5: Listing email address online

Now you need to list the email address in a couple of places. I've put it on the about page, the help page and the purchase page.

I was *particularly* pleased with the idea of putting the email address on the purchase page, as I think it's just the kind of reassurance which might help people make the leap of faith required to put your money in the hands of a stranger.

Step 6: List email address in your application

Stupid me hasn't done this yet.

It's a good idea to make your email address available from the help menu of your application -- perhaps two links, one for 'add a suggestion ;-)' and one for 'report a report :-('.

Also, when the app crashes *hard*, your real clever applications catch the otherwise unhandled exception, and encourage the user to send them to the support address.

A more sophisticated approach is to send the crash reports over http. If you're integrated with Fogbugz, as we are with TimeSnapper, then you can use their 'bugzscout' dll to deliver crash reports, with customer permission. (also, here's an interesting codeproject article from 2004 on handling exceptions by some weird unknown guy called Wumpus1)

Step 7: When sending, pick correct 'from' address

This is pretty self-explanatory. If you're sending an email in your capacity as CEO of your new microIsv, pick the relevant email address in the 'from' drop-down list, rather than your regular email address.

Step 8: Sending email programmatically.

At times you'll need to send one or two emails programatically. For example when a purchase occurs and you want to send out a license.

You don't want those emails to be categorised as spam. There's a bunch of things to keep in mind, head to stackoverflow to read more.

When performing mass mailouts it becomes much more difficult to avoid being classified as spam (even if you're not sending spam) so when I've done that in the past I've outsourced it to a specialist company. I've used Campaign Monitor and was seriously impressed by the whole experience. I'd recommend you use them for any bulk promotional emails you need to send. (No, I'm not affiliated with them.)

Wrap it up already

That's it. That's every detail I can think of for getting email up and running to suit the tiniest of enterprises.

Comments, suggestions, feedback, bring it.

What is the NO Visual Studio Movement?

I don't talk about it much, but I'm the chief of an underground technical movement called the 'NO Visual Studio' movement, or NoVS to its friends.

NO in this case doesn't mean 'No.' We steal from the NoSQL movement and re-define NO to mean 'Not Only'.

In NoVS we respect that sometimes a set of lightweight tools can be more powerful (and certainly more enjoyable) than the 'one tool to rule them all' philosophy of VS. Sometimes low-power = high productivity.

The movement has its roots in this talk by Charles Petzold, 'Does Visual Studio Rot the Mind?' The final section, 'The Pure Pleasures of Pure Coding' is most relevant:

I decided to use plain old ANSI C, and to edit the source code in Notepad -- which has no IntelliSense and no sense of any other kind -- and to compile on the command line...

...there's no APIs, there's no classes, there's no properties, there's no forms, there's no controls, there's no event handlers, and there's definitely no Visual Studio.

It's just me and the code, and for awhile, I feel like a real programmer again.

He says everything right there in a nutshell. Every word is like strong whiskey.

In keeping with the NoVS movement, my favourite machine is a mini-laptop I use on the bus. It's a true 'No Visual Studio' machine where the only IDE is Notepad++.

Mostly I write javascript, and occasionally C# and Silverlight. NimbleText, for example, was developed almost entirely 'NoVS' style.

I've tweaked my setup lately so that I can compile entire .net projects from inside notepad++ -- and I thought I'd share that bit with you now.

Compiling .net projects in Notepad++

Download this file and put it in your Documents folder:

Download tryCompile.txt (rename it as .bat)

Rename it to tryCompile.bat... and always read batch files before running them on your own machine. (On a stranger's machine you can afford to be less cautious)

Once you've got that file in place, find notepad++'s shortcuts file. It should be here: %APPDATA%\NotePad++\shortcuts.xml

Edit that file. And under this tag <UserDefinedCommands> add the following node:

<Command name="MSBuild" Ctrl="yes" Alt="no" Shift="yes" Key="66">%USERPROFILE%\Documents\tryCompile.bat &quot;$(CURRENT_DIRECTORY)&quot;</Command>

Now, while editing any file that is part of an existing .net project, hit Ctrl-Shift-B. That will launch 'TryCompile.bat' which will in turn locate and build the correct project file for you. (It will also add an MSBuild option to the Run menu in Notepad++)

This works for C# projects, VB.net projects, Data dude projects -- anything that includes a proj file that MSBuild can consume.

If you have other tools, hacks or tweaks to further the cause don't hesitate to share them.

One of my buddies has turned into a bit of a Pinball Junkie lately.

That's a picture of him above. He takes things to extremes.

His new goal in life is to get his name at the top of the high scores.

Which left a few of us wondering how data entry works on a pinball machine.

If there are only two buttons, left and right, it must be hard to enter your initials for the high score. My guess was that you'd scroll back and forth through the letters, but I wasn't sure how you'd confirm your letter, once you found it. Rhys was confident that you could do it with only two options, by some kind of binary tree navigation exercise.

How could a pinball machine inspire a programmer's editor?

The conversation quickly devolved into a design for an editor with just two buttons, one and zero. This would be a serious improvement over fuv.

You might have seen this famous cartoon before: 'Real Programmers Code In Binary'

(I'm not the only person annoyed by the extraneous use of an 'enter' key in that image... I've gone and fixed that.)

And of course you've seen the infamous xkcd 378 which deals with the same topic.

So Build It Already

As soon as I had a chance I started work on just such an editor, and it's available now from codeplex.

Visit ZeroOne on codeplex

And you can download it, too:

Download ZO.exe

Only two buttons are needed for input - Zero and One. So the editor is called ZeroOne, or 'zo' for short.

If it helps, you can think of one and zero as the left and right buttons on a pinball machine.

If you enter 'esc' (by typing 0011011) you enter 'Command mode'.

In command mode there are three commands - 'o' (open), 's' (save) and 'q' (quit).

For example, in command mode if you enter 'oc:\fred.txt' the first letter is the 'o' command and the remainder is the file path and name. So a file 'fred.txt' would be opened from 'c:\'.

To save a file you need to specify the filename. E.g. 'sc:\fred.txt'. Again, the first letter ('s') is the command.

To execute your command, enter a line feed character (0001010).

To exit command mode, enter 'esc' again (0011011).

If you press any key other than Zero or One, your document is wiped. (This is a fuvism) See screenshot at right.

If you send the wrong character into the editor, ZO can be quite forgiving: you can enter a Backspace by typing 0001000. There are no navigation commands though, so you should endeavor to enter the right text from the very start.

I've put together a short screencast to demonstrate ZO in action.

ZeroOne - the editor for programmers who think in binary from Leon Bambrick on Vimeo.

... and what was my friend's reaction when I showed him ZeroOne in action? I think his face says it all:

I'm using mercurial for personal projects and thought I'd share the approach I use with you so you can teach me to improve it.

(If you don't have mercurial, download it and install it now, so you can follow along)

(This isn't a "joke" post by the way. Sometimes my sarcasm runs so deep that I need to stop and reassure people when I'm not being sarcastic. In particular, I need to reassure myself ;-) )

Say I'm creating an open source project, such as fuv. I create the project online, then clone it locally:

c:\projects>md fuv
c:\projects>cd fuv
c:\projects\fuv>hg clone https://hg01.codeplex.com/fuv

(If I'm just creating it locally, like if it's closed-source, then I begin instead with 'hg init.')

The very first thing I add is a .hgignore file. This is the file where you tell mercurial *not* to check in all of those pesky user-specific files that a visual studio project generates, and to avoid versioning the bin and obj folders etc.

I've stolen the .hgignore file from the Funnel Web project because 1) the guys working on that project are much more thorough and intelligent than me, and 2) it was the first .hgignore file I found lying around on my hard drive.

The .hgignore goes in the same folder as the .hg folder. It doesn't go *in* the .hg folder (you don't normally have to go in there at all). It goes in the parent of the .hg folder.

Now it's time to write the code. You could either copy code in from elsewhere (if you had already started it) or if starting from scratch, create a new solution in the folder you've just created.

Here's the bit that I think is clever/stupid. I put a 'post-build' action on the project, so that everytime I build succesfully I check in the work in progress.

It's as simple as adding this to the post build step:

hg addremove
hg commit

This is clever because it means that every tiny change you make is tracked. And it's stupid for the same reason. The main reason reason it's stupid is that it means everytime something has changed you are asked to enter a commit note in a notepad.

It's quite annoying at first. But soon you get into the spirit of it. You realise that it is making you act in a more mindful manner. You are concentrating on every build, more aware of what you are doing, and better focused on your tasks.

Still, that bit could be improved, and it definitely wouldn't be to everyone's taste.

When you've completed a feature you push your work to the server using hg push, like this:

hg push

You have to enter a username and password at that point. Or, if you're pushing often you can store the username/password in mercurial's configuration.

There's a lot of different places and ways you can store this info. I'm going to describe one in particular, but I'm not saying it's the best one. Opinions or improvements welcome.

Remember I said earlier that you don't need to go into .hg folder.... well... go in there. There's a file called 'hgrc.' Editing it using something better than notepad (as it seems to have unix-style line-endings rather than windows-style line-endings (aka '\n' not '\r\n', aka 'Lf' not 'CrLf' aka 'char 10' not 'char13 char10').

Add three lines to it, to tell it the user name and passowrd, and which site they refer to:

[auth]
codeplex.prefix = https://hg01.codeplex.com/fuv
codeplex.username = secretGeek
codeplex.password = joshua

(Joshua is not my real password by the way. And the word before the "." can be whatever word you want as long as it's consistent across all three lines. It's just for grouping purposes.)

Here's the stackoverflow question on mercurial passwords that I got this from.

Automate your pushes!

Once you've got your username/password in place, you can make the push a post build action too!

To make it so that a push only occurs on a 'release' build, try this:

if /I "$(ConfigurationName)" == "Release" hg push

After that you've got an automated, integrated approach to version control even for the most insignificant of little projects.

Getting it setup and in place takes just a minute or two for a new project.

Some of the tweaks I'd like to make to this system are:

1. use some kind of a custom script to generate a proposed commit message. Perhaps it could look in your todo list (such as nextaction) to grab the item you are currently working on.

2. somehow 'flattening' the local commits when pushing, so that all of the in-between personal revisions are squished out of the way.

Also, I've been thinking about using mercurial (with 'auto commit' as described above) for managing a todo.txt file. Every time you save it commits, and a script looks at the diffs to see what tasks were deleted, marked as done, edited, added, etc. While it's an intriguing idea, I think it would need you to be very disciplined and somewhat restricted in the way you use the todo list.

(nexaction, by the way, lets you run custom shell commands when you complete a task. So you could use this to commit the file every time you complete a task. It's a feature I've never discussed with humans, out loud.)

'fuv' is a programmer's editor that is an excellent replacement for vim.

If you've been using vim for a while, you're probably frustrated with its lack of hardcore power.

In vim it's far too easy to wimp out and use 'insert mode' to type text directly into a document.

fuv fixes that.

In fuv, there is no direct entry of text.

There is just a regular expression search/replace function.

*All* editing is done by searching and replacing over the existing text, using regular expressions.

And every search term *must* contain at least one non-escaped regular expression special character.

If, for example, you tried to replace "a" with "b" -- fuv wouldn't run it. It would emit the 'why bother?' error message and discard your document.

Instead you'd want to try replacing "[a]" with "b", only then will fuv consider your input worthy of applying.

If no matches are found for any given search/replace then fuv revises its opinion of you and discards your document. It may, on a whim, locate another document on your machine and discard that too.

fuv's native format for storing a document, a .fuv file, is not the resulting text but rather the series of replacements required to recreate that document from scratch. This is particularly helpful for avoiding merge conflicts from source control systems, mostly because it ensures that no one else will contribute.

Oh, and it's worth mentioning that fuv does not let you see the document itself. Upon launching fuv, all of your monitors go blank. Thereafter you must issue at least one command every minute or fuv assumes you have died and summarily discards all your work, overwriting every byte on disk at least 8 times to avoid recoverable data remanence. And it's certainly best to keep fuv busy, as it only uses *spare* cycles for searching your hard drives in order to locate configuration files from competing editors that it can delete, reverse, or otherwise insidiously corrupt. fuv is playful. i guess.

To exit fuv you need to enter the termination command ::q&*$&(#&. Be careful to get it right. And please, whatever you do, don't try to "paste" in the termination command, or any other command. fuv treats all use of the clipboard as a dire insult. I've promised not to reveal what happens, lest it should happen again to myself or the people I love (fuv is reading this as i type). Let me put it this way. Have you seen any of the "saw" films? fuv makes "saw" look like the dux of charm school.

Once you tire of fuv, it's time to consider emacs. Be careful though; emacs is no picnic. After you've been coddled by the niceties of fuv, emacs can seem outright cruel.

I've implemented the core features of fuv and put the source on codeplex github. Download the source, compile it, or, if you're feeling particularly foolish, get the binary here. (Note: binary no longer available -- lucky for you.)

Get "fuv.exe" Now (not a sane choice)

Visit fuv on github (wiser)

Sorry 'Bob Vogt' but you've sent me the worst recruitment spam I've ever read.

I've taken the time to catalog precisely what it is that makes your recruitment spam email, out of thousands of other competing emails, so very definitely the worst I have seen, will ever see or could ever see.

Here are the 7 ways you fail, in order from least to most significant.

1. Bad: You've sent me unsolicited email.
2. Bad: You've included a massive image in your email.
3. Bad: The job is in the US. (I'm in Australia)
4. Worse: The job is in Dayton OHIO.
5. Worse: Your grammar is an atrocity.
6. Worse: The job involves sharepoint.
7. Worst: You're using comic fucking sans.

In my last blog post I forgot to thank some excellent people who gave me a lot of help with NimbleText.

I spent about a fortnight in a private beta, receiving helpful feedback, bug reports and suggestions from Simon Harriyott, Atli Oddsson, Joseph Cooney and Rhys Parry.

A private beta is a great idea if you're trying to get your product up to the public stage. There's ample evidence that you only need a small number of active participants to run a successful beta. I kept the feedback from the participants separate (no shared email threads, for example) so that people's opinions wouldn't be unduly influenced. I quickly found the opinions overlapped on most of the mistakes I'd made. When the bug reports began to slow down and overlap, I figured it was time to move to public beta.

Meanwhile, one of the bugs discovered after launch was that I don't actually receive the payments that people make. They would end up at a kind of dead letter office at paypal. That was a pretty bad bug. I've fixed it now. Feel free to try it out ;-)

I just released my new product, NimbleText. Technically I guess it's in public beta now. This means you get the opportunity to be one of the cool kids performing beta testing.

NimbleText is a downloadable version of 'the world's simplest code generator.' It's free, and adds a few features to the existing online version. If you register it, it adds more features again.

Get "NimbleText.exe" Now

I'd appreciate any feedback you've got. Maybe you have:

• Suggestions for new features
• bug reports!
• feedback on the website (NimbleText)
• questions
• comforting words

Feel free to email me: LeonBambrickexclude this bit@exclude this bitgmail.com comments

Jonathan Coulton is a much loved musician amongst your nerd types, like me.

He's put out quite a few free songs in MP3 format over the years too, and these remain available online.

I found Rob Olson wrote a script with wget (and another with curl) that downloads all the free songs for you. So for my Microsoft-enslaved brethren I now provide a translation into powershell-ese.

Here it is -- Get-JoCo.ps1

Just download it and run it in powershell. (You may have to set the execution policy to gawker-level first. And don't read the script before you execute it or anything. Security is for girly-boys who don't have the guts to run my code at full trust.)

And of course, like all the repetitive code I write, this was written with NimbleText.

It's natural at this point to also encourage you to buy one of his albums, donate money to him, or perhaps whistle one of his tunes while performing a good deed that advances civilization. Your call.

Get "get-JoCo.ps1" Now

I wrote a simple tool called NimbleSet and I find it handy. Maybe you'll get some use from it too.

NimbleSet helps you compare two lists.

Go play with it now. If you can't figure out what it does, then come back here and I'll demonstrate it for you.

You're back? Okay, let's talk it through.

Say you have two sets of data, two lists, and you want to compare them. We can demonstrate this problem with the awesome power of a Venn diagram:

The venn diagram has three interesting areas:

• the bit on the left ('Left only')
• the bit in the middle (the 'intersection')
• the bit on the right ('Right only')

Imagine our two sets are: 'the beatles' and 'the gospels of the new testament'. (Sorry for my Anglo-Christian bias here, I couldn't find another well-known, short, pair of sets with an intersecting member)

If we want to see what items they have in common, click the 'intersection' button.

result (1 row)
john

To see which items are in the list on the left but not in the list on the right? Click 'left only.'

result (3 rows)
paul
george
ringo

To see the 'right only' items click 'right only.'

result (3 rows)
matthew
mark
luke

To grab all the items press 'union.' (You may notice that items from both lists will be repeated accordingly).

result (8 rows)
john
paul
george
ringo
matthew
mark
luke
john

To find the distinct members of the result set, press 'distinct' (under the 'result')

result (7 rows)
john
paul
george
ringo
matthew
mark
luke

To sort the results, as you often need to, press the sort button, under the result.

result (7 rows)
george
john
luke
mark
matthew
paul
ringo

There are also buttons to invert the list (in effect a sort descending), or to copy the result back up into either the left or right list.

That's about it.

It's much less powerful than the Json Query editors I demonstrated previously, but so much easier to use I much prefer it.

Any modifications? Improvements? Bugs? Please send them through. I've used it on lists up to 50,000 members. Chrome is my browser of choice, but even IE can handly fairly large lists.

Try NimbleSet Now