Programming Should Be Relaxed, Care-Free and Easy

While I'm on the subject of last week's New England Code Camp, there was another statement made during one of the sessions which stuck with me.  This was a session early in the day where Richard Hale Shaw was talking about maintaining focus and tracking progress in one's software development career.  The format of the discussion was interesting.  He started out by making 20 statements about software development while we noted to ourselves whether we "agree" or "disagree" with each statement.  Then the session progressed with discussions about each one.

The statements were in many cases intentionally vague.  The idea we ended up focusing on was that context is key in many of these things.  And, of all the statements that were made, the one that stuck with me the most was:

Programming should be relaxed, care-free and easy.

The room was divided on this one, which wasn't uncommon among most of the statements given that we all inferred our own context based on our own experience.  This one also generated a good bit of discussion.  Time didn't permit very much, though.  The basic idea we got out of the discussion was that what we do is difficult by nature and we enjoy challenges and all that good stuff.  We don't want things to be stressful, but "easy" just doesn't happen in the real world.

But, at least for me, that didn't really resolve the statement.  I still stayed in the "agree" camp.   Thinking about it, I keep circling back to a point I shared with the group about how it all depends on how you define your terms.  Let's define these ones...

1. Relaxed - Well, we can all agree that work shouldn't be stressful.  Stress begets poor results.  Every good manager knows this, and every programmer wants to work for a good manager.  Sure, sometimes stress happens.  Sometimes deadlines are tight.  But, honestly, that's what managers are for.  If a project is unrealistically managed and the stress of it trickles down to the developers, then the project is in danger.  The developers should be relaxed.
2. Care-free - I can see how this one can have a lot of different meanings to a lot of different people.  At first one may picture a kind of hippie-like carelessness to the world around you.  This, of course, isn't a good approach to programming.  My interpretation was a little different.  When I think "care-free" I'm reminded of an instruction given to the American during a sparring match in The Last Samurai:
   

   "Mind the sword, mind the people watch, mind enemy - too many mind"

   This is where the developer should be.  He shouldn't have external cares pressing him while he's working.  His team (manager, project manager, tech lead, etc.) should keep those things out of the way.  The developer should be able to remove these external influences and work in a care-free, worry-free environment.  The work being produced by the developer is the only concern.  If that work has value to the company, then the environment which produces that work has value to the company.
3. Easy - This was the one that most people didn't like.  Again, it's a matter of definition.  Easy is the opposite of difficult, that's easy.  But at the same time, difficult is not the same thing as challenging.  I certainly agree with the overall opinion that what we do is by its nature challenging.  It's interesting, it requires intelligence and focus.  However, just because what we do is challenging doesn't mean it's also supposed to be difficult.  That's a cop-out for people who don't want to make it easy.  Making it easy takes effort, it takes time, it takes work.  But the result is that it should be easy in the sense that it should be enjoyable.  This goes back to the "relaxed" bit earlier.  The job itself is challenging, but the act of going to work and doing the job should be easy.

As it was in the session at Code Camp, I'm sure there are lots of differing opinions.  That's part of what makes the profession so enjoyable.  But, for me (emphasis mine)...

Programming should be relaxed, care-free and easy. 

OO HTML

I've been kicking around a thought in my head for a few days now, and I'm not sure where to go with it.  (Or if there even is anywhere to go with it.)  The idea struck me while I was at New England Code Camp this past Saturday, specifically in a session with MS-Joe on JavaScript in ASP.NET.  (Great speaker at workshops like this, by the way.  I'd love to attend more interactive stuff with this guy.)

He was talking about jQuery selectors and such, and someone in the audience asked, "So it uses CSS to select elements?"  Joe replied with a little explanation, but essentially said, "Yes, it uses CSS selectors."  Immediately I was compelled to raise my hand to clarify... "Well, it's not so much that it uses CSS selectors.  Think of it more that jQuery and CSS use the same selectors to identify elements in the DOM.  It doesn't really belong to either of them."  This prompted a very short discussion about how one can decorate elements with classes that have no CSS purpose and serve only for jQuery selection.  Joe said, "That's interesting, and I can't say I've ever used classes for non-CSS purposes before jQuery."

I didn't want to derail the session, so I kept my ongoing thoughts to my self where they've been stirring for a few days.  But ultimately, my thought was...

Can one effectively think of class specifications on HTML elements as analogous to interfaces on class implementations?

For some reason I'm fascinated by this question.  What are the implications, if any?  From the point of view of the selectors, it makes sense.  For example, if you want all of the "td" elements in the document, you can select them by their type.  Essentially, you're looking for a particular element implementation, "td."  Class specifications, on the other hand, are element-agnostic.  You can select by "myClass" and get all elements which have that class, regardless of their type.  Basically, all elements which implement the "myClass" interface regardless of the implementing type.

Does this even mean anything at all?  Is there any direction to take this?  I'm not sure.  Maybe I'm just mulling over the obvious, but for some reason the very concept of it intrigues and excites me.  Or maybe as I dive further into serious JavaScript application programming (I'm loving MooTools, by the way), someday this will make for an interesting and useful object-oriented approach to DOM manipulation.

It's just... interesting.

Why I think CouchDB is Awesome

Recently I have gotten a little practice at thinking about how awesome CouchDB is. I gave a presentation entirely shot from the hip on this unique technology and the topic its advantages came up recently on the project's main mailing list. I figured trying to summarize some of this would make a good blog post. So... here is the list of my stand outs:

Easy horizontal scale path:

It's HTTP. Guess what there are already a lot of and well understood? HTTP load balancers and caching systems. It has master-master replication built in. Your database logic is in a design document, which is just another document that can be replicated across nodes.

Vertical scaling:

With support for Android and iOS you can now take the same database and use the built in replication to take it up and down from mobile, desktop, and server. Awesome.

HTTP JSON:

Anything can talk to it. You don't have to have a middleware piece to talk to it for many web application scenarios. This can greatly simplify things.

Changes API:

You can have a lot (I mean a lot) of systems monitoring for changes and apply filters to get just what you want. 

Concurrent at it's core:

Thanks to Erlang and the ideas of MVCC you can have many connections to the database with no worries. I think I have read that some test cases found that you would run out of IO bandwidth and ports before CouchDB would stop responding. It might be slow (probably have time outs), but it's up and talking. Write speed is limited since it's serialized on a node, but in either case you could load balance that.

Now this wouldn't be completely fair I suppose if I didn't list some of the pain points:

Documentation is a bit spread out.

You really have to read the book and mix in the wiki and blogs.

Auth/Auth system is pretty primitive:

Sounds like there is some ideas around to improve this and it'll probably get you through most cases. If it doesn't get the job done of course you could just add a middle layer to manage these things. Using other database technologies you would probably have a middle layer anyway that managed auth/auth, so probably not that much of a pain point.

Learning Curve:

You pretty much have to study CouchDB for a little while before you grok it. There aren't a lot of features to make you feel at home when coming from a traditional database technology. Biggest one obviously is that any real querying is done via predefined map/reduce views. These are computed incrementally and have no side effects. It's hard to get a decent mental model of using documents and map/reduce.

There are probably more for both the pro and the con list but that sums up what I tried to hit recently.

Source Control and Inverting the Motivation

Sorry I haven't written in a while.  I've been starting a new job (yes, again) and, you know, a transition sort of consumes a lot of time and effort.  Also, this one involves relocation.  But so far I've been unquestionably happy with the results.

Anyway, I've been working at a client site for a few weeks now as we define and document a project.  One of the subjects that needed to be addressed is one of source control.  They were previously hosting somewhere off-site, and they're looking to us for recommendations on what kind of setup they'll want as they move forward.  Not a problem for us, of course.  We specialize in helping clients.  So, for the purpose of this client, it's pretty cut and dry.

But the experience as a whole got me thinking a lot more about source control.  Sure, we all have our favorite products that we know inside and out (for the most part, anyway) and it often just boils down to Yet Another Religious War among geeks who all think their preferred product is better.  That's our culture, it's how we think.  But, thinking about it, there's a key aspect of source control that I feel is all too often overlooked.  The component of developer motivation.

Let me explain...

"Source control" is more than just a repository for code.  It's more than just a repository which tracks in minute detail any changes made to code.  The name itself implies a greater purpose.  "Control."  For it to be successful or useful by any measure, it needs to be a controlled point of access to code changes.  Not just track them, but insist on tracking them.  To this end, source control needs to motivate developers to use it.  It's something we've all touched upon before.  A source control system should facilitate what we're doing, not get in our way.  It should never create a barrier to what we're doing.  It should never motivate us not to use it.

Consider an example...

• System 1 has a source control repository which holds the code.  There isn't really anything closely resembling continuous integration, nor is there even an automated deployment process.  Deployment to any environment, be it test or production, is done by a developer.  He compiles the code locally, sets up the configs locally, and copies the output to the server.
• System 2 has a source control repository which holds the code.  Upon check-in (at least to the main repository), the continuous integration system compiles the code and runs its automated tests.  Once everything passes, it automatically deploys to a target environment.  Maybe not the official QA environment, maybe it's just an internal shared Dev environment.  But it's deployed somewhere and is immediately live.

Now, given these two systems, which one has source "control"?  Well, think of it from the point of view of a developer.  If you wanted to make a change and see the result of that change, each system has a shortest path to make that happen.  And any manager or professional of any kind will tell you that the shortest path is the path you should always expect people to take.

In System 1, the shortest path is to make the change, compile it, and copy it to the server.  In System 2, the shortest path is to make the change and check it in to source control.  The difference is clear.  System 2 motivates the developer to use the source control system.  System 1 inverts the motivation.  Such a setup actually provides incentive for the developer not to use source control.

Sure, the developer knows the importance of source control.  He wants to use it.  But you know how it goes... He's just going to skip it this one time because he just needs to quickly see the result of this change in the test environment.  He'll update the source control later.  Really, he will.  You would, right?

Both of these systems host the source code in a central repository controlled by the business.  Both of them provide tracking to any code changes made in the source control system.  But only one of them controls the source.  Only one of them acts as a gatekeeper.  Yes, in System 2 a developer can still circumvent the source control.  But it's a hassle.  And his changes will be over-written on the next check-in.  So why would he?  System 1 sits outside the path of development.  It's an extra step.  System 2 is the path of development.

And it happens more often than we think.  Ask yourself... How do you track changes to your database schema/procedures/views/etc.?  That's source code too, after all.  Those are a major part of the overall system and their changes absolutely must be tracked.  But even in System 2 above, how are database changes tracked?

I've seen plenty of System 2's out there which treat database changes exactly like System 1.  (Hell, I've even helped design and painstakingly maintained such a setup.  So I know about the motivation.)  It's a question I ask when I encounter a new setup at a new job or a new client site:

• Me: "How do you track your database changes?"
• Them: "Oh, just like our code.  We keep it in the source control repository."
• Me: "How are the deployments handled?"
• Them: "Simple, we run the scripts against the database."
• Me: "Manually?"
• Them: "Ya, why not?  Developers check in their change scripts and then run them at deployment time."
• Me: "Doesn't that invert the motivation?"
• Them: "Doesn't that do who with the what now?"
• Me: "Well, the physical act of recording the change in source control is itself the extra step.  There's no motivation to actually do it.  The target database doesn't know the difference.  It's source, but it's not controlled."

It's not enough to just keep a repository of your source code.  It's not enough to track changes to that repository in minute detail.  It's not enough until you've created an environment where the shortest path from developer to server is through source control.  Not as an extra step, not as a to-do item on a deployment checklist pinned up next to the developer's desk, not as something off to the side which needs to be remembered.  That's just a source repository.  Source control needs to be in the path.  Not in the way, mind you, because that just provides the developer with motivation to go around it.  It needs to be part of the path of least resistance.

The Shortest Distance between Two Points is MATH

They need me to put together a simple little system at work that finds known locations within a given radius of a given location. This sounded familiar, so I dug up an old SQL query of mine from a LONG time ago...

SELECT
  Name,
  Address,
  City,
  State,
  Latitude,
  Longitude,
  (
    ACOS(
      COS(@center_latitude * (PI()/180)) *
      COS(@center_longitude * (PI()/180)) *
      COS(Latitude * (PI()/180)) *
      COS(Longitude * (PI()/180)) +
      COS(@center_latitude * (PI()/180)) *
      SIN(@center_longitude * (PI()/180)) *
      COS(Latitude * (PI()/180)) *
      SIN(Longitude * (PI()/180)) +
      SIN(@center_latitude * (PI()/180)) *
      SIN(Latitude * (PI()/180))
    ) *
    (
      (@equatorial_radius * @polar_radius) /
      (
        SQRT(
          (@equatorial_radius * @equatorial_radius) -
          (
            (
              (@equatorial_radius * @equatorial_radius) -
              (@polar_radius * @polar_radius)
            ) *
            (
              COS(@center_latitude) *
              COS(@center_latitude)
            )
          )
        )
      )
    )
  ) AS Miles
FROM
  Places
WHERE
  Miles <= @search_radius

This query accepts a center lat/long (the customer location) and a radius (the distance from the location to search) and finds any known locations within that distance from the center and notes that distance in miles (so we can sort and find the closest).

It also accepts parameters for the radius of the Earth. The radius of the Earth can be expressed in many various ways. For simplification, we'll use these:

@equatorial_radius = 3963.190 miles
@polar_radius = 3949.902 miles

(Note that this equatorial radius may not account for the crust displacement during the 2004 Indian Ocean earthquake.)

This distance calculation not only plots a circle around the area, but in the projection of that circle onto the plane of the Earth it accounts for the curvature of the Earth’s surface and the bulging at the equator, derived from the WGS-84 ellipsoid model.

We never did get around to using this at a previous job. (They plotted searches as rectangles around the center... ew. Just goes to show how a fundamentally broken business idea can churn out sub-par results from an otherwise intelligent and talented team of developers.) But maybe I'll finally get a chance to use it here.