Blog Title

IOS Web Service

2012-08-08T00:00:00Z

This following example is a small snippet of code I found to call a simple web service and return it to a NSURL string. You will need to use a XML parser to parse your web services data. This web service sends the request information in the url.

-(BOOL)CallService:(NSString *)value
{
    // Call web service to verify a session object or string
    BOOL result = YES;

    // Create the objects for calling the web service
    NSString *buildURL = [NSString stringWithFormat:@"https://coryrylan.com/web-services/MyWebServices.asmx/myServiceCheck?IDReceived=%@", ID];
    NSURL *url = [NSURL URLWithString:buildURL];

    //Call the request
    NSURLRequest *urlRequest = [NSURLRequest requestWithURL:url;
	cachePolicy:NSURLRequestReturnCacheDataElseLoad
    timeoutInterval:1];

    // Create the objects for parsing the xml data returned by web service
    NSData *data;
    NSURLResponse *response;
    NSError *error;

    // Call the web service
    xmlData = [NSURLConnection sendSynchronousRequest:urlRequest returningResponse:&response error:&error];

    NSXMLParser *parser = [[NSXMLParser alloc] initWithData:data];

    [parser setDelegate:self]; // You can create a parser method to remove any whitespaces or apending chars if needed

    reply = [[NSMutableString alloc]init];

    // Read the xml data returned by the web service
    [parser parse];
    if([reply isEqualToString:@"yourErrorResponse"]) //If your service returned ect do this
    {
        ErrorMessage = @"Error";
        return NO;
    }

    if([reply isEqualToString:@""] || reply == NULL) // Else if no reply do that, or use error object
    {
        //No reply from web service
        ErrorMessage = @"Connection Error";
        return NO;
    }
    return result;	//Else return the result or error
}
//XML PARSER
-(NSString)parser:(NSXMLParser *)parser foundCharacters:(NSString *)string
{
    reply = [NSString stringWithString:string];
    return reply;
}

IOS Journey Load Animation

2012-08-20T00:00:00Z

This following example is a small snippet of code to create a small loading animation for your IOS apps in Objective C.

UIActivityIndicatorView *loadAnimation = [[UIActivityIndicatorView alloc]

initWithActivityIndicatorStyle:UIActivityIndicatorViewStyleGray];

loadAnimation.center = CGPointMake(160, 220);

loadAnimation.hidesWhenStopped = YES;

[self.view addSubview:loadAnimation];

[loadAnimation startAnimating];

IOS Journey Load Multi-Threading

2012-08-20T00:00:00Z

This following example is a small snippet of code I found to create a separate thread from the main thread. This allows you to process information without holding the main thread. For example if a web service is taking a while to load or respond if on the main thread the application may shut down because it believes the application has locked up. This allows the user interface to be usable while loading.

// For asynchronous threading use the following and place code within brackets.
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT,(unsigned long)NULL), ^(void) {
    // Example Thread separate until view loaded then push
    [self.navigationController pushViewController:myViewController animated:YES];
});

// For a separate thread place your method call in the following selector.
[NSThread detachNewThreadSelector: @selector(MyMethod) toTarget:self
withObject:nil];
// To break out of the current thread and process something on the main use the following:
[self performSelectorOnMainThread:@selector(yourMethod) withObject:nil waitUntilDone:YES];

IOS Journey the Observer

2012-08-20T00:00:00Z

The NSNotification observer allows you to add a observer which watches for a certain event to trigger. This is useful if a view come into the display or the app is resumed from being suspended in the background. This example is setting an observer to the UIApplicationDidBecomeActiveNotification. When this event occurs the selector of the method of your choosing will fire. This is useful if the app has been suspended and need to update its information via web service.

[[NSNotificationCenter defaultCenter] addObserver:self
    selector:@selector(someMethod:)
        name:UIApplicationDidBecomeActiveNotification object:nil];

IOS Character Counter

2012-08-23T00:00:00Z

This following example is a small character counter that can keep track of the number of characters in a text view that needs to be limited to a maximum amount of characters.

//Only check if text field has been altered
-(void)textViewDidChange:(UITextView *)textView{
    //500 chars max
    if([[textView text] length] > 500){
        //If max reached close keypad
        [textView resignFirstResponder];
        //Append off extra chars
        textView.text = [textView.text substringToIndex:500];
    }
    //Count and display amount of chars left
    CounterBoxLabel.text = [NSString stringWithFormat:@"Characters left: (%i)", 500 - [[textView text] length]];
}

Javascript JQuery Ajax

2012-08-29T00:00:00Z

This following example is a small snippet of code for a AJAX web service call to
a .NET service with JQuery. We will be sending a email and name to our web service to sign up for a email subscription.

/*JS Email Subscription AJAX web service*/

callService();

