Beneath every great forest lies something even greater. See #SpringBoot book cover from @PacktPub

learning-spring-boot-mock-coverI recently got confirmation of the cover image of “Learning Spring Boot”. I don’t have the official cover, but I created a mock up based on the stock image.

I’m really excited about this. About a month ago, Packt sent me a collection of stock images to pick from, and this one was PERFECT. To top it off, I just read Dave Syer’s drafted foreword, and it only solidifies my feelings. (I don’t want to steal the thunder. You’ll have to get the book to read his epic opening words.)

You see, this image shows a great forest. Tall trees. Beautiful beams of light shining through. And just the right amount of mystic charm to please the eye. And yet, a forest’s greatest strength lies beneath it. No forest can stand strong unless it has a strong set of roots that have grown and solidified over the years. A deep undergrowth of roots that supplies the nutrients.

That’s what Spring Boot is. It is a strong growth of patterns, discoveries, who knows how many hours of real world experience, and more. This can be seen by those that begin to use it. But it wouldn’t exist today if it wasn’t for the strong foundation of the Spring Framework. Ten years ago, Spring Boot was impossible. Spring didn’t exist yet.

But today, after ten years of development, the Spring Framework is the de facto standard for application development on the JVM. I remember when the 10,000th issue was opened against the Spring Framework. It was a landmark event. Tens of thousands of contributions to the project. Thousands of committers. Hundreds of pages of polished, detailed documentation. All for a project that has been open source from day one. It truly represents a community effort to create something greater.

Many conferences are conducted every year around the world to discuss Spring. Millions of copies have been downloaded and permeated the Java development space. People chat back and forth in hallways, on chat channels, and at JUG meetings about “the Spring way”.

And as I remember from the first presentation I saw from Graeme Rocher on Grails, his bottom line comment was “Grails IS Spring”. Grails didn’t sit on top of Spring. Grails didn’t use Spring. Grails WAS Spring.

Well Spring Boot can say the same. Just visit, and you’ll find 60+ guides showing “the Spring way” of solving common problems. Guess what; almost all of them use Spring Boot. Not because it’s “the product to sell”. Nope. The people that wrote those guides (including me) LOOOOOOVED using Spring Boot to solve these problems and so many more. And that is what got me so fired up that I had to write another book after having been burned out over three years ago.

Stay tuned!

“Learning #SpringBoot” enters finishing stage with @PacktPub

packt-logoGreetings readers,

Having just sent off the last rewrites, my book has entered the finishing stage. This is the point where my publisher begins to turn the crank on converting my LibreOffice manuscript into a printable tome. They also sell e-copies and even have a subscription library model. You can pay a flat rate and essentially access any book they have, including mine when it becomes available. My goal is to post a link the moment I see at available for ordering.

So what’s in this book?

For those that haven’t kept up, here is a quick listing of the chapter titles:

  • Chapter 1, Quick Start with Groovy
  • Chapter 2, Quick Start with Java
  • Chapter 3, Debugging and Managing Your App
  • Chapter 4, Accessing Data with Spring Boot
  • Chapter 5, Securing Your App with Spring Boot

First of all, this book is in NO WAY comprehensive. To cover everything Spring Boot does would require multiple titles. People that construe Spring Boot as being the solution to über JARs or just embedded servlet containers are missing the point. Spring Boot is an entirely new approach to app development that polishes up rough edges of Java that have been around for years. In the paraphrased words of Andrew Glover at this year’s SpringOne keynote, “Spring Boot has made Java fun again!”

This book attacks several of these key areas from the context of helping everyday developers do their job. When you sit down to build an app, you want to start writing functional code on Day One, not get buried in architectural layers and UML diagrams, right?

Spring Boot is designed from the ground up to write solid apps using Spring that you can carry all the way to the server room. And it comes packed with production-grade services you’ll need to maintain it over the life of the project.

platform-spring-bootWhy can’t I just read the reference docs?

A good question that authors must always be ready to answer when pitching their idea or trying to sell copies later on is this: “Why would I buy your book?”

I won’t lie to you. Spring Boot’s reference doc is quite stunning. I have seen many ref docs, and have always found Spring docs to historically have some of the most in depth material I can find. MANY open source projects come in light on this front. However, it’s become tricky to have lots of depth without getting lost. Spring Boot’s ref docs actually do a fantastic job of diving in, and yet still giving you paths to other areas you might need.

Even then, when its time to sit down and start producing apps, you want examples and demos and a handful “this is the best way to get started.” I have extracted material from the reference docs, but tried to link together a chain of useful concepts that can get you in motion the first week you start a new project. These concepts aren’t always arranged in the reference docs in the same order you might be using them to crank out your e-commerce site. (If they were, it would be a tutorial, right?)

This book is also filled with tips. Small sections all over the place that try to answer the question, “Why did you do that right there?” No decision is ever 100% right. Things depend on the context, so I fee it’s important to supply a context for why you may choose one path or another.

Ideally, you should be able to read this book cover-to-cover, and then when you visit the reference docs, use them with even greater effectiveness.

Are there other books out there?

Right now, no. Nothing. Nada. Zip. You can’t find another book on Spring Boot. My publisher and I worked hard to get this one to market as fast as possible. Why? Because Spring Boot is hot! The session at least year’s SpringOne conference was packed to the hilt. At this year’s SpringOne (a week ago) almost every talk wove in detail about Spring Boot even including Grails plan to rewrite itself on top of Boot with their 3.0 release.

People are hungry for this, so we hammered out an outline that would cover the arguably most popular topics people are clamoring to read about.

I have other colleagues and friends in the software industry that have been talking about book deals. One reached out to me to write a proposal, but I had to politely decline because they asked me the week after I had signed my contract.

Are other books coming? For sure. I’m sure many publishers are working up deals, consulting existing authors, or ears open for new proposals on the topic. But no one is going to have anything available next month.

Big shout out to @altfatterz @geowarin @furikuri @royclarkson @phillip_webb and @rob_winch as I wrap up “Learning #SpringBoot”

polishing-learning-spring-bootI just shipped out my last rewrite for Learning Spring Boot. I am TIRED. The past five nights, I have stayed up later than midnight to get in last edits and incorporate feedback from my reviewers.

These guys are really talented. I couldn’t ask for a more solid team to pick over my material and offer substantial feedback. It can be humbling at times. But the reward is tremendous. I really hope this book meets a lot of people’s needs.

I have overheard those not quite familiar with Spring Boot try to capture it in a single statement. “This is Dropwizard.” “This is a web app in 100 lines or less.”

Sorry, but Spring Boot is WAY more than that. My book tries to cover quite a bit of ground, but as I concluded in my closing sentence, “This is only the beginning.” Spring Boot tackles LOTS of things, and makes them easier. And it’s just getting started. Frankly, I’m not sure what it will look like a few short years from now. But for the time being, I’m very satisfied at getting this written and edited. I hope you enjoy it.

Day Two: Sprechen Deutsch mit meinen freunden @springone2gx #s2gx #german

springone2gx2014_banner_speaking_200x200So weit, ich habe mit Ollie Gierke, Christoph Stroble, und Michael Hunger in Deutsch gesprecht. Super! Das is sehr Spaß!

In Amerika, wir mussen zwei Jahre im Hochschule lernen. Das ist schlecht! Niemand nur zewei Jahren lernen kann etwas. Ich habe drei Jahre im Hochschule gelernt, und das war vor 25 Jahren. Aber mit, anki, und, I kann Deutsch wirklich genießen!  Täglich, ich gehe mit meine Tochter zu Kingergarten, and dann ich gehe nach mein Haus wo ich studiere mein Deck.

Zeit für Frühstück!

Despite being buried at #s2gx, managed to submit chapter 1 rewrite for “Learning #SpringBoot” to @PacktPub

learning_spring_boot_ch1_odtThere was a mix-up of communications with my editor. I told her that I was out this week. But it appears that just won’t cut it. Packt Pub is FAST! Thankfully, I invested time during last night’s flight to work on Chapter 2 – Quick Start with Java. This morning, after fixing up Spring-a-Gram, I was able to polish up and submit the rewrite for Chapter 1 – Quick Start with Groovy.

Word is that they’ll actually have this book out sometime in October. Wow! Everyone I talk to is stunned at the speed this book is being cranked out. I have become very glad that my other TWO talks I submitted for SpringOne did NOT get approved! When would I have time considering I still have to prep slides.

As a side note, I also SUPER glad to have used asciidoctor. It made edits super, super, SUPER simple to deploy. Stay tuned!

Working in the cloud on spring-a-gram while flying through the clouds #s2gx

spring-a-gram-catThings are rather intriguing. I am flying through the sky, in the clouds if you will, towards Dallas, Texas. This week is the fun filled SpringOne 2GX conference. As I fly through the clouds, I’m pushing updates to my app, in the cloud. :) Another humorous fact is that I started this blog entry in the airport terminal, but delayed posting UNTIL I got on the plane, so I could access the WiFi.

