Every developer desires to write code that does not break their previous functionality (unless you intentionally want to break it 😎). Functional testing involves writing a set of tests either unit, integration, acceptance or End to End tests to check whether a system or some piece of code behaves in a way that it should. Most of these kinds of tests check assertions against the desired outcomes. Given that developers develop systems that should behave in a certain kind of way, we as testers expect that this behavior should not change and the purpose of our functional tests is most of the time to validate that the behavior of our systems has not changed even after changes have been made to the code base.

Automated testing is the new norm when it comes to writing tests for software systems and this is important mainly because we can save time and verify that our software systems have not broken even as our applications scale both in size and in the number of users. But like any other technology Automated testing has its limits.

Functional testing was developed to check for behavioral changes and outcomes but this is slowly being outpaced by our testing needs as we keep pushing the limits to satisfy that user who caught a visual bug. For example, It is presently not uncommon to find such a test with a blend in of functional and visual assertions.

desscibe('Login Workflow', () => {
  it('can login in a user successfully', () => {
     await navigate('/login');
     await fillIn('[data-qa="login-email"]', 'testuser@test.com');
     await fillIn('[data-qa="login-pass"]', 'testPassword');

     expect($('.submit').to.have.class('btn-primary'));
     await click('.submit');
     expect(find('.dashboard-text').to.contain('Welcome testUser');
});
});

In the above test, we are checking that a user is able to log in and also going an extra mile to confirm that there is a class btn-primary and a Welcome testUser message when the user logs in. Without a doubt, this test will increase our confidence given that we are going beyond testing the functionality of the logging in the component but also verifying that the message that a user should see can be seen when they log in. But does this solve our visual problems that are bound to occur?

Overdoing visual assertions in functional tests leads to the Assertion hell Where you might end up being tempted to assert that every single class exists, every button has a particular class, every element has specific margins, padding, or even opacity(not considering the millions of possible permutations that can occur in the UI elements). Without your own knowledge, you will be leading yourself in a rabbit hole that might lead to tests that are not maintainable in the future.

For functional tests to continue being of assistance they need to have these characteristics: validity, reliability, objectivity, and norms. To top it all up tests need to be maintainable, simple and straight to the point where no struggles should be present when debugging or fixing them. Tests should be straightforward and one should not spend time trying to understand what a particular test is written or what it is testing as that should be clear from the beginning. Porting visual assertions to functional tests slowly dilute the purpose of functional tests and in the end, we may end up with tests that are not objective, reliable or even valid in some circumstances. Imagine having to re-write your functional tests just because you changed class names or you adjusted your margins 🤔 (It does sound ridiculous right?).

Now that we know that having lots of visual assertions in tests that should majorly test behavior is a bad practice and that they do not in reality, have a lot of coverage in terms of visually testing applications, then what is the way forward? (of course, this post was not all a rant about bad testing behaviors 😄).

Visual regression testing is the solution we might all need if we have more visual assertions needs than behavioral assertions needs in our functional tests. Visual tests behave just like functional tests with the difference being that the outputs are normally what is perceptible to the human eye. Visual testing creates visual differences in the application changes and rather than saying the test passed an assertion or failed, it creates a visual difference in terms of an image. The image shows you what your application looked like before changes were made and what it looks like currently after the changes have been made. With this in mind, a developer or tester can easily tell whether the code change was a feature or the changes introduced a bug.

When a test with visual regression is set up, on the first test run a baseline image is created and this image is used as a base for all other test runs. In the event of an image change, the visual regression software shows the base image(baseline) and the checkpoint(newly generated image). If at all there are any changes, an Image diff is generated highlighting what has changed in the image by comparing the baseline and the newly rendered checkpoint image by the test. With visual assertions, you can be able to determine visual differences within a range of screen widths while at the same time emulating different devices and browsers. The process of achieving visual assertion is not as tiresome as would be when trying to achieve this with functional tests.

Visual tests are not at all replacements to functional tests but replacements to the testing of visual behavior which most teams have implemented in their functional test suites. Visual testing does not explicitly declare that a visual representation is wrong and in most cases leaves it to the user to either embrace the new visual image generation or reject it. If a user accepts a new visual regression image then it automatically becomes the baseline image and all other tests will be run against the newly generated image snapshot (now our baseline).

Moving away from all the praises, some of the features that make applications intuitive are the features that make visual regression a nightmare as the snapshots and images are static representations of the application at a specific time. Having animations, GIFs and dynamic data in an application can lead to major frustrations. When doing visual testing the snapshots will most often change when any UI changes are detected and this can happen without an actual change in the structure of the application. Practically this makes it difficult to visually have consistent images and test cases too if the situations are not well handled. The problem can, however, be fixed by freezing the animations and blocking out sections of the application that are dynamic hence making the images that are generated look consistent over time.

Another fix to dynamic data for visual regression testing would be to use a mock server instead of making actual API calls and this will ensure that all the data that the application expects has already been mocked and we can, therefore, expect consistency of the snapshots as we are already aware of the outcomes even before the tests start running. There are different tools out there that utilize visual regression testing and while some can be picked and used immediately, others may take days to set up.

Usage

Now that we saw how visual behaviours are tedious to write and assert, take an example of how visual testing can prove useful especially for tests that one uses to assert that the structure of the web application does not change.

describe('Login Page UI Elements Test:', () => {

  beforeEach(() => pageObjects.actions.goToLoginUrl());
  it('can get all form elements on login page', () => {
    cy.eyesOpen({
       testName: 'Login Page UI Elements Test: can get all form 
       elements on login page'
    });
    cy.eyesCheckWindow({
        sizeMode: 'selector',
        selector: '.auth-box-w'
   });
 });
})

Above is a visual test that uses Applitools Visual AI plugin and cypress test framework to assert that all elements in a login page are present. In the beforeEach() the user is redirected to the login page where the test is supposed to run then cy.eyesOpen() uses the eyesOpen() method from applitools to initialize the visual test and the cy.eyesCheckWindow() uses the method checkWindow() from applitools to take a snapshot of the page. Once the test has run a method called cy.eyesClose() is called to teardown the test and the test processes terminate.

When the test is first run, the visual test tool creates a baseline that it associates to the test and keeps it for subsequent runs. On a second run, the baseline image is then compared to the newly generated image by the second test run (commonly known as the checkpoint) and the test either passes or fails depending on the state of the image.

baseline image

In the above baseline image, there is a graph and a number of rows that were captured by the visual test software and this was what was recorded as the baseline image. Any changes made to the web application will be shown in the checkpoint image and a choice can then be made to either replace the baseline image or to flag the changes to the web application as a bug.

checkpoint image

In this checkpoint image, the graph does not load and therefore an image difference is shown of items that do not correspond with what the baseline image had when the test was first run.

The reality is, this is so much easier to debug as we can automatically tell that the bar graph is not present, something which could have been very difficult to achieve using functional testing. Another error that would be difficult to identify would involve an abrupt change of data in the bar graph that is not supposed to change, while it is difficult to identify with the naked eyes, the visual testing tool would immediately capture and highlight the differences on the image diff. Imagine having to assert that every bar element is of a specific length or height and having to update such functional tests when the data changes. This would be unmaintainable in the long run.

As tools get better and better, we will witness a transition of most teams from the current norm of functional testing to visual regression testing. Artificial Intelligence models might be at the forefront to advocate for these kinds of technologies such as the visual AI tools from applitools. As at the time of writing this article (November 2019) the technology to Artificially identify image differences pixel by pixel is not that great, but there is so much potential for what can be done and what the technology can achieve.

In conclusion, it is important for teams to understand that if at all they deal with applications that test more visual behavior than functional behavior in their test suites then they need to invest in a visual testing tool. Adoption of the visual testing tools not only makes it easier for teams to work efficiently but also reduces the testing time and significant reduction in the time spent catching bugs that would otherwise be caught by the users of the applications developed.

Functional Vs Visual Regression Testing was originally published in The Andela Way on Medium, where people are continuing the conversation by highlighting and responding to this story.

Software Testing involves the validation and verification of the system functionality against the requirements. Various tests can be carried out to validate whether the system performs as required. In this article, we will be diving deep into two of the most fundamental types of testing: Unit and Integration Testing.

Unit Tests
Unit testing involves testing individual components or units in software development.

The purpose is to validate that each unit of the software performs as designed. A unit is the smallest testable part of any software. It usually has one or a few inputs and usually a single output.

With unit tests, we get coverage. Coverage only shows us the number of lines in our code that are executed when we are running our tests but not exactly the bugs or the robustness of our solutions. As a matter of fact, it is useless to measure the robustness of a codebase using coverage as we can have high coverage without proper testing. Testing is about the quality and not the quantity and as Goodhart’s law goes When a measure becomes a target, it ceases to be a good measure.

When it comes to test execution and application robustness, quality and not the quantity of tests is what matters and coverage or a high number of unit tests do not seal the deal.

Do not read me wrong I am not saying unit-tests are entirely useless. I am just saying that you require more than unit tests to gain confidence in the performance of your applications in the real world. To solve the deficiencies created by unit testing, integration testing is used to tie up different units and ensure that they perform as expected when wired up together.

Integration Tests
The level of testing involves combining a group of software units and testing them as a group. Integration testing should always be done once the unit-testing phase is done.

The purpose of this level of testing is to expose faults in the interaction between integrated units.

Integration tests are higher in the testing pyramid than unit-tests and have a goal of ensuring that processes and not units are tested. Writing Integration tests might involve mocking responses using fixtures, trying out user-centric scenarios such as reloads, intentional error introduction and even testing out edge-case scenarios during usage.

Integration tests cover the scenarios that are too complicated for unit testing to capture but that would also be an overkill for the end to end testing process. Integration tests could involve a process such as:

1. Navigate to the login screen
2. Enter login details
3. Navigate to the dashboard
4. Reload to ensure the application preserves the state of the logged in user.
5. Validate user is still logged in

While the above process is simple and almost obvious it is almost impossible to achieve using unit testing. The example, however, exemplifies the use of the application in the real world and uses various units to achieve the result. Integration tests, therefore, serve the purpose of bridging the gap between user-scenarios that involve different units and components grouped together and functionality written for the sole performance of the application (sole units and components). Truth be told, integration tests on their own cannot guarantee the application robustness and they are too part of the pyramid of what makes up a good system.

Conclusion

Both integration and unit tests are important for any software where the guarantee of usage and robustness needs to be present. In all instances, however, the test scenarios and the test cases are what determine the quality of tests and not the coverage. Next time you write your application remember that without integration testing all you are doing is exemplifying the above gif. Happy Testing!

Towards a robust testing future: Unit Vs Integration Tests was originally published in The Andela Way on Medium, where people are continuing the conversation by highlighting and responding to this story.

Did you know that the current number of internet-connected devices as at 2018 was more than the number of people who actually exist on earth? CISCO reports that by the year 2020 there will be about 30 billion connected devices, we are currently at about 23.14 Billion.

The ‘Internet of Things’ (IoT) at first may sound like a complicated application and use of technology but in the actual sense, it is a fairly simple concept to understand and maybe if you are ambitious enough to implement.

IoT is a network of devices, vehicles, and home appliances that use embedded systems and are connected together through the internet with the aim of interaction, connectivity, and data sharing.

Let’s try to break down some concepts here, for a system to be considered to be using IoT it has to have a network of devices that are connected through the internet, the system should share data through a network and should make use of embedded hardware systems that run software enabling the device to be ‘IoT capable’.

The concept of IoT was to spread the ‘smartness’ of devices beyond normal computers, laptops, and mobile devices and transfer the same to traditionally ‘dumb’ devices. IoT converts dumb devices to smart devices by adding the capability to network, communicate and share data. So say your fridge only had the capability to store veggies, with IoT it could be able to tell you what capacity of veggies you have left and also order the same from your nearest food store, with your permission of course (sounds cool ?).

IoT is a fairly new technology to the technological field but the potential of what the technology holds will change the world. The term IoT was coined at Massachusetts Institute of Technology (MIT) in the year 1999 by Kevin Ashton with the first device known to use IoT being a Coca-Cola dispenser machine that could report its inventory on whether the loaded drinks were cold. Like any new technology, the future has to be drawn, legislation written and success defined and to this day we are yet to get to the last phase before IoT products can be made available to the mass markets in large scales.

IoT cannot exist without the internet as the devices are made alive by the internet. One of the major setbacks of IoT has been having devices that need a strong internet dependency which means that IoT can only be implemented in areas that are internet ready and that can provide the required bandwidth for both connectivity and data sharing.

It is beyond evident that IoT has been inspired by the growth of mobile devices, cloud computing, and computers that envision a whole new world of ubiquitous computing. Adding to the sweet bit of IoT might be the birth of 5G network (set to be rolled off and tested in early 2019) which promises speeds of up to a whooping 20Gigabytes per second within distances of up to 90 meters which are about thrice of what 4G has been able to achieve. Not only are the speeds super good but also it is expected to have ultra-low latency levels which mean seamless communication and data sending between the various IoT devices (communication nodes).

Away from technological and engineering jargon, here is why IoT will be a deal breaker for our economies once it is rolled out in large-scale use:

Building and Home Automation

Through the use of IoT, it is possible to monitor and control mechanical, electrical and electronic systems in various buildings using one single system. The main advantages that are attributed to the interconnection of devices include efficient energy management systems for buildings and hence promotion of a greener economy, massive data collection which could be a major driver for data science and machine learning, real-time monitoring which provides for efficiency and accuracy when monitoring remote systems.

Transportation

Using IoT in autonomous driving could mean zero or close to zero traffic in the future smart cities as the vehicles could communicate through the use of sensors and draw alternative routes to ease traffic. The data received from the vehicles could also be used to calculate the routes that would lead to more energy saves for the vehicles (electric of course). IoT could also be used to solve problems such as city parking, traffic lights control, and even toll collection services.

Agriculture

IoT through use of various sensors is currently being actively used in agriculture to monitor humidity, temperature, pH levels, wind speed, rainfall and even pest infestation in crops. The sensors are integrated with mobile applications and cloud platforms and this becomes essential in the automation of the farming practice.

The above are just examples of what IoT can be used to do, among others are how it can be used to stop forest fires, create safety for logistical needs and goods under transit and better still be used in a predictive analysis of weather patterns. Ooh and not to forget the smart cities where every single system will be interconnected.

Truth be told we are still quite far from achieving the dream and we might not get to this soon but the reality is that we are slowly starting to see the onset of a future that we have long dreamt about. Smart televisions that can talk back to us, smart speakers that can do anything from controlling our home lighting to increasing the temperatures of our rooms and talking smart speakers. All the above implementations explain how IoT is slowly gaining pace. Mind you we are just at the beginning of an era which might be more interesting than what we are prepared for.

Hardware and robotics are fairly expensive fields to venture in but that does not mean you miss out in the fun if you are an IoT enthusiast. The world is constantly changing and IoT will be the technology that will solve most o the problems dealing with automation and real-time inefficiencies. While the field still seems level and the storms are yet to come, I believe we can all play a role in ensuring that the IoT field has enthusiasts not only as software developers but also as testers and feedback givers on the quality of products produced by the field. We can inspire great technologies but we must be willing to give sacrifices of both feedback and developing the newly formed IoT ecosystem.

Awesome projects that IoT has inspired in Africa

M-Kopa Solar: A solar kit that is used to provide lighting to rural homes that are not yet connected to the electrical grid. The kit can be diagnosed and repaired remotely if need be.

Farmerline and M-Farm are also successes of IoT in Africa as they both assist in the boost of crop production by leveraging the use of IoT and Big Data to provide the farmers with sufficient information to improve on their practices and make their current farming methods more efficient through connected systems.

Africa is a growing continent and the rest of the world knows it, the problem is figuring it where to start tapping the existing potential of the continent. Thinking critically IoT could be the game changer, solutions could range from farming solutions to solutions that will help the continent save water or diagnose diseases with minimal interference of a medical practitioner. I mean there are a lot of problems that need to solved and Africa would be the perfect ground to build the technology, experiment with it and see it become something beautiful in the future.

The Internet of Things just like any other technology will continue to grow both in complexity and sophistication and this will solve challenges such as data processing and data analysis problems which are some of the largest challenges of IoT. We cannot ignore the fact that IoT is the next wave of innovation that will lead to the “humanization” of every object in our day to day life through the use of automation.

Convergence of complementary technologies such as machine learning, Artificial Intelligence, and big data will also play a major role to ensure that the implementation of IoT becomes much faster and easier and therefore leading to improved aspects of our lives be it at home, at work or anywhere that comes in between the two.

Do you need to hire top developers? Talk to Andela to help you scale.
Are you looking to accelerate your career as a developer? Andela is currently hiring senior developers. Apply now.

Why IoT is the real deal was originally published in The Andela Way on Medium, where people are continuing the conversation by highlighting and responding to this story.

Every single month (or less )a new JS framework is shipped, however, a few years ago after a period of agony for frontend developers, ReactJS was born. ReactJs is one of the fastest growing Javascript Libraries in history (Thanks to JS hype) but are we utilizing the core react functionality to full capacity? Your guess is as good as mine, NO! The usefulness of ReactJs is in its strength to integrate reusable components in a project hence eliminating the frequent violation of the Don’t Repeat Yourself (DRY)principle (spaghetti code). Modular reusable code not only creates an appeal to the reader, or developer but also reduces the amount of code that the developer has to write.

While the focus of reusability to many developers lies is on large components that are used by more than one route, it is also possible for small components on the same route to enjoy the modularity of being fully reusable. Reusability means that if for example, you had a button, you do not have to define any other button but instead reuse the button for all other reasons that you may require, this is through customization of the button props. Props are arbitrary inputs to a component and they define how a ReactJS element should appear on the screen. In ReactJs passing in props is what determines if various properties of a particular component can be changed or reusable. In illustrating how Reusable components should work we will use a Card component and a Button component that we will customize to produce cards and buttons of various characteristics all taken from one reusable component. sounds cool?

The Card component holds a skeleton of what a card should look like i.e all the props that we should pass to the card and the general structure of the card. The skeleton is what we will modify to produce the desired component output. The properties (props) passed to the Card and Button components will be used to modify the components to the liking of the user and this is done depending on the desired end result. Defining what props the component should accept gives the component the flexibility of having different properties when it is rendered. {props.propName} is used as the standard definition of props in functional components.

If at all a user requires a card with a border classcard border-primary or even a button from the bootstrapbtn btn-primary those are the props that will be passed ontoprops.cardBorder andprops.className in the card and button components respectively. Thecard text,card header and even thecard images are totally customizable hence ensuring that the card component can always be recreated by passing down the required props. The reusability also applies to the button component which is called by theprops.children property of the reusable card component.

Reusability of ReactJs components not only increases readability but it also eliminates the chances of errors and code bugs as errors can be traced back to one point of failure (The parent component), and once resolved it works for all the components.

One catch to reusable components is that the user is at liberty to make the choices of how much reusable their components can become. For scalability purposes the higher the reusability levels the better for the codebase and this will trickle down to the developer happiness levels (assuming nothing else at the time is diluting this state). It takes less effort to debug a simple single component rather than it would take ten components that are doing something similar or closely similar.

From a simple card and button, little or no effort and usage of DRY principles you can be able to build and ship great features that are scalable. ReactJs was built for reusability and if one cannot be able to reuse the basic UI components then you might need to rethink your development strategy and whether you are using ReactJS for the right reasons.

The image above is an illustration of the three components built from the Reusable Bootstrap Card and Button. Zero hustle involved!. The only different things among the components are the props passed down from the main Higher Order Component that calls each of the cards including the profile section.

Software development is an art and it is not all about writing code, it is all about writing good code. As I love to say software development is not about getting to the end goal, it is a journey and getting to that understanding makes life more interesting as you strive to not only get to the end but also understand everything that will lead you to the end of your goal. Happy Coding!

ReactJS: The Art Of Reusable Components was originally published in The Andela Way on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the last couple of weeks, I have been experimenting with Node using express and MongoDB as the tools of work. One thing to note is that NodeJs is a runtime that is built on Javascript’s V8 engine. NodeJs executes javascript code outside the browser and that makes it famous for use in day to day JS applications that do not necessarily run on browsers. NodeJS is therefore famous for writing server-side-scripting and command line tools.

Express is a web application framework that is built to work with NodeJS to build web applications and Application Programming Interfaces (API’s). Well if you do not mind, express is the de-facto standard server framework for working with NodeJS.

MongoDB is a document Oriented Database that was designed to store semi-structured data. MongoDB stores information in terms of key-value pairs and unlike relational databases information is not held in different tables that bear a relationship with one another. Well, my choice for MongoDB is that I wanted something I could work with which was easy to understand and a bit flexible.

I know you might know What API’s are if you are still reading this article right now :-), so I am going to save you the time to read through what API’s are and how to create one using Express and MongoDB. In a couple of weeks, however, I took lessons home that could be great for any person who might want to dive into the development of API’s using both Mongo and Express Js.

Lesson One: Return Statements

Express Js offers a flexibility of return statement and in offering such you might be carried away too much to forget that you need to handle errors. An example is a statement below that should add a user or throw an error if any exception is encountered in the process of creating the user. While the statement appears almost okay, where the arrow the lack of a return statement poses a loophole as the app is bound to crash if the error is found twice. A return statement on results when errors are found is more important than you may actually believe.

Wrong!

User.addUser(user, (err, user) => {

if (err) {

->>>>> res.json({

success: false,

message: "Failed to create the user" + `${err}` || err

});

} else {

res.json({

success: true,

message: "User Registered Successfully",

user

});

}

});

Correct!

User.addUser(user, (err, user) => {

if (err) {

->>>>> return res.json({

success: false,

message: "Failed to create the user" + `${err}` || err

});

} else {

res.json({

success: true,

message: "User Registered Successfully",

user

});

}

});

Lesson Two: Unit Testing

Testing is as important as the code you write, while you might not understand why we should write tests, it is not only for the purposes of increasing the coverage on Travis and coveralls but it also gives you the first-hand experience of how your code will behave under different circumstances. If your tests do not work properly you, therefore, risk having a buggy application that will more often than not break when your users use the application. At this point after fixing more than half of the application using tests, I think testing is the only way to give you the confidence of a bug-free system and lots of nights of sleep.

Lesson Three: Testing Frameworks

As I dived into the project I was determined to not only finish it but to also learn from it. testing was a huge part and there was no way I could ignore it. I went through several frameworks including jest and mocha and even more packages that made testing easier like chai, supertest, and even mongo-client. Mocha was my choice as there was more recommendation from individuals who have previously used it. Halfway through I discovered a huge blocker, mocha was running the tests but after initializing the MongoDB connection after running the tests, the connection remained open.

After several sleepless nights, I then discovered that Mocha no longer terminates processes and therefore you should always explicitly terminate your processes after the tests run and more to that you should carefully read the documentation as the changelog was just recently done in April 2018.

To terminate mocha tests you then have to have two things either have a flag —-exit on package.json after running the tests or

"scripts": {

"test": "./node_modules/.bin/_mocha --exit --reporter spec"
}

explicitly terminate after your tests have run

after(async function(done) {

await User.deleteMany({});

await Car.deleteMany({});

await process.exit(0); // Terminate process after running tests

done();

});

Lesson Four: Callbacks

Callbacks are important in Express, it is so easy to ignore them but trust me they are important. Most of the time code implementation has callbacks the either to return the data that is required or an error if an exception is raised. However, when it comes to running tests, most of the execution is done in a top-down approach and that means if the Base TestCase fails to run all other tests will fail.

You explicitly need to have callbacks when running tests as the failure of one test could easily transition to the next test.

Example Test Case

it("Should throw error if wrong car id is provided on fetch", function() {

request

.get("/oober/api/cars/1")

.set("Authorization", _token)

.then(res => {

res.body.should.be.a("Object");

res.body.should.have.property("success");

res.body.should.have.property("success").eql(false);

res.body.should.have.property("message");

res.body.message.should.be.eql("Error fetching car");

});

});

it("Should get a single car", function(done) {

request

.get(`/oober/api/cars/${_carId}`)

.set("Authorization", _token)

.expect(200)

.then(res => {

res.body.should.be.a("Object");

res.body.should.have.property("success");

res.body.should.have.property("success").eql(true);

res.body.should.have.property("carData");

});

done();

});

If the first test fails to run, it will automatically affect the running of the second test if the callback method is not declared as shown above. Best practices should always to initialize the parameter ‘done’ in the test method as in the second test and to always return the done method when execution of the test completes whether successfully or with an error. Express is intelligent enough to know that the argument[0] on the test method is a callback.

Lesson Five: Coverage and Continous Integration

Run away from Travis at any cost! Run! I have spent the last four days trying to figure out what is wrong with Travis and in all honesty, I did not find an answer to the question, I would not mind if you emailed me or just left me a comment below :- Travis is really good as it literally takes 5 minutes or less to set-up but really bad when it comes to memory intensive projects and projects that have a lot of dependencies.

Introducing CircleCI-2.0 Circle CI creates images for different jobs and if you are familiar with docker, it like creates containers for your application integrating all the resources that are required for you to run or test your app. After migrating and running away from Travis I was able to successfully integrate coverage and coveralls, for all the future developers who will be reading this article my advice would be if you have a complicated working structure do not work with Travis, I repeat do not try running your tests with Travis!.

Well, while I may not qualify to be a Best Practice Master, here is the link to the app in question, you may learn a thing or two and maybe write an article too for the future aliens on an advanced level of understanding. Until the next article, peace-out!

The Art of War was written at around 750BC by a Chinese General known as Sun Tzu. The success of the general throughout the time period was attributed to his mastery of craft on how to fight and how to wage war on his enemies by controlling an army and the external factors such as water, wind, soil rivers and food. The art of war applied to the soldiers whether when one was being attacked or whether they were attacking.

Below is an extract of some of the most important snippets i got from the text. While this is applicable in war ,some of it makes perfect sense on why you should apply it in the real life with the perspective of winning and becoming a better individual.

Chapter One:

• All warfare is based on deception. Hence, when we are able to attack, we must seem unable; when using our forces, we must appear inactive; when we are near, we must make the enemy believe we are far away; when far away, we must make him believe we are near.
• If your enemy is secure at all points, be prepared for him. If he is in superior strength, evade him. If your opponent is temperamental, seek to irritate him. Pretend to be weak, that he may grow arrogant. If he is taking his ease, give him no rest. If his forces are united, separate them. Attack him where he is unprepared, appear where you are not expected.
• If your opponent is of choleric temperament, seek to irritate him. (It gives you a vantage point of attack)

Chapter Two :

• What is essential in war is victory, not prolonged operations.

Chapter Three:

• It is said that if you know your enemies and know yourself, you will not be imperiled in a hundred battles; if you do not know your enemies but do know yourself, you will win one and lose one; if you do not know your enemies nor yourself, you will be imperiled in every single battle.
• For to win one hundred victories in one hundred battles is not the acme of skill. To subdue the enemy without fighting is the acme of skill.
• What the ancients called a clever fighter is one who not only wins, but excels in winning with ease.
• He who knows when he can fight and when he cannot will be victorious. (A very important fact about life)
• In the practical art of war, the best thing of all is to take the enemy’s country whole and intact; to shatter and destroy it is not so good. So, too, it is better to recapture an army entire than to destroy it, to capture a regiment, a detachment or a company entire than to destroy them.

Chapter Four:

• Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win. (Do you first seek to get rich then invest? )
• Management of many is the same as management of few. It is a matter of organization. (How you manage your small things is how you will manage everything in life)

Chapter Five:

• To a surrounded enemy, you must leave a way of escape. (This is to deceive them that there is a way out so they may not put their all into the war)

The Art of war is a masterpiece that il probably not see another in the nearby days to come, however i am close to finishing this copy but still in awe of the clarity of things from a perspective of the writer. While i am looking forward to writing the rest of the extracts, i am also looking to get deeper meanings of the art of war and its application in real life. Il always appreciate your claps. :)

I have a dream that anybody found to be guilty of corruption will be hanged by means of public execution, next to Tom Mboya’s statue along Moi Avenue (Nairobi, Kenya) that it may serve as a reminder of what ill corruption has brought us. I have a dream that anybody suspected of corruption should never hold any public office and i also have a dream that every individual will speak out and condemn specific acts of corruption that seem so minor yet they drive our country in the days before colonization.

Recently i have been having a conversation with myself (I do this a lot in case you are doubting my state of mind). Where and how did we get here and in all honesty, when did the rain start beating us. Was corruption a curse poured in Africa and is accountability a plague that we all run from. No, as a matter of fact we saw this coming, we raised this child, we fed her, all of us, we fattened her and made her arrogant, and now that she is matured and no longer a child we have little or no control over her.

African corruption begins from the point that we do not even know how much our members of parliament earn. By the fact that the earnings are kept private, it can be clearly said that any amounts of money given to them are theirs to ‘share’ to the members of their respective constituencies, point to note, they can ‘willingly share’ or just opt not to.

Tracking Money …..

I have a theory for all the engineers in the world those who went to school and those who never went close to it. Maybe tracking money could solve our current African corruption ailment, what if in theory every coin every note had a unique signal that it transmits in a randomly generated sequence, the signals are then open sourced and anybody can be able to view transactions happening but anonymously, lets call it public-money ledgers(not bitcoin this time). On the open platform, various individuals can be able to see and identify abnormal transactions at various locations and be able to report on these incidences.

case 1: Kenyan police officers are known for bribes especially traffic officers, assuming that by afternoon they have collected 100 notes of 50 shillings, there are 100 different uniquely identifiable signals that can be traced to the location of the money, from understanding the patterns we can be able to tell the abnormal behaviours as every signal increment is done after a particular time period hence raising eyebrows over the source of the money.

Case 2: Recently there has been a case of withdrawals of millions of shillings in local banks in an unauthorised manner from government scandals. So say Tenderprenuer A is withdrawing their ‘hard earned’ corruption money and depositing it in an account, the signals which are unique can be traced and located despite where the money is deposited from or spent at.

Among other things that tracking money can assist in is identifying drug money and laundered money. But well all that is not something which will see the light soon, maybe it is a futuristic concept that is good as it is on this medium blog and to me nothing much but a dream. Until the next one, Be the change you want to see.

‘I never Freeze’ being my recently found philosophy, i assigned myself the task then tried my luck to still see the light of day at the end of the Sprint. In this post i will be sharing how as a developer you can be able to host your react-js application in a production server using a multi-build docker file and Nginx.

Some of the things you need to understand before you start this tutorial are:

I did not have prior DevOps Knowledge.

The React application to be deployed is already created.

Nginx only serves files in Production.

The Dockerfile, docker-compose.yml and default.conf should be kept in the application root.

React applications are Single page applications and therefore all files are served from the index page and not necessarily physical pages.

Life is not as easy as you may imagine :)

To deploy the application to the production environment you need first to create a dockerfile. A dockerfile is basically the file that creates the container that will encapsulate your application and make it runnable on any unix environment.

Dockerfiles do not have any extensions and therefore creating them is as straight forward as day, The file has two build parts one where the application is copied to the working directory and all the dependencies are installed and the second process where the app generates the production build to be deployed to either the QA or production servers. Having a docker file like the above means that one already can create a container with the command

docker build -t somedockerimagename .

This will create a docker container from the existing dockerfile. To run a docker container we may require a docker compose file which is in charge of starting and stopping our created containers. The docker-compose.yml is a yaml file and therefore follows YAML configuration standards as shown below.

