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

131–140 of 155 posts

Re: Lessons learned defying Joel Spolsky with Django

#131

Post by Daishiman »

jroseattle wrote: post #47
LockeWatts wrote: post #42

Earlier quoted context omitted.

I'm not really sure why Steve Jobs is your model for code design.

Apple has/had a history of re-writing code over the years. The first iPods and their iterations were code re-writes, IIRC. Many of the onboard applications were completely re-written for the iPad.

Rewriting for new hardware is totally different from rewriting business logic. In the first case there are sometimes no other choices left.

Also, the code that usually goes into hardware microcode and firmwares is much more tightly coupled.

Re: Lessons learned defying Joel Spolsky with Django

#132

Post by Daishiman »

gingerlime wrote: post #107

> 20ms with Jinja2 without auto-escaping could this performance improvement back-fire if you end up with a security issue? I'm not saying that it definitely would. If you know what you're doing / trust your data sources or sanitize them elsewhere, you should be fine. I'd be careful turning off such a feature completely though...

Of course. This is merely a tradeoff between performance and developer time. 99% of projects will never have HTML autoescaping as a performance pain point. Then again, you're going to need tens of hours to review all templates to make sure you're escaping everything. If your hardware budget is greated than what it costs to audit the code, it's the proper decision.

Re: Lessons learned defying Joel Spolsky with Django

#133

Post by akmiller »

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…

"At some point you'll have to parse out result and build an object graph anyway"

This type of thinking has to stop! Sure, some times it may be necessary to extract data from SQL and turn it into some type of object. However, most of the time it's enough just to get the data and work with the data directly.

Re: Lessons learned defying Joel Spolsky with Django

#134

Post by rmrfrmrf »

akmiller wrote: post #133
macspoofing wrote: post #77

Earlier quoted context omitted.

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…

"At some point you'll have to parse out result and build an object graph anyway" This type of thinking has to stop! Sure, some times it may be necessary to extract data from SQL and turn it into some type of object. However, most of the time it's enough just to get the data and work with the data directly.

* grabs OO sword and shield and prepares for battle * .

Re: Lessons learned defying Joel Spolsky with Django

#135

Post by j-kidd »

PommeDeTerre wrote: post #128
neilk wrote: post #89

Earlier quoted context omitted.

There are libraries which build up a model of a query - selections, constraints, etc, and only turn it into a string at the point of executing it. SQLAlchemy was already mentioned. In the JavaScript world, there's node-sql. https://github.com/brianc/node-sql

That kind of code often ends up being worse to deal with than the SQL it is replacing. I've always found it kind of odd how there are some people who despise SQL merely for its syntax, yet they'll turn around and advocate the use of libraries which mimic a SQL-like syntax in some other programming language (but do an absolutely terrible job at it). The node-sql examples are atrocious, for example. It's even more obvi…

> I've always found it kind of odd how there are some people who despise SQL merely for its syntax, yet they'll turn around and advocate the use of libraries which mimic a SQL-like syntax in some other programming language (but do an absolutely terrible job at it).

No, I use ORM because I love SQL. ORM doesn't replace SQL. ORM helps to generate the exact SQL I want with much less code.

I have seen application with thousands of stored procedures, most of them boilerplates, and only supports one particular flavor of RDBMS. I have seen too much hand-crafted SQL in the form of "@param_xxx IS NULL OR field_xxx = @param_xxx".

I used to think that Tom Kyte was right, that everything should be in stored procedures. Now, I am thankful for ORM (more specifically, SQLAlchemy).

Re: Lessons learned defying Joel Spolsky with Django

#136

Post by iconfinder »

level09 wrote: post #41

I found these tools mentioned by the author really helpful, I compiled a list of them: http://jinja.pocoo.org/ https://www.getsentry.com/welcome/ http://graphite.wikidot.com/start https://opbeat.com/ is there a way though to use/test opbeat ?

Just send them a message via twitter or email. I'm sure they will help you get started.

Re: Lessons learned defying Joel Spolsky with Django

#137

Post by drdaeman »

lucian1900 wrote: post #52
drdaeman wrote: post #27

Earlier quoted context omitted.

The only problem I see, is we can't rewrite SQL. I.e., in pseudocode: query = SQL("SELECT * FROM entities WHERE owner = ?", owner=me) ... if some_condition: query = query + SQL.WHERE("OR public = TRUE") ... if other_condition: query = query + SQL("LEFT JOIN things AS t" " ON t.entity_id = entities.id") \ + SQL.WHERE("things.value > 0") ... my_nice_list_of_results = run(query + SQL("LIMIT ?", count)) This should be te…

SQLAlchemy lets you do precisely that. Give it a try, I haven't written a line of SQL since I've been using it.

Yes, I know and use it, but SQLAlchemy is not SQL. It's completely another (although, SQL-inspired and compiled-to-SQL) language, which rises learning barriers. I find myself frequently thinking SQL then mentally transforming the queries to SQLAlchemy syntax, which is somehow pointless activity, considering the fact computers excel at transforming formal languages.

I believe, If someone'll take an SQL SELECT statements parser and create a library that'd generate SQLAlchemy query/statement object from them, such library will make development more productive.

Re: Lessons learned defying Joel Spolsky with Django

#139

Post by drdaeman »

gngeal wrote: post #111
drdaeman wrote: post #27

Earlier quoted context omitted.

The only problem I see, is we can't rewrite SQL. I.e., in pseudocode: query = SQL("SELECT * FROM entities WHERE owner = ?", owner=me) ... if some_condition: query = query + SQL.WHERE("OR public = TRUE") ... if other_condition: query = query + SQL("LEFT JOIN things AS t" " ON t.entity_id = entities.id") \ + SQL.WHERE("things.value > 0") ... my_nice_list_of_results = run(query + SQL("LIMIT ?", count)) This should be te…

"The only problem I see, is we can't rewrite SQL." I believe that the phrase you're looking for is "lack of compositionality".

I fail to see why one can't manipulate parsed SQL's AST. SQLAlchemy shows thas manipulating SQL-inspired objects is perfectly possible.

It's only bridge between sqlparse and SQLAlchemy that's missing. I guess, just because nobody had a wish, will and time to finish and share one.

Re: Lessons learned defying Joel Spolsky with Django

#140

Post by zzzeek »

drdaeman wrote: post #137
lucian1900 wrote: post #52

Earlier quoted context omitted.

SQLAlchemy lets you do precisely that. Give it a try, I haven't written a line of SQL since I've been using it.

Yes, I know and use it, but SQLAlchemy is not SQL. It's completely another (although, SQL-inspired and compiled-to-SQL) language, which rises learning barriers. I find myself frequently thinking SQL then mentally transforming the queries to SQLAlchemy syntax, which is somehow pointless activity, considering the fact computers excel at transforming formal languages. I believe, If someone'll take an SQL SELECT statemen…

this is more or less what HQL does (http://docs.jboss.org/hibernate/orm/3.3/reference/en-US/html...). However the huge advantage to composing SQL as an actual object construct is that you get reusable constructs which serve as components to composing a larger structure. String-based SQL OTOH means you're going to be concatenating strings together which is error-prone, verbose, and even hazardous from a security point of view as it discourages the usage of bound parameters.
Post reply on HN