karlmdavis

This is Sonatype's response to the earlier "How to take over the computer of any Java (or Clojure or Scala) developer" concerns and discussion [1]. I'm very relieved they've fixed the big problem there, as having so much infrastructure reliant on plain HTTP was a giant hack waiting to happen.

[1] https://news.ycombinator.com/item?id=8099713

For me that's almost all fields: I try to make just about everything immutable by default. Makes reasoning about concurrency much simpler.

His post from today, "The Diving Save" [1], is also quite relevant to this: how do you keep someone, once they've started to check out?

[1] http://randsinrepose.com/archives/the-diving-save/

I did just that when I switched my server from ESXi (which used the same formats). For me, the vmware2libvirt command from Ubuntu's virt-goodies package did the trick.

I documented my transition in some of the sections on this page: https://justdavis.com/karl/it/davis/servers/eddings/vms.html

Wait... you're saying he's arrogant because he's taken a job that he enjoys primarily because of the humbling perspective it offers?

Isn't that almost exactly what investors are doing, but on a smaller scale? Both are giving up cash-in-hand for that lottery ticket.

Also Humble Bundle.

The latest Spring release supports a Groovy DSL for configuration: http://docs.spring.io/spring/docs/4.0.0.RELEASE/spring-frame...

Think about the largest, most complex codebase you've ever worked on. Then, remove any architecture documentation, wikis, etc. used to document how it's all tied together. Then, remove the build scripts and any lib folders.

Imagine how much fun it'd be trying to get that to build. Multiply the terror that inspires by (at least) 100x.

>Everyone hates it ...

I don't; that's a bit of a sweeping generalization. I happen to enjoy writing webapps in JAX-RS and Wicket, and I know a number of folks who enjoy writing them in other frameworks.

Using that logic, how could you possibly take the book itself seriously, since the publisher isn't just giving it away for free?

> It would depend on the amount of "bottom feeders". That's a bad way to define it though, "non-productives" might be better, since it would include pensioners, children, students (including people who go back to studying if this program is introduced, but are older than 0-24 years), really ill people, ... mostly not people I'd define as bottom feeders.

You're absolutely right, thanks for the correction.

He didn't say to always be 'taking' new jobs, he said to always be 'looking'. And I'm guessing he's not exactly referring to "sending out resumes" or "going to every interview you possibly can."

Don't this:

> The aggregate effect of free money is what will determine the outcome.

And this:

> Not what exceptional individuals might achieve with it, but what a lazy drunkard would achieve with it matters)

Contradict each other? The "aggregate effect" = "lazy drunkards" + the effect of "exceptional individuals" + the effect of everyone else. So it really isn't the lazy drunkards that matter; it's the overall effect that does. If, on average, it improves society then isn't that a win?

Very often, when talking about basic incomes and similar programs, people seem to say things like "twice as many people will take advantage of the system and be lazy." To me, that's not a sufficient criticism: it all depends on the percentages. If a program increases the percentage of bottom feeders from 1% to 2%, say, but also doubles the quality of life of everyone else, that would be a huge win to me. Obviously, the numbers I chose in my example are probably unrealistic, which just further illustrates how important it is to actually determine what the numbers are/will be.

Have you come across JaCoCo [1]? It does its instrumentation via a JVM agent at runtime-- no need to recompile your code just to test for coverage.

I've been using it for the last year or two and love it! One of my favorite features is how easy it is to generate separate coverage information for unit tests vs. integration tests. Sonar provides excellent support for it, as well.

[1] http://www.eclemma.org/jacoco/trunk/doc/

> I've never written a linked list. Guilty as charged. Java has a LinkedList class and I've never bothered to look at the implementation nor have I ever been curious enough to (re)write one from scratch.

Good! You're right: the JDK's implementation is perfectly acceptable, and you'd be crazy to write your own. I certainly haven't, either.

But if you have any CS education, I'll bet you know what a linked list is at a high level. And I can probably verbally walk you through turning that into a "spec" that's good enough for a basic whiteboard implementation of one that supports a couple of basic operations. It's (hopefully) just another fizzbuzz: a simple problem to demonstrate that you can code something/anything. The overwhelming majority of applicants can't.

So, I understand and am incredibly sympathetic to the stress problem some folks have. I also occasionally freeze up when put on the spot, though I fortunately tend to recover after a minute or so of verbal stumbling.

That said, hiring quality engineers is HARD, and often ends up coming down to a numbers game. If I've got 100 applicants to go through and know (from past experience) that over 80% of them couldn't code their way out of a wet paper bag, then I need short, deterministic interview techniques that will identify those candidates who are actually worth my time. Thus: fizzbuzz. I've met lots of folks who talk a great game, have all kinds of experience listed on their resume, and yet somehow can't write up a linked list or fizzbuzz solution in any language.

So, I accept that there will be some false negatives in order to more quickly narrow the focus down to those few rare folks that can actually code. It sucks: it isn't entirely fair to folks who struggle with stress/nerves, but I need a 5-15 minute litmus test that can be done remotely and I haven't found anything else more effective.

