The Pragmatic Bookshelf

PragPThe Secondu Iterationb

IN THIS ISSUE

* Rothman and Lester on mentoring * Marcus Blankenship on managing programmers * Ron Hitchens on Resource Oriented Computing vs Object Oriented Computing * Brian Sletten on Resource Oriented Computing vs Microservices * Tom Geudens on Resource Oriented Computing * Dan Wohlbruck on the C language * Antonio Cangiano on new books for programmers Issue #66 December 2014 PragPub • December 2014

Contents

FEATURES

Your Object Model Sucks ...... 15 by Ron Hitchens The big idea in Object Oriented Programming was always messaging, not objects or classes. Resource Oriented Programming gets that right.

Microservices Is not the Answer ...... 23 by Brian Sletten Microservices has the right idea. It just doesn’t take it far enough.

Introducing Resource Oriented Computing ...... 33 by Tom Geudens There’s a program that’s been running for 25 years, that scales like nobody’s business, and that’s based on open protocols. Can your code measure up to that?

The Evolution of C ...... 44 by Dan Wohlbruck Dan continues his series on the history of programming languages with more on C.

— i — DEPARTMENTS

On Tap ...... 1 by Michael Swaine

Swaine’s World ...... 3 by Michael Swaine We follow Twitter so you don’t have to.

Rothman and Lester ...... 6 by Johanna Rothman and Andy Lester Have you been stuck mentoring the new guy? Or are you, on this job, the new guy? Her’s how to play that.

New Manager’s Playbook ...... 9 by Marcus Blankenship Launching a new column by Marcus on what to do when you become a manager.

Antonio on Books ...... 48 by Antonio Cangiano Antonio looks at all the new tech books of note.

Pragmatic Bookstuff ...... 51 Want to meet one of the Pragmatic Bookshelf authors face-to-face? Here’s where they’ll be in the coming months. Also, find out which are the top-selling Pragmatic Bookshelf books and what new books are coming out.

Solution to Puzzle ...... 53

Except where otherwise indicated, entire contents copyright © 2014 The Pragmatic Programmers.

You may not sell this magazine or its content, nor extract and use more than a paragraph of content in some other publication without our permission.

Published monthly in PDF, mobi, and epub formats by The Pragmatic Programmers, LLC, Dallas, TX, and Raleigh, NC. E-Mail [email protected]. The editor is Michael Swaine ([email protected]). Visit us at http://pragprog.com for the lowdown on our books, screencasts, training, forums, and more.

ISSN: 1948-3562

— ii — On Tap It’s All About Messaging You can download this issue at any time and as often as you like in any or all of our three formats: pdf [U1], mobi [U2], epub [U3]. by Michael Swaine Resource Oriented Computing For half a century, we’ve been building software that makes certain broad assumptions about operating systems versus applications and data versus code. For the past quarter of a century, we’ve been deploying a lot of that code in a space that makes its own, somewhat different, assumptions: the World Wide Web. Yet the code underlying today’s web apps usually doesn’t look all that different from the earliest C code that Dennis Ritchie wrote. It’s not that there haven’t been new and empowering paradigms. Object Oriented Programming burst on the scene with some deep and powerful ideas about messaging... but then, because people took its name too seriously, it became all about objects and classes. Resource Oriented Computing grew from that same root, but kept the focus on messaging. The result is that, in Resource Oriented Computing, the relationship between code and data becomes more balanced and respectful, and distinctions like application program versus operating system become academic. Resource Oriented Computing takes its inspiration from that extremely long-running and infinitely scalable and incomparably successful software project, the World Wide Web. It is a new/old paradigm that asks the question: shouldn’t your app work the way the Web does? As the articles by Ron Hitchens, Brian Sletten, and Tom Guerens show, Resource Oriented Computing is a very different way of programming. It’s not microservices, although there are similarities. It’s not just REST-based app development, although it encompasses that model. It’s more. And in terms of lines of code you need to write, it can be less. This month’s issue explores the ideas behind Resource Oriented Computing, compares it to more familiar approaches, and introduces you to a platform that will let you get to Hello World and beyond with this different take on software development. We’re also introducing a new columnist in this issue: Marcus Blankenship brings his expertise and insights on how to deal with the challenges of being a new manager or team leader. Also, regular contributors Johanna Rothman and Andy Lester talk about the challenges of dealing with The New Guy (or of being The New Guy), Antonio Cangiano reveals all the hot new

PragPub December 2014 1 programming books, and Dan Wohlbruck digs into the history of programming languages.

Kids and Code Yes, but I mustn’t forget to remind you that you can also download our special issue on teaching kids to code for free at the Prose Garden website [U4]. It contains: • “Constraints and Freedom” by Jimmy Thrasher, • “The Hour of Code” by David Bock, as well as • “Giving Back” by David Bock, • “Lego League: Lessons Learned” by Seb Rose, • “Coding Unplugged” by Fahmida Y. Rashid, • “The Anti-Cosby Approach to Teaching Kids Programming” by Chris Strom,

• and “The Selfish Teacher” by Michael Swaine.

Who Did What photo credits: Cover: “Get the message!” https://www.flickr.com/photos/fabolous/12414076055/ [U5] by Patrik Theander is licensed under https://creativecommons.org/licenses/by/2.0/ [U6]. Page 15: “Can-Can Girl” https://www.flickr.com/photos/garryknight/ [U7] by Garry Knight is licensed under https://creativecommons.org/licenses/by/2.0/ [U8]. Page 23: “Back to the Future DeLorean Time Machine” https://www.flickr.com/photos/lautenbach/ [U9] by AdamL212 is licensed under https://creativecommons.org/licenses/by/2.0/ [U10]. Page 33: “Speak, Talk, Microphone, Tin Can” http://pixabay.com/p-238488/?no_redirect [U11] by Ryan McGuire is licensed under https://creativecommons.org/licenses/by/2.0/ [U12].

editing and production: Michael Swaine

editing and research: Nancy Groth

customer support, subscriptions, submissions: [email protected]

staff curmudgeon: John Shade ([email protected])

PragPub December 2014 2 Swaine’s World Retweets and a Puzzle If you want to learn more about Resource Oriented Computing, this issue’s theme, you would do well to check out the course offerings at Skills Matter by Michael Swaine [U1]. Brian Sletten’s REST and Resource-Oriented Architecture Bootcamp [U2] is just one of the upcoming ROC-centric events coming up. What our editor is paying attention to this month. Looks like tweets. This Coding Life • $5 says Groupon backs down, drops the name Gnome, and rebrands their OS to KDE. — @dbentley • 2014: For the first time I had a legit use for the ‘+ operator in CSS. I stand by my rant from 2008: http://ejohn.org/blog/selectors-that-people-actually-use/ … — @jeresig • “What’s bower?” “A package manager, install it with npm.” “What’s npm?” “A package manager, you can install it with brew.” “What’s brew?” ... — @ddprrt • Suggestion from a @GDIsf-er: paired programming for couples. Really great idea, or really, really bad idea? Discuss. — @pamelafox • @tenderlove “I’d like 1.0 root beers.” “That’s a root beer float.” “Make it a double.” — @harpaa01 • Finding just the right level of abstraction feels like a warm blanket. — @benrady • There is a working generation of people who have never known email as a channel for messages you want from people you know. — @chadfowler • Doing nothing is harder than it looks. — @tara • Card Deck of Notable Women in Computing. http://buff.ly/1B7l9x7 #girlscode #coding — @jovenprogram • “What we do not automate, we are doomed to repeat.” - @ultrasaurus at @RubyWorldConf — @pat_shaughnessy • “JavaScript doesn’t care what you think.” — @RachelAppel The Writer’s Mind • Somewhere, all my protagonists sit around a metaphysical dinner table, drinking and complaining about me. — @codejill • Whatever else they are, book tours are reliable mechanisms for making the touring author more self-referential. — @GreatDismal • Thrilled to hear that Ursula K. Le Guin just won the Medal for Distinguished Contribution to American Letters! — @brainpicker • If you’re 30 or younger, for over half your life ZERO published works have entered the US public domain through copyright expiration. — @Roz_Morris • The Icelandic word for raccoon is þvottabjörn which means “laundry bear.” — @SamuelMoen • My tweets are not written to be read. They are written to be said aloud, with pain and passion, at the pace of speech. — @SwiftOnSecurity

PragPub December 2014 3 • Raleigh-Durham’s airport has 2nd Edition, a *used* book store. #ultracivilize — @GreatDismal • Don’t be too hard on yourself when you’re not feeling creative. There are literally 2 major league baseball teams named after sock colors. — @RandiLawson

Mixed Media • This font is made entirely from satellite imagery of buildings. http://wrd.cm/10Tl6UV pic.twitter.com/QdqrSgJ2B0 — @WIRED • Facebook just launched Techwire, a curated channel for tech news. — @mims • Car companies should collaborate on the tones their horns make, so when a bunch of cars honk at the same time it’d make a major chord. — @charliepark • It’s so exciting to hang out with cardboard @chadfowler!!! — @tenderlove Looking Forward to That • Why you probably won’t understand the web of the future. http://qz.com/292364/why-you-probably-wont-understand-the-web-of-the-future/ … — @davewiner • 2017: All “apps” have been reduced to a collection of icons which accumulate numbers inside red dots. Tap to remove the red dots. Good job. — @drewtoothpaste • It really does look a little like a flux capacitor. http://www.engadget.com/2014/11/11/flux-3d-printer/ … — @pragpub

Observations • “Between prosperities” sounds so much more optimistic than “flat broke.” — @KentBeck • Well that’s weird. Mattel just introduced Computer Engineer Ken, who also can’t program but costs 20% more. — @secboffin • The BRCK looks like a cool product: http://www.brck.com Designed & prototyped in Kenya! — @timbray • Twitter followers, if you haven’t already picked out my Christmas present, that Thor Frog diorama looks pretty special. — @pragpub • Something I don’t hear often: “I’m sorry, I have to run, my boat is leaving.” — @venkat_s • http://mail-tester.com has a progress bar that consists of a snail, moving across the page. Kudos. — @PragmaticAndy • “Those who successfully managed a company to maturity are unlikely to be able to manage it back to youth.” -Russell Ackoff — @hemppah • Success measured by getting a different error each time. — @selenamarie • Never say “it does not fit to our culture.” You are a part of the culture and every culture can evolve and improve like you do. — @lemiorhan • Great thought from @jeffpatton: Nobody ever said “I love this product, it came out on time.” Loving #bddx and I’m only 30 mins in. — @victoriawiggins • Celery is 95% water and 100% not pizza. — @BiIIMurray The Puzzle Here’s this month’s brain-teaser. It’s a sudoku, but with letters. Using only the nine letters that appear in the grid, fill in the empty cells so that every row, every column, and each of the nine 3x3 boxes contains all nine letters.

PragPub December 2014 4 And it’s also an anagram. Properly arranged, the nine letters in the puzzle will form the codename of a tech product, so finding that codename and the product it refers to are also part of the challenge. Solution further on in the issue; don’t peek! If you need a little hint to get started, the word BLEU appears in one column.

X X X X X X X X B

X X E X X U X X X

R X U X X A X X E

X X X B X C X L X

X X X X R X X X A

X X X I X X E X X

B L X X X R C X X

C X X X I X L B X

X E X X L X X X I

• A selfie is a picture of the picture-taker taking a picture of himself looking at himself taking his picture. — @pragpub

The Tweeters Here’s the list of folks I followed this month: Rachel Appel, Geoff Arnold, Ars Technica, Stefan Baumgartner, Kent Beck, Dan Bentley, Tim Bray, Tara Tiger Brown, BuzzFeed News, Megan Carolan, Clinton Foundation, Alan Cooper, Cory Doctorow, drewtoothpaste, Lemi Orhan Ergin, Chad Fowler, Pamela Fox, Cory Foy, William Gibson, Hacker News, Aaron Harpole, Joanne Harris, Parker Higgins, Jenni Hogan, Metrics Hulk, Andy Hunt, Hermanni Hyytiälä, Ron Jeffries, jgehtland, Myriam Joire, Elizabeth K. Joseph, Olaf Koens, Corey Leigh Latislaw, Randi Lawson, Graham Lee, Andy Lester, me and philbae, Ernie Miller, Christopher Mims, Roz Morris, Bill Murray, Jill Murray, Jen Myers, #NotAllBlkFeminists, Open Whisper Systems, P. Oppenheimer, Charlie Park, Aaron Patterson, Maria Popova, Joven Programador, Ben Rady, John Resig, James Rocchi, Sam, Pat Shaughnessy, snipe, Stormy, Chris Strom, Venkat Subramaniam, Michael Swaine, InfoSec Taylor Swift, Larry Tesler, unpixie, Maciej Walkowiak, Victoria Wiggins, Dave Winer, Jon Winokur, and WIRED.

Fair’s fair. You can follow me at www.twitter.com/pragpub [U3]. Or visit my blog

at swaine.com [U4].

PragPub December 2014 5 Rothman and Lester The New Guy Johanna: Your boss is hiring someone new. Or, you have to work with someone across the hall for a week or a month. Or, maybe you’re the new guy or gal on by Johanna Rothman and Andy Lester the project for a while.

Have you been stuck mentoring the new guy? Or Whichever the situation: either you need to mentor or coach someone for a are you, on this job, the new guy? Her’s how to play while — or you yourself need coaching or mentoring. that. For some of us, this is a recipe for a disaster. “Leave me alone, in my cube. Don’t interrupt me,” you think. Or, “Just pair me with someone else. Anyone else. Don’t stick me with the new guy.” There are ways one can approach mentoring or coaching. The first thing to note is that coaching and mentoring are two very different things. We’ll get to the definitions later in this column, but let’s handle what you might do if your boss comes to you and says, “Please mentor/coach the new guy.” Andy: That sounds like a pretty horrifying thought, that your boss would dump someone on you without prior discussion and what she had in mind for you to do, but go ahead, let’s run with it. Johanna: Even if your boss discussed this with you, it still might be horrifying. You might subscribe to the buddy theory of bringing new people in [U1], or you might not want the hassle of working with someone for a few weeks. Andy: I see “The New Guy’s” needs as knowing how things are done in the organization. Like most things, there’s the technical half, and there’s the people half. The people half is the most immediate. When I’m in a new organization, I feel like I’m constantly being watched and I hate worrying about Doing The Wrong Thing. There’s so much about how things get done that is just part of the culture that can be alien to the others. Maybe in your old organization you did asynchronous communication via email and Google Chat, but in the new one it’s all IRC and trouble tickets.

Ben Balter recently published a guide to how to communicate effectively [U2] while working at GitHub. While I don’t suggest that you need to write a 15-point manifesto, the types of things he discusses in it are excellent examples of what “The New Guy” needs to know. The other half is technical. Much of this should be documented somewhere, such as in a department wiki, but even if it is, walk through the important technical highlights of how exactly things get done. Think about day-to-day life and what TNG needs to know. Who do you go to with PostgreSQL problems? What editors do you support as a team? How much flexibility do the devs get in choosing tools? What’s a high-level view of your development

PragPub December 2014 6 stack? How are code reviews done? What’s the development process? Who controls what boxes? Does everyone have sudo or is access tightly controlled? There’s a ton of day-to-day life that the existing staff takes for granted. Johanna: Yup, those are exactly the kinds of things you want to explain to TNG. If you have an agile team, or you’re transitioning to agile, there are a few other questions that need to be answered whether or not they’re asked: not just when do standups occur, but also what are the team norms? Do we limit work in progress as a team? Do we check in more often or less often? How do we ask for help or offer feedback? Do we do code review? All of these things are part of “how do we work here?” Andy: I don’t see those as being just for the agile shops. Every one of those, except maybe asking about standup meetings, applies to every programming shop. Johanna: One thing TNG can do is say, “Huh? I didn’t expect that.” Your new guy just came in through your good hiring process, right? You made sure you hire great people, right? So, if the new guy looks puzzled, or doesn’t understand something, maybe you have an obstacle that you should remove. Maybe there is something that everyone trips over every day. But, only the new guy actually sees it. Listen to what the new guy says, “huh?” to. Andy: Certainly we should all be good listeners, but when working with new hires you have to listen over and above the call of duty. I’d say you may even need to listen to what’s unsaid. Many people are afraid of “asking too many questions” for fear of looking incompetent, and all the reassurances that there are no stupid questions is not going to put that to rest. Johanna: Let’s summarize. Your new guy needs to know where all the apps are. TNG needs to know what’s acceptable to do and not to do: whether you do code reviews and how. When the meetings are, and what to expect from them. If you’re smart, you’ll get the new guy to help you debug your new employee intake process too!

If you use a formal buddy system [U3], you can reduce the time it takes for TNG to come up to speed. As for the difference between mentoring and coaching? Here are my definitions: Coaching is about offering options with support. Mentoring is a professional developmental partnership in which one person shares knowledge, skills, information, and perspective to foster the personal and professional growth of someone else. You might mentor someone and then offer to coach them.

About the Authors Johanna Rothman helps leaders solve problems and seize opportunities. She consults, speaks, and writes on managing high-technology product development. She enables managers, teams, and organizations to become more effective by applying her pragmatic approaches to the issues of project management, risk management, and people management. She writes the Pragmatic Manager email newsletter and two blogs on www.jrothman.com [U4].

Andy Lester has developed software for more than twenty years in the business world and on the Web in the open source community. Years of sifting through résumés, interviewing unprepared candidates, and even some unwise career choices of his own spurred him to write his nontraditional book [U5] on the new guidelines for tech job hunting. Andy is an active member

PragPub December 2014 7 of the open source community, and lives in the Chicago area. He blogs at petdance.com [U6], tweets at @petdance, and can be reached by email at [email protected].

External resources referenced in this article:

[U1] http://www.jrothman.com/2004/12/how2-create-a-buddy-informal-mentoring-program/

[U2] http://ben.balter.com/2014/11/06/rules-of-communicating-at-github/

[U3] https://pragprog.com/book/jrgeeks/hiring-geeks-that-fit

[U4] http://www.jrothman.com

[U5] http://www.pragprog.com/refer/pragpub51/book/algh/land-the-tech-job-you-love

[U6] http://petdance.com

PragPub December 2014 8 New Manager’s Playbook Having Difficult Conversations with It’s a fairly routine deployment, but this time, it’s not full of victories. Employees Something goes wrong — seriously wrong — and when the dust settles, you discover the problem centers on a basic mistake made by one of your by Marcus Blankenship programmers.

In this new column, Marcus addresses the problems To add to the pain, this particular programmer just happened to leave work every new programmer-manager faces. early that day and missed all of the fun. Your stomach is churning, your head is pounding, and you’re about ready to rip loose a torrent of frustration on innocent bystanders. Welcome to management! Now is the perfect time to have a difficult conversation.

Difficult Conversations, Defined A difficult conversation is any interaction you have with your team members that puts you in position of delivering course correction. As a programmer, you probably weren’t forced to face this situation because you were responsible for your own work, period. As a manager, you’ll be faced with initiating these emotionally-charged exchanges on a regular basis in a supportive, professional manner. Difficult conversations can range from pointing out a flaw in a piece of work, reinforcing company policy, or the ultimate — having to tell someone to clean out their desk and pick up their last paycheck on the way out the door. We all love giving positive feedback, like breaking the news about a promotion or heaping praise on the person who saved the project with an elegant workaround. But when someone you manage screws up and it’s time for some good old-fashioned accountability, most people would rather pay out of pocket to endure a root canal than to have to tell their former peer that they screwed up.

Why Difficult Conversations Are... Difficult Let me point out the obvious: No one likes conflict. In today’s work environment, where we’ve been steeped in politically correct notions of self-esteem and egalitarian relationships, these top-down conversations feel soooo 1970s. Rather than playing the nice guy, you have to act like an authority figure, asking people to toe the line, straighten up, and start doing better work. You’re

PragPub December 2014 9 afraid of coming off like your junior high principal with his polyester suits, rigid ideals, and wooden paddle.

Warning: Duck and Cover Is a Dead End Naturally, most people avoid that uncomfortable place. The problem is that most managers haven’t found a more functional system. When it comes to team issues, they’d rather sit around singing “Kum Ba Yah” than give negative feedback. In fact, most well-intentioned new managers I meet tend to fall into one of two less-than-productive camps when it comes to conflict: 1. Those in the first camp don’t talk about problems at all, hoping deep in their hearts that things will magically improve and that everyone will just do everything perfectly so a manager won’t have to step in at all. 2. Those in the second camp don’t think they should have to give correction and instruction — team members should just “get it.” Usually, after months of watching a programmer make mistake after mistake (without intervention), their internal scorecard gets filled up, and they decide that this person just doesn’t cut it. They seethe with frustration and decide that the only solution is to fire the guy. Clearly, there’s a lot of room between those two positions for clear, helpful communication, even if it’s not easy. So what’s the answer?

Have More Difficult Conversations Don’t start looking for a magical mantra or a perfect script to make these uncomfortable situations vanish. You want to learn to steer the ship, not look for an escape hatch. A willingness to look a problem in the eye and practice having tough conversations pays huge dividends. Believe it or not, these conversations can be handled in a way in which you and your team can see them as a normal — and productive — part of the design process. These tricky conversations can actually be an effective tool to connect with team members, invest in their skills, and help the company deliver a quality product that keeps them economically viable. Before you call someone into your office for a difficult conversation, it can take the pressure off a bit when you know your role and own it in these situations.

Be the Conductor I like to use the analogy of the technology manager as the conductor of an orchestra [U1].

Up at the podium, the conductor has the perspective to see and hear everything. They know when the bassoon player misses her entrance. They hear the sloppy fingering of the third violins in a difficult passage. What does the conductor do in response?

PragPub December 2014 10 A skilled conductor will stop the rehearsal, gently and clearly point out the mistake, and have the musicians run the section again, several times if necessary. Conductors know there should be little or no shame in these exchanges — it’s just part of preparing an entire group for a magnificent performance. Usually, a few minutes of focus can smooth out the problem. While the musicians never enjoy getting singled out for less-than-stellar playing, they also understand that this attention lands on everyone eventually. It’s part of being in an ensemble. For more persistent problems, conductors will usually call the musicians aside and suggest something like extra rehearsal time or one-on-one sessions with the section leader. If that intervention doesn’t do the trick, then it is very possible that they’ll be looking for another bassoon player next season. In other words, clear communication concerning individual and team performance has a predictable pattern, and the world doesn’t fall apart every time the conductor points out a need for improvement.

Small Conversations, Big Payoff Likewise, you can offer ongoing feedback in small, granular ways so you grow comfortable giving correction and your team doesn’t panic when they receive it. One easy way to do this is by offering a bit of criticism every time you review a piece of work from a team member, even (and especially!) if it’s minor. Your programmers will soon understand that you’re paying attention, and the nudge will help them level up their game. For the naysayers who think that their team should just “get it” without even this simple level of intervention, let me give you a wake-up call. Yes, we’ve all had employees who walked on the scene somehow knowing exactly what needed to be done and did it without a whisper of direction. It is a beautiful thing to behold. After dealing with both interns and seasoned programmers for years, I can tell you that these rock stars who seem to automatically “get it” had someone invest in them and train them in the basics of team culture. Now it’s your turn. Here’s how to use that power wisely.

Be a Surgeon, Not a Barbarian In every manager’s office there hangs an imaginary sword. It’s a sword of decision and power that was handed to you with the position, making it possible for you to respond to your team’s needs without having to run to your manager every time there’s an issue. Most new managers eye it nervously, hoping and praying that they’ll never have to touch it. Others are more passive-aggressive, eyeing it in front of team members and saying, “Don’t make me reach for this.” In either case, the sword rarely gets used, which just makes the manager look really clumsy every time he tries to pick it up.

PragPub December 2014 11 Practice Creates Ease and Finesse Watch little kids playing with swords. The first time they have one in their hands, they either make feeble jabs or they run around screaming and hacking the air… and their siblings. New managers, unfortunately, do the same. Some are so timid with their power that their team has zero confidence in management’s skills or leadership abilities. Others use it only when they’re boiling over with frustration, leaving their team to hit the decks to avoid their wrath. When managers make a conscious choice to practice using this power on a consistent basis with an average workflow, they’re reducing the learning curve and increasing team effectiveness. With a little practice, you can turn your sword into a scalpel, making small, pinpoint cuts that leave little mess and heal quickly, just as a surgeon does. The keys to this approach are a commitment to improving a bit each week and having a simple, reliable plan to follow. After years of trial and error and watching some truly remarkable managers, here’s the playbook I’ve created.

Six Steps to Navigating Difficult Conversations Whether your first difficult conversation is in the future or you’ve been handling them badly for months, have the courage to go through the process whenever it presents itself. I guarantee you, in most cases, the outcome won’t be as bad as you think it will be.

