Make something people need - <AUTHOR> http://jacquesmattheij.com/make+something+people+need <comment><USER2> One person's need is another person's want is another person's "wtf is this? get off my lawn!"...

Need is in the eye of the beholder. I think "Make something people need" really means "Make something some people are willing to pay for". Which is nice, but more niche advice than "Make something people want".

No one wants to pay for Google search. But it's damn useful, and a great thing to have made (and led to business services that businesses need). Conversely, nobody needs any given movie or song or fiction book or game - they are largely commoditised and interchangeable before you've actually consumed them. But making movies and books and other forms of unnecessary art still makes hundreds of billions of dollars of revenues every year.

"Make something people want" applies to more companies than "Make something people need", imho.

<comment><USER3> "But making movies and books and other forms of unnecessary art still makes hundreds of billions of dollars of revenues every year." Everything else being equal, I would not choose these markets. Why? Because these markets are too sexy and too crowded: too much people write games and books out of enthusiasm. (I was one of them.) If you are a game enthusiast, sure create an indie gaming company. But if you somehow can get excited about a business problem which is a pain point for some people, then it is better to choose that imho.

I would say:

Make something people need, and avoid overcrowded markets where a viable business model became problematic (e.g. free is the default) because of oversupply (like tools for professional developers)

</comment></comment><comment><USER4> It's interesting to see that since Jacques left HN his articles seem to dominate the front page whenever he writes one (which I'm quite happy with since I like reading them).

Maybe we're subconsciously trying to make him come back by flooding his server with requests for attention.

</comment><comment><USER5> Just a note: Youtube is now massively profitable.

