71–80 of 225 posts
Great post, though this bit stuck out for me: current_zip = meta.IntegerField(max_length=5, blank=True) You should not store zip data as an integer as they can start with 0. Zip codes use numbers, but aren't actually numbers themselves (leading zeros, no arithmetic, etc). Plus, someday you'll want to ship something to Canada.
One of the things that makes me sad is there is no project even remotely close comparable to Django for say Golang or Scala. I love the fact that you get an admin interface out of the box. And tons of documentation. The views/template stuff is a bit dated since everyone started moving to frontend/backend services and SPAs but we still have DRF which is incredible in the amount you get for "free". I've had the "pleasu…
Actually, I've had the exact opposite experience. I like using Django for small and mid-sized projects, because with Flask I have to spend time adding all these extra libraries for universally required functionality on a quick app whereas, with Django it's plug and go.
However, the larger the project gets, the more I like Flask since I have near total control and understanding of the app. There's no digging into Django internals to make some obscure customization.
Then again, it's been several years since I last used Django, so it may have changed for the better here.
Django’s documentation is still the best I have worked with so far of any software project I came across to date. It not only explains, it educates.
I find it some of the hardest documentation (close to AWS) to understand the best way to do something. I think it's great if you know what you're doing or you have a rough idea of what to do but need more information, but for someone new to the framework it makes me want to paper cut the webs of my fingers and bath my hands in vinegar because it would be less painful.
A lot of these things are only common mistakes because of Django's unusual behavior. > POST to views loses POST data The middlewares shouldn't be redirecting POSTs then! They could have returned a client error instead. > Blank object names They could have provided a fallback of __class__.__name__. > Integer & NULLS If the admin interface knows the field is required, why does it even attempt to insert a null value? It…
>The middlewares shouldn't be redirecting POSTs then! They could have returned a client error instead.
It does raise RuntimeError during development
>> Integer & NULLS
>If the admin interface knows the field is required, why does it even attempt to insert a null value? It could return a validation error.
Maintaining integrity is databases' job primarily, also I could have triggers and functions inside my database to fallback to some default value when there isn't one incoming. This isn't an uncommon setup.
>> Appending to a list in session doesn't work
>Django's behavior with ORM relationships has always disappointed me. There's no way to work with them in memory like in SQLAlchemy because they always attempt to sync out changes to the database immediately. As a result you often have to write some very strange code. They could change this.
Where did ORM come from? Session backends are not exclusively written to be stored in databases.
>> Errors about undefined attributes with one-char names
>They could have done a type check to see if you passed a string instead of an iterable of strings.
...etc.
This way they'd have to type check at thousands of other places where types are assumed. If one isn't comfortable with python's syntactical sugar coatings - inevitably leading to some syntax gotchas, then they should move to more statically typed language.
Earlier quoted context omitted.
Sort of, but you'll have to assemble several different libraries to make it good. It doesn't handle request validation, JSON serialization/deserialization, or databases well out of the box. If you use Flask with Flask-SQLAlchemy be sure to use apply_driver_hacks to enable the pool_pre_ping option or you'll end up in production wondering why 1/3 of your requests are getting a bad DB connection from the pool. Honestly,…
Hug [0] has my goto for REST. Validation, versioning, serialization, automatic documentation. [0] http://hug.rest
Earlier quoted context omitted.
What makes Go projects easier to maintain?
I would argue that it's simplicity. I believe I've read somewhere that Golang was designed with junior engineers in mind. They wanted to create a language that young engineers could learn easily yet cannot make a lot of mess due to its simplicity. They baked all features necessary right into the language. You get a http server, ssl support, templating engine etc. right in the language. You also have a database agnost…
The tipping point for me was actually progressing through these tutorials a few times.
In Ralis land, creating a new page results in no less than 3 files being touched. A new view and controller, and a modification to routes.rb so the page can be hit. If those pages need to interact with the database, you also need to create a model and likely a database migration to write your new tables. Once you get comfortable with the ecosystem, you stop seeing the generators as newbie crutches and start seeing them as serious time savers. It's like you're learning a Rake-based metalanguage that spits out Ruby and ERB code.
It's much less time consuming to just delete any extra boilerplate than to make all those changes by hand.
That said, if you dig simplicity, then things like Django and Rails (especially Rails) will be huge turnoffs. The magic is their selling point :)
One of the things that makes me sad is there is no project even remotely close comparable to Django for say Golang or Scala. I love the fact that you get an admin interface out of the box. And tons of documentation. The views/template stuff is a bit dated since everyone started moving to frontend/backend services and SPAs but we still have DRF which is incredible in the amount you get for "free". I've had the "pleasu…
Scala / Play Framework does in fact have an out of the box solution for this: https://www.playframework.com/documentation/1.2.2/crud Edit: This was removed in Play Framework 2
A lot of these things are only common mistakes because of Django's unusual behavior. > POST to views loses POST data The middlewares shouldn't be redirecting POSTs then! They could have returned a client error instead. > Blank object names They could have provided a fallback of __class__.__name__. > Integer & NULLS If the admin interface knows the field is required, why does it even attempt to insert a null value? It…
> If the admin interface knows the field is required, why does it even attempt to insert a null value? It could return a validation error.
There's a lot going on here. In this case, you're telling the admin interface that nothing is required of the user. There could be a default value, for example. On the more technical side, blank and null are different concepts that are codified differently in different database systems. Here, in most systems, a integer attribute is nullable. If it were a string attribute, however, there are cases (Oracle) where null and the empty string are not distinguished, which is rather sensible for text.
This separation supports all of these modes.
I'll give you that `blank=True` lives in the wrong place in today's Django, but it was an early design and it stuck.
1) Frontend React+Redux paired with an API (eg golang http server serving json)
2) Your boss is going to want "APIs!" soon anyways. le sigh.
3) IMO its as easy to do a JSON API HTTP server in golang as python, but you get typesafety, compiled code and multicore ...
When it comes to django itself, there are nuances, and yep, some of them probably can be smoothed over for developer experience, but developers must have knowledge over their tools.
If you feel like django is getting in your way, take a step back. Maybe you can remove some of the abstractions it provides and do it yourself? Maybe look at the source code? If the magic is no longer working, it's time to realize that it isn't magic to begin with, but possibly a lack of understanding.