JIRA to Task Managers

I used to have a JIRA to Omnifocus Script which fell into disrepair for a bit.

It worked well, but as the Mac modernized itself it ended up with a lot of issues.

So I rewrote it by splitting it into a front-end (JIRA) and back-ends (the different task managers) for Yosemite and El Capitan. Now it’s called JIRA To Task Managers.

The one I use and support is JIRA and Things, which is the task manager I’ve been using lately.

Take a look and have fun!

Have fun!

Stupid monitoring trick: Watch mysql queries fly

Put this somewhere in your ~/bin:

watch 'echo "show processlist" | mysql -u whateveruser --password=mypassword | grep -v "show processlist" '

Now run it and you will have a poor man’s monitor, kind of like top but for MySQL. That coupled with screen (or multiple terminals) may give you some quick and easy piece of mind.

This should give you *a lot* of monitoring automation ideas. It should be easy to put together a shell script that puts it all in a little “important things panel” to use watch on. Sometimes that’s all you need.

Ruby Appscript – Sweet automation

Yesterday a coworker pointed me to ruby’s appscript. I have found it nothing short of amazing.

I love my Mac, and many of us like the idea of automating our software, until we try to use AppleScript to do it. To say that Applescript is professional developer unfriendly is an understatement. I like ruby but to make ruby and applescript talk requires sending strings to osascript in just the right way and getting the output from osascript back. Not a lot of fun at all.

Enter appscript. Appscript is a ruby library that interfaces with applescript seamlessly.

Continue reading “Ruby Appscript – Sweet automation”

Concurrency Strategies for Hibernate Caching

Caching and concurrency management are tricky. If you have a cache that lives in memory but you have updates to the database that the objects originally came from, how are you going to make sure that the cached objects still reflect the contents of the database?

This really depends on what type of data you are dealing with. Data types that are mostly read (news, notices, articles) probably benefit from whatever caching you can provide, while areas of data that change a lot (shopping carts, server status records) probably won’t benefit from caching at all.

Here are the concurrency strategies on hibernate caching explained:

technorati tags:

Continue reading “Concurrency Strategies for Hibernate Caching”

On the topic of assertions

Every assertion should be thought from the standpoint of

  1. What was expected
  2. What actually happened

Translation: assertTrue should always, always have a message.

Consider the following:

assertTrue(mv.getViewName()
    .startsWith(myController.getSuccessView()));

This will only return “assertion failed”. Which is great, but how do we know what happened? If this is buried on one of the lunt automated remote builds, how am I supposed to know what is going wrong? Which is the expected? What actually happened?

A much better version of the same looks like this:

assertTrue(
    "Was expecting something like "
        + myController.getSuccessView() + " but was "
        + mv.getViewName(),
    mv.getViewName()
        .startsWith(myController.getSuccessView()));

Same assertion, but now it tells me more specifically what’s going on and I can fix bugs with it. Once I set this on the test, it becomes easy to see what was going on.

I recently had a Saturday with some other Bay Area developers where we did a lot of thinking about testing, so expect some more advice in the future as I collect my notes.

Remember the goal of unit tests is to “find bugs” (thanks Harry!). An assertion without an associated message merely notifies you that a bug occurred but doesn’t actually “find it”. As you are writing your unit tests, make sure you find it as well.

technorati tags:, , ,