Randy Heffner, VP and Principal Analyst at Forrester Research, is also really smart.

Put them together — along with other mobile business technology innovators — and you get Randy’s latest research study:

“Mobile Solution Architecture: User Authentication Is The Foundation Of Mobile Trust”

Abbreviated synopsis: “… This report analyzes how key business issues and user scenarios factor into four major mobile authentication design questions, identifies product categories that can play a role in your mobile authentication architecture, and recommends a five-step process for establishing that architecture.”

Who should read this report?  Business leaders who want to ensure that the mobile apps they deliver to customers and employees are trustworthy and secure.  So… pretty much everybody.

Major props to Randy Heffner and his team for their awesome work.

You can download the report in its entirety here (free for Forrester clients).  If you need more help, give us a shout at 704.930.7444 or drop us a line at start@skookum.com.

Our New .NET Open Source Library: Hero

Here at Skookum Digital Works, we love open source software. There are many advantages to utilizing code that is built by a community of people, and we would feel remiss if we did not give back to the community we love so much.

SDW is proud to introduce a new open source product for the .NET community to handle user authorization. It’s called Hero, because who doesn’t want a big strong man…I mean code library…to save them?

Hero’s Purpose

Hero is an ability based authorization library for .NET MVC and WepAPI projects. It was inspired by the Rails project CanCan and by Derick Bailey.  Hero can be installed via NuGet.

Ability (or activity) based authorization provides a more flexible and maintainable approach to the traditional .NET authorization technique. Hero decouples the permissions and the code. By associating a role to a method or action in .NET (through typical Authorization attribute), you are creating a tight coupling between a role and an action. However, what happens when your role name changes? What if new roles are added into the system? Now you are required to update all code that references that role name or go through and add the new role. Instead, if you assign ability names to an action or method you abstract the functionality and the permissions can be done programmatically. This allows for a loose coupling between functionality and roles/users.

When the user and roles requirements change, you only need to update one section of code rather than going through your entire project looking for those tight couplings. Permissions are effectively encapsulated within a single, refactorable file similar to the ability.rb in CanCan.

Hero additionally supports Razor views to support hiding or disabling page sections based on a users’ effective permissions.

Finally, Hero also includes a Javascript component to more easily support Single Page Applications (SPA). The client side version of Hero allows the injection of security authorization into javascript functions through AOP techniques.

Server Side Example

For a full example of how to take advantage of ability based authorization in your MVC or WebApi project, you can view the Sample project here.

In the sample, we are creating a vanilla todo list application. The initialization and configuration of Hero should occur in one location, for instance, in the Global.asax file. This makes it easy to quickly review the abilities, roles, and their combinations all in one spot. We have setup Hero such that it will create a HeroConfig.cs that lives in your App_Start folder when you install the Nuget package. You just need to add the following line to your Global.asax file to perform initialization of Hero:

A user can perform basic CRUD operations on a list and it’s items. Registering abilities to users is extremely simple in Hero.  The following code will will create a Delete ability and associate it to a role (AdminRole):

Once you have created an ability and registered it with a role (or user), you can then begin using our custom authorization attributes in your code. The following code will require a user to have the Delete role to perform the Delete action in this controller.  If you are working in a WebApi project, the attribute name is AbilityWebApiAuthorization instead of AbilityMvcAuthorization:

That is all the code you need to perform authorization on the server.  For an example of how to utilize the client side version of Hero, see our example below.

Razor View Helpers

In addition to performing authorization checks through the Attribute helpers, if you need, you can also access Hero directly from your views.  You can do this with the follow code snippet:

Single Page App Example

Hero has a corresponding client side library to help control visibility of functionality on the client. This makes single page apps easier to work with and control visibility based on a users effective permissions. For example, in the ToDo applicatio,n we do not want users to see the Delete button if they do not have access to that ability. Through a simple module to encapsulate the buttons available in the system, this can be performed on the client:

The previous code works by injecting a security check into the showDeleteButton function of the TestModule.  If the current user does not have the ability to Delete, the function will not be allowed to run (and thus the button will never be shown).

Conclusion

The new open-source, .NET library Hero allows you to quickly and easily integrate an authorization system into your .NET project. At SDW, we have worked hard to create a modular system that is both easy to configure and easy to maintain long term. Based on our previous two articles on continuous integration through Team City and code reuse through NuGet, we have developed a module that we can both integrate into our future projects and release to the .NET community as well.

Happy programming.

Aaron Draplin
*one night only*
draplin.com

Skookum Digital Works World Headquarters
skookum.com

May 16th, 2013, 6:30-9:00 PM
201 S. Tryon Floor 2
Charlotte, North Carolina 28202
$15 ($25 at door) supports CLT’s AIGA Chapter

Space is limited!
This event is open to the public.

The Talk

Aaron swears a lot. We like that about him. He also grows a mean beard and has lots to say about being creative and earning a living. Get Cosmic.

Why The SDW?

We’re a software company. Aaron did our logo, which we’re quite proud of. It will be nice to meet him in person.

Plus we’re selfish and wanted him to finally make an NC poster.

Where Have I Seen Him Before?

If not from that bear wrestling league in the Pacific Northwest, you probably have seen his work everywhere. Field Notes for one.

Also, here’s a great interview with Aaron at The Great Discontent.

The Event

Get your tickets, now. In addition to being a unique, evening (and Thursday) version of our Tech Talks, this even will be a preview of the new SDW World HQ at 201 S. Tryon in Uptown Charlotte.

We are moving buildings this summer, and though we won’t be in our final space, attendees will get a preview of what’s to come with our new offices.

Room to grow. Room to dream.

Come hang out.

The following is part two of a three part series describing our .NET application development infrastructure at Skookum Digital Works. (Part One is here.)

Application Development Code Reuse

Code reuse is one of the most talked about things in development circles. Unfortunately, a lot of developers like the idea of code reuse and are great at using existing open source libraries, but most don’t actually write code that is reusable. The reasons are wide and varied, but some of the common explanations (excuses) for writing one-off code are:

• lack of knowledge
• difficulty in planning out thoughtful programming
• confidence to create clean, concise code
• time to get this project done vs. saving time on the next projects

All of these reasons are legitimate, but with a little knowledge and some discipline, code reuse is easier than you think. Over the past ten years developers have built better tools to package and reuse code.

Here at Skookum Digital Works, our node.js devs build modules, our Rubes build gems, and our .NET devs build NuGet packages.

These tools combined with foresight allow all developers to build and reuse code.

So how do the software programmers at Skookum Digital works use Github, TeamCity, NuGet, and Visual Studio to build our module platform? Let’s examine our process and highlight some lessons learned.

Source Control

SDW uses Github for our source control system. Github is based off the wonderful source control product git. Github provides a lot of interesting features that make developing code, especially open source code, a pleasure.

The process starts off with identifying code that is reusable. This is where the knowledge barrier typically comes into play. It can be difficult to know when code is going to be reusable. A lot of different blogs have entire sections devoted to identifying the properties of reusable code based on languages and frameworks. Some great examples are:

• Uncle Bob Principles of OO Design
• Ruby Science
• Javascript Design Patterns

Most modern languages though provide some concept of breaking code into reusable blocks. In .NET, we focus a lot on OO principles, SOLID principles, and—depending on the complexity—Domain Driven Design principles.

At SDW, each time we identify code that can be broken into a module, we create a new Github repository to store that code. This isn’t strictly necessary, but it just makes configuration easier.

NuGet

NuGet is .NETs package management system and nuget.org provides an open platform to share modules across development teams. You can upload modules to nuget.org if you want to share with the world, or you can setup your own enterprise nuget.org server very easily.

Here at SDWm we are currently running our own NuGet server based off TeamCity. No special setup required—you setup TeamCity you automatically have access to a private NuGet server. We plan on releasing any open source modules on nuget.org, but we also have closed source modules for specific clients that we cannot release to everyone.

It is important to setup roles on TeamCity so that you keep these two worlds separate. Getting setup on nuget.org is really easy;just register an account and use the API key from within TeamCity.

TeamCity

We have seen TeamCity in part one of our .NET series and the power that it provides. As mentioned, TeamCity also supports a NuGet server out of the box.

TeamCity NuGet modules

We currently have our modules setup such that if TeamCity can build, run unit tests, and verify the modules have enough test coverage, they are automatically built into NuGet packages. These NuGet packages are then stored on a internal NuGet server. We additionally have TeamCity setup such that when it builds the NuGet packages it does so using Semantic Versioning. It is very important to version your modules and to follow specific guidelins so that other developers know when breaking changes, etc. are coming.

In Visual Studio, we just point to that NuGet server—and voila—we now have a system to maintain and update code modules. This makes it super easy to break out code and share it with other developers (and other projects as well). This is especially important to us as a custom development shop so that we do not rewrite the same code over and over again.

(In part three of our series you will read about a security module that we have built and successfully integrated into multiple projects.)

Visual Studio

We use Visual Studio 2012 as our development environment. It has excellent NuGet integration now.

It’s simply a matter of right-clicking a solution, viewing the packages, and then choosing to update a particular module as necessary.

Conclusion

Here at Skookum Digital Works, we have developed a system to encourage our .NET developers to think and build modules. Now when we recognize a module, we can quickly set it up for resuse in other projects (this takes about one hour to do the full setup).

We have made the code reuse process as automated as possible to ensure we are focusing on solving business technology problems and NOT focused on code infrastructure and deployment.

We look forward to continuing to leveraging this system and beginning to open source more of our .NET modules.

Next up, in part three, Keith is going to discuss the first .NET open source module we are releasing.

.NET kinda/sorta gets a bad wrap in the open source development world. That’s unfortunate because most estimates show two-thirds or more of Fortune 5000 businesses use .NET for some part of their infrastructure.

SDW prides itself on mixing the open source with the enterprise. It’s advantageous for progressive, open source, and experimental software builders to have the knowledge necessary to sew organizational change from the inside out.

To do that, we have to be able to meet a lot of clients where there at. And for large companies, that means we not only need to be HTML5, CSS, JavaScript, node.js, Ruby, Python, PHP, and iOS experts but also .NET as well (among other languages).

The following is part one of a three part series describing our .NET application development infrastructure at Skookum Digital Works. We have an amazing team of .NET developers who also know how to slang up-and-coming open source code, so we wanted to specifically share our .NET workflow and the types of projects which benefit or require .NET

.NET & TeamCity

In some of our recent .NET projects here at SDW we’ve been taking advantage of TeamCity.  For those of you who don’t know, TeamCity provides us with a continuous integration platform. What the heck is a continuous integration platform? I’ll give you the deets and explain why it makes our lives easier.

Continuous Builds

The TeamCity platform monitors SDW’s Git repositories for new code commits.  Once something new is committed, TeamCity retrieves the latest code and attempts to perform a build.  The build runs locally on the TeamCity server using a local install of the .NET framework (We are using .NET, but TeamCity can be used for some other platforms also). You can setup multiple build machines and Windows, Linux, and OSX all work as build agents.

The benefit of continuous integration is that within minutes of someone checking in some new code, you immediately know if you have a build-able code-base.  This is awesome, because it keeps developers in the know about what commit caused the build failure and who committed that code. This way developers can quickly get a failing build back on track, without having to spend time going through source control commits finding the broken code.

Unit-Tests

Continuous builds are great and all, but what if a developer commits some code that compiles just fine. Then that code changes some functionality that breaks logic the overall application is depending on? That’s where unit tests come in to save the day. In our .NET projects we implement unit tests that verify our application functionality, and with our handy dandy TeamCity installation we can verify that with every code commit. Like continuous builds that happen on each commit, TeamCity will also run the unit tests for the project on every code commit and provide great information about why a failure is happening.

Now, if a developer changes some functionally that is core to the application but forgets to run the unit tests on their machine, TeamCity will let us know if a unit test isn’t passing. Also if you want to see how much of your application is covered by your unit tests, you can add some code coverage statistics (through JetBrains dotCover). This can be done for free by just leveraging the built in TeamCity version of dotCover without having to separately purchase a code coverage tool.

Continuous Deployment

So now we have a buildable code base, and we know stuff is stable because all our unit tests have passed. Who’s going to deploy the thing? TeamCity of course. TeamCity can be setup to deploy to a number of environments using various deployment scripts.

