You need to install openssl-devel, zlib-devel, bison, gcc, make, patch, tar, and maybe gcc-c++ (although I don’t think this one is needed).

Go get the latest ruby 1.9 source, as of this writing 1.9-p378, and extract it somewhere. Then go get the patches on this bug, at the specific comment. You will need to apply at least the openssl-build-fix patch, since fedora uses openssl 1.0 and it’s not yet into ruby 1.9. Then follow your typical ./cofnigure, make, and make install stuff. I installed mine into a prefix of /opt/ruby so that it wouldn’t affect any fedora ruby stuff that it might want. I then added ruby’s path to the end of my user’s PATH variable.

That’ll get you a working ruby 1.9 in Fedora.

Woot.

EDIT:

Man, this guy has all sorts of good stuff: http://www.vim.org/account/profile.php?user_id=9012

cucumber, rails, ruby, git-vim integration. VIM FTW!

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.

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.

Unit testing in ruby is just like unit testing in any other language. Assert_* methods abound.

Using the debugger is similar to using gdb or some other debugger as well. There’s a list of commands, you can set breakpoints and watch variables. Nothing very surprising there.

The author offers up a “checklist” for going through your program to ensure that it all works. He firstly reccomends that you run the program with -w. Keep warnings on, so you can resolve issues. He mentions an interesting issue with precendence regarding {} and do…end. To quote the example source code from the book:

def one(arg)
  if block_given?
    "block given to 'one' returns #{yield}"
  else
    arg
  end
end
def two
  if block_given?
    "block given to 'two' returns #{yield}"
  end
end
result1 = one two {
  "three"
}
result2 = one two do
  "three"
end
puts "With braces, result = #{result1}"
puts "With do/end, result = #{result2}"

Which produces:

With braces, result = block given to 'two' returns three
With do/end, result = block given to 'one' returns three

So that’s something to keep in mind. Another gotcha that caught me, is that output may be buffered. I was writing a program to theif images from a website, and I wanted to use print “.” to show completion of an image, but the software wouldn’t show anything. puts “.” would work, but that put a newline character. I hacked around it by calling $stdout.flush to force it to put the . to the console. Setting “sync” on the thing may have worked better.

Also of note is a benchmark module built into ruby. You can profile and run benchmarks and it’ll provide you pretty statistics after running. I’ve used the java profiler before in the past, and it can really help you identify slow parts of your software.

That’s mostly the core of the language, and how to build programs. Now, I get into more of the grunt work of building ruby software. I’ll have to look into section two and see if I’m going to jump directly into rails or not…

Fibers are completely 1.9. There’s no such thing as fibers in ruby 1.8. They sound like they’d be some kind of lightweight thread, but are really just a coroutine. I’ve never heard of coroutine stuff before, so this concept is new to me. It allows you to decouple a few things. The books example is having a background fiber running some complex calculation while the main thread does something with the previous result of that calculation. There’s some more on fibers, coroutines, and continuations, but the text doesn’t appear to be very complete on this part. It links to oblivion to get more information on continuations. Doh.

Multithreading. Ruby 1.8′s threading model was implemented entirely within the interpreter. So you only got one thread on the CPU, one core. Not so great. Ruby 1.9 has some marginal improvements so that you can run native threads, but due to the thread model changing it will never really run more than one thread concurrently. So while it can jump between threads quickly, you can’t have a truly multithreaded application in ruby. I’m hoping that ruby 2.0 or maybe 1.9.1 will have updated those libraries that don’t work in this threading model so that true multithreading can happen. Especially for things like Rails, where it could provide a huge performance benefit.

The exsting threading abilities in ruby are pretty potent. You can get the stats, see if it’s alive, join with it, and set the priority of the thread. Threading behaves similar to how it works in other languages. Without the debug flag set, a thread that raises an exception will die, but the others will continue. Which is the way things should happen, but it’s difficult to catch exceptions that way. You can set abort_on_exception to true, and then the vm will abort with a RuntimeError when the thread raises an exception. There is of course a mutex to help with synchronization issues. Finally, there’s also a Queue class for producer/consumer type applications.