Spring-a-Gram is my demo app used to demonstrate Spring Data REST. With it I will show just how quickly you can create a back end and shift your focus to the front end. The app is used to create images and then upload them through a RESTful service. I built a mobile web page so you can take pictures with your phone, upload them to a website, and view it from other locations. For fun, I threw in sharing via twitter.

Gearing up for @SpringOne2GX. (It’s not too late to register!)

DSC05391This is a short week for US citizens, since this past Monday was Labor Day. Of course, while I took time off, it didn’t really save me from the fact that I still have a boat load of stuff to do before I fly off to Dallas this upcoming Sunday.

I look forward to seeing many colleagues face-to-face. It’s a great time of cameraderie. And it’s also one of the most heating times of the year when we want to get certain things released to the Spring community.

I’ve been working primarily on two teams this past year: Spring Data and the Allspark team. Primarily I have worked on Spring Data REST, a project that lets you export any Spring Data repo with powerful RESTful endpoints supported by hypermedia. I have also made significant contributions on converting all their reference docs to asciidoctor. (Stay tuned for more on that).

At the same time, I have been using my RESTful skills and knowledge to interact with the Allspark team. This group is focused on a mobile R&D. As people are becoming aware, not only is software consuming the world, but mobile is consuming the software world. With billions of mobile devices in circulation, many businesses deal with mobile traffic as a primary means for lots of customers.

spring-a-gram-catRESTful services are a key facet to developing mobile apps, so I have used Spring Data REST to bridge the gap between Spring Data and mobile interfaces by building a demo application. Roy Clarkson and I will be demonstrating it next week. The app is called Spring-a-Gram and has been developed to move as much development as possible off of the server and onto the client.

In our demo, I’ll show an iPhone mobile web app that can take pictures and upload them to a backend database. Then it will let you tweet links to all your friends. Roy will demo an Android app that does similar things. All the while, it showcases the power of Spring Data REST and hypermedia.

My goal that I am trying to accomplish this week is to get the latest Spring Data GA release into my demo so I can show of the new ALPS metadata. This will be a signature achievement, because it will remove the need for a client developer to actually peek at the apps domain model. Instead, one can interrogate the RESTful service purely with a tool like curl and figure out how to a interact with the backend.

At the same time, I’m polishing up the getting started guides so that readers can skip over the build steps and jump right to the content. The process of putting such dynamic features into an asciidoctor-based guide was quite enlightening. I wrote JavaScript, CSS, and HTML and learned a lot of really fascinating things. I just can’t wait to gather with my colleagues and have a toast to this past year’s work!

If you happen to be coming (it’s not too late to register!!!!), send me a tweet or a message on this blog site. I’m trying to gather notes on all the people I plan to link up with. (In the meantime, I’ve told my editor for Learning Spring Boot that I’m basically unavailable to work on rewrites for the next two weeks.)

Happing coding!

That’s a wrap! “Learning #SpringBoot” ‘s 1st draft has been submitted to @PacktPub

learning-spring-boot-ch-5Last night, I worked from 9:30pm until 2am. Whew! It was tough work, but I needed to pull it across the finish line. I had the code lined up quite nicely for the entire chapter. I simply need to tell the story of how all this stuff worked together.

As I’ve said before, security by itself is complicated. There is a lot of fine details involved. When someone first starts reading the reference docs of Spring Security, it can get real intimidating real fast. That isn’t Spring Security’s fault. It’s inherent to the nature of locking something down except for the right people in the right context with the right protections. “right” and “wrong” can be very hard to define in just a couple sentences.

I tried to walk through what is happening, provide a little “why is this happening” and finally leave some links for those that want to dig a little deeper and understand the incredibly complex stuff that Spring Security is ACTUALLY doing for them. The protocols Spring Security picks up and handles are quite complex, and when you get to the end, I hope the reader has a strong appreciation for how simple Spring Security has made it to give the developer control while still protecting system integrity.

With all that said, I breathed a big “whew!” as I bundled up this chapter’s manuscript and emailed it over to my editor at Packt. I have already started receiving feedback on the other chapters from my review team. These people are sharp! They really know Spring and have spotted some sloppy mistakes on my part. After I parse all their comments, this should be one well honed book!

