DEV Community: ConfigCat

What can European SaaS companies do after EU-US Privacy Shield invalidation?

sige — Thu, 24 Dec 2020 14:05:15 +0000

There is not much hype around this topic however, I believe it is very important for EU businesses today.

The European Court of Justice declared the EU-US Privacy Shield to be ineffective due to the FISA 702 regulations in the United States. This basically means that US authorities can execute targeted surveillance on non-US citizens and companies. They can collect, keep, and use this data for investigation. This regulation does not affect US citizens and businesses.

Our company ConfigCat.com serves feature flags and is the sub-contractor of other companies as part of the supplier chain. Some of our European customers started to worry about if their data is safe with their sub-contractors and how does this affect GDPR.

Being a Europen SaaS company with a global user base we looked into how we can handle this quickly with minimal user impact both technically and legally.

If you are facing or faced similar issues, I'd like to hear your thoughts about it. Do you think we are going to face an increasing number of privacy issues in the future due?

Here is what we did:

Implemented a Data Governance feature in ConfigCat, so customers can decide if they want their data distributed globally or only in the EU based CDN nodes.
Reviewed all our own sub-contractors swapping the US ones who fall under the FISA 702 regulations.

I'm personally having a bit of anxiety about where this is going. Ideally, every entity should be able to use any service no matter where they are located without being worried about the safety of their data. Maybe I'm just too idealistic.

Our blog post on the topic: https://configcat.com/blog/2020/11/28/eu-us-privacy-shield

Feature Toggling Tools for $100 or less

Nichole — Tue, 07 Apr 2020 17:38:56 +0000

When it comes to feature flags, there are several packages available for start-ups on a tight budget. Here's a comparison of cross-platform packages which all offer flag management, segment targeting and percentage-based targeting.

It's worth pointing out that these services could be used for remote configuration, but they don't really compare to Firebase Remote Config. The latter is better suited to modifying content remotely. While none of these packages have out-the-box A/B testing analytics, APIs and integrations are available.

Flag evaluations are implemented differently on each platform:

Cloudbees Rollout and ConfigCat have opted to implement all evaluations on the client side, their servers only store flags and rules.
LaunchDarkly and FeatureFlow have two types of SDK's. Server-side SDK's are comparable to those of ConfigCat and Rollout. In contrast, client-side SDK's allow flag evaluations to take place on the server-side.
Bullet train does all feature flag evaluations on the server-side.

Arguably, server-side evaluations are better suited for mobile apps and web front ends, whereas client-side evaluations are fast and secure.
A differentiating factor is the functionality to schedule releases through the console, LaunchDarkly and FeatureFlow have incorporated this into their front end. Another front-end feature of interest is user segmentation management, which is available with LaunchDarkly, Rollout, and Bullet train subscriptions.

Let's dive into the available options below.

LaunchDarkly

Well established, boasting many SDKs, integrations and a functional web app.

The "Starter" package can be purchased for 75$ per month and allows for unlimited projects, environments, feature flags and rules. Reach, however, is capped at 1000 client-side monthly active users (MAUs); Server-side MAUs are uncapped. In addition, teams are limited to one developer / product owner.
LaunchDarkly probably supports more languages than any competitor product on the market. They also support JSON flag types. As mentioned, both segments and scheduled releases can be managed through their web app as an additional convenience.

SDKs: Android (Java and Kotlin), C/C++, Electron, Erlang, Go, Haskell, iOS (Objective and Swift), Java, JavaScript, Node.js, PHP, Python, React, React Native, Ruby .Net, Roku, Xamarin

Integrations: Azure DevOps (formerly VSTS), Bitbucket Pipelines, Datadog, Dynatrace, Jira, Microsoft Teams, New Relic, OAuth, Slack, Splunk, Terraform, Visual Studio Code, Webhooks

launchdarkly.com

ConfigCat

Ideal for large teams with few applications and variable MAUs.

ConfigCat's start-up package, "Pro" goes for 49$ per month if you sign a 12-month contract. There is no limit on the number of users who can be organised into 2 permission groups.
There is also no limit on the number of MAUs, although, the service is capped at 25 million requests per month - that's about 10 requests per second. As per the SLA, they guarantee 99.8% uptime. Support is also available on slack and live chat over and above email.
The package, however, only allows for 100 feature flags, 3 products and 3 environments. Each flag can have a maximum of 8 segment rules and 8 percentage-based rules.

