A place where we write words Ignition Blog

Welcome to the Ignition Development blog, where we talk about a wide range of technical and non-technical topics.

December 2015 Entries

Technical (and other) Challenges of 2015

My yearly "Christmas blog post" has a slightly different spin on it every year. This year I thought it might be interesting to talk about some of the technical challenges that arose as part of our projects this year, with a few non-technical challenges thrown in for good measure.

We’ve had the opportunity to work on a number exciting solutions this year. Development projects are always beautiful and unique snowflakes, so each one provided us with new and interesting challenges.

Converting a large ASP.NET WebForms application to ASP.NET MVC - I say we take off and nuke ASP.NET WebForms from orbit. It’s the only way to be sure.

One of our major customers invested in upgrading an aging WebForms web application to ASP.NET MVC 5. What could have been a nightmare turned out to be quite an interesting exercise.

Because the WebForms app was originally built (by us, incidentally) using the Model View Presenter (“MVP”) pattern, the conversion was much simpler than it otherwise would have been.

It reinforced that good architectural patterns are a benefit not only when building an application, but especially when performing large-scale refactoring years later.

It turns out that not cramming all your business logic into the View layer makes your life much, much easier later on -  who knew?

For us, it was great to have this part of the customer's code converted to MVC. It allowed the customer to use some fairly complex HTML markup in their sites without worrying about what WebForms controls may do to the rendered HTML, and from a developer perspective it was a great feeling to have reduced the amount of WebForms code in the Universe.

Making a decision on MVVM/Angular

There really are a lot of front-end JavaScript frameworks out there, aren’t there?

Last year we invested in AngularJS 1.x for a few projects that justified complex front-end databinding and templating.

This year, we’ve made the decision to move away from Angular.

There were a number of projects where we had to stop and ask ourselves if we were going to use Angular, and the state of Angular made it very hard to answer 'yes'.

AngularJS 2.x has just entered into beta, however it has been in an alpha state for the last 21 months. That's a really long time for an alpha, and during that time there's been a lot of uncertainty about the feature set that 2.x might bring to the table.

Various long time Angular fans have been expressing dissatisfaction with the direction the framework was taking, and the only thing that was certain is that 2.x would break all our 1.x work.

This made it really hard to justify investment in Angular 1.x for large projects; it simply felt like a path to creating technical debt.

What’s going to replace AngularJS in our toolbox? We’re not sure yet, but we’re spoilt for choice.

Responsible Design

In 2014 we saw an increased emphasis on mobile first and responsive designs, and that trend continued in 2015 (#thanksgoogle).

This year we worked on a project to use a responsive design on a family of large ecommerce sites. Some instances of the application see >50% of their sales from mobile devices, and a great mobile experience isn’t something that could be ignored or deprioritized.

The shops had previously had their own separate mobile sites (e.g. http://mobile.mysite.com) which used workflows and screen designs tailored specifically to mobile devices.

We were tasked with implementing a new, cohesive design for the platform. Because the functionality was so similar between mobile and desktop users, we mostly got away with a purely responsive design.

While we've always known the pros and cons of dedicated mobile site versus a responsive one, it was interesting to experience some really stark examples of these in the flesh. Mobile workflow is different, and being able to treat it differently is a valuable thing which is hard to achieve using a fully responsive approach.

For example, the main site navigation user experience required duplicate markup (one set of menus for desktop, another for mobile) and a combination of agent detection and media queries to show the correct elements.

Technically, this felt far from optimal (although it was the best option given the circumstances) and the fact that it would have been much cleaner to solve the issue in a separate mobile site was a great example of the compromises often needed in large responsive sites.

Reduced maintenance was a key goal of this specific project, so reducing the number of designs per shop by removing the mobile specific versions ended up yielding a net gain, however it wasn't without the occasional compromise.

Being on the receiving end of an external code review is kind of terrifying

One of our new customers required an external code review for the purposes of due diligence and corporate sign-off.

No matter how confident you think you are, a code review is always a nerve wracking experience. It had been a while since we'd had anything externally reviewed, and it was time to put our money where our mouth was.
We're happy to say we passed with flying colours, although with some low-priority suggestions to mull over.

It was interesting to read the review and disagree with some of the recommendations. For example, enforcing strict password complexity requirements may have been detrimental to overall security; the target users would have been more likely to reuse complex passwords they already remember (e.g. Active Directory credentials).

There's no such thing as 'perfect' in the arms race that is code security (something that the numerous public site breaches during 2015 should have reinforced to every developer, CTO, CEO, user, and well - everyone actually), but we we’re still really proud of our results.

Large-scale performance testing is fun

For many New Zealand businesses, load testing their web presence isn’t a priority. A brochure-ware site might take a few hundred visitors per week and so there’s really no need to test its performance under heavy load.

But what happens when a customer’s non-functional requirements include handling 5,000 concurrent users working through a process that writes to the database multiple times? Well, you get to do some fun load-testing with great simulation tools like Web Test Framework in Visual Studio 2015!

We built the application with this kind of scalability in mind (multiple web servers, in-memory caching, middle-tier write queuing, optimized Entity Framework queries), but having hard numbers to back up our architecture was necessary.

After some back-and-forth with the infrastructure provider (kids, remember, SQL latency will kill you), we successfully tested up to 6,000 concurrent users with acceptable response times from the site. We stopped there because we were saturating our own outbound bandwidth and because 6,000 is a nice, round number.

The content problem doesn’t have a technical solution

We're often on the nagging end of things regarding web site content. Customers can be really slow to get their content ready so we can put a site live.

We refreshed our web site this year (you like the new design, right?), and it was interesting to be on the other end of the stick.
We were really in love with the visual work that our friends at Transformer Design had created for us, and we wanted to make sure that our content did justice to their shiny design.

The result of our desire to measure up meant that the process took a lot longer than we expected.

Lessons we learned:

  • Take advice from others, but have a single decision maker. Just like a design exercise, writing content by committee is something which will get frustrating very quickly.
  • Stop and consider your audience, and think about what you're trying to tell them. Make it easy for them to work out the differences between your offerings and to quickly find the things that they're looking for, such as contact information.
  • Less is more. Fine tune your language, keep it brief and to the point. If you want to write more lengthy pieces then start a blog instead.

Our customers are awesome

2015 has been a busy year for us, and as always I'd like to say thanks to our customers, partners, and friends for being part of it. The team is all looking forward to a well-earned break so we can recharge for 2016.

If there's anything above that has you interested, or if you'd just like to get in touch about a project (or projects) that you have in mind for 2016, then please drop us a line.

Our office is closed from the 23rd of December through to January the 11th, however limited support is available for urgent issues. Please follow the support procedures as normal if you need urgent help over the break.

Happy Holidays everyone!



This blog entry was posted @ Wednesday, December 30, 2015 10:37 AM | Feedback (0)