For your iOS App: Hire a Ninja, Not a Mixed Martial Artist - <AUTHOR> https://medium.com/ninjarobot-apps/hire-a-ninja-not-a-mixed-martial-artist-caed5f2c8c80#.mrnezcmrp <comment><USER2> Everyone knows you should hire a rockstar.

<comment><AUTHOR> Not quite, I've found many first time CEO's that are looking for a Demi-god of sorts

</comment></comment><comment><AUTHOR> For your first App, better go with someone that knows the Dark and polished aluminium Arts of iOS</comment>


Deliberate Practice - <AUTHOR> http://www.stubbleblog.com/index.php/2008/05/deliberate-practice/ <comment><USER2> Has anyone had any success applying deliberate practice principles to learning how to hack? I'm having a hard time coming up with measurable units of work because hacking is very much an art.

Measuring output by lines of code or # of functions doesn't give the right metric. It's like measuring the # of brushstrokes a painter takes to gauge his/her quality.

<comment><USER3> Hacking's an interesting case because all practice is also product. That means that if you practice enough, you eventually "finish" your practice material (which is great in one respect, but it means you have to find a new one to practice on, which often has its own probles). It also means that it's impossible to practice without a project to practice on - I know some blogs suggest "code kata", but most of the interesting problems in software development occur when you get past 3000 lines or so, and you can't really see that when you're writing Quicksort for the umpteenth time.

Anyway, here's what I think the difference between an expert hacker and an experienced non-expert is. When faced with a bug, a non-expert will fix the bug. An expert or prospective expert will ask himself "What caused this bug, and how can I prevent it from ever happening again?"

The answer will usually be some form of unit/regression testing, so the prospective expert will write some tests to catch the bug and _then_ fix it. Then they'll ask themselves "What prevented me from writing tests in the first place?" and the answer will usually be some combination of tedium and lack of defined interfaces. So they'll fix the first problem by learning how to abstract test state into reusable fixtures, and they'll fix the second by refactoring the production code so it has clearly defined public interfaces with defined inputs and outputs.

Then, after doing this a few times, the prospective expert will ask themselves "Where are my bugs coming from? What are most of my tests checking?" And if their code is anything like mine, the answer will be "the use and abuse of mutable state". So they'll go through their code looking for places where they can use purely functional techniques to eliminate mutable state. Or they'll change their APIs so that they eliminate any call-order dependencies they've programmed in. Or they'll encapsulate their mutable state in certain well- defined objects with known lifetimes.

Then the prospective expert will look at this activity and think "how could this be made less tedious?" And the answer will often be to add some extra abstractions which have now been made obvious because of the data flow's been exposed.

Then they add some more features, keep track of the root causes of their bugs, and fix the _next_ most common error. (Which in my experience is usually type errors, but unfortunately working in a statically-typed language seems to eliminate many of the opportunities for abstraction that are exposed in the last step, unless it's Haskell, which isn't yet practical for webapps.)

Disclaimer: I'm not an expert. Yet. I am, however, noticeably better than I was 8 months ago when I left my last job. One of the reasons I left was because there was a ceiling to how many of the above techniques I could apply - I could unit test my own code, but I couldn't change the API to make it more stateless, or eliminate nulls as a legal parameter to methods, or separate components so they were each stubbable on the local computer.

I have known a couple programmers that were real experts though - one wrote the filesystem and transaction server for Stratus and has been an early engineer and tech lead (and sometimes VP of engineering) of 3 IPOs. She was full of all these techniques, some obvious and some pretty subtle, for reducing bug rates. For example, she'd define a private copy constructor on any class that wasn't intended to be passed by value, so the compiler would flag shallow copies as an error. Then she defined this in a mixin base class and inherited from it, so she didn't need to implement the pattern in every single one of her classes. Or she'd use references vs. pointers as a way of flagging object ownership: they're exactly the same thing, but the compiler won't let you delete a reference, so she'd pass by reference if ownership wasn't being transferred and pointer if it was. Every language has these sort of subtle tricks: in JavaScript, it's things like not extending built-in prototypes and using closures effectively. The difference between deliberate practice and mundane programming is that you're actively looking for patterns like this when you deliberately practice.

<comment><USER4> I disagree as I think the real difference is mainly in the design process. If there are too many bugs or things start to get complex an expert hacker will ask himself what I can do to improve the design? To make it simpler, more modular? If I've this problems probably I've a design error.

Actually most of the times like an expert chess player an expert programmer just using "pattern matching" and his experience can tell what the right design (right = simple, modular, scalable, ...) is among all the different possible solutions. That's the difference not testing or ways to avoid pitfalls.

<comment><USER3> I don't think we're really disagreeing, as usually the answer to "How do I make sure this never happens again?" is some sort of design change. My point is that this is done iteratively, in response to _actual_ problems, instead of hypothetically in response to imagined problems.

I should probably also make clear that experts don't throw away everything they've learned with each new project and start anew. They do throw away _some_ things, and part of being an expert is knowing what to throw away and what to keep. It's sort of an unfortunate fact of software engineering that each problem is different: otherwise, you'd just use pre-existing software. But there're some skills (like the C++ tricks I picked up from my Stratus friend) that you can take with you as long as you maintain the same technology platform, and others (like unit testing and clear component interfaces) that apply to all platforms.

<comment><USER4> > in response to actual problems, instead of hypothetically in response to > imagined problems.

This is really one of the differences indeed and you stated it very well, and you are right, stated this way we are saying a very similar thing. Also I think this other sentence from your comment is very interesting:

> part of being an expert is knowing what to throw away and what to keep.

So now the picture I get is that the real difference is selectiveness: about what design to pick among the possible, what problem is worth to fix, what experience is worth to remember.

Thanks for the interesting comment.

</comment></comment></comment></comment></comment><comment><USER5> The Freakonomics guys discussed deliberate practice recently on their NYT blog: [http://freakonomics.blogs.nytimes.com/2008/03/11/how-did- a-r...](http://freakonomics.blogs.nytimes.com/2008/03/11/how-did-a-rod-get-so- good/)

</comment><comment><USER6> There is a famous saying from the Army: "You don't rise to the occasion, you fall (or default) to your level of training".</comment>


Easy Retweet Button - <AUTHOR> http://ejohn.org/blog/retweet/ <comment> onreact-com Good solution but it only tracks bit.ly tweets as far as I can see so the number displayed is wrong. I prefer the Backtype WordPress plugin as a solution that tracks most short URL services. It's like Tweetmeme but better.</comment>


OpenEMR 5.0.0-4 - <AUTHOR> http://www.openhealthnews.com/content/openemr-releases-medical-image-viewing-support <comment><AUTHOR> Hi everyone! Matthew, an admin of OpenEMR, here.

This imaging release this took _many_ nights and weekends, but the small project team really worked well, even across multiple time zones and cultures!

Hope you enjoy reading about the solution and I would like to mention that the software is used by many low-resource healthcare facilities around the world. Our team of volunteers could do even more for these folks with donations on our Open Collective: [https://opencollective.com/openemr](https://opencollective.com/openemr)

If you want to join our global team of volunteers, you are welcome! We take everyone... designers, programmers, clinicians, tech writers, etc. Contact is in my profile.</comment>


OmniTweet - An experimental minimalist Twitter Client for Google Chrome - <AUTHOR> http://github.com/abraham/omnitweet

<comment><USER2> you can essentially do this (post a twitter message from the address bar) in Chrome or Firefox without installing anything if you just configure a custom search engine with the path <http://twitter.com/home?status=%s>

1\. In Chrome, go to Options > Default Search engine > Manage > Add

2\. Give it a name/keyword e.g. "tweet" and URL <http://twitter.com/home?status=%s>. Hit OK.

3\. Now from the address bar, you can type: tweet [msg]

4\. Forwards you to twitter. Although you still have to click a button on twitter, you could easily write your own serverside twitter API client that could post your tweet without the click.

<comment><AUTHOR> Yes you can. It would not however poll for new mentions, and direct messages wich OmniTweet does.

Plus you have to wait for twitter.com to load which takes longer and longer.

</comment></comment><comment><AUTHOR> OmniTweet is my current guilty pleasure project.

<comment><USER3> It looks like a perfect example of minimalist usability, and definitely not something you should feel guilty about. Aside from the rough edges, of course, like the fact that it's hard to install until Chrome makes some more progress on their extension API.

<comment><AUTHOR> Thank you. :) It is mostly just a guilty pleasure project for when I don't want to do contract work.

Yes. The install process is horrendous. Starting Chrome with a terminal command gets irritating to say the least. Hopefully Google will roll some of the APIs into beta soon.

<comment><USER4> Thanks for testing out the omnibox API when it is still so difficult to use. We start out new APIs in experimental to get a feel for how they work before becoming stuck with them forever.

<comment><AUTHOR> No problem :) I've had fun working with it.

Is the Chromium Extension Group the best place for me to provide feedback on the omnibox API?

<comment><USER4> The group is a good place. We read tweets and blog posts too, so that will eventually make its way back.

</comment></comment></comment></comment></comment></comment><comment><USER5> I don't suppose the Omni folks might complain about the name?

<http://www.omnigroup.com/>

<comment><AUTHOR> Could be if OmniTweet ever gets popular enough.

