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.

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.

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.

1. 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.
2. Validation is dirt simple. I’m using a few custom flyweight objects for a tricky page, and by adding a simple @Validateable annotation to the class I can make use of a constraints block on my own class. And it ties in with the error messages.
3. 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.
4. 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.

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.

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.

While I’m glad Microsoft is taking these steps, the reality is they don’t have a choice. I was talking with a couple recruiters in the local area last week. They said .NET was the big language during the Great Recession, but now all the work and openings are for Java. The .NET stuff people are looking for is actually for Sharepoint, so not real .NET.

The .NET ecosystem is losing mindshare and the open sourcing of some key pieces of the stack is a way to try to spark some developer interest. GitHub is the virtual public house for coders today, so Microsoft wants to jump on that bandwagon too. In this case, they’re supporting Git, but keeping the hosting at Codeplex, so they’re still trying maintain their alternate universe.

I applaud Microsoft for taking these steps, but I would have been more impressed if they did this two years ago when they were holding a winning hand rather than today where they’re competing with Adobe in a race to the bottom.

I headed down to the flagship Apple store on Knox Henderson and was prepared to be amazed. Much to my dismay, I wasn’t. Yes, the screen is beautiful, and yes, LTE is awesome. But as a happy iPad 2 owner, the device was completely underwhelming.

I still do most my real reading on a Kindle DX, so the iPad 2 is still a device for wasting time. Twitter, Facebook, Flipbook and the rest all look perfectly fine on my iPad 2.

The biggest steal at Apple was the price cut of $100 off an iPad 2. If you don’t have a tablet today, the device to get is the iPad 2. At the current price, it is a real steal and it is this device which really puts the screws to the Android tablet space.

The device I really want is the one I’m still waiting for Amazon to build. So dear Mr. Bezos, listen up! I want an updated Kindle DX. Same size, but with a better eInk display, higher contrast, faster page turning, and lose the keyboard and go with a touch sensitive screen. That would be the device to die for. Unfortunately, I think Amazon is too fixated on the Kindle Fire to really build it.

This was especially ironic, given in the recent past our roles were swapped and I was the guy tempering his enthusiasm with a conservative eye. The whole conversation though got me thinking about what does “bleeding edge” really mean?

I’m pretty comfortable in both Java and javascript. I like hacking with NodeJS and Express, with JQuery Mobile or Sencha Touch on the front end. I started with ExtJS almost four years ago, so I’ve embraced client-side MVC as a tool for web development.

Programming languages are tools for solving problems. I’m a fan of hand tools for woodworking, so I think the tool that best represents a programming language is the wood chisel. A good wood chisel is a beautiful tool. It is able to efficiently carve a block of wood to your vision, similar to how a programming language carves code to meet your technical vision.

Chisels are sharp — scary sharp. An expertly-sharpened chisel makes your typical razor look like a table knife in comparison. Incorrectly using a chisel can result in a nasty cut, in the best case, or a trip to the ER, in the worst case. But that’s the nature of the tool. You need to practice with it a lot to ensure you don’t hurt yourself, let alone get good results.

Programming languages are very similar. Someone inexperienced with a language can end up in the virtual ER of missed deadlines, cancelled projects and unhappy customers. But a master of the language can produce beautiful, maintainable solutions which solve peoples’ problems.

So is the chisel a bleeding edge tool because of the damage it can do? Obviously not. Woodworkers have been using chisels for a millenium. It is the inexperience of the practitioner that can make it, quite literally, bleeding edge.

Programming languages are the same. Putting me on a Python project could end up causing a lot of project bleeding, given I’ve never written a line of Python before. But it doesn’t mean Python is a bleeding edge technology.

There are no bleeding edge technologies — there are simply people uncomfortable with new tools. Usually, someone calls a language or framework “bleeding edge” when they don’t know enough about it to be productive. It’s like picking up a chisel for the first time. That mirror-sharp edge makes it pretty clear you can seriously hurt yourself with it. The master, though, doesn’t look at the chisel as a way to hurt themselves. They see the chisel as a tool in their box for solving problems.

Now that Sencha Touch 2 has reached Release Candidate status, I decided to give it a try for another small side project I’ve wanted to do. I kept the backend the same, using NodeJS and Express, but took the time to dive in and learn Sencha Touch 2 at least enough to be productive.

First off, Sencha Touch 2 has really improved in the documentation area. The docs include a lot more examples, and I found the Jog with Friends sample to be the most useful. The API documentation is also much improved. Each of the classes contains sample code so you can quickly see how to use the features.

On the downside, the documentation isn’t 100% consist on how applications are created. For example, the Ext.Map sample uses the trimmed-down Ext.setup() versus the preferred Ext.application() syntax.

One of the best resources for learning the framework is the SenchaLearn Github repository. This has a lot of tutorial and sample applications. Drew Neil also has an excellent collection of sample applications on his repository. His Sencha-Touch-Boilerplate project gives you a great starting point for an application, making development a lot easier. I used this boilerplate for my application and it works great.

The biggest mental hurdle with Sencha Touch 2 was getting my head around how the MVC components interact. It all came together for me when the notion of refs and controls clicked. In a typical Java / Spring Framework application, URLs are mapped to a controller, which then determines the view to render. In a simple Sencha Touch 2 application, that doesn’t have to be the case, and that is what kept throwing me off.

In a Sencha Touch 2 application, you can specify routes that map URLs to controller actions, but that isn’t necessary in a small application. Instead, you load the Viewport with a view, and the controllers are event listeners around the actions in a view.

For example, here’s my app.js file:

Ext.application({
    name: 'Javamug',
 
    controllers: ['Main'],
    views: ['Main'],
 
    launch: function() {
        Ext.Viewport.add({
            xclass: 'Javamug.view.Main'
        });
    }
});

I’m loading up the Viewport with a specific view and that’s it. In this case, my Main view is TabPanel, and it loads up a bunch of tabs. Sencha Touch takes care of rendering the correct view when you click an icon on the tab, which is a nice time saver.

Here’s what the first page looks like:

>

In one of my views, I have two buttons which are defined like this:

{xtype: 'button', ui: 'green-round', text: 'Yes', id: 'attendButton'},
{xtype: 'button', ui: 'red-round', text: 'No', id: 'declineButton'}

Note I added an id attribute to them. This is what makes controllers easy to use. In my Controller, I define the refs and control properties to capture the events from these buttons and call some methods when they are tapped:

config: {
    refs: {
        attendButton: '#attendButton',
        declineButton: '#declineButton'
    },
    control: {
        '#attendButton': {
            tap: 'attendMeeting'
        },
        '#declineButton': {
            tap: 'declineMeeting'
        }
    }
}

The refs section is create some getters for my two buttons. Since I put an ID on the components, I can use that to map them to the friendly names in my controllers. The result is that inside the controller, I can call getAttendButton() and getDeclineButton() from my code to get access to the button directly without having to navigate some contorted hierarchy.

The control section works in a similar way. I’m using the ID of the components, which get mapped back to the components via the ComponentQuery class at runtime. Inside the braces for each button, I’m defining an event listener for the button’s tap event. In this case, tapping the button with ID of attendButton will call the attendMeeting() method in the controller.

Once I quit trying to forcibly shoehorn the controllers into the process, similar to how I would do in Java, and just let them be event handlers, life got easy. I’m still learning the ropes, and I know it is possible to specify URL routes inside the controllers, but I didn’t have a need to do that in my simple application.

The next hurdle was with the Ext.Map component. I wanted a tab which showed the location of our meeting in a Google Map. I beat myself over the head for a whole evening trying get this to work right. It was complicated by the examples not being consistent. The Jog with Friends, Kitchen Sink and Map Demo samples each do things differently. Complexity was compounded by the fact there is a bug with the Release Candidate with rendering maps on TabPanels.

