Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lessons learned defying Joel Spolsky with Django

speakerdeck.com

Post reply on HN
Print view View original

91–100 of 155 posts

Re: Lessons learned defying Joel Spolsky with Django

#91

Post by jroseattle »

macspoofing wrote: post #71
jroseattle wrote: post #35

I was expecting this slidedeck to be a bit more focused on defying Spolsky, and whether or not that was a good decision. FWIW, I've never bought into Spolsky's vision that re-writing code is poor strategy. Steve Jobs never thought twice about ripping something apart and starting over. If anything, code re-write can be an advantageous position -- you often have a greater understanding of the problems you're intending…

>I've never bought into Spolsky's vision that re-writing code is poor strategy. I think it's something that's true in general but false in some specific cases. Rewriting involves spending enormous time and resources to at best standstill, and at worst move backwards ( chances are your re-written product will be poorer in features, and initially buggier than your old, stable, battle-tested version). For smaller compan…

Yes, very true. Although I'd like to add some context.

> Rewriting involves spending enormous time and resources to at best standstill, and at worst move backwards ( chances are your re-written product will be poorer in features, and initially buggier than your old, stable, battle-tested version).

There is plenty of evidence that this has happened in many places and with many companies. A very real scenario that's played out before.

I'd say those scenarios were not well-executed. If the outcome of a re-write is "standstill", the re-write is pointless. There is no justification for proceeding with it.

However, if "standstill" equates only to user-facing features, chances are the re-write is to address critical issues elsewhere (I get the impression that was the situation with the OP.) In that case, "standstill" doesn't apply. It's simply a matter of deciding whether or not the effort and risk justifies the reward.

To my main point, Spolsky's hard-line essentially says re-building your application from scratch is bad strategy. I think it is short-sighted to draw that line. I prefer to exercise judgment and draw on the resources at my disposal for the given situation. I presume many others do as well.

Re: Lessons learned defying Joel Spolsky with Django

#92

Post by mwsherman »

k4st wrote: post #29
zzzeek wrote: post #4

Don't use just one ORM and then declare "ORM's are stupid". The "object = None" / "object_id = None" issue illustrated here is certainly not a mistake every ORM makes.

The SQL generated appears correct, unless the underlying database can guarantee that all foreign key constraints are met. That is, I consider this a failure of the user of the ORM to appreciate that the two invocations of filter are not identical. In the former case, the query is verifying that the object_id field cannot be used to find a foreign object--regardless of the value of object_id. This is exactly what it i…

Correct, these are semantically different. You’ve described it well. The ORM would be incorrect if it did not generate the SQL that it did.

Part of the issue is confusing object data with metadata. The id is an implementation detail of the data store – metadata. What the user is trying to do here is “talk database” and “talk model” at the same time.

Which is a perfectly good argument against an ORM. But one should commit to a metaphor, or not: http://clipperhouse.com/2012/02/29/suspension-of-disbelief/

Re: Lessons learned defying Joel Spolsky with Django

#93

Post by simonw »

Aqueous wrote: post #15
zzzeek wrote: post #4

Don't use just one ORM and then declare "ORM's are stupid". The "object = None" / "object_id = None" issue illustrated here is certainly not a mistake every ORM makes.

Why not just write the SQL?

Because (at least for the kind of queries common to most web applications) you can develop faster using an ORM. Less boilerplate, less repeated code, less time thinking about how to convert between SQL and application-level representations of your data - and most importantly, no time at all spent thinking about how to dynamically generate SQL queries using string concatenation (a sure-fire way to introduce bugs and security vulnerabilities in to your code).

Re: Lessons learned defying Joel Spolsky with Django

#94

Post by simonw »

jokull wrote: post #75
pyriku wrote: post #26

Earlier quoted context omitted.

Middlewares, context processors, forms, (class based) views, and tons of third party applications. The CTO of a startup where some friends are working thought the same you did, and 2 years ago rewrote everything to Flask. Now they're going back to Django. Django is much more that an ORM and templates.

Django middlewares is a poorly designed system. Flask has all of the things you mentioned except for forms. For that you can use Flask-WTF, but these libraries are becoming outdated anyway because they’re HTML based and don’t work so well for JSON validation.

I've found Django forms to work extremely well for validating non-form-based data - the API is a neat way of representing a set of validation rules and running them against a set of data.

Re: Lessons learned defying Joel Spolsky with Django

#95

Post by tomsthumb »

hcarvalhoalves wrote: post #62
Alex3917 wrote: post #30

Earlier quoted context omitted.

"what advantage does Django provide at this point in this project anymore?" Documentation. I use Django but without any ORM and with Jinja2, so it's basically just Flask but with more stack overflow threads and more third-party software. Is there any actual advantage that I would be getting by using Flask instead?

