Reblogged from Medium.com:
Reinforcing Development Best Practices with brutally inflexible rules.
A fly-on-the-wall at the MMT Digital offices might occasionally hear mutterings along the lines of;
“If it’s not in Bitbucket, it doesn’t exist.”
A phrase which, when uttered, roughly translates as “what the heck are you doing? how am I supposed to work with this?” and essentially boils down to the belief that;
Once you understand source control, you can’t fathom why you would ever work without it again.
Source control is essentially the management of versions and changes to files. But why should we insist so strongly that everyone uses it?
Having a decent source control system in place allows multiple developers to work in parallel on the same project and project files, gives each of them access to an annotated code history, and the ability to create or combine parallel sets of changes from others into a final, ‘working version’ of that code.
Using source control in this manner also makes the automation of testing and deployment processes possible, improving our development efficiency.
The final, and most business critical point is that, using a Distributed Version Control System (DVCS) in conjunction with a service like Bitbucket makes us ‘Fireproof’ in the sense that — if our offices were to suffer an overnight calamity — we still have multiple intact copies of the source code, from which the entire project could be restored.
This final ‘business critical’ point is where our rule originates. The best rules work on many levels, you see.
- From a business point of view, we care a lot about how we could continue, should the unthinkable happen.
- From a developers’ point of view, we want contextual and historical information about our code base.
- From a team’s point of view, we want to reduce the obstacles to working in parallel on the same project.
We can’t do any of this without source control, but we can do all of it with source control, and it’s for that reason we say:
“If it’s not in [source control], it doesn’t exist.”
Harsh maybe, but with solid reasoning behind it.
What is Git? What does it do, how does it work, how does it fit into my workflow?
If you’ve ever wondered about the answers to any of those things, this session is designed for you, my friend.
Starting with the assumption of no prior knowledge of Git or even of version control, we’ll cover the technology at a theoretical level, its manifestation in your projects in the physical level, and your development workflow at the practical level – by which time you’ll be ready to step out into the world, secure in your knowledge of what the heck Git is, and ready to use it in your projects – and you’ll marvel at how you ever worked without it.
A 10 minute ripping yarn through the world of responsive images.
I’m amazed that I’ve never really used this before, but as well as using Git to manage your version history, you can also tap into built-in Git hooks to copy your project source code into another location after you’ve pushed your updates.
Essentially it’s a cheap deployment process, and allows you to keep your source code repository and all its gubbins in one location, and serve your website from another.
DigitalOcean has an excellent tutorial which runs you through setting up this kind of thing on a Linux-based box, and that’s available here: How to set up Automatic Deployment with Git with a VPS.
This is an excellent presentation, emphasising the need for, and benefits of, building Fast websites.
Getting into GitHub, for fun, kudos and all that jazz.
A brief talk introducing Grunt as a task management option for the development team.
Mixing a full-time job programming and hobby-time job blogging is a tricky balancing act. To the extent where I could give up on the blogging side of things for weeks, months or even years and not feel too bad about it. After all, we’re not in this for money, we’re in it for the kudos and warm fuzzy feeling we get from passively helping out other geeks.
However this presentation, and the conversations it prompted with work colleagues, has convinced me to take up blogging again. Hopefully it will inspire you in much the same way!
Ian Greentree, another of our Agile developers at MMT Digital has been writing about his experiences with Agile development on his blog, and gives us some of his tips for dealing with the stresses and strains of working in an Agile way.
As we become too stressed and anxious, we lose our ability to make informed decisions and problem solve. As a developer this has a direct effect on quality of the code we write.
Like many of us, he’s experienced the ups and downs of both Agile and traditional waterfall approaches for development, and if you’re interested in this sort of thing, check it out in his blog post: http://iangreentree.blogspot.co.uk/2013/05/developing-agile-mind-stress-and.html