Book Review: Instant Django 1.5 Application Development Starter

By jama22 | Published: April 2, 2013

51PkWx9l59LPackt Publishing recently contacted me to do a review of Mauro Rocco’s “Django 1.5 Application Development Starter“.  As someone who only dabbles with Django in his spare time, I’ve found it very difficult to keep up with the changes that come out with each major releases.  For me, Rucco’s  book promised to be a good way to get back into the meat of Django with some practical, hands on examples.

The good news is that the book is quite short (< 70 pages) and is a very easy read.  Rocco’s code snippets are project-driven examples that are easy to read and quite simple to follow. Unfortunately, having said that I am hesitant to recommend it to a newcomer to the Django framework.  In his attempt to distill the essentials of Django into less 70 pages, he has completely overlooked some of the most fundamental concepts in Django. As Rocco begins to explain the Django framework structure, he dives right into the creation of Models without having first explained what an “application” was in the world of Django. In the section titled “Top 6 features you need to know about”, Rocco totally overlooks the basic function of serving static content on your pages. Furthermore, Rocco’s examples uses an older syntax for method-based Views instead of the “newer” class-based Views which were introduced in Django 1.3. In fact most of the code snippets in this book are explained in a very matter-of-fact style; not much time is spent discussing further readings or best practices. I understand that certain sacrifices must be made when writing a beginner’s tutorial, but I feel that Rocco could have done a better job discussing “next steps” for those who are aching for more formal knowledge.

If you’re looking to get started with Django, I would point you to the official documentation instead: https://docs.djangoproject.com/en/1.5/. Once you have mastered the tutorials there you can find plenty of advanced topics online through forums and blogs.

Rating: 2/5

 

Posted in Django, Tech | Tagged , , , , , , | 3 Responses

Product Review: Podio

By jama22 | Published: December 6, 2012

I’m always working with a host of project management and collaborative software suites to help manage and track my team’s progress through a project.  In the past I’ve reviewed  popular agile software platforms: IceScrumm, ScrumWorks, and Jira + Greenhopper.  While working for Rogers I was begrudgingly forced to use Rally and its suite of requirements tracking tools.  Thankfully I had a great scrum master and we reverted to physical post-it boards for the meat of the team’s planning and estimation work.  At InViVo, where I was Project Manager for a short stint, I used  Redmine to track bugs and requirements across multiple micro-projects.  In my down time my preferred go-to resource for all my side-projects has been  PivotalTracker.  Pivotal has a super-simple, intuitive UI, it works on desktop and mobile and it allows me to collaborate with my team on user stories in near real time (seriously, check it out).

Having used so many variations of project management software and collaborative tools, you can understand my reservations about Podio.  When I first read about Podio it sounded too good to be true: its social, its collaborative, and it merges the needs of the project manager, the accounts director, the marketing guru, the HR manager and the development team.

The Good News

I honestly and truly believe that Podio can do just that.  It really can help my HR manager and recruiter to find the perfect candidate.  It really can help me organize events and promote discussions around what color tablecloth to use.  It has a slick UI with lots of Facebook-like elements.  It’s also super simple to add users to a workspace from within your organization, or even from external systems like Google, Live, GoToMeeting and Facebook.  I’ve browsed the app store and some of the workflows in there are amazing.  There’s definitely a strong community of followers developing and customizing apps for their Podio needs.

The Bad News

My team uses absolutely none of those workflows.  As a software development and design production house, we needed a precision tool for requirements and bug tracking.  What we really got was a social collaboration tool that is focused on discussion and not the item of change itself.

“But James, Podio has a Bug module for all of its workspaces!  What do you mean it doesn’t do bug tracking?”

I’m glad you asked!  Yes, Podio truly does have a Bug module for most of its workspaces.  To the casual observer it appears that it has all of the necessary ingredients for a bug tracker: a list of bugs, status, severity, priority, adding bugs, assigning bugs, etc. But once you start to use the module on a day-to-day basis you slowly begin to realize that the Bugs module simply isn’t meant for any level of serious defect management.

GUI Glam Over Function

This is a screenshot of the Bugs module for a real project that we are working on and tracking in Podio. The first thing you’ll notice is that everything after the Priority column is cut off.  This is intentional and incredibly annoying. Imagine for a second that you are a project manager who has to triage the 572 defects which reside in this project.   When triaging defects, every project manager is looking for an at-a-glance overview of key essential information: description, priority, severity, status, responsibility, date entered, project.  By default I can see 3, maybe 4 columns of data if I really know table’s column arrangements.  I blame the restricting table view on Podio’s  three column page layout; its is incredibly limiting and prevents me from consuming any significant amount of data.  Yes, Podio looks really pretty and it has lots of fancy sliding divs, but it makes life incredibly difficult for me to compare and contrast bugs.

To be fair, the Bugs module has four other views: Badge, Card, Activity and Calendar.   Unfortunately for me, none of them are much better than the Table view of the bugs seen above.

The Fundamentals just aren’t there

Notice how the Low Medium and High labels under the Priority column are highlighted green (green= good), whereas URGENT labels are highlighted in yellow (yellow =not so bad).  It doesn’t take a UX expert to understand that the colour green is often equated to “good” or “go ahead” in most cultures; so one should always be hesitant to apply this colour to Priority labels.  I cannot understand how the Podio team overlooked this simple but essential UX element.  Automatically color coding defects using a sensible colour scheme is the most elementary feature for any defect management suite.

Podio also doesn’t tell you the exact date and time a bug was entered, when the bug was modified, and who executed the change.  As a project manager and a former QA team lead, this is a deal-breaker.  My QA team is going to hell of a time doing regression testing if I can’t find the original developer who marked a defect as fixed and when he fixed it.

I can go on and on about Podio’s lackluster attempt at creating a bug-tracking application.  The few issues that I have already identified should already tell you that the Podio team did not design the Bugs module with serious software development in mind.  I can imagine how this lightweight bug tracker could be used to manage Events or minor projects, but I would not recommend it as a serious requirements or defect tracking tool.

Posted in Mangement | Tagged , , , , , , , , , , | 6 Responses

The Dangers of Points Based Heuristic Reviews

By jama22 | Published: November 12, 2012

For those who are unfamiliar with the concept, points based heuristic reviews are an attempt at creating a formalized website review process. In a points based heuristic review the usability expert will reward points to predetermined categories based on how well a site satisfies the selected usability heuristic.  Using this system a reviewer can establish a numerical scorecard for the website.  In theory these numbers can be used to identify key areas where the website is weak and be used as a baseline for competitive analysis against other sites.  Smashing Magazine has a good writeup the process here: A Guide To Heuristic Website Reviews

One of the biggest dangers of heuristic reviews is the equal-weighting points system. According to the article on Smashing heuristics can be assigned a value of 0, 1 or 2.

0 points if it falls short of a metric, 1 point if it’s halfway there, and 2 points if it does the job

Consider the following heuristics:

  1. Customers can submit reviews on products
  2. L1 Navigation highlights the users’ current position in the site

Let’s say you’re reviewing an online e-commerce platform. The impact of not being able to satisfy heuristic #1 is significantly more detrimental than not being able to satisfy heuristic #2.  And yet both heuristics are given the same weighting in this scoring system.  In other words, missing out on 2 points because of missing customer reviews should mean a lot more than missing out on 2 points because of menu highlighting.  This relative ranking of heuristics is missing from the equal-weighting points system.

One solution to this problem might be to introduce a more granular breakdown of heuristic #1.  Instead of a single rule worth 2 points, let’s split it up into multiple heuristics:

  1. Customers can view reviews
  2. Customers can submit reviews
  3. Anonymous customers can submit reviews
  4. Customers can review submitted reviews
  5. etc.

