Pewpewarrows

> Also, not everyone works on projects hosted on a vps. ftp/sftp is very much still relevant in the real world.

Those two things are not mutually exclusive.

I'm sorry, but if you're a professional web developer you need to stop editing files directly on remote servers. Period. Full stop.

Apologists post in threads like these time and time again, whether the argument is for them using PHP, SVN, or whatever. My reply boils down to this:

Sure, you can construct a home using nothing but straw and mud. And because the house is still standing at the end of the first day, you convince yourself that those are good materials for your next job. But don't kid yourself. Straw and mud are not good, modern tools for construction. You're going to be looked down upon by the rest of your industry that moved on to wood, brick, and cement. Deal with it.

MetroTwit is the only other app with a great new Metro UI that I've found.

No, they haven't. GitHub only recently changed their top toolbar layout to include those icons, and today expanded them with even more indistinguishable-at-a-glance ones.

Does Rails not have an equivalent to the Django-Debug-Toolbar to easily debug stuff like this in development?

As for production, going with a fleshed-out service like NewRelic makes more sense to me. If I see slow queries start happening I'd want a broader report of what's going on in my system, not just a map of the query to a controller/action.

Regarding "Don't use ancient system Python versions" and "Use virtual environments", you can knock out two birds with one stone by just using pythonbrew. It also saves you the hassle of rolling your own deb/rpm if a package doesn't happen to exist.

Also, Chef/Puppet aren't "alternatives" to something like Fabric. Use the former for server provisioning, and use the latter for actually kicking off the deployment process. Trying to shoe-horn the finer deployment steps (git checkout, tarballing, symlinks, building the virtualenv, etc) into Chef was a nightmare every time I tried. Those tasks are better suited for Fabric's imperative design. Plus you can just run any Chef commands from Fabric itself, or use something like pychef for finer grained control. It's a win/win.

As someone who to this day still cringes every time they need to work with the subprocess module, do yourself a favor and use Kenneth Reitz's excellent wrapper library called Envoy:

https://github.com/kennethreitz/envoy

For reference, he's the same guy that did the Requests module, which is pretty much the defacto standard for avoiding urllib hell.

When doing a large refactoring or removing modules all-together, leftover .pyc or .pyo files can cause some very hard-to-identify import errors.

Sorry if the sarcasm was lost on you. GitHub very obviously has paid accounts and makes money without ads.

The last time I checked, GitHub has 0 ads on it. And they're clearly not making any money off of their users, because features like paid accounts don't exist. It's impossible to monetize a product without slapping tons of intrusive advertisements all over the place.

/s

In practice it's <2% on average per site. But at this point I don't view it as any extra effort. It's just a different way of approaching my development workflow. And it might just be a placebo, but it makes me feel like the site functions are more testable and compartmentalized.

Here is how I handle this for projects that I work on, and I haven't received a single complaint thus far:

1. Decide if the core of the site is undoable without JavaScript. Something like Google Docs or games relying heavily on Canvas/WebGL are prime examples. It is very rare for this to be the case, but if it is then disregard the rest of the steps.

2. Build the entire site without even considering JavaScript as an option. The advantage of this is I can finish all functionality without opening my browser window once. I build out the core with unit tests, and assert the base user workflow using integration tests that can simulate things like form submissions to route end-points. My test suite is now a constant confirmation that my site works with JavaScript disabled.

3. Open up the site in a browser, and begin the design & UX portion of development. Because the site is essentially feature-complete and tested already, I can have a lot of fun experimenting in this stage, tweaking things to my heart's content.

4. I slap this on the page after I'm satisfied with the enhanced UX that design and client-side scripting provides:

    <div class="jsnotice">
        We notice that you currently have Javascript disabled. While this site is fully accessible
        without it, you're still missing out on some pretty neat features. We work tirelessly
        to ensure that our scripts are small, unobtrusive, and do not harm your user experience.
        Please add us to your whitelist, or <a href="//enable-javascript.com/">enable Javascript in your browser</a>!
    </div>

Using Modernizr, that class only shows if JavaScript is disabled. The message itself is unobtrusive, and I always provide a way for the user to dismiss it permanently. If I want, I go into a little bit of detail on what "features" they're not experiencing fully.

The only reason Wordpress and Drupal became successful is because PHP is present on basically every shared host you can find on the internet. They stayed successful by building a community of plugins and themes.

The actual internals of both are a complete mess, and trying to get them to do anything outside of trivial blog hosting and content management is a nightmare.

Just because you don't know of any Python/Ruby/Java "apps" doesn't mean they don't exist. Jenkins, Redmine, Trac, etc.

The same could have been said for the dozens of front-page discussions the past few weeks about Sexism in this industry.

I'd just like to comment that, having built a medium to large Flask app over the last year, I would never recommend it as a framework for non-trivial sites.

