n8agrin

I think an organization's governance structure being successful has more to do with how the people in the organization want to be governed than whether it's building an app or feeding the poor.

With full respect to your right to criticize, I don't understand what differentiates an organization trying to build a social networking app around biodiversity data from an organization feeding the poor, and those organizations' ability to experiment with their governance system. Can you expand that thought or is it rhetorical?

Sociocracy is a theory of governance: https://en.wikipedia.org/wiki/Sociocracy

I've had similar thoughts. Any interest in sharing notes? Generally I've been thinking there should be a standard declarative format for data vis. This should be inspired by prior art like ggplot, Grammar of Graphics, Vega, VegaLite, etc.

From there it could be compiled to targets declarative or procedural (eg to generate VegaLite specs, echart specs or Observable Plot configs in JS).

How have you been thinking about this problem space?

:) Ty for being part of the community

:heart:

:heart:

Look for "A Little History": https://www.inaturalist.org/pages/about

https://www.inaturalist.org/

While I deserve no credit for its current success, it's been used by millions to:

* catalogue millions of plants and animals around the world

* tagged image data has become critical for computer vision training models

* map species range and impact of various natural changes to biodiversity, with data cited in scientific journals

* new species have been discovered through the app

previous HN thread - https://news.ycombinator.com/item?id=22442479

iNaturalist was the final product of my Master's degree thesis team. I haven't contributed to it since school, about 11 years, so I don't deserve any credit for its success. The folks who have kept it alive are personal heros - they sacrificed a lot and invested so much to build the community that exists today. It's probably the project I'm still the proudest to have contributed to.

When we started, our goal was to encourage people to go outside and engage with the world around them. We dreamt that the data gathered by the community would be used in scientific research, but weren't confident it would ever reach enough of a critical mass. It has! More surprisingly, we had no idea how important iNat's image dataset would become for computer vision research.

Again, so proud of the folks who have helped to make iNaturalist thrive and so glad it still exists in the world.

In the context of a large client application, I often advise engineers that if we're optimizing things like the types of `for` loops we use, we've won the performance lottery. That is, I've never found a critical performance issue that is the result of using `forEach` instead of `for`.

For those curious, this is the law which allows you to sue the police: 42 U.S.C. § 1983

"Every person who, under color of any statute, ordinance, regulation, custom, or usage, of any State or Territory or the District of Columbia, subjects, or causes to be subjected, any citizen of the United States or other person within the jurisdiction thereof to the deprivation of any rights, privileges, or immunities secured by the Constitution and laws, shall be liable to the party injured in an action at law, suit in equity, or other proper proceeding for redress, except that in any action brought against a judicial officer for an act or omission taken in such officer’s judicial capacity, injunctive relief shall not be granted unless a declaratory decree was violated or declaratory relief was unavailable. For the purposes of this section, any Act of Congress applicable exclusively to the District of Columbia shall be considered to be a statute of the District of Columbia."

More here: http://en.wikipedia.org/wiki/Enforcement_Act_of_1871_(third_...

I couldn't agree with you more, that's why I linked the paper.

Here's a good paper about animated transitions in stats graphs and their effectiveness. http://vis.stanford.edu/files/2007-AnimatedTransitions-InfoV...

@nnnnnick this looks great. I work with d3 on a daily basis and while I think that it's a great toolchain, the need for something small, fast and canvas based was absolutely needed. Well done.

What's old is always new, especially on the Internet. I'm constantly reminded of the "Simpsons' did it" South Park episode whenever I'm reading press briefs about new startups.

I want no local storage anywhere near me other than maybe caches. No disks, no state, my world entirely in the network. Storage needs to be backed up and maintained, which should be someone else's problem, one I'm happy to pay to have them solve. Also, storage on one machine means that machine is different from another machine.

I'm always shocked that this hasn't happened faster. I've expected Dropbox, Amazon, Google and Apple to move into this space more aggressively, but at best they've all only just scraped the surface of what's possible.

I actually think both of you are right. It's not about exclusively communicating with your friends or exclusively following celebs, it's about both. What you care about combined with a personal audience to discuss it with. The kid you found as an example subscribes to Paul Ryan's and Newt Gingrich's feeds along with his friends' feeds. Twitter can target Republican, right-leaning ads towards him. Maybe he discusses politics with his friends online and off.

Hand by hand chip counts http://www.wsop.com/tournaments/chipcounts.asp?rr=5&grid...

This is great work and it's still early days. Looking forward to seeing the code clean up and having more extensible options for things like legends and fewer properties tightly coupled to chart instances.

I posted it immediately after it was announced. It got ~20 quick up votes but never landed on the home page: http://news.ycombinator.com/item?id=4040049

You're making a lot of assumptions that are unfounded.

What you're suggesting is usually called progressive enhancement. Yeah it's great, but sadly when you are using a system like Spine, Backbone or Ember, it's not just a matter of "endless Firebug sessions" to resolve the initial bootstrap problem.

No one claims that this is not possible, nor is anyone "crying foul". On the contrary I know first hand how much of this work was done at Twitter and how difficult it is. But as you stand by your petulant claim that "twitter.com is slow because twitter is incompetent or doesn't care about their product." I stand by mine, that there are tradeoffs when embracing one style of development over another.

Feel free to disagree with me but back it up with experience, not false assumptions, blanket statements and the denigration of many good people.

I don't fully understand your point. My quote you're using is meant to be rhetorical. So you're not Twitter... are you implying that you could build an all JS application and avoid all of the problems that Twitter ran into at Twitter's scale? If so, I'd love to see you execute your ideas successfully and explain them so we could all learn from you.

It's really easy to armchair-engineer and just declare bad design. What's harder is to actually build a system that scales well in the very unusual circumstance that sites like Twitter, Google and Facebook find themselves in.

Let's take your solution: it's really difficult to build a development environment that allows a large team to work efficiently which is not based on having essentially a single bootstrap file when deployed in production. When you break apart your files into smaller chunks you are asking your developers to understand the intricacies of asynchronous loading of each file and impose dependency management on everyone. This is a huge problem at Twitter's scale.

FWIW, Twitter did break apart their files into smaller chunks pretty effectively using the Loadrunner project (https://github.com/danwrong/loadrunner).

I'm not making any assumptions, I'm telling a story about what I watched happen first hand. As you say, you can split up your assets, that does help significantly. You can also put stuff on CDNs, that helps significantly too. Believe me, Twitter engineers are super smart and they've done all of this. But at the end of the day if your business model depends on people looking and interacting with your content, or if you just want your site to be super fast, having a loading spinner while you wait and download the rest of your application in the background isn't going to cut it.

Good question. I should be clear and state that when I say 1-2s page load times I meant the time from when one requests the page to when one can see it. In general API requests are fast, what is slow is having to always deliver a large JS bootstrap across the network (JS files, templates, etc) and then having to make the relevant API requests to produce the UI. Caching is generally touted as a good solution to this problem, but in my experience it tends to be insufficient. Yahoo did an (older now) study showing that 40-60% of visitors arrive at your site having an empty cache (http://www.yuiblog.com/blog/2007/01/04/performance-research-...). Another solution is to pre-fetch data for the UI and deliver that with the bootstrap but it's still difficult to speed up a ~1 or ~2 MB download. This is what really ends up killing the experience.

Twitter didn't dump Rails, or Ruby.

Let's say you have a website and let's say that website serves a lot of traffic. Now let's say you relegate Rails to act as just your API because clients are fast now and you want to do some new cool stuff with Javascript also, you're convinced your site is more like an "application". So you build this system and it works really well, except for one thing. The first time you load the page it takes a second or two minimum to get the page loaded. That's ok at first, but really soon it becomes annoying. So you do everything you can with your client, caching whatever possible. You get the load time down to something like 1s. That's better but still not great. Some static sites can spit back pages in like 200ms (across the network!!) and that 800ms difference is crucial to the overall feel and snappiness of your "application". Eventually you give up, you keep the parts of the site that work well as a client-side app, push the rendering back to the server because even though the server is a long ways away from the client and even though clients are fast, you can directly control how quickly the server builds a page and you can optimize that to your heart's content. Now you've gotten your page loads way way down to like 400ms. You're doing great, people love you and you've saved the day. I've fabricated the numbers, but this story is based on truth, because you know who you are? Twitter, Alex's employer.

That's not to say that Rails doesn't make a great API and that Alex doesn't have a point. There certainly is a place for frontend applications out there built on frameworks like Spine, Backbone or Ember (all great projects). Those types of applications have their advantages in some cases. But, it's prudent to be pragmatic and to recognize that the times where you truly need to build a client driven application are few and for the other times Rails is still great at serving up HTML.

It is a kite, made by Slingshot. See: http://i.imgur.com/3Fgct.jpg and http://ride.slingshotsports.com/kiteboarding/leading-edge-in...

For obvious reasons I'm guessing Twitter or Square. Though I wouldn't be surprised by a Salesforce acquisition either.