[http://www.bellinghamherald.com/2011/03/09/1906416/youtube-s...](http://www.bellinghamherald.com/2011/03/09/1906416/youtube- shifts-from-googles-errant.html)

[http://www.wired.com/magazine/2010/03/ff_youtube_5secrets/al...](http://www.wired.com/magazine/2010/03/ff_youtube_5secrets/all/1)

</comment><comment><USER6> What if people don't know what they need or want? Sometimes we try to build or develop something exactly as someone asks. Most of the time, that's exactly what they need; but many times they are wrong: requirements are wrong, even the sense of "need" or "want" is misplaced.

When we are developing something new, a new product or service, software or building, we always try do please people, trying to perceive what their needs or wishes are. But what if they don't really know? As Ford said once "if i asked people what they wanted, they would say 'a more powerful horse'". Sometimes, what people need or want is something that isn't here yet. Maybe we try to much to build something according people's wishes, and the finished product is nothing more than a copy of thousands of solutions made by people who thought the same thing.

I know it may be hard, but to really make a difference, we have to try to stay ahead. Even ahead of potencial customers. Either you're right or wrong, you'll know it soon enough

</comment><comment><USER7> Not so Good: Build it and they will come.

Good: Make something people want.

Better: Make something people need.

Even better: Make something people need and know that they need. If they don't already know, someone will have to help them know. That someone might be you and helping them will take sales and marketing, a significant consideration.

Even better: Make something people need, know they need, and are willing to pay for now. Competing against "we're not ready, maybe next year" is tougher that competing against any competitor.

Best: Make something people need, know they need, are willing to pay for now, and has their hair on fire. Leapfrogging to "let's just solve this problem now" is often the best (and most fun) way to deploy.

[EDIT: In response to some of the replies to this thread: This is _not_ about "guessing what people need", worrying about competition, or assuming "if I need it, others must too". This is about getting up off your butt, talking to people, finding out what they must have, and building it for them. There are people everywhere desperate for solutions to their problems, and I promise you, they're not finding them. Sure, you may scratch your own itch and hope that someone else needs it, but this is a lottery approach. Most start-ups fail because they built something no one else wanted or was willing to pay for.

There is absolutely no better way to find out what to build than finding customers first. Please don't be like me and learn that the hard way. There are great apps everywhere that nobody uses while people suffer because no one is building what they want.]

<comment><USER8> In my opinion, people should stop trying to guess what solves other peoples problems and just solve their own.

Best(er): Make something YOU need and are willing to pay for now.

If you solve your own problem, you're guaranteed to understand the problem, execute well, and be surprised how many other people have the same problem.

<comment><USER9> That's exactly what I'm banking on with the new app I'm developing <http://www.mightycv.com>. I needed a new résumé and didn't like the more generic builders I found out their. I wanted a résumé builder that worked for hackers and integrated easily with HN, github and stackoverflow and so I built one. I really hope that by scratching my own itch I've executed well and made something that others will find useful.

If there's lot's of competition in a particular area then I think it might be a better plan to focus on a niche part of that larger market. Remember facebook was only for college kids to start with.

</comment></comment></comment><comment><USER10> This is very general speaking. Of course, make something people need is good, because you have a nice niche then to sell something, but I think it is not accurate enough. Everything a person needs are 4 walls, a roof, something to eat and someone to love. Lets find a better sentence, something like: "Make something which makes people smile". While it is not catchy like the original sentence, it is a lot more accurate. A secretary will smile when presented with a better accounting software. A lumberjack will smile when given a better axe. A developer will smile when given an awesome new programming language.

Oh, and not to be mistaken, it is totally OK to have these people pay for things that make them smile, Disneyland also takes an entrance fee.

</comment><comment><USER11> "Make people want something you have." is probably also a common strategy.

</comment><comment><USER12> There are very few things that people truly need: food, water, air, arguably shelter. Unless you are a farmer or building houses, you aren't making something that people need. This whole discussion seems a bit silly to me for this reason. Anybody who is building a tech company is building something that people want, not something that they need. Do you really _need_ Amazon or eBay? No, of course not.

</comment><comment><USER13> People don't need fart apps, but they seem to sell well. What gives?

<comment><USER14> Is Angry Birds something I 'need?' Well, maybe for some people I guess.

<comment><USER15> Cheaper than therapy ;) Though arguably one could classify entertainment as a need.

</comment></comment></comment><comment><USER16> This reminds me of quote from Matt Mullenweg (founder of Wordpress): "Be a pill, not a vitamin."

</comment><comment><USER17> Build something you enjoy building.

</comment><comment><USER18> if they need it they want it, if they want it they need it

<comment><USER19> You might need to educate customers about their need. They might need something without knowing it.

<comment><USER18> Then they don't want it.

<comment><USER20> correct. but if you don't know it even exists, how could you need it? especially considering that all startups are just luxury products, since humans don't need anything other than water and food.

<comment><USER21> In many cases we could get into the definition of 'need'.

But consider something like legal/regulatory requirements. Perhaps you don't know about some law at the moment, but you _should_ be complying with it. I have a product that fixes this problem for you. Until I call you, you don't want it but you still need it. When I tell you this, hopefully you'll understand and I have a good chance of a sale.</comment></comment></comment></comment></comment>


Some Useful Probability Facts for Systems Programming - <AUTHOR> https://theartofmachinery.com/2020/01/27/systems_programming_probability.html <comment><USER2> I want to share a trick with you all.

> Because the monster battles are statistically independent, we can make a > rough guess that about 1 in 9 players still won't have a special item after > 20 battles.

From a game design perspective, for some situations this can be a real problem that leads to players getting discouraged and quitting, which leads to loss of revenue. In the games I've made, I've often used a special trick for overcoming this problem. Rather than using plain random numbers, I conceptually use a shuffled deck of cards, where each player receives a different random seed for the shuffle and I maintain state on how many "cards" they've drawn so far. I put one "win" in the deck and some number of non-wins. This way it's still random, but if people keep at it they'll eventually get the thing that they want. With plain raw probabilities, you'll always have a certain number of customers that keep paying to try and keep failing. The random shuffle is a way better way to approach this from a customer service perspective.

This makes it easier to reason about from a game design and customer service perspective. I can say that no player will ever have to go through more than X attempts. I say it's a customer service issue because in many of my games the players feel like there's real money on the line, and so it can literally lead to customer service tickets, wailing, and gnashing of teeth.

<comment><USER3> An additional consideration is that predictability can lead to unintentional gaming of mechanics. For example, there are WoW addons that keep track of your bonus damage RNG trinkets to tell you when your RNG is hot and when its cold so you can optimize when you use some big finisher.

<comment><USER4> This got really bad in World of Warcraft: Legion, when people were deleting and re-creating their characters to try and get better loot.

The game had these "Legendary" items of incredible power you could attain that were insanely rare, but had a sort of "pity timer" where you'd get a higher and higher chance of obtaining one based on how long it'd been since your last item.

The problem is that the legendary items were almost inconceivably rare drops through pure random luck, but the escalating chance was really predictable. You were all but guaranteed to never get a legendary item through pure chance alone, but you were basically guaranteed to get one every two weeks if you did all the time-limited content available. (Dungeon raids you can do once per day/once per week, daily chore missions, etc).

For the first few months of the system's availability, after 4 legendary items you'd no longer get the "pity timer" bonus to your loot rolls on legendary items, so your character was effectively capped at 4 legendary items.

Some of the available items could increase your character's combat effectiveness by a relatively huge margin compared to others, and it only took about a week to power-level a new character and get it one or two legendary items, so for a while people were abandoning their max level, legendary-geared characters with 100+ hours invested into them to try again.

<comment><USER5> Speaking of WoW, I got hit by the statistics when they introduced an achievement for the in-game valentine's holiday.

Each player got a bag that you once an hour could take a random piece of heart candy from. There were a fixed number of heart candies, the bag worked for a week, and you needed one of each to get the achievement.

One random draw once an hour for at max a week is a limited number of attempts, what are the odds of never getting a certain heart piece? About one in a million or so. How many players did WoW have at that time? Over ten million. So you're pretty much guaranteed that even if you never missed an opportunity to draw a piece of candy, some players would never get one of each, and never get the achievement... Statistics is a bitch.

(They implemented pity timers for every similar achievement afterwards, as far as I know.)

<comment><USER6> > what are the odds of never getting a certain heart piece? About one in a > million or so. How many players did WoW have at that time? Over ten million. > So you're pretty much guaranteed that even if you never missed an > opportunity to draw a piece of candy, some players would never get one of > each, and never get the achievement...

This extends the time to get the achievement from one year to "for 0.0001% of players, two years".

That will annoy those, um, ten people, but "getting the achievement next year" is pretty different from "never getting the achievement".

<comment><USER5> Yeah, because the achievement was part of the meta-achievement What A Long Strange Trip It's Been, and if you were one of those ten people, like me, it was pretty damn annoying. (There were actually quite a lot more of us, since very few people drew the maximum amount of candies from the bag, so the realistic odds of never getting it despite your best efforts was maybe one in 100k or something?

Anyway, they fixed it retroactively for the first year somehow, so that was nice.

<comment><USER6> > Yeah, because the achievement was part of the meta-achievement What A Long > Strange Trip It's Been

This severely _weakens_ the case that it was a problem that needed to be fixed; if you're getting the Valentine's achievement because you want What A Long, Strange Trip It's Been, the extra waiting time you suffer from not getting Valentine's the first time around is lowered. (Because you would have had to spend a lot of that time waiting anyway, for the other calendar-based achievements that you didn't already have.)

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Birthday paradox is way too important to omit from this list!

For example if you're uploading stuff to a bucket, you can compute its hash first to figure out if a duplicate already exists and if so, skip the upload.

Why can you do this? What if it was just a hash collision? Shouldn't you still compare the contents to _really_ make sure they are the same?

Turns out if your hash function is N bits you will need to have 2^(N/2) items before you see two hashed to the same thing by chance. If you choose a 256 bit cryptographic hash function like SHA256, that's 2^128. This probability is so low you have a higher chance of encountering a cosmic ray bit flip!

[https://en.wikipedia.org/wiki/Content- addressable_storage](https://en.wikipedia.org/wiki/Content- addressable_storage)

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

<comment><USER8> > _Turns out if your hash function is N bits you will need to have 2^(N /2) > items before see two hashed to the same thing by chance._

No no no. That's not how probability works. You will see that many on average, but you don't " _need to_ " anything before you can see a collision. You could get collisions on the next 100 files. It's just unlikely. The bitspace bounds the denominator of match probability for each file independently, it does not count files. Unlikely events happen all the time _somewhere_.

<comment><USER7> The precise statement is that you need to have O(2^(N/2)) items before the _probability_ of finding a hash collision is greater than 50% (or whatever nontrivial percentage). English is hard and I think whoever cares about the details can look it up themselves.

<comment><USER8> > _I think whoever cares about the details can look it up themselves_

Your statement was an incredibly common and often repeated misperception of probability and circumstance. Someone looking it up for themselves, as you suggest, is more likely than not to encounter dozens of wrong statements on the subject before they ever find a right one. I think it behooves us to not add more misinformation to the pile.

</comment></comment></comment></comment><comment><USER9> A missed opportunity: the balls-and-bins discussion didn't go on to discuss the power of two choices.

In short, if you're tossing N balls randomly into N bins, you should expect the most heavily loaded bin to get log N of the balls.

If instead you "toss" by choosing two random bins and then putting the ball in the one with fewer balls, you should instead expect the most loaded bin to get only log(log N) balls.

In practice, it's often not so hard to modify the first strategy into the second to get dramatically more uniform load distribution among bins.

[http://www.eecs.harvard.edu/%7Emichaelm/postscripts/handbook...](http://www.eecs.harvard.edu/%7Emichaelm/postscripts/handbook2001.pdf)

(You might ask, if two choices are good, are three better? Yes, but only slightly. You get an exponential improvement going from 1 to 2; after that, testing more bins improves by constant factors.)

<comment><USER10> > _You might ask, if two choices are good, are three better? Yes, but only > slightly. You get an exponential improvement going from 1 to 2; after that, > testing more bins improves by constant factors._

The intuitive explanation for this is that the largest benefit comes from avoiding the most full bin. Two choices is always sufficient to do that.

</comment></comment><comment><USER11> Another one to add: if N is big enough, even statistically improbable events like single bit flips in memory become likely or even nigh-certain. For example, if you set up a bunch of fake domains that differ from real domains in a single bit, you might get upwards of a dozen hits _per day_ from clients clearly trying to reach the real service - this is called Bitsquatting: [http://dinaburg.org/bitsquatting.html](http://dinaburg.org/bitsquatting.html)

For example, setting up the server "mic2osoft.com" (a one-bit-flip error from microsoft.com) yielded this request:

        msgr.dlservice.mic2osoft.com 213.178.224.xxx "GET /download/A/6/1/A616CCD4-B0CA-4A3D-B975-3EDB38081B38/ar/wlsetup-cvr.exe HTTP/1.1" 404 268 "Microsoft BITS/6.6"

This is a machine trying to download some kind of update package _from the wrong server_ because somewhere in its memory the "r" from "microsoft.com" got flipped to a 2 (0x72 -> 0x32).

<comment><USER12> Is it possible someone typed that in manually?

</comment></comment><comment><USER13> Worth mentioning is the The Waiting Time Paradox:

"When waiting for a bus that comes on average every 10 minutes, your average waiting time will be 10 minutes." And worse "when the average span between arrivals is N minutes, the average span experienced by riders is 2N minutes."

These realizations about Poisson distributions have a lot of real-world implications such as packet traffic, call center calls, etc.

\- [https://jakevdp.github.io/blog/2018/09/13/waiting-time- parad...](https://jakevdp.github.io/blog/2018/09/13/waiting-time-paradox/)

<comment><USER14> For some reason this is the post that took me back to a EE numeric analysis and stats practical exercise nearly 40 years ago. A friend encounters a miserable looking me standing on the street with a clipboard and a stopwatch. Friend: "What the hell are you doing?". Me: "Testing the hypothesis that passing traffic is Poisson distributed".

</comment></comment><comment><USER15> My favorite of such applications of probability is the Poisson stochastic arrival (get _arrivals_ at discrete points in time) process. There are two amazing, powerful, useful, non-obvious biggie points:

(1)Axiomatic Derivation

As in

Erhan Çinlar, 'Introduction to Stochastic Processes', ISBN 0-13-498089-1.

an arrival process with stationary (distribution not changing over time) independent (of all past history of the process) increments (arrivals) is necessarily a Poisson process. So there is an arrival _rate_ , and times between arrivals are independent, identically distributed exponential random variables.

Often in practice can check these assumptions well enough just intuitively.

Then as in Çinlar can quickly derive lots of nice, useful results.

(2)The Renewal Theorem.

As in

William Feller, 'An Introduction to Probability Theory and Its Applications, Second Edition, Volume II', ISBN 0-471-25709-5,

roughly, with meager assumptions and approximately, if the arrivals are from many different independent sources, not necessarily Poisson, then the resulting process, that is, the sum from the many processes, is Poisson.

E.g., using (2), between 1 and 2 PM, the arrivals at a busy Web site, coming from lots of independent Web users, will look Poisson and from (1) can say a lot for sizing the server farm, looking for DDOS attacks, security, performance, network, and system management anomalies, etc., e.g., do statistical hypotheses tests.

Similarly for packets on a busy communications network, server failures in a server farm, etc.

<comment><USER16> Indeed, poisson processes are surprisingly common in networking.

</comment></comment><comment><USER17> We can all use excellent reminders like this about how random outcomes can be distributed really unevenly.

For example, attributing even _some_ success to randomness (a reasonable assumption, I would think) at least N fraction of successful people you see in life are just lucky! If 1000 people flip a fair coin 10 times, there's a really good chance (60%+) someone gets 10 heads in a row!

Optimize your existence as you see fit with that information! Generate more N, spend more time with your family, try to move the needle on the amount of randomness that contributes to your personal definition of success, etc.

<comment><USER18> > Optimize your existence as you see fit with that information!

That sounds very intriguing, yet I don't really have an aha!-moment. Care to give an example or two from your personal experience?

<comment><USER17> Sure.

I quit a job that put me in the top 5% of salaries to do something I loved that gave me more time outside work, because I realized the woman I share my life with was my "ten heads in a row" and not the job that depressed me.

Another example is that rather than sinking my time into one project, one hobby, one organization, I tend to jump around a lot. That isn't to say I am constantly in that state, I've just learned that eventually the coin will flip heads and I'll be working with great people on something really interesting that is worth my time to go deep. "Worth" here, not necessarily being financial. It might be educational, or a cause I'm passionate about. Or fun. This optimizes for N.

<comment><USER17> Also moving from law to programming, I changed the effect of randomness on my success.

In law, I could kick ass, and still lose a case, because of many things that are likely to be depressing to list in public.

In programming, if I kick ass, it deterministicaly leads to something that works! That _is good_. Sure there is politics and popularity and all those normal human problems too, but those same problems existed in law, so I'm not losing anything there.

</comment></comment></comment></comment><comment><USER19> However million-to-one chances crop up nine times out of ten. [https://wiki.lspace.org/mediawiki/Million-to- one_chance](https://wiki.lspace.org/mediawiki/Million-to-one_chance)

<comment><USER20> My favourite quote from the series. He was such a great author.

</comment></comment><comment><USER21> Thank you for posting this, the explanations are intuitive and the real-world examples really help one think about the implications of these probability facts.

</comment><comment><USER22> An easier almost-proof of the N trials with 1/N chance bit uses the approximation log(1+x)~=x for small x.

See: let's find what is Q such that Prob(no successes in M trials)~=Q. This is:

(1-(1/N)^M ~= Q

therefore

M log(1-1/N) ~= loq Q

Using the approximation,

-M/N ~= log Q

that is

exp(-M/N) ~= Q

M=N yields the result.

Now, if we slightly change the problem so Q is a probability threshold such that Prob(no successes in M trials)>Q, we get an exact statement: since x>log(1+x) exactly, -M/N > log(1-1/N) > log Q.

</comment><comment><USER23> Not exactly related with the content of the article, but I was also reminded of the German tank problem: [https://en.wikipedia.org/wiki/German_tank_problem](https://en.wikipedia.org/wiki/German_tank_problem)

</comment><comment><USER24> This was a great and readable explanation!

Also it was a great example as to why you should never use "random" as your load balancing algorithm unless you plan to always have 1/3 extra capacity.

Or conversely why you should always have 1/3 extra capacity if you must use random.

<comment><USER25> That condition is only met if you send N requests to N routers. If you send 1,000,000*N requests to N routers, they will almost always be evenly distributed.

<comment><USER24> But then you're under capacity. The assumption is that it takes N servers to service N requests simultaneously.

</comment></comment></comment><comment><USER26> In the same line, some of you might be interested on the slides for my Probability webinar:

[https://drive.google.com/file/d/1qz4wAmwiKadshhrStxcz-8atb0S...](https://drive.google.com/file/d/1qz4wAmwiKadshhrStxcz-8atb0SFcfQ6/view)

where I try to go from the very basic to some useful applications (like Bayes theorem, A/B testing).

You can also subscribe to my newsletter: [https://data4sci.com/newsletter](https://data4sci.com/newsletter) where I also announce future webinars, live tutorials and trainings, etc.

</comment><comment><USER27> All these examples (in the article and in the comments here) shatter my mind. I don't find it intuitive and even after reading the explanations I feel like there's something I'm not getting. I'd attempt a marathon to be conversational in probability theory.

<comment><USER28> Probability is incredibly non-intuitive! If you're willing to run a marathon to become more conversant in it, spend the ~4-5 hours to run marathon on this course: [https://projects.iq.harvard.edu/stat110/home](https://projects.iq.harvard.edu/stat110/home)

<comment><USER27> Thanks for the link!

</comment></comment></comment><comment><USER29> In a lot of computer games that use probability game developers will actually use pseudo-RNG, or other means to deceive players about what their actual chances are because otherwise the game will seem "unfair" to a segment of players.

<comment><USER30> some examples of what you mean?

<comment><USER31> Dota 2 definitely does this for a lot it's RNG. For example, your chance of critically hitting increases whenever you don't critically hit.

[https://dota2.gamepedia.com/Random_distribution](https://dota2.gamepedia.com/Random_distribution)</comment></comment></comment>


Uber's quarterly losses jumped nearly 40 percent to $1.46B - <AUTHOR> https://www.recode.net/2017/11/28/16713430/uber-losses-softbank-stock-third-quarter <comment><AUTHOR> Choice snippets:

> "The U.S. is very, very competitive right now between us and Lyft, so I > don't see the U.S. as being a particularly profitable market for the next > six months," Khosrowshahi said.

(Recall that previously, Travis said that Uber was profitable in the US [1].)

> The company's net revenue for the third quarter was $2 billion, up from > $1.66 billion in the previous quarter.

Which means that net revenue grew only about 20% in Q3.

[1] [http://fortune.com/2016/02/18/uber-profitable- us/](http://fortune.com/2016/02/18/uber-profitable-us/)

</comment><comment><USER2> IIRC they also increased the salary for many employees to make sure pay was fair across the company.</comment>


A mechanism for calculating your trust of an individual - <AUTHOR> This is an idea that's been on my mind for a couple of years.
Something reminiscent of PageRank, but for individuals, as in propagating trust. I trust B, and B trusts C, and as such, C is trustworthy to some extent.
There are several aspects of trust, I guess. Like accountability, correctness of memory, moral character (could be deterred by some forms of law violations?) ... dunno if that is relevant, though. Maybe only the intuitive meaning of "trust" is enough.
There is no universal trust, all goes back to you trusting "seed individuals", that in turn trust other people.
Maybe a scale of 0-11 will determine your trust of an individual, so that you can get "circles" of trusted individuals. Maybe you need negative trust, or maybe that is what 0 is for, effectively shutting down that individual in your trust graph.
But, other individuals may not trust the one who is zero-ing that individual, and may trust him.
If implemented as an app, to verify that you are a trusted individual in whatever context (maybe when starting a company), you bring up your app, and it shows a QR-code.
You scan it with your app and your trust of that individual is calculated.
Maybe this whole concept is defeated by counterfeiting? Just screenshotting that QR-code makes you copy that individual ... But then again, copying someones ID is just as problematic.
Any thoughts? <comment><USER2> First of all, one should define what one intends by "trust". The best definition I have ever come across is that A 'trusts' B if B can hurt A but A feels safe disregarding this prospect.

<comment><AUTHOR> Well, this mechanism could be used by governments, for example "Should we let this individual create an LLC within our legislation" or by some village-like communities as in "Is this individual safe to let live here".

As in both comprises the fact that letting B possibly hurting A (being the community, or an individual, or the government) by letting him to X.</comment></comment>


Apollo Client 1.0: A flexible, community-focused JavaScript GraphQL client - <AUTHOR> https://dev-blog.apollodata.com/apollo-client-1-0-a-flexible-community-focused-javascript-graphql-client-2253b90e6c84 <comment><USER3> We use Apollo for the [http://expo.io/](http://expo.io/) client and have found it to be extremely pleasant to use. I love how flexible it is too -- you can use it for weird things like building an ORM layer for SQLite. For example: [https://github.com/brentvatne/apollo-sqlite- experiment/blob/...](https://github.com/brentvatne/apollo-sqlite- experiment/blob/master/src/App.js) \-- the queries here go through a custom NetworkInterface which use a pretty simple graphql resolver ([https://github.com/brentvatne/apollo-sqlite- experiment/blob/...](https://github.com/brentvatne/apollo-sqlite- experiment/blob/master/src/resolver.js)) built on graphql-anywhere to pull the data out of the DB.

<comment><USER4> What is the expo.io client? The site you linked has a broken certificate and then just replies "default backend - 404".

<comment><USER5> Works fine for me. Check your computer for viruses.

<comment><USER6> This comment is an interesting instance of Poe's law.

</comment></comment></comment></comment><comment><USER7> It's been a bit, but I found the ergonomics and flexibility of Apollo to be miles ahead of Relay.

I also found it fairly straightforward to set up Server Side Rendering (SSR). My example is at [https://github.com/rattrayalex/isomorphic-react-relay- router...](https://github.com/rattrayalex/isomorphic-react-relay-router- koa/blob/master/frontend/server.js) if it helps anyone, though it's a year out of date.

EDIT: A more up-to-date example at [https://github.com/rattrayalex/django- graphql-react-ssr/blob...](https://github.com/rattrayalex/django-graphql- react-ssr/blob/master/frontend/koa-apollo-redux-react-ssr/index.js) – meant to open-source it as a simple SSR lib.

<comment><USER8> Interesting. I haven't used Apollo in production. Are there specific things (apart from mutations!) that it makes easier?

<comment><USER9> Mutations are much simpler. Cache updating is flexible and easily customised. They have subscriptions and polling. Fetch More for pagination. Generally clear and flexible to work with

</comment></comment></comment><comment><USER10> I've just started working on a graphql project now and from the frontend perspective its phenomenally better than a rest api. The backend side of things is also pretty simple so I'm really enjoying it.

With Rest APIs there's always the problem (with numerous solutions) of how you select the particular fields and how you nest and or do not nest the resources in the api. With GraphQL this is more or less a non-issue - the client just requests want he wants and gets it back if he's allowed access to it.

I know GraphQL has been around for a while but this has been my first full go with it and I could easily forsee it doing to REST what REST did to SOAP - <USER2> least for the use case of building frontend clients that consume some api.

<comment><USER11> I'm kind of hoping that nesting resources becomes a non-issue in the future once HTTP/2 is widespread. Ideally you don't ever nest resources. With HTTP/2 the overhead of additional requests can be significantly lower, and you get the benefit of using client cache.

This becomes pretty powerful once cache digests land, so a HTTP/2 REST service can just proactively push only the resources to the client that it has an (up- to-date) copy of.

Nesting resources is a bit of an anti-pattern imho, and the solution looks bad because it's a poor fit in the protocol.

Of course, all of this is a bit of a moot point if you don't believe in addressable/linkable resources as a good solution. If you're not doing/believing in hypermedia in REST, you're much better off with something like GraphQL because it provides a very complete solution. You just need a ton of domain knowledge to be successful at proper REST.

<comment><USER12> HTTP/2 doesn't fix the problem of loading data dependencies over a connection with a noticeable round trip latency. Even with server push, you need some way of defining what is to be pushed.

As a very contrived example, one page might show users who have access to servers in availability zones in aws regions. With an unnested rest api doing nothing intelligent with server push over a 250ms round trip, you're looking at a second of overhead just for sending ids back and forth.

Of course, there are ways of defining inclusion that are closer to restful than graphql is.

<comment><USER13> Falcor sort of solves this by allowing you to communicate "references" in the graph. For example, it might inform you that users.52.friends.1 is actually users.45, so the client will cache it at that location instead.

This is less complicated than GraphQL's solution of using the Relay Node interface.

<comment><USER12> Relay and GraphQL aren't the same beast. One of the reasons to choose Apollo is to avoid the extra complications which Relay adds.

</comment></comment></comment></comment></comment><comment><USER14> This is not a knock on Apollo in particular, but I am wholly underwhelmed by what gets hyped up in this industry. There isn't anything novel here. A new generation of programmers rediscovers Remote Procedure Call (they call them mutations), schemas (NoSQL was so last year), and various older concepts and rehashes it while putting down a strawman they claim is Representational State Transfer (which if they read the thesis, they would realize that their concerns are nitty gritty details which are only tangentially related to the architecture described).

Also the community-focused angle is disingenuous. It's backed by venture capital of the Meteor Development Group and based upon a single vendor specification, GraphQL by Facebook.

<comment><USER15> Many great open source products have huge commercial backers--the important thing is that there is a community, which is in fact very true with Apollo.

I get what you're saying and I'm sure there is lots of truth to it--that doesn't make what's going on now the best to ever do it (i.e. the fastest way to produce the most meaningful user experiences). If it wasn't the case, we'd be doing remote procedure calls in C or whatever.

Bottom line: ur point is one that should be heard, but there's a way more value could be added in how you present it.

</comment></comment><comment><USER16> GraphQL and Apollo literally saved our app. Before we made the switch, we were plagued with issues from other providers such as technology stack compatibility issues, queries making issues and more.

We actually made the decision to switch to GraphQL 1.5 weeks prior to deadline and was able to get configuration and queries going in almost no time at all. I know I sound like a commercial right now but it seriously was very easy to setup and the querying learning curve was minimal.

The console is easy to use and the combination of the Playground with Mutation Callbacks helped me to setup and test my first AWS Lambda function of which I was able to do within 2 days and the AWS learning curve is not so easy to absorb.

Aside from all of this, the Graphcool team was very helpful and right there when we needed them whether on chat in the console or on Slack.

</comment><comment><USER17> Huge congrats to the amazing team at Apollo! :)

We at Graphcool ([https://www.graph.cool](https://www.graph.cool)) are super excited about this release as the majority of our customers are building their apps with Apollo Client.

A few months back we launched Learn Apollo ([https://www.learnapollo.com/](https://www.learnapollo.com/)) here on Hackernews which so far has helped thousands of developers to get started with Apollo. (HN Link: [https://news.ycombinator.com/item?id=13187431](https://news.ycombinator.com/item?id=13187431))

For people just starting out with Apollo: With tools like graphql-up ([https://www.graph.cool/graphql-up/](https://www.graph.cool/graphql-up/)) it's super easy to get a GraphQL API for your Apollo apps. We're looking forward to contribute more to Apollo and its ecosystem going forward!

</comment><comment><AUTHOR> Hey, Sashko from the Apollo team here - we're excited to keep improving Apollo Client and build more awesome tools for GraphQL development! If you're excited about this space and want to work on open source and also commercial products for GraphQL, we're actively hiring for a variety of positions: [http://jobs.meteor.com/](http://jobs.meteor.com/)

<comment><USER18> Hi Sashko. I have been working a few years ago on a visual query builder for SPARQL. (Cf datao.net) May be you can find some inspiration for visual tools on top of graph query languages.

Cheers...

</comment></comment><comment><USER19> Sashko and Jonas from the Apollo team were guests on JAMstack Radio this week, it's a great primer if you're just getting into Apollo+GraphQL [https://www.heavybit.com/library/podcasts/jamstack- radio/ep-...](https://www.heavybit.com/library/podcasts/jamstack- radio/ep-11-exploring-graphql-through-apollo/)

</comment><comment><USER20> Congrats to the Apollo Team and contributors for all the awesome work that went into this release. The majority of our customers at Scaphold ([https://scaphold.io](https://scaphold.io)) are using Apollo to power their applications with amazing results.

We're excited to keep working to push the limits of GraphQL by supporting awesome features like subscriptions, persisted queries, and much more!

If you're in SF come to meteor tonight for the GraphQL meetup and let's talk about what's coming next.

</comment><comment><USER21> I just started diving into using Apollo client the an Elixir backend (using Absinthe). It's an amazing combo! I look forward to more releases from the Apollo team.

<comment><USER22> Absinthe is pretty nice, I wish their docs were a tad bit more full-featured (more examples, perhaps?)

</comment></comment><comment><USER23> Have really enjoyed using Apollo Client with React, Redux and Redux Saga. It plays very well with TypeScript too.

<comment><USER22> Interesting I'll need to look into how well the Apollo Client plays with Redux and Redux Saga since I'm using them in my stack. I had assumed that it was more "apollo-focused" and thus wouldn't play nice.

</comment></comment><comment><USER24> Using apollo with react native has been a great experience. works well with react navigation and graph.cool as well. Only thing I would improve is the subscription features. Feels kind like theres a lot missing in subscription to customize depending on application. Like applyMiddleware and other hooks .

</comment><comment><USER25> I've been using GraphQL with Apollo and Absinthe/Phoenix for a civic data gerrymandering project. Fantastic combo and everything plays well together. Certainly looking forward to using this stack on something big and bad in the near future.

<comment><USER26> Interesting. I'm considering building a graphql service using Absinthe. Could you give more information on your experience? Any difficulties?

<comment><USER27> Not GP, but I've been using it for the last several months and overall its been incredibly pleasant to work with. Bruce Williams and Ben Wilson have done a fantastic job with the API, and they are incredibly helpful on the slack channel. Its basically replaced Phoenix for most of my needs, which isn't a design goal of theirs—it just works out that way.

There's a few areas the guides are a little sparse, but the API docs are pretty solid. That will improve over a little more time. There are some areas like returning errors to the client that are sort of roll-your-own in the graphql community at large, but those kinds of things for me have come down to just finding a practice that works for me and going with it. I haven't had a chance yet to upgrade to the latest version, which supports middleware and subscriptions, along with stuff I _think_ was already supported like transport-level batching.

My advice if you're thinking about using it is to build out a basic set of features with it and expand your usage—you'll find out pretty quick if you like that modality, and apollo makes a great combo with it if you do.

</comment></comment></comment><comment><USER28> After much time wrestling with Apollo, I found it was much easier to use Fetch API than use Apollo client. It took me an afternoon to roll my own client with Fetch after several days trying to figure out why Apollo wasn't doing what I wanted. Note we were using a .Net implementation of GraphQL on backend.

Now working with GraphQL in production, I would NOT recommend using it, especially if security is a concern. We're now implementing persisted queries, which means we call a query ID and return a predefined query/mutation. This essentially turns GraphQL into something like a Rest endpoint.

GraphQL was fun to use in the building stage and did make things easier to me as a front end developer. But as we made iterations on our schema and application, I think GraphQL added more work because there were so many more details to manage in the queries.

</comment><comment><USER29> I'm about to start re-writing an api as GraphQL, I'm looking at the comments of support for Apollo, and looking at their webpage, but I'm failing to see what the real benefit is.

What is the problem with GraphQL that they are addressing?

<comment><USER30> Apollo Client doesn't solve problems _with_ GraphQL, it provides a client _for_ GraphQL.

<comment><USER29> Thanks Jives, but that still doesn't really help, does it? GraphQL from a client side are just json requests/responses, right? Am I missing something else?

</comment></comment></comment><comment><USER9> The Apollo extension for Chrome is also awesome. It needs to display errors better but it is already very essential.

<comment><USER9> [https://chrome.google.com/webstore/detail/apollo-client- deve...](https://chrome.google.com/webstore/detail/apollo-client- developer-t/jdkknkkbebbapilgoeccciglkfbmbnfm)

</comment></comment><comment><USER31> I tried integrating Apollo with my Redux app a few weeks ago but found it very confusing, so I just made my Redux app work with my GraphQL Rails backend without Apollo.

</comment><comment><USER32> I've used Apollo with [http://graph.cool](http://graph.cool) and it's been pretty good so far. The folks at graph.cool are very responsive and have good documentation - filling in holes where Apollo has been lacking. Often times if you run into a gap or a mystery with Apollo - the graph.cool guys will answer the question while the stackoverflow question will languish a bit.

</comment><comment><USER33> I'm using Apollo with [https://www.graph.cool](https://www.graph.cool), and for me as mainly a frontend developer, it has been absolutely great so far. I've used both Relay and Apollo quite extensively in the past, and while both have their pros and cons, I do enjoy working with Apollo right now. Apollo had the added benefit of existing for several platforms in roughly the same way, so I've had the pleasure of using Apollo with both React and Angular 2. Great work!

I just got to plug graph.cool too for people interested in GraphQL and Apollo. I've been using it for quite a while, and the platform has been working great. I've been chatting quite a lot with their support (hey Nilan if you see this ;)) and they've been very helpful both in matters concerning the platform, but also for my app and GraphQL in general. I really recommend trying it out!

</comment><comment><USER34> I'm in total love with Apollo Client! I'm using it at work with a custom graphql backend and on personal projects using [http://graph.cool](http://graph.cool) which just rocks! I hope the community will grow with people who use angular with apollo-angular as well.

</comment><comment><USER35> I've been using Apollo now for the last month or so, in production and I have to say that it's been a fantastic tool to work with. The community and the team behind it are also second to none out there; hugely friendly and incredibly helpful. Check out their Slack channel if you run into any issues!

</comment><comment><USER36> How awesome is the expo example on [http://dev.apollodata.com/](http://dev.apollodata.com/) ... I just tried it on my iPhone. Freaking amazing how well it works. Mobile app development has come leaps and bounds from where it was a year ago.

</comment><comment><USER37> Can anyone compare use of Relay + Apollo? I've used Relay extensively but never tried Apollo.

<comment><USER38> +1. If anyone has tried both, please share your experience!

<comment><USER39> Relay has some nicer ergonomics when it comes to composing queries from fragments for different components, and the mutation behaviour is a bit more "magic", but both of these benefits come with some serious restrictions on what you can do. The next version of Relay looks like it'll do away with this approach, bringing it closer in line with how Apollo does things right now.

I'm a heavy user of Relay (been using it since it was first open-sourced around 18 months ago), but given that it's going to be changing quite a bit in the near future, I think newcomers to GraphQL are going to be better off with Apollo for now.

<comment><USER38> Thanks. Yes I too am using soon-to-be classic Relay. I've enjoyed transitioning to Relay.GraphQLMutation and can't say I miss the fat query. So Relay "modern" will be like Apollo... interesting.

</comment></comment></comment></comment><comment><USER40> I tried Apollo on my new personal project (in combo with Next.js as backend framework and Graph.cool as a graphql server(because I'm lazy to set up my own and of some additional featues)) - so far it is the best stack for me. you can check the repo here [https://github.com/alexedev/scz](https://github.com/alexedev/scz)

</comment><comment><USER41> Can we use Apollo with Meteor seamlessly now. Meaning is it production-ready to use? I like Meteor's reactivity so so much.

<comment><USER42> I am wondering the same thing. I believe they wanted to appeal to the broader JS community first, then build in reactivity to Meteor. That is the only reason why I haven't picked it up yet.

</comment></comment><comment><USER43> I recently started making an app with the combination of Apollo Client and Scaphold ([http://scaphold.io](http://scaphold.io)), and I can't get over how easy it is to rapidly built an app.

The combo has taken all the pain of backend development out of the picture. Awesome to see GraphQL take off.

</comment><comment><USER44> I'll second Jonas in being amazed and humbled by the GraphQL community. There is just so much great stuff going on right now. Apollo is doing great work and we use the Apollo Client for most of our examples at Graphcool.

I'm happy to answer any questions about the GraphQL ecosystem as well as how it might fit for your specific use case.

<comment><USER45> First, a huge congratulations to the Apollo team! You have more than delivered on the original promise of the Meteor group.

I am really excited about the proliferation of GraphQL APIs as they replace standard REST endpoints! When I heard that GitHub released a beta of their API with a GQL endpoint, I immediately wanted to try it out.

I learned, however, that it is extraordinarily difficult to connect to multiple GQL endpoints with a single Apollo client. I cannot even imagine how that would work. Should a single GraphQL endpoint have "clients" of its own, through which it could proxy requests to other endpoints? Should the front-end application have multiple clients, each with its own endpoint? There are a lot of easy, inelegant solutions which come to mind.

Several GitHub issues reference similar ideas, but there is no clear solution. Do you have any thoughts about how an application can conceptually replicate the simplicity of REST requests to multiple & diverse endpoints, when the endpoints are GraphQL-structured?

</comment></comment><comment><USER46> Hopefully a GraphQL server can't be far behind.

Edit: I guess you do something like this: [https://github.com/RisingStack/graphql- server/blob/master/sr...](https://github.com/RisingStack/graphql- server/blob/master/src/server/schema.js)

<comment><USER47> The Apollo team also provides some superb GraphQL server tooling:

[http://dev.apollodata.com/tools/](http://dev.apollodata.com/tools/)

The ability to express your schema in GraphQL instead of JS is especially nice. The server+client Apollo experience is really nice if you give it a try, and judging by the roadmap laid out in the blog post there are a lot of benefits to come.

</comment></comment><comment><USER48> Love the momentum of graphql.

Anyone use graphql with fire base? I'm curious on the use cases.

I did a test project in react native with fire base and it felt like early days of Meteor. Apollo's architecture may or may not conflict with firebase in an app. Anyone have some insights?

</comment><comment><USER49> The amount comments from 1 day old accounts in this thread advertising graph.cool is silly.

</comment><comment><USER50> I have been working on a project using Apollo and React for both web and native and it has been a real pleasure. Apollo + graphql has made so many things that would have been a huge mess with redux and a rest api so much easier and cleaner.

</comment><comment><USER51> I love graphQL and Apollo's React work flow that mimics Redux's HOCs. The addition of it probably increased the maintanablity of my apps 5x. Added bonus, I found a backend as a service that that works perfectly with Apollo. Graphcool has increased the maintainability of my app ten fold. I no longer mess with writing my own reducers for the backend. The Graphcool community is also great; they are very helpful on slack and put out a ton of content on top of there great docs.

Watch this video; if you already use graphQL you'll be hooked on Graphcool:

[https://m.youtube.com/watch?v=5uxq8Om- AZQ](https://m.youtube.com/watch?v=5uxq8Om-AZQ)

Here's the code:

[https://github.com/graphcool-examples/react-apollo- auth0-exa...](https://github.com/graphcool-examples/react-apollo- auth0-example)

<comment><USER22> This almost sounds like an advertisement.

<comment><USER52> I'd like to see more of the comments in here actually discussing an honest assessment of the trade-offs when compared to other approaches.

</comment></comment></comment><comment><USER53> It's sad that we have to start asking this again of open source software, and I'm glad to see a normal MIT licence on the Apollo code itself, but is this in any way encumbered by Facebook's unpleasant PATENTS file?

</comment><comment><USER54> I've started on programming early this year as a new year resolution, the tutorials on apollo and the help from Graph.Cool comunity alowes me to learn so much... really excited for whats to come...

</comment><comment><USER55> Off topic, but I noted the coincidence of releasing Apollo Client 1.0 a few weeks after the 50th anniversary of the Apollo 1 accident... I'll read that as a tribute...

</comment><comment><USER56> We've been working a lot with Graph.cool recently in conjunction with Apollo. It's a powerful combination and each day we are learning of powerful ways of working with our data. Our data is going to be heavily dependent on the relationships we build between each model. All very exciting. Easier now to build apps on both web and native that share their data.

</comment><comment><USER57> using graph.cool ([https://www.graph.cool/](https://www.graph.cool/)) it save me the need to write backend, this is not just code writing but also API design which is hard and changing, so I can iterate on the client code and redesign and I don't need to iterate on the server the server is just there and I know it is ready to whatever I need on the client, graph.cool integration with Algolia and Auth0 also work fine for me and allow me to complete my MVP along a development happy path, all high-quality component I grab into my stack with minimal integration effort

</comment><comment><USER58> Using Angular 4 + Apollo + Graphcool has been the easiest alternative so far to use Graphql with Angular.

</comment><comment><USER59> Awesome,

Shameless plug we just released our app today that would not be possible if it weren't for Apollo.

If you're interested in exploring fashion, check out Nelo on the app store:

[https://itunes.apple.com/ca/app/nelo-shop-tv-fashion-and- dre...](https://itunes.apple.com/ca/app/nelo-shop-tv-fashion-and-dress-like-a- star/id1139675415?mt=8)</comment>


The Genealogy of Eliza - <AUTHOR> http://elizagen.org/

<comment><USER2> tl;dr to try eliza:

1) Install SBCL.

2)save this file: [https://raw.githubusercontent.com/jeffshrager/elizagen/maste...](https://raw.githubusercontent.com/jeffshrager/elizagen/master/coselleliza1969and1972.lisp)

3) run sbcl in your terminal ($ sbcl)

4) paste "(load (compile-file "coselleliza1969and1972.lisp"))", after the star

5) enjoy computing history!

<comment><USER3> I'm one of the folks who transcribed it from the scans and added the compatibility glue. One bug remains: The original doctor answered as soon as you ended a sentence with a period ("PLEASE TERMINATE INPUT WITH A PERIOD OR A QUESTION MARK."). In the resurrected version you also have to press the return key. It breaks the immersion, but I couldn't find a way to implement the correct behavior in a portable way.</comment></comment>


The 1955 Citroën DS Still Feels Ahead of Its Time - <AUTHOR> https://www.youtube.com/watch?v=t76fnNGiFhQ <comment><USER2> Is it possible to buy a Citröen car in US?</comment>


Ask YC: is it ok to make an iPhoto-like iPad app? - <AUTHOR>

Or would that not be acceptable according to Apple? <comment><USER2> You can make any app you like. It wont get into the app store if it duplicates functionality provided by Apple.</comment>


JavaScript web apps considered valuable - <AUTHOR> http://molily.de/javascript-web-apps/ <comment><USER2> This is what I tell potential customers that are evaluating our product that creates single-page web applications where the JS dynamically creates all content: if you want search engines to crawl the content, then you're not using the right product. It's a surprisingly easy decision when viewed in those terms. Most SAAS products that likely would be implemented as SPAs do not care about public search engine access, and are only used by B2B customers where you can dictate a certain minimum standard in terms of browser versions (IE).

Everything else should be a traditional static web site with "decorative" JS, or "progressive enhancement".

<comment><USER3> Google can and does crawl Javascript driven web apps. Last year they even deprecated the AJAX crawling scheme that they used to recommend on the basis that they can now crawl web apps: [https://googlewebmastercentral.blogspot.co.uk/2015/10/deprec...](https://googlewebmastercentral.blogspot.co.uk/2015/10/deprecating- our-ajax-crawling-scheme.html)

<comment><USER2> Yes, but in the case of SAAS apps, what exactly are they crawling (if allowed) ? In our case, it would be a bunch of edit controls, grids, buttons, containers, etc. that don't really make a whole lot of sense in the context of a search engine.

I think it's important to start recognizing that there's two distinct types of web "applications" starting to emerge: the more traditional kind of "application" that is actually more like a web site, and the newer kind of application that is more like an actual application (desktop/mobile).

Edit: Just read the new guidelines, and they are now considering serving up different content for the crawler as being "against the rules". So that probably cements the idea that you shouldn't allow Google to crawl anything that's mostly content-free and just an "app".

<comment><USER3> "Don't let Google crawl your site if it's not appropriate" is great advice, that's true, but it has nothing to do with whether you're serving up JS or HTML.

<comment><USER2> Yeah, I'm conflating the two, based upon my personal experiences.

But, are people really writing applications that generate all content completely on the client side via JS, but want the end result to be more like a traditional web site ? That seems weird, even to me. :-)

<comment><USER4> Tons of news sites are doing exactly this.

I can't tell you how many times I follow a link from Facebook or other social media, only to be brought to a page where a spinning gif spins for several seconds while JS loads the article.

</comment></comment></comment></comment></comment></comment><comment><USER5> I generally agree with the article, but the examples of javascript web apps that were given seem weak:

> Most web apps I work with daily have highly sophisticated in-browser > interactions that are built with JavaScript and can only be built with > JavaScript: Flickr, YouTube, Facebook, Twitter, GMail etc

The web apps that I use the most day-to-day are Trello, Slack and Gitter. IMHO, those are better examples of js bringing actual value to the table that progressive enhancement simply cannot.

With that being said, the issue of overusing SPA technology when it doesn't fit the need is definitely real.

Part of the issue comes from people wanting to pad their resumes w/ experience in "hot" technology, or people who do have a genuine interest in improving their skills, but are not very skilled in identifying the pros and cons of whatever "new hotness" or "best practice" they read on their favorite news aggregators. By extension these creates an industry for grunt work to maintain/refactor/rewrite everchanging codebases/frameworks. Coupled with the general tendency of people to favor new shrink-wrapped libraries over doing good ol' painstaking research, it's difficult to reverse that trend.

<comment><USER6> >> Trello, Slack and Gitter

Never used them, are they important? What do they do? I've used all the ones cited as bad examples.

<comment><USER5> For me they are tools for work and they are the web apps that I use the most every day (I work remotely). Trello is a task management system where you organize tasks as drag-n-drop "cards" and Slack/Gitter are chat apps (Slack is for company chat and Gitter is for my open source project community).

I do use Youtube/Facebook/Twitter etc as well, but I use them primarily for content consumption for entertainment, so my usage patterns of those services wouldn't be affected much if they were written without using javascript at all. In contrast, drag-n-drop and the ability for real-time collaboration are the killer feature of Trello (for me), and obviously there's no way web chat would ever work smoothly without js.

</comment></comment></comment><comment><USER7> I am a JS dev (after a lot of experience in statically typed languages) and just amazed to see the comments in this thread. At one end its experts(or near-experts) and at other end is just ignorants who probably did some $(...).show() and call it javascript. No wonder why its hard to hire good javascript developers. People just don't appreciate how wonderful this language is.

<comment><USER8> Way too many C#/Java developers who used JS in the early 2000s and hated it still think it's the same language.

<comment><USER9> The MS AJAX control toolkit and UpdatePanel probably didn't help, either.

I think I can probably say that Javascript engines are an order of magnitude faster than they were 16 (!) years ago.

If I may make a generalisation, C#/Java devs are more likely to be "enterprise" developers and said enterprises were more likely to be the ones on IE <11\. I know I fought damn hard to upgrade from IE8 just a couple of years ago. My webdev skills suffered as a consequence, too.

Microsoft moved pretty fast once they realised that IE needed to compete again - and Visual Studio evolved alongside it (mostly).

VS2015 is now a pretty good development environment for Javascript/Typescript and even includes some Grunt build support (although I haven't had a play with it yet).

<comment><USER10> > I think I can probably say that Javascript engines are an order of magnitude > faster than they were 16 (!) years ago.

Two orders of magnitude. I just checked, and on my laptop [http://web.mit.edu/bzbarsky/www/mandelbrot- clean.html](http://web.mit.edu/bzbarsky/www/mandelbrot-clean.html) (the first JS thing I wrote where performance of the language itself seriously mattered) runs in about 30-60ms in modern browsers. On the same hardware, it runs in about 2200ms in Firefox 3, which is the last pre-JIT version of Firefox. Other benchmarks I've tried show similar improvements results. And that's only going back to 2008; the interpreter was a good bit slower another 8 years before that.

</comment></comment></comment></comment><comment><USER11> I agree that Javascript web applications have a place. The problem is that the pendulum has swung too far, and folks are using Javascript everywhere. Static content generation on the client side, rendering non-interactive content, on the backend, in the build process, as a generic scripting language... the list goes on.

We're watching programming and design concepts which played out back with Windows 95 being hailed as "the future of programming". We're being told "worse is better" as Javascript is being used to turn our computers against their users by serving as a vector for malware, ads, and bots.

It's a mess, and it's going to take pushes from the far side of the pendulum's swing to bring it back to a sane place. If the pendulum was actually stalled too far towards "server side only", I'd agree that "server side only" articles would be too much - but we're not there.

> We can only improve the user experience with the front-end technologies we > have.

No, we are more than capable of degrading the user experience with the front end technologies we have. There's a lot of proof of that on the web today. Delayed full page ads, pop-overs for every third word, hijacked scrollbars, malware installs...

<comment><USER12> JavaScript has grown up; it's got one of the best package managers anywhere, rapidly improving syntax and semantics, a large passionate community, loads of great tooling and a well maintained cross-platform binary in the shape of Node. It's no less deserving than any other language to be run on a server, as part of a build, generic scripts, whatever. Browser security issues arise because it's hard to resolve total user security across the public web coupled with highly interactive scriptable web pages ... its got nothing to do with the JavaScript language per se. It's fair enough to argue against the level of control scripts happen to have over the browser, but web page scripting could be implemented in <insert some other language here> and the same issues would be present. Your comment comes across as ignorant and prejudiced I'm afraid.

<comment><USER13> NPM and the community that surrounds it is a nightmare. I guess you could be talking about Bower but either way they are far from good,let alone best.

<comment><USER12> I was talking about npm. And I find the JS community welcoming, friendly and passionate and for the more serious npm modules out there highly technically literate, but hey it's a subjective thing I suppose :/

<comment><USER14> So, the package manager that doesn't do proper deduplication and, thanks to nested dependencies, runs over the file path length limit on multiple platforms?

<comment><USER15> FYI, the nesting and deduplication were fixed in NPM 3. It uses a flat structure now.

Unfortunately, in their place the version resolution algorithm is now subject to order dependency: the same package.json file, run at the same time with the same packages available in the NPM repository, can give different results on different machines depending on what had already been installed.

<comment><USER16> Yep. Solved long file paths. All we had to give up was determinism!

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> I am a huge fan of JavaScript myself mostly because I found it very fun to work with and that you can do anything with it at the moment (websites, games, native mobile apps, smart TV apps, program raspberry pies and much more). About single page apps now: don't do a SPA if your website is not really an interactive application. Do you have a game, photo editor, P2P video chat? If yes, go ahead, SPA is really great for those things but for God's sake do not create a single page app when your website actually has more pages with different content and no interactivity. Why try to emulate how a browser works (loading, rendering, etc...) inside the browser itself?

</comment><comment><USER13> > Most web apps I work with daily have highly sophisticated in-browser > interactions that are built with JavaScript and can only be built with > JavaScript: Flickr, YouTube, Facebook, Twitter, GMail etc.

There is truly nothing about any of those that couldn't be done with a simple page refresh. Especially YouTube. Generally I find most of what JavaScript adds just irritating.

<comment><USER18> That's hilariously clueless. Do you think youtube is just a <video> tag?

<comment><USER19> Let's list Youtube's features that could be done with no Javascript

* Displaying the video

* Controlling the video (although with the browser's default controls)

* Being logged in

* Listing videos

* Voting

* Commenting

* Suggested videos

* Subscribing

Actually, I can't see a single thing that can't be done without Javascript. It has no complex notification system aside from annotations (and I'm not sure anyone enjoys annotations), nothing that isn't provided by browsers. But no javascript would require page refreshes, which makes for a worse UX. Eh, we survived refreshes before. Maybe browsers could even agree on a standard to refresh only part of the pages by querying the server themselves. Throw in five lines of JS to save to localStorage the current time on the video and restore it on reload.

<comment><USER18> So you are saying one shouldn't use JS to implement voting and comments but instead voting and comments should interrupt the video and then one uses JavaScript to restore the playback position. You also imply youtube should have waited for 6 years or whatever for video playback to even be possible without client side programming.

> Maybe browsers could even agree on a standard to refresh only part of the > pages by querying the server themselves.

Maybe browsers could also agree on implementing all needed applications in the browser. Then you just make <youtube> tag and you have implemented youtube.

<comment><USER13> HTTP 204. You send the request, the browser stays where it is. Super simple, and what it was made for. Amazon used to use it quite heavily back in the day.

<comment><USER20> The interesting thing about the modern web developer is that they don't know jack or shit about HTTP.

<comment><USER13> Yes. Quite literally "kids these days". HTTP is so powerful and so under utilized today.

</comment></comment></comment></comment></comment></comment></comment><comment> open-source-ux An unanswered question in this debate is: what is a web app and what is a web site? Sometimes the boundaries are blurry and sometimes they are clear.

For example, should a blog rendered in the browser be treated as a web app? Or rendered principally as HTML and CSS before it's sent to the browser (rather than rendered in the browser using Javascript). Here's an example: over 300K of Javascript to render a plain text page: [http://elm-lang.org/blog/new- adventures-for-elm](http://elm-lang.org/blog/new-adventures-for-elm)

My impression is that some developers are beginning to treat anything rendered in the browser as a web app - even plain web pages with no dynamic elements.

Why do developers do this? Is it because it makes their life easier using a single tool or language for both dynamic and static content? Or is it because they want to learn a new framework that's popular or interesting? Whatever the reason, one has to ask if giving users a good and fast site experience comes anywhere into the equation.

<comment><USER16> "Is it because it makes their life easier using a single tool or language for both dynamic and static content?"

Mostly this. As soon as you add a bit of dynamicism, it becomes easier to do everything in one language/workflow.

</comment></comment><comment><USER21> Each time yet another hipster posts his unique snowflake insights about why we absolutely need yet another bloatware to build websites _on this vey site_ (which is just static html pages over an FS storage in less than MB of code, including a dialect of Lisp and related DSLs) a kitten dies somewhere.

</comment><comment><USER22> Henrik Joreteg has a related talk[1] and post[2] on the evolution of web apps that are worth checking out.

[1]: [https://speakerdeck.com/henrikjoreteg/the-evolution-of- the-w...](https://speakerdeck.com/henrikjoreteg/the-evolution-of-the-web-app- fluentconf-2015)

[2]: [https://joreteg.com/blog/viability-of-js-frameworks-on- mobil...](https://joreteg.com/blog/viability-of-js-frameworks-on-mobile)

<comment><USER23> Here's another good one: [https://youtu.be/okk0BGV9oY0](https://youtu.be/okk0BGV9oY0)

</comment></comment><comment><USER24> JavaScript web apps are fine, as long as they are "isomorphic", i.e. the front-end code is also run on the server and the resulting HTML is sent to the client, and as long as it's possible to at least navigate to and read all the content without having JavaScript enabled.

</comment><comment><USER25> Am I the only one wondering what the fuck "progressive enhancement" is? Even the "enhanceconf" website doesn't explain.

>We're convinced progressive enhancement remains an important aspect in pushing the boundaries of the web while still providing a robust experience for every user.

What?

EDIT:

>Your HTML is not more accessible or more semantic when it's rendered on the server.

IDIOT DETECTOR TO FULL POWER. It is by definition more accessible if it doesn't require Javascript to render.

<comment><USER26> [https://en.wikipedia.org/wiki/Progressive_enhancement](https://en.wikipedia.org/wiki/Progressive_enhancement)

</comment></comment><comment><USER27> > Most web apps I work with daily have highly sophisticated in-browser > interactions that are built with JavaScript and can only be built with > JavaScript: Flickr, YouTube, Facebook, Twitter, GMail etc.

Good that GMail is created with GWT. So it doesn't even use JavaScript. Most people are so afraid of JavaScript that they create hella crazy abstractions (Angularjs [Google], ReactJS [Facebook]) and even then Microsoft and Google trying to avoid JavaScript more and more with Typescript or Dart, they transpile it. JavaScript maybe is valuable in the web, but not in it's current form. So much quirks that you either spend using a library or fixing browser incompabilites.

A lot of people here said that transpiling will be used a lot in the upcoming years, and I think that also. People will more and more. They want to use Python/Scala/Java/Whatever on both sides. Also it will reduce complexity by a lot.

Currently your typical webapp has, a server-side technology (even if you are using node), then you have a web frontend which uses at least npm, however mostly you end up with npm, bower, gulp/grunt, webpack and whatever.

> Client-server architectures instead of monoliths

What about small teams? They can't split their monolith since it will become unmanageable. So if they have two apps, frontend/backend it's still a mess to manage these projects with a small team.

> We need to stop excluding JavaScript apps from "the web as it was intended". > JavaScript apps are "of the web", not just second-class citizens "on the > web".

In my eyes JavaScript should be used where it is needed, but not used in stuff which never should touch it. JavaScript is still a mess.

<comment><USER28> > Also it will reduce complexity by a lot.

I have to disagree. Adding another layer of abstraction cannot reduce complexity, although it might make certain tasks _easier_. Consider assembly vs C as an example: C can make lots of programming tasks way easier, but the complexity of the system is not reduced.

With C, this becomes apparent when the program segfaults. A garbage-collected language or Rust can prevent segfaults using a subsystem to manage and/or enforce memory ownership, again making lots of tasks easier, while adding even more complexity.

In the case of transpile-to-JS languages, these can fix many of the shortcomings of JS and make lots of tasks easier, but they are a more complex system which can cause additional work if the generated code fails at run time, and the browser debugger brings up something completely different from your source code.

Your point that we will see more transpiled languages in the future makes sense.

<comment><USER29> I can see where it will reduce code complexity while upping stack complexity.

You're right that it's not always less complex. Trying to trace an error through some of these systems is ridiculous. I miss the days of it just pointing to a line number.</comment></comment></comment>


Appeals court rules NSA's bulk phone data collection illegal - <AUTHOR> https://thehill.com/policy/national-security/514854-court-rules-nsas-bulk-phone-data-collection-illegal <comment><USER2> Alas. In the legal field, this is called "dicta" and is non-precedential.</comment>


Ask HN: How to determine company valuation? - <AUTHOR>

We are a technology start up in photography domain based out of Europe. Our target customer segment are professional and semi professional photographers.
The team comprises of the CEO (Senior Executive with more than 15 years experience in Sales/Marketing) and 3 Software Developers with 3-4 years experience.
We launched two months back and have got good response. (However, we are not profitable yet). The seed investment into the company is close to 100K USD and we are trying to raise more funds now.
I was hoping to get an idea on different ways in which the valuation of a company can be calculated especially the ones that are in the stage as ours. <comment><USER2> At this stage there's no calculation. Market price is just a reflection of how much confidence investors have in you.

<comment><AUTHOR> Thanks very much for the answer pg.</comment></comment>


Encrypt Your Private Dropbox Data With EncFS - <AUTHOR> http://www.webupd8.org/2011/06/encrypt-your-private-dropbox-data-with.html <comment><USER2> This is better than TrueCrypt-on-Dropbox [1] in the sense that there's probably much less bandwidth inflation due to encryption, if any.

However, with EncFS be warned:

"Anyone having access to the source directory is able to see how many files are in the encrypted filesystem, what permissions they have, their approximate size, and the last time they were accessed or modified." [2]

Since tarsnap does the block partitioning and encryption client-side, it doesn't suffer from either problem.

[1] <http://news.ycombinator.com/item?id=2546626>

[2] <http://en.wikipedia.org/wiki/EncFS>

<comment><USER3> The post was updated with a command to exclude the EncFS key file from being synced.

</comment></comment><comment><USER4> Im sorry, but the whole idea of Dropbox was simplicity. This method requires installation of two more pieces software on every machine that will need access to encrypted data and does not explain or guarantee that it will work across platforms which is what dropbox is all about(I can access same files on my phones, tablets, windows pcs, macs and web)

I basically approach Dropbox as a tool that fits its purpose and this purpose unfortunately does not include properly encrypted data. So any sensitive documents would NOT go into dropbox. They would be backed up into an online backup that is encrypted on my side instead.

<comment><USER5> I find myself wondering if you actually read the content. Your first paragraph seems like a response to the article, but then your second makes it look like you didn't. Are you encrypting your files via hand-calculations before putting it on Dropbox, or using a second software package you installed as a tool? In which case what exactly is so hard about using one of the transparent file systems, which both boast a decent array of OS support options, that you have some sort of solution for that doesn't involve installing something beyond Dropbox?

<comment><USER6> I'm not sure if we both read the same comment. The second paragraph focuses on the fact that Dropbox is not suitable for sensitive content, and therefor he suggests using another service that offers client-side encryption (Tarsnap, possibly, as I think that it does that). He is not saying that he is putting encrypted files on Dropbox.

<comment><USER4> exactly, for sensitive data I use a different service that does client-side encryption: CrashPlan

More on their encryption options here:

<http://www.crashplan.com/blog/tag/crashplan-encryption>

</comment></comment></comment></comment><comment><USER7> This idea seems to come up every few months. Don't do it! (At least unless you seriously understand the caveats or something substantial has changed with encfs and/or Dropbox.)

Here's my comment from a year and a half ago: <http://news.ycombinator.com/item?id=895660>

... and from a few months ago: <http://news.ycombinator.com/item?id=2454924>

</comment><comment><USER8> Or don't use dropbox, use rsync, disk encryption, cron and SSH. Works across Mac/Linux & SCP on windows. With rsync+ssh+cron+disk encryption, you have full responsibility. Competency with rsync is empowering and can be as simple as dropbox, and way way way more secure.

</comment><comment><USER9> I have been doing this for some time. Not with Dropbox but sync'ing the encrypted files to my own server with rsync.

Install "Cryptkeeper" on Linux to have an tray icon to more conveniently mount and unmount.

</comment><comment><USER10> This sounds great, I assume there's no way to view these files on an iOS device (which is still quite workable encryption - only for dekstop)

</comment><comment><USER11> I've been happy with Tarsnap for encrypted remote backup purposes. I've got 8 months of daily snapshots, around 6Gb per shot. So far it's cost me around $7.

</comment><comment><USER12> Thanks, this is a lot better than the truecrypt system I had set up. Although I have a sqlite database that seems not to work with this... that will be staying in the truecrypt file system.</comment>


Monitoring Heart Health, One Toilet Seat at a Time - <AUTHOR> https://spectrum.ieee.org/the-human-os/biomedical/devices/monitoring-heart-health-one-toilet-seat-at-a-time <comment><USER2> To me, Emfit makes a lot more sense as these measurements (including heart rate variability) are best made when you are relaxed and sleeping. It's a sensor that is put under the mattress. It will detect when you lie down and continuously collect ballistocardiography and sleep data: [https://www.emfit.com](https://www.emfit.com)

During the day, you can wear a smartwatch or a smart ring instead.

</comment><comment><USER3> This reminds me of Chris Speed's toilet paper sensor experiment. Although it's more frivolous, the fairly detailed analysis of the ethics and sensitivities around monitoring people's visits to the toilet seems to apply equally well for this invention...

[http://chrisspeed.net/?p=1529](http://chrisspeed.net/?p=1529)

</comment><comment><USER4> This was already parodied four years ago:

[https://techcrunch.com/2014/11/18/smart-pipe-just-might- be-t...](https://techcrunch.com/2014/11/18/smart-pipe-just-might-be-the-best- waste-based-startup-video-ever/)

</comment><comment><USER5> Is there any of these markers that couldn't be tracked with a smart watch?

Of course, some people (like myself) might prefer not to wear a smart watch so it can still make sense and places like hospitals seem like an obvious market as well..

<comment><USER6> smart watches are terrible at measuring heart rate because they are at wrist. much better at finger tips for example.

was checking my iwatch while I've done an exercise that had its own heart monitor. the iwatch data wasn't even close.

<comment><USER7> That's not quite correct. Smart watches have gotten quite good at measuring heart _rate_. They are sometimes a bit slow to notice drastic changes (like going from sedentary to exercise), but they're pretty accurate when it comes to just counting beats per unit of time. They can be, however, quite sensitive. If it's not working well for you, it's likely because the sensor is wet, or dirty, too tight or too loose.

The fingertip seems like a truly terrible place to measure heart rate, given that fingers are constantly moving and pretty sensitive to pressure. They're the easiest place to measure oxygen saturation (SpO2) though.

Most (if not all?) smart watches have optical sensors, which register the _flow of blood_. You can measure the change in velocity and count the number of beats and the time between them. It doesn't tell you anything about what the heart is doing. A single lead ECG can do that reasonably well. Anything more professional (12 lead holter) quickly becomes impractical for long term use.</comment></comment></comment>


8 Things I Wish I Knew When Starting My First Business - <AUTHOR> http://www.quicksprout.com/2009/05/05/8-things-i-wish-i-knew-when-starting-my-first-business/ <comment><USER2> I found his advice about "hiring a law firm" interesting (see also [http://www.quicksprout.com/2009/05/05/8-things-i-wish-i- knew...](http://www.quicksprout.com/2009/05/05/8-things-i-wish-i-knew-when- starting-my-first-business/#comment-47424) ), but I could not help wondering if it was a bit overkill, especially since I have seen a lot of advice here that suggests that most small companies do not need legal representation, especially when they are just starting out. Is legal counsel an unnecessary expense for a new company, or a necessity?</comment>


Games People Play - Bayesian filters in recruiting - <AUTHOR> http://weblog.raganwald.com/2008/03/games-people-play.html

<comment><USER2> Somebody has actually implemented this (<http://londonmiddleware.org/chaff/>), though it's not clear how seriously the results are used in a real candidate evaluation.

<comment><USER3> Thanks for the link, I will add it to the post. +1!

<comment><USER4> You end your article with 'Bayesian filters will not outperform a human in hiring'. But that's not the point.

A classifier, and especially a supervised classifier, is really just a tool for intelligence amplification. Make a dumb man perform smarter, and a smart man perform better than almost anyone without the advantage. Similar to providing physicians with a checklist for common procedures which has been developed by iterative analysis of outcomes. It's very hard to become a physician if you're dumb or lazy, but it's quite easy to get fatigued on a 36-hour residency shift, or get complacent if some 'trivial' procedure interrupts your microsurgery specialty. And the stakes are far higher in most surgical interventions.

Naturally, many doctors resist. But the best figure out how to use this to their advantage. It increases the efficiency of the system. Likewise, having the 'advice' of a machine that has been trained on a corpus of good multiple- human-actor decisions, over time, can provide individuals with better judgment than their experience alone. This is more apparent with a larger corpus and finer-grained classification -- eg. multidimensional classification with a huge corpus and eigenclasses of suitability. Game that, and you're smart enough to be in management, most likely ;-)

So, I don't believe you should let your detractors off so easily. Maybe a talented human will outperform an filter with a small corpus. But I'd bet dollars to donuts that, for someone who isn't a full-time interviewer, the assistance of a well-trained filter will increase their acuity and throughput, allowing them to get on with their real jobs and worry less about dumb hires.

You can't really avoid the enthusiasm of junior employees who haven't been burned, and this is another scenario where a filter can help them gauge their judgment by providing a historical perspective. "You know the last guy we hired who interviewed like this, one of your coworkers spent 2 hours a day for 3 months training him, and then we fired him!" That's something you want to avoid, and I have seen this happen at places like Google where you might think they'd be immune. But once you let the dumb or negative folks in, it's all downhill from there.

So -- replace humans? No. Augment them? Yes. It's what computers (and statistical analyses) are meant for!

</comment></comment></comment><comment><USER5> An employee will cost anywhere from 20K/year to 500K+/year. I think it is worth spending 2 minutes personally reading each resume.

<comment><USER3> Ah, my old friend whose name is here. Your comment is absolutely true.

If I may ask, are you mentioning it because you think the post is suggesting otherwise? Or are you just mentioning it??

<comment><USER5> No, you're not suggesting otherwise. But using "Bayesian filtering" (or whatever variation of it) is best on huge data sets. Working manually, I could tell you with near 100 percent reliability which email is spam--better than any filter. It's inefficient for a human to do it, so a process that can remove 95 percent instead of 100 is acceptable. Inefficiency matters less as the data becomes smaller and more important.

Real life example: My current manager has some twisted filter on his brain, whereat he is convinced that a mastery of certain things (like design patterns, or "OO architecture") are extremely important. We were interviewing a while back, and some kid said his 'proudest achievement' was a Pac-Man clone he made. Well, my manager's filter did not include the words "Pac-Man clone" and so we never even looked at it.

Every good candidate in a creative field is going to go outside the bounds of _any_ filter you can come up with, training or otherwise. The better they are, the more likely this is true. A tool that is suitable for flagging "V!agr3" is not necessarily the tool for...identifying good pharmaceutical researchers.

<comment><USER6> That was the main concern I had about the Bayesian resume filter - would it work at small (or even mid-sized) companies? Sure, with Google getting 10K's or resumes a month, they could mine some monster data out of it, but if you hire a couple people a year and get 100 resumes, do you have enough data?

I guess Reg's point was that even if it isn't perfect, it gives you _some_ data, which is a heck of a lot better than _no_ data.

<comment><USER7> Some data is not always better than no data. Sometimes data can provide a bias that you don't want. So it has to be the right data that you have. For example knowing that someone attended a prestigious university is likely to create a bias towards hiring that person and ignoring clues that indicate otherwise.

If your classification filter recommends somebody it's possible to let that piece of information provide the same kind of bias. So if the data you have is likely to be unreliable you might want to just ignore it.

<comment><USER3> "So if the data you have is likely to be unreliable you might want to just ignore it."

That prompts me to ask two questions:

1\. So should you forget about data, or pay attention to collecting good data? WHich course of action is more important? 2\. If you don't make decisions based on data... Just how are you making decisions?

I am serious about question #2. We aren't talking about face to face interviews here, we're talking about looking at 200 resumes and deciding which ten people to call with the expectation of bringing 3-5 of the ten in for interviews.

In my experience, when people tell me they are using their "experience" and "judgment," They are actually using a highly biased process, such as selecting people who went to their University or preferring people who share the same hobbies.

<comment><USER7> 1\. try to collect better data if possible. if that's not possible ignore the source of that data (and likely find another source that can provide more reliable data). So I might ignore the automatic resume filter and perhaps judge the fitness of a candidate based on how enthusiastic they seem about work they've done in the past (just an example)

2\. You always need to make decision based on data. But sometimes you need to allow your brain to interpret the data for you, even for resumes. If you're getting more resumes than you can handle reading by hand you can implement a spam filter. For example require candidates to solve a sample problem and submit the answer along with their resume.

And as far as gaming by providing stock answer to the coding problems try this: extract actual problems (bugs or new features) from your real application, write automated tests for them and then put the problems online for interested candidates to solve. After a while identify a new problem from your application and put that online. Not only are you finding quality applicants you're solving real problems at the same time.

These are just some thoughts that went through my head by the way, I can't speak for how effective these methods are (or would be).</comment></comment></comment></comment></comment></comment></comment>


Show HN: DailyWall – A Mac app that will give you new wallpaper every morning - <AUTHOR> https://dailywall.space <comment><AUTHOR> Every day at after 10AM DailyWall will set you a new desktop wallpaper from a massive curated collection gathered across Unsplash, Pixabay and Pexels

Check it out on ProductHunt: [https://www.producthunt.com/posts/dailywall-for- mac](https://www.producthunt.com/posts/dailywall-for-mac)</comment>


Ruby on Rails 3.2.13.rc1 had been released. - <AUTHOR> http://weblog.rubyonrails.org/2013/2/27/Rails-3-2-13-rc1-has-been-released/

<comment><AUTHOR> My first release! I'm so excited! Please tell me if you find any regressions. ❤</comment>