Namecheap Makes $44,000 Donation to the Electronic Frontier Foundation - <AUTHOR> http://www.elliotsblog.com/namecheap-announces-44000-donation-to-eff-0181 <comment><USER2> Namecheap also bans the word 'hacker' from URLs. If you want to register a domain with the word hacker (and a bunch of other words which they won't release), they give you a giant warning basically equating hackers with criminals, and make you submit a request to them before them that they have to okay before you're allowed to register.

Oh, and you can't use a credit card (hackers steal those, you know!), you have to have funds already in your account.

I'm sorry, name cheap, I want to love you, and stuff like donating to the EFF makes me want to love you even more, but please stop this absurdity of hackers == criminals.

(I found this out when registering raspihacker.com -- which is clearly a front for me evil criminal enterprise!)

Here, I just tired to register "potatohacker.com" and got this: <http://i.imgur.com/uz4yrBt.png>

<comment><USER3> > "...basically equating hackers with criminals..."

Let's not get carried away.

I have accidentalhacker.com registered with Namecheap. I recall having to have a quick phone call with support to make sure I was legit. Really, it's not that big a hurdle.

I was able to pay with my credit card and I've been _extremely_ happy with their service and support.

<comment><USER4> What is their criteria for determining if a registration is legitimate?

<comment><USER5> Apparently, that you aren't reluctant to call them.

</comment></comment></comment></comment><comment><USER6> Glad to see voting with my money is having a real impact. I've been using namecheap since the godaddy fiasco and love the service.

<comment><USER7> Same here now if only transferring from GD to NC was cheaper!

<comment><USER8> It's pretty cheap, I thought. It sucks if you have a ton of domains, but transferring over also renews the domain for an additional year, so the transfer itself really costs basically nothing. I just transfer whenever it's coming close to time to renew my registration anyway...

</comment></comment></comment><comment><USER9> It's worth pointing out the while NameCheap is a accredited registrar, they register all customer domains via eNom. You'll be subject to Demand Media's (eNom's parent company) whims and policies.

<comment><USER10> What a shame. I like NameCheap's style, but Demand Media and their shitty search-engine-spamming content farms can kiss my entire ass.

Not that I feel strongly on this topic or anything.

<comment><USER11> I think your thinking of Name Media, I always confused the two as well.

<comment><USER10> I am definitely thinking of Demand Media: <http://en.wikipedia.org/wiki/Demand_Media>

</comment></comment></comment></comment><comment><USER12> I wish someone like givewell would do domain-specific comparisons. I'd like to find out the best: 1) Drug policy organizations (e.g. MAPS) 2) Violence/gun violence organizations (which are both pro-2A/RKBA and anti violence) 3) Digital freedom organizations (like EFF). 4) Immigration reform for tech entrepreneurs 5) Encouraging tech entrepreneurship, particularly for underrepresented groups (veterans, women, racial minorities, geographic areas outside SFBA)

I respect that you can probably save a lot more lives by giving out malaria nets in Africa than by donating to MAPS or the EFF, but I personally care a lot more about drug policy and computer freedom, so when I'm making a voluntary charitable donation, I'd prefer to address those issues (particularly if I'm in the tech industry and making a corporate donation).

I'm a fan of EFF, but not convinced they're the most efficient way to donate a marginal $1, since they already seem to have a huge amount of funding. In general I prefer donating to very small organizations doing very targeted work with low overhead, and with an "end date" where once they accomplish their mission, they disappear.

<comment><USER13> Let us know if you find some organizations that you like! I'm sure many here would love to read such a post and help contribute.

</comment></comment><comment><USER14> Namecheap is so awesome, sopa, eff, great customer service- I wouldn't be surprised if their next move was to start accepting bitcoin as a payment method.

Talk about a tech-savvy business!

</comment><comment><USER15> Also see <https://www.gandi.net/supports/> , though I'd love to know some amounts or at least orders of magnitude there.

<comment><USER16> Gandi also has a moral code in their TOS. No thanks.

<comment><USER17> I was a customer couple of years ago. To this day I still get their newsletter and there's no link to cancel it. They say you have to log in and change your "newsletter settings".

Also their stupid auto-generated username "XY<account_number>-GANDI".

<comment><USER18> Why don't you contact them? I can't imagine it'd be hard for them to unsubscribe you from that (I did easily, but I'm still a customer so I could log in and do it).

</comment></comment></comment></comment><comment><USER19> Brilliant marketing.

<comment><USER20> That was going to be my comment as well: nice idea and well executed. I think it manages to balance the marketing and charity/cause angles well, which is a balance that's pretty easy to flub.

</comment></comment><comment><USER21> One more reason I use Namecheap, and have moved almost all of my clients to namecheap. (They really do need an affiliate program though!)

<comment><USER22> They have one: <https://www.namecheap.com/other/affiliates.aspx>

<comment><USER21> Thanks, didn't know about that. 15% of first purchase, eh? Since most people transferring will only buy a year for ~$10, a $1.50 one-time payment doesn't really do the trick! An ongoing 15% would be more like it.

</comment></comment></comment><comment><USER23> These guys are not only smart but knows how to take down the GoDaddy giant.

</comment><comment><USER24> May I also recommend Nearlyfreespeech.net, an excellent registrar and host with a good record of upholding free speech?

One example of upholding free speech: [http://blog.nearlyfreespeech.net/2012/10/06/official-uk- gove...](http://blog.nearlyfreespeech.net/2012/10/06/official-uk-government- attempt-at-censorship/)

</comment><comment><USER25> Very cool. Just picked-up a few certs from them and I need to register a few domains soon. They'll be my first choice.

</comment><comment><USER26> I'm going to have to transfer from godaddy->namecheap, this is the kind of thing I love to see ISP's do.

</comment><comment><USER27> any hackernews users review of namecheap as registrar, DNS, and/or email hosting?

<comment><USER28> I've been using them since the GoDaddy elephant hunting thing. I'm about 80-90% satisfied. The control panel is a bit messy, and the one time I contacted support they were generally helpful but not amazing. No plans to change registrars, and I would recommend to friends.

<comment><USER29> We're working on a UI overhaul. Your feedback is noted. :)

<comment><USER30> Because support is already awesome, right? :)

</comment></comment></comment></comment><comment><USER31> Just registered a .me domain to use along with github pages.

Honestly I'm glad somebody else got the .com domain, having "myname.me" is pretty cool

</comment><comment><USER32> I was regretting registering my domain with them recently, but not anymore, I'll be renewing it just because of this. nb

</comment><comment><USER33> Awesome.</comment>


The state of Web Components - jarek-foksa https://hacks.mozilla.org/2015/06/the-state-of-web-components/

<comment><AUTHOR> I was reluctant to use Web Components in any personal project and shoo'ed my coworkers away from using it on commercial projects because the uptake by browser vendors seemed so lackadaisical. I'm thankful to Mozilla for explaining the reasons why -- it's complicated! noone agrees!

I am loathe to polyfill modern browsers adding completely needless overhead trying to chase some panacea. At least Chrome and Firefox need to agree on (and be in the process of implementing) a feature for me to consider using it and polyfilling it.

The Web Components thing seemed overengineered and too much work for component developers to get wide adoption outside of widget toolkits. All that behind- the-scenes offsetTop confusion tells me that the way Google envisioned makes it a bad fit for the DOM/CSS/JavaScript hodgepodge cruft-pile that has built up over the years. The fact that there are so many open proposals out there for the various features should be a signal to architects to run the other way on Web Components.

So, into this vendor mess strides React, (and to a much lesser extent Angular and Ember due to ocean-boiling), which gives us a fancy component model atop standard DOM and JS. And at just the right time -- web apps are far too big this decade to be coded monolithically. I mean, everyone knows that, but what could you do about it before a decent UI component framework appeared?

Being able to compose your app in terms of nested components is the way build large, high-quality, well-tested web apps because it lets us reason about parts of the UI rather than the whole. And the DOM performance with React ain't too bad neither. And being able to render the same React component statically on the server and dynamically on the client solves a lot more problems too.

<comment> jarek-foksa None of the frameworks you have mentioned support proper sandboxing of component internals. They are leaky [1] and incompatible with each other abstractions. We need at least some basic native shadow DOM support in order to hide implementation details and avoid naming clashes.

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

<comment><AUTHOR> Agreed, most libraries and frameworks have nasty leaky abstractions; that is part of the cost of choosing to add those packages in your architecture. And heck, the browser itself is a clown car full of leaky abstractions, we deal with the problem everywhere.

I think successful open source projects have a pretty good track record managing leaky abstractions since they have so many users. JQuery did a good job in this area over time, papering over many of the leaky abstractions present in the DOM across browsers. Looking at the bug tracker for React, I think they are doing okay too after a rocky start. Haven't really tracked Angular, but I hear Ember is a pretty well run project too.

Shadow DOM does sound pretty good, but not essential to componentization if you're managing your ID's carefully. Honestly, I don't care if a framework or the browser manages my component scopes, I just want it taken care of.

I always thought scoped stylesheets would be more important to non-leaky UI component development, but it seems like that is yet another dead-end experiment that didn't catch on. [http://caniuse.com/#feat=style- scoped](http://caniuse.com/#feat=style-scoped) So we fall back to tooling again, and get something like SASS to manage and build our monolithic stylesheets.

I prefer linking to Joel Spolsky's blog when describing Leaky Abstractions since he coined the term: [http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...](http://www.joelonsoftware.com/articles/LeakyAbstractions.html)

<comment> jarek-foksa ID prefixing won't prevent component internals from leaking to event listeners, querySelector results, TreeWalkers/NodeIterators, innerHTML, and many other APIs.

Native shadow DOM allows me to write components with strict encapsulation on pair with the built-ins such as <button> or <input>, neither framework comes even close to that.

Styles defined inside shadow DOM are always scoped to the local shadow tree, so there is really no need for style[scoped]. Chrome and Opera (and maybe Firefox) support CSS encapsulation inside shadow DOM making the CSS preprocessors less needed.

<comment><AUTHOR> Shadow DOM does sound pretty cool, I wish its design allowed it to fit in better with existing DOM.

