It works quite well, with a few gotchas (mainly in the JS, handling the watch() event). If you're using Python the pyBrowserID library helps with some low-level details although it's easy enough with requests/urllib.
I strongly suggest you consider the legal implications.
Suppose you're about to hire some guy. You ask for his Facebook page, and it turns out from the page he's gay.
You then turn him down for the job for some completely unrelated reason - maybe because his SQL skills aren't good enough.
However because you asked for his FB page, he could then claim discrimination because you discovered his sexual orientation.
Would you win in court? Maybe, but then you and your company have been dragged through the mud. Think of the press coverage, boycotts etc.
More to the point - you'd deserve to lose. You don't own your employees. What he does outside office hours - as long as it's legal - is his own damn business and none of yours.
I want to see the candidate's twitter feeds, Facebook pages, LinkedIn profiles, activity on mailing lists and github, etc. and the recruiter has to be happy I'm not going to screw them over with that info.
My Twitter account is anonymous. My Facebook account is for friends and family. You're welcome to look at my LinkedIn and Github profiles, otherwise you can eff off, it's none of your business and I'll walk right out the door if you ask for them.
Hackerjobs is a wasteland - for example, just 3 or 4 Python jobs. Don't waste your time there.
My suspicion - based on own experience and some hints in the OP's post - is subtle ageism in the industry.
Experience, track record and ability go out the window when the company you're interviewing for are in their early 20s and don't want any old guys cramping their style.
Odd maybe but when I read numerous posts on "developers in hot demand" it just doesn't gel with reality. I had way more offers 10-11 years ago after the dotcom crash than I've had the past year or two, despite much more experience (both in the industry and open source).
Maybe it's great if you live in a tech hub. Take the programmer who happens to live in Nowheresville, Nebraska. He lives there because his wife has a job there, or other family commitments, so he can't just up sticks and move to the Valley. So he's looking at the local job market, which is probably shitty death march or legacy VB projects or whatever. Moving to the Valley is only really practical for young, single people without kids and mortgages.
Remote jobs are the answer, but they are still few and far between, even among supposedly "forward looking" startups. So for your programmer in Nowheresville the job market is to all intents and purposes a bleak and desperate place, no matter how experienced or talented he happens to be.
> I go to cafes here and it's not unusual to see people coding, discussing startups, practicing their pitch. Almost everybody I know is building something. Not working for a big company is like a badge of honor.
Sounds like a recipe for an impermeable echo-chamber.
Well, we all need to eat, and if you want to do web dev, and 90% of web dev jobs in your area are PHP...
So yes, PHP may put food on the table, but if it's the only tool you get to use professionally (without having to start your own company) then you are pretty much forced to use it. Hence the hate. Now I get to use other tools, I just don't care.
I wonder if the reason for that is the move to the web - the drag and drop & generate code paradigm doesn't work so well with the classic HTML/CSS/JS combo(although they tried with .NET).
Maybe in a parallel universe where HTML wasn't the basis for web apps - where perhaps we're finally heading for now - we'd have seen instead leaps in RAD tool development.
All other things being equal, a "homegrown" project by coders who know what they're doing is going to be better than a framework project by coders who don't. Yes, I understand your reason, and given coders of equal ability it may be true; but I've seen Django projects written so badly the framework made very little difference to maintenance overhead (and as Django becomes more popular and mainstream we're going to see more examples of this).
What if you want to get rid of the username field altogether?
For example, my typical use case: unique email address for logins, no usernames:
I suppose you could subclass User with a longer username, and sync the username with the email address using a signal, for example.
Still, it's a chunk of workaround I end up doing one way or another with each new project. Hopefully soon (based on discussions on django-developers group) we'll see some kind of pluggable User model.
I'm not arguing against using a framework, if it fits your project requirements, and we can argue the day long about micro-vs-full-stack. There are good arguments for both, they suit different people and projects.
My own observation is that bad codebases are the result of bad development practices regardless of framework. In my last job the code quality was so poor (and the management processes so broken) that whether they'd used Django, Flask or roll-your-own would not have made a whit of difference.
Sure, if you did it completely on your own. More likely you use Flask or Pyramid which provide the plugins/entry points/templates to make wiring these components together quite easy.
Really, it's more of a management problem than a coding problem. Short-term thinking, bad hiring/outsourcing practices, and poor client expectations management, among others. A framework or language isn't magic pixie dust that will make these problems go away.
At this point I'd prefer to work on a well-managed, professionally coded project written in PHP than one written using <insert-python-framework-du-jour-here> run by idiot managers.
Most codebases I've seen that are badly maintained or managed over the years are horrible messes - whether Django, Rails or anything else. The last codebase I worked on - written in Django - was appallingly bad. That's no fault in any way of Django, but no framework is going to save you from poor coders, last-minute rushed requirements, chronic technical debt, or lack of investment in refactoring.
> I think people who criticize Django have yet to make up their minds about what a framework is all about, and what, if anything, it's for. They just hold on to their utopian idea of what their framework should be.
No, they have a different idea of what a framework should do or not do. Doesn't mean they have some utopian idea just because it's not Django.
> Django templates are sloooooow. Jinja 2 is an order of magnitude faster
Template execution speed is unlikely to be the bottleneck for the vast majority of sites. I prefer Jinja2 for the flexibility (macros etc) rather than the performance.
Django 1.5 fixes this with custom user models:
https://docs.djangoproject.com/en/dev/topics/auth/#customizi...