
In [Factorial](https://www.factorialhr.com), we had the need to know during the
CI analysis which pull request were introducing new
[Rubocop](https://rubocop.org) offenses in our source code.

The requirement was a bit tricky. We didn't want existing offenses in our
source code, only the new ones. This let us to set an starting point as a
threshold of offenses to start decreasing it to zero.

There are similar projects out there, like
[rubocop-git](https://github.com/m4i/rubocop-git),
[diffcop](https://github.com/yohira0616/diffcop),
[nexocop](https://github.com/SimpleNexus/nexocop), but not all of them offer
differences at line level. Only
[rubocop-git](https://github.com/m4i/rubocop-git) offer this nice feature but
you have to craft the commit id to get the proper fork point of your pull
request.

For this reason, I created `rubocop-changes`. Also, I was a bit curious to play
with git diff and Rubocop output. The idea was to cross both outputs to know
exactly in which line there were new offenses.

This is just an example of a failing pull request with one offense:
```
== components/importer/app/services/workbook.rb ==
C:145: 28: Style/TrailingCommaInArguments: Avoid comma after the last parameter of a method call.

12 files inspected, 1 offense detected
```

If you want to play with it, you have it available as a gem in
[RubyGems](https://rubygems.org/gems/rubocop-changes).


Runs rubocop and shows only the offenses you introduced since the fork point


rubocop-changes


I'm a daily user of [Tmux](https://github.com/tmux/tmux) as my favorite
terminal multiplexer. One day, talking to
[Jorge](https://github.com/Morantron), he impressed me with a new hint
picker in the terminal. He was able to pick paths, sha's and other
interesting stuff with few keystrokes. My reaction was priceless.

Jorge did an extraordinary job, building all necessary pieces in Bash to
achieve the text picker behaviour. He only deserves my gratitude for all the
time I have been using
[tmux-fingers](https://github.com/Morantron/tmux-fingers).

During a [Fosdem](https://fosdem.org/) conf, we had the idea to rewrite it to
another language. He had these thoughts many times ago but it was hard to start
from scratch. So, we decided to start playing with Node.js and
[react-blessed](https://github.com/Yomguithereal/react-blessed), but we
detected some unacceptable latency when the program booted. We didn't
investigate much about this latency.

During those days another alternative appeared, called
[tmux-picker](https://github.com/RTBHOUSE/tmux-picker), implemented in python
and reusing many parts from
[tmux-fingers](https://github.com/Morantron/tmux-fingers). It was nice, because
it was fast and added original terminal color support.

I was curious to know if this was possible to be written in
[Rust](https://www.rust-lang.org/), and soon I realized that was something
doable. The ability to implement tests for all critic parts of the application
give you a great confidence about it. On the other hand, Rust has an awesome
community that lets you achieve this kind of project in a short period of time.

## Demo
[![demo](https://asciinema.org/a/232775.png?ts=1)](https://asciinema.org/a/232775?autoplay=1)


A lightning fast version of tmux-fingers written in Rust, copy/pasting tmux like vimium/vimperator


tmux-thumbs


I started this project as a side project to learn Rust. I was searching a
combination of different technologies to play with. I was looking for some
ideas of projects where **network communication, concurrency and file parsing**
were essential parts of the project.

I used some load testing application in the past like *JMeter*. Although they are
so powerful and great, at some point it started to be complicated and
cumbersome to setup a test plan. For this reason a lightweight
[Rust](https://www.rust-lang.org/) application to run a load testing plan of
your web application looked a good side project to create Drill from bottom up.

The project was really influenced by this new trend of having a configuration
Yaml file to code a set of actions. At that time my reference was the syntax of
[Ansible](https://www.ansible.com/).

The project started with a small set of features, but for years we have been
keep adding more and more set of nice things. Right now you can do awesome
things like choose the number of requests, choose the concurrency, dynamic
headers, load CSV, cookie support and much more.

If you want to play with it, you have it available as a binary in
[crates.io](https://crates.io/crates/drill).

Really happy of this project that helped me to learn Rust and all the ecosystem
around it. Also, I want to say thanks to all developers that helped to improved
it. 🙌

## Demo
[![demo](https://asciinema.org/a/164615.png?ts=1)](https://asciinema.org/a/164615?autoplay=1)


Drill is a HTTP load testing application written in Rust inspired by Ansible syntax


drill


I remember it was about two months ago when I was talking with Eduardo
Lanchares about the best stack for the next webapp. Sometimes you are at work
and you are stuck with the current set-up of frameworks and tools that are
quite difficult to change or refactor. This forces you to always work with the
same mentality not allowing you to test new approaches to solve problems.

Following our desire to learn new stuff to make our life easier, we wanted to
experiment with new technology to build a side project with a complete new
stack that fits better with the app requirements.

In that same week, a friend of mine was talking about a bug that was affecting
him in the web client of Transmission. This [bug](https://trac.transmissionbt.com/ticket/5857)
was affecting more people because we found an open bug report in the tracker
that was 2 years old. We decided to check the source code and try to fix it
because we thought that would be a piece of cake. But a few hours later we
discovered that was not as easy as we expected and at some point we gave up.

With all these things in mind we had the perfect scenario and excuse to start
playing with a new side project. We decided to start building a new interface
from scratch to understand new patterns, new approaches and discover what would
be the next challenges for the _ultimate interface_.

## Our experimental stack

Reviewing all of the features in the current Transmission web client, the stack
we chose was React for the user interface, Mobx for the state management and
CSS modules for all the stuff related with the application styles, with a new
build process managed by Webpack.

On the other hand, and with the above stack in mind, we decided to use some
best practices for the long term quality of this project. Some of these were
things like a strict set of Eslint rules, unit tests, UI tests and
internationalization.

With this decision we wanted to achieve a more reliable interface, better
performance, security and correctness. In conclusion a better way to maintain
this web application.

## Demo
![demo](demo.gif)

## Other

With Edu, we presented this experimental project on the BarcelonaJS. Those are
the slides: [Presentation in BarcelonaJS](https://docs.google.com/presentation/d/1cYbyC2Qkf85SQm4Ceq7e9TzXgaiJwMJ_VYilGn-_960/edit?usp=sharing)


React Transmission is an ongoing reimplementation of Transmission web interface.

react-transmission


I was impressed by [Logstalgia](https://logstalgia.io/), a software to show
graphically the traffic that a web application is receiving in realtime. It
uses the `access.log` files to know the origin, the response code and other
information and show it as a *Pong* game style.

You can see a nice demo here:

<iframe width="560" height="315"
src="https://www.youtube.com/embed/HeWfkPeDQbY" frameborder="0"
allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture"
allowfullscreen></iframe>

I wanted to improve my experience with [NodeJS](https://nodejs.org) and I was
curious about trying to replicate the same with Canvas and WebSockets.

Although the result was not impressive as the original, it was nice to deliver
a working PoC that was achieving to get all the pieces to work together.


A Logstalgia port with Node.js, Canvas and WebSockets.


~ferran.basora

All projects

rubocop-changes

tmux-thumbs

drill

react-transmission

nodestalgia