/\ndy

Email is the Kind-killer

Email is the mind-killer.
Email is the little-death that brings total obliteration.
I will face my email.
I will permit the email to pass over me and through me.
And when it has gone past I will turn the inner eye to see its path.
When the email has gone there will be nothing
Only I will remain

Replacing Bukkit with CanaryMod for Minecraft

In May this year, we published a book aimed at helping kids learn how to program in Java, using the Minecraft game.  Parents and educators flocked to the book, and eager kids around the world started writing Java plugins using the popular Bukkit library.

But then in September, 2014, the Bukkit library disappeared, apparently the victim of copyright dispute from a former developer. The server portion of the library (CraftBukkit) was removed from the Bukkit site, github, and other sites. So far, there's been no news and no indication that it will ever return.

We here at pragprog.com, however, are agile publishers. 

And so on October 1, 2014, I am pleased to release the new second edition of this very popular book, Learn to Program with Minecraft Plugins: Create Flaming Cows in Java Using CanaryMod, now available in  from pragprog.com/titles/ahmine2.

This new edition of the book has been thoroughly revised and updated to use the CanaryMod library and server, available at canarymod.net. It will be out in print by the end of this month. Special thanks to the crew at CanaryMod.net, they've been very helpful and supportive.  Great group of people.

Happy modding!

/\ndy

New Agile Method announced: SCRAP™

April 1, 2014 (Raleigh, NC)

A new methodology aimed at reducing defects and increasing reliability in code has been announced.  “SCRAP™” is a novel combination of Scrum and XP (eXtreme Programming).

SCRAP™ takes elements from Scrum (the “Scr”) and adds in the “P” from XP, but leaves out the controversial “X” (extreme) elements. The “A” crept in when we weren't looking.

The major innovation in the SCRAP™ method is to take all the code developed at the end of an iteration, and scrap it.  Throw it right out. It sucked anyway, you'd be doing the world a favor.

“We've started SCRAPing our code every other Friday, and we couldn't be happier,” said Sue Mee, team lead at Cavus-Totum, a leading full-stack applications consultancy.  “Our customers are delighted that we're not bugging them with new releases, and our developers have really blossomed.  They are now able to learn all kinds of new techniques that they never would have tried before, because they know it's SAFE to SCRAP the code at the end of each iteration.”

“This is a real innovation,” said Andy Hunt, noted industry observer. “It's a very pragmatic approach to dealing with very real problems. In most cases it really is the best solution to dealing with a huge variety of architectural and process issues.”

Critics say that this approach isn't new at all, and was widely practiced in the early days of software development before version control systems became widely available.

“Github is a real problem with SCRAP™,” said Terry Bull, CTO at Cavus-Totum. “With all that forking going on it's really hard to actually get rid of code completely.”

Despite those difficulties imposed by the modern internet, SCRAP™ is really taking off, with a whopping 97% of companies surveyed by Gaga Group in favor of adopting SCRAP™ for a majority of their current projects.

A conference for SCRAP™ enthusiasts is planned for late in 2014, but details are still being thrown out.

Easy Media Server with a Pi and DLNA

I was playing around with a Raspberry Pi this weekend.  Normally I have the Pi hooked up as a high-definition audio player for 24-bit 96kHz audio files through a USB audio adapter.  

But this time I wanted to do something a little different—I wanted to be able to play some movies stored on a USB stick on an iPad or iPhone. The Pi to the rescue!

It's really trivial to set the Pi up to serve media files that you can play on a mobile device.  One way to do that is to use a DLNA server and client.  You can go all out and use something like XMBC, but that's a little heavyweight and more fuss than I wanted for this application. 

All I needed to do was to install a small package named minidlna,and to mount the 32GB USB stick that had movies on it.

First, to get the UDB stick mounted, you need to find the device name, which will be something like /dev/sda1. To see what device it may be, insert the USB stick into a USB slot on the pi and use fdisk:

    sudo fdisk -l

In that output, you'll see some lines for your USB stick that might look like this:

    Device Boot      Start         End      Blocks   Id  System          
 /dev/sda1   *        8064    60566015    30278976    c  W95 FAT32 (LBA) 

Ok, on the last line I see that's my FAT32 formatted (DOS) 32GB USB drive, and it's on device /dev/sda1. What I'd like to do now is make a mount point for the USB drive (I'll call it /media/usb32) and tell Linux to automatically mount that device on that mountpoint:

    sudo mkdir /media/usb32
    sudo mount -t auto /dev/sda1 /media/usb32

Now the USB files will show up in the directory /media/usb32.

All we need next is to install the minidlna package:

    sudo apt-get install minidlna

