#LearningSpringBoot 2nd Edition available for pre-order! See @PacktPub today

If you didn’t catch it, last week Packt released my Learning Spring Boot Video tutorial. It contains about four hours of in depth, hands-on coding with arguably the most popular Java stack out there – Spring Boot.

b05771_mockupcover_normalStarting this week, Learning Spring Boot 2nd Edition is now available for pre-order.

2nd Edition is targeted at Spring 5 + Spring Boot 2, which means we’ll be building reactive Java apps using Spring + Project Reactor (one of the hottest topics at this year’s SpringOne Platform conference).

If you want a hint of what reactive apps are, checkout Rossen and Stephane’s keynote.

Perhaps you’re wondering how you can pre-order a book for Spring Boot 2, when the project is currently at 1.4.1.BUILD-SNAPSHOT (as of this morning)? Spring Boot 1.5 is planned to be relatively light, while at the same time, a parallel effort to ramp up “bootiful” love for Spring 5 (reactive) will be underway.

And if you haven’t heard, I wrote this book’s predecessor using Asciidoctor. My code samples are pulled into the manuscript automatically by a simple script. I can iterate over the code, bump versions with ease, take advantage of Boot’s new features, and delay actually turning over the manuscript to my publisher. Plus, Packt and I are working hand in hand to align this with Spring Boot’s GA release of 2.0 slated for next spring.

Hang tight, and stay tuned as things move forward!

Compiling with @ScrivenerApp – How to make your manuscript look GOOD!

Like many of my friends, I like a simple, step-by-step guide when learning something new. So I’ve decided to capture how to use Scrivener, the greatest writer’s tool invented since the ballpoint pen, and show you how to crank out something impressive.

If you have no clue what Scrivener is, their own videos should whet your appetite. Assuming you are up and running, let’s dive in!scrivener-compile-button

  1. Assuming you are inside your wonderful book (in my case, Darklight), hit the Compile button.
  2. You’ll be thrown into something filled with more options than a scrivener-paperback-novelblue plate diner. I kind of like the look-and-feel Scrivener can give you for print ready things, so where it says “Format As”, select Paperback Novel.
  3. scrivener-contentOn the left hand side are a series of options. Let’s start by picking Content, and then ensuring you have selected Manuscript from the binder.
  4. On Print Settings, make sure Publishing is selected.
  5. Separators is kind of neat. Ever notice those like “* * *” between scenes in a book? This is where you get to set them. “Text” is what is known as a scene break and “Folder” is a chapter break, so you can pick options like “Page Break” as a folder separator, and some custom separator like “* * *” to put between scenes. If you’re not sure what each what one means, there’s a short sentence describing it perfectly.
  6. Formatting. This part can get really confusing. This is where you can decide what chunks of stuff are shown. There are different levels. When you pick a given thing (Level 1+, Level 1, etc.) it will highlight the piece of the binder where this applies. It lists “Title”, “Meta”, “Synopsis”, “Notes” and “Text”. Essentially, you can print/not print these various aspects. Ever read a book that opens every chapter with an encyclopedia entry? (Think DUNE or THE FOUNDATION) You can enter this text the chapter level and flip it on here. None of that? No problem. Clicking on “Title” for each level and “Text” for the Level 1. Nothing short of tinkering to find
  7. Formatting >> Options…. Pick “Remove first paragraph indents” “At the start of each new document”, and you’ll get that professional style of the first paragraph of every scene not being indented.
  8. Formatting >> Section Layout. Title Prefix and Suffix is where Scrivener will automatically plug in “Chapter 1”, “Chapter 2”, etc. No need to manually number your chapters. First Page is where you can do things like “make the first three words of a new section upper case (small caps even!). You can also make each chapter or scene start on a recto or verso page. (I can never remember which is which, so if you want this, just try it).
  9. Title Adjustments. Got a Prologue or Epilogue that needs to NOT be numbered like other chapters? Click on the little gear icon, and check those chapters to exclude them from being counted.
  10. Layout. I’ve read some books that only put the “* * *” when the scene break happens at a page wrap, where you can’t spot an extra line. This is the place to do that.
  11. Transformations. Probably don’t need this unless you are down converting your material into some format that doesn’t allow things like italics, underlining, or other stuff. (I once submitted a query that only allowed pure text. Would have been perfect.)
  12. Replacements. I don’t use this.
  13. Statistics. Nothing to do here.
  14. Tables. I have none in my works, so no comment here.
  15. Footnotes. I haven’t written that required such a feature. If you use it, let me know!
  16. Page Settings. This one is critical. There are several things to tailor your output so I’ll break them down into section.
  17. scrivener-page-setupPage Settings >> Page Setup. When creating a camera ready PDF for CreateSpace or whomever, you need to pick the trim size. It’s a fancy expression for page size. This where you can specify things like 6″x9″, 5″x8″, etc. It delegates this out to your native system, so Windows and Mac users may have a different experience.
  18. scrivener-marginsPage Settings >> Margins. After picking your trim size (which seems to translate into metric on my own system), you can then pick the margins. This is where Scrivener really shines. When you picked Paperback Novel earlier, it converted left/right margins to alternate such that the spine of the book has a little more margin than the outer parts. This picture shows 1″ top and bottom as well as 1″ outer and 0.5″ inner. This is where you can grab your favorite paperback and measure their margins, making your work look like it.
  19. scrivener-headers-and-footersPage Settings >> Header and Footer/First Pscrivener-facing-pagesages/Facing Pages. This is the content at the top and bottom of every page. I really like left pages being left formatted, and right pages, right formatted. The following shows me putting the title and page number of my manuscript on the left, and my name/page on facing pages. This really makes your camera ready document shine like real books. Finally, you can pick a different font and size for headers and footers at the bottom.
  20. Quick Font Override. Skip.
  21. With all these settings, you just need to pick the output. Always, always, ALWAYS Compile for PDF. PDF files make the world go around. Everyone can see them. Everyone accepts them. It’s a quick and easy proof.
  22. Click Export and wait for it to turn the crank.

