I’m now on devlicio.us!

December 29th, 2008

I have been invited to becoome a blogger on devlicio.us, and am excited to be joining them! I plan to do all future tech posts on devlicio.us, so please check there for new posts, and while you’re there, take a look at the what my talented co-bloggers over there have to say.

Thanks for reading,


On Password Security

December 18th, 2008

If you are storing user-entered passwords in your system, it’s imperative to keep those passwords as secure as possible.  With all the systems that require passwords, users often end up reusing one or two passwords for many sites.  As users also often reuse usernames (or use a single email for all sites) that means if you have user information for logging in on one site, you then have information for logging in to many sites as  that user.  Example: even if you’re just a site where users can log in and create silly little drawings, if a user can enter their own password on your site, there’s a good chance you can use that information to get into that user’s online email, or possibly even their banking sites.  So, good security rules would dictate treating that password as sensitive personal data, even if it’s not sensitive in your context.  In face, I think this might even apply if your system assigns the user a password.  If you are forcing the user to accept a new password, you might expect that once they have memorized that password they might start reusing THAT password elsewhere.  (if anything this sort of reuse is probably MORE likely with the non word, mixed case, mixed letter and number high-security passwords, since people can remember very few of those and a lot of sites want that kind of thing)

So, what to do to treat passwords well? One-way hash it-nothing less is acceptable.  You really don’t want anybody to ever be able to look at that password again.. remember, that password is black-hat hacker’s gold.  If the user forgets their password, they can reset it.

Some organizations have a policy of a clear-text password for “good customer service” (if the user calls to say they forgot their password,  the person answering the call can give them their password again)  this is a REALLY bad idea-it could be someone impersonating the user, and even if it’s not, the person answering the phone is one more person unnecessarily exposed to that password.  So, encrypt the password, and rethink the customer service angle.  If a customer calls asking for their password, say something like “To protect your privacy and identity  we do not store your password in a way that is retrievable by me or anyone else, so I cannot tell you your old password.  However, I can reset your password for you, and you should receive the information to reset your password in an email.  Please do not tell me your new password; I do not need to know it.”

Another argument sometimes used to store passwords in clear-text or a reversible encryption is so that administrators look up passwords so they can can log in to the system as that user to debug sepecific user-reported issues.  While verifying issues at this level is a good idea, allowing admins to access user passwords is a bad idea, as they should NOT see these passwords, and it requires passwords to be stored in a viewable format.  Asking users for passwords when issues appear is not ok either-the admin should not need any access to the passwords at all.  However, theses admins have a legitimate need-the right solution is to build into applications an impersonation system.  From an admin area, an administrator would have a backdoor into the system that allows them to access the application authenticated as a particular user-no literal logging in as that user required, so no password needed.

Psychology of a “pretty good” programmer

December 9th, 2008

(This post refers to no single person or job, but is describing a personality type I and others have encountered)

Just to get this out of the way, a really bad programmer is easy to spot-a truly bad programmer can be a perfect storm of inability to understand and unwillingness to try, a lack of caring or opinions, poor innate troubleshooting skills, and general lack of intelligence. Such people do make a living as programmers (which is a separate, interesting issue) , but they’re not who I’m addressing today.

More interesting to me than the truly awful programmers are the pretty good ones. They crank out code that works, they’re good troubleshooters, and they are generally reliable. Some of these people are senior. They do what they do pretty well. They accomplish things, deliver sizable projects. They focus on risk that is near-term… a guaranteed return is the way to go, every time-“this is what I know, and that’s what I’ll do”. As for how current work will be to deal with in a year or two from now if things drastically change? That’s another day.

There are problems with this approach though…sometimes improvements initially appear as risks. For example, writing unit tests (upfront time not spent on “production code”), writing in a concerns-separated fashion(moving things around is stirring things up for no reason), or exploring a new technology or methodology(time that could slow down the project, or even lost entirely if the new tech doesn’t pan out). Finishing the task is key to this mindset, and keeping an application useful, understandable, and maintainable is, frankly a lot of “busywork”. Problem is, the long-term success of the project can hinge on those factors.

Well… I’m trying to understand the mindset. As I said, the people I’m talking about are smart, capable people, so it’s not a simple case of lack of ability to think it through- there’s more to this story. It’s easy to imagine non-coding managers taking this approach, but why competent developers?

NHibernate and Entity Framework Battle it Out in the Real World

December 3rd, 2008

The scene: a company division with no prior in-house experience using any ORM of any kind. A really, really legacy database-the kind with many composite keys, fields with mystery names, uneven use of enforced keys, etc. Currently, access done through ADO teamed with stored procs containing dynamic sql involving string concatenations (horrible for speed, security and my sanity among other things)

