Also, this is kind of long.)

I have the following association set that represents a document repository.


User 1-n Folders
User 1-n Roles
Folder 1-n Documents
Documents n-n Brands


Folders n-n Viewer Roles
Folders n-n Manager Roles


Lastly, Users n -(polymorphic through)- n Brands

In order to display a tree of Folders a given user can view, that User must
be a manager or viewer of a Folder, and his Brands contain Brand of at
least one Document under that Folder (a Document associated with a Brand under a folder lets the user view that Folder iff that user has the Brand.)

So the way this was originally implemented was a recursive loop
something like this:

def show_subfolders(folder)
User.folders.each do |folder|
show_subfolders(folder)
end
end

Class User
def folders
Folder.find(:all,:conditions => ‘parent = folder’,
:include => [:manager_roles, :viewer_roles, {:documents => :brands]]
).each do
|folder|
if method_to_check_brands(folder) && method_to_check_view_perms(folder)
yield(folder)
end
end
end

The eventual problems that developed with this logic were the following:

1. second-level includes are problematic in Rails, this generated
   outer joins against seven tables
2. massive join, recursively called. I believe the Big O* is (c!)^n,
   glancing quickly
3. Indexes don’t help, because the outer joins sort of blow the
   performance gains away
4. All data is being selected, so just sheer amount of data transfer
   slowed things down
5. The yield adds a lot of crap to the callstack
6. Brand and View/Manage permissioning was already happening in the code

With 245 documents under 30 folders, mysql logged slow queries that
had to examine 320,000 rows — and that was multiple times.

The solution? Remove the :includes. Since permissioning and
restriction was already happening in code, I let Rails do its own
thing and select when necessary. This lowered the response time from
10+ seconds for page view to 0.5 seconds. (And for what it’s worth,
doing the join statements manually, or removing the second-level :includes only brings it down to 2 or 3 seconds.)

By reducing the stuff that needs to join, indices are are used more
efficiently, and letting Rails do a find for Folder.documents on each
iteration ends up being a lot faster than trying to join with the
view/manage/brands permissions.

The More You Know!

* It’s been over a decade since I actually figured out the order of an algorithm. I’m sort of guessing, here.

Well, here’s a quick and dirty migration that’ll save you from moving files manually.

Automove Files for Storage Changes, with acts_as_attachment

Originally I wanted to do something like Attachment.new( OldAttachment.find(?).attributes ), but there were issues with that because acts_as_attachment wants uploaded data to be a tmp file or some crap. This ended up being the easier way, all in all.

Use with care.

Since Paypal purchased Verisign they are discontinuing the pfpro extension to PHP. And in fact, what I’m reading is that Sept 2009 is the end of life for that functionality, meaning requests will not work beyond that point.

For sites using pfpro that ned to transition, the solution is
1) use the java sdk
2) use the .net sdk
3) write your own api to utilize curl and https
4) use a public api for curl and https a la This post from the paypal developer forum

ALSO…
this means if you’re installing a 64 bit system, you’re pretty much screwed because there are no new libraries/binaries released for pfpro under that platform… unless you’re running a .net or java solution.

Sucks.

• build-essential
• ruby1.8, librubymysql, ruby-devel,gems
• mysql
• vim-full (ruby, perl, etc)
• subversion
• kernel-headers
• exuberant ctags

Config

• nvidia-glx
• envy
• gnome-color-chooser

Graphics

• inkscape
• gimpshop

Connectivity

• synergy
• ssh-server
• citrix client
• sshfs
• nfs
• smbfs

Misc

• firefox extensions
• compiz-fusion
• amarok
• restricted codecs (w32codecs, mp3, flash, etc)
• msttcorefonts
• gmail-notifier
• tilda
• vmware-server
• opera
• ies4linux

There are a bunch of other things I have to set up as well, such as NFS mounting the dev server, installing Vim plugins, and reinstalling my Firefox extensions, but for the most part it took about an hour and a half from the start of install to finish for me to get my box up and running nicely again. I really like Ubuntu’s package management

Protip: Put your dot files (such as .gaim or .vimrc) into subversion. Makes migrating and recovering from HDD failure very easy.

Compiling Ruby 1.8.5 on an ancient redhat box is difficult. It’s not as simple as just make/make install… it doesn’t work right out of the box. My solution was to statically link ruby during compilation.

1. Grab the source
2. Extract
3. Do “./configure”
4. Edit ext/Setup (a text file), and uncomment everything except for
   1. openssl (unless you have openssl 0.9.7 or higher)
   2. pty
   3. Wil32API
   4. win32ole
5. Move ext/openssl out of the install directory
6. ‘make’
7. su, then ‘make install’

This got me a working ruby installation, minus openssl and pty. The problems I was running into were library related, mainly glibc, libssl, and crypt libraries. It’s certainly possible to get a working installation without all the monkeying around with statically linked executables, but I was running a risk of destabilizing the rest of the system by doing that.

Note: Your Mileage May Vary

Good luck!

A Very Contrived Example:

def string_to_integer
  if block_given?
    yield.to_i
  else
    0
  end
end
a = [1,2,3]

A) a.inject string_to_integer { ’5′ } do |i,sum| i + sum end => 11
B) a.inject string_to_integer { |i,sum| i + sum } => undefined method error
C) a.inject string_to_integer do |i,sum| i + sum end => 6

in A, the first brace is sent to the string_to_integer method
in B, the same happens, but the block was actually meant for inject
in C it works as intended.

Just food for thought.


