duggan

Indeed, it's not like there are an endless number of common subdomains which don't convey much information. "www" is one, "blog" is another. That's about it.

Out of 150 students that graduated my year of high school (2003), an all boys school, I was the only one who chose to follow a computing career.

All my friends, even those with a similar (or more advanced) aptitude and interest in computers, chose different paths. Chemistry. Theoretical Physics. History. Politics. Economics.

Nobody wanted to be doing computing professionally. Men were/are afforded to be outcasts or underdogs, socially; there's some romanticism to it. I'm not sure the same has applied for women, but maybe that's changing.

Theory: the fields you mention, law and medicine, (historically and still) convey a higher social status on the member. There's also a relatively well trodden path through apprenticeship, successful practitioner, and eventual transition into other stable/respectable paths (politics, judiciary, hospital administration) as your career winds down.

Software engineering doesn't have that (yet?)

I've also made the image available in all regions, for those who want to run in additional regions:

  N. Virginia: ami-2400984d
  Ireland: ami-d8d2d8ac
  Tokyo: ami-a361e1a2
  Singapore: ami-6e703c3c
  Sydney: ami-4e0e9f74
  Sao Paolo: ami-9d7aa180
  N. California: ami-94f6dbd1
  Oregon: ami-cf9206ff

For those having trouble with the EC2 instructions, I thought I'd point out that I think that the Archive Warrior[0] (which is much easier to get up and running on your laptop, etc) running over my tethered cellphone is my most performant client.

Yahoo don't appear to rate limit mobile devices / IP blocks as aggressively as everything else (probably because cellular providers tend to have many customers behind one IP).

[0] http://www.archiveteam.org/index.php?title=ArchiveTeam_Warri...

Merits of whether Keep is comparable to Reader aside - I wonder how long we're going to be seeing the "...but Google Reader" refrain from pundits.

The camps of opinion I've seen on how Google should behave:

1) Pundits: Support an increasingly burdensome array of fringe services which cost them more than they gain (in their opinion)

2) HN: Reduce their experimental forays and leave (for now) private/small companies to their niches.

3) Coders: open source the services when shuttering.

1 and 2 would seem anathema to Google - the next Facebook could be hiding in either the organizational lethargy created by the former or the failure to act on the latter.

3 is going to be prohibitively expensive or difficult depending on how the service was built.

I'm just not sure there's anything other than a lot of sound and fury in the future of these discussions, which makes them boring.

Frankly, I think you are deliberately misinterpreting the spirit of the suggestion. Your interpretation reduces the original point to absurdity: "do something for no reward."

UDP is kinda the only game in town with in-app analytics (if you don't want to drop ZeroMQ all over the place); Metricfire's PHP (and other) client libraries have been on this for a while now - http://docs.metricfire.com/

Interested to know, since I've never "liked" anything other than friend's status updates, (and I "unliked" all the autoliking they did when they converted a bunch of profile fields into likes a couple of years ago).

As someone who dropped out of college to join a "startup," I can reliably say that I didn't have enough information at the time to make an informed decision about what I did or didn't need to know.

I'm happy with how my career has gone since then, but it would be absolute hubris to declare that it was due to my astounding foresight or careful assessment. I was a) motivated b) lucky and c) relatively free of responsibility.

Maybe I've had a more skewed career than most, but I've spent my career working with complex and busy systems. I never had a "freelance web developer" period. I've never just spat out web app after web app for clients. To take your specific example, I missed out on a chunk of algorithmic complexity in college (which I have since picked up) that sheds light on real world problems that might otherwise seem confusing or unconnected.

I understand your frustration, believe me, but be careful not to mix up the knowledge with the institution, or the message with the messenger, as it were.

Alternative export tool, doesn't require login, open source and can be trivially rehosted by anyone if the traffic overwhelms:

Source: https://github.com/duggan/instazip

"Demo" (aka, you can use this unless traffic kills it): http://instazip.orchestra.io/

Caveats: bit buggy, running on a free Orchestra plan, wants a very recent browser to run.

PRs obviously welcome/sought.

> I expect that even if the gyros stop while you're driving you wouldn't fall over because... well because that's how bikes work.

I don't imagine the dynamics would be the same, after all, you're the gyro on a normal bike. If the vehicle was unloaded and you were going straight, you'd probably be able to keep enough manual balance control to come to a relatively controlled halt deploying the parking struts.

However, I imagine the gyros are going to be compensating for internal imbalance (shopping, baggage) in everyday scenarios, or be travelling around a corner, or in traffic, etc, so you might have less time than you think to regain control before toppling.

I think this misses the point a bit - the "best available language" is an assortment of criteria. If you take away some of those criteria, you're no longer asking the same question.

I think it would be a stretch to suggest that the use of "literally" here was for the sake of hyperbole. It seems pretty clear that it's intended as an analogy.

Interesting videos though, didn't realize I'd stepped on another unexploded grammar mine from The War. I really should know better at this stage.

“BGP is literally the glue of the Internet” - I think you’ll find BGP is figuratively the glue of the Internet ;)

I'm still looking forward to Minority Report style interfaces for the desktop, like https://leapmotion.com/

Probably not the best model for mobile interaction, but there's plenty of seats free at the man-machine interface table.

Here is an incredibly lengthly argument which tries to be more balanced: http://rossduggan.ie/blog/infrastructure/cloud-vs-metal-infr...

Jeff is glossing over a lot.