The mission? Given the constraint of not being able to change the underlying database aside from adding on some views, build a clean, modern app to eventually replace a legacy app that’s creating significant maintenance pain.

Early on, the team decided to lean toward use of an ORM-several team members had had positive past experience with ORMs, and it seems to be the way the industry was headed. However, that still left a choice-which ORM? The choice was quickly whittled down to NHibernate and Entity Framework. We ran two small parallel spikes, and ended up with a few thoughts about working with each:

First, we picked 3 or 4 tables to map to with both technologies, wrote up some simple classes, and then set about setting up persistence through an ORM-agnostic repository via both mappers.

NHibernate’s mapping files are relatively easy to read, but there’s no GUI to write them for you. It lets you write your classes and then work on your mappings separately afterward. The classes are clean POCO. NHibernate requires some code modification (virtual/overridable) and works better with some child-to-parent mappings that don’t seem like they should need to be there, but generally, modifications needed are minor. Repository is straightforward, and there’s lots of helper code online to do the legwork. Not tested, but it’s got sophisticated caching built-in.

Entity Framework was from Microsoft and had a GUI. The classes were autogenerated in one direction, from the database to the GUI to the classes… non-mapped properties caused errors-the proper place to put such artifacts was in a separate partial class file for the class-looking at the autogenned class, it was VERY clear you were not supposed to touch it, and probably not supposed to look at it.. this left the class spread across your partial and the gui. In addition, there were tight EF dependencies on these domain objects. Not to mention, after working with the GUI, I got the strong feeling that the GUI would not be able to handle complex scenarios, leaving us working with the raw verbose and complicated (and not really designed to be hand-edited) mapping xml. A pre-written class doesn’t seem to be able to be used easily-at least, we were exploring the usefullness of the gui, which left us to recreating the pre-written classes via the gui. It wasn’t clear if it was possible to mark a class as read-only, and code wouldn’t even compile if fields required in the DB were not mapped. Repository pattern was a bit more work-less guidance online… not sure if that’s because EF is so incredibly new, or because EF users are generally not as familiar with this pattern… in any case, it was a bit more tweaking to get things working through a moderately ORM-agnostic repository interface. No seamless caching yet-that’s slated for v2.

Non-technical factors:

NHibernate was an industry leader, was fairly mature, had been around a few years (and a few MORE years if you counted Hibernate) and a team member (me) had experience using it in a high-profile production environment. No paid support available to speak of (not counting unknown companies here) but a truly responsive, helpful community with a product that is in active development… but then, NO backing company (not even Red Hat these days) … potential of giving fly-by-night appearance to non-techies as a result.

Entity Framework is brand-spanking new. If it were a car, it might still have temporary plates! It’s a 1.0 Microsoft product, with all that implies. Next version slated for 2010. If anything happens, Microsoft’s there for help, or (worst case) to receive a lawsuit. And it’s always easy to justify a Microsoft product.

It was a tough debate, but we ended up going with Entity Framework. Despite agreeing that NHibernate was the better technical solution, the team eventually concluded that having a backing company was extremely valuable for the organization, and that the GUI would be helpful for people coming into the project that were unfamiliar with ORMs.

The next morning, we set about doing some preliminary mapping. (ignore the DDD-related problems with this workflow for now, please)

  • Yeah, that GUI is looking even more inadequate…
  • Generated class and mapping files are THOUSANDS of lines long-this really sucks what with the inadequate GUI
  • IT was REALLY easy to screw up the EF stuff so the gui couldn’t load-easiest way to deal was to redo the whole thing-I think we did that about 5 times that morning.
  • It didn’t seem to deal well with the messy legacy db. Due to the db-first nature of EF, the messiness was going to leak through into our classes…
  • We were going to be on the hook to support this thing-were we ready to do that?

By noon, we’d decided to switch to NHibernate. Cleaner code, clearer classes, and a team member with experience suddenly became a whole lot more compelling.

Working through those mappings has been a valuable, revealing process too. (more on that in a later post)

