explorers' club

explorations in dev, science, sci-fi, games, and other fun stuff!

Leave a comment

My Developer’s Toolbox

After a moment of pause & introspection, I realized I tend to be wordy and long-winded.  So rather than have a paragraph or 5 of WHY and HOW, I will just make a list and go from there.

IDEs, tools, things

  • WebStorm – for all things non-Adobe related, this is my JavaScript, HTML, CSS, etc. IDE of choice.
  • Flash Builder – for all things Adobe, this has been a great tool for years, built on Eclipse with plugins for SVN, Git, etc.  Love it.  I won’t be going further into anything Flex/Flash related unless requested.
  • Sublime Text 3 – shell scripting, quick looking files, XML, has a super neato feature where you can actually edit multiple lines simultaneously.
  • Git – at first I was very weirded out by Git. It had all the familiar vernacular as SVN (branch, tag, merge, commit, etc.) but the meanings were different. After taking a nose dive into it, I LOVE it.  Super easy to use, the command line is easy enough that I rarely use…
  • Source Tree – this is a Git GUI for Mac.  Somethings are better left to the command line, but for those edge cases, I like this app.
  • GitLab – not a tool per se, but an alternative to Github with private, free repos.
  • Github – free, publicly hosted Git repos.
  • Gist – this is Github’s flavor of a pastebin with the ability to fork it.  You are starting to see many stackoverflow posts utilizing this to debug/debate code
  • Mou – a markdown editor/viewer app for Mac.


  • node js - server-side js, powerfully simple with an ever-growing ecosystem.
  • npm – stands for node package manager, a command line API that comes installed with node for fetching node package resources.  Powerful stuff folks.
  • bower – a npm module that sorta does the same thing as npm, but client-side-oriented. Better-put, it’s a resource management tool.
  • require js – an asyncronous dependency loading library based on AMD.  I’m not a big fan of the AMD API as it seems verbose compared to CommonJS’s API but it’s a great utility for keeping your code modular and it’s easy to debug with.
  • browserify – a npm library that allows you to build an app much like require does, using the CommonJS’s API, but rather than loading things async, it traverses the dependency tree and compiles a single javascript file for use in the browser.  I’ve only begun to realize it’s potential as it also allows access to many node.js modules out of the box.

I’m sure I’ve missed a few.  But this is my toolbox overall.  How does your toobox compare?

Leave a comment

Bundles up your Git’s working copy changes (compared against HEAD)

Rather than give a history of why I’m doing this, I’m going to skip it and just post the code.  If there is a built in Git command that grabs the working copy (meaning non-committed changes) please let me know.  In the mean time, this will suffice.  


  1. It’s a (bash) shell script so usage would mean you open your bash shell (Terminal on Mac)
  2. navigate to the Git project
  3. type . ./create-bundle.sh

the actual script


Easy Way to Delete a Sparsebundle from Time Machine

I have had a Time Capsule in service for over 4 years.  It has been used to backup my old personal mac, my current personal mac, 2 work macs and my mom’s mac.  I’ve since updated from Snow Leopard all the way up to Mavericks, my old personal mac died (pre-solid alum body MBP 2008 era had known integrated video card issues, this one went through 2 of them), I’m no longer working for either of those companies and haven’t access to the computers and somehow my mom’s backups have been corrupted.  So…. I need to kill 4 of the 5 sparsebundle files.

This solution is going to be super quick.  You need to be comfortable with using the command line and have some patience.  When you’re deleting several dozen GBs of data, things can be slow to start.  Ok here are the steps:

  1. understand that what you’re doing is not orthodox and that it’s irreversible.  If you’re not comfortable with that idea, I’d not do this.
  2. grab a ethernet cable
  3. connect your computer to the Time Capsule (TC) with said cable
  4. make sure you can see your TC from within a Finder view in the sidebar
  5. open Terminal (either navigate to Applications -> Utilities -> Terminal or hit ⌘ + space to open Spotlight and type “terminal” and select Terminal from the list)
  6. in terminal type:
    cd /path/to/sparsebundle

    in most cases it will be located here:


    If not you can type “cd” then from within the Finder, drag the sparsebundle into the terminal where it will fetch the path for you.

  7. now the next step is where a little bit of patience is needed.  Nothing sucks more than dealing with something you’ve been banging your head against for ages only to think you have a solution and it doesn’t even provide feedback.  in terminal type:
    find ./bands -print -delete

    in some cases you may need to type:

    sudo find ./bands -print -delete

    which will prompt you for your password

  8. this is basically getting  a list of everything in the sparsebundle’s bands folder, prints it out in the terminal (which is your feedback to know SOMETHING is happening) and then it deletes them one by one
  9. you can now safely delete the sparsebundle without affecting another sparsebundle by typing:
    cd ..

    which backs us out of the current directory and then

    rm -rf ./Your.sparsebundle

