rcoder

Since adding and removing Apache modules already requires a restart of the httpd process, a good source-based build system like ports can make adding and removing modules via build flags nearly as straightforward as dynamic loading.

I just wanted to weigh in and say how huge this is, not just for the question of "is buying a better deal than renting," but also to allow you flexibility in terms of job relocation and family changes.

My girlfriend and I moved to the Bay Area about 18 months after buying our first house, and were able to do so in part because the rent from our tenants (who are good friends, as well) basically covers our mortgage. Not having to feel tied down to a particular city allowed me to take a risk on an exciting new job that I probably would have passed up if relocation had involved selling our house.

http://gist.github.com/945435

There's an anonymous superclass injected into the inheritance chain every time a module is included into a class.

So, while it might make sense to use explicit superclasses as a semantic modeling method, the runtime behavior is effectively the same whether you use a mixin or a concrete class.

First of all: you're just straight-up wrong about file transfers and polling. The select(), epoll(), et. al. syscalls are exactly what you want for large network file transfers. This is not the same as naive "polling", but is what most implementers mean when they talk about an event/polling based server implementations.

Even "green" threading runtimes like MRI and CPython can still multiplex threads in the presence of blocking I/O calls, because the standard C syscalls can easily indicate when the main thread would block while trying to read or write.

Furthermore, a "threaded" server in no way has to allocate a full hardware thread for every client. Single-threaded, callback-based systems may fare nearly as well for I/O-bound workloads, but threads still have real value for many if not most real-world concurrent systems. A pool of worker threads can keep both the CPU and I/O subsystems maximally active without forcing a "shared nothing" architecture onto a system located on a single physical host.

In a world of multicore CPUs, limited L1/L2 cache, and fast kernel schedulers, threaded code can stand toe-to-toe with pure event loops for non-trivial workloads.

Even leaving aside the advantages of a DVCS such as Mercurial, I think that Review Board has a cleaner, more responsive UI. The "interdiff" feature (i.e., show diffs between changesets in this review request, not against the trunk) is pretty great, too.

Also, as a fairly mainstream Django app, it's not dependent on the App Engine runtime, which lets you run it on any standard Python/WSGI-capable web server on any recent version of Python. (App Engine only supports 2.5.)

If you're using Mercurial or Git, I'd highly recommend you check out Review Board; the initial setup is easy if you've deployed any WSGI apps before, and the web API makes it pretty easy to tie into your ticketing/CI/IRC bot/etc.

Um, ever tried to stream Netflix video from anything that wasn't running the latest Silverlight? Or diverting/capturing the video from the stream, even on an authorized client?

That's why there's still no Netflix client for Android or Linux, and why Netflix probably doesn't have to worry too much about content sniffing.

Furthermore, the only way in which WEP or WPA improve real security is by keeping folks who don't know the key off the local network. Since most shops freely give away their network keys to anyone with enough cash for a cup of coffee, and seldom if ever rotate keys, it's an awfully weak level of protection.

If you assume that other network users are potentially hostile, and/or that the coffee shop owner (or its ISP, or someone who "hacked" their Linksys router via an unchanged admin password) can't be trusted, your only real option is routing your traffic over VPN to a trusted host elsewhere on the 'net.

That doesn't require that a server know the key; it only requires that those parties exchange a shared key in advance. It's no different than, i.e., a PSK WPA network password, or a shared encryption key on a workgroup document.

You could still use a service like Dropbox as a reliable offsite backup, while doing all your crypto locally. Think of it as the "availability" service to complement your local policies that insure integrity and confidentiality.

Might your students be better served by learning to use a more traditional version control system than Dropbox as a repository for their class projects? Mercurial and Git both have "large file" extensions/forks available that make asset management less painful, and the lessons learned w.r.t. workflow would carry forward into many other, non-game-related programming projects the students undertake in the future.

I'm sorry, but I don't follow.

For all bit-identical copies of a file, the secure hash will be the same. For all copies of that file encrypted with the same symmetric encryption key, the same property holds. Encrypt it with AES-256 using a shared key, and all users can still take advantage of the LAN copies and de-duping that Dropbox supports for unencrypted files.

Now, if you want full asymmetric (RSA, PGP, whatever) encryption of files with per-user keys and fast LAN copies/de-dupling of the plaintext version, you're of course out of luck. That's not a failing of Dropbox, though; the same would be true of any NAS solution, locally-hosted or not.

Performance isn't awesome, but then again, the flagship NYTimes iOS app hasn't worked for me in weeks (crashes on startup, fails to refresh articles when no other app has connectivity problems, etc.) so I might just give it a shot as a Times UI for a while.

It goes both ways, of course; less-savvy candidates might not know what they're getting into, and can be offered what seems like a sizable salary bump only to discover after arrival that they're worse-off in total.

: I Am Not A Kernel Hacker

As long as the fixed overhead of the patch is small (which the linked thread seems to indicate) this should be a sizable win for desktop Linux boxes without much downside for server loads.

The upside is that the city is only 40 minutes away; the downside is that SF tends to be kind of a black hole for culture, sucking everything cool into the city limits and leaving the south bay with all the strip malls, supermarkets, and car dealerships.

If you're going to school or working a startup, it can be survivable. There are enough coffee shops, cafes, and restaurants around downtown Palo Alto to let you pass a lazy Sunday afternoon pleasantly enough, and the occasional trip to SF by car (or by train, with a hotel stay in the middle) helps to alleviate the boredom.

