Feature flags are a simple concept. A feature flag is a conditional block of code that allows you to toggle specific functionality on or off. This allows for separation of code deployment and feature deployment.

A simple example:
if ( flagService.IsFlagActive(FeatureaFlags.SuperCoolNewFeatureFlag) )

{

                DoTheSuperCoolNewFeature();

}

Types

Release Flags

Release toggles will often have a broad scope. They will wrap an entire feature set, possibly disabling both UI components and business logic. Doing so allows you to deploy code with the flag off, so it’s not accessible to the user. When development of the feature is complete and code deployed, the flag can be flipped on to enable the functionality.

Experimental Flags

Experimental toggles are more about gathering useful data from users. By toggling visual functionality components for specific users, you are able to log interactions and determine what your users like and use most. This is referred to as A/B testing.

Ops Flags

Ops toggles are used to toggle operational aspects of a system. For example, when switching to a new payment system, a feature flag can be used to determine if you use the new or old payment system. This allows you to quickly switch back to the old payment system without having to re-deploy if an issue arises.

Permission Flags

Permission toggles allow you to toggle specific functionality for specific groups of users. For instance, you could allow privileged/premium users into beta functionality to give it a test run before going live to a larger user base. Conversely you can ensure that a given set of users resistant to change, are the last to get new functionality.

The many advantages to using feature flags

Infrastructure or lack thereof

Projects seeking to go for a serverless architecture, such as mobile app development, can utilize companies that offer software as a service for feature flags. You are able to enjoy the benefit of having no infrastructure to maintain, while being able to toggle functionality and systems for your entire user base, without users having to update the app.

For projects that do utilize infrastructure there are still tremendous advantages. With the use of feature flags practices like continuous deployment become much more attainable. Developers can code a feature with the flag turned off, continuously deploy their code to production, and turn the flag on when the feature is complete. This separates code deployments from feature releases.

Rollbacks

This allows the team to form an always forward, never backward mentality. Barring catastrophic failure, rollbacks can become a thing of the past. Rolling back takes time to do and can carry its own negative impacts; especially when database changes are involved. Rather than going through the hassle of rolling back a deploy if an issue is discovered, a flag can be turned off to disable certain functionality and the change takes effect immediately. This means developers can get right to fixing the problem, and not waste time trying to stop it. This lowers both the time a user sees an issue, and the turn around time for a resolution.

Merge Conflicts

While they don’t go away entirely, even merge conflicts get better with feature flags. Since code can be deployed while off, Pull Requests can be made for smaller chunks of code more easily. This means code reviews are less complex, faster and easier to do, and code is merged to master more frequently.

User Insight

As mentioned in Experimental Flags, A/B testing is a very powerful tool for determining what your users want and use. You get real insight into user actions that you can act on. For instance, if you create a new feature and a group of users never use it, you may want to re-evaluate if you roll it out to your entire user base. You can make tweaks and see if a different user group increases usage.

Debugging

Feature Flags can even aid in debugging a production environment. If a developer needs to investigate a high priority production issue, time is of the essence. But pointing a local dev build straight at production is dangerous and getting a local database copy of production can take lots of time. A great strategy is to include sections of targeted verbose logging behind an Ops Flag. This allows you to only turn on the verbose logging when you want it, so that your production logs don’t get cluttered up. With more verbose logging enabled, the developer may get hints that allow them to quickly resolve the issue.

Feature flags don’t make everything better

Technical Debt

Feature flags are often an immediate source technical debt. If you have old code living beside new code, you have technical debt. Allowing the old code to sit there as a backup means you don’t fully trust what you have built, which isn’t ideal. Further, it can be very easy for a developer to miss an execution path and not update legacy code. This means if you have a problem with your new code, and attempt to turn the flag off, the legacy code may experience issues as well.

Code Complexity

As you create more and more flags your code will experience cascading code complexity. Creating nested feature flags means you are creating additional execution paths. Depending on the number of logical layers in your application and the number of nested flags this can quickly become very complex and difficult to debug or test. When testing a feature, developers and QA will need to know every flag involved and test every flag in every on-off combination to truly pass every test case. This can quickly become unreasonable even for the most likely combinations.

Overhead Cost

There is an overhead cost to implementing feature flags. Just in response time, each flag you check is an additional database or web call. On high frequency operations, this could cause a delay. There are additional code paths that may need to be implemented as well. For example, imagine a system that stored an order shipment price in tbl_shipment. Let’s say we have a new feature to store the shipment price per item in tbl_shipment_item. Switching straight to the new feature means we can change all out our queries to use the new column. But if we want to have a feature flag to switch between the two, even when the flag is set to use tbl_shipment_item, we need to still update tbl_shipment. This is to make sure that if the flag is ever switched off, the data is still correct, and not stale. These additional steps may not always be obvious and are easily forgotten.

When Considering Feature Flags

Dos

Planning

When planning the project work for the new functionality discuss the need for feature flags. If you think a feature flag is warranted make sure to create a task specifically for the creation of the feature flag which ensures the developer has capacity to guarantee all routes and logic are covered and not overlooked. In addition, the feature flag should be included in the acceptance criteria for the story.

Housekeeping

Most feature flags should be short lived. Once you are sure a new feature is solid you should begin removing the flag and old logic. It may be useful to create a future PBI to remove the flag right when your first make the flag. Set the PBI to be 3-4 sprints in the future to ensure proper testing time in a live environment.  Consider checking your flags for the last time they were toggled and removing those that haven’t changed in some time.

Use unique and descriptive names for your feature flags. Never re-use old names. You want to be sure you know what is being toggled and where when you change flags, and similar names can cause confusion. Additionally, in code, it’s wise to use an enum or some concrete class for identifying your feature flags; never use just plain strings. When you go to remove a flag, having compile time context about flags is much better than searching through code for a specific string

Testing

Given the complexity feature flags can introduce, always make sure to test in a staging or dev environment before toggling a flag. Logic may have changed or been missed since the flag was created.

