We are announcing a new library that adds ability to build your Django urls in Javascript without copy-pasting or building urls by string conctatenation.
Don’t-Repeat-Yourself (or DRY) is one of the main principles of Django framework and writing applications with Django. The DRY principle is stated as “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.”
DRY aids with maintenance and understanding of the application code.
Django’s solution for not hardcoding urls in HTML is called named url patterns which allows you to reference paths by a predefined name. Sadly, no such logic exists for Javascript as Javascript generally is not run through Django template processing due to overhead considerations.
And so, developers hardcode their urls for AJAX requests which is not only repeating the same information already defined elsewhere, but can also make parametrized urls impossible to read as string concatentation is excessively used.
We have built upon a solution already created by Marco Louro (mlouro on GitHub) and used his Javascript reverse function, but added a way to automatically build a list of all Django urls in your project and output them to a Javascript file.
You can easily hook into your build process by using the management command provided. The command looks through urls defined in your Django project and builds a list of the paths. It also recognizes where the parameters are expected and converts the parameters, named or otherwise, into an easier format for Javascript to process.
After including the library and the resulting files to your webpage, you can build your urls as such:
I just found this quote from the Mythical Man-Month by Fred Brooks. I have read the book before, but must admit I failed to see this quote. It is almost comical how well this describes reality.
It is very difficult to make a vigorous,
plausible, and job-risking defense of an
estimate that is derived by no quantitative
method, supported by little data, and
certified chiefly by the hunches of the
managers.
— Fred Brooks (1975)
I always had an inkling to learn more formal ways of software estimation than the ones I practice. It would be nice to deliver an estimate with a bit more comfort. My current estimation method revolves estimating the complexity, looking at the past mistakes, and adding a decent buffer.
That quote from Brooks is just plain awesome…
At Lights On Software, we were doing quite a bit of interviewing over the last few months. We specialize in Django software development and we interviewed candidates for Django contracting positions. I did a quick search on the Internet to find a good base for my list of questions, but unfortunately, the search didn’t yield many results. So half an hour later, I had my own list and hopefully some of the readers will use it for their own interviews.
All recent positions we hired for were contract and we skipped the usual HR-style questions such as ‘Where do you see yourself in five years?’, ‘What are your weaknesses?’ and concentrated on figuring out if the person is qualified for the job we have at hand.
The usual disclaimer: the questions are higly subjective on our experience and your milage may vary. For example, we are located in Canada and the two official languages empose specific requirements – we frequently internationalize our apps. Moreover, these questions will test only knowledge and will not test unimportant traits such as problem-solving skills, initiative, and ability to research and learn on the job.
Warm-up:
How are you using Django? What sorts of projects have you worked on and in which capacity?
What do you like about Django? Python? Compare Django with other frameworks you have used.
Describe how Django is MVC? or shall we say MVT:)?
How good are you at estimation? Everyone is bad at estimates. You are looking for people who know that they are bad and multiply their estimates by 2 or 3.
Do you test code? It is strange if the candidate never tested code, but it is equally suspicious if she keeps going on about the benefits of TDD. We love the idea of TDD, but in practice, very few organization, clients, and the developers have patience to do it properly.
More technical:
To assess the depth of the person in a certain topic, I usually start with a general question that everyone should know and then move into more specific areas probing if the person has been exposed to some of the finer details.
It is unlikley that the candidate will fit perfectly and you should give people the benefit of doubt as long as they meet your broad criteria. Also, learning individual things on this list will be easy, but learning a multitude of different things will take a couple of months at least.
What Django tools and pluggables are you using or aware of? South, multilingual, tagging, profiles, registration, etc. This question is very useful in order to understand how long someone has been developing with Django.
What are the named url patterns? What is the url template tag and what is its usefullness?
Tell me about a templating system in Django. What is template inheritance? How do you get contents of a parent block?
What is a template tag? What is an inclusion template tag? How do you create a template tag?
What is ORM? Why is it useful? How does Django accomplish such functionality? What is model inheritance? What types of model inheritance are there in Django?
In table inheritance, how are the two tables related? (the pointer mechanism)
How would you internationalize Django application? (if it is important) How would you internationilize values stored in the database?
How do you extend a user profile in Django?
What is a forms framework? How do you use it to create a form? What is a shortcut way of creating a form for a model?
Describe signals in Django? What is their usefulness? What design pattern do they remind you of? How would you implement the above mentioned design pattern? ( My favourite question )
This is about an hour of interviewing right there. Feel free to add your questions below in the comments.
Shameless self promotion -> Meanwhile for all those of you who are looking for experienced Django developers, there are a couple available at Lights On Software
First, let me touch upon our motivation to use Wave. I learned about Google Wave when Lights On Software was hired in the beginning of July to work on an exciting new project that entailed building an accounting system for small businesses. This was my first time hearing about Google Wave.
I went and watched Google I/O video …
…that presented a product in a great light and got everyone excited. To me, the excitement of the audience was a warning sign – I did not want to invest my time in learning another bubble technology the way Facebook Apps were in 2007 and Google App Engine was in 2008. Since then, I take the new technologies with a grain of salt buying into them only if there is a real tangible benefit.
Let’s take a step back and clarify what Google Wave is all about. I know some of you are getting tired of this, but what is Google Wave? Here is my take on it.
Google Wave is a new communication platform unifying multiple modes of communication methods IM, Email, and document sharing attempting to solve an issue of email being used for what it is not well-suited for. Incidentally, Google Wave also solves the problem of unifying the knowledge from disparate sources: emails, shared documents, or IM conversations.
I rationalized Google Wave as a useful platform when I remembered how many abuses our emails take on a daily basis. Have you ever used email to have an IM-style conversation -“Hey, let’s have lunch at 1pm… Burrito Boys”? Have you used email to share documents back and forth? Have you tried searching for a tidbit of info from a client in your email and the documents attached, and then trying to remember if one of the developers already fixed the issue?
This is an problem experienced by every business in every industry – the bigger the project the more common the problem. We use Basecamp for project management, and I keep thinking how much better it would be if it was Google Wave enabled! I particularly miss IM-style conversations in Basecamp.
Enough of Cool-Aid drinking, let’s roll the sleeves and get our hands dirty.
For the particular problem that Lights On Software is facing, embedding Waves into web pages, makes the most sense thus embedding is the first place I decided to checkout.
I went on the website and tried to follow embedding tutorial which to my amusement did not work. This is significant deviation from old Google days when Gmail was in beta and was already production ready. There are a couple of non-trivial small gotchas that, hopefully, this tutorial will help you avoid.
I am assuming that you already have a Google Wave Invite. If you don’t, feel free to contact me limited quantity available for $5K each (People tried).
Step 1. Please login to the sandbox server. This itself presents a feat, as it is not clear how to do so. There are no links from the API docs to the sandbox server only from the invitation email – I understand the reasoning, but not very user-friendly. Currently, there is only one Google Wave server – https://wave.google.com/a/wavesandbox.com/, but there will be more in the future. In fact, you will be able to run one yourself to host your enterprise data separately from Google. Is Google trying or what?
Step 2. Create a new Wave that you would like the public to see. I use the term public loosely. Currently, it is rather elitist crowd flashing their invites left and right on Twitter. Once you create Wave, notice a small Debug menu link in the top-right corner. Choose the Wave Id menu option, you will need to substitute this in the sample HTML that tutorial provides.
Step 3. There are also couple of useful robots that aid you with the embedding of Waves. For example, Embeddy – embeddy@appspot.com posts a usable tutorial HTML with the Wave ID already substituted for you. Also, there is Madoqua Wave Bot blog-bot@appspot.com that print the id for the Wave you are in (be carful HTML created is using production server that is not live yet).
If you are planning to make available publically, do not forget the bot that allows public access – public@a.gwave.com. Hint: first add this address to your contacts, and then add this bot as a participant on the wave – he will add everyone to your wave.
Step 4. So, finally, you are sick of my rumbling and you have a page that contains HTML similar to what Embeddy posted on your Wave. Refresh the page, if you get a blank page, most likely you are running Firefox. Firefox(below 3.5) is not friends with HTML 5 and for best results use Safari or Opera.
If the page asks you to login, open another tab, the login process will not redirect you back to your page.
That’s it for today!
Let me know if you have any questions or trouble getting embedding to work!
