DEV Community: Lucas Bleme

A terminal UI for Apple Containers

Lucas Bleme — Wed, 02 Jul 2025 16:22:27 +0000

Apple finally released native support for containers, but it is missing a compatible GUI. I built lazycontainer, a terminal UI to make it easy to manage Apple containers. It is written in Go, and uses bubbletea🧋

https://github.com/andreybleme/lazycontainer

First impression

I have been trying the native apple containers on my Mac for the last weeks, and it looks fast. Docker is one of the few things that makes my M1 feel slow, so I've been experimenting with replacing it with apple containers on my local environment for simple stuff like Postgres and Redis.

It still has significant limitations in terms of networking and memory. It does not support routing traffic from container-managed applications to host applications. To workaround this, we need a port forwarding tool like socat or netcat to establish a TCP connection between the host and the container and redirect the traffic. Not cool.

socat TCP-LISTEN:8000,fork,bind=192.168.64.1 TCP:127.0.0.1:8000

There is no CLI support for managing volumes. Even though it allows running a container with a volume container run --volume, we can't list or remove mounted volumes as we are used to doing with Docker. Same for networks.

The first release also didn't come with support for compose. We are used to relying on docker_compose.yaml files to provision multiple containers, but that is not supported for now. This is one of the most requested features, and would definitely drive more adoption if added in the next release.

It is great to see native containers come to Mac, but lima and colima already enable decent performance for containers running on Mac, and most importantly, being Docker compatible. It is hard to see this announcement as groundbreaking if they don't provide support for most things we are used to having in the Docker ecosystem.

In the meantime, the open source community is hacking to make it compatible with Docker-like tools. Let me know what your thoughts are on it! Are you using it or planning to?

Paper digest of the week: The UNIX Operating System

Lucas Bleme — Tue, 16 Feb 2021 11:40:32 +0000

Hello! This is the first digest of the research papers I've read and written a small summary about.

I will not be posting the digests here, this is just an announcement.

If you'd like to be notified every other week with new paper digests, you can subscribe to the substack newsletter.

#1

The first is “The UNIX Time-Sharing System”, a paper published in 1974 by Dennis Ritchie and Ken Thompson presenting the main aspects of the UNIX Operating System with its file system, I/O operations, process synchronization, and the shell implementation.

https://andreybleme.com/2020-12-17/the-unix-time-sharing-sytem-summary

#2

10 years later Dennis M. Ritchie publishes “The Evolution of the Unix Time-sharing System” describing the UNIX file system, the process-control mechanism, and the idea of pipelined commands. This paper also presents the social events that influenced the system’s evolution.

https://andreybleme.com/2020-12-29/the-evolution-unix-time-sharing-sytem-summary

An interesting fact that you might not be aware of, is that Dennis M. Ritchie is the guy who created the C programming language. In both these papers, you can see his contributions to UNIX, and the moment when the UNIX team decided to rewrite its assembler using Clang.

Don't forget to subscribe if you are interested in more digests like this one!

Inspiration is perishable

Lucas Bleme — Mon, 24 Aug 2020 22:22:14 +0000

As a software developer solving all kinds of problems every day, I have new ideas for side projects quite often. To be honest, most of them are useless and shitty ideas, but sometimes an idea that makes me feel excited pops into my head. Right after this new idea comes, I start to wonder about the big picture: "which database will I use? How should this be called? Where am I going to host it?", and I bet you already know where it ends. Yeah, I wonder about these side things for days/weeks, and I end up doing nothing, zero code.

Looking with more clarity into this recurrent sequence of frustration steps, today I reminded myself about a lesson that I have learned from DHH and Jason Fried's Rework book about inspiration:

"Inspiration is like fresh fruit or milk: it has an expiration date. If you want to do something, you've got to do it now. You can't put it into a shelf and wait two months to get around."

This is such a simple thing, but also very game-changing when you apply in your own life. We quite often get pumped about building something, but we quickly have the bad idea of saying to ourselves that we'll do it later. Don't do it! Later you won't be pumped up about it anymore. If you are inspired on a Friday night to build that thing you want, just jump into the middle of it. Don't waste time thinking about all those things that have to be done around it that does not make you feel excited: do it latter.

Just build it

A few weeks ago, after watching a Hashiconf talk, I got really excited about learning Go. In that same day, I started by taking the Tour of Go, I have read some core stuff that allowed me to proceed in a more smooth way, and boom, in a few days I was able to contribute with a feature for a Golang open source project. It may not sound like a big thing, but well, I don't remember the last time I went from zero to actually doing a real thing I felt inspired about without wondering a lot of things that kept me away from it.

Inspiration is powerful (cliche, but true). People get so much more done when they feel excited about what they are doing when there is inspiration working in our favor. A few hours of inspired work may give you the will you need to accomplish so much more than an entire week of struggling work. Inspiration will not wait for you though. "It's a now thing". Whenever you feel it, grab it, and don't let it expire!

If you liked this post, consider sharing.

What other things you think can help us to get things done?

Building a CLI tool to deploy static websites

Lucas Bleme — Fri, 12 Apr 2019 15:19:54 +0000

Using S3 static content hosting is arguably one of the cheaper and simpler ways to host static web sites. The problem starts when you have to repeatedly create buckets using the AWS console, set static website hosting policies, upload files, and finally make them public all the time. This repetitive process gets even more annoying when we need to upload only a few files specific to a site, rather than all of them.

With this in mind, I searched for some tools that propose to solve some of these problems. I found some, but none of them simple enough focusing on the important tasks: creating the bucket with static hosting policies, and uploading the files. That was when I had the idea to create a simple command-line interface, light and easy to be installed, to manage the deploy of this kind of website in S3.

Here I will present the step by step to create a simple tool to help us deploy static sites using only Nodejs.

If you just want to use the app, you can run in your terminal:

npm install -g theros

Visit https://www.npmjs.com/package/theros to see the complete documentation.

Here is the link with the complete code implementation on Github. Let's go to the code...

Command structure

We want to be able to perform the basic operations we have just described in the terminal using simple commands.

To create a bucket:

theros create --bucket

To deploy all files:

theros deploy --bucket

Theros is the name of our npm package. Don't worry, we will publish it at the end of this post.

The library we are going to use in order to provide these commands is the commander.js.

Having already created the brand new npm project running npm init, we need to install the commander.js by running npm install -s commander. Let's see the basic struct of the two commands (create bucket and deploy):

#!/usr/bin/env node
const program = require('commander')

const awsCredentials = {
  region: 'us-east-1',
  accessKeyId: '',
  secretAccessKey: ''
}

const bucketParams = {
  Bucket : ''
}

program
  .command('create')
  .option('-b, --bucket <s>', 'Bucket name', setBucket)
  .option('-k, --key <s>', 'AWS Key', setKey)
  .option('-s, --secret <s>', 'AWS Secret', setSecret)
  .action(function () {
    console.log('Creating bucket')
  })

program
  .command('deploy')
  .option('-b, --bucket <s>', 'Bucket name', setBucket)
  .option('-k, --key <s>', 'AWS Key', setKey)
  .option('-s, --secret <s>', 'AWS Secret', setSecret)
  .action(function () {
    console.log('Performing deploy')
  })

function setKey(val) {
  awsCredentials.accessKeyId = val
}

function setSecret(val) {
  awsCredentials.secretAccessKey = val
}


function setBucket(val) {
  bucketParams.Bucket = val
}

program.parse(process.argv)

Let's start by understanding the first line: #!/Usr/bin/env node. This line is the one that tells unix-like systems that our file should be run via the command line. Whenever you see this #! (hashbang or shebang), you can assume that it's an executable file. Since our cli.js file will run whenever a user types theros in the command line, we need this line to be at the beginning of out cli.js file.