SDKs: Android (Kotlin), Angular, Go, iOS (Swift), Java, JavaScript, .NET Node.Js, PHP, Python, React, Ruby

Integrations: CircleCI, DataDog, GitHub Action, Microsoft Teams, Slack, Trello Power-Up, Webhooks (3 per environment), Zapier

configcat.com

Cloudbees Rollout

Perfect for small scale (streaming) apps and A/B testing.

With an annual contract, the "Solo" package will set you back by 60$ per month. This package includes unlimited feature flags, projects, environments and rules. An obvious benefit is the ease with which you can dive into A/B testing analytics using Google Analytics.
The service works with streaming applications and is compatible with Android TV, Fire TV, Roku, Chromecast, Apple TV and Tizen.
MAUs are, however, capped at 2000 and as the package name suggests, only one user has access to the platform.

SDKs: Android (Java), Go, iOS (Swift and Objective-C), Java, Javascript, .NET, Node.js, PHP, Python, React Native, Ruby, Typescript

Integrations: DataDog, Google Analytics, Jira, Mixpanel, New Relic, Prometheus, Segment

cloudbees.com

Bullet Train

Good for low traffic applications with potentially high MAUs.

The "Scale-Up" package can be purchased for 99$ per month. It includes unlimited flags, projects, environments and rules. The service is capped at 2 million requests per month (1 request every 1.25 seconds) and a maximum of 10 team members have access to the platform. It comes with priority email support.
There is also a more affordable "Start up" package for just 29$ per month. This package limits the number of requests to 250 thousand (1 request every 10 seconds) and 3 users. The priority email is also excluded.
As the project is open source you could opt to host it free of charge.

Client Libraries: Android (Java), iOS (Swift)), Java, Javascript, .NET, NodeJS, Python, React, React Native, Ruby

Integrations: Webhooks

bullet-train.io

FeatureFlow

Functionality without the bells and whistles.

Their "Medium" plan retails for $80 per month. On this plan, you receive unlimited feature flags, projects, environments and rules. It also comes with 'Basic' support which guarantees an uptime of 99.8%.
This plan allows teams of up to five to use the service. Unlike competitor products, audit logs are not included. In addition, MAUs are limited to 10 000.
FeatureFlow offers a lightweight "Playground" option for 1 user. This can be used for 1 project, with maximum 2 environments and 10 feature flags. MAUs are capped at 1000.
Integration and language support are rather limited.

SDKs: AngularJS, Go, Java, JavaScript, .NET, Node.Js, React, Ruby

Integrations: Slack

featureflow.io

The table below summarises the pros and cons of each package.

In summary, LaunchDarkly's 'Starter Package' supports the most SDK's and their web interface is slightly more functional. ConfigCat's "Pro" package allows large teams to work together. Rollout's Solo package is the most convenient for A/B testing. Bullet Train's "Scale-Up" package is suitable for low traffic applications. FeatureFlow's 'Medium' package is ideal if you don't need added features such as audit logs and two factor authentication.

	LaunchDarkly: “Starter”	ConfigCat: “Pro”	Rollout: “Solo”	Bullet Train: “Scale-Up”	FeatureFlow: “Medium”
Cost ($)	75	49 (annual contract)	60 (annual contract)	99	80
Number of users	1	Unlimited (2 permission groups)	1	10	5
MAUs	1000 client side, unlimited server side	Unlimited	2 000	Unlimited	10 000
Number of projects	Unlimited	3	Unlimited	Unlimited	Unlimited
Number of environments	Unlimited	3	Unlimited	Unlimited	Unlimited
Number of feature flags	Unlimited	100	Unlimited	Unlimited	Unlimited
Number of rules per feature flag	Unlimited	16 per flag	Unlimited	Unlimited	Unlimited
Requests per month	Unlimited	25 million	Unlimited	2 million	Unlimited
Impressions per month	Unlimited	Unlimited	500 000	Unlimited	Unlimited
Security	Two Factor Authentication	Two Factor Authentication and SSO	Two Factor Authentication
Audit logs	Yes	Yes	Yes	Yes	No
Feature flag evaluations	Server side and client side	Client side	Client Side	Server Side	Server side and client side
Guaranteed Uptime as per SLA		99.8%			99.8%

