How to

Not just a ‘one-trick’ pony: How to use .net Core to Monitor App Health

Monitoring app health is of utmost importance in order to ensure that bugs and other vulnerabilities are patched on time. Today, let’s delve into ASP.net Core, a middleware solution that provides support to conduct health checks on an application.

First introduced in ASP.net Core 2.2, the health check feature is exposed via configurable HTTP endpoints. These health checks can then be used to check whether a database is responding, to check whether all dependencies are in order and more.

Getting started To get started, create an ASP.net Core project in Visual Studio 2017. To do so,

  1. Launch the Visual Studio 2017 IDE.
  2. Click on File > New > Project.
  3. Select “ASP.Net Core Web Application (.Net Core)” from the list of the templates displayed.
  4. Specify a name for the project.
  5. Click OK to save the project.
  6. A new window “New .Net Core Web Application…” is shown next.
  7. Select .Net Core as the runtime and ASP.Net Core 2.2 (or later) from the drop-down list at the top.
  8. Select API as the project template.
  9. Ensure that the checkboxes “Enable Docker Support” and “Configure for HTTPS” are unchecked
  10. Ensure that “No Authentication” is selected as it is not necessary.
  11. Click OK.

Register health check services

Next, proceed to call the AddHealthChecks method in the ConfigureServices method of the Startup class. The health check middleware can be added by calling the UseHealthChecks as shown in the code snippet below.

public void ConfigureServices(IServiceCollection services)
 {
    services.AddHealthChecks();
 }
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
 {
   app.UseHealthChecks("/health");
   app.UseStaticFiles();
   app.UseCookiePolicy();
   app.UseMvc();
 }

Do note that under this method, both the ConfigureServices and Configure methods are called by the runtime.

Built-in vs. custom health checks

Now we come to a fork in the road. ASP.net provides us the ability to either use the built-in health check or to deploy custom health checks.

The built-in health check allows you to take advantage of the Entity Framework Core DbContext health check to report if the Entity Framework Core DbContext is able to connect to a given database. To do this, add the Microsoft.Extensions.Diagnostics.HealthChecks.EntityFrameworkCore NuGet packages and configures health checks in the ConfigureServices method as shown below.

services.AddHealthChecks().AddDbContextCheck<MyDbContext>
("IDGDbContextHealthCheck");

Do remember that you always have the option of using other health check packages available on NuGet. These include SQL Server, MySQL, MongoDB, Redis, RabbitMQ, Elasticsearch, Hangfire, Kafka, Oracle, Azure Storage, and more. These community packages are available in the AspNetCore.Diagnostics.HealthChecks repository on GitHub.

This doesn’t work for me. I want to go custom.

Assume you want to verify if the application is unable to connect to a database or an external service. If you decide to create a custom health check, extend the IHealthCheck interface and implement the CheckHealthAsync method.

public class MyCustomHealthCheck : IHealthCheck
	{
        public Task<HealthCheckResult>
    	CheckHealthAsync(HealthCheckContext context,
    	CancellationToken cancellationToken =
    	default(CancellationToken))
    	{
        	throw new System.NotImplementedException();
    	}
	}

Note how the HealthCheckResult struct has been used here.

public async Task<HealthCheckResult>
     	CheckHealthAsync(HealthCheckContext context,
     	CancellationToken cancellationToken =
     	default(CancellationToken))
    	{
		if (IsDBOnline())
{
            		return HealthCheckResult.Healthy();
}
        	return HealthCheckResult.Unhealthy();
    	}

The IsDBOnline method can be used to check if the database is working as intended.

private bool IsDBOnline()
    	{
        	string connectionString =
        	"some connection string to connect to the database";
       	try
       	{
          	using (SqlConnection connection = new
          	SqlConnection(connectionString))
          	{
                	if (connection.State !=
                   	System.Data.ConnectionState.Open)
                 	connection.Open();
          	}
           	return true;
       	}
       	catch (System.Exception)
       	{
           	return false;
       	}
    	}

The HealthCheckResult object shown in the code above allows us to pass description, exception, and status data represented as a dictionary of key-value pairs. This information can then be presented on a health check web page. After building your custom health check, remember to configure the custom health check type appropriately in the ConfigureServices and Configure methods of the Startup class to start leveraging it.

Visualize your health check

If you wish to view the results of your health check in a more visually appealing format, you can use an open-source visualization tool named HealthChecksUI. To use this tool, install it from NuGet by using the following command at the package manager console window.