So let’s take a little peek at my own novel, DARKLIGHT, and see it’s output.

darklight-prologueFor starters, the prologue came out beautifully. I excluded it back on Title Adjustments, and see how it’s not numbered?

Hmm. I can see that the first sentence, though unindented (as expected), does NOT have the first n words capitalized. Need to go back to Formatting >> Section Layout and tweak that.

darklight-chapter-1Chapter One looks good. The text I have in Scrivener appears as the subheading for the chapter (see screenshot below of my binder, with Prologue and He’ Coming). Of course, I need to get first n words capitalized.

Now let’s checkout the headers as well as the margin of the spine.

Okay, the margins looks okay. They are bigger at the spine than the edges, but I think that’s still a bit much for a paperback. darklight-headers

And yikes, I got the headers backwards! Oh well, live and learn, right? Need to go back to Page Settings >> Headers and Footers.

scrivener-new-sceneSo, after fiddling with margins, opening scenes, and headers, things look a little better.

And look! The headers look MUCH better.

scrivener-new-headers

Looks like enough to go fiddle with and fine tune. Hope that gets you going and compiling your Scrivener manuscript.

Happy writing!

 

 

JavaScript – the mutable functional programming platform

javascript-all-the-thingsJavaScript, amidst its funny quirks, is an interesting platform for functional programming. Especially given its highly mutable nature. Yes, you heard that right: a mutable functional programming language.

Let me head things off real fast. I’m not an expert on JavaScript. Not sure if I would qualify for senior status should I join a JavaScript-only team. Take my comments with a grain of salt. I just happen to express more interest in JavaScript than most of my surrounding teammates, and have learned a little more, so they tend to come to me with questions.

javascript-nested-functionsJavaScript is HEAVILY based on writing functions. You create them, you pass them around, you anonymously declare them, and you invoke one function while passing in two other anonymous functions. Functions within functions within functions. It is, as I like to say, Inception-esque.

But JavaScript is built on some of the craziest notions. Not a week goes by that someone doesn’t post a truth table of JavaScript comparison operations. It’s rules for converting and not converting between strings and other types is absurd. On a fundamental level, JavaScript is broken.

