What Is It, Really?

What Is It, Really?

“What is it, really?”

Those four words launch a boondoggle.

It starts with smart software engineers. Smart and bored. They’re using a software library or tool to solve a problem. They have a lot of options to choose from. Multiple open source and commercial solutions, high quality, lots of customers or users. But it just isn’t perfect. It’s missing a few things they need and has a few of things they don’t.

So the engineers begin to ponder the nature of this tool. And they start with a gross oversimplification.

  • What is a name server, really? It’s basically a lookup table.
  • What is an object cache, really? It’s… well, it’s another lookup table.
  • What’s an ORM, really? It’s a map between SQL result sets and object fields.

Everything is just a map! And those are all real examples. I’ve seen companies who:

  • ignored Open LDAP, Netscape Directory Server, and Active Directory to write their own name server
  • ditched Ehcache to write their own that crashed the app on any serious load, and nobody knew why (multiple offenders)
  • ditched ORM to write all their queries by hand, seemingly unaware that they could easily use SQL for the 20% of queries that needed optimization. And since they supported MSSQL, Oracle, and MySQL, they wrote their DAOs 3 times. Cut and paste, baby!
  • wrote their own version of Struts with some extra features; then they were stuck on a proprietary Struts 1 clone long after Struts 2, Spring MVC, etc. came out.
  • wrote their own terribly designed version of portlets/JSF/etc. that nobody in the company understood after the creator left (and even he was shakey on it)

I’ll admit, often it’s less boredom than intimidation. You request the feature and the maintainers respond, “That sounds great! The source is over there, let us know when you’ve added it.”

You don’t even look at the source. I mean, it’s gotta be crazy complex. It already does so much. You’re not sure where to start. The developer contribution guide is scant and/or years old.

So you start rationalizing. You’re using just part of this thing. How hard would it be to recreate that? You’d understand all that code because you wrote it. And you could add those extra features you needed.

But you’re vastly underestimating the problem. To start with, the corner cases. I remember a story from Jamie Zawinski about the Netscape/Mozilla rewrite.1 A couple devs were reimplementing the FTP functionality. They had taken a few weeks and had a question about an edge case. He helped them, but the real issue was that the original code was gnarly because it had taken them 6 months to find and handle all the edge cases. And they were ignoring the original code because it looked icky. The same has been said about search code, Unix utilities, ORM, caching, anything with serious concurrency, etc.

Enterprise software companies seem particularly prone to all this. Perhaps because the sales division loves proprietary tools and lock-in.

What I am not saying

I am not saying don’t innovate. Or that you can’t improve things or come up with better products.

  • If you want to create a new open source competitor, go for it. A number of ORMs came before and after Hibernate, both open source and commercial. More will come.
  • If you can build a product and sell it, even though there’s competition, go for it.
  • If you need a small piece of a bloated dependency, and you can knock this out with unit tests pretty quickly, go for it.
  • Are you brilliant, working with other brilliant folks who will vet this idea? And it’s for something of massive scale, like Google, FB, Amazon, or MS would need? Go for it.

What I am saying is that building a one-off of a sizeable, complex component, for just your project, will waste tons of money and become a huge regret for all involved. And it’s always done because of ignorance.

Another way

As a manager, if I have the budget for a new, complex subsystem, I have the money to go to the maintainers of the project causing you grief and say, “Hey, if you agree this is a good idea, how much would I have to pay you to implement it? Are there committers who are available and want to be paid fairly to make this better?” Almost certainly yes. Maybe there is commercial support. The work would be blessed in advanced and fast-tracked for review.

At a minimum, you can hire them to write a proper contribution guide and code walkthrough so your devs don’t crap their pants at the prospect of contributing.

This happens often in projects like Linux. It’s cheaper and causes fewer problems in the long run. But when it comes to developer frameworks and libraries, reinventing the wheel seems like too much fun to pass up.

If you liked this, you’ll appreciate What’s the Developer Experience?

Thanks to Dave Ford and Kiran Manur for hilarious, head-shaking discussions about this. And to Joel Spolsky for probably writing about this 15 years ago.


  1. I’m almost certainly misremembering this, but some fine young cannibal will correct me. I couldn’t find a reference, so it was probably in a book. Coders at Work? []
What’s the Developer Experience?

