Announcements

Providing Business Continuity and Assistance to Fight a Global Pandemic – the Calcey Experience

COVID-19 has brought the world to an unprecedented standstill. The crisis has also resulted in a working from home experiment at global scale. As a software product engineering company offering dedicated, remote teams for building digital products to technology companies in Silicon Valley, New York, London and Gothenburg – working remotely is part of Calcey’s DNA. However, having the whole company working from home instead of Calcey’s headquarters at Trace Expert City, was still a new experience. 

Nevertheless, Calcey’s team has kept work going at the same velocity and in-line with all timelines committed to clients previously. As well as providing business continuity at a time of high uncertainty, Calcey’s also making crucial contributions to the efforts of some of its clients battling the epidemic. 

A team from Calcey is currently working around the clock, from their homes, building modules to support Fresh Fitness Food (FFF)’s efforts to provide meals for frontline NHS workers. FFF is a scale-up offering meals tailored to individual needs and health goals, delivered to door in London. FFF has been on a steep growth trajectory in recent months – after having digitized its processes end-to-end, with a customer and workflow management solution built by Calcey. It is now facing unprecedented demand as its offering has become a magnet for Londoners facing a shortage of food supplies. 

Another Calcey client – Compare Networks, a technology company based in California, supplying media and platform products for life sciences and healthcare industries, operates Biocompare.com, a global market place for the lifesciences products, providig anitbodies and testing resources, along with millions of other products, for researchers racing to find cures for COVID-19. Calcey’s team has been building and maintaining all technology platforms for Compare for almost a decade and continues this work unabated, during this crucial period.  

Calcey has been able to manage this shift to working from home, relatively smoothly due to quick contingency planning and internal practices, that we’ve been working on for a while, that support this style of working. We shared some of these practices through a recent blog post. Stay agile, stay safe and let’s do our bit to support our customers, businesses and commmunities through this period. 

Announcements

Keeping the Lights on in a Software Engineering Services Company During a Global Pandemic

As COVID-19 brings countries and economies to a standstill, here’s how we at Calcey are continuing to work, albeit remotely.

Image credits: digiday.com

As we write this, all of humanity is collectively focused on battling the COVID-19 pandemic. Towns, cities, and even countries have gone into lockdown, pushing businesses everywhere to allow their employees to work from home.

As a software engineering services provider, we are fortunate that our business model, industry, and circumstances allow us to keep going. But, we also recognise that keeping an entire workforce sane while working remotely for weeks is no walk in the park. It takes a lot of foresight, planning and trust to build a viable remote operating model. 

Oh, and a lot of experience, gained through trial and error over the years.

We thought it apt to share our model of remote work, which is allowing us to carry on unimpeded.

Prepare in advance

Almost a year ago, Sri Lanka was put under curfew in the wake of the tragic Easter Sunday attacks linked to an ISIS terror cell. That was the first time we tried this new model of remote work, and this year, we were able to use that experience to our advantage. Adversity is after all, a good teacher.

COVID-19’s spread around the world was slow at first, and that gave us a small window to draw up our plans. Two weeks before the Sri Lankan government imposed an island wide curfew, we at Calcey conducted a few remote work trials in which the entire Calcey team participated.

Being a software engineering services provider, Calcey has always been proud to offer our team members the freedom and flexibility to manage their own time. For instance, Calcey had already implemented an optional working from home policy, before this crisis hit. But we knew COVID-19 was going to have a huge impact on a country like Sri Lanka where tourism is a key industry (i.e. it was only a matter of time before COVID-19 reached Sri Lanka), so it only made sense to plan, execute, and learn.

Give people all the tools they need to do their job

Remote work models (and even regular work models) will quickly fall apart if people are not given all the tools they need to get their work done. Consider how sometimes, companies don’t allow offsite access to internal systems for no valid reason. In a remote work model, this kind of roadblock quickly leads to frustration, which in turn leads to a complete breakdown.

All Calcey team members were given access to all systems and devices they need beforehand. There were also a few challenges, which we eventually managed to overcome. For instance, the QA team was faced with the dilemma of figuring out how to share devices used for testing purposes while working remotely. To solve this, we turned to Browserstack, a device cloud application which allows our QA team to conduct testing on different devices through the cloud, very much similar to how they would carry out device testing if they were inside a physical office space.

Build remote-friendly team structures

At Calcey, we have built team structures so that they are remote-friendly anyway. Each development team has a team lead or architect who is in charge of technology architecture, but also assists the developers in thinking through their problems, identifying the right libraries and tools to use etc. The leads and architects are our very own walking, talking internal knowledge bases and have insight into all our projects by virtue of their experience.

Every day, all team members check in with their respective leads or architects, and discuss what needs to be done for the day or week. The goal of this practice is to anticipate any potential roadblocks and proactively figure out how each developer would overcome them. In our view, this is both a good coding practice, as well as a sensible course of action to follow, in general. We first solve the problem, before writing any code. 

The regular check-ins with the leads and architects then become a collective problem-solving session. Having an experienced hand in the fray means that we apply standardized solutions to commonly faced problems, allowing everyone to focus on the novel engineering challenges of the project and turns this into a hands-on mentoring process. 

As a result, our developers are not really working alone even when they are physically away from each other. They don’t have to reinvent the wheel at every turn while trying to figure things out on their own, and can still show up at the office with a full head of hair once the curfew is lifted for good. Less frustration equals better productivity, after all.

Put in processes and trust people to make it work

Given how we operate to tight deadlines to ship code, we have put processes in place for everyone to check in their code. Team leads are not looking over people’s shoulders and micro-managing them. Instead, we rely on a powerful tool— trust. We trust all team members of Calcey to check in regularly, provide updates and raise questions where necessary, and work together as a team.

In our experience, trust is what makes remote work (and a whole lot of other things) possible. Calcey team members know and understand that they have the freedom to manage their time so that they can both get their work done, and also live a full life. We also have a results-based culture, which goes a long way towards helping make Calcey remote-friendly. 

Remember, employees are also human


Being forced by the government to remain indoors at all times and the limited human interaction that comes with it, can quickly take a toll on an individual’s mental health. People need breaks, and perhaps even an occasional distraction to calm their minds during trying times like this. It is with this in mind that we took the initiative to organise an e-sports tournament, in which the entire company can participate. Never one to rest on our laurels, we are looking at putting together a roster of a few such activities for everyone to participate in, from the safety and comfort of their own home.

What systems, tools, and processes have you employed in your company to make remote work possible? Let us know in the comments.

And finally, we would also like to salute and thank all first responders, medical professionals, and key workers who are tirelessly working day and night to ensure that we are protected from the threat that is COVID-19.

Stay safe!

StartupsTrends

Navigating The Maze Of Tech Stacks

What You Need To Know Before Choosing A Tech Stack For Your App

Image Credits: mindinventory.com

When building an app, deciding on what tech stack to use is perhaps one of the biggest obstacles to overcome. The right tech stack can help provide the user with a great experience, thus helping drive adoption and growth in the early stages of an app’s lifecycle. But if the wrong choice were to be made in selecting a tech stack, the consequences are dire. There is often no going back, and development teams will have no choice but to scrap everything, move to a new stack, and restart development efforts all over again.

There are a few important factors to consider when choosing a tech stack. They are:

  • Current requirements and feature roadmap
  • Budget (especially in the case of startups)
  • Competency of the development team

However, care must be taken to not let the capabilities of the development team override or constrain the feature roadmap.

Next, it is important to pay attention to the proposed architecture of the app. For instance, one can choose to build a native app, cross-platform app, or a hybrid app. Today, ‘Progressive Web Apps’ are also popular, but we don’t think it is apt to consider them as a distinct application architecture, primarily because they are essentially repackaged web apps.

Let’s now compare the pros and cons of each architecture.

Native Apps

Native apps are specially made and coded for a specific mobile platform in its native programming language, and as such are extremely suitable for processor intensive and GPU intensive apps. Native apps make full use of technologies provided by the platform itself, and hence there is minimal chance of running into issues. Development of native apps is also relatively straightforward. Components are provided out of the box, and connecting them to an app is quite simple. 

The most obvious drawback with opting for a native tech stack is that if you decide to build apps for multiple platforms, you also have to build separate versions of the app. Native apps do not allow for code sharing between platforms and as a result, development times are longer and require a higher investment. By virtue of also having two separate codebases, maintenance can also be challenging. Even if a new feature is to be rolled out, your development will have to build the feature into two different codebases.

  • Technologies available:  Swift (iOS), Kotlin (Android), Objective-C, Java
  • Native apps: Uber, Pinterest, WhatsApp (These apps all make use of extensive functionalities available on the device, hence the need to go with a native tech stack)

Cross Platform

Cross platform apps can be deployed or published on multiple platforms using a single codebase, instead of having to deploy multiple native apps, one for each platform.

A cross platform tech stack will allow you to potentially use upto 80% of code used within an app, across multiple platforms. This is perhaps the biggest advantage of opting for a cross platform stack. Apart from this, there is also the benefit of being able to quickly render UI elements using native controls, very much similar to how a native app would.

However, the very characteristics which make cross platform tech stacks attractive can also be their downfall, depending on the envisaged use case. The fact that not all code can be shared necessitates extra, and a rather tedious amount of development. Further, a cross platform stack may not be as fast as a native stack, and the level to which it can interact with the device is largely dependent on the framework.

  • Technologies available:  React Native, Flutter, Xamarin, NativeScript
  • Cross platform apps: Uber Eats, FB, CitiBank, Instagram

Hybrid Apps

A hybrid app is created as a single app, but for use on multiple platforms such as Android, iPhone and Windows. From a technical standpoint, hybrid apps are actually a combination of native apps and web apps. As a result, a single hybrid app will work seamlessly on any operating system such as iOS, Android, Windows etc.

Hybrid tech stacks allow for a significant degree of code sharing between different platforms. In a boon for developers, hybrid stacks also allow for the core part of an app to be built using web technologies, paving the way for shorter development times. The web app underpinnings of hybrid tech stacks also mean that the core codebase of a hybrid web app can always be updated via a ‘hot code push’, bypassing the formal App Store and Play Store channels.

Apart from lower performance compared to native or cross platform tech stacks, hybrid tech stacks also suffer from a design flaw whereby not all code can be shared between different platforms, therefore a certain degree of native code development becomes mandatory. Further, performance too can take a hit, since all in-app interaction is routed through an embedded web browser control. A good example for how this can go wrong comes from Facebook, which in 2012, disastrously bet on an HTML5 stack for its apps. Today though, all of Facebook’s apps are built on React Native, which is a cross platform tech stack. When a hybrid tech stack is used, UI elements will also be rendered as HTML components, instead of native elements, thus leading to slower performance.

  • Technologies available: Ionic, Mobile Angular UI, Bootstrap
  • Hybrid apps: Diesel, MarketWatch, McDonalds, Sworkit

So Which Tech Stack Is The Best?

There’s no definitive answer to this question, and the decision would always depend on factors such as current requirements, the feature roadmap, budget etc. as we mentioned earlier. But, what is important is to choose the right stack for the job. A mis-step here can often be the difference between success and failure for your app.

How toTrends

Easy API Testing With Postman

Understanding Postman, the app that has become the darling of code testers around the world

Image credits: meshworld.in

Any given app in this day and age may employ a number of different APIs from various services such as Google Analytics, Salesforce CRM, Paypal, Shopify etc. This complex combination of multiple APIs which interact seamlessly with each other through a common application codebase is what has freed us from the need to be bound to our desks. Thanks to APIs, people today can choose to even run entire businesses on the move.

However, while there is no doubt that the task of imparting various functionalities into an app has been made easier thanks to APIs, these very APIs also complicate the job of a Quality Assurance engineer in many ways, the most obvious being that every time the core codebase is modified for any reason, the APIs must also be tested for compatibility with the new code. Naturally, testing several APIs over and over again is quickly going to get tedious.

This is where Postman comes in, to help with the tedious task of API testing. API testing involves testing the collection of APIs and checking if they meet expectations for functionality, reliability, performance, and security and returns the correct response.

Postman is an API client which can be used to develop, test, share and document APIs and is currently one of the most popular tools used in API testing. Its features allow code testers to speed up their workflow while reaping the benefits of automation as much as possible. Postman’s sleek user interface is a boon to testers, who don’t have to go through the hassle of writing lots of code to test the functionality of an API.

Postman also has the following features on offer:

Accessibility

Once installed, Postman allows users to create an account which then syncs their files to the cloud. Once complete, users can access their files from any computer which has the Postman application installed.

In addition, it is also possible for users to share collections of testing requests via a unique URL or even by generating a JSON file.

Workspaces & Collections

Postman’s interface is built around workspaces and collections. Think of a workspace as an isolated container within which a tester can store, group, and manage all their code test requests. Workspaces are further divided into Personal and Team workspaces. As their names indicate, personal workspaces are visible only to a user, while team workspaces can be made available to a team. Each team gets one common workspace by default, with the option to create an unlimited number of new workspaces.

