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.


Chapter 4 of Learning #SpringBoot submitted…upgrading manuscript to 1.1.5.RELEASE

learning-spring-boot-ch-4Yesterday afternoon, I bundled up Chapter 4, Data Access with Spring Boot and shipped it off to Packt Publishing. They were happy to receive it on time.

Then I saw Spring Boot release version 1.1.5.RELEASE. I just updated all my source code to the latest version, edited the fragments, and fixed the links in my asciidoctor files. Reading through all the issues of this release, nothing appears to be of any impact to this book.

Naturally, I’ll recheck everything after I wrap up Chapter 5, Securing Your App. In the next and final chapter, I’ll show how Spring Boot speeds up securing apps. By merely adding Spring Security to your classpath, Spring Boot leaps into action and locks things down with suitable defaults. You can easily alter various settings. Finally, you can start plugging in custom configurations as needed.

secure-ssl-appSecurity, in my experience, has historically been a tricky subject. I’ve seen countless teams apply security as the last step. People also don’t understand that security is a multi-layer effort. It’s not ALL contained in the application.

And security requires a certain understanding; a frame of mind. When I worked on the commercial engineering team a couple years ago, I applied several strategies to prevent users having their data compromises. Not all of these ideas were my own. Many came from a teammate that had a prankster’s perspective.

If you look at the second image in this blog, you’ll see a perfect depiction about how people will do something like configure SSL for a website and call it a day. SSL only secures one aspect of things. Usernames and passwords only cover a few more aspects.

This chapter will help cover how Spring Boot makes it much simpler to secure the embedded Tomcat servlet container. It will show how to institute authentication and authorization to verify you are who you say you are and that you’re authorized to do what you must. It’s important to plug in security from the get go, and Spring Boot makes this even easier than ever. But never stop looking for attack vectors that you must block to avoid issues.


Sprinkling in some @SpringData #REST to chapter 4 of Learning #SpringBoot /cc @PacktPub

learning-spring-boot-ch-4As I hack away at the last couple sections of chapter 4, I have enjoyed being able to sprinkle in a little Spring Data REST. That project is really neat. I think it’s the way of the future for many apps out there. By providing an incredibly easy point of access to data, built on lots of standardized conventions, it’s impressive how it provides a good RESTful API while also mixing nicely with the data access layer.

Spring Data is a great way to skip over writing boilerplate CRUD functionality. Spring Data REST provide a powerful, hypermedia-driven RESTful way to interact with it. It sets you up to easily create modern front ends to interact with it.

I knew when I staked out this chapter in my proposal that I would include a section about Spring Data REST. I can’t pass up the chance to get the word out. With only a week until the first draft of chapter four is sent in to Packt, I need to knock out the last bits of this chapter and then gear up for chapter 5, Securing your Spring Boot App.


How open source has commoditized computers

mac-snow-whiteAs I type this blog entry, from my wife’s newly purchased MacBook AIr, I marvel at the power of open source. Thanks to open source, we are no longer bound to a particular vendor, operation system, or anything else.

My wife’s old netbook was the last machine in this household that ran Windows. Back when we got married and lived in a smaller house, the desktop computer in the living room ran Ubuntu LInux. It took my wife little effort to learn how to drive that machine, considering she primarily used computers to browse the internet and a little bit of picture management when making Shutterfly books.

I introduced her to OpenOffice (later migrating to LibreOffice) for writing. I then threw in Dropbox and gave her her own folder to keep her own written works. With all these in place, it didn’t even take a whole day before she was up and running, editing her manuscript on the new Mac.

By moving to a handful of open source projects, the need for a particular vendor evaporated. Now we can pick a machine based on more important things like: quality, performance, and tools. I got her a maxed out 13″ MacBook Air (8GB memory , 512GB SSD disk).

Suffice it to say, she is definitely happy. You can even see the decal she just ordered up above! I have gone in and done a couple extra steps, like installing Crashplan to back things up. I am also installing Homebrew in case I need this machine as a backup development workstation. I also flipped on remote login support so I can ssh into this lightweight laptop as needed. It truly is a thing of beauty. Ahh! Goodbye Windows!

Hear about #REST and #hypermedia with #mobile UI @springone2gx this year! #s2gx


Spring Mobile/Android guru Roy Clarkson and I are giving a talk at SpringOne this year. We will be mixing Spring Data with RESTful APIs.

