God, I was so fed up with django.contrib.auth.models.User, not being able to ignore Username was probably the most insane part, I always felt email was a better choice than Username. I along with a bunch of people I know are looking forward to swappable User model, far saner than the round-about approaches I was using.
Very much agree with this. Websites rarely require users to choose a unique username nowadays (email is enough) and it's been a pain hacking Django to work like that, since many email addresses won't fit in the username field.
In fact I always hate it when application frameworks make arbitrary decisions at the schema level on how long usernames, real names, emails, street addresses, etc. can be. I always use varchar(254) myself. (Unless using a schemaless db like Mongo where this is not even an issue.)
It's not terribly straight forward to do this, depending on which apps you may use. E.g. django-registration or even django.contrib.admin. Username is hard coded in many places. It will get there, but apps have some work to do.
If Android team doesn't see this as a potential feature, they should at the least close the bug, just letting it rot does not align with the goal of having a bug tracker.
Though the article is new to me I don't understand the context of this submission.
(Never using web.py and not being fully aware of Django's status in 2005) I see that overall they seem to have faired well. All you need is a settings.py file to run a Django app. The templating is slow performance-wise but pretty expressive.
I love that the Django community as a whole is pretty responsive to criticism. The 'Why Django Sucks' talk at DjangoCon is an example. My biggest complaint was the horrible User model (you cannot not have 'username' for a Django app using the User model). But they've fixed it now. The major complaint against Django is that it is monolithic, but the devs have worked hard to keep the system decoupled allowing one to replace most modules. But if you want something small Django is not the one for you I guess, and there is nothing wrong in it. One size fits all is never possible to achieve and not a good solution too.
I'd suggest Flask. Flask is a very lightweight microframework, yet it contains everything you need to write a web app in Python. If you want to write everything in one file with Flask, you can. If you need several files, you can do that. You can use proper views if you want. Or not.
Depending on the complexity of the project it might take you just as long to read how a monolithic framework decided to tie everything together (warts and all, because that will inevitably have historical cruft and technical debt).
The extensions were mentioned; User logins for example are just a "pip install Flask-Login" and "from flaskext.login import whatever" away. I had reason to roll my own, ~100 simple lines that were easily plugged.
There are pros and cons, neither is "better", the right tradeoff depends on what you're making.
Well, except that the login process for Django has a lot more people looking at it, and you know that the parts are going to work together pretty well.
For example, Flask-Login (https://github.com/maxcountryman/flask-login/blob/master/fla...) imports md5 and sha1 - not a very good sign. How do I make it use something sane? Well, there's Flask-Bcrypt, which provides bcrypt hashing... except that it makes no mention of Flask-Login or how to integrate it. Flask-Login also doesn't mention Flask-Bcrypt.
So... you're back to hacking on or digging into Flask-Login to figure out how it works and making it use Bcrypt or some other hashing algorithm.
Wait - I just realised that Flask-Login doesn't handle storing user data or models, or checking passwords, just logging them in. So what do I need for that? Is that Flask-Principal? And just WTH is an IdentityContext, anyway?
An IdentityContext is the context of a certain identity
against a certain Permission. It can be used as a
context manager, or a decorator.
You see why people use Django now? :) Sometimes you just want the standard user-logging-in-and-storing-in-the-database without having to write it yourself.
However, the Extensions library [-1] (which is not strictly speaking part of Flask) provides quite a lot of functionality - apart from your referred SQLAlchemy (which does the job well in our backend), there's a nice API generation factory [0] [1] and other neat stuff. For quite a lot of intents/purposes, flask extensions will do the job. But in the end of course it is a microframework. (From limited personal experience, a very neat general-purpose microframework nevertheless!)
[-1] http://flask.pocoo.org/extensions/
[0]
[1] A particularly sexy example that simply uses models from SQLAlchemy (from the quickstart in [0]):
manager.create_api(Person, methods=['GET', 'POST', 'DELETE'])
manager.create_api(Computer, methods=['GET'])
where Computer and Person are DB models easily defined with the help of SQLalch.
(This is not to counter (there isn't anything to be countered, just providing links / luring people..)
* Flask fan here.
Flask is not a "micro" microframework per se.
It provides a thin facade over werkzeug - which is anything but lightweight or micro.*
Another Flask fan here. If Armin says Flask is micro, and other frameworks which aren't considered micro are far larger than Flask, what makes Flask not a micro framework?
>It doesn't contain everything you need at all - that's why it's called a microframework.
I said everything you need to make web apps in Python, and I stand by that. Maybe it doesn't have an ORM or user account management, but for my purposes, it's great for small apps.
Having looked at both web.py nad Flask, web.py seems more elegant at first glance.
I like the mapping of a resource to class and method names to class method.s I am not sure I like Flask's method handling and having to do if ... elif .... else (maybe I just found some bad example, so please correct me).
Also url dispatching at the top makes it easier to understand what's going on rather than having it spread to each of the decorators somehow.
Flask and Sinatra are great. Easy to learn and easy to customize. They have stable APIs, unlike big frameworks like Rails and Django. This means you don't have to worry about what happens when you upgrade your application to the latest version.
Django isn't loosely coupled by default, but it can be used in a relatively loosely coupled way. E.g. you can easily use your own SQL and templating engine. Yes you can't just hot swap in a new web framework without rewriting the core app code, but that's the case with every framework.
I think it's time to cut this 'version number' debate. Mozilla has been pretty clear about the plan to use such a system. The only problem was from enterprise users which Mozilla has addressed. The background auto-update is in the stable builds now, should be enough to keep FF updated. I am really tired of this versioning non-sense. Users complained, Mozilla addressed legitimate concerns. Now it's just a difference in perspective. Seems like the new system is actually helping Mozilla put out updates faster. Lets move on.
I know they've been very open about why they're using major revision numbers for minor features. I don't like it when Chrome does it either. I just don't like the arms race that is developing to have the higher revision number. I just get a little disappointed when I see a new major number and the changelog is minor additions and bugfixes.
Just because Mozilla has their reason for making the change doesn't mean everyone has to be happy about the change. I'm not complaining about Firefox, I'm complaining about the number, and the corruption of what that number is supposed to mean.
The fact that you're talking about "major revision number" means that you're still thinking about this from the old perspective. There is no "major version number". There is just a number that gets incremented with each release. They could have just as easily used the date as version number. Now I'm thinking that maybe they should, just to get rid of this senseless discussion.
> I just get a little disappointed when I see a new major number and the changelog is minor additions and bugfixes.
Don't be. There will be no "major additions" anymore. They will now release small features, quickly. So no major feature bump. Hence no need to wait for one either. It's like a number of small steps instead of one giant leap.
I don't see this as an arms race at all. (Heck, it took a major outcry just to convince Mozilla to show the version number in a place where normal users could find it.)
I agree that it's a redefinition of what "version number" means: now it's essentially date based, rather than feature based (though the two are obviously correlated). But I can't see any obvious reason to read "redefinition" as "corruption". It's just different, and both Mozilla and Google had sensible reasons for making that change.
In fact, their decisions may make it worth questioning those assumptions more broadly. Is there a chance that your version numbering method is causing subtle problems for your own development process?
The Linux kernel does it too. Ubuntu and Gnome do a steady release as well, just not quite as rapidly. Chrome isn't alone by a longshot.
This rapid release schedule is just the most efficient way for these teams to deliver new features in a stable way. Taking 1-2 years to land code in the next major, stable version of the product just isn't practical anymore.
Fc*king paywalls. This is such an amazing article, if only they could not have paywalls for research articles. Its as if the licenses will make enough money to fund the research, stupidity I say.
The FF dev tools offer a very different experience compared to Chrome. I am curious about the rationale between having different views for web inspector & debugger.
I am on Aurora/Ubuntu. The binding for the Debugger (Ctrl-Shft-S) doesn't seem to work for me and the Dev toolbar has no way to open the debugger view.
Many people claim Java gives better performance. I would like to know from some experienced programmers how it had been a few years ago. Was Java always this well performing?
Seems like Java community did quite a lot to get Java to perform better. How likely is it for a language like Python or Ruby to do something like that? I understand that these are vastly different technologies and we simply can't compare implementing a JVM feature in say a Python interpreter, but any commentary would be appreciated.
Sun hired some of the best minds in the business to make Java perform around 1999 - literally the guys that wrote the first runtime optimizing compilers and generational garbage collectors (eg. David Unger and team from Self), and also had some of the pioneers in LISP (Guy Steele). The major performance gains began in Java 1.3 in 2000 through Java 5 in 2004, with steady gains since, particularly in terms of garbage collection in large-memory, multi-core environments.
IBM also had some very bright minds working on their J9 JVM which was aoriginally targeted at embedded environments but was so good it became their mainstream VM. I'm not sure how much "borrowing" it does from the Oracle VM, but it's definitely a different architecture.
Another language could do this of it had wealthy patrons with a keen interest to make it so. Google with Python might be a possibility, but they are huge Java users already and have some of the old Sun team working for them.
Google started with Python with Unladen Swallow, but stopped after a combination of uninspiring results and the fact that while Google uses a lot of Python internally, it's generally for non-performance-critical applications. For the cases where performance counts, it's generally done in C++ instead.
Java has been pretty fast since it used a JIT circa 1998. The main reason it got a bad rap was that it needed tens of MB of memory for basic apps. This means that folks with their Pentium I's and II's with 64MB RAM perceived Java as slow since basic apps would swap like crazy. A few years later J(2)EE app servers (notoriously heavyweight) made heavy use of many many layers of abstraction resulting in poor performance. These two events have unfairly tainted Java's reputation.
The JVM has improved performance by developing more advanced garbage collectors and profiling JIT compilers over the years to the point where it is the JVM is the fastest managed runtime out there.
http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...
Short version is that Java tends to take a lot of memory and a fair while to start up, but once it gets going it's very fast. A bit like comparing a Boeing to a small sports car. The sports car will drive you to the shop around the corner very fast. The Boeing will take a long time to prepare for takeoff, but once it gets going will leave the sports car behind in the dust.