What’s the Developer Experience?

This is an excerpt from Enterprise Sofware Confidential, my white paper on buying enterprise software without making a huge mistake. 

In this article, you will learn:

  • solid business reasons to care about developer happiness – even when they’re not your employees
  • why so many enterprise vendors produce piles of garbage that still sell

When making a major software purchase, you have a lot of questions. But there’s one that nobody asks, yet is so critical: what’s the developer experience like?

As you read earlier, enterprise software is all about configuration and customization. Your company has proprietary processes to which the software must conform. Or it should. Granted, many times the software is in line with industry best practices and you are not. Changing your processes to match the software is a win/win. But if you’ve invested time and money to create competitive advantages, you don’t throw them away to save engineering dollars.

So no matter the core feature set, there will be a bunch of custom programming to get this thing off the ground. Yet nobody asks if it will be pleasant for the developers. Yes, pleasant! Maybe you don’t care if the programmers like their job. Maybe you don’t like your job. Misery loves company, right?

Kidding! Of course, you care about the happiness of your employees. But in most cases, these are not your employees. They’re at the system integrator or vendor, and you’re paying them a lot to power through it without complaining.

In reality, there are solid business reasons to care about developer happiness, even if they’re not “your” developers. (Note: I’m going to use the word integrator to denote anyone customizing your software. Short for system integrator, but often referred to as professional services or solutions consultants in the biz.)

Golden Handcuffs
Golden handcuffs are what we call the high salaries paid to good engineers so they don’t leave because the work sucks and they are not learning anything new. This cost is passed on to you, of course. And sooner or later, they are going to leave.  Maybe in the middle of your project. Probably to a better platform in the same industry. A lateral move pay-wise, but a raise in enjoyment.

Ill Communication
The experience could be bad because the vendor doesn’t support system integrators well. Poor documentation, no access to the bug tracker, and firewalls between the integrators and the product team. When something goes wrong, it’s on the integrator to prove it to the product team, which is a long and painful process when you can’t talk to them directly. Many eye-rolling questions. (“Have you tried turning it on and off again?”) And that time is billed to you!

A Pile of Garbage
Often times, the reason it’s a bad developer experience is because it’s bad software. It didn’t start that way (I assume). The 1.0 version was pretty good, used the latest and greatest frameworks and incorporated smart design decisions.

Then the sales division took over. If the vendor has to spend a lot on sales, and that team is credited with driving revenue, they amass power. When that mindset grows to the point where engineering can’t make a stand for quality, you’re on a path to a pile of garbage.

Sales will push for new features over fixing bugs. Marketing will mandate deadlines to meet their initiatives (trade shows, commercials, etc.), rather than how long it takes to do it right.

Have you heard of the term technical debt? That’s what you get when you rush developers instead of giving them time to do it right. Quick and dirty is expected every once in a while, but they need time to clean up the mess. In sales-driven organizations, that rarely happens.

Unfortunately, piles of garbage can have pretty long shelf lives. Prohibitive sales costs keep out challengers, and customers rely too much on social proof. Waaay too much.

From a technical perspective, however, I have not seen a product recover from pile-of-garbage status.1 They become notorious among engineers. The problem you’ll have is that engineers aren’t terribly confrontational. Notice that I have not called out any bad actors. Engineers love the truth and want to be honest, but they’re unlikely to openly bash products, especially the ones paying their salary. The good ones simply find better work.

What to do?
I started writing a comprehensive list of questions you want to ask when choosing software. But I don’t want to mislead you into thinking a list of questions off the internet prepares you for shelling out megabucks on software, with answers from dubious sources. If you have a software development background, and bought that type of software before, and oversaw its implementation and use, you’re in good shape. Otherwise, hire a consultant. Doesn’t have to be me, just someone with that experience. Then get them

Then get them to act like a seedy private eye. Wine and dine developers to get them to open up about how much they enjoy the platform. You will be shocked at how many vendors you eliminate this way.

You can comment on Hacker News.

  1. If you have, I’d love to hear about it. []
Enterprise Software Explained

Enterprise Software Explained

I recently wrote a hit article on buying enterprise software, and I was working on the followup when I realized that you, the manager tasked with choosing it, could benefit from an overview from an insider. I’ll explain how this software is packaged and delivered so you can discuss it with more confidence.

