Recently GitHub announced GitHub Enterprise, a way to have all of the goodness of GitHub behind your own companies firewall on your own servers. GitHub in general is an obvious win for developers, but when trying to pitch why it’s so awesome to managers, execs, etc I was sort of at a loss as there isn’t currently much on the GHE site as far as features, etc. I reached out to GitHub trainer Matthew McCullough @matthewmccull for some ideas on features that I was not even aware of, and we came-up with a GitHub wiki page which outlines all of the various features we could think of that you would get over plain git hosting by using GitHub Enterprise:

GitHub Enterprise

While this is the only thing I’m aware of to use to help you pitch GitHub Enterprise to your peers and superiors at the time of writing, I plan on this being a living entry and will update it as I’m made aware of more stuff. If you know of other features, please update the Wiki entry above. Also, if you have other resources to use for pitching GitHub, contact me and I will add them to this page.

This is just a quick note to mention that one of the first open source projects that I wrote, CFAkismet, the ColdFusion based Akismet client, has finally moved to GitHub. Read more about it’s new location on the CFAkismet Project Page.

My primary home machine as of this writing is a 2008 model MacBook Pro, and every since I have upgraded it to MacOS X Lion, I’ve have had nothing but problems with it. I held of on upgrading until iOS 5 came-out, which then needed Lion for iCloud support. I gave in and ended-up spending several months troubleshooting various problems to get my machine back into a usable state.

This blog post is not the end-all authorative information about how to fix instability problems in Lion, it is however a quick guide of things to check if you are an experienced Unix/MacOS user. I don’t outline the steps down to the actions you must perform, it’s just an overview on what you should check. There are no guarantees that any of this will fix your problems, and you should have an expert do this for you if any of this stuff is unfamilliar to you.

Out of all of the things I read about people having problems with Lion, the culprit in at least 95% of the situations was old software interferring with Lion. Given that I have taken my machine from Leopard, to Snow Leopard, to Lion, there were bound to be problems leftover from old software.

The most important thing I have learned in this process is that Lion is not an operating system you want to upgrade to because it has a lot of massive changes in it. Do everything you can to only use Lion from a clean install. I can’t stress this enough. You will spend much less time getting your machine back to a usable state by doing a clean install than you would having to troubleshoot this stuff. In hindsight I’m still at least a little bit glad I didn’t because I learned a lot in the process, and getting Lion usable again has been a frustrating but somewhat rewarding experience.

Now that I’ve got all of that out of the way, here are some of the steps you should do in order to figure out why your machine keeps locking up:

1. Review Log Files

This is the quickest and most valuable step in figuring out what is going on. If you’re lucky, there will be all kind of different traces of badness happening including kernel panics. Google for anything suspicious you see in log files, and fix it if possible.

2. Make Sure Your Hardware Is In Good Working Order

You could actually have some sort of hardware problem that is making Lion crash. Maybe you have RAM that is not working correctly, a problem with your video card, etc. Make sure your hardware is not an issue.

3. Repair Disk & Disk Permissions

This is a pretty good thing to do in general when you are having system problems. It doesn’t take long to run, and it will almost always find something wrong, especially if you are experencing crashes.

3. Update/Uninstall Always Running Applications and Daemons

Are you running up to date software for everything that runs at startup? Some suspects would include software like Little Snitch and Dropbox. This sort of software almost never updates itself automatically, so make sure you are running the latest versions of programs that run at start-up or as daemon processes.

4. Update Frequently Used Applications

What programs do you usually have open when you experience a lock-up/crash? You should probably make sure they are all the latest versions. Run them one at a time and see which one causes Lion to crash.

For me, during troubleshooting I narrowed it down to Google Chrome. I instead ran Firefox for awhile and the crashes went away. Eventually I switched Chrome to the dev channel and it seemed to be stable, but I had already done a bunch of other stuff in the process so no idea if that was actually the fix or not.

5. Remove old Kernel Extensions

This one is kind of nasty and you could end-up really hosing your system. Be very careful while doing this. I ended-up finding a very old Cisco VPN extension from 2007, and well as some library called “Soundflower” or something like that which was also incredibly out of date.

6. Do A Clean Install Of Lion

If you’ve done all of the steps above and are still having problems, I would suggest a clean install of Lion. If you continue to have problems even after a clean install, you likely have a hardware problem.

Honestly I’ve had an almost finished blog post in my drafts folder with a lot of bile and hate for Lion for at least a month or two after seemingly wasting so much time trying to figure out what the problem was. However after running through all of these steps several times to make sure I didn’t miss anything, my old MacBook Pro from 2008 is stable again!

I can’t exactly point my finger at Apple for the problems I’ve had as I would say they were likely the fault of old software. I have certainly not been that happy with them as of late, though.

This site, to some degree, has been online since the first part of 2003. Given that it’s almost 9 years old now, it certainly has some baggage associated with it. Over the past few years I’ve been severely neglecting it; every since I lost a custom theme I’d coded by hand, I just never found one I was very happy with. Also around the same time, I signed-up for Twitter, then left a job I had been at for 4 years to join a startup and things have just been crazy every since between my career and personal life. I have about twice as many followers on Twitter than I do RSS readers of this blog, and it’s time to change that!

The state of my blog has been killing me and it was time to update it. I’ve had the last week off of work and have spent a portion of it ripping the guts out of this blog and replacing them. New theme, almost all new plugins, etc. Other than starting off on a new blogging platform, it’s pretty much been done to this site. I still have some editing and purging of old entries to do, but I wanted to iterate quickly and get something out the door TODAY.

