Everybody needs coffee right? My reports definitely need coffee, so I wrote up
a script for that. If you ever find yourself at a lonely command prompt with node
installed, by all means indulge.
This simply prints a nice ascii art coffee for your enjoyment. You’re welcome.
Hokey smokes kids! Where did all the content go. Since I neglected this site for
so long I figured what better way to get moving again than to completely dump
my existing hosting solution, transfer the old tired WordPress blog to Hexo and
try some new things. Here we go. Perhaps a new theme one of these minutes…
The best and worst part about software development is the variety. If you’re interested in it, there’s a piece of software that does it. In fact, there are probably a dozen different projects. This goes for both the broad application picture as well as the layer below it – All of the myriad libraries that allow us to build modern applications with such great fidelity. Places like GitHub, CodePlex and even Code Project are brilliant resources for community and discovery. Many of us don’t use them enough. As developers we should make it a point to mine these regularly. Browse what’s out there, you never know what gems you might find.
The flip side is that amidst all that variety you can be paralyzed by choices, which is why you need to experiment. There’s a balance between being productive and spending cycles researching and gathering knowledge. I don’t claim to have the right formula. I like shiny things, and I can burn a whole night just reading documentation and playing with this new ORM or that fascinating library over there. All at the expense of the deadline at the end of the week. But we all have to spend some time doing it – storing up our knowledge so we can apply it when the time comes. When you need to answer the question ‘what’s the best tool for the job?’ it’s nice to be able to have enough background to make the right choice.
While I didn’t set out to turn this into a ‘top 10 must have tools from 2012’ kind of post, I did want to share a few tools I’ve used a lot this past year. Some of these projects I’ve applied in production applications (or soon will), others I’m still discovering and learning to use.
By far the library I’ve used the most this year has been MVVM Light. Laurent Bugnion has done a great job of putting together a streamlined, easy to use MVVM framework. It’s available for WPF, Silverlight, Windows Phone and The Applications Formerly Known as Windows Metro Apps. I’ve dabbled with others like Caliburn.Micro and ReactiveUI but haven’t taken them to production. Not because they’re bad tools, just became too familiar with MVVM Light I think.
I ran across Value Injecter earlier this year and it’s been a great tool for mapping objects. I had previously used AutoMapper for these situations, but Value injecter seems to handle things much more dynamically.
Mono.Options/NDesk.Options is a great little package for parsing command line options. It’s by no means new, but incredibly useful for easily giving your command line tools a little extra polish. They have a nice little NuGet package as well.
I’ve started spending a bit of time with ServiceStack. I hope to do a lot more with this project in the near future. They tout “Thoughtfully architected, obscenely fast, thoroughly enjoyable web services for all.” This is a great example of a project that makes what can be a rather tedious process in some technologies just super easy.
Xamarin. Cross platform mobile development in C#. I’m a big proponent of keeping your UI native and fast. I think the approach at Xamarin is the most pragmatic I’ve seen, and I hope I get to participate in a few projects that leverage this in the next year.
So those are just a few examples, and for every one of those I’ve no doubt looked at a few more more that just didn’t suit me or the tasks at hand. But I definitely had to spend some time tinkering to find out. All told they’re part of a greater collection of tools that I can use to develop software faster and better.
So go check out some code this year. Be the squirrel with the most nuts, not the squirrel in the stew.
We use TargetProcess at work to organize and run most of our projects. For the most part it does a nice job, though there are some quirks here and there. Mostly minor, but I kept getting greatly annoyed with the assignable layout in the TimeSheet view. I use this quite a bit to review and transfer time for billing purposes in lieu of a more automated approach. To this day I’m not sure how it comes up with the order of entries. It’s sort of by project… but not really.
I wanted at a way to quickly see what items went with what a common project, so I put together a little userscript to highlight them as such. The image to the left is the general result. See the nice red item in the middle of all the tan ones? Yeah, that’s what I’m talking about… Oh, TP.
Grab the script over on github if you’re the other person interested in this and fiddle away. Highlighting doesn’t automatically refresh when you perform an operation like moving from week to week, so there’s a refresh link up by settings to manually reset it.
By the way, Tampermonkey is a great script manager for chrome, and I used it with great joy to test and edit this thing.
Quick Code Generation from Simple Templates. Templar is all about getting over the ceremony that most code generation/template packages make you suffer through and just getting down to business. Create a template, generate some code, copy paste and go. Save it for later.
I’ve been working on Templar a bit here and there over the past couple months, and the time has come to let it out. I put an early prototype together a couple months back, but a new UI and approach was inspired by some stuff I saw the code52 guys working on. I’ve been sitting on more or less what I wanted to release as a first pass for a few weeks now and finally got down to putting some documentation together.
It’s still a bit raw in UI, missing features and a few bugs here and there, but the basic concepts are solid for now. If you’re interested, check out the help page for more info and the download link. Give me a shout with any critiques.
GitHub recently released a new client for using Git on windows. I’ve pretty much stayed away from git myself, mainly because it’s been a real pain to use on windows. Mercurial works fine for me and quite honestly I think between the two, religious wars aside, it’s six of one half a dozen of the other.
That said I seem to like to abuse myself and try anything new and shiny, so I’ve spent a little time with GitHub for Windows. If nothing else I’ve been finding it interesting to see how developers are applying metro style techniques to more serious applications (e.g. not your regular consumer facing stuff.) It’s a nice little app, I love some of the unique ideas they have in there. Mainly little UI embellishments and the tight integration with github. Clearly a lot of thought was put into making some of the onerous git tasks one-click simple.
I’ll have to spend some more time with it to contrast with Tortoise Hg, my core version control tool of choice. Even though Tortoise Hg is a great tool, the general experience and UI design is not all that great. At the end of the day, if GitHub for Windows is a better tool and there is (mostly) underlying functional parity between the two DVCS systems, it’s worth considering a switch.
SourceGear’s DiffMerge appears to be a nice alternative to kdiff3. It’s interface is moderately intuitive, which sets it apart from almost every other merge tool I’ve ever used. It’s free, and worth spending some time to get acquainted with.
For Mercurial users, their wiki has a page on how to set it up as your external diff viewer.
I was catching up on some Hanselminutes the other day, in particular show #294 Developing a mobile app for iPhone, Windows Phone 7 and Android with Toran Billups caught my attention. I’ve done development on all three platforms so I had fun comparing and contrasting his experiences, and I agree with a lot of Toran’s points.
Since Android is my the target of my current project I thought I’d write up a quick how-to for getting your IDE all set up for development. I agree that it is not as straightforward as the iPhone/windows phone experiences might be. But it can be a lot less painful these days than it use to be. So here’s my quick guide to getting up and running quickly.
This guide targets Eclipse. It’s really not that scary. If you’re not familiar with Eclipse, like any new tool, once you get use to how it works I think you’ll find it to be a competent environment. Maybe it’s not the most beautiful or elegant piece of software, but it certainly gets the job done.
Get the Basics First things first, you need the Java Development Kit and Eclipse itself. Now you might be tempted to head over to Oracle’s sites for the JDK. I urge you not to, they clearly didn’t design it for human interaction or optimize for usability. Instead, head on over to http://ninite.com and install from there. It’s quick and easy, and while you’re at it you may want to pick up some of the other handy utilities they have. Select your tools, click the big Get Installer button and let it work for you.
Install the ADT Plugin
Fire up eclipse (by default it gets installed in C:eclipse. yeah, it’s not perfect) and prepare to install the Android Developer Tools plugin. This provides the necessary extensions within Eclipse for android development. If you want all the in depth details check out the ADT page in the sdk documentation. Here’s the quick version. In the Eclipse menu, select Help -> Install New Software… then Click the Add… button on the far right to add a new repository. The resulting dialog requires two fields a name and location. For the name use ADT, or whatever suits you. The location is: https://dl-ssl.google.com/android/eclipse/
Click OK and once the information loads, hit Select All to select all the options and Next> to start the install process. There are a couple clicks after that to accept license agreements and unsigned content. Confirm those and installation should proceed.
Once complete Eclipse will ask to restart. Let it do so.
Configure the SDK
After you restart Eclipse a dialog will pop up prompting you to configure the Android SDK. The SDKs allow you to develop against various Android OS versions. At the very least you’ll need one. Install the latest, add 2.1 if it suits you. You can always go back and add more as we’ll see later.
Click next, after a little downloading you’ll be asked to accept some more license agreements. Accept and continue with the sdk downloads.
Start Developing
At this point you’ve got all the basics you need to start developing for the Android platform. Hopefully you have a real life hardware device at hand to test with. The Emulator is usable for limited testing, but very slow. And by slow, I mean f*cking slow.
At this point you’re probably ready for Hello World. There are a few more steps to it, the documentation here covers that in a straightforward manner.
After that, you might want to examine some of the sample projects. You’ll need to add samples via the Android SDK Manager. The ADT plugin added a toolbar item for it (look for the green android), but you can also get to it via the Window Menu. (It’s also worth noting that the AVD Manager is the tool you’ll use for creating emulators, and can be reached from this menu as well).
The SDK Manager basically gives you a tree view of the different SDKs and options within them. Look for the version you want to target and select the Samples for SDK Item and click install.
Once that is done you can choose File->New->Project… to open the New Project Wizard. Open the Android Folder and Select Android Sample Project. Click Next, select your SDK target, Next, then choose a sample to create within your workspace. This page lists many of the samples with links to some details on their function.
Digging Deeper If you are unfamiliar with Android development, the steps above will get you a platform to start with, but you’ll still have a lot of learning ahead. There is a wealth of information on the Android Developer site. You can read further on the SDK and more details about installing and configuring it here.
While the process is certainly more involved than it should be, it’s more lengthy than difficult. I’ve definitely suffered through worse. Over the past year or two the tools and process have improved, so here’s to hoping Google is focusing on continuing to make the process faster and simpler in the future.
Just like my last ‘review’ this is un-review like. That’s just how I roll with these things.
So, CSS: The Missing Manual. I think the last time I read a book on CSS was in 2001? My chief competency and love for development has never been (at least by choice) rooted in the web. Certainly making a rich, interactive, incredibly beautiful UX for the web has never been something I’ve achieved with resounding success. That said I’ve written plenty of usable web applications and I’m plenty comfortable whipping up the styles and markup needed to do it.
So why crack open a slightly dated and very introductory CSS book? Well, making web pages really elegant has always been a little frustrating for me. The inner workings of why layout happens the way it does in a web browser can sometimes seem like a black art. So my assumption was that maybe it was time to get back to basics and take a look at a reference that assumes nothing. I wanted to parse through all the “yeah, I get that” moments and pick up as many of the fine details that I may have either known and forgotten, or just plain missed from the get go.
I don’t think that’s an uncommon experience, especially in the software industry. We operate on multi-faceted projects that can span three, four, (or more ???) technologies at a time. Then after a few months we move on to something else and do it again. It’s impossible to be an expert at more than a couple languages and frameworks and understand the minutia of each. It’s probably not reasonable to be a true expert at more than one. So there are always holes to fill here and there, and sometimes it takes a while to get to filling them. So that’s the long answer to why an intro CSS book. It’s one of the techs I know I could use a little more work on at a fundamental level. Better late than never. I encourage you to think about a few places you’d like to hone your skills, take some time out and fill in what’s missing.
As for the book, it was a solid read. It’s a bit dated, (August 2009) and that shows. As expected there was a lot of content that I already knew. There were quite a few discussions of dealing with rendering problems in certain older browsers (yeah, that one) that I glossed over. But in between all that I picked up on the minutia that I was looking for. There are a lot good nuggets of information that really cleared things up, especially where layout is concerned.
In particular, I found the code examples to be highly useful. If you’re interested, they are available for download on the O’Reilly site if you’re in the mood to browse. The web is always nice for being able to see how things were done. These examples are particularly useful because they demonstrate some core concepts without any other cruft.
Having popped this book off the stack I feel just a tad better about my relationship with CSS, but a whole lot better about filling in a nagging gap that’s been there for a long time. Off to the next one…
Last week I was having a discussion with a coworker during which I said some rude things about the frustrations of Making Beautiful Things in the web. I was rightfully chastised for probably not putting a concerted effort into understanding css under the hood. At least never to the depth of mastery. Did I mention most of my hateful remarks were made in the general direction of CSS? Come on, like you’ve never?
I thought on it a bit later and figured he was right. I’ve spent the last couple years with my nose in XAML and feeling pretty good about it. Perhaps it is time to put some more focus back on the real web side of things. It so happened this weekend I had the rare opportunity to play bachelor for one and a half days, so I decided to be constructive and put that time toward reading a few tech books. I thought I’d share my general opinions.
But before I dug into CSS I thought I’d warm up and make sure I had a firm grasp on what’s new in the realm of HTML5. So I chose Introducing HTML 5 by Bruce Lawson and Remy Sharp. When I picked this up I was hoping for a relatively quick read, something to get a distilled overview of what’s cooking in the HTML landscape of late. Turns out this book read exactly like I had hoped. Man, that almost never happens! The writing style is, front to back, concise and clear. They got to the point, gave some good descriptions, and moved on before I could get bored.
It starts out with a good overview of new tags, general structure of html5 documents, why the spec has been created and how to go piecing together all these new elements in a way that jives with the spec. After the first couple chapters I really felt like I had a good feeling for the direction and reasoning behind html5.
The rest of the chapters were each focused on a specific technology. I won’t go into any gory details, but here’s a quick list:
There’s not necessarily ton there that you can’t grok from doing a little googling about each topic, but again, it was nice to have it all neatly organized and made for a good fast read. There’s just enough in each chapter to get you familiarized with all the bits and get you started working with them. I think the Authors did a great job, and I’d very much recommend it as a solid intro read.
As for CSS, well, that review is coming…
But before I go, they mentioned a few good resources in the book that are worth sharing. Here are a couple of note: