Show HN: My MVP for a Travel Recommendation Engine - <AUTHOR>

Many years ago (2007?) I put together this site: http://www.tripzard.com .  I never launched it, because it was basically a MVP/POC so it's not very refined, but I just found it again today and was surprised it still kind of works decent.
The idea was kind of like "Find Your Spot" where you answer a bunch of questions about what you like to do when you travel, and it calculates where the best places for your to travel would be.  Most people I found don't realize there are some interesting options out there instead of just going to Cancun.
What does the HN community think, is this a project worth picking up again?  The site is probably buggy etc.. but it does represent a lot of manual data gathering on my part and there still is nothing out there like this site to my knowledge.  I've always enjoyed travel, geography and history so this project was definitely a joy to work on. <comment><USER2> I just completed running one full scenario (destination South America) and everything (including the results) went perfectly for me.

Now, some observations/suggestions, mainly related to SEO (Based on the current site, I'm nearly sure you already know this, but just in case):

1) Missing Title and meta tags

2) Consider rewriting

<http://www.tripzard.com/results>

to

<http://www.tripzard.com/results/south_america> (or whatever)

and

<http://www.tripzard.com/places/91>

to

[http://www.tripzard.com/places/south_america/argentina/bueno...](http://www.tripzard.com/places/south_america/argentina/buenos_aires)

Let me know if you need me to volunteer any work on this - will be happy to do what I can.

<comment><AUTHOR> Thanks for the tips, makes sense!

</comment></comment><comment><USER2> One quick suggestion, for Step 1 - use IP to geolocation and show visitor's country by default. Can improve the UX just a bit. :-)

I'd call it extremely well thought-out (even if not fully implemented yet) and _way_ too _cool_! (I noticed some fine mod rewrite work there - super cool.)

With travel sector being one of the largest money spinners online, I'd say just floor the gas pedal on this, like _now_ \- I can already see the major (and not-so-major) online travel booking portals scrambling to license this from you.

ps. Give a serious thought to patenting this, urgently.

<comment><AUTHOR> Thanks! Geolocation is a good idea to remove an unnecessary step.

<comment><USER2> Check my thread announcing free geolocation API in case you need it:

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

</comment></comment></comment><comment><USER3> 1\. Too many questions

2\. Ensure that the questions are all ordered the same; that is: conservative response, centrist, liberal (no crime, some crime, crime ok)

3\. Cancun was the first return for me with 100%. Maybe I don't know myself, but I worked in back country Alaska and have crossed the country several times on motorcycle. I'm not the Cancun type. Your copy above says explicitly "instead of just going to Cancun." Hmmmm.

<comment><AUTHOR> That's pretty funny Cancun came up... the algorithm definitely needs work if I continue it, or maybe Cancun is your dream vacation and you didn't realize it ;)

<comment><USER3> Cheers to that!

</comment></comment></comment><comment><USER4> I really like this. Do you have the ability to bring smaller destinations in to the mix as well? (E.g., Moab, Aspen, Zacatecas, Mendoza, etc.)

I agree that there are too many questions. Ideally, I'd like one page of questions, with options to "refine" once I see the results. I think that having shorter questions with standard answers (e.g., "must"/"nice to have"/"don't care"/"don't want") would make it easier to quickly go through.

<comment><AUTHOR> I could bring it to anywhere in theory, just a matter of getting the data. I think I picked all major cities in North America and capitals of most of the rest of the world for this version

</comment></comment><comment><USER5> I think it's a great idea. It would be nice to not have to answer so many questions though. Maybe a few basics, and then let me browse around and "like" things (NOT publicly on Facebook), and then infer what I like. More of a recommendation engine. But then with the option to manually "advanced search" using all (or some) of the questions.

</comment><comment><USER6> Maybe you could have some helpful presets to present some results quickly i.e.

\- 18-24 year old male looking to go nuts <click here>

\- adventurous couple with young kids <click here>

\- boring, retired couple who are scared of ethnic food <click here>

I filled out the profile for Asia and got Bali - which is full of Aussie tourists drinking and surfing but I specifically wanted no night- life/partying/prostitution. Somewhere like Phuket, Koh Samui, Boracay would have been better fits in my opinion. I guess with more data points the accuracy should improve over time.

</comment><comment><USER2> Clickable:

<http://www.tripzard.com>

</comment><comment><USER7> Wanderfly.com has some features to check out. Good use of flickr api.

I had similar idea and found wanderfly, among others.</comment>


Show HN: Star Wars GUI / MultiTouch UI - <AUTHOR> http://chrisgannon.wordpress.com/2014/09/24/star-wars-guimultitouch-ui-controls-again/

<comment><USER2> Hehe -- iOS musicians might recognize the actual app they are using in the clip. It's called TouchOSC ([http://hexler.net/software/touchosc](http://hexler.net/software/touchosc))

Interface.js uses the same vector-art style, though it could use a bit of color: [http://www.charlie-roberts.com/interface/](http://www.charlie- roberts.com/interface/)

<comment><USER3> Even non musicians- the OSC protocol is used a lot in HCI research for prototyping (TUIO is built on top of OSC). For my master's thesis, I implemented a system that allowed a user to seamlessly transfer content (an open picture, playing video, etc.) from device to device in a room (phone, pads, tabletop computers, etc.), and the protocol gluing everything together was built upon OSC.

<comment><AUTHOR> Thanks both for taking the time to check this out and offer these insights and links - I was so blown away by the UI on the Star Wars demo I was sure they'd probably developed it themselves. Looks like I didn't need to build these at all! (Although I will be rebuilding these using SVG and doing tutorials on them as I go along).

</comment></comment></comment><comment><USER4> Any chance you'll put this on github? It would be amazing to use this style of retro-futuristic UI to control my laser hardware in realtime. Plus it's Star Wars. :)

Great work! It looks fantastic.

<comment><AUTHOR> Yeah I'll get them up there at some point. The code is less than presentable right now though - I'm slightly embarrassed by it ;)</comment></comment>


Show HN: Toasted – Remove gender bias from your writing - <AUTHOR> Toasted tells you how gender-specific the tone of your writing is. By following its suggestions, you can tune your writing to better engage with male or female readers.
https://www.isittoasted.com/ <comment><USER2> I pasted in several of my more recent blog posts. I seem to be pretty consistently gender-neutral, though sometimes indulge in masculine words like "feeling" and "goal", and in feminine words like "feel" and "daily".

<comment><AUTHOR> Thanks for taking a look! "Feeling" and "feel" are both pretty close to neutral, but it looks like the different in verb tense is responsible for them being on different halves of the spectrum.

<comment><USER2> Where does the data come from? How do you determine the gender bias of a word?</comment></comment></comment>


Show HN: Sodaphonic – record and edit audio in the browser - <AUTHOR> https://sodaphonic.com <comment><USER2> Hey, I have also done an audio editor and recorder in the browser! All the audio is stored and processed on the server. You can Check it out there: [https://twistedwave.com/online/](https://twistedwave.com/online/)

<comment><USER3> Upload as guest failed. The same file worked on Sodaphonic.

</comment></comment><comment><USER4> Neat! I sometimes think it would be interesting to develop a web-based podcast production platform, where a similar sort of feature would be available for post-production. But also use WebRTC for conferencing, streaming, allowing callers to "dial in" to live shows and wait their turn, etc.

