Lessons Learned as a Front End Developer

I have had the opportunity in a professional setting to work with a number of the various JS frameworks that are out there and recently I have caught the Vue bug.

Vue.js has moved its way up to what I would consider the modern top 3 frameworks now sharing the spotlight with Angular and React.  While it’s adoption ratio is still a ways behind the other two, it has a pretty lively community there is a lot of development of 3rd party libraries.   It is impressive for a framework to have moved so far without the corporate backing of mega giants like Google and Facebook.  

From a technical perspective Vue.js is easy to pick up and quite a delight especially if you are experienced in the AngularJs world.  I appreciate what the Angular team did when the created what is the modern Angular framework and while I feel it has its strong selling points Vue.js feels more like the natural evolution of AngularJs.  It takes what was there and expands on it adding many concepts and tools one finds in React.  

One thing I greatly enjoy about Vue is the single file component concept.  You write your html, js, and css (or whichever flavor of these your prefer) all in the same file.  One thing that really grated on me in developing with Angular or AngularJS was all the jumping around to different files when working with the same component or view.  This also keeps it simple for a testing perspective because all you need to know test this file is in one place.

Another feature I really enjoy is the Vuex store.  Now Vuex is a plugin to Vue and you do not need it to begin writing in Vue, but it almost feels if you are developing anything that is more than one or two simple pages, you will want to utilize some sort of global reactive store.  Vuex is a simpler implementation in my opinion to the rxjs workflows that were built into Angular.  It takes less time and code to add to the store and its easy to lazy load modules on the fly as needed.    Now this can be double sided.  It is almost too easy to put things in the store and use it as a kind of global catch all.  I have seen quickly how this can lead developers to misusing the store and and causing significant speed decreases in their applications.  I do however feel that quicker development time outweighs the risk in this case.  

