Hacker Newsnew | comments | show | ask | jobs | submit | 100k's comments login

Yegge's "It's not software" from 2004 has a nice bit about microservices -- pretty ahead of the hype curve on that one:

> What if every "API call" were hosted by a different server? Well, you'd have a lot of flexibility in fixing any given call without needing to impact clients that don't use it. And it'd be easier to distribute it over multiple machines — it seems like it'd be a better design than the BEA WebLogic design, which is to run a few copies of your MonolithService on each of a handful of machines. There would be new problems to solve, but who's to say it wouldn't be a better design overall? We won't know unless we ask the question.

https://sites.google.com/site/steveyegge2/its-not-software


This looks really nice. The resources linked to are also cool:

http://www.daveliepmann.com/tufte-css/

http://sachsmc.github.io/tufterhandout/


Only if the early engineers could write in a language that they were as productive in as Ruby. Getting Stripe launched was the key thing Stripe needed to accomplish. Everything else follows from that.

-----


There are certainly enough languages to choose from.

-----


Sure there are tons of languages, with different strengths and weaknesses. The part that is important is that the early engineers need to be productive in the language.

Choose boring (to you) technology.

-----


If the technology that's boring to "early engineers" has significantly more weaknesses than the alternatives, then, simply: the wrong people were hired.

-----


Stripe is worth $5 billion. I don't think they hired the wrong people.

-----


Ex post facto justification of complex interdependent decisions and consequences by virtue of market valuation?

That's just dumb survival bias endemic to the YC camp.

It's not something you should actually base business and technical decisions on.

-----


Pretty sure it was a standard list of questions - perhaps emailed.

Still, she is one of my favorite writers so it's interesting to read what she likes reading.

-----


I would like to think it was certainly emailed because I can't imagine a live interviewer getting those kind of answers and continuing in that vein; I really want to assume the only way that could have happened was if there was no real back-and-forth between the interviewer and the interviewed.

-----


It's a standard thing NYT does and it's pretty obvious that the questions are pre-written and sent as a batch.

http://www.nytimes.com/column/by-the-book

-----


More appropriate to call it a questionnaire than an interview.

-----


Alas, what a lazy approach. An opportunity wasted.

-----


I don't think that's fair. It's one of several standard types of interview, and legit in its own right, as long as one doesn't confuse it with the others. It's not like Ursula Le Guin hasn't done plenty of face-to-face interviews too.

-----


> It's one of several standard types of interview

Except it's not actually an interview. Call it a Q&A or something if you like, but "interview" implies back-and-forth conversation.

-----


That's fair enough re my usage of the word, but the article never calls itself an interview, and the point that this is a well-known standard format holds. Let's not dismiss things for shallow reasons.

-----


Sometimes they are. I really like it. I was selected to speak at a Ruby conference with a blind submission process. I remember feeling pretty good when one of the people who was a frequent speaker at Ruby conferences was whining on Twitter that their talk wasn't selected.

-----


It's the future!

http://blog.circleci.com/its-the-future/

-----


Crap like that actually happens. I have a mathematician friend who does a bit of programming ask me about Docker, as someone had told her to use it. She works as a researcher in academia, so probably only needs to run her script a few times to get results. Why the hell would you recommend Docker?

-----


> probably only needs to run her script a few times to get results.

Agreed that she doesn't need to use Docker. But if she is writing a paper on those results, she might want a way to reproduce her findings years down the road (even after she switched Distros), or to collaborate with others who want to reproduce/build on her research (and may not be running her distro).

It's easy to think "oh, this script just requires python 2.7", but most of the time you actually have many more dependencies than that (libxml, graphviz, latex, eggs, etc.) A Dockerfile requires some work to setup, but it tracks your requirements in an automated way.

So I'm not going to say "all researchers should use Docker". But I will say "Docker could be useful to some researchers". Just like Source Control, it's a tool that solves real problems. Source Control has gotten easy enough to use that it's recommended everywhere. Docker (or some other container standard) will get there eventually.

-----


For research apps docker would be a godsend. Resea ch software is of the "install exactly this version of x,y,z,r,g and h" and then apply these patches....

Docker is really good for dev environments. I've had a relatively painless time dockerizing snapshots of old internal web apps so I can hack on them without installing things into my main desktop environment. It lets me have lots of server things side by side.

-----


I liked looking through my parents' photos as a kid, but there was a couple of photo books at most. I can't imagine my (hypothetical) grandkids sorting through 60 years worth of digital photos unless software has gotten a lot better.

The busy work and stress of dealing with digital photos has actually caused me to take fewer photos. I have a preservationist bent and I just don't want to deal with organizing them.

-----


that's the sad part - few photos available made each of them worthy inspection, bringing memories etc.

now, having 100 GB of photos & videos from somebody's childhood will either produce ignorance of whole content (no, nobody will ever want to go through all of them, guaranteed, and if yet they would hate it), or some automated way (yet to be invented) to take out best maybe 100-200.

By not selecting few good worthy now, you're just pushing the decision into the future, to your/somebody else's shoulders.

-----


Perhaps folks working at also-ran startups are not there because they are bad at picking but bad at getting hired[1] at more successful companies.

[1] This doesn't mean they're bad -- they could have trouble interviewing, or be subject to conscious or unconscious discrimination.

-----


The rest of the site is a helpful database of tech companies considered to be "breaking out" which would look good on your resume/teach you a lot/maybe make you some money.

-----


Very interesting!

Direct link: http://www.cosmographica.com/spaceart/pluto-predicted.html

-----

More

Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: