Book Review: Getting Started with Twitter Flight

I recently read Getting Started with Twitter Flight by Tom Hamshere. The book was published in October 2013. Another book was also published around the same time. To my knowledge, these are still the only two books about the Twitter Flight framework.

The book is very short; Chapter 1 marks 18% progress. There is nothing wrong with a short book. To me, it alludes to the simplicity of the Flight framework.

Furthermore, there is a bit of content dedicated to justifying choosing Flight for your next project. Again, I do not believe this is a flaw of the book. As developers, we want to know about success stories with a framework we are considering.

The Good

Tom does a good job of highlighting what Flight is and is not. For example, he brings up the fact that Flight does not have a data model system. He also points out the absence of an included templating engine. Better still, the author touts that these things are not “missing”; they are intentionally left out, and that gives you more flexibility to choose what works best for your project.

I really appreciate the author’s recommendations for event naming throughout the book. He takes this to another level by dedicating an entire chapter to the cause. Even if you disagree with the actual convention Tom shares, his points on devising a naming convention are spot on.

Mixins can be tricky to grasp for many. The book’s chapter on them goes into exceptional detail. In fact, Tom makes certain to answer questions a reader may not know will be on his/her mind soon after starting to use mixins. He tackles mixin order/priority, method extension, advice, and mixin composition (mixins within mixins).

The Bad

Chapter 4 dives into setting up a Flight application. I felt this chapter was a little too tool-oriented. It aims the user at using Yeoman to generate the scaffolding of Flight pieces. I understand this approach makes for a very fast “get up and running” scenario, so maybe I am over-criticizing.

In contrast, chapter 12 discusses testing Flight components and mixins from a more agnostic view. There is a brief mention of the Jasmine-Flight and Mocha-Flight test extension projects. However, most of the examples show how to get at the necessary Flight objects in order to exercise them with assertions for any test framework. This is okay, but it does not fit the approach used elsewhere. I found it very odd to see a section on “Extending Jasmine for Flight”. The Jasmine-Flight project already does just that (and is referenced at the beginning of the chapter), so I do not understand the reasoning for this content.

Throughout the book, I spotted several mistakes with the code examples and corresponding discussions. Managing code for a book is not trivial, but I did expect higher quality for such a short book. Most of the mistakes were typos or names that obviously changed over the course of refactoring. However, a few of the mistakes are outright incorrect code bits. I read another review of this book where the reviewer stated he submitted errata that he discovered. Upon looking on the publisher’s website, I could not find any errata listings.

In the same spirit of errata, I do expect to see some attempts at upkeep for a technical book. By that I mean, as the framework changes, readers should really be able to see notes about areas of the book that are no longer relevant. How else will a newcomer make sense of the content when attempting to apply it to a later version of the framework? One simple example is the “defaultAttrs” property of a component. In a later version of Twitter Flight, the property was renamed to “attributes”.

A much more drastic example of this is with regard to the author’s opposition to the use of nested components. The author starts the book touting no “parent-child” relationships among components as a strong plus for a scalable architecture. In chapter 13, Tom details the problem with using nested components and how to get around their use. However, the Flight team recently released the withChildComponents mixin to handle just that; child/nested components. If you do some forum digging, you can even find that Tom had a part in a similar mixin when his team (of TweetDeck) created the withTearDown mixin internally and began probing the community for interest in open-sourcing it.

This is a perfect example where the author should come back to the book and make some amendments based on his own changes in viewpoint. I found forum posts about his team’s belief in the power of nested components since the book was published. That information is certainly worth knowing to a reader of a book that is just a little over a year old! At least add a note on the publisher site with a link to a blog article. Better still, revise the book as a second edition.

The Ugly

The “ugly” is named such because it is the part of the review where I offer my recommendation for or against this book. I also hate being on the fence.

Were there a better book available for the Twitter Flight framework, I would not recommend this book right now. I would not, because it feels like the book was published and never thought about again. I can live with the errors, although an errata list would be ideal. All the issues combined with the fact there are no amendments or notes about changes of the author’s views just add up to a total that is less than whole for me.

Since I have not read the only other book on Flight available, I cannot say with certainty that you should not read this book. Information on Flight is hard to come by; trust me on this one. Therefore, anything you can get is worth reading. However, be very mindful of the content; do some research, and try it out for yourself. You should be able to discern the gospel from the opinion if you are careful.

Why We Switched from AngularJS to FlightJS

