Personal Brand – Back to Basics

When I went to work for my current employer I knew they had extreme views on brand protection. There was a line, fuzzy as it was. I thought I could still post about technology without crossing that line. As my job changed this became increasingly more difficult, and about four years ago my already anemic posts dropped to next to nothing.

Earlier this year I began writing and posting again. Even the long gap through Spring into Fall was because I was working on some longer projects. The issue is that none of it has anything to do with my professional life. That has always been the purpose of this site. While I’ve mixed creative and professional, the main thread was always related to my career in technology.

This has all lead me to re-evaluate my personal/professional brand, or lack there of. While I’m still struggling with whether to mix my creative efforts with professional, it’s time to get back to basics. I’m still at the same company, but my work has evolved over time, and I feel I can once again negotiate that fuzzy line.

The Beginning

When I started this site it incubated from some writing I had been doing condemning the superhero culture I saw circa 2005. We celebrated the heroic win when all was lost, when we should have praised those who delivered without issue time and again. It was about the rise of “the villain” as an agent of change. You can see that sentiment reflected in this site, “Malignant Genius: When you think like a genius, think malignant thoughts.”

Fast forward, and some of those old concerns still exist. My company refers to it as the diving catch. Pitching a no hitter is lauded, but forgotten. The diving catch makes the highlight reel. However; we’ve also seen movements such as DevOps, and agile methodologies adapted from manufacturing that focus on fewer defects and better quality. Times have changed and so have I. So where’s a villain to turn?

Moving Forward

There’s a lot of talk about the disruption of technology to move industries forward. This is where I’ll be spending most of my time professionally in the future. While I can’t discuss the tangible work I’ll be doing, I’ll also be helping to define what this means for my team and how we approach the work. It’s this, “disrupt to advance” space that I’m planning on addressing here. Not what the disruptions are, but how do you approach disruption.

I hope folks will find the ideas and topics in this space interesting. Who knows, maybe it’ll lead to a new tag line, “Be the change, think malignant thoughts.”

If you ask an Architect to shovel $h!7, they’ll build you a $h!7 shoveling machine that shovels 20 lbs of $h!7 a minute.
If you ask an intern to shovel $h!7, they’ll shovel $h!7.

Sometimes you need to move product in mass quantities, in a predictable way.
Sometimes you just need to shovel some $h!7.

Knowing the difference can be the key between success, and needing hip waders.

A First Look at Web Components and Object.observe

I had some extended time off during the holiday season and decided to dig into some of the new features that will be coming to ECMAScript[ES] 6 and 7. Specifically Custom Components[ES 6] (Custom Elements, Templates, ShadowDOM, etc.) and the new Object.observer methods[ES 7]. There is a lot of excitement these days for standards and there is some good reason for it. My intent here is not to go into the implementation details of the standards. There are some excellent blog posts
out there that do the job of providing an overview (see links at the end). Rather, what I’d like to do is discuss a bit of why you might care, and touch on some of the gotchas I came across.

As a companion to this post I’ve also uploaded some code resources out on github. This goes with my commitment to make my personal development more open source. One of the projects I’ll be posting is a rewrite of a collaborative research/planning tool I’ve been toying with for the last few years. This version uses custom web components and the new observer methods as opposed to Angular which I’ve been using almost exclusively for the last few years.

What

The suite of functionality that make up web components allows you to develop and share web functionality in a modular and isolated way. Though this is a very simplistic and rudimentary view. There are four basic areas of focus that makeup what is considered “web components.” Each can be used individually, and have many strengths to stand on their own.

  • Custom Elements
  • HTML Imports
  • HTML Templates
  • Shadow DOM

Used together this new added functionality can be quite powerful and opens up new options for sharing code between projects. In fact using web components one could embed one application into another, while allowing the original application team to maintain the code. This is something that currently relies on iFrames to achieve. While it works, it can be cumbersome and buggy to work with.