This should really go without saying, but I’m not responsible for any harm that comes to your computer, data, sanity, whatever from following these steps.

Leave a comment

Problem Solving: Finding Whole Cubes Within a Range of Integers

My intent is not to provide an answer per se, rather it’s to provide insight into the way I think and to foster discussion.  Copy & paste at your own risk.

This the 2nd of 3 tests that I recently took in applying for a developer position.  Due to copyright restrictions I cannot post the problem here verbatim.  I’ve substituted certain values and names.  I can give you the gist (both :) here:

the problem


  • the input value X  is within the range  -2147483648 to 2147483647
  • the input value Y  is within the range  -2147483648 to 2147483647
  • X <= Y


Write a function

function solveIt(X, Y);

that will return the number of whole cubes within the range of integers X and Y, including X and Y if applicable.

the solution

my thinking

Sometimes the simplest solution is staring you in the face but like many developer issues of the Computer Science flavor, we developers can’t seem to see the forest for the trees.  I knew this was one of those problems.  Rather than attack this code-first, I decided to detach myself from my developer role and approach this as a word problem given to a high-school student.

The easiest way to find the nearest whole cube’s root is to just try to find the cube root of a number.  Since we’re working within a range we can assume the following:

  • negative numbers will have a single negative cube root (rather than try to deal with NaN results, imaginary numbers or other mathematical anomalies, keep in mind Math.pow(-n, 1/3) returns NaN)
  • if the cube root of a number is an integer, then the number is a whole cube otherwise
  • for the lower range’s number we need to round the cube root up (Math.ceil)
  • for the upper range’s number we need to round the cube root down (Math.floor)
  • negative numbers can be treated as positive values given the first assumption (which I make use of by recursively calling my solveIt function)


core solution & float fix

w/ quint tests

Leave a comment

Problem Solving: Random Rules & Regexp (JavaScript)

My intent is not to provide an answer per se, rather it’s to provide insight into the way I think and to foster discussion.  Copy & paste at your own risk.

This is one of 3 tests that I recently took in applying for a developer position.  Due to copyright restrictions I cannot post the problem here verbatim.  I’ve substituted certain values and names.  I can give you the gist (both :) here:

the problem


  • the input string P can have a length of 0 – 50000
  • the input string P will only consist of the characters X, Y and/or Z


Keep in mind that this is my interpretation of the task at hand.  While it’s unfortunate that I can’t recreate the test verbatim here, I can say it was very explicit, but did leave room for interpretation.  Without further ado…

Write a function

function solveIt(S);

..such that, if any transformation applies, pick one at random, transform the string, and continue the process until no transformations are applicable.  Now where there is some room for interpretation is in the transformation rules.  An example of a transformation rule looks like this:

substitute some occurrences of “XY” with “XX”

As you can see, the word “some” could be interpreted differently.  Rather than overthink that part of the test, I assumed they meant to apply the transformation to any & all occurrences.  I think the coding difference is rather trivial at this point.


  • XY -> XX
  • YX -> XX
  • YZ -> ZZ
  • ZY -> ZZ
  • XX -> X
  • ZZ -> Z

the solution

Leave a comment

Thoughts: MutationObservers, MutationEvents & Element.prototype hacking

I recently presented some code on a video/screenshare interview.  In the code, I had decided to eschew solutions like Backbone or jQuery and roll my own solution.  This was partly to learn more about how things like Backbone & jQuery work internally (or at least attempt an educated guess at it).  But it’s also part of my psyche, I like not only using my tools, but knowing how my tools work.

rough draft

To dive more deeply into what I had attempted I will list it out how I got it working:

  1. app loads and triggers a DOMReady event via require.js’s DOMReady plugin.
  2. the view’s module in question does the following:
    1. loads it’s HTML fragment
    2. does a recursive check to see when the actual DOM element has been appended.  This recursion uses some simple getElementByID checking, if it’s there proceed, if not wait 100 ms and check again
    3. once appended to the DOM, calls a addedToDOM method

So very hacky, very homebrew and very amateur.  But it worked and since that was not an important part of the app per se, it stuck and was left to fester.  The basic premise is I attempted to take an HTML fragment (kinda like Handlebars, Mustache, ejs, etc.), combine it with some View-type logic (kinda like Backbone’s View) and trigger an API of sorts.  Pardon my lack of webdev nomenclature here.  I’m still broadening my vocabulary.

Now in the interview I was commended for my solution considering my experience with DOM-oriented javaScript.  But then the folks said that since I was purposely avoiding solutions present in jQuery or Backbone that I should check into MutationObservers & MutationEvents.


