I recently found this great decision tree for centering elements with CSS. It is both accurate and helpful, which you might expect since it comes from the excellent CSS-Tricks site.
Archives for category: Uncategorized
It’s been about a year since I created the Mercurial nextMerge revsets alias. It has worked well, but recently the complex Enterprise Web Library repository exposed some flaws, especially the script’s obliviousness to the need for recursion when delving down the graph to determine the safe merges that must be done in preparation for a “no-op” merge. I’ve just published a new version that fixes all known flaws. It deals with the recursion issue not by actually doing recursion (which isn’t possible with revsets), but by returning multiple changesets to let the user know that nextMerge must be rerun.
Here’s the updated code, which you can drop into your Mercurial configuration file:
I’ve just created a new package in the ReSharper Gallery containing external annotations for the Humanizer library, of which I’m a big fan. If you use Humanizer and ReSharper, open up the ReSharper Extension Manager from Visual Studio, find the Humanizer.Annotations package, and install it now! It doesn’t yet cover the entire library, but pull requests are welcome!
I greatly enjoyed this talk by Erik Dörnenburg and Martin Fowler about the responsibility aspect of software development and especially software-as-a-service. We developers should never forget how privileged we are, and with this comes the responsibility of periodically checking ourselves to make sure we’re helping to take the world down a good path.
(Post title from FDR)
We just set up a new team blog over on the Enterprise Web Library site. Also, I just posted there about why we no longer support ASP.NET session state.
Last week at the Build conference, Microsoft announced the formation of the .NET Foundation and the related open-sourcing of Roslyn, now called the “.NET Compiler Platform”. I have been building web applications atop .NET for over a decade and this is the most encouraging news I have heard in a while.
Over the past few years I have watched platforms like Python, Ruby, and of course the JVM (via “new” languages such as Groovy) steal developer excitement away from C# and .NET, at least in the open-source community. Check out this Ohloh graph. While I’m not sure what the future holds for .NET as a client-side platform (I think it largely depends on Xamarin), for server-side, line-of-business web app development, .NET continues to be a terrific platform (if you use the right libraries/frameworks on top of it) and there is absolutely no rational reason for an experienced web developer to jump ship. If Microsoft, Xamarin, and the other eventual sponsors of the .NET Foundation follow through and grow the foundation to its potential, they have a good chance of choking off the somewhat-irrational exodus from the platform.
I’m heavily involved in the Enterprise Web Library open-source project, and the other contributors and I sometimes run into situations in which we need to merge two complex branches together. This happens mainly because we don’t always have the time to promptly review and merge each other’s changes; sometimes a contributor will write some code that won’t make it into our canonical repo for several months. But anyway, when merging, we try to always avoid “criss-cross” merges (i.e. merges in which the two branches being merged have multiple Greatest Common Ancestors) since these can result in changes being accidentally undone and other bad things.
After toiling away for the better part of a week, I’ve created a Mercurial revsets alias called nextMerge that takes in two branch heads (merge destination and merge source) and gives you the next ancestor of source that you should merge into destination. It will just return source itself if there is no criss-crossing. If there is criss-crossing, it will tell you to first merge each parent of a merge changeset that would cause a criss-cross, and then it will tell you to actually do the criss-cross merge, but at this point it will be what I call a “no-op” merge, meaning that it should not change destination in any way since all you’re doing is merging in a merge changeset whose parents (i.e. the actual code changes) have already been merged. This no-op merge reduces the number of Greatest Common Ancestors for the original desired merge, and when we get down to just a single GCA, we can safely proceed with the original merge.
Complicated explanation, I know. Drop me a line if you want to know more. But to use nextMerge, just drop the code below into your Mercurial configuration file:
Happy merging!
I recently published a new essay about single-page applications:
I’ve spent the past ten years building and maintaining web applications, and during this time I’ve collaborated with a few other people to organically develop a library/framework that helps with a lot of the commonality I’ve seen across these applications. Up until now, this library has been internal, but after a couple months of hard work I’ve finally been able to release it under the MIT License as a NuGet package (the library is built on top of Microsoft’s ASP.NET). There’s not much information out there yet about the library, but over the next few months I hope to improve that situation so that if you’re interested in using it to build an app you’ll at least have a place to start.
