Sunday, December 21, 2014

End of Year Retrospective: 2009 - 2015

This blog has been my passion for several years now and it is with joy I look back upon several years of posts, referrals, and visitors. This deck is a little snapshot of the history of C#er : IMage with a focus on you, the reader, who makes it all possible. It's my "thank you" as we move into the Christmas season and look ahead to the New Year. So, Happy Holidays (and don't worry, I will be working on the fifth installment of the AngularJS series, so keep an eye out for that)!

Note: the following slide show is best viewed full screen.

Jeremy Likness

Saturday, December 20, 2014

Lenovo Yoga 3 Pro Review (and Surface Pro 3 Comparison)

My interest in the Yoga line began several years ago when I was looking for a lightweight, portable development machine to use as my primary device and to test Windows 8 apps on. I wrote about the IdeaPad Yoga 13 here. I continued to use that device as my main one until I purchased a HP TouchSmart 15t-J000 Quad Edition so that I could have 16 gigabytes of memory to run virtual machines. Even after that purchase I still used the Yoga as my portable “go to device”.

For work I was issued a Surface Pro 3. The Pro 3 serves as my main development machine and what I carry with me, so I have several months of use to draw from experience. I was really, really excited when Lenovo sent me the Yoga 3 Pro for review. I was able to put it side-by-side with the Surface Pro 3 and share my thoughts here.

The unit that I received was a Lenovo Yoga 3 Pro Convertible Ultrabook. The model they sent me was orange, which I wouldn’t ordinarily choose for myself but has actually grown on me. In fact, were I to pick up a new machine with that color, I’d go for it – it’s still a professional, metallic looking orange that gets a lot of attention wherever I take it.

The specs at a glance:

  • 13.3” screen size
  • 3200 x 1800 (QHD+) resolution
  • 1.1 GHz dual-core Core M 5Y70 (boost to 2.6 GHz)
  • 8 GB DDR3-SDRAM memory
  • 256 GB SSD 
  • 802.11 A/C wireless
  • BlueTooth 4.0
  • 7 hour (per marketing) battery life
  • Windows 8.1 Pro operating system
  • 13” x 9” x 0.5” dimensions
  • 2.62 lbs. weight

Cost as of this writing is around $1400.00.


The box is follows the common pattern for contemporary ultrabooks and slates: black, sleek, and modern. The cover shows off the various modes that the Yoga supports.


Opening the box was fun. There is unique packaging that enables the laptop to literally rise out of the box, as you can see here:

Build and Ports

The tablet itself feels sturdy and metallic all around. It is super lightweight and extremely thin. The new “watch band” hinge is very sturdy, and although it can be distracting with so many moving parts I think just adds to the distinctive style of the ultrabook. What is most amazing to me about this device is the abundance of ports. Check out this side:


The stack is a No. 2 pencil, the original Yoga 13, my Surface Pro 3, and at the bottom is the sleek Yoga 3 Pro. On the side you are looking at there is power, reset, orientation lock, volume rocker, headphone and microphone combination jack, and USB 3.0 with charge. On the flipside:


That side has the charging port that doubles as a USB 2.0, another USB 3.0 port, a mini-HDMI out, and card reader. Pretty packed for such a light and thin device! The new watch hinge allows it to bend completely flat:


As you can see, when flat it is thinner than the pencil.


The display is gorgeous. It is viewable from all angles and packs such a high pixel density that the images are just vivid and clear. Although it is glossy I didn’t have many issues with glare. It is a touch screen and does invite smudges, so you will want to keep a cleaning cloth handy if you use touch frequently.


As you can see, there is plenty of room for a lot of tiles and they all display crisp and clear (any blurriness is from the camera and not the display itself). It is awesome watching full screen video on this laptop, but more importantly when you are working the high pixel density makes it easier to put several apps side-by-side for maximum productivity.


