#12in23 and Advent of Code 2023

Last year I did have too much time on my hand, and while I spent a lot of time chilling, I did miss using my brain at least a little.

So I worked on these two challenges.

Exercism #12in23 

I am a big fan of exercism, which is a site with exercises to learn all kinds of programming languages. The quality of the tracks varies a lot, nonetheless the most popular ones are very useful. There is also a mentoring element, which I haven't used myself. 

You can either solve the tasks in an editor on the website, or use a small CLI tool to download the task and submit solutions. It is all straightforward to use and fast. 

Every year they also have some kind of challenge. In 2023, it was to learn 12 languages in the year called #12in23. You have to solve five exercises for each language to complete it. 

I just did the bare minimum for some languages I already know and some I wanted to have a look at. 

The ones I know and used recently: PHP, Ruby, Python, JavaScript, Go and Bash. No surprises here, except that you still tend to forget basic stuff over time. 

Some I haven't used in ages: C and C++. C++ especially seems to be a moving target. 

And some I haven't used professionally or just touched before: Elixir, TypeScript, Kotlin, and Emacs Lisp.
I like Elixir, and I decided to continue learning it. Some design decisions don't make a lot of sense to me at the moment. This might be my OOP brain.
TypeScript seems nice if you have to do front-end stuff.
I can't really see the point of Kotlin, it is pleasant, though.
Emacs Lisp … I think I keep on just copying and pasting other peoples code for my Emacs config. 

I didn't work on getting any of the challenge badges. Furthermore, I wasn't really that much into it.

Advent of Code 2023

This year was the first time I gave it a go. I solved most of the puzzles using Ruby. 

Every day you get a challenge on the Advent of Code site and once you solve it, you get a harder version. 

In most cases, you can brute force the first challenge, but not the second one. 

I made it until day 11, solving both challenges and stopped doing it on day 13, due to travel, and never picked it up again.

I think the best thing about this is the amount of learning you do if you do it in some kind of community (Reddit, Slack, employer, …). People have different approaches, use different languages, and different goals. 

People who do this every year have an advantage, as there are some standard solutions you can keep in your toolbox. 

I am not sure if I will do it again. I don't know how this would work with having a full-time job at the same time. But I still would recommend it to everybody to at least give it a try.

My Workspace

I like looking at pictures of other people's office set-ups. With most people working from home at the moment you see more and more nice workspaces especially tuned for video conferencing.

I was lucky enough to have a space and a reasonable set-up already. By chance I also had ordered bits and pieces before everything was sold out on Amazon.

There are a few things I still want to improve. The light is not ideal for video conferencing and I am also going to try a separate microphone for better sound.

Desk

My basic desk set-up is always the same. This is the first time I have two big screens, but I always have the same keyboard, headphones and mouse.

I think this goes back to at least 2000.

In our currently closed office I have the same again and when I start a new job I usually bring the devices with me as not every company lets you freely choose.

The computer is always running the current version of Fedora Linux, often upgraded over many years.

1. Dell Monitor U2719DC UltraSharp. I really just wanted one of these as I still had another very old monitor. This one came with a pixel error and Amazon send a replacement, but never managed to get the pick-up of the broken one sorted. So now I have two and use the one with the broken pixel for the not important stuff, like Slack. I think the broken pixel is not even a broken pixel, but an insect stuck between the layers - a real bug.

2. Dell Monitor U2719DC UltraSharp - the nice one, which has my browser, shell and Emacs.

3. Microsoft Natural Ergonomic Keyboard 4000 GB layout - while I am always looking for new fancy hacker keyboards I have stuck with this one. I have another one in storage in case this one breaks.

4. Logitech Mouse G502 Hero - my mice and keyboard are always wired, which limits choice a bit. I have pretty big hands and like a mouse that fills them.