3 Ways to Use Feature Flag Management in DevOps

CsillaOnTheRoad — Sat, 21 Dec 2019 08:49:10 +0000

Theoretically speaking, DevOps is a methodology that aims to merge the operation of different technical teams during the systems development lifecycle. However, there are several practical methods that serve the DevOps philosophy. Feature flag management is one of the best tools you can implement to enhance collaboration and reduce development time. We'll discuss three ways how feature flags can be easily used in a DevOps-driven environment.

1. Breaking Down Silos Between Business Units

When Agile practitioners came up with the idea of the DevOps culture, their main purpose was to eliminate the boundaries between development and IT operations in order to best serve business needs. Larger tech companies have realized that involving non-tech teams in the development lifecycle can highly boost productivity and shorten development time. With the help of feature flag management platforms, you don't need to be an avid coder to turn a new feature on or off. For instance, the marketing team of your company decides to have a Black Friday promotion on the company website. The campaign manager asks the dev team to put three banners on the website a week before the campaign begins and remove them when it ends. Also, on Black Friday, the price of certain products must appear with 70% discount and go back to full price the next day. The dev team changes the code accordingly, implements feature flags through a management platform and grants the campaign manager with full access to the requested feature flags. This way, the campaign manager gets full visibility over the requested features. Plus, if the marketing team changes the start date, the campaign manager can turn on or off the implemented features when necessary. With such a collaboration, developers can concentrate on building and give control of releases over to other teams.

2. Deploy When You Want and Release When You Are Ready

The pace of releasing new features has tremendously changed in the past few years. We all remember the days when software companies deployed feature releases on a monthly, quarterly or annual basis. With the arrival of DevOps mentality, however, the frequency of deploying updates and new features has reduced to weekly, daily or even hourly releases. Techniques like continuous integration (CI) and continuous delivery (CD) have started to sneak into the development pipeline enabling developers to constantly release their code. CI means that members of a dev team integrate their code to a shared repository as frequently as possible and then the code is verified by an integration system before it gets delivered. Obviously, when processes speed up, mistakes happen. And that’s when feature flag management comes in handy. If it turns out that the integrated code is buggy, the developer can simply apply a feature flag, disable the broken code chunk without touching the master branch and fix the bug later. Feature flagging can also be applied in the continuous delivery (CD) pipeline. CD is an extension of continuous integration in a sense that it ensures that you can release new features quickly and frequently in a sustainable way. If a change in the code is wrapped in a feature flag, you can easily turn it off if it cripples your application or website even after it got released.

3. The Dark Launch – Now You See It, Now You Don’t

In 2016, Facebook decided to introduce new reactions to posts and some new emojis were added to the Like Button. It’s always risky to modify something as popular as the Like Button so Facebook chose to release these new features to certain countries only to get some direct feedback before they roll them out globally. Based on the received feedbacks, the social networking company kept the new reactions and made them available to every Facebook user. This is a classic example of a dark launch, when only a certain percentage of users see the new feature and depending on their reactions, the feature is kept and gradually rolled out to everyone, modified or tossed away. The best way to coordinate and control such a release process is through a feature flag management platform. In the management platform, you can wrap the new chunk of code in a feature flag, toggle the flag on for a small number of users and keep it off for the rest. From DevOps point of view, dark launching enhances the continuous delivery process because you can add a feature flag to every new feature to separate its rollout from code deployment.

Wanna learn more about feature flags? Check out these two free feature flag services:

ConfigCat - https://configcat.com/

Unleash Hosted - https://www.unleash-hosted.com/

Targeting with ConfigCat: Releasing feature updates without risking your brand’s reputation

Nichole — Thu, 12 Dec 2019 09:23:32 +0000

Don’t be a Snapchat, be an Instagram.

Redesigns can be risky - just ask Snapchat. When their redesign went live in 2018, users were unimpressed. There will always be users averse to change and you cannot please everyone. Staged rollouts, however, can be used to manage and minimise backlash.

ConfigCat streamlines feature flags, making user targeting and staged rollouts simpler.

Suppose we have created a new direct message feature for our existing photo app. Using ConfigCat’s management console, we can create a flag to enable and disable this feature.