Look around for related flags that could affect the logic outcome. Nested flags can create many unexpected logic routes that need to be tested. Just because one environment is set one way, doesn’t mean a different environment is.

Don’ts

While feature flags are handy, they are not a solution for every problem. Do not attempt to put everything behind a flag. This will drastically increase the complexity of your codebase and can quickly become unmanageable.

While it may be tempting, most feature flags shouldn’t be kept around forever.  Make a plan for removing them. Each flag adds alternate execution paths that your developers will need to account for. This can quickly increase the scope of new functionality and easily ruin initial estimates for work.

Conclusion

Feature flags are a power tool with many uses but can lead to a messy codebase. Using them should be carefully thought about in each scenario and only used when appropriate. Feature flags should be considered more as a development aide than a go-to pattern. Feature flags allow a developer to achieve continuous deployment and clients see great value in the speed at which issues can be resolved.

References

  • Bird, J. (2014, August 8). Feature Toggles are one of the worst kinds of Technical Debt. Retrieved from https://www.javacodegeeks.com/2014/08/feature-toggles-are-one-of-the-worst-kinds-of-technical-debt.html
  • Connolly, J. (2019, April 11). Introducing Feature Management in Full Stack: Launch new features with confidence. Retrieved from https://blog.optimizely.com/2017/10/18/feature-management/
  • Contributor. (2017, May 22). Feature Branching vs. Feature Flags: What’s the Right Tool for the Job? Retrieved from https://devops.com/feature-branching-vs-feature-flags-whats-right-tool-job/
  • Engdahl, S. (2008). Blogs. Retrieved from https://aws.amazon.com/blogs/startups/continuous-delivery-and-effective-feature-flagging-with-launchdarkly/
  • Erik. (2018, January 9). Your Feature Flag Management Needs to Include Retirement. Retrieved from https://rollout.io/blog/feature-flag-retirement/
  • Feature Flags. (n.d.). Retrieved from https://www.optimizely.com/optimization-glossary/feature-flags/
  • Meléndez. (2018, June 7). The Top 5 Use Cases for Feature Flags. Retrieved from https://rollout.io/blog/top-5-use-cases-feature-flags/
  • Paul-Hammant. (n.d.). Trunk Based Development. Retrieved from https://trunkbaseddevelopment.com/feature-flags/
  • Rusovsky, E. (2017, February 20). Every Change is a Feature. Every Feature is an Experiment. Retrieved from https://rollout.io/blog/continuous-feature-deployment-for-mobile-apps/
  • Samuele Resca. (2017, February 11). Continuos Delivery using feature toggle. Retrieved from https://samueleresca.net/2017/01/continuos-delivery-using-feature-toggle/

To anyone like me who has been working to keep up with the many changes to SharePoint over the last few years, the words “major platform upgrade” bring back painful memories of cumulative updates and complicated infrastructure changes. Fortunately for us, with SharePoint Online, updates are released much more frequently and in much smaller pieces than with past versions of the SharePoint Platform. Unfortunately, that also means we need to pay much closer attention to the small features released by SharePoint to find those that could have a major impact. Today I’m going to share a few modern SharePoint features that can save you (or your company) time and money by eliminating some frequently performed and repetitive tasks while utilizing the latest in modern architecture and design.

Hubs & History

Some of the most repetitive and frequent tasks performed by Site Owners after creating a SharePoint site are:

  1.  Setting up the Site Navigation
  2. Applying company theme’s and styles

With a little bit of setup work by a SharePoint Admin, this time can be completely eliminated for most sites by using Hubs! Before we dive too deep into Hubs and what you can do with them, let’s talk a bit about their predecessor – subsites.

In the past, the only way to group sites together and benefit from inheritance was to create subsites within a Site Collection. In most cases this  led to a requirement to break permissions inheritance between the root Site Collection and children subsites, plus a justified fear of changing the root Site Collection for the unknown impact the change could have on children subsites.

Now, with SharePoint Online, any Communication or Team site can be registered by a SharePoint Administrator as a Hub, then either Administrators or Power Users can associate other Communication or Team sites to Hub sites. This frees up the parent/child relationship and allows users and administrators to freely re-arrange sites as needed without having to move sites, folders, files or even change security.

Theme & Navigation

SharePoint Hubs provide a way to organize & group site collections, but there are a few more benefits that make them a much better alternative to subsites. The most obvious benefit when looking at a Hub site is the additional navigation menu, but as you associate other site collections to the Hub you really start to see the benefit of accumulated time saved. The Hub navigation menu and applied theme are automatically applied to all sites that are associated to a Hub – meaning if you have 7 departments, each with their own Hub and have 200+ associated site collections, changes can be applied to only those 7 Hubs and will then automatically be inherited from the remaining 200+ sites.

Site Scripts & Design Templates

Some of the most exciting changes coming from the SharePoint Team are around Site Scripts and Site Designs. Now don’t let “Scripts” intimidate you – they’re a no-code, declarative JSON solution to perform small actions such as joining a hub site, updating navigation links, and applying a theme.

Designs might sound intimidating as well, but essentially they’re just ways to apply those Site Scripts either to existing sites or future sites as part of the creation process. If you’ve created a Communication site recently, you might have noticed the default design templates available for Showcase and Topic:

communication site design setup screen

Conclusion

There are even more benefits from using Hubs that I haven’t covered, such as gaining a shared search scope and shared/aggregated News that can be consumed in the News webpart, with even more features expected and on the Microsoft Feature Roadmap! By grouping your company intranet sites into Hubs, you’ll be saving your users time both due to the enhanced navigation and the automatically applied site theme & styling.

Come back later for part 2, where we will dive deeper into Site Designs and Site Scripts by looking at how to utilize MS Flow and Azure Resources in Site Designs and Site Scripts for more advanced automation!

References

To be consistent with my “what I’ve been up to” style of blogging I wanted to talk about the benefits of creating a functional test framework and what that framework might look like.

If you’re like me then you probably think that automated functional testing using Selenium is really cool. If you aren’t like me, but automated functional testing is a necessary evil in your position, then simplifying your interaction with the entire experience should be really cool. In either case, creating, employing, or utilizing a framework for your functional tests can drastically improve your testing in a way that benefits the entire team.

Computer with magnifying glass and gears

The Order to Things

A member of our team explains functional testing like this; instructions sent to a man who lives in our server, who carries out those instructions on his computer in the exact manner in which they were sent to him. This really isn’t that far off. One of my largest pain points in writing functional tests was that sometimes I would ask this unnamed guy masquerading as computer hardware to click on an element I expected to be on page, but forgot to tell him to wait for it to show up. In fact, I found that there were usually always a certain set of steps and protocols that I should always follow when performing the simplest of actions.

For a click, I need to wait until my element exist on the page, then I need to move my mouse to that element, I need to wait for it to be in a clickable state, and I need to perform the click itself. While I can easily handle this in the test itself, it probably isn’t the easiest place to manage it. Instead, I can setup this sequence as a method in a framework, and call to it in the test. This works well for a couple reasons. The first being that in my test I only need to write one line of code instead of 4. Secondly, with this action handled in the framework I never accidentally forget a step. By doing this I am making my test easier to write, easier to read and I am ensuring consistency across the scope of potential actions.

public static void Click(IWebDriver wd, By by)
        {
            try
            {
                WaitActions.WaitUntilElementExist(wd, by);

                var element = wd.FindElement(by);

                FindActions.MoveToElement(wd, element);

                WaitActions.WaitUntilElementClickable(wd, element);

                ClickElement(element);
            }
            catch (Exception ex)
            {
                throw ex;
            }
        }

Don’t Make Me Repeat Myself

This idea of repeatable code extends beyond the steps to perform basic actions in tests. In our functional test infancy we handled most things at the test level. The framework aims to handle most of that work upfront, so the focus can shift to writing the test instructions themselves. The framework handles things like setting up the driver or Eyes for Applitools, in addition to addressing the different actions we can take in our tests.

Another measure along those lines is taking sections of the application that are tested repeatedly and moving them out of the individual tests so that they can be called upon in multiple tests when needed. When we need to update any of these sections, we can do it in one place. If a header on the site changes, we do not have to update every test that interacts with the header, but rather reference the portion of the project that handles interacting with the header.

public void CheckHeader(IWebDriver wd)
        {
            var header = FindActions.FindVisibleElement(driver, By.ClassName("header-inner"));

            var logo = FindActions.FindVisibleElement(driver, By.CssSelector(".logo-inner img"));

            var topNavLinks = FindActions.FindVisibleElements(driver, By.CssSelector(".mobile-nav .dropdown"));

            var secondLevelLinks = FindActions.FindElements(driver, By.CssSelector(".dropdown-menu li"));
        }

Batteries Included

Another cool feature of this framework is that it was made into a NuGet package that can be included in any projects at our company. If I want to create a new functional test solution to go with my existing webapp, I can simply pull in the package and hit the ground running. The NuGet package has all the references it needs already included. The setup of my driver and other essential classes have already been handled in the framework. I can immediately start writing tests. If I focus on the repeatable pieces of my application and create those methods in my best test, I can gain a good bit of test coverage on my application with relatively little overhead.

Batteries

Simplicity for Adoption

What I hope proves to be the largest benefit of creating the framework is promoting adoption throughout the team because of its simplicity. Team members who were unfamiliar with testing, or more specifically, testing with Selenium and the nuance associated with that, will be able to test simply and reliably with little overhead. Before, we were asking a test developer to understand the finer points of Selenium and how it interacts with the browser to create effective tests. Now, creating a test should translate much more simply into what interacting with the application feels like in real world terms – find this element, click this button, type into this search bar.

Simplifying how testing is done and lowering the barrier to entry on who can create tests should allow for more testing. Troubleshooting and understanding tests should be much easier for developers that interact with the test after they have been created or product owners trying to understand what kind of coverage they have on the application.

Do Less. Get More

A functional test framework will allow your company to do less work and get more from it. The framework ensures that tests follow the required protocols with more consistency and less overhead. The framework reduces the amount of work and shortens the time required to get a test project up and running. Finally, simplicity in testing can promote adoption throughout the team, leading to more team members creating tests and ultimately more testing as a result. Having a framework in place is essential to any functional test program.

So it has been a full year since you purchased your Sitefinity license and now you aren’t sure if you should keep your subscription active. Take a look at these benefits and I am sure you will see that it is worth the investment.

Continued Sitefinity Technical Support

If you renew your subscription, your technical support package will be automatically extended for another year giving you access to a dedicated team of Sitefinity engineers with guaranteed response times.

Technical Support Representative

New Features and Improved usability

You can be among the first to explore new product releases, betas, service packs and complimentary modules. You will have a say in the product roadmap, and your feature requests will be treated with higher priority.

Product Updates and Lower Cost Support

The Sitefinity subscription is the most cost effective way to stay abreast with the latest technology. Product updates are released several times per year including new features and enhancements to the product. With the license subscription, the latest product releases will be available for download directly from your account and you will be able to upgrade your project at your convenience, thus eliminating the cost of purchasing new licenses.
 
Money Jar

Bug Fixes

Bugs are fixed on a weekly basis and the fixes are released usually on Fridays two to four times per month. The goal with these weekly hotfixes is to help customers and partners address important issues for specific use cases without having to wait for the next service pack or major product update. The weekly hotfix builds are available to customers who have access to the official product release that precedes.

Wrench fixing softward bugs

Discounts on additional modules

When your subscription is active you will have access to preferential upgrade terms and special discounts for other Telerik products. Customers with active subscriptions are also eligible for special services like free domain alias licenses.

The Takeaway

All Sitefinity licenses include a one-year subscription, which guarantees access to new releases, product updates including new features, bug fixes, and technical support. After the first year, the subscription renewal is the most cost-effective option to stay abreast with the latest technology and get technical support which is key to keeping your online presence fresh and effective.

