SoylentNews

I was only at like 86% coverage, but here's some pics I took during the max coverage part, plus a pic I got from a friend. The shadows in the trees was interesting...I guess when the light shines through the leaves it acts like the pinhole effect.

With filter: http://imgur.com/LgGjXye/

Tree shadow: http://imgur.com/PHQCUy1/

Nuther filter: http://imgur.com/fKm8hYb/

I always wanted to look into writing a CS paper that's a formal study of unit testing and test-driven development. Basically, set up a study with two groups performing development and comparing TDD vs legacy-style. I guess you could use a set of CS majors as your test subjects.

So you'd have a control group that just does development, and then a test group that does TDD. The experiment would be designed as follows:

Create a codebase for each individual to work on. The code would be something like this:

main() {
    val = calculateAreaOfSomeComplexShape()
}

calculateAreaOfSomeComplexShape() {
    cube1 = calculateAreaOfCube(length=5)
    cube2 = calculateAreaOfCube(length=4)
    cylinder1 = calculateAreaOfCylinder(radius=5,height=4)
    cylinder2 = calculateAreaOfCylinder(radius=4,height=6)
    sphere1 = calculateAreaOfSphere(radius=2)
}

calculateAreaOfCube(length) {
   return cubeANumber(length)
}

squareANumber(in) {
    return in*in
}

cubeANumber(in) {
    return in*in*in
}

calculateAreaOfCylinder(radius,height) {
    step1 = areaCircle(radius)
    return multiply(step1,height)
}

areaCircle(radius) {
    return 2 * pi * radius
}

multiply(a,b) {
    return a * b
}

calculateAreaOfSphere(radius) {
    step1 = squareANumber(pi)
    step2 = multiply(4,step1)
    return multiply(step2,radius)
}