And configure it by editing it's config file. I'll use vi, but you can use a simpler editor such as nano (sudo apt-get install nano) if you're not into vi.

    sudo vi /etc/minidlna.conf

You need to add a line to tell the dlna server where your video files are:

       media_dir=V,/media/usb32

The "V," tells it to look for video files under that directory.  Now that you've saved the config file, reload the server:

    sudo service minidlna force-reload

And you're good to go. The server will lurch into life and start indexing your files, which might take a minute or two.  While it's getting set up, go ahead and install a DLNA-compliant viewer on your mobile device.

I had good luck with an app named ArkMC that seems to work smoothly for me on the local network.

And that's it! Simple, easy to set up, and it works a charm. Now I can stream locally from a a larger selection of movies, audio or photos than fits on any of the iPads or iPhones.  So first up I'll replace the 32GB stick with a 128GB stick, or maybe a 1TB disk drive...

That's the fun of doing it yourself instead of buying a pre-built, bespoke device. Want more memory? Just plug it in. Need different features? Load a different package or get to hackin' it yourself.

Gotta love the Pi.

/\ndy

Learn to Program with Minecraft Plugins almost done

My newest book, Learn to Program with Minecraft Plugins: Create Flying Creepers and Flaming Cows in Java is now content-complete and will be heading to prodcution in just a few weeks. That means it won't be long before we've got actual printed copies in hand! If youv'e already bought the book (and a lot of you have!) now's the time to let me know about any problems you've run into, anything that could be clearer, anything you'd like to see.

If you haven't bought the book yet, you can order it in paperback and get the ebook immediately from pragprog.com/titles/ahmine.

It's a great way to introduce kids to the fun of programming. And yes, it really is fun.

Get started now and you'll be ready in time for summer vacation!

No Place for Bugs to Hide

We talk about “bugs” in software as if they were caused by some unavoidable, blood-thirsty third-party that invades our pristine code, much as ants might attack a sweet picnic basket or mosquitoes an exposed neck.

But while bugs seems to be both unavoidable and blood-thirsty, they of course aren’t coming from anywhere but our own hands. We make them, and then they sit there, hidden in plain sight, right in front of us. Waiting for just the right moment (the demo in front of the vice-president?) to spring out from hiding and mock our calm expertise.

Do you know why we advocate the practices that we do in modern programming? Sometimes the reasons get lost in the drive to full buzzword-compliance; or perhaps you’re doing a programming practice because everyone else is doing it, or because some author recommended it. So let’s talk about why.

If you can cut down the number of places for bugs to hide, then when you do create a bug, you’ll find out about it right away. Not a month or six from now, once the app has been approved or the startup has launched or whatever. Get rid of the hiding places and you can fix the bugs now, while they remain small (bugs that hide, of course, snack on leftover code and grow stronger and larger with each passing day).

So here are but a handful of popular practices that help eliminate hiding places:

Unit tests

Why do a unit test at all? For only one really compelling reason: to prove that the code you just wrote does what you think it does. The tests pass, and know you know with some certainty what the code is really doing. That still might not be the right thing for it to do, but at least you’ve removed one breeding area for bugs.

End-to-end Tracer Bullet Development

The first iteration of a system should go from end-to-end, even if it’s as simple as “Hello, World!” That is to say, you’ve got all the major parts hooked up as it will be in the final system: from database through browser via some middleware, that sort of thing. No single part has to do much at all, but it needs to be there—to shine a light and remove a dark hole where bugs can hide.

Buddy up to Prevent Bug-Blindness

We are all particularly blind to the bugs we create, but fortunately a second pair of eyes (someone else’s, preferably) can usually spot them when we can’t. So practices such as Pair-Programming, or Code Reviews (be they nice and informal or excruciatingly formal) can really help identify our own blind spots. Have someone else check all your code before you check it in.

Frequent Delivery / Demo

And of course, nothing brings bugs out into the spotlight as effectively as an audience. Bugs just love the spotlight in front of a live audience, it’s a great chance for them to show off. And get caught. So give them the opportunity often: deliver working software every week or two, and demonstrate it to someone who cares. The bugs can’t resist the urge to show off, and then you’ve got them nailed.

Share Your Status

You need to know what the rest of your team is working on. You need to know when they’re stuck, or when a subtle change in direction or design starts to gain traction. By the same token, you want your buddies to know when you’re stuck or have come up with a new direction. The classic Stand Up Meeting from Scrum is a great way to do this: it’s a quick meeting, you do not go into problem-solving mode, you simply answer three questions:

1. What did I accomplish yesterday? That is, what concrete thing works now that didn’t work or exist before? Never answer with an abstract form of “I’m working on xyzzy.” That’s a dark hiding place. Be concrete.
2. What am I going to accomplish today? What’s your goal to get working today? Same criteria apply as to the first question.
3. What is in my way? This can be a big one. Do you need help? More resources? An answer from a reluctant source? The list of these blockers is your manager’s TODO list.

There are all sorts of other ways to reduce hiding places for bugs: information radiators, continuous build machines, code-level techniques including refactoring, and many others. None of these techniques will stop you from enbugging in the first place, but they will help you find them and squash them more quickly.

Code can be a dangerous place. Keep it well lit, and do go in there alone ;)

Directions for Safe Use

What a great time for open source. Thanks to these marvelous tubes that we call The Internet, there are now uncountable tons of great libraries, frameworks, gems, answers on stackoverflow and more that you can use to add features and functionality to your project quickly and easily.

Unfortunately, a lot of these bits of code and approaches come with their own problems as well. That’s only fair, and to be expected. But the real problem is that most times the author does not disclose these problems. You’re left to discover them—painfully—on your own, or gripe about them in a forum along with other users.

So I put forth a modest proposal. All code you use (be it open source or other) should be subject to similar truth in labeling as we see on pharmaceutical products. You know, the ones where the possible side effects for a headache tablet include headaches, dizziness, and sudden death. That sort of thing.

I won’t name names, but thinking of some technologies I’ve used lately, a few common warnings come to mind:

• Warning, may cause code bloat and gas.
• Use only in iterative environments.
• Do not use if you have a history of procedural programming.
• When used with dual-MVC, may cause confusion, blindness, and death.
• Must be used in the presence of an actual architecture.
• Use on Microsoft operating systems may cause nausea and headaches.

Got any others? Comment below or on twitter (I’m @PragmaticAndy).

/\ndy

Announcing Garnet, A Pure Non-Functional Language

April 1, 2013

There’s nothing as thrilling as announcing a new programming language: a new hammer for all the professional nails you might encounter. And this is possibly the most efficient, most effective programming language ever designed: Garnet.

Garnet is the first Pure Non-Functional language. According to Andy Hunt, the secret to it’s breathtaking efficiency is that “it doesn’t do a damn thing.”

Forecasts are optimistic that this new technology will save corporations billions of dollars that would otherwise have been waster on floundering projects using conventional technologies such as Ruby on Rails, PHP, and the abacus.

“To develop this, we looked at the really hard sciences—seriously hard problems from cryptozoology, astrology, numerology and that head bump thing,” reports Mr. Hunt.

Why “Garnet” as the name? “We wanted a name for something that was harder than Ruby, because, you know, that’s impressive.” When it was pointed out that ruby is actually harder than garnet on the Mohs mineral hardness scale, Mr. Hunt replied “Whatever. The point is, this is the perfect evolution of declarative style programming.”

“To program a system in Garnet, you simply declare what you want, and it will fail to deliver. It’s a lot like Prolog, but with less logic to go wrong.”

User reaction has been uniformly positive. “It’s a huge time saver,” said Fred. “Usually, we have to spend months and months writing code that fails to deliver. Garnet gets us there right away. It’s perfect.”

Andy Hunt
The Pragmatic Programmers
PragProg.com

Resistance is Natural

Resistance is Natural.

Resistance is the enemy. You’ve probably encountered resistance in at least popular form: we call it procrastination. But envision resistance as a much more powerful, more universal and pervasive force. Something like a meta-gravity, weighing down any of your significant endeavors.

That’s how writer Steven Pressfield views it in his book, The War of Art. Resistance as a mindless, destructive force, acting against all your better interests.

Whether it’s a creative endeavor in some art, an entrepreneurial venture or enterprise, diet or health initiative, education or project of any kind, resistance is there to be met as an opposite and equal force.

Resistance is sneaky and subtle. Procrastination is an obvious and easy manifestation, but that doesn’t make it any less potent. Some procrastination is easy to spot, especially if it involves cat memes or Reddit. But what about more subtle forms of procrastination, such as hiding behind estimates, or avoiding pair-programming, or not writing unit tests, waiting until you know before you try, or the pinnacle of group procrastination: the big meeting?

Then there’s the subtle expressions of resistance: some buried, niggling fear. Fear of failure, however small or large. Fear of being exposed as a fraud. Fear of loss. The perceived lack of support from your boss, or folks who work for you, your family, spouse, kids, and the rest of the infinitely uncaring universe. The unforeseen setbacks that send a stab of panic through your viscera.

