One feature that I felt was missing from the “encrypted volumes” implementation was the ability to verify the validity of the encryption keys. After spending some time figuring out how to do this, I decided to document the process to help others who might be facing the same challenge.

Key Validity Check

To verify the validity of an encryption key, follow these steps:

1. Create a Temporary Encrypted Shared Folder: This folder will be deleted after the verification process to ensure no encryption keys remain accessible on the NAS.
2. Upload the Encryption Keys: Place the .rkey files in the new shared folder.
3. Connect to the NAS via SSH: Navigate (cd) to the shared folder.
4. Decode the Key Files: The key files are base64 encoded. Use the following command to decode them:

    find . -name "*.rkey" -exec sh -c 'base64 --decode "$1" > "${1%.*}_decoded.rkey"' sh {} \;
   

5. Check the Validity of Each Key: Use this command to verify each key:

    sudo cryptsetup open --test-passphrase /dev/vgX/volume_X -S 1 -d /volumeY/temp_key_check/XXXX_VolumeX_decoded.rkey -v
   

   Where X is the volume number of the volume you need to check, and volumeY/temp_key_check/XXXX_VolumeX_decoded.rkey is the path to the decoded key. Synology stores the encryption key in slot 1, this is why we specify -S 1 (this is not strictly necessary, without this argument the command would check all slots, if I’m not mistaken).

   • If the key is valid, you will see this in the command output: Key slot 1 unlocked.
   • If the key is incorrect, you will see this instead: No key available with this passphrase.

   In both cases, you will see No usable token is available in the output: this is normal.

   IMPORTANT: This command is non-destructive, and it can safely be used on a mounted volume.

I perform this check quarterly to ensure that I can access my files, even if I need to reset the NAS or move the HDDs to a different unit.

Before starting, I must say that tmux is available from SynoCommunity, in a package called “SynoCli Network Tools”. SynoCommunity is a reputable and trustworthy source, but I decided not to install any unofficial package on my Synology, since I want absolute stability.

The Problem

Modern NAS devices pack considerable computing power, and can have a very decent amount of RAM: they can do much more than storage. I often need to do analysis on big volumes of data, and I prefer to avoid doing it on my laptop (limited storage, heat, etc.). I can connect to the NAS with SSH but, having to rely solely on nohup for long processes, can be pretty limiting. To give you an example, a couple of weeks ago I wanted to move a 5 TB folder to a MinIO server: the simplest way I could find was to use MinIO Client (with the mc cp command). I was going to run the mc cp command from a MinIO Client container, to move data from a shared folder on the NAS to a MinIO Server container.

Since I knew that the process would have taken a couple of days at least, I wanted to avoid having to keep a terminal open and rely on a stable network connection for all that time. I could have possibly run something like nohup mc cp on the client container, but I am uncertain if that is even possible, and I preferred to keep the process running in a shell.

The Solution

My solution is simple: I used a third container—based a basic alpine image—with the addition of tmux and OpenSSH. The idea is to run tmux inside the container, and ssh back to the host. I am no Docker expert, but this is the Dockerfile I used:

FROM alpine:latest
RUN apk add openssh
RUN apk add tmux
# The following command is just to keep the container alive once started
CMD tail -f /dev/null

From the directory containing the Dockerfile, I just did the following:

1. Build the image: docker build -t alpine_tmux .
2. Start a container based on the new image: docker run -d --rm --name tmux alpine_tmux:latest
3. Start a shell: docker exec -it tmux sh
4. SSH into the host: ssh your_username@$(/sbin/ip route|awk '/default/ { print $3 }')¹

If you want to avoid building the image, I have published the one I use (please note that I have added a couple of other tools) to it. The image is on Docker hub, if you want to use it, you can skip point 1, and replace the command at point 2 with: docker run -d --rm --name tmux tagliasteel/tmux_ssh.

Once the work is done, I just stop the container with docker stop tmux, and docker cleans everything up (since the container was created with the --rm option).