Not to continue this off-topic digression too much further, but a Mac Pro running OS X Server is in no way a replacement for an "enterprise" XServe deployment.

For a full explanation, see this TidBITS article:

http://db.tidbits.com/article/11735

tl;dr version: The Mac Pro takes up 4x the rack space and lacks hot-swappable power supplies and drive bays, making it an awful fit for most 24x7 server environments.

At this point, we've created our own payment gateway wrapper. At an API level, it doesn't look terribly different from Paython, so I'm cautiously hopeful that we'll be able to port our PayFlow Pro and stored credit gateway backends if it looks like Paython is gaining traction.

On top of those, we use Apache, mod_wsgi, Fabric (in a slightly-weird way which I'll get into below), mod_xsendfile, Mercurial, and a home-grown migration library.

Serving static files via nginx or Apache is fine, but generally requires that you copy them out of your various pluggable apps and into some static docroot on every deploy. We use mod_xsendfile instead (with another Django helper app, which I'm hoping to get onto Bitbucket in the next week or two) to directly serve static assets out of the 'media' directory of each installed Django app.

Our use of Fabric is slightly non-standard, too, as I mentioned; instead of writing a single 'fabfile', we have a collection of development, testing, and deployment commands which use Fabric as a very high-level Python API for distributed command execution.

Regardless of the stack you choose, as a non-sysadmin, there are a few habits and practices I'd strongly recommend you keep in mind to avoid getting yourself into a painful place later:

First, set up a staging environment that looks as much like your production setup as possible. It can be on the same server, or in a local virtual machine, or (even better) on a spare server that can be pressed into duty if the primary ever goes down.

You should always have a recent dump of your production database loaded into this environment, and the ability to pull a more up-to-date snapshot in quickly. (This will help with recovering from major "whoopsies" in production, too, and force you to continually test your backups.)

Second, keep copious, detailed notes on everything you do while deploying, updating, or troubleshooting production issues. I'm literally talking about stuff like this:

  Created uploads directory:
  mkdir /var/www/uploads
  chown www /var/www/uploads
  chmod -x /var/www/uploads

  Configured upload directory in Django settings:
  echo "UPLOAD_FILE_DIRECTORY = /var/www/uploads" >> /usr/local/deploy/myapp/src/myapp/settings.py

I like to use simple text files (backed up in Dropbox, of course) for these notes, but a wiki is fine if that's your preference. It may seem like pointless duplication of effort at first, but grepping a directory full of notes to see what you changed is a much more reliable triage technique than counting on yourself to remember a bunch of details. This goes double when you're panicking in the middle of a production outage.

Beyond that, everything else is gravy. If you're using Apache/mod_wsgi now, I'd recommend you keep using it until you hit a real scaling limit, or have spare cycles to try out a secondary hosting setup post-launch.

(In case anyone's interested in that migration tool, it's on Bitbucket: https://bitbucket.org/rcoder/finch/overview )

I also assume that every Mac is going to have to be assigned a UDID now, unless Apple is completely reinventing their DRM scheme. Regardless, the piracy options for Mac apps are almost certainly going to be similar to their iOS cousins, if not a little easier because every Mac is effectively "rooted" out of the box.

https://developer.apple.com/appstore/mac/resources/approval/...

Also, while V8 is quite heavily optimized for performance on modern PCs, I haven't seen much to support the idea that it is a great fit for memory and CPU-constrained mobile devices. Early versions of Dalvik specifically traded runtime compilation (as implemented in HotSpot and most other modern JIT-ing JVMs) for ahead-of-time in order to minimize the memory footprint of applications. Any VM designed around heavy runtime optimization (like a mobile V8 derivative) would have to be carefully tweaked to not thrash horribly given the memory constraints on most smartphones.

There's no silver bullet here. Hashing on insertion order would basically guarantee that writes would favor one node over another, which random hashes would force you to aggregate results from all available nodes for each query.

PHP is a very pragmatic, simple language with a complex and baroque set of libraries. It's great for hacking together websites, but working with PHP (even for many years) doesn't tend to teach you the kind of technical and aesthetic judgement that differentiates an assembly-line coder from a productive, engaged hacker.

Learning Ruby or Python might be the shortest path to another gig, but it probably won't push you outside your comfort zone far enough to really improve your programming if you stick to the usual Rails/Django garden path. If you want to really push yourself and grow as a developer, learn something completely unrelated to the standard LAMP stack.

Lisp (especially in a modern form like Clojure) is a good choice, as are Smalltalk and Erlang. C++, Java, or C# may let you jump up a pay grade or two, but tend to lead into dead-end "enterprise" coding, unless you're lucky enough to stumble into a top-notch shop that happens to be using them for their efficiency rather than their "manager-approved" status.

Most importantly, I'd suggest actually building something in whatever language(s) you decide to pick up. Reading blog articles and tutorials is all well and good, but it's far more impressive for you to be able to show code and talk from experience about the relative strengths and weaknesses of the languages you've worked with. Even a half-finished side project hosted on GitHub (or hauled into your interview on a personal laptop) will go a lot further than regurgitating buzzwords on demand.

Linux may have gained real acceptance as a server OS, but businesses overwhelmingly still prefer Windows on the desktop.

Also, if you're hiring programmers who can't pick up a new language to work on your project, you're doing it wrong. Most of the capable folks I've worked with loved learning new tech; the problem is usually keeping them from jumping onto a new platform for every project.