While these are valid heuristics, the analysis itself runs into the danger of introducing too much “fluff” into the overall analysis.

Another method may be to adjust the equal-weighting scoring so that heuristics that are deemed to be more important use a 0 – 4 range instead of the standard 0 – 2.  Personally I would prefer this method over introducing more rules as it visibly affects the overall score-total for the heuristic’s category.  However this introduces the complexity of identifying important heuristics and scaling them appropriately.  Maybe some rules should be 0 – 8, or 0 – 12!

Posted in General | Tagged , , , , , , | Leave a comment

18 Wheeler Shopping Trips

By jama22 | Published: November 11, 2012

The other day a buddy of mine posted a link to this article in The Register on his Facebook feed: Twitter survives election after Ruby-to-Java move.  He followed it with a bold (and honest) question: why did Twitter choose to use an unproven platform like RoR in the first place?  Before I describe what happened next, a bit of full disclosure: 99% of the time I’ll lurk through similar discussion threads on Facebook but never comment.  I don’t like to subject my non-geek Facebook friends to tech rants and I honestly believe that places like HN, SO, /r/programming, etc. are more suitable discussion platforms for technical discussion.  So when I decided to throw my two cents into the discussion it was because I was deeply annoyed.

Don’t Use an 18-Wheeler for Shopping Trips

The 18-wheeler tractor trailer is an essential mode of transportation.  Surface trade conducted by truck between Canada and the US totaled 24.5 billion by December 2010 (source).  It is a proven method of transporting goods between cities in a quick and efficient way.  There’s even an interesting study done by the Swedish Association of Road Haulage Companies done in 2009 about “A Week without Road Transport” (source).

Sure, the 18-wheeler is an awesome truck, but you won’t see me using it for my weekly shopping trips!  It sounds silly that I even suggested that I could use an 18-wheeler for a trip into town, but that’s exactly how I feel about the: “Why use <new technology X> when you can use <proven technology Y>?” argument.

6 years ago Twitter Inc. was just one guy with an idea. Sure, he could’ve written a huge monolithic version of Twitter using Java, but at what cost? What’s the time to market on something like that? its flexibility to adapt to changes? Was RoR the right choice? maybe not. But imo if you’re making a web app to test a theory (will people use this app?) that needs to constantly adapt to user requirements (@ referencing and RT wasn’t built into Twitter v1.0) with a limited staff, you use what works. When they decided to move on to Java they again did the right thing, they bit the bullet and did full re-writes on core packages. Most companies wouldn’t even consider such “drastic” measures. Are standards the solution to that? probably not. What the industry really needs more guys like Twitter who can look past the sunk-cost fallacy and deliver better customer experiences.

You see, the argument isn’t just “should we use A or B?”.  The real question is: “does using technology A or B help us finish the app as quickly as possible within the confines of our existing resources”?  And then as time moves forward and you become successful like Twitter Inc., the followup question should be: “what do we need to fundamentally change to address our customer needs?”

Who knows, maybe you need to start taking 18-wheelers into town so that you can start supplying grocery stores with produce.

Posted in General | Tagged , , | Leave a comment

AJAX JSON Responses using Django class-based Views

By jama22 | Published: May 14, 2012

Class-based generic views were introduced in Django 1.3. This is a pretty big game changer compared to the “usual” definition of views as functions. Unfortunately, if you go through the official documentation, you’ll find that most of the explanations are very surface-level. You’ll find some very generic usages of Mixins and generic Views, but less about customization and AJAX-y type calls.

In my particular usage of class-based views, I want to respond to an AJAX call with a JSON dictionary. In the old world, this would’ve been quite straightforward as there are plenty of articles, tutorials and blog entries which describe this process. In the new class-based views, the only hint you get is in the “More than just HTML” section of the docs. After a bit of fiddling, I was able to figure out how to do it, so I’m hoping to add to the conversation by outlining my solution.

Read More »

Posted in Django | Tagged , , , , , | 3 Responses