Forem: Runtime Revolution

Connecting React Native to localhost

Andre Nunes — Tue, 28 Apr 2020 08:44:21 +0000

This is something that happens to me on every React Native project.

How can I make a request to my local API (that runs on localhost)?

To be able to do a request to your local machine you have to do two things.

First, you must use your machine IP as the base URL for the request.

To discover your IP, just type this command on your console and look for the inet that looks like 192.168.1.200.

ifconfig | grep inet

---

**inet** 192.168.1.200 netmask ...

After that you will need to update your Android and iOS configurations.

Android

One of the problems may be related to CLEARTEXT HTTP, which protects apps from accidental usage of cleartext traffic.

Starting with Android 9 (API level 28), cleartext support is disabled by default.

* from Android Developers

Which means that Android can only make a request to HTTPS sources. So we need to allow our application to use HTTP sources.

In the AndroidManifest.xml file, we need to add these lines:

<manifest ...>
  <uses-permission android:name="android.permission.INTERNET" />

  <application
    android:name=".MainApplication"
    android:usesCleartextTraffic="true"  
    android:networkSecurityConfig="@xml/network\_security\_config"...>

    <activity android:name=".MainActivity" ...>
      ...
    </activity>
  </application>
</manifest>

This will allow our application to connect to EVERY HTTP source. But we want to allow only your machine’s IP. So to do that we will need to create the network_security_config.xml file in the folder main/res/xml.

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
  <domain-config cleartextTrafficPermitted="true">
    <domain includeSubdomains="false"> localhost </domain>
    <domain includeSubdomains="false"> 10.0.2.2 </domain>
    <domain includeSubdomains="false"> 192.168.1.200 </domain>
    <base-config cleartextTrafficPermitted="true"/>
  </domain-config>
</network-security-config>

This file restricts the HTTP domains that our app can communicate with. The IP 10.0.2.2 is an alias for the emulator to 127.0.0.1, and 192.168.1.200 is our machine’s IP.

After that we need to set the domain url on the Android emulator. So open Dev Settings by clicking CMD + M and then click on Debug server host & port for device. On this modal we add our machine’s IP 192.168.1.200.

iOS

On the iOS side we will have the same issue, we need to allow our app to do requests to *HTTP * sources.

By default, iOS will block any request that’s not encrypted using SSL. If you need to fetch from a cleartext URL (one that begins with http) you will first need to add an App Transport Security exception. If you know ahead of time what domains you will need access to, it is more secure to add exceptions only for those domains; if the domains are not known until runtime you can disable ATS completely. Note however that from January 2017, Apple's App Store review will require reasonable justification for disabling ATS. See Apple's documentation for more information.

* from React Native

To do that we will need to update our Info.plist file and add the NSAppTransportSecurity key.

<key>NSAppTransportSecurity</key>
<dict>
<key>NSExceptionDomains</key>
  <dict>
  <key>localhost</key>
  <dict>
    <key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key>
    <true/>
  </dict>
  </dict>
</dict>

On iOS we don’t need to define our machine’s IP because it translates localhost to that.

After that all we need to do is re-install our app on the emulator and it’s done, with this you can now make requests to your local API.

Note: This should only be used on local development environment, don’t commit this to your production app.

Recommended links

I’m a software developer from Portugal, currently working at Runtime Revolution as a front-end and mobile developer.

Runtime Revolution
anunes9 - Overview

Golang DNS Resolving

Luís Costa — Thu, 23 Apr 2020 10:04:33 +0000

Lately, I have been writing Golang (more commonly known as just Go, which is what I’ll be using from here on out) at work, and so far I have been enjoying it a lot! This is a small TIL (Today I Learned) about making Go correctly communicate with services in the local machine like, for instance, Redis, Postgres, or Kafka.

In my particular situation, the project I am working on is running on my machine, however, some of the needed services (Redis, Kafka) are running inside a Docker container. For instance, Redis is accessible via the hostname redis, and likewise for Kafka. Initially, I thought that simply adding the following entries to my etc/hosts files would be enough for the name resolution to work properly:

127.0.0.1 redis kafka

However, the code was still throwing errors because it could not connect to redis or Kafka. Turns out that Go has two ways to perform address name resolution, depending on the operating system it is running on. On OS X (which is my case), Golang uses a different name resolution library called cgo, which is a bit different than the default name resolver. You can see which name resolver your Go program is using by setting the flag GODEBUG with the value netdns=2. Here’s a sample output for my program:

GODEBUG=netdns=1 go run main.go
> go package net: hostLookupOrder(redis) = cgo
...

On OSX, applications are not allowed to make direct DNS requests. So, let’s try running the program with the pure Go name resolver:

GODEBUG=netdns=go+2 go run main.go
> go package net: GODEBUG setting forcing use of Go’s resolver go 
> package net: hostLookupOrder(redis) = files,dns

(The + sign is used to tell Go to force a specific name resolver and to show debugging information).

And it works! Since the pure Go name resolver is used, Go accesses local files in the machine to perform name resolutions such as /etc/resolv.conf and /etc/hosts

Nowadays I work at Runtime Revolution as a full-stack software developer. Working here has been, and continues to be, a great learning experience. I’ve matured professionally as a developer, as well as a human being.

Remotees At Work

B Jacquet — Tue, 14 Apr 2020 07:31:00 +0000

Re·mo·tees (rĭ-mōt-ēs): A person hired to work for another from outside the office, usually from home.❊

For the past month Runtime Revolution has been working full remote, for reasons the whole world is aware of. Going remote is such a game changer at Runtime, and to me personally, that I immediately wanted to blog about it. This time ‘round I twisted things a bit and asked some of our readers (fellow co-workers) to share their experiences on (forced) remote work.

All you need for remote work. Photo by Ana Gonçalves.

In this post I’m joined by Ana Gonçalves, João Ribeiro, and Maria Luís Duro. Ana is a Team Leader and has been with Runtime Revolution for four years. During that time she has contributed to ten different projects! João is another Team Leader and he has been with Runtime for two years. Maria is our IT Recruiter. She’s hiring! 😉

Are you working alone at home? Are you enjoying it?

