Month: January 2020

Posted on

Passions And Alignment

It’s funny how life works. The highs and lows, ebb and flows are what makes life interesting.

My first career was in live production. Lighting, Sound, Rigging. Doing concerts, theater and conventions. I honestly very much loved that career. I spent the last five years of that career as the Technical Director for a fairly large theater, with a mid-sized events arena, located in a smaller market.

The problem was, being in a smaller market, there was a fairly low cap to my income potential. Eventually, my wife and I realized that in order to make the income I had projected for myself required a change, either moving to a larger market, or changing careers. The biggest downside to moving to a larger market was I would inevitably end up working on the road, which isn’t a great environment for a family, plus my wife prefers the size of community we live in.

Since I had been involved with programming since the third grade, furthering my education in this area was a natural fit. The college I ended up attending required at the time a minor for all students going after a Bachelors degree. While many of my Computer Science compatriots chose a Math minor (which only required a handful of extra classes), I viewed my degree from an investment standpoint. I figured if I was having an issue getting a job as a Software Engineer, there was very little chance of getting a job as a Mathematician, especially with a Math minor. So, I did a minor in Network Administration, figuring there would always be someone needing a computer fixed.

This choice ended up being a wise one. I finished my degree two months after the dot com bubble burst, pretty much killing the software industry in the Unites States. Between 2002 and 2009, I worked as a Software Engineer for about two and a half years. The rest of the time was as a Network Administrator (a few times working as a Software Engineer who also did Network Administration for the companies I worked for).

In 2009, I was asked to help build a pirate themed restaurant. At the end of my live entertainment career, I was able to help build a theme park that was installed in Jeddah, Saudi Arabia. I worked on two contracts for that park. The first was doing lighting, audio, video integration and show control for a “haunted mine ride”. I received a second contract doing lighting, audio and show control throughout all the walkways of the park, and a few specific themed areas.

With that experience, I was able to design the show segments, lighting, audio, special effects and show control for the restaurant. Several of the special effects I build were using small, discrete controllers, based off of the Basic Stamp processor. I had never done this before, and was an enjoyable learning experience.

After a few years working with the themed restaurant, thing started to slow down, and I needed to find other work. I did some contract mobile programming in the interim, but finally went after a full time development job. I ended up getting hired by an airline as a C# developer.

After working here a few years, I ended up transitioning to another company as a PHP Software Engineer. Through some individuals I had worked with previously, I ended up, on the side, starting to build displays for a local Children’s Museum. The museum has a great staff that builds and conceived most of the displays. They use me to add electronics, or build really odd projects. As part of this, I learned how to build interactivity with devices like Arduino’s and Raspberry Pi’s.

In the last six months, the company I was working for and I split ways. I used my side contracts to bring in income during this period (plus a descent severance package), but eventually, my wife insisted I get a regular job again (at some point I’ll do a post on the contracting mindset vs the employee mindset). I ended up as the I.T. Lead Instructor and I.T. Manager for a tech college.

A month and a half after I took this job, the corporation that owns the college (and several others) made a shift in their approach. In short, they decided to no longer take on any more on-ground students, and moving all new students to the online university that is part of their portfolio. They made the commitment to support all current students through graduation, which game my position a specific timeline.

During this time, I’ve been waiting for another project I’ve been helping to design to officially start-up. That project is still coming, but there is no specific timeline yet, and my job here ends in a little over two months. Once again, my wife was becoming very uncomfortable with the unknowns coming up.

Here’s where the stars aligned. My mother, who is also a Software Engineer, has been working for a trucking company for many years, helping with devices to reprogram the vehicle computer (modern version of chipping a vehicle). Several years ago, they came out with a device not intended for deals, but for end users. As part of the project, I was able to design and build a web platform to allow updating of the devices.

After the project, a discussion was had on the possibility of bringing me on full time. My mother was told due to history in the company, they did not like to hire family members. Bummer. I really like the project, and the people I worked with.