I think another selling point of Vue is its ease of use.  It takes very little knowledge to get running in Vue outside of a general understanding of ES6 practices.  There are a few directives and things to get to know but most of it is quite simplified for the developer.   Now you can use Vue with TypeScript or pull in the Vue ESLint plugins to make your Vue code abit more opinionated, but at the end of the day those are choices that you or your team will make.  One of my big resistances to Angular is how TypeScript and extra knowledge is forced on the developer.  I think there is a place for frameworks that require a steep learning curve (lets face it C# .NET isn’t going anywhere) especially in enterprise development.  I do think there is a value in allowing the coder to choose when they want this bloat though.  Vue makes it self very friendly to the beginner or junior and I think that is very valuable.

I have had the opportunity to get a little more exposure to Angular (Angular 2+) over this past few weeks and wanted to talk through my initial thoughts. Now I have dabbled with Angular before but mostly just small one off things and nothing I would want to be part of a production application.

So Angular feels a bit cumbersome and slow to develop with to me, but part of that I feel can be overcome by becoming more comfortable with it like anything else you do it takes practice.  Though I do feel developing with it will always be a bit slower than its predecessor.  AngularJS just had less to set up to really use it in my opinion.  

So why is that?  Well AngularJS was pretty much vanilla pre ES6 JS or at least that was what I was used to.  As a result you did not have to worry as heavily about Dependency Injection, imports, etc... Sure you had to include things in modules, but at the end of the day as long as you named a service that AngularJS had access too you didn’t really care where it came from.  The trade off here is that by being a bit more verbose with imports and explicit DI Angular seems to be a bit safer and secure as far as always including exactly what you want. 

TypeScript also adds some complexity to this as well.  So I know you don’t have to use TypeScript but unless you are working in a vacuum and really don’t care about community documentation this really is not an option.  So TypeScript and ES6 syntax in general adds a bit of extra weight with building out classes, constructors, and needing to deal with strong typing.  You can get away from some of this, but you really dont get the true power of the framework if you are not using it all.

Now on the subject of community documentation, this is also a problem that I found slowed my development.  I was looking for information around the APP_INITIALIZER and while I was doing so I found docs for many different versions of Angular including beta stuff.  This made it really hard to follow some of this as Angular has changed so much since then and having to comb through docs and try to discern whether or not it is valid in the current version.  More than once I tried something I found only to find that what was recommended was now deprecated in the current version (5.x at the time).  While its awesome to see such innovation from the Angular team bad documentation makes the large community hard to take advantage of at moments. 

Now with all this said I find the IDE support to be incredible.  WebStorm has become my front end IDE of choice (I am exploring a few others at this time just to see what else is out there though...) and I find that most JS IDEs support a strong Angular integration.  I thought AngularJS had a strong integration, but on seeing such strong completion of classes and methods off of them I have learned how much better it can be and this is a speed boost.  

I consider myself someone who does his best to learn from past mistakes, but one thing that I continually see myself and others continue to make mistakes with is over and under abstraction.  Now I am going to talk about this from a Front End Code perspective, but I feel most of this can apply cross language and stack.

So to talk about over abstraction first, I recently have had the fun of working with a control that was designed in theory to work with any data set given to it.  Its first use however was with a rather complex data set, so it is riddled with conditional statements designed to check if the data it was dealing matched the complex data set or if instead it was anything else.  The code for handling everything else is remarkably simple but as this code only is currently used against the complex data set we never actually see if the other code works outside of simple unit tests.  In addition the code for dealing with this specialized set continues to get modified in the same file as the generic.  This has made development a real pain against any new features for this “generic” control.  The problem with all of this is we have realized way too late that we simply need a specialized version of this control purely for this specialized data.

With this in mind we probably should not have tried to make any of this generic from the beginning until it was needed.  Then when/if another data set needed to use this control we could create a generic control that uses the base underlying logic and functionality of the specialized one.  This gives us two cleaner implementations rather than one messy one.  However, does this line of thinking violate the DRY (Don’t Repeat Yourself) principle?   I would like to think that DRY like many things in life is not black and white.  Sure you don’t want to have duplicate code, but we also want readable maintainable code so I think DRY can bend at times.

Not abstracting until completely necessary can bite you in the end though as well.  In the same code base we performed similar functionality to filter on large sets of data on many different pages.  This functionality, was roughly the same on each page it appeared, however the types of filters could greatly differ as well as some of the logic that happened after a filter.  For this reason we abstracted some root logic but kept each of these separate and repeated a lot of code 10 plus times around the project.  When we realized one day how much we were repeating our code we underwent a huge refactor to stream line how all of this worked and to force all of these components to behave the same way for consistency.   The overhaul to do all of this was costly and time consuming but it made our development time so much faster after it was completed.  If we had followed the abstract when needed principle when we created the second or even the third of these, and began to create a common control to handle all of this we would have saved a lot of time much earlier on and not had to make such a costly refactor.

Knowing when to abstract code and make common functions, services, and components can be very difficult and is one of the biggest decisions we as Software Engineers face when we start working on a feature.  However taking a few minutes to ask ourselves a few questions can make this a lot easier for us.

Does this functionality exist anywhere else in the application?   

Yes) If the answer is yes can we reuse the functionality as it stands or with some work can we make it generic to use in both places.  If we can we probably should discuss that.  If not then it should be asked if it could it be written better to do so or if the use cases are too different.

No) If the answer is no and we are not going to immediately reuse it for an upcoming feature, then this probably should not be made generic at this time.

A few years back I was exposed to the idea of the testing pyramid and how one should write as few e2e UI automated tests as possible and do as much possible in the unit testing layer as possible.  When I first heard this I was a proponent of unit testing, but I argued against it because there are things I felt unit and integration tests could not catch.  That and writing protractor e2e tests against an AngularJS application was just so easy.

In truth I knew that if I really wanted I could simulate all of the button clicks and such in the unit and integration test layer as well and pretty much the only thing that would have to be tested on the automated e2e layer would be the full wiring along with some appropriate translation stuff.  So in a way I was violating a core principle by which a developer should work in doing the right thing over the easy thing in only writing functional unit tests.

Well fast forward a few years and I have begun to see the problem in flipping this pyramid on its head.  Automated e2e tests are far more fragile and can become flaky easily in comparison to the unit tests.  While writing e2e tests is simple it is also much easier to write tests in the unit test layer along side the dev code at the time of development.

In addition to the fragility, new frameworks are working now to encourage testing more in the unit and integration layer by making this simpler and more straight forward.  The recent work I have done with Angular (4.x) shows how easy unit testing could and should be for a developer and why the pyramid is flipped the way it is.  

So I dont know if I will continue doing this after each day, but I just wanted to express how blown away and impressed I am just after my first full day at ng-conf.  

So this is not my first conference as a developer, I have been to a handful and I do not want to knock any of the ones I have been to as each are valuable in their own right.  With that said ng-conf is an experience in and of itself.  

