Tag Archives: Ruby

Boiling the Ocean (or Attempting to Keep Up With Tech)

I was asked by a fellow developer how I keep up to date on the variety of technologies that I’m expected to understand when doing my job. I intended to write a short answer, and generate a blog post as a longer answer. I got this idea from Scott Hanselman, who in his talks about productivity mentions saving keystrokes, and the idea that when you answer a question for someone, you should share that in a way that is useful to you and others. With that in mind, here’s the advice I would give if you find yourself taking on a job that requires a broad knowledge of the technology and software.

Question: Somebody in your position obviously needs to understand a lot of technologies to be able to pick the best solution for a project. How do you approach learning and having an understanding of all the new stuff that is constantly coming out? Obviously you can’t sit down and learn every tiny detail, but do you just obtain a high level understanding of how things work and then flush out the details once you start a project in a technology that you’ve never used before?

I use Google Reader a lot, I just checked and I have 121 rss/atom feeds going into it. They are not all work related, and it’s not like I read every article. But I star stuff I want to read, or put it in Instapaper and then go back to it. I try to read a mix of updates on what I already know and interesting things about what I don’t.

As for how to learn and retain, and relate technology, that is a harder question. I’d love to tell you that you just get a high level exposure first and then fill in the details when needed, but my mind doesn’t work that way. I hated classes like Systems Analysis in college that only talked about systems in generic terms, because I couldn’t relate those terms to specific examples.

My own take is that in the beginning of your career, you just have to learn practical skills and learn the tools you work with well. When you start wanting to learn about systems and being able to evaluate, compare, select, recommend, etc, then you pick up as follows:

Let’s say I’ve never used a database, and I’m assigned to work on a project that will use Ruby on Rails and PostgreSQL. Take the on the job time to learn the tool as well as you can, focusing on the aspects you need for your job. Where possible, try to understand and separate product names / features from conceptual names / features. In this example, that means understanding what database and schema mean in generic terms, and why they mean different things in the PostgreSQL than they do in some other products (like Oracle or SQL Server). Spend a little bit of off time playing around with an easily attainable (usually open source) alternative. Spend a night or two doing those same types of tasks in MySQL. You’re not looking to be a dba, just doing similar tasks as to what you do. Finally, talk to people who use other products and compare. This works great with products that are hard to get a hold of because of cost, etc. In this example, talk to an Oracle DBA or App Developer. What features do they like about their product that would prevent them from switching. If you don’t know one, ask the question online. Quora, LinkedIn, Twitter are all great places for this kind of question.

At this point, you’re out of work time (so not counting your project time working with PostgreSQL because you would have done that anyway) is 4-6 hours on MySQL and maybe another hour in conversation. But you should have a really good idea of the concepts surrounding relational databases.And you should know what the different projects compete on in that arena and what some of their strengths and weaknesses. If you spend time away from that field and come back in, you should have the conceptual understanding and just need to buff up on the implementation details and latest trends.

Two other quick pieces of advice. First – After getting the practical experience on a type of tool, read the Wikipedia page. Most pages are at most a 15 min read and they lay out the purpose and strategy behind any tool type, and usually list the major players in that area. Second – Try to keep personal opinion from having to much sway. We all prefer different tools, but every tool can be criticized. That’s important to do, and know it’s weakness, but don’t dismiss the tool outright. They were built for a reason, a context. And many of the weaknesses relate to some tradeoff the programmers / vendor made that has a good reason behind it.

A Comforting Warning About Agile

“Beware of becoming an Agile zealout, because this can backfire and put people off. Don’t treat people who are not applying Agile as fools who just need to see the light! This is disrespectful, and people simply won’t listen to your rants.” -Rachel Davies in Agile Coaching1.

Why is this comforting? Good communities self-monitor. Many of today’s communities with momentum have some ego issues. Communities like Agile, Ruby and Mac folks. All three of those communities are great and everyone should be learning more about them, so this isn’t meant to start a flamewar. But what comes off as passion in an upstart community can be obnoxious in an established community. And it certainly doesn’t fly well with the 2nd and 3rd tier adopters that are often the target of such zealotry.