That last comment might ruffle a few feathers.

  • “You talk about Java a lot. It can’t be as bad as Java!”
  • “Python is crazy with its mandated whitespace formatting. Pu-lease!”
  • “AbstractSingletonProxyFactoryBean. Need I say more?”

(Heh, that last one makes me laugh too. Yes, it’s a class from the Spring Framework, and when you say it, it illustrates either everything wrong with Java or with the Spring Framework.)

keep-calm-and-learn-javascriptBut JavaScript doesn’t have a standardized packaging system. With Java, you have JARs. Python has eggs. And Ruby has gems. To fill the gap, there have been several packaging systems (AMD, Webpack, Browserify, UMD, and requireJS come to mind).

JavaScript somehow has made it into every browser out there (arguably the only reason it has grown in stature), yet many people today are coding in the newest spec, ES6, which hasn’t been folded into browsers. So, we use Babel.js. It’s a little toolkit that transpiles ES6 code into ES5 (currently supported version). But to accommodate all the build systems i just mentioned, there a LOTS of recipes to hook it into your packaging system of choice.

JavaScript, something born in the web browser, has made its way server side. Java itself includes a JavaScript engine (Rhino, Nashorn). node.js emerged as a new way to build server + client apps purely in JavaScript.

weird-al-javascriptThe thing is, when you start talking JavaScript, code geek to code geek, you have to do a little content negotiation. Because you might speak native JavaScript when your buddy is heavily into jQuery. (Believe me, the apps look very different on that aspect alone). You might be using Webpack bundles while your buddy wants something simpler like requireJS. You might be coding ES6 while your buddy uses ES5. If you didn’t get it, ALL these are orthogonal choices. You can write jQuery + Webpack + ES6.

learning-spring-boot-2nd-edition-mockIf you haven’t caught my drift, this is why I elected to yank most of the JavaScript code from Learning Spring Boot – 2nd Edition. I had plunked down quite a bit into the 1st edition, and too many people found it distracting. I’d be happy to yak about JavaScript at a conference, but most people aren’t interested in that.

At the end of the day, I find JavaScript cute and fun. I like building frontends using React.js. But if I had to make it my full time job, I’d probably go nuts. It’s that freaking crazy.

Happy coding!

i-love-javascript

Learning Spring Boot – 2nd edition on its way from @PacktPub

learning-spring-boot-2nd-edition-contract-headerlearning-spring-bootI just signed a contract to write Learning Spring Boot – 2nd Edition. This will nicely dovetail the Learning Spring Boot Video tutorial I’m currently recording.

The 1st edition had five chapters. The goal was to get to market, fast, and gauge reader’s reactions, so we kept it short and sweet, focused on the most critical bits. The results were a SMASH HIT! That book catapulted forward faster than my previous titles. Packt Publishing approached me a few months ago to record a video, and at the same time, discuss doing a 2nd edition. Suffice it to say, we’ve hammered out a solid lineup.

What’s the plan? The 2nd edition will be composed of ten chapters, and is squarely aimed at Spring Boot 2.0 (which comes with Spring Framework 5.0). Spring 5 will include lots of goodness including Project Reactor support for reactive data access as well as reactive Spring MVC. In this day and age, people want stuff that scales. Spring has already proven that, but as more and more people start using things like Project Reactor, RxJava, and other stuff to squeeze more out of their servers, the Spring team has stepped up to improve things once again.

learning-spring-boot-2nd-edition-chapter-hintWe’re shooting to have it out next Spring (see how I did that?). It’s not a rehash, but some of the key lessons will re-appear. For example, a Quick Start with Java is always cool. Just see one of Josh Long’s many presentations!

We’ll dive into Spring’s support for reactive web and data access that’s in motion right now. But other hot stuff is coming as well. (This is just half of the ten chapters coming)

Stay tuned!

 

learning-spring-boot-2nd-edition-signature

 

Book Review: CHANGER by @mattgemmell

I just finished a REALLY neat book by Matt Gemmell, CHANGER, and I thought I’d capture my reaction in the form of a book review.