In the end, I finally got it to work by creating the map in the initialize() method of the view and adding it to the Container manually. The code looks like this (after dealing with the bug):

Ext.define('Javamug.view.Map', {
    extend: 'Ext.Container',
    xtype: 'mapcard',
 
    requires: [
    	'Ext.Map'
    ],
 
    config: {
        iconCls: 'locate',
        title: 'Location',
        layout: 'fit',
 
        items: [
            {
                ui: 'light',
                docked: 'top',
                xtype: 'toolbar',
                title: 'Location'
            }
        ]
    },
 
    initialize: function() {
 
        this.callParent();
 
        var position = new google.maps.LatLng(32.9770421, -96.8270373);
 
        var infowindow = new google.maps.InfoWindow({
                content: 'Improving Enterprises<br/>Addison, TX 75001'
        });
 
        var map = Ext.create('Ext.Map',{
            mapOptions : {
                zoom : 14,
                mapTypeId : google.maps.MapTypeId.ROADMAP,
                navigationControl: true,
                navigationControlOptions: {
                    style: google.maps.NavigationControlStyle.DEFAULT
                }
            },
 
            listeners: {
                maprender: function(comp, map) {
 
                    var marker = new google.maps.Marker({
                        position: position,
                        title : 'Improving Enterprises',
                        map: map
                    });
 
                    google.maps.event.addListener(marker, 'click', function() {
                        infowindow.open(map, marker);
                    });
                }
            }
 
        });
 
        map.setMapCenter(position);
        this.add(map);
    }
});

The mapConfig section was a major pain too. Normally, you can specify a center property which contains the LatLong of where you want to center the map. Except it doesn’t work. My desired center kept popping up just out of view in the top left corner. I finally removed the property from the config and just manually called the setMapCenter() method of the Ext.Map component and that worked.

One thing I don’t like about Sencha Touch is how it handles pages which are mostly HTML text. Stuffing a bunch of HTML markup into the html config element isn’t an elegant solution. Fortunately, the Oreilly demo app has a good way of solving this. They create a new panel which takes a URL in the config and uses the initialize() method to load the content for the URL. The code looks like this:

Ext.define('Javamug.view.Meeting', {
    extend: 'Ext.Container',
    requires: ['Ext.Ajax'],
 
    config: {
        iconCls: 'calendar2',
        title: 'Meeting',
        styleHtmlContent: true,
        scrollable: 'vertical',
        url: 'current.html',
        items: [{
            ui: 'light',
            docked: 'top',
            xtype: 'toolbar',
            title: 'Java MUG'
        }]
    },
 
    initialize: function() {
 
         Ext.Ajax.request({
            url: this.config.url,
            success: function(rs) {
                this.setHtml(rs.responseText);
            },
            scope: this
        });
    }
});

Using this technique, I could use a Jade template in Express to create the “static” content rather than pack it all into the JavaScript view file.

Outside the complexity, there are two downsides to using Sencha Touch. First is theming. This blog post provided the most help in figuring out how theming works. Using the Bootstrap template above also make life a lot easier because it starts with the app.scss and config.rb in the right place and includes instructions in the README.md file on how to compile them.

The second downside is size: Sencha Touch is not a light-weight framework. My CSS, combined app-all.js and framework files came in around 700K for a simple application. I could trim things down by eliminating some of the includes on the theme, but that is still pretty large. By comparison, in my JQuery Mobile application, the framework files came in around 250K in size.

The tradeoff for the larger size is being able to use a sophisticated client-side MVC framework with great looking, and performing, components.

Sencha Touch 2 is a big win for me. I want to work on the file size, but now that I have a feel for the framework, I’m expecting my learning to pick up. I’ll hopefully get a chance to give a whirl on a larger application soon.

