Skip to Content

Category Archives: Development

A thoughtful insight into why Redis

 

It’s common for us developers or technology enthusiasts to encounter technology that we can use right out of the box without really knowing what that thing actually does. It was not long ago when I was first introduced to Redis, this magical thing that solves all sorts of problems. 

I was working on a Rails application when I first heard about Redis, but I wasn’t really trying to work with Redis per se, I was more likely trying to make Sidekiq work; a background processor for Ruby that needs Redis in order to work as I had always been expecting things to work, out of the box.

If you are not familiar with background processors on web applications, it is basically a function whose result is not imminent and can be postponed; this is because the end-user can live without immediately knowing the result, such as resizing their profile picture, or a more commonly known example, when you upload a video to Youtube and it tells you to come back later for the result.


The basics

Using the same example above, let’s think about how we can make this work in case we wanted to build our own solution for background processes. The best and most simple solution would be:

1. During a request, identify what information should be delivered ipso facto and what can be processed later.
2. Store information about what can be processed later, of course, the obvious answer here is to use our database, whose only job is to do so.
3. Run a different process than our main application (the one receiving the request); it will be monitoring the database in case something needs to be processed.
4. Process whatever needs to be processed.
5. Profit.

In case you are wondering, as I was wondering at some point: what is this process that will be checking for background processes in the database? Well, it will be most likely another instance of your main application, but configured to run without a web server listening for requests, and instead, a routine to check for new background processes to run, this way the worker (main application, without the fancy web server) will have access to all the goodies you have already written to make your life easier, models, serializers, etc. Or in the case of Rails developers, let the magic flow to our worker.


The problem

Ok, so it seems like we have the solution here, so why bother to even think about an alternative for any of the 5 easy steps to build our worker? Time will be wise and when you reach your millionth user, you will notice that your database is starting to have problems reading and writing all the information your inconsiderate users want your application to store and retrieve for them, and on top of that, the worker is always trying to access the database in hope of finding more background processes to run; after all, the database is the only source of truth for knowing the next background process to be run.

Let’s say that at some point, retrieving a row from our background processes table takes x amount of time; a rough explanation of how our database manager is accessing the data will be the following:

1. It listens for a query request through the configured port.
2. It processes the query to know what to fetch from disk (a more complete explanation of this step can be found here).
3. It asks the OS to read certain sectors on the disk.
4. It reads the sectors from disk.
5. The OS returns the data from the disk.
6. It stores the rows in memory.
7. It sends the information back to the requester.

The key steps here are 3-6. If the database manager wants to access data written in the disk, that petition needs to be made to the Operating System in order to access it. And not only that, we depend on the availability of the disk’s reading capabilities, which can vary depending on the hardware used in our server. For the sake of simplicity, let’s say these 4 steps take 4/7x of the time necessary to return the requested information. So if our request takes 1s to be completed, almost 60% of that time was used to retrieve information from disk and be stored into memory. Wouldn’t it be better if we could have that information already in memory from the beginning? Well, the time you had been waiting for is here, I present to you: Redis.


The solution

Redis is, from the front page of its site:


“an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker”.

The secret sauce here is: “in-memory”. Redis always stores the data in-memory (RAM) so the response time of any petition can be lightning-fast and can be accessed in the same fashion as a normal database, such as MySQL.

Redis also has the capability of doing a backup of what it stored in memory to disk, so in case you need to restart the machine running the Redis service, you won’t lose anything, as long as the Redis service finishes to do this backup. After the restart or in the case of a failure, when the Redis service starts again, it will populate the in-memory database with the backup made into the disk.


How it works

You won’t believe the simplicity of Redis, it is just, wait for it… a dictionary (a map if you will), so it is a concept really easy to grasp. You basically set keys with a certain value, and that value can be from a simple string to a member of an ordered set. Redis has a really impressive catalog of structures that it can manage; a complete list of these structures can be found here.

Every structure has its own set of commands, for example, to set and get a simple string from Redis, you will do something like:

 

 

Usage

Just as our first example, we can use Redis to store what our worker needs to start running background processes, in a sense:

1. Our main application writes into Redis a descriptor of the background process.
2. Our worker reads the descriptor and runs the background process.

Another interesting use of Redis is when a third-party service we are using works using authentication tokens. Basically, you make an auth request to this third-party service, and it will be returning a refresh token and an authentication token that will work for a certain amount of time, let’s say 1 hour. So, where should we store these tokens inside our app? You guessed it, Redis; so that it can be accessed later for other requests, or even be used by our worker.