The Agile development methodology was formalized in 2001 and has become the leading process for software creation. Developers love the flexibility it gives by not requiring that everything be figured out up-front. But as a client, how can you feel comfortable signing a contract without already knowing exactly what you will get?

First some background

Classic software development involves a sequential process:

  • Requirements – define the problem and solution in complete detail.
  • Design – create the blueprint to implement the requirements.
  • Construction – build the system based on the design.
  • Testing – confirm what was built works as specified in the requirements.
  • Implementation – launch!

This process is commonly referred to as “waterfall” because the output of each phase flows into the next.

Waterfall Software Development Lifecycle diagram

At first glance this seems like a very reasonable approach. The requirements represent a complete description of the work that will be provided, and serve as the contract between the client and the development company. Expectations are clear and both parties are on the same page.

Why wouldn’t we always want to do that?

The problem is that software is intangible and complex. Words on a page don’t always capture and communicate the essence of what is desired. Even a very clearly stated requirement can be interpreted and built 100 different ways, and it is likely that at least 95 of those won’t be satisfactory. The result is a well-repeated (though somewhat mythical) response from the client:

It’s just what I asked for…. But not what I wanted.

How is Agile different?

Agile was created to address shortcomings in the waterfall process that occur when developing a complex software system.

The principle difference with Agile is that it is a very iterative and interactive process. Agile projects are broken down into short mini-phases called “sprints” – At Mercury our sprints are 2 weeks. The entire requirement-design-construct-test-deploy cycle happens within each sprint. The goal is to have demonstrable results to review with our clients every sprint and get feedback.

Agile software development lifecycle illustration

Imagine with the waterfall process if a fundamental assumption was made during requirements, but during testing was proven to be false. The project is nearly complete and potentially months of work must be revisited. By doing small incremental feature development, we prove out our assumptions quickly and can change direction as needed.

Change Happens!

Change is the enemy of the waterfall project. Imagine we are building you a web application, and 80% through construction an event occurs in your business that suggests changing course would be beneficial. By now you can see the devastation this brings to the project. This ends with a difficult conversation on change requests and costs.

OK I get it… so what’s the answer?

First let me put you at ease, because by now you may be thinking where I am headed is to ask for a blank check with no understanding of where we are going.

With Agile you still need a vision. At the beginning of the project we need clear understanding of some high-level questions:

  • What problem are we trying to solve?
  • What goals do you want to achieve?
  • What approach will we use to solve your problem?
  • How will we define success?

With this framework, Mercury can define a solution by creating a set of “user stories” which describe in your language both the functionality desired and the benefit. Here is an example story related to workflow in a hypothetical cash disbursement system.

As an Employee Supervisor
I want to review pending disbursements and approve or deny them
So that I can confirm their accuracy prior to generating payment.

This statement tells us not only what you want to accomplish, but who cares about it and why. What we don’t do is try to define every single field, button, and click in the process at this point – we don’t know enough yet. Doing so is frankly a waste of your money because it is almost guaranteed to require revisiting later when we do know more.

We then take this collection of stories and estimate time and effort, which of course translates into dollars. With your approval, we will begin work towards meeting your goals with a budget to work against.

Every two weeks we review our plan and select the features that will provide you with the most value that can be delivered in the next two weeks. When complete, we demonstrate these features, get feedback from you, and then plan for the next sprint.

Agile Scrum Board

The key advantage agile provides us is the ability to course correct after every sprint. Once we start delivering features you can see and touch, you can quickly see where we are headed. This gives us the opportunity to adjust as we go, instead of getting to the end and realizing we are in the wrong place.

It’s all about value!

Agile also gives you – the client – control over the process. If you want to add something new, we can do that! If you want to do that but not change the budget, you get to pick what we take out. Or maybe the new idea adds so much value you are willing to add it on top, but you get to decide.

You also have the option of eliminating features as we make progress. Maybe you thought we needed to build out some reports, but now that you are seeing the lookup screen come together you realize they won’t be needed. The good news is since those were prioritized lower, we haven’t spent any time (i.e. your money) on those features yet, and you can easily cut them from the project.

Project completion

When we get to the end of this process we may end up with something that looks quite different from what we originally envisioned. Ideas were revised and features were cut in favor of others that were added. But by focusing on the overall goals of the project instead of rigidly holding to a narrowly defined requirements document, we will end up with a superior product that was created collaboratively and truly provides the value you wanted.

Teacher pointing to chalkboard

If you are familiar with professional service companies specializing in Web Development or Digital Applications, then you are undoubtedly aware of the pressures and day-to-day struggles that come with meeting the demands of clients. Contrary to social folklore, the customer is not ALWAYS right, however they should always be HEARD. Instead of arguing and potentially losing a client, here are some helpful actions meant to prevent you or your company from constantly battling over the same ground.

The basis for these guidelines is Education. Educating your clients isn’t difficult, however it is an essential part of any successful project and following these guidelines can certainly improve the working relationship you have with clients. It is very important to note: this Education needs to take place before the project begins and even before pen touches paper. Trying to implement these recommendations after work has begun is asking for serious trouble.

1. SET EXPECTATIONS AND BOUNDARIES

Setting a solid foundation for a new project means forging reasonable/attainable expectations with your client. Promising too much or too little is easy to do. It is imperative that you make your presence and views on important topics known from the start. The client needs to know and more importantly understand that hiccups can and will occur causing inevitable delay or push back of other requests. Of course, you and your team do your best to minimize these mishaps, but we are all human and software is challenging! Setting these expectations with the client ties heavily into the next key point.

People communicating via headset and computer with speech bubbles

2. THE MORE COMMUNICATION THE BETTER

Before you get red-faced, I’m not implying you talk with the client daily and in turn get loads of requests and feedback while not getting any actual work done. Communication in this sense refers to meetings or demos you set up and speaking to the client ensuring they know that feedback needs to be thorough with explicit details on what they require. The C-word also refers to you as the designer/developer reaching out for questions and concerns along the way. There is no need to wait until interim meetings when something pressing is hindering you from delivering the highest quality product.

Man presenting to a group of people

3. YOU’RE AN EXPERT, SO BACK IT UP WITH FACTS

