(No boats were harmed, involved, or even really alluded to in the making of this post)
I think it’s possible to accumulate “intellectual debt”. Thoughts and ideas that you’ve had, worked on, developed, talked about, but have not written up and published. You can have an idea, but until you’ve tried to write it up properly such that someone else could read and criticise it, you can’t be sure that it actually makes sense.
I’ve finally found the time to sit down and start using Vagrant for Real Things. For the unaware, Vagrant is essentially a tool for managing development VMs – excellent for such things as managing a local development environment, or developing and testing Chef/Puppet configuration. For more detail see the excellent set of slides by Vagrant author Mitchell Hashimoto – Develop and Test Configuration Management Scripts with Vagrant.
I was reading through the ElasticSearch Guide this morning and found me a typo.
This is nice. This is so much nicer than the other all-too-common model:
- Find appropriate contact method, be it a web form or email address somewhere on the site
- Email them a description of the issue
Sometimes I get a reply. Sometimes I don’t. It’s all too fire-and-forget. What GitHub gives me is visibility and openness. There’s now a public URL for my pull request / issue. The “open requests” count increments. This doesn’t sound like much, but it’s important. Anyone visiting the repository sees the count. Anyone can see the issue.
Features include reputation tracking and graphing, to see how you’re doing compared to your friends and rivals, and a detailed comparison tool, so you can see exactly what badges someone has compared to you, and vice versa.
(Note, if you haven’t read it already, I recommend my previous article on Django and Static Files to get an understanding of the fundamentals)
Pretty much every Django project I deploy, I use Amazon’s Simple Storage Service (S3) for hosting my static files. If you aren’t particularly familiar with it, then the salient points are:
I’ve been loitering in #django on Freenode recently, and misunderstandings about static files have cropped up enough that I figure me putting this together might help.
A typical Django project will have multiple sets of static files. The two common sources are applications with a
static directory for media specific to them, and a similarly-named directory somewhere in the project for media tying the whole project together.
The folks over at NHS Hack Day put together a presentation on SlideShare with a list of all the projects, and of the judges – check it out for for a good overview of the kind of things that people put together.