Who eats who in open source - <AUTHOR> http://www.platformonomics.com/2019/11/dining-preferences-of-the-cloud-and-open-source-who-eats-who/ <comment><USER2> [https://webcache.googleusercontent.com/search?q=cache:www.pl...](https://webcache.googleusercontent.com/search?q=cache:www.platformonomics.com/2019/11/dining- preferences-of-the-cloud-and-open-source-who-eats-who/)

<comment><USER3> Also [https://web.archive.org/web/20191123091956/http://www.platfo...](https://web.archive.org/web/20191123091956/http://www.platformonomics.com/2019/11/dining- preferences-of-the-cloud-and-open-source-who-eats-who/)

</comment></comment><comment><USER4> The root of the issue is that licensing costs, the only costs that open source is guaranteed to reduce, can be a small percentage of operational costs in practice. If open source makes little effort to optimize the vast majority of other operational costs at scale, and this is largely the case in my experience, it can literally be economically uncompetitive with a closed source product that does optimize those other operational costs even if it has a license overhead or creates vendor lock-in.

I see this dynamic more and more, companies have figured this out. Sure, buyers _prefer_ open source infrastructure without vendor lock-in, but they don't prefer it enough to spend 2-10x the OpEx, which is often the case in these discussions. The poor optimization of operational costs (except for license fees) is a critical weakness in open source, and it is increasingly being attacked successfully. Open source is a nice idea that most companies love, but they aren't going to spend mountains of extra money in operational costs to get it.

<comment><USER5> > If open source makes little effort to optimize the vast majority of other > operational costs at scale, and this is largely the case in my experience

I feel the opposite is true. There are many open source projects that are at least on par with their proprietary counterparts. Postgres is competitive with every SQL DB I've heard of except maybe in some niche use-cases. Redis is open source and incredibly performant. Same with Kafka (if you use it well). Linux sure runs better than Windows in my experience.

There is also a whole class of open-source libraries like React that have taken over. I can't even think of a proprietary frontend framework.

What software are you thinking of when you make these claims?

<comment><USER4> There are two major dimensions to the operational cost weaknesses of open source. Neither is guaranteed to be meaningfully exploited by proprietary software in any particular case. Since we are talking about operational costs, this is almost entirely about data infrastructure software, not things like React.

First, there is a vast amount of supported operational tooling that is simply missing from open source ecosystems. PostgreSQL, which I still use extensively, is a perfect example of this. The code bases around this tooling are _several times the size of the product they support_ , and it isn't the kind of code that most developers aspire to write despite its high value to the customer. Oracle and SQL Server have architectures that are as obsolete as PostgreSQL, they don't compete on the basis of being modern, efficient designs but on the basis of having dramatically better operational tooling. Cloud RDBMS attack a different aspect of this.

Second, is the operational infrastructure costs i.e. how much hardware is required to run a given workload. This is the larger threat to open source, particularly as the data intensity of business increases. PostgreSQL, Kafka, and Redis (I've used all three operationally) have several times the hardware requirements to deliver a workload in practice than is required with a state- of-the-art architecture. This isn't hypothetical, I've designed engines that replaced them when warranted. An 80% reduction in infrastructure cost is attractive when you are already spending tens or hundreds of millions of dollars per year on it. Some popular proprietary software is just as inefficient but that isn't guaranteed to remain the case (and I've replaced those systems too). Designing efficient software architecture isn't magic (see: ScyllaDB), you simply see very few examples of it in open source because it isn't a priority (see: use of managed languages for data infrastructure despite this being a known limitation).

The reality is that I can guarantee data intensive businesses who make competent use of open source that I can reduce their infrastructure costs by 4x with ease. You can bury a _massive_ amount licensing and engineering costs in those savings.

Also, some companies are explicitly looking at this as a major "green" initiative. The wasteful infrastructure footprint to deliver a workload with open source is viewed as _environmentally unfriendly_ , and this is pushing companies to consider proprietary solutions even if they are not sensitive to operational costs. That isn't a conversation open source is currently prepared to have but it is coming.

<comment><USER6> > _I can guarantee data intensive businesses who make competent use of open > source that I can reduce their infrastructure costs by 4x with ease_

I am interested in your perspective and experiences.

> _Oracle and SQL Server have architectures that are as obsolete as > PostgreSQL, they don 't compete on the basis of being modern, efficient > designs but on the basis of having dramatically better operational tooling._

What dramatically better tooling does SQL Server has?

> _PostgreSQL, Kafka, and Redis (I 've used all three operationally) have > several times the hardware requirements to deliver a workload in practice > than is required with a state-of-the-art architecture._

What should I think of when you talk about state-of-the-art architecture? And what would replace aforementioned tools?

What should the open source offerings do to win you over?

<comment><USER7> > What dramatically better tooling does SQL Server has?

I don't know about Oracle but SQL Server Data Tools (SSDT) and SQL Server Management Studio (SSMS) are vastly better than anything I've seen for open source databases.

SSMS is just a really good visual client with an excellent table/view designer, diagram builder and query builder with GUI management features that let you manage virtually every facet of your server and databases.

SSDT lets you treat your SQL schema, database settings and deployments like code, with versioning. All of your table schemas, views, functions, procedures, settings, seed data, etc. are stored as text in your git repo. When you're creating, it has excellent intellisense/autocomplete. You can use it to diff your schema and data against a given SQL Server database to generate migration scripts. You can also do data comparisons between your seed data and your server and you can diff schemas and data between 2 different servers without even having created an SSDT schema. Another very useful feature is that you can reverse engineer a SQL Server database that was already created in order to start your SSDT project. It also has visual designers for all of the aforementioned things. It used to be a separate tool, but now it's part of the free Visual Studio community edition. Both tools are free, as are various editions of SQL Server.

Also, SQL Server itself has had features for a long time that PG is just starting to get such as real Stored Procedures, ones that can return multiple heterogeneous result-sets, run transactions and do control of flow with SQL- like statements (IF/THEN, DO, WHILE, etc.) It also has table variables, which are like in-memory tables, that you can use as a faster type of temp table for certain sets of data.

Since I moved off of Windows for my workstations, I've been running SQL Server in Docker on Linux for the past few months - it's rock solid.

<comment><USER6> Afaik, those things are available in DBeaver [0] and MySQL Workbench [1] as well.

@jandrewrogers also mentioned a 4-fold performance increase by switching to proprietary solutions from pgsql. I am still wondering what those solutions might be...

\---

0\. [https://dbeaver.io/](https://dbeaver.io/)

1\. [https://www.mysql.com/products/workbench/](https://www.mysql.com/products/workbench/)

<comment><USER7> I've used both and I can assure you that both the products you mention fail to approach the utility and more importantly, the quality of either SSMS or SSDT.

Have you tried the SQL Server based products at all?

<comment><USER6> Not that much, so I might have to take a better look then. :)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> > The unexpected and asymmetric competition from the clouds confounds open > source companies, who must confront the fact the competitive advantage of > knowing their software better than anyone else isn't the insurmountable moat > they had hoped. It is never fun to wake up and discover your product is now > just a feature of a broader offering, but this is what is happening with > software. Claiming open source is eating the cloud is like coffee bean > farmers claiming they're eating Starbucks: it willfully (or just out of > delusion) ignores the vast majority of what the customer is buying.

As always, 'commoditize your complement': [https://www.gwern.net/Complement](https://www.gwern.net/Complement)

<comment><USER9> > (in Robert Metcalfe's infamous expression, cross-platform web browsers & the > Internet would reduce Windows to a "poorly debugged set of device drivers")

Compare the number of platforms nowadays which (to varying extents) treat Linux as a free set of buggy device drivers.

</comment></comment><comment> awinter-py Missing piece of the argument -- the AGPL service provider clause (that didn't make it into GPL v3).

The author is talking about physical infrastructure as adding value, and they're right, but there's a middle layer that cloud vendors add to their managed tools -- things like auto backup, upgrade and resize for mysql.

These are enhancements to open source DBs etc that cloud vendors keep in-house as secret sauce. This makes the stock version of open source software hard to operate in the way AMZN / GOOG operate it, while still allowing AMZN / GOOG to benefit from community effort without giving much back.

<comment><USER10> With AGPL you still get eaten, just in a different way. The cloud providers will rewrite your software from scratch while maintaining protocol/API compatibility.

<comment><USER11> That's just simple competition that we've always had. Microsoft working on a competitor to your product was the huge fear of the 90s. Cloud providers competing with your own source code is a new phemonema.

The original thesis would be that brand loyalty would be strong enough to prevent forking like this. "You don't want that third-rate version, get the real thing from the original authors!". It appears that the customer base assumes quality is roughly equal considering its mostly the same code.

<comment><USER12> In many businesses, getting permission to buy/license from a new supplier is way more effort than just selecting another option at the cloud provider you're already set up with.

</comment></comment></comment></comment><comment><USER13> I'll play the 'open source eating cloud' argument because what merit it has, isn't addressed in this piece.

How do computers earn people money? Speaking in 2019 that's obvious. Cloud providers earn the most.

There used to be other ways people got rich off computers. But all those businesses imploded against the awesome might of '0 marginal cost', 'only good solutions survive', world of open source.

Open source has 'removed more profits'/'provided more value' then the cloud. Cloud is simply the high profit game until competition kicks in, open source tools become the norm, and only the value of the virtual machine is sold at 1% the current price.

</comment><comment><USER14> I work at Pivotal and disagree with a fair amount of the characterisation thereof, but my bias is mostly informed by actually working there for the last 6 years. Let's look at the heart of the argument instead.

> _If you squint, open source could be seen as a very generous charitable > donation to some of the largest and wealthiest corporations on the planet._

Broadly: yes. Except backwards.

FLOSS can be seen as a public good -- it is non-excludable and non-rivalrous. Excludability is the property that someone can be prevented from using the good (eg, requiring payment to consume a can of soft-drink). Rivalrousness is the property that utility from consumption of a good by one person diminishes utility for another person (if I drink the soft-drink, you get less of it).

Economics predicts that public goods will be underprovided by a pure market. This is because of the free rider problem. Since I can't be excluded from the good, I can consume it without giving something up for it. Since it's non- rivalrous, there's no meaningful back pressure that eventually raises the cost of consumption to an unacceptable level.

A strictly rational agent will _always_ free ride on a public good. And most of the time, most rational agents will not provide a public good, because the cost of paying for everyone else's consumption exceeds the benefits of their own consumption.

This hints at one of the ways that public goods get provided: through subsidy by benefactors, who will capture some but not all of the value created by their benefaction. A wealthy person may so enjoy seeing the opera that they will donate heavily to the local opera house. They don't capture the full benefit -- other folks can watch the same shows -- but they capture _enough_ value that they are satisfied with the arrangement. They might also get value from other factors, such as social approval.

The cloud providers do _not_ sell public goods. Their services are fully excludable. If you refuse to pay, service will end. They _are_ rivalrous at the limit, though, putting them into the category of club goods. These are much more likely to be provisioned in a pure market, since the benefits and costs fall more "correctly" on those who obtain or bear them.

<comment><USER15> >>Economics predicts that public goods will be underprovided by a pure market. This is because of the free rider problem. Since I can't be excluded from the good, I can consume it without giving something up for it. Since it's non- rivalrous, there's no meaningful back pressure that eventually raises the cost of consumption to an unacceptable level.

>>A strictly rational agent will always free ride on a public good. And most of the time, most rational agents will not provide a public good, because the cost of paying for everyone else's consumption exceeds the benefits of their own consumption.

Thus the reason Free (As in Freedom) software advocates promote the use of Copy-Left Licensing, and why non-copyleft (like MIT, BSD, and others) are slowly eroding "open source" to less fully formed software and more just the tooling, libraries and dev environments used to create software

<comment><USER16> Being an old dog at tech, given how the community has been anti-GPL licensing, pushing for non-copyleft licenses, I predict that in a couple of years we will be back to the PD, Shareware, Demoware, Beerware, PostcardWare, whatever were all the way to share code during the 80 and 90's on home computers.

And it is already too late to change course back to GPL being widespread.

Every year there is a new project replacing GCC with LLVM, on Android the kernel is the only major GPL piece still standing (with Fuchsia on the horizon), on embedded there is a rise of non-copyleft OSes (including Zephyr, a Linux Foundation project), and so on.

<comment><USER15> <sarcasm> Dont worry Microsoft Loves Linux and Microsoft Loves Open Source. I am sure they will be the protectors we need </sarcasm>

</comment></comment></comment></comment><comment><USER17> I'm skeptical about _" multi cloud eats cloud"_. If you're going to be boxed into using a lowest common denominator of services, cloud has less value. You might as well jump straight to hosted bare metal. The skill sets needed aren't much different than multi-cloud, and it's much cheaper.

</comment><comment><USER18> The cloud is eating business relying on licensing. This is relevant for both open and closed licenses. By the way I have wrote a post on that when the MongoDB debate was raging: [https://medium.com/hackernoon/aws-and-mongo-and- open-source-...](https://medium.com/hackernoon/aws-and-mongo-and-open-source- efcdcfb00514). The way for Open Source to survive is to make it attractive for cloud providers.

<comment><USER19> How does one make their project attractive to cloud providers? For the sake of discussion; an infrastructure project like a job scheduler or some such?

<comment><USER18> I was more thinking about making the licensing attractive to cloud providers. The idea is that cloud providers are the dominant players - so for Open Source to survive it needs to be adopted by them. But yeah - I don't know how to do that. Licensing is not a core of their proposal, open sourcing their software does not impact their revenue directly - but might indirectly by letting other cloud providers compete with them using their own code.

</comment></comment></comment><comment><USER20> I wonder if advancement in orchestrator will shift the balance. There is a lot of effort into putting human knowledge into software, so that it can react to unexpected situation and self heal. K8s operators to be specific.

If this software works well enough, what would be the competitive advantage of AWS?

<comment><USER21> K8s is not an advancement in orchestration and is very much on the AWS side in this, deeply integrating with proprietary cloud services that do their own operations and infrastructure, not even considering open sourcing those services and their supporting infrastructure nor working towards alternatives to replace them. It's just that the same thing that makes AWS piles of money is the same thing the company behind k8s is after, so they are definitely not going to advance k8s in a way that commoditizes AWS. Not that they are even capable of doing so.

</comment></comment><comment><USER22> > Pivotal got eaten by "Dockernetes" aka containers (ironically because Google > was pissed off about Hadoop, but that is another story)

Would anyone care to give a brief summary? It's the first I've heard of this.

<comment><USER17> I believe it's just saying that Google was disappointed that their MapReduce research didn't give them any market presence or power. Hadoop took the concepts and ran with it, with no direct benefit to Google. Pivotal benefited a lot with their commerical distro of Hadoop.

Google didn't make the same mistake with K8S and it killed Pivotal's PCF.

<comment><USER14> Hadoop looked to be a big part of Pivotal's overall strategy early on but didn't pan out. Labs and Cloud Foundry have contributed the lion's share of revenue for most of Pivotal's life, though data products like Greenplum, Gemfire and RabbitMQ have also contributed a lot.

Kubernetes was never really about Pivotal in any universe I can think of. It was about AWS.

Disclosure: I work at Pivotal.

</comment></comment></comment><comment><USER23> People rarely mention in these debates that Bitcoin is open source, along with essentially all other cryptocurrencies. Indeed, the cryptocurrency business model could hardly exist without open source. It isn't the same community at all as Linux / Postgres / etc, but it certainly should be considered a great success for open source.

</comment><comment><USER24> This conflates open source with companies using open source as a competitive advantage. For the latter, yes, cloud is eating their cake.

</comment><comment><USER25> Open source thought they could sell consulting and hosting services to fatigued devs, if they fatigued them enough. All those single project focuses left the door wide open for multi-clouds to "just add glue" between disparate open source projects and actually aim to be easy.

We now await to see if compute will become a commodity or just priced that way to prevent it becoming so. Is any challenger bold enough to bite off more of the pie than they can chew?

</comment><comment><USER26> This analysis seems correct if OSS = OSS ISVs.

</comment><comment><USER27> I was hoping this article was going to be more like "who makes enough money to eat working on Open Source Software?"

<comment><USER28> Me too. I don't think there are many people making enough money to eat working on Open Source software. If you see GitHub, the largest most active projects are funded by Mega Corps like Micro Face Goog.

I wonder how many companies are successful with open source but paid licence for commercial use.

</comment></comment><comment><USER29> "whom"... Who eats whom...

</comment><comment><USER30> Who eats closed source software?

<comment><USER31> The cloud, too.

Think of Office365, SAP Cloud Platform. It's benefical for a closed source vendor to switch to a service model, collect monthly recurrent fees and get free ultimate leverage against the customer.

</comment></comment><comment><USER32> Right now your webserver is eating your post

</comment><comment><USER33> [https://web.archive.org/web/20191123091956/http://www.platfo...](https://web.archive.org/web/20191123091956/http://www.platformonomics.com/2019/11/dining- preferences-of-the-cloud-and-open-source-who-eats-who/)

<comment><USER34> That one's pretty clearly past the tipping point in usage, so I think we can leave it above.

<comment><USER33> Agreed, sorry. I wanted to add the archive link but felt like being snarky for some reason</comment></comment></comment>


CodeHS Wants To Teach Every American High Schooler How To Code - <AUTHOR> http://techcrunch.com/2012/11/26/codehs/ <comment><USER2> I suppose its an enviable effort but I wonder if its out of touch with the true state of education. Insisting kids learn to code in the current educational climate should not be a priority in most American schools. You see most of us have blinders on whether we know it or not 1) we magnify the importance of programming and technology because we ourselves make a living from it 2) many of us are in a socio-economic bracket where we are not exposed to the average highschool environment (I'm not saying we are hoity-toity but if you live in SV or make more than 60k/yr you probably dont have a true grasp on it - consider yourself lucky)

Kids first need to learn logic, math and english at a certain baseline... every good programmer is probably quite good at all 3 of those foundational things - those skills are the enablers for unlocking programming in a basic capacity. The problem is that the average highschooler is struggling immensely to get to that basic baseline at the time of graduation. Additionally with the very real budget and over-capacity problems, when new core curriculum is proposed the first predicament is what is going to have to get axed in its place. Somebody is going to have to pick something to say goodbye to that is actually truly core learning. Yes Im sure we all have our favorites of what we think is non-essential core curriclulum but in reality our opinions don't count and to be a realist they probably shouldn't - only the opinions of the district, administrators, teachers and parents count in any real way. Additionally, when you put programming up against any part of the core curriculum (geometry, algebra, literature, etc etc) - most will axe programming - I probably would as well.

<comment><USER3> >we magnify the importance of programming and technology because we ourselves make a living from it

I'm not so sure about this. Programming is one of the only skills I can think of that free you from having to find a "job". If the market is crap you can make something yourself. You don't have that option if you're, say, a SAP administrator because it takes a fairly large organization to have that.

<comment><USER4> >Programming is one of the only skills I can think of that free you from having to find a "job".

You're ignoring carpentry, sewing, knitting, smithing, machining, writing, cooking and a host of other non-STEM related skills.

I'm the only member of my immediate family that doesn't work in one of the "trades", and oddly enough I'm the only one that doesn't work for myself.

<comment><USER3> You have a point but several of your examples will allow the person to not have to find a job at a big company but they either have a big up front cost, a very low ceiling on potential earnings or both. Programming has neither and _that's_ what I was talking about. Sorry if I didn't express that clearly.

<comment><USER5> Almost everyone I know in the trades makes more money than the people I know in software.

I'm talking about really skilled plumbers, electricians, contractors, etc. Not high-school dropouts hanging drywall so they can buy their next hit of meth or case of beer.

<comment><USER4> I personally don't see a huge difference between the traditional skilled trades and being a software developer.

One of my brothers, who is a carpenter, cares as much about wood (species, age, drying method, etc) and his tools as I care about computers and my tools. We both spend way more time than "normal people" caring about the things that matter to our craft.

Disclaimer: I'm a big fan of the software craftsmanship thing. I may be an idiot.

</comment></comment></comment></comment></comment></comment><comment><USER6> With stuff like this, we degrade the quality of our profession over time.

Dont get me wrong, i like the idea and its good to have more people who understand programming. On the other hand it will also yield alot of low quality programmers, because the higher quality learn to code out of their own interest anyway. So in the end i am not convinced that its a good thing to have even more Rails programmers working for 15$ an hour.

Yes programming is a valuable skill, but i dont agree it needs to be more of a universal skill to people like carpentry or plumbering for example. The people that need it for their job will have to learn it, the people that are passionate about it will learn it, all others will probably never learn it because it requires a ton of work and they end up on the low end, and we really have enough of bad programmers.

<comment><USER7> > On the other hand it will also yield alot of low quality programmers, > because the higher quality learn to code out of their own interest anyway. > So in the end i am not convinced that its a good thing to have even more > Rails programmers working for 15$ an hour.

Very few people would argue that by teaching everyone to write, the job of being a professional writer is degraded. What we are saying is that coding is a form of literacy now. We are not advocating that everyone become a professional programmer; and similarly, teaching people to write is not advocating that everyone become a professional writer.

In many jobs knowledge of computational thinking will be important.

<comment><USER8> Computational thinking != programming.

I think the objective you're aiming towards would be better served by attempting to raise the bar on mathematical thinking and reasoning. Programming can have a part to play in that, but I'd argue that you'd get much more benefit for equal cost simply by performing studies on which forms of mathematical teaching actually taught students mathematics.

<comment><AUTHOR> Programming can be really helpful for teaching mathematical thinking and reasoning. It's a fun way to approach the subject from a different angle.

Many kids _hate_ math but might enjoy programming. It's important to engage students. They'll learn a lot more if they enjoy it.

<comment><USER8> Many kids also hate programming. It's _boring_ , sitting there in front of a screen all the time, typing in incomprehensible text that the computer throws back in your face because you missed a comma here or a semicolon there. There's a huge groupthink bias here in favor of programming as the solution to all problems here at Hacker News because we're all programmers and we tend to frame problems and solutions in a way that makes them amenable to solving via programming.

That's why I suggested that we need to figure out what sort of math education works, rather than suggesting a particular alternative. There is research showing what kinds of mathematical education is effective. I posit that we would be much better off asking for those results to be put into practice everywhere, rather than foisting yet another folklore-based curriculum onto our already overburdened teachers.

</comment></comment></comment></comment></comment><comment><USER9> After reading just the title, I was worried. After reading the article, I'm much more optimistic. Figuring out how to scale up tutoring and "why doesn't this code work" might actually make a difference.

I'm a high school computer science teacher. I've personally taught (face-to- face) the basics of programming to more than 2,000 students over the past fifteen years. Quite a few of those have been "low income".

Letting kids struggle and being able to support them when they get stuck is key to deep learning.

Kudos, and ping me if I can be of help.

<comment><AUTHOR> Thanks! We totally agree, and I'd love to talk. Shoot me an email at firstname.lastname@example.com

</comment></comment><comment><USER10> These stories appear about every month or so, right? I think it's apparent that a certain segment of society would love programmers to be the new factory-workers.

<comment><USER11> It's never going to happen because it's lost on them just how hard programming is. I can say with a straight face, & not a hint of cynicism that programming is second only to medecine, as a wide-practiced* occupation, in terms of the cognitive effort it asks of its practitioners.

<comment><USER12> I am all for making good programming instruction available to anyone who wants it. I hate to think lack of access to knowledge and mentors is holding potentially brilliant programmers back. But I'm also sure this isn't going to turn programming into unskilled labor.

"… most people can't learn to program: between 30% and 60% of every university computer science department's intake fail the first programming course."

And that's just to pass a class, and these are people who chose to go to school and major in computer science. And that says little about future success writing real-world code, which some people can't seem to pull off even after getting a degree.

As far as I can tell, programming is part aptitude and part learned skill, and not everyone has any real aptitude for it. This doesn't mean they're stupid: they may be absolutely brilliant at something else. That thing just happens not to be programming.

But I see no harm in letting anyone who wants to learn to program try, and in giving them as much support as possible. At worst it's another failed experiment, but if the upside is inspiring a few more people to become great at this I'm all for it.

<comment><USER7> > "… most people can't learn to program: between 30% and 60% of every > university computer science department's intake fail the first programming > course."

You say "most people can't learn to program" because 30-60% fail a university computer science class. But can you really jump to that conclusion?

There are many other more feasible explanations. What if the class was taught poorly? What is students had no interest? What if the students never put in any time? What if the class wasn't fun? What if the students saw no potential gain from learning this material? What if there are too many barriers to even getting started and writing your first program?

I can tell you that we have a 5 year old, 9-10 year olds, high schoolers, and 80 year old grandpas on CodeHS, and _all_ of them are able to learn. This speaks to the importance of introducing concepts in the right way, and making it fun and rewarding.

<comment><USER12> A big part of me hopes I'm wrong about this. Even if it's not what everyone wants to do for a job, being able to code is incredibly empowering. I was lucky to appreciate that early on.

I'm an odd case: I was a _really_ stubborn kid, and I decided to learn to program while I was in grade school, so I picked up a language manual and dove in. I was obviously more than interested; I was deeply obsessed, and I happened to be good at plowing through ridiculously dry reading and fighting with something until I made it work. My experiences aren't typical, and I don't have a good handle on what _is_ typical. (I also learned BASIC, then assembly for two CPUs, then C, then some higher level languages. My path is undeniably strange.)

I'd think most people choosing to study computer science would be interested in it, but I also know I met people in college who had no idea what they were getting themselves into, and they didn't exactly meet a kind introduction. There has to be a better way to teach this than what I saw.

It'd be really interesting to see how many students who go through your program go on to pick up a few programming languages or who can ultimately understand deeper computer science topics. Basically, what impact does this have on the world?

<comment><USER7> > Basically, what impact does this have on the world?

That is a big question, but I think the answer is that this helps teach critical thinking, and prepare digital citizens. I think another think allowed by teaching programming is helping students be able to create ideas they have. I wrote more about this here: [http://blog.codehs.com/post/33113754964/the- factors-of-knowl...](http://blog.codehs.com/post/33113754964/the-factors-of- knowledge)

</comment></comment></comment></comment></comment></comment><comment> k-mcgrady I've never liked the movement to get all kids to learn how to code. It's not an essential skill like Maths or English (or the language of your country). If we are doing our jobs right the only people who should ever need to write code are the ones who want to. Schools should offer computer classes for students who want to learn, obviously, but insisting everyone learn more than the basics (which kids growing up these days tend to know anyway) is a waste of time.

<comment><USER13> Indeed. Why should the peasants learn to read when there are priests to do it for them?

<comment><USER5> It's more a question of trying to fit everyone into the same mold. Literally teaching every student to code makes about as much sense as teaching every student to weld, or play piano, or learn Latin, or <insert other specialty skill here>. Not that knowing any of those things is bad (most are probably beneficial) but it's ignoring the individuality of the students.

Not every kid is interested in programming. Schools would do better if they could do a little more to nurture the abilities and interests of their students rather than try to fit them into a one-for-all standard curriculum.

<comment><USER13> At my school we were taught an instrument (for a while, to see if it took), introduced to shopwork including welding, and taught Latin for several years.

That last one is less useful but I wouldn't compare it in any way to basic computer programming, which allows some insight into the running of the modern world.

Just saw an amazing comment about this over at the register - 'Democracy requires every person to understand the world to some degree. Computers are an important part of our world. So people need to have at least a general idea about how they work. They need to know what they do where their inherent limitations are.'

</comment></comment></comment></comment><comment><USER14> I truly wish them the best of luck, better CS education in HS is sorely needed. When I graduated HS in 2006, my school was just starting to phase out our programming classes that were still taught in Pascal by a soon retiring teacher. I remember those classes fondly, but I also remember how difficult it was to get other students to care.

</comment><comment><AUTHOR> New link that isn't broken: [http://techcrunch.com/2012/11/26/codehs-is-on-a- mission-to-b...](http://techcrunch.com/2012/11/26/codehs-is-on-a-mission-to- bring-computer-science-education-to-every-high-school-in-the-u-s/)

</comment><comment><USER15> and highschools teach everyone how to math, in the end it's still up to the individual

<comment><USER16> True, but I think the idea is more about trying to make computer science thought of more as a fundamental skill as math is. It's only going to be more important to know how to program as computers rule almost every subject. Pretty soon they'll stop putting "computational" in the front and it will just be an assumption.

<comment><USER17> No, it won't be. Computers used to boot to a flashing command prompt where you could program your ever-lovin' heart out. The fact that they don't today is progress.

[http://www.codinghorror.com/blog/2012/05/please-dont- learn-t...](http://www.codinghorror.com/blog/2012/05/please-dont-learn-to- code.html)

<comment><USER18> Let's replace "code" with "write." Please don't learn how to write. Only writers do this, and we really don't need more of them anyway. There was a time when this wouldn't have sounded crazy.

Learning to code teaches problem solving, new ways of breaking down complex scenarios, and a means to actually build something. It's true that not everyone needs to be a software engineer, but not everyone needs to be a mathematician either, and we don't use that as a basis to tell people not to learn math. Much like math, coding can be abstracted to a form of thinking in a way that plumbing cannot.

I have a friend right now that is using CodeHS to teach 10 year olds, and they're absorbing it like sponges. And I have met so many people that, in retrospect, have _wished_ they had learned to code at a younger age. Maybe if people had told them to learn how to code, they would have.

</comment></comment></comment></comment><comment><USER19> Here is my $0.02. While this may be a great idea, coupled with the current state of software industry this is absolutely terrible! Let me elaborate. What does it take to get a job as a programmer? Next to nothing. After graduating with my computer science degree I've spent a few years working with the most incompetent people who were cooks, business graduates, poured concrete 2 months prior (you name it) and then decided to become programmers because they coded a formula in a spreadsheet.

I've spent some of the most agonizing hours unclusterfucking big bowls of pasta code with meatballs and all kinds of other shit all sprinkled with cheddar cheese. Then I had to hold their hands so that they wouldn't make such a stupid mistake again, and again and again. Then i left and you know what? These people still work there. This is exactly what this kind of thing encourages. It encourages coders, not software engineers/developers and it ends up hurting the industry more than helping it. Yes, you'll have some high school kids who'll like coding. They'll graduate from school and will be sucked into their first programming job right out of HIGH SCHOOL writing shitty code, making way more than their friends and making someone's life miserable. Then a small fraction of those kids will get better (some much better) and maybe get formal education, while the majority will remain damn coders. The industry allows this and it only gets worse. Look, we're not professionals by any formal definition of an engineering profession, but at least we can try to get there some freaking day. But it's incredibly hard to do when you have so much "noise" entering the work-force. Don't get me wrong, i think programming IS essential and I DO believe it should be taught, but i just don't see how this benefits anyone at this point in time.

<comment><USER7> > I've spent a few years working with the most incompetent people who were > cooks, business graduates, poured concrete 2 months prior (you name it) and > then decided to become programmers because they coded a formula in a > spreadsheet.

If we make CS education accessible earlier, you could imagine that more people would actually be more prepared to enter the field.

> Don't get me wrong, i think programming IS essential and I DO believe it > should be taught, but i just don't see how this benefits anyone at this > point in time.

A few immediate benefits: Giving job opportunities to students who would have never had them before. Allowing students to complement their other subjects with knowledge of programming. Demystifying the use of computers. Creating their own projects.

Those seem like benefits to lots of people at this time.

</comment></comment><comment><USER20> It is about 'meaning'. I'll elborate: there are so many things you can learn, so many areas of art, of science, of mathematics, of history and what not - but _why_ should we learn them? Because they are useful? They make us a better person? This is the elephant in the room. Education and learning is more of an attitude instead of constantly stuffing yourself with 'potentially useful information'.

Programming is arguably one of the best ways to derive pleasure and seeing meaning in the learning process. You create, you design, you implement, you learn from others and in the end - most importantly - you have something working (and to show off), together with the thrill of knowing that this existed _because_, and solely because, you made it happen.

It gives one a purpose. So in order to bring things that're only in your imagination into reality, you learn to code better, and learn about what you're trying to code (say, history, or science, or Tarot decks if you're into that).

Instilling this sense of purpose to our young is a very lofty goal. In our current context, programming seems to achieve this goal in a far more time- efficient and rewarding way.

<comment><USER7> Thanks for your comment.

> So in order to bring things that're only in your imagination into reality, > you learn to code better, and learn about what you're trying to code (say, > history, or science, or Tarot decks if you're into that).

I think this is one of the most powerful aspects of learning to code for students. They can create something that is important to them. They can build something that complements their learning in other areas.

... and if this comes to schools... they can directly apply things they learn in school.

</comment></comment><comment><USER21> As a high schooler, I think its' good that companies are trying to reform computer science in high school. Comp Sci AP scares away too many kids, I think, because Java at first is an intimidating language and you don't get much out of the programs you create. Just seeing lines come out of the console isn't as gratifying as building a simple paint app in canvas. The key is teaching students how to build practical applications right off the bat. If my school had offered iPhone app making, I'm sure a ton of kids would have taken the class (granted Objective-C probably would have scared many of them away within the first few days). Making something with a UI makes computer programming seem more practical and interesting than sorting and searching an array in Java and spitting out its position in the console. On an unrelated note, Karel the dog and his (her?) world reminds me a lot of Greenfoot and GridWorld.

</comment><comment><USER22> This may be partially "futile". Though my experience (from teaching and 15y of recruiting) is inconclusive I still lean strongly towards the "double hump" theory is true.

"All teachers of programming find that their results display a 'double hump'. It is as if there are two populations: those who can, and those who cannot, each with its own independent bell curve."

<http://www.eis.mdx.ac.uk/research/PhDArea/saeed/>

[http://www.codinghorror.com/blog/2006/07/separating- programm...](http://www.codinghorror.com/blog/2006/07/separating-programming- sheep-from-non-programming-goats.html)

</comment><comment><USER23> "You are using Internet Explorer, an unsupported browser :(

You should download Google Chrome so you can get started!"

Just a warning from a high-school teacher: this is a non-starter in a _lot_ of schools. High-school IT departments have a lot on their hands keeping kids on approved sites, and (for historical reasons, as I understand it) IE is one of the easier browsers to deploy in such a way.

I know you probably don't want to develop for IE, but if you want to hit the market at large, you'll have to. I can probably get my IT department to put Chrome on for an approved list of students, but not every school will be willing to do that.

</comment><comment><USER24> _While students will likely get the most out of CodeHS if it's being offered in a computer science class taught by someone familiar with CS, the platform allows teachers to learn right along with their students._

That there is putting a finger on a huge cultural hurdle. Not just for the adoption of this problem bu maybe to adaption to the modern world. The rule of thumb is that teachers need to be 5+ years more advanced than their students.

A teacher that finds the material hard is a very different role.

</comment><comment><USER25> I want to teach every American sexagenarian how to reverse dunk, taking off from the free throw line. My "Show HN: Hacking Levitation" will be along shortly.

Teach kids math, teach kids to write, and let those who care to find their way to coding. The schools are doing badly enough on math, reading, and writing that this is the area that requires concentration.

</comment><comment><USER2> Anyone else getting a 404? ... seems ironic given the headline

<comment><USER18> Down for me as well--looks like TC is having some issues. Clearly they could use some coding help too.

<comment><USER26> 404 means that they most probably removed the post.

<comment><AUTHOR> Yeah, the post is down. If you're interested, you can check out <http://codehs.com> or <http://csinhs.com> to read about us.

</comment></comment></comment></comment><comment><USER27> Best of luck! The education system is incredibly antiquated; it's time to give future generations the tools to not only compete, but to thrive in the 21st century.

</comment><comment><USER28> Wish you success. Have them get a project, personal side projects can teach a lot.

<comment><USER29> Any ideas for suggested projects/games?

</comment></comment><comment><USER30> Crap, I don't want programming to be a mainstream job when I grow up

</comment><comment><USER29> What a great idea!</comment>


Transparent Solar Panels Will Turn Windows into Green Energy Collectors - <AUTHOR> https://www.the-open-mind.com/transparent-solar-panels-will-turn-windows-into-green-energy-collectors/ <comment><USER2> This is blogspammed PR that gets it wrong. This is a research project that is nowhere near production with many "ifs". Vertical surfaces don't make a lot of sense for solar since they get limited exposure. They'd have to be incredibly cheap to make financial sense.

Research like this comes out every day. 90% of the time it's not possible to make it practical.

<comment><USER3> A large fraction of the cost of solar is installation — the panels are actually a minor expense in most rooftop installations. So using windows, which are being installed anyway, isn't all that crazy. It will work best on a South-facing window at a high Northern latitude or vice versa.

<comment><USER4> > the panels are actually a minor expense in most rooftop installations

I have had the questionable delight of seeing a specification made for a rooftop installation recently, so I know this is not universally true (even if you use an older type of solar panel, which is cheaper).

<comment><USER3> The online price of the panels on my roof is under 1/3 of the total cost of the system. The inverter and related hardware is much less than that.

</comment></comment></comment></comment><comment><USER5> Office towers seem like a natural fit for this and have a huge surface area to collect solar energy from! Hope this makes it out of the lab and into commercial buildings in quick fashion.

</comment><comment><USER6> My house has 4 walls and a roof to cover solar panels in before it makes sense to make my windows solar panels. Unless it is one of those skyscrapers where the entire exterior is glass.

</comment><comment><USER7> Just from a physics point of view, I have a hard time believing this. Isn't a large portion of the energy coming from the sun photons in the visible wavelengths? If the solar panel is transparent, it's allowing those photos through and not collecting energy.

Or am I wrong, and most of the energy is in the non-visible range?

<comment><USER8> most of it is in the blue i think, but from the surface of the earth this range is scattered so the next peak is in the green-yellow. I'm sure there's UV we could capture with windows

</comment></comment><comment><USER9> 1\. Utility solar will _always_ be cheaper then distributed solar.

2\. The biggest limiting factor on renewable adoption is cost.

3\. We will never run out of space to put solar panels.

The last thing I need is a pile of extensive, over-complicated, version 1.0 technology and all of its electrical wiring, etc crammed into my windows.

<comment><USER10> > 1\. Utility solar will always be cheaper then distributed solar.

Utilities are often privatized monopolies these days, that's not at all a safe assumption. Look what happened with California and Enron.

[https://en.wikipedia.org/wiki/Enron#California's_deregulatio...](https://en.wikipedia.org/wiki/Enron#California's_deregulation_and_subsequent_energy_crisis)

<comment><USER3> Also, look at the hilariously high cost of electricity in PG&E territory. If you can deal with storage and peak loads, on-site generation is competing with 20-40 cents / kWh charged by PG&E, not the vastly lower prices that PG&E pays for generation.

<comment><USER10> Downed PG&E transmission lines are also implicated in causing fires in the state, just another argument in favor of decentralized, on-site generation.

</comment></comment></comment></comment><comment><USER11> This lacks data. We'd need to know the efficiency, life expectancy and energy production cost of the cells in order to know if this is really interesting. If you need more energy to produce the cells than the amount they'll provide throughout their lifetime, it's not worth it. Sure, it looks cool, but it's too soon to publicize.

</comment><comment><USER12> Many negative comments. While this might not yield the desired results right now it's still good that different approaches are being explored and evaluated.

Also, as for many things (think gorilla glass) the right application might not be the one for which this technology has been developed originally.

</comment><comment><USER13> What is up with this site that disables selecting text and the right click menu?

<comment><USER14> F12 > Console, then run:

        document.onmousedown = null
        document.body.onselectstart = null
        document.ondragstart = null
        document.onselectstart = null
        document.oncontextmenu = null</comment></comment>


Ask HN: Have you been scanning the archives for favorites to add? - <AUTHOR> It might be fun to pool our associative memories.<p>Leave a comment, maybe with an explicit link to your favorites for convenience, and maybe link to old favorites that stuck in your memory. I'll start in a comment below. <comment><AUTHOR> As of this writing I think I have ~100 favorite stories and about as many favorite comments:

[https://news.ycombinator.com/favorites?id=akkartik](https://news.ycombinator.com/favorites?id=akkartik)

Here's my sentimental favorite, about Ricky Jay's close-up card magic:

Secrets of the Magus [https://news.ycombinator.com/item?id=8568467](https://news.ycombinator.com/item?id=8568467)</comment>


Tiny PE (2008) - <AUTHOR> http://www.phreedom.org/research/tinype/

<comment><USER2> I recommend checking out Corkami's articles/posters:

[https://code.google.com/p/corkami/wiki/PE](https://code.google.com/p/corkami/wiki/PE)

[https://code.google.com/p/corkami/wiki/PE101](https://code.google.com/p/corkami/wiki/PE101)

[https://code.google.com/p/corkami/wiki/PE102](https://code.google.com/p/corkami/wiki/PE102)

It also has a section about the minimal size: [https://code.google.com/p/corkami/wiki/PE#minimal_sizes](https://code.google.com/p/corkami/wiki/PE#minimal_sizes)

Modern Windows versions refuse to run the 97 b and 133 b files from the linked article.

<comment><USER3> I wasn't able to run them starting with the 468 B file with only the file alignment reduction (which as stated, violates the official PE spec).

</comment></comment><comment><USER4> For those who don't know, there are several executable formats where smaller programs can be written. For instance, a .COM executable (a legacy format now [2]) can be written in just 20 bytes [1].

In the case of the Portable Executable (PE) format, 97 bytes is certainly an impressive feat.

[1]: [http://www.gnostice.com/nl_article.asp?id=225&t=The_Smallest...](http://www.gnostice.com/nl_article.asp?id=225&t=The_Smallest_Hello_World_Program_At_20_Bytes)

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

<comment><USER5> This makes me wonder what the smallest asm.js program could be.

<comment><USER6> ;

<comment><USER5> Not valid asm.js, doesn't do anything useful.

</comment></comment></comment></comment><comment><USER7> A quick google reveals the answer, but this article would benefit from "A PE file is ..." in its introduction. Maybe it's expected that the target audience already knows this info however

<comment><USER8> Indeed, I thought it was a minimal version of Bart's Preinstalled Environment (BartPE) ...

</comment></comment><comment><USER9> Importing a dll from a UNC path to load the file over WebDav is quite an amazing trick, many props to the author.

</comment><comment><USER10> Wow, what a great read. Nice work.

</comment><comment><USER5> WebDAV for retrieval is just HTTP GET right?

<comment><USER11> Yes</comment></comment>


Was Richard Feynman a Great Teacher? - <AUTHOR> http://math-blog.com/2016/02/01/was-richard-feynman-a-great-teacher/ <comment><USER2> It's the same here in Argentina. You buy a book to study the subject of the Physics class, and then you buy the Feynman as a companion because it's very interesting to understand the subtle parts.</comment>


User experience design for APIs - <AUTHOR> https://blog.keras.io/user-experience-design-for-apis.html <comment><USER2> When I worked on the .Net framework at Microsoft we would run usability studies on many of the APIs well before we shipped them. It was always enlightening seeing how professional programmers use your API. We would assume that people would approach the API with a specific mental model for example, only to find that they thought about the API quite differently. I wrote an article in 2004 about how we approached API usability at the time: [http://www.drdobbs.com/windows/measuring-api- usability/18440...](http://www.drdobbs.com/windows/measuring-api- usability/184405654)

The great thing about doing usability studies on APIs is that it is easy to mock up a prototype of the API that people can start to code against. The API doesn't have to work but you get to see how people react to the names of classes, methods, parameters etc. I used to blog about API usability and what we were learning here: [https://blogs.msdn.microsoft.com/stevencl/tag/api- usability/](https://blogs.msdn.microsoft.com/stevencl/tag/api-usability/)

There is a group of researchers and practitioners currently working on API usability. Some good links here: [http://www.cs.cmu.edu/~NatProg/apiusability.html](http://www.cs.cmu.edu/~NatProg/apiusability.html)

</comment><comment><USER3> Before I left Square earlier this year, I lead our design efforts on the developer API.

[https://docs.connect.squareup.com/](https://docs.connect.squareup.com/)

It was really interesting work and the team was quite committed once we found the right team.

People always asked what does a designer do on an API. It turns out that if the team cares, quite a lot.

Documentation is the obvious one but lots of other things like structuring the actual information, setting up apps, working on API explorers, look at terminology even how the endpoints are thought of and of course, how do you easiest get up and running with the API.

It was surprisingly interesting work from a design point of view.

<comment><USER4> +1 Perhaps I have said this before, but UX folks have been my go-to colleagues whenever I need their inspsirations for anything ranging from graphs (like monitoring metrics) to debugging since the UX team is heavily involved from the inception of a project and sometimes have more intimate knowledge of the overall architecute of the project than the core developers do.

They are amazing (of course I am talking about the right kinds).

<comment><USER3> And I have it the same way with developers. They were always my go-to colleagues more than other designers for insights and

I would generally suggest to hang out with radically different perspectives than your own.

Luckily, in my new company both my partner feel the same way.

<comment><USER4> Right!

Worth sharing I am a DevOps so I do production support. One night I was at the dinner table fixing some horrible issue. My sister and brother-in-law asked why I was frowning. Initially I refused to explain the situation but they convinced me to brief them the failure. They raised some questions as outsiders (one is a doctor, another is an accountant). Immediately lightbulb lighted up! Within minutes I was able to find the root cause, pushed a fix, documented the issue, and closed my laptop.

<comment><USER3> Exactly

</comment></comment></comment></comment></comment><comment><USER5> You cannot build a large API effectively without using it. Programming is tons of details, and you're going to miss some if you aren't programming with your API yourself. It's like building a graphical user interface without ever firing it up.

For instance, if you build a simple REST interface with a list at /object/ and details at GET /object/1 and changes at POST /object/1, then you're good, right? This is a well-understood way of structuring things?

Well, what if your objects are really simple and someone has to synchronize 100k of them. It's not possible to do that efficiently through such an interface.

The API has to see some use, and it has to be able to evolve as you learn. And you need to be ready to make some sacrifices on your side of the fence, to make the life of the API user easier.

<comment><USER6> This is essentially the argument behind BDD, except applied at a level where the 'customer' is another developer.

Some of the worst APIs I've seen have been ones designed by a backend developer based upon some vague specifications handed down by a non-technical PO. They were often designed with half of the stuff that was necessary missing, lots of stuff that wasn't necessary and some stuff which made no sense before being thrown over a wall.

The better APIs were 'designed' by the developer who would write the code that would consume them. Even if that just meant an email or a scrap of paper with a few example URLs and snippets of JSON.

</comment></comment><comment><USER7> Programmers are so bad with this, this needs to be a more respected aspect of writing software in general. "Well, I comment everything" isn't enough. If you spent hundreds or thousands of hours on your API, but skimp on the part where you actually look at it from the users' point of view, that's such a colossal waste. You have to multiply the number of future users with the hours wasted on tedious setup hoops and learning confusing naming conventions. I look at the damage bad UX design can do to society, culturally, and I weep. A single bad decision, there, can cause _millions_ of wasted hours.

<comment><USER8> Two decades into my career and I absolutely shudder every time I get a request to "integrate with <xxx>'s API, it'll be easy!"

It almost never is.

Everything about the experience sucks. The documentation is usually a mess and the code flow is usually strange as hell. But I can live with that.

It's the completely opaque error states that kill me. The article dedicated an entire section to it and I hope people take it to heart. When I pass bad data or something you're not expecting give me some clue as to what it might be!

I just spent 60+ hours working on an integration. 95% of that was spent changing parameters and encodings hoping that something would magically fix the 400 I kept receiving back from the server.

It turns out a shared secret had a typo (on my end).

The thing is this bad design is costing that company real $$. Not only was it a frustrating experience for me, I took a couple of hours of their engineers time trying to hunt it down. The lack of error handling made it difficult for them to track the issue down on their side as well.

I'll never forget the first time I touched Twilio's API. Everything was so clear. I had screwed something up, and got a clear message about what was wrong. It was magic.. and the whole thing was up and running in less than an hour.

Give me more of that please!

</comment></comment><comment><USER9> Nit: Really verbose error messages like the last example are at risk of being brittle. If the API changes, there may be a failure to update the error message. This is because the messages may concern things at a distance, and may have arbitrary prose that no longer makes sense.

For example, imagine if all your error messages were basically documentation style prose. That would be a nightmare, and would set you up to a lot of error message refactoring. A better strategy is somewhere in the middle.

<comment><USER10> Wow, the example in the article is an _extremely_ verbose error message! But still, detailed and helpful error messages really do make the developer's life easier.

When building API end points, I take a different approach by including both messages _and_ message codes, as well as a general "result" code (to make it easy to determine if it's a basic success/error result (also including the right HTTP code)).

An example that I'm working on right at the moment:

        {
            "result": {
                "code": "error",
                "message_code": "too_many_user_agents",
                "message": "You have sent %s user agents; this is more than the maximum allowed per batch (%s user agents). Please send fewer in each batch."
            }
        }

The message describes the problem; what they did wrong, what the limit is and how they can fix it so it doesn't happen again.

As well as this, the developer can easily check that the response _code_ was an error, and there's the _message_code_ \- this will NEVER EVER change for this problem, so a developer could write code to specifically deal with that scenario.

However there's also a human readable _message_ , which may potentially change (perhaps a grammar or punctuation fix, or if it included a URL it might change one day...)

I've found this approach is the best sort of middle ground.

</comment></comment><comment><USER11> I'm recommending this post to everybody I'm working with.

Many APIs are targeted to internal teams creating SPAs nowadays. Maybe the same developer writes both the backend API and the fronted app. Those APIs tend to be a wild west of all the mistakes the post is about. Documentation is often sub optimal, not to talk about vulnerabilities introduced by quick and dirty hacks because the team decides that the backend can trust the frontend (missing validations and missing authorization checks are common in the experience of a collegue working on penetration tests.)

Unfortunately such badly designed APIs are going to hinder the development of new functionality for the time being. We're moving from spaghetti code to spaghetti APIs.

</comment><comment><USER12> Folks interested in this would probably also be interested in:

* this talk by Jesse Noeller from PyTexas a few years ago: [https://www.youtube.com/watch?v=-vZ_E1OO_PY](https://www.youtube.com/watch?v=-vZ_E1OO_PY)

* the WriteTheDocs community, which is sortof a mashup of traditional technical writers and software engineers. [http://www.writethedocs.org/meetups/](http://www.writethedocs.org/meetups/)

* the mailing list GET PUT POST (shameless plug): [https://getputpost.co/overhauling-api-docs-with-gocardless-9...](https://getputpost.co/overhauling-api-docs-with-gocardless-90cc2e656750)

<comment><USER13> Related, but shameless plug, my PyCon 2017 talk "How to make a good library API" is also about the "API as UI" concept: [https://www.youtube.com/watch?v=4mkFfce46zE](https://www.youtube.com/watch?v=4mkFfce46zE)

There's also a Django-specific version called "Your Django app is a User Interface": [https://www.youtube.com/watch?v=Mnzvjn1v1CY](https://www.youtube.com/watch?v=Mnzvjn1v1CY)

<comment><USER12> ooh thanks!

</comment></comment></comment><comment><USER14> API documentation and usability is so severely lacking, even in products you would expect to deliver something excellent. I work for an ISP, and we've recently acquired industry standard software for things like DDI/IPAM and so on. The software, annual licensing and so on for some of these products is 5 to 6 figures, yet the API(s) are a mixture of ambiguous REST, undocumented SOAP and a day-to-day nightmare.

The only breath of fresh air I've had lately is interacting with the NetBox API which uses Swagger to sort of self-document and allow for testing.

</comment><comment><USER15> I've found that first writing the docs first using API Blueprint has been the single most valuable thing I've done in my API development. It really makes you think about data shape, input params, edge cases etc. and leads to much nicer APIs in my experience. I think it's because, in my case anyway, it's a separate project and language to the implementation, so your thinking is not bound by whatever you're implementing with.

</comment><comment><USER16> A few more guidelines that seem obvious to me, but which I see broken _all the time_ :

1) If an API value can be changed any time, it should probably be a plain object property

2) If an API value can be changed but there are side effects, it should probably be a "setFoo" method

3) If an API value can be specified, but not changed after init/instantiation, it should probably be an argument to the constructor or init function

</comment><comment><USER17> I really like the error messages that Joi[1] provides. You can easily use the error.message property to give a human friendly message to the end-user and if the default options don't serve your needs you can overwrite them with custom messages.

Someone made a Joi playground a few months ago, Joi Tester[2], that makes it really easy to test your Joi schemas. If you're curious, feel free to give it a try (I'm not affiliated with the tool in any regards but I do think it's awesome).

[1] [https://github.com/hapijs/joi](https://github.com/hapijs/joi)

[2] [http://framp.me/joi-tester/](http://framp.me/joi-tester/)

</comment><comment><USER18> Everyone who has ever worked with a "proper" API (e.g. Mailchimp) with awesome and intuitive status messages will hopefully never again fail on this. Very bad that this is still not state of the art.

<comment><USER5> I find it interesting that you hold the MailChimp API in such a high regard.

I use it frequently as an example of how not to build an API. I find it hard to integrate efficiently with it - it got worse from version 2 to 3, although some of the blunders have later been fixed.

You're probably right that the error messages are relatively thorough. Many of the constraints aren't documented in the reference documentation, though, so it requires trial-and-error.

</comment></comment><comment><USER19> Great, except for this…

> _(in general, always use ValueError and avoid assert)._

ValueError is for when,

> _an argument that has the right type but an inappropriate value, and the > situation is not described by a more precise exception_

(the docs explicitly note only for builtins, but I'm frankly okay w/ people using it in their code.)

You should _not_ be raising this when you should be raising AssertionError, however, the two conditions are very different; the latter is for conditions that _should_ be true but for some reason aren't. I find these usually crop up when running through a bunch of ifs:

      if a:
      elif b:
      elif c:
      else:
        # *One* of the above should always match, in this case.
        # This branch should never be taken, and it wasn't any fault of the user we're here.
        raise AssertionError('good description of the situation')

Attempts to restructure the above are usually fairly bad: you can omit the `else`, but then execution will never take any branch, and if the branches do something like initialize a variable that the code following the branches will make use of, you're doomed anyways, and it's better to bail in an informative manner. You can meld the last elif and else together (i.e., the else just handles case C above), but then it also inadvertently handles unexpected states D, E, etc. too.

IMO, AssertionErrors should indicate bugs in the called API. ValueErrors indicate bugs in the caller's use of the API.

(You may choose a less "destructive" method of asserting, such as logging, but in my experience, these get lost, and if you're in an undefined state then you still need to find some way to _repair_ that state, and in my experience most attempts to do so are more trouble than they're worth. It's better to fail earlier and harder and louder, s.t. bugs are discovered and swiftly fixed.)

<comment><USER20> > IMO, AssertionErrors should indicate bugs in the called API. ValueErrors > indicate bugs in the caller's use of the API.

Yes, I agree with this stance. `ValueError` should be used for user-provided input validation (as well as `TypeError` in some cases). But as it happens, many Python developers use `assert` statements to do input validation, and generally don't provide any error messages in their `assert` statements. I'm suggesting going with `ValueError` (and a nice message) instead.

</comment></comment><comment><USER21> APIs and programming languages are UI for programmers, so yeah, they deserve some UX thinking.

However, where is the current trend of functional programming in this piece? (I am not disparaging FP, on the contrary, I think it's a good development.)

Shouldn't API calls be, for example, easy to test? In functional programming, we often avoid doing actions directly, and instead give descriptions of actions (in form of functions) that are to be made. Does your API support that?

What about minimization of the state that the API requires to keep, and its transparency?

I am sorry if I come off a little incoherent. Best would be if I could give some tool a program that calls an API, say a sequence of API calls. And I would be told, this sequence is valid for the API. So I could prove for my program that it is accessing the API correctly.

</comment><comment><USER22> Reminds me of Bryan Helmig's (Zapier) talk at APIDays SF back in 2013 about an API consumer shift.

[http://bryanhelmig.com/your-api-consumers-arent-who-you- thin...](http://bryanhelmig.com/your-api-consumers-arent-who-you-think-they- are/)

</comment><comment><USER23> > Deliberately design the user onboarding process. How are complete newcomers > going to find out the best way to solve their use case with your tool? Have > an answer ready. Make sure your onboarding material closely maps to what > your users care about: don't teach newcomers how your API is implemented, > teach them how they can use it to solve their own problems.

Really good tip! Going to spend a little more time reworking my onboarding workflow with this in mind.

</comment><comment><USER24> Perhaps "Don't change your API to something incompatible but with the same names" would be a good piece of guidance too?

[https://github.com/fchollet/keras/issues/3921#issuecomment-3...](https://github.com/fchollet/keras/issues/3921#issuecomment-340626202)

</comment><comment><USER25> Not an "API", but git has a terrible UI... yet the error messages (and guidance included in response to correct commands) are the best I've ever seen. They guide the user through a typical workflow.

A similar guidance is pop-ups in games (e.g. when next to car, "F to enter").

</comment><comment><USER26> After three attempts at designing an ML rest-lile API, I ended up writing the deepdetect's API. Never touched its fundamentals since mid 2015. Very very far from perfect but has served great til now!

</comment><comment><USER27> pytorch with a keras like functional/layers API would be amazing. I'm guessing we might see that in tensorflow when keras adds support for the new eager mode.

<comment><USER28> Can you elaborate? I feel like torch.nn gets you pretty close.

</comment></comment><comment><USER29> It's telling that this is on the Keras blog, because the Tensorflow APIs are quite a mess</comment>


Why I released a crappy todo app that no-one will ever use - <AUTHOR> http://www.moreofless.co.uk/just-ship-it-like-yesterday/ <comment><USER2> A lot of the programmers/devs/engineers I talk to don't ship much code. They just re-work some existing code base to add X or Y feature. These people don't have a clue to what it takes to design something from the bottom up and hammer it into something that resembles the original idea. Shipping code, which is my favorite passtime, is just damn difficult. Not because the code itself is hard. No. Its because we procrastinate, change our minds, focus on early optimization, decide to to talk to others about it, and just do everything expect shipping the damn thing.

That is why you shoul dno tcall your project crappy. Hell no. You went ahead and shiped something. You started a project and saw it through. You know how many people go through life without ever finishing something? A lot! But you managed to do something. And to be honest, it is quite handy. Its is a nice project that could be setup on an intranet so people would stop using email attachments to keep track of their todos.

Keep hacking and shipping. Good luck.

 _edit_

Do you mind listing your email on your profile? I'd like to get in touch with you.

<comment><USER3> Good for you, OP (site is down so I can't try your app at the moment).

orangethirty: as someone who is learning programming and trying to ship something as well (but running into the difficulties you alluded to), your post is very encouraging.

<comment><USER4> It's really encouraging to see someone ship something despite all the doubts. I agree with parent and find this really encouraging.

I've built a similar prototype as well, but just kept it locked up because honestly I was afraid to really put it out there since I shared the same doubts.

So to get past that fear I'm just going to put it out there. <http://app.iammako.com>

<comment><USER2> I went there and found a log in wall. Why do that if you want me to test it out? Make the demo work without me having to register. Email me when you do that and Ill poke around the app and give you some feedback. I liked the background in the log in page, though.

<comment><USER4> Sorry about that. I made the app so that you can organize your todos into projects (so more of a pm app), and invite others to work with you on projects. What I could try and do is just set it up so you're logged into a test account by default to poke around.

I'll let you know when I've taken care of that. Thanks for showing interest!

</comment></comment></comment></comment></comment><comment><USER5> Good.

I think it's an important milestone to build something end to end, no matter how simple or imperfect.

On a related note, I was recently looking for a todo app for my phone and found myself wondering how it is that there are so many (hundreds) apps, many of which have their own ardent fans.

When there are so many competing apps and such parity between them, what's the lure for using one over another?

In my case, I tried several and ended up using the one which felt most intuitive to me - the app which allows me to record and organize things the way I think of them with the least effort.

So...I wonder if the relatively low barrier of entry to creating sufficient functionality in such an app has worked with the myriad, individual ways of thinking about time and tasks to feed multiple many successful apps in the same space.

If this is the case, how different would other spaces, which are currently dominated by just a few players look and feel if the mechanics were easier to implement?

<comment><USER6> It's really hard to get a todo app right because the information you juggle is so small, and individual user preferences are so vast that even competing in efficiency with a text editor and a plain text file, or a paper and pen, is hard.

So in one way the mechanics are trivial. In another way they're an immense challenge.

</comment></comment><comment><USER7> A good friend with 20+ years of programming experience once told me "even putting a form that collects basic information, and sends it as an email, is hard." Shipping a software product, no matter how lightweight, is freaking hard.

</comment><comment><USER8> I felt the same way when I released my todo app (<http://benrhughes.com/todotxt.net> \- a windows implementation for <http://todotxt.com>). I mean, who's ever going to use this little PoS that I wrote basically so I could update my task list at work? The last thing the world needs is another todo app.

That was a bit over a year ago. Now I have ~500 active users and a half a dozen of contributors. I get random "thanks" emails, the occasional donation, and something nice to put on my resume. And the satisfaction of actually shipping something.

</comment><comment><USER9> Site is down. Cache:

[http://webcache.googleusercontent.com/search?q=cache:www.mor...](http://webcache.googleusercontent.com/search?q=cache:www.moreofless.co.uk/just- ship-it-like-yesterday/&hl=en&pws=0&prmd=imvns&strip=1)

Link to the actual app (when it comes back up):

<http://www.moreofless.co.uk/todo>

<comment><AUTHOR> It's back up now, had some emergency firefighting to do - never expected to get onto the HN front page, my poor old server never saw it coming!

</comment></comment><comment><USER10> I like hearing these stories of released apps. It's one reason I like the Show HN threads. I enjoy reading about how they overcame the problems they encountered. As somebody who is working on a project, it helps to distract me from frustration and (hopefully) fix a problem I will stumble across in the future.

</comment><comment><USER11> Well it would seem that the logical next step is going to be giving it a way to provide permanence to the data. That generally means online storage, but there might be other ways that are more in keeping with your offline approach... or maybe you could give the user an easy to remember token that they can use to fetch their todo list from another computer. I like the shopping list aspect of it. I would focus my energy completely on the usability side. Keep optimizing for convenience.

I've just launched a todo list sort of an app too, but it borrows heavily from open source components, much hairier, different audience to yours I suspect (alouy.com).

</comment><comment><USER12> Seems like you have the right attitude! Shipping a "crappy todo app" is more than many will manage, best of luck with releasing more and more projects in the future.

<comment><AUTHOR> Hey, thanks tommoor, appreciate the kind words.

</comment></comment><comment> qu4z-2 Well done!

I know the feeling of working on things and never shipping. I recently decided to actually see a small program (vim plugin) all the way through from idea to documented, installable release.

It's also highly bare-bones (around 10 lines of vimscript, although it started as many more). But I don't want to get side-tracked talking about it. I guess my real point is:

Congratulations on shipping. God knows it can be harder than it seems.

</comment><comment><USER13> I was expecting the first comment to be something like "because you are a jackass" but then I realized that I'm not reading Reddit.

</comment><comment><USER14> Congrats on shipping.

Looking at these comments, I can tell HN is doing its best to re-discover its positive attitude towards "shippers" -- I kind of feel bad for anyone who tried to post a "Show HN" a month ago, only to hear crickets in the comments section. ;)

</comment><comment><USER15> To be honest, most people will never ship something by themselves their entire career. Also, most people will ship something that they think is crappy but it turns out it's the next big thing.

So, kudos for trying. Keep it up!

</comment><comment><USER16> Maybe I should have titled my app submission this morning "A crappy list of good domains that no one will ever use". A provocative title seems to be good for at least 28 more points than I got.

<comment><USER16> (To add: My point is that sometimes "shipping" isn't enough -- you need something else to grab attention).

<comment><AUTHOR> heh, totally agree. I'm totally shocked that I made it onto the first page. Posting the todo to HN was just part of the "lets just ship this thing" process and I got real lucky.

</comment></comment></comment><comment><USER17> Hey Steve, great projects dude. You've got my upvote. Keep it up! I especially loved Squareleaf and PicStrips. Even NotForest has a pretty sweet hypothesis and design.

<comment><AUTHOR> Thanks! Readability kinda stole Notforest's thunder but I still use NF every day, so damn useful.

</comment></comment><comment><USER18> This is cool!

Feature creep: add some neat keyboard shortcuts for the power users ;)

<comment><USER19> I love RTM for that reason.

</comment></comment><comment><USER20> +1 for shipping code</comment>


Scalability issues for dummies - <AUTHOR> http://alwaysnewmistakes.wordpress.com/2009/07/20/scalability-issues-what-are-they-and-their-repercussions/

<comment><USER2> _This is the point where you realize that developers aren't engineers, but craftsmen and that fixing these problems isn't exactly a science but black voodoo magic._

I have mentioned it three or four times before but I'll say it again: the key takeaway from the YSlow presentations is that _fixing the frontend is a science, not black magic_ and that _user-perceptible load times are dominated by front-end factors_.

Not your database! Not your application logic! Not your web framework! Not your idiom for string concatenation!

If you have three CSS files, condensing them to 1 CSS file is as close to zero technical risk as any intervention in the history of engineering, will take you far under a man-day to implement a process to correct this defect, and will provide instant, lasting, guaranteed performance gains everywhere you were using those three files.

If you don't gzip your Javascript, CSS, and HTML yet...

If you have spent weeks thinking about how to use memcached and not so much as a minute discussing expires headers...

<comment><USER3> _[U]ser-perceptible load times are dominated by front-end factors. Not your database! Not your application logic! Not your web framework! Not your idiom for string concatenation!_

It is true that user-perceptible load times are dominated by front-end factors. However, whether the user perceives anything at all -- or if, instead, the web site has collapsed under load -- is dominated by back-end scalability.

Scalability is far more about _keeping things running_ than it is about _making things fast_. People should pay attention to both front-end and back- end issues -- a website which is up but loads very slowly isn't very useful, but neither is a website which loads very fast but goes offline whenever it gets a lot of traffic.

<comment><USER4> "Scalability is far more about keeping things running than it is about making things fast"

The need to state these facts is further evidence that this is an arts and crafts industry (and not scientific). Imagine physicist saying "Inertia should not be confused with momentum".

<comment><USER2> Inertia and momentum are not just different points on the same continuum. "Keeping things running" and "making things fast" are, at least as the author is using the term scalability. Look at the graph of response time versus number of operations included in the article. It says "As the site gets busier, performance is impacted negatively to the point where it compromises the user experience". That is virtually the definition of a scalability problem (more scale = boom!) without ever requiring the system to stop running.

I suppose you could arbitrarily redefine scalability such that problems caused by scale which did not cause the server to crash were not scalability problems, but your redefinition would not contribute to professionalizing the field of web development.

<comment><USER5> No, it isn't. People in our industry commonly use the word scalability to denote metrics such as response time but that's just plain wrong.

You can have a website that takes 3 minutes to load yet still be scalable. As long as it takes 3 minutes to load when you have a single user, 3 minutes at 1000 users and 3 mintes at 1 million you have a scalable website. Scalability is all about keeping the same (or at least close) performance as your load increases.

If you want to know more about scalability I suggest you read Theo Schlossnagle's excellent Scalable Internet Architectures book.</comment></comment></comment></comment></comment>


Uninteresting Places - <AUTHOR> http://popula.com/2020/07/27/florida-mall/ <comment><USER2> I wonder how many weird internet musical micro-genres will be birthed by the economic and social waste laid by COVID-19. Mallsoft was just a weird vaporware offshoot paean to mall culture in the '80s and '90s; now it's a requiem to the malls of today.

[https://knowyourmeme.com/memes/cultures/mallwave- mallsoft](https://knowyourmeme.com/memes/cultures/mallwave-mallsoft)

<comment><USER3> What the...? I never heard of mallsoft before. I watched some of thoss videos (well, listened). I cant believe that's a thing. I'm laughing. Am i supposed to laugh or is this considered art?

<comment><USER4> Mallsoft popped into my head when reading this too. Basically mallsoft is a sub genre of vaporwave which is Ambient / electronic music with a focus on evoking and creating nostalgia. mallsoft is a sub genre because it focuses on the nostalgia of an empty shopping mall.

Vaporwave etc is absolutely fascinating.

It's also dead now.

<comment><USER2> It's just expired because it was a big internet niche fad in like 2012. Subsequent micro-genres have appeared since, and also had their turns. Perhaps we'll soon see new ones based on '00s nostalgia.

</comment></comment></comment></comment><comment><USER5> This feels more like a "I don't like David Sedaris" article than a "Uninteresting Places" article.

<comment><USER6> Hi, author here. Thanks for reading! Glad to see the article getting interest here. I do in fact like and respect Sedaris and have read several of his books. Commenter throwanem put it well when they wrote that Sedaris is a metonym. What Sedaris said at the talk gave me a certain feeling, and I wanted to explore that. I think it's also a testament to his skill as a speaker that he was interacting with the audience so much, and his interaction left an impression on me.

<comment><USER7> Sedaris has been on the 'making old NPR listeners laugh via speaking gigs' track for a looooong time now. I saw him in Berkeley a while back; go spend a day in town and make jokes about it seems to be a bit of an easily- transportable schtick. The bit I remember from Berkeley was a visit to a kind of stationary store that was somehow appointment-only in like 2015-ish, and got a mix of admiration (HOW?!) and ribbing (REALLY, BERKELEY?!).

That kind of mix of nostalgia and disdain is the essence of Sedaris, i think... A cloying love for the past with a solid recognition and disdain for the terrible parts of it. Mid-century modernism accompanied with a side of unrelenting homophobia. The familiar atmosphere of home, suffused with the cigarette smoke that will eventually, slowly, painfully kill your mother.

Like most comedy, there's a question of punching up vs punching down. Punching up is funny: sticking it to the homophobes is great. But punching down is mean and contemptible... So it all comes down to whether you, in the audience, see Sedaris as a survivor/escapee of suburbia, or as some New York literati come to talk about how much your mall sucks.

<comment><USER8> > Like most comedy, there's a question of punching up vs punching down.

"Punching up" vs "punching down" is this weird trope that materialized in the past couple years as a way to argue "making fun of MY preferred groups is not allowed." But there are many successful professional comedians who don't agree with it, and "punching down" on the rubes is in fact a time honored genre of comedy...

</comment></comment></comment></comment><comment><USER9> For those who left the article wondering what Sedaris's beach house is named, it is the "Sea Section".

</comment><comment><USER10> Interesting article, I don't really know if this is what Sedaris is getting at, but recently I came across the term "non-place":

Non-place or nonplace is a neologism coined by the French anthropologist Marc Augé to refer to anthropological spaces of transience where the human beings remain anonymous and that do not hold enough significance to be regarded as "places".

[https://www.brown.edu/Departments/Joukowsky_Institute/course...](https://www.brown.edu/Departments/Joukowsky_Institute/courses/archaeologiesofplace/7994.html)

From what I've read online the inclusion of shopping malls is a bit contentious because for many friends they served as a central meeting & hangout place. And as a result of that kind of transcend their primary purpose. I can certainly see why people hold a strong nostalgic (possibly even melancholic?) attachment to malls in particular.

</comment><comment><USER11> To the author: Thanks for this. I grew up in Tallahassee (actually, Havana, but even fewer people know where Havana is than know where Tallahassee is). I spent way too many hours of my childhood in Tallahassee Mall, Governor's Square Mall (I remember when it opened), and the long-dead Northwood Mall.

Now I live in Singapore, another place with heat, humidity, rain, mosquitoes, and reptiles eager to ruin your day. What it has that Tallahassee doesn't: literally dozens of malls. :)

<comment><USER6> Thanks for reading and sharing your experience! I go to a gym that's in Northwood Mall, and there are a couple other businesses survive. I should've written about that one too, wish I could've seen it back in the day. The City just bought Northwood and they're turning it into a big police station.

</comment></comment><comment><USER12> So many formative moments in my life happened in my local mall. I live in the exurbs of NYC and the mall was the only sensible, safe meeting place for my friends and I. Notably, it was a place where we could hang out without parents around.

It's hard to defend the existence of malls. I think they're a symptom of larger problems concerning community design. I also think that they encourage excessive commercialism. Still, none of that changes what the mall means to me.

</comment><comment><USER13> This is a nostalgia thing. What he wants is this.[1]

[1] [https://youtu.be/VUMTshUflTg](https://youtu.be/VUMTshUflTg)

<comment><USER6> Hi, thanks for reading. You're right, but the mall golden age was before my time. What I like about the mall I wrote about is that it doesn't feel dead, it still has some of the essence captured in Fast Times or this video, which is one of my favorites: [https://m.youtube.com/watch?v=_q7zfJwQIsg](https://m.youtube.com/watch?v=_q7zfJwQIsg)

<comment><USER3> I grew up in the 80s and went to the mall many friday and saturday nights to be with friends and, later, to flirt with girls.

A typical exciting night went like this: parents dropped us off and picked us up (too young to drive). Sometimes I'd carpool with friends, sometimes we would just meet there.

We might catch a movie (two screens were typical, maybe 3, so they could fit a theatre attached to a mall unlike today's 24-screen monsters).

Then we would hit the mall video arcade -- some malls even had two arcades! -- then the ice cream shop or Orange Julius ... this was before food courts... then browsing or shopping at KB Toys toy stores, Spencer Gifts, and Encore or Walden Books (especially the Dungeons & Dragons section in the book stores).

But the primary reason for going was to socialize. We would pass other groups of kids walking up and down the mall like us, looking for something do but really just enjoying being together but never admitting that to each other. That wouldn't be cool.

Sometimes we knew those other groups of kids, sometimes not, and on rare occasions a fight might break out or at least a chase through the mall.

I didnt go into the department stores really, unless they had a toy section or maybe a sports section, but i think the girls went into them for makeup, etc. Claire's didnt exist yet and neither did Victoria's Secret or Target.

When it was time to go, we'd call the parents on pay phones if we hadn't prearranged a pickup time, then wait outside if it was summer.

I remember seeing E.T. in theatres in this manner in the summer of 1982. And later, Rocky III.

Simple memories of fun childhood times when we were learning independence.

</comment></comment></comment><comment><USER14> I'm a little shocked, actually, that the writer dislikes David Sedaris.

<comment><USER15> Interesting, I like malls and dislike David Sedaris. I dont think Ive ever felt so connected to an author before. Different strokes, I suppose.

<comment><USER6> Glad I'm not alone! Thanks for reading. Like I've commented elsewhere in this thread, I by no means hate David Sedaris. I think he of all people would appreciate a nobody taking potshots at a famous writer, and hopefully value my criticism. That criticism is genuine but ultimately lighthearted and an avenue to discuss other feelings.</comment></comment></comment>


Screw Google - <AUTHOR> https://imfromthefuture.com/serp-monopoly-strategy/ <comment><USER2> Mods need to update title. The current title is "It's Not About Ranking #1 – The Monopoly Strategy"

Seems to be a generic article about SEO

</comment><comment><USER3> +1 for learning about KeywordKeg</comment>


Ask HN: How do you fall asleep? - <AUTHOR>

I've always had trouble falling asleep. But not having a 9 to 5 has made it even worse. Left to my own devices I fall asleep when I'm mentally exhausted and wake up, without an alarm, when I'm rested.
I just can't seem to shut my mind off at will, and further I can't decide if the effort to go to bed at a reasonable hour is even necessary, aside from fitting in with social norms.
What do y'all do? Do you try to go to bed at a reasonable hour? Why? How do you shut your brain off and sleep? <comment><USER2> Start dreaming in your head. Don't think of real stuff or ideas you're working on. Dream or imagine something. Stretch. Get comfortable.

</comment><comment><USER3> I struggle falling asleep sometimes as well. Actually, a lot of the time. Here's what helps for me:

1\. Don't bring my laptop into the bedroom. If it's around, I keep giving in to the urge to check HN or Facebook or Twitter or my email "one last time" every 15 minutes or so.

2\. I drink a glass of milk and take a melatonin tablet about 30 minutes before bed. Melatonin helps induce drowsiness.

3\. Turn the light off. Seems totally obvious, but if I'm reading in bed, I may have my lamp on. Sometimes I just have to force myself to turn the f!#kng light off so I can fall asleep.

4\. Turn the AC down. I sleep better when it's a little chilly, so I turn my thermostat down a few degrees a little while before bedtime.

5\. Daydream. I just start running through some kind of scenario in my head and let the fantasy run until I fall asleep.

</comment><comment><USER4> Truth be told, badly. I can lay awake all night thinking about stuff and then when I get up in the morning I can be more tired than I was when I got in.

Very frustrating, and I wished there was a reliable, non pharmaceutical way to get a good nights sleep. I've tried a lot of different things over the years, the only thing that seems to help me is to stop 'work' around 4 pm and to only work on physical stuff after that. (not that anything I do could legally be called work, but it keeps me busy nonetheless).

</comment><comment><USER5> I don't think there a many people able to shut down their brain by pure willpower. When I notice that I can't go to sleep I get up again. Why?

Because when the body is not ready for rest, it's, atleast for me, impossible to force him. So I just start doing things like go for a walk in the dark, read a book or clean up. Once I get tired I hop back in bed and surprise, I'm able to fall asleep.

</comment><comment><USER6> One thing I've found to help is listening to a podcast, oddly enough. Even though I enjoy the content, something about the sound from the TWiT network just seems to put me out if I'm laying in bed with it on.

</comment><comment><USER7> Kids. They remove most barriers to sleep.</comment>


Tesla's demon-haunted cars in Irma's path get a temporary battery-life boost - <AUTHOR> https://boingboing.net/2017/09/10/iron-man-is-a-dick.html <comment><USER2> A Lot of commercial products have the functionality there and disabled/locked (Windows is an example and some other cars are just a software update away from higher power) Unlike TFA I don't see any issue with this.

More interestingly it seems Tesla has now set a precedence for any other disaster or has it?</comment>


Build a video platform - <AUTHOR> Anyone interested in contributing in this new video streaming app? <comment><AUTHOR> [https://github.com/stoufa88/lawd-desktop](https://github.com/stoufa88/lawd- desktop)</comment>


BoofCV: Real Time Computer Vision in Java - <AUTHOR> http://www.codeproject.com/KB/library/boofcv_alpha_v02.aspx

<comment><USER2> Beautiful!

When it has a full-blown camera tracker then it can rule _hint_ _hint_</comment>