Back in 2007 I wrote an article for DevX giving a quick intro to Ruby goodness. I've now found that you need to sign up or register or something to read it.
Since my contract says I get the rights to the article after 120 days, I've re-posted it.
The video from my Ignite Phoenix 7 talk, "Fashioning Technology: Wearable computers and a network of things", is up on the Neurogami YouTube channel. Watch it
The video of my MountainWest RubyConf 2010 talk on Hubris is now available.
James Britt: Hubris - The Ruby/Haskell Bridge from Neurogami on Vimeo.
You can watch it on Vimeo or grab it from the Confreaks site.
There are plenty more sweet videos up on Confreaks as well, and of course the usual goodness on the Neurogami Channel
As with Rawr, the Monkeybars project will be moving off Kenai.
Code will move to GitHub, tickets to Pivotal Tracker, and they'll be a Google Group set up.
Once that's done, some code from Jimpanzee will be copied over. In particular, they'll be some bult-in support for using Neurogami::SwingSet.
SwingSet wraps some core Swing components to make it easier, and nicer, to create UI objects with simple, text-edited, Ruby.
Monkeybars could always create and manipulate Swing objects created using inline code, but you needed to fall back to Java/Swing naming. It was useful and nice but not as clean as it should be. Great for tossing up a simple alert box, less great for doing, say, a data input form.
This was rarely an issue because knocking out a GUI using the free WYSIWYG editor in Netbeans was easy and and convienent. And experience has shown that you really do want to use a proper GUI editor and robust layout manager when building sophisticated applications.
Nonetheless there were people who incorrectly believed that Monkeybars required Netbeans. Or some other GUI tool. And people who just don't want to open up some extra tool unless they really really have to. Well, Neurogami::SwingSet takes care of all that. You can eat your cake, and have it, too. (Makes for great "gee whiz!" demos, too.)
Rawr, the world's greatest application packaging tool for cross-platform JRuby apps, is moving. We're migrating away from Kenai, and over to GitHub. And Pivotal Tracker. And Google Groups.
The new repo home is http://github.com/rawr/rawr
The plan is to next revive the Rawr-lib Google Group.
Then, move the current issues over to Pivotal Tracker.
And then plan a new release!
Thanks to Mark Wotton, Hubris-Haskell (that Haskell portion of the Hubris Ruby/Haskell bridge) now works on 64-bit Ubuntu.
When I last tried it I got some nasty errors. Mark has fixed this, and I gave it another whirl.
I'm using Ruby Version Manager on my Kubuntu 9.10 64-bit desktop PC, and to build Hubris-Haskell I needed to tell it were to find the libruby.so.1.9 files. (BTW, if you want to play along you need to tell rvm to always build ruby with --enable-shared so that you get the required shared object file.)
I then added the libruby.so location to /etc/ld.so.conf, and ran sudo /sbin/ldconfig.
From there I was able to run the example code that comes with hubris with no trouble.
Sweet!
A new version of Rhesus has been released.
Rhesus is a simple yet powerful code templating tool. It uses prototype folders and files to generate code, with variable substitution.
This release has some minor changes and bug fixes.
The template options file, originally called .options.yaml is now called .rhesus-options.yaml
Importing new template folders from a git repo now works.
Rhesus was borking automagic file and folder naming conversion, where it decides whether some file or path should be created as CamelCase or snake_case. The current fix is the addition of a language setting in the options file. Right now it only reacts to ruby, in which case it assumes that files and folders should use snake_case. If you omit that it looks for certain file name aspects (e.g. common Ruby file extensions) and uses that to drive the format. But this has been unreliable, hence the new option.
This is an unsatisfying solution for assorted reasons, but mainly because it's so heavy-handed. But the fix does make things work better.
I've started looking at Crocodoc,a Web site that allows you to upload documents and share them for editing and comments. It's quite slick and nicely done. Even better, there's a Web API. There's now also the start of a Ruby library to wrap this API: Neurogami::Crocodoc.
It's still pretty beta, meaning the API may change and it has a few hacky features in place to try out some behavior.
For one thing it is usng curl for all HTTP requests, at least until I replace it with some Ruby code. This was a fast way to get started and it makes it easy to see what's happening if a request fails.
It's also using an ad-hoc YAML file to store document details. At the moment the Crocodoc API does not have a methods to get a,list of your existing docs. However, to do anything with a document (aside from uploading) you need its UUID. You get that when you do an upload. So, in order to be able to later go and manage existing documents the Ruby code is storing off the data returned for a successful file upload. I have to believe that the Crocodoc API will include a file list method at some point so I'm not too concerned with the current workaround. On the other hand, having a way to cache this data could be handy. Actual usage will drive the code though.
As of today I am the admin for the Monkeybars and Rawr projects
I’m taking over from Logan Barnett who has, without a doubt, done a fantastic job with these projects. (And of course big props to David Koontz as well. David and Logan have been the magicians behind Monkeybars and Rawr.)
My immediate plans:
The means not just going through the code, but getting more familiar with Kenai
These are forks of rawr and Monkeybars, created to make it easier for me to pursue certain design, packaging, and business goals. It worked well for me, but it’s less useful overall to have multiple projects that are kinda sorta the same.
I don’t want to impulsively just merge in the features that distinguish my forks, but I know that at least some of them have good use cases and should be made regular features.
However, I hope to get some feedback from current rawr and Monkeybars users to see how best to go about things.
It is quite likely that I will move things off of Kenai. I’ve never really liked the site; the mailing list has wonky navigation, and I’d prefer to just use github for the repo. Bug tracking is another matter. Github’s issue tracking is OK, but not terribly robust. Pivotal Tracker may be a better choice.
But there may be features or options in Kenai that I’m unaware of, especially regarding the integration of tools, so I need to do a bit of homework.
If you are a user of Monkeybars or Rawr let me know your thoughts on the Kenai services.
Comments [0]