AnnouncementsLife at Calcey

Empowering the Future Generation with Coding

Education is the passport to the future; for tomorrow belongs to those who prepare for it today

Malcolm X

Keeping this quote in mind Calcey recently dived into a partnership with the Karuna Trust to empower disadvantaged youth. Our goal was to create and support a full-time training program that would provide young people who had completed A/L’s, but not got selected to local universities, a foundation in IT and software development, preparing them to take up internships in software companies within 6 to 8 months.

A call for applications was sent out and participants for the program were chosen through a shortlisting process. It was encouraging to see a significant number of female applicants. The program curriculum was designed by Calcey and YMBA Maharagama provided a venue for conducting classes. Calcey interviewed and hired a full-time instructor. Then the program kicked off on the 27th of June, 2019 and is now underway with sessions also being delivered by Calcey team members, who have industry experience and expertise in the various technology or subject areas being discussed.

We’ve been thrilled with the feedback we’ve got so far. It’s great to see the students enjoying the curriculum we designed and wonderful to see their enthusiasm to learn. Our team members facilitating the program are energized by the thought of supporting these youth to become self-sufficient and acquire skills in a growing industry that can take them anywhere in the world.

Calcey has conducted a similar program in Rambuka before and its success led to many requests for another batch to be provided the same opportunity. This time we chose to locate it in Maharagama, so that its easier on our team members who are volunteering their time for this worthy cause.

Cheers to more sessions to come.

How to

React native advanced Mobile Application Development

New to React Native?

The technically inclined amongst us may already know the story of React Native. Developed by Facebook, it is essentially a set of libraries that can communicate with their corresponding APIs. This is where the ‘Native’ tag comes in. By design, React Native is able to easily access features native to the device it is being run on, be it a phone or tablet running Android, iOS, or even Windows, connecting native threads and JavaScript threads through its event-bridge.

React Native uses a mix of JavaScript and XML-like syntax, known as JSX, to render the user interface as a function of the application’s current state. This makes it much more interesting to build component rich UIs with principals like stateful components, a layout engine, virtual DOMs, etc.

Let’s go deep.

Here, at Calcey, React Native is one of our favorite tools to work with. Along the way, we’ve picked up a few tricks useful for scalable react-native app development which we’ll be sharing today.

Write reusable components (But don’t overdo it)

Write reusable components (But don’t overdo it)

React recommends creating reusable components as much as you can. Obviously, this makes maintenance and debugging considerably easier. However, as any experienced coder knows, defining components with too much specificity can actually render them useless. Similarly, defining components too loosely will complicate things.
Take the example of building a screen for an app. A screen is essentially a group of components. Intuitively, it makes sense to write common UI elements such as buttons, lists, etc. as reusable blocks of code. This will not only save time but also make your code cleaner.

Safe coding

Safety is determined by how far the platform will go to prevent the developer from making mistakes when writing applications. Due to the freedom given by JavaScript to decide a coding style based on the preference of the developer, code safety will become an important factor, especially when dealing with scalable apps.

React Native has a few tricks of its own which support Flow and TypeScript to avoid such cases if the developer decides to use them. Flow grants us the ability  to easily add static type checking to our JavaScript. It will also help prevent bugs and allow for better code documentation. Meanwhile, TypeScript will provide great tooling and language services for autocompletion, code navigation, and refactoring. The ecosystem you work in usually has a major influence on helping you decide  what to use, as does your previous exposure to static type systems.

However, Calcey uses these tools to make sure that developers are benefiting from them when it comes to readability of the code, or the code standards.

Extract, extract, extract

React Native projects tend to include a large number of common elements such as styles, images, and global functions (functions that format dates and times, make requests to a server, etc.). At Calcey, we generally encourage our developers to keep such elements separate from the component code. This makes it easier to share elements from anywhere within the app, while also making a given app’s codebase cleaner, and easier to maintain and scale.

Here’s an example of a color.js file coded by one of our developers:

