Google Homepage Size Over Time - <AUTHOR> http://measuredmass.wordpress.com/2012/10/06/google-homepage-size/ <comment><USER2> I find this interesting as well as unimportant at the same time. Interesting because it shows that Google has responded to increasing connection speeds by adding bells and whistles to their homepage. That's really great.

Unimportant because with Google Chrome, Firefox, Safari, etc. - going to the google homepage is almost entirely optional. Google is working so hard into baking themselves into almost any facet of web functionality that their homepage is becoming less and less important over time.

The only reason I check the google homepage is to look at the doodles.

<comment><USER3> Strangely, Google is killing off the one thing that keeps me going to their _sorta homepage_ , iGoogle. When they finally do kill it about a year from now, I'll have to come up with some substitute which may not be so Google- centric.

<comment><USER4> Yeah I don't understand why they do that, igoogle is pretty good and I use it alot.

<comment><USER5> I don't even know what igoogle is or does.

User adoption is what drives features like this to remain, not how useful they are.

<comment><USER6> That is true. This feature has been around for many years and used to be advertised on their navbar before Google+ came about, but it never stood out as a prominent component of the Google experience. I figure they are pushing people to adopt Google+ as their "portal" but I'm likely wrong as the two products are quite different. It could also be that it doesn't generate any revenue and the experiment is nearing the end of its life cycle.

</comment></comment></comment></comment></comment><comment><USER7> I always enjoyed this interesting story:

 _One vigilante sent Google an anonymous email every so often just listing a number, like 37 or 43. Eventually Mayer and her colleagues figured out it referred to the number of words on the Google homepage—the implication being that someone was keeping track, so don't screw up the design_

– The Google Story

<comment><USER8> A friend of mine used to keep a post-it note on her monitor with 2,073,418,204 written on it. She was keeping track of the number of pages google reported it had indexed[1]. We got very excited when it changed to 3,083,324,652.