Final Thoughts

When I don’t need to run commands on other containers, I prefer to just map the volumes I need (adding -v to the docker run command above), and install everything I need inside the container. I like the alpine image because it’s extremely minimalistic, of course I would choose a more appropriate image if I needed to do something very specific.

Nothing here is particularly complex but, as a docker newbie, it took me a while to come up with this solution. I hope it will be useful to others facing the same issue.

Summary

While I will not go into too much detail, I will outline the entire process, from storing the images and metadata, to creating and deploying the collection smart contract, and everything in between. In particular, I will cover the storage of images and metadata more extensively, since I believe many of the NFT collections are weak on this side.

Here is a list of the topics I will cover:

• Storing information on IPFS;
• Installing a smart contract development environment (I will use Hardhat for this);
• Creating an NFT collection, following the ERC-721 standard, and using OpenZeppelin contracts;
• Deploying the collection to a testnet first, and to the mainnet after;
• Minting images and, finally, using them as a profile photo on Twitter.

Disclaimers

1. In this post I will focus on the Ethereum blockchain only;
2. The main objective here is to get through the entire process relatively quickly; you need some basic understanding of modern development to follow.

1. Storage

I am sure everyone has read something about NFTs (and web3 in general) not being truly decentralized: if not, I recommend you have a look at this famous blog post by Moxie Marlinspike.

One of the main points of concern is that NFTs does not include the content (an image, video, song, or anything), but only a URI pointing to it. The content can very well be stored on someone’s private server. This gives no guarantees that the content will be available in the future, or that it will not be changed.

IPFS

One solution is to use an immutable file storage, like IPFS. Unfortunately, most people don’t understand how IPFS works: while it guarantees that the content will not change, it does not guarantee that it will be online. I can run an IPFS node on my laptop and add files, but the moment my laptop goes offline, those files will not be available anymore. There are pinning services, which can maintain the content online on your behalf: the best known is Pinata, and offers free accounts. This is a better solution, but it does not guarantee that the content will be available indefinitely: Pinata’s users can decide to unpin content from their account at any moment. If they do, there is no guarantee that the content will be available.

We will use a different service, called NFT.Storage. The service is completely free, and leverages Filecoin to keep the content online. If you are curious about how they can keep content online for free, have a look at their FAQ.

2. Development Environment

The development ecosystem for Ethereum smart contracts is quite rich today, both in terms of environments and languages. If you decide to stick with the main language, Solidity, the three main development tools are: Remix, the Truffle Suite, and Hardhat. If you are a beginner, I recommend you try out Remix: there is nothing to install—it runs in the browser—and it includes awesome tutorials (they will be available if you install the LEARNETH plugin, as shown in the screenshot below).

While remix would have been perfect for this task, I decided to use Hardhat. The main reason is that I’m a bit allergic to advanced IDEs and I prefer to do everything in the terminal, using tmux and vim.

To use Hardhat you need Node.js. I will not go through the details of installing it; I will use version 16.16.0 LTS, which I have installed using nvm:

nvm install 16.16
nvm use 16.16

At this point, you can follow the steps from the official Hardhat Guide to install Hardhat and create your project. We are also going to use the hardhat-etherscan plugin, so our smart contract will be verified on Etherscan.

3. Creating the Collection

On the blockchain, an NFT collection is just a Smart Contract. There are two standards suitable for this type of tokens: ERC-721 and ERC-1155. The latter covers advanced use cases, specifically for gaming, so I will use the classic ERC-721. Most of the blue-chip NFT collections are built following this standard as well.

Since this collection will represent me, and my usual name on social media is taglia, I have decided to call it “TagliaMyselves” and to use “TAGLIA” as symbol. Please change these values if you are following the tutorial.

We will start by installing Hardhat and initializing a project inside an empty folder:

mkdir taglia_myselves
cd taglia_myselves
npm install --save-dev hardhat