The Sencha guys have really knocked it out of the park with Sencha Touch 2. It is, without a doubt, the most sophisticated and polished mobile JavaScript framework out there right now.

I enjoy the hackathon concept for the chance to meet new people, and also to stay geeky. It’s fun to see what you can produce in a weekend with some dedicated focus. The hackathons at the AT&T Foundry are more “bush league”, being nothing like a BeMyApp competition, but it’s still a lot of fun.

For the hackathon this weekend, I decided to jump in and write some code. I was hoping someone pitched something I could latch on to, but that was not the case. And based on my pre-pitch reconnaissance, I was the only person playing in the mobile web space. So I decided to go the army-of-one route and work on a small idea I had. It was basically around mobile enabling the change management approval process for enterprises. The intent wasn’t to make a million dollars; it was just to give me a context to really get in to some of the technologies I wanted to play with.

Here’s what my simple landing page looked like:

Since I was starting green field, I had to make some technology choices. For the web layer, it came down to Sencha Touch or JQuery Mobile. I haven’t written any production quality code with either, so the challenge was getting up to speed quickly and being productive.

Sencha Touch is extremely sophisticated, but it is also much more complex. If you’re willing to invest your soul into it, it can pay great dividends. Since I was going to be hopping through all the layers, I didn’t want to have to do the major mental context switching it required.

JQuery Mobile is a bit cruder, but it follows the web paradigms. You still play with pages, using HTML tags, and the framework deals with the rendering on the mobile device. For how short a time I had, it was a much easier framework to work with and get my head around.

Another big advantage to JQuery Mobile is the excellent theming support via ThemeRoller. I needed some different colored elements for my application and was able to quickly generate them via ThemeRoller.

For the backend, I was planning to go with Grails, but since I didn’t really need 90% of the framework, I opted to go with NodeJS and Express.

Like the web tier above, I have never written production NodeJS code either, so this was really a test on how quickly I could embrace it and get productive with it. I’m happy to say not only was it extremely productive, but I had a blast doing it. The NodeJS/Express combo makes for a blistering fast dev cycle, and I even liked the Jade templates. This will be my go-to combo for future hackathons.

For the storage layer, I wanted to go with MongoDB, but after about 15 minutes I realized the storage didn’t matter for my pitch, so I cheated and went with simple JSON objects on the server side for my data structures. The ease of using JSON structures server-side is one of the other big advantages of NodeJS.

I completed my simple app and a basic Keynote presentation in time for the pitches. I have no delusions of grandeur in the complexity of my app. It was about playing with some new technology, not making the next Facebook. But I still managed to win 4th place out of around 14 teams, so I was pretty happy.

A couple observations on the hackathon in general:

1. The AT&T Foundry rocks. I may despise AT&T Wireless for their absolute shitty network, but they killed it on creating a great environment for startups and these sort of events.
2. The majority of the teams were working on native Androids apps. There wasn’t a single iOS project. I found this really strange, and not indicative of the current market. I’m suspecting it is because Android breeds more of a hacker mentality with its open source nature, but I don’t see the market to justify the investment.
3. There were also a lot more Windows Mobile developers than I expected. I actually expected zero. It might have helped that Microsoft was tossing in some of the prizes and had experts on hand to help. The hackathon winner was a Windows Mobile application. There might be some traction behind Windows Mobile, but Microsoft is so late to the game it will be hard for them to make a dent in iOS. The only advantage to Windows Mobile is it allows mediocre enterprise .NET developers to easily produce mediocre mobile applications.
4. There weren’t any other mobile web developers. This floored me. I still see the future is device-independent, mobile web development with JavaScript and I expected others to be playing in that space. I’ll still keep blazing down this trail.

AT&T is planning on holding Mobile Hackathons quarterly at the AT&T Foundry, so I’ll definitely be doing this again. And next time, I plan on getting much more complicated on the code side.