Saturday, 24 November 2012

Where is your site? Boy!!!

It's not something which gives you pleasure to publicly humiliate oneself; but I guess that's what I need just now.

It's been almost 3 years since I registered my domain.

And till this moment I failed to put a good website in there :-(
It's not because I can't code one, It's a child's play for me to put a site up (at least a basic one will take no more than few hours).

Yet, I've only a demo project in there. I should be ashamed.

Why didn't I put something up:
I've lot of lame excuses; yeah I'm good at it.

  1. I wanted an awesome design, And I didn't find one.
  2. I decided on a complex design involving lots of bleeding edge technologies, And I don't have a VPS/server.
    • Well, honestly, I only had resources for GAE, but still I could have managed an awesome site. "Kick my A**"
  3. I was so busy with work and creating solutions for others.
  4. I asked my friend to create a design for me, & he is yet to deliver it. Blame him, he is so lazy.

Enough, I can't take anymore abuse :'-(

Doh, Duh,
I sat down today and designed a UX for my to be created site. (Hah, at least... )



It's what I came up. We'll see how long I'll sit idle before turning it into a product.

Here's what I think about the stack.

  1. Google App Engine (GAE) as hosting platform. You know it's in cloud and is so scalable and blah.. blah.. (I don't have a VPS, probably don't need either, at least for now.). I wanted to try node.js
  2. Python as back-end: My plan is to create a REST api to serve data to view. Now presentation layer at back-end. Scala? might be!
  3. Big Table as my database. Why should I pay for Google Cloud SQL!
  4. Backbone or Ember as my view/front-end. These are so hot, so want to burn my finger.
  5. memcached to speed-up things - if wanted.
  6. And, usual HTML5, CSS3, JQuery stuff with html5-boilerplate & twitter bootstrap.

Wish me good luck & most importantly poke me & call me lazy if you doesn't see a site before next year.

A site can give me more visibility and leverage, still....

PS: All right reserved on the idea & design displayed in this blog post.

Friday, 16 November 2012

Correct way to structure your Django 1.4 projects




PS: This post is written assuming you're familiar with Django and at-least have some basic experience trying to set-up a Django project (for learning or for some cool project).

Purpose: To show how to properly set-up your Django1.4 project after seeing other developers getting it wrong (seen it wrongly structured by my mentee, senior developers and junior developers at my firm.).


Django 1.3 Project structure: Initial structure followed by two apps added to the project.
Django 1.3 Project structure: Initial structure followed by two apps added to the project.

Refer above picture, where I shown a Django < 1.4 project structure. (I know, at least Django 1.2 & 1.3 follows this structure).

First tree view is of the initial structure that you will get by calling
$ django-admin startproject Proj
Take a note that manage.py, settings.py, urls.py are in the main folder.
Following  tree display is after creating two apps named app1 & app2. You'll do it as follows

$ ./manage.py startapp app1
$ ./manage.py startapp app2
Those apps are created in the same level as settings.py and manage.py

Django 1.4 Project structure: Initial structure followed by two apps added to the project. And at last a wrong structure that I've seen people adopting.
Django 1.4 Project structure: Initial structure followed by two apps added to the project. And at last a wrong structure that I've seen people adopting.


Now,  Django 1.4 changed this organization slightly. They now make settings.py & urls.py into a separate module (or app, whatever you like) along with added wsgi.py (which can be used as is for your Apache wsgi configuration, in most cases).

First tree view shows basic project structure after createproject.
~/Django1.4/bin/ $ django-admin.py createproject Proj
Note that an module called Proj is created with settings.py, urls.py and wsgi.py within Proj main folder.
You can rename main folder to anything you wanted (or keep it as it is).

Also note that manage.py is still kept at higher level (although Django1.4's manage.py is different from from the manage.py found in earlier Django releases).

Following tree display is obvious & correct way to structure your project. It's result after running startapp to create two applications app1 & app2.
~/Project/ $ ./manage.py startapp app1
~/Project/ $ ./manage.py startapp app2
Now app1, app2 and Proj modules will be available to each other if outer Proj folder is in python path.
Which will be in path, because manage.py is kept at outer Proj folder and runserver will do the necessary. Here every apps and django settings & routing are kept as separate modules. Isn't this great?
Well, I like it, it help me better organize things and was so obvious for me from start.


Just to show how others get it wrong by emulating previous project structuring - i.e.,your apps laying beside settings.py, urls.py and all (you know, we hate change :-/ ) -  see the last tree view.
Now, you have one app/module called Proj and your supposed to be apps app1 & app2 are - well correctly speaking - become sub-modules of your app called Proj.

Does it make sense now! Well then I succeeded, if not go and read from beginning, shoot me a mail, leave a comment or abuse (at least show some passion; eventhough I'm going to delete most of 'em anyway). 
Caution: Some might even try to copy manage.py into Proj module ;-)


Update:  An attempt to make it a screen cast happen just after posting this. I know there're lots of rough edges out there. Please bare with me and provide constructive feed-backs.
Find it at YouTube Or Vimeo

'