The .command('create') function is the one that generates the "create" command. The .option('- b, --bucket <s>', 'Bucket name', setBucket) function specifies a parameter that we can use with the "create" command, this parameter can be used as "-bucket" or only "-B". The last parameter of the .option() function accepts another function, which in our case will be executed to capture the parameter value typed by the user: setBucket(val).

The "deploy" command follows exactly the same structure.

The user needs to use its Access Key and Client Secret to authorize our application to create or modify buckets and upload files to its account. You can find these credentials on the AWS console.

Here we are already able to capture the user input for both commands. To test just run in the terminal:

node cli.js create –bucket my_bucket –key my_key –secret my_secret

Creating the bucket

Now we need to effectively use the AWS SDK to perform operations on the user account. To do so, first we need to install the SDK: npm install --save aws-sdk.

Let's create a new s3Services.js file containing the operations: authenticate, create bucket and upload:

const AWS = require('aws-sdk')

function setAwsCredentials(awsCredentials) {
  AWS.config.update(awsCredentials)
}

function createBucket(bucketParams, staticHostParams) {
  const s3 = new AWS.S3()
  s3.createBucket(bucketParams, function(err, data) {
    if (err) {
      console.log('Error creating bucket: ', err)
    } else {
      console.log('Successfully created bucket at ', data.Location)
      setPoliciesForWebSiteHosting(staticHostParams)
    }
  });
}

function setPoliciesForWebSiteHosting(staticHostParams) {
  const s3 = new AWS.S3()
  s3.putBucketWebsite(staticHostParams, function(err, data) {
    if (err) {
      console.log('Error defining policies: ', err)
    } else {
      console.log('Successfully defined static hosting policies.')
    }
  });
}

module.exports = {
  setAwsCredentials,
  createBucket
};

The setAwsCredentials() function updates the credentials of the AWS object.

The createBucket() function creates the bucket with the specified name, and if the operation succeeds, invokes the setPoliciesForWebSiteHosting() function that updates the policies of the existing bucket by configuring the bucket to host static sites.

Let's look at our cli.js file after implementing the call of each bucket creation function:

#!/usr/bin/env node
const program = require('commander')
const s3Services = require('./app/s3Services')

const awsCredentials = {
  region: 'us-east-1',
  accessKeyId: '',
  secretAccessKey: ''
}

const bucketParams = {
  Bucket : ''
}

const staticHostParams = {
  Bucket: '',
  WebsiteConfiguration: {
    ErrorDocument: {
      Key: 'error.html'
    },
    IndexDocument: {
      Suffix: 'index.html'
    },
  }
}

program
  .command('create')
  .option('-b, --bucket <s>', 'Bucket name', setBucket)
  .option('-k, --key <s>', 'AWS Key', setKey)
  .option('-s, --secret <s>', 'AWS Secret', setSecret)
  .action(function () {
    s3Services.setAwsCredentials(awsCredentials)

    staticHostParams.Bucket = bucketParams.Bucket
    s3Services.createBucket(bucketParams, staticHostParams)
  })

// hidden deploy command

function setKey(val) {
  awsCredentials.accessKeyId = val
}

function setSecret(val) {
  awsCredentials.secretAccessKey = val
}

function setBucket(val) {
  bucketParams.Bucket = val
}

program.parse(process.argv)

Deploying the website

Uploading our files involves two distinct steps: first we have to read all the files in the current directory, and after that, upload it using the AWS SDK.

Interacting with the File System

We will use the Node native library, FS, to read recursively and synchronously all the files in the current directory and its subdirectories.

We also need to capture the MIME type of each of these read files so when we upload it, the "content type" field of the file metadata record is correctly filled. When uploading an index.html file for example, the correct "content-type" should be "html". To do so, let's use the node-mime library.

