postfuturist

As a part-time PHP hater who often has to work with it professionally, I believe this is a fantastic resource. The bit on databases in particular is something that all PHP devs should read.

That said, it is difficult to bring a legacy code base in line with modern style, though you can improve it over time.

Also, this could benefit from some other gotchas, extremely surprising behavior and best practices for avoiding common pitfalls.

If you violate the GPL license on code you are distributing, you can be legally compelled to stop distributing the code and pay damages to aggrieved parties. You cannot be compelled to fulfill arbitrary requirements of the license, like sharing private information, your own source code, punch yourself in the face, fly to the moon, or give up custody of your first-born child.

Made in USA is about much more than just patriotism. In the USA, many people buy locally produced goods since it supports the local economy better, reduces carbon emissions from shipping goods half-way around the world, and isn't produced in slave-labor conditions of 3rd world countries.

(Also, you don't understand patriotism? It's tribalism, something deeply encoded in our behavior from many thousands of years of tribal evolution.)

The original is freeware and runs nicely in dosbox (warning, it is rather fun). I'm backing this just as a thank you for making the original free.

Hm, what if there is an error in processing and you've already sent the "HTTP/1.1 200 OK" and started streaming output? You're better off utilizing caching and other optimization based on profiling.

mod_wsgi + Flask (or just about any WSGI-based python app) is relatively straight forward: http://flask.pocoo.org/docs/deploying/mod_wsgi/

Looks like another overpriced Google TV. I already have one, and it isn't supported very well. Never again.

Looks like a nice API (in a few languages) on top of some basic AMQP functionality backed by RabbitMQ. We're building something rather similar (for internal use, not a product). Might have to keep my eye on it, though it's hard to tell what it would cost for server licenses from the webpage. The core server is closed source with rate-limited free binary downloads.

Very fun, needs a keyboard -> piano key mapping for maximum pleasure. Oh, I see it's open source, too bad I'm at work right now.

I've found Vim + Slimv + SBCL an adequate development environment as a long time Vim user.

I've really tried to make a conscious effort to always assume that someone's opinion is valid, even if I disagree, and to extend this to all matters of taste and opinions. I understand that some developers like working in Windows, or enjoy developing native iOS apps. First, I can't assume that it's always because of cognitive dissonance or ignorance that people enjoy things I loathe deeply. Second, I need to make an effort to recognize the aspects of the thing that are desirable and assume that the things that bother me, don't bother everybody in the same way. It's an unpopular mode of thinking among software developers, which is normally ruled by tribalism and prejudice.

A significant fraction of our users are on IE 7 and 8. We use this for charts, they look great on IE: http://g.raphaeljs.com/

This device doesn't look like it will work well in my lap. I use a 5 year old laptop that I'm pretty happy with. I have a tablet that I never use but that's mostly because I don't like touchscreen interfaces, except on phones where they are lesser of 2 evils (the other evil being super-tiny keyboards).

I ran into a wall when trying to use unix-y tools to do somewhat complex, regex/replace functions for code refactors. Basically, anything inside a single line is easy, but once you cross that line barrier, the complexity increases dramatically. That rendered the changes useless because most programming languages allow you to add arbitrary new-lines between any token in the language.

I'm not the poster, but Hardy is an LTS release that is still supported in server configuration. It's quite a bit newer than Centos/RHEL 5, which is widely deployed on servers (potentially the most popular platform for existing deployments, still).

It's an up-front investment in time that pays off over the long run. I do it all the time in programming, pick the right API's and abstractions ahead of time (spend a good amount of energy and time) so I don't have to spend as much time and energy later. Eventually it pays off--a lot. If you think how you dress doesn't affect how people treat you in the world, you're terribly mistaken. Even more if you are a woman.

This is a nice hack.

Most JavaScript implementations are faster just due to the amount of R&D dollars poured into them due to browser competition. Ruby, Python, and PHP could (and should) have runtimes competitive with, say, V8, it's just that nobody has built them yet.

7 blocks has to be the shortest solution, right? http://imgur.com/r50yY

You're making a lot of assumptions that aren't true. I regularly instruct doctors on my condition in detail, they do usually listen and are reasonable. However, I am often disappointed by the lack of depth of the research they do in advance of meeting (and billing me exorbitantly).

Recently, my sister (same condition) drove a couple hours to see a specialist who had obviously not read her file or done any research and made some truly awful suggestions (one that could certainly have lead to her death if she had followed it). He billed her for the time.

