rcoder

My understanding is that Scala already wraps lambdas in internal class instances with a `call` method, so I would imagine that CPS will carry a similar performance and memory hit.

It certainly won't be quite as fast as idiomatic Java code, but it should be considerably faster than other non-local exit implementations that rely on exception handling to manipulate the stack.

Supporting multiple version control systems means accepting the set intersection of their features as your baseline. Part of why GitHub has been able to just fly is their laser-like focus on only those features which facilitate collaboration atop Git. (I say this from painful experience, having spent much of the last couple of months months trying with only limited success to make users of Subversion, Mercurial, and Git happy with the same UI for source code repository browsing.)

Furthermore, trying to implement fork queues, pull requests, and even proper contributor attribution atop Subversion would be a ridiculous amount of work for very little gain.

Regardless, if you really want to stick with Subversion, you might at least consider setting up a cron job that fetches to a local git-svn mirror and then pushes a clone to GitHub. You won't have to learn a whole new version control system, and your users will happily run circles around you with their ability to fork, branch, and merge before you can copy your source tree into a new tag.

This is something I keep trying to tell people whenever micro-benchmarks appear showing that such-and-such web server handles >5k concurrent connections within a particular memory footprint, or that this-and-that message queue supports 8k enqueue/dequeue ops per second without hitting disk.

How many Rails apps out there can handle more than, say, 200-300 concurrent clients without either pegging the CPU or bringing the database to its knees?

Putting Passenger behind Nginx just removes a need to install + configure Apache for folks who are already use and like Nginx. It may also have some benefit on memory-constrained environments like entry-level VPS hosts.

That being said, I personally think that folks who spend days or weeks tweaking their deployment to run in <256MB of RAM to save a few bucks a month on hosting should probably reevaluate their priorities.

Using a default configuration, Apache actually maintains a pool of worker child processes which handle the actual request processing, rather than forking on every incoming request. You can allow it to fork more workers under load, or keep it locked down to manage resource usage. You can also configure it to use an alternate MPM (Multi-Processing Module) to use thread pools, fork on each request, or some mix of the above.

The difference in resource usage is due more to the fact that Apache is written to be a sort of generic network service platform, rather than a lean-and-mean HTTP server. It allows plug-in modules (whether written in C, or any of the mod_perl/python/ruby/etc. dynamic language bindings) to interact with just about any stage of request processing. In addition, a default Apache install will usually link a large number of other modules in each worker

That being said, tuning Apache for performance + minimal resource usage is a bit of a black art. If you're not comfortable configuring + building your own server package from source, it's probably easier to just grab Nginx and be done with it.

It's not a question of being able to "afford" dropping out to work on a startup, so much as it's a question of what you're willing to give up to do it.

My parents made less than $30k combined when I entered college in the late 90s. I dropped out after my freshman year, worked as a restaurant cashier and temp for about six months, then managed to land an entry-level media production job at a startup. Since then, I've slowly clawed my way up to a decent development gig at a major systems player in Silicon Valley, all without the benefit of a college degree, or any major financial support other than my own earnings.

Even several years after I first "broke in" to the industry, however, I've had entire years where I made only a few thousand dollars. If you're willing to live in shared housing, eat a lot of cheap stir-fry and soup, and occasionally suck it up and ask a friend or family member for a couple of hundred bucks to make rent that month, you can weather some pretty drastic changes in your income.

Regardless, after a decade or so of working as a developer, I've found that the lack of a college degree matters less and less. Am I less likely to be on the short list of folks to get promoted to upper management? Almost certainly. Does that bother me? Not really. I like writing code, and am happy to continue doing so until something else seems more interesting.

I was at demo these guys did for a SV Rails Meetup, and while the basic functionality is pretty damn cool, I have some concerns about the base footprint of applications.

The baseline they quoted was 2MB, which may not be much when you're talking about a desktop app downloaded over cable or DSL, but in the mobile space, where (non-iPhone) devices may only ship with 50-100MB of storage free, and many users are served mostly by poky EDGE networks, a multi-MB "hello, world!" seems a bit excessive.

That being said, for their core market -- namely, developers porting enterprise app UIs to mobile devices -- I think it could be an acceptable tradeoff for the productivity gain that results from it being "just another browser app".

Honestly, this isn't all that far off -- modern Intel and AMD chips have essentially nothing in common with the old 8086 line, and in fact use microcode heavily to "emulate" the classic instruction set.

Of course, it took them a few years longer than he thought to get there, but the basic idea is sound.

If you know and like Tomcat, may I suggest you have a look at JRuby deployment for Rails apps? With recent versions of jruby-rack and the warbler gem, it's as simple as listing your dependencies in a config file, and then running 'rake war' from the top level of a Rails app to get a shiny new WAR file ready to drop into your Tomcat deployment directory.

Once upon a time, people made the same comments about Ruby and Rails: "it's a fringe language", "the tools are immature", "you shouldn't use it because you can't find Ruby coders", etc., etc.

I find it honestly hilarious to hear it suggested that one of the early high-volume Rails shops should stick with "safe" language choices because they won't be able to hire enough developers to work with a new language.

I've read through the sources to Kestrel, and found them quite easy to grok. If anything, most real-world Scala code seems to be essentially very clean Java, with much of the syntactic cruft (redundant type declarations, inner classes, 'public static final' declarations, etc.) removed. Any experienced, effective developer is going to spend far more time getting to know your in-house APIs and coding style than they are the language.

A really talented sysadmin with good tools may be able to manage 100 servers; a great developer can optimize your algorithms to get an order-of-magnitude reduction in the number of servers you need.

Eventually, more servers == more headcount.

Please read the original article. Nowhere in it (or the original talk) does Alex advocate using Scala instead of Rails for the things that Rails does well -- namely, interactive web page rendering.

Within that niche, Rails does a fine job. For infrastructure and middleware code, however, Rails has little to offer other than the Ruby language, which has serious issues when applied to time + memory-intensive problem domains.

I'm a huge fan of Ruby, and a (perhaps somewhat begrudging) user of Rails, but that doesn't mean I think they're the right solution to every problem.

First of all, I don't think it's fair to accuse the Twitter dev team of working without real experience and numbers to back up their decisions. They have a huge volume of data being generated by their service, and have weathered the whole "Rails doesn't scale" flame-fest with relative grace and good humor. IMHO, that entitles them to talk fairly freely about the relative scalability of different languages and frameworks.

Secondly, any "ranting" you hear in this article is the product of El Reg, not Alex. He mostly offered a calm, positive presentation about the improved speed (with relatively little, if any, tradeoff in developer productivity) that came from using Scala instead of Ruby for critical infrastructure services.

Regardless, most Java web applications' performance issues stem from framework-itis, not from the underlying runtime. By itself, Tomcat (or another modern Java servlet container) is capable of some pretty impressive throughput -- perhaps not on par with a lean, pure C server like nginx, but not nearly as limited in functionality and extensibility, either.

No matter what you think about Java the language, you at least have to admit that HotSpot blows MRI, YARV, the Python VM, and Parrot out of the water when it comes to raw performance on low-level code. That doesn't save you from bad implementation ideas, but it does at least give you the possibility of getting fast, efficient code, if you have a decent compiler and work fairly close to the metal.

Using Scala is one way to produce that sort of low-level implementation code without wanting to gouge your eyes out (which is how most Java source tends to make me feel, anyway).

More importantly, Mercurial is extensible in Python -- you can write extension modules, hooks, etc., all of which have full access to the (albeit poorly-documented) Mercurial internals.

Writing extensions for Git is rather different, since you effectively can't. To extend or build on Git, you end up doing a lot of shelling out to the 'git' binary with use of 'raw' output formats and regexp-based scraping. It's pipes and shell subcommands all the way down, instead of a library-style programming API.

Which you prefer depends a lot on the diversity and preferences of the community using your repositories. Mercurial pushes you towards usability and single-language (Python) solutions, while Git easily drops into a classic UNIX-like "lots of little scripts" solution.

I've settled into a pretty happy workflow using Git as a local snapshot of an upstream Subversion repository using git-svn. With a bit of discipline, you can keep things nicely in sync, and get the benefits of cheap-as-hell branching and local/offline commits without forcing your entire project team to migrate to a new VCS.

I've got some notes on the subject on my blog:

http://rcoder.net/content/daily-git-svn

The key difference here is that one group is going after those they consider guilty of unauthorized copying of media, while the other is simply trying to have their claim of authorship respected.

Torrent files of MP3s and TV shows don't, as a general rule, mis-represent the original creators of a work. Because of that, they can still drive real revenue for those artists -- people may initially acquire an album or episodes of a TV show illegally, then go on in the future to pay for new content from the same people.