What is there not to love about the keyboard? I think the keyboard is where the Lenovo line really shines. I’ve always enjoyed their keyboards and this one is no exception. Ironically the actual size inside the bevel is very similar to the Surface Pro 3 Type Cover keyboard. However, as you can see in this picture the keys have nice spacing between them:


The function keys are what I’ve grown used to in an ultrabook (basically the numeric row doubles as functions and you have to press a special key to invoke the functions). Although there is little travel in the keys, it doesn’t bother me at all (maybe because I’m used to typing on the Type Cover for the Surface Pro 3?) and feels great. It is also very soft and quiet, so when you are typing it doesn’t sound like rain is pounding on an aluminum roof like other keyboards.

Here is another look, side-by-side going left to right: IdeaPad Yoga 13, Surface Pro 3, and the Yoga 3 Pro on the right.


The keyboard is backlit and really easy to turn on/off (hold down the function key and tap the spacebar). The rubber surface surrounding the keyboard has a lovely texture and makes it easy to rest your hands. Overall I give this keyboard an A (would be A+ if it had more travel, but I get why it had to be designed this way to keep the ultrabook thin and light).


The touchpad is the same as other recent Lenovo models: a single surface with a slight bevel so you can feel the difference between left and right clicks. It is easy to use, responsive, and overall works great. My only issue with the touchpad is that sometimes it’s difficult to determine which side you are on so I often find myself right-clicking when I want to left-click or vice versa, but this seems to be consistent across any type of slate or ultrabook touchpad (I have the same issue on my Surface Pro 3). 


The built-in speakers were as good as I would expect in a light and thin device. They were definitely superior to the ones built into my Surface Pro 3 slate, but as with most ultrabooks tend to sound tinny and completely fail to render anything remotely resembling bass. The volume is great so if you want to share something with friends and family the combination of QHD display and sound will work great, but if you want to immerse yourself in quality sound I’d go for headphones or external speakers. The BlueTooth 4.0 means you can use wireless headphones and the sound produced is top quality – I did a trial run with my Sennheiser travel headphones and the sound delivery was flawless.


The performance overall was solid. The SSD is extremely fast so the laptop boasts one of the fastest boot times of any device I have. It boots more quickly than the Surface Pro 3 and is literally ready to login just seconds after you touch the power. Anything disk-related is obviously going to run well.

Processing power is a mixed bag. Although the chipset is a specially designed one for lower power consumption, that also means less horsepower. For most workloads you won’t notice any difference, but the two areas I did see some slowdown was with heavy development (i.e. building large applications) and streaming full screen video. I’m sure the latter was more related to powering the high definition screen but some online sources did experience stutter and some synchronization issues with the sound track. These were very rare however and for the most part this laptop will work just fine. To put it in perspective, it out performs the IdeaPad Yoga 13 that I used as my primary development machine for years, but it does fall short of the i7 processor that I have in my Surface Pro 3.

Battery Life

Battery life was a bit disappointing for me. Although I did not run a formal test, I did purposefully keep it with me for several days without the power cord. What I found was a life close to what my Surface Pro 3 has – about 6 or 7 hours. It seems the design compromised performance for a low power chip but it’s not clear to me what was gained when the higher powered i7 lasts nearly as long. It’s not a bad battery life at all, I just expected it to be a lot more considering the chip design.


The wireless worked great. I had no issues connecting to any hotspots public or private, and was able to achieve very fast speeds on any network. The 5G worked flawlessly and seemed to have a stronger signal than my Surface regardless of where I was in the house. Taking it on the road with me I was also able to connect anywhere I took it.

What I Like

The tablet is gorgeous. It has a solid build quality. Everywhere I brought it with me, people were asking about it. They wanted to know what model it was, if they could it, and always were surprised by how light and thin it was. They really liked the orange color and one co-worker made the comment, “They should just go ahead and put a Lamborghini logo on it, because that’s what it is – the Lamborghini of laptops.”