Sometimes this is the most difficult guideline to handle with finesse. You are trained, certified, college educated, and/or have designed and developed for years; one or more of these things qualify you to do your job and do it well. Clients have opinions and some are much more vocal about them than others. Establishing your credibility is fundamental in getting the client to understand you are not injecting your personal styles for the sake of it. A few ways to soften the edges and effectively guide them is to show some solid research or data that backs up your decisions, or give examples of other sites or books that use your design and function well. Also, when demoing to a client, don’t just click through the process, take time to explain in detail WHY you did these things.

4. FEEDBACK IS SUGGESTIVE AND NOT PRECSRIPTIVE

Nothing is worse than hearing “I just don’t like that”, or “Could you try something different?”. Educating the client and nicely pressing them to continually provide meaningful input until the project is complete is highly beneficial for both parties. It is vital to take the time at the beginning of a project to really listen (and ask questions) about what the client is looking for in a website which in turn could help circumvent the need to teach this lesson at all.

Two men in suits shaking hands

5. STICK TO THE CONTRACT

The main reason a document outlining the work to be completed and the terms in which they are handled is drafted and signed is to protect both parties. Sounds simple enough, but often work is shoved in to a workload that was never discussed during contractual meetings. Without question there are exceptions and new items that arise during a lengthy project but be sure to stand firm on variations from the agreed upon terms. Reading the contract out loud to the client and conversing about all questions/concerns is a necessary practice in establishing a firm base for success. Some key things to highlight in your detailed contract should be:

  • Intended work hours
  • Milestones/Phases for the Project
  • Payment rules
  • Requirements for Feedback
  • Overall budget with overtime costs

It can be a wonderfully pleasant task to create a beautiful website for a new or established company. Everyone can be on the same page and the budget can be effortlessly adhered to and the client can receive everything they wanted. For the imperfect scenario (basically 99.999% of them), you can follow these 5 guidelines to hopefully prevent World War III. Educating the customer has been and always will be the smartest way to provide effective and fruitful client services throughout any project.

WebJobs and Function Apps, or Azure Functions, are both services in Azure to run triggered or scheduled tasks. I have worked on setting up WebJobs before and then started hearing/reading about these Azure Functions in various blog posts and meetups. Between the information from these sources and recently studying for the Developing Microsoft Azure Solutions exam made me interested in a comparison of the two services and cases where one solution may be preferred over the other.

In this post I make an assumption on basic knowledge of creating Web Apps and navigating the Azure Portal.

Cost and Storage

Money Bag

One of the first things when suggesting an implementation, other than “How long will it take?”, is “How much will it cost?”.

Creating a Web Job is free as long as you have an existing App Service Plan. Running web jobs does consume resources so you will need to keep track of the usage and scale your service plan up or out accordingly.

Function Apps can use an App Service Plan or a Consumption Plan. You can see the details of pricing on the pricing page but it allows you to only pay for resources while the app is running.

One additional cost of selecting a consumption plan is a storage account. You can use an existing account or one will be created by default when the Function App is created and pricing is handled separately from the Function app.

The consumption plan also includes a free grant of the first 400,00 GB/s of execution and 1 million executions. So depending on the execution time of your code all you will pay for is storage.

Set Up

Both WebJobs and Function Apps support similar languages – C#, F#, Powershell, bash, php, python and javascript. I have only worked with C# projects so far but it might be an interesting challenge for a future post to create some in other languages. Very recently support for precompiled functions has been announced which means you can publish a class library as a function app opposed to requiring a Function project type which is not pre-compiled.

WebJobs are a related to an App Service and can be deployed along with the web app they are paired with or uploaded to the Azure Portal as a zip file. For a C# console app this would be the web deploy package. You can have multiple WebJobs in a single App Service.

Azure portal webjob setup

WebJobs can be run continuously, triggered (for example as a webhook) or set to run on a schedule. The schedule for a WebJob is set in the portal when uploading the zip file or in a settings.job file in the project. The schedule is set using a cron expression.

Function Apps are their own resource in Azure listed under App Services.

For a small side track – in the screenshot below you will notice that both the Function App and Web app are assigned to a different App Service Plan. Didn’t I just make the point previously that Function Apps used a Consumption plan and not an App Service plan?

setup2

Going into the App Service Plan you will notice that this plan’s Pricing Tier is set to Consumption where the App Service plan that my Web app is tied to is set to Free.

App service plan overview menu

setup-4

Function Apps have a unique feature that you can edit the code directly in the browser. When starting up a Function App you are given various ways to create the application – starting from a pre-made or blank template, starting from source control or downloading a publish profile to deploy from Visual Studio.

Integration

Both WebJobs and Function Apps have been integrated with other Azure and 3rd party services. Function Apps are built on top of WebJobs so any triggers that WebJobs support Function Apps will, too. For example you can have a WebJob or Function App trigger based on actions in an Azure DocumentDB, Azure Storage, Twilio, Event Hubs and many more.

Additional Considerations

One point to consider when making a decision between Function Apps and a WebJob is that Function Apps have some limitations on time and memory usage. Function Apps apply a 1.5GB max memory and a 5 minute max execution time. Like many things this will probably change over time but for now it is something that requires consideration.

Use Cases

Now that we have gone through and compared some of the features of each service, when would you consider using each one? Outside a couple requirements it really is dependent on the project and your preference.

Consider using WebJobs when:

  • Long running task
  • High resource consumption tasks
  • You have a Web App that is closely related to the task you need completed
  • This is where your skill set lies

Consider using a Function App when:

  • Short running tasks
  • Low resource consumption tasks
  • The task is not closely related to an existing application hosted in your Azure account
  • You want the in browser editing capabilities

These are just my opinions – every project is different so use your knowledge of the project and requirements to make the best decision for your project.

One of the challenges I have made for myself at work is, over the next few months I plan to take a look at some of our services and WebJobs that are existing and see if there are any benefits to switching to a Function App.

Resources

