Mentalbrew

Nickle and Diming Myself

2012-03-31T17:11:00+00:00

It wasn’t that long ago that spending money on something tech was often a big ticket item. While today there are still many expensive things to purchase (tablets, smartphones, etc) I’m finding that a decent chunk of my outgoing money is tied up in a bunch of little one-off purchases and subscriptions.

While I have found value in those things I have decided this month to cancel them all and find out which ones actually are necessary and which aren’t. I’m also scaling back on the one-off purchases for a month like ebooks (which I buy often) and such.

Why?

The biggest reason why is that I want to focus on my spending habits that are impulse buys and which add up over the course of a month. Many of these things are completely worth the price paid for them but I end up not utilizing the item or reading the ebook until a much later date if at all. I simply get it because it’s something I’m interested in and it’s cheap. What’s $5 dollars here or there right?

Another reason for the change in habits is simply this: without constant new items to keep my attention or distract me, I’m hoping to see a more focused approach to that which I am working on now. Many times I feel I’m running a mile-wide and and inch deep. Gaining perspective on what I should be doing and giving time to work on the things I want to do is a goal hindered by lack of focus.

From Here To There

I’m going to trial run this month and see how things go. See what’s improved and test the idea that I’m somehow missing out on something if I don’t have these subscriptions or items. Hopefully, reducing peripheral clutter will illuminate those things around me that are really important.

The Inflammatory Need Not Apply

2012-03-27T21:01:00+00:00

Yesterday I posted an article on something that I think could be improved and/or make a good addition to the Linux distribution world. I however, went about it the wrong way and worded it in a manner that was nothing more than inflammatory.

This, as you would expect, wasn’t well received by some and rightly so. Sometimes it is easy to forget that real people work on open source projects and they have feelings. It’s also easy to forget that open discussion on any topic should be voiced in a manner that invites discussion rather than shutting it down.

Years ago I decided on some simple principles for how I would conduct myself online and I thought I would share them here:

Don’t be anonymous - While I can respect a person’s right to be anonymous I personally feel that having my real identity associated with my words and actions is necessary toward my improvement as a person and openness with others. It’s easy to attack or deride others behind a veil of anonymity but becomes much harder when I can be just as easily scrutinized.
Don’t Delete - I’ve made it a point to never delete or edit a post I’ve made publicly. If I ever decide to edit something it would be for an addendum to my post and never to remove or conceal something I said. The few times I have removed something it was at the request of another person involved which to my remembrance has only happened twice and wasn’t regarding a personal opinion of mine nor denigrating anyone. What this means is basically there will be stupid things I have said that I regret or would word differently but I’m treating them as though they are spoken words which cannot be uncalled.

I have a new one after yesterday:

Be nice - Basically, treat others how I would want to be treated and encourage rather than discourage.

Hopefully, more thought will go into my future discussions and comments and more importantly, transparency as always.

Where Linux Needs to Change

2012-03-26T12:38:00+00:00

I got started with Linux around 1996/1997-ish. At the time I was completely fascinated by the fact that there was something out there that wasn’t Microsoft or Apple. I had been a Windows user my entire life and the idea that people would come together and provide a free operating system and related software greatly interested me.

So, over the years I investigated Linux and not that long after switched to dual-booting Linux and Windows. I’m still amazed that I was ever able to get things accomplished using Linux compared to where it was and what it provided when I started.

It wasn’t uncommon for me to switch distributions weekly to try out all there was in Linux. RedHat, SuSE, Slackware, Mandrake (Mandriva), and on and on. I became a master at backing up my home directory and re-installing an entire system within an hour.

I remember distinctly doing web development freelance work on Slackware, using Gimp for my graphics needs on the newly minted Gnome 2.0 desktop environment that I compiled from source by hand.

Eventually, I moved away from dual booting anything and simply used Linux as my one and only operating system.

So what I’m about to say is not coming from somebody who briefly used Linux and decided it’s not ready for the desktop. I believe experience-wise, Linux distributions can provide a great user experience for the newcomer and superuser alike. My relationship with Linux goes back over 15 years. I have used some distribution of Linux for my main and only desktop for over 12 years and every server under my personal management is running Linux. I really like Linux.

Where Things Broke Down

Having discussed my history with Linux some may be surprised that my most recent purchase for a new laptop was nothing other than a MacBook Pro. Why? Whhhhhhyyyyyy?! (think of George from Seinfeld shaking his fists in the air).

There are two primary reasons I switched to Mac for my development needs:

It was Linux/Unix -like. I can get most of the benefits of being on Linux and/or Unix that I’ve come to love. Having a solid command line option with all of the Unix tools I’m used to is a huge win for me.
I can manage my development requirements to my liking. It is not dictated that my entire OS version decides what specific version of something I need to run.

Of these two points, I would like to address the second one and how I believe Linux would be better off if things changed.

Choices Are Essential

