Shlrm.org Blag

Reading about groovy. It’s got some really interesting things. It brings the magic of dynamic typing and such (like ruby and python have) to java. But it doesn’t replace java, it simply adds it to java. So when you’re writing a groovy script, you can actually just write pure java and it’ll still work. That’s a very interesting (and potentially evil) feature. Imagine code with groovy and java intermingled. Yikes.

Anyway, there’s also something called grails. It’s groovy’s rails application framework. I’m hoping that it’ll be more useful to me than ruby on rails was. Whilst I was able to get some stuff done in rails, I wasn’t able to do quite what I wanted to do. Things didn’t interoperate the way I wanted them to. Building things to be completely REST-ful was a pain. It may simply be that I don’t know enough to do fully RESTful applications.

Also, testing was a pain in rails. I found several testing frameworks, but none quite fit what I wanted to do. That may have had something to do with my insistence upon using constraints in my database. Rails isn’t built to handle constraints, it wants your database to be dumb. I don’t really think that’s a good thing; having constraints in your database allows the database to make more intelligent optimizations regarding the data. Since rails assumes there aren’t any constraints on the database, it generates tests that break databases that use constraints. There are a few work-arounds, but none that exist well enough to actually run all my tests at once. I can piecemeal them and if I do them in the correct order, everything works just fine.

Regarding ruby itself, I miss the ability to create threads. I’ve finally understood threading in java, and how to efficiently and effectively use threads to handle things. Lacking a similar threading operation in ruby (at least an obvious one) I had a lot of trouble trying to implement some of the things I wanted to do. I love the dynamic-ness of ruby, and I like the ability to just write code and it does mostly what I think it should. There is probably a good way to do threading in ruby, I mean, people have written webservers entirely in ruby, I just haven’t figured it out. I’ll probably still use ruby for things, I’ve got a project or two churning around in the back of my mind to use ruby on, but for now, I think I’ll stick with Java.

This has turned more into a rant about what I don’t like about ruby and rails. I guess I’m hoping that grails will live up to my expectations more than rails did, and that groovy will give me the dynamic fun that I enjoyed with ruby.

I wrote this to provide me a simple wget type program.

require 'net/http'
require 'uri'

proxy_addr = 'localhost'
proxy_port = 8118

url = URI.parse('http://shlrm.org/baconflowchartvj8.jpg')

Net::HTTP::Proxy(proxy_addr, proxy_port).start(url.host)   do |request|
  puts "Connected to teh proxy"
  # connected to mah proxy
  to_save = url.path.split(/\//)[-1]
  File.open("c:\\" + to_save, 'wb') do |f|
    puts "opened file"
    request.request_get(url.path) do |response|
      content_length = Integer(response['content-length'])
      total_count = 0
      response.read_body do |str|
        if str.length > 0 then
          total_count += str.length
          print "Complete: #{total_count} of #{content_length}:  "
          puts "%4f" % (1.0*total_count/content_length*100)
        end
        f.write str
      end
    end
    puts "Written file"
  end
  puts "done connecting"
end
puts "all done"

So that’s it.

Well, this is all that’s left for learning the core of the language. How to use ruby’s built in Unit Testing framework and how to fiddle with the debugger. This post will be very short, because there’s not a whole lot to unit testing. Going over the debugger is kinda silly too, since it’s mostly just a command reference. Also, I found an interesting gotcha in the examples listed that I’ll share with you. There’s a benchmarking and profiling module worth saying a few words about. (continue reading…)

Fibers, threads, and processes! Oh, my! Fibers are probably the most interesting part of this, and ruby’s slightly broken threading model. Processes are interesting from the aspect of being able to communicate with external programs. (continue reading…)

The next chapter is one on basic input and output. This one is also kinda short. Or maybe it feels short, as there’s not a whole lot of new stuff to digest… EDIT: heh, well I started out saying it was short, but turns out I had more to say about it than I thought. Maybe I’m getting better at this blagging stuff. (continue reading…)