End of the Week

• allyn
• June 27th, 2008
• 04:28:11 PM
• 1 Comment

There’s less than an hour of the work week left! Today I’ve been putting RSS feeds into our app - should be awesome. It’s been a bit of a pain, but only because we decided to do something a little more complex with it then just everything having a feed and that’s it.

Our app has a lot of methods. Most of those methods have names that are immediately apparent as to what they do. Some, however, do not. SO, as a teaser, I will provide the names of three methods. These are copied and pasted right out of the code, so if you touch your screen you can consider yourself the closest outsider yet to the beauty that is known only as: The Feisty Piranha Project.
Does the fact that I not only wrote these methods, but defended their names, make be a bad computer scientist? I don’t know. Whatever, they’re awesome.

def self.convert_to_noob_readable
def to_s_with_jazz

And my personal favorite..

def yes?

In addition, check out this screenshot I took of our app’s current stats. Yes, we need more testing code.

nevermind, the text looks terrible

• ering
• June 23rd, 2008
• 04:08:51 PM
• 3 Comments

So, I was thinking I was so awesome exporting a pdf from InDesign and importing into Photoshop to get a png with pixel-perfect accuracy (a one-pixel line actually shows up as a one-pixel line!), but of course turning off anti-aliasing makes the text chunky and sucky. Anyway……………

At the beginning of the week, I made a huge decision: I switched from designing the project in Illustrator to InDesign. O M G. I did some very in-depth research (read: 3 minute Google search) into what designers are using to layout pages, but didn’t really find any solid blog posts or information.

I was brought up as a print designer. Though my experience with InDesign is in no way limited, using it for the purpose of designing for web is a new and somewhat odd prospect. In my opinion, InDesign is first, a print design tool. Yes it has XML exports, yes it has exports for Dreamweaver. So, whatever, I don’t know where I’m going with this.

Here’s some things I like better in InDesign:

Pages. Websites have pages, not layers. InDesign has pages, not just layers.
Master pages. These are great for things like headers and footers, elements that appear on multiple pages in the same place.
Selecting text and object. When you select a text box and an object to resize, by default, only the text frame but not the text resizes. This is really useful for making, say, a line and a text frame 300 pixels wide without stretching out the text.
Align to baseline grid. Not that I love using it, since I like having control of every pixel, but if I wanted to limit my self to a 14px baseline, the option is there.
Export as multi-page pdf. I am almost positive you cannot export 10 Illustrator layers as a 10-page pdf.
Paragraph styles and character styles. If used properly and consistently, styles are very similar to css, which is super. Edit: Illustrator has this as well, but that doesn’t make how rad it is any less radical.

Things I like better in Illustrator:

Pixels. You can choose pixels as your units. The closest you get in InDesign is points. When it comes to font sizes, points and pixels are not exactly the same thing.
Hide Artboard. I haven’t found this feature in InDesign, probably because it is built for designing printed materials with actual edges. A piece of paper isn’t usually resizable by the user the way a browser is.
Command-H. This hides frame edges, points, etc. This way you can have something selected, move it around and preview how it looks without deselecting it. Does this exist in InDesign? I can’t find it.
In general Illustrator feels more delicate than InDesign. I don’t know if that makes any sense, but it’s a good thing to me.

I could go on, but I actually don’t really feel like it right now.

Depending on the style and size of the project, I would still consider using Photoshop or Illustrator in the future. But we’re talking the big-time here, so InDesign it is.

Getting friendly_id to work!

• robert
• June 23rd, 2008
• 02:16:28 PM
• 1 Comment

If you have read Allyn’s post from a week ago, you would have noticed him saying:

“For example, our current application has a page that executes several hundred queries when it loads. Obviously this is absolutely horrible and will have to be fixed before it’s released.”

Well, this was exactly what I set off to do this morning! When we initially wrote the page we used Eager Loading to cut down on our queries, though for some reason it was not working!

I looked into it for quite some time with Kevin, and we came to the conclusion that the Friendly ID plugin that was causing all the trouble. For some reason, it wasn’t passing our ActiveRecord’s :include parameters.

After poking around int he code for a bit, we came up with a solution:
Line 127 has a method called “find_using_friendly_id” in the SluggableClassMethods module. This method was originally not passing on the options parameter, since it wasn’t calling ActiveRecord’s default “find” method. Instead it was returning the Slug class’s polymorphic association, e.g., “Slug.sluggable.” I reworked the method to get the Sluggable class type and then called the find method, to which I passed the options parameter! So, with a little tweaking, this method now works with :includes, :conditions, and all the other fun ActiveRecord find parameters.