Install-Package AspNetCore.HealthChecks.UI

Once the installation is complete, configure the package in the ConfigureServices and Configure methods of the Startup class.

public void ConfigureServices(IServiceCollection services)
{
	services.AddHealthChecksUI();
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseHealthChecks("/health", new HealthCheckOptions
{
	Predicate = _ => true,
	ResponseWriter =
	UIResponseWriter.WriteHealthCheckUIResponse
});
	app.UseHealthChecksUI();
}

Finish things off by adding the following configuration in the appsettings.json file to let HealthChecksUI know where to fetch the health check information from.

"HealthChecks-UI": {
	"HealthChecks": [
  	{
    	"Name": "Local",
    	"Uri": "http://localhost:1994/health"
  	}
	],
	"EvaluationTimeOnSeconds": 10,
	"MinimumSecondsBetweenFailureNotifications": 60
  }

Fire up your application and navigate to /healthchecks-ui to see your health check in action!

OpinionTrends

Bringing Calm To The Valley: Lessons From Alex Tew

How one man learned to build things that matter, the hard way.

Alex Tew’s name may not ring a bell to Gen-Zers today, but for Millennials and the generations before them, Tew’s story is the stuff movies are made of. Venture capital funded growth and stock exchange listings didn’t mean anything to Tew. He just wanted to make money, quick, and that’s exactly what he did. At 21, Tew was a millionaire. And it took him only 4 months to get there!

Meet Alex Tew /Credit: Coach.me

Then he became depressed.

Then he made it big, again.

How?

And what lessons can we learn from Tew’s story?

Striking Gold and Post-success Depression

One late night in August 2005, Tew was in his room, wondering how he was going to pay off his student loans. At the time, he had just enrolled in business school at the University of Nottingham. Tew decided to brainstorm cheap things he could sell a million of. He managed to come up with a few ideas, including one for a questionable product called the ‘Gum Slinger’, which was basically a small pouch for used chewing gum.

Then he struck gold: Tew decided to start a web page with a million pixels that could be purchased for $1 apiece.

Today, this idea would have been laughable. But remember, this was 2005, and the internet as we know it today was still in its infancy. MSN Messenger ruled supreme, and internet advertising was a virtual mirror of the Wild West.

Two days and $50 in domain fees later, the Million Dollar Homepage was born.

Tew’s concept was extremely simple. For a minimum of $100, an advertiser could buy a 100-pixel block (10 x 10 grid) and display an image or logo of their choosing, with a hyperlink. The only guideline was that it couldn’t be porn.

Tew managed to successfully sell 4.7k pixels to friends and family, and he used the money to hire a PR agency to draft a press release. The release was picked up by the BBC and The Guardian, and advertisers started buying up pixels on his site.

The evolution of milliondollarhomepage.com

One month in, Tew had raked in $250k, and was receiving 65k hits per day. By the end of October, he’d made $500k from more than 1.4k advertisers. Come New Year’s Eve, 999k pixels had been purchased. Tew auctioned off the last 1k on eBay; MillionDollarWeightLoss.com bid $38k, bringing his grand total to $1.04m

After paying the tax man his fair share, Tew was left with nearly $700k to his name. He promptly dropped out of college and moved to London. Over the next four years, Tew tried to replicate his initial success by launching various different ventures. But it was all in vain.

Lesson 1: Provide Value, Don’t Demand Attention

Success can be like a treadmill. Once you achieve a certain amount of it, there comes an insatiable hunger for more. This can trick people into focusing their energies on creating things whose success entirely depends on virality or fame. Instead, Tew argues that you must focus on building things which actually enhance someone’s quality of life i.e. provide value. “Success can actually be bad, and can teach you the wrong things. I was thinking about ideas that would get attention instead of provide value” says Tew.

Unable to replicate the success he had with the Million Dollar Homepage, Tew moved to San Francisco and joined a friend’s startup incubator.

Lesson 2: Look To Your Own Problems To Find Your Next Idea

The four years he spent looking for his next big idea (2006-2010) took a toll on Tew. He didn’t eat or sleep well, and his mental health took a toll. Till then a lifelong meditator, Tew found himself slowly drifting away from his daily practice. Tew realised that he had to initiate some corrective action..so he built another website. The result was donothingfor2minutes.com, a simple website with a 2-minute timer that would restart if you moved your cursor. It was Tew’s way of forcing himself to meditate.

