Category Archives: Uncategorized

Ruby + Rails, Uncategorized

Building an App – EKG

February 16, 2020 Peter Fitzgibbons Leave a comment

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!

Uncategorized

Write Better Software : Embrace your Humanity

May 31, 2012 Peter Fitzgibbons Leave a comment

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!

Uncategorized

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

March 29, 2012 Peter Fitzgibbons Leave a comment

I recently registered on heroku with my work email address : peter@fitzgibbons.info (obsfuscated)
My ssh id_dsa though is signed with my personal email address : peter.fitzgibbons@gmail.com.

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.

Uncategorized

STOP SOPA

January 18, 2012 Peter Fitzgibbons Leave a comment

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.

Uncategorized

BDD/TDD test cycle for beginners

January 18, 2012 Peter Fitzgibbons Leave a comment

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
end

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 (http://cukes.info)? 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.

Uncategorized