A decade of writing this stuff? Seriously.

In tinkering with my blogging platform and playing with different technologies, I’ve just realized that I’ve been writing online for well over a decade now.

It started a long time ago, when I was writing personal stuffs on a public Open Diary back in 1995, under an alias, which for the life of me, I can’t recall. The site is currently unavailable, and I was curious to see if they still indexed old entries, and see if I could dig anything up from back then.

It was a place that I tossed out whatever I had in mind, a place to jot down the ideas running through my head, a place for a creative outlet with the safety of knowing nothing would ever come back to me, since I lived behind the veil of anonymity (since back then, PRISM was just a dream…), and I was able to express whatever I wanted, in a safe-like place.

After writing there for a couple of years, I was witness to the 1997 Ben Yehuda Street Bombing – I was at a cafe off the street with some friends, when it happened, and went to offer whatever help I could, having had some First Aid training. After spending some 2 hours dealing with things that I’ve pushed far to the back of my mind, I was gathered by a friend, carted to his house, and sat in shock for a few hours, before making my way home.

The next day, I wrote about it on OD, and referenced my friend by first name only.

A couple of days later, a comment came on my post, asking if my friend was ‘So-and-so from Jerusalem’, and if so, that they knew him, and agreed that he was a great help. We began discussing our mutual friend, and eventually met in person.

This was the first revelation I had – you’re never truly anonymous.

We became pals, hung out a few times, and continued to stay up to date with each other for a while.
I did notice that after a while, my writing dwindled, now I knew that there is someone out there who knew who I am, not that I was saying anything outrageous, but the feeling of freedom dropped.

During my time in the Air Force, I wrote extremely rarely, since getting online was near impossible from base, so after discharge in 2000, I pretty much had stopped writing altogether.

In 2003, my friend Josh Brown invited me to the closed community (at the time) of LiveJournal, where it quickly grew into the local social networking site, where we could post, comment, and basically keep up with each other’s lives.
Online quizzes were ‘the thing’ and posting your results as an embed to your post was The Thing to do.

After spending 4 years on LJ, they began providing additional customizations, added features for paid-only users, and I didn’t want to spend any money on that, rather I wanted to host my own site.

So I did, for a while. In 2006, I built my own WordPress 2.0 site (history!), hosted it on my home server (terrible bandwidth) and began on the journey of customized web application administration. Dealing with databases, application code updates, frameworks, plugins, you name it.

I think I actually enjoyed tinkering with the framework more than actually writing.

Anyhow, I’ve written sporadically over time, about a wide variety of things, both on this site, and elsewhere.
The invention of Facebook, twitter, and pretty much any social network content outlet has replaced a lot of the heavier topic writing that went on here.

But it does indeed fill we with some sense of happiness that I’ve been doing this for a long time, and have preserved whatever I could from 2003 until now, and continue to try and put out some ideas now and then.

My hope is that anyone can take the to express their creativity in whatever fashion they feel possible, and share what they want to with the rest of us.

The Importance of Dependency Testing

Recently I revisited an Open Source project I started over a year ago.

This tool is built to hook into a much larger framework (Chef), and leverages a bunch of code many other people have written, and produce a specific result that I was looking for.

This subject is less about the tool itself, rather the process and procedure involved in testing dependencies.

This project is written in Ruby, and as many have identified in articles and tweets, some project maintainers don’t adhere to a versioning policy, making it hard to ensure working software across multiple versions of dependencies.
A lot rides on the maintainer’s adherence to a versioning standard – one very popular one is Semantic Versioning, or SemVer for short.

This introduces a few other questions, like how frequently should a writer release new versions of code, how frequently should users upgrade to leverage new fixes, features, etc.

In any case, my tool was restricted to running the framework’s version 10.x, considering that between major versions, functionality may change, and that there is no guarantee that my tool will continue working.

A new major version of Chef was released earlier this year and most of my existing projects are still on Chef 10.x, as this is still being updated with stability fixes and security patches, and the ‘jump’ to 11 is not on the schedule right now, so my tool continues functioning just fine.

Time passes, and I have a project running Chef 11 that I want to use my tool with.

Whoops. There’s a constraint built in to the tool’s syntax of dependencies that will report that “you have Chef 11, this wants Chef 10.x and not higher, have a nice day”.

So I change the constraint, install locally, and see that it works. Yay!

Now I want to commit the change that I made to the version constraint logic, but I want to continue testing the tool against the 10.x versions, as I should continue to support the active versions for as long as they are alive and in use, right?

A practice I was using for the tests that I had written was: given a static list of Chef versions, use the static entry as the Chef version for installation/test.

This required me to update the static list each time a new version of Chef was released, and potentially was testing against versions that didn’t need testing – rather I wanted to test against the latest of the mainline release.

I updated my constraint, ran the test suite that I’ve written, and whoops, it failed the tests.

Functionality-wise, it worked correctly on both versions, so the problem must be in my test suite, right?

I found a cool project called Appraisal, that’s been around for a while, and
used by a bunch of other projects, and you can read more about it here.
It allows one to specify multiple version constraints and test against each of them with the same test suite.

Sure enough, passes on version 10, not version 11. Same code, same tests. #wat

So now it’s time to do some digging. I read through some of the Chef ChangeLog, and decide there’s too much to wade through there, rather let’s take a look at the code my tool is using.

