About Barrett Sonntag

Google+

Creating and Taking Ownership of Your Personal Brand

In the beginning

When I began programming it was a solitary pursuit. I didn’t connect with any other hobbyist or professional programmers for several years until my first real job. At that same time I bought this domain without an idea of what I was going to do with it. I remember the desire to claim a space online, and to create a personal presence. This wasn’t my first domain, and I regret not continuing the pay for my registration of older domains. I remember someone I didn’t know well coming up to me in high school and asking why my site wasn’t live anymore. At that point I realized I could have an effect on someone without ever knowing them; simply by publishing my own presence online. My personal brand uses my own name: Barrett Sonntag.

Our modern development space is an open book

During this time Linux was fighting for enterprise respect while being created by countless programmers from all across the globe for the love of creation. I watched this open source software movement being vilified and fought. Any developer today can look around, look at GitHub, and see just how much benefit open source software has brought to our chosen profession. Everything in GitHub is tracked, and everything has a unique name on it. That unique name links to a page which lists all of their contributions, which languages they use, and which projects they contribute too. With just a little searching you can create a complete picture of a programmers activity online. Even the lack of activity is knowledge that asks questions. I can’t share the code for private projects, but by contributing publicly I can share a bit of my experience and passion. Your accountability in code is easily viewable so think carefully about cursing in your comments.

My turning point to making the Barrett Sonntag brand

In 2007 I made a conscious decision to own my personal brand, that is Barrett Sonntag. Some coworkers and I started searching ourselves online. Those with common names didn’t appear at all, but since I am blessed with a fairly unique name some content came up. Some stuff I forgot about, but was proud of. My good friend Ronald Figueroa bought his own domain not too long after that conversation. At the same time I saw a possible future where someone else would come into the Internet with my name, and I wouldn’t be able to recoup ownership of my name. I had a head start and I took it. I took ownership of the Barrett Sonntag brand, and that extends beyond my personal reach. It is my creation, it is what I have chosen to publish and relate to myself. I have gone to the source where my employers, my clients, and my customers go searching for truth to create my personal brand. Search engine optimization for the self!

The information super highway

Thousands of people are intentionally doing the same thing right now. There are personal blogs of developers, designers, project managers, or hire me sites, that are purpose built. These personal brands are extremely valuable, increasing your future potential earnings, discoverability or providing an edge in getting your next job. The Internet is how we discover the world outside our personal network. Even when I get a personal recommendation for something I turn right around and enter that into the search engines of the Internet to get a feel for the general consensus. The idea that I did Internet research on potential clients and employees was novel at the time in my personal network, but is common place today. At the same time over these last few years we’ve had more people join the Internet as consumers. They only created content on social networks, and learned hard lessons about the permanence of the Internet. The pictures you post, the words you say have an unknown lifespan, and that idea is hard to understand. So we have these personal brands being created right now whose value does extend beyond the person who is creating them. The creation of your own personal brand is a way to take control of reality in relation to yourself. You have an opportunity to be selective about the picture of you that someone else builds in their mind when they search for you online. You can highlight your achievements, point out your contributions, and wax poetic about something related to your brand.

The risks of connecting the virtual and physical

The creation of your online presence, your personal brand, or your history on the Internet can also be a security measure. Defamation of character as I understand it is a matter between two entities. Someone has stated false claims on my brand, or another person whose name matches my personal brand does something newsworthy, creates a lot of noise unrelated to what I have created. The more effort placed into my brand the more robust I believe it might be in that event, and no I haven’t had to test that yet. There has also been many instances of unorganized but large amounts of individuals acting aggressively. They will tweet, post to blogging platforms, share on social networks. I don’t know if there is a defense of that to be honest. There is a large amount of risk taken in creating your own personal brand connecting an online presence with your physical presence. The risk is not only to yourself but to those near to you whether you’re in the right or not. A statement can be taken out of context, an opinion you gave, and comments you made in the past can haunt you if it is connected to your personal brand in a negative way. Your personal social media pages that are public or private can be connected to you. Private social networks can be made public in the blink of an eye by accident or on purpose. Those photos you thought were cool or comments you made in college might not reflect who you are now, and can hurt your personal brand.

A personal brand is free to create, but I can only imagine how much PR disaster relief can cost. It doesn’t even have to be done with the intent of creating a formal brand. You can create, with some effort, the picture you want, and the reality you want. Don’t be fooled though, there is not enough potential value to risk lying. I only publish the truth as I know it at that moment, it’s a lot easier to be consistent, I am always able to change my opinion based on new information, and there is no web of lies. Nothing goes away in the information age, there is no secret that can be kept once it gets uploaded, and if you lie it will eventually come back around. Even offline sleuths can uncover public records that are then uploaded and spread. There isn’t a defense strong enough to suppress the truth once it hits the Internet.

Another consideration to keep in mind when you strike out to create a personal brand is hacking. A stale site that isn’t up-to-date is a prime target for hackers. They don’t make any noise when they infect your sites and are very difficult to get rid of. I’ve had more than one time of my own dealing with security vulnerabilities so keep your brand active and the problems if they arise won’t go unnoticed.

