Why I'm Sticking With Remember the Milk

I'm a list maker by nature - my wife sniggers at me sometimes as I add something to my to-do list that I've already done, only to mark it completed immediately (I like having a record of those things).

For years, my to-do list flow was something like this:

• Remember just before bed that there are a couple important things I need to do the next day.
• Grab a piece of paper (blank paper, a bill, whatever's laying around).
• Make a quick to-do list in the corner, rip it off the full paper and put it with my wallet.
• Come home from work the next day and find the piece of paper with my wallet with most of the tasks undone.

When I got an iPhone a couple of years ago, I decided I was going to start using a better system.

For the past couple of years, I have used Remember the Milk, a fantastic to-do list manager that has a great iPhone application.  It has some benefits and drawbacks though:

Remember the Milk Benefits:

• Easy to use
• Keyboard commands
• Great iPhone app
• Reminders
• Repeating Tasks
• Tasks can be set for a specific time as well as date

Remember the Milk Drawbacks:

• iPhone app requires a $25/year Pro membership
• Email reminders are only for that day's tasks, not for anything that's overdue
• Can't reorder tasks other than using priority or the like

When the time came for renewal of my $25 Pro membership this year, I decided to look around.  My only major requirement was that whatever I did needed to have a native app on the iPhone so it could remind me about tasks.

I discovered Wunderlist fairly quickly, due to the amount of buzz around it and gave it a try.  I really really wanted to like it.  I went all in, migrating by hand my entire existing list of short term and long term tasks.  I gave it a full month before I finally threw my hands up and had to go back to Remember the Milk.

Wunderlist Benefits over Remember the Milk:

• Reorder tasks to your heart's content
• Native Mac App
• FREE

Wunderlist Drawbacks:

• Reminders only worked when adding tasks from the iPhone app (if you set them at all).
• Any tasks added from the web interface don't get a reminder email.
• Can't set a time on a reminder (Call John at 1pm tomorrow)
• No repeating tasks

These drawbacks all ended up becoming an overall deal breaker for me.  I need my to-do list to remind me every month when various bills are due, every 6 months to renew my auto insurance, etc.  I need to be able to be reminded at a specific time about something.  Finally, I needed to be reminded when I had something due, regardless of where I entered the task.

I hope Wunderlist can add these features someday and if so, I'll give them another shot.  For now though, I am happily back at Remember the Milk as a Pro member again.  It's just not that important for me to be able to reorder tasks and save $25/year.

Now if Remember the Milk could just let me reorder tasks and add subtasks into the mix, I'll be a member for life!

Setting up Atlassian FishEye with GitHub

The other day a co-worker asked me if we could point our Atlassian FishEye instance at GitHub repositories.  I did some poking around and after having a hard time finding any specific instructions in any one place, I decided to write a post about how I made it work.

Assumptions

• Admin access to FishEye.
• Admin access to a GitHub repository.
• Git client and SSH client installed on the FishEye server and available in the PATH.

Instructions

1. Login to FishEye, go to Administration -> Repositories and click "Add Existing...".
2. Choose "Git" from the dropdown, give it a name/description and click "Next".
3. Grab the SSH url from your repository in GitHub and enter it into the "Repository Location".
• Will look something like "git@github.com:ORGANIZATION/REPONAME.git"
4. Under "Authentication Style", choose "Generate key pair for ssh" and click "Generate".
5. Copy the resulting block of text into your clipboard.
6. Go to your repository in GitHub, go to "Admin" and choose the "Deploy Keys" tab.
7. Click "Add another deploy key", name it "FishEye", paste the block of text into the "Key" field and click "Add Key".
8. Back in FishEye, click "Test Connection" and if all is well, click "Next" and then click "Add".

You will very quickly start seeing that the GitHub repository is being indexed and when done, you'll be off to the races!

Tools

Every time I do a home improvement job, the same pattern repeats itself.  Every. Single. Time.

I start out trying to "make do" with the tools I have on hand to save myself some money and trips to the hardware store.  In the end, after much time, frustration and cursing (if the job involves plumbing, my mortal enemy), I find myself over at the hardware store buying the tools I actually need to do the job.  I come home, try things again using the right tool and am amazed at how much easier it was to do with the proper tools.

Case in point - this weekend I was installing a nice big cast iron sink in the kitchen and needed to reroute some plumbing to handle the upgrade from a single basin to a double basin.  My groove joint pliers weren't big enough to handle the nut on the new drain and I spent way too much time trying to mess around with alternative options before breaking down and grabbing a nice big 16" set at Lowe's.  While I was there, I grabbed a head mounted flashlight as well - what a difference that makes!  I finished the job in no time with a nice large set of pliers and a well lit work environment (no more balancing a flashlight against the side of my head while I work on my back under the sink).

This got me thinking about software and techniques for my "real" job.  I don't have the benefit of water spraying in my face and raw knuckles to force me to realize that I'm using the wrong tools.  Where might I be trying to get by with the wrong tools when I could change things up and use the right tool for the right job?

I don't have an answer yet, but I think it's time to evaluate what's working and what's not and ruthlessly trim/upgrade to reduce wasted time and energy.  Look for a future report about what's working and what's not.

Atlassian Summit 2011 - Call for Speakers!

Atlassian is looking for speakers for their annual Summit in June - do you have a good case study to share?  The deadline is March 1st, so if you want a free ticket to the Summit, submit an abstract for a talk ASAP.

http://summit.atlassian.com/speakers

I run the local Atlassian User Group in the Washington, DC area - if you get a talk accepted, contact me and I'll see if we can schedule you for our next meeting in April/May to get a chance to try it out on an audience!

Putting Google Maps In Its Place

Did you know that Google Maps is not perfect?  I know, I know, crazy, but it's true!

A few months ago, while trying to map out a different route to visit a family member in Kinsman, Ohio, I realized that Google Maps thought that Kinsman was somewhere in Southeast Ohio.  This is completely incorrect (Kinsman is pretty far up in Northeast Ohio) and it made it really difficult to get directions.  In fact, even if I used the full street address with zip code, Google kept throwing me to the wrong location.

So, I decided to try out the "Report a Problem" button and ask Google to put it in the correct place.  A couple weeks later I received an email confirming that I was correct and a couple months after that, Kinsman was back in its proper place.  Yes ladies and gentleman, I moved a city across the state of Ohio!

Looking at various news sources online, it would appear that this is not an uncommon problem.  CNN reported back in September about how Google Maps kept "losing" Sunrise, Florida.  Even worse, last month Nicaragua accidentally invaded Costa Rica due to an incorrect border line on Google Maps.

I've also noticed lately that when trying to map directions in the DC area that no matter how hard I try, Google Maps won't let my route take I-66 outside the beltway, forcing my route onto all manner of side roads to get around.  CORRECTION: This is now fixed.  Not sure why it had such an aversion to I-66 (other than the obvious fact that it's an overcrowded, backup-prone freeway).

Moral of the story?  Always sanity check things before blindly following Google Maps directions (especially if you're preparing to do any border patrolling).  :-)

Back in the Saddle

After a long hiatus, it's about time for me to startup the ol' blog again!

I've redesigned everything, added "About" and "Currently Reading" pages and plan to start more regular posts.  Expect to see topics in the near future such as Atlassian Meetups, Bitbucket, Google Apps Migrations, iPhone Programming and Conferences/Personal Development.

Proxying Atlassian Apps - Part Deux

In my previous post I explained how to setup your Atlassian applications behind a proxy server.

One of the benefits I didn’t mention was that as your usage grows, if you need to move one (or more) of the applications off onto their own servers, you can do this by getting the application setup on the new server and then changing your Apache config file settings to make the ProxyPass and ProxyPassReverse point to the new server IP instead of “localhost” for the application in question.

However, if you are using Crowd for your centralized Authentication and SSO, you may find that logging into the application you moved becomes a little, shall we say “quirky”?  The best way to explain what you’ll see and how to fix it, is by way of an example.

Let’s say you had JIRA, Confluence and Crowd all installed on one server as described in my previous post.  As part of the Crowd setup for JIRA and Confluence, you will have setup a “crowd.properties” file to tell each application where to authenticate.  The default setting in that file is “http://localhost:8095/crowd/services” and we’ll assume you left it that way for both JIRA and Confluence.

As you get more and more users up and running, you’ve decided that JIRA needs it’s own server to handle the load, so you move it to another server and modify the ProxyPass settings to point to the right location.  When you were setting up the JIRA on the new server, you were smart and remembered that a locahost url for Crowd wouldn’t work anymore, so you changed the JIRA “crowd.properties” file to point to “http://your.server.name/crowd/services”.  All seems to be well with the world.  You can still login to JIRA, so the Crowd integration seems to be working.  You browse over to Confluence and you hit a login screen.  What’s this?  A login screen?  So, you login to Confluence using the same credentials - hmm, it seems to work.  You browse back to JIRA and you hit another login screen.  What in the world is going on?

You’ve entered the netherworld of “Trusted Proxy Servers” (bum BUM BUM BUUUMMMMM)!!!

If you were to login to the Crowd Administration Console, goto the Administration Tab and click the “Trusted Proxy Servers” section, you’ll see a list of IPs and a text box to allow you to add more.  The only IP in the system at the moment is likely “127.0.0.1”.  The reason you are not staying logged in between JIRA and Confluence now is because when you login from JIRA, the request is coming from the new JIRA server via the Apache proxy.  The IP being associated with the session is the public IP of your Apache instance, not the 127.0.0.1 “localhost” IP that Confluence registers when it talks to Crowd directly on port 8095.

If you find the public IP of your Apache instance and put it here in Trusted Proxy Servers, you will find that everything magically works again!  If you are having trouble, I recommend turning the logging on “root” and “com.atlassian.crowd” to ALL, browse to JIRA or Confluence after logging into the other and then look in the logs - you’ll see something about the session tokens “not matching” and the IP address being registered will be right there in the logs.  Just don’t forget to turn the logging back to INFO when you’re done - no sense running out of disk space in about 15 minutes…