I have a piece of content like this:

<div class="site-application-header">  
  <span>Something on the left</span>
  <span>Something on the right</span>
</div>  

While this can be handled with things like floating or positioning, I prefer to use FlexBox as it provide a more flexible solution and to me, is easier to understand by reading the code. I used the justify-content: space-between; FlexBox property (or -ms-flex-pack: justify; for IE 10) and everything looked fine except in IE 10.

What ended up being the issue is that I was using span elements and in order for this to work properly, the elements need to be either block or inline-block. I ended up switching the code to:

<div class="site-application-header">  
  <div>Something on the left</div>
  <div>Something on the right</div>
</div>  

For example, lets take an auto complete component. An auto complete component will have some HTML to display the list of auto complete items. It will also have some logic to be able to interact with those items. You can do things like using the keyboard to cycle through them or clicking on one of them to select it. The HTML and logic code are tightly tied together because there is a pretty good chance that if you change one, you are going to need to change the other and they are not useful alone.

What about multiple templates?

One may argue that if you have your template as a separate file, you can create multiple templates that can use the same logic code. For example, with AngularJS, you can define a templateUrl property of a directive to be a function that can return a number of different strings that will resolve to the url path of the template that you want to use. While this is true, I would argue two things.

First, this is something that I have not commonly had to do in practice. I think being able to use multiple templates against the same logic code is one of those things that in theory sounds great, but it is not exactly a common use case in practice. Most of my 9+ years in web development has been mainly in managing CRUD style web applications and 98% of the time, my logic code was always running against 1 template anyways.

Secondly, when you do have the occasion where you do need this type of functionality, ReactJS provide a more flexible solution in my opinion, mixins. Lets says we want to have a large card and a small card component that will need the same logic. With AngularJS you create a card directive and dynamically generate the templateUrl for the type of card you need.

angular.module('app')  
.directive('card', [
  '$compile',
  function($compile){
    return {
      templateUrl: function() {
          return something === true ? '/templates/card-small.html' : '/templates/card-large.html';
      },
      //other properties
      compile: function(element, attributes) {
          //your logic
      }
    };
  }
]);

Using this directive might look this this:

<card data-type="small" ...></card>  
<card data-type="large" ...></card>  

With ReactJS I would first create a card mixin.

var cardMixin = {  
  //your logic
};

Then would create a SmallCard and a LargeCard component.

var SmallCard = React.createClass({  
  mixins: [cardMixin],
  render: function() {
    //return your template code
  }
});

var LargeCard = React.createClass({  
  mixins: [cardMixin],
  render: function() {
    //return your template code
  }
});

I find mixins to be a much better system of adding functionality to components compared to AngularJS directives. Sometimes something that I would have written as a directive in AngularJS can be just a mixin (but I will leave that for another post).

ReactJS is not ExtJS

One things that I have seen is some comparisons of ReactJS to ExtJS because of the tightly couple template and logic code. While at a high level they both do manage HTML based on JavaScript code, their implementations are so different I don't think they are really that close to each other. I have used ExtJS in the past and it was a very painful experience, the complete opposite compared to ReactJS. Anyone can take a great idea, write a bad implementation, and then use that implementation as a reason why the general idea is bad. ExtJS for me created a bad implementation of using JavaScript to manage HTML but ReactJS created a much more elegant solution.

It should also be mentioned that ExtJS is designed to provide you everything for building a web application from a core framework to a set of components complete with styling and ReactJS is just a library for build components. Comparing all of ExtJS to ReactJS would not be fair however I think just looking at the API for managing HTML is fair.

Lets take a look at a simple panel component, this is from the ExtJS 5.0.1 documentation which I believe is the latest version as of writing this:

var filterPanel = Ext.create('Ext.panel.Panel', {  
    bodyPadding: 5,  // Don't want content to crunch against the borders
    width: 300,
    title: 'Filters',
    items: [{
        xtype: 'datefield',
        fieldLabel: 'Start date'
    }, {
        xtype: 'datefield',
        fieldLabel: 'End date'
    }],
    renderTo: Ext.getBody()
});

Now lets assume we have a Panel, PanelContent, and DateField ReactJS components already written, the ReactJS code for the same panel in my head would look like this:

var filterPanel = React.createClass({  
  render: function() {
    return (
      <Panel>
        <header>Filters</header>
        <PanelContent>
          <DateField
            Label="Start date" />
          <DateField
            Label="End date" />
        </PanelContent>
      </Panel>
    );
  }
});

Now I am not saying the ReactJS's JSX is a perfect system for written HTML in JavaScript, it definitely has it's rough edges, but for me, the ReactJS code is much easier to read and understand. I think it is because it resembles HTML pretty well which is something any front-end developer should already be familiar with. ExtJS basically creates it own custom API that is something you going to have to learn. This is only a simple example, things can become very hairy very quite with what I remember from my ExtJS days.

I should also note that ExtJS does as have css integrated into thier API for creating components but I did not do in the ReactJS version. This post is just about HTML and JavaScript, I will leave the styling aspect for another post.

Sometimes when certain patterns are not recommended (like keeping your template and logic code separate) it is not necessarily because the general idea is bad, it just might be that there is not a good implementation of that idea. I think ReactJS is a very good implementation of the idea that it makes sense to keep your template and logic code together in the same file.

some  
random  
words  

Now lets say you have 2 branches. Lets say a branch called merge1 changes the first line to changed and you have a branch called merge2 that changes the second line to specific. Now you merge in merge1 however when you try to merge in merge2, you are going to get a conflict. This was a little weird to me at first since those branches changed different lines (and SVN merges this type of change fine) however in the process of investigating it, I learned about merge conflict styles with Git.

By default, you are going to see this in the file when you get the merge conflict:

<<<<<<< HEAD  
changed  
random  
=======
some  
specific  
>>>>>>> merge2
words  

Now if theses are pull requests that you didn't work on, it would look like merge2 changed the first line to some which technically didn't happen. A comment on a stackoverflow post of mine made mention of configuring the merge.conflictstyle with:

git config --global merge.conflictstyle diff3  

When I made this change, the file now looks like this when a merge conflict happens:

<<<<<<< HEAD  
changed  
random  
||||||| merged common ancestors
some  
random  
=======
some  
specific  
>>>>>>> merge2
words  

With this you can much more clearly see that there has been a change to the branch I am merging into where some is now changed and my merge is changing random to specific. I now know that I should keep line 1 as changed and line 2 as specific. The other merge conflict style is not so clear that merge 2 didn't change changed to some.

I don't know why diff3 is not the default merge.conflictstyle but I would recommend anyone using git to make this change to make dealing with conflicts easier.

So instead of creating promises like this:

var defer = bluebird.defer();  

you need to create promises like this:

var defer = protractor.promise.defer();  

Everything else expect one things works as expected. I found out that the WebDriver promises does not exposed a resolve() method. After looking at the source code a little, I figure out that I needed to use the fulfill() method.

If you create code the returns a promise with Protractor and you want to use the promsie in an assertion, make sure the you create a WebDriver promise.

$red: rgb(212,65,43);
$red-dark: rgb(202,0,2);
//etc...

This seemed like a good idea however it quickly became clear that this would not work. What happens if I want to create a color darker than $red but lighter than $red-dark?

I then started to name colors like this:

$red1: rgb(10, 0, 0);
$red2: rgb(202,0,2);
//etc...

This is slightly better because there is no context in the variables name so I can make $red3 darker than $red1 and lighter than $red2 but I still didn't really like this method of naming either.

Name That Color

In my researching of naming SASS color variables, I came across a tool called Name That Color. You give it a HEX value and it gives you the name of the closest matching color. With this tool I now name my colors like this:

$valencia: rgb(212,65,43);
$guardsman-red: rgb(202,0,2);
//etc...

Now you might be saying "How and I supposed to know what color $valencia is?". That is a downside to this method however that can be resolved by grouping logical colors together and comments. With that, I don't think it is any worse than names like $red1 and $red2 and it is more flexible that $red and $red-dark. It is also not like $red1 and $red2 is all that much better. Even though I know all $red* variables are red colors, that does not mean I don't have to look up the color in the styleguide when deciding which red to use. Since I am going to have to lookup the colors anyways, might as well give it a real color name.

This method also has a slight upside which is that it can help identify very similar colors. There is somewhere around 1500 color names it can give so if I give it a value and it gives me a color name I already have, I probably don't need both colors. It also helps there is not a common system to generating color variable names.

Commandline Tool

