Debugging Sinatra with racksh and pry
By Kamil Ciemniewski
October 17, 2012
One of the most beloved features of the Ruby on Rails framework is certainly its “console” facility. Ruby on Rails programmers often don’t need any debugger simply because they can view their application state in their app’s console. But what do we have at our disposal when using Sinatra?
The sheer beauty of Sinatra
Many of us who had an opportunity to play with Sinatra stand in awe of its pure simplicity. It gives you raw power as a programmer to structure a whole project however you like. It isn’t as opinionated as Ruby on Rails - in fact, there is even a framework called Padrino built upon Sinatra leveraging its unopinionated nature.
Sinatra’s way (®) was also employed in many other languages like JavaScript (through Node.js), Clojure and even in Haskell.
The elephant in the room
The above paragraph seems cool, doesn’t it? It provides a catchy and exciting marketing copy, just enough to make you a little bit curious about this whole Sinatra thing. And while Sinatra stands the test of practicality, otherwise it wouldn’t be hailed as widely as it is today, there are “gotchas” waiting just around the corner.
Almost every web application could be simplified just to this …
ruby sinatra
Piggybak Update: Line Item Rearchitecture
By Steph Skardal
October 17, 2012
Over the last couple of weeks, I’ve been involved in doing significant rearchitecture of Piggybak’s line items data model. Piggybak is an open-source mountable Ruby on Rails ecommerce solution created and maintained by End Point. A few months ago after observing a few complications with Piggybak’s order model and it’s interaction with various nested elements (product line items, shipments, payments, adjustments) and calculations, and after reviewing and discussing these complications with a couple of my expert coworkers, we decided to go in the direction of a uniform line item data model based on our success with this model for other ecommerce clients over the years (whoa, that was a long sentence!). Here, I’ll discuss some of the motiivations and an overview of the technical aspects of this rearchitecture.
Motivation
The biggest drivers of this change were a) to enable more simplified order total calculations based on uniform line items representing products, shipments, payments, etc. and b) to enable easier extensibility or hookability into the order architecture without requiring invasive overrides. For example, the code before for order totals may looked something like this: …
ecommerce piggybak ruby rails
Simple bash shell script for running batch MySQL jobs
By Barrett Griffith
October 16, 2012
The other day I needed to run a simple mysql job to backup and delete some database records on a live server. Being a live server, it is important to make sure you aren’t asking the database to take on jobs that could potentially lock it up. Better to run a batch job. Running a batch is simple. You can call it right from the mysql console with:
source [path_to]/[the_batch_script].sql
But what if there are millions of records that need deleting? Bash shell script to the rescue.
Here is the idea of the SQL job that needed to get run a few times:
START TRANSACTION;
/* Find what you want to delete and put a LIMIT on your batch size */
CREATE TEMPORARY TABLE records_to_delete_temp SELECT id from `records` where ..... limit 1000;
/* Creating backup table to archive spam orders */
CREATE TABLE IF NOT EXISTS `records_backup` LIKE `records`;
INSERT INTO `records_backup` SELECT * from `records` where id in (select id from `records_to_delete_temp`);
/* Delete Dependents - If your records have foreign key dependencies, delete them first */
DELETE FROM `dependent_1` where record_id in (select id from `records_to_delete_temp`);
DELETE FROM `dependent_2` where record_id in (select id …shell mysql
How to pick a Ruby gem
By Tim Case
October 15, 2012
RubyGems are one of the big benefits of developing in the Ruby environment as they can provide you with a powerful set of building blocks that were created by some great developers. Earlier in my Ruby career I used to think of RubyGems as a quick way to get some “free” code into my applications and I would spend a tremendous amount of time trying to see what kind of apps I could concoct by stacking gem on top of gem. In practice this turned out to be foolish because rather than gaining a stack of “free” code what I was instead doing was “paying” for each gem by having to learn how each of these gems worked and what kind of assumptions and gotchas they were bringing into my apps. I changed my ideas about gems and now I opt by default to avoid adding gems to my projects, but when I do decide that a piece of functionality might be better served through a gem, I make sure to put potential candidates through a rigorous vetting process.
When looking for a gem the question I keep in mind is, “Does adding this gem to my project benefit me more than just writing these features by hand?” I measure the gem up against some criteria and if the …
ruby rails
Don't Sleep on Rails 3 SQL Injection Vulnerabilities
By Tim Case
October 14, 2012
SQL injection is a problem that every web developer needs to be aware of when accepting parameters that will during the life of the request be converted into SQL statements. Rails historically has done what it can to mitigate this risk for the developer by providing vehicles for sanitizing parameter inputs at the points when they are being converted for use inside of a SQL statement, however with Rails 3 there are numerous ways to execute a SQL statement against the database and some of these methods are safer than others.
Consider two cases where valid Rails code is vulnerable to SQL injection:
#user inputed parameters
params[:query] = "'robert'; DROP TABLE students; ##"
#CASE 1 - find_by_sql
User.find_by_sql("SELECT * FROM users WHERE (name = '#{params[:query]}'") ##(BAD BAD BAD)
#generated SQL
SELECT `users`.* FROM `users` WHERE (email = 'Robert'); DROP TABLE STUDENTS; ##') ##(THIS STATEMENT WILL DROP TABLE STUDENTS)
The example above shows how find_by_sql can allow parameters submitted by a user to be directly entered into a SQL statement and how an attacker might use the vulnerability to wreak havoc. These types of find_by_sql …
ruby rails
Feature Isolation, an Overview
By Mike Farmer
October 10, 2012
Yesterday, Brian Buchalter blogged about a recent presentation I did for End Point Rails developers.
While the blog article did a great job of capturing some of the nitty gritty detail from the presentation, I’d like to just followup with a quick overview statement about Feature Isolation. I’ve also made my slides available for anyone who is interested.
Feature Isolation is what I’m calling a development strategy for adding new features to existing applications. In Rails, I’m utilizing cucumber, a tool for transforming use-case language into ruby code, to specify the requirements and then execute them outside of the Rails environment and away from the complexity of the rest of the application.
Using stubbing and a minimal mock of ActiveRecord (FastModel) I can then begin to design my feature from a more object oriented approach than is typical in Rails development. I can bring in any models, new or existing, that I will need and stub out the interface to the database. Likewise, I can design my classes and their public interface. Getting all my tests to pass from a high level without actually developing the behavior itself allows me to make design decisions …
ruby rails testing
Feature Isolation with Mike Farmer
By Brian Buchalter
October 9, 2012
My brilliant co-worker Mike Farmer gave a presentation today talking about a development strategy he calls “Feature Isolation.” It involves developing new features on the fringe of your application, isolating it from the complexity of existing code. This allows greater focus on ensuring that your feature is well designed from an object-oriented perspective and that you don’t build more than you need.
In order to truly isolate the feature, Mike put together some cucumber tools to allow you to run cucumber without Rails and to create what he calls a “FastModel”. The models are fast for two reasons. First, you don’t need to load ActiveRecord to get functionality like specifying field names, specifying relationships, or emulating saving records. Second, it let’s you to sketch out a design for your class while the cost of change is very very low.
An Example: Product Variants
Here’s an example of a tight little feature and step set for showing shoppers a comparison of product variants.
Feature: As a shopper, I want to compare the variants of a product
Background:
Given there is a product named "Product A"
And it has some …rails testing
Piggybak: The Roadmap
By Steph Skardal
October 8, 2012
Over the last couple of weeks, a few of us at End Point have had some discussion about the future direction of Piggybak. Piggybak is an open source mountable ecommerce framework written in Ruby on Rails supported and developed by End Point. It introduces core ecommerce functionality into a Rails application, but is intended to allow the mounted Rails application to maintain control over some architecture elements.
Pros of Piggybak
Until now, the advantage of Piggybak is that it’s a fairly lightweight approach. It leverages the power of RailsAdmin rather than creating it’s own admin. It allows the mounted Rails application to make decisions on what types of items are sellable and how these items are found (i.e. product finding methods, SSL configuration). Piggybak also has streamlined integration of ActiveMerchant, which immediately provides support of over 40 popular payment gateways. Piggybak has a cookie-based cart and an AJAX-driven one-page checkout.
Cons of Piggybak Approach
Because Piggybak has a lightweight approach, the major disadvantage is that it cannot compete with existing ecommerce frameworks as an out of the box solution with a full ecommerce feature set. …
ecommerce piggybak ruby rails