Unknown's avatar

Posts by Shawn McKinney

A bike riding code monkey.
Dad with Kelly and Timothy circa early '90's.

2016 Dirty Kanza Part I – The Signup

The pic above from l to r, Kelly, Richard, and Tim McKinney circa xmas ’91.

Note:  this post is about my first-ever Dirty Kanza 200 experience on June 4, 2016. 

Part I – The Signup

Read Part II – Prep / Training

Read Part III – Friday

Read Part IV – Starting Line

Read Part V – Checkpoint One

Read Part VI – Hitting The Wall

Read Part VII – Checkpoint Two

Read Part VIII – Checkpoint Three

Read Part IX – Finish Line


My father, Richard McKinney, passed away December 23, 2015.  He had suffered for about 10 years from a series of health problems increasing in severity.  Throughout that time I never heard him complain.  If asked he would declare all of the reasons he considered himself fortunate.

I owe my love for cycling to him.  From my earliest memories, there were plenty of bikes around.  First a Huffy Stingray hand-me-down in the late ’60s.  Later were the department store 3, 5 and 10-speeds, ’70s era European road bikes, and finally into the mountain bikes of the ’80s and ’90s.

In those days (early ’70s) parents let their kids run loose and we took full advantage of it.  In the summer, it was not unusual to leave right after breakfast and not return until just before suppertime (our cutoff ).  Pack up a few peanut butter and jelly sandwiches and we’re good to go.  We’d explore the countryside on bikes.  Pavement, gravel, singletrack and doubletrack.  Sometimes we’d run up against hobos making their way across the area via the highways and railroad tracks.  Maybe we’d come back carrying some kind of snake or turtle and Mom would not be happy.

“What do you think you’re going to do with – that?” she’d ask.

There were boundaries.  Don’t cross the Delaware River west of town or the US Highway 24 to the north.  Little Wild Horse Creek was especially off limits.  Kelly once cut his foot on a crossing, bad enough to require stitches.

Screen Shot 2016-06-21 at 1.03.37 PM

Perry KS hasn’t changed much 45 years later.

Beyond the creek were miles of unbroken ranch land to be explored. The hills NE of town was left by Pre-Illinoian glaciations 600,000 years prior and we couldn’t resist them. We’d hose ourselves down using the water spigot at the edge of town, before returning to our house, between the two churches, one Methodist, the other Catholic.

We thought we were being slick, but Mom would always find out.  Years later she told us how – muddy underwear from swimming in the creek.

Those were simpler times and our parents were not fearful like many are today.  The worst thing that ever happened was being prevented from riding due to a mechanical problem, missing a cutoff or going out of bounds, and getting into trouble (grounded).

A very poor quality Polaroid photo of us in Perry, KS (early ’70s)

1497899_10206908779790731_8985013281111561056_o

l to r, Kelly, Kevin and Shawn McKinney circa ’73

Years later, after I got too busy to ride, my Dad would throw hints by sending me home with new bikes to try out.  I’d mostly ignore his attempts during my 20’s and 30’s but he never gave up and once even sent me home with an electric bike (which I still have).

Here’s a newspaper clipping of me riding one of Dad’s hand-me-down bikes with son Zachary…

Zack&Shawn-Jan2000

From the local rag (Maumelle Monitor) Jan 20, 2000.

Over the years, as my passion for cycling has ebbed and flowed, I received steady encouragement from him.  Of late, as the number of hours in the saddle rose to extreme (crazy?) levels, he continued to support and applaud my accomplishments (modest though they were) never once hinting I might be overdoing it.

My younger brother, Timothy, completed the 2014 DK200 in just under 14 hours.  He subsequently dedicated the accomplishment and gave him his coveted Race Against the Sun award,  I was there acting as support for Tim, and the moment was not lost on me in terms of importance. The seed was planted.

So after Dad died talk returned to the Dirty Kanza and thoughts of signing up in 2016.  Before that time the race was on my bucket list but I had no concrete plans for making a run this year.  After the funeral, and with pleading from my family, we decided to go for it.

13245503_10153597833766156_3125960679442112175_n

When it became time to sign up I was leaning toward the Half Pint (100 miles).  To me it made sense as it would give a taste without having to commit to more training than I was accustomed to.

It was then my brother Kelly convinced me to do the whole enchilada.  You’ll get there in June and want to do the full distance he reasoned.  Somehow he swayed me and I signed up with him along with Gregg (cousin), and Dan (close friend).

Little did we know what we had gotten ourselves into.

600667_10206894322069297_9044119770813017364_n