Being a fan of both SFF as well as military/action thrillers like the Jack Reacher series by Lee Child and the Jack Ryan books by Tom Clancy, this one really tickled my fancy.

An European military task force is summoned to respond to a growing threat. A threat that hooks you in from the get-go. I started and couldn’t put it down.

Having read Schrödinger’s Kittens and The Search For Reality a few dozen times, this story really clicked for me. HINT: That book has to do with non-locality and multiple outcomes. That’s ALL I’m going to say.

So if any of that sounds interesting, then you can read the Prologue and the first three chapters for free.

Cons

As an author myself, I noticed a few things that could have been improved. For one thing, the scenes had a bit too much head hopping. I prefer for a given scene to stay with one character. And sometimes the adverbs were a bit much. If some of them had been traded in for a little more show-don’t-tell, it would have been beyond perfect.

Pros

As stated in The Irresistible Novel, the things I’m mentioning are preferences. My friend calls them MOOs (My Opinion Only). The most critical thing you can have in your story isn’t writing craft. It’s actual story that draws the reader in. CHANGER has exactly that.

Cover art

As I’ve already said, don’t skimp on the cover. Matt certainly did not. The front and back is a feast for the eyes. For fun, I’ve thrown in the full cover so you can read the back cover copy. Delicious, huh?

changer-backcover

The magic of software development

People think I have a magical talent. It’s funny seeing the difference between what I know and what others think I know when it comes to debugging stuff.

Simply put, I know how to tinker. I have clues, hunches, and insights. But that stuff is useless to a developer not willing to roll up their sleeves and engage in ten solid hours of trial and error. Often times, that is what makes or breaks a demo or a customer feature.

clock-with-a-questionDid I mention ten hours? Sorry, I meant ten days! Or sometimes it takes ten weeks to push your way through a mountain of integration, setup, and labor. Whatever it takes. But it isn’t solved by “knowing the answer” when you sit down at the keyboard.

We software devs work in the strangest field. First, we pursue a degree in either Computer Science or Computer Engineering. Ever seen a scientist and an engineer talk? Polar opposites. So what is software development? A science or an engineering trade?

My buddy Russ Miles has likened this to R&D, since there is no real sense of “can you have that ready in a month?” Building a bridge between two fixed endpoints is much easier to estimate than “can we have this website operational by next year?”

Experiment: Find your most non-technical friend, and ask them if they have a clue what you do. Then try to clarify when they say “no.” And try, and try, and try.

Solving software problems can seem foreign to both science AND engineering. On many days, it’s just tinker, tinker, tinker. And yet, our world’s dependency on it is growing.

HamletSoftware is really just organizing a set of patterns to respond to information. We need certain behaviors triggered automatically, and software is a giant stack of rules meant to handle that. As we collect more information and link more things together, the need to manage this grows.

A good visual of what software really entails is a hologram. Remember that limited-response hologram from I, Robot? We are just tinkering to put together a set of rules to better manage everything around us.

This requires tinkering, not magic. Good ole elbow grease is sometimes the best tool.

A good book cover provides incredible value

There’s an old saying: never judge a book by it’s cover. While applicable in the metaphorical sense, when it comes to actually publishing a real book, people do judge books FAST based on the cover. Having a good book cover is a must.

When deciding on a book, what do you do? If you have stepped foot inside a physical bookstore and found a section you’re interested in, you probably browse. Waltzing across the isles, I’ll guess you stop based on some snazzy title. Pull out the book, glimpse at the cover, and read the copy on the back. Whether or not you open the book and look at a single page is governed by two things: the cover and the description on the back.

Indie publishing demands a well designed cover

Listening to Steve Womack last week talk about the huge changes in the publishing industry, becoming an indie author is a popular move. But one thing you MUST do is invest some decent money in a top notch cover.
Ever publish a book through someone else? You may have learned through brutal means that you are NOT in control of the cover. Whoever is betting money on selling your story will often leave you out of the entire process. Instead, your publisher’s marketing team makes such choices.

Finding a good graphic artist

If you self publish, you are in control. Spending $100-$200 on a good graphic artist to produce a cover is money well spent. Assuming you have a decent story, you should be able to make that back.

