Musings about Entrepreneurship, Technology and Software Development

Accidental Technologist

When You Can’t Check a Checkbox using Capybara

In my last post I documented an issue I was having using Capybara on a client’s Ruby on Rails application with a ReactJS frontend.  I wanted to share another issue I came  across during my feature testing escapades.

The Problem

During my recent feature testing project I had a form which has a checkbox on it. The checkbox had a label with it. Did I mention this is a ReactJS frontend? I’m not sure if this is specific to ReactJS, but I suspect it isn’t. I think other frontend JavaScript frameworks may exhibit the same problem.

The Ruby code for my feature test is dead simple:

  check “English”

That’s it. The test should run and when it finds the checkbox with a label of English, the checkbox should be checked. But, it doesn’t work. After many attempts at making this work and more Google searches than I can remember..I ended up at the Capybara mailing list.

The Solution

Thomas Walpole was kind enough to reply with his thoughts on the matter:

99.9% sure your checkbox isn’t actually visible on the screen.  

What you’re describing as the “checkbox” is probably an image (probably added via CSS pseudo elements) being shown in place of the actual checkbox input element to ensure the same styling across different browsers.  If the checkbox has a label element correctly attached to it you can use `check(‘whatever’, allow_label_click: true)` – https://www.rubydoc.info/ github/jnicklas/capybara/ Capybara/Node/Actions#check- instance_method –  to tell Capybara to click the label element instead of the hidden checkbox input to toggle state.  If you don’t have an associated label then you’ll need to find whatever element is actually visible on the page and click it instead.

