Category Archives: spring

A tale of two mediatypes

I’ve spent the last several weeks picking up something I started back in 2015. Way back then, in the airport departing SpringOne, I started working on the third mediatype for Spring HATEOAS. There were already two: the original one based on pure Jackson and HAL.

This was Collection+JSON by Mike Amundsen. As a traveling consultant, speaker, and author, Mike has actually penned several mediatypes while also advocating for evolable, adaptable RESTful architectures. Working on this one, I made considerable progress. The progress was really about me learning how Jackson worked.

When your pull request gets turned down

You see, Spring HATEOAS doesn’t just crank out hypermedia. We have a collection of domain classes that represent a neutral format. Your Spring MVC controllers can actually be used to generate multiple forms of hypermedia. At least, that’s the idea, and in it’s formative six years of development, that premise hasn’t been dropped.


So after supposedly finishing the job and submitting it to the project lead, Oliver Gierke, I wondered why my work wasn’t getting merged. I chatted with him and learned of another effort afoot that was blocking its acceptance: Affordances. Another group of people were working on a very deep, extensive enhancement to Spring HATEOAS, and Oliver didn’t want to complicate things by having yet another mediatype in the baseline.

Two years later, when I rejoined the Spring Data team, I picked up the mantle of Spring HATEOAS. Oliver’s responsibilities had grown including become the official manager for the Spring Data umbrella. One of my biggest undertakings was to start reading through this Affordances API handiwork and bring it forward. Doing so required months of reading, testing, experimenting, polishing, and coding.

When your pull request gets turned down…again!

My months of effort were clobbered by the inalienable fact that the code had suffered major feature creep. It had also been forked into a couple other branches. Despite months of massaging a pull request that had over 200 commits and getting all of its tests to pass, Oliver and I agreed to shelve that work in favor of starting over.

Yes, I proposed starting over and trying to implement the same concept from scratch. If you want a hint of how long this took, you can see it in the commit logs. Because we squash pull requests, this causes the timestamps to go back to the original, first commit. This image shows code merged on November 29th, yet the commit for the Affordances work dates July 13th.

Ultimately, I crafted a much lighter weight API that allows chaining multiple Spring MVC methods together. With that, Spring HATEOAS can unpack these related links into the right format for each mediatype. For example, HAL-FORMS looks at any POST or PUT methods, finds the input type, and extracts its properties.

Testing an API by using it with another mediatype

So my big test with Collection+JSON was to take this two-year-old effort, rebase it against all of Spring HATEOAS’s improvements, and see if a completely different layout of JSON could be derived from the same vendor neutral representations INCLUDING this new Affordances API.

Step one was to rebase this entire chunk of code. Since it had previously been written against Java 6 and Spring HATEOAS was now on Java 8, that alone was a bit of effort. Several contracts had been altered meaning not all the implementations worked. Had to hammer that out.

Then in the midst of revamping things and reading the spec in detail, I noticed something unfortunate: I had completely misread the format of data. I thought turning a POJO into a simple JSON object was okay:

It looked like Collection+JSON’s “data” field would let any type of nested domain object get turned into a simple JSON structure.

Turns out, Collection+JSON requires a very explicit array of key-value pairs:

This is not nestable unless done out-of-band.

Additionally, it required that I code up the ability to extract property names and values from objects for serialization, and go the other way for deserialization. This is kind of like serializing inside the serializer. Yech! But I got it done. So after several weeks, I managed to rewrite half if not more of my original code and get things working.

Next step–Affordances!

I had to hook into the Affordances API and generate custom things pursuant to this new mediatype. Two years ago, I was very aware of Collection+JSON’s “template” and “queries” sections. And I hadn’t a clue how to populate them. Until now.

This would be the moment of truth at how well I had designed this API for HAL-FORMS. Turns out, the API was quite well suited to handling this.

Coding the Affordances API, Oliver had recommended creating an AffordanceModel and AffordanceModelFactory to allow mediatype-specifics to be neatly encapsulated behind a incredibly simple interface until the mediatype’s serialization code could unpack it. Turns out that was a very good decision.

Debugging the code, I could see that a model was now being generated for both Collection+JSON as well as HAL-FORMS, and I only need one of these for any given situation. Having this complex, detailed code is most important, and handily doesn’t leak into unnecessary areas.

I had allowed some Spring MVC specifics to leak into my HAL-FORMS handlers. That was a no-go, because the whole idea is to have things be tech neutral at this point.

One of my last tests was to have one Spring MVC controller wired up, and have it serve queries for two different mediatypes.

With this in place, I began to engage in classic jürgenization. This has taken me several days. I discovered a missing pair of units (serialize/deserialize custom extension of ResourceSupport) and hence missed a critical corner case. Crisis averted, I have pushed off the final set of commits to Travis CI and submitted it to Oliver for review.

Using one mediatype to develop another

Having built HAL-FORMS, I enjoyed leveraging all the lessons learned to build up Collection+JSON. It gave me a starting point for tests that needed to be written, a nice repeatable pattern of serializers and deserializers that also had to be tackled.

And having just recently performed the work for HAL-FORMS, I was ecstatic that when I solved a particular problem for Collection+JSON, I was able to refactor HAL-FORMS to use the same solution, ensuring consistency between the two.

Every time I work on another mediatype, the whole project gets stronger, better, more reliable. That’s why I can’t wait to circle and resume my efforts with UBER Hypermedia. Most of the work is done. Or at least, that’s how it appeared when I was last there!

But I wanted to let it rest, and circle back. WIth three mediatypes implemented (HAL, HAL-FORMS, and Collection+JSON), UBER will be a real sizzler. After that, SIREN, and then possibly XHTML.

See you then!

The power to say no

One of the most important things we can do is to say no. A lot of things arise in work, in life. And the hardest thing is to sometimes say no. To indicate this shouldn’t be done. To voice our objection. Not argue, just say no.

Since Berlin, I have been working on adding Affordances to Spring HATEOAS. We’re talking a feature branch that has over 200 commits from the original author. The effort was pursued a couple years ago. It stalled out because no one on the team had time to champion this effort. Another team of developers actually forked the branch and added more. Finally, I joined earlier this year and started reading this vast sum of new code.

And I read, and read. And read. And. Read. We’re talking three months of reading, editing, polishing, changing, and rebasing. Did I mention reading?

So earlier this month, Oliver and I have a Google Hangout code review. I have pushed this code as far as I can. I have polished as much as possible. But when it comes time to defend it before my manager, one who maintains almost as high of a coding standard as Juergen Holler, things quickly fall apart.

“I just see piles and piles of code,” Ollie said. And I nodded along. He was right. I didn’t want it to be true, but it was clear. He quickly spotted my sample where both a PUT and a PATCH were shown, the outcome that one method required every parameter, while the other required none.

“Couldn’t we spot the method and flip that bit automatically?” he asked. More nodding from my end. He was gosh awful right. And I knew this current branch of code was never getting near the master branch.

So what did we do with three months of effort? We regrouped.

“What if we start clean? The serializers for HAL-Forms are solid. Why don’t we work on a fresh Affordance API, and see how much of Spring MVC we can leverage to find the other details?” I said.

And here I am, two weeks later, closing in on a feature branch. It includes HAL-Forms mediatype plus a VERY lightweight API for defining an Affordance.

This small bit of Spring MVC + Spring HATEOAS code is lifted from a test case.

  • It’s the handler for a GET /employees/{id} call.
  • It creates two links: self and employees.
  • Using a new method (withAffordances) and a new utility method (byLink), it has access to everything about this the PUT and the PATCH operations, and can glean the attributes needed to run those two methods.

And it doesn’t involve piles and piles and piles of code. I think I spent two days trying to model where these “Affordances” would live. (Ended up in the Link itself, since a Link can have one or more). I spent another day or two digging through the method invocation to build these links, and harvested extra Spring MVC details, like the route, the incoming request body’s type, and a little more.

I think I’ve spent maybe two days ensuring these bits of code don’t intrude on each other. For example, the code that reads Spring MVC annotations isn’t part of the Affordance interface. That will make it easier to write a JAX-RS version down the road. We also need to support Spring WebFlux at some point as well. And the Affordances stuff cannot leak into the mediatype.

So focusing on getting single resource, collections of resources, and pages of resources working has taken a total of maybe two weeks. (Today was the day I got pages working).

Oliver is quite excited about this. As am I. This will set the pace for implementing other hypermedia types. We currently have HAL and are adding HAL-Forms. Coming: Uber, XHTML, and SIREN. And when these arrive, they will become available to Spring Data REST.

Additionally, my handful of PRs I worked on over the past three months are ALSO getting reviewed, so there is indeed a lot of motion of Spring HATEOAS.

I’m really happy Oliver say “no”. Remember, it’s your option to say as well. Just be ready to defend it with all your might.

API evolvability is key in a system of systems

Heh. That tweet was a follow up to Oliver’s latest presentation on the topic “API evolvability is key in the system of systems”. So what does this stuff mean, and why is it important?

API evolvability is one of the core underpinnings we get when we use the constraints laid out in Roy Fielding’s dissertation. And what is that exactly? In essence, the web grew FAST and is a major success. Many of the reasons are that is constrains us in certain ways, thus forcing certain things forward. Web sites are easy to evolve WITHOUT evolving the web browser. The value of this cannot be stated enough.

For decades, developers have faced the issue of evolving APIs. The concept of REST is take some of the underpinnings of the web and take them into API-land. Evolving APIs with similar constraints should make it possible to scale such changes and avoid some of the brittle, backwards-compatible breaks we have suffered for years, which can lead to slow downs in evolution.

How does this tie in with Spring?

I recently moved back to the Spring Data team. I had been on that team before, working on Spring Data REST. A key library that supports it is Spring HATEOAS. In Spring HATEOAS, we have an API meant to build hypermedia-powered RESTful APIs. And due to the incredible popularity of ALL Spring Data projects, Spring HATEOAS hasn’t received enough love.

No more!

Since jumping on this fab team, I have started putting together a list of proposed updates, enhancements, and polishings. Next week, I’ll be in Germany with the rest of the Spring Data team having a coordinated meeting. Among the many topics, Oliver and I will be hammering out this plan to propel Spring HATEOAS forward to be benefit of the community as well as the Spring Data REST community.

And one thing that Oliver has invested much time in speaking at various conferences about DDD, REST, and API evolvability. I have a strong desire to create some sort of code repository, a playground if you will, where people can checkout things and see how to evolve an RESTful API using Spring HATEOAS and the concepts of REST.

That way, we aren’t just preaching a high falutin’ concept, but showing how it can be done.

And I also imagine that in putting together such a repository, we can also find the gaps and holes in Spring HATEOAS. I suppose it’s risky putting this all out in a blog post, but I just wanted to share some of the ideas floating around in my brain as we ramp up support for Spring HATEOAS.

Laptop on a work table with DIY and construction tools all around top view hobby and crafts concept

Spring Boot is still a gem…waiting to be discovered

devnexusLast week, I had the good fortune of speaking twice at the DevNexus conference, the 2nd largest Java conference in North America. It was awesome! Apart from being a total geek fest with international attendance, it was a great place to get a bigger picture of the state of the Java community.

intro-to-spring-data-devnexus-2016A bunch of people turned up for my Intro to Spring Data where we coded up an employee management system from scratch inside of 45 minutes. You can see about 2/3 of the audience right here.

It was a LOT of fun. It was like pair programming on steroids when people helped me handle typos, etc. It was really fun illustrating how you don’t have to type a single query to get things off the ground.

platform-spring-bootWhat I found interesting was how a couple people paused me to ask questions about Spring Boot! I wasn’t expecting this, so it caught me off guard when asked “how big is the JAR file you’re building?” “How much code do you add to make that work?” “How much code is added to support your embedded container?”

learning-spring-bootSomething I tackled in Learning Spring Boot was showing people the shortest path to get up and running with a meaningful example. I didn’t shoot for contrived examples. What use is that? People often take code samples and use it as the basis for a real system. That’s exactly the audience I wrote for.

People want to write simple apps with simple pages leveraging simple data persistence. That is Spring Boot + Spring Data out of the running gate. Visit and get off the ground! (Incidentally, THIS is what my demo was about).

I-heart-spring-AidenI was happy to point out that the JAR file I built contained a handful of libraries along with a little “glue code” to read JAR-within-a-JAR + autoconfiguration stuff. I also clarified that the bulk of the code is actually your application + Tomcat + Hibernate. The size of Boot’s autoconfiguration is nothing compared to all that. Compare that to time and effort to write deployment scripts, maintenance scripts, and whatever else glue you hand write to deploy to an independent container. Spring Boot is a life saver in getting from concept to market.

It was fun to see at least one person in the audience jump to an answer before I could. Many in the audience were already enjoying Spring Boot, but it was fun to see someone else (who by the way came up to ask more questions afterward) discovering the gem of Spring Boot for the first time.

CedricTo see the glint in someone’s eye when they realize Java is actually cool. Well, that’s nothing short of amazing.

The state of Spring so far…

I-heart-spring-AidenI have never been more excited to be a part of the Spring team as I am now. It feels like we are blazing new trails left and right. Seeing the massive turnout this week for Stephane and Brian’s “Spring Boot University”, a 3-hour session at DevoxxFR, left me awestruck. Wish I could have been there.

Everywhere I turn, people are gobbling up Spring Boot. They tell me, this is what they have been looking for. How did this happen? It’s a really neat history.

A little bit of history

The Spring Framework started lean and mean. It was a fantastic way to integrate critically needed tools through its profound power of dependency injection. Some people criticized this as hype, but the community’s massive adoption proved the vitality of this approach. Coding was fun! Demo apps are one thing, but people were using Spring Framework to build large, complex systems. Complex systems need lots of components. Existing APIs like JMS, JDBC, and other things came with the need for lots of plumbing. These APIs were way too low level. And thus was born JmsTemplate, HibernateTemplate, and my personal favorite: JdbcTemplate.

But that was not all. Building web apps with Spring MVC was hot. It made testing app controllers nice and easy. You weren’t obligate to run web-based acceptance tests through complex controls. Instead, you could isolate things. Nonetheless, as the needs of the community grew, so did Spring. To help different parts of Spring grow and evolve and now slow down the core framework. other projects were formed. Spring Security, Spring Data, Spring Integration, Spring Batch, and more. At one point, people expressed their dislike for “spring.jar” containing everything. The Spring team chopped things up into finer grained JARs so you could grab what you needed. Then we had too many JARs. What?!?

As the power and might of Spring grew, so did its learning curve. People were asking which project to use. How to integrate them together. What version of Spring Integration with the version of Spring Framework I’m using? How do I even start using Spring MVC? What steps do I need to carry out?

Spring Boot is born

platform-spring-bootThus was born Spring Boot. Spring Boot brought forth a series of critical concepts.

  • Pre-pick the versions of Spring and other libraries so you don’t have to
  • Auto-configure boilerplate stuff like Spring MVC, Security, Integration, etc.
  • Remove key beans if you define your own
  • Accelerate Spring’s power of externalization of properties to Warp Factor 9!
  • Add on DevOps-ready metrics

A big hurdle was mixing together different libraries. If I have Spring Framework 4.0.1, what version of Spring Integration should I pick? Simple: pick one version of Spring Boot, and both of those dependencies are pre-picked for you. Boot doesn’t stop there. It extends into lots of key 3rd party libraries. This decision was so popular, that Spring IO was created to reach out and harmonize the versioning of 380+ libraries.

A big issue (especially for me, a non-web guy at the time), was standing up Spring MVC. First, you had to put certain bits into web.xml. Then you needed to stand up view resolvers, message converters, controllers, and a whole cadre of other components. You really needed to understand Spring MVC to do it and to do it right. Spring Boot stepped up to the plate and said, “don’t worry, we’ve got you covered”. Add “spring-webmvc” to your project, and Boot will create all that stuff for you. You just create a controller that returns view names, and you’re up and running.

danielskullNo form of automation can ever cover every circumstance. Sooner or later, developers need to break out of the framework’s default position. And this is where LOTS of tools fail on a massive scale. There are two common outcomes: 1) Don’t permit such customization and hamstring future developers or 2) Add so many extension points that the simple use case vanishes. Spring Boot introduces option 3) Drop bits of auto-configured stuff when you create your own. This is known as backing off, and has moved the bar forward on app and framework development really far. New applications and new frameworks will surely adopt this approach to expansion because it just makes sense. If you build a framework and don’t shoot for this, someone starting after you might catch up and pass you because they will.

Something I’ve needed for years before I wrote Java for my day job was externalization of application properties. I dealt with development, test, and production environments. Rebuilding apps for each target was wasteful. So I hand wrote code for that. Spring Framework has always had powerful support for properties files, but Spring Boot took that feature and accelerated the options. Having APP_ENV and -Dapp.env both map to @Value(“${app.env}”) String appEnv or class ApplicationProperties { public void setAppEnv(String env)… } is sheer genius can cannot be understated. People talk about 12-factor apps and high tech wwizbang manifestos, but this concept is simple to grok and applicable just about everywhere. You could be running a close network solution (which I did at my old job) with no cloud involvement and find this technique the Right Thing To Do.

DevOps-ready controls and metrics is something area always begging for. System administrators, program managers, business analysts, and others are always asking for this extra metadata about our apps. Being able to spit out a first cut of this by simply adding one dependency to an application is phenomenal. Then being able to craft your own metrics and controls with little effort ramps your app up to production ready and Management Friendly by providing them the warm fuzzy metrics for clients without breaking the bank of technical debt.

Where are things now?

With Spring Boot spreading across the Java ecosystem over the past two years, it really is exciting to see how much fun people are having building apps. They focus on the end game, not setting up infrastructure. Hearing chatter like “Using Spring Boot is like pair programming with the Spring team” (@starbuxman) and “Spring Boot is just what we need” is cool. I get excited to go the Nashville JUG and talk about some piece of Spring, not just because it “looks good”, but because I can sincerely point out how using it is simply fun! Isn’t that what real software is supposed to be? Functional, carries business value, and at the same time, fun to build and release? It almost feels like Spring Boot introduces yet another rennaisance to application development.

3021OS_mockupcover_normalI have been quite pleased that my previous book, Python Testing Cookbook has earned double the advance over the past three years (and keeps making me money!) But I jumped out of my chair when the first statement for Learning Spring Boot came in last month and showed that over 400 people had bought a copy. My excitement to write about Spring Boot was paralleled by my instinct that people would want to learn about Boot’s secrets.

There is a lot of action happening in the Spring team as we continue to blaze trails we couldn’t foresee five years ago. Many of our key decisions in the past have put us on a strong  footing to continue pushing the envelope for the future in both application power as well as ease of development. The community experience of putting out new features, getting feedback, and generally building something better each and everyday that helps thousands of people solve problems is both inspiring and humbling. There’s no other place I’d rather be working.

Happy coding!

Chapter 2 shows #SpringBoot + #java + #spring #mobile + #jquery. Fun!!!

learning_spring_boot_ch2I just shipped off chapter 1, “Quick Start with Groovy”. Last night, I dug through and updated the code samples along with outputs to Spring Boot 1.1.1.RELEASE, which went out late yesterday. It really is awesome having that effort minimized thanks to AsciiDoc! Basically, I edited the code directly, re-ran the bits where I had captured console outputs so I could recapture them, and made other suitable updates.

Now it’s time to dig in deeper on chapter 2, “Quick Start with Java”. The neat thing with Spring Boot is that what would be usually trimmed down to toy apps due to space constraints can really show off some slick stuff.

ch2_fodtIn this chapter, I am writing an app that will scan multiple GitHub repositories for open issues and print them out on a web page. It shows the name of the repository, a hyperlink to the issue, and the title. I could put more, but I think this gets the point across.

From there, I will ramp up things wicked cool by adding mobile support. I’ll plug in super simple automatic view switching between desktop and mobile views thanks to Spring Mobile. And I will add a mobile view with jQuery Mobile. Given the rise of mobile-based apps, I think this will be VERY appealing to my readers.

And once again, thanks to AsciiDoc, I don’t waste time on typesetting code. Instead, I WRITE the code, and add explanations and details, a lot like writing reference docs. Yum!!!

Having a ton of fun with Spring Data REST + Javascript

Today has been 100% fun coding with Spring Data #REST, javascript, and pics of cats. 🙂 —

Since last fall, I have shifted to working full time on Spring Data REST. This is an amazing project. It takes Spring HATEOAS & Spring Data and combines them together. This way, your Spring Data repositories are exported with an automatically generated hypermedia interface.

What does this mean? Maybe it’s not obvious, but data stored in a persistent repository is now available to desktop web apps, smart phone hybrid apps (those that basically wrap a browser), and native iOS/Android apps.

I’ve spent several months getting up to speed on this project by fixing bugs, adding new features, and adding to the test suite. This has slowly but surely helped me understand how it works. I don’t have it all down, but when we reached 2.0.0.GA, and had the basic CRUD functionality working, I proceeded to write a handful of getting started guides. This way, other people could quickly see through simple examples how to add a hypermedia interface to their existing Spring Data-powered apps.

But for at least six months, I’ve had a vision for where I could take this project. I finally felt I had enough know how to start working on a sample application that would heavily use this hypermedia + some javascript to build a dynamic web app. (NOTE: There are pictures of cats!) That’s what I’ve been working on for the past couple weeks.

Thankfully, we have some super sharp javascript coders on our team. I’ve been able to get solid feedback on my newbie javascript code. And it’s been fun! Javascript has a neat, function-oriented perspective. Instead of focusing on classes, i.e. nouns, I have been writing in terms of verbs. When you click this, do that, then that. It’s a big shift. But I ran into familiar territory when I needed to splice some data together. One of my javascript colleagues told me about reduce(), and when I read about it, I recognized it was the same as foldLeft.

Ultimately, I didn’t use it, because it didn’t fit what I needed, but nonetheless, it was nice to run into javascript’s nice functional APIs.

I have been having an extra dose of fun this past week. My colleague commented, “hey @Greg. looks like you’re having a ton of fun! :)” That was the truth! I just didn’t realize it was so obvious.

I’ve always been a language junky. While I enjoy writing Java full time and am really good at it, I love the opportunity to write code in any language. (Okay maybe not COBOL, but I think you get the idea.)

Hopefully I’ll be able to offer a presentation at SpringOne on this exact topic. It’s not guaranteed, but I’ll see if I can get a talk approved. Now…back to coding javascript!

A day in the life of one Spring developer

Recently I have been cheering each day that I wake up and work on the Spring team. I was also inspired by Ollie’s recent slide show that explained many of our tools we use to build professional grade, open source software. So I thought I might capture my own version of why it’s so exciting to work with this team by walking through a single day – today!

Warming up

I usually wake up between 7:00 and 7:30. I mozy up to get both of the kids and bring them downstairs. I put together some breakfast. After they start eating, I begin sipping my first cup of coffee and check for new email on my iPhone to see what big things I need to look into.

At my old job, I would have been heading out the door by 6:00 and joining the great commute to get across town. Now I get to cash in on that spare time with more sleep. And since most of my colleagues work in different time zones, there’s no rush as to when I start working anyway. Nice!

I saw an email from Gunnar about blogging the new release of Spring XD 1.0.0.M4. I figure when I get back from dropping the kids off at school that I can post some extra tweets to his blog post as well as the new guide I updated to go along with that release.

After I vote up his blog post, I go to my office upstairs, because there’s a 30-minute internal tech talk from Jon about Reactor. It recently went GA, so I’m interested to catch this! I connect to a webex session and then let the meeting call me back on my phone so I can listen in. Pretty neat stuff! I saw his talk at SpringOne and kind of enjoyed that even though it’s Java, he is deliberately using some radical tactics to write terse code (like a statically imported ‘$’ function!)

First real task of the day

Having finished that quick presentation on Reactor, I finally have some space to work on a more detailed issue. Thomas Risberg has posted details about one of our historical announcements of Spring for Hadoop that seems to have been lost while converting the website. There is a detailed discussion on a github issue with everything I need to know. Since they couldn’t find the legacy content, but did find a forum article with the same content, the decision is made to create a permanent redirect to the forum article instead of combing through database backups.

Time to get cracking. I’ve been reading a lot about hub, the handy CLI tool that empowers git to work with github repos. (Get it? git + hub = github.) One of my co-workers told me how incredibly efficient it was and also that it hasn’t caused any issues, so I figure this is a good opportunity to try it out.

Since this is a redirect from the old domain, I have to patch the redirect app, not the website itself. I clone the official version of the redirect app to my laptop. After making sure the gradle build passes with flying colors (with no edits), I then fire up IntelliJ and import the project. It appears there is a handful of automated tests, with one assert for each redirect. Using the info from the github issue, I write a new test case, asserting that the old link permanently redirects to the new one and run it. It fails (as it should). Then I open up the redirect rules file and add a new one at the bottom. The test passes. Yeah!