Short of wasting everyone's time with take-home projects (which I often employ in later stages of the interview process), what other options are out there?

Hey wait, what're you on about? I'm Karl, and I AM in New York City. Am I being voted out?

Well, I've got two main use cases for configuration management tools: 1) managing CI build farms, and 2) managing my home network.

Both of those environments are mixed-OS. The build farms are composed of a Jenkins master with multiple slaves of various OSes: Ubuntu, RHEL, and Windows. My home network is running Kerberos and OpenAFS (amongst many other random things [1]) on Ubuntu and Windows.

> We don't believe in hiding too many OS details from you -- for instance, not only do package names vary between distributions but think about how Apache is managed so very differently between Ubuntu and CentOS -- in fact, we've observed in many cases that trying to pave over those things can make content a lot harder to work on.

I don't know... the Puppet module for Apache [2] seems to do a reasonably good job of managing this. Admittedly, pretty much none of the "main" Puppet modules support Windows, but the underlying resource system absolutely does, so adding that support is just a matter of submitting pull requests to the modules.

[1] Everything's documented here: https://justdavis.com/karl/it/

[2] https://forge.puppetlabs.com/puppetlabs/apache

Sorry, but I'm not finding a link to those playbooks anywhere in the Ansible docs. The only cross-platform example I could find in the examples was the riak one [1].

Based on that example and the modules you mentioned, I'm guessing that the only real mechanism for multi-OS playbooks are separate sets of YAML files for each OS? If so, that's not exactly a great abstraction, though I'll agree it is workable. Still seems to be leaving Windows out in the cold altogether, as well, which is a show-stopper for my mixed environments.

[1] https://github.com/ansible/ansible-examples/tree/master/riak

I've been using Puppet on a project for a few months now, and I'm definitely not 100% on it: it's... very rough around the edges, and far more fussy than it should be. But it does have one major thing going for it: wide OS support, specifically including Windows.

Ansible doesn't seem to have this, which makes it a non-starter for me. The project mentioned above that I'm working on is a build farm, and that farm includes Ubuntu, RHEL, and Windows boxes. Ansible also doesn't look like it was designed to shield Playbook writers from the underlying OS much, either. At least, it doesn't seem to have any analogue to Puppet's OS-independent `package` resource; Playbooks all call yum or apt specifically.

That's a shame, because it does look a lot simpler to get up & running with. Learning Puppet and building up useful manifests for it has been a real slog.

Do you have a citation for the 75% number? The last one I'd seen was 3% or 4%.

Not really, no. I've found resumes to be terribly poor indicators of hiring suitability, and so I end up conducting brief first-round phone screens with most at-least-slightly-suitable candidates.

This correlates well with the article here, as it turns out that resumes were more useful as a writing sample assessment than a work experience assessment to this company.

As it should be! You have more of an explanation anywhere?

I use the release plugin myself on almost all my projects, but--BUT--it needs to be said that it's not very flexible. If you can't live with the way it's setup to do things, you're better off writing a shell script to automate things your way than trying to bend the release plugin to fit your needs.

> the fact remains that it [Maven] exists and most developers will have to interact with it at some point or another. That's simply not the case in many other systems.

Are you saying that when developing in Node, you don't have to interact with npm or other build & deployment utilities? End-users of packaged Java applications don't have to interact with Maven any more than end users of packaged C applications have to interact with Make.

Is this correct? Wouldn't they still need all of the leaf private keys to decrypt things?

My understanding was that having a CA's private key just enables someone to issue new child keys for that CA. That vulnerability could be addressed with certificate pinning.

> Anyways, I think a big portion of the "hiring problem" is that companies are too afraid of hiring a "bad" developer. They somehow have this notion that if they fail to hire a great developer then its no big deal, but if they accidentally hire a bad developer, their company will all go to shit.

I've worked in organizations where the hiring process the OP is advocating for (short one hour, possibly non-technical, interviews) demonstrably led to serious problems in that organization. Have you ever sat in on technical software engineer interviews? It's beyond horrifying how many developers I've seen that have a great resume, a decent portfolio, talk a big game, but literally can't solve a fizzbuzz-style problem on a whiteboard. I'd say the percentage in my area of developers who fail at this is at least 80%!

Think about that... if your hiring procedures are lax, possibly 4 out of every 5 developers on your team will be ludicrously incompetent. I don't care how tight the hiring market gets; dumbing down interviews is simply not an option with those kinds of odds.

If you haven't already seen it, you should read Atwood's article on the same subject: "Why Can't Programmers.. Program?" [1].

[1] http://www.codinghorror.com/blog/2007/02/why-cant-programmer...

> Docker relies on a different sandboxing method known as containerization. ... Most modern operating system kernels now support the primitives necessary for containerization, including Linux with openvz, vserver and more recently lxc, Solaris with zones and FreeBSD with Jails.

I'd guess it's (at most) as secure as the underlying OS containerization support.

> That's purely an adoption-by-browser problem.

... which is a pretty big problem, right? Especially since I don't think FF is likely to pick up NaCL unless/until hell freezes over.