A natural progression to personal brand creation

This personal brand, Barrett Sonntag, is something I never imagined when I started programming. I never considered that I would work with other people on enormous code bases that were created by our predecessors. You’re probably already on your way to creating a personal brand of your own. Open source software has won the day, programmers have put themselves out their, and connected themselves with their code. You can trace contributions, bugs, comments, successes, and mistakes back to the person that created them. The connections may be created innocently at first, perhaps as leverage in an interview, but soon build into a map or history of your footprints across the net. To make this personal brand and directly connect it to yourself takes courage. It is to become vulnerable, and is a commendable step for people with less supportive environments. You are spreading your arms wide and saying here I am, this is my mark. I want to show you what I am proud of, what I think makes me valuable, how I act, and how I think. Many people have become social through these personal brands only in the way today’s Internet understands social interaction. It never requires any physical presence to create a brand with a social appearance. The stereotype of a basement dweller can be one of your most prolific sources of information and have an extremely valuable personal brand.

Be the authority on your personal brand

Why do we take the risk in curating a personal brand? Because there is no other option to create opportunity besides a true network of people who know you. That true strongly linked network will have a short reach, and has the chicken and the egg problem. You can create a larger weaker linked network that has a long reach in your spare time. These personal brands persist beyond social networks that rise and fall, and so long as you maintain them they will be the single source of information on you and your curated personal brand. Your guest posts to other blogging platforms could vanish overnight, or the platform might decide that they want to kill a feature that you’ve invested time in. The longer you own your personal brand’s domain name the more value it has. So take a look at your own footprints across the sites you use, and objectively see if you’re creating a brand you’d be proud of. Then take ownership of your personal brand and stake your claim for your online presence.

IE9 crashes when dragging, scrolling, and updating styles

Internet Explorer 9 was released 4 years ago in 2011 which sounds like a short time, but it really is an eternity in the world of web development. IE has had 3 releases since then and the 4th is on the horizon, but the upgrade cycle of many companies doesn’t reflect that fast pace. So we must continue to support IE9, and in doing so we will uncover more obscure bugs that will never see fixes.

This was the case recently when working on a grid view in JavaScript. A customer reported IE9 would crash, as in close the browser window down, when dragging a column to reorder them. They could drag the column in either direction and repeat the crash reliably. No error message, no where to clue where to start other that the drag action.

Since there were no error messages to go off of I used WinDbg after reading a MSDN blog post on debugging Internet Explorer. I had a virtual machine downloaded from modern.ie. After getting WinDbg hooked up to IE I set off to replicate the crash and had no trouble in doing so. The error message stack trace ended inside mshtml.dll, which is also known as Trident, the IE rendering engine.

Internet Explorer architecture

Internet Explorer architecture

WinDbg delivered the crash stack:

6D6DD5BB 81 3F D0 AD A3 6D cmp dword ptr [edi],6DA3ADD0h

mshtml.dll!CDispScroller::SetScrollOffsetInternal()	Unknown
mshtml.dll!CDispScroller::SetScrollOffset(class CSize const &,int,bool,enum tagCOORDINATE_SYSTEM)	Unknown
mshtml.dll!CDragDropManager::DragOver(unsigned long,struct _POINTL,class CSize const &,unsigned long *)	Unknown
mshtml.dll!CDoc::DragOver(unsigned long,struct _POINTL,class CSize const &,unsigned long *)	Unknown
mshtml.dll!CDoc::DragOver(unsigned long,struct _POINTL,unsigned long *)	Unknown
mshtml.dll!CDropTarget::DragOver(unsigned long,struct _POINTL,unsigned long *)	Unknown

Looking at the ScrollOffsetInternal function I suspected it might be in the CSS positioning of the grid area. It was able to scroll left and right as the user dragged for a wider-than-browser grid. I removed all positioning from the element and was still able to get the crash. I lost the crash log that had the right clue, which is the one I got when I removed the positioning classes. The log mentioned CSS colors, paint, and I remembered that there was a hover on the columns as you dragged over them to indicate which one was active. I removed the class, and couldn’t crash the browser! However I lost that visual cue, and though I discovered the issue I wanted to keep the existing functionality in place.

The problem was in the timing. When we hit the drag enter event we would check to see if the element is a valid target, then add the class which changed the look. The crash happened when dragging an element, scrolling the element container, and updating the drag enter target’s parent class when it was outside the container. That update caused an attempt at a paint, which ultimately took down the browser on a null exception. WinDbg even let me walk through the assembly instructions to see Trident was trying to perform a math operation at the time. The solution was easy, just update the CSS on the next event and not in the same one. So now we drag and scroll, then update the style using setTimeout pushing that action off to the JavaScript event stack.

The older technology gets and the more you continue to have to use it necessitates learning new tools to take the investigation into your own hands. Don’t be afraid of debugging tools like WinDbg. It didn’t give me the answer outright, and Trident is closed source but the stack trace gave me some logic to follow. It gave me the clues I needed to deduce the problem and come up with a solution that not only works, but one that I understand why I had to add that setTimeout.

Unit Testing a JavaScript app using RequireJS with Mocha, PhantomJS, Chai & SinonJS