Time to commit the changes. git + hub is turning out to be pretty neat. I basically craft my pull request right from the command line. I switch over to github and merge it. Chris has already setup a CI job so that when it passes, it automatically deploys it into our cloud foundry production space, and I hear a nice “ding!” on HipChat reporting a successful build. Then I test the old link, and I get nicely forwarded. Since I had embedded “Resolves <issue number>” in the title of the pull request, the issue itself it automatically closed. I delete my branch, and “git pull” to update my copy. Mission accomplished! I flip over to our project manager (something we started experimenting with) and move that issue into the “Done” column.

Work on my issue management prototype

Another thing I’ve been hacking away at for a couple weeks is the means to manage issues from multiple repositories. Roy, Craig, and I spent the entire summer writing 40+ getting started guides, each in separate repos on github. Since we launched all that content at SpringOne, we’ve had people report issues and also submit pull requests to help fix things we missed. The trick is, each guide is in a separate repo. Going from repo to repo to check the status of these issues is cumbersome.

My app uses Spring Boot and Spring Social GitHub to gather a stack of issues and cobble together a web page. It’s still in the infancy stage, but hopefully this can become a handy way to keep tabs on open issues surrounding all the content we have crafted, especially since more guides are being drafted. I can see on HipChat that Dave has responded to my issue with templates and in fact figured out why they weren’t working. He offers a temporary work around. I check it out and it works great! Now I can start making the pages look half decent. (Not being a UI expert myself, I think I’ll use as a tip on how to get started with Thymeleaf templates).

In the process of building my issue management template, I go ahead and submit a pull request to add “html_url” to GitHubIssue. This PR provides a quick way to jump to the issue instead of looking at the HATEOAS-based record. Wow. Again, using git+hub makes submitting this PR fast! I think I could get used to it. BTW, I’ve been getting to grips with HATEOAS, realizing it’s a fundamental piece of REST that is not yet heavily adopted by many. (I’m going to need it when I finally clear enough off my plate to focus on Spring Data REST.)

Time to run some errands, but I stay connected

It appears the clock has rolled around where it’s time for me to pick up the kids from school. I close my laptop and stuff my iPhone in my pocket. I get there a few minutes early, so I check tweetbot and HipChat for any new traffic. I see a few tweets about how people are noticing that Spring talks at the Spring Exchange in London seem to be tilted heavily towards pure Java and no longer sporting much XML. This is nothing new and has been going for several years. But people still seem to assume Spring is heavy on XML!

Nothing important on HipChat. Oh well. I know that if anything critical comes up and someone @’s me on HipChat, my iPhone will chirp, so I don’t feel disconnected. Much better than Skype on the iPhone which zings me every time a message is sent on any discussion channel. We’ve been using HipChat for six months and it’s awesome.

Even though picking up the kids is a forty five minute round trip, it’s no real bother since I feel like I don’t waste my time with endless meetings and instead focus on getting quality software built when I’m at the keyboard.

After getting back and putting the kids down for a nap, it appears one of my colleagues has a new release of Spring for Apache Hadoop. It elicits a chain of “congrats” emails on our developer email list. We often “high five” anytime a new release is put out to the community. Since our team is spread across 12+ countries, it seems like a great way for our team to celebrate releasing early/releasing often.

Other issues crossing my desk

Another issue seems to have popped up a couple nights ago, appeared again this morning, and was finally resolved this afternoon. Our website serves up project information from each project’s gh-page branch. This lets each project manage that content and not require a redeploy. It’s a feature provide by github. You can use anything you want, even hand written HTML, but many people use Jekyll and so do we.

Gunnar first spotted it when he was updating Spring XD’s project page. Spring Gemfire also made a release and saw some issue. Dave has figured out that github made an update to the versions of libraries they were using to render page content. It appears to expose a bug that we had in our pages.

This issue showed up on my desk because I also had to update the core page with the new version info as well. Naturally, both project leads were asking me what was going wrong with page management. I wasn’t sure, and sent out a team wide alert on HipChat asking for assistance. Later on, Phil comes to the rescue by not only tracking down the specifics (he put together our page templates in the beginning), but proceeds to offer a patch to our baseline templates that all the project leads can use to update their project pages. Basically, it’s an issue with a fix that I didn’t have to solve. I just helped to facilitate the conversation.