Step One: Notice the Signals that Say: “Time for a Difficult Conversation!” When you’re having conflict with someone, you can feel the frustration all over your body. Pay attention to the pit in your stomach, clenched fists, or tension headache. They’re a signal that it’s time to clear the air. Sometimes, the signal isn’t a feeling. You might hear yourself say things like: • This always happens... • He never gets this right... • Not again... Whatever your particular trigger, know it well and use it as a flag to take action instead of burying your head in the sand.

Step Two: Don’t Fume. Commit to Take Constructive Action. Avoiding action will only create resentment. Choose a time in the immediate future where you can discuss the problem with this person so you can both move forward.

Step Three: Make a Plan. If you’re on the verge of losing your temper, go for a walk or take some deep breaths. This is not a time to prepare an exact script or build a bullet-point

PragPub December 2014 12 litany against this person, it’s just time to zero in on the core of the problem and possible solutions. Let off a little steam, talk out loud to yourself (in private!), or sketch out your opening line (see below), but don’t burn a lot of time on this point. Move forward.

Step Four: Have the Meeting in Private — Soon. Yes, this is uncomfortable for the team member, but talking to them one on one will provide a calmer environment, remove the possibility of distractions, and keep eavesdroppers out of earshot. And if they do have that sinking feeling as they follow you to your office for a private conference, that’s okay. It’s an honest, nearly unavoidable reaction. This is a matter that needs attention, and they will know that immediately.

Step 5: Be Steady and On Point. This is not the time to pull out every infraction from the past six months or be so vague about the problem that your team member has no idea what problem you’re actually discussing. Don’t yell. Don’t repeat yourself. Don’t bombard them with information in the hopes of making your criticism more valid. Venting your anger isn’t productive, so stay focused on the outcome you really want from the discussion. Using a single framing sentence usually makes things crystal clear. I like to use the word “disappointed” in these discussions. It’s a subtle way of telling this person that I do hold them in high esteem, and this incident doesn’t match that overall impression. Here’s one of my favorite go-to scripts in these tense situations: John, I was really disappointed when X happened. I want to understand why and find out what we can do to make sure it doesn’t happen again.

Step 6: Shut up. Listen. Then Listen Some More. Silence can be a very powerful tool in these situations. While it can be excruciating to let empty space hang out there, do it. Drink some coffee or count to 10, but let the other person have some time to collect their thoughts or get past an emotional moment. When your team member does respond, resist the temptation to refute what they’re saying or meet their defensiveness (which is completely understandable) with defensiveness of your own. Be willing to take the blame for any mistakes on your part and circle around to the solution. Always focus on the solution. While anticipating these difficult conversations is never a picnic, each time you move past the fear and choose to get through them, you develop more experience, more perspective, and more confidence.

PragPub December 2014 13 Even better, you are able to improve communication within your team, making your job even easier. One day, you may even find a team member knocking on your door saying: Can we talk? I screwed up and I want to make sure it doesn’t happen again.

About the Author Nearly 20 years ago I made the leap from senior-level hacker to full-on tech lead. Practically overnight I went from writing code to being in charge of actual human beings.

Without training or guidance, I suddenly had to deliver entire products on time and under budget, hit huge company goals, and do it all with a smile on my face. I share what I’ve learned here [U2].

External resources referenced in this article:

[U1] http://www.marcusblankenship.com/blog/2014/08/14/lead-from-the-podium/

[U2] http://marcusblankenship.com

PragPub December 2014 14 Your Object Model Sucks Resource Oriented Computing Is What Object-oriented programming is one of the watershed developments in Object Oriented Programming Wanted computer science of the last half-century. Appearing first as a concept at to Be Massachusetts Institute of Technology (MIT) in the late 1950s and evolving over a period of 20 years or so, objects first became well known in Alan Kay’s by Ron Hitchens Smalltalk language starting in the late 1970s. Objects were later popularized by C++ and Objective-C and adopted by the masses with Java in the 1990s, The big idea in Object Oriented Programming was followed not long after by C# and other variants. Object-Oriented Programming always messaging, not objects or classes. Resource Oriented Programming gets that right. (now known as OOP) has become so ubiquitous that it’s generally accepted to be The Way It’s Done. There’s nothing wrong with OOP per se. Kay’s design principles are as valid today as ever and objects work well for bundling state and behavior into handy little cohesive chunks that (hopefully) make for easier to read and maintain code. But OO is a language design style. It’s a conceptual pattern that lets you mentally manage code complexity by decomposing it into manageable, easy-to-grasp pieces. But OO is not a solution to every problem. Almost lost in the mists of time is Alan Kay’s regret for coining the term “objects.” An email from Dr. Kay to the Squeak mailing list in 1998 said “The big idea is ‘messaging,’” and went on to say: “The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be.” With a bit of research it’s clear that the OO programming style invented by Kay and others was intended as a step along the path to a grander vision of systems built around message-passing. Objects were just one instance (excuse the pun) of a thing that can exchange messages with other things. In Java/C#/C++/etcetera, we “invoke methods,” but we’re really passing a message to an object when we do so (you may remember your computer science professor mumbling something about that when you were in school). The important idea is the messaging, not the object metaphor. You should really think in terms of “a method of delivering a message to an object” rather than “executing a code method inside an object.” The real problem with objects arises when the object metaphor spreads beyond where it really makes sense. Doing “object persistence” may intuitively seem like a good idea when you’re the one writing the object-oriented code. Or invoking methods on “remote objects.” Or any of the various and sundry other schemes for building a (shudder) object-oriented architecture. A glob of data stored somewhere outside of a running program is not an object, even if it represents the serialized state of a formerly running object. You can’t send a message to that “object” and it will never send a message to you. Sending

PragPub December 2014 15 messages to remote objects makes a bit more sense, but if that object is not in the same runtime environment as the sender, why speak to it in an object-specific dialect? Why does it even need to be an object as long as you can communicate with it? Why not express the message to the remote object with a protocol that’s usable for communicating between any two entities across a network? Does it really matter if the thing on the other end is an object like you? It’s the message exchange that’s really important. Send the message to the remote system with a standard protocol. When you send a message you care about the response, not the details of who or what generated it. Objects are a language-specific construct (specific to a single combination of source file, language, compiler version, and runtime, in fact). They are not a suitable metaphor for building a system architecture around. No database should care which language/version your objects are, or even that you’re using objects at all. Neither should a network service be communicating in terms of serialized objects. This is the worst kind of tight coupling and it makes for systems that are incredibly brittle in the face of change. You want a foundational abstraction that’s more general than objects.

Living In a World of Resources Like it or not, for the vast majority of information systems the data is far more important than the code. This may be a blow to your programmer’s ego but it’s the data (the information in the system) that has value to the business, not your lovingly crafted, exquisitely refined object model. To be honest, the fewer objects you create and the less code you write the more reliable and stable your system will be, and the easier your life (and everyone else’s) will be in the long run. This is not to say that models don’t have their place. Modeling your data well is vitally important and is the foundation upon which any well-designed information system rests. Understanding the data, expressing relationships correctly, and managing it efficiently are all essential to building a successful information system. Where things have gone off the rails in recent years is that we’ve confused object-oriented code designs with data entity designs. It’s generally not a good strategy for an OO coder (who likely doesn’t know much about data modeling) to bang together a domain class model of how he wants to fondle the data in his code, then use a generic object-relational mapping (ORM) framework to squirt out an auto-generated database schema. That puts your long-lived data at the mercy of the relatively short-lived code. To put it bluntly, that is irresponsible system software design. The data will almost certainly outlive the code (and the coders). Computer language fashions come and go, but the core assets of your business, as embodied in your data, change much more slowly. When code fashion moves on and your data model no longer fits the object model expressed in your shiny new code (if there still is one), you will be forced to choose between kludging around the resulting impedance mismatch or tossing it all out and starting again. Your data is not a collection of objects, it’s a collection of resources.

PragPub December 2014 16 Code should adapt to and work with your valuable data resources, not vice versa.

Model Your Stuff as Resources, Not as Objects The resource should be the central metaphor of any information system. The resource abstraction, much like the object class in Java, is the most general way of referring to “something” in a consistent way. In a system with many communicating components — exchanging messages — a simple, non-assumptive abstraction to represent “stuff” (an abstract set of information) is essential. Otherwise, a tangle of dependencies and the resultant complexity quickly gets out of hand, dooming the system to eventual failure. Resources are so generic and so simple to work with that it seems they can’t possibly be useful for your incredibly complicated project with all its complicated, complex complexity. But the truth is that the greater the complexity and the more unique your requirements, the more likely you are to fail if you don’t adhere to a rigorous resource-oriented design. The World Wide Web is, by several orders of magnitude, the most complex software system ever assembled by humans and it’s built entirely on a tiny set of fundamental resource abstractions and protocols. The Web has been running continuously for over two decades now, has never broken, never needed a rewrite and continues to accelerate its growth. Is your project more complicated than the World Wide Web? Didn’t think so. Want to build systems that don’t break, keep running, and scale out indefinitely? Right. The typical lifecycle pattern for large software systems when plotted as a graph exhibits a sawtooth pattern. They grow in size and complexity until they reach a sustainability limit, typically within just a few years. At the breaking point, it becomes more cost effective to throw it all away and start again from scratch than to fix it. But the Web doesn’t display this characteristic. It has grown in size, massively, but not grown appreciably in complexity. There is no foreseeable limit to its scalability and it performs better after 20-odd years of operation than it ever has.

REST Is Just the Beginning Web services built on the principles of Representational State Transfer (REST) have become very popular in recent years. And for good reason. REST’s focus on simplicity and universal abstractions drives out unneeded complexity while preserving the essential message-passing capability. The moniker REST comes from the PhD thesis of Roy Fielding, one of the key creators of the HTTP protocol that underlies the Web. REST is simply applying the proven and standardized design techniques of the Web and HTTP to exchange messages across a network. There’s that idea again: messaging. REST is performing the same basic function as invoking methods on an object, sending a message from a requestor to a responder, but at a more fundamental level of abstraction. REST, via the simple HTTP protocol, completely decouples the two correspondents. They need not be objects of the same kind and version, they need not be objects at all nor implemented using even vaguely similar technologies. Nor do they need to be aware of each other before the instant when a requestor looks up the location

PragPub December 2014 17 of an endpoint by its uniform resource identifier (URI) in order to send a message. All they need to agree on to communicate effectively is the terse vocabulary of the HTTP and DNS protocols. Resources are the bedrock abstraction of REST. Every REST endpoint identifies a resource; message payloads are representations of resource state; and the verbs and headers describe what the resource is, what to do with it, or what was done with it. Simple, no nonsense, and stunningly powerful. By leveraging the same core principals that have made the Web so successful, REST services enjoy the same benefits and resilience in the face of change as does the Web itself. You’re thinking: “Great. REST is awesome for trundling lumps of XML or JSON across the wire. But I still need to un-marshal it into a Java object model so I can work with it, right?” Yeah, that’s one way to go.

It’s Resources All the Way Down Effectively, REST services and their clients are small subsets of the greater Web, so it’s not hard to grasp why they exhibit similar characteristics and benefits to the Web itself. That’s awesome. But the code that sits behind a REST endpoint is a different matter. Right? I can’t make use of resources inside the service implementation. Right? I need code for that. Right? We need to convert those external resources into an object model to do anything useful. Right? Right? Yeah, that’s one way to go. Another is to carry on doing what works so well in the large and apply the same resource model all the way down the software stack. This is called Resource Oriented Computing (ROC) — and it will fundamentally change how you think about software. All you need to do is fundamentally challenge your preconceptions of what “software” really is.

It’s Resources, Not Code, that Matters The big idea behind ROC is that code written in conventional programming languages, OO or otherwise, is just one way of expressing computation and, as it turns out, often not an especially good one. The research team at HP Laboratories (later 1060 Research) that developed ROC set out to discover why large software projects fail so often (according to an IAG study, 68 percent, while a McKinsey report says 17 percent go so badly that they can sink the entire company) and also why seemingly successful systems tend to decay over time and eventually also die. In doing so, they questioned why the most complex software system of them all, the World Wide Web, seemed to be immune to this phenomenon of software senescence. This led them to investigate the essential differences between the Web and traditional software systems. What they found was that the success of the Web boiled down to three primary aspects:

PragPub December 2014 18 • universal, generic resource abstraction • extremely simple communication protocol to exchange resource representations • just-in-time, late binding of URLs to resources The first of these enables messages (representational state transfers) to mean literally anything. The second allows for transport of those messages anywhere whether the nature of the content is understood or not. And the third allows the mapping of a URI (uniform resource identity) to a URL (uniform resource location) to change at any time. That is, a client requesting a resource doesn’t know the actual location until the very last instant, when it resolves the URL.