Each and every session on day 1 offered some great advice or thoughts which are all very practical and useful.  Even when sitting through a talk which started off with things I felt I already had a solid grasp on, one of the developers behind the project or an expert user would offer some twist or gem of wisdom that I had not considered.  Also each and every speaker was great at delivering their message whether it was sharing how the Angular CLI worked behind the scenes, talking about modules in Angular vs ES2015 modules, or even a talk about redirecting your negative thoughts in a positive creative direction (Just to name a few talks).  I highly encourage anyone who is working on an Angular or AngularJS project to take some time and catch some of the recorded sessions.

While you can watch at home being here is so much better for a few reasons.  I have never met a more friendly and welcoming group of developers at the conference where we could openly just chat about some of the technical issues we are facing whether it is performance, upgrading to Angular, or how we test.  I find that this is equally or in some cases more beneficial to talk to people who are in the weeds just like you and has given some perspective to existing plans or ideas or makes you think about looking at problems in a different way.

In addition to chatting with other developers there is of course the fun and social aspect of parties put on by vendors/sponsors, but the sponsors themselves are also a valuable resource here that you only get by being here.  I have already had a chat with a few sponsors and am looking forward to hopefully chatting with at least two more in the coming days to talk through some of the ideas they already have presented at the conference or put up in the wild.

Its been a while since I have posted here and while there are many topics that I wish to visit with this blog coming up especially with some of the things I have been exploring with Angular updates and Typescript I want to step back and talk about something that I feel is core to being a good developer or really a good employee, manager, or person in general.

A while ago I gave a book recommendation for Team Geek (the newer printings are called Debugging Teams) and in this book they talk about the three pillars that should be kind your guide to your every day work ethic and approach.  These are Humility, Respect, and Trust.  Now during my first reading I kind of glazed over this section thinking oh yeah one more list of three things to keep in mind.  Having been a Boy Scout, I thought well file that away many of the other Oaths and sayings I have heard in the past.  However given time to work with others and re read this chapter 4 times now, I have grown to really respect these values so I just want to take a few moments to promote these pillars as reminders to other developers.

So Humility, this is one of those easy to say hard to do things.  One might think sure I am humble I am open to criticism from my manager or a senior developer, but truly embracing this value is so much more.  To paraphrase a famous quote “Life is a classroom and everyone in it a teacher”.  This means many things to developers.  For one we need to be open to learning from any source no matter how junior and in what form it may be presented.  Just because we are well seasoned or think we know how to handle a situation it never hurts to listen to input.  You never know maybe it does not help you today, but maybe it will tomorrow.

Respect is honestly the simplest of these to understand and grasp.  The “Do unto others as you would have them do unto you” applies to your work life interactions too.  If you want to advance or succeed at your job you need to be willing to treat your coworkers with a degree of respect in order to get anywhere.  This ranges from listening to feedback as mentioned above, to being supportive, and communicating with your coworkers.  If you are getting frustrated with something a coworker is doing, before getting upset with them think about what you can do to improve a situation or what you might not be doing that has lead to the situation.  

Trust is a hard one, as the book illustrates many developers like to kind of hide in a hole and do their own thing and hide their code away from prying eyes or people that may add bugs to it.  However you have to trust in those you work with.  As mentioned above new ideas or improvements can come from anywhere so you have to trust your teammates to help you with that.  In addition you need to trust your coworkers to do the right thing.  You cannot always make all the decisions, even if you are the senior developer of a team at some point that junior dev you work with is going to have to spread his wings and fly so instead of sheltering them trust them to take on gradually bigger projects so that they can learn and grow.  

So I have been fortunate enough to work for a very great employer that allows Software Engineers to use a lot of personal creativity in approaches to handling day to day problems and challenges and I am here to tell you how valuable that is.  Engineers by and large are usually considered more technical than creative but when allowed space and time to problem solve and create solutions, often times the results will amaze and astound.

To further build on this idea some companies offer their Software Engineers a chance to express their creativity and ideas by going off rails for a few days in something commonly referred to as a Hackathon.  Now there are many forms of Hackathon, some are community code jams, but many companies have found success in allowing their developers to do so internally.  The Hackathon is a powerful tool and time for many reasons.

It is a time for developers to back off from what they are normally doing.  While I enjoy what I am doing and love the day to day work I am in there can be a sort of repetiveness to any work.  A Hackathon gives a nice few day break to step back and use something new or work with a technology you are currently using in a new way.  This time away is both refreshing and helpful for developers because on return you can see new angles on old problems when looking at things with renewed perspective.