Conclusion

There are limitless situations that will fall in the Redis use cases. As always, in technology, Redis is not the magic solution for everything, experience will tell you if Redis is a fit for what you are doing. And of course, you can always create your own solution using Redis, but I bet there is at least one project out there that will fit you just right, but if you are really passionate about a deep understanding of how things work, go for it, in the end, practice makes the master.

I hope you find this information useful to make an informed decision in the future, and feel free to comment here what your results were when using Redis, or if you have a cool alternative to it.

 

0 1 Continue Reading →

How to be a better developer without coding?

Entering a new company is always a challenge, a challenge that not only entails testing your technical knowledge but also how you interact with your co-workers.

Talking with friends and fellow programmers about their experiences when entering a new company, I gave myself the task of delving a little more into a specific topic “What qualities do you consider positive in a co-worker?” And considering his answers, I made my best effort to take the qualities that they mostly emphasized on as positive aspects of a co-worker. These capabilities are named “Soft Skills” according to Sophia Bernazzani.

What qualities do you look for in a co-worker?

It seems like an easy question to answer and I know that many will agree that some of the most important qualities of a developer are:

  • Creativity
  • Logic
  • Discipline
  • Knowledge

In my opinion, these qualities must be intrinsic in a developer, so the additional skills to these four are the answer to this question.

Proactivity

As developers, every day we face difficult situations or beyond our control, knowing how to anticipate these situations and having an action plan before them is the best feature of proactivity.

Pavneet Singh Saund says that “Proactive: create or control a situation instead of simply responding to it after it has happened“. Keeping this in mind, having a proactive teammate is so positive since that ensures that even if there is always a storm, there will be a person who brings calm and an efficient action plan against the problem or problems that arise and in turn will always try to be one step ahead of the problems.

Empathy

As Zachary Paruch says in his article, “Empathy is typically associated with being able to put yourself in the place of someone else”. Taking this into account, we can understand how a newbie feels, because we were all newbies once, that’s why we often feel the need to help them in the way we would have liked experienced teammates to help us.

This desire to help simply by having experienced similar situations is the exact definition of what Zachary Paruch means in his article, and it is why I propose putting it as a quality that a teammate should have for the benefit of the entire team, this, because supporting teammates help them grow as developers and makes workflow more fluid and less stressful among their members.

Curiosity

Albert Einstein said “I have no special talents. I am only passionately curious”. This curiosity led him to be a legend among physicists and was a quality with which he stood out in his field. Curiosity is a quality that we should awake as developers as it helps us to always try to ask ourselves why the code works, and not simply know that a certain method is useful for this or that, and also, if I write something, then another thing may result.

Another advantage that curiosity gives us is the fact that when we see that new technologies are born, a hunger grows in us for learning and knowing about them, as well as mastering the technologies we already knew before.

Curious teammates generally have good learning habits, and good habits are contagious.

Seeing someone with that hunger to learn, that hunger to master new technologies and that desire to grow as a programmer is not only motivating but also extremely useful because generally, this kind of teammates have something useful to comment and they are usually people who like to share what they learn, which is always beneficial in a team since all the members learn only by listening and taking as an example the curious teammate.


Teamwork

Teamwork makes the dream work” is what Liz Chatterton says in her article

Working as a team seems to be an easy task, but knowing how to deal with people with different ideologies, ages, and skills, becomes a challenge that we all have to go through. Mastering teamwork and knowing how to interact with people who are part of the team makes you a person with whom you can gain trust faster, and in a team, trust is one of the most important things since it not only makes working with you more comfortable, but it also helps your colleagues dare to comment or ask something about the job without fearing to be told something negative about it.

Remember that “A comfortable job is a dream work”.

Motivation

Doing what we like should always be our main objective. Motivation denotes passion for your work. When you like what you do, it is shown from the first moment. Having a motivated partner is something contagious, a good attitude and desire to do your job makes the whole team reach a unique tuning. If you are motivated, developing the other skills described in this article will be easy for you. Remember how James Clear defines motivation “Motivation is a powerful, yet tricky beast” but with enough effort, discipline, and above all motivation, you will improve yourself bit by bit. 


Conclusion

In conclusion, to be a better programmer, your Soft Skills will also be of the utmost importance. How you handle yourself in a team is going to say a lot of your value as a teammate. Knowledge and natural talent are not everything; how you treat your teammates and how you behave in different situations says a lot about you.

The points presented in this article are just some of the points that I could rescue from my experience and different conversations with fellow programmers. If you have any point that you want to extend or add, do not hesitate to leave it in the comments and I will see how to add it to the article.

0 0 Continue Reading →

6 reasons why you should stop using Java and use Kotlin instead

 

As an Android developer who started working with Android 4 years ago, I had to learn Java in order to create native applications. For the first two years, I learned a lot about Java and I started to feel that I was getting good at it. During this period, I heard you could use Kotlin to create Android apps but I always thought “There’s no way Google would deprecate Java, it’s their main language.”

A year passed, and first-class support for Kotlin was announced at Google I/O 2017. In 2018 Kotlin was voted as the second most loved programming language (StackOverflow).

 

Most Loved, Dreaded, and Wanted Languages

StackOverflow. (2018). Developer survey 2018. [Image]. Retrieved from https://insights.stackoverflow.com/survey/2018

 

Additionally, according to Pusher in “The state of Kotlin 2018”, after the official announcement, the Android community has been migrating from Java to Kotlin rapidly.

 

Kotlin’s growth
Pusher. (2018). The state of Kotlin 2018. [Graphic]. Retrieved from https://pusher.com/state-of-kotlin

 

A few months after Google I/O 2017, I was still using Java because I thought Google would not deprecate it, and you could still use it to make apps, so I thought Kotlin was in its “baby steps”.

Even when I kept thinking I should wait a little bit more, I did not want to lose an opportunity to learn a new programming language, so I decided to experiment a bit. I started reading articles, blog posts, and following tutorials. After a while, I started to get bored because I was only doing tutorials or easy examples of Kotlin. Following tutorials are a good start, but it only shows you the basics of a certain topic, and I really wanted to apply all the new things that I had been learning to a real project. My prayers were heard and I was assigned to a new project in which I had to start from scratch, so I took the risk to use a new language in a real project and learn on the way.

To my surprise, learning Kotlin was unexpectedly easy thanks to my Java background. If you’re asking yourself, “Should I use Kotlin instead of Java?” Well, yes, you should! But, why?

 

Here are some advantages of Kotlin over Java that to consider:

 

1. Say goodbye to NullPointerException

The NullPointerException is the most common exception for a Java developer that Kotlin wants to eliminate by using Nullable types. A nullable type is an object that can be either null or not, and it is defined by the question mark (?). 

If you try to access some property of a certain String, e.g., the length of b, the Kotlin compiler won’t allow you to compile your code because it detects a prominent NullPointerException (NPE). In order to know the length of a nullable string, you have to tell the compiler that it can access that property only if it is different from null by adding the question mark.

The main benefit of using nullable types is that they give us the chance to avoid an unexpected NPE before our app crashes in runtime.

Nullable types provide this benefit due to Kotlin, which detects a possible NPE and Android Studio won’t let us compile our code until we fix it, ensuring that our application is null-safe. However, you may keep in mind that Kotlin does not solve the NPE issue, but it forces you to prevent this exception when your app is running.

 

2. Extension functions

An extension function is a way in which you can add new functionality to an existing class without having it inherit from the class. For example, if you want to remove the last character of a String:


3. Reduce boilerplate 

Boilerplate is the repetitive code that you see in almost every place of your project. A really cool example to identify a repetitive code is a POJO class in Java.

You can create the same POJO class in Kotlin by defining a data class. 


4. Data class

The example above is using a data class; we can use a data class when the main purpose of the class only holds data. Likewise, it gives us the chance to avoid adding unnecessary code to every class we need.

 

5. Interoperability

Kotlin can work with Java in the same project without any trouble because both languages have similar bytecode structure. If you are migrating your app or you want to add a feature (built with Kotlin) in your existing Java application you can do it.

 

6. Android Studio IDE

Android studio has grown a lot, and its compatibility with Kotlin is excellent. Also, it has a feature which lets you convert Java code into Kotlin code by just doing a simple copy/paste, or with a few clicks. This is a useful advantage if you are considering migrating your Java app, but keep in mind that you have to be careful because you are going to use Android Studio to migrate your full code. I prefer to use this feature only to convert little pieces of code.

 

It’s not all a bed of roses.

Kotlin is not a perfect language. In fact, it has cons that you may be interested in knowing before choosing it as your main language to develop Android applications.


Learning curve if you are not a Java developer