Richard J McKinney 1935 – 2015

 

Next Post: Part II – Prep / Training

 

 

 

2016 Dirty Kanza Part VI – Hitting The Wall

Pic above 65 miles into the 2016 DK200.

Note:  this post is about my first-ever Dirty Kanza 200 experience on June 4, 2016. 

Read Part I – The Signup

Read Part II – Prep / Training

Read Part III – Friday

Read Part IV – Starting Line

Read Part V – Checkpoint One

Part VI – Hitting The Wall

Read Part VII – Checkpoint Two

Read Part VIII – Checkpoint Three

Read Part IX – Finish Line


Only 65 miles into the Dirty Kanza 200 and already getting worried; running at higher levels than anticipated.  Heart rate was a full 10 beats per minute over the expected.  Was this a malfunction in the HR monitor?  No, it’s working correctly.  This terrain was far more challenging than what I’d trained for and was causing me to work harder maintaining a decent pace.  I knew that going in but hearing about something and experiencing it firsthand are two different things.

By this time Checkpoint One was 15 miles behind.  That is when I began to sense the trouble.  Stomach had just stopped working.  I could nibble but had lost a real appetite.  I knew eating was the only way keep going.  At mile 50 you are fueling for mile 100.  Stop eating and run out of gas fifty miles later – he’s dead Jim.

Checkpoint One is where the mistake was made of replenishing all fluids (about 3L) with a combination electrolyte and calorie replacement mix.  The reasoning was sound.  Didn’t want to eat, maybe could compensate by drinking.  Normally on a day like this (hot), it would be half pure water, half EFS (chosen mix).  Ten miles past that checkpoint the mixture had become warm/syrupy/sweet/salty and it took everything I had just to continue drinking – it.

What I’d have given for a cold bottle of plain water!  My body was becoming dehydrated and that plays tricks on the mind.  Began to fantasize about how good that water would taste.  Longing for it.  Yet I still had over 35 miles before Checkpoint Two, during an unsupported race, no aid stations, towns, quickmarts or help from my support team – unless I wanted to quit.

Around this time a jeep was passed, parked on a hilltop, off the road about 20 meters.  I stopped and hailed the driver.

“I’ll give you five bucks for a bottle of water,” I told him, only half joking.

The driver chuckled and replied he’d be happy to “give” me one.  I found out later he was a member of a Kansas City jeep club that patrols the area every year.  Not sure what their mission is specifically but suspect it’s to act as first responders when things go awry for riders who get in over their head.

That bottle was a small one, but got me another 10 miles, before once again thoughts of dehydration set in.  Knowing these races are as much mental as physical I squelched the negative thoughts, took another swig of the knarly mix, and dug in for the next big climb.  Whoever said Kansas was flat never rode these sections.  Checkpoint Two was still over 25 miles away so I had to make the most out of the resources I had.  Nasty or no I’m gonna drink that swill.

About halfway into the next hill my left quad began cramping.  Brief stabs of excruciating pain.  Felt like a sharp knife being inserted deep into the muscle.  “No!” I proclaimed loudly and pounded on the leg using my left fist as a hammer, followed by an attempt to massage away the spasm by grasping it fully and squeezing hard.  I’m sure any riders who were nearby thought I had gone stark raving mad.

“This is NOT going to happen!” I cried again, nearly at the top of my voice.  After months of training, with it’s thousands of miles and expenditures, not gonna end here, like this.  As the cramp eased I worked my way, slowly, over the top of the hill, pedaled gently down and steadied myself for the next big climb, with it a new concern…

20160604_115430

Next Post: Part VII – Checkpoint Two

 

Why Bugs are Good

Goes against the grain of conventional wisdom.  The nastier, the better.  How can this be?  Let me state the ways.

  1. Status.  It demonstrates an active project.  If you go to their bug tracking page and can’t find a bunch of open defects, something is wrong.  It’s dead, Jim.
  2. Relevance.  Shows that people are using it.  Early on, I once heard a developer proudly proclaim his code never has bugs.  That I still remember 25 years later is a testament to how profoundly stupid of a statement it was.  If your code doesn’t have bugs, it’s not being used.  The more it’s used, the more bugs to find.
  3. Excellence.  Bugs bring out the best in us by challenging our assumptions and testing our abilities.
  4. Openness.  Let’s admit it, we only hide when embarrassed or scared.  Much better to own up, accept the consequences, move on.

LDAP is dead. Long Live LDAP!