While the Name That Color tool is pretty nice I did not like the fact that I had to use a website to use it and that I needed to give it a HEX value (I usually use HSLA for colors but I will get to that in another post). To solve those issues, I created a small NodeJS command line tool. After installing it you can run:

name-that-color [color value]

The [color value] can be anything that is supported by the One Color library. You can use it like:

name-that-color "hsl(120, 75%, 75%)"  
hsl(120, 75%, 75%) name is Sulu  

I have only been using this naming convention for the past month or so but time will tell if this naming convension works better for me than other. How do you name you SASS color variables?

Test First

One of the more extreme (in my opinion) views with TDD is:

Never write a line of production code until you have a failing test for it.

This is something that never really appealed to me because it didn't help me in creating better quality code. I've no real rule about this because I don't think there needs to be one. Sometimes I'll dive into the code first and sometimes I'll write the tests first. I generally write tests first when I'm modifying a piece of functionality and write code first when I'm writing new functionality but there's no hard rule that I follow.

Unit Test Execution Speed

Another thing I hear in the TDD camp is that your unit tests should run so fast that they can be executed on every code change. Why? How does that help me? Some editors auto saves when switching between applications. If I'm in the middle of making changes and I switch to another application, do I really need the tests to run and tell me they are failing (something that I already know because I'm not done coding).

Lets say for the sake of argument that I thought this was a good idea, how do we get that kind of speed? Well, we mock everything besides what we are testing. Network calls, I/O calls, database calls, etc... I'm not always a fan of this fan because mocking out everything besides the extremely small piece of code I'm testing decreases my confidence that the code is working properly even if the tests pass.

Lets say I've a database call that I'm mocking for my tests. I then have a feature request that requires a change to the database structure. I update my mock for the tests, make my changes, and my tests now pass. If I forget to make the change to the actual database, when I push my code, it's going to break. "But that is what integration tests are for". Why have 2 sets of tests that test the same thing? I like to get the most out of my time and having over 100% code coverage doesn't make sense (I don't even care about getting to 100% code coverage a lot of the time).

That is not to say I don't mock anything. I mock stuff if the value it adds out weight the costs (like most things). Mocking database calls or I/O calls doesn't add much value. It might make things faster but in this day and age, computer power is relatively cheap. I can run about 1000 tests per minute with my local code making database calls to an external server (if I were to setup the database locally on a VM or something, I imagine it would be faster). While this speed might be way too slow for some, I'm more than fine with it.

Something that I do mock are HTTP requests. I use the supertest library to mock HTTP requests for my NodeJS code. Why do I mock HTTP requests but not database calls? In my experience, these tests are closely tied to the production code and I can't remember a time where I had a mocked HTTP request test pass where the actual code failed. I'll also test services that I don't have control over. If there's some 3rd party API that I don't control, then I'll probably mock that too.

Mocking for me is done on a case by case scenario. Just like most things, I'll weight the pros and cons of mocking something and if the pros out weight the cons (and different people will evaluate this differently), I'll mock it.

Code Coverage

Another thing I hear is how close they are to 100% code coverage. Well good for you. If your building a control system for an aircraft, you probably want to make sure everything works for any possible scenario that anyone can possibly think of and then some. Not all applications need that level of testing and I generally work on those kinds of applications.

I don't spend a huge amount of time trying to think of every single use case that my code could possibly encounter. The amount of up front time I put into thinking of use cases for my tests are determined by a number of factors like what is the life expectancy of the code, what is the worst thing that could happen if something breaks, how often is the code going to run, etc... I'm going to spend more time thinking about use cases for an ORM or a payment system than I would for a command line utility that simplifies the use of rsync. I'll make sure to write tests for all the use cases I can think of and then add tests as issues come up.

Why don't I care about 100% code coverage? Well, it doesn't increase my confidence in the code. Having tests that run every single line of code in your application doesn't mean your code is bug free. You could have a method call that has a parameter that passes the test but 5 different others parameters might fail the test in different ways and just don't know it.

If you have the time to invest to get to 100% code coverage and you think it's worth it, then by all means, go for it. Just don't think 100% code coverage === bug free code because it doesn't.

Testing Levels

This is more of a general testing thing, not specific to TDD. There are many levels of testing, some of the more common ones I hear are:

• unit - low level testing, generally a function/method with mocking out all other things
• integration - testing that includes calls to external services (database for example)
• end-to-end - testing the simulates user interact with the end application

Now some people would say that all of your code should have tests for all of these levels but that is something I disagree with. This is because I don't see the point of testing the same code with 3 separate test suites. I'll generally have 2 different automated test suites, one for unit/integration tests and another for end-to-end tests.

First of all, I write my unit/integration tests as one set of tests because I don't believe everything should be mocked (as mentioned above). I'll then write end-to-end tests as a separate set because they do take a bit longer to run since it's interacting with the end application (which for me is generally the browser).

Overlapping Tests

Something that some people would advocate for that I generally don't do intentionally is that the unit/intergration tests and end-to-end tests should be testing the same thing, just doing it at different levels (and the end-to-end tests can test a little more since it's interact with the end application). If my code doesn't interact with the DOM, then I'll write unit/intergration tests. If I've some code that is DOM heavy, I'll write end-to-end tests. Sometimes I'll have code that has both in which case I'll have both types of tests that will overlap a little bit. The point is that I don't go out of my way to prevent unit/integration tests and end-to-end tests from overlapping but I also don't go out of my way to make sure they do overlap.

