Joe Kratzat

I'm a passionate software developer, that loves to explore.

Theme Toggler: My First Atom Package

Lately, I have been using the Atom editor. I really like working with it. The custom packages and themes make it very nice. My only issue has been that dark themes are terrible to work with while outside, and light themes are too bright inside.

I know there are two great theme changing packages already: Outdoor Theme, and Theme Switcher, but neither gave me quite what I wanted.

Since Atom makes it easy to generate and distribute packages I went ahead and created Theme Toggler. It is very basic. It toggles between a dark and light theme using ctrl + alt + t. The one thing it does different from Theme Switcher is changing the UI theme as well as the Syntax theme. I like to keep the UI consistent with the Syntax, but if you don’t you can use the settings to easily override my preferences.

Anyway, that was my motivation for creating Theme Toggler. Well, that and I have wanted to make a package for a while. I hope to write up in more detail just how to create a package. Until then Atom has some great documentation on this here.

3rd Party Libraries and Android Studio Gradle Issues

I want to start this off by saying that this was for Android Studio 0.2 and at the time of this post that is already outdated. However, I feel this might help others.

The project I was working on was currently using an older version of the Android Gradle plugin (0.4.2) with and older version of Android Studio. I had version 0.2 which requires the Android Gradle plugin minimum of 0.5.

I was getting gradle build errors, and Android Studio import errors. I needed to update my project build.gradle file as well as all the libraries. This meant I needed to go and edit the build.gradle file manually (0.3 fixes this issue), and change:

dependencies {
  classpath ''


dependencies {
  classpath ''

Doing this for the main app was not an issue, however some of the libraries I did not have access to like ActionBarSherlock. I had to fork the repo and update the gradle version.

For other projects like SlidingMenu I needed to fork it and setup a build.gradle file manually. This is my default build.gradle file

Lastly, for Volley I had to create a new repo and add the followling:

buildscript {
  repositories {
  dependencies {
      classpath ''

I’m not sure if doing this is the best way, but it allowed my project to build and seems to be working. I have seen others doing the same thing, like Path’s ActionBarSherlock.

If I find a better way to do this you better believe I will post an update. This just seems gross to me.

Jenkins and Bitbucket

Tonight I had to setup a new instance of Jenkins. Having never set Jenkins to work with Bitbucket before I thought this might help out others. This will cover Jenkins accessing only Bitbucket, having it deploy might be another post, but that isn’t covered here.

Jenkins install

Starting out, I have a blank Digital Ocean droplet. There is basically nothing. I had to install Jenkins, which is pretty basic:

wget -q -O - | sudo apt-key add -

sudo sh -c ‘echo deb binary/ > /etc/apt/sources.list.d/jenkins.list’

sudo apt-get update

sudo apt-get install jenkins

This will create the jenkins user and start up the Jenkins servlet on port 8080. If you need to setup Jenkins other ways checkout the How-to.

Carrierwave, RSpec and FactoryGirl

As part of a project I wanted to run some rspec tests on a model that had many children models using Carrierwave to upload files to S3.

My models look something like this:

class User < ActiveRecord::Base
    has_many :images

class Image < ActiveRecord::Base
    belongs_to :user

    validates_presence_of :file
    mount_uploader :file, FileUploader

New Site Setup

With Posterous closing down April 30th (thanks Twitter) I felt it was time to move my site elsewhere. I opted for Github Pages using Octopress (designed for Jekyll).

So far I’m very happy with it. Everything is very customizable, setup was super simple and fast, and deployment was a snap! I say that with the caveat that some ruby/rails development experience might be necessary. Was Posterous easier than all of this? Sure, but I’m a developer. I should get to know all this stuff since I have never really used it before.

There is a better reason I chose to use this setup over something like Posthaven, Square, Wordpress, etc. I hope in the future there will be a project for me to flex my Octopress/Jekyll muscles. After all learning new (to me) things is always useful.

Just Commit

I’m adopting the motto Just Commit. I’m tired of over thinking. It makes things move slower, and can sometimes be crippling. A good friend of my tends to tell me “just commit” when refering to code. If something breaks, fix it. If something isn’t optimal yet, it can be optimized later, but just commit. This, starting a few days ago, is my new life motto.

So from now now I will be just commiting!

Spring-ws SOAP ‘No Adapter for Endpoint’

Why am I using SOAP? I don’t want to talk about it. Basically I have a need for a Spring MVC project to provide a Spring-ws SOAP endpoint. After following the Spring documentation here and downloading the source code here I noticed something. The documentation is using jdom for marshalling. While the source code is using jdom2.

After struggling for a while I find out that using jdom, even with everything setup correctly, will result in the following error:

‘java.lang.IllegalStateException: No adapter for endpoint’

This, I guess, is a known issue. The thing to do is use jdom2, or something else like JAXB, Castor, etc.

I know documentation is hard to keep up-to-date. I just thought I should put something else out on the net incause others have the same issue.

Git: A Powerful Front-end to Subversion

Git is a great version control system. I have used it for some time on many different projects and I really enjoy working with it. My life is bit simpler because of Git.

When I had to move back to SVN I didn’t really like the idea of losing local features branches, stashing , and easy merging. Luckily, Git has the a svn command which allows me to use Git as my front end to SVN.

What do I mean by front end? Basically, I use Git on my development machine, and use the git svn command to push/pull code from the SVN Server. Git is how I interact with SVN.

Why, if SVN is already being used, would you use Git? SVN is used in many code bases I have been working on lately, but that doesn’t mean I can’t still use the advantages of Git.

Branching and merging: I’m sure, like me, you have tasks that change quickly. On a daily basis I need to switch from working on a new feature, fixing bugs, etc. Git allows me to switch from a feature branch I’m currently working on, to a new branch for a bug/fix then merge the new branch and push upstream. Then finally get back into my larger feature branch.

Typically with SVN or other CVSs this is a bit more challenging. Many times I would have to say “Hold on while I get to a good stopping point”. With Git I temporarily save my changes (Stash - will talk about a bit later) and create a new branch and start working.

Working Locally: I don’t have to comment feature code out just to make sure it is checked in. Since Git is a DVCS I can store all my changes locally, to later be pushed to SVN when ready. This allows me to check in early and often locally without messing up a co-worker by having crazy comment code strewn about the code base. I can make sure my feature is fully ready, and tested, before pushing upstream for all to use.

Stashing: As mentioned before Git allows me to temporarly check in current code changes. Many times someone will point out a trivial issue in the code which needs to be in production “now”. With git stash I can save whatever it is I’m working on with out having to check in non-working code, again saving me time to not have to be in “a good stopping point”.

There are many other features Git has, these are the ones that make it a great front end for SVN. Using git svn not only saves me time, but it allows me to keep my code out of the master SVN repository until it is good and ready. I can count the number of times I have been working in newly pulled code only to find something is broken because line 23 in some file should have been commented out. Since I don’t like when others do that I choose to use Git to help make everyones lives a bit easier. What is the old saying: Do unto others as you would have them do to you.

Two tutorials that helped me:

Unity3D and JSON Parsing

Today I was working on a Unity3D web player project that requires pulling JSON from a remote server. I needed a way to parse the JSON string. After working with multiple JSON libraries (Jayrock being the main one) I found that LitJson worked well with in Unity once you had the DLL. I was unable to get Jayrock to work with Unity’s web player. Turns out that Unity desktop builds use a subset of the Mono SDK, which can be changed to use the full SDK. However, the web player can not be changed, limiting access to System.web which is needed by Jayrock.

While running ./configure it would output the following error message:

configure: error: Please install mono version 1.1.17 or later

I did confirm my mono version:

Mono JIT compiler version 2.6.7

After using the Googles for a bit ran accross a post a link to download a zip file that had the DLL already built: Download (224.2 KB)

With some code changes JsonMapper seems to be working and I’m able to parse the JSON.

List listOfLessonProgress = JsonMapper.ToObject<List>(www.text);

What I was working with:

Unity3D version: 3.3.0f4

MonoDevelop version: 2.4.2

OS: OSX (10.6.7)