Most importantly, this will provide critical context and understanding to my final article, which will arm you with questions and talking points, both internal and external. That’s the one that will prevent you from going all Fahrenheit 451 on your company’s cash pile.

If you think you know all this stuff, please take a quick read and let me know if I’ve left anything out. Thanks!

What the heck is it?

I was a little surprised  the first time an exec asked me, “What exactly is ‘enterprise’ software?” But it’s a reasonable question. In my view, it is software designed to handle the needs of the world’s largest and most complex businesses. This might include:

  • thousands of transactions per second (Black Friday, returns after Christmas)
  • large or complex data1
  • highly complex business logic
  • integration (data sharing and process triggers) with similarly complex systems

How do you write software that can do all this? Well, you don’t create a software package, like Word or Excel. You create a software platform. Something that can be molded and extended to meet your business needs within that specific domain (ecommerce, ERP, CRM, marketing automation, etc.).

SaaS or On Premise?

Software as a Service includes vendors like Salesforce, Shopify, Mailchimp, Google Analytics, etc. They host it, and everyone is on the same system. It’s sometimes called “cloud based” because marketing thinks that’s cool. There might be different tiers of prices/features, and they will likely do something extraordinary for you if you throw enough money at them.

On Premise
The name implies it’s installed on your servers, but it doesn’t have to be. Could be hosted by the vendor, integrator, or anywhere you like. The key is that each installation is a one-off that requires separate installation and maintenance. Almost all on premise enterprise software includes the source code for you to customize, so it can also be a unique snowflake (for better or worse).

OOTB, Configuration, and Customization

OOTB is out of the box. It’s the features you get right after installation and minimal configuration. Like user management, and, um… well probably something else, you did just pay 6 figures for this.

Configuration requires no coding, just enabling features and modifying settings through the user interface. A product expert or business analyst (typically referred to as an administrator/admin in this case) can handle this, no need for a coder.

Note: Salesforce enables a ton of functionality via configuration, to the point where a Salesforce certified “developer” doesn’t do any actual software development (coding). Of course, there is coding you can do for Salesforce (Apex), but why not use confusing vernacular when you can? Welcome to enterprise software.

Customization requires coding. It’s often the bulk of the cost of the software. I frequently see professional services (what they call this work, along with the installation and configuration) running 1x-3x the license cost, which is often 6 figures.

Good enterprise software will have clear extension points (APIs) for customization. Most SaaS software has a web service API for integration. Web services enable your integration code to run anywhere, written in any language on any platform. You have a .NET coder, but the enterprise platform is Java/Linux, or some mystery? No problem. Through the API, you can download your orders, upload changes to your your customer database, destroy valuable data, etc.

A couple SaaS platforms, like Salesforce and Demandware, have a proprietary programming language, in addition to their web service. On premise software might have a web service interface, and/or a language API like Java or C#.

None of that is rocket surgery, but takes time to get the requirements right and cover all the edge cases. The problem comes when a core feature is implemented incorrectly for your business and there’s no way to customize it through the API. You have to change the core code (and maybe the database) to meet your requirements. I often suggest changing your process to match the software, if this is possible. But maybe you’re doing it differently because this is a competitive advantage. Or you’ve already changed your process to accommodate another, more expensive piece of software. Implementing this is possible with on-premise software that includes the source code.

Basic Architecture

It’s important to understand, at the 30K ft. level at least, the different parts of the software.

  • Core code: The creamy center. It has most of the functionality and underlying services. It includes the APIs to integrate with other software (say, ecommerce to ERP or CRM) and add/modify features (customization).
  • Admin interface: The interface to configure the software.
  • User interface: What your customers or employees see.
  • External integration code: This uses the web service API, FTP, or other external integration method. This code is stored and run completely separately.
  • Custom code: What you write to add/modify features. It’s typically stored somewhere it uses or overrides – not overwrites – the existing code. Typically. It could include…
    • modifying the user interfaces mentioned (changing the templates)
    • code using the Core APIs to add features and integrate with other software
    • changing (overwriting) the core code, if it’s really needed to support the business

As you’ll see in a second, modifying the core code is a lot like going back in time. You fix one thing, like, you didn’t total your classic car. But you somehow wiped out all the pandas. And we’re at war with Eastasia. (Luckily, we’ve always been at war with Eastasia.)


