Webpack is a module bundler similar to Browserify but with a different philosophy. Browserify was born with the goal of making it possible for developers to write CommonJS(node code) in the browser. Webpack allows you to write CommonJS but it also allows you to use other formats that might not be supported by node. One thing that makes it interesting is that since it doesn’t try to comply with CommonJS, it allows developers to declare dependencies on files that are not necessarily JS, which can be helpful to create self contained components.

Getting started with Webpack

Lets create a simple React app using Webpack. We can start by creating our HTML entry point:

1
2
3
mkdir ~/webpack
cd ~/webpack
touch index.html

Every now and then I have to dig into other people’s code that doesn’t comply to my coding standards. When I make a change on these files, Syntastic lights up like a Christmas tree. Since this is not my code and I can’t really fix it, I prefer to temporarily disable Syntastic:

1
:set SyntasticToggleMode

Once again I changed computers and had to install and configure Vim so it works the way I like it. This time I was a little smarter and created a script that I can use in the future to install it and configure it with one command.

It will install the latest version of vim(from github), download and install the most useful plugins and create a .vimrc file. Just clone the get-vim github project and run:

1
./do.sh

And you are set. Hope it is useful.

Reworkcss is an easy to extend CSS processor that has some cool features I want to explore. Lets start by installing it:

1
2
3
mkdir ~/rework
cd ~/rework
npm install rework

Rework has a very simple API. It receives a string of CSS code and it outputs a rework object. You can then run plugins on this instance and finally output the result:

1
2
3
4
5
6
var rework = require('rework');
var plugin = require('plugin');

rework({source: 'style.css'})
  .use(plugin)
  .toString();

The interesting part happens on the plugins so lets look at some of the most interesting ones.

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.