The questions and their results

• What versions of Ruby have you ever tried out?
• What versions of Ruby do you currently use in production or for real apps?
• What testing frameworks are your active projects using?
• If you were starting a new Rails project right now, what testing frameworks would you use?
• What mocking/stubbing frameworks are your active projects using?
• If you were starting a new Rails project right now, what mocking/stubbing frameworks would you use?
• What do your active projects use to populate testing data?
• If you were starting a new Rails project right now, what would you use for populating testing data?

What versions of Ruby have you ever tried out?

Summary: a wide variety of Ruby versions used. What the heck is kiji, you might ask? This was a useful post on kiji.

What versions of Ruby do you currently use in production or for real apps?

Summary: Mostly 1.8.7 and 1.9.2 in production use right now. REE is production-ready. Tweet

What testing frameworks are your active projects using?

If you were starting a new Rails project right now, what testing frameworks would you use?

Conclusion: Expect to see MiniTest in more production apps in the future. Tweet

What mocking/stubbing frameworks are your active projects using?

If you were starting a new Rails project right now, what mocking/stubbing frameworks would you use?

Conclusion: RSpec mocks are here to stay. Tweet

What do your active projects use to populate testing data?

If you were starting a new Rails project right now, what would you use for populating testing data?

Conclusion: Factory Girl and Machinist are going to remain popular. Rails fixtures are hanging around. Tweet

The Data Source

Here is the spreadsheet of results (with contact information and bad rows stripped). I didn’t spend very much time making killer visualizations, and there are some great comments in there. Highly recommended to get a feel for what people are using. Someone else could probably create a correlation table of common tool sets. For example, showing that people who use RSpec commonly use a certain mocking framework. Also, there is geographic info there, so we can see which region is on the cutting edge…

Edit: A note on the charts. People could respond with multiple answers, and I just tallied the answers for each category. For example, if 50 people said they used 1.8.6 and 1.8.7 and 50 people said 1.8.7, 1.8.7 would get 2/3 of the chart (100 “votes”), and 1.8.6 would get 1/3 (50 “votes”). The graphs could have been clearer, feel free to create a better visualization with the data. Thanks to the Hacker News commenters for bringing this up.

Logistics

I took the data, and filtered it with this script:

#!/usr/bin/env ruby
 
types = []
File.open(ARGV[0]).each do |line|
  line.strip!
  types += line.split(", ") unless line.length == 0
end
 
counts = Hash.new(0)
types.each do |type|
  counts[type.downcase] += 1
end
 
counts.each do |key, value|
  puts "#{key}\t#{value}"
end

Then, I put it in an Open Office spreadsheet, cleaned up the data a bit and sorted by the number descending. I should have probably outsourced this task, as it took awhile to get things looking right. It was terrible getting the chart images out of OO though. Had to copy to Draw, then export selection to an image file…

What did I miss?

Is your favorite testing framework not represented here? I left out some frameworks that only one person said. Check the spreadsheet for all of the data and some great comments. If you want to fill out the survey after having read this, go ahead and do so here. I might update this blog post at some point in the future or create a second one with updates…

What else could I have done, and do you want to be notified when future surveys take place? I’d imagine something in my survey process could have been improved. Leave a comment or email me at panozzaj@gmail.com!

Original article: The State of Ruby and Testing

However, it was tough to think about what needed to be abstracted out of the solution that I was going to use. What I did was to copy the original to another area, change it to work in that context, and then factor out the common parts as best as possible to a library function. I expect to use this function a few times, so this seems to make the most sense from a flexibility and maintenance perspective.

Copying allowed me to clearly see the similarities and the differences so that I knew where the seams were. Just doing it in my head was not as helpful. I was overthinking it, and came up with a couple of solutions at first that were suboptimal. Then, I said, “whatever, just get it done and I can refactor from there.” That seemed to be a better solution. Also, I felt that I did not overgeneralize the functions when I used this approach. This is a positive, as when I overgeneralize, the code becomes harder to work with in the future.

Note that I did indeed go back and reduce the duplication. Pushing it out to a nebulous “sometime” would have been quite ineffective. Instead, I promised myself “in half an hour.” I felt good about keeping this promise to myself.

I guess the lesson I learned was: use the materials you have to help you on your way. Whether this is temporary image files when you are preparing your website overhaul, or scraps of paper or whiteboard space, getting ideas out in physical form lessens the load on your mind. See also my post on streaming, which I still use on a daily basis.

Do you have any rules of thumb for this type of situation?

Original article: Write-Copy-Fix-Refactor

Life is suffering.
The origin of suffering is attachment, due to ignorance.
The cessation of suffering is attainable.
The eight-fold path leads to liberation.

I was coding happily along, and realized in a flash of insight that this applied to what I was working on.

In coding, suffering comes from:

• not being comfortable making a change because you don’t quite understand how the system works
• working hard but realizing your code is still buggy
• a client being less than impressed by “a change that couldn’t break anything”, but did
• not being able to refactor because you can’t see all of the implications
• wondering if this ever really worked at all
• having that bug pop up again, although we thought it was fixed
• not delivering with quality and on time

The Four Noble Truths of Coding

Coding is suffering.
The origin of suffering is attachment, due to ignorance.
The cessation of suffering is attainable.
The path of executable specifications leads to liberation.

This is a bold statement to make. By using automated means of capturing the assumptions present in code, one breaks the painful cycle that comes from ignorance about the code base. Coding then becomes not suffering, nor not-not suffering, but just coding. Instead of coding in fear, it again becomes a creative process that encourages working with others in harmony. With automated tests of some sort, instead of having the law of cause and effect operating over the course of months, weeks, or days, feedback operates instead in terms of minutes.

However, there is a middle path to take here. If one is entirely safe, one loses the creative edge that makes the project exciting and lessens nimbleness with too much process and boilerplate. If one is too loose, one stands to let some quality slip. Experience seems to be the best guide.

This thought probably emerged from reading philosophy and Working Effectively With Legacy Code.

Original article: The Four Noble Truths of Coding

// connect to database
code
code
code

This might be an indicator that you can extract the code under the comment into a separate method to make things clearer and more modular.

For example:

public Connection connectToDatabase(necessary parameters) {
    code
    code
    code
}

This is nice because it is just as readable, and it’s harder for the description of the code block to get out of sync with what the code actually does.

Between when I thought of this and when I actually published it, I read a similar blog post that confirmed this thought pattern. Fowler also talks about this in Refactoring.

Original article: Refactoring Tip

Let us start with the first source of technical risk, the high-risk subsystem. Which subsystems have high technical risk? To assess this we must perform our project-level analysis to determine how each program objective (expense, cost, performance, and speed) will impact profits. Then we assess each subsystem to determine how it might impact each of these factors. The easiest way to do this is to use a team meeting in which members estimate the downside risk for each subsystem in terms of magnitude and probability. This can be done by having each member assess risks independently, having a discussion on why different team members have rated risk differently, and then having team members reassess risks. The output of such a meeting is a surprisingly good understanding of project risk. Contrary to the common view that unknown risks are most important, most teams are surprisingly aware of where they are likely to fail in a program.

This reminds me so much of the Agile practice of planning poker that I’m dubbing it “risk poker”. Both practices make sense to me because they use crowdsourcing to solve the problem. I think software teams are more aware of the risks on the project than they typically give themselves credit for, leading to the paradoxical value of this practice. By doing this practice, teams make explicit the knowledge that they already have but are often hesitant to act on for one reason or another.

While doing some basic research to see if this term had been employed yet, I also stumbled across protection poker, which deals more with security risks.

Perhaps I’m reinventing the wheel and risk poker is a well-known concept with a different name. Has anyone employed something like this on a project?

Original article: A Tool For Your Toolbox: Risk Poker

Experience

I’ll admit that I got a mulligan. It was a Ruby on Rails project for an internal tool. I hadn’t worked with that technology stack much before. I kind of hacked something together based on the requirements, and it worked fine. There were few tests, and the design definitely did not use best practices. But it worked.

Next, I worked on a six-month-long Rails project using mostly TDD. After that, an opportunity arose to clean up the internal tool and add some features.

It felt really good. I felt like I knew the environment so much better, and could see where problems in the code could be easily solved using better Rails or Ruby techniques. It was quite exciting. At times, I was surprised that the code actually worked at all. I think that most developers rarely get this type of opportunity unless they are on a maintenance project, and I do think it was a valuable experience to see the aftermath of my own coding.

Synthesis

But afterwards I came to the realization that developers shouldn’t feel guilty about producing software. There are always going to be new technologies and practices to learn, tradeoffs to be made, and hindsight clearer than the present view. Should I refactor this class now or later? Should I make this easily extensible, or are we truly not going to need it? What should we work on first to reduce the technical risk on this project?

After every book I read on a subject, I learn new techniques and ways of thinking about problems. But this shouldn’t stop activity in the present. I will never have one hundred percent of the knowledge I need, and the solutions that I come up will only satisfice the problem.

I’m assuming that developers are really putting their best effort forth. This doesn’t absolve the developer from learning from their mistakes or preemptively learning.

I’m just trying to say that developers shouldn’t feel bad because they didn’t know enough to prevent every problem or solve every dilemma in the best way possible. Seeing mistakes in the past for what they are just indicates growth. Getting it right every time implies skill stagnation or perfection. Which one is more likely?

Have you had an experience where you wish you could go back and change something on a software project? A time when you read your own code and cringed? Where’s the balance between getting things right and getting things done? Consider leaving a comment!

Original article: Guilty Developer Syndrome

// TODO: implement the foo module here
...
// HACK here be dragons
...
// XXX
...
/* FIXME:  late at night, I need some sleep */
...

One advantage of using these tags is that they are easy to search for and give an understanding of where the code can be improved. Most IDEs even have a special view to look for these kinds of things.

My personal view is that writing a comment like these basically says that I should do something. If it gets checked into source control then it’s a problem. I should either address this right now or create a task to address the problem in the future. In the rare case that something is urgently broken, it’s best to fix it and then immediately figure out the root cause and any ramifications, when the problem is freshest. Delaying just adds a time cost to whoever tries to fix this in the future. Maintainers need to ask, “Is this still relevant or important, and how do I fix it if it is?” The second option is to put TODOs into a standard tracking system for later analysis instead. What seems urgent to fix at this time might not matter much in the greater scheme of things, so this work should be prioritized like everything else.

TODOs are definitely not acceptable for commenting out large swaths of code that break the build. The build exists for a reason–use it as a tool for creating higher quality integrated code. If your code doesn’t integrate, it’s your problem to fix it immediately. Commented-out tests are worse than useless because they add to the codebase and are not kept in sync with the main development line.

As a tangent, I usually write a date and author in comments. Even though people can use repository annotations (svn/git blame/praise), it’s much easier to see how relevant this comment is.

// AJP20021116 - I'm not sure that this works for all values of N.

Hence, if you were working on a project and saw this comment, it’s clear that it immediately is probably out of date or just not that important if it hasn’t been fixed in the past eight years. If I’m still around, future developers can ask me to recall what I was thinking.

What are your thoughts? Do you use TODOs in your code? What do you use them for? Do they make maintaining a project easier or harder?

Original article: TODO: FIXME, HACK, and XXX

The staging environment provided by Git means that I have a local version control system that no one else can see. This allows me to take continually check things in without worrying about mucking up the general repository. I like this because I can make changes quickly and check in whenever I make progress and things mostly run correctly. This is great because I hate it when things are improving and then I make some boneheaded change to a bunch of files and can’t figure out how to get back to a working state.

When I’m ready to check into the shared repository (in SVN), I can do this as a separate operation. What’s nice is that I can squash, modify, and reorder local commits so that my development history is clean of the rabbit trails that inevitably pop up. Theoretically, the staging environment allows me to not need to run full test suites before locally committing to ensure that I don’t break the build. This was not really a gain that I utilized though.

The second advantage was quick local branching capability. This allowed me to have several streams of development going that were mostly independent of each other. This was invaluable for quick bug fixes, and helped when work was blocked due to a client member being unreachable. Another great advantage was the ability to have my master branch be clean and always be ready for a demo. Git branches differ significantly from SVN branches, in that they are much faster to work with, require less space, and, perhaps most importantly, Git offers better merging capabilities.

Everyone else on your team can still use SVN normally, and you will see their changes if you use the correct workflow. There are numerous sites that describe this workflow and variations of it, so I won’t detail this. Just Google ‘git svn workflow’.

Issues

Attention conservation notice: heavy Git nomenclature to follow, probably not useful for the casual reader.

I ran into a couple of problems that I’d like to discuss, and my final solution. One issue was that I developed for quite awhile in Git and then needed to put this into the client’s SVN repository. There are numerous risks that I should have mitigated by doing this as I was going along with the project. I did not commit against my better judgment because I thought that my code structure might change significantly. However, it never really did. In the future I won’t hesitate to do this now, as the pain of messing around with version control is not really all that high.

I initially was interested in keeping my development history around, but this turned out to be pretty hard based on some specific things that I did. I think that the main reason for this is that I wanted my commit messages to have the correct name and email. I’m pretty sure I changed this setting in ./.git/config, but something must have gone awry. Hence, I ran a one-liner at the command line similar to the following:

git filter-branch --env-filter "export GIT_AUTHOR_NAME='<my name>';
                                export GIT_AUTHOR_EMAIL='<my email>';
                                export GIT_COMMITTER_NAME='<my name>';
                                export GIT_COMMITTER_EMAIL='<my email>'" HEAD

However, when then subsequently running git-svn commands, I received this error: Can’t call method “full_url” on an undefined value at /usr/lib/git-core/git-svn line 425.

My understanding of what this error means is that git-svn can’t find a join point between local development and your remote branch. Running the git-svn init or clone commands sets this up correctly, but what I was doing messed it up. I think I lost quite a bit of time by not understanding that rewriting the history at the end (which I typically did) would cause git-svn to get out of sync. I also messed around with grafts for awhile, which probably didn’t help matters any. I think in retrospect I probably should have only rewritten commit history for commits that I did locally, and not mess around with grafts at all. This would have probably allowed me to just `git svn rebase` to keep my history and have a flurry of checkins with the right information. But at this point, I was alright with losing my development history since I had already spent a bit of time working on it.

Once I was ready to import my changes, I found the following process to be helpful. Basically I add SVN directories, sync with these directories, copy over the files in master from my local directory, then commit the changes and dcommit to SVN. First, let’s add the standard SVN layout to the SVN repo. If you’re worried about messing something up, doing this process locally first is helpful, and then doing it to a sandbox directory might be advisable. See this page for an example of the former.

> svn co <repo/folder>
> cd <folder>
> mkdir trunk tags branches
> svn add trunk tags branches
   A         trunk
   A         tags
   A         branches
> svn commit -m "Base directory structure."
   Adding         trunk
   Adding         tags
   Adding         branches
   Committed revision 1.

Then in a clean directory, you can execute:

# the --prefix=svn/ gives you remote branches prefixed with svn/
# which helps to namespace them
> git svn clone <repo/folder> -s --prefix=svn/
   Initialized empty Git repository in <folder>/.git/
   Using higher level of URL: <repo/folder> => <repo>
   W: Ignoring error from SVN, path probably does not exist: (160013): Filesystem has no item: File not found: revision 100, path '<folder>'
   W: Do not be alarmed at the above message git-svn is just searching aggressively for old history.
   This may take a while on large repositories
   r1 = <treeish> (svn/trunk)
   Checked out HEAD:
     <repo/folder> r1
> cd <folder>
> git branch -a
   * master
   svn/trunk

I’d modify your .git/config file to have the correct username / email if necessary at this point.

Then you can copy all of the files from your original working directory (the one where you did all of the development) except for the .git directory. If you copy this over, you’ll have to start all over again. At this point:

> git status
   # all of your files
> git add .
> git commit -m "Changes from my local repository."
   Created commit <treeish>: Changes from my local repository.
   ...

And finally:

# in case someone updated the SVN directory that you're working with (unlikely)
> git svn fetch
> git svn dcommit --dry-run
   Should see something about pushing to <repo/folder/trunk>
> git svn dcommit
   A file1
   # etc....

This should add your files in the trunk folder in the SVN repo. Hope this helps!

Original article: git svn

'abc' =~ /c$/     => true
'abc' =~ /a$/     => false
'abc' =~ /^a/     => true
'abc' =~ /^c/     => false

I can remember what the anchors are. When I have trouble remembering which is which, I use the following mnemonic:

Regular expressions are perfect, like the Garden of Eden.
Snakes end the Garden of Eden.

In this case, the dollar sign looks a lot more like a snake than the caret does, so it’s the ending anchor. This might be corny, or perhaps not completely accurate to the original story or the true nature of regular expressions (hairy beasts that they are), but it’s served me pretty well.

Original article: Regular Expression Anchor Mnemonic

Here’s a real-life example that likely took place over the course of a couple of hours:

control_parsing
 Go through documents and figure out what appropriate values would be for the metadata and the control data to get it out
  Given a standard document, the ability to correctly parse out the fields
   Given a patient identifier, find the matching patient
    What API call do I use for this?
     Where is the system id of 387 coming from?  I could swear I've seen that before
      I don't think it's actually used, I think that we just use the patient identifier and the user's institution id
       Pretend we are calling the API call with the known patient identifier and user's institution id to ensure that I have the right mental model

Process

I use vim to type out my thoughts and save them a text file. I could see marking things off by putting ‘#’ at the beginning of the line, which for me would gray the line out, but normally I just delete things when I get done. This results in a nice feeling of crossing things off of the list. If I’m in the heat of solving a problem, I often don’t write or delete lines. But when I come to a stopping point or am considering what next to do, I usually write out what I am thinking. This minimizes overhead and preserves flow.

A Tangent

The subject in the first line is the git branch that I am currently working with (I typically use description-datetime-created as the branch format.) If there is a need to switch branches, then I keep this stream around to remind me of the current state of the problem.

A script named cb (create branch) is how I usually create branches now with git:

#!/usr/bin/zsh
zmodload zsh/datetime
git checkout -b $1-`strftime "%Y%m%d-%H%M" $EPOCHSECONDS`

Then `cb branch_name` results in a new branch called branch_name-YYYYMMDD-HHMM. If there is an easier way to query the time a branch was created, I’d be interested to hear it.

Benefits

Constantly specifying the next thing that I need to do or resolve has the benefit of keeping me conscious about what I am doing. While I saw this with the pomodoro technique (“how does what I’m doing relate to the current pomodoro?”), this makes the process more explicit. I can easily track my problem-solving process and see where I might have gotten into some rabbit holes. Sometimes I just find myself looking at a file and realizing that I have no idea how I got there. Whenever I find myself in that situation, I immediately switch to the stream file and reorient myself to the problem I’m currently trying to solve.

Another benefit of the streaming technique is being able to jump back into problem solving after breaks and interruptions. There are times when I can come back to the computer and see where the cursor is in the file and know the next thing to do, but it normally takes awhile to load the problem into my head. Reading through my thought process seems to decrease this ramp up time. Perhaps just writing down how I am approaching the problem makes things clearer for me the next time.

It seems like the problem solving process can generally be best represented as a stack, so I try to reflect this with indentation. Sometimes it forms a bit of a tree structure, but this is likely a problem-solving smell. If a new line does not fit cleanly under the main heading, then I examine the new direction carefully. As a result, I tend to be more aware of when I am considering something that might increase work in progress. Perhaps this task should be considered later, or maybe I should create a new branch before trying to implement this change. Seeing a very long chain of things might indicate that I have too many questions or am not breaking work up effectively.

Like I said, it’s new, so I haven’t worked out all the kinks. But so far it has been well worth any trouble. Let me know what you think if you try it out for a day!

Original article: Problem Solving Stack