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!
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.
Ubuntu Geek provides a great little guide on speeding up Firefox. A lot of the about:config settings he proposes changing are already fairly optimal on a Mac, but disabling IPv6 seemed to make the most difference on my case.
[From Speed Up Firefox web browser | Ubuntu Geek]
This script logs into your JIRA and creates OmniFocus tasks for each of the JIRA items that are assigned to you, so they sync to your Omnifocus for iPhone, you only have to keep track of one inbox, etc. It only takes a tiny bit of setup.
Continue reading “JIRA To Omnifocus Script”
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”
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:
Continue reading “Concurrency Strategies for Hibernate Caching”
Every assertion should be thought from the standpoint of
- What was expected
- What actually happened
Translation: assertTrue should always, always have a message.
Consider the following:
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:
"Was expecting something like "
+ myController.getSuccessView() + " but was "
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:testing, junit, assertions, java