Getting Git Right!

Last week Celix.at brought Atlassian and their Getting Git Right event to Vienna (or Schönbrunn Palace Conference Center to be precise). By means of introduction Sven Peters talked about how Atlassian organizes a company with 300 developers working distributed, 850 employees in total, building Jira, HipChat, Bitbucket and a vast number of other developer tools.

Sven: “Developing software is a social challenge, Git helps ship software faster and smarter.” Atlassian switched from Subversion to Git 5 years ago. The technical part is one thing – the Jira team alone migrated 11 year’s work, 200+ committers, 21,000 files and 47,228 commits – Sven gives away, but the human side of things is a little trickier. Looking at its customers, Atlassian predicts 63% will have moved to Git by December 2015. That’s good news as Git users release daily to weekly as opposed to monthly, a trait of many a team using Subversion. Additionally, studies see 15% more code reviews when using Git (and their pull request functionality) than with other version control systems.

Happy developers

Nicola Paolucci (Git Evangelist for Atlassian) then took over claiming that Git adaptation makes for happy developers. Git brings speed as it doesn’t break the flow. Plus: it’s written in low level C by the main contributors of Linux and filesystem developers. It gives you the freedom to switch context fast (feature branching) and losing work with Git is very (very) hard. It’s easy to find history commits with git log commands and when all is lost, one can always fall back on reflog (only garbage collected every 90 days). Some nifty git log commands that were fairly new for me:

git log --after
git log --before
git log --diff-filter=D --summary

… and:

git branch --no-merged
git branch --merged

… to verify if I indeed merged a certain branch. Nicola also explained Rebase as ‘a way to replay commits, one by one, on top of a branch’. An --interactive rebase is that plus deciding ‘interactively’ what to do with each commit (pick; squash; rework; fixup, etc).

Effective workflow

Sven Peters went on to talk about how Git introduces an ‘effective workflow and improves code quality’. Demo-ing a brand new feature in Jira that allows you to create a branch straight from whatever issue, Sven emphasizes the pain tool switching used to be. Going over the various workflows within Atlassian teams, Sven highlights the merge strategies between branches (either hotfix or feature) and how Atlassian Stash (a repository manager much like Github) allows you to set automatic merges for your branches. Sven: “Code review meetings tend to be boring and even uncomfortable as your code gets discussed, but they lead to better quality and you learn heaps from how others write code.” Making code reviews part of daily work and doing them asynchronously (read: not in meetings per se) makes the whole thing ‘way less painful’. And Git’s pull requests call for code reviews before a merge, making it a more natural process.

As a last piece of advice Sven recommends to have every line of code connected to a real life problem / issue (in your bug tracker). And he tips checking out blog.atlassian.com for tons of information about Atlassian’s migration and Git in general.

Docker and mutation testing at the Berlin Ruby User Group

We attended the RUG::B (Berlin Ruby User Group) yesterday – as we do regularly. It was full house at co.up (Adalbertstrasse 8) and the program interesting.

Working in a different country

Jan Schulte (@neinasaservice) started off with a convincing case on ‘where Microsoft did a good job to make developing software easier’. With an almost exclusive Ruby audience, that must have been a tough cookie.

Jan got started with .Net in late 2007, was employed mid 2010 as a .Net developer and ‘only’ got started with Ruby in October 2013. He now uses a vast number of tools (Ruby, JRuby, vim, Rake, git, ctags, Mac OS X, Vagrant, Virtualbox, CouchDB, MySQL, Elasticsearch, …) whereas in his .Net days his toolbelt was much smaller with Microsoft Windows [XP, Vista, 7, 8], .Net Framework, C#, Visual Basic.net, SQL Server, Team Foundation Server, Office and Internet Explorer.

Jan praises Microsoft for having a solution ‘for everything’ with Office, Internet Explorer, Sharepoint, Team Foundation Server and libraries such as the Entity Framework for O/R Mapping – ready for commercial use. Product maintenance not being their strong point. Talking discontinued support for SilverLight Jan complains that does not only mean no more bugs will be fixed. You cannot fix bugs yourself as it’s not open source software, nor can you add features or even look at the code. (more…)

How-to deploy your Node.js app on anynines

I wrote a small Node.js app to test deploying with Node.js and MongoDB on anynines. The application enables visitors to browse quotes and add their own to the database (what could possibly go wrong?). It’s not likely it will ever win a startup competition, but it IS a neat way to demonstrate deploying a JavaScipt app* on anynines.

You can find the example application at nodejs_mongodb_example.de.a9sapp.eu.

Getting started with Node.js

Make sure you have Node.js installed and MongoDB setup on your developer machine. Let’s verify your Node.js installation and start the MongoDB server:
$ node -v
$ mongod

Clone the repository to take a look at the application and run it locally:
$ git clone git@github.com:anynines/nodejs_mongodb_example.git
$ cd nodejs_mongodb_example
$ node app.js

Visit https://localhost:3000 in your browser to see the application in full glory. (more…)