Archive | Ruby

Notes from Feb 25th Web Dev Meeting: Brian Cardarella on Ember.js

The Portsmouth Web Dev meetup is hosted at Alpha Loft in Portsmouth. This month there were two meetings: Ember on the 25th and Lightning talks on the 26th. On the 25th was the first, with Brian Cardarella of dockyard.com giving the main presentation on Ember.js.

Brian started with a bit of a history lesson. Ember spun off of SproutCore from Strobe. SproutCore 1.0 suffered from the slow (at the time) JavaScript runtimes and overly-complex UI widgets, resulting in a poor user experience. The 2.0 branch was started and Yehuda Katz (core contributor, Rails, jQuery and more) and Carl ??? and pushed off UI elements to focus on the core and on speed.

The run loop is the core event loop engine of Ember, and code in Ember can enqueue new items onto the loop, which continues to loop as long as there are items to be processed. There is great documentation in the Ember Guides, and a good video overview. Brian suggests that the Ember Starter Kit is just that, a good way to get started, but likely not appropriately robust for a professional application.

Enough background, we jumped into http://ember.jsbin.com/ and Brian commenced live coding in Ember to demonstrate how the Ember application essentially hooks into the body tag of the DOM and can read and write elements from there. He showed how actions could be triggered by observed changes, that setters and getters were required for property manipulation.

Ember has its own form of MVC (doesn’t everything?) where Models are business rules containers, and Controllers are contexts in which your interactions with models occurs, essentially acting as proxies. Views are nearly becoming deprecated as their functionality is being replaced with HTML5 Web Components (there’s currently a polyfill for these called polymer.) Routes are similar to Rails with nesting. URLs can be considered a state manager for an Ember app, so two users see the same thing at the same URL, unlike some other JS frameworks. There is an Ember Inspector for Chrome and FireFox that allows you to dive deep into the View Tree, Routes and Data for debugging. Excellent peer support is available on IRC at emberjs and emberjs-dev.

Brian and Dockyard have built Ember-AppKit-Rails as a gem to create a shared directory for an Ember app and its Rails backend. Note this is Very Beta, Somewhat Experimental and may be abandoned. You have been warned. Brian explained there are not yet any Best Practices worked out, so different attempts have been tried. Side-by-side projects where the two are separate may turn out to be a better design; Brian is looking at Ember AppKit [Update: Deprecated, but URL updated for reference]. Ember is designed to deal with different backends, depending on their API syntax. The one he was using was ActiveModelAdaptor, build to work with Rails.

An excellent question on “Where do you do validation?” And the answer: pretty much everywhere. Brian is the author of ClientSideValidations and has some experience with this. He tried something similar with Ember but points out that the context of the front end and backends can be so different that the validations aren’t necessarily the same.

Brian then proceeded to do a demonstration of an under-development project by Dockyard and even in its early stages, it appeared pretty promising.

Brian recommended downloading Ember, reading through the Guides, and taking some time to learn the components. Promises are a key element to the Ember framework and are worth reviewing; ECMAScript 6 will have promises built in. Handlebars, the templating language, is expected to be replaced by HTMLBars in the next major revision. Best practices and calling conventions (especially error/exception/validation handling) are still up in the air; check out JSONAPI.org for some work on this front.

So, we had an action-packed, fact-filled, acronym-filled session with a lot of good material and an excellent overview of the state of Ember and its promising future. Thanks for Brian for speaking and for Josh Cyr, Alpha Loft proprietor, for hosting!

rbenv on Fedora 19: for want of a nail,…

… a kingdom was lost.

Fortunately, I don’t have a kingdom at stake. My tale is more like the House That Jack Built. I had to spend a little time building the tools to build the code to build the language upon which I build solutions for clients. And the path was strewn with gotchas, but I persevered. Since I’ll likely need to do it again some day, I’ll record it here in hopes I can retrace my patch, er, path.

I’ve installed Fedora 19 on my main development laptop, replacing an older Mint 12 install that had gotten too old to maintain easily. I’ve spent some time updating and configuring the machine in my spare time. With FireFox already installed, Chromium was an early addition. Thanks to syncing, these browsers retain the history and passwords of the sites I spent all day on. I moved over my ssh keys and configurations and vim configurations and installed git and the basic development setup is ready to go: most of my coding occurs on remote systems. Next came Apache and PHP in order to develop locally. Finally, I started on Ruby and Rails. Here, I took a tangent from past installs and installed rbenv rather than RVM, the Ruby Versions Manager. I have seen problems with RVM and the 2.0 version is coming along slowly. In the meantime, Bundler has come along and solved a number of problems with gems, gemsets and disk clutter, but in a different and incompatible way with RVM. I thought that this was a good opportunity to inform myself of a new tool, should I run across it on a new gig. Also, I had seen a Drew Neil videocast in his VimCasts series recently where he showed some very useful tools, but rbenv was a pre-requisite. Due to the way RVM works, rbenv can’t be installed side-by-side, so I had to remove RVM. No time like the present!

