Are Your Programmers Working Hard, Or Are They Lazy?
http://mikehadlow.blogspot.co.uk/2013/12/are-your-programmers-working-hard-or.html
Emulation in Chrome DevTools
http://youtu.be/z7sTRdSpA04
22 Crazy Perks You Should Ask Your Boss For (spot the ones we already enjoy)
http://www.linkedin.com/today/post/article/20131203162756-5799319-22-crazy-perks-you-should-ask-your-boss-for
The Guardian responsive front-end open sourced
https://github.com/guardian/frontend
Performance Calendar: Reducing Domain Sharding
http://calendar.perfplanet.com/2013/reducing-domain-sharding/
Rails 3.2.16 and 4.0.2 have been released!
http://weblog.rubyonrails.org/2013/12/3/Rails_3_2_16_and_4_0_2_have_been_released/
github: Expanding context in diffs
https://github.com/blog/1705-expanding-context-in-diffs
Devops road at Tuenti
https://vimeo.com/album/2565361/video/76750531
How to initiate a DevOps Transformation (Video)
http://dev2ops.org/2013/12/how-to-initiate-a-devops-transformation-video/
Baruco 2013: Building a Culture of Quality, by Bryan Helmkamp
http://youtu.be/Jsi1YTkXwxA
Friday, December 13, 2013
Friday, November 29, 2013
Friday Links
Why GNU grep is fast
http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html
CMS Trap
http://hakunin.com/cms-trap
http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html
CMS Trap
http://hakunin.com/cms-trap
Friday, November 22, 2013
Friday Links
At my current job at devex and my previous job at Splendia we have a tradition of everyone sending an email with interesting links to the internal mailing list on every Friday.
The idea is to spread the knowledge and give everyone something to read for the weekend, when there is plenty of time (ha!).
I am going to start posting some of these here too, because I think they are good and also because I have nothing else to write about at the moment.
Today it is only three links:
How GitHub (no longer) Works - very good talk about growth and changes in a company.
http://www.infoq.com/presentations/github-evolution
Preparing the Netflix API for Deployment
http://techblog.netflix.com/2013/11/preparing-netflix-api-for-deployment.html
Realities of Performance Appraisal
http://blog.learningbyshipping.com/2013/11/09/realities-of-performance-appraisal/
The idea is to spread the knowledge and give everyone something to read for the weekend, when there is plenty of time (ha!).
I am going to start posting some of these here too, because I think they are good and also because I have nothing else to write about at the moment.
Today it is only three links:
How GitHub (no longer) Works - very good talk about growth and changes in a company.
http://www.infoq.com/presentations/github-evolution
Preparing the Netflix API for Deployment
http://techblog.netflix.com/2013/11/preparing-netflix-api-for-deployment.html
Realities of Performance Appraisal
http://blog.learningbyshipping.com/2013/11/09/realities-of-performance-appraisal/
Wednesday, July 17, 2013
Moving on...
I have confess that this was shorter than I would have thought or wished for, but Thursday is my last day at Splendia.
Splendia is a very different company from my previous employer Softonic. While Softonic has all the perks and advantages of a big successful company with a large development team.
Splendia is much smaller and when I arrived the whole team had just arrived too and was confronted with a "legacy" code base.
The amount we managed to do in this year is just amazing and this wouldn't have been possible without the brilliant team. Fernando (the CTO when I started), recruited very well and made everyone fit in right away.
We changed everything, from introducing scrum sprints, going from zero to 3000 unit tests, re-factoring big parts of the system, continuous integration, functional testing and everything else you expect from a modern Internet company. I gave a talk at WeLovePHP last weekend, which talked about all of this.
I leave because of changes in the structure of the company and because I have the opportunity to join an exciting new project.
More about this when I have started...
Saturday, July 13, 2013
WeLovePHP Talk: Methodologies and tools used by the Splendia development team
Today I gave
a talk at WeLovePHP, which is a quarterly talk and workshop series organized by Softonic in Barcelona. They also do one about JavaScript.
I can highly recommend them if you are interested in PHP, JavaScript or related topics.
I talked about the processes and tools we are using at Splendia.
There are no pictures in the slides ... sorry.
I can highly recommend them if you are interested in PHP, JavaScript or related topics.
I talked about the processes and tools we are using at Splendia.
There are no pictures in the slides ... sorry.
Labels:
barcelona,
conference,
development,
github,
php,
splendia,
symfony,
work
Friday, July 05, 2013
Klaus Damian R.I.P.
Last month my father Klaus Damian died much too young and rather unexpected.
He was a hero to me, like every father should be. But he made it especially easy.
When he retired he was the Head of the Astronauts Training Division at the EAC (European Astronaut Centre) of the ESA (European Space Agency). As far as I can remember he always worked with satellites and spacecrafts. He travelled the world to go diving with astronauts in the Caribbean, do zero gravity flights, to see rockets or spaceships take off from all continents.
I always remember the map of the world he had on his wall, which had a pin for every trip and they were everywhere.
The thing is that you don't realize this as a kid, you get used to the exotic food that you get to know. You get bored of meeting yet another astronauts (except maybe the Russians, they are fun). You forget where you put all the autographs and ESA and NASA stickers and patches. As a teenager you just expect every dad to be like that.
So he had a pretty busy life I would say, but when he retired he really started living it to the full. He travelled even more, whenever I tried to call him he was somewhere in the desert in a cave, on top of a mountain in South America, hiking the Camino de Santiago, climbing at Mount Everest Base Camp, sitting on his or some other boat.
In 2011 he, my brother, my sister and me did a trip to Vietnam and Cambodia and I must confess I had a bit of trouble keeping up with him. He didn't care if we slept in a luxury hotel, on a boat, in a bus or spent 24 hours in a train, he was always enjoying himself.
I have no idea how he found the time, but he also learned to sing, write stories, play the stock market, automate the house (so nobody knows how things work now), dive, paint, run marathons, cycle and all kind of other things.
We didn't really talk to much, because of the distance, but also because we both are not really into small-talk. If one of us called the other one we always expected the worst, because why else would you call?
He didn't call this time.
I hope he doesn't expect us children to achieve what he did, because frankly, he made it a bit difficult by setting the goals so high. But without him I wouldn't be where I am now. I wouldn't have discovered the fun of science and computers so early. I might not have been so open to move to different countries and try new things. I will try to live my life to the full too though, because what else is there?
I will miss him.
Saturday, May 18, 2013
A Code Review and Continuous Integration Workflow
As hopefully most people working on software projects nowadays we are writing unit tests and do code reviews.
All of these are run on our integration branch, whenever a new feature is integrated.
Before this can happen the code will be reviewed by other people in the team and only if there is a consensus it will be merged into the integration branch.
For the code reviews we are using the pull request system of github. It works very similar to other code review tools, you see a diff view of the changes and are able to add comments to discuss the code.
In these comments we are using a convention of "+1", "-1" and "[B]" to give the pull request a thumbs up, down or mark it as blocked because a critical bug was found. Anyone in the team has a vote and is allowed to discuss any request.
In addition to this the unit tests and some smoke tests will be run on the code of the pull request to avoid merging broken builds.
Only if the tests are successful, there are three positive votes in total and no blocker the request will be merged.
In the beginning all of this was done manually. Developers had to run the tests before the created the pull request and only senior developers had the right to merge a pull request. Every couple of hours they would check the list of pull requests and verify that they had enough votes. It was a distraction and also prone to mistakes.
What gave us a big push in productivity was the introduction of two tools to the work-flow.
With this we are testing every pull request before it gets merged. We also run a limited set of static code analysis, because we want to keep this build fast to give quick feedback. Currently it takes around seven minutes.
I have reimplemented this script to make it possible to publish it. You can find it under the name plus-pull on github. I have added some more features to make it also useful for open source projects.
In the screen-shot you can see how this works in practice.
Work-flow at Splendia
As our project is a large PHP site we are using PHPUnit for unit testing and various static code checking tools (checkstyle, phpmd, pdepend, phpcpd) to verify the quality of our code.All of these are run on our integration branch, whenever a new feature is integrated.
Before this can happen the code will be reviewed by other people in the team and only if there is a consensus it will be merged into the integration branch.
For the code reviews we are using the pull request system of github. It works very similar to other code review tools, you see a diff view of the changes and are able to add comments to discuss the code.
In these comments we are using a convention of "+1", "-1" and "[B]" to give the pull request a thumbs up, down or mark it as blocked because a critical bug was found. Anyone in the team has a vote and is allowed to discuss any request.
In addition to this the unit tests and some smoke tests will be run on the code of the pull request to avoid merging broken builds.
Only if the tests are successful, there are three positive votes in total and no blocker the request will be merged.
In the beginning all of this was done manually. Developers had to run the tests before the created the pull request and only senior developers had the right to merge a pull request. Every couple of hours they would check the list of pull requests and verify that they had enough votes. It was a distraction and also prone to mistakes.
What gave us a big push in productivity was the introduction of two tools to the work-flow.
ghprb
First the GitHub pull request builder plugin, which enables Jenkins to automatically start a job for each pull request. It has additional features, like starting another build if more commits are added or recognising comments that instruct it to retest or white-list people who are allowed to create builds. It is similar to the pull request feature of Travis-CI only with the full possibilities of Jenkins to your disposal.With this we are testing every pull request before it gets merged. We also run a limited set of static code analysis, because we want to keep this build fast to give quick feedback. Currently it takes around seven minutes.
PullRequester / plus-pull
The second tool is a simple script which was written by one of our developers and it was called PullRequester. It runs as a cron job and checks whether the pull requests satisfy the +1 and successful test rules. If all is OK it automatically merges it.I have reimplemented this script to make it possible to publish it. You can find it under the name plus-pull on github. I have added some more features to make it also useful for open source projects.
Final Words
Even though these tools are not magic the increase of our productivity was visible. I account this mostly to way it enabled asynchronous working. No developer has to wait for a senior developer or poke someone to merge his code. As long as he can find three people who agree it will be merged automatically. And as everyone is interested in reviews themselves they tend to happen quickly.In the screen-shot you can see how this works in practice.
Monday, February 04, 2013
Splendia
I must admit that this post comes a bit late. As I have mentioned before, I have left Softonic last year.
The main reason was that it was too difficult to change anything there and nobody seemed to know what to do about it. This might have changed by know.
After Softonic I started at Splendia, where I am still at. Splendia is a hotel booking website focusing on luxury hotels. The company is much smaller than Softonic in every respect.
What drew me in was that they replaced nearly the whole IT team and replaced it with a much more agile team using technologies and methodologies that are industry standards in most PHP companies.
The team is also always open for changes to improve the speed of development.
When we arrived the state of the code was pretty bad. How bad? Well, there were zero unit tests at the beginning of 2012 for example.
By now we have a growing test suite, continuously run through Jenkins. We use github for code reviews, vagrant for workspace virtual machines, cucumber for functional tests, puppet for configuration management and composer to pull in various dependencies including symfony components, doctrine and pear libraries.
I will post some more about how we use these in the future.
Other nice perks: the computers are nice with two big screens, you get to install your choice OS as long as it runs vagrant. The office is located in the centre of Barcelona, which gives a better choice of restaurants and shops. I can also park my bike in the office, which allows me to commute every day now (more about this later too).
There are some things I miss about Softonic though (besides the people there): the pretty office, Spanish classes, free coffee, snacks and the cafeteria for my tea time.
Compared to Softonic the office hours at Splendia are also very rigid, which is annoying.
Well, hopefully more soon...
The main reason was that it was too difficult to change anything there and nobody seemed to know what to do about it. This might have changed by know.
After Softonic I started at Splendia, where I am still at. Splendia is a hotel booking website focusing on luxury hotels. The company is much smaller than Softonic in every respect.
What drew me in was that they replaced nearly the whole IT team and replaced it with a much more agile team using technologies and methodologies that are industry standards in most PHP companies.
The team is also always open for changes to improve the speed of development.
When we arrived the state of the code was pretty bad. How bad? Well, there were zero unit tests at the beginning of 2012 for example.
By now we have a growing test suite, continuously run through Jenkins. We use github for code reviews, vagrant for workspace virtual machines, cucumber for functional tests, puppet for configuration management and composer to pull in various dependencies including symfony components, doctrine and pear libraries.
I will post some more about how we use these in the future.
Other nice perks: the computers are nice with two big screens, you get to install your choice OS as long as it runs vagrant. The office is located in the centre of Barcelona, which gives a better choice of restaurants and shops. I can also park my bike in the office, which allows me to commute every day now (more about this later too).
There are some things I miss about Softonic though (besides the people there): the pretty office, Spanish classes, free coffee, snacks and the cafeteria for my tea time.
Compared to Softonic the office hours at Splendia are also very rigid, which is annoying.
Well, hopefully more soon...
Subscribe to:
Posts (Atom)