The timing was perfect. The rise of the internet and the proliferation of smartphones had brought with it loads of ‘mental clutter’ and people were starting to talk about digital detoxes. Questions were being asked about the long term impact of social media on one’s mental health, and the practice of mindfulness was having its moment.

According to Google Trends, search interest in mindfulness has continued to grow

Lesson 3: Take Your Time To Build

Alex was in no hurry. He built donothingfor2minutes.com in 2010. He took the next two years to figure out what he was going to do with it. In 2012, he finalised his plan to build a more robust meditation app.

Finding the seed money wasn’t easy and Tew was laughed out of many meetings. “When you talk about meditation with people who don’t meditate, and who work in tech, it’s so far outside of their world of focus” he says.

Tew eventually managed to put together $1.5 million, and launched Calm, the meditation app.

It didn’t take long for the Calm app to become popular Credit: Calm App

Lesson 4: Be Clear About How You Are Going To Monetize

From the outset, Tew was very clear about what his value proposition was going to be, and how he was going to monetise his app. To this day, the app’s flagship feature– a 10 minute guided meditation– remains free. Calm makes money by selling premium access to things like ‘Sleep Stories’ (which are basically bedtime stories for adults), and masterclasses on wellness topics.

Calm, Today

Calm’s annual revenue growth is almost a perfect ‘hockey stick

Today, Calm is valued at more than $1 billion and counts the likes of TPG and Ashton Kutcher amongst its investors. The app is locked in a two way battle for domination with competitor Headspace, and was named Apple’s App of the Year in 2017. According to App Annie, an app market data firm, Calm is the top grossing health and fitness app and 20th overall on iOS, while Headspace, its main competitor, is the seventh-highest grossing health and fitness app and 103rd overall on iOS. With more than 40 million downloads and more than 1 million paying customers, Calm’s success has been nothing short of extraordinary.

And behind much of this success is one man: Alex Tew (and his life lessons).

How to

RxSwift: Noob to Student in 10 minutes

Some time ago, we wrote a blog post on what Reactive programming is. As a technique, reactive programming has become so popular that more than 40 languages, including Java, have evolved to support reactive programming techniques. Reactive programming powers the codebases of some of the world’s largest online platforms such as Netflix, AirBnB, and Crunchbase. So clearly, it’s a technique worth familiarising yourself with.

One of the key principles underpinning Reactive programming is the use of asynchronous data streams. But what is an asynchronous data stream? Simply put, an asynchronous data stream is a stream of data where values are emitted, one after another, with a delay between them. The word asynchronous means that the data emitted can appear anywhere in time, after one second or even after two minutes, for example. 

With Reactive programming, data streams will become the spine of your application. Events, messages, calls, and even failures will be conveyed by a data stream. In a reactive programming environment, these streams will be observed and reacted to, when a value is emitted.

What are the key benefits of using Reactive techniques in your codebase?

  • Functional
    Reactive programming will allow you to avoid intricate stateful programs. Instead, you will be able to make use of clean input/output functions over observable streams
  • Asynchronous
    Traditional try/catch methods cannot handle errors in asynchronous computations, but ReactiveX is equipped with better mechanisms to handle errors.
  • Less is more
    Reactive programming provides developers with operators and transformation elements, which can be used to convert boilerplate into fewer lines of code.
  • Concurrency
    Reactive programming also provides new schedules and observers to handle threading and queues.

Getting Started

RxSwift is one of the best ways to deploy reactive code in your application, especially if you develop for iOS. Essentially, it is Swift’s own version of ReactiveX (or Rx). The more technically inclined amongst us would think of RxSwift as a library to compose asynchronous and event-based code using observable sequences and functional style operators, which allows for parameterized execution through schedulers.

RxSwift can be installed through CocoaPods just like any other pod library. A typical Podfile would look something like this:

# Podfile
use_frameworks!
target 'YOUR_TARGET_NAME' do
    pod 'RxSwift',    '~> 4.0'
    pod 'RxCocoa',    '~> 4.0'
End

Next, run podfile to install the RxSwift library to your project.

$ pod install

Understanding the RxSwift Landscape

There are a few key elements in the RxSwift universe which you must keep in mind at all times.

Observable Sequences, Observables and Observers

Everything in RxSwift is an observable sequence, or something that operates on or subscribes to events emitted by an observable sequence. Observable sequences which will emit data continuously for one or more instances are simply called ‘Observables’.

