Sonalight (YC W12) Lets You Text While Driving Without Touching A Phone - <AUTHOR> http://techcrunch.com/2012/03/08/sonalight-lets-android-users-text-while-driving-without-touching-a-phone/

<comment><USER4> Haven't studies shown that it's not the physical act of interacting with a phone that causes distraction, but rather focusing on conversing with someone not physically present?

<comment><USER5> I dunno about studies, but for me it's definitely the eyes-not-on-the-road. I'm so thankful I haven't gotten into a crash despite the few times I've been stupid enough to text while driving.

<comment><USER6> [http://www.nsc.org/safety_road/Distracted_Driving/Pages/Cogn...](http://www.nsc.org/safety_road/Distracted_Driving/Pages/CognitiveDistraction.aspx)

"While many people know texting while driving increases crash risk, the lack of understanding about the risks of phone conversation while driving remains a challenge. Talking on hands-free or handheld cell phones requires the brain to multitask – a process it cannot do safely while driving."

</comment></comment></comment><comment><USER7> I was watching PG's interview on Bloomberg yesterday on he said that most YC startups choose to develop on iOS first then port it to Android. (I can't remember if he said he advises startups to do iOS first before Android).

My guess is this is cannot be easily done on iOS.

Android's API has been more open than iOS.

<comment><AUTHOR> We did choose to start with Android because it has more powerful APIs. We don't want to cut out half of the smartphone market though, so we'll get once we're happy with Android we'll move onto iOS.

<comment><USER8> The upside to Android is you can push fixes to market in a matter of hours - so you can iterate faster and worry less about accidentally pushing crippling bugs.

<comment><AUTHOR> This is absolutely correct and I had forgotten about this huge advantage until you just mentioned it. We've been on a very aggressive release schedule, pushing major overhauls to the app every 2 weeks since we started in August. It definitely wouldn't have been possible to move as fast on iOS.

<comment><USER9> I can assure you that the process of iteration is horrible on iOS. It's awful to be in the situation having a team that is able to learn fast and develop improvements within days, but then having to wait a 7 day cycle for every new improvement or test. Plus from time to time Apple will just reject you - <USER2> weekend our update (a bug fix update!) was rejected because of a method name we were carrying for months. This is really not helping anybody, neither app developers nor users.

</comment></comment></comment></comment></comment><comment><USER8> "Amazingly, the trick even works when the phone is just sitting there, its screen black, and sleeping. Say "text by voice" and it wakes up"

I'm pretty sure this is impossible without aggressive battery draw. Altho if you're driving you can be using a car charger. The GPS already makes this neccessary unless you want to risk killing your phone before it guides you home.

It would be nice if they could hook into the 'car dock' app or google maps nav - so that their background service auto launches when those launch. I believe that's possible with some egregious permissions.

Also maybe get the 'charger in' permission and actively listen whenever the phone is plugged in.

Cool idea.

<comment><USER10> >I'm pretty sure this is impossible without battery rape.

I'm starting to sound like a broken record on HN about this, but this kind of comment trivializes actual, no-kidding rape by comparing it to a low battery, and comes across as inherently misogynistic even if you didn't intend it that way.

If we really want to be serious about opening up tech and getting more women involved, and more importantly if we want a world with less rape in it, we've got to cut this kind of thing out.

<comment><USER11> If he said it "kills the battery" would you say that it trivializes actual, no-kidding murder? I doubt it.

Also, men can get raped too. I don't just mean women raping men; men rape men too. (Would a "Don't drop the soap" joke be too inappropriate here?) It could be argued that assuming only women can be raped is the misogynistic position.

Last, saying that we've got to cut this out "if we want a world with less rape in it" is, frankly, ridiculous. Nobody is going to read the "battery rape" comment and subsequently be more likely to rape someone.

<comment><USER4> This kills the crab.

</comment></comment></comment></comment><comment><USER12> Clever but stupid. You divide your attention this way and you will end up dead in a ditch.

<comment><AUTHOR> It's a shame that we get this reaction. Emergency workers, truck drivers, and couriers all use our app and find it really helpful because they have to spend all day driving and want a safe way to communicate. (My favorite is a group of patrol officers in Kentucky who have Android phones attached to docks in their squad cars and use our app.)

Somehow even though it's risky and illegal, one third of drivers choose to text and drive. It's hard to get solid numbers, but around a few thousand people die every year in the US because of this, as well as causing hundreds of thousands of injuries[1]. Any way we can make driving safer overall is a net win.

