Could New York City Eliminate Free Street Parking? - <AUTHOR> https://www.nytimes.com/2019/11/20/nyregion/nyc-street-parking.html <comment><USER2> > Driving down any avenue, the traffic lanes have been diminished because of > the bicycle lanes and the parking areas have been diminished because of the > bike rentals. It's punishing drivers.

Funny how drivers are willing to blame everyone except other cars. Walk down Canal or Broome around rush hour and it's pretty clear that the problem is not bike lanes (neither have them) but the fact that there are just too many cars for the amount of space available.

It will be interesting to see what happens with city politics after the next mayoral election. My sense on the ground is that political will from the non- driving majority is stronger and more organized than it has been in the past.

<comment><USER3> > My sense on the ground is that political will from the non-driving majority > is stronger and more organized than it has been in the past.

This might be an unfair generalization, but I associate pro-car sentiments with older conservative voters, who unfortunately do turn out to elections more strongly. The outer burroughs certainly elect in that direction.

</comment></comment><comment><USER4> You never hear a peep about street parking in the NY Times unless it can be framed as some sort of existential class struggle question and great historical social justice dilemma, all or nothing.

Meanwhile there are some 140000 "parking placards" in NYC that are abused with great abandon by a privileged class of state workers to park wherever the fuck they want, with enforcement curiously missing. Here is a tip for an aspiring writer: don't try to condense an issue into a single column and inevitably come up with the 100 year old quotes of the plight of the struggling minimum wage worker, find a detail and research that.

<comment><USER5> You mean like these three articles on it from the NYT?

[https://www.nytimes.com/2019/02/21/nyregion/parking- placards...](https://www.nytimes.com/2019/02/21/nyregion/parking-placards- city-workers.html)

[https://www.nytimes.com/2019/06/04/nyregion/parking- ticket-s...](https://www.nytimes.com/2019/06/04/nyregion/parking-ticket- scandal-nyc.html)

[https://www.nytimes.com/2017/05/26/nyregion/the-new-math- of-...](https://www.nytimes.com/2017/05/26/nyregion/the-new-math-of-parking- placards.html)

</comment></comment><comment><USER6> Pedestrians and bicyclists spend more than drivers at local businesses in New York City [0].

[0] [https://www.transalt.org/sites/default/files/news/reports/20...](https://www.transalt.org/sites/default/files/news/reports/2012/EV_Shopper_Study.pdf)

<comment><USER7> While this is a helpful point, I think it would be nice if this issue were framed more in terms of physical and mental health, not just as a question of how to optimise economic output. We need less cars for almost every possible reason you can think of.

<comment><USER6> I want to make a point. There should be no concern that The War on Cars harms the economy of New York City. It is a claim without evidence.

<comment><USER7> I agree. But I would also counter that it is worth killing cars even if there were a measurable negative economic impact, because of all the clear benefits we would gain in exchange for it. But of course even these subtler benefits (like mental and physical health), would necessarily result in improved economic output overall.

</comment></comment></comment></comment><comment><USER8> A must read classing for anyone interested in this topic:

 _The High Cost of Free Parking_ by Donald Shoup

[https://www.amazon.com/High-Cost-Free-Parking- Updated/dp/193...](https://www.amazon.com/High-Cost-Free-Parking- Updated/dp/193236496X)

<comment><USER6> What makes this a must read?

<comment><USER9> Donald Shoup, a UCLA professor, is one of the few academics who has been studying the economics of parking and is considered THE authority on the subject.

</comment></comment></comment><comment><USER10> More than residential parking, I feel that double-parking for deliveries, drop-off/pickup, etc. is a major contributor to traffic and congestion. I like the idea mentioned of flex-zones that can be used for different purposes and perhaps address some of these concerns. Unfortunately, allocating parking spaces is a zero-sum game.

<comment><USER11> > _double-parking for deliveries, drop-off /pickup, etc. is a major > contributor to traffic and congestion_

If half the street weren't off limits due to parked cars, traffic could easily route around such disruptions.

</comment></comment><comment><USER12> In New York owning a car is a huge luxury, the city is giving away free real estate to the richest of the rich New Yorkers. Getting rid of free street parking is a great idea.

<comment><USER13> You must not visit Queens, Bronx or Manhattan beyond 110 very often. They have extensive car ownership. I don't think anyone would call them rich.

<comment><USER14> True, we should be careful to not conflate "Manhattan" with "New York City".

That said, I agree with OP's comment within the context of _Manhattan_. Anyone who owns a car there is _very_ wealthy, even within the context of a wealthy city.

(I don't agree with pegging the divide at 110th street, that's much too low.)

<comment><USER15> Anecdotal, but my relatives who live/grew up in the outer boroughs call Manhattan "the city".

<comment><USER16> Thats only if you live in NYC you refer to Manhattan as "the city" but we very well know that New York City consist of all 5 boroughs

</comment></comment></comment></comment></comment><comment><USER17> >> _" In Chicago, neighborhood parking costs residents $25 a year; in Los Angeles, as much as $34; in Washington, $35; and in Portland, Ore., $75. In Boston, a pass for neighborhood parking is free, but officials are considering charging people with one car $25, and more for second and third cars."_

The area highlighted in the article is the Upper West Side in Manhattan, which is a primarily residential area and not a commercial area that will be subject to a 2021 congestion toll. I don't know of any data that tracks the breakdown of outsider vs. resident cars, but generally I feel that the majority of cars who "cruise an average of seven blocks [...] before they find an empty space" will not be impacted much if residential parking permits are issued.

In fact, residential parking permits would probably still result in the same problems mentioned in the article: double-parked vehicles during the day, remnants of a car-centric culture, and residents desperately circling for free parking spots. The one benefit of a parking permit would be an increase in city revenue.

This is sort of addressed in the article where "residential parking fees in other cities have not been a panacea, in part because neighborhood permits usually do not deal with the supply-and-demand problem — too many cars for the number of spaces."

You could force residents to pay for garages which generally charge $700+ per month to store a sedan (more for SUVs), but then we keep hearing how such policies favour the rich and wealthy because they disadvantage residents who need vehicles to drive to work every day.

<comment><USER18> Nobody who lives on the Upper West Side is driving to work. They circle looking for spots when they have to move their cars for street cleaning and when the get back Sunday night from their country houses.

[https://nyc.streetsblog.org/2019/07/05/new-york-is-really- aw...](https://nyc.streetsblog.org/2019/07/05/new-york-is-really-awesome-when- the-rich-people-leave-and-take-their-cars-on-vacation/)

<comment><USER19> as an UWSer who does not know anyone with a "country residence" or who can afford a second residence at all given the exorbitant price of living in this city, there are plenty of other reasons for people to take the car out in the middle of the day on a summer weekend like, say, going to a beach with your chairs and cooler etc which isn't something you can do with public transit, or going hiking someplace not right off a train line, or any number of things that ordinary non-super-rich people do.

<comment><USER18> Sure, but every time NYC "car culture" questions come up, people start wringing their hands about people who need to drive to work. If we're talking NYC that's a low percentage of people who do drive to work (whether they _need_ to is another question) and for the Upper West Side (say, zipcodes 10023, 10024, 10025) very low, 6%-7%.

[http://zipatlas.com/us/ny/zip-code-comparison/percentage- pop...](http://zipatlas.com/us/ny/zip-code-comparison/percentage-population- drive-to-work.16.htm)

It is less compelling to say that people need free curbside parking so they can go to the Catskills, whether they have a house there or not.

<comment><USER19> I would certainly support resident parking permits. I don't think many people need to commute _into_ the UWS for work by car, since of course the entire neighborhood is hooked up to transit endpoints that have their own parking, which is not necessarily true for the places that UWSers commute _to_.

</comment></comment></comment></comment></comment><comment><USER20> I live in Europe, but I see no reason why parking space would be free. I also don't see a reason why a part of the street should be used parking when they are built for driving. I am not an eco-nazi, I use a car and a motorcycle, but they are always parked either on my property at home, in the shopping mall parking (cost included in the price of the products I buy) or in the parking at the office (which the employer already considers as a cost when paying me a salary).

<comment><USER21> It's a function of the urban design. In neighborhoods that are planned around residences having off-street parking, it's not necessary, and many have a blanket "no overnight street parking" rule.

In others, almost no residences have off street parking and there are few if any commercial garages, so everyone parks on the street. Reducing the curb space available for parking forces the least patient street parkers to give up their cars.

</comment></comment><comment><USER7> If we could do a reset, there's no way people would choose to allocate around half of public space just for cars. And especially when a significant portion of that is space taken up by empty cars that are serving no one. We should abolish almost all street parking in the city.

[https://twitter.com/BarmanNYC/status/1193229051609206784](https://twitter.com/BarmanNYC/status/1193229051609206784)

</comment><comment><USER22> On-street parking is sanctioned littering. People should not be allowed to litter giant cars on the streets.

</comment><comment><USER23> I live and work in Manhattan and there is a great deal of traffic congestion that could be fixed by removing parking spaces on streets that have 1\. dedicated bus lanes. 2\. bike lanes.

14th St has removed all parking and auto traffic and the crosstown buses are very frequent even on a weekend and convenient.

A lot of traffic can be blocked by delivery trucks that are double parked on streets which have parking on both sides.

One reason is that the trucks are too wide for the city streets. There should be a mandated by law maximum width on delivery trucks for NYC that are no wider than an SUV or other wide car. Instead of making the trucks wide, make them long and narrow.

That way, even if the delivery trucks like Fedex, UPS, Freshdirect, etc are double parked, they don't block the entire street.

</comment><comment><USER24> > But even as the number of parking spaces has shrunk, the numbers of cars has > risen.

So basically, the actual people who live there, believe that even with all the difficulties cars are the best way to go?

And the city wants to .... make things harder for them?

That's pretty backwards.</comment>


LIBRE: Liberating Research - <AUTHOR> http://www.liberatingresearch.org/

<comment><AUTHOR> I'm linking to it because I think it's always good to discuss this problem and potential solutions. However, if this platform is run by anonymous people (the "author" meta tag says "Andrew Leeds Burton for Browse Digital" in the HTML source of the page, but Browse Digital seems to be a web agency) and is centralized, I'm not sure its a viable option. I know this kind of platform is hard to decentralize, but to me it still seems necessary for research to be independent.

EDIT: the domain name whois point to this guy: [https://pandelisperakakis.wordpress.com/](https://pandelisperakakis.wordpress.com/). Indeed, his Twitter one-line bio says he's one of the co-founder.

EDIT2: got more info here: [https://twitter.com/p4bl0/status/402892533149089793](https://twitter.com/p4bl0/status/402892533149089793) (read the whole conversation).</comment>


New Thinking on Covid Lockdowns: They're Overly Blunt and Costly - <AUTHOR> https://www.wsj.com/articles/covid-lockdowns-economy-pandemic-recession-business-shutdown-sweden-coronavirus-11598281419 <comment><AUTHOR> [https://archive.vn/9XITB](https://archive.vn/9XITB)</comment>


Seven Design Patterns and Trends in 2009 - <AUTHOR> http://drawntosimplicity.com/blog/2010/01/04/seven-design-patterns-and-trends-in-2009/

<comment><USER2> 404\. Perhaps this is it:

<http://www.drawntosimplicity.com/?p=3></comment>


Always ship trunk: Managing change in complex websites  - brown9-2 http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf

<comment><AUTHOR> For what it's worth, this is pretty much exactly what we did at the last web property I ran with ~500 million monthly pageviews. We had a configuration framework that allowed us to flip bits on the fly (and, importantly, flip them back), without a deploy, in ~1 second across all of our app servers. The app servers listened to a message queue which would broadcast changes of configuration values.

This one thing alone made a huge difference in our engineering velocity.

If you're looking for a pre-built component to do these things for you today, check out Apache Zookeeper: <http://hadoop.apache.org/zookeeper/>

<comment><USER2> Yes. If you're in this situation Zookeeper will change your life.

</comment></comment><comment><USER3> Good points, and we're doing almost exactly that, with one difference.

I think it's worth having 2 branches you ship from: master and production (or, in reverse, master and development).

The reason is that this way, if you're in the middle of some relatively large and untested changes in the development branch, you still have a copy of exactly what's on production to work on in case there's an urgent patch that needs to go out.

This is not strictly necessary, of course, but we've found that it's saved us some hassles.

</comment><comment><USER4> At the end, he asks "What would a version control system for a web app look like?" Perhaps that's only a rhetorical question, but I think he's already touched on a partial answer: it's a configuration management system. A good configuration management system will help you keep track of what's currently deployed where (although variation per login id is generally out of scope) and help you be sure that the requirements for deployment are met. The source for the configuration is normally kept under revision control for non-branch elements that revision control does well: _why_ the change went in, _who_ put the change it (in case the "why" was incomplete ;-}), _what_ the change was (centralized diff), and _when_ the change went in. _When_ can be important for those little used but essential features that you find out stopped working some time ago, and you want to find out _what_ made it break.

He advises discipline in removing unused configurations. I'd like to hear what sort of dependency analysis tools support that activity.

<comment><USER5> Doesn't Google App Engine provide some of this for free? You upload versions, change which one is deployed, and can easily roll back at a moment's notice. It's not as swift or sexy as multiple configurations in the same code, but still far nicer than managing it yourself.

</comment></comment><comment><USER6> This will seem a lot less heretical if you do a lot of A/B tests, since if you're already supporting 2^13 versions of the code running simultaneously, heck, what is a couple more.

</comment><comment><USER7> It's easy to miss, but this talk is given by a Flickr engineer and is how they deploy their code. Pretty big recommendation.

<comment><USER8> Former eng manager actually.

In this preso he's focusing in on just one aspect of how Flickr does things. He did a more wide-ranging talk with ops guru John Allspaw last year.

<http://velocityconference.blip.tv/file/2284377>

For instance, as people noted already, he's advocating testing features on live servers -- in a controlled way. This doesn't work unless you have the kind of dev/ops cooperation that he describes in the above video, as well as practices for quickly rolling back changes and a culture of not blaming people.

</comment></comment><comment><USER9> Wow, I just learned a new idea. Test SaaS on production servers. Sounds scary but makes sense. Fast driving is not always dangerous driving. Great post.

</comment><comment><USER10> Sounds like a bit of tool support would be useful.

Note that the UNIX command patch has a -D <symbol> option, which results in the patch only being applied if the (C/C++) program is compiled with -D <symbol>, so this idea is not actually all that new...

</comment><comment><USER11> Good 5 minute read.

Last slide asks a great question:

 _What would a revision control system built for supporting deployed web applications be like?_

</comment><comment><USER12> After much experimentation over the years, I've found the best approach as follows (using git):

\- always ship master

\- always develop using topic branches (branches dedicated to a single feature)

\- deploy topic branches to dev/staging (with large visible footer label text)

\- don't leave old topic branches around on your central git server (delete as soon as its tested and merged back into master)

</comment><comment><USER13> My first thought is that this should be managed using a Factory pattern. If one is truly doing A/B testing, then this is manageable for N = 2, and a lot of repeated conditional code with the same if-then-else statement will disappear.

If they are A/B testing a lot of things, then this can get unmanageable. For that, how about a collection of functions? (methods? I am not trying to be language-specific at all here.) Have a facade which stores references to the actual functions. This is much easier if your application is structured in a functional or nearly-functional way.

Writing 100 if-then-else statements without making a single error is doable. But making the conditional logic disappear and just having to manage the methods themselves and a configuration is much easier.

<comment><USER14> That was my thought at first as well, but probably for illustrative purposes, it was easier to do if-else statements. The more structure there is, the higher the learning curve. For a presentation, it probably wasn't necessary.

<comment><USER15> In practice, it turns out to be easier to do with if-else statements as well.

A factory pattern is useful when you know ahead of time along what dimensions your system will change. You can build an interface with methods for each of those change points, then call out to those methods when appropriate. For each experimental variant, you provide a different implementation and instantiate it based on experiment selection at the factory.

Unfortunately, these types of configuration changes, by definition, tend to be _experimental_. Meaning you have no idea how the app is going to change to accommodate them, you just have an idea that might or might not help users and you want to test that hypothesis as quickly as possible. Rearchitecting your app to build the appropriate factory interfaces takes significantly longer than just throwing in an if, and it's all wasted effort if the experiment comes back with a null result (as many do).

If you find yourself making experimental changes to the same areas often, _then_ you might want to look at introducing a Factory. But design patterns in general are something you reach for once the system has matured, not something you do when you're still experimenting and exploring the domain.

<comment><USER13> If you read my post carefully, I propose a Factory, then reject it in favor of something simpler.

My proposal reduces the refactoring to "this block of code becomes a function call." There's still a piece of conditional logic, for each dimension, but it only gets written once. The application code gets smaller by applying this, except for one startup routine where we set up the thunk. Overall, it's actually less code than sprinkling conditionals everywhere. You could set things up so you change the configuration of all your A/B experiments in a single file. It's not so much a pattern as it is a reorganization of the logic along a straightforward application of DRY.

One might still want to stick with the conditionals everywhere if most of the code needs local state. This is probably an indication of a need to refactor, though.

</comment></comment></comment></comment><comment><USER16> Thank you - very concise and will help me personally in a current initiative to drive some points home!

<comment><USER16> I suppose some details would be appropriate....

I'm dealing with a suite of what used to be plain-old websites that slowly, over time, started to gain functionality. PHP crept in there (just for includes) - the web team went from one person to an entire department in a short period of time, and some functionality keeps creeping in there - some of it done by developers, some of it done by web PHP guys who shouldn't really be writing code. Incremental direct updates to the site on a daily basis are a regular thing by far too many people.

I'm sure many people have the same story.

The challenge is in taking the current situation and turning it into something manageable with release control, testing, and so on - because it's at a point where a simple mistake by a designer can (and has) effectively taken the site down, and due to the nature of the update process, it's hard to find out 'wtf' just happened. The GOOD part is everyone is on-board with changing things (no politics).

The hard part is figuring out what those changes are - as soon as we started trying to fit this into the standard developer workflow, it was obvious that we were adding far, far too much un-needed technical bureaucracy (do we have a word for that?) for no real benefit - and the idea that the release and deployment tools are where the real benefit is is really becoming apparent - the version-control system is necessary, but it's not strictly the most important piece.

So for me, these slides (wish I could see the talk that went with it) really helps cement that I'm not insane for thinking differently about how this should work.

</comment></comment><comment><USER17> btw: scribd works really well now.

</comment><comment><USER18> 92 slides is a bit long for the points the author is making, although it's hard to say without hearing the talk.

Basically the author prefers GIT and mercurial over subversion because of easier branching, and argues for having multiple versions of the backend running in order to switch between them with with configs in your code (eg. cfg["use_new_awesome_backend"] = 1) in multiple variations (eg. if (rand(0,99)<10) cfg[".."]=1, etc).

<comment><USER19> >Basically the author prefers GIT and mercurial over subversion because of easier branching

That wasn't exactly the conclusion I got out of it. I felt like he expressed a slight preference for git and mercurial, but at the end he asked for people to envision what a web/SAAS version control system should really look like, since none of the 3 fit that bill, in his opinion.

(I agree with the second half of what you wrote that I'm not quoting here.)

<comment><USER18> True, I missed the point in the first part. Thanks for pointing that out.</comment></comment></comment>


Cloud SFTP for S3, Dropbox, Box, Google Drive - <AUTHOR> https://couchdrop.io/mft <comment><AUTHOR> Nice tool and simple to use. There is a monthly sub, but the time we save for our workflow automation is worth it.</comment>


The Amazon Rainforest Was Shaped by Humans (2017) - <AUTHOR> https://www.smithsonianmag.com/science-nature/pristine-untouched-amazonian-rainforest-was-actually-shaped-humans-180962378/ <comment><USER2> Charles Mann's excellent book "1491" covers this in-depth, including some background on how this "untouched nature" myth came to be (Holmberg's Mistake). He chides scholars on both sides of the political aisle for taking a sense of agency away from the indigenous peoples, and lays out (seemingly) well-sourced evidence for how impactful the fires, especially, were on the local environments.</comment>


Cubism.js: time series visualization - <AUTHOR> http://square.github.com/cubism/ <comment><USER2> Full-screen demo: <http://square.github.com/cubism/demo/>

Part of the Cube 0.2.0 release: <https://github.com/square/cube/wiki/Release- Notes> <http://square.github.com/cube/>

If someone would suggest a reliable, free source of realtime data that won't fall under peak load from HN, I'd be happy to replace the random walk data source with something more realistic. (For example, stock data, wind measurements, etc.) I added a sine to the random walk to make it a bit more interesting, but these visualizations are much more compelling with real data.

<comment><USER3> You guys are doing amazing work at Square. These projects seem to keep reading my mind for what I'd build if I had time to devote to visualization.

Getting a stream off Twitter for words like "square", "visualization", "data", "d3", "javascript" wouldn't be too hard and falls over pretty rarely.

</comment></comment><comment><USER4> We're now using this for production metrics at Square - thanks to the builtin Graphite support - and it's changed everything about how we can visualize them. This is faster, more intuitive, and more beautiful than anything that rrdtool graph or Graphite's grapher can kick out. Absolutely recommended to anybody who needs to have realtime visual feedback about system performance.

</comment><comment><USER5> I'm less interested with the graphing and more interested in Cube itself, which seems to be a nice simple data warehouse solution.

Has anyone used this in production? How does it compare with other data warehousing projects? Are there any prominent alternatives?

<comment><USER6> My startup uses it in production. We probably send a couple million events a day and have a big dashboard with around 40 graphs on it. We also have other dashboards split out for viewing specific things. It works pretty well once we got MongoDB tuned properly. We're receiving events via UDP (which we had to add in, but is supported out of the box in the new version, I believe)

I don't think it's meant to be used as a full-on data warehouse. The closest thing people usually compare it to is Graphite.

</comment></comment><comment><USER7> This new library looks great; it basically lets you do fancy visualizations of time series with data from any time series database. There's Graphite import code already. Square's related project Cube includes its own datastore; Cubism.js just pulls out the visualization part to use with your own datastore.

</comment><comment><USER8> This is interesting, I do want to ask though why you went with stacked graphs as opposed to overlaid line graphs. This makes sense when comparing disparate data points (Load vs Memory vs HTTP Requests), but are you doing this with similar data points as well?

The full screen demo is really what triggered the question for me. I've got a bunch of servers that we monitor and have found that a single graph that shows load for every server gives me a better indicator for those that are outliers. Perhaps you're just not using this for that purpose.

Would love to hear some of the use cases, are you doing all of your graphing with this?

<comment><USER2> We use it for both, but most commonly we use it to compare a single metric (such as CPU or network utilization) across hosts.

Line graphs work well when you only have a few hosts, but start to suffer when you try to plot many hosts simultaneously. Depending on how noisy your metrics are, line graphs are good for showing the envelope, but are less effective at revealing when one or two hosts are behaving oddly; the anomalies get lost in the mess of lines. (It doesn't help that the default colors in Graphite are bad; the host that happens to be assigned bright yellow against a white background becomes much harder to see.)

Small multiples give each host a dedicated row, so you don't have to worry about occlusion or distraction. However, that requires more vertical space, which is why you need horizon graphs or a similar technique to compress them. Scrolling with a vertical rule also helps detect coincident anomalies across metrics.

<comment><USER8> Thanks for the insight. I hadn't seen horizon graphs previously, they're interesting and a great way to compact data and in a way that maintains readability.

Regarding line graphs, there is some visibility loss by having a a single line graph show a ton of servers. I tend to think that deviations that are worth noting tend to stick out. That isn't always going to be the case I suppose, but nothing is 100%.

I'm just not sure how this scales if I've got 100 servers with 2-3 metrics each that I'm tracking. Perhaps this is better for more of a detailed view than a dashboard where where more density is needed. They're certainly more readable then what we use today.

</comment></comment></comment><comment><USER9> Really nice graphics. It might be interesting to be able to select a region and have a pop-out that zooms into that region and maybe shows additional information. For example, showing cpu performance I would like to select a region where performance declines and get a pop-out that shows a more detailed view and includes network, disk access and memory statistics. I am sure there are many more uses though. Keep up the nice work!

Edit: Not really the purpose I know but it was just something that struck me as a possible use case.

</comment><comment><USER10> I was just coding up some d3 time series visualizations, and bang! Square delivers. Thanks mbostock!!

</comment><comment><USER11> Doesnt work in webkit nightly.

        TypeError: '[object HTMLDivElement]' is not a function (evaluating 'callback.apply(this, (arguments[0] = this, arguments))')

<comment><USER2> Lots of things might not work in nightly builds. That's why they're nightly. ;) I tried the latest Mac OS X WebKit r115090 built on 24 April 2012, and it worked fine for me. If the latest nightly doesn't work for you, please let me know by filing an issue on GitHub and giving more details about your OS and version so that I can track down the problem. Thanks!

<https://github.com/square/cubism/issues>

<comment><USER11> Ahh, yeah. I guess because they look so much alike, I mistake WKN's functionality for Safari's (which this does seem to work fine with).

</comment></comment></comment><comment><USER12> first time web guy here. Any answers would be appreciated [http://stackoverflow.com/questions/10326902/how-to-scrape- re...](http://stackoverflow.com/questions/10326902/how-to-scrape-real-time- data-and-load-it-into-cubism-js)

</comment><comment><USER13> Wonderful, I will be able to use this in an upcoming project. Thank you. :)

</comment><comment><USER14> Amazing work!! Bravo Sir, just Bravo!!

</comment><comment><USER15> Doesn't work on android =/

<comment><USER16> Older Android versions don't support SVG (used to render the axes), but it should work in Ice Cream Sandwich.

<comment><USER17> Confirmed: Nexus S, 4.0.4, and it looks fine: <http://imgur.com/N2cLn>

</comment></comment></comment><comment><USER18> This is amazing! Kudos!

</comment><comment><USER19> never heard of horizon charts before, and found it amazing.

<http://vis.berkeley.edu/papers/horizon/>

<comment><USER20> If by "amazing" means "I need an explanation to see what I'm seeing", then I agree with you.

Analytics visualizations are great when they're pretty, but if they aren't comprehensible, you've failed. In the vast (>1) user testing I've done with horizon graphs, it just isn't grokkable.

People in general don't want to look stupid, so they aren't going to volunteer a "hey, what the heck am I looking at here?" They'll just assume they aren't smart enough to get it and be quiet.

<comment><USER2> Agreed; horizon charts take some explanation. However, once you understand what they're showing, they become quite natural. That makes them suitable for dashboards that are monitored by a regular audience (say, production engineers, stock traders), since the viewer learns the first time and then benefits subsequently from the concise representation. However, I probably wouldn't recommend them for a mass audience in a one-off visualization, where the effort to understand might be beyond the viewer's patience for a single viewing.</comment></comment></comment>


Do College Admissions by Lottery - <AUTHOR> http://www.nytimes.com/roomfordebate/2015/03/31/how-to-improve-the-college-admissions-process/do-college-admissions-by-lottery <comment><USER2> Not a bad idea. Personally I'd still reform it based on the Australian system, though.

Rank every single graduating high school student, via a series of tests, from smartest to dumbest. Let each kid nominate their college preferences on a form. Universities then offer places to the students who nominated them based purely on their ranking. (There's some messing around for second, third preferences and the like). Done! Easy!</comment>


Show HN: Hyperpixel – Best landing pages for inspiration - <AUTHOR> https://hyperpixel.io/ <comment><USER2> To be honest, I dislike any landing page that makes it hard for me to figure out what the product/company/service does. There's this new trend where too many landings focus on the "one-liners" that look more of an advertisement rather than an actual tagline.

Don't get me wrong, I love the site! You've done a great job with the design and I really enjoyed discovering some landings that are straight to the point and beautiful.

<comment><USER3> > too many landings focus on the "one-liners" that look more of an > advertisement rather than an actual tagline

I'm not sure how you judge "too many" \-- every major site has A/B tested their one liners to death, and what you see are the winners..

<comment><USER4> I think his point is that they shouldn't be using one liners at all, despite line A winning over BCD. He wants them to instead use proper text and descriptions.

<comment><USER3> Well, the transition from "proper text and descriptions" to one-liners was thoroughly A/B tested too, over the course of a decade, by millions of web sites.

Ultimately, on majority of sites large majority of visitors didn't read "proper text and descriptions". Monkeys like shiny things.

<comment><USER5> > the transition from "proper text and descriptions" to one-liners was > thoroughly A/B tested too

I have my doubts on that.. I'm pretty sure the transition occurred before A/B web testing actually became popular. One liners are _instantaneously_ more appealing than a block of text, even if their long-term usage is worse for the user. (which would also throw off A/B testing, if it did occur)

Blocks also tend to be done with significantly less stylization, aka less work, so you'll also see projects starting with a block of text (just shitting out information, because its easy), and later working towards the more modern and appealing one-liner. And it takes a good deal of work. So you've got the affects of cargo-culting and investment involved as well.

And finally, more likely than not, most of those websites _didn 't_ have the resources, time or interest to A/B test this, and if they did, not thoroughly. It's easy to imagine someone with no design background looking to ape something (because they're not interested in this, just need to shit it out), so they'll hit the standard _design-notable_ sites, and see the one-liner + image. Looks good enough, Apple probably did their homework, why the hell not. Of course, I'm in the business of software, and no one knows my name or has any inkling of what I do, but what the hell.

And then of course because its become popular now you have frameworks popping up to help build in that particular fashion, and it becomes simpler/easier to do that than anything else. So it eventually becomes _unreasonable_ for most sites to do _anything other than this_.

And then it falls out of fashion and we'll move on to _two-liners_

<comment><USER3> Well A/B testing has been around for ages. We did traffic splitting to two variations in the 1990's. No fancy tools, but fundamentally same. In regards to one-liners, there probably were multiple changes occurring over long time, interleaved:

\- Increasing information overload etc changed visitor behavior to prefer less text.

\- Large companies who did A/B testing eventually noticed that change in visitor's preferences and evolved towards one-liners.

\- Some small companies who didn't do A/B testing copied the one-liner style from large companies, when seeking "inspiration".

\- Remaining small companies followed, as one-liners were the dominant trend.

</comment></comment></comment></comment></comment></comment><comment><USER6> This is exactly what I was looking! I was working today on my product landing page - [https://techevents.co/](https://techevents.co/) and started by looking for examples to get some inspiration. And you just combined all together in one place. Very useful, great job!

<comment><AUTHOR> Looks really good!

Thanks! The content is updated every day

</comment></comment><comment><AUTHOR> I eventually ended up with almost a hundred websites in my bookmarks to get inspiration from. This is when I decided to put all that into a more visual aspect.

One feature that needed to be there: the color palette extraction that the landing pages contain. Some websites put colors together without any context, I think that can help

</comment><comment><USER7> The most remarkable thing for me is how similar many of them look, as if it was the same designer doing them all.

</comment><comment><USER3> This would be great with discussions and perhaps ratings.

Basically instead of just looking for inspiration, people could dissect the landing pages and share opinions/ideas about them for learning purposes.

<comment><AUTHOR> That's a good idea, it is written in the roadmap, I'm just wondering how to implement it. Some similar websites propose this feature but the discussions remain empty. Maybe I should propose a :clap: counter

<comment><USER3> Personally, i wouldn't care at all for some like/clap counter by itself, but I'd be interested in honest, brutal, in-depth, professional dissecting of landing pages.

I haven't surveyed current alternatives so there might already be something decent, but everything i've bumped into has been shallow "wow +1 plz visit my page" stuff.

But of course building community for digital marketing professionals is entirely different undertaking than having gallery of landing pages..

<comment><AUTHOR> That's a good point. I was wondering how I could blog around those, and this is so far the best SEO that could be done. It would require time, or at least until I find a process. Maybe there are contents that I could automate, or I could pick 2 or 3 landing pages a week and review them for the blog or/and the newsletter.</comment></comment></comment></comment>


Unit testing redux containers the better way using jest - <AUTHOR> http://rahulgaba.com/front-end/2018/10/19/unit-testing-redux-containers-the-better-way-using-jest.html <comment><USER2> Maybe I'm missing something here, but I disagree.

>> Since we are exporting a higher order component, it makes testing the component more complicated than it has to be.

What exactly are you testing on the connected container components? I agree with the stack overflow article you linked to, just test the components... not the connected components. [0]

>> While this methods has very less boilerplate code and it allows us to properly test each function, it kind of a hack since we are exporting a function just to make is testable which is a code smell. We should export a part of our code only if it is being used somewhere else, not to test it.

No it's not. Unit tests are good, mocking is the real code smell here.[1] You should in fact have more of these unit tests instead of a bunch of integration tests.[2]

Your container components shouldn't be doing much other than what's listed here.[3]

[0] [https://stackoverflow.com/questions/51943248/react-redux- tes...](https://stackoverflow.com/questions/51943248/react-redux-testing- mapstatetoprops-and-mapdispatchtoprops-with-enzyme-jest)

[1] [https://medium.com/javascript-scene/mocking-is-a-code- smell-...](https://medium.com/javascript-scene/mocking-is-a-code- smell-944a70c90a6a)

[2] [https://martinfowler.com/articles/practical-test- pyramid.htm...](https://martinfowler.com/articles/practical-test-pyramid.html)

[3] [https://medium.com/@dan_abramov/smart-and-dumb- components-7c...](https://medium.com/@dan_abramov/smart-and-dumb- components-7ca2f9a7c7d0)</comment>


If your website isn't mobile responsive yet, you're losing sales - <AUTHOR> http://catchi.co.nz/articles/persuasion-usability/why-mobile-optimisation-must-be-a-high-priority-to-avoid-plummeting-online-revenue/

<comment><USER2> If your website requires me to click an "X" and "No thanks" on a full-screen popover, has distracting "like", "favorite", and "reddit" buttons, and fails to finish because one of the 67 HTTP requests hangs, you are losing sales.</comment>


Fighting Theranos Charges, Holmes Blames Advocacy Journalism - <AUTHOR> https://www.bloomberg.com/news/articles/2019-06-28/fighting-theranos-charges-holmes-blames-advocacy-journalism <comment><USER2> [https://www.outline.com/XpHwfh](https://www.outline.com/XpHwfh)

</comment><comment><USER3> If it weren't for those meddling kids, I would've got away with it!

</comment><comment><USER4> Why can't people stay on subject

</comment><comment><USER5> The cause of my Getting Caught was all the pesky Finding Out</comment>


XMPP: A Communication Protocol for the Internet of Things - <AUTHOR> https://www.briskbraintech.com/xmpp-a-communication-protocol-for-the-internet-of-things/ <comment><USER3> > XMPP supports federation, which means that devices from different > manufacturers connected to different platforms can talk to each other with a > standard communication protocol.

The idea behind federation with XMPP for humans (aka, Jabber) is that my friend can have an account on server A (firstname.lastname@example.com), and I can have an account on server B (firstname.lastname@example.com), and we can tell each other our addresses (because we know each other in real life), and then get messages to each other, which is cool, because we're friends, and both know English, and so will be able to meaningfully communicate. Not bad!

The idea behind federation with XMPP for IoT devices is...what? That my smart lighbulb can be talking to a control server run by Phillips, and my smart fridge will be talking to a server run by Samsung, and...they have no idea each other exists, have no ability to address each other, and have no ability to generate messages the other can consume, because they're completely different devices, from different manufacturers, with different protocols? Even if the fridge wanted to tell the smart lightbulb to turn on when the door is open, they need a shared "lightbulb control protocol", no? This feels like claiming email lets any two people on Earth hold a meaningful conversation; just because you can transport the message to the recipient doesn't mean they can understand the language of the message.

How does federation help here? Or any other XMPP feature? There's just no attempt to tie any XMPP feature or characteristic to the nominal use case.

<comment><USER4> It'd be cool if the fridge just announces "my door has just been opened", and a controller decides what to do with the lightbulb (or should the logic be on the bulb with some parsing like if (device == "refrigerator" and location == my.location and component == "door" and state == "open") { ... }?)

It'd be cool if the sunroof can open when it gets the message from the weather monitor that it's a nice day out, and the AC can switch off when it gets the message that the sunroof is opening...

<comment><USER5> Federation won't solve tha.

Heck, the best way for your house is to use multicast, with a unique IP for each endpoint type, and a unique port for each distinct endpoint within the type.

The endpoint IDs could even be self assigned, with the idea that you'd only really need a gateway for use outside the home. Standard but extendable protocols can be developed too, so everything can interop but still include custom stuff beyond the standard.

<comment><USER6> Apple's Bonjour protocol?

<comment><USER7> Bonjour is actually an XMPP extension. [https://xmpp.org/extensions/xep-0174.html](https://xmpp.org/extensions/xep-0174.html)

<comment><USER8> Bonjour is Apple's name for their implementation of mDNS service discovery. It doesn't involve XMPP.

XEP-0174 is a peer-to-peer extension to XMPP which uses mDNS ("Bonjour") to discover other clients on a local network. For a while, Apple had an implementation of this in iChat.

<comment><USER5> I think they still do, in Messages

<comment><USER8> Not anymore. I believe XMPP support was finally removed from Messages in macOS 10.14. (Almost nobody noticed.)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> People who worked extensively with XMPP in the past told me that it just wasn't cut for the current paradigm, with real-time and asynchronous communication, network hopping (mobile, wifi, etc) and just the way things evolved since... 1999. There were some changes planned but apparently the whole thing would be better off rewritten in a new form, and the effort never really kicked off, much like the protocol itself faded from use as we moved towards more and more hybrid networks and uses.

It's a sad realization, I always thought XMPP would save the day some day, but apparently there's a lot of work between now and there. And it might just as well be called something else. I think the latest move towards HTTP/3 enforcing SSL1.3 is one way to envision a fully secured web, 10 years from now.

<comment><USER7> We work extensively with XMPP, so I can speak with some authority on this topic.

It is true, the protocol was invented in 1999 for then-relevant conditions. There are good things - everything that is related to federation works remarkably well, and bad things - multi-device usage, reconnection, etc.

However, the very thing that is mostly panned here by Matrix proponents - modularity and extensibility - allows to uplift it for the modern world. Actually, we recently did just that, by developing a bunch of new protocols and implementing them on an XMPP server. I'll spare the verbose details, but in short, we redesigned reconnection process from a resumption of an XML stream to restoration of messenger state, and it works rather well. That set of protocol extensions greatly helps to improve the performance of our upcoming XMPP client.

<comment><USER10> Who are "we" and what client/projects are you working on? Are these changes new public XEPs that others can/will implement?

<comment><USER7> "We" are makers of Xabber, a popular XMPP client for Android. It had gotten a bit stale lately: a few years ago we figured out that XMPP improvement should start on the server-side, so we diverted all our resources towards creating a set of protocol and implementation it on a server, an alpha version of which was released last month, it has a built-in an insanely great web version of Xabber, which likely offers the best XMPP UX ever, on any platform. We also plan to release an iOS version of Xabber soon - this month or next.

Our protocols are public, and we plan to submit them to XSF, once we're done translating them from our native language. Hopefully, these XEPs would be supported one day by other clients. We believe they are crucial for XMPP future.

<comment><USER10> Very interesting. Which server are you enhancing? Do you provide xmpp hosting?

<comment><USER7> We forked ejabberd because it's the best existing XMPP server. We do provide XMPP hosting (at xabber.com/xabber.org domains), but currently, it's just standard ejabberd, a transition to our own build will come later, hopefully, this year. We also plan to provide domain hosting.

</comment></comment></comment></comment></comment></comment><comment><USER11> My GE Microwave uses XMPP for its control. It sends its status using a JSON object of hexadecimal addresses and values: [https://brianhenryie.s3.amazonaws.com/2019/door_opened.xmpp....](https://brianhenryie.s3.amazonaws.com/2019/door_opened.xmpp.log.html)

I started reverse engineering it but haven't quite finished. The plan is to connect it to Home Assistant and negate any need to communicate outside my house. To get the above output, I wrote a tool for logging the communication in iOS: [https://github.com/brianhenryie/xmppframeworklogger](https://github.com/brianhenryie/xmppframeworklogger)

</comment><comment><USER12> For some reason the article doesn't mention it, but there is a few retracted XEPs for IoT (sensor data[0], provisioning[1], control[2], etc). I think it would be neat if they've incorporated Semantic Sensor Network Ontology[3] and were actually used. But it seems that in practice there are mostly custom and unspecified binary protocols, with inherent TOCTOU issues, awkward integrity checks, and with no security measures (anecdata, based on 7-8 years of dealing with various devices that can be classified as IoT).

Regarding the use of XMPP for it, as pointed in other comments, it indeed looks like unnecessary overhead, but I think it is quite similar to using HTTP for transfer of things other than hypertext: not a perfect fit, but already has good software support, standards, and additional features that are useful. And perhaps more importantly, no wheels to reinvent poorly and hide from customers.

[0] [https://xmpp.org/extensions/xep-0323.html](https://xmpp.org/extensions/xep-0323.html)

[1] [https://xmpp.org/extensions/xep-0324.html](https://xmpp.org/extensions/xep-0324.html)

[2] [https://xmpp.org/extensions/xep-0325.html](https://xmpp.org/extensions/xep-0325.html)

[3] [https://www.w3.org/TR/2017/REC-vocab- ssn-20171019/](https://www.w3.org/TR/2017/REC-vocab-ssn-20171019/)

</comment><comment><USER13> Why XMPP? Seems a bit of unneeded overhead.

<comment><USER14> Indeed. XML itself is nontrivial to parse and the "infinite" extensibility is just overkill for probably 99% of the time I've seen it used, XMPP included.

As an aside, this article seems quite devoid of actual content, bordering on spam IMHO. The title mentions IoT but the term appears only _once_ in the entire article at the end, in a vague "XMPP is for messaging and IoT also needs messaging, so.... XMPP and IoT!" way. This is the sort of page that clogs search engine results with useless non-content.

<comment><USER8> XMPP's own extensibility is a huge stumbling block as well. Almost every major feature of the protocol is implemented as an optional extension, so it's very difficult for clients to rely on anything being consistently available.

<comment><USER15> Well you have a choice. You make a protocol extensible and live with the fact that people are eventually going to extend it. Otherwise you choose a different fixed protocol for each and every task and live with the fact that you will never get any level of interoperability at all.

If one complains about extensible protocols, one should be willing to come up with some other approach that works.

</comment></comment></comment></comment><comment><USER16> Any IOT protocol should be lightweight and ideally UDP, 3 ways TCP handshake takes too long, XMPP is supper verbose. Use HTTP like the mozilla IOT thing for that... MQTT QOS 0 is pretty ok.

<comment><USER17> Ideally you absolutely don't use UDP if you care about data delivery, or you just reinvent a poor implementation of TCP. I want my smart light to come on, my doorbell to ring, and my dryer to tell me the cycle is complete 100% of the time.

<comment><USER16> yes, if you care about delivery you also dont use MQTT QOS 0, use 1 or 2. FOr sensors that report often (and you can loose some packets in the middle) or idempotent actions that you can repeat should be fine though.

</comment></comment></comment><comment><USER18> At this point, please just let XMPP meet it's long overdue death.

<comment><USER7> Rumors of XMPP imminent death are greatly exaggerated.

</comment></comment><comment><USER19> XMPP was too heavy even for its intended purpose - chat.

MQTT is the way to go for IoT.

MQTT at the edge, Kafka at the core.

<comment><USER7> Do you know a better "less heavy" solution for federated chat? Matrix? That matrix which server can handle 50x fewer users than ejabberd on similar hardware?

<comment><USER19> Yes, Erlang was designed for fault-tolerant distributed scalable concurrent chat :)

There is a good Erlang MQTT broker: emqtt / EMQX.

</comment></comment></comment><comment><USER20> I really wanted XMPP to work, but it was a hard protocol to like. It ticked a lot of the right boxes on paper, but in practice it didn't always lend itself to efficient or neat implementation. It didn't feel like it was designed by programmers for programmers.

(A feeling I'm very familiar with these days as I work in the telco business - an entire business that knows fuck-all about how you create standards that lend themselves to clear implementation)

It kind of started off on the wrong foot by using XML. XML is too complicated. There is too much freedom, and freedom to screw things up. It also puts too much flexibility and semantics in the wrong place. Complexity, gnarly performance characteristics and design dilemmas abound.

And not paying attention to important detail such as cheap and predictable message framing is such a boneheaded mistake - you have to pay attention to things that make implementation awkward. It is the first problem you need to solve when creating a somewhat performant implementation and you find yourself stumbling out of the gates having to compromise. Sometimes by having more than one XML parser - one to do framing and one to deal with messages.

It has been many years since I worked on anything XMPP-related. I have no idea if XMPP has improved (probably a good idea to spend a weekend playing with XMPP again to have a look). But if it still depends as heavily on XML, it is not for IoT.

Please do not put it in IoT devices. Please, please, please.

IoT spans from devices with systems more powerful than your desktop computer (in kilowatts and MIPS) to small systems that have perhaps hundreds of BYTES of RAM.

While microcontrollers are getting bigger, with some having megabytes of flash and even hundreds of kilobytes of memory, the most interesting growth areas are in devices that use very little power. Ofte as little as a dim LED. And when they sleep, which many do most of the time, they need to draw so little current you'll spend many sleepless nights poring over datasheets to figure out if there's a voltage regulator out there that doesn't blow your entire energy budget.

For the big systems you can do whatever you want. Go crazy. For constrained devices, not so much.

If you need some infrastructure for communication that is to be useful, you have to be able to scale down. Paradoxically scaling up is easy - <USER2> things down is hard. It tends to make systems grow ugly warts when you create adapters all over the place to translate between domains.

And it isn't just about size. It is about asymmetries in communication patterns as well.

More primitive protocols are quite popular (like MQTT and CoAP). Things that can be done with more or less constant memory and CPU requirements. But they're not necessarily great for everything. And people do not necessarily understand how to design with them. They tend to exist at the edges of systems and concern themselves with hauling data back and forth between constrained devices and the luxury world of more powerful computers.

Then there's the traditional embedded world where it feels like you are always dealing with hermits that got cut off from the rest of the world 25 years ago. Things are getting better as the embedded world is gradually being invaded by more mainstream programmers, but it is painful to watch. People who aren't very good at software versus people who aren't very good with constraints.

What is almost shocking is when you get a peek inside the kimono of different embedded companies / chip manufacturers and you realize the stark difference between where they are in a developmental sense. Some understand where they need to go, and mainly struggle with getting there - others just have no clue how far behind they are from where they need to be.

And then mix in politics, companies that are hysterically protective about their IPR, and the time pressures that exist, and you have multiple culture collisions at once.

I can understand the attraction of XMPP. I really can. But if you ask me we need to do messaging over again. And it has to do less - not more.

</comment><comment><USER21> Far too verbose to take seriously. Small devices don't have enough memory to store all those strings, or do complex parsing. Then again we are discussing 'IoT' which is sort of like the tooth fairy... so basis in reality is optional.

</comment><comment><USER22> XMPP for this purpose feels like an overkill. Open Sound Control might be an interesting alternative. After all, like MQTT, it originated in a world where equipment needed to talk to each other.

</comment><comment><USER23> Offtopic: what are your thoughts on PJON (pjon.org)?

</comment><comment><USER24> I guess if you have one really bad idea, you can't make it any worse by mashing it up with another really bad idea, right?

</comment><comment><USER25> Ugh, is there a reason your web page doesn't work with my PAGEUP, PAGEDOWN or arrow keys?

<comment><USER26> Ironically the fault is due some code intended to make scrolling smoother but some bug is making it so instead it doesn't scroll at all (source: [https://i.imgur.com/XIewJXS.png](https://i.imgur.com/XIewJXS.png))

<comment><USER14> In practice, "smoother" almost always means laggy and sluggish. It's one of the things I always turn off upon a new install of a browser.

<comment><USER27> This is not a browser feature, this is a JS-provided thing. IME, the browser smooth scroll is pretty neat, but website-provided implementations suck.</comment></comment></comment></comment>


Here is now available on iOS - <AUTHOR> https://e.here.com/pub/sf/FormLink?_ri_=X0Gzc2X%3DWQpglLjHJlYQGhXzg3kPWqgoErouuRorKWvza7cl7nCB2H3m2lVXMtX%3DWQpglLjHJlYQGNNzgDdDkFOgpUhRpzaAizg8oEJygY0zblU2TJ5e&_ei_=EvG965vsLsiGbOb9xb3O9Qm7vk9HHlB9MrCE7Os_ljDOBDWON0H5G8jv-bF6EvdPYxakxKVraZ_tfe_FRe0eCXNEnXEE9MqVI5Mm0a2p8M.

<comment><USER2> The ability to download maps for use offline has been useful for international travel. GPS on with data roaming off comes in super handy in a pinch.

</comment><comment><USER3> Doesn't seem to work with Pioneer's AppRadio or with Apple's Carplay.

Being able to display on the vehicle head-unit is a killer feature for me on a GPS app, so I'll be sticking with Waze for now.</comment>


Dear Marginalized People Coming Into Tech - <AUTHOR> http://modelviewculture.com/pieces/dear-marginalized-people-coming-into-tech

<comment><USER2> Is there a group for older white males trying to break into the industry?

<comment><USER3> > Is there a group for older white males trying to break into the industry?

Uh, the ACM?

Or any of a number of professional organizations where being older, white, and male will typically confer an image of knowledge and competency. I seriously hope you are joking, but this tired refrain "nobody gave _me_ any special treatment" is so terrifically ignorant of social reality and insulting to anyone who has ever been followed by store security simply for not being white.

And why, pray tell, would the industry even need to encourage more older white males to join what ranks are clearly swollen by this demographic? The entire point, in case you were too self-absorbed to notice, of encouraging marginalized people to join the tech industry is to ensure a diversity of ideas and opinions, rather than risk becoming a narrowly focused homogeneous echo chamber incapable of sustaining any real innovation because everyone thinks exactly alike.

<comment><USER2> Whoa...you read WAY too much into my question.

I understood the point of the article perfectly well.

I am an older white male trying to get into web development. I'm sure there are plenty like me already in the industry, but I've heard, anecdotally, that it can be hard for someone of my age to break into the industry. Ageism, if you will.

My question was serious, but perhaps misplaced.

<comment><USER4> Ageism is real, but if you start going to your local meetup groups, you'll be in good shape. As a young guy, I've discovered I have a bias for assuming all older people at a meetup have at least 15 years of experience on me.

Some people will hold age against you. Those people are small minded assholes -- be glad they're self selecting out.

</comment></comment></comment></comment><comment> vezzy-fnord _The tech industry is undeniably dominated by straight white men (much like the rest of the world, surprise surprise)._

I realize this article is basically a pep talk for minorities, but I'd just like to point out that, in fact, there exists a world outside of the West.</comment>


University yoga class canceled because of 'oppression, cultural genocide' - <AUTHOR> https://www.washingtonpost.com/news/morning-mix/wp/2015/11/23/university-yoga-class-canceled-because-of-oppression-cultural-genocide/\ <comment><USER2> Link is broken, remove the backslash at the end to fix it: [https://www.washingtonpost.com/news/morning- mix/wp/2015/11/2...](https://www.washingtonpost.com/news/morning- mix/wp/2015/11/23/university-yoga-class-canceled-because-of-oppression- cultural-genocide/)

<comment><USER3> ^ he means forward slash. Dang DOS newbies... ;)

Yes... ironic to get a -404 given the title referring to cancellation

</comment></comment><comment><USER4> _The higher-ups at the student federation got involved, finally we got an e-mail routed through the student federation basically saying they couldn't get a French name and nobody wants to do it, so we're going to cancel it for now._

This, to me, is the best part of the story. She had a workaround using a different name because she didn't really care about "yoga", and that didn't work out either because of the "everything needs a French name" rule.

</comment><comment><USER5> Every day that passes, real life becomes more and more like something out of The Onion.</comment>


Socialtext founders launch Pingpad, a single app for chatting and collaborating - <AUTHOR> http://www.venturebeat.com/2015/09/22/socialtext-founders-launch-pingpad-a-single-app-for-chatting-and-collaborating/ <comment><USER2> And what's the disposition of SocialText? A key detail the author of this story would be wise to include.

<comment><USER3> After extensive research, I uncovered key details about SocialText at the following website

[http://www.socialtext.com/](http://www.socialtext.com/)

<comment><USER2> Your sarcasm isn't appreciated. I want to know why the founders left their company, and are creating a new company that is in a related space.

Why didn't they just do it as a part of SocialText?

And what should the current SocialText employees think about their founders leaving and basically starting over, with a fresh cap table, while they try to make something of value with the remains of a founder-less company?

<comment><USER3> Those are all fine questions, but your original was just "what happened to ST?", which begged for an lmgtfy :-)

Myself, I wouldn't suspect any particularly interesting backstory here. ST was founded thirteen years ago (!), and Ross left a while ago.</comment></comment></comment></comment>


Crowdfounders back homophobic pizzas [video] - <AUTHOR> http://www.wired.com/2015/04/week-on-the-internet-17/

<comment><USER2> Religion is so weird.</comment>


Aluminium recycling – How it works [YouTube 2015] - <AUTHOR> https://www.youtube.com/watch?v=chIFt2A9MRI <comment><AUTHOR> I'm wondering if this is the technology enabling Apple's recycled Aluminium products.

The airjet sorter with X-ray detection at 5:27 is particularly crazy.</comment>


Ask HN: Some good engineering blogs that go through the design process? - <AUTHOR> Are there any good engineering (company or community based) blogs that delve into the design process while building their systems/products?<p>I'd like to understand how teams compare tradeoffs, handle technical difficulties while designing systems for their products. <comment><USER2> I curate a bunch of articles (about 10 every weekday) on [https://discoverdev.io](https://discoverdev.io)

A lot of articles are companies describing their exact issue, possible designs considered and final design adopted. Check out the tags "#software- architecture" ([https://www.discoverdev.io/tags/software- architecture](https://www.discoverdev.io/tags/software-architecture)) or "#scaling" ([https://www.discoverdev.io/tags/scaling](https://www.discoverdev.io/tags/scaling)) for articles that you're looking for.

I've been doing this for about two years now and perhaps curated about 5000 such blogposts!

</comment><comment><USER3> Interesting you've mentioned this. I'm working on a series of YouTube videos that is aimed to teach engineers a) how to think and design an application from scratch and b) How this process works at companies so they get a sense of what it's like professionally.

The channel is called "Think Code" and I'm working on different videos focused on a) teaching people how to code quickly and easily (free of course), b) give junior engineers and understanding of what's expected from them professionally and c) share advice to engineers on how to become better engineers. e.g., problem solving, how to learn new systems quickly, trouble shooting tips, practical advice on scrum that actually works, etc.

Let me know if you would be interested. I'm working on releasing videos next week.

</comment><comment><USER4> The Uber Engineering Blog[0] is the first thing that that comes to my mind.

It has posts describing optimizations and approaches they took in certain subsystems.

[0] [https://eng.uber.com/](https://eng.uber.com/)

</comment><comment><USER5> My personal favorites are Ebay Engineering Blog - [https://www.ebayinc.com/stories/blogs/tech/](https://www.ebayinc.com/stories/blogs/tech/)

And Toptal blog.

</comment><comment><USER6> [https://github.com/kilimchoi/engineering- blogs](https://github.com/kilimchoi/engineering-blogs) has a list of engineering blogs [https://github.com/donnemartin/system-design- primer](https://github.com/donnemartin/system-design-primer) good resource into distributed system design

</comment><comment><USER7> These sites are not blogs, but might still be worth exploring:

[http://aosabook.org/en/index.html](http://aosabook.org/en/index.html)

and

[https://softwareengineering.stackexchange.com/questions?sort...](https://softwareengineering.stackexchange.com/questions?sort=votes)

</comment><comment><USER8> I write a blog on building a SaaS app. I go pretty deep into design, implementation etc. Two articles hit the HN front page in the last month.

Https://blog.checklyhq.com

</comment><comment><USER9> A curated list of engineering blogs is here: [https://twitter.com/engblogs](https://twitter.com/engblogs)</comment>


Uber Isn't Letting Its Drivers Carry Guns Anymore - <AUTHOR> http://www.newrepublic.com/article/122094/uber-isnt-letting-its-drivers-carry-guns-anymore <comment><USER2> _> We have adopted a no-firearms policy to ensure that both riders and drivers feel safe and comfortable on the platform._

As a driver, I would feel less safe with a firearm _not_ in my car. The reason I would have a firearm in my car is because it provides me with peace of mind in my safety. That statement is silly. The reason drivers would have guns in their car is because it makes them feel more safe. If they felt less safe, they wouldn't be keeping a gun in their car. Would they?

 _> The companies' differing policies came to light after an Uber driver in Chicago shot a man who was firing a pistol into a group of people. The Uber driver, who was not named and who had a concealed carry permit, had dropped off a passenger only minutes before pulling out his gun and firing six times at the man shooting a pistol. _

So a Chicago man potentially _saved peoples ' lives_ thanks to having a gun, this brings up the differing policies, and Uber bans guns instead of Lyft allowing them? Strange how that reasoning works. Is there a detail I'm missing? Did he shoot a lone officer firing into a crowd of 6 criminals?

<comment><USER3> You're overlooking the possibility that drivers who don't want firearms in the car might prefer a policy that forbids passengers who are carrying. If there's a clear majority preference that's the opposite of yours then Uber's business interests will incline them towards pleasing the larger rather than the smaller group, regardless of whether you find the majority's position logical or persuasive.

<comment><USER2> _> You're overlooking the possibility that drivers who don't want firearms in the car might prefer a policy that forbids passengers who are carrying._

You're correct, I did overlook that in my pro-gun leaning bias and my pro- logic leaning biases.

Fluff policies that don't actually _do_ anything in practice are weird to me. I don't see how this actually provides comfort to anyone who feels uncomfortable around guns. But hey, if a placebo policy works for people. It works. * shrugs * If a person is carrying a concealed weapon or a weapon in a backpack/purse, it's not like the driver is going to know. This policy only affects drivers/passengers who are _known_ to be carrying a firearm. Drivers can still carry one in the glovebox so long as passengers don't find out about it, etc.

But yes - from a business perspective. You do what's more popular. If the popular action is to have a fluff policy, you add the fluff policy. It's not like it actually _changes_ anything and it wins you some PR brownies. Sometimes I forget to put my business glasses on when looking at things like this.

<comment><USER3> Dragonwriter points out the business case for this: it lets Uber shift liability entirely to the firearm owner (and shifting liability onto other parties is arguably the core of their business model and a fundamental characteristic of platform capitalism in general).

I'm not sure what the disclosure laws are for public v. private companies, but liability situations create material risk for investors and those material risks have to be budgeted for and built into a firm's financials. Uber clearly aspires to be a global company. They're going to look at the risk that a driver or passenger draws and fires their gun, and the risk that they might be sued by the victim or victim's family, as well as the PR cost of stories like 'Uber driver/passenger kills person' or 'Uber/driver passenger kills innocent person' etc. etc. The probabilities of guns being used unsafely or irresponsibly might be very low, but we know that in the aggregate there are many injuries and deaths every year from negligent use, and we can extrapolate from that to the possibility of an Uber employee or customer being either a victim or a perpetrator of an illegal or negligent act involving a firearm.

To put it bluntly, the cost to Uber's bottom line of a driver or passenger becoming a victim of crime due to _not_ having a gun is likely much lower than the cost of a driver or passenger killing someone, even if the probability of the former event is much higher. Get shot as an Uber driver, everyone feels sorrry, but it's the shooter's fault rather than Uber's you chose to work as an Uber driver and pick up a fare from right outside the OK corral, you might have been killed anyway before having time to draw your gun (like those two police in New York sitting in their patrol car a while back) - too bad, so sad. If an Uber driver were to kill someone without good reason then it would just be a legal horrorshow - years of discovery, high profile court case, reams of adverse publicity, hideously expensive settlement _at best_.

I don't know what Uber is valued at right now, $20 billion or something? If it were a person, that would put it among the world's wealthiest individuals. The brutal reality is that your life is probably worth no more than a couple of million, and quantifiable value is the only kind that matters in capitalism.

<comment><USER4> >Get shot as an Uber driver, everyone feels sorrry (sic), but it's the shooter's fault rather than Uber's

But this policy change could now expose them -- since Uber explicitly forbids the driver from carrying for self-defense, its policy guarantees a defenseless victim.

<comment><USER3> Yes, but what's the incentive to hold up an Uber driver, who isn't being paid in cash? OK, this doesn't prevent drivers from being selected by psychopaths or people who are intent on stealing cars and wanting to minimize risk, but the necessity to register a phone and a credit card to sign up for Uber service acts as an effective deterrent to most criminals in the first place.

And when you get down to it, a) nobody needs to drive for Uber, so if you don't like the risk calculus, don't do it; b) guaranteeing a defenceless victim is a lot less blameworthy than shooting people, notwithstanding the nutbags on fox news trying to hold a preacher responsible for being gunned down in his church the other day, and c) the legal & PR liability from leaving someone at risk is still massively lower than the liability from facilitating a (hypothetical) crime - sins of omission are always punished less severely than sins of commission.

I'm not saying this policy of Uber's is fair or rational for society at large, just that it is rational from the self-serving POV of the firm itself.</comment></comment></comment></comment></comment></comment>


Overreliance on hand sanitizers may increase risk of virus infection - <AUTHOR> https://japantoday.com/category/national/focus-overreliance-on-hand-sanitizers-may-increase-risk-of-virus-infection <comment><AUTHOR> See also the useful document from the US CDC: "When is clean too clean?" [https://wwwnc.cdc.gov/eid/article/7/2/70-0225_article](https://wwwnc.cdc.gov/eid/article/7/2/70-0225_article)</comment>


JSDB.io - A Database of JavaScript Libraries - <AUTHOR> http://www.jsdb.io

<comment><USER2> JSDB is the name of a javascript cross-platform environment based on SpiderMonkey, that exists since 2005 and is still active.

<http://jsdb.org/>

<comment><USER3> That doesn't seem like a very good name. Why "DB"?

<comment><USER4> From the front page: "JSDB is JavaScript for databases, a scripting language for data-driven, network-centric programming on Windows, Mac, Linux, and SunOS. JSDB works with databases, XML, the web, and email. It is free and open-source. Use it as a JavaScript shell, to run CGI programs, or as a web server."

<comment><USER3> But, that's kind of a silly reason right? It's obviously a general purpose server platform. Nobody would say "NodeJS/perl/ruby/python/PHP/C++/Go/Java is for databases".

<comment><USER5> Actually, it was originally designed to allow quick access to databases, but grew very quickly. So, no, not a silly reason at all.

<comment><USER6> It doesn't sound like it has much to do with databases anymore, so the name really doesn't seem to fit.

<comment><USER2> Hacker news doesn't have that much to do with hacking these days either, do you think it should change?

<comment><USER7> I believe hacker news is very much so relevant to hackers. <http://en.wikipedia.org/wiki/Hacker_(programmer_subculture)>

I believe that jsdb.io is also a fine name for a database of js libraries. I find it easy to remember. While looking at the url might be misleading before you've visited, once you've seen the site it'll be clear.

<comment><USER2> That was tongue-in-cheek, see the parent comment.

BTW, I don't think jsdb is a bad name, but it's already taken.

<comment><AUTHOR> With two unrelated projects I don't see a huge problem... People are not going to confuse the two, and I dont want to go into which is "more appropriate". Both jsdb.org and jsdb.io are completely free to name themselves as they want. No trademarks, no infringements. It was honestly a really nicely appropriate and memorable name for the service.

It was also a steal for a four letter domain name :)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> In Google Sets[0] I entered CPAN, CTAN, CRAN, CJAN, names of archive repositories for other languages.

It added JSAN.

[0] [http://googlesystem.blogspot.co.uk/2012/11/google-sets- still...](http://googlesystem.blogspot.co.uk/2012/11/google-sets-still- available.html)

</comment><comment><USER9> The library is called jQuery, not Jquery - same with jQuery UI, DOM is an abbreviation.

It looks like you've crudely turned things which aren't words which start with an uppercase letter into ones which do, for no reason.

<comment><AUTHOR> Thanks for the tip. Fixed. Stared at it for so long during development that I didn't even notice!

</comment></comment><comment><USER10> Would be great to have something like this also serve up the JS files via a CDN, and provide a JS-based loader (like require.js for remote scripts). Plus maybe dependency management?

<comment><USER2> That's <http://cdnjs.com/>

<comment><USER10> Ooh, nice; I've seen this before too but forgot all about it. @ksokhan, maybe think of linking up the CDN URL's from cdnjs.com to your site? Your site definitely offers more as far as discoverability.

<comment><USER3> While you're at it, link to <http://npmjs.org/>

e.g., <http://www.jsdb.io/view/socket-io> -> <https://npmjs.org/package/socket.io>

<comment><AUTHOR> Yea, had a few people mention this... definitely my next addition! stay tuned :)

</comment></comment></comment></comment></comment><comment><USER11> Looks useful. Some comments

\- I wish there were a way to sort by name

\- How are the ratings calculated? (Just realized that if you hover on a library's rating it tells you the rating is "derrived (sic) from combination of the other metrics": would be good to know how exactly + "derived" is misspelled.)

<comment><AUTHOR> Ah good point on the first, and working on the second! want to be a bit more transparent, but basically, its simply a combination of the other factors listed with some logical balancing through multipliers. (ie. stars is weighted more than contributor count)

</comment></comment><comment><USER12> I expected the "sort by" thingy to be at the top-right of the list of things I was viewing.

Despite that minor gripe, please accept my compliments. I'd love to see a site that can point me at all the newest and most popular JS tools and maybe this can be it.

<comment><AUTHOR> Thanks for the kind words. The sort by _should_ only list the current page/category. You might be confused because "sort by" ignores pagination and rearranges all of the libraries in that category, and _only then_ re-paginates it... Or am I misunderstanding your comment?

<comment><USER12> Thanks for coming back to me. Let me clarify what I mean.

When I'm on the front page or, especially, once I have selected a category, I want to be able to sort that list by newest/top-rated/last-updated/etc.

I'm used to seeing the option to do that sorting (or filtering, if you ever do that) up at the top of the things I am looking at, rather than by the list of categories.

So, the recommendation I am making is to show any sorting/filtering controls at the top of the list instead of on the left hand side of the page.

<comment><AUTHOR> Aah, yes! That makes sense. Ill take a look at modifying the design to do that, its probably a better UI paradigm.

</comment></comment></comment></comment><comment><USER13> I think a tag system instead of a directory system may be better for categorizing libraries. For example, is D3 is "data / undefined". Arguably it could exist in multiple categories.

<comment><AUTHOR> This is probably the hardest problem to solve in building a tool like this. Ive thought a lot about this, and here is my thinking:

Its not an either-or scenario. Tags are great at grouping similar libraries together, but it doesn't work very well when you look at all the tags together, since there is no clear hierarchy.

Categories are good, on the other hand, for creating a clear structure for looking for libraries. If a user is confused about where to find something specific, they can just search it.

My plan is to combine the two approaches in jsdb: have a clear and very general category system, and a tag system for finding inter-related js libraries.

<comment><USER3> What? Why have two systems?

Just make the categories be system-defined tags. Display your navigation with only them. Let users add new tags but don't display them in the nav.

</comment></comment></comment><comment><USER3> Why require a Github URL? I should be able to give you any number of URLs to any sites for each lib. This would be much more useful!

</comment><comment><USER14> There's also MicroJS:

<http://microjs.com/>

<comment><AUTHOR> Whoa, sweet find! Slightly differently positioned though I think...

</comment></comment><comment><USER15> Looking like a great resource, nice work. +1 on the suggestions to link to npm and cdnsjs.

I did spot that searching for 'require' did not find 'requirejs' (searching 'requirejs' finds it).

<comment><AUTHOR> Yea, good point. The search system leaves a bit to be desired, but I'm working on it!

</comment></comment><comment><USER16> Maybe add Typehead for search form [http://twitter.github.com/bootstrap/javascript.html#typeahea...](http://twitter.github.com/bootstrap/javascript.html#typeahead)

<comment><AUTHOR> Yea, the search system right now is a very basic iteration (I really just wanted to get this launched) but I definitely have plans for making it better. Typeahead is definitely one of the first things I'm going to add.

</comment></comment><comment><USER17> That is pretty cool. I added my game development library/framework as "2D Images", but maybe "Game Development" could be a separate category?

<comment><AUTHOR> Yea, I was thinking of actually adding that, as well as a few other categories. Thanks for the submission!

</comment></comment><comment><USER18> Oddly, you've been working on something very similar to a small project of my own. www.javascriptoo.com. Great work.

</comment><comment><USER3> <http://www.jsdb.io/search?q=closure>

:(

<comment><USER19> <http://www.jsdb.io/submit>

:)

<comment><AUTHOR> The beauty of a collaborative system!

</comment></comment></comment><comment><USER20> Great work. Cheers from the <http://jster.net> folks. :)

<comment><USER21> Looks more mature than JSDB.io - particularly with the larger collection of libraries and tagging system etc. But honestly your site is cluttered and ugly, JSDB is winning there. A twitter feed, really? I think your site needs some clear direction. Just saying.

<comment><USER20> Good points. Any specific ideas? The Twitter feed could go, that's definitely true.

<comment><USER21> Ok, I'll give some suggestions, I'll be blunt. But first you should know that I'm not a web designer - so take them with salt. It might also be worth asking for suggestions as a Hacker News thread? Or perhaps a web-design specific forum. I'm taking an interest because I think the web development world really needs a good site to serve as a list/index/catalog of open-source javascript (and css) libraries, with user ratings and comments etc.

Fundamentally, I think the intent of your design is wrong. Its cluttered and all about the bells and whistles rather than focusing on use-cases and the problems your site should be trying to solve.

(1) Home page Editor's Choice Part Get rid of this, I don't think users care about your editors picks. User's care more what the user base / crowd thinks. So you could perhaps put trending libraries (those receiving a lot of up-votes recently) here instead. Or otherwise just remove it all-together.

Blog Part Also get rid of this. The foremost parts of your homepage should be the Category list and a search box. Also get rid of the tag cloud - doesn't add anything IMO.

Layout and Color Scheme All wrong, too many different colors and shades, jagged lines and shadows everywhere. Less is more here I think.

(2) Category Page Layout Change to a list-view instead of a grid-view. The grid looks too squashed, and users don't mind scrolling - list view is better for responsive design / mobile devices. Also sort the list by rating.

Each Library Increase the font size of the description <\- will work better when you change to a list view instead of a grid. Show the rating larger as well, and then to a lesser extent the GitHub stars etc. Take some design pointers from the StackOverflow question list (<http://stackoverflow.com/unanswered>).

(3) Library Page Comments Shift the DISQUS comments above the 'ALSO ON JSTER' part, put that stuff at the bottom, users care more about comments. Remove the 'RECOMMENDED CONTENT' - its irrelevant and your site is too immature for advertising yet.

Rating System Light bulbs? I honestly think you would be better off with an up/down vote rating system like StackOverflow. A library having a 5/5 rating doesn't mean anything when there is only one vote (probably from the developer who wrote it and submitted the library). If you wanted to make it really smart, you could allow users to up/down vote a library for specific category. For example, users could up-vote the D3.js library within the 'Charting' tag/category only if they wish to - which means the user thinks D3.js is good for charts.

That's all for now - have run out of time.

</comment></comment></comment></comment><comment><USER22> I wish there's a way to sort by the size of the library.

</comment><comment><USER23> or the best among all: Vanilla Js <http://vanilla-js.com/>

<comment><AUTHOR> Thats funny :) took me a bit to figure out the joke

</comment></comment><comment><USER24> very useful link, you should work on interface though..very hard to filter the lib i want...

</comment><comment><USER25> <http://microjs.com/> much easier to browse

<comment><AUTHOR> Can you qualify that? Would love to get help/suggestions on making navigation better...

<comment><USER25> What i meant was, everything on a single page and i could just ctrl-F search the list. JSDB.io is neat too for a larger growing list of JS.

</comment></comment></comment><comment><USER26> maybe needs some more categories. where to put markdown libs?

<comment><AUTHOR> definitely. Working on it! If you are in doubt though, just put in in Miscellaneous and I'll clean it up later :)

<comment><USER27> Nice that you're tweaking things. You may want to move Underscore from "helpers/object-extends" to "application-tools/utilities".

<comment><AUTHOR> Yea, that makes sense. Moved. (I'm a bit doubtful about that helpers category in general, probably going to change it)

</comment></comment></comment></comment><comment><USER28> i like it, hope to see more

</comment><comment><USER29> thank you for making this</comment>