[1] [http://web.archive.org/web/20030205061559/http://www.google....](http://web.archive.org/web/20030205061559/http://www.google.com/)

<comment><USER9> Does Google report this anywhere nowadays? I searched for it a while back and couldn't find it.

<comment><USER10> I found only estimates: <http://www.worldwidewebsize.com/> 40-50 billion pages. From the site:

"The size of the index of a search engine is estimated on the basis of a method that combines word frequencies obtained in a large offline text collection (corpus), and search counts returned by the engines. Each day 50 words are sent to all four search engines. The number of webpages found for these words are recorded; with their relative frequencies in the background corpus, multiple extrapolated estimations are made of the size of the engine's index, which are subsequently averaged. The 50 words have been selected evenly across logarithmic frequency intervals (see Zipf's Law). The background corpus contains more than 1 million webpages from DMOZ, and can be considered a representative sample of the World Wide Web."

</comment></comment></comment></comment><comment><USER11> I see the general point being made here, but it's important to put it in context. The current homepage design is arguably more minimalistic and useful than any design from 2000 onwards. Links to other Google services are conveniently located in a bar at the top where they don't get in the way (as opposed to crowding the area around the search box previously). I can click a microphone and speak my query. When I start typing, results start loading instantly. All improvements in my book, and definitely worth it for the broadband world, which is probably a lot of Google's business at this point. I think it's important to separate minimalist and usable design from minimalist HTML -- I'm sure Google is keeping an eye on their page size and making conscious cost-benefit decisions here.

Now don't get me started on the results page though...

<comment><AUTHOR> I'm not sure I had a point (though minimalism is appealing); when putting the numbers together, I just wanted to see what the plot looked like.

</comment></comment><comment><USER12> TFA: "...included only the size of the '.html' file, no images or fanciness."

The '.html' file for google.com has most of the 'fanciness' embedded in it in the form of a ton of JS and all the CSS.

I think this architecture was put in place when instant search/preview went live which is the cause of the first large spike. I'm guessing the second spike is integration with google+.

</comment><comment><USER13> This looks incorrect. [http://web.archive.org/web/20110713000446id_/http://www.goog...](http://web.archive.org/web/20110713000446id_/http://www.google.com/) is only 28K according to ls -lh.

Perhaps OP forgot to put id_ after the capture timestamp in the archive URLs? The id_ makes sure that the Wayback Machine only returns the page as it was when it was indexed.

<comment><AUTHOR> I definitely used id_ . I saved the source that I used; I'll recheck things.

<comment><AUTHOR> Should be fixed now. The last point is still ~100k. Running Chromium, if I'm logged in, google.com's HTML saves as 104k. Logged out, it's 94k, as measured by ls -lh.

<comment><USER13> Looks good. I was using cURL, so that explains the ~100k vs. ~28k discrepancy.

</comment></comment></comment></comment><comment><USER14> I'd be curious to see a similar plot of average internet speed vs time.

<comment><USER15> And, correspondingly, a plot of Google homepage HTML file size divided by average internet speed vs time, so we wouldn't have to compare the two curves in our heads.

</comment></comment><comment><USER16> It's 100 kB now.

If the plot had a similar curve from 0-50kB would everyone still be commenting? What about 0-5 kB?

Is this about the absolute values or the curve?

Unless everyone is expecting exponential page size growth to continue indefinitely (and ignoring bandwidth increases), I don't see the point.

<comment><USER17> 1-5 kB would be even more interesting. That would make Google's flagship page several orders of magnitude smaller than most websites.

</comment></comment><comment><USER18> would be interesting to compare this to world wide typical and average bandwidth availability.

google used to prize page load times for their search landing page. i wonder if the increase is coming about because they recognize they can indeed get away with it and maintain their performance goals, or if they re-shifted priorities and/or acceptable values for load times.

<comment><USER19> Perhaps also the page is tee-ing up for even faster results page access, by way of instant search.

And I haven't checked, but perhaps most of the k weight comes in after the page has rendered, in which case it wouldn't negatively impact perceived load time.

The page is also more featurefull than it used to be when in the logged in state.

</comment></comment><comment><USER20> This is ignoring the fact that a whole bunch of assets (CSS/JS) are embedded into the page to reduce the number of HTTP requests.

<comment><USER21> Wouldn't it be better to have two asset pages, one for JS and one for CSS. ( unless there's a way to merge those two )

I don't know how often google changes that code, but even if it were as often as weekly, users would gain the benefit of caching those files and loading locally, thereby making the page even less to download.

Or are those two http hits really that expensive?

The only reason I can think it is a bad idea is caching could hurt them. If the browser doesn't handle caching correctly, and they do change the source, frequently or infrequently, users may see broken pages and/or broken functionality. Not all users know of Shift-reload, none should need to, and I find it doesn't work reliably myself.

What is the best practice here? 2 http requests, embedded code on the page, arbitrary http requests that are cached, no caching, etc.?

<comment><USER22> > If the browser doesn't handle caching correctly, and they do change the > source, frequently or infrequently, users may see broken pages and/or broken > functionality.

Typically you just use a new URL to get around this ... Frequently changed cacheable files (css, js) are usually timestamped or contain version information in the filename.

</comment></comment></comment><comment><USER23> On average, the size of a website triples every ~5 years.

Nowadays there are lots of really fat websites with tons of resources. Personally, I think that's kinda convenient. This way it's a lot easier to make sites which are much faster than those of the competition.

More and more people start to merge all of their CSS and all of their JS files, then they minify them, and finally the whole thing is gzipped. This surely helps a lot. However, their sites still continue to grow, because they continue to add more and more crap.

<comment><USER24> If only my internet connection tripled every 5 years too.

In reality, it was 28.8Kbps up to 1999, then has remained in the 2-3 Mbps range ever since.

</comment></comment><comment><USER22> I wonder how much of this has nothing at all to do with presenting search results to the user, i.e. fulfilling the user's expectations... (guess: > 95%)

Does anyone have a good CLI for Google and duckduckgo that I could use from within putty with clickable links? (similar to surfraw, but just dumping text + URLs from the results to stdout instead of launching a text mode browser)

</comment><comment><USER25> ?

$ curl -sL <http://google.com> | wc -c

11328

<comment><AUTHOR> Plot updated to answer your question. There's a big difference between that which is served to curl and to a browser.

Thank you!

</comment></comment><comment><USER26> Maybe it's psychological, but I feel that since they shifted to SPDY the encrypted version is more responsive despite the bigger size.

</comment><comment><USER27> The important thing is iGoogle was killed off.

<comment><USER28> Not yet, another year. <http://www.google.com/ig>

</comment></comment><comment><USER29> It gets cached so it's okay.

</comment><comment><USER30> The label of the ordinate contains an error - kilobyte = byte * 1024, as opposed to byte / 1024

<comment><USER31> No,

#bytes * (1 kilobyte)/(1024 bytes) = #kilobytes

or bytes/1024=kilobytes, for short.

Basically, it's a conversion factor, not a definition.

<comment><USER32> Might want to consider using the unambiguous term kibibyte instead.

<http://en.wikipedia.org/wiki/Kibibyte>

It is a tradeoff, it avoids the need to explain which definition of kilo is used, at the cost of using a far less common term.

<comment><USER33> Kibibyte doesn't make things clearer in this case. They aren't talking about whether the factor should be 1000 or 1024. The first poster said that kilobytes should be bytes * 1024. That is incorrect. The number of kilobytes is equal to the number of bytes / 1024, not bytes * 1024.

</comment></comment></comment></comment><comment><USER34> Seems like it goes down hill roughly when Marissa moved on.

<comment><USER35> I'm sure someone is measuring yahoo.com since Mayer joined. :)</comment></comment>


What is exactly in the air you're breathing? - <AUTHOR> http://whatsinyourair.hellowynd.com/ <comment><USER2> Why was "exactly" added to this title? It doesn't help and the position makes the sentence ungrammatical.

Not to pick on bayareafoodster, but I note both their other submissions have poor grammar in the titles. Generally best to stick to what the originals say, unless you can add value without errors.</comment>


Rewards of Up to $500K Offered for FreeBSD, OpenBSD, NetBSD, Linux Zero-Days - <AUTHOR> https://www.bleepingcomputer.com/news/security/rewards-of-up-to-500-000-offered-for-freebsd-openbsd-netbsd-linux-zero-days/ <comment><USER2> This makes me sad. People working on open source projects get nothing. Sometimes they get some money. Sometimes they get some fame. People who don't build anything, but find a hole, they are heroes, they get prizes, they are worshiped.

If there is a commonly used open source library without hackable bugs, you won't even hear about the author who committed his/her own time to build reliable software.

If someone finds a bug, then she will get some prize, and will be invited to a conference. And the library author will be publicly bashed as an idiot.

Sometimes open source people don't even get mentions.

I was working on a patch for a huge open source project once. I spent hours on that. Two other people helped me, they also spent some significant time on that. And we managed to implement this. Who was mentioned in the release changelog? The person who committed that. Then I stopped spending my precious time on such things like giving someone the credits for my work. I love programming, I work on my own projects instead.

And all that makes me sad.

<comment><USER3> _> This makes me sad. People working on open source projects get nothing. Sometimes they get some money. Sometimes they get some fame. People who don't build anything, but find a hole, they are heroes, they get prizes, they are worshiped._

I think you've misunderstood what's happening here. Zerodium, the company mentioned in this article, is an exploit broker. They buy vulnerabilities from researchers, then sell them on to government intelligence agencies. The entire purpose of their business is to undermine the security of the tools we use.

Bug bounties are a response to this trade in exploits. They incentivise researchers to publish vulnerabilities rather than selling them to spies. They're a necessary evil to keep zero-day vulnerabilities out of the hands of oppressive regimes. It's not nice, but that's just the world we live in.

Large companies that rely on open source software have started to understand the importance of financially supporting OSS development, largely as a result of the Heartbleed crisis. The Linux Foundation's Core Infrastructure Initiative has created a secure financial foundation for critical open source projects.

<comment><USER4> > They buy vulnerabilities from researchers...

or provide an opportunity for the original developers to introduce an obscure backdoor and cash out

<comment><USER5> That's an interesting take on the situation.

Was there any instance of this? Are there disincentives against this? (I guess the entity offering the bounty could say, only software released before this day is available. Though malicious contributors can very certainly guess that there will be other future bug bounties too.)

<comment><USER6> > Was there any instance of this? Are there disincentives against this? (I > guess the entity offering the bounty could say, only software released > before this day is available. Though malicious contributors can very > certainly guess that there will be other future bug bounties too.)

I believe sometime ago there was new surrounding backdoored crypto also on the low-level side of things there was a secret rootkit in Street Fighter that allowed for an EOP

[https://github.com/FuzzySecurity/Capcom- Rootkit](https://github.com/FuzzySecurity/Capcom-Rootkit)

[https://www.blackhat.com/docs/eu-17/materials/eu-17-Filiol-B...](https://www.blackhat.com/docs/eu-17/materials/eu-17-Filiol- By-Design-Backdooring-Of-Encryption-System-Can-We-Trust-Foreign-Encryption- Algorithms.pdf)

</comment></comment></comment></comment></comment><comment><USER7> There is a zero sum trade-of between exploit brokers and the public's interests. I don't mind for-profit businesses, especially large ones, paying for exploits to their own products. Open source projects such as the BSDs, however, can't afford it and they donate their work to the public for public benefit. For those systems selling and buying exploits rather than reporting them to the devs is unethical, IMHO, for both the exploit discoverer and the broker.

</comment><comment><USER8> Can we fix this kind of behavior without spiraling down to a money-spending competition? (Which the open source community clearly cannot win?)

With open-source developers being badly paid, large numbers of relatively unknown contributors with little to lose (ie no reputation, no criminal charges, no repercussions whatsoever), and major corporations not caring enough about Uncle Sam to spend $$ to shield open source software they use, who will stop this kind of decay?

It used to be that the stakes were low, the developing community was small, and the amount of software was manageable. If someone introduced a zero-day, sooner or later would be caught and kicked out. Few people cared about breaking into this software so some donated personal effort was adequate to shield against those intruders.

Now if you can remotely compromise Debian or Ubuntu you have millions of servers in your hands and potentially hundreds of millions worth of private data. I don't see how this can be stopped.

</comment><comment><USER7> I find especially interesting the tables showing the payoffs for exploits of different platforms. It gives us insight into supply of and demand for the exploits:

[https://www.bleepstatic.com/images/news/u/986406/attacks/Zer...](https://www.bleepstatic.com/images/news/u/986406/attacks/Zero- Days/zerodium_prices_mobiles.png)

[https://www.bleepstatic.com/images/news/u/986406/attacks/Zer...](https://www.bleepstatic.com/images/news/u/986406/attacks/Zero- Days/zerodium_prices_desktops.png)

</comment><comment><USER9> This gets into the entire controversial business of selling exploits to "Security companies." Often these companies are just brokers, sometimes selling to states, but also to criminals.

Years ago at Ruxcon in Melbourne, this came up in a panel discussion. One of the members, Ranty Ben, talked about how exploit sales were part of his career/income.

The talk was originally here, but it seems to be gone now: [https://www.youtube.com/watch?v=xlJ1DQdjVHM](https://www.youtube.com/watch?v=xlJ1DQdjVHM)

</comment><comment><USER10> >Zerodium is known for buying zero-days and selling them to government agencies and law enforcement.

So how much is Zerodium getting for these Zero days? If all you care about is money then aside from the fear that you might end up getting investigated by one of these agencies, why wouldn't you sell directly to them for more money than Zerodium is giving you.

Otherwise if you actually care about the security of systems, then disclose it to the developers, give them reasonable time to fix/patch and submit it as a CVE.

<comment><USER11> The concept of government contractors is quite common. If zerodium can guarantee auditing and safe zeroday acquisition then I don't see anything different in governments using a broker to attain their exploits.

The same attractions would apply as when they're dealing with other government contractors rather than individual actors.

The really sad thing here is that those exploits might be put to use against the people of the world.

</comment></comment><comment><USER12> I fell into cybersecurity after doing some consulting to a major department of the government of Canada on machine learning. While there I was shocked at how bad things are. FVEY may be the pre-eminent alliance in the cyber domain of war, but defence is so much harder than offence if the situation isn't rushed. This didn't really dawn on our political leaders until recently, but they don't really know what to do.

So I started methodically learning cybersecurity. I ended up writing this comment about a year or two in:

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

> It's surprising how bad cyber security is, but so much of it is right there > in the pages of this [U Waterloo textbook]. It's like finding out you can > buy a Patriot missile for $250 and some spare time in the evenings.

Over the past two years I think the world is starting to understand where we are headed, but there are no easy solutions. Many of the problems we have are the same ones we've had since the dawn of the NSA. Computers need operating systems. Operating systems are really fucking hard to make completely secure, let alone completely secure and borderline useable. If you think $500k for 0days is high you ain't seen nothing yet. When autonomous systems run everything or when greater numbers of Wall St traders start realizing what they can do with an 0day and some outlying put options we're going to see 0days worth tens of millions as the arms race heats up.

The problem with cybersecurity tools (and AI / autonomous systems) is that it's all dual use. The same tools you probe your own server with are the same ones you can probe others with. Worse—we can't even control the export of attack tools because it's all essentially just data. You can't stop people from memorizing code snippets or facts.

Even so, we need to instil fear into people in the West. We need to limit who they're legally allowed to sell the vulns to. Allied states: Yes. Defence interested parties: Yes. Some cybergang: Fuck no. We need to deny travel visas to the direct family members of other individuals in unaligned states that sell 0days to the worst actors.

It won't stop malactors from getting these bugs, but it will make it significantly more expensive for them to do so, and at the end of the day war and crime are economic concerns as much as they are political.

<comment><USER13> I saw an ad (math dept. at Canadian university) from the government looking to hire cybersec people. I was pretty interested, but didn't match the requirements they were looking for (experience with cybersecurity). As someone with a background in scientific computing, I wonder what the transferable skills are between sci-comp/cybersec, apart from data analysis/machine learning?

<comment><USER14> IMHO you are probably smarter than they are, especially if you can remain scientific about things.

</comment></comment></comment><comment><USER15> If the government has to crowd source its back doors then there may still be hope for digital freedom.

</comment><comment><USER16> Can't you use some form of static analysis to highlight potential vulnerabilities?

<comment><USER17> The low-hanging fruit amenable to this type of discovery has been plucked years ago.

</comment></comment><comment><USER18> This is disturbing. $500k payout for colluding to indrocuce a back door in OSS.</comment>


Show HN: I'm building a tile map editor - <AUTHOR> ...and posting my progress on youtube. Lately I've been trying to get some money going from my side projects (released a game on android supported by ads). I don't think recording me writing code is very appealing, so what I've been doing is after I add a new feature to my tile editor I'm posting a video showing the feature. I don't really know what I'll do with the tile editor after (besides using to create my games).
The videos are also helping me with my english. I used to be fluent when I was younger (and have conversation with actual people from school), now I just listen and barely speak, so the video is helping me with my pronunciation.
Anyways, here's the link if you're interested:
Part 1: https://www.youtube.com/watch?v=bzbs3rIJ-t8
Part 2: https://www.youtube.com/watch?v=iZzxaNkQPCw <comment><USER2> Your English is good, maybe just open the mouth more while talking, especially for vocals. Interesting videos.

<comment><AUTHOR> yeah, on the last video I was super tired. but thanks

</comment></comment><comment><AUTHOR> Part 3: [https://www.youtube.com/watch?v=eYC_AQCQKGY](https://www.youtube.com/watch?v=eYC_AQCQKGY)</comment>


Ask HN: How do I start building an affiliate site? - <AUTHOR> There was an article on here a few days ago about using low PageRank sites to find good terms to optimize a page for, and the author demonstrated that they bought geek-watches.com because of that information. That got me curious, and I started playing around with Google Keywords/Google Insights for Search. Most domains (sans dashes) for the keywords I tested that had more than 1K hits per month were taken, but I found and registered one that looks quite profitable: 17jewelwatch.com
The query has a strong average on Google Keywords, a good history on Insights, and directly refers to products which can sell for quite a high price.
Right now though, I don't really know what to put on the site, or what format I should use. I've been thinking of putting some general/historical information about the product, and then specific information for buyers, and some images/videos/etc. and doing this in a wordpress blog with a minimalist theme -- at the same time I remember reading many good things about the "Parrot Secrets" type one page layout, and I'm not sure overall what is the right way to go.
Does anyone have experience that they're willing to share? <comment><USER2> Publish unique content regularly and run the website as if it were your own business. It's the only path to succeeding with affiliate sites, skimming small profits over thousands of sites will never work unless you go deep into it. Sounds like you're new to the market. Lay low, make a little money and use this time to learn what works and what doesn't. End of the day a _real_ site with real unique well though-out content will rank well in Google over time and may attract real customers as opposed to skimming random people who land on your page/site.

</comment><comment><USER3> I guess the best for you to do is follow the <http://challenge.co/training/> They try to sell you a lot of stuff, but never the less they give you an amazing insight into building your own online site.

An other great resource is from problogger [http://www.problogger.net/31-days- to-build-a-better-blog-joi...](http://www.problogger.net/31-days-to-build-a- better-blog-join-9100-other-bloggers-today/)

In your case I would go with the challenge, it just started 3 days ago. so you are perfectly in time

</comment><comment><USER4> You probably missed the boat with this one. Google has been making it harder to rank with these kinds of sites. Sites like these are considered spam.

Create something of value, it's the only way!

<comment><USER2> If you publish unique content Google doesn't discriminate between an affiliate site, and a non-affiliate site. If you build your site out like a normal business would you have nothing to worry about. If you throw up one page with scraped content and expect to gain rank you're crazy.</comment></comment>


Can we warn humans about nuclear waste in a million years' time? - <AUTHOR> https://www.independent.co.uk/independentpremium/long-reads/nuclear-power-plant-radioactive-waste-chemical-weapons-disposal-a9103776.html <comment> 08-15 This is all completely backwards.

The dangerous fission products have half lives of around 30 years. If we consider them useless (they aren't), we can easily bury them. People will be able to read warning signs in 300 years, and rock formations stable for a few hundred years are easy to find. Or drop glass logs to the ocean floor; glass doesn't dissolve in a mere 300 years.

What causes long term problems are the transuranics. These have half lives of a few thousand years, and produce heat. Over the long time scale, the rock won't conduct away enough of that heat, so the repository heats up, corrosion is accelerated, solubility enhanced, etc. But they don't belong into the the trash. Transuranics can be separated and burned in a reactor.

After that, only weak beta emitters remain. I-129 is so weak, it probably wouldn't even cause problems if we used it to fortify table salt. (What to do about Tc-99 is a topic for another rant.)

So why don't we recycle the waste? Because politicians, not engineers, decided that if some nations recycle, terrorists will use the extracted Pu to make an atomic bomb or something. It's illogical, but for the sake of argument: No, they won't. Reactor grade plutonium contains ~40% of Pu-240, which makes it useless for bombs. But while Pu-239 has a half life of 24000 years, that of Pu-240 is only 6500 years. If we left the Pu in the ground for, say, 15000 years, half of it will decay. But what remains is actually weapons grade, and no longer protected by the highly radioactive fission products. What if somebody dug that up and made a bomb from it?

And now I'm looking at an article that lists ways to tell future generations how to find the plutonium mine.

<comment><AUTHOR> I'm trying to imagine a scenario where humans 15,000 years (or even 300 years) from now exist at a level of technology sufficient to dig up deeply buried plutonium and have it be worth the effort, for good or evil. With even that much tech, they'd surely have other tools easier to utilize. Might make an interesting nuke-fi story.

<comment> 08-15 You're not wrong. The point is that these anti-proliferation arguments are internally inconsistent.

To be honest, I think the anti-proliferation concerns together with the ridiculous million year horizon were made up in order to have an argument against nuclear power.

<comment><AUTHOR> As I replied to the other commenter, it's most interesting as a semiotics puzzle. We agree, OMG!nuclear is more of a distraction.

</comment></comment></comment></comment><comment><USER2> This title made me think:

1\. Will our society live to warn the future humans?

2\. What the hell we are doing to earth

</comment><comment> jerome-jh No need to warn them, a Geiger counter is more than enough to detect nuclear waste. Spared reading one article.

<comment><AUTHOR> The article explains how waste may leak and contaminate water supplies or make its way up the food chain. Future humans or others may find these facilities and not comprehend our warnings. It may or may not be possible for everyone carry a radiation detector at all times.

<comment> jerome-jh There are areas where natural radioactivity or chemicals just occur at dangerous levels. So it is certainly not a new problem to spot and avoid those areas.

So in xx years:

Either humans still have technology, and they can find out there is contamination with a Geiger counter or chemical analysis, and stay away as much as possible from the contaminated area.

Either they lost technology/knowledge, and they will over time find out the place is unfit for life, through unborn babies, malformed animals/human, or other signs, just like the ancients did. In this case, our warning signs are of no help either, may actually be counter productive.

I stand by the idea that's the kind of article that's not worth reading past the title.

<comment><AUTHOR> I don't disagree with you. I think it's most interesting as an abstract semiotics puzzle. What information conveys extreme danger (whether emergency, acute or chronic) when the observer no longer shares our language, or even our species?</comment></comment></comment></comment>


Ask HN: Is the future of server-client communication gRPC or GraphQL? - <AUTHOR> <comment><USER2> Neither.

gRPC is an RPC mechanism, IDL, and codegen that uses HTTP2 as a transport, but by design requires the designer to control (and/or supply) both the server and the client -- or provide ample, ample documentation of the binary serialization format and the interface for a third-party to be able to implement a client, which is considerably more effort than today's typical scenario of loosely, best-effort parsing some JSON and pluck out a field or two. Therefore gRPC is _most_ useful for internal (i.e. server-to-server in the same org) communication and for server-to-official-client communication (like from Google's servers to the Official Gmail App on multiple platforms).

GraphQL is a query language. It's a way of structuring requests, similar to how SQL is a way of structuring requests you then send to a database engine to evaluate. Just like SQL is a perfectly acceptable interface of interacting with certain applications (like databases), GraphQL is too, which treats the executor as a big datastore.

However, mutations in GraphQL read much the same way as Document-Wrapped style WSDL: you define VerbInput as the incoming message/Object, and VerbPayload as the response message/Object. While GraphQL is otherwise really neat, I fail to see the innovation here; this is simply RPC over an object-oriented wrapper using a syntax that's clearly not amenable to it [1][2].

[1] [https://facebook.github.io/relay/graphql/mutations.htm](https://facebook.github.io/relay/graphql/mutations.htm)

[2] [https://facebook.github.io/relay/docs/graphql- mutations.html...](https://facebook.github.io/relay/docs/graphql- mutations.html#content)

I believe that JSON-on-the-wire, HTTP(2)-as-a-protocol will remain the most common form of client-to-server (and vice versa) interaction in the future. Note that this _isn 't_ the same thing as REST, albeit many such APIs are colloquially called 'Restful'. This style of APIs is typified by up-and-coming codegens like Swagger, RAML; the ones that look on the wire like [http://jsonapi.org/](http://jsonapi.org/)

And the reasoning is:

\- it's easy to produce as a server

\- it's easy to consume partially (as it's often done), or in entirety

\- it's plausibly human readable, and thus, debuggable without special instrumentation

\- it's (mostly) emittable and consumable by a wide range of programs and environments, like the browser address bar, XHR, Fetch API, the browser JS console, curl, wget, and a myriad HTTP clients</comment>


Perceptiv's Shift (YC W15) Turns Drones into Smart Dollies for Filmmakers - <AUTHOR> http://blog.ycombinator.com/perceptivs-shift-yc-w15-turns-drones-into-smart-dollies-for-filmmakers <comment><USER2> That's a very nice control system. Smooth tracking, and no visible jitter in the shot. Tracking reliability will be the big issue; losing track on the hero during a shot is unacceptable.

I wonder how they do tracking. The tracker in OpenCV isn't that good, but then it's about fifteen years old.

Movie production will soon be using fewer Louma cranes and manned helicopters.

They'll eventually need to put an ADS-B transponder (there's a 100g unit available for drones) on the thing and get the procedures in place with the FAA so productions can use this in areas near airports. That makes the drone radar-visible to air traffic control and other aircraft.

<comment><USER3> Founder here :). Thanks for the great comments! OpenCV has very rudimentary tracking capabilities. This is why we went back to the drawing board and developed something that is robust in a wide number of cases including in busy environments or where saliency is not high.

You are correct about tracking reliability, however, most of our early customers were more worried about creative control and smoothness. So, we've worked hard to make sure they get that level of control while not having to worry about the minutiae of controlling a drone/gimbal.

In cases of occlusions or odd situations where it may lose track of the actor, they are more than happy to quickly re-initiate tracking.

</comment></comment><comment><USER4> Heck yes! Alas not a filmmaker but I have wanted something very nearly like this forever. I go horseback riding regularly, mostly through relatively open areas (county parks / regional preserves / city trails etc). I have wanted a drone that can carry a GoPro (or something) to capture footage of our rides (sometimes we go through some gorgeous country that we really wish we could capture on video).

However, here is the kicker, because we ride at a fast trot or canter, I can't actively control the quad. Instead, I must be able to passively control it. It must perform specific, pre-defined actions based on my position, speed, and heading while flying, steering, and maneuvering without receiving any input directly from me. It should continually adjust its position and flight path based on my speed according to the rules I pre-define. For example, after takeoff with the camera turned on, the drone ought to stay ahead of me, say 30 feet ahead and 20 feet off the ground. Then if I start moving faster than 10 mph it should come to my side about 30° (10 o'clock). If I continue at this speed for more than a minute it should do a slow semi circle around me and come to the 2 o'clock point for a minute. If I keep going it should... etc etc. I don't care if I have to program the drone in code or through a UI, I just want to be able to define lots and lots of rules (based on the terrain of the day). Of course it would need to protect itself from running into trees and walls, or any other objects while trying to follow my rules as closely as possible.

You have my attention.

<comment><USER3> Wow. This is great information! You have a very well laid our requirement :).

"Of course it would need to protect itself from running into trees and walls, or any other objects while trying to follow my rules as closely as possible."

And that is the kicker. A lot of the features you've outlined can be done with current technologies simply using GPS (though framing would be wrong unless you have a SHIFT-like product). However, none of it is safe to use. Even if you were in "mostly" open areas, to constantly watch out and make sure the drone doesn't crash is very cumbersome.

Comprehensive sense-and-avoid is the golden egg of the drone community, precisely because of the features you've mentioned!

</comment></comment><comment><USER5> Nice application! Based on what I have seen so far, I am pretty sure they are using a tracker based on correlation filters [1]. These are very fast and robust. Naive implementation does not provide scale, which is visible in the video. but this is rather trivial to do. OpenCV 3.0 has also implemented this MOSSE [2] tracker.

Overall, these trackers are not able to learn and will always fail in same situation. It would be great if they had re-detection capability and improve with every touch from the operator.

[1] [http://home.isr.uc.pt/~henriques/circulant/](http://home.isr.uc.pt/~henriques/circulant/) [2] [http://www.cs.colostate.edu/~bolme/publications/Bolme2010Tra...](http://www.cs.colostate.edu/~bolme/publications/Bolme2010Tracking.pdf)

<comment><USER3> Wow! The author of TLD, that's quite the honor :). You are right about a lot of the issues we've been facing. However, our focus is squarely on getting tracking results VERY fast, so we can get smooth operation from our controllers. We are working hard to incorporate some global re-detection (and scale), however, we are balancing this with running the algorithm fast online, onboard the drone.

I'd love to talk and bounce more ideas off of you! Ping me, pj(at)perceptivlabs.com

</comment></comment><comment><USER6> I wonder if this is based on OpenCV or if it's a proprietary system. Looking at the demo it could be using CAMShift with Kalman control?

My experience with OpenCV is that object tracking depends heavily on hue differences between the tracked object and the background - eg. I start out tracking my face, and wave my hand in front of my face, the tracker then starts to track my hand instead. Have you found a good way to mitigate this issue?

<comment><USER3> Very good question! a) We've found that OpenCV's boilerplate algorithms have much bigger problems than the ones you have mentioned in deployment scenarios. So, we've had to develop something better from the ground up (while still using the OpenCV infrastructure). b) For the tracker to go back to tracking your face, it would require global re-detection which is usually a much slower process. Moreover, the tracker would have to know what your face looks like under different lighting conditions and angles. This is something we are investing in heavily. Convolutional neural networks have shown a lot of promise!

</comment></comment><comment><USER7> This is fantastic. I've been wanting to see something like this!

I'd love to see a partnership with GoPro and get these into live events (once GoPro can do live feeds). I'd love me some Red Bull Rampage, or Supercross footage.

Supercross has this spider cam concept they started this year, but it still requires a camera on wires zigzagging the stadium, this would solve the issue. if you can get live footage out.

awesome stuff!

<comment><USER8> Perceptiv founder here. Thanks for the support! Would love to talk to GoPro but we haven't been able to do that, so please talk to us if anyone has leads :) Great idea about live streaming! We're definitely trying to figure out how to do that.

</comment></comment><comment><USER9> Filmmakers?

This is law enforcement and military's wet dream. Chasing suspects or hostile force in an urban setting. Possibilities are endless.

<comment><USER3> Hahah! I'm sure it is, but it is far less interesting to us. To know that someone is creating fantastic works of art using something you've made is much more rewarding :).

</comment></comment><comment><USER10> Never thought we could possibly have self flying video camera drones that I used to see in animation films, in real life...

</comment><comment><USER11> Any prospect of prototype availability for an upcoming project?

<comment><USER3> Hey! We can definitely talk about this. We do have early prototypes. Ping me, pj(at)perceptivlabs.com

<comment><USER11> OK, I'll be in touch this week. Thanks!

</comment></comment></comment><comment><USER12> amazing product and kickass team</comment>


Ask HN: The Future of Mobile Payments Processing - <AUTHOR>

Hi HN, I'm working on a project and I just wanted to get a general feel from peers with a pulse on public perception. I'm caught between working on hardware to read banking cards via the audio jack and via optics (i.e. Card IO). Also as a heads up, I'm keenly aware of Apple phasing out the audio jack in favor of their lightning interface and the pros and cons of both implementations.
The problem is while this optic based data extraction is low-cost and democratizes card data gathering amongst other things, I don't believe it will grow in popularity because people generally don't trust the technology with private data. The concept of you putting your banking card up in a specific frame and a snapshot taken (even though it's not saved) will not resonate with a society already plagued with various privacy concerns. It will also be hard to process the numbers on older, heavily use cards with recessed numbers etc.
I'm curious to know what you all think about this growing movement of data extraction at the cross section of mobile payment processing.
Thank you. <comment><USER2> To be honest I don't see room in the mobile payments market anymore for third parties. I see Apple pay,Google wallet,PayPal and Amazon taken up 95% of the pie in 5-10 years.</comment>


How to fight back against Google AMP - <AUTHOR> https://markosaric.com/ <comment><USER2> You're linking to a home page. Link to the article is [https://markosaric.com/google-amp/](https://markosaric.com/google-amp/)</comment>


Ask HN: How do we sell our profitable dev shop? - <AUTHOR>

Both of us are regular contributors to HN. We are two partners who have a dev consulting company. We need 2 sell it "quickly" (other opportunities - we have a great working relationship and biz is growing). One of us could stay on full-time and the other one would leave, if we sold.
Our company does python, ruby, scala. No Java/PHP. Some Apps. We have a full pipeline of work for months. We do not do outbound BD. We have a staff of about 15 people. We are half in the US / half offshore. Almost all are on US timezones.
A US buyer w/US devs that wants more offshore devs could be great.
We are jolly good at what we do. Our clients like us. We have some popular apps and websites that our clients built.
Sorry for being so vague. We are sure its a good business to sell. do not want to upset existing customers or employees and we are both popular enough on hacker news that people may notice. We do not know how to find a buyer!
an email is in our profile (or comment here?) <comment><USER2> Annual revenue is there, but what are the annual earnings? I think the investor would just clip coupons and wouldn't want to manage it so the question is: what is the coupon? (You might be able to do the same:If you don't need the money but just want the time, wouldn't the person leaving just make their dividends? And the person who stays just gets the salary+ dividends?)

<comment><AUTHOR> removed details above. 25% gross margin tho.

</comment></comment><comment><USER3> If I were in this position, I'd try to work something out with one or more of the 15 staff. Those are the people most likely to be able to derive ongoing benefit from the business.

Consulting businesses are notoriously hard to sell, the perception (rightly or wrongly) being that a lot of the value lies in the current leadership.

<comment><USER4> I'd agree... A phased approach is probably best but it'd be a long one.</comment></comment>


Ask HN: How do you motivate yourself to exercise or eat healthy? - <AUTHOR>

<comment><USER2> Besides look in the mirror?

But seriously, in my case, I'm determined to never become an insulin-dependent diabetic. I was over 340 lbs. 16 years ago (and believe it or not, I was _not_ a big eater compared to male peers), then I read about low-carbohydrate eating strategies, and had slow but significant success (lost over 120 lbs in a 20-month span).

But getting back to the question: my motivators were/are: 1) appearance 2) staving off degenerative disease (diabetes, heart disease, etc.) 3) activity enjoyment (e.g. hiking, volleyball, etc... weight is a limiting factor and contributes to injury)

My biggest problem is maintaining a regimen when I am _not_ getting results. This is how I derailed in the first place in my late 20s -- despite running 4-6 miles 2-3 times a week, I couldn't lose an ounce.

Also, keep up on current science: for example, you could expend a lot of effort doing something that isn't that helpful if you a part of the population that is a low genetic responder to cardio (see the University of Bath study as covered in Michael Mosley's "The Truth About Exercise" on PBS). In my case, I also exhibit the classic symptoms of AD-36 exposure, so I have a tougher row to hoe.

<comment><USER3> Wow AD-36 is interesting! I never knew that. I'm curious if we could give it to people having trouble gaining weight?

</comment></comment><comment><USER4> The thing is that once you get your diet and exercise routine right 'for you' then the issue of how to keep it up goes away. It's so self-reinforcing that you would be hard pressed NOT to eat and exercise well.

The hard part is getting it right for you. I like to run and I've run my whole life so exercise was never an issue, guess I lucked out there. I've tried going to a gym many times and it just is not for me, for example.

Whereas it took until my 50s to figure out that a low-carb diet was right for me. Before I had a terrible sweet tooth, but now you couldn't pay me to eat sugar.

So my advice is to try lots of things without getting hung up on the dogma associated with each, until you find the things that click.

</comment><comment><USER5> By understanding that change does not happen immediately. I read somewhere that it takes 60 days to form a habit. Rather than look for changes, I looked to form a habit of walking every day for an hour. I've lost 25 lbs in the past three months. I didn't see the slightest bit of a difference in the first two weeks, but I kept going. Make it a habit and you won't need to motivate yourself.

</comment><comment><USER6> Its not about being motivated, its about designing your lifestyle, if you want to eat outside but the table is inside, move the table outside. Design your life so that you have to workout, rather than fighting temptation just don't have crap in your cupboard. Sell your car and buy a bike.

</comment><comment><USER7> Exercise: make it part of your commute, by biking or walking to work. Or something you enjoy, like hiking, cycling, basketball, tennis, etc.

Eating healthy: remove everything you shouldn't eat from your home and only eat food out of your home. Eat Soylent for one meal a day.

<comment><USER8> Have you played with Soylent at all for flavoring btw? I'm curious if people are doing that or just going with it plain.

<comment><USER7> I'm drinking it plain and quickly, like medicine. It's not offensive but I don't want to become offensive or boring over time.

</comment></comment></comment><comment><USER9> I think it is not too hard. For myself I am just feeling a lot better when I eat healthy and go to the gym. I am more productive and more alive. I can learn more, work more and so on.

</comment><comment><USER10> I had peripheral neuropathy (tingling in my hands and feet). It turned out to be a vitamin B deficiency. But while we were trying to figure out what was causing it, one of the options was that it was an early onset warning for diabetes. I asked the doctor what to do now so that I didn't get diabetes in five years, and he said, "lose X pounds". That set a target weight for me, and gave me a pretty strong incentive to try to hit it.

In actual fact, I tend to run about 2-3 pounds above my target, but I take stronger action above that.</comment>


New Workplace Policy and Training Requirements in California - <AUTHOR> https://casetext.com/posts/new-workplace-policy-and-training-requirements-in-california <comment><USER2> It's amazing the minute nooks and crannies of life that government is involved in these days. You can argue that the effects of this legislation are worth the costs, but you can't argue that there isn't also negative consequences of such legislation. And it's much more than economic. There's a slippery slope you go down, and if you don't realize until it's too late things can get real nasty.</comment>


Google+ Games will not be available after June 30, 2013 - <AUTHOR> https://support.google.com/plus/answer/3123176

<comment><USER2> Seems to make sense; it was never fully opened to developers, and making Google+ a Facebook-style app-platform-on-a-webpage never seemed a very Google-y approach (for gaming or anything else); so its not surprising that they announce its retirement at the same time that their strategy around Google+ apps in general and gaming in particular are more clear (cross- platform gaming services under Google Play Gaming Services, app integration with G+ through G+'s SSO features and, for sharing via G+, the Moments API.)</comment>


Kubernetes 1.15: Extensibility and Continuous Improvement - <AUTHOR> https://kubernetes.io/blog/2019/06/19/kubernetes-1-15-release-announcement/ <comment><USER2> >Details about what makes a schema structural will be published in a blog post on kubernetes.io later this week, and it is of course documented in the Kubernetes documentation. < [https://kubernetes.io/docs/concepts/extend- kubernetes/api-ex...](https://kubernetes.io/docs/concepts/extend- kubernetes/api-extension/custom-resources/#specifying-a-structural-schema) >

It doesn't actually appear to be documented there (yet). However this appears to be the KEP for it: [https://github.com/kubernetes/enhancements/blob/master/keps/...](https://github.com/kubernetes/enhancements/blob/master/keps/sig- api-machinery/20190425-structural-openapi.md)

<comment><USER3> You can find it in the official docs here:

[https://kubernetes.io/docs/tasks/access-kubernetes- api/custo...](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom- resources/custom-resource-definitions/#specifying-a-structural-schema)

</comment></comment><comment><USER4> It sort of bothers me that the kubeadm logo is just the K8s logo wrapped in the React logo.

That said, I'm a big fan of the improvements to the CRD's. That was a pain point in the past.

<comment><USER5> It bothers me that the people mistake the stylised atom drawing for some JS library.</comment></comment>


Shit Linus Says - <AUTHOR> https://gumroad.com/l/prQdM <comment><USER2> This would be great if it was just a download link but they make you use a horrid email thing.

<comment><USER3> Why not just use mailinator.com to get around that?</comment></comment>


Open webOS 1.0 is here - <AUTHOR> http://www.webosnation.com/open-webos-10-lands

<comment><USER2> The GitHub repository is at <https://github.com/openwebos/> for anyone who is interested.

I'm tentatively excited by this. webOS was my 'first love' in modern mobile operating systems. Though it lacked the polish of iOS and was limited by the hardware both Palm and HP chose to pair with it, it was ahead of its time in many respects.

Just think, before the original Droid launched on Verizon, webOS had more marketshare and mindshare than Android. Imagine what could have been.

<comment><USER3> I like the approaches of both webOS and Firefox Mobile OS. For sure Javascript might not be the language one would choose to start with if one was re envisioning the web today with all the last decades learnings. And perhaps a fresh start could see lots of the incidental and accidental complexity dropped from CSS and HTML. But they are what we have today, and perhaps in time Javascript can align itself more closely to Scheme and a WebCPU element can come along to allow near native code where needed.

I have difficulty seeing a strategy underlying Google's effort with Java/Android - I dont see where it fits for a web company. The App / App Store centric distribution model is a step away from open exchange of information, and the whole App updating model seems very pre- web. Building up yet another Java ecosystem for UI seems another miss step like the original MIDP/J2ME disaster - what is it with Java encouraging non domain experts to implement libraries and frameworks?. Particularly as the web seems to move farther each day from Java in the browser.

Also iOS is quite uninteresting to me from an application development perspective. It has a very 80's feel to it with hard coded apps encouraging fragile pixel precise layouts. It seems primarily about building a money pump around a closed eco system. Some elements of the system are beautiful executed - the whole CoreAnimation / CALayer giving fluid graphics composition for example. But for the vast majority of throwaway apps the level of effort needed to implement native Apps - which for the most part are a gluing together of OS APIs seems like overkill.

<comment><USER4> Yes. It seems like you could reuse a lot of work from your web application with something like WebOS.

("It seems" == totally unfounded guesswork).

iOS development seems like more of a temporary stopgap to the eventual rise a great standardized mobile web platform. Well, temporary meaning "probably 4-5 years or so".

<comment><USER5> Agreed. While I totally understand the reasons for going native, it depresses me to see so many people so enthusiastic about it. We _only just_ got out of an era where you had to recode significant parts of a web site to satisfy all the browers.

We can at last write once and use (almost) anywhere... so now we go straight back to boxed off proprietary solutions.

</comment></comment></comment></comment><comment><USER6> Hold the phone. It's Linux based, open source, and apps are written in Javascript, not Java?

Down with Android. Long live webOS!

<comment><USER7> I don't understand the hatred of Java and love of JS. Is Java not open source? And isn't Android open source as well? Note that Google apps are not part of the core of Android.

<comment><USER8> From my perspective, JS is more more enjoyable to use when writing UIs. Java's strictness is not nearly as useful for UI work than it might be for other domains, and Javascript's first-class functions greatly simplify event-based work (which is much of what happens in a UI). Also, JSON is painless to use in JS, while Java will again get bogged down in its type system -- if you use JSON as a transport format then yet another plus for JS. Java is great for the server, but I would never want to write a UI using it.

</comment></comment></comment><comment><USER9> I wonder if a better approach would be to rebuild WebOS on top of an Android base instead? It seems like they are choosing to fight a war they cannot possibly win. If they want to run on other people's hardware why not build on top of a very well supported platform? Any rooted phone would have 100% driver support. Could be easier than installing a custom ROM. At least they would be able to get a foothold in the market. If my Galaxy Nexus could run the WebOS UI and continue to run legacy Android apps I would switch over right now. I know this isn't really the original goal of this project and maybe there are good technical reasons this would not be possible. It just seems like it would achieve the same thing in a more practical way. Perhaps they could maintain both a standalone WebOS and a WebOS/Android version?

<comment><USER10> Someone can probably build an app player for android apps, but architecture wise, what you just described sounds kind of like a custom UI for android.

The rationale for not doing something like this philosophically is that the underlying point of webos is that it shouldn't feel like a 'whole new platform' to a web developer, but rather the platform they are already most familiar with, even more than android, i.e the web.

</comment></comment><comment><USER11> Might have some pretty major security flaws...

[https://github.com/openwebos/core- apps/tree/master/com.palm....](https://github.com/openwebos/core- apps/tree/master/com.palm.app.email#html-sanitizer-function-used-in-the-email- display-message-view-is-limited-to-remove-only-certain-tags-such-as-script- iframe-object-embed-more-generic-solution-is-planned-for-post-beta-release)

</comment><comment><USER12> I loved WebOS, but part of the key to the gestures, on my Pixi at least, was the touch sensitive area beneath the screen. I didn't expect that to translate well to the tablet form factor, though I never tried a touchpad running WebOS.

</comment><comment><USER13> If (usable) builds come for the Galaxy Nexus, I will be forced to try this out :)

<comment><USER14> Here you go: <http://blog.openwebosproject.org/post/32477144913/news-flash>

<comment><USER15> Well, about that "usable" part...

<comment><USER14> Need to be patient, porting is a laborious task. This is nothing more than an early alpha.

</comment></comment></comment></comment><comment><USER16> WebOS could do something different and allow for apps to be loaded on the fly via a URL. Oh wait, that's what a web browser does..Why isn't WebOS aiming to be a web browser with the ability to cache apps using standardized (or maybe non-standard if needed) technologies? Then, you wouldn't need a marketplace or app store necessarily, because users have access to the apps directly off the web. Not to mention, this will save storage and move towards cloud computing more nicely. Oh, and think about how easy it would be to transfer an application from device to another device. WebOS should focus on being just that, a web OS. This means URLs; DNS is the backbone of the web after all.

</comment><comment><USER17> Curious, is this helpful to people building web apps or ios/android mobile apps ?

</comment><comment><USER18> These mobile platforms that use web tech(boot to gecko, webOS, etc) really aught to wait till ES.Next becomes implemented before they go 1.0. If they have C++ code extensions, they aught to wait till C++11 is full implemented in their compiler of choice.

<comment><USER19> Why?</comment></comment>


WebSockets RFC is now official - <AUTHOR> http://www.ietf.org/mail-archive/web/ietf-announce/current/msg09663.html

<comment><USER2> What's the best option for using websockets with Python?

WSGI doesn't support it ([http://librelist.com/browser//flask/2010/9/1/flask- and-webso...](http://librelist.com/browser//flask/2010/9/1/flask-and- websockets/#c5cd3883a8012c672792106000e11c63)). gevent is an option ([http://blog.pythonisito.com/2011/07/gevent-zeromq- websockets...](http://blog.pythonisito.com/2011/07/gevent-zeromq-websockets- and-flot-ftw.html)), but would something like Mongrel2 be better (<http://mongrel2.org/>)?

UPDATE: There's also Juggernaut (<http://flask.pocoo.org/snippets/80/>), which uses node.js under the hood.

<comment><USER3> I have had a lot of success with Tornado ... <http://www.tornadoweb.org/documentation/websocket.html>

<comment><USER4> +1 for tornado. And I also use Tornadio, which implements the backend for Socket.io.

</comment></comment></comment><comment><USER5> Websockets browser support: <http://caniuse.com/#feat=websockets>

<comment><USER6> I let socket.io worry about that. Great library.

<comment><USER7> I agree about socket.io. It works quiet well for most of what I need. The only issue I have with is is I can't figure out if it now supports sending and receiving ArrayBuffers? Does anyone know anything about this?

My use case involves sending model data to display in WebGL. Sending it any other way would be inefficient.

<comment><USER8> It's something we're currently working on. We're going to be integrating a XHR binary data fallback as well into our realtime engine.

</comment></comment></comment></comment><comment><USER9> For Perl mongers interested in WebSockets then take a look at...

* Mojolicious web framework which managed to keep up with the constantly moving standard! - <http://mojolicio.us/>

* PocketIO which is a Perl implementation of SocketIO - <https://github.com/vti/pocketio>

* Protocol::WebSocket module which adds WebSockets to the PSGI (Plack) stack - <https://metacpan.org/module/Protocol::WebSocket>

</comment><comment><USER10> Yay! Looks like they fixed it. Now, it looks like it is a normal upgrade request so proxies, et al, should play nice. Yaaay!

<comment><USER11> Yep, they undid the crazy 8 bytes of body that wasn't declared by content- length, back in hixie-76. The current protocols play nicely with HTTP aware proxies now.

They introduced plenty of other crazy things.. but at least it works with proxies.

<comment><USER12> I'm not to happy with this change though.

At least with hixie-76, connections would fail to connect if the intermediate proxies are not understanding WebSockets. Now, your connection will succeed, both client and server will believe they can successfully communicate, but communication will not work and die a slow timeout. Not very reliable, is it ?

<comment><USER13>
      * try websocket
      * on failure, fallback to comet

It's fairly easy to implement.

</comment></comment></comment></comment><comment><USER14> Mojolicious, a modern Perl web framework, has great support for WebSockets. Check out <http://mojolicio.us/>

<comment><USER9> You probably couldn't see my earlier Perl comment in all the jetsam & flotsam here :)

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

</comment></comment><comment><USER15> Now CouchDB's _changes can support websockets!

</comment><comment><USER16> link to html version: <http://tools.ietf.org/html/rfc6455>

instead of the plain-text one: <http://www.rfc-editor.org/rfc/rfc6455.txt>

</comment><comment><USER17> I look forward to pushing this to the absolute limit. Chat? Can we do something cool with voice? What about websites-as-desktop-software that started when Ajax got cool, but paused when developers ran into the limits of Ajax? How far can that now go? GPS services?

<comment><USER18> gps service? checked!

Well kind of. Last summer I did a road trip to newfoundland (canada) with a laptop, a gps and a webcam onboard [1]. The idea was to have people (friends and family) to follow our trip through a website to which I pushed webcam frames and gps coordinate in real time using websocket (socket.io) over my smarthphone. It was fun!

[1]: [http://blog.rassemblr.com/2011/07/how-to-hack-a-road-trip- wi...](http://blog.rassemblr.com/2011/07/how-to-hack-a-road-trip-with-a- webcam-a-gsp-and-some-fun-part-i/)

</comment></comment><comment><USER19> ITYM "WebSockets is now officially IETF Proposed Standard" or something like that.

Publication as an RFC doesn't signify any status of the protocol standards- wise, almost any protocol can be documented in an informational, experimental or historical RFC.

<comment><USER20> But RFCs don't change every month, which is the real milestone being celebrated here.

</comment></comment><comment><USER21> Let the games begin!

<comment><USER22> Quite literally. One of the most obvious applications of this is creating asynchronous multiplayer browser games.

<comment><USER23> Oh boy. Pretty soon we will need UDP sockets in the browser.

<comment><USER24> WS is already kind of fire-and-forget. Socket.IO supports that, and can handle thousands of messages/second, I don't think that will be needed.

<comment><USER25> Except, it's implemented on top of TCP. So you still have the head-of-line blocking problem. In a real-time application like games, if some congestion causes a few packets to be dropped, you don't care about them any more (assuming your protocol gives absolute positions of everyone involved); but in TCP, they will be retransmitted, and later packets queued until it can catch up. As websockets are based on TCP, you can't avoid this. Even if you have a "fire and forget" message based layer built on top of TCP, the head-of-line blocking will still kill your performance, causing people with bad connections to get persistent lag rather than a few dropped frames.

<comment><USER24> That's true, but in practice networked games built on websockets are doing fine right now, and will until browsers get stable capabilities for more intensive 3D gaming (likely in around 2 years time). I guess I meant they won't be needed _yet_.

<comment><USER26> Well, I'm working on a web-based real-time multi-player game, and I'd say that UDP would be very welcome by me. When I'm on a good connection, TCP is fine and things work perfectly. But as soon as my connection becomes just a tiny bit unreliable and packets start dropping, it becomes completely unplayable, as TCP has to retransmit those dropped packets before any new packets are processed.

Since all we get is TCP right now though, you can take advantage of that at least and easily do things like send deltas instead of absolute positions, and even things that depend on reliable order of transmission (which you can't rely on if it were UDP), in order to reduce bandwidth use.

</comment></comment></comment></comment></comment></comment></comment><comment><USER27> Note to self: don't start reading RFC's when you're supposed to go to bed to get up for work in time the next morning.

</comment><comment><USER28> Awesome! Should be interesting to see a slew of new collaborative tools and games coming out soon!

</comment><comment><USER29> Incredible news. This day couldn't come soon enough.

</comment><comment><USER30> I had no idea this was in the works (not been reading ietf lately). Wonderful post.</comment>


Reselling SSL certificates - <AUTHOR> Is it feasible to make decent money reselling ssl certificates on line without offering other services such as web hosting or VPS? Anyone willing to share their experiences? How do you start such as business? <comment><USER2> I recommend you to try Cheap SSL Shop Reseller Program [https://www.cheapsslshop.com/partner- program](https://www.cheapsslshop.com/partner-program). They are offering huge benefits to their reseller partner, and also you can buy SSL Certificate for your website at the lowest price.

</comment><comment><USER3> Sorry, reselling? How does this work, exactly? Would you find an upstream CA that is trusted, implement automation around their API, and sell certs?

Why would I pay you instead of just using the upstream vendor?

Why would I go to the trouble of dealing with you instead of a conventional provider like GoDaddy or Verisign?

What about Let's Encrypt?

</comment><comment> tony-allan Ditto for @jackfraser's comment.

In the Let's Encrypt era who is going to spend money on a certificate?

<comment><AUTHOR> Many businesses can't use Let's Encrypt for various reasons. I am not talking about certs just for someone's personal blog. I don't think Let's Encrypt can provide equivalent functionality to an EV SSL cert, for example.

</comment></comment><comment><USER4> find vendor, sign up for reseller account, grab api keys, churn our ssl certs using favorite language, create front end to site, and sell. Maybe you'll get bought by Symantec, who knows -that's the sad and typical end for that dream

<comment><AUTHOR> Would not make me sad to get bought up (lol). My goal is to make money not sell certificates as a hobby. Do you have experience in this area? Care to share? I am just interested if reselling is economically viable at this time. There seems to be a glut of resellers on the Internet. I am interested in first hand experiences to better understand the market place before investing time in creating my own site.</comment></comment>


Building DIY LED strips for fun - <AUTHOR> https://a.wholelottanothing.org/2020/07/18/building-diy-led-strips-for-fun/ <comment><USER2> If you came here hoping for _good_ resources on how to set up and control LED strips, angry that the article linked was bad and devoid of any good details, here are some useful resources.

#1: AdaFruit loves you and has a guide: [https://learn.adafruit.com/adafruit- neopixel-uberguide](https://learn.adafruit.com/adafruit-neopixel-uberguide)

#2: Andreas Speiss has a phenomenal youtube channel that offers a lot of solid tips and tricks for new makers looking to avoid common pitfalls: [https://www.youtube.com/watch?v=IIl5nDjfkjY](https://www.youtube.com/watch?v=IIl5nDjfkjY)

#3: GreatScott! (another great youtuber) has a really fun article on what I'd label a very "intermediate" LED project to get a sense of how to put everything together to make a unique object that is not simply a matrix and a lot of software: [https://www.youtube.com/watch?v=tXfMg8y1Fs4](https://www.youtube.com/watch?v=tXfMg8y1Fs4)

Good luck, and one last tip: remember to be careful that your microcontroller may be fried by the voltage your LED strips needs. It may seem that there is an obvious solution to that which is, "Just use 2 power supplies" but with 3-wire LED strips group loops can exist and ruin your ability to control the strip. Don't despair, search for "buck converter board" and then look up how to tune it. You'll get a system efficient enough that you can drop 12v to 3.3v and it won't drain your battery or overhead your enclosure. Linear regulators are _not_ your friend, they're usually cheaper specialist tools for folks who care about radios.

<comment><USER3> As for voltage difference between controller and lights, you can sacrifice the first led and power it at 3.3v and power the remaining ones from a second power supply. The first led will be a little dimmer than he rest but this setup has been very stable in my tests.

<comment><USER4> How does that work? Do I understand correctly that you connect the first led to a esp32 (+3V, onewire, GND) and then connect +12V and GND to the second led?

I wonder why it wouldn't work if you connect +12V on the first led?

<comment><USER5> The LEDs in the article are WS2812B LEDs that operate at 5v rather than 12v. 5v is a slightly more "normal" LED voltage, 12v strips are usually going little tricks like have 3 or LEDs in series and using that to get the required 12v drop.

With the WS2812B you're issue is that they operate on 5v logic for communications. 3v logic from a chip can _just about_ communicate with 5v devices. But you can't send the signal very far before the voltage drop stops communication. The cheat here is to use a single WS2812B LED as logic voltage converter. You put a resistor in line so it's operating at ~4v, give it a 3v logic signal it can understand, and it'll then talk down stream using ~4v logic, which you can then pump into normal 5v LEDs.

You can find detail of this little trick on hackaday[1]. But it's specific to WS2812B type LEDs that are really microcontrollers that happen to also put out light, rather than traditional dumb LEDs that have no smarts.

[1] [https://hackaday.com/2017/01/20/cheating- at-5v-ws2812-contro...](https://hackaday.com/2017/01/20/cheating- at-5v-ws2812-control-to-use-a-3-3v-data-line/)

<comment><USER6> IME, you can use 3.3V logic with 5V WS2812B/SK6812 strips, no trouble.

Each LED reforms the signal before sending it to the next LED in the chain, so voltage dropping over distance shouldn't a huge issue for the logic line unless the strip is very far away from the controller.

And the datasheet almost agrees with my experience; the "high" voltage threshold is listed as 0.7×VDD, and 0.7×5=3.5V. That's a bit over 3.3V, but I haven't had any issues across several projects. Maybe it's because many USB supplies provide a little over 5V to account for droop? Maybe the datasheet is slightly pessimistic? Maybe 0.7 really means 2/3? Whatever the reason, it simplifies the wiring for small displays.

Here's my favorite reference for the single-wire protocol that these LEDs use, since everyone seems to be chiming in with one:

[https://wp.josh.com/2014/05/13/ws2812-neopixels-are-not- so-f...](https://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-finicky- once-you-get-to-know-them/)

<comment><USER2> I think maybe folks got the model number confused. There are strips where the entire signal is passed verbatim without being reformed to every package on the line, but everyone stopped using them because they're awful.

In my experience, slow microprocessors are WAY more tricky to deal with than a 3V3 logic voltage for these strips; and often lead to crazy hacks. I'd way rather just put a modestly powerful resistor or a buck converter in my project than deal with trashy old Atmel chips, given how absurdly cheap ESP32 and ARM M7 packages are.

</comment></comment></comment></comment></comment></comment><comment><USER7> This is a nice, interesting, useful article, but the title is garbage.

Step 1: Buy some WS2812B strips.

You're not building the strips. You're building the control infrastructure.

<comment><USER2> I believe the word you're searching for here is "clickbait."

Controlling LED strips is not a boring project and it's a wonderful entry into the hobby since it often works with very safe voltages and is happy with cheap components.

But this article is clickbait, and it's probably the most detail-free article imaginable on the subject.

<comment><USER8> > works with very safe voltage

True for constant voltage, resistor limited current ones only. With constant current LED drivers, the voltage is approx 3V per LED. So it adds nicely to unsafe levels, albeit DC.

Another note is the power supplies can be quite unsafe too - esp. the cheap off-brand ones.

<comment><USER2> Panels and strips using more than 24V are extremely rare, with 12V being common and 5V existing for the hobbyist crowd. I've never seen a 24V rig for hobbyist uses (although some Ikea strips run there).

You don't wire them in serial anyways. In general if you care about blocks of LEDs at all you don't wire them in serial.

</comment></comment></comment></comment><comment><USER9> LEDs get a lot of attention from people without any kind of training with electronics, but they aren't as simple as people think - LEDs consume _a lot of power_. If someone isn't careful and doesn't know what they are doing, it's very easy for them to create a fire hazard.

[https://hackaday.com/2018/01/29/the-engineering-case-for- fus...](https://hackaday.com/2018/01/29/the-engineering-case-for-fusing-your- led-strips/)

<comment><USER10> good to see that! I (physics grad) was eyed very skeptically by a crowd of CS and architecture (like in houses) people, when I started buying fuses and caring about fire-safety (all the people were much like: oh light, wow (whilst I was: power, hot)

</comment></comment><comment><USER11> This one on "self organizing LEDs" was fun and motivating:

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

Video: [https://youtu.be/Ueim2Ko8VWo](https://youtu.be/Ueim2Ko8VWo)

<comment><USER9> Pretty simple to do this honestly, it's been done many times before. There are phone apps that do this that have been around for a while. After all it's just assigning an x/y value to a position that a color was detected at.

</comment></comment><comment><USER12> That looks really slick. Nice job!

These sorts of projects can be a lot of fun. I did the same sort of things a couple of years ago on my deck.

I had a rpi and Arduino in the loop cause that's what I had lying around, the ESP solution sounds much simpler.

Then we moved a couple months later...

[https://imgur.com/gallery/E4lbU](https://imgur.com/gallery/E4lbU)

</comment><comment><USER13> Adafruit is an amazing source, their NeoPixel ecosystem is exceptional. They also offer an RGB NeoPixel strip variant with modules that ALSO have a dedicated "warm" or "cold" white LED module. This is great in case you want to actually use your LED's as non color LED's for some time.

</comment><comment><USER14> I found this to be a rabbit hole. e.g. Ideally you want 24V not the 12V most of the cheap stuff is. And then you really want one that has warm white LED instead of just RGB'ing the white.

...and pretty soon you're looking at real money

<comment><USER15> Why 24V? What does it improve?

<comment><USER8> Power is proportional to the voltage squared (P = V * V /R), so the power supplies need less current -- cheaper, more reliable - less heat, less voltage drop.

The same holds true for the power supply in NA vs most of the world (save Japan). 110V vs 230V - much less copper needed for conductors. motor windings, etc.

Flip note: the better option is using constant current drivers, for higher efficiency (they might have unsafe voltages, though)</comment></comment></comment>


Ruby IDE - <AUTHOR>

I am using codecademy to learn ruby and I am running into a problem where I can't advance to the next level because of a syntax error. The error is very nonspecific so I don't exactly know what component of my code contains an error. I would rather use an IDE  and a book to learn Ruby. Are there any recommended free integrated development environments? <comment><USER2> RubyMine is good, albeit glitchy on large projects.

</comment><comment><USER3> but my choice is IntelliJ IDEA with Ruby plug-in

[http://www.jetbrains.com/idea/features/ruby_rails.html](http://www.jetbrains.com/idea/features/ruby_rails.html)

</comment><comment><USER4> Sublime Text 2 or 3

</comment><comment><USER3> try aptana; [http://www.aptana.com/products/radrails](http://www.aptana.com/products/radrails)</comment>


Shannon Entropy and Information Gain explained through fun probability games - <AUTHOR> https://email@example.com/shannon-entropy-information-gain-and-picking-balls-from-buckets-5810d35d54b4 <comment><USER2> i think the classification of ice as "low entropy" and water vapour as "high entropy" is a little simplistic... ice in your refigerator on a hot summer day does not have "low entropy."

otherwise a really accesible tutorial on a difficult subject. easier to grasp entropy as a probabilistic/info theory concept, than physics.</comment>


Interfaces – The Most Important Software Engineering Concept - <AUTHOR> http://blog.robertelder.org/interfaces-most-important-software-engineering-concept/ <comment><USER2> When i think of interfaces, i recall being told to think about how and why a DVD works.

The DVD would have been manufactured by a factory somewhere in china, by a bunch of people who does not know you. And yet, the DVD fits perfectly, on a drive that you bought, probably manufactured in the United States, by people who does not know you, nor the DVD manufacturer.

The software to read the DVD is written by yet another set of people, in yet another country, all of whom would not have talked to any parties mentioned above. And yet, the DVD is read perfectly, with error correction to adjust for any minor scratches.

The DVD plays video and audio data, created by people (probably in hollywood) who also have not met any of the parties above. And yet, it reproduces the sound and audio completely correctly as the original directors/composers intended.

And all of this, costs less than 50c a piece, with a drive that could be bought for less than $30.

That is the power of interfaces.

<comment><USER3> Power of capitalism too.

</comment></comment><comment><USER4> I have been skeptical of the notion of "interface" lately.

First of all, there is comment from Erik Meijer who said something like "interface without laws is useless" (he was referring to "interface" as a concept in OOP languages, and by "laws" he meant some algebraic laws). Basically what he wanted to know was the algebra, not just interface.

And if you look at it from Curry-Howard correspondence perspective, where programs are proofs and types are theorems, then basically, since type is an interface, you could say that theorems are interfaces in mathematics. So there already is a very precise notion of what is interface.

On the other hand, I also kinda like the notion of DSL as an interface, as described in the recent article here on HN: [http://degoes.net/articles/modern-fp/](http://degoes.net/articles/modern-fp/)

What seems to be the main contention here - should the interface just use the names (akin to philosophical nominalism) and leave them open to interpretation or should it somehow encode the properties of things it describes (akin to philosophical realism)?

<comment><USER5> Indeed, this quickly becomes obvious after writing Haskell for awhile. Lawless typeclasses just seem clunky and get less reuse compared to their lawyer'd up brethren.

You also can get a very slight taste of this in C#, Java, etc as well where larger interfaces seem clunky and get less reuse than smaller interfaces. In C#, if an interface has some nice properties, typically the extension methods on these interfaces with allow for a combinational explosion of generic utility functions. So this might be one way to judge the "algebraicness" of interfaces. You see this a lot of the LINQ collections libraries, which seem to have put some thought into laws.

Unfortunately in these languages you can only go so far due to the lack of higher kinded polymorphism (T<A> types vs just Type<A> types).

<comment><USER6> One thing that baffles me a little bit about LINQ in .NET is that it's got a dual identity.

On one hand you've got the IEnumerable<T> interface, which supports the fluent syntax and is extremely easy to riff on with extension methods. (The "fluent syntax" itself is just a bunch of extension methods.)

On the other hand you've got the mechanisms you need to support the query syntax, which behave more like duck typing. If you implement a couple methods with certain names and signatures, not all of which are formalized by an interface, then the compiler will let you use query syntax with objects of that type. It also turns out that the stuff you need to implement are roughly the bind and return operations from a monad. . . but not exactly. In particular, the element they use in place of bind is a bit more complicated, and not in a way that adds any real expressive power. It just makes the signature a bit more irritating to support.

In other news, re: lack of higher kinded polymorphism - That's something that the maintainers of F# have forcefully resisted adding to the language. The argument, which I've yet to take the time to look into deeply, is that typeclasses interact poorly with formal interfaces so you shouldn't allow a language to have both. I'm a bit skepty on that one, though, since I'd assume there would be wailing coming from the Scala community if it were really that bad.

<comment><USER7> Im guessing F# also may want to limit constructs which cannot interop with C# . Not sure if Scala's HKTs are usable from Java

<comment><USER6> Maybe, but I'm inclined to guess that it could probably be made workable without much more pain than what it takes to interact with F#'s curried functions from C#.

Usually the recommended approach for making F# code usable from C# is to add an object-oriented wrapper layer to the F# library. That ends up being much, much easier in practice than trying to deal with F# code on its own terms from C#.

<comment><USER8> "... add an object-oriented wrapper layer to the F# library."

Do you have any sample code that serves as an example? It would be immensely helpful. Thanks.

</comment></comment></comment></comment></comment></comment><comment><USER9> Hi, I'm the author. I submitted this yesterday, but I didn't even get 1 upvote, so I'm glad to see it here today as I think it is a very important topic for discussion. Feedback from the submission on Reddit has suggested that this article is too long which I now acknowledge. I'd be happy to hear any critiques you have.

<comment><USER10> Good article. Interfaces and modularity are core concepts, worthy of much attention. Especially questions like how to do functional decomposition, finding the right abstractions, and good interface design.

I'll chew on your statements about the success of Python. Though my first love was LISP, I'm now far more comfortable leaning on static typing and composition.

\---

The best book on software design I've ever read was written by two economists.

Design Rules: The Power of Modularity

[http://www.amazon.com/Design-Rules-Vol-Power- Modularity/dp/0...](http://www.amazon.com/Design-Rules-Vol-Power- Modularity/dp/0262024667)

This book didn't change how I program so much as changed how I think. Like the difference between making and criticizing art. Whereas SICP gave me new mental models, Design Rules gave me new philosophies. More like Design of Everyday Things did.

<comment><USER11> Thanks for the link. Let me repay you with one:

[http://www.amazon.com/Design-Essays-Computer- Scientist/dp/02...](http://www.amazon.com/Design-Essays-Computer- Scientist/dp/0201362988/ref=sr_1_1?s=books&ie=UTF8&qid=1456549011&sr=1-1&keywords=design+of+design+brooks)

</comment></comment></comment><comment><USER12> Awesome write up.

While I agree that dynamically typed languages -- by their loosely defined API requirements -- are more difficult to scale, it's not difficult to add type checking and/or provide a well structured public API where necessary.

I think statically typed languages go too far in the other direction. Tyr type and API definitions are too strict leading in a ton of unnecessary effort (ie boilerplate), increased surface area for potential bugs, and overly restrictive limits that require 'creative' workarounds to effectively write code.

I think there's a 'happy medium' to be found where type checks are required for certain inputs and a clearly defined API can be established without the need for private/internal/public syntax artifacts.

I've been playing with this a bit in JS lately. Using model definitions to specify the structure and enforce validation. As well as defining facades with the ES6 module import/export syntax to define public APIs. Finer grained control (ie private vs internal) can be defined using closures that provide internal interactions while hiding the private implementation details.

<comment><USER13> > I think statically typed languages go too far in the other direction. Tyr > type and API definitions are too strict leading in a ton of unnecessary > effort (ie boilerplate), increased surface area for potential bugs, and > overly restrictive limits that require 'creative' workarounds to effectively > write code.

Given this description of statically typed languages, I'm guessing you haven't tried OCaml or Haskell.

<comment><USER12> I was specifically referring to statically typed OOP.

You're right, I haven't tried OCaml or Haskell so I can't make a qualitative judgement on how easy/hard type coercion is in either.

<comment><USER14> The need for type coercion is a very good indicator of a bad design. Haskell just forces you to deal with it _right now_ instead of never.

</comment></comment></comment></comment><comment><USER15> Hi Robert,

I'm not sure what you'd like to see discussed from the article. To me, it read like an overview of something I already knew.

It's one of those things where if you know it, you don't need to hear about it. If you don't know it, hearing about it won't make sense anyway.

I can see this being part of a course for beginners but frankly - people will figure out what interfaces are for and what leads to problems by writing enough code and/or seeing how good libraries/frameworks tackle the problems they had difficulty with and learn from that.

My 2 cents.

<comment><USER9> I suppose that is re-assuring to hear. I expected that a few of the points might be controversial because I haven't heard others explicitly state them. I wasn't sure if they were just my opinion or something that everyone else thinks too.

</comment></comment><comment><USER16> Polymorphism is very powerful, because it lets old code call new code.

But abstraction layers have costs. (Explicitly declared) interfaces are a cost (time to introduce into the system, complexity, lines of code, impedes refactoring).

Therefore, don't use interfaces (i.e. introduce abstraction layers) until needed (cost is justified).

By the way, if you manage to come up with a layer of abstraction that doesn't have as much explicit cost, it's a cheaper layer of abstraction. So dynamic languages' "duck typing" feature allows interfaces to emerge gradually, without explicit code to introduce them. Arguably, but IMO, that's a better approach.

I disagree with the article's definition of a leaky interface: "A Leaky interface exists when the interface is prone to being ignored during any communication between the system and the environment."

A leaky interface is an interface that has non-obvious, non-declared behaviors, and the code _has_ to rely on those behaviors to deliver value/functionality.

It can be something as simple as an inconsistent implementation that leaks an underlying implementation detail. It doesn't mean that the interface is prone to be ignored. In fact, it can be used quite a lot--just in slightly different ways.

</comment><comment><USER17> The most important software engineering concept is _indirection_. Interfaces are an expression of this concept.

[p.s. edit: structural indirection, to be precise.]

</comment><comment><USER18> This article would have helped tremendously back when I was struggling to wrap my head around the purpose of interfaces. Great visualizations and certainly a very unique but also a very logical way of looking at interfaces. Great article.

</comment><comment><USER19> I think _coupling_ and _cohesion_ stand out as fundamental software design principles. (I wouldn't say it's "interfaces" as I can imagine interfaces with tight coupling or low cohesion.)

<comment><USER20> "Coupling" I understand, as sort of opposed to "modularity". What do you mean by "cohesion" in this context?

<comment><USER21> The ideal is low coupling and high cohesion. That's supposed to mean your system is composed of parts that can be understood separately. Low coupling means that the innards of each module are isolated from the others. High cohesion means that each module presents a clear and distinct purpose.

Thinking in terms of interfaces (in the general sense) helps towards this ideal. If an interface is cluttered with dozens of functions, it's a sign that it could be refactored into more cohesive units.

<comment><USER22> > Low coupling means that the innards of each module are isolated from the > others.

Isn't coupling just the complexity of the dependency graph? I would say depending on an interface is coupling as well. In my experience complex static typesystems encourage highly abstracted interfaces which are sometimes even more cancerous dependencies (that doesn't apply for really basic and practical things like Iterables which come with the language).

For this reason, IMHO an even better ideal than coding against interfaces is relying on concrete datatypes that are just a given, like structures and arrays of integers.

<comment><USER21> Maybe my understanding is idiosyncratic, but I see low coupling as most essentially meaning that the modules interact at small and well-defined boundaries, which gives you flexibility when you want to do things with the units like test them, replace them, etc.

Depending on an interface can be a kind of coupling, sure, but I think it depends. I think abstract interfaces, or at least statically typed data types, can be great for understandable systems...

In Haskell, there's work being done on allowing some kind of module signature, so that you can have several implementations of the same API be compatible with the same source code. I'm interested to see how that will play out.

You could see a Java-style interface as a specific global name given to a set of method signatures. Using that name incurs a dependency on the library that defines it. Sometimes it makes sense to redefine the interface in your own library, and then you can use adapters to make other implementations compatible—but this is all kind of boilerplate stuff that you wouldn't need if Java was more flexible with interfaces...

<comment><USER22> Thanks. I think I confused low coupling with loose coupling.

Where do I find information about the Haskell module thing?

<comment><USER21> I'm not totally clear about the concept either. :)

It's called Backpack.

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> Opinion: If interfaces is the most important software engineering concept, then the most important interface is the one used to control I/O. Different approaches. Fun to think about.

<comment><USER24> Programmer interfaces surely will look different from interfaces consumed y the general public.

</comment></comment><comment><USER25> As far as the S/W engineering take away -- simply put, an interface _allows two disparate pieces of code_ to work together. One compiled piece of code, for example, can interact with another piece of code, which could be written and compiled years after the initial.

</comment><comment><USER26> Thanks for posting!</comment>