Matt RaibleMatt Raible is a writer with a passion for software. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.
You searched this site for "free sex movies for men non blog". 1,227 entries found.

You can also try this same search on Google.

Life without TV

As a Denver sports enthusiast, April started as a great month. The Nuggets and the Avs both made the playoffs and both appeared like they would do fairly well. Of course, neither of them did and by April 30th, both teams' seasons where over. I watched the final Nuggets game of the season in Seattle and was so disgusted I decided to turn off my TV for a month.

When I first told my kids (who spend 50% of their time at my house), Jack's lower lip started to tremble (mostly because it meant no Wii). Abbie quickly asked "What about the iPad?" I said that was OK and both kids quickly cheered up. I don't generally watch a lot of TV (~10 hours/week), and I grew up without electricity, so this wasn't a huge change for me. However, I do have some shows that I've been following this year. Namely, 24, FlashForward, The Office and American Idol.

For the last 6 months, I've been developing an online video site, so it wasn't long before my brash "no TV" decision turned into a nice opportunity to research other sites offering online video. Here are some observations from my month without TV.

  • Almost no online video sites work on the iPad because of Flash. I get the feeling that most online video sites aren't doing HTML5 <video> because of DRM and progressive download vs. streaming.
  • Netflix is a cool app for the iPad, but most of the streaming content is crap. My kids found plenty to watch, but I never found anything.
  • Hulu is the bomb if they have shows you like to watch.
  • The ABC app for iPad is great if they have shows you like to watch.
  • I watched a lot less movies because I didn't have onDemand and didn't feel like renting/ordering DVDs.
  • I found my laptop offered a better viewing experience than the iPad.
  • My kids found the iPad offered a better viewing experience than my laptop (easier to hold/share).
  • The iPad isn't loud or comfortable enough to replace the modern TV.
  • My TV (and surround sound) offers a much better viewing experience than a computer.
  • Ads on Hulu are short and sweet (15 seconds) and seem to inspire higher engagement because you're willing to wait for the show to resume.
  • My team has developed both a webapp and a native app that work on the iPad, but I was never inspired to use either due to lack of shows I wanted to watch.
  • American Idol was difficult to find online. When I did find it, it was very poor quality.
  • I did not use BitTorrent because I forgot what a good resource it is.
  • I found myself going to bed a lot earlier.

Overall, it was a great experience and I recommend others try it. However, with the Stanley Cup Finals, NBA Finals and World Cup this month, I'm glad I turned my TV back on. ;-)

Posted in General at Jun 03 2010, 08:06:49 AM MDT 2 Comments

Abbie and Jack's Field Days

Last week, I had the pleasure of attending my kids' field days. For those who aren't familiar with field days, it's basically a sports day for elementary schools. The best part of this year's field days was seeing my kids have so much fun with their classmates. Of course, it didn't hurt that their teachers were also smitten with the thought of the school year coming to a close.

I took a few pictures and shot a bunch of video to remember how much fun they had. I know most readers won't enjoy these as much as I do, but I always like posting fond memories on this blog. Below are a couple videos I compiled and enhanced with appropriate music.

I especially like Jack's friend's dance moves at the end of the video below. ;-)

If you have trouble viewing either video here, check them out on my YouTube channel.

Posted in General at May 26 2010, 06:49:39 AM MDT 1 Comment

What's New in Maven 3.0 with Matthew McCullough

Last night, I attended the Denver JUG meeting to hear some excellent talks by Matthew McCullough and Tim Berglund. I took notes during Matthew's talk, but my battery ran out before Tim's talk started. Below are my notes.

Matthew started out by described the differences between Maven 2 and Maven 3. As he began, he emphasized it wasn't a beginner talk, but mostly for existing Maven users that understand how to read a pom.xml and such.

The Roadmap
Commits to Maven 3 have been happening for the last 3 years. Matthew is not an employee of Sonatype, but he mentioned their name quite a bit in his talk. Sonatype has hired several committers (7 that Matthew knows of by name) that now work on Maven 3 full-time. For compatibility with Maven 2, the project has 450 integration tests and they test it against 100s of Maven 2 projects. Maven 3 has plugin classloader partitioning and a legacy simulation layer for old plugins.

The main improvement in Maven 3 is speed. It's been performance tuned to be 50% to 400% faster. Benchmarks (guaranteed by integration tests) include better: Disk I/O, Network I/O, CPU and Memory. Another new feature is extensibility so Maven is a better library rather than just a command-line tool. Now there's a library and APIs that you can use to do the things that Maven does. Plexus has been replaced with Guice and it's now much easier to embed Maven (Polyglot Maven and Maven Shell are examples of this).

Below are a number of other changes between Maven 2 and Maven 3.

  • Syntax: pom.xml still uses <modelVersion>4.0.0</modelVersion> so it can be a drop-in replacement for Maven 2 projects.
  • Validations: poms are heavily validated against common mistakes, warns when plugin versions are not specified (use mvn validate to see issues), blocks duplicate dependencies (examined in same POM only, conflict resolution used otherwise).
  • Help URLs: wiki page URLs now shown for all error messages. One of the first Apache projects to do this.
  • Removals: profiles.xml external file support removed, Maven 1.0 repository support removed <layout>legacy</layout> (it's been 5 years since any commits to Maven 1).
  • Behavior: SNAPSHOTs always deployed with date-stamps, artifact resolution caching has been improved to do less checking (override with mvn <phase> -U).
  • Plugins: version auto-selection favors RELEASEs over SNAPSHOTs (opposite for Maven 2), versions cannot be specified as RELEASE or LATEST, plugins only resolved from <pluginRepository> locations.
  • See the Plugin Compatibility Matrix to see if your favorite plugins are compatible.

Maven 3 hopes to be a drop-in replacement for Maven 2, but non backwards-compatible changes will be happening in Maven 3.1. It's anticipated release is Q1 of 2011 and will likely contain the following features.

  • "Mixins" for direct dependencies
  • Site plugin takes over <reporting>
  • Backwards compatibility by <modelVersion
  • There's a good chance 3.1 breaks compatibility with legacy POMs

Another new thing in Maven 3 is Toolchain. Toolchain a common way to configure your JDK for multiple plugins. There are only a handful of plugins that are toolchain-enabled. User tool chain definitions are defined in ~/.m2/toolchains.xml. To use different toolchains (JDKs), you specify a vendor and version as part of your plugin configuration.

Maven Shell is a high performance console that's a Maven 3 add-on. It's hosted at GitHub to make community contributions easier. It goes on your command line and it offers syntax highlighting and context-sensitive help (by typing ? at the command prompt).

Another major improvement in Maven 3 is Polyglot Maven. Tools like Gant and Buildr have made Maven look ancient, but they've also given it a good challenge. Maven 3 is likely to leapfrog these tools because of its ability to use different languages for your build configuration. Currently, 6 languages are supported. Polyglot Maven is a super-set distribution of Maven 3. It's not shipped with Maven 3 core because it contains all the other language implementations and is quite large. Polyglot Maven also contains a translate tool that allows you to convert any-to-any language. It has a DSL framework with Macros and Lifecycle Hooks. Macros allows for more concise syntax.

After talking about Polyglot Maven a bit, Matthew shows us a demo translating pom.xml to pom.yaml and then running the build. After that, he showed us examples of what a pom looks like when defined in Clojure, Scala and Groovy. Someone asked about file parsing performance and Matthew said different languages would cause a single-digit performance difference as part of your build process. Personally, I can't help but think any non-XML parser would be faster than the XML parser.

In regards to m2eclipse, a new drop (0.10) occurred a few weeks ago and it's one of the highest quality releases to date. It has major refactoring and many performance improvements.

For sample Maven projects see Matthew's Maven Samples.

I very much enjoyed Matthew's talk, both because of his presentation techniques and because he had a lot of good information. While I've tried Maven 3 and Shell in the past, I've been newly inspired to start using them again on a daily basis.

Tim's talk on Decision Making was also excellent. The biggest things I learned were that conflict is good (idea-wise, not personal) and things to look out for between teams (fault lines). Hopefully both Tim and Matthew post their slides so I can link to them here.

Posted in Java at May 13 2010, 03:54:21 PM MDT 1 Comment

Thanks to Seattle for a Great Weekend

One of the things I like the most about my current gig is I get to travel to Seattle every-so-often. I've had a fondness for the Pacific Northwest since I went to high school in Salem, Oregon. That fondness has grown over the years from many visits to family, friends and conferences in the area. A couple weeks ago, I had the pleasure of visiting Seattle once again. While I've been there a few times with colleagues this year, it's been 6 months since I hung out in Washington with my sister.

This trip was mostly work, flying in Wednesday and leaving on Sunday. The work week was very enjoyable: sunny skies everyday, nice running routes and we accomplished our goal. Friday afternoon, we finished a bit early and I enjoyed a scenic Friday Afternoon Office at Edgewater Hotel while waiting for my sister, Kalin, and her wife, Mya.

Spending the weekend with Kalin and Mya was a blast. They have good friends that live in Ballard (North/Hipster Seattle). They were out of town, so we got to enjoy free, hip accommodations for the weekend. On Saturday, we took a long stroll down to the Mariners game at Safeco Field. A relaxing afternoon of baseball ensued, as well as a very fun evening in downtown Ballard. As evidenced by the pictures in this post, many smiles happened as we reminisced, caught up and had fun like good friends do.

Olympic Sculpture Park Kalin and Mya Cool Place to Live We made it! 7.2 miles in 2:24.

Sweet Seats at the Mariner's Game Rally Caps! Midnight Wheeeeee!!

I left Seattle on Sunday with the feeling that it's quickly becoming one of my favorite cities. That feeling was likely nurtured by the combination of great weather, an accomplished mission and hanging out with my super-fun family. Regardless, thanks to Seattle and "the girls" for a great weekend!

For more pictures from this weekend, see Seattle 2010 on Flickr.

Posted in General at May 11 2010, 07:30:53 AM MDT Add a Comment

My iPad Review

Wi-Fi iPad One week before my home computer was stolen from my living room, the iPad was announced. After watching the initial video, I figured I might want to get one. Fast forward to iPad release day. I was skiing with a friend in Winter Park as I was scratching my head trying to come up with good Easter presents for my kids. Then it hit me: An iPad would be an excellent Easter gift for my kids.

I called the Cherry Creek Apple store and asked if they had any left. They said they did, but they'd likely be sold out before the end of the day. I arrived back in Denver around 3 and was 2nd in line at the Apple Store at 3:30. 5 minutes later, I walked out with an iPad. They were sold out of 32GB models, so I went with the 64GB.

CNET has a good about the 5 Reasons NOT to get an iPad. There #1 reason is great: because you don't need one. They're absolutely right, I didn't need an iPad. I wanted a new home computer so I don't have to pack my MacBook Pro back and forth to the office. However, I realized that most of the time I'm at home, I'm not doing much hard-core computing. Most of the time, I'm checking e-mail, reading Twitter or reading articles. So I bought it because it was cheaper than a new home computer, but I also realize it's not a computer replacement.

It's really just a big iPhone.

In every aspect, it's a larger iPhone. Abbie's first words when she opened it on Easter Sunday were "It's a big phone!" It is a big iPhone, but it's much more pleasant for reading articles and e-mail. Beyond that, it seems good for games, but it's certainly not super-duper fantastico. It's a bit heavy; too heavy to read as you would a book. After holding it for an hour or two last night, my left hand started to get sore. Also, its keyboard sucks. Maybe I'll get used to it in the long run, but without the tactile feedback of keys, it can be difficult to type without looking. The other things I don't like about it are:

  • There are very few good apps (iPhone apps work, but they're small).
  • The screen gets dirty quickly and it looks kinda gross when it's not lit up.
  • The Photos app doesn't work at all for me. It says "Updating Library" when I open it, then crashes several seconds later. Maybe I have too many pictures (12.5K items, 28.5 GB).
  • When it's synching with my laptop, it constantly connects and reconnects and makes a loud noise each time.

I took the iPad to work on Monday and received some interesting feedback from co-workers.

There are some good things about it. First of all, it's wicked fast. Apps *pop* and load their data very quickly. Way faster than my iPhone and faster than both my MacBook Pro and the powerhouse Mac Pro I use at work.

I really like the newspaper apps for reading the latest news articles. I'm not much of a news person, but there's a good chance I read more of it because the apps are so pleasing to the eye. Also, the Netflix app sucked me in as soon as I started reading about it. I've bought my kids several movies on iTunes, but there's still not a huge selection to choose from. With Netflix and its live streaming, we have seemingly thousands of movies to choose from and they're all a touch away. The Mail app is also pleasant to use, possibly moreso than Mail.app on OS X and Gmail in any ol' browser.

There's a good bit of me that's underwhelmed with the device, but I think it has a lot of potential when more apps start appearing. It also seems to need some accessories right away: namely a case to carry it in and a shield to keep clean. I could also see getting a stand for it to enhance its digital picture frame feature. If I could plug it into my HD TV, it might even eliminate my need for OnDemand Movies and DVDs.

I think the biggest potential for the iPad is kids, baby boomers and couples. There's a good chance all of these demographics have a real computer in their home, but the head of household doesn't want to spring for two. Take my mom for instance, she wants an iPad for e-mail because my dad always hogs their iMac. My kids aren't that enthralled with it, but it took them awhile to appreciate the Wii and iPhone. With the Wii, it was the Super Mario Bros. game that reeled them in. Same story with my iPhone; they love the games.

My guess is the real attraction of the iPad will be the apps that are built for it. I can't wait to see what developers come up with.

Posted in Mac OS X at Apr 06 2010, 10:51:22 PM MDT 9 Comments

Developing Rich Web Service APIs with Java

This afternoon, I attended Ryan Heaton's talk on Developing Rich Web Service APIs with Java. I've always admired Ryan's work and what he's done with Enunciate. Below are my notes from his talk.

We've come a long way from the WS (SOAP) <-> EJB days. There are many tools that you can use to develop web services today. A Web Service is an API that's accessible over a network via platform-independent protocol. Historical examples of web services (in chronological order):

  • CORBA
  • DCOM
  • RMI
  • SOAP
  • REST

A Web Service is composed of code wrapped with a container and it's bound to a contract. The table below shows the types of web services and their equivalent Java standard.

StandardTechnology
SOAP JAX-WS
RESTJAX-RS
XMLJAXB
JSON???

JAXB is the standard technology used to marshal XML <-> Java. It's annotation-driven, using @XmlRootElement, @XmlElement and @XmlAttribute to translate Java properties to XML.

JAX-WS is a Java standard, outputs classes as SOAP endpoints and it's annotation-driven. @WebService and @WebMethod are the main annotations. @WebMethod is only needed if you're trying to expose a non-public method.

JAX-RS is a Java standard used to expose REST services. Not surprisingly, it's annotation-driven. The class itself needs to be annotated with @Path. Methods are annotated with @GET, @PUT, @POST or @DELETE. If you need to pass in a parameter to a method, you can add a path parameter like the following:

@Path("/{id}")
@GET
public Person readPerson(@PathParam("id") String id);

To specify the possible mime-type outputs of a method, you can use the @Produces annotation. For example:

@Produces({"application/xml", "application/json"})

You can also do this for input methods with the @Consumes annotation.

For JSON, there's no Java standard. However, there's a number of libraries available, including Jackson, Jettison, GSON, XStream. Personally, I've used Jackson and highly recommend it.

The major players in exposing Java code as JAX-WS and JAX-RS services are Oracle, Spring and JBoss. Oracle (formerly Sun) has implemented the JAX-WS reference implementation and it's called Metro (a.k.a. JAX-WS RI). For JAX-RS, Oracle has the Jersey project. For Spring, the JAX-WS and JAX-RS implementation is Apache CXF. JBoss has JBoss-WS and RESTEasy.

There's also a number of custom containers for exposing web services. For example, AMF (implementations: BlazeDS, GraniteDS), GWT-RPC (GWT), JSON-PRC (DWR), Atom (Abdera), OpenSocial (Shindig).

The contract is a very important part of a web service API. It's composed of an Interface Definition Language (WSDL, WADL JSON Schema), Developer Docs (text, context, preconditions, restrictions), example code and client libraries.

Enunciate allows you to create your contract for your web services. It's a build-time WS Development tool. It generates developer documentation and client-side libraries (for Java, C/C++, Objective C, ActionScript and Ruby). It leverages existing specs (JAX-*) and fails fast at compile time.

From there, Ryan gave us a demo of Enunciate and how it could easily create an API website based on JAX-RS annotations.

I liked Ryan's talk and I'm definitely a fan of Enunciate. While I didn't learn anything new, I think there's a lot of Java developers that don't know about the various standards and how easy it is to develop web services. Hopefully by taking notes from Ryan's talk, I'll get the word out a bit more and make more folks aware of Enunciate. On a related note, Sonatype has a good post on how they documented the Nexus API with Enunciate.

Posted in Java at Mar 18 2010, 05:51:00 PM MDT 1 Comment

How We Hired a Team of 10 in 2 Months

Back in December, I started a new contract with Time Warner Cable (TWC). As part of the terms of that contract, it named the following as one of my deliverables:

Assist in identifying, recruiting and hiring additional full-time Web development staff, emphasizing open-source framework expertise.
    - Timeframe: ongoing, throughout the six-month engagement
    - Deliverable: targeting 2-3 quality leads/hires

Since this was a local gig and I always like a good challenge, I asked my client to raise the number from 2-3 to 4-5. Shortly after signing that contract, my project began. Almost immediately, I began spreading the word on Twitter.

When TWC hired me, it was just the beginning of a larger initiative. They were making a number of large changes:

  • Moving from Waterfall to Agile.
  • Restructuring organizationally for functional teams.
  • Moving from ColdFusion to JVM technologies.

To help with the move to Agile, I contacted a good friend, Brad Swanson. Brad is the founder of Propero Solutions and has always had a passion for agile coaching and making teams more efficient. At the beginning of the year, we setup 2-day training class in Herndon, VA to kick-off the Agile Initiative. There were 15 existing developers on the team when I started and 40 people showed up to that initial training. Most of these additional folks were from Product and QA. Brad's message of working together quickly resonated with the group and you could see their eyes light up with their new-found knowledge.

After the success of Brad's training, we leveraged his network to help us find some very impressive coaches to assist with our efforts. We hired two Agile Coaches to start working with us at the end of January.

While our agile movement was progressing in January, I started contacting friends, former colleagues and referrals about coming to work for us. For friends and former colleagues, my e-mail simply outlined the positions available, the exciting opportunity of the project and that TWC was willing to pay very competitive salaries for strong engineers. While it didn't happen immediately, I did manage to convince 4 former co-workers to join me, including the team I built at LinkedIn and worked with at Evite.

Following those 4, most of the candidates we interviewed were referrals or folks that contacted me directly after seeing my tweet. I'm amazed that I never had to write a blog post to advertise the positions.

Once we identified potential candidates, we executed the following process:

  1. Requested a resume (or LinkedIn Profile URL) via e-mail.
  2. If skills and experience looked like a match, we sent a list of screening questions specific to the position.
  3. If screening answers were satisfactory, we'd schedule a face-to-face interview.
  4. We then conducted a face-to-face interview with a list of questions specific to the position.
  5. If convenient, we took the candidate to lunch to explore their social skills.
  6. After interviewing, the interviewers would huddle for 5-10 minutes and give thumbs-up/thumbs-down and we'd right up a summary e-mail for our boss.
  7. If thumbs-up, our boss would contact the candidate, discuss the details and extend an offer.

This process turned out to be a great way to hire a kick-ass team very quickly. You might notice that HR was not involved at all in this process. While we did use them to post jobs and such, we found that our recommendation-based process of identifying high-quality candidates worked much better. HR was able to bring in folks with lots of buzzwords on their resume, but no one knew them or what they were capable of.

Once a person passed the screening questions, our interview focused more on a person's social skills than their technical ability. The first half of the interview was all about their career experiences and what they enjoyed/disliked about employers and projects. The second half consisted of a handful of very technical, hard questions that we expected people to struggle with. If they answered correctly, we were impressed. If they didn't, we examined how they handled explaining they didn't know the answer. It was interesting to see how many people didn't simply answer "I don't know".

One of my most interesting observations of the process was our question about "what was your most enjoyable employment experience and why?" Most folks responded with something very early on in their career, and often it was their first job. This caused me to reflect on our industry and careers as a whole and wonder if people get more miserable as they keep working. It's a shame there's not more folks happy with their current jobs.

By mid-February, we managed to fill most of our open headcounts. We'd successfully hired 2 Agile Coaches and 8 Developers in a little over 2 months. While everyone hasn't started yet, there's several of us now working in my Denver office. We pretty much caught everyone off-guard with our success and we've moved onto our next biggest problem - were do we put everyone? The TWC Broomfield office is building out space for us, but it'll likely take them a few months to complete the project. My office that fits 4 comfortably had 8 of us in their last week. I had to sit on a garbage can when pairing because we'd run out of chairs.

To solve our short-term space constrains, I've successfully negotiated additional space upstairs from our landlady and we've ordered a number of new desks for folks. Our desks arrive Monday and we're setting up pairing stations upstairs next week. All-in-all, it's been a wild ride with a fair amount of stress. Interviewing folks wasn't that stressful, but trying to hire folks while writing code and trying to deliver features for our project was challenging.

We've been emphasizing pair programming and hiring process required a lot of e-mail communication. When we were pairing, we'd ignore our e-mails for most of the day and then have to catch up at night. Once people started on-boarding, we had to figure out the best way to get them started and slinging code. We established an on-boarding plan and we've been able to get everyone running our app on their machines before lunch. We've even had a couple folks committing code by the end of the first day.

This week, we on-boarded 3 of our final 4 developers. I breathed a big sigh of relief that the hiring was over and we could get back to slinging code and making things happen. As luck would have it, I received an e-mail from my boss on Tuesday that the hiring engine is starting up again and we need to hire 6 more developers. While I'm not anxious to start the Hiring Engine again, I am glad to know it works well and it has helped us build a great team. I'm not going to post the positions as part of this blog entry, but there's a good chance you'll hear more about the gigs if you follow me on Twitter.

Posted in Java at Mar 05 2010, 12:01:57 PM MST 5 Comments

Reviews for Grails: A Quick-Start Guide and Kanban and Scrum

A couple weeks ago, I had a business trip from Denver to Washington, DC. Since I didn't have any coding to do on the flight, I brought along a couple books and was surprisingly able to finish them both en route. Tech books that can be read in a single flight are my favorite. Another book I recall doing this with was First Steps in Flex back in December.

The books I read were Dave Klein's Grails: A Quick-Start Guide and Henrik Kniberg and Mattias Skarin's Kanban and Scrum minibook. Below are short reviews of each book.

Grails: A Quick-Start Guide
I've developed a few Grails applications, so I didn't expect to learn a whole lot from this book, but I was pleasantly surprised. Not only did it introduce all the basic concepts in a clear and concise way, it actually made it fun to read. The first chapter does a good job of introducing Groovy; showing you how to use closures and the easy-to-use collections API. From there, you dive into learning about the project, which is actually a real-life web application called TekDays.com. Then the foundational Iteration Zero is planned and executed.

In Chapter 3, you dive right into creating domain classes and their relationships. All the different mapping types are covered: one-to-one, one-to-many and the good ol' many-to-many. Since this is often a difficult part of an application, it's always nice to see how much Grails simplifies it. I liked the Ajax section in Chapter 7 and especially the part where it showed how to do a TagLib to show threaded comments in a forum.

Chapter 7 (Security) was a little disappointing in that it showed how to hand-roll your own security rather than using the Spring Security plugin (formerly Acegi) or the Shiro plugin (formerly JSecurity). I'd especially have liked to see how to do Ajax authentication where a token is generated for the client and included as a header in each subsequent request.

Other than that, I really enjoyed Chapter 10 where I learned how to implement search using dynamic finders, Hibernate's Criteria API and the Searchable Plugin (which gets its awesomeness from Compass). Implementing Compass in Java requires many, many annotations. In Grails, it's as simple as adding the following to your domain class.

static searchable = true

I truly enjoyed this book, especially with its Agile Development patterns that used iterations to get things done. Grails: A Quick-Start Guide is a code-intensive journey that gets up you to speed on Grails quickly and efficiently. It's very much like the framework itself. It eliminates the yak shaving and allows you learn without distractions. Kudos to Dave Klein for creating such an enjoyable and easy-to-read book.

Kanban and Scrum
In my career, I've used Scrum on quite a few projects. Of course, it's not the processes that typically make a team successful. Rather, it's often the gelling of the team members, as well as respect for coding practices that are proven to create higher quality code - specifically TDD and pair programming. Before reading this book, I'd heard a bit about Kanban, most of it from Marty Haught's Lean Teams: Doing more with less presentation.

This book did a great job of showing the differences between the two approaches: how Scrum promotes iterations whereas Kanban promotes cycle time. The most interesting part of the book is the Case Study in the 2nd half. This section shows how a team used various techniques to develop a well-oiled development machine. I think the most important thing to note from this section is how the team was willing to change, learn and grow based on their experiences - in a very rapid fashion.

In my current gig, I'm helping a team of developers move from waterfall to agile processes. We're leveraging many aspects of Scrum and agile by using a coach, iterations, daily standups, TDD, continuous integration and creating "as built" documentation when we finish developing a feature. The "As Built" documentation is something I picked up from working at Chordiant and I've found it to be a great way of education developers (and outsiders) how things were done in an iteration.

One thing we've seen in our first few weeks is that iterations don't work for all teams or individuals. A Kanban model fits much better for them. Having a Kanban board allows them to visualize (and control) their workload in a much more efficient manner. We haven't started implementing actual boards on a wall, we're just using spreadsheets for now. However, we do have two Agile Coaches starting this week so I expect things to improve rapidly.

Back to the book. More than anything, I enjoyed reading this book because it made me excited about the changes I'm helping implement and I believe in many of the practices in both Scrum and Kanban. I enjoy iterations and structured expectations around development, but I can see how Kanban would work better for folks in operations and infrastructure. I look forward to implementing the best parts of both worlds and hopefully a similar Case Study of what worked and what didn't. With any luck, we'll be able to learn, evolve and produce at a much higher level than previous waterfall practices achieved.

Posted in Java at Feb 01 2010, 09:29:40 AM MST 5 Comments

What's your preferred development infrastructure stack?

Over the years, I've used many different source control systems, wikis, bug trackers and continuous integration servers. On many projects, I've been responsible for recommending and helping to install these systems. For the most part, they've often been disparate, meaning there wasn't a whole lot of integration between the various applications. Here's a list of all the different systems I've used:

I believe all of these applications are useful in supporting an efficient development process. When clients have asked me to help them build this type of infrastructure, I've often asked if they wanted to pay for it or not. If not, I'd recommend Trac (since it has a wiki, source viewer and bug tracker all-in-one) and Hudson. If they were willing to pay, I'd recommend the Atlassian Suite (Confluence, JIRA and Bamboo).

These stacks all seem to work pretty well and the Atlassian Suite certainly works great for AppFuse and other open source projects. However, I recently had the pleasure of working at Chordiant Software where we used Chordiant Mesh to collaborate and develop software. Their Mesh system is powered by Jive Clearspace and provides a wealth of tools for each project, including a dashboard, discussions, documents, notifications and widgets providing status + links to JIRA and Bamboo.

Even though Clearspace's rich text editor caused me some early frustration, I really enjoyed the fact that a solid development infrastructure existed. It made it much easier to collaborate, document and execute our development process. I realize that it's difficult to build and maintain a custom development infrastructure stack. Chordiant had a whole team that developed, enhanced and supported their environment. But that doesn't mean it's impossible and not worth striving for.

I think there's a number of best-of-breed applications you can use to build a sweet development infrastructure stack.

  • Source Control: Git
  • Source Viewer: FishEye
  • Wiki: Jive SBS
  • Bug Tracker: JIRA
  • Continuous Integration: Hudson

I've only used Git for a few weeks, but I can easily tell it's better than Subversion. I don't think it's easy to convince companies to switch their source control system, so it's probably not worth arguing if you're already using Subversion. I can also envision using Confluence instead of Jive SBS, but then you lose forum support and have to use something like Mailman or Google Groups. JIRA Studio looks close to my dream stack, except it doesn't support Git or a forum + mailing list system.

What is your preferred development infrastructure stack? Why?

Posted in Java at Jan 12 2010, 09:54:46 PM MST 30 Comments

Grails OAuth and LinkedIn APIs

Back in November, I wrote about how to talk to LinkedIn APIs with GWT. A week later, I figured out how to do it with Grails and contributed a patch to the grails-oauth plugin.

Since then, a few folks have asked how I did it. Since code speaks louder than words, I took some time and 1) verified the oauth plugin works as expected and 2) created an example application demonstrating functionality. You can find the results in my fork of grails-oauth on GitHub. You can also view the example online.

