Coding With Intent

Why I'm Sticking With Remember the Milk

2012-02-09T10:21:00.000-05:00

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

2012-02-08T11:48:00.003-05:00

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

Login to FishEye, go to Administration -> Repositories and click "Add Existing...".
Choose "Git" from the dropdown, give it a name/description and click "Next".
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"

Under "Authentication Style", choose "Generate key pair for ssh" and click "Generate".
Copy the resulting block of text into your clipboard.
Go to your repository in GitHub, go to "Admin" and choose the "Deploy Keys" tab.
Click "Add another deploy key", name it "FishEye", paste the block of text into the "Key" field and click "Add Key".
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

2011-10-24T10:01:00.000-04:00

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!

2011-02-17T12:47:00.000-05:00

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

2010-12-06T07:53:00.000-05:00

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

2010-12-03T22:13:00.000-05:00

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

2010-03-16T11:56:00.002-04:00

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…

Running your Atlassian Apps behind a Proxy Server

2010-03-16T11:54:00.001-04:00

The Atlassian suite of applications (JIRA, Confluence, Crowd, FishEye/Crucibleand Bamboo) is an amazing set of tools for anyone trying to run a halfway serious development shop.

The easiest way to get started is to install the “standalone” versions, which essentially means each application comes in its own Tomcat instance - this allows for seperation of your application JVMs and gets you the ability to restart just the application you want when doing maintenance (not to mention the fact that I find the deployment instructions for their non-standalone version a bit long-winded).

The problem with this approach is that each application will, by default, end up running in the root context (/) of its own port. So, your JIRA instance might be athttp://your.server.name:8080 and your Confluence might be athttp://your.server.name:9080 (and so on and so forth).

I have found that the simplest solution is to put everything behind an Apache proxy so that you can run the whole thing on port 80 with the various applications on their own paths (“/jira”, “/confluence”, etc).

The first step is that you need to modify the “server.xml” for each of your applications to run them on something other than “/”. To do this, look for the following:

<Context path="/"...>

and change it to something like:

<Context path="/jira"...>

Once you restart the applications, they’ll now be available on the port at the path you’ve just configured - something like http://your.server.name:8080/jira.

The second step is actually pretty straightforward. You’ll need an install of Apache with mod_proxy enabled. Within the VirtualHost section of your Apache config files, you’ll want to put the following:

ProxyPreserveHost On
ProxyPass /jira http://localhost:8080/jira
ProxyPassReverse /jira http://localhost:8080/jira
ProxyPass /confluence http://localhost:9080/confluence
ProxyPassReverse /confluence http://localhost:9080/confluence

Once you restart Apache (and assuming it’s listening on port 80), you can now browse to http://your.server.name/jira and http://your.server.name/confluence.

Don’t forget to update the server urls in the Administration sections of the various applications to make sure that things like emails and RSS feeds and things like that all have the appropriate links.

Thinking in Groovy

2008-09-25T11:53:00.002-04:00

I’m currently reading Programming Groovy and Groovy Recipes to hone my Groovy skillz and I’ve come to a realization: my Grails apps and the several scripts I’ve written for work have been nothing more than a thin veneer of Groovy syntax over Java programming. I’ve still been “thinking in Java” as I write code. This is not necessarily a bad thing - I’m still able to write code that is *much* more syntactically simple (lists and strings are so much easier to work with in Groovy), but I’m not really writing true Groovy meta-programming code. Venkat and Scott’s books are helping me down that path…maybe someday I’ll actually be “Thinking in Groovy”.

Install Subversion on Apache with SSL

2008-09-25T11:50:00.000-04:00

Guest post by my brother John.

Mike and I need a good place to share code, so I decided to install subversion on our server. I had a couple requirements for our source control setup:

accessible from anywhere
browsable via the web
authenticated access (for both read and write — this is for private code)
secure connection (don’t want my password sent in the clear)
easy to use (eg, once I have a working copy set up, I don’t want to type my password every time it connects to the server)

I looked at the options, and discovered that svn+ssh can be a great secure option, but didn’t deliver on everything I wanted. I decided to try subversion over HTTPS, and so far I’m very happy with that solution.

Environment

When I started, I didn’t have Subversion installed on our server, I didn’t have WebDav enabled, and I didn’t have any sites set up with SSL. I did have several basic virtual hosts set up in Apache 2, and a couple tutorials to help me along the way.

Install Subversion and set up repository

Start by installing subversion. On Ubuntu, it was as easy as this (thanks to this Introduction to Subversion):

sudo aptitude install subversion