I’m pretty pleased as to how it’s turned-out and plan on trying to blog more frequently. If that doesn’t happen, I suppose I may as well shut it down or rethink it a bit.

Like many Mac users, I use hot corners to start my password protected screensaver when I’m ready to walk away from my desk. Seemingly out of the blue, I was unable to use hot corners any longer. I tried changing the settings, added another hot corner, etc, and nothing seemed to work. Finally after much googling I found a thread on apple.com with other people having the same problem. Most of the solutions said to reboot which I didn’t really want to do, but eventually someone else found a way to fix the problem:

a) Open up Activity Monitor (/Applications/Utilities/Activity Monitor)

b) In the search filter type “Dock”

c) Select the item in the list who’s Process Name is “Dock”

d) Click on Quit Process.

The Dock and Expose will be restarted and the problem should be solved.

Give that a whirl and hot corners should start working again for you.

I think Jetty is one of the best kept secrets in the Java world, in particular for getting a quick container up and running with full integration with Maven for local testing of Java based web applications. I was doing a non-stock configuration of Jetty 7 and Maven today which took way too much Googling to get working (mostly to custom configure the connector), so I thought I'd document the process for those looking for the same thing. If you're looking how to get Jetty 7 working on Port 80 (particularly on Linux or OS X) with Maven, you're in the right place. As of the time of writing, the latest stable release of Jetty looks to be 7.1.6.v20100715.

The three minor hurdles to configuring Jetty 7 and Maven are making sure port 80 is not already taken, getting the right connector implementation configured, and running Maven as sudo so that Jetty has permission to run on Port 80. In OS X, you can see if anything is already running on port 80 by running the following command from Terminal:

If you're on OS X and see something running on Port 80 yet you didn't install a webserver, chances are it's Sharing. Go to System Preferences > Sharing and disable it. Otherwise, figure out what process is running on port 80 and make it go away.

Now to configure the Jetty Maven plug-in, here is what my configuration looks like which you should replicate in your pom.xml under the plugins section (and adjust to your particular directory structure and desired context):

One of the difficulties I encountered was getting the connector working correctly. Since Maven has moved to be an Eclipse project, the package structure for the connector has changed and thus the reason most of the existing documentation on getting custom connectors to work did not work for me.

The last remaining hurdle to overcome is that running a standard “mvn jetty:run” doesn't work on OS X (and likely Linux as well). You'll see the error message “Embedded error: Permission denied”. If you run Maven with error stacktraces enabled, you'll see an exception that looks like this:

This is because you need elevated permissions to run applications on lower ports on *nix based systems. Simply run it as sudo, “sudo mvn jetty:run” and you'll be good to go.

Not a terribly tough problem to overcome on your own, but I thought I'd try and try to save someone some time if they run across the same issues.

Finding myself in a situation of needing to increment values in a map in Java, I was curious to see what the most efficient way to do so. Said piece of code will be looped over thousands of times and I wanted it to run as quickly possible. Yes, I know that pre-optimization is the root of all evil, but in this case it was something I needed to be conscious of.

I found a question/thread on StackOverflow where someone else had already pondered the same thing and got a long list of possible answers to compare to each other, including using Apache Commons and the Google Collections Library. After testing all of them, the fastest way ended-up being implementing a "MutableInt" class and using it as the value data type in the map:

Pretty interesting stuff! Note that the above code snippet is not very cleanly formatted, but you'll get the idea.

After upgrading to Snow Leopard on my MacBook Pro, I only found a couple of minor issues which were easily fixed. One of them was Microsoft's Remote Desktop Client crashing at startup when I ran it. Luckily the fix was very simple-- I simply downloaded the latest version from Microsoft and installed it again. If you're having problems with Remote Desktop in Snow Leopard, give it a try!

Microsoft Remote Desktop for OS X

Alternatively, you can also try downloading CoRD, an open source Remote Desktop Client and installing it. It seemed to have trouble connecting to my Windows XP workstation for whatever reason, but that doesn't mean it won't work for you of course.

CoRD

CoRD is a Mac OS X remote desktop client for Microsoft Windows computers using the RDP protocol. It's easy to use, fast, and free for anyone to use or modify.

I'm currently setting up a new Hibernate project and finally getting around to trying out JPA annotations instead of using any Hibernate configuration or mapping files-- what the hell took me so long!!??! Anyhow, among the many gotchas I came across, one was how to deal with using Interfaces with Hibernate entity beans and associations.

When you declare an association to a Hibernate Entity with an Interface without using the correct annotation syntax to point Hibernate at the implementing class, you will likely see exceptions like this while running JUnit 4 tests in Eclipse:

Most of the solutions I saw made you create a duplicate persistence.xml that had all of the same information in it which seemed silly to me. Eventually with the help of Google I came across the answer somewhere (which I no longer have around) which was to modify the field annotation to point at the class which implements the Interface:

One other thing to check-- make sure your @Entity annotation is importing the JPA annotation (javax.persistence.Entity), and NOT the Hibernate annotation (org.hibernate.annotations.Entity). If you import the Hibernate @Entity annotation it will not find the entity bean.

Hopefully that's of some help to someone. Just a quick post-- back to work I go!

One tool I'm used to having without installing (it's included by default in FreeBSD) is Dig (which is short for Domain Information Groper). Dig is a really handy tool for checking and troubleshooting DNS related issues once you learn how to use it. For instance, it makes it easy to see how your MX records are resolving:

Luckily this is easy to install, just not terribly intuitive or easy to find as it's not a package known as dig:

That's pretty much it-- you should now be able to use dig!