Breaking Catch 22

It seems the journey to break catch 22 has come to an end. Today marks a very long road crowned with success. As of July 30, I will be moving to a full time development position. On top of that, I will be taking over as the manager of the group to which I belong.

As another plus for the day, it seems the Android work is finally getting some momentum and we will be kicking off a series of basic apps to interface with our software. I will be working closely with our iPhone guy to build the Android equivalent of what he is doing.

It has been a very long day and I wish I could think of more to say. I’m not sure what will become of this blog since the reason behind putting it together is over. Most likely, it will just become a place for me to share cool technologies I come across and cool things I am working on. That all remains to be seen.

Lessons learned: Work hard, stay excited about technology, and don’t give up.

Today, I spoke with our COO regarding my current situation and the ever postponed move to full time development. Everything has hinged on finding someone to back fill my current position.

As of today, there is a plan in place and that person has been chosen. The projected time line for the change is around 90 days. Success!

I have been using Linux and Open Source software for years now. I have enjoyed the benefits of free software, from not having to worry about viruses to having almost anything you could want just a few clicks/commands away. I have gone as far as getting other people to use the software and have personally seen several other people switch to Linux as their primary OS. I have found myself a bigger advocate than ever over the last year and often struggled to understand as people would fight their computers and viruses, but not give open source software a chance. Luckily, I have seen the landscape changing.

The one burning need I have felt over the last year was to get involved with open source as a contributor. I have wanted to help with documentation, advocacy, and most of all, with programming. I am an analyst and Java developer in my day job, but like many others in this industry, I needed more. I wanted more experience than I was getting at work. I wanted more than anything to find a project that I felt like I could really contribute to.

I would check out various projects and watch them. I would read suggestions that would say you should find something you use and contribute to that project, so I would watch them as well. Honestly, what I cared most about was getting the experience working on an open source project, not so much about what the goal of the individual project was. It was intimidating. Being a somewhat junior developer, most of the projects seem overwhelming and most projects didn’t make it obvious or easy for people to get involved.

Several weeks ago I saw a post on the Python-Announce mailing list that a new site was released to help people find easy bugs and documentation issues as a way of contributing back to open source. The site works by tracking these easier items and building a community around people who want to get involved and help out, but aren’t quite sure where to start. Openhatch.org turned out to not only give me the direction of where to get started, but has also turned out to be the project I was looking for. As someone who has personally struggled with trying to find the place to get started, this is a subject I care a lot about. I couldn’t think of another project where I would rather put my time.

I decided to jump on the IRC channel. The core project team made themselves available to answer questions. I mentioned that I wanted to help and asked where the best place to get started might be. The project lead, Asheesh, suggested I look at writing an interface to Bitbucket to allow people to pull in their contributions to projects hosted on Bitbucket. It sounded a little scary, but I figured if he thought it was a good first task, it must be OK. It was! I learned so much in working on the new functionality. The site already pulled from Ohloh, Github, and several others, so I was able to read through the existing code and get an idea of what needed to be done. In addition, I had to write test before my code would be accepted. That was great, since the test pointed out several places where I had problems, and allowed me to correct the issues must faster than if I had to manually track down the issues. So, in all, I contributed to an open source project, learned a little about writing unit test, and realized just how important writing the test are. The day my code went live was a great day. I was the first one to run the code after the restart and saw it action, working perfectly (thanks to the tests).

Even though I write code during the day, there is something special about contributing to an open source project. If you use open source software and you care about making the software and the community around it better, there is no time like the present to get started. Join up on openhatch.org and find something easy to get you started. Once you start, you will not want to stop. I no longer wonder why people work on software for free and put so much of themselves into making it successful. I am one of them now and can’t wait to give more of time and effort into watching this movement grow.

If you are a project owner or core developer on a project, make it easier for people to get involved. Mark your simpler bugs as ‘Easy’, or ‘Bite sized’. Make sure to add your documentation issues to your tracker so people can find them and work on them. Make yourself available for questions and make a special effort to make new people feel welcome. If it hadn’t been for the team at openhatch.org, I might still be looking for a place to contribute. They took me in, gave me some suggestions on getting started, and a few weeks later, I am contributing and feel like part of a team. Making new people feel this way will not only make them want to help your project, but make them lifetime contributors to making the OS community even better.

Recently I wrote a post, which I later deleted. I had started looking at working on a project called Evennia. It is a MUD/MUSH server written with Twisted and Django. My initial impression was that the project needed everyone to come together on a demo game, so people who were interested in using the code base would have something to go on. The idea was well received, however I realized it would pretty much just be me starting out. I was OK with this, until I got into it more. I realized that evennia was more of an engine that can be used to create a MUD engine. Much work would need to be done to get things into a state where it could be usable for a game. Looking at the MUD landscape, I don’t think my time would be well spent in a project to build the MUD engine. If the core code base were headed that way, it would be fine, but this isn’t the case. The core devs are interested only in the engine itself, not building a workable game from it.

Lessons learned: Put a little more effort into watching the community and reading the code/experimenting before you overtly volunteer on a project.

While I may have gotten a couple of people interested in doing more with evennia, I probably now look like a jerk. Oh well, on to other things and hopefully areas where my contributions can apply to a project that will see fruition. At the moment, I am closely looking at http://openhatch.org. Their entire purpose is to connect people with projects that could use their help. What a great idea. I’m thinking open hatch itself may be the project to contribute to. This time, I’ll spend a little more time checking it out first. On the upside, the project is done in python, with Django.

The Definitive Guide to Jython
http://apress.com/book/view/1430225270

The authors describe this book as having the intended audience of a Java developer wishing to use a dynamic language other than Groovy orJRuby. This is a very accurate assessment.

The first section serves as a quick introduction to the Python language, however should not be completely skipped even by seasoned Python developers. As a Python and Java developer, it was good to see comparisons of similar features from both languages. In many cases, the authors took the time to show code examples from both languages, side by side.

The book then leads into practical application of Jython. In addition to sections on how to call Java code from within your Jython scripts, extremely detailed instructions are given for calling Jython code from within Java. Also, the reader is taken through instructions on setting up Jython with their IDE (a must for any Java developer) and using JDBC calls from within your scripts.

Next, the reader is taken on a journey through using Jython with JSP, Django, Pylons, Swing integration, and – very importantly – eployment to Java application servers such as JBoss and Glassfish. Readers are then exposed to testing techniques for Python/Jython,and details on Concurrency in Java and Jython.

The book ends with several Appendixes which should not be missed. Parsing XML with Jython? It’s there. Writing Ant task? Yep.

I give the book a 4 out of 5. The only thing that would have made the book better would have been to spend a little less time talking about Python syntax and explaining only the differences between the languages. My thought is that if someone buys this book, they have likely already read an introductory book on Python and will spend much of the first 160 pages reviewing what they already know. This could have been condensed to about 15 pages by showing only the differences between the languages. However, as I mentioned before, the comparisons of features, and the places where the integration points are mentioned, are worth reading that section.

I should warn Python developers looking to learn more about Java. This book is not for you. Many of the topics covered assume the reader has existing knowledge of Java, including application servers and GUI development with Swing.

If you are looking for a book on Jython, this is the only book I would consider buying. I highly recommend it for any developer looking to gain the speed and ease of Python within their projects. So, go out and buy the book. Support the authors for the obvious hard work they put into making such a great book.

Android Application Development
by Rick Rogers, John Lombardo, Zigurd Mednieks, and Blake Meike
Publication date: May 2009
336 pages

Reading previous reviews, my initial impressions were that the book wouldn’t live up to the description. In contrast, I found the book to be a good introduction to the platform and to specific requirements for building an Android application.

The book starts by explaining how to set up your system for development of Android applications with Eclipse. The information was correct and made no assumptions as to your previous exposure to Eclipse. While most of this information is available from the Android Developers site (http://developer.android.com), it did go a step further and explain the layout of the Eclipse IDE. This includes portions directly related to Google’s plugins.

Unfortunately this good section was followed by downloading and installing the MJAndroid project. The project doesn’t work. Like many other reviewers, I was able to download and compile the project, but it wouldn’t run in the emulator, without giving fatal errors. Given that this was the example project for the book, this was a major strike against the it.

The book proceeded to explain various portions of the project and how they relate to the topic at hand. While the explanations of each section of an Application was quite good, doing a good job of helping me to understand the subjects, the code in the downloaded application didn’t match what was printed in the book. It appeared as if the authors were continuing to make changes to the code (for a new edition maybe) and publishing them. Steps should have been taken to freeze the code and make it clear to readers what should be downloaded. This may be the reason the code wasn’t able run on the emulator.

Finally, time is taken to explore how an application is published and what must be done to submit to the App store, the Google APIs, and interacting with databases telephony, and Inter-Process Communication. These were some of the best chapters in the book.

Overall, if a second edition is planned, I would likely read it, especially given the smaller size of the book. The explanations of each section were great. The only overshadowing issue being that the example code didn’t match the actual code, and that it didn’t run on the emulator. My one request for a future edition would be to add a section on interacting with web services and parsing of XML and JSON. And again, thanks to the authors for not basing the entire book around the creation of a game. My vote, 3 stars. It is worth the read if you have a Safari sub.

I just started work on a new Django app to allow me to define my musical practice goals, then record my sessions and the progress I make. This will eventually find its way into the Out of the Darj website so that all of the students can use it as well. The plan is to include a profile of sorts where you can define your goals and show your progress toward making your goals a reality.

The project is named ’stanton’ after the great Stanton Moore. You can find the repo here: http://github.com/markfreeman/stanton

This past Thursday was the first official meeting of the Birmingham Area Python Users Group (PyHam). I volunteered to do the first presentation, which was an overview of unit testing frameworks in Python. I thought the presentation went very well. I’m very interested in testing, and know that I should be, but getting started can be the hardest part. It was very interesting to hear the take others have on the subject and to hear most everyone else admit that they feel the same way I do. The biggest lesson I took away from the meeting is to always make sure you right your code to be tested, or you will never write the test.

The last few weeks have been quite busy. I’ve been preparing for the first PyHam meeting, where I will be giving a presentation on common testing frameworks in Python. I have a tendency to volunteer to talk about subjects I’m interested in, but don’t know much about. This should be interesting. I’ve certainly learned quite a bit in the last couple of weeks. Our first official meeting will be next week (1/21) at Birmingham Southern College, at 6:30pm.

I had some down time over Christmas and decided to use it learning the basics of sqlalchemy. Since I like using the command line to get around and I have been wanting to try my hand at a basic to do list program, I decided I would try to mimic Gina Trapani’s todo.txt.

The commands are slightly different than those used by todo.txt, mostly due to some limitations of using optparse. Currently, the program supports adding task, deleting task (completing them), updating task priority or description, and listing all task or searching the task for a keyword.

Running the program for the first time will create a database and settings file for you. This may be changed in the future to where only the db file is created and the settings file is already included. Additionally, there are some path issues that will be addressed in the near future. Once these issues are addressed, I plan on packaging the program up for listing on pypi.

You can see the source and download the program on github.