We can then create a ConfigCat client in our python application. Using the feature flag key generated above, we can get the boolean value and use it in a conditional statement.

if __name__ == "__name__":
    configcat_client = configcatclient.create_client('<API Key>')
    direct_message_enabled =   configcat_client.get_value("directMessageEnabled"
        , false)
    if direct_message_enabled:
        PhotoApp().run()
    else:
        PreviousPhotoApp().run()

Let’s roll out the update internally, this can be done by filtering on email addresses.

Once we’re happy, we can release the feature to beta testers. ConfigCat allows us to create custom attributes for users. We can define an attribute ‘user_type’ and set it equal to ‘beta’ to identify beta testers.

The attribute ‘user_type’ should be included when user objects are instantiated.

example_user = User('<Some ID>', 'user@example.com', 'Germany',
                     {'user_type': 'beta'})

We can then filter in all beta testers.

Once we are ready to go live, it may be a good idea to release the feature to the public in stages, on the off chance something goes wrong. Sensitive users have been identified as the most at risk, it’s probably best to leave them for last. Let’s exclude sensitive users and target a portion of the remaining user base.

Let’s include all the remaining users.

And finally, let’s enable the feature for sensitive users

It’s worth noting, ConfigCat also allows for more than just boolean type comparisons. Navigate here for more information on the Python SDK and other documentation.

Switches for future - feature flags in product development

zsuzsi-kun — Thu, 05 Dec 2019 12:04:12 +0000

How using feature flags makes your product development successful and safe

By the given example you can follow the process from idea to satisfied customers

Software (or even hardware) development could be a real challenge. Not just because it needs all your attention and a lot of time to do but you cannot be sure (even if you made research on the market) that your customers would like the new feature or product.

That is the reason why product development is not just a part of a job, but it is an independent work. It needs specialists, managers, tactics, and tools too. Having a good idea is far too little to give off the perfect software product - you are going to need the best people and the best tools for that.

But what if you have a really good idea and all the needed people and tools to start? On the stage of development, you have only a short period of time and you do not have too many chances: we can say that you have only one. Thus, you are going to need not just the previously mentioned people, tools and methods but some sector-specific solutions are indispensable too.

Feature flags for software development are like prototypes and tests for mechanical engineering.

This special toolset given by feature flags could guarantee a light and less risky process. To show you how it works and how can you implement it in your development process we give you an example. So have a cup of tea, let's enjoy the ride and get familiarized with the world of feature flags by using a smart interface developed by ConfigCat's team!

What is a feature flag? How can it be used for targeting?

Feature flags are like small switches in your code. They can be used to start or switch off given functions - in this way they can be used to control which users are able to see or use a specific option, feature or program part. Using of feature flags can make much easier the testing process since you can choose your target audience by a switch - you do not need any complicated choosing methods or rewrite the code by each testing step.

From a problem to an idea and just one more step to the solution.

A feature for university student which makes the planning and applying on a course easier.

Neptun unified education system is a web-based administrative interface that can be used by not just the administrative body of a university, but it is open for tutors, teachers, and students too. The system is made for all the administrative tasks since the registration at the beginning of a semester to logging into any classes.

A few years ago, a new feature appeared in the system: the schedule (or timetable) planner. This function enables the users to see the preferred classes in a table - as they have registered to these courses, but it is just a plan for the semester. This feature makes easier the process of applying for the selected courses too. Now we are going to see how we can manage the introduction of a new feature like this.

In this article, we are presenting this process by using ConfigCat but this is not the only tool to use in a case like this, you can manage it with another feature flag tool too. For example, you can use the product of Unleash.

1. step: Idea and development

Since this is a part of the software like any other function, the team must develop it. After writing the codes and finalize the first version, the testing process can be started.

Get familiarized with feature flags at this point. Using ConfigCat you can easily create switches for specified groups. These groups could be your testers or the small circle you do not want to show the latest release of your function. It is up to you, but without feature flags, the testing and implementation is a way more complicated process. Connect ConfigCat to your written code and let's start the testing!

2. step: Choosing the right audience for the first test

As you can feel, this is not a change you can easily build in the code and let rock. Minor changes must be tested - so one bigger like the scheduler must be too. And this is the point where feature flags step on the stage.