I mentioned that if you are a Java developer, the learning curve is effortless but, it may be difficult if you are learning on your own without having an expert Kotlin developer helping you or without any Java experience.

Speed compilation
When we talk about speed in compilation time, Kotlin seems to be slower than Java in some cases when trying to perform clean builds.

Find a Kotlin expert
There are a lot of Kotlin developers available in the market, but if you want to find an experienced mentor that helps you improve your skills, it may be a difficult task.

A few learning resources
As I mentioned before, the Kotlin community has been growing fast, but even so, finding a good learning resource could be difficult if we compare it with Java.

If you are interested in learning Kotlin but you don’t know how to start or where to start, you can visit these links to learn more about it:

  • The official Kotlin page is the official documentation that Kotlin gives us. It is easy to read and it has a lot of good examples.
  • Android code labs are a bunch of awesome tutorials made by Google developers.
  • Android Weekly is a free newsletter that helps you to stay cutting-edge with your Android Development skills. Every week you will receive an email with several topics, tutorials, and posts about Android development.

 

Conclusion

Everything about Kotlin has been fascinating. I have encountered zero issues with this language or any implementation that I want to add to my projects. I have been able to solve every challenge I have faced by using Kotlin, without the necessity of adding any Java to my code. 

I do recommend you look for guides when starting to use Kotlin, especially if you’re not a Java developer. Getting help could fast track your learning. Receiving tips, getting feedback, or maybe being told the solution you implemented is not the best; every padawan always needs a Jedi that guides them to the light side of the force. 

If you are still using Java, my suggestion is to try Kotlin. If you have been following Google’s I/O since 2017, you have noticed all examples about new implementations and tools are using Kotlin. If you are a beginner and looking for a language to learn, choose Kotlin and do not worry; there is a lot of good information about how to start. 

 

https://pusher.com/state-of-kotlin#adoption
https://kotlinlang.org/docs/reference/android-overview.html
https://kotlinlang.org/docs/reference/data-classes.html
https://kotlinlang.org/docs/reference/extensions.html
https://insights.stackoverflow.com/survey/2018
https://www.netguru.com/blog/kotlin-java-which-one-you-should-choose-for-your-next-android-app

0 7 Continue Reading →

Test cases; an asset or a hindrance for the QA testing process?

 

This blog post aims to address a controversial topic within the QA tester community: test cases. When I first read about this topic, I was wondering whether test cases are actually an asset or a hindrance to the QA testing process. The following paragraphs are meant to help us distinguish between the advantages and disadvantages of different test cases. 

On one hand, some people say that it is essential to design a test plan and have the whole list of test cases before starting to test. These people consider test cases an asset. On the other hand, some other people say test cases are actually a hindrance to the QA testing process since the tester would then be biased, thus limiting creativity by focusing on the test cases.

First, I am going to present the information supporting the idea of test cases being an asset. 

 

Test cases are an asset

 

As we know, there are some projects which lack documentation for different reasons; given the circumstances, these teams cannot provide new teammates with the proper information to understand the product. In this case, new people on the team can use test cases as the documentation they need in order to understand the project.

Other people consider test cases important as it shows stakeholders and/or clients the parts of the system which have been tested; in other words, what testers have worked on. From this perspective, test cases are such a nice tool for the QA testers to justify their work.

Moreover, writing test cases before running any tests is also considered good practice so that future testers are able to run the necessary tests once the person who designed the tests is no longer in the project.

For other testers, creating the test cases before even getting their hands onto their new product is great to learn the product. By executing a set of tests, they will get a pretty good hands-on experience without having to use their peers’ time to give them a tour of the product.

 

Test cases are a hindrance

 

For instance, according to James Bach and Aaron Hodder in their article “Test cases are not testing: towards a culture of test performance”, testing cannot be predicted for two reasons, on the one hand, there is always more testing to do than what we can afford to do, and on the other hand, we don’t know where the bugs are until we find one. Creating test cases before testing may bias the tester.

Similar to what happens with recipes, which are not cooking, we need to bear in mind that a test case is not a test, and should avoid using an artifact as the basis for human performance; also keep in mind that with tacit knowledge and skill, the artifacts are not central, and they might not be necessary whatsoever. So the test case may have a role, but the tester is indeed the center of testing.

Taking the example of the recipe into account, the performance of the tester should have substantial freedom to make her own choices from one moment to another. Having said this, if a tester has a test case, it is hard to make decisions at the moment of testing because the tester is then biased by the test cases being followed.

