Rent time with founders from Parse, Hipmunk, Sincerely and Reddit through Exec - <AUTHOR> http://blog.iamexec.com/post/20415502048/rent-a-tech-company-founder-through-exec-for-donors

<comment><USER2> Trying to create an account on exec:

\- email cannot contain the '+' character (yes it can!)

\- phone should be 10 characters long

I can go around the first problem but not the second one (I'm in France: country prefix (33) + number = 11 pos).

I understand the service is targeted at SF residents right now, but since it's available for "virtual" tasks, why be so restrictive?

<comment><AUTHOR> Sorry, right now I don't think we have a good way to validate international phone numbers, we should fix that soon. The email refusing "+" was because of a crappy lib that I was using, and it isn't terribly high on the list of things to fix.

So, I guess the real answer is that it is restrictive because that was what was easiest.. sorry :(

<comment><USER3> Here is some handy regex:

/^([\w\\!\\#$\%\&\'\ _\\+\\-\/\=\?\^\\`{\|\\}\~]+\\.)_ [\w\\!\\#$\%\&\'\\*\\+\\-\/\=\?\^\\`{\|\\}\~]+@((((([a-z0-9]{1}[a-z0-9\\-]{0,62}[a-z0-9]{1})|[a-z])\\.)+[a-z]{2,6})|(\d{1,3}\\.){3}\d{1,3}(\:\d{1,5})?)$/i

<comment><USER4> Or just check for an @ symbol and use confirmation email.

<comment><USER5> It's worth hesitating before introducing a confirmation-email step. You're certainly going to lose people every time you increase the complexity of the signup process.

<comment><USER6> In some countries (EU?) you're required to do a confirmation-email step.

</comment></comment></comment></comment></comment></comment><comment><USER7> Neat way to kill two birds with one stone. Not only do you get to promote Exec but you also get people to donate to a wonderful charity. Its great that you got such great founders to donate their time.

<comment><USER8> Win-win indeed! Thanks. I'm on the advisory board of donorschoose.org, so I'm super biased, but they're indeed awesome (also, use my matching code! 'breadpig')

<http://donorschoose.org/alexisonCNN>

</comment></comment><comment><USER9> This is full of win. $100 for charity and an hour of advice from some really great people. I'm on board, now I just need to figure out who I'm going to talk to. Edit: signed up to talk with Tikhon Bernstam.

</comment><comment><USER10> This is awesome. Maybe more startups should figure out product-specific ways to do charity periodically. It's a good way to test new features, too.

</comment><comment><USER11> Brilliant! This is a great way to demonstrate the power of the Exec model.

</comment><comment><USER12> This phone-calls-with-celebrities model has been tried many times before but it simply isn't viable in the longterm for various reasons. Clearly you can get people to do it occasionally and even enjoy it, so it's great for things like what exec is doing, but it's not something that many people would do on a regular basis.

That said there are definitely still unexplored variations on this idea that have at least a decent probability of success, so I think it's worth it for those seeking ideas to take a closer look here.

<comment><USER13> calls-with-experts has been done and is huge.

<http://www.glgresearch.com/>

<comment><USER12> In this case it makes sense because these people already do consulting for a living, so this is just another way to get clients. And further, the person calling is going to be looking for expertise about a specific topic rather than looking to talk with a specific individual because of their accomplishments or whatever, so it's much less socially awkward.

I do still think there is an opportunity though to get celebrities who wouldn't normally do this to do it, it's just that none of the ways that have been tried so far have been suitable.

<comment><USER14> It's not just consultants. They connect you with industry experts. One of the biggest spammers on linkedin I find are these types of companies looking for domain experts.

</comment></comment></comment></comment><comment><USER15> all of the founders are young. no grizzled veterans. fascinating.

i would like to speak to a similar group, except 20 years more mature, running a business like Apple or Boeing.

<comment><USER16> This is what GLG does: <http://www.glgresearch.com/>

I did a lot of interviews via GLG (and similar services) as a consultant, with rates ranging from $200-700 per hour. The $700 range was for C-suite interviews at $5-10B revenue companies. I imagine a senior person at Apple or Boeing would be well in the thousands per hour for a similar service.

The people who are paying for these services aren't small start-ups trying to grow -- it is private equity and consulting firms with really deep pockets making multi-million/billion dollar decisions. They'll pay what it takes.

<comment><USER17> I've done GLG (and other similar services) in the $700 range. It's not just for C-level execs at $5-10B revenue companies (I cofounded two venture-backed startups).

I started by charging $400. Then I realized that some of these calls last 15 minutes. At "$700 per hour" we're talking about a whopping $175 to do the scheduling routine (some back-and-forth), make time in my schedule, interrupt "flow", and take the call.

I now insist on a 1 hr minimum and bill $700 and do it occasionally when the offers come in (handful of times per year) because I like talking about the subject matter. It's not exactly the best use of my time.

</comment></comment></comment><comment><USER14> This is a really cool idea. I tried to book Matt or Justin saturday for an hour but any would be worth that small price. I bet if you had pg people would pay 1k+ per hour.

</comment><comment><USER18> Need this for NYC. I have to imagine that this is the next area to expand to.

<comment><USER8> Hear hear. Believe me, I've been bugging Justin to come here. All in due time...

</comment></comment><comment><USER19> Hopefully this is adding value to those who are calling in. It looks a little self serving Exec marketing stunt. But, good on them!

</comment><comment><USER20> I seriously wonder why someone hasn't created an app/escrow service to mimic/enhance 900 numbers.

Experts enter, hours available, and their price per unit (minutes, hours, whatever).

Users would basically pay the experts premium to cut through any and all communication filters to get ahold of that person right then. If the expert doesn't answer his phone right then it would text them to respond with 3-4 digits for a set time (clients chooses time range) to reschedule (or deny).

If you find yourself not taking calls the system will automatically increase your cost per hour until it is worth your time to just answer the damn phone (it will be eventually).

Think of it as a simple handshake service for payed phone consultation.

In the speaker/entertainment industry you quickly come to realize that pretty much everyone has a price to get their full immediate attention, it doesn't matter if it's Bono or Tim Cook. Not to be crass but everyone is pay-for-play at some dollar amount.

Anyone from Ilya Grigorik, to Gary Vaynerchuk could probably set a price point that would make them very happy and generate calls.

<comment><USER21> This is precisely what AnyFu is: <http://www.anyfu.com>.

We haven't launched yet (just testing out the system), but we've processed five client/expert sessions in the past couple weeks and the feedback has been overwhelmingly positive.

<comment><USER22> This is genius. How do you vet your experts? When is this going to release? Please take my money.

</comment></comment></comment><comment><USER23> No founder is so cheap as to have their time to be rented from. Besides, if I want to connect with some of the founders, all I have to do is send them an email.</comment>


Opera is expanding its suite of cryptocurrency tools with a built-in wallet - sahin-boydas https://thenextweb.com/hardfork/2018/07/11/opera-cryptocurrency-browser/ <comment> sahin-boydas pretty smart move before IPO</comment>


Ask HN: Are you also having problems to access AWS EC2 resources in eu-west-1? - <AUTHOR> Health checks of a few instances have failed since about an hour ago and we're having intermittent problems to access the EC2 web console. Seems to be isolated to eu-west-1. Same problem in at least two AWS accounts.<p>Are you also seeing this? <comment><AUTHOR> They have verified this on the status page now: [https://status.aws.amazon.com/rss/management- console.rss](https://status.aws.amazon.com/rss/management-console.rss).

Haven't seen anything about instances failing health checks there yet but one of our instances have a built-in check failing currently.</comment>


Tim Cook demands Obama White House defend Americans' right to strong encryption - <AUTHOR> https://boingboing.net/2016/01/13/apple-ceo-tim-cook-americas.html <comment> corp-a good luck with that...</comment>


The original EPR paper [pdf] - <AUTHOR> http://www.drchinese.com/David/EPR.pdf

<comment><AUTHOR> The original paper by Einstein, Podolsky, and Rosen that challenged the Copenhagen interpretation of Quantum Mechanics and first described what is today called quantum entanglement.</comment>


The Idea of Sunk Cost in Product Development - <AUTHOR> https://medium.com/@amarjeet000/the-idea-of-sunk-cost-in-product-development-81ae22905765

<comment><USER2> I agree that many product guys fall in love with their product so much that the user's point of view ceases to matter to them</comment>


Distrusting git - <AUTHOR> http://benno.id.au/blog/2011/10/01/git-recursive-merge-broken <comment><USER2> > OK, so the bug never trigged in 16,000+ Linux kernel merges. Strangely that > doesn't actually make me feel any better.

I remember when I discovered recursive merge. Turned it off straight away. Testing on a specific kind of code base with 16k test cases isn't that much better than 'untested'.

I like merge conflicts - they don't destroy my productivity and make me feel secure that my SCM isn't stepping beyond its bounds - automatic merges are always dangerous, even if they work 99.9% of the time - the time when it destroys two people's works more than makes up for that (this has happened to me with p4v and git in real world scenarios near a deadline).

I've always had a hard time with git though to be fair... but no problems with mercurial. It started with an installer where it was easy to accidentally download the source repo over my metered connection... 'Linux quality software' for sure.

The more I've learned about how git works the more I don't want to use it. :/

</comment><comment><USER3> "Person does something stupid, blames tools" ><

In general: _commit before you start doing major tree /history manipulation stuff like merging; committing is what makes your data really secure!_ This is not a subtle point, it's merely common sense, and because of git's "commits are lightweight, local, and amendable" model, there's little excuse _not_ to commit.

[It seems somewhat likely this person was used to subversion, which has much more heavyweight commits and a more limited model, and thus requires doing more stuff while in an uncommitted state. But "like subversion" is not synonymous with "good practice."]

</comment><comment><USER4> If you aren't keeping daily (or better) snapshots, you're doing it wrong. git (or any other such system) isn't a backup any more than RAID is. There's always the possibility of running into some massive bug that corrupts the whole repository, and having the damage get propagated as happened to KDE last year.

</comment><comment><USER5> Interesting...but mostly as the general warning on trust in software, and as a historical memento (Oct 2011).

</comment><comment><USER6> Though it was posted 2 years and 3 months ago, and the article states that the bug was fixed, to me, the interesting parts were tracking down the versions of git that were affected, and demonstrating the need for more rigorous regression test cases in build --test.

</comment><comment><USER7> interesting.

It re-inforces the need for task branches. And don't merge into uncommited code.

</comment><comment><USER8> "zfs snapshot"</comment>


Eight Deaths now tied to e-scooters - <AUTHOR> https://www.consumerreports.org/product-safety/deaths-tied-to-e-scooters/ <comment><USER2> I really hate articles like this. Eight deaths out of how many rides? How does that compare to driving, biking, walking? There's a lot of anger and resistance aimed at e-scooters. Maybe it's valid but this article doesn't make the case.

</comment><comment><USER3> It's not only car drivers' fault. I've routinely seen scooter riders float through stop signs, go 15 on sidewalks, flip a u turn in a busy street, generally never signal, jump a set of steps on a scooter, do "brake burn" tricks, hop on one after a night at the bar, etc. The public can be pretty careless, and I'm frankly shocked this number is so low given the fuckery I've seen by the general public riding these. It's like a sense of caution, common sense, and rules of the road are just gone and they fee they are finally free to do what they want when they want.

</comment><comment><USER4> Most of these injuries are caused by motor vehicles colliding with scooter riders. There is little to no infrastructure for bicycles and scooters in the US and cyclists have been screaming for years. Now it's happening to scooters too. If you are an experienced rider you have at least a few stories about reckless drivers that almost killed you.

'"what has immediately become clear is that 75 percent of the known fatalities with shared e-scooters were due to collisions with cars."'

<comment><USER5> Two of my friends suffered serious knee injuries while riding e-scooters. That passes three of my risk filters. Something is a risk if:

1\. Happened to a friend of a friend. 2\. Happened to one of my friends. 3\. Multiple fiends.

</comment></comment><comment><USER6> We should be requesting info on E-scooter involved traumatic head injuries / wrist and ankle injuries.

These are easier to hide / arguably have more of an impact on the public than death itself.</comment>


Set Theory: A Summary - <AUTHOR> https://mathvault.ca/hub/higher-math/math-symbols/set-theory-symbols/ <comment><USER2> In what universe does someone need to be introduced to the union of two sets and to transfinite induction simultaneously?</comment>


Index of all WikiLeaks cables with tags - Google Fusion Tables - <AUTHOR> http://www.google.com/fusiontables/DataSource?dsrcid=317391

<comment><USER2> How do you read them?

I've already found how to filter them: View -> Filter. (Althought it always times out, too much documents).

</comment><comment><USER3> I don't see that cable contents here..

<comment><AUTHOR> This was submitted by the Guardian. Could be that they will upload content later. Anyway, awfully slow now. Those servers are hogged ;-)

Edit: Here you can see them all including content: <http://news.ycombinator.com/item?id=1948360>

</comment></comment><comment><USER4> Really? Must we use the 'gate' suffix? Could we possibly put an end to this practice?

<comment><USER5> What suffix will we use then?

<comment><USER6> How about none. Just use words plainly and skip cuteness.

<comment><USER5> I'll rephrase my original question, since apparently you didn't understand it as evidenced by you not supplying any concise name.

What's the plain words for this?

<comment><USER6> I'll also rephrase and say I think the current trend of giving a concise name / label to everything is contributing to the soundbite mentality. This is the "Wikileaks of US State Dept cables". From there, you can keep referring to the "cables" for short.

I'll concede that labels makes it easier for search engines, but I am not convinced that that is a good thing.</comment></comment></comment></comment></comment>


You Can Now Use LastPass to Log Into Android Apps Automatically - <AUTHOR> http://mashable.com/2014/03/26/lastpass-autofill-android-app/?utm_cid=mash-com-Tw-main-link

<comment><USER2> This is great. LastPass now works nearly exactly as it does in the desktop browser extension, but for apps too. They register the app as accessibility provider, so that it can detect when a view contain keywords such as "username" and "password", and then prompts you to choose which account it is based on a guess which credentials link to the app. Makes life lots easier, particularly with apps that clear the login screen when you switch out of them.</comment>


Handle passwords with Keychain - <AUTHOR> http://sirupsen.com/handle-passwords-with-keychain/

<comment><USER2> I wish there was something like Plan 9's Factotum that today's programs used. It didn't just store keys for you; it handled authentication on behalf of your client.

<http://en.m.wikipedia.org/wiki/Factotum_(software)>

</comment><comment><USER3> One feature that is not noted in the article is the configurable access to the items in the keychain. You can allow certain binaries to access certain items in the keychain with or without a password. So for example, for your banking credentials to be autofilled in Safari, you can require the master keychain password to be entered. This is extensible beyond the browser, though, another example being SSH key passwords accessible by ssh.

</comment><comment><USER4> The one issue I have with using Keychain as the primary password manager is that I lose all my passwords when I cross over to Windows or Ubuntu.

<comment><USER5> Indeed, that's what I like about 1password - with their web interface you can practically access your passwords from everywhere - and hopefully there will be a ubuntu version soon.

<comment><USER6> I use 1Password's "Anywhere" feature to host my passwords over a VPS. All you need is a browser (on any OS) at that point. There's also ways to do it over Dropbox: <http://help.agilebits.com/1Password3/1passwordanywhere.html>

</comment></comment></comment><comment><USER7> I use this system myself - except without the `security` command and with random passwords. Which is annoying as my generator is command line, so there's a lot of cut and pasting going on. This will be a distinct improvement to the system.

</comment><comment><USER8> what if you're not around your Mac? You're screwed.

</comment><comment><USER9> Except...you're kind of SOL if you want to log into something from your mobile away from your computer, right?

</comment><comment><USER10> Also its only good if you use a really strong passford in the first place...

</comment><comment><USER11> It has great password generation too, especially compared to 1password. The passwords really are rememberable.

</comment><comment><USER12> yeah if you are mac only this is great, otherwise get a better product.</comment>


The US Coal Industry Is Declining Irreversibly - <AUTHOR> https://oilprice.com/Latest-Energy-News/World-News/The-US-Coal-Industry-Is-Declining-Irreversibly.html <comment><USER2> This seems good as long as the industry is being supplanted domestically with renewable alternatives at the same rate it's falling.

<comment><USER3> Among those renewables are "biomass" which is just burning trees. If we burned all the trees in the country it would only be enough fuel for a year. This is replacing one awful fuel source with another. Wind and solar rely heavily on fossil fuel infrastructure or directly—-solar panels are made with coal and mined quartz. And it has to be replaced ever few years. It's looking more and more like nuclear is the only real option but that is another terrifying option because companies are greedy and will mismanage it and we can't afford nuclear disasters.

<comment><USER4> biomass is a lot more than just trees. and even then its byproducts of forestry product production like saw dust.

<comment><USER5> Biomass as an energy source is limited by net primary productivity. Humans already appropriate a large portion of this (~20%), and total fossil fuel consumption would roughly double this (inexact numbers, it's been a while since I've looked at this).

Factoring in typical assumptions of population and economic growth, and the picture darkens further.

We simply don't have available biomass to power the present economy, let alone one with more people of net higher average wealth. There are reasons humans switched from renewable to nonrenewable energy resources. Unfortunately the practice is unsustainable on several fronts.

[https://old.reddit.com/r/dredmorbius/comments/2cvap7/the_int...](https://old.reddit.com/r/dredmorbius/comments/2cvap7/the_intractable_problem_of_biomass_for_fuels_is/)

[http://www.eoearth.org/view/article/153031/](http://www.eoearth.org/view/article/153031/)

[http://agroinnovations.com/blog/2007/04/27/the- photosyntheti...](http://agroinnovations.com/blog/2007/04/27/the- photosynthetic-ceiling/)

[https://web.archive.org/web/20120810132407/https://environme...](https://web.archive.org/web/20120810132407/https://environmental- issues.wikispaces.com/Photosynthetic+ceilings)

I especially recommend Jeff Dukes, "Burning Buried Sunshine" (2003):

[https://dge.carnegiescience.edu/DGE/Dukes/Dukes_ClimChange1....](https://dge.carnegiescience.edu/DGE/Dukes/Dukes_ClimChange1.pdf)</comment></comment></comment></comment>


Ask YC: I am modifying my startup. can I update my application? - <AUTHOR> My startup is a chatbot. I am making a pivot, adding more features and getting into a different market.<p>Is it possible to update it? or it's too late and I would do it next cycle? <comment><USER2> Send an email with the question to email@example.com . These post may fade away unnoticed.</comment>


Unemployment Rate for Computer Occupations Fell in May - <AUTHOR> https://www.forbes.com/sites/stuartanderson/2020/06/11/unemployment-rate-for-computer-occupations-fell-in-may/#16761e8716ad <comment><USER2> I thought that developers would eventually be hit hard by this.

If anything, the recruiters seem to have stepped up their work. My LinkedIn is awash in jobs. My inbox is getting something every 1-2 days. Jobs I applied for even a year ago are now getting back to me.

<comment><AUTHOR> With remote work being more acceptable now, many of those jobs are likely to be shipped to Canada and India because of these upcoming immigration regulations.</comment></comment>


Outlook.com breaks the 25 million active user mark, releases an Android - <AUTHOR> http://thenextweb.com/microsoft/2012/11/27/outlook-com-breaks-the-25-million-active-user-mark-releases-and-android-app-and-new-themes

<comment><USER2> Jumped on my own name email address on Outlook when they relaunched the new look and I have to save I love it. I find it much easier on the eyes and in the UX department than Gmail.

Gmail to me feels stale and over encumbered by labels and buttons and checkboxes.

There are some thing about Outlook that do annoy me, mainly how it doesn't want to save my password in the login form and automatically fill it in. It's ridiculous. I also dislike having to type my email address instead of just the username. `firstname.lastname@example.com` it gets tiring.

I don't regret switching! :)

<comment><USER3> Bookmarklet to force firefox to remember any password, even on pages that have autocomplete=off (like outlook.com)

[https://www.squarefree.com/bookmarklets/forms.html#remember_...](https://www.squarefree.com/bookmarklets/forms.html#remember_password)

Drag that to your bookmarks toolbar and run it once before submitting the form on the website you want to remember passwords on.

</comment></comment><comment><USER4> The reason Outlook.com has 25 million users is that it's harvesting/transplanting users from the it's Hotmail user base.

<comment><USER5> I'd use the term "bullying" in this respect.

<comment><USER6> Are they just urging people to switch, or do they actually move them over without the user having a say in it?

<comment><USER5> Urging - regularly. I use a hotmail account for trash signups and they are pushing constantly.

<comment><USER7> Out of curiosity, how are they pushing? I just signed up for a new Hotmail account, and the only upsell I'm getting consistently is a small "Free Upgrade" link in the bottom left (which actually appears to be structured as an add, which is kind of strange).

By the way, you can opt into "Outlook.com" without getting a new email address. You can keep your same address but get the new Outlook.com experience, which is quite frankly much improved.

Disclosure: I work for Microsoft.

</comment></comment></comment></comment></comment><comment><USER8> the android app is outsourced to a company and it's awful.

<comment> angry-hacker It looks more like a joke... this can't be real.

<https://play.google.com/store/apps/details?id=com.outlook.Z7>

</comment></comment><comment><USER9> I registered way back, and subscribed to two mailing lists to try it out. That exposed a major flaw to me: Conversation views are in reverse time order. Which is _kinda_ okay if you're talking to an actual person and might just want to look up what you previously said, basically an extended version of (goshawful) top-quoting. It does break apart if you're trying to get into a new mailing list conversation where you have to read through 10 posts.

If it had an option of reversing that, it wouldn't actually be that bad. Not as good as gmail, but better than all the desktop-clones like gmx.com or yahoo.

</comment><comment><USER10> the outlook.com web app is nice, but the Android app is complete junk,, looks like something they just put together in few days.. makes me wonder why they even bother making it in the first place...

</comment><comment><USER11> I wonder how many of the 25 million are people squatting on their family names and such. That's what I've done. I login once a week or so to make sure the account stays active.

<comment><USER12> How frequently must one log in (to modern email clients) in order to not be deactivated? Once every 5 months and 30 days?

<comment><USER13> I think it's 90 days for hotmail/outlook, which is pretty short compared to gmail, which I think is a year. But, that would also explain why it's a lot easier to get the email name you want on hotmail/outlook.

<comment><USER14> If you're using a multi-account IM client(Adium/Pidign/etc') you can add the account there, and it will stay alive as long as you continue to use the client.

</comment></comment></comment></comment><comment><USER15> Does the address book sync work in this version, or is it still broken like in their Hotmail app?

</comment><comment><USER16> By "active" they must mean "actively collecting spam".

<comment><USER17> I have a very active hotmail account and it's actually amazing at filtering out spam.

</comment></comment><comment><USER18> What a coincidence, I registered yesterday. Must have been me ;)

But seriously: WTF. It sucks so badly, that badly needs to be redefined. OK, it's much better then msn/live mail was... and redefining badly is perhaps a bit too harsh. But it still sucks.

Did anybody see what it looks like? It is very clean. Boring even. And in chrome the screen is not even 100% height in the mail overview. (And sending mail from google mail ended up in junk, but that may have been bad luck).

I do like the new stuff MS is trying though. I really hope their metro stuff on desktop and mobile will cause some movement in the 'almost the same for many years now'-interfaces from other manufacturers. In that case I might benefit from their experiments as well.

<comment><USER19> I am downvoting you because you said 5 times that it's bad, and you have provided 1 single arguable example of why it is so.

<comment><USER18> I agree, I do not deserve points for just saying how I 'feel' about outlook.

Thats no fundamental reason. Just a feeling. It depends on how you look at it: this feeling, just not liking it, might others have as well.

<comment><USER20> I think Outlook.com has plenty of real usability issues. For instance, it immediately forgets which messages you had checkboxed if you just jump to the next page and come back. And the whole From/Subject index view can display very little information compared to Gmail. You don't get the same "I am in control" feeling. And whatever you click on Outlook.com, there's always a noticeable delay before anything happens.

Personally I think that if you launch a new webmail service, you should first make it at least as functional, usable and solid as Gmail. Otherwise what's the point.</comment></comment></comment></comment>


My Occupy LA Arrest, by Patrick Meighan - <AUTHOR> http://myoccupylaarrest.blogspot.com/2011/12/my-occupy-la-arrest-by-patrick-meighan.html

<comment><USER2> It's difficult for me to believe any of these stories without more proof.

There was a video going around a couple of weeks ago about how "peaceful protesters" were pepper-sprayed and arrested by the cops. All news organizations showed us only what they wanted to show us to make a point that the cops were the bad ones in the situation.

The full video showed the protesters not listening when the cops told them to leave, making a circle around them, and not allowing them to leave. The cops also told them to cover their eyes because they were about to get sprayed.

I wish people from both sides would stop spewing out so much propaganda.

<comment><USER3> > _It's difficult for me to believe any of these stories without more proof._

You're either claiming that the posting is a fake, or that the author (someone quasi-notable, even) has outright _lied_ about their treatment. You're spewing FUD to justify your continued fantasy where the cops are the good guys.

Honestly, created 8 days ago? I hate Eternal September.

<comment><USER2> "created 8 days ago?"

Haha, I've been reading HN for 3+ years now. In fact, I was thinking the same thing when I read your response. A forum is supposed to be about expressing your opinions. I wasn't being offensive but because I'm not all on board with your opinions, you have to jump to conclusions and throw an online temper tantrum. It's things like these that will make me leave HN for good (believe me, I've thought about it many times).

Moving on from the ad hominem.....

"You're either claiming that the posting is a fake, or that the author (someone quasi-notable, even) has outright lied about their treatment. You're spewing FUD to justify your continued fantasy where the cops are the good guys."

Would you call not telling an important part of the story lying? I'm sorry but I've seen too many OWS supporters spread false information about their situation in order to make themselves look like the good guys. I can't tell you how many Photoshopped pictures I've seen as the truth and other people out-right denying things that happened.

If you can't be an adult and tell me the truth, I will never be on your side.

I also don't know about you but I don't automatically assume everything that a "quasi-notable" author/star/etc is the truth. This is how many countries have gotten themselves into trouble.

<comment><USER3> A lie of omission is a lie, yes. But let's take a look at some actual passages from the article:

> _Each seated, nonviolent protester beside me who refused to cooperate by > unlinking his arms had the following done to him: an LAPD officer would > forcibly extend the protestor's legs, grab his left foot, twist it all the > way around and then stomp his boot on the insole, pinning the protestor's > left foot to the pavement, twisted backwards. Then the LAPD officer would > grab the protestor's right foot and twist it all the way the other direction > until the non-violent protestor, in incredible agony, would shriek in pain > and unlink from his neighbor_

> _When I involuntarily recoiled from the pain, the LAPD officer threw me > face-first to the pavement. He had my hands behind my back, so I landed > right on my face. The officer dropped with his knee on my back and ground my > face into the pavement_

> _a separate team of LAPD officers used knives to slice open every personal > tent in the park_ ... _and then yanked out and destroyed any personal > property inside those tents_

> _As a reminder, Antonio Villaraigosa has referred to all of this as "the > LAPD's finest hour."_

So, we have a group of people in a _public park_ exercising their _right to protest_ , whereby they are arrested with systematic excessive force while their belongings are destroyed. What could have been omitted that would possibly justify this?

Furthermore, you're asserting that the author must be lying in some way, without presenting any proof of your own. I can only conclude you aren't looking for truth at all, but for justification to dismiss the post as it doesn't fit with your world view.

<comment><USER4> How, exactly, should LAPD have gotten those folks unlinked and removed them? Remember, those folks didn't want to unlink. Your answer should include some evidence showing that it would have worked.

Your right to protest does not include a right to occupy a public park for an indefinite amount of time.

As to their property, they were given notice that it would be removed. They ignored said notice. Again, what would you have the police do?

Acceptable answers result in the property removed without the cooperation of the owners or significant costs to the city.

FWIW, Villarigosa's statements in favor of these actions are perhaps the best argument against them in my mind because he's a disaster.

<comment><USER3> > _How, exactly, should LAPD have gotten those folks unlinked and removed > them?_

By waiting for them to do something they should actually be arrested for, rather than using trumped up misdemeanor charges as an excuse to quash dissent.

> _Your right to protest does not include a right to occupy a public park for > an indefinite amount of time._

Actually, it does. Every one of these protesters is choosing to spend their time in this park (symbolizing something) rather than carrying about their lives. What harm is being done? Public parks aren't in short supply.

> _significant costs to the city._

Government efficiency is an anti-feature. If police save 50% doing something a certain way, that just means they'll do twice as much of it.

<comment><USER4> > > How, exactly, should LAPD have gotten those folks unlinked and removed > them?

> By waiting for them to do something they should actually be arrested for

That's not a mechanism for unlinking.

> Government efficiency is an anti-feature. If police save 50% doing something > a certain way, that just means they'll do twice as much of it.

In other words, you want to abolish govt spending. Great!

<comment><USER3> If one refuses to cooperate with an arrest it's reasonable for the police to carry out the procedure without the person's cooperation, but this is a far cry from forcing the person to cooperate through physical abuse. If one goes limp during an arrest, it's not unreasonable for the police to carry them, but it's highly unreasonable for the police to kick a person on the ground until they decide to get up of their 'own' volition.

Also, it's not my job to brainstorm ways for the police to carry out their missions, and some things will always be physically impossible for them to do. Tough. For example, it's probably impossible to read my encrypted disks. Does this mean the police, in the process of collecting evidence, should be able to beat me until I unlock them?

> _In other words, you want to abolish govt spending. Great!_

You state this as if you expect it to be incongruent with my beliefs. Honestly, the most worrisome part of OWS is seeing supposed small-government people supporting heavy-handed disruption of the protesters.

<comment><USER4> Lots of words, but you still haven't explained an acceptable-to-you means of getting them to unlink.</comment></comment></comment></comment></comment></comment></comment></comment></comment>


Ask HN: What are your biggest time savers when building a SaaS? - <AUTHOR> What are some things you do when building a SaaS that save a ton of time?
Some that I can name:
* Use a web framework
* Customize a template instead of building from scratch (wrap bootstrap)
* outsource your billing (zuroa, chargify, etc.)
What are some tricks you can use to go from idea to product in two weeks? <comment><USER2> \- Outsource authentication. Use Okta, Auth0, or the likes. Especially cheap for Enterprise SaaS apps where there will not be a lot of users.

\- Use a first-party, well-known framework for the frontend. create-react-app, vue-cli, etc. They work well and have supported upgrade paths

\- Setup a CI/CD pipeline and testing site early. This may be an upfront investment, but it will allow you to quickly iterate, have something to demonstrate, and easily launch your prod site when you're ready

\- Other things I personally like are UI Framework for the frontend, ORM with migration support for the Backend, and Swagger with automatic client library generation. There's arguments for and against each of these but they help me devolop faster

<comment><USER3> I agree writing login, forgot password, two-factor auth, change password is a huge time suck. My fear of using a 3rd party such as Auth0 for such a critical part of your application is vendor dependency. I've been bitten badly by 3rd party companies shutting down, being acquired, or abandoned.

<comment> ISO-morphism I hate to advocate for it, but AWS Cognito is _laughably cheap_ and certainly not going anywhere. Big downside is that there isn't a way to export; you'd have to list all usernames and have every user reset their password. Not really helping with vendor dependency, unfortunately.

It takes a lot of sorting through terrible docs to understand, but user pools are OpenID Connect compliant. You get canned login/mfa/forgot ui's out of the box for every platform, and it's _so cheap_.

50k MAU with Cognito: free. [1]

50k MAU with Auth0: $850/mo. [2]

[1] [https://aws.amazon.com/cognito/pricing/](https://aws.amazon.com/cognito/pricing/)

[2] [https://auth0.com/pricing](https://auth0.com/pricing)

EDIT: Thinking about this post a bit, it doesn't really address your key concern of vendor lock-in and feels like a shill. My immediate gut reaction was "who cares if you're locked in, no way can you beat the price," and that isn't very constructive. I know on an intellectual level that history has taught us a lot of things about monopolies and entrenched players, but emotionally the visible price tag elicits a strong response. Maybe someday Teddy Roosevelt will rise from his grave and save us all.

</comment></comment></comment><comment><USER4> * Use an OPINIONATED framework.

* Generate your pages server side. client side frameworks add a ton of complexity for no benefit.

* Deploy to Heroku.

* Outsource your development if you can afford to.

* Concentrate on your landing page and blog. This is how customers will find you.

* Write system tests. chrome driver or whatever your framework supports.

<comment><USER5> I know a lot of people on HN say server rendered first, but imo the difference in speed and complexity is minimal if you already know Vue/react/angular.

Really the biggest benefit of server rendered is keeping everything as a monolith but if you have to support mobile then you need to expose an API anyways

<comment><USER6> Pre-rendering techniques on all SPA is poor and will introduce a lot of complexity.

</comment></comment></comment><comment><USER7> don't be afraid to tell the client no you can't support something.

</comment><comment><USER8> Use the stack you are most proficient in, unless you are building a SaaS in order to teach yourself a new language/framework.

</comment><comment><USER9> vue is really a time saver for me. if I need to write an internal tool, I'd even use a vue based ui framework, like [https://www.iviewui.com/](https://www.iviewui.com/)</comment>


Imaginary 6502 Emulator / Assembler - <AUTHOR> http://www.mdawson.net/asm6502/6502asm.php <comment><USER2> Are there any other building blocks in the hardware platform? From the example, it looks like the machine has the full 64K of RAM, the 6502 and a framebuffer device with custom video modes.</comment>


Ask HN: Any tools to encode mp4 to stream of frames? - <AUTHOR> I don't understand video encoding/decoding algorithms. What I want is to process a video stream and parse each frame individually, either as an image or as a matrix of rgba values. Anything out there that can help me with that? <comment><USER2> If you're looking for a library to do this programmatically, try imageio (Python) or OpenCV's VideoCapture (C/C++/Python/Java). I recommend imageio - very easy to deploy, compared to OpenCV. Don't know about other languages.

</comment><comment><USER3> Here is one way to just extract the frames:

ffmpeg -i in.avi -q:v 0 imagename_%04d.jpg

</comment><comment><USER4> ImageMagick [http://www.imagemagick.org/script/index.php](http://www.imagemagick.org/script/index.php)

</comment><comment><USER5> Google h264 to raw. Yuv format is what you describe</comment>


Site Blocking: What the UK Government would prefer you not to see - <AUTHOR> http://www.tjmcintyre.com/2011/08/site-blocking-what-uk-government-would.html <comment><USER2> Funny, they don't mention that Deep Packet Inspection can be prevented by Secure Socket Layer encryption (i.e. https). Or am I missing something?

<comment><USER3> That is because Deep Packet Inspection can not be prevented with SSL:

[http://www.sonicwall.com/downloads/SonicOS_Enhanced_5.6_DPI-...](http://www.sonicwall.com/downloads/SonicOS_Enhanced_5.6_DPI- SSL_Feature_Module.pdf)

<comment><USER4> "The Client DPI-SSL deployment scenario typically is used to inspect HTTPS traffic when clients on the LAN browse content located on the WAN. In the Client DPI-SSL scenario, the SonicWALL UTM appliance typically does not own the certificates and private keys for the content it is inspecting. After the appliance performs DPI-SSL inspection, it re-writes the certificate sent by the remote server and signs this newly generated certificate with the certificate specified in the Client DPI-SSL configuration. By default, this is the SonicWALL certificate authority (CA) certificate, or a different certificate can be specified. Users should be instructed to add the certificate to their browser's trusted list to avoid certificate trust errors."

Or otherwise the SonicWALL DPI needs to sit in front of the resource being protected and have the SSL private and public keys to do the full encryption/decryption.

Either way, it is not transparent and can't just be deployed, especially if the user is wary and won't just add a new CA to his browser.</comment></comment></comment>


Branches and PRs: institutionalised distrust? - <AUTHOR> https://www.jimkinsey.com/blog/feature-branching-institutionalised-distrust <comment><USER2> I use branches and PRs when developing _solo_ , nevermind developing on a team.

It's incredibly freeing to be able to say "This branch is treated as a sandbox. The code is in flux, history is mutable." and "This (master) branch is stable. Every single commit in it is good, passes all known tests and linting, should be safe to rollback to, should be amenable to `git bisect`".

When developing on a team, even if I _can_ push directly to master, I usually shouldn't and won't. I want a second pair of eyes on that code.

Does this "process-heavy" workflow mean I distrust myself? Sure. I expect that I am human, make mistakes and oversights. I also expect that my coworkers are human, and I'm not going to trust their solo efforts any more than my own.

If branches and PRs are institutionalized distrust, well, remember that a healthy amount of distrust is good for you.

<comment><USER3> I can only agree to this.

Personally I have stopped seeing branches as part of a distrust system and PR's being some sort of gate-keeping/control mechanism. And more and more see them as a healthy self caution.

I no longer see making a PR as something for others to judge my work and disapprove of it, but more as an opening for collaboration and discussion. More of a friendly "can we look at this together so we can make it even better", as opposed to an authoritarian "I've done the best I can, I hope it meets all requirements and I don't get complaints". Of course this depends on how people view it at the other end of the line as well, and some people never change. But overall having this look at things made my life as a (open source) developer a lot less stressful.

</comment></comment><comment><USER4> With Git, creating a branch and merging into master takes mere seconds.

It's not about distrust - it's about making systems reliable. People make mistakes. Having things branched out from master means that those mistakes aren't as damaging.

Using other branches does not require you to institute onerous restrictions. I don't understand what this author is arguing against - it reminds me of a comment on another recent submission:

> In his book, The Checklist Manifesto, Gawande reports that at the end of a > big checklist pilot project for the World Health Organization (IIRC), > participating surgeons were surveyed.

> • One of the survey questions was, in essence: Would the use of checklists > improve your surgical practice? Most of the surgeons responded no. This was > consistent with the resistance that Gawande encountered: I don't need no > stinking checklist; I'm a good surgeon!

> • But the more-telling survey question was this: Would you want another > surgeon to use a checklist if operating on you or one of your family > members? Something like 93% of the surgeons surveyed responded ... yes.

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

<comment><USER3> "Pilots don't use a checklist because they are dumb, they use a checklist because they are smart".

</comment></comment><comment><USER5> There are several things wrong with this IMO.

First, branching/PRs are not automatically process-heavy. If it is for your company, there's probably something else wrong.

Second, this process—if done right—dramatically INCREASES code quality and DECREASES defects. This can be backed up with data. Code reviews, if they're not rubber stamps, are extremely valuable.

Third, the trunk-based model described in the article often leads to big-bang release branches. Master should be gold. This facilitates rapid and small releases, which directly impacts the business. This can also be backed up by data (e.g. see the Accelerate book).

Fourth, this model (again if done right), plays an instrumental role in compliance. The article doesn't even mention compliance, which is a HUGE thing bogging down a lot of companies trying to adopt DevOps practices right now. It has nothing to do with discipline or trust.

</comment><comment><USER6> I just don't think this makes its case well, though there is a case to be made.

I have worked at places where one person should _never_ have the ability to push unreviewed code into master because the company was huge and already successful and it'd be a security risk.

I have also worked with coworkers who fetishized the process part of stuff and wanted to create all sorts of rules with high overhead to solve entirely hypothetical problems from their imagination.

The hard part is differentiating the two.

</comment><comment><USER7> There's nothing holding you back from setting up a process in which developers can approve their own pull requests.

I worked with such a workflow before and it worked like a charm. You only ask for a third-party approval when you know the feature you worked on is big and might break something. It is all about trust.

The pull request interface is very good to show you all the code you worked on and review everything before committing to master.

<comment><USER8> Why require PR approval if people can do it themselves? Then it just becomes useless ceremony over allowing people to merge without approvals or PRs

<comment><USER9> PRs are a useful artifact that can trigger CI builds, provide an organized way to discuss changes, record reasoning behind multi-commit changes, etc. etc.

</comment></comment></comment><comment><USER10> Nonsense. Code review increases quality and test suites take time to run. Topic branches and PRs create parallelism and accommodate asynchronous review.

<comment><USER11> Also creates a huge backlog and a possible bottleneck in reviewing. Each process must accommodate the maturity of the team, not the other way around.

I find that trunk based works extremely well combined with pairing and/or ci/CD, it's the fastest way to deliver value if you have the checks in place (mostly good tests and review through pairing).

</comment></comment><comment><USER12> It's not about trust. It's about:

* Catching errors more quickly.

* Increasing the bus factor my having each bit of code read by at least two developers.

* Getting everybody on the same page, both by disseminating information, and by holding each other to a consistent coding style.

<comment><USER13> To me, the coordination thing is the biggest unexpected benefit.

Sure, you can do coordination offline as an asynchronous thing. But making it a blocking part of the commit process just gives you so much higher confidence that it's going to actually happen.

Though really, you're even better off if, as much as possible, you do the coordination and communication before the code review. If you have agreement on basic approach before then, you can reduce the amount of last-minute stuff to minor style changes, fixing errors, and cleanup.

Code review, as a business process, tends to push things this direction. If you don't do reviews, you might skip coordination and communication. If you do reviews, you know it's happening at some point, and it only takes a few bad experiences of having to redo all your work to clue in that maybe those discussions (which you are now definitely having) should be started earlier.

</comment></comment><comment><USER14> > "People can break the build by pushing to master without running the tests > first" \- is the problem here that people could break the build? Or is it > the lack of trust in other devs to act with professional discipline?

> To me the latter issue is much bigger. If there isn't trust and discipline > within a team, then that team is unlikely to be highly effective and may > even slide into dysfunctionality.

I trust coworkers' discipline 95% of the time, but everyone makes mistakes. Automated testing and code reviews catch bugs, and allow codebases to scale from tiny teams to large teams.

</comment><comment><USER15> The goals of branches and PR is that programmers are _inherently_ untrustworthy. Large portions of code can easily contain hidden bugs and complexity, and we've all written our fair share of code that would only ever make sense to the person who wrote it. We haven't institutionalized the distrust, we've simply formalized it.

</comment><comment><USER16> > not just pushing completed features to master, but every last _well-crafted_ > commit

(emphasis mine) If you're making "well-crafted" commits, you're staging them somewhere. If it's not on a branch, then it's not sharable - but it's still HAPPENING.

</comment><comment><USER17> This is nonsense, and comes across as exactly the case the author is talking about, a solution (no branches and PR's) looking for a problem (It must be trust, who can argue against increasing trust in the team). In our team, we have a huge amount of mutual trust and respect. We still PR, because it catches issues early, and improves overall quality.

</comment><comment><USER18> I wonder if he actually tried it. I always thought the same about PR's for internal process, until I actually tried it. It made working with feature branches much more convenient.

I mainly use it to test if features meet their functional description before merging, but also reviewing the code at the same time does help to spot subtle misunderstandings in the requirements.

I also disagree that it would hold back development of inexperienced members of the team. Having the structure with PRs allows them to work on things that they otherwise may not have been trusted with yet to work on at all.

</comment><comment><USER19> > If there isn't trust and discipline within a team, then that team is > unlikely to be highly effective and may even slide into dysfunctionality.

> building a process into a team which signifies a lack of trust is unlikely > to ever improve matters

This is one of those "I can't help fix problems because you're just hopeless if you have problems, but I can make perfect better" articles that come up time to time about why you should use X (that nobody does in practice, or not for very long).

</comment><comment><USER20> > The introduction of controlling processes is often a way of consolidating > power structures or building them from scratch for later (ab)use - and I > would always question people's motives in these cases. In such highly > bureaucratic hierarchies, those on the lower levels often feel absolved of > responsibility and that is not likely to end well, either.

This is a really great insight, and I'm glad I read the article twice, because on the whole, I think it's a bit hysterical.

</comment><comment><USER21> Normal brain: commit directly to master.

Expanding brain: give up distributed version control entirely.

Galaxy brain: write directly to the deployment server.

</comment><comment><USER22> Yes, they are a giant waste of time and in general slow things down and don't improve your ability to add more features over time. Bigger win from having good tests and properly factored code encourage by shared owership (no disincentives to change any code you see fit)

<comment><USER23> Depends on the team. Sometimes they're great, sometimes people just start rubber-stamping the reviews because of time pressures, laziness, or lack of familiarity with the code.

Right now, I'm on a team of 3. 2 embedded devs and 1 web dev. The web dev keeps asking me to PR their web framework changes, but I'm not a web guy. The other embedded dev has ADHD and can only rubberstamp my reviews. Basically I'm just wasting time complying with the branch/PR/merge/tag cycle.

<comment><USER2> I've had a similar problem in the past. The things I've found to be very helpful are:

1) Don't look at the PR diff as a whole, look at individual commits, and judge each one, then read the PR diff.

2) If the commits are too big to keep in your head, don't make individual sense, etc., ask your coworker to rewrite their history until you can do 1)

2b) If the individual commits make sense, but the PR still is too big to comprehend, this PR should probably be split into multiple smaller PRs which can be reviewed, approved, and released individually (or at least in sequence).

3) If you lack still lack enough context to make a good review, ask your coworker to walk you through the commit, and just explain out loud why they're making the changes they're making. Sometimes, a "rubber-duck code review" is enough. Even if it's not, any programmer can read and understand a single line of code at a time, and you can likely tell if that line of code is complex or elegant.

Plus, even if you don't know the full technical context of a proposed change, people are fairly good at picking up whether another person has an explanation that makes sense, or if they seem to be making it up as they go.

4) Spend the time and do the reviews, and become more familiar with that part of the code. It sounds like right now, that part of the code has a bus factor of 1.

5) Track time spent doing code reviews, and track bugs caught during code review. Code review has notable benefits for your team/company, so justify and sell that. You have fewer bugs & a better bus factor. When estimating your next sprint (or other unit of work), know that you'll spend X hours per week doing code review, and integrate that.

<comment><USER22> I hear you, I'm just one of those pair programming zealots now. Whenever we work with clients who insist on PR workflow eventually we just bury them in PRs and it basically slows velocity to a crawl until we sort out the ownership and start committing to master and get proper piplined ci in place. Or we work with folks who have historically done PRs and think they are helping code quality but everything is a mess because there's so much resistance to refactoring as part of normal work. No one wants to accept massive changes in PRs.</comment></comment></comment></comment>


Ask HN: Not looking to change job, 2 potential opportunities, how to leverage? - <AUTHOR> I'm currently happy with my current position in an engineering role. I've got great working conditions and still motivated by my day-to-day tasks. The future also looks bright for the company.
I'm however getting e-mails from past colleagues (in 2 different companies) to talk about opportunities. I think these could easily work if I wanted to go through the process. I was wondering what would be the best way to leverage these to improve my current conditions e.g. compensation?
Thank you! <comment><USER2> I've done this: you interview with the other companies and negotiate a good offer — the best you can — and then see if your current employer will match or beat it. Easy.</comment>


The Loophole in the Hedonic Treadmill - <AUTHOR> http://nautil.us//blog/-the-loophole-in-the-hedonic-treadmill?utm_source=Nautilus&utm_campaign=67a999dd57-EMAIL_CAMPAIGN_2017_04_28&utm_medium=email&utm_term=0_dc96ec7a9d-67a999dd57-60565561 <comment><USER2> It reads like an elaborate sponsored piece for plastic surgery. Even if it focuses on plastic surgery, it does not provide any details on the types of plastic surgery.</comment>


Final draft of R7RS – small Scheme standard - <AUTHOR> http://lists.scheme-reports.org/pipermail/scheme-reports/2013-July/003660.html <comment><USER2> you may also want to see john cowan's presentation on R7RS-small last year to LispNYC: [https://vimeo.com/29391029](https://vimeo.com/29391029)

</comment><comment><USER3> I'm new to LISP (only a little over a year) but I already feel the same way about R*RS as I do about ANSI SQL: You'd be crazy to target it instead of making the most of the runtime you've chosen.

Has anyone here ever deployed to multiple runtimes? Why did you do it? I'm curious.

<comment><USER4> E.g. libraries that can be implemented in pure Scheme should arguably target R*RS rather than any particular implementation, to save on reimplementation efforts.

</comment></comment><comment><USER5> Does anyone have any idea what the overall plan for Scheme is?

From what I understand R7RS small is aimed at being closer to R5RS while avoiding the controversial things introduced by R6RS.

But what about R7RS large? What are the overall aims of that? Has that been decided yet?

<comment><USER6> My understanding is that would be R8RS, and would be a continuation of R6RS. They seem to be doing the tick tock sort of model of alternating focuses for "releases".

<comment><USER5> Thanks - in fact bgruber's video link above [1] about R7RS-small also includes a section about R7RS-large too. I hadn't seen the video when I asked my question. Basically another working group will work out the details at a later date and it will be much larger - about 80 packages and probably bigger than Common Lisp according to the video.

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

</comment></comment></comment><comment><USER7> Is anyone here planning an implementation ?

<comment> muuh-gnu It is the Scmeme way: You'll quickly see half a dozen of different and incompatible implementations, but not a single newsworthy project on top of them. And soon after that, they will get bored and start yet another cycle of speciation.

<comment><USER8> The goal of the R7 is to avoid this. You could read the article and the spec before saying sneaky comments like this.

<comment> muuh-gnu It was R6's goal also. But it didnt accomplish the stated goal but just introduced more incompatibility into the overall Scheme ecosystem. But instead letting all implementations at least get up to R6, they now have R7 on the horizon. They afre churning standards out more quickly as implementors can implement them.

And frankly, I dont see what the point will be: R7 small is not much differrent than R5, so it is kind of pointless. R7 big is as big as common lisp, and very few implementations will have the resources and the willingness to implement it and discard their current non-standard APIs they had for years. And even if the majority of them manages to implement R7, they will finally reach the point where Common LIsp was 1994, with no added value over Common Lisp, provided of course they dont decide to obsolete R7 also and get to R8 before that.

<comment><USER9> So R6 is bad because it's a big departure from R5 but R7-small is bad because it doesn't change much?

The point of R7 is to make it is easy for implementation to upgrade from R5 after the controversial R6.

Ideally, most of the libraries in R7-big will be able to be written mostly in R7-small. If they are smart, they'll make a R7-big FFI library, and then every other library can be written in R7 + C.

This means an implementation would only need to implement R7-small and would get all the libraries of R7-big for free.

</comment></comment></comment></comment></comment><comment><USER10> Can someone familiar with the process explain where this lies in the standardization process?

Does "final draft" mean this is the official R7RS-small standard, does it mean this is the final text being sent to the steering committee for endorsement, or does it mean something else entirely?

<comment><AUTHOR> _this is the final text being sent to the steering committee for endorsement_

I think that is correct. The Working Group had put up draft 9 for public vote, which (narrowly) made the 85% ratification requirement set by their charter. There was a final objection made by Gerald Jay Sussman, whose opinion carries a lot of weight when it comes to Scheme... The WG voted unanimously for a change that addressed his concerns, and the Steering Committee approved the making of this change, after which we had this tenth draft. I do believe the WG is done with it. Therefore it seems basically set in stone, unless the Steering Committee edits it, which seems to me outside the scope of what they do (although I don't feel I completely understand how this works).

</comment></comment><comment><USER11> Can someone sum up the major changes?

<comment><USER6> Don't think of 7 as being after 6. It is more of a continuation of 5, a smaller standard with fewer bells and whistles. Due to this, a summary of major changes may not be appropriate.

<comment><USER12> I thought it was going to have a small and large version within it?

</comment></comment></comment><comment><USER13> This is very exciting!</comment>


The Most Popular Course at Harvard - <AUTHOR> http://qz.com/123705/the-most-popular-courses-at-harvard/

<comment><USER2> My two regrets from college are not taking a programming class nor spending any additional time in statistics. Now I am trying to teach both to myself. As a 33 year old with a young child, doing everything I want to do now is becoming harder and harder.</comment>


QbQbQb, my cutting edge html5 game is out - <AUTHOR> http://qbqbqb.rezoner.net

<comment><USER2> This is freaking awesome.... I love the music... also the gameplay too.. nice idea! :D</comment>


The technical story of Muxtape - <AUTHOR> http://tlvx.net/post/74143734/the-technical-story-of-muxtape <comment><USER2> This is cool. I'd love to see more stories like this, a coder talks about what he does, instead the linkbait submissions that are taking over HN recently.

</comment><comment><USER3> I'm kinda fed up with the idea PHP = beginner's stuff don't touch it (as I am a PHP developper).

True it is a very permissive language with a bunch of awkwardnesses, but that's the main point of using it.

Building something with a tiny LAMP stack is done in seconds, which can then be extended into something huge (think Facebook or Flickr). It's very extensible, you can add any stuff you like (frameworks, ...). Basically it's as if you start with a blank sheet of paper and decide where you want to go.

I don't know many programming languages allowing this.

</comment><comment><USER4> In a sentence, he loved Rails, joined Muxtape despite it being written in PHP cause he believed in it, felt unproductive and missed Rails, so he took a day to rewrite in Rails.

<comment><USER5> it does seem a little backhanded to have rewritten the app in ruby and then passively alter opinion to use ruby. maybe that's better than aggressively trying to alter opinion?

one of the first django teams i was on after college had a guy who frustratedly rewrote our work in ruby. the rest of us were new to python, django and web apps in general, while he was more experienced, so he kind of missed the whole point about learning, mentoring and team work versus getting frustrated and wasting time.

this was a different situation, and is also just an anecdote. nonetheless, i couldn't help but cringe when i heard he'd rewritten the app in ruby without first consulting the team, even if just to say--look, i'm going to do this in my spare time as a learning experiment. i'll check in before it gets out. i appreciate ya'll's support.

</comment></comment><comment><USER6> Jeez that freaking floating picture sucks.

<comment><USER7> Firebug -> Inspect -> Click on freaking floating picture

Console -> $1.style.display="none"

<comment><USER8> Another method:

Right-click picture, "Inspect Element"

Firebug expands

Right-click highlighted img element, "Delete Element"

</comment></comment></comment><comment><USER9> He is talking about a site that it took one person one day to rewrite. Then he writes:

'''Ruby's inheritance, metaprogramming, flexible mixins, and testing culture support a fantastically granular ecosystem of encapsulatable, interchangeable, combinable tools.'''

This doesn't sound very convincing.

</comment><comment><USER10> I would like to see his one line of ruby that replaces 20 lines of php. I am not saying that it is not possible but I am pretty sure that is more about abstraction than anything.

</comment><comment><USER11> Technical story? Well here it is: "I ported this small, simple band site from PHP to Rails in a day. My co-developers (this site has more than one?!) didn't understand at first but I brought them round".

I don't get this site Muxtape.com. I've seen it mentioned here a few times but I don't understand why it's "favoured".

It looks like a super-simple site where a few bands have uploaded some pictures and a couple of songs, which can be played by a flash player. Well, that's neat and all, I like the minimalist design, and mootools rocks, but, you know .. and?

I kept looking for some kind of advanced functionality. Since the domain name kind of sounds like "mixtape" I was clicking on the songs and trying to, you know, mix them. Nope - one at a time. Right. So where's the beef?

The guy says he ported to Ruby in one day, and I can believe that, since the DB design was already done and it looks like most of the work is in the layout and JS which could be just copied over into Rails.

So, can anyone enlighten me as to how this site, while nice for what it is, is special in some way such that "hackers" would care about its implementation especially?

<comment><USER12> Read <http://muxtape.com/story> to get a little more background.

<comment><USER11> Ah. Thanks for the link, I get the relevance now. Quite a sobering tale.</comment></comment></comment>


Sony Promises VR Music Video, Other Entertainment Content - <AUTHOR> http://www.billboard.com/biz/articles/news/digital-and-mobile/7504876/sony-promises-vr-music-video-other-entertainment <comment><AUTHOR> Found via Billboard Biz but it's an AP story; not intending to dupe or blog spam. Figured subject is of interest overall.</comment>


Segment Open Fellowship 2017 - <AUTHOR> https://segment.com/blog/segment-open-fellowship-2017/ <comment><AUTHOR> I wonder if Stripe is going to do one again this year: [https://stripe.com/blog/open-source- retreat-2016](https://stripe.com/blog/open-source-retreat-2016)

</comment><comment><USER2> This is very cool, I hope all those selected find success, and major props to segment for giving back to the FOSS community.</comment>


Software Engineering at Google (2017) - <AUTHOR> https://arxiv.org/abs/1702.01715 <comment><USER3> Buried in the "2.11 Frequent rewrites" section, but a great hack for "productivity via a sense of ownership":

 _" In addition, rewriting code is a way of transferring knowledge and a sense of ownership to newer team members. This sense of ownership is crucial for productivity: engineers naturally put more effort into developing features and fixing problems in code that they feel is "theirs"."_

<comment><USER4> If you have engineers with physiological problem of "not invented here", you have a very serious issue. I am currently seeing this in real time in one of the projects and I was told _almost exact_ same words as "reason" to recreate what we already have and working beautifully. It was clear to me that some developers are just too lazy to dive in to complex system. They get ticked off by one imperfection here and other over there and immediately run for exit shouting "I could do so much better". Instead of understanding why things are the way it is, they fantasize about how they can one up original authors and claim their own hero title. They go on to throughly underestimate the time to recreate what has taken years of learning. So they spend next many months sweating out, copy as much code from "old" stuff as they can, dropping important feature here and there, adding new and old bugs - very often arriving at more or less same place they started off. Meanwhile competition has moved on to V2 laughing their way to the bank and customers scratch their heads why you are still stuck in same place for so long. Then our new "owners" gets their promos after massive marketing of how much better everything is now. But to everyone's surprise they soon leave the project because working on bugs and incremental features has became boring and BTW, the new stuff is just as complex as old stuff. New devs roll in and we start the whole cycle again.

<comment><USER5> You can call it a psychological problem if you want but calling names is not a solution, nor does it really provide a good path to finding a solution. The labor market being what it is, people will leave steady jobs with good pay for more exciting work with riskier prospects and less pay. This happens _all the time._

Bug fixes and incremental features will generally not get you promoted for good reasons, we expect senior engineers to have system design skills and there is simply no way to demonstrate that without having your engineers design systems. If you only assign tasks based on the needs of your product and not on the needs of your workforce you could easily find yourself with a critical skill shortage.

There's a certain inefficiency to this, but only if you put your blinders on. If you have engineers churning out meaningless work then you certainly need to address that problem, but if you prioritize short-term product success over team health you are only trading one problem for another.

<comment><USER6> > Bug fixes and incremental features will generally not get you promoted for > good reasons.

This is exceptionally bad, but sadly true.

If you have an engineer who can unblock teams and fix issues in an hour that others take a week or cannot fix at all, they are gonna jump ship if they can't be recognized.

At that point you've lost a valuable resource.

<comment><USER7> Recognition is stupidly cheap.

If I can do that without it being a fluke, they'd better bump my salary.

<comment><USER8> Would you settle for a certificate?

<comment><USER9> My landlord doesnt take certificates.

</comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> What I don't understand is how they accomplish larger collaborative changes. The paper says:

 _" Almost all development occurs at the 'head' of the repository, not on branches."_

Googler Rachel Potvin made an even stronger statement in her presentation about _" The Motivation for a Monolithic Codebase"_ [1]:

 _" Branching for development at Google is exceedingly rare [..]"_

In the related ACM paper she published with Josh Levenberg there is the statement that:

 _" Development on branches is unusual and not well supported at Google, though branches are typically used for releases."_

I my world when we have to make a bigger change we create a branch and only merge it into the trunk when it is good enough to be integrated. The branch enables us to work on that change together. I don't understand how they do this at google. As far as I understand in their model they either have to

\- give up on collaboration and always have just a single developer work on a change.

\- share code by other means.

\- check in unfinished work to the trunk for collaboration and constantly break trunk.

[1] [https://youtu.be/W71BTkUbdqE?t=904](https://youtu.be/W71BTkUbdqE?t=904)

[2] [https://cacm.acm.org/magazines/2016/7/204032-why-google- stor...](https://cacm.acm.org/magazines/2016/7/204032-why-google-stores- billions-of-lines-of-code-in-a-single-repository/fulltext#)

<comment><USER10> I think they don't branch code because perforce branches are horrible and merging them back to HEAD is extremely painful process for monorep.

<comment><USER11> So, use a better tool?

<comment><USER12> Or, don't branch. Is branching so essential?

<comment><USER13> Isn't it essential for mental organisation? How do you think about what's different about a set of changes without some sort of DAG?

<comment> yjftsjthsd-h Just do one thing at a time? Today, I am working on X; my commits are for X, and details are in the commit message.

<comment><USER14> That breaks as soon as you have to interrupt working on Nice To Have Feature X to working on Inportant Bugfix/CVE Y.

<comment><USER15> How often does that happen to an individual developer though?

Once a month? In an averagely well run company even that may be towards the higher end.

Should your entire development strategy be based on a once a month occurrence?

<comment><USER16> > Once a month?

Closer to once a week for me.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> So, the thing that is still buzzing in my head now and not mentioned in the article (maybe I didn't read carefully enough), what actually gets released into prod after a change is reviewed and merged.

If the monorep contains let's say five different products and in a day only one of them gets a merge, then Blaze still builds all five and all five are released (based on successful integration testing)? OR only releases the changed product (and any other ones which depended on the changed one)

EDIT: Also, the "canary" server is still for testing ? There may exist practically a set of canaries running very different versions ? Is there any correlation or any version "roll-up" constraints between various canaries ?

<comment><USER18> Like kyrra said. Releases are handled by independently by each team. Teams are in various states of maturity in relation to their release practices. Some are fully automated. Some involve manual QA. I've supported teams across that continuum as a SETI at Google.

I'm not as well-versed in canarying though I've set it up for a team or two. I've only ever seen a single canary version for any particular binary.

Canarying is done. I haven't seen canaries running multiple versions of the same binary. Though teams will often guard new behavior behind experiment flags.

<comment><USER17> Thanks for all replys above (Kyrra, Joshuamorton and ASinclair), these have been very helpful.

</comment></comment></comment><comment><USER19> The protocol buffers stuff seems pretty cool. At my last job (small web dev shop), we had constant headaches over the class definitions of endpoints changing and some js file not having its model updated to correspond. I thought we should be writing XML files that both ends could be reading in - <USER2> never got up the political will to make that big change though.

[https://developers.google.com/protocol- buffers/](https://developers.google.com/protocol-buffers/)

<comment><USER20> Yep, protocol buffers are like a cross-language type system for the data that moves between systems with the side benefit of compact serialization. They're awesome and definitely a big productivity boost above a certain scale.

<comment><USER19> Something like this would have indeed saved us a lot of time in the long run. Oh well.

</comment></comment></comment><comment><USER21> I was the maintainer of a third-party library used by thousands of dependent applications at Google. I have to admit, I still have not seen on the outside a system that allows me to change the version of numpy, and know that thousands of dependent applications either work or break, within an hour of making my change.

Being able to write and use a mapreduce with a high level of confidence that my code would continue to work years later was another nice benefit. MRs I wrote in the first year at Google still compiled and ran with minimal changes almost 10 years later(!) which is amazing given the amount of environmental change that occurred.

That said, somebody could still halt development across the company by changing and checking in a core file (like proto defs for websearch) without testing.

Whatever social system led to google3/borg and the amazing productivity associated with it, it was a special moment that hasn't been replicated many times.

<comment><USER22> People who like multirepos are always saying how easy it is to pin dependencies but like you I haven't seen anyone doing it right since I left Google. The monorepo third-party system works well in practice.

Ps thanks for getting scipy into third_party all those years ago.

<comment><USER23> > The monorepo third-party system works well in practice.

It's worth noting that this is only viable at Google because they don't use git. Git's insistence on every client having a full copy of all history of every file in the repository makes monorepo _much_ more expensive.

I see conflicting reports over whether google use Perforce or something proprietary called "piper"?

<comment><USER21> I used a git wrapper for google3 repo. It wasn't great. There are a number of semantic differences between piper/perforce and git that made it awkward. Especially code review- git doesn't handle code review well (I still find this to be an issue with github and other sites that have code review). but it was not an officially supported solution and I believe the replacement for it is based on another DVCS, Mercurial, for some silly software engineering reasons I don't like.

<comment><USER22> I used the git wrapper for a few days until I hit a day-ending `git gc`. That's when I knew git was terrible.

</comment></comment></comment></comment></comment><comment><USER24> Previous discussion: [https://news.ycombinator.com/item?id=13619378](https://news.ycombinator.com/item?id=13619378)

</comment><comment><USER25> "Individuals and teams at Google are required to explicitly document their goals and to assess their progress towards these goals"

This seems attractive for other large organizations. Any positive or negative experiences from readers?

<comment><USER26> My experience is that the difference in raises between an employee that got an "Exceeds Expectations" and one that "Meets Expectations" isn't significant enough to be worth wasting the time worrying about it.

The best way to make more money is to change jobs. Google may be different.

<comment><USER27> Well, if you exceed expectations, doesn't that mean you didn't set your goals high enough?

<comment><USER28> At Google you are expected to exceed expectations.

But seriously, you are evaluated against the role description (software eng? product mgmt?) and your level. If you exceed expectations consistently over several review cycles, you are encouraged to apply for a promotion.

The goal is to get you promoted into a role and level where you can consistently meet expectations.

<comment><USER29> Ahh the Peter Principle. [https://en.wikipedia.org/wiki/Peter_principle](https://en.wikipedia.org/wiki/Peter_principle)

<comment><USER30> Specifically the opposite. The peter principle implies you'll make it to a point where you flounder and can't manage. This is the opposite: You make it to a position where you do well, but aren't spectacular (compared to your peers in the same position).

Roles/levels are calibrated so that expectations at L+1 are generally speaking aligned with strong performance at L.

</comment></comment></comment></comment></comment></comment><comment><USER31> I used to be proud of many things in the article when working at the G.

Not anymore. Let me talk startup anti-Google pattern here.

* Most of Google's code is stored in a single unified source-code repository, and is accessible to all software engineers at Google

This can be the worst nightmare from a management POV in a startup. Sure it sounds wonderful everyone can see/fix anyone else code but 99% people shouldn't have time to do so (if they do their work load is not full, increase the load). The 1% I guarantee all your codebase has just been stolen by an ex- employee with malicious attempt. Instead divide your codebase into different projects/roles and people only gain access when needed.

* Software engineers at Google are strongly encouraged to program in one of five officially-approved programming languages at Google: C++, Java, Python, Go, or JavaScript.

We use Go for backend programing and vue (javascript) for frontend. Don't use Java if possible, keep away from C++ and definitely never Python which is a maintenance nightmare.

* The next step is to usually roll out to one or more "canary" servers that are processing a subset of the live production traffic.

Not necessary when your misery not-product-market-fit-yet website only gets 100 users. Just roll-the-f-out , let it break and fix later. Building the canary system is a huge overkill in the early stage.

* All changes to the main source code repository MUST be reviewed by at least one other engineer.

Same as above. Just build and RTFO.

<comment><USER32> > Not necessary when your misery not-product-market-fit-yet website only gets > 100 users. Just roll-the-f-out , let it break and fix later. Building the > canary system is a huge overkill in the early stage.

Being a startup does not excuse this kind of cavalier attitude

<comment><USER31> When you face life-or-death scenarios everyday as a startup founder.

Not a single startup was killed by software bugs or design faults. Never. Many other things do.

</comment></comment></comment><comment><USER33> I'm curious to learn more about Google's approach to project planning and management, beyond OKRs for personal or team goals.

Do all teams use the same standard process or are teams allowed to do their own thing? What tools and cadence do they use to track project milestones and progress? With Google's monorepo and a centralized bug tracker, they could make some nice project dashboards.

<comment><USER34> Each team does their own thing. There's some project management tools that are popular, but no Google-wide standard.

</comment></comment><comment><USER35> Not worth a long discussion, but is the Blaze build system they are referring to in fact Bazel?

<comment><USER36> Yes. Blaze is the name of the binary inside Google. 90% of the code is in common. Differences are 1. integration with Google-internal tools, and 2. legacy misfeatures we plan to remove.

(I work on Bazel)

<comment><USER37> What kind of internal integrations, if I may ask? Does it automatically deploy code for you on a successful build or something like that?

<comment><USER38> For example, blaze has integration with Google's build cache. Most of the time it takes 0 seconds to compile a given file, when someone else has compiled it before with the exactly same contents, dependencies and compiler flags.

</comment></comment></comment></comment><comment><USER39> Page 17 - "any employee can nominate any other employee for a 'peer bonus' \- a cash bonus of $100 - up to twice a year..."

Is there a hard cap/limit on this policy now? I might have to take the rap for that, having peer bonus'd my entire office on my last day there back in 2012. My bad.

<comment><USER30> I think that's "you can nominate a specific other person twice a year". There's a soft cap on how many people you can nominate per year period, but its pretty high.

</comment></comment><comment><USER40> Other than the 20 percent free time, compensation and offices, the engineering culture at Google doesn't seem to have anything special based on this well written pdf. It is in fact very similar to other large tech companies. Just in case you were still wondering what really attracts great engineers.

<comment><USER41> I think it attracts a lot of great engineers that they can (mostly) work on something which is used by billions of users. You can basically improve the life of 1B ppl by writing code.

Also: having a FAANG company in your CV makes it super easy join any other tech company.

<comment><USER40> Reality is that most of the engineers at Google don't work on google search nor google map. They work on "smaller" projects that don't necessarily reach billions of users. It doesn't change the fact that everything has to be engineered in order to work for a large amount of users, true, but do you really get that reach? nope unless you're in a very hot and selective team at G.

Also, your statement is valid for companies like Facebook, Uber, Apple, Amazon, etc. It is not a valid argument anymore in my opinion. But I totally get your point.

<comment><USER42> Google has 7 products with 1+ billion users.[1]

1\. [https://www.popsci.com/google-has-7-products- with-1-billion-...](https://www.popsci.com/google-has-7-products- with-1-billion-users)

<comment><USER40> Now let's look at the ration billion-user-products versus the total number of products. That'll give you the ration of employees having a huge impact:

[https://en.wikipedia.org/wiki/List_of_Google_products](https://en.wikipedia.org/wiki/List_of_Google_products)

And we're not even looking at the number of active users per product versus the total amount of gmail ID's enabled for all google products by default (e.g. Google+)

<comment><USER42> > Now let's look at the ration billion-user-products versus the total number > of products. That'll give you the ration of employees having a huge impact

That logic doesn't make any sense. No company allocates staff equally to all their products. More popular products (or higher revenue-generating products) are always better-staffed than less popular products.

<comment><USER40> You can't say "always". This doesn't make sense either because it's on a case by case basis. You could have a simple product used by billions of people, which doesn't require many devs, or you could have a complicated infrastructure no one knows about that gets billions of requests from 10 other products per day. This could be handled by an army of engineers.

Is your hot product in a maintenance mode? If so, just a few devs can handle it.

Then you have companies with groups like retail, legal, hardware, etc. They require tones of software engineers to build internal tools. They definitely don't reach billions of users and you see a lot of these teams. What I found out while working at some of the Faang's is that the hottest teams are usually very lean. You'd be surprised how one single rock star engineer can handle. When you start having +10k engineers in your company, only a minority of folks will end up working on the hot stuff.

</comment></comment></comment></comment></comment></comment></comment><comment><USER43> I opened this document expecting to have my mind expanded by learning about amazing new techniques for high-level software engineering. I was disappointed. A lot of it just seems to be about release engineering. Yeah, sure, release engineering is really hard and important for a company like Google, but it's of limited general interest. I was particularly disappointed by Google's indifference to the use of smarter languages than the Big 5 (C++, Java, Python, etc).

As an example of something that _did_ expand my repertoire as a software engineer, check out this article by Jane Street: [https://blog.janestreet.com/testing-with- expectations/](https://blog.janestreet.com/testing-with-expectations/)

</comment><comment><USER44> Software developers that can't work with code they didn't write themselves are not skilled Software developers.

</comment><comment><USER45> >>Most software at Google gets rewritten every few years.

>> This may seem incredibly costly. Indeed, it does consume a large fraction of Google's resources. However, it also has some crucial benefits that are key to Google's agility and long-term success.

Uh... No? Chrome, gmail, search, youtube, analytics, android, documents all usually have 2 or 3% functionality changes each year. What a ludicrous proposition stated so matter-of-factly.

<comment><USER46> Is it possible most software at Google is not Chrome, Gmail, Search, Youtube, Analytics, Android or Documents?

Also do you work at Google? If you don't, you might not be able to perceive all the changes to those applications on the backend. The user interface may change at a more constrained pace, but it can still be true that most backend code is in a constant state of revision.

For example, what defines "Search" in your example? The google.com search interface rarely changes (logo notwithstanding), but what do we have to go on for how often search infrastructure or processing code changes?

<comment><USER45> Let me be clear (and I don't work at google). I'm not saying google doesn't spend a lot of engineering time doing rewrites. I'm saying if google DOES spend a lot of the engineering time of its 20,000 engineers doing rewrites that is BAD by all measures.

Maybe it would explain how a company with 1,000 startups worth of "top-talent" engineers could not produce any new functionality in the last 5 years though (small exception of AI)

<comment><USER47> This is a good point worth exploring. If google has 1000 startups worth of talent (which is another point worthdiscussing) the corporate structure has clearly slowed down new functionality or new product ideas. It seems like it is 1000 times harder at google which levels the playing field.

</comment></comment></comment></comment><comment><USER48> Where's Dart?

</comment><comment><USER49> This all looks nice and perfect, but what's the catch ?

<comment><USER50> That at the end of the day, this is all controlled and used by human beings, who are notoriously known for sometimes being mean and selfish?

Examples: the 80/20% project work that is described is a really good idea IMHO, however if somebody choses to work 50/50 in a period, becuase that person is "almost finished and longing to present it", then it might turn into a problem for the team leader and the employee.

Software sometimes fails, even highly sophisticated build automation.

Rewriting software may introduce a sense of ownership to employees, but it may also lower the quality of the code that is being rewritten - worst case to the extend that the code needs another rewriting to even function as intended.

...but why let yourself get blocked by the negatives, instead of being inspired by the positive?

</comment></comment><comment><USER51> Which part discusses what Does with your IP when you're not sitting in the office?</comment>


Is Summer Different Now? - <AUTHOR> http://www.nytimes.com/2014/08/17/upshot/is-summer-different-now.html <comment><USER2> Honest question, has there ever been a generation that experienced youth the same as the generation before them?

<comment><USER3> I'm sure it was fairly constant pre-industrial revolution, but maybe change is just accelerating over time.

<comment><USER4> No. Rivers changed courses. The levels of rain fluctuated. The levels other important resources fluctuated, namely those like animals, trees, and other raw materials that pre-industrial societies relied on.

The environment is fundamentally in flux.

<comment><USER5> That doesn't change youths very much.

</comment></comment></comment></comment><comment><USER6> It is for many.

More employers are parsimonious with vacation time, so no summer trips. Moms work now. Thus many kids go to daycare, but we call it camp.

I envy my friends who are teachers married to teachers. I would love to spend my summers with my wife and son!

</comment><comment><USER7> My Dad, who is still alive, kept a diary of growing up during the Dust Bowl in US midwest. Unfortunately, that diary is lost. But those days of dust and drought, growing up on a farm during the Great Depression, and later going to war in the South Pacific and coming back and then working as a civil rights worker left an indelible mark on him.

He really enjoyed a book I gave him recently, Bill Bryson's "One Summer -- America, 1927". He says that it brings back many memories.

</comment><comment><USER8> I went to day camp in the 1960s.</comment>


Parallel Locality Sensitive Hashing - <AUTHOR> http://istc-bigdata.org/plsh/ <comment><USER2> I've been trying for weeks now to get a system running that can handle larger than RAM datasets and returns queries in an acceptable time. It's running ok now but far from optimal (size of DB is ~100 GB and it contains a few hundred million entries).

Does anyone here have experience with any implementations (such as likelike, lshkit, etc.) and can recommend something that can handle larger sets? All the implementations I have found were either not maintained, old, not running or not suitable for production use.

Will definitely take a look at the paper but unfortunately it's always a very long way from here to an actual implementation (there is no code published as far as I could see).

<comment><AUTHOR> Google's simhash paper shows how to do 8 billion 64bit fingerprints in memory:

Detecting Near-Duplicates for Web Crawling ([http://www.wwwconference.org/www2007/papers/paper215.pdf](http://www.wwwconference.org/www2007/papers/paper215.pdf))

SEOMoz has in-memory and db-backed implementations of simhash in Python ([https://github.com/seomoz?query=simhash](https://github.com/seomoz?query=simhash))

<comment><USER3> Simhash is indeed wicked fast.

Unfortunately, it's also encumbered by a patent: [http://www.google.com/patents/US7158961](http://www.google.com/patents/US7158961)

</comment></comment></comment><comment><USER4> That's crazy, I was just diving into the nilsimsa LSH utility ([http://ixazon.dynip.com/~cmeclax/nilsimsa.html](http://ixazon.dynip.com/~cmeclax/nilsimsa.html)) code when I decided to take a HN break, and boom! LSH news.

Cool.

<comment><USER5> This is the first time I've heard of nilsimsa. Looking through the docs to find the algorithm, here's how it is described, but I'm still not clear on what a "character separation" is in this context or which 3 characters are chosen:

> Nilsimsa uses eight sets of character separations (character, character, > etc.) and takes the three characters and performs a computation on them: > (((tran[((a)+(n))&255]^tran[(b)]*((n)+(n)+1))+tran[(c)^tran[n]])&255), where > a, b, and c are the characters, n is 0-7 indicating which separation, and > tran is a permutation of [0-255]. The result is a byte, and nilsimsa throws > all these bytes from all eight separations into one histogram and encodes > the histogram.

I've found that in practice, shingling text and then minhashing it is scary- good at finding similar documents.

</comment></comment><comment><AUTHOR> This is the paper linked to at the bottom...

"Streaming Similarity Search over one Billion Tweets using Parallel Locality- Sensitive Hashing" ([http://istc- bigdata.org/plsh/docs/plsh_paper.pdf](http://istc- bigdata.org/plsh/docs/plsh_paper.pdf))

</comment><comment><USER6> For some context, locality sensitive hashing is handy for quickly finding "similar" data points in high-dimensional space. This comes up a lot in collaborative filtering and recommendation problems (find similar products to hawk at your customers) and topic modeling (find similar text that is semantically getting at the same thing).</comment>