ris

77 ms·

811.
by ris 9y ago
> On the other hand, it doesn't hurt to write your code with performance and scalability in mind. Neglecting this too hard may result in bad performance even for the first 10 users. Absolutely. But the architectural choices you make
812.
by ris 9y ago
> The downside is you have a potentially hard scalability ceiling Which 99.9% of projects will never ever hit, and those that do will by that point have become such an extreme scale that significant reengineering should be something that
813.
by ris 9y ago
That's fun - when I was working on this problem a few years ago and unable to find sufficient academic literature on the subject I thought I'd "invented" what turns out to be known as the Viterbi algorithm (duh) and hadn
814.
by ris 9y ago
This turns into a very interesting dissection of postgres' internal workings, but it's hard to get over the beginning's massive caveat of using a RDBMS as a queue.
815.
by ris 9y ago
That's not remotely the same thing. In django, one specific file is looked for and imported if it exists, django then looking for an `urlpatterns` in it. No side effects anywhere. Just a default place to look for something, much like
816.
by ris 9y ago
The problem with this sort of advice though is that everyone likes to think their project will go hyperscale, or will be prepared to if necessary. The reality is that very very few of them ever need to yet so many design with this is mind n
817.
by ris 9y ago
> Django smooths it over so you end up with cached property counts for things which are trivially computable from the DB Uuuh I've never encountered this problem
818.
by ris 9y ago
You can't just pretend these people don't exist. The bulk of the developer population are what could be called mediocre. Heck, I'd class myself as fairly mediocre. You will end up working with these people or inheriting a p
819.
by ris 9y ago
Views "register themselves" as functions that should be called given a certain URL at import time. That is a side effect and it's horrible if you want to do anything more subtle. Way more "magic" than anything djang
820.
by ris 9y ago
This. If I tell someone to go away and write me a project in flask or a project in django, provided they "go with the flow", the django one will almost always be nicer. A sensible `manage.py` interface. Apps that can be built to b
821.
by ris 9y ago
> But flask also almost invented the whole @route API, which is really awesome. -1000 on this. It's a side-effect-on-import nightmare. Not to mention scattering your url scheme all over your view modules makes it much harder to spot
822.
by ris 9y ago
> I think learning the mistakes and seeing the problems and pain firsthand let's you appreciate and hopefully understand the decisions that were made. In my experience, people just don't . They just continue on oblivious think
823.
by ris 9y ago
I'd wager it would be possible to implement the django ORM on top of SQLAlchemy.
824.
by ris 9y ago
> But SQLAlchemy is definitely not "better". It is more powerful, more correct, more proper, more flexible. Indeed - for my purposes, it's better. But I loves me' databases. > And Python, which is "who cares
825.
by ris 9y ago
So having used both, this is what I tend to say about them: some of Flask's commonly-used components are better than django's (SQLAlchemy notably), but altogether, django is a better framework. I strongly disagree with the not
826.
by ris 9y ago
> I feel like Django has too much magic Are you kidding? Flask is side-effecty module, global-variables, make-sure-you-put-this-magic-incantation-which-you-dont-understand-in-your-init everywhere.
827.
by ris 9y ago
Beyond that, you tend to often realize you haven't quite made the logical split of components in quite the right place, or the "right place" for that split to be changes over time. Then you've got the fun task of movin
828.
by ris 9y ago
I'm pleasantly surprised to see so many Nix enthusiasts milling around in this thread and I'd like to encourage people to step up and do their part in helping improve and maintain nixpkgs. It's really not that hard, and it&#x
829.
by ris 9y ago
Hooray! Still, it's not exactly transparent in a way that you could get with lazy array evaluation.
830.
by ris 9y ago
Investing time in writing your complex code in their Go dialect may leave you in shackles and at the mercy of their pricing plans.
831.
by ris 9y ago
That's not to say there aren't things NumPy doesn't do that it could . How about lazy evaluation or even just matrix chain multiplication? Either could save a lot of computation.
832.
by ris 9y ago
This looks awwwwfully nonfree...
833.
by ris 9y ago
I think it hugely depends on what your WHERE clause is.
834.
by ris 9y ago
You're not supposed to do pointer arithmetic with these pointers. It's generally meant for storing pointers "at rest".
835.
by ris 9y ago
Thing is, none of these are language agnostic. jsonschema is the only one that makes an attempt at that. It's a slight pity that the python jsonschema package doesn't support some of the more powerful recent features though.
836.
by ris 9y ago
This is one of the reasons I get quite nervous when people start talking about these private-implementation, "cloud native" database services (Aurora, Redshift, Spanner...). As wonderful as they sound (and possibly are), not only
837.
by ris 9y ago
As of late I've come to a new belief as to the real reason for microservices' current popularity. DevOps, deployment, and whatever-hyperopaque-cloudy-service-amazon-have-launched-this-week are the cool & fun things happening
838.
by ris 9y ago
As exciting as this is (and it really is) it's yet another thing that explodes the number of possibilities for optimization. It's getting towards the point of unmanageability and I hope there will be a movement towards, if not aut
839.
by ris 9y ago
Didn't see that coming, eh?
840.
by ris 9y ago
The correct response is to file a bug report, not write a clickbait-y article.

More ›