Ana: “Me and my partner are both working from home right now, we work in separate rooms because we have meetings quite often. We need separate spaces so we don’t speak over each other. Sometimes we notify each other if there’s going to be a meeting so that the other doesn’t make too much noise. Other than that we basically work as if we were alone and try not to interact much during the day, apart from lunch and snack times. It can be nice to work without the usual hustle of the office and with my cat’s occasional company, but human interaction is also missed. Overall, working from home has its pros and cons. For now I’m enjoying it but I’m afraid I might get over it soon.”

João: “I’m not alone, since my girlfriend is also remote during this time.

We made some ground rules before starting this period and one of them is to work in separate rooms in the house, since we have this possibility.

These two “offices” were also set up in rooms that we don’t use for our off-work time, which means we can disconnect and still be in the living-room / kitchen / bedroom without the work office feeling. I can say that this new experience is definitely different from the normal routine, it’s better in some aspects but at the same time, worse in others. I think I’ve been able to focus more easily than in a busy day at the office, since I don’t get interrupted as often.”

Maria: “I’m currently “in quarantine” alongside my parents. The three of us are working but in separate spaces since we all have jobs that require calls or video chats. For now it’s all going well and we try to respect each other’s schedules. We eat lunch together to maintain interaction, have coffee breaks, and try to keep a fairly normal life. Since this is a particular situation in which we all need to stay at home I don’t feel my personal life is any more involved in my day-to-day than it was before. Because we’re not used to spending all hours of the day with each other sometimes we get a bit annoyed but it’s a feeling that goes away fairly quickly.”

Now that you don’t commute, what do you use that time for?

João’s less is more setup.

Ana: “I usually spend about 2 hours a day to commute and I actually used to read during that time but now I don’t read as much. Now I try to be mindful with my time so I don’t fall into the trap of working more than usual. I use the extra time to bake (I like making my own sourdough bread and the extra time is very much appreciated), tidying up, or use the extra hour in the evening to do some yoga.”

João: “In the morning I get up at the same time as I did before, I just get ready a lot more slowly and the rush part of my day is not here anymore. I use that time to catch up on the news (“real” television news), calmly eat my breakfast, and sometimes still read a bit as I used to do on the train.”

Maria: “Usually in the morning I go for a run outside and come home to continue some workout exercises I would otherwise do at the gym. I save the end of my day to play video games (I am revisiting some oldies like Pokemon and Kirby!)”

How did you, and your team, adapt to the long distance?

Ana: “We as a team work from an office but we work remotely with the product team. We have standups twice a week with them, so that interaction hasn’t really changed that much. We added a daily standup internally so we see and talk to each other regularly and PRs [Pull Requests — Ed.] are usually published in a Slack channel, as we did before. We also created a Zoom link that we called “Virtual Kitchen” so anyone from the team can join after lunch and during breaks to talk to each other about whatever they want, as we would do if we were in the office.”

João: “In my project we’re divided into different teams, inside the project, so in my team we started doing two daily check-ins, one in the morning and one near the end of the day. I feel this keeps the team connected even though there might not be that many updates in each one, but we get to see each other and also talk a little bit. Apart from that nothing much changed, if you need help with something you talk to who you think might help you and schedule a call, or simply write a message in your channel and get some responses to it. For all the people in the project we also started doing some “Watercooler Calls”, twice a day you can get together with others and just talk about “nothing”, which is great to keep the mental sanity!”

Maria: “We adapted pretty well. We talk everyday and maintain our weekly meetings. Personally I feel the response time isn’t so immediate but at the same time it doesn’t have a particularly adverse effect in our work. I believe that now more so than before, all my questions are answered. Because of this change, working from home has made us more aware that we need to maintain all channels of communication open and do business as usual.”

Maria’s minimalist office, in the dinning room.

Name one thing that is absolutely indispensable to have at your desk for remote work

Ana: “Tea and headphones are very much indispensable to me, having wireless headphones is even cooler because I can walk around the house and still hear whatever is being said in the “Virtual Kitchen”.”

João: “Water, ANC Headphones and hand cream to keep my hands from drying!”

Maria: “ My desk is pretty basic, since I’m working in the living room (where we eat haha). I only have a notebook, a pen, and a bottle of water to keep me hydrated :)”

Ana’s Virtual Kitchen.

I echo the sentiments expressed above by my co-workers. I’m also at home with someone who’s doing remote work and we also work in separate rooms. I wonder why do we seek a quiet place to work, when at the office we would be working in an open space with multiple distractions? Why do we seek the shift from busy open space to quiet alone room?

As for the added “bonus” time, I use it differently. Oddly enough I find my concentration levels varying throughout the day and I tend to compensate by spending my commute time on working hours. But that is not the norm and so far I was able to catch up seasons one and two of Westworld’s TV Series.

Runtime Revolution’s culture and values are spread throughout its teams and their projects. But that doesn’t restrict them in adopting different routines for remote work. During this time I’ve worked with teams relying mostly on group text messaging and occasional voice calls (through Slack), and other teams opting for an always on group voice call with occasional text (through Discord). Though apparently similar solutions, I find voice to be less disruptive than text. As soon as I know the discussion doesn’t concern me, I find it easier to ignore human voice. That doesn’t happen with notification beeps and flashing icons luring me to text waiting to be read.

I want to thank Ana Gonçalves, João Ribeiro, and Maria Luís Duro for taking part on this post and sharing their insights. The Q&A interviews were conducted safely on Slack and no COVID-19 virus was spread through them.

❊ Remotees is word I made up. The title is a pun on Peter Seibel’s wonderful book Coders At Work. Read it!

I work at Runtime Revolution as Full Stack Rails developer. We help startups kickoff their business and reach the next level.

How to start with React Native

Andre Nunes — Tue, 17 Mar 2020 11:15:04 +0000

In this article, I’ll tell you what you need to bootstrap a React Native app.

Photo by Monica Sauro on Unsplash

So what is React Native?

React Native combines the best parts of native development with React, a best-in-class JavaScript library for building user interfaces. (…)

* from React Native

React Native allows you to create Android and iOS applications with the same code base, that behave nearly the same using all the resources of React with a little tweak.

Setting Up Your Development Environment

The installation process that is described on the React Native site is well documented and easy to follow, but here is the short version. I use a MacBook Pro as my development machine so the commands will be for macOS.

Installation process

