DEV Community: Igor Santos

Keyboard shortcuts to raise specific windows

Igor Santos — Sun, 22 Jun 2025 17:40:28 +0000

As soon as I got a Keychron K10 Pro, I started to wonder what to do with those extra 4 keys on the corner.

First, of course, I needed some cooler keycaps than square/circle/triangle/cross. So I got a couple from AliExpress - Pokémon not only because yes but also because cooler keycaps were waaaay too expensive (RIP One Piece).

Then, I had to do something with those damn keycaps.
For years and years, I already had a tiny script that only allowed me to open a single instance of SpeedCrunch (a simpler but smarter calculator, with no keyboard because I always used full keyboards lol). If the calculator was already opened somewhere, the script would raise the window instead.

Over the last year or so, that script suffered multiple iterations, until the current siwm version, which is PHP-based and uses wmctrl and xprop to play around with the windows.

Right now, my keyboard can directly focus all the routine apps I use:

Bulbasaur opens Home Assistant and Spotify;
Pikachu opens Slack and PHPStorm;
Squirtle opens my time-tracking apps;
Charmander opens WhatsApp and Telegram.

I hope this is useful for more people! It's not public on GitHub because it's inside my private dotfiles repo 🙃

#!/usr/bin/env php
<?php
array_shift($argv); //script name
$search = array_shift($argv);

function has_arg(string $arg): bool {
        return (in_array("--$arg", $GLOBALS['argv']) || preg_match("/(?<!-)-[a-z]*$arg[0]/", join(' ', $GLOBALS['argv'])));
}
function debug(string $msg): void {
    if (DEBUG) {
        echo "[DEBUG] $msg\n";
    }
}
define('DEBUG', has_arg('debug'));

if (!$search || $search[0] == '-' || has_arg('help')) {
    echo <<<HELP
    Usage: siwm <search> [executable] [-hdc]
    Args:
        search    : what you're searching for (window title, or class together with --class)
        executable: what to run if nothing is found - if this is not given, it tries to execute the search string
    Options:
        -h/--help : show this and quit 🙃
        -d/--debug: show extra debug info
        -c/--class: search by window classes instead of titles

    HELP;
    echo "\n";
    exit;
}

if (has_arg('class')) {
    $wmctrlSearch = 'wmctrl -x';
    debug("Searching by class: $search");
} else {
    $wmctrlSearch = 'wmctrl';
    debug("Searching through window titles: $search");
}

$search = preg_replace('/([\[\]])/', '\\\$1', $search);
$searchCmd = "$wmctrlSearch -l | grep -iw -m1 \"$search\"";
debug("$> $searchCmd");
$isOpen = shell_exec($searchCmd);

if ($isOpen) {
    $wmctrl = 'wmctrl -i'; //selects the window by its ID, which is more reliable
    debug('Window found: "'.trim($isOpen).'"');
    [$id] = explode(' ', $isOpen);
    echo "Raising window $id...\n";
    if (str_contains(shell_exec("xprop -id \$id"), 'STICKY')) {
        echo "[DEBUG] Hmmmm, it's sticky! Let's do it differently.\n";
        shell_exec("$wmctrl -R $id; $wmctrl -r $id -b add,sticky");
    } else {
        shell_exec("$wmctrl -a $id");
    }
} else {
    echo "No window found matching '$search' 🤨 \n";
    $app = join(' ', array_filter($argv, static fn($arg)=> !str_starts_with($arg, '-')));
    if (!$app && !str_contains(' ', $search) && shell_exec("which $search")) {
        $app = $search;
    }

    if (!$app) {
        echo "Also, nothing to execute related to that. Try [...]\n";
        exit;
    }

    //https://stackoverflow.com/a/11921855/102960
    echo "Running `$app`...\n";
    if (pcntl_fork() == 0) {
        shell_exec($app);
    }
}

Quick tip: Sharing JetBrains code style throughout the repository

Igor Santos — Thu, 15 Nov 2018 01:46:32 +0000

This is a quick one. There's an article from JetBrains explaining how to properly include the .idea folder in the project's repository. However, I was never able to understand how to include the Code Style there. On three different projects, we ended up sharing the Code Style export through Slack... lol