function callService() {
  // Here we will create our data object to send. In this example we are
  // sending a email subscription request. We will send a email address and a name.
  var data = {
    email: $('#emailTextBox').val(),
    name: $('#nameTextBox').val()
  };

  $.ajax({
    type: 'POST',
    url: '/myWebServices.asmx/emailSubscription',
    data: JSON.stringify({ data: data }),
    contentType: 'application/json; charset=utf-8',
    dataType: 'json',
    success: function(response) {
      if (response.d == true) {
        alert('You have been subscribed');
        //Do any work you want if the web service was successful.
      } else {
        alert('Error');
        //Or throw a error
      }
    },
    error: function(error) {
      alert('error');
      //Or throw a error if service failed
    }
  });
}

Agile Development Is Not Bad

2013-03-19T00:00:00Z

I often hear proponents to agile code say that it makes sloppy untested code.
I feel that this is incorrect and should be addressed. The idea of rapid deployment and agile code development is simplify how we think, write, and source control our code. By breaking our code into smaller iterations they become more maintainable and easier to deploy.

Code proves whether a theory works or not. Trying to make all the features for a product or making them perfect only delays your releases and puts strain on your team. By making your features small and easy to release you also make them easier to test. Would you rather test a small feature set and release or a large milestone with many features? We should be testing as we go but often a large milestone is pushed to production then the team is inundated for weeks with bug or feature fixes. If we would keep the milestones small and light we can fixes problems as we ship and keep our products shipping without halting our development cycle.

By rapid deployment we can get immediate feedback from our customers and users. Nothing is more detrimental on the morale of a team than to spend months on a feature only to find out that the customer does not like or use it. This could of been prevented by releasing a small simple version of your feature. It does one thing and one thing well. We would of gotten feedback about the core idea of our feature much sooner and save many resources doing so.

Agile code comes down to one thing. Simple. Simple feature, simple idea, easier tests. The core idea is retained. The product or feature is in its most simple state it becomes easier to test and maintain. So in summary, keep it simple, keep it short, test early and often with users. Deploy, receive feedback, correct, and repeat. Following this cycle will help you keep your code clean and maintainable while getting your product out there.

Emotional Interfaces

2013-03-19T00:00:00Z

As web developers and designers it’s our responsibility that our users have the best experience possible. This may seem like obvious advice but is often ignored or put on the back burner on larger scale projects. The interface is what the user initially responds to. It’s comparable to a first impression. If our interface fails to convey our message or have a good impression we have lost our user before they have even used our product.

Our interfaces cannot lie. Interfaces must reach a human connection conveying our intent clearly. This usually is the case for any good design. But to convey our message clearly we must be careful with our context and content. Our context is what gives our interface the human element. Think about any emails or text messages you have received in the past. How often did you read the message in one tone or context to find out later that was not the true meaning or intent of the message? Was the tone meant to be more serious? Was it lighthearted and fun? This often happens with our users. The tone and context of our interface can distort our true intent we want for the user.

How we design must be intertwined with our context, content, and emotion. This can help guide the user without glaring messages or instructions. It should feel natural as if it were a human to human conversation. They understand your tone and intent immediately, this helps the user become comfortable with your interface. If you can accomplish this your users will return and enjoy their experience every time.

The Performance Advocate

2013-03-19T00:00:00Z

I wanted to write this after working on a large mobile first responsive redesign. Our project goal was to redesign a static desktop site to become a clean fast responsive website to allow all devices to access our website.

Often our design process was interrupted will feature implementation and last minute changes. A feature or design was added in all good intent but was never questioned about how this could effect the site performance. Note to clarify I will refer site performance to front end performance and not server side performance. Most of your site speed will be on client side based on load, render, and script performances.

We had multiple developers implementing multiple featured and page modifications. Front end performance may not be your teams strong suit but should always be top priority in you implementations. Not everyone knows the pitfalls with client browsers. To resolve this teams should always have a Performance Advocate. This person should always question performance with any design or feature implementation. Even if the idea seems solid, question it. Test it on multiple devices and networks. Find the pitfalls and issues that could arise. Your Performance Advocate could commonly fall under the job title as a Front End Engineer or Front End Dev Ops, etc.

The Performance Advocate should focus on these three main issues with every decision:

Render Performance ( Perceived Load Time / Jank )
Page Load Weight
Script Performance

There should be strict performance standards in projects and the Performance
Advocate should help enforce these standards. These standards could be the following:

Maximum Page load with no cache will not exceed 500kb anything else will be deferred
All Javascript will be deferred after onload
No inline JS
CSS should never be more than 3 selectors deep or exceed 30kb total
All static resources are minified and Gzipped into single files on a CDN
Our maximum onload requests is 5 everything else is deferred.