Hackathon’s also sharpen a person’s skills.  Above I commented using a technology in ways that have not been used this is one of a few ways a developer can learn new things during this time as well as if they use something completely new.  However Hackathons also allow the development of more soft skills like team work, communication, planning, etc.. This is why in some companies you will see Hackathons like a project to change the lightbulbs in the office to be more energy efficient, or building a planning board to make life easier.  These projects do not involve coding persay, but they require lots of other collaboration that still makes them great for individual and group development.

So the other benefit of Hackathons is of course business value.  Now all things above provide value as well such as developer health and growth, but more than that comes from these events.  Developers pick problems they want to explore and some of these come from solving the pain points of their lives by developing internal tools.  These tools have the potential to go on to make the daily work of a developer easier which in turn can increase developer productivity and velocity.  Others are problems they are curious about which can open up new ideas and markets of business or features for a product.  A great example of this is Facebook.  The like button we are all familiar with started as a Hackathon and now it is a regular feature of facebook that many users ‘like’ to use.  It even has been enhanced to have more features as of late with reactions.

To start I do not claim to have a normal development background.  I got my start with development in C and pretty much hated it and moved straight to HTML, CSS, Javascript preferring the front end web stack.  I also learned a lot of this from what was at the time a bit more unconventional setting with The Iron Yard.  

While I was learning Javascript I was introduced to the concept of unit testing my code.  The first assignment I had on this I failed miserably and something with that kind of made things click that I needed to pay more attention these tests.  So from then on I unit tested everything I did, using a mix of behavioral and unit tests through Jasmine in all of my own projects at the time.  Now this put me at odds with most others I was learning with as many disliked unit testing and some just outright refused to write them.  Even I at the time was not fully sure of their value, but I wrote them all the same.

Doing this has saved me so many times in my own development.  As a presenter pointed out at a recent conference unit tests are like a safety net for your code.  They guarantee that your code works as intended, but they also protect you when you need to make a refactor to your code. In this situation a unit test can let you know if your refactor worked or not or if in refactoring something else you broke a dependent function. 

So with this in mind I forged ahead and became very comfortable unit testing in raw javascript, from this I was able to pick up unit testing strategies in JS based frameworks (such as Angular) with relative ease.  Now as I mentioned a recent conference above, I got a chance to chat with other developers and presenters.  It amazes me how few places actually rely on unit tests for their code.  In the agile world some shops believe testing their code is actually a separate story/concern than developing the functionality.  This is not true in my mind.  You would not buy a car or a laptop without knowing it had been fully vetted and the same should go for your code.  Now some may point out that you can manually make a test and verify that something works or does not, and this is true.  But what about two weeks from then, a month, 5 years.  Without tests no one will remember all of the edge cases to hit with a particular bit of functionality.  

Writing unit tests saves you time and money.  Now some functionality will have to be tested with end to end tests with something like selenium, protractor, etc..  Also there are somethings that cannot be tested with unit or e2e tests, but these are few and far between.  

Now that conference I mentioned dealt with Angular 2 largely and it has introduced the idea of model driven forms and this has me excited.  Basically model driven forms allow you to set your models, validation, and other form functionality up in Angular Components.  So what is the big deal?  It means that we can actually now unit test all of that form logic that required flaky behavior driven tests, or equally flaky e2e tests.  If possible unit tests should be your major line of defense when it comes to code quality and Angular 2 is shaping up to be a very testable framework.

Third Party components can both be incredibly useful and also a major pain to a developer all at the same time.  These can range from frameworks like Angular, Ember, Bootstrap, etc.. to tools and visualization components like Full Calendar, Google Maps, d3.js, etc..

Something I struggle alot with as a developer is when do I write something myself to meet my needs vs when I should find something that exists and not reinvent the wheel and I have found a few things helpful to keep in mind.

1. Dont reinvent the wheel.  

Odds are any problem out there that you will face has already been tackled by someone else in some form, so learn from their pain.  If someone has created a great responsive CSS framework, for example, that meets 90% of what you will need to do then by all mean it should be considered as something you want to use given license restrictions, performance, etc...  That work is done and if it is not over kill for what you need using it means you can focus less on duplicating what has been done and more on churning out awesome features for your end user.

2. Consider the Bloat and Time 