Once the docker-compose file is there you can simply run a command to launch your react application in the container. Walaah!! :

docker-compose up -d 

Production

One thing i might have skipped is that the production configuration is quite different for the local configuration. As a point to note React applications create virtual routes and not actual pages. Nginx however treats routes as pages and therefore it is easy to find the index.html/homepage running while all other routes are not. To solve the error in Nginx you need to override the settings in /etc/nginx/conf.d/default.conf. Adding a single line does the trick. To do this however one needs to create a default.conf file then move it to the /etc/nginx/conf.d/ directory when the docker container is created. The replacement to the default.conf file can be found here:

Incase you wondered if i was showing you how to be a DevOps Engineer, nope i was not, i was just showing you how things flow around the DevOps World. I know i have skipped quite a bit off stuff but i know you are bright enough to figure that out :).

Money began even before we knew what Agrarian Revolution to be a thing. Actually the first form of currency exchange was known to be barley. Workers in the roman empire could receive as much as 6 bags of barley for the male workers and only 3 bags of barley for the female workers (gender inequality might have began here). The foremen in the empire could receive at least 1500 bags of barley. I don’t want to imagine how you’d go to a shoemaker and carry a kilogram of barley.

The system became more complicated with time and as an empire if people paid taxes in barley i wonder where the capital would keep it. One thing about the nature of human beings is that we are always inclined not to trust and that is an inbuilt instinct both for protection and for survival. To overcome this ,the roman government came up with silver ignots that were imprinted the roman ruller Denarius at the time.

The symbol of authority was meant to ensure that all the individuals have a common trust as the coin indirectly says. ‘ I the Ruler of the roman empire have verified the true value of this coin and as i trust it so should you. Coming to the present day that is what all currency is made of. As a matter of fact creating a fake currency is a worse crime than murder in many countries. Lets now take a step back why do we carry value less coins and notes and attach value to them just because someone believes in them.

At the time of usage of silver ignots, both Muslims and Christians were not even in good terms but the Sheikhs and Christian rulers allowed money that was imprinted and which bore ‘value’ despite where it was from. In other words money formed the strongest human bonds that are known in the present day breaking down bonds of religion ethnicity and even geographical barriers. Stepping back and now re-thinking what is money you just realize it is a couple of valueless papers and metal coins that just keep order on how the world operates.

From the money discussion now comes the real argument, what is the government? The government is a structure not located anywhere and not owned by somebody and not totally existent. the government is a belief that only belongs with the people who believe in a system that they found to be in place. I am actually thinking right now that if the entire human race was wiped away from existence then the new generation would know nothing of governments and political hierarchy.

Why then do we have an inexistent system controlling the people and being in charge of all activities in a country, because it all starts from trust. Trust that a body called the government should be there and also trust that there should be a currency to keep the people and their government in check. Maybe i am however just overthinking the situation. Meanwhile i can try have a chat with Elon Musk and think of an alternative when we safely land in Mars, but for now theres nothing much that can be done, we just have to embrace our lies and live with them.

You walk into a room full of people and the people you spot having conversations do not exceed the number of five, everyone else seems so occupied with someone else on the other side of the world and if not they are busy stalking people on facebook and giving likes for things that they do not like. Is it a generational problem or i am the odd one out, someone who feels like all is not well.

Being at a generation of people who consider themselves ‘enlightened’ it is a sad reality that soon conversations are gonna die off and we will opt for an easier way out of life’s problems, in the allusion of having real conversations, the younger generations do not have time for hanging out or expressing themselves in a simple chat, they will probably never know the tension that comes when one is trying to ask a girl to become their girlfriend as ‘Whatsapp chat message got ya !’.

Phones have made most of us live in illusions as we can be able to edit, delete and hold back. The reality of life has washed away what we consider for us to become human, the rawness of conversations is that once you say something it is done and nothing in that particular instance can be taken back, good or bad it gives an opportunity to learn and we appreciate conversations simple or complicated.

I wonder not when individuals met through a social media platform, dated online through facebook, got married after the first year and then divorced in the second year. We are living in a generation where everything is ‘pap!’ and as the going goes ‘easy come easy go’ We will never get to experience and understand the reality of conversations if we never have them.

I may not be the realest relationship counsellor out there but i think we are all guilty of misusing our devices for conversations that we did not want to have or the ones that we felt were uneasy to have face to face. More guilty are we for using our phones when we needed to shrug off a conversation or escape to be quiet and be regarded as a weirdo. Now that we are all on the same page why don’t we start by YOU not using your phone on your lunch table when people are around. Thanks. :-)