Observers on the other hand, can subscribe to these observable sequences to receive asynchronous notifications as new data is gathered to perform operations.
Observable sequences can emit zero or more events over their lifetimes.

In RxSwift an Event is just an Enumeration Type with 3 possible states:

  • .next(value: T)
    When a value or collection of values is added to an observable sequence it will send the next event to its subscribers. The associated value will contain the actual value from the sequence.
  • .error(error: Error)
    If an Error is encountered, a sequence will emit an error event. This will also terminate the sequence.
  • .completed
    If a sequence ends normally it sends a completed event to its subscribers.

Subjects

Subjects are a special form of observable sequences, to which you can subscribe and dynamically add elements. Currently, RxSwift has four different kinds of subjects.

  • PublishSubject:
    If subscribed to, you will be notified of all the events that happen after you subscribed.
  • BehaviourSubject:
    A behavior subject will give any subscriber the most recent element and everything that is emitted by that sequence after subscription.
  • ReplaySubject:
    If you want to replay more than the most recent element to new subscriber on the initial subscription, you need to use a ReplaySubject. With a ReplaySubject, you can define how many recent items you want to emit to new subscribers.
  • Variable:
    A variable is nothing but a BehaviourSubject wrapper which feels more natural to non-reactive programmers. It can be used just like a normal variable.

Operators

Operators are used to filter, transform or combine data sequences before sending them to subscribers. RxSwift provides what is known as a ‘Marble Diagram’ to help select the operators you need. A Marble Diagram visualizes the transformation of an observable sequence. It consists of the input stream on top, the output stream at the bottom and the actual transformation function in the middle.

Schedulers

Schedulers are used to create thread safe operations. Generally, operators will work on the same thread where the subscription was created. With the use of a scheduler, operators can be forced to work on a specific queue.

RxSwift has five types of schedulers:

  • MainScheduler
    This scheduler abstracts work that needs to be performed on MainThread. In case schedule methods are called from the main thread, it will perform the action immediately without scheduling. This scheduler is usually used to perform UI-related work.
  • CurrentThreadScheduler
    This scheduler schedules units of work on the current thread. This is the default scheduler for operators which generate elements.
  • SerialDispatchQueueScheduler —
    This scheduler abstracts work that needs to be performed on a specific dispatch_queue_t. It will make sure that even if a concurrent dispatch queue is passed, it is transformed into a serial dispatch instead. Serial schedulers enable certain optimizations for observeOn.The main scheduler is an instance of the SerialDispatchQueueScheduler at work.
  • ConcurrentDispatchQueueScheduler —
    This scheduler abstracts work that needs to be performed on a specific dispatch_queue_t. You can also pass a serial dispatch queue, and it should not cause any problems. This scheduler can be used when some work needs to be performed in the background of the application.
  • OperationQueueScheduler —
    This scheduler abstracts work that needs to be performed on a specific NSOperationQueue. This scheduler is suitable for instances where there is some bigger chunk of work that needs to be performed in the background and you want to fine tune concurrent processing using the maxConcurrentOperationCount. function.

And that’s about it. You have now successfully learned the basics of RxSwift. Feel free to give RxSwift a try yourself by clicking on https://github.com/ameera/LoginWithRxSwift 

Happy coding!

References:

  1. Ameera Damsika: Tech Talk on RxSwift
    https://www.facebook.com/calcey/videos/vb.199985621561/2478458815600885/?type=2&theater
  2. https://medium.com/@duydtdev/concepts-about-rxswift-and-how-to-install-rxswift-library-to-project-5a1c3484ca6e
  3. https://medium.com/ios-os-x-development/learn-and-master-%EF%B8%8F-the-basics-of-rxswift-in-10-minutes-818ea6e0a05b
OpinionTrends

Data May Be The New Oil, But Don’t Be A Rockefeller

Is there a right way to use your customers data?

In a world where data was touted as the ‘new oil’, it was only a matter of time before the debate between privacy and data sharing reached a new crescendo. Starting with Cambridge Analytica, scandal after scandal has kept alive the ever-evolving debate around how our personal data is collected and used.

In short… don’t be Dogbert Credit: Scott Adams/Dilbert

To begin with, sharing data does have its merits. For instance:

  • Medical researchers need access to confidential patient data to use in their studies of diseases to identify cures.
  • Retail chains need consumer data to identify markets that can support new stores while meeting demand.
  • Municipalities need to share data to improve transit systems and public safety.
  • Makers of intelligent connected cars need to enable vehicle data exchange and the monetization of vehicle data while protecting data privacy.