Upgrades can be very tricky depending on the platform and level of customization. With most SaaS, upgrades should be automatic and you get all the admin UI features and core fixes and improvements. The rest will require enabling through configuration, modifying the user interface, or adding code to access new features in the API. Code using old APIs should still work if they do it right.

With on premise, some of that will be the same. A new version means a new core. You drop it in, run regression tests, and you should get the fixes and performance improvements to the core code, plus any new admin screens.

In both cases, you may have modified the UI. That means your code is overriding theirs, so any features in the UI won’t be available until you add them to your custom templates. With on premise, you may have modified the admin screens as well, so same deal.

Finally, you may have modified the core code.  This means you have to merge your changes with the new core. Which means understanding all the new code, but even the old code may have been changed significantly. Improving existing code is called refactoring and is an industry best practice. Lucky for you, such things are rare in enterprise software. No matter, it’s still a pain, and error prone. When finished, run a smoke test: are there still pandas?

In all cases, upgrades will be vastly aided by running your regression test suite. These are all the end to end tests created by your QA team that prove everything is working as it should, and they should be automated. When a project is running late, QA is the first thing to go. Why not assume we got it right the first time? When it’s time to upgrade, if you scrapped these tests, you’re going to have to factor them into the cost of the upgrade, along with everything else. Also, scrapping these tests means you have bugs you don’t know about, which can be really embarrassing for you.

Or you can continue to ignore proper QA. Just have your interns and office admins run through some basic tasks to see if anything broke. If so, blame it on the vendor. The vendor will never admit it’s their fault, but that’s OK until your CEO wants to be on your conference call.

Welcome to enterprise software.

  1. I find most businesses don’t have true, valuable “big data” despite the hype, but it can be pretty scattered and complex. []
Ask a Repair Shop

Ask a Repair Shop

This is the story of how you’re buying your enterprise software the wrong way. Probably your appliances, too.

This is an excerpt from my guide, “Enterprise Software Confidential.”

This post is also available in Chinese thanks to Xu Zhi.

Some years ago, I had a broken GE washer. Pretty sure I knew the culprit, but if I was wrong I’d waste a bunch of money on a part I couldn’t return. So I called a local repair shop who serviced a number of brands, including mine. “Oh, we don’t repair GE anymore. They’re pretty much throwaways now. When they break, you just buy a new one.”

This shocked me, beyond learning of GE’s quality nosedive.1 If their products frequently broke, wouldn’t that mean a steady stream of work? Then I realized a flaw in human reasoning. The first time it breaks, you blame the manufacturer. The second time, and every time after that, you blame the repair shop. For a repair shop, servicing appliances from a bad vendor can damage your reputation. Upon realizing this, I called him right back. “If GE is bad, who do you recommend?” I got a full education on washers, including a lot of industry dirty laundry.

Since then, every time I make an appliance purchase – vacuum cleaner, dishwasher, car – I go to a repair shop. They’re always excited to talk to someone who will listen. They may even have a used model that will last you for years.  (more…)

  1. Could be better now, but I wouldn’t know. []

Upgrading to Grails 3


I’m upgrading an app from Grails 2.4 to 3.1 and thought I’d take share my thoughts and notes.

First, I want to say that I’m very grateful to the maintainers for all their hard work. I know this wasn’t easy.

Second, I’m not a full time coder anymore. Running a software/staffing company gives me lots to do. So although I’ve been doing Grails for a few years now, and Spring/Hibernate before that, consider me a casual user. Still, I have opinions – don’t we all? I’m sharing them because I want Grails to thrive.

As you know, Grails began as a way to make Spring/Hibernate development much easier. Over time, it grew a wonderful ecosystem, but it’s still Spring/Hibernate at its core.

When Spring 4 was launched, I attended an event where all the new features were explained, along with Spring Boot. The Spring people were very excited. But I kept thinking, “This is nice, but it’s still well behind Grails.”

The problem is, SpringSource made a lot of changes under the hood to deliver those features. And Grails, being a layer on top, had to be rewritten to remain compatible and up to date.

