Saturday, November 25, 2017

puts_debuggerer 0.8.0 is out!

puts_debuggerer, the library for improved Ruby puts debugging, now has better support for Rails.

In a Rails environment, puts_debuggerer now automatically outputs to Rails logs at the debug level. This is facilitated using the new "printer" support, which is a configurable option that comes with smart defaults.

The "printer" option value can be a global method symbol or lambda expression to use in printing to the user. Examples of global methods are :puts and :print. An example of a lambda expression is lambda {|output|}
It defaults to :puts , but if Rails is detected, it defaults to: lambda {|output| Rails.logger.debug(output)}
# File Name: /Users/User/example.rb
PutsDebuggerer.printer = lambda {|output| Rails.logger.error(output)}
str = "Hello"
pd str
Prints out in the Rails app log as error lines:
[PD] /Users/User/example.rb:5
   > pd str
  => Hello

Learn more about puts_debuggerer over here:

Monday, October 23, 2017

Sunday, August 06, 2017

Ultra Light Wizard v0.1.4 Wizard Step Breadcrumb

Ultra Light Wizard just got an update (v0.1.4). It now ships with a wizard step breadcrumb like the one in this screenshot:

Its semantic markup and CSS is easily stylable and customizable, especially to developers well-versed in HTML5 and CSS3.


Saturday, July 29, 2017

How To Test-Drive Rails Generators?

Rails generators are a form of meta-programming in Ruby. They're basically programs that write programs. To be more specific, in my open-source project Ultra Light Wizard (also a pattern presented at RailsConf 2014), the Rails generator ultra_light_wizard:scaffold generates models, controllers, views, routes, helpers and a migration automatically when the user wants to build a wizard.

How does one test-drive such a Rails generator though?

I started by writing a standard RSpec test and then quickly realized that if I were to test-drive what each file generated contains, I'd be opening a can of worms and getting lost in so much unimportant detail.

Then, I had an idea. Why not create a full-fledged Rails app as a fixture and place it under the "spec/fixtures" directory?

Next, how about I configure the app exactly as needed to run the generate command from a test, but then during the test, I leave it untouched and copy it on every test-run to avoid messing up the reference version?

Well, to explain, you end up with an RSpec test that looks like this:

Now, comes the tricky part. How do you test by invoking the generator on the project copy?

Well, I took the easy way out and simply dropped down to the shell from Ruby as follows:

In other words, by invoking "rake" from the Rails project copy, I started another RSpec test suite run from within my main test suite. Totally meta, eh!?

Now, here comes the meat of the work, in the form of feature specs written for the Rails project copy. To explain, the tests shown below are written from the user's point of view for the effect of running the generator in a real Rails app (the top part consists of helpers [e.g. fill_in_project_fields] and the bottom part has the test cases as "scenarios" [e.g. scenario 'can start wizard']):

And with that... problem solved. Here is an example test run:

Notice how the inside RSpec test-run (from the reference Rails project copy) reported 5 examples, and then the outer RSpec test-run reported 1 example (the one that spawned the rest).

Pros to this approach are success in covering end-result of generation, and decoupling tests from detailed work of generator.

Cons are obviously increased complexity, albeit that is balanced with decreased complexity of writing the inner integration specs and freedom of implementation.

How have you handled Rails generator testing in the past? Care to discuss pros and cons?

Wednesday, July 26, 2017

Self-Installing Apps

I have recently explored the idea of self-installing apps while implementing the new Glimmer executable.

What do I mean by a self-installing app?

An application that requires external dependencies, potentially written in multiple languages/technologies, and can handle self-installing them upon first-run via a simple seed command.

Think of it like a seed of a bean plant, which you'd plant (download), water (execute), and then voila, a full-grown app sprouts up, grabbing extra components off the Internet as needed.

To translate this into my example above, Glimmer, has a non-ruby dependency, SWT.jar (Java Archive), which must be setup properly for Glimmer to work. As a self-installing app however, it detects whether SWT.jar is available or not on the first run, and automatically downloads and installs it if unavailable, or otherwise uses it and runs without a hitch. That works on Mac, Windows, and Linux with both x86 and x86-64 CPU architectures.

Self-installing apps are nothing new, but I am documenting my first venture into it in JRuby (albeit I've collaborated with a developer in the past who wrote such an installer for an application I built at a past company I worked for)

I shall explore the idea of having self-installing apps auto-update themselves as well in the future. Stay tuned for a blog post about the subject if I do implement.

Would it be a good idea if all software was self-installing and self-aware? Please share your thoughts in comments.

You may try Glimmer over here.

Glimmer Ruby Desktop Library Version

Glimmer Ruby Desktop Library Version is released!

It now supports one-way Tree data-binding similar to that of SWT Table.


You may learn more from the screenshot and rspec test included below.

Happy Glimmering!

Tuesday, July 25, 2017

Puts Debuggerer v0.7.1 with run_at condition option

Puts Debuggerer v0.7.1 is out.

(defaults to awesome_print as its print_engine now)

Ever wished you'd see debug statements only the first time a puts statement executes, and avoid printing 10 or 100 times in a test run? Now you can with PutsDebuggerer.run_at option.


(default = nil)
Set condition for when to run as specified by an index, array, or range.
  • Default value is nil meaning always
  • Value as an Integer index (1-based) specifies at which run to print once
  • Value as an Array of indices specifies at which runs to print multiple times
  • Value as a range specifies at which runs to print multiple times, indefinitely if it ends with ..-1 or ...-1
Can be set globally via PutsDebuggerer.run_at or piecemeal via pd object, run_at: run_at_value
Global usage should be good enough for most cases. When there is a need to track a single expression among several, you may add the option piecemeal, but it expects the same exact object passed to pd for counting.
Examples (global):
  PutsDebuggerer.run_at = 1
  pd (x=1) # prints standard PD output
  pd (x=1) # prints nothing

  PutsDebuggerer.run_at = 2
  pd (x=1) # prints nothing
  pd (x=1) # prints standard PD output

  PutsDebuggerer.run_at = [1, 3]
  pd (x=1) # prints standard PD output
  pd (x=1) # prints nothing
  pd (x=1) # prints standard PD output
  pd (x=1) # prints nothing

  PutsDebuggerer.run_at = 3..5
  pd (x=1) # prints nothing
  pd (x=1) # prints nothing
  pd (x=1) # prints standard PD output
  pd (x=1) # prints standard PD output
  pd (x=1) # prints standard PD output
  pd (x=1) # prints nothing
  pd (x=1) # prints nothing

  PutsDebuggerer.run_at = 3...6
  pd (x=1) # prints nothing
  pd (x=1) # prints nothing
  pd (x=1) # prints standard PD output
  pd (x=1) # prints standard PD output
  pd (x=1) # prints standard PD output
  pd (x=1) # prints nothing

  PutsDebuggerer.run_at = 3..-1
  pd (x=1) # prints nothing
  pd (x=1) # prints nothing
  pd (x=1) # prints standard PD output
  pd (x=1) # ... continue printing indefinitely on all subsequent runs

  PutsDebuggerer.run_at = 3...-1
  pd (x=1) # prints nothing
  pd (x=1) # prints nothing
  pd (x=1) # prints standard PD output
  pd (x=1) # ... continue printing indefinitely on all subsequent runs