I’ve been thinking of writing a long article around everything a web developer should know about application security for quite some time, and it’s clear to me that this mastodontic exercise is never going to take place all at once.

In order to get things rolling, I’ve decided that, instead of writing one long, exhaustive article, I’ll be splitting my efforts over a longer period of time, and come up with a series around Web Application SECurity (WASEC, since I like to shorten things).

In this article I’d like to introduce the contents I’m going to write about, and how I’m planning to publish them.

Interested in learning how a compromised CDN wouldn’t affect your users? Want to know why CSRF is going to die? Read on.

Today I spend some time to build iploc, a small CLI utility that lets you retrieve geographical information of an IP address.

A few months back I started writing on freeCodeCamp, with the spirit of “giving back” to the community whatever I used to share on my personal blog as well.

FCC is a very interesting publication, and one of the personalities I got to “discover” was Quincy Larson; it was by following Quincy that I discovered I could opt-out of Twitter’s ad tracking, something that turned out to be quite of a journey.

git bisect is a very handy command that lets you isolate which commit introduced a bug: you tell it which version of your repository was bug-free and it runs a binary search between your current commit and the one that seems to have bug, asking you to confirm on whether the bug seems to be there at each step of the search.

Curious? Let’s see it in action!

Even though I have a physical copy of this book, I never got around finishing it until I bought it on Kindle — power of digital convenience :)

This is a book that was recommended to me by one of my former colleagues, but turned out to be pretty disappointing.

It seems like developers are afraid of using make as they link it to the painful experience of compiling things from scratch — the dreaded ./configure && make && make install.

Part of this fear is due to the description of what make(1) does:

The purpose of the make utility is to determine automatically which pieces of a large program need to be recompiled, and issue the commands to recompile them.

Not everyone is aware that make can be easily used to manage tasks in your projects, so I wanted to share a brief introduction ad how Makefiles help me automate some tasks in my day to day activities: this brief guide will focus on using make as an automation tool for tasks rather than a tool for compiling code.

When you go to your favorite grocery store and the cashier processes your products, he or she will most likely scan them through a barcode scanner which will emit a sound — a sound that’s only there to signal that the scan was successful, and he or she can move onto the next product.

When you develop user interfaces for repetitive tasks, and especially when some sort of scanning is required, it might make a lot of sense to think of giving your users additional feedback so that they don’t have to go back and look at the screen every time they process an action — they can probably simply hear a confirmation sound, or feel an alarming buzz.

Let’s dig a bit deeper.

In the past few months I found myself busier with moving data here and there, so much that scripts ending with load(transform(extract())) have become my bread and butter — sad life, some say!

Last night I wanted to import a bunch of data stored in SQL Server into a MySQL database, but didn’t want to get my hards dirty with a GUI or PowerShell because, well, PowerShell.

The result was mssqldump, a small utility – similar to mysqldump – to export data into TSV.

At the end of last year I decided to try completely removing Facebook from my life: truth to be told, FB does a great job at letting you disconnect by deactivating your account and decide when to come back — so it was an easy experiment.

In this post I’d like to report a few observations 5 months down the line.