Collections are simply a collection of pre-built requests that can be organized into folders, and they can be easily exported and shared with others.

Ability to create Environments

In Postman, environments allow users to run requests and collections against different data sets. For example, users can create different environments, one for development, one for testing, and another for production. In such a scenario, authentication parameters such as usernames and passwords can change from environment to environment. Postman remedies this by allowing users to create a staging environment and assign a staging URL, staging username, and password. These variables can be then be passed between requests and tests allowing users to easily switch between different environments.

Parameterization

Postman allows users to parameterize requests as variables, thus granting users the ability to store frequently used parameters in test requests and scripts. Postman supports 5 different types of variable scopes namely Global, Collection, Environment, Data, and Local.

Scopes can be thought of as different “buckets” in which values reside. If a variable is in multiple “buckets”, the scope with a higher priority wins and the variable gets its value from there. Postman resolves scopes using this hierarchy progressing from broad to narrow scope.

Creation of Tests

It is also possible for users to create custom tests which can be added to each API call. For instance, a 200 OK request test can be created to check if an API successfully returns a given request.

Postman also contains a very helpful Snippets section which contains a set of pre-written tests which can be deployed with a single click.

Testing each field of a JSON RESTful service manually every time there is a change can be very time consuming, therefore the best way to do this is by validating the structure using a schema. Given below are the steps to follow to validate the schema using Postman.

Step 1: Assuming that we already have a JSON structure we will start with the Schema Generation. We will use https://jsonschema.net/#/ for generating the schema where we can copy and paste the JSON doc into the JSON Instance and it will generate the schema for us

Step 2: After generating the schema we will go to the tests tab of the postman and declare a variable Schema and paste the schema as follows

Var schema = { <Insert Schema here>
}

Step 3: After that we will write the test as follows to do the validation process.

pm.test('Schema is valid', function() {
pm.expect(tv4.validate(pm.response.json(), schema)).to.be.true;
});


Automation Testing

Postman has a complementary command-line interface known as Newman which can be installed separately. Newman can then be used to run tests for multiple iterations.

Consider a situation where there is a need to run a selected collection of written tests automatically without opening Postman and manually triggering those tests. This is where Newman comes in. Thanks to its ability to collaborate with any program that can trigger a command, such as Jenkins or Azure DevOps. For example, with the help of Newman our tests can be integrated with CI, and if any code change is pushed, CI will run the Postman collections which will in turn help developers obtain quick feedback on how their APIs perform after code changes.

Postman can be used to automate many types of tests including unit tests, functional tests, and integration tests, thus helping to reduce the amount of human error involved.

Newman is also special in that it allows users to deploy collections on computers which may not be running Postman. Collections can be fetched through the CLI of a host computer, by running a few commands.

For the uninitiated, here’s quick tutorial on how to install Newman:

Note: Installing Newman requires the prior installation of Node.js as well as NPM (Node Package Manager).

  1. Open the command prompt (Terminal for mac)
  2. Type npm install -g newman
    Now Newman is installed in your system.
  3. Export the collection you want to run as a json file. (For instance, collectionFile.json)
  4. On command prompt go to the location of the collection json file & run the command
    newman run collectionFile.json
  5. If you want to run the test with environment variables you can export the environment as a json file.(For instance, environmentFile.json)
  6. You can run the test with the environment variables using the command
    newman run collectionFile.json -e environmentFile.json

Following are some of the other options that can be used to customize the tests

-d, --data [file] Specify a data file to use either json or csv

-g, --global [file] Specify a Postman globals file as JSON [file]

-n, --iteration-count [number] Define the number of iterations to run

--delay-request [number] Specify a delay (in ms) between requests [number]

--timeout-request [number] Specify a request timeout (in ms) for a request

--bail Stops the runner when a test case fails

Easier Debugging

The consoles contained within Postman can be used to debug any errors that may arise. Postman contains two debugging tools. One is the console itself, which records any errors which take place while testing an API. Second is the DevTools console, which helps debug any errors occuring with respect to the Postman app itself. For instance, if Postman crashes while executing a test, the DevTools console is where you would look to diagnose the problem.

Support for Continuous Integration

By virtue of being open source, Postman supports a wide variety of Continuous Integration (CI) tools such as Jenkins and Bamboo. This helps ensure that development practices are kept consistent across various teams.

 

With so many features on offer to make life easier for code testers, it is not surprising that in the world of code testing, Postman is heralded as the best thing since sliced bread.