Showing My Commits

The first thing I needed was to only show commits that I had made and ignore commits from author developers. The --author argument allows you to specify a pattern or string to match against commit authors. git log --author="Jason Gilman" will show just my commits. I wanted a git command that I could share with other developers so I didn’t want to embed my username in it. Your git author name comes from the .gitconfig file in your home directory. It can be retrieved with the command git config user.name.

I’m also only interested in the commit date, hash, and message. The --pretty argument can be used to limit the output of log. Passing --pretty=format:"%cd %h %s" along with --date=short to show only the day would show just the information I wanted.

The command I had produced so far was this

git log --author="`git config user.name`" --pretty=format:"%cd  %h  %s" --date=short
> sample output
2013-04-18  e3feb22  Undoing frim fram adjustments
2013-04-07  0a3a1df  Reticulating mumbo jumbo
2013-04-05  7b4bf01  Correcting mispelling
2013-04-05  206ed78  Harnessing power of the force
...

Showing Last Month’s Commits

Now that I had just my commits in a decent format I needed to find last month’s commits. There are a bunch of different ways to search using git log. One useful argument is --since. You can pass it simple phrases like git log --since="last month". This looks promising but wasn’t what I wanted. If today was April 18th it would show me all the commits from March 18th until today. I wanted all of the commits in March. The solution turned out to be the use of --before and --after which accept dates in the format of YYYY-MM-DD. I can show all of my commits for the month of March with this command.

git log --before={2013-04-01} --after={2013-03-01} --author="`git config user.name`" --pretty=format:"%cd  %h  %s" --date=short

I wanted to be able to run this command every month without having to manually type in a new date. The date command can be used to retrieve dates in different formats. It takes different arguments depending on the OS. The current date can be printed on Mac OSX with date "+%Y-%m" and the previous month can be printed with date -v-1m "+%Y-%m" If we substitute those two in place of the dates we have a command that will show all of my commits from the last month. I also appended --reverse so that the commits would be shown in ascending order.

git log --before={`date "+%Y-%m-01"`} --after={`date -v-1m "+%Y-%m-01"`} --author="`git config user.name`" --reverse --pretty=format:"%cd  %h  %s" --date=short

Putting it in Git Config

I don’t want to have to remember that full command so I created an alias for it in ~/.gitconfig.

# inside ~/.gitconfig
[alias]
  # other aliases here
  my-commits-last-month = !git log --author=\"`git config user.name`\" --before={`date "+%Y-%m-01"`} --after={`date -v-1m "+%Y-%m-01"`} --reverse --pretty=format:\"%cd  %h  %s\" --date=short

Now I can show my commits from the previous month just by running git my-commits-last-month

First off, I’m (Tracey) speaking to the DC Lean Startup group on March 19 with a number of other co-founders at a meetup called “Startup Battlefield” about the stresses and more life-centered issues around running a startup. I’m also probably going to take a couple of minutes about what it’s like working with your husband, which is not something I often talk about! Please click here for the meetup info.

Element 84 is taking over the April Data Science meetup in Columbia, MD! Jason, Dan and Marc are all going to be speaking on April 9. Jason Gilman will focus on the theory of visualizations and why we need them as developers. Next, Dan will dive into the details of how to build an interactive visualization and Marc will present a real-world example of the visualizations in action. Please click here for the meetup info.

At Element 84 world HQ we’re going to be hosting the newly formed ClojureDC meetup in April as well and have started sponsoring the group. Here is the main group page – with info about the first meeting on March 26. This group is very open to newbies and those interested in the technology. We’re looking forward to being involved with this group. I’m sure Jason will have some great blog posts coming about the material that’s being covered.

Also stay tuned… we have another new staff member to announce but I wanted him to have his own post!

I worked on a large legacy code base many years ago where the practice was never deleting code. Out of date documentation, old forked versions of libraries, and irrelevant bash scripts littered this project’s repository. The original developers weren’t around anymore. Whenever I had to fix a bug it would always involve several wild goose chases. I’d start tracing and grep’ing through the code trying to determine where the bug was. Eventually I would realize that the entire set of code I was working through wasn’t called at all. Or at least I thought it wasn’t called. I was never completely sure. There were no tests at all so I never had any confidence what I was changing would actually work.

I was afraid to delete the code for fear of breaking something. Deleting unnecessary code, documentation, and tests is part of good project hygiene. These dead bits must be cut out and removed. That and a good set of regression tests help avoid the fear of doing more harm than good.

While there are cases where it’s obvious and necessary to remove things, sometimes it’s hard to let go. We’re proud of the code we write and the applications we build. Deleting a feature can feel like you’re negating your efforts or declaring it worthless. You might also feel the need to justify the existance of features that are no longer needed. You spent all that time designing, building, testing, documenting, and maintaining it. How can you give all that up? This is similar to the sunk cost fallacy. It doesn’t matter how much effort has been expended on building something. You have to choose objectively. Ask yourself, from this point on, does it make sense to keep this code around anymore?

I’m currently faced with this dilemma. I built a tool for orchestrating the deployments of many different applications and tools across dozens of machines. I’m really proud of the design and implementation. It automated a very painful process at the time I built it. We recently started the process of switching to Chef for managing virtual machines. I realized we could replace all the custom deployment code with a few Chef cookbooks.

