Daniel Parker accident

on May 17, 2010 @ 01:54 AM

Daniel Parker, a colleague, friend, and coworker of mine passed away this evening. Daniel was competing in a triathlon on Friday night when he got into a biking accident. Daniel was airlifted to the University of Michigan hospital and underwent two surgeries between Friday night and Saturday, but during the second surgery they stopped because it wasn’t helping Daniel’s condition.

You may know his name if you’re a developer, because so was Daniel. You may know him from his work with Quickbooks and Ruby or maybe his GMail rubygem or one of his many other projects that he authored or contributed to.

You may know him as a Christian, because so was Daniel. While he wrote code because it was fun and he was quite good at it, he first and fore-most lived for the Lord.

You may know Daniel as a fervent competitor with a kind heart and a powerfully analytical mind. You may know Daniel for a number of other reasons, and if you didn’t know Daniel then I assure you, if you did, he would have left nothing but an impact of an honest, energetic, intelligent, warm hearted, analytical, yet loving person.

I knew Daniel because of his work in the Ruby community and in the Ruby community in the midwest and specifically Michigan. Last fall I attended GRGivecamp with Daniel. Four months ago, Daniel came and began working with me at Mutually Human Software. Daniel and I worked closely together for about 30 hours a week every week. Every day we’d pair program (or party as Daniel would call it). Almost every day we’d eat lunch together and talk – sometimes about work and sometimes about everything else in life. I never imagined that four months of my life with someone could have such an impact. That’s also the kind of person Daniel was – impactful in all the best ways.

Before I had ever met Daniel personally, my colleague John Hwang had told me that he was the kind of person we wanted to work with, not just the type of developer, but the kind of person. At first I was skeptical, but after I met and began workingw ith Daniel I knew John was right. Daniel was more then just a developer—he was human. He was the kind of spirit and person who anyone would want to build a team around. He was an amazing developer, but even more-so he was an exceptional person. It’s hard to believe that Daniel was only 23 years old.

I will miss you Daniel, as a friend, as a colleague, as a human. May your life go on to impact countless lives. I know you have impacted mine.

P.S. – when you get to heaven be sure to teach everyone Rook, they’ll love it just as much as you did when I introduced it to you. That will forever be a cherished night in my life.

UNIX tee in real life

on April 29, 2010 @ 02:13 AM

I wrote a nice little article on using the UNIX tee command in real life. If you’re wanting to see the purpose of tee or learn something new about bash, check it out:

http://mutuallyhuman.com/2010/4/29/unix-tee-in-real-life

Happy coding!

Binary Chop Shop in Scala

on November 03, 2009 @ 02:25 AM

In an effort to start learning Scala again (i started in the summer then got busy) I decided to tackle a simple yet fun code kata from Dave Thomas called karate chop

I ended up using Specs to make sure I passed Dave Thomas’s test criteria. I’m sure my below two solutions (recursive and while loop) are quite clunky compared to someone who’s familiar with Scala, but the goal of this was to get something running and passing. In a week or two I’ll revisit again after learning some more things about Scala and hopefully be able to tidy things up a bit.

Anyways, here’s my code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

class BinaryChopShop {
  def chopRecursive(target: Int, list: List[Int], args: Int*): Int = {
    if(list.isEmpty) return -1;

    val offset = if(args.isEmpty) 0 else args.first;

    if(list.size == 1){
      return if(list.first == target) offset else -1; 
    } else {
      val index = list.size / 2;
      val value = list(index);
  
      if(target < value)
        return chopRecursive(target, list.slice(0, index), offset);
      else
        return chopRecursive(target, list.slice(index, list.size), offset + index);
    }
  }
  