I’ve looked both in MutationEvents and the newer MutationObservers since my interview.  Both are exactly a solution I could have used for my problem.  While I went ahead and skipped prototyping out anything with the MutationEvents (hereinafter referred to events), I did do some hacking with MutationObservers (hereinafter referred to as observers).  The nice thing about the observers route is you can narrow down a part of the DOM tree that you want to watch changes on.  You don’t necessarily have to listen to the whole document, which in a bigger application could be a performance issue.  In fact, that was what prompted the change from the events route to the observers route.  However if you go on StackOverflow, you’ll see that plenty of folks argue that the newer observers API is wonky and hard to get a handle on.  I think the new API is pretty solid and offers quite a bit of information.

forward thinking

After doing some piddlin’ with observers I started to see an issue with what I was trying to accomplish.  The problem that comes about from trying to use observers is that in my case, I don’t have a clue what parent node/element is going to need to watch for childList changes.  I could use the body or a root div tag to do that, but then I’m observing pretty much the whole DOM which negates the advantages of observers.  I might as well be using the MutationEvents if that’s the case.  So I did some brainstorming.  Coming from an actionScript background, any DisplayObject can and will fire addedToStage and removedFromStage events.  So triggering any logic contingent on being added or removed is as simple as adding an event listener for those 2 event types.  I was really surprised to see that that functionality was not built into the Element API (or if it is and under a different name, I have yet to find it).  Ergo my silly rough draft solution and subsequent investigating of the events and observers solutions.  But then I decided to poke around a bit more and thought “why can’t I MAKE an API similar to ActionScript’s DisplayObject stage-related events?”.

my hack

I should preface this hack by saying I don’t necessarily understand ALL of the pitfalls of this approach, but I do get that it could be problematic.  Anywhoooo….  My approach is basically overriding the existing appendChild and removeChild APIs on the Element.prototype.  AHHHHHHHHHH yes I know, terrible.  But check it out and maybe it won’t be so bad?

All I’m doing is storing the existing APIs, overriding them, calling the old ones and checking to see if addedToDOM or removedFromDOM functions exist on the child element being manipulated.


Well the obvious pitfall is that if you’re working with another library that might be doing something similar, then there is that chance that it’ll break.  Then again if you have another library looking for functions named “addedToDOM” or “removedFromDOM”, chances are you’re not using this hack.  The other pitfall is this: There IS a difference between Nodes and Elements.  That difference is beyond my knowledge at this point but I could see some issues arising from this.

Please comment on this.  This is a learning journey for me and I learn best by making mistakes, piddlin’, making more mistakes and hearing what my friends and colleagues have to say.  Thanks.


Thoughts on JavaScript: A Paradigm Shift


Over the last 2+ months, I’ve been doing quite a bit of soul searching.  Mostly I have been evaluating my desire to stay in the IT game.  With the demise of Flash I’ve been really struggling to get enthused about learning JavaScript.  This is my semi-educated first and subsequent impressions of JavaScript and really more of a journey to my thought processes and rationalizations on WHY I should just suck it up and learn this quirky, frustrating, kinda-cool language called JavaScript.

At first blush

When I first decided to take the plunge and start learning javascript, I’ll admit I was less than enthused.  Javascript has been around in some form or fashion since the 90s.  It’s not a real object oriented language and achieves pseudo class inheritance via it’s reliance on a prototype chain + plenty of wonkery.  For any seasoned Flash/Flex/Actionscript developer this seems like a step back to AS2 or AS1 even.  It lacks strong typing.  It’s subject to per-browser quirks.  While being “standardized”, it seems Microsoft, Apple and Google all want to seed the path of progress with various APIs and styling idiosyncrasies .  With all these reasons anyone with a similar background could appreciate my reluctance in learning it.

But alas the tides are shifting.  And so are my attitudes.

The good ol’ days

I generally subscribe to the ol’ idiom “If it ain’t broke, don’t fix it”.  Ergo my initial attitudes.

It used to be that any real application had 3 components to it: the client which was user-facing, presenting data and receiving user input; the services that interpreted said user input and forwarded data; and the data which resided in, yep you guessed it, the database.  Pretty basic application programming oh let’s say for the last 10-15 years at least.  Generally these 3 separate components were comprised of 3 separate technology languages.  Whether it be a Flex-Java-Oracle system or an HTML-PHP-MySQL system, it generally required 3 specialists to work on the individual components and to work in concert.  Anyone with experience in an enterprise-development environment knows the plethora of problems that arise from supporting legacy data and legacy services with an ever evolving client.  Looking further into the HTML-PHP-MySQL system, you ofttimes have PHP services serving up client side code.  Basically the rendered client was assembled on the service layer.   In a case like this, you’re blurring the lines of responsibility and are actually committing an OOP no-no!  You’re coupling your design to your service layer.  Thinking back, I can now appreciate why it always seemed that as a client-side developer, we were always waiting on the service guys to catch up.  They had to unravel the mystery of legacy code in order to serve pure data to a Flex client.  Sorry guys if ever I seemed impatient.