Test cases do not cover as many scenarios as a tester would like, for several reasons. A test case, most of the time, can cover the happy path and the most common paths for a feature, but they lack focus on elaborate scenarios, tricky paths a normal user might follow. Having test cases biases the tester. Testers are then tricked into focusing on the scripts, rather than focusing on learning about the product, or finding bugs. They may execute the test cases to the letter, and they can perfectly carry out this activity without finding any defects, which is the main objective of a tester, not to have bugs on the product.

 

Conclusion

Based on my experience regarding test cases and whether they are convenient or inconvenient for the QA testing process, I do have my own take. In the end, I believe it all comes down to being open to the needs of the product, meaning there will be some times when test cases will be quite useful, but some other times, it’ll be better not to stick to a document. After all, testing is more about how testers perform, rather than the test cases per se.

For instance, if regression testing will take place, the best approach might be to use scripts so the tests are carried out straight forward. If the testing is not about checking the main functionalities in a product, the following scripts might not be the best approach since the tester should be free of biases, the product should be explored in great detail. Important to take into account the fact of keeping documentation once testing is done, even though there are no test cases, the tester should keep notes of the results, for further situations.

 

References

 

0 0 Continue Reading →

How to conquer legacy code and not die trying

As a software engineer, I know how frustrating it can be to work with legacy code, especially when your client has no idea of the level of technical debt you are inheriting, and wants you to deliver bug fixes and new features as soon as possible. If you’re as passionate about software development as I am, you’re supposed to enjoy it, not hate it. That’s why I’m writing this blog post: To share my experience and a key piece of advice about how to deal with it.

The most common issues of working with legacy code are:

  • Having no tests at all, or no useful tests.
  • Outdated dependencies.
  • Poor software architecture.
  • Technical debt.
  • Lack of documentation.

Here are some recommendations about how to deal with it and not to die in the attempt.

Risk Assessment

After performing this assessment, you’ll be aware of all the risks you’re taking (or inheriting). In the end, you’ll have to decide how comfortable you are with the given risks. Therefore it’s super important to know the current state of the project and to be aware of what to expect when it’s time to get your hands on the code.

The goal of this assessment is to learn as much as possible of the current codebase. My recommendation is to focus on the following:

  • Documentation: Unfortunately, most of the time the only documentation that you might find in an existing project is the README file, and even worse, this file is usually not up to date. Look for architecture diagrams, wikis, or any other documentation that can help you to understand the codebase at a glance.
  • Test coverage: Speaking of documentation, tests are considered the best code documentation. You should check for the current test coverage, but more importantly, check the quality of the tests. Sometimes tests check against specific text instead of testing the business logic that drives that text to be displayed. If there are good quality tests, you should be able to have a better sense of the business logic, and moreover, the current architecture.
  • Dependencies: Having a ton of dependencies is not a good sign. I always try to avoid adding a new dependency unless it’s strictly necessary, or the benefits of said dependency exceed the cost of making it happen. Check how outdated dependencies are and how difficult it would be to do upgrades. Pay extra attention when it comes to deprecated versions and you need to do major upgrades.
  • Deployment process: A new feature, bug fix, or improvement is not considered done until it reaches the production environment. You need to understand what the deployment process is since you have to take this into account while giving estimations.
  • Backlog: After getting a little bit familiar with the codebase, you need to know what’s about to come. You might be asked to add a particular feature that might not be that easy to add given the current architecture or the version of the dependencies implemented. The value of knowing the backlog beforehand is to raise any warning flags in the early stages so that you can plan.After going through each of the above points, you should be able to communicate any risks to your client. Set clear expectations and decide whether to move forward or not based on your discoveries.

Buy insurance

If the test coverage isn’t the best, you should ask to work on adding tests before adding new features. You need to be confident enough that you’re not adding new bugs while changing the codebase, and the only way to be sure is to have a proper test suite. Good test coverage is your insurance as a developer.

Refactor on the go

I know that you might be tempted to do a major refactor as soon as you start touching the codebase; however, based on my experience, that is not always the best option. A big refactor can take forever; it’s like a chain reaction. You start with a few files or lines of code, which then scales so quickly that you’re suddenly in a situation where you’ve already refactored hundreds of files with no end in sight.

A better option is to do small refactors on the go. Refactor the code you’re touching based on the features you’re working on.

The approach that I like to follow in this case is one of the SOLID principles, Open-Closed principle, which suggests that a class should be open for extension and closed for modifications. If you can’t extend an existing class or file, then create a new one following this principle, and use it only when it’s required. Avoid changing existing implementations since it can scale quickly, and you might get lost in the refactoring instead of focusing on delivering the feature.

Conclusion

Dealing with legacy code shouldn’t be that painful. It depends on your approach to working with it.

Here are the things that you should do before starting the feature development:

  • Read the existing codebase.
  • Analyze the current backlog.
  • Add tests until the point you feel confident enough.
  • Set clear expectations to your client.


Once you’ve already started the development process, these are the things you should bear in mind:

  • Avoid major refactors; instead, do refactor on the go.
  • Add tests to any single feature or bug-fix you work on.

Let me know your thoughts in the comments section. If you have any other suggestions about how to deal with legacy code, feel free to share it with us.

 

0 5 Continue Reading →

Design thinking for Developers (Workshop, part 2 of 2)

The following video is the core content of the second part of a Desing Thinking workshop imparted by our friend Michael Gharabiklou, Founder/Managing Partner at Quor Studio. You can watch part one here.

 

0 0 Continue Reading →

Design thinking for Developers (Workshop, part 1 of 2)

On his visit to TangoSource’s México’s Headquarters, our friend Michael Gharabiklou, Founder/Managing Partner at Quor Studio, shared his knowledge about Design Thinking with us.

The following video is the core content of a 3-hour workshop and the first part of a 2-video series. It Includes the Design Thinking process and the importance of empathy in this methodology, among other topics.

 

 

0 0 Continue Reading →

React Context may be here to save us all from prop drilling.

What is prop drilling?

Prop drilling is when a prop is passed to a Component only for the sole purpose of passing it down to a child.”

In React, it is pretty common to find yourself writing a lot of boilerplate code for passing a value to a component, only to pass that component down again to a child, and this can be repeated as many times with many children as needed, until the data you are passing down reaches the component where you need it.

Not only this will cause a considerable amount of extra code written, but it will also affect the architectural design of your component, which will now require to have a property that the component itself will not even use, the prop is there just to be passed down the chain until it reaches the final component that will, in fact, use it for something. This issue is even more noticeable in apps written using a global state approach, where all the app state is saved in a global object.

In the previous image, the arrows represent the way the data needs to flow down to reach the components where it is needed; the lower in the three the component that needs the data is, the more drilling needs to be done to reach it.

React Context has always existed within React, it was previously shipped with an experimental context API and it was created with the sole purpose of getting rid of prop drilling, react itself has used it internally for a long time, but it was only until March 2018 that a completely revamp version of the context API that we can now use was released. This new version will not only help us to avoid prop drilling, but it’s now possible to use that context approach to manage our application state. Hey! We can even replace redux and only use vanilla react without any extra library to manage our centralized state architecture.

In the following image, we can see how with React Context, we just make the values available from everywhere in the chain instead of passing them down in the form of properties to other components, we do so by wrapping the components in a context that can be accessed from any position in the tree.

You can now see how there is only one arrow and that we no longer need to be passing down values over and over again to reach our farthest components.

Now with some code examples

Using Prop Drilling to pass down data example:

1) We mount our main element Toggle.

2) Inside Toggle, we can see how the Switch component saves the state and passes it down by using props, on property for printing the button state and OnToggle function for changing the actual state.

You can visit a working demo here: https://codesandbox.io/s/prop-drilling-mpzen

 

Now an Example using React Context:

1) First, we need to create a React Context (React.createContext) with some default values for our state, “on” will be started as false and let’s make onToggle an empty function for now. This created react context, which will give us access to a context provider and a context consumer:

  • ToggleContext.Provider: This will make the context available for every child.
  • ToggleContext.Consumer: When inside a Provider, it will allow us to read the context.

2) Lets make <ToggleContext.Provider> component a bit more intelligent by adding our state and our custom function (toggle) to toggle the switch value between on and off.

In order to do this, we need to initialize our Provider with the “on” and toggle values via its value property and then make sure we pass down all the children inside.

3) This will give us our custom ToggleContexProvider that we can now use to wrap the entire application in, and since Toggle lives inside a Context Provider we can use a Context.Consumer from any child to read the state provided by ToggleContexProvider

4) This is the rest of the code, notice how we use ToggleContext.Consumer for accessing whatever objects we used in values={} for our Custom Provider, also notice how we can use it directly inside the component where we need it, instead of passing it down every time, avoiding prop drilling.

Usage:

Implementation:

In the example above, we used a React Context to wrap the entire state of our small application, but you can use several different contexts for each of your app’s concerns and abstract your logic in different files.

You can visit a working demo here: https://codesandbox.io/s/53pq01x144

 

Conclusion:

Sometimes having a centralized-managed state is very similar to having a globally declared variable, this is often avoided because it leads to having a very confusing data model for your application, answering the question “can I modify this without breaking the app?”, which is sometimes very difficult to answer.

Prop drilling helps with this without any doubt, but we need to keep its downsides in mind. Use prop drilling only when you want to be very specific about how the data flows and you want to make clear dependencies between components, but use react context for normally managing the state in the rest of your application.

If you want to learn more on how to use context, here is a great place to start: https://reactjs.org/docs/context.html

 

References:

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

Code examples inspired by:
https://kentcdodds.com/blog/prop-drilling

0 2 Continue Reading →

Rails basic API authentication with Sorcery and JWT

APIs have become more and more popular due to increasing demand for development of mobile and single page apps, and so the need of sessionless server-side applications, being those that are token-based the most popular ones now days due to their relative easy implementation. Here you have a great example that uses JWT to secure a microservice-based application.

JWT (or jot) stands for JSON Web Token and as it states it is a web token structured in a JSON format. JWTs are composed of 3 parts: the header, the payload, and the signature. In short, the header contains the type of token and the algorithm for the cryptographic signing; the payload (or claim) contains the information wanted to securely send to the server, and the signature which contains the secret key known only by the server and that is used to decrypt the data contained in the payload. It is not the primary objective of this post to explain in detail what JWT is, so if you want to know more about it you can do it here.

JWTs are used in the next way:

  1. The API server generates the JWT.
  2. The JWT is sent to the client.
  3. The client saves the JWT (i.e. in LocalStorage).
  4. The client sends the JWT back –we’ll send it on a request’s header– to the server.
  5. The server uses the JWT’s payload data for X or Y purpose. In our case to identify the user that is performing the request.

 

Besides JWT, we need an authentication strategy to actually identify users. We’ll use Sorcery for this purpose; I recommend you to go ahead and read the documentation if you haven’t done so. You can implement any other authentication library –or build your own– but for this particular case I personally like Sorcery because it offers all basic authentication features and it is not as overkilling as other libraries.

This is how the general authentication flow looks like:

jwt-diagram

Fig. 1 JWT Flow

Conveniently there is a jwt library that we can use to generate user’s token, so go ahead, read its documentation and install it in your project.

Next, we’ll create a service to provide the JWT, another one to validate it, and a last one to authenticate the user.

app/services/jwt/token_provider.rb

app/services/jwt/token_decriptor.rb

app/services/jwt/user_authenticator.rb

NOTE: In this case we are assuming that JWT is in ‘Authorization’ header with format ‘Bearer xxxx.yyyy.zzzz’, that’s why we are splitting @request_headers['Authorization'].

Implementing our services

We need to generate the JWT after user has successfully logged in:

Or signed up:

The token returned in the response should be properly saved in the client so it is sent back to the server in subsequent requests’ headers.

Then we need to authenticate user on future requests. Adding an authentication method on ApplicationController will let us use it on ApplicationController’s children controllers to protect our private endpoints:

And that’s it, our API is now secured using a sessionless approach. From this point on you can add more complexity using jwt and Sorcery‘s methods to, for instance, make token expire after 1 hour or reset user’s password.

Let me know in the comments section below what you think about this strategy.

0 9 Continue Reading →

Dev jobs: A microservices architecture journey

Recently at Tangosource I was assigned to work on an internal project named Dev Jobs (see dev jobs on iOS and dev jobs on Android), where I had the chance to work next to great teammates and implement a microservice architecture with Ruby on Rails, nodeJS, JWT, Ionic, Docker, and several testing tools, including RSpec, Mocha, Frisby, and Protractor. In this first post, I’ll explain the basics of the microservice architecture.

What is a Microservice Architecture ?

Martin Fowler gives a great definition.

[1]“The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”

The Problem

Let’s have some context. We are building a server side application that must support different client side platforms such as:

  • Desktop browsers
  • Mobile browsers
  • Native mobile applications

 

Also, we need to consume an external API service. In our case, Linkedin through Oauth2 for authentication. And the ability for users to chat between each other.

On an architectural matter we still had to decide between monolithic or microservice. So let’s dig a little more on this two.

Monolithic vs MicroServices

Monolithic

