• 2011-05-30
    • design-patterns
    • software
    • dry

    Keeping Your Validations Dry

    Why we repeat validations and how we can do it less.

    Any programmer worth his salt hates repeating code. That’s why we find situations that force us to repeat ourselves grating. Today, Web Development Sucks begrudges the pains of having to repeat validations both client- and server-side.

    Sadly, this is not a web issue but a software issue. For several years now I’ve been developing a client-server WinForms application that deals with the same greivous pain. See, all programmers that care about a good user experience will also care about performance. And so to reduce roundtrips, we repeat some logic on the client.

    If we unreservedly trusted the client, couldn’t we simply shift our backend validations to the frontend? I don’t think so. The backend must assume that anything the client sends is untrustworthy. Malicious threats aside, it’s a matter of maintaining data integrity and probably the best place to do that is as close to the database as we can get—in fact, right at the database. The database is, after all, the last line of defense. If our data gets compromised so does our business. Thus, we’ve learned not to rely on validations we can’t guarantee.

    Where does this leave us? We enforce our rules on our trusty server. But since we care about user experience, that leaves us where, again? With repeating logic on the client.

    I’ve pondered this repeatedly as project after project we’ve dealt with at least duplicating some validations. Recently, I’ve been working on a personal project. Same issue. I thought I might try again to address it. This lead me to one possibly good solution: metarules.

    1. Represent your validations (rules) using metadata.
    2. Write server- and client-side interpreters that enforce them.

    In this way, the repetitious bit is in writing the interpreters.

    Take the following model:

    class Person < ActiveRecord::Base
  validates_presence_of :first_name
end

    We code our validations right on the model. But what if we didn’t? What if that validation was stored as metadata in the database? Let’s forget for the moment that databases already support this by allowing us to mark fields not nullable. What we want is a more universal approach. What if we persisted our validations as data (in the database or elsewhere) and any given tier was equipped to abide by that data?

    TYPE      ATTRIBUTE       RULE