The advantages aren't really in using Flask, but being able to use a better ORM (or no ORM at all, just SQL abstraction) and template engine. After working with Django ORM for a large project, I started to rethink the usefulness of models. It turns out just treating data as sets lends to a functional style and is simpler down the road.

> It turns out just treating data as sets lends to a functional style and is simpler down the road.

Could you elaborate on this or point in the direction of something that does? I'm pretty sure I get the gist but having some more meat to chew to make sure the perspective is fleshed out fully would be awesome.

Re: Lessons learned defying Joel Spolsky with Django

#96

Post by fooooobar »

PommeDeTerre wrote: post #32
Aqueous wrote: post #15

Earlier quoted context omitted.

Why not just write the SQL?

When ORMs first started becoming popular during the 2000s, especially within the Java world, their proponents drummed up a lot of animosity toward SQL. While a lot of us who had started working with SQL in the 1980s, if not earlier, were perfectly fine with using it, many younger developers were scared away from it by these claims. So we've had a generation of software developers who were essentially raised to hate S…

I have never heard it being about people not liking SQL. It's always been about not having to manually convert the results back into objects, and being able to easily switch databases if needed.

Re: Lessons learned defying Joel Spolsky with Django

#97

Post by GhotiFish »

macspoofing wrote: post #77
PommeDeTerre wrote: post #32

Earlier quoted context omitted.

When ORMs first started becoming popular during the 2000s, especially within the Java world, their proponents drummed up a lot of animosity toward SQL. While a lot of us who had started working with SQL in the 1980s, if not earlier, were perfectly fine with using it, many younger developers were scared away from it by these claims. So we've had a generation of software developers who were essentially raised to hate S…

I disagree. There's a lot of boilerplate ontop of raw SQL that can and should be abstracted away. At some point you'll have to parse out result and build an object graph anyway, it would be nice if it was done for you already. You can also plug-in things like a caching engine easily and transparently. Most ORM systems will give you options. My experience was with Hibernate, which had let you do Object queries, Criter…

hibernate lets you do object queries, criteria queries, hql queries, and finally raw SQL

So you have to learn

   Object Queries
   Criteria queries
   HQL Queries
   Raw SQL
   HIBERNATE
And this has made your life easier has it? Hibernate is massively complicated, and you're right, it doesn't insulate us from the database, Not even slightly. So the amount of shit I now how to know has quintupled, just to persist an object!

But hey, BOILERPLATE, right?

Re: Lessons learned defying Joel Spolsky with Django

#98

Post by Uchikoma »

nickbruun wrote: post #57
Uchikoma wrote: post #48

Iconfinder. They are profitable? They have business requirements? Joel wrote about the problems of a rewrite when you need to earn money, implement money making features, heavy competition while at the same time maintaining two plattform where one is a moving target. I don't think Iconfinder fits in any of these constraints.

Incorrect. We fit in all of those constraints at the point where a rewrite was decided ;)

Thanks for your reply, from looking at Iconfinder it did not look like a large piece of software with lots of business requirements.

Re: Lessons learned defying Joel Spolsky with Django

#99

Post by plorkyeran »

jokull wrote: post #75
pyriku wrote: post #26

Earlier quoted context omitted.

Middlewares, context processors, forms, (class based) views, and tons of third party applications. The CTO of a startup where some friends are working thought the same you did, and 2 years ago rewrote everything to Flask. Now they're going back to Django. Django is much more that an ORM and templates.

Django middlewares is a poorly designed system. Flask has all of the things you mentioned except for forms. For that you can use Flask-WTF, but these libraries are becoming outdated anyway because they’re HTML based and don’t work so well for JSON validation.

I've found Flask-WTF to work quite well for validating JSON. It looks a little weird at first due to the naming scheme mismatch, but I haven't encountered any actual functional problems with it.

Re: Lessons learned defying Joel Spolsky with Django

#100

Post by bmelton »

nnq wrote: post #6

Bumping into ORM limitations + moving to Jinja for templates --> one word: Flask ...really, what advantage does Django provide at this point in this project anymore?

To throw a completely different wrench into the mix, I mostly just use Django to provide an API anymore, and for session handling.

I love and use Django, and have built large projects where I haven't really run into any limitations with it[1], but for the most part, nowadays my workflow is to pip install django, south, tastypie, then load in a template with Backbone and Marionette, then get to town.

Templates are either Mustache or Underscore, depending.

[1] - Yeah, it could be faster, but if you have a large, confusing database schema that you inherited, the Django ORM is great for getting things stood up, and then just tune the queries after the fact. It's still a huge timesaver vs. writing every query by hand.

Post reply on HN