I think react components give you pretty good isolation. You don't spend any time querying by selector or innerHtml, you just update your model, it re- renders the component tree, and then a diff of the DOM yields the mutations it will do on your behalf. Event binding is similarly abstracted. It's a different paradigm than what you're describing, and I think it works well for a lot more use cases than just "componentize the DOM".

I'd love to be able to combine shadow DOM and react somehow (assuming wide browser support emerges). I bet a lot of performance optimizations could be derived in the browser from native Shadow DOM.

</comment></comment></comment></comment></comment><comment><USER2> I'm really surprised to see Apple's name on this list. Their behavior over the last few years has led me to conclude that they are no longer interested in seeing the Web flourish now that they have market power. Glad to see progress (even if it's obscenely slow).

<comment><USER3> I often wonder to what degree any given web feature is influenced from higher up in vendors' organizations. It would be fascinating to know how high up these decisions go.

</comment></comment><comment><USER4> It's finally nice to hear about Web Components again. I remember when they started Polymer you heard how Web Components were the future, and then they just dropped off the radar.

Good to know that all the major vendors are continuing to develop them though.

<comment><USER5> The post has an answer to why that happened:

 _Web Components were a Google effort and little negotiation was made with other browsers before shipping. Like most negotiations in life, parties that don't feel involved lack enthusiasm and tend not to agree.

Web Components were an ambitious proposal. Initial APIs were high-level and complex to implement (albeit for good reasons), which only added to contention and disagreement between vendors.

Google pushed forward, they sought feedback, gained community buy-in; but in hindsight, before other vendors shipped, usability was blocked._

<comment><USER6> > but in hindsight, before other vendors shipped, usability was blocked.

Haven't we learned this lesson before?

I think it's more likely that Google didn't want other vendors' interference, to avoid design by committee thwarting whatever they were trying to achieve.

<comment><USER7> It seems like the way to do it is from a bit of both camps. Someone has just got to make it, deploy it and use it. Critically is this bit: Everyone (including the author) needs to learn from it, decide how to improve, what to change what to scrap. For there is were the specification process starts for all involved.

Refer to how SPDY was developed. Lessons were learned because stuff got done and it was out there. Then everybody came back to the table a little wiser. On the whole at least that's how it looked to me.

</comment></comment></comment></comment><comment><USER8> I've had a lot of trouble finding out what people are thinking about the comparison between shadow dom/web components and react.

If web components are finalized and ubiquitous, how does that effect react?

<comment><USER9> It's like the difference between TypeScript and ES6. The goals are intentionally aligned, and as the underlying platform adds support for the constructs that power TypeScript, it can continue to delegate more and more to the underlying platform.

Knockout custom elements, for example, are extremely similar to web components. As support for web components proliferates, Knockout can keep the same framework API but use web components under the covers.

<comment><USER10> I look forward to using Web Components myself, regardless of the actual method we'll end up creating them.

Just like jQuery has become "useless" in many cases, it took us a long way to where we are today. Sure we'll need to worry about SEO, etc. but Googlebot (and others, hopefully) are already quite capable of executing Javascript.

To me the Riot.js web component syntax seems very natural to write - more so than JSX. Here's an example:

[https://www.symfony.fi/entry/build-a-web-component-with- riot...](https://www.symfony.fi/entry/build-a-web-component-with-riot-js-and- yandex-maps)

</comment></comment></comment><comment><USER11> Why does this author _italicize_ in _weird_ places?

<comment><USER11> Because srsly

Array.from(document.body.querySelectorAll('em')).forEach(em => em.style.fontStyle = 'normal')</comment></comment>


Show HN: Bk – Backup Made Easy - <AUTHOR> https://github.com/alcover/bk <comment><AUTHOR> \- You are working on a file, making many versions, without using git.

If you're like me you would just copy/paste the file and get 'foo (copy1)', 'foo (copy2)' or worse : 'foo (copy1) (copy1)'.

Now with `bk foo.py` you get 'foo_2020-06-04-18-28.py'.

\- You are in a folder and want to archive it.

You would normally move-up the FS, then try to remember `tar` flags, then compress, then come back-down to the folder.

Now with `bk -z .` you stay where you are and the job is done, creating '../yourcurrentdir_2020-06-04-18-28.zip'</comment>


NSA Says It Foiled Plot To Destroy Our Economy - <AUTHOR> http://www.businessinsider.com/nsa-says-foiled-china-cyber-plot-2013-12 During Sunday's 60 Minutes white-wash of the NSA, Debora Plunkett, director of cyber defense for the NSA, claims they "stopped" a nation-state cyber attack that would brick computers across the country through a fake BIOS update. She claims the NSA "stopped" this attack by "working with computer manufacturers to close the vulnerability." Sounds like FUD to me. <comment><USER2> LOL</comment>


Your Company Should Let You Work from Anywhere - <AUTHOR> https://www.bloomberg.com/news/articles/2019-09-15/sunday-strategist-your-company-should-let-you-work-from-anywhere <comment><USER2> Disclaimer: I haven't read the article. But I am working for a client that doesn't have space for all of the consultants on the project to come in to the office and this leads to wild miscommunications that lead to non-trivial delays which ultimately result in the client to ask the (local) consultants to come in to the office to talk to the staff to settle miscommunications. Setting aside the assertion that the client might need to communicate better we're all humans and misunderstandings happen. For remote workers who can't come in for a face-to-face meeting there's little chance to overcome a situation like this.

If companies were always able to communicate effectively then I might agree with the title... but this game works both ways and sometimes it's the employee/consultant/contractor who has the communication deficit which is exaggerated by remote.

<comment><USER3> Aside from physical communication, every other type is achievable through computers. Does that mean the only way to resolve a misunderstanding is through physical communication?</comment></comment>


The best investment I never made - <AUTHOR> http://www.lindventures.com/blog/2012/06/23/the-best-investment-i-never-made/

<comment><USER2> One data point, one result. Obviously it's a universal truth right?

There are probably thousands of examples of people making an outstanding return on investing in property. And the example given in the post is extremely contrived:

"For example if you can start a new business with $50,000 then sell 20% of it to an investor for $200,000 in 1 or two years, you've created $1m worth of value in that time. Do you think if you bought a property for $1m with a 10% deposit, it would be worth $2m in two years or less? No way."

How many people can create companies worth $1M in 1-2 years that with certainty? How about compared to how many people can buy property? And what if you had invested in a house in China back in 2007-2008? The value of your home would have doubled by now so that your $1M would have been worth $2M with no extra effort.

Context, timing, skill, and luck play a great role into what makes a good investment. Let's be wary of over-generalizations made from anecdotal examples.

</comment><comment><USER3> "For example if you can start a new business with $50,000 then sell 20% of it to an investor for $200,000 in 1 or two years, you've created $1m worth of value in that time. Do you think if you bought a property for $1m with a 10% deposit, it would be worth $2m in two years or less? No way."

Sorry but I have to point out that this is a very flawed comparison. How much work did you put into that house? - I think the assumption here is none. How much work did you put into your business? - depending on how much you consider your rate to be probably a lot... potentially even more than $200,000.

A more fair comparison would be an actual home builder or developer and there are many that do just this and could cite comparable or even much higher returns.

<comment><USER4> What a lot of people miss when comparing the returns of a home to say, the stock market, is that a home also __provides a place to live __. Of course a home would return less, because if it didn't the price would quickly shoot up because people see the inherent value in having your (lackluster) investment put a roof over your head.

</comment></comment><comment><USER5> I bought a 300k house for 70k (4.9% Fixed) after the bubble burst (Florida) the house had never been under 100k since it was built in the 80s Now it's value is back up to 150k, rent pays mortgage and maintenance 3x. I understand your point, however property can be a good investment if you make smart choices.

<comment><AUTHOR> In Australia you wouldn't be able to buy a bus shelter for $70,000.

<comment><USER5> My house is 5/4 with garage, 4 miles from Miami Beach. Since Florida was the epicenter of the bust we now have the best prices. :)

</comment></comment></comment><comment><USER6> Just a heads up, my anti virus Nod32 says that there is a trojan embedded in this link.

<comment><USER7> Getting the same warning here, Firefox won't even let me load the page.

</comment></comment><comment><USER8> Just to clarify - when you refer to buying (or not buying) a property - do you mean actually buying it, or taking out a loan (mortgage) to "buy" the property. I've noticed, especially in north america, people tend to refer to "buying" a house when really they are borrowing it and paying for it for a long time...... just curious.

<comment><USER9> That's the reality of the situation when you boil it down. But technically, a mortgage holder did completely buy his home form its previous owner, and does now own it himself. It's true he paid for it with money borrowed from the bank (and the bank lent it under certain conditions), but it legally his house, not the bank's.

</comment></comment><comment><USER10> The argument seems to be that not buying property was a good decision, because investing that capital into a startup instead produced a better ROI than property investment would have.

But is that the normal case? What are median returns for property investment versus self-funded-startup investment?

<comment><USER11> For me the part that hit a nerve was this: "Nobody likes to have debt and as soon as you have it, you become restricted in what you can do."

Most of us hear the constant refrain of what a good idea home ownership is, and how it so much better than renting, when you take into account the mortgage interest deductions and appreciation. And that's all true, but what they never really emphasize is that once you take out a mortgage you've got that $1,000 monthly payment (for example) that you've got to meet EVERY month, for the next 30 years or until you sell. And you have insurance, property taxes, maintenance, etc.

Carrying long-term debt and especially owning a home really does impact your thinking. You become more risk-averse. You start thinking that a steady paycheck is a better idea than taking the risk of starting a business. As time goes on, you feel like you have MORE to lose because you've been paying on the debt for a while and you actually have some equity. It's why banks view mortgages with equity as lower risk, and why car insurance is cheaper if you own a home.

As far as buying property as an investment, i.e. renting it out, the "common wisdom" is that you make your money when you buy. You absolutely need to get a really good deal when you buy, because the rent you're able to collect will basically be a break-even on your expenses, so wnen you eventually sell your profit is a function of your purchase price. Unfortunately a lot of people pay too much for houses that they think are in a "hot" rental area, and they never really make any money on them.

<comment><USER12> > _what they never really emphasize is that once you take out a mortgage > you've got that $1,000 monthly payment (for example) that you've got to meet > EVERY month, for the next 30 years or until you sell. And you have > insurance, property taxes, maintenance, etc._

You've got a similar obligation if you rent. Rent or buy, you're still out on the street if you stop paying.

> _Carrying long-term debt and especially owning a home really does impact > your thinking. You become more risk-averse._

Meh, student loans, the ultimate long-term financial obligation, didn't make me risk-averse at all. I'm slightly more risk-averse today -- and I do own a home -- but I attribute a great deal of that to getting older. The prospect of starting over from 0 becomes less appealing the older you get.

> _As far as buying property as an investment, i.e. renting it out, the > "common wisdom" is that you make your money when you [sell]. You absolutely > need to get a really good deal when you buy [...]_

Yes. If you're considering buying a place that you'll possibly rent out in the future, you need to be serious about it and do your research. When I was scouring the internet for articles and forums about it, I was shocked to see just how serious -- and * unbelievably fiscally conservative* the people are who buy rentals seriously are.

<comment><USER13> > _"Rent or buy, you're still out on the street if you stop paying."_

Not true at all. Buying means you've _committed_ to a particular lifestyle, city, and income level for a very, very long time. Renting carries none of these commitments and risks.

If I lost my job today I wouldn't be anywhere near screwed - my lifestyle can be downsized a _lot_ in very short order (on the order of 1-2 months to reduce my burn rate by 5x).

This freedom is important to me. Right now I'm in the middle of a relocation - I want to experience a new place, with a different pace and different culture. I wouldn't be able to do this if I had bought property. If I wanted to bootstrap a startup I can easily move into a much, much cheaper place and immediately free up a lot of capital.

<comment><USER12> > _Not true at all._

Well yes, it's true that if you stop paying your rent or mortgage you will be evicted. Although you're safer in a house you bought because the bank has to foreclose first.

> _Buying means you've committed to a particular lifestyle, city, and income > level for a very, very long time._

Depends on your definition of "a very, very long time". 5 years is the accepted minimum threshold for buying a place, and if you did your homework properly you should be able to break even renting it out. There was a time when 5 years seemed like an eternity to me, but not these days :)

