Creating a UI component library is a common practice nowadays. There are many good examples out there, being bootstrap and foundation some of the most popular as of this writing. Although those are good options for prototyping, there are some reasons while they might not work for big companies.

They need customization to match your company image; If you want to use them for your company you might end up tweaking it so much that it no longer look like the original library.

They are bloated; They are made to meet multiple needs so they include many components that you might not need. Even when you can create your custom build, the components themselves are made for flexibility so they will most likely include stuff you don’t need too.

They are not components; These libraries call themselves UI frameworks, so they are not really component libraries. They usually provide a plethora of useful classes that you can incorporate into your HTML, but there is no really way to say “I want this thing in my page”. You have to do it yourself. Some components they offer also need JavaScript, which means that to use the framework you need to include the CSS and JS and then add the correct classes to your HTML. In a lot of scenarios this is acceptable, but probably hard to scale.

Python allows you to install packages using PIP. This works fine for small projects, but when you want to create a portable application you might run into problems if your application depends on a version of a package that is different to the version that another application depends on. Because by default PIP will install packages in a folder similar to:

1
/usr/lib/python2.7/site-packages/

PIP(PIP Installs Packages) is Python’s recommended tool for package managing. Most modern operating systems come with Python and PIP installed. You can check if Python and PIP are installed using the which command:

1
2
which pip
which python

If PIP is not installed you can follow the documentation to install it.

Oauth2 is an authentication method where you allow clients to access resources in a server by authenticating in a different server. I am building a system where I will need this infrastructure so I will do my best to explain how to build and use an Oauth2 server.

The components

• Resource owner: This is a person. Lets call him Adrian
• Resource server: This is a server where Adrian’s information lives (along with other people’s information). The resource server needs to show Adrian only his information. We’ll call this app server
• Client: This can be a browser or an app that Adrian uses to interact with the app server. This is the browser
• Authorization server: This is our Oauth server. It validates user credentials and assigns tokens among other things. We’ll call this one oauth server

UUID stands for Universally Unique ID. It is a 128-bit value that is usually represented by hexadecimal characters divided by dashes:

1
b54c9b1a-e19c-44e7-ab81-9528c195da02

They are called Universally Unique because in practice it is very hard to have collisions even if two(or more) independent systems generate these IDs independently. It is of course possible to have collisions, but the chances of it are low enough that it can be treated as impossible in most scenarios.

The trunk development flow is an alternative to gitflow or github flow that is used at very big companies(LinkedIn, Google, FaceBook) to allow many developers to work in the same code base with the least amount of friction.

This model existed before git, so it doesn’t really use all its power. If you have done development using another flow, it might even feel wrong at the beginning, because it discourages branching and merging, but it is all for a good reason.

These are the rules I follow when using the trunk model with git:

• Master is always stable – The master branch should always be stable and deployable. For this reason your codebase should be guarded by as many tests and monitoring as possible. Developers should feel comfortable deploying anything that goes to master as soon as it is committed because there may be a system that continuously deploys the master branch.
• No merges allowed – The master branch should remain flat by always rebasing to it. Keeping the master branch flat makes is easier to bisect and revert commits.
• No branches for large tasks – On other flows, branches are created for large tasks that may take days or weeks. This makes development easy, but integration hard. When you are done developing your feature and are ready to add your changes to master, there may be conflicts. Fixing conflicts that are weeks old is hard and error prone. To avoid this problem and still allow for large tasks, use feature toggles instead.

I’m again starting a new project with tools I am not familiar with, and it is exciting. This time I get to play with React. I’ve been wanting to play with React for a while but I got distracted by other technologies. I played a little with Polymer and I liked it so far. I’ve been using Angular for a while and it really annoys me that it is really difficult to componetize. I have heard a lot of good things about react, so I really want to put it to the test.

What is React?

React is more similar to Polymer than to Angular. React Helps create UI components that are easy to reuse. It doesn’t provide a Router, Model or Controller, so you have to take care of those aspects yourself.

I’ve been using JavaScript for a few years, and as of today it is my favorite programming language because it allows you to build things really fast. All the JavaScript I wrote in the past was in a version called EcmaScript 5. I know there is works on EcmaScript 6 and EcmaScript 7, but since I work mostly on the browser, I can’t really use it until the browsers add support.

Babel is a ES6 to ES5 compiler. This means that you can write code in ES6 and it will be transformed to something most browsers understand. This is interesting because it allows us to use new features that are not yet implemented in all browsers, but also because it resembles the way software was developed in the past(write, compile, run). The problem with the old programming model is that it could take some time to compile the code, so there was a delay from when you write the code and you can see it in action. For JavaScript the compilation time can be brought down to something fast enough that the developer doesn’t realize the code was compiled.

When a web project starts getting big, managing dependencies becomes hard if you don’t have the right tools. If you have some experience with web development, you probably use RequireJS to manage your dependencies.

RequireJS does a great job but if you are familiar with node, you probably wish it was as easy in the browser. Dependency management is built into node, so you don’t have to worry about it.

Browserify lets you write node-style code that works in the browser. It is basically a replacement for RequireJS that allows you to create bundles with less configuration.

I just built a little node app that I want to make publicly available. I got a little dedicated server where I am going to host my app. The problem now is getting my app into the server. In the past I had done this task using FTP, but now I know better. There are tools out there that allow us to deploy our app to our server(or list of servers) with a single command, and flightplan makes this task very easy for node apps.

Installation

We need flightplan in our development machine so we can run deploys from there. We can install it from npn:

1
npm install -g flightplan

This globally installs the command line tool that allows us to run the fly command. We also need to install flightplan as a dev dependency of our node project:

1
npm install --save-dev flightplan