Install Xcode and Android Studio
Install node and watchman

Install Java SDK

Install Xcode command line tools

Open Xcode, then choose the Preferences… menu.

Go to Locations panel and install the tools by selecting the most recent version in the Command Line Tools dropdown.

Install CocoaPods

Install react-native-debugger

And you are ready to go.

Now what you need to do is bootstrap your application.

React Native has a built-in command line interface, which you can use to generate a new project. You can access it without installing anything globally using npx, which ships with Node.js. (…)

* from React Native

After you create your app you can choose to run the app on iOS or Android.

To open the app on iOS just run this command, it will open the iOS simulator and install the app.

To open the app on Android you will need to create a virtual device on Android Studio, open the virtual device and run the following command.

And there you go, the app is running!

Debugging

To use react-native-debugger you need to enable remote JS debugging on the simulator option:

On iOS press CMD + D and click on Debug JS Remotely.
On Android press CMD + P .

A nice feature of React Native is Hot Reloading, which allows you to see the code changes in real time without having to restart the app.

To enable this option, open the simulator options and click on Enable Hot Reloading.

At this point you have your React Native environment set and ready to start coding some apps.

Starting with AWS DynamoDB using Python

João Gomes — Tue, 10 Mar 2020 10:08:07 +0000

Amazon DynamoDB is a key-value and document database that delivers single-digit millisecond performance at any scale. https://aws.amazon.com/dynamodb/

This guide is meant to provide a base, or a quick start, for interfacing with AWS DynamoDB using Python, its contents are based on the repo https://github.com/5thempire/aws-dynamodb.

The chosen examples are meant to illustrate the breadth of options available, even though they’re not the typical use case.

We are going to create two tables: one for storing URLs and their corresponding domain, and another for storing logs, which have a timestamp, a log status and a message. The URLs data model will be using a key-value configuration, while the logs data model will use a document configuration.

First things first, let’s define the data models.

Key-Value — URL data model

The key-value configuration is a very simple implementation, where the only requirement is to specify the key or index. In DynamoDB this is set under the attribute definition and the key schema.

The attribute definition stores the name of the keys and their corresponding type.

The key schema defines the type of primary keys we’re using, in DynamoDB they can be one of two types, hash or range. We could have one of each, but for the current example we’ll only be using hash, leaving out range for you to play with.

Document — Log data model

The document configuration is a bit more complex. To query the log documents we’ll use two indexes, one will be the timestamp and the other the status of the log, the latter of which is set as a global secondary index.

The global secondary index also includes a projection attribute. This configuration is very important, since it defines what will be retrieved when we query using the secondary index. In our definition we’re retrieving the complete document.

Python DynamoDB base class

This approach has one base class to interact with DynamoDB, which is not meant to be used on its own, but to provide a solid base for the table specific definitions. These specificities are set by overriding the abstract methods for get, put, update and remove.

Python URL class

This class overrides the base class by defining what’s specific to the domain data model interaction.

Python Log class

This class overrides the base class by defining what’s specific to the log data model interaction, but also adds filtering methods. There are two filters defined:

filter_by_timestamp_status : which uses both timestamp and status keys to filter results
filter_by_status : which filters by a specific status (i.e.: INFO)

Wrapping up

Don’t forget there are a few options out there that provide the typical level of abstraction a database model normally requires. However, sometimes a more hands on approach is preferred.

For those who want to experience a running example visit https://github.com/5thempire/aws-dynamodb. There you’ll find the samples mentioned here along with the corresponding set of tests, that can be used as a basis for further experiments.

References

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html

https://amazon-dynamodb-labs.com/

At Runtime Revolution we take our craft seriously and always go the extra mile to deliver a reliable, maintainable, and testable product. Do you have a project to move forward or a product you’d like to launch? We would love to help you!

Tech Recruiters are crybabies! 😭😭😭

Fausto Nunes — Wed, 26 Feb 2020 15:59:22 +0000

Yap. I said it. Let the flame war begin! 🔥

If you’re on LinkedIn and you’re, in some way or another, in the Tech industry, I’m sure you have a few (or a lot!) of recruiters on your network.

Recruiters are a strange group of people that search for Developers and other professionals to fill up a vacancy (or more) in a specific company that needs a person with that set of skills. Some recruiters forget they’re dealing with actual people. You know, fellow human beings with families, friends, desires, fears, expectations and demands. Sometimes it’s hard not to think of recruiters as cartoon villains, reducing everyone to a number in a body shop, especially if they’re working for shady outsourcing companies with an evil mastermind as CEO.

You’ve probably seen recruiters whining on Linked In about how a candidate did this and that or stopped replying at some stage of the recruitment process. There are rude people everywhere, but seriously, can you blame them? I dare to say, most of the time they had good reasons to be rude or they simply reflected the way they were treated in the first place.

Here’s a list of things most recruiters do that make no sense and reinforce the stereotype:

Sending the same old template to everyone, no matter the seniority, project, tech stack, etc.;
Not knowing or not giving details about the project or company they’re hiring for;
Assuming everyone in Tech must love Star Wars — Darth Vader/Stormtrooper image “Apply now!”, “Join the dark side”, Yoda image “Join the force!”. You know what I’m talking about… ughhh 😒;
Having 5 recruiters from the same company hitting you up with the same message in the same week;
Ghosting after you had an interview with them;
Not providing feedback;
Saying they have THE perfect opportunity for you, when they don’t even know you;
Calling you during your working hours, knowing it might get you into trouble;
Saying someone referred you, when you know it’s bullshit;
Creating fake job ads just to put you on their database for future opportunities.

Just to be perfectly clear, I am a recruiter and I’ve had some of these things happen to me when I was job hunting and it sucked!

I try to use what I learned from that process to be better at this job. Do you remember that old saying: “treat others the way you want to be treated”? The same applies here.

Some companies do put recruiters through a lot of pressure, unreasonable deadlines and objectives, outdated tools and give them no space to think about what they’re doing and no room for improvement (Numbers, numbers, numbers!). Believe me, I’ve been through it and whining about candidates on LinkedIn isn’t going to make things better.

If that’s your case, I suggest you find a better company to work for, because if they don’t treat you right, it’s way harder to do the right thing. Besides, you’ll be on the other end of the recruitment process again. It’s a great time to learn how candidates think and feel when you are the candidate.

