Keys: Musical Keyboard with Gesture Controls, Modularity, and LEDs - <AUTHOR> http://www.playkeys.io

<comment><USER2> Interesting product with an amazing low price point. Being small and inexpensive, I am interesting in seeing how this can moving into educational settings. I loved the part of the video show a toddler learning to play. I will be interested in what the response from musicians will be to using this for performance and as a midi input device for working with audio software.

If you are looking for a traditional keyboard check out the McCarthy Illuminating Piano.

[http://mccarthypiano.com/hardware.aspx](http://mccarthypiano.com/hardware.aspx)

</comment><comment><USER3> The proximity sensor seems very similar to the Roland "D-Beam" infrared light sensor [http://en.wikipedia.org/wiki/D-Beam](http://en.wikipedia.org/wiki/D-Beam), which is itself a bit of a gimmick. The design itself seems inspired by the KMI QuNexus [http://www.keithmcmillen.com/products/qunexus/](http://www.keithmcmillen.com/products/qunexus/) .

<comment><USER4> Also - sorry for the double comment. The design was definitely influenced by similar form factor keyboards like the Op-1 and QuNexus although the latter does not use actual keys but is an MPC like pressure sensitive pad rather than a push/levered/actuated key. Also, in general, the design was influenced by the status quo of how producers / musicians approach such MIDI instruments and why/how they're used.

The biggest difference in our design is the exclusion of all controls, buttons knobs and so on which means that even though the Keys device is about the same size as some of these other portable devices, the keys themselves are nearly the same size and layout ratios as traditional. In other words, full size keys not mini size which is hard to tell in the pictures. This feature, of both our personal opinions and the feedback of professionals we gave Keys to, is significantly more important than any other in a truly useful as well as portable keyboard.

The fact that all controls are removed and the design is purely keys also allows for the modular nature, and the ability to connect Keys together in various ways as well as other modules.

</comment></comment><comment><USER5> Another interesting instrument:

[https://www.kickstarter.com/projects/artiphon/introducing- th...](https://www.kickstarter.com/projects/artiphon/introducing-the-artiphon- instrument-1)

</comment><comment><USER6> Love the creativity. I have observed though that "musical" people can play anything, and non-musical people cannot. It has always been a curious thing which I first noticed in music classes at USC.

<comment><USER7> This is one of those learned things that becomes _inborn_ , I think.

I have a few things I'm pretty good at, and I'll pick up & try anything, because it's fun. Most of the music I make is improvised. And I've been picking up & trying any instrument I run across for decades now, so I have snippets of experience in lots of things now.

My wife studied classical piano from an early age, and can sit down and _sight-read_ stuff I haven't got a chance at playing on any instrument. But she never improvises, never tries out other instruments, and thus can't really do the same thing (pick up anything and make music on it).

We both have a (possibly-inborn) talent for music, but we've taken quite different paths, and those years spent quite differently really show, now.

<comment><USER6> That is an interesting contrast, and similar to ones I've seen. People who have trained on an instrument such as a piano (or violin in one case) from a young age, who are technically proficient but never stray off the music page. And people who like to play around with the notes and try different things, on anything, even non-instruments like soup cans at one campout I was on.

<comment><USER7> Almost anything can be used as an instrument; some easier than others (blowing over the top of a bottle), but just about everything makes noises that can then be organized, modified, etc. :)

You can make surprisingly complicated music just clapping.

I think the crucial difference is just in how we grew up thinking about music.

My wife grew up in a culture where everything was publicly judged, students and performers were rated & ranked, etc.. If you did something and you didn't do it _well_ , you'd better do it in secret.

I wasn't _free_ from those feelings, but it wasn't as emphasized; and as I grew up, I eventually had a good base of things I was known to be good at... which in a way freed me to do other things badly.

And the funny thing about trying lots of new things (and doing them badly) is that practice makes you _better_ rapid competence in new things -- this works in music, but also in anything else in life.

This is what I most want to emphasize whenever anyone talks about people with natural talent for music, for example (which can seem particularly magic to people with little experience of their own).

There are probably some inborn elements involved -- how well your ears work, etc. -- but so much really is learned, and once you're hooked, the amount of "practice" in music and thinking about sound becomes huge.

I'm not a pro performer, and not likely to become one; but it's something I love, so I probably spent 6+ hours a day doing something with music interleaved into it. Not sitting down with an instrument, most of the time, but washing the dishes. Driving the car. Playing with my kids. Walking the dog.

So I can imagine how pervasive it could be for someone really focusing their life on music.

Natural talent, sure; but don't forget the _hundreds of thousands_ of hours some people spend training their minds to the patterns of music.

</comment></comment></comment></comment><comment><USER8> why did they give it a non-standard keyboard layout? having the black keys be higher up & "overlap" front-to-back with the white keys is pretty crucial for playing with any sort of speed. also wary of the button-like keys vs traditional lever-like keys on real pianos.

other than that, the proximity sensor looks awesome, and the price point is pretty incredible! not to mention the light-up stuff for people learning.

<comment><USER4> I was worried about that too when we first started to give it to musicians. We had to test this design out first, before we launched it. I'm not a piano player, but I would produce music on flights to China and back a lot when we were doing manufacturing for the gTar and I would get these midi controllers and they would all break going in and out of my backpack.

That's where the design initially came from, but I knew one of the most important things is that the keys had to be full size. Mini key designs always left something to be desired, and I would just use my laptop keyboard instead - which seemed to be more effective and in the long run more convenient too - since these controllers were really cumbersome.

So when I first gave the design to musicians I was scared that they would immediately reject it. The Keys were full size, but the interface was different than what they were used to. But they made zero mention of it, and you can see in later half the video: [https://www.youtube.com/watch?v=guKRk3WPc40](https://www.youtube.com/watch?v=guKRk3WPc40)

I know no feedback sounds like bad feedback, but in this case it was really positive. These guys would immediately start wailing on keys like it was natural. These are guys that do this for a living, and I didn't hear one comment about the difference in the keys from a traditional piano.

So take it for what it is - We weren't ignorant of the fact that Keys isn't a traditional design, but all the same - this approach also makes it significantly more portable - and the great thing about AMON (the networking stuff) is we could always make a traditional version and it would still work and link with the non-traditional layout.

<comment><USER7> Interesting -- I'd be curious to see what actual musicians would say. It really depends on the type of music you're building with it, I'd say.

I'm not primarily a keyboardist, but I use them; in this case it would surely be tricky to play anything that uses the black keys much; your hands have patterns memorized that (I'd imagine) would be tough to adapt to having the black keys on a separate row.

But because it's MIDI, it really does depend on what you're building, and it might not matter. Recording simple snatches of melody would be fine if you keep away from chromatic lines -- e.g., if you want to add a line that's in C minor, just record it in A minor (all white keys except maybe the G#), then transpose it in a few seconds.

You wouldn't play the Flight of the Bumblebee on it, though.

<comment><USER4> I can't disagree with you, these haven't gone out into the wild yet - but I will say I've seen some truly gifted piano players / keyboardists take to this without any mention of strange finger/hand issues with the layout.

I'll be honest, I'm not a keyboard player. I designed this to be truly mobile and portable without making compromises on the key size, which my theory is that having a full scale keyboard is more important than the traditional design of the keys. The former makes the device useful, and the later makes it familiar but also prevents it from being very portable without shrinking the keys or otherwise compromising on other dimensions.

I've seen people shred on Keys, it's pretty awesome to see, since I can barely play Yankee Doodle - but I'm getting a lot better!

</comment></comment></comment></comment><comment><USER9> I might have missed something, but have they left out touch sensitivity (i.e. velocity)? That's a major deal-breaker!

<comment><USER10> Ideally the dream keyboard would have BOTH.

For playing piano, and other player-volume controlled instruments, you want velocity sensitivity.

For organ, or maybe early electric "pianos" you don't...you want an expression/volume pedal. This is one reason a virtuoso organ player can do things a piano player couldn't - they can use all kinds of "wrong" reachs and finger movements that enable them to play things that they couldn't otherwise.

</comment></comment><comment><USER11> Are these full-size keys?

<comment><USER4> Keys has very close to full ratio keys to a standard piano. If you take it and put it up against a normal piano you'll see the keys span about the same length as two octaves, maybe by a difference of 2-3 mm.

This was a very critical aspect of the design and actually led to the implementation of the proximity sensors. We had to remove all controls to get this size but still be about the width of a 13" laptop - and the need for certain controls like octave transposition was the impetus for looking into other control methodologies like proximity based gestures.</comment></comment>


Delphi Self-Driving Car Completes Coast-to-Coast Trip - <AUTHOR> https://twitter.com/DelphiAuto/status/582607174037176320 <comment><AUTHOR> They have successfully completed a coast-to-coast trip with no human intervention.</comment>


The Seven Deceptions of Microservices - <AUTHOR> https://scottrogowski.com/the-seven-deceptions-of-microservices.html <comment><USER2> Nice article, recognised the pain points that if not excecuted well micro services will increase complexity. Like soa did also. But why bashing architects? You can not develop a large system without an architecture... most architects are well trained to steer agile developments imho.</comment>


Learn HTML5, JavaScript and CSS With Mozilla's Free School of Webcraft - <AUTHOR> https://www.drumbeat.org/webcraft/sign-up

<comment><USER2> Was really hoping for a description or an about piece for that page. The link to the email list goes to a Google group, which is sure to confuse people as well.

Like the idea, just a strange way to execute.

</comment><comment><USER3> I've been running a program with some similar goals that is currently focused on Ruby but will hopefully expand into other areas. ( <http://university.rubymendicant.com> )

I'm really excited to see similar efforts, especially from folks like Mozilla who have considerable resources available to back something like this. But I sort of wonder how well the peer to peer model works, and whether it produces consistent enough results to be able to have a certification system that means anything. Personally, I don't think certification is important, but it seems to be one of the key goals of this project.

Has anyone been involved with the parent project, P2PU? I'd be very interested in hearing what sort of experiences folks have had with that. (<http://p2pu.org>)

</comment><comment><USER4> Confused and no patience for the above link!

</comment><comment><USER5> More information here: <https://www.drumbeat.org/webcraft>

<comment><USER6> Which leads to the even more useful page of: <https://www.drumbeat.org/node/1544/about>

It's a peer-to-peer online university, where students teach courses about the areas they're experts in, while others can gain course credit for taking and performing well on those courses. The hope is to gain some credibility with employers by the end of 2011 and to have ~250 courses offered as an alternative to currently expensive certifications and often outdated university courses on web development.

</comment></comment><comment><USER7> I would have loved to attend those courses. Will they record the courses?

<comment><USER8> It's not all that clear from the link but I believe they are all online courses so anyone can attend. :)

</comment></comment><comment><USER9> Thank you! This looks fantastic, and I am very glad you shared this.

</comment><comment><USER10> Am I supposed to know who the people in those pictures are?

<comment><USER11> Why, they're hipsters, of course! Cool people who became so because they learned HTML5 and liked being seen learning it

</comment></comment><comment><USER12> W3schools seems to cover these pieces, and a number of others, without the self regard and the "teaser" advertising. So does the Google Code University for that matter.

<comment><USER13> W3schools is pretty bad for "teaching" in my experience. It's serviceable as pure reference to look up bits, but even then it's inferior to other references available.

You're right that there are other sources available to learn, and those are awesome...but they are not exactly comparable to this.

For one, most of those other sources just release material, like MIT's open course ware. It's a great resource for learning, but it's not the same as actually being enrolled in a class, participating, etc etc. You also do not receive any kind of credit.

Then there are some places where it actually is a course, but most of those are probably not "peer to peer"...I find that idea pretty interesting, and I had a good experience with Reddit University.

Another thing is this has the name "Mozilla" attached, which carries some cachet with it.

So, overall most of the "pieces" of this are already done yes....but I think this is an interesting combination and am pretty excited at the potential of it.</comment></comment>


A litmus test for an open-source company - <AUTHOR> http://www.sdtimes.com/content/article.aspx?ArticleID=34351&print=true <comment><AUTHOR> Annoying initial ad, but the article is fairly interesting.</comment>


Against the real enemy: why organized labor should join with entrepreneurs - <AUTHOR> http://www.washingtonmonthly.com/magazine/mayjune_2011/features/the_real_enemy_of_unions029138.php

<comment><USER2> The author spends a lot of the article wondering about why Big Labor seems to be whiffing so many obvious opportunities (joining with entrepreneurs is the hook but it's really just one special case of the larger point), but the answer is obvious once you drop the theory for a moment and look at the reality: Big Labor leadership is not the same as Big Labor membership. Leadership has long since become its own entity, and succumbed to the first law of organizations: All organizations inevitably evolve until the perpetuation of their own existence becomes their overriding priority. Big Labor and Big Business are adversarial, certainly, I don't think claiming they are in cahoots adequately explains the behavior we see, but they _do_ require the same basic environment to exist in. Which the article itself points out, but since he's collapsed the two distinct entities into one he isn't quite able to follow through on what it means.

It probably is in the interests of the membership to join with and support entrepreneurs. It is absolutely not in the interest of the leadership to do so.

(I know there is more than one union; I speak in the singular for convenience. In practice it seems to me pretty much every union you've ever heard of is all in the same place.)

The author also trots out the terrible "voting against their best interests" argument (insulting those who don't believe what you do is generally an unpersuasive argument technique) after three pages of explaining how supporting unions has failed to produce the best outcome, the irony apparently lost on the author. I don't vote Democrat precisely because I do not believe it to be in my best interests. I believe with what is IMHO some justification that they tend to trade short-term gains for long term losses, and tend to simply create new entrenched interests instead of protecting mine. I live in Michigan, where the long term losses have arrived. A lot of people have voted their "best interests" around here. Perhaps less insulting and more verification that it really _is_ their "best interests" being served is in order. Second order effects can't be ignored.

The real point of the preceding paragraphs not being to prove that my beliefs are true, as justifying them here would be a waste of time, but that the assumption that not voting Democrat must be motivated by stupidity and lack of self-interest is not fully justified. There are good reasons not to vote Democrat. (There are good reasons not to vote any particular party.)

(Oh, and don't mentally translate "I don't vote Democrat" to "I vote Republican", BTW. It would not be accurate.)

<comment><USER3> Regarding conflicting interests in the unions: <http://news.ycombinator.com/item?id=2599005>

</comment></comment><comment><USER4> This article is silly. Entrepreneurs and unions are natural enemies.

A dynamic entrepreneurial environment is the last thing unions want. In a competitive market with many players and new startups improving things regularly, the union shop will have higher costs than their competitors and they will go out of business. Even if costs are equal right now, a startup will come along and disrupt the industry, destroying any business with rigid contracts.

And if entrepreneurs work with unions, they are playing with fire. What happens when a startup invents the UnionLaborTron (a machine which replaces union laborers)? Work rules incompatible with rapid iteration. My startup employs low skill labor and we have a new workflow every week. If I needed to negotiate with a union rep every time I do that, we would shut down.

</comment><comment><USER5> I can not figure out the premises of the conclusion. I can sort of figure out how small businesses could help labor from the article, but on the other fork - what do unions offer a small businessman?

Thought experiment:

If I found a small software firm, I will need an office, a janitor on Fridays, a secretary, a marketer-type, and some engineers. (well, I'm approximating here, YMMV).

As an employer, I want to pay people enough so they stick around. I want to pay just enough to get the quality of people I need, but not so much the company is run into the ground. I don't see that a union helps me. If I pay people badly, they will leave; at least the people I hired, who I assume are generally hire-able and good enough to find jobs elsewhere.

Politically, I don't want to have to add this or that to my company's operation unless it makes me money (e.g., our top performer needs child leave, and him staying with leave is better than him quitting).

So, what does a union get me in my Pnathansoft firm? I am confused. Please take pity on me and explain. :-/

</comment><comment><USER6> huh. funny, 'cause my understanding that the basic ideas organized labor fights for (e.g. pay based on seniority rather than perceived merit, no firings without a well-documented good reason that involves the employee not following the rules and protectionism on the international front) Are largely incompatible with what most Entrepreneurs need.

I mean, this is my perception, and it may be incorrect, but I think it's a pretty common perception among business owners.

And really, when you get down to it, small businesses and entrepreneurs, generally speaking, treat employees much worse than even union-free large businesses. Larger companies do a lot of the things unions want simply because there are hoards of lawyers willing to jump on them if it even looks like they might have a case. I mean, sure, you could bring a wrongful termination case against, say, me... but you'd have a difficult time finding a lawyer to take it on a percentage of the winnings; you can't get blood from a stone, and my company just isn't worth that much.

</comment><comment><USER3> Unions on both sides of the Atlantic have made huge strategic errors in the last three decades that have eroded much of their influence, relevance and power.

Embracing enterprise and entrepreneurs in a deep way would a massive stride forward. I don't see it happening though. Finding a common enemy to unite against is one thing, but the fundamental shift in outlook required to go beyond that is something else altogether.

Labo(u)r will find other ways to organize in the 21st century instead forming/joining 20th century style unions.

<comment><USER7> _Unions on both sides of the Atlantic have made huge strategic errors in the last three decades that have eroded much of their influence, relevance and power._

Probably not strategic errors so much as natural consequences of the fact that the interests of the people running the union at any given time are not quite aligned with the interests of the union.

<comment><USER3> Yep, our old friend the Principal-Agent problem strikes again. Misalignment of interests leads to decisions that aren't to the long-term benefit of the organization.

<http://en.wikipedia.org/wiki/Principal-agent_problem>

</comment></comment></comment><comment><USER8> No entrepreneur in her right mind would allow organized labor anywhere near their business. Best case, you cut out one of three monopolistic entities. (union labor and stockmen, cut meat packers)

Once you let that camel under the tent -- you're screwed.

Example: [http://pressrepublican.com/0200_opinion/x1859507528/Labor- ag...](http://pressrepublican.com/0200_opinion/x1859507528/Labor-agreement- raises-concerns)

In the example, unions from one area of a state used their political influence to require a type of labor agreement that excludes companies that aren't union shops -- even though those companies pay union prevailing wage.

</comment><comment><USER9> organized labor IS a monopoly, a monopoly on a company's labor. And having a monopoly on the supply of monopoly's labor supply is the most profitable monopoly of all.

so, no, I don't think unions will want an end to monopolies.

<comment><USER7> _And having a monopoly on the supply of monopoly's labor supply is the most profitable monopoly of all_

Indeed, and the holy grail of having a monopoly on a monopoly is having a monopoly on government employees. Witness the way the United Auto Workers formed an offshoot, the SEIU, which now dwarfs its parent.

<comment><USER9> Well, having a union at old Ma Bell or at a monopoly utility was/can be pretty lucrative. And there's never a rate cut. Governments are always fumbling their budgets.

The government unions are so bad because we can't simply decide "well, I'll just write letters." And its easier to build in time bomb benefits. All you have to do is steer union dues and volunteer labor to those that play along.

</comment></comment></comment><comment><USER10> We need a new blend of progressive and libertarian principles that honors the concept of respect for those who work, but does not support the dinosaur ideology of big labor.

Big labor is bad for the same reason big govt and big business are bad -- it exists to exist.

</comment><comment><USER11> India is developing since you can exploit Indians via caste system. <http://www.rediff.com/news/2007/may/03touch.htm>

China is developing since you can exploit Chinese by abusing human rights. [http://www.rediff.com/business/slide-show/slide- show-1-tech-...](http://www.rediff.com/business/slide-show/slide-show-1-tech- apple-workers-forced-to-sign-no-suicide-pledge/20110504.htm)

Americans are suffering since US regime is letting Chindia exploit their people via outsourcing.

</comment><comment><USER12> After learning a lot of economics, I went from standard coastal American views to incredibly hostile to labor unions. After learning more about political factions of all stripes, I became more sympathetic.

I think labor unions and similar do have some value, but today's versions aren't going to last. They're fundamentally hierarchical, seniority-based organizations and entrepreneurship is usually anti-hierarchical and anti- seniority.

Actually, that's one of the growing trends that no one's talking about yet. This generation is the first one where a very significant minority of people reject hierarchy-driven organizations and refuse to "work their way up." It still comes unnatural to our generation and there's social pressures against it.

But the next generation that grew up as digital natives, a lot more of them are going to reject the hierarchy and strike off on their own. There will still be social pressure against it, but much less so as our generation shows what's possible (and the people who did reject the standard track are doing pretty well).

The generation _after_ that, our kids, I think the standard hierarchy/seniority model will be near dead for them. But still, there's a lot of people in trades that "worked their way up", and they're going to hate this trend.

It should make for interesting times. As for labor unions, they've really got to stop selling out their younger members if they want to survive. The unions keep bargaining off younger members' pay and benefits to protect older members. That ain't sustainable - there's an entire culture shift going against them, though it's really just started to pick up steam the last 5-10 years.

<comment><USER13> _As for labor unions, they've really got to stop selling out their younger members if they want to survive. The unions keep bargaining off younger members' pay and benefits to protect older members. That ain't sustainable_

Unions know this but most are between a rock and hard place. When negotiating contracts they can only do it for the people being represented up to that point. Anyone that joins after that contract is signed is on a new, seperate contract. So when a union representative has to bring back the terms to it's members its usually like this, "the company has agreed on the pay scale with us, but any new hires will be on a seperate contract. Do you vote Yay or Nay?" Now each union member has to decide if they will accept the contract as it stands or do they go on strike for some ambiguously defined "future hire".

In fact, this sounds exactly like how our government decides to run its debt. Do we pay it off and take the lumps or push all the hard decisions on ambiguous "future generations"

The fact is people are selfish and unions represent people. Personally, I don't care to join one but I don't get angry at people that do nor do I go postal in chatrooms talking about them.

</comment></comment><comment><USER14> A lot of people on the left side of the political spectrum are starting to wake up to the fact that many people _start_ startups as Democrats, but quickly become strongly libertarian in their economic views as they come face to face with the realities of government waste, regulation, and corruption.

The Uber and AirBnB founders are unlikely to pull the lever for statists, for example. And this is very dangerous to the progressive movement as startup founders tend to be smartest and most resourceful of their peers. Huge amounts of money has been invested in making sure all college grads mouth fashionable left-of-center slogans on economics, but the movement started by Paul Graham inadvertently threatens to unwind all that.

This article is motivated by that realization and is one (vain) attempt to bring entrepreneurs back into the fold. There are other attempts too, like "Startup America". But in the longer term these efforts are unlkely to succeed as more and more people at early stage companies encounter manifest contradictions between their lived experience and the religion of their birth -- namely progressivism.

</comment><comment><USER15> In one of his interviews, John Mackey pointed out that there are legislative reasons for this as well. America isn't allowed to have in-house unions like those of Japan. The present laws predispose unions to antagonistic relationships.

</comment><comment><USER16> Why do people imagine that organized labor (in some cases monopoly labor) is any different than big business? When big business has an unequalled advantage it abuses it, trying to milk money out of customers without returning any value. Big labor does the same. Creating bureaucratic organizations that maintain job security and job pay merely for showing up and belonging to the union, rather than actually doing the work better or more efficiently.

</comment><comment><USER17> I have an 1:20 commute but its on a bicycle the whole way. If its killing it sure is a fun way to die.</comment>


History and Background of JavaScript Module Loaders - <AUTHOR> http://appendto.com/2016/06/the-short-history-of-javascript-module-loaders/ <comment><USER2> A recommended read</comment>


Extending optionals in Swift - <AUTHOR> https://www.swiftbysundell.com/posts/extending-optionals-in-swift <comment><USER2> I'm not particularly impressed by of any of these extensions, because they don't seem to actually fix the underlying problems. I used to write code that was overly defensive around Optionals, and I'd carefully do things like wrapping in flatMap or throw guards in, but I've come to realize that this just ends up hiding errors in the cases where you know something is supposed to have a value. For this article in particular, I think there are better ways to do what he's trying to do:

For the converting an Optional to an error example, he could just put both statements in one guard. Sure, being able to show that you're passing a function into another is pretty, but it really is overkill for something that doesn't even need an extension to Optional.

I think isNilOrEmpty, personally, just encourages papering over bad APIs: it is never correct to represent an empty Collection with nil. UITextField.text should never be nil (to the point where I think that this method is improperly annotated; I can go check though); if it is your view hierarchy is in a state where asking it for its text returns nil this should be a hard error because you must have messed up somewhere. Just force unwrap in this case, and if you're designing an API, think twice about returning Collection?.

Lastly, get(orSet:) is just a skirting around the issue. Forget to set the value of this view? Just set it again! Just ignore the fact that a clear logic error that must have occurred if I ended up at a point where I'm trying to access a view that doesn't exist.

<comment><USER3> These are my rules of thumb in priority order:

1\. Don't use optionals.

2\. If you must use optionals due to technicalities (e.g. IBOutlet, weak reference, etc.), make it implicitly-unwrapped.

3\. If you can't make it implicitly unwrapped due to 'nil' being a legitimate value, then use regular optionals, but force-unwrap it everywhere _except where `nil` is expected to occur_.

There's nothing worse than a codebase unnecessarily littered with

        guard let x = x else { return }

If my assumptions about some value were wrong, I want it to break as loud as possible. Silently returning (or making up some silly default value like an empty string or zero) is the worst thing you can do for yourself and your colleagues. (Except if you're a manager whose bonus is tied to your app's crash stats)

<comment><USER4> Your approach seems to be a completely wrong use of optionals (have you been writing in Java or any other language with implicit nullability?) since you're giving up type-safety of Swift. Do you use implicitly unwrapped optionals for delegates too?

<comment><USER3> >since you're giving up type-safety of Swift

Giving up _type-safety_? Sorry, but I don't understand this in the current context.

As for delegates: if the delegate can be 'nil' during normal operations, then it should be a regular optional as per rule #3.

</comment></comment></comment></comment><comment><USER5> I'm not a huge fan of Optional.matching (also commonly called Optional.filter) because you may want to "filter" non-optionals as well, i.e. T -> Optional<T> given a predicate. Unfortunately Swift doesn't (yet?) allow writing extensions on any generic T and the alternatives are a free function and an Optional initialiser, neither of which allows you to easily chain them. (Another alternative is a custom operator, but let's not.)

So perhaps the best we can do is Optional.matching as defined in the post, combined with turning a non-optional into an optional using Optional(...) in case we want to "filter" non-optional values using a predicate.

<comment><USER6> > Unfortunately Swift doesn't (yet?) allow writing extensions on any generic T

I'm keen to understand the use case for this kind of code, where T literally conforms to zero protocols. Would you not create a protocol with a default implementation and then conform to that in this case? An example would help me a lot!

</comment></comment><comment><USER7> I'm somewhat surprised that the Swift Optional doesn't come with `orElseThrow` or `filter`. I mean, even the Java Optional has those combinators.

<comment><USER8> filter -> flatMap / compactMap without arguments

orElseThrow is something you might need more often in Java, Swift handles optionals with if let / else checks or Result enums instead of functions that either result an object or throw an Exception. Throwing errors / exceptions is pretty rare in the language compared to the Java / C# world.

Only when doing stuff like mapping JSON I set up try / throw trees because in the end I might not care about the Error at all and just discard it.

<comment><USER9> And with Codable times of manually mapping JSON to objects are over, at least you have to deal with something sane.

<comment><USER8> I really needed stuff like snake_case support

<comment><USER10> [https://developer.apple.com/documentation/foundation/jsonenc...](https://developer.apple.com/documentation/foundation/jsonencoder/keyencodingstrategy/converttosnakecase)

Also, as already said, CodingKeys.

<comment><USER8> Right, I said _needed_ , not need ;)</comment></comment></comment></comment></comment></comment>


LLVM 2.8 Released - <AUTHOR> http://www.llvm.org/releases/2.8/docs/ReleaseNotes.html

<comment><USER2> _Clang C++ is now feature-complete with respect to the ISO C++ 1998 and 2003 standards._

this seems like a pretty big milestone. in particular, clang now has a libc++.

they also mention now supporting objective-c++. that's got to be one strange beast to code in.

<comment><AUTHOR> LLVM is "sponsored" by Apple, who are keen to see good Objective-C support; Objective-C++ isn't really a combination of C++ and Objective-C, its more a compatibility option between different libraries and APIs.

<comment><USER3> > Objective-C++ isn't really a combination of C++ and Objective-C, its more a > compatibility option between different libraries and APIs.

Eh, I'd say that's even more misleading.

In the same sense that Objective-C is a strict superset of C, Objective-C++ is a strict superset of C++, adding the same features to C++ that Objective-C adds on top of C.

In practice, this means that you can mix Objective-C++ and C++ in the same file (but you can't treat C++ classes and objects as Objective-C++ classes or objects, or vice-versa).

<comment><AUTHOR> I think you've misinterpreted my post. I /generally/ agree with what you've said.

</comment></comment></comment></comment><comment><USER4> Today's discussion about the clang 2.8 release: <http://news.ycombinator.com/item?id=1762335>

</comment><comment><AUTHOR> Source code visualisation of LLVM development over 9 years: <http://www.oriontransfer.co.nz/research/code-visualisation>

</comment><comment><AUTHOR> Release announcement : [http://lists.cs.uiuc.edu/pipermail/llvm- announce/2010-Octobe...](http://lists.cs.uiuc.edu/pipermail/llvm- announce/2010-October/000036.html)

</comment><comment><USER5> I don't understand the hype.

I downloaded and installed the Mac binaries, but it couldn't compile the STL headers that Xcode installed.

It's _FAR_ from production quality, IMHO.</comment>


Ask HN: If the world were to end 2 years from now, what would you do? - <AUTHOR>

Would you still be working on what you are working on now. If not, are you sure you are doing the right thing now? <comment><USER2> Well that depends.

How many people know about it - is it a secret that only I know or a few select people know about, or is it common knowledge.

Is it inevitable or can something be done to stop it or mitigate it's effect? And if something can be done, can I help?

And finally, does the world ending mean that end of all Earthly life? No Moon or Mars base, or one or more spaceships with humans on them.

</comment><comment><USER3> If I knew that the world would end in 2 years the last thing I would be doing is working.

I would spend that time with family and loved ones.

<comment><AUTHOR> But would you do that for 2 years. You would need to do something else too I guess. What if you did not have enough savings for 2 years. You would need to work. But what kind of work would be available?

</comment></comment><comment><USER4> Inevitable world ending? I'd join the 300 Club -- <http://en.wikipedia.org/wiki/300_Club>

</comment><comment><USER5> I would try and prevent it.

If it's inevitable, I would relax and enjoy life as much as I can. The problem is, everyone would, and we would run out of food/water/fun pretty quickly.</comment>


In Search of a Secure Time Source - <AUTHOR> https://blog.hboeck.de/archives/890-In-Search-of-a-Secure-Time-Source.html <comment><USER2> First off, an annoyance: I'm annoyed that there is no DHCP option to specify "This is the current UTC time". That would let the DHCP server tell the client what the current time is, with enough accuracy for most things. I mean, if you're already trusting in the info already provided by DHCP, you might as well trust this, too.

DHCP Options 152-155 (from [http://www.iana.org/go/rfc6926](http://www.iana.org/go/rfc6926)) might work, but that's part of a different standard.

Anyway, the main thing I wanted to note is that your ISP likely already has NTP servers that you can use. You might even be getting them, via DHCP Options 4 and/or 42 (though 42 is more appropriate). At least that way, your NTP queries don't go out to the wider Internet.

If you have your own network, then you should have an NTP server. The bigger the network, the more NTP servers you should have. Each NTP server should be getting time from 10 different upstream servers (stratum 1 or 2). Ten is the maximum number of NTP servers which NTPd will check at once. Querying more NTP servers will allow NTPd to identify and exclude "falsetickers", which are serving bad time.

Ideally, your NTP servers should have a local source. "Local source" means you are getting time from a device which queries something like GPS, GLONASS, WWVB, etc.. That way, when the local source is working, your NTP server becomes stratum-1; when not working, your NTP server becomes stratum-2 or -3, but can still serve time within your network.

If you have multiple NTP servers, each one should have a different local source: One checking GPS, one checking WWVB, one checking GLONASS, etc.. You can tell NTPd that each of your servers should peer with the others, to increase accuracy. You could even have multiple local sources on each server.

All of the is still unencrypted, though, but it is mitigated by keeping the NTP traffic within your own network. And also by having so many different time sources, it's possible to identify bad ones.</comment>


Follow up to YC Designers, Can You List More? - <AUTHOR>

I really like the designers listed here:
http://news.ycombinator.com/item?id=134703
Can you please list even more designers? I would really really appreciate it! Thanks! <comment><USER2> My personal portfolio is here: <http://sicret.net>

And many good designers can be found here: <http://faveup.com></comment>


Suspicion - <AUTHOR> http://xkcd.com/632/

<comment><USER2> The next frontier of the Turing test. Money talks.

</comment><comment><USER3> sounds like the perfect use for <http://botornot.com>

Sadly, it's already registered</comment>


Data Center Overload - <AUTHOR> http://www.nytimes.com/2009/06/14/magazine/14search-t.html?_r=1&hp <comment><USER3> "it is estimated that a 100-millisecond delay reduces Amazon's sales by 1 percent."

Can any of the bright minds here shed some light on this? 100ms doesn't seem at all enough to have that big an impact. (especially for something like amazon - where there is likely some level of intent and definate trust that the site is valuable). I just can't see how a .1sec delay could affect so many sales?

<comment> puzzle-out [http://www.drunkenfist.com/304/2008/12/29/why-front-end- perf...](http://www.drunkenfist.com/304/2008/12/29/why-front-end-performance- matters-to-everyone/)

<comment><USER3> :) Thanks (all) for responding. I guess I never realised how much of amazons purchases must be spur-of-the-moment. (NOTE: I order stuff from amazon - <USER2> usually in groups as I'm shipping it to australia - so all of my stuff is planned - i'm going there to buy something)

But - if anyone has the metrics to prove a figure like that - it would be amazon.

</comment></comment></comment><comment><USER4> Edit: whoops. this is supposed to be a response to the first comment.

I would guess that the 1% figure is the average loss for each 100ms of latency. So if it took 5 seconds longer to load each page, 50% less people would ultimately make a purchase.

Which is still a very high number, and makes me wonder if most of Amazon's customers are impulse shoppers, or whether these numbers were just fabricated to help sell AWS.

Either way, it's not a very meaningful without knowing the context and overall probability distribution of lost sales vs. latency.

</comment><comment><USER5> Printable Link: [http://www.nytimes.com/2009/06/14/magazine/14search-t.html?_...](http://www.nytimes.com/2009/06/14/magazine/14search-t.html?_r=2&hp=&pagewanted=print)

EDIT: Doesn't work unless you have the correct Referer...

</comment><comment><USER6> I think the last point was the most interesting.. data substations. Every suburb/town could have a data substation that all connect to form the cloud. computing as a service, exactly the same as electricity. shit is about is get interesting.

<comment><USER7> Isn't the logical conclusion that every one's PC inside their own home forms part of the cloud?

It reminds me of a joke business plan developed over some beers: Provide free electric heaters for old people to run in winter, which were actually PCs connected to a phoneline doing data-intensive grid computing :-)

</comment></comment><comment><USER8> "Google search is not without environmental consequence — 0.2 grams of CO2 per search, the company claims"

I wonder how that compares to the CO2 cost of driving to the library to look up the same bit of information for the average person?

<comment><USER9> It's a fallacious analogy. People didn't use to drive to the library to look up tidbits of info - search engines create new demand. Also, use of libraries has gone up greatly since they began installing computers for patrons. So driving to libraries is increasing even as Net use is increasing.</comment></comment>


Multithreading or Light-weight processes ? - <AUTHOR>

I personally feel using light-weight processes for intra-application multitasking is far more superior than having concurrently running threads that share the same block of memory.
Light-weight processes are far more secure than threads in the sense they don't share memory and thus avoid a whole host of problems associated with it.
IMO, they are also easier to work with (while programming); I find the message-passing IPC model simpler and more manageable.
Additionally when it comes to parallel computing; even there light-weight processes are a win-win scenario. There's no need for complex algorithms that manage shared memory between CPUs when each CPU can be assigned 1/more L.W.-processes and they all interact by message passing.
I think on a well designed OS, L.W.-procs should be as efficient as threads.
Some applications like Google Chrome already use L.W.-procs (for each tab the user opens a seperate process is launched). It surprises me that a lot more people don't use it already, given its many advantages.
Which model of multitasking do you think is better? (especially in terms of programmer efficiency) <comment><USER2> I'm a fan of lightweight processes. I really recommend reading the following:

[http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1....](http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf)

Threads are a seemingly straightforward adaptation of the dominant sequential model of computation to concurrent systems. Languages require little or no syntactic changes to support threads, and operating systems and architectures have evolved to efficiently support them. Many technologists are pushing for increased use of multithreading in software in order to take advantage of the predicted increases in parallelism in computer architectures. In this paper, I argue that this is not a good idea. Although threads seem to be a small step from sequential computation, in fact, they represent a huge step. They discard the most essential and appealing properties of sequential computation: understandability, predictability, and determinism. Threads, as a model of computation, are wildly nondeterministic, and the job of the programmer becomes one of pruning that nondeterminism. Although many research techniques improve the model by offering more effective pruning, I argue that this is approaching the problem backwards. Rather than pruning nondeterminism, we should build from essentially deterministic, composable components. Nondeterminism should be explicitly and judiciously introduced where needed, rather than removed where not needed. The consequences of this principle are profound. I argue for the development of concurrent coordination languages based on sound, composable formalisms. I believe that such languages will yield much more reliable, and more concurrent programs.

<comment><USER3> I second the recommendation of linked paper: It is a very good explanation of _why_ threads are problematic; every programmer who consider using threads ought to read it.

</comment></comment><comment><USER4> Your definition of "light-weight process" appears to be the same as a normal process.

<comment><USER5> Indeed. Run

ps -eLf

To see what LWPs are

</comment></comment><comment><USER6> The key features are _isolation_ and _fault management_. Isolation means that each process is separated from the others and can only communicate via a safe means. What happens when a process dies? Good systems have far more fault- tolerance.

An additional benefit is _security_. Your model can rely on some processes having the capability to access confidential data. These act as proxies for accessing that data and protects it. The OpenBSD operating system has used this "privilege separation" trick for years.

Everything with shared memory will die in the long run. The hardware can't keep on fooling us with a big memory space shared among all processes anyway.

</comment><comment><USER7> If you need to process a bitmap in parallel, it's a pain to use processes, since there's a significant amount of memory that has to be passed around. And it's inefficient, as you would always have to copy memory to the other process.

That's what threads are for - parallel paths that need to share memory. Processes are for parallel paths that rarely need to access the same data or to synchronize between them.

Don't forget also that when your CPU shares time, it divides up the time equally among the processes. So if your application creates 20 processes, it takes a disproportionate amount of CPU time (I believe, someone correct me if I'm wrong).

<comment><USER4> _Don't forget also that when your CPU shares time, it divides up the time equally among the processes. So if your application creates 20 processes, it takes a disproportionate amount of CPU time (I believe, someone correct me if I'm wrong)._

It depends on the OS. In most cases, threads are the only schedulable entity (think of a classic process as containing one thread), so there is no difference between 20 single-threaded processes and one process with 20 threads.

</comment></comment><comment><USER8> I don't think this needs to be an "either/or" type of scenario. Depends on the specific requirements.

Sometimes you need a multi-threaded model...i think a GUI library is a good example of that. Other times, a multi-process model would be easier to set up...a "just run in the background" sort of thing.

I also don't quite understand why suddenly everybody is afraid of writing multi-threaded applications. Just make sure you understand how the threading model works in your specific technology and what abstractions are provided. If your application is complex enough to require a "complex algorithm to manage shared memory", then i think you need to really take your time to understand what you're trying to do.

Having said that; I acknowledge that chasing down bugs caused by threads is not fun at all. Especially race conditions since they are seemingly un- predictable. But i think it is getting easier with newer platforms and tools.

</comment><comment><USER9> The decision depends on the interactions between them.

Threads make intercommunication cheap but at the price of exposing to problems like deadlocks or data access synchronization overhead.

My rule of thumb is to use process and move to threads only when there is a significant added value.

</comment><comment><USER10> It's a false dichotomy, I think - they're not the only models around. Cf Erlang's process model - no shared memory, and far less resources per process than either OS processes or threads.

<comment><USER11> Yes, I'm kind of confused about what the original poster is actually talking about. Erlang has a pretty good model, but it's enforced at the language level, not the OS level - strictly speaking, its processes do "share memory" in the sense that they all run in the same OS process. Of course, the implementation more or less prevents them from stomping on one another, so it ends up working quite well.

</comment></comment><comment><USER12> I don't think lw-process is a good answer to server-side programming. for desktop programming, multi-process can avoid program fails and provide superior performance. but for server-side, considering the consuming of memory and computing resource, threads and lock-free data structure are the better choice. Well, when needing a robust server-side program, you indeed have to program something like lw-process&thread hybrid.

</comment><comment><USER13> The one that fits the problem at hand is the best model to use. one's not clearly better for all cases than the other.

</comment><comment><USER14> There is no good answer to this that encompasses all scenarios. Some times it makes more sense to use threads, some times LW procs.

Things like chrome make an interesting case for using LWP in an environment that usually uses threads, but it still does not necessarily mean it is a better solution.

</comment><comment><USER15> <http://www.kegel.com/c10k.html>

</comment><comment><USER16> I actually like the competition. I dislike the unconditional fanatics :)

</comment><comment><USER17> I think we should go back to single-threaded, non-parallel. Those were the days.

</comment><comment><USER15> "man clone"</comment>


Habits of Highly Effective Software Developers - <AUTHOR> http://blog.stackraft.com/the-7-habits-of-highly-effective-software-developers/ <comment><USER2> Here is another one: a highly effective programmer will never use a low contrast design for publishing text that somebody should read. Never. Low contrast design is a very good indicator for unawareness and non-thinking followers.

It is good advice to stay away from companies that publish low contrast things.</comment>


Jeri Ellsworth and the Robot Uprising of 2038 - <AUTHOR> http://blog.robertelder.org/jeri-ellsworth-robot-uprising/ <comment><USER2> Jeri is a national treasure, future robot overlord savior or not. I am, and know so many who have been inspired by her. I am sure just her enthusiasm for electronics helped arm a generation of techno warriors against possible automatron subjugation.</comment>


Making Debian Responsible For Its Actions - <AUTHOR> http://sheddingbikes.com/posts/1285659877.html <comment><USER3> I didn't see the words "bug report" anywhere there. Debian is a volunteer organization, open to anyone. If you want to improve it, sign up and help instead of just ranting about crazy paranoid theories like:

> It's simply a tactic to make sure that you are stuck on Debian.

Of course I'm biased, as I'm a former Debian maintainer, but I think that Zed's connection with the reality of the situation is tenuous, at best, in this case.

Making a distribution is difficult, and doing so with 1000's of volunteers who are not working on it full time (and since you're not paying for it, they don't really owe you anything) and are distributed throughout the world adds to the difficulty, so yes, there are bugs and problems and challenges to overcome. That said, if each author of each package in Debian got their way about the exact location of files and so forth, the system would be utter chaos. If you think your package isn't being treated right in Debian, get on the mailing list, file a bug report, make your case, and get things fixed, rather than treating Debian as "the enemy"... Sheez.

<comment><USER4> There is a reason that Debian is being singled out, which you ignore - <USER2> likes to add lots of distribution-specific patches to _everything_ they package. Other OSes/distributions are not as problematic, because they are much more likely to ship software as the author wrote it (unless it's ridiculously broken _and_ unmaintained _and_ important.)

Also: why should software authors have to write bug reports to Debian?

<comment><USER3> With 1000's of packages, and 1000's of maintainers, saying that "Debian" likes to patch "everything" is a pretty big claim.

A lot of the patches that do go in make whatever package integrate better with the rest of the system.

> Also: why should software authors have to write bug reports to Debian?

Because there's a bug?

> "Even though the piece of software I asked aptitude to install requires > these libraries to run, they refuse to install it."

At first glance, that sounds like a packaging bug to me, with Rubygems, not with one of Zed's packages. The best thing to do in those cases is report the bug, rather than attempt to "make Debian pay" (for the thousands and thousands of hours of work to give you a free operating system, presumably?)

<comment><USER5> Why should the author report a bug when it's the incompetence of the Debian maintainer?

The 'gem' command not working after installing the 'rubygems' package does seem like a bit of a bug, to put it mildly, you'd think a cursory test by the maintainer would catch that.

<comment><USER6> As far as I'm concerned, having rubygems available _at all_ in Debian is a bug. Gems should be repackaged as .debs.

<comment><USER7> This. The point of Gems and Maven and the CPAN client and all this other crap is to smuggle code into a production box while carelessly failing to get it into the platform's database of what's installed where and what depends on it. They replace one tool that knows everything that's going on, with many tools each of which can't.

Somehow we got stuck with a critical mass of small-scale developers who never faced the nightmare of somehow keeping the right tarballs on hundreds of machines in different roles without good tools, so now we all get to relive it.

<comment><USER8> That's hilarious. Users of Maven and CPAN represent a "critical mass of small- scale developers"? Holy shit.

A similar idea was voiced a few days ago, specifically regarding Java libraries ([http://fnords.wordpress.com/2010/09/24/the-real-problem- with...](http://fnords.wordpress.com/2010/09/24/the-real-problem-with-java-in- linux-distros/)).

My response remains the same: Debian (or what-have-you) is but one distro among many, and those of us that treat such things as important but fundamentally commodity deployment platforms have no wish to spend our lives babysitting whatever package manager happens to be on the operating system we're using that month/year/whatever. Further, plenty of people have plenty of good reasons for deploying on Windows and OS X, so using tools that work well there make sense.

The priorities of the various linux distros aren't everyone else's priorities – which somehow seems to come as a galloping shock to some.

<comment><USER9> That is why I use Slackware. Installing new software by hand from tarballs is a bit tedious compared to package managers, but it is transparent, and when I am done I can be pretty sure it is going to work. I have tried other distros, even Debian once (for some reason the Debian wouldn't let me sign in as root, I never did figure out why), but I keep coming back to Slackware - for its transparency.

<comment><USER10> And Slackware's packaging is light enough that it is fairly simple to write wrappers around gems/CPAN modules/Python eggs. The latter two have prewritten SlackBuilds that you can use, assuming that the setup.py is not doing anything too shady.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> > But here's the problem, Debian package maintainers don't want to give up > control to the responsible parties. I would more than gladly make my own > .deb packages, but they refuse to let me. In fact, I plan on making packages > for the major Unices in order to head them off. That's what everyone ends up > doing.

As a user, and amateur administrator of my home machines, I've learned the hard way that third-party packages supplied by the original software vendor are, in general, utter crap. They're built against a distro two or three versions old; or they're built for Mandrake or Ubuntu instead of Red Hat or Debian; they "install" a tarball to /tmp which the post-installation script untars in the root directory; they don't have any dependencies declared at all but crash at startup if you don't have a particular version of libjpeg... if you're relying on the packaging system to detect file conflicts or outdated dependencies, third-party packages can be very, very scary.

The single biggest reason I choose Debian (and sometimes Ubuntu) is the uniformly high-quality packaging. Zed's found one problem package, and a trawl through Debian's bug tracker will no doubt find others, but the fact of the matter is that with a single command I can install almost any Free software in the world, and have it installed and set up within seconds - and Debian has years of experience figuring out how to make that work. I don't think that's a thing to be dismissed lightly.

<comment><USER12> I used Debian on the desktop for 2 years (2008-2009) ... the whole time the Iceweasel package (their repackaged Firefox) has had its renderer broken, making some web pages unusable for me ... this wasn't a problem if I manually downloaded and installed Firefox, and it finally got fixed just before I switched to Ubuntu.

It does have the best software repository ever, but boy how much it sucks when something's broken.

</comment></comment><comment><USER13> This is in no way specific to Ruby — if you look at the way any sufficiently advanced software you're familiar with is packaged in Debian, you'll find it to be completely fucked. Ancient versions, nonstandard configuration files, random things disabled at compile-time (often for ideological reasons), files scattered everywhere with the new locations hardcoded, with basic features broken into separate packages. My favorite is the random patches, which when they aren't in the service of the aforementioned ridiculousness, are mostly cherry-picked from current upstream versions to 'fix bugs' without accidentally introducing features because they're afraid of new version numbers. When a patch doesn't fit those categories you really have to worry, because now they're _helping_ (see OpenSSL)

The result is that any program or library that you use directly must be sourced from upstream, _especially_ if it's less than 15 years old or written in a language other than C or C++. Luckily pretty much all of the modern programming language environments have evolved to cope with this onanistic clusterfuck.

Haskell has more fucked by Debian than any other language I know of — when I last had to deal with it a year ago there were two broken+old builds of GHC with different package names and mutually-exclusive sets of packages that depended on them. On top of that the version of cabal (Haskell's packaging tool) in the repository was so far out of date that you couldn't use it to build anything remotely recent (including useful versions of itself), nor could you use it with anything in Hackage (the central repo).

My old roommate had listened to me bitch about this stuff for years, and always dismissed me as crazy for thinking that the packaging was fucked (though he did share my hate of _debian-legal_ ). Last week he called me out of the blue and apologized — he'd installed Wordpress through Debian and they'd broken it up into a bunch of library packages, but still left a base skeleton of random php files and symlinks, accomplishing nothing but breakage and unportability.

</comment><comment><USER14> Here is my beef with Debian.

A lot of the software they package comes with unit tests. Those unit tests have a purpose. They are meant to see whether or not the software as configured and installed, works.

Debian systematically strips those unit tests out, and _never_ runs them to see how much stuff they are shipping already broken. Why? Why not package the unit tests as an optional package, and make sure they have a wide variety of systems in different configurations running them to notice problems?

I can't count how many times I've tried to install a Perl module from CPAN, found it was failing its unit tests, installed the Debian package with it, ran the unit tests, and found that the unit tests said the package, as installed, was broken. It's not as if the package developer didn't try to tell you you were missing something. Why throw that information away?

If they did this then they'd automatically catch a lot of problems that currently get missed. Heck, insert a test for ruby gems that says, "Does this software start?" They'd have caught this bug automatically.

Until Debian catches up with standard best practices, I completely can't agree with the meme that they run software better than everyone else. It isn't as if unit testing is a new idea. It has been pretty mainstream for most of the last decade. Some were doing it earlier. Perl has been doing it since the 1980s.

<comment><USER15> I don't think it's so cut and dry. In the ideal case, the packages don't need tests because they are going into the system already tested. _If_ the package is correct then running the unit tests is just redundant work because you are getting an identical copy of a package that already tested good with the appropriate dependencies. I think that's the theory anyway. On the other hand, theory does not always match reality.

Debian CPAN packages _do_ run the unit tests--they just run them when you create the package and not when you install the package. In fact, the package will not build unless the tests pass.

<comment><USER14> Sorry, but it really is that cut and dry. In the ideal case you don't need unit tests. In the real world, they are useful.

One of the big things that unit tests are supposed to catch are hidden dependencies. By nature, hidden dependencies are likely to be installed on the maintainer's machine, so unit tests only help if they are run somewhere else.

As a prime example, the bug that Zed was complaining about was a dependency problem of EXACTLY this sort. It worked fine on the maintainer's machine. It didn't work on Zed's machine because he didn't have a key library installed. No unit test the maintainer can run would catch this. Even a stupid unit test Zed can run would have flagged this immediately.

Incidentally about the Debian CPAN packages, my experience with them a few years back was that they were so consistently broken (usually because of locale issues) that I have a hard time believing that unit tests had actually been run by anyone. Or if they were, they were ignored.

<comment><USER15> Well, then maybe what they really need is a single server/farm out there that just goes through all the perl/ruby/whatever modules and installs them and runs their unit tests. That way you get the same coverage but you don't waste my time. I, personally, don't want a bunch of unit tests to run when I install stuff--it's slow enough as it is and it's (usually) completely redundant.

It seems the same to me as slackware or one of the other "compile everything yourself" distros--they force you (the installer) to do a bunch of redundant calculations. If someone can compile on my architecture then why should I _ever_ have to compile it? The same with unit tests--if someone can run the unit tests on my exact configuration then why should I _ever_ have to run them?

<comment><USER14> You still don't get it.

If you're installing item after item, then the odds are that at some point you're going to install the dependencies, and after that the tests will pass and mean nothing. So you keep on wiping, installing one thing, and testing. Fine. Now you have cases where package A conflicts with package B and you never find it. And now what? The number of combinations to test is incredibly large, and nobody is likely to have tested your exact system.

As for the unit tests, make them available, make them optional. That's OK by me. I'd opt to use them. Particularly since I learned the hard way that most of what I want in CPAN either isn't in Debian, or isn't up to date there. So I install things directly from CPAN. That means that when I install from Debian, there is a possibility of library conflict that I want to notice.

<comment><USER16> Perhaps a compromise would be to have the package-install-time unit tests run in "testing" and "unstable", but be turned off for "stable"?

<comment><USER14> That would be worlds better than what we now have. But I'd like the option to turn it on. (And I'm sure others want the option to turn it off.)

<comment><USER17> I'm not sure what the -dbg packages in Debian/Ubuntu are strictly for, but wouldn't this be a case for it? If one could post-run the tests by saying "apttest Foo" or something along those things, integration into utilities to automatically install test packages and run them shouldn't be a huge hurdle.

<comment><USER18> I can't speak as to whether or not it would be a good idea for -dbg packages to run unit tests, but their nominal purpose is that they contain extra symbols to allow for debugging.

<http://wiki.debian.org/DebugPackage>

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> ...and people ask me why I write tons of freeware, but make so little of it open source.

The reason is simple: control. If I can't control every stage of the development, deployment, and distribution process, I don't want in (yes, I'm a control freak. No, I don't think necessarily a blemish on my personality, it's just who I am). If there's something wrong with how my users perceive my software, it's because of something _I_ did wrong, not because someone took my hard work and toil and perverted it with their own changes, be it making the code ugly with nasty function names or dirty hacks (in my opinion, of course) or if they distribute it in a way that makes users cringe. It's my hard work, and I deserve to be (a) in control of the user experience, and (b) attributed.

If you're willing to make your awesome utility/code that you've spent 5 years developing and maintaining fully available to the public, giving up all control of the end-users' perception of the package, you have a bigger heart than me. But me, I'm a selfish guy when it comes to my users, and I don't want anyone to even have the possibility of hurting them. I have _my_ users' best interest at heart, you probably don't. At least, not to the same extent that I would.

<comment><USER20> You could still make it open source but craft the license in a way to prevent redistribution

<comment><USER3> > You could still make it open source but craft the license in a way to > prevent redistribution

Then it would not be open source.

<comment><USER21> There are certain clauses that don't affect the definition of a program as open source, but would prevent it to be included by, let's say, Debian. I'm thinking on the old BSD license or the branding problem of Firefox.

<comment><USER3> Debian includes the Firefox code, though. You can certainly say "you can redistribute my code, but not call it XYZ if you've modified it", that still lies within the realm of open source.

<comment><USER21> That was my point. It's open source and still it's not distributed under the Firefox brand, so users won't fill bugs in Mozilla's bugtrack.

</comment></comment></comment></comment></comment></comment><comment><USER22> I sympathize with frustration at poor software packaging, but the proposed solution seems completely disproportionate to the offense. I also don't see any real evidence presented for the assertion that Debian's policies are based on a corrupt motive. What OS is actually pure and innocent of technical flaws and bad policies? If I recall, openSuse is in bed with Microsoft, Ubuntu fails to contribute code to important projects, Fedora is really just Red Hat's beta testing, etc. One of the pains of open source software is that things you write will probably be messed up in lots of ways by other people. If seeing software packaged or modified in ways you don't like makes you angry and advocate retaliation, is that really consistent with the philosophy of a free software license?

<comment><USER13> The efforts of both Zed and Debian are based on the same corrupt motive: _self-satisfaction_

As the upstream developer, Zed wants to make sure that his software is distributed in a manner that is useful to people and actually works and shit. This gives him jollies.

As the distributors, the Debian contributors want to fullfil ideological goals, fit everything into their neat hierarchy, assuage neckbeard sysadmins that the version number is sufficiently ancient (not that the software is, given the distro patches), pretend to care about people running it on the PA- RISC port of Debian GNU/kFreeBSD, wank about licensing, and reach consensus. This gives self-important teenagers and manchildren all kinds of joillies.

<comment><USER23> I can't believe this getting upvoted. I wonder how much software you use _every single day_ thats created and maintained by "self-important teenagers and manchildren".

</comment></comment></comment><comment><USER24> I've always thought that it was a bad idea for Linux distros to package any language libraries at all. It seems like a lot of repeated work and your users will probably end up needing to install things manually in the end. Things will require the lastest version of gems, new and essential features will be added, etc. Just give your users a manual on how to install gems (or pip, or whatever) and let it be. The users of language libraries are exclusively programmers after all; I think it's safe to assume they can handle library installation.

That said, Zed is blowing this way out of proportion.

<comment><USER3> > Just give your users a manual on how to install gems (or pip, or whatever) > and let it be.

Uh... that might work for one language, but for 10? 20? And some poor sysadmin is supposed to use all these disparate tools to install security fixes too?

And you're forgetting that there are "end-user" programs that depend on those libraries as well, so they really do need to be packaged up.

> That said, Zed is blowing this way out of proportion.

That goes without saying.

<comment><USER24> _And you're forgetting that there are "end-user" programs that depend on those libraries as well, so they really do need to be packaged up._

I'm not forgetting this. I don't think the user's programs should use the same libraries (or even the same language install) that the distro's programs depend on. This way, if the user messed something up (like trying to upgrade a library), the entire distro wont be hosed. It's a really bad idea from a stability, security, and design standpoint if you don't keep these two things separate.

</comment></comment></comment><comment><USER25> Actually, the Ruby and Rubygems Squeeze packages have been in quite a flux lately. One of the more recent Ruby1.9.1 packages broke Rubygems completely due to some changes in the Ruby 1.9.2 source and they way they handle gems. The latest version of Ruby has really integrated the Gem package management system into its core. It has therefor been decided to stop building a separate Rubygems package for the 1.9.x series and let the Ruby1.9.x package deal with gems.

Have their been clashes between the Ruby and Debian communities? Yes! Are we all working toward a solution? Yes! Will it happen instantly? Unfortunately no, but I think the two groups are now talking and are making some good progress. Keep an eye out for some good stuff in the future.

</comment><comment><USER26> [Disclaimer: I'm not a Ruby developer, but have developed in plenty of languages, as well as being a sysadmin for a fair while]

IME, separate package-management for each and every language is more painful than the problem he is describing.

Rubygems, CPAN, whatever other languages use.

As soon as you install things outside of the distro package-manager, it has no idea what is going on with those packages and so continues to think that they aren't installed. If there was a way to get the package-managers for language libraries and the distro to play together nicely and work for dependencies etc then this would be OK, but as it is it's a bit of a sysadmin nightmare.

Edit: I thought that installing distro-supplied packages into /usr/local was against the FHS?

<comment><USER3> > way to get the package-managers for language libraries and the distro to > play together nicely and work for dependencies etc

Yes, hacking the language's package manager to talk to the distribution package manager is probably the only way to really go about solving the problem in an elegant way, and even that is not without its pain points.

<comment><USER26> > pain points

Absolutely, but this problem has been around for a long time, and fighting with distributions on how to get it to work won't help anyone.

Of course, it also means that if you install a buggy version of a library from, say, CPAN then you could break distro-supplied packages... I guess it depends on which you value more: distributor-provided testing or being able to install out-of-band packages onto your distribution more easily and with proper dependencies.

</comment></comment></comment><comment><USER27> It might be worth re-evaluating this rant in the light of Lucas Nussbaum's (Debian Ruby maintainer) recent "mythbusting and FAQ" post:

<http://www.lucas-nussbaum.net/blog/?p=566>

<comment><USER28> This is far from being a rant. It's a concise exposition on the Debian/Ruby issues.

Thanks for posting the link, but being labelled a rant, I nearly didn't go there. Just want to encourage others to read it for an excellent explanation of the issues at hand from the guy who is doing the work.

<comment><USER29> I'm pretty sure that "this rant" in the parent refers to Zed's post not Lucas's. The parent's point being "we should look at Zed's rant again after reading this discussion by a Debian Ruby maintainer."

<comment><USER27> Exactly.

</comment></comment></comment></comment><comment><USER30> I think there is an important point here. Debian has a lot of control, and takes very little responsibility. A similar situation:

<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380731>

<comment><USER31> wow, just wow. You would think that if you volunteer to maintain something, you would actually like what you are maintaining.

</comment></comment><comment><USER32> Hypothetical question: Now that rvm has been created, would anyone still use apt-get to install ruby even if the latest version was supported?

Sure you could argue that yes, ruby should be installed with apt-get and alternative versions should be handled with Debian's alternatives infrastructure...

I think this is an interesting case in which version numbers are more than just version numbers, they are more like sister projects, and they don't fall neatly into the "conservative and stable" or "bleeding edge and risky" camps the way maintainers typically view different versions.

From the perspective of a package maintainer, if we had to include an alternatives list for every dot version of every package, then the distro would explode in complexity.

Ruby and Python just happened to grow so quickly that their growth didn't immediately trigger the appropriate response from distro maintainers, and very quickly the community worked around the problem.

<comment><USER7> apt-get or yum for ruby? Hell yes. After wasting countless hours on random versions of crap scattered around some servers' filesystems but not others, now nothing hits production without being in a package that installs and uninstalls cleanly and declares everything it relies on being present. That includes my own code, which we package ourselves.

<comment><USER15> Hear hear. Nothing strikes fear in my heart like a /usr/local hierarchy filled with a million random versions of random programs. BTW, if you are going to install something into /usr/local, at _least_ use a cheap and easy packager like GNU "stow".

<comment><USER32> I used to think that. But consider:

A user can manage his/her own stuff in ~/bin and add it to path if he/she wants.

A sysadmin can put things somewhere like /usr/local/experiment33 and make sweeping changes just by changing the default path, which a user could override for customization.

</comment></comment></comment></comment><comment><USER33> Obviously, he should spend just a few hours in the shoes of a package manager. Honestly. What would it be without packages/ports? A mess.

The only people trying to make it bearable here are the package/ports managers and yet they don't get any kind of reward for their job. They have to come up with crazy tricks to make things just work because people who write software are unable to write proper install notes, list dependencies correctly, etc..

This process is heavy, slow and doesn't always produces the expected results (there's no doubt about it). So people thought it would be great to have just language-specific package management systems and make it unbearable again. Alright. I personally never use them and install stuff at hand unobtrusively.

Now, do your job. Go fill a bugreport. Or better yet; fork. This is not discussing things, this is not helping. Tears don't help.

</comment><comment><USER34> I have never used gentoo. Does gentoo patch packages as much as Debian? Or is their build process sophisticated to allow parallel install of multiple versions of say postgresql?

<comment><USER13> Gentoo avoids making patches specific to itself wherever possible, when it does it's generally just to make it compile+work, the changes are straightforward, and they are _applied live on your machine_ in a self- documenting way.

The build process is also sophisticated enough to be able to 'slot' potentially-incompatible versions of the same package so that they can be installed simultaneously. From my recent snapshot of the package repo I can install 5 different simultaneous major versions of postgres, with a variety of independent build options.

</comment></comment><comment><USER35> You know, maybe somebody would want to know the Debian POV on this issue:

* <http://www.lucas-nussbaum.net/blog/?p=566>

* <http://www.lucas-nussbaum.net/blog/?p=575>

Debian is all about stability and volunteer effort.

Whining is not going to fix things.

</comment><comment><USER36> I'm okay with Debian packages, unless someone include locusts as dependency <http://xkcd.com/797/>

</comment><comment><USER37> This is an Ubuntu package problem, not Debian. In case you didn't notice, Ubuntu is built from a snapshot of Debian /unstable/. They call it unstable for a reason, I guess.

On Debian stable "aptitude install rubygems" followed by "gem install rake" just works. This looks like a completely gratuitous rant, I've seen Jed Shaw better inspired.</comment>


Threading in C# - Free E-book - <AUTHOR> http://www.albahari.com/threading/ <comment><USER2> I've actually read through that site a bit before, and it's a great introduction to the different multithreading constructs in .NET (even if you're not using C#).

</comment><comment><USER3> Pretty neat website. The book _More Effective C#_ also has a great chapter on multithreading in C#.</comment>


Passive-Aggressive Behavior Is Useless In A Startup - <AUTHOR> http://www.feld.com/blog/archives/2007/07/passiveaggressi.html

<comment><USER2> Thanks for sharing, been there done that. ;-D</comment>


Google removed "Reply by chat" if recipient is off-line. Insanity - <AUTHOR>

If I got a question via chat when I was off-line, I want to respond via chat as it's important (at least to me) to preserve discussion continuity. And that is also what "reply by chat" is for, to not start new conversation. Not everyone is on-line all the time, so it's fine to reply even if my interlocutor is not on gtalk/gmail/whatever right now.<p>But since today (or maybe earlier, but I did not notice it before) I cannot (seeing only "XYZ is not available to chat") and it's ridiculous. Don't you think? <comment><USER2> I think you wanted to post here, but somehow ended up on HN: <http://www.google.com/support/forum/p/chat?hl=en></comment>


Crash leaves Toronto UberX driver confused about insurance - <AUTHOR> http://www.thestar.com/news/gta/2015/03/22/crash-leaves-toronto-uberx-driver-confused-about-insurance.html

<comment><USER2> I wonder who would take a job as a spokesperson for Uber? It seems like you're just doing a Baghdad Bob impression. You get to make statements like this one:

       Heath called it "unfortunate" to hear that
       "this driver-partner felt misinformed.
       We're always trying to enhance our process
       of communicating with our driver-partners."

At least Baghdad Bob did it for his political party and/or his country.

</comment><comment><AUTHOR> Two interesting bits from the story:

"He notified Uber and "right away my app stopped working." A week after the accident, Sindi says, the only thing he received from the company was an emailed form asking for details about the crash. "

and

"Uber maintained its insurance's unique nature can't be disclosed publicly or it might be duplicated by competitors"

Uber apparently doesn't even know if their supposed insurance policy has a deductible or not.</comment>


Life Lessons From A 27-Year Old - <AUTHOR> http://www.lifeaftercubes.com/2010/11/29/7-life-lessons-from-a-27-year-old/

<comment><USER2> I don't like traveling. I really don't. I spend most of the time feeling uncomfortable in some way (temperature isn't right, have to use the bathroom, worried about getting robbed) and it costs money! Why do people think that because they like traveling everyone else will too? And why is "go travel" considered any kind of advice? </rant>

<comment><USER3> >I spend most of the time feeling uncomfortable in some way (temperature isn't right, have to use the bathroom, worried about getting robbed) and it costs money!

That's _exactly_ why you should travel to learn about the world outside of your immediate cocoon.

<comment><USER4> I worked _hard_ to spin this cocoon. I'm fine where I'm at.

</comment></comment></comment><comment><USER5> Outcomes in the stock market and the startup world are at least somewhat correlated, which seems like a downside to being heavily invested in the stock market while committed to a startup.

<comment><USER6> To me, the best idea is to invest in areas that are less correlated with your own field.

For example, a good friend of mine works at a mutual fund as an analyst covering banks. For him, his job is already highly levered to the performance of equity markets.

Rather than invest in more stocks for his personal account, he's been looking at places where he can diversify and earn a decent return. For example, he's been investing in rental properties. Another friend works as an oil & gas ibanker, his investments are mostly concentrated in commercial real estate deals.

<comment><USER7> I have a similar feeling on big corporate employee stock purchase plans. You should _always_ sell the shares as soon as they vest (if you have the discounted purchase price most of these do) as you will likely see a stock dive around teh same time you lose your job.

</comment></comment></comment><comment><USER8> "From someone who has (hopefully) only lived about a quarter of their life"

Do other people feel the same way? Obviously future medical advances might change my mind on this, but I would prefer to die around 80...

I know the cliche is "you feel that now when you're young, you wait until you're my age and say that again"... but I suspect that when I do reach that age, my main reason for not euthanizing myself would be not wanting to upset people who know me, rather than because I actually want to live to be 100 years old.

<comment><USER9> While I completely respect your opinion and believe you and only you should be allowed to make the decision about when your life ends, I have to say that I also completely can't understand your perspective.

I want to live as long as medically possible, as long as I am not a vegetable or in horrible pain.

100 years, 200 years, 500, 1,000. I just don't think I will get bored of life.

<comment><USER8> If I don't get bored of life then I would change my mind... but I think I would, and based on, for example, old aged relatives of mine, I think they would agree with me even if they either havent said it out loud or haven't realised it themselves.

<comment><USER10> It is impossible to disentangle "bored of life" from "bored of being old" with current technology. It is very easy to imagine that people pretty freely conflate the two. Put an arthritic 80-year old on the verge of death from any of several conditions popping thirty pills a day in a fresh, healthy 18-year- old body and ask them if they're still "bored of life" in a month.

</comment></comment></comment></comment><comment><USER11> I'm sorry, but these lessons are crap. The only lesson that matters is actually from the Kenny Rogers song, The Gambler. "The secret to survival, is knowing what to throw away and knowing what to keep"

This goes for everything, girls, goals, jobs, ideas and even food =)

If you know what you want, you'll never go wrong. Most people don't know what they want, and spend forever trying to find it. But then it's too late.

</comment><comment><USER12> Your point on be an engineer is what I have been thinking lately. I am 27 as well and not in a position to be an enterpreneur. What I have realized is I need to start developing libraries(javascript/jquery) and not just use it.

<comment><USER7> I actually strongly disagree: You need to be a user of libraries not a developer of them when you work in business (that does something other than sell libraries).

<comment><USER13> I think the first poster is spot on.

Most businesses you _want to work for_ will also develop libraries/frameworks that are used in house. Or they might develop applications which consist of more than just plugging libraries together.

<comment><USER7> You will develop code you reuse, you may even pack it into libraries, however you shouldn't be thinking this is a fundamental process of the business. It's a side effect that makes some things simpler when you do similar things repeatedly.

</comment></comment></comment></comment><comment><USER14> Somehow I think he got the definition of "f-you money" wrong</comment>


Applied ML: Composition-Aware Search for Shutterstock Photography - <AUTHOR> https://www.shutterstock.com/labs/compositionsearch <comment><USER2> As the primary researcher and engineer on this project, I'm really excited to finally have been able to release this, and it's also the first system we've shown off that includes a technical whitepaper. Nothing would make me happier than seeing a paper come out in Arxiv that improves this system.

</comment><comment><USER3> This is a great application of computer vision applied to everyday business problems. Kudos to the shutterstock search/CV team.

</comment><comment><AUTHOR> The whitepaper linked in the upper-right is highly informative: [https://www.shutterstock.com/labs/compositionsearch/static/c...](https://www.shutterstock.com/labs/compositionsearch/static/cas- final.pdf)

</comment><comment><USER4> Finding good copy space is such a time consuming part of looking for images and any way to make that easier would be welcome!

</comment><comment><USER5> Love the ability to find images with copy space - I've never seen that before. It's also really fast.

</comment><comment><USER6> Truly unique tool. Will save designers hours.</comment>


Four ways trans people are changing the gender/tech debate - perfect-machine http://venturebeat.com/2013/10/19/four-ways-trans-people-are-changing-the-gendertech-debate/

<comment><AUTHOR> Here is something from the article:

"Take PalominoDB for example, a database architect firm founded by trans entrepreneur Laine Campbell."

For a group that would like to be a part of society, they sure do make an effort to separate themselves.

Why should it matter if you are woman, man, black, white, or transgendered and running a successful business?</comment>


Forget tacky loading spinners, just use a wait cursor - <AUTHOR> http://bricss.net/post/17941857127/forget-loading-spinners-use-a-wait-cursor

<comment><USER2> Nice idea, but I disagree that this should make us "Forget tacky loading spinners". Loading spinners are a big step forward from wait cursors in that they:

\- Can be used to show _what_ is loading, especially if you use AJAX to update only part of the screen/content, rather than indicate a global loading state.

\- Work on devices that do not have a cursor. Touch anyone?

\- Don't make you feel like you are running Windows 3.1

\- Don't make you fear your browser/system has frozen.

<comment><USER3> You've said everything I wanted to.

</comment></comment><comment><USER4> One issue I have with this is that due to the commonality of spinners, I associate the wait cursor with waiting on the browser (memory issue, temporary CPU spike, large js script running) rather than an waiting on the results of an ajax request.

For me at least, using this technique would probably cause me to perceive the site as being slower or more resource intensive than it truly is.

</comment><comment><USER5> I just clicked on your demo and my brain instantly though, oh crap my browsers crashed again. Even though I knew it was going to change the cursor to a wait button.

</comment><comment><USER6> Did this (using jquery):

var loadingLayer = { step: 0, add: function(){ this.step += 1; //didn't know how to call checkState() automatically after any other call this.checkState(); }, remove: function(){ this.step -= 1; this.step < 0 && (this.step=0); this.checkState(); }, clear: function(){ this.step = 0; this.checkState(); }, checkState: function(){ if (this.step === 0){ $("body").removeClass("loading"); } else { $("body").addClass("loading"); } } }; $(document).ajaxStart( function(){ loadingLayer.add(); }); $(document).ajaxComplete(function(){ loadingLayer.remove(); });

I know the JS is uggly but i'm not an js expert (it works).

<comment><USER6> Live demo: <http://jsfiddle.net/NXqe5/>

</comment></comment><comment><USER7> I vastly prefer loading spinners over wait cursors.

A wait cursor usually represents some form of synchronous wait to the entire application. If I get the wait cursor in a native application, there's a good chance that I'll need to wait for it to finish before I can continue my work flow.

A loading spinner is often more asynchronous and targeted. If I click the preview button in GitHub, then only that element is being loaded, and it doesn't stop or slow down any other part of the UI.

A good UI should be asynchronous; ideally there shouldn't be any operation that locks or slows down the UI. If an expensive operation is taking place, place a busy notifier on the affected elements. Having a wait cursor for the whole application or window seems an anachronism.

</comment><comment><USER8> No cursors on mobile. So.

</comment><comment><USER9> There's no cursor for mobile devices so whatever you think works only works for a percentage of users.

</comment><comment><USER10> Because browser wait cursors tend to make me instinctively cmd-w or cmd-q

(close tab or close application for you non macheads)</comment>


Ask HN: How do AJAX-heavy, non-static-content sites offer ads? - <AUTHOR>

How do AJAX-heavy sites (where users spend the majority of their time on a single page) server ads? As far as I know, once a site is loaded, that ad will be staring at the user throughout his session. Is there an option (AdSense or ad other networks) that would display new ads every, say, 5 minutes? <comment><USER2> I haven't actually tackled this problem, but using setTimeout to reload would be my first attempt at this issue. If that doesn't work, I might design my app in such a way that it can remember its state, and make it so that some buttons actually refresh the page. (This would detract from user experience, but hey, Ads do the same)</comment>


How to Convince Someone When Facts Fail - <AUTHOR> https://www.scientificamerican.com/article/how-to-convince-someone-when-facts-fail/ <comment><USER2> Sadly a little light on detail, but does offer up:

> 1\. keep emotions out of the exchange, 2. discuss, don't attack (no ad > hominem and no ad Hitlerum), 3. listen carefully and try to articulate the > other position accurately, 4. show respect, 5. acknowledge that you > understand why someone might hold that opinion, and 6. try to show how > changing facts does not necessarily mean changing worldviews.</comment>


Ask HN: How can I help my local community during the Coronavirus pandemic? - <AUTHOR> I'm in the US, only a few cases in my city.
I've seen the efforts to build open-source ventilators, but I'm wondering if there's something I can do now.
I imagine there are systems & processes that will break down, has anyone observed somewhere analytical/technical effort might make an impact in their local community?
Do any of the other standard volunteering channels make sense right now (food bank, etc.)? <comment><USER2> 1) The most effective thing you can do is not get sick, and not get others sick by social distancing.

2) The next most helpful thing you can do is support hospital workers. If you have friends who are nurses, doctors, etc. Ask if there is something you can do to make their lives easier. Are there errands you can do for them? Do they have toilet paper and other essentials at home? Is there a local nurse association that you can call and offer your time, energy, money, and specific skill set to?

3) Long term, the most effective thing you can do is to support hospital workers. There is an on-going nursing shortage. Nurses are being asked to take care of too many patients at once. It leads to worse care and burnout among hospital staff. We have a culture where bumperstickers that say, "support our troops", "support our fight fighters", and "support our police officers" is relatively common. We don't do that for our nurses. When they bargain for higher pay, reduced patient loads, more nurse training they don't have a bandwagon of people and politicians who reflexively say, "support our nurses" and provide money and resource to them. Their concerns are met with indifference by the wider society and our failure to support them and respect their profession harms us all.

[https://www.nytimes.com/2020/01/22/well/live/the-nursing- sho...](https://www.nytimes.com/2020/01/22/well/live/the-nursing-shortage-is- threatening-our-care.html)</comment>


Online planning poker tool: Pokrex – The easiest way to planning poker - <AUTHOR> https://pokrex.com <comment><AUTHOR> Simplicity and efficiency are at the heart of everything I do at Pokrex. It utilizes clean UI and intuitive interactions to make it make estimating easier. The original thought of building up this tool, is because the network environment in China sucks, most of the tools we were using ain't working smoothly. Then I started to create one to focus on usability and holistic user experience.</comment>


Experience with Tcl/Tk - Brian W. Kernighan - <AUTHOR> https://www.usenix.org/legacy/publications/library/proceedings/tcl95/full_papers/kernighan.txt <comment><USER2> Interesting, but only as a piece of pretty ancient history :-)</comment>