export function hexToRgbA(hex: string, opacity: number) {
  let c;
  if (/^#([A-Fa-f0-9]{3}){1,2}$/.test(hex)) {
    c = hex.substring(1).split('');
    if (c.length === 3) {
      c = [c[0], c[0], c[1], c[1], c[2], c[2]];
    c = `0x${c.join('')}`;
    return `rgba(${[(c >> 16) & 255, (c >> 8) & 255, c & 255].join(',')}, ${opacity})`;
  throw new Error('Bad Hex');

Store management

To most React Native developers, Redux is an absolute necessity. But at Calcey, we believe that Redux is not a necessity for the most part. The way we see it, bringing Redux into the picture would be akin to using a hammer to crack open an egg.

Ever since we started using Redux, it has only come in necessary for the most complex of apps where immense scalability is required. To understand this better, consider why Redux was developed in the first place. As Facebook grew to become what was essentially the biggest web-app in the world, it had to contend with the headache of not being able to show the correct number of notifications in the header bar. At the time, it was just difficult for Facebook (or any other web-app) to recognize changes in one part of the app (e.g. when you read a comment on a post) and reflect that change in another area (i.e. reduce the number of unread notifications by one). Facebook wasn’t happy with forcing a web page refresh to solve the problem, so it built Redux as a solution.

Redux works by storing information of an app in a single JavaScript object. Whenever a part of an app needed to show some data, it would request the information from the server, update the single JavaScript object, and then show that data to users. By storing all information in one place, the app always displayed the correct information, no matter where, thereby solving Facebook’s notification problem.

Problems cropped up when other independent developers began using a single object to store all their information—basically every single piece of data provided by the server. This approach has three main drawbacks namely, introducing a need for extra code and creating the problem of ‘stale data,’ whereby unwanted data appears within an app from a previous state and increases the learning curve for new developers.

So how does one overcome this problem? By planning ahead, and using proper requirement identification. If you envision that your app will have extreme scalability issues in the future, it may be better to employ Redux from day one. Otherwise, deploying Redux selectively is wiser. After all, it is possible to apply ideas from Redux without using React. An example of a React component with a local state is given below:

import React, { Component } from 'react';
class Counter extends Component {
  state = { value: 0 };
  increment = (): void => {
    this.setState(prevState => ({
      value: prevState.value + 1
  decrement = (): void => {
    this.setState(prevState => ({
      value: prevState.value - 1
  render() {
    return (
        <ChildComponent value={this.state.value} />
        <Button onClick={this.increment}>+</button>
        <Button onClick={this.decrement}>-</button>

We can take these attributes or functions to any depth of the component tree and use them inside those components. This mechanism is called prop-drilling. Be warned though, it’s not a good idea to drill multiple layers unless you have an understanding of where the props are coming from, and where they are going next.

Another solution we can use is the Context API provided by React itself. The Context API allows us to access these props of the parents from any child or a parallel component using the consumer design principal. All these options are used at Calcey, based on the use case.

These are a few of our internal React Native practices and tricks. What are yours? Let us know in the comments below!

How to

Automating The eSignature Process Using DocuSign

In an ever-evolving digital world, legal documents with dotted lines for signatures are perhaps one of the last remaining analog holdouts. However, that too is now going digital, with e-signatures gaining more widespread acceptance.

There are a plethora of services online which allow users to sign documents electronically. DocuSign is one of the most well known, while HelloSign, SignNow, and Citrix RightSign are a few others that make up the rest of the pack.

The basic premise of eSignature services

In order to use an eSignature service, a user must first upload a document that will be scanned by the service. Next, the user will be allowed to define the areas on the document where a signature or some other type of input is required from the signees. Once all this is done, the signable document will be delivered to the specified signees via email.

Everything works seamlessly when it is just one document that needs to be sent across at any given time. However, what if a user needs to frequently send similar sets of documents to different groups of signees, perhaps on a daily basis?

In such scenarios, it may not be wise to require a user to upload documents and define input areas several times over. Not only is this time consuming, but it is also extremely tedious.

Faced with this problem, one of our own clients recently turned to us for help.

Our Solution

Having identified the scale of the problem, our engineers set out to develop a solution that could unite the convenience provided by a service such as DocuSign with the simplicity and seamlessness promised by automation.

Since the client was already using the DocuSign platform to send documents to signees, our engineers decided to build a layer of code that would sit above DocuSign, thus essentially building a customized eSignature platform for the client.

Our solution is expected to allow the input of all details relevant to a signee such as full name, address, etc into a database. Once the data has been input, all the client has to do is select the relevant document, select the name of the signee, and the code will take over the task of populating all the relevant fields with the correct information.

How We Built It

In order to build a code layer that runs atop DocuSign, one must first sign up for a DocuSign developer account and build a sandbox. Visit and sign up to create a sandbox.

Next, an authorization method must be chosen. Due to the need to ensure that the application is able to access the DocuSign API without the need for any human interaction,

Calcey’s engineers chose to use JWT as the authorization model. With JWT in place, our custom application will seek to impersonate a user with a DocuSign login. In order to allow the impersonation to take place smoothly, we must register the application with DocuSign, and ensure that the target user provides explicit permission for the API to use their credentials. It is important to note that the process of granting permission to use one’s login credentials is a one-time action.

You can now choose to create an envelope template, which can hold a set of documents that require signing. Once the documents have been uploaded, the user needs to manually specify where data input is necessary on each document.
Note: When creating placeholders, it must be ensured that the template contains one or more signees. It is also important to insert only the role of the signee when creating the template since all other relevant information will be taken care of by the application.

Once all placeholders have been defined, we can consider the template ‘ready’. Now, whenever a user wants to send out documents, the DocuSign API can fetch a list of pre-uploaded templates, allowing the user to pick and choose the correct set of documents to send out. With the aid of the Template ID, the DocuSign API will create what is known as an ‘envelope’ and automatically deliver the documents to the intended recipients.