Category Archives: Uncategorized

An ADHD Adventure

I have been on an ADHD adventure nearly my whole life. My first diagnosis was somewhere in my mid-late single digits (5-7ish). Back then it was ADD, and the only possible relief was Ritalin – as far as “we” know anyway.

A lot has changed in the nearly 50 years since then. I have been officially/unofficially diagnosed with ADHD for at least 20 years. Wellbutrin has been the Medical MD “solution”, which I’ve taken on and off. Only this past month, after 20 years, did a life coach ask me if I was on an ADHD med, with the focus of our coaching to handle my ongoing symptoms of lack of focus, trouble with organization/prioritization, and trouble with focus. Life coach says : Anyone on ADHD med should be having a much different experience with these issues.

So, a Psych MD consult and a new ADHD med starting today.

Do I feel different?
Maybe? It’s only been 4 hours. Seriously. I think I do sense better “presence”. I’ll follow up this post in a month or so.

DHH – Software’s Warrior

Warrior? That’s a bold statement, and possibly widely discarded by DHH himself and the industry at-large. Really, though, think through the HerosJourney, what are the basic traits of the Hero – courage, vision, principles.

DHH on courage.
The article RailsIsOmakase presents an underlying trait of DHH – courage to stand his ground, regardless of the hell-and-high-water that will come. For 10-years on he has stood by the principles of Rails, and really more personally, has stood by his own principled views, even in the face of wild backlash over his own bold statements in RailsConfPresentations.

DHH with vision.
Well, an easy seque from the discussion of courage – DHH has held the constant vision from the very start of where Rails fits in the wider arena of Web Frameworks, and that vision has been maintained through the years.

DHH as principled.
Courage and Vision need to be grounded on principles. Like Omakase, there are certain decisions that can be ceded and compromises that can be achieved, yet a set of main rules and guides drive the overall path of development and change over the Rails framework. There are a multitude of examples of this, and DHH has led the 37Signals team with principled vision through so many successful projects.

Whether DHH would consider himself to have ever been the Warrior of any Hero’s Journey is not really the point. We can celebrate his guidance and vision for the Rails project and by extension our Rails community by that name anyway, since what we can truly celebrate is the Courage, Vision, and Principled Guidance that DHH has given to us all these years.

Thanks David!

Building an App – EKG

In this series, I’ll build an app in step-by-step posts that will produce an EKG (heart monitor) display.

The inspiration is the Phillips IntelliVue MP50 (found at my local hospital):

Tools we’ll use

Pretty much the whole point of this series… to learn some new tools and techniques:

  • Rail 6 – coming from a Rails 4/5 background, I’ll point out specifically “new to me” details.
  • SvelteJS – both introductory how-to and deep-dive into charting and real-time data streams.
  • Real-time data streams – although our sample data comes in CSV form, we’ll build some benchtesting harness to present this data to our front-end in “real-time”

Assumptions I’ll make

This tutorial makes many assumptions about you, the reader. Hopefully you can find what you need in the EKG – Resources page.

  • You know what Terminal is (or Cmd and PowerShell). You know what $ means in script examples
  • You know Ruby, and maybe Rails (not necessarily version 6)
  • You know some basic database operations, at least enough to understand Sqlite db

Project Details

I’ll be working through the following details over the series:

  • EKG sample data / downloads
  • Streaming real-time data to client (websockets)
  • SvelteJS
  • ChartJS (as a SvelteJS component)
  • ChartJS real-time update
  • Display layout
  • Automated downloads of sample data (web scraping the EKG sample-data site)
  • Creating a desktop app (ElectronJs + SvelteJS)
  • “VCR” controls over display – a design addition leveraging our desktop/mouse/keyboard oriented implementation

Let’s get started!

Write Better Software : Embrace your Humanity

This is a bit of a stream-of-conciousness post about thought processes-vs-time.

As a software developer, I invariably encounter new challenging problems, algebraic, database, mathematical. I spend time working through these problems, and the larger more complex ones take significant time, hours, many-hours, days. The day problems are the frame of reference that is interesting here.

How do we solve our problems? How much subconcious thought is involved in brainstorming solutions, testing them against the constraints and requirements of the problem-set, and ultimately encountering a solution that fits?