I’m a polyglot developer. I work in PHP, Ruby, and some Java. I also work with software that is considered legacy and therefore need to manage my requirements with that. So I will often run multiple versions of PHP and Ruby.

Ruby has largely solved this issue with tools like RVM and RBENV. But the PHP issue remains and I don’t understand how it’s going to get any better.

Basically, my whole point here is that a version of a distribution, say Ubuntu 12.04, dictates a version freeze on every piece of software that is included in that distribution.

This applies to everything, not just PHP, which I am using in this specific instance. Because of how EVERY major distribution is designed, they all share one common flaw: Whatever version of software I receive by using that distribution will stay the same FOR THE LIFE of that distribution and trying to get newer versions of that software will only create headache and heart pain for the user.

You would literally need to wait for a newer version of YOUR ENTIRE OS, to be able to get an updated version of just one piece of software that is running on it.

This is stupid. Just plain dumb. The work that distributions go through to backport bug fixes and security updates for every piece of software on their release is a waste of resources.

There is no good reason why the OS needs to dictate what version of git, f-spot, LibreOffice, Tuxracer, or whatever I would like to run.

The Solution

I would love to see a distribution that did three things:

Provide a stable platform w/ bug fixes and security updates for the critical pieces of the operating system.
Provide a consistent framework for integration with third party apps and let the App owners take care of the rest.
Universal binaries that work across all multiple versions of the OS within reason. The FatElf project looks like a great step in this direction but GPL issues may interfere with that.

Conclusion

It is ironic that the Unix mantra of “Do one thing and do it well” is completely ignored and the standard practice for current distributions is to provide the entire kitchen sink, take-it-or-leave-it approach for the entire OS stack. This is asinine and unecessary.

Project Launch and Lessons Learned

2012-02-13T09:04:00+00:00

A little while ago I finished up a project developing a calling card website and store for my friend Evan Calkins at Hoban Cards. The business creates hand-made calling cards on one of several vintage presses he has in his shop.

This project turned out to be a great learning experience in several ways and the fact that I didn’t have to design the site, but only work on development as Evan is a designer himself was really nice.

Deploy, Deploy, Deploy

The first thing I tackled when working on the application was to get it deployable right off the bat. Even if it was nothing but a shell.

We were going to be hosting this on a Rackspace virtual server which I manage myself. Getting everything set up in a quick and easily deployable form took more time upfront but payed off quite a bit in the long run.

I was surprised at the benefits gained by simply having things easy to push out and be live. The largest noticible difference was that Evan and I could literally work side by side and quickly have our changes live as we iterated over the site. No messing with copying files, making sure permissions worked, database migrations, etc. Either of us could deploy at any given moment and rollback if things messed up. That opened things up for us to work on what was important at the time and not having to wait on each other to finish.

We found quite a few bugs earlier that only would have cropped up in production. Building our deployment meant we found these issues right away and could deal with them in the context of the release rather than as one big ball of ugly to fight with at the end of the project when things are really tight.

Use Pre-Existing Tools, Replace Later

One item I found to be very helpful was to utilize Twitter Bootstrap for both the frontend and backend UI. This allowed me to focus on the code and how things worked rather than dwell on where to put things and why they didn’t do what I want.

Once we were far enough along Evan was able to slice up his design and completely replace the frontend easily. Since bootstrap worked so well, and there was no driving reason to replace it we decided to leave it for the backend.

Git And Friends

The project would have definitely died without Git http://git-scm.com/. It allowed us to work separately on the application without stepping on each others toes. Should something come up that we both had worked on, merging took care of the differences and life was good.

Since this was a non-opensource project we hosted it privately using Gitolite https://github.com/sitaramc/gitolite. If you don’t have the desire to store all your private code in Github, hosting your own is relatively easy and the fined grain permissions make Gitolite a great asset in your toolbox.

Stripe and Paypal

The previous incarnation of Hoban Cards was a simple site with Paypal. While Paypal has served Evan well he despised the backend and having many international customers there was some concern about his options if Paypal decided to contest something.

So we decided to integrate both Stripe payment processing and Paypal, giving the customers the choice.

Since launching we’ve been pleasantly surprised that most customers chose the custom card processing and those that chose Paypal replied they only did it because it was easier than getting their credit card out. Most expressed that they did not care one way or the other.

Moving forward, Evan may choose to remove the Paypal option altogether.

Conclusion

This was not a big site or application by any means, which actually turned out great for developing a process of constant iteration. At the end of the day, the project was fun for both of us to work on, customers got a great purchasing experience, and Evan got a backend to manage orders and keep things organized.

Tools

Rails 3.2
Postgresql
Twitter Bootstrap
Stripe
Paypal
RapidSSL
Ubuntu
Rackspace Cloud Server
Capistrano

Web Development Is Not for Beginners

2011-12-14T22:09:00+00:00

This article will mainly be in response to another blog post I came across awhile ago here: Rails is not for Beginners; but is related to a larger topic I’ve wanted to write about.

The crux of the blog post was mainly that the overhead and complexities of Rails is so great that it’s making it harder for beginners to get started in web development.

I’m not going to disagree about it being hard for a beginner to learn rails but I think the underlying issue is not the framework but the entire industry.

When I started as a web developer (called webmaster at the time) things were pretty simple. If you had HTML3.2, a basic understanding of images and linking, and could figure out how to upload your files you were doing pretty well.

Over the years the entire industry has matured and started building more and more on those technologies to deliver more complex sites. My main point is that we are not developing the same websites we did 10 years ago and therefore what we now call web development is not for beginners.

Requirements

When I look at the staggering amount of technologies a person needs to know just to start out in web development it’s incredibly tiring:

HTML5
CSS
Javascript or at least jQuery
HTTP Protocol (get, post, redirects, status codes, etc)
Web servers (apache, nginx, or whatever for development)
Git/Mercurial (if you’re doing it right)
Browser quirks
Code editor (can’t get much done without one)
SSH/FTP
Server side language (php, perl, ruby, python, java, etc)
Frameworks (rails, zend, codeigniter, catalyst, etc)
CMS/Blogging (drupal, wordpress, refinery, typo3, etc)
Databases (MySQL, Postgres, sqlite, etc)
DB Theory (normalization, queries, etc)

This is just to get started if you want to be able to provide services to clients. Once you’ve picked your stack then you get the joy of maintaining knowledge of a moving target.

I haven’t even touched on what the ever growing mobile market is doing to web design/development and things that need to be considered for being accessible to everyone.

Tools

The article mentioned also touched on the size difference in the codebases regarding Rails vs Sinatra. Ignoring the apples vs oranges issue, the main thing that jumped out at me was the fact that while Sinatra might be a lighter, easier framework to learn, when you need it to do something beyond simple functions you’re going to need to write it yourself. That’s not so much a problem unless of course you’re a beginner and wouldn’t know where to start.

At least with Rails there’s a very good chance a solution exists out there that you can use without really have to get your hands dirty.

I’m not attempting to put down Sinatra as I think it is a great framework and has a strong place in a web developer’s arsenal, but things need to be weighed with what a person can develop with it if they have a beginner’s understanding of things.

At the end of the day, all of these things are tools and skill can only really be forged from experience and practice.

Keep on

Learning things is hard. I’m not writing this to discourage a person from being a web developer. But like developing any skill, you start small and build from there. Where I disagree with the author is that the point of difficulty for web development doesn’t fall in the design of a specific framework but even lower in the technologies that framework is built upon.

Fear of Failure

2011-10-31T21:04:00+00:00

As any good developer I’m constantly working on my craft to become better and more efficient. I study what others are doing, I subscribe to newsletters, screencasts, and any other information on web development that will inspire me to up my skills and stay motivated.

As such, I’ve found that even code I wrote just a few short months ago now seems stupid and embarassing to me. This wouldn’t be such a big deal if this same issue didn’t effect another aspect of my development: code sharing and publishing.

Basically, since I know that I’m probably not doing something the best way it can be done or in a manner that is deemed “proper” I fear putting my code out there for all to see. Risking that somebody who knows far more than me will call me on my amatuerish attempt at programming. In short I fear looking stupid.

This thinking serves no good purpose since the times that I have grown the most in any practice of discipline in my life was when I had the ability to learn from others and accept critique on my most recent work. Sharing my work and learning from others is a very critical step in the development of any skill.

What Can Be Done?

I was inspired to write this by a recent article I read from a developer who is well respected in the Ruby community. Basically he stated how his development process goes including the mistakes he makes and the bad decisions he made in the past. He even detailed how he didn’t follow exact procedures that the are considered “blessed” by the established leaders.

Fear is a powerful force. The worst type of fear is not that which is external but that which is internal. Your own fear is hard to defeat and can leave you paralyzed. Here are a few of the fears I face specifically in development:

Unknown - Sometimes I procrastinate on doing something because I’ve never done it before. It’s something totally new to me and perhaps I don’t even know where to start. There times when I can have several solutions to a single problem and fear selecting the wrong one even after a great deal of thought.
Monumental - There have been times I’ve literally been frozen in front of my screen trying to get started but I have no idea where to start due to the complexity and scope of the project. Breaking tasks down into small pieces and timeboxing myself usually gets me going in the right direction.
Criticism - I fear posting something I’ve worked on due to the possibility that I may be denigrated for doing it wrong or poorly. I will never know however how well I’m doing until others can oversee and give me feedback.

These are just a few of the things that hold me back. I’m sure you have plenty of your own.

The Solution

There are several keys I’ve found to overcoming these obsticles and getting over yourself to get things done.

Surround yourself with good people. A good person wants to see you succeed and will do what they can to encourage you. Be that person for somebody else as well. The learning goes both ways.
Surround yourself with difficult people. Putting yourself in a situation where you need to keep your game up is also very motivating if you have the right attitude for it.
Metrics, metrics, metrics. Set goals for yourself that you can measure and constantly check to make sure you’re meeting those goals. Keep records so you can be reminded of how far you have come. Re-visit old code and see what mistakes you made then that are obvious to you now.
Observe others. See how they work. What tools do they use? What philisophy do they follow?
Get it out the door. If you have a project that you are waiting on to be “just right” before releasing it to the world, stop, and push it out the door. Chances are nobody is going to care about your project at all let alone run through it with a fine toothed comb.

Conclusion

Fear of failure or rejection needs to be conquered. It’s dead weight that will hold you back from pursuing your dreams. Anything that gets in the way of progress needs to be dealt with. I’m actively working on dealing with those fears. If you recognize any of these traits in you then I would encourage you to sit down and make a plan to overcome them. Find what motivates you and move forward.

Using Rbenv to Manage Your Ruby Installs

2011-10-24T20:26:00+00:00

I’ve used RVM for quite awhile to manage my Ruby installations both on my development machines and my servers. Early on using RVM for production machines was pretty difficult, but support for everything I needed soon followed and life was good.

Recently, RVM has been challenged by a newcomer in the Ruby community called rbenv created by 37signals’ Sam Stephenson.

The Conflict

The introduction to rbenv was not without some controversy as the new project appeared to be derogative toward the work that Wayne Seguin had put into RVM. This naturally rubbed people the wrong way and led to some spirited debate regarding which product was better.

I really didn’t care at the time which was technically better as RVM simply worked for me. I never ran into the issues opponents of RVM stated regarding the overwriting of cd or the gem commands and such. My work never introduced me to any of these issues and the main feeling I get was that very few people did have actual issues, but those who simply did not like RVM were quick to use these things as another excuse to bash RVM.

One thing has led me to try rbenv over RVM and that was overhead. RVM introduces more complexity throughout your environment that has to be planned and accounted for when using the solution on your development machine as well as for production use. rbenv is simply a little closer to the metal and provides a similar workflow as RVM.

I would encourage a person to try both and see which they like most and why. Following is my installation and workflow that I use with my new rbenv install.

The Players

In typical Unix/Linux tradition rbenv is a single function utility that is best used when combined with other utilities. In my setup I will use the following:

rbenv - This provides the ability to switch between installed ruby versions by using “shims” in your environment path.
ruby-build - This utility actually downloads and installs the different ruby platforms as “definitions”. You can download and compile the ruby installs by hand that rbenv can then use but this simply makes it easier.

Setup

The first step is to clone the rbenv project into your home directory under ~/.rbenv like so:

bash console

git clone https://github.com/sstephenson/rbenv ~/.rbenv

All of your ruby installs will then be stored in ~/.rbenv/versions.

Next step is to add the rbenv path to your shell environment. In bash this would be either .bashrc, .bash_profile, or even .profile. If you are using Zsh you can place it in .zshrc or .zshenv.

bash

export PATH="$HOME/.rbenv/bin:$PATH"
eval "$(rbenv init -)"

You can now start a new shell or run exec $SHELL to use the new configuration.

This alone will give you the ability to switch between multiple ruby installs but ruby-build provides a nice, easy way to install these so you don’t have to do it by hand. To install ruby-build you first need to clone the git repo:

bash console

https://github.com/sstephenson/ruby-build

Now change into the ruby-build directory and run:

bash console

cd ruby-build/
./install.sh

If ./install.sh doesn’t work you may need to run it with super user priviledges like so: sudo ./install.sh.

Now you should have everything you need to manage multiple ruby installations.

Workflow

The first step is to install a ruby version of your choice. This is very easy with ruby-build:

bash console

ruby-build 1.9.2-p290 ~/.rbenv/versions/1.9.2-p290

That is kind of more work that I like to do and ruby-build makes it easier by adding to rbenv for easy local installation:

bash console

rbenv install 1.9.2-p290

The previous command takes care of where to install your ruby versions which is one less thing you need to remember.

Once I have a ruby version install I like to set one to be my global ruby interpreter for my shell sessions like so:

bash console

rbenv global 1.9.2-p290

Now you can test to make sure you have the correct ruby version by typing:

bash console

ruby -v

The Rehash Annoyance

One very annoying issue with rbenv is the fact that it needs to be told to rehash its shims after you install a new ruby version or any gem install that provides a binary. There is a solution in the works but until that is ready if you find yourself wondering why a command isn’t working when you just “gem installed” it, try running:

bash console

rbenv rehash

Per Project Ruby

If you have a project that needs to be configured to use a specific ruby version you can change to the project directory and type:

bash console

rbenv local 1.9.2-p290

This will drop a .rbenv-version file in that folder specifying the ruby you want. Anytime rbenv comes across a .rbenv-version file it will default to using that specified ruby version.

System Ruby

If you need to have access to the default system ruby for example to compile the Command-T extension for Vim you can simply type:

bash console

rbenv shell system

This command will tell your current shell that you want the system ruby version available. This will not effect other shells you have open or any new shells you create.

Conclusion

rbenv has a very low overhead for everyday use and follows the Unix/Linux tradition of doing one thing and doing it well. I purposefully didn’t touch on having gemsets as I’ve found with most of my projects using bundler I had no issues. If you need to have something comparable to RVM gemsets you can use the rbenv plugin created by Jamis Buck called rbenv-gemsets. It currently has issues on Zsh though to be aware if you’re using that for your shell.

All-in-all rbenv is a solid replacement for RVM. Aside from having to rehash the shims which should hopefully be resolved soon I currently find using rbenv a good experience.

Update - I forgot to mention and was reminded in the comments that RVM and rbenv are NOT compatible and you will need to uninstall RVM before moving forward. It’s a really easy process. Simply type:

bash console

rvm implode

This will remove RVM from your system. You will still need to go through your .bashrc/.bash_profile configs and remove any RVM information there.

A Simple Git Workflow

2011-10-11T10:00:00+00:00

In my previous post on git I covered the basics of how to host your own repositories for items you wish to not have on Github or that you simply do not want to have to pay for private repositories.

Today I will go over a very basic and simple Git workflow that easily works for small teams and is simple to keep track of in your head.

Basics

I like to keep my master branch production ready at any given moment. There are several reasons for this:

Many third party tools don’t need to be configured to work with the master branch as it’s almost always the default.
When somebody clones your repo the master branch is usually the default that they start with. Having master be the stable production branch is easier on them.

So, once we decide we want our master branch to be the production ready branch we then must move onto how we will develop our workflow.

Development

I normally start with a development branch when starting out and I don’t have anybody else working on the project for the moment.

When working in development I don’t concern myself with whether or not things are in a working state. The goal is to make sure any changes we are making live on the server and we don’t have a long time passing where changes are just sitting on the local development machine.

Since I am assuming the product is very young and nobody is currently working on it I initially use development to flesh out the workings of the application. Once things are good I then will get things passing and merge into master.

Getting The Ball Rolling

Now that we have a stable master branch and a development branch for ourselves this is where you can start implementing a team approach to working on the app.

Team members are encouraged to use a topic branch both locally on their machine and tracking on the server to make sure work is being backed up regularly. When their topic branch is done then they should merge into development. If everything in development looks good you can then merge into master and deploy immediately.

Deploying immediately is very important as you don’t want code sitting in master that isn’t being exercised in production. Only running in production will you know that the code works.

Assumptions

You may wonder why you don’t just make sure your topic branch is good and merge directly into master. This is totally fine if that’s how you want to manage things. With Git there is no ‘one way’ to do things.

I like having a development branch so things can be reviewed before being deployed. If you have people on your team who are not comfortable with deployment it’s good to have a process where you can oversee what’s going on in the system.

Walkthrough

So, assuming we have a local repo that is tracking a server repo with just a master branch we can create our development branch like so:

bash console

git checkout -b development

Then push that branch to the server and track it:

bash console

git push -u origin development

You can also create your topic branches the same way:

bash console

git push -u origin topic_branch

Eventually you’ll be all done with your topic branches you can simply remove them by typing:

bash console

git push origin :topic_branch

Conclusion

This isn’t the only right way to manage your development workflow. This isn’t a wrong way either. Pick and choose what will work best for your team and discuss it with them. You may find some things work great for your team and others fail miserably. The beauty of Git is it lets you choose. It also gives you enough rope to hang yourself.

Using the Pomodoro Technique for Development

2011-10-07T10:10:00+00:00

The deadline is looming, the project you’re working on is very complex, things are broken, and you have more features to implement. If you’re like me this kind of stress paralyzes your brain. You just stare at your screen willing some magical force to push your programming into action but the more you try to focus the more scattered things become.

It’s like trying to go to sleep because it’s late and you have to get up in the morning but you spend your time counting how many hours of sleep you’ll get if you could just fall asleep “right now”.

If this scenario or something like it has played out for you before I would like to introduce you to a system that has helped me get things back under control and structured.

The Pomodoro Technique

The Pomodoro Technique is a timeboxing practice where you list out all of the things you need to get done and priortize them not quite unlike the “Getting Things Done” system. The main difference here is that once you’re done making a list of items to be addressed you pick out all of the ones you think you can accomplish just for today.

Once you have your “Today” list done you then choose the most important of those items and prepare for a pomodoro.

A pomodoro is a unit of time which is usually 25 minutes for which you focus completely and solely on the task at hand. No interruptions, no email, phone, or even co-workers bothering you.

The goal is to get through the entire 25 minutes focused completely at what you need to do.

When the pomodoro is up you take a 5 minute break and spend time doing something unrelated to your main task. Get some water, go to bathroom, or whatever. Once your 5 minutes is up you start the timer again for another 25 minute time block.

How Does This Help?

Time is the thing in this life we cannot control. Everybody is alotted the same amount. By timeboxing your current activity your mind is allowed to train itself for sustained focus on a particular task.

Once you’ve started doing a few pomodori (plural) you’ll see the difference in how quickly your mind can get back on task.

Knowing that you only have to concern yourself with the next 25 minutes also relieves the subconscience of those nagging tasks that would normally occupy your mind and keep you distracted.

How To Get Started

All you really need to have to get started is simply paper for making a list and a timer of some sort. Kitchen timers work well but there are also timers you can get for Windows, Mac, and Linux which can help you keep track of finished Pomodori as well as set your chat applications to “Away”.

Conclusion

Do I use the pomodoro technique everyday? Nope. Although I really like it and find it very valuable I only turn to it when I’m having a hard time focusing or are very stressed about the mountain of work ahead of me and need to get things back on track.

At the end of the day it’s a tool to help you do better.

Hosting Your Own Git Repositories

2011-10-04T00:00:00+00:00

Coming from a background as a Linux administrator I manage my own development server. It’s a VPS that I pretty much store my development life on. Getting started setting up a remote git repository over ssh is not as straight forward as it is in mercurial or even svn. This is my technique for managing my own private repositories.

Requirements

Linux/Unix - Whatever flavor you choose.
Git - Installed on both the server and locally
SSH - You will need to have this installed and configured

On The Server

It’s best to decide where you want to store your git repos. I like using /srv/git for everything I do but you can pretty much place it anywhere you want. Even your home directory if you only need it just for yourself.

In this directory you’ll want to create a bare git repo with this command:

bash console

mkdir reponame.git
cd reponame.git
git init –bare

That’s pretty much all there is to it on the server end of things. Using git over ssh is super simple.

On Your Local Machine

On your local machine you will need to create a git repo and have at least one commit into it.

If you wondering why you couldn’t just clone your git repo from the server and start there, git won’t allow it as technically there is nothing in your server git folder yet.

If you have a repo on your local machine that has at least one changeset then you can add your server as the remote origin like so:

bash console

git remote add origin user@yourserver.com:/srv/git/reponame.git

Once that is done you can then push your local master to the server and you’re good to go:

bash console

git push -u origin master

The -u turns on tracking for that branch so git will notify you if you need to push back to the server after changes.

Conclusion

It’s pretty simple once you know that steps but if you’ve come from an Subversion or Mercurial background it doesn’t make much sense at first.

If you are running Redmine on the same local machine you can easily add your server git path to a project and browse your changesets through Redmine.

Rails 3.1, RSpec, And Cucumber Setup

2011-10-02T22:07:00+00:00

Getting a Rails project setup and running can sometimes be a tedious chore as well as different for almost every developer out there. This article will detail my most current setup of Rails for new projects. I, like many developers out there, try different things from time to time, so how I’m configuring Rails now will most likely be different not long down the road.

Tools

RVM - I use RVM for development. You can use whatever you like for managing your ruby installs but I’ve never had a great deal of trouble with RVM and I’m not remarkably impressed with the new kid on the block rbenv and ruby-build. Perhaps someday I will change.
Ruby 1.9.2 - Every new project I do is on Ruby 1.9.2.
Linux/Unix - I use Linux at home and Mac OS X at the office. Either of these will do fine. You can probably do this for Windows but I haven’t tried.
Rails 3.1 - I’m starting with the latest and greatest at the time of this writing.

Getting Started

Using rvm, create a gemset for your new awesome project:

bash console

rvm use 1.9.2@awesomeproj –create

Then, while in your newly created gemset:

bash console

gem install rails –no-ri –no-rdoc

The –no-ri and –no-rdoc prevents installation of documentation which can take a long time.

Once Rails is installed successfully you can then create your new project:

bash console

rails new awesomeproj –skip-test-unit –skip-bundle

I skip the test-unit stuff because I immediately install rspec and cucumber. Skipping bundler will make things faster since I’m going to be changing my Gemfile anyways.

Configuration

My next step is to create a .rvmrc file so RVM will know when we jump into the project directory what gemset and ruby version we would like to use. In the project directory run:

bash console

echo 'rvm use 1.9.2@awesomeproj' >> .rvmrc

Then cd .. and go back into the project and RVM will ask if you want to accept this .rvmrc file. Say yes and your good to go. On some systems this may be accepted by default.

Gemfile

Open your Gemfile and add this:

Gemfile

gem 'therubyracer'

group :test, :development do
  gem 'rspec-rails'
  gem 'cucumber-rails'
  gem 'spork', '~> 0.9.0.rc'
  gem 'database_cleaner'
end

What did this do? Your Gemfile is where you specify what external gems you would like to use in your Rails app. I’ve add the gem therubyracer so the coffeescript processor will work. There are several options available but this works on Linux and Mac. With the group block I’m saying that I want these particular gems to be available both when in test and development modes. Why not just test? Well, we need these gems to be available for :development so we can use their generators and other behaviors.

Once these are installed go ahead and run

bash console

bundle install

