Jira vs Github :: Agile vs Open Source

A few years ago, my team got into Open Source. Specifically, we started writing all of our apps on github (as opposed to our SVN). We wanted to do this because we wanted to invite scrutiny. We never expected people to look at our stuff, we just felt that by putting it out in the open, we’d want to do better internally.

We went whole-hog. Organized stories with issues, organized sprints with milestones. It was pretty hot stuff. And it was all in the open. Potentially, someone could come by, see what we’re doing and offer to take a story from the backlog of issues. That’s open source. ish. We have a lot more we can do. A lot of growth to do.

Then we started using Jira. The board system within Jira Agile was excellent. Allowed for better organization, reporting!, and visual representations of work. It’s great. It’s Agile. But it also replaced what we were doing with Github issues.

We essentially replaced Open Source in favor of Agile. Our organization is great, we’re keeping track of things fantastically, but we’re no longer open. We don’t have transparency on what we’re working on anymore. People can’t potentially help. Our code is out there, but we’re not inviting. Our process is no longer out there.

So what’s our solution? We don’t have one yet. But what /can/ we do?

We need to put our vision statement out there. We need to put our plans out there. We need to expose what it is we’re doing. We also need to stay agile, keep our tools intact, keep our reporting.

This means we probably need to be duplicating efforts. Open Source and Agile are both hard work and organization. That they can’t line up and be the same effort is not a blocker, just an “oh well”.

Mobility Workshop

gold stick figures sitting together working on their gold laptopsA couple of months ago, we had a very successful presentation on vagrant/puppet. Given by a developer, it sparked motivation in some devops enthusiasts to give a workshop. It went really well. (Vagrant Tutorial)

They had a great format with their workshops that seemed effective. They were super enthusiastic, which translated to super prepared. They had created a wordpress post that was a very detailed, step by step instruction on getting started.

The interest and effectiveness of this sparked motivation to do “other topics”. So I put together this tutorial on mobile development, “featuring jQuery Mobile”.

I thought the idea of something where I had the material prepared beforehand and could just say “go” was a great place to start. This shouldn’t be a presentation, it should be an opportunity for people to get their hands dirty.

I was running through tutorials and found a lot of them had put their code on github. At some point I had the idea to use branches to “step” through the tutorial. The way I envisioned the workshop going was to start with nothing, and build out a mobile app through logical steps — as a lot of tutorials do. Do a header, do a menu, do a list, do a link, do a transition, do a search. Coming up with a list of “things to do” was easy.

Putting it together with github also meant I could just put the directions in the base readme and it would be a completely self-contained tutorial. (Not to mention, having it in git allowed me to force people who I know don’t want to make the switch out of SVN to use a VCS that is so much nicer.)

Anyway, the finished draft took a long time. It was a lot of easy stuff, but time consuming.

(Mobility Workshop)

The most important part came after the draft was finished. I gathered some team members and some cross-team members — basically whoever would come sit with me and had them run through it to see if it made sense. They were brutal. It was great. A lot of this work happened after hours, so the language was at times, very stream of consciousness. Having people with varied familiarity with the topics covered allowed for some invaluable revisions.

Overall, the workshop proved to be a wonderful exercise in collaboration and teamwork, and regardless of how the actual workshop goes, it has left me better than I started, so that’s good enough.

Custom Slides and Github Hosting

So I was putting together a presentation on Accessibility for my department. I knew very little about accessibility, so I read as much as I could and watched every youtube presentation I could find on the subject. A lot of them were total crap, but a few from some of the google io conferences were really great. They had working examples and code rendered inline to the slides.

I thought this was great so I went looking for what they did for this and found that (for at least the 2011 and 2012 io conferences) they have provided a slide template that is geared just for that.

The 2012 one is reasonably nice: https://code.google.com/p/io-2012-slides…

So I altered this, “forked it” and dumped it into my github: https://github.com/jazahn/axs-slides

That in itself is pretty cool, but then I thought, hey, I want to put these somewhere people can get at them. So originally I had them on my public web space for work, but it was sort of annoying to git commit, git push, log in to the server, git pull. Logging in can be an annoying step for my work if I’m not at work and need to VPN.

Artie had a cool idea of using github pages  http://pages.github.com/). Because these slides are all static, I don’t even have to worry about what server these are running on. All you have to do for this is create a gh-pages branch and anything in that branch will automatically be hosted. So what I did was create that branch, set it as the default branch, and removed the master branch (to avoid confusion and simplify). After altering my remotes, now I just have to git push from my dev environment and it’s automatically put on the server:

Very cool.

Continuous Integration with PHP on Travis CI and Github

People on high have been preaching the wonder of continuous integration for a while now. It’s been all about Jenkins forever. Jenkins is still the #1 choice for most people, but I recently ran into Travis CI and at least short term, this is going to be the solution for our shop.

What is Continuous Integration for PHP?