Our setup uses a PowerShell script to deploy our Development and QA git branches to our Windows Azure servers. With this power, we always have the latest stable code in an environment that is ready for testing. Also, developers don’t have to worry about taking the time to push code to the test environments to keep them up to date. If you’re interested to see how this deployment works, we got our guidance from a blog post on Scott’s Blog.

In addition to deploying applications, TeamCity support publishing NuGet packages directly. More on this in part 2 of our .NET series.

Code Quality and Consistency

Finally TeamCity additionally supports FxCop and Resharper inspections out of the box. Now your team can work with the default best practices and whatever naming conventions you wish to support. You can setup the build to fail or just warn that the current code is not meeting your team’s coding standards.

Notifications

While it’s fun checking out the overview page TeamCity provides in its install, but who wants to keep that thing open all the time to go check for build failures? That’s where setting up TeamCity to send emails to certain users on build failures comes in handy.

There are a number of settings you can subscribe to, but I think the sweet spot is getting emails on the first failure and then the first success after that. This way you are not getting spammed with all kinds build success (or failure) emails, and you’ll always be in the know on whether or not the code base is in a good state.

Conclusion

Continuous Integration has great benefits that can help developers be confident about the status of their code base. It also provides software developers significant time savings while building, testing, and deploying new features.

“You don’t make choices on data. You make choices on information.”

In this SDW Free Friday Tech Talk, Douglas Welton, MAC OS developer (yes, a Unix programmer in the flesh!) and SDW Tech Talk regular, took us through myriad questions related to visualizing data over time.

This presentation explored the design, creation and use of Data Visualization in our current cultural environment. Douglas also discussed why people want to visualize data in the first place and broke down the value that can be derived from different types of visualizations.

In addition, we also learned about some of the programming and statistical tools that are available to anyone interested in creating interactive data viz.

Great talk!

More Douglas Welton

http://www.einsteinslegacy.com/

Twitter
@einsteinslegacy

Here’s a question we often hear:

“Who are your best-fit clients?”

The answer is simple:

“Anyone who has overseen a successful custom software project…

or

…an unsuccessful off-the-shelf integration.”

The Ideal Client Profile

We engage with personalities and innovative mindsets across all industries, job titles, departments or functions.  And that’s a good thing.

Just as our projects span the technology spectrum, we’re interested in a narrative-based client qualifier because it’s far more indicative of the client’s potential to be philosophically aligned with how we build custom software.

Title is irrelevant. Perspective is paramount.

Past Experience

Great-fit clients often experience one of two software development outcomes before working with us:

1)  Terrible, awful, no-good, “why did I buy something off-the-shelf?” outcome.

• Their offshore partner wouldn’t return calls.
• Project went WAY over-time and over-budget.
• Nobody wanted to use the software once built.
• IT gave them hell over security issues; or if they’re IT, someone else is gave them hell over usability issues.
• Every InformationWeek/Inc/WSJ article on technology innovation still makes them feel like a putz.
• They failed, and are extremely worried to go down the pre-packed software route again.

2)  Awesome, revenue-generating, time-saving, boss-thinks-I’m-smart, custom software outcome.

• They built a technology application that actually solves a unique business problem.
• They worked with a business technology partner who employs innovation professionals to guide the project.
• They incrementally reviewed app features during the Agile development process in order to stay on schedule.
• They were under budget because unnecessary features were trimmed during preliminary user-testing.
• IT (and/or marketing) is patting them on the back.
• Every InformationWeek/Inc/WSJ article on  technology innovation validates their decisions.
• They won and can’t wait to move on to the next project.

In either case, our ideal client has learned lessons that now enable them to make efficient decisions, set clear priorities, and avoid time-killing mistakes.  They know what it takes to build complex, user focused, custom business software.

Business Technology Project Success Tips

In our humble opinion, ideal clients do the following:

• Engage with the partner’s team and empower them to think creatively; they trust the innovation expertise and proven process.
• Never say “Show me how you’ve done this before.”  They know that they’ve hired a crew to build something that’s never been attempted before; there is no apples-to-apples comparison for disruptive innovation.
• Understand that they’re purchasing a process, not a defined and static deliverable.  Custom software ALWAYS evolves through development and keeps evolving based on marketplace feedback and usage data.
• Seek out business technology innovation partners, not IT vendors.