After you build the code in the program or a parallel test version of your program, you can implement some feature flags. First, let's chose the developer team - they can easily notice all the smaller issues at first sight.

Fig. 1: Feature flag for the first tester group: developers

ConfigCat's intuitive interface lets you develop feature flags based on the role of the users or any other identification attributes like beta testers, age group - the borderline is given by the collected data from the users.

Here I would like to mention that this is one of the good reasons why you should collect all the needed and important data from your registered users. There are some data you do not have to ask for (e.g. country, used platform, browser) since they are accessible by using cookies or simply log in to the app. But other parameters like age, sex, or program they are enrolled should be asked for.

Well, now we have chosen the group of the developer teams. This targeting strategy works well if we did give attention to tagging the people using our software. (No, it is not a waste of time, as you can see!)

After they accepted the changes and did not find any major issues, the testers' range could be widened.

Step 3: Giving access to more and more users

You can continue the testing process step-by-step. After giving access to your developers, you can find beta testers and your friendly users. (Friendly is a tag you can give to your user based on his or her activity and mindset.)

In ConfigCat, you can manage these flags as you can see on Fig. 2.

Fig. 2: Managing different feature flags in ConfigCat

You can even merge some lines by using the same attribute but different identification:

Fig. 3: Merging identifications

In case of the scheduler in Neptun we can say that the beta tester group can be selected from the volunteering testers or by random. The friendly ones are users who have given some feedback before. Since we need a lot of feedback now, it is not a negligible aspect and we can use their opinion later in the public release process for marketing purposes.

Step 4: Start the test process on a selected faculty

Like Facebook does with countries, we can implement new features by faculty to faculty. In this example, we have chosen GPK (Faculty of Mechanical Engineering) and have made the new function available for students on this faculty.

Fig. 4: Giving access to students of GPK in ConfigCat

As you can see on Fig. 4. students of other faculties are not able to see this new feature. We can manage different testing periods by changing the accessibility and see which faculty is the most open for the new function.

This method is like the technique used by bigger developer teams, like Facebook, etc. They usually test a new function in a selected country and after evaluating test results they make the decision if the new function could be implemented globally or should be eliminated from the codes.

Step 5: Start testing on the whole university

After trying out the new function on a faculty we can start the 'global' tests. The function could be reachable for all university students.

Fig. 5: Giving access to all the faculties at the university

In some cases, there could be a smaller group, the skeptics and you should be careful with them. They are the users are not open to new functions and features. Since they can be decision-makers you should evaluate the risks before you make the given feature available for them. They are sensitive to the changes and they notice all the minor problems too. Maybe you should make another global test before giving them the right to see the new development. You can lock them out by creating a category for them as you can see on Fig. 6.

Fig. 6: Making unavailable a function for a specific group of users

In case of Neptun we would lock out the 'older generation' as they are less open to the new features (in this case they are Ph.D. students and teachers).

At the beginning of the testing process, we can choose only a few students from the university. In ConfigCat this can be done by making a target in %, as you can see on Fig. 7. The percentage of the users can be adjusted based on the feedback.

Fig. 7: Selecting only 5% of the whole university and locking out the sensitive users

Step 6: Start the new feature as a built-in option and make it accessible to all users

After made all the steps above you have finally arrived at the most exciting part of a development process: implementation. Now you can turn all your switches on - giving enough light to your work and its results.
Now the sensitive decision-makers and the skeptics can try the new feature out. In case of Neptun we should finally make enabled the new features for the 'older generation' too.

After giving green light to the new functions we would like to think that our work is done. But I can tell you, it is not true at all. In this century you must be eager to new development opportunities not just for getting on top of your sector but to remain competitive in it.

ConfigCat can help you make your development process safe - but it cannot work instead of you. It is just a tool like feature flags are in the testing process. We are gladly helping you with not just our product but with our experience too.

Try out ConfigCat on our website and please do not hesitate to contact us with any doubts of yours!

Releasing new features to a small audience first using feature flags

sige — Thu, 14 Nov 2019 14:10:12 +0000

Do you have a product with a consistent user base and you are releasing new features? Then you need to decide whether it’s enough to just test these features in- house. This decision is always tricky, because sometimes it really is useful to receive feedback from a wider audience without the risk of imposing the new feature on your more important or so-called “sensitive users” (major companies that were pleased with your facilities and services up to the present, and you cannot risk the collaboration with them).