5. Logitech Mousepad G440 - matchy-matchy with the mouse. I could do with a smaller one, because of the hight DPI of the mouse.
6. Sony Headphones MDR-1RBT - I am a bit addicted to headphones. I have three different Sony MDR-1 versions (RBT, ABT and R). I love the fit and sound.

7. PC AMD Ryzen 7 3700X, 32GB, 1TB, build up recently, also has a cheap fanless graphics card

8. Chair - from my first job/start-up, still works

9. APC BX1400U-GR Back-UPS BX, power outages and brownouts are quite common in Spain and even more so in the countryside. This protects the computer, there is another one for the routers and NAS.

a. Fleximounts F6 monitor arm for laptop - it works, not a lot of movement

b. Fleximounts F6D monitor arms for screens - same for two devices

c. Logitech C920 HD Pro - I am lucky I ordered this in time, it works, I probably won't upgrade any time soon. The Logitech Brio is also silly expensive.

Support

Not directly related to work, but supporting the main computer.

d. Thinkpad T430s on a arm and T470s on the floor - laptops from work, I use them in the office and here when I need another small screen or different device. One of them also has Windows on a partition for devices that require Windows for firmware upgrades

e. AmazonBasics paper shredder - goes together with the messy GTD stack on my desk, everything that I don't file goes into this one.

f. Synology DS218+ - backup of the computer, Syncthing backup, all my music and films.

g. USB Charging station (with Raspbery Pi running Syncthing on top), with various USB-A, micro-usb, and USB-C connectors and one for Garmin watches

h. Rubbish router from provider

i. AmpliFi HD Router - super simple set-up, annoyingly only with a mobile, supports multiple mesh repeaters that are all over the house

j. HP OfficeJet Pro 9010 - maybe I should have gone for a laser? I don't really print a lot

k. Thermometer / Barometer - it is way too hot in my office

Sound

I like my old school Hi-Fi components. If I had unlimited money I would just be buying this stuff on ebay the whole day.

The combination of the Sony amplifier and JBL speakers gives a sound I love.

The amplifier is also connected to a Chromecast Audio for multiroom sound, computer and headphones.

l. Tape deck Sony TC-K790ES - needs some work, the rubber transport bands disintegrated and need replacement, which is a bit tricky

m. Tuner Sony SA3ES - I never use it, but it is pretty!

n. Amplifier Sony TA-542E - this must be pretty old too, still works fine

o. JBL Control 1 Pro speakers - come with mounts for the wall and look sleek

Art & Memories

Since we bought the house and I have no further move is planned I made some effort to finally put all kind of stuff on the wall.

p. Sven Vaeth & Paul Cooper flyer 17-7-93 Warehouse Cologne

q. Photo from the Space Shuttle signed by Astronaut Robert Crippen

r. family

s. My dad and myself on our last holiday together. I have no idea why we shake hands.

t. family

u. X-Ray Cyclist by Nick Veasey sold by IKEA. Nick is one of my favourite artists and this is the cheapest way to get a great quality print.

v. Newton MessagePad 130 - I really did use this back in the days. It is a bit bulky.

w. Palm V, Palm Tungsten T, Ericsson t39 with extra antenna and calculator from school - this was my "smartphone" back in the days when phones got smaller every year. I sometimes connected it with bluetooth to the Palm for connectivity on the go. I miss small phones.

x. random memories box: old business cards, passport, party flyer, motorcycle key

y. Curves Calendar - don't google that. It has photos of mountain roads for each month to remind me of cycling. I just get a new one every year and replace it.

Lead Dev Live 2020

I heard of the Lead Dev conference series some time at the end of the last year. There are not many conferences that focus on engineering leaders, most of the technology conferences are focused on specific technologies, methodologies or the business side.

It was too late for the Berlin 2019 conference, so I set my eyes on either the London or Berlin 2020 conference. In the end I decided against London, because I wanted to avoid short plane trips as much as possible and staying longer in London also wasn’t an option.

Then the COVID-19 thing happened and Lead Dev organisers decided to cancel or postpone some of the 2020 conferences and also offer an online conference: Lead Dev Live 2020.
It was a two day conference on April 7 and 8, 2020. Not only was it streamed live, but also completely free. Each day had a single track happening in the afternoon and evening CEST. 

Streaming was via one long YouTube stream for each day, which was well produced except for some technical issues that were quickly resolved.
In parallel to this everybody had access to a Slack community for general chat, topic specific channels and networking.

In the end I didn’t watch all of the talks, but most of them. I am just going to list the ones I recommend to watch if you get the chance.

Overall I enjoyed the experience, they had some great speakers and some topics I can directly relate to.
I noticed that I found the panels more difficult to follow, you get a lot of whitespace between the speakers and there is no consistent story. This makes it easy to lose concentration, check your messages or fetch a new cup of tea. A normal talk with a story and possibly slides can really grab your attention and take you on a journey.
One thing that didn’t work at all for me were the Slack channels running in parallel to the talks. The main #leaddev-live channel was very noisy and just flooded with people just saying hello. Any announcements flew past so fast that it was pretty much unusable. Something like a channel only for announcements would have been more useful. You also run very quickly into the usual Slack problem of having too many channels and then too many notifications.

I definitely would join another conference by Lead Dev. I might even pay for it.

Would I go to a real Lead Dev conference? Yes, but only if it is close to me. I wouldn’t spend the time and money required to travel further than maybe a two hour flight. 

Day 1  

The first day was focused on the effects of COVID-19 on management and remote work.
YouTube stream day 1

Leading teams through times of uncertainty and upheaval [Panel]

Camille Fournier, Lara Hogan, Rachana Kumar and Christian McCarrick
https://youtu.be/yxiDblyYkrI

Good insight into how different companies and engineering approach the crisis with some well known guests.  

Minimum Viable Business Continuity Management

Meri Williams
https://youtu.be/TCu0gJ_hLq8

Talking about all kinds of aspects of continuity management. From risk assessment, testing, planning and communication.

Avoiding the pitfalls of rebuilding software [Panel]

Dan Berry, Jai Chakrabarti, Bryan Liles and Erica Stanley
https://youtu.be/lsgbGRkysJE

Rebuild or refactor in many words.

Day 2

The second day was more of a mix of different topics.
YouTube stream day 2

Tradeoffs on the road to Observability

Liz Fong-Jones
https://youtu.be/wkXKbC1GWIM

Keep SRE and observability boring. Use the tools that you can easily obtain instead of reinventing the wheel.

Designing effective OKRs [Panel]

Aniela Crisan, Whitney O'Banner, Antonio Verardi and Heidi Waterhouse
https://youtu.be/tBchi7FzRFU

Panel about OKRs in general and in tech teams. I really enjoyed Whitney’s take on this. Her talk from 2019 “Setting Objectives and Key Results in your team” is also worth a watch.
Another related talk watching from 2018, which was also played during one of the technical glitches in this conference is “Goal-Setting Workshops for Managers” by Melinda Seckington.

Apps, stacks, and frameworks: avoiding “Shiny Object” syndrome

Angel Rivera
https://youtu.be/Zk9Rg0Hswu0

This talk was quite random, but still interesting. He talked about his experience of using a new shiny technology (MongoDB) without having any expertise in this himself or in the team. 

Risky business: taking risks in production

Matthew Hawthorne and Leemay Nassery
https://youtu.be/Np8NFmjLn4Q

How to manage risk by using a/b tests, metrics, testing, …

Building and conveying vision [Panel]

Neha Batra, Lawrence Bruhmuller, Kevin Goldsmith and Maria Gutierrez
https://youtu.be/I9-_4WYUEhE

How to create and convey a message to your team.

Letting your CEO deploy to production

"One click" deploy (*)

Recently our CEO Raj Kumar spent a week in our Barcelona office where the majority of our engineering department is located.

