mattlanger

Because if you've been coding since you were eight then you should probably know by now the difference between anecdotes and data.

[Full disclosure: I did my first hacking with BASIC and Rexx at around seven or eight because my parents were wealthy enough to afford an Amiga 500--but this experience would never inspire me to write an article claiming that everyone who started coding at a young age must have come from similar socioeconomic conditions.]

And I think this speaks to one of the points I tried to make here (http://langer.tumblr.com/post/538680961), which is that ideas like this can come off as witty or clever in such a male-dominated industry because most of us are tone-deaf to the many ways in which another person might find something like this offensive.

Interesting. There's more on page 3 in case you didn't read that far.

That the author seems to view the present through the lens of a struggle between Islam and Christianity, it is somewhat unsurprising that he should view the future through the similarly black-and-white lens of Western democracy v. totalitarianism.

If anyone else was confused by this, I believe it is in reference to http://goo.gl

I had not heard of that project until just now. It's nice to see they're giving it some thought rather than just slapping something together, but I'd love to see "longevity" added to the project goals.

But, in the context of the present economic zeitgeist, my sympathies go out to the fully qualified guy or gal who is out of work and probably freaking out about it who now not only has to jump through hoops in order to submit a resume but also has to see her career marginalized with terminology like "code ninja" that was already trite five years ago. My sympathies most definitely do not go out to the person actually getting paid to read the resume, on the other hand.

2.) The person you want to hire is probably going to think twice about working with a group who considers viewing HTML source to be a demonstration of one's "ninja-skills".

3.) The person you want to hire probably got bored after 30 seconds and went to go do the http://www.pythonchallenge.com/ instead.

Whoa, that's a lot of data.