I don't even want to sum up the amount of time that Django would have solved my problem instantly, but instead I had to pull my hair out dealing with Flask's global variables, circular dependency issues, and general lack of cohesion or standards. I think it's a great micro-framework if you're writing a one-python-file personal site or blog. Anything larger than that and you're going to regret it.

The parent comment was only pointing out how incredibly fast and easy it is to get started with TastyPie. The moment you decide to create an API resource that isn't a one-to-one mapping with a database table or Model, TastyPie is still able to come with you every step of the way.

Sorry, but I wouldn't give up Django-TastyPie for anything else (including Flask) for API development. Sure, I could spend a month building an API framework from scratch in Flask for a project, but why would I?

For those wanting to see an interesting approach to solving this problem (not written by me): http://tumbledry.org/2011/05/12/screw_hashbangs_building

Associated HN discussion: http://news.ycombinator.com/item?id=2592741

Can you honestly not see that they stacked the competition in their favor by customizing the device from its stock install state?

And not that it's relevant, but I like Microsoft's products. I think their direction of the latest Windows Phones are great. I'd rather they didn't resort to cheap tricks to try and "prove" that their product is better.

I find it more interesting how incredibly shady and underhanded the entire "challenge" is to begin with. They get to choose the exact rules and conditions, for which they've specially customized their phones beforehand, even if it's completely outside the bounds of what an average consumer would ever do.

In this case, it was to show the weather of two different cities. The only reason the contestant won was because he happened to need that information enough in his day-to-day life to warrant the two separate weather widgets on his home screen. The Microsoft representative obviously knew what the challenge would be going in, and already had the tiles ready to go.

All of my casual chat with friends happens over Google Talk, Facebook, or Twitter.

All of my work-related communication happens over internal Jabber, IRC, or Skype.

AIM, like MSN and ICQ before it, has gone the way of the dodo bird in every tangentially related social circle that I've touched in the last 5 years. Frankly I'm not surprised in the least that their tech team was supposedly all laid-off... I didn't even know that one still existed for the product.

The languages themselves are pretty equivalent. But with PHP it's easier for newbies to grok things when you can just point a web server at a directory that has a "blog.php" file in it, and visit "myserver.com/blog.php" to execute that script and see results. With python you have to understand the basics of what WSGI is and how it works, which is pretty poorly documented for people just starting web development. The "visit a file from my browser's address bar" motif is easier to grasp than "my url gets interpreted as a string that I then parse and route to a function imported from some other file".

Again, because PHP has such a low barrier of entry, more developers use it. So it's only logical that you'd see more tutorials and questions for it.

No, I'm not implying that. Of course it's possible for a poorly written site to be built with Python or Ruby. But I've never seen a single one expose its implementation details through filename extensions, or map urls directly to files on disk: both things that PHP does by default.

Yes, I've used Cakephp. It's a slight improvement.

Sorry, but my primary complaints of PHP are in no way related to anything that I've "brought to it." These are all default behavior out of the box:

- Error messages that are often nowhere near where the problem is, and sometimes contain no stacktrace

- PHP-provided function names are inconsistent and follow no set convention, mostly because the language was built without Objects or Namespaces

- The arguments to PHP-provided functions are arbitrarily ordered (such as array manipulations, and string searching). I have to look them up every... single... time.

- Core features of basically every other popular dynamic language took years to arrive in PHP. Hell, it didn't even get a real shorthand array syntax until a few months ago.

- Backwards design decisions, such as having sort-related functions modify data structures in-place.

- Completely insecure on a default install. No directory traversal protection, combined with having urls map directly to on-system files, is a recipe for disaster.

- No isolation or easy support for simultaneous PHP working copies. If I want to work locally on 2 separate PHP projects, each requiring different PHP versions and different (often conflicting) libraries, I have to pollute my entire global workspace.

I could go on, but it's making my blood boil recalling the times I had to deal with this foul stain of a language. There is no reason for a self-respecting developer to ever choose it, especially when alternatives like Python or Ruby exist. Period.

Because Python and Ruby sites are built properly, and don't expose their filenames as extensions in the url (.py or .rb). In fact, their urls don't even map to actual files to begin with, which immediately avoids several large security holes in PHP-built sites. With PHP you have to do some clever url rewriting and redirecting all your traffic through one central "index.php"-like script.

PHP is the training wheels of the server-side language world. You can pick it up and almost immediately see results on any number of popular hosting providers that provide support out of the box for it. That's why you see it so much.

I should have specified that those actions take place out of context. Such as showing a half-naked man riding on a horse down the beach to sell a product to women.

Obviously everyone has different sensitivities, but if you cannot objectively identify sexism of both men and women in advertisements, yes you're a hypocrite.

I never intended it to be a counter-argument. I was just pointing out how hypocritical it would be if you don't agree that half-naked men in advertising is as equally sexist and offensive.

I really hope that everyone is as equally offended and quick to point out sexism for every advertisement, television show, and movie featuring a very fit, shirtless man doing a stereotypical "masculine" activity (construction work, heavy lifting, playing a sport, or fighting each other).