If you're already massively invested in hardware, in terms of people, processes and hardware, then you could argue that cloud architecture is less valuable in the general case, otherwise, it's usually no contest.

And yet all of these seemingly negative results arguably drove the development of more interactive web interfaces, rekindled a broader interest in Javascript, eventually resulting in better libraries and, ultimately, things like Node.js being possible.

  > spend a month moving our framework over to Go

Seems a little extreme. Just use it for small, discrete projects. No need to bet the farm.

There's some serious miscommunication going on every time this discussion comes up.

A lot of people seem to conflate all data abstractions with the term "ORM" (which has a very specific meaning), therefore assuming everyone who thinks ORMs are a bad idea are arguing against all forms of data abstraction.

This is not the case.

One of the better articles on this: http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern

Personally, one of my favourite discussions is Laurie Voss' "ORM is an anti-pattern": http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern

For a european perspective; a company I used to work for was in this situation many times over. We worked with law enforcement and the data protection commission to ensure zero "pollution" of unrelated information into legal requirements (like subpoenas).

If you end up being contacted by law enforcement for data, I'd recommend doing everything you can to help educate them about the information you carry. It might be tempting to volunteer as little as possible, but you also might be the first willing and knowledgeable technical person they've spoken to in some time, and starting a relationship like that on a good foot can be incredibly useful to your company; maybe even you personally.

It can mean future requirements get handled without hassle, and may never even come to you at all if they know it's information you don't or can't carry. You can also help shape policy around how such things are handled for others in future.

YMMV depending on jurisdiction, but it's worth considering contacts from law enforcement as an opportunity to build a healthy (two way) relationship.

Thanks, John!

Suggestion / Question: the "suggested users" list disappeared after my first follow, so discovery has become a little tricky.

Does it exist elsewhere? If not, might be a good idea to put it back in.

That was a lovely read, thank you.

I think a lot of the comments are going to focus on how to make "more toys, better toys", and maybe that's inevitable given the audience, but I think that misses the point a little.

All children need is a prop and imagination; the more vague the prop the more things it can be. Realistic toys are, frankly, an adult obsession, because they will always fall flat in the face of what a child's mind can conjure up.

Dear me, how patronizing.

The reason, by the way, that leadership is often correlated with extroversion is more to do with American ideals of the perfect citizen since about the time of Dale Carnegie than due to any actual results.

In fact many successful CEOs are introverts, because deep critical thinking and mediation tend to be useful qualities, surprisingly enough.

Not in finance though. And the world of finance has had a smooth ride, alright.

A few other commenters have suggested that they don't get a chance to get past "First, make it possible." to making things beautiful, then fast. The person writing the checks doesn't care if the implementation is horrible, as long as it works, etc.

Thing is, both points of view are correct, in different ways.

The kind of long development cycle Nathan alludes to here is not something a lot of people can do, but is one of the risks you can take / benefits you gain if you're your own boss. I wonder if it's more common in larger companies, who can afford to polish some projects before putting them into production? With a startup, it's more likely that there's one or two projects, and both are P1-CRITICAL.

For people wanting to explain it to a boss, I think it's best put in terms of technical debt[1]. This project will be expensive, but by spending more time/resources up front, there is a much lower cost to adding features or fixing bugs in the future; this includes getting new coders up to speed on the codebase, turnaround of critical features, etc. The cost is initial time to market - it will be longer before you see version 1 going out to people who can use it.

Taking on technical debt is a perfectly valid business decision under the right circumstances. If time-to-market is critical and you're planning on having enough money when it's successful to pay off that debt in the future, then maybe you want to throw out making it beautiful / performant just to get something in front of people.

Planned technical debt is a business decision. It's the folks who buy up front and ignore their debt that end up with problems, but that much is something we're all familiar with. One way or the other, that debt is paid eventually, whether with cash or time.

Even if you're in the unfortunate position of turning out software that sucks for people who don't care though, there's light at the end of the tunnel! The best thing about programming is that the more you do it the better you get at it. The faster you get at it. This means you can build refactoring into your projects and estimations without making a big hoo-hah (as it were) about it.

Open source projects are another outlet people have to scratch their perfectionist itch; if you start a project, you decide the timelines, features, level of polish, etc.

[1] http://www.codinghorror.com/blog/2009/02/paying-down-your-te...

This Coder Dojo thing (http://coderdojo.com/) has been slowly growing momentum for a while now, but has recently had a burst of activity, with setups in SF, New York and Boston on the way.

James, at 19, seriously has to be commended for the sheer dedication he's thrown behind this endeavour. Ben has also been behind the scenes for a long time, only 18 himself.

It's inspiring, and humbling, to know these guys are putting all their energy into helping kids learn how to code.

I've no idea what your constraints are, but splitting the index into more manageable chunks, writing to multiple masters and reading from n slaves off each is an approach that has worked quite well for me (40 million plus records, big lumps of user generated content, total index about 100 GB iirc).

You sacrifice on the accuracy of IDF+, but gain some robustness as result too.

If the BitTorrent approach doesn't work too well, you might consider something similar. I've jotted down a few reading resources for scaling Solr++ but I should probably do a write up of the architecture I built for Boards.ie.

[1] http://wiki.apache.org/solr/DistributedSearch

[2] http://rossduggan.ie/blog/technology/reading-list-for-scalin...

I think for tackling a subset of these problems (well, circumventing them) ZeroMQ is generating a good deal of interest.

http://www.zeromq.org

http://www.zeromq.org/blog:multithreading-magic