These are just a handful of example standards the team should establish.
Define them in the beginning of the project. They should become part of code reviews and testing. Project performance standards should never get in the way of emergency bug fixes. Performance guidelines should be at the project level. Some projects may require more lenient or strict rules. The advocate should check these standards with every feature. If the feature breaks a rule then the team must meet to determine how the feature can be implemented while meeting the guidelines. Without the advocate the end result could be a slow product. If the advocate challenges this before code is even touched we can keep the performance in the design from the beginning creating a fluid and fast application.

For features or systems already in place that did not meet the standards the development team should set time or budget to fix these issues. The advocate or anyone should submit issues, pull request or cases to fix the issues. Make it aware that your team is delivering a sub par product by not fixing these problems. The idea of the performance advocate is NOT that only one person should worry about performance, the ENTIRE TEAM should always focus on performance. The advocate is a assigned role to ensure and enforce the performance standards of the project.

The breakdown
Design > Question > Implement > Test > Reflect

Design your feature or application
Question the performance issues and address the issues
Implement the code and correct any performance issues
Test, test your audience, mobile, low end devices, mobile networks, etc.
Reflect, did we meet the budgets and performance guidelines? If not back to the drawing board to come up with improvements.

Thoughts On Large Mobile First Responsive Project

2013-11-11T00:00:00Z

These are just some of my thoughts after working on a large mobile first responsive design project. These are some key points or highlights that I feel were most important in the project construction.

Design

Ensure a designer or dev with design experience designs features not devs or clients to prevent poor typography and missing design fundamentals
Include front end engineers with the design aspects to be an advocate for performance but able to contribute to the design
Wire frame the html and css mobile first then upwards defining your breakpoints
Build all html and css then pass on to backend dev team to hook up to sever, allows clean markup and eliminated repetitive styles
Have style guide created with html and css before project begins.
Do not allow client to make last minute design changes, causes rendering bugs to be introduced unexpectedly

Styles

Use SASS, helps keep your code DRY
Only 1 to 2 people on Styles ( CSS, SASS, LESS) ( issues will duplicate styles and poor render performance ) or Module out your application between designers

Implementation

Design mobile first and performance first
Have a Performance Advocate
Set performance rules and guidelines and follow thoroughly
Set support guidelines such as minimum browser requirements for your application
Be very cautious of browser sniffing as it add code complexity and can bite you later ( Bad sniff ). Feature detection is always better.
Ensure that your server side framework compliments your front end code and does not work against it. If so then change it.
Use progressive enhancement to build site resilience to failure such as lack of features or graceful degradation.
Have no Javascript fall-backs for at least key features. Not just for no js users but for network resilience such as js failed to load because of weak mobile network.

2014 Blog Update

2014-01-05T00:00:00Z

So its been a great year for me as a student and part time web developer. I was able to work in a great responsive web site EstateSales.NET and learned much from it. Now that its 2014 I will graduate in the spring and I have officially been hired as a full time web developer at Vintage Software. Excited to start new projects this year. This year I will be focusing on some new topics.

Web performance on responsive web sites.
Maintainable responsive design
Resilient web design
Off-line support on web applications

Look for me on Github & codepen.io for any new projects or want to collaborate just
tweet me @coryrylan Happy new year!

Web Con, University of Illinois Conference Notes Part 1.

2014-05-01T00:00:00Z

Here are my notes from University of Illinois Web Con 2014. These are from the talk
"Life without a BS Foundation"
by Kianosh Pourian.

"Build a framework around your design not design around your framework."

Cons for using front end frameworks such as Twitter Bootstrap and Zurb Foundation:

Not semantic
Naming conventions not established/documented poorly
Performance issues (bloat)
Little to no file structure especially Sass project for Bootstrap
Difficult to update
Design implementation frameworks fall short
Does not follow the DRY principals
Overriding is very difficult and tons of extra code and uses little of the framework
Editing the framework breaks any update
Impossible to create a framework for everyone
CSS is old and part of the issue
Spend a lot of time learning someone else's code
Not ideal for enterprise or large applications

"When building a site or web application, one must build it for success. Success means that small projects will evolve into large projects.

What to do:

"Do the sh*t yourself"
Write your own CSS
Create Style Guides
Use Sass or a preprocessor
Follow OOCSS Principals
Atomic Design
Organize your code in modules in folders (each folder is a atom or module)
The global import file should have comment of what the modules are being imported for
Have a unified naming convention
Folders helps packages modules for individual consumption
Learn from frameworks such as Twitter Bootstrap and Zurb Foundation

Web Con, University of Illinois Conference Notes Part 2.

2014-05-01T00:00:00Z

Here are my notes from University of Illinois Web Con 2014. These are from the talk
"Learn Every Programming Language" by Patrick Delancy

4 programming paradigms

Procedural
Logical
Functional
Object Oriented

Procedural

Loops
Procedures/Functions/Subroutines
Global/Static Variables
GoTo
Lexical Scoping