This will install Hardhat and all of its dependencies. At this point, we need to initialize the project, and we do this by simply running npx hardhat (which will prepare an appropriate folder structure). We will create a simple JavaScript project:

We will choose the defaults for all the other points.

Now, your directory should look like so:

README.md         contracts         hardhat.config.js node_modules      package-lock.json package.json      scripts           test

We will focus on three key components:

1. hardhat.config.js: this is the configuration file, where we specify the Hardhat plugins that we will use, and the networks that we will use for deployment;
2. The smart contract itself, which we will generate using OpenZeppelin’s wizard, and which will be stored in the contracts directory;
3. The deployment script, scripts/deploy.js.

I have changed my configuration file, hardhat.config.js, like so:

require("@nomicfoundation/hardhat-toolbox");
require("@nomiclabs/hardhat-etherscan");

/** @type import('hardhat/config').HardhatUserConfig */
module.exports = {
  solidity: "0.8.9",
  paths: {                         // add this
    artifacts: './src/artifacts',  // this is where our compiled contracts will go
  },
  networks: {
    hardhat: {
      chainId: 1337,
    },
    mainnet: {
      url: "YOUR INFURA MAINNET ENDPOINT",
      accounts: [
        "YOUR WALLET PRIVATE KEY"
      ],
    },
    ropsten: {
      url: "YOUR INFURA ROPSTEN ENDPOINT",
      accounts: [
        "YOUR WALLET PRIVATE KEY"
      ],
    },
  },
  etherscan: {
    apiKey: "YOUR_ETHERSCAN_API_KEY"
  },
};

A couple of things to note:

1. I have added the hardhat-ehterscan plugin: this allows me to verify the smart contract very simply. A verified smart contract has a green checkmark on Etherscan, and its source code is visible by everyone; this plugin needs to be installed, by issuing this command: npm install --save-dev @nomiclabs/hardhat-etherscan.
2. I have added the Etherscan API key, so the plugin can work (you need to create an account on Etherscan, and copy your API key for this to work).
3. I have added three networks:
   1. hardhat: this is a development network, created by Hardhat itself, and running locally;
   2. ropsten: a public testnet¹. You have to add your wallet’s private key here (more on this later);
   3. mainnet: the main Ethereum blockchain.
4. I am not running a full Ethereum node on my laptop, for simplicity I decided to use Infura for this. All you need to do is to create a free account on Infura, create a project of type Ethereum, copy the endpoints for Ropsten and Mainnet, and paste them into your configuration file.

3.1 Creating the Smart Contract

Solidity development is not in the scope of this tutorial, so for this exercise we will use OpenZeppelin’s Wizard. This is the way I have configured my contract:

Let’s go through the configuration step by step:

• Contract Type: As you can see from the selected tab, at the top, I have chosen ERC-721, as discussed earlier in this post;
• Settings:
  • Name and Symbol are quite obvious;
  • Base URI is essential, and I will go a bit deeper. In an NFT collection, each token has a URI which points to its metadata (the location of the image is specified inside the metadata); this token URI is built by concatenating the base URI with the token ID. So, assuming we are minting token 19, its token URI will simply be the collection’s base URI with “19” appended. This is usually done by creating a directory, and storing the metadata JSON file for each token inside it, appropriately named. Since IPFS is an immutable file system, the Content ID (CID) of a directory will change every time its content changes. So, this approach is only valid if we can create all the NFT images and metadata before we create the smart contract. If we upload everything at the same time, we will get a single CID for the directory containing the metadata. I want to be able to add new images at any time, so I can’t use this approach. One could argue that I could get a constant directory URI by using IPNS, but in that case, I must forego immutability. I will always be able to change the content of existing tokens in the future, and this goes against the concept of NFT in my opinion. By leaving the base URI empty, we will be able to set a different URI for each token.