[http://www.nsc.org/news_resources/Resources/Documents/NSC%20...](http://www.nsc.org/news_resources/Resources/Documents/NSC%20Estimate%20Summary.pdf)

<comment><USER13> People that are going to send messages while driving are going to do it no matter what. This app makes it much more safer that's all. Its a step in the positive direction, no doubt about it.

<comment><USER14> _People that are going to send messages while driving are going to do it no matter what. This app makes it much more safer that's all. Its a step in the positive direction, no doubt about it._

_Safe_, or just safer?

There can be problems with people thinking that risk has been reduced or eliminated; it can encourage more risky behavior.

[http://www.npr.org/templates/story/story.php?storyId=1821731...](http://www.npr.org/templates/story/story.php?storyId=18217318)

"It seems counterintuitive to give drivers less information, by taking away street signs, stop lights and lane markings, to make them drive more safely."

Also, <http://bicycleuniverse.info/eqp/helmets-nyt.html>

"Specialists in risk analysis argue that something else is in play. They believe that the increased use of bike helmets may have had an unintended consequence: Riders may feel an inflated sense of security and take more risks."

Absent specific studies on this there's room for doubt about "much more safer".

</comment></comment></comment></comment><comment><USER15> Tested this out yesterday on a friends Android Phone, very impressive to say the least.

Voice to Text... \- Who do you want to text? Nobody \- Aborting (something along these lines at least).

Shame it's not possible for the iPhone, activating an app via voice while it's sleeping. Very cool!

Shame that you can't select your language (Dutch/French/German etc...) - <USER3> wonder if this uses the Google Voice API?

<comment><AUTHOR> We do use the built in speech recognition that's part of Android. We definitely want to do other languages (and luckily Google supports a lot of languages), but are focusing on English for the short term and will expand once we get that right.

</comment></comment><comment><USER16> Any plans to move on to gtalk or maybe gmail? I'm trying to avoid txting in general. Love the product, it's running whenever I drive alone. Thanks

<comment><AUTHOR> Glad you like it! We'll definitely move to email and chat once we get texting down perfectly. We still have a ways to go.

</comment></comment><comment><USER17> Wow, this is awesome! Definitely gonna try this out next time I'm driving and texting...I mean, driving and _thinking_ about texting! ;)

<comment><AUTHOR> Somehow it's one of these things that everyone does but nobody admits to. Any way we can make driving safer is a win.

</comment></comment><comment><USER18> How is this different or better than Vlingo? (Which by the way uses a more generic wake-up request - "Hey, Vlingo")

<comment><AUTHOR> Vlingo's interaction is mostly hands-free, but there are a lot of points where it really wants you to push a button or read the text on-screen. We've also found it's confusing for first time users who want to send text messages, while we've tried to make it almost impossible to mess up while using our app.

Small anecdote: I knew we were onto something when I got my mom a new Android phone for Christmas and she managed to send a text without a hiccup on her first try- she had never used voice tech or even a smartphone up to that point.

</comment></comment><comment><USER19> Wonder how many traffic accidents these guys will prevent? I am guessing a lot! Actually, they will also prevent tickets you get from texting while driving in California. I have gotten one and it sucked!

Definitely worth trying, especially for a hyper-connected road warrior like myself.

<comment><USER20> Wow, I am the worst offender in terms of driving and texting.

Pretty scary (and stupid on the part of those of us who do text and drive) since according to Wikipedia, "the risk of crashing while texting /driving increases by 23 times, because reading or sending a text diverts the driver's eyes from the road for an average of 4.6 seconds"

I'm from Germany which has really strict laws on this and all phone activity (texting, calling, emailing) is forbidden while the engine is on (leave it to the Germans to be this strict).

<comment><USER21> Not only in Germany, it's a common restriction in many European countries: see page 44 of <http://www.etsc.eu/documents/Report_Nomadic_Devices.pdf> for a list of legislations in Europe in 2009.

</comment></comment></comment><comment><USER22> Voice commands already do most of this on Android pretty easily, and have for a long time. It looks like the real advantage here is setting it up before you start driving and being able to interact without long pressing the search button - but that seems pretty rough on the battery.

<comment><AUTHOR> We agree a large part of the advantage is not touching the phone at all. I disagree about voice commands though- if you put that app in the hands of someone who's never used it before, most people will give up before they successfully send a text.

</comment></comment><comment><USER23> Nice job guys! The Google voice settings are a little clunky though.

<comment><USER24> Wish my siri-less iPhone had this option.

</comment></comment><comment><USER25> I'm not a fan of texting/calling while driving. I wouldn't text someone while driving, nor replying. If it's urgent, people wouldn't text me anyway.

</comment><comment><USER26> How does it deal with a PIN protected phone when in sleep mode? Maybe there's a security issue there or does it ask for the PIN through voice?

<comment><AUTHOR> It won't be able to popup behind the locked screen because of the security issues you mention, but you can still use the app through voice. The worst an attacker that got hold of your phone could do is use the app to send text messages and read any messages that the phone received while they had control of it.

</comment></comment><comment><USER27> What are you guys using for voice recognition? Seems to be having some trouble with my Australian/German/Eastern European accent :)

<comment><AUTHOR> Sorry it's giving you so much trouble! We're using Google's default voice recognition engine. It does allow for different accents, but we haven't turned this ability on in the app. If it's getting names wrong, you can also try spelling the contact name one letter at a time, that usually works for people.</comment></comment>


Bradley Manning leaked Granai Airstrike "~86-147, mostly women and children" - <AUTHOR> http://en.wikipedia.org/wiki/Granai_airstrike#Video_of_the_airstrike

<comment><AUTHOR> I posted the link. I wanted to describe my reasons :

I know that even the most justified war is ugly : there are accidents and mistakes and innocent people die at times, despite the best precautions.

Im aware that the freedoms I have every day, are a result of a coalition of democratic countries winning WWII and other conflicts. Many of my freedoms were won by American strength : military, economic and technological. I'm not an American, but I hold up the Constitution, the rule of Law and Democracy as high ideals - the best way humans have come up with so far of coexisting on this planet.

But a Democracy cannot exist where there is no free speech nor the right to question the government and the law. Citizens need information on whats happening : we need freedom to speak and anonymity to discuss in private, if we are to have a functioning Democracy.

I think Bradley Manning had a moral obligation as a soldier and as a citizen, to release the information he did. From what I read it seems that he was careful not to share information that would get other soldiers and spies killed, nor give the enemy any material advantage in the war.

What I think should happen is that this should be a civil trial by jury to decide whether he acted legally and morally. He leaked news of military 'mistakes', so he should not be tried by that same organization. A civil jury should decide whether the obligation to uphold the Constitution, by leaking, outweighed his obligation as a soldier to keep the information secret.

Even more worrying here is that the Obama administration is pushing for this to be tried as 'giving information directly to the enemy' ie. treason, when clearly the motivation was not that.

If there were no Wikileaks, no Press, no privacy.. how would we keep our secret organisations in check, and have any confidence they are following their mandate ?

</comment><comment><USER2> It's important to note that there is absolutely no proof Manning leaked this, as the video was never posted online:

> _Assange blamed former spokesperson Daniel Domscheit-Berg for taking the > video, who said he had deleted it along with 35,000 other files when he left > Wikileaks in September 2010. To date, the video has never been publicly > released._

<comment><USER3>
      | In March 2013, Julian Assange said Wikileaks had
      | successfully decrypted the video and described it
      | as documenting "a massacre, a war crime".

This statement is confusing. I originally read this as stating that the video was decrypted March 2013.

<comment><USER4> It's not confusing. It would mean what you originally read only if there were a comma after "said".

<comment><USER3> s/confusing/easily misread and could probably be written more clearly/

</comment></comment></comment></comment><comment><USER5> I wonder if this is an example of one of the freedoms that they hate us for.

<comment><USER6> What do you mean "freedoms they hate us for"? Can you clarify?

<comment><USER5> It is a sarcastic reference to an often repeated line from a speech Bush gave shortly after 9/11/2001.

[http://www.washingtonpost.com/wp- srv/nation/specials/attacke...](http://www.washingtonpost.com/wp- srv/nation/specials/attacked/transcripts/bushaddress_092001.html)

My point here being that "our freedoms" plainly is not why they hate us. The real reason is because of our involvement and interaction with them. When such involvement and interaction is kept classified for decades, then the American public has no hope of correctly evaluating statements such as Bush's.

<comment><USER7> Are you sure they don't hate the "decadence" of modern Western society?

<comment><USER8> Ask Michael Scheuer:

[http://www.dailymotion.com/video/xgj08e_michael-scheuer- on-b...](http://www.dailymotion.com/video/xgj08e_michael-scheuer-on-bin-laden- s-true-motives_news#.UbPIvdvMdXI)

<comment><USER7> His argument is that radical Islamists hate us for what we do, not who we are. But we do what we do because of who we are. That's nearly a tautology in a democracy. We support Israel because its people largely share our values. We threw Saddam Hussein out of Kuwait and maintained a presence in Saudi Arabia because we support and defend the sovereignty of our allies, particularly when those allies supply vital resources. We continued to prop up Mubarak because we thought he was better than the alternative, etc.

All of these are policies reached through a free, democratic process, which has not been a hallmark of those societies which have welcomed Al Qaeda into their midst.

Also, have you heard of Sayyid Qutb? Just curious.

<comment><USER9> Also remember when all the fatwas were proclaimed for a Danish newspapers publication of a cartoon featuring the Prophet Muhammad? That's not even considering the issue of extremist religion and Sharia law, as led to the shooting and near-murder of Malala Yousafzai.

Islamist culture is _not_ entirely compatible with Western democracy, just as far-right fundamentalist Christian extremism is not entirely compatible with Western democracy (e.g. the 1996 Olympic Park bombing).

<comment><USER10> Why do you say _Islamist_ and not _radical Islamist_ , while you say _Christian extremism_ and not just _Christian_?

<comment><USER9> I'm using Islamist as the term was first defined, which means exactly "Islamic terrorism". As far as I know there's never been a popularly-agreed-on meaning of "Islamist" other than that, if you're referring to the peaceful followers of Allah the term is Muslim, or perhaps Islamic, but never Islamist.

Christian on the other hand is already overloaded with many meanings and I don't feel like inventing new words when I can simply add adjectives as appropriate.

Pray tell, is my explanation sufficient?

<comment><USER11> "Islamism" certainly does not mean "Islamic terrorism". It means a belief that Islam should be a force in the public sphere, not just a private religion.

[http://en.wikipedia.org/wiki/Islamism](http://en.wikipedia.org/wiki/Islamism)

<comment><USER12> Which is precisely the thing that is incompatible with Western democracy. Of would you like to amend the First Amendment?

<comment><USER11> It's absolutely incompatible with democracy, and more importantly in my opinion, with liberalism.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment> SG- Is anyone else really bothered that Daniel Domscheit-Berg deleted it as well as all the other things he did to Wikileaks when he left the project?

</comment><comment><USER13> Manning supposedly leaked only the video about the airstrike, the facts about it - including high number of civilians killed - were known long before. Even the reference article was created before the Manning story. Since the video was never released, the connection between Manning and this story is rather weak.

<comment><AUTHOR> For such an event, you really want to know there has been a proper investigation.

I dont know if there was a video, what it showed, how many people died, how many were combatants, what their ages were.

If I was a soldier.. Id want to know that these things are investigated well.. because I really don't want to kill innocent people by mistake. Where did the mistake happen along the chain of intel and of command, who didn't double check, was someone gung-ho or negligent ?

<comment><USER14> _Where did the mistake happen along the chain of intel and of command_

Let's start here:

[http://www.truthdig.com/eartotheground/item/200601011_fbi_un...](http://www.truthdig.com/eartotheground/item/200601011_fbi_unable_to_attract_arabic_speakers/)

<comment><USER13> How the fact how many FBI people speak Arabic has any relationship with the Granai tragedy?

<comment><USER12> I means that when you're a scrooge and decide not to attract people to fill positions that you need by offering them some monetary incentive, you have to spend even more money on bombs and spare parts that fall in the wrong places.

<comment><USER13> I don't think the situation we're discussing here has any connection with anybody being not paid enough.

</comment></comment></comment></comment></comment></comment><comment><USER15> "Hi. How are you? I'm an army intelligence analyst, deployed to Eastern Baghdad, pending discharge for "adjustment disorder" in lie of "gender identity disorder." I'm sure you're pretty busy.

If you had unprecedented access to classified networks 14 hours a day, 7 days a week for 8+ months, what would you do?

"I'm in the desert, with a bunch of hyper-masculine trigger-happy ignorant rednecks as neighbors... and the only safe place I seem to have is this satellite internet connection. I already got myself into minor trouble, revealing my uncertainty over my gender identity. Which is causing me to lose this job. And putting me in an awkward limbo...

At the very least, I managed to keep my security clearance (so far), and little does anyone know. But, among this "visible" mess, there's the mess I created that no one knows about yet.

Hypothetical question: if you had free reign over classified networks for long periods of time, say, 8-9 months ... and you saw incredible things, awful things ... things that belonged in the public domain, and not on some server stored in a dark room in Washington, D.C. ... what would you do?

Say ... a database of half a million events during the Iraq war. From 2004 to 2009, with reports, date time groups, lat-lon locations, casualty figures...? Or 260,000 state department cables from embassies and consulates all over the world, explaining how the first world exploits the third, in detail, from an internal perspective?

Let's just say _someone_ I know intimately well, has been penetrating U.S. classified networks, mining data like the ones described, and [has] been transferring that data from the classified networks over the "air gap" onto a commercial network computer ... sorting the data, compressing it, encrypting it, and uploading it to a crazy white-haired Aussie who can't seem to stay in one country very long.

Crazy white Aussie = Julian Assange..

In other words, I've made a huge mess.

"And, it's important that it gets out, I feel, for some bizarre reason. It might _actually_ change something. I just ... don't wish to be a part of it. At least not now. I'm not ready ... I wouldn't mind going to prison for the rest of my life, or being executed so much, if it wasn't for the possibility of having pictures of me plastered all over the world press, as a [poster] boy.

I've totally lost my mind. I make no sense. The CPU is not made for this motherboard. I cannot believe what I'm confessing to you.

"So, it was a massive data spillage, facilitated by numerous factors. Both physically, technically, and culturally. [It's a] perfect example of how _not_ to do INFOSEC. [I] listened and lip-synced to Lady Gaga's Telephone while exfiltrating possibly the largest data spillage in American history.

Weak servers, weak logging, weak physical security, weak counter-intelligence, inattentive signal analysis ... a perfect storm.

I mean, what if I were someone more malicious? I could've sold to Russia or China, and made bank."

Adrian shot back, "Why didn't you?"

"Because it's public data. It belongs in the public domain.

Information should be _free_." \- Bradley Manning

</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>==

This is true bravery. This is courage. This is heroism. Capitol Hill does _not_ have the intelligence quotient to understand this.

Either that, or they're just corrupt. It's probably the latter.

I am praying to a God I know doesn't exist, if only because I feel helpless in this matter. Bradley Manning, please be free. Just like the information you set out to liberate, be yourself liberated from tyranny.

<comment><USER16> _" I'm in the desert, with a bunch of hyper-masculine trigger-happy ignorant rednecks as neighbors..._"

Funny how averse most HNers are when it comes to perpetuating stereotypes and making negative generalizations based on race or gender, but when it comes to the military or people from "flyover states", it suddenly becomes acceptable.

<comment><USER15> In case you didn't notice, those were Bradley Manning's words, not mine.

</comment></comment></comment><comment><USER17> God bless Manning; a true American Hero that remembered he swear to protect his mother's soil from enemies foreign AND DOMESTIC.

He will probably rot in jail for the rest of his life for what he did. And I salute him for taking the hit!

<comment><USER18> > He will probably rot in jail

This is where we, the people, must step in to make sure it doesn't happen.

<comment><USER13> And how you plan to achieve that? Short of overthrowing US government, I don't see how it is possible to not have Manning, who violated a ton of US laws and already pled guilty for some of those violations, not going to jail. The law is not American Idol, so ending a lot of SMSes to some paid number is not going to work. Neither liking some page on Facebook would. Any other ideas?

<comment><USER19> The law is not American Idol - the rich and well connected don't win that contest so easily.

<comment><USER13> They win because you enable them by your votes. Each politician elected today had people voting for them. Each of this people decided to vote for this politician in his own free will. However rich you are, you still have to have people voting for you. So these "well connected" people are there because of the voters that put them there.

</comment></comment></comment></comment></comment><comment><USER20> You know what bothers me about this? Look how this event and everyone like it is surrounded by newspeak. We were uncertain. Unfortunate casualties. Inconclusive intelligence. Imminent threat. American interests. It's all bullshit. The US government can't even tell _themselves_ the truth let alone anyone else. They are drinking the kool-aid through a firehose.

<comment><USER21> It's war. Shit happens in war.

It's terrible, of course, but I don't think anybody in the military _intends_ things like this to happen (aside from a few legitimate psychopaths who use the chaos for their own ends). It's 'just' a horrifying side effect of using war and military power as a blunt instrument for statecraft.

<comment><USER22> > It's war. Shit happens in war.

Fuck that, the U.S. has a huge dominant army with superior technology and well trained personnel. They bombard a village because it's easy and effective.

Someone made a decision that the lives of American soldiers were worth more than an entire Afghan village. That's a war crime, and someone should pay for that. And that person should not be Bradley Manning..

<comment><USER23> What do you think used to happen with artillery strikes? It doesn't make it ok, but in war when under fire, they would call in air-strikes or artillery and clear a whole ridge. The difference is "the heat of battle" versus intelligence that 3 terrorist operatives where staying in a village of 300 people.

Military operations are not law enforcement. They aren't required to prevent all deaths other than combatants. I don't know where you draw the line on collateral damage, but to say that you can't kill any "innocents" is not practical.

<comment><USER24> _" but to say that you can't kill any "innocents" is not practical."_

Yes, by all means, let us not burden our efficiency at slaughtering our fellow man with morality!

<comment><USER9> Why should the soldiers on the ground consider it moral that 5 of them die so that 1 less civilian dies?

Certainly that's an easy choice for you to make; you're not the one bearing the brunt of that decision.

<comment><USER19> Because they signed up for it and are paid to risk their lives. They then get another choice - they can refuse to go there. The civilians don't get that choice. There isn't much fair in the situation, but I sure dont think many people would argue that the civilians are in the position of strength.

</comment></comment></comment></comment></comment></comment></comment><comment><USER25> This begs the question - what's out there that America fears so much as to carry attacks like this out?

<comment><USER26> Non Americans.

It doesn't go unnoticed across the world how Americans refer to Americans as "Americans" instead of just "people". It is always said as though there is difference and that Americans have more intrinsic value.

<comment><USER27> That's why nobody cared about the NSA spying on foreigners. Like your privacy (or any other human right) was more valuable depending on where you happened to be born.

</comment></comment></comment><comment><USER9> Unless Assange is going to claim that the bomber crew knew there were that many women and children there and dropped the bombs anyway I don't see how a video of a horrific event is really supposed to add to the horror. "Massacre" could be said to follow from the Wikipedia article video or no video; "War Crime" is much more serious but requires actual evidence of that, such as occurred at My Lai during Vietnam.

<comment><USER28> "oops" is not an excuse

<comment><USER9> True, but it's also not a war crime.

<comment><USER29> Summary of the Geneva Conventions of 1949 and Their Additional Protocols - [http://www.redcross.org/images/MEDIA_CustomProductCatalog/m3...](http://www.redcross.org/images/MEDIA_CustomProductCatalog/m3640104_IHL_SummaryGenevaConv.pdf)

Pretty sure there's something in there about destroying entire village(s) filled with people.

<comment><USER9> Yes, destroying civilian targets with no valid military usage is considered a war crime.

Destroying a civilian building being used as a military facility, on the other hand, is not a war crime, except if there was no valid military purpose to the strike or the strike was not proportional to the military value that might be gained (e.g. it would never be acceptable post-Geneva to kill 1000 civilians just to destroy an enemy soldier). That was one of the justifications the Germans used to sink Lusitania (which despite American and British protestations, it appears the Germans had actually been right in retrospect).

</comment></comment></comment></comment></comment><comment><USER30> An ancillary irony is the B1 Bomber, yet another example of a zombie military- industrial complex project that should have died decades ago. There's no good reason for it to be flitting around Afghanistan in the first place.

</comment><comment><USER31> That's a terrifyingly wide range.

<comment><USER32> any number (> 0) of children killed is terrifying.

</comment></comment><comment><USER33> Bradley Manning == Smedley Butler

</comment><comment><USER34> "mostly women and children"

Of course it would have been much less horrific if it was mostly civillian men instead of mostly civillian women?

Or would it be more okay because civillian men are more likely to be guerilla soldiers? So then it wouldn't be so terrible to kill them "just in case"?

<comment><USER19> I love how killing >guerrilla< soldiers is ok. You invade a country, collapse the fragile infrastructure and then accuse the locals of being the problem - there is no chance than they're fighting for something worth believing in... It's just, well, their country. Btw, I don't mean you specifically, I mean the US military/government members who supported this.

<comment><USER34> Well yeah. It's not often that one side is definitely bad and the other is definitely good.

<comment><USER19> Good comment. I think you could go a step further and say one side is never all bad. I'm sure there is an exception out there, but I don't know it.</comment></comment></comment></comment>


Feds reviewed only one bid for Obamacare website design - <AUTHOR> http://washingtonexaminer.com/feds-reviewed-only-one-bid-for-obamacare-website-design/article/2537194

<comment><USER2> The reporter is wrong in his characterization of IDIQ's. They are not some little used or known loophole of government procurement. IDIQ's are extremely common especially for IT services.

IDIQ's are also competitively bid. When the IDIQ is solicited multiple vendors compete and a single or multiple awards are made. In the case where multiple awards are made, as in the IDIQ used for healthcare.gov, each awardee then gets to compete for the individual task orders issued under the IDIQ. With a multiple award IDIQ except for under limited circumstances an individual task cannot be directed awarded to without allowing all contractors on the IDIQ a chance to compete.

The particular IDIQ used for healthcare.gov was the CMS ESD. This IDIQ was a multi-award with the 16 awardees being: Northrop Grumman, CGI Federal, EDS, CSC, IBM, Lockheed Martin, SAIC, ViPS, Buccaneer Computer Systems, IDL Solutions, Quality Software Services, Maricom Systems, 2020 LLC, iFed LLC, Alta Systems, DCCA. Now some of these companies will actually be partners on the contract so the total number of competitors for each task is not 16.

<comment><USER3> Indeed, except that people who don't follow this area indeed don't know about them. A whole bunch of people have been getting upset at a DHS procurement for _billions of hollow point bullets!!!_ ... which of course is an ID/IQ contract where the government is only obligated to buy 1,000 rounds of each type in the first year. The extreme total would only result with maximum purchases for it and the following four optional years (and the possible quantities of the various types of rounds ordered are very much not what you'd want for a civil war, but that's looking even deeper into the contract).

Ah, as a side note, annual US civilian production of ammo is 12+ billion rounds per year, with 3 or less billion being rimfire. Importation is not inconsequential (and much greater post-Newtown), so this isn't really even _that_ large in the scheme of things.

Anyway, as you say, they're common in IT, where knowing ahead of time how much of what you'll need is not entirely possible, although this is the first I've heard of one for software or complete systems including serious amounts of custom software, or multiple vendors all in the same game.

Funny thing, I briefly worked for AMS starting just before most of it was bought by CGI. Not top tier, but I didn't get the impression they were at the bottom, where I'd e.g. place CSC, which was mentioned in the article.

(I myself was in a national security unit that got bought by CACI, which for a variety of reasons I declined to join.)

BTW there are conservative sites of high quality. _The Washington Examiner_ is unfortunately not one of them, unless you're reading a column by Micheal Barone or one of the their other big names.

<comment><USER2> They are very common for software and complete systems including serious amounts of custom software. Also partners on IDIQs, especially large multi- award ones, are very common. At least they are on the civilian side. About half my life is spent working on proposals in response to tasks for complete systems issued under multi-award IDIQs.</comment></comment></comment>


The Domain-Driven Design Paradox (2016) - <AUTHOR> http://ouarzy.azurewebsites.net/2016/02/17/the-ddd-paradox/ <comment><USER2> When the developer is the domain expert, you've achieved the singularity. /s

A large percentage of the time, there is no domain expert available, or there simply is no domain expert. We've all worked at that place. You start a new job and you're left to your own devices to sink or swim. You wonder why no one can be bothered to take the time to give you the big picture. Who is the customer? Who is the user? Are they the same person? What problems are we trying to help them solve? Are we optimizing for speed, correctness, usability? How do our competitors do it? Who are our competitors?

How about some backstory on this codebase? I can look through source history like I'm doing an archaelogical dig. But how about a narrative on why certain choices were made?

The reason no one will take the time to answer these questions for you is that they will quickly be exposed as not having answers. The best they can do is say "I'll have to ask so and so", and then you'll never hear back.

Also, there is a pervasive vibe that when you're brought on as a developer, it's not your place to ask business-y type questions. Let the people person talk to the people, and you dig ditches where we tell you to dig them. And if we ask you to fill it back in because we told you to dig in the wrong place, well then, you're here 40 hours a week and work is work right?

/end rant

Sorry guys, my fingers just kept typing.

<comment><USER3> I've never worked at a place without a domain expert.

If the company's new, then everybody's aware that they're learning, and so they actively seek expertise. If the place is old, then I've always been able to find people who understand the domain; they've been soaking in it for years.

What you're asking for is something a little different, somebody who can feed you a pre-digested analysis, one suitable for understanding/designing the code. That definitely doesn't exist. That person must be us.

We understand our domain, computers. They understand their domain, business. They will never understand computers particularly well. So it's incumbent on us to lead the collaboration to create a shared domain model, a formal map of their territory.

Of course, some places do try to stop us from working in the ways that are most effective, to treat us as robots. When that happens, the old Agile advice applies: either change your organization or change your organization.

<comment><USER4> > either change your organization or change your organization

Two different but related meanings coming from two valid parses of the same string, nice!

</comment></comment></comment><comment><USER5> > Even on the implementation side of a project, there is a lot from DDD that > is always usefull. It's not always about CRUD or CQRS and Event Sourcing. > But it's always about naming the methods, classes, interfaces and modules > according to the domain language, the Ubiquitous Language. This is DDD.

> If I encourage collaboration between technical and domain experts and work > iteratively to refine a conceptual model, I can claim I'm doing DDD.

This. I am tired of the so-called 'DDD-experts' trying to convince us that you must use X framework with Y techniques to 'properly' implement DDD. In the eyes of some managers I know DDD is something mysterious, something that requires expert consultants to do and if we copy paste their design we will be doing 'DDD'. That explains why in my company each team has their own understanding of 'DDD'. To me, the Ubiquitous Language is the essence of DDD. As long as I name my class/method/function/variable accordingly then I am doing DDD. And we try to make it so that the Domain Experts can read our code and say its business logic is correct or not, even if they don't know anything about programming at all. To do that we can use whatever tools/languages we want, OOP, FP, Free Applicative, DSL etc..

It's the Domain that matters in Domain Driven Design, not the framework or languages or even design patterns.

EDIT: Fixing formatting again..

<comment><USER6> Everybody seems to agree that when your engineers understand the domain they are working on, they build better solutions. There is always some snake-oil salesman suggesting your engineers either don't need to understand the domain, or there's a shortcut by which they can learn it.

There isn't. And every generation seems to rediscover that truth and give it a different label.

<comment><USER7> Just to reinforce what you are saying, there were people doing this even in ancient Greece, see Plato's Gorgias.

[http://www.gutenberg.org/ebooks/1672](http://www.gutenberg.org/ebooks/1672)

</comment></comment></comment><comment><USER8> Cache of page: [http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://ouarzy.azurewebsites.net/2016/02/17/the- ddd-paradox/)

<comment><USER9> > Error 403 - This web app is stopped.

Oh, 2017... We need web app to show static content.

<comment><USER10> This. We've been pushing Microsoft to add static site support to Azure Blob Storage for years but keep getting rebuffed. Apparently their official advice is to spin up a free "Web App" \- as if that is in any way comparable to a truly distributed static file server like S3 / AzStorage.

<comment><USER11> Clearly they don't want your business. So, why not use someone like GitHub, AWS, or GCP who does?

<comment><USER12> Use wordpress for your content.

The clouds will charge $300 when you'll go first page on HN. You don't want that.

<comment><USER13> I have a counterexample.

My blog is hosted on AWS S3 with CloudFront CDN and costs a few dollars per month (most of that comes from Route 53). One day it appeared on the front page of HN. Total blog cost that month didn't exceed 5 USD.

<comment><USER12> You are lucky to have a small audience and no media to deliver.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> While I like DDD very much (created much tooling over last 10 years to help develop software in such a way), but if you move outside of useful implementations, you don't end up with much. Talking to domain experts, analyzing your domain... that's just a straw man arguments to sell DDD. Ubiquitous language is a good argument for DDD, but I don't see that practised a lot. There is often a noticeable disconnect between how experts talk about the system and the abstractions in the system which represent them.

Also, on technical level, while there are a lot of useful things in DDD (aggregate roots, value objects, repositories, ...) there is also a cargo-cult like notion what is a good way to develop software. And when you listen to "the experts" you often get a feeling they can fake the talk, but surely don't know how to walk.

My single question to see if someone is practicing DDD is: do you refactor your codebase on deeper insights? I'm yet to see someone say yes to that. Often you get excuses not to touch code which is working since refactoring large codebase is impractical/risky.

<comment><USER15> I refactor my code fairly regularly (as specifications change). The use of TDD, DDD, CQRS and Event Sourcing gives me immense flexibility to be able to refactor a large codebase and then test it through its whole lifespan (with actual data).

<comment><USER16> > The use of TDD, DDD, CQRS and Event Sourcing gives me immense flexibility to > be able to refactor a large codebase and then test it through its whole > lifespan (with actual data).

What is your experience in applying those principles in a team? It would be very interesting to get some insight on it.

<comment><USER15> 1\. TDD is simple enough. Everyone should be doing it. 2. DDD - this usually results in plenty of healthy debates on naming conventions. Acronyms are abhorred and we try to agree with the stakeholders on the meaning of each word they use. 3. CQRS and Event Sourcing - this has required our team quite a bit more of startup time than a CRUD application would have. We have been lucky to have a very understanding Product Owner who gives us plenty of time to deal with tech debt. Although single features may have originally taken us longer (than the time it would have taken to do the same with CRUD) at the start of the project, years on this time and the complexity of refactoring or adding features has not really increased, as any functionality is contained within its bounded context.

The biggest difficulty has been explaining what we are doing and why to senior management. But we haven't had any bad incidents so far, so I think they like us.

<comment><USER17> Do you do full-blown event sourcing or apply it to specific areas only? If the latter, how do you decide which? How do you deal with performance? Specialized database (e.g. Event Store) or not?

Real life success stories about ES are rare, so I'd love to get more insight in the anatomy of the solution (way beyond these few questions). Blog post request, I guess.

<comment><USER15> We have full-blown event sourcing for pretty much everything. The performance on the read side is great (obviously). We have an Event Store and we rebuild the Domain for every new command, so it isn't particularly fast, but we have a situation where commands are only issued a few times every year by a single person, whereas there are millions of reads every day (hence justifying CQRS as a solution). We have a mixed solution around replaying events though, largely around the issues we have with file uploads. Every file upload triggers multiple events (uploaded, processed etc) and we have different solutions for different files. Small files we store in the events as a blob, whereas big file events upload the data to a projection store and will not be replayed, so we don't have the issue of having to keep the original files forever as well as the database. I should probably write a blog post about the project at some point, but I'd like to investigate with my bosses as to how much I can actually reveal about the domain (because it would make the read so much more interesting if I could say everything).

</comment></comment></comment></comment></comment></comment><comment><USER15> Frankly, concepts like Ubiquitous language ARE definitely a silver bullet - I've written an article on how they increase your bus factor ( [http://www.michalpaszkiewicz.co.uk/blog/busfactor/](http://www.michalpaszkiewicz.co.uk/blog/busfactor/) )

<comment><USER18> Ubiquitous language only exists in mature domains. If you think of mathematics as the ultimate example of clear and precise language with rigorous definitions then most domains are on the other end of the spectrum. In these domains there are multiple names for the same concept within a department let alone the whole company. Changing that requires patience and continuous direct access to stakeholders/experts. Not impossible but I have rarely seen it work to its full potential.

<comment><USER15> You are absolutely right, but campaigning for a ubiquitous language in a company has far more benefits than just the application of DDD to your code. In meetings with other teams or stakeholders, we often hear or say things like "can we agree to call _this thing_ _this_ from now on". We then proceed to clarify exactly what is meant by the terms. It goes a long way.

</comment></comment></comment><comment><USER19> I don't think DDD is a silver bullet; building quality software will require DDD but it will also require more.

But don't get me wrong, I always been a proponent of keeping Domain concerns in The Domain layer.

It makes much more things easier in the long run, beginners should be exposed to DDD very soon in the learning process, in my opinion.

DDD and the principle of separation of concerns always reminds of Uncle Bob screaming "DATABASE IS DETAIL!": [https://www.youtube.com/watch?v=o_TH-Y78tt4&t=42m45s](https://www.youtube.com/watch?v=o_TH-Y78tt4&t=42m45s)

</comment><comment><USER20> Do people still recommend Eric Evans' book on DDD? Or would Vaughn Vernon or Scott Millett be better ways to learn it as of now?

<comment><USER11> I personally found the Vernon book to be overly repetitive and actually light on real application guidance. It almost turned me off to DDD.

The Evans book is the better investment by far.

<comment><USER17> While Millett and Tune's book is generally good, it too is very repetitive about the fundamentals.

</comment></comment></comment><comment><USER21> A bit of advice to authors: define acronyms when you first use them. DDD is defined the link text locally, on HN, but not at the site. CQRS & CRUD are also not defined. I'm familiar with CRUD, but not CQRS. DDD, lacking context, I was initially thinking the graphical front-end for gdb.

<comment><USER21> TL;DR: There's too many T.L.A.'s pulled out of A.S.S.'s and sometimes, a bit of context to disambiguate is helpful.

</comment></comment><comment><USER22> Agreed. Focusing on the domain is never a bad idea. The application of DDD can be insane though. If you have to learn about event sourcing and CQRS and microservices architecture, and schema evolution, and scala and Akka cluster with sharding and singletons and whatever else is employed just to be able to function, it can be very impractical to build and grow teams, let alone run the software.

<comment><USER23> All those things that you mentioned are just implementation details that some people use with DDD, you can do DDD with assembly if you wanted to.

<comment><USER24> Or plain Java or C#, more likely :)</comment></comment></comment>


All Electric Cri Cri - <AUTHOR> http://www.eads.com/eads/int/en/news/press.255618dd-959b-4f4a-865b-ad884f380318.70472f39-dd6f-4428-a792-91d82cb9791b.html <comment><USER2> It's nice that they named it after a beloved Mexican children's songwriter. (Well, they probably didn't but Cri Cri is an unusual name to coincide on, isn't it?)</comment>


Launch HN: Multis (YC S19): online business bank account for cryptocurrency - <AUTHOR> Hi HN,
We're Théophile and Thibaut, and we're building Multis (https://multis.co): an online bank account designed for companies holding cryptocurrency. We're helping them store it, spend it and earn interest.
We have been in this industry for the past 3 years. Thibaut used to lead sales at Stratumn, a Nasdaq-backed company helping companies securing their shared workflows through cryptocurrencies. Théo built several decentralized applications before starting the company in 2018.
Wallets are the cornerstone of the industry: you need them to store and transact with cryptocurrencies. But these wallets are not designed for business. You cannot perform simple business operations like running a payroll, paying vendors, or earning interest, which you can currently do from your modern business bank account.
Cryptocurrencies - and particularly stablecoins - are a reliable, fast and cost-efficient medium of exchange. It's a technology that enables anyone to move value and assets across borders, with no intermediaries. We believe it can help companies save a lot, since most of them are now actively transacting with partners abroad, from suppliers to foreign contractors.
The number of companies building and transacting with cryptocurrencies is growing (e.g. Stateofthedapp listings grew by 250% since 2017), despite still being in its infancy. Most of these companies are operating in the cryptocurrency industry, or are e-merchants willing to reduce payment fees and optimize working capital.
These companies struggle to manage their assets and make the most of them. They typically have between 5 and 10 wallets, none of them being designed for a business environment. This makes business spending and accounting still to painful and time-consuming. And cryptocurrencies sit idle, because there are just too many frictions.
We realized what was really needed: an application to manage cryptocurrency the same as a modern online business bank account, with features and financial services powered by both crypto and traditional currencies. In short, a crypto-first bank. Here are our main features today:
- Store - multi-user wallet with dashboard and transaction history
- Pay - spending policies and streamlined payment flows (1)
- Exchange - swap 70+ tokens with ethers, dollars and euros (2)
- Earn - savings account yielding interest on stablecoins (3)
- Soon: EUR and USD bank accounts
We will make revenues through commissions on financial services like fiat ramps, and through monthly subscriptions for premium features like accounting exports or fiat accounts.
Our goal of making a unified front end that works like a business bank account is challenging to achieve because the technologies we're using are very heterogenous:
- we have two databases: the Ethereum blockchain and Cloud Firestore
- we have two backends: smart contracts and Firebase Cloud functions
- we have two authentication systems: private keys stored on individual wallets (we're self-custodian) and email addresses
- we have two authorization systems: the multisignature contract owners and the owner/guest roles in our security rules
- we have two type of assets: cryptogoods and traditional currencies
- we will have two storages: IPFS and Firebase Storage
You can read more here about our architecture (4) and our approach to security (5).
Cryptocurrency is still a recent technology that generates understandable skepticism.The ICO craze did not help. We feel that payment is becoming a tangible use case though, and companies ranging from Facebook to JP Morgan are now actively investing in it. We believe more will join. There are still many uncertainties about regulations, accounting, and each new SEC or FinCEN guidance make the teams' hair turn grey. But things are moving forward on the ground, despite the excess of hype in the space.
We want to make Multis useful, so we have one question: what would be the key features and financial services you would expect as a company? They don't have to be related to crypto directly. We'd also love your feedback, your questions and your ideas. Thanks!
(1) https://medium.com/multis/introducing-direct-transfers-a-new...
(2) https://medium.com/multis/multis-launches-first-token-swap-c...
(3) https://medium.com/multis/our-new-compound-integration-lets-...
(4) https://medium.com/multis/imagining-a-leaner-way-how-to-ship...
(5) https://medium.com/multis/security-at-multis-9609d346c91b <comment><USER2> This is a very interesting approach of merging crypto with the legacy system. Good luck in your endeavours!

<comment><USER3> thanks a lot - yes we think that having fiat and crypto side by side can be interesting :)

</comment></comment><comment><USER4> Great idea!

Just this week I was approached by a recruiter for a crypto-app building company that I know of and really like. I was (imo) a great candidate for them skill-wise, but they only pay in BTC. And while I'm a fan of crypto, I have bills to pay and they all want dollars. I don't want to deal with converting to USD every paycheck and figuring out if I need to pay taxes, transferring to my "real" bank account, etc.

I REALLY hope you all can help with stuff like that!

<comment><USER3> totally understand the hassle of figuring out how to pay taxes etc.

we definitely want to champion this idea of having fiat and crypto side by side, and how to do it properly.

going all crypto might be too brutal and we think the hybrid approach makes more sense: work for a company that pays you in fiat (for bills and legacy stuff ;)) and crypto.

life is an experiment ;p

</comment></comment><comment><USER5> You need to be very careful when using the term "bank". It's a very sensitive and regulated domain and depending on the countries you're targeting, you may have to remove it entirely until you have the appropriate licences to use it.

<comment><AUTHOR> You're absolutely right! We're still iterating on that one. "Banking account for crypto and fiat" rather than "cryptobank" seems to be the right way to mitigate risk for now (e.g. Mercury "banking built for startups"), but we certainly want to be extra cautious.

</comment></comment><comment><USER6> Very interested in testing out your product as it seems like it solves some real painpoints of ours. Is there someone we can reach out to directly and provide detailed feedback to after we have a chance to try it out?

<comment><AUTHOR> We'd love to help and get your feedback! email@example.com

</comment></comment><comment><USER7> You already mentioned payroll and vendors, so I think you're already thinking of what I'm about to suggest... and then I might try to talk you out of it.

When I think of business cryptocurrency financial stuff, I also think of those things. Employees need to be paid, and they might want their paycheck in crypto or in fiat, or a combination of the two. Vendors that need to be paid will usually just want fiat, either through some kind of fiat electronic transfer, or a "bill pay" check that's printed and mailed.

The problem is that payroll is HARD. That's why banks, who handle business accounts, don't do payroll and it usually falls onto specialist companies. Given the "global" nature of cryptocurrency, many of your customers will likely have employees spread across the world, which also adds payroll complications when it comes to withholding, legality of cryptocurrencies, etc.

You might want to just partner with a payroll company otherwise you'll find that most of development (business, software, and legal) will end up being sucked into that blackhole side of the business that doesn't even have a high margin.

Paying vendors? That's relatively simple in comparison. That's why most banks DO provide bill-pay and transfer services.

What I suggest for your "secret sauce" is being very internal bureaucracy friendly and give out employee corporate debit cards freely.

Build your system so when a business signs up, they can make accounts for all their employees and managers and set up authorization workflows. If Bob in accounting wants to buy a new chair, he should be able to submit the request for the funds. If it meets various criteria (ex: less than $500, only needs manager approval and not department head approval) and gets approved, then your system makes the cost of the chair (plus some buffer) available on Bob's wallet which has a linked Multis debit card.

If the business only provides debit cards to managers and up, then it would make the funds available to the managers crypto wallet (and associated Multis debit card) so they can purchase Bob's chair.

Lastly, if you put in place this support of business organization structure, use the same structure for the multisignature systems. One of the signatures could be Bob's manager, or maybe it would require the manager and the department head, etc... But not Bob and his wife, who happens to be a manager in an entirely different department at the business.

I've done crypto work before, and also have recently build a "corporate bureaucracy friendly" authorization system for a SaaS I'm working on so putting those two experiences together seemed natural :-)

<comment><USER8> Payrolls are done by accounting, but they use an interface to the bank to make the actual payments. It's usually a CSV file or similar, which is uploaded by the accounting software, and has just the amounts and account numbers. Checks are not used outside of USA.

<comment><USER9> Having worked at ZenPayroll in the early days, I can say with confidence that this is not true. Payroll is not handled by accounting software and it sure as hell is not uploading amounts and account numbers.

As for paying people in crypto, we considered it (I was the engineer working on it) and then we decided against it because it's a terrible idea.

1\. Crypto transactions aren't reversible so reversing fraud is impossible.

2\. Users don't fully understand how blockchainy things work. Providing customer support to explain wtf any of it means would be a nightmare.

3\. Users can't use crypto for anything. I mean maybe buying illegal things on DarkNet markets but other than that the entire blockchain ecosystem—billions of dollars of investment—has yet to build a single usable product solving a real problem.

4\. Currency changes value all of the time. What if someone can't pay rent because they were paid in Internet coins that lost value in the time between their pay period and the end of the month? They're just…kind of fucked? And again, most people don't really understand what's going on here so "it's their fault" is a very uninteresting response. Don't set people up to make poor decisions with ramifications they don't understand, even if we can absolve ourselves of theoretical accountability on Internet forums.

5\. In the US you can't pay people in whatever you want. These regulations exist for good reason, back from when companies would try to pay people in store credit. Is blockchain whatever a real currency or a narrow utility that locks people in? Legally it's a grey area (or was when we worked on it.)

Overall, it's just a terrible idea. No one is sitting at home thinking, "damn, I wish I could be paid in blockchain." I mean, they kind of where when crypto was going up and up and up and it was some speculative get-rich-quick pump and dump, but not anymore. (And anyway, we maybe shouldn't encourage people being paid in speculative coins with no real-world uses? I don't know.)

<comment><AUTHOR> 1\. Was fraud a big issue at ZenPayroll? I would assume this to be an issue for fortune 500 companies, not smbs

2\. We're helping crypto companies for now - they get it. Hopefully non-crypto people will get it too as crypto becomes mainstream :)

3\. e-merchants like Rakuten started accepting crypto. Amazon could follow. Consumer apps offering higher interest rates than traditional banking could also be compelling

4\. You're right! that's why we're bullish on stablecoins like USDC or DAI - value is pegged to USD

5\. Still grey, but moving fast - you can now pay people with bitcoin as long as they get minimal wage in USD. Paying bonus in crypto is an interesting use case

<comment><USER9> Fraud isn't something you can worry about after the fact. There are strict regulations around anti–money laundering and counter-terrorism that are less about de-frauding an SMB then spinning up fake businesses and using payroll as a conduit. The challenge with blockchain payments in payroll is anonymity and irreversibility (two of its significant differentiators.)

At that point, what are the benefits? Transaction speed is one, but you only really get that if the business pays in crypto (otherwise you still need to wait for the ACH payment from them or float the money (don't float the money.))

<comment><AUTHOR> \- Is crypto really different from cash for this? Plus anonymity seems relative now as agencies like Tracfin can track back addresses.

\- Our users generate revenues in crypto. Paying employees with it is just convenient, faster, and cheaper when part of their staff is abroad.

</comment></comment></comment></comment></comment></comment><comment><USER10> Sounds like a very good idea. As a depository institution are you looking to acquire a banking license (like varo did)?

<comment><AUTHOR> Thanks! For now, we will partner with regulated bank infrastructure providers - they have the licence. Just like neopbank players have been doing with Synapsefi in the US or Solarisbank in the EU.

</comment></comment><comment><USER11> Glad to see you guys continually innovating. Wish you the best of luck. -Gil from Gilded

<comment><AUTHOR> thanks so much Gil :)

</comment></comment><comment><USER12> > Cryptocurrencies - and particularly stablecoins - are a reliable, fast and > cost-efficient medium of exchange

May I respectfully ask for a citation on this statement's three claims please?</comment>


Show HN: Require approval to merge GitHub pull requests - <AUTHOR> https://pullapprove.com <comment><USER2> This is neat! I'm excited to see things about the GitHub code review ecosystem improving. I've long wanted to see "when tests pass and a reviewer :shipit:'s, then go ahead and merge the code" bots.

I wrote a bot of my own, which I have at [https://betterdiff.com/](https://betterdiff.com/) . The idea there is that instead of having humans go through and give cursory reviews, you have a round of automated review by robots (using normal, industry-standard tooling) and it comments on the PR just like a reviewer would. I'd love to hear your thoughts. :)

</comment><comment><USER3> This is pretty cool. We built something similar internally at a previous company - very handy to enforce good development practices, and ensure that no unreviewed code is deployed to production for security purposes.

<comment><AUTHOR> Thanks! We started it for the same reason -- internal use. Felt like we might as well turn it into a service so other people wouldn't have to build it too!

Is there anything you learned by building your tool that would be worth us building into PullApprove?

<comment><USER3> Well, without looking past the landing page for your tool, some quick thoughts:

\- "Read and write all public and private repository data" is a pretty serious github auth request for people just wanting to kick the tires of your service. Perhaps only ask for basic email address, then get additional permissions (or allow manual setup) later?

\- Have you managed to prevent _all_ commit access to master (for example if someone does a regular push to master without opening a pull request)? I'm not super familiar with how github protected branches work, but it only mentions preventing accidental force push. If there is any way to bypass this, it would be nice to have an option which auto-reverts any unauthorized changes.

\- One pain point we found was where developers amended a pull request by squashing all commits and force pushing to their PR branch. We found that this was annoying having to go back and ask for another +1 from the team when the actual diff hadn't changed. To fix this we stored the sha256 of the complete diff along with the PR status, so that if a commit was amended but no code changed, it was automatically approved.

\- On that note, there is quite a difference between people who want to use this to encourage good development practices, and those who are using it for security audit. For example, if I make a PR, and someone nitpicks my indentation and gives a +1, then I amend my commit to fix the spacing, do I need to bug that person for another code review, or just go ahead and merge? In spirit my code has been reviewed already, but if you are trying to protect against an owned laptop being used to deploy code into production, every commit should be reviewed. I would recommend making this an option for each team (whether to simply require approval for each PR, or every single commit).

\- Extra feature that would be cool: requiring multiple (or specific) approvers if you touch a certain subset of files/folders in the repo.

<comment><AUTHOR> Awesome, thanks for the detailed feedback.

\- Great point on permissions. I'm certainly going to do some digging to see how many people get turned away by that level of access. I could definitely understand if people are cautious with that, as you were, because they should be!

\- The prevention of commits to master all happens via GitHub's new protected branches feature (they use Git hooks I believe). You're right, preventing force push is part of it, but the other thing it can do is require status checks (PullApprove is just another status check) on all commits to your base branch -- meaning nothing can be directly committed to the base branch, but should instead run through a pull request. Pretty interesting stuff: [https://github.com/blog/2051-protected-branches-and- required...](https://github.com/blog/2051-protected-branches-and-required- status-checks)

\- Thanks for sharing this one, I definitely wouldn't have thought of that without experiencing it myself.

\- I'm planning on building some settings towards this. The most basic one giving an option that approval statuses go back to "pending" on new commits. It could possibly get more specific, giving an option to ignore whitespace changes etc...

\- Nice idea. I'll throw this in the hopper.

Let me know if you have any other thoughts!

</comment></comment></comment></comment><comment><USER4> Some cool stuff here, though I think a demonstration video or fancy animation would be nice. Like someone else has mentioned, it's a little intimidating to give full access just to see how it works -- you might convert more customers if they can see how it works and some common use cases before they need to commit the time to trying an integration.

<comment><AUTHOR> Thanks for the feedback, I totally agree. I'll see if we can work something up that shows the whole flow -- from creating a pull request, to approving via PullApprove, to merging.

</comment></comment><comment><USER5> It would be cool too if you could set conditions on when to merge. I finish a PR it's kind of late :

Merge tomorrow 8am if tests passing etc.

</comment><comment><USER6> I used to think that this was a really weird missing feature in Github. Then someone introduced me to true Gitflow using forked repos have used it with all teams since. With a forked repo someone with read access can post a PR to the originating repository without the ability to merge.

Does no one else use this methodology on their teams?

<comment><AUTHOR> Forked repos is absolutely one way to accomplish preventing merge privileges (since it removes all push access). At least for us, our workflow and tooling is much simpler if all developers work on the same repository.

Even in the case of forked repos, I think PullApprove can still have some benefits. Ex. Someone forks and makes a pull request, but it needs to be reviewed by two key developers before it should be merged. PullApprove could help to formalize that process, requiring that both of those developers mark it as "approved"...

Does that example apply to your workflow? Or is there anything else about your process that a service like PullApprove could formalize? I'm looking forward to hearing more about how other teams deal with some of these issues...

</comment></comment><comment><USER7> Does it support a dynamic reviewer? In other words, instead of assigning a person who approves pull requests, it would allow merging if at least one other person with write access approved the code.

That would be the main use case for the company I work at, right now we're doing that manually by tagging and waiting for the response.

<comment><AUTHOR> Currently there's two ways "approval" can be determined. 1) Approval by "any" of the reviewers means it has passed. Ex. The 3 people with write-access get chosen as the reviewers, and if any 1 of those 3 approve it, then it passes. 2) Approval by "all" of the reviewers means it has passed. Ex. Of the 3 people chose as reviewers, all 3 would have to approve the PR for it to pass.

Does that make sense? I think #1 gets at the scenario that you're talking about, but right now it doesn't automatically choose the reviewers based on who has read/write/admin access. You would just choose those people manually when you set up the repo and choose whether the rule is "anyone" can approve it or "everyone" has to approve it.

<comment><USER8> I think the scenario shadeless was describing is that the author of the PR shouldn't be able to merge but anyone else with write access could. It would be my ideal scenario as well. (You could of course bypass this by doing it in Git if you really needed to.)

<comment><AUTHOR> Gotcha, so if three users have write access then when a PR is opened by one of them, one of the other 2 users has to approve it?

If your scenario only has two users (you and one other person) then this flow can already be accomplished (the two are both reviewers, and you set approval required by "everyone" \-- so you approve your own PR and then the other user has to also). If you've got more than two users, that's something we'll have to add but it sounds like it's worth doing!

</comment></comment></comment></comment><comment><USER9> I received an unsolicited email from these guys. The email does not get subscribed to many things to keep volume low. Did they buy a bunch of addresses to spam?

<comment><AUTHOR> Sorry if you got an email that felt unsolicited. The only email that was sent was to some users of Sibbell ([https://sibbell.com](https://sibbell.com)) which is another GitHub-related service we built. We really weren't trying to spam people, but thought they might have a genuine interest in another tool based on GitHub.

</comment></comment><comment><USER10> Oh look, another tool to get in the way. Of course "write" access means "merge" access, they are the same thing. How about we try this thing called trusting the developers.

If you can't trust your own developers, you have bigger problems then "merge access".

<comment><USER11> At risk of feeding the troll: the point, as made in their tag line, is that you don't always want any individual with the ability to create a branch to be able to merge to master, for a variety of compliance and stability reasons. This is just a codification of the existing strategy used by all kinds of teams, where a PR is submitted and approvals are solicited in the PR from other team members before merge.</comment></comment>


Speeding up JSON processing in go – Andrew Klotz - <AUTHOR> https://klotzandrew.com/blog/speeding-up-json-processing-in-go <comment><USER2> I'm curious, anyone know of a good resource for understanding the output of pprof and figuring out what all the numbers, colours etc mean?</comment>


Moving to GraphQL from Soap or REST - <AUTHOR> https://blog.apimatic.io/moving-to-graphql-from-soap-or-rest-2383f7dc6523 <comment><USER2> Not worth discussion: this is a paid service with ridiculous limitations (for $15/mo) one gets support for 'converting' 1 API with 10 endpoints in a team of up to 2 members.

<comment><AUTHOR> You do not pay for conversion. Transforming API specs from one format to another is totally free. But APIMatic does offer other services, like SDK Code Generation and creating API Docs Portal from any API spec format, which is what the paid tiers are for.

In fact, API Transformer is free service with support included, which I have not seen other SaaS providers doing.

Disclaimer: I work at APIMatic. :)</comment></comment>


Ask HN: Best books you read this year? - <AUTHOR> Sci-fi, nonfiction, fiction: what did you like? <comment><USER2> The Way Of Men by Jack Donovan.

But I don't expect it to be popular with the highly politically correct HN crowd.

</comment><comment><USER3> Outliers by Malcolm Gladwell

Art of the Start 2.0 by Guy Kawasaki</comment>


BroadcastChannel API – Communicating between tabs - <AUTHOR> http://dibaiee.ir/broadcastchannel-api/

<comment><USER2> A first class API for cross-document communication is something that has been sorely needed for a long time. I've solved this problem in the past by treating LocalStorage as a page of shared memory and using it to create a publish/subscribe event system. I'm sure the same concept can be used to create a compatibility shim for this API.</comment>


Framer 2: Prototyping with Photoshop Integration - <AUTHOR> http://www.framerjs.com/

<comment><USER2> I like it. I'm a coder / designer and I usually do the layout stuff in photoshop and then add animations when I actually build the product (i.e. Core Animation in my case) but that can cost quite a few build / test cycles until it has the right feel (speed, animation, etc) to it. I'm a huge fan of Quartz Composer but to me it just doesn't feel like the right tool for the job, especially since interactivity (i.e. touching, clicking) feels a bit like an afterthought in there. Also, I really don't like Flash; had to do Flash programming years ago, and can't stand the UI anymore. So this tool looks like the solution that perfectly solves the problem I'm having there. Thanks, I'll play around with it tomorrow!

</comment><comment><USER3> "I'd like to say again though that supporting more browsers is not one of my primary goals."

<https://github.com/koenbok/Framer/issues/2>

That's a shame.

<comment><AUTHOR> But I hope understandable for a prototyping tool. I'll take contributions though.

<comment><USER4> Sofa still rules! And now in open-source. Cheers, Koen.

<comment><USER5> What's Sofa?

</comment></comment></comment></comment><comment><USER6> This looks pretty nice for designers who happen to know a little bit of code. Most designers I know do their mobile mockups in After Effects so they can really demonstrate interactions and animations.

<comment><AUTHOR> That's exactly what it was made for.

</comment></comment><comment><USER7> For some reason it doesn't seem to be working with CS5. I run it alongside Photoshop and it just says "syntax error: Expected end of line but found identifier. (-2741)" for a split second.

<comment><AUTHOR> Argh, sorry for that. I did not have CS5 to test. I'll see if I can at least put in a better error message.

</comment></comment><comment><USER8> couldn't it be used for real applications -not prototyping- with phonegap? awesome work good luck

</comment><comment><USER9> awesome tool Koen, great work!</comment>


Why Still So Few Use Condoms - <AUTHOR> http://www.theatlantic.com/health/archive/2013/04/why-still-so-few-use-condoms/275301/ <comment><USER2> Because they don't fucking feel nice?

Condoms are a way of protection that was imposed on us because of AIDS. It's not like people like them -- they just were them because they have to.</comment>


Js13kGames 2014 winners announced - <AUTHOR> http://js13kgames.com/#winners

<comment><USER2> Sweet! I got 20th overall: [http://js13kgames.com/entries/particularism](http://js13kgames.com/entries/particularism)

I wrote a post today about my two entries: [http://jere.in/12](http://jere.in/12)

Thanks for all the hard work, end33r.

</comment><comment><USER3> Please don't vote for an HN post because someone asks you to. It will probably get the post, and possibly your account, penalized.

You should upvote something on HN because it's intellectually interesting, not because someone is promoting something. The penalties are a shame when the post actually _is_ interesting and could have done well on its own.

<comment><AUTHOR> I'll remember about that, thanks.</comment></comment>


IDPF, EPUB Standardizing Body, Has Combined with W3C - <AUTHOR> http://idpf.org/news/idpf-has-combined-with-w3c <comment><AUTHOR> I believe it a good thing that the EPUB standard will henceforth be further developed by and within the same body that develops the standards on which EPUB relies. After all, EPUB is "stripped down html5" anyway. As a developer of Web-based html5 books, I can certainly see the benefits of becoming enabled to re-use my static html and css 'as-is' and repackage into EPUB-based books for offline consumption by e-readers.

But there's some fierce objection against the merger of IDPF into the W3C [1][2], the key (?) argument being formulated as:

> "The W3C is focused on promoting the Web, but eBooks are not websites. When > the IDPF is gone, who will advocate for readers?"

Maybe a fair point, but I don't think I can agree. While it is true indeed that reading long-form content like books requires enduring focus, and that having to read them in a browser where linkbait always is luring to have you click away into a never ending feed of distraction, the problem is not the underlying technology.

[1] [http://www.publishersweekly.com/pw/by- topic/digital/content-...](http://www.publishersweekly.com/pw/by- topic/digital/content-and-e-books/article/72492-overdrive-s-steve-potash- moves-to-block-idpf-merger-with-w3c.html)

[2] [http://futureofebooks.info/](http://futureofebooks.info/)

<comment><USER2> I thought that WhatWG were actually the ones developing HTML5?

<comment><USER3> WhatWG is just rubberstamping "whatever Chrome implements" (sometimes with feedback from Firefox) as HTML5.

The actual development is entirely controlled by the browser vendors, causing pain for everyone trying to parse HTML programmatically.

<comment><USER4> Because everything went so well when the W3C was left to their own devices...

<comment><USER3> Certainly better than bullying cURL into accepting their idiotic URL specification.

Especially considering what they want would rather be specified as a parser for generating URLs from user input, and not to simply demand every tool interacting with URLs to be able to parse malformed URLs.

<comment><USER5> WHATWG didn't bully cURL into URL, people complaining that cURL didn't match browsers did that.

The WHATWG made a decision long ago that its standards would be descriptive (describe how people parse it), not prescriptive (describe how people should write it). Anyone who attempted to write a web browser would have had to reverse-engineer how other browsers treated crap, because it was the only way to get websites to work. If you think the definition of URL was stupid, you should see what they had to do to support document.all: define a new concept in JS to represent the notion of "this looks and acts like undefined but you can actually use it as an object."

<comment><USER3> And a descriptive standard is entirely useless.

The entire point of a standard is that implementors agree on a design definition, then implement it, and it stays consistent, forever.

If you look at standards that work and fail, you'll quickly notice a pattern. Prescriptive are Metric, the A-series of paper, the entire SI system, most open standards, etc. Descriptive are the imperial / US standard, Letter paper, Microsoft "Open" XML, etc.

And before you complain that prescriptive standards are useless because you can never change legacy systems: Several countries have prescriptive language design, with legal authorities how the language has to be used, and they manage to deal with centuries of legacy data.

<comment><USER5> The email RFCs are prescriptive, and totally useless. I actually have evidence, for example, that RFC 2047 is more often violated than not, and I wonder if message/global will ever see usage as a Content-Type. Prescriptive attempts at tackling memory models in languages have generally failed.

Also, your delineation of prescriptive/descriptive is laughable. The imperial standard, letter paper, and OOXML are all prescriptive standards (albeit OOXML is a very badly written one). Prescriptive language standards aren't necessarily well-applied--ask how many people follow the 1996 German spelling reform, or how many use «le hashtag» instead of the "official" «le mot-dièse» (hint: look at the name of the Wikipedia page is).

OOXML did poorly not because it was descriptive but because it wasn't precise. It was an XML rendering of internal Office file formats, and its description of terms were no better than internal documentation. Something like the TNEF format is much closer to a descriptive document, since it spends a lot of time discussing the differences between Outlook 2007, Outlook 2010, and Outlook 2013 at various steps.

<comment><USER3> Considering I'm German, the 1996 spelling reform was exactly what I was referring to – I've only found a single document this decade which wasn't in the new spelling.

All other documents I read have been updated in the meantime.

If an entire country can update centuries of material in a few years, why is it so hard to update some simple websites, or, in case that's not possible, ship a polyfill as Addon?

<comment><USER5> If a new version of, say, Chrome were to drop the Mozilla/5.0 from its UA and break a website because it relied on Mozilla/* in its UA detection (there are STILL sites that do this), who would users blame? Chrome, obviously.

If you're trying to make a new web browser, it's even worse--people won't use it if it breaks the sites that use it. And the web developer would say "it works in all the major browsers, what's wrong with it and why should I spend the time to fix it for your shitty new browser?"

The problem is that the blame for broken sites is universally attributed to browsers, not website developers.

<comment><USER3> That's why you create a new version that is specifically _not_ backwards- compatible with the old one, ensure all tools have appropriate linters already existing, browsers in developer mode or beta/dev versions fail on such sites, etc; and then let websites opt-in to the new version with a special header.

<comment><USER5> That has been tried before, and that has failed. One of the things that HTML5 fixed was the DOCTYPE mess (in fact, the <!DOCTYPE html> represents the minimal string that enabled standards mode in every browser, including IE). In addition to standards/quirks mode (and the concurrent but separate HTML/XHTML issues), Mozilla tried versioning JS (that was ripped out), and IE tried the compatibility mode switches.

It should be noted that later versions of IE eventually gave up and joined the crowd by having its UA string pretend to be Chrome, which pretends to be Safari, which pretends to be Firefox, which pretends to be Netscape.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> When I was making a simple EPUB app for my own use [1], I found it surprising that many publishers don't follow IDPF standards. Most do, but there are a significant amount that mix and match all sorts of rules.

[1] [http://jathu.me/bisheng/](http://jathu.me/bisheng/)

<comment><USER7> Any pattern to it or anything in particular that struck you?

<comment><USER8> The problem is two fold. The first is that most authors and publishers are not very technical. The second is tools like InDesign created EPUBs that would fail the idpf epubcheck tool with errors [1]. Adobe has fixed some of these issues in later versions, but it's expensive for a publisher to re-export all their books.

What this leads to is basically fixing random, one off issues depending on publisher and book. I would definitely suggest not writing your own reader and instead looking at something like Readium (and contribute if you have time!).

[1] [http://mademers.com/two-more-indesign-cs5-export-to-epub- bug...](http://mademers.com/two-more-indesign-cs5-export-to-epub-bugs-to- report/)

<comment><USER9> I oversee the epub production for an academic publisher, and the epub conversions are created by our typesetter at the end of production. They do indeed do a bit of custom programming (and sometimes manual labor) to make the files come out decent. They're supposed to run epubcheck on every file before delivery. I'm the guy who ends up fixing all those little random errors, so I have to insist that the code be reasonably clean and orderly (they work to a spec document that I prepared). Plus, accessibility is a concern. Poorly coded and disorganized files don't play well for people who need assistive reading systems.

</comment></comment></comment></comment><comment><USER10> This is good news. Making fully baked ePubs for the first few versions of the B&N Nook was more art than science due to some of the problem with ePubs.

</comment><comment><USER11> I guess I've never really understood the need for ePub when PDF is now a standard. I'm sure I'm missing something, the question is: what is that thing?

<comment><USER12> My thought has been more like, "I guess I've never really understood the need for ePub when HTML is now a standard." … which is exactly what this announcement is about.

<comment><USER13> Ideally, ePub would be "reflowable HTML plus baked-in things you would obviously want in a book made dead simple for author-editor-publisher workflows that will never involve a programmer in a million years". Proper footnotes that appear on the same page as the thing they're footnoting, for example.

In practice though this is still a shitshow even in ePub 3, 99% of publisher just ship a pile of endnotes, and consequently certain authors like Terry Pratchett are a god-awful experience in ebook format. Jumping back and forth every 30 seconds sucks.

There are work-around that can be done with JS or certain reader-specific markup you can use for iBooks to at least get pop up footnotes, but most publishing houses don't have the technical knowhow or desire to invest that much time in doing the right thing. There needs to be dedicated markup and a better standard for how readers should treat its display whenever possible.

A real failure of the standardization committee, and it will likely only get worse with a group that cares even less about books specifically. The standard continues to be driven by people more interested in gee-whiz features than solving longstanding problems in replicating table-stakes features of print.

<comment><USER9> Readers complain that ebooks cost too much, and then readers complain that publishers don't want to spend money on technical stuff.

But some of the problem is that there's not a lot of payoff for technical development, because only some platforms will support it. The Kindle doesn't handle Javascript or math at all, has very poor support for tables, SVG art, and video. So there's half your market gone right there.

<comment><USER13> > Readers complain that ebooks cost too much, and then readers complain that > publishers don't want to spend money on technical stuff.

To be clear, I'm complaining that the standard overcomplicated certain desirable feature to the point where publishers would have to spend money on technical stuff, when they shouldn't have to.

I fully get why publishers don't want to have to engage in fiddly, expensive bespoke development per-title.</comment></comment></comment></comment></comment>