If you are facing this dilemma, ConfigCat‘s feature flags for targeting might provide you with a solution.

Let’s say you have a product like Instagram, and the company decided to add new poll-boxes, quiz types and options for embedding links in the stories while removing some of the older ones.

Using feature flags you will have the opportunity to enable certain features to certain group of users. Let’s say you would like to enable a feature only for the users within your company or only to a small percentage of your users (maybe in one country only) before releasing it to the entire world. In addition, you might want to exclude big companies, like H&M or Victoria’s Secret until you have received the favourable feedback from your employees, “friendly users” and a small percentage of app-users or even users from a selected area (country).

Even though in this article it’s exemplified with ConfigCat, targeting works just fine with other feature flag tools as well — for example with Unleash-hosted. The process of targeting special users goes down in the following way:

First step: you need to enable the feature:

Log in to access the Management Console
Go to Feature Flags & Settings
Select TARGET SPECIFIC USERS after clicking the actions icon

After you turned on the feature flag, you will be able to target specific users.

How does the targeting rule work?

By adding a rule you can specify a group of your users whom a new feature will be enabled or a different value will be served. A rule consists of an Attribute of a user in your application, a Comparison value (e.g. a list of email addresses) and a Comparator. ConfigCat evaluates the targeting rule every time your application requires and decides what value to serve.

A property of the user is considered as an attribute, and it can vary between e-mail address, country, and identifier or custom (you can add highly specific attributes such as eye colour).

The comparison value is any string, number or comma separated list to be compared with the selected attribute using the comparator. It can be a list of e-mail addresses, companies or users in a specific country.

The comparator has four different setting options and it marks the selection of the users with a specific attribute from the list (comparison value).

The term ‘served value’ mentioned before refers to the exact value that will be served to the users that fall into that fraction. Depending on the kind of your setting this could be:

In our example the On/Off Toggle is relevant because that is the usual state of a feature flag, but ConfigCat offers a range of different setting kinds and types.

You actually have multiple options in choosing the served value of the feature flag, for example, it can be the On/Off Toggle presented above (note: here the number of options must be 2), but if you decide to use Text and/or Number the maximum number of your options entirely depends on your subscription plan. You can add/remove options by clicking the Actions icon.

Once you’ve enabled your feature for the list of your employees for instance, you can add multiple targeting rules and ordering by clicking on the Actions icon; thus you can create more complex rule sets.

Rule sets are evaluated one by one, from top to bottom direction.
Change the order of targeting rules by drag n’ drop.

Example

Enable a feature only to users within your company except the PR team (Connor and Natasha) by adding two targeting rules:

To all other uses serve: OFF

This value will be served as a fall-back if none of the above rules apply or a User Object was not passed to the ConfigCat correctly within your application.

You can also target a percentage of users. If you enable a new feature on a platform like Instagram, you might want to be granted public feedback by including a randomly selected fraction of your users whom a feature will be enabled, or a different value will be served. The sum of all % values must be equal to 100.

Select TARGET % OF USERS after clicking the actions icon.

To sum up, targeting can prove to be great help in experimenting with new features while offering you and your company a risk-free path to gather feedback from the targeted users. Feature flags provide you with a safe environment with the option of changing your mind.

I am a happy SaaS developer. Here are my values, focus, and tools.

david-zoltan — Thu, 10 Oct 2019 12:10:01 +0000

There is this layer of abstraction where you create code. Above that is where you determine how to organize it. And above that, where you decide what real-world problems you want to solve.

Often, we think we want to solve the problems of our users. But how often do you stop to think about who your users are? And here I don't mean "do you have user personas?" and things like that. I mean, who are your stakeholders? Who do you want to make happy?

The most important person is...

Chances are high that your most important stakeholder is yourself. And any software you create should make you happy. You'll use the software that you created to make yourself happy in a way that's special to you. Maybe you take pride in creating cool stuff (I do). Or you want to be dirty rich (I do). Or you love the feeling of helping other people (well, it depends on who those people are, but mostly I do).

Pride, Money, and Helping others

Can you make other people happy if your software crashes? Maybe. Can you take pride in software that crashes without you knowing about it? Hell, no!

