Missing the Link
One of my favorite magazines for keeping up on the business and entrepreneurial world is Forbes magazine. Between the print edition and Flipbook, there is never a lack of good content to read. One article yesterday caught me attention.
The title is Recruiters Say: Avoid LinkedIn At Your Peril. It was about recruiters reinforcing how important a good LinkedIn profile has become for job seekers. I agreed with everything the article said, but they missed an interesting aspect. Job seekers are also using LinkedIn to check out employers and the people who will be interviewing them.
Prior to joining Credera, while I was resume fishing for interesting jobs, I had an interview with JCPenney. The HR recruiter was extremely sharp, and obviously very passionate about her company, so that passion sparked my interest enough to do a phone screen with the hiring manager. We set a date and she gave me the name of the person I would be interviewing with.
My first stop was LinkedIn, where I searched for the hiring manager. The search came up empty. This was a huge red flag. An IT professional and manager, at at a major corporation, who doesn’t have a LinkedIn profile, implies that the person is either an idiot or doesn’t care about their career. When it came time for the interview, the person didn’t disappoint — he was a total bonehead who pretty clearly demonstrated how poorly IT is run at JCPenney. I wasn’t a good match for the job, but this idiot actually made me hate JCPenney.
I could have probably written this guy’s LinkedIn profile after talking to him for 15 min. “10+ years at JCPenny. Project manager with zero technical skills or instincts. Promoted through the ranks via a game of political survivor. Always on the lookout for someone new to blame.”
So LinkedIn is a tool that cuts both ways. In the tech job market, as things heat up, future employees will be using LinkedIn to vette their future prospective employers just as much as recruiters are using it to find future employees. Any company that expects to hire good people needs to ensure their own people put on a good face for the company via LinkedIn, especially the hiring managers. And not having a profile speaks the loudest of all.
The Limits
Erik and I had lunch yesterday with a cool local entrepreneur, Sunny, who has banked his product on Grails. His company also does Grails consulting on the side, so he has several years perspective on using Grails for both his own stuff and for clients.
I was interested in talking with Sunny to discuss the limits of Grails and what had been his experience on things to watch out for. My current Grails project is winding down, and I would like to use it more in the future, so it is always interesting to talk with someone further down the path. Here are some of the nuggets of wisdom he gave us about Grails:
Dynamic Typing
While Sunny appreciates the dynamic nature of Grails, team size can tip it from a benefit to a liability. With more people on the team, he found he was having to write more tests to compensate for an increase in errors from using dynamic typing. Since the compiler can’t pick up all the dumb stuff, a lot of a testing was needed to ensure the correct output. Sunny uses a distributed development team, so not all the developers are sitting in the same room sharing knowledge.
My own guess is that the sweat spot for a Grails team is 3-4 developers working on-site together. As soon as you get too many developers, or they are geographically distributed, the increased productivity of Grails starts to get offset by the extra testing required for simple things that wouldn’t be needed in a statically-typed language. On the plus side, Grails makes it very easy to write tests, but that is still code that needs to be written.
I would imagine this fits in the same sweat spot as Ruby on Rails, so I would be interested to heard from my RoR friends if they see the same issues.
Hibernate
While GORM makes things easy, at it’s roots, it is using Hibernate. That means all the rabbit holes you can go down with Hibernate are just as dangerous in Grails. In Sunny’s case, he has over 100 domain classes in his product, and managing them becomes a chore. The biggest problem is working with deeply nested object hierarchies and cascading updates.
I’ve seen this same issue with straight Hibernate, so it’s not the fault of Grails. One of my prior applications had several eight-to-ten deep persistent object graphs, and it was a total nightmare for doing updates or creating new objects. There was a lot of compensating code around creating the graphs that ended up causing lots of problems when it came time to update an object in the graph. The optimistic locking would get confused and think you were trying to update an outdated version of the master object.
I would apply the same wisdom to Grails as I would to Hibernate: avoid deeply nested domain models.
Performance
I haven’t deployed any Grails applications that handle a high user load, and Sunny’s application is more batch-oriented. What he saw is that Grails got extremely slow in batch operations, mostly due to how Hibernate handled transactions.
He recommended turning on SQL tracing for your hotspots to really see what is going on, and tune appropriately. In his case, he had what he believed was a simple operation, but it resulted in over 20 SQL operations at the Hibernate layer.
This is a danger zone for ORM in general. I’ve seen it on about every Hibernate application I’ve dealt with. Hibernate likes to get chatty, and unless you really pay attention, you can end up with issues that drastically impact your performance under load. If you really care about performance, make sure every SQL operation counts.
Upgrading
I haven’t had to deal with this, but Sunny has worked with applications using about every version of Grails. The big pain is upgrading between Grails versions. Outside the language features that change between versions, plugins are one of the biggest problems. He found that the supported “core” plugins tend to play nicely together in upgrades, but he makes use of a lot of third-party plugins. These plugins end up having version conflicts on transitive dependencies that are painful to sort out.
This is another issue that isn’t specific to Grails, and I’ve run in to on about every large Java project. Java has a rich community, with a billion open source libraries to solve about any need. Unfortunately, you can too easily go into “DLL hell” with your jar files when libraries want to include different versions of the various libraries.
My own preference is to try to stick to the core SDK, be it the JDK, Spring or Grails, and really think hard about what you include. My favorite peeve is including Jakarta Commons just to get a cheap toString() method. You now end up with a frivolous dependency that will end up biting you in the butt later.
Summary
Sunny has been really happy with Grails, in spite of the limitations. He’s looking forward to some of the new Groovy 2.0 features around static typing to eliminate some of the unit testing needs. And it it sounds like Grails is growing. More startups are starting to use it, and it sounds like it is more popular in Europe than here in the states.
Outside the dynamic typing, most the issues he has seen are endemic to any large Java application. Grails still provides a significant productivity boost over any of the other JVM-based options out there.
The Easy Button
I’m about six weeks in to what has turned out to be a medium-sized project, and I’m hating the thought of my next Java project. Why? Because this project is in Grails and it has been such a joy to work with, it will be downright painful to do a classic Java / Spring MVC application again.
This is my third project using Grails. Each project has given me a chance to dig deeper in to the framework. The first project was more as an observer/reviewer and I wasn’t impressed with the outcome. The second project was me writing the code, and it started to click. Now, on the third project, I’m really starting to appreciate the framework.
So why does Grails rock? Here’s a few of the key things I would have a hard time dealing without.
- GORM makes database access infinitely simpler than any of the Java alternatives out there. It is simple to create new domain classes, and also to map to existing databases.
- Validation is dirt simple. I’m using a few custom flyweight objects for a tricky page, and by adding a simple
@Validateableannotation to the class I can make use of a constraints block on my own class. And it ties in with the error messages. - Thanks to the Grails command line, development is super fast. Make changes and they appear immediately. There is no twiddling your fingers waiting on a Maven build script.
- The included taglib is actually pretty comprehensive. I still have a fair bit of custom JQuery code, but even it very cleanly ties in to the Grails controllers for AJAX calls.
My only pain with Grails has been the same one that has vexed Java developers for a decade: the java.util.Date class. This class remains a steaming pile, even wrapped in Groovy goodness. But the solution to this problem is one plugin away. Every sane Grails developer should be using the Joda Time plugin to handle dates.
So Grails is my new shizzle. I plan on using it at the next hackathon, and hopefully will use it for my next project. Any Java developer that hasn’t taken a look at Grails 2.0 really needs to give it a glance and see what they’re missing.
A Parent’s Rage
I’m doing something right now that I never imagined I’d be doing. I’m camped out with a dozen other parents in front of Plano ISD Headquarters, waiting for the doors to open tomorrow morning at 7:30am so I can transfer my daughter into a good kindergarden.
You see, Plano, in spite of being one of the richest cities in the country, has some really bad elementary schools. And my house is about 100 yards on the wrong side of a wrong line. We’re on the very corner of the district attached to Weatherford Elementary. Here’s what Weatherford looks like:
Now I’m sure any family living in Dallas ISD would kill to have a Recognized school for their children, but when you know Plano has so many Exemplary schools that have outstanding education programs, Recognized doesn’t cut it.
The school right across the street from us is Hightower Elementary:
It sits there, taunting us, completely unobtainable. Most the Exemplary schools in Plano are already closed to transfer, so the war for parents is to escape to some of the few remaining Exemplary elementary schools.
The following breakdown shows the challenge Plano ISD is facing:
Weatherford
Hightower
The troubled Weathford is >50% economically disadvantaged. This is stunning for Plano, Texas. And even at an elementary school level, nearly 50% of the students are “at-risk”, meaning there is a high probability the child will drop out of school before completion.
The staff of Weatherford is spending their time encouraging kids from dropping out of school; academics is a hard target to hit. Contrast this with Hightower, where the exemplary rating in so many areas demonstrates their ability to focus on academics instead of the peripheral issues.
So here I sit, one of those crazy parents camping out for the night to try to get my daughter into a good school. Plano is only going to get worse, and this same problem will keep creeping north into Frisco and Allen.
I don’t know the solution. Every parent wants to do the best for their child, but what happens when the other guy’s drive to do the best for their child ends up dragging down your child? Dallas’s solution to this is a vast network of very good private schools. Those with money ensure their children get the best education possible, and those without suffer through with the public schools.
The problem is effectively a two-tier system, with children graduating from public schools in Dallas being woefully underprepared for the future compared to the private school kids. I’d like to think we could come up with an education system where every child has the opportunity to excel and do their best, but I don’t know what it is.
Small World
I’ve been living and working in Plano, Texas, just north of Dallas, for the past 10 years. In spite of Dallas being a pretty large city, the IT world has always felt small. When I meet someone new, the degrees of separation from a common friend is usually only one.
As a hiring manager, this was always a big advantage. There was rarely a candidate I couldn’t get an honest opinion on from a friend I trusted. All the good folks know a lot of other good folks, and there is a great deal of camaraderie among them.
This has always worked out to the advantage of the companies in the area. If they managed to hire a few of the good guys, they could ensure the rest of the IT people they hired were also good. It was a free and easy quality filter.
Now that the local job market has rebounded, this tight network is going to work to the disadvantage of a lot of local companies. With the tight labor market for talented Java developers, the calls and emails that used to be “tell me about John Doe” are now “tell me about Company XYZ”.
Talented people want to work at companies that don’t suck, and now that the market is good, they have more choices. I had a recruiter call me today pitching a spot at a company where one of the friends I work with just left. I knew from him the place was a suckfest, and I didn’t hesitate to tell the recruiter that too. Companies like this, and the one I just left, are going to have a brutal time recruiting and retaining talent based on their word-of-mouth reputation.
Dallas is as small as ever, but after seeing the small world syndrome work to the benefit of a lot of employers, the winds are shifting and a lot of the suck companies in the area are going to have that same syndrome working against them.