HN user
Why is he called a Mozilla blogger? He doesn't work for Mozilla foundation or Mozilla corp as far as I can see (nor does he claim to). His linkedin states he associates with the "Mozilla community", but that's hardly an official representative of Mozilla as "Mozilla blogger" implies.
I still don't understand why they couldn't just introduce a new keyword that has the same meaning as a missing semicolon. Call it 'ret' or something as a 'lesser return'. Relying on ppl to be semicolon hunters is poor for readability.
It also means you can't put more expressions on the same line because doing so requires a semi-colon which then eliminates the special semicolon behavior. Having an explicit 'ret' keyword means you could accomplish that and have more expressions for a separate block on the same line if desired.
Oh good, now it only takes 24 people to design and implement a page with 'proper' HTML 4/5 + CSS 1/2/3 + JS that is 'responsive'.
I stopped reading A List Apart when it became rather apparent that they either delight in adding more tedious work to a web designers check-list, or just truly seem to think every project needs this many people working on it (or someone with insane mental capacity that can actually do half the stuff they recommend).
The mental overhead involved in modern web design automatically precludes the vast majority of either normal folks, or companies not big enough to have 24 people make a web page.
When we can reduce the effort needed to do this properly, then it'll be worth giving people a pat on the back. Not when it takes 24 people to make a page that works properly on a few devices.
I've met total posers that can whip up the little snippets that people have time for in an interview... and I've met great coders who crash and burn a live code session due to interview stress.
I've consistently found open-source code to be a much better sample since the person being interviewed is not under such pressure when writing it. And yes, the pressure from being in a room with 3 ppl watching you is very different from "deadline pressure" to complete a task when employed.
I don't think the github resume is going to be the standard for quite awhile, but I know it makes my job when hiring much easier when we can discuss code and techniques used in an open-source project the interviewee wrote, than arbitrary questions that only prove he's recently memorized an algorithm book.
The real thing developers should think about, is the competition. This is what made "has college degree" an easy filter for employers. If you have 800 applications, tossing the ones missing a github repo in addition to the college degree trims it down a bit more.
Will you miss some possibly great people? Absolutely. Same with the college degree filter. But you'll still likely end up with a bunch of "would like to hire" candidates and it'll be easier to see what their work actually looks like. If you're applying for a job, you should absolutely consider how to stay ahead of the competition, and I'm sure companies in the future when bombarded with so many applications will add things like this to the resume filter.
I tried it in FF Nightly and FF release. Using the latest Flash as far as I know.
Love how there was obviously no testing of the site on Firefox, as clicking the video pause or volume buttons hides the entire video. Pause/volume works fine on Chrome/Safari of course.
Exactly why we need Bittorrent Live to take off. P2P live video streaming can help bypass shoddy bots.
Good point, I forgot to mention that Firefox is expanding the developer tools it comes with:
http://blog.mozilla.com/blog/2011/08/16/new-tools-in-mozilla...
Also, it hasn't landed in Nightly yet, but there's some really slick dev tools that are being built into Firefox:
http://hacks.mozilla.org/2011/07/tilt-visualize-your-web-pag...
There's some nice CSS and Javascript tools coming too, but I can't seem to find any URL's on them at the moment.
As a bunch of other people in the comments have noted, Firefox can take a huge amount of memory, the one thing they also have in common.... is the Firebug extension. It should come as no surprise to them then that Firefox is not actually leaking the memory... Firebug is. A quick Google search for "Firebug memory leak" will lead to multiple examples of massive Firebug memory leaks.
It's a bummer that Firefox gets the blame for Firebug's memory leaks. If people would like to avoid that, the best thing would be to use Firefox's multiple profile feature so that they activate/install Firebug in a Developer profile, and keep their general browsing profile without Firebug. It's rather amazing just how much, and how fast Firebug can leak memory as using a separate profile will make abundantly clear.
http://lifehacker.com/5481213/master-multiple-firefox-profil...
Yep, Python works great so far, I threw up a little cookbook recipe for a Pyramid app: http://docs.pylonsproject.org/projects/pyramid_cookbook/dev/...
Since its fairly easy to composite multiple WSGI apps together, one could run a few different Python WSGI-based apps under a single multi-threaded process to take full advantage of the free quota. That would work with Pylons/Pyramid/Flask and other Python web frameworks that don't rely on a single set of module global settings (Django).
This is because running commands is from a one-off dyno vs. the formation dyno's that have requests routed to them.
I think you missed the bit about Pylons being a 'glue' framework between other packages. Those packages have gotten quite a few new features over the years, and they continue to get new features regardless of whether Pylons users use them.
This is the kind of nice thing about using multiple open-source packages that are in heavy use throughout the Python world beyond just web frameworks (unlike web2py).
I agree, I'm in the North Bay, and I'd be open to helping people work through pyramid, and discussing things in person. Would a meet-up next Thursday night (the 11th) work for some folks? Maybe around the South Bay or SF if someone can get some space?
Not quite the same, because the new version has a bunch of features added. If you'd like to stick with the camera analogy, you should think of the pylons framework more as a good lens for the DSLR. Most of the features are from the body, so you upgrade that and keep using the same lens.
The Pylons framework was almost entirely just glue between your choices of ORM/templates along with using WebHelpers and Beaker. Those projects are still in use with pyramid, still getting updates (and thus a pylons project will still get feature updates via them).
I tried to explain this better here: http://groups.google.com/group/pylons-discuss/browse_thread/...
As mentioned below, there's no "leaving" involved. The pylons code-base has been maintained for several years with little in the way of new features, just bug fixes, some minor clean-ups, and security fixes. That isn't changing... so there's nothing 'different' for the pylons code-base involved.
I'm confused where this notion of leaving pylons comes from, when nothing is changing with it.
We had originally considered calling it p2, unfortunately that would've sort of bound the package name to sound kind of odd when someday we get to Pylons 3. Also, given the amount of new code to merge in, and then slowly deprecate the old code in the pylons package... it seemed more convenient to use a new name.
This also means that no one installing the 'pylons' package will have to worry about someday installing a version that deprecated things their old pylons app needed. Using pyramid means that you can use the new, along with the old one, at the same time, without worrying about version conflicts in the package.
Before this, there were several efforts and results of those efforts to combine code in common and share more. First, we had an informal set of talks that resulted in a 'pipefitters' type mail list where people sounded ideas around on how to build our stacks on more common components.
Second, there was an effort on a code-branch called 'marco', that was to be a common set of code for a bunch of the underlying configuration setup. It's code was also out there, and ppl poked at it some: http://bitbucket.org/chrism/marco
It got a little ways, but it kept looking more and more like the existing repoze.bfg... which brought us to a point where pylons-trunk was built on BFG. This entire discussion is on the pylons-dev list here: http://groups.google.com/group/pylons-devel/browse_thread/th...
Then, in an effort to resolve remaining differences in the code, several of us flew out to meet in person to discuss remaining issues in the code and see if a better collaboration could work out. We decided to try out the idea of a merger, since pylons-trunk for Pylons 2 was doing little more than minor extensions of repoze.bfg anyways, which was collapsed into the pyramid code-base (and is a distinction in that respect from repoze.bfg which doesn't have those bits).
It worked out quite well from some attempts at 'trying it out' and the news of this leaked quite a bit earlier than we anticipated making it hard to try and put together what I think could've been a better process.
Was there a discussion where we asked everyone in both communities for their input on merging? Not really, we talked to primary contributors and developers who had worked on each stack to try and solicit input and ensure they were all in favor of it. But yes, I agree entirely that I should've solicited feedback from the pylons community at large.
For pylons the code-base, there really isn't going to be any difference from what there is right now, and has been. A maintained, stable, mature code-base, that has hit a point where there's little more to be done with it. It's been at a feature-standstill for about 2+ years now. It's not going away, and it will still be maintained.
So I think the way the merger was done definitely could've been announced differently, with more emphasis on what it meant for the pylons code-base (nothing really), vs. the continuing development efforts of myself and other pylons developers.
- Ben
Many people loved "from pylons import config", until it didn't work, which frequently happened anytime someone wanted to use something from a Pylons app in a command line script (which seems to be pretty often). I do have a few minor clean-ups that help slightly with that stuff which I'll likely put out a Pylons 1.0.1 to address.
> Let me make this clear: do I believe Pylons could be better? Yes I do. Do I think killing it to make it better was a good idea? No, I don't.
So, the whole 'killing' thing seems slightly extreme. I've maintained Pylons with few changes besides bug fixes, security fixes, and deprecating old things for the past several years. And now the announcement that I don't plan on doing any more than the same thing for the pylons package code-base is "killing it off"?
If you're happy with pylons, there's no need to stop using it. The docs will always be available for it, the code-base will not be removed. By design, I just couldn't see how to continue it forward in ways that I (and a lot of people I've talked with) need.
Of course, a lot of people may not need anything more than pylons provides right now, and in that case I'd be hard pressed to tell them to switch their code to use pyramid. pylons is stable, mature, and has been maintained as such for quite awhile, there's a book that still pretty much applies to 1.0.
> Anyway, I have tremendous respect for Ben and can't blame him for getting bored and wanting to work on something different.
Thanks, sorry my nick doesn't reflect it, this is Ben. Seems I can't change my profile info on ycombinator, sigh. Or that 'feature' doesn't exist, anyways...
As I mentioned, the Pylons code-base was essentially frozen for any direction forward which I needed to build higher level tools. I know this may not be immediately obvious to everyone depending on your requirements, and pylons suits many peoples needs perfectly well.
I will be blogging about this in the future, at which point some of the key differences, and what they enable will hopefully become more clear. But Pylons is definitely not dead, and I think it won't be too long before people start to see what a larger development team can do. :)
Depending on what you're prototyping, it could very well be done faster with Django. Django provides a bunch of 'generic views' which can make tossing up lists of objects from the db very fast to get started with. Then usually you end up fully replacing it all later, but it gives you a good start.
My views haven't changed since I answered this: http://stackoverflow.com/questions/48681/pros-cons-of-django...
If your app doesn't clearly fit into the sweet-spot's for Django, the argument will be less compelling. The pyramid code-base does have a lot of maturity behind it, it's not completely brand-new, so I don't think it'd be a problem to develop against it to be able to utilize its additional extension points.
Sorry you didn't see it, I'll try again: http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just...
I'm sorry you feel that way, as the developer of Pylons, I really don't look at this as killing Pylons anymore than the lack of any new functionality has killed Pylons 1.0 in the past 6 months.
Pylons 1.0 has been in maintenance mode already (effectively), 1.0 was in fact nothing more than a few tweaks on 0.9.7, ie. maintenance release with a 1.0 version number and finally killing a few deprecated things.
The FAQ explains why when attempting to extend Pylons for new functionality, I hit a dead-end: http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just...
Finding a path forward for extensibility that didn't hit this forking problem: http://lincolnloop.com/blog/2008/apr/4/reusable-django-apps-...
was a very major concern of mine. I think this will address that, and when Django makes the changes necessary to remove the forking problem I won't be at all surprised if it requires porting your apps...
To answer your first question, it won't be nearly as easy of a transition as it was from Pylons 0.9.7 to 1.0. For some reason, the fact that Pylons 1.0 hasn't had any updates or feature additions in the 6+ months hasn't seemed to be an issue, it was already mostly in a "it works as well as it can work" stage.
Plugging in the old Pylons app using WSGI isn't really any more kludgey than using WSGI for any other app composition use, which is plentiful.
For the second question, the best reason would be that in the world of web development, all web frameworks will deprecate old technology. It's the only way to move forward if a fundamental design decision in the core needs to be re-architected.
I know many former TurboGears users may have a lot of angst about this, because the rug has been pulled out a bit more than for Pylons users, who have rarely had to deal with everything at the bottom being replaced. This direction was taken to help avoid that again in the future, because now all the development for everything... top to bottom... we have under one roof so to speak.
In pyramid we have a core that is architected to deal with the extensibility issue, and can pick up development of features that the Pylons 1.0 code-base couldn't handle. Since its based on over 2 years of development and use in the repoze.bfg community, it means its very solid and stable already.
In short, I think it's on track to be one of the most stable Python web frameworks out there, just like Pylons 1.0 and prior has been quite stable. My advice would be to try new, small experiments and projects with it first. I'll be publishing more articles highlighting the improvements and extra features it brings to the table soon.