For the record it is named after the Chrome feature omnibox not Omni Group: [http://code.google.com/chrome/extensions/dev/experimental.om...](http://code.google.com/chrome/extensions/dev/experimental.omnibox.html)

Edit: I have also never been particularly happy with the name so will probably change it regardless.

<comment><USER6> I was thinking TweetBox but that name is taken several times over.

<comment><AUTHOR> Maybe TheRealTweetBox? Hehe. I have a couple of ideas for new names rolling around my head.</comment></comment></comment></comment>


The Plane Giving the F-35 a Run for Its Money - <AUTHOR> http://motherboard.vice.com/read/low-and-slow <comment><USER3> There was a fantastic article and analysis I read some weeks ago that addressed this issue, and I'm trying desperately to find it. However, I remember the key points, and I'll surmise them here:

\- The A-10's survivability is overrated. The Air Force conducted studies after both Gulf Wars and found that the A-10 was taking higher damage per sortie when compared in '91 to '03\. That Iraq's air defense was in shambles didn't seem to diminish the fact that the A-10 was becoming more vulnerable to more sophisticated weapons. Technology has made cheaper weapons more effective since the 1970s in which this was designed. In a higher threat environment, the lack of sophisticated sensors, threat identification, and ECM is seen as not boding well.

\- The A-29 is a fantastic plane. But it's giving the A-10 a run for it's money, not the F-35. In the low-threat COIN environment, it has all of the benefits of the A-10 with none of the drawbacks. That famous cannon isn't always idea against militants in the mountains when you're worried about spraying your own troops. That the A-19 can carry small guided weapons just like the A-10 gives it capabilities where it counts. And it's half to a third of the price to purchase and maintain.

So the A-10 is getting squashed from two sides: The F-35 can penetrate the high-threat environment, and provide CAS in a lethal SAM environment, while the A-29 can provide CAS/COIN against militants in a low to non-existent threat environment. There is no middle ground. It left when air defense systems gained the sophisticated tracking and accuracy that wasn't there in the 1970s and 80s.

The A-10 was a fantastic plane and well designed for the time in which it was envisioned to fight. But even I agree that it's time has passed. Like the F-14, it's sad to see it go, but I think it's the right call.

<comment><USER4> "The Air Force's F-35A version of the aircraft and hold 182 rounds. It's slated to be externally mounted on the Marine Corps' F-35B jump-jet variant and the Navy's F-35C aircraft carrier version and hold 220 rounds"[1]

The F-35 has no hope of doing sustained CAS. It is another Air Force "drop your bombs and fire a few shots then run home" plane. An A-10 can keep insurgents away from your troops for a fair amount of time.

They should strip the Air Force of its CAS role and hand it back to the Army. Then the Air Force can concentrate on what it likes: strategic bombing and air dominance.

1) [http://defensetech.org/2015/01/02/a-tale-of-two-gatling- guns...](http://defensetech.org/2015/01/02/a-tale-of-two-gatling- guns-f-35-vs-a-10/)

<comment><USER3> There's a lot more to CAS than simply how many bullets your gun has. In any case, it's often not the preferred weapon. Bullets are indiscriminate. Small, precision warheads are becoming more in favor because the safety margin is better.

We've been seeing quite a bit in Afghanistan now where CAS is actually being performed by a B-1 carrying a SNIPER pod, sitting up at medium altitude with a large load of small precision bombs.

But that shows you the type of environment Afghanistan is, where the Air Force can deploy high value assets like a B-1 to perform CAS, because their anti-air threat is non-existent. The Air Force is not developing the F-35 to fight insurgents, they're deploying it to fight a well equipped, conventional force that will have multiple layers of sophisticated weapons. They'll do everything they can to soften these up before the strike aircraft go in. But there /will/ be some that remain, and its in this environment, that the F-35 needs to survive.

In the low-threat environment against insurgents, you can do that job just as well as the A-10 with the A-29 as the article states, for ever cheaper.

This is the conclusion that the Air Force has come to, and that's why they're retiring the A-10.

<comment><USER4> My cousin has related stories of the A-10 watching over him and his troops. Bullets most definitely were the main item related. The A-10's ability to stay above his group and fire a couple of rounds every so often allow them to sleep. The F-35 or B-1 is not going to do that. Drones don't currently do that. The goal is to safeguard the troops and bullets work very well.

The Air Force hates CAS and will say anything to get out of it. The fact that a modern version of the A-10 has not been developed (the F-35 is not a modern version) says everything about the Air Force's direction.

<comment><USER5> The A-10 is an obsolete concept. Weapons are so much more advanced than armor that the best defense is to not get hit. If you want cannon fire supporting you from above then you want an Apache.

<comment><USER6> Curious why half of your postings are ragging on the A-10 and claiming it is obsolete?

For that matter, the Apache is considerably more fragile than the A-10.

<comment><USER3> I was a little puzzled about this as well. Specifically, this incident: [https://en.wikipedia.org/wiki/2003_attack_on_Karbala](https://en.wikipedia.org/wiki/2003_attack_on_Karbala)

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> There's something similar in the world of jet aircraft too. The Textron AirLand Scorpion, built from off the shelf parts, designed to take a whole bunch of ordinary weapons systems, went from design to flying at air shows inside 3 years, without massive costs. It's a subsonic, twin jet plane with a stall speed around 100 knots, which costs ~$20m.

It's not remotely clever compared to the Eurofighter, Sukhoi Su-XX jets or similar recent generation multi-role aircraft, but for low speed engagement with flexible hardpoints and easy maintenance, it's hard to find many competitors. Which is weird, given the nature of most aerial combat roles for the past 15 years.

<comment><USER8> I thought of these fighters as well. Governments don't buy these because they don't want a 9/10 fighter. They'd rather buy a decades old 10/10 fighter even though they'll never need (and probably can't pay for) that extra 1/10.

</comment></comment><comment><USER9> > but had the plane been flying as low and slow as older generations of attack > planes did, the crew might've realized their error simply by looking down at > the ground.

There are a lot of WW2 incidents of friendly fire casualties from ground attack aircraft, both from aircraft attacking their own guys to aircraft being downed from anti-aircraft fire from their own side. This happened to all sides in WW2.

<comment><USER10> Also WWII had 4 major theaters, probably 100 000 000 troops mobilized or deployed, and production lines for armor and planes that would make Henry Ford gawk. The scale guaranteed that the friendly fire will occur often.

<comment><USER11> Not scale but lack of forward airforce liaison officers. Germans didn't have the same problem.

</comment></comment></comment><comment><USER12> "A crew operating a high-tech fighter plane made a terrible mistake" -> "Had the crew been close enough to the ground to see their enemies, the mistake _may_ have been avoided" -> "A-10's require pilots to be close to their enemies" -> "A-10's and planes that rely on dated technology are superior to those that utilize the latest and greatest weaponry."

This argument is useless without determining how many incidents like the example described at the beginning of the article occur, whether they could be avoided with an older plane, and whether the cost of the mistakes made by the newer planes outweighs the advantages they provide.

<comment><USER13> Not in this case it was a sw issue on the GPS that caused this problem.

<comment><USER14> It seems like fixing the software problem is a more reasonable response than buying and maintaining significant numbers of a new air frame.

<comment><USER13> Yes an example of poor test cases happened a few times in Iraq as well

</comment></comment></comment></comment><comment><USER15> Afghans eventually withered down close Soviet air support. Soviet strategy seemed to be winning with new air and infantry tactics. Until they started losing hundreds of aircraft. If I remember correctly it was mostly heavy guns and not US Stingers that did the trick.

The enemy is well aware that all they have to do is win an endurance war against an inflexible bureaucracy that bleeds money and outlast the patience of a fickle populace. This was demonstrated recently enough in Vietnam. US strategy was losing, even though they won almost every fight in both wars.

It would take a lot more than this one cheap fighter to outlast the Afghans. At least body count was better this time.

</comment><comment><USER16> A different plane would not have helped winning Afghanistan. suffering might have been even longer. The expectation to win there is an illusion.

Looking for technological solutions - low or high tech - is just more of the same misguided thinking. The case is lost in a totally different way - it's not technology.

<comment><USER10> Everything is winnable. But the pentagon is mostly a state/corporate subsidy program with some military capabilities as a side effect.

US hasn't been in a war they HAVE to win since WWII (and even then continental US was pretty safe) so the institutional knowledge that was bought with blood is soon forgotten.

Afghanistan was not won, because there was never a criteria for winning towards which the military and the state department to work. And the fact that US has the habit of cooperating with the wrong people in third world countries, makes things worse.

If the US had courts in Afghanistan in which to try corruption, Afghanistan would be a better country now.

<comment><USER17> Germany was winnable because after the fighting U.S. and other allies we're willing to occupy the area with huge number of troops for 50 years. Also Marshall plan.

Korean war was winnable for the same reason. Huge numbers there. Even today. Here you can see the long tail of Korean war. [http://www.heritage.org/~/media/images/reports/chart5_1.ashx...](http://www.heritage.org/~/media/images/reports/chart5_1.ashx?w=520&h=429&as=1)

Vietnam was not winnable because general population didn't support such high numbers for occupation. There we're practically no U.S. troops left for the last two years of the war.

Since Vietnam U.S. cannot use draft. So U.S. can only conquer one, maybe two countries while keeping Korea and Europe under control. But that leaves those troops bound on foreign soil. Which in turn limits U.S. power projection and therefore cannot be the long term solution.

Wars have not changed. DoD just would love to find a way to win wars without the ensuing occupation. And that's unlikely to happen.

<comment><USER18> No, as old Macchiavelli put it: if a country is hard to conquer, it will be easy to hold; if a country is easy to conquer, it is hard to hold. The reason is that a united, highly organized country fights hard, but it won't fall apart into dozens of factions after being conquered. Unlike countries like Iraq or Afghanistan.

<comment><USER17> I'm holding a copy of Prince and happened to find that verse. It's about Ottoman imperium and feudal France.

If there is a dictator and you simply become the new dictator, then keeping a country is easy. That would have been because none of the military leaders would have any loyalty among the people. But nationalism has happened since and it's questionable if this would hold anymore.

If there is large number of Feudal lords, this makes taking France potentially easy as some of them would betray the king. But on the other hand they would have loyalty of the people with them.

Times have changed, otherwise Iraq should be peace of cake now that Saddam is dead.

<comment><USER18> After Gulf War I, Saddam had to resort to brutal military actions to keep the various tribes from seceding. Afghanistan has been ruled by 'feudal lords' for a long time. Neither Iraqi nor Afghan soldiers were eager to die for their states, which were colonial constructs anyway. If the country you are invading implodes after a few days of fighting, you can expect trouble.

</comment></comment></comment></comment></comment></comment><comment><USER8> "The Hornet's cost per flight hour? $25,000 to $30,000, according to official Navy figures. It's estimated the F-35 costs anywhere between $31,900 to $38,400 per hour to fly."

So the F-35's lower hourly rate is almost the same as the Hornet's upper rate? Doesn't seem like that much of a deal.

<comment><USER19> The Hornet is an actual Jet and therefore those costs are real. The F-35 estimates are the most conservative that are legally defensible but will almost certainly much greater than that once actually in service.

</comment></comment><comment><USER20> The real kicker for me was the cost per hour for flying these. 600 bucks. Roughly 2 orders of magnitude less than a 'modern' plane.

<comment><USER21> The numbers I can find for operating JAS Gripen is roughly $4700, so there are some modern planes that are only one magnitude cheaper. However, many tend to not prioritize operating costs very high.

<comment><USER22> The Gripen is specifically designed for cost effectiveness. If you want a modern jet fighter with the most bang for your buck, the Gripen is the most obvious choice. If money is not an issue, there are plenty of better jets available.

</comment></comment></comment><comment><USER23> What I got from reading this article is the impression that it makes absolutely no sense to use the F-35 for close-air support. It is inferior in performance and far more expensive to operate than the A-29 for CAS missions. Here in Canada, politicians are dithering and dickering over whether or not to buy the F-35 now that it's looking less impressive and the weak Canadian dollar has made it far more expensive. For some inexplicable reason, the prevalent idea is that the RCAF should own and operate just one model of fighter. This idea needs to change.

The reality is that Canadian planes have not engaged in air-to-air combat since the Korean war, but virtually every conflict the CF participates in requires close-air support. That mission is currently fulfilled by CF-18's. The A-29, or a similar plane, could provide superior CAS capability for far less money. Then, as an added bonus, the successor to the CF-18 would not need to be compromised for CAS, as the F-35 is. Canada could look for a pure air- superiority fighter, and buy a smaller number of them because they would not be called upon to perform CAS. The end result would be an air force that's better at it's primary roles and far cheaper, and Canadian forces (and their allies) on the ground would be far safer.

Maybe I'm wrong?

<comment><USER24> I'm totally with you. The CF-18 is pretty good for Arctic sovereignty and for maintaining our NORAD commitments, but absolutely terrible for peacekeeping & observation missions. Same goes for coast guard missions. The F-35 seems like it would just be bad at all of them. Would you want to fly a sortie north of the Arctic circle in a single engine jet?!

<comment><USER25> In your opinion what makes it terrible for peacekeeping & observation? Isn't it just a matter of Canada not buying and integrating suitable armament? With Jdams and Paveways you have to go too close for early operations, but Canada still dropped 10% of bombs in Libya according to wikipedia. Sweden has a similar setup, missing proper ranged options but they were restricted to doing strictly recon in Libya. In the end I suspect that even if you had the ability, no-one besides USA(/UK/France/Germany) has the stockpiles/willingness to start throwing around cruise missiles in foreign ops. For smaller countries there's political reasoning behind doing enough but not everything you possibly could in foreign ops.

Not all modern fighters have started as a multi-role, but every good fighter has ended up as one.

<comment><USER24> Dropping bombs isn't necessarily peacekeeping :).

If I'm remembering properly, my grandfather was stationed in Yemen in '63-'64 as an aircraft field mechanic. Their mission was purely observational: every 12 hours, fly over the border and count any accumulation of military equipment. I believe they had a DHC-3 Twin Otter.

I don't know the specifics, but looking at the specifications: 945 mile range, 121 mph cruise speed on the DHC-3. That's give or take a 6-7 hour loiter (they were landing in the desert and had fuel trucks come daily). It's harder to get exact specs on how a CF-18 would perform on such a mission, but I've got a pretty good feeling it's not going to be landing on any gravel airstrips, nor is it going to be fun trying to count vehicles on the ground.

When I think of peacekeeping missions, I think of boots on the ground, ideally with air support. Looking at the A-29 from the article, that sounds a lot more like the type of aircraft that should be providing that support.

</comment></comment></comment></comment><comment><USER13> The blue on blue in Afghanistan mentioned in the first para was caused by the GPS resetting its self (to the current location) when the batteries where changed.

Which is why the SF team unfortunately called the strike on them selves - <USER2> happened a couple of times I belive.

</comment><comment><USER26> My biggest concern about F-35's is how quickly they can be made in wartime situations. They have so many sophisticated instruments... can they really be mass produced? In WW2, Germany had the best tanks, but the Soviets and the Americans overwhelmed them with numbers. You can say that WW2 is an old war, but if you're wrong do we really have a reliable plane that we can mass produce anymore?

<comment><USER27> In modern, high-intensity warfare, you fight with what you have. The days of producing a Liberty ship a day are way past our industrial capability, and the technology in the F-35 and fighters of its caliber limit the ability to mass produce in anything close to WW2 quantities.

<comment><USER26> You could say that about the initial stage of the war, but can you maintain an occupying force for years against a sophisticated country? In that case, we would eventually run out of F-35's due to sabotage or maintenance issues.

This idea that the only thing that matters is what you already have creates a race - can you crush resistance before those who are resisting realize that you have limited long-term capability?

<comment><USER27> The weapons used in an occupation are vastly different than what you use to initially defeat an opponent. Most occupations are faced with insurgencies equipped with small arms, not 5th generation aircraft.

In Iraq, we had time to spool up production of MRAPs to counter IEDs, and were pretty quick to deploy equipment that would aid in COIN warfare.

But MRAPs would be shit in a real war against a peer grade opponent; too heavy, too slow, confined to roads, poor overall performance.

</comment></comment></comment></comment><comment><USER28> A terrible article entirely predicated on anecdotal evidence. I have no doubt that most of the 'technologically advanced' equipment Americans put into and will put into wars will ultimately fail to live up to expectations.

But let's give another anecdote about the A10. In Iraq, the A10, just like the B52 in Afghanistan, was responsible for killing two truck loads of British soldiers. Its pilot mistook the luminous arrow signs that indicated friendly forces for missile systems.

In Afghanistan, an American Apache mowed down a platoon of British troops after being called in as air support and mistaking the troops for the enemy.

The thing that links all these incidences is not low or high tech but the American military. Clearly its pilots, soldiers, staff are not trained properly. Just a bunch of reckless idiots. Much like the government that sent them.

<comment><USER29> > * The thing that links all these incidences is not low or high tech but the > American military. Clearly its pilots, soldiers, staff are not trained > properly.

No, the thing that links them all is war - it's incredibly messy and people have been killing the wrong people in wars for as long as men have been fighting.

<comment><USER30> Whilst you are correct, and every conflict has blue on blue engagements, the US military have a very bad reputation for being bloody dangerous to their allies. Mission videos that do emerge of incidents where US aircraft, helicopters and drones end up engaging friendly or non-hostile targets commonly show a marked desire to engage the enemy and view any and all information coming in as confirming that initial prejudice.

I'm not saying this applies to all US military personnel or that other militaries do not have problems.

<comment><USER3> I honestly believe this is largely the result of the U.S. performing the vast majority of sorties flown.

Deploying air forces in an expeditionary capability is difficult and expensive. It's much more difficult than deploying a ground unit. Few forces have this capability.

When you're in Afghanistan, and 90% of the CAS sorties are performed by the U.S., then it stands to reason that if an incident occurs, it'll likely have been a U.S. aircraft based on odds alone.

<comment><USER28> I suspect you're correct. Issue is, from what I read, it would perhaps be better if most of those sorties were never flown. It seems that use of air power will tend to prioritise the lives of soldiers over civilians. ('Blue on blue' not withstanding, but then my point above was not really about that, but about the anecdotal nature of much of the conversation.)

<comment><USER3> If I'm reading you correctly and I take this to it's logical conclusion, one could correctly assume that in any war, regardless of the precautions, technology, and training, you will have civilian deaths. You'll have terrible incidents where friendly forced were shot at, or buildings misidentified and a family of four blown up.

It's probably drifting out of scope of this conversation, but it can probably never be reemphasized enough that these will be the consequences of any war, and as such, a war should never be seen as a favorable outcome. In that, I definitely agree with you.

<comment><USER28> Indeed agreed.

</comment></comment></comment></comment></comment></comment></comment><comment><USER31> I can certainly buy the narrative that the military is spending too much money or designing weapons for the 'last war'. Yet I have a nagging suspicion that this is like the business users complaining that IT won't just buy everyone $200 laptops to save money. Devil's advocate: what could the Airforce's rationale be? I hate to write off the professionals so quickly.

If you need a turboprop attack plane to deal with a specific threat, you can fast track something cheaply because it's a widely known/used technology. The converse isn't true. You can't go back and decide you need a top tier $trillion fighter in a month.

Loiter time is important. Yet most military engagements in history are decided by speed and firepower.

<comment><USER32> The problem is that all the employees are just playing minesweeper, a $3k macbook pro running windows in a VM is the wrong tool for the job. $200 notebooks are perfect.

</comment></comment><comment><USER33> Thats a bit like eating soup with a fork and concluding the fork is broken.

<comment><USER34> The fork is the wrong tool.

<comment><USER20> You have to give the guys the right tool for the job. The guys are telling you that the F-35 is the wrong tool for the job. "Yes, keep using that drill to install those nails because otherwise the taxpayers will have our asses."

</comment></comment></comment><comment><USER35> Talk about clickbate, it's a shame to see this up voted on HN.

</comment><comment><USER36> This is the equivalent to saying that a cigarette boat could get a couple shots off in a fight with a battleship because of it's maneuverability and speed.

Well yes that may be true.

However, it's more likely a battleship would sink a cigarette boat with a precision guided weapon a second after it becomes visible on the horizon.

<comment><USER37> ahhh, but put a little effort into building the cigarette boat and the response envelope is drastically small, small enough that a swarm of cheap boats could gut a battleship.

</comment></comment><comment><USER38> I would love to see the content labelled as "sponsored by Embraer" or the likes.

<comment><USER39> Really? You really think Embraer would go to _Vice_ for its PR?

<comment><USER40> Their PR dept could very well have floated this story all over the place and Vice is the one that took the bait.

</comment></comment></comment><comment><USER41> My working assumption is that military procurement has everything to do with which contractors need to get paid and very little to do with military objectives, since we don't actually have any achievable military objectives.

</comment><comment><USER42> Quantity has a quality all its own.

</comment><comment><USER43> WW2 era? What a load of rubbish, just because it has a propellor. The basic Tucano first flew in 1980.

By the same yardstick I assume Vice thinks a helicopter is da Vinci era?

~~

The turboprop ( geared propellor driven by a jet engine ) is still the most efficient means of aviation propulsion devised; it surpassed internal- combustion engines in efficiency in the early 1960s, with the Turboméca Astazou, and continued to improve.

Turboprops fall-off in efficiency with altitude and speed, but below around 20,000 ft and 400 kts they're the champions.

<comment><USER44> Typically in the news process the copyeditor chooses or edits the title of the piece for brevity and "punch."

By saying "WWII-era," the title very succinctly sums up the idea that "hey, there's this interesting airplane that's been in the works alongside the very expensive F-35, but it's actually much cheaper and much less technologically advanced, but actually much better suited for the war in Afghanistan--and it resembles the types of fighter planes that you've seen in 'Pearl Harbor' and 'Saving Private Ryan'."

The title is meant to convey as much information to the audience (a general, non-technical audience) in as few words as possible, and it mostly does its job.

If you read the article, it's clear that the authors understand the difference.

<comment><USER45> I think dingaling's point is that the headline is clickbait.

<comment><USER46> The editor was trying to convey as much info within the given length as they could. They didn't realize that it would result in a title that was also clickbait. Remember, never blame malice where stupidity will suffice.

(P.S. Of course it was click bait and purposefully done so, there is an art to creating clickbait headlines that can be defended as not being clickbait.)

<comment><USER47> Do you actually have a line of communication to the editor or are you guessing?

<comment><USER46> Direct line of communication. But they could still be lying, so I guess I should say it was a guess.

Actually, I got a psychic to get me direct access to their brain, so I'm sure they aren't lying. But they could be incorrectly remembering it. So we still can't be certain. For it to be 100% not a guess, I'm going to need to get go back in time with my time machine and have the psychic come with me, but he is saying something about how that could cause problems.

So sadly we are stuck just inferring (guessing) with the information given.

</comment></comment></comment></comment></comment></comment><comment><USER6> For close-air-support (which the Air Force really doesn't want to be involved in...), the most effective aircraft have often been cheap, slow, unsexy aircraft that can carry a lot of ordinance, take a lot of punishment, and get down low and slow to hit ground targets with bullets. See the Ju-87 Stuka, IL-2 Sturmovik, Douglas A-1 Skyraider, AC-47 and AC-130 gunships, and the A-10.

</comment><comment><USER48> War in Afghanistan? I seem to miss the formal declaration of war by congress as required by the constitution.

<comment><USER49> Happily, I'm here to help! This is what you missed:

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

Anything else you need?

</comment></comment><comment><USER50> Hell, lets scrap them all for a fleet of modern drones supported by advanced AI.</comment>


Show HN: A mostly complete 2014 "Tools of the Trade" - <AUTHOR> https://github.com/cjbarber/ToolsOfTheTrade <comment><USER2> Is anyone surprised that so many of those are payed services instead of OSS projects?

I understand payroll, analytics and others like such. But things like bug trackers, dashboards, CIs, exception handling, log monitoring. At some level maybe it is a bit like selling shovels during a gold rush. Find what most start-ups need and monetize that. The gold prospector has a high chance of going home empty-handed, but he will surely need a shovel to even start digging.

<comment><USER3> > Is anyone surprised that so many of those are payed services instead of OSS > projects?

No. Developer time is expensive, whether you're contracting it out or you're paying for it amortized over salary/benefits/etc.

If its going to take more than 4-8 hours to setup and/or more than 1-2/hours a month to maintain, I'd rather get a credit card out and just pay for it.

Do what you're best at, outsource everything else.

<comment><USER4> I'd rather use an OSS solution but pay someone else to host and maintain it, that way if they shut down or whatever I can just copy my data and worst case run it myself.

<comment><USER3> Does it need to be an OSS solution as long as the data can be exported at will into a standards compliant format?

<comment><USER5> "Standards compliant format" can be misleading. Sure, an app might give you a zip file of CSV files (which is as 'standard' and 'humanily readable' as you can get), but that doesn't mean you'll be able to import it into another tool/software. The data model could be completly different.

<comment><USER6> Good point... but likewise: just because an app is OSS doesn't mean it's data is portable.

<comment><USER5> It does. You can run any version of any OSS programme with or without any custom patches you write. You can obviously import that zip-of-csvs into that programme.

<comment><USER6> Maybe I phrased that poorly. All data that can be retrieved or viewed can also be exported with enough effort. But OSS doesn't guarantee that process will always be easy and hosted, closed-source doesn't guarantee it will be hard.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> It's a great list, but I don't understand why it's limited to SaaS. Self hosted apps could definitely be considered "tools of the trade". Perhaps I'm just biased because I sell a self hosted project management app - [http://duetapp.com](http://duetapp.com), but it seems like an arbitrary distinction....

<comment><USER8> OT to the post, but is there a reason you went the self-hosted route rather than SaaS?

<comment><USER7> Short story - It's a product that I needed that didn't exist. There are only a handful of self hosted project management apps and none of them felt like the right fit, especially with regard to UX. After a couple of years of waiting I finally decided to build it myself.

I wrote about some other reasons on my blog (i.e. cost), but the primary reason is that I wanted it for myself. Here are the links to the blog posts if you're interested in reading more about my thought process:

[http://www.duetapp.com/blog/no-more-project-management- apps/](http://www.duetapp.com/blog/no-more-project-management-apps/)

[http://www.duetapp.com/blog/is-saas-the-only-business- model-...](http://www.duetapp.com/blog/is-saas-the-only-business-model-for- the-web/)

<comment><USER8> Thanks! It's always interesting to hear the thought process behind entrepreneurs choosing a path that isn't the norm (since SaaS does seem to be the default path for better or worse).

</comment></comment></comment></comment><comment><USER9> > Jenkins | [http://jenkins-ci.org](http://jenkins-ci.org) | @jenkinsci | > $60/mo - $200/mo

AFAIK, and can tell from the [http://jenkins-ci.org](http://jenkins-ci.org) site linked, Jenkins is still free (libre and gratuit).

</comment><comment><USER10> Another updated list of tools and utilities: [http://www.hanselman.com/blog/ScottHanselmans2014UltimateDev...](http://www.hanselman.com/blog/ScottHanselmans2014UltimateDeveloperAndPowerUsersToolListForWindows.aspx)

</comment><comment><USER11> Pay pay pay pay pay pay pay.

I have all of that and pay nothing. It builds up otherwise very rapidly.

For example the company I work for currently churns out a mere $16k a year for JIRA now that the pay pay pay has caught up...

<comment><USER12> You have to pick your poison: build up subscription costs, or build up support costs to maintain your own deployments. Depending on your budget, the number of users, the need, the support contract with the vendor, and your priorities, the costs can go either way. That's the premise that both ___ as a service and ___ proprietary software selling support contracts are built upon.

<comment><USER11> Or avoid the tool treadmill to start with...

That is my philosophy.

Managing licenses sometimes has a large overhead as well.

</comment></comment></comment><comment><USER13> Created a PR for a basic table of contents, I can see this being pretty useful when the need arises.

<comment><USER14> Wouldn't hurt to alphabetise the individual content lists either.

</comment></comment><comment><USER15> What happened to all the applications and services for outsourcing HR departments in terms of payroll, benefits, ect.? -- thought there were a bunch more than Workday and ZenPayroll?

Getting a full list of those would be particularly useful.

<comment><USER16> ADP off the top of my head

</comment></comment><comment><USER17> We tried to use Airbrake at the last startup I contracted for and it was embarrassingly underwhelming. The landing page makes it look awesome, but compared to HoneyBadger, it was just not up to par when it came to error notification. We were looking for centralized errors for Ruby and Python code so we ended up going with Rollbar.

Airbrake shirts are great though.

</comment><comment><USER18> Nice job Chris! If anyone wants to see feedback from other developers about these tools, the majority of them are on [http://leanstack.io/popular](http://leanstack.io/popular) (disclaimer: Founder of Leanstack.io here).

<comment><USER19> Nice app. I noticed vendors can't self-select a category. That might be a useful feature for services that want to identify themselves in a category that isn't immediately clear. For example, the lines could blur between File Storage and Cloud Storage.

<comment><USER18> Thanks! Self-selecting for categories could get tricky because we're regularly creating and deleting categories as we see fit. We'd rather stay on top of that than put the burden on vendors. But we usually do make edits if a vendor asks.

</comment></comment></comment><comment><USER20> Why are there two different Log Monitoring sections, with no overlap in tools?

An alphabetisation of section headings and a clickable Table of Contents would be good, given the pretty comprehensive nature of the list.

<comment><USER21> I think it's because the list is being built by pull requests. Two people submit a Log Monitoring section at the same time and the repo owner merges without really paying attention.

</comment></comment><comment><USER19> I created a PR for a Cloud Storage section since I didn't notice one yet and added [https://kloudless.com](https://kloudless.com) to it. (disclosure: co- founder of Kloudless here).

Google Docs is probably the closest cloud storage-related utility on that list, but is under the "Notes" category.

</comment><comment><USER22> Awesome list.

I recommend adding ToutApp([http://toutapp.com](http://toutapp.com)) under sales tools.

</comment><comment><USER23> It's fascinating that the proliferation of EC2 has enabled services by different vendors to be provided on virtually the same physical network (with associated performance).

Much of what is attributed to the rise of SaaS and "The Cloud" is in fact a direct consequence of Amazon's infrastructure.

<comment><USER24> > Much of what is attributed to the rise of SaaS and "My Butt" is in fact a > direct consequence of Amazon's infrastructure.

Gotta love #cloudtobutt [https://chrome.google.com/webstore/detail/cloud-to- butt-plus...](https://chrome.google.com/webstore/detail/cloud-to-butt- plus/apmlngnhgbnjpajelfkmabhkfapgnoai)

</comment></comment><comment><USER25> As a small time developer, none of these tools is in my budget, I have no budget. So this list is useless to me.

Ok sure, I wasn't your target audience, that's fine. but the title doesn't suggest "Tools for active/established companies who have money to burn and needs to fill"

</comment><comment><USER26> List only has (the neat) Hirefire under Heroku tools, here's a list of 60 separate Heroku tools:

[https://www.expeditedssl.com/pages/the-hot-and-heavy-list- of...](https://www.expeditedssl.com/pages/the-hot-and-heavy-list-of-heroku- development-resources)

</comment><comment><USER27> This list does a great job of curating the most popular apps by category.

There's a ton of long-tail to SaaS these days. I've heard a lot of people use our app directory to discover some of them: [https://zapier.com/zapbook](https://zapier.com/zapbook)

</comment><comment><USER28> Great list. Created a PR for gosquared, datadog and rsync.net as I couldn't see them on there.

<comment><USER29> Thanks! You may be interested to know that we just announced Petabyte and larger file systems at 3 c/GB...

</comment></comment><comment><USER30> You guys seem to be missing Wercker. [http://wercker.com/](http://wercker.com/) is my favorite CI/CD. Its free while its in beta, has a great UI and has a simple but powerful configuration system

</comment><comment> johnx123-up [http://www.cssilize.com/](http://www.cssilize.com/) ($35) and [https://sudopay.com/](https://sudopay.com/) ($29) were discussed here before.

</comment><comment><USER31> I missing the web directories of yore that have such nice lists. Search engines only bring up a few relevant results and the rest are all keyword and link stuffed. Hope you take some pull requests or make this a wiki.

<comment><USER32> This is a very valid point, the other day I was looking for a wifi sniffer tool because I was getting terrible speeds over the last couple weeks and I wanted to ascertain the cause; there was nothing recently put out that compared more than 2 products, nearly all the blog posts were from 3-4 years ago, and the tools they compared were either bought out by cisco and the like or went out of business/ended support. really just having this type of list would be huge.

</comment></comment><comment><USER33> "ElasticSales is currently booked out for the rest of the year and therefore not able to accept any new clients at the moment."

Any alternative Sales as a Service recommendations?

<comment><USER21> I don't know much (anything?) about sales, but these guys look like an alternative: [http://www.generationsalesgroup.com/](http://www.generationsalesgroup.com/)

</comment></comment><comment><USER34> I would add Chargebee for recurring billing and Scout for server monitoring. Two polished, quality tools with solid teams behind them.

<comment><USER35> Thank you! Added it to the list. :)

</comment></comment><comment><USER36> [https://hakiri.io/](https://hakiri.io/) would be a nice tool to add to this list.

</comment><comment><USER37> all services - do people still pay for code? i.e. commercial libraries

or has open source finally killed that business model?

<comment><USER38> I wish there more open-source libs offering commercial options. I don't want to see libraries I depend on being abandoned. Might also want to have access to support. I'm sure there are many companies who would pay and still want the project to be open source and have an active community. Sidekiq is one example of this which seem to be going quite well. I think it is a problem that very important projects are being developed for fun after work (openssl anyone). While I do not want the "pay for all libs" like in the .net world I do hope to see more for-profit open source projects.

</comment></comment><comment><USER39> Github and Bitbucket "Issues"? I don't get that. Wonder if it's a typo.

<comment><USER40> Issue tracking? I have seen a private BitBucket repo with a public list of issues. BitBucket provides private repos for free, unlike Github, by the way.

</comment></comment><comment><USER41> another tools for Remote Collaboration

\- GoToMeeting [http://gotomeeting.com/](http://gotomeeting.com/)

\- Zoom.us [http://zoom.us/](http://zoom.us/)

</comment><comment><USER42> I work at a startup and we do CRM and we aren't on there!

<comment><USER43> Fork it, add your startup, and make a pull request :)

</comment></comment><comment><USER44> waffle.io is hyperdope on the Bug/Issue Tracking side too. Makes GH issues look like trello, and allows boards for multiple repos.

<comment><USER45> Cheers, just been looking for this kind of thing, seeing as my workflow is centered around GitHub.

</comment></comment><comment><USER46> >Continuous Integration/Code Quality

There's Strider.

<comment><USER47> Which is a great app, but a bit rough around the edges currently. Getting there though.</comment></comment>


Artists and writers whose works enter the public domain in 2018 - <AUTHOR> http://publicdomainreview.org/collections/class-of-2018 <comment><USER2> I've had this Slashdot comment bookmarked since 2009: [https://yro.slashdot.org/comments.pl?sid=1306857&cid=2873632...](https://yro.slashdot.org/comments.pl?sid=1306857&cid=28736323)

      In the USA Copyright lengths are very simple. Anything
      older than Mickey Mouse is public domain and everything
      else is still copyrighted.

Edit: Typo--fixed the year.

<comment><USER3> Honestly, I wish they'd just issue a special exception for Disney instead of screwing up the entire system because they don't want to appear nakedly corrupt.

<comment><USER4> My idea for Disney-appeasement without special exemptions: Let copyrights be extended for 14 years at a time, indefinitely, with the requirement of registration and a token filing fee. Anyone who cares can keep their copyright for as long as they want, if they just care enough to fill out a 1 page form. Anyone who doesn't care that much (or no heirs, or whatever), the copyright expires. Bonus side effect: for everything still in copyright, there is a database you can look up current contact info for licensing.

</comment></comment></comment><comment><USER5> Copyright schemes are almost always for the distributors, not the creators.

Let creators enjoy the full benefits of copyright by returning the ownership back to creator after 10 years.

After a decade, it is expected that creators will be able to command bigger cut as compensation for popular works and thus, inspire more creators to publicly deliver works due to the expectation of more appropriate and fair level of compensation from interested distributors. Otherwise, creators are discouraged from independent creation of works if it's believed that they will suffer perpetual loss of copyright ownership in exchange for a minuscule payment.

Similar scheme exists in Europe: [http://evolver.fm/2012/02/29/why-mastered- for-itunes-wont-de...](http://evolver.fm/2012/02/29/why-mastered-for-itunes- wont-defuse-a-copyright-time-bomb/)

As it stands, distributors can say "well, sell us the copyright for a dollar and we might give you a cut. No, not a licence, the copyright! At least you'll get a lot of exposure? Hehehe"

The current scheme has a lot of economic encouragement for indy creators to aim for live music, book signings, etc. Where creators need can be present and needed.

<comment><USER6> Hmm... Not sure what to think about this.

The real question is: What role should publishers/distributors have, and be allowed to have?

From a writer's standpoint, I think it was common _not_ to grant the publisher a perpetual license. The publisher would offer the author an advance and get exclusivity. If the book made enough money to cover that advance, the copyright would revert to the author (publisher may still have license to keep publishing, but not exclusivity).

In today's world, people can and do make big money self publishing on Amazon, so the hold publishers had has reduced. The argument makes less sense now than 20 years ago.

If you want to argue that self publishing is still a crap shoot compared to traditional publishers, then we have to recognize the great value publishers can bring to the author, and discuss why government intervention (i.e. law) is necessary in this case.

</comment></comment><comment><USER7> "Wondering what will enter the public domain through copyright expiration in the U.S.? Like last year, and the year before… Nothing"

(sigh)

<comment><USER8> What is expected to happen with US law in 2019 - another Disney extension?

<comment><USER9> I still don't understand why Disney has historically been so paranoid of Steamboat Willie entering the public domain anyway - Isn't Mickey protected well enough by trademark (which is perpetual so long as it's defended) that copyright on a 1928 cartoon is no longer instrumental in maintaining the proprietary protection of the character?

<comment><USER10> Don't forget that Disney really knows the power of public domain. Could you imagine if "Snow White" was allowed to enter the public domain? Anyone would be able to retell that story to their children without worrying about performing a copyrighted work in public without a licence!

<comment><USER11> Well they can do that anyway. Snow white is a fairy tale that's existed for hundreds of years. What's copyrighted specifically is the _disney_ version of it.

</comment></comment></comment></comment></comment><comment><USER12> I live in Italy. Can I get (legally) the works of Willa Cather and G. H. Hardy (the mathematician)? According to [https://en.wikipedia.org/wiki/2018_in_public_domain](https://en.wikipedia.org/wiki/2018_in_public_domain) they enter the public domain in 2018 as well.

</comment><comment><USER13> How exactly does CHE GUEVARA not make it into the picture list?

<comment><USER14> The most famous picture of him is presumably not out of copyright...

</comment></comment><comment><USER15> Now that Disney absorbed 20th Century Fox, is there a way to know what movies' copyright are controlled by them ?

</comment><comment><USER16> Hoping that Canada sticks with 50.

</comment><comment><USER17> shower thought: now that Disney owns Star Wars, it will never be public domain

</comment><comment><USER18> (I often drop this into PD threads so sorry if you've seen this before, but) the Standard Ebooks project[1] that I contribute to takes PD texts, updates them with better markup and a high quality house style, adds PD cover artwork, then releases them again back into the public domain. Although I'm outside the US the project is US-based, so I'd love to see a yearly update interval again there for both texts to produce and sources of cover art.

[1] [https://standardebooks.org/](https://standardebooks.org/)

<comment><USER19> Thanks for your project, I've downloaded some ebooks and it was great to read them. I would just like to let you that, at least on my ereader (sony prs t1), the book covers do not show at all. I looked at the epub source and I think I saw some svg in the cover, it was probably that.. It's an old ereader..

<comment><USER18> Maybe you could file a bug at [https://github.com/standardebooks/tools](https://github.com/standardebooks/tools) ? Alternatively, I had a similar problem with my Kobo and Calibre, which was messing with the file in some way even though I had all conversion options disabled. I just use Finder to copy them over now.

<comment><USER19> Done, thanks!

[https://github.com/standardebooks/tools/issues/63](https://github.com/standardebooks/tools/issues/63)

</comment></comment></comment></comment><comment><USER20> Is there a list of all the artists whose works won't but should, thanks to Disney, corrupt politicians, et al?

<comment><USER21> Yes, the Center for Study of the Public Domain at Duke Law School publishes exactly such a list every year.

Here's the one for 2017:

[https://law.duke.edu/cspd/publicdomainday/2017/pre-1976/](https://law.duke.edu/cspd/publicdomainday/2017/pre-1976/)

<comment><USER22> Once/if Dr. Seuss enters public domain you're going to see that everywhere. The entire world will turn into a Seuss wonderland. Or at least I can dream it will.

<comment><USER23> Nothing created after Mickey Mouse will ever enter the public domain in the United States.</comment></comment></comment></comment>


Engineyard Challenge Python Code - <AUTHOR> http://fpaste.org/paste/18766

<comment><USER2> I dont wish to be, umm, mean. But I know of at least 3 companies (ours included) that could run this in a few minutes.

this is my code (using mighty, our python based cluster service):

      import mighty

      word_generator = mighty.word_generator("wordlist",(mighty.APPEND_NUMERALS,5))
      phrase_generator = mighty.word_concentate(word_generator,' ')

      job = mighty.match_to_hash('PROVIDEDHASH',mighty.SHA1,phrase_generator.iterate_all)
      job.priority = mighty.CRITICAL
      mighty.submit_job(job)

Done. Takes about 5 minutes (I wont enter - it's not fair).

EDIT: added CRITICAL as the priority or it takes longer :)

EDIT: ok so the code is a bit the wrong side of the tracks. It wouldnt take long to refactor it :)

<comment><USER3> This isn't actually correct, is it? Assuming an average 6-letter word length, there are about 10^67 valid combinations that your iterate_all() can go through: (((2^6) * 1000) ^ 12) * (94 ^ 5) = 3.5 * 10^67

Since this is much larger than the total hash space (2^160 = 10^48), you can hope you'll get a collision after the number of tries equal to half of the hashspace (10^48 / 2). That means you'll have to generate 10^47 hashes. At 5 minutes of runtime, you'll have to generate 10^45 hashes per second.

Bottom line: if you can run this on 200,000 cores, you'll have to generate 10^40 hashes per second per core, and that seems impossible to me.

<comment><USER2> Weeell we have 20,023 computers (that fluctuates a tad). That's probably about 30,000 cores in the end.

I cant iterate the whole lot - but I can cover a substantial portion more of the keyspace in 5 mins than most could in the 30hrs. I bet 5 minutes will easily get me damn close :)

<comment><USER3> I'm seeing about 1 million hashes per second on a single core. So, you can do about 10^11 hashes per second on 30,000 cores. At that rate, it will only take you 10^48 years to cover the keyspace.

You won't even cover a fraction of a percent of the keyspace before the sun burns out.

</comment></comment></comment></comment><comment><USER4> Theoretically I'm having around 500 CPUs with 3gHz each and 2000GB RAM at my disposal. Maybe I should give it a try. Hint: University Cluster =)

Anyway thanks for the code examples, I'm pretty sure I can learn something from them.

<comment><USER2> 500 cores gives you no really higher chance of getting a good combination over someone with one PC.

Yes you get 500 times the attempts in the 30hr period. But if you run the figures it's something like 0.00000001% difference in the amount of keyspace you can cover :)

AKA just run it on a couple of PC's an hope you get lucky!

</comment></comment><comment><AUTHOR> Here's a first pass at a python implementation for the Engineyard Challenge ([http://www.engineyard.com/blog/2009/programming-contest- win-...](http://www.engineyard.com/blog/2009/programming-contest-win- iphone-3gs-2k-cloud-credit/)).

Note that it doesn't do any random chars at the end of the string and doesn't change the case of the words.

</comment><comment><USER5> Ahh, I see that you're generating an entirely new random string each iteration. Interesting.

I've done mine in Pike, which will be faster (though not as fast as C).

<http://github.com/jamesotron/HashChallenge/tree/master>

<comment><USER6> I've started mine in erlang. I'm going to run 10 dollars worth of ec2 time and see how far I get.

<comment><USER7> I've got mine in C. I probably won't run it, just wrote it for fun. Honestly, if you were thinking of spending a cent on this competition, I think you'd get a better ROI buying a SuperLOTTO ticket.

<comment><USER8> Lotto tickets aren't nearly as much fun as coding, so what's another 10 bucks.

Personally I'd run through a thousand bucks of computer time to play around with something or test a hunch before considering a lotto ticket.

Lotto tickets are taxes for people that are not good in mathematics.

<comment><USER9> or they just play for fun

<comment><USER10> Alas, being good in mathematics spoils the fun.

</comment></comment></comment></comment></comment></comment><comment><USER11> I'm getting about 250k sha1 hamming distance calculations per core per second, on an Intel(R) Xeon(R) CPU 3050 @ 2.13GHz (from /proc/cpuinfo). This is a full implementation... I can just drop in the word list and challenge phrase on game day.

Intel(R) Xeon(R) CPU 5148 @ 2.33GHz gives me 300k/sec.

Anyone else have a quick & dirty benchmark?

<comment><USER12> I'm getting more than 1M SHA1 + Hamming Distance calcs/core/sec on a Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, and I haven't really optimized beyond the obvious.

It's a brutally simple algorithm, really. XOR + bitcount, which only iterates for each 1 bit, so the lower the total hamming #, the faster it finds it.

It's in C, so everything works in unsigned long blocks. Compiled with -O3 it's:

real 0m0.968s

for 1M each on two forked processes, and 80 lines of code.

<comment><USER12> Oooog. Boy is my face red. I was recalculating the main SHA1 each time through the loop. A minor refactoring mistake with a major impact...

With the base string hash pulled out of the loop, it's looking more like 1.7M SHA1 + HD calcs/core/sec.

<comment><USER11> Yeah, mine's Perl, and running on a slower processor, so the difference feels about right.

Of course my main calculation is only one line:

$hamming_dist = unpack("%160b*", sha1($attempt_phrase) ^ $challenge_sha);

:)

</comment></comment></comment></comment><comment><USER5> I found this academic paper on finding collisions in SHA1, but unfortunately I'm not smart enough to figure out what it's telling me. [http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersio...](http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf)

</comment><comment><USER9> Is this supposed to run on Unladen Swallow? Or does the GIL not come into play here?

<comment><USER13> It uses the multiprocessing package, which is new in Python 2.6. From the docs:

 _The multiprocessing package offers both local and remote concurrency, effectively side-stepping the Global Interpreter Lock by using subprocesses instead of threads._ <http://docs.python.org/library/multiprocessing.html>

<comment><AUTHOR> multiprocessing is also available in 2.5, which is what I used, just do: easy_install multiprocessing

</comment></comment></comment><comment><USER14> and here's a probably slower, brute force perl variety: <http://gist.github.com/149173></comment>


2 is a code smell - <AUTHOR> http://tech.puredanger.com/2011/10/12/2-is-a-smell/

<comment><USER2> You might with more justification claim that varargs methods are a code smell, as they conflate the algebraic structure of the elements and the operations on them (for example that they form a semigroup with respect to the operation at hand) with the traversal over a collection of elements, thereby grossly violationg the principle of separation of concerns. After all, many interesting algebraic structures _are_ defined in terms of binary operators. If you separate operations between elements and traversal over collections, you can fold any operation over any traversable entity, with just #operations + #traversables functions, instead of #operations * #traversables functions. (You have a similar structure in languages from the APL family, where operators are all unary or binary, and traversal is specified by adverbs to the operators.)

This does of course not apply if you use a deliberately restricted language that has just one type of collection traversal, in that case you are better off with varargs, as n*1 < n+1.

</comment><comment><USER3> This is pretty much an instance of the good old "zero, one, infinity" rule.

[http://www.catb.org/jargon/html/Z/Zero-One-Infinity- Rule.htm...](http://www.catb.org/jargon/html/Z/Zero-One-Infinity-Rule.html)

<comment><USER4> This article restricts itself to a context where following "zero, one, infinity" results in simpler, more concise code. This is a good restriction. In general, following "zero, one, infinity" will often put you at odds with YAGNI.

<comment><AUTHOR> My experience with Clojure has been that sticking to N is so harmonious with the Clojure way that it is simpler and yields more flexible code.

If the code is _simpler_ then I don't see how YAGNI comes into play. Why would you do something that is both more complicated and less amenable to future needs?

<comment><USER4> By "in general" I meant outside the context the post was restricted to, i.e. Clojure. What you're saying is the same as what I said in the first part of my comment, up to "This is a good restriction."

</comment></comment></comment></comment><comment><USER5> Cache: [http://webcache.googleusercontent.com/search?q=cache%3Ahttp%...](http://webcache.googleusercontent.com/search?q=cache%3Ahttp%3A%2F%2Ftech.puredanger.com%2F2011%2F10%2F12%2F2-is- a-smell%2F&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en- US:official&client=firefox-a)

tl;dr Clojure is awesome. And use

        (defn add-vectors [& vs]
         (vec (apply map + vs)))

instead of

        (defn add-vectors [va vb]
         [(+ (first va) (first vb)) (+ (second va) (second vb))])

since in Clojure code that operates on 1 or N things is usually better than some other fixed value. (Like 2.)

</comment><comment><USER6> I try to be very pedantic about having the most terse, yet readable code possible in my application. This probably means that if, for now, I only need to know how to add two vectors, I will only include a function that adds two vectors and no more. I do realize there's hidden structure there waiting to be exposed, but programming is largely about elaborating the _useful_ structures. If the author's examples had been in Java instead of Clojure, a lot of us would've been complaining that he's over-designing.

I do think the author has a point, but to me the logical complexity progression for a piece of code is:

1\. Make it work in the "1" case.

2\. If necessary, make it work in the "2" case.

3\. If necessary, make it work in the "n" case (n variable).

I find this particularly useful for larger decisions: I can make this work right now if I add this tiny little wart? No problem. Another thing came up and a similar wart is required? Ok, I guess. A third? Time to find the structure that my code is telling me about and refactor to expose it.

<comment><USER7> The final (varargs) add-vectors function in the OP is clearly (at least to me) more terse and readable than the original (2 arg) one. I've only written a couple thousand lines of Clojure to date, but code like that already just looks right. The varargs version has less possibilities for errors; the 2 arg version allows for several permutations of first/second to be written incorrectly, or the wrong va/vb used.

</comment></comment><comment><USER8> What about sub-vectors? That smells like a 2 to me...

I'd rather call fold or foldr myself and KNOW how it handled more than 2 arguments. I'd rather do it for add-vectors too, just so it was consistent. You have to define primitives somewhere. Even if what you call elsewhere is some fluffy handle-everything function. At the very least, I wouldn't call it a smell.

<comment><USER9> I agree that it isn't necessarily a smell.

It really depends on the scope of the problem. Is this supposed to be a fully- functional addition function, or is this a throwaway helper function that the coder wrote because they were doing that specific operation many times, and they didn't want to type the entire thing out? If it's the first case, then it may be an issue. If it's the second, it's just poorly named, and not necessarily an issue at all.

</comment></comment><comment><USER10> If a co-worker told me that my function was "code smell" because it took 2 arguments, I would tell him that he needs more important things to worry about.

<comment><USER7> If a coworker told me the same thing, I'd ask, "Why?" If they gave me the explanation given in the article, I'd say, "Thank you, that's a nice little improvement. The code is simpler AND more general." Then, I'd go on working, a little bit better of a programmer for it. If I repeated this ritual a few hundred times, I might actually become a halfway-decent programmer. In this field, details matter.

<comment><USER11> There's a difference between seeing that something can be generalized, optimized, or improved and spending the time to do it.

Knowing that difference and applying judgement is a major differentiator between inexperienced programmers and experienced ones. That, I think, is what heyrhett was getting at.

<comment><USER7> I don't get it. In the case of the vector-add function, once you've happened to notice the more general solution, implementing it will take a couple of minutes. It's not comparable to an optimization, which would normally increase the risk of code errors -- it is a simplification, which would decrease the risk of code errors.

Two minutes to make a minor simplification and learn a generally good way of approaching things with the tool at hand (clojure)? Count me in.

</comment></comment></comment></comment><comment><USER12> Reminds me of zip, zip3, zip4, etc. in Haskell.

<comment><USER13> Erlang as well, though they don't go to 4 IIRC. A pragmatic compromise of providing a simpler interface for common use cases.

<comment><USER14> Haskell actually goes all the way up to zip7. A generalised zipn function is quite complicated to write in Haskell, due to the type system. Here's a blog post about it: [http://paczesiowa.blogspot.com/2010/03/generalized- zipwithn....](http://paczesiowa.blogspot.com/2010/03/generalized- zipwithn.html)

</comment></comment></comment><comment><USER15> K handles the general case:

        1 1 1 + 2 2 2
      3 3 3

        (1 1 1; 2 2 2; 3 3 3) + (4 4 4; 5 5 5; 6 6 6)
      (5 5 5
       7 7 7
       9 9 9)

<comment><USER16> As does R :)

        > c(1, 1, 1) + c(2, 2, 2)
        [1] 3 3 3
        > matrix(c(1, 1, 1, 2, 2, 2, 3, 3, 3),
        +        ncol = 3, byrow = TRUE) +
        + matrix(c(4, 4, 4, 5, 5, 5, 6, 6, 6),
        +        ncol = 3, byrow = TRUE)
             [,1] [,2] [,3]
        [1,]    5    5    5
        [2,]    7    7    7
        [3,]    9    9    9

Not quite so concise and elegant but it's pretty straightforward stuff for most R users.

</comment></comment><comment><USER17> Since we've already descended into anecdotal territory, lemme drop an anecdote. I had a dot-product function which turned out to be a hotspot in some numerical code. The original function looked something like:

        def dot(v1, v2):
            return sum(i * j for i, j in zip(v1, v2))

Very functional, very pretty, very straightforward. But it was slow, both in CPython and PyPy. A bit of bytecode analysis and profiling later, we realized that unrolling would be faster by several orders of magnitude. So I checked this in:

        def dot2(u, v):
            return u[0] * v[0] + u[1] * v[1]
        def dot3(u, v):
            return u[0] * v[0] + u[1] * v[1] + u[2] * v[2]

And the bottleneck went away. From the Zen of Python: "Practicality beats purity."

<comment><AUTHOR> If you spend any time in the Clojure community, I think you'll come to an appreciation that practicality and performance are key principles of its design. The goal is to obtain both high levels of abstraction and performance.

<comment><USER18> But performance means different things to different people.

If you're writing code where dot products are not something you do a lot of, then keeping a clean, idiomatic functional implementation is probably fine.

If you're writing code where dot products happen _a lot_ , such as on real- time three-dimensional games (which happens to by my oeuvre), then the performance increase of having specific, unrolled implementations is huge.

<comment><USER5> It depends on what the language and compiler do for you, the elegant form may actually be faster than your supposed uglier-but-faster optimization. As always, time-test before and (if you've decided it's necessary) after optimizing. I remember reading a warning somewhere in the Clojure docs about how using (get x idx) is much faster than (nth x idx), I don't remember why though.

<comment><USER18> This is of course true; ALWAYS profile the code before and after any optimizations, it is quite common for things not to act the way you'd expect (either because of the hardware, the compiler, or even other bits of code you're not aware of, which perhaps relies on certain assumptions).</comment></comment></comment></comment></comment>


The future of computers: 3D chip stacking - <AUTHOR> http://www.extremetech.com/computing/119843-the-future-of-computers-3d-chip-stacking

<comment><USER2> Xilinx's Vertex 7 FPGA uses a stacked design for the interconnects. The FPGA logic is all 28nm, but sitting under it is a completely passive 65nm interconnect layer.

[http://www.xilinx.com/products/technology/stacked-silicon- in...](http://www.xilinx.com/products/technology/stacked-silicon- interconnect/index.htm)

</comment><comment><USER3> > _"chip stacking obviously works in synergy with Intel's 3D FinFETs — though > curiously there is no sign of TSV on Intel's roadmap"_

Wouldn't chip stacking exacerbate heat dissipation issues? It seems to me that desktop chips would stand to gain far less from this approach, so why should it be surprising that Intel isn't rushing into it?

<comment><USER4> I wonder if you could etch channels for liquid coolant directly into every 3rd layer or so...

<comment><USER5> [http://www.eetimes.com/electronics-news/4077160/IBM-GIT- demo...](http://www.eetimes.com/electronics-news/4077160/IBM-GIT-demo-3D-die- with-microchannel-cooling)

</comment></comment></comment><comment><USER6> We know this for a long time. Few years down the road in sub 10nm, we will reach the era where we cant shrink transistor endlessly. The problem with chip stacking on die is how to get rid of the heat passing through each layer.

Stacking in itself has proven to be feasible by the Memory Cube. Where Heat isn't much of a concern.

<comment><USER7> I expect that what we'll see is a top layers of general purpose processing on top next to the heat sinks, then lower power layers further down, like maybe a layer of L3 cache then a stack of main memory. Probably also a lot of dark silicon which is only lit up for special tasks, like media encoding or encryption.

</comment></comment><comment><USER8> Wasn't that one of the innovations of Apple's A4 chip? Stacking the RAM chips on top of the CPU core inside the same package?

<comment><USER9> The A4 does use this technology, but Apple certainly did not invent it (though I wouldn't be surprised if they claimed so). It has been used in cell phones for years, and only recently others are starting to adopt it, and extend it to place two chips side by side on a Si substrate within a single package. The reasons are purely economical. In the past, much benefit can be had just by shrinking the transistor size. At the current feature sizes, though, physics is not helping anymore and there is very little benefit in terms of raw transistor and wire speeds, and power. So chip makers need to find more ways to extend Moore's law a few more years. FinFETs and stacked chips are just such ways.

<comment><USER9> I'm curious why my comment was downvoted? Just for future reference.

<comment><USER10> Probably the rather off-topic _though I wouldn't be surprised if they claimed so_ part.

<comment><USER9> Ah. Makes sense. Thanks.

</comment></comment></comment></comment></comment><comment><USER11> Hasn't chip stacking been the future of computers for 10 years? Especially of SoC solutions.</comment>


Ask HN: Is this for real? I can't tell if I'm being trolled at - <AUTHOR> http://www.newscientist.com/article/dn21334-kopimism-the-worlds-newest-religion-explained.html

<comment><USER2> 1\. Would donations be tax-exempt?

2\. Would these people be entitled to privacy when they perform their religious activities?

3\. Would they be able to block courts the publication of their secret rites?

4\. Would they be allowed to freely express their religious views, and live their holy life?

</comment><comment><USER3> It's true yes. But does seem trollish. Weird world out there</comment>


5 lessons I learned from starting a business in Japan - <AUTHOR> Hey everyone, Not too long ago I quit my full-time job to start some small businesses in Japan. It's been an amazing adventure so far with plenty of ups and downs. I recently wrote a blog post about my experiences which you might find interesting:
https://www.innerspeakerconsulting.com/5-lessons-start-business-japan
Let me know if you guys have any feedback or similar experiences.
Thanks! <comment><USER2> Thanks for sharing your experience. I've been to Japan a few times and absolutely love it. I hope one day, I'll get the opportunity to live and run my business from there. Do you an email where I can reach out? I'd love to learn more about your business.

My only experience is as a tourist observing the workers and it does look as what you described with longer hours and great importance placed on work but that companies will also reward you with loyalty. I've also heard that hiearchy and respect is important. I feel like there could be certain values that could be extracted as part of Western society - we recently had a retailer reporting bankruptcy and being unable to afford the pensions/severances of employees but somehow the management team was retained and were provided with decent bonuses. Something seems broken there.

<comment><AUTHOR> Thanks for reading and that's great you are interested in living and setting up your business here. You can email me from the contact box or from the address on this link:

[https://www.innerspeakerconsulting.com/contact](https://www.innerspeakerconsulting.com/contact)

Yes the long hours, hierarchy and respect are all true. I used to work for a Japanese company and some of the hours were brutal but it was great experience to be fair. Like you say, Western countries could learn a fair bit from Japanese values (respect, being in control of emotions, integrity etc).

It's certainly a very interesting place to live and work and I highly recommend coming over if you get the chance. Feel free to reach out via mail if you have further questions about living and working in Japan. Also check my blog as I'll be posting articles about my experiences over here which might be interesting for you.

Thanks for reading!

</comment></comment><comment><USER3> How is the startup scene now in Japan 2017?

<comment><AUTHOR> Yeah I think the start up landscape is slowly changing in Japan with more and more people starting small businesses and trying to make it on their own.

They've recently made it easier to create a company (lots of capital was required in the past but not anymore) and it's actually really easy to start a sole proprietor business. A lot of entrepreneurs over here now are setting us as a sole proprietor as it's really easy to get going and also open a bank account under the business name.

Also a lot of events happening in the start up scene especially in Tokyo. It's always good meeting with other entrepreneurs, hearing about their experiences and of course expanding your network.

Thanks for reading the blog and be sure to check back as I'll have some new content up there soon.</comment></comment>


It's difficult to innovate in Colombia, and the government is messing up. - <AUTHOR> http://torrenegra.com/post/115127554528/its-difficult-to-innovate-in-colombia-especially

<comment><USER2> Saving you a click, the first bullet point is they're going after uber.</comment>


Heart in a Box - <AUTHOR> http://sci-fo.com/heart-in-a-box/ <comment><USER2> The source page: [http://www.transmedics.com/wt/page/ocsheartintro_med](http://www.transmedics.com/wt/page/ocsheartintro_med)</comment>


U.S. Navy Launches a Drone from a Submerged Submarine - <AUTHOR> http://www.defenseone.com/technology/2013/12/navy-launches-drone-submerged-submarine/75026/ <comment><USER2> "This six-year effort represents the best in collaboration of a Navy laboratory and industry to produce a technology that meets the needs of the special operations community"

And the endless defense spending continues.

[http://nation.time.com/2012/09/25/comparing-defense- budgets-...](http://nation.time.com/2012/09/25/comparing-defense-budgets- apples-to-apples/)

</comment><comment><USER3> If sub launched drones can eventually engage in precision bombstrikes and air- superiority operations, this could presage another shift in naval warfare.

<comment><USER4> It used parts of the Tomahawk system, the precision bombing was largely covered. Drones are supposed to be cheap. Billion dollar delivery platforms don't really align with that. This is the US Navy trying to keep a weapon system designed for the cold war. An attack submarine that isn't stalking boomers is a hole in the water into which money is poured.

<comment><USER5> Why are drones supposed to be cheap?

<comment><USER6> It's one of their main competitive advantages. If a drone launch starts costing millions of dollars, the benefit it has over a traditional aircraft fly-over starts to diminish.

<comment><USER5> I don't see traditional aircraft taking off from a submerged submarine any time soon. That would seem to be an alternative advantage to offset the cost.

<comment><USER7> actually, the Japanese already invented that in WWII - [http://www.nbcnews.com/science/sunken-japanese-wwii- submarin...](http://www.nbcnews.com/science/sunken-japanese-wwii-submarine- found-coast-hawaii-2D11701154)

<comment><USER8> Not true. You forgot the submerged part.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Yeah, that's cool and all, but can it deliver a package in 30 minutes or less?

</comment><comment><USER10> NRL does amazing work. Their people are highly qualified scientists who get paid peanuts.

</comment><comment><USER11> How do they get it back?

<comment><USER12> For the test they landed at a nearby base. They don't address how an operational weapon system would work in the article.

I'd propose to wipe their memories and land them at a reasonably friendly if not secure location. (Order is important.) barring a safe landing spot, crash them as best you can. War is expensive. The last number I saw for a C5 was $5000/hour, and that was a long time ago.

</comment></comment><comment><USER13> This brings to mind the idea of an amphibious quadcopter. That's not what this is, but that's what I thought of.

I wonder if a waterproof quadcopter would navigate well underwater. It seems like it could be an interesting environment to experiment with advanced acrobatic maneuvers at lower speeds.

</comment><comment><USER14> why Navy is building submarine launchable drones instead of building submarine drones?

<comment><USER15> Firstly, how do you know they aren't?

Secondly, a drone sub has vastly different mission capabilities than a drone aircraft.</comment></comment>


Ask HN: I made a JavaScript library called NippleJS and people are getting angry - <AUTHOR> It all started with an issue on my library, https://github.com/yoannmoinet/nipplejs/issues/80 which is cool, because we can discuss about the issue and the point raised was fair IMHO.
But it all went to shit pretty quickly, so I locked the thread and decided not to change the name.
Now the guy is just insulting me on twitter.
https://twitter.com/lazerwalker/status/1054658757228195840 https://twitter.com/lazerwalker/status/1054768005249462272
I still think NippleJS is a funny and innocent name.
Everybody has nipples, so it's pretty inclusive too.
I don't know anymore... is it? I'm really looking for advices on how to handle this before it goes sideways.
Sorry for the drama. <comment><USER2> Yeah just ignore. His initial tweet ('precious white dudes...') is borderline racist even. Reading the github issue, you handled things well even if others didn't, regardless of the merits of renaming the library or not.

<comment><USER3> Not sure how colour/race and gender come into the issue at all.

The fact that he's bought them into the argument to emphasise his point shows his point has little merit.

</comment></comment><comment><USER4> Woman here. I don't find the name offensive or foul or exclusionary, though I don't find it especially humorous either and could understand why it might make some people uncomfortable. With that in mind, I'd describe it as a bit crass; and in a career context, unprofessional. Not worth getting into a flame war over, either way.

</comment><comment><USER5> Here's an article of a developer who went through something similar: [http://findingscience.com/ruby/2014/11/17/why-im- renaming-a-...](http://findingscience.com/ruby/2014/11/17/why-im-renaming-a- gem.html)

The bit that stands out to me is an e-mail he received from a female engineer:

> While the idealist in me would love to aim for a world where sex was treated > more equally and openly, the unfortunate reality of tech is that it has been > a haven for misogynistic men and the environment is heavily male dominated. > While in an ideal world the name SexMachine would be something that both > genders could joke about, the reality is that the tech community is not > ready or capable of that today.

<comment><USER6> From the comments on that thread:

> RapeLiberalSluts • 4 years ago

> For your own mental health, stop believing this nonsense about misogyny. > Your peers are brainwashing you.

That's even 4 years ago when it wasn't _quite_ as popular to be so edgy/hateful outside of certain communities.

<comment><USER4> Edgy?

</comment></comment></comment><comment><USER7> > > [https://twitter.com/lazerwalker/status/1054768005249462272](https://twitter.com/lazerwalker/status/1054768005249462272)

One of the tweets in response to this one:

> Thanks for doing this. It is especially tone deaf at this moment in time > when trans rights are under direct attack in the US for a group of cis men > to feel entitled in how they talk about other bodies.

What the hell does this have to do with trans people? "entitled in how they talk about other bodies"? What?

It's a nipple. Men have nipples. Women have nipples. Everyone has nipples. My cat has nipples. This has nothing to do with trans people.

 _At worst_ , the name is unprofessional, but definitely not worth changing.

</comment><comment><USER8> > _I still think NippleJS is a funny and innocent name. Everybody has nipples, > so it 's pretty inclusive too._

I agree. The entire situation is absurd. The advice to ignore the naysayer(s) seems to be the correct course of action.

That said, the original issue has some comedy gems in it which I feel are worth mentioning here:

[https://github.com/yoannmoinet/nipplejs/issues/80#issuecomme...](https://github.com/yoannmoinet/nipplejs/issues/80#issuecomment-416608625)

and in a later post (different author):

 _" And if nipples really make you uncomfortable, maybe you should visit a professional? Today you can't run away from nipples, they are everywhere and you will just be more and more uncomfortable."_

</comment><comment><USER9> That Twitter guy should be ignored, some people just want to find something to be outraged about.

</comment><comment><USER10> Just ignore him. It's him who wants to create the drama.

<comment><AUTHOR> Thanks! I'll do just that then.

</comment></comment><comment><USER11> Haha that's hilarious. Don't worry about it, internet is full of dumb people. The only way to never offend anybody is to never do anything and have no personality whatsoever.

Keep the name, don't let them police all the delightful quirkiness out of the world.

</comment><comment><USER12> I'm sorry you have to deal with this..

I find it very amusing that he says "It feels like a microcosm of politics in 2018"

I agree with him there, if he means people finding reason to be offended over anything..

He was scared of mentioning using your library to his colleagues, but has no worries shouting about it to the world on twitter?

It makes me sad that people go out of their way to rob the harmless small joys of others.

</comment><comment><USER13> It did take an unfortunate turn.

Good luck with the library, whatever you decide.

In a curiously pertinent piece of timing, you are not the only one rejecting calls to rename:

[https://mobile.twitter.com/hardmaru/status/10548722327222231...](https://mobile.twitter.com/hardmaru/status/1054872232722223104)

</comment><comment><USER14> Baby bottles have nipples.

Also, those little nuts in a bicycle wheel rim that hold the spokes in place and apply tension to them? They are called spoke nipples.

This numbnut that is harassing you will have a heart attack if he ever brings a bike with a broken spoke into a shop.

Some sort of short connector in plumbing is called a nipple, also.

</comment><comment><USER15> Simple. It is called "compromise". Understand their concerns (they are valid IMO) and offer to change the logo but say you will keep the name for discoverability.

Using for example a baby bottle as your logo would be less offensive. IMO.

<comment><AUTHOR> That's actually a good idea. I'll figure something out.

With the current logo I really wanted to integrate the actual output of the library, and it was fitting the name quite well, I thought.

</comment></comment><comment><USER16> I don't think of it as offensive. It's an anatomy part, why would someone be offended by their body? Imho, don't change it, because there's no reason for such an action

</comment><comment><USER17> Don't change the name. It's awesome. Every time a request like that is honor, the world becomes a little bit more riddicolous place.

</comment><comment><USER18> NippleJS is a totally cool name! Guy is insecure, not your problem. Move on, is what I'd recommend.

</comment><comment><USER19> He's trying to bully you into changing the name, instead of accepting the communities decision.

</comment><comment><USER20> I hate how politics keeps creeping in software industry. A few weeks ago there was a heated debate on Twitter over changing "SLAVE" to "REPLICA" in Redis, and sadly the maintainer gave in to the pressure.

</comment><comment><USER21> y, sounds like it worked out, I think you handled it perfectly.

Nice work btw, I'll have to find a use for this.

<comment><AUTHOR> Thank you, it's old code, but it works :D

mostly.

</comment></comment><comment><USER22> Let the people who are complaining maintain a rebranded fork, then we'll see if they really care or not.

</comment><comment><USER23> such a cool name

</comment><comment><USER24> just block the commies

</comment><comment><USER3> And the customary xkcd:

[https://xkcd.com/243/](https://xkcd.com/243/)

(nsfw language)

</comment><comment><USER25> Giving you a star just for the name!

</comment><comment><USER26> " _A virtual joystick for touch capable interfaces._ "

Tune out the Twitter peasants. The name is _perfect_.</comment>


Google is helping to power a US immigration cloud project, new documents show - <AUTHOR> https://www.theverge.com/2019/8/29/20838201/google-cloud-immigration-uscis-protests <comment><USER2> If you want to listen to this article in audio, here's a link where you can do that: [https://www.listle.io/#/article/1904006635](https://www.listle.io/#/article/1904006635)</comment>


Colorblind Users Push Technology Designers to Use Signals Beyond Color - <AUTHOR> https://www.wsj.com/articles/colorblind-users-push-technology-designers-to-use-signals-beyond-color-11591351201 <comment><USER2> I wonder if colorblind users would be better served by browser-based adjustments, so every page they encounter on the web is colorblind-user- friendly.</comment>