The Ties that Don’t Bind On the Web, the advantages of just-in-time URL resolution are obvious and well-understood. Late binding allows, for example, moving a website by changing a DNS entry to point to a different physical server. All subsequent requests, because they’re resolved after that point, will be sent to the new location. It also allows major websites to use a single URL, such as http://amazon.com, and to change the URL resolution on the fly on a case-by-case basis. Amazon has thousands of servers and every request is vectored off to one of them according to complex routing algorithms that make sub-millisecond, per-request decisions. But you’re probably thinking to yourself “I use Java because I like static typing and I hate run-time interpreted code because it’s unpredictable and hard to test. That’s why I stopped using Perl.” That’s a legitimate concern, but the truth is that even in a language like Java “late-binding” happens all the time. There is very little conceptual difference between just-in-time class loading and URI resolution. But the dynamic nature of URI late-binding generally bestows more benefits than disadvantages. There are a wealth of fallback resolution strategies that you can employ to satisfy resource requests at run time, either by configuration or with custom algorithms. Most such conditions in a language like Java are fatal and can’t be recovered from. Testing of ROC systems is often much easier than for object-oriented APIs. As discussed below, ROC systems tend to naturally be cohesive, well-encapsulated, and decoupled. This makes it very easy to test the pieces of a system in isolation and to validate that interface contacts are not being violated. It’s also trivially easy to inject mock resources (because of the late-binding of URIs) at testing time.

What About the Graph? At this point you may be asking yourself “But what about the graph of objects I build up, with references and relationships? If resources are just opaque blobs how do I know what refers to what?” At the protocol level it’s true that resources are essentially just cargo. But that doesn’t mean you’re not allowed to look inside. Resource envelopes contain Multipurpose Internet Mail Extensions (MIME)-type information so that interested parties can interpret the resource payload.

PragPub December 2014 19 In REST, the Richardson Maturity Model describes how hypermedia controls embedded within resources can be used to represent relations between resources. These relations can describe a resource graph or other relationships, permanent or transient, that are appropriate to that resource. REST hypermedia is a far more powerful way to express relationships than simple pointer references between objects. For example, a resource may contain links to resource URLs that don’t yet exist. Is that an error? No. Those resources may exist in the future when the client attempts to resolve the links. Or they might be created on the fly (a search result, for example) when requested. In an object graph, references must be to a live object, or null. Hopeful assertions about the future are not allowed in object models.

Look a Little Closer With all this talk of REST and hypermedia, you’re probably still thinking in terms of HTTP services. But the trick of ROC is that HTTP doesn’t need to be a part of the picture. The HTTP address space, though huge, is just one kind of addressable resource space. Resource Oriented Computing abstracts the concepts of spaces and resolution even further, right into the heart of your application. In ROC, your app or service operates on resources and URIs, rather than objects, at the finest level of granularity. Rather than calling a method to produce a result (ignoring the issue of side effects for the moment), you resolve a resource endpoint to obtain a result. In the course of producing that result, the endpoint may fetch other resources (just like a method may call other methods). A big difference between ROC and OO is that in ROC the result is always immutable. When invoking a Java method, in most cases, the processing will be repeated every time it’s called and will compute the same result. In ROC, because the resulting resource is immutable by definition, and the URI is the name of the resource, the resource can safely be cached (keyed by the URI) and need never be computed more than once. And here’s the kicker: that’s true of all resource endpoints, including the ones that may have been resolved in order to produce an aggregate result. When a resource is requested for the first time, perhaps five other resources may be resolved in order to construct that resource. Now, not only is the final result cacheable (because it’s immutable) but so also are the five sub-resources (they’re also immutable). If another resource is then requested that uses three of those five, those three can be fetched cheaply from cache to construct the new aggregate resource (which is then also cached). Unlike caching strategies that are grafted onto large software applications in languages like Java, either by explicit code calls or decorating methods with annotations, caching in ROC is organic to its very nature. It’s not an afterthought or something that must be blended in. It’s just automatically there and it has profound effects on overall system efficiency. In physics terms, a running ROC system naturally seeks its lowest energy state. (This is not just metaphor — it can dramatially reduce actual CPU power consumption as well.)

PragPub December 2014 20 Ignore that Resource Behind the Curtain One of the joys of designing in a resource-oriented way is that you’re allowed to be lazy. And lazy in two wonderful ways. The first is that once you’ve solved a problem in a general way that solution becomes a resource that you can make use of again and again. The second is that you can put off dealing with complexity by simply referring to [some complicated thing] as another resource. You can do this recursively by decomposing [some complicated thing] into a collection of [somewhat less complicated things], pretty much indefinitely, until [some complicated thing] has dissolved into an assortment of simple, cohesive, reusable resources. Sounds a bit like the stated philosophy of object-oriented design, doesn’t it? And don’t forget, all those resources, from the smallest piece up to the big, hairy [some complicated thing] will be cached after they’re first requested. After that, they’re extremely cheap to use again. Once built, an endpoint can be used by any client, faithfully responding to all comers. But more importantly, the uniform interface of that endpoint is always simple, regardless of the complexity of its implementation. The complexity needed to produce that resource is hidden behind the simple uniform interface and is never a concern of the client. With ROC, the same benefits accrue all the way through your application or service. Not only does it yield a more robust and performant solution, the atomization of functionality into well-encapsulated resources tends naturally to result in reusable resource modules that you can call upon for the next project. This creates a virtuous circle where everything gets faster and easier.

Uncoupling The ROC model, resolving URIs rather than calling API methods, yields another underappreciated benefit. ROC systems are not just loosely coupled, they’re completely decoupled. Because the resource and URI abstractions are so simple, no assumptions are ever made about who’s on the other side of the interface. This makes it much easier to mix and match resources to build up systems because they are naturally well encapsulated and resist abstraction leakage. The decoupled nature also means that requestors and responders can evolve independently. As long as the simple interface contract doesn’t change, neither side needs to inform the other when they make internal changes or improvements. It also gives excellent separation of concerns so that, for example, independent teams (or companies) can develop different parts of the system with very little coordination required. The uniform interface is so simple that it’s actually hard to break compatibility. ROC-based systems are far easier to evolve over time. Because the functional pieces tend to self-organize and dependencies are easy to spot and eliminate, the footprint of any given change is usually quite small. In many cases it’s just a matter of adding a few components or shuffling them around a bit to accommodate new requirements. It’s a bit like being a symphony conductor: you make a few changes to the sheet music to change the tune, rather than building entirely new instruments for the orchestra.

PragPub December 2014 21 Protect Yourself from the Future None of us can predict the future, but we can all learn from the past. The evidence is overwhelming that traditional software development techniques are expensive, slow, difficult, and prone to failure. The resulting software systems generally tend to exhibit these same characteristics as well. The resource model supporting the World Wide Web works: it’s simple, it scales, it evolves, and it’s virtually unbreakable. Where do you want to spend your future?

On the Web

• W3C Web standards [U1]

• Fielding REST dissertation [U2]

• Fowler on the RMM [U3]

• NetKernel ROC container [U4]

• OverStory LLP [U5]

About the Author Ron Hitchens is Founder and Principal Consultant at OverStory LLP, a London-based consultancy specializing in architecture, design, and delivery of information systems centered around REST, ROC, and NoSQL/XML databases such as MarkLogic. Ron has over three decades of software industry experience and so has a pretty good idea of what works and what doesn’t.

Ron has been working with Java and JVM languages since 1997. He is a Sun/Oracle Java Champion and JavaOne Rockstar. Ron is the author of Java NIO O’Reilly Media [U6], as well as other books and articles, and has spoken at industry conferences in the United States and Europe.

In 2010, Ron emigrated from sunny California to rainy England and today works with companies in the United Kingdom and worldwide to design and build high-performance, robust systems based on resource-oriented principles, seeking to avoid the dreaded sawtooth. Contact Ron at [email protected].

External resources referenced in this article:

[U1] http://www.w3.org/standards/webarch/

[U2] https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

[U3] http://martinfowler.com/articles/richardsonMaturityModel.html

[U4] http://1060research.com/

[U5] http://overstory.co.uk/home/

[U6] http://shop.oreilly.com/product/9780596002886.do

PragPub December 2014 22 Microservices Is not the Answer Resource Oriented Computing Is What At the end of “Back to the Future” (and confusingly reshot for the beginning Microservices Aspires to Be of “Back to the Future 2”), Marty McFly finds himself in the comfort of his Present after having a reality-shaking experience in the Past. His entire by Brian Sletten worldview has been upended as well as his sense of self and family history. While he returns to his timeline only a few hours after leaving it, in his own Microservices has the right idea. It just doesn’t take context he spent several days in the 1950s. it far enough. After painfully few moments of serenity in the Present, Doc Brown appears suddenly to take Marty and Jennifer back to the Future for new adventures. As they climb awkwardly into the Delorean, Marty expresses concern that there will not be enough road to get the car up to 88 miles per hour. This is his experience with the technology of time travel. He can only barely accept that it is real even after having experienced it firsthand. To the extent he does, however, he has a fairly rigid and simplistic view of how it works. Doc Brown glances at Marty with amusement and says, “Roads? Where we’re going, we don’t need roads!” ...and proceeds to fly away into the future. I am reminded of this scene by the current wave of discussion about Microservices in the Blogosphere, magazine articles, and at various tech conferences. While none of the people who have gotten mileage out of naming and discussing Microservices claim they represent new thinking, those who have been considering these ideas for over a decade feel like well-established thinking has been brought from the Past back to the Future (our Present). Having spent all of this time in our timelines talking about the benefits of this approach, it feels like this new group of advocates has shown up in the Present “only a few hours after leaving it.”

The problem, as I see it, is that proponents of Microservices seem not to be advocating something wonderful in its own right, but are instead reacting to the expensive masses of monolithic, highly coupled code deployed in heavyweight containers. In this, I think that they, like Marty, have an incomplete picture of what could be realized. I am not trivializing these ideas or those who have started to agitate for them. Rather, I am hoping to see the vision expanded upon and more fully pursued. The broader vision I’m talking about is resource-oriented computing. To get a sense of how ROC expands on Microservices, we should first get clear about what people mean by “Microservices.” This architectural pattern represents a collection of key ideas from various technical sources. These include: • REST Interactions

PragPub December 2014 23 • Lightweight Containers • Unix Pipes and Filters • Service-Oriented Architectures • Self-Contained Services • Bounded Contexts • Distributing the Development Let us look at each of these architectural choices individually.

REST Interactions The one experience that everyone has had with resource-oriented systems is the Web. The loosely coupled, hypermedia-driven architecture has evolved over the last 25 years, but it has remained true to its core. It works because of its use of standards that embrace change. Anyone with a domain name can publish identifiers into that domain. The cost of publication and maintenance is low. The representation of the resource is independent of its identity (but is generally HTML). The means of production are basically irrelevant and put virtually no burden upon the clients (unless you pick a technology that requires plug-ins or bleeding-edge browsers). This ecosystem flourishes even as various technologies, browsers, and content-management mechanisms come into and out of fashion. By moving away from thinking only about documents, we can start to imagine information-sharing systems that exhibit the same scalability and flexibility. REST, as an architectural style embracing these ideas, defines a naming scheme (URIs, URLs, and URNs), a means of interaction (semantically-constrained HTTP methods), and a representation mechanism where the server can inform the client what its options or affordances are. The combination of these approaches yields the properties that we see on the Web. They were always intended to solve problems within organizations as well, not simply on public-facing systems. Microservices do not require the use of HTTP and REST APIs, but that is generally how they are defined in order to achieve the loose coupling, scalability, and evolvability of the Web.

Lightweight Containers Initially, web servers would serve up static content. This evolved to be dynamically generated content, using Perl and cgi-bin. Eventually, we had a variety of options including Tomcat, Resin, and then full-blown J2EE containers like WebLogic, WebSphere, etc. As we tried to do more and more via the Web, we needed to handle concurrency, transactions, encryption, sessions — the list goes on. We generally thought in terms of applications, not resources. If we needed to manage identity, authentication, and authorization, we would want to put everything behind the same protected curtain. These containers were expensive (if they were commercial) or expensive to maintain (if they were commercial or open source) and we deployed monolithic, tightly coupled systems. If there were individual bugs in one part of the system, we would generally still have

