RSS
 

Archive for the ‘Ruby Notes’ Category

OOMA call log statistics with Ruby (Part 2)

23 Mar

In my last article (part 1) I described the OOMA Logger application that I had running on my development machine, and I promised to make it available by deploying it to Heroku which is a cool service for deploying web based Ruby apps.  The application is now live at http://oomalogger.heroku.com (nice name right!)

First off, I ran in to a couple of unforeseen problems like the fact that heroku apps are for all intents and purposes read-only (which meant for example, that I had to figure out the Nokogiri parsing problem and not use the file-system work-around hack that I had come up with).

Read the rest of this entry »

 

OOMA call log statistics with Ruby – Tech Notes

22 Mar

One of the initial problems that come up with Ruby web application development is where do you host it? A lot of the general web-hosting sources don’t support Ruby unless you are on dedicated servers and roll-your-own environment. Heroku is an amazing service for Ruby developers that makes it drop-dead simple to deploy Heroku apps.

The “oomalogger” application turned out to be both more and less complex than I originally thought. Less complex, because I didn’t need a database after all and more complex because of unforeseen things like Heroku applications being essentially read-only and my needing to work around those issues. T here is a tmp and log directory for temporary and log files but in general and for scalability the Heroku app should not be trying to write files to the file system. Read only files are okay as long as the total app size including the static files is less than 50mb and preferably less than 20mb.

The work-around for the Nokogiri file parsing problem – the Mechanize returned page could not be parsed by Nokogiri was as follows: if the Mechanize doument that was returned is in object ‘page’ then you have to parse the page object with the ‘body’ method (i.e page.body) instead of attempting to parse the entire object ‘page’.

Deploying to Heroku essentially followed these steps:

The config.ru file must contain a require statement for sinatra; the name of the application to be run and the statement to actually run the application for oomalogger this looks like:

1. Create a config.ru file

This is the Rack configuration file, which is actually just another Ruby script.

1 require 'sinatra'
2 require 'oomalogger'
3 run Sinatra.application

This tells Rack to include the Sinatra and the  oomalogger, then run the Sinatra application.

2. Initialize an empty Git repository in the snip folder

1 $ cd workspace\rubyprograms\oomalogger
2 --> $ git init
3 Initialized empty Git repository in .git/
4 --> $ git add .
5 --> $ git commit -m 'initial import'
6 Created initial commit 5581d23: initial import
7 2 files changed, 52 insertions(+), 0 deletions(-)
8 create mode 100644 config.ru
9 create mode 100644 snip.rb

This just creates and initializes an empty git repository on your computer.

4. Create the Heroku application

1 --> $ heroku create oomalogger
2 Created http://oomalogger.heroku.com/ | git@heroku.com:oomalogger.git
3 Git remote heroku added

5. Push your code to Heroku

01 --> $ git push heroku master
02 Counting objects: 4, done.
03 Compressing objects: 100% (4/4), done.
04 Writing objects: 100% (4/4), 999 bytes, done.
05 Total 4 (delta 0), reused 0 (delta 0)
06 -----> Heroku receiving push
07 -----> Rack app detected
08 Compiled slug size is 1.9M
09 -----> Launching....... done
10 App deployed to Heroku
11 To git@heroku.com:oomalogger.git
12 * [new branch]      master -> master

Notice that this pushes your code and loads your application into deployment.

You can now go to your application on Heroku and you should be able to see it.

 

OOMA call log statistics with Ruby (Part 1)

18 Mar
ooma call log service snapshot image

Output from OOMA call log service

So far, I have been using OOMA (premier) for a little more than three months which means, based on my prior AT&T bills that it has just about paid for itself. It also means that every month from now on without a phone bill is money in my pocket free-is-good.

I’ve been busy over the last few days on a small Ruby programming project. I’m somewhat new to Ruby, but not to programming. I was looking for a project to help me bring some of the Ruby concepts together – while there are some great Ruby tutorials and books available you can’t really learn to program in a language until you actually start to write code. Read the rest of this entry »

 

Arghh Vista!

08 Mar

I just spent three hours last night debugging a Ruby program only to figure out that the problem is a bug in Vista.  I was trying to pass a command line argument to a program that just wasn’t working. I assumed that I was trying to read the arguments incorrectly but it turned out that Vista just wasn’t passing the arguments to the program.

Failing Vista Ruby File Association:  testruby.rb value1 value2 This fails as the command line arguments value1 and value2 are never passed to the program testruby.rb (or just testruby).

Working Vista File Association: ruby testruby.rb value1 value2 Calling the ruby onterpreter directly worked showing that it was the Vista File Association manager causing the problem.

