Disposable Email Aliases: Organize Your Messages

There is a trick you can use with many email services out there that could really save you some hassle with runaway junk email. Disposable email aliases (also known as sub-addresses) are quite handy. They allow you to quickly enter an email address in a sign-up/registration form that is different than your actual email address. Instead of signing up with your real email address (say, it’s iamawesome@somewhere.com), you would use a disposable alias instead (e.g., iamawesome+untrustworthy-service@somewhere.com).

Why Would I Ever Want to Do That?

It’s simple, really. How many times have you signed up for a new website/service, and then started receiving, even more, junk email than you already were? Perhaps, you noticed a sudden surge in spam just after subscribing to a newsletter or entering a sweepstakes/giveaway. Many websites and services don’t hesitate to sell your information to anyone willing to pay for it.

Sure, you can enter a fake name, phone number, and even mailing address to maintain your privacy. However, you know you’ll have to verify your email address before you can gain access to whatever goodies your after. Furthermore, you may even need to receive an email from the asking company to get what you want (e.g., newsletter, reminders, notification that you won a prize, etc.).

Providing the requesting site/service with an email alias helps you achieve your goal with them, but give more power to handle the potential onslaught of junk email. The best part is, you will receive any email sent to a disposable email alias in your regular inbox, yet you’ll be able to see that it was sent to the alias.

OK…What Can I Do with This New Power?

By providing an email alias, you can do all kinds of neat things!

  • Know exactly who sold your email address.
  • Easily filter incoming email to your alias into folders/labels, instead of the standard inbox.
  • Send an email directly to the trash when received to your alias.
  • Register an additional account with a website/service, but still receive email at your main one.

How Can I Create Disposable Email Addresses?

Each email provider may be different, but there are quite a few that stick to a pseudo-standard. Many email services use the plus sign (+) then whatever additional text you want after your username to construct a disposable alias. So, if I wanted to sign up to shadyplace.com, and suppose my real email address is “matt@somewhere.com”, I could instead enter: “matt+shadyplace@somewhere.com”.

Other email services use a dash/hyphen instead of a plus sign. Others still, require you setup a dedicated “basename” to use for disposable email aliases; then you add a delimiter (dash, plus sign, or whatever), followed by your new alias.


You knew this wouldn’t be perfect, right? Well, there are still a lot of websites/systems out there that don’t properly support valid email addresses.

Bad Validation on Web Forms