asciidoctorI also have truly enjoyed the development process of this book. Writing it in asciidoctor has let me focus 95% of my effort on the content. I work with an IDE open so I can tweak the code, run it, tweak again, and then commit the changes. My manuscript simply includes code files and fragments, and I layer it with some prose to explain what is happening and why it’s happening. Here and there I put tips and notes to answer questions I can foresee.

Then on the command line, I constantly regenerate an HTML rendering of the book. I read through it in chunks and polish it up. After all is done, I finally open up the LibreOffice output and and walk through to fine tune bits of code that overrun the width of the page. By staying away from the word processor as much as possibly, the integrity of this book’s content has been kept at what I feel is tip-top shape.

Chapter 5 of Learning #SpringBoot almost done!

This Thursday I’ll be submitting the first draft for Chapter 5 – Securing Your App with Spring Boot. If you have no experience with Spring Security, then I hope you’ll enjoy this chapter. Security by itself is a complex topic. There is no single thing that instantly makes your entire application secure from everything.

Spring Security is a powerful application level security tool. You get very detailed control and can customize to your heart’s content. But as is often the case, people want to use some basic settings that enact a common security model: authentication and authorization.

When you add Spring Security to a Spring Boot project, things get automatically locked down. This is handy for demos, but this chapter will show you can then go in and configure things more to your liking. My plan is to walk through in-memory based options (good for testing and getting started) as well as a configuring a couple different databases that are commonly used. With that sort of introduction to Spring Boot + Spring Security, it becomes much easier to read the online reference docs if you want to cut over to an LDAP-based user data store.

As I said earlier, security doesn’t start and end at the application level. I want this chapter to be comprehensive in the sense that security doesn’t end at the application level. Spring Boot does a fantastic job of inverting the concept of a container by having the app bring along embedded Tomcat to run itself. In this chapter, we’ll see how to configure Spring Boot’s embedded Tomcat servlet container use SSL, strengthening the end-to-end security of your app.

docbook…what a piece of junk!

lukepieceofjunkIn the past week, I have focused on porting the Spring Data Evans release train to asciidoctor. It has been joyous and torturous. The joy is moving away from docbook and towards asciidoctor. The torture is dealing with all of docbook’s idiosyncrasies and the wonderment at how someone could build such a tool in the first place.

First of all, XML is a highly nested data structure. The nesting is used to convey semantics, but XML was originally designed as a machine-to-machine communication medium. It was indicendtially written using ASCII so that devs could debug the communications more easily along the way. Using it to create documentation systems is ridiculous.

docbook-whitespaceIf you look at this fragment of docbook, you can see all the wasted space based on standard XML formatting. Reading and maintaining this is an eyesore and the source of carpal tunnel.

asciidoctorLooking at asciidoctor is much more pleasing. There is no cognitive overhead of angled brackets. No extra indentation. And the results are easier to visualize. The semantics are so much clearer.

But that isn’t the only thing that has been a hassle. To do this migration, I wrote a SAX parser that properly pushes and pops as elements are started and finished. In essence, as you start a new element, a new state needs to be created an pushed onto a stack. When that element finishes, you pop that state off the stack, and properly append it to the previous state, i.e. the enclosing XML token. I had this working smoothly. Along the way, if you hit any characters between the XML entities, they need to be appended to the top of the stack’s “chunks”.

But docbook has so many awkward situations, like <section> <title>blah</title> <para> <section> <title>blah</title>…., that would lead to a level 0 header followed by a level 2 header. Where is level 1? Nowhere to be found and up to me to clean up.

Also docbook has SO MANY different tokens that really expresses the same thing. For every different element type, I created an AST node to represent it. But when it came to <code>blah</code>, <interfacename>blah</interfacename>, and <literal>blah</literal>, I created only one, Monospaced. These all basically get converted to the same thing: `blah`, i.e. some text wrapped in back ticks.

Other stuff is simply impossible. I did my best to handle tables, but too many quirky things can go wrong. So I did my best and then hand edited after the fact. Callouts are worse. Asciidoctor makes callouts awesome. But getting over the hump of docbook’s format is such that I don’t even try to convert. I just stuff the raw AST content in the output and warn “DO THIS PART BY HAND”.

Given all this, porting the whole documentation of Spring Data to asciidoctor required me to invest three days of effort purely at building this script. I actually rewrote the script after Day 2 because I had made a fundamental flaw. But I met my objective of migrating all of the Evans train by this past Monday.

But the pay off of writing the script properly has been great. I hadn’t written a SAX parser like this for ten years. It brought back keen memories. Thankfully, using Spring Boot CLI + Groovy made it a pleasant, scriptastic experience.