The landscape for web development is rapidly changing. It seems like not too long ago, I was making a decision with my team to avoid using JavaScript in our projects due to browser inconsistencies; that was actually 15 years ago. Since then, we’ve seen jQuery, HTML5/CSS3, Modernizr, and an ocean of other JS frameworks.

Haste Makes Waste

How do we (web developers) keep up with all the JS frameworks popping up monthly? That is a challenge indeed. The thing I try to remember is, rushing to adopt the latest thing can lead you and your team to a painful misery.

Sure, you should check out these frameworks. Read about them, code a little with them, run some tests with them. Just don’t go all-in with a framework for the sake of “being current”. Avoid heavy rewrites of your system(s) without knowing how key parts will perform under the new regime.

Angular is Super-Awesome

Pro AngularJS (Expert's Voice in Web Development)AngularJS is quite different than most of the MV*1 JS frameworks out there. Angular lets you, basically, extend HTML to your liking. This is a key concept for the framework. There is a very strong template engine built into Angular around this extension concept. Furthermore, directives provide developers with the power to extend HTML however they see fit. For me, the thing I really like about Angular is its two-way data binding.

Angular’s two-way data binding makes me smile. With other similar frameworks, you either get one-way data binding, or you get some twisted mass of wrappers in order to achieve mostly two-way data binding. Now, I’m fine with one-way binding, if it’s easy enough to get the data out when I need to. However, if you’re going to offer two-way data binding, it has to be seamless and unencumbered.

I loathe having to wrap my models in some specialized structure. It’s even worse when I have to use multiple types of wrappers depending on what type of model I’m using. The worst of all is being forced to not only wrap my main model with a certain wrapper object, but also having to then wrap some properties on that model further with other wrapper objects. Yeah, I get why it’s considered required in order to achieve the goal.

Angular works with plain old JavaScript objects (POJO). I love that! It just knows when the user changes an input value tied to a property on my model and updates my model when that happens. It also watches my model for changes via code and then updates any input values in the UI automatically. Brilliant! Yes, there are some performance concerns with constantly polling objects.

There are a ton of books on AngularJS. Even a top 10 seller on Amazon (at the time of this writing) for all JS development books is on AngularJS!

So, Why Abandon Angular?

If you are expecting to read that we “abandoned” AngularJS for FlightJS because Flight is better, well…go back and read the introduction of this article. I learned that lesson long ago. You really should have good reasons against the framework already in-place before deciding to leave it. I try to never make such decisions purely on how much I like some other framework over the current one. That mentality will have you hopping from rewrite to rewrite, and your projects will suffer.

We also didn’t abandon AngularJS. We’re watching it’s future and viability carefully though. We still have projects using it where a decision to switch has not been made at this time.

Like so many frameworks, AngularJS has some strict rules you have to follow (once you learn them) in order for everything to work together. It’s to be expected to some degree. However, when you find that your creativity or ability to generate behavior in your application suffers because of those rules, you have a problem.

With AngularJS, try getting field validation on a form that doesn’t trigger on most fields until the user moves focus from the corresponding input, but also doesn’t trigger on some fields until the form is submitted. I dare you! Can it be done? Sure. However, it is a horrible, ugly mess to get something like that working due to limitations imposed by the framework.

Let’s not argue over the viability of the above validation request. The scenario I’ve depicted is actually one with proven UX benefits, no matter how poorly I’ve described it here. That’s not the point anyway. What gives Angular the right to tell my team how to implement a good validation UX? None.

We also found creating custom directives of any heft was somewhat painful. Having to avoid DOM manipulation outside of directives (never tweak the DOM from a controller) added tons of extra ceremonial code just to fit that restriction.

Scope is cool, but it is so misused in a lot of “educational” material, it’s hard to tell how it should be used. Even the official learning documentation uses Scope frivolously. There are several articles about using Scope properly. It’s obviously not so obvious how you should use it.

We’re not the only ones spotting the flaws. Others are questioning if this is a fad framework. You should always question a framework and its direction. If it changes for the worse, stick with a version you still trust, or look to get out. Have you heard about AngularJS 2.0 and the direction shift it’s taking? Don’t judge 2.0 just yet; wait for it to release first. However, be prepared for massive change.

The Angular Way

I’ve seen/read/heard so many times that you need to do this or that “the Angular way.” That’s half the problem though! There needs to be more flexibility. I’m not talking about how you need to use dependency injection with a framework, or that it relies on jQuery. What I’m talking about is how much of a pain it is to utilize other external libraries with a framework. Before AngularUI’s Bootstrap project hit the scene, it was very painful to use Bootstrap components with Angular; I’d say impossible, but that’s just lazy.

So, what if I’m a Foundation user instead? Again, it took some time, but some folks came up with directive projects to integrate Foundation with AngularJS. Still, it feels clunky to have to go to all that trouble just to integrate with other libraries. Pick another, lesser-known library and there likely isn’t something out to easily allow you to use it with Angular. What’s more, you’ll be putting in a lot of time writing your own integration.

You should control your framework, it should not control you.

How is Flight Different?

Getting Started with Twitter FlightFlightJS is very different. I won’t say it is better for all the reasons already included above. However, for my team, on many projects, Flight will be a better fit for us. You should read about it, see it in action, play around with some code, then decide if it’s a better fit for your team. Don’t take my experience with Flight as a de facto. Flight utilizes the built-in strengths of HTML and JavaScript. Specifically, it uses the DOM (document object model) and its event model. You author succinct components and attach them to DOM nodes. These components are complete islands; no component can reference another component, by design. Absolute decoupling of components is key to Flight’s power.

Communication is Important

So, if no component can reference another component, and each is a small, self-contained bit of behavior, how do they all communicate? Just because a component cannot directly hold a reference to other components, that doesn’t mean no coordination can be achieved between groups of components. I don’t have your cell phone number, but I’m communicating with you right now.

Events are the sole form of communication between components. When one of your components does something notable, it should publish an event about that accomplishment. Sometimes, events are just notifications that something was done. Other times, components include full details about what was done. Other components subscribe to the events they care about and respond how they see fit.

UI components are attached to a specific DOM node that they work against and possibly manipulate. This type of component subscribes to events within its node to respond to user interactions (i.e., click, change, keydown, etc.) and to other external events. These components also publish custom events that make sense to the system (i.e., ui-user-list-requested, ui-user-selected, etc.).

Data components are attached to the document node and don’t mess with elements in the DOM. Instead, they provide non-visual behavior (AJAX interactions, data sorting/filtering, etc.), then publish events about those tasks (i.e., data-user-list-retrieved, data-user-selection-saved, etc.).

How to Manage All Those Events

If you think about all the tiny little components you could end up creating in a given application (Twitter has hundreds in play on what seems like a simple front-end), you may wonder how it’s possible to keep track of all the events each publishes and subscribes to.

It can certainly be a tangled web of event names to manage, but remember; each component will likely only be concerned with a handful of events. That said, if you misspell an event when subscribing, even your tests can’t catch it if you think you spelled it correctly.

I use Trello to manage the components that need to be worked on. I also use shared documents (for my teams, they are on Google Drive) to catalog every event that is published by components on a page. I am also toying with the idea of writing a simple Node.js tool to parse a project’s components in search of event publishing and subscribing in order to generate a living document of event usage.

Mix It Up

Composability is another feature of Flight I find remarkable. This may seem counter-intuitive considering that components aren’t allowed to reference other components. However, there are other ways to achieve composition. Flight uses mixins to “include” shared behavior with your components.

Suppose you want to encapsulate a form in a component and make it modal when shown. You could write a dialog mixin. Your form component could then “mix in” the dialog mixin to extend its behavior with modal focus. Likewise, if several components you are authoring have many shared behaviors, even with slight variations, you can write a mixin to act as a “base type” for those components. You can even override just the bits you need to for any mixin your component uses via advice; a special type of mixin for just that purpose.

Wait, ‘X’ and ‘Y’ are Missing

There is no template engine in FlightJS. There is no data binding in FlightJS. These things are “missing” intentionally. Flight doesn’t impose those things upon you. That does mean you need to handle those things yourself or via other libraries. However, I have found it freeing.

Why should a framework tell me I have to always use client-side templating? What if server rendered views retrieved via AJAX are the most performant for my application? I should have the freedom to choose how I render information to the user on an individual basis.

In fact, in one of our websites (a hybrid with separate areas that act sort of like SPAs themselves), we discovered that for some views server-side rendering was much faster. Yet other views benefited most from client-side templating with raw JS object data bound to them. With Flight, we were able to choose what worked best for each situation.

More Information

There is very little information about FlightJS out there compared to more popular frameworks. In fact, I’ve struggled quite a bit to find much of anything. I did buy the book shown above; Getting Started with Twitter Flight. It’s written by a Twitter developer that works on TweetDeck, so you can count on accuracy and insider knowledge of the framework. The book has been invaluable for some of the finer points of Flight.

Another great way to learn is to also read the tests written for the framework.

Who are “We”?

I’ve been referring to this elusive “we” and “my team” throughout this article. I work on several teams, as lead on most (but not all). I can’t reveal all of those I’m discussing in this article outright. However, I can talk about one very small team.

My team at Wish on a List is currently in the process of moving from AngularJS to FlightJS. I plan on writing about that transition on this blog over time. We’re over half way done, so there is plenty to write about from our perspective.

1 MV* indicates an array of patterns that all share concepts of models and views. It’s the last parts of the patterns that differ; thus the *. Some of the many MV* patterns are: MVC, MVP, MVVM, MVPVM, etc.


SecuritySwitch Grows Up on Google Code

Edit: Due to a trademark infringement, this open source project will now be named SecuritySwitch. What a huge PITA it was to migrate to a new project on Google Code! Since you cannot rename a project, I had to create a new one and move everything over to it. I so enjoyed blowing 2 hours of my day off on Good Friday.

I recently posted about an update to my WebPageSecurity module project to the newly named SecuritySwitch. One of the best ways to ramp up coding on the project again is to get it into a public code repository.

Get with Git?

I thought about using Git on GitHub, but I want to get moving on this and that would not be the case if I had to fumble through learning Git now. Although, I do really like the concept of a distributed version control system (DVCS). Instead, I will stick with Subversion (SVN) for now.

Google Code

That lands the project in the capable arms of Google Code, which I find to be a very nice new home for SecuritySwitch. I will likely have a dedicated page here on GeekFreeq for SecuritySwitch that refers visitors to the project on Google Code, and/or I will just pipe updates from the project site here via RSS.

Anyway, this is the first stage of a “grown-up” SecuritySwitch.

WebPageSecurity becomes SecuritySwitch

Edit: Due to a trademark infringement, this open source project will now be named SecuritySwitch. Feel free to read the comment posted by the holder of the trademark on the name I originally planned to use. It was a polite enough message. I think there may be ground for me to stand on with the first name, but I don’t care to go to court over the name of a project that is free for anyone to download.

After a bit of a struggle supporting my WebPageSecurity module on Code Project, I’ve decided to put some quality effort into the project in the very near future. One of the first things that needed attention was the name.

What’s in a Name?

Could I have named it something more generic all those years ago? Perhaps, but not likely. After a few minutes of running through some of the key nouns and verbs that describe the project’s purpose, it will now be known as SecuritySwitch.

Educational Value vs. Quality Functionality

Another change to the project will be the maintenance of the dual source code languages. Since I originally started the module, a distinct project for C# and VB.NET have been maintained. While this was great for the educational aspect of the article and accompanying code, it is not ideal for a quality “product”.

After some consideration, I decided to drop the VB.NET version of the source code in favor of a single project written in C#. An immediate benefit to the community of this decision is faster releases.

What’s Next?

All of this change should be balanced with something to make it all worth while. I intend on stopping development on the 2.x version of the module for .NET 1.1 where it is now. Of course, I’ll fix any bugs, but no new features will likely be added. Version 3.x for .NET 2.0 will continue until version 4.0. That’s when I will add some of the new features in the queue and enable full support for ASP.NET MVC as well.

Keep checking back for more progress on this project.

ASP.NET “Remember Me” Option with Forms Authentication Not Working?

ASP.NET Login Control
ASP.NET Login Control

So, you’ve set the timeout value for forms authentication to a fairly large value, yet checking the “remember me” check box on the Login control still does not persist your users’ authentication, even after a fairly short period of inactivity.

    <authentication mode="Forms">
        <forms timeout="10080"/>

Don’t spend hours trying to figure out why this, seemingly, basic functionality doesn’t perform as it should. The solution to this problem is very simple, albeit somewhat obscure.

Continue reading ASP.NET “Remember Me” Option with Forms Authentication Not Working?

SVN, the Way of the Tortoise

Although, Subversion (SVN) is not new, it is still one of the most widely used version control systems (VCS) available. SVN is a tool that allows users to track the changes of files. Yes, it’s that simple.

Interfacing Your Demons

Like many version control systems, SVN utilizes a command-line interface (CLI) to interact with users. Some users frown upon the command-line; especially, Windows users. However, I want to point out how necessary it is that these tools use the command-line.

After you use a version control system for a good length of time, you should notice that there are routines you follow over and over again. Perhaps you lock certain files before editing them to prevent conflicts with other potential editors on your team. Maybe you always commit your changes when you build a project for release, or when you shut down your computer for the evening. The point is, these are things that can be automated with small scripts through build events or even Windows Task Scheduler. Having a command-line tool is essential to such automation.

On the other hand, there are many times you will want to issue commands to SVN on-demand. A nice graphical user interface can make things much easier and faster for those tasks. Enter TortoiseSVN.

Continue reading SVN, the Way of the Tortoise

Save the Developers Lost to Microsoft?

Save the Developers was a site dedicated to educating Web surfers about the tremendous failings of Microsoft’s Internet Explorer browsers. The site sported a free “badge” for Web developers and webmasters to include on websites to spread the word. “The word” being that Internet Explorer versions prior to 8 ignore all standards for HTML and CSS (the markup used by Web developers to create webpages). Ultimately, users were pleaded with to upgrade  to version 8 beta; at least leave version 6 behind and move on to version 7.

So, why all the past-tense in my explanation above? Well, the Save the Developers website ( now redirects to Microsoft’s website for Internet Explorer 7 and 8 beta. At first, one might assume that Microsoft bought the domain for the website and issued the redirect themselves. However, I’m not so sure about that upon some digging.

A whois query for reveals that the owner of that domain is Microsoft Corporation; no surprise there. However, a whois for (and .com) shows the owner to be Conveyor Group. There is only a month left before the domains expire, so who knows. Maybe they succumbed to the financial power of Microsoft.

Simpler Robust ASP.NET Providers

I don’t like writing about something that I’m “currently working on” too often. The problem with that is sometimes other things (e.g. life) get in the way of my proposed timelines. All that aside, there are times when the standard SQL web providers are overly complicated for the rest of my database schema. I think it’s great that you can use the same tables for multiple applications. It’s also great that the primary keys for most of the entities are GUIDs, since these are much harder for an unauthorized user to guess.

Sometimes it’s all just too much!

Integration with the Rest of Your Schema

The default implementation of the ASP.NET providers are not ideal for integrating with the rest of your database schema. By that I mean, if you want to include a foreign key to a user’s ID in a table that you’ve created for your application, you’ll have to play by those default rules. Your foreign key will have to be a unique identifier (SQL Server’s GUID data type).

What if I’ve already defined my entire schema and the User ID I had in mind is an integer?

Write Your Own Providers

Something that I truly appreciate with ASP.NET since version 2 are providers. Being able to customize the implementation details of specific pieces of a well-defined machine is empowering. Unfortunately, for the membership, role and profile providers, your data for each will more than likely be interdependent. For example, you cannot use the default SqlMembershipProvider with a custom role provider that does not link to the aspnet_Users table or use a GUID for the User ID when associating roles to users. If you want to change the data type of the primary keys for some entities, you’ll have to write custom providers for all aspects you wish to use in your application.

It’s also not as simple as just changing the data type from a uniqueidentifier to an int. Ideally, the flexibility to configure the providers to use one of your own existing tables in the database would be more robust than hard-coding several table names into the code. What if the provider uses the correct database provider based on the supplied connection string? How about the option to use dynamic SQL or stored procedures?

These would all be very nice features for a set of ASP.NET providers. Of course, I have a real-world example. My host lets me create MySQL databases for my website. They have MySQL 5 installed, which has the ability to create stored procedures (after a bit of a wait). The only trick here is, stored procedures in MySQL 5 are actually stored in the “mysql” database. This can pose a problem for security in a shared hosting environment. Everyone’s stored procedures are in the same “bucket”! It would be great if I could configure my membership and role providers to use MySQL and build dynamic SQL instead of relying on stored procedures.

They’re Coming

That’s the plan. I am currently writing ASP.NET providers that offer all the benefits mentioned above. When will this project be complete? Who knows with my schedule! I can tell you that I have a couple of big websites that I’m working on that will require MySQL as the backing database. They also require membership and roles support. I guess I’ll be finishing the providers in order to complete those websites. ;-)

Web Page Security – New Version

Some of you know me as a friend and code poet. Some know me as the crazy guy trying to get donations for his dad to get him a Wii. Some just know me as “that guy who wrote the web page security module for ASP.NET“. Others don’t know me at all; how did you end up here by the way?

Well, I am finally setting out to write the next version of the web page security module. I have quite a list of features requested by its many users. The fact is, I’ve been wanting to write the new version for nearly 2 years now. I have an idea that will make this thing so much more usable that I’m beginning to doubt its efficiency. So, before I begin putting too much effort into it, I will be running some tests, like a responsible programmer.

I suspect the new method I have in mind will be a bit more CPU-intensive. The problem is, I have no idea how much more CPU I can expect the algorithm to use. I’ll see how my tests go, beginning tonight. If the metrics show an acceptable increase in CPU (I’ll have to decide what is acceptable), I will begin coding the new version this week.

Stay tuned.