However, if you simply copy the style from the IDE into the Project itself, it will start showing properly on the .idea folder. The problem is that this option is not really obvious, and there's little clue on why this single setting is not included on the said folder, while other parts of the project settings are clearly marked as "shared/project exclusive".

This has been tested on PHPStorm, but I'm pretty sure it will work on PyCharm, IntelliJ, WebStorm or whatever else flavor of a JetBrains IDE you use!

Have fun coding.

My preferred merge strategy for Pull Requests

Igor Santos — Fri, 03 Aug 2018 07:42:47 +0000

In every decent team project I've worked before (that had PRs in place), the merge strategy was to squash all commits into a single one, to be done into the master branch.

In the beginning, it felt odd, as "all my hard work and organized commits" would become a single, standardized blob of sorts. Then I got used to the flow and, well, whatever, right? It works®.

But then it came the time it was me who was deciding the path a team would start to walk through. And the question came, why squash merges? Why rebases?

As people say, first you resist, then you accept, and then you question what was happening.

So, to help with understanding why I chose Squash Merge to be the default for our repository:

Squash merges are usually preferred not only because of the "flat history" (that is usually easier to navigate with any tooling), but actually, because the history gets much cleaner and "straight to the point", without all the partial commits that are common during development.
If the squash is done correctly, you'll still maintain all commits' text in the squashed commit, so you can still get some details about the development of that feature, without clogging your master history.

One should also remember history is not only used to see code progress on a timeline/tree, but also for blaming changes. Even though you can use tools or extra options to "ignore" partial commits, blame probably won't - or will get too convoluted, at least.

I did some quick research to see discussions on the subject, and I can link you to two references that show my opinion and that I used to enhance my arguments above:

Answer about squash preference, on a CLI tool for Git Workflow:

[...] And over time, that's all we really care about in the history. Who made this change and why was it made. Squash merging allows us to do that while still giving all of our developers the individual freedom to develop in the way that suits them best.

GitHub manual about PR merge strategies:

You can use squash and merge to create a more streamlined Git history in your repository. Work-in-progress commits are helpful when working on a feature branch, but they aren’t necessarily important to retain in the Git history. If you squash these commits into one commit while merging to the default branch, you can retain the original changes with a clear Git history.

(this was also posted to my Medium)

Best wishes of no-conflict merges!

The state of Laravel-based APIs - a personal research

Igor Santos — Tue, 12 Jun 2018 08:02:33 +0000

Friendly disclaimer: this is a quick and dirty post that I'm putting together as I research API resources to build an API for a project I'm working on, so I'm sorry for being so direct and to the point, and also for the number of levels and bullet points :)
It was written in the order of "here only for the sake of completeness" down to "probably what we're going to use".

TL;DR

GraphQL should be the way to go only if your frontend sort of requires it. Needs a lot of boilerplate and manual sync between your Eloquent models and GraphQL-related code.
JSON-API is the most respected standard that could face GraphQL, but on Laravel-land it renders you documentation-less. You'll probably have to write separate documentation on API Blueprint or something like that, and it might take you some time as well. You can also discover how to get Blueprint generated through a specific package (that bridges JSON-API with Dingo), but... good luck on that.
Handwritten RESTful API... Do I need to comment on that? It's handwritten. Certainly not a good option for a medium or big API. EOF.

Prologue: basic API requirements we had

should have built-in documentation, that's not dependent on the developer to manually write it (think PHPDocs that magically autocomplete in your IDE)
it needs to be blazing fast, as it will be used on a speed-sensitive user interface
- here the features of field-selection from GraphQL or JSON-API come to my mind
- obviously, a simple cache layer might also be helpful

Research and comparisons

API type option 1: GraphQL

Short conclusion. Doesn't seem trivial to be built, as there's a lot of boilerplate to be written that repeats information from Eloquent: GraphQL Types, Queries, and Mutations. That happens on both packages found, and neither of them helps by having a boilerplate-generator.

Helpful Packages

By Folkore Atelier
By Rebing, based on Folklore's

API type option 2: RESTful

Subtype 1: JSON-API

Conclusion: also not that trivial to work with, but seems simpler than GraphQL. However, documentation might be a weak point.

