Makai's Blog
Month
Arin Sime, founder of AgilityFeat and one of my former classmates at UVA, put together this great email course on the Agile Methodology. It’s great for those unfamiliar with Agile (especially clients you are trying to convince to use it!) and brushing up on your concepts.
Highly recommended!
At 26 minutes into this video, the presenter gives a great summary and example of what a closure is in general and in JavaScript. The entire video is worth watching if you have the time.
One of my coworkers didn’t like my 10ish parameter argument Java method during a code review. I admitted it looked awful and modifying the parameters to pass in was a serious annoyance. We end up refactoring the code to use an intermediate object, which worked fine. But I wondered why I haven’t faced the same thing in Python during my Django projects.
Then I realized - when specifying any more than a couple of parameters in Python I name them as they go in. Named parameters make it easy to mix and match the parameters without getting confused.
Java needs to get with the program. Except for C and C++, Java is the only major language that doesn’t support named parameters.
There was an interesting video of a talk given by Alex Gaynor, a Django core committer, on the direction of the framework. Here’s the summary of what’s coming.
There is currently no release date set for Django 1.4 although work towards 1.4 happens in the public development trunk that can be checked out with SVN (http://code.djangoproject.com/svn/django/trunk/).
Django 1.4 will drop support for Python 2.4. The motivation behind the change is to use more context managers, a creation from Python 2.5, and make the internal Django code better.
Alex sees future base Django installations coming with less “stuff” by default with the option to install packages specific to your needs. For example, the EmailBackends would be an interface that if you needed SMTP support you would install a separate module to use.
Several current efforts for Django 1.4 or beyond that are going on are template compilation, composite fields, and making templates and forms better. Template compilation is a refactoring of the way the templating system works behind the scenes. The idea is to genericize the way templates work so other templating systems can use the shared infrastructure. Composite field improvements will enable better ways to query the database. Forms are difficult to work with in templates so this effort aims to improve how forms can be used within templates.
It’s interesting to see the dramatic change going on in the Rails community over 3.0/3.1 compared with the steady plodding along of Django. As both a Java and Python developer, it’s much easier to keep up with Django and know that my framework knowledge won’t be out of date within a year.
If you have team of 16 developers and they spend 30 minutes in a meeting that does not help you get the product out the door, you’re 1 man day behind where you were before you walked into the meeting.
For every additional 15 minutes the team spends sitting around and not solving technical or project problems beyond that 30 minute meeting, you’re losing a ½ man day of work.
People need to meet to pool talents and solve problems, but everyone in the room that isn’t contributing is simply wasting her time. Math doesn’t lie: you’re wasting man hours sitting there not solving problems. Eliminate unnecessary meetings or you won’t make your deadline.