Once that’s completed we can then move on to configure RSpec and Cucumber.

RSpec

To install RSpec run:

bash console

bundle exec rails g rspec:install

From here on out every project command we need to run other than bundler itself needs to be run through the bundle exec command. This will insure our project only loads the gems we’ve specified in the Gemfile.

What the rspec:install command basically does is generate everything needed to start using RSpec for your testing. If you now run:

bash console

bundle exec rspec spec/

You should see the following letting you know that RSpec is at least configured correctly:

bash console

No examples found.


Finished in 0.00004 seconds
0 examples, 0 failures

RSpec and Spork

As you start the BDD/TDD process one of the things you’ll notice right away is the amount of time it takes to run your tests after each change. Since you should be alternating very often between tests and code it can be very draining and counterproductive to have the test load time take several seconds per run. Almost all of the overhead lies with loading Rails. Using spork you can load Rails once and keep it running, then only run your tests when needed which is a lot faster. To configure RSpec to use spork you’ll need to run the following:

bash console

bundle exec spork –bootstrap

Now, open your spec/spec_helper.rb file and remove the require ‘rubygems’ line since we are using bundler.

The next thing you’ll want to do is find the following block and copy everything after it.

spec_helper.rb

Spork.each_run do
  #…
end

Then paste the contents of that into the Spork block at the top of the file:

spec_helper.rb

Spork.prefork do
  #…
end

My spec_helper.rb looks like this (with many comments removed):

spec_helper.rb

require 'spork'

Spork.prefork do
  # This file is copied to spec/ when you run 'rails generate rspec:install'
  ENV["RAILS_ENV"] ||= 'test'
  require File.expand_path("../../config/environment", __FILE__)
  require 'rspec/rails'

  # Requires supporting ruby files with custom matchers and macros, etc,
  # in spec/support/ and its subdirectories.
  Dir[Rails.root.join("spec/support/**/*.rb")].each {|f| require f}

  RSpec.configure do |config|
    # == Mock Framework
    #
    # If you prefer to use mocha, flexmock or RR, uncomment the appropriate line:
    #
    # config.mock_with :mocha
    # config.mock_with :flexmock
    # config.mock_with :rr
    config.mock_with :rspec

    # Remove this line if you're not using ActiveRecord or ActiveRecord fixtures
    config.fixture_path = "#{::Rails.root}/spec/fixtures"

    # If you're not using ActiveRecord, or you'd prefer not to run each of your
    # examples within a transaction, remove the following line or assign false
    # instead of true.
    config.use_transactional_fixtures = true
  end
end

Spork.each_run do
end

Once that is done the only thing left is to tell RSpec to use spork in the .rspec file add the following:

spec_helper.rb

–colour –drb

Now run spork by simply doing:

bash console

bundle exec spork

Once spork is running your RSpec tests should be a lot faster.

Cucumber

Cucumber is far easier to setup with spork. To get started simply run:

bash console

bundle exec rails g cucumber:install –spork

Then start spork for cucumber:

bash console

bundle exec spork cucumber

The to run your cucumber steps:

bash console

bundle exec cucumber

Or just your @wip tagged scenarios:

bash console

bundle exec cucumber –profile wip

Conclusion

This is a barebones setup for Rails using RSpec, Cucumber, and Spork. I haven’t touched on adding factories like factory_girl or fabrication as this post is already a little long. Also, I’ve heard that spork may cause some headaches at times. If this is the case for you kill the spork process and run the tests without to see if the problem persists. This will let you know if it’s actually related to spork or something else that you’re missing.

I know that there are now application templates that you can provide to rails which will pretty much do all of the above automatically for you. I however like to configure things by hand. One reason is just part of the ritual of starting a green field app which can be an important part of the mindset. Another reason is simply that I like to know what is going on under the hood of my application. Should it break, I’m the one who needs to fix it after all.

Is RSpec, Cucumber, et al Making Testing Too Risky?

2011-09-28T00:00:00+00:00

Intentions

Let me first start this article with the premise that I am not trolling the Ruby on Rails community or trying to stir up a controversy. This is an actual legitimate discussion I’ve had with a co-worker recently as we determine what testing methods to use and why and was brought up again thanks to this article. Thoughtful discussion is encouraged.

Plethora of Testing Tools

One of the great things about the Ruby and RoR communities is their quick moving pace and the speed at which new and cool ideas get implemented. It could be argued that this is also a shortcoming of the Ruby community as many projects flare up in a bright light of activity only to burn out shortly after or abandoned if a newer shiny project comes along. Leaving adopters to fend for themselves at the next upgrade of their projects.

Testing has been the core of the Ruby on Rails community specifically and the community has some of the most cutting edge frameworks available due mainly to the awesome syntactic constructs Ruby allows.

With all of this has come a lot of projects aimed at making your testing and application behavior more efficient, concise, effective, or what have you. TDD, BDD, ATDD, and on and on the list grows of not only the styles (or pedantic approaches) of testing but the frameworks that go along with it.