Roy and I have been working on a demo app that let’s you snap pictures and then upload them to a centralized web site through a simple RESTful API using hypermedia. The code to build the back end is über easy and lets you focus on the problem you’re trying to solve. On top of that, we’re building some functionality to then tweet your pic to all your friends.

spring-a-gram-catOriginal idea, huh? (See video below for my inspiration!)

The focus of our talk is about the powerful role hypermedia plays in creating flexible APIs, and how Spring Data REST puts you in control of building multiple clients. We will have a desktop web site as well as a mobile UI. We are also plotting to release the app on Cloud Foundry so you can go around and take pics during the conference and tweet them to your friends and colleagues.

Don’t forget. Early bird registration ends August 9th and will go up $150, so sign up now!

When in doubt, capture it on your phone

broken-retina-screenThis afternoon, I dropped my laptop. Sadly, I could tell it was kaput. The image to right isn’t fuzzy due to a shaky camera. So I loaded up my family so we could drive to Nashville to the nearest Apple store and get the ball rolling on repairs.

After dropping it off, we walked back out to the car to get a bite to eat, since repairs were estimate to take less than an hour. We encountered a woman parked next to us. She stopped us and accused us of hitting the back-left bumper of her car and causing damage. She then pointed to a ding on the front-right part of our bumper, and said that was where we had hit her.

I was startled and not sure what to do. When we had parked earlier, I was quite sure we hadn’t hit anyone. Before I could collect my thoughts, my wife spoke up, “The paint on your car doesn’t match the color of ours.” Wow! She is sharp. I walked over and confirmed it. The woman’s car had bits of orange on it. Our car was dark cherry red. Distinctly different.

But this didn’t dissuade her accusations. She mumbled something, thinking that we had merely scraped off the exterior paint, implying her vehicle had an undercoat of orange. Again, my wife quickly pointed out that her scrape and our ding were at different levels. Her scrape was clearly six inches higher off the ground from the ding on our. I walked over and stood next to our ding, and held my hand against my leg, marking the height. Then I walked over to the woman’s car, and demonstrated that there was no way we could do this.

evidence-her-carShe wasn’t accepting that either. So my wife promptly said we would be happy to call the police to sort this out. I thought that would do it for sure. Most people don’t want to deal with law enforcement. But not her. After thinking for a few minutes, she asked us to call. I made a call and waited for cop to arrive.

The whole time, I could hear Judge Mulian’s voice in the back of my head, “show us your evidence!” (Okay, I watch court TV. Don’t judge me!) I knew that no matter what transpired, we might get sued. I needed to gather all the evidence I could here and now, and save it for the future. I took a picture of the ding and the scape. I also took a picture standing right next to it with my finger pointing to each. That way, each picture clearly demonstrated the difference in height. (And I figured it might make good blogging material, if not at least capture it historically).

The police officer arrived quickly, and spotted these glaring holes faster than us. We were promptly told we could leave because it was clear we weren’t responsible for the damages to the woman’s car. But I knew, that wouldn’t stop her from suing us anyway. Without clear evidence, we were at risk of losing. I was happy I had gathered all the pictures. I also had observed that the women never heard our address nor did she take a picture of our tag. The odds of her finding us and suing us is remote. But I have a record of the circumstances in my phone. Just in case.

Chapter 4: Data Access with #SpringBoot on the move /cc @PacktPub

learning-spring-boot-ch-4I’ve gotten things moving quickly with chapter 4. The general idea is that I want to show how to get off the ground super fast using Spring Boot and H2 as an in-memory database. Give the user the tools to either load up some sample data with a SQL script or with the Spring Data APIS. And then from there, see how to transition to production data.

You see, a common problem people deal with is building code on their development workstation and wanting to write unit tests. But the database is a fixed source of data. What do you do? Wipe it clean before every test run? What about other developers? That’s where in-memory, local database really shine. They are fast, have zero setup, and when you shutdown the test app or test case, everything is clean.

So using that to write code, test cases, etc., is great. But eventually, you have to switch over to pointing at a development database, perhaps a test bed database, and ultimately, a production database. Your app shouldn’t have to go through crazy gyrations and edits to move between those different environments.

And that’s the story I want to tell in this chapter. Spring Boot + Spring Data + Spring Framework makes this so incredibly easy. It’s a problem I ran into several times in the past, and with the über awesome power of Spring Boot+Data+Framework, I want to show my readers that there is no reason to fear the multi-environment database setup!