  def chopWhile(target: Int, list: List[Int]):Int = {
    var nlist = list;
    var offset = 0;

    while(!nlist.isEmpty){
      if(nlist.size == 1){
        return if(nlist.first == target) offset else -1;
      }
      
      val index = nlist.size / 2;
      val value = nlist(index);
      
      if(target == value) return index + offset;
      if(target < value){
        nlist = nlist.slice(0, index);
      } else {
        offset += index
        nlist = nlist.slice(index, nlist.size);
      }
    }
    return -1;
  }  
}

Summary of thoughts on data and migrations

on October 17, 2009 @ 08:16 PM

I shared a summary of my thoughts today with my project team (we’re distributed, multi-national team)... and I thought what the heck why not share with the rest of the world to. Here goes…

I’m not sure what everyone’s conventions or views are on handling the removal of data in the app that is no longer used, so here are some of the guidelines I follow to help promote sharing and consistency.

Seed data

To load data that has to exist for the application to run, I like to use seed data and I am a big fan of Michael Bleigh’s seed-fu plugin. Seed data should be setup so that it can be loaded at any point during the lifetime of an application. It should not destroy data that leaves orphaned data and it should not duplicate data.

Updating data

I like to use migrations to update existing data. If the migration and data update is complex and irreversible I will add a unit test around the migration because due to the high risk of causing irreversible damage (unless a full DB backup is loaded).

Updating application-required data

When the data that the application depends on changes (ie; the seed data) I tend to update both the seed files as well as add a migration to properly handle any existing data, whether this means removing the data, marking it as delete or inactive, etc.

Updating data

In development modifying data directly through MySQL or ruby scripts is much more forgivable and often very fast and efficient. We have no risk of causing users of the application harm or loss of data. Once something is figured out I like to either add a seed-file and/or a migration if it’s a change that needs to get made on staging and production.

In staging modifying data directly is less appealing because staging is supposed to represent what happens when we go to production. If we have to modify data directly in staging then we’ll probably have to modify it in production, so a migration and/or seed-file is a better place to track the change. I find it tempting sometimes to script/console and modify data directly.

A problem with this is that we risk screwing up staging for folks who are using it to preview features, check out bug fixes, etc. I find it better to dump the database and pull it over to my local development machine. Once I have it I can load it up locally, recreate the issue, and do whatever I need to do to find the source of the issue. This removes the risk that you fill further break staging for any users using it. Once I find the issue if I need to I will add/update a migration and/or seed file.

In production modifying data directly is super dangerous. It’s a change that occurs outside of version control and potentially without being run in development and/or staging which could catch bugs in the updates. The risk of causing irrevocable damage is so high I think doing this should be avoided.

I find it’s always been better to take an extra few minutes to make sure the fix is right and then to deploy, then it is to make a quick fix directly in production and find the change caused new issues. Production should never turn into a debugging sandbox. Pulling over a backup if necessary is safer and allows us developers more freedom to freely change the data to find the appropriate fix.

If you have to use script/console not MySQL

If you find you need to update data directly it’s better to use script/console, then by touching the database directly using MySQL. For example, Scott once asked me to change his user name. Changing his user name was a very low risk change, so I loaded up script/console and made it.

The benefit of script/console is that you let all of the rules and validations inside the application be run when you make the change. If I had made Scott’s username too short, too long, include inadmissable characters I would not find out if I did it directly through MySQL, unless I had duplicated all of the logic in MySQL stored procedures and triggers (which I cringe at the thought of).

Conclusion

Well, that’s pretty much a summary of my personal guidelines when it comes to dealing with data updates, migrations, seed-files, etc. If you have any other guidelines you follow that you find helpful please share. I think being on the same page here will help us as we push forward.

git review

on October 01, 2009 @ 01:15 AM

I’ve gotten into the habit of review code that comes down from every other developer, rather than blindly merging in. For a while I was typing “git log master..origin/master” but it became to tedious to type out. I’ve updated my .gitconfig to provide the following alias:

[alias]
  review = !"git log  master..origin/master" 

Now I can simply say:

git review

If you want to view actual code changes rather than simply the changelog just add the -p flag:

git review -p

A little nicer.