The failure was triggering here, and was showing a default value.
This meant that Chef was no longer loading the configuration file that I provide here correctly.

So I took a look at the current version of the configuration loader, and visually compared it with the 10.x version.
Sure enough, there’s one small change that’s affecting me: Old vs New

working_directory? What’s this? Oh, it’s over here, just a few lines prior.

Reading the full commit, and the original ticket, it seems like this is indeed a good idea, but why are my tests failing?

After further digging around in the aruba test suite extension I’m using, I realize that the environment variable PWD remains set to the actual working directory of my shell, not the test suite’s subprocesses.
Thus every time it runs, the chef_config_dir is looking in my current directory, not the directory the tests are running in.

After poking around aruba’s source code, and adding some debugging statements during test runs, I figured out that I need the test suite to change it’s PWD environment variable based on the test’s execution, which led to this commit.

Why is this different? Well, before, Ruby’s Dir.pwd statement would be invoked from inside the running test, loading the config from a location relative to Dir.pwd, where I was placing the test config file.
Now the test was trying to load the config from the process’ environment variable PWD instead, and failing to find the config.

Tests, pass, and now I can have Travis CI continue to test my code with multiple dependencies when it changes and catch things before they go badly.

All in all, an odd behavior to expect in a normal situation, as my tool is mean to be run interactively by a user, not via a test suite that mocks up all sorts of other environments.

So I spent about 2-3 hours digging around to essentially change one line that makes things work better and cleaner than before.

Worth it? Completely, as these changes will allow me to continue to ensure that my tool remains working with upstream releases of the framework, and maintain compatibility with supported versions of the framework.

TL, DR: Don’t skimp on testing you project against multiple versions of external dependencies, especially when your target users are going to be using more than one possible version.

P.S. Shout out to my girlfriend that generously lets me spend time hacking on these kind of things 😀

The Ripple Effect of Choices

We live our lives in a chaotic universe.

Atoms crashing into each other, at crazy fast rates, hyper-vibrations and electric pulses being at the core of our bodies, all working in tandem to get us through our day.
Do they govern our choices? Do our choices govern them? Who is in charge here, anyways?

Many traditional organized religions may express that everything is at the will of a higher power or being, and that we are governed from above.
Some may express that everything is predetermined other than moral decisions, and that is what we are responsible for.

An interesting statement I heard at one point is that “anyone trying to reconcile divine predetermination and free will has a fool’s errand.”

I like to think that I make my own choices about all things, but the subsequent impact of any given choice is pretty much up in the air.

This morning before I left my house, I made a choice of what to wear. Since today I will be presenting a short talk on a professional topic, I chose khaki slacks instead of jeans.

Once I left the house, I had to choose which form of transportation I would take to the office – take a CitiBike, or take one of two trains.

Since I was dressed “nicely” and didn’t want to get all sweaty, the bike option was out. Leaving me with the trains.

Then the choice of which train, and walking towards one of them would bring me to a breakfast cafe where I like to get a morning sandwich sometimes, so I took that option.

I walked in, saw the LONG line for food, and chose to turn around and head to the train instead of waiting. It’s not that great a sandwich anyways.

So I turn the corner, it’s a small alleyway, and a lady is walking about 2 strides ahead of me. I notice that at one point, she pauses, and lets a car coming from ahead pass completely before resuming, and I realize it’s because they are coming at high speed, and there’s deep puddles, s she was avoiding the splash.

A few moments later, another car comes along, and she speeds up, I pause, and try to remain far enough from the splash zone.

Nope.

She looks back at me with a touch of concern, while I’m spattered with droplets from a puddle of unknown cleanliness, and wrings a wry smile, as I smile back at her and say “I should have done what you did!”

Will the water dry? Pretty sure it will. Will my slacks reamin presentable? Don’t know just yet, still drying right now. Did every choice up until this point bring me here? Yes. Was this the universe pushing me here? I don’t think I’ll ever know.
But it did provide me with a new set of ideas.

Years ago, Life Magazine featured a picture (I spent 20 minutes looking for it online, couldn’t find it) of a pedestrian leaping like a ninja to dodge a monsoon-like splash from a passing vehicle, and this experience immediately re-triggered that image. I now feel like I can further relate to that particular image better, probably reinforcing some neural passageway inside my brain of a long-term memory resurfacing.

It provided me with what might call a “New York experience” since this is probably not the first time this has happened in a small alleyway in NYC, and it most certainly won’t be the last.

This short experience also reminded me that you can’t “ever go back and change something”, despite having a Flux Capacitor. If if you could, would you? I wouldn’t.

It also brought to the forefront that all the choices I’m making today were driven in part by choices I made in the past – one fo which was the choice to speak in front of others.

Your life is made up of the set of choices, experiences and hopefully the subsequent knowledge gained from them. It’s kind of what makes you: You, and me: Me. That’s one reason (of many) why we’re all different.

In short, make good choices. Good is a subjective term to you at the time you have to make them. As long as you take a moment at think: “Is this the best choice I could make right now, given everything else I know from before?” then you’ll probably be ok. We make tons of these choices unknowingly every day.

Oh, and what’s good for the goose might not always be good for the gander.


P.S. This blog post was written during my first attempt at the Pomodoro Technique in a cafe. Dunno how I feel about it yet, but it sure worked to hammer out a post in a focused amount of time.