Doing a copy-and-paste job on someone else's blog content, however, breaks the link (however tenuous) between author and reader, which means that the author is unlikely to ever see anything of value back from the interaction. Not only are they deprived of direct financial (AdSense) and social (search rankings, public visibility) benefits, they are robbed of one of the most valuable commodities available to a blogger: direct feedback from interested readers.

Without a GIL, you not only have to make sure that your entire VM + runtime are re-entrant, but that every library you call into is, too. You can call it "lazy," but it's a fairly standard + pragmatic way to safely layer multi-threading atop arbitrary C libraries.

I work on the Project Kenai (http://kenai.com/) team at Sun, and we provide hosted source code repositories, ticketing, wikis, and a variety of other tools for project management.

We're still in beta, so you'll need an invite in order to actually create a project. Hit me up via email (my HN username at gmail.com) and I can pass along an invite if you're interested.

Honestly, calling this VC, or even an incubator, is probably a misnomer. This is an entrepreneurial bootcamp. Whether or not the training you receive in the program is worth $1500 is up for discussion, of course.

A simple one-way hash will provide sufficient security for most cases. Assuming you're representing items for sale in a Javascript array, you might send data like this to the browser:

  var forSale = {
    "book": {"price": 19.95, "description": "a book", "checksum": "c6da835c1fd2ee98d68eee3912dd199e41c82a32"}
  }

The value for 'checksum' is just a SHA1 hex digest of the ('book', '19.95', 'secret'), joined by tab characters. It can be included as a hidden form field or invisible element within your page; it doesn't matter so long as you can capture it and POST is along with the item + price.

In your order-processing logic, just check that the hash verifies with your secret key ('secret' in the above), and you know with a reasonable degree of certainty that the original page was one generated by your server.

I think you sort of missed the point of _why's original article, though. He's not lamenting the difficulty for computer-savvy adults to get started programming -- the main thrust of his article is towards our failure to provide an easy-to-use, freely-included sandbox for kids to experiment with programming.

How many of the other folks here started out just as described in this article: namely, writing silly little BASIC programs for early Commodore, Apple, or DOS systems?

There are a handful of projects aimed at just this niche (Scratch and Greenfoot, for example) but none of them come standard on any new system. That lack of immediate availability means that kids have to actively seek out the tools + have the ability/privileges to install new software before they can even start experimenting with something like this:

  10 PRINT "JENNY HAS COOTIES!"
  20 GOTO 10

AFAIK, none of the add-on replication mechanisms you mentioned can guarantee total consistency across multiple database backends: OIDs are not replicated, and there are no hard guarantees against external modifications taking your databases out of sync.

As an alternative, you can use Point-In-Time-Recovery (PITR), also known as "log shipping", to transfer copies of your write-ahead log files from a master server to a warm standby. PITR allows you to have an exact replica of your master database, modulo whatever delay you incur in the log transfer itself.

For those who haven't aren't familiar with write-ahead logs, they function much like the logging in modern filesystems: changes are written there before being flushed to disk, so any incomplete transactions can be replayed from the logs if the server goes down unexpectedly.

Of course, the log-shipping method doesn't allow your secondary server to serve as a read-only replica as MySQL's built-in replication does. Largely for that reason, (depending on your workload and requirements, of course) MySQL may be a better choice. However, I've found Postgres PITR to be an excellent option for low to medium-traffic databases in those cases where I'm willing to trade the possibility of the loss of a few seconds' updates for guarantees that my DDL, object identities, and constraints will be maintained consistently between my replicas.

For those who are curious, the PostgreSQL docs online have a decent introduction into the use of write-ahead logs for replication and backups:

http://www.postgresql.org/docs/8.2/static/wal.html

We use JRuby on Rails for my main project at work, but I've been doing some Clojure hacking in my personal time, and thinking about using it for some of our asynchronous job-processing needs. Using JRuby + ActiveMQ + Clojure would potentially let us cluster all our core infrastructure in the same JVM, while still getting nice concurrency across all our available cores.

My point is precisely that most state employees are not free to interpret law as they see fit. The rules defining hiring, retention, pay raises, etc., are written quite precisely across the board, not just for teachers. Trying to game the system is a breach of ethics, if not an outright crime.

I'm not trying to defend the public-sector model -- there are obvious inefficiencies, and many of the best potential hires would never even consider a government job for many of the same reasons you suggested. I'm just not sure how better to balance the need to be accountable to the taxpayers with the desire of administrators to pay their staff according to ability, not just seniority.

There's one critical area where assessment of teachers varies from those in medicine, law, etc.: many states require consistent salary and retention policies across all their schools. Given the limited resources available to do any sort of meaningful performance measurement, that pretty much means that any "pay for performance" model will necessarily require a single set of standardized tests that can be delivered to every student in the state.

...and we all know how well those sorts of tests measure real learning and intelligence, right?

As someone who spent most of my primary school years in "gifted student" magnet programs (like, I suspect, many other HN readers), this appeals to me personally. However, I have it on good authority from actual teachers that separating students according to interest and aptitude disadvantages the average and below-average students greatly, while providing only minimal benefit to the best students.

This argument still makes no sense to me. Teachers are in an obvious and direct way responsible for producing the next generation of doctors, lawyers, and computer programmers. How can we then in good conscience refuse to pay them as much as people working in those fields?

Think of it this way: in private firms, employees who demonstrate mastery of both their own specialization and "people skills" are promoted to management, so that they can guide and support the next generation of workers. They are paid more for this than their employees, in part due to the fact that not everyone can do what they do. Similarly, teachers have to balance knowledge of the actual material being taught, and all the "soft" skills of classroom management: facilitating discussions, maintaining discipline, keeping emotions and energy on an even keel.

Any manager who could effectively herd 30+ techies would be lauded as worth their weight in gold; why then isn't a teacher who does the same thing with as many children (a harder task, to be sure) appreciated as the deft administrator they must be?

> What is the relevant difference between axe-handles and music?

Music is more than a product -- live performance is a social experience, not just private consumption. People go to see bands live for many reasons other than the rendition of notes they could get from a recording: they flirt with other concert-goers, they experience mistakes and improvisations by the artists, and they drink and dance in public.

Similarly, good teaching is not a solitary or entirely reproducible event. The best teachers I've ever had were the ones who could get students talking to each other, generating and assessing ideas faster than any one pupil could alone. You can't get the same experience reading a textbook or watching time-delayed streaming video of a lecture. I'm not even entirely convinced that online interaction can pull it off, at least in areas like history and the arts, where subjective and emotional arguments are just as critical as hard logic.

There is more than one axis on which coffee shops compete, though. Price is one of the least-critical, IMHO -- ambiance, service, and "extras" like a decent menu or late-night hours will earn you a lot more loyal customers than a $0.25 price cut on coffee. Remember, if cost was the major deciding factor, people would be making their coffee at home. Going to a coffee shop is a social act, so the "scene" matters at least as much as the product.

The problems (and attempted solutions) the article's author described sound to me like they all stemmed from a lack of interest in paying any attention to the market. He admits that the most prominent and loyal types of coffee shop customers (commuters who just want to grab a cup for the road, and laptop warriors who want to sit tight and work for several hours) weren't interested in his business, and then seems surprised that he failed to make a profit? Color me unsurprised.

You can make money in the service industry, eventually -- but you have to provide something that people want. Simply being in love with your own clever ideas is seldom a good path to profitability.

I noticed that, too -- it really looks like they want a single individual who can both make high-level technical decisions and implement + support a bunch of infrastructure at the same time.

I would call that person a co-founder, not a CIO, and a particularly over-burdened one, at that.

Look, I'm the last person who would assert that a liberal undergraduate education is a necessity for everyone -- I dropped out of a high-priced, prestigious liberal arts college after a year, started coding for a living, and think I made the right decision. That being said, there is real value to be found even in the "soft" classes at such institutions.

While any college likes to tell potential students and parents that they'll teach their students "how to learn," the truth is that most kids do still have a lot of cognitive development to do at 18 years old, and even more social and professional. Being able to spend several hours a day arguing about complex and nuanced subjects with other bright young people (all under the supervision of a facilitator with a very high level of expertise in the subject under discussion) is an almost priceless experience.

That being said, it shouldn't cost $50k/year just to be able to have those discussions. Moving some of the content online will help (though some amount of face-to-face interaction is still a must to develop good social graces IMHO). Cutting down on the level of pampering should be a first step, too -- at 19 years old, there's little excuse for someone to be unable to cook for themselves, or find a place to live.