I wrote some code.

Specifically, I wrote a plugin for Anki which converts all those terrible cx, gx, hx, jx, sx, and ux combinations into the aesthetically pleasing ĉ, ĝ, ĥ, ĵ. ŝ. and ŭ characters. Prior to this I’ve never written a plugin for Anki, and even now I claim no expertise. Anki is written in Python, and so are its plugins. I found a plugin that adds some support for the German language to Anki and used that as a model to build my plugin.

To use the Esperanto plugin, open Anki, go to File -> Download -> Shared Plugin. Type “esperanto” into the search box. My plugin is the only one that matches that search, so it should be highlighted already. The plugin is called “Esperanto Support for Anki”. Click Ok and it should download and install for you. In your deck, when you want to add a card for Esperanto, make sure the card is using the “Esperanto” model rather than “Basic” model.

I’m open to suggestions and feedback, and if you are curious about the code at all, open up your Anki plugins folder and take it a look. The code is right there and it’s very simple.

No related posts.

The entire venture is a part-time deal for myself and Thomas, because we both have day jobs. So we had to maximize the effect of our efforts by building on a platform that provides all of the basic stuff that just about any website needs these days. That platform for us is Pinax, which is itself built on top of Django in the Python programming language. I can’t say enough good things about Pinax because it let us focus on what was unique to our site, while Pinax handled user authentication, OpenID, avatars, Gravatar, social network features like friends and messaging, announcements, administration, error handling, internationalization, and so much more that we actually had to strip out some of the built-in features because we felt it was too much for our site. These features are very modular and allowed us to essentially turn them on and off as if by a switch.

This project has been a great learning experience for me and continues to be so. In just three weeks we have almost 900 users, who mostly have found their way to our site via word of mouth on Twitter and some great language learning blogs. These users have been making many suggestions to make RhinoSpike even better, some of which we’ve already implemented and many more which we plan to do soon.

If you haven’t done so already, check RhinoSpike out, and tell me what you think! I’d love to hear it!

No related posts.

Related posts:

1. Update: Barra de Español version 1.1 released!
2. Barra de Español has been accepted to Mozilla’s public addon list
3. Barra de Español: The making of a Firefox extension

The way I inserted the characters before was to find the currently focused element, assume it was a textbox, and modify its value using the selectionStart property to know where the cursor was. Once I learned that the message body textbox could not be found using document.commandDispatcher.focusedElement, (that’s what “if(!focused) focused = document.commandDispatcher.focusedWindow.document.activeElement;” is all about) I found that the element used by Gmail for the message body wasn’t even a textbox, and didn’t have a value or selectionStart properties.

So the solution is to create a keypress event and dispatch it, like so:

One important thing to note is that the parameter ch is not a character value, but an integer containing the character code you want to insert. So, for example, to insert the character ‘á’, ch must be the value 225. To find the values I needed I used the wonderful character lookup tool at http://leftlogic.com/lounge/articles/entity-lookup/.

Bonus tip: If you are developing a Firefox extension and are using a text file in your profile’s extension directory to point to the folder where your code is located, and you move your code to another folder, you will discover that Firefox won’t load your extension, even though you edited the text file with the new location. The fix is to find a file in your profile directory called extensions.cache and delete it. This frustrated me for at least an hour last night, and Google failed me on this.

Related posts:

1. Barra de Español: The making of a Firefox extension

I will say that I was able to write one of the major features completely, and nearly completed the second major feature. The main reason I didn’t complete the second feature is because it required scraping some data from a web site, and that web site made some of the data difficult to parse by putting it into an image. I didn’t discover this until about 2 nights before the deadline. Without the second feature I didn’t feel the application was compelling enough to enter into the contest, which is too bad. I think I will be able to get the data I need from an alternate source, so I will resume development of this app and hopefully release it to the public later.

I didn’t realize it at the time, but working on this project had increased my stress level quite a bit. I enjoyed working on it, and I’m beginning to appreciate how the Android SDK works, but the deadline was always in the back of my mind. When I decided to call it off, I felt a quite noticeable relief.  I don’t think the stress builds as much for deadlines at my day job, but having to focus my spare time on one project to the exclusion of others was too much for me. I think I need to keep my side projects deadline-free from now on.

Related posts:

1. My development plan for the Android Developer Challenge 2

I was a bit surprised by how long this process took. I nominated it when I released version 1.1 on June 7. 83 days later it was accepted, and during those 83 days I had no feedback as to what was going on. A week or two ago I visited an IRC chat room for add-on developers and was told that 2 or 3 months was pretty common. Recently Mozilla released a statistics dashboard that shows how many add-ons get created or updated daily. I’m not sure how many reviewers Mozilla has, but it makes more sense why it takes as long as it does now that I can see those numbers.

Regardless, I’m happy my little add-on has been accepted and I definitely have plans to enhance it in the future.

Related posts:

1. Barra de Español: The making of a Firefox extension
2. Update: Barra de Español version 1.1 released!
3. Barra de Español 1.2 is now available!

Recently I purchased an Android phone, and I love it! It’s everything I wanted a phone to be. It has an excellent web browser, a full QWERTY keyboard, GPS, and it’s hackable! I decided pretty quickly that I wanted to write an app for it, and as I start looking for the documentation on how to write one, I discover that Google is holding a developer contest. This discovery changed my approach to developing this app.

I’m not going to talk about the app I’m working on, but I did want to share how I intend to work on it, because it’s a little different than my normal approach to personal projects. Normally I start with a minimal list of features. These are the features that are most important to me. I work on each one a little at time, slowly improving the pieces until they are functional and working well together. Each piece  that I work usually causes me to improve the other pieces of the program until finally they’re all done at around the same time. At this point the project is probably ugly. I may give it some finishing touches, but not always. The project is for me, so functionality trumps aesthetics.

For this contest I felt that developing an app required a different approach. I made a larger list of features that I felt the app could do that I had not originally planned for, especially features which would take advantage of some of the built-in hardware and software on the Android platform. I then prioritized each feature based on how essential the functionality is to the application, how much the feature took advantage of the platform, and how impressive I thought that the feature could be.

With this prioritized list, I’m going to develop each feature as a whole, one feature at a time. Each feature must be functionally complete and aesthetically pleasing before I move on to the next feature. The reason for this is because if the entry deadline arrives before all of the features are complete, I can still submit an application which is still functional and polished, even if it has fewer features than planned. With my normal development style I could be stuck with an ugly app where only half of the features work by the time the deadline rolls around.

I don’t expect that I will be able to complete all of my planned features for this project by the August 31 deadline, but I hope with this plan I will have a decent app to submit. There is a bit of a learning curve that is slowing me down though. Even though it’s been over five or six years since I’ve worked with Java, the changes to the language are similar to the changes to C# over the same time period. The real learning curve comes from the Android framework. The activities, intents, content providers, etc. are easy enough to understand but I’m still dealing with an API that is brand new to me, and will take time to absorb.

Wish me luck!

Related posts:

1. Update on my Android Developer Challenge 2 attempt

Related posts:

1. Barra de Español 1.2 is now available!
2. Barra de Español has been accepted to Mozilla’s public addon list
3. Barra de Español: The making of a Firefox extension

I have just released a new Firefox add-on called Barra de Español, a toolbar for those who are studying the Spanish language. It makes it easier to find definitions for words in Spanish or English, it helps you insert special characters that are specific to Spanish into any textbox in Firefox, and it provides links to native Spanish websites useful for learning the language. You may install it from addons.mozilla.org.

Jealousy inspired me to create this add-on. A couple of months ago, I saw an article on Tofugu.com about a Japanese toolbar and thought to myself, “Why do the people who study Japanese have all the cool tools? Where is the cool stuff for Spanish students?” Seriously, I see links to cool Japanese tools all the time, but rarely do I see the same thing for other languages. So rather than letting jealousy slowly consume me like a snake eating a mouse, I did something about it.

Doing something about it did not happen instantly though. With as many years as I’ve been writing code, I still cannot conjure working applications into being through wishful thinking alone. Also, I’ve never written an add-on for Firefox before, I did not know what was involved. Searching the tubes provided me with this handy tutorial on creating a Firefox toolbar. This was exactly what I needed, and explained in small steps the process of creating a toolbar.

Firefox add-ons are written using XUL, Javascript, and CSS. As a web developer, I already knew two out of the three. XUL turned out to be pretty simple though. It’s just an XML-based language used to describe the UI, just like you would use HTML on a web page. Some of the Javascript I wrote did require some googling, because in addition to the standard stuff (DOM, etc) used in Javascript when doing web pages, there are APIs specific to Firefox that you need to use. Overall the process of putting together this add-on was pretty quick and easy.

While I may have skills in art of coding, I lack any skill in the art of… art. So while I was able to put together a nice, functional toolbar on my own, it was ugly. What it really needed was some decent icons. Instead of taking art lessons, I looked around a bit and I found an excellent set of icons created by Yusuke Kamiyamane which were free to use under the Creative Commons Attribution License 3.0. What a deal! I can use some nice icons for my toolbar for free as long as I give credit to the person who made them? I can’t beat that.

To my credit, I did create the icons that look like “á” and “Á”. Even I can select a font and type in an image editor.

Once I had the toolbar put together and looking nice, I needed a way to distribute it. I can use my website, but that’s not visible enough. The place to go for Firefox extensions is addons.mozilla.org. The process to get your add-on on their site is pretty easy. You register as a user, go to their developer tools page and follow the directions to upload your add-on. Your add-on isn’t publicly listed at this point though. You must first fill out all the required information about your add-on, and categorize it properly. Once you’ve done that, you can have it moved into the Sandbox, which is where Barra de Español is as I write this. Add-ons in the Sandbox get the “Experimental” label that you may have seen on some Firefox extensions. It’s also a little harder to search for them because you have to specify that you want to include experimental extensions when you search for add-ons.

The next step beyond the Sandbox is to get your add-on publicly listed. In order to do that you must upload some images showing your extension to the addons.mozilla.org site, your add-on must not be considered “pre-release”, and you must get some user reviews. Barra de Español meets all three requirements now, so I’m going to nominate to be moved to public today. When I do that, I need to describe my testing process for the add-on. I tested it by installing it and using it on Firefox 1.5, 2.0, 3.0, and the 3.5 beta on Windows XP, and also on Firefox 3.0 on Linux. Worked like a charm on all of those versions thankfully, since that’s what I claim to support. From here I’m not sure how long it will take to be publicly listed. It has to go through some review process that I’m not familiar with yet. I hope it’s as easy as the rest of the process has been.

I’d like to add a special thank you to Ramses of spanish-only.com for correcting my Spanish on the Barra de Español homepage. I hope this article was informative, interesting, or both for you. If it wasn’t, then why did you read it all the way to the bottom?

Related posts:

1. Barra de Español has been accepted to Mozilla’s public addon list
2. Barra de Español 1.2 is now available!
3. Update: Barra de Español version 1.1 released!

In my last post I stated the difficulty I was having finding a python library to handle the SOAP web service which I’ll be using to get the data for this project. I gave up on using a library for SOAP and decided to use urllib2 to send the SOAP request and retrieve the response, and ElementTree to parse the response. Both of these are standard libraries in Python 2.5 and higher, so you should not need to install anything extra to use these libraries.

Creating the SOAP request

I decided to take advantage of Django’s template system to create the SOAP requests. The advantages of this approach are that I can easily insert variable data into each SOAP request, I don’t have to manually build the XML in code using a potentially clumsy API, I’m not hard-coding the XML in a string, and tweaking the request is as simple as editing any other XML file.

To accomplish this, I created a templates directory under the bible directory (this the directory where models.py lives). I edited settings.py so that Django knows where the template directory is.

In the templates directory I created a file called soaprequest_listbooks.xml which contains the SOAP request to get the list of books from the web service.

You may have noticed that this template doesn’t use any variables at all. That’s okay, in the future I will be making this code usuable for all our SOAP requests, so I will need to be able to use template variables in the future.

Sending the SOAP request and reading the response

At this point, I haven’t written any code that does anything yet. I’m going to change that now. In the bible directory there is a mostly empty file called views.py. This file is intended to contain views, which are methods that produce an HttpResponse based on a given HttpRequest. I created a view called listbooks_view, which will retrieve the list of books of the Bible from the web service, and save these books in my database.

The path used to parse the XML in the SOAP response is kind of nasty due to the heavy use of XML namespaces in the SOAP response. In my experience this is pretty common, and is just the nature of dealing with SOAP. To give you an idea of what the XML that I’m parsing looks like, here’s a snippet of the SOAP response:

If you’re following along at home, you may be tempting to run the django test web server and see if the code works. You will be disappointed when you see “ProgrammingError at /listbooks/ ERROR:  value too long for type character varying(50).” What this means is that the name field in the Book model is too short. As you can see from the SOAP response above, this webservice uses long names for each of the books of the Bible. Where I initially expected names like “Matthew” and “Corinthians I”, instead I got names like “The Gospel According to St. Matthew” and “The First Epistle of Paul the Apostle to the Corinthians.” Thankfully this is easy to fix. I edited models.py so that the name field in the Book model is 120 characters long instead of 50.

Next, I need to adjust the database so that the name column for the “bible_book” table is 120 characters long. Note that in the snippet below I use PostgreSQL for my database. If you are using MySQL or some other database, the SQL will be slightly different.

Now, you can run the django test webserver. Open http://localhost:8000/listbooks/ and you should see “Success!”

So how do I know this worked? I go back to the database to see what’s in the “bible_book” table.

If you have questions, or if I missed something or just didn’t cover it enough, then leave a comment.

Related posts:

1. BibleFeed Project: Creating the models
2. The difficulty of consuming a .NET Web Service using Python
3. Introducing the BibleFeed project