Don’t do this the wrong way. If you think snagging a handful of images from Google Images and pasting them together will do the trick, forget about it. First of all, you are probably running into gobs of copyright violations. I’ve created decks using such means, but actual commercial work requires properly vetted sources of art.

A good graphic artist can also take stock images and blend them together, making professional grade edits (like altering hair color, facial hair, etc.) and has better access to fonts. The graphic artist also has a keen thing you don’t: artistic experience. When putting together a title’s cover, your artist will have a better feel for what fonts work, how to position the elements, and can put in the small touches you have never thought of.

If you find a good graphic artist, my suggestion is to continue going back for future projects. Your artist will grow to know you, and your titles can take on a certain signature. And of course, there’s the implicit vote of confidence if you like that artist’s work.

Keep on writing!

The value of backwards compatibility

springI was listening to Episode 6 of the Nash Dev Cast as they spoke about bitrot, of how stuff degrades as the whole Internet upgrades around you. It really reminded me of the inestimable value of Spring’s approach to backwards compatibility.

Something that is almost unnoticeable is that the Spring Framework and its entire portfolio has backwards compatibility. Bumping up the version in your project when a new release comes out is a no-brainer. They just don’t break stuff. You may get alerted to deprecated features, but the JavaDocs will kindly direct you along the upgrade path. Moving from Spring 1.2.8 -> 2.5 -> 3.0 -> 4.0 has such little cost, that people are eager to jump to the latest.

junior-devAs a junior developer, this kind of thing doesn’t really resonate. And not because you are somehow bad. No. It’s simply because you don’t have as many war stories to share over upgrading other libraries, and having major breakage. Senior developers at conferences will share a beer and discuss some crazy upgrade that got started, and a breaking change they were forced into turned a 2-day upgrade into a 3-week effort.

Even as a senior developer who recognized this feature of the Spring portfolio, it wasn’t until I joined the team and proposed changes, that I learned of the technical challenges this team faces to enforce backwards compatibility. It really rose to the surface when I heard Juergen speak about Spring 4 being “Java 8 ready” but still working with Java 6. With scrunched eyebrows, I leaned closer as he spoke during the 2013 Birds of a Feather at SpringOne how the framework would certainly support Java 8 features, but still operate on Java 6.

That perplexed me. How could a framework take advantage of things like Optional yet blink “no problem” if you used Java 6? Digging in, I learned not only how to build a JAR file with Java 6 specs but neatly keep Java 8-based API calls inside Java 8-flagged classes that were only loaded when Java 8 was the loading engine. And I learned how hard this effort was.

I already respected the Spring team and the programming model they had developed. But this level of technical expertise combined with forward thinking plans to start ten years ago and maintain to this day, was quite impressive.

So, listening to podcasts about JavaScript open source modules, sifting through and evaluating products, and getting “left-padded” at times, made me snug and comfortable in my decision to bring onboard the Spring Framework years ago. Their decisions to invest so highly in the community have paid dividends I have no idea how to tabulate.

In defense of leftpad

Given the time I’ve had to think about the whole leftpad controversy, I have to come to the conclusion that leftpad was PERFECTLY FINE with its decision to build a module with only eleven lines. (As to the brooha over unpublishing and then being forcibly republished by npm, that is a different topic.)

leftpad wrote code anyone with half a brain should be able to write

laptop_chimpThat must be the biggest sentiment I’ve heard. Blogs, podcasts, and other forums have thrown out this strong criticism of leftpad’s code. It’s best summarized as “have people forgotten how to code?”

Gee, leftpad getting unpublished broke React.js, Babel.js, and how many other systems? If those impressive projects saw value in leftpad, sounds pretty big of me to judge them all for making such a foolish decision. After all, that’s what I’m doing, right? I’m ascribing judgment for using it.

Let me be clear: I haven’t actually READ leftpad’s code. I’m not defending the physical lines of code in that module. The market spoke and accepted leftpad. I am defending the choice others made because I myself haven’t invested the time to make a better choice.

leftpad wasn’t REALLY used by React.js, etc. It was just a transitive dependency

