static_typed

Luckily for Uber, the protesters only protest a maximum of thirty five hours per week, Fuck off entirely for the month of August, and won't travel more than two miles from one of the dirty bistros to protest in the first place.

If I was Uber, I would pay cash to all the homeless people to take slow long rides in the normal cabs to block them up.

Or if you are actually going to perform an upgrade, consider a move to one of the more mature, stable, secure frameworks under Python, Perl or PHP.

Less Rails - less fails. Simple!

Citations or evidence required for your claims that Twatter is absolutely one of the best around.

We owe Twatter a big thanks for showing Rails on Fails doesn't scale (via so many fail whales), and so guided many a new startup to explore Scala, Erlang, Python, C++11 - basically things with a good chance to help not hinder your startup.

Thanks Twatter!

I can see the conversations now: "..and they trust you with their wife data?"

"Dumbfucks".

The fact is COBOL is still used, and useful today, all these decades later. I wonder what the sentiment about Ruby on Fails will be in thirty years time, and I don't think we will still be using it.

RESTful services still work in those situations where they are correctly applied. Maybe what has happened is some of the less mature and more shrill developers have stepped back from their war on any Web service that doesn't fit their dogmatic rest-tard view of the world. There are plenty of valid XML-RPC based services that continue to run well despite the whining that someone somewhere did not yet have a ruby gem to connect their ruby on fails site to it and that it was simply unacceptable - and so complain on twatter they must!

So in short - no, REST works, use it in the right places, and remember kids - not every Web service or endpoint has to expose a REST based interface.

Boss has a problem, so he hires an MBA, now he has 300 problems, and he got fired as well.

Database administration - is not a fire and forget task. It dismays me greatly that so many developers do not see beyond the code in their IDE, and think they can just bring a DBA for a few days, and all will be well. It may also surprise some developers just how much return on investment a good DBA can bring - they can and do learn about the business, the data, the processes and can then help get the best from the database as a result of that knowledge. But they can also serve as an SME on the database engine technology, perhaps pointing out where it is not being used in the right or optimal way. The biggest gains in performance generally come when they help a team of developers who were treating the database as a dumb data store and not making any use of the features offered.

The DBA is not dead! They just look and smell that way!

But in all seriousness, if your app uses a database, you are incompetent not to employ an expert to help with the database, whether advising on the query plan of those non-performant queries, or what is the best setup for the current stage of the business and app, they are very useful.

My old Nokia phones had a flashlight mode built in, very quick to activate and use, not as a separate app. Even if it does need to be an app on Android, at least include it in the base or core, as it is such a popular and useful thing to have.

The key takeaway in the benchmarks seem is that Go is significantly slower than the rest, much much slower.

Apart from the regular 30-sec interval postings on HN extolling the virtues of Go, it seems to me, people should rekindle an interest, or discover a new interest in D, C or Erlang where performance is a consideration, and maybe Go where a need to feel like part of the post-Ruby crowd.

Sure - when restaurants take on a new cook or chef, they may well ask him to produce a dish or two, but none of those dishes will be sold to paying customers outside. The staff/management will check them, try them, review them, but will not be selling them to the customers outside.

Really? I am required to have an account with Github, to prove something?

In the real world, some of us work on highly proprietary code bases, where putting any code up online could expose the risk of future lawsuits or prosecutions, certainly this has already happened to individuals in the industry.

Thankfully in the real world there are some sensible and mature interviewers who are able to look beyond the heinous crime of not having a Github presence.

Firstly, I think they wanted to 'assess' not 'asses', well at least I hope so (spell checking is not optional; even on a blog).

Now, I agree with the blog post: if you want me to code at interview it has to be open source, pseudocode or a toy library. Not your production app. I don't want to see you proprietary code till I am hired in case some moron on your staff later goes on a spree suing people on an open source project where the code looks 'similar' to what they may have seen in your code-for-free cheapskate interview process.

Well, Martin should be happy Scala is getting discussed, even if he doesn't agree all that is being said. There are plenty of new and old languages that never get a mention on HN, let alone grace the front page.

That said, he should probably not take any criticism personally. They are discussing Scala the language, not Martin the creator of that language.

The other day, my colleague received a wolf whistle, and turned around to remonstrate with the guy behind her.

He then pointed out, it was actually the woman next to him who had actually whistled. She smiled and replied it was her, and she didn't mean any harm, she just thought my colleague was 'cute'.

It's not really a problem about peacocks, or feminists, it is simply a problem about respect, in each we treat others and how in turn we would expect others to treat us.

Are all the articles on Vulture Beat like this? "Someone said..", "Someone else said...", "This one time at band-camp..."

Wow - just read a more recent comment from Ben here: https://github.com/joyent/libuv/pull/1015#issuecomment-29568...