The neatest feature of #git I didn’t know was there

I have been using git for several years now. But like any other tool, you don’t REALLY know all its power without using it in the craziest situations. I’ve just discovered a core aspect of git that totally drives me nuts given what it can do!!!

Git is a distributed version control system, right? Those of us using it with github are probably well aware of pull requests, making local commits, and doing various day-to-day operations. But something I didn’t understand until I had to process a pull request from the Spring community was exactly WHAT a git commit was.

Git commits are hashed. The don’t use counters, because they must be unique across any machine. You can’t depend on the counters working correctly. Instead, the idea is that people can develop separately, in another repository, and then submit pull requests to make a contribution. I as the developer can then merge your pull request. Sounds great, right? But did you just skim over that that sentence, “merge your pull request“.

What are we doing when we “merge your pull request“? It typically means we are pulling changes from your forked clone to mine, but once you realize that there is zero requirement for a relationship between your fork and mine, you discover that commits can be pulled into ANY repo and branch.

For Spring’s getting started guides, we have a central repo where people can write entirely new guides, and submit them as pull requests. But we don’t merge them there. Instead, we create a whole new repo and pull in the commits there. And we do that after you have made your contribution. If you look at those commits, it will appear as if everything was created, developed, and published there. But it wasn’t.

For any guide, the tentative author first creates a draft for a guide. Authors are encouraged to create a fork of that central repo and then start making their edits. At that point, everything can be pushed up to a branch. The author crafts a pull request. From there, we could merge back to the original master, but we don’t want to. Instead, we want each guide in a separate repo to suitably manage each guide separately. This lets us take all of the author’s handiwork, and put in that separate repo.

Basically, commits are self contained. If you develop something on one branch, and I development on another branch, it’s possible to merge both of these efforts into a third branch in a totally separate repository. And it doesn’t matter if one is a forked clone of the other. Clean things up, and we can turn this all into a pull request back to the original master. Or it can go elsewhere.

The point is, breaking up work into commits, sharing them with others on branches, whether on your fork or not, you can keep things nicely segmented. Then it becomes easy to hammer out issues and fold things together. And the side effect is that ALL commits retain their history, status, and who wrote what. You can squash things if you wish, whereupon some of the history is flattened. But this type of flexibility is incomprehensible when using something like subversion.

Why git + @Dropbox + @Asciidoctor + @Crashplan => perfect environment for writing /cc @PacktPub

packt-logoOne tidbit that Packt sends its authors is strong advice to BACK UP YOUR WORK. It will happen. So don’t get caught with no back up of your efforts.

As I being working on chapter four of Learning Spring Boot, I can tell you that I got this one covered in spades. I’m a firm believer in version control. I use git to manage my manuscript, code, and everything else. Mind you, This way, I can always back up to a previous version of anything and either recover something or use it to respond to feedback. In general, version control is protection from my own edits.

The git repository for my manuscript lives inside my Dropbox folder. That way, all my work is immediately visible on my phone, my wife’s tablet, and any other computer I have linked. To top things off, it essentially backs everything up to a remote location. This is a way to back up against hardware failure.

I also have a Crashplan account. I have the maximum plan, which means ALL my computers (max is 12 machines) are backed up with unlimited data volume and unlimited versions. I can find older versions of files if need be, and if I can’t locate via git. I have actually rebuilt my laptop twice in the past four years, and Crashplan was the key to recovering personal data.

To top things off, using Asciidoctor to write my manuscript has been fantastic. I don’t focus on layout, spacing, and other boring word processor stuff. I have focused on content. Quickly rendering a web page of a given chapter and proofing it in my browser is GREAT. After all that, I then open it up inside LibreOffice, and make sure I haven’t broken any margins. I’m still having to hammer out some issues with an editor, but I’m sure this investment will pay off in the long run.

Why did I write this? One of my followers spotted some new product from Amazon that appeared to be a collaborative tool. He or she was suggesting I take a peek. I quickly spotted the price tag of $5/user/month. No need! For writing a small book, all these tools are enough. The only thing I’m paying for is Crashplan. The rest of the tools are free.

When I think about doing the same thing fifteen years ago, I cringe at what the state of the art was back then. To truly embrace open source back then and pursue an open source only lifestyle would have been nigh impossible. But today? No one thinks twice about using free software tools to get real things accomplished.