Below is a quick tutorial explaining how to integrate LinkedIn into your Grails application.

  1. Download and install Grails 1.1.2.
  2. Run grails create-app to create your application.
  3. Add the following to the bottom of grails-app/conf/Config.groovy:
    oauth {
        linkedin {
            requestTokenUrl="https://api.linkedin.com/uas/oauth/requestToken"
            accessTokenUrl="https://api.linkedin.com/uas/oauth/accessToken"
            authUrl="https://api.linkedin.com/uas/oauth/authorize"
            consumer.key="XXX"
            consumer.secret="XXX"
        }
    }
    
    You can get your consumer.key and consumer.secret at https://www.linkedin.com/secure/developer. Make sure to set the OAuth Redirect URL to http://localhost:8080/{your.app.name}/oauth/callback for testing.
  4. Download the oauth-plugin, extract it and build it using grails package-plugin. Install it in your project using grails install-plugin path/to/zip.
  5. Add a link to the GSP you want to invoke LinkedIn Authentication from:
    <g:oauthLink consumer='linkedin' returnTo="[controller:'profile']">
        Login with LinkedIn
    </g:oauthLink>
    
  6. Create grails-app/controllers/ProfileController.groovy to access your LinkedIn Profile.
    class ProfileController {
        def apiUrl = "http://api.linkedin.com/v1/people/~"
        def oauthService
        
        def index = {
     
            if (session.oauthToken == null) {
                redirect(uri:"/")
            }
     
            if (params?.apiUrl) apiUrl = params.apiUrl
            
            def response = oauthService.accessResource(
                    apiUrl, 'linkedin', [key:session.oauthToken.key, secret:session.oauthToken.secret], 'GET')
     
            render(view: 'index', model: [profileXML: response, apiUrl: apiUrl])
        }
     
        def change = {
            if (params?.apiUrl) {
                println("Setting api url to " + params.apiUrl)
                apiUrl = params.apiUrl
            }
            
            redirect(action:index,params:params)
        }
    }
    
  7. Create grails-app/views/profile/index.gsp to display the retrieved profile and allow subsequent API calls.
    <html>
    <head><title>Your Profile</title></head>
    <body>
    <a class="home" href="${createLinkTo(dir:'')}">Home</a>
    <g:hasOauthError>
        <div class="errors">
            <g:renderOauthError/>
        </div>
    </g:hasOauthError>
    
    <g:form url="[action:'change',controller:'profile']" method="get">
        Your LinkedIn Profile:
        <textarea id="payload" style="width: 100%; height: 50%; color: red">${profileXML}</textarea>
        <p>
            <g:textField name="apiUrl" value="${apiUrl}" size="100%"/>
            <br/>
            <g:submitButton name="send" value="Send Request"/>
        </p>
    </g:form>
    </body>
    </html>
    
  8. Start your app using grails run-app and enjoy.

As mentioned earlier, you can download the grails-oauth-example or view it online.

One improvement I'd like to see is to simplify the parsing of XML into a Profile object, much like the linkedin gem does for Rails.

If you're interested in learning more about LinkedIn and OAuth, I encourage you to checkout Taylor Singletary's presentation LinkedIn OAuth: Zero to Hero.

Update: I updated the oauth-plugin so it's backwards-compatible with OAuth 1.0 and added Twitter to the example application to prove it. If you're seeing "Cannot invoke method remove() on null object", it's likely caused by your redirect URL pointing to an application on a different domain.

Posted in Java at Dec 22 2009, 03:37:57 PM MST 7 Comments