We’re not reinventing the wheel here:

It all comes down to respect and treating people fairly.

I follow a strict no bullshit approach to HR and I’m glad Runtime-Revolution supports it. If you are interested in who we are and what we do, make sure to reach out! I’ll make sure you get a clear picture of our way of doing things.

4 quick tips to improve your communication skills

Nuno Tomás — Tue, 10 Dec 2019 15:31:19 +0000

Photo by Galen Crout on Unsplash

One of the essential skills that you’ll need is how to communicate all the things related to your work. I am constantly baffled by the lack of education/preparation that college provides for one of the most critical assets you can have, regardless of your chosen career path. Be it Sales, Software Development, Customer Support, you name it, strong communication skills help amplify your strengths. In this article, I’ll be mostly approaching things based on a Software Development area perspective, since it’s what I’m familiar with, but the same lessons can be applied to any other area.

1. Start by listening

You cannot answer if you don’t know the question. Or rather, you can, but the odds of getting it right are minuscule at best. I’ve said it before, and I’ll say it again, when programming something, you have to start by understanding the problem, not the solution. When it comes to communication, you have to do the same thing. Open your eyes and ears and listen. Know how people communicate, learn what the problem is, and understand what they are expecting. With that info, adapt your communication in a way that best suits the people and context involved.

2. Adapt the message to the listener

People talk to others as if they possess the same information, in terms of context and knowledge, as they do, I’ve seen it happen many times. This inevitably ends with either having to constantly repeat the same thing, or a half-hearted acknowledgment where the listener acquiesces to something they didn’t fully understand. In all likelihood, they will even need to pass the message along, resulting in a process strikingly similar to playing the broken telephone game in a foreign language.

You’ll need to get a sense of how the listener is involved, how much they know and what their perspective on the matter is. You then explain the context and the impact of the solution with simple and understandable terms. It’s possible that your message still won’t get through the first time, if so, try to arrange new ways/metaphors (possibly something more closely incorporating their knowledge and experience).

3. The right amount of words

It is difficult to understand what the right amount of words is. You always want to express your ideas perfectly, and that means you don’t want to talk too much nor too little. When you talk too much, you might throw people off if they’re not able to follow your line of reasoning, or they might plain get tired and nod off. When you talk too little, people might not grasp the full picture and fill the blanks with the wrong info. Yes, the Goldilocks principle is ever-present in communication.

It’s never easy, but you should strive to be concise and straightforward with your message. One thing that helps me a lot is to write it down, get some fresh air, and then try to see with fresh eyes, as if I were a client seeing it for the first time.

4. Feedback cycle

Picture the following: A problem comes up at 4 pm when the client notifies you. By 5 pm, everything is back up and operational. The way you communicate can dramatically change how a situation is perceived. Check out the following examples illustrating two distinct approaches to handle this same scenario. Notice that the time taken to deploy the fix is the same in both instances, and it takes exactly 1 hour to have everything working again. If you put yourself in the client’s shoes, how would you react to Example 1 vs. Example 2?

Example 1

Example 2

It’s all about how you manage expectations. The client has a big problem in their hands, and the best way to work through it is by helping them follow along with your process. In the second example, I assure you that the person on the other end will be much more at ease. By knowing where we’re at and having a better view of what’s going on, should they need to report it to someone else, the level of the aggravation felt will be greatly diminished.

Conclusion

Communication is hard because one size doesn’t fit all. Even if you know the listener, the context in which you’re delivering your message can influence the way you communicate. There’s no easy process, but there are simple principles to follow. And if you follow them and adapt, you will make your day to day a lot easier.

If you have any comments or feedback on this subject, I’d love to hear from you!

Saving data inside the browser’s storage — a summary

João Chitas — Mon, 19 Aug 2019 20:11:02 +0000

Saving data inside the browser’s storage — a summary

Photo by Samuel Zeller on Unsplash

Every time you visit a website you may have noticed that on repeated visits there are some elements that no longer appear or load faster. It could be cache working its magic or maybe there is something inside your browser that triggers these behaviors.

A very simple example: modals asking for your consent about the use of cookies. After the EU approved the GDPR regulation, many websites started showing a modal warning the user that, to improve their experience navigating the page, they use cookies. Accepting the use of these needs to be stored somewhere so that when you visit the site for a second time, it would behave in a different way (in this case, the consent modal would no longer appear). This could be stored inside a server database but that would be complex. Instead, the browser has its own storage and cookies are just one storage type. Your choice is then stored inside your browser in the cookies store.

With this post, I’ll try to explain to you, in a very brief way, the different types of browser storage that you can use while providing some code snippets to illustrate their usage. In the end, I’ll list references to posts with more details about this topic!

Cookies

Good old cookie. This is probably the most famous browser storage. Everyone who surfs the internet has heard about it. From this link:

Each cookie is effectively a small lookup table containing pairs of (key, data) values — for example (firstname, John) (lastname, Smith). Once the cookie has been read by the code on the server or client computer, the data can be retrieved and used to customise the web page appropriately.

It is easy to create or get a cookie. The document element contains an API to manipulate them. Here are some code examples:

// get all cookies
cookies = document.cookie;

// add a cookie
// must be a string with the format "key=value"
document.cookie = "pokemon=bulbasaur";

Local Storage

Local Storage is a type of web storage that stores data as a key/value pair structure and without expiration date. Even if the user ends their session, the data inside local storage will not disappear. The value stored can only be a string and if the user wants to store an object, they will need to stringify it when storing and JSON parse it when retrieving the value.

// get the storage
pokedex = window.localStorage;

// insert into store
pokedex.setItem('1', 'Bulbasaur');
pokedex.setItem('25', 'Pikachu');

// get from store
let pikachu = pokedex.getItem('25');
console.log(pikachu); // _Pikachu_

// remove from store
pokedex.removeItem('1');
let bulbasaur = pokedex.getItem('1');
console.log(bulbasaur); // _null_

// clear the store _aka_ reset pokedex
pokedex.clear();

Session Storage

Session storage is very similar to Local Storage. The main difference is that after the page session ends, the data inside the Session Storage is cleared. Both Local Storage and Session Storage have the same API. Just type pokedex = window.sessionStorage to access it.