require 'iconv'
require 'charguess'
# Reads an arbitrary file and attempts to convert to a new file in UTF-8
# Sort of quick and dirty
# You should note that Iconv.conv will barf if you specify
# a source encoding that doesn't match the actual source encoding
def poop_out_utf8(infile, outfile)
  if infile == outfile
    puts 'Source and destination are the same, silly!"
    return
  end
  out_file = File.new outfile, 'w'
  begin
    File.open(infile, 'r') do |file|
      file.each_line{|line|
        out_file.puts Iconv.conv('UTF-8', CharGuess::guess(line),line) unless line.nil?
      }
  end
  rescue Exception => e
    puts e
  ensure
    out_file.close
  end
end


You should have iconv already. CharGuess you’ll need to install yourself, most likely. Grab the clib here, and the ruby binding here.

Assuming you’ve extracted the clib to /home/user/libcharguess/ (and done the ./configure/make/sudo make install bit), install the ruby charguess bindings with

ruby extconf.rb --with-charguess-include=/home/user/libcharguess/cpp/
make
make install


Situation: class with dynamic, on the fly class method definitions of the form

What this does is defines some class methods role1_email_addresses, role2_email_addresses, etc on the fly.

Works perfectly, until the first element returned in users is actually an empty email.

This is an example of writing clever code for succinctness (which is rampant in ruby circles). The problem is this code has bugs, and in order to fix it you have to rewrite it or add extra checks and workarounds. Which means the code is no longer succinct nor clever.

In my recent experience, that’s all that overly-clever code gets you. You just end up making extra work for yourself (or the maintainer) down the line.

C:\Documents and Settings\jonw\My Documents\Installs\InstantRails-1.3a-win.zip
[0] Archive type: ZIP
–> InstantRails/ruby/bin/ruby.exe
[DETECTION] Is the Trojan horse TR/Spy.Ruby.Ka.2.C
–> InstantRails/ruby/bin/rubyw.exe
[DETECTION] Is the Trojan horse TR/Spy.Ruby.Ka.2.A
[INFO] The file was moved to ’451431cd.qua’!

I don’t know what’s up with that.

Yesterday, all the developers from work went to Snakes and Rubies, in Chicago. It was rather fun. This was a seminar/conference for Ruby on Rails and the Django framework for python.

Adrian Holovaty is one of the three developers who created the Django framework for Python; initially for use on the Lawrence, KS local events and information site.

David Heinemeier Hansson is the developer who initially began development on the Rails framework for Ruby two years ago, though at this point there are other collaborators, I believe. Rails is used in projects linked off 37 Signals.



Both presentations were neat, though I will say that I was initially disheartened when David’s Rails presentation consisted almost entirely of code screenshots. That, at least at first, steered me away and gave me a far better feeling for Adrian and his Django presentation. It took a little while to get over that and listen without rancor.

Both technologies are really sweet. For those unaware, they both provide a method to use their respective languages, Ruby and Python, to quickly rock out websites and web applications. What I took away from the event is that they’re both well-thought and extendable technologies, but Django is aimed to be more of a general purpose site builder for sites with dynamic content and interrelations between that content, whereas Rails is aimed more specifically at the web application construction aspect of things.

I don’t know if this is a fair characterization or not, but it’s what I took away.

The difference in presentational style makes things difficult when trying to choose one over the other — Adrian’s Django presentation was very engaging and entertaining. It was very much a proselytizing thrust. David’s Rails presentation was just… code. His assumption of the format was that people already were familiar and knew about the framework, and the presentation aspect of the seminar was just fluff or feature displays as a prelude to the QA portion. It was harder to learn what I, as a developer, could really do with the framework.

The entire trip home was essentially spent discussing the pros and cons of both as far as we could determine. We’ll have to just try them both it seems. Very few of our developers know Python and none know Ruby at work — it will be interesting.

One other thing to mention, there was a lot of PHP bashing going on. Very much in the same religious wars vein as Mac v. PC or Linux v. BSD. Some of it was valid, but most of it was cheap shots. I just want to mention that what a lot of the PHP bashers fail to realize is it’s the programmers who write bad PHP code. If you treat PHP as if it were C++ or some other functional language, the coding requirements to write good code are the same. For reference, I have never heard C bashing (aside from bemoaning the use of pointers) from anyone, even though it has a lot of the same issues as PHP. So I say the put-downs were a little off the mark — it is equally possible to write bad code in Ruby and Python as it is in any other language.

Having said that… I had an epiphany prompted by one of David’s comments — he characterized PHP as the Devil, always prompting you to do bad things. My ephiphany was: This is true, because PHP is basically lazy man’s C++.

Examples:

• There is no strong typing, you can do all the nasty C++ stuff you got D’s for in college, and furthermore, there’s no compilation. So there’s no incentive to actually test your code or think about validation or error checking. At least with C you get errors or odd behavior when you try to use an int as a char, and if you have an eventual parse error, you know right off the bat.
• In PHP the language construction is half-assed about being half-assed. You kind of have C-style objects, but they’re not strict so if you really want you can refer to private data (which only became truly private in PHP5.)

You’re set up in a situation where you want to write bad code in the form of shortcuts, inlining what should be functions, and straight declaring what should be objects. It just sets you up, as a developer, to be a poor coder.

The thing I think people really miss is that you can ignore those promptings and write the good code anyway.

In any event, two of the valid criticisms brought up, namely verbosity and length of applications, are issues I’d like to get rid of. PHP, like C++ and C, almost requires that your code be extensive and long. For that reason alone, I’m willing to look at another language solution.