So maybe you find a great tool that does what you want it to do, say Google Maps, and you want to use it.  Thats great you certainly dont want to hand roll a mapping and geocoding service in most situations.  Now if you are using a framework such as angular and you come across some angular based wrapper for google maps the tendency from the prior statement is that the work is done for you, so maybe it is worth using as well.  This is not always the case.  You are adding a base mapping tool to your application which meets the needs of your project, adding a middle layer to communicate it can be nice if everything works out perfectly, but it will add additional size to your 3rd party files.  So the question is how much does it gain you and is it worth the bloat.  

Sometimes, it is like in the case of angular ui’s bootstrap wrapper.  It provides angular directives for common bootstrap controls and handles this very well.  That leaves one less control for you to have to worry about most of the time.

Other times such as with the mapping example it may or may not be as correct.  You have to consider what is the middle wrapper gaining you.  Is it saving you an hours work, two hours work, a days work?  If it is saving you time, how much time will your wrestle with it if it does not fully meet your use case.  I have found in many examples that these middle layers are great for what the person or group that wrote it needed, but not for all my use cases.  Generally in this case I would spend more time wrestling with it to get it the way I want rather than writing my own wrapper for what I need anyways.  In this example Google Maps is not all that hard to work with and would only take a short amount of time to write a wrapping directive for, plus there are many great examples on how to do it online.  The majority of the time when you write a component or tool yourself you will end up with something more narrowed in on your needs and therefore less bloated.

3. Troubleshooting and Complexity

So when I get past these first two considerations the next thing that comes to mind is how difficult will this be to trouble shoot should something go wrong.  In the map example say you are trying to render a map with a few points on it and you get the map showing but all of the sudden your points are not showing on it.  Well now you have to check your code, the calls to the mapping provider, and any middle layer you may have added.  Where as if it is just your code you are more familiar with what to look for.

In addition while adding third parties can make less work up front stacked third parties can add update complexity.   Take angular-ui for example.  When a new version of angular comes out that you want to update to, you may have to wait until the version of angular-ui is updated to handle it.  This can slow the ability to use new features or potential fixes for bugs and issues.   

4. Consider why you dont want to write you own

Why are you looking for a 3rd party for your solution.  If its to fix a large thing like mapping, charting, etc .. that can be reasonable.  However, if it is because of fear of the unknown or tackling something new, maybe it would be worth trying it to learn something new yourself.  The only way to grow as a developer is to challenge yourself.

A year ago if I had read this I would have read this title on my blog I would have assumed that this would be about why I hate bootstrap.  I would have given a list of reasons as to why bootstrap is a terrible horrible thing, but I may have seen the light and learned to be a bit more open minded.

So Twitter Bootstrap is a framework that can do a number of things for a web application, most commonly it can provide simple consistent reusable styling for a clean look and feel.  

Now this sounds amazing so why did I hate it so passionately? Well to me Bootstrap created so many cookie cutter web applications that all felt way to similar in design, colors and layout.  Every time I would think of using bootstrap I would end up planning how to override 90% of its base behavior and styles to create something unique and that to me was wasteful.  It always seemed like writing some custom css was the way to go.

Well, I may have been wrong about this and a few other conceptions about bootstrap.  So the custom css route can work on a small application or site because realistically you do not need much to be able to create a simple clean small app.  Scaling this gets messy though especially when you factor in other people touching the same code base.  When everyone begins working on writing custom css styles get easily overwritten duplicate styles get created and well your css becomes several times larger and slower than it can be if you do not have a clean place to start from.  Now it is possible to avoid this, but it is far easier and more generally scalable to start with a strong base like Bootstrap, Foundation, etc ... 

So what are some strong bases that are provided by a framework like Bootstrap?

1. Responsive Scaling

Perhaps Bootstrap’s strongest point is its responsive grid.  The grid allows developers to quickly and easily change layouts for common sizes with just a few common classes.  Without this you end up with a mess of media queries in style sheets that typically are not consistent.  

My old school of thought had me creating a new query every time something needed it on the page, so for a given page I could have like 10 different media queries.  This was not a solid practice on my behalf and does not scale well in a larger application.  

Bootstrap offers you a nice column based approach for folding and expanding layouts at various sizes with its column sizing classes.  With this content easily can all adapt at once to main recognized breakpoints.  Now I already knew about this feature when I first dismissed bootstrap, but what I did not realize back then was how much more there was too this.  Not only can your wrap content this way, but Bootstrap also provides helper classes to allow things to appear or disappear at these breakpoints.  This kind of functionality makes code much more maintainable that a bunch of individual media queries.

2. Consistency

