warning: default `to_a’ will be obsolete

ruby

Apparently Object.to_a will eventually be obsolete (not sure when).  I was using it in the following context:

def foo(args)
  args.to_a.join(',')
end

According to this very old ruby-lang thread, this [*args] is a suitable alternative:

def foo(args)
  [*args].join(',')
end
No Comments »

Learning git

development

What?…you’re not using git yet? Everybody’s doing it.  It’s all the rage (at least for Rubyists)!

I finally blocked out everything else for a few hours yesterday afternoon to learn git.  A couple of observations coming from SVN:

  • The use of SHA1 hashes to identify revisions will take some time to get used to, but it appeals greatly to my inner geek.
  • No central repository (every clone is the full repository) makes me feel safer about my data somehow.
  • If you want a central repository like svn, use “git push <repo-url>”

There are lots of resources and tutorials out there, but I found the SVN Crash Course coupled with git’s own help pages “git <command> –help” to be all I needed.

No Comments »

Ramp up your testing for Safari/Webkit

development

Do you test in Safari with the same priority as other browsers? If not, you might should start making it a part of your routine. According to an article on Rob Pegoraro’s Faster Forward blog, Google’s new mobile OS, Android, contains a browser “built on the same open-source WebKit software as the Safari browser in Mac OS X and the iPhone.”

If Google can accomplish what they hope to with Android, namely, to be the mobile operating system, then developers will have yet another target browser to test for. I’m not complaining, though, Safari/Webkit is a great browser. And, as long as it maintains good adherence to web standards the additional testing only serves to better our web applications.

1 Comment »

New development blog

misc

I’ve set up shop here with a new blog to focus on software development. I’ll be porting some of my related posts from my personal blog over the next few days/weeks.

No Comments »

ActiveYahoo: A Ruby API for Yahoo! Web Services

ruby

Do you Yahoo? I do, and was recently a little disappointed in the Ruby offerings for the Yahoo Web Services API. So, a little coding and we have ActiveYahoo:

require 'active_yahoo'
y = ActiveYahoo::WebSearch.new(‘YOUR_APP_ID’, ‘ruby’, { :results => 2 })
y.result.total_results_returned  # => 2
y.result.records[0].title  # => "Ruby-lang.org"
y.result.records.map { |r| r.url }
#  =>  ["http://www.ruby-lang.org/en", "http://en.wikipedia.org/wiki/Ruby_programming_language"]

A primary objective of ActiveYahoo is to encapsulate Yahoo‘s responses into their own objects. For example, an instance of the WebSearch class will return a WebSearchResult object. Special care is also given to convert response fields into appropriate Ruby data types.

So far, the following Search services have been implemented: Web, News, Images, Audio, and Video. More will follow soon. The essentials are on Rubyforge here:

View the ActiveYahoo project page
View the documentation

No Comments »

Monotony vs. Usability Luster

development

I think there is an interesting dynamic that occurs when a developer is freed up from the monotony of the development process. Specifically, there is a direct consequence on the usability of a product when a developer’s progress in slowed by monotonous tasks.

As a developer, I’d love to claim that my initial design intentions (sketches/wireframes, task flow) are spot-on every time. Ha! Let’s be realistic: creating a good user experience is hard to do.

It is often the case that the product is near a finished state before some usability issues are encountered. In other words, the product may be feature-complete, and deemed releasable, but it’s that extra effort towards usability that can really make a product shine.

What can we do as developers to make sure our end product has that finishing touch? Or, more specifically, what blockers exist to keep us from achieving this goal?

I’d suggest monotony is a key blocker:

Monotony vs Usability Luster

Let’s define our two forces at play:

  • Monotony - any repetitive, tedious process, task, or routine that drags down creativity during the development process
  • Usability Luster - the extra, finishing touches on a product that exponentially elevate the product’s usability

For a developer, more monotony means less time and space (grey matter space) to cope with finishing touches. If, as a developer, I feel like a cubicle code monkey all day, every day, then that is affecting my ability to push out a quality user experience.

How can we combat monotony?

  • Use tools that reduce monotony and increase productivity
    • Rails comes to mind
    • A good IDE
  • Use good programming technique
    • DRY (Don’t Repeat Yourself)
    • Design Patterns (where appropriate)
    • Test (reduce your stress level by testing)
  • Get a cheerleader
    • Find that guy/gal who encourages you through the monotony

What do you do to get through the monotony? What other techniques do you use to ensure that little something extra for the user experience?

1 Comment »
WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in