Changing my test to include this for the checkbox, worked perfectly. 

  check(“English", allow_label_click: true)

I hope someone finds this valuable and will save them some time and hair pulling.

Fixing StaleElementReferenceError When Using Capybara

I’ve been spending an extended period of time lately writing Feature specs for a Ruby on Rails project using Capybara. Overall it’s been a fun project to work on but I had run into a few issues along the way. One in particular is the StaleElementReferenceError exception that get thrown when you are trying to find an element on your page that you know is there but Selenium can no longer find.

The error appears to be a timing issue between the page loaded in the browser, it being rendered and Capybara and Selenium trying to find the element. After much trial and error, along with many Google searches, I found no solutions that were reasonable. Even though many people had the same problem.

The solution was pretty simple actually. I added a rescue to my test and simply slept for 1 second and retry the failure. I admit, this seems like a hack but it works and that’s all I really cared about at the time. I see no ill effects from this, no measurable delay.

RSpec.feature "Listings", type: :feature, js: true do
   scenario "can edit common area - step 3" do
      begin
        post_a_space_step_1_with
        click_on 'Next'
        post_a_space_step_2_with
        click_on 'Next'
        click_on 'Edit Common Area'
        expect(page).to have_content "Step 1"
      rescue Selenium::WebDriver::Error::StaleElementReferenceError
        sleep 1
        retry
      end
    end
end

I’m certainly open to a better solution or an explanation as to why this might be bad. Please leave comments. Hopefully I help someone get around this really annoying problem.

Ruby on Rails Testing Resources

When taking the plunge into Ruby on Rails it’s really easy to get carried away with learning all about the framework. It’s easy to learn the fundamentals and later realize the Rails community is a community of testers. It’s a strange world when you set out to learn about testing, TDD (test-driven development), BDD (behavior-driven development) and other acronyms and phrases relating to testing Ruby on Rails applications.

I decided to put together a short list of helpful resources to get started. If you have suggestions that would be useful to be added to this list, please add a comment or email me directly and I’ll update this post.

Books

  • Everyday Rails Testing with RSpec – this is a great, hands-on, roll-up your sleeves and get-to-work book. If you want to use RSpec on a daily basis, this book gives great advice on how to use RSpec in your day-to-day routine. It’s kept up-to-date with latest RSpec too.
  • Rails 5 Test Prescriptions – I use this book as a reference I often go to. It’s been updated to from previous versions to now Rails 5 and is a great tool to have on the shelf.
  • Effective Testing with RSpec 3 – if you decide you’d rather start without worrying about all the details around Rails you can start with learning RSpec with plain Ruby and help yourself. I’ve been through this one cover-to-cover and it’s a great tutorial.
  • The Minitest Cookbook – if you decide RSpec isn’t for you, this is probably the ultimate resource for Minitest. Well-written and kept up-to-date.

Podcasts

You can’t really learn testing from a podcast but you can learn how others approach the craft. The first is a podcast dedicated to testing Ruby applications. The rest is a list of a few episodes of podcasts that discussed testing.

I’ve been listening to The Ruby Testing Podcast and picked up some nice tidbits so far.

Training

I love Pluralsight.

Xavier Shay has long been involved in the Ruby community and well-known for discussions around testing. One of his best blog posts explains his approach to testing.

I’ve taken several courses on Udemy and they are one of my favorite places for training. The prices are low and there are many courses, so you have to do a bit of work to see which course is right for you but well worth the effort.

Speeding up Slow Time Machine Backups on macOS

I’ve been a long-Time Apple Time Machine for many years and it’s saved me many times.

I back up to a Synology NAS drive configured with Time Machine support. Time Machine has always been fast and efficient until I upgraded to macOS El Capitan (10.11). During that time, backups could be measure in hours instead of minutes previously. I initially thought the slowdown had to do with a recent software change in my Synology NAS.

I spent a bit of time in the Synology forums trying to solve the problem with various suggestions from users. Nothing worked.

I upgrade to macOS Sierra (10.12) and High Sierra (10.13) when they came out, hoping something had changed that fixed the agonizingly slow backups. No luck.

Disabling Throttling

I recently started to try to find a solution again since my backups recently went up in size and the slowness was really noticeable. Estimated backup times measured in days. After a bit of digging I found this suggestion, entered in a Terminal window:

 sudo sysctl debug.lowpri_throttle_enabled=0

It worked beautifully. A very large backup went from days to hours. Subsequent backups now take minutes instead of hours.

Note: you can re-enable throttling with a similar command:

 sudo sysctl debug.lowpri_throttle_enabled=1

I admit I don’t know the side effects of disabling throttling, so use at your own risk.

Making it Stick

If you want to have throttling turned off between Mac restarts, you have to do a bit more work.

Create a file under /Library/LaunchDaemons/fix-el-capitan-slow-time-machine-speed.plist with the contents:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>Label</key>
    <string>fix-el-capitan-slow-time-machine-speed</string>
    <key>ProgramArguments</key>
    <array>
      <string>/usr/sbin/sysctl</string>
      <string>debug.lowpri_throttle_enabled=0</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
  </dict>
</plist>

Make it belong to root:

 sudo chown root /Library/LaunchDaemons/fix-el-capitan-slow-time-machine-speed.plist

Make it load at startup:

 sudo launchctl load /Library/LaunchDaemons/fix-el-capitan-slow-time-machine-speed.plist

Conclusion

I’ve also tested on macOS Mojave (10.14.1) and can confirm a nice speedup. Overall, everything works really well now. I can’t take credit for the solution as I did some searching and came across several places this was mentioned, including one from Apple. I just know that it works!

Amazon.com Provides Some of the Worst Customer Service

The title says it all, Amazon.com provides some of the worst customer service. Just try to contact them and see for yourself. They are so big that they create their own rules and we have to live by them.

I placed an order last night and here is the email I received this morning:

I never contacted Amazon about unauthorized activity on my account.

When I called their Customer Service, they could provide no good explanation other than I placed an order for a higher dollar amount than usual and this was the way they ensured I was being protected.

This was for MY benefit. The order was cancelled, my account was locked and all of my payment methods removed. I think Amazon expects that I should be grateful for their astute attention to security.

It’s now up to me to change my password after 5 hours, add my payment accounts back in and recreate the order they deleted.

This is how Amazon treats customers. I’ve been placing thousands of dollars worth of orders for years with never a problem, until Amazon thinks I ordered something too high priced.

I’ve been contacted by the fraud department of my credit card companies before; some was valid fraud while others were my purchases. The process was simple, they sent a text or called me to verify the purchase. I like this feature, it’s saved me. Amazon saved nothing but added aggravation.

I’d love to have another place to order from for the items we need. Amazon is getting too big and we need other options. If we had real options, I would take my business elsewhere today. I know they wouldn’t care but if enough people did this, then they might.

Ruby on Rails – Supporting SSL for PostgreSQL on Heroku

For anyone who received this notice from Heroku:

Since 2016, all newly-provisioned Heroku Postgres databases have enforced the use of SSL to keep your data safe. However, one or more of your Postgres databases are running on legacy infrastructure, which does not enforce the use of SSL. In order to update your database to our security standards, and in response to potential impacts caused by Spectre and Meltdown, all databases – including those on legacy infrastructure – will be moved to our new Heroku PGX plans in a set of maintenances starting in March 2018 and concluding by April 2018.

What Do I Need to Do
In preparation for these maintenances, please check that your applications are using SSL to connect to your Postgres database and enable SSL connections if needed. Instructions on how to perform these steps are available in Dev Center.

If you’re using Rails 4.1+ there is a support article on the Heroku Dev Center, that helps clarify making updates to our database.yml file. This allows customizing some connection behavior to PostgreSQL.

Some parts of the database.yml file that cannot be changed include:

You cannot use the config/database.yml to set any values found in ENV[‘DATABASE_URL’]. This is a list of attributes you cannot change:

  • adapter
  • database
  • username
  • password
  • host
  • port

But, what can be changed include sslmode.

production:
 sslmode: require (disable|allow|prefer|require)
 pool: 15

I decided it would be helpful to reach out to Heroku to understand their guidance with regard to their notice. Their response:

If you’re using the pg gem, the default sslmode setting (and for libpq, the library that underpins it), is prefer this means that should the server have SSL support, it will be used when the connection is established. This means there should be no action required, though if you wish, it’s worth a test with spinning up a staging environment with a non-legacy Postgres instance.

It seems if you’re using Ruby on Rails with the pg gem, you should be OK doing nothing but with brownout period scheduled, it’s probably a good idea to test during one of those times.

Heroku Support also indicated setting the environment variable PGSSLMODE would also override the default behavior for sslmode used by libpq.

It seems this is a notice which doesn’t effect a majority of Heroku customers and is a necessary and worthwhile upgrade. Hopefully this helps others as the public information available for this from Heroku is minimal.

Fixing Your Puma-dev SSL Problems on Google Chrome

Ruby on Rails developers have it made in many ways. We rely on and take advantage of great software created by the community. Puma-dev is just one of those great pieces of software.

Puma-dev has some nice improvements over Pow, which Basecamp had promoted for years but has seemed to stop development.

Puma-dev allows developers to better mirror their local development environment to that of production. Prior to Puma-dev or Pow, developer would have to access their Ruby on Rails applications with something like localhost:3000 in their browsers. It works but having a real URL to visit, like mygreatapp.dev is better.

This worked well until a recent update to Google’s Chrome browser:

A lot of (web) developers use a local.dev TLD for their own development. Either by adding records to their/etc/hosts file or by using a system like Laravel Valet, which runs a dnsmasq service on your system to translate *.dev to 127.0.0.1.

In those cases, if you browse to http://site.dev, you’ll be redirect to https://site.dev, the HTTPS variant.

That means your local development machine needs to;

  • Be able to serve HTTPs
  • Have self-signed certificates in place to handle that
  • Have that self-signed certificate added to your local trust store (you can’t dismiss self-signed certificates with HSTS, they need to be ‘trusted’ by your computer)

I’ve faced this myself and Chrome refuses to serve the site, only showing security errors.

When trying to fix this problem I search a lot around the web and came up with very little. There were plenty of acknowledgements that since .dev is now a top-level domain (TLD) and Chrome 63 treats it as such and forces SSL, it looked like moving away from .dev would be needed.

This was my assumption until I discovered a recent post from Barry Woolgar of Storm demonstrating setting up Puma-dev. He addresses troubleshooting .dev TLD issues specifically:

If your browser complains about an untrusted root certificate, please do the following:

  1. Open Keychain Access
  2. Click the login keychain in the left pane, then find the Puma-dev CA certificate in the right pane
  3. Double-click it and expand the Trust section, and make sure it says Always Trust
  4. Drag it into the System keychain in the left pane
  5. Restart your computer
  6. Try https://my-project.dev again!

Although I didn’t need to restart my Mac, this worked perfectly! I can now serve .dev domains in Chrome and latest Firefox.

ABC Family – Terrible User Experience from a Company Who Should Know Better

Somehow I was added to an email list from ABC Family, specifically Freeform. This is a channel that airs children’s TV shows. Much of their content is terrible but I’m not their target audience.

I have been receiving emails about new programming being added to their lineup. Our daughter is now 18 and outgrew what they have to offer, so when their latest email came in, I decided to unsubscribe. Here is their message to me:

2018 01 10 14 44 09

This is terrible! This is a terrible experience as a user. Here’s what bothers me:

  1. I’m trying to unsubscribe from their mailing list. The title indicates I am being added to another list, a Do Not Email list. What?
  2. They’ve recorded my request. Why? Don’t procrastinate, do it now.
  3. They need up to 10 business days to remove me, add me, or whatever for processing. 10 days? How are they handling my request, carrier pigeon? We’ve all belonged to email lists before, we know how unsubscribing should work..it should happen NOW.

This single interaction with ABC Family has stuck in my mind for a while. It has left a lasting impression.

Leave a positive lasting impression with your customers. If they decide they don’t want to do business with you any longer, don’t burn the bridge..maybe they’ll be back at some other time. Maybe they will recommend you to a friend. If you burn bridges, they will be gone for good.

#

Complacency kills. →

Matthew Dicks explaining so well, what we should all already know and strive to do:

There is always someone better than you. The bar is always higher than you think. When you stop looking for and striving for that higher bar, you are doomed to remain far below it.

Failure to seek out people better than you results in complacency, and complacency is the worst. Complacency produces mediocrity and a false sense of security. It results in an inability to see the scarcity of resources and increasing levels of competition in this world.

It’s true in the field of technology as it is in the rest of our lives. There are always better, smarter developers from whom we can learn. There are better and brighter people in every aspect of our lives, whether it be a better parent, better spouse or better handyman. We can learn from everyone; don’t assume you know the most.