SharePoint is an industry standard platform for creating a company intranet, but the out of the box styling leaves something to be desired. Even a well-designed site can fail to engage employees if it isn’t visually appealing. In this blog, I will explore several options SharePoint offers to customize the user experience, and explain the pros and cons of each approach.

For this discussion, I will consider each approach within the context of these factors:

  • Design – how much flexibility does this approach have in creating the desired branding?
  • Effort – how time consuming is the approach and what skills are required?
  • Admin – what implications are there for the future maintainability of the site?

SharePoint WYSIWYG page editor

Colored table displaying Design, Effort and Admin pros and cons
At the low end of the spectrum is using SharePoint’s CMS editor. This allows SharePoint users to easily update text, content, images, and links. Users that have used a CMS such as WordPress or Sitefinity will be comfortable with this solution and can generate pages and content with no technical skills required.

There are two downsides to this approach. First, since content is manually put on the page it is static and requires updating anytime that data should change. This increases the admin time necessary. The remaining methods all rely on SharePoint content to allow the pages to be dynamic.

Second, the out-of-the-box options for styling are limited to what you can do within the WYSIWYG. This approach risks producing inconsistent branding across the site, as each editor makes styling decisions on a page-by-page basis.

SharePoint List WebParts and CSS styling

Color coded table displaying Design, Effort and Admin pros and cons
Leveraging SharePoint content items and exposing them through WebParts is typically seen in many organizations. This approach scores high in both the effort and admin categories. Creating new content types and using WebParts is something business users can easily learn how to do. WebParts are designed to expose the underlying content types which allows the page to be dynamic. The SharePoint List WebPart also allows custom views to be created by admin users to fine tune what data is displayed as appropriate for the context.

To apply branding to pages built this way, SharePoint allows for the CSS to be adjusted. This gives you a limited amount of control over the visual appearance of the site. Company brand colors can be applied, fonts can be adjusted, and similar tweaks can be applied.

The advantage of this approach is that once the CSS styling has been applied, users can continue to use the standard SharePoint editor and WebParts. Any new list created on a page will automatically pick up the styling. This also allows designers to ensure more consistency in branding across the site.

I still score this one red for design because the options available for modification through CSS are limited. A designer with any aspirations of using artistic license will quickly run into the boundaries of this approach.

Overall this is well suited for a SharePoint site where ease of administration is a key factor.

SharePoint Content Search WebParts (with display templates & CSS)

Color coded table displaying Design, Effort and Admin pros and cons
Content Search WebParts allows designers to extend the previous approach while gaining access to significantly more styling options.

Using this approach, designers effectively create their own WebParts that are connected to SharePoint content lists and add them to the site. These custom controls give the designer access via display templates to control the HTML markup that is rendered. The level of effort has increased as this method requires more web design skills than before, but in exchange you get a much more visually pleasing result.

Another advantage of this approach is that with a little training, site admins can learn how to leverage these content search parts. Once they are created, non-IT admins can reuse these controls elsewhere on the site. The pages continue to remain dynamic since the components are still connected to the SharePoint lists.

The obvious question is why the yellow coloring for administration then? Mercury has found through our experience that these components rely on behind-the-scenes indexing that SharePoint does to make the data available to the control. This means that when a new item is added or modified in SharePoint, it will not be immediately visible on the control. Once the SharePoint index process picks up that content and puts it in the index, then it is available for display. In the real world, we have seen this take anywhere from a few minutes to almost 24 hours depending on the site. We have found that even a short delay can cause frustration for admin users who can’t see the immediate impact of their changes.

SharePoint API (with JS & CSS)

Color coded table displaying Design, Effort and Admin pros and cons
For a truly custom branding experience, leveraging the SharePoint API is the way to go. This gives the site designer full control over the markup and allows for the creation of a site that approaches a full custom web page experience in appearance. Additionally, the API is not subject to the SharePoint Index limitations in the previous approach, so content changes are immediately reflected on the site.

From an effort perspective, this is the most complex approach and requires the same set of skills required to do true web development. Of course if the goal is a highly branded site the additional effort will be worth it to produce the desired results.

The drawback with this approach is that business user admins are more limited in their ability to change the site. Future changes to page layout or content types would require changing the code that renders the page. The admins no longer have the ability to reuse the components as they do with the content search web parts. On the plus side this also ensures that the integrity of the site design is maintained.

Summary

If you were waiting for the approach that had all 3 boxes green, I’m sorry to disappoint you. As with all implementation discussions, there are always trade-offs. Before selecting an approach, you need to consider your goals for the site, the amount of branding desired, how much budget and time you have available, which skillsets you have at your disposal, and the level of flexibility in making changes. Armed with those answers, my hope is that this discussion will help guide you to select the appropriate approach.

As a relatively new architect-level hire at Mercury, I have spent a large amount of time exploring code bases that are new to me. In that exploration, I have come across a variety of source code peculiarities and problems related to issues with naming conventions. These are fairly rare situations and as such can take a while to diagnose and get to the true root problem. As a whole, naming schemes can vary greatly between organizations, with some of the bigger names like Microsoft contributing their recommendations on best practices. The issues I will describe below are specific to situations in Mercury’s development process, but might help to identify possible pitfalls in yours.

Case Sensitivity Differences in .NET Framework

The .NET framework allows development in VB.NET as well as C#, with interesting differences in case sensitivity. C# is a case-sensitive language, which means that it can recognize the difference between the following methods:

void myFunction()
void MyFunction()

This is definitely not a best practice programming-wise, and coworkers might frown upon your decision here, but according to the framework, this is allowed. However, VB.NET is case-insensitive, meaning that it cannot allow the same methods with the only difference being capitalization. This also applies to parameters in a method signature, namespaces and properties.

Where this could cause conflicts is when introducing compiled code into your solutions. For example, if you are working in a VB.NET solution and you introduce a NuGet package which was initially developed in C# with two methods that vary only in name capitalization, you are going to face compilation errors.  It is not always easy to track down what that NuGet package might be doing, so keep this case in mind.

Variable names in JavaScript