With Bootstrap or any other framework in an application multiple developers working in the same application can gain a level of consistency that is not easily doable with custom css.  This comes from how bootstrap sets generic clean styles to form elements, typography, containers, etc.. When a button is created on a page with bootstrap classes it will be the exact same as any other button in the application and can use the same primary, secondary, and disabled values because those all come out of the box. 

Now this is something I used to think of as more of a weakness (forgive my ignorance) because it to me created tons of pages on the internet that all had identical buttons.  I know now this does not have to be the case.  If you desire unique forms, buttons, etc.. you can take and change up the consistent style with tools provided by Bootstrap.  They even offer community created and maintained themes out on the wrap bootstrap site.  So if you want to change your application to look like an NC State site you can get that theme and all the styles will be updated to match the NCSU standards.  This provides a certain power and quick startup that can cost a lot of developer time and energy that does not need to be put into it.   Why reinvent the wheel after all.

3. Ease of Use

Looking back at the arguments I made in the past it is almost laughable to see how my views have shifted.  I used to criticize Bootstrap’s ease of use saying why does it matter how easy to use it is, base CSS should be easy to any developer.  What I did not consider back then was the ease of learning a class structure unique to your style sheet.  Ramp up time teaching someone custom classes and conventions is expensive, plus if a class is misused or misnamed future alterations to that class can be pretty bad for all parties involved.  

Bootstrap on the other hand has a well known class structure and follows patterns that almost any web developer can pick up quickly even if they have not seen it before reducing ramp up time.  In addition it provides great standards by which to create more reusable elements.  For example most of bootstraps buttons follow the “btn-*” naming convention.  Say you want to create a style for circle buttons in your application, “btn-circle” becomes a good common sense name that is easy to follow.

In Summary

As with all things time changes opinions and mindsets (Just ask Donald Trump).  So I guess you could say I have seen the light, I understand more now the value that a tool like Bootstrap can provide and how much better and easier it can make the life of a developer when used properly. 

Recently I have even been working on a small website for a friend and I pulled bootstrap in just for a few of its nice features.  I could have coded that functionality in myself, but why reinvent the wheel when someone else has done the work for me to make my life easier.  This already being done left me more time to focus on other ways to improve this site and further meet the clients expectation.  

So why am I writing this particular blog post about things that should be common sense to many other developers out there?  I guess its partially a selfish post to remind me of why I should keep an open mind, forcing me to put these thoughts down.  It also is in a way there for anyone else struggling with openness or rejecting Bootstrap or another piece of technology.  I encourage anyone struggling with a dislike of a tool, component, etc... to take a step back and really evaluate their thought process.

So the Amazon Echo has been on the market for a while now and I recently got the opportunity to hack away a bit at one and I learned quite a bit from the experience.  

First and foremost I do not get out of my standard Front End Web code stack all that often and while this was not too much of a departure using node.js to program a simple application it still was nice to get out.  That being said you can pretty much define most of you need to do with Alexa with node and not really need too much else.

Now before I go to far into these lessons I used aws to host all of my code as lambda functions.  This can be done in other ways but for sake of time this is the route that was taken.   Basic code and instructions on how to do this can be found here.  

Lesson 1: File structure: So following the sample demo provided above it is easy to create a simple lambda function using the AWS inline editor.  However this method breaks down when you have need for more than one file or folder.  AWS covers this by allowing you to upload a compressed folder of files to run against.  So in theory this should be rather simple.  However, this was my first time working with AWS in such a way.  So in order to do this with an Echo Skill, one must upload the files with an index.js file.  Echo will try to run index.js, so if this file is missing the whole skill will break down.  

You can have more than one file that gets used by index.js but these files must be compressed together and uploaded as a compressed folder.  This is where I ran into my first issue.  You cannot compress the folder containing these items.  If you do so the process will fail.  Instead you must select the files and folders you want included and then compress them, not the folder containing them.

Lesson 2: NPM:  So the basics of the Echo Skill I was writing called for it to make a simple REST call to a cloud hosted api.  This sounds like it should be easy, but in my green state with node I actually ran into a few problems with this.  So in order to make efficient REST calls an npm package was added for restler a REST based library for node.   From another blog post online, it seemed that the lamdba function should force an npm install before execution of the Echo Skill, but upon further inspection this was not happening.  This may have been a wiring issue, but I found zipping up the node modules folder along with the rest of my code solved this issue.  

