Fauzism

Feb 26

Bravura - First Look

My latest project on GitHub.

Bravura - A Visualization tool for Time-series data.

It requires mongodb, numpy, and web2py. I plan on removing web2py dependency and ship it with some sort of self contained web server.

Apart from that, it uses Flotr, isotope, jquery and protoype on the front end.

I have committed the first draft. Its a shitty piece of code right now, but I mean to improve it soon.

You can of course start using it even now. Check out the screen-shots.

I spent a lot of time choosing the color palette. Time well spent!

Feb 14

To Shalu

Jul 26

Shivling : Avoiding boilerplate in views in Django

I have been unable to find time to continue my Shiv series, however, a chat with a friend(@arihersh) who has just started learning django reminded me of a small piece of code I had written sometime back. The chat went something like this

Ari Hershowitz:
I’d like to have html “widgets” that have certain actions, without having to create an artificial url + view to control the widget.
Maybe that’s what your framework does?
Yousuf Fauzan:
gimme an example
Ari Hershowitz:
Ok…
I’ll try to describe…
I want to create a search bar that goes on any page.
To do this in Django, I think I need to: (1) create a search form, (2) put it into a template, (3) include the template into any other template.
I also need to create a view for the search bar, with its own url, right?
Yousuf Fauzan:
you need a search result view
Ari Hershowitz:
So if I have the search bar on page x, I’ll have to call the search bar’s url from page x.
Yousuf Fauzan:
i.e. the url that the searcdh form will post to
Ari Hershowitz:
Yes, actually that’s the issue:
I found that on each page I include the search form, I’m writing a lot of boilerplate code into *each* view of the pages that use the search form.
What I’d like is to write the template and view for a unit once (e.g. a search form). Then only have to include it in the other page’s template, without making any changes to the views in order to pass variables around

Read More

Jul 06

Shiv The Third - Return of Tutorial

Continuing from my previous posts on Shiv, Shiv - A wrapper over Django and Shiv - Part Deux, I will now try to explain about various components involved in Shiv. In this post we will talk about Media and Element. In later parts, we will explore Tabs, Boxes, Widgets, Pages, and Caching.

An app using Shiv should have the following files
1. page.py: This will contain the definition for all Page container classes
2. box.py: This will contain the definition for all Box container classes
3. widget.py: This will contain the definition for all Widget container classes
4. tab.py: This will contain the definition for all Tab container classes
5. element.py: This will contain the definition for all Element container classes
6. media.py: This will contain the definition for all Media classes
Media

Media classes define the various media used by all the containers of the Project. Shiv uses a naming convention for media classes. The media class of a container class named “ABC” should be “ABCMedia” and it must be derived from shiv.media.Media.

Read More

Jul 03

Shiv - Part Deux

After debating whether to release early or release well, I have settled for the former. I hope that once the code is out in the open and I get ridiculed for the lousy code quality, it will motivate me to find time more aggressively to correct and refine the framework.

I will try to find some time to continue my little tutorial of Shiv with sample applications in the next installment. In the meantime, here is the link to the git repository. Have a look and feel free to ask me any question that you might have.

https://github.com/lzdev/Shiv

Part 1 | Part 3

Jun 19

Shiv - A wrapper over Django

I joined LazyZach as the first hire back in 2009. I was already in love with Python by then and when it came to deciding which technology to use, the answer was quite obviously, Django.

While Django does speed up development, I wanted something a bit more streamlined to my thought process. Having my “views” all over the place was definitely not the way I wanted to go. Plus, there was a need for a more clear separation of back end and front end tasks (I was, and still am, a bit weary of all the html and css stuff that goes around). All this and some more made me develop Shiv, a thin wrapper over Django.

For all those Django noobs out there, one thing I wish to say is that “Django is Python”. Realize this, and life will be so much simpler for you. And yes, do not go about learning Django, learn Python and you will know Django inside out.

In this post, I will discuss the basic idea behind Shiv. Other key features and benefits like AJAX handling, Widgets, auto JS/CSS minimization, will be discussed in later posts.

Read More