Similar to the above, it’s important to realize that JavaScript is also a case-sensitive language, it identifies a difference between the following variables:

var myName()
var myname()

This is something that you can potentially come across when working in either a vanilla JavaScript project or while using a JavaScript library such as jQuery. It’s more likely that you will come across this situation when using a full JavaScript framework, such as AngularJS or ReactJS.

Especially if you are integrating with a webservice of some kind, you could face issues with the naming convention coming from the service versus the binding used in the framework. In our case, we were integrating with a WebAPI service which we had developed, and we had specified the following naming for the output from our WebAPI:

config.Formatters.JsonFormatter.SerializerSettings.ContractResolver = 
new CamelCasePropertyNamesContractResolver();

This says that, regardless of how the naming convention is utilized in our WebAPI project models, the output is going to be such:

startsWithSmallLetter

The issue in our AngularJS application was that we were reading most properties correctly, with the camelCase formatting, and a very large application was working 95% as intended. Later we noticed that one of the columns in our database was always null. Backtracking the problem, from the models through the WebAPI layer and into the AngularJS application, we discovered that we had improperly capitalized the binding in this way:

ng-model="model.AccidentallyCapitalizedFirstLetter"

Because JavaScript is case-sensitive, this created a new property to our JSON object:

 var model = {
            AccidentallyCapitalizedFirstLetter: "",
            accidentallyCapitalizedFirstLetter: ""
        }

Whatever was entered into our application on the front-end was never properly bound back to the WebAPI for saving to the database, and this information was perpetually lost. We had discovered a very small mistake, with a large effect which wasn’t easy to determine while debugging through a missing data issue.

Confusing Third Party Namespaces

Sometimes the naming issues you run into aren’t your fault or even in your control: we have faced several instances of plugins and third party tools which are nearly identical in name to other tools, sometimes differing by only one letter. Sometimes the plugin is named such that it seems like it would be supported by a major corporation, but in fact it’s one developer trying to exploit the similarity. One non-development example is the court case of Nissan Motors vs. Nissan Computer, two different entities with claims to the same name.

In our case, we ran into an issue relating to Microsoft and a SDK they provide to access their cloud-based APIs. In 2014 a version 2.0 was released for what they called the ‘Microsoft Azure Graph API Client’, a tool to access Azure Active Directory and a few other Azure resources in code. This SDK was made available via NuGet, Git and Microsoft’s site.

In 2016 Microsoft released a new tool, this time called the ‘Microsoft Graph API Client’. This incredibly similar name is a tool replicating the complete set of functionality of the Microsoft Azure Graph API Client, with some additional features of being able to access Office365 and the rest of Microsoft’s suite of cloud tools. Both of these tools are currently supported, and because of the cross-over between functionality, it’s very likely that either or both will come up when doing any form of web search.

If your architecture is currently setup to support one of these versions of the Microsoft SDKs, then it’s likely that you want that specific library instead of the first one to come up from a search. This could become even more confusing when a newer developer is tasked with extending some functionality and chooses to add a new library to the existing stack because closely named projects introduce ambiguity.

Apache Hosted URLs

Probably one of the most interesting, and hard to solve issues, that came up as part of a naming-related problem, was related to an Apache hosted application. In this case, we were using a set of testing tools, and in code we would reach out to those tools with a standard HTTP-based web request. During the lifecycle of these testing tools we had consistently been working with a naming convention like this:

www.our-testing-appliance.com/InitTest

With this approach, we had never run into any issues that we could notice, and we were initiating functional testing using this location across dozens of different projects. Considering that our approach was a successful one, we looked into refactoring our testing solution into a NuGet package. This is where we started to run into errors.

Specifically, in our NuGet package we defined static classes to initiate the connection to the testing application. Our implementation of this library would simply define a test, and the results of this were coming back with the connection being denied. This was surprising, especially given that we could go back into an older application immediately after and have a test work successfully.

With some debugging of the network, we determined that the URL above was giving a 301 response, it was redirecting to the correct URL:

www.our-testing-appliance.com/inittest

Since the Apache host is case sensitive, it wasn’t responding to the two URLs as the same destination, and instead was redirecting from the capitalized case to the lower case. The static class implementation was not handling the redirect, whereas our previous implementation did follow the redirect and get the response from the new route.

Conclusion

These issues nearly all turned out to be minor problems in code, but each gave different indications as to what failed. They all started out as some different symptom, either database oriented or networking related. Starting from an assumed problem, it was surprising to see how much of an effect capitalization could have, beyond just making everything a bit more confusing. In the case of third party naming conventions, I’ve learned to be very clear in my documentation, to include links, and to not trust external libraries to always follow sensible conventions.

References

At the end of 2016 I embarked on a goal to develop an in-house framework for Mercury to use on our internal websites and web apps, as well as client projects. This blog post is geared toward front-end developers looking to make their own framework, and in this post, I’ll talk about approaches I took and lessons I learned during development of the Mercury UI Framework.

Why Another Framework?

At Mercury, we utilize Bootstrap quite often. Many of our client sites use it under the hood. We’ve also dabbled with Foundation, and there are many more out there. The advantage to using a framework is quite obvious:

  • A well-architected UI layer
  • Lots of components
  • Nice documentation
  • Browser testing for free
  • Large ecosystem with examples, tutorials, and add-ons

While we’ve become experts at using Bootstrap, customizing it (tip: use the SASS version!), and extending it, over time I’ve found it lacking in areas and stagnant in new features. Version 4 has been promised for a long time now, but has yet to appear in its final form. After taking a look at the early alpha code, I also felt like it wasn’t pushing itself far enough (there are good things coming, though – flexbox first CSS, refactored cards components, and more). Better responsive components, like tabs and tables? Nope. An off-canvas nav? Nada. Mega menus? Zilch. So, I decided to create a framework that offered more while keeping the things we use most often.

Mercury UI Framework - Components 2

Plan Ahead

Browser Support

