Gift ideas

  • 3 pack of magnetic phone micro USB chargers for $15 – Link
  • Grow lighting for plants – Link
  • Alexis enabled kindle for $30 – Link
  • Laser projected keyboard controller for $30 – Link
  • Renaissance festival shirt $30 – Link
  • Laser projected mouse controller for $70 – Link
  • LeapMotion programming kit for $80 – Link
  • Neonode TouchBar – Touchscreen Capabilities for $70 – Link
  • Tobii eyeX – eye tracking for a mouse for  $70 – Link
  • Echo dot – Link

For stocking stuffers

  • NFC ID ring for $4 – Link
  • Cane handle, decorative – Link
  • NFC id rings for $18 – Link (size 9?)
  • Costume pieces:  99cents ring, $4 cross
  • Pacific Rim $9 – Link
  • Live, Die, Repeat $9 – Link
  • John Wick – $14 or $6 dvd – Link
  • No candy please.  Nor super sugary stuff.
  • Packets or jar of standard swiss mix (no marshmellow) are ok

Get J an army stocking – Link


Notes on Xpath / XML with css

Xpath adventures!

I was using a chunk of code that I found to be rather brittle for testing Xpath with Capybara in a ruby on rails integration test.  Originally I was just calling click_link on the first link within the .body tag.

The problem is that’s really brittle.  Any other links put in there before that will mess up the process.  Also, if I make that page a partial so I can reuse that particular list on other pages, then my test is broken.

So my practice now is to add a class or div to the top of all partials or pages even if I have the body & nothing else is in that page.

An example:

The partial _campaign.html.haml would have a .campaigns at the top wrapping it.  Then my html/css parsing with Xpath would be `.campaigns` to get into the section of the list I want to affect.

For my purposes that’s enough.  If you want to go deeper though – as you have more elements inside & need to be selective, then you would add more path hierarchy … .campaigns/.list-group/.list-group-item[1] … with the last [1] being select the first item in the list group.

Xpath best practices is to not stack too many or any nested items so they use within.  Still, probably best to only use two within‘s one to grab the first unique class/div name & the next to grab the last div or element before running the method against the result.

  • Instead the previous campaigns example, using the within would be combined with something else….
within('.campaigns') do

Also, as a bonus I had to figure out the calls for using spaces in the names/titles.  There are two methods I like.

  • Exact matching with “multiple class selectors”… .something/.something_else – Link.
  • Matching Xpath to just search a string for a partial match with the xml/css  – Link.  I would still scope the search/match pattern (2nd method) by using a .within anyways as the whole point is avoiding brittle tests.

Finding the class based on an object instance of the object in Rails with Constantize

Trying to write a rails method to count the rows in a table.

The twist:  I want to do it in such a way that I can call the method from any object and it will automatically determine the name of the table to count the rows from.

Basic outline of the flow … I want to use Rails Way to identify the table & count the resulting table name’s rows.


To do so I need the name of the model.  As my test object, I cleverly naming it anObject

2.3.1 :040 > anObject = Player.first
 Player Load (2.4ms) SELECT "players".* FROM "players" ORDER BY "players"."id" ASC LIMIT $1 [["LIMIT", 1]]
 => #<Player id: 1, screenname: "Serena Mitchell I", motto: "Wyaaaaaa.", country_id: nil, created_at: "2017-09-01 12:52:27", updated_at: "2017-09-01 12:52:27">

Rails has several definitions which hold that information in various states.  I chose to use .class …

2.3.1 :043 > anObject.class
 => Player(id: integer, screenname: string, motto: string, country_id: integer, created_at: datetime, updated_at: datetime)

When we look at this, it’s more information than we need.    The Rails Way is to call the .name method out of the class method …

2.3.1 :046 >
 => "Player"

As a bonus .name gives us access to .constantize which is the goal.

2.3.1 :048 >
 => Player(id: integer, screenname: string, motto: string, country_id: integer, created_at: datetime, updated_at: datetime)

Now we can put .constantize to search all the Rails app’s constants …

2.3.1 :050 >
 => Player(id: integer, screenname: string, motto: string, country_id: integer, created_at: datetime, updated_at: datetime)

… which when proceeded by the will give the activerecord model as an object which we can then .count against …

2.3.1 :052 >
 (0.8ms) SELECT COUNT(*) FROM "players"
 => 46

At this point should net us what we need, so I wrap it in a method for easy reuse …

#  gets name of constant to get a count of model
def row_count(ar_object)

This of course isn’t perfect, if ever you had an conflict in the naming scheme, scope issues or an orphaned object from the inheritance tree, the .constantize search up the object inheritance tree would fail even though your object exists.

Note there is another way, that if you are only doing ActiveRecord objects works too … Link.  My example is slightly more generic example as you can use it to find other types of objectives – though you can’t use the count method with most of them.

The reason you would use it, is that it’s more self documenting, thus more in line with the Rails Way ….

# is basically the same as for this purpose

My studies from other authors which I found helpful, in no particular order …

  • Failure points & discussions for constantize – Link
  • Implementing in a custom module from Stackoverflow – Link
  • Implementing the constantize lookup in depth & use – Link
  • Safelty constantize in forms, aka don’t – Link
  • Metaprogramming & testing with constantize – Link