• Features:
  • Mintable: I want to be able to mint new tokens whenever I intend to use a different photo, and I would rather avoid manually assigning a token ID every time.
  • Enumerable: This increases the gas cost, and is useful if you are creating a collection that you wish to trade. I have not enabled this, since this collection is for my personal use only.
  • URI Storage: This is required, since we are not using the Base URI option. We will be able to set a specific URI for every token, when it is minted.
  • Other features: I invite you to read more about the various features.
• Access Control: I have chosen the simple model, Ownable, since I am the only one interacting with the contract and I do not need roles.
• Upgradeability: I don’t need the ability to upgrade the contract in the future.
• Info: This section is quite self-explanatory.

Note: the wizard does not include a way to limit the number of minted tokens. I don’t need that, but if you do, you need to modify the safeMint function to take that into account.

As you can see, the smart contract is simple, and we can use it straight away. Please customize the various elements to your liking (YOUR@EMAIL.HERE, CollectionContractName, YOUR_TOKEN_NAME, YOUR_TOKEN_SYMBOL).

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.9;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/utils/Counters.sol";

/// @custom:security-contact YOUR@EMAIL.HERE
contract CollectionContractName is ERC721, ERC721URIStorage, Ownable {
    using Counters for Counters.Counter;

    Counters.Counter private _tokenIdCounter;

    constructor() ERC721("YOUR_TOKEN_NAME", "YOUR_TOKEN_SYMBOL") {}

    function safeMint(address to, string memory uri) public onlyOwner {
        uint256 tokenId = _tokenIdCounter.current();
        _tokenIdCounter.increment();
        _safeMint(to, tokenId);
        _setTokenURI(tokenId, uri);
    }

    // The following functions are overrides required by Solidity.

    function _burn(uint256 tokenId) internal override(ERC721, ERC721URIStorage) {
        super._burn(tokenId);
    }

    function tokenURI(uint256 tokenId)
        public
        view
        override(ERC721, ERC721URIStorage)
        returns (string memory)
    {
        return super.tokenURI(tokenId);
    }
}

I have stored this code in a new contract file, called contracts/TagliaMyselves.sol. You should name this file according to your contract name.

Of course, we need to install the OpenZeppelin contracts in our project, like so:

npm install @openzeppelin/contracts

Note: You might have to update the pragma solidity like in your smart contract, if that is different from the version you have installed. In my case, the wizard generated it with ^0.8.4, and I changed it to ^0.8.9. You can check which version hardhat installed by looking at the demo contract that it created (contracts/Lock.sol).

3.2 Creating the deployment scripts

Although I want to store this contract on my hardware wallet, for simplicity I will deploy it using a software wallet, and transfer the ownership later. This is the deployment script, please customize the contract and file names according to how you named your smart contract.

scripts/deploy.js

const hre = require("hardhat");

async function main() {
  const TagliaMyselves = await hre.ethers.getContractFactory("TagliaMyselves");
  const taglia_myselves = await TagliaMyselves.deploy();

  await taglia_myselves.deployed();

  console.log("TagliaMyselves deployed at:", taglia_myselves.address);
}

// We recommend this pattern to be able to use async/await everywhere
// and properly handle errors.
main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

Please update these files using the contract name and file name that you used above.

4. Deployment

We will do a quick test, deploying locally, followed by deploying on the testnet, and finally on mainnet.

4.1 Local deployment

To deploy locally, we need to start a node which will simulate a full Ethereum node. Hardhat makes this simple, you just have to run this command:

npx hardhat node

This will create 20 accounts, with 10,000 ETH each. The output of the command is clear, but please NEVER use those private keys on anything which is not running locally. At this point, we can deploy with this command (you need to use another terminal window or tab; I use tmux which makes all this effortless):

npx hardhat run scripts/deploy.js --network hardhat

> TagliaMyselves deployed at: 0x5FbDB2315678afecb367f032d93F642f64180aa3

The deployment should be successful. If it is, you will see the contract address. If you like, you can interact with your contract by using the console: npx hardhat console. Kindly note that not everything will work on this simulated node.

4.2 Ropsten

As next step, we will deploy onto the Ropsten testnet, and try the safeMint function. There are a couple of steps here that I did not mention earlier. I will use Metamask: once you have installed the extension in your browser and configured it, you need to switch to the Ropsten network. You can follow this video to do that:

Your wallet will initially be empty; you can get some ETH using a faucet. You can just search for “ropsten faucet” and pick one of the results; the last one I used is Ropsten testnet faucet, and I believe it sends you 1 ETH every day.

To deploy a smart contract, you need to sign a transaction, and for that you must use your account’s private key. You should add the key to your hardhat.config.js file, in the Ropsten section, under accounts. Please see above in this post, where I have added the content of the file. In Metamask, you can get your private key by clicking on the three vertical dots next to your account name, and selecting “Account details”. Please be very prudent when handling private keys, and never share them if you are dealing with the mainnet.

Now, to deploy, you need to use this command:

npx hardhat run scripts/deploy.js --network ropsten

> TagliaMyselves deployed at: 0xfB4268c4Bc79eCF5567581f6b0Eaf918dc018c95

This will contact Infura and deploy your contract on the Ropsten network. If you go to Etherscan on Ropsten and enter your contract address, you will already see it. The contract is not verified, though, which makes interacting with it more difficult. Hardhat simplifies the contract verification. If you followed the tutorial from the beginning, you should have your Etherscan API key in the Hardhat configuration file, and you should have installed the appropriate plugin. You can verify the contract with just one command:

npx hardhat verify --network ropsten 0xfB4268c4Bc79eCF5567581f6b0Eaf918dc018c95 # <- Replace this with the address of your contract

> Nothing to compile
> Successfully submitted source code for contract
> contracts/TagliaMyselves.sol:TagliaMyselves at 0xfB4268c4Bc79eCF5567581f6b0Eaf918dc018c95
> for verification on the block explorer. Waiting for verification result...

> Successfully verified contract TagliaMyselves on Etherscan.
> https://ropsten.etherscan.io/address/0xfB4268c4Bc79eCF5567581f6b0Eaf918dc018c95#code

Of course, you need to use your smart contract address, which you got when you deployed. If you reload your contract page on Etherscan now, you will see the source code (in the Contract tab), and you will be able to interact with it. This is very convenient, and spares me from having to write an app to interact with the contract. Let’s try to mint our first test token:

1. On Etherscan, click on the “Contract” tab (which now has a green checkmark, since the contract is verified);
2. Go to the “Write Contract” section;
3. Click on the “Connect to Web3” button, and connect it to your Metamask;
4. Expand the “safeMint” function, add your wallet address as the to argument, and whatever you want as uri (we will use something sensible on mainnet, no need to worry for now);
5. Click on “Write”.

At this point, Metamask will ask you to approve the transaction. This is a regular transaction, and it writes data to the blockchain; as such, it requires gas. If you followed the instructions earlier, and got some ETH from the faucet, everything should work once you approve the transaction in Metamask. This is the first token minted, so it has ID 0 (zero). If you go to the “Read Contract” section, on Etherscan, you can verify that token 0 has the URI that you set (use the tokenURI function, and set tokenId to 0). You can mint other tokens and play around with the contract.

We are finally ready to deploy to mainnet!

4.3 Mainnet

The process of deploying on mainnet is the same as it was on testnet; we just indicate the correct network.

npx hardhat run scripts/deploy.js --network mainnet

Again, after deploying the contract, we will verify it as we did earlier on Ropsten.

There is just one missing component before I can finally mint my photo: the metadata.

5. Metadata

NFT metadata are stored in a JSON file, and the URI of a token will point to this file. The file has some standard properties that all marketplaces and other actors (Metamask, Twitter, etc.) can read. I will just use some basic properties, since I do not intend to trade these tokens, and I do not care about anyone calculating the rarity, or showing each token’s traits.

This is the metadata I will attach to my first token:

{
  "name": "Cesare Tagliaferri",
  "description": "Portrait photo",
  "image": "ipfs://bafkreihxigpbhmaxkmsyxkssfxhsrod5dqaspj7ma6nmwmp2ycvlsam2gm"
}

The ipfs:// URI corresponding to the image key, is what I got from nft.storage when I uploaded my photo. I used their application, called “NFT UP”, which is super simple to use.

Once I have saved the JSON object into a file, I can upload it to IPFS too, using NFT Storage again.

6. Minting a token with my photo and using it on Twitter

Now we have all the components ready. We just need to mint one token on mainnet, using the IPFS URI pointing to the metadata. Once this is done, you will immediately see your token using the mobile version of Metamask, or if you log into any marketplace with the wallet where you stored the minted token. Every service uses some APIs to read the token’s metadata, so you will have to wait for a while before you see your image on a marketplace, or before Twitter accepts it as profile photo.

Conclusion

While not planned, this ended up being a very long post! I hope it will help someone else, definitely I learned a lot while writing it. And now, let me show off my Twitter profile.

Earlier this week, I had the pleasure of recording a session for the Fintech Forum, representing Mintable.

It is an interesting conversation about NFTs, a bit more technical than what you usually find on this subject. We cover the technical challenges of building NFTs (including how to start and what tools to use), and the challenges of building an NFT marketplace.

The event—hosted by Tech in Asia and AWS—is on July 7, 2022, and is free. You can register here. If I can, I will post the session after the event.

For some time, I have been using an external Bluetooth device (Jabra Speak 710), which has a dedicated mute button. This is convenient since I had the same control for all software platforms and a clear visual cue about the state of the microphone (Jabra shows a ring of red LED lights around the speaker if the microphone is muted). On the negative side, this adds friction since I have to remember to switch on the Jabra and to check that the conferencing platform is using the correct input/output channels. My webcam has a decent microphone, and my screen has excellent speakers (way better than Jabra’s). Also, I don’t have to remember to switch something on before the meeting, and I can simply join.

To get the same “universal mute” functionality that I had with Jabra, I decided to use Keyboard Maestro and my Stream Deck¹. This solution gives me the same universal mute button, including the visual cue. I don’t have the visual indication if using my laptop away from my desk, but that happens rarely, and it’s not a significant inconvenience. This solution also allows me to instantly mute the microphone, independently from what I am doing.

Here is a brief explanation of how I set this up. The only required external component is Keyboard Maestro. It should be possible to use Shortcuts, but I used Keyboard Maestro because I wanted to control the entire workflow with one button on the Stream Deck.

Keyboard Maestro Macros

I use two macros:

1. Mic - Toggle Microphone²: Toggles the microphone on and off;
2. Mic - Update Stream Deck button: Updates the Stream Deck button every minute—so the status is correct even if the volume is changed by other apps or using the system controls³.

If you don’t have a Stream Deck, you can just use the first macro. You need to delete the last step, which calls the other macro to update the Stream Deck button.

You can download the macros here.

For the Stream Deck icons, I have used SF Symbols and the very good Button Creator for Stream Deck on the Mac App Store.

I also use a keyboard shortcut to trigger the microphone, which is useful when using the laptop away from my desk⁴.

Stream Deck configuration

On the Stream Deck, I use the official Keyboard Maestro Plugin since I want to update the icon and the title of the button. The button I use is R4C6 on the Stream Deck: I have assigned it a custom ID, so my macros would still work if I decide to use a different button. As shown in the screenshot below, the ID used in the macros is MIC.

I hope you find this useful!

I will make another attempt to post more regularly, targeting a post every month. My interests have also shifted a bit during the past few years; you can expect posts on the following topics:

• Productivity (I went back to OmniFocus, in case you wonder);
• Privacy and Security;
• 3D printing.

We are the problem…

The main issue with privacy is rooted in our mindset: most people don’t have any understanding of the risks and implications of using connected tools and services. There are big powers at play, and the vast majority of users don’t even realize that they’re valuable targets. Whenever I talk on the importance of using strong passwords, different on each app and website, most people just roll their eyes.

Almost no one realizes that there has been a significant shift in the world of cyber-security. On one side you have what we see in the movies, where the smart hacker will bypass all defenses and firewalls of any government agency or military base, within seconds. And, on the other hand, you have the real world, where some lazy fraudsters will buy a script from a hacker and exploit tens of thousands of vulnerable devices around the world. Most people are only familiar with the first case and don’t realize that they are likely already victims of the second. Everyone is a target, as long as they have essential files, a computer (or any device with some computing power such as a router), a bank account, or a credit card.

When was the last time you updated your home router’s firmware? Do you know that search engines are continually indexing vulnerable devices? You could, for example, look for all Synology Disk Stations with a guest account enabled, all vulnerable MicroTik routers, all open or hackable webcams, just about anything. Do you think this is difficult to do in real life? In the video below, in less than a minute, I log into some random person’s Netgear router. From there I could very quickly jump into their home network, get their private files, intercept all the network traffic, install ransomware or crypto-mining software, even switch off their home’s Wi-Fi and lock them out of their own router. A small piece of advice: log into your router, switch off UPnP (Universal Plug and Play), change the password, and enable automatic firmware updates.

A quick snapshot of me getting into a router a million miles away

Just consider that a newly found zero-day vulnerability can be worth millions on the black market, while it is only worth a fraction of that if it’s responsibly disclosed. A weakness on a consumer router won’t be used to hack into a foreign government, but it will be used to exploit as many unaware people as possible.

…and also the solution

Our responsibility as technologists is to raise the level of awareness and start spreading safe privacy behaviors around us. If we do this in the workplace, our employees will then bring good habits home to their families and friends. At TSC, even though we are still considered a startup, we have mandatory periodic security training, monthly phishing tests, enforce the use of two-factor authentication, and provide all employees with a password manager not only for their work passwords but also for their private ones. We also offer a VPN for people who travel or like to work in public places. We have seen a massive transformation in the way our people behave in their everyday life, and at the same time, the attack surface of our company has shrunk considerably.

I, personally, have not used Google search in years, and find that DuckDuckGo provides excellent search results without harvesting my data. I also use content blockers on all my browsers and devices, do not allow my email clients to download images or other remote resources, and route all my web traffic through a VPN. While it might seem extreme to some, these are the steps I chose to take to protect my personal data.

In reality, we trade our privacy for convenience every time we do a Google search. I encourage everyone to take an honest look at their own privacy posture and make informed choices about how much personal data they are willing to share with the world.

I have originally posted this article on TSC’s website, but I thought it would be relevant for OSOMac’s readers as well.

I have originally posted this article on TSC’s website, but I thought it would be relevant for OSOMac’s readers as well.

I want to work with people who love technology and development

Before getting into the technical reasons which make Elixir a great choice, I want to address the very first concern everybody raises. Where do we find people with the right technical experience and skill when most developers haven’t even heard of this language? Indirectly, this is the first test in an interview: if somebody has not heard of some new technology, it might mean that development is just a job for them, and I do not want them on my team. Business is going well, so we are happy to invest the time to allow a new hire to learn something new, as long as we get passion and commitment in exchange. At TSC, we want things done correctly, and would rather have a deadline missed than accumulate technical debt.

I am proud to say that we have world-class Elixir developers on our team, and none of them had previously used the language in a professional context before joining our team. Now they interact with the creators of the language and contribute to Open Source projects. Not only that, but they have fun and enjoy what they are doing.

We plan to start hosting Elixir meetups at TSC soon, with the goal of helping to make this technology more mainstream.

Functional Programming is the way to go

Even though this programming paradigm is not taught enough in Computer Science schools—which seem to be unable to move on from Object-Oriented Languages such as Java—the added robustness and scalability are too important to be disregarded. What seduced me years ago was the concept of immutability: it is so simple, yet it solves most of the issues related to concurrency and multi-threaded applications. Welcome to a world where Mutexes, Semaphores, and blocking code are things of the past.

The functional style also leads to simpler and more reusable code. This means not ending up with the thousands–of–lines–long procedures of Imperative languages, or unreadable class structures typical of Object-Oriented languages (which technically are sub-types of Imperative Programming).

Elixir has rock-solid foundations

First, Elixir was created by the same people who created Ruby on Rails. It maintains a lot of the cool concepts of Ruby while pushing towards a purely functional style. Secondly, Elixir is based on Erlang, which is arguably the most scalable and robust stack existing today. Erlang does not need introductions; it has been used in mission-critical applications for decades and shines for its massive scalability and robustness. Threads crash and hang, but this is part of the design of Erlang, which makes small bugs and software instabilities something that can be handled at runtime.

Elixir repaints Erlang with a modern syntactical structure, greatly improving readability and productivity. On top of Elixir, the Phoenix Framework incarnates the best concepts of modern frameworks, taking many ideas from Rails, without the dogmatism into which Rails seems to have fallen lately.

Last but not least, the tools available for Elixir & Phoenix are impressive for such young technologies. This is incredibly helpful for increased productivity and is still very lean.

Conclusion

In May 2017 we started a complete rewrite of TSC’s main product, Atium, which was previously written in PHP. Before year end, we had our first clients live on the new stack. Within the first half of 2018, all of our existing clients were migrated to the new product. We have not had any unplanned downtime since the system went live. Atium is a very complex system: the short time it took to our small team to build the platform, and the resilience of the end-product are proof of the dependability of the technology stack we have chosen. Stay tuned for future posts on our architecture and security design.

As already said last week, I decided to migrate OSOMac to a new architecture. Over last weekend I had some time on my hands, and I started. The migration went smoothly, and as far as I can see, most things should work.

So, OSOMac is not running on WordPress anymore, and is now entirely static, hosted on AWS S3, and cached all over the world by AWS CloudFront. Thanks to CodeShip I only need to push an update to a specific GitHub repo, and the site is automatically deployed. There are plenty of posts on how to move from WordPress to Jekyll, but if you are interested in more details of my own experience, feel free to ask in the comments (which hopefully works with Disqus), or use the contact form.

This new concept is by no means a completed work; I will retouch the design and hopefully write a bit more often.

All the old permalinks should work as usual, but I did not go through all the old posts and fix the various WordPress shortcodes, so some images are missing, and some text is poorly formatted. I doubt I will ever have the time to fix that. However, if you need something that you can’t find, let me know.

Oh, I have left a link to the descriptions of my old apps, but I will leave it to the reader to find it (and if you have old links they should still work). Also, all the download links for HandBrakeBatch should still work, just much faster.

Atom feed

The Atom feed for the website changes from /feed/ to /feed.xml. This should be managed transparently by most RSS clients, if not, please change it manually.

• I do not like the design anymore: my taste has considerably changed since I had chosen the current theme, as the general design trends;
• The current structure does not reflect well the primary purpose of the site: this was supposed to be a platform to showcase my creations, but now I have the chance of coding for work;
• WordPress is an overkill for my needs;
• I fell in love with Jekyll and static websites: Jekyll is a work of art, and the speed and security of a static site are unattainable with any back-end.

I already run two Jekyll websites, for the two companies of which I'm CTO:  I know what is going on at any steps of the chain, without having to rely on any back-end code (that I did not write) to do some magic. On top of that, with a simple CI/CD setup, I can update the sites from my phone in minutes.

So, here is the plan:

1. Prepare a new, plain and minimalistic design;
2. Migrate from WordPress (which I'm hosting on a DigitalOcean droplet) to Jekyll;
3. Start writing again: not often, but whenever I have something to say.

Timeframe? Days, maybe weeks, but not months.