To install it run: npm install --save mime.

Just like we did with the interactions with S3, let's now create a new file containing the files reading operations. We will call it filesystem.js:

const fs = require('fs')
const path = require('path')
const mime = require('mime')

function getAllFilesFrom(currentDirPath, callback) {
  fs.readdirSync(currentDirPath).forEach(function (name) {
    const filePath = path.join(currentDirPath, name)
    const stat = fs.statSync(filePath)

    if (stat.isFile()) {
      fs.readFile(filePath, function (err, data) {
        if (err) {
          throw err
        }
        callback(filePath, data)
      })
    } else if (stat.isDirectory()) {
      getAllFilesFrom(filePath, callback)
    }
  });
}

function getMimeType(filePath) {
  return mime.getType(filePath)
}

module.exports = {
  getAllFilesFrom,
  getMimeType
};

The getAllFilesFrom() function here returns via callback all the files found in the directory specified in the parameter as well its subdirectories. This function verifies if the checked file is actually a file if (stat.isFile()), if true, the function returns via callback the full file path and its content: callback (filePath, data).

If the fetched file is actually a directory else if (stat.isDirectory()), the function is called recursively, so that the files in that subdirectory are also read and returned.

Finally, the getMimeType() function has the simple goal of returning the MIME type corresponding to the given file path.

Performing the upload

Now that we can read the files of a directory and get their paths and types, we can implement in our s3Services.js the function to perform the upload:

const AWS = require('aws-sdk')
const filesystem = require('./filesystem')

function setAwsCredentials(awsCredentials) {
  // updates credentials
}

function createBucket(bucketParams, staticHostParams) {
  // creates bucket
}

function uploadObject(bucket, filePath, data) {
  const s3 = new AWS.S3()
  s3.putObject({
    Bucket: bucket,
    Key: filePath,
    Body: data,
    ACL: 'public-read',
    ContentType: filesystem.getMimeType(filePath)
  }, function(error, dataS3) {
    if (error) {
      return console.log('There was an error uploading your file: ', error.message)
    }
    console.log('Successfully uploaded file: ', filePath)
  });
}

function setPoliciesForWebSiteHosting(staticHostParams) {
  // updates bucket policies
}

module.exports = {
  setAwsCredentials,
  createBucket,
  uploadObject,
};

The uploadObject() function is fairly simple. We call the s3.putObject method containing the bucket name, the file name, body (content in bytes of the file), ACL (access permission), and finally the ContentType.

If the upload fails for some reason we simply return an error message to the user.

Putting all together

Now that we have the code for reading files and uploading, both encapsulated, we can make the calls in our cli.js file:

#!/usr/bin/env node
const program = require('commander')
const s3Services = require('./app/s3Services')
const filesystem = require('./app/filesystem')

const awsCredentials = {
  region: 'us-east-1',
  accessKeyId: '',
  secretAccessKey: ''
}

const bucketParams = {
  Bucket : ''
}

const staticHostParams = {
  Bucket: '',
  WebsiteConfiguration: {
    ErrorDocument: {
      Key: 'error.html'
    },
    IndexDocument: {
      Suffix: 'index.html'
    },
  }
}

// hidden create command

program
  .command('deploy')
  .option('-b, --bucket <s>', 'Bucket name', setBucket)
  .option('-k, --key <s>', 'AWS Key', setKey)
  .option('-s, --secret <s>', 'AWS Secret', setSecret)
  .action(function () {
    s3Services.setAwsCredentials(awsCredentials)

    filesystem.getAllFilesFrom('.', function (filePath, data) {
      s3Services.uploadObject(bucketParams.Bucket, filePath, data)
    })

});

function setKey(val) {
  awsCredentials.accessKeyId = val
}

function setSecret(val) {
  awsCredentials.secretAccessKey = val
}

function setBucket(val) {
  bucketParams.Bucket = val
}

program.parse(process.argv)