Object Oriented

Class/Entity
Abstraction (interfaces)
Encapsulation
Inheritance
Polymorphism

Functional

Focuses on the process and not the entity models
Functions as values
Pattern Matching
Composition
Partial Application
Monad/Computation Expression
Closures (JavaScript and C#)
Deconstruction/Decomposition
Currying (JavaScript)
Recursion/Tail Recursion
Option/Maybe
cons/car/cdr

Logical

Facts
Relationships
Very declarative

Site Performance Review 8/2014

2014-08-01T00:00:00Z

So I decided to take a performance review of my own personal site after some optimization work and write about some of my findings. I did a average content breakdown on my home page and will cover a few other pages that load different resources.

I calculated all the resources for first time view on my home page with gzip. I do not include third party resources such as Google Analytics and Disqus because they are usually async and are outside of the developers control.

Content Breakdown for coryrylan.com (home page gzipped)
Resource	Size	Percentage
HTML	2.5kb	2.9%
CSS	7.5kb	9.0%
JavaScript	0kb	0%
Images	17.8kb	20.9%
SVG	23.2kb	27.4%
Fonts	33.6kb	39.8%
Total	84.6kb

JavaScript

If you closely you will notice I have 0kb of JavaScript. Excluding Google Analytics this is correct. I have other JavaScript dependencies on my site I load only when needed. I use Disqus for blog comments. I also use Prism.js for code examples on my blog as well. On my Contact page I use JQuery & JQuery Unobtrusive Validation library for my contact form validation. Listed below is the content breakdown of all JavaScript resources on my site.

JavaScript Breakdown (gzipped)
Resource	Size	Percentage
JQuery & Validation (Contact)	46.6kb	90.1%
Prism.js (Blog)	5.1kb	9.9%
Total	51.7kb

CSS

I only have one CSS file that is minified. I use Sass as a preprocessor for my CSS. I generate a separate CSS file for ie8 non media query support.

CSS Breakdown (9.0% gzipped)
Selectors	695
Rules	382
Total	7.5kb

Performance side note, because my CSS is so small I can inline this in the head of the document to get a faster paint time. This is because the server will not need to go get a CSS file to start rendering the screen. I have tried this and it does improve speed but I have not yet found a build process that I am happy with to automate this.

HTML

I have one HTML page requested from a prerendered view on the server. I do not
pull any dynamic content except on blog post comments.

HTML Breakdown (2.9% gzipped)
Resource	Size	Percentage
Home Page	2.5kb	100%

Images

I have two images on my home page currently. I have one JPG and one SVG background. I do have images
on other pages of my site such as blog posts. All my images are compressed and gzipped.

Images Breakdown (48.3% gzipped)
Resource	Size	Percentage
Image of myself	17.8kb	43.5%
Background SVG (gzip fails)	23.1kb	56.5%
Total	40.9kb

SVG

Performance side note, currently SVG images are not gzipping on my Azure host and I am working on a solution. This causes a extra ~15kb to be downloaded. If anyone knows of a solution please feel free to comment.

I load in two font sets for my site. The first is Roboto Regular for my base font. The second is a custom built icon set from Fontello.

Font Breakdown (39.8% gzipped)
Stat
Fontello	6.5kb	19.2%
Roboto Regular	27.3kb	80.8%
Size	33.8kb

Performance tests can be skewed because if you request the browser to prefetch/prerender other pages in the background to make them load faster. I turned this off while running the tests. Prerendering doubled my load time because of loading resources for other pages even if the requested page was completely rendered. This skewed my page speed index score. This applied to webpagetest.org and not to Google Page Speed

Performance Stats
Load time	1.689s
Start Render	0.996s
Speed Index (3G connection)	1291
Google Page Speed Mobile	88/100
Google Page Speed Desktop	95/100
6 Requests	84.6kb

Overall my site has pretty good performance. My Page Speed Index is around 1291 on a 3g connection. My Google page speed mobile ranks a 88 out of 100 and desktop a 95/100. Good scores but definitely can be improved. My major performance issue currently is my SVG images not gzipping. I am guessing some type of config issue. My other major performance issue is CSS loading. I can optimize my CSS by inlining in the head or deferring the unnecessary parts. I also could defer loading of my web fonts to improve render time and make the site useable sooner. I'll be post a update after working on some improvements and see how much faster I can push my site.

SVG gzip in Windows Azure

2014-08-04T00:00:00Z

When running a Windows Azure website you may run into a problem I came across with gzipping content. By default Azure websites are very easy to set up and have little maintenance cost. Most of the performance features are turned on by default with one exception. SVG images seem to not gzip on website instances.

Azure Websites seem to also ignore the web config overrides for this as well.

Unfortunately the way to turn this on is to use Web Roles. I did not want to deal with that hassle so I created a controller to handle incoming SVG requests as recommended from these two posts, [Stack Overflow](http://stackoverflow.com/questions/17029543/enable-gzip-compression-for-svg-in-azure-web-sites) and [Asp Weblogs](http://weblogs.asp.net/jongalloway/asp-net-mvc-routing-intercepting-file-requests-like-index-html-and-what-it-teaches-about-how-routing-works).

Thanks to David Ebbo (@davidebbo) he pointed me in the right direction in making a better solution. it turns out you can get gzip to turn on for SVG with the web config. The solution is below, as well as the comments.

<configuration>
   <system.webServer>
      <staticContent>
         <mimeMap fileExtension=".svg" mimeType="image/svg+xml"/>
      </staticContent>
      <httpCompression>
         <staticTypes>
           <remove mimeType="*/*"/>
           <add mimeType="image/svg+xml" enabled="true"/>
           <add mimeType="*/*" enabled="false"/>
         </staticTypes>
      </httpCompression>
   </system.webServer>
</configuration>

The key part I was previously missing was the <remove mimetype="*/*" />.
If you read the comments by David it seems that this will be fixed and turned on by default on the next Azure update.

ASP MVC Critical CSS Performance

2014-08-06T00:00:00Z

I recently did a performance review of my own site and have added multiple improvements. One of best improvements was optimizing the loading of my critical CSS. By including the critical CSS inlined in the head of the HTML we can send in a single response everything the browser needs to start rendering our view. The browser now does not have to wait on a request to a external stylesheet. Try to keep the total size of the HTML and inlined CSS to around 14kb. This will allow the browser to more likely receive the HTML file altogether and not receive it in multiple portions across the network. This reduces latency and improves the render speed. This is difficult to achieve but is a good goal to shoot for.

The hard part is determining what is critical to your view as this can change on a page to page basis. My site is fairly simple so I deferred CSS such as animations, web font definitions and print styles as they are not necessary to get the view painted to the screen. There are many tools to help identify your critical CSS. UnCSS and Grunt UnCSS on GitHub are great tools to help automate this process. I am not going to cover these tools in this post, I'll be focusing on how I was able to get my CSS inlined into my ASP MVC views.

The first set up I have is I leverage Sass to precompile and organize my CSS in a modular style. I group all my non critical CSS in one CSS generated file. This file I load asynchronously using the Filament Group's LoadCSS. Using this I can defer my CSS until after page load. This example uses the MVC bundling feature with a no js fallback.

<head>
  <script>
    // loadCSS
    function loadCSS(e,t,n){"use strict";var i=window.document.createElement("link");var o=window.document.getElementsByTagName("script")[0];i.rel="stylesheet";i.href=e;i.media="onlyx"o.parentNode.insertBefore(i,o);setTimeout(function(){i.media=n||"all"})}
    loadCSS("@Styles.Url("~/bundles/deferred/css")");
  </script>
  <noscript>
    @Styles.Render("~/bundles/deferred/css")
  </noscript>
</head>

So now that we are deferring our non critical CSS we inline the CSS needed to render what is visible when the HTML loads. I bundle and minify my CSS with Sass for this bundle as well but you could use the MVC bundling tool. Even better use a Grunt/Gulp task to identify exactly what critical CSS the page needs. A side note, any JavaScript in the head should be async so it does not prevent the browser from the critical render path.

To inline your CSS you can use the following line in your views.

<style>
  @html.raw (File.ReadAllText(Server.MapPath("~/Content/Sass/all.min.css")));
</style>

This is a really easy simple way to improve performance on your site if it has a small amount of CSS. If you have a large site with large CSS files I would recommend leveraging a Gulp/Grunt task to identify what CSS should be deferred.

Site Performance Review 8/2014 Part Two

2014-08-11T00:00:00Z

I recently did a performance review of my own site. In this post I am going to cover what I did to improve my site performance and what challenges there were. Here is my site before I started optimizing my pages.

Old Performance Stats (Home Page 3G connection)
Load time	1.689s
Start Render	0.996s
Speed Index (3G connection)	1291
Google Page Speed Mobile	88/100
Google Page Speed Desktop	95/100
6 Requests	84.6kb

Gzip and SVG

So the first major issue for slowing my site down was my SVG images not gzipping. I load a large background SVG onto the site that was about 23kb. I looked into why my Azure server configuration was not gzipping SVGs and I came up with a solution. Unfortunately this was the most difficult issue to resolve. I wrote a blog post on what I did to fix this here, SVG gzip Windows Azure. After resolving this I was able to compress the SVG background down to 7.6kb.

Fonts

The next fix to improve performance was to optimize my fonts. I use Roboto as my font site wide. Loading in a custom web font really slows down the text render time on the page especially on mobile. So the first thing I did was go to fontsquirrel.com and subset my copy of Roboto. Before sub setting my file size was 23.7kb total. After sub setting I reduced my file down to 17.6kb total.

Next I deferred loading of my font until after document load. This causes FOUT (flash of unstyled text) but if the web font is lost in the network or slow to load the browser will be using the default system font until the custom web font is loaded. I used the Filament Group's awesome script LoadCSS. Something I noticed is if you use the HTML5 prerender/prefetch feature it can minimize FOUT on the next page. I only noticed this in Chrome.

CSS

Deferring your non critical CSS and inlining critical CSS in the head of the document can greatly improve your render times. The idea is if you inline your CSS the document the CSS will arrive with the document and the browser can start rendering your page immediately. The browser does not have to wait to load in a external stylesheet. The tricky park is knowing what to inline and what not to inline. Only inline the minimal amount to render above the fold content. Anything else can wait. The other issue is you need to keep this inline small. You don't want to bloat your HTML pages with inlined CSS. The ideal amount is to keep your HTML and inlined CSS to a total of 14kb This helps ensure the file is sent altogether. This is a difficult guideline but a good
one to shoot for.

The CSS I chose to defer were selectors that dealt with animations, font loading, icon fonts, and print styles. All of this CSS was unnecessary to get the first time render to the screen. I used the LoadCSS script to load in me non critical CSS. I wrote a small blog post on how I inlined critical CSS for a MVC project. I used unCSS to analyze what selectors were not being used and removed unnecessary ones as needed.

The Aftermath

Here are my performance test scores now after all of the optimizations.

New Performance Stats (Home Page 3G Connection)
Load time	1.3s
Start Render	0.7s
Speed Index (3G connection)	994
Google Page Speed Mobile	98/100
Google Page Speed Desktop	100/100
6 Requests	68kb

First paint with text to screen in less than 1 second on a good 3G connection. [#perfmatters](https://twitter.com/hashtag/perfmatters?src=hash) [pic.twitter.com/HqNg493Z3O](http://t.co/HqNg493Z3O)
— Cory Rylan (@coryrylan) [August 2, 2014](https://twitter.com/coryrylan/statuses/495618360089268224)

Overall the work was well work it. My site can now render in one second on a good 3G connection and half a second on a cable connection. Optimizing client side performance can be difficult at times but with good tooling it can be a automated process of your builds.

AngularJS Controller As Syntax

2014-09-12T00:00:00Z

Angular JS has some great MVC, MVVM or MVW (Model View Whatever) patterns. In Angular there are a few different ways to declare and use a controller. Lets look at the most common way using the $scope object.


<section ng-app="app">
  <div ng-controller="ScopeExampleCtrl">
    {{message}}
  </div>
</section>

'use strict';
var app = angular.module('app', []);

app.controller('ScopeExampleCtrl', function($scope) {
  $scope.message = 'This is a model value from the $scope syntax.';
});

So this works great no issues but lets look at the Controller As syntax that was introduced in Angular 1.2


<section ng-app="app">
  <div ng-controller="ControllerAsExampleCtrl as example">
    {{example.message}}
  </div>
</section>

'use strict';
var app = angular.module('app', []);

app.controller('ControllerAsExampleCtrl', function() {
  this.message = 'Value from the "Controller As" syntax.';
});

This syntax does a few things for us. The first benefit is we don't need to bring in $scope as a dependency. This cleans up our controller a bit. We can directly add any properties we want on our view by using this on the controller. You can still bring $scope in as a dependency if you need to use other things such as $watch or $on. This allows you to easily be able to see controllers that may have special exceptions than your average controller.

Nesting Controllers

In the view the ControllerAsExampleCtrl as example the example creates a instance of the ControllerAsExampleCtrl for that controller's view. So lets look at why this is important.

In the next example we have a simple controller that assigns a string to the scope value of message. We inject the $scope object as a dependency of the controller. So what happens if we nest two controllers that happen to have the same property of message?


<section ng-app="app">
  <div ng-controller="ScopeExampleCtrl1">
    {{message}}
    <div ng-controller="ScopeExampleCtrl2">
      {{message}}
    </div>
  </div>
</section>

'use strict';
var app = angular.module('app', []);

app.controller('ScopeExampleCtrl1', function($scope) {
  $scope.message = '$scope value from Controller 1';
});

app.controller('ScopeExampleCtrl2', function($scope) {
  $scope.message = '$scope value from Controller 2';
});

If you look at the HTML it can quickly become confusing to understand which property belongs to which controller. This is even worse when we have base controllers or large sections of HTML that divide up the controller declarations. Take a look at the same controllers but using Controller As to bind their values.


<section ng-app="app">
  <div ng-controller="ControllerAsVmExampleCtrl1 as example1">
    {{example1.message}}
    <div ng-controller="ControllerAsVmExampleCtrl2 as example2">
      {{example2.message}}
    </div>
  </div>
</section>

'use strict';
var app = angular.module('app', []);

app.controller('ControllerAsVmExampleCtrl1', function() {
  this.message = 'Controller As value from Controller 1';
});

app.controller('ControllerAsVmExampleCtrl2', function() {
  this.message = 'Controller As value from Controller 2';
});

If we use the Controller As syntax we can avoid this issue. It simplifies the code and makes it clear which property belongs to each controller. This also helps us from not having to use the $parent property. When you declare with Controller As we get a single instance of that controller with the name that you define. So we have a instance of ControllerAsVmExampleCtrl1 named "example1," and a instance of ControllerAsVmExampleCtrl2 named "example2." This prevents the name properties from possibly colliding with each other.

Controller as VM

Attaching our models using this on our controllers leads to a clean syntax but what happens when the context of this changes?

'use strict';
var app = angular.module('app', []);

app.controller('ControllerAsVmExampleCtrl1', function($scope) {
  this.message = 'Hello World';

  $scope.$watch(
    function() {
      return this.message;
    },
    function(newVal) {
      console.log(newVal); // 'undefined'
    }
  );
});

The issue here is this.message in our $watch method now references to the function execution context instead of the this.message on the controller. To fix this we could use .bind() This would fix the issue of this referencing the function instead of the controller but there is a better way. We can assign this to a variable called vm (view model).

'use strict';
var app = angular.module('app', []);

app.controller('ControllerAsVmExampleCtrl1', function($scope) {
  var vm = this;
  vm.message = 'Hello World';

  $scope.$watch(
    function() {
      return vm.message;
    },
    function(newVal) {
      console.log(newVal); // 'Hello World'
    }
  );
});

By assigning this to vm we solve the issue of the this context. We also gain a clean looking view model for our controller. This follows more of a MVVM style pattern. We can easily see anything attached to our view model can be accessed in our view. This has become my preferred way to write my controllers on all my Angular projects.

Using the new Controller As syntax brings some great benefits to our code including scalability and readability of our controllers and views. I have been using this on a large scale Angular project and using this syntax has created great benefits to the code. To read more about the Controller As syntax check out the docs at docs.angularjs.org.

AngularJS Application Organization

2014-10-06T00:00:00Z

There are many ways to organize a Angular project. I am going to cover the ways you can structure and name your project files and the pros and cons to each. Lets first start simple. A brand new project usually starts with a app.js file. This is usually where you have your app declaration, app dependencies and route definitions. When first starting out in a new Angular project this is actually a very good idea. Just starting with one file will keep things simple while you learn.

Lets take our application one step further. We have been adding more to our app and now have multiple Controllers, Directives, Filters, and Services. So the next organizational method we can choose is to break our single file into multiple Angular module types. We can have one JavaScript file for each of our file types. Each for Controllers, Services, Directives, and Filters along with our app.js file. All of these can live in our application folder. Now when we are looking for say a Directive we can go look into the directives.js file. This is good for small applications and still keeps things relatively simple and easy to learn.

So looking back at organizing our modules by type what happens when we start getting multiple features? We don't want to be working on a single feature and have to sift through multiple Controllers in the Controllers file when we really
are only focused on one thing. This leads into our next pattern, organizing by feature.

By organizing our code by feature we can focus on the specific task at hand without having to search through code that is not relative to the feature we are
working on. We can add all the modules related to that feature in a single JavaScript file that has a descriptive name. This means we can easily browse our application and find where exactly the code is for that feature. This is great for small to medium applications.

This last pattern for organizing our Angular project is for medium to large scale applications. If our features grow to be large or complex in nature it is not wise to have a single large file for each feature. This will make it more difficult to maintain that given feature. So taking the previous method one step further we will break our features up for our Angular module types (Controllers, Directives, Services, Filters). Each Angular module gets its own file with a descriptive name inside a folder that has a well thought name for that feature.

This gives us the most flexibility to grow in our application. By each feature organized by folder we can quickly drill down to the feature we are looking for. In each folder we have multiple files each containing a single module. This makes the code maintainable and lowers the cognitive overload of large code files. This is my preferred way to organize angular applications and offers the most room to grow your application.

Other pros and cons to the feature based module organization exist as well. A con to this style is it complicates our build process. You would not want to include all these files individually in our application. This would cause heavy network latency to download all them separately. Instead you will want a build step to concatenate and minify all your source files and any dependencies together into a single file. This will keep your application fast and quick to download. You can use tools such a GruntJS or GulpJS to automate this process. These tools are build task runners your can run in NodeJS.

Another advantage to the feature based and individual module files is testing our JavaScript. By organizing our files in this style we can organize our tests to match the exact same pattern. The tests can all exist in a separate folder
form the source code. Each module file has a single corresponding test file all the test are in a single folder named by that feature.

IIFE and module closures

Closures can be very important when in comes to isolating modules and bugs in any JavaScript application. As we follow the pattern of each Angular module receiving its own file I'll show you my preferred method of structuring that module. Using the Immediately Invoked Function Expression Pattern (IIFE) we can close off our module from leaking outside of its scope. Example:

// Module 1
(function() {
  'use strict';
  app.controller('HelloWorldCtrl', function() {});
})()(
  // Module 2
  (function() {
    'use strict';

    app.factory('helloWorldService', function() {});
  })()
);

This pattern creates a anonymous function that is created and executed at runtime. This isolates our modules code. This can be important from preventing name collisions when we concatenate our files together. If you notice we also have the statement "use strict" in our IIFE. The "use strict" is a ES5 optional property that gives us some protection against some poor design patterns. If a object or variable is used without a definition that normally would be created on the global object "use strict" with cause a runtime exception protecting us from accidentally polluting the global scope.

File Naming

The last thing I want to cover is file naming. There are some unofficial Angular naming conventions you can follow. You do not have to follow these but just make sure your project is consistent in the naming and any team members understand this as well. First we can start with naming Controllers. A common naming pattern for Controller names and the file name is the following: HelloWorldCtrl and helloWorldCtrl.js. Controllers tend not follow the traditional camel case pattern you often see because a Controller is treated somewhat as a constructor. You are "newing up" a instance of that Controller at runtime. File names tend to follow camel case and the same name as the Controller. Next are services.

Services follow a similar naming convention. helloWorldService and helloWorldService.js. Services usually end in the word Service. The file and module name follow the camel case pattern. Filters use camel case on the module name and file name. Filters are not suffixed with filter like Services and Controllers. Example customCurrency and customCurrency.js.

The last naming convention to cover is Directives. Directives when registered in the Angular application are camel case, phoneValidate. This Directive when used in the HTML follows snake case, <input phone-validate /> (Angular handles the conversion and expects this format). The filter source file follows the Snake Case format, phone-validate.js.

So we have covered naming our angular modules and defining our file structure based on our application size. There are many ways to set up a Angular JS application just remember stay consistent and try to follow the community conventions whenever possible.

TL;DR

all one file in app.js
all in one folder, multiple files ordered by type
all in one folder, multiple files ordered by feature
multiple files and folders organized by feature and type
follow some sort of naming convention early on
each file should be singe module/feature in IIFE with strict mode

JavaScript ES6 let

2014-10-30T00:00:00Z

There are some very exciting features coming to JavaScript over the next few months in ES2015 or known as ES6. Not all browsers support all of the new ES6 feature set but you can use a transpiler such as BabelJS or TypeScript to transpile ES6 to working in the browser ES5. Browsers are actively working on these features and some you can try out today.

This post I am going to cover the let statement. let brings some new functionality that will help keep our code from falling into some of JavaScript's tricky parts.

JavaScript ES5 and earlier has function scoping available. It turns out you can do just fine with function scope but programmers coming from a Java or C# background may get tripped up from using block scoping. So lets look at a example.

function foo() {
  var bar = 0;
  if (true) {
    var bar = 1; // Same variable
  }
  console.log(bar); // '1'
}

In this example foo() returns 1 even though the inner bar assignment is in the if block. This is because the inner bar assignment is not scoped to the if block but rather the function. This can be a common source for bugs. In JavaScript any variables declared in a function are hoisted to the top of the function. So the previous example is behaves as if you wrote it in the following format.

function foo() {
  var bar = 0;
  var bar = undefined;
  if (true) {
    bar = 1; // Same variable
  }
  console.log(bar); // '1'
}

The inner bar is hoisted to the top of the function then reassigned to equal one in the inner block. Another common case of this behavior is in for loops.

function foo() {
  var i = 'hello'; // Same variable
  for (var i = 0; i < 3; i++) {
    // Same variable
    console.log(i); // '1 2 3'
  }

  console.log(i); // '3'
}

We get back 3 instead of 'hello' because our i variable was hoisted to the top of the function. As you can see this can cause confusion and introduce bugs into our code. So using the new ES6 let statement we can solve some of these issues.

function foo() {
  let i = 'hello'; // Different variable
  for (let i = 0; i < 3; i++) {
    // Different variable
    console.log(i); // '1 2 3'
  }

  console.log(i); // 'hello'
}

Using let we can block scope our variables and prevent them from being hoisted. Using let also prevents the accidental creation of duplicate variables. We will get a error if we have two variables named the same and declared with let within the same block. var would of silently
and override the first declaration.

function foo() {
  console.log(bar); // ReferenceError
  let bar = 2;
}

function foo() {
  let bar;
  let bar; // TypeError
}

Once you start using ES6 its recommended to always use let over var for variable creation. This will help keep consistency and prevent confusion of the two. let and many other ES6 features will make JavaScript easier to maintain and use for the future.