The amateur takes these all personally, and resistance wins as you waste kilowatts of psychic energy trying to relive, rehash, revisit and reframe these events. The professional sits down, shuts up, and moves the ball forward.

I hate sports metaphors in general, but in this case it’s particularly apt. If the action you’re taking right now isn’t “moving the ball forward” (i.e., not advancing you to your goal), then resistance has won this round. It’s all about moving the ball forward, even if it’s just moving a few inches for now.

Think about that a moment. If your current activity, whatever it is, is not advancing you toward your goal, then it’s pulling you away from it. And no, it’s not letting you idle or stand still. If you’re standing still, your goal is still is motion—away from you. You’re losing ground.

King Leonidas of Sparta once said that the supreme virtue was “contempt for death.” Pressfield equates that in our modern times with “contempt for failure.” No matter what, move the ball forward. Ship the software. Write the chapter. Paint the picture, shoot the scene, post it, commit the code, whatever. Get it out there. Now.

And tomorrow the battle begins anew. New adversaries, new tactics. Resistance is clever, and will go for your soft spots. But resistance’s fatal flaw is its single-minded goal of stopping you from doing what you must. There’s one sure fire to win against resistance in all it’s forms:

Do it anyway.

How to Avoid Agility

There are many great ways to avoid being “agile.” Some are obvious, such as a sticking to a design or schedule long past it’s expiration date. Plans tend to be like milk on a hot summer’s day in that regard. They go sour quicker than you expect. But hey, it’s the plan, it’s already coded, so we chug the chunky milk anyway.

Maybe you’ve even realized that you can successfully hide from agile development in the agile practices themselves. Ron Jeffries points out one way you can avoid reality by hiding in the relative comfort of OCD estimating in his article in PragPub magazine, Estimation is Evil. Ron exhorts us to skip estimating entirely, and start shipping something now.

And that’s exactly the point. Estimation, Test-Driven Development, Pair Programming, Iterations, all the other agile practices are merely tools. As I’ve said (until I’m hoarse) doing the practices doesn’t make you agile. They are helpful, they are useful, but they do not define agility or, by themselves, take you to the next level.

What is the next level? Improv. That is, instead of planning and then executing, you want to execute, evaluate, and repeat. Picture yourself as a geeky jazz soloist: get out a couple of bars of a solo, see how the audience reacts, and change it up as needed, including trying things you’ve never done before.

What is agile development?

“Agile Development uses feedback to make constant adjustments in a
highly collaborative environment.” (from Practices of an Agile Developer)

The reason Ron insists we ship is simple: to be agile, you need feedback, and you need to adapt quickly to that feedback. You need to be able to change your designs, your code, your process, your team — whatever needs changing to reflect the new reality that feedback has reveled. To get feedback on your project, it needs to be in front of the intended users. Often. Every day, every week, surely no longer than once a month.

Note that this doesn’t necessarily mean all your users; you may only roll out to the entire user base much less frequently, say every 6 months or yearly. Or maybe you do it every hour, that’s up to you. But you need feedback from real (albeit maybe a subset) users constantly.

That’s why “Real Artists Ship” as Steve Jobs told us. You have to stop procrastinating and put it all on the line, with real risk in front of real users, all the time.

And that’s where we try and hide from agility. I think it’s a form of procrastination, a form of psychological resistance. The code isn’t ready yet, it just needs…

Don’t wait for the super-elegant object-relational mapping layer you’re going to design from scratch. Don’t wait for that time when you know that new language and environment better. Don’t wait for the committee meeting. Don’t wait to get it right: getting it out there is part of the process of getting it right. You don’t need to get it right the first time, you need to get it right the last time (/ht Jim Highsmith). But on your own, you’re just guessing. Maybe you’re a great guesser, or maybe you’re like me and you guess wrong a lot too. In front of real users, you’re don’t have to guess. You know.

And now you can change what needs changing.

The Marine Corps Way

Agile development is improvisation. It’s making changes to the project based on continuous feedback in near-real time. The U.S. Marine Corps has a common and oft-cited slogan: “Improvise, Adapt, Overcome.” That’s what modern software development needs to be like.

But it seems all too often we’re not improvising, or adapting. We’re just banging out the same old memorized riffs and calling it “agile.”

Ask yourself what you’ve adapted lately. Have you changed the code all around because of some insight from real world use? Great! Have you changed your process because of an insight from a retrospective? Have you changed your team? Your tools? Anything else? At all?

Are you actually adapting? Or just complacently doing TDD, Pairing, stand-up meetings, et al?

Don’t wait: Improvise. Adapt. Overcome. Today.