That means this upgrade is a necessary evil. Because I left Spring for Grails a few years ago, for me it means work and frustration with no benefit. That’s not meant to be an insult, but rather a compliment to Grails 2.x, which worked so well for me and thousands of others. I know the maintainers didn’t have a choice, but at no point during my Grails dev did I ever think, “Gosh, I wish Grails had a completely different architecture under the hood. It’s really holding me back!” Most of the Grails devs I talk to feel the same way. So I’m sorry this post isn’t quite ebullient.

I’m doing this now because I know this is the future,1 and doing it with a project still in development will be way easier. I have another an app in production and I want to take the lumps with a pre-launch project first.

Docs on upgrading are decent, but I had a lot of questions it didn’t answer. Hopefully this is helpful.

New Tech

Grails 3 incorporates the following technologies you’ll have to understand:

  • Gradle (replacing Gant)
  • YAML
  • logback (replacing log4j)
  • Asset Pipeline plugin

Gradle does seem to be a improvement over Ant (and I never liked Maven), but the Grails build system always worked great for me. YAML and logback seem simple enough, but I don’t see the value added, especially after hosting a talk on log4j 2, which looks great.

Asset Pipeline is a hands down win, and something you should be using in 2.x if you’re not already. I know a lot of people are still using the Resources plugin, but it’s time to move on.

I’ll add that the command line expects you to be running with JDK 8. run-app crashed immediately with a bytecode error and the answer was to set the GRAILS_OPTS environment variable to “-XX:-UseSplitVerifier -Xverify:none”. Later, I simply changed my JAVA_HOME to JDK 8, which doesn’t need that. I think we’re all ready to move on to Java 8 now anyway.


Update: I want to share some inside info from a JetBrains employee. JetBrains uses votes and social media (Twitter complaints) to prioritize work. The Grails community has been pretty lax in voting for IntelliJ issues, hence we’re seeing core functionality like reload/debug half-broken for Grails 3. Please upvote issues, and comment if an issue is holding you back.

The Grails community is unanimous in it’s support for IntelliJ, and I previously wrote about why it’s better than GGTS (Eclipse). I believe GGTS has been discontinued as it was maintained not by the Grails team, but by the SpringSource tools team that makes STS. If your employer was too cheap to buy you IntelliJ before, you have an ironclad argument now.

I had to upgrade to the latest version to use Grails 3. I had put this off because I knew the Grails view was missing. Now it’s there for Grails 2 projects, but not 3. I didn’t realize how helpful it was until I lost it.

I used it to create my project, since in Grails 3 you create a blank project and copy your old project into it. First thing you need to do is pull up the Gradle tool window and click the refresh icon. As brilliant as IntellliJ is, it’s too dumb to realize this is a Grails project, even though it just created it. It thinks it’s only a Gradle project until you pull up the Gradle tool window and click the refresh icon. After this, you’ll see the Grails menus and your app available in the run configuration menus. Absolutely critical, yet not in the docs or automated for you, leaving some confusion.

Once Gradle is refreshed you can use the usual way of running it, but that has a glaring bug – environment variables you set in the run configuration are not passed on! This is a big deal, as you’ll read below, because environment variables are the standard way to do external config now that specifying files is not supported out of the box.

To get around this, use the Application run configuration. Go to ../grails-app/init and right click on Application.groovy to run/debug. Note: this is not your config file. That’s under conf, with a lowercase ‘a,’ see below.

However, there’s another problem – if you need to test SSL connections, you need run-app -https, and as mentioned that doesn’t work with environment variables. Since it’s local, I’m running with an insecure channel, but I’d like that fixed.

