Month: September 2017

Home / Month: September 2017

This little article has the minimal amount of relevance relating back to software development, but instead a recounting of how I’ve had the an opportunity to become friends with two individuals who are utterly changing my world from a musical perspective. This article describes simply my own amazement to hidden talents, and learning an interesting technique while producing & recording a cover with these talented individuals.

Failed Vocals, Sour Notes & Polyrhythmic Woes

I am no vocalist; this is a key fact which friends and family will attest to in greater numbers than I appreciate, but it’s true.

In past projects I had attempted to befriend AutoTune -which was a horrible idea if I may add, so that I could capture various melodies, lyrics and emotions that would fly around my head during the time I should have been studying. Later, when I realized that I should never attempt a vocal rendition of Ah’s Take On Me, I jumped into the electronic music technique of vocal sampling and chopping. This produced wondrously random, yet tangible, results. Though I hadn’t uploaded any of that crop of music to online sources due to other perfectionism issues, I was content with the vocal sampling technique for the sound I was developing for that time.

One issue with the technique above was the lack of control I’d have over the samples or melodies. This is perhaps, due to my inexperience in audio production at the time which resulted in a  ‘well I guess it sounds good enough’ attitude after I’d find a decent glitch-vocal melody. Think The Glitch Mob, Skrillex, Dada Life, or Daft Punk. Think any of those artists, but much less polished.

This issue, snowballing with various other issues a teenager would encounter when they can’t relate to sport programs or science fairs led me to give up entirely on music which had vocals (in any form). I started to gravitate (in the rare instances I would play or produce) to genres such as Ambient, Post-Rock, and Djent. Interesting mix of genres, but they all catered one way or another to the progressive genre which I have quite the affection for when the standard radio tune becomes boring.

Oh You Sing? Prove It.

This is my typical reaction when someone mentions how they love to sing, or they have been taking lessons for years on end. I love to hear their definition of ‘singing’, and also their vocal skill. I am judgemental, as no one should be surprised to hear, but I found this was an appropriate request since I was often surprised and moved by said individuals. More so, I was happy that they could carry a tune much better than I because it could open up the door to potential collaborations and get-togethers in the future.

This method of playing with friends led me to discover one individual’s amazing -and perhaps hidden to the public eye, vocal ability. They are the definition of all I could ever wish that I sounded like. It quickly caught my attention, in consequence the ideas began to pour out onto various notes, chord sheets, and recordings. All of which, revolved around their talents. I do wonder if some days they regret that initial jam with me some days, for I always had new ideas or experiments to try ever since.

Recording a Simple Cover

The above process occurred twice in the past summer, and by fortune both individuals had such a complementary skillset that playing together was inspirational for all. Perhaps I’m over exaggerating a simple exchange of cover songs and various melodic jams, but you have to understand that I’ve been playing various instruments for close to a decade with the minimal amount of genuine interaction with real musicians & talented individuals. Anyone can play Wonderwall.

This inspiration led to us trying a fun no-holds cover recording of Foster the People’s Pumped Up Kicks in the span of a single day. With the instrumentation that we had used, recording the essentials took only a few hours, leaving the rest of the day for perfectionist rerecords, and experiments.

The former is a burden of love which must be dealt with when instrument or vocal melodies aren’t as  desired by the group, and the later is simply me attempting to live up to the title of a producer for fun. That is where I realized that I was recording ‘Winners’, those that see every opportunity to improve themselves; to attempt experiments which are purely based on ideas and sounds that I hear in my head.

With the minimal amount of hesitation or concern, I recorded two talented musicians attempting dangerous harmonies, real-time counterpoint, and even live vocal chopping. All of this can be heard on the final product, and I couldn’t be prouder of the result that the three of us had come to together:

Changing the Perspective

This experience is one which really did grant me a new perspective in contrast to previous projects. In this cover, is the energy & excitement of three individuals who did not know that morning what the final product would sound like; let alone the song that we’d choose to cover! One change to my thought process is the literal idea to let things ‘flow’, meaning to let ideas come and go, instead of trying to confine them to a pre-set rhythm, harmony, or style that I *MUST* have. Instead, these experiments and reinterpretation of the song resulted in a track that encompasses the sound that we wanted, but also allowed for natural growth of the track itself.

Coming from a programming background, I’m a very rigid individual who enjoys schedules, slotted appointments, and routine. This change in perspective was one that I would never accepted had it not been presented in the way that song had done so. Those two individuals, both of which admitted that they had never recorded before, truly did shine through rigid structure and hesitant ideas to create a truly interesting experience. It translates too into the actual song, which I’ve had a close friend describe as ‘a slower, grooved version full of modern nuances’ and another comparing the track to ‘schizophrenic thoughts’. Quite the impressions!