Then we want to create our first repository. I decided to have only a single repository, which will store all of our projects. It’s fairly simple to change to multiple repositories if desired. You can put the repository just about anywhere, but I wanted a common location, so I used this:

sudo mkdir /var/repository
sudo svnadmin create /var/repository

We’re going to want Apache to be able to write to the repository, so we’ll make it own the files right now (apache runs as www-data on my server):

sudo chown -R www-data.www-data /var/repository

Set up authentication

We’re going to use basic HTTP authentication over our SSL connection. To do this, we’ll need to set some users and passwords up in a new /etc/svn-passwd file (you could put it somewhere else, if you want):

sudo htpasswd -cm /etc/svn-passwd john
sudo htpasswd -m /etc/svn-passwd mike

The first command created a new /etc/svn-passwd file, and set the password for john using an md5 hash. The second command set the password for mike. Both of them prompt for the new password to be set.

I’m not going any further than that on authentication. I believe that I could set up more detailed privileges in the /var/repository/conf/svnserve.conf file, but I’m not going to worry about that — any user that is able to authenticate via the svn-passwd file will be granted full access to the repository.

Create self-signed certificate

For my purposes, a free self-signed certificate for SSL is all I need. I found a great tutorial on creating this cert, and followed all of their directions. First, I made sure that the ssl-cert package was installed:

sudo aptitude install ssl-cert

Then I created the cert by running the following command and answering all prompts:

sudo make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/ssl/certs/selfsigned.pem

Install and configure SSL

I mostly followed the instructions in this tutorial to enable and configure SSL support. mod_ssl was already installed, but not enabled, so I ran this to enable it:

sudo a2enmod ssl

That links the mod_ssl.conf and mod_ssl.load files into /etc/apache2/mods-enabled/. The default settings in mod_ssl.conf should be fine.

Now we need to set up SSL on one of our vhosts. Choose a vhost, edit the conf file for it, and duplicate the existing virtual host with a few modifications.

<VirtualHost *:80>
  ServerAdmin webmaster@localhost
  ServerName  domain.com
 
  ...
 
</VirtualHost>

Copy that, change to 443, and enable SSL:

<VirtualHost *:443>
  ServerAdmin webmaster@localhost
  ServerName  domain.com
 
  ...
 
  SSLEngine on
  SSLCertificateFile /etc/ssl/certs/selfsigned.pem
</VirtualHost>

Now restart Apache, and make sure there are no errors on startup:

sudo /etc/init.d/apache2 restart

Test that https is indeed working: https://domain.com/

Install mod_dav and mod_dav_svn

We need to make sure the mod_dav_svn.so is installed on the server.

sudo aptitude install libapache2-svn

Check and make sure that the mods-enabled directory contains links to both dav.load and dav_svn.load — if not, run these commands:

cd /etc/apache2/mods-enabled
sudo ln -s ../mods-available/dav.load
sudo ln -s ../mods-available/dav_svn.load

Edit that virtual host conf file again, and add a new section inside the 443 virtual host:

<VirtualHost *:443>
  ServerAdmin webmaster@localhost
  ServerName  domain.com
 
  ...
 
  <Location /svn>
    DAV svn
    SVNPath /var/repository
 
    AuthType Basic
    AuthName "Subversion repository"
    AuthUserFile /etc/svn-passwd
 
    Require valid-user
  </Location>
 
  SSLEngine on
  SSLCertificateFile /etc/ssl/certs/selfsigned.pem
</VirtualHost>

Restart apache once again:

sudo /etc/init.d/apache2 restart

And now you should be able to access svn via https, using the user and password you set up in the svn-passwd file at https://domain.com/svn/

And If you want to import a project to the repository, you should be able to do something like this:

svn import /path/to/existing/code https://domain.com/svn/myproject/trunk -m "initial import"

Hope this helps someone, and that I didn’t forget any key steps in the process.

Regex to strip spaces and SGML tags

2008-09-12T11:44:00.002-04:00

A DBA coworker wanted some regex to strip SGML tags and spaces from a database for some reports he was doing.

He wanted to turn this:

BiScO<sub>3</sub>:<html_ent glyph=”@nbsp;” ascii=” “></html_ent> Centrosymmetric BiMnO<sub>3</sub>-type Oxide

into:

BiScO3:CentrosymmetricBiMnO3-typeOxide

So, I came up with this pattern: <(.|\n)*?>|\s and tested it at http://www.regextester.com.

Apparently, in Oracle 10g, you can use the REGEXP_REPLACE function to do some nifty lookups and transformations.