Helpful packages

Nil's Laravel5-json-api

Implements include, fields, sort, page
Almost boilerplate-free with generic controllers
- However, you still need to configure Transformers, although they don't repeat much information from the Eloquent model
No support for documentation generation. At all.

Laravel5-json-api-dingo

Good points

Theoretically, brings together the best of both packages, including Dingo's features (Dingo is discussed later) such as Auth, Versioning, Rate limiting, Docs and Routes into laravel5-json-api (called L5JA from now on).

Bad points

it's not clear how documentation could be generated, as Dingo depends on annotations and L5JA is ideally based on a generic controller implementation. There might be other integration issues, as the examples do not clearly define how to bring both packages together, besides a basic routing sample.
support also seems to be lacking behind.

cloudcreativity's Laravel-json-api

This one has very long documentation; while seems complete, it might take a while to read everything and implement (took me a while reviewing the docs to see what features were available). And there are at least two empty pages, with a simple "todo" note.

Good points

also sort of boilerplate-free with generic controllers, and basic code generation for the other things (Adapters, Schemas)
Adapters and Schemas will still need some filling and manual sync with the Eloquent model, though
Also sports first-class validation rules for the API (which might end up being duplicated on your code, just like Eloquent details....)
seems to have a decent Auth infrastructure

Bad points

no clear mention on the docs about the selection of fields, and missing docs for sorting and "sparse fieldsets" (if that what I called "selection of fields"?) (issue on the topic)
filtering must be hand-written as well, there's no automatic API to turn filter parameters into Eloquent queries (much like GraphQL queries are built... sad).
also, no mention about documentation generation. There's an old issue that states Swagger can't work together with JSON-API, and the main developer doesn't have time to dedicate to that (we all know how open-source is born and dies, right? Free developer time during the lifecycle of a related project...)

Subtype 2: Plain "bring-your-own-standard" JSON API

Conclusion: the easiest to be built in our case, as we might end up needing only a couple of read-only endpoints. Might need some boilerplate to allow for field selection or advanced querying capabilities, but generates Blueprint documentation files and might even generate HTML docs with other generators.

Helpful Packages

Dingo

Good points

complete feature-set: auth, rate limiting helpers, errors, routing, doc generator (through Blueprint files)
Blueprint files can be used with a number of parsers to, then, generate HTML documentation or similar. Options and related resources are listed at the bottom of this post.

Bad points

Well... you'll have to write all your controllers and actions by hand. And define all your filters, if any. And whatnot.

Restler

This is actually unrelated to Laravel, but Eloquent can be easily made to work with it, so it's worth mentioning as a companion project to your main Laravel application.

Good points

complete feature-set, including Swagger documentation based on PHP Doc blocks and method parameters (that are also used for automatic request validation)

Bad points

Got abandoned:

stopped on PHP 5.4 support, while could have a great usage of PHP 7 first-class types
stopped on an old version of Swagger, missing some of its features - probably one of the reasons the package got abandoned, as Swagger is sometimes referred as a very complicated beast to deal with.

Sample implementation

Once upon a time, I started working on an API Server build with an Eloquent extension (also sort of abandoned) and Restler. It included some base controllers that made CRUD actions only a couple of lines away.

Other useful resources

Apiary - complete toolset (needs clarification!) to define, document and work on APIs.
Apimatic's transformer - UI and API that can translate to/from almost any doc format. Could be integrated in the API generation pipeline.
Dredd - parses Blueprint/Swagger docs and automatically runs tests to ensure the Backend complies with the defined documentation.
Blueman [probably outdated] - Generates Postman collections based on Blueprint files
PHPDraft - basic HTML generator from Blueprint files
Laravel Blueprint docs - generates integrated documentation inside your Laravel project, using its routing, and Blade templates for further customization.

How to set different defaults for author and committer at git

Igor Santos — Sat, 21 Apr 2018 03:36:55 +0000

Me, looking for a way to set different author and committer on Google: nowhere to be found. Sad Igor was sad.

I wanted to have a default Committer that’s different from my default Author, as I need to differentiate commits made from my local and testing environments.