Saving the Off-Takes

While recording with friends in the past, I had heard from a podcast on recording ‘the performance’ the concept of recording 24 bars before the actual punch in. This was, to allow the musician to get into the song instead of being thrust right into the cue point, and in turn perhaps play some interesting tidbits knowing that the ‘fiddly’ sections could be removed in post. I did this for almost all my songs, because it allowed for me to capture the moment before the actual recording which was not anticipated in the context of the song. Some of the projects have muted channels full of little tidbits; out-of-key solos, funk bass rhythms, counter-melodies. They’re great, because sometimes it’s exactly what the song needs.

This idea was used quite a bit on the cover, which results in the way some of the vocal harmonies fight for breath and syllables between your ears and drum fills are manipulated to create a rhythmic pulse in the second verse. Even the piano, which becomes a dominate rhythmic point of the song -with the constant whole bar chords, was simply David just playing the chords while waiting to get to his vocal harmony. Does this mean I potentially have Gigabytes worth of ‘noise’ on most recordings which isn’t present on the final product? Absolutely, but in the end, it’s a trick that I’m glad to have employed in my work flow.

Wow. That is quite the mouthful of a title; a title appropriate for one who’s position is described between an intern and full-stack developer with less than two years under his belt.

First, some background context symbols which will be found throughout the article:

  • ${SD}: Senior Developer
  • ${UD}: UI Developer
  • ${BD}: Backend Developer
  • ${IFUG}: ME. *I Forked Up Guy*

Mistake #1: Return Promise<A, B, C, D>().then(DeliverDemCodes());

Even if you’re the best estimator the world had ever seen, learn as I never did that story ${A} will take an incredibly long time to develop due to stability issues. Acknowledge that ${D}, though perhaps an easy 2 hour task, may result in quite a bit of refactoring of ${C}. Perhaps you don’t have enough resources to even consider ${B} in the timeframe allocated.

In other words, in the world of bleeding-edged production and inexperience, never assume that development is a linear and constant variable.  Regardless of experience, knowledge, sleep deprivation; nothing is ever a ‘simple’ task which can be remedied in a defined time frame.  I was once delayed by two hours because my main workstation -with uncommitted code ready for attention,  decided 10AM would be the optimal time to update it’s security protocols and packages.

Mistake #1 Lesson:

${A} took 3 days, which is what the ${UD} and ${IFUG} expected. We did not expect ${C} to take a good chunk of 2 weeks, effectively causing us to leave ${D} on the storyboard. ${SD} was not mad, but also curious as to how I factored in the original estimation…. I told him I’m horrible at gambling.

Mistake #2: // TODO: Remove Legacy Code From Awesome Project!

You know how parent’s always respond to inquisitive questions with ‘because I said so’? I never enjoyed that as a kid, and thus is helped to form a overly-confident egocentric behavior that I wear at times; instead of asking ‘why’, or ‘should’, I simply do. I do, with zest and vigour. This can translate into questionable decision making skills at times, and even more questionable conclusions to basic logic.

Where am I going with this? Well one day I while developing around ${SD}’s code base with ${UD}, we had noticed a bit of UI work which was used only in a single, non-visible use case which had no application to the current scope. In the eyes of ${IFUG}, and the ${BD}s who were testing our work, it was an eyesore and issue to be tackled.  With precious time before the next presentation, one had to act brash and swiftly to remove the issue; not considering the potential risks / issues it would cause in the immediate future. My overconfidence that this was simply just a dead code from a legacy base was at an all time high, so I commented it out, recompiled, and committed the change.

Even if your IDE claims your code is unreachable / never used… don’t blindly comment it out and commit. When the tests pass, and the features aren’t breaking, don’t pass it off as a ‘fix’ and move on, neglecting to mention it.

Mistake #2 Lesson:

${SD} was not overly pleased with my actions the next day, for it turns out it was his configuration which was used on another branch of the same UI…. I had cost him hours of debugging only for his eyes to see the recent git diff, and discover that this genius right here (${IFUG}) commented out the code which configured his current feature. We had a good talk about that for the next few hours.


It’s very easy to get caught up in the development of a project, even more so when you’re given the keys to build the *arguably* most important layer. In the past few months, I’ve taken on more leadership roles & positions which resulted in my judgement also becoming a questionable state of mind at times. In that state, it’s very easy for flaws to burst through and expose themselves in your decision making skills. Ego, confidence, recklessness, these are the flaws which I had exposed in the later half of summer, and just a few of the lessons that I had to experience to truly understand.