The sad part of it all this: "I'm probably going to step back from libuv and node.js core development. I do it more out a sense of duty than anything else. If this is what I have to deal with, then I'd just as rather do something else. "

Joyent - well done - you have shown potential customers to now be wary of becoming too entangled in your products or ecospace, lest they get bitten by the effects of your blog space comments and the ramifications of these.

Joyent - well done - you have shown open source developers you would fire them (how?) before you would establish the facts. Developers - be wary here before you selflessly give your time and effort to these projects.

The lynch mob on the internet - shame on you all. There was no issue here for you to shout and scream about, let alone bring out your virtual portable gallows. What ever happened to benefit of the doubt? For shame. The sad part is that there are real gender issues out there, but instead of spending the time and effort on those, where they do actually exist, you spent it on here, on this, which was more a poor communication at best, a minor issue of lack of respect amongst fellow developers at a stretch, but not, and never a sexism or gender issue.

The commit itself, and the events around that were already discussed on another thread, but about this blog posting specifically - this is a little extreme.

I would have hoped at this point, an official posting, on the corporate pages would have a more sensible and calming approach. I guess not.

All in all, no one comes out of this looking well.

1. However well intentioned, this sort of pedantry (the change from 'him' to 'them') just alienates efforts to make things more inclusive, rather than actually helping .

2. Reverting the change appears to be fairly petty. By all means talk to the author of the commit about it, but commit tennis just makes the project look a little immature.

3. Is libuv really now at the point where it is 100% kitchen-sink-included-feature complete, mathematically and empirically tested bug proof, and with code so clean it brings a tear to a developer's eye? If not, then why are you all wasting time on such petty commits, and not on actually, you know, improving the code base.

My boss always puts herself in frame as the 'user' in her comments, documents and emails, so all examples are framed with 'her' in mind. Does anyone mind? Does anyone start making changes to 'them'? No, not really. I guess there are more important things to do.

Hiring primer:

1. Hire based on ability, experience, and if the candidate has a good attitude and approach. 2. Hire based on company and team fit - this does not mean six of the exact same profile (i.e 3.25 years J2SE developer from a tech background), but instead look to build a well-rounded team with a variety of backgrounds and approaches to tackling the project. But they should all be able to sing the same song, even if in different keys, it is no good where each sings a good but unique and competing song. 3. Do not discriminate, especially in a so-called "positive" way. It is just bad policy. 4. If you say your company will provide training, make sure you do. 5. Avoid bell-curve based staff evaluation schemes. 6. No point number six, the first five should be enough!

From the blog, it has the following piece of code:

def outcome(hiring_procedure): allowable_candidates = [c for c in all_candidates if hiring_procedure(c)] candidate_values = [risk_profile(value(c)) for c in allowable_candidates] return candidate_values.sum() / len(candidate_values)

What happens if we get to the return line, with an empty candidate_values? ZeroDivisionError ?

The French farmers would not stand for this, they will probably be out burning truck loads of seeds, having first forced the truck to stop via roadblock.

My wife got to test-read your HN reply for work. She's not exactly a power viewer, but found your limited humour and restrictive mindset incredibly frustrating.

Her conclusion was that comments should state exactly what the user wants to state, either because they are incredibly well stated withing specific constraints (see other comments on this page), or because they simply do as they're told (see other comments on this page).

The comment is neither, it basically does what you think it should do, without any of the depth and sophistication of others' opinionated experience. It may hit the sweet spot for some, but it seems to me to be a very small niche.

The end result was that my wife was ready to delete the thing out the browser window, and handed it over to me with the words "see how long you last before you want to smash it".

As the site now says "Error establishing a database connection " maybe the coding was ended a little too early?

Some of us do care. We care about paying more for overpriced RAM upfront because we cannot upgrade later. We care that we have to leave our laptop with Apple for long periods of time to do repairs of any kind (do they repair? Probably replace). We also care about the environment. Shiny is nice, but shiny comes at a cost way above the dollar sales ticket.

Still. Some don't care.

Just when you thought they could not make their hardware any more repair unfriendly, they find a way.

I think iFixit needs to start having a minus score on the repairability score - this can earn a one, it surely has to lose that for extra soldered and glued parts alone.

In business, the simple way to get rid of problem customers and maybe to avoid taking them on in the first place, is to ensure you have per customer pricing and agreements. For example, client A is a good customer, so a support ticket for them costs just $150, but client B is a right royal pain in the backside and so their support ticket cost is $550. Similar scaling for development etc. Keep raising prices till they go or stop calling so much, as required.

Fine, go read the bug trackers for them. Your point was? Oh, probably better to spend the time patching your desktop and servers given the massive drive through holes Java has left there.