Here is the new find_using_friendly_id we worked up:

# Finds the record using only the friendly id. If it can't be found
# using the friendly id, then it returns false. If you pass in any
# argument other than an instance of String, then it also returns false.
def find_using_friendly_id(*args)
  return false unless args.first.kind_of?(String)
  slug = Slug.find_by_name_and_sluggable_type(args.first, self.to_s)
  begin
  # Get the class and pass our options
    object_class = Module.const_get(slug.sluggable_type)
    options = args.extract_options!
    return object_class.find(slug.sluggable_id, options)
  rescue # The class was bad, use the old slug way
    return false if !slug
    return false if !slug.sluggable
    slug.sluggable.send(:finder_slug=, slug)
    slug.sluggable
  end
end

Hope this helps someone out there!

Interns can Learn Ruby/Rails Quickly

• kevin
• June 20th, 2008
• 01:47:18 PM
• 1 Comment

This has been pretty awesome week for the ol’ FPP. As Bob already indicated, we’ve been busy implementing Erin #2’s design in with the code and markup. Basically, that means a lot of fiddling with HTML, CSS, and some javascript to make all the magic start happening.

Interestingly, neither Dusty or myself have written much of any code for the project. But, that’s not to say the project’s codebase isn’t sufficiently awesome.

One concern that Dusty and I had long before we started the internship: could interns with little-to-no experience with Ruby/Ruby on Rails learn quickly enough to be productive over the course of a 4 month project?

The overwhelmingly apparent answer is yes: Al and Bob have rapidly picked up Ruby/Ruby on Rails.

I attribute this quick adaption to the elegance and ease of use of Ruby and the Rails framework. As Al pointed out, often times, the language just makes a lot of sense; it behaves as one would intuitively expect.

Additionally, the availability of numerous Rails plugins helps speed up development immensely. Since they’re open source, plugins also double as great code examples (well, most of them anyway).

Another factor: about a month or so before the internship started, shortly after we made our hiring decisions, we sent Al and Bob a few books to help jump start their Ruby/Ruby on Rails knowledge.

Agile Web Development with Rails, 2nd Edition
The Ruby Programming Language

We also threw in a classic, just for good measure.

The Pragmatic Programmer: From Journeyman to Master

Lastly, one could argue that both Al and Bob may possibly be bright individuals… imagine that! ;p

Oh what a week!

• robert
• June 20th, 2008
• 09:45:25 AM
• No Comments

It’s been an exciting week for us on the Feisty Piranha Project! Monday concluded Phase One of our operation! Around 3:00, we demoed everything we completed to people from the scary outside world, which was an interesting way to start out the week. The demo was very successful; the project is really shaping up. We spent the rest of this week cleaning up the bits and pieces that didn’t quite make it into Phase One, and we’ll be start Phase Two this coming Monday.

Because of the successful conclusion of Phase One, all of us at BrightMix are going BOWLING TODAY! AND YOU ARE INVITED!

All are welcome to join us! As a little incentive, the people that come will get… Oh, why am I talking? You should just come and find out!

Anyways, as I was saying, we spent the rest of this week cleaning and polishing all the little bells and whistles of Phase One. (Special thanks to Ian Selby for helping me out with one of the polishings.)

Although a lot of the features are looking, feeling, and behaving better, it is a bit depressing when you spend a few hours addressing a single problem only to change 7 lines of code. But, fact of the matter is, at this point, small tweaks and changes can make a huge difference in the functionality and usability of the app.

All of these little tweaks have brought some of Ruby on Rail’s quirks out of the woodwork. The quirk that’s made me the angriest occurred I was tried to save an ActiveRecord model object to the database in YAML format. So, I converted the model object to a YAML string and stored it into a “string” column in the database. However, ruby wasn’t able to convert the YAML string back into the correct model object; it would, instead, create an object of type “YAML::Object” rather than the model object’s class.

As it turns out, this was happening because the model object’s class wasn’t loaded, so it could not create it properly. Drrr….

I drummed up a few solutions for this (like here, and a few other home-brewed solutions that I came up with), but they didn’t wind up working for me.

In the end, I decided that the best fix was to just approach the problem differently, which, in turn, actually cut out a bunch of the code’s complexity… and gave me a better overall solution.