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 studieren. Das ist schlecht! Niemand nur zwei Jahren lernen kann etwas. Ich habe drei Jahre im Hochschule studiert, und das war vor 25 Jahren. Aber mit duolingo.com, anki, und dazpod.de, 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 meine Decke.

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.

 

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.

Cheers!

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!