> _This freedom is important to me._

This is the important bit. There are 1,000s of rent vs. buy arguments all over the internet but IMO it comes down to what you want for yourself. That freedom to move about at will is important to you, so it sounds like you've made the right choice for you. I like where I live and I despise moving, so buying was right for me.

</comment></comment></comment></comment></comment><comment><USER14> There are markets where the monthly cash cost of owning a home is lower than renting. It sort of looks like that could be the case in parts of the Peninsula right now -- but mainly because there just isn't much inventory either way.

Thinking like Warren Buffet ($1 today is not $1, but actually $20 after it compounds many cycles) is technically inaccurate (the correct thing is DCF/DV), but products a more correct result.

<comment><USER15> Trulia/Movity did a visualization on this <http://trulia.movity.com/rentvsbuy/>

<comment><USER14> Wow, that is awesome.

The big change in the past year is that private equity and hedge funds have gotten into buying single family homes, using automation, to rent. The thing which terrifies me is that they are more efficient than random individuals as landlords, so they may all exit the market together. I've also heard that they are much more efficient at setting rents, doing so based on income in an area, vs comparables -- if they can take enough inventory out of the market, that ends up making a lot of sense.

<comment><USER15> That sounds like a really interesting market, is this first-hand information or have you read about it? I'd love to read a good article on this if you know of any.

<comment><USER14> [http://online.wsj.com/article/SB1000142405311190429250457648...](http://online.wsj.com/article/SB10001424053111904292504576484571234105448.html)

<comment><USER15> Thanks!

</comment></comment></comment></comment></comment></comment><comment><USER16> The overall principles (being free of debt = good) in this post apply anywhere, but I think some context might help. AU hasn't had a housing bubble pop in a long time. It's currently not possible to find a reasonable place to live for less than $500k.

</comment><comment><USER17> A couple of things for perspective. Here in Australia HELP (it used to be HECS) is a government student loan that you pay back as you earn later in life. You can pay your course fees upfront instead if you like, but either way the amount is not onerous for a basic degree, and it's basically a few percent extra on your income tax until it's paid off (if your wage exceeds $X)

The other is that housing in Australia has gone berserk in price. We have the most expensive housing relative to average income in the developed world, except for Hong Kong. That's happened in only the past 10 years. What was a $200k house then is now a $500-600k house, and wages have not grown to match. Buying a house now is not a good investment. Buying a house back then was a good investment, with the benefit of hindsight.

<comment><USER18> Depends on location, there is probably still money to be made in property. Melbourne of instance probably now has very little undeveloped land within 10km of the CBD, even 20kms is mostly filled in. The population is still rising quickly and lots want to live inner city. So I don't see those prices crashing any time soon.

Granted it is a little like Apple shares, as expected high future demand would be built into the prices.

HECS is such a better system that what you read about US student loans that I wonder why they don't have similar. HECS doesn't touch your wage until you earn around 50k and even then only takes a small percentage. No one feels like they are taking a big financial risk here undertaking higher education.</comment></comment>


Code Obfuscation for Patent and Court Filings - <AUTHOR> http://blogs.adobe.com/acrolaw/2011/06/code-obfuscation-for-patent-and-court-filings/

<comment><USER2> Obfuscation for patent filings? A wet dream of the intellectual "property" lobby. Get the monopoly on idea! Now even without actually disclosing it!

</comment><comment><USER3> Wasn't part of the benefit of this patent thing the fact that once the patent has expired the whole society can use the previously patented innovation for the greater good of all its members?

Somewhat clever solution to an "evil" problem...

</comment><comment><USER4> Does Adobe have a patent on that obfuscation process for patents?

<comment><USER5> I think so, but it's obfuscated.

</comment></comment><comment><USER6> For a moment there I thought this is an April Fool's joke — but… you just can't make that stuff up.

</comment><comment><USER7> I think that they mean copyright registrations, not patent applications:

<http://www.copyright.gov/eco/help-deposit.html>

"In any copy option where portions of the code are blocked out, the blocked- out portions must be proportionately less than the material remaining."

Though most people I know just use the option to submit object code, since (1) the object code is usually available anyway to anyone who buys the software and (2) since you only have to submit about 50 pages of object code, you're not giving much away anyway.

</comment><comment><USER8> I would be very surprised if simple diagonal bars are sufficient to prevent a good programmer from reconstructing the code. Has anybody here tried it?

<comment><USER9> Also, how does a watermark act in a PDF?

Is it like those cases where documents requested under FOIA had black bars hiding sensitive text which could simply be moved/removed with the right tool set?</comment></comment>


Ask HN: Why companies shy away from expanding in Midwest / Central part of US? - <AUTHOR> Majority of technology companies generally prefer to expand on either west or east coast, both of them are really expensive to live and crowded.
Why companies don't prefer to expand in central part of country where everything is inexpensive?
One comment I have heard from people is lack of talent pool outside tech hubs, wouldn't talent go wherever there are better opportunities? <comment><USER2> People will list a lot of good and legit reasons (investors are there and want to keep tabs, talent, etc), but I think bias "sometimes" plays a part.

A while back I worked for a company that was in the networking business. We had an office in the Twin Cities supporting some but not all products. The company was at the "need warm bodies" stage as they looked for people to fill some tech support roles in the valley and just couldn't get anyone. They reluctantly recruited a few of us from the Twin Cities (they were told they had to). It was all "oh man I hope you can handle this" / "This job usually requires a Master of Computer Science and 8 years experience..." and so on.

Then we started doing the job. After all that build up we were shocked, by how easy it was. It was still just tech support, and no more complex than we had done in the past with other products. You never once would think of computer science and that job. Just know the product, be able to communicate (funny enough customers didn't like the guys in the valley...), and work your way logically through problems. They were doing in the valley for +2x per person costs (and they were less productive) absolutely convinced the jobs had to be there....

</comment><comment><USER3> 1) Investors and their money. It's much easier to get angel/vc money in a tech hub. Investors either are there already or frequently travel through the tech hub. For companies with investor money, investors generally prefer to be able to come into the office and see everything. Most of these investors are based near tech hubs.

2) Partnerships. If you're in a tech hub, it's easier to find companies to partner with, even by happenstance. It's also easier to sell yourself if your from SF, NYC, Boston than if you're from Boise, unfair as that is. Lastly, it's easier to convince a company to acquire you if they already have an office in that metropolitan area.

3) Talent Pool. This is really about two things: tech workers and seasoned execs. Generally speaking the talent pool is much higher in the tech hubs. The average engineer has been to multiple meetups, best practices have filtered down from the FAANG alumni into the general engineering population. Anecdotally, the people we turn down at my current job would have been "rockstars" at my previous jobs in CT and Westchester (the NYC suburbs). Execs are more likely to have been part of a high growth startup or at least have exposure to tech best practices or tech in general.

Outside of tech hubs, you're really committing to hiring junior engineers and training them, hiring consultants to fill key exec or management roles, hiring engineers from consultation companies (many of the hires that are willing to travel are international) and if you want truly great hires your going to be flying in a lot of candidates and many will still decide that they don't want to move anyway (they essentially need to decide to move away from their family, friends and work connections and rebuild that. It's a hard decision and many people back out late in the process)

A good technology analogy is that starting a company in a coastal tech hub, is like being able to use AWS cloud services. It can be cheaper to build your own data center, but being able to spin up server clusters at will and outsource database management, etc increases a company's velocity significantly. You can build a tech company outside of a tech hub (see ExactTarget), but it's harder to scale up past a certain size and exiting is much harder. Getting venture capital is harder and may be on worse terms. Finding good engineers in your stack nearby is more difficult (anecdotally it's a frequent occurrence to find companies using custom frameworks and/or best practices from 3-5 years ago, including the regional "success" stories)

</comment><comment><USER4> Companies don't move because the talent won't move. As soon as you move for "cost savings" you've already told any employee you actually want working for you that engineering excellence isn't valued; so who's going to move for that.

The "crowded" part is the reason companies don't move inland. It really can't be overstated how much the quality of talent drops off as you leave regional hubs like NYC or SF. This compounds too, things may be expensive in these cities, but the amenities, job opportunities, and networks are exponentially better. Cost of living reductions evaporate when stacked up against lost future earnings (percentage raises on a smaller base + no opportunity to job hop + reduced opportunity for any potential spouse to do the same), more money spent on transportation and housing, etc.

</comment><comment><USER5> Well, I think that they are, especially as the costs of talent in the coasts gets higher. I am focusing on established tech companies, as for new companies there is a different set of criteria (outlined well by twunde).

For established companies, they can seek out talent pools available in major non coastal cities and build satellite offices.

I am not familiar with all of the central USA, but I am familiar with Denver. Denver is one of the 20 finalists for Amazon hq2, and gusto and slack opened Denver offices. Oracle has a big presence in the Denver area, and Microsoft and Google both have offices in Boulder (close to Denver).

</comment><comment><USER6> The old days are long gone. Most companies are pretty lean, and the prospect of sending a key person to Minnesota just isn't reasonsble. How are you going to convince some hotshot to move? Remember that spouses work these days!

Plus, if you want to save money, you can send work to India, Phillipenes, etc and plug into a network of managers and business types.

Is it short sighted and probably a bad thing in the long run for American companies? Sure. Does that matter? Nope!

</comment><comment><USER7> Chicago/Atlanta doesn't count?

[https://www.google.com/amp/s/www.citylab.com/amp/article/399...](https://www.google.com/amp/s/www.citylab.com/amp/article/399623/)</comment>


Dark Matter Detector Records One of the Rarest Events Known to Science - <AUTHOR> https://www.sciencealert.com/a-dark-matter-detector-just-detected-one-of-the-rarest-events-ever-in-science <comment><USER2> Arstechnica has a much better summary:

[https://arstechnica.com/science/2019/04/dark-matter- detector...](https://arstechnica.com/science/2019/04/dark-matter-detector- identifies-extraordinarily-rare-radioactive-decay/)

But the best source is the original paper, which is quite readable even for a non-expert:

[https://arxiv.org/pdf/1904.11002.pdf](https://arxiv.org/pdf/1904.11002.pdf)

</comment><comment><USER3> This is, I am sure, a dumb question, but I read this [https://en.wikipedia.org/wiki/XENON](https://en.wikipedia.org/wiki/XENON) and I just don't know enough to completely understand the concept, but my dumb question is how do they know the event they saw was a spontaneous decay and not caused by a WIMP or whatever Dark Matter is? If it is such a rare event, how do we know that it wasn't a dark matter particle that caused it but the reaction was different than anticipated ? Can anyone take on a ELI5 here ?

<comment><USER2> It's not quite as rare as the article makes it out to be. It's not like they by chance happened to detect a single event that only happens every few trillion years. They had a TON (actually three tons) of xenon. Decay events happened every few days, and they collected over 100 of them. Those events have a particular "signature" that allows them to be distinguished from other kinds of events. Even then, they needed to apply statistical methods to compute the odds that the data they were seeing was real and not from random chance, and the result was that the odds were not quite high enough to qualify as a discovery by the usual standards.

Details are in the original paper, which is pretty accessible:

[https://arxiv.org/pdf/1904.11002.pdf](https://arxiv.org/pdf/1904.11002.pdf)

<comment><USER4> I'm always amazed at how much good science happens based on inferring things from what's known or guessed with high confidence.

<comment><USER2> Why is that amazing? How would you expect it to work?

</comment></comment></comment></comment><comment><USER5> Wow, 2800 pounds of Xenon, at $120/gram, is about $150M. Hope they don't have leaks. I thought these detectors used dry cleaning fluid.

<comment><USER6> I worked on a different xenon-based experiment[1] for my PhD. We were looking for similar rare decays to learn about neutrinos. Our observation of double beta decay of xenon 136 used to be the record for rarest decay.

Xenon has some very nice properties as a particle detector for rare events:

1\. For one thing, it's a noble element, and so it can be purified very well to reduce background decays of other elements.

2\. It's also a very heavy atom, and so it's self-shielding from external radiation. The core of the detector is shielded very well from radiation coming from the outside, so any signal you see there is most likely from decays of xenon or from things like dark matter WIMPs that don't interact much with matter.

3\. It is a natural scintillator[2]. It gives off light when an interaction or decay ionizes the xenon atoms. That lets you actually detect the event, and by collecting the scintillation light, and the electrons from the ionization, you can get a decent measurement of the energy of the event.

4\. It's recyclable. The XENON1T experiment follows the XENON100 experiment. The 100 kg from XENON100 were reused in XENON1T, and the tonne from XENON1T will be reused in future experiments. So the cost gets amortized.

$120/g sounds on the expensive side. The price is always changing based on supply and demand. One manufacturer deciding to use xenon in some process, or finding a way to replace xenon with argon, can swing the price by an order of magnitude.

As for leaks, I can say on our experiment we took the possibility very seriously. The entire xenon gas system was made of ultra-high-vacuum plumbing, and we helium leak checked every connection. When the xenon was outside the experiment in bottles, we had sniffers around the bottles to make sure they weren't leaking. We also had emergency systems in place if we needed to recover the xenon, including a "balloon of last resort" that would've captured the xenon in the event of a catastrophic failure.

[1] [https://www-project.slac.stanford.edu/exo/](https://www- project.slac.stanford.edu/exo/)

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

<comment><USER7> Can you talk more about the "baloon of last resort" and the process to recapture the gas from it?

Has a "baloon of last resort" ever been needed in any similar experiments?

<comment><USER6> We never had to use it, thankfully.

Our experiment (like the XENON experiments) used liquid xenon. The boiling point is roughly -110 °C, so it requires cooling to stay liquid. If that cooling had failed, the xenon would have started to boil and turn to gas. Gaseous xenon takes up something like 300x more volume than liquid.

So we had a few things to deal with this. We had some pretty giant UPSes to provide backup power. Imagine a shipping container filled with lead acid batteries. That was enough to keep the cooling running for about a day. During that time, we would start recovering the xenon. That would involve running compressors to stuff it back into bottles before power ran out. We also had a limited ability to cryopump the xenon out. Cryopumping involves cooling a gas cylinder (usually with liquid nitrogen) so the gas condenses inside. But that was always limited by the amount of LN we had on hand, which wasn't much.

But suppose we couldn't get all the xenon back into the cylinders before power ran out, or if our compressors failed. First, our detector would have failed. It was made of thin copper to reduce radioactivity. The xenon would have mixed with the HFE (Novec) fluid we were using for coiling. After that, as the xenon continued to boil, it would have burst some burst disks built into the system. And those were connected to the balloon.

The "balloon" was some plastic material, about 10x10x20 meters that we had stashed in an alcove off to the side of our experiment. It would have hopefully contained the xenon.

Since we never had to use it, I'm not completely sure what the process would have been. We would have shipped it off to some industrial gas facility, and they have the equipment to distill it out. And then we'd probably have to spend more time purifying it ourselves.

I doubt such a thing has ever been used. Most experiments, even underground ones, weren't dealing with the constraints we were. The mine we were in wasn't dedicated to science, and a dedicated facility would have had better support. For example, we couldn't run generators to deal with a power failure because there were limits to how much diesel equipment could be running underground with only natural ventilation, and the ventilation fans didn't have backups. Likewise, a dedicated facility would have had a better supply of liquid nitrogen. We only had one portable dewar, rather than a large tank.

</comment></comment></comment></comment><comment> le-mark _Thanks to the XENON1T dark matter detector lodged under the Gran Sasso mountains of Italy, scientists have recorded one of the rarest events to ever be detected: a special type of radioactive decay in xenon-124.

It's an amazing feat, because the decay of this isotope is extremely, extremely slow. In fact, xenon-124 has a half-life of 1.8 x 10 to the power 22 years – roughly one trillion times longer than the age of the Universe._

Does that qualify as impossible odds?

<comment><USER8> (I'll repost one of my comments in a similar thread, with a few minor changes.)

If you have only one xenon atom in a box, to have a 50% chance that to see that it decayed you should wait a "1.8 x 10^22 years—or about a trillion times the age of the Universe".

If you have two atoms in a box, you must wait approximately half of the time to have a 50% chance to see the decay. (It's not exactly one half, there are some technical details here, but one half is a good approximation.)

They have 2 tons of xenon. I'm not sure if 1 ton = 1000kg or 907 kg, but it doesn't change the result too much. I'm also not sure about the isotope of Xenon they are using, so I'll use 131 as the atom mass, but it doesn't change the result too much. With 2 tons you have 2 x 907 * 1000 / 131 x 6.02x10^23 = 8E28 xenon atoms, so you expect to have a few decays per hour (if I did the calculations correctly).

I'm not sure if they can detect the 100% of the decays and the noise level, so it probably takes a longer time to detect a good signal.

<comment><USER9> >If you have two atoms in a box, you must wait approximately half of the time to have a 50% chance to see the decay. (It's not exactly one half, there are some technical details here, but one half is a good approximation.)

Really? As far as I know radioactive decay is mostly believed to be a Poisson process (or rather the time it takes for a single atom is believed to be exponentially distributed), in which case the time it will take is _exactly_ one half, on average.

<comment><USER10> Are the two of you using the same answer to the question "Does a X% chance of 2 events (in given interval) contribute X% or 2X% to the chance of seeing one event?"? That is, do you mean [time for a 50% chance of seeing ≥1 decay] or [time to see, on average, 0.5 decays].

<comment><USER9> In my case I'm talking about the (average) time until the first decay.

</comment></comment></comment></comment></comment><comment><USER11> For something this exceedingly, impossibly rare I'd expect an in-depth discussion of how this is NOT an instrument mistake or a mis-interpretation of the measurements. There appears to be none of that.

<comment><USER12> It's a 4.4 sigma detection, so not a discovery by particle physics standards. [https://www.nature.com/articles/s41586-019-1124-4](https://www.nature.com/articles/s41586-019-1124-4)

I've heard suggestions that the result is more of a curiosity than of fundamental importance, and that this is why they get to publish a uncertain result in nature.

<comment><USER13> _4.4 sigma ... uncertain result_. You partical physicists are a funny bunch!

<comment><USER12> The famous 750 GeV bump of 2016 reached a maximum significance of 4.4 before dropping down as more data was added.

Particle physics has a _lot_ of events, so locally improbable things get likely when considering the totality of the data sets.</comment></comment></comment></comment>


Worse is Better - le-mark https://www.dreamsongs.com/WorseIsBetter.html <comment><AUTHOR> This was a deeply meaningful essay to me when I first read it several years ago. It's on my list of "Things Every Developer Should Read".</comment>


Mozilla's Crowdsourcing Mystique - <AUTHOR> http://www.businessweek.com/technology/content/jul2009/tc2009071_384108.htm

<comment><USER2> "Mystique" is a good word, since they have this mystique about being this egalitarian, community driven organization, but in reality, Mozilla is a fairly badly run open source project. The 40% number in the article counts localizers, doc writers, and other ancillaries, so it seems high, but the vast majority of core code changes are done by Mozilla Corp. employees.

The project is really quite insular. Straightforward bug fixes may go in smoothly sometimes, but try to get any feedback on feature suggestions, and you'll often find deaf ears, even if you're willing to do the implementation. Or may submit a patch to bugzilla for a bugfix, and it'll just get ignored. But then a year later someone at MoCo runs into the same bug doing Firefox work, comes up with roughly the same patch, and it hits the tree within a day.

There's also significant components where nobody in the organization actually understands how they work, so if you submit a patch to say, XPConnect, it won't ever go in because nobody feels confident enough to review it.

WebKit is actually more vibrant in terms of non-Apple code contributions than Mozilla.</comment>


Ask HN: Which stack do you use at your startup? - <AUTHOR> <comment><USER5> Make your MVP in whatever language you know best. Don't chase after buzzwords or trends.

I personally use PHP, mySQL and Redis with nginx proxy, cause I know these the best.

Probably nodejs would be a bit faster, but then again, I would probably make 100s of mistakes, not to mention god knows how many bugs, because I'm not 100% familiar with the language.

</comment><comment><USER6> C on FreeBSD on EC2.

Yes, the dynamic parts of the Tarsnap website are written in C.

<comment><AUTHOR> Which OS do you use for development?

<comment><USER7> It's a fair question. Many people use FreeBSD just for servers and use other distros for their workstations.

<comment><USER6> I guess so. It seems strange to me that anyone would want to inflict upon themselves the pain of using different environments for development vs. production, though.

<comment><USER7> You'd think so, but I bet a large portion of developers on hacker news develop on a mac and run their apps in production on a linux distro. At least for web apps.

<comment><USER6> Could be. I know a lot of Mac owners who only ever do three things directly in OS X though: Run a web browser, use video conferencing software, and launch linux and BSD virtual machines.

</comment></comment></comment></comment></comment></comment><comment><USER8> Haskell & Elm. Deployed to AWS with NixOps. Persisted with PosgreSQL and Redis. Code hosted in either Bitbucket or GitHbub. Tasks managed with Trello and email. Occasional sync meetings over appear.in or Zoom (I travel).

<comment><USER9> This is my favourite stack here by far. What are your pain points?

<comment><USER8> NixOps supposedly supports several hosting providers, but the DigitalOcean integration is currently broken. AWS works great, but it's annoying to be forced into that choice by the tool.

Haskell and Elm both work great, but I can imagine in future using something like Haste or PureScript Bridge; it'd be nice to work with both the backend and UI as a single project. Not a pain currently, but this is a nice to have.

Biggest pain is documentation. Haskell stuff is documented, but more hand- holdy examples would be ideal. OTOH, some language communities have a culture of writing documentation that is too hand-holdy, flooded with emojis, and is generally frustratingly infantilising. I'd like Haskell to strike a balance between the two. I'm optimistic we'll get there eventually.

<comment><USER10> Have you run into design decision limitations with Elm yet?

<comment><USER8> Nope. Not in any of the several products I've put in production with Elm. There have been times when I've needed more things than Elm provides — one time I needed a library for parsing a streaming JSON response — but the JS interop through ports works just fine.

</comment></comment></comment></comment></comment><comment><USER11> You might find some interesting answers at [https://stackshare.io/stacks](https://stackshare.io/stacks)

<comment><USER12> Stackshare is more informative than a majority of the replies in this thread that aren't stating their startup's name or use case.

</comment></comment><comment><USER13> Started with Python + Django + MySQL, hosted on PythonAnywhere.

At some point, decided to rewrite the project from scratch in Clojure using MongoDB, since Clojure was much better suited for solving the problem in question (modelling the grammar of a natural language - [https://www.pealim.com](https://www.pealim.com)) and MongoDB was better suited for the constantly evolving grammar spec. The rewrite took around two months and I believe that it was the right decision, though I still miss some of the things that Django provides for free (like the admin interface and user authentication).

I also use ClojureScript + Reagent, though not yet on the user-facing parts of the app.

<comment><USER14> pealim.com is my most visited site (according to the chrome home screen). I could not have learned עברית so quickly the last couple of years without it. תודה רבה!!!

</comment></comment><comment><USER15> On [https://www.stackpair.com](https://www.stackpair.com) I'm using Go, Rails, Redis, Memcached, Minio, Sidekiq, Postgres, and Kubernetes on GKE.

The iOS app is Cordova: [https://www.stackpair.com/apps/ios](https://www.stackpair.com/apps/ios)

For storage and backups I use Hubic and Rclone. Hubic is the best deal I've been able to find for LTS: 10TB for €5/m.

</comment><comment><USER16> We [1] use a Laravel back-end for the main system, hosted on autoscaling EC2 behind a load balancer. Our front-end web application is built on Angular, running on S3 behind CloudFront. Since we process a lot of data, we use background jobs (with SQS as a broker) to perform our analyses. The actual data processing and wrangling is done in Python.

We have released some parts of our systems as open source projects [2], [3], [4].

[1]: [https://odysseyattribution.co/](https://odysseyattribution.co/) [2]: [https://github.com/code-orange/telemachy](https://github.com/code- orange/telemachy) [3]: [https://github.com/code- orange/jot](https://github.com/code-orange/jot) [3]: [https://github.com/code- orange/statuspage](https://github.com/code-orange/statuspage)

<comment><USER17> Great to see Laravel in this discussion! Beautiful framework.

A couple of questions:

1\. Why did you go with Python for data processing instead of PHP?

2\. Why not use Redis for queue/background jobs processing?

<comment><USER16> I agree! Lumen is my go-to framework for small web-based things right now, picking things from Laravel is so powerful.

1) At the time, Python (and with it pandas/numpy) seemed to be a good fit for the data we were working with (and the analysis was developed as a separate project from the main system that calls it). If we were to do it over right now (and we well might in the coming months) we would probably move this into PHP as well, which makes writing workers much easier.

2) Cost-wise, SQS makes a lot of sense - the system is highly distributed and cut up into parts (the description in my first comment is a bit simplified) so adding redis to the mix means adding a whole new server. For SQS, we're just paying per-message (and we don't have a _lot_ of messages, so it's cheap). Furthermore, I've built an algorithm to scale up the background workers based on the queue size of SQS. This runs in Lambda, which makes it super easy to access SQS properties versus connecting to a remote redis server. Basically, the algorithm rents new EC2 instances whenever the load is high and terminates them whenever the load is low.

</comment></comment></comment><comment><USER18> We sell diagramming libraries, most notably (by sales volume) a JavaScript diagramming library: [https://gojs.net](https://gojs.net)

Our stack is: _we don 't care._ One of us spun up a couple AWS resources and a windows machine with IIS because that's what he knew how to configure the quickest. It seems like it would be a waste of time to spend any more time thinking about it until we have a real need.

We have some orders database stuff we wrote ourselves ages ago with SQL Server that hasn't needed significant changes in 10+ years.

In other words, to us, the stack is whatever makes itself disappear the soonest so we can work on the actual product. Nothing fancy, nothing new, nothing changed for the sake of it.

If our product touched the stack more, we'd spend more time on it, but only insomuch as it _was_ the product (if the product is a speedy website, etc).

Our workflow/cycle is all JavaScript based for the JS product. We push release with a gulp script I wrote.

</comment><comment><USER19> As an indie founder, I prefer to use Node/Express and React/Redux, hosted on Digital Ocean. Really fast and convenient to build SaaSes and single page apps like:

[https://nulis.io](https://nulis.io)

[https://helix.startuplab.io](https://helix.startuplab.io)

If I don't need a lot of fancy interactive functionality, and am building more of a usual web 2.0 website, I sometimes go with Django/PostgreSQL:

[https://fictionhub.io](https://fictionhub.io)

[http://webacademy.io](http://webacademy.io)

[http://lumiverse.io](http://lumiverse.io)

For static blogs and content websites, I go with pelican generated sites simply served with nginx:

[https://startuplab.io/blog](https://startuplab.io/blog)

<comment><USER20> helix reminds me of [https://github.com/ioddly/meditations/](https://github.com/ioddly/meditations/)

I'm curious if you prefer Django over js alternatives for any particular reason?

</comment></comment><comment><USER21> windows 200, ms access for the backend, ASP (VB) for the frontend.

we also do java applets

<comment><USER22> you probably meant Windows 2000 ;)

<comment><USER23> Windows Trajan emperor edition has a really good firewall up there (sorry for bad joke, had to make it).

<comment><USER21> Windows 200AD :)

<comment><USER24> :P I still write orchestral music with Cubase on a 1999 IBM PC running Windows ME. Writing this comment on my new (2005) computer with OmniWeb browser, os x 10.4. Hmm maybe I should be in healthcare.

</comment></comment></comment></comment></comment><comment><USER25> We're not exactly a startup, but a small growing data science, analyst, and engineering team in a bigger company. You name it... but a typical data and web stack.

OS/Distros: FreeBSD and Linux (CoreOS and CentOS)

Languages: Python (Data Science) & Javascript (Front End)

Frameworks: Flask, Django, Angular, React, Bokeh, Tensorflow, Scikit-learn

Container Services: Docker, Mesos/Marathon/DCOS (currently testing Kubernetes in GKE - Google Cloud)

Databases: Redshift, Postgres, Cassandra/Scylla

Deployment Tools: Jenkins, Github, Gitlab (different team)

All running in AWS deployed through CloudFormation and Salt.

There's even a Windows Server 2016 instance thrown in there for good measure running Tableau. That's the most reliable part of our stack. </rolls-eyes>

<comment><USER26> Node.js/GraphQL/Next.js/PostgreSQL/AWS Lambada (via up). Entirely serverless stack with the application state residing in the DB and a JWT to identify the user. No OS, containers, kubernetes, instances, etc to deal with other than a single RDS instance.

</comment></comment><comment><USER27> We use Elixir, Go, C++ for backend and JS, Java / Kotlin, C# for frontend. We also use Postgresql, Rabbitmq and Redis.

<comment><AUTHOR> How are you managing deployment of these many technologies? What does your CI/CD workflow like?

<comment><USER27> We mostly use docker with docker swarm. Currently exploring moving to Rancher. Also we use Gitlab CI for CI/CD. Our workflow looks like this: a release is tagged, CI tests and builds a docker image which is pushed to our private registry and then we use ansible to deploy the new release on our servers. We mostly use onprem for our production and can't use any cloud with the regulations and limitations we have.

</comment></comment></comment><comment><USER28> I run a development shop in Australia and work with a lot of startups to build their MVP. This puts us in a position to recommend our preferred stack:

\- Django backend

\- React frontend

\- Native mobile iOS/Android OR Xamarin (depends on project)

\- PostgreSQL

\- AWS (Elastic Beanstalk) OR Heroku

\- S3

<comment><USER29> I am an experienced Django developer, but just starting with React. Can you point towards any source which suggests good project setup and structure?

<comment><USER28> I have not personally been involved with a lot of the development for the past couple of years. I could ask a colleague. Send me an email - firstname.lastname@example.com

</comment></comment></comment><comment><USER30> We're building/selling "enterprise" software.

Multi-tenanted single codebase supporting both SaaS and self-host (Windows, Linux, macOS).

Stack:

\- EmberJS front-end

\- Go backend (static binaries that embed EmberJS GUI)

\- MySQL database

\- AWS EC2 pulling Docker images from Docker Hub

</comment><comment><USER31> Python, Django, Go, Lambda, ECS, EC2, TS/JS, React

</comment><comment><USER32> Not sure we qualify as a startup anymore but our stack is Kotlin + Gradle + Kubernetes on GKE.

Definitely the best stack I have worked with thus far.

<comment><USER33> what framework?

</comment></comment><comment><USER34> [https://DNDEmail.com](https://DNDEmail.com) is do not disturb for your Gmail.

We use Python on Google App Engine. Google's NDB datasource.

The Chrome Extension is written in JavaScript.

Wordpress on wpengine.com for the front-end brochure website.

I've written about how to simplify your MVP stack[[https://dndemail.com/2018/01/30/how-to-simplify-your-app- pla...](https://dndemail.com/2018/01/30/how-to-simplify-your-app-platform-and- dump-the-co-founder/)] to speed up launching.

<comment><USER35> Webapp2 or something else? :) It's been so long I've seen someone use python on GAE, it's ridiculous. It was my first ever "real world" programming project back in 2011.

<comment><USER34> Yes, webapp2 with Jinja for the front end. For my endpoints I am just pushing json through webapp2. Simple to use and administer.

</comment></comment></comment><comment><USER10> We use PHP. PureScript Haskell Postgres :) all on kubernetes atop AWS.

</comment><comment><USER36> Elixir (Phoenix) in AWS Fargate.

</comment><comment><USER37> Plain Ruby + Sinatra+ Puma + MySQL (ConnectionPool) + Sidekiq on Redis for the back-end. Sinatra/ERB for low-traffic sites, and ReactJS on S3 for more traffic on the front-end. I always like to err on the side of common denominator, rather than adding as many 'currently hip' tools as possible. Every time I try new things, it eventually brings me back to this set of tools.

</comment><comment><USER38> At Shelf [1] we use:

Front-end: React, Redux, Vue.js, Meteor.js. Served from S3 via CDN (AWS Cloudfront)

Back-end: Node.js in AWS Lambda with AWS API Gateway, also Node.js in Docker hosted on AWS ECS, spot instances

Storage: MongoDB (on mLab), Elasticsearch (on Elastic Cloud), S3

Other: GitHub, Circle CI, Terraform, Jest

[1] [https://shelf.io/](https://shelf.io/)

</comment><comment> git-pull For anyone here interested, there's a website that has a nice UX for this: [https://stackshare.io/](https://stackshare.io/)

What I like about it is you can add open source projects to your stack, not just SAAS services. And also, you can split your server-side stack from your personal tools.

</comment><comment><USER39> Meteor + React + MongoDB got eddtor.com really quick out of the door. But after 5+ years of maintaining my shipped products (I'm a freelancer, ME-JUST- ME kind of dev), my absolute happiness in customer service & maintanance was the most boring stack of all: PHP + HTML + JS + MySQL/MongoDB. Vanilla FTW.

</comment><comment><USER40> My present client has ASP.Net/SQL Server/Azure.

Not the greatest fan of Azure, mainly because of the admin portal, but apart from that it's been good.

Constantly get told by their clients that we do everything much faster than other SASS providers they work with, like weeks where others have turn arounds of months.

</comment><comment><USER41> Backend: Java (phasing out), Go (phasing in), Postgres, Redis, all on Ubuntu EC2's.

Frontend: JS (TypeScript/ES6), React, ReactNative, SASS, all Webpack'ed (except RN).

I think it's a fairly light stack but am happy with it. I would use this as the starting point for pretty much every project.

<comment><USER42> I love Go, but always feel it is not very productive for web app backends. What about you ? Do you use an ORM w/ Go?

<comment><USER43> Go optimizes for readability and lack of surprise at the expense of conciseness, which is why you feel it may not be productive. I think that the better maintainability vs. something like Rails massively outweighs the upfront cost of having to type more code, but other people might judge differently.

Furthermore, Go emphasizes "doing it your own way". There are no big web frameworks in Go, you just pull in some small and rather orthogonal libraries and make up your own abstractions to tie them together as you build your application. The end result is something that's highly optimized for your personal needs, but it requires a certain way of thinking and working that's not for everyone (and not always desirable). Some people do better when given more freedom; those should prefer Go etc. Some people do better when working within a well-known set of rules; those should prefer Rails etc.

Regarding ORM, I use Gorp ([https://github.com/go- gorp/gorp](https://github.com/go-gorp/gorp)) for INSERT, UPDATE, DELETE and basic SELECTs (e.g `SELECT * FROM things WHERE id = $1`), but when doing complex reports, I write SQL by hand [1] because ORMs are usually too constrained. I always feel like I know more SQL than the people who designed the ORM.

[1] For example: [https://github.com/sapcc/limes/blob/ab4245a8f195672b808f990f...](https://github.com/sapcc/limes/blob/ab4245a8f195672b808f990f9f7c2452652c475d/pkg/reports/domain.go#L100)

<comment><USER42> I usually do the same, or even just sqlx. But then wish I had gone full-ORM when I have to change SQL code in 50 places due to a column rename...

<comment><USER43> I'm struggling to think of instances where you would want to rename a column without changing the behavior of the column. The latter would mean that you have to review those 50 places anyway.

</comment></comment></comment></comment></comment><comment><USER44> We are doing live video streaming, mostly Java and React.

Our backend is running on Kubernetes in Google Cloud. Streaming servers are hosted in AWS, but we are preparing to move to dedicated servers.

We also use Consul for service discovery and statistics for streaming servers.

</comment><comment><USER45> (serious) hobby project: beanstalk, vertx, java, dynamodb, elasticache. Frontend: Kotlin.

</comment><comment><USER17> We use Laravel for the backend and VueJS on the front end. Forge/Envoyer for deployments.

Amazon S3 for storage, db/redis for queue processing.

Great setup, a lot of the headache is taken out and lets us focus on the development aspects of creating software.

</comment><comment><USER46> Backend: Python, Go, Java

Mobile development: Android and React Native

Database: MySQL and PostgreSQL

Redis and also RabbitMQ.

<comment><USER47> Could you please share your experience with RN?

Have you created an app from scratch or added RN to existing native app?

<comment><USER46> I have never created an apps or worked with React Native before. But, I would share the experience from my colleague who develops Android apps in our startup.

We are a startup that helps people in the middle-low income using technology. The people who use our technology usually have Android mobile phone with minimum specifications (Jelly Beans, low memory and spaces). At first launch, we used Android Native to build our application. The application meets our costumer needs since we consider to build an apps that consumes low memory and spaces. Then our costumer are growing and the features are complex, we use React Native to existing native app. Our application now consumes memory and spaces two times than Native one. Beside that, sometimes when you use a library, Native is more stable than React Native.

</comment></comment></comment><comment><USER48> Rust on Linux with Cassandra, the strong typing without a GC is a boon to stability and performance (my own sanity). Cassandra is fantastic, looking forward to using Scylla at some point.

<comment><USER23> Would you mind if I asked what type of application do you have that needs the kind of write performance? Also, are there any Rust drivers for Scylla?

This stack looks awesome in terms of pure perf.

<comment><USER48> Ads (matching, serving, recording analytics), Scylla uses the same protocol Cassandra does. I've been using the CDRS crate which is pretty nice. It has a few rough spots that I've started to smooth over and send PRs for when I get a chance.

</comment></comment></comment><comment><USER49> As a data company specialized in real time statistics for combat sports, we've built an API with Node.js + Hapi and MySQL. The front-end was developed with Vue.js.

</comment><comment><USER50> Rails monolith, jQuery for some user interaction (new features are starting to use Vue.js). Hosting on Linode. Capistrano for deployments.

Nothing special, but it gets the job done.

<comment><AUTHOR> Which service do you use for hosting your repository?

<comment><USER50> Github

</comment></comment></comment><comment><USER51> Erlang in the Backend on DigitalOcean. React/immutable/requirejs/bootstrap in the frontend.

The integrations with payments and similar are Java on AWS Lambda.

</comment><comment><USER52> Node and React/Redux, both with TypeScript. Starting to wish I'd learned PureScript so I didn't have to make do with Ramda for scaling.

</comment><comment><USER53> Server-Side:

\- Python with Pyramid

\- SQLAlchemy with Postgres + Cassandra

\- Celery with Redis

\- Swagger

Client-Side: Mostly React, React-Native

</comment><comment><USER54> Java (SparkJava Web Framework), PostgreSQL, Redis, Angular 4, S3 for files. Have also used Spring, Jersey, SQS, MongoDB in previous projects.

</comment><comment><USER55> Context:

[https://fibery.io](https://fibery.io) \- Work management platform for SMB

Stack:

Clojure

PostgreSQL

Kafka

React

Javascript

</comment><comment><USER56> Backend:

      - Go, NodeJS
      - Redis, MongoDB, Tile38, Neo4j
      - <USER2>
      - <USER3>

Frontend (mobile app):

      - React-Native

<comment><USER20> How has Traefik worked for you? Is it serving production traffic?

</comment></comment><comment><USER57> i'd like to see this question answered only by companies grossing over $100 million and less side-dev passion projects.

<comment><USER14> My company is well over that number. I probably only know about a quarter of the stacks... And even within those, there is a lot of variation. There are java heavy stacks, python heavy stacks, nodejs, Ruby. Lots of systems level stuff in C, C++, Java. I can't even speak to any front end frameworks (although I know there are at least a few). Almost every other application you could think of is in use somewhere... Nagiod, Sensu, Icinga, OpenNMS, memcached, redis, nginx, Apache, redshift, MySQL, postgresql, rabbitmq, zeromq, Ansible, Chef... This is likely barely scratching the surface.

</comment></comment><comment><USER58> Elixir, React, Postgres hosted through Heroku.

</comment><comment><USER59> I use Go + MongoDB. Hosting via Docker/Kubernetes in GKE. Gitlab is used for VCS, CI/CD and issue tracker.

</comment><comment><USER60> Python/Django, PostgreSQL, React, EC2.

</comment><comment><USER61> Using postgre, redis, FeathersJS, Nuxtjs, and VueJS. The near real-time updates and sever side rendering is great.

</comment><comment><USER62> Python, Django, Postgres, Cassandra, RabbitMQ, Redis, MySQL, Nginx, HAproxy, Elasticsearch, Spark, React.

</comment><comment><USER63> Python, Flask, SQLAlchemy, sklearn, numpy, Amazon Elastic Beanstalk, Postgres (on RDS). PowerPoint ;-)

</comment><comment><USER64> Node.js / Express, Nginx, RethinkDB, Docker, tiny bit of Go. Preact / hyperscript frontend.

</comment><comment><USER65> Python Flask, SQLite, some front-end framework that is available at the time, Linux Digital Ocean

</comment><comment><USER66> Backend - <USER4>

Frontend - React app

DB: MySQL

<comment><AUTHOR> How do you do migrations with Golang? Which ORM do you use?

<comment><USER67> This may be useful: [https://github.com/mattes/migrate](https://github.com/mattes/migrate)

<comment><USER43> Seconded. I use it with the go-bindata backend and Postgres driver. Some notes:

\- Migrations are written in plain SQL, so there may be portability issues if you need to support multiple DBs. (Or you need to write the same migration once per supported SQL dialect.)

\- It does not `CREATE DATABASE` for you when applying the first migration. For my app that uses Postgres, I wrote some extra code to do that. Feel free to copy if you like: [https://github.com/sapcc/limes/blob/ab4245a8f195672b808f990f...](https://github.com/sapcc/limes/blob/ab4245a8f195672b808f990f9f7c2452652c475d/main.go#L145-L178)

</comment></comment></comment></comment><comment><USER68> Backend API servers: Golang, Python, Redis

Frontend Web Servers: PHP (Laraval), JS (React), MySQL

</comment><comment><USER69> ReactJS front-end, Grails back-end API with a PostgreSQL DB deployed on AWS.

</comment><comment><USER70> Ruby, Scala, Postgres on AWS

</comment><comment><USER71> Ubuntu, node.js, MongoDB, Mongoose, express, RE:DOM, stylus, nib, pug, ...

</comment><comment><USER72> Company - www.LetsEnvision.com Stack: Swift, Obj-C Python C++ MongoDB

</comment><comment><USER73> SQLite, ASP.NET Core, jQuery, Bootstrap. Kinda boring but works

</comment><comment><USER74> I use Stackoverflow :)

<comment><USER75> Me too!

</comment></comment><comment><USER76> PHP (Laravel), JS (Vue + Vue Router + Vuex), MySQL.

Keeps things simple.

</comment><comment><USER77> Python, Flask, Tensorflow, Keras, Amazon MWS, Boto

</comment><comment><USER78> for my food site I use nginx as a proxy, Go for the server and Postgresql as the database. I deploy to digitalocean

</comment><comment><USER79> for what? if its for analytics? we use Panoply and Chart.io sources are all over the place

</comment><comment><USER80> \- java

\- dojo

\- IE11

\- jenkins

\- we are not a startup :)

</comment><comment><USER81> Backend: Node.js, SQL Server, Redis.

Frontend: React, Redux, Bootstrap via create-react-app.</comment>


Why constant mocking in RSpec is bad - <AUTHOR> https://hqc.io/2017/03/26/constant-mocking-is-bad.html <comment><USER2>
        What if there are some core classes or third-party
        libraries we use also require Time.now to work?

The "once" expectation will fail, indicating that the mock doesn't accurately represent the behavior of the system?

Note that in the DI case, unless there's additional work being done to inject the double everywhere else `Time.now` gets used the spec will silently use the built-in version.

<comment><AUTHOR> Yeah that kind of test tends to be fragile and the outcome is unpredictable.

There's no need to inject the double everywhere in other tests because the built-in version is the behavior we want the function to work.</comment></comment>


The Several Million Dollar Bug - <AUTHOR> http://jacquesmattheij.com/the-several-million-dollar-bug

<comment><USER2> This isn't remotely a bug, it's not even really anything to do with browsers. The browser will be doing (roughly) the following:

        while pending_requests():
            send_request()
            read_response()

But what send_request and read_response are doing is putting data on the OS's outbound queue and then attempting to get data from the inbound queue. If the data is already in the inbound queue before the request is put on the outbound queue it doesn't matter - the browser is not aware of this fact. So long as the "responses" don't come in faster than the browser is sending requests and causing the queue to overfill, and so long as the responses send out come in the order the browser is sending requests this technique will work. In general this is just an "optimistic strategy".

<comment><USER3> So once the initial request is made you can push anything you like to the browser using this pipelining method? What is stopping the responses from coming in too quickly and "overfilling" the queue? To make it work doesn't seem too hard but aren't there possibilities for exploits if you're loading in to memory unrequested data?

<comment><USER4> Hm. Now you have me wondering what potential for abuse there is in this. I never looked at it from that angle.

<comment><USER5> Potentially, you could imagine a poorly-written web browser that could be fooled by an extra HTTP response, confusing it with a later request to a _different_ web site.

So you could follow up a HTTP response for [http://empty.website.with.no.other.files.to.request.com/](http://empty.website.with.no.other.files.to.request.com/) with a HTTP response containing malicious javacript. When the user then tries to view a different website (say their facebook page), they get 'served' your javascript that is now running under the context of the new site. Cookie stealing and other attacks could be run.

In practice it would be unlikely to happen. If the client doesn't read the 2nd request then it is likely to be sitting in a network buffer assigned to the first connection, which will probably be thrown away when it comes to open a connection to the new site.

<comment><USER6> That's not how it would work. The later request would be made on a fresh TCP connection (since it's a different URL). Your previous unsolicited response is sitting in the buffers for the old TCP connection. They would not mingle.

</comment></comment></comment></comment></comment><comment><USER5> An alternative way to pump lots of webcam frames was to use multipart-MIME responses. That way, there was only one HTTP request and the response just streamed JPEG images, one after the other. No need to break any specifications to get full network usage.

<comment><USER4> Yes, we did that too (on Netscape, IE did not do multipart for the longest time and when it did it at first was quite buggy).

<comment><USER5> I'd forgotten the pain of trying to get IE to work with this! I can see how the technique in the article could be a good workaround.

ISTR some webcam software that would fall back to a java applet (that would parse the multipart MIME) on IE. Anything is preferable to that though!

<comment><USER4> Yes, but we did everything we could to stay away from things like java, downloads and plug-ins. Our mantra was 'it just has to work with whatever the user already has'.

And there always was a way, even if sometimes it required some - for want of a better word ;) - unorthodox methods.

</comment></comment></comment></comment><comment><USER7> For anyone who was, like me, confused by who "we" is and why I was supposed to know that, this is from the author's "About" page:

> _My main occupations are being owner /operator of ww.com, which pioneered > streaming webcam technology, and working as a consultant to do technical due > diligence._

Reading the article, at first I assumed he was someone who worked on an early browser or something, then maybe a hardware webcam manufacturer. I assume that he's just not used to people showing up at his blog with no context about who he is, so there you go.

<comment><AUTHOR> It's jacquesm ([https://news.ycombinator.com/user?id=jacquesm](https://news.ycombinator.com/user?id=jacquesm)), a regular and top contributor here ([https://news.ycombinator.com/leaders](https://news.ycombinator.com/leaders)). I think most regulars on HN recognize his blog and are somewhat familiar with what he has done. It would be nice to have a short explanation in the article though :)

<comment><USER8> I put together a set of capsule bios of the top 20 HN contributors, which might be useful background info: [http://www.kmjn.org/notes/hacker_news_posters.html](http://www.kmjn.org/notes/hacker_news_posters.html)

<comment><USER9> Nice work! It would be useful to have their HN names as part of their bios.

<comment><USER8> I was a bit undecided about that, though I'm leaning towards adding them now. There was a small discussion about that when I first submitted this: [https://news.ycombinator.com/item?id=6957005](https://news.ycombinator.com/item?id=6957005)

</comment></comment></comment></comment></comment><comment><USER10> Some IPSes (Intrusion Protection Systems) that perform deep-packet inspection won't pass such traffic.

But this isn't really a "bug" per se; the TCP model is a stream is a stream is a stream. There's no notion of time, packets, or correlation between streams. So browsers (and the OS) are acting only as they can; by treating a TCP connection as two independent streams.

(Though, how could it be otherwise? Assume HTTP over SCTP (sequenced packets). We can't require, or even allow, HTTP servers to ignore response packets that arrive "too early", since it's possible that observers of the client (e.g. Wireshark) may not observe the exact same timing, which would lead to divergent interpretations of the conversation.)

Amazon does this too. Upload APIs will return 4xx errors well before the body is uploaded in the event there's an issue with the headers. Not that (a) most HTTP clients pay attention to this, or (b) they can do anything about it without closing and reopening the connection.

<comment><USER4> > Some IPSes that perform deep-packet inspection won't pass such traffic.

So will those ISPs also not pass Amazon's upload APIs responses? That would be pretty sloppy!

<comment><USER10> IPS (Intrusion Protection System), not ISP. And yes, they'd drop the connection on such an error response if configured to do so. (Which is likely what you want to do anyway in this case. Amazon's engineers had the foresight _not_ to respond early in the case of a successful upload thankfully.)

<comment><USER4> Ah! Complete reading fail on my end. (thanks for the edit, it is much clearer now, I apparently substituted ISP for IPS).

I don't think it is possible to respond early in case of a successful upload, after all, that means the upload can still fail for a variety of reasons. Success indicates that you can move to the next state, and an 'early success' might still turn into a late failure.

</comment></comment></comment></comment><comment><USER11> Agreed with some of the other posters that this isn't a bug. It would be pretty hard for a browser to make this _not_ work. To make it not work, the browser would have to check whether there's data available in the local socket buffer before issuing an HTTP request. On Unix, you could e.g. put the socket in non-blocking mode, issue a read() to read 1 byte, and then see if you're getting an EWOULDBLOCK. If you get data instead of EWOULDBLOCK, then (supposedly) you're in violation of the RFC and therefore the browser might decide to close the connection (what should it do otherwise?)

It just doesn't make a lot of sense doing the above. Especially because there's a fundamental race condition here: there is no way to distinguish between data that's in-flight but not received prior to the browser issuing the request, and data that was generated after the remote peer read the browser's request.

<comment><USER10> You could encounter this behavior (dropping unsolicited responses) multiple "legitimate" ways (all of which suffer from the race condition you mention): reading & writing in separate threads can do it; so can an asynchronous receive mechanism.

Erlang TCP connections can be configured for asynchronous receive: any incoming data is delivered as a message to a given process, which usually immediately acts on it. Say this process has not yet sent a request; it's not unreasonable to just drop the incoming data.

Of course, I would consider such behavior non-conforming, for the reasons you point out. Time isn't really defined in a TCP stream.

Better is to utilize the flow control Erlang provides for asynchronous receive, but this is extra effort so it's plausible a naive implementation would miss this.

</comment></comment><comment><USER12> I remember this sort of thing being called "push" back in the day (1995 or so). Before animated GIF support was added to Netscape this was the only way you could achieve animation of any sort on the Web.

The only concrete example I can recall is that Suck.com used this to have an animated logo at the top of their page. (I think this predated the Java applet version that you see on the Internet Archive...)

<comment><USER4> You're thinking of x-multipart-replace.

</comment></comment><comment><USER13> This is a nice hack.

Combining it with dynamically generated DNS names might be a nice "content accelerator" add-on for CDNs, etc.

ie: a page uses resources, each of which has a unique url.

You have custom infrastructure (that sits in front of a normal website) which dynamically generates a new subdomain for each resource, and replaces the resource urls with the new urls (using the subdomain).

At the top of the page (or ideally on the previous page) you include some zero-length resources with the same MIME-type as the resources you want to serve.

The browser requests these resources, and as soon as you have the connection open you reply with the zero length resource and then the actual resource you want to serve.

Subsequently the browser requests the actual resource, and finds it already waiting.

The unique hostnames are needed to allow you predict which resource will be requested.

(This was probably patentable until I wrote it all out, too ;))

<comment><USER4> That needs a POC, I'm really curious if you can get that to work reliably. You may even have the ordering problem solved.

</comment></comment><comment><USER14> Isn't this what SPDY try to implement?

<comment><USER4> One of the elements in SPDY is that responses to requests can be pushed by the server anticipating a request. But that's a relatively new development compared to when I figured out that this 'feature' is supported by just about every browser out there. And it's kind of logical, if you implement HTTP in the most straightforward way then the network stack will buffer the response until the next read, regardless of what the rest of the program is doing. So when the browser issues that read (either in a separate reader thread or in the same one if it is programmed single threaded write-then-read style) it immediately finds the answer to the request it just sent out.

Strictly speaking extra bytes sent past the end of the response to the current request (or before even any request has been sent) is a protocol violation but I'm really not complaining about this one, after all, that line in the spec does not actually specify the timing. We all just read between the lines to see what we expect to see: ping ... pong.

</comment></comment><comment><USER15> This sounds less like a bug, and more like a specific tweak to his logic due to his specialized use case.

In most cases, even if the web server knows that a specific page contains images, it does not know if the browser is actually going to request those images. What if it is a bot? What if the user cancels? What if they have disabled image downloads in that browser? What if they have the images and other secondary files cached?

I do think it is worthwhile to consider such things for your individual needs, but most use cases won't change the standard request/response mechanism.

<comment><USER16> While true that you cannot know whether the client will request the images, you can use their user agent to make a pretty decent prediction. There will be corner cases where you are wrong, but most of the time your prediction will be true.

For instance, if a bot is pretending to be a Chrome browser, you'd think it was a regular client, but in fact it was not. But that's the bot's fault, not your implementation.

<comment><USER17> > _But that 's the bot's fault, not your implementation._

It's your implementation that breaks the protocol spec, not the bot, so it is still your fault.

</comment></comment></comment><comment><USER18> What is the purpose of this trick? So reduce lantency?

I get that if the browser sends a GET request for a picture, it's possible that the server already answered. But what happens afterwards?

Is the connection closed? Or does the server send another JPG again?

multipart-mime / content-replace only worked with Netscape, not with IE.

What else is needed for this solution?

Is there a index.html page with a <img>-tag and some javascript that requests the picture again every time the image was loaded?

</comment><comment><USER19> Is it possible that the technique had become widespread and actually known about by the browser makers? i.e. it was a bug but they didn't want to break any applications so didn't fix it...

</comment><comment><USER20> Am I missing a trick or does this only work when the only thing you're serving at that HTTP server is the JPEG image of the camera? Otherwise the user later refreshes the page thus doing a "GET / HTTP/1.1" and gets /image.jpg instead.

<comment><USER4> Yes, you're missing a trick. The url was modified on each request to bust the caches in between.

<comment><USER20> But how will that work if you're sending the response before you parse the request? You don't know the URL the client is after. Were you relying on the browser keeping the same connection alive so you always went index.html->jpegs?

<comment><USER4> The cam _only_ sends out images, it can't really do much else. So you don't need to know the request, it is implicit.

<comment><USER20> Right, what I meant was that you can't have the camera serve a nice /index.html with the embedded image and other niceties like modern IP cameras do, because you reply with an image to every request.

<comment><USER4> Well, you can actually. All you need to do is switch modes after the _first_ request, which you handle like every other. Which is in fact what it did... The idea here is that once you've received one request for an image all subsequent requests on that socket will be images as well.

<comment><USER20> Ok, then you are relying on multiple requests on a single socket, which was what I had suggested before. Does that work reliably though if the user reloads the page while it's streaming? Wouldn't the browser reuse the same connection to request the HTML page again and get an image instead?

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> Does anyone have any specific examples of this?

<comment><USER4> If you put your email address in your profile (or send me a line) I'll reply with a link to a cam that is still online from way back when using this technology.

I'd rather not post the link in the thread because the poor people sending out the stream would not be able to satisfy even a small portion of the kind of volume that HN can direct to a site in an eyeblink.

<comment><USER22> Alright, here's one of those dumb questions you seem very open to: Can we use this technique to (for example) reply with all of a page's dependencies upon the initial request? i.e. if a user goes to www.example.com/ and the server immediately replies with /, /favicon.ico, /styles.css, /script.js, /banner.png, etc? I imagine if it were possible, this would result in a massive reduction in latency...

<comment><USER4> Well, you can and you can't. See the problem is that you have no idea what the next request will be about! So if you're sending the _same_ kind of request from the client you can respond with a payload in the mime type that is being expected. But for your usecase you could receive a request for /style.css and respond with /favicon.ico if a client decided to make the requests in an order that you did not anticipate.

If you get lucky it will work, but if you're unlucky then you'll be sending out the wrong payloads on all but the first request.

The only reason this trick worked for the webcam is because it knows ahead of time what _kind_ of request will come (the request for the next frame). That's why it can anticipate.

<comment><USER22> Informative!

<comment><USER22> Now that I think about it, one could use a small javascript library embedded in the index page to make a number of additional requests and interpret them as the correct types via data: URLs. That would be a lot of messy hacking to shave off a few hundred ms, but might be an interesting exercise to undertake...

</comment></comment></comment></comment></comment></comment><comment><USER23> Using this method, you could possibly reduce load times by sending Javascript and CSS files with the HTML file

<comment><USER24> Assuming those requests are sent in order, that could be an interesting optimization!

<comment><USER4> > Assuming those requests are sent in order

That's the problem right there. Right off the bat I don't see how to get around that one.

<comment><USER13> Dynamically generated unique hostnames per resource would work.

<comment><USER25> I'm probably missing something but... wouldn't all the extra dns lookups remove most of the speed advantage?

</comment></comment></comment></comment></comment><comment><USER26> Isn't this what UDP is for? Or did it not exist in those days?

<comment><USER4> Sure UDP existed 'in those days'.

But how are you going to use UDP to send images to a browser without using a plug-in or an applet? The whole idea was to remain 'compatible' (for small values of compatible) with HTTP, which more or less guaranteed delivery.

UDP wouldn't make it through most firewalls and would make all kinds of assumptions about port forwarding and so on besides that fact that browsers simply do not expect content to arrive via UDP.</comment></comment>