--------  --------------  -----------------------------
person    first_name      required

    The server-side model could then interpret and enforce those metarules. The same thing could happen client side just by outputting our rules as data—not code—to the client:

    {
  "attribute_rules": [{
    "type": "person",
    "attribute": "first_name",
    "rule": "required"
  }]
}

    What we’ve done is traded hardcoded logic for interpretive data. We enforce our rules on both the front and back ends in a DRY manner. This allows the client to avoid needless roundtrips to the server. It allows the server to choke out bad data if the client rules are circumvented. Now to universally effect validations we’re left to maintain our metadata and our interpreters.

    Any sort of rule can be universally enforced so long as we provide:

    1. Rules represented as data
    2. Interpreters 1 that understand and enforce them

    I dunno but it seems to me that a schemaless database (like MongoDB) would be a perfect repository for these kinds of rules. Anyway, as I continue to work through this, I’m sure I’ll learn some things and have more to say.

    I haven’t found any good articles addressing this problem. If you have, please provide links. I’d love to learn what others are doing. I’d be especially gratified to see well-used design patterns make this less an issue, especially as I too weary of repeating validations. I love DRY code and architectures. I always fret over having to maintain the same logic twice. My gut tells me I’m inviting trouble.

    1. I see no reason why you couldn’t use a compiler instead of an interpreter.

    permalink

    • 2011-05-22
    • ruby
    • startups
    • boardgames
    • originality

    You Can Always Be Original

    I can’t tell you how many things I invented that already were. I’m a programmer by profession any by hobby so I do a lot of just-for-fun coding projects. In some of them, I just toy with ideas. Others I develop for practical use.

    I’ve been doing Ruby and Rails for about 5 years now and it has given me a renewed passion for creating things. Part of the story for how I landed in Rails starts back in the days when I was using classic ASP.

    I have been creating webapps (mostly for personal use) since before the time that the term “webapp” was popular. And like every lazy programmer I don’t like repeatimg myself. So the helper functions and classes that I created for my first webapp eventually became my core codebase for creating my next app and the one after that and so on. Many projects later this codebase had grown in to an untamed monster. Worse yet, by the time that I gained enough experience to be moderately good at coding webapps, the codebase was large enough that a rewrite would be a major undertaking. It was legacy code but code, nonetheless, that allowed me quickly develop webapps. So I kept using it.

    The annoyance factor of my smelly web framework wore on me and, eventually, I could bear it no more. I had two options. I could either organize and rewrite it into something well designed or I could find and adopt something that was already well designed. I set out with the latter in mind figuring if I found nothing I could always fall back to a rewrite. As I researched web frameworks I soon understood that I was going to have to pick up a new language as well. There were good frameworks out there but none of them were built on ASP. I had already discovered open-source software and Ubuntu, so the prospect of moving on to a non-proprietary language was quite appealing.

    Like someone we know in the Rails community, I too am opinionated. I’m picky about what’s good style and what’s aesthetically pleasing. As such, certain languages just plain bothered me. I liked that PHP was popular worldwide and that it didn’t seem much of a leap from ASP. Its pointer notation just looked ugly and, quite honestly, I found it visually offensive. That was out. I kept looking and I stumbled upon a video that compared several web development platforms: Rails, Django, and (I think) Zope. As you would expect, I found pros and cons to each platform and its underlying language. I researched many platforms including some built on Java and Smalltalk, but ultimately it came down to two frontrunners: Rails and Django. Both looked great. I almost felt that I couldn’t go wrong whichever direction I chose; however, wanting a good, long-term ROI, I wanted to choose carefully.

    Ultimately, I chose Rails for a couple reasons. First, I found Ruby far more appealing to my sensibilities and preferred aesthetics. I disliked Python’s use of identation to write self-closing blocks of code (which is one of the reasons I resist Haml). Second, I really connected to the underlying philosophies found in Rails (and Ruby). (Chosing a framework — platform, library, gem, etc. — based on how well I connect with its philosophies has always served me well.) In fact, it felt that I had already invented (at least for myself) the ideas that I later found so well articulated in the Rails manifesto. I had been using the convention-over-configuration principle since my second webapp and I suspect that would be true of every other reuse-loving developer. I don’t remember the full details of the Rails pitch, but I do remember that bullet-point-by-bullet-point my excitement grew. It aligned with many of my own practices and ideas.

    Rails deserves all its credit. It’s not so much to have and work ideas in isolation, as I did. It’s better to develop and share those ideas, as DHH did. And it’s even better if, you can popularize the idea or product — as Ford popularized automobiles and Rails helped popularize Ruby. Greater things happen when ideas are worked by communities.

    In a way, I guess I’m just amazed at how so many people in relative isolation “originate” the same basic ideas. It’s almost as if the ideas always existed. They’re fruit on trees just waiting to be plucked. The trouble is, if you’re not putting your ideas out there, many others may end up solving the same problems without the benefit of your unique insights. I’m sure millions of people have said something like “hey, I already invented that” when they see something new on television. In reality all they really did was thought of it and that, My Friend, is practically meaningless.

    I’m very much an idea guy. I work a lot of ideas, and I know I need to get better at taking them further and getting them out there. Implementation matters more than ideas. I’m tired of toiling over some design, really giving it a lot of time and energy, only to later discover (through my voracious reading and research) that someone else had already hatched practically the same idea. It’s unavoidable. If you’ve thought of it, someone else will too. Or maybe you’re the someone else.

    I, for example, worked on a social CMS and then later discovered some of the ideas had already been implemented in Drupal. I continued my work and decided to tackle the problem of how to reconcile that two posts by two different authors were actually about the same thing. This lead me to discover topic maps and subject identifiers which offered a very similar solution to the one I had worked out.

    The great things about discovering that your ideas is secondhand is that you are often presented with a good deal of more thinking on the subject. What’s also great is that there will sometimes be a community continuing to develop and refine the idea. That’s a win too. But what can be disappointing is that it makes it extremely hard to offer something fresh and new to the world. I mean, if you’re one of those guys who wants to make a useful webapp (or any kind of product), the prospect of being the guy who presents it to the world, who revolutionizes something, who provides a better solution to an old problem is exciting. It can deflates your sails when you consult Google only to discover that your great idea exists in a dozen different flavors.

    Still, I have come think if you’re passionate about an idea, you shouldn’t drop it just because it’s already been done. You don’t have to be totally original to be original. No matter who you are, you can offer something different. Your ideas for a GTD app, won’t necessarily be the same as any of the thousands of other GTD apps out there. And if it is, that should be good news: you’ve saved your time. You shouldn’t be doing it. Change some significant thing. You need to differentiate enough that some should prefer your implementation.

    It’s one thing to work for a living and it’s another to create for a living. If you’re concerned only with earning a paycheck, I trust you can earn something if you work hard enough. If you’re concerned with making a ding in the universe, follow your passions and create something that is uniquely you, a unique combination that makes your contribution somehow different.

    Greg Kinnear in Flash of Genius portrays Robert Kearns, the inventor of intermittent windshield wipers. Kearns takes Ford to court alleging the motor company stole his idea. The Ford defense argues that the parts used to create the intermittence already existed. In his brilliant rebuttal, Kearns reads the first few lines of Dickens’ A Tale of Two Cities and then continues:

    I haven’t checked but I’m pretty sure there’s not a single word in this book that is new and they can all be found in a dictionary. All Dickens did was arrange them into a pattern. He created something new by using words, perhaps the only tools that were available to him just as almost all inventors have had to do in history.

    That’s how I see creating. You don’t have to invent corn to make cornbread.

    In addition to a love for coding, I have a passion for playing designer board games. Every year lots of new games are published. In boardgaming circles hardcore gamers are sometimes critical about games stating that some new game does nothing more than use mechanics from some other games. Maybe so, I think, but it’s the particular combination that makes it unique. The game Outpost was redone as The Scepter of Zavandor and again as Phoenicia. I prefer Zavandor which is neither the first nor the last. Nor is it completely original.

    Now, when it comes to web frameworks, I could have chosen Rails or Django. Both are solid and well-designed and yet they both continue to exist and to appeal to different people for different reasons. Just because a problem has been solved doesn’t mean the manner of the solution will appeal to everyone.

    Original ideas are rare. Original implementations are not.

    How many portable media players are on the market nowadays? They all offer the same basic features. Still they differ in what may seem insignificant ways: size, color, shape. While these aspects may be less significant than others (like features, capacity, and cost), they are not meaningless and they will matter to some.

    During a year end blowout there were 2 Passats left on the lot, one black (v6) and one white (v4). Having owned a peppy v6 Chevy Berretta, I very much wanted another v6 engine. Still, something about the car being white made it look much better to me than the black. Should the color or a car really matter? Isn’t the main thing that it gets you from point A to point B? Probably. But even an attribute as minor as color can sway a person’s decision. For the last 2 decades I’ve owned white cars.

    Kearns recognized that originality allows us to reuse existing things if only we arrange them in our own unique way. Even making one small change to something that already exists can be enough to cause people to prefer your product. (On a recent episode of Shark Tank there was a man who added a popout scraper to the head of a broom. He invented neither the broom nor the scraper and yet the investors fought over partnering with they guy.) Sure, many of the ideas you’ll have, will have already been thought (and even implemented). That’s why ideas are a dime a dozen and that what really matters is what you do with an idea.

    Still, I trust that the result of following a passion can produce something original and good. Don’t not do something you once aspired to do because it’s already been done. Just offer enough of a twist to set it apart in some way. And continue to be both passionate, even vocal, about what makes that particular twist so great. The personality behind a product can be as much a part of your product as the product itself. Don’t just have ideas, do ideas — and trust that your unique spin will make them great. As you must already know, even a small change can have a great impact.

    permalink

    • 2011-04-06
    • ruby
    • design
    • software

    It’s Not Just “Sexy Code”

    When it comes to crafting code, I’m about asthetics. Code should be pleasing to the eye and easy to read. My boss dismisses it as just “sexy code”, but I think there’s more to it. It expresses more with less. There’s a focus on clarity. It reads like verse. Being terse and well structured means readable. And this, in turn, means maintainable.

    I’m constantly surprised how little attention other programmers pay to this. If the code addresses the ticket, it’s done. There’s very little consideration for its future. That code may not have dreams of attending an ivy league school, but it has a future. And if you’re thinking about it, you’ll be less likely to let it settle for living in the ghetto.

    I contract at a VB.NET shop. On the side I do Ruby. Ruby has shaped my thinking. I love the philosophy that code should be beautiful and that coding should promote programmer happiness. I often try to bring Ruby ideas to our .NET world. In our shop, I’m sort of a black sheep. I’m the guy bucking the system with new ways of doing things. I’m the guy writing extension methods and helper classes in an attempt to make code more expressive with fewer keystrokes. Code craftsmanship isn’t a concern. Churning tickets is. Creativity, for the most part, can be left at the door.

    I can’t understand how some programmers fail to make the connection that beauty does more than evoke emotion. It makes things more functional. And because beauty makes a thing more enjoyable to use, a beautiful thing gets more use. When we work with beautiful things that have beautiful designs it feels less like work. It promotes happiness. Chores become fun.

    When working within a body code I notice the details. Is it expressive? Well structured? Verbose? I can’t help but notice my surroundings and be bugged if things are not in good order. I can’t help when I’m already in a room fixing a broken light switch not to also repair the squeaky door hinge. I want the room to be a nice place to visit if ever I have to pass that way again. For me, it’s leaving things better than I found them. This means I go beyond the bounds of a ticket. When I spot code smells, I find the urge to clean things up irresistable. I’m passionate about improving code if it can be improved. I think passionate programmers are more likely to be craftsmen, to pay attention to the elegance, not only of a design, but also to even a single line of code.

    I’m of the mind that the business domain should shape most everything from native classes to the language itself. In the long run, most every large project should progress toward becoming a framework. It’s bound to. In any business domain, patterns will emerge and when they do they should be extracted for reuse. I often address this by working out a DSL or an API. I don’t care only that you can ask an object to do something, I also care about the manner of the asking.

    When it comes right down to it, extend the core classes if you must. Write those convenience methods. Effectually, your framework should cater to beautifully expressing the patterns and concepts most prevalent in the domain. Some designs are shaped by the idea that extending native classes is dangerous. (That’s how jQuery differs from Prototype.) I prefer to bend a class to whatever shape I see fit. I understand the risks. I just prefer that my objects do what I ask them to do. And I want to ask them directly. I don’t wanna have to instantiate some visitor or decorator or wrapper. If its a dog, I’m gonna teach it to roll over. I’m not having someone else roll the dog over. Objects that can do for themselves are things of beauty. And they read nicer.

    Matz created Ruby to satisfy his idea of beauty. I also have my own idea of beauty. While I’m not about to create my own language, I don’t have a problem taking a language and bending it to satisfy my personal sense of beauty. In doing so I think the result is usually more durable, useful, and maintainable, not just “sexy”.

    permalink