Category Archives: spring

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 http://start.spring.io 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. 🙂 —https://twitter.com/gregturn/status/448219842056052736

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 http://waffle.io 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 https://spring.io/guides/gs/serving-web-content/ 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 http://zoom.us 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.

Spring Framework releases WebSocket support + SpringOne 2GX around the corner

A lot of hot news is coming from http://blog.springsource.org/.

SpringOne 2GX is just around the corner!

I’m speaking at this year’s SpringOne 2GX conference. You sign up to hear my talk: Grails in the Real World(TM). But that is not all.

There are going to be some of the best developers in the Java/Grails/Groovy community there, ready to give top notch talks. Don’t miss it! Think: Big Data, Spring XD, Grails 3.0, Spring 4, Cloud Foundry, Java 8, Security, Reactor, Spring Data. Cool!

BTW, if you register through August 9th, you will save $200. Get it while it’s hot!

Don’t forget, if you enjoy my blog and catch me there, come and grab me! I am honored to meet you face-to-face.

Bootstrap and jQuery make me look good

I recently was given a task that seemed kind of big for me. I had to generate a web site targeted for a certain with little time. I put off planned vacation time in order to meet this schedule.

Bottom line, I spit out the site, and to top it off, my co-workers were impressed with my work. I had picked three key technologies:

  • Grails
  • Twitter Bootstrap for styling
  • jQuery for incidental refinements
Grails was the ticket to rapidly building a web site that not only was easy to create, but had mature plugins like Spring Security, ability to map some URLs for customized REST points specified in the requirements, and easy ability to manage database evolutions. Grails also comes fully loaded with Spring which through its MailTemplate made it easy for me to build an email-driven registration system.
But Grails was just the beginning. I had been tinkering in my spare time with learning how Twitter’s Bootstrap layout library worked. It was fantastic and let me quickly build a professional looking site. I learned how to use the various classes to lay things out. Then on the input fields, I was able to easily tag required fields. Bootstrap provided convenient validation. I even marked up certain fields using the HTML5 “email” types, and Bootstrap would trap entries that didn’t have email fields and alert the user.
Finally, I needed to force users to scroll through a EULA, and that is where a bit of jQuery did the trick. I had jQuery only enable a checkbox when they scrolled to the bottom, and then clicking on the checkbox would in turn enable the submit button.
All of this may sound like Web Programming 101, but what you probably don’t realize is that for the past 10+ years, I have worked on thick client interfaces using Swing and other things. I am a real newbie when it comes to HTML, CSS, and JavaScript! But tools like these define a whole new style of programming. Based on what I’ve seen, today’s web programming paradigm isn’t the same as what it was five years ago.
That means I don’t need to catch up on how people built web pages 5-10 years ago. I need to learn what people are doing today. And tools like Grails, Bootstrap, and jQuery tell me that this is in my grasp. My fundamental skills as a programmer are still useful even in a paradigm I sidestepped for 10+ years.
Maybe some people would consider my web-based skills impure because I lean on these libraries too much. I admit I probably couldn’t build these things if I had to. But that doesn’t matter. When people were building up the web 15 years ago, they never imagined many of the standard things we use today. And what does it matter? If the site looks good and works, that’s what counts, right?
This makes me excited to work on the “next” website. These tools make it really fun. Even now I’m learning how to customize the look-and-feel of Bootstrap. I’ve already plugged in a custom font. After a bit, I might figure out how to customize the navbar. All good stuff.
Happy programming!