I'm trying a new format for content, instead of writing I've recorded some audio, I think this will be a better format for my to share ideas. You can find the audio here.
PS: If you know a better workflow for sharing audio like this, please let me know.You can find the rest here. There are view comments.
For the past month or so I've been using a combination of Google, Stackoverflow, and bugging people on IRC to muddle my way through using various VCS that I'm not very familiar with. And all too often my queries are of the form of "how do I do git foobar -q in mercurial?". A while ago I tweeted that someone should write a VCS translator website. Nobody else did, so when I woke up far too early today I decided I was going to get something online to solve this problem, today! About 6 hours later I tweeted the launch of VCS translator.
This is probably not even a minimum viable product. It doesn't handle a huge range of cases, or version control systems. However, it is open source and it provides a framework for answering these questions. If you're interested I'd encourage you to fork it on github and help me out in fixing some of the most requested translation (I remove them once they're implemented).
My future goals for this are to allow commenting, so users can explain the caveats of the translations (very infrequently are the translations one-to-one) and to add a proper API. Moreover my goal is to make this a useful tool to other programmers who, like myself, have far too many VCS in their lives.You can find the rest here. There are view comments.
I read just about every single ticket that's filed in Django's trac, and at this point I'e gotten a pretty good sense of what (subjectively) makes a useful ticket. Specifically there are a few things that can make your ticket no better than spam, and a few that can instantly bump your ticket to the top of my "TODO" list. Hopefully, these will be helpful in both filing ticket's for Django as well as other open source projects.
- Search for a ticket before filing a new one. Django's trac, for example, has at least 10 tickets describing "Decoupling urls in the tutorial, part 3". These have all been wontfixed (or closed as a duplicate of one of the others). Each time one of these is filed it takes time for someone to read through it, write up an appropriate closing message, and close it. Of course, the creator of the ticket also invested time in filing the ticket. Unfortunately, for both parties this is time that could be better spent doing just about anything else, as the ticket has been decisively dealt with plenty of times.
- On a related note, please don't reopen a ticket that's been closed before. This one depends more on the policy of the project, in Django's case the policy is that once a ticket has been closed by a core developer the appropriate next step is to start a discussion on the development mailing list. Again this results in some wasted time for everyone, which sucks.
- Read the contributing documentation. Not every project has something like this, but when a project does it's definitely the right starting point. It will hopefully contain useful general bits of knowledge (like what I'm trying to put here) as well as project specific details, what the processes are, how to dispute a decision, how to check the status of a patch, etc.
- Provide a minimal test case. If I see a ticket who's description involves a 30 field model, it drops a few rungs on my TODO list. Large blocks of code like this take more time to wrap ones head around, and most of it will be superfluous. If I see just a few lines of code it takes way less time to understand, and it will be easier to spot the origin of the problem. As an extension to this if the test case comes in the form of a patch to Django's test suite it becomes even easier for a developer to dive into the problem.
- Don't file a ticket advocating a major feature or sweeping change. Pretty much if it's going to require a discussion the right place to start is the mailing list. Trac is lousy at facilitating discussions, mailing lists are designed explicitly for that purpose. A discussion on the mailing list can more clearly outline what needs to happen, and it may turn out that several tickets are needed. For example filing a ticket saying, "Add CouchDB support to the ORM" is pretty useless, this requires a huge amount of underlying changes to make it even possible, and after that a database backend can live external to Django, so there's plenty of design decisions to go around.
These are some of the issues I've found to be most pressing while reviewing tickets for Django. I realize they are mostly in the "don't" category, but filing a good ticket can sometimes be as good as clearly stating what the problem is, and how to reproduce it.You can find the rest here. There are view comments.
Today's post was originally supposed to be about my work on multiple database support for Django, but I'm exceptionally tired so that's been bumped to tomorrow, sorry. Instead I'm going to use today's post to give a thank you to some software I use that doesn't get enough press, and that surely deserves a thanks. I'm not going to be listing any libraries or programming languages just the desktop software I run day to day:
- Chromium - I've been super please since switching to Chromium for my day to day browser, it's very fast, but I wish it had plugin support, and a debug tool like Firebug.
- Firefox - My development browser, the cornucopia of plugins makes my life easier, everything from Firebug to DownloadThemAll.
- XChat - It's my IRC client, I probably log about a dozen hours on IRC per day, maybe more. The biggest wart I have with it is that ctrl+l clears the screen, and that's not bad for software I use for 70+ hours a week.
- Gedit - It's my text editor. Syntax highlighting, file browser, proper indentation support, I'm not sure there's a whole lot more to ask for.
- Skype - Between using it to record DjangoDose to catching up with friends it's an invaluable asset.
- Ubuntu - My operating system, by extension the Linux kernel, Gnome desktop and everything else that goes into it should all take a bow.
And that's pretty much it for desktop software, I took a peak back at my list from last year and it's almost identical, I guess all of this software is doing something right. I also wanted to take a minute to thank various web services I use:
- Pandora - I blow through my monthly allowance of 40 hours in one week. I think that says something.
- last.fm - I love the fact that it tracks all of the stats about the music I listen to. I really wish it had a way to combine the "music neighborhood" and friends features to find people in my social graph with similar taste in music.
- Github - It really is the bee's knees of code hosting software. There's very little to say other than the number of repositories I have should stand as a testament to its quality.
- Blogger - I use it to host this blog, and while I'm actively working towards moving away from it, for now it stays and it deserves a thank you.
- Invoice Machine - It takes most of the tedium out of dealing with invoicing, I'm grateful for that.
And that's my list. I promise that tomorrow I'll have my post on multiple database support. See you then.You can find the rest here. There are view comments.