Top 5 Acronyms You Must Know - <AUTHOR> https://medium.com/@LYKAPP/top-5-acronyms-you-must-know-24c6ba129344 <comment><USER2> TPIASWOT: This piece is a stupid waste of time.</comment>


Appic.Video: Share and sell videos just like Netflix - <AUTHOR> https://www.appic.video/ <comment><AUTHOR> Inspired by popular video streaming services such as Netflix, YouTube and Vimeo we carefully designed and developed Appic.Video to help you share and sell videos online. Thus reinventing how businesses can interact with their customers and earn money.

<comment><USER2> Looks nice. I'll check it out. Thanks.</comment></comment>


Piled Bodies, Overflowing Morgues: Inside America's Autopsy Crisis - <AUTHOR> https://www.nytimes.com/2020/02/25/magazine/piled-bodies-overflowing-morgues-inside-americas-autopsy-crisis.html <comment><USER2> > Most medical schools do not promote or discuss forensic pathology as a > possible career path. Last year, only 44 out of 24,399 active residents in > subspecialty programs in the U.S. undertook forensic-pathology training. > "It wasn't even an option in medical school," Todd Barr, a forensic > pathologist working under Gilson in Cleveland, told me. "Pathology was > barely even taught. I think I had a forensic mind already, back then, but > nobody ever said, 'Hey, you ought to think about forensics.' And I wish they > had." It took him 13 years of practicing medicine to find his calling in > forensics, because he never knew about it.

44 out of 24,399 is...quite something.

<comment><USER3> I was fortunate to have Michael Baden as one of our professors at Columbia. His lectures were extremely entertaining and packed to the rafters. Even with his showmanship, I don't believe anyone in my class went on to forensic pathology.</comment></comment>


Be progressive - <AUTHOR> https://adactio.com/journal/7706

<comment><USER2> Like Jeremy, I wish there was an easier, more convenient way to use progressive enhancement. I think the front-end MVCs are an interesting way to get websites developed today but it'd be great to see isomorphic javascript go somewhere if it does.

<comment><USER2> [http://radar.oreilly.com/2014/10/isomorphic-javascript- with-...](http://radar.oreilly.com/2014/10/isomorphic-javascript-with- lazojs.html)</comment></comment>


Debops (2014) - <AUTHOR> http://enricozini.org/2014/debian/debops/ <comment><USER3> I like this a lot, and I love the term DebOps.

The way developers somehow think DevOps is (or should be) an abbreviation of "Developers doing/replacing Operations" is terrifying to me.

I'm also in the same boat as the author, in that I recommend and target Debian Stable + Backports (and some vendor/community repos when required).

<comment><USER4> A bit over a year ago I researched what "Devops" means, and the answer seemed to be Developers being able to push code to production without having to involve Operations. This sounds like a good goal to have (presuming you've got good unittests etc.) as it removes an unnecessary friction for developers.

What it doesn't include is all the higher-value work the people on the Operational side tend to provide, like thinking about rollbacks, machine failure, network failure, provisioning, capacity planning, change/configuration management, security, monitoring etc - which is not to say that all developers don't think about these things, their focus tends to be on developing product rather than these non-functional requirements.

I'm presently in a world of Ubuntu LTS+a few manual backports for similar reasons as the authors. My home systems are ansible managed, giving me things like wireshark installed everywhere if I need it and new machines automatically hooked into Prometheus monitoring (which is much easier with my debs). I've seen what happens if you try to manually manage machines, and know that a small bit of upfront work will bring dividends later.

Writing the core code is just one critical step in running software long term, let's not forget the rest of the critical steps to keep it running in a sane way in the future.

<comment><USER3> Many people have different interpretations of the term 'DevOps', but what you're describing in that first paragraph is Continuous Deployment.

Yes, it's related to (in that it's often a beneficial result of) but it's not explicitly the same as DevOps, by any definition I've seen, good or bad.

<comment><USER4> Among all the definitions I found, that was the only common theme.

I've been discussing this with others in the "DevOps" space and in recruiting terms a "DevOps engineer" seems to mostly mean an "Ops engineer". True Devops (in the sense of developers who also care about and perform all of their own operations) is a culture, not a job role and one that seems quite rare in the wild.

<comment><USER5> Definitions of the term are almost as diluted as "cloud" is. It is easier to define it as what it's not.

Look up Jez Humble for a bit more idea into the origins of the term. The term is a primarily a buzzword among larger companies and almost always followed up by some engineering cultural change objective rather than about how code is deployed or even developed and run. You know that it's another management- focused trend when there's entire conferences where people say devops constantly without mentioning anything about code and half the folks in attendance or speaking are consultants in suits that consider Excel formulas the extent of their coding skills.

So the common theme I see is "any way besides what we used to do operations traditionally." It's mostly used for "operations with some idea of what is being deployed on the stack above them." Most start-ups don't have this problem at all with modern infrastructure (no more rack and stack at your 5-man start-up probably) though by definition because rigidly defined roles are a Big Company Problem.

<comment><USER3> The problem modern startups have is that a developer sees he can make calls to AWS or Azure APIs and assumes that makes him qualified to define system architecture, security policies, deployment processes, etc.

"Modern" infrastructure (by which I assume you mean provisioned, destroyable VPS instances + associated services such as AWS, Azure, etc) is effectively just a new "how" \- you call an API instead of deploying a config file or similar. You still need to know the "what" and the "why" to be effective.

<comment><USER5> I don't necessarily see the situation as inflated egos as much as lack of resources to do it better. I have rarely met developers that are excited to do operations work like defining and implementing system security policies, change control, and orchestration. It's a chore that's as exciting for them as doing their laundry.

I'm being very conservative with what "modern" means (within the past 20 years is about right). Traditional shops are still racking and stacking machines and maybe deploying VMs by hand using ITIL stuff trying desperately to slow down system changes to deal with demand rather than to speed things up like most shops have done. Where I am now, the "traditional" IT side of the house takes roughly 5 months to provision a new server (I lead operations on anything bleeding edge, which is now standard for most start-ups).

Going from using maybe kickstart files to API calls is not as big of a deal as the fact that you can even get something on demand in any way instead of going, finding another job, quitting that job, coming back in shame, and realizing that the server you asked for is finally up.

<comment><USER3> I've definitely met developers who made the choice to say "I can do this myself, I don't need someone else to do it", and I've also met developers who when tasked with "make our app run" simply say "ok, its running on port 80, so it's up right?" without any of the associated work to make it secure, reliable, backed up, etc.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> I recently had to develop an Erlang application targeting Debian "stable". It was humiliating at best. Countless hour were wasted trying to get around bugs in prehistoric packages, or building new (and working) packages from scratch.

Never again.

<comment><USER7> Live dangerously: deploy on Arch. Then you'll never have to work with outdated anything again ;)

Actually, although I've been using Arch Linux for over two years now (not in production; I'm not brave enough), I've hardly had any issues at all with its rolling updates. The worst was just having to manually delete some Java binaries from /usr/bin when the way it handled Java was updated to allow Java 7 and 8 to exist side by side.

<comment><USER8> I know a lot of people who use Arch. I myself used Arch for about 10 years. Everyone I talk to has glowing reviews of it, and they've never had any issues.

I stopped using Arch about 3 years ago after my system became unbootable after an update. It was no the first time. In the past, I would be fine reading update notes and fixing the issue. But since I started troubleshooting servers at work, I have _zero_ patience for doing it at home.

One other annoyance that comes with rolling releases is that you should update more often, to avoid making bigger (sometimes conflicting) changes to your system. You end up reading release notes more often. I could turn on automatic updates, but I've been bitten by that in the past.

Arch also encouraged me to tinker, and I was much more likely to make breaking changes to my system than I am now just running Ubuntu. If I had the time/energy to try out new distros at home, I would probably try Nix or something similar, that emphasizes rollback capability.

</comment></comment></comment><comment><USER9> There's also DebOps[0], a collection of ansible playbooks a " Debian-based data center in a box".