I was working on some ideas for him to meet the team and get some insights into our daily work. While most of the company is aware of UI/UX and front-end changes we are doing to our site, some of the back-end and infrastructure work can seem like black magic. I think it is important to take every opportunity to bring this output closer to the rest of the company and especially the leadership.

By chance I watched the very good presentation “Getting Real about Managing up” by Kellan Elliott-McCrea, which contains as one example the idea of letting your CEO deploy to production.

One of the goals of our engineering team is continuous deployment. I set this out when I joined Devex to give us a far goal to aim for. I was inspired by Etsy’s Code as Craft blog and the book “Web Operations”. For me the important part was not continuous deployment itself, but all the changes in engineering culture required to achieve it. You need a good technical base from unit to integration tests, infrastructure as a code, continuous integration and a infrastructure team that is working side by side with the developers.

At the beginning this seemed to be an impossible task, QA and deployment were completely manual, there was no unit testing, no code reviews, a clear separation between developers and operations. The code itself was a mess too, with lots of moving parts, outdated libraries and no easy way to introduce testing.

But we slowly made progress, simplified the system and slowly worked our way up from deploying once in a blue moon, to once, then twice a week.

Currently we are at one deploy a day, with some manual involvement of QA. The deployment gets kicked off by a chatbot and is well documented in our engineering handbook.

The short version looks like this:

1. Check QA status
2. Tell the chatbot to deploy 
3. Check the metrics

Everybody in the engineering team is already in the rotation of deploys and it is easy enough for everyone in the company to do it.

Our CEO Raj Kumar was happy to do it and sat together with our two infrastructure engineers to help him along. Because there are some permission requirements it was also easier to do it from the workstation of our lead engineer.

After some hiccups in QA the progress went smoothly and we had a new release in production.

I guess in the end he was surprised how boring it turned out to be. Which a deploy should be.





btw: we are hiring: Check out our current open positions


*) the hat is part of the deploy protocol and not a fashion statement

Saying goodbye to some legacy code

When I joined Devex a bit more than six years ago most of the code base was in one large monolith. This monolith was based on Ruby On Rails and was responsible for delivering devex.com.

urn

This part was called "neo". I guess because it was a rewrite of a previous Java
version. I am not sure if it was a reference to Matrix or the Greek meaning. 

There were already some initiatives in place rewriting parts of it in different services, but the monolith was always looming in the background.
Any changes to it required increasing amount of work. It was like someone tried to put the definition of technical code into code.

I generally against rewrites, they tend to last for years and you loose a lot of knowledge that is baked into the original. I also have nothing against Monoliths. So I tried refreshing the code base by upgrading the dependencies, getting the few tests to run and making local development easier with Vagrant. I realized fairly early that this was not going to work.

So we went with a gradual rewrite. Whenever we worked on part of the site we migrated it to our new architecture (Also a Monolith or at least a Duolith).

Now six years later we finally switched off the remainders of "neo" and I thought we should celebrate in style.

Legacy code is after all something that successfully supported you for a long time and enabled you to start with something fresh. Devex wouldn't be were we are without "neo".

Cremation - ignore the dog

So we staged a proper funeral, where everybody who wanted said some words. We also collected printouts of the most annoying bits of code, some very dated looking screenshots and some email and chat conversations from the very beginning.



This was my eulogy:

Today we say goodbye to maybe the best known system at Devex.+
Neo - from Greek meaning young or new, which he was neither.
Or from the Matrix character, handsome, powerful and agile, which he was also not.

We all have memories of him that will stay with us for a long time.
We laughed about his quirks.
He had amazing depths, which brought us sometimes close to tears trying to understand him.

His heritage will live forever in our data structures.

Finally we burned the printouts, collected them in an urn (aka hummus glass) and cheered with Cava while chatting about the "good" old days.

I hope you can give your legacy code also the sendoff they deserve.

