Yesterday, I decided to pull the trigger on updating to Windows 8.1. It went smoothly, but I couldn't seem to get Octopress working for me. Luckily, Daniel Auger posted a quick snippet (originally posted by @dlobckdotorg) on how to get back up and running. If you're moving Octopress to a new computer, make sure you save that post! Just in case either of their sites go away, I've reproduced it as a Gist here: https://gist.github.com/s992/23d35ebad8e8988c02c5
I first heard about Ratpack about a month ago at Gr8Conf US. I didn't make room in my schedule to go to any of the sessions, but I did add it to my (long) list of stuff to check out. Most things that end up on that list have a 50/50 chance of ever making it into my editor.
Luckily, I found an excuse to check it out - and I'm glad I did. My current project at work requires me to interface with a third party web based API, but that API doesn't actually exist just yet. Using Ratpack, I was able to quickly mock up the API and then code against my mock. Unfortunately (or maybe fortunately!), the application is for work and I can't share it. What I can share, however, is my first impression of Ratpack.
I tend to write stuff iteratively. I'll write a little chunk, then poke at it a bit, then write some more, and so on. The Groovy Console is a great tool for doing so, but one thing that just hasn't "clicked" with me yet is the concept of dependencies, classpaths, and all the dependency management stuff in between (Maven, Gradle, Ivy, etc.).
I quickly found myself frustrated with my lack of understanding, so I got in to the bad habit of just pasting all my classes right into the Groovy Console window and playing around with them right there. As my toy projects grew larger (and especially once they started relying on external dependencies), this became unworkable.
I did some poking around and found three ways to run the Groovy Console from Gradle, which (as far as I can tell) populates the Groovy Console classpath with everything I need for my project.
Occasionally I'll run into someone who is having trouble debugging their Angular application and their first complaint is almost always the incomprehensible error messages. You know the type, they look like this:
You'll see ugly error messages like that when you are using the minified version of Angular. But, don't lose hope! You can find a full error message with a (sometimes) helpful explanation by just hitting the link immediately following
Error: [$injector:unpr]. I find that a lot of people tend to gloss over that URL when confronted with the ugly error. For an example of where that link takes you, you can try this one from the screenshot: https://docs.angularjs.org/error/$injector/unpr?p0=iDontExistProvider%20%3C-%20iDontExist. It's obviously a contrived error for the sake of this post, but it will give you an idea of what to expect.
Now, if you're working in a development environment and battling ugly error messages, you can swap out your minified Angular for the unminified version and get a nicer error:
Now we can see what's going on at a glance (in this case, Angular's dependency injection can't find
iDontExist), but we still have access to the URL in case we need more information.
As I was going over my tentative itinerary for GR8Conf (my first Groovy conference!), I spotted a session titled, "Functional testing your Grails app with GEB." The session, given by Colin Harrington, will be covering "...what it takes to test your grails application with Geb." According to the Geb website, Geb (pronounced "jeb") is a browser automation solution for Groovy. I've always been curious about browser automation, and Geb's easy-to-read syntax really piqued my interest. I decided to dive in to the documentation - The Book of Geb - and see if I could take some of their examples and translate them over to my site.