PragPub December 2014 24 to go through painful regression testing of the entire system because we deployed the whole thing every time. Reuse of services across workflows was often not possible because of the heavyweight nature of the containers. In response to this, a whole slew of newer, more lightweight containers were developed. We started to think about deploying individual services in environments like Play, Node.js, the Restlet framework, etc. Because the containers themselves were less burdensome, it was generally easier overall to deploy services one by one. Additionally, the low-ceremony containers affect the individual services less dramatically, which helps increase the potential for reuse in a variety of contexts. By their nature, Microservices require lightweight containers, although there is no particular affinity for specific containers.

Service-Oriented Architectures In an attempt to solve the problem of having to deploy multiple copies of the same code everywhere (a.k.a. “DLL Hell” or “Jar Hell”) and to increase the opportunity for reuse across applications and workflows, our industry adopted a model of shared services in the late 1990s and early 2000s. The goal was to allow clients to discover and use appropriate versions of services through standards like SOAP and XML-RPC. While complicated, contract-based services remained highly coupled and often performed poorly, the idea of decomposing workflows into reusable chunks of business functionality remains a goal of many IT departments and architects. Microservices certainly attempt to continue the spirit of these approaches without the heavyweight infrastructure and tooling that came before. The resource abstraction is a superset of the service abstraction, so that we have a uniform naming and interaction model across documents, data, services, and concepts. So while service decomposition is still a goal, it is only part of a larger picture.

Unix Pipes and Filters Unconstrained architectures give designers complete freedom to build whatever they want. In collaborative or distributed systems, this is less desirable than it sounds. In order to interoperate with the different pieces of the system, you would have to distribute knowledge about what makes each piece different or unique. This, of course, tangles concerns and couples pieces unnecessarily. By putting constraints on how the pieces of the system interact, you are freeing the components from having to know about specific variations. This usually allows for simpler, more reusable, and composable components. The Unix Pipes and Filters system is perhaps the most well-known example of this. By constraining the system to use file abstractions for input and output, each individual element is simple and easy to test. The full set of tools in the Unix ecosystem is a testament to how successful this strategy can be. There are tools for text manipulation, image processing, translation, compression, encryption, digital signatures, etc., which all basically work together. In the microservices space, the constraint is usually the Uniform Interface of the Web. This provides a consistent mechanism for interacting with arbitrary resources.

PragPub December 2014 25 Additionally, it is possible to “wrap” existing resources with calls to other resources, providing means of protection, transformation, etc. See here [U1] for these and other examples of patterns that benefit from a uniform resource interface. There are not necessarily default choices for the response representation from Microservices yet, although there are certainly common hypermedia formats in use. If you are defining a collection of services, it is worth considering a consistent mechanism between services to achieve the kind of pipelining we see with Unix systems. Additionally, if you support content negotiation, it is possible to request the right kind of representation or at least a satisfying form for various pipelined activities.

Self-Contained Services One of the downsides of large, monolithic deployments is that a large dependency tree will cause you no end of strife. If different parts of the code have dependencies on different versions of a standard library, something will need to be refactored — or you should just quit. When building systems and APIs, this dependency weight is called encumbrance and it is a measure of how painful it is to use the thing you are designing. If the encumbrance of an API or system is too high, then it is probably not worth it to use. By interacting in loosely coupled ways, we can drive down the encumbrance (and thus the cost of integration) of an API. If the service manages its own dependencies, then the client does not also have to pay for the encumbrance. This increases the opportunity for reuse in different workflows and applications.

Bounded Contexts One of the ideas that Microservices takes from Domain-Driven Design (DDD) is the idea of Bounded Contexts. This is an acknowledgement that not every piece of a system needs the same data and behavior from domain objects. Accounts and orders are connected but each might mean different things to customer management, order fulfillment, marketing, finance, channel partners, etc. Trying to plug the needs of all of these different contexts into a single domain model is likely to complicate the uses and pollute the interfaces. The main issue here is that, as a client, contexts that you do not care about might force changes to the API or domain model you are using. This can obviously have impacts upon your integration costs, releases, etc. By defining a Bounded Context, each specific collection of users is connected by their interchange needs but those details do not leak into other uses.

Distributing the Development One of the more tangible results of monolithic systems is that the cognitive burden to understand them is huge. It makes it difficult to bring people onto a team and also complicates the distribution of work. Interrelated code and layers makes it easy for different groups working in close proximity in the source code to step on each other. This, in turn, complicates the check-in, testing, and release processes.

PragPub December 2014 26 One of the goals of the Microservices initiative is to reduce the scope of what anyone has to work with at any given time. The focus is on doing one or more tightly defined activities with well-established inputs and outputs. The testing scope is well defined and easy to replicate. Smaller services that are self-contained are easier to learn and maintain and are much less likely to interfere with other activities. Not only does this reduce the cost of development in terms of time to merge, but also allows greater parallelization of development, which can increase the velocity of a team.

ROC and NetKernel Now that we have established what Microservices are generally thought to be, you might ask why I imply they are not fundamental enough or do not go far enough. All of the architectural, deployment, productivity, and limited visibility arguments are great and valid and valuable. The main issue is that the resource abstraction is generally considered as a temporarily valuable handle to mediate the interaction between a client and a service in what might be radically different contexts. The client sends or receives a representation, converting to or from object or data structure form as needed, and then goes about its business. It isn’t that we do not derive benefit from this short-lived exchange; it may just be that we do not derive enough. If the objects being exchanged are rigid and tied tightly to the domain model, then the benefits of loose coupling may be lost. If the client is making service invocations as if the service were colocated in the same memory space, or the interactions are such that we need to round trip the object to and from the serialized form frequently, then the performance will suffer because of the cost of the abstraction. If we are attempting to allow reuse across a variety of applications and workflows, then we may need to pass too much state in to define the context for a particular interaction (thus complicating the API and reducing its chance for reuse). If we are mixing and matching synchronous and asynchronous models or other mismatched forms of concurrency, then we may lack adequate infrastructure to protect the backend resources. If the services require transactional properties, then we will need to enforce them somehow, again likely modifying the interface or forcing us to deploy the services into the same container. Fundamentally, the main shortcoming of the decontextualized microservice is that distributed state and identity are really hard problems to solve. By not committing to the resource abstraction in a broader context, we introduce all manner of structural, procedural, and performance impedances that may outweigh some of the purported benefits of the approach. Although the Microservice community understands the benefits of resource abstractions, they just do not hold onto the abstraction long enough. They think in terms of code on the client side and immediately shift back to thinking about the code on the server side after passing through the request handler. They don’t go the full resource-oriented route. NetKernel is a wholly resource-oriented environment. While it is easy to map resource identifiers to Object-Oriented, Functional, Scripted, or Procedural implementations, sticking with the resource abstraction yields powerful and surprising benefits. Where most RESTful or resource-oriented environments only look that way from the outside (via HTTP requests), internally everything

PragPub December 2014 27 in NetKernel is URI-addressable and resource-oriented. At its core, NetKernel is simply a resource-oriented microkernel that satisfies requests in a given context. That does not sound overly exciting or powerful, but it ends up being both. Let’s see how by starting with what we already know.

ROC in Practice Consider a Web request. The host name of the URL is resolved within the global DNS context. Then, a request is made to an appropriate port using an appropriate protocol (usually 80 and HTTP). The handler on the port reacts to the request and indicates success or failure in the response. The whole power of the Web and REST is wrapped up in this pattern.

The semantics of the GET request (safe, idempotent), combined with a logically named and stateless request, induce the properties of caching. If we have already retrieved a resource that has not changed, we do not need to do so again. This subverts the always-present latency penalty in distributed systems. Metadata about the request carried as cookies, headers, or query parameters can be used to identify the user and compare against an authentication and authorization model. The server can determine whether you are allowed to issue this request at all, at a particular time, from a particular application context, etc. Because we are issuing a request to a logical identifier, rather than mapping directly to the origin server, we can introduce a load balancer as the intermediary that responds to the request first before rescheduling the request on an arbitrary backend server. The client knows nothing about this change but the system can now scale horizontally by throwing more machines at it behind the scenes. If the client knew too many details about the resolved handler, this would not work. But, logical, stateless requests make it happen.

Now imagine the ability to request a file: res:/etc/Config.xml.

If this were like the Web, issuing the equivalent of a GET request to this resource (in NetKernel that is a SOURCE request) could return the file. By default, it might come back as an InputStream. But, as a resource-oriented environment, I could instead ask for it as a String or a byte array or any other kind of form that makes sense and we will do the equivalent of content negotiation to get it to me in the form that I want. Trying to do that with code-oriented thinking would require all kinds of gymnastics to allow for the variations in form that we might request. NetKernel is not alone with this kind of capability. The Restlet framework provides both client and server-side support that allows you to issue GET requests to a URI and request a specific form in the response. Where it can do the conversion for you, it will. But what if we issue that request within a different context, not the single value context (like DNS and the Web) that points to a file on disk, but instead one that intercepts the request and reroutes it to some Groovy code that queries a relational database, gathers the results, and emits what looks like an XML file in response. Our code issuing the request is none the wiser, nor should it be. All it knows it that it needs a configuration. How it is generated is irrelevant. This is part of the freedom and the flexibility of the Web. We want

PragPub December 2014 28 headlines or sports scores or social networking interactions, we do not generally care how they are produced. This limits our visibility and reduces our risk of being negatively affected by changes in the implemented code. Something else is going on, however. If the first request, the one that resolves to the file, happens again and the file has not changed on disk, it would be a waste to reread the data from the disk again. If we can uniquely identify the requested resource and attach some metadata to the response, then we can store the result in some kind of a cache. A subsequent request would see if the resource response was in the cache, check its metadata against the file on disk, and then return the cached result if nothing had changed. If the cache starts to get too full, we can check to see how long ago the resources were requested and casually eject things that were not currently being sought.

If one piece of code requests the configuration file as a String, but another piece of code wants it as a parsed DOM object, we do not find it in that form in the cache, but we also do not have to reread the file in from the disk. All that needs to be done is to put it in the requested form by parsing the existing String instance. Now, the DOM instance can also be cached as well as the String. If the file on disk changes, both forms would be ejected, but until then, there is no need to if this is a commonly requested resource. If only the first request wanted it as a String but later we only gets requests for the DOM object, then we can start to reject the more infrequently requested form in favor of the more popular form. The caching system responds to runtime activity to optimize the use of the finite resources of the cache. It certainly would be possible to hand-tune most flexible caching systems to behave this way. The difference is that we would have to anticipate correctly what was most important to put in the cache, whereas here, with the Uniform Interface of a resource-oriented system, there is nothing overly special about our file on the disk. The exact same scenario could happen with our alternate resource resolution involving Groovy and a relational database. The Groovy script is stored on disk. It is a resource that can be cached, as can its higher order form of compiled bytecode. Compilation is simply a form of content negotiation in this environment! The Groovy bytecode is executed to read in a SQL file (also cacheable from disk) that executes the query against the relational database. As we cross outside the boundary of the NetKernel runtime, we will need some kind of signaling mechanism to indicate when the table data has changed, but this is a relatively straightforward problem outside the scope of this immediate discussion. Accept for now that it is possible and not a significant complication to the caching strategy. With the response from the query cached, we process the result set into our XML form and return a String, a DOM or whatever else form the client requested. We need not be aware of the specialized content negotiation. Ultimately, the request for the resource is also cacheable in any of the forms as long as the metadata attached to the response indicates that it is all still valid. This is a simple and trivial example of how bringing ideas from the Web into a software execution environment can yield many of the same benefits we see between systems. But, as we learn to apply these ideas to ever more functionality, we see that systems begin to self-optimize while simultaneously

PragPub December 2014 29 remaining loosely coupled. Because of the Uniform Interface of the resource-oriented system, many of these properties will emerge automatically. Some integration efforts, data formats, etc. will take special planning, but the return on investment remains high across the board.

