This interview with Alex Payne of Twitter is an interesting read. Question number 2 is the most striking:
“All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.”
While I have nothing but admiration for RoR I can’t help but wonder why more Web 2.0 startups aren’t using .NET and the Castle stack. You get lots of the nifty features like ActiveRecord, testable MVC, JavaScript generation, etc, etc. There’s out of the box support for multiple databases, and with the recent release of Hibernate Shards it would be possible to port database partitioning. Plus you get it all with the scalability and performance offered by the .NET runtime:
Image Credit: Jeff Atwood
I’m sure Rails will mature to the point where these discussions are moot. Until then, however, Castle can give you the RoR sexiness without always resorting to the “throw more hardware at it” approach to scalability.
In the past week, there’s been a significant amount of blog chatter around the lack of documentation for Castle. There is information out there, it just doesn’t have a central knowledgebase. That information resides in blog posts on committer sites or posts to the developer’s mailing list. In an effort to make this documentation more discoverable I’m going to attempt a weekly post summarizing the new and noteworthy changes to the framework with links to relevant documentation.
MonoRail
Contrib: MonoRail Code Generator
Components
- Set Validator: Validates a single property against a set of possible string or enum values. The enum support is nice because you don’t have to hard code the strings in a regex.
UPDATE: Eleutian has released the source for their code generator and it is now an official Castle Contrib project, so I have removed this one. You can access the sources here.
Last week I came across
this post by Jacob at Eleutian. They discuss a process by which they parse their
MonoRail controllers and views during a pre-build step. It was an excellent post that really got me interested in having something like this for my MonoRail applications. There was no source code with the post, but it was detailed enough for me to quickly whip up my own implementation. (Thanks for saving me all that thinking!)
I’m not sure how close this is to Elutian’s version, but it’s working well for a not-much-thought-few-hours-of-coding implementation. Here is the code to do with as you wish. I make no guarantees that it works perfectly for anything other than my sites. That said, it works very well for those.
There are a few differences with my implementation.
- I named the top-level element Root instead of Site. Site kept opening Resharper’s import namespace tooltip.
- I generate a no parameter version of all actions, regardless of whether one is defined on the controllers. This allows me to easily access the Url property for creating form actions without needing to remember appropriate parameters.
- I added a MailViews node to the root level so that you can render email messages using the same strong-typed syntax.
There are also some things I still would like to implement.
- Adding all referenced assemblies as using statements at the top of auto-generated classes. Right now, the generator extracts the entire params list from actions as a single string and re-uses it in the ControllerActionReference properties. This means that if you don’t specify a fully-qualified type-name for non-primitive parameters the code will not compile.
- Adding another Root level property for the Layouts. I’m considering using an enum because then they can be used in the Layout attributes.
To use it in your project, just build the Common.Build project and put it in a folder accessible to your web project. Then edit your web project’s build file and add a UsingTask node under the Project node:
<UsingTask AssemblyFile="..\extbin\Common.Build.dll" TaskName="Common.Build.GenerateMonoRailStubsTask" />
Then, add a BeforeBuild target right before the ProjectExtensions node:
<Target Name="BeforeBuild">
<GenerateMonoRailStubsTask PathToOutput="AutoGenerated" NameSpace="MyProject.Web.Controllers" ViewExtension="brail">
</GenerateMonoRailStubsTask>
</Target>
The PathToOutput property is the folder name where the generated files should go. That file must exist or the build will fail. The NameSpace is the namespace that you would like your controller generated in. The ViewExtension is the extension of your view files.
Feel free to let me know about any bug fixes or features that might be useful!
Great programmers have an uncanny knack for overcomplicating things. In my career I’ve started countless hobby applications only to stop 30% in because I’ve gotten mired in nitty-gritty details and came down with a horrible case of frameworkitis. Part of the problem is that writing frameworks is challenging, fulfilling work. However, it often takes longer to write the framework than the application itself. So after 2 months of writing code and little application functionality to show for it the project peters out and dies. Alex’s post about this sums the problem nicely.
It really is very hard trying to stay away from creating libraries, thinking about future uses and what extra things I can put in that might used in the future. Simply creating code that works and only does what I need it to really helps to move things ahead.
Part of the reason for Ruby on Rails’ quick adoption is that it provides a solid framework for development that has enough features to keep us framework quasi-developers happy while staying out of the way enough to make the framework work for the developer instead of against them (CSLA anyone?). It’s slick and sexy. It’s the iPod of development frameworks.
So why should the Ruby developers be the only ones having all the fun? What if you are a .NET/Mono developer and you want to achieve the same levels of web development nirvana? I highly recommend you check out the Castle Project�and its MonoRail and ActiveRecord projects. It’s Ruby on Rails for that PC guy in the Apple ads.
Ignoring the fact that Castle’s site isn’t as sexy as RoR’s, the speed and sheer fun of developing a MonoRail/ActiveRecord project is unlike any I’ve experienced with .NET. (I don’t want this blog to get too tech-y, but enterprise developers will absolutely adore Windsor as well.) Plus, their are brilliant minds behind the code, it’s all open source and the community is thriving. Oh, and if you are afraid of Beta software (you shouldn’t be - others aren’t) version 1 is right around the corner.
If you’re one of the enterprise developers out there making web apps in .NET I suggest you get a taste of Castle. It’s a heck of a lot more fun than slimming down ViewState. If you are a product manager of .NET web apps and want your programmers to like you more, tell them you completely agree.
I regularly download and experiment with new software tools. Just this week I’ve experimented with Cozi, New York Times Reader, Touchstone and the latest beta of Windows Live Writer. Most of these apps have an installed life-span of three days. I install them, play with them for a bit, shut them down and see if I get the urge to use them again. If I find myself using a program more than a few times a week it’s generally regarded as a keeper.* That’s not to say that the applications hitting the recycle bin are somehow deficient. I just like to keep an eye on software trends and install a lot of applications meant to solve problems that I don’t have.
With all of this software testing I see an awful lot of installers. Err… maybe I should say a lot of awful installers. It amazes me that we are in 2006 and a user’s first interaction with our software has the least amount of thought given to it. Primacy and recency play a large part in forming a user’s first software impressions just as they do with other media. Try and keep these things in mind the next time you find yourself in the unenviable position of installer development.
- Keep it simple
Installshield and the Visual Studio installer have horrible habits of putting useless screens in between steps. If the step isn’t imperative, drop it!
- But not too simple
Don’t assume all users want their program in the Program Files folder and want 14 shortcuts littered throughout their system. Trust me, users aren’t dumb. They will find be able to find the application they just installed. NASCAR branding of the Desktop helps no one.
- Test the hell out of it
QA efforts often gloss over the installer. Don’t fall victim to this trap. Test your installer as thoroughly as the rest of your application. This goes for usability testing too. There’s no reason your installer should be three times as complicated as the rest of the program.
- Oh, and don’t forget the uninstaller
Your mother taught you to pick up after yourself. Heed her advice and make sure your uninstall process does the same thing. If you put something in the registry, remove it on your way out. If you created some files after install (that won’t get cleaned up automatically by the uninstaller) kill those too. While you won’t get a medal of valor for your efforts you will avoid irritable bloggers complaining about your carelessness.
* In case you are curious, of this batch all but Cozi are still installed. Cozi doesn’t hit my demographic but I was really curious to see the interface. The Times Reader is pretty impressive and will probably lead to an article about WPF in the future ? but it’s still beta and has some rough edges. I also don’t generally read the Times. Touchstone is an application I really want to sink my teeth in to but I’m still waiting on an invite code. Finally, Windows Live Writer is working exceptionally well for me (I’m using it right now). So far I highly recommend it.
When designing our last product we had a tough time deciding whether it should be a smart-client desktop application or a browser-based web application. Prior versions of the program were desktop apps with a component for online synchronization. However, the past few years had seen a few web-only competitors spring up in the marketplace. It was not an easy decision to make. For a variety of reasons we decided to go the desktop application route. Some applications are just not meant to run in a web browser and there were too many critical features we couldn’t pull off properly.
With all the buzz around Web 2.0 and the push for more and more desktop software to run in a web browser you can’t help but wonder if the mass-market desktop application is an endangered species. The Museum of Modern Betas now catalogs over 1,000 active beta web apps.
Recently, however, I’ve been seeing some evidence that desktop applications aren’t dying. They appear to be evolving into a hybrid offering the network capabilities of a web-application combined with the flexible GUI toolset offered by desktop apps. Cozi, The New York Times Reader and Delicious Library would all work on the web but the experience outside of a browser is so much more compelling. I tell you we’re about to see the return of desktop applications. It may take a few creative successes to get the ball rolling, but I feel that it’s inevitable. All that’s missing is a spiffy logo.
I was reading through the new Office 2007 UI Style Guide and found the following UI Design Tenet:
No surprises. Task panes or dialogs do not appear automatically on document open. Only user actions should open and close task panes or dialogs. Ideally, all task panes are opened using a button in the Ribbon.
Many developers and product managers fall in to the habit of forcing information on users when something is amiss. Office was especially fond of these modal dialog interruptions.
The problem with these alerts is that they are obtrusive and obstructive. Many users don’t care that their document has macros in it. Many more don’t even know what a macro is. So in the majority of cases it is a distraction that prevents people from getting their work done.
Abiding by their new UI Style Guide, Excel 2007 has a more civil approach to the impending doom of macros. No dialog box is shown when you open the document. Instead the macros are disabled automatically (the default action from the previous dialog) and a notification toolbar is presented allowing you to enable/disable them at your will.
This is the way intelligent software is designed. The user’s concerns are considered and the application works with them instead of against them. Any action that interrupts users’ from their intended goal is one that should be avoided. Remember this next time you find yourself about to use the word modal in a PRD.
An article posted on Adaptive Path’s web site from back in 2004 has started making the rounds on digg, dzone and soon my entire OPML file. The article is dolefully titled “90% of All Usability Testing is Useless.” Go ahead and read the article. I’ll wait.
All done? This article really struck a chord with me. My number one peeve is the author’s blanket thesis that 90% of all usability testing is useless. Maybe 90% of the usability testing methods that Becker is implementing are producing invalid results. He might want to consider changing his methods before throwing the baby out with the bath water.
There’s more to usability testing than just recording users and asking them to perform tasks. Unfortunately, the places Becker feels usability testing breaks down for the web are just as big pitfalls for other applications. Poorly implemented tabs are poorly implemented tabs, regardless of the presentation layer.
The article’s second complaint it that usability testing shouldn’t be done by consultants. I completely agree that if the product is essential to your business there are only short-term cost savings involved with outsourcing pieces of it. Though neither of us has research to assert our claims, I’d be willing to bet my lunch that 90% of usability testing is not done by consultants (they could be so lucky!). In fact, I doubt that 90% of software projects get any usability testing at all. Consultants or not, as a user of software I’d rather any usability testing done!
Maybe it’s me, but I’ve always read Adaptive Path essays with a pinch of skepticism. They strike me as a bit too much marketing meant to instill clients with confidence in their work. I just wish they had a bit more editorial oversight. (or allowed comments!)
Lately there has been a lot of discussion about finding top software development talent. Coincidentally I just attended a class on recruiting and selection given by Dr. Kyle Lewis. It’s amazing, when you are presented with the actual research statistics, how much of a failure current recruiting tactics are. Check out the reliability and validity results of typical selection methods.
Based on this, there is no silver bullet to talent recruiting. In fact, most typical hiring methods are pretty limited in their utility. We can only hope to stack the odds in our favor by implementing a variety of selection methods and doing everything in our power to raise the reliability and validity of typically futile techniques. The most commonly used selection methods are interviewing, references and work samples. Let me attempt to explain why these methods are generally flawed and touch on some things to consider when you employ them.
- Interviews - You might exclaim: ?Why are these unreliable and invalid?! I can?t imagine hiring a candidate without a rigorous interview process!? And rightly so. However, most interviewers that haven’t been taught otherwise (myself included!) don’t know the first thing about conducting a good interview. We “chat” with candidates and ask a few probing questions to see what they are interested in or have experience with. It?s usually pretty ad-hoc and if you overlaid the content from an interview with candidate A over the content learned in an interview with candidate B there would be little correlation. This is where those low reliability and validity scores come from.
If you want to start deriving real value from your interviews they need structure. The same series of questions should be asked of all candidates. Each questions should have previously decided upon “good” and “bad” answers that the candidate can be measured against. The questions should also be tied to the position the candidate is applying for. Make sure you?ve covered your bases with the questions as well: ask enough to determine knowledge, skills, traits and behaviors. If you don’t conduct interviews with more objective methods you?re really doing yourself a disservice.
References - This one is pretty obvious. References just don’t hold much water. For one thing, most companies won’t give references outside of clarifying name, rank and serial number. There are too many potential legal ramifications involved. So that only leaves personal references. Let’s face it, what personal reference isn’t going to give glowing reviews? You?re incredibly unlikely to get any overwhelming information from a reference.
Work Samples - Of the methods mentioned, this is the only one that is both reliable and valid. However, don’t assume you can just collect work samples and base the majority of your decision on this. Due to non-disclosure contracts getting real world samples is rarely possible. Spare-time project samples should also be considered with a grain of salt. Documentation and longevity are hardly the goals of this work. It’s generally not an apples-to-apples comparison to what they will be doing on a daily basis. Plus, the samples are very job and task specific. A work sample showing how well a candidate can architect a CRUD application is not indicative of their skill to do 3D engine programming. That said, if you can get representative work samples from a candidate and they live up to your expectations, you’ve got some strong evidence at your disposal.
Regardless of how you go about your interviewing, try and keep a few of these thoughts in mind. Just taking a hard look at how you interview, and making a point of trying to improve this skill set will go a long way. No one wants to end up with “that employee.”
Well, here’s the first post. I guess we have to start somewhere so this is where we start. Look forward to some real content shortly. Right now I’ve got to twiddle a few more knobs and make sure everything’s working.