![\"javascript](\"https://res.cloudinary.com/carloscuesta/image/upload/v1477416503/c0i28paxv6adsw1gynln.png\")
Debugging is an essential part of programming. As a Developer I spent some of my time fixing bugs and problems.
\nLet's cover and share some tips and tricks for debugging with the JavaScript console object. Taking a look at the methods to get an in-depth knowledge of the debug process.
console.assert()console.assert(x > y, 'Error x is not bigger than y');\nUse console.assert() to check if evaluated expression is false. You must pass a boolean assertion to the .assert() method.
There are a lot of methods to log information and values to the console.
\nconsole.trace()console.trace('message', object);\nPrints a stack trace. This is useful to see where a method call starts and his cycle.
\nconsole.table()console.table([{name: 'carloscuesta.me', language: 'html'}, {name: 'starterkit', language: 'javascript'}, {name: 'generator-starterkit', language: 'javascript'}]);\nDisplays Object and Array data into a friendly tabular format.
\n![\"console](\"https://res.cloudinary.com/carloscuesta/image/upload/v1477417126/wb1dq3zkflbhs5ovdfvy.png\")
console.log() console.error() console.warn()console.info('This is just a message');\nconsole.warn('This is a warning message');\nconsole.error('This is an error message');\nDisplays an information, warning or error message to the console.
\n![\"javascript](\"https://res.cloudinary.com/carloscuesta/image/upload/v1477417270/j3kfhcw2e0o0arqhnbkc.png\")
console.time() console.timeEnd()console.time('timerLabel');\nconsole.timeEnd('timerLabel'); // => 9.15ms\nStarts a timer with an associated label to track how long a process takes to complete.
\n![\"javascript](\"https://res.cloudinary.com/carloscuesta/image/upload/v1477417796/qjjglvjgmqnlk2uweoxm.png\")
monitor()monitor(functionName);\nUse the monitor() method to track function calls. Returns the name of the function called and the arguments.
![\"monitor](\"https://res.cloudinary.com/carloscuesta/image/upload/v1477505625/ulqwbwg8kdzftbcksqdb.png\")
monitorEvents()monitorEvents(object, ['event']);\nmonitorEvents(document.body, 'click');\nUse the monitorEvents() method to listen for events on a specified object.
![\"monitor](\"https://res.cloudinary.com/carloscuesta/image/upload/v1477505807/lmegkkoaaiyrudy8q8if.png\")
\n\n","images":{"featured":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/v1477333951/qvitf2uh1p2i6mo0ubzb.png"},"preview":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/w_500/v1477333951/qvitf2uh1p2i6mo0ubzb.png","lqpi":"https://res.cloudinary.com/carloscuesta/image/upload/t_lqpi-post-preview/v1477333951/qvitf2uh1p2i6mo0ubzb.png"}},"slug":"debugging-with-the-javascript-console","title":"Debugging with JavaScript console"},{"dateModified":"2016-08-16 10:55","datePublished":{"formatInWords":"almost 4 years ago","formatDate":"16 August 2016","value":"2016-08-16 10:55"},"disqusIdentifier":"15","excerpt":"HyperTerm is an Open Source Project created by ZEIT. The goal of the project is to create a beautiful experience for command-line users.","html":"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
\n
Hyper is an Open Source Project created by ▲ ZEIT. The goal of the project is to create a beautiful and extensible experience for command-line interface users, built on open web standards.
\nHyper is built on top of Electron with JavaScript, HTML and CSS, so it's a hackable terminal!
\nAt the moment, Hyper is only available for MacOS – download here, Windows and Linux builds are coming very soon.
\nConsidering that is something built with web technologies, in my opinion it has a good performance and speed and there's no big difference for me between using iTerm vs HyperTerm.
\n![\"hyperterm-materialshell](\"https://res.cloudinary.com/carloscuesta/image/upload/v1471016296/kzmy572isneufvmbz9wt.png\")
\n\nThis is how my HyperTerm looks. I'm using the materialshell version for HyperTerm hyperterm-materialshell
\n
Developing plugins (themes and packages) it's easy, with ALT+CMD+I you can open the Web Inspector to see what's going under the hood and style your terminal with only CSS. Take a look at the configuration object to see the options and properties available for customization.
See an example of an Hyper theme and package. You should take this as a starting point when building one of those two.
\nTo install a plugin, open the configuration file with CMD+, and add the plugin name into your plugins list like this:
plugins: ['hyperterm-materialshell']\nRemember! You can contribute to HyperTerm in the GitHub Repository.
\n","images":{"featured":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/v1471010360/dxqqzy2oyppnzunnkhtx.png"},"preview":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/w_500/v1471010360/dxqqzy2oyppnzunnkhtx.png","lqpi":"https://res.cloudinary.com/carloscuesta/image/upload/t_lqpi-post-preview/v1471010360/dxqqzy2oyppnzunnkhtx.png"}},"slug":"discovering-hyperterm","title":"Hyper a Terminal built on open web standards"},{"dateModified":"2016-08-05 20:16","datePublished":{"formatInWords":"almost 4 years ago","formatDate":"05 August 2016","value":"2016-08-05 20:16"},"disqusIdentifier":"14","excerpt":"How to deploy static websites with surge, the most easy and simple way to deploy a static site, all from your terminal. Surge it's free.","html":"Surge is a static web publishing tool for the command line. It's the most simple and easy way to deploy a static site that I've ever seen!. Surge is free and includes a lot of cool features out of the box. Just with a single command you will get your site deployed.
\nTo install Surge just run:
\n$ npm i -g surge\nAfter that you will need to create a surge account providing an email and password. Once you're registered and logged in, you can deploy a static site running surge
$ surge login\n$ surge\nYou'll be asked for the path or folder you want to deploy and the domain for the project. You can add a custom domain inplace of the surge.sh subdomain.
\n![\"Carlos](\"https://res.cloudinary.com/carloscuesta/image/upload/v1470403437/lwsxsmmkcouz18xhmoju.gif\")
\n\nSuccess! Project is published and running at carloscuesta.surge.sh
\n
Use the list command to get a to see every project you’ve published on Surge. To delete a site on Surge just run teardown
$ surge list\n$ surge teardown\nIf you use Gulp or Grunt, you can integrate Surge into your workflow with the existing plugins for Gulp and Grunt.
\n","images":{"featured":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/v1470405094/gaj6zuulfkujtcwonuiv.png"},"preview":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/w_500/v1470405094/gaj6zuulfkujtcwonuiv.png","lqpi":"https://res.cloudinary.com/carloscuesta/image/upload/t_lqpi-post-preview/v1470405094/gaj6zuulfkujtcwonuiv.png"}},"slug":"how-to-deploy-static-sites-with-surge","title":"How to deploy Static Sites with Surge"},{"dateModified":"2016-07-12 15:15","datePublished":{"formatInWords":"almost 4 years ago","formatDate":"12 July 2016","value":"2016-07-12 15:15"},"disqusIdentifier":"11","excerpt":"Discover how Slack could improve your daily life boosting up your productivity and organisation mastering and hacking with the integrations and automations.","html":"I'm an active user of Slack since last year and I've been using it at work, with developer groups and friends. Two months ago I figured out how Slack could improve my daily life, boosting up my productivity and organization. Let's get started.
\nFirst, I decided to create my own Slack channel where I'm the only real person. Even though the purpose of Slack it's the communication.
\n![\"Carlos](\"https://res.cloudinary.com/carloscuesta/image/upload/v1468244718/cgytdcc5zpai3uxwmlce.png\")
\n\nThe main objective for this channel was to serve as a personal dashboard sending useful information.
\n
As soon as you have a bunch of different projects with Continuous Integration, Code Coverage, Deploys and Tasks to track and do, you can't not stare to the different websites to check the statuses of all the processes, that's not productive.
\nThis is what I use every day related to development.
\n\nThere is a lot of cool stuff you can do with the slack integrations, just search for the apps or services you're using to make slack even better.
\nAfter that I've ended up with these channels and integrations.
\n![\"Carlos](\"https://res.cloudinary.com/carloscuesta/image/upload/v1468258036/g0s1rdzorkg6rweq2zng.png\")
\nCode Climate, GitHub, Heroku, IFTTT, Statsbot, Travis CI, Trello Alerts and Coveralls
#ciContinuous Integration related notifications, Travis CI and Coveralls.io. Check build and code coverage statuses.
\n![\"Carlos](\"https://res.cloudinary.com/carloscuesta/image/upload/v1468262828/ezbh1ikocqksmglwfxs9.png\")
#deployDeploy related notifications, mainly with Heroku. Check the deploy statuses.
\n![\"Carlos](\"https://res.cloudinary.com/carloscuesta/image/upload/v1468259968/wnqjd46w2vj9vj1t6iju.png\")
#githubGitHub related notifications, commits, pull requests, issues and branches.
\n![\"Carlos](\"https://res.cloudinary.com/carloscuesta/image/upload/v1468269620/xhkbud2prvwuiydsc6cr.png\")
#trelloTrello related notifications, boards, cards, tasks, assignments.
\n![\"Carlos](\"https://res.cloudinary.com/carloscuesta/image/upload/v1468265322/tuxrrrxmezsrivnfslab.png\")
#general #socialRandom stuff, such as weather forecasts and other information. Social related notifications, twitter.
\nIn the end It's all about having the tools in one place, in my use case I'm even in the free plan, so that's not bad at all!
\n","images":{"featured":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/v1468268511/rivyclg6zmk4fuidfbwv.png"},"preview":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/w_500/v1468268511/rivyclg6zmk4fuidfbwv.png","lqpi":"https://res.cloudinary.com/carloscuesta/image/upload/t_lqpi-post-preview/v1468268511/rivyclg6zmk4fuidfbwv.png"}},"slug":"mastering-and-hacking-slack","title":"Mastering and Hacking Slack integrations"},{"dateModified":"2016-04-07 17:55","datePublished":{"formatInWords":"about 4 years ago","formatDate":"07 April 2016","value":"2016-04-07 17:55"},"disqusIdentifier":"10","excerpt":"Learn how to automate your project dependencies with greenkeeper and github. Get automatically a pull request when a dependency gets updated.","html":"I discovered greenkeeper.io at the NodeConf Barcelona 2015, when Stephan Bönnemann made a little demo of the project to show what was all about.
\nBasically what greenkeeper does is sit between npm and github, observing all of your dependencies. When they get updated, your project gets a pull request with that update. The CI tests kicks in, and Greenkeeper watches them to see whether they pass or not.
\nAt time of writing this post, I'm using greenkeeper in my opensource projects, and it's really awesome, handy and easy to use.
\nAs I said the main reason for using greenkeeper is to stay up to date with the dependencies, know the changes and fixes introduced in every release and see if they break your build.
\n$ npm i -g greenkeeper\n$ greenkeeper login\nAfter installing and login, you will have to enable greenkeeper for each repository you want to.
\n$ cd github/repo\n$ greenkeeper enable\nNow, you will receive pull requests from the greenkeeperio-bot that will look like this
\n![\"greenkeeper](\"https://res.cloudinary.com/carloscuesta/image/upload/v1460042483/exmcofmkxt427z8gkt9k.png\")
![\"greenkeeper](\"https://res.cloudinary.com/carloscuesta/image/upload/v1460043221/pa5bjbnfakjo4fgcfnbu.png\")
Greenkeeper is free for open source projects. Learn more about greenkeeper at greenkeeper.io.
\n","images":{"featured":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/v1459975401/fqblmsoopyqkjhfnoxgb.png"},"preview":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/w_500/v1459975401/fqblmsoopyqkjhfnoxgb.png","lqpi":"https://res.cloudinary.com/carloscuesta/image/upload/t_lqpi-post-preview/v1459975401/fqblmsoopyqkjhfnoxgb.png"}},"slug":"greenkeeper","title":"Automating dependencies with greenkeeper"},{"dateModified":"2016-03-23 17:00","datePublished":{"formatInWords":"over 4 years ago","formatDate":"23 March 2016","value":"2016-03-23 17:00"},"disqusIdentifier":"9","excerpt":"How to get HTTPs for free and easily in your websites with Cloudflare.","html":"To get HTTPs for your website, you need a certificate signed by a trusted certificate authority, and you will pay for that process. But with Cloudflare you can get easily and free HTTPs for your site (which currently, is what i'm using for my website and blog).
\nFirst, if you are not registered, create an account in Cloudflare it's easy and free!.
\nAfter that you will need to add your site to Cloudflare introducing your URL. Cloudflare will start to scan your website DNS, choose the free plan and point your domain Nameservers to the ones provided by Cloudflare, e.g:
\niris.ns.cloudflare.com\nbeau.ns.cloudflare.com\nOnce the process is complete, at the Overview tab you will see a green bar with your site and Status: Active. Note: This process can take up to 24 hours to complete.
![\"CloudFlare](\"https://res.cloudinary.com/carloscuesta/image/upload/v1458416188/etfwmd9m0f21mookp4tz.png\")
Now, go to the Crypto tab and at the SSL section select Flexible.
![\"Cloudflare](\"https://res.cloudinary.com/carloscuesta/image/upload/v1458416193/s8rr9mdyfekvqlcrmgvv.png\")
At this point your HTTPs will be generated and available for your site.
\nFinally, create a page rule to enforce and redirect your users to use the HTTPs version inside of the Page Rules tab. Add the pattern URL to match your site and enable the option Always use https.
![\"Cloudflare](\"https://res.cloudinary.com/carloscuesta/image/upload/v1458416201/i8ouserwpmziojnqilla.png\")
You can check my websites with HTTPs provided by Cloudflare @ carloscuesta.me – carloscuesta.me/blog
\n","images":{"featured":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/v1458417733/brc35chtj5ru0mijckn0.png"},"preview":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/w_500/v1458417733/brc35chtj5ru0mijckn0.png","lqpi":"https://res.cloudinary.com/carloscuesta/image/upload/t_lqpi-post-preview/v1458417733/brc35chtj5ru0mijckn0.png"}},"slug":"https-cloudflare","title":"Free and easy HTTPs with Cloudflare"},{"dateModified":"2016-02-06 15:55","datePublished":{"formatInWords":"over 4 years ago","formatDate":"06 February 2016","value":"2016-02-06 15:55"},"disqusIdentifier":"7","excerpt":"Carlos Cuesta terminal setup with ZSH and Oh-My-ZSH, using materialshell and my dotfiles.","html":"Terminal is a place where a developer spends a lot of time, running commands, looking for outputs and doing a bunch of stuff, so better to stay comfortable and productive with it.
\nI use ZSH as my main shell along with Oh-My-Zsh. By default, OS X comes with bash, a simpler shell. To setup ZSH and install Oh-My-Zsh run:
\n$ chsh -s /bin/zsh\n$ sh -c \"$(curl -fsSL https://raw.github.com/robbyrussell/oh-my-zsh/master/tools/install.sh)\"\nTo see what shell are you using run:
\n$ echo $SHELL\nAfter setting up ZSH and Oh-My-Zsh, now we are ready to customize and put our shell on steroids.
\nI use a theme called materialshell that I've made for my own.
\nFollow this guide to install and setup my terminal.
\n![\"Carlos](\"https://res.cloudinary.com/carloscuesta/image/upload/v1454753967/gazne7uhxuq8ugpfvile.png\")
I have my own dotfiles repository with all my shell configuration files, where you can take a look to learn and be more productive with your shell.
\n","images":{"featured":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/v1454754838/kcuq34zbo1yieygmx0y6.png"},"preview":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/w_500/v1454754838/kcuq34zbo1yieygmx0y6.png","lqpi":"https://res.cloudinary.com/carloscuesta/image/upload/t_lqpi-post-preview/v1454754838/kcuq34zbo1yieygmx0y6.png"}},"slug":"terminal-setup","title":"Terminal setup"},{"dateModified":"2016-01-28 08:15","datePublished":{"formatInWords":"over 4 years ago","formatDate":"28 January 2016","value":"2016-01-28 08:15"},"disqusIdentifier":"5","excerpt":"DevTools Author is a selection of author settings for Chrome Developer Tools that provides a small set of options to enhance your web development experience","html":"DevTools Author is a selection of author settings for Chrome Developer Tools, built by Mike King.
\nIf you use DevTools as your frontend development environment, DevTools Author provides a small set of options to enhance your development experience.
\n![\"Devtools](\"https://res.cloudinary.com/carloscuesta/image/upload/v1453933837/fn0zr6grjcxzmpifbniq.png\")
chrome://flags/#enable-devtools-experiments (Paste this url in chrome search bar and click on \"Enable\" and restart Chrome).⌘ ⌥ i / F12); Settings > Experiments > check Allow custom UI Themes.Now you will be able to choose a different UI, font and customize the look of the Google Chrome Developer Tools.
\n![\"Devtools](\"https://res.cloudinary.com/carloscuesta/image/upload/v1453933882/hah4qlyoiiks9g9szri4.png\")
If you maintain open source or personal projects, the process of updating and finding new versions for the dependencies used in them could be boring and time consuming.
\nThere are good solutions to avoid the manual process.
\n![\"npm](\"https://res.cloudinary.com/carloscuesta/image/upload/v1453840290/fuyhmakd4wt9lik6d9jp.png\")
Out of the box npm includes a command to check for outdated packages, without installing anything npm outdated
$ npm outdated\nnpm-check-updates is a command-line tool that allows you to upgrade your package.json dependencies to the latest versions, regardless of existing version constraints.
\nInstall the package and run ncu
$ npm install -g npm-check-updates\n$ ncu\nLibraries.io is a web application that monitors open source libraries it's useful when you have a project hosted on GitHub, it's free for open source projects and notifies you when there's a new release of a dependency that your project is using.
\n","images":{"featured":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/v1453840186/piym6jjmjkefij0quxmz.png"},"preview":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/w_500/v1453840186/piym6jjmjkefij0quxmz.png","lqpi":"https://res.cloudinary.com/carloscuesta/image/upload/t_lqpi-post-preview/v1453840186/piym6jjmjkefij0quxmz.png"}},"slug":"keep-npm-dependencies-up-to-date","title":"How to keep npm dependencies up to date"},{"dateModified":"2016-01-20 18:00","datePublished":{"formatInWords":"over 4 years ago","formatDate":"20 January 2016","value":"2016-01-20 18:00"},"disqusIdentifier":"2","excerpt":"Hi I'm Carlos Cuesta! I am a Front End developer based in Barcelona, Spain. Coding addicted that enjoys building things with code and I ♥ OpenSource.","html":"Hi I'm Carlos Cuesta, welcome to my new website and blog!
\nLet me introduce myself, I am a Front End developer based in Barcelona, Spain. Coding addicted that enjoys building things with code, I like design, tecnhology and I ♥ OpenSource.
\nWith the beginning of this new year, I think it's time to start a new project for me, my own website and blog, of course it's opensource, so you can take a look at the code right there at the github repository.
\nThis whole website it's built on NodeJS with Express, Jade, SASS and Ghost as a blog system and most of the data that is shown at the homepage is fetched from GitHub, Twitter and Ghost APIs, so all the info will be updated every day automatically!
\nIn my blog I'll be talking about a lot of things related to the front end development such as: JavaScript, CSS (and preprocessors), HTML (and templating systems), Web Performance, Tools, Workflows, and much more!
\nTo finish my first post, all I want to say is the first thing that a developer makes when he writes his first lines of code.
\nconsole.log('Hello World!');\nReactiveConf is a two days conference about functional and reactive programming that takes place in Bratislava 🇸🇰, at the Old Market Hall. I attended the conference with three workmates from Ulabox, @sospedra_r, @juanmaorta and @markcial. The venue was organized in two stages: the Main Stage and the Discovery Stage.
\nThe conference day started with the registration, a backpack with a cool t-shirt, socks and stickers was given to every attendee.
\n![\"ReactiveConf](\"https://res.cloudinary.com/carloscuesta/image/upload/reactiveconf-2017-carloscuesta.png\")
The Old Market was a comfortable and big place to watch the Main Stage talks. Upstairs there was a big space with TV's to follow the live-stream, a ton of bean bags and a few XBOX's to play with 🎮.
\nDiscovery Stage was located in another place called Ateliér Babylon, within a 5 minute walk from the Old Market Hall. This stage was too small, at the second day we had to turn back to the Old Market, due to the lack of space, losing the opportunity to watch the \"Understanding Webpack from inside out\" talk. 👎
\nThe food was very nice 🍗. A few serving points were distributed along the Market Hall. Also, the schedule was very well planned the number of breaks helped to follow the presentations easily!
\nIn terms of talks the quality and technical level was good. But with some speakers I thought that they were selling us their product instead of training us. Also I noticed that some talks, IMHO were offtopic according to the Reactive paradigm.
\nHaving said that, these are my favourite talks ⭐️:
\nAll talks were recorded and live streamed through the ReactiveConf youtube channel. Be sure to take a look into it! 👇
\n\nI learnt a lot of things at the venue and I really enjoyed the great atmosphere of the conference. Actually I've met a ton of friendly people!
\nHuge thanks to Ulabox 💖 for giving us the oportunity to attend ReactiveConf! 🇸🇰 ✈️
\n","images":{"featured":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/v1504460420/nmm99etv7j32h5lsulgx.png"},"preview":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/w_500/v1504460420/nmm99etv7j32h5lsulgx.png","lqpi":"https://res.cloudinary.com/carloscuesta/image/upload/t_lqpi-post-preview/v1504460420/nmm99etv7j32h5lsulgx.png"}},"slug":"reactiveconf-2017","title":"ReactiveConf 2017"},{"dateModified":"2017-10-18 10:15","datePublished":{"formatInWords":"over 2 years ago","formatDate":"18 October 2017","value":"2017-10-18 10:15"},"disqusIdentifier":"59cfbaac613ac70679db193e","excerpt":"The process of moving my website and Ghost blog from Heroku to DigitalOcean. Provisioning up the server with Node.js, Nginx, LetsEncrypt and PM2.","html":"Last weekend I've moved my website and blog to DigitalOcean. At the time of building this website 2015 I choosed Heroku as the platform to host my application, because I didn't wanted to deal with server provisioning and maintenance.
\nHeroku is probably the easiest way to ship your application into production 🚀. In my use case, the GitHub repository that hosts the code for my website, was connected to Heroku and magically I've managed to ship my application using continuous deployment through Travis CI and GitHub.
\nHowever I knew that I would be switching at some point to an IaaS considering I would need more control over the infrastructure of my application.
\nMy website is a Node.js application built with Express, Pug and SCSS. The blog runs on a self-hosted Ghost.
\nSince the start of using Heroku, I wanted to use a single Dyno to keep it simple. But every dyno is attatched to a process, so I managed to start Ghost as a module from the Express application. This workaround wasn't the best solution, but it worked more than a year and a half.
\nRecently, Ghost went out of beta and released the 1.0.0 with a ton of breaking changes. Since then it was nearly impossible with my needs to keep using Heroku.
I decided to make the move considering it an opportunity to learn and improve my infrastructure.
\n\n\nIf you don't have a DigitalOcean account, use this link to register and get $10 for free!
\n
After spinning up a 5$ droplet, the first thing I did was disabling root login and password authentication. That means only SSH can be used to connect to the server.
\n$ sudo ufw allow 'Nginx Full' && sudo ufw allow OpenSSH\n$ sudo ufw enable && sudo ufw status\n\nTo Action From\n-- ------ ----\nOpenSSH ALLOW Anywhere\nNginx Full ALLOW Anywhere\nOpenSSH (v6) ALLOW Anywhere (v6)\nNginx Full (v6) ALLOW Anywhere (v6)\nWhen I was on Heroku, I used Cloudflare to obtain SSL 🔒. But LetsEncrypt is way better. Just because you get end to end encryption.
\nTo get your SSL certificate, first, you need to install certbot.
\n$ sudo add-apt-repository ppa:certbot/certbot\n$ sudo apt-get update && sudo apt-get install python-certbot-nginx\nThen, open your Nginx configuration file find server_name directive and set your domain.
server_name example.com www.example.com;\nVerify the configuration and if you have no errors, reload it.
\n$ sudo nginx -t\n$ sudo systemctl reload nginx\nNow it's time to obtain our SSL certificates for the domain specified at the Nginx config file.
\n$ sudo certbot --nginx -d example.com -d www.example.com\n\n\n⚠️ Before obtaining the certs, you'll have to point the domain to your DigitalOcean IP. That's the way Certbot verifies that you control the domain you're requesting a certificate for.
\n
If that's successful, certbot will ask how you'd like to configure your HTTPS. Finally the certificates will be downloaded, installed, and loaded.
\nLetsEncrypt certificates are only valid for ninety days, however the Certbot cli includes an option to renew our SSL certificates and we can automate this process with a crontab.
\n$ sudo crontab -e\nAdd a new line inside the crontab file and save it. Basically you're asking to your server to run the certbot renew --quiet command every day at 04:00.
0 4 * * * /usr/bin/certbot renew --quiet\nBoth applications are started as a daemon on the server. So even though the server is restarted, automatically both apps will go up.
\ncarloscuesta.me: Uses PM2 – production process manager for Node.js.
carloscuesta.me/blog: Ghost uses ghost-cli to update and run the blog.
I use Nginx as a reverse proxy against the applications that are running on localhost.
The first block of my configuration file, redirects all the requests to https.
\nserver {\n listen 80;\n listen [::]:80;\n server_name carloscuesta.me www.carloscuesta.me;\n return 301 https://$server_name$request_uri;\n}\nAfter enforcing HTTPs, we use another server block to set our locations. Those locations will define how Nginx should handle the requests to specific resources.
As an example, if your make a request to carloscuesta.me, Nginx will match our / location and is going to proxy_pass the request to my http://localhost:PORT where the Node.js application is started.
Also, we're enabling HTTP2 and SSL for our server, providing the certificates and keys needed.
\nserver {\n listen 443 ssl http2 default_server;\n listen [::]:443 ssl http2 default_server;\n\n ssl_certificate ...;\n ssl_certificate_key ...;\n ssl_dhparam ...;\n\n server_name carloscuesta.me www.carloscuesta.me;\n\n location / {\n proxy_pass http://localhost:PORT;\n proxy_set_header Connection \"upgrade\";\n proxy_set_header Host $http_host;\n proxy_set_header Upgrade $http_upgrade;\n proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n proxy_set_header X-Forwarded-Proto $scheme;\n proxy_set_header X-NginX-Proxy true;\n proxy_set_header X-Real-IP $remote_addr;\n }\n\n location ^~ /blog {\n # Same as / with another port\n }\n}\nCodePush is a cloud service from Microsoft that gives us the ability to instantly push updates to a react-native application. Ideal for addressing bugs and introducing small features.
\nInstall the code-push command line tool and create an account. 👇
$ npm i -g code-push-cli\n$ code-push register\nIn order to associate our application with CodePush we have to register it. This process needs to be done one time per each platform.
\n# code-push app add <appName> <os> <platform>\n$ code-push app add codePushRN-ios ios react-native\n![\"CodePush](\"https://res.cloudinary.com/carloscuesta/image/upload/v1505033866/fbvjm5jbshllzoxitknw.png\")
Having said that, if you ship to iOS and Android, you'll end up with two CodePush applications codepush-iOS codepush-android, with their own deployment keys respectively. 🔑
Add react-native-code-push as a dependency to your project and then link it 📦. At the time of linking you'll be asked for the deployment key obtained from registering your application on CodePush.
Provide the Production key if you don't want a Staging environment, incase you need it setup multi-deployment.
$ yarn add react-native-code-push\n$ react-native link react-native-code-push\nNow it's time to CodePush-ify our application. Basically we have to wrap our app root component with the codePush HOC. 🔫
\nimport codePush from 'react-native-code-push'\n\nclass App extends React.Component {}\n\nApp = codePush(App)\nOnce you have integrated CodePush, the simplest way to deploy a production build, is to use the code-push release-react command: 🚀
# code-push release-react <appName> <platform> [options]\n$ code-push release-react codePushRN-ios ios -d Production\nIf you work with Staging and Production environments, first you need to ship 🚢 a staging release and then promote it to production.
$ code-push release-react codePushRN-ios ios\n$ code-push promote <appName> Staging Production\nAfter making a deployment, you can list the install metrics and metadata of the update. 📈
\n$ code-push deployment ls <appName>\n![\"codePush](\"https://res.cloudinary.com/carloscuesta/image/upload/v1505066296/yoioqwxipsdlhoriacax.png\")
By default, CodePush will check for updates on every app start, if an update is available, it will be silently downloaded and installed the next time the app is restarted ⬇️. The check frequency can be modified as well as the install policy.
\nI've created a demo application for this post, to show how CodePush works. CodePushRN is installed in Release mode into my iOS Simulator in order to emulate a real use case.
The first time we open the app, as you can see at the metrics screenshot, CodePush checks for updates and silently downloads a new one. As I said before, on the next app start the update will be installed. 💯
\n![\"react-native](\"https://res.cloudinary.com/carloscuesta/image/upload/v1505066571/vmv0aqiqu0y0l0evthd7.gif\")
\nModifications of the native code such as AppDelegate.m, MainActivity.java and others cannot be distributed via code push. Those changes require a re-build of the binary. ⚒
On iOS the bug fixes and features released with CodePush should maintain the app's original/presented purpose. ⚠️ Section 3.3.2 Apple developer agreement.
\nBuilding native applications with React (JavaScript) is awesome ❤️. Until the time you have to release a new build, specially, if you are not an iOS or Android native developer. The process of shipping manually an application to the stores is a painful and time consuming experience, even though it's documented.
That's when Fastlane comes to the rescue ⛑! In this post I'll explain how to automate the release process for an iOS 🍏 and Android 🤖 application. Handling the most common tasks such as: Code signing, App builds, Beta distribution and much more! Actually we use Fastlane at Ulabox for building our react-native apps.
\n\nFastlane is the tool to release your iOS and Android app\nIt handles all tedious tasks, like generating screenshots, dealing with code signing, and releasing your application.
\n
Before installing Fastlane make sure you have the latest Xcode command line tools installed, then install Fastlane ⬇️.
\n$ brew cask install fastlane\nOnce installed, create a fastlane/ 📁 folder inside of your react-native project at the root level. Then, create a file called Fastfile within this directory ☝️.
The Fastfile is the place where we're going to code the lanes. A lane contains a group of actions that will be executed synchronously in order to automate a process. An action, is a function that performs a task.
\nLet's get started with this Fastfile base template, as you can see there's a before_all hook, that basically performs a health check 👨⚕️, with three actions, to ensure that you're on the latest master branch with a clean status.
fastlane_version '2.53.1'\n\nbefore_all do\n ensure_git_branch\n ensure_git_status_clean\n git_pull\nend\n\nplatform :ios do\n # iOS Lanes\nend\n\nplatform :android do\n # Android Lanes\nend\nAlso we've defined the two platforms that we're going to use 🍏 and 🤖 which will contain the specific lanes for each context. Having the platforms defined allows us to execute lanes like that: fastlane ios lane fastlane android lane.
The best way to code sign it's match, before integrating match into a lane you have to:
\ninit option.ios platform that uses match.desc 'Fetch certificates and provisioning profiles'\nlane :certificates do\n match(app_identifier: 'com.app.bundle', type: 'development', readonly: true)\n match(app_identifier: 'com.app.bundle', type: 'appstore', readonly: true)\nend\nNow you can run fastlane ios certificates or use cerfiticates as a function in another lane. match will automagically save the provisioning profiles and certs on your OS X Keychain.
Automatically when you build an Android application using the assemble task in Release mode the application will be signed. But first you need to generate or fetch the signing key and add it to the project, so take a look at this facebook guide to know how to do it.
To generate a signed build we're going to create a lane that uses the cerficates lane that we've created before and gym to compile our application. At the end of the process we want to increment the build number in order to ship our application to beta testing services.
desc 'Build the iOS application.'\nprivate_lane :build do\n certificates\n increment_build_number(xcodeproj: './ios/name.xcodeproj')\n gym(scheme: 'name', project: './ios/name.xcodeproj')\nend\nTo generate a signed .apk we're going to create a build lane. As you can see we're using the gradle action, to clean the project and assemble a release build, with gradle tasks.
desc 'Build the Android application.'\nprivate_lane :build do\n gradle(task: 'clean', project_dir: 'android/')\n gradle(task: 'assemble', build_type: 'Release', project_dir: 'android/')\nend\n Then automate the versionCode bump, by hooking up the assembleRelease with this little task.
Testflight ✈️ is the way to go when it comes to iOS beta testing. Works really good, though the Developer Portal is slightly confusing. With pilot we can manage our TestFlight builds.
\nThe beta lane will use the build lane to provide a signed .ipa to Pilot, then is going to commit and push the changes produced by increasing the build number and finally will upload the local build to Testflight. 🎉
desc 'Ship to Testflight.'\n lane :beta do\n build\n pilot\n commit_version_bump(message: 'Bump build', xcodeproj: './ios/name.xcodeproj')\n push_to_git_remote\n end\nAndroid uses the Playstore to share beta builds. We can automate that with fastlane too!
The beta lane for Android is nearly the same as iOS, uses the build lane to generate the signed .apk, commits the versionCode changes and using supply promotes the local build to Playstore as a beta release. ✨
desc 'Ship to Playstore Beta.'\n lane :beta do\n build\n supply(track: 'beta', track_promote_to: 'beta')\n git_commit(path: ['./android/gradle.properties'], message: 'Bump versionCode')\n push_to_git_remote\n end\nI strongly recommend to add fastlane as npm scripts to make it part of your current build system.
\"scripts\": {\n \"ios:beta\": \"fastlane ios beta\",\n \"android:beta\": \"fastlane android beta\"\n}\nAnd that's all! Kudos to Felix Krause and all the people behind Fastlane 👏
\nIf you want to know how to automate this process into a Continuous Delivery system take a look at this post 👀
\n","images":{"featured":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/v1502890819/jnx9rvews220lun09pkp.png"},"preview":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/w_500/v1502890819/jnx9rvews220lun09pkp.png","lqpi":"https://res.cloudinary.com/carloscuesta/image/upload/t_lqpi-post-preview/v1502890819/jnx9rvews220lun09pkp.png"}},"slug":"shipping-react-native-apps-with-fastlane","title":"Shipping React Native apps with Fastlane"},{"dateModified":"2017-07-17 13:00","datePublished":{"formatInWords":"almost 3 years ago","formatDate":"17 July 2017","value":"2017-07-17 13:00"},"disqusIdentifier":"20","excerpt":"Git development workflow. Feature branches, rebase on top of master, squash and merge.","html":"Git, it's the most popular version control system and widely the most used for tech companies. In fact, as a software developer you'll be continuously using a tool like that.
\nI'll try to explain the best workflow I've found so far working on a codebase with a lot of people. There's no silver bullet for Git, but from my own experience feature branches, rebase and squash makes my workflow easier 👨💻.
\nCreate a new branch every time you start doing a new feature, bug fix, whatever.
\ngit checkout -b feature-branch\nAlways rebase a feature branch on top of master before merging it. Even though there are no conflicts, it's always good to test your features or changes with the latest master available.
You'll avoid a lot of problems by just doing:
\ngit rebase -i origin/master\nAfter that you'll need to push --force the branch, because the history has been modified and now your changes are on 🔝 of master ✨.
To maintain a healthy master log 📖 use --squash when merging a branch. All your commits will be grouped in a single one. Remember to keep your master history clean and easy to understand ☀️.
git merge --squash feature-branch\ngit commit -m 'Squash commit message'\nReact Amsterdam is a full day conference on all things React. The biggest conference I've ever been with more than 1000 developers from all across the 🌍. I went with two workmates from Ulabox @sospedra_r and @juanmaorta. The event was organized in two tracks: React & React Native.
\nThe conference day started with a React Amsterdam ⛴ that moved the attendees and speakers from Amsterdam Centraal Station to the venue location that was a beautiful place called Kromhouthal.
\nOnce registered, a bag with a cool t-shirt some stickers and a notebook was given to every person at the conference. Then the breakfast started with a big selection of coffe, fruits and baked goods. ☕️
\n![\"React](\"https://res.cloudinary.com/carloscuesta/image/upload/v1492937790/zceh4lwnpnkkbcaswfwu.png\")
The event was mainly focused at the React track, the difference between the stages was really noticeable. But didn't make any difference on the quality of the talks. Due to my needs I've moved between the two tracks. Overall the technical level was really good 🔝. I learnt something in each presentation, solved some problems and got a ton of ideas.
\nAll talks were recorded and live streamed through the React Amsterdam youtube channel. Be sure to take a look into it! A lot of interesting things going on here ☝️.
\nMy top 5 favourite talks are:
\nThe lunch and dinner catering was a bit of a mess, the food was super healthy and tasteful but there wasn't enough to feed +1000 people. Even at the closing talk a lot of people left the stage to find something to eat 🌮.
\nAs I mentioned before, I really enjoyed the conference and I'm very happy with the talks. Also, I encourage you to join the next edition if you are into the React game ⚛️.
\nHuge thanks to Ulabox ❤️ for giving us the oportunity to attend React Amsterdam! 🇳🇱 ✈️
\n","images":{"featured":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/v1492934128/jtbtd9kfsk0mstxb9c1g.png"},"preview":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/w_500/v1492934128/jtbtd9kfsk0mstxb9c1g.png","lqpi":"https://res.cloudinary.com/carloscuesta/image/upload/t_lqpi-post-preview/v1492934128/jtbtd9kfsk0mstxb9c1g.png"}},"slug":"react-amsterdam-2017","title":"React Amsterdam 2017"},{"dateModified":"2017-01-03 11:45","datePublished":{"formatInWords":"over 3 years ago","formatDate":"03 January 2017","value":"2017-01-03 11:45"},"disqusIdentifier":"18","excerpt":"As 2016 has come to an end, I would like to write a post reviewing my year and keep this as an habit. 2016 was a year full of new things...","html":"As 2016 has come to an end, I would like to write a post reviewing my year and keep this as an habit.
\n2016 was a year full of new things, at the very beginning of the year I started my blog, the place where I'm writing this post now. I've been doing a lot of Open Source and learning new things everyday. Also I have met a lot of new people, which some of them have made an impact in my daily life.
\nI've introduced a new habit of running (3-4 days per week) 🏃 to maintain a healthy life. Also this helps me to refresh and clear my mind when I'm a stressed out 🔥. Doing sports activity it's now a must for me.
\nOpen Source projects built in 2016:
\nI'm very happy with gitmoji, a project that has become popular on GitHub (was one of the first trending GitHub repositories for a few days ✌️) and people found it useful for their own projects. Now having more than +1300 ⭐️.
\nCreating a popular Open Source project to experience the contributions, issues and pull requests was one of the main goals for the year! 💪
\nEven though it's not a big list, I've been maintaining all the previous projects created in 2015. In total I've made 847 contributions in 2016.
\nThis year I've visited the city of Stockholm 🇸🇪 for Christmas and I absolutely loved it! 😍. Such a beautiful city to stay and live I would say. I will be going into Stockholm again in summer ☀️. Probably I'll be making a blog post to share some photos and thoughts.
\nFor 2017 I want to do more things that make me happy:
\nCan not wait for 2017! Let's go for it 😎
\n","images":{"featured":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/v1483439719/wwvt74vzlfr3ybg6l0py.png"},"preview":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/w_500/v1483439719/wwvt74vzlfr3ybg6l0py.png","lqpi":"https://res.cloudinary.com/carloscuesta/image/upload/t_lqpi-post-preview/v1483439719/wwvt74vzlfr3ybg6l0py.png"}},"slug":"2016-year-in-review","title":"2016 Year in Review"}],"2018":[{"dateModified":"2018-10-16 12:10","datePublished":{"formatInWords":"over 1 year ago","formatDate":"16 October 2018","value":"2018-10-16 12:10"},"disqusIdentifier":"5b6c646126d36606d1805ab3","excerpt":"Creating scalable React components using the folder pattern. A simple way to organize and structure React Components.","html":"It's been a while since I've started working with React and React-Native in production. One of the greatest things about React is the flexibility the library gives to you. Meaning that you are free to decide how do you want to implement almost every detail of your project for example the architecture and structure.
\nHowever this freedom on the long term, could lead to a complex and messy codebase, specially if you don't follow a pattern. In this post I'll explain a simple way to organize and structure React Components.
\n\n\nA Component is a JavaScript function or class that returns a piece of UI.
\n
We're going to create an EmojiList component and then we are going to refactor it breaking it up into smaller isolated pieces applying the folder pattern. Here's how our component looks like:
![\"emojilist\"](\"https://res.cloudinary.com/carloscuesta/image/upload/emojilist-compressed.png\")
As I mentioned before, we can start really simple and small, without following any pattern. This is our EmojiList component contained in a single function.
If you open the CodeSandbox sidebar you'll see that our file tree looks like this:
\n.\n├── components\n│ ├── EmojiList.js\n│ └── styles.js\n└── index.js\nThere's nothing wrong with this approach. But on larger codebases that kind of component becomes hard to maintain, because there a lot of things in it: state, ui, data... Take a look at our component code below 👇
\nEmojiList.js
import React from \"react\"\n\nimport styles from \"./styles\"\n\nclass EmojiList extends React.Component {\n state = {\n searchInput: \"\",\n emojis: []\n }\n\n render() {\n const emojis = this.state.emojis.filter(emoji =>\n emoji.code.includes(this.state.searchInput.toLowerCase())\n )\n\n return (\n <ul style={styles.list}>\n <input\n style={styles.searchInput}\n placeholder=\"Search by name\"\n type=\"text\"\n value={this.state.searchInput}\n onChange={event => this.setState({ searchInput: event.target.value })}\n />\n {emojis.map((emoji, index) => (\n <li key={index} style={styles.item}>\n <div style={styles.icon}>{emoji.emoji}</div>\n <div style={styles.content}>\n <code style={styles.code}>{emoji.code}</code>\n <p style={styles.description}>{emoji.description}</p>\n </div>\n </li>\n ))}\n </ul>\n )\n }\n}\n\nexport default EmojiList\nA step to improve this code, would be to create separate components into the same file and then using them at the main component. However, you'll be sharing styles among other things and that could be confusing.
\nLet's start refactoring the single component into multiple ones by breaking up the UI into a component hierarchy.
\n![\"emojilist-breakdown\"](\"https://res.cloudinary.com/carloscuesta/image/upload/emojilist-breakdown.png\")
If we take a look at the image, it's easy to identify that we can break up our UI in three different components: 🛠
\nEmojiList: Combines the smaller components and shares the state down.SearchInput: Receives user input and displays the search bar.EmojiListItem: Displays the List Item for each emoji, with the icon, name and description.We're going to create a folder for each component, with two files, an index.js that is going to hold all the code for the component and the styles.js. That's one of the good things about this pattern. Every component defines his own UI and styles, isolating this piece of code from another components that doesn't need to know anything about them.
Notice that inside the EmojiList folder, (that is a component), we add two nested components that only will be used within the EmojiList component. Again, that's because these two components aren't going to be used out of that context. This helps reducing the visual clutter a lot.
.\n├── EmojiList\n│ ├── EmojiListItem\n│ │ ├── index.js\n│ │ └── styles.js\n│ ├── SearchInput\n│ │ ├── index.js\n│ │ └── styles.js\n│ ├── index.js\n│ └── styles.js\n└── index.js\nNow let's isolate and separate the code into the three components from the smallest to the biggest one:
\nEmojiListItem/
This component renders every emoji item that will appear on the list.
\nimport React from \"react\"\n\nimport styles from \"./styles\"\n\nconst EmojiListItem = (props) => (\n <li style={styles.item}>\n <div style={styles.icon}>{props.emoji}</div>\n <div style={styles.content}>\n <code style={styles.code}>{props.code}</code>\n <p style={styles.description}>{props.description}</p>\n </div>\n </li>\n)\n\nexport default EmojiListItem\nSearchInput/
This component receives the user input and updates the state of the parent component.
\nimport React from \"react\"\n\nimport styles from \"./styles\"\n\nconst SearchInput = (props) => (\n <input\n style={styles.searchInput}\n placeholder=\"Search by name\"\n type=\"text\"\n value={props.value}\n onChange={props.onChange}\n />\n)\n\nexport default SearchInput\nEmojiList/
This is the top level component, holds the state and data of our example and imports the other components to recreate the whole UI of our tiny application. Isolating components makes the render method more readable and easier to understand ✨.
\nimport React from \"react\"\n\nimport SearchInput from \"./SearchInput\"\nimport EmojiListItem from \"./EmojiListItem\"\nimport styles from \"./styles\"\n\nclass EmojiList extends React.Component {\n state = {\n searchInput: \"\",\n emojis: []\n }\n\n render() {\n const emojis = this.state.emojis.filter(emoji =>\n emoji.code.includes(this.state.searchInput.toLowerCase())\n )\n\n return (\n <ul style={styles.list}>\n <SearchInput\n onChange={(event) => this.setState({ searchInput: event.target.value })}\n value={this.state.searchInput}\n />\n {emojis.map((emoji, index) => (\n <EmojiListItem\n key={index}\n code={emoji.code}\n description={emoji.description}\n emoji={emoji.emoji}\n />\n ))}\n </ul>\n )\n }\n}\n\nexport default EmojiList\nThat's basically the architecture that I use at the company I'm working on. I'm pretty satisfied with the experience of using this pattern. Our components turned out a lot easier to maintain and use. Anyway there are no silver bullets on Software Engineering, so figure what works best for you or your team!
\n","images":{"featured":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/scalable-react-components.png"},"preview":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/w_500/scalable-react-components.png","lqpi":"https://res.cloudinary.com/carloscuesta/image/upload/t_lqpi-post-preview/scalable-react-components.png"}},"slug":"scalable-react-components-architecture","title":"Scalable React Components architecture"},{"dateModified":"2018-10-15 09:53","datePublished":{"formatInWords":"almost 2 years ago","formatDate":"19 September 2018","value":"2018-09-19 09:53"},"disqusIdentifier":"5ae59dcdb3211a06522ad69b","excerpt":"The process of continuously delivering React Native apps with Fastlane and Travis CI automatically. ","html":"A year ago I wrote a post about how Fastlane could help us to improve our React Native apps shipping process. At that moment even though everything was automated, the deployment relied on one of us with a provisioned machine in order to launch the rocket 🚀. We could improve easily that process by continuously delivering our apps through a CI machine. That's when Travis CI comes to the rescue! 👷🏻♂️
\nBefore explaining what's the problem, it's important to understand the complexity of our deployment process.
\nIn a nutshell we have two platforms: iOS 🍏, Android 🤖 and every platform compiles two applications: Beta testing app also known as Canary 🐤 and Production 🚀 one.
\nBasically every platform goes through a lane sequantially that looks like this 👇
\nNow let's see in depth every step of the deployment process to understand what we do.
\nSigning native applications is scary 😱, specially when you come from the JavaScript ecosystem. Certificates, provisioning profiles, keys... You have to be utterly organized when using them in a development team.
\nWe adopted the codesigning.guide concept through Fastlane. Basically this idea comes up with having a specific git repository to store and distribute certificates across a development team. We store both iOS and Android code signing files on an encrypted private git repository that lives on GitHub.
\nThen, our CI machine on every deploy clones the repository and installs the decrypted certificates. On iOS the CI creates an OS X Keychain where the certificates are installed.
\nNative builds and stores require code version bumps.
\nEvery platform has his own way to manage versions and build numbers. The difference between those two is that the version should be used as the public store number that identifies a new release, and the build number is an incremental identifier that bumps on every build.
\nAndroid 🤖
\nversionNameVERSION_CODEiOS 🍏
\nCFBundleShortVersionStringCFBundleVersion and CURRENT_PROJECT_VERSIONThose attributes are stored on .plist, .pbxproj, .properties and .gradle files. To automate and do version management we use the package.json version number as the source of truth for our public version numbers 💯. This allows us to use npm version cli command to manage bumps.
We need to provision two machines to build and compile our native applications.
\nFor iOS we setup a macOS system with Xcode, because it's the only way to compile and sign the application. On Android we provision a Linux system, with all the Android Studio, packages and tools that we need.
\nThose machines are created by our CI, that means every build runs on a new fresh and clean environment 💻.
\nTo distribute the application to beta testers we use TestFlight on iOS and HockeyApp for Android. We tried Google Play Beta but it was too slow on the app roll out compared to HockeyApp.
\nTo distribute the application to the stores we upload the production build to TestFlight on iOS and Google Play Store for Android. The release is done manually by a human being.
\nTo get human readable information about crashes and errors, we use a service called Bugsnag. Every time we deploy a new build, we need to upload debug symbols .dSYM and sourcemaps to Bugsnag.
Finally, when the apps are deployed, we need to inform our beta testers, release manager and developers, that we have a new version. We use Slack with a bot that sends alerts to some channels.
\nEvery time we wanted to do a release, we had to manually fire 🔥 the Fastlane deployment lanes. That means that human factor was needed. This was a time consuming process that often failed due to code sign, biased environments, software updates, native platform dependencies...
\n\n\nMachines should work, people should think.
\n
Definitely we decided to end with those problems by automating all the things!
\nThe solution is to implement this automated process into a system that continously delivers our master branch pushes up to the stores magically 🎉, giving freedom to the manager to decide when a new release comes up. Finally, we could forget about everything and be happy! ❤️
Now we're going to take a look on how we integrated Travis and Fastlane to automate the deployment of our apps 👏.
\nWe have two deployment lanes one for Android and one for iOS. I've simplified the lanes a little bit for the explanation to focus on the important parts of it. First we deploy Android platform and then iOS.
The lane receives a version number that comes from the package.json, as I said before this allows us to do versioning through npm.
The first thing we do is bumping the public version number and the build number. On the iOS lane, we need to setup_certificates, to save them on the Keychain and be able to sign the apps.
After that we start the canary 🐤 and production 🚀 lanes. Those two are the ones who build the native app.
Canary: Beta testing build, ships to TestFlight and HockeyApp.Production: Production build, ships to TestFlight and Google Play Store.Then, we upload all the sourcemaps and debug symbol files to Bugsnag.
\nNext, we create a git branch where the version bumps will be commited, through the commit_and_push_version_bump lane. Later, on the iOS lane we merge the created git branch on top of master using the git_flow_merge lane. We need to commit the bumps, in order to maintain the version along with the deployments. Otherwise the stores should throw an error that the uploaded version already exists!
Finally we reach out Slack, to communicate both deployments.
\nAndroid 🤖
\nlane :deployment do |version: version|\n bump_version_number(version: version)\n canary\n production\n sh 'npm run repositories:upload:android'\n commit_and_push_version_bump\n slack_notification(platform: 'Android', version: version)\nend\niOS 🍏
\nlane :deployment do |version: version|\n setup_certificates\n bump_version_number(version: version)\n canary\n production\n sh 'npm run repositories:upload:ios'\n commit_and_push_version_bump\n git_flow_merge(version: version)\n slack_notification(platform: 'iOS', version: version)\nend\nSo, here's how our git log, looks like after merging a branch to master and making a deploy 🙌:
![\"GitHub](\"https://res.cloudinary.com/carloscuesta/image/upload/ghlog.png\")
We use build stages, to run our deployment process in three steps, sequentially. This allows us to deploy our apps only on the master branch when our tests passed ✅.
Let's take a look at the build stages 👇
\n![\"travis-build-stages\"](\"https://res.cloudinary.com/carloscuesta/image/upload/travis-build-stages.png\")
Every build stage has his own provisioning and enviroment. For instance, Deploy iOS runs on a macOS machine with Xcode and Node.js installed, while Deploy Android uses an Ubuntu machine with JDK, AndroidSDK and Node.js.
Test stage ✅
\nOn the first stage we execute the linters and test suites. To ensure everything is working as expected. If something fails here, we automatically stop the deploy.
\n- stage: Test and lint ✅\n language: node_js\n node_js: 8.5.0\n install: yarn\n script: npm run test:lint && npm run test:unit\nAndroid stage 🤖
\nAndroid stage creates a provisioned Ubuntu machine with all the software and dependencies needed. Then we build the Canary 🐤 and Production 🚀 applications apps. After that we deploy them. In around 15 minutes ⏰ our Android apps ship. 👏
\n- stage: Deploy Android 🤖\n if: branch = master AND type = push\n language: android\n jdk: oraclejdk8\n android:\n components:\n - tools\n - platform-tools\n - android-26\n - extra-google-m2repository\n - extra-google-google_play_services\n before_install:\n - nvm install 8.5.0\n - gem install bundler\n - bundle install\n before_script:\n - ./internals/scripts/travis/gitconfig.sh\n install: yarn\n script: npm run deployment:android\niOS stage 🍏
\niOS stage creates a provisioned macOS machine with Xcode and all the dependencies needed. Then we build the Canary 🐤 and Production 🚀 apps. After that we deploy them. In around 20 minutes ⏰ our iOS apps ship. 👏
\n- stage: Deploy iOS 🍏\n if: branch = master AND type = push\n language: node_js\n node_js: 8.5.0\n os: osx\n osx_image: xcode9.2\n before_install: bundle install\n before_script:\n - ./internals/scripts/travis/gitconfig.sh\n install: yarn\n script: npm run deployment:ios\nThe monorepo term is a compound word between \"mono\", from Ancient Greek \"mónos\", that means \"single\" and \"repo\" as a shorthand of \"repository\".
\n\n\nA monorepo is a strategy for storing code and projects in a single repository.
\n
Monorepos allow you to reuse packages and code from another modules while keeping them independent and isolated. This is particularly useful when you have a ton of code that you're constantly repeating on different projects.
\nDependencies are hoisted to the root level of the project, that means you can share dependencies across all the packages that you have in your monorepo. This reduces the overhead from updating and managing multiple versions of the same dependency.
\nMaking cross-repo changes within different repositories is painful. Typically involves manual coordination between teams and repos. For example let's say you have an API that is used by many clients and you want to make a breaking change into the contract. It's not trivial to apply the update to all the clients and then coordinate the deploy of the projects and so on. With a monorepo it's easier since everything is contained in a single unit.
\nBefore considering to implement a monorepo architecture, make sure you have the problems that this concept solves ⚠️. There's no need to overengineer a project. Remember keep it simple ✨
\nNow that we know what is a monorepo, the tools that we're going to use and what are they useful for, let's create a real example to see how it works.
\nLet's begin creating our monorepo 👏. The first thing we need to do is define the structure of the project. In this example I created two directories:
\npackages/: This directory will contain the isolated modules that we are going to reuse on all the applications.applications/: This directory will contain all the applications of our monorepo..\n└── src\n ├── applications\n └── packages\nAfter that, we're going to create package.json to define the workspaces and dependencies of our monorepo.
The workspaces field is what Yarn uses to symlink our code to the node_modules in order to reuse and import the code, we'll see this later on.
Finally we install lerna as a devDependency to manage the monorepo.
{\n \"private\": true,\n \"engines\": {\n \"yarn\": \">=1.17.3\"\n },\n \"name\": \"monorepo-example\",\n \"workspaces\": [\n \"src/applications/*\",\n \"src/packages/*\"\n ],\n \"scripts\": {},\n \"devDependencies\": {\n \"lerna\": \"latest\"\n }\n}\nNow, let's define how Lerna is going to manage our monorepo in a lerna.json configuration file.
packages: The directories that we defined as workspaces in the package.json.npmClient: The client used to run the commands.useWorkspaces: This flag tells lerna that we're going to use yarn workspaces.{\n \"lerna\": \"latest\",\n \"packages\": [\n \"src/applications/*\",\n \"src/packages/*\"\n ],\n \"version\": \"1.0.0\",\n \"npmClient\": \"yarn\",\n \"useWorkspaces\": true\n}\nWe finished our setup 🙌! Let's add some simple code to see how we can manage and reuse packages on our monorepo.
\nA package inside our monorepo context, is an isolated and reusable piece of code. That means, every time we want to create a new package, we're going to create a new independent directory.
\n.\n└── packages\n └── sayHello\n ├── index.js\n └── package.json\nEach package needs to have a package.json with the name and version fields defined. This is important because this describes how we're going to import and use this package on the code base. You can also have dependencies in your package if you need them. On this example I'm writing a simple package called sayHello.
{\n \"name\": \"@packages/sayHello\",\n \"version\": \"1.0.0\",\n}\nThink of every directory inside the packages/ folder as an isolated module, with his own tests, dependencies and code.
const sayHello = (name) => {\n console.log(`Hello ${name} 👋🏼`)\n\n return name\n}\n\nmodule.exports = sayHello\nThis was pretty simple right? Now let's say that we have an application that it's called cli. In order to use sayHello package we should add it as a dependency on the package.json file. To do that we have a fancy yarn command 🎉
yarn workspace @applications/cli add @packages/sayHello@1.0.0\nNow from our cli application we can import and use the package! 💯
const sayHello = require('@packages/sayHello')\n\nsayHello('Carlos')\nFinally, we run our cli application from the command line using Lerna 🚀
![\"monorepo-workspaces\"](\"https://res.cloudinary.com/carloscuesta/image/upload/monorepo-workspaces.png\")
You can find the example explained on the post on this GitHub repository 👀. I know this was pretty simple, but there are a ton of things you can do with monorepos! For example you can share react components in different applications while keeping them isolated. But take a look below 👇 to see monorepos on big open source projects!
\nHere's a list of well known open source projects that are using the monorepo architecture:
\n\n","images":{"featured":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/JavaScript-monorepos-with-Lerna-and-Yarn-Workspaces.png"},"preview":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/w_500/JavaScript-monorepos-with-Lerna-and-Yarn-Workspaces.png","lqpi":"https://res.cloudinary.com/carloscuesta/image/upload/t_lqpi-post-preview/JavaScript-monorepos-with-Lerna-and-Yarn-Workspaces.png"}},"slug":"javascript-monorepos-lerna-yarn-workspaces","title":"JavaScript monorepos with Lerna and Yarn Workspaces"},{"dateModified":"2019-09-12 17:00","datePublished":{"formatInWords":"10 months ago","formatDate":"12 September 2019","value":"2019-09-12 17:00"},"disqusIdentifier":"5d78d0fcf942665cd6becd9a","excerpt":"I'm going to explain why it's important and how you can use error boundaries in a React-Native application to improve error resiliency 👨💻","html":"React 16 released a new concept called Error Boundary. This concept introduces a new way to catch JavaScript errors 🐛 in a React project.
\nIn this post I'm going to explain why it's important and how you can use error boundaries in a React-Native application to improve error resiliency, so let's get into it! 👨💻
\nAccording to the official React docs 📘:
\n\n\nAs of React 16, errors that were not caught by any error boundary will result in unmounting of the whole React component tree 😱.
\n
Unmounting the whole React component tree, means that if you don't catch errors at all the user will see an empty white screen 💥. Most of the time without having any feedback. This is not a great UX ❌, fortunately you can fix this by using Error Boundaries ✅.
\n![\"React-Native](\"https://res.cloudinary.com/carloscuesta/image/upload/react-native-error-unmounted-tree.png\")
To benefit from Error Boundaries, we'll have to create a stateful component that will use the following lifecycle methods ♻️:
\ngetDerivedStateFromError: This method is going to update the component state to display a fallback UI.componentDidCatch: This method should be used to log the error to an external service.So let's create the component that will catch errors in our application:
\nclass ErrorBoundary extends React.Component {\n state = { hasError: false }\n\n static getDerivedStateFromError (error) {\n return { hasError: true }\n }\n\n componentDidCatch (error, info) {\n logErrorToService(error, info.componentStack)\n }\n\n render () {\n return this.state.hasError\n ? <FallbackComponent />\n : this.props.children\n }\n}\nPretty simple right? With a few lines of code, you can catch errors on your React-Native app 🎉
\nTo use it, all you need to do now is to wrap it around any component that could throw an error.
\nconst App = () => (\n <ErrorBoundary>\n <Children />\n </ErrorBoundary>\n)\nThis component will catch all the errors that are thrown by any of his children. A common thing is to use it at the top level of your application 🔝 to catch anything without having to use it on every screen or route 👏
\nThat's how our FallbackComponent looks whenever an error is thrown by our application 😍
![\"react-native-error-boundary\"](\"https://res.cloudinary.com/carloscuesta/image/upload/react-native-error-boundary.png\")
⚠️ Error Boundaries only catch JavaScript errors, all the native crashes that your application might have are not handled.
\nreact-native-error-boundaryFew months ago, I created a simple, flexible and reusable React-Native error boundary component. Take a look into it 👀 if you're thinking about adding error boundaries to your app!
\n","images":{"featured":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/handling-react-native-errors-with-error-boundaries.png"},"preview":{"src":"https://res.cloudinary.com/carloscuesta/image/upload/w_500/handling-react-native-errors-with-error-boundaries.png","lqpi":"https://res.cloudinary.com/carloscuesta/image/upload/t_lqpi-post-preview/handling-react-native-errors-with-error-boundaries.png"}},"slug":"managing-react-native-crashes-with-error-boundaries","title":"Managing React-Native crashes with Error Boundaries"}]}},"__N_SSG":true}