CI to most people involves building and running integration tests. PHP clearly doesn’t build, but good PHP still has unit tests / integration tests / functional tests — so CI for PHP is running those tests before code merges.

What makes Travis CI good?

Probably ease of use. There is no setup of a “travis server”. It’s a service that they run. You hook it to a repo you have access to and set up a config file and it’s good to go.

But this only works with github?

That’s probably the biggest detractor. It’s currently built exclusively for use with github. Which is awesome for github projects, but not every project can be on github. We don’t always have control over where our repos are — and not everyone is an open source person.

Posted in Development, Open Source, PHP. Tags: , , , , , . Comments Off on Continuous Integration with PHP on Travis CI and Github »

Feature Branches with Code Reviews

We have been trying to find a process for doing code reviews for a little while. Because most of our current projects are in github, it made sense to try and use some of the github features to help in this process.

I have been using issues for stories and milestones for sprints for a while. And it works out nicely because I get a pretty neat gamificationy results.

So I started using a feature branch in order to have the ability to make pull requests on my own project and get a discussion thread before code is merged into the trunk (production).


This discussion is a great way to get a reasonable code review before merging code. Right now we’ve decided to only do this for non-trivial changes, but with a very high bar on “trivial”.

Gamification in Software Development

Gamification has been on my mind a lot lately.

I was just doing some of my sprint planning and found myself filling out borderline excessive github issues for my project. I put all of the issues for the current sprint into aptly named milestones. So as I finish the issues in the milestone, the milestone progress bar gets filled up. I recently realized I enjoy doing this because it’s very game-like.

I’ve turned work into a game and I think it has increased productivity and general happiness with employment. Maybe that sounds lame, but it seems true in my case, I would recommend it for most people who are finding their current work stale and are looking for some self motivation.

Rendering templates obsolete?

There’s an interesting discussion on github today (courtesy of javascript weekly) about whether rendering templates and template engines in general are obsolete in today’s javascript-heavy applications. This topic seems to come up periodically, although the idea hasn’t really taken off. I think the first time I came across it was in the seaside framework, which is great by the way. I don’t have a strong opinion one way or the other, so I’ll be interested to see how the discussion develops.

Github zip doesn’t include Submodules

Seriously, what were they thinking. This completely invalidates the use of submodules. We want our code to be available without having to know git. That’s the whole reason they have the download a zip link. But not including all of the code means you have to unzip the code and then use git to get the submodules.

Submodules are great for code reuse. But if I can’t intend my project to be downloaded by people that just want to install it and not code anything while using submodules. This is horrible.

Inserting images into Github’s wiki

This is something I was not able to find clear information on. Specifically, I wanted to add a flow chart I’d created to the wiki. I’ll also be adding an ER diagram later. It’s cool to have the important development documents somewhere where they can be accessed and perhaps edited from anywhere by anyone if need be. Github has a failing in this regard I think. They should have an interface for this.

The trick of it all is the wiki is itself a git repo. What you have to do is check out that repo. In my case, my project was https://github.com/jazahn/HarvardCards. To checkout that project, you would use the command:

clone  git at github.com:jazahn/HarvardCards.gi... .

But that’s the project. The wiki is:

clone  git at github.com:jazahn/HarvardCards.wi... .

So you have to check that out, add the image file to it, and then you can [[add the image]] via relative path image link.  https://github.com/jazahn/HarvardCards/w…

Open Sourcing Now vs Later

We decided a little while ago to open source our projects. We had people asking for it and we kept having to say “sorry, we can’t really do that”. Our software wasn’t written with the understanding that anyone would look at it ever, so like most software it was poorly documented and tightly coupled with proprietary services. So it wouldn’t really be helpful to people and we were embarrassed by our own code (as most people are).

So we decided to rewrite some of our applications and the question came up should we open source it from line one of the code or wait until we were at version 1.0. When talk first started about open sourcing everyone agreed open sourcing from line one was the way to go. We three it out on github and just worked off of that. Then people started asking to see it. And there was some delay because we needed to decide on a license. And then we had a license and no one wanted to release.

I personally wanted to tell people where the code was. That’s the point I thought. But it became increasingly important to everyone else to release a more complete project. The thinking, I believe, is that if we release something that isn’t really useful to anyone from the get go, people aren’t going to ever check back. The thinking is they’ll take one look, say “huh” and never look back.

I can understand that but I still don’t agree with it. If you wait to open source software until it’s in a state you feel comfortable with, it will just keep getting pushed back because we as developers often have a perfectionist complex. It will never be perfect though.

The solution, I believe, is documentation. Not developer documentation, but very simple user documentation that doesn’t take long to read that they can look at and get a good idea at the state of the project and he direction of the project. A properly organized issue list can be very helpful. If peole can take a look at what’s being worked on, they can get a feel for where the project is. Thankfully github facilitates all of this in one place.

Just put it out there, but make it easily understandable what he state of the project is, where it works and where it’s lacking.

Posted in ATG. Tags: , . No Comments »