Now for the new observer methods. One each for Object and Array. Even if you never use the observers directly you should be very excited about them. This makes the observer pattern a first class citizen of javascript, and brings a huge performance boost to data-binding. Currently the frameworks such as angular, knockout and backbone use methods like dirty reads to track when changes happen to objects, which constantly check the status of objects. The early reports on performance tests are clocking 20%-40% gains.

For more information about the details of web components and the observers, please see the links at the end of the post.

Why

“Big whoop. I’ve got an MVC framework that I use, and it works for me. Why should I invest the time to learn all this?” Ok so that last part is bait. <soapbox>Software development is a craft, and as craftspeople we should all be constantly striving to learn the new. It’s how we improve both ourselves and our craft.</soapbox> Aside from that, as a part of the new ES standards you should expect your favorite MVC framework to be going through some major updates in the next few years. Web Components are one of the major reasons that Angular is going to be so radically different in version 2.0. While you can certainly write web code without understanding how your favorite engine works, your applications will be better for having the knowledge.

Another reason is that personally, I’m sick of frameworks, and it turns out I’m not the only one. In my research I came across a small cadre of folks actively advocating the ditching of frameworks. This has been building for a while and can be seen in the plethora of small single use libraries that sprang up a few years ago. These smaller libraries were meant to be alternatives to the blot of frameworks like jquery and others. Take just the libraries/helpers you absolutely need, and leave the rest behind. Over the last year I’ve been able to work with my project teams and have removed explicit use of jquery from all of my projects. However; we still haven’t removed our dependency on frameworks, they just do something different. MVC. We use AngularJS for MVVM and today I couldn’t see working without it. A year from now? Hurm…

Gotchas

Now for some of the downsides. We’re still in the early days of the specifications and the ground may shift under us for a while.

Browser Support

At the time of writing only Chrome supports the observers and web component support is spotty.

Implementation Patterns

Patterns are tough to come by other than one-off usages. There seem to be some patterns emerging, but these are mostly driven by a few big projects like polymer and x-tag. As adoption picks up we’ll see people using them in ways no one is anticipating today, and this will lead to an evolution in patterns and best practices.

CSS

While there are a lot of kewl things you can do with CSS isolation, things get a little funky when it comes to interacting with the shadow DOM. I suggest reading the post shadowdom-201. All of the shadowdom articles are good, but this one focuses on styles, and helps shed some light.

Custom component scope

Managing scope with custom component prototypes drove me crazy for a while. In particular the lack of private variables. I think there are some ways around this, but it’ll need more research. When you look at the sample code you’ll see that I dealt with this a couple of different ways, and the pattern evolved. there’s definitely room for improvement here in the samples.

Observer growth

In Chromes implementation of observers, I noticed that it kept adding duplicate observers with the same signature. With event listeners, if you add another listener on the same object with the same method, the engine is smart enough to know it’s a duplicate and will not add the second listener. I think this may be a bug in Chromes implementation and expect it will be resolved, but I did have to do some extra work to handle it. This is why you’ll see that I use a custom collection object with custom observer notifiers as opposed to the Array.observer.

The Code

https://github.com/strye/web-component-sample

The code is provided as a working example of using the aforementioned technologies in an application. The best way to use it would be to read the article linked at the bottom and then reference the code as examples.

Please keep in mind that the code is experimental. I’ll be making improvements over time and adding more comments as I do.

Links

Getting Started

General Info – http://webcomponents.org/
Custom Elements – http://www.html5rocks.com/en/tutorials/webcomponents/customelements/
HTML Imports – http://www.html5rocks.com/en/tutorials/webcomponents/imports/
HTML Templates – http://www.html5rocks.com/en/tutorials/webcomponents/template/
Shadow DOM 101 – http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom/
Shadow DOM 201 (CSS & Styling) – http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-201/
Shadow DOM 301 (Advanced Concepts & DOM APIs) – http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-301/

polyfills & libraries

https://github.com/WebComponents/webcomponentsjs
https://github.com/Polymer/observe-js
https://www.polymer-project.org/
http://x-tags.org/

The cloud is more than virtual servers

One of the toughest battles I face these days is tying to make people understand that the “cloud” is more than just infrastructure. Modern cloud providers such as Amazon and Microsoft offer a development ecosystem. I think that this is such an important point that I want to state it again. The modern cloud is more than just server virtualization, it’s a full development ecosphere.
Now I’ve used two different terms here that are similar but distinctive. ecosystem and ecosphere. I want to describe what I mean by both. The cloud as a development ecosystem implies a set of open tools that can be used to develop solutions that extend beyond the cloud, while a development ecosphere brings to mind a closed system where a solution never leaves the cloud. Modern platforms provide both options. Large corporations can use the cloud as an extension of traditional data centers, and can and should look at using more than one provider. The ecosystem is typically associated to companies who are migrating to the cloud platforms. Companies who utilize the cloud as an ecosphere are more likely to be start-ups or smaller companies. Typically referred to as being “born in the cloud,” these companies might not have any server infrastructure outside of a cloud provider at all. Email, collaboration, and even the products they sell are fully serviced and sourced in the cloud.
What do these two sibling terms have in common? They both utilize more than just infrastructure. Data storage, messaging, file storage, security, work-flow, etc. These types of managed services that can go way beyond simple virtual servers, are what I’m referring to with both of the aforementioned terms Ecosystem and Ecosphere. Developers have an unprecedented ability to get to market with new software faster than ever before. This can be both empowering and frightening at the same time.

Fact Checking

I’ve been interested in the concepts of event sourcing for several years, and am taking a serious look at it again. I’m frankly a bit dismayed at what I’m seeing on google. On the first results page I’ve found a blog post that refers to event sourcing, and misuses the term. I’m hoping that there’s a translation issue here, as it’s a very well put together post. I suspect French may be the writers primary language. I also don’t have any fundamental issues with the architecture they describe in the post. I’m currently using something very similar, but it isn’t “event sourcing,” it’s Pub-Sub. While you are “Sourcing” events to a subscriber, this has nothing to do with event sourcing, and is already a well established messaging pattern.

We all misuse terms from time to time (I’m a big offender), and as our industry is constantly evolving it can be difficult to keep up with every new term out there. However; if you are going to use a term such as event sourcing in the title of a public post, please do just a bit of research before publishing. A quick internet search would have not only shown the mistake, but also introduced them to a new architectural pattern. I’m not trying to trash the author, hence I am not including a link. Rather I’m speaking of it here, more as a way to keep my self honest. As I said, I’m a big offender.

For those who don’t know what I’m going on about, event sourcing stores system data as a series of events in the order they occurred. While in some cases an aggregate object is created from these events, the events themselves are always maintained in an event store. Aggregate objects can be destroyed and then recreated by reading, or playing forward, the events in the event store. This allows you to recreate an object as it was at any period in it’s lifetime. The basic concept is similar to a source control system, where you can see the entire history of a files check-ins, and revert back to a specific period in time. Event sourcing is closely related to Domain Driven Design (DDD), and you will likely hear people refer to using the events to derive system state, as opposed to a specific objects data model.

The Architecture Journey – Micro Services

The term “micro-services” seems to be everywhere these days. As I’ve been looking into it deeper, my initial impression of it has changed. Mostly because my first introduction was from someone who knew even less than I did. This caused me to dismiss it originally. My mistake. As I’m learning more, it seems to be a natural extension of some principals I’ve always been a big proponent of, such as CQRS. While not the same, it does follow the principal of breaking up monolithic back ends into smaller units that can be scaled independently.

This is a very vague and generic description, but I’m really just beginning the journey. So far micro-services seem to be closely related to the direction I’ve been pushing my architectures over the last few years. I’m hoping I can leapfrog my own thinking on the topic, and evolve at a faster pace. Exciting times. I’ll post more on the subject as I learn, and have a chance to experiment.

PS: It’s NaBloPoMo time (National Blog Posting Month). I was very unsuccessful the last time I tried to do this. Lets see if I do better this time around.