David Goodman’s keynote, LDAP 2020 Paradise Lost or Regained?, provides a retrospective for us to contemplate. In it, he describes LDAP’s roots (X.500), where it’s been (U of Mich, Netscape, Sun, Symas, Microsoft, ForgeRock, etc.), and offered insights of what needs to change.

Bottom line, it’s healthy to continually ask the question – Is LDAP dead?  For the answer, we’ll only slightly alter Mark Twain’s famous quotation:

Reports of LDAP’s death have been greatly exaggerated.

Why is that?  For starters, because of conferences like LDAPCon. More than its in-depth technical analysis and tutorials, is what happens in the spaces between the talks.

These spaces nurture the protocol by allowing free discussions on the flaws, and room to create plans for corresponding fixes/enhancements.

Just what are these fixes and enhancements?  Have a look at the program and slides.  Subscribe to the LDAPExt mailing list, share in best practices, and above all, keep attending LDAPCon!

See you at LDAPCon 2017!!

JavaOne Survival Guide

With next week being my 12th time at JavaOne, here’s some wisdom for those who’ve never been.

  1. Use the schedule builder.  Many sessions fill up early and if you didn’t reserve your seat you’ll be stuck in overflow.

  2. Don’t miss the Oracle Appreciation Event.  It’s one of the hottest attractions in San Francisco.  Event bracelets are highly sought after and traded by the locals on the free market.  I recommend leaving well in advance of the encores to avoid the long queues that gather for the return bus trip.

  3. Enjoy a brew at the Thirsty Bear a block from the Moscone center.  You’ll be glad you did.  And don’t skip the tapas.

  4. Attend the BOFS.  More casual (and fun) than the event keynotes or technical sessions.  BOFs are a great way to meet the leading minds working with Java.  The relaxed format encourages audience participation and are a way for your voice to be heard.
  5. Trouble reserving a room within your price range nearby?  Try renting an Airbnb apartment.  Often times apartments may be rented for a fraction of the cost you would otherwise pay for a hotel room.
  6. Take the BART.  No need to rent that car or pay $40 in cab fare.  BART has terminals at both local airports, is fast, easy and cheap.
  7. Get out and walk a bit.  Market Street (shopping), Union Square (more shopping), and China Town (eating and sightseeing)  is walking distance from the conference hotels.  Better yet, stop by the Embarcadero for a ride on one of the ferries shuttling commuters across the bay.

    If you’re lucky you might snag a bar seat at the Slanted Door which is one of the best restaurants in town.

    Need a laugh?  Check out Pier 39’s Sea Lions at the Wharf.

  8. Stay until Friday.  Avoid the mad rush to the airport on Thursday afternoon.  The conference pace slows to a crawl which is nice after all the earlier hustle and bustle.  There’s usually plenty of free beer left as Oracle tries to drain the last of the kegs.

The Seven Deadly Sins

These personality traits destroy engineering projects:

  1. Stupidity is the most obvious toxic personality trait found on this list.  Engineers of this caliber leave a trail of destruction wherever they go.  Under qualified for all but the most basic tasks, ill-equipped to solve problems, repeatedly makes the same mistakes, requires constant hand-holding 1
  2. Hubris is harder to spot because the possessor’s swagger acts as a cloaking device.  Eventually the weight of repeated faulty assumptions catches up.  Known for diving headfirst down rabbit holes and not pulling back until after the damage is done.  Frequently the naysayer, stands in the way of practical solutions in favor of counter proposals with snowball chances in hell.
  3. Sloth a.k.a the sandbagger. Tasks of critical importance somehow are never their responsibility.  First to give up, known for coming in late, leaving early and disappearing for long periods of time.  Taken alone, they cost, but one resource. Beware the sandbagger however, their presence Demotivates.
  4. The Over-extender is the least undesirable due to good intentions.  Doesn’t know how to say ‘no’.  They hurt projects because of bottlenecks created by unfinished tasks.
  5. The nitpicker can’t shut up.  Feels the need to speak the truth in spite of the greater good.  Their constant stream of disparaging comments damages morale.  Worst when found in the leaders; the spawned negativity permeates the atmosphere with fear and dampens creativity.
  6. The micro manager will expect a detailed explanation for everything under the sun.  Has an obsessive need to stay informed about every nuance.  Can be dangerous in a crisis, delaying first responders when their presence is most needed.
  7. Fear a.k.a. Elmer the FUD, is stuck in the past.  To say Elmer’s overly conservative is an understatement.  Frightened by anything new and blocks innovation reflexively.
  8. Bonus: The Firestarter, a.k.a. gaslighter, ignites the workplace with artfully applied little jabs. Twisting words of coworkers seen as rivals into insults, just for kicks. One way to counter is to play dumb and have them repeat, “Sorry, I don’t understand what you mean… What did you say?”