For example, I have this extend text component for AngularJS that just includes DalekJS tests (an end-to-end tester similar to Selenium). Now there was a point where I ran into an issue that I probably spent 20-30 minutes trying to figure out why a test was failing. Having unit/integration tests would've probably reduce the time to figuring out where the issue was. At that point I was like, "I need to make all my end-to-end tests have corresponding unit/integration tests". The more I though about it though, the amount of time it would take to invest into writing unit/integration tests that correspond with my end-to-end tests would probably not be worth in the long run.

Adding tests to make the code slightly easier to debug doesn't seem to be worth the effort in the long run from what I've seen.

Testing is important and I'm definitively not suggesting that you don't do it. Always make sure you write tests as you are developing code. Always make sure that when a bug does come up, you either add or update a test to make sure that case it covered to help prevent it from show up again. I just don't agree with the notation that you write code to make your tests pass. You should be writing tests to help increase your confidence that your code is working properly when you make a change.

The Good Stuff

Clean UI

One of the goals of Ghost is to make things simple for blogging and I think it does a really good job at that. Right now all you can really do is see a list of your posts, edit your posts, and then basic settings but what is has is really nice.

The list of the content is simple with just a list of title and status on the left and clicking on them gives a preview on the right. Edit content is pretty much the same, markdown you write on the left and the live HTML preview on the right. Setting are pretty standard.

I know this project is still early in it's development but I think (hope) that they will maintain this clean looking, minimalist UI for the admin tools.

MarkDown

I am a huge fan of MarkDown. I think it is a much cleaner and simpler way to write and store formatted text. Having editors like TinyMCE or CKEditor seemed like a good idea at the time but they just add complexity and what should be a really simple process, writing. I am really glad Ghost has gone with using MarkDown (along with not having a formatting toolbar at the top).

Installation Process

The manual installation process was pretty simple for me. I just followed the installation instructions they have. No issues and very minimal amount of work on my part. The only manual thing I have to do was tweak the config.js file.

Even with the easy install, I just went with Digital Ocean's pre-configured droplet.

Needs Improvement

Spell Check

Ghost right know lacks a spell checker and since I am not the best speller in the world, it is a little annoying. I know this is something on their list of things to do, even though the "it should be fixed soon" was posted back in 15 October 2013. Until then, I am going to have to remember to copy my blog posts into an editor that does have spelling checking before I make the post public.