Flash forward, and a few weeks ago, they ended up letting go one of their developers. A few days ago, my mothers manager had a discussion with her on finding someone that would be able to program on these custom chip devices. She reminded them I could pick it up pretty quick, but they had said no before. Due to my background, my history with the company, timing, and just plain dumb luck, within a day I was brought in for an interview, and offered a job.

As one of my friends put it, part of it was odd skills they needed, but also was the connection to get me in the door. There’s a lot to be said for that. This is where networking is so important. Don’t pass up networking opportunities, because it is much easier to find a job or a project when you already have relationships.

Posted on

Entertainment Technology Convergence

For those who came to this blog from the I.T. industry, the focus on the entertainment industry may seem a bit odd. What most people that don’t work behind the scene’s in the Live Entertainment industry is that the technologies used have become more and more tightly integrated with an I.T. based backbone.

When the Disney Corporation built Disney’s Animal Kingdom park in the late 90’s, they used a new technology (at the time) by the company Digigram called CobraNet. For the uninitiated, CobraNet was an early Audio Over IP technology that allowed up to 64 audio channels to run over computer network segment.

A few years later, when Disney built Tokyo DisneySeas, they put in a gigabit backplane throughout the park, specifically to handle the standard data as well as CobraNet traffic. This allows Disney to have a central control room, and push out all the audio to speakers from there. The way the technology works, there is a specific few millisecond of latency added at each router, so they are able to calculate the timing to keep everything synchronized to the frame.

Over the years, CobraNet was replaced with CobraNet 2. That technology has lost market share to Dante, as well as several other Audio Over IP technologies.

Around the same time that Audio Over IP was making headway, work was being made in the lighting industry for controlling concert lighting over IP networks. Leading up to the mid-80’s, just about every company that made theatrical dimmers used their own proprietary control system. In the mid 80’s, industry leaders finally got together to define common protocols, so equipment would be interchangeable (and much easier to cable).

Two protocols came out of that first consolidation: AMX192 and DMX512. Obviously, AMX is an Analog based protocol, and DMX is a digital based protocol. Eventually, almost all the theatrical control systems moved over to DMX (especially as programmable moving lights became prevalent in the industry).

Fairly quickly, DMX was being stretched to the limits of its capabilities. In response, companies started coming out with proprietary protocols for running DMX over IP. With time, a handful of protocols started to dominate the industry. Eventually, again, industry leaders came together to define public protocols, in attempt to standardize the industry.

Currently, the leading proprietary protocols are ShowNet, Pathport and Sandnet. The public protocols are ACN, ArtNet and ESP Net. All of these run over IP networks, and can exist over the same fiber connections as the Audio Over IP devices (running on separate VLAN’s).

Posted on

Imitation, The Highest Form…

As a child, growing up in Southern California, we would go to Disneyland with a certain degree of regularity (being only about an hour away). Even with the somewhat regular schedule of attendance, when I knew I was going to the next morning, I would have great difficulty falling asleep the night before (almost as bad as trying to fall asleep on Christmas Eve).

As I expanded my knowledge of technology, through my adolescence, I began to view the rides, both the new creations, and ones I had been on hundreds of time, with a view of how these creations were created, how the technologies were harnessed to tell the varied stories. It didn’t help that I had a leg up on the basis, being raised in the Movie industry by a Father who did Special Effects professionally (I was introduced to the “Anarchist Cookbook” at an early age – the original – to assist in building explosives for use in a movie).

Between this odd background, and the many years I spent studying music, eventually led me into the live entertainment industry – specifically, lighting, sound, video and rigging for concerts, conventions and special events. In the late nineties, my Father was contracted to add Special Effects to “The Hidden Mine Ride” at a new theme park, “Jungle Land at Mersal Village” in Jeddah, Saudi Arabia (renamed the “Lost Mine”). I ended up being contracted to do the lighting, sound, video integration and show control. Later, I was asked to do lighting, sound and show control throughout the park walkways and a few special features. I’ll probably do a series of posts about this project later.

Several years after completing the installation of Jungle Land, I was hired to design and install theming for a Pirate themed restaurant, “Pirate Island Pizza” in St. George, Utah. I also designed the theming for the second location, though another group was hired to do the A/V installation. Later, when the corporation bought the store back, I had to maintain the cheap, hacked home automation system with cheap Chinese theatrical lighting (the equipment I used was all theatrical and industrial level systems, meant to last for years).

During the design phase of the project, I did many visits to Disneyland, specifically, the “Pirates of the Caribbean” ride. Specifically, I would look to see the lighting and audio techniques the Imagineers used (if you get a chance to go, look back every few minutes, especially if you’re sitting in the front of the book. Pretty soon, everyone will be looking back when you look, to see what you’re looking at!).

I also “borrowed” the concept of the thunderstorm the “Rainforest, Cafe”. I do believe mine read better though. With the audio controller I used, and with my lighting design, I would have the storm start back corner of the restaurant, and roll through to the front. We also created a canon fight between our faux ship, and a “fort” we built.

Unfortunately, neither of the pirate themed restaurants exist any more. They were a lot of fun to design and build (and stretched me quite a bit. I was sitting down with the founder of the Pirate restaurants today, and he showed me a video of a pirate themed restaurant in France that “borrowed” a lot of our design for their restaurant. Their ship wasn’t as tall as ours (forcing the cannon heads to be aimed up, so as not to blast the patrons in the face with smoke), and their lighting design was very rudimentary (some of the lighting looked good, and some quite bad). And the dialog for the pirates is just annoying.

They even used the skull cave entrance to the arcade. It opened up about two years after we opened our first restaurant (and we just found out about it). Well, they do say that imitation is the highest form of flattery. And I do give them credit for integrating live actors with zip lines. It’s just hard to see someone take my artwork. While I was taking someone else’s. Ya, it’s a hypocritical loop. Oh well, just got move on.

Posted on

Moving to Agile

As I wrote in the last posting about Agile, truly moving to Agile development requires a buy in from company hire ups. In our case, we knew we had to change directions. There were lofty goals ahead of us on what the business was asking for in the platform we were creating. Way more than three engineers could handle.

Our current operation just wasn’t scalable. The founder, who had, among 50 or so other hats, was acting as the product manager and the QA manager. To give full credit, he did start with an idea, and hired contractors to start his vision. He had started long before the Atlassian stack exited, let alone other tools. He had learned to organize his operation through the extensive use of spreadsheets (and he loved the Google stack).

When our new CTO came on, during the testing cycle of last waterfall iteration, he saw the chaos that was our testing scheme. The system had become large enough, and inter-twined enough, that his testing spreadsheet had over 10,000 tests on it. A lot of support engineers, along with us developers spent quite a few late nights running through the tests, to get a release done we were comfortable with.

On top of that, the current platform required a build. The only system that could do the build was on the system of our most senior engineer, who lived in Canada, not the Southern United States. As you can see, getting to done was a monstrous task, and we knew we needed to ramp up the number engineers we had working on the product.

This shows one of the huge strengths of Agile. It’s built for scale. And since as a team, you focus on breaking down the projects into small tasks, accomplished and tested quickly, you eventually get rid of the huge testing cycle (admittedly, getting to that point takes time, but you’re able to shorten what is tested based on what was worked on).

As we were educated on Agile, we were also introduced to the concept of Srum. In a few weeks, after finishing the last release, the CTO started hiring more engineers, and got us working in the Scrum format. Really getting into Scrum took a little bit of time, since along with hiring more Software Engineers, the CTO also had to start building a QA team, as well as a Product Development team.

For those new to Scrum, a Scrum team consists of 3 to 8 Software Developers, a QA Engineer, and a Product Manager. Over time, we came to learn, in our teams, the ideal number of Software Developers was 5.

We were introduced to the concept of breaking projects into a series of “stories”, and weighting the “stories” with a point basis. The point basis is a numerical description of how hard a task is. The idea is, the entire team points the stories, discussing and debating the weight, until a consensus is reached. Once all the stories are pointed, team members choose what they are going to work on over the next iteration, called a sprint.

One of the genius points of Scrum, is that is it supposed to be self-organizing. There is a designated “Scrum Master”, who leads the team, but not from an authoritarian stance. The value of the points are supposed to grow organically (though we did end up adopting a standard hour-value for a point, to make it easier for management to project timelines and efficiency).

Since team members choose what they are going to work on, they are in essence committing to the rest of the team that they will have the tasks completed within the next sprint. The length of the sprint is arbitrary, and our teams chose to make each sprint 2 weeks long. The tasks were not considered complete, until after the QA member of the team had tested each tasks, and product management had accepted the work.

As we were making the evolution to full Agile and Scrum, we broke into two teams: a team specialized to a very unique set of code (which I was on), and the other, larger team, that did more generalized work. The other team investigated build systems (to free up our most Senior Engineer, and to protect the company in case something ever happened to him), and also investigated frameworks, since our code was old enough to be very custom.

One other thing the other team worked on (other than code enhancements) was creating coding standards for each language we worked in. Unfortunately, since all these major enhancements were being done by the other team, while my team was neck deep in new code, we were always playing catch up after the fact on learning these technologies (and never did have a say in the accepted coding standards).

One other change that happened very quickly was moving our development process to the Atlassian stack (even before investigations into the build systems occurred). I was so thankful to get away from all the spreadsheets, and start using a Scrum board. Eventually, as our teams grew out, there was one team that was working on integrations for our front end system that chose to use a Kanban board. This also meant moving away from SVN server (which had served us well for many years), and moved over to Bitbucket (a GIT based system, focused more on private repositories rather than Open Source repositories – also part of the Atlassian stack).

When we first started doing Scrum, our CTO acted as our Scrum Master. Over time, as he was getting spread wider in his responsibilities, those who chose to volunteer to become Scrum Masters were sent off to classes to become Certified Scrum Masters. I was one of those. As our CTO said, not all trainers were of the same value. The one he recommend, which we went to, was a group called “Mountain Goat”. If you are interested in becoming a Scrum Master, I highly recommend this group (I don’t get any kind of kick back for saying that, or linking to their site – I really mean it!).

For those interesting in learning Agile development, here are a few suggested readings:

Learning Agile: Understanding Scrum, XP, Lean, and Kanban

Scrum: The Art of Doing Twice the Work in Half the Time

Scrum Mastery: From Good To Great Servant-Leadership

Posted on

Hard Things

As part of the journey I’ve taken in self improvement, one of my mentors have a list of hard things to do. The concept is that if you force yourself to do hard things, when life throws curve balls at you, they will seem easy. You can’t do hard things once. It’s a workout, sometimes physical, more often mental. And just like going to the gym, you can’t go once a year for two weeks, and expect to have any long lasting results. You need to create a pattern, a habit, and follow that pattern again and again to see the growth.

There are quite a few hard challenges that involve exercise. Specifically running. Well, that’s out. No that I’m lazy. I used to enjoy running quite a bit. Until I blew out my ankle in a theater rigging accident. Can’t run now. On the exercise front, I have taken the challenge from exercising once to twice a week, to constantly exercising three times a week (I plan to eventually move to five days a week, but really need to build up more endurance to be able to do that. I’ve only been going to the gym consistently at all over the last four months).

One of the other challenges is to create a blog, and write in it at least once a week. I’m combining that with another challenge of writing at least 1,000 words a day for a year. So, sometimes I may post more than once in a day. Maybe I’ll prep several posts to happen in a week. Sometimes, the writing will be private correspondence. I do plan on achieving these two goals.

Another goal I’m looking at is starting a YouTube channel and make a video every day. Well, I already have a YouTube channel (https://www.youtube.com/user/litemizer), though I haven’t done much with it. I’m obviously not afraid of getting in front of the camera. I’m just not sure what subjects I’d cover. Reading the posts in my blog would be pretty boring (both for the me and the audience). Hopefully, I can come up with some ideas for content, so I can follow up with that goal.

Many of these goals are intended to creating a rhythm of doing hard tasks. Some are to feel the elation when goals are completed. Several are both. I’m very interested in seeing where this goes.

Posted on

Agile Development

A lot of talk has been given in the last 10 years to the concept of Agile Development. Since it’s creation in 2001, it has swept the software engineering industry. I remember first hearing the about it back in 2013. I was working as a Software Engineer as a C# developer. I was getting ready to take some time off, and my manager had mentioned she wanted to investigate Agile development, and incorporating it in our team.

I did a quick search for something on Agile I could read while on vacation. I stumbled on the book, “The Phoenix Project”. While not specifically on Agile, it gives a great basis on flow constraints. It’s an easy read, and really opens up the mind on how to spot bottlenecks in a flow process, and how to alleviate them.

In a lot of ways, this is what Agile development is all about. For years (and even for a lot of companies is still the normal flow), the way we developed was what was know as “Waterfall Development”. You spend a lot of time designing every minute detail of your software, get approvals, go back, refine the design, get more approvals, and finally, start coding. Once you’re done coding, you test, fix, test, fix, blah, blah, blah. Eventually, after several months, you release a finished product. And then you go back, and start designing again.

This flow has several huge draw backs. If there is a need for your company to shift directions, and you’re halfway through the development phase, how do you, as a company, react? Do you drop what the developers and project managers have spent weeks to months designing, and start over? Do you let part of your developers finish what’s been started (making the process even longer)?

From a current industry approach, is releasing software once or twice a year acceptable? Is this maintainable if you’re build a cloud based platform?

These questions, and a million more like them, are why Agile is taking over. Any SAAS platform that is doing Waterfall development will never be able to keep up with their competitors. The concept of CI/CD (Continuous Integration and Continuous Delivery) cannot exist in a Waterfall environment.

When I came back from vacation, my manager did her best to implement Agile. Looking back, she didn’t have the training and understanding to really implement Agile. I give her huge credit for trying. It’s very difficult to move to Agile without the buy off the upper management of a company, and it’s hard to get that buy off if you don’t fully understand the framework. And none of us really did, so we really only integrated a small piece of Agile.

The next company I worked for started out very small. They had been around for quite a few years, and the primary product was starting to get some maturity. I was the third engineer hired at the company, and it was definitely a Waterfall approach. Over the first year and a half I was there, the company saw remarkable growth, which included building out a large dev team. One big issue with Waterfall is that it doesn’t scale well.

As the company grew, the founder was getting spread to thin, and so a CTO was hired. He was well versed in Agile. He came in just as we were going into a debugging session before a release. He watched us struggle with the thousands of tests required to ensure full integration worked seamlessly. As the next iteration began, he began to integrate Agile and Scrum into our operation flow. While it took a while for us, as a dev team, to really get up to steam on the mindset, once we did, the amount of quality work getting completed skyrocketed.

My next post will delve into how we moved from Waterfall to Agile, and some of the hurtles we had to overcome.

Posted on

New Focus

A while back, I read a great book called “Think and Grow Rich” by Napolean Hill. This great book was written back in 1937, and it’s truths have inspired countless generations. It is a study of the great economic minds of his time, taken over 20 years.

One of the recommendations given in this book is to find proper mentors. Sometimes, this means finding these mentors by studying about them and their lives, if you don’t have the ability to have a one-on-one relationship with the would be mentors.

Through this recommendation, some time ago, I started following John Sonmez, creator of the Simple Programmer blog, and the Bulldog Mindset blog. He has been a great resource of information for developing myself, both as a software engineer, and as person.

One of his recommendations is create a blog to promote myself, which is the purpose of this website. In fact, he has a course specifically on doing this (and a few other courses geared towards software developers) which can be found here.

So, this blog will be about software development, as well as theme park technologies (another passion of mine), and occasionally some tidbits from my past life in the movie industry and live entertainment industry.