(Corrected: Thanks to Scott Bellware for the heads-up that even if you’re working on a VB project, it’s still POCO and not POVO, since the C stands for CLR, not C#.)

Broken Windows

November 27th, 2008

We all know the broken windows idea, but Jan did a nice, clear write-up of it. such a simple idea, so hard to fight in the day-to-day.

Professional Under Pressure

KaizenConf goals

November 4th, 2008

So, I’ve got some rough goals for myself from Kaizenconf… (in no particular order)

  • I’m going to make really learning the MVC framework a higher priority so our team here can have enough info to consider whether to move the team that way eventually… I mean, of course we will, but I’ve got to have enough ammo to ensure that happens 🙂  Anyway, eventually, do some sort of team presentation would follow, like for the IoC stuff below.
  • I’m going to read more of that DDD book that I’ve only gotten about 3 chapters through.  I know, it’s terrible I haven’t read more, but I’ve gotten through a bunch of the Ubiquitous Language stuff, which has already been helpful.  I have the feeling more useful content follows.
  • I’m going to be putting together some sort of presentation(s) for my team about IoC/DI with mocking, and maybe NHibernate to do my part to equalize team knowledge.   My team here isn’t against some of these “new” ideas/change, but they’re not neccessarily sold on them either, so I’m going to work on making sure I can really prove out why.  This is actually not a bad thing at all for me, making sure I can justify stuff instead of presenting things from a gee-whiz perspective will definitely make for a better sell. Yes, , I know there’s a lot of material out there, but I should probably do a lot of this legwork myself so I’m best prepared.  Talking for an hour doesn’t come naturally to me, so I’ll have to know things that much better.
  • My list of books to read has gotten larger (see this list for a start)
  • I’ve got Prism, MEF, and Mass Transit as message-oriented things to look into that could be useful on my current project since we’ve got a setup that suggests a SOA approach.
  • We’re very early into doing Scrum on our team here and I think we need the discipline it’s got, and really want to prove this out before going in a totally different direction, but I’m going to read up more on Lean/Kanban some more, (offhand, Scrum-Ban may prove helpful), and see if there are tweaks that can be borrowed from those ideas that would improve our current experience.

Future posts will hopefully outline my actually doing the stuff above.  Additionally, some specific thoughts on the conference itself to follow… at some point.

At KaizenConf

October 30th, 2008

This is a lot of fun.  I’m definitely learning, meeting lots of people who were previously only blog photos/email addresses to me, and I’m having a great time too.  Also, there’s some VB.NET – converted stuff I’ve been alerted I should post.  Woohoo, contributing back in my own tiny way.  Consider this my reminder to myself to do that. Also, to start twittering.  It’s clear twittering has gotten beyond the inane “I am eating Lucky Charms for breakfast-crunchy” type stuff that I didn’t care about to also being a useful networking/reference tool…. and as I mentioned in conversation tonight, I’m getting that feeling like I felt with Facebook a few years ago-like the crowd was moving on and if I wanted to continue to “exist”, I should go too.   Anyway, in the interests of full disclosure, I  should probably state here that I had Frosted Flakes for breakfast, not Lucky Charms.

Off to sleep, there’ll be a real post on the event in the next few days.

DDD and Aggregates

September 26th, 2008

I started reading Eric Evans’ book Domain Driven Design.  (Seemed like one of those foundation books you have to have read if you want to be a certain type of developer)  I decided to give it a go after I got about halfway through the “Domain Driven Design Quickly” pdf – it seemed interesting enough that I wanted to have a go at the real thing.

Anyway, one thing it talks about is Aggregates… basically, a tree of dependent objects that don’t mean anything alone-like line items to an order, as opposed to a customer that is an entity that has meaning by itself.  I guess I haven’t explored things enough yet, but I’m thinking abouton something I’m looking at-I’ve got something like an order, and something like a line item.  There should be no separate repository for the line item.  However, in practice you may need to deal with the line item by itself, for instance the “edit the line item” screen on a website.  In a desktop app, you’d pull out the line item w/ roder, keep that around, and then save when the editing’s done.  However with this web scenatio, you come back from the editing screen and have… some IDs.  Sure, you may have selected the line item from the order… but as the web is stateless, you don’t have your order and order item all ready to update, you’ve got to rebuild that and apply the changes before a saving.  So, you’d pull out that line item from the repository *via the ID*. Or if you prefer, pull out the order via its ID, then iterate through its line items and pick out the relevant line item from the line item collection by ID.. also messy-you preserve the aggregate idea since there’s now no repository for  line items, but you’ve got iteration, and worse, a domain-level usage of picking by ID, which feels like bleed-through.  But you really need the order and the order item, so you can make your changes and then save.  Uh, I guess you can put them in your session, but that just seems even worse than either of the above options due to unreliability.  But maybe that’s me being pessemistic.  anyway, is there a clean way do deal with this?  Or at least a generally agreed-upon lesser evil?

Funny, apropos comic

September 23rd, 2008

Everything Is Going Just fine, thank you

KaizenConf, here I come!

September 16th, 2008

Woohoo! Just came back from lunch and my invite was waiting in my email!  I’m going to KaizenConf!  See you all in Austin!

List of Invitees
Interestingly, the list seems to be in first-name alpha order, so at the moment, I’m #1 on the list.  Wild.