Hacker News new | past | comments | ask | show | jobs | submit | kaveri's comments login

The template system rocks if you like handcuffs on your templates - and for some projects that may be the case.

Otherwise it's crippled in comparison to Jinja or Mako - with large amounts of un-Pythonic boilerplate if you want to write template tags.

To an extent you can replace it but again you will have trouble with those "reusable" apps.


I think it's better to keep additional logic in your page view functions instead of letting it bloat the template html. Why use a two pass method to parse your custom template logic into python code when you can just write the python code in the view functions?


Good point raised in one of the comments: why not have a giant wind platform out at sea to generate the hydrogen, and have tankers come and offload/replace the hydrogen tanks on a continuous basis ?


I think the point being made is that it has an API similar to the Django ORM, not that it is an ORM.


Link to petition ?


I'm not sure about the causes, but it seems in the UK for example that social mobility has decreased in the past few decades compared to the 1960s. A big part of that has been the disaster of comprehensive education - the old grammar school system, which selected children from poorer families, gave at least some a chance of climbing the social ladder. Comprehensive schools are more of a lottery than a meritocracy, and the wealthy as always have the option of fee-paying "public" schools.


Absolutely agree with you on most of the points. A couple of quibbles - Django now supports multiple databases (as of 1.2) and South (http://south.aeracode.org/) is more or less the default migration tool nowadays and is OK for most jobs.

Personally, I find generic views to be useless for anything but the simplest of prototyping. Making them functions rather than callable classes was a big mistake IMHO. I very rarely use them in a serious project.

Another pet hate is UserProfiles - you have to use a separate model if you want any custom fields for your users which entails a join whenever you want to use it. It's been a ticket for years but nobody seems willing to fix it.

I agree with you 200% on templates and am in a very similar situation. Having to write convoluted code in template tags for the simplest of things is frustrating, when you can have simple function calls and template macros in Mako and Jinja2.

I'm not hugely fussed about AJAX myself - I tend to keep things simple in the views and just pass JSON back and forth and jQuery does most of the front-end work. I disliked the Rails way of binding everything to a particular JS library, not sure if it's still done that way any more.

Django is OK for certain projects. What annoys me though is that like Rails, it has gotten such mindshare in certain companies that they call themselves "Django shops" and want to use it for everything, without considering alternatives. Personally I stay well clear of it for my own projects - Pylons, Werkzeug, SQLAlchemy et al are a lot more fun to work with.


>Django now supports multiple databases (as of 1.2) and South

I don't get to use either at work.

I don't really care for SQLAlchemy either.


There's still no reason to limit post size because Twitter does - title and shortened URL to the original post works fine.


It's a great idea in theory, the problem is that corporate designs go through ten different committees each wanting something different, so you end up with an unusable mess.


The process is described in vivid detail in the following comic by The Oatmeal:

http://theoatmeal.com/comics/design_hell - How a Web Design Goes Straight to Hell


Exactly, the first design mockup is the easiest part of the process.

From my experience, getting feedback from a small team in 20 person startup can drastically change the site from the designers original vision.

At the bigs companies there are many different stakeholders who need to be appeased. Some of the changes may seem illogical to the average consumer, but they might be well justified by management. For example trying to keep a few big corporate clients happy by including a large cheesy marketing message on the homepage.

Edit: But I admit, DHL is in desperate need for a redesign. Their website is awful.


I absolutely agree that big companies would dramatically slow down the development process. And that's why I put a disclaimer on each page saying it takes consulting and understanding of the problem domain to produce a final result. Mockup is definitely just a first step, but I figured it's the step that attracts an attention.


And it is interesting how different, huge, departments own various pieces of the web page--menu bar, right margin, left links, and so on. And fight for changes of any sort to their piece of real estate.


This. Plus people making UI decisions rarely have any experience in it. Yet they feel like they know everything.


Very nicely done. I take it this is running on Google App Engine ? (Just a guess, based on the Google Account signup).

No need to market it as just for rural locations. In the UK we have Gumtree for example, which is a serious competitor to Craigslist. While I agree to some extent with the idea of Craigslist's simplicity, I think it is becoming long in the tooth and unwilling to consider new ideas, and it's time for a decent, usable replacement.

Some IP-based geolocation would be nice. And some localization: "yard sale" and "apartment" for example are US terms. But that's nitpicking, which is a good sign :-)


Nope running at Linode. Postgres/postgis and mod_perl on the back end sending JSON to the UI rendered in javascript.

Thanks for the information on Gumtree. I will look at that.


Django != Python and Rails != Ruby. There are other solutions in either language that might suit your project better.


>There are other solutions in either language that might suit your project better.

What I use at work isn't up to me. I'm paid to work, not whine and whinge about the spade in my hand.


Who said anything about whining ? It is your duty as a professional to promote what you consider the best tool for the job. A spade isn't much good if your job is to rake some leaves.

Of course your advice might be overruled for perfectly valid technical or non-technical reasons. But by keeping silent and not suggesting alternatives you are doing yourself and your employer a disservice.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: