flame-broiled unicorn and dragon drenched in awesome sauce
Kotoba wants to be your friend!
In what will be an interesting experiment in social networking, Kotoba now befriends other Twitter users who make posts that match a predefined list of words or the word of the moment. The idea is for Kotoba to reach out to like-minded Twitters in hopes they are interested in learning a new language. Let me know what you think: for, against, or indifferent.
Some of you may have noticed that kotoba_app is now speaking! While the first fits and starts included my heavy-handed hand in the background, we have since gotten ourselves to where it does it all by itself. Papa is very proud.
What is all this about? How to get periodic, background process running on a web-site. This is absolutely nothing new. Every site requires maintenance scripts to handle various things. Sometimes certain processes are just too expensive to run all the time, otherwise the processes are too computationally expensive to do any other way than asynchronously (i.e. not synchronized with the user’s request). Other processes just lend them to be doing in a periodic manner (e.g. updating daily statistics).
My goal was to select a word randomly, generate a message, and then tweet it (or so say Tweeters in the know, ya know) to kotoba_app on a periodic basis.
My first approach was to use BackgrounDRb, a full-blown solution that allows workers to be called either periodically with a scheduler, or added ad hoc to a scheduler for asynchronous processing. In a word: butter. However, in what boils down to hindsight being 20/20, I put this solution together onto a shared hosting service. In short order I was asked to take it down as it was against terms of use; sadly but understandably so.
While upgrading my hosting to a dedicated server is very tempting, it is premature at this point. So what are my my other options? Cron! No, not Tron. But maybe better; hard as that is to believe. Given the ubiquity of cron I do not want to duplicate extant sources; but if you want to get the quick on this approach then skip over to Kip at Ameravant who has a very succinct post on how to go about getting cron to work for you.
While I did not get to use BackgrounDRb in production (yet), one unexpected consequence was an opportunity to refactor the extant code for twittering. In the end, the bits and bobs that call Twitter, to generating tweets, to selecting a random word have all been sufficiently separated; as they should be.
And even better? Writing word of the moment, including UI design and complete implementation, took less than 60 minutes. Then again, we are using RoR, the ultimate in web rapid development frameworks. But still, not shabby.
Some years (ahem, many) years ago I met the quite interesting fellow, Dave Malinowski, while a student at the University of Kanazawa, Japan. (For those in the know, we call it 金大. Tokyo cannot have all the fun.)
At the time I recall Dave being an amazingly adaptable and capable linguist who was comfortable in every setting, every culture, every language. Needless to say, we both admired and envied his near savant levels with language; the rest of us laggards struggling far behind.
Flash forward to today. Dave is now in Berkeley doing what he does best: bridging cultures with a wonderfully titled site, Found in Translation. Dave has a number of articles in English and Japanese that you can read more at here. And for those who are learning Japanese, take some heart, or solace, in reading Dave’s post on the horrors of kanji.
As an aspiring student of Japanese who believes that language acquisition is more just the bricks and mortar (words and grammar), I find Dave and his colleagues work inspiring. They are doing a wonderful job of providing a meaningful forum for persons yearning for that singular, shared dream: understanding.
Kudos, Dave!
In order to help introduce ourselves to new words sometimes it is best to find them serendipitously. While serendipity by not definition is not something we can will to happen, there are some good substitutes. Kotoba now offers a moment’s word. Just refresh and continue your journey, or come back whenever you want to learn, or rediscover, a word.
Additionally, you can follow kotoba_app on Twitter; our friendly bot will bring you new words on a daily basis.
One thing that I like to do is ensure I am using the best practices I can even (especially) in my personal projects. Kotoba is no different.
One thing that has bothered me with Rails is the myriad of ways to get external components into a project. Gems are, of course, a great way to get system-wide control of gems, but then you need to manage them a bit more explicitly to ensure that your system configuration does not change from under your feet when a newer version gets installed afterwards. You can just import it directly from a source repository. Quick. Dirty. Bad. Bad. Bad. Did I mention it is bad? Yes. Bad.
While some of the projects I am using are located on Git repositories (more on this later), there are a few that are using subversion much as I am. While svn has the concept of externals, this can be a whole lot of messy when you have multiple externals, each of which gets interrogated every time you do an update. Ultimately, svn-externals require more work than they are often worth. Why do something when you can be lazy and let a tool do it for you?
Solution? Piston. [1, 2, 3]. Both Robby and Chris make good points about how difficult svn-externals can become. Piston just makes it simple.
To import a project from svn:
piston install svn-url vendor/plugins/project_name
To lock to the specific version of a project:
piston lock vendor/plugins/project_name
To unlock and update then:
piston unlock vendor/plugins/project_name
piston update vendor/plugins/project_name
To see that status of your Piston managed projects:
piston status
And what about Git and Piston? 1.9.1. Alternatively, here. Unfortunately, as of tonight I have not been able to get this to work. But I have not given up.