Interestingly, though, the Comcast ToS (just as an example: http://www.comcast.net/terms/network/amendment/) would see users capping out on bandwidth allotments in just a week at this suggested rate: 250 GB/month is an extremely large amount of data, much more than a typical residential customer uses on a monthly basis. Currently, the median monthly data usage by our residential customers is approximately 2 - 3 GB.

Granted, those gigabytes can come via non-internet channels, but that number still seems mighty high.

I moved personal and work email to Mutt and uninstalled my Gmail notifiers; I moved IM to bitlbee on irssi; I moved RSS to Newsbeuter; and I moved Twitter to ttytter. I keep all of this running in a screen on my remote shell.

And this was certainly not the intent of my project when I started it, but I can't even begin to tell you what a difference it's made for my productivity. I usually leave my screen on an empty shell prompt, so even if I see my terminal I've got no idea what's going on in those other terms unless I actively go looking for them.

Granted, I have the luxury of working at a small startup (< 20ppl) and I can maintain some aloofness with regard to IM (because if a colleague really needs something from me I've probably not more than 20ft away), but as far as this other stuff goes, do you really need to know what's happening on Twitter in realtime? Is there ever really an email so important that it can't wait until you've finished your current thought?

Positing the existence of the decimal system because humans evolved with ten fingers is something I can get behind. The seven-digit phone number, on the other hand, I'd probably attribute to other causes.

Be careful with that line of thinking. Time and again throughout the history of the digital age, data has ceased to exist precisely because it was in a digital form. Consider this remark from the US National Archives: "By the mid 1970s, when computer tapes for the 1960 census came to the attention of archivists, there remained only two machines capable of reading them. One was already in the Smithsonian. The other was in Japan!" An entire task force now exists at the National Archives (http://www.archives.gov/era/papers/preservation.html) to address the problem of expiring data formats (old cassettes, magnetic tape, etc).

Take the following hypothetical: if Google goes under sometime in the next decade, and takes all of its data with it, the thousands of volumes that have been archived by the Google Books project will persevere only because university libraries around the world have copies of them on their shelves. Data continue to exist even when they're not immediately available to us at our terminals.

[And this is most certainly not the forum for this, but if I'm reading between the lines correctly you seem to be speciously implicating that Judaism was surpassed by Christianity as the predominant western religion because of its failure to embrace the printing press, but I would point out to you that a.) I own a lovely bound copy of the Tanakh, published by the JPS and available from Amazon for the low low price of $23.10, b.) the total number of adherents of Christianity had leapfrogged Judaism by at the latest the 4th century--a full millennium before Gutenberg--and would only continue to skyrocket seeing as it was the de facto faith of a sprawling political empire, and c.) Judaism is an inherently non-evangelical faith, so talk of such competitive tallying is really irrelevant anyway.]

It seems to cover a lot of bases, too: a student's HTML must validate, she has to get her feet wet with at least a little bit of JS and Ruby, she'll have to open up Photoshop at least once--a pretty well-rounded picture of a project lifecycle.

It might be neat to add an additional project onto the end on deployment, so students would have to muck around on a command line a little bit, configure Apache, etc.

I've been thinking about this a lot lately through the lens of late-19th- and early-20th century European philosophy and literary theory, when guys like Gautier and Baudelaire and Mallarmé and Benjamin and Kraus were livid about the rise of the newspaper and, later, the feuilleton (early serialized novels). These men--poets, mostly, or at least advocates of the form--saw the confines of the newspaper column as a reduction of writing proper, where writing (in their strict poetic sense) necessitated a careful consideration of the placement of each word on the page.

The same considerations can well be applied to blogging, at least on an abstract formal level. You're very right: it all falls apart if there's not ample content to back up a thoughtful design. But it is probably still the case that while a great design may do little for mediocre writing, great writing can be held back by mediocre design.

Well the difficulty really arises when you want to go a step beyond full HTML control and allow for JS and AJAX (think pagination with really artful page transitions). How do you allow users complete control without turning your service into a cesspool of XSS attacks?

Their question as to whether blogging is "too easy" really resonates with me: I began prototyping a CMS a while back on the premise that Blogging Should Be Harder (a reaction of sorts, I guess, to services like Posterous and Tumblr [full disclosure: I am a very happy user of the latter]). And what I found is that if it's hard to design a "blogazine"--manually setting type and choosing colors for each individual post--it's just as challenging to build an "anything goes" CMS.

I still think it's a great idea. There might only be a handful of people out there who would use it, but those that did would likely be producing really top-notch content.

Or as is so often the case (and also a valuable learning experience) how to unsuccessfully run a business.

I like to think that the whole point is to make something awesome/memorable/useful/meaningful/worthwhile that also creates jobs and produces wealth.

I made the foolish decision a while back to choose a data storage option based on benchmarks and hype, and I'm currently paying for it by having achieved spectacular launch failure and now completely rearchitecting my backend.

NoSQL emerged only after a decade or so of webscale challenges helped us finally realize that everything only looked like relational nails because the only tool we had was SQL hammer, and that tackling every data warehousing problem with SQL was coming at the cost of money, engineering hours, and headaches. Now that viable, production-ready alternatives have become available it's important that design decisions to go beyond seeing problems as not-nails and seeing them instead for what they are.

Are you looking for reliable, versioned master-master replication for embedded devices? Might want to consider Couch. An obscenely fast caching tier that need not persist to disk? Sure, check out Scalaris. A fully distributed and pluggable map-reduce architecture capable of storing a metric fucktonne of data? Hbase might be for you. And, it should go without saying, there are still and there will always be problems for which SQL is the best solution.

In any event, an invaluable starting point is Richard Jones' post at Metabrew discussing research on a number of options for Lastfm: http://www.metabrew.com/article/anti-rdbms-a-list-of-distrib...

I ran across this sometime in '99 or '00 and got inspired to create a Flash presentation of all the proofs. It got a little out of hand when I decided to do the same for Apollonius' conics, which in the days of pre-1.0 Actionscript meant rolling your own trigonometric functions.

That PC later crashed and I lost everything, but this site is still kicking around. I love the internet.

Read it all--it's worth it. Plus, that this was even written (not to mention well-received) poses a fine counterpoint to any argument stating that storytelling on the internet is dead: http://www.kungfugrippe.com/post/169873399/clackity-noise