If we take this approach, we need to keep the following in mind:

  • Build one application to rule them all.
  • Use one language ( Ruby, PHP, JavaScript, etc. ) we could not take any extra advantages from other programming languages.
  • The architecture needs to be flexible enough to support API through AJAX and render HTML.
  • The development team needs to feel comfortable with the language we picked.
  • Security. We will have a public API to serve mobiles/clients.
  • Best tools for RTCP. So we can have a nice looking chat
  • Testing. build testable code

 

I have seen great monolithic architectures that can support all of this. One of my favorites is RoR engines based or nodeJS services based applications.

MicroServices

In the other hand, if we go for MicroServices we must take in mind the following:

  • Delegate responsibilities in small applications.
  • We can use different languages per service. Which is the best choice per responsibility?
  • How are we going to communicate each service ? Normally with tcp/ssl.
  • How are we going to persist Data through services?
  • Security: Protect the services.
  • Testing: Test all microservices.

 

On a personal note, as a developer working on a microservice platform, I can focus only on the technical details wrapping a specific service. This does not mean I should not understand the whole set of services as a unit.

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

— Melvyn Conway, 1967

Having this in mind, we had to start by making technical decisions, such as how to protect our API, how to manage RTCP, by nature HTTP is stateless which means is sessionless so for our case we had to maintain a session through tokens ( JWT ), at first we though maybe nodeJS for RTCP since nodeJS is strong for DIRT ( Data Intensive Real Time )  apps. But we had not only had to take care of the tech devs but also for dev resources, currently at TangoSource we have strong Ruby on Rails devs so we had to work all together and take advantage of the expertise of each team member, our best bet was to use RoR for business logic, and take advantage of nodeJS. So the combination of RoR and nodeJS makes the solution solid and strong.

Solution

For this particular project, we decided to go for the MicroService and have some fun! The first thing that we needed to figure out was defining the responsibilities per service. So we end up with 4 microservices.

  • Ionic
    • More than a service, it’s the client side of the application. Ionic by itself is a front end SDK for hybrid mobile apps using AngularJS.
  • IDP
    • Responsible for (a) providing identifiers for users looking to interact with a system, (b) asserting to such a system that such an identifier presented by a user is known to the provider (c) possibly providing other information about the user that is known to the provider.
    • This may be achieved via an authentication module, which verifies a security token, and that can be accepted as an alternative to repeatedly and explicitly authenticating a user within a security area.
  • SP
    • In charge of persisting all user’s data, including interaction with the system. This service will contain all the business logic
  • Chat
    • In charge of establishing real-time communication among users within the system.

 

We decided to protect the services with JWT

Architecture

devjobsarchitecture

Each square represents a service, and the lines are how they communicate between each other.

Ionic : This might be the most critical service of them all, but not the most important. We have 3 main components:

  • Ionic server
    • An HTTP server in charge of sending all the assets ( HTML, CSS, JS ) to the next component.
  • Ionic Cordova
    • A Mobile SDK, which provides the user’s interaction with the app, and consumes the rest of the microservices as resources. This component runs on top of 3 different type of devices.
      • Android
      • Ios
      • Browser
  • Ionic App
    • Ionic admin panel, this panel allow us to configure GCM and APNS exposing a protected API.

 

IDP : This service is in charge of giving identity to a component/user. This service will expire a valid token with a component/user’s basic information on the JWT’s payload. Similar to memoization, this service will keep track of sessions using Redis on a basic TLS connection. Thanks to the RFC 7519 standard, this service can scale in other microservice based architectures and be reused.

SP : This is an API/Https service protected with JWT. This micro service is in charge of persisting all user’s interaction/information using MySQL with a standard TLS connection. It also manages the business logic.  

Chat : This microservice will provide real-time communication between users. This RTCP (real time control protocol) is being protected with JWT on the handshake process, and persists the communication activity on MongoDB, a NoSQL database.

Conclusion

Taking these kind of decisions is not simple. It requires a lot of experience in order to compare libraries/languages, you must at least know how they work, and it’s even better if you have used them. Remember that you will not build this by yourself, you are part of a team. It’s smart to sit with your team and discuss each individual’s strengths and weaknesses in order to make the best tech decisions.

DO NOT mix responsibilities of the micro services, instead identify your services. Add all the needed documentation to help the team such as /*Comments */,  READMEs, and Wikis.
A microservice architecture is not always the best approach, and could be painful if you are not careful.

4 9 Continue Reading →