This isn’t an excuse for half-assed Agile. Go for “full-assed” commitment to whatever system a team uses, and in more cases than not, they should be doing a flavor of Agile (usually lean) throughout the software lifecycle.

But blind assertions and a condescending tone won’t win anyone over. No matter what is being sold. This can be a particularly hard trap to avoid when a person or their business are sold as Agile experts. Or… “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” –Maslow

When leaders and authors in the community stand up for moderation, it is a sign of maturity.

  1. Note that Agile Coaching is written by Rachel Davies and Liz Sedley, but Rachel Davies only is cited above as the quote is in a “Rachel says” section.

Rake Tasks For NuGet

If you use NuGet, and only check-in your packages.config files to source control, then your source control repository will stay smaller, and checkout faster. Checking in binaries is usually a nice thing to avoid. However, you need new developers to be able to get those libraries locally easily, and to allow your build server (continuous integration or otherwise) to keep libraries up to date.

After all, that’s one of the advantages of NuGet, you only download a new library when you first need it for that solution, or when you change versions.

In order to solve this problem, I use a rake task, as we use rake for other setup tasks (creating or seeding databases, continuous integration, etc). Rake may sound like an odd choice for a .Net environment, but it’s very good for customing cmd line tasks, and all the .Net building and setup we have run into can be done from the command line. Anyway, assuming the directory structure below, I thought I’d share the Rake tasks…

MySampleProject
|-Rakefile
|-tools
 |-NuGet.exe
|-Source
 |-Packages
  |-NHibernate
  |-MassTransit
 |-SampleProject.Web
  |-packages.config
  |-SampleProject.Web.csproj
  |-other files, etc
 |-SampleProject.ServiceBus
  |-packages.config
  |-SampleProject.ServiceBus.csproj
  |-other files, etc

Relevant tasks in the Rakefile below. Note the ci task using nuget task before it builds.

def nuget_for_project(project_dir)  
  sh "tools\\NuGet.exe " + 
    "i Source\\#{project_dir}\\packages.config " + 
    "-o Source\\Packages"
end

namespace :nuget do  
  desc "nuget for servicebus"  
  task "ServiceBus" do	
    nuget_for_project "SampleProject.ServiceBus"  
  end    

  desc "nuget for web"  
  task "Web" do	
    nuget_for_project "SampleProject.Web"  
  end  
  
  desc "nuget for all"  
  task "all" => ["nuget:ServiceBus", "nuget:Web"]
end

desc "continuous integration task"
task "ci" => ["clean", "nuget:all", "build", "test"]

Rake Breathing New Life to Building Old Projects

I’ve seen lots of examples of rake (the ruby make replacement) being used as a build tool in non-ruby projects. Many of these are still modern platforms, like .Net. For example, StructureMap builds with rake. But I’ve found that even on older platforms, the power of having a full programming language in your build tool is useful.

Recently, I was working through examples in Thinking in C++, and there is the need to build many small one file examples. I started writing a Makefile to simplify this, and decided to try rake instead.

The power of a programming language brings a lot to table when doing repetitive tasks. Check out the following Rakefile which generates a build, run, and clean method for each file listed in an array. And there are aggregate methods which will run or clean all.

exe_name = ["hello","c_in_cpp","file","vector"]

exe_name.each do |f|
  desc "clean #{f}"
  task "clean_#{f}".to_sym do
    sh "rm -rf #{f} #{f}.o"
  end

  desc "build #{f}"
  task "build_#{f}".to_sym => "clean_#{f}" do
    sh "g++ #{f}.cpp -o #{f}"
  end

  desc "run #{f}"
  task "run_#{f}".to_sym => "build_#{f}" do
    sh "./#{f} 2> error.log"
  end
end

desc "run all"
task :default => exe_name.collect{|f| "run_#{f}"}

desc "clean all"
task :clean => exe_name.collect{|f| "clean_#{f}"}

If any of the above is unclear, and you want to see the output, do the following: copy and paste that code into a file named “Rakefile”. Run “rake -T” to lists all available tasks. You won’t be able to actually run the tasks, unless you have the appropriate cpp files in the directory (ie “rake run_hello” requires hello.cpp).

If you want to learn a build tool, and know ruby, or want to learn ruby rather than some specialized build language with no other uses, give rake a shot.