BDD not so much, really? Part II

on May 28, 2009 @ 07:38 AM

I think there’s a confusion that BDD == toolset (ie. Cucumber, Cucumber+RSpec, rspec). That needs to stop. BDD is an approach to software development. You drive your software by focusing on behaviour. This is usually done by focusing on behaviour from the outside-in. This starts by identifying the behaviour of the application, then driving inward until you get down to the low level components.

Focusing on behaviour may yield different tools throughout the process. Cucumber and RSpec are just two examples. You could very well use Cucumber plus test/unit, or perhaps just RSpec, or maybe nothing at all. These are just tools to support a development style. They are NOT the development style themselves. You can use Cucumber in a way that doesn’t support BDD. Same goes for RSpec and any other tool.

I realize there are people who don’t buy into the RSpec philosophy. To them it’s just another take on unit testing. I do buy into RSpec. From day one RSpec’s goal has been to be a BDD tool that tries to get the words right. Can you use xUnit libraries in a way to achieve the same affect? Yes you can, but most of those usages have been heavily influenced by RSpec which was built on the ideas and motivation for BDD and “getting the words right”.

Without this focus many of the high level test/unit style add-ons (especially in the ruby world like context, shoulda, test/spec, etc.) wouldn’t exist. So to me, this makes the subtle differences very important as it changed how everyone wrote their tests.

For me personally, testing is an activity after you write code. I find it refreshing to talk about writing code examples to drive design and tests to talk about actual testing. Perhaps it could be phrased as, you start with examples and when you’re done you end up with tests. Similar to starting with user stories and ending up with features. Right now that works in my head, but it’s late and I may need to revisit that thought after a few hours of sleep.

Example is just a better word then test to. When you talk to someone and you don’t understand what they’re talking about you don’t say, “give me a test”, you say, “give me an example”. Well, that language is more natural. You are providing an example of how something should work. This example ends up providing regression (test) value once its implemented, but you didn’t start with a test, you started with an example of the code you wanted.

BDD not so much, really?

on May 28, 2009 @ 06:05 AM

Updated May 29, 2009

This rant is in response to http://robertlally.com/post/bdd-not-so-much

BDD didn’t start off as a replacement for TDD. It started off a way to better understand and explain the process of TDD. The name change as I understand it was to communicate the intent of TDD in a clearer and more direct way. You’re not writing tests for the sake of writing tests, you’re driving behaviour. Focus on the behaviour you want to achieve first and foremost. Use that behaviour as the driving force for your examples (or tests).

Corey Haines nailed it on his comment to the same post, “BDD is no longer a replacement for TDD, but, rather it is a workflow for creating a system that more closely resembles what the client is looking for.” I think two of best tools which exist to support the BDD workflow of outside-in are Cucumber and RSpec. Cucumber for higher level system behaviour and RSpec for driving lower level design.

In the article, the author criticizes the “should” language. Rather than simply scoffing at the idea of replacing “assert” with “should”, I tend to think about it in terms of natural communication. The reason I like “should” language over “assert” language is that when I’m communicating with another developer I don’t say, “assert equal one day to do things good”. That doesn’t make any sense. I say, “one day to do things to should be good”. It’s much more natural for me to write closer to the language I think and communicate than it is to translate it to assertion-speak. I want to communicate in my code more closely to how I communicate to other people.

While the term BDD is a few years old it takes a while for dialogue to happen, and understanding to occur. I’m sure a lot of people hear about BDD, read about it from Dan North’s Introducing BDD . BDD started as a way to explain and better understand BDD, but what I think was realized was that it was much more than simply TDD.

Many tools are emerging which claim to support BDD-style development. It’s important to note that BDD isn’t the tool. You can have many tools support BDD style development in different ways and to different degrees. Although a good tools makes any process easier, what makes BDD is the mindset you have and how you go about writing software. Certain tools emerged with this in mind and are thus labeled BDD tools. Cucumber, RSpec, and JBehave are some examples.