However, there’s a catch. Isn’t there always? Fedora 19 uses a version of OpenSSL which is configured differently than what used to be typical. I am no crypto expert, but I understand they disallowed some form of elliptical curve (EC) encryption. Ruby, as part of its build process, tests for that specific functionality, so builds will break on Fedora 19 (and recent Red Hat, too). There is a fix in the pipeline: https://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/41808, which changes the behavior from requiring this specific form of encryption, which wasn’t really required, just a poorly chosen hard-coded test) and instead tests to confirm that there are some algorithms for encryption by iterating through them. So. Now, I knew there was a fix, I just had to figure out how to wedge it into my system. Thank goodness for internet search engines! Here http://philippe.bourgau.net/how-to-install-a-patched-ruby-interpreter-wit/ was a similar enough situation that I could interpret the process for my system, with different version numbers, of course, and a few tweaks. After a few false starts, I had my own custom patched versions of Ruby 2.0 and 1.9 installed a ready to go.

It may not be clear why I didn’t just install the version of Ruby that comes with Fedora 19. At the moment, that version is the same (p247) as the current version, but as a developer, I don’t want to have to count on the distribution to keep their versions up to date in order to have the most recent version on my systems. Since I’ll be deploying systems into production, and therefore exposed to potential attack from the internet, I need to have the ability to build from the latest source code and to apply patches as needed. This provides the best possible security to my clients for this app. I also need to support older versions, so having worked out the recipe for 2.0, I was able to backport the same changes into Ruby 1.9.3 and install that on the system as well. At the moment, I don’t have any need for Ruby 1.8.7, but now that I’ve worked out the build routine, I’m confident I could deploy that if needed.

NH Ruby September 2011: Backbone.js Jason Morrison

Twelve folks attended the September meeting of the New Hampshire Ruby Rails Group. Due to some logistical issues, we moved the meeting from NH-ICC to AlphaLoft, thanks to AlphaLoft member Nick Plante. Jason Morrison of thoughtbot was the featured speaker, talking about backbone.js.

Organizer Brian Turnbull got the meeting started with brief introductions.

Clients want the improved client-side experience of rich-client apps within the browser.

But which framework? Different patterns: MVC2 is what we’re used to seeing in Ruby/Rails. MVC and MVVM (Model-View-View-Model or Presenter).

