Since I’m using GitHub for the ProjectPier work I’m doing, one of my senior colleagues at Tactica mentioned that GitHub has a resume creation app, that nicely showcases the different work a developer does through their service. Here’s my GitHub resume.
I tweeted about that, and the always friendly Web Development Instructor at Red River College, Kyle Geske, replied with a link to his GitHub resume.
A GitHub resume, based on a history of code commits that a developer has made can be a valuable resource to use when looking for a new job, because it shows the ability to develop software.
Create yours and link it here if you please! Oh, and you can fork the code and contribute enhancements.
I’ve been tasked with revamping the backup strategy at my new job, and I think I am finally happy with what I’ve come up with. As usual, I’m wondering what others have done when they were tackling such a task, and what you, dear reader, think about my setup. Please leave me a comment if you want to share your thoughts, or links to articles you’ve read that relate to anything discussed here (along with a short description of how it relates).
With websites, it appears there are three distinct data components that require backups: Code, content files, and the database. If you implement a well-thought-out version control setup, you can keep only one backup of the current repository, since it in itself contains all the revisions.
- Code only ever changes when the developer makes an update, and always changes on the development server (I swear!). The developer commits his changes to version control manually, and then uses a deployment automation tool to publish the changes to the production server.
- With content files and the database, the changes are mainly done on the production server, and since we are not going to ask the user to commit to our version control system, this should be automated, either at intervals, like daily – or if it is plausible – just-in-time, directly triggered through the CMS when content is added.)
With incremental backups to Amazon S3, we used to pay about $1/month for this service at the medium-size call centre I used to work at, so that part should be fairly inexpensive, but the overall cost of this setup is significantly higher if you are paying for a hosted VCS.
Again, I would really appreciate your thoughts on this, and links to articles written based on what others have learned from experience in this area. Thanks for reading!