ROC: Benefits As NetKernel is resolving these requests to arbitrary resources (all using the same mechanism), it must attach the handling to computational resources, in this case threads allocated for use by the microkernel. Because all of the requests are issued to logical, stateless resource identifiers, it can act like our aforementioned load balancer. Extra CPUs become like extra backend servers. The client knows nothing about them, but controlling the resolution context allows us to transparently take advantage of extra resources. Multi-core concurrency is available even for code not explicitly written to support it because of the loose coupling between the layers and how requests are handled. All of this would fall apart if we suddenly have to start caring about the particular implementation details of different pieces of code. If we are maintaining state in objects and then having to protect concurrent access to it or worry about the differences between language A and language B, or different synchronous or asynchronous processing models, or whatever else manifests itself in code, then none of this would be possible. As we said earlier, completely unconstrained architectures give you complete freedom, but mediating those differences tends to spread the knowledge in too many places. By adopting constraints similar to the Web as well as the Unix Pipes and Filters model, NetKernel allows you to build systems that scale and combine in powerful ways. This is one reason that assembling systems as the combination of resources rather than explicitly interconnected code makes all the sense in the world. Surprisingly, as powerful of a picture as we have painted so far, it is but a fraction of what is possible. Architectural patterns for scale, protection, transformation, distribution, etc. fall out of the resource abstraction being adopted completely. Metadata about requests can be captured at the edge and follow the request as we cross internal boundaries within and without the same memory contexts. If we treat configuration of workflows, state machines, and rules engines as resources, then the entire behavioral handling of a system can change at a moment’s notice when the configured resource is modified. At the end of the day, all of the design goals of Microservices have been designed into the NetKernel environment for a decade. Modules expose URIs that are mapped to some form of handling by arbitrary implementations (clients have no visibility into this process). Modules are self-contained and manage their own dependencies. Clients can discover what services are available as resources and pick the appropriate versions to use. Teams are able to break up a complicated system into smaller, tightly focused reusable pieces. Assembling the results into powerful systems is more about coordinating between resources and less about writing large amounts of code.

PragPub December 2014 30 So while all of the structural and architectural and development and deployment goals of Microservices are met by this resource-oriented environment, this is simply the beginning. The runtime environment that embraces the resource abstraction takes it from there.

Microservices vs. ROC: Summary These advanced ideas are where Microservices come up short. Their advocates have seen the power and the mystery of the Web, but they maintain a fairly rigid notion of what that means and what it entails. A thin resource abstraction over code consumed from other code is only a very small part of the story. Like Marty’s notion of time travel, they kind of get it, but not entirely. The cost of the abstraction is amplified in the transition from resource abstraction to code and back again. If we are issuing requests repetitively or as part of an orchestration of resources, then things get even worse as we lose the ability to cache partial results of the highest order form (effectively automatically). It would have been impossible to intentionally design the public Web we have today, yet it is one of the most valuable, powerful, and crucial systems ever built by humanity. Its properties emerged from a combination of architectural choices over time. These choices highlight loose coupling, Uniform Interfaces, and emergent properties that optimize for the nature of the data and how it is used in real, live communication interactions. The only way this works is because the individual pieces have a consistent way of looking at things: logically identified resources. What we attempt to build within organizations is not likely to approach the success, complexity, or scale of the Web. However, the tools we choose to use can greatly enhance or impede our chances of success. There is a lot of really good thinking that has gone into the identification of the Microservices pattern, but it does not respect the resource abstraction fully and cares too much about code. All of the individual choices and goals to minimize coupling, encumbrance, leaking of details between contexts, etc. are useful. But you will not get the Web by simply assembling standalone, single-purpose, and individually deployed services. You need a comprehensive vision and an ecosystem that operates with the same technical and economic principles that made the Web so successful. As it turns out, we can look over ten years into the Past to find such an environment being used to bring us back to the Future. “Code? Where we’re going, we don’t need code.” —Doc Rodgers (One of the creators of the NetKernel environment is Dr. Peter Rodgers.)

About the Author Brian Sletten is a liberal arts-educated software engineer with a focus on forward-leaning technologies. His experience has spanned many industries including retail, banking, online games, defense, finance, hospitality, and health care. He has a B.S. in Computer Science from the College of William and Mary and lives in Auburn, CA. He focuses on web architecture, resource-oriented computing, social networking, the Semantic Web, data science, scalable systems, security consulting, and other technologies of the late 20th and early 21st Centuries. He is also a rabid reader, devoted foodie, and has excellent taste in music. If pressed, he might

PragPub December 2014 31 tell you about his International Pop Recording career. He is also one of SemanticWeb.com’s “Top 100 Semantic Web People.”

External resources referenced in this article:

[U1] http://www.amazon.com/Resource-Oriented-Architecture-Patterns-Synthesis- Lectures/dp/1608459500

PragPub December 2014 32 Introducing Resource Oriented Computing It’s All About Messages Twenty-five years ago Tim Berners-Lee invented the World Wide Web. His vision wasn’t the most beautiful of the available options, but it prevailed by Tom Geudens because it allowed everybody to join in, scaled extraordinarily well, and maintained a high level of reuse. There has been nothing invented nor There’s a program that’s been running for 25 years, discovered in the Information Technology realm in the last 25 years that has that scales like nobody’s business, and that’s based on open protocols. Can your code measure up to done equally well. that? The Web is simply the most successful software project ever.

It probably has something to teach us. That was the thinking when, fifteen years ago, a research team at Hewlett-Packard Labs started to investigate the properties of the World Wide Web. Out of this research, continued by 1060 Research Ltd., came Resource Oriented Computing (ROC), a way of applying the properties of the web to software. 1060 Research implemented ROC into their flagship product, NetKernel. Meanwhile, slowly but surely, these ideas about the properties of the web — particularly Representational State Transfer (REST) protocols and more recently “microservices” — have become mainstream and widely embraced. But the full model of Resource Oriented Computing goes beyond these concepts. The goal of this introductory article is to get you started quickly with NetKernel, the 1060 Research implementation of ROC, so you can explore the ROC paradigm. We’ll implement “Hello World” the ROC way and discuss some theory (but not a lot). All you need to bring to the party is an open mind, an operating system (Windows, Linux, Mac OS X) running Java 1.6 or better, NetKernel [U1] downloaded on that system (in a temporary location, you’ll use it to install NetKernel), and basic Java familiarity.