Before setting out creating a framework, the first thing you should do is plan what browsers you need to support. This will help inform approaches and effort once you start writing code. At Mercury, we support the latest two operation system and the latest two browsers. That means Windows 8.1, Windows 10, macOS 10.11, macOS 10.12, iOS 10, iOS 9, Android 6, and Android 7 for operating systems on desktop and mobile devices. For browsers, support includes IE11, Edge, Chrome, Firefox, Safari 9 & 10, Safari iOS 9 & 10, and Android Browser. As of late 2016, that covers about 95% of OS’s and browsers in the USA.

Identify Features

The next step in planning is to identify the features you want to build. For my framework, I wanted to create something on par with Bootstrap, but take it further too. This meant including:

  • Accordions
  • Alerts
  • Badges
  • Bands
  • Buttons
  • Button groups
  • Cards
  • Dropdowns
  • Grids
  • Heroes
  • Input
  • Input groups
  • Mega menus
  • Modals
  • Off canvas navs
  • Pagination
  • Tables
  • Tabs – Horizontal
  • Tabs – Vertical
  • Toolbars
  • Tooltips

I also know I wanted to have good documentation with code snippets to copy and paste, as well as a Kitchen Sink of one screen with all components that could be the basis of a projects’ style guide. The table component I created offers 3 different approaches to making tables friendly for small screen devices. Both tab components (horizontal and vertical) change to accordions as well for better mobile usability. I also wanted to make sure I provided breakpoint classes to turn on and off styling, if needed.

Mercury UI Framework - Brand Colors

While identifying features, it’s also a good point to brainstorm how you can make your framework unique. What feature(s) can I include that will set it apart from the rest and make somebody want to use it? How can I provide value for myself, my coworkers, my peers, and for clients? Where can I make things easier and better? Where can I save time for the things I do day to day?

Lastly, identify what you don’t need to create. For the Mercury UI Framework, I made the conscious decision to not include a rotator (also known as a carousel or slider). Much has been written about their poor accessibility, and because there’s more than enough plugins out there, I kept a rotator component off of my features list.

Create A Timeline

After choosing features, the next step is to create a timeline and estimate how much time you’ll need to complete it. The actual time it takes will be different depending on the skill level of the person writing the code, so this should be different for everybody. Also, finding a good MVP (minimal viable product) point for an alpha release is a good idea – you can always have more feature releases in the future. Make sure your timeline includes:

  • Research
  • Building the framework
  • Refactoring
  • Testing (Applause, manual, etc.)
  • Bug fixes
  • Dogfooding (using what you build)
  • Documentation
  • Testing the documentation
  • Setting up hosting, environments, etc.
  • Pipeline creation
  • Code quality analysis (SonarQube, linting, etc.)
  • Code reviews by peers
  • More testing, bug fixing, and refactoring time

Research Best Practices & Industry Trends

Even if you’re a seasoned front end developer, you should take some time to research. In my opinion, you’ll want to target where the industry is going, not where it is now or where it’s been. Is CSS Grid viable yet, or should I stick with Flexbox? What about responsive type? Should I use LESS or SASS? How can Gulp help me? Utilize resources like CSS-Tricks, Sitepoint, Smashing Magazine, and Codepen to gain inspiration and novel approaches. Collect these links and decisions somewhere, like a OneNote or text document, that you can refer back to later. While not everything made it into the Mercury UI Framework, doing this research will inform the code you write. Some decisions, like using the lobotomized owls selector for global margins, will impact the whole framework. Make sure to refer to Can I Use to make sure you’re providing support for the browsers you chose.

Make It Themeable

The framework I created is meant to be used by front-end developers who have the skills to use SASS, so the approach I took was simple: use SASS variables to theme the basic look and feel of the framework, such as colors, border styling, and sizing of elements. I also utilized SASS maps so that developers could easily add or remove breakpoints and alternate colors for components. If you have the time or need, you could go wild and create a theme generator like some frameworks offer. I’d recommend also keeping your CSS code specificity as low as possible so that other developers can easily override your styles with their own without accruing technical debt.

Make It Easy To Use

If you want other people to use your framework, you’re going to need to create good documentation that has examples, code snippets, and explains your architectural decisions. You’ll probably also want a roadmap with where you’re going with future versions, a place for keeping track of bugs, and several ways for people to get your code (repo, direct downloads, etc). One lesson learned is that documentation takes just as long as writing the framework code – don’t leave it until the end! Try and document your work as it’s completed so that othing is left out or forgotten.

Hold A Code Review

If you’re the only one developing a framework, it’s a good idea to get an outside perspective to make sure your decisions and your code make sense to somebody else via a code review (also known as the number of WTF’s per minute). Another set of eyes and a different brain can help you point out confusion, poor code, or generate ideas for improving your framework. You can hold a code review with a coworker, a developer of a different discipline, or a development manager. If you want a truly outside opinion, find a peer via a front-end development Meetup group. Make sure to follow up a code review with actual action, such as refactoring or creating more documentation.

Test It

This may seem obvious, but sometimes designers and developers cut corners by skimping on testing. Be honest with yourself and really put your framework through its paces by testing it thoroughly. This includes browser testing, functional testing, code analysis, linting, and dogfooding your own work. At Mercury, we’ve adopted Applause for testing our websites and apps, and the Mercury UI Framework was run through this service just as any other project. It helped uncover 70+ issues that I was able to correct, giving piece of mind that the code I wrote would hold up on production sites and apps. Your timeline created earlier should include a healthy amount of time for testing and fixing bugs exposed during that process, as well as multiple rounds of testing if you undergo extensive refactoring during development.

Conclusion

If there’s one thing I want to impart in this blog post, it’s that creating a framework is a lot of work. I hope my time spent can help somebody else looking to do the same. By structuring the process into different segments, you’ll be better armed to complete your framework project and produce a better product as well. Also, remember that you’re never really done with a framework, or any development project for that matter. New needs and ideas arise, browser support changes, bugs will be exposed, and you’ll feel the need to refactor your work.

If you’re interested in checking out the Mercury UI Framework, visit the documentation for the site at http://mercuryuiframework.azurewebsites.net/ (pretty URL coming soon).