Vendor is a dirty word. You need a partner.

Building custom business software is really, really hard but really, really worthwhile.

When clients understand that technology evolution is a journey and then hire us to transform their processes and culture, there’s no limit to where we can take their business.

In this SDW Free Friday Tech Talk, Chris Halligan, founder of the failed “companion TV content” startup OtherScreen, candidly walked us through what OtherScreen got wrong, how “the market fired them,” and the lessons learned from being another technology startup relegated to the dustbin of history.

OtherScreen decided to shut down after several rounds of prototyping, beta testing, and early funding.

Chris was very forthcoming and candid in his assessment of his own startup’s failure.

This talk is funny.

Chris Halligan’s Links

OtherScreen:
http://otherscreen.com

Twitter:
@chrishalligan

Every developer who knows jQuery has written code like that looks like the following.

Browsers are sophisticated creatures, and here we have tried valiantly to slow them down. Let’s examine what we have just asked them to do and how we can work with our friends, the Browsers, instead of against them.

Problem No. 1: DOM Querying.

The example code sets the expectation that you are handing jQuery a reference to a DOM node already. If this were true you could avoid the overhead of the selector engine (in the case of jQuery, this would be Sizzle) resolving your selector.

However, this code would be equally valid passing in a selector like '#main #tableview .data-table:nth-child(2)'. This would mean that each call to jQuery would need to perform that entire lookup again.

This is why caching your selectors is so valuable. The expense of selector matching would go from a minimum of three calls per scroll event in the above example to one.

Problem No. 2: Unnecessary Object Creation.

Everytime you call jQuery(element), you are creating a new jQuery object. In many traditional websites, this overhead would hardly be noticable. It’s very likely that no one will ever notice your lack of stewardship over memory management.

However, in a single page webapp, game, or other high performance scenario, these memory issues will compound. As noted in the solution to DOM Querying, you’ve also just reduced the number of objects floating in memory from three or more per scroll event to one. Total.

The garbage collector thanks you one thousand thanks.

Problem No. 3: Reflow. Repaint.

Reflow and repaint are browser operations that handle calculating layout and drawing. The depth of this topic is far beyond the scope this article, so I highly recommend “How Browsers Work” by Tali Garsiel on html5rocks. Also, Paul Irish has an amazing roundup of resources .

But what does repaint and reflow have to do with grabbing some elements and listening for some scroll event?

You have the power to trigger or not to trigger these events. There are a number of attributes that simply getting them will cause the browser to reflow. Tony Gentilcore has been even kind enough to provide a list concerning webkit. offsetWidth/offsetHeight, though, are two that will trigger reflow everytime. There is a reason jQuery neatly packages them both up nicely for us when we call .offset().

We triggered reflow not once, but twice, when we only needed to do so once. The browser does not like us very much right now.

By batching all of your reflow methods together, and then drawing later, we can greatly improve the performance of our webapps.

Wrapping up

None of these issues are enough to break the horse’s back by their lonesome. Though, compounding these issues with the experience you are trying to build can quickly add up. (Who remembers the Twitter scrolling performance woes of yesteryear?)

I hope that by knowing a little bit more about what work you are asking the browsers powering your work to do, you are better equipped to make informed decisions.

In this SDW Free Friday Tech Talk, Mecklenburg County (which is more or less made up by Charlotte, North Carolina) GIS Programmer Tobin Bradley talked to us about lots of fun stuff.

Tobin is the creator of the the Strategic Planning and Support division’s open-source mapping tool, The Quality of Life Dashboard, a responsive, interactive map that uses HTML5, jQuery, Leaflet, and Google Charts.

The largest technology meetup group in Charlotte, NC got to hear about life inside a government GIS department, Tobin’s thoughts on open data, and current trends and tools for web mapping and where things are headed in the future.

Mecklenburg County GIS Programmer Tobin Bradley’s Links

Quality of Life Dashboard:
http://maps.co.mecklenburg.nc.us/qoldashboard

Tobin on Github:
https://github.com/tobinbradley

Tobin’s Blog
http://fuzzytolerance.info

Twitter
@meckgis
@fuzzytolerance