Many input forms validate the data you provide to make sure it’s properly formatted based on the type of data expected. For example, when you enter a phone number, sites may attempt to ensure you only enter digits, and only in the format allowed for the area (e.g., in the US, only 10 digits are allowed in groups, separated appropriately; ###-###-####). A US zip code must be either 5 or 9 digits and if 9, the last 4 must follow a dash (e.g., #####-####).

Well, an email address must conform to a very specific format as well. For example, an “@” must be present, but cannot be the first or last character, etc. Unfortunately, so many systems incorrectly validate email addresses. Most are overly restrictive. For example, a plus sign (+) is totally acceptable in an email address, before the “@” symbol. Yet, many websites don’t allow a plus sign at all. So, if your email provider allows disposable aliases, but requires a character that some (or many) websites won’t allow you to enter your email address, you’re out of luck with those services.

Hackable by Humans

Another issue with most disposable email aliases is the fact that it doesn’t take a genius to look for these patterns in order to thwart them. In other words, a spammer could write a program to look for the plus sign, and remove that part of the email address in order to get at your “real” address. Worse still, a nefarious programmer could substitute any text after the plus sign in order to bypass any filters you may have set up to organize/delete your incoming email.

Sending From a Disposable Email

Finally, most email providers allow you to send messages from a disposable alias. Often you can set up a standard alias (not disposable) with these services and then send from those aliases.

Support for Disposable Aliases

There are several email providers that support this concept of “disposable aliases”.

Supporting Email Providers as of 2016-Jun-10

The following email providers allow you to use disposable aliases. I’ve also provided an example alias for each, if my username (or base name) were, “groovynobody7531” (which it is not), and I wanted to create an alias for “education”.

Email Provider Example Disposable Alias
More info
(also, Live and Hotmail)
More info


If you’re using the business/work edition of some of the above email providers with your own custom domain, this feature still works! For example, if you have Gmail for Business and setup your custom domain, “example.com”, for email, you can still use disposable email aliases with your domain (e.g., matt+whatever-i-want@example.com). I use this at work all the time when I’m testing websites we’ve written and need to set up multiple accounts to test against.

“Click Here” Has No Place in Software

No "Click Here"“Click here”, is probably the worst text anyone could choose for a link/button. I say “probably” because I’m sure there could be worse choices for a given context. Regardless, please don’t use, “click here”…ever.

“Click Here” is Often Redundant

If you design your software appropriately, it should be obvious what action is necessary to invoke some feature. If it looks like a link or a button, you click it. Therefore, if you feel the need to inform your users what action to take, you should reconsider the design of such elements.

Your software’s links/buttons should be designed in such a way that users can easily identify them for what they are. Once they identify them, they know what to do with them. So, use colors, underlining/overlining, borders, icons, depth, and other techniques to help users identify your links and buttons.

Also, do yourself (and others) a favor by using more than just color to differentiate links from other text. There are plenty of people out there with color vision issues that prevent them from distinguishing a subtle color change (even a dramatic change is hard to see for some color blind individuals).

What Text Should be Used Instead?

You know that verbiage you included just before, or just after, the phrase, “click here”? That’s where you should look for the text you should be using for your link or button instead. Consider the following example sentences with the infamous “click here” link/button.

Let’s see what these sentences should look like instead.

Proper Context

Now, your users have context right there with the link/button. They know what clicking it will do now. They don’t need to be told to click it; they need to know what will happen if they click it.

Search Engine Optimization (SEO)

There is an added bonus to using the proper text for your web links; SEO. All the top search engines categorize pages based on their content. Some of the best sources of that content are the page title, headings on the page, and the text used to link to the page. A bunch of “click here” links to a page do nothing to help search engines determine what that page is about.

Book Review: Getting Started with Twitter Flight

I recently read Getting Started with Twitter Flight by Tom Hamshere. The book was published in October 2013. Another book was also published around the same time. To my knowledge, these are still the only two books about the Twitter Flight framework.

The book is very short; Chapter 1 marks 18% progress. There is nothing wrong with a short book. To me, it alludes to the simplicity of the Flight framework.

Furthermore, there is a bit of content dedicated to justifying choosing Flight for your next project. Again, I do not believe this is a flaw of the book. As developers, we want to know about success stories with a framework we are considering.

The Good

Tom does a good job of highlighting what Flight is and is not. For example, he brings up the fact that Flight does not have a data model system. He also points out the absence of an included templating engine. Better still, the author touts that these things are not “missing”; they are intentionally left out, and that gives you more flexibility to choose what works best for your project.

I really appreciate the author’s recommendations for event naming throughout the book. He takes this to another level by dedicating an entire chapter to the cause. Even if you disagree with the actual convention Tom shares, his points on devising a naming convention are spot on.

Mixins can be tricky to grasp for many. The book’s chapter on them goes into exceptional detail. In fact, Tom makes certain to answer questions a reader may not know will be on his/her mind soon after starting to use mixins. He tackles mixin order/priority, method extension, advice, and mixin composition (mixins within mixins).

The Bad

Chapter 4 dives into setting up a Flight application. I felt this chapter was a little too tool-oriented. It aims the user at using Yeoman to generate the scaffolding of Flight pieces. I understand this approach makes for a very fast “get up and running” scenario, so maybe I am over-criticizing.

In contrast, chapter 12 discusses testing Flight components and mixins from a more agnostic view. There is a brief mention of the Jasmine-Flight and Mocha-Flight test extension projects. However, most of the examples show how to get at the necessary Flight objects in order to exercise them with assertions for any test framework. This is okay, but it does not fit the approach used elsewhere. I found it very odd to see a section on “Extending Jasmine for Flight”. The Jasmine-Flight project already does just that (and is referenced at the beginning of the chapter), so I do not understand the reasoning for this content.

Throughout the book, I spotted several mistakes with the code examples and corresponding discussions. Managing code for a book is not trivial, but I did expect higher quality for such a short book. Most of the mistakes were typos or names that obviously changed over the course of refactoring. However, a few of the mistakes are outright incorrect code bits. I read another review of this book where the reviewer stated he submitted errata that he discovered. Upon looking on the publisher’s website, I could not find any errata listings.

In the same spirit of errata, I do expect to see some attempts at upkeep for a technical book. By that I mean, as the framework changes, readers should really be able to see notes about areas of the book that are no longer relevant. How else will a newcomer make sense of the content when attempting to apply it to a later version of the framework? One simple example is the “defaultAttrs” property of a component. In a later version of Twitter Flight, the property was renamed to “attributes”.

A much more drastic example of this is with regard to the author’s opposition to the use of nested components. The author starts the book touting no “parent-child” relationships among components as a strong plus for a scalable architecture. In chapter 13, Tom details the problem with using nested components and how to get around their use. However, the Flight team recently released the withChildComponents mixin to handle just that; child/nested components. If you do some forum digging, you can even find that Tom had a part in a similar mixin when his team (of TweetDeck) created the withTearDown mixin internally and began probing the community for interest in open-sourcing it.

This is a perfect example where the author should come back to the book and make some amendments based on his own changes in viewpoint. I found forum posts about his team’s belief in the power of nested components since the book was published. That information is certainly worth knowing to a reader of a book that is just a little over a year old! At least add a note on the publisher site with a link to a blog article. Better still, revise the book as a second edition.

The Ugly

The “ugly” is named such because it is the part of the review where I offer my recommendation for or against this book. I also hate being on the fence.

Were there a better book available for the Twitter Flight framework, I would not recommend this book right now. I would not, because it feels like the book was published and never thought about again. I can live with the errors, although an errata list would be ideal. All the issues combined with the fact there are no amendments or notes about changes of the author’s views just add up to a total that is less than whole for me.

Since I have not read the only other book on Flight available, I cannot say with certainty that you should not read this book. Information on Flight is hard to come by; trust me on this one. Therefore, anything you can get is worth reading. However, be very mindful of the content; do some research, and try it out for yourself. You should be able to discern the gospel from the opinion if you are careful.

Why We Switched from AngularJS to FlightJS

The landscape for web development is rapidly changing. It seems like not too long ago, I was making a decision with my team to avoid using JavaScript in our projects due to browser inconsistencies; that was actually 15 years ago. Since then, we’ve seen jQuery, HTML5/CSS3, Modernizr, and an ocean of other JS frameworks.

Haste Makes Waste

How do we (web developers) keep up with all the JS frameworks popping up monthly? That is a challenge indeed. The thing I try to remember is, rushing to adopt the latest thing can lead you and your team to a painful misery.

Sure, you should check out these frameworks. Read about them, code a little with them, run some tests with them. Just don’t go all-in with a framework for the sake of “being current”. Avoid heavy rewrites of your system(s) without knowing how key parts will perform under the new regime.

Angular is Super-Awesome

Pro AngularJS (Expert's Voice in Web Development)AngularJS is quite different than most of the MV*1 JS frameworks out there. Angular lets you, basically, extend HTML to your liking. This is a key concept for the framework. There is a very strong template engine built into Angular around this extension concept. Furthermore, directives provide developers with the power to extend HTML however they see fit. For me, the thing I really like about Angular is its two-way data binding.

Angular’s two-way data binding makes me smile. With other similar frameworks, you either get one-way data binding, or you get some twisted mass of wrappers in order to achieve mostly two-way data binding. Now, I’m fine with one-way binding, if it’s easy enough to get the data out when I need to. However, if you’re going to offer two-way data binding, it has to be seamless and unencumbered.

I loathe having to wrap my models in some specialized structure. It’s even worse when I have to use multiple types of wrappers depending on what type of model I’m using. The worst of all is being forced to not only wrap my main model with a certain wrapper object, but also having to then wrap some properties on that model further with other wrapper objects. Yeah, I get why it’s considered required in order to achieve the goal.

Angular works with plain old JavaScript objects (POJO). I love that! It just knows when the user changes an input value tied to a property on my model and updates my model when that happens. It also watches my model for changes via code and then updates any input values in the UI automatically. Brilliant! Yes, there are some performance concerns with constantly polling objects.

There are a ton of books on AngularJS. Even a top 10 seller on Amazon (at the time of this writing) for all JS development books is on AngularJS!

So, Why Abandon Angular?

If you are expecting to read that we “abandoned” AngularJS for FlightJS because Flight is better, well…go back and read the introduction of this article. I learned that lesson long ago. You really should have good reasons against the framework already in-place before deciding to leave it. I try to never make such decisions purely on how much I like some other framework over the current one. That mentality will have you hopping from rewrite to rewrite, and your projects will suffer.

We also didn’t abandon AngularJS. We’re watching it’s future and viability carefully though. We still have projects using it where a decision to switch has not been made at this time.

Like so many frameworks, AngularJS has some strict rules you have to follow (once you learn them) in order for everything to work together. It’s to be expected to some degree. However, when you find that your creativity or ability to generate behavior in your application suffers because of those rules, you have a problem.

With AngularJS, try getting field validation on a form that doesn’t trigger on most fields until the user moves focus from the corresponding input, but also doesn’t trigger on some fields until the form is submitted. I dare you! Can it be done? Sure. However, it is a horrible, ugly mess to get something like that working due to limitations imposed by the framework.

Let’s not argue over the viability of the above validation request. The scenario I’ve depicted is actually one with proven UX benefits, no matter how poorly I’ve described it here. That’s not the point anyway. What gives Angular the right to tell my team how to implement a good validation UX? None.

We also found creating custom directives of any heft was somewhat painful. Having to avoid DOM manipulation outside of directives (never tweak the DOM from a controller) added tons of extra ceremonial code just to fit that restriction.

Scope is cool, but it is so misused in a lot of “educational” material, it’s hard to tell how it should be used. Even the official learning documentation uses Scope frivolously. There are several articles about using Scope properly. It’s obviously not so obvious how you should use it.

We’re not the only ones spotting the flaws. Others are questioning if this is a fad framework. You should always question a framework and its direction. If it changes for the worse, stick with a version you still trust, or look to get out. Have you heard about AngularJS 2.0 and the direction shift it’s taking? Don’t judge 2.0 just yet; wait for it to release first. However, be prepared for massive change.

The Angular Way

I’ve seen/read/heard so many times that you need to do this or that “the Angular way.” That’s half the problem though! There needs to be more flexibility. I’m not talking about how you need to use dependency injection with a framework, or that it relies on jQuery. What I’m talking about is how much of a pain it is to utilize other external libraries with a framework. Before AngularUI’s Bootstrap project hit the scene, it was very painful to use Bootstrap components with Angular; I’d say impossible, but that’s just lazy.

So, what if I’m a Foundation user instead? Again, it took some time, but some folks came up with directive projects to integrate Foundation with AngularJS. Still, it feels clunky to have to go to all that trouble just to integrate with other libraries. Pick another, lesser-known library and there likely isn’t something out to easily allow you to use it with Angular. What’s more, you’ll be putting in a lot of time writing your own integration.

You should control your framework, it should not control you.

How is Flight Different?

Getting Started with Twitter FlightFlightJS is very different. I won’t say it is better for all the reasons already included above. However, for my team, on many projects, Flight will be a better fit for us. You should read about it, see it in action, play around with some code, then decide if it’s a better fit for your team. Don’t take my experience with Flight as a de facto. Flight utilizes the built-in strengths of HTML and JavaScript. Specifically, it uses the DOM (document object model) and its event model. You author succinct components and attach them to DOM nodes. These components are complete islands; no component can reference another component, by design. Absolute decoupling of components is key to Flight’s power.

Communication is Important

So, if no component can reference another component, and each is a small, self-contained bit of behavior, how do they all communicate? Just because a component cannot directly hold a reference to other components, that doesn’t mean no coordination can be achieved between groups of components. I don’t have your cell phone number, but I’m communicating with you right now.

Events are the sole form of communication between components. When one of your components does something notable, it should publish an event about that accomplishment. Sometimes, events are just notifications that something was done. Other times, components include full details about what was done. Other components subscribe to the events they care about and respond how they see fit.

UI components are attached to a specific DOM node that they work against and possibly manipulate. This type of component subscribes to events within its node to respond to user interactions (i.e., click, change, keydown, etc.) and to other external events. These components also publish custom events that make sense to the system (i.e., ui-user-list-requested, ui-user-selected, etc.).

Data components are attached to the document node and don’t mess with elements in the DOM. Instead, they provide non-visual behavior (AJAX interactions, data sorting/filtering, etc.), then publish events about those tasks (i.e., data-user-list-retrieved, data-user-selection-saved, etc.).

How to Manage All Those Events

If you think about all the tiny little components you could end up creating in a given application (Twitter has hundreds in play on what seems like a simple front-end), you may wonder how it’s possible to keep track of all the events each publishes and subscribes to.

It can certainly be a tangled web of event names to manage, but remember; each component will likely only be concerned with a handful of events. That said, if you misspell an event when subscribing, even your tests can’t catch it if you think you spelled it correctly.

I use Trello to manage the components that need to be worked on. I also use shared documents (for my teams, they are on Google Drive) to catalog every event that is published by components on a page. I am also toying with the idea of writing a simple Node.js tool to parse a project’s components in search of event publishing and subscribing in order to generate a living document of event usage.

Mix It Up

Composability is another feature of Flight I find remarkable. This may seem counter-intuitive considering that components aren’t allowed to reference other components. However, there are other ways to achieve composition. Flight uses mixins to “include” shared behavior with your components.

Suppose you want to encapsulate a form in a component and make it modal when shown. You could write a dialog mixin. Your form component could then “mix in” the dialog mixin to extend its behavior with modal focus. Likewise, if several components you are authoring have many shared behaviors, even with slight variations, you can write a mixin to act as a “base type” for those components. You can even override just the bits you need to for any mixin your component uses via advice; a special type of mixin for just that purpose.

Wait, ‘X’ and ‘Y’ are Missing

There is no template engine in FlightJS. There is no data binding in FlightJS. These things are “missing” intentionally. Flight doesn’t impose those things upon you. That does mean you need to handle those things yourself or via other libraries. However, I have found it freeing.

Why should a framework tell me I have to always use client-side templating? What if server rendered views retrieved via AJAX are the most performant for my application? I should have the freedom to choose how I render information to the user on an individual basis.

In fact, in one of our websites (a hybrid with separate areas that act sort of like SPAs themselves), we discovered that for some views server-side rendering was much faster. Yet other views benefited most from client-side templating with raw JS object data bound to them. With Flight, we were able to choose what worked best for each situation.

More Information

There is very little information about FlightJS out there compared to more popular frameworks. In fact, I’ve struggled quite a bit to find much of anything. I did buy the book shown above; Getting Started with Twitter Flight. It’s written by a Twitter developer that works on TweetDeck, so you can count on accuracy and insider knowledge of the framework. The book has been invaluable for some of the finer points of Flight.

Another great way to learn is to also read the tests written for the framework.

Who are “We”?

I’ve been referring to this elusive “we” and “my team” throughout this article. I work on several teams, as lead on most (but not all). I can’t reveal all of those I’m discussing in this article outright. However, I can talk about one very small team.

My team at Wish on a List is currently in the process of moving from AngularJS to FlightJS. I plan on writing about that transition on this blog over time. We’re over half way done, so there is plenty to write about from our perspective.

1 MV* indicates an array of patterns that all share concepts of models and views. It’s the last parts of the patterns that differ; thus the *. Some of the many MV* patterns are: MVC, MVP, MVVM, MVPVM, etc.


Performing without Rehearsal: No Thanks

Would you perform in a play without any rehearsal? Perhaps if the play were a monologue on a topic you knew inside and out? Of course, I think even then, I’d practice my skit in front of a mirror or some friends and family. I’d at least try my luck with the dog or cat!

Preparation seems like a given, especially for large/important projects. In addition to preparing for something of importance or complexity, it’s always good to do a “dry run” to see how things will go. This applies to technical projects/tasks as well as things like performances in front of an audience. Odds are, you’ll have an audience; it just may be a horde of users for your system. It’s better to work out the kinks and automate as much of the process as you can.

So, imagine having to upgrade a piece of open-source software that your team heavily customized through several years of significant version releases. Suppose the client was afraid to allow you to perform any upgrades for years as they tacked on more and more customizations to the existing codebase. After all, it’s been working all this time. To make matters worse, suppose many of these customizations had to be made to the core code due to the youth of the version in-use. Now, finally, you are allowed to upgrade to the latest version. It’s going to be a nightmare, but you have a plan…in your head.

You know that a rehearsal is in order. In fact, there are so many things that need to be rewritten in order to work with the latest version of the customized software, you just know that problems will appear during the process. So, it makes sense to “perform” the “play” on the base software and database before any of that code is rewritten and re-integrated.

What Really Happens?

You know what really happens in this story; don’t you? Yeah, you do. The coding begins first. A fresh installation of the latest version of the software is used to rewrite all those customizations properly. Then, after a lot of effort is sunk into the coding, somebody thinks it’s a good idea to upgrade the data (no doubt this is huge amounts of data); the rehearsal.

The “performance” is a disaster! The data won’t upgrade; most likely due to all those customizations that slowly worked their way into the bytes somehow. Now you’re stuck with the old version of the software until you can figure out what is preventing the upgrade. There is way too much data to make it easy, so the process could take months, if your client even opts to bother now.

What’s worse? The coding for the upgrade is nearly finished! So, what if the client decides to cut-and-run on the upgrade? All that coding could be discarded; thrown away. Is it your team’s fault for not insisting on performing the rehearsal first? Is it the client’s fault for pushing hard to get the upgrade done and wanting to see their custom features in the new system quickly?

I wouldn’t be the one to answer those questions. I sure as hell wouldn’t be the one to say, “I told you so!” No, that would be a bad idea.

What’s the Moral?

Push hard for what you know to be the right path to a successful project; no matter what that project may be. Have I seen the above “story” happen several times in my career? Yep. Would I feel bad if I experienced the same again? Probably a little, but I’d feel a lot less remorse because I would shout about my experiences if necessary to be heard.

Decision-makers, listen to your experts. Clients, you are decision-makers, so the preceding fully applies to you. However, if you choose to ignore the advice of your experts, don’t expect them to sympathize with your plight. More importantly, please don’t make the ensuing backlash their burden to bear alone.

Git vs. Mercurial


Git is fast, efficient, and not too opinionated. Throw-away branches are a plus (and a minus). With this feature, you can create a feature branch to try something out or work on a new feature in isolation. When you’re done, you can merge the branch back to master/dev/whatever, and delete the branch. In fact, this methodology is prescribed. It’s as if the branch never existed. That can be great, but there are down sides. Knowing the true history of a feature branch has advantages, and you’ll miss out on them if you delete it. If you’re okay with that though, Git branching rocks.


Git is certainly great, but lacks polish when dealing with its users. If a command has 3 primary uses, and 1 is used 90% of the time, 1 is used 8% of the time, and the last is used 2% of the time, wouldn’t it make sense to make the most used scenario the default for the command? Why is it that so many Git commands require the most used scenarios/options of that command to have so many switches, yet the least used scenarios are the default switch-less version of that command?

Prefer a GUI over the command line? Don’t you ever tell a Git lover that you prefer a GUI for managing your repositories. Just, don’t even bring it up; you’ll get flogged! However, you do have options. GitHub for Windows is excellent software for visualizing your repos in, well in Windows. SourceTree is another great application for working with Git (and Mercurial) in Windows and Mac. But, again, just don’t bring up the fact that you use a GUI for Git. It’s just safer if you keep that to yourself.

Remote Hosting

Sure, you can host a remote repo on your own server, but there are much friendlier options. GitHub is the de facto standard for hosting Git repos and sharing them with others. They support public repos for free, which is great for open-source projects. Bitbucket added support for Git repos after solely supporting Mercurial for quite a while. Now, you can host either type of repo and as an inverse to GitHub, Bitbucket supports private repos for free. Kiln is another great hosting provider for Git (and Mercurial). You can even use Git and Mercurial interchangeably with repos stored on Kiln (which is simply amazing).

Mercurial (Hg)

Mercurial is fast, efficient, and a bit opinionated. Most people will have a difficult time finding real noticeable differences between Git and Mercurial. The absolute biggest difference is branching. Mercurial doesn’t really have a concept of throw-away branches. That is, once you create a branch in your repo, it’s there for keeps. You can get rid of branches with plugins or cloning around the revisions that include the branch. However, having permanent history is actually a strong point for persistent branches in Hg. When you look back through the history, you can actually see where the named branch revisions came from, and that can provide insight into the origins of that code. If you need to work on an experimental branch that may not make its way into the repo, you do have a recommended option; clone the repo and work in the clone for the experiment. If your experiment doesn’t pan out, delete the clone; if you decide to use the code, push it back to the original repo and merge.


Mercurial is more friendly to non-Linux systems and their users. Yes, I’m vaguely nodding to Windows here. Typically, the commands for Mercurial have sensible defaults, so you’re not constantly hunting down what options you need or constantly typing just to execute a simple command. Installation is also a breeze.

If you prefer a GUI to the command line, there are very nice pieces of free software available. TortoiseHg is a favorite (Windows only). Hailing from the days of TortoiseSVN, this product integrates with Windows Explorer, but now supports a stand-alone client for managing all your repos in one view. Let’s not forget the new kid; SourceTree (by the folks behind Bitbucket) is an excellent Mercurial (and Git!) client that runs on both Windows and Mac. They are catching up with features found in TortoiseHg, but while quickly doing just that, they are also providing unique features (and workflows) to a great application.

Remote Hosting

Again, you can host your own remote repo; Mercurial supports that option. However, Bitbucket offers free hosting for private repos and their system is just outstanding (you can also host Git repos with them). Kiln is another wonderful hosting option for both Mercurial and Git. As mentioned above, you can even use Mercurial and Git interchangeably with repos hosted on Kiln (your team members can use whatever they are comfortable with).

Which is Better?

Really, the appearance of distributed version control systems was a tremendous turning point for developers. Everybody has a full copy of the entire repository as a local copy. You can work offline and sync later. Each developer can act as a makeshift backup of the shared repo. Branching/cloning allows for safe feature trials that can be selectively merged into more stable branches.

Git and Mercurial resolve to the same end; a very efficient history of all your project’s changes over time. It really comes down to your preference of branching strategy and sensible/insensible defaults for the available commands. So, which is better; Git or Mercurial?

Nice try! There’s religion, then there’s politics, and right behind those are programming languages and tools. If you state that one is definitely better than another, you set yourself up for a war. However, we do all have an opinion. Mine is for Mercurial, but that’s just me. I use both extensively on many projects, so I’m not just talking out of turn.

Note: I won’t tell you that your preference is wrong, so do me a favor and don’t tell me that mine is either. Besides, if you’re really nasty about it, I’ll never approve your comment. ;-)

What I Really Want for Christmas 2012

I am becoming less and less concerned about tangible things in my life. A minimalist, I am not…yet. My wife and I are certainly heading down that direction of our yellow-brick road. However, I still want “stuff” for Christmas!

So, if I don’t want tangible things, what do I want for the 12 days leading to Christmas this year? I’m glad you asked. I want:

  1. currency that is notfunny money“,
  2. the practice of switching back and forth between standard and daylight savings time to go away (it’s just plain unnecessary in 2012),
  3. a conscience that’s just a little more forgiving of me,
  4. to live in a city that’s not completely corrupt and a county that’s not completely broke,
  5. whole foods stores/markets within reasonable reach,
  6. game developers to focus more on co-op multi-player than deathmatch/PVP,
  7. a house that has less…right angles (you heard me),
  8. financial freedom,
  9. more chance to enjoy nature,
  10. deeper, engaging stories in single-player games,
  11. better chances to show my wife I care,
  12. and less worries about safety by moving away from the 2nd highest rated city in the country for violent crime (per capita).

Convert a Value to Nullable

I’ve decided to start a new series-like set of articles on highly reusable code snippets. I write a lot of these types of snippets and figure it’s time to share. Kicking off will be the ConvertToNullable function.


I despise boilerplate code in general, but I really hate writing the same code over and over to check if a variable equals some “default” value and acting on that case. That’s why I wrote SafeDataReader (article to come) years ago. SafeDataReader is constructed with a DbDataReader and adds a ton of new Get method that let you easily and safely access fields on the underlying data reader with strong typing.

One of the key benefits of SafeDataReader is that every Get method has an override for supplying a default value. If you use this version of a method, it will return your default value if the field is null (DBNull.Value).

Unfortunately, I wrote SafeDataReader before the much needed Nullable type was introduced to .NET. I also have not taken the time to go back and update it to support nullables. That leads us to the “dilemma” behind today’s code snippet.

The Problem

Have you ever written something like the following?

DateTime? someDate;
DateTime someTemporaryDate = GetSomeDate();
if (someTemporaryDate == DateTime.MinValue) {
  someDate = null;
} else {
  someDate = someTemporaryDate;

The GetSomeDate function may be legacy code, but it only returns DateTime (or another value type). However, you write code for the new millennium and want to use nullables for a clearer intent of the unknown value. Regardless, this type of code block is a PITA that bleeds unreadability.

Going back to my SafeDataReader example, here is some code that is nice and tidy until the DateTime value needs converting to a Nullable<DateTime>.

var setting = new Setting {
  Title = reader.GetString("Title"),
  Quantity = reader.GetInt32("Quantity", 1),
  BeginDate = reader.GetDateTime("BeginDate"),
  EndDate = (reader.IsDBNull("EndDate")
      ? (DateTime?)null
      : reader.GetDateTime("EndDate"))

Ugh! I hate that bit with the EndDate. Since Setting.EndDate is a nullable DateTime, I have to jump through ugly hoops to handle a null just because my GetDateTime method doesn’t yet support nullables.

The Reusable Solution

Nothing beats a generic reusable solution to such a problem. Let’s see it!

protected static T? ConvertToNullable<T>(T value, T defaultValue)
  where T : struct {
  if (value.Equals(defaultValue)) {
    return null;
  return value;

protected static T? ConvertToNullable<T>(T value) where T : struct {
  return ConvertToNullable(value, default(T));

Now, we have something that will clean-up those previous examples.

DateTime? someDate = ConvertToNullable(GetSomeDate());
var setting = new Setting {
  Title = reader.GetString("Title"),
  Quantity = reader.GetInt32("Quantity", 1),
  BeginDate = reader.GetDateTime("BeginDate"),
  EndDate = ConvertToNullable((reader.GetDateTime("EndDate"))

That is much better! Enjoy!