Unit testing is something every developer agrees should be done, but often doesn’t do. Setting it up isn’t hard after reading and evaluating what feels like a 7 course meal of modules that need to come together hand in hand to allow you to write some tests. It is fairly easy after you’ve learned more than you ever wanted to know about unit testing. Not easy at all, so I’m going to distill a stack down here for you. This is just one of many possible combinations, but when you’re just trying to get started the best solution is the one you pick and stick too first.

What is in the stack?

Much of the problem with getting started is the friction of deciding which modules you want, which work well together, and did you make the right choice of technology. Don’t stress about it, any finished stack will work well. This stack is comprised of several technologies, the app framework is replaceable. For this post I will connect a JavaScript app using RequireJS to the test runner Mocha through the PhantomJS headless browser and asserted with Chai. I’m also using Backbone and MarionetteJS to illustrate frameworks in testings too.

Setup

Serving the App for Testing

In order to run testing the application will need to be hosted and accessible locally through a web browser. If you’ve already got a solution for hosting your files locally you can skip this step. For the purposes of this tutorial and testing we’ll install http-server using the command npm install http-server -g. You can spin up a server on port 8080 now by just typing http-server app from the test folder. The “app” parameter in this case is the folder where the server root will be. Point your browser to http://localhost:8080 and you should see a file listing for the folder you specified.

Collecting Dependencies

We’ll be using npm and Bower to bring in dependencies for this project. After getting npm installed you’ll want to install bower and the grunt-cli globally by running this command npm install bower grunt-cli -g. You can pull down the entire working testing application from a GitHub repository I created called requirejs-unit-testing-mocha. I had started to put each file and contents in the body of this post but it got out of hand very quickly. The gist of it is that once you clone this repo you’ll need to run npm install and bower install from the root directory of the project.

Verify the Setup

Once you’ve cloned the repo, run npm install and bower install you should be able to start the http-server pointing to the app folder. Once the server is running run grunt mocha and you should see three green tests as passed. Next we’ll go over how everything has been connected.

Wiring it up

Executing the Tests

The grunt task setup in gruntfile.js is much less complex than it may seem. The meat of the task is in the command on line 11 which is running the npm module mocha-phantomjs which loads up our tests in the PhantomJS headless browser.

Loading the Test Suite in the Browser

Loading up the all the tests is just as you’d imagine running your site would be. All the dependancies are included in the index file under our tests folder. Here we add in Mocha, Chai, all the Sinon files, and the RequireJS startup file. Important notes here are the global declaration of expect and should on line 37 for later usage as well as setting the RequireJS baseUrl on line 51 which allows the included files to work as expected.

Including the Tests

The main file loaded by the test page is mochaRunner.js which includes all the tests we have for the project. The core function is what starts up the tests, either through mocha-phantomjs or just mocha if you load it in a regular browser. At this point everything needs to be ready, so the dependency list here starting on line 3 is where you include every test file you make. A tip here is to also include any other dependancies first before you list the test files out.

Writing Tests

Test file naming

I’ve written up one test spec file in basicTest.spec.js. Each test file follows a .spec.js extension convention. This extension isn’t required but tests files tend to be made in the same name as the JavaScript file they are testing so this extra spec tail makes them easy to differentiate. You should note right now that I haven’t followed this convention in this example test spec, which now should help you remember the right way! This file should be named sample.spec.js. Putting the entire test suite in a subfolder this way also allows for easy exclusion during releases and deployments.

Test setup

Each set of tests starts with a describe block taking a description parameter that helps to organize the output and group tests that have similar buildup and teardown experiences. The before and after functions happen before and after all the tests in the describe block are completed. Similarly the beforeEach and afterEach functions happen before and after each of the individual it assertions happen. This continues for nested describe blocks where each parent describe block’s beforeEach and afterEach functions run before the current scope beforeEach and afterEach functions run for each it assertion.

Assertions

Each it block is a single assertion to test one piece of functionality, a single unit, hence the name unit tests. Each it block expects to end with a Chai assertion. In my examples I use should.contain and should.equals. You can use any style of assertions, but it helps to stick to a single style in a project.

Stubbed assertion

Once you’ve included a dependacy you might need to make it respond how you want, or listen for something to have been called. This is where stubbing comes in and SinonJS starts helping out. Line 42 starts a unit test where I’ve created a stub of my show function and returned an arbitrary object instead. Note that after you stub something you should restore it as well!

Asynchronous Assertions

Not all tests can be asserted immediately but need to be asserted on a following event in the JavaScript call stack. To facilitate this you pass in a function variable to your it function named done. You can then call done() explicitly in a callback or promise return to let the mocha runner know you’ve finished the test assertions.

it('async test function', function(done) {
  setTimeout(function(){
    done();
  }, 100);
});

Where to go from here

This post covers a lot, much more than I planned. If you didn’t already have knowledge of all the tools used it might have been more daunting, but it is worth sticking to it. This is something you only have to setup a few times. Once it works you can just write tests and enjoy the benefit of them as your project and team grows. This isn’t all there is to testing but it should get you going or fill a missing gap of knowledge in getting started on testing your project.