Lesson 3: Sample Utterances and Slots:  Once a lambda function is all ready to go the Echo Skill is wired up in the Amazon Developer console.  Here a developer has to define a few things.  A developer needs to point to the code for the skill, wire up the phrase to run the skill, as well as wire up any utterances and slots to accept from the user to trigger specific functionality.  I could go on for a while about many different take aways from here but I will break it down to two key things learned.

First crafting both your utterances and run phrase is very important and some thoughts need to be kept in mind

Keep wording simple and short where possible.  Echo’s speech recognition is good, but longer phrases generate more room for error.  In addition hard to pronounce words can be misspoken easily or misheard 

Avoid using words key to Echo’s functionality.  So often times when a word such as ‘order’ needed to be said Echo seemed to forget the skill and jump into its amazon shopping mode trying to order somethings. Some words to avoid are:

Order

Play

To Do

Remind

Purchase

Make sure to test your phrases audibly.  Its easy to test whether your function runs from the developer console just by typing the phrase, but just because it works there does not mean it will be easy for the Echo to understand your phrasing so be sure to test it in the console first but run a few device tests too.

The other major take away I had involves using slot parameters with Echo utterances. So Echo will allow someone to write an utterance like:

ApplicationIntent add the following to my achievements {achievement|Achievement}

So what this translates to is when a user says ‘Echo run YOURAPPLICATION to add the following to my achievements climbed the Tooth of Time.’  you have created a parameter that collects what is said after ‘add the following to my achievements’.  So one would expect ‘climbed the Tooth of Time’ to be passed into your Lambda function.  However, in this example only ‘Time’ would have been passed through.  This is because if inside the ‘{...}’ only one word is before the ‘|’ Echo will only pass the last word that is said.  In orde to capture everything said simply add as second word before the ‘|’ like below

 ApplicationIntent add the following to my achievements {cool achievement|Achievement}

Now ‘climbed the Tooth of Time’ would be passed through to your inner functions.  

Using ‘var’ to init a variable or method in javascript should be just second nature to most by this point, but I was recently reminded of the importance of this.

In a small angular directive I wrote a function that accesses a parent controller and gets scope from it to return some shared values.  I had multiple directives off of this scope that all did the same thing, and I stored the retuned scope object in a variable named ‘parent’ that was only used within the context of the link function of the directive.  

In my work on these directives I missed the ‘var’ statement on one of these parents.  The app still ran perfectly fine, but recently some bugs cropped up with a third party library that does some analytics through the window object.  It then came to light that the app was modifying the window’s parent property because of the missing ‘var’ to init it.  The app assumed we meant window’s parent.

I wanted to take a few minutes and plug a book that I am currently reading.  Team Geek is an amazing read for 95% of the developers out there.  As developers working with others can be difficult but it is often a large part of what we need to do.  Whether it is working with other developers, managers, or end consumers a developer needs to be able to be a team player.

Team Geek gives a great portrayal of the short comings developers have when it comes to working with others and helps to discuss how to improve yourself to be a better team player.  The first few pages alone proves to be very eye opening as the book immediately launches in to talking to the developer themselves about how to be a better team member and slowly branches from their in later chapters to talk about working with other team members.

I personally have benefited largely from this read already.  I think a lot of this is owed to the book being written by actual developers who are in the thick of their careers sharing the experiences they have had and communicating information in a way that makes  sense to the working developer.  

As I continue to work with Angularjs I continue to be impressed by all of the power the frame work offers a developer that can be leveraged to do some really neat things. 

Recently though I had need to build out a dynamically generated list from an array of variable length with each needing a watcher on a boolean to check for a change to that boolean.  This sounded simple enough to do to start.  Simply utilize ng-repeat with that array and you are off to the races.  

I had already created watchers with ease before so I figured it was just a matter of figuring out which $scope.$watch function to use.  Was it a simple $watch, $watchCollection, or $watchgroup.   Also should I watch the array as a whole or should I watch the objects, or the booleans themselves. 

Suddenly what I had thought simple became more thought provoking.  It became more infuriating then thoughtful though as I delved into implementation.  It seemed that nothing I tried would actually watch for the change in those boolean flags.  I tried all of the various options above but angular seemed unaware of the boolean as it changed value.  It would note the initial setting of the values from the watcher, but nothing else after that.  

So after spending a long time trying to make it do what I wanted I finally gave in and asked for help from a more experienced angular developer.  He showed me a different way to watch an object then I was used to.

I had always used the format:

$scope.$watch(’array[0].boolean’, function(newVal, oldVal){...});

He showed me that when the “magic string” does not seem to grab the value that you are looking to watch you can tell angular specifically which value to watch by returning it in a function like so:

$scope.$watch(function() { return array[0].boolean}, function(newVal, oldVal){...});

So I have been delving into the world of angular as of late and have created my first set of cascading directives that transclude each other.  This capability is one thing that makes angular such a powerful app framework.  It gives you the ability to create a directive that you can put your own html in with a transclusion.  In that html you can call another directive that also does some transclusion and continue your cascade.  These children directives can also require their parents in order to be able to make sure they are not called out of context.

This multi tranclusion is extremely powerful and allows for a lot of customization within the file.  However there is a lot of room for problems with this methodology.  

One major issue I ran into was passing scope from the called directive down to the transcluded html template.  It seems a change was made in angular a few versions ago that prevents some scope leak by preventing a directive template from passing its scope down to its transcluded child.  This issue caused me no small amount of grief and several hours of work and rework before I finally found this useful github bug filed for this very issue.  https://github.com/angular/angular.js/issues/7874.

The inject directive here solved this problem completely for me to pass the scope of one directive down one level to its child.  As a forewarning this cannot be used on multi levels as it sits.  In other words you could not call inject on a parent directive and then again on its child.  

The other major issue I ran into involved the performance of rendering my transcluded directive templates to the DOM.  This was primarily due to the existence of an ng-repeat as part of one of the directives.  I found three great ways to increase performance.

1. One way bind elements where ever possible.  A lot of items in a repeated list do not need to be two way bound and by removing the watchers it significantly decreases the speed to render. 

2. Remove conditional checks where able.  Directives like ng-if, ng-show, and ng-hide really slow down rendering because for each item there must be a pause to check to see if the condition is met before moving on to render more.

3. Use “track by” on your ng-repeat declaration.  This is especially important if there is any paging or rerendering of this list.  Without this angular virtualizes a reference to each repeated item and has to generate some reference value.  If each item comes back with a unique identifier then angular does not need to do any extra work to refer to them.

Recently the abundant use of Material design on the web has really caught my eye.  It seems to be the new in thing on the web and everyone is in a rush to implement it.   

Personally, I do see some of the attraction and am planning to try a few implementations myself, but I would not say that I am jumping on the band wagon just yet.  

In this growing age of mobile technology designers and web developers talk of the need of thinking Mobile first, Desktop later.  I like this principle.  It teaches you to use space wisely and forces you to think of what the end user needs to see and what is actually important to them.   Material components to me can support this model because they can look great on both, or am I missing something?

When I go to many pages implementing material design they have great mobile sites and apps.  They really plan out how to make an awesome mobile experience. However, when I look to the desktop versions of these sites it seems that they failed to implement anything different other than a blown up version of the mobile app.  Has the new trend become Mobile First, Desktop Never?

Google's new Inbox app is a great example of this.  It is very user friendly on the phone but on the desktop there is a lot of wasted space and buttons that are still optimized for mobile.  There is large space to the left and right side of the email section that could really be better utilized.  In addition frequently used actions could be exposed as the screen width increases.  Now I am not trying to complain about Google in particular here but since they are one of the larger companies behind the material movement I feel they are a prime example to call out.

I think that we as developers and designers need to remember that while mobile design and implementation is very important right now, that desktop usage is still very important as well and applications and sites need to be optimized and styled for both.  Desktop development does not need to be the very first thing you develop and design but it should be there in the back of your mind as a mobile design is worked through.  

So recently I have been working with LESS style sheets a lot more and I came across an oddity when using the calc() function.  To set this up I was using multiple LESS files that would compile down to one CSS file before being served to the client.

While working I had need of the calc() function to calculate the height of an item and make it the height of the screen minus the height of the header.  This was a simple enough calculation: calc(100vh - @headerHeight);  

I learned quickly enough that LESS runs the calc() function when compiled down to CSS and instead of having a calc function in my CSS, I had the value 60vh (headerHeight was 40px). 

After a little bit of research I discovered that I needed to defer the running of the calc() function to the CSS by using the syntax: ~"calc(100vh - @headerHeight)";.  

Now the calc function was being handled by the CSS, but I had a new problem.  CSS cannot handle a LESS variable, so I needed to pass the value of the LESS variable down instead of the variable so I rewrote the function once more to be: ~"calc(100vh - @{headerHeight})";