Posts

Showing posts with the label oss

Newly open source

Well its about 10 years too late for some of this stuff but I figured I'd open the source to my dead projects I have lying around. Some are pretty raw, like my flocking applet from a college course, while others are completely functional and dare I say beautiful code, like my X10 Java library. FlockingApplet - a graphical applet that simulates the flocking behavior of birds. handlecheck - a web app that searches the web to see if your favorite username is taken. gwt-common-widgets - a collection of Google Web Toolkit widgets x10-java - a Java library for home automation.

TeamCity build triggering by GitHub

Image
So I started using GitHub for a side project and discovered their very cool feature of service hooks. A service hook allows a repository administrator to setup a callback to another service when a commit is made to the repository. For example it can send an email, or chat a message via Jabber. Now continuous integration servers, like TeamCity , can poll source control systems every few minutes to see if any changes have been committed. But wouldn't it be more efficient to use a service hook to trigger a build? Looking at GitHub's service hooks, there wasn't one already available to callback a TeamCity server, but right on that same page was a link to the open source repository for GitHub Service Hooks . They "eat their own dogfood" so to speak and make it very easy to contribute new service hooks back to them. So I took an evening, did my first Ruby coding in a while which included more time getting Ruby setup and working on my Macbook than actually coding....

Best Practices with Maven: OSS forks

Recently I came across a company that is forking several open source Java projects. I saw they were making a mistake that I also made a few years ago and have since learned from. In Maven's distributed repository architecture project artifacts, like JAR files, are uniquely identified by a coordinate system composed of a group identifier, an artifact identifier, a version number, optionally a classifier, and a packaging type. For instance, the most recent version of the Apache Commons Lang project has a Maven coordinate (i.e. groupId:artifactId:version:classifier:type ) of commons-lang:commons-lang:2.5::jar . A few years ago, if I wanted to make custom changes to this project I would get the source, make my changes and then deploy the result to our private Nexus repository under a new groupId such as com.jaxzin.oss:commons-lang:2.5::jar . That might seem reasonable. Then a year later or so I tried something different and changed the artifactId like this commons-lang:commons-lang-jax...

HandleCheck: My Google App Engine and Open Source Project

So I signed up for a Google App Engine account a while ago, almost right after it's Python version was released last year. Of course, life prevented me from taking the time to learn Python, and so the learning curve prevented me from building or deploying anything. Fast-forward to two weeks ago when Google released the Java API for the Google App Engine (GAE from here on out). Being a full-time Java programmer for the past 10 years, now we're running on all cylinders! I applied for a Java account on the day it was released and my Java GAE account was approved within 24 hours, but it took a few days for me to make some time to start writing some code. After about 8 hours of development I had my first working prototype of a web application running on the GAE. My first GAE webapp is a service that connects to a set of social web sites that provide user names and profile pages for their users to see if a username you are interested is still available across those sites. My ...