For each file read by the filesystem.getAllFilesFrom() function, we upload it using our s3Services.uploadObject() function.

To test the deploy command, just run:

node cli.js deploy –bucket my_bucket –key my_key –secret my_secret

Publishing the package to the NPM repository

Now that we have the two basic functionalities ready, we want to make it available to the world. We'll do this by making our CLI app available as a node package at npm: https://www.npmjs.com/package/theros.

1. The first step is to create an account at https://www.npmjs.com/.

2. Having created your account, we now need to add the account created in the npm installed on the machine we are using. Your email and password will be requested when the following command is executed in the terminal:

npm adduser

3. For the operating system to recognize our package as an application running on the terminal, we need to include the following piece of code at the package.json file:

"bin": {
  "theros": "cli.js"
}

The name of the command that will run our application can be any one, here I chose theros, pointing to the cli.js file.

4. Now we just need to publish the package to our account by running:

npm publish –access=public

If you got an error while trying to publish, make sure the name you chose for the package does not exist in the manager: https://www.npmjs.com/search?q=your_package.

If it already exists, you need to choose another one.

If the errors persist, see here my complete package.json file and make sure you did nothing wrong.

Bonus

There are some cool extra features I have implemented, such as:

Ignoring specific files when using the deploy command by using the --ignore <list_of_files> parameter.
Pointing to some custom directory in order to deploy files stored in a different place by using the --root <directory_path> parameter.

And some improvements we can do, for example:

When creating a new bucket, it might be interesting for users to be able to create a new CloudFront distribution associated with this bucket. It is a very common step every user deploying static websites at AWS needs to perform, it could be easily implemented. Check the Github issue.
Use a configuration file such as a theros.yaml, containing authentication keys, a default root folder and bucket names to avoid the repetition of typing the same things all the time.

Sample file:

default:
  root: 'build/'

production:
  key: 'XXX'
  secret: 'XXX'
  bucket: 'theros.io'

development:
  key: 'XXX'
  secret: 'XXX'
  bucket: 'theros-dev.io'

Check the Github issue.

That's it!

The biggest difficulty I faced when creating this simple application was dealing with files using the filesystem (FS) API. The functions are not intuitive at all, and the documentation of this API is not so good. I know it's not fair to put the blame on the tool, since Node was not originally intended for applications of this nature.

The main benchmark I used was this application called Stout, made by Cloudflare staff. They chose to build a CLI using Go lang, which seems pretty smart to me, since the Go language offers an infinitely richer tool for manipulating files than does Javascript.

Personally I have little experience with Javascript and Node, so be sure to comment if you have any suggestions for some code improvement or ideas for new features :)

Stubbing responses from documented APIs. Worth it?

Lucas Bleme — Mon, 24 Sep 2018 14:31:29 +0000

On the project I currently work, we use swagger for documenting our API. The frontend team use this documentation to create the calls, send the given parameters and so on...

It's a Contract First approach: since we have the contract defined both teams can start working together, since they are respecting the contract.

The problem is: some endpoints returns complex objects, some API calls depends on different frontend data to be sent as headers or parameters. Because of this, frontend developers tend to be blocked waiting for the API endpoint to be ready to be called, because it's impossible to perform the call if the endpoint isn't implemented yet.

One of our collegues suggested us to use some tool that creates enpoints with returned values according to our swagger documentation.

For example: we have in our swagger an endpoint such as

GET /machine?name=foo&type=bar

This tool would read it and then expose an enpoint such as

GET tool.com/45er3z7/machine?name=foo&type=bar

When this endpoint is called, an object with the swagger specification format will be returned.

Do you guys know any tool with this propose? It doesn't need to be open source.

Would be usefull to use such a tool? In our case I do think so.

Some people suggested we coud build a tool to solve it...

Personally I feel like it's a "super engineering" effort.

What are you thoughts on this situation and building a tool for such a pourpose?