2001This one doesn’t sit right. It’s kind of like saying, “React.js is good. The people writing it would never need something like leftpad. They just got caught by some intermediate dependency.” Can you smell the disdain?

If leftpad was used by an intermedia dependency, and that is what all the big weights used, then the transitive property applies. Not only has the market said leftpad met needs, but the intermediate dependencies are just as valuable. See what I did there? Transitive dependency, transitive value.

leftpad isn’t actually the best way to do what it did

Kaypro_in_Israel_1984Here is where it gets interesting. This is what I hear from those that have spotted the transitive link. Can’t criticize React.js, because they didn’t REALLY use leftpad. Let’s look elsewhere.

People have been singing the UNIX tune of “do one thing and do it well” as microservices arise. Defenders of leftpad point it out as a composable function, adhering to the UNIX philosophy. But if you can tear out “do it well”, then leftpad doesn’t qualify for this concept. Hence, leftpad was a badly written composable function.

Sorry, maties, but as software engineers, we seek out solutions on a daily basis. And in the land of open source, we constantly make “build or buy” decisions. Whenever someone asked me, “what is an engineer”, my answer has always been, “we find a good enough solution for the problem at hand.” We don’t seek perfect answers, because we don’t have an infinite budget.

For a LOT of people, leftpad was good enough. They could have written a better solution, but they could also have written a better solution for LOTS of other modules. Imagine the cost of perfecting every single thing you use. Or how about this: imagine the cost of tens of thousands of developers writing an equivalent to leftpad. Perhaps 15 minutes tops, but multiplied by 10,000 and your talking 2500 hours of effort. Doesn’t that defy the concept of open source?

What’s next?

imageI know people that don’t like certain tools out there. They have written their own version of things. At first glance, there’s underscore and lodash. These two libraries essentially do the same thing. But one project was not satisfied with the other project. Hence, they built a fork and whole community around it.

These are people I respect, because they took the time to evaluate the current state of affairs and write their own solution. When I go pick from one of these two solutions, I can find out the basis of one or the others. Has the bulk of the JavaScript community picked one of the other? Or is it a big split? These are factors in choosing.

I can spend all my time building everything from scratch and live under the haughty label “I know how to program. I’ll build it myself.” But we already have a term for developers like that: “Not Invented Here“. Some people will only touch code they themselves wrote.

If you actually spent the time to read leftpad’s code, then used it or decided otherwise, that’s fine. But don’t go around criticizing others for using leftpad. After all, you’re criticizing the choices of MANY others.

Good developers take breaks

Boring PresentationSomething that has become crystal clear since I joined the Spring team is how important it is to take a break. Good code happens when developers take breaks.

Of course there are times when I find myself working solid until 8:00 pm or later. But I try to make that the exception rather than the norm. Most of the time, I’m pulled away by my kids coming home from school. In fact, I’m often annoyed at stopping a minute early.

STTNG_pinballAnd yet I’m astonished at how many perplexing problems I’ve solved by simply stopping, doing something else, and **BAM**, the answer pops into my head. Sometimes within minutes, sometimes the next morning while putting shoes on one of my kids. Those are the moments when I remind myself that developers take breaks. I consider that payoff for having stopped early.

This phenomena is well know. In fact, you’ve probably heard of it. I also so it addressed keenly at a writer’s conference last year. Your subconscious is still working on the problem whether you are or not. Sometimes, when you aren’t actively trying to fix it, your noodle is freed up to look back at what you did, what you’ve read, and other things.

devnexusWhile chatting with a teammate of mine at DevNexus, he expressed that if he hadn’t taken various breaks, gone for walks and thought about the architecture he was designing, the project he was striving to build would never have happened.

HamletReflection is a critical component. My martial instructor often taught “visualize, visualize, visualize.” It’s a mechanism to put your mind on the subject, even when you’re not actively pursuing it.

The key thing is telling yourself to take that break. To pause. To stop and not burn the candle at both ends. If you work that hard, your subconscious will be on the ropes. Those extra ideas that can often succeed when you may have failed all day, may not come at all. It’s a big leap I know, but give it a try.