Doctors are like coders, some are orders of magnitude better than others. Some are so bad, they have a net negative impact on your health.

Yep, it's also disheartening to see them holding a printout of one of the few articles available online, which I already know is pretty out-of-date and down-right wrong in places.

It pays to become an expert in your own (or your family members') medical conditions, because you'll quickly become more of an expert than 99% of the doctors you will rely on for care. It helps when they all ask the same dumb questions, which they will do. If your condition is mildly rare, you'll notice when you see a new doctor, that their knowledge will be limited to what you found out in the first hour of internet research on the condition, unless they are a specialist on that particular condition.

I have a slightly rare genetic condition, and I've only met 2 doctors who know more than I do, and that's because they do active research on the exact condition and have authored or co-authored multiple research articles on it.

I'm just a working developer. I'm not looking to start a business of my own any time soon. I'll say one thing: I don't work for companies that cut paychecks out of rapidly dwindling venture capital funds and I don't work for large corporations that hire and fire teams like chattel. If the bubble burst tomorrow, it wouldn't affect my life in any meaningful way. I'd probably get fewer recruiters bugging me, which would be nice for a change.

Have you read RFC2616? It is quite approachable, and this is an improvement over the plain text version. Any web developer worth his or her salt should know about it enough to at least look up status codes and headers. It's resolved a number of debates at work when designing REST API's.

Awesome! Small, but important bug is that internal links are broken:

correct link : http://pretty-rfc.herokuapp.com/RFC2616#character.sets

link in text : http://pretty-rfc.herokuapp.com/RFC2616#character-sets

Programming tastes evolve over time. At one point, and for at least a few years, I believed Python was the one true language revealed mystically to GVR. Up until that point, I'd done most programming in C++, so you can imagine how much fun Python was, in comparison. After further development and discovery of other programming languages, the shortcomings of Python have become obnoxious, much like torturing someone by dripping water on their forehead incessantly. Part of the problem is that I have to use Python for my professional work now. Using a language for your day job is a sure way to reveal all the issues.

Here's what rubs me raw day-in and day-out:

1. Lack of immutable/persistent data structures. 2. Lack of multi-line anonymous functions/lambda. 3. Variable scoping fail, causing hacks like the new `nonlocal` keyword. 4. worst_possible_variable_name_convention. 5. Python evangelism. (community issue, mostly) 6. Hypocritical "explicit is better" and "flat over nested" values with insane amounts of magic built into language and class system. 7. No switch. 8. GIL. (Actually the CPython runtime in general) 9. No macros. 10. the insane way "unicode" is supported. 11. and on and on...

At this point I write Python code, but not generally by choice. Mostly my coworkers can't even imagine writing code in another language, given that we have been allowed to choose our implementation language(s) as a team.

Every fraud prevention scheme is going to have false positives, so there's no excuse for not providing the user with an appeal process.

Any given site might not experience a DDoS attack, but if you run a hosting company, it will happen. The frequency depends on how many customers you have, how popular they are, etc. If a DDoS attack catches you by surprise, then you are very ill-prepared. One possible strategy is to throw the targeted customer under the bus and call it a day. For hosts of a certain size, that may be reasonable, as long as you clearly communicate that to customers.

I've seen these attacks mitigated single-handedly by an experienced fellow with no access to fancy equipment. I believe it went something like this, change the DNS to point at some EC2 instances to do front-end load balancing with some scripts that detect and drop connections from attacking IP addresses and do severe rate limiting. You can proxy legitimate requests back to the original servers.

Granted, not everyone knows how to do that in a pinch, but it shouldn't be a big deal for a hosting company. You only have to figure out how to do it once and when you detect a DDoS attack, flip the switch for that customer.

DDOS attacks are a fact of life, nice to know that Rails Machine will throw you under the bus when one happens. Doesn't seem to fit their homepage description: "You write Rails apps. We deploy, manage, support, monitor, and scale them. Done."

I think we use this: http://pypi.python.org/pypi/chishop/

You just set it up on a local server, and upload packages the same way they are uploaded to real PyPI.

    python setup.py register sdist upload

You can specify alternate PyPI server with a ~/.pypirc. There are probably other ways to do this. What's nice about this is you can upload your own private packages or your own personal forks of packages. We do both.

We do this, but also add a couple layers of safety between us and PyPI:

1. Run your own secure, local pypi clone with exact source versions of the packages you use.

2. The packages for production are built into RPMs from the local pypi.

PyPI is great for discovery, getting things running quickly, and testing new versions, but you never want to rely on it, even for development.