The article mistakingly sheds Cucumber in the light of solely driving the design of code and suggests its a bad tool to do that. Of course it is! It is not a tool intended to drive the design of your code from a low level. It is to communicate in plain text how the application should behave. The plain text is something that is business readable, something that adds value not at the code design level, but at a higher level: communication and understanding requirements!

Cucumber is equivalent to a high level integration test for those of you who come from a testing background. It runs the entire application (or whatever can be reached through automation, different types of systems have different limitations). It works in combination with a tool used to drive out the design of your application using lower level code examples. For example, RSpec.

The #1 output of BDD is a working application that is behaving as expected. In addition to that you have an application-level regression suite in which you can run against the code base at any time. You also end up with smaller, more focused code examples which provide regression against isolated behaviour of the system.

Combined, you end up with documentation at two critical aspects. The first is business readable scenarios that the system supports. The second is developer documentation made up of the lower level code examples. Since these are often written more clearly than assert-style syntax it’s easy to produce human readable behaviour specifications for focused pieces of behaviour. And in the end you have a repeatable process which allows you to confidently produce the working software.

I also don’t see where UML to BDD comparisons make any sense. UML is a modeling language. BDD is more of an approach or methodology. A more accurate comparison would be plain text scenarios vs. UML. Although that makes little sense as a comparison because UML is not something you can give a non technical person to write, read, and edit.

BDD by itself doesn’t fix any problems. It provides an approach which focuses on behaviour first. To me, there’s no point in building a low level library if you’re not aware what higher level problem you’re solving or objective you’re adding value to. This boils down to a person still has to “do the work” to make it successful.

At the end of the day though I cannot speak for anyone else except myself. Shifting my focus on behaviour rather than “tests” led me to write better code examples. Often times I would write less of these because I was writing better examples. It’s also helped improve communication between myself and my team, customers, and other developers. BDD may evolve into something else, or perhaps a new perspective will come around that will take the world by storm. I am all about continuous learning and improvement. And I invite any ideas Mr. Lally or anyone else brings to the table.

Also, BDD never claimed to be THE answer. Any process that claims to be THE answer will surely not be THE answer for everyone in all situations. BDD has been an answer for many people though and as of now it will continue to be an answer for me in how I work.

A good resource worth checking out for BDD, it’s philosophy, and how to apply it in practice is The RSpec Book

rspec/cucumber ML email etiquette

on May 09, 2009 @ 03:18 AM

Aslak Hellesoy requested on the rspec/cucumber mailing list the other day that folks stop top posting. His words:

I find it really hard to follow conversations that use top posting (http://en.wikipedia.org/wiki/Posting_style). If you have a [Cucumber] topic, please respond with inline comments. And use plain text email – not html.

I agree with Aslak’s request for the most part. There are times when top posting is perfectly acceptable, but those are too often blurred by the countless times where people are just plain lazy. While most of the replies have been rather humorous in response a couple recent replies have the look of actual requests to the community: snip out things not pertaining to your reply and the removal signatures.

The only part I don’t agree with is the text email. I’m sorry, but if you use an email client which can’t show html, or can’t not show the html part of an email then you need to find a new email client. I have the feeling Aslak was referring to folks that only send HTML email, void of a plain text part. If that’s the case I am in full agreement with his request.

Aslak’s request was well intended and thoughtfully brought about. I hope the replies stop before there is a giant list of dos and donts, followed by a flamewar that will most likely have a negative impact on such a wonderful community.

BDD w/Rails Class

on April 03, 2009 @ 02:30 AM

Shortly after RailsConf and while The RSpec Book is hitting the printers I’m going to be teaching a BDD w/Rails class with the amazing guys at Collective Idea

• Official announcement – http://mutuallyhuman.com/2009/4/3/bdd-with-rails-class
• Offical Course – http://ideafoundry.info/behavior-driven-development

Hope to see you there!

Scenario Observation

on March 20, 2009 @ 12:00 AM

One of the hardest things about being the developer and the scenario writer is that we’re in the thick of it. Once we get something written down we want to get it to work and then move on. This may involve copy and pasting part of an existing scenario to just get the job done. We get antsy.

One of the benefits of having the customer (or someone else) write the scenario is that we get to be the critic and not the author. We can focus on the scenario and ask questions like: does it read well? Is it doing too much? Is doing little? Can I understand its intent? etc. etc.

When working with a pair our pair should really challenge us to write good, communicating, intention revealing scenarios (just like they should be doing with code). This can be hard when we are working solo because we may just be staring at the screen for too long, and we can’t see the forest for the trees. If that’s the case grab someone else for a quick review, even if it’s after you finish implementing the scenario. Refactoring applies to scenarios to.

Scenarios are like code, if we don’t tend them well, they will grow messy and hard to maintain. We are best served to spend a little time upfront to keep them tidy rather than wait until we have hundreds of steps that don’t do a good job of communicating and require people to have to read through all of the step definitions to figure it out.

Go forth and code! ;)