I believe every human, in and out of technology work, encounters a situation to “sleep on it”. In the developer community, I have discussed with many many colleagues about problems and how a colleague solved it while eating breakfast, in the shower, in their dreams, etc. I have solved computing problems in every one of these ways, and I’m sure many more. I recall solving a problem while watching the sunrise once… and computing was not on my mind in the moment.

The fact is that every living moment of our life colours the work that we do in technology. These complex computing environments that we are implementing in technology today easily defy our abilities to immediately grasp the full-breadth of the design, the implications of design decisions, and the constraints, requirements, and responsibilities of components of the design at various levels of abstraction. Every time we are introduced to a new application design, it takes time to fully absorb that information and be able to make new hypotheses, suppositions, corrections, enhancements, and improvements upon that design. Our brain, though, is not as compartmentalized as we belive (or sometimes wish!). All those moments “off-hours”, spending time with family or friends, eating a meal, watching TV, reading a book, sleeping, dreaming… change the connections in our vast computational grey-matter. Those changes then directly affect the way we consider and imagine the technological problem-set that is also at hand over the time of days.

Our humanity colours everything we do and think about as computer scientists. It is extremely important that we embrace this aspect of our humanity, and embrace our colleauges humanity as well. Take time and give our wet-ware the computational time it takes to gain our insights and understandings of our common problem-sets.

“Sleeping on it” could be the best thing for your career you could do.

It has done wonders for my career!

Heroku ! Fingerprint already exists when key-comment does not match account email

I recently registered on heroku with my work email address : (obsfuscated)
My ssh id_dsa though is signed with my personal email address :

Heroku doesn’t like this one bit.
Following this advice, I created id_heroku_rsa wtih my work-email comment.

Still no-joy.  But, this StackOverflow thread left a clue… using the ssh debugging output, I can see that ssh is still trying to send id_rsa or id_dsa.
The answer, included on that post is to ‘ssh-add’ the special key created.

Voila, now my push succeeds.


From Wikipedia on STOP SOPA DAY

Imagine a World
Without Free Knowledge

For over a decade, we have spent millions of hours building the largest encyclopedia in human history. Right now, the U.S. Congress is considering legislation that could fatally damage the free and open Internet. For 24 hours, to raise awareness, we are blacking out Wikipedia. Learn more.

BDD/TDD test cycle for beginners

I sent this message to a RailsMentor Protege of mine :

A couple notes on BDD testing :

1. Never test “the glue”. “Glue” means anything that Ruby or Rails should be doing “automatically”. That means, database querying, sending values from controller to view, etc. So, in a view test, you should be able to adequately test your views using the isolated view tests. This is where you could test that your table-building code is working right as you expect. Your controller tests should be able to be tested without database requests (mocking model instances), see #2.

2. Skinny Controllers, Skinny Views. Make your controller code, and your view usage as absolutely minimal as possible.
The ideal controller method looks like :
def show
respond_with @some_record

Yes, THAT SMALL. Rails framework provides a HEAP of assistive methods to accomplish that. #before_filter, #after_filter, #respond_to

Views should contain very little Ruby code. #render :partial and generous use of Helpers allows your view code to be very small (and subsequently, very testable). Repeatable elements like table-rows should be in partials, where they are easily testable.

3. Cucumber-level testing : Are you using Cucumber ( Cucumber scripts should really be reserved for “business owner specification”. A business owner would not usually be concerned with error handling or the exact placement (or even widget-type) of elements on the forms. The Business owner instead is interested in knowing that Page A => Page B => Page C works… or for instance, “If I buy product “Widget Sharpener”, then my shopping cart counter increases to 1 ”

There is a general BDD/TDD work cycle :

Create cucumber feature
Code supporting Cucumber step
Cucumber-RED : Cucumber execution fails because step causes failure in model/view/controller
Match expected functionality in model/controller/view RSpec
RSpec-RED : Rspec execution fails because functionality is not implemented
Modify model/view/controller with added functionality
RSpec-GREEN : Rspec now succeeds
Cucumber-GREEN : Cucumber now succeeds

You will often find steps 5-7 (Rspec Red/Green cycle) will repeat several times between Cucumber Red/Green cycles. This is our minute-to-minute Ruby-programmer’s work experience.

I’m looking forward to hearing more from you of your experience learning Ruby and Rails.