Known problem – not so quick a fix A quick Google search shows that this is a known Vista problem with pretty much everything that uses file associations and arguments. The fix, after some trial and error, was to change the registry keys. The fixes found via Google only worked after I started regedit and then did a search for ‘ruby.exe’ – the location of ‘ruby.exe’ in the HKEY_CLASSES_ROOT\Applications\ruby\ entry may be new with Ruby 1.9.1.
HKEY_CLASSES_ROOT\Applications\ruby\shell\open\command\default contains the value “C:\Ruby19\bin\ruby.exe” “%1″change this to “C:\Ruby19\bin\ruby.exe” “%1″ %*
After about another hour of trial and error, the above change is the only one that seems to work – other recommendations to change HKEY_CLASSES_ROOT\rbfile\shell\edit\command\default and HKEY_CLASSES_ROOT\rbfile\shell\open\command\default did not work (with Ruby 1.9.1).

 

Ruby: Installing GIT and Heroku (Part 2)

03 Feb


Heroku is an interesting hosting platform and service for Ruby applications. Heroku also has a command line client (a Ruby Gem) that allows the developer to create, save, deploy and rename applications to the Heroku site. Once the application is deployed it is available over the web for anyone to use or test. Heroku claims nearly 50,000 apps have been deployed thus far. Heroku is a great way to deploy an application that you are working on for web testing at a low (or even free) cost.

You have to install and configure the heroku command in your local environment in order to make use of and manage Heroku applications.

  • Install the “heroku” gem. You will be asked to enter your Heroku credentials the first time you run a command: gem install heroku
  • Add your public key immediately after installing the Heroku gem:
heroku keys:add
Enter your Heroku credentials.
Email: winston.lawrence@gmail.com
Password:
Uploading ssh public key /Users/winston/.ssh/id_rsa.pub
 

Ruby: Installing GIT and Heroku (Part 1)

01 Feb

GIT is a widely used version control system in the Ruby community. Version Control Systems in general or Source Code Management (SCM) systems like GIT are pretty much standard these days for any software development. Subversion has been widely used in the past especially for Java development but the Ruby, particularly Rails, community has been moving heavily towards GIT.  I needed the GIT client at least to be installed, as a base for some other projects (more on that later).

  • Downloaded: http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/ and installed Mingw.
  • Downloaded the  devkit (ruby addons) from rubyinstaller.org /addons.html  this version displayed a cygwin (the unix environment emulator under windows) heap problem, the solution for which was to use a rebased msys DLL (or if you have the Microsoft Visual C++ compiler then you could download the source code version and compile which would eliminate the problem. If you don’t have the VC commpiler (like me) then download the  msys-rebased.zip from http://www.madwizard.org/electronics/articles/winavrvistaand overwrite the existing msys-1.0.dll.
  • Generate the public and private key pairs: c:\Applications\Development\GIT\bin>ssh-keygen -t rsa -C “winstonlawrence@gmail.com”
Generating public/private rsa key pair.

Enter file in which to save the key (//.ssh/id_rsa): \users\winston\.ssh\id_rsa

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in \users\winston\.ssh\id_rsa.

Your public key has been saved in \users\winston\.ssh\id_rsa.pub.

The key fingerprint is:

76:6e:69:f3:1c:dd:b0:ef:1c:95:bd:05:43:2f:71:94 winston.lawrence@gmail.com

 

Installing the cheat GEM

19 Jan

I guess that I must have installed the cheat GEM on Ruby 1.8.6, but it was so long ago that I was thinking that it was part of the Ruby base – part of the charm in using Ruby I guess. Anyway it’s a quick install right just go to the command prompt : C:\Users\winston>gem install cheat the console indicated that all went well [Successfully installed cheat-1.2.1; 1 gem installed; Installing ri documentation for cheat-1.2.1...; Installing RDoc documentation for cheat-1.2.1...] but on testing:C:\Users\winston>cheat cheat

c:/ruby19/lib/ruby/gems/1.9.1/gems/cheat-1.2.1/lib/cheat.rb:150:in`cache_dir’
uninitialized constant Cheat::PLATFORM (NameError) from c:/ruby19/lib/ruby/gems/1.9.1/gems/cheat-1.2.1/lib/cheat.rb:16:in `sheets’
from c:/ruby19/lib/ruby/gems/1.9.1/gems/cheat-1.2.1/bin/cheat:4:in`<top  (required)>’
from c:/Ruby19/bin/cheat:19:in`load’
from c:/Ruby19/bin/cheat:19:in`<main>’

Not cool, cheat.rb is failing! Read the rest of this entry »

 

Installing Ruby 1.9.1

16 Jan

I decided to install Ruby 1.9.1 on Vista – since I may as well work with the latest version but I did leave Ruby 1.8.6 installed as well in case there were some incompatibility issues.

I ran Ruby 1.9.1 for a day or two with no problems until I installed the mysql gem (gem install mysql) and immediately ran into failing database operations. After looking around the net the best fix to the problem that I found was as follows:

Solution: Copied libmysql.dll from this address: http://instantrails.rubyforge.org/svn/trunk/InstantRails-win/InstantRails/mysql/bin/ to c:\ruby19\bin. The fix works with mysql version: 5.1.30, which is what I have installed and it replaces the dll that was installed by the mysql gem. So far everything looks like it is working properly.