IndexedDB

IndexedDB is a more complex type of storage, useful for storing larger amounts of data and complex objects. The API is much more complicated to use, compared to the ones provided by Cookies and Local/Session Storages. Because of that, there are libraries that make it easier to use. Like the other types of storage, you can store and retrieve elements using a key. For that, you’ll need to specify the database schema, open a connection and manipulate the data with transactions.

Here is a snippet of a very simple flow for using the browser IndexedDB:

// init IndexedDB
let request= window.indexedDB.open('POKEDEX', 1);

// to create an new object store, you must define
// a function to onupgradeneeded
request.onupgradeneeded = function(event) {
  let db = request.result;
  let store = db.createObjectStore('POKEMONS', { keyPath: 'pk'});
};

// store on DB
request= window.indexedDB.open('POKEDEX', 1);
request.onsuccess = function(event) {
  let db = request.result;
  let transaction = db.transaction('POKEMONS', 'readwrite');

  let store = transaction.objectStore('POKEMONS');

  store. **put** ({
   pk: 'pikachu',
   value: {
     number: 25,
     name: 'Pikachu',
     moves: {
       "move\_1": "Volt Tackle",
       "move\_2": "Tail Whip"
     }
   }
  });

  transaction.oncomplete = function() {
    db.close();
  }
}

// get object from the store
request= window.indexedDB.open('POKEDEX', 1);
request.onsuccess = function(event) {
  let db = request.result;
  let transaction = db.transaction('POKEMONS', 'read');
  let store = transaction.objectStore('POKEMONS');

  let pokemon = store.get('pikachu');
  pokemon.onsuccess = function(event) {
    console.log(pokemon.result.value);
  }
}

Because this is a complex process, even for small examples like the one above, there are libraries, like dexie.js, that help you use IndexedDB.

Conclusion

As you can see, browsers provide a variety of tools to store data for very specific cases. There is also another one called Web SQL but this one has been deprecated for a quite few years.

This is just a very small summary of those tools so please, take a look at some references below for more information.

References

Pokémon © 2002–2019 Pokémon. © 1995–2019 Nintendo/Creatures Inc./GAME FREAK inc. TM, ® and Pokémon character names are trademarks of Nintendo.

No copyright or trademark infringement is intended in using Pokémon content on this post.

I’m currently a Ruby-on-Rails developer at Runtime Revolution that still likes to play the good old Pokemon games for the GameBoy. Go check our website to know us more.

Organize your translations using multiple locales files

João Chitas — Mon, 06 May 2019 14:56:53 +0000

Of course, this contains an example with Pokémon!

Photo by Kyle Glenn on Unsplash

Internationalization of a website's content is always something to have in mind. Although many countries have a second language, not everyone knows how to speak or write it. In my country, Portugal, only the latest couple of generations understand English, at least in a way that they can use it on a daily basis. Some older generations didn’t even know how to read and write in Portuguese; illiteracy in our country was a major concern.

Because of these type of things, a website (in my opinion) should have at least 2 languages a user can select from, or enough languages to reach as many users as it can.

Hard-coded text in an application is somewhat of a bad practice, but in a Rails application we can find inside the configs/locales a file with the name en.yml. This file is a place where we can set strings that may appear in different places, instead of hard coding them. But, they don’t need to be only in English. You can create other translations files for different languages for instance: fr.yml and es.yml (French and Spanish, respectively).

To change which locale you are using, you can set I18n.locale with the language code, or even set the default language with I18n.default_locale.

I18n.locale = :pt

I18n.deafaul\_locale = :es

Okay but, now imagine this case: you are a Pokémon fan like me and you would like to make a website with all the information about them (names, types, moves…). Yes, you could save everything in a database, but that’s not the point, I don’t want you to be that smart.

Start by adding info about the first 151 inside en.yml… It is already a lot of information, so you’ll have a very big file. OK, now create a locales file for Portuguese, pt.yml. Now you have all the info for a Portuguese native to read.

I said to start with the first 151… Now add the ones from the second generation and you get info about 251 Pokémon. Oh, but in generation two, the generation one Pokémon can learn new moves, so you’ll have to update that info going through the whole file.

This is a big edge case but I think you already know where I want to go with this… In the future, changing a locale file could be hard to manage if you don’t structure it right from the beginning.

If only we could organize them a little bitbetter.

Well, you can! Rails lets you organize your translations in a way that’s much more suitable to your project. You can create multiple locales files for the same language and spread them into different folders, in a structure that makes sense to you or the project scope. This example was taken from the Ruby on Rails Guides:

|-defaults
|---es.rb
|---en.rb
|-models
|---book
|-----es.rb
|-----en.rb
|-views
|---defaults
|-----es.rb
|-----en.rb
|---books
|-----es.rb
|-----en.rb
|---users
|-----es.rb
|-----en.rb
|---navigation
|-----es.rb
|-----en.rb