Overall I am pretty happy with Ghost as a blogging platform. My blogging needs are pretty basic so all the extra functionality that something like WordPress has is something I wont miss. I just need a simple platform where I can easily write blog posts (which Ghost provides) and display it is a nice clean way (which the Ghost Crisp Theme provides. I am pretty tech savvy so for the extra stuff I need (analytics, code syntax highlighting, etc...) I have been able to add easily myself.

It will be interesting to see how this project progresses in the future. You can look at the Roadmap to see the projects that are planned/in the works.

When I say unfamiliar code, I am not talking about code that you have not worked on before since that is generally going to be the case when it comes to code reviews. When I say unfamiliar code, I am talking about reviewing code in parts of the stack that you don't work on. I am a primary front-end developer and 90-95% of my time I spend in HTML, CSS, and JavaScript. How useful is it for me to be reviewing back-end PHP/MySQL code (or whatever it might be)?

The Benefit

The benefit I see with reviewing code in the parts of the stack you don't normally work in would be that it allows you to become more familiar with that code. I can understand this thought process and it does make sense however I don't think the main reason for doing code reviews is to become more familiar with the system, it is to make sure the code that is being pushed is of a high quality.

The Downside

With that mindset, having someone review code that they don't work in on a day-to-day basis seems like a bad idea to me. I mean there have been commits I have seen that I would have given a passing grade on in a review where others who work in that part of the codebase on a day-to-day basis have given comments of improvements that should be made.

Now I agree that you should have at least a high level understanding of how the application you work on works from top to bottom even if you don't work in all the parts of the system on a day-to-day basis, I just don't think code reviews is how you should be exposed to those parts of the system.

It seems to me like if you have the developers, developers should mostly be reviewing code that they work in on a day-to-day basis. Front-end developers should be reviewing front-end code and back-end developers should be reviewing back-end code. I think this will give you the best results as far as code quality is concerned. Now if you only have 1 front-end/back-end developer, then it's fine for a back-end/front-end developer to review the code (better that than no-one reviewing the code).

What do you use code reviews for? How do you handle who reviews what code and what works best for you?

AngularJS 2.0

For the most part, I am happy with the changes that are coming. I like that they are going to take advantage of a lot of what ES6 is going to provide. I also like that they are going to be more modular in the design of the internal components of angular (and they have already started that in the 1.x series). I know they are also making some changes to better support mobile which I think is good, however I don't do a lot of mobile work so it is not that big of a deal to me.

One things that I really like is there plans for the router. I think everyone can agree that the default router that AngularJS provides is a little bit to simplistic. It seems like the design of the new router is going in a similar direction as the UI Router is (a router I highly recommend for AngularJS 1.x).

Another thing I think some people are upset about is the fact that as it stands now, AngularJS 2.0 is only going to support version 10+ for IE. I for one am completely for this. I don't think they are doing this just to push people to update their browser, I think it is being done in order to produce a better library by not having to support browsers that don't support the features that they need. I feel this is the only way we are going to be able to push the web forward as a platform

AngularJS 1.x

Now one of the modules for AngularJS 2.0 is called Watchtower.js which is a change detection system. Now based off my understanding of this library, while it will use object.observe() if it is available, it does have a fallback system that provides pretty good performance improvements on the currrent dirty checking that AngularJS 1.x does. Based on this information, I asked the following question:

And the response I got from Brad Green was:

I was a bit disappointed. I could understand not doing this if it was not possible because of browser compatibility but that does not seem to be the case here. I would love to be able to volunteer to do this work (and that not totally out of the question) but I am very doubtful I would have the time to learn the inner-workings of AngularJS well enough to make this kind of change. Maybe someone else will be able to do this for 1.x (or I will find the time to do it myself).

Overall I am excited for the changes in AngularJS 2.0. I am sure we are a bit ways out from seeing 2.0 released (even though some of it's components are already up on github) and I probably wont be using it that soon after it is release but until then, I will be pretty happy using the 1.x series.

If your interested in keeping up with the latest developments on AngularJS you can always looks at the github repos or read the weekly meeting notes.

The issue I ran into was that when retrieving the value from the textarea element, if the textarea ended with a space, it was not your standard space, it was a unicode non-breaking space (\u00a0). When I did a console.log() on the value, it looked like a space however when doing a comparison to ' ', it was resulting false. After spending a few hours debugging the components JavaScript code, it turned out that the had nothing to do with the JavaScript code, it was the CSS.

The textarea had the white-space property set to nowrap. Now I can't remember why I did that, I sure I had a good reason as that time, but it was not needed. After reading the MDN documentation on the white-space property, it did make since what was happen. With setting the white-space property to nowrap, it was causing the ending space of the textarea to be saved as a unicode non-breaking space \u00a0. Luckily, I did not need the property so I was able to fix the issue just by removing it.

Just goes to show that something you might think is completely un-related is the root cause of the issue. I would have never thought to instinctively look at CSS for an issue with the output of the value for a JavaScript DOM element.