The End

Update (March 2020)

We got a present from our CEO while he was visiting the Barcelona Devex office this week....

RIP Neo Mug

Books I wish I read earlier

When I wrote the review of The Manager's Path I started to think about other books I wish I had read earlier.

Usually these triggered some kind of change in how I approach my work or life. This list is definitely incomplete and I will add more to the goodreads list at the bottom of this post.

Extreme Programming Explained: Embrace Change by Kent Beck

I still remember when and where I read this for the first time. It was on a plane from the US OSCON back to London where I had my start-up. 

Up to that point all of our projects where waterfall and we basically had no unit tests in our code.
On the plane I decided we had to do major changes and we did these over the next years.
I was still pretty inexperienced in leading a team, but this was one step into the right direction.

By now most of the things mentioned in the book, like pair programming, small cycles, unit testing, agility are well used and documented. This small book is probably still worth a read.

Getting Things Done: The Art of Stress-Free Productivity

This book is one of the ones where the solution is so obvious that a one page summary would probably enough. Nonetheless this is a good book and gave me a better idea about organizing myself.
I am using a mix of the paper approach for all the paper one still receives and Todoist for everything else.

In the end it is just a form of Kanban or Inbox Zero. It doesn't matter how you manage your tasks, just keep your work in progress small and your tasks prioritized. 

Web Operations: Keeping the Data On Time

A collection of essays and interviews that gave me lots of ideas about DevOps and that side of a company in general. I still use it as a reference for things like post mortems.
 
Because these are mostly stories it is an easy read and you don't have to read the book in sequence, just pick the ones that you find most interesting.

Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity

Mostly interesting and inspiring because I am so hopeless bad at this. As an introvert the idea of being candid and even worse radical candid seems absurd. But I know it is one of the areas I have to work on and the book gave me new ideas in a nice form.

It is a bit long though and does repeat the main points over and over again. 

The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses

I am not working at a start-up any more, neither am I on the business side. I just wish we had this in my time in London. We would have avoided a lot of pain and would probably be still around now.
Implementing this in an existing setting is a lot harder unless you have buy in from the top.

The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change

A great book for engineers transitioning to management. Another book I would have loved to have had at my start-up, thankfully it didn't exist back then. My review of The Manager's Path.

Definitely worth reading for all developers even if you don't plan to go into management.

I wish I read this earlier

Web Operations: Keeping the Data On Time

by John Allspaw

Extreme Programming Explained: Embrace Change

by Kent Beck

Getting Things Done: The Art of Stress-Free Productivity

by David Allen

Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity

by Kim Malone Scott

The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change

by Camille Fournier

Friday Links

John Resig: Write Code Every Day
http://ejohn.org/blog/write-code-every-day/

Agilar: Scrum teams: self-organizing or self-directed?
http://blog.agilar.org/index.php/2014/04/09/scrum-teams-self-organizing-or-self-directed/

etsy engineering youtube
https://www.youtube.com/user/etsyengineering

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.

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.

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.

Calm

Before:

#include <stdio.h>

int main(void)
{
  printf("Hello world\n");
  return 0;
}

After:

<>;;.""(()){}\#
0
acddddeeefhiiiiiillllmnnnnnnooooprrrrsttttuuvw
H

International PHP Conference 2011 Spring Edition impressions

I planned to post this a lot earlier, but I wanted to do the presentation at Softonic first and I am also very lazy.

My employer was so nice to send a colleague and me to the International PHP Conference 2011 Spring Edition in Berlin this year. It was a three day conference. There also was one day of workshops, which we skipped. We also skipped most of the keynotes, because most of them were in German and didn’t seem very useful.

I concentrated on the topics that interest me most: agile, unit testing, continuous integration, continuous deployment and Symfony/Doctrine. So here goes a quick summary of the stuff I think was good.

DevOps fuer PHP by Johann-Peter Hartmann slides

A very good introduction on DevOps, mostly introducing lots of tools and how they are used at Mayflower GmbH. I found especially the bits about self service virtual machines and clouds for developers interesting. They are using a combination of puppet, vagrant, fog and eucalytus for this. He also emphasized how important the culture in a company is to make this possible. All of this enables faster development and deployment. I plan to have a separate post about this soonish.

3*PHPUnit by Sebastian Bergmann

This could have easily fitted into one talk. And if you have seen any of his talks before you could have skipped most of this too. I liked the quote about removing the release cycle and making it much more fluent, reference to the etsy blog (which is brilliant) and latent code patterns. None of this is new stuff though.

MySQL, PHP - The current State by Johannes Schlueter

Oracle man. Improvements in MySQL 5.5 and 5.6. memcached interface, which is currently in labs. Some examples of the asynchronous mysqli interface, which sounds really interesting for some use cases. Also information about mysqlnd plugins, especially the mysqlnd_uh one which allows writing these in PHP. All of this is not so useful if you like your ORMs though.

Large-Scale Data Processing with Hadoop and PHP by David Zülke slides


Highly recommended if you can see this at any conference. Very good presentation, starting with the use cases of sites which are producing lots of data and need to use map reduce to mine it. It continued with a live demo on a laptop, first tuning it until the speed increased by using map reduce and later connecting two laptops to show how well it scales.

Next Generation API Documentation by Arne Blankerts

I didn’t expect much of this last talk, but it turned out to be pretty good. As PHPDocumentor seems to be pretty dead, there is a need for a new system. CI systems usually also generate the API documentation, so it is important that this is also fast. phpdox seems to solve this, but it is still in an alpha stage so we have to wait and see.

Miscellaneous

I also saw a lot of other talks, but most of them were either introductions to things like node.js, nginx, JavaScript QA, Doctrine NoSQL and Symfony CMF. None of these contained any new information for me. Sometimes I wonder I should stop reading blogs and twitter two months before a conference, just to make them morei nteresting.

You can find more summaries and links to the slides if available here: http://joind.in/event/view/681

git workflow for the bikesoup project

I have been one of the many converts to git and try to use it whenever possible. So far this has been mostly for smaller project, open source projects, Fedora and a little bit at work.

bikesoup is my first bigger project using git. I started with initial development on the master branch and created feature branches which got merged back into master. Before going live for the first time I created a live branch. This is pretty much what you would do in subversion too, maybe with the exception of any feature branches.

Once the site went live I created a feature branch off master for each issue in bugzilla I am currently working on. When I am happy with the fix I merge it back into it.  And when the feature goes live it the feature branch is also merged into live. The diagram below shows this process.

When first working like this I had all kind of problems when I merged into live. When you branch a feature and then only work on this feature before you merge it back into master git uses fast-forward merging, which messes up the feature branch. If you merge this feature then into live you merge in fact master, which is probably not what one wants. So now I use --no-ff on all merges.
The nice thing is that you can go back to feature branches. Sometimes a bug gets reopened and I don't want to create a separate branch for this. Then I can check out the original feature branch add the fixes and merge back into master and then live.
To make it a bit more interesting I have also a hot-fix branch off live for things that have to fixed fast because the site is broken. This gets also gets merged back into master. And some other branches which track changes to configurations in live and master which don't get merged between the main branches.

So, how does this look in practice?

The git-set-file-times is necessary, because git can mess up the file times when switching branches, which messes up the rsync of the symfony deploy script. The script sets all file times to the last commit times.

If you are coming from subversion (or worse) it isn't easy how fast the branching and merging is. One way to visualize is the diagram to the right, which just shows the branches of one day. Some of these just contain a few line changes.

Another way to describe it is "two seconds", that is how long the script above takes (just the branch switching, branching and merging, without the time for bug fixing and upload of course).

So, whoever is still not using git: try it on a small project and I promise you will fall in love with it soon.