Are ${SD} and I on good standing you may ask? Of course! Only after we established some rules which were settled on with fresh peaches.

Since May, I’ve had the unique experience of working with MEAN stacks on a daily basis, each varying in complexity and architecture to reflect a different end goal. A semester ago, I’d never guessed how little time I’d be spending writing C++, Java, Swift, or even Python applications compared to JavaScript-powered web applications. Furthermore, this is the first time in my life that I’d been exposed to a technology stack not taught at Seneca, which during the time of my attendance examined LAMP, and C# / ASP.NET stacks.


What is a MEAN stack?

Each letter in MEAN stands for the technology platform used – similar to a LAMP stack (Linux, Apache, MySQL, PHP), MEAN stands for MongoDB, Express, Angular, and Node.

MongoDB – The persistence Layer

Express – The back-end layer

Angular – The front-end layer

Node    – The renderer layer


The Learning Experience

I explained in a different blogpost how little I knew of modern-day ES6+ JavaScript, and how easy it was to fall into a spiral of constant peril while trying to learn said new technologies. If it weren’t for David Humphrey’s brilliant instruction, I can imagine within a matter of hours I’d quickly become discouraged to the point of dropping the stack all together. Luckily, that was not the case.



Luckily for me, I’ve only had to learn the basics about MongoDB and how it relates to the data you see in your various mediums. It’s a fantastic NoSQL database tool which really helped me to learn the benefits and downsides to non-relational databases in a variety of contexts.


Having data saved as BSON (Binary JSON) is quite the freeing experience compared to the programmed constraints of SQL-centric databases. Being able to insert entire JSON objects, regardless of the document’s structure, allows for a much more scalable and flexible database in my opinion.


Granted, this depends entirely on the purpose of the database. Need data to remain constrained to preset rules, configurations, and relations? SQL. Need a place to store your marked up blog posts, or to save the comments of an article within the article structure itself? NoSQL!  You wouldn’t want to save one’s most important information for example in a database which doesn’t enforce any constrains natively (though, drivers / mappers such as Mongoose do alleviate this issue very well).



Express was an interesting beast, full of new paradigms and JavaScript-centric programming habits.  Coming from a PHP / .NET background, the flexibility of Express allowed for rapid prototyping and scaling of applications.


In this technology, I also learned how to write proper REST API programs which would power the back-end in the cleanest (at the time) way possible. I’m certain GraphQL (a newer technology which is already taking web development by storm) will become the successor to the REST API back-ends, but for my needs I’m content with the knowledge accumulated on REST practices. My URL end-points have never looked better.


Angular 4

This semester was my first foray into Single Page Applications (SPAs), which have an internal routing mechanism allowing for a single page load to access most if not all of the views. You learn rather slowly just how powerful Angular can be from my experience, because many opinionated workflows and APIs are hidden behind  a seemingly unforgiving platform complexity. Once you learn the basics, such as routing, services, components, child-views, then you realize just how much can be achieved by surrendering one’s self to such a framework.


Angular 4 does have it’s limitations, and this goes back to a similar topic of ‘what is the end goal for this program’? For example, I made my life a living hell by choosing Angular for a project which really, didn’t receive any of the benefits Angular 4 could offer, simply because it was used out of ‘hype’ and not ‘logic’.


Would I recommend learning / using this for other novice web developers? Absolutely! Angular 4 is a hot topic among enterprise and startups alike, and equally valuable for web applications which revolve around a SPA architecture.


Conclusion & Thoughts

If I had to describe the experience in a single word, it would be ‘perplexing’; this is a different word than I would describe the technology stack itself, which would be ‘influential’. There are quite a few hurdles that one has to get through before seeing truly remarkable results, but once one looks back at all the programming paradigms relating to a JavaScript-centric stack that was implemented, I’m certain they’d be amazed.


Working with MEAN technologies for the vast majority of the summer has allowed me to learn quite a few bleeding-edge technologies such as Web-Sockets, Webpack, Web Components, and SPA front-end frameworks. These technologies, though niche to the software developer or desktop programmer, have paved the landscape of open standards which must be supported by browsers, and likewise how one approaches the concept of a modern web application. Open Source advocates such as Netflix have contributed tens of thousands of lines of revolutionary code, all relating to the modern web & it’s various uses to the end user. I truly am grateful that I could immerse myself in such a trend which is transforming the literal internet for everyone, and though communities and developers alike are segregated on the current state of the world wide web, I am forever content knowing what I had learned, and what I was able to accomplish.