Choice fatigue (http://www.nytimes.com/2011/08/21/magazine/do-you-suffer-from-decision-fatigue.html) : there seem to be more JavaScript frameworks than JS developers.

  • Capuccino – PowerPoint in the browsers, 270North
  • SproutCore (1,x,m 2.z) ricu Ui widget framework,.0 from the ground up rewrite, less widgets
  • Knockout.js: useds the HTML5 Data- elements
  • Batman.js – from Shopify, ActiveMerchant, using Node.js server-side component
  • JavaScriptMVC – mature, uses jQuery, filterable grids, lots of power
  • Spine.js – CoffeeScript, asynchronous front end, does full validation on client-side
  • Backbone.js – tonight’s featured framework, well-documented (in Doc-O)
  • Angular, Coherent, PureMVC-js, AFrameJS, TrimPath Junction,

Moving parts:

  • History
  • Router
  • View
  • Model
  • Collection
  • Sync
  • Underscore
  • $

Jason wowed the crowd with an excellent demo of an app under development and spoke eloquently of the power, and the dangers, of deploying MVC (or MV-something-else) into the client. His slides contained a great many good references. My laptop gave out at this point, so I didn’t take additional notes, but you can find his slides at http://jayunit.net/backbone-js-on-rails-talk and source for the slides at https://github.com/jasonm/backbone-js-on-rails-talk/blob/gh-pages/slides/index.md

One of the little things that got the crowd all excited was the line numbering on Jason’s Vim session: the current line was numbered 0, and line numbers incremented both up and down the screen. “Oh, that” Jason said. ‘set rnu’ is the command (see :help rnu within vim for details.)

Michael Tomer talked a little bit about his project, rocket.io, which is an interesting project trying to solve similar problems: “real-time” (no http lag) page updating, background sync between client and remote server. You can find his work at [updated link] https://github.com/actsasbuffoon/rocket-io

Thanks to Jason for an awesome presentation, to Nick Plante for hosting us at AlphaLoft, to Brian Turnbull for organizing the meeting, announcements and logistics, and to all the attendees for their participation.

NH Ruby meeting, 15 August 2011: Brian Turnbull, Rails 3

Brian Turnbull ran and presented to the August meeting of the New Hampshire Ruby Users Group meeting, held at the New Hampshire Innovation Commercialization Center. Over a dozen attendees turned out for the meeting, despite the inclement weather.

Brian presented an introduction to Rails 3 using a small application he had built for  work. He gave us an overview of the problem to be solved, skipping the irrelevant details, and explained how that fit into basic MVC concepts. We touched on the idea of design patterns. We examined or discussed many facets of Rails development, including rake tasks, migrations, fat models – thin controllers, using HAML for view templating, creating your own custom validators, deployment using Capistrano and more.

Brian mentioned several useful resources, such as Google, the Rails Guides, the API reference,  and more. He mentioned that he’d read Metaprogramming Ruby [Updated link] and thought that it changed his perspective on using Ruby.

As always, there was time for folks to get their questions answered. There were questions on stack dumps in rake, unobtrusive JavaScript, new features of Rails 3, Capistrano deploys to non-git-clients, and more.

Thanks to Brian for a information-packed presentation, and to all for attending and participating. Brian is always looking for ideas for future meetings and volunteer help in organizing.

 

Notes from NH Ruby/Rails, 21-Feb-2011

Eight attendees made it to the February meeting of the New Hampshire Ruby Rails group at the New Hampshire Innovation Commercialization Center. A round of introductions included the usual suspects and several new people with interesting backgrounds and interests.

Brian Turnbull talked about Ruby debugging. He had a sample he created on Github Ruby comes with it’s own debugging library, but you can add a good one with a gem: ruby-debug.
Commands:
list – lists the code currently load
next – steps through the code listed, but skips over subroutines.
step – steps into the code
where – dumps the stack
finish – finishes the current subroutine call
display – dumps a value
(commonly use display value.inspect to make a cleaner display)
pp – pretty print, evaluates any Ruby code you want
edit – launches the EDITOR variable in our shell
catch – catch exceptions
cont – continue
break – set a breakpoint

,,, and so forth. Use the help, it is your friend.

The second example is far more complex, with a Sinatra app using OmniAuth and an LDAP provider. Following the supplied documentation, the app crashes on startup. (That’s what you get for reading the docs!) Debug and another tool – rbtrace to the rescue! Excellent demo of the problem and how the tools can debug them.

Notes from NH Ruby/Rails, 17-Jan-2011: Brian Turnbull, OmniAuth, Nick Plante, Mirah

Seven members attended the New Hampshire Ruby / Rails group meeting held on 17-January-2011 at the New Hampshire Innovation Commercialization Center (NH-ICC). We had two presentations: Brian Turnbull talked about OmniAuth and Nick Plante showed a project he’s doing with Mirah on the Android platform.
Brian Turnbull is an engineer working for ARRIS and injects Ruby into his build tools whenever he gets the chance. A recent project required authentication against multiple providers and he did some research on OmniAuth. Brian presented a slideshow explaining the basic concepts of authentication and how they’re implemented in OmniAuth. Apparently, OmniAuth was the authentication method of choice during the most recent RailsRumble, used by most of the contestants. Brian outlined the process needed for working with an existing provider and demonstrated it with clear and simple code. He followed that up by showing how to build your own custom provider and authentication strategy. Brian’s sample code can be found on his github account.
Nick Plante has been working on an Android rich client app as part of a web-based social application that’s soon to launch. Nick told us that working on Java for Android has reinforced his love of Ruby. There’s not yet a good port of Ruby to the Android platform, but he has been impressed with the Mirah language, a hybrid solution that compiles to bytecode and runs natively on the JVM. He has developed a Ruby generator called protoform to construct the skeletons of a Mirah app. He gave us a tour of the components and built a simple “Hello, World” app, deployed and ran it on his Android VM.
Thanks to Brian for organizing the meeting and for the OmniAuth presentation, to Nick for talking about his Mirah project and to the NH-ICC for providing the fine facilities.

Notes from CentraLUG, 6-Dec-2010: David Berube, MySQL Operations

Six people attended the December 2010 meeting of the Central New Hampshire Linux Group, held at the NHTI‘s Library from 7 to 9 PM. David Berube was the featured speaker, talking about his experience with large scale high-performance MySQL applications.

David is an independent software developer and consultant. One of his larger projects over the past couple of years has been an application for scheduling actors for auditions. This involves agents and projects, auditions, roles, videos and a number of other entities in a complex and fast-moving application. He’s used Ruby on Rails, PHP, MySQL, a NOSQL database, Amazon S3, A rack of Mac Minis, BSD, Linux, and a number of other elements. He had some insightful things to say about the development process, managing a client project, handling difficult requirements, scaling up million-row databases for subsecond response times and more. It was a meeting well worth attending.

There were a lot of useful tools and reference sites mentioned, and I was only able to take note of a few: Useful Ruby add-ons: New Relic, Query Reviewer, Percona Operations Day, Cacti for data aggregation. An In-depth discussion of NoSQL (“Not Only SQL”) Databases: what are they, what are they good for, what are the liabilities? A good discussion of the trade-offs of using NoSQL, reference to the NHRuby presentation on Redis a few months ago, and more.

Thanks to David for an informative presentation, to the attendees for a dynamic interactive session, and to the NHTI Library for the facilities. Future meetings at the Concord location have been suspended, we encourage our regulars to attend the Manchester ManchLUG meetings. If you haven’t already, consider subscribing to the announcement list so you’ll know when there’s an upcoming meeting. (Subscribers to the discussion list will automatically receive the announcements, too.)

Notes from Ruby SIG, 16-Aug-2010

The New Hampshire Ruby/Rails group met as usual on the 3rd Monday of the month. We met at the New Hampshire Innovation Commercialization Center, a new space near the Pease airfield. Mark Galvin, NHICC’s Managing Director, was kind enough to offer the space for our meeting and tell us about the ICC. Eleven members attended the meeting.

As we often do, we started with a round of introductions. It’s always interesting to find out who’s there and what they’re up to. I mentioned the GNHLUG calendar and Nick plugged the upcoming Ruby Rampage. Near the end of the meeting, we plugged the NorthEast RailsCamp, coming up on it’s third meeting, this one in Stowe, VT. 5 alums from previous camps were there, and all loved it. There may still be a ticket or two left, even though the site says zero – you’d better hurry!

We were lucky enough to have two presentations tonight.

Brian Turnbull presented “Interfacing Ruby with C.” He explained he needed to do some automation with a “black box” his company was using, and their documentation consisted of a C API and a DLL. Rather than developing an entire application in C, he used Ruby to interface to the C API and then could develop an easy-to-modify Ruby app. That turned out to be a good idea, as the final product he delivered turned out to be very different from the initial request, and having the ability to rapidly re-develop in Ruby was a success. To show us how to use C to access Ruby and vice-versa, Brian used a simple example of a “leaky bucket stack,” a fixed-length stack that would lose the oldest item as the stack was pushed. It was a great example in that it had enough complex behavior to be useful, while simple enough to explain and translate into C without too much effort. First, we reviewed the pure Ruby implementation. Brian proceeded to build up the equivalent code in C, calling Ruby array functionality and data types where appropriate. He then showed how to configure the C extension from from Ruby, build, compile, debug and run from the ruby command line.

See the example code and slides (I’ll update the URL when available). Also http://github.com/bturnbull/padpaws for his more advanced C example.

Brian Cardarella, @bcardarella, http://bcardarella.com, presented his gem, client-side validation, which he developed while working on the “Raise Your Vote” site for the Democratic National Committee. The Raise Your Vote site is intended to assist in voter registration by collecting data online and generating matching PDFs of the voter application. Naturally, 50 states have fifty different forms, with different requirements. He wanted to avoid duplicating the server-side validations with hand-maintained client side code, as the regular changing of requirements and the difficulty of keeping business rules in synch across the two languages would doom the project. He wrote client-cisde_validations to use the declarative validations within the entity models to generate the equivalent Javascript code. Client-side_validations has remarkable depth and breadth, handling nearly all of the common and exceptional types of valiation (Brian notes the few difficult cases in his slides). You can find the code on GitHub (gem code, examples) and the slides here: client_side_validations.pdf

Thanks to Brian Cardarella for travelling all the way to Portsmouth and thanks to both Brians for their fine presentations. Thanks to Nick Plante and Brian Turnbull for organizing and promoting the meeting and the group. And thanks to Mark Galvin and the New Hampshire Innovation Commercialization Center for providing the fine facilities!

Notes from New Hampshire Ruby/Rails Group, 19-July-2010: Redis, Resque, Vanity, Mogotest, Nick Plante

The July meeting of the New Hampshire Ruby/Rails group was held as usual on the third Monday of the month at RMC Research in Portsmouth. Nick Plante was the featured speaker, talking about Redis, the NOSQL database, Resque and Vanity. Brian Turnbull ran the meeting and brought pizzas — thanks, Brian and Nick!

We started off with a round of introductions and speaking a little bit about who we are, what we do, why we’re there. There’s an interesting assortment of backgrounds: a few folks with deep Ruby experience, a number of people transitioning from other languages (Java was mentioned more than once) and some web design folks looking to get a little deeper into the workings. Brian mentioned that the Ruby Rampage was coming up fast – October 16th – and that seats went quickly once registration for the event was open. Keep an eye out for future announcements.

Nick Plante talked about Redis, Resque and Vanity. You can view the slides here: http://www.scribd.com/doc/34712184/A-Quick-Introduction-to-Redis-NH-rb. Redis (http://github.com/antirez/redis) is a NOSQL (“Not Only SQL”) database that has a simpler API (put/get/list keys) than the complex SQL needed for a relational database. It is a “key-value” store that stores flat values (and/or documents, arrays, lists, etc.) with a great deal of speed, high-performance, reliability and scalability. It is ideal as the primary means of access for data on a demanding web site, acting as a cache for underlying relational data or transient data. Nick talked about how he and his partner used Redis and the Resque
Ruby library (http://github.com/defunkt/resque) to manage a job queue where the front-end servers posted jobs, many background workers processed the jobs, and the front end could display progress or completion. Nick also talked about A/B testing with Vanity, another package which uses Redis as its backend datastore. Vanity lets you present two different interfaces (hence the A/B) and monitor statistics on how the users react to the differences (do green buttons get better conversion than orange?). Nick wrapped up by showing us some of the code used in Mogotest and how they managed backend tasks.

As a bonus, we got the briefest of tours of what Mogotest can do: it will spider a web site, gathering the content, show you validation issues with the code (HTML and CSS), compare how the web pages look in a number of different browsers (side-by-side or a slick overlay). This can be really handy to include as part of testing a web site. Mogotest has just entered into public beta, during which you can test your site for free. Check it out!

Thanks to Nick for a very interesting presentation! Thanks to Brian for coordinating the event and getting pizza! Thanks to RMC for the great facilities.

HowTo notes: installing REE, Passenger, Ruby on Rails on CentOS5

Recently, I installed Redmine, the Rails-based project tracker,  on an existing virtual private server, running CentOS 5 Linux and an assortment of LAMP applications and web sites using Apache, PHP and MySQL. I chose Ruby Enterprise Edition (REE), an optimized and high-performance version of Ruby, and Passenger, an Apache module to connect to Ruby. Here are the steps I followed, as a reference and in hopes it might help others:

  1. Log onto the box via ssh. As a good practice, I run as an unprivileged user, and use sudo only when superuser rights are needed. So, download the files and un-tar them and read the READMEs and run the processes as a regular user, switching to root via sudo only when the rights are needed.
  2. Download and install Ruby Enterprise Edition. Today, that’s:
    wget http://rubyforge.org/frs/download.php/68719/ruby-enterprise-1.8.7-2010.01.tar.gz

    but follow the instructions you’ll find at http://www.rubyenterpriseedition.com/download.html for the latest. Those instructions will have you un-tar the file and then run the installer.

  3. Install the tools needed to build Ruby Enterprise Edition. If you run the installer, it will prompt you for missing tools. In my case, I needed to:
    sudo yum install gcc-c++ make patch zlib-devel openssl-devel readline-devel
  4. If you’ll be using mysql, you’ll need the native code to build the matching gem. REE attempts to build gems for MySQL, SQLite and PostgreSQL, so choose your flavor and issue the appropriate command like:
    sudo yum install mysql-devel
    

    or postgresql-devel or sqlite-devel as appropriate.

  5. Follow the instructions supplied by the REE installer. They did a nice job on that. To install Passenger when I was done, some additional source code files were required:
    sudo yum install httpd-devel apr-devel
    sudo /opt/ruby-enterprise-1.8.7-2010.01/bin/passenger-install-apache2-module
  6. Once again, follow the prompts to add the proper load module and path commands to your web server configuration, add a configuration file for your site, and you’re ready to start installing your site’s code.

NOTE: It wasn’t the case with my particular host, but you may need to adjust your SELinux settings, if you’ve got SELinux enabled. See the post at http://www.catapult-creative.com/2009/02/04/installing-rails-on-centos-5/ and look for “SELinux” for some ideas.

Powered by WordPress. Designed by Woo Themes

This work by Ted Roche is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States.