This is not as straight-forward as setting name/email at git, as there are no separate configuration entries for author and committer. However, it’s still possible if you override some environment variables, as follows:
Example (at your ~/.bashrc or ~/.bash_profile):

GIT_COMMITTER_NAME=”Deploy server”
GIT_COMMITTER_EMAIL=”deploy@server.dev”

In case you’ve forgotten/don’t know, you can set default name/user for git commits by editing ~/.gitconfig or running commands like these:

$ git config — global user.name “Igor Santos”
$ git config — global user.email “igor.santos@example.com”

Hi, I'm Igor Santos

Igor Santos — Sat, 22 Apr 2017 00:04:10 +0000

I'm a back-end developer fond of front-end interfaces with around 10 years of experience. Most of them with PHP, but some at Rubyland as well and a couple of others dealing with JavaScript.

You can find me on GitHub, Twitter and most other places as igorsantos07.

I live in Rio de Janeiro currently, but as a remote developer @ Toptal sometimes I'm working from all sorts of different places.

That's me!

A (not so) small rant on techniques to copy MySQL database structures

Igor Santos — Tue, 07 Mar 2017 00:00:00 +0000

And here I am, facing a simple task of duplicating the original company’s database into a test db, so we can, uh, run tests.

Just a matter of mysqldump’ing it, you would guess.
Some rare folks would even point to CREATE TABLE x2 LIKE x1. Very clever.

But MySQL is not here for you. He’s quite a respectable but buggy guy, in the end. I’m writing this small article, to sum up all the resources I found along this adventure, in the hope this could help other adventurers out there.

TL;DR: play around with mysqldump and SSH, or use string sorcery with SHOW CREATE TABLE.

`CREATE TABLE LIKE` doesn’t copy views

This issue is quite simple: you can’t create views with a CREATE TABLE command, obviously.
And no, there’s no CREATE VIEW x2 LIKE x1, because a view’s usage is similar to a table’s only in some cases. You have to resort to string sorcery and the output of SHOW CREATE VIEW.

Bonus: should I mention there’s no way to separate tables from views on commands such as SHOW TABLES?

`CREATE TABLE LIKE` copies everything from the structure, except constraints

The manual tells you that you can copy over your table using that command, including column attributes and indexes. But there’s no clear statement saying your constraints will go forgotten.
It also tells you foreign keys will be dumped correctly by mysqldump, even telling you about the ordering issue that utility has. But why tell you the negative, unsolved issues such as that those constraints are not included in the CREATE TABLE LIKE copy operation?

So in those two cases, you got to resort to string sorcery. The usual features MySQL built for that doesn’t work.

`mysqldump` might take forever to run across a network

In some cases we would need to copy the structure from a machine to another, so the best way would simply to give mysqldump the host, user, and password, and ask him for a complete dump that database schema, correct?

Oh well, if we ssh’d into the server and ran mysqldump it would take, say, 3 secs to dump everything. Downloading that dump over SSH would take the same amount of time.
If done using host/user/password it could take almost 3 minutes (!!!), over the exact same VPN network.

Thus we had to stuff into our application some SSH credentials. Just for that single operation. DB credentials are not enough for MySQL’s dump protocol.
Go wonder.

`mysqldump` might ignore your foreign key order

Again, as stated in the manual, mysqldump will disable foreign key checks on your dump so table order can be ignored during importing.
However, that depends on your command line options. If you get naïve and try to speed up things --compact‘ing your dump, MySQL will take your disable command out; you’ll have to add it by hand — what’s not hard, as you’ll be renaming the original database in the dump anyway…

Views on mysqldump or SHOW CREATE VIEW include information related to the original user

One more thing you get to replace() on your dump: the view’s part will include the algorithm and definer options — the last one, pointing to the user that created it. Unless that user is yourself, you got to replace that or MySQL will ask you for more permissions than you have.

CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`192.168.0.1` SQL SECURITY DEFINER VIEW `mydb`.`v_cool_view` AS (…)

The final solution

To make stuff work both locally and across the network, we had to:

Verify if we had a local copy of the original db. If the answer is yes…

Get CREATE statements for every table and view
Alter the needed information on those (especially on CREATE VIEW commands)
Run drops and foreign key checks
Run each of those create commands

As it turns out, playing around with SHOW CREATE statements took the same amount of time CREATE TABLE LIKE takes, if not less.

If we had to connect to an external DB…

run mysqldump over ssh into that machine
Alter dump as needed, especially on view commands
Add drops and foreign key checks
Write that into a temporary file, and run it over mysql client As we had to alter the dump before running it, a simple pipe wouldn’t do; altering it with cat and sed would complicate things way too much, and there was no way to run a bunch of queries at once through our ORM, nor a reliable way to separate each query in the dump file (many were comment-fenced).

Good luck on your MySQL adventures, sir. Good luck.

Quick tip on Git diffs for PHP files

Igor Santos — Thu, 15 Sep 2016 23:00:00 +0000

Every time a PHP developer runs git diff on the command line a kitten dies:

Hell no! This piece of code is inside a method, not the class :(

Those @@ snippets are called Hunk Headers - because every part of a diff is called a hunk, duh. Unfortunately, git is too stupid to figure out PHP files should be diff'd according to PHP syntax, so you need to give it a hand by using a rule on git attributes.

Unfortunately(2), git attributes are not that easy to configure user-wide as config options are (no git global commands), thus here's the tip:

create the folder if it doesn't exist: ~/.config/git (or whatever is in $XDG_CONFIG_HOME)
write in ~/.config/git/attributes this: *.php diff=php
Save and diff away

This can also be configured per project by adding the same text inside a .gitattributes file.

There you have it! A decent Hunk Title on PHP files

It's quite weird why Git doesn't understand out of the box that through the file extension, as there are pre-baked settings to understand several syntaxes (such as TeX, Fortran, HTML, etc). Go figure!

References

http://stackoverflow.com/questions/28026767/where-should-i-place-my-global-gitattributes-file

Migrating from Less to Sass - really a good idea?

Igor Santos — Tue, 27 Oct 2015 23:00:00 +0000

I started my new project using Laravel (more on this later), and as it comes pre-packaged with a Gulp helper called Elixir (facepalm: they misnamed it after the Erlang platform), I decided to migrate the original theme CSS files into Less files.

Why Less, you ask? I don't know either. In my last project (ProtoBoard, now an abandoned pet) I used Stylus, although I don't remember the reason as well - probably to use just some of Sass's syntax (no semicolons) without fear of deprecation or the Sass quirkinesses, or maybe because I though I would still need Ruby to compile stuff. Before that, in my old Ruby life, I used to use Sass, but there was no other option at that time besides the defunct TurbineCSS (a project I liked so much I adopted the docs site for years when the original maintainer gave up on it).

Now, after a couple of strong recommendations over Sass, and the fact my stylesheets were taking a whopping ~7s to compile on my 5-years old machine (Sass has a C compiler, so it must be fast, right?), I decided to do the migration over to Sass. At this time I still don't heavily use Less features, I have just indented a couple of rules from the original theme, set color variables here and there and add one mixin, so I thought it wouldn't be a painful process.

Indeed, it wasn't. Besides, as said before, some Sass's quirkinesses. I'm probably going to stick with Less, because of the following reasons:

I use a couple of colour functions, such as darken(), lighten() and fade() from Less. In Less world, they receive a color (hex, HSL or name) and a number, be it a decimal or a percent. In Sass world, however, the lightness functions use percents and the opacity functions (fade-in()/fade-out()) use decimals between 0 and 1; percents and decimals are not interchangeable. Where are the standards here? I can't see any. Could you pls decide what type of number for percents you're going to use, Sass? thnx

Mixins: Less vs Sass, using color names as an argument. If you use darken(goldenrod, 20%) in Sass, it will work fine, but by using goldenrod as an argument to a mixin and passing the color name into darken(), it yelled a compilation error regarding "color must be a color". Go figure.

Although functions like darken() can work just fine with color names in both languages, if you pass a color name into a Sass mixin and use it in a function, it's going to yell at you. So what, Sass? Some arguments are internally changed when they're passed around? WTF
It appeared to me that using Sass to compile my CSS gave whooping 100ms of advantage (in a process that takes around 7s). However, running a simple benchmark (below) between branches I could notice Less was actually faster on my machine. In any way, the speed difference is certainly irrelevant.
Sass actually made a bigger CSS file. However, as I'm running some post-processors as well (namely Autoprefixer and a minifier), the difference would also be irrelevant in production. The size differences are highlighted in the benchmark below as well.
I felt Sass (at it's mostly accepted SCSS syntax) a little bit more verbose, by having to use @mixin and @include to declare mixins, instead of using them transparently as classes. That's certainly a matter of taste, though. On the other hand, Less interpolation feels weird - variable: @var; interpolation: @{var} (?!).
Sass is more simplistic when you're including another file; Less allows you to simply reference files without actually outputting them into the final file, or force them to be interpreted as Less/CSS. That's quite handy sometimes and might make for leaner CSS files.

In the end, I saw really no advantage on using Sass over Less. Both languages seem to have almost the same features, although Sass seems to be more programmable (not that I see this as an advantage; that thing is still a styling language in its roots, right?). Both languages yield similar results on speed and file size (if minified; but you're always going to compile your files to production, right?). Thus, I'm sticking with Less, as it has a bigger front-end community (I think) and does not play a joke with me regarding percents and (you can judge me here) color names.

If there's any other advantage on using Sass, could you kindly tell me? I found none... Besides variables being written with the same prefix my project's language (PHP) uses lol

Platform details

The tests above were run on a 5-years old machine, a high-end Core2Duo with 8GB RAM (with most of my development applications open). The code can be seen here:

Sass branch: source files, compiled CSS, gulpfile
Main branch (Less): source files, compiled CSS, gulpfile

And yes, I know, these source files seems to be a mess. They're original from a theme I bought, and there's already an issue to remind me to merge them together.

Here are the benchmark results, using gulp and gulp --production. The size indicates the final CSS file size, and the time in bold is the average between the 5 times compilation was run (each value indicated below).

The gulpfiles can be seen in the branches highlighted before, as well as the resulting development CSS files.

Less (production) - 108.007kb ~ 6.906s
6.78s | 7.21s | 6.75s | 6.96s | 6.83s

Less (dev) - 149.122kb ~ 5.366s
5.07s | 5.41s | 5.35s | 5.55s | 5.45s

Sass (production) - 108.110kb ~ 7.44s
7.21s | 7.73s | 7.77s | 7.39s | 7.1s

Sass (dev) - 151.576kb ~ 5.494s
5.73s | 5.27s | 5.24s | 5.67s | 5.56s

DEV Community: Igor Santos

Keyboard shortcuts to raise specific windows

Quick tip: Sharing JetBrains code style throughout the repository

My preferred merge strategy for Pull Requests

The state of Laravel-based APIs - a personal research

TL;DR

Prologue: basic API requirements we had

Research and comparisons

API type option 1: GraphQL

Helpful Packages

API type option 2: RESTful

Subtype 1: JSON-API

Helpful packages

Nil's Laravel5-json-api

Laravel5-json-api-dingo

Good points

Bad points

cloudcreativity's Laravel-json-api

Good points

Bad points

Subtype 2: Plain "bring-your-own-standard" JSON API

Helpful Packages

Dingo

Good points

Bad points

Restler

Good points

Bad points

Sample implementation

Other useful resources

How to set different defaults for author and committer at git

Hi, I'm Igor Santos

A (not so) small rant on techniques to copy MySQL database structures

CREATE TABLE LIKE doesn’t copy views

CREATE TABLE LIKE copies everything from the structure, except constraints

mysqldump might take forever to run across a network

mysqldump might ignore your foreign key order

Views on mysqldump or SHOW CREATE VIEW include information related to the original user

The final solution

Verify if we had a local copy of the original db. If the answer is yes…

If we had to connect to an external DB…

Good luck on your MySQL adventures, sir. Good luck.

Quick tip on Git diffs for PHP files

References

Migrating from Less to Sass - really a good idea?

Platform details

`CREATE TABLE LIKE` doesn’t copy views

`CREATE TABLE LIKE` copies everything from the structure, except constraints

`mysqldump` might take forever to run across a network

`mysqldump` might ignore your foreign key order