(The file's extension is in ruby but you can use _yml _inside.)

To use a structure like this, you need to let Rails know where to look for the files:

# config/application.rb

config.i18n.load\_path += Dir[Rails.root.join(_'config'_, _'locales'_, _'\*\*'_, _'\*.{rb,yml}'_)]

Going back to our example, we can now think of a possible structure to organize our Pokémon’s information. Here’s an example:

|-pokemons
|--models
|---en.yml
|---pt.yml
|--views
|---en.yml
|---pt.yml
|-moves
|--models
|---en.yml
|---pt.yml
|--...

Or you can do something like this:

|-models
|--pokemons
|---en.yml
|---pt.yml
|--moves
|---en.yml
|---pt.yml
|--...
|-views
|--homepage
|---en.yml
|---pt.yml
|--...

And then, each file will be something like this:

# config/locales/models/en.yml

en:
 models:
  pokemon:
   name: Name
   type: Type
   moves: Moves
...

# config/locales/models/pt.yml

pt:
 models:
  pokemon:
   name: Nome
   type: Tipo
   moves: Ataques
...

# config/locales/views/homepage/pt.yml

pt:
 views:
  homepage:
   title: Pokémon e Companhia
   main\_section: Vou apanhá-los todos!
...

Always scope the translations by the name of the folder, to avoid overrides.

With a structure like this, it is now easier for you or any developer on your project to add, change or remove a translation for a specific language. This is great if you need to refactor some code and delete some legacy references in the project. Trust me, refactoring a big and unique translations file is not a pleasant task at all.

Pokémon © 2002–2018 Pokémon. © 1995–2018 Nintendo/Creatures Inc./GAME FREAK inc. TM, ® and Pokémon character names are trademarks of Nintendo.

No copyright or trademark infringement is intended in using Pokémon content on this post.

I’m currently a Ruby-on-Rails developer at Runtime Revolution that still likes to play the good old Pokemon games for the GameBoy. Go check our website to know us more. Oh, and we’re hiring!

To merge or to rebase: that is the question

Diogo Leitão — Tue, 16 Apr 2019 15:17:50 +0000

Photo by Pablo García Saldaña on Unsplash

It’s one of the eternal questions that ignite all dev discussions, on par with:

Tabs vs Spaces
Statically typed vs Dynamically typed
Han Solo vs Greedo
Jacob vs Edward

To make things simpler, I’m going to use an analogy. Let’s step away from code and programming for a while.

Integrating a paper research team

You recently integrated a group of people who are working on a big article or thesis. As you can imagine, you won’t do all the work and neither will the rest of your team. The work will be divided into fairly equal parts, so that each member of the team can focus on their branch of work.
A given member of your team is the lead researcher. This means that their decisions and comments carry more weight; in case of a draw, they are the ones who have the final say. Therefore, we can say that your lead researcher’s work is the source of your truth.
You have been assigned a new chapter on the research. You Google some existing papers on the subject (based on the main research document), find some images, plot some graphs, draw some conclusions, etc. A few days later, the lead researcher says some other colleague finished their part of the work and that piece has been merged into the main document (which, as I mentioned earlier, is your source of truth).

Photo by Jon Tyson on Unsplash

How should you continue your work from now on? How will you incorporate the newest additions into the research you’ve done so far? What if it clashes with what you currently have? Since the main document is your source of truth, you know it was approved by your peers and by the lead researcher, so you have to do you work starting from there!

Adding new information / Getting updates

How you think it will happen:

Zipper gif @ https://giphy.com/gifs/cgi-FS2GiqcNGT292

How it will most likely happen (with fewer deaths and injuries, hopefully):

Git Merge GIF @ https://tenor.com/view/git-merge-gif-5920259

Before the YOU’RE A REBASE PURIST accusations start pouring in, let me say that git merge has its advantages (of course it does!), the same way that git rebasehas its disadvantages. People who’ve been through it know that solving merge conflicts is easier and a lot less cumbersome when you use git merge.

However, what I want to focus is not which one is better, but rather which should be used in which situations.

Going back to the research paper analogy, once you get the updated version of the main document, rebasing your work on it will produce a more coherent work. If you were to merge everything together, you’d probably end up with clashing definitions and mixed up pages (if you started your work on page 20, and the latest document has 23 pages, your work does not belong on page 20 — the same way your commits will be spliced in-between the main branch’s commits).

Furthermore, when checking the log, we will see changes on both sides (main branch and our branch). If we place our changes on top of the most recent commit, there’ll be a straight line detailing in which order everything was done, and so we end up with a more coherent and clearer log history (and we don’t have to read through all the Merge branch develop into dl/feat-123/example commit messages as well).

Merging your research back into the main document

Now that you have your work sorted out and cleaned up, it’s time for the final review before merging it into the main document. By doing this, the moment your work was added to the main research will stand out, because everyone will know when what you did was introduced.

Back to code

I think that most of what I explained before was self-explanatory. Either way, here’s a quick recap, with code:

You’re added to a repo
Someone assigns you a feature (let’s assume the main branch is develop)
Someone updates develop, so you should rebase your branch
Once you’re finished, open a pull request, get your code reviewed, and merge it into develop

Summing everything up

If in the future you have any doubts about whether you should merge or rebase, remember the following:

Always rebase from parent branch: this way your work will always be on top of the most up-to-date version of the work (and you avoid having multiple merge commits, keeping you branch history cleaner and clearer)
Always merge into parent branch: when you merge your branch, you will know when that was done, since there will be a merge commit stating it!

Whether it’s frontend, backend, mobile or DevOps, at Runtime Revolution we have a spot for you!

Grids, why I love them, and why you should not run away from them

André Bártolo — Wed, 10 Apr 2019 14:34:21 +0000

Grids, why I love them and why you should not run away from them

I am a designer, a UX/UI designer to be precise, and I love grids. But wait, which designer doesn’t? Okay, I know designers are not all the same and perhaps not all designers love grids, but we have to admit that in general designers do love their grids and there’s a reason for that. Grids are cool and very useful, this post is all about grids, why I love them, and why developers should have a better understanding of them.

Grids are used to design all kinds of things: logos, books, furniture, posters, flyers, websites, apps, webapps, icons, and so on. Whenever possible, I start with a grid, no matter what kind of project it is. It can be just what you need to break free from that fear of a blank sheet in front of you, and to start realizing all the potential stored in that [brand new] canvas.

Grids bring order; they help you decide sizes, proportions, and the placement of elements. Grids bring clarity and consistency; they help you collaborate and speed up production. A grid always works with, rather than against, the designer and the developer.

Grids are gradually shifting from mere helpers to an important part of the whole work process. If you are a developer you might think “Okay cool, this guy loves grids and the framework I love has a grid system, problem solved!” but what if I ask you to work with a grid that was specially designed for that project? You would have to develop that grid, and make it responsive and understand how it works across all platforms and have more work. Why? Because development frameworks take a “one size fits all” approach when it comes to grids and sometimes it’s okay to work with but that approach generally doesn’t work. For one reason or another I am never fully satisfied with the grids that most development frameworks provide, because they demand compromises I am not willing to make.

Grids are not static! These days, dynamic is a word we use a lot, and with good reason; things change all the time! Design needs to be fluid, to use more relative values, not absolute ones. Design needs to adapt to content, not dictate it. Design needs to accommodate, not disarrange.

In my process I take two things into consideration when preparing a digital grid. First one is screen sizes aren’t standard , and the second one is different projects have different needs. These starting points warn us that things need to adapt, breakpoints are not always going to be the same, the number of columns may vary, their size, the gutter between each column, if the grid has margins or not, all may vary.

Now, why do developers need to better understand grids? Because if you take part in this process there is as much in it for you as there is for a designer. You will gain independence, and will not need to constantly ask for changes. You will be faster in your work. Your code will be cleaner and tidier, in order to accommodate what the grid asks, and you will collaborate more, leaving time to what’s important. All this because you understood the grid, the structure, and how things move and evolve.

If you reached this far in this post, I will assume you are interested in grids (Who isn’t!?). So let me introduce you to some types of grids:

1. Responsive grid

The responsive grid is a grid scheme designed that uses around 12 columns and is complemented with gutters and margins. As the screen becomes smaller, the responsive grid adapts by losing columns in order to fit the screen, so for example in a 3 breakpoint scheme it would be: desktop 12 columns, tablet 8 columns and mobile 4 columns.

Responsive grids are great at adding order and balance and a great resource for less complex project.

2. Fluid grid

Fluid grids are similar to the regular responsive grid but these scale with browser size. There are several ways to do this, and one of my favorites is nested grids where smaller grids are nested into bigger ones, also fluid grids usually use relative values instead of absolute.

Fluid grids usually produce better mechanics for responsiveness since they are more agile and they prove to be a better option for more complex projects or heavy content projects.

3. 8-point grid

This system should be used in conjunction with another system (a fluid system for example), because the primary goal of this 8-point system is to create a consistent ratio of measurement (all sizes, paddings and spacings should be divisible by 8).

8-point grid systems are a great tool for teams because they create an easy system of communication between designers and developers (no fussing over pixels). A developer can easily eyeball an 8pt increment instead of having to measure each time.

There are plenty more grids to explore but these three are a good start, they can lead to some huge improvements in your work and help you in complex projects. Understand that when someone puts time and effort into a grid, it is usually not just because that person loves grids, but more so that they have studied the problem and have developed something that could help everyone. It’s not only about the user, it’s also about you.

I am UX/UI designer at Runtime Revolution who is quirky and loves a good laugh that has wonderful brain to memorize idiot things and forget important ones. I love all kinds of design and I’m all about making questions and finding solutions.

Building a Slack App using Ruby and Sinatra

Nuno Namorado — Mon, 11 Mar 2019 14:43:08 +0000

Photo by Morre Christophe on Unsplash

My team at Runtime Revolution uses an in-house app for team management and other day-to-day chores. Recently, I was asked to integrate Slack’s Slash Commands into it.

Being new to Ruby I accepted the challenge with added motivation and drive. This was a good side project to improve my Ruby skills.

From the start, I wanted to create a small standalone app that could be easily integrated with our existing Rails application. There are a couple of web frameworks out there. Some offer Rails-like features, Hanami and Padrino, just to name a few. However, none offered the small footprint and modularity that Sinatra implies. So I went with Sinatra.

Providing a simple yet powerful DSL, Sinatra enables the creation of web applications with ease. Using community created modules we are able to quickly build a fully-fledged API server with authentication, logging, etc. or a small HTTP module for other Ruby applications or services.

In this article, I will:

give a brief overview of Slash Commands and Actions, as well as the concept behind interactive messages;
guide you through the creation and configuration of a Slack application;
build a “Surf forecasting” Sinatra application for receiving and sending Slack messages;
show how to deploy an app using Heroku service or embed it in a Rails application.

1. Slash Commands and Actions

Slack apps can do more than just sending simple text messages. Using the Slash Commands and Interactive Components (buttons, menus, date pickers, popups, etc.), apps are able to effectively create more engaging experiences.

The diagram below provides a basic outline of the typical flow using interactive messages. Note that the interactions can be triggered by a variety of sources found within the API provided by Slack.

Slack interactions overview. Taken from Slack docs.

In the context of this article, the origin will be a user action triggered by a command_._ The app will then send an enriched message containing buttons, which allow the user to select one of several outcomes presented.

Slack API documentation can be somewhat confusing when referring to actions because almost everything is an action. However, when it comes to configuring a Slack app, as we will see further along, there is a clear separation between Slash Commands and Interactive Components.

What are Slash commands?

Slash commands, as the name states, are commands that the user can execute by writing with a leading / followed by the name of the command. A known example of this is the /remind.

Slack apps can register new Slash Commands, which will instruct Slack to send an HTTP POST request to the receiving server. The app server will act accordingly.

Note: The string /<name> is what identifies the command and all words that follow will be the command parameters.

What are Actions?

Actions are events triggered when the user selects a menu action or clicks any interactive element on a message (buttons, selects, date pickers, etc.). Slack apps can register up to 5 actions in the Interactive Components page or have unlimited actions if they use interactive elements on messages.

Every action is identified by its respective callback_id, and every time the user triggers one a different HTTP POST will be sent to the receiving server.

2. Creating and configuring a Slack Application

There are a couple of things to consider when creating a Slack application for sending and receiving interactive messages. We will have to set specific auth permissions, activate the Interactive Components feature, and configure Slash Commands.

2.1. Create the app

Navigate to https://api.slack.com/apps and press the “Create New App” button. Add a name and assign it to a workspace of your choice.

2.2. Configuring Slash Commands

Having created the app, go to Slash Commands page and press “Create New Command”. Fill the form. Set the Request URL with a dummy URL, we’ll come back to this page later.

Command form

2.3. Activating Interactive Components

Go to the Interactive Components page and switch “on” the feature. Again, set the Request URL with a dummy URL. This will be updated later, with the actual endpoint. Hit “Save changes” on the bottom.

Interactive components configuration

2.4. Set permissions

Going to OAuth & Permissions page_,_ in the Scopes section, search for “Add slash commands and add actions to messages (and view related content)” and save.

App permissions

2.5. Installing

After following the previous steps, we are ready to install the app in the selected workspace. Go to the Install App page and trigger the installation.

3. Building the app

We are going to build an application that will give us the current surf forecast for a given place in the world. We will use Windguru’s website to compile the necessary information. For added fun, let’s also include the location map of the spot, so it’s easier to interpret the information given by the variables. We will use Mapbox’s static maps API for that.

Note :

During the creation of this article and while coding the example app, I identified some common behaviours for proccessing and sending Slack messages. So, I decided to create a simple Sinatra module and provide it as a gem (sinatra-slack). All examples shown are using this gem.

3.1. Interactions

The app will have two types of interactions:

the user uses the command /surf today carcavelos for example, to retrieve the forecast information. If the provided variable, spot_name, is enough to pinpoint the desired surf spot, the forecast is returned to the user.
If during the first interaction, the search result is ambiguous, the app will send in return a message with multiple buttons one per each surf spot result, up to a limit of 5. This will allow the user to continue the flow.

Interaction 1

Interaction 2

3.2. Requirements

Ruby environment correctly configured;
code from repo — Slash Command Article;
a working Slack App with a configured /surf command and Interactive Components activated.
ngrok tool to tunnel all Slack requests to your local dev environment.
Mapbox account.

3.3. Local development

Slack needs to send requests to valid HTTP endpoints, so we will have to set up some HTTP forwarding using ngrok.

Download the tool from their website, create a free account. When logged in, start the forwarding requests by running,

./ngrok http 3000

this will start the server and you are now able to receive requests on your dev machine.

Go back to Slack App’s configurations page, in the /surf command configuration paste the ngrok endpoint to the Request URL input and do the same for the Interactive Components section.

The final URLs should look something like this:

https://<ngrok-domain>/slack/commands
https://<ngrok-domain>/slack/actions

3.4. Starting the app

Before starting the application, set the environment variables

MAPBOX_API_TOKEN — create one in the Mapbox’s account page;
SLACK_SIGNING_SECRET — in the Basic Information page, copy the secret from the Credentials section.

either using the .env file or the command line and start the app by running,

bundle exec rackup

Note: To use .env, install dotenv gem.

3.5. Project overview

The S_urforecaster_ app consists of the following files:

app.rb — your main app file. This is where the Sinatra application will be configured;
config.ru— this is the Rack configuration file;
lib/surforecaster.rb — helper class to fetch data from Windguru’s API.

app.rb

The code below contains comments for some relevant parts. However, a couple of things to notice:

The class must inherit from Sinatra::Base ;
To use the Slack app specific DSL, register the Sinatra::Slack module;
All requests from Slack need to be verified. By setting the :slack_secret option, the module will verify each request sent to both commands_endpoint and actions_endpoint. For more information about the Slack verification process, see their docs;
The quick_reply parameter in both command and action definitions lets you set the text that the server will send back to Slack, as soon as it receives the command or action request. This is not necessary, but it’s a good practice to let the user know that their request was correctly received and is being processed.
Under the hood, the module is using Sinatra::Async to process the requests asynchronously. Slack requires that all command and action requests be answered within a 3-second interval, so we need a mechanism to process the request in the background for longer tasks. We will then have to respond with HTTP Post, to the response_url sent in the original request.
Command and Action signature definitions use the Mustermann string matching definitions. Looking at the command signature definition /surf *granularity :spot_name, the * allows catching the first word in a non-greedy way, leaving the rest of the words for the spot_name variable. To know more about it, go here.

config.ru

We will use the rackup command to start the Sinatra application. The config.ru file contains all the necessary options for the app to run. Notice the topmost comment, this is where you can set all command-line options which rackupwill pick up.

lib/surforecaster.rb

This is just a basic ruby class for fetching forecast information. It contains 3 methods that will be used in different stages of the command and action flows.

3.6. Adding interactivity to messages

As described above, Slack responses can be simple text messages or more complex, with rich text, images and other actionable elements like buttons and menus.

For Surforecaster app, we will need to send both messages with images and buttons.

To send messages with interactive components, two message properties are required — callback_id and fallback. In the example below, we are using a helper method to build a slack message and pass along the callback_id value. If you look closely, we are setting the same name as the action signature defined in the app.rb, using the string interpolation to set the callback_id according to the current command granularity (that was sent by the command). This is a nice way of passing around values between Slack and the app, without having to cache it somewhere else.

To send messages with images, you just have to set the property image_url.

4. Deploying

The final step of this exercise is deploying the app we just built. As previously stated, Sinatra apps can be deployed as a standalone app or embeded in a Rails application.

4.1. Standalone mode

We will be deploying Surforecaster using Heroku and Docker.

There are a couple of things you need to do first:

create an account on Heroku or use an existing one;
download and install Heroku CLI.

Create a new app in Heroku using,

heroku create \<app-name\>

Then, we need to set your app stack to container. Run the command,

heroku stack:set container -a \<app-name\>

Set the values for the two environment variables (SLACK_SIGNING_SECRET and MAPBOX_API_TOKEN) either in the app settings page, c_onfig vars_ section or using Heroku CLI with,

heroku config:set SLACK\_SIGNING\_SECRET -a \<app-name\>

Now, let’s look at these 2 files:

heroku.yml — this is the manifest file with the definition of the Heroku app;
Dockerfile — contains the instructions for building the app image that will be deployed.

heroku.yml

build.docker.web tells Heroku to build the Dockerfile at the root of the project;
run.web command is executed when launching the container. Heroku doesn’t let us define a static port number, so we have to set it through an environment variable, $PORT.

Dockerfile

Inherits from an official Ruby image;
installs necessary dependencies missing from the image;
copies the app files to the working directory.

Integration

We will be using the Github-Heroku integration for automatic deployments, so that every time a code change is pushed, Heroku will build and deploy the application. However, you could also choose to deploy using Heroku Git or Container Registry methods.

4.2. Embedding in a Rails App

Another way of deploying this app is to embed it in an existing Rails app. You can do this in two ways:

Changing the config.ru file to something like this:

or by using Rails routes:

Last step

After the deployment is complete, copy&paste the new URL to the Slack app configuration pages and that’s it! Go to the Slack workplace and start “commanding” stuff.

Future work

By creating Slack Apps with Interactive Components and Slash Commands we can accomplish really useful integrations that can simplify any company’s processes.

Keep in mind that we’ve barely scratched the surface in terms of interactive elements, we can still experiment further with select menus, date pickers, popups, confirmation messages, etc.

During the making of this article, I created a Sinatra module accessible through the “sinatra-slack” gem. It’s still not production ready and there are a lot of interactive component helpers missing.

I work at Runtime Revolution as a Full-stack developer currently focusing on Ruby. My background is .Net and C#, with incursions into Angular and React.