[0][https://github.com/debops/debops](https://github.com/debops/debops)

<comment><USER10> I remember going over with the author on what we should name the domain[0]. I figured it was pretty unique.

[0][http://debops.org](http://debops.org)

</comment></comment><comment><USER11> How do you not bundle in dependencies when coding in, say, Java ? The Java packages on Debian are for the most part outdated. It's way more practical to just use Maven, build a fat jar and be done with it.

<comment><USER12> How do you not bundle dependencies programming in anything? If you want to be portable across Linuxes, you can't even count on tcsh or env being installed at the same path. Counting on the stuff installed with the system unleashes a world of pain on the user.

<comment><USER13> >you can't even count on tcsh or env being installed at the same path

This is what tools like Autoconf and pkg-config take care of. Lots of people use them to discover executables and libraries and generate files with the right machine-specific variables in them. You should _never_ assume that binaries are in /usr/bin or that libraries are in /usr/lib. A lot of packaging issues are caused by such assumptions.

If you use the right tools, you don't have to bundle your dependencies. Bundling introduces a serious maintenance burden onto the developers _and_ the packagers. It's easy to avoid bundling for C libraries and things, but with the prevalence of language-specific package managers, it's become a harder problem because everyone just assumes that you will fetch dependencies through it and never use the system package manager. It's a sad state.

</comment></comment></comment><comment><USER14> > I build my software targeting Debian Stable + Backports. At FOSDEM I noticed > that some people consider it uncool. I was perplexed.

I am also perplexed... what are these other people doing?

<comment><AUTHOR> They are doing stuff like this:

[https://news.ycombinator.com/item?id=9952356](https://news.ycombinator.com/item?id=9952356)

<comment><AUTHOR> To the downvoters: the comments on that post mention a lot of deployment methods that people not doing Debops are using.

</comment></comment></comment><comment><USER15> So I develop PHP. The reason I don't use Debian stable is because the latest version of PHP on there is 5.4.41, which is behind the "old stable version". That means security fixes only.

No bug fixes that resolve problems, or modern functionality (that release is over a year old), and will be EOLd in 1 month. That means a big delta of change that will be needed to handled when debian finally does get round to upgrading. Large deltas of change mean lots of risk.

It's much better to stay further up the crest of the wave and handle more regular updates, to minimise the size of the risk I'm bringing into my code at each release, than it is to stick to an old version and not handle the stream of new functionality that's coming in as it arrives.

<comment><USER16> Debian Stable has 5.6.9 at the moment, [https://packages.debian.org/jessie/php5](https://packages.debian.org/jessie/php5) \- and shipped with 5.6.7 initially.

Security updates for php5 in Debian seem to have changed from backporting security fixes to staying up to date on any given upstream minor branch, including other fixes. [https://security-tracker.debian.org/tracker/source- package/p...](https://security-tracker.debian.org/tracker/source-package/php5)

<comment><USER15> Gah, well there's that argument out the window. We tend to use docker on CoreOS here, so it's not much of an issue.

Maybe next time I stand up a real VM I'll look at using Debian stable then.

</comment></comment></comment><comment><USER17> Never understood why debian ended as the distribution of choice of the DevOps- related movements. Ubuntu is understandable - developers used it on their desktops so when they orderer their first VPS, they chose ubuntu. But why debian?

Also why it looks like RHEL family is completely out of fashion? Is it considered too "enterprisy"?

<comment><USER18> Why Ubuntu? If you're not writing GUIs, Ubuntu is just a less-stable Debian.

<comment><USER19> > Why Ubuntu?

PPAs.

<comment><USER20> PPA's are a seriously killer feature. Easily one of the most important parts of the Ubuntu ecosystem. Not enough people realize it.

<comment><AUTHOR> What is the killer part of PPAs? It is pretty easy to setup your own repo on a server using reprepro or aptly. Is it the build-machines-as-a-service aspect? Or the ease of adding a PPA to your system? Or the fact anyone can dump some stuff into a repo and have Launchpad/Canonical/Ubuntu bless them?

<comment><USER21> I think it's the part of having bleeding edge packages easily linked into your system. Other options might be available but people simply don't know about it. And developers themselves might already provide the PPAs which means there are many PPAs available.

Might be the worst solution but is the most well known.

</comment></comment></comment></comment></comment></comment><comment><USER22> Using Debian isn't a panacea. Neither is any particular distribution. Anecdotally, the only personal server I've had hacked was running Debian - <USER2> to it using an old openssh version (the issue was not present in later versions). It was fixed quickly, but I got 0dayed.

<comment><USER3> The only server's I've seen (and subsequently replaced, with Debian) breached were old CentOS boxes.

The key thing here is not "Debian is bad" or "CentOS is bad" it's that you need to keep up to date with security patches. For Debian that usually means a combination of using the Security Apt repo, and for things like OpenSSH, using the Backports Apt repo.

I do agree that Debian isn't a silver bullet, but in my experience it's much easier to work with from a setup/management point of view than CentOS, particularly for small shops that are't heavily invested in a full-blown CM tool - shell scripts and/or Debian config packages [1] can be used to fully provision one server or fifty.

[1] [http://debathena.mit.edu/config- packages/](http://debathena.mit.edu/config-packages/)

</comment></comment><comment><USER23> Related to this: Outsourcing your webapp maintenance to Debian

[https://feeding.cloud.geek.nz/posts/outsourcing-webapp- maint...](https://feeding.cloud.geek.nz/posts/outsourcing-webapp-maintenance- to-debian/)

</comment><comment><USER24> Yes, working smart not hard.

The value of going home on time each night, because there is a wealth of google searches to expose and workaround known bugs should never be underestimates.

</comment><comment><USER25> Please edit title with (2014)

</comment><comment><USER26> Am I the only one who finds this style of usually-just-one-sentence-per- paragraph almost completely unreadable on a visual level?</comment>


Ask HN:  Feedback Please - TapInko.com - <AUTHOR> http://www.tapinko.com

<comment><USER2> It says I can't see go to the webpage because I'm not using a supported browser. I'm using Firefox 3 on linux. However, I can see the webpage if javascript is off, but not much is there.

<comment><AUTHOR> We will enhance the site as we continue to move forward, thank you for pointing this out.

<comment><USER3> If you get errors reported like this to your customer support, try answering with a more personable response. The way you phrased this comes off as dismissive and doesn't specifically address the issue reported.

<comment><USER4> Would you have preferred "You use a niche browser on a niche operating system which our analytics indicates less than 1 out of 10,000 visitors use, accordingly, we're spending our engineering resources elsewhere and I would not expect resolution of this anytime soon. Toodles"?

<comment><USER3> Actually, yes. That's way more personable and less canned. I also said, "if you get emails _like_ this" meaning similar in nature, not necessarily subject matter.

</comment></comment></comment></comment></comment><comment><USER5> Nice idea. Reasonable implementation. Ugly design.

Poor colour choices, inconsistent fonts and poor and inconsistent layout decisions preclude it from looking professional. It all feels a bit 90s and clunky, frankly, and would put me off using your site.

Grey buttons in the top-right look incredibly tacky and don't match the rest of the site. The entire black-to-grey gradient strikes me as a bad idea, especially as white-on-black text isn't something business websites generally do. Navigation and how people use the site is generally poorly thought out (although the map is decent enough), and relies too much on clunky search functionality with poor usability, especially when you have so little content. The use of overflow: auto for the results instead of letting it go down the page is a poor design decision and that, combined with the "register" popup, reminds me of a spam site rather than a legitimate company. I'd have a serious rethink about most aspects of the design, with a combination of looks and usability in mind.

As others have commented, using browser sniffing to block access to your site is extremely bad form, not least for the simple reason that you'll never be able to keep up with browser variations and end up with annoyed users. I remember the problems it caused 10 years ago with the browser wars. Get rid of it, support the 5 major browsers and assume that everything else is out of your hands.

When you visit the site, you've got a lot of space going "Advertising made easy", "The advertising marketplace" and even "Register Today!" text, but what you really need is a box summarising exactly what your service actually does rather than using vague slogans. The fact I had to click through to understand fully the purpose of the site is a bad sign.

</comment><comment><USER6> I've bought a lot of advertising over the years and would use a site like this.

Homepage has too much nagging to register without a clear value proposition or explanation of the site's purpose. It isn't clear what the service is from the overly broad homepage taglines: "Advertising Made Easy" and "The Advertising Marketplace". (The domain name doesn't convey either but it is brandable). I'd tighten that tagline into something more specific and compelling.

You might want to start by focusing on a specific geographic market (i.e. Philly) or vertical (i.e. political ads) or type of advertising (i.e. print) or even just college papers and expand from there. (I bet a lot of consumer product companies would advertise in college papers if it was easier to do) Newspaper or radio remainders would be good now that Google is exiting.

The calenders don't work in FF 3. Also, white text on a black background is tough to read and is unprofessional to me. The FAQ page javascript is an annoying and unneeded interface.

Happy hunting and let us know how it goes!

<comment><AUTHOR> Thanks, your feedback was great. Please check back when you need to place/sell ad space and let me know if you have any further questions, comments, or concerns.

</comment></comment><comment><USER7> This is a really timely product given the recent discontinuation of Google Print Ads system. Nice effort.

My only recommendation: I'd like to see what the My Inko control panel will look like before I decide to sign up for an account.

<comment><AUTHOR> Sure... We built MyInko to be extremely easy and intuitive... my suggestion is to create an account and go ahead and click on MyInko... there is a video you can watch in the very bottom of the Inventory screen... but the other tabs are equally as easy to navigate. Thanks again.

</comment></comment><comment><USER8> I was a little confused when I first arrived on your site. All of the different words and taglines danced around what it is you really do. It says "Advertise Here," "Advertising Made Easy," "The Advertising Marketplace," etc. The big map could have been from any number of businesses.

Since this is the internet and advertising is everywhere, seeing the words "advertisement" don't really tell me anything. Is it online? Print? Billboards? Your home page doesn't say.

You need to make it extremely clear what you're selling and to whom--something like "Buy Real-world ads online."

<comment><AUTHOR> Do you like the saying: "Advertising Off-line"?

<comment><USER8> You might combine that with your current tagline to make this: "Offline Ads Made Easy." You still need to imply that you're letting people buy something or making the buying process simpler.

If you settle on a tagline you might think about using some imagery that represents what you do -- college newspapers, billboards, restaurant menus, etc.

A picture may not be worth a thousand words but it can usually replace a paragraph . . .

<comment><AUTHOR> Thanks Gavin... great advice.

</comment></comment></comment></comment><comment><USER9> Holy crap, that is an excellent idea.

Poking around a bit, my only suggestion so far is to make the text font size bigger on some of the text-heavy pages (FAQ) and make the line lengths shorter. Lines of text should be around 65 characters long.

<comment><AUTHOR> Thanks Natch, let me know if you would like to watch one of our interactive product demos

</comment></comment><comment><USER10> If I wanted to advertise in the US, I would probably use this to get ideas on what kind of ad spaces are available and what their ceiling prices are. Then I would call them and try to negotiate. In my limited magazine advertising experiences I've found that list prices can be a multiple of what you'll get after a bit of haggling.

<comment><AUTHOR> It is no secret in the industry that the prices listed are NOT the prices agreed upon.

We have taken this into consideration and you can use the messaging tools of TapInko to 'haggle'. Have a look, let me know your thoughts.

The goal really was to keep it easy.

</comment></comment><comment><USER11> <http://browsershots.org/> may prove helpful to see how others using all the various web browsers are viewing Tapinko.

<comment><AUTHOR> Great site Ryan... thanks.

</comment></comment><comment><USER12> You've done a good job with simple layout on the main page, but I had no idea what you were all about when I first hit the page. Your titles say "advertising marketplace" and "advertising made easy". I suspect that most people visiting a website are accustomed to think online advertising. But you are focused on print. So why don't you actually say 'print' advertising anywhere on the main page.

That is my biggest complaint. I have no idea what this is all about unless I dig deeper (which most people won't do).

<comment><USER13> I had the same experience. The first page you see doesn't explain what it's all about except to say advertising and to show a map of the US. From that I immediately think it's about geo targeted online ads.

</comment></comment><comment><USER14> You may want to photoshop the foot of 4th dude out:

<http://www.tapinko.com/images/thedudes.jpg>

:)

<comment><AUTHOR> Good eye...

</comment></comment><comment><USER15> Good concept, and an impressive, if glitchy implementation. When I switched tabs in my browser and came back later, it reloaded the home page, rather than displaying where I left off.

Also, you misspelled "Worcester" in the description of "The Towers" at Worcester Polytechnic Institute in Massachusetts.

</comment><comment><USER16> "Select a state or search below to advertise:" Where do I select a state? Typing NE in the giant search box didn't yield Nebraska search results, however I then spotted the state drop down (not on the home page!)

"Search returned 1 results:" takes up a TON of screen real estate relative to the total area allocated for search results. Using the back button breaks search results filtering (at least state-based) - look at how Mint elegantly handles this use case.

Something about the spacing or presentation of the search results is irritating to me but I can't put my finger on what. The resulting pricing pages, by contrast, are quite nice and present the information in a coherent way.

</comment><comment><USER17> The UI is kindof cramped.

When I see the screen there isn't any statement containing information about the site. I see the info in the browser's title but not on the page.

The page doesn't fit in a 1024x786 monitor. Site gets an F(37) in yslow (too many files). Not a big fan of inner scrollbars when clicking on a state, it would be better to utilize the browser window's scrollbars. No easy way to go back to the map unless I click home again.

The login bar clutters up the screen. Might be better as a popup dialog.

<comment><AUTHOR> Thanks for the feedback... this is great advice.

</comment></comment><comment><USER18> FireFox on Debian (IceWeasel) is not recognized as FF3 and I'm being asked to upgrade.

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:188.8.131.52) Gecko/2008122010 Iceweasel/3.0.6 (Debian-3.0.6-1)

<comment><AUTHOR> Sorry, we will open up the platform soon. Bug checking and time have limited the site for right now, but thank you for pointing these out.

<comment><USER19> If some of us using an older browser is going to break stuff serverside then I think you've probably got some _major_ issues to work through.

Howabout a "No, thanks. I'll risk it. LEMME IN!" button?

</comment></comment></comment><comment><USER20> Your UI needs a little work.

The results to be specific, they don't tell me much without reading for more than 10 seconds, try showing ad rates, available slots, etc.

<comment><AUTHOR> So give a little break down in each search window.... but do you think a more interactive and sophisticated search would help here? I was thinking of allowing users to target specific outlets based on the markets they desire to capture.

</comment></comment><comment><USER21> Awesome Idea.

<comment><AUTHOR> Thanks. Interested in trying it out? I think you might see us help your drinkingfor.com venture.

</comment></comment><comment><USER22> Being asked to upgrade from FF3 B4 Pre. Fail.

</comment><comment><USER23> I wish I could access the site with Konqueror. But it redirects the browser forcibly to `please upgrade your browser to' page.

You could at least give some way to ACK the message and go ahead anyway, without fiddling with user agent settings.

</comment><comment><USER24> Good idea, but the site is a bit busted. The registration lightbox wasn't dismissed after I signed up.

It would be nice to be able to easily compare the rate cards of different publications.

<comment><AUTHOR> Hmmm thanks Jim... it's definitely supposed to close after you register.

</comment></comment><comment><USER25> Not sure what the name means. Kinda odd.

I looked in my area (Ohio) and you seem to have multiple listings for the same person. The college newspapers and other local rags are a great idea.

<comment><AUTHOR> Hey Matt, those different listings are the same person but different advertising opportunities and outlets. The next version of the product will join all the opportunities under individual accounts.

Thanks,

-Pete

<comment><USER25> Ah, that would be helpful.

</comment></comment></comment><comment><USER26> When I search something it says "Want to sell through the TapInko network? Click here."

Since the words are already a blue hyperlink, you can probably leave off "Click here."

</comment><comment><USER27> I'm using Firefox 126.96.36.199, which I don't want to upgrade. So I'm just going to join the others in "Please add the 'Try anyway'" link

</comment><comment><USER26> When I click on "sign in" it does not auto-focus me to the username box.

</comment><comment> cool-RR Screencast not working for me (Firefox 3.0.8)

</comment><comment><USER28> post a username and password so we don't have to sign up?

</comment><comment><AUTHOR> TapInko is the online Market Place for Traditional Media, we were a DreamIt Ventures company last summer and have spent a considerable amount of time understanding the 'offline' advertising world. Though this is the first version of the product, we have many features in the works. I will be giving an online WebEx tutorial this Friday at 3:00 pm (est) and invite anyone to watch. If you are interested please shoot me a message.

Thanks,

\- Pete Groverman - email@example.com

Some things about the venture:

1) We have an executed agreement with The Greater Media Group of Freehold NJ, they have begun creating profiles for their different outlets

2) We are based out of Philadelphia

3) Our goal is to make advertising...easy

4) Buyers of Adspace can use their same account to also become Sellers of Adspace (ie. a restaurant desires to place an advertisement but also sell advertisements in their menus)

5) How We Differentiate from Google Print Ads: <http://www.phillypreneurs.com/2009/02/david_vs_gooliath/>

6) If you have a publication or outlet that you would like to sell advertising on (even as a sticker on the back of your computer) please feel free to make a profile.

7) Business Model: No setup costs, no annual subscription fees, we charge only 7% per completed transaction to the seller. This charge includes all banking fees and credit card costs.

</comment><comment><AUTHOR> If you have any interest in being part of a startup and like the concept, we would love to hear from you as well... definitely trying to build out the team and find some 'A' players.

Thanks,

-Pete</comment>


Saltpack – A modern crypto messaging format - <AUTHOR> https://github.com/keybase/saltpack <comment><USER2> The [https://saltpack.org/](https://saltpack.org/) web-site links to a insightful post about authenticated encryption with associated data (AEAD) and the shortcomings addressed by saltpack: [https://www.imperialviolet.org/2015/05/16/aeads.html](https://www.imperialviolet.org/2015/05/16/aeads.html)

<comment><USER3> The streaming AEAD problem is being solved in [http://age- tool.com/](http://age-tool.com/)

</comment></comment><comment><USER4> Vaguely related for people who want simple secure encryption tools is Age: [https://github.com/FiloSottile/age](https://github.com/FiloSottile/age)

<comment><USER5> How are people handling private keys in age?

I don't really want my private key file just sitting around in plaintext.

One obvious thing to do is to use age to encrypt that file with a passphrase. I had hoped that if you gave age a passphrase encrypt file in place of a plaintext private key file, it would recognize it and ask for the passphrase, but alas, it does not.

So far, the only way I've found to do this without making a temporary copy of the plaintext private key on disk is to use a FIFO. Given a file, "input", encrypted to my public key, a file, "key.dat" containing my age private key encrypted with a passphrase, this decrypts "input" to the file "output":

      $ mkfifo f
      $ age -d -i f input > output &
      $ age -d key.dat > f
      ...age prompts for the key.dat passphrase...

Another approach would be to make and mount a RAM disk, decrypt the public key to that, decrypt input, and then unmount and destroy the RAM disk, but that seems more bother, and also less portable. The FIFO trick should work on any modern Unix or Unix-like system.

This is assuming I even want a key file. Age keys are quit small. Here's a private key it just made for me: "AGE-SECRET- KEY-15KMEW7TZY2T02V33ZM0MPH65CTTGHFY34DP2PDQDXFZGT3JU8GQQ5GDAYU"

That's small enough that I'd be happy to store all my private keys in my password manager, and copy/paste from there when I need one. The FIFO trick can work with that:

      $ age -d -i f input > output &
      $ cat > k
      ...paste in the key...

That echos the private key to the terminal, though, so maybe something like this?

      $ SAVE=$(stty -g)
      $ stty -echo
      $ age -d -i f input > output &
      $ echo "Paste the key, press RETURN, then control-D"
      $ cat > k
      $ stty $SAVE

I suppose that can be turned into a little shell script, so not having direct support for encrypt private key files is not too annoying--at least on Unix and Unix-like systems.

Is there a reasonable way to do this on Windows?

<comment><USER6> process substitution might help you avoid an explicit fifo; it should work for this example but in general handling stdin can be tricky when using process substitutions.

        age -i <(age -d key.dat) -d input > output

if you're using gnu pass to store private keys, you could do something like

        age -i <(pass age-key-personal) -d input > output

</comment></comment></comment><comment><USER7> Not my areas to comment on the technical details, but have things improved since the first time this was on HN [1]?

Seems like some of the choices they made were getting bashed, though I'm not sure the reasons were more than personal preferences.

[1] [https://news.ycombinator.com/item?id=14067003](https://news.ycombinator.com/item?id=14067003)

Edit:typo

</comment><comment><USER8> Finally, some attempt to rebuild the transparent, copypastable, text-based crypto message format. Binary messaging is not a replacement.

Cannot comment on the crypto part yet, but the general idea is excellent, we need this.

<comment><USER9> It's NaCl plus Base62 encoding with a fairly simple framing method, that should be fairly rocksolid as far as crypto goes. Internally it's messagepack with binary data for the internal payload, so that's also pretty good and solid.

<comment><USER10> Every messagepack library I've encountered is optimized for speed and not memory or type safety. That's a bit concerning in a secure messaging format.

<comment><USER9> That shouldn't matter much here, as long as the underlying crypto is fine, baring any very bad exploits in the message pack library, any manipulated message should fail authentication.

<comment><USER10> They memory safety and type safety of the messagepack library do matter I think: as with PGP, there's nothing to stop a bad guy from obtaining your public key and sending you encrypted messages. In fact, distribution of public keys is encouraged.

<comment><USER9> Unlike PGP, this library is interfaced with a FFI interface or you can write your own lib without too much effort. PGP requires understanding it's stdio RPC format. That is the source of some issues related to malicious messages. And of course that PGP doesn't much care where it finds them.

The later very much depends on the email client but the former is less of an issue.

In a worst case using this, you'll be looking at a crash in your client. Code execution is an unlikely issue in Go. The lib doesn't care much about the inside format of the message so that should be a non-issue as well.

I think PGP just gave this sort of messaging format a bad rep because PGP has a bunch of issues related to "being able to cleanly decrypt and encrypt a message".

</comment></comment></comment></comment></comment></comment><comment><USER11> Can anyone security minded comment on how this tool compares to the Scuttlebutt Secure Handshake[1]?

Notably I've been looking at various modern "safe and easy" crypto tools and found Scuttlebutts handshake interesting. Yet, the entire protocol was a bit difficult to use, and left me with the impression that I'd have to write a lot myself in my preferred language (Rust) to get a batteries included experience. And, for good reason, I'm always hesitant to write anything about crypto hah.

... though, now that I'm looking for a Rust salt pack lib, it doesn't seem to exist in Rust either. Humm.

[1]: [https://ssbc.github.io/scuttlebutt-protocol- guide/#handshake](https://ssbc.github.io/scuttlebutt-protocol- guide/#handshake)

</comment><comment><USER12> More interesting details can be found here: [https://saltpack.org/encryption- format-v2](https://saltpack.org/encryption-format-v2)

</comment><comment><USER13> This is excellent! We need more work like this that is standardized and stable.

From the protocol end, I heard good things about noise [1] but I haven't seen acual apps make use of it(Edit: It literaly says "Noise is currently used by WhatsApp, WireGuard, Lightning, and I2P." On their page). I highly encourage the author of saltpack to keep a reference list of projects that make use of saltpack.

[1] [http://noiseprotocol.org/](http://noiseprotocol.org/)

<comment><USER14> Noise is a bit different in that it's mostly for creating DH protocols with a reduced chance of shooting oneself in the foot. Saltpack seems like it's a wrapper for AEAD encryption w/nacl's secretboxes that also does serialization via messagepack? I'm not sure I see the point of a "crypto messaging format" that pastes nacl and messagepack together and calls it a standard.

<comment><USER13> I think they're similar in that as you pointer out they reduce the chance of you shooting yourself in the foot. Perhaps a project using noise for data-in- motion and saltpack for data-at-rest(and before transmission) would involve less foot shooting?

</comment></comment></comment><comment><USER15> How does it compare to age-encryption.org?

<comment><USER16> I believe Age doesn't have the dependency on messagepack.

I do like Saltpack's ASCII armour format better, though.</comment></comment>


An Exploration of Identity - <AUTHOR> http://www.r3cev.com/blog/2017/4/25/an-exploration-of-identity <comment><USER2> This company pivoted from blockchain to "Distributed Ledger Technology". Now it's pivoting to identity? Blockchain companies are snakeoil.</comment>


An Introduction to Java Web Services Programming - <AUTHOR> http://mrbool.com/an-introduction-to-java-web-services-programming/28116

<comment><USER2> Oh, it's about how to make the service/server. I was hoping it went over how to make a _client_ for somebody else's (SOAP/WSDL) service.

Making a client for SOAP is easy -- as long as you and your biz partner are using the same version of the same tool. God, I hate SOAP. Tweaking Axis to work with Visual Studio sucks.

There's a reason startups want to use REST, and leave the bodies of the "enterprise service bus" types out in the dumpster in the back parking lot :-)

</comment><comment><USER3> JEE 6 helps a lot in make code cleaner and with less boilerplate.

</comment><comment><USER4> I'm assuming this was posted as a joke, because the HN crowd is pretty anti- Java.

You can, of course, take easier approaches. With RESTEasy, for instance, you add a single line of configuration to web.xml then add the desired annotations to your POJOs and you are in business.

<comment><USER5> i am not anti-java. not at all. but to be honest, creating this simple web service shows really how complicated some things are in java.

<comment><USER4> Yes, when you go this route, it's very complicated. But good, user friendly frameworks have been built on top of these foundations, and those should be used.</comment></comment></comment>


Average faces are not more attractive. Their skin is just smoother - <AUTHOR> http://www.uni-regensburg.de/Fakultaeten/phil_Fak_II/Psychologie/Psy_II/beautycheck/english/schemaanpassungen/schemaanpassungen.htm

<comment><USER2> This is a good example of the type of scientific caveats you need to worry about when you run an experiment. Chances are, your experiment will tell you something, but it won't tell you the full story, and if you drill down further you'll discover something else that's more accurate but probably a less sensational headline.

<comment><USER3> The essence of the problem is in the _generalizing of the conclusion_. The experiment will rigorously demonstrate something utterly abstract and then the experimenter will make huge intuitive leaps when interpreting the results.

I have found this to be the most overwhelmingly common flaw with experiments reported by mainstream journalism, particularly those in the field of psychology.

<comment><USER4> _The experiment will rigorously demonstrate something utterly abstract_

Actually, the "average faces are more beautiful" claim hung up on something _very specific_ (skin tone). I think it's _small_ details that aren't controlled for that often invalidate the more abstract conclusion of psychology experiments.

</comment></comment></comment><comment><USER5> [http://www.uni- regensburg.de/Fakultaeten/phil_Fak_II/Psychol...](http://www.uni- regensburg.de/Fakultaeten/phil_Fak_II/Psychologie/Psy_II/beautycheck/english/schemaanpassungen/m\(1-4\)-g_an_m\(1-32\)-s.jpg) [http://www.uni- regensburg.de/Fakultaeten/phil_Fak_II/Psychol...](http://www.uni- regensburg.de/Fakultaeten/phil_Fak_II/Psychologie/Psy_II/beautycheck/english/schemaanpassungen/m\(1-4\)-s_an_m\(1-32\)-g.jpg)

I don't think you can make this observation from these two faces. There appear to be differences in terms of hair and eye color as well. Plus, the facial hair isn't as visible in the smoothed-out face. I may be being pedantic in pointing the second point out, but I still think it says that there's more involved here than just the skin.

Not to mention that the skin color appears to me to "dull" some of the sharper features of the face by making them less noticeable. I think a case can be made that skin can have an enhancing effect on an average face, but I don't think this is enough to write facial structure out altogether.

<comment><USER6> yeah, well does "attractiveness" of a 2d picture of a face that looks like it was computer generated (the second male picture) as compared to an actual person's face actually correlate to physical attraction in the real world? I don't think you're being overly pedantic.

</comment></comment><comment><USER7> The confusion is due to different interpretation of "average". They should have used _median_ faces instead of _mean_ faces.

Ba-da-bum.

<comment><USER8> Mode faces: <http://dkpresents.files.wordpress.com/2009/07/2ur9h61.jpg></comment></comment>


South Korea's Simple Way to Indicate Vacant Parking Lots - <AUTHOR> http://www.youtube.com/watch?v=nw9g9OVHdJI

<comment><USER2> Save oil by using another precious resource: helium.

</comment><comment><USER3> I like the simplicity of it.</comment>


Ask HN: Bitcoin Price Speculation - <AUTHOR>

Bitcoin is currently trading below $300. Where do you guys think it will be 6 months from now?<p>P.S. Can someone with enough karma set this up as a poll? I would love to get an HN consensus on this. <comment><USER2> Bitcoin's price is mostly backed by speculation, if there is bad news or a lack of 'faith' it will go down, if there is good news and faith is restored the price will go up. The organic bitcoin economy hasn't dramatically improved from my impressions, I would love to use bitcoin, personally, but there lacks ad networks (for generic audiences) or payment processors (for credit cards) which pay in it which means I can't keep every aspect of the webmaster payment cycle within bitcoins so I continue to use fiat. However, finding server providers and domain registrars who accept bitcoin is very easy.

<comment><USER3> > Bitcoin's price is mostly backed by speculation

Bitcoin's price is 100% backed by speculation.

Bitcoins are worthless. They are worth $0. They are useless hashes. Their value is $0, and their price is destined to be closer to that than its current $265.

This scam has been over for over a year. The hucksters who created this fraud bailed out for the most part once they hyped the price up to over $1000 in November 2013.

People are still suckered into the Nigerian scam, and are also still suckered into _this_ scam, for reasons unknown to me. The creator, "Satoshi Nakamoto" turns out not to be a real person. Mt. Gox is busted for fraud. The main ASIC makers, Butterfly Labs, are busted for fraud. The coins have no value. What signals do people need to realize to not spend their hard-earned cash on these worthless hashes?

Of course, some high faluting types in Silicon Valley have put their imprimatur on Bitcoins. But they did the same thing to Pets.com, Flooz and other worthless dot-bombs 15 years ago. Just like major banks and Wall Street peddled worthless subprime real estate and mortgages 8 years ago. Caveat empor, before you trade your cash for a Bitcoin hash, ask yourself, cui bono?

<comment><USER4> How did it get value to begin with? Can you explain that mechanism? Someone had to be the first to put their money into it.

All fiat currencies are driven by the speculation that someone may want to trade with you in the future. They are useless 'pieces of paper'

You seem to think promotion has stopped because it hit $1000? Such an arbitrary figure. It could be much higher if it was adopted further.

<comment><USER5> There are two kinds of people who buy bitcoin - those who genuinely find bitcoin useful in conducting transactions, and those who are trying to make money off the first group.

It turns out bitcoin's rapid price growth was driven by people from group 2, not group 1.

</comment></comment></comment></comment><comment><USER6> I would guess it would be worth anything from $0 to $3000+, with an expected value E(x) of $277 (the current price).

Does that help?

</comment><comment><USER7> According to this video on youtube it's mainly due to bitcoin inflation i.e. mining rewards.

[https://www.youtube.com/watch?v=_-TLA3j-ic4](https://www.youtube.com/watch?v=_-TLA3j-ic4)</comment>


Show HN: HN Recommends – Curated recommendations from Hacker News - <AUTHOR> https://hnrecommends.com <comment><AUTHOR> Over the years, I collected recommendations from various Hacker News users. It's common to see a book, for example, getting recommended again and again and when I noticed a product or service consistently mentioned I would take note. At times, even a single recommendation was strong enough to get me to bookmark it. HN Recommends is my attempt at sharing all the gems I have gathered from the Hacker New community.

More recommendations will be posted soon.</comment>


Study: Brain Objectifies Women As Body Parts, Men As Whole - <AUTHOR> http://stlouis.cbslocal.com/2012/07/26/study-brain-objectifies-women-as-body-parts-men-as-whole/

<comment><USER2> Previous discussion:

<http://news.ycombinator.com/item?id=4292823></comment>


The Global Decline of Religion - <AUTHOR> https://www.foreignaffairs.com/articles/world/2020-08-11/religion-giving-god <comment><USER2> People are filling the religious vacuum with scarier stuff.</comment>


Apple stops Nest product sales in the US - <AUTHOR> http://www.bbc.com/news/technology-33655417

<comment><USER2> This is news only in that it's "news" \- nothing about the decision to do this should surprise anyone. Apple isn't Best Buy - why would they sell a product that doesn't work in their ecosystem. It would be like the Microsoft stores selling controllers for the Playstation.</comment>


Lasers could be used to detect drunk drivers - <AUTHOR> http://www.gizmag.com/laser-detection-drunk-drivers/32388/ <comment><USER2> That would be a game changer.</comment>


Ask HN: Are we approaching another 2008/dotcom boom crisis? - <AUTHOR> <comment><USER2> While the economy is certainly headed for a few rocky months, I think the tech sector will bear it out better than average. They are better equipped and better set up to keep working remotely, less reliant on physical supply chains which are getting disrupted.

That being said, as the total money available in the system goes down, it will impact the demand tech companies have for their products.</comment>


Ask HN: Startup growing, best way to become company? - <AUTHOR>

I am working on an app with some friends / family.  We've all put in some money, split up what our ideal shares would be (i.e. 70/20/10), and after launching our app we're starting to gain some traction.  We would like to become a legal corporation to protect us, and at the same time we need to do what is best for the startup.  How the heck do I figure this out? <comment><USER2> Talk to a corporate attorney who specializes in startups. Setting up a _real_ startup (assuming that's what you want) is a lot more involved than merely setting up a corporation.

</comment><comment><USER3> You don't. You find a good attorney and let them do it.

</comment><comment><USER4> Maybe you should consider to apply at Y Combinator.</comment>


DARPA's Cyber Fast Track: How to get your security idea funded - <AUTHOR> http://rsmudge.wordpress.com/2011/11/09/darpas-cyber-fast-track-my-experience/

<comment><USER2> In case anyone was wondering, the OP's project is titled _A language to control and automate cyber capabilities_.

The other projects are listed in this article: <http://www.networkworld.com/community/node/79135>

\- Rogue Networks: Methods of detecting malicious web server traffic

\- Immunity Federal Services, LLC: Combining expert knowledge and symbolic analysis for detection of exploitable bugs

\- Charlie Miller: Evaluation of Near Field Communication in mobile smartphones

\- Secure Ideas, LLC: MobiSec Live environment mobile testing framework

\- Korelogic, Inc.: Hand held testing

\- Assured Information Security, Inc.: MoRE: measurement of dynamic code

\- Peak Security, Inc. : TinyLANE - Mobile hardware endpoint security for individuals

\- Raphael Mudge: A language to control and automate cyber capabilities

</comment><comment><USER3> I heard various DARPA PMs including Mudge Zatko speak yesterday at DC; looks like DARPA has finally realized that organized government money hoggers aren't doing squat to actually advance the state of the art in cyber defense. I found their policy on funding even offensive research very refreshing.

</comment><comment><USER4> a bit of an odd place(?) to get funded but congrats!

<comment><USER5> It only seems odd because from the outside it's a big, faceless, scary bureaucracy. The Valley and that ecosystem seems that way to most folks outside it, too. There's serious cash to be had from USG and arguably fewer strings than you get on most term sheets.

Once you get past the scary outside, you realize it's normal people on the inside. Submit a proposal and you'll find they're delighted to help you. And they'll give you funding.</comment></comment>


Why you suck at estimating – a lesson in psychology - <AUTHOR> http://blog.muonlab.com/2012/04/12/why-you-suck-at-estimating-a-lesson-in-psychology/

<comment><USER2> The real problem is the impossibility to define the requirements in a way that they can't be misinterpreted.

We (as a industry) tried it with UML and we found out that it is more work than actually writing the code and it was still useless because there isn't a possibility to check for errors.

Because of this, "the developers" and the "managers" need to reach an agreement on a more emotional level where they can trust each other and fill in the gaps with their expertise and experience.

Just keep on trying to document the requirements more detailed, estimating more factually will be a waist of time and it will lead to bureaucracy and mediocre software.

</comment><comment><USER3> Yeah you might be getting burned by these, but even if you are very careful to avoid them, estimating software development in particular is pretty much impossible for anything beyond trivial. The fractal complexity of software means there are often unknown unknowns waiting inside various libraries and architectures that you plan to use. I realize other domains have similar problems (large construction projects come to mind), but to paraphrase Dijkstra, no human endeavour spans a greater scale in orders of magnitude than programming, and it's all just a heap of text with minimal transcription cost!

Given the nature of software, I think that the only sane process is an agile one, where the estimate and scope is under continual refinement as the project develops and becomes better understood. Sometimes business requirements dictate otherwise, but that will always lead to a suboptimal solution.

I think that may be the key reason why I prefer startups to other forms of programming work: in a startup you can not afford to do anything for ceremony or to CYA, the focus on optimizing the product must be relentless.

<comment><USER4> Agree 100%. For those who haven't done Agile estimation before, I strongly recommend Martin's 'Agile Estimation and Planning' book - quick to read and lots of good stuff, in particular:

* Write your requirements as 'User Stories' - discrete units of functionality that are as independent as possible and can be developed and tested as a unit. This gives you maximum feedback on how far along you are against your original scope.

* Estimate complexity, not time. For the reasons this guy gives, people suck at estimating how long something takes. However they are better at estimating how complex something is, particularly relative to other similar things. This means you can estimate each story using 'story points' (an arbitrary measure of complexity, relative to other stories), and then be reasonably confident that two stories rated the same are going to take about as long to write. There is some variation here, of course, but averaged out over all your stories you can get quite accurate results, and usually increasingly-accurate as you go along.

* The people making the estimates should be the ones that are going to be doing the work! Seems obvious, but many places have one person (often a manager or team lead) estimate a task, then have the developers build it, and then the manager gets upset that the developers are 'lazy' (i.e. his estimates were rubbish). As the author says, use planning poker with your development team. This can seem like an Agile kool-aid gimmick to those who haven't used it, but it is a very effective way of getting everyone's input. The best developers are often those less likely to volunteer information in a group setting, and this is a great way of getting their opinions without putting them 'on the spot'.

</comment></comment><comment><USER5> (Really) useful resources on estimating:

\- [http://www.mountaingoatsoftware.com/presentations- estimating...](http://www.mountaingoatsoftware.com/presentations- estimating?page=1)

\- [http://www.mountaingoatsoftware.com/books/1-agile- estimating...](http://www.mountaingoatsoftware.com/books/1-agile-estimating- and-planning)

(I'm not affiliated with Mike Cohn but took his estimating and planning course and must say it's worth the money).

</comment><comment><USER6> I often find that _over-enthusiasm_ for a task can often be a huge factor in getting estimates wrong: over-enthusiasm will lead to the compound effect of underestimating past experiences, over-confidence, and, when your interest wanes, you end up dragging your feet and spending a lot more time doing the gritty, uninteresting parts of the task.

</comment><comment><USER7> The other half of the problem is that management (especially nontechnical "PMP" types) suck at understanding the realities of software development and obsess too much on deadlines and "accountability" when they would do better to focus on removing obstacles for the team or, god-forbid, perhaps jump in and do some of the actual work.

<comment><USER8> Nooooo, please don't let them get involved in the actual work!

EDIT: Maybe I should politely rephrase that: If they're anything like my previous non-technical managers, I'd rather they make the most of their talents elsewhere.

Moving back on topic, the article is worth reading just for the mention of Planning Poker alone. Another moment of enlightenment for me on HN.

</comment></comment><comment><USER9> Wondering whether this article should credit Daniel Kahneman's "Thinking, Fast and Slow" as these ideas seem to come fairly directly from that book.

[http://www.amazon.co.uk/Thinking-Fast-Slow-Daniel- Kahneman/d...](http://www.amazon.co.uk/Thinking-Fast-Slow-Daniel- Kahneman/dp/1846140552)

</comment><comment><USER10> Scrum attempts to solve many of these problems, rather than just labelling them:

[http://www.writemoretests.com/2012/02/estimating-like-an- adu...](http://www.writemoretests.com/2012/02/estimating-like-an-adult-what- to-steal-from-agile.html)

</comment><comment><USER11> Take the 'psychology' out and insert 'software development'. We're actually really quite good at estimating things in a psychological sense, it just stands out when we mis-estimate.</comment>


Parsing file uploads at 500 mb/s with node.js - <AUTHOR> http://debuggable.com/posts/parsing-file-uploads-at-500-mb-s-with-node-js:4c03862e-351c-4faa-bb67-4365cbdd56cb

<comment><USER2> This is nitpicking, but it always bothers me: "mb/s" is an abbreviation for "millibits-per-second". You meant "MB/s", although this wasn't obvious; if you hadn't mentioned maxing out a GigE connection, it could have been interpreted as "Mb/s", which is short for "megabits-per-second".

</pedantry>

</comment><comment><USER3> Writing everything in callback style is not nice. Why aren't they using a language with coroutines?

<comment><USER4> This presentation has a tiny bit on coroutines:

<http://nodejs.org/jsconf2010.pdf>

> Coroutines complicate the mental model while adding only cheap syntactic > pleasures.

<comment><USER5> Actually, that's not a very good argument. The answer to that is "to you, maybe". The better argument is this one: "Must worry about I/O occurring in all function calls. (They might call wait().) The user needs to make their functions coroutine safe!" I think this is the reason why coroutines are more popular in functional programming languages where side effects are limited by style or by enforcement of the language itself.

<comment><USER3> That is not a good argument either. If you are going to write your entire IO library in asynchronous style like node.js then you could easily make all IO routines coroutine safe. In fact you have exactly the same problem whether you use coroutines or not. If you have a nice asynchronous program and I call wait in the middle that's going to hurt you in the same way.

<comment><USER4> You're correct, it would not be impossible to write coroutine safe code in node.js.

The problem is just that coroutines are not natural in JS, and people will shoot themselves in the foot all the time.

Some "features" are better left out to allow a bigger audience to write reliable Software. Your milage may vary.

<comment><USER3> Perhaps, but in my experience using coroutines is easier than using callbacks because coroutines make code look the same as if it was synchronous.

        readAsync(function(x) {
          readAsync(function(y) {
            write(x+y)
          })
        })

vs

        x = read()
        y = read()
        write(x+y)

You don't really need to know how to use the full power of coroutines if you just want asynchronous operations. You just need to know that read() may block the current coroutine.

<comment><USER6> You could even be more explicit about the whole thing, use _futures_ and only allow them to block. The above example would go something like this if the reads can't be executed concurrently:

      future_x = read();
      x = future_x.wait();
      y = read().wait(); // shortcut
      write(x + y);

Or something like this if the reads are independent:

      future_x = read();
      future_y = read();
      // one of a handful of functions that can "block", all operating on futures:
      waitForAll(future_x, future_y);
      write(future_x.get() + future_y.get());

Using futures rather than implicit suspension has the added advantage of being able to pipeline independent reads just as you can with callback-style asynchronous I/O.

You can already implement[1] an approximation of this in terms of callbacks, but it doesn't look quite as nice, e.g.:

      var handler = new AsyncHandler();
      // independent, pipelined reads
      readAsync(handler.cb());
      readAsync(handler.cb());

      handler.whenDone(function(x, y) {
        write(x+y);
      });

It gets substantially uglier than that if the dependencies aren't so straightforward, e.g. A, B & C are independent, D depends on A & B having completed and the last part of the code requires the results from C & D. Futures do much better in that sort of situation.

[1] I've built a basic but usable helper for this purpose: <http://github.com/pmj/MultiAsync-js/tree/master/src/> I hear the Dojo toolkit contains something similar.

<comment><USER3> Excellent :)

Why do you have a separate wait & waitForAll? Couldn't get() wait automatically?

<comment><USER6> I was just throwing ideas out there, not really thinking it through. :) Although you're absolutely right about waitForAll() in that example, there is a point to that sort of function, say if you wanted to add a timeout. Or you could have a waitForAny() function - useful if you only need one of the futures to finish before proceeding.

get() vs. wait() is admittedly a question of preference. Personally, I'd keep them separate and even go so far as to have it warn you if you called get() without a wait() or a successful isReady() or so on that future. It keeps the suspensions explicit and the intentions clear. It's a bit like explicit vs implicit transactional systems.

<comment><USER7> Out of interest, is this any different to WaitHandles + async delegates in .NET? Doesn't look like it to me but I could be missing something:

        Func<string> reader = read;
        IAsyncResult future_x = reader.BeginInvoke(null, null)
        IAsyncResult future_y = reader.BeginInvoke(null, null)

        WaitHandle.WaitAll(new[] { future_x.AsyncWaitHandle, future_y.AsyncWaitHandle }); // takes optional timeout

        string x = reader.EndInvoke(future_x);
        string y = reader.EndInvoke(future_y);

        write(x + y);

<comment><USER6> Looks like it's essentially the same type of programming model, although I have a feeling WaitHandle.WaitAll() just blocks the current thread. In the ideal case, it would internally call the event loop coroutine and process other events instead without sending the thread to sleep. Thread scheduling involves system (kernel) calls, coroutines are purely userspace, just like node.js's async callback mechanism.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> It's a pity that browsers couldn't just tell you the length of the part in the header of each part.

<comment><USER4> I think the reason multipart works that way, is so you can stream data that you don't know the full length of beforehand.

But afaik, that's pretty much never the case with file uploads, unless you are uploading a file that is still growing in size - so yeah, it's annoying : ).

('felixge2' because my other account is in noprocrast mode: )

<comment><USER9> Think of it the other way too: it allows the HTTP server to start writing the file to disk without having to completely load the file into memory.

<comment><USER4> You could still do that if the length was pre-announced, or am I missing something?

<comment><USER10> Yeah, you could -- I wonder what would happen if the client gets it wrong or is deliberately dishonest? Not trusting the client is a big part of writing an open server and this seems like you would have to trust the client in a big way.

<comment><USER4> Well, it's not a big problem - you should have a timeout on incoming connections, and node is pretty well-suited for having lots of "hanging" connections (I ran some test with 56k active connections).

If a connection is closed, either by a timeout, or EOF, you simply check if the promised content length matches the count of received bytes - if not you should probably discard the whole thing (unless you're specifically supporting broken clients).

</comment></comment></comment></comment></comment></comment><comment><USER11> When parsing boundaries you know the first character is going to be a hyphen(-), and the last character is going to be a newline. Wouldn't it be easier to search for hyphens, and then read until you see a newline, and then compare to the boundary? Typically boundary characters are random printable characters, so you might be doing more work than you need.

<comment><USER12> The rub is "search for hyphens": you have to look at every character until you find a hyphen; the point of Boyer-Moore is that you don't have to even look at most of the characters at all.

<comment><USER11> Ah, that makes sense, thanks.

</comment></comment></comment><comment><USER13> If I can get a revenue stream of approximately $1000 a month my entire website will be literally a call to a few different web services and some fancy- shmancy CSS files. God I love hacker news! Ok fine there will be some of my code in there, hopefully not for long because soon there will be a tool to solve any other problem as well :P As long as these don't get too pricey.</comment>


We Only Hire the Best - <AUTHOR> https://m.signalvnoise.com/we-only-hire-the-best-c711c330fc2e#.yty4hjlla <comment><USER2> Such a no brainer, but jezus it's about time for someone to call out the hiring posts.

Hiring a good employee is like shopping for a car. You don't buy the coup if you have a family of six, a gas guzzler when you're a commuter, or a 2wd when you live in the boonies. It's a balance of values.

I've seen "rock star" coders fail in team environments because they can't communicate. I've seen great communicators fail because they were all talk. I've seen really great team players impolode when facing the customer.

I'd rather have an employee who is good at a few things than one who is "The Best" at one thing. It's called hiring for employee fit, not so you can tell your buddies how l33t your team is.

<comment><USER3> Definitely reading too much into your comment and not responding just to you but the hiring post trend, but IMO all of those scenarios are conflating mismanagement with bad hiring. Have a rock star coder who can't communicate (I'd challenge whether or not that was possible another time)? Put them in a position that minimizes the amount of communication they have to do or set up a structure for their inbound/outbound communications that works for everyone. Great communicator? Have them figure out how to facilitate that person who can't communicate. Great team player? Have them work with the team and don't make them outbound.

Point is, effective team building doesn't end at offer letters. Hire for fit, then fit the hire. Train up. Just because someone is weak in some area doesn't mean they can't contribute meaningfully given the proper resources and support, nor is a strong hire going to succeed without the same carefully tailored support.

</comment></comment><comment><USER4> Experience tells me that hiring posts that demand this level of excellence are often covering for weaknesses in their process.

"We only hire the best!"

 _The best at what?_

"The best at everything of course. We want a full stack wish fulfillment genie."

 _Either you have no idea what skills are missing from your current team, or they are all missing, and you want to fill that gap with one person rather than a team._

Job postings that ask for excessive skills across multiple disciplines say to me: This hiring manager doesn't want to do their job. The management job of creating a team, process, workflow. Why bother building a team of shared responsibilities? Why take ownership of the team's process? That would be hard. Instead I'll just hire one uber-nerd and make them do it all.

<comment><USER5> Here are some of my favorite lazy hiring manager practices:

      * asking for "everything but the kitchen sink" skills
      * confusing Java with Javascript
      * even mentioning J2EE in the requisiton (who on Earth wants to do that in this day and age?)
      * copy-pasting of the requisition leading to truncation of the posting

<comment><USER6> I was talking to the product manager for a product we were having issues with from a major player in the corporate software place who, when we told the manager we were experiencing Java exceptions and instability, kept calling them "JavaScript exceptions." I couldn't believe a PM couldn't even keep the language that the product was written in straight.

</comment></comment></comment><comment><USER7> Nothing is said here that wasn't better said by Joel Spolsky over a decade ago: [http://www.joelonsoftware.com/items/2005/01/27.html](http://www.joelonsoftware.com/items/2005/01/27.html)

<comment><USER8> Expected this to be the top comment.

Nothing new DHH isn't widely praised for originality, but come on this whole article is like a total re-hash. And he doesn't even bother to mention Joel... to me that means he's trying to take credit, or he doesn't know about Joel... uh, yeah.

<comment> why-el > DHH isn't widely praised for originality

Unless you have more to say I think this is an unnecessary attack on David's person, especially that one might think of a couple of things he did that are original. ;)

</comment></comment></comment><comment><USER9> [https://blog.codinghorror.com/we-hire-the-best-just-like- eve...](https://blog.codinghorror.com/we-hire-the-best-just-like-everyone- else/) (discussed at [https://news.ycombinator.com/item?id=11223316](https://news.ycombinator.com/item?id=11223316))

[http://danluu.com/programmer-moneyball/](http://danluu.com/programmer- moneyball/) (discussed at [https://news.ycombinator.com/item?id=11326940](https://news.ycombinator.com/item?id=11326940))

<comment><USER10> That Dan Luu blog post is gold. It really is kind of sad how arbitrary, capricious, and wasteful hiring in IT is, not to mention the short-sighted thinking about talent.

I also really liked the post he did about discrimination in tech:

[http://danluu.com/tech-discrimination/](http://danluu.com/tech- discrimination/)

</comment></comment><comment><USER11> One other aspect of "we only hire the best" that wasn't explored by this article is the practice -- especially common among unicorn companies -- of purposely casting a far wider net than needed, so that their hiring yield on applicants is dauntingly low.

The recruiting process is deliberately set up to yield a lot of false negatives -- i.e., applicants who are qualified on both skill and fit who are rejected for some arbitrary bullshit reason.

I suspect it's largely an effort to mindfuck the employees who do make it through the process. I'm so lucky to be here! Only 3% of applicants even make it to a five-minute founder interview, and only half of them get hired!

<comment><USER12> Well, lots of people have to be rejected for a the not-bullshit reason that there are only n jobs available at the company and n+x people applied. Even if they are all great, x number of people are going to be rejected.

<comment><USER13> I'm not so sure. My understanding is the big tech companies hire engineers on a rolling basis and basically take everyone they like.

They're not approaching it for the frame of satisfying a requisition for a specific role with the best of the N applicants for it on X date, they're picking up talent as quickly as possible and then sorting out where to place people after the hire/no-hire decision is made.

<comment><USER14> It's more like there is unlimited demand, and most managers could think of more things to do if they had more staff.

</comment></comment></comment></comment><comment><AUTHOR> "Everyone thinks they're hiring the top 1%."—Joel Spolsky, 2005

[http://www.joelonsoftware.com/items/2005/01/27.html](http://www.joelonsoftware.com/items/2005/01/27.html)

<comment><USER15> Well I must suck then because there aren't companies lining up to just hand me a job like Joel says happens to all good developers. I have to hustle in order to keep food and a roof.

<comment><USER16> Don't worry. I'm sucking right there along side you. 3.5 years experience and I'm not even getting recruiter spam in the volume some of the people here are. :P

<comment><USER17> You probably would be if you lived in SF. Since the available housing ratio to jobs is 1 to 3, they have effectively guaranteed that not all jobs can ever be filled. Great for the job supply!

<comment><USER18> Or NYC. Or another major urban area with plenty of tech jobs. Anecdotal but everyone I know here in tech (varying roles, skills, and levels of experience) gets plenty of recruiter spam. By contrast, I do know similar people who have had a tough time with the only difference being they're in a smaller market in the interior and are not willing to relocate.

I think location really matters a lot. Telecommuting has not made it irrelevant. There's strong network / market effects for an industry with frequent job hopping and frequent changing of company hiring needs -- employees want to be somewhere with a lot of employers and employers want to be somewhere with a lot of employees, so the top few cities end up taking the lion's share of the tech work.

If anything, easier communications maybe has made it easier for companies to just open up an office somewhere just because that place has a lot of prospective employees. Maybe in an earlier era slower communications with colleagues in other offices might have made this less attractive, but it's so easy now. E.g., tech companies starting in SV but then also opening up an Austin, Pittsburgh, London, Seattle, NYC office because there's plenty of prospective hires there. What you don't see them do much is also open a St Louis, Tampa, or Little Rock office. It's just not worth it.

DEFINITELY consider trying moving to a major tech hub, or just a bigger city at least, if you have persistently had a hard time finding a job locally.

</comment></comment></comment></comment></comment><comment><USER19> Corp: "We only hire the very best"

Programmer: "What's the salary?"

Corp: "Market average. Also, we're looking for people who aren't just motivated by money"

<comment><USER11> We want people who are motivated by _the mission_.

<comment><USER20> If the mission is feeding starving children, or curing cancer, or public service, then yes, I want people who are motivated by the mission. But usually the mission, the _real_ mission, is to make the founders exceptionally wealthy, and forgive me if that doesn't get me out of bed in the morning.

<comment><USER21> Even if the mission is to cure cancer, thats the worst reason to not pay people well. Those are the most difficult problems, and you definitely need the best people to solve the hardest problems. If the idea is to pay people really poor because that problem is so difficult, I think its a bad idea and simply taking advantage of people, not to mention the best people will go solve other problems that pay them well.

<comment><USER22> This is the problem with education (and all non-profits for that matter).

1\. People work in education because they love the work, not the money.

2\. We don't need to pay educators well because they're not the tops in their fields.

3\. We can't recruit top candidates because the pay is shit.

4\. Rinse, repeat.

</comment></comment></comment></comment></comment><comment><USER23> "You know what the best people I've ever met or worked with had in common? ALMOST NOTHING!"

I've found the best have interesting hobbies. The not so best have nothing to say beyond "how bout that sitcom/drama/game last night, eh?". The extroverts won't shut up about it and the introverts have to be coaxed, but one way or another if they can tell stories for hours, about something other than TV last night, they tend to be pretty good at their job.

Its a weaker argument that it has to be a craft hobby. Beer, carpentry, knitting, playing music, writing poetry, subject doesn't matter. If doing something the right way is important to them as a core value outside of work, then they'll tend to do things the right way at work.

</comment><comment><USER24> "First, "the best" is bound to be situational. Someone who can thrive in one environment might get crushed in another. The peak skills that gave them a leg-up in one domain may very well make them unfit for work in another."

Key statement here. Some employers need top coding skills in modern technologies. Some employers, like my current one, really don't need a top coder: they need good analysis skills with some coding. Employers need different degrees of executive function and technical skill. My previous employers valued high technical skill, but we had single product/project focus. My current employer doesn't need high technical skill, but a successful person in this environment needs to be able to multiplex across four projects with differing requirements - COTS implementation, soup-to-nuts software development, bridges between existing systems, etc. - while also providing at least second level support for existing systems.

In addition to executive function and technical skill, add in social skill. Some employers in my past had no problem with on-edge bright technical people. My current employer values politeness far over technical ability.

"Best" and even "successful" have to be defined by each organization according to their mission and values.

</comment><comment><USER25> Thanks for this reminder of basic management practice which needs to be posted about once a year: hire good people and get the most out of them through superb leadership, great working conditions and ample incentives to achieve.

"We only hire the best" is a sales slogan, not a true management principle. The "best" aren't usually for hire at any given moment; they're very well employed already, or otherwise occupied. And when a high caliber person decides to move on, someone in his or her network will likely hear of it and snap them up.

I'd rather hear them say, "We have excellent hiring practices that filter out incompetence and unpleasant personalities. We have a great team here and we're really proud of the hard work they do."

Of course you can make a case for disruption; sometimes what a business needs is someone to challenge the norms, shake things up, rattle the chains, and that can be unpleasant if not downright threatening. An old manager of mine called such people "brilliant assholes". Gotta love'em for what they can achieve, but they're often not much fun to be around!

</comment><comment> daniel-levin "We Only Hire the Best" doesn't have to have any truth to it to be of use to companies. Their purpose in hiring is to extract value from candidates. Convincing people that they'd be amongst the best is all you have to do. The rhetoric comes from existing employees, who may be rationalising their decision to work there. It feels good to be amongst "the best" \- I want to be amongst the best! I am sure I'm not the only one with such aspirations. If being 'the best' means over-fitting to the requirements of a company, then the most successful (viz. "best") candidates will optimise for what that company wants. It means by the time they arrive at work they're already largely conditioned into behaving as their new company would like them to.

Yes, "the best" is a transparent lie. It doesn't matter though, because it serves the interests of companies who espouse it. DHH is calling a spade a spade here - but I'd hazard that the vast majority of the HN crowd already know.

Also, globally, _there are lot of extraordinarily shit software people out there_. If we define quality by "gets things done and doesn't break things and act in a crappy and deleterious manner", then it is not difficult for "the best" to mean the upper 60% of software people. It is completely reasonable to assume that the companies with this mantra do indeed hire from the top 60%, if only because of how many rubbish people there are.

</comment><comment><USER26> The best line I heard "we don't hire a$$$holes". That's a check-mate statement. I think to myself what if I don't get selected :-( . I did get selected only to realise they hired people down the line whom I'd consider rectal orifices. Can't catch a break really...

<comment><USER27> The "No assholes" rule should really be the #1 rule when hiring.

I've heard a lot of complaints from friends and family in the tech industry over the years, as I've had my own issues. While details vary, it always comes down to the acting up of one obvious asshole or another. It infects the whole team/company/project.

In the long run, a team of average but positively motivated people more often than not beats a team with an asshole in it, even if he/she is a rockstar/guru/ninja/jedi/whatever. And their lives won't be miserable in the process.

<comment><USER28> The problem is an "asshole" is subjective. I might find someone to be an asshole that someone else might not think is an asshole.

<comment><USER27> At least from my limited sample, more often than not the assholes are considered to be assholes by everyone else. "Well, everyone thinks he/she's an asshole, but he/she does the job, or has been in the company for a long time, or knows someone in the executive team".

That's where the problems lie, when everyone the person is an asshole but no one can do anything about it.

</comment></comment></comment></comment><comment><USER29> Joel wrote this same post about 10 years ago. [http://www.joelonsoftware.com/items/2005/01/27.html](http://www.joelonsoftware.com/items/2005/01/27.html)

<comment><USER30> Ecclesiastes 1:9 -- The thing that hath been, it is that which shall be; and that which is done is that which shall be done: and there is no new thing under the sun.

<comment><USER31> wtf does this have to do with anything

</comment></comment></comment><comment><USER32> "Losers always whine about trying to hire the best...." \- J.P. Mason

"The best" is a relative measure. An absolute measure must be set first and gatekeepers put in place to guard it. Then, do all you can to find candidates exceeding that measure and then pick the best FIT you can from there.

blisterpeanuts is right on...

</comment><comment><USER33> It's signaling 101.

What are you supposed to say; we hire mediocre developers? Give me a break. "Best" is such a loaded, nothing term that it doesn't really mean anything without a ton of context.

This is a waste of outrage.

<comment><AUTHOR>
      > What are you supposed to say; we hire mediocre developers?

That's a perfectly valid business strategy, and one that is practiced by many big consulting firms. You put someone's butt in a chair, you are billing for them by the hour, and if they won't work 90, 100, or 110 hours a week, there's always someone else who wants their job.

They're not that great, and they know it, and you like it like that.

<comment><USER33> _big consulting firms_

Ok, fine. That's obviously not what we're talking about. You don't recruit talent or raise capital on the idea that you are going to put talent in the sub-basement of a server room because they are a "warm body."

</comment></comment></comment><comment><USER34> "We only hire the best, because nobody else has a hope of surviving the mess that our previous 'best' made."

Seriously, I think WOHTB is an indication that the company doesn't know the difference between selection and training. They want the technical equivalent of Navy SEALs (which is already a questionable goal) so they put in an equivalent of BUD/S, but that's a _training_ program and they're using it for _selection_. Anybody capable of getting past that is either a faker or doesn't need it, and since the second group will also have little patience for it all you're left with is the fakers. Not a strategy for success. I don't mind, though, because their failure makes things easier for the rest of us.

</comment><comment><USER35> > (Did you see Hamilton and Rosberg collide in Formula 1 last week? Mercedes > probably wish they had more of a Vettel and Webber kind of dynamic right > now.)

Vettel and Webber crashed as well in Turkey 2010 as they battled for the lead: [https://m.youtube.com/watch?v=vx9zIQvrdZU](https://m.youtube.com/watch?v=vx9zIQvrdZU)

</comment><comment><USER36> DHH back at it again, dropping truth on the dev game. This was a timely post because my friend and I were just mocking the phrase "we only hire the best" this past weekend. If you like DHH's writing, check out one of his other recent posts: RECONSIDER [0].

I think pointing out some of the absurdities of software development culture and startups is fun. It's unfortunate that Startup L. Jackson hung up his hat :/.

0: [https://signalvnoise.com/posts/3972-reconsider](https://signalvnoise.com/posts/3972-reconsider)

</comment><comment><USER37> There's no way they hire the best. My company told me they already hired all the best programmers!

</comment><comment><USER38> This makes me think of an observation an old colleague of mine made to one of the revolving-door CTOs at our former employer. He said there are three things you can offer to get good engineers... high pay, an interesting problem, and a great work environment. If you can't offer at least two, you really need to excel at the last one.

Problem with former employer was a lousy work environment for uninteresting work...

</comment><comment><USER39> I was looking at a senior position at a "we only hire the best" firm yesterday, a senior position requiring at least a masters plus a decade of experience. But right at the bottom of the qualifications: "Must be proficient in Word, PowerPoint and Visio".

</comment><comment><USER40> Places that truly hire the best are not doing it through job postings. The the company / department leadership are actively involved spending time networking to curate a queue of candidates for hard to hire roles.

The second thing high performing companies do is have entry level roles where you can mass hire to see who rises to perform as "the best" where you can then promote out of that pool into your "hard to hire" roles where you cannot afford an average or below average player on the team.

You'll also need to pay the best at market rates for "best" not market rates for "average". "Pay" breaks down into what I call 'the money/fun dial' \-- the dial goes from 0% money / 100% fun to 100% money / 0% fun. At 0% money those activities are called hobbies and everyone has a list of activities they enjoy doing each day they either spend money on or at best break even. At 100% money / 0% fun this is effectively "selling your soul" \-- these are the jobs that leave you no time or energy to have hobbies, non-work relationships, or a family. With my company we aim for 50%/50% on the dial -- we pay well, allow folks to work hard on meaningful projects, and give them time for hobbies/friends/family. I view life as a marathon and if you turn the dial up or run a company culture with the dial turned up beyond 50% on money people will work for you until they burn out or make enough to find a long term home.

</comment><comment><USER41> Sometimes I even ask myself: "you only hire the best…at what exactly?" there is difference between having a fancy degree/accolades and actually contributing meaningfully to your work. I have also seen(in my thin years of experience) that at most companies, there is a disconnect between HR and company's talent needs. Only those who have figured out how to bridge that gap hire "the best"(subjectively).

</comment><comment><USER42> In the spirit of going deep, the root cause of the F1 crash was human error (being in the wrong strategy mode) rather than ego.

<comment><USER43> Yeah, that was a whole different kind of error. Also, the line before that is pretty wrong too, so I guess we're just going to have to ignore the whole paragraph.

</comment></comment><comment><USER44> Another good post on the same subject is:

We only hire the best means we only hire the trendiest

[http://danluu.com/programmer-moneyball/](http://danluu.com/programmer- moneyball/)

HN discussion:

[https://news.ycombinator.com/item?id=11326940](https://news.ycombinator.com/item?id=11326940)

</comment><comment><USER45> just like when you see signs "best pizza/hero in town" or "we use best ingredients" at eateries

</comment><comment><USER46> Sooooo good! I think I may start replying with a link to this article every time a recruiter contacts me with one of these types of jobs. They almost always require moving to the Bay area for some "hot new" startup and a whopping $80k salary + equity. Can't live off that in the Bay area and I have no desire to work for your Uber for X startup, do weekly scrum sessions or work in an open office environment crammed tight.

I think a quick reply with a link to this article will do the trick.

</comment><comment><USER47> We only hire the best. We are going to consult all the best experts and we'll get the best people in the office to make 37 Signals great again. It will be a beautiful thing.

</comment><comment><USER48> One of the chapters of "Parkinson's Law" (the book that among other things coins 'bikeshedding') discusses hiring from a satirical point of view. He makes the point that the easiest kind of hire is when only one candidate applies, so it's good to load down your adverts with as many requirements as possible so as to put applicants off.

</comment><comment><USER49> And what if a candidate has a good background in computing, computer science, AI, and pure and applied math and, then, also a good STEM field Ph.D. degree from a leading research university.

Do you want to "hire the best" or do you want to reject anyone with a Ph.D. degree? E.g., how many STEM field Ph.D. holders have you hired to date?

</comment><comment><USER50> > but recognizing the difference between what you'd like to be true and what > actually is serves as a prerequisite for closing that gap

...and not recognizing it is a prerequisite for running a company.

</comment><comment><USER51> It needs to be read as "We only hire the best (we can find)". So the results are explained by the search and selection "algorithms" applied in the hiring process.

</comment><comment><USER52> Is it just me or svn blog quality greatly reduced these days ?

</comment><comment><USER53> Although I agree most of what DHH said in this blog post, I am a little disappointed that he only offers Don'ts but not in Do's.

</comment><comment><USER54> Employer: I want the most work for the least money.

Employee: I want the most money for the least work.

In the current market Employer > Employee.

</comment><comment><USER55> Isn't the author of this post the primary villain from the big #rubydrama article on HN over the past couple of days?

</comment><comment><USER56> I see a lot of people on this thread who just say it's bullshit without understanding what's going on. You can live your life that way, or you can enlighten yourself on what really is going on and make the right decision.

This "salary cut" works only in this case: The employee is not just looking for money but something intangible from the job (Experience/network/etc.) This doesn't apply to most of you guys who have no intention to start a company or make a huge leap in life. That's why you think it's bullshit. But there are also a small number of people who are really not driven by just money but puts a lot of value on the intangibles I mentioned above.

Many startups look for these types of people, so to those of you who are hating on this idea: there's nothing wrong with you hating on them. It's by design, these companies don't want you either. I know from experience because I've hired people who just got in without any specific reason. These people tend to give up very soon because they simply don't care about what they're building. And again, there's nothing wrong with that. It's just that these startups can't afford to hire you.

Here's my horror story: I was working on a startup. We were fortunate to have a guy who's extremely talented and wrote the core part of our product. However he switched ship immediately when he realized it was a business that will take time to mature. I really hated that guy for a while because we had to basically abandon our core product the day he just left. Now I understand and also know that part of it was my fault too, but it was a very difficult experience for me. If you look at the world with this lens you'll notice so many "rockstar developers" jumping ship after another when things don't go well for the company (which is totally fine for them but bad for the company). That's why startup companies should care more about the "right match" than "rockstar developers". And hiring a rockstar developer by paying him tons of money when he's not so passionate about the company's vision is the worst thing you can do.

An analogy is most girls who don't want guys who are just in it for her looks. When you try to seduce a girl, complementing her looks rarely works unless your social status is extremely obviously high or if your looks are extremely great. In most cases you have to demonstrate that you like her not just for her looks but because of her personality. Most girls don't want a guy to just have fun for one night, never to see again, especially if they like them. I know many girls who gave up on a guy she really liked because she didn't want to be hurt. Startups are like that.

<comment><USER57> I'm not even going to try to reply on the sexist nature of the second half of this comment, but focus on the startup-related one.

Your guy switched to another company because you were on track to become rich off his work, and he was not. If you incentivized him right, he'd stay. Did you ask him why he left? Because if not, you really did not learn a lesson.

<comment><USER56> I knew someone would call me sexist. I know where you're coming from but I think people whenever they come across something that makes them uncomfortable just call it "sexist", "racist", etc. and call it a day. All I did was state the fact. You explain how it is sexist and if it's logical I will shut up.

Lastly, he switched because no one was getting rich off anyone's work. We were going through difficult times. But that was not the point of my comment. You blame me of being sexist but maybe you should also be less biased when reading someone else's words.

<comment><USER58> Well with all due respect, you yourself didn't address OP main point in your answer : Did you or did you not try to rightfully incentive your main coder? It seems to me that many founders want early employees to take the risk of a co-founder but with the reward of an employee.It always amazes me that some people don't realize that being mad a someone for acting in his best interest is actually selfish.

</comment></comment></comment></comment><comment><USER31> what a shit headline.

</comment><comment><USER59> so... they're really just lowering their standards... I was told here on HN that's wrong...</comment>


How to Spy On Your Competition - <AUTHOR> http://www.businessinsider.com/how-to-research-your-competition-2011-5 <comment><USER2> On this topic we've just launched a hosted competitor monitoring service, <http://www.webalertpro.com>

It's a website content monitoring service that generates daily reports for all content changes for all your competitors websites.

It was a quite an interesting technical challenge since most sites generate loads of small unimportant changes (and text moving around in lists, dynamic news reels, dates etc..) of no interest to anyone. So the approach we tool was to rank each change. So when a user adds a new site to monitor the first few days of crawling it are spent learning where the important content changes take place on the site. We can then report assign to each change alert a score between 1 and 10 (ChangeRank!).

We're getting quite some interest in the applications of this, from campaign monitoring, marketing compliance and figuring out what content changes your competitors are making for the purpose of SEO.

<comment><USER3> er... « There was an error processing your request:

Please contact us, or try again. »

<comment><USER2> Thanks for trying it out. There was an issue with sites that redirect from http to https. Just putting in a fix and will ping you when done.

<comment><USER2> Should be fixed now if you want to have another go...</comment></comment></comment></comment>