On Writing Good Software

on December 22, 2007 @ 10:21 PM

The craft of writing is so similar to that of software development. I recently found this out by reading On Writing Well by William Zinsser. Below are some quotes from the book with commentary on how they apply to the software developer.

You will write only as well as you make yourself write.

Substitute write with write software and it remains a truism.

Writing software is easy. Writing good software is hard. It takes discipline to become a good software developer. The only way to get there is to write better software today then you wrote yesterday. And the only way to do that is to learn from what you and others have written.

Clutter is the disease of American writing.

The same can be said for writing good software. It’s very painful to create or find a bloated method or class doing something it shouldn’t be doing. It’s even more painful to maintain. Small and simple works wonders within the design of a program.

Strip every sentence to its cleanest components.

Strip every method and class to include only the functionality it needs to do its job. Methods which might be used at some point—get rid of them. Comments which try to explain away complexity or ambiguity—simplify the code so it’s readable and remove the them. Classes which try to do everything—refactor and pull out things it doesn’t need to do into their own class or module. Clever code—turn it into simple code. Simplify, simplify, simplify.

You must know what the essential tools are and what job they were designed to do.

A carpenter must know how-to hammer nails and saw wood before he can build a house. Likewise, a developer must know how-to write good code, perform object decomposition and refactor before he can build an application. Other basic tools and skills that a developer should know are: writing testable code, testing and test automation.

Take your stand with conviction.

Care about the software you develop. Stand up for customer involvement. Stand up for short iterations. Stand up for testing. Stand up for quality, even when the deadline is fast approaching, it’s the best chance you’ve got for hitting it with working software.

Never hesitate to imitate another writer.

Never hesitate to imitate another developer, especially one that writes better software than you. It will make you better in the process. Find open source projects that exceptional developers have worked on and read that code. How are they attacking a problem? How did they solve it?

A while back a coworker asked me if I had read through Mephisto’s source and I said I had scanned it, but that I didn’t think it was anything special besides the routing. A few weeks later I started reading the source. Rick Olson, the author of Mephisto, has some great techniques and code tucked away in Mephisto, things that I would be missing out on if my coworker would have never challenged me to read the source. Thanks Drew.

...it’s hard not to be intimidated by the expertise of the expert.

Ask questions. If you don’t understand something, ask. If you think it’s a dumb question, ask. Let the resident expert enlighten you. When they explain something and you still don’t get it, ask clarifying questions. They didn’t wake up one day an expert. And neither will you.

Writing is related to character. If your values are sound your writing will be sound.

Developers who have character are exceptional people to work with. They not only write better software, they inspire those around them to write better software.

Decide what you want to do. Then decide to do it. Then do it.

For all of those “I want to learn language X”, “I want to start learning TDD”, etc. statements—start learning language X, start doing TDD.

Think small.