Installation Installing NetKernel is very easy: Position yourself in the directory above the one in which you want to install (for Linux, assuming you want to install in /opt/netkernel, position yourself in /opt; for Windows, assuming you want to install in D:\netkernel, position yourself in D: Then execute the downloaded jar: Linux (by which we mean Linux and OS X at the *nix level):

java -jar [temporary location]/1060-NetKernel-SE-5.2.1.jar

Windows:

PragPub December 2014 33 java -jar [temporary location]\1060-NetKernel-SE-5.2.1.jar

******************************************************************** * JAR BOOT NOTES * ------* NetKernel is now running an HTTP server on port 1060 * * To start using NetKernel open a web browser * and go to: http://localhost:1060/ ********************************************************************

• Point your browser at (you guessed it) http://localhost:1060. • Select “Install NetKernel.”

• Read and accept the 1060 PUBLIC LICENSE v1.2. • Enter the target directory. • Tick “Expand JAR files.” • Enter proxy information if required. While NetKernel does not actually require connectivity, updates and security patches are distributed from a repository, and updating NetKernel is comparable to updating a system with yum or Windows update. • Select “Install.” • You should get a message:

NetKernel was successfully installed onto your filesystem at [installation location]

Point your browser at the shutdown link (http://localhost:1060/tools/shutdown). Allow the jar execution to finish... and congratulations, you’ve installed NetKernel! Starting the freshly installed NetKernel is also very easy: • Position yourself in [installation location]. • cd [installation location] • Run the boot script: Linux:

bin/netkernel.sh

Windows:

bin\netkernel.bat

• Point your browser to http://localhost:1060.

Automation If you’re like me and have a background in System Administration or if you’re into DevOps, you might be interested to hear that the installation can easily

PragPub December 2014 34 be scripted and integrated into Chef / Puppet / Ansible / (take your pick). NetKernel can be run as a service (no superuser required) on both Linux and Windows installations.

Setting Up a Development Environment ROC development is not code-centric. Exactly as it is professed for “microservices,” you write small components that do one thing well and combine them together into a potent whole. A typical module (application) is therefore never very big. While you do have a choice of languages, NetKernel itself is developed in Java, so Java is a logical choice. My personal choice is to use Java to write components and Groovy to combine them. For development I use standard Eclipse. Each NetKernel module is a “Java Project.” I build “in place,” not bothering with src/build subdirectories. The only thing you need in order to write components are the jars in [installation location]/lib in your build path.

Yes, I know. The above does not quite sound like a professional setup. By all means, go with what makes you most productive. I tend to keep it light for development, the reason being that there’s very little code involved anyway. Continuous Integration. Automated build and deploy. Git. Jenkins. Maven. Gradle. All of these are beyond the scope of this article, but rest assured that NetKernel development can be made to work with all of these.

Hello World the ROC Way Everything in ROC revolves around resources and the spaces these resources live in. As an example, the internet is a (not the, just one of many) space, the URLs are resource identifiers. More on that when I go into a bit more theoretical detail. For practical reasons there is a concept of “application,” a module. Important from a Java point of view as this is the level where the classpath plays. Important from a deployment point of view as this is the unit of deployment (either in the form of a directory or a jar).

Every module has a module.xml file in its root. This file describes the resources and spaces in the module. In fact, it is perfectly possible to have a module - with functionality - that only has a module.xml file.

Let’s have a look at the barebones example that we’ll extend in this article:

PragPub December 2014 35 urn:org:tomgeudens:helloworld 1.0.0 tom geudens / hello world tom geudens / hello world urn:org:tomgeudens:helloworld:internal

Yes, it is XML. Don’t run away. While JSON is the — currently — prevailing format for data exchange, XML still rules as far as configuration and description are concerned. The above XML contains some metadata for the module, the tag allows for changes to module.xml to be picked up by the running NetKernel (very useful during development). Last but not least it defines two (root)spaces. The first one is public, which means it can be imported into spaces in other modules. It imports the second space, which is not public, meaning it cannot be imported outside of the module itself. When deploying a module, there are two things that come into play. First is the location where you want the module to reside. NetKernel itself keeps the core modules underneath [installation location]/modules (have a look, you’ll find modules both in jar form and directory form), for this article we’ll use [installation location]/project-modules for our own modules.

For our example:

• create the [installation location]/project-modules directory

• create a directory named [installation location]/project-modules/urn.org.tomgeudens.helloworld-1.0.0

• put the module.xml file in that directory

The second thing is the fact that a module needs to be activated in the running NetKernel instance. In [installation location]/etc/modules.xml you can see how this works for the core modules. You could add our application module in there, but there is a better way:

• create the [installation location]/etc/modules.d directory (if it doesn’t exist yet)

PragPub December 2014 36 • create a tomgeudens.xml in there with the following content:

project-modules/urn.org.tomgeudens.helloworld-1.0.0/

If all goes well you should see the following line in the console output:

I xx:xx:xx ModuleManager Loading tom geudens / hello world v1.0.0

Congratulations. You’ve deployed your first ROC module. It doesn’t do a whole lot yet. Before we address that, a bit of background is in order.

A Bit of Background Resource Oriented Computing isn’t difficult. But — and there’s no way avoiding this — it is different. Quite different from Object Oriented Computing/Programming. Developing a component will typically require less than 200 lines of code ... if any code at all. So, what is it about? In ROC, everything is a resource. You can think of a resource as an addressable bit of information. Resources live in spaces. You can think of a space as a mathematical set or a scope or a context. A resource can be requested with its space as the context. And that’s it, there’s no more. Everything else is derived. Now, when you request a resource, you never get the resource as a result. What you get from a request is a representation of a resource. If you accept that when you point your browser to http://google.com, what you get is not the http://google.com, but a representation of it and that at that same instant thousands of other people also get a representation of http://google.com ... you’ve understood the concept. Pretty boring without seeing it in action, no? Let’s get back to our example module and breathe some life in it.

Fleshing It Out Change the public rootspace in module.xml so it looks like this:

Hello World urn:org:tomgeudens:helloworld:internal

Make sure you deploy this changed module.xml to the [installation location]/project-modules/urn.org.tomgeudens.helloworld-1.0.0 directory. You should see the following in the console output:

PragPub December 2014 37 I xx:xx:xx ModuleManager Unloading tom geudens / hello world v1.0.0 I xx:xx:xx ModuleManager Loading tom geudens / hello world v1.0.0

How’s that for hot deploy? This is where the tag comes in useful during development. We have now created a resource and its identifier is res:/tomgeudens/helloworld-literal. However, since we haven’t exposed it to the outside world yet, it is only available inside its space in the NetKernel instance. Not to worry though, we can take a look in there. • point your browser to http://localhost:1060/tools/requesttrace • select the module in the module pulldown • select the space in the space pulldown • enter the identifier

• select 'Resolve’

The request trace tool allows you to split up the request resolution and the actual request. This is extremely useful during development and troubleshooting. Request resolution is very much like DNS resolution: it takes the logical identifier and tries to find the endpoint that can provide the physical representation. We’ve set the public space as the context here and ... no surprise ... it has a match. Try the same with the private space.

• Select 'Execute’ (Response)

PragPub December 2014 38 As you can see, a request response contains a bit more than just the resource representation. Most of the time you’ll just work with the representation though.

• Select 'Execute’ (Representation)

A working Hello World! You may have noticed the expiry determinants when we asked for the request response. NetKernel offers superior (patented) caching. I say offers, but even out of the box it does a very good job. Requests in an application typically follow a distribution. Anybody who’s looked at what gets requested on a website will know that some parts get requested all the time while some pages never get any attention at all. On a commercial product website this distribution may shift quickly (depending on weather, trend, event, release, sale, ... ), but there still is a distribution at a given time. NetKernel automatically keeps the hot spot of the distribution in cache. And it follows shifts in the distribution automatically.

Writing Some Code If you haven’t created the module in your IDE yet, this may be the time to do so. I named mine urn.org.tomgeudens.helloworld, the module.xml file is in the root of that. As stated earlier, you need the jars from [installation location]/lib in your build path (you don’t need to deploy them by the way, they are part of the NetKernel instance).

Add the following to the public rootspace in module.xml (between literal and import) :

tomgeudens:helloworld:accessor org.tomgeudens.helloworld.HelloWorldAccessor res:/tomgeudens/helloworld-accessor

• Create a package in the root of the module directory : org.tomgeudens.helloworld

• Create a class in that package : HelloWorldAccessor.java

PragPub December 2014 39 Here are the contents of that class:

package org.tomgeudens.helloworld; /** * * Hello World. * * @author Tom Geudens. 2014/10/11. * */ /** * Accessor Imports. */ import org.netkernel.layer0.nkf.*; //import org.netkernel.layer0.meta.impl.SourcedArgumentMetaImpl; import org.netkernel.module.standard.endpoint.StandardAccessorImpl; /** * * Hello World Accessor. * */ public class HelloWorldAccessor extends StandardAccessorImpl { public HelloWorldAccessor() { this.declareThreadSafe(); this.declareSourceRepresentation(String.class); } public void onSource(INKFRequestContext aContext) throws Exception { aContext.createResponseFrom("Hello World"); } }

Deploy the module to the [installation location]/project-modules/urn.org.tomgeudens.helloworld-1.0.0 directory. Again you should see the messages in the console output.

Remember where you can check to see if it works? Exactly, in the Request Trace Tool. You now have two resource identifiers to try out:

res:/tomgeudens/helloworld-literal res:/tomgeudens/helloworld-accessor

Did you notice the difference when doing Resolve on the second one?

PragPub December 2014 40 In the space resolution is top-down. The first physical endpoint that can satisfy the request gets it. There’s more than one way to skin an Ouphe. If you know what an Ouphe is you’ve been playing Magic The Gathering for too long, but that’s a topic for another magazine. I wanted to show a third way to accomplish our goal:

Add the following to the public rootspace (you know the drill by now) between accessor and import:

res:/tomgeudens/helloworld-data data:text/plain,Hello World

In order for this to work you also need to add something to the internal rootspace which should then look like this:

urn:org:netkernel:ext:layer1

As you can see, we map a third resource identifier (res:/tomgeudens/helloworld-data) to another resource identifier (data:text/plain,Hello World). The data: scheme is made available in one of NetKernel’s many toolkits. Which we need to import in order to use it. Deploy. In the Request Trace Tool, for the public space, you can now try:

res:/tomgeudens/helloworld-literal res:/tomgeudens/helloworld-accessor res:/tomgeudens/helloworld-data

For the private space you can experiment with the data: scheme:

data:text/plain,Something Else

I can think of at least 10 more completely different ways to accomplish the same thing. You could get the text from a file, either with a fileset endpoint from within the module structure itself or with the file:/scheme (same import

required). You could use a freemaker [U2]) template and make it a bit more dynamic (freemarker is available as an import too), you could ...

PragPub December 2014 41 Unit Testing (and Documentation, and Logging) Testing is important. And if you want to follow a test-driven approach to do ROC development, you can, most certainly. Your components, however, are going to be small, and most ROC developers have a more relaxed approach to testing. Having said that, there is an ROC testing framework that comes with NetKernel and you can find it by pointing your browser at http://localhost:1060/test/. More information about how to add testing to your modules can be found at http://localhost:1060/book/view/book:mod:test:book/. Yes! NetKernel comes with its own ROC documentation framework too and you can easily add your documentation in there too. Another common topic is logging. Documentation for that can be found at http://localhost:1060/book/view/book:guide:physicalreference/doc:physicalreference:logging.

Making It Available Before I move to the conclusion of this article, we want to make one more change to our example module. Having all the resources inside NetKernel is nice, but no system stands alone and, of course, NetKernel is no exception. It has outward facing modules (called transports) that can bring requests in and carry results out. In fact, the management interface at http://localhost:1060 is just such a transport — it consists of a Jetty webserver that brings requests inside (and shows the results in your browser). By default, there’s a second Jetty webserver that runs on port 8080 where you can host your applications.

How? Easy. Add the following right at the top of the public rootspace:

HTTPFulcrum

It’s beyond the scope of this article to explain what this endpoint accomplishes, but deploy again and you should be able to point your browser to:

http://localhost:8080/tomgeudens/helloworld-literal http://localhost:8080/tomgeudens/helloworld-accessor http://localhost:8080/tomgeudens/helloworld-data

You now know how to set up NetKernel and build a Hello World application with it. You’ve soaked up a bit of ROC theory, which may have whetted your appetite for more of this Resource Oriented Computing stuff. And you’re now prepared to truly grok the rest of the ROC articles in this issue.

Source code can be found here [U3].

About the Author Tom is a consultant for all things ROC and Cloud Computing. He has more than twenty years of experience in IT, is the author of the O’Reilly book Resource Oriented Computing with NetKernel, and lives near Brussels, Belgium. Everything else you want to know about him can be found here [U4]. He also blogs about ROC and NetKernel here [U5].

External resources referenced in this article:

[U1] http://apposite.netkernel.org/dist/1060-NetKernel-SE/1060-NetKernel-SE-5.2.1.jar

[U2] http://freemarker.org/

PragPub December 2014 42 [U3] https://github.com/elephantbirdconsulting/netkernel-contribution/

[U4] http://netkernelbook.org

[U5] http://practical-netkernel.blogspot.com

PragPub December 2014 43 The Evolution of C The PragPub History of Programming Dennis Ritchie was born in December 1941, in Bronxville, New York. He Languages Series received his undergraduate and graduate degrees in Physics and Applied Mathematics, respectively, from Harvard University. His doctoral thesis was by Dan Wohlbruck subrecursive hierarchies of functions. He said about himself: “My undergraduate experience convinced me that I was not smart enough to be a physicist, and Dan continues his series on the history of that computers were quite neat. My graduate school experience convinced me programming languages with more on C. that I was not smart enough to be an expert in the theory of algorithms and also that I liked procedural languages better than functional ones.”

“Early in the development of Unix,” he said, “I added data types and new syntax to (Ken) Thompson’s B language, thus producing the new language, C. C was the foundation for the portability of Unix, but it has become widely used in other contexts as well; much application and system development for computers of all sizes, from hand-held to supercomputer, uses it. There are unified United States and international standards for the language, and it is the basis for (Bjarne) Stroustrup’s work on its descendant C++.” Not to mention Objective-C and other descendants. Dennis Ritchie’s innovation was the C programming language. His inspiration was making it portable. Bell Labs didn’t make computers and neither Thompson nor Ritchie had anything to gain by making Unix and C proprietary systems. Despite this, portability wasn’t their first concern. Consider what it would be like if we established our first colony on the moon. After making the colony habitable, the colonists will want to make it as much like home as they can. Upon leaving the Multics project, Thompson, Ritchie, Brian Kernighan, and a few others wanted to make their environment at Bell Labs as much like home as they could. Unix began as a method to improve the Lab’s computing environment. Dennis Ritchie had written a C programming reference manual before The C Programming Language book came out. (This is the famous “K & R” manuscript written by Brian Kernighan and Dennis Ritchie that everyone refers to as the white book.) He categorized his language into the following sections: • Lexical conventions: identifiers, keywords, constants, strings, expression operators, types, and other separators. • Types: Integer, Character, Floating, and String. • Objects and lvalues: An object is a manipulatable region of storage; an lvalue is an expression referring to an object.

PragPub December 2014 44 • Conversions: A number of operators may, depending on their operands, cause conversion of the value of an operand from one type to another. • Expressions: Primary expressions, Unary operators, Multiplicative operators, Additive operators, Shift operators, Relational operators, Equality operators, and Assignment operators. • Declarations: Used within function definitions to specify the interpretation which C gives to each identifier. • Statements: Expression, Compound, Conditional, While, Do, For, Switch, Break, Continue, Return, and Goto. • Lexical scope: The lexical scope of names declared at the head of functions (either as formal parameters or in the declarations heading the statements constituting the function itself) is the body of the function. • Collection of Types: Structures, Functions, Arrays, and Pointers. When asked about the most valuable feature of the C language, Brian Kernighan said: “C is the best balance I’ve ever seen between power and expressiveness. You can do almost anything you want to do by programming fairly straightforwardly and you will have a very good mental model of what’s going to happen on the machine; you can predict reasonably well how quickly it’s going to run, you understand what’s going on, and it gives you complete freedom to do whatever you want.” “C doesn’t put constraints in your way, and it doesn’t force you into using a particular programming style; on the other hand, it doesn’t provide lots and lots of facilities, and it doesn’t have an enormous library. But in terms of getting something done with not too much effort, I haven’t seen anything to this day that I like better. There are other languages that are nice for certain kinds of applications, but if I were stuck on a desert island with only one compiler I’d want a C compiler.” At the second History of Programming Languages conference held in Cambridge in April 1993, Ritchie described a moment in the development of the C language: “After creating the type system, the associated syntax, and the compiler for the new language, I felt that it deserved a new name; NB (for New B) seemed insufficiently distinctive. I decided to follow the single letter style and called it C, leaving open the question whether the name represented a progression through the alphabet or through the letters in BCPL.” C is a typed language. In language design, types are classes which define values. For instance, the classification of one variable as an integer and another variable as a string are examples of types. Ritchie describes how C progressed: “During 1973 through 1980, the language grew a bit: the type structure gained unsigned, long, union, and enumeration types, and structures became nearly first class objects (lacking only a notation for literals). Equally important developments appeared in its environment and the accompanying technology. Writing the Unix kernel in C had given us enough confidence in the language’s usefulness and efficiency that we began to recode the system’s utilities and tools as well, and then to move the most interesting among them to the other platforms.

PragPub December 2014 45 “We discovered that the hardest problems in propagating Unix tools lay not in the interaction of the C language with new hardware, but in adapting to the existing software of other operating systems. Thus Steve Johnson began to work on pcc, a C compiler intended to be easy to retarget to new machines, while he, Thompson, and I began to move the Unix system itself to the Interdata 8/32 computer. The language changes during this period, especially around 1977, were largely focused on considerations of portability and type safety, in an effort to cope with the problems we foresaw and observed in moving a considerable body of code to the new Interdata platform." As C became more widely used and better understood, there were some who believed that it could be made better. By the 1980s, a study by Bloor Research concluded that for a given software project, 11 percent of the project’s cost was spent on the requirements and design phase, 22 percent of the cost on programming and testing, and 67 percent was spent on software maintenance. The software industry had evolved from allowing a programmer unfettered creativity, to something called structured programming, and moved on to object-oriented software development; all with the idea of making software more reliable. It was a happy coincidence that object-oriented software design (OOD) and the Simula 67 programming language both relied on something called a class to collect objects. Simula used classes for the purpose of simulating events while OOD used them for representing the actions of objects. It was a happy coincidence because in April 1979, Bjarne Stroustrup, who was then working at the Computing Science Research Center of Bell Laboratories in Murray Hill, New Jersey, began a project to analyze the Unix kernel to determine to what extent it could be distributed over a network of computers. Stroustrup had used Simula at the University of Aarhus, Denmark, before going to work for Bell Labs and he decided that the C programming language could be extended with classes to help him with his project. By October 1979, Stroustrup had written a pre-processor for C to support what he called C with Classes. Stroustrup wrote an essay titled A History of C++: 1979-1991, in which he described the transition from C with Classes: “During the April to October (1980) period, the transition from thinking about a tool to thinking about a language had occurred, but C with Classes was still thought of primarily as an extension to C for expressing modularity and concurrency. A crucial decision had been made, though. Even though support of concurrency and Simula-style simulations was a primary aim of C with Classes, the language contained no primitives for expressing concurrency; rather, a combination of inheritance (class hierarchies) and the ability to define class member functions with special meanings recognized by the pre-processor was used to write the library that supported the desired styles of concurrency. Thus, the language provided general mechanisms for organizing programs rather than support for specific application areas. This was what made C with Classes and later C++ a general-purpose language rather than a C variant with extensions to support specialized applications.” In the same essay, Stroustrup talked about classes: “Clearly, the most important aspect of C with Classes — and later of C++ — was the class concept. A class is a user-defined data type. A class specifies the type of the class members that

PragPub December 2014 46 define the representation of a variable of the type (an object of the class), specifies the set of operations (functions) that manipulate such objects, and specifies the access users have to these members.” He summarized C++ this way: “In other words, C++ made object-oriented programming and data abstraction cheap and accessible.” Ritchie and Stroustrup were collaborators — not competitors. First the C programming language and, in its turn, C++, were adopted by the American National Standards Institute (ANSI) with standard compiler specifications and libraries. Both languages were essential to the growth of the personal computer and the ability of applications to run on multiple machines. Dennis Ritchie has been given the Turing Award (with Ken Thompson) and the National Medal of Technology and he continues his work with Bell Labs.

About the Author Dan Wohlbruck has over 30 years of experience with computers, with over 25 years of business and project management experience in the life and health insurance industry. He has written articles for a variety of trade magazines and websites.

PragPub December 2014 47 Antonio on Books Thirty New Books People get their start in programming in all sorts of ways. Some start young, others later in life. As developers there is no denying that the ability to code by Antonio Cangiano transforms your mind and lets you see the world in a different way. It’s true that everyone, regardless of their profession, could benefit from learning to Antonio looks at all the new tech books of note. code. So I applaud every effort in that direction, particularly those that are Antonio Cangiano is the author of the excellent aimed at kids. Technical Blogging [U1] and you can subscribe to his reports on new books in technology and other fields This month’s pick for me is a “For Dummies” book. That doesn’t happen often. here [U2]. However, this one is a particularly good title by an excellent educator who knows how to appeal to kids and help them learn about programming and the STEM world. True, some kids will steal your copy of K&R while you are not looking and start coding the hard way, but plenty of smart youngsters need a gentler, higher level introduction that quickly shows them why they might want to consider programming in an environment that’s specifically built for them. So if you have a son or a daughter, consider getting them this book. They’ll most likely love it. For the rest of us, shall we say, more grown-up folks, I’d like to mention Lightweight Django. There are relatively few current Django books out there, and this one focuses on modern modular web development in Python (previous experience with Django recommended).

Coding For Kids For Dummies [U3] • By Camille McCue • ISBN: 1118940326 • Publisher: For Dummies • Publication date: November 17, 2014 • Binding: Paperback • Estimated price: $16.44

Advanced Android Application Development (4th Edition) [U4] • By Joseph Annuzzi Jr., Lauren Darcey, Shane Conder • ISBN: 0133892387 • Publisher: Addison-Wesley Professional • Publication date: November 24, 2014 • Binding: Paperback • Estimated price: $45.12

Practical Cryptography: Algorithms and Implementations Using C++ [U5] • By Editors at Auerbach Publications • ISBN: 1482228890 • Publisher: Auerbach Publications • Publication date: November 24, 2014 • Binding: Hardcover • Estimated price: $57.70

How Linux Works: What Every Superuser Should Know [U6] • By Brian Ward • ISBN: 1593275676 • Publisher: No Starch Press • Publication date: November 21, 2014 • Binding: Paperback • Estimated price: $22.91

Alan M. Turing: Centenary Edition [U7] • By Sara Turing • ISBN: 1107524229 • Publisher: Cambridge University Press • Publication date: November 20, 2014 • Binding: Paperback • Estimated price: $10.90

PragPub December 2014 48 Mastering JavaScript Design Patterns [U8] • By Simon Timms • ISBN: 1783987987 • Publisher: Packt Publishing - ebooks Account • Publication date: November 21, 2014 • Binding: Paperback • Estimated price: $44.99

CSS Animations and Transitions for the Modern Web [U9] • By Steven Bradley • ISBN: 0133980502 • Publisher: Adobe Press • Publication date: November 22, 2014 • Binding: Paperback • Estimated price: $22.10

Introduction to Modern Cryptography, Second Edition [U10] • By Jonathan Katz, Yehuda Lindell • ISBN: 1466570261 • Publisher: Chapman and Hall/CRC • Publication date: November 6, 2014 • Binding: Hardcover • Estimated price: $73.44 The LEGO MINDSTORMS EV3 Idea Book: 181 Simple Machines and Clever Contraptions [U11] • By Yoshihito Isogawa • ISBN: 1593276001 • Publisher: No Starch Press • Publication date: November 21, 2014 • Binding: Paperback • Estimated price: $17.80

Beginning iPhone Development with Swift: Exploring the iOS SDK [U12] • By David Mark, Jack Nutting, Kim Topley, Fredrik Olsson, Jeff LaMarche • ISBN: 1484204107 • Publisher: Apress • Publication date: November 19, 2014 • Binding: Paperback • Estimated price: $30.74

Game Programming Patterns [U13] • By Robert Nystrom • ISBN: 0990582906 • Publisher: Genever Benning • Publication date: November 2, 2014 • Binding: Paperback • Estimated price: $30.63 Make: Getting Started with Raspberry Pi: Electronic Projects with the Low-Cost Pocket-Sized Computer [U14] • By Matt Richardson, Shawn Wallace • ISBN: 1457186128 • Publisher: Maker Media, Inc • Publication date: November 6, 2014 • Binding: Paperback • Estimated price: $12.08

The Art of Game Design: A Book of Lenses, Second Edition [U15] • By Jesse Schell • ISBN: 1466598646 • Publisher: A K Peters/CRC Press • Publication date: November 6, 2014 • Binding: Paperback • Estimated price: $51.76

From Mathematics to Generic Programming [U16] • By Alexander A. Stepanov, Daniel E. Rose • ISBN: 0321942043 • Publisher: Addison-Wesley Professional • Publication date: November 17, 2014 • Binding: Paperback • Estimated price: $28.50 Learn to Program with Minecraft Plugins: Create Flaming Cows in Java Using CanaryMod [U17] • By Andy Hunt • ISBN: 1941222943 • Publisher: Pragmatic Bookshelf • Publication date: November 8, 2014 • Binding: Paperback • Estimated price: $19.36

Java in a Nutshell [U18] • By Benjamin J Evans, David Flanagan • ISBN: 1449370829 • Publisher: O'Reilly Media • Publication date: November 6, 2014 • Binding: Paperback • Estimated price: $34.24

Mastering Machine Learning With scikit-learn [U19] • By Gavin Hackeling • ISBN: 1783988363 • Publisher: Packt Publishing - ebooks Account • Publication date: November 10, 2014 • Binding: Paperback • Estimated price: $40.49

PragPub December 2014 49 Lightweight Django [U20] • By Julia Elman, Mark Lavin • ISBN: 149194594X • Publisher: O'Reilly Media • Publication date: November 13, 2014 • Binding: Paperback • Estimated price: $28.60 Android Security Internals: An In-Depth Guide to Android's Security Architecture

[U21] • By Nikolay Elenkov • ISBN: 1593275811 • Publisher: No Starch Press • Publication date: November 2, 2014 • Binding: Paperback • Estimated price: $28.27

Spring Recipes: A Problem-Solution Approach [U22] • By Daniel Rubio, Josh Long, Gary Mak, Marten Deinum • ISBN: 1430259086 • Publisher: Apress • Publication date: November 4, 2014 • Binding: Paperback • Estimated price: $34.18

The Book of CSS3: A Developer's Guide to the Future of Web Design [U23] • By Peter Gasston • ISBN: 1593275803 • Publisher: No Starch Press • Publication date: November 13, 2014 • Binding: Paperback • Estimated price: $19.69 Building Cross-Platform Apps using Titanium, Alloy, and Appcelerator Cloud Services [U24] • By Aaron Saunders • ISBN: 1118673255 • Publisher: Wiley • Publication date: November 3, 2014 • Binding: Paperback • Estimated price: $26.96 High Performance Parallelism Pearls: Multicore and Many-core Programming Approaches [U25] • By James Reinders, James Jeffers • ISBN: 0128021187 • Publisher: Morgan Kaufmann • Publication date: November 17, 2014 • Binding: Paperback • Estimated price: $75.95

Learning to Program [U26] • By Steven Foote • ISBN: 0789753391 • Publisher: Addison-Wesley Professional • Publication date: November 14, 2014 • Binding: Paperback • Estimated price: $19.62

Advanced Excel Essentials [U27] • By Jordan Goldmeier • ISBN: 1484207351 • Publisher: Apress • Publication date: November 5, 2014 • Binding: Paperback • Estimated price: $31.99

PowerShell in Depth [U28] • By Don Jones, Jeffery Hicks, Richard Siddaway • ISBN: 1617292184 • Publisher: Manning Publications • Publication date: November 14, 2014 • Binding: Paperback • Estimated price: $36.93

Web Development with Django Cookbook [U29] • By Aidas Bendoraitis • ISBN: 178328689X • Publisher: Packt Publishing - ebooks Account • Publication date: November 17, 2014 • Binding: Paperback • Estimated price: $44.99

SVG Essentials [U30] • By J. David Eisenberg, Amelia Bellamy-Royds • ISBN: 1449374352 • Publisher: O'Reilly Media • Publication date: November 3, 2014 • Binding: Paperback • Estimated price: $25.72

SQL Database for Beginners [U31] • By Mr. Martin Holzke, Mr. Tom Stachowitz • ISBN: 099040207X • Publisher: LearnToProgram, Incorporated • Publication date: November 3, 2014 • Binding: Paperback • Estimated price: $21.59

Machine Learning: Hands-On for Developers and Technical Professionals [U32] • By Jason Bell • ISBN: 1118889061 • Publisher: Wiley • Publication date: November 3, 2014 • Binding: Paperback • Estimated price: $38.49

PragPub December 2014 50 Pragmatic Bookstuff Here’s what’s up with the Pragmatic Bookshelf and Here’s what’s happening at Pragmatic Bookshelf. its authors. What’s Hot

1 1 iOS 8 SDK Development

2 8 Seven More Languages in Seven Weeks

3 2 Programming Elixir

4 10 Rails 4 Test Prescriptions

5 NEW Fire in the Valley

6 NEW Pragmatic Unit Testing in Java 8 with JUnit

7 6 Agile Web Development with Rails 4

8 11 Seven Concurrency Models in Seven Weeks

9 NEW Metaprogramming Ruby 2

10 3 Learn to Program with Minecraft Plugins

11 NEW The Nature of Software Development

And here’s what the authors are up to:

Who’s Where When

2014-11-28 Code that fits your brain: This is a talk of how our code should look to fit the way we think, remember and reason. Adam Tornhill CHOOSE Forum 2014, Bern, Switzerland [U1]

2014-12-04 AV Foundation Film School Chris Adamson (author of iOS 8 SDK Development [U2] ) CocoaConf Atlanta [U3]

2014-12-05 I am speaking about GPU Programming and 3D Graphics Mathematics. Janie Clayton (author of iOS 8 SDK Development [U4] ) CocoaConf Atlanta; Atlanta, GA [U5]

2014-12-09 Exploding Management Myths Johanna Rothman (author of Behind Closed Doors [U6] , Manage It! [U7] , Manage Your Project Portfolio [U8] , Hiring Geeks That Fit [U9] , and Manage Your Job Search [U10] ) Management Myths Webinar [U11]

2015-01-28 Talk on "Overcoming Resistance to Change" Rachel Davies (author of Agile Coaching [U12] ) OOP conference, Munich, Germany [U13]

2015-02-27 Talk on "Building Learning into Team Life" Rachel Davies NorDevCon, Norwich, UK [U14]

PragPub December 2014 51 2015-03-04 Talk on "Back to the Future: what ever happened to being eXtreme?" Rachel Davies QCon London [U15]

What’s Happening But to really be in the know, you need to subscribe to the weekly newsletter. It’ll keep you in the loop, it’s a fun read, and it’s free. All you need to do is create an account on pragprog.com [U16] (email address and password is all it takes) and select the checkbox to receive newsletters.

PragPub December 2014 52 Solution to Puzzle Here’s the solution to that puzzle:

A C L X E I R U B

I X E R B U A C L

R B U L C A X I E

E R X B A C I L U

L I C U R E B X A

U A B I X L E R C

B L I A U R C E X

C U A E I X L B R

X E R C L B U A I

Rearranging the letters from any row, column, or smaller square yields EXCALIBUR, which was the code name for the Apple Power Mac LC 5400.

PragPub December 2014 53