However, when companies and app developers start using this vast pool of data at their disposal to create new revenue streams by essentially commoditizing the user, there arises a question about the ethics of such practices. For instance, The Verge has revealed that while struggling to generate revenues post-IPO, Facebook considered selling access to user data in order to make money. Last year, Buzzfeed News revealed that out of nearly 160,000 free Android apps available on the Google Play Store, nearly 55% tried to extract and share the users location with third parties, while 30% accessed the device’s contact list.

In light of all this, it is only natural for users to start worrying about the privacy of their data, prompting governments to crack down hard on firms and developers who misuse personal data. But, as developers, how do we ensure that the data we collect is used for the common good, and not for any nefarious purposes (even by accident)? Where do we draw the line when it comes to data collection practices?

Here is a list of best practices (and common sense) which we advise our clients to follow

Have a privacy policy

Before you try to collect any data at all, it is important to think really hard about why you want to collect customer data, how you want to use it, and whether or not you will be sharing this data with external parties. Once these basics have been figured out, build upon them to formulate a data collection and privacy policy for your company, product, or app. Use simple, clear language (because nobody understands legalese), but run it past your lawyer to make sure that everything is okay. Finally, make the policy available and easily accessible on your website and app.

Be transparent

While the law may shape how you disclose your policies and handle your data, being transparent with your users about how their data is collected, used, and shared is a very good idea. After all, being transparent builds trust. Providing users with the power to control the data they share with you is also a giant leap forward. For instance, if you’re developing an app, consider providing users the ability to view, limit, or delete the data they have shared with you. This will ensure that whatever data you have with you, has been collected entirely with the consent of your users.

Designing self-service pages where users can control their data can be a huge step forward for user privacy and consensual collection. Users can understand the data they’ve explicitly provided, the data you’ve gathered in the background based on their usage, and the ongoing ways that data is currently entering your systems. This encourages users to take an active and considered approach to their own privacy and allows users to refuse specific types of collection with an understanding of how that may affect their access.

When given a choice between collecting and correlating data in the background and asking for it explicitly from users, it is usually best to tend towards the latter. While your privacy policy may outline various ways that you may gather data, asking directly will minimize surprises and help build trust. Users may be willing to provide more information when they feel like they control the interaction rather than when it is collected by monitoring behavior, which can feel intrusive.

If you’re domiciled in a locality where GDPR applies, then it goes without saying that almost all of the above are requirements that you must comply with. GDPR is essentially a legal framework which governs how firms can collect and handle user data, while providing greater protection and rights to individuals. The costs of non-compliance with GDPR can be quite high. Smaller offences could result in fines of up to EUR 10 million or two per cent of a firm’s global turnover (whichever is greater). Those with more serious consequences can have fines of up to EUR 20 million or four per cent of a firm’s global turnover (whichever is greater). For more information, see what The Guardian has to say.

Build strong safeguards

If you are collecting user data, a data breach can be your worst nightmare. Not only would it be a public-relations disaster, but in a worst-case scenario, it could spell the end of your company or startup. Data breaches lead to people’s identities being stolen, credit cards being opened in their name without them knowing it, and even fraudulent tax returns being filed. If you’re going to collect all this personal data, it’s your responsibility to safeguard the data you collect.

To that end, we recommend that you:

  • Back up your data in case your systems crash
  • Ensure there is no personally identifiable information within your database (make sure it’s all encrypted or anonymized)
  • Have malware, antivirus software, and firewalls that protect from data breaches (and make sure it’s all up to date)
  • Have an emergency plan in the event of a data breach

Minimise permissions

When you ask users permission to access certain data or services on their phones, ensure that you are only asking for permissions that are appropriate, and not excessively intrusive. For example, if your app is a simple tic tac toe game, it doesn’t make sense to ask the user for permission to access the camera on their device.

Don’t use code you don’t understand

Developers usually work with a lot of open-source software when building apps, and it is a very common (and good) practice to rely on other people’s code snippets, be it in the form of frameworks or libraries, where relevant. Platforms such as GitHub are a treasure trove of top-notch code snippets, which can often cut development time by a significant amount. But if that code is handling your users’ information inappropriately, it’s your problem. So make a point of checking code before you rely on it.

What are your thoughts on the data privacy vs. data sharing debate? Let us know in the comments below!

Cover image credits: Unsplash