Two immediate thoughts come to mind. First, good object decomposition. Work with simple objects that work with a single responsibility and let the overall system evolve of those simple objects. Second, short iterations over long ones and short stories over full blown specification documents. Thinking small in these regards will help you produce cleaner and simpler code as well as produce the right working features—sooner.

rak, ack and findit

on December 13, 2007 @ 04:52 AM

In Helpful Command Line Tools from last month I posted on my custom findit script.

Jason Porrit commented on that post and mentioned ack , a perl alternative to grep and find which offers terminal color highlighting to your results. I also found this morning a ruby alternative called rak

All of these utilities do the same thing, they search a directory structure for files whose contents match a given pattern.

Here’s Ack

Here’s Rak

Here’s findit

Overall ack and rak beat out findit, but findit has a much better name. I think I’ll just alias findit to rak. (yes I”m biased to ruby code over perl code).

The only thing ack and rak are missing is a filename only option. If I can find every file matching a pattern from a given start directory that would rid me of findfile as well!

Helpful Command Line Tools

on November 23, 2007 @ 02:54 PM

Here’s a post about some of the command line tools (both standard on *nix systems and homegrown) which make software development just a little more efficient.

The homegrown tools may only work on OSX. This is because unix utilities on OSX often have different options to do the same thing (such as sed’s -E on OSX and -r in Ubuntu).

find

find is a unix utility for searching files in a directory hierarchy. find is a powerful tool that comes with a lot of options. Some are more common then others.

Here are the options I use frequently:

• -name pattern – this will match filenames against the supplied pattern
• -exec command argument \; – runs the specified command against each file matched

1
2
3
4
5

# Using -name to find all files or directories which match the pattern "*.rhtml"
find ./ -name "*.rhtml"

# Using -exec to find all rhtml files whose file contents match "Continuous Thinking"
find ./ -name "*.rhtml" -exec grep -Hn "Continuous Thinking" {} \;

For development the -name option doesn’t help me much as TextMate’s Apple-Tab is far superior and faster to use, but editors like TextMate lack the efficiency of doing a -name and -exec combination from the command line. Sure TextMate has Apple-Shift-F to search file contents project wide, but what about all of those files you want to exclude (like log files), plugins (vendor/plugins) or the whole rails directory (vendor/rails).

TextMate doees give you the ability to exclude certain files (or directories) from your TextMate project, but it removes all references to them from within your TextMate project. This feature will speed up Apple-Shift-F searches, but sometimes you want to include those other files or directories.

The find command given the -name and -exec options can be a pain to type out. So I’ve written a helper script called findit.

findit

findit is a wrapper around find. It’s simple and fast. It’s usage is simple:

• findit where pattern

Maybe you’re looking for that view template which contains the text ‘Fuzzy Bear’:

1
2

zdennis@elijah:> findit app/views/ Fuzzy Bear
app/views//bears/new.rhtml:26:      <label for="fuzzy_bear">Fuzzy Bear</label>

Notice how you don’t have to use quotations around the arguments Fuzzy Bear. Everything after the first argument is treated as a part of the pattern.

Another example may be that you’re looking for where alias_method_chain is defined in rails. Well let’s look:

1
2

zdennis@elijah:> findit vendor/rails/ def alias_method_chain
vendor/rails//activesupport/lib/active_support/core_ext/module/aliasing.rb:23:  def alias_method_chain(target, feature)

So the power of findit comes from the fact that it’s easy to use and it handles most common occurrences of what a developer like me looks for such as the filenames that matched, the line numbers it matched on and a printout of those matching lines.

findit also ignores all .svn, CVS, .log, .project, .dylib and .o files. Of course you can change this though by editing the findit.

Download

Give it a try click here

findfile

findfile is similar to findit except that it only matches on filename patterns. The usage is still the same:

• findfile where pattern

Recently I had some issues with installing PostgreSQL from ports and there was a patch to the Portfile for the PostgreSQL port to get it to install correctly. I had no idea where the Portfile was so I let findfile to the work:

findfile /opt/local/var/macports Portfile | grep -i postgres

Download

Give it a try click here

locate | slocate

locate (and by extension slocate) may be one of the most under utilized unix tools in the mac world.

locate is used to find files by searching a database. Since it uses a database of file paths it is almost instantaneous whereas tools like find can take a while depending on how much files you have in a directory structure.

slocate can be thought of as “secure locate”. For more information consult this doc

Here’s the same example from findfile but this time using locate:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

locate Portfile | grep postgres
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql7/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql80/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql80-doc/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql80-server/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql81/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql81-doc/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql81-server/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql82/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql82-doc/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql82-server/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql83/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql83-doc/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql83-server/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/postgresql_autodoc/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/java/postgresql-jdbc/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-postgresql-exception/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-postgresql-greentrunk/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-postgresql-layout/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-postgresql-pqueue/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-postgresql-proboscis/Portfile
/opt/local/var/macports/sources/rsync.macports.org/release/ports/ruby/rb-postgres/Portfile

locate loses its usefulness when it’s database is out of date. Fortunately it’s easy to add it to cron. Here’s what I have in my /etc/crontab file to have slocate update it’s database every night at midnight:

0 0 * * * root /opt/local/bin/slocate -u

locate comes with Leopard, and slocate comes with ports. I have my locate aliased to actually run slocate. They use different databases so pick one and use it or alias one command over the other like I have. There’s not much of a point to have both slocate and locate.

If you decide to give slocate a try you can install easily by running:

sudo port install slocate

whatsmyip

whatsmyip is a script I use in my screen configuration so I can always tell what my local ip address is. ifconfig output is pain enough to look at and I try to avoid it at all costs:

1
2

zdennis@elijah:> whatsmyip 
en1: 10.0.4.100 en2: 10.37.129.2 en3: 10.211.55.2

Download

Give it a shot, click here

Programmer, Developer

on June 13, 2007 @ 03:16 AM

I used to think that I was a software developer based on the sole fact that I was paid to write code, no matter how crappy it was. Over the past few years I’ve realized that I was no more of a software developer as a guy who picks up trash on a construction site is a contractor.

I’ve noticed that alot of so called “developers” fall into the same camp that I was in. I’ve mentally made a distinction between a Programmer and a Developer. _This is much more generic dictinction of different types of coders then say an Apprentice, Journeyman or Craftsman is._

A Programmer is someone who codes. They don’t necessarily take into consideration a whole lot of things outside of fact of getting the job done.

A Developer is someone who codes with consideration. They consider:

• coding quality and best practices
• program design with natural decomposition
• testability, automated testing, manual testing
• readibility
• maintainability
• refactoring
• code performance (when its time to evaluate performance)
• teamwork
• responsibility to their customer and to their fellow teammate(s)

These definitions are influenced from object-oriented thinking and agile software development practices. You may completely disagree with them entirely. I’ve raised the bar for how I develop software. If it’s less for you then we just have different expectations of what makes a Developer. I’m ok with that. But, is your customer?

Ever since I started writing code I recognized that my potential was where I wanted to be. I could see the potential of what I could become and what I could accomplish. With this I had a genuine thirst for knowledge and I was eager to quench it. I’ve spent thousands of dollars and have read tens of thousands of pages from technical books. I’ve spent countless hours coding.

I spent too long of a time in the Programmer camp. I could have been much farther ahead early on given a few degrees change in direction.

So what was my problem? My problem had to do with the following goals when I first started:

• knowledge of multiple programming languages
• knowledge of different types of development: web apps, cgi, standalone,daemons, libraries
• coding speed
• all previous items as soon as possible

I wanted to know as much as possible in as little time as possible and I wanted to be able to produce results as fast as possible. A worthy goal, but the goals fell short of what is required of a software Developer.