<comment><USER5> I think Cast does something like that? I haven't used it myself, so I'm not 100% sure what features they offer. But it sounds like they handle streaming audio between co-hosts, recording individual tracks, and doing the post-show editing. [https://tryca.st](https://tryca.st)

</comment></comment><comment><USER6> I don't have any audo files on my desktop. would be nice to have a default so i could play around without hunting for one

<comment><AUTHOR> If you're using Chrome or Firefox, you can try it out by just recording something. Might not be clear enough, so thanks for the feedback!

</comment></comment><comment><USER7> Really nifty! I can see where this is useful if there's no Sound Recorder handy. However, would it be possible to add simple tuning features such as gain/boost, pan, pitch bend, and maybe reverb?

<comment><AUTHOR> Thanks! Yes, definitely. On the list.

</comment></comment><comment><USER8> Hm, might be functional but also doesn't really offer a lot of utility or even gimmicks in my opinion. Yes it works, seemingly okay. Not sure I'm really too crazy about the Export to Wav or MP3 function, that kind of opens a Copyright can-of-worms issue when given some thought.

<comment><AUTHOR> I'm not sure I understand, what copyright issues can you envision?

<comment><USER9> The MP3 codec is patented in the US, due to expire at the end of next year: [https://en.wikipedia.org/wiki/MP3#Licensing.2C_ownership_and...](https://en.wikipedia.org/wiki/MP3#Licensing.2C_ownership_and_legislation)

</comment></comment></comment><comment><USER10> I love how people start working on related projects around the same time without shared knowledge. I'm working on a web based audio tool to help vocal actors right now and learning about the apis. It's not an editor but uses some of the underlying tech.

</comment><comment><USER11> I wrote one of these a while back, yours is nicer. Now I don't have to put mine back up!

[https://github.com/meandavejustice/metastaseis](https://github.com/meandavejustice/metastaseis)

</comment><comment><USER12> I tried a variety of ways to upload a file but can't get it working. Both dragging and dropping, and clicking the button and selecting a file, didn't do anything as far as I can tell.

Running Firefox 48.0 on Linux

<comment><AUTHOR> Thanks for letting me know. Will look into it!

</comment></comment><comment><USER13> Hey, I did one too! All client side, with wave editing and export: [https://wav.hya.io](https://wav.hya.io)</comment>


Ask HN: Does it exist? A system to manage my recurring Web App payments - <AUTHOR>

I've seen dozens of solutions that help a business collect and manage recurring payments from customers, but I can't seem to find a solution to manage my recurring payments to the myriad of web apps I use. Does it exist?<p>I often worry that if I setup a recurring payment, I will forget about it and stop using the app at some point but let the payment continue recurring (and waste money). <comment><USER2> For the apps that accept paypal, it's a decent common point of contact to maintain all recurring subscriptions. It allows me to see all my current, old subscriptions at one place and i can discontinue one at any point.

<comment><AUTHOR> Yeah, I thought of PayPal, but can't stand using it.

<comment><USER2> Can you elaborate on the reason?</comment></comment></comment>


Collision Course: a type of road junction that is dangerous for cyclists (2018) - <AUTHOR> https://singletrackworld.com/2018/01/collision-course-why-this-type-of-road-junction-will-keep-killing-cyclists/ <comment><USER2> Someone saw the Tom Scott video about this from a couple of days ago? [https://www.youtube.com/watch?v=SYeeTvitvFU](https://www.youtube.com/watch?v=SYeeTvitvFU)

<comment><USER3> Is it somewhat ironic that at :15 seconds into the video a car hurls through a stop sign?

<comment><USER4> At 1:26, a car rolls through it too. Quite as a few, as he sort of points out near the end.

I like this as an example of a problem that can be solved by engineering far more easily than by changing human behavior.

</comment></comment></comment><comment><USER5> Another solution is to block off the eastern exit, turning it into a T junction. It's low traffic, there are multiple alternative routes and the road to the east is short and insignificant. This technique is used a lot in towns nowadays to shut off dangerous junctions onto arterial routes (and to prevent 'rat runs').

The alternative route round works out at 5 minutes longer but in a national park that's pretty good, and the lives saved should be worth it. Map view here: [https://www.google.co.uk/maps/place/Ipley+Manor+Stables/@50....](https://email@example.com,-1.4616827,15z)

<comment><USER6> An even simpler solution that I have seen implemented on some open field crossings is to deliberately block the view line somewhere close. It doesn't have to be blocked on the entire approach, just enough to ruin the illusion of having sufficiently observed the entire crossing road. It could be a billboard with traffic safety propaganda (or ads), some greenery or a stack of photovoltaics. Not much bigger than a bus usually.

<comment><USER7> this solution is actually discussed in the article and dismissed because it would be very visually intrusive with the rest of the forested land and because careless drivers might still only give a quick glance after not seeing any cars while approaching the junction from far away.

<comment><USER8> Right, they presume that the entire approach would have to be covered. But the parent asserts that a short fence would be enough. (I'm inclined to agree.)

</comment></comment></comment></comment><comment><USER9> Something to add to this is that 'stop' signs are pretty rare in the UK compared to somewhere like the US. People wouldn't be expecting a 'stop' sign at a junction like this, so they're expecting to yield, and due to the blind spot they think they are yielding.

<comment><USER10> > People wouldn't be expecting a 'stop' sign

It's bright red!

<comment><USER9> > It's bright red!

I'm not saying it isn't.

But in the UK most junctions are yield, so drivers don't approach junctions thinking 'I might have to stop' they think 'I'll have to yield', so if they aren't paying attention their default is to yield.

<comment><USER11> Are there not multiple warning signs there's a stop sign ahead?

The MUTCD version: [https://upload.wikimedia.org/wikipedia/commons/7/7d/MUTCD_W3...](https://upload.wikimedia.org/wikipedia/commons/7/7d/MUTCD_W3-1.svg)

<comment><USER9> I think that's an American sign. The context of the article is the UK. We don't that exact sign in the UK. I think there is a 'stop in 100 yards' sign but I can't recall ever seeing one. But the point was people aren't paying attention to the signs... so another sign doesn't solve that.

<comment><USER11> MUTCD == the (American) Manual on Uniform Traffic Control Devices, it was intended to demonstrate what I was talking about.

If you add multiple (large) signs ahead of the actual control device, you'll have higher compliance, since the unusual sign doesn't appear out of the blue.

<comment> 2019-nCoV Maybe in NA. In the UK the likely solution would be to install a roundabout. You can't ignore an upcoming obstacle, in which you're forced to give way.

<comment><USER12> Gotta say, as a biker, I love roundabouts for that reason- and people who _don 't_ ignore the obstacle go flying [1]. As a driver, I love the idea of drifting around one sometime when I have the skill and there's legitimately nobody nearby. Also forces people to focus, which is nice.

[1] [https://duckduckgo.com/?q=car+hitting+roundabout&t=vivaldi](https://duckduckgo.com/?q=car+hitting+roundabout&t=vivaldi)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> When 2 objects are on a collision course moving in straight line motion, the heading to the other object does not change.

For this reason, efforts to detect asteroids heading toward earth by detecting their motion against the background sky will fail over short time spans. That's because the ones on an actual collision course will not appear to move against the background for a few days prior to impact. An impactor will seem to come out of nowhere.

<comment><USER14> The Earth moves in an orbit around the sun, so the only way this would be a problem is if the asteroid were not visible at all until only a few months (or even less?) before impact.

<comment><USER15> To a first-order approximation, and from far enough away, a collision with the Earth is a collision with the Solar System.

Our motion within the Solar System is relatively small if the asteroid is a very long way away; it's easy to find scenarios where a fast moving asteroid will appear stationary over a 6 month period.

</comment></comment></comment><comment><USER16> Reminds me of the time I almost died riding on The Embarcadero. This [https://www.google.com/maps/place/Embarcadero,+San+Francisco...](https://www.google.com/maps/place/Embarcadero,+San+Francisco,+email@example.com,-122.4039694,179m/data=!3m1!1e3!4m5!3m4!1s0x80858066993643ad:0x77178399d59a1e7f!8m2!3d37.7992627!4d-122.3976732) is the intersection. This is the link to the view you would have as a cyclist [https://firstname.lastname@example.com,-122.4030922,3a,74.5...](https://email@example.com,-122.4030922,3a,74.5y,268.57h,70.82t/data=!3m7!1e1!3m5!1sAF1QipPQXGu79Rxu575JjSzjZsyxcwoAZ6fZo0LticqV!2e10!3e11!7i11000!8i5500)

Long story short, I was an idiot cyclist thinking I had calculated everything[1], when in fact, I hadn't. Someone in a car going northbound at about 60mph on Sansome had to slam on their brakes to save my life as I crossed from the right bicycle lane to chestnut. I was super lucky they were watching, and their brakes worked, and that they had enough reaction time.

From then on I have never ran stoplights. The problem is that, as they say, the first one is free. You might start out as a cyclist running a simple stop sign on a dead street. But as you get more comfortable, the temptation is to run ever more complex street lights. In my case, I only did it when I didn't see any cars. The problem with intersections like this is there are cars you _cannot see_.

[1] - Things to calculate:

1\. Southeast bound car traffic on Embarcadero.

2\. Whether there were southeast bound muni trains on the Embarcadero dividing route.

3\. Whether there were northwest bound muni trains on the Embarcadero dividing route.

4\. Cars behind you on northeast bound Embarcadero ( I had to cross from the bikelane on the left )

5\. Northbound cars on Sansome. This is what I missed.

<comment><USER17> I don't know who needs to hear this, but the driver who gets mad at you for running a light might be a fellow or former cyclist.

There is nowhere you gotta be that is so important that you should be committing moving violations to get there. The rules of the road apply to you ever bit as much as a car, and you have absolutely no moral authority at all if you won't even follow the goddamned traffic laws.

You are not only risking your own life, you're making the rest of us look bad, and creating hostile drivers that other people have to deal with.

<comment><USER18> I don't run lights myself, but I don't agree with the theory of perfect symmetry of moving violations. The risk one poses to others by breaking traffic laws is different for a pedestrian, a cyclist, a car, a semi-trailer, and a jumbo jet. Insisting that all violations matter the same is nonsensical.

In places, this recognition has actually been codified into law (see [https://en.wikipedia.org/wiki/Idaho_stop](https://en.wikipedia.org/wiki/Idaho_stop)).

<comment><USER19> I'm not really certain where I stand on that, but several thoughts come to mind.

It's If a bicyclist and a driver approach a four way stop and the driver runs it, he can kill the bicyclist. If the bicyclist runs it, the driver can kill the bicyclist. While the risk is not symmetrical the outcome is the same.

One would think that the party with more risk would be less likely to run the stop sign but in my experience (which is probably not typical world wide) in the Bay Area the opposite is true. Although admittedly it seems the law just isn't enforced here. Maybe unequal laws would more likely be enforced and some combination of personal risk plus enforcement would achieve the desired outcome.

Additionally many bicyclists are also drivers. So it might be prudent to penalize them for the behavior equally so that it discourages the behavior in general and removes dangerous drivers more easily; assuming their behavior on different vehicles correlates.

<comment><USER20> I add another point. All cyclists are also pedestrians. Maybe not in the Bay Area but pedestrians often run traffic lights when there are no approaching vehicles. A cyclist feels closer to a pedestrian than to a driver in my experience. So, no traffic, no danger, run the traffic light. The same cyclist (and pedestria) will stop when driving a car.

<comment><USER21> As someone who runs red lights from time to time both as a pedestrian and cyclist I more or less think this is the general view, especially if we take into account that bicycle lanes, at least in my country, often are linked to the pedestrian lights. I would never run a light in a car and if I ride my bike on the road I behave as a car.

Another imo. important part of this is the (perceived) risk of running a red light. If I run a red light on my bicycle I yield for everyone, i.e. my speed is low and I only have to watch for cars that go straight through the crossing which are easy to predict. Basically no need to interact with anyone, simply watch out for cars. Following the lights is the opposite, my speed is generally higher and I have to interact with turning cars. All crashes involving cars that I've been in have either been cars that should have yielded when turning or cars that are blowing through stop/yield signs. This is generally how bicyclists get hurt and I mainly see it as an infrastructure issue. The problem is that infrastructure is relatively expensive to change and so the blame often seem to focus on the cyclist for "not following the rules" or "not wearing a helmet" and nothing really seems to change.

<comment><USER20> Yes, that's it. Actually infrastructure did change in the last 30 years (roundabouts, etc) but to make cars safer, not bicycles. Those improvements were quite successful. Unfortunately they bring cars closer to bicycles any time they narrow the road. Old style intersections like the ones in the article suffer from the constant bearing problem but the cyclist can usually see a car coming from the other road. A car approaching from behind doesn't have to steer toward the side of the road where the cyclist is. With roundabouts and narrow lanes, not much so. Modern roads are also much more dangerous for pro riders. Check how many crashes there are in a bunch because of infrastructure built for cars. That was not the case in the 90s.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> If anyone's looking to learn more about road layouts (who isn't?!), Road Guy Rob has a good channel:

[https://www.youtube.com/channel/UCqdUXv9yQiIhspWPYgp8_XA](https://www.youtube.com/channel/UCqdUXv9yQiIhspWPYgp8_XA)

</comment><comment><USER23> Every road is dangerous for a cyclist. Really the only solution is to adopt pedestrian-centric traffic laws like The Netherlands or Japan.

In Japan, blowing a stop sign and killing a cyclist would be a "dangerous driving causing death" charge, which would result in a prison sentence, loss of your license, a fine, and ~$1,000,000 in compensation to the family of the person you hit.

<comment><USER24> In reality, it doesn't always work quite like this. Japan has a system of assigning a percentage of blame to both parties in a traffic accident. "He was 80% to blame for not yielding, you were 20% to blame for being too far out in the road."

While in general this system works fairly well, there does seem to be a lot of pressure to share blame as much as possible. The only person I know how got 100%/0% was T-boned by a driving going through the middle of a red light.

Also, cars are often judged to be be much more at fault than cycles. Perhaps this is why bicycles can often be very reckless on the roads: taking blind corners without slowing down, cycling on the wrong side of the road against traffic etc.

<comment><USER23> In reality it does work quite like that if someone dies and you are judged to have driven dangerously (危険運転致死傷罪).

</comment></comment></comment><comment><USER25> This is a fascinating look at a perfect storm of a junction. For both vehicles to be unaware of each other just seems unfathomable, especially that this occurs in a place where you're effectively on an open plain with good visibility in all directions.

I've stayed down the road from here (East Boldre) on a number of occasions so I'm familiar with the junction having both driven and cycled through it. I've even cycled through there with my kids in a bike trailer, which makes me feel a little sick.

A number of comments are suggesting larger engineering endeavour to fix the issue so it's probably worth pointing out a few things about the environment, as it's a fairly unusual place. This is a national park that's been fairly untouched for a long time. There are a lot of large animals wondering around but rather than being fenced in, they mostly roam freely. They often just have reflective collars to help stop collisions at night where they frequently congregate on the road.

Furthermore, in the Uk in general, intervention seems to be strongly discouraged. Certainly compared to NZ, where I grew up, over here there seems to be more of an expectation that people should do the right thing without being nannied. I was told that when it comes to road intervention, it's only post incident that changes will be made to prevent future situations from occurring.

Another anecdote. Where I worked in south London there was a junction on a hill where traffic coming down the hill wasn't allowed to turn across the traffic coming up. There was a sign, but it wasn't especially obvious. On a weekly basis there was a surveillance van with a camera that sat the fining people (later, through the post) if they broke the no turning rule. We complained to the council a number of times about it because we often saw near misses. It wasn't until the day a motorbike went through a car windshield that a change was implemented. And, even then, it was only a chance to the signage.

</comment><comment><USER26> I read this article a while back, and immediately one intersection in my locale came to mind. So on my next trip through it in my car, I took a careful look. Sure enough, my impression was that it would be hard to see a cyclist, or even an approaching car. Of course I'm always careful, but now I'm extra careful.

</comment><comment><USER27> I'm curious about whether planting trees and bushes would help. This would make drivers know that they haven't seen the other road, and would make them slow down on approach to the junction.

<comment><USER28> That's not the worst idea, like that they'll take the stop sign serious. In Europe, stop signs can only be installed at certifiably dangerous junctions, but in the current state the intersection doesn't look half as bad as it actually is. With a few strategically placed bushes impressions might actually match on-the-ground facts.

</comment></comment><comment><USER29> Was doing some charity bike ride when I was 16 and, halfway through, there was something like this. I'd zoned out and was gonna cycle on through the intersection when someone called out for me to stop. If I hadn't, I'd have been splattered by a speeding Corvette. I wonder if this may have played a factor.

</comment><comment><USER30> As an American I find it very odd that they blame the angles of the roads for making it dangerous. Until recently that intersection had no stop signs. One road had a yield, meaning most of the time no one stops in _any_ direction, on _either_ road. That gets drivers in the habit of not stopping.

Maybe if varies by state, but I grew up in a rural area of California, but every intersection I can remember has had at least one road required to stop (either a two-way stop sign, four-way stop sign, or traffic lights).

I get that stop signs are nearly illegal in the UK and some other parts of Europe, but that is the problem. In the US a driver on the minor road has to stop, look both ways, then proceed. It is to much safer than the driver on the minor road getting in the habit of not stopping and just plowing through a road that has the right of way.

<comment><USER31> The problem with stop signs is that cyclists also need to stop and on a bicycle you really notice all the wasted energy.

<comment><USER30> On this intersection the cyclists that got hit were on the main road, meaning they wouldn't have to stop.

If a cyclist on the minor road had a clear view, slowed down down, and looked both ways, they wouldn't need to come to a complete stop. A cyclist treating a stop sign like a yield sign is pretty only endangering themselves. A motorist plowing through a yield sign that should be a stop sign, or plowing through a stop sign, that is dangerous to other people.

</comment></comment></comment><comment><USER32> Why is the cost to bend one of the roads slightly, creating an offset junction, £100,000?

<comment><USER33> My guess: purchasing the land, paying for studies, laying new road, removing old road.

£100,000 sounds cheap. Two people already died. If I was a family member of a third victim, I would've wanted the government to pay £100,000. I would be asking government officials if it was worth it.

(Approx 125,000 USD at today's exchange rate)

<comment><USER32> There's a linked response from Hampshire County Council [1]:

"We are working with partners at New Forest District Council, the National Park Authority, English Nature, The Verderers, The Forestry Commission and the police to explore what can be done longer term and are currently carrying out a review of the junction, which we hope to finalise in the new year. The land beyond the paved road surface is Crown land and this will require permissions to be granted to us for any realignment of the road to be carried out."

Crown land (part of the national park, presumably) means it "belongs" to the queen, so that shouldn't be an issue.

Other comments on that discussion say the same offset junction has been done in many other places.

The best thing is probably for anyone who lives in Hampshire to write to their MP.

[https://beyondthekerb.org.uk/collision- course/#addendum](https://beyondthekerb.org.uk/collision-course/#addendum)

</comment></comment></comment><comment><USER34> I read this article when it was out two years ago, and this is the most important takeaway from it:

> And secondly, significant movement of the head will bring previously > obscured sections of road into view.

I've been doing it ever since, always translating and rotating my head quickly on crossings.

</comment><comment><USER35> Previous (quite lengthy) discussion:

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

</comment><comment><USER36> I wonder if a "Stop Ahead: XXX Killed at this intersection" sign would be effective. Sure it's non-standard. But that's something of a +1 in this situation.

<comment><USER37> I've often thought it would be useful to put a permanent marker of some sort at the spot of every traffic fatality. In the US, people often put crosses up, but this is haphazard, and of course can't be in the roadway. Maybe a painted gray X or something.

The point is that a crap-ton of these would serve as a useful warning to the wise.

</comment></comment><comment><USER38> They could install at least two speed humps on approach, one, to disengage the blind spot and a second really large one to force cars to almost stop.

<comment><USER39> From the article:

>Speed bumps are a reasonable idea in terms of being a low-cost intervention, but regulations permit their use only under street lighting, so they cannot be used here.

<comment><USER40> Also (adding more detail): The reason why you can't install lights is because there aren't any wires for the electrical grid, so that would cost a lot of money to add, and the locals would likely object to the extra source of light pollution.

</comment></comment></comment><comment><USER41> I follow him on the why the cars don't see the cyclists. Why don't the cyclists see the cars?

<comment><USER42> The Tom Scott video has a good animation on this: [https://youtu.be/SYeeTvitvFU?t=119](https://youtu.be/SYeeTvitvFU?t=119)

Because of the layout of the junction the cars are actually approaching from behind the cyclists.

<comment><USER43> Wow: The _very first_ car in that video to arrive at the stop sign fails to stop.

Of the vehicles in the video we see traversing a stop sign, I count 5 cars that come to a stop and 5 that do not. (One bicycle crosses: it comes to a complete stop).

<comment><USER32> That surprised me.

Stop signs are so rare in the UK -- I can only think of one in the area I grew up -- that they're taken seriously. Or at least, I thought they were.

"Until 2016, each stop sign had to be individually approved by the Secretary of State for Transport.", though that requirement has been removed.

</comment></comment></comment></comment><comment><USER44> I have an idea. What about putting a solar powered radar that lights up a flashing sign when cross traffic is detected to draw the driver's attention. Even better would be coupled with signalling that indicates which direction a vehicle is approaching from. Even more advanced would be to compare the vehicle speeds from both roads, and change the warning from yellow to red flashing lights if a collision is immanent.

Actually, I'd like to see that last part put into place at any hazardous intersection, in case a driver misses seeing a stop sign or red light.

<comment><USER45> Generally one would prefer safety features to be fail-safe, not fail-deadly, i.e. traffic lights that give you green when there is no cross-traffic is OK, but warning only if something is detected is used only in limited circumstances.

</comment></comment><comment><USER46> The author dismisses the question of why the cyclist shouldn't check the cross traffic by implying it's onerous or unexpected to do so becauseof the angle. IMO this intersections real problem has little to do with visibility acronyms and everything to do with simply two roads intersecting with nothing to adjudicate the intersection. I bet $100 the are even more car-car crashes here than car-bike crashes.</comment>


Open Source microblogging - <AUTHOR> http://status.net/ <comment><USER2> What we need is not only open source microblogging, but also distributed, decentralized microblogging network.

I suggest each personal domain's _microblogging.example.com has a TXT to show the current status.

<comment><USER3> Would something like this maybe work?

.

.

.

Decentralized microblogging protocol

\</comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>

"Microblogging" is the generation and recipient-directed distribution of short (typically less than 140 characters) posts. There are four fundamental actions: making a post, requesting past posts, and subscribing and unsubscribing from future posts. A "post" is a piece of text produced by a user at a particular time.

Given an open connection to a microblog server, here is how each of the four actions works:

1\. making a post

The user sends one line:

"post " <username> " " <secret> " " <text> CR LF

If the username or secret contains spaces, double-quotes, or backslashes, or is empty (for example, if the user connected over SSL with a client cert, there is no need for a secret), it must be enclosed in double-quotes and any double-quotes or backslashes preceeded with a backslash. The server responds with either

"ok" CR LF

or

"error " <message> CR LF

.

2\. requesting past posts

The user sends one line:

"request " <requestee> " " <n> ["posts"|"seconds"] CR LF

The server responds with any number of lines of the form

"post " <timestamp> " " <text> CR LF

where <timestamp> is the time that particular post was made, as seconds since 1970-01-01 UTC, and <text> is the text of the post. There should be one line for each post made by the user <requestee> not more than <n> seconds old, or one line for each of the last <n> posts made by <requestee>. After sending all the posts it will send, the server should end with a line

"done" CR LF

.

3\. subscribing to new posts

The user sends one line

"subscribe " <requester> " " <requestee> CR LF

to request that the server forward any posts made by <requestee> to the requester by connection to the microblog daemon on the host the connection was made from. The server responds with

"ok" CR LF

or

"error " <message> CR LF

.

4\. unsubscribing from new posts

The user sends one line

"unsubscribe " <requester> " " <requestee> CR LF

to request that the server cease forwarding posts by <requestee> to <requester> at the connecting host. The server responds with

"ok" CR LF

or

"error " <message> CR LF

.

Subscribing (and unsubscribing) require a way for a microblog server to forward posts to another server. So we have a fifth action:

5\. forwarding posts (server-to-server)

The origin server connects to the target server and sends one line

"forward " <requester> " " <poster> " " <timestamp> " " <text> CR LF

. The target server responds with

"ok" CR LF

or

"error " <message> CR LF

. In the case of an error response, the origin server may wish to pretend that the target user has unsubscribed. A server may try to forward posts to non- subscribed users, but shouldn't be surprised if it gets an error response.

...what would be good ports for this, 5544 for plain and 5545 for SSL?

<comment><USER4> Why invent a new protocol for this, rather than just using HTTP?

<comment><USER3> How would that help? You'd still need to put just as much work into defining request and response formats, so it would just be a useless layer of bloat.

<comment><USER4> 1\. Every language under the sun would already have a client library for talking to it

2\. Existing mechanisms for scaling HTTP (caching proxies, HTTP-aware load balancers) would work out of the box

3\. HTTPS would be available if you needed it

4\. You wouldn't need a new port assigned, and existing firewalls wouldn't need to reconfigured.

5\. You wouldn't get people like me asking "why not just use HTTP?"

<comment><USER3> 1\. Using HTTP does not save having to properly format requests or parse answers. What makes exchanging messages by means of an HTTP library easier than exchanging messages by means of the socket library that that HTTP library is built on?

2\. Hm, maybe. Or maybe using HTTP would increase the need for such mechanisms. ...How much would be cacheable, anyway? About the only thing would be fetching past posts, and I'd expect most of that to come from web frontends anyway (which would have their own caching).

3\. HTTPS is just HTTP over SSL. SSL is available without having to use HTTP.

4\. Hm. Maybe dns SRV records could be used to get around needing a port assignment, and what firewalls would actually matter? I'd think it would be like smtp/pop/imap, people just use webmail clients and their firewalls don't care.

5\. :) I just don't see that requiring http for something that would in practice be almost entirely for server-to-server communication would actually provide any benefits.

...hm. I included a spec on how to make posts thinking that it could also be used by client programs, but the connect-back design for forwarding messages wouldn't work for that. :(

<comment><USER5> 1\. HTTP includes verbs to handle everything you mentioned. Posting is a POST, listing is a GET, getting a single message is a GET, subscribing is a POST, deleting is a DELETE, etc.

2\. Many networks use proxies and caches such as squid, varnish, etc. My servers are locked down with iptables, and I would have to open up ports in order for them to speak a new protocol

3\. What's your point? Your protocol is just a layer over TCP. Why not just use TCP? And TCP is just a layer over IP. Why not just use IP? Following your logic takes us back to early DOS days where each program drives each piece of hardware directly.

4\. Your argument against using HTTP is that ... people are just going to use HTTP anyway?

5\. With libraries such as Rack and WSGI setting things up to speak HTTP is too easy. Not to mention node.js, mochiweb, etc.

<comment><USER3> TCP provides reliable streams, which IP doesn't. HTTP takes those reliable streams and provides... what, exactly? I guess it turns the streams into request/response message pairs (with lots of extra headers), but that's not nearly as useful - especially since parsing messages out of a stream really isn't harder than understanding the contents of the messages themselves.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> an example would be great; i'm confused about what this is. the open source part indicates technology, but the site looks like some guy offering consulting to businesses.

<comment><USER7> <http://identi.ca/> is a public microblogging site running the laconica/status.net software.

<comment><USER8> Is status.net a rebranding of laconica, or a fork of some sort?

edit: looks like a rebranding <http://status.net/2009/08/28/laconica-is-now- statusnet/></comment></comment></comment>


Why is it so hard for developers to work with non-developers? - <AUTHOR> I've noticed that it's often very difficult for to work with non-programmers.<p>* Non-technical people often express doubt about answers provided by programmers.<p>* Programmers often to have to explain and explain and re-explain or risk sounding condescending if they say anything that even remotely sounds like 'you're not a programmer; you wouldn't understand".<p>* Non-technical people try to 'help' by Googling stuff and sending links. I've literally had non-technical users email me StackOverflow answers to absolutely unrelated problems, and other stuff like Wikipedia articles that are only tangentially related.<p>What does HN think about good strategies to avoid feeling stressed out by trying to work collaboratively with non-technical people? <comment><USER2> You may want to consider rephrasing your question to, "Why is it so hard for me to work with non-developers?"

Please take this in the spirit it is intended, which is to help you not feel stressed.

I think the most helpful thing you can do is understand the priorities of the non-developers and speak to those points. If the non-developer believes you understand their priorities they will have confidence in you, and they will take your input/responses at face value.

If you think that your ability to communicate with non-developers is limited find an example that you can learn from to improve your effectiveness. Sales engineers are technically proficient, but they have the ability to present and communicate to non-technical parties in an effective manner. Part of the key to that is focusing on the objective rather than getting someone to understand something as well as you do.

</comment><comment><USER3> _" Why is it so hard for developers to work with non-developers?"_

It's not hard for all developers. I've been working with non-developers for decades, both as a developer and a development manager, and I haven't found it difficult (and as far as I know, they haven't found it difficult to work with me either).

 _" Non-technical people often express doubt about answers provided by programmers."_

Programmers (including myself here) often give the wrong answers. A healthy degree of skepticism is a good thing to have.

 _" Non-technical people try to 'help' by Googling stuff and sending links..."_

I've never encountered this.

 _" What does HN think about good strategies to avoid feeling stressed out by trying to work collaboratively with non-technical people?"_

You have to remember that developers are just a small part of what makes a company work (even a tech company), and that the other people are just as important as you are. For example, without salespeople, there may not be any revenue from which to pay the developers. Without QA people, the developers' code might be too buggy to release. Without product managers, there may not be a sense of which direction a product should go. We all have to work together.</comment>


Is High Quality Software Worth the Cost? - <AUTHOR> https://martinfowler.com/articles/is-quality-worth-cost.html <comment><USER2> Most of the time when a team is writing low quality software it's not really a choice. No one made a conscious decision not to write tests, not to do PR reviews, or not to refactor. It's actually that the developers _are not capable_ of writing tests, reviewing code, or refactoring to a sufficiently useful level that it's worthwhile. If you've come in to the industry and joined a company that doesn't do those things then you've never learned those skills.

Where Martin Fowler says you'll see the benefit of high quality code in a few weeks he's making the assumption that the team is capable of writing high quality code but choosing not to, whereas it's actually more likely to be the case that the team would need to go away and learn how to write high quality code before they can start, including things like learning how to write testable code in the first place. That is a much bigger and _much_ more time- consuming problem.

The article is absolutely 100% correct that high quality code lets you go faster but it ignores the root cause of the problem - developers have been writing low quality code for so long that unlearning all the bad habits and actually _getting better_ is a _huge_ undertaking.

<comment><USER3> It's important to note that having high test coverage doesn't make code good. Unit tests will actually make bad code even worse because it will be even more difficult to change the underlying logic (because the tests lock all the poor implementation details into place).

Tests have nothing to do with code quality. All they do is verify that the code works. I would argue that the simpler and therefore the better your code is, the less you need to rely on tests to verify that it works. Fewer edge cases means fewer tests.

I'm a big fan of integration tests though because they lock down the code based on high level features and not based on implementation details. If you ever have to rewrite a decent portion of a system (e.g. due to changing business requirements) it is deeply satisfying if your integration tests are still passing afterwards (e.g. with only minor changes to the test logic to account for the functionality changes).

<comment><USER4> _> Tests have nothing to do with code quality._

I didn't downvote your comment but I vehemently disagree. Mission-critical code such as NASA flight guidance, avionics, and low-level libraries like SQLite depend on a suite of tests to maintain software quality. (I wrote a previous comment on this.[0])

We also want the new software that commands self-driving cars to have thousands of tests that cover as many scenarios as possible. I don't have inside knowledge of either Waymo or Tesla but it seems like common sense to assume those software programmers rely on a massive suite of unit tests to stress test their cars' decision algorithms. One can't write software with that level complexity that has life-&-death consequences without relying on numerous tests at all layers of the stack. Yes, the cars will still have bugs and will sometimes make the wrong decision but their software would be _worse_ without the tests.

High quality software relies on both lower-level unit tests _and_ higher-level integration tests. Or put another way, both "black box" and "white box" testing strategies are used.

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

<comment><USER5> Isn't this disagreement basically the same point made by Martin about different kinds of quality? SQLites tests don't say the code is architected well and reusable and modular and blah blah blah, it says that it works. When people talk about the quality of NASA code or SQLite, that feels more like external quality than internal quality.

<comment><USER6> The 100% MC/DC testing in SQLite does not force the code to be well- architected, but it does help us to improve the architecture.

(1) The 100% branch test coverage requirement forces us to remove unreachable code, or else convert that code into assert() statements, thereby helping to remove cruft.

(2) High test coverage gives us freedom to refactor the code aggressively without fear of breaking things.

So, if your developers are passionate about long term maintainability, then having 100% MC/DC testing is a big big win. But if your developers are not interested in maintainability, then forcing a 100% MC/DC requirement on them does not help and could make things worse.

</comment></comment></comment></comment></comment><comment><USER7> I love the opening sections of this article, but the end left me feeling wanting.

> the best teams both create much less cruft but also remove enough of the > cruft they do create that they can continue to add features quickly. [...] > They refactor frequently so that they can remove cruft before it builds up > enough to get in the way.

In my experience in several large teams over 20 years, this is not a great summary of what actually happens. What actually happens is accumulation of customer requirements. We build new features and the old features that don't fit easily with the new ones are not allowed to be removed. Everyone on the team wants the old features removed, and at the same time, the team reaches consensus that doing so would alienate loyal customers and lose business.

The decision is to avoid financial risk, not to drop software quality. The new features are also required, and so compromises and complications arise from supporting both. This is the main source of what is being called "cruft" here. I've seen truly great engineering teams, I've never seen engineering teams good enough to withstand conflicting requirements between old and new features. I don't know what the solutions are, but I'm suspecting the thinking on solving this these days is planning a year or two ahead, publishing the deprecation schedule of old features. This takes a certain kind of management that is willing to sacrifice a few dollars today for the bigger picture, it isn't easy to find.

<comment><USER8> That's true. A lot of people think that being customer centric means to exactly do what the customer says. But sometimes you have to say "no" or propose different ways to achieve their goals so you can keep the software architecture halfways clean. Unfortunately it doesn't help that often engineering is not allowed to or doesn't want to talk to the customer directly so a lot of these trade offs never get to the customer.

<comment><USER9> > achieve their goals so you can keep the software architecture halfways clean

That sounds... like a bad decision. We create compromised software solutions to support the business, we don't compromise the business to support the software (unless it involves the safety of others).

<comment><USER8> You have to have a balance or you will reach a point where the software is so compromised it can't support the business.

<comment><USER9> I've rarely seen that happen, but I have seen the inverse (over-engineering) hurt businesses considerably more. I'll stick with the devil I know.

</comment></comment></comment></comment></comment><comment><USER10> What high quality software?

I work in the public sector in Denmark, we operate 300-500 systems from private suppliers and none of them work, none of them are particularly cheap either.

Our medical software on life supporting machinery is about the only software that actually always does what it's supposed to, but it goes decades without changes. Everything else is a broken mess, regardless of what principles of development the companies adhere to.

I think the only software that we operate, which is both high quality, stable, secure and capable of adding/removing features when we ask is our dental software, and that's actually some of the cheapest software that we buy. It's not made by a tech/development-house though, it's made by a couple of former dentists who do it as a side product on their main business which is selling dentist equipment.

So maybe the real issue lies with the development houses? But our experiences are obviously anecdotal so it's hard to say.

<comment><USER11> The real issue is that you pay them to deliver bad software.

I know it sounds like a weird thing to say. But had you as a customer demanded and were willing to pay for something different, you would get that.

Think about how the public sector buys a software development project; what the sort of process the supplier has to go through, how they qualify, how they bid, how the requirements are formed, how the software is tested, delivered and so on.

Had the public sector prioritised the internal quality; it could have done so. But it chooses not to.

In a public sector IT project the actual softare development is only small fraction of the cost. Other parts. Sales, legal, management, testing, documentation ... have much bigger impact on the suppliers ability to make money. Thus those are the parts you get and that is what drives the cost.

<comment><USER10> When you buy big enterprise systems you enter contracts that aren't easy to exit. You also bind so much money into those contracts that you don't really want to leave them either, even if the company sucks at delivering. Maybe you'll fight them in the courts for a few years and maybe they'll compensate you a few hundred million, but once you enter these deals you're basically in them until the law dictates that you have to do another round of bidding.

I've done this with a lot of difference companies and a lot of different development and project management philosophies though, and they all fail.

We've gone full waterfall, we've gone full agile and everything in between. We've done long detailed requirement specifications and we've invited companies into the heart of our business, to let them literally work inside our offices sitting shoulder to shoulder with our domain knowledge. None of it produces high quality software.

The highest quality software we have, aside from a few small suppliers, is the software we build ourselves. It's anecdotal again, but it's the same story I hear in my network of digitalisation managers across the countries public sector and banking.

<comment><USER12> With the way government contracts work, you'll almost never get really high- quality software that way. The contractor simply does not have any incentive to do so, as it isn't in the contract. Instead, the contract usually gives them the incentive to drag things out as long as possible and make sure development costs are as high as they can get away with; "cost plus" contracts are notorious for this.

<comment><USER10> I've worked in the private sector though, things weren't better there.

</comment></comment></comment></comment></comment><comment><USER13> When talking about quality, "good enough" is always good enough.

When I build a garden shed, I will not make strength calculations on the whole think, and my foundation will be pretty basic. My "timbered some wood together" shed will stand for 50 years, just as the "made a garden shed like an appartement building". Only the latter will take way more time and effort.

When building an appartement building, good luck doing that with the same effort as building a shed. You will have some nasty surprises once you start adding weight to the different floors. The whole thing will collapse.

So in the end, it makes no sense to build a garden shed as you would an appartement building, and it makes no sense to build an appartement building as a town shed. A lot of people forget this in the software world.

So the quality "support" depends on the project itself. Small projects need less, big projects more. Just like small companies need less process overhead, and big companies more.

Like everything in life, it all comes down to balance, and experience will teach you where the balance lies. Because sometimes you will go too far the the left, and after that you compensate and go too far to the right. But the balance will always be somewhere in the middle.

So no matter what project, "good enough" will always be good enough.

<comment><USER14> > So in the end, it makes no sense to build a garden shed as you would an > appartement building, and it makes no sense to build an apartment building > as a town shed. A lot of people forget this in the software world.

I agree, but I think that in the software world we're not even to the point where we can build sheds reliably well. We have neither historical knowledge that informs what the "ideal"[1] shed should look like, nor materials that won't suddenly change form the next day[2], nor tools that won't sometimes explode on us halfway through construction.

I understand the disdain for the "sufficiently smart compiler" argument, but I think that there's a long way to go in development of software tooling before we can get to the point of slapping together software like a shed. A pet peeve currently on my mind is throwing exceptions for invalid method parameters. For example, I genuinely appreciate the work that Microsoft has been putting into the .Net ecosystem, but out of all the recent changes I feel like non-nullable references is the only one that helps me write higher quality code instead of improving productivity a little bit (Now we just need enums that are actually type safe (one can dream)).

I'm excited for Rust, I hope it finds success in the world dominated by C/C++. I'm hoping something similar comes along for the world dominated by Java/C#. Elixr looks really cool and in the vein of what I would be wanting, but I haven't used it at all to know how an "enterprise" Elixr development process would work.

I'm just hoping that "good enough" can get better in my lifetime.

[1] Not in the quality sense, but in the "Platonic ideal" sense

[2] Broken dependencies

</comment></comment><comment><USER15> I work in QA and don't like the reduced focus on quality (selfishly, because I've got the skillset to get paid by assuring quality).

The article shows a graph that indicates that, over the long term, teams that attack cruft or spend time reducing it make a better product with more features.

To be cynical though, who cares? Who cares about the long term? Your goal as a startup is to crank out features fast enough to keep ahead of the competition and do so long enough to get bought out, IPO, or otherwise exit with a wheelbarrow of cash. Then the cruft is someone else's problem.

We're not exactly in a "long term focused environment". We're over here moving fast and breaking things. Bugs on production are fine, we'll just do a hotfix and then thank everyone for staying late and being rockstars.

Hell, half the S-1 documents I've seen flat-out state "we're losing a billion USD per year, our operating costs are definitely going up in the future; we may never be profitable" but it doesn't seem to matter one bit. "We're going to get big enough to raise our margins!" Neat, enter a scrappy competitor using vc funds to subsidize _their_ overhead, undercutting you with the same business model you started with. That's not long term thinking.

Yes there are better ways to produce higher quality software, but who cares?

</comment><comment><USER16> It's cheaper to develop high quality software, so let's all pay $500k+ a year to hire people capable of doing it for us, find a recruiting team good enough to find them, build a culture they actually want to join, and then hire enough of them that they have time to do regular code reviews, write tests, refactor code, etc.

High quality software takes a lot more than management telling everyone it's ok if they want to write high quality code.

<comment><USER17> False dichotomy. You don't need $500k engineers to write quality software. $150k/yr ones will do it just fine if you teach them how to do it and part ways with those who don't see the value in following basic quality standards.

<comment><USER18> I assume you need more than one dev to deliver the kind of project OP is thinking of, so that 500k is for a dev team

<comment><USER17> Pretty sure the OP meant that only $500K+ per head FANG employees are capable of writing quality software. To be fair, you can't write any other software at FNG (don't know about A): you won't be allowed to check it in. Some people leave due to not being able to pass the readability review. But FANG employment is not a prerequisite. I have personally hired something like 20 engineers of varying seniority and within a month or two, they were cranking out impeccable work.

</comment></comment></comment></comment><comment><USER19> I'm going to let you all in on a little secret weapon for high code quality and bug-free code called Design by Contract. Not only will contracts find bugs, you can set it up in such a way that it forces you to fix them or you don't have running software.

It's a myth that it's faster to put a bug in a bug list and deal with it later. If you find a bug, fix it immediately, most bugs take only a couple minutes to fix anyway. With DbC, you will find more bugs and it will reinforce the discipline to fix them then and there.

The graph that Martin Fowler showed where high-quality code allows for faster development is true. Where I would disagree is that there is an initial bump in time. Probably because most people will write tests as a sign of quality. Don't write those tests, go faster, use contracts.

</comment><comment><USER17> I'm currently consulting for a small startup one of the two engineers in which just doesn't get why he needs to adhere to any sort of a coding standard or write tests, or just write code that doesn't make your eyes bleed. To make matters worse, the founder thinks this engineer is "very capable" and just "set in his ways". As a consultant, it's not my place to fix such issues, so I'm thinking of dropping the client in question, for the first time in my career. The project is pretty cool, and I charge a steep rate, but this is just not worth the aggravation.

</comment><comment><USER20> It seems to me that the software market is a "market for lemons"[0]. Consumers lacking a decent way to validate software quality don't believe you when you do in fact produce a high quality product as other firms who produce low quality software are making the same claims you are. Everyone assumes that virtually all software quality is bad, and if its going to be bad anyway why not complete the work quickly as well?

[0][https://en.m.wikipedia.org/wiki/The_Market_for_Lemons](https://en.m.wikipedia.org/wiki/The_Market_for_Lemons)

<comment><USER21> Related, Dan Luu has a great article [1] where he looks at software hiring/organizations from the "market for lemons" angle.

[1]: [https://danluu.com/hiring-lemons/](https://danluu.com/hiring-lemons/)

</comment></comment><comment><USER22> The case is not being made particularly well, I feel, from the perspective of decision makers who incentivise quick-and-dirty tactics.

The cost/benefit of adding internal quality is only apparent over the entire lifetime of the product. If the product life is short, or only simple features are added, or not many of them, or the original design is a good fit for the feature scope in the future, you may never see sufficient benefit and the internal quality will be a net cost.

I'd grant that people tend to underestimate product lifetime and future complexity (perhaps wilfully, in some situations). A lot of people simply say "let's cut corners". I don't think there's a failure to explain to them that cutting corners can have downsides, as the article suggests. Everybody knows that. It is not unique to software, either.

</comment><comment><USER23> Grant me the diligence to work out well architected systems with great naming and tests, the courage to churn out quick prototypes for testing if we're building the right thing and fast hacks for suffering coworkers — and the wisdom to tell the former from the latter.

— Freely after Reinhold Niebuhr

</comment><comment><USER24> It's Martin Fowler. He makes money off trying to help people write better code. So you get the answer of "mostly yes."

Ask management, or upper management, or a customer, to write something as lengthy and comprehensive from their perspective, and I bet they could be pretty convincing that high quality is not always the best choice.

I hear those arguments quite frequently.

<comment><USER2> _It 's Martin Fowler. He makes money off trying to help people write better code. So you get the answer of "mostly yes."_

Isn't the true of every expert in every industry? They all make money telling people (what they believe is) the right way to do something, and it often sounds obvious once someone has actually articulated it, and _even more often_ there's someone else whose job is to prioritize keeping costs down telling people that actually it's not true because they can save a few bucks in the short term by doing things the quick and dirty way. You choose who to believe.

<comment><USER24> I define a difference between experts who make their money informing others how to write high quality software and experts who implement the (hopefully) high quality software.

As the latter, there are most definitely cases where the high-quality argument is not valid. It's not a matter a belief. It's more about constraint. If you have the time and expertese, quality is great, and that's when I like software development the most. But I've also decided to eschew quantity to meet external demands. Then we're talking mitigation: "We'll farm out these 3 services to juniors/external devs to meet the client's/management's deadline with the expectation they'll be chucked and rewritten later." We're making the decision to take on technical debt and hopefully keep it isolated enough that it's relatively easy to redo.

Martin Fowler and his ilk are frequently lacking a level of pragmatism that must be adopted to meet business needs.

</comment></comment></comment><comment><USER25> The author's distinction between internal and external quality is useful, but there is also an argument that internal quality has observable effects beyond development time. It is harder to reason about the correctness of software containing lots of accidental complexity, which means, in practice, that it is more likely to have problems that get through into the field. This is particularly so for security matters.

</comment><comment><USER26> I really liked and found interesting the end of this sentence:

> "For several years they have used statistical analysis of surveys to tease > out the practices of high performing software teams. Their work has shown > that elite software teams update production code many times a day, pushing > code changes from development to production in less than an hour. As they do > this, their change failure rate is significantly lower than slower > organizations they recover from errors much more quickly. Furthermore, such > elite software delivery organizations are correlated with higher > organizational performance."

<comment><USER27> Poor quality teams that push to production faster will definitely 100% turn them into good teams! Right? Right?

</comment></comment><comment><USER28> Even if the trade-off was real, which it isn't, reputational damage due to software issues is hard to fix, once blame is assigned correctly.

E.g. would it matter to Apple if "holding it wrong" issue was software or hardware? It's even more damning to purely software companies.

<comment><USER29> consumers kind of expect software issues and reputational damage is par for the course, especially with hugely expensive government systems where the development is 100% offshored

</comment></comment><comment><USER30> I agree that high quality software is usually more cost effective than lousily-put-together software, but not in all cases.

If you are building something new, as the article recognises, or in some cases you don't have a lot of experience, or you expect to grow fast, etc., what you build will have problems anyway, it might soon become obsolete, unmaintainable or ineffective... and then die. You should still have a decent plan, but in these cases it would be more effective to not bother much about high quality. You need to be really prepared in order to write high quality software in a business environment, and that's not something achievable through just will, in a reasonable amount of time. You need to understand sometimes you lack experience / definite direction / resources / ...

If you have the experience, a clear scope and goals, then high quality might indeed be the most effective way to go.

When building your own, small projects, high quality might be the way to go too, as you won't hate what you are doing and you will learn much more. Here effective would mean a very different thing.

But I think that considering the _effectivity_ of code in different contexts is a better perspective than talking about quality. It's always a good idea to spend some time considering the architecture; it's always a good idea to keep things modular; to keep code as easy to delete/replace as possible; to write as little code as needed. But the quality? Well, it depends. What's even quality? (and I'm the kind of guy that can't stand writing lousy or ugly code :D)

</comment><comment><USER31> The best part of the article is the point on the graph marked "This point occurs in weeks not months". This is 100% true.

</comment><comment><USER32> His conclusion that "high quality software is cheaper to produce" neglects to mention any kind of time frame over which it actually becomes "cheaper".

Over the short term (e.g. the next several product features) it may in fact be cheaper for a team to focus on speed and not quality. The accumulated technical debt would only cause problems for future development, and that's why it's taken on. In most cases, I think everyone (including management) knows perfectly well that high quality software is cheaper in the long run, but they're willing to take on that debt in order to have some short term benefit.

<comment><USER33> He does mention that in talking to experienced developers, they find _cruft_ slowing down their progress as early as a few weeks into a project. Additionally, his graph shows the cross-over as "a few weeks."

</comment></comment><comment><USER34> The thing is, do those costs surface to the other units of business that drive dev decisions? Product might feel the pain, but do marketing and business get it? Do they feel the perils of lost opportunity cost, unclear requirements, technical debt and slow work?

Often, dev and product are slaves to the business machine that only cares if the money keeps flowing. At many places, the dev team is not an equal partner with an equal seat at the table. Paying down technical debt is often an unpopular notion when "we could be making money".

You really need the entire company to understand what it means to develop software.

</comment><comment><USER35> One premise this article is based on is that more features = a better product. However that isn't always the case. Having a codebase which makes it easier to add new features isn't necessarily going to make that product succeed over a competitor.

If Product A adds 10 bad/mediocre features it'll become bloated and hard to use. If Product B, in the meantime, adds 2 good/great features the market will recognise this. Now Product A is stuck with 10 features they don't want. And good luck trying to take away those features from your users!

</comment><comment><USER36> My general sense is that high quality software always wins in the long run. I'd argue that is the primary reason Google has rapidly gained share in markets traditionally dominated by Microsoft and other enterprise software companies -- Google's software is noticeably better.

As with most things, you get what you pay for.

</comment><comment><USER37> This article has the implicit assumption that you're holding the team constant. What if I really broke out the checkbook and brought in Martin Fowler to lay out a plan for technical debt cleanup? Or acquired a key data provider that has a terrible API in order to have direct access?

Certainly that's buying higher software quality yet that's not what is being discussed here (but I wish the author would discuss it!).

What this is saying is having developers think and plan a little bit instead of treating every day like it's the home stretch of the Kentucky Derby and you're half a length behind plays off pretty quickly. I would agree with that! I also like the point about letting teams with high momentum move fast and make improvements, I often see such teams reigned in and I tend to think that's a mistake.

</comment><comment><USER38> The thing that ages software is changes. The irony with software is that the most successful pieces of software need to be changed frequently, because of changing requirements. It means that the software is very useful. The more useful it is, the faster it ages and the worse the code gets. The best written software that doesn't change means that its usefulness is very limited.

It is impossible to design software that can account for long term changes. It's 100% impossible. You need to design for the near future as best as you can, and realize that eventually you need to refactor.

So design your software with the best maintainability you can for the next few years and then try your best to refactor it as you go along with new changes, but don't beat yourself up with things like tech debt creep up.

<comment><USER39> " _The irony with software is that the most successful pieces of software need to be changed frequently, because of changing requirements._ "

I don't think that this is true. Some software doesn't need to change much at all and yet remains quite useful. I'm thinking of common Unix utilities as a good example here. Some haven't changed much in decades and yet are still essential to many workflows.

I think what is closer to the truth is that many tasks that we write software to accomplish have rapidly changing or highly variable requirements. This is especially true of things that directly support business processes. Those kinds of software projects are either going to require a lot of changes or will need to constructed in a highly flexible manner so as to acomodate different needs.

<comment><USER38> It depends on what your definition of "successful" is. I meant in the monetary term. Sure, there are old Unix utilities that haven't changed much but they haven't made a lot of money. Those with paying customers generally require a lot of changes to make their customers happy.

</comment></comment></comment><comment><USER40> In many cases, especially in the early days of a startup, you can't even afford the 1/2 weeks to increase code quality, because you might not have a business by then. If you have a demo for a customer the next day, at that point software quality does not matter at all.

<comment><USER41> I mean, are there startups that have a demo a week or two after they are created? Because the article is saying that correct software is cheaper on every timescale past that.

<comment><USER40> What I meant is that the closer you get to a delivery date, the more stress there is on you to "just make stuff work".

Most software projects that: 1) create business value, 2) are not trivial, and 3) have time constraints, reach a point where you have to just finish it, no matter the cost to code quality. I see it where I work. We have pretty good programmers, but sometimes we have to create debt intentionally because we know that's the way we'll make the deadline, and therefore impress customers, and therefore buy more time to write new features, and fix that debt.

<comment><USER42> This makes sense, but -honestly- how often do you take the time to fix the debt? Or are you pushed for the next feature?

</comment></comment></comment></comment><comment><USER43> If you have experience and follow best practices, you should produce decent quality code in the same amount of time as producing bad quality code.

In those cases, the gains from improving the code further are not always worth the costs since you should already be taking care of the low hanging fruit. There are always more you can do, but often times good enough is good enough.

It is often worth it for inexperienced developers to spend more time refactoring their code though. Besides the obvious improvements to the code base, it helps them gain the skills to do it "good enough" the first time.

</comment><comment><USER44> Another great reason why Low-Code platforms are worth exploring and adopting

</comment><comment><USER45> A heuristic that I've noticed:

There are exceptions to every rule, but when someone says that they are the exception to the rule they probably are not.

For example, we all know people who are lovable ###holes. However, in my experience people who think they are lovable ###holes are generally just ###holes.

My theory is that this is because people who are the exception to the rule are vigilant not to go to far, work to improve their flaws, or try to compensate. On the other hand, people who say they are the exception to the rule do so to use it as an excuse for not doing those things.

Applied to this topic; I'd argue that if someone says that for the software they are working on it isn't worth the cost to do refactoring/code reviews/write tests then they are probably wrong.

</comment><comment><USER46> Yes! Although a lot of time it seems more important to be creating the _right_ software that is actually needed!

</comment><comment><USER29> people are used to crappy software though and in enterprise world software regularly gets scrapped as it becomes unmaintainable. internal quality is not important at all as it can't be put on a spreadsheet whereas cost can

<comment><USER47> In the enterprise world, isn't the problem that unmaintainable software doesn't get scrapped, because it's so embedded at the core of the organisation, and maintenance snowballs. I'm thinking of sprawling ERP systems and 'core' Banking in particular.

Quality can be put on a spreadsheet: Cost of maintenance, regulatory cost, transition cost. However, a lack of commitment to radical change exists due to lacking risk appetite.

For example, 'Challenger' banks in the EU with only a few million in VC funding and a couple of handfuls of developers are able to provide complete banking services and really good (instant response) customer service. The equivalent system in a F500 bank can cost hundred of millions of dollars and simply applies a band-aid as another layer on decrepit systems, which still get supported.

As another example [1], a poster shared on HN a couple of days ago that Tencent have 6000 developers supporting QQ, yet WeChat has only 50. All in the same company but silo'd and very different management philosophies for overlapping apps. I find that amazing but completely understand.

'Innovation' is the fashionable enterprise-level replacement buzzword for 'creativity'. The Enterprise-world has lost it's risk appetite, and is slowly being erased.

Edit for the link: [1] [https://news.ycombinator.com/item?id=20021568#20024492](https://news.ycombinator.com/item?id=20021568#20024492)

<comment><USER48> > _For example, 'Challenger' banks in the EU with only a few million in VC > funding and a couple of handfuls of developers are able to provide complete > banking services and really good (instant response) customer service. The > equivalent system in a F500 bank can cost hundred of millions of dollars and > simply applies a band-aid as another layer on decrepit systems, which still > get supported._

Aren't they able to do this simply because they piggyback off existing financial infrastructure, limit their scope, and eschew doing anything at all in the meatspace? Some of the complexity of real banks come from having a great many branch offices[0], handling ATMs, currencies, credits, all sizes of customers (from individuals to corporations), and running some of the backend financial services themselves.

\--

[0] - or whatever you call the place you physically go to do your banking; not sure about the correct term.

<comment><USER47> [0] Indeed, 'branch' is the correct term. For retail business 'branch' is the bricks and mortar space you see on a high streets for retail customers including SMEs, and for institutional 'branch' is usually head office of the country (but the only thing that matters is the relationship manager that looks after individual customers for institutional customers, the handling of business done in a shared service centre somewhere offshore).

Challenger banks, that don't have branches (well, they do in the regulatory sense, but not in the customer service sense) all seem to use MasterCard (please correct if Visa also serve them), so I'm sure there's a deal there somewhere but I'm also sure they are required by regulators to run their own general ledger as independently licensed banks, and yes existing infrastructure (it's actually quite simple to set up an ATM network of your own using existing protocols and networks). ATM withdrawals are transaction- free for the user. A challenger to payment systems is FasterPayments providing RTGS payments at low cost, who are now expanding in Hong Kong/HKD (and perhaps more).

They (challenger banks in the EU) do have very low interest rates, but seems targeted for low balances and perhaps the business model is to take advantage of PSD2 in the future for brand and financial management, I don't know, N26 makes a big deal of travel insurance and value-added services for a monthly fee of 10-15 EUR. PSD2 destroys the traditional concept of brand of a bank simply leaving the brand of the service.

Part of my background is setting up and managing shared service centres for institutional businesses, so I'm looking somewhat from the outside in the retail space as a user, but an avid user.

</comment></comment></comment></comment><comment><USER49> Did you deliver any business value today? No, but my code looks like poetry.

<comment><USER50> Code quality as discussed in the article is more of a global property (the architecture) than a local one (syntax/implementation). Code that is bad locally can be fixed, not so much for a bad design.

</comment></comment><comment><USER51> Its absolutely imperative that you dont let anybody claiming themselves to be a programmer anywhere near a keyboard. Unplug them all now, unless you have all the safety precautions in place to catch any potential problem no matter how small or insignificant it may first appear. They will ruin your business. 100 percent guaranteed. Absolutely critical word of advice. Nobody should ever claim to be capable of being able to write any function in any scripting language. Only AI can write programmes in todays world. The risk is to high.</comment>


Ask HN: Solopreneur(Tech) seeks pricing demo/selling/negotiation advice - <AUTHOR> Hey Guys,
I have kind of spent some 3 months on designing a product. The collective features that I provide, if you use other softwares would cost somewhere around 500 - 600 USD per month.
The MVP is ready, and I want to approach the first customer. I want to do a demo for him. And then make sure at least he pays me half the market price.
If you kind of throw in pointers how to go about price negotiation, and convince him to use my product. It will be really helpful for me.
I am basically a developer, mostly geeky, don't possess good sales skills. So feel free to throw in whatever you want to.
Thanks! <comment><USER2> 1\. Identify twenty likely customers, mostly through LinkedIn

2\. Contact them with a short honest linkedin mail thing. (It comes at 20 quid a month or so to LinkedIn).

3\. Arrange demos with as many if them as possible - online or in person.

4\. Be clear what benefits the product gives these people - more accurate tracking? How much is that worth? There is always a way to get to the bottom line - post here if you are stuck

5\. In the demo focus in the benefit to them.

6\. Pricing - ask them what they would pay first. They will probably push back. Don't be silly at this point. Stick with your 500/mth figure. If they are interested great. If they want to pay less that's also great but then _they must give or do something for the discount_. - mostly that can be being part of the beta program - where they are obliged to take a ten min how's it going call with you each month the discount applies.

7\. Send an invoice the day they say yes. Don't faff about with credit cards - send invoice and chase up.

I have missed some stuff - but try that

</comment><comment><USER3> If you don't mind me saying I think you need to get out of your comfort zone and talk with people about your product. It will make a massive difference and you will not be finding out 2nd or 3rd hand what people like and don't like. Thats what I did years ago with my first one and it made a massive difference. I was naturally shy when younger (as many people are) but conquering that made a huge difference. Good luck with it</comment>


The Quest for Randomness - <AUTHOR> http://www.americanscientist.org/issues/pub/2014/3/the-quest-for-randomness <comment><USER3> There's a challenge posted online to compress a file of one million presumably random digits, and it's been running for 10+ years without anyone claiming the prize:

[http://marknelson.us/2012/10/09/the-random-compression- chall...](http://marknelson.us/2012/10/09/the-random-compression-challenge- turns-ten/)

<comment><USER4> If it was generated by a physical process, it might be possible that the signal has lower entropy than a truly random signal. It would be interesting to look at n-gram frequencies.

First you would have to extract the original digits. Since log(10) * 10^6 / log(256) = 415241.01, and the binary file contains 415241 bytes, I assume that the binary file is produced by converting a million digit number to binary.

</comment></comment><comment><USER5> I wrote a more rigor-oriented article on Kolmogorov complexity a while back. HN readers might enjoy: [http://jeremykun.com/2012/04/21/kolmogorov- complexity-a-prim...](http://jeremykun.com/2012/04/21/kolmogorov-complexity-a- primer/)

I too love Aaronson's writing style, so my work is no substitute for his insights.

</comment><comment><USER6> Darn, the article stopped right before it got to the interesting part in my opinion.

I love Scott Aaronson's writing and way of explaining things though. I was thinking how well this article was written before I looked at the author.

Randomness is a subject that fascinates me, as I've been studying how it relates to quantum mechanics. I've arrived at the conclusion that a more useful word that "random" is "unpredictable".

<comment><USER7> Scott writes very well. And he writes some of the lengthiest technical posts I have read. I find writing one paragraph of technical writing akin to chewing diamonds. Don't know how he does it. I have been lurking on his blog for some time and I have learned a great deal.

</comment></comment><comment><USER8> At an intellectual level I have accepted that quantum mechanics truly are random, but in a small corner of my mind I still believe that the universe is deterministic.

<comment><USER9> I think it's fair to say that's a reasonable coping mechanism for staying sane. QM notoriously has no everyday analog, whereas determinism holds up reasonably well in daily life!

<comment><USER10> I feel the opposite... determinism does NOT fit with my day to day observance, because my perception is that I have free will. If I accept determinism, I also have to accept that I actually don't have free will, and that seems contrary to my perception of myself.

<comment><USER11> So, what if some omnipotent trickster/adversary/god designed a deterministic universe specifically to fool you into thinking you have free will?

I tend to believe in free will myself and I _hate_ the above argument because I don't know of any way to refute it. As far as I know, the question of free- will vs determinism is unanswered. Even tests of randomness using Bell inequalities requires an assumption of free choice. It's... _disquieting_.

<comment><USER10> My point wasn't that the world COULDN'T be deterministic BECAUSE I have free will... I was saying that the world NOT being deterministic fits better into my own perception of how the world works, since it appears to me that I have free will.

As far as I know you are correct; there is no way to distinguish if I actually have free will or not.

<comment><USER12> Not trying to tell you what you should think about your own free will, but here's what I think about mine:

What I consider as me, my consciousness, is getting fooled in so many ways to think it made decisions it pretty much just observered... that particles making up my grey matter can go this way or that way, randomly, without "me" actually taking any conscious influence on them, doesn't really make a difference to me. It's like the difference between a truly random random number generator, and one that just spits out a pre-determined list; "I" don't get to pick the numbers either way.

When I was younger, I tried to "see where my thoughts come from", and it always seems like they come around some corner, out of some blind spot. I never meditated but I, but I always liked the phrase "watching thoughts arise", because that's how it seems, they come into view of my inner eye so to speak, but the inner eye does not make them, not originally. I can add 2+2, but I can't _make_ me get the idea to add 2+2. Well, actually, I can make myself get the idea to add 2+2, but I can't make myself get the idea to make myself get the idea to add 2+2... and so on. Is it possible to talk about these things without it sounding like esoteric gibberish?

Anyway, I kinda don't think we have free will, not to the degree we like to believe, anyway - but I can't help treating myself and others as if we did. I think life would seem kind of pointless otherwise, certainly anything beyond bacteria and plants, so it might be a necessary illusion for us "higher" life forms.

</comment></comment></comment></comment></comment></comment><comment><USER13> I've done some work with monte carlo and discrete event simulation. The runs/iterations produced utilize psuedo-random number generation. Many discrete-event simulation software platforms reproduce exactly the same numbers on a given run. Also, monte carlo simulation software like @Risk and CrystalBall enable users to select psuedo-random number generation methods. For instance, utilizing the Latin Hypercube method will sample more evenly from a Gaussian distribution rather than pulling more from the peak and tails.

</comment><comment><USER14> so much for i.i.d. random variables.

we don't know if the variables are random and have no way to tell - <USER2> - if they are independent or identically distributed.

i was always confused when cryptography textbooks only talk about pseudorandomness. probably `import random` is not sufficient for them

and I was also confused by ergodic theory textbooks, which qualify levels of randomness like "equidistributed" or "3-fold mixing" but we can find dynamical systems which only go so far.

that would be an interesting experiment to see what happens to the law of large numbers if the randomness bits are correlated.

</comment><comment><USER15> I think the guy working on TempleOS is basing his concept on the idea that computers can provide some sense of "randomness".

Not really related, but I thought it was an interesting connection.

</comment><comment><USER16> > As a first step, we could check whether the digits 0 through 9 appeared with > approximately equal frequency, among, say, the first million digits. Passing > such a test is clearly necessary for randomness...

Why is that the case? This just means that the digits are uniformly distributed. Why can't they have a different distribution and still be "random"?

<comment><USER5> I think he is appealing to intuition here, where randomness means you can't predict the next drawn value with accuracy better than uniform.

But you're right, you can draw randomly according to a different distribution. However, if you allow any distribution in your definition of "random" then you get the constant distributions. It's not very intuitively random anymore. So the question becomes, how do you pick which distributions are allowed and which aren't?

</comment></comment><comment> Ono-Sendai Kolmogorov complexity as a measure of randomness / information content has problems in my opinion: [http://www.forwardscattering.org/post/7](http://www.forwardscattering.org/post/7)

<comment><USER5> I think your contention (if you're the author of this post) is misguided. In particular, the "languages" you define have the string hard coded in their definition, and are hence at least as long as the string you want to encode. In other words, your additive constant is not universal.

The definition of Kolmogorov complexity is not with regard to whatever machine you want. You fix one and only one universal Turing machine U at the beginning, and then you measure the Kolmogorov complexity of a string using a different language with respect to U. Using your notation, K(x) is defined as K_U(x), and you can relate it to K_perl(x) by K_perl(x) + |perl interpreter written in U| = K_U(x). If you wanted to redefine all of Kolmogorov complexity using your L_{perl, i} language, you could do that just fine, but then it's _your bad definition_ that makes the interpretation silly.

Besides, if you pick an otherwise "random" string and single it out as being special, doesn't that intuitively make it no longer random?

<comment> Ono-Sendai Thanks for the detailed reply, I'll ponder upon it and reply in a bit :)</comment></comment></comment>


Scottsdale, AZ libraries to offer co-working spaces - <AUTHOR> https://asunews.asu.edu/20120205_alexandrianetwork

<comment><AUTHOR> For those in Arizona, ASU's venture catalyst at skysong is doing some great things. <http://asuventurecatalyst.org/></comment>


Ask HN: How do you store secret site credentials? - <AUTHOR> The default option seems to be just put your secrets in the cloud somewhere. Other options seem to involve using a vault like 1Password (clunky), or gpg & file encryption (messy). It seems that Hashicorp's Vault should do this, but I can't quite figure how.<p>Is there a good way to have credentials somehow checked in with your code? <comment><USER2> If you're using AWS, you can use Secrets Manager: [https://aws.amazon.com/secrets-manager/](https://aws.amazon.com/secrets- manager/)

</comment><comment><USER3> We encrypt them with a secret not in the repo itself - part of our deploy decrypts them as-needed.

edit: scripted in python via pynacl...</comment>