(yes, there's a bug in the code above)

Control group just gets the code, gets the known good answer, and is told "go debug this!". Time how long it takes to fix it.

Test group gets the code, but is told "write unit tests for each method". Then fixes any problems and see if it gives the known good answer. Time how long it takes to fix it.

So interestingly, my hypothesis is that the control group might actually fix the problem more quickly because they don't have to write unit tests.

But then, give the 2 groups another set of code:

main() {
    val = calculateAreaOfSomeComplexShape()
}

calculateAreaOfSomeComplexShape() {
    cube1 = calculateAreaOfCube(length=5)
    cube2 = calculateAreaOfCube(length=4)
    cylinder1 = calculateAreaOfCylinder(radius=5,height=4)
    cylinder2 = calculateAreaOfCylinder(radius=4,height=6)
    sphere1 = calculateAreaOfSphere(radius=2)
}

calculateAreaOfCube(length) {
   return cubeANumber(length)
}

squareANumber(in) {
    return in*in
}

cubeANumber(in) {
    return in*in
}

calculateAreaOfCylinder(radius,height) {
    step1 = areaCircle(radius)
    return multiply(step1,height)
}

areaCircle(radius) {
    return 2 * pi * radius
}

multiply(a,b) {
    return a * b
}

calculateAreaOfSphere(radius) {
    step1 = squareANumber(pi)
    step2 = multiply(4,step1)
    return multiply(step2,radius)
}

(its a different bug this time)

Control and test group, same task. But now the test group can run their unit tests right away and spot the error. Time how long it takes them to fix vs how long it takes the control group to debug the whole thing again.

I think you could make the sample code even more complex. Figure out ways to make the call tree deeper and wider.

I'm honestly curious what the results would be. Does the unit testing group show a significant improvement the first or second time?

So almost everyone agrees that testing and stuff is good. Automated testing? Even better.

And in a lot of progressive software shops, we've got fully automated build pipelines that continuously run unit tests, prettifiers, security scans, and things like that against code that is being checked in by developers. In my opinion, this is amazing and fantastic. It greatly improves code quality and also greatly enhances productivity. Combined with something like ChatOps/Slack, now you've got almost-real-time feedback on the state of your software projects. As a developer I love it.

Some people that this even a step further. They trust their automated QC/verification processes so much, that if the processes give a thumbs up then the code can be deployed automatically and immediately to production.

In my opinion: Game Changer! I still believe

Speed of iteration beats quality of iteration

(--John Boyd) so anything that increases velocity is a step in the right direction.

(disclaimer: obviously this doesn't count if you're writing code for a nuclear power plant or the space shuttle. But if all you're doing is a silly little webapp...)

So, since my company is in a constant state of flux (as are all, I believe), in our inexorable march to DevOps I've migrated from mostly writing code for our customer-facing products that we actually build, to working with the systems and ops folks in the management of the environment. Since we are now like 80% in the Cloud (tm)(c)(r) our new internal buzzword is <sarcasm>Software Defined Data Center</sarcasm>. The entire cloud datacenter is built via code (or at least code-like text, such as raw JSON). The goal was for the sysad team to start operating like a software team.

I can't tell if this is good or not.

My current biggest challenge is trying to figure out how (and even *if*) you could apply CI/CD and automated testing principles to this type of environment. Again, if you Google around the ol' blogosphere you'll find plenty of articles, whitepapers, blogs, essays, and writeups from people who all state that Testing is Good, Automated Testing is Better, and indeed the infrastructure-side of your teams should indeed be doing all these things. But what I've found interesting is...I can't find anyone who actually provides concrete examples of implementation and mechanics. Its easy to find examples and tutorials for software products, but not infrastructure.

Here's what I mean. Say you have a Ruby on Rails app as your customer facing product. Its pretty straightforward nowadays to have an automated test suite, which upon commit/push to your repo automatically spins up a container, deploys the code, and runs all the unit tests. Upon success, again its pretty easy to use some orchestrator, CI pipeline, or configManagement tool (i.e. jenkins, ansible, puppet, chef, bamboo, gitlabCI, etc etc etc ad nauseam) to push all this nifty code to production.

So let's say I'm managing.....let's say an OpenLDAP server. How can you CI something like that? Deploy to a container? There's nothing to really unit test. The biggest test I want to do is, say I'm deploying 3 or 4 of them, making sure replication is flowing between them. Its trivial to write a script that does this test, but where's the orchestration? Upon commit/push, do you have your CM tool deploy an entire new cluster and run these tests? Who acts as the observer/controller for this non-trivial event? It seems really super heavyweight.

It really sort of turns into a "who watches the watchers?" scenario. Automated unit testing via CI works because your code product can be completely contained, observed, and controlled via a test harness. Well how do you test harness something like an Active Directory Domain Controller? Or your Jira server?

In short, it sounds like a good idea to do "automated testing" for automated deployments of enterprise systems, but actually doing it? Its a lot harder than it seems.

....and here's mine!

Let's start with a few core tenets.

• Tenet 1: Over time your organization's process flow will align with your org chart

I can't remember where I read this, but I believe it. It makes sense because its most driven by...

• Tenet 2: The maturity and agility of an organization can be measured by the speed with which it communicates

Again, I can't remember where I read this. CMMI training maybe? But again, this makes sense because your ability to change ("pivot") depends upon your communications speed. On my team, we can huddle up and change what we're doing RIGHT NOW if need be. But if it involves another team?

Let me ask you this, how easy is it to communicate with someone on your team? Probably pretty easy. What about someone on another team? OK, you might have a personal relationship with someone so its easy, but structurally and in larger bureaucracies its probably pretty hard.

Now synthesize all these things. What it tells you is,

Your ability to execute depends STRONGLY on your org chart.. Plain and simple.

OK, so....let's think about the product lifecycle. From requirements to deployment and sustainment. Within this specific lifecycle you've got Dev, and you've got Ops. And typically at some point you have to transition your product from Dev to Ops. So, if you have on your org chart, those two teams separate, you have purposefully built in a limiter to your velocity.

So the simple solution? Reorg, and put those teams together. You've now allowed the product lifecycle to speed way up. In fact, in many cases (like CI/CD) its so fast its not even recognizable as a transition from dev to ops anymore.

So there. That's my definition of DevOps.

I see so much doom and gloom......college degrees are worthless, graduating kids can't find jobs with their degrees, robots will put all the service industry workers out of work, etc etc etc.

So if I've got a kid, or know a kid, who's about to graduate high school, what's the life advice for them?

• Go to college: straight to 4-year or big name. Pros: connections Cons: debt
• Go to college: community college first. Make sure you intern. Pros: no debt, work experience, might be able to get hired somewhere... Cons: ...just not for $100k right out of school.
• Degree? Medical? Maybe. Engineering? Maybe. Law? Doesn't seem tenable. Business? No freakin' way. Digital Art? Maybe Anything else: You're screwed.
• Skip college, find a trade or cert path. Pros: You can probably eventually find a job somewhere Cons: You'll be underemployed and have a low ceiling (I'm not saying this is fair, I'm just saying pragmatically this will probably happen)
• Join the military? Um......
• Skip college, don't do anything Pros: warm and safe in your parents' bedroom Cons: You'll never reproduce

Actually, I joke to myself that within the next few years, my kids could probably get their BS and MS completely online, then get a 100% telecommuniting job, and eventually be making more money than I do and still be living at home.

So I saw this on *cough* another site *cough* but what books are people reading nowadays? I saw a comment, something like "My attention span is so shot from twitter and the web that I can't even finish a whole book anymore". I wonder if I'm suffering from that. I've tried to read a couple books lately but couldn't get traction:

• Redwall by Brian Jacques
• The Final Empire by Brandon Sanderson
• Countdown to Zero Day by Kim Zetter
• Why We Want You To Be Rich by Donald Trump and Robert Kiyosaki

There's more but....bah, I can't remember.

So......anyone read any good books lately?

I've never been a big believer in certifications. A college degree has some worth, in that I believe it taught you to think and stuff. But even then...to be honest when hiring I probably base 50% off the technical prowess you can show in conversations, whiteboards, coding challenges, and 50% in culture fit in conversations with some of the senior staff.

Well, not all employers are like that. Some place a lot of value on certifications. In fact, the metric by which you are assumed to be competent in a skillset is if you have the requisite certifications.

For my denigration of certifications, its even one step further. Although I study best practices and vendor literature, I don't believe in blindly following it. I believe in sandboxes, experimentation, breaking things, trying things out. If you told me to build a clock I would not follow a step-by-step instruction manual and build it right the first time. I'd probably throw the instruction manual away and then take apart a bunch of clocks and screw around trying to put them together until I found something that works and I'm satisfied with it.

Again, for a lot of large enterprise organizations this doesn't fit. They pay for enterprise support for a reason.

IMHO, sadly, the IT world is moving away from my approach and more towards the enterprise approach. Most of the IT market is not flexible, configurable tools for sysadmins. Instead its out-of-the-box integration tools. "Buy product X! It does Feature Y and integrates out-of-the-box with product Z!". So if you have Product Z and your employer wants Feature Y, they'd rather pay enterprise prices for Product X and you as the sysad are supposed to follow the step-by-step instructions to install and configure the application.

Hogwash, I say! How are you supposed to truly troubleshoot or performance tune such a situation? But I digress.

In the spirit of being a good team player (and my own career health), in the last year I've attained three certifications, whereas in the past 20+ years of my career I've had zero.

And I'm taking an exam tomorrow for one of the hardest ones yet, and I'm STRESSED. I mean, like panic attack stressed. Hand shaking, had to pull the car over, throwing up in the bathroom stall, can't sleep stressed. Ugh.

Come tomorrow afternoon I'll either be on a super high or....I dunno. Just resign and become an Uber driver I guess.

Ever see a post on a forum like this? The meme, "If someone did Y at my company, they'd be fired immediately!"

• https://ask.slashdot.org/comments.pl?sid=1684362&cid=32555488
• http://thedailywtf.com/articles/comments/Does-Not-Compute-Crunchies,-Virtual-Returns,--More/2#comment-243921
• https://ask.slashdot.org/comments.pl?sid=4094229&cid=44578189

I just find it interesting...in my experience, unless you're working at a mom-and-pop or startup, a big corp can *never* fire you immediately, even if they want to. Its months and months of "Improvement Plan" and "Counseling" and so forth.

In fact, when working at the larger companies I have frequently made the joke, "I wonder if I stopped working right now, how long it would take for me to get fired?". What's the bare minimum I could do to not get fired? I think as long as I sign my timecard I'm probably good for 3+ months...

I used to have a whiteboard by my desk, and whenever a particularly witty and insightful comment was made I would write it down. Here are some of my favorites:

• Sometimes you just need to write the dang if statement!

  (Wasn't until a few years later that I saw Ken Thompson's quote about brute force)

• Ugly code is ok, as long as its wrapped and hidden in the library modules.

• Once you document a kludge, its no longer a kludge.

• The most dangerous thing to say during a project is, "Wouldn't it be cool if..."

Then of course, some of my favorite quotes, that I actually ascribe to, even to this day:

• The first attempt is always wrong. You must iterate towards the best possible solution, not try to get it on the first try.

  — Matt Bilotti

• A cardinal, fundamental law of programming: It’s harder to read code than to write it.

  — Joel Spolsky .... which leads us to:

• Debugging is twice as hard as writing code. Therefore if you write code as cleverly as possible you are not smart enough to debug it.

  — Brian Kernighan

• Speed of iteration beats quality of iteration.

  — John Boyd ... which leads us to:

• Move fast and break things. Unless you are breaking stuff, you are not moving fast enough.

  — Mark Zuckerberg

The most memorable quotes from books that stick out in my mind, the ones that literally caused me chills or to gasp out loud:

"They're dirty, they're all dirty. The entire Five Squad."

"Fire." Enough energy shot out the side of the dreadnought to destroy a small moon, and Battlecruiser Division One ceased to exist.

She did not know what was more satisfying: the sound of a dozen swords drawn as one or the look on his face.

What are some of yours?