This would have a lot of benefits. An open source tool like Chef is going to have been tested very thoroughly. In addition to whatever unit and regression tests come with Chef it will be tested in real world scenarios millions of times. Chef is going to be maintained and updated by the community. We’ll be able to benefit from the hard work of all those people. Though we would still have to write our own cookbooks for deploying our applications all the glue code from my framework would be replaced by Chef itself. This would seriously reduce the amount of code we’d have to maintain for deployments. Another benefit of using a well-known and widely used tool like Chef is that all the common problems are solved and only a Google search away. When you hire a new person it’s possible they already have experience using it. This won’t happen with my custom solution. I’m not going to find answers on Stack Overflow about my custom deployment framework.

One possible downside of switching to a non-custom solution is that it might not fit our needs as well. While I don’t have much experience with Chef it seems extremely flexible. Pretty much anything you can write in Ruby you can do in Chef. There aren’t any more downsides that I could think of aside from the cost of having to learn a new tool. This is mitigated by good documentation, another benefit of using a well-known, popular tool. There’s also the many articles and online guides that have been written by third parties.

What seemed like a bad thing, throwing away a framework I had spent a good chunk of time developing, turned out to be an easy decision. There are just too many reasons not to make the switch. We have to be ruthless. We can respect the effort that went into building the old while we make way for the new.

What we found is that recruiting for more junior talent isn’t going to be any easier than it has been for the great team we’ve managed to snag so far. IEEE.org said in October that “The Association for Computing Machinery is forecasting that about 150,000 computing jobs in the United States will be opening up each year through 2020, but last year fewer than 14,000 American students received undergraduate degrees in computing science.” Doing the math, we’re short about a million CS people. Some of those roles will be filled by those that come from other related fields, my degree is in Civil Engineering and Paul majored in Computer Engineering; but those are some staggering odds.

So, we talked with the Career Services folks and did some brain picking. We figured out that we need to play up the fact that we’re small. Honestly, Paul and I had planned on “business casual” dress and after talking it over, we both ended up wearing our e84 tees. Some students loved the fact that we weren’t one of the fortune 500 companies we were standing next to. Another ray of hope, most students say that the deciding factor in choosing a job is the relationship they develop with the recruiters on campus. Good news there is being the recruiter and the one they are going to work with should help! We’re also going to need to hustle – there are consulting companies that actually have staff living and running small branch offices in Blacksburg to work with the students year round.

I do have to say I was really happy with the students we spoke with. For the most part, they were really professional and polite, some really bright kids. Made me proud to be a Hokie. Although answering the “what year did you graduate” question is getting less fun…I’m looking forward to getting some more junior talent in and getting our program up and running.

Ruby’s Enumerable module has a useful method called each_cons. It’s useful when you need to perform an operation over N consecutive items. Here’s an example:

a = [1,2,3,4,5,6]
a.each_cons(3) { |l| puts l.inspect }

# output
[1, 2, 3]
[2, 3, 4]
[3, 4, 5]
[4, 5, 6]

It’s like a moving window, N items wide, that returns each consecutive N items. I don’t use it very often but occasionally it comes in very handy.

eachCons in CoffeeScript

I needed to do something similar in a web application recently. I was hoping Underscore.js would have an easy way to do it but it doesn’t have one built in. You can build a function in Javascript to do it without too much effort. Here it is written in Coffeescript

# Calls function fn with consSize items from array a.
eachCons = (a, consSize, fn) ->
  for i in [0..(a.length-consSize)]
    fn(a[i..i+consSize-1])

# Sample usage
a = [1,2,3,4,5,6]
printer = (s) -> console.log(s)
eachCons(a, 3, printer)

Try this in jsfiddle

Underscore.js with eachCons mixin

That works but if you’re using underscore.js throughout your app then you’ll have two different styles of iteration functions. You can extend Underscore.js using the mixin function. The following coffeescript shows how to extend Underscore.js to support eachCons.

# Define a function that takes:
# obj - an object to iterate over
# consSize - the number of consecutive items to get 
# iterator - a function we'll with each subset of items
# context - becomes 'this' when in the iterator function
conser = (obj, consSize, iterator, context) ->
  for i in [0..obj.length-consSize]
    stop = i + consSize
    stop = obj.length if stop > obj.length
    slice = obj[i...stop]
    iterator.call(context, slice, i, obj)

_.mixin({"eachCons": conser})

Then we can call the eachCons underscore function like this

a = [1,2,3,4,5,6]
_.eachCons(a, 3, (l) -> console.log(l) )

Try this in jsfiddle

Jason will be talking about debugging with visualizations and showing off some awesome examples from his work with NASA.

We all build complicated applications that do amazing things. They juggle state for thousands of objects, perform complicated algorithms across multiple threads, and stay up for weeks or months at a time. We need to understand what’s happening in our applications. Until now the primary means of communication from application to developer has been symbolic; in gigabytes of logs, alert statements, stack traces, and emails. We can do better. Jason will argue the case that we should be building visualizations to debug our code and give you tips on how to build your own.

In addition to a new icon, we’ve introduced Questia integration within iHomework. Questia provides a huge library of online research material, and is now only a tap away. iHomework uses your assignment titles to automatically search the Questia library and provide research material that will help improve your productivity. If you find a book, article, or journal that you think can help, you can have iHomework send you over to the Questia app for a rich reading experience.

This update also includes bug fixes to the iOS app and cleans up some remaining iPhone 5 issues. We’re working on a Mac update to address iCloud issues and hope to have more on that shortly.