Now you get into running multiple processes. The simplest is to just call system(“do some command”) or use backticks `.  If you want to have a small conversation with your external process, you’ll need to use IO.popen. You can then talk to it and read from it. You may have to flush the data to the IO object. Nothing terribly new to people that have worked with external processes before. Ruby supports a fork(2) type invocation by passing a single minus sign to IO.popen(“-”,”w+”). Ruby will then fork off another interpreter, the parent will get back the IO object, and the child will get nil. Ruby also supports Kernel.fork, Kernel.exec and IO.pipe, but the book doesn’t go into it much, except that it’s platform dependent. Lastly, you can pass a block to it IO.popen. Works amazingly similar to File.open. Block runs, and when it’s done the popen is cleaned up. A naieve assumption again, however, because it’s difficult to do any error handling.

Well, that’s it for today. Next up is Unit testing. Blech. I may be almost ready to go on to ruby on rails. The second part of the book is “Ruby in its setting.” Talks about Command-Line arguments, namespaces, character encoding, documenting ruby, ruby and the web, and finally ruby and Microsloth Windows. May have to skim those chapters. It might be time to learn me some rails! And build something!

An IO object in ruby is a bidirectional channel between ruby and some external resource, to almost quote the text. There’s a foot note that tells you that a single IO object may have more than one file descriptor. The text talks about how things can automatically close, but poor error handling can cause problems there. The example given is where you pass a block to the File.open method. You process the file within the block and if everything goes well, the file is autmoatically closed when the block ends. However, your file variable is scoped within that block, so if an error is thrown, you lose your file variable. You’ll end up with an IO object floating around in the heap, keeping files open, until it finally gets collected. Not really a good thing to do.

There’s a few examples on reading from files. You can read an entire file into a string, or into an array of lines. Kinda handy. Just don’t forget to rescue exceptions. Writing to files is pretty simple. You can even simulate an iostream from c++ since the << operator is set up for append in ruby. You can also include ‘stringio’ and do all your fancy file operations directly in memory on strings. Handy for when you need to submit stuff via XML-RPC or some sort of HTTP method.

Ruby comes with a set of classes in the socket library so that you can play with TCP, UDP, SOCKS, and Unix sockets. You can also deal with network goodies at a very high level. To thief a simplistic example from the book:

require 'open-uri'
open('http://pragprog.com') do |f|
  puts f.read.scan(/<img alt=".*?" src="(.*?)"/m).uniq
end

That example there shows how painfully easy it is to theif images from a website. Of course, this is a naieve example. We don’t rescue any errors or anything, but still, it works quite well. The text promises more to come in Chapter 20 about using Ruby on the interblags. I can’t wait!

Turns out I was getting sick. Bleh. Yay for day-quil! Anyway, the chapter in the book on Exceptions is kinda small. Exceptions work just about exactly the same as they do in Java. Throw and catch aren’t quite the same, however. In ruby you “fail” or “raise” an exception. “throw” and “catch” work for bailing out of loops.

In ruby, exceptions are caught by using “rescue” and behave just like catch in Java. There is also a “finally” type clause, called “ensure”; behaves the exact same way it does in Java. Ruby has the concept of a “retry” which is kinda neat. There is great potential for infinite loops, however, so take care. “raise” in ruby behaves the same way as “throw” in java.

“catch” and “throw” are different. You use it to bail from a loop. Ruby will crawl up the stack when you throw something, looking for the location to catch it. Then it’ll jump outside that loop and finish. I personally think that’s pretty spagetti code inducing, but I can see where it might have its usefulness.

And that’s it. This blag post is really almost as long as the actual chapter. Next up is I/O.

The book discusses defining and calling methods. This is a very fascinating topic, not. They only new thing there for me was “splat” args. The concept of rolling up all the arguments into one array and then you can hand that on to the super, or another method. The *args will get automatically expanded into parameters for the other method.

More things are expressions in ruby than in other languages. If statements aren’t statements, they’re expressions. If returns a value.

Parallel assignment is another new concept. Wierd, but useful. It makes it easy to swap variables. You don’t have to define a swap variable to switch things out.  Nested parallel assignment travels down the dark rabbit hole of insanity. It’s ugly to look at, and difficult to comprehend. You can use splats to eat variables. You can have a single splat anywhere in the assignment (a, *b, c) and it’ll eat everything as long as the rest of the variables are satisifed. So you could eat everything in the middle, and just have the first and last ones assigned. I’m not really sure where this will be useful, but it’s there. Finally, there’s no ++ or — operator in ruby! You have to use += 1.

Theres the standard gamut of boolean operators, adding a few. && and “and” do short-circuit logic, so that’s nice. However, ”and” has a lower precedence than &&. To mix it up even more, “and” and “or” have the same precedence but && has a higher precedence than ||. I believe that could cause some really wierd problems for people expecting a certain behavior. I think I’ll stick to just using && and ||. There’s a construct for setting a value to a variable if it doesn’t exist: var ||= “default value”. Makes it easier than using an if statement. Flip-flops were mentioned again using conditionals and ranges. Perhaps if someone requests it, I’ll try to explain it better, but I think I understand the concept well enough and don’t really need to go into it again.

Case statements are far more powerful in ruby. You don’t have to have a simple type. Since everything is an object, case uses the method ===. That makes it really awesome. You can have a case statement doing regular expression evaluations to parse lines. Quite handy. You can attach a conditional to a statement to only run that statement if $foo evaluates to true. Reads nice and clean, however you can quickly descend into madness if you’re not careful. You can have if expressions that return a value only if $foo. So yeah.

y = if even then
  6
else
  5
end if assign_y == true

According to the text, ruby has lame built-in looping constructs, because iterators handle the majority of looping! You’ve got the standard while and until construct. You can attach while and until to a block, but the block will always be run at least once, regardless of the evaluation of the while or until. That’s not quite normal, especially since it won’t run a statement once. There’s “next”, “break”, and “redo” modifiers to manipulate flow of the loop. Redo is quite handy, makes it simpler than using recursion to reprocess a line. For .. in constructs are neat, basically it’s a cleaner way to write iterator |paramter| block code. It has a bit of scoping difference, so I’ll probably try to stick to the more explicit syntax. 

A bit on scoping. Ruby 1.9 has a concept of block local variables, so you can define a variable that is scope limited to a block. The example in the book shows it pretty well, you have a variable called square, defined outside the block. You then use a variable square within a block, with a different purpose. Now my variable outside the block is broken, because the scope leaked. You can prevent this in ruby 1.9 by |; square| as a block parameter. It’s now local to that scope and your external variable is unaffected. Yeah, you could just use a different name, but this improves readability. At least, I think it does, my brain can handle keeping scope. Turning on ruby warnings (which by the way is appearing to be a good thing to do) will help you catch these scope issues.