Today I had to read about git tags in order to be able to explain in a better way why somebody would use tags and for what. The old (and still good) git workflow explains very well how to develop using branches but doesn’t explain too well why we create the tags and how should be used on production. It just saying “that commit on master must be tagged for easy future reference to this historical version”. If you followed that guide and now you are ready to go live with your code changes, you maybe wonder what should you do with the tag? Why did you create it. Some people would say, just leave it there, maybe somebody, in a shiny day will take a look to it. Just go to production and do git pull origin master. But I don’t think this is the purpose of the tag.

For some of my projects, most of the time I use two branches: master and dev and I work mostly in dev. If I need to send the url to some clients with some dev/beta features I should create another (sub)domain like dev.myproject.com and sometimes, if I forget to change some configurations about the domain name (specially with some “very intelligent” CMSes that keeps the configuration in the database) I will get an email back saying “the new feature is not working” 🙂

Let’s assume we want to download a file (or to do some tasks) to every 5 seconds, but the condition is to not do the same task twice or more times at the same moment, even if takes more than 5 seconds. For example, we have a to download a file and this will take 8 seconds. Also, if takes more than 5 seconds, it should not wait until the next iteration, to start again (3 seconds more), but will start the download immediately.

So, the traditional cronjob/lock file combination was not suitable for my case.

REST Anti-Patterns – A lot of people (or companies) pretend to have a REST API. Read this article and you will understand that not all the API’s that implement GET and POST methods are REST APIs. It is an old article (from 2008), but still valid.