While this no doubt leads the community into an almost craft-like mentality regarding code and how we develop elegant, beautiful systems I have to ask if this comes at a cost that can be sustained over time.

Does Complexity Introduce More Risk?

Minitest or Test::Unit come to mind when I think of simple testing libraries and in fact these ship in the Ruby standard library. I’ve read that the entire codebase to MiniTest is somewhere around 300 LOC.

Compare the relative simplicity of that codebase to one of the most popular testing frameworks out there, RSpec, which is very large and encompasses several smaller modules (Core, Mock, Expectations, etc).

While it has been shown that lines of code and project size don’t correlate with how well a framework is written it does increase the potential of errors and issues creeping into the framework as well as complicating the frameworks interactions in the project community around it (think mocking frameworks, capybara, etc).

Are these interactions getting so complex that it is harder to maintain a testing methodology due to the increasing complexity of both the system under test and the framework testing that system? This thought was particularily brought home by this article.

Have you ever spent more time figuring out a testing issue that had nothing to do with your code and more likely related to the complex interactions of your testing framework? I know I have. Chalk this up to inexperience most likely in my case but at the end of the day I didn’t exactly walk away with warm fuzzy feelings about my test suite.

Long Term Outlook

With testing frameworks getting larger and far more comprehensive, do we run the risk of building a large test suite for our application only to find that it is no longer supported just a few short years down the road. Does having to refactor your entire test suite still leave you with a good feeling about the solidity of your testing? Is there enough community support to carry a project on for the foreseeable future if the originators move on?

Conclusion

Change is a good thing. It often brings innovation and a new way of doing things. What attracted me most to the Ruby on Rails community is the constant drive of new and interesting projects. What worries me as a developer of long term projects is hitching my most crucial code (the test suite) to a project that may or may not be around for the long haul.

End Note

I should say finally that I use RSpec and Cucumber daily in my work and I really enjoy what RSpec has to offer over other testing frameworks. This isn’t a rant against any technology but simply a concern over what the future brings as our testing frameworks get more and more complex.

Finding More Time in Your Day

2011-09-27T00:00:00+00:00

It seems as life gets more automated, finding the time to do the things we really enjoy is getting difficult. Advancements in technology have more likely than not added more to our plate than existed before. Not to mention have limited our attention span and ability to focus on something intently.

The purpose of this article will be how, as a developer or small business, you can find more time to get things done that are important to you without sacrificing your family time.

I will also note that these are items I am working on right now and have seen success with. I can say however, that any failure I’ve had hasn’t been with these simple ideas as much as my inability to be consistent and disciplined with them. But each new day I start over and keep pressing on toward the goal.

Wake Up Early

Waking up early is probably the last thing most people want to hear but the benefits show themselves everytime. I am naturally a night owl and I am more likely to stay up late in a burst of activity than I have been to rise early and get some things done before work.

Why did I make the change? There are several reason why waking up early in the morning is preferred over bingeing in a late night programming spree:

Less Distractions - There are far fewer distraction early in the morning. I’m married with three young children. The morning guarantees some quiet time. While it is harder to get up at 5am the benefits are a more focused time to work on my projects.
Timeboxed - If you have a day job and need to be at work by 8 or 9 then you know that your time in the morning is valuable. You have a set period of time and you can focus your mind during this quiet hour to really focus on what you need to do.

Prepare The Night Before

Now, if you are like me you also probably recognize that getting up early in the morning can be eaten up by the most basic of tasks: getting ready for the day, eating a breakfast, etc. Here are a few things I do to minimize my early morning cost.

Pack my lunch the evening before - This will save you a lot of time if you simply prepare your next days meal the night before. Often I will do it immediately after dinner and just use leftovers from that or quickly make a sandwhich while I’m cleaning up from dinner.
Get your clothes ready the evening before - This may sound stupid or perhaps make you feel like a child but by preparing you clothes in the morning that is simply one mental process you don’t need to make in that early morning time.
Pack Your Stuff - Prepare what you need for work in the evening and stick it in your car (if you drive to work that is). Like I’ve stated before, do whatever you can to minimize your upfront.

Conclusion

There is a lot more that can be said on this subject but the basics are there. Take a step back from your day to day routine and see what can be optimized to improve the quality of your time. Analyze the things in your life that waste time or can be delegated out somehow. Make moves to do only the things that add value to your day and bring you closer to your goals.

Rebooting This Blog

2011-09-24T14:56:00+00:00

I am, once again, for like the eleventy-hundreth time, restarting my blog. I’ve realized over time that mixing my personal blogging with my development blogging doesn’t really serve either audience very well and leads to some confusing conversations.

Since all of my freelance and sidework projects go under the mentalbrew moniker, I’m going to reboot this blog for my technical, web development-esque content.

I plan on starting a new personal blog once I get the time.

My plan is to write about the things that interest me in web development and its surrounding industry. I also plan to write tutorials and series on specific technologies.