Paradigm Shift

But that’s all changing.  Now I may have my facts a little skewed or screwed but I think I have the big picture right and here it goes.  Thanks largely in part to technologies like iOS’s dis on the Flash, Nodejs and a move away from SQL-based databases, we start to see technology stacks in pure javascript (aside from some DB specifics).  Now we can have a client written in javascript that talks to a services layer in javascript that then hits a DB that stores data in big ol’ fat JSON-ish objects.  While I can’t speak to the technological pros/cons of such a technology stack, I will state the obvious – JavaScript is here to stay.

As a Flash/Flex/Actionscript developer, at first that chapped my hide, royally I might add.  But in retrospect, I see the value in it.  I’m pragmatic and from a numbers game, it makes a whole heck of a lot more sense to have a common language serve as the core/majority of your technology stack than it does to have 3 or more distinct languages.  From the human perspective, say I’m an expert javascript client-side developer, the ramp up time to help hop onto the service layer written in js is significantly lower than say me as a Flex developer having to hop in and start learning all the ins and outs of PHP or Rails or Java.

Some advantages

In the previous point, I already listed that you have more reusable skill sets that can be applied.  As a client-side developer, I WANT to be more versatile.  And prior to this opportunity, the opportunity costs for entry into the realm of a server-side developer was very high.  Now I can take what i learn as a client-side JS developer and go hop on the node services.

The next advantage is the cost of entry is low.  I’m sure I won’t win any fans with this statement but JavaScript has a low cost of entry.  I’d probably not call it an elegant language (yet).  There seems to be TOO many ways to do something, most of them very cumbersome.  But any Java, ActionScript, C* developer will probably feel at ease diving into the code.  I can’t speak for Rails, PHP or other folks but from what I have heard, they seem to have an easy time learning JS too.

Next up: Javascript is forgiving.  Or rather the browser is.  Now this can be a huge point of frustration as debugging things that just don’t work because the browser decided to eat the error.  But in most cases, if you’re careful, you can write some pretty gnarly JS code and still have it work.

It’s everywhere.  So if you add up all the iPhones, iPads, iPod Touches, Android phones and tablets, pretty much any computer sold in the last decade, you can make a safe bet that Javascript came with the installed browsers.  So it’s ubiquitous.  I’d be interested to know the penetration states of say EcmaScript 5 compliant browsers vs say Flash Player 9 or 10.  Considering the explosion of iOS and Android in the last 3-5 years, I’d say JS beats Flash Player’s what? 98% penetration stats?  I’m taking a wild guess so if you have actual numbers, fire away.  This is today.

Used to we spoke about refrigerators, microwaves, coffee machines and other non-computer appliances with some sort of embedded Java interface.  I’m sure in the very near future if not already today, there are appliances being made with Linux & apps/interfaces being built with Javascript.  This will be very appealing to non-computer tech companies who want to jazz up their UI without investing too much in proprietary software.  Embedded technology can be cheaper and have a lower point of entry via Javascript.

Lastly, why code to multiple platforms when you can code once.  That’s not to say you won’t have per-platform specifics but if you can code 98% of your application in one source and then have platform specifics left to the last 2%, I’d say that’s a net win.  While I appreciate the advantages that native code for iOS and Android provide, in terms of many of the aforementioned advantages for jS, you really can’t beat it.  Gaming is probably the only example that I can think of where going native is your best bet.  Most users aren’t going to notice the 2-3ms difference because the browser takes a tad bit longer than the native touch interpreters.  We’re talking the 98% here.

The sapling

So you probably think me a JS fan-boy.  Not at all.   I think Javascript has so much room to grow.  With EcmaScript 6 coming hopefully soon, we can see less design-wizardy and more development common sense.  Built in module APIs, interfaces, some sort of more-class-ish APIs, yumyum.   JavaScript also allows you a level of freedom that I never had coding in Actionscript.  All of the sudden I find my right pinky hurts less because I’m typing less colons & semicolons.  OMG!!!!

Really it boils down to this: I’m pragmatic.  Either I can be the tree that bends with the wind or I can be the tree that breaks in the wind.  Whether you like it or not, Javascript is here to stay for a good long while.


Get every new post delivered to your Inbox.