environments {
    development {
        grails.plugin.springsecurity.secureChannel.definition = [
                [pattern: '/**', access: 'REQUIRES_SECURE_CHANNEL']

IntelliJ is so smart it notices when you’re using something without the source and docs, and suggests you grab it.  That is terrific.

But like the Gradle refresh, it also does things that are confusing. If I click on just about any file, including settings.gradle, the editor tab shows the file name. But when I click on build.gradle, the tab has the app name. I know I’ll get used to this, but it adds to the learning curve. And I’m chuckling as I write this and realize this is trivial compared to the fact that I now have to learn Gradle. Hey, at least it’s not Maven 🙂

Update: auto-reload broken?
I find that auto-reload on edit is now broken. Not sure why, but as linked there is a similar issue. Auto-reload works fine when I run ‘grails run-app’ on the command line. I can run that in the background and edit with IntelliJ, but I can’t debug. Losing the edit/test cycle with the debugger means troubleshooting is much slower now, especially with controllers, which are a real pain to unit test.

Update 2: Workaround (Thanks Josh!)
I’ve done more investigating. Basic reload via the grails run-app configuration works. However, there is a significant disconnect between the editor window and compiled code – the editor uses the code built on startup when determining if a line can have a breakpoint. So if you change the code and want to set a new breakpoint, it won’t work

In the comments, Josh pointed out that it was working for him when run via Gradle. Follow the docs to run/debug via Gradle. It worked, but I couldn’t find the console output. To see it, in the Console window that is showing Gradle tasks/times, click the toggle button with the tooltip “Toggle tasks executions/text mode.” Now you’ll see the console output.

Note that this still does not allow you to run via HTTPS like with run-app. It’s good enough for now, but please upvote this issue to make it better for everyone.


Grails 3 introduces an application.yml file that is used by default. Even though the docs describe it as “an alternative format,”I have found at least one setting that must be set in application.yml:


We do not have a definitive list of what must be defined in the YAML file. That is the only one I noticed, but there certainly could be more. If you’re going to use application.groovy, you may want to add a check in BootStrap.groovy and exit on missing settings.

So why was YAML chosen? Because Spring Boot uses it, and according to Graeme Rocher it’s fully machine writable where Groovy sometimes isn’t (or not easily). But for whatever reason, the helpful comments in Config.groovy are gone. If you’re upgrading, you can just copy them all over.

If you’re converting to Groovy or vice versa, this SO question may help:


One thing you’ll need to change is your defaultPackage, since Grails create-app doesn’t ask for it. I had originally converted all the YAML to Groovy, then found defaultPackage is ignored when in application.groovy. For now, this is my whole application.yml, but expect I’ll need to add more:

        defaultPackage: com.madeupname.web

Which takes precedence if you use both? Short answer is “don’t do that!” Make sure there is zero overlap between the two config files. You won’t get an error or even a warning, and in my test YAML consistently overrode Groovy, but you can’t assume that will always be the case. The recommended approach is to stick with application.yml and use Groovy whenever you need to programmatically set values. You’ll also have to keep an eye out for plugins modifying either file.

If you need external configuration files, you’ll have to do some hacking. I recommend reading this thread on the dev list. But the general recommendation is to use system variables/command line arguments (which take precedence) or environment variables (see Spring PropertySource). This is probably what you need to do if you’re deploying to a PaaS like Elastic Beanstalk, Cloudbees, Jelastic, etc.

Update: external config
Thanks again to Josh in the comments, I found very clear instructions from Haki on how to enable external config in Grails 3, and it’s pretty easy. As instructed, I added the VM option to my run config, updated my Gradle config file, and made sure the format was YAML. Maybe you can use Groovy config for this, but I played it safe.

With reload not working properly for debug in the Application and run-app run configs, you have to use Gradle, which requires external config files because IntelliJ doesn’t support setting environment variables for Gradle tasks.

So it would be great if you could upvote this issue to support environment variables.


Because of the sweeping changes to the architecture, most (if not all) plugins need to be updated to work with Grails 3. In many cases the change is small, but you’ll want to check what the latest compatible version is.

Unfortunately, the Grails plugin site, while improved, still has issues. The good news is that it separates Grails 3 compatible plugins. The bad news is that the current version could be way off. For example, Spring Security UI needs a lot of supporting libraries, including Hibernate4 plugin. You can find it here:


Problem is, the actual latest version is 5.0.7 and definitely not 5.0.0.RC1. There’s also no clear list of required and optional dependencies, you need to look to the plugin docs for that. If an official/core plugin has the wrong version listed, I’m forced to distrust every version on the plugin site. I’m also wondering how that info is added, and I suspect it’s manually, since the fields plugin has its source and issues links reversed.2

Another concern is that after a year, the Grails 3 compatible Mail plugin is still a release candidate, and Spring Security UI is just a milestone release. This is going to give a lot of people pause when considering upgrading.

The MailService class changed, but it’s no longer needed. Config is largely unchanged, except for the environment variable placeholders. This is for Gmail:

grails {
    mail {
        host = '${MAIL_HOST}'
        port = '${MAIL_PORT}'
        username = '${MAIL_PASSWORD}'
        password = '${MAIL_USERNAME}'
        props = ["mail.smtp.auth":"true",
grails.mail.default.from = "[email protected]"
grails.mail.default.to = "[email protected]"

You have to change very instance of:

static scaffold = true


static scaffold = <em>Classname</em>

I also found a potential bug where the configuration setting domainSuffix is only changing the model name and not what is expected in the view. The workaround is to remove the domainSuffix setting and update all your controller responses to remove the word “Instance.” So companyInstanceList would be changed to companyList, and the same with count, etc.

Spring Security
I use S2 core and UI plugins, which must be updated. For S2 UI, you must specify plugin and library dependencies. In particular, you need to specify a number of GORM libraries, and it’s not clear why. The docs do not list in one place every plugin you (likely) need. Here’s my build.gradle config for both plugins:

compile 'org.grails.plugins:spring-security-core:3.1.1'
compile 'org.grails.plugins:spring-security-ui:3.0.0.M2'
compile 'org.grails:grails-datastore-core:5.0.7.RELEASE'
compile 'org.grails:grails-datastore-gorm-support:5.0.7.RELEASE'
compile 'org.grails:grails-datastore-gorm:5.0.7.RELEASE'
compile 'org.grails:grails-datastore-simple:5.0.7.RELEASE'
compile 'org.grails:grails-datastore-gorm-hibernate4:5.0.7.RELEASE'
compile 'org.grails:grails-datastore-gorm-hibernate-core:5.0.7.RELEASE'
compile 'org.grails.plugins:mail:2.0.0.RC6'


It’s not config, but I had a class in src/groovy that used the @Validateable annotation, and now wouldn’t compile. You need to make it implement the Validateable trait (interface) instead.

Looking back, it does not seem that bad, but without knowing any of the above it was an exercise in frustration. Hope I save you some trouble!

  1. Kind of like when I moved from Subversion to Git. []
  2. While the main Grails site has a button to fix any page, the plugin sub-site does not, and there’s no docs to fix plugin data. []

Notes From Thee Linux Conference (SCALE 14)

I attended SCALE for the first time this past weekend and highly recommend it. They had not only talks, but all-day training sessions for which you would reasonably expect to pay hundreds of dollars. I also got to meet Jenkins founder Kohsuke Kawaguchi, Apache Bigtop founder Konstantin Boudnik, and Randal L. Schwartz, whose Learning Perl I referenced countless times back in my Perl days. Plus I got to spend quality time with good friends.

Here are my notes from talks. I’m no longer in admin/DevOps, so I picked talks that piqued my interest.

Scaling – from Joel Salas of HauteLook
They are an ecommerce site that has to deal with high burst traffic. It’s LAMP, so not entirely applicable to my stack (Grails), but there were some good tips that many high traffic sites could use:

  • Tuned, a Linux daemon that collects data and allows you to set optimal system defaults that can have a big difference.
  • He prefers Gatling over JMeter for load testing. (I’ll note I’ve had good success with the latter, but never hurts to learn about new tools.)
  • Varnish, in addition to a CDN.
  • SolrCloud for search.

Postgresql EXPLAIN PLAN – from Josh Berkus of Red Hat

Postgresql for big data/data science – from Jim Nasby

  • Slony and Londiste should no longer be used
  • Can scale to 80+ cores
  • pg_shard – for sharding/replicating PG tables
  • cstore – columnar data store
  • PGStrom – allows PG to utilize the GPU
  • PostgREST –  give any PG DB a REST API
  • Toro DB – Mongo DB compatible JSON document DB, but built on Postgresq. Can save you a ton of space and I/O.

Dart by Randal Schwartz

  • Looking really good, lots of progress made, in use on big projects (100+ devs) at Google
  • Works on Node.js
  • Lot of work into making it compile into readable JavaScript
  • Great features taken from Java: types, reflection, concurrency, async futures, streams
  • Removes unused functions on packaging (smaller downloads, e.g., won’t include all of jQuery)
  • Pub is where everyone shares open source packages: https://pub.dartlang.org/
  • Free book to learn, kept up to date: https://www.dartlang.org/docs/dart-up-and-running/