Footnotes

1. We’re not talking about trainees here. Professionals with many years of experience and incapable of functioning without help within their core competencies.

JavaOne Open Source IAM Expert Panel

Once again we’ll be meeting in San Francisco for a Birds-of-Feather.

Open Source IAM Expert Panel Part 4


Abstract
There is a growing need in the market today to provide open source identity and access management (IAM) solutions that are both comprehensive and easy to use. Despite this growing need, the track record for open source solution providers in this space has been mixed. This session provides an opportunity for dialogue between those that need such products and those that create them. The goal of the session is to provide the attendees with information for better exploiting the products available today and to answer any questions they may have. At the same time, they get an open forum in which to provide ideas on what needs to change going forward.

Panelist
Igor Farinic, Senior Software Engineer, Cofounder, Evolveum
Les Hazlewood, Cofounder and CTO, Stormpath
Misagh Moayyed, Software Engineer, Unicon, Inc
Bill Thompson, Director, Digital Infrastructure, Lafayette College

Moderator
Shawn McKinney, Systems Architect, Symas

Schedule
October 26, 7:00 pm – 7:45 pm | Hilton—Plaza Room A
BOF (Birds-of-a-Feather) Session

Slides from previous events

  1. Part I – October 1, 2012
  2. Part II – September 23, 2013
  3. Part III – September 30, 2014
  4. Part IV – October 26, 2015

Apache Fortress SAML Demo

The aim of this tutorial is to connect Apache Directory Fortress with Spring Security SAML and a common Identity Provider – SSO Circle.com. It’s not intended to highlight all of the possible locations in code where security checks may be applied.  For that take a look at The Apache Fortress End-to-End Security Tutorial.


Fortress SAML Demo

Go to https://github.com/shawnmckinney/fortress-saml-demo, complete the steps under the README.

More info here: Fortress-Saml-Demo

Saml-Demo-Block-Diagram-Master

What Are Temporal Constraints?

Defined

Ability to control when an entity activation occurs based on time and date criteria.  Temporal constraints are typically applied during User and Role activation as part of an authentication or authorization check.

What Are They For?

Can be used to limit when a User may log onto or activate a particular Role within a security domain.  Follows the principle of least privilege as it ensures access rights are only granted when appropriate.

How Do They Work?

There may be policies to control what dates, times, and days of week a User may access a particular area of the system and in what Role.  Can also be used to enforce a lockout period when the User is inactive or otherwise away for an extended period of time.

Apache Fortress Temporal Constraints

Fortress allows constraints to be applied onto both User and Role entities.  There are rules that fire during an activation event (any policy enforcement API call):

  1. Can the entity be active on this Date?
  2. Is the entity within a lockout period?
  3. Has the entity exceeded a particular inactive period?
  4. Can the entity be used at this time?
  5. Can the entity be used on this day?
  6. Are there mutual exclusion constraints that prevent activating this entity?  (Roles Only)

These temporal constraint rules are pluggable and may be added, overridden or removed.

What are Password Policies?

Defined

A set of rules surrounding the content, quality and lifecycle of a password.

What Are They For?

Helps to safeguard the integrity of password values within a particular security domain.  With moves toward Multi-Factor Authentication (MFA) and other biometric authentication measures one can make the argument that the password’s days are numbered.  Nevertheless they remain in use widely today and will continue for the foreseeable future.

How Do They Work?

Define a set of rules to be enforced during a password lifecycle event.  An example of a lifecycle event is authentication, password change and password expiration.  There are a few standards that govern how systems should behave in this area.

IETF Password Policies

Apache Fortress adheres to IETF Password Policy Draft.  While this draft was never formally adopted it has traction within the various directory implementations and remains the de facto standard today.

Password Policy Enforcement

Password enforcement options include:

  1. A configurable limit on failed authentication attempts.
  2. A counter to track the number of failed authentication attempts.
  3. A time frame in which the limit of consecutive failed authentication attempts must happen before action is taken.
  4. The action to be taken when the limit is reached. The action will either be nothing, or the account will be locked.
  5. An amount of time the account is locked (if it is to be locked) This can be indefinite.
  6. Password expiration.
  7. Expiration warning
  8. Grace authentications
  9. Password history
  10. Password minimum age
  11. Password minimum length
  12. Password Change after Reset
  13. Safe Modification of Password
  14. Password Policy for LDAP Directories