Can you help your users without knowing what they do? I doubt. Would you be proud to see thousands or millions of people using your software? Sure!

Can you save face without the ability to hide bugs quickly? Do you feel safe without control over how your software works? I don't. Would you be proud if 99% of people would perceive your software as bugfree, stable, and easy to use? I would! And I would make a lot of money out of it!

3 key abilities every happy software business has

You see the patterns here? It's hard to create software that will make you become rich, feel proud, and will help other people unless you:

are notified as soon problems or bugs pop up
can observe how your users use your software
can hide buggy features or roll back to previous stable versions quickly

On the other hand, the whole thing gets easy after you:

see all remote errors right after they appear
can see what your user see and where they click
alter/reconfigure how your software works instantaneously

3 SaaSs that make me happier, secure my business, and help my users

This section sounds like an advertisement, right? Well, this is a short list of services that provide me the key abilities of seeing bugs, understanding users, and remote controlling my software.

Sentry.io

This is the one that shows me bugs. (Disclaimer: I'm not working for Sentry. I use their service and love it.)

Their service has helped two of my companies creating much better software. Sentry collects all the exceptions and other errors from my software components and shows them in an organized, easy to oversee way. I can find not only the exceptions but the stack traces and other context data there. Sentry.io has helped me to kill 99% of my bugs in hours. And it takes only a few minutes to set it up. Their integrations (SDKs) have sensible default behavior and require almost zero configuration in my end.

Smartlook.com

This is the one that shows me what my users do. (Disclaimer: I'm not working for Smartlook. But again, I make great use of their service.)

The Smartlook guys allow me to watch what my website visitors do, just if I were looking directly at their screen. Smartlook creates recordings of users' actions and shows me those recordings. It does this in a GDPR compliant way, by masking out all sensitive data and storing the recordings for a short amount of time.

ConfigCat.com

This is the one that helps me remotely control my other software products. (Disclaimer: I created this service. And I love it too.)

ConfigCat allows you to create visual dashboards (it's a webpage behind a unique URL, guarded by login/password, or SSO) where you can control and reconfigure how your software works - the software you build for your users and to make yourself happy.

You can add feature flags, targeting rules, and traditional configuration settings to those dashboards. Then you can integrate that dashboard into your software through the ConfigCat SDKs in a few minutes.

What you get at the end of the day is a loosely coupled way to do canary releases, phased rollouts, sit on the feature flag hype train + the ability to change your software's configuration values through the ConfigCat dashboard.

Bonus track about ❤️

I guess she's got her reasons.

https://www.youtube.com/watch?v=CsrfovOPcjk

For those who lost the feeling of their own importance while they were creating software for others (me included). And for those left by their girlfriends while they were creating software for others (me and my ex included).

How do you recruit for user tests?

sige — Mon, 09 Sep 2019 10:22:50 +0000

I feel I got lost in the maze of Google searches filled with advertisers and self marketing articles. Seems quite hard to find authentic information about user testing.

Where do you guys usually recruit subjects for user tests?

I'd like to test my service on 3-5 software developers with a few years of experience. I believe my needs aren't that extraordinary.

Do you guys offer money or a subscription to your service in return?

Thanks for the help. I'm a little clueless here.

Playing around on CodePen I have created a simple HTML page with dynamically updating content based on feature flags

sige — Sun, 08 Sep 2019 23:51:17 +0000

This Pen demonstrates how to update a page content dynamically using ConfigCat feature flags.

Complete guide to build a Slack Chatbot in 7 minutes and host it for free

sige — Fri, 06 Sep 2019 22:27:35 +0000

Based on GitHub's Hubot. Connected to Slack. Deployed to Heroku.

I have a thing for robots and wanted to build a chatbot as an experiment that calls my service's (ConfigCat.com) \health endpoint and returns if everything is okay. It took me quite a long time to go trough the possible frameworks and docs, read all the outdated guides to find the quickest and cheapest way. I feel like it might worth sharing.

The tools needed:

Node.js installed
Slack workspace
Free Heroku account
Preferred code editor

Adding Hubot integration to your Slack Workspace

Find Hubot in Slack App Directory

Connect to Workspace

Take a note of the API Token, you'll need it later

Running Hubot on local machine

Install Yeoman and Hubot generator

npm install -g yo generator-hubot

Scaffold a Hubot project

mkdir catbot
cd catbot
yo hubot --adapter=slack

Start Hubot using API Token

HUBOT_SLACK_TOKEN=xoxb-271695489427-739714865891-Z5gPPiuTORKDFO4QvqKe1B9y ./bin/hubot --adapter slack

Open Slack and start a conversation

The chatbot should be available under Apps.

Test with `help` command

Recognizing `health` command

And make a HTTP GET call to ConfigCat's /health endpoint and reply back the results via Slack.

I created a configcat.coffee under /scripts folder with the following code:

module.exports = (robot) ->
    robot.hear /health/i, (reply) ->
        robot.http("https://api.configcat.com/api/v1/health")
        .get() (err, res, body) ->
            reply.send body

See the complete source code on GitHub.

I used CoffeeScript because I like to experiment and it feels fancy. But you can use JavaScript as well.

Test if the `health` check works

Deploying to Heroku

Check Node.js version

node --version

Open package.json and check Node.js version. In my case the generated package.json was "node": "0.10.x" so I changed it to:

"engines": {
  "node": "10.16"
}

Git commit

Make sure you’ve created a git repository, and that your work is committed.

git init
git add .
git commit -m "Initial commit"

Heroku CLI

Install the Heroku CLI. then log in.

heroku login

Create app.

heroku create

Set environment variable for API Token.

heroku config:set HUBOT_SLACK_TOKEN=xoxb-271695489427-739714865891-Z5gPPiuTORKDFO4QvqKe1B9yt --app=arcane-dusk-29327

Git push

git push heroku master

Avoiding sleep mode

Since I'm using Heroku's free plan, the app will eventually go to sleep mode. To avoid that add hubot-eroku-keepalive script to your chatbot.

Reference docs

Lazy man's guide: multiple GitHub HTTPS accounts on Windows

david-zoltan — Sat, 10 Aug 2019 10:02:03 +0000

Using multiple GitHub account's on Windows sucks by default. If you are tired of Window's Credential Manager storing only one account's credential for git:https://github.com then here is a 1-minute fix for you.

TL;DR

If you know what you're doing just:

delete your GitHub credentials from Windows Credential Manager
run git config --global credential.github.com.useHttpPath true
continue coding

If you need more detailed instructions and learn about the background just read on.

The full story

I'm juggling with multiple GitHub repos on a daily basis. They all require different credentials. It's not only the repos of ConfigCat, my feature flag service (a great LaunchDarkly alternative "by the way") but my other projects too. If you're a developer at heart, I'm sure you know what I'm talking about. I never really liked how the credential manager on Windows stores one single GitHub account for all my repos by default.

Just came through @arnellebalane's great post about setting up multiple GitHub accounts the nice way. His solution is based on SSH keys and is pretty thorough.

While I would never publicly admit that I'm lazy, I happen to know a quick and dirty solution here. I decided to share the "lazy man's guide" to set up multiple GitHub accounts on Windows. While @arnellebalane's solution is really nice, you might be interested in a more basic approach...

The problem

If you're using Windows Credential Manager to store your username/password for your GitHub account, and you have to work with different GitHub accounts for different projects, then I'm sure you've already experienced

fatal: Authentication failed for https://www.github.com/name/repo.git

Usually, this happens when you try to push to one of your repositories in the name of another account that is for your other project.

The root problem is that Windows Credential stores the one same account for all your GitHub repositories.

The solution

There is a simple, three steps solution that will help you store multiple different GitHub accounts, one for each of your GitHub repos.

Simple 3 step solution:

remove your current GitHub credentials from Windows Credential Manager
tell Windows to store different accounts for each of your GitHub repos
provide your username, password once again for each repo when you are prompted for your credentials - this is the last time you need to do that

Removing current GitHub credentials from Windows Credential Manager

Go to Windows Credential Manager, open the Windows Credentials tab, locate git:https://github.com, open the entry, and click Remove.

This will remove your GitHub credentials from the credential manager.

Tell Windows to store different accounts for different repos

Issue the following git command:

git config --global credential.github.com.useHttpPath true

Now, Windows will store different logins for each of your GitHub repos.

Reauthenticate

Just work on your project. Whenever GitHub asks you for your credentials, just type your username and password. Windows will store them and you never ever have to provide them again for this repo.