I’ve made some more progress on what will be my first Android market application – “Where is Io”. I’ve learned a lot about sqlite performance on the phone, which isn’t bad as long as you limit the number of database opens you do. I’m also trying to make the interface more self explanatory to even those with less astronomy knowledge. Here are the current screen shots:
I’m not going to explain anything else on the interface, but I would love questions / comments in the blog if this seems confusing. My “must do” task list probably puts this at about 2 weeks away from publish into the market. Fortunately, Jupiter is only just coming out of the Sun now (with a missing belt!) so as long as I get this out in the next month or so it will be useful to folks.
This weekend I learned about JNI… that’s a blog post for another time. The net result is this:
Yes, it looks like the glory of Atari land graphics, but that’s not the important part. The important part is that it looks a lot like that last graph I posted. The net result is that I’ve got the data being generated in an android environment.
And for those that care, Io is in yellow.
After nearly a month of tinkering with code, nearly giving up twice, and realizing that I was going to actually need to relearn my linear algebra to get a real solution, I managed to create this graph. It is the position of the moons of Jupiter relative to the planet as seen from earth.
Thanks to Thor for helping me get to the realization that straight up geometry wasn’t going to be good enough, and help boot strap my relearning of vector math. Once I started using real linear algebra I didn’t even have to cheat on generating the sign. Next step… JNI.
It’s been 2 years since I got my Proliphix thermostat, and while I did some early hacking on it, largely the whole effort just sat around for the last 2 years. However, with the fun of connecting up my weather sensors, I went back in this weekend and beat the code into a much more sane interface.
Thermostat.rb 1.1.1 was released yesterday. It provides a concise interface to the Proliphix web services API. An example of the usage is something like:
thermostat = Thermostat. new("hostname", "admin", "password")
# get the current temperature
current_temp = thermostat.temp
# get the current setback heat value
current_target_temp = thermostat.heat_to
# set the thermostat to 69F (units are set in the thermostat)
thermostat.heat_to = 69
I’ve got support under the covers for everything in the Proliphix API. I’ve only mapped about 1/2 of it to the user visible interface, starting with all the functions I’ve tended to need or use. I was a good little agile developer and built unit tests for everything here. Using the new module, I added the thermostat to my homegraph code, with some pretty reasonable results:
All this is released under the MIT license.
Over the weekend I was working on revamping a whole set of older ruby projects, some having to do with my Proliphix Thermostat. I had this crufty Rakefile from the icalendar project that I’d been copying and modifying for new projects, and it was slowly degrading. I thought that there had to be a better way. There is, it’s called newgem.
Newgem is like h2xs in the Perl world, something to stub out a new module with all the right files and structures. But, as the Ruby folks tend to do, it ups the ante in the process. In addition to the basic build, packaging, testing, and coverage results you’d expect, you also get a targets for: creating you rubyforge website, publishing your gems to rubyforge and gemcutter, posting release announcements on rubyforge, and even posting blog posts about your release (though I haven’t configured that one yet).
The release cycle is now:
rake release
rake website
rake post_news
The Rakefile created is loading these features from base modules, so it’s only ~ 30 lines, a heck of a lot easier to maintain than the 300 line Rakefiles I had which provided about 1/2 these features inline.
If you are doing Ruby development, you should really check out newgem.
About 14 months ago I raised my hand to help with a more interactive web presence for the Poughkeepsie Farm Project. This kicked off a large discussion over the course of the year, a web committee, and a great pro bono new graphic design. Many many people were involved to get this project to completion, I just consider myself a catalyst.
Today, after a year of work, we launched the new farmproject.org:
Go check it out. Now that we’re on a drupal platform, we’ll be rolling in smaller features over time. I’ve got a few ideas queued up that I’ll try to get out there for the first member pickup at the end of May.
As I’ve been working on my weather station at home at nights, I realized the code would be a lot cleaner if I wasn’t constantly keeping track of temperature units. So I created the Temperature module for Ruby which adds methods to numbers to make them implicitly temperatures, as well as a parsing method on strings. To get a flavor of it, here are some examples:
freezing_in_F = 32
freezing_in_C = freezing_in_F. to_C
boiling_in_C = 100
boiling_in_C.units = "C"
boiling_in_F = boiling_in_C.to_F
absolute_zero = "0K".to_degrees
absolute_zero_in_C = absolute_zero.to_C
absolute_zero_in_F = absolute_zero.to_F
The full documentation for the project is on rubyforge. Gems, tar, and zip format have all been published, and it should be propagating out to the main gem servers tonight. It’s not exceptionally complicated, however it is convenient, and it’s even got 236 unit tests to ensure it’s doing things right. The code is released under the MIT license, so you are pretty much able to do anything you want with it.
On March 1, 2010 · Comments Off
I’ve finally got some very simple ruby code collecting my weather sensors to the round robin database. It took me some time this weekend to finally get my head around RRD, with having to predefine all the data you want to keep and how. It’s not much, but it’s a start.
On February 24, 2010 · Comments Off
We’re 1 step closer to the launch of the new Poughkeepsie Farm Project website, so it’s down to some final edits before it gets flipped live. While I was looking over the test site the other day, I realized we still had some links, and images that referred to the existing site, which would break once we did the final domain switcheroo.
I came up with the following snippet of jquery to highlight bad links and images client side so that editors would realize they needed to do something about them:
function highlight_bad() {
$("div[id='content'] img[src^='http://farmproject.org']").css("border","9px solid red");
$("div[id='content'] img[src^='http://www.farmproject.org']").css("border","9px solid red");
$("div[id='content'] img[src^='http://test.farmproject.org']").css("border","9px solid red");
$("div[id='content'] img[src^='http://pfp.dague.org']").css("border","9px solid red");
$("div[id='content'] img[src^='http://farm.dague.org']").css("border","9px solid red");
$("div[id='content'] a[href^='http://farmproject.org']").css("border","9px solid red");
$("div[id='content'] a[href^='http://www.farmproject.org']").css("border","9px solid red");
$("div[id='content'] a[href^='http://test.farmproject.org']").css("border","9px solid red");
$("div[id='content'] a[href^='http://pfp.dague.org']").css("border","9px solid red");
$("div[id='content'] a[href^='http://farm.dague.org']").css("border","9px solid red");
}
So every time we find a link or image that starts with an absolute url to one of the addresses the site has had inside the content block, we highlight it. This has been incredibly effective so far in catching some things I didn’t even realize was an issue. This with the combo of drupal’s broken link detector internally is helping us ensure the content is consistent prior to launch.
Mo Hax and I have started a weekly effort to gather up some of the IBM internally created OpenSim / Second Life content and contribute it to OpenSim as stock content. As OpenSim approaches the 0.6 release, it would be good to have some more reasonable stock content included for those people that aren’t Second Life Heads, and have huge inventories of their own stuff sitting on their disks. The results of week one was a single handshake animation, and a lot of understanding on how our stock content system works, and how it should be changed to make it easier to contribute to it.
Yesterday, in between builds and meetings, I decided to refactor a few LSL scripts I had that used unique OSL functions that let you dynamically create textures on objects, both from text drawing commands, and from images of the internet. Those are all now in the OpenSim Library, and accessible for anyone in world. They are under the same license as OpenSim, so do what you will with them.  (Note: I’ve found the client caches the inventory trees, so you’ll need to clear cache before they show up.)
The scripts contributed yesterday are as follows:
- osTextBoard – a text board I wrote to do agendas or note taking in world. Modify the script, hit save, and you get the content in your text board texture. Multiple font sizes, colors, and names are used.
- osWeatherMap – a 3 panel cycling weather map for US weather. This is inspired by the work nebadon did on osgrid.
- GrafittiBoard – Justin Casey’s GrafittiBoard (as seen on osgrid), which is similar to text board, but has an llListen hook so that if you talk on channel 43 it displays it on the board.
Consider all of these as launch points to more complex things. But, they’ll at least give people a flavor of what is possible. And you’ll get it with every opensim build.
|
|