When you learn as much as possible in the shortest amount of time with no regard to how you take that information and you end up learning only a small amount of what was there to be learned.

When you apply what you’ve learned as fast as possible with no regard to any of the aforementioned Developer “considerations” you end up making habits out of bad practices. And it will take alot of time and discipline to break them.

Developers take on a personal responsibility for the software they write. They don’t just value the end result. They value the entire process leading up to the end result and then they value the end result.

While Programmers continually apply bad practices, Developers provide consistently good practices. From what I’ve seen it goes like the following:

• while Programmers avoid testing to produce faster short-term, Developers continue test to produce faster and more consistently long-term

• while Programmers copy and paste over and over again to produce faster short-term, Developers refactor and create re-usable components to produce less buggy software, faster, long-term

• while Programmers avoid the use of decomposition because everything can be inlined to produce faster short-term, Developers use decomposition to provide a solution which makes more natural sense (this leads to more manageable, maintainable, readable and scalable code for the long-term)

• while Programmers often code by themselves to produce faster short-term, Developers value the input and ideas generated from other people to produce better and more correct solutions (this often leads to avoiding common mistakes from not correctly understanding the problem description and solution requirements)

• while Programmers often code 12+ hours several days in a row to produce more in a shorter amount of time, Developers work a sustainable-pace to produce more correct code in a shorter amount of time (when you’re brain is tired and you are tired you make mistakes, if you keep on coding you just dig yourself a bigger hole. Staying fresh with a sustainable pace minimizes this.)

• while Programmers commit to unrealistic customer expectations immediately, Developers communicate why the expectation is unrealistic and work with the customer on determining a realistic set of features in a realistic amount of time.

This isn’t to say that Programmers are evil coders. The term “Programmer” encompasses alot of people. These people might be:

• inexperienced,
• irresponsible,
• lacking discipline,
• or just bad programmers

Every coder starts out in the Programmer camp. Whether they evolve to the Developer camp is simply up to them. Who determines whether they’re out of the Programmer camp? They do.

Responsible Programmers quickly evolve into effective Developers because responsibility requires discipline and discipline does the right thing in any circumstance. The sooner you take responsibility for your craft as a software developer, the sooner you’ll enjoy the benefits of being a Developer.

Communication is essential

on April 12, 2007 @ 01:32 AM

Models [charts, diagrams, stories, graphs, etc] are valuable only to the extent that they facilitate communication among human beings. —David West

Communication is the most essential part of a project. Sometimes the artifacts that are generated to help facilitate communication end up hindering it. If the target audience can’t understand the artifacts you’re presenting them with chances are you need to stop trying to explain it to them and find something that they can understand.

the effort required to construct the model must be less than the communication value that arises from its user. —David West

I was once the project lead on a web-based project management application for a Fortune 50 company. The GANTT chart was deemed by the customer to be the most effective form of communication since everyone else in his company used them. In fact, they all used Microsoft Project to generate them.

We spent about six weeks of development per the customer’s direction integrating support to output an exact Microsoft Project GANTT chart replica. At the end of those six weeks the GANNT chart was canceled.

I don’t know why the GANTT chart was canceled for sure, but during the time of development we discovered that our domain experts and our customers didn’t really understand a GANTT chart. They sorta knew what it looked like because it was what they gave to their coworkers and bosses every few weeks to report progress, but they didn’t really understand what they were really trying to capture.

I think that once they understood what they actually wanted and what a GANTT chart actually was that it didn’t make sense to use a GANTT chart after all. But that’s just my speculation of course.

Tools like Microsoft Project are evil, mostly

I don’t like tools like Microsoft Project or any tool that locks you into their process for how you should do things. Or maybe it’s that I don’t like people who use tools but don’t understand how to use the tool or at least what the outputted artifacts (diagrams, GANTT charts, etc).

Thank you to people who don’t effectively communicate

I try to communicate effectively, and I try to constantly improve that communication. People who don’t either of these things will make my portfolio bigger.