I work with a great team

I seriously think I work with some of the sharpest people in the industry. I have come up with some decent ideas and coded things to completion. But everybody I interact with keeps me on my toes. Their skill sets are stellar and they don’t require gobs of management to stay on track. We get together occasionally, either on a Google Hangout or using for pairing sessions. Everyone is on their A-game for monitoring blogs, twitter, and other sources of information. Relevant blog entries get emailed around the team. Tweets are passed around. I check feedly where I monitor dozens of blogs, and occasionally a blog post that catches my attention. There is a real buzz working with this team.

A couple days ago, I rang up Rob Winch, aka Mr. Spring Security, on Skype for a five minute chat after tracking down a regression that pointed at new CSRF functionality. He quickly pointed out what needed to change so that Spring Security’s new-and-improved CSRF would work properly in the context of unit testing. While I wrote Spring Python’s security module and feel myself well versed in the core concepts behind Spring Security, it shows what I DON’T know. Not really sure I have a working understanding of CSRF. But Rob does. Good thing he’s on the job!

Every time we meet to either brainstorm or pair up and code, I get a renewed sense of purpose and camaraderie. What’s even more amazing is that these people want to hear my ideas as well! I had joined VMware back in 2010, but was working on a different team. Earlier this year, I joined the Spring team (a dream job in my book). I finally got to meet many of my teammates for the first time, face-to-face two months ago at the SpringOne conference. And it’s only been getting better.

We work with state of the art tools, some of the best innovators, and people that really understand quality software with no junk process. This team has good management, not bogus red tape. I’m just hoping the skills and knowledge of my colleagues is rubbing off on me.

Catch my #Grails talk @springone2gx!

I’m speaking at SpringOne 2GX next month. I invite you to come see my presentation: “Case Study – Grails in the Real World“.

I have been working hard for some time on other material that will be presented at SpringOne. With that stuff briefly off my plate, I have dove head first into getting my presentation ready! There isn’t a lot of time. I got a hold of the template for our slides and have been writing raw material, slowly trying to morph it into a top notch presentation.

What are you talking about?

Most of my presentation is aimed at showing off a Grails app I built about several months ago. The app’s purpose is to serve up maven artifacts for our commercial tc Server product. The latest version of tc Server now has the embedded Tomcat feature, and to use it, many developers are interested in simply adding a maven dependency to their project.

We essentially wanted to provide this feature free to developers, but still track download statistics. So I set out writing a Grails app that allowed you to register by email address and then give you the settings to plugin into your maven build file. It works great! The Grails app is essentially a proxy server. It pulls down the files from our super secret location, and forwards them to the requester.

Growing pains

I went through a lot of growing pains making it all work. You register online with an email address. The app sends you an email with a hashed activation code. You have seven days to activate or the link is thrown out.

At one time, we generated a random hash link that you can see after account activation. Later on, that was replaced with an authenticated REST endpoint with extra steps to configure that for maven.

The whole time, I wanted to share this with other developers that might be going through some of the same pains as me in making it functional, durable, easy-to-use, and able to withstand a barrage of customer-driven mistakes (which always happen!) It was also reminiscent of work at my previous job where I built a 24×7 Ops center that managed a nationwide network. My team ran into a whole host of technical and customer issues, and I’d like to think that my experience there helped shape things on this Grails app.

If you come to my talk, you will get to walk through these various bits of the app and hopefully learn some tactics to help your own development efforts. Given that the production app contains secret email passwords and other proprietary information, I had to make a sanitized version of the app. That is mostly done with just one thing remaining. Hopefully, it won’t take too much work to orchestrate the presentation.

Even if you don’t catch my presentation, I strongly encourage you to sign up for SpringOne 2GX. This is one of the best conferences out there, with some of the best people in the industry coming to speak from around the world.

Spring Boot and other hot releases from Spring!

More hot updates from Spring!

Stay tuned. There are more releases coming!

SpringOne 2GX is coming!

I’m speaking at SpringOne 2GX next month. Come see my presentation: “Case Study – Grails in the Real World“. This is the hottest Spring conference with leading technologist from across the industry. I’ll be super excited to see you there.

P.S. Don’t forget to register before Friday, August 9th at midnight so you can save $200.