Ryan Heathcote Engineer. Teacher. Dreamer.

Grails 3 Logging

While working on a Grails 3 application, I needed to access the logger inside a src/groovy class. The solution wasn’t immediately obvious. I found the answer in this Mr. Haki post, although I had to guess a bit because he doesn’t specifically mention logback (or grails, for that matter) in that post. The answer is to add the @Slf4j annotation to the class.

src/main/groovy/com/package/name/MyUtil.groovy

package com.package.name

import groovy.util.logging.Slf4j

@Slf4j
class MyUtil {
    ...
    def methodThatLogs() {
        log.info "Hello World"
    }
    ...
}

Thanks, Mr. Haki!

I thought they were Crazy...

How often have you heard someone describe something someone else wanted to do and say, “At first I thought they were crazy, but over time I realized it was really smart”? The point being: sometimes revolutionary actions are better. Sometimes change is the right thing to do. But it doesn’t always seem sensible. Sometimes, if you are convinced that something is true, you just have to do it – show others. Does this always work? No. But sometimes you have to do the crazy thing before you have evidence it is the best thing – when all you have is theory. Things like the iPhone. Until the iPhone, the potential success of a device with only one physical button and a massive touchscreen was dubious. Now it is a no brainer. I’m sure a lot of people thought Jobs was crazy. But now, they realize he was really smart.

Humans aren’t infallible. The prevailing way of doing things is especially liable to lose touch with sensibility, and yet seem sensible. Sometimes, you have to do something that seems senseless in order to break this trend and change things.

There is a beauty in this: Instead of saying that the prevailing trend is always right, or that the revolutionary is always right, I’m just saying humans are subject to incorrect prejudices. This means that sometimes, when doing something crazy, you could be up against the cynicism of other people for good reason – sometimes you are crazy and you need to come back down to earth. Other times, you are the one who is right, and society is crazy. It’s difficult to tell up front. And for most things, it is worth trying to change things – not for the sake of change, but for the sake of experience. As long as the person who believes in the change is liable for its success or failure.

The final point here is this: If you have an idea that seems crazy to most people – give consideration to why. But remember that at some point you will have to simply swim against the trend until the fruit of your efforts becomes evident.

The Problem with Computer Science Capstone Courses

As a recent college graduate turned (or perhaps still turning) professional software developer, I often find myself pondering my college education and how it could have been better – how it could have more effectively prepared me for the kind of things I do now.

Lately I’ve been pondering the teamwork aspect of working as a developer. It is something that was not emphasized in my education to the extent that I experience it in the organization. And I’m not calling for more group assignments, per se. I tend to have apprehensions about group assignments as they are practiced that would make for a separate post. I think group assignments are exactly not the way teams I’ve worked on have worked. The teams I work on are made of developers of different experience levels and different areas of expertise. I frequently ask my senior devs for help or advice. They review my code. But at times they will also ask me for help when working on a platform with which I am more familiar – or sometimes when they just need the act of asking a question to solve the problem. So group work isn’t exactly the same. Most students are still students – they may know a bit about different things – but you don’t get the dynamic of having a dev with ten years more experience than you telling you how you can make your code actually readable.

The other aspect that I’ve only recently been understanding is the community. A lot of problems are solved in (online) community – between open source projects (mostly) hosted on github, and finding answers to questions (mostly) on stackoverflow, a lot of the time I spend solving problems involves the programmer’s best friend, Mr Google (which takes me to one of the two aforementioned communities regularly). In other words, I gain a lot from the resources the software development community provides.

Though I haven’t contributed to an open source repo in any significant way, I know what code reviews have done for my abilities and confidence as a developer. So I know that a good open source project, with a solid set of people driving it, can provide the same kind of learning to me and others who contribute. I have recently been looking to contribute to a project I am passionate about, Aurelia, and am keen not only to be a part of that community, but to learn from people I would probably never meet on the street.

I have also more recently started interacting with the stackoverflow community. I admit initially I just wanted to boost my reputation so that I could do things. But as I started engaging with the site, I started to realize how my actions can contribute to others the value that I derive from the site – upvoting good answers (because I look at the number of upvotes when evaluating the quality of an answer…). Commenting on questions to add information that is useful. Asking questions, because others might have the same. The key thing I’ve discovered is that interacting with the community, a community that can at times be very harsh, I have learned to communicate better. I have learned to look for information and answers that are meaningful, and I have learned to share those answers in ways that are clear. I’m not saying I’ve finished learning these things – but I can see that I have improved.

Now to connect these thoughts back to capstone courses and teamwork: In a university, you might be able to get the depth of experience by having professors review student code, and encourage team assignments. But professors already don’t do enough research. And professors aren’t on the cutting edge of software development in practice like a good software shop. Or a good open source project. And finally, the capstone course that is supposed to bridge between being a mere student and a real-world developer lasts for only 1 or 2 semesters. Hardly enough time to really practice the community and team interactions that really grow developers.

What if we had students spend at least their last two years, if not longer, doing two things:

  1. Find an open source project you like, and find an easy issue – starting with that, contribute to the project. Instantly, you are able to be mentored by a good programmer, for the cost of your legwork on things that may take time away from the main contributors solving deeper problems. You learn to develop code on a team, not just for yourself. Follow conventions, make things readable, that kind of thing. And take constructive criticism. (I’ve also found with several projects I’ve worked on where I was coming in long after the project had been first deployed to prod – I started out small, doing very simple tasks that I barely understood, and over time I figured out enough to be a major contributor on those projects. Each task taught me a little bit more, and over time, that built).
  2. Find easy stackoverflow questions on things you are learning about, and answer them. The process of researching things you don’t know teaches you. And the process of interacting with people you have never met about strictly technical matters in a place where you want to look good encourages you to learn good communication.

I think that if students started these things earlier in their time in college and kept them up, they would end up being better prepared for lives in the world of software development. They would be better programmers (having been mentored by much more experienced developers), better team players (having practiced working on open source teams), better communicators, and better problem solvers. The other thing is that they would have a body of self-directed contributions (to the open source project) that would demonstrate their skills to potential employers. It is not uncommon for potential employers to ask for links to github and stackoverflow profiles. These places demonstrate skills in a more measurable way than almost any interview process ever could. Why not get students building those before they graduate?

Sanitizing HTML in Aurelia

I am developing a javascript application using Aurelia. I had some trouble binding an HTML containing property to a div. The original code looks like:

    <div class="terms">
        ${object.htmlProperty}
    </div>

Because the documentation for Aurelia is still developing, so I wasn’t able to find a reference item for this. I ended up piecing together the things I needed to know.

This StackOverflow question indicated that you need to use innerHTML.bind:

    <div class="terms" innerHTML.bind="object.htmlProperty"></div>

It looked like everything was dandy just doing that – I even injected <script>alert('some alert stuff');</script> into object.htmlProperty, and got no alerting. But the script tags were making it into the content unobstructed, so it looks like Chrome was keeping things safe, rather than Aurelia.

I had noticed issue 7 and pull request 19 from the aurelia repos, but was having a hard time figuring out what exactly they were saying with that.

Eventually, I found this commit from the pull request which added a sanitizeHTML value converter to the repo. This was noted in the 0.10.0 release notes:

Binding to innerHTML and innerText is now supported. You can use the new sanitizeHtml value converter along with this.

Once I got that detail I was able to get my html property bound and sanitized simply by doing:

    <div class="terms" innerHTML.bind="object.htmlProperty | sanitizeHTML"></div>

From the pull requests there is also a way to specify a custom sanitizer, which, according to PR19, looks something like this:

    <div innerHTML="value.bind: some.prop; sanitizer.call: mySanitizationFunction”

I have not tried this, but something like that should work.

Groovy Quirks

I guess this is probably a good idea – to briefly journal issues I come across here. Maybe they will benefit someone else. Maybe they will benefit me in the future. TODO: turn this into a blog category with it’s own page that links people in here… ;)

So I have a function with a default parameter. This default parameter is a list with one item. A list because the user can specify a list with more than one item. This one item is a bit of a magic number. It’s 200 – you can probably guess why. :) But this doesn’t work:

static final MAGIC_NUMBERS = [200]

Thing getThing(magicNumbers = MAGIC_NUMBERS) {
    doStuffWithMagicNumbers(magicNumbers)
}

It appears, based on this stackoverflow post, that the java constant thing doesn’t like arrays – probably because the thing that is constant is the array pointer, so it’s a constant, but it doesn’t really work. And perhaps it doesn’t work in a default parameter cause ain’t nobody got time for dereffing pointers…

You can hit me at my contact page if you want to tell me I’m daft. But if you have the same problem, sorry. I don’t know what’s wrong. :/