CL-Twitter is here, for (some of) your lispish twittery needs. Or it will be, once the code is in a usable state.
Right now you can load twitter.lisp into a REPL and make, delete, list posts, and so on, but it’s broken as an asdf package. I’ll fix that later – right now this is more proof-of-concept stuff while I learn how CL works.
It’s tested in Clozure, but the heavy lifting is all done in drakma and cl-json.
It does. I’m not entirely it’s an active project these days, but I’ve been using it to get up and running with clozure. Getting clbuild to work with clozure involved a bit of jiggery-pokery, however. Basically what I needed to do was:
implementations to point to an architecture-specific release./clbuild update cclclbuild.conf:
DEFAULT_LISP_IMPLEMENTATION=ccl
CCL=/home/alex/clbuild/source/ccl/lx86cl64...and that's it. ./clbuild slime does what I want, and I haven't found anything that breaks ./clbuild install yet.
I'm cutting my teeth on a twitter client library (because yes, the world does need another one, damnit) which I will either a) post to github, or b) bury under the blissful outpourings of /dev/rand.
Well, all I can say is that I hope I’m not treading on anyone else’s namespace with my little effort.
I finally got bored with rolling and re-rolling my own command line processors in Python, so I’ve knocked together a little something to make things simpler for myself.
It’s loosely based on the marvellously prolific Ara T. Howard’s main gem, but it doesn’t have nearly the feature set. Yet. I guess I’ve given myself something to aim for there.
Anyhow, here’s how to use it, nicked straight from the README:
import main
import sys
def callback(params):
print "Called with " + params['foo'].value
m = main.mode("run", callback)
m.option("foo")
m.description="How not to be seen"
main.process(sys.argv)
Called as:
$ python b.pyOutputs:
Usage:
# How not to be seen
b.py run --foo=<foo>Called as:
$ python b.py run --foo=barOutputs:
Called with barThere’s lots left to do (decent error handling, for instance – it makes a modicum of effort, but largely you can expect mistakes to blow up in your face), but it’s a start.
My last post (from ages ago) dealt with creating a parser wrapped around celerity. That approach has since stopped working because of API changes, so I figured I might as well see about doing it properly by directly talking to NekoHTML, which is the parser underlying HtmlUnit. If you install celerity, you get the nekohtml jar anyway, so I figured I might as well try to make some sort of use of it.
Because I’m not so familiar with the Java XML APIs, this took me more hunting than I expected, but I’ve wrapped it up in a gem for posterity.
In other words: ew. This code is icky but (possibly) useful.
require 'nekohtml'
html = "<html><head><title>Title of Majesty</title></head></html>"
Nekohtml.parse(html).at("//TITLE").text
# => "Title of Majesty"
HTML parsing in JRuby seems to be going through a slightly odd patch. Nokogiri and Hpricot both seem to have problems. There’s one project I’m working on at the moment which needs xpath support, and by chance I happen to be using Celerity, which wraps htmlunit. If I need an HTML parser, I thought, there must be one somewhere hidden within that I can use. For extra bonus points, I wouldn’t even need to package any native code, celerity already has that covered…
And so it came to pass. celerity_parser is an almost trivially thin wrapper around HtmlUnit’s HTMLParser class that’s got just enough functionality to do what I need, which is search for elements by xpath, and extract text and XHTML structure. When I say “trivially thin”, I really mean it – there’s a grand total of 2 Ruby classes, and 5 methods you might want to use.
Here’s how it works, taken from the README:
root_node = CelerityParser.parse(html_content)
found_elements = root_node.search("//html/head/title")
found_elements.first.text # => "Html page title"
That’s pretty much it. Dependencies are on jarib-celerity and jruby itself. Enjoy, and I’m open to pull requests and suggestions if you need more than this. I’ve not done any speed tests, but it’s native Java so might be quite nippy.
It’s slightly more involved than you might think to make a custom Rails environment that is based on another. In my case, I wanted to have a staging environment that was as close as possible to production. So, I thought require 'config/environment/production' should do the trick.
Not so.
Because of the config.foo magic and the fact that it requires binding tomfoolery, environments aren’t loaded, or loadable, with require. They’re read and eval’d. Here’s what I’ve got at the top of config/environment/staging.rb at the moment:
production_environment_path = File.join(File.dirname(configuration.environment_path), 'production.rb')
eval(IO.read(production_environment_path), binding, production_environment_path)
So far so good. I’ll update here if that turns out not to be the whole story.
I stumbled on this today. I don’t know why, but I’ve always had a block over what the word “monad” actually means, and how the bind and return operations map to that meaning.
In the linked StackOverflow post, there is a single sentence that fixes the problem:
An alternative term is computation builder which is a bit more descriptive of what they are actually useful for.
Ah-ha! The rest of the post is made up of some great examples. Go read if you’re as confused as I was.
As part of the spangly new and exciting project I’m working on, I’ve got a dumb JRuby client app that runs on the user’s desktop, which I need to have upload data to my S3 buckets. I pondered and read for a bit. S3 is new to me, so I was wandering off down the path of “touch the key with a public-writeable ACL, wait for a completion notification callback, then close the ACL.” This, obviously, is madness.
Luckily, the fine folks at Amazon have already thought of this, and provided a POST mechanism designed for browsers. It’s got a slightly strange gotcha, though: the uploaded file must be the last element in the POST body. This and Ruby’s default Net::HTTP API sent me looking for alternatives to building the post by hand.
The solution is quite neat. I’ve got a teeny Sinatra app sitting on the server whose only purpose is to serve prevalidated upload forms to authenticated clients. Auth is provided by Rack. The client just uses 6 lines of Mechanize code to fill in the form details and submit it to S3. It’s rather a library-heavy solution, but as a concept it doesn’t get much simpler.
And simpler is better.
For reference, here’s my standard Rails kit at the moment:
I want to add cucumber and thin to this, but cucumber has given me problems in the past and I just haven’t got round to trying thin out yet.
The more I think about it, the more I think that we need controller tests in Rails that don’t render. Functional tests just don’t cut it if you’ve got anything non-trivial in either the controller actions or the view. I know we should be aiming for simplicity in precisely those places, but sometimes you just can’t distill everything into a fat model.