It is so light that when I added it to my backpack with my existing devices I barely felt the difference. The keyboard is incredible (and above all, quiet) and the screen is gorgeous. It connects fast and performs well. Above all there are tons of built-in ports for connectivity. Overall it is a great device that I would recommend.

What I Don’t Like

For something so thin and sleek I was expecting a longer battery life. I also don’t understand the lack of a digitizer pen included with it. I believe you can purchase an accessory but to me a pen is a must. I know some people don’t get why the Surface Pro 3 advertises the pen so much because a lot of people simply don’t use it, but I do. I use it to take notes, highlight documents, digitally sign, navigate menus on the high resolution display and highlight presentations.

I also wish the processor was just a bit higher end. I notice the difference between heavy workloads on my Surface Pro 3 compared to the Yoga, and the Surface is truly a tablet that I can detach from the keyboard and hold in my hand. I think if you’re not a developer or media editor (i.e. if you aren’t using it to produce online video, for example) you won’t notice the difference, but trying to squeeze more high end functions out of it may be challenging to a few. 


I would consider this to be the  best ultrabook hands down. Although some people might consider the Surface Pro 3 to be like an ultrabook, I consider it a slate and don’t think it competes directly with the Yoga 3 Pro. Here’s the bottom line:

If you want something thin and lightweight with a gorgeous, large display, plenty of ports, and comfortably fits in your lap without any wobble, go for the Lenovo Yoga 3 Pro. If you want something smaller and lighter that you can just carry around like a tablet and scribble on with a pen but still use for heavy workloads (i.e. full power i5 or i7), go for the Surface Pro 3. Both are excellent, top notch devices that exist in a slightly different class from each other.

Saturday, December 13, 2014

The Top 5 Mistakes AngularJS Developers Make Part 4: Hacking the DOM

This is the fourth part in a five-part series that covers common AngularJS mistakes. To recap, the top five mistakes I see people make are:

  1. Heavy reliance on $scope (not using controller as) 
  2. Abusing $watch
  3. Overusing $broadcast and $emit
  4. Hacking the DOM
  5. Failing to Test

In the previous posts I’ve covered some nuances around controllers and how they communicate with each other and expose information for data-binding. In this post I’ll elaborate on the importance of data-binding and share why it’s important to avoid hacking the DOM when writing an Angular application.

Hacking the DOM

In the end, web applications are about the DOM. You may be surprised to learn one of the most viewed posts of all time on this blog is a short one about a simple hack for IE 6.0 that I posted almost five years ago. I’m also not too shy to admit I really didn’t understand JavaScript at the time as evidenced by the “solution” (it worked, but wasn’t necessarily the best way to approach it) and considered it an inconvenience that I simply had to work around so web applications would work.

In fact, shortly after that post I did a proof of concept for an emerging technology (at the time) called Silverlight and ended up converting to it. To make a short story even shorter, there are many reasons why Silverlight made sense at the time and although it is no longer the main technology I use, I do consider Angular to be the modern HTML5 answer to Silverlight and the MVVM pattern.

The two biggest benefits I feel data-binding provides are:

1. A declarative UI that encourages testability

2. A designer/developer workflow

The second is really the result of the first. Let’s take a step back. What do I mean by declarative UI? Consider for a moment this code:

var value = window.document.forms["myForm"]["name"].value;
(value === null || value == '') {
    alert('Name is required.');

Now take a look at this solution instead (note the “required” attribute:

<input id="name" name="name" required placeholder="Enter your name"/>

Answer this: which one is easier to understand, even by a non-developer? And which one scales better – in other words, when there are more fields that are required, which solution is easier to apply to the new fields as they are introduced?

The declarative approach provides building blocks that can be placed in mark-up. The imperative approach allows logical code that requires a deeper understanding. Imperative code may enable more complex manipulation and make sense for business logic, but in my opinion you should declare as much of your UI as possible to make it designer-friendly. That’s the second point: by having a nice separation between the UI and your more complex back-end logic, your designer can literally work on the UI and manipulate it in various ways independent of your programming.

Fortunately, Angular provides a solution that allows you to encapsulate imperative logic in a declarative directive. Before I explore that further, however, I need to address the “traditional” method for imperatively interacting with the DOM: jQuery.

The jQuery Factor

I’ve been in code bases with controllers that look something like this:

function Controller($scope) {
    $ = '';
    $scope.nameError = false;
    $scope.$watch('name', function() {
        if ($ === null || $ == '') {
            $scope.nameError = true;

Although this may work, my next post is going to cover testing and I think anyone would be challenged to test this piece of code without spinning up a browser page that has an input field with an identifier of “name.” That’s a lot of dependencies and tests are supposed to be easy to set up and run!

Now before I continue, let me make it clear I am a huge fan of jQuery. In fact, Angular will automatically fall through to use jQuery when it is present. When it is not, Angular provides it’s own lightweight version called jqLite. Just to be clear, however, I think the biggest benefit of jQuery is this:

jQuery is a tool for normalizing the DOM.

What do I mean by this? Just take a look at this comparison of web browsers and you’ll find things aren’t as standard as they may seem. Instead of having a lot of logic to detect which browser you are running in and use the appropriate APIs, jQuery normalizes this for you. You get a consistent interface to interact with the DOM and let jQuery worry about the implementation nuances across browsers.

In fact, people often ask me if Angular means “no jQuery.” Although Angular can greatly reduce the amount of jQuery used in an app, sometimes jQuery is still the right answer when heavy DOM manipulation is required. I just want to make sure it happens in the right place. Getting back to Angular, I have three very simple rules when it comes to interacting with the DOM, whether I’m using jQuery or jqLite or anything else. The rules are:

1. Any imperative DOM manipulation must happen inside a directive

2. Use services to mediate between controllers and directives or directives and other directives

3. Services never depend on directives

That’s it. Even though this is older code, if you look at my 6502 emulator written in TypeScript and Angular, you’ll find a graphics display and a console (to see it in action, click Load to load a source, Compile to build it, and Run to execute it). The main CPU, however, never references the DOM and is ignorant of how it renders. In fact, whenever a byte is set in an address range that represents the display, this code is executed:

Cpu.prototype.poke = function (address, value) {
    this.memory[address & Constants.Memory.Max] =
        value & Constants.Memory.ByteMask;
    if (address >= Constants.Display.DisplayStart &&
        address <= Constants.Display.DisplayStart +
        Constants.Display.Max) {
        this.displayService.draw(address, value);

Notice it simply passes the information to the service. The service is also testable in isolation because there is no dependency directly on a directive or the DOM. You can view the source here. So what happens? The directive takes a dependency on the service, hooks into the callback and renders the pixels using rectangles in SVG as you can see here.

There are several advantages to this approach. One is testing that I’ll cover in the next post. Another is stability. The more you rely on specific ids or specific types of DOM elements, the less stable your code is. For example, let’s assume I decided that SVG was the wrong way to render the display and wanted to use WebGL or something different. In this example, the only code I need to change is inside of the display directive. The service and application remain the same. I call this “refactoring containment” because the clean separation is like a bulkhead keeping you from having to change massive portions of the codebase or regression test your entire app just because you are tweaking the UI.

Here is a conceptual view of how your application might interact with the DOM – note the key interactions are either directly via data-binding or indirectly through the service/directive chain with jQuery thrown in where it makes sense to normalize the DOM.


To better illustrate this I’ll share a few more practical examples. Let’s take the initial comparison between imperative and declarative. How do you set the focus on an element declaratively? One approach would be to consider the focus a “state.” When a field is in an invalid state, for example, you’ll want to set the focus so the user can easily correct it. The app should only care about the state, and the directive can take care of the focus. Here’s an idea for the directive:

app.directive('giveFocus', ['$timeout',
        function ($timeout) {
    return {
        restrict: 'A',
        replace: false,
        scope: {
            binding: '=giveFocus'
        link: function (scope, element) {
            scope.$watch('binding', function () {
                var giveFocus = !!scope.binding;
                if (giveFocus) {
                    $timeout(function () {
                    }, 0);

Place the directive on the element you want to have focus, and data-bind it to whatever property should trigger the focus. The timeout simply allows the current digest loop to finish before the focus is set.

Note: some of you may be lining up outside of my door waving pitchforks and throwing rotten eggs because I used $watch after writing an entire post about avoiding $watch. This is one of the cases where I believe $watch makes sense, because the isolate scope is such an intrinsic component of a directive.

Here’s an example of how you might use it:

<input type="text" id="name" give-focus="ctrl.invalidName" />

Now for an example with a service. It is quite common for your app to need to know the current size it is running in. You can only do so much with media queries and CSS. For example, let’s say you are rendering a grid with server-size paging. How do you set the page size? A common approach is to simply fix it to a hard-coded value, but if you know the height of a row you can easily accommodate the device and resize the grid accordingly.

Here’s a size service that simply keeps track of the height and width of the window you are concerned with. Your app will watch the values to make adjustments as needed.

function SizeService() {
    this.width = 0;
    this.height = 0;
} app.service('sizeService', SizeService);

Here’s the size directive. It hooks into the resize event of the browser window and recalculates the size of the element it is bound to.

app.directive('bindSize', ['sizeService',
    function (ss, w, to) {
        return {
            restrict: 'A',
            replace: false,
            link: function (scope, element) {
                function bindSize() {
                    scope.$apply(function () {
                        ss.width = element[0].clientWidth;
                        ss.height = element[0].clientHeight;
                w.onresize = bindSize;
                to(bindSize, 0);

To use it, simply place the directive on the element you want to track the size of:

<div ng-app="myApp" ng-controller="ctrl as ctrl" bind-size="">

You can see a combined demo of the focus directive and size directive here. (If you want to support multiple elements, just pass in an identifier on the bind-size and change the service to track an indexed array of widths and heights).

Keep in mind you don’t necessarily have to use services just to mediate between controllers and directives. Sometimes the directives might use a service to communicate with each other! For the size example, it might be more practical to have another directive use the size service to set the page size on the grid, so the controller is never involved (or just queries the page size from the service, rather than trying to do any computation itself).

Don’t think you have to build these for yourself. Angular already has quite a few built-in features to help separate DOM concerns from logic concerns. For example, you can inject an abstraction of the window object using $window. Using this approach allows you to mock and test it (i.e. $window.alert vs. the hard-coded window.alert).

For class manipulation check out my Angular health app. I use the BMI value to color code the tile based on whether the individual is in a healthy range or not. To swap the class I use the built-in ng-class directive with a filter as you can see here.

Modern applications don’t just focus on look and feel, but the entire user experience. That means motion study and animations where it makes sense for transitions. Although I risk exposing the true reasons why I am a developer and not a designer, the Angular Tips and Tricks app uses the ngAnimate module with animate.css to create transitions. The most egregious examples are in the controller as piece.

The key is that the animations are declared in HTML and automatically trigger based on state changes and transitions. The services and controllers in the app are completely ignorant of how the views are implemented. This allows me to test those pieces and even develop them completely independently of the designer. The designer can literally add or remove animations and tweak how those animations work without ever stepping on my toes even if we are working on the same area at the same time!

To recap, there are just three simple rules you need to follow to avoid hacking the DOM and create truly scalable, maintainable, testable, and fun to use Angular applications:

1. Any imperative DOM manipulation must happen inside a directive

2. Use services to mediate between controllers and directives or directives and other directives

3. Services never depend on directives

That’s it. I know I’ve mentioned testing several times, and I realize even today there are some shops that question its value and consider it to be overhead. Not only do I believe in the value of testing, I think it is so important that it makes my top five mistakes because too many Angular developers are missing out on one of the framework’s biggest benefits. Testing will be the topic of my next post.