DEV Community: merlos

Agent orchestration. The end of coding as we know.

merlos — Thu, 26 Feb 2026 01:45:31 +0000

Are we doomed or it's the best time to be a software developer?

These days, if you don't mention AI in your writing, you risk appearing obsolete. Software engineering is currently undergoing a profound paradigm shift—one that may see traditional engineering disappear in favor of what can be called Code Agent Orchestration.

The Rise of the AI Agent

You have likely heard of OpenClaw, an open-source personal assistant that has gained massive traction on GitHub. Its creator was recently hired by OpenAI.

While the product itself is interesting, its tagline is what truly resonates: "An agent that actually does things." What I find most enlightening is how it was developed. In a recent interview on the Max Friedman podcast, Peter Steinberger, the creator of OpenClaw explained his development process.

Essentially, to evolve the product, he engages in a conversation with a coding AI (using tools like Claude Code or CodeX). Indeed he does this with several in parallel. And these agents are the ones actually writing the code in the repository.

From Code Snippets to Repo Access

Steinberger explains in the podcast how he leveraged AI agents to generate the code. And the key change is the agentic nature of the LLM—the ability of the AI to work directly on the codebase.

In the "early days" (only a year or two ago!), the workflow was incredibly high-friction. To get anything done with ChatGPT, you had to follow a manual loop:

Prompt: Provide a detailed spec in a chat window.
Wait: Watch the code chunk generate line-by-line.
Manual Labor: Copy-paste the code into your IDE.
Debug: Copy-paste the error back to the chat if it failed and repeat.

This process was clunky and fragmented.

Now, the code agent removes the "middle-human" for these repetitive tasks, allowing the AI to work directly on the codebase. It can:

Read the existing architecture.
Modify source files directly.
Write and run tests to verify the changes.
Fix runtime problems before finishing the task.

This is further enabled by increased context windows. Where early models could only "remember" a few hundred lines of code, modern models can hold entire relatively large codebases in memory, allowing the agent to understand complex dependencies across a large project.

Because it can take some time for an agent to complete a task, to be more productive, Steinberger was launching several agents in parallel. For instance, while one was completing a complex refactor, he was discussing the architectural approach of a new feature with another. Indeed, he achieved such level of proficiency that he confessed he had to purchase several accounts because he run out of credits.

Peter Steinberger also confesses that he no longer reviews every line of code; he focuses only on critical components. His rationale is that most code is "boring"—simply moving data from one place to another or transforming between formats. Newer models are now proficient enough to handle these tasks autonomously.

The Death of Language Barriers

Another interesting shift is that you no longer need to be "proficient" in a specific language to build with it. Most programming languages share common concepts: variables, loops, and conditions. While the syntax varies—semicolons here, indentation there—the logic remains similar.

Historically, the real barrier was learning the libraries and ecosystems. This is what separated a senior developer from a newbie. However, LLMs have "read" all the documentation. This enables a frontend developer who knows JavaScript to suddenly write a Python backend, a native iOS app in Swift, or even C++ for an IoT microcontroller.

Language is no longer the barrier, but your skill to instruct the agent to write what you need.

The Future: Creative Destruction

We are at the "steam engine" moment of software development. This is a period of creative destruction. How may this affect our industry?

At the Individual Level

A developer might see the glass as half-empty: years of skill-building are being devalued as LLMs do the job faster and cheaper. However, the glass is also half-full: these tools provide superpowers. You can now build ideas in weeks that previously required a full team and months of effort.

At the Market Level:

TheseWe can expect software development costs to plummet. Here is how I believe this shift will affect the industry:

Layoffs and Salaries: We can expect a market correction. As a single developer becomes as productive as five, the demand for traditional "junior" roles may decrease. Additionally, the barriers to entry will lower; as more people enter the market, we may see a downward trend in average salaries.
SaaS Competition: Established enterprise software giants will face a "mushrooming" of new competitors who can offer the same core features at a fraction of the price. In an even more saturated market, strategies to make your product shine among the others.
Commoditization of Development: Small to medium companies that previously relied on off-the-shelf SaaS or complex enterprise systems may now choose to build custom, in-house tools. While custom software can be perfectly integrated into a company's specific processes, enterprise software often requires the company to adapt to the tool—cluttering the experience with unnecessary features and a steeper learning curve.

A Paradox of Creativity

There is a strange paradox in this revolution. We once imagined technology would automate "blue-collar" labor—cleaning floors or filing invoices—to free humans for the "white-collar" joy of writing, drawing, and coding.

Instead, we are seeing a world where generative AI targets the tasks we find most intellectually rewarding, while humans are still required for the physical labor.

I love coding. Even after 20 years, I still find it magical to see logic come to life on a screen. However, I’ve been playing with this "mini-army" of agentic minions lately, and it is transformative.

While agentic workflows might commoditize the syntax, they amplify the vision. We aren't losing the craft; we are evolving into Code Agent Orchestrators. The ceiling for what a single developer can build has just been shattered. What a time to be alive.

Are you ready to lead the orchestra?

ChatGPT bot with your own data

merlos — Sat, 25 Mar 2023 07:33:25 +0000

In this article I will explain how you can build a simple custom bot based on ChatGPT API that will answer questions based on a custom knowledge base.

As we know, ChatGPT and other Large Language Models (LLM) have been trained with the materials publicly available on the Internet. In particular ChatGPT knowledge base only covers till 2021.

In addition, it is also well known that the internet is just the tip of the iceberg, and there is a lot of content, the deep web, that is not publicly available and resides behind intranets, require to login or are so specific that ChatGPT may not reach that knowledge level.

So, the question is:

Can we create a ChatGPT like bot that provides answers based on our small piece of deep web or with a very specific content custom made knowledge base?

Yes, and it is fairly simple.

Here is what you'll achieve after following this tutorial. In this case I tested it with the contents of my personal webpage.

Cool, isn't it?

So, What's the process you need to follow?

Gather the base of knowledge you want to use for your bot. For example, a set of webpages PDF, markdown, word files, etc. Create the corpus with the content that has the answers to the questions.
Convert the corpus plain text files. Convert those files into plain text. We need this step because the model that generates the answer needs plain text as input.
Create a set of embeddings. Embeddings is a way to translate information into a vector format to perform a semantic search. In our case the embeddings are used to find the documents that most probably have the information that can be used to generate the answer to our question. To create the embeddings the text files will be broken in chunks and we will call an OpenAI API to create embeddings for each chunk.

What do I need?

You only have a couple of pre-requisites:

1) A box with python (tested with 3.9 and 3.11)
2) OpenAI account, and an API key. You get some USD of free credits for testing.

The free credits should be enough even for a relatively large knowledge base.

The code that we will use on this tutorial uses GPT3.5turbo model, which is the version prior to GPT4. It's API is compatible with GPT4 API. So, if you get access to it, you just need to change the model.

In addition, some basic python knowledge may help you to customize the code.

Let's bot it!

First, clone the repo and install the dependencies:

git clone https://github.com/merlos/ask-me/
cd ask-me
pip install -r requirements.txt

If you haven't done it yet, create the OpenAi account and get an API key. Then, set this environment variable within the command prompt:

# OSX and GNU/Linux
export OPENAI_API_KEY=<your key>

# Windows
setenv OPENAI_API_KEY=<your key>

Collect your knowledge base

The goal of this step is to gather the data that will be used as corpus and convert each file it into a plain text file.

Although the repo comes with a few basic tools, depending on your particular use case and you may need to do some additional work for gathering and converting the content.

In any case, I would start with a small dataset to test the answers and play around.

Also note, that these large language models are optimized for ingesting text, so formats such has data tables won't provide good results.

The repo comes with a few tools that may be useful.

The first one is scrapper.py. It takes as argument a webpage address and goes through all the pages that are within the domain. For example:

python scrapper.py https://www.merlos.org

As output, it will create the folder ./text/www.merlos.org/ with the scrapped pages in text format. The scrapper is not the best in the world, so it may have small glitches. The source code is pretty well explained.

For more corporate environments. Another tool provided is is DownloadSharePointDocs.ps1 This is a PowerShell script downloads the files from a SharePoint library.

# In a powershell prompt
.\DownloadSharePointDocuments.ps1 \
    -SiteUrl "https://<tenant name>.sharepoint.com/sites/yoursite/" 
    -LibraryName "Library"
    -DownloadFolder "./LibraryDocuments"

Note that DownloadFolder must exist. The script downloads the required powershell modules.

To run it on a GNU/Linux or a Mac you need to install PowerShell (f.i brew install pwsh). On windows you need to run it as Administrator if you don't have the modules required.

The last helper that is provided is pdftotext.py. This script takes a folder with a set of PDFs and converts them into txt files. You can download or collect PDFs, leave them in a folder and this script will convert them into plain text.

python pdftotext ./path/with/pdfs --output ./text/filesfolder/

For other types of documents such as word documents or slide deck presentations, you may need to find some other tools to convert them into plain txt files. The only requirement for the next step is to place all the documents converted into plain text, in a folder for the next step.

You can leave in the comments any other tool that you have used for gathering the data.

Process the data.

Now, you have a folder full of plain text files that will be your corpus. The next step is to break down these files in smaller chunks of text, and include something called embeddings.

We break down the files in small chunks because the OpenAI API has a limit on the amount of text it can process in one single call.

The creation of embeddings is a technique widely used in natural language processing (NLP) and will help us to do a semantic search.

To get the embeddings run the following script indicating what is the source folder with the text files from the previous step.

python process.py ./text/www.merlos.org

This script will output the files:

processed/corpus.csv, which is just a list of the txt files in one single csv files, and
processed/embeddings.csv that includes the embeddings.

This step is relatively slow, consequently you may prefer start with a small subset of docs for testing.

During the implementation it was noticed that the reliability of OpenAPI was poor (maybe because I was in the free tier?). It returned errors in many occasions. If there is an error, you can relaunch the script and it will recover the session.

If you have a large corpus you can use this loop that will relaunch the script automatically.

until python process.py ./text/folder-with-txt-files; do echo "Restarting...";done

You have some additional documentation about this on the README file of the repo.

Test it

Ok, now it's time for the coolest part. We have the corpus with the embeddings that is everything we need.

You can test it in the command line.

python ask.py "this is my question?"

Or you can do the same launching a browser

python web.py

And open the browser at http://localhost:5000

What happens behind the scenes when you ask a question?

The first thing that will be done is to try to find the chunks of text that most probably have the answer to the question. To search that text we will use the embeddings we calculated on the processing step.

An embeddings is just a way to represent a word - or strictly speaking a token - in a vector format. Therefore, instead of having the word king or queen, you will have a vectors, for instance, (1,1,1) and (1,1.4,1), but witch a lot more of dimensions. The values on the different dimensions will depend on how "close" they are. In the example, king and queen will be close because they are semantically related.

When we pose the question, there is an algorithm that is run on the server that searches in the local dataset for the chunks of texts whose content have the closest embeddings to the question and, therefore, are more likely to have the answer to the question.

Once we have the chunks of texts that most likely have the answer, we will send those chunks of texts (the context) together with the question and we will will literally ask ChatGPT to provide an answer based on the text provided, similarly to a prompt that you would provide in the ChatGPT website. This is what is sent the API:

Based on the following context:
   {context}
answer the following question:
   {question}

Where {context} are replaced with the chunks of text found and the question is the {question} provided by the user.

Hack the code

The source code of the repo is pretty straight forward and, even if you don't have much python knowledge you should be able to follow it.

Alternatively, you can paste the code into ChatGPT and ask it to do the changes on your behalf :).

Last words

Definitely large language models and Generative AI are going to change the way we learn, work and find information.

However, right now only big tech companies like OpenAI (aka CloseAI), Google with Bart, or Facebook with LlaMa, seem to have the capacity to release these kind of models, but my hope is that either soon computing these models will be accessible to anyone or that some organization will release a truly open model similarly to what happened in the image field with Stable Diffusion. That will foster innovation and will make these technologies available even in countries and organizations with less resources.

Original Iceberg image: https://en.wikipedia.org/wiki/File:Iceberg.jpg

How to setup Metasploitable in a Mac with M1 chip

merlos — Wed, 30 Nov 2022 20:30:44 +0000

Intro

Metasploitable is a virtual machine image that includes lots of vulnerabilities (on purpose) and that can be used to learn how to hack into a machine.

There are two virtual machines for Metasploitable (v3):
1) Ubuntu 14.04
2) Windows 2008 server

Whereas I was able to setup the Ubuntu virtual machine, I could not find the way to run the Windows one and I could not find any reference of someone that made it work.

There is a previous version, Metasploitable 2, based on GNU/Linux that is also fun to use. The steps are also explained below.

Pre-requisites

You need to have installed two tools:

UTM, that is a Virtual Machine engine that runs in M1 chips
Homebrew, which is basically a package manager that allows you to install many open source tools easily

Below you have the steps to install them, but if you already have them, you can skip the steps.

Install UTM

Go to https://docs.getutm.app/installation/macos/
Click on the button Download from GitHub
Install the package.

Install HomeBrew

You just need to run this in a console:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Note: You may need to install Xcode’s Command Line Tools if you don't have them. Just run:

xcode-select --install

At the end of the installation check out that there are some instructions to add to your .zshrc file.

After the installation you should be able to run the brew command. If you run brew doctor you should get Your system is ready to brew.

brew doctor 
Your system is ready to brew.

Download the Metaexploit 3 image

Thankfully, the guys of Rapid7, the company behind meta exploit, have already created a two images that can be used in Virtual Box, an open source Virtual Machine Engine. However, VirtualBox is not compatible with M1 chips at the time of writing this article, that's why we are using UTM.

So, now, let's see how to download the images and what we need in order to run Metaexploit 3 in UTM.

Go to https://app.vagrantup.com/rapid7
Select the VM you want to download. In this case, the Ubuntu one.

Download the file

The name of the downloaded file has a weird name (some kind of unique id) and does not have extension, but behind the scenes it is a .zip file. So, you need to rename it.

cd Downloads
mv e41199c7-4afd-42b0-80fd-61ee0126e19d metasploitable3-ub1404.zip

Then unzip the file and enter the folder:

cd metasploitable3-ub1404
ls -la                    
total 4407704
drwx------@   6 user  staff         192 Nov 30 08:50 .
drwx------@ 588 user  staff       18816 Nov 30 09:18 ..
-rw-r--r--@   1 user  staff         258 Oct 29  2020 Vagrantfile
-rw-r--r--@   1 user  staff        6367 Oct 29  2020 box.ovf
-rw-r--r--@   1 user  staff          26 Oct 29  2020 metadata.json
-rw-r--r--@   1 user  staff  2256726016 Oct 29  2020 metasploitable3-ub1404-disk001.vmdk

Next step is to convert the VirtualBox image format .vmdk, into a format that UTM understands. For that we need to install qemu (used by UTM behind the scenes) using brew

brew install qemu

Now, to convert the file just use the following command:

qemu-img convert -O qcow2 -c ./metasploitable3-ub1404-disk001.vmdk ./metasploitable3-ub1404-disk001.qcow2

where -c indicates the source file and -O is for the output format, in this case qcow2

Create the UTM VM

The last step is to setup and run the virtual machine in UTM

Open UTM
Create a new VM (button with symbol +) and select "Emulate".

3 Click on other and "Other,"

Click on "Skip ISO boot."

For hardware, leave it as is. but lower the RAM if you want, it only needs like 1024 MB (maybe less).

For the rest of the options just next, next, next... until you get to the "Summary" page.
On the summary page, select "Open vm settings" then "Save".

A new dialog box with the settings of the VM will appear. You can change the name of the VM.

Click on the "QEMU" in the sidebar and uncheck "UEFI Boot".

Under "Drives" section of the sidebar menu, select "IDE Drive" and delete it.

Now in the Drive section, click on "New Drive", and then in "Import".

Select the .qcow2 file you created earlier with the qemu-img command
Click Save and start the VM.

If you need to login you can use username vagrant and vagrant also as password.

Bonus: Metasploitable 2

Now that you have everything in place installing metasploitable2, another Linux machine, is very simple

Go to https://sourceforge.net/projects/metasploitable/
And download the .zip file
Unzip.

Use qemu-img convert

cd Metasploitable2-Linux
qemu-img convert -O qcow2 Metasploitable.vmdk Metasploitable.qcow2

Repeat the same steps in UTM as for installing the Metasploitable 3 but now, when you create the new drive, use the Metasploitable.qcow2 file.

To login you can use msfadmin for both username and password.

In both machines to get the IP addresses, just run the command

ifconfig

Now you can play around with the VM.

If you found this article interesting and you would like me to write some more articles exploiting the vulnerabilities, just drop a comment below.

EOF

How to write a good README

merlos — Mon, 17 Oct 2022 04:33:59 +0000

The README file is the one-stop documentation file. Usually, it is not only the first file any person will read when reaching your project for the first time, but also it is the key document for your recurring visitors.

Why is important the README?

A few weeks back I had to install an open source project in my computer. It was the first time I was interacting with the project and experience was horrible, something that should have taken me no more than one or two hours to do, took me two days, and the main reason it took me so long was because it had a README file that could be improved to help developers new to the project to have a better first interaction.

Integrate and use open source solutions, library or tools in our own projects is the day-to-day for many developers, and the starting point for this tasks is arguably the README file. So a good README, is as indispensable for an open source project as it is the quality of the code.

Who is your audience?

Before digging into what are good contents and how to write a README file, let's dig into who's going to read this document.

To write a good README one of the keys is to think about the reader. Who is this file for? Who is your audience? In this regard, I like to classify them in three categories.

End users. They are the actual users of your application. These may also be business analysts that are seeking for a solution. They may not have a strong technical knowledge and they are more worried about the functional aspects of your solution and not so much about the technology implementation.
Technical users. These are people that have technical background and are going to install or setup the project in their own environment. You can consider them also as some kind of integrators. They are going to take your project and integrate it into the project they are working on. They care about the technical aspects, but just as a user, that is, they do not care too much about how it is implemented, but more about the functionality offered. For example, if your project exposes an API or it is a library, they want to use the API/library, but they are not interested in learning about all the implementation details.

Note that depending on the project type, sometimes the end user and the technical user may be the same target audience. For example, if your project is a Javascript library such as React JS, your end user is also, most of the time, the technical user, a developer. However, if your repository is an iOs application, your end user - someone with an iPhone who will use App Store - is not necessarily the same as your technical user - someone that wants to install the app using Xcode.
Contributors. They are people you are going to interact with somewhat because they go one step beyond in their involvement with your project. For example, a contributor can be a technical user that needs some support to install the solution, someone that wants to report a bug or suggest a new feature, someone that wants to submit a pull request with an enhancement, or someone that wants to support economically the project. As you can see, this is the most diverse group, but including all of them in one group keeps things simple.

README format and writing style

Although README files are plain text files because most of the source code hostings such as Github, GitLab or Azure Repos support the Markdown format. Because of that, most of the README files you will see in the wild are written using the Markdown syntax.

This text format is pretty simple but rich enough for having a nice output. It supports headings, bold, italic, bulleted lists, numbered lists, code blocks, links, etc. Indeed, behind the scenes, this blog post is written in Markdown too.

Quick example of Markdown:


# Heading 1

Preprending a `#` at the beginning of the first 
line of a paragraph converts it into a heading 
1 (biggest font heading).

## Heading 2

Two `#` is for heading 2. And so on so forth till 6.

To set a text in *bold* just enclose it 
in asterisks. For _italic_ use the underscore. 

Markdown also supports [links](http:/dev.to/merlos)

Based on the axiom "people don't read, they scan", the proper use of Markdown will allow you to give the document some visual structure and help users scan the contents of the file.

By setting a structure (using headers, lists, paragraphs) you are helping you users to quickly find the information they are seeking.

For example, a developer found your project while he was in the subway coming back home, because he was on the phone he starred it and a few days later came back to install it. Some weeks later he found a bug, and he wanted to report it. By adding headings - that is structure - to your README - he will have it much easier to find the particular section he is interested in.

Furthermore, to adapt the text to the way we read online, i.e. scanning, searching for key words, etcetera, you can follow some basic principles for writing for the web, like the following:

Use short paragraphs. Using around 3 to 5 lines is a good rule of thumb. Each paragraph should have only one concept. This will help scanning.
Use bulleted or numbered list instead of comma separated lists. This list of basic rules is na example. Again this helps scanning.
Never ever use click here for a link, use some meaningful text instead. Among other reasons, using click here forces users to read the context around the link, whereas a more appropriate text, will explain the reader why you shall never use click here.
Highlight key words or sentences paragraphs with bold. Avoid using underline, because it may be confused with a link.
Start with the most important information in each paragraph. Use inverted pyramid structure** in your writing. Start with the content that is most important to your audience, and then provide additional details.

README contents

Ok, now that we know who are we writing for and good practices about how to give structure and form to the file, let's see some suggested contents for the README.

The structure presented here follows the natural way of interacting with your project:

First we will shortly explain what it is the project about,
then, we will continue on how to install and how to get started with it and,
finally, we will provide the reader how to get involved, how to collaborate.

This structure follows the level of involvement with your project it is expected from each of the categories of users we have presented. End user just wants to learn about the project.

Note that some sections may not fit your project in particular or you may prefer to label them differently, but in any case the three level structure above will apply for sure.

Let's start with the sections:

Overview

Here you want to briefly introduce your project. It should not be more than two or three paragraphs. Think what you need to tell to someone that is looking at your project for the first time. The main audience for this section are your end users.

After this short intro, you may include links to the website, wiki page with further explanation and/or a demo for those that are interested in getting more about your project.

Finally, you may want to list some of the technologies, frameworks that you are using or supporting (if it is not obvious). This piece of info is interesting for the technical users that may need to evaluate if it fits the architecture of their project or organization.

Here is an example of the React JS project (in Markdown)

React is a JavaScript library for building user interfaces.

1. Declarative: React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes. Declarative views make your code more predictable, simpler to understand, and easier to debug.
2. Component-Based: Build encapsulated components that manage their own state, then compose them to make complex UIs. Since component logic is written in JavaScript instead of templates, you can easily pass rich data through your app and keep the state out of the DOM.
3. Learn Once, Write Anywhere: We don't make assumptions about the rest of your technology stack, so you can develop new features in React without rewriting existing code. React can also render on the server using Node and power mobile apps using [React Native]().

[Learn how to use React in your project]().

As you can see, first the project is showcased and at the end, you get a link to more info. In this case, the main audience are developers, and therefore end users and technical users are the same.

Install

At this point, you got enough attention from the README reader, so he wants to go one step beyond and try it.

Here you have to expose the steps to install your stuff. For example for a NodeJS application, usually you will instruct something like:

git clone http://url-to-my-repo
npm install
npm start

Or for a python library

pip install your-library-name

and so on so forth.

PRO Tip: In Markdown you can enclose code blocks with three apostrophes. If you add the name of the language after the first set of three apostrophes (for instance ruby, javascript, typescript, swift, bash) when rendered, syntax highlighting will be applied.

For example:

Is rendered:

    // This is my Javascript code
    if (a > b) return true;

Note that in this case you are assuming that the reader has the package managers, npm or pip, installed on his system, which may not be the case. So, think about specifying the pre-requisites needed before attempting to install your project. Just providing a link to the install page of each pre-requirement may be a great help for your reader. In the NodeJS example above:

  To install this application you need 
  (Node JS 16.0 or above)[https://nodejs.org/en/download/]

Usage / Getting started

Now that the reader has your project in his system, it is time to showcase the superpowers he can do now thanks to your stuff.

In getting started you can either include some basic instructions inline or point to a more rich documentation.

The goal is to guide the reader in what to do once he has just installed your project in his environment.

Documentation

In addition to the basic first steps/getting started the reader may want to dive into all the functionality of the project. It may depend on the kind of project:

For an application it may describe how to use it, the options, how to set it up for different use cases.
For a library, framework it may describe API, methods, classes, or some advanced examples.

Some additional documentation you may think about are:

Deployment good practices. How to deploy it in a production environment.
Security guidelines. How to harden any installation to avoid any cybersecurity issue.
Troubleshooting.
etc.

Depending on how you structure your documentation and your README you may merge this section with the Getting started one.

Development

From now on, this and the following sections will be for the readers that get into the nitty-gritty of your project or that want to become an active member of the community. Within the classification of potential readers are the ones that we called the contributors.

This development section is for setting up the environment in dev mode. What are the tools that you need and how to run the project in debug mode, run the unit testing, etc.

# Example of running the automated unit test suite
npm test

Contributing

This section is for providing any additional information for the reader that wants to really contribute.

How to report a bug
Code of conduct
Coding Style guide
How to make a pull request (PR)
How to get support
How to make a donation
How to contact for commercial support
etc.

You may want to add part of this documentation in a separate file. For example, GitHub allows you to set up the CODE_OF_CONDUCT.md and other files.

Acknowledgements

It is a good practice to acknowledge those who have been inspiration of your work (other repos, other projects) or mention those key contributors of the project, that is, those that have added new features, submitted pull requests, fixed bugs, etc.

License

The last section of the README typically is reserved for the copyright and license.

Though, at a first glance, you may think that this is not important, the truth is that it setting up a license is key as it helps other developers to understand the limits of the use of your software.

Here you have a list of open source licenses. You should have a rough idea of what each license means. Personally, I usually choose between GPL3 and MIT.

MIT is the simplest license one, more or less it says: you can do whatever you want with this piece of code. Do it at your own risk and do not suit me.
GPL, is a copyleft license. It is a more restrictive license than the MIT as it forces any contribution or customization of the code to be publicly released, as well as to be distributed under the same GPL license. It is less attractive for a commercial usage, but better for the overall community as any contribution reverts back to the community. For example the GNU/Linux kernel is distributed under this license.

In this section of the README, you don't need to add the whole text of the license, just the banner, but usually, you should include a copy of the whole license in the file LICENSE or LICENSE.md.

Extra balls

A couple of things that you can add to your project README are images and status badges.

Images

As it was mentioned earlier, README files generally are written in Markdown. This language, allows you to link images within that will be displayed once the Markdown is rendered.

In particular there are two cases which this may be useful:

To make it look cooler. For example adding a logo at the beginning of the readme, makes it look good. It gives a good first impression.
Showcasing / Providing a demo. An image is 1,000 words worth. You can record a simple animated GIF and showcase key features of your project helping the reader to grasp what's your project about with less effort.

Status badges

Another "cool" thing you can add in your README file is a status badge. A status badge displays what is the status of a particular aspect of your repo, it can be if the unit testings are passing failing, if your pipelines are working, what is the latest version released, the code coverage, and a long etcetera.

It gives a snapshot to your visitors in a nutshell some indicators of the project.

You can check the badges/shields repo to add some badges to your project.

The only drawback of using images and the badges in the README is that they will not be rendered in a simple text editor, but you can ignore it as most of the time this file will be displayed either in the repo website or in a developer friendly editor which usually support Markdown rendering.

Summary

If you are working in an Open Source project, the README file is a key one-stop document that can boost the developer experience.

To write a good readme you need to keep in mind the types of audience that will read the file: end-users, technical users and contributors.

You should pay attention on how people read on the web, helping them to scan your README using Markdown, and the good practices for writing for the web such as short paragraphs, lists and the inverted pyramid writing schema.

The contents of the README should follow a structure that first introduces the project, then explains how install and use it and, finally, explains how to get involved in the project as contributor.

I hope you enjoyed the article. One final question. What is the best or your favorite README file?

Write code for people: Dos and don'ts to improve your React code

merlos — Sat, 18 Jun 2022 20:43:50 +0000

During the last three years I have reviewed many pull requests of React applications. I consistently observed in different developers some practices that could be improved just by keeping in mind the following sentence:

I am writing code for other people.

Why write code for humans?

Either if you are writing enterprise applications or creating an open source project, your code is going to be read and maintained by humans. This is a mantra you must always keep in mind.

Some readers may pose that code is run on machines, so if the code is not efficient you cannot consider it good code. That's a good point, but if the code is readable bot not efficient, it will be easier to understand where to change it to make it faster.

Good code that is developer-friendly has several advantages.

It is more pleasant to read and easier to understand.
Reduces onboarding time. Development teams sometimes need more capacity, so new staff or consultants may join the team. On those cases, human centered code makes on boarding much smoother and less time costly.
Takes less time to maintain. It is very common to spend a lot of time in an application/library, then you release it, and, for a while, you don't modify it. One day, after some months you need to change something and... guess what, now you don't remember what you did, so you need to read your own code.

Dos and don'ts to make : Recipes / Tips

We'll start with some general JavaScript tips and then move to more specific tips for React.

Do use significant names in variables.

Whenever you create a variable ask yourself: Does the name of a variable convey what is the content of the variable?

In general, follow these rules:

Use the shortest name,
But also be as precise as possible.

 //  ❌  Not good
 const list = ['USA', 'India', 'Peru', 'Spain']
 list.map(item => console.log(item))

 //  ✅  Better
 const countries = ['USA', 'India', 'Peru', 'Spain']
 countries.map(country => console.log(country))

In general do not use generic names such as list, item, they are short but not very meaningful. A list can contain anything and it will not give any clue about its contents to the reader of your code. A more precise name, such as countriesin the example above, is better.

Also, I personally prefer to avoid acronyms in variables as they may be harder to understand for junior/new developers.

 //  ❌  Not that good
const handleClk = e => { 
    console.log("User clicked the button" + e.current.value) 
}

//  ✅  Better
const handleClick = event => {  
    console.log("User clicked the button" + event.current.value) 
}

This "rule" makes the code more verbose but also easier to understand.

In other languages like Python it is common to use acronmys/abreviated versions - for example when importing modules - which is somewhat fine as these are widely spread conventions across existing documentation, examples and even novice learners.

# Typical way of renaming modules in python
import numpy as np
import tensorflow as tf
import seaborn as sns

The rational of this convention is to type less, be more productive (Now with autocomplete of the editors is no longer true), make the code less verbose and "faster" to read for expert eyes.

Following this idea, there may be cases in JavaScript in which you use shorter versions, for example:

// doc instead of document 
const doc = createNewDocument()

As summary, do give some thought when naming variables in your code. I believe this is one of the hardest part of software development and it differentiates good developers from bad developers.

Do use consistent names across the app.

Give good names to variables is not enough, they have to be consistent across the whole react app.

To solve complex problems we create small independent logic units. We follow the strategy of divide and conquer to make it easier. We implement components in an isolated way, they have some inputs and throw some output. However, we should not forget these units belong to a higher order organism, your application.

Ask yourself upon creating a variable, function, component or a file, if its name is consistent with the names already used in the application. Example:

  //  ❌  Not that good
  //File1.jsx
  const sectorsData = useSelector(sectorsSelector)

  //File2.jsx
  const sectorsList = useSelector(sectorsSelector)


   //  ✅  Better
  //File 1
  const sectors = useSelector(sectorsSelector)

  //File 2
   const sectors = useSelector(sectorsSelector)

For files:

/redux/constants/<entity>Constants.js
/redux/actions/<entity>Actions.js
/redux/selectors/<entity>Selector.js
etc..

Do follow the Don't repeat yourself (DRY) principle.

That is, if you see that your are repeating similar code or logic in two places, refactor that code to use a function, component, etc.

  //  ❌  Not that good
  const getPdfName = (country) => { 
    const now = new Date()
    const pdfName = `${country}-${now.getFullYear()}-${now.getMonth()}-${now.getDay()}.pdf` 
    return pdfName
  }

  const getExcelName = (country) => { 
    const now = new Date()
    const xlsName = `${country}-${now.getFullYear()}-${now.getMonth()}-${now.getDay()}.xls` 
    return xlsName
  }

  //  ✅  Better
  const buildFilename = (name, extension) => {
    const now = new Date()
    return `${name}-${now.getFullYear()}-${now.getMonth()}-${now.getDay()}.${extension}` 
  }

   const gePdfName = (country) => {  
    return buildFileName(country, '.pdf')
   }

  const getExcelName = (country) => { 
   return builExcelName(country, '.xls')
  }

Do keep files short

I use 200 lines as a benchmark. Specially when we talk about React components, if you have a file that has more than 200 lines, ask yourself if you can split it in smaller components.

Also, if the large majority of your component code is for fetching and processing data, think about moving that code to support/helper files. For example, you can create a folder /src/lib/ and keep there your utility functions.

Also, it is not advisable to have more than a certain amount of files (~10-20) in the same folder. Structuring the folder into sub-folders makes the project more readable.

Do create a compact code.

  // ❌ Not that good
  const handleClick = newValue => {
    const valueAsString = newValue.toString()
    if (onClick !== undefined) {
      onClick(valueAsString)
    }
  };

  // ✅ Better
  // Previous code in 1 single line.
  const handleClick = newValue => onClick && onClick(newValue.toString())

Although compact code as a general principle is good, it may sometimes obfuscate what is the code actually doing. So:

Do document your code.

Specially for helper functions the interface needs to be clear.

Do include comments for pieces of code that may not be very obvious. Example:

  // ❌ Not that good
  editor.countWorths= nodes => {
    const content = editor.serialize(nodes);
    return content.length ? content.match(/\b[-?(\w+)?]+\b/gi).length : 0;
  }

  // ✅ Better
  /**
   * Counts the number of words within the passed nodes
   *
   * @param {Node} SlateJS nodes
   * @returns {integer} Number of words
   */
  editor.countWords = nodes => {
    const content = editor.serialize(nodes); // one string with all node contents
    //Extracts number of words with the regex unless empty string (0)
    return content.length ? content.match(/\b[-?(\w+)?]+\b/gi).length : 0;
  };

Do use linters and code formatters

Linters are code analyzers that provide estilistic suggestions. The most widely spread in Javascript is esLint. Setting it up in a react application is pretty easy.

The other tool that will make your code more readable and save you time is a code formatter. It will indent and break the lines of your code. It will really make your code much easier to read and will save you time. In JavaScript we are lucky, we have prettier that formats your code on save.

Do use `on` and `handle` as prefix on event props and handlers

This is a de facto standard on React naming conventions. It is widely used on the official react documentation and gives the reader a cue on what is the prop for.

For event props use on as prefix (for instance, onClick, onSubmit, onBlur).

For the handlers of those events use the prefix handle (for instance, handleClick, handleSubmit, handleBlur).

    // ❌ Not that good
    export default function SendEmailForm (sendEmail) {

    /// process / validate email form
    sendEmailWasClicked(event) {
      sendEmail && sendEmail(formFields)
    }

    return(
     <form>
       ...
       <input type="submit" onClick={sendEmailWasClicked}>
        Send email
       </input>
       ...
     </form>
    )

    // ✅ Better
    export default function SendEmailForm (onSendEmail) {

      handleSubmit(email) {
        // process email info
        // ...
        //
        onSendEmail && onSendEmail(email)
      }

      return(
       <form>
         ... 
         <input type="submit" onClick={handleSubmit()}>
           Send email
         </input>
         ...
     </form>
    )

Do not add handler code in the render

In my experience it makes the code harder to read when the logic of the handler is within the render.

  // ❌ Not that good
  <button onClick={() => {
    if (name==='') {
       setError("Name is mandatory")
        return
     }
     if (surname==='') {
       setError("Name is mandatory")
        return
     }
     onSubmit && onSubmit({name, surname})
  }}>Submit</button>

    // ✅ Better
    const handleOnSubmit = () => {
     if (name === '') {
         setError("Name is mandatory")
         return
      }
      if (surname === '') {
         setError("Surname is mandatory")
         return
      } 
      onSubmit && onSubmit({name, surname})
     }

    ...

    return( 
      ...
      <button onClick={handleOnSubmit}>Submit</button>
      ...
     )

One liners may be ok to make code more compact.
Example:

    // ✅ This is ok
    return (
        <button onClick={() => onCancel && onCancel()}>
            Cancel
        </button>
    )

Do use `const` by default

Whenever you create a variable use const by default. Use let
only when it is going to be assigned several times. Avoid var.

It will save you some hard to find bugs.

    // ❌ Not that good
    let today = new Date()  // Today 99.9999999% won't be reasigned

    // ✅ Better
     const today = new Date()

Note that you assign a variable when the name is in front of an =. So you can modify Arrays and Objects as constants.


    // ✅ This will run 
    let day = new Date() 
    day = new Date()

    // ❌ It will not run
    const day = new Date() 
    day = new Date()  // you cannot reasign a const

    // ✅ This will run 
    const myObject = { a: 'prop created during assignment' }
    myObject.b = {b: 'object content can be modified after creation'}

    const animals = [ 'dog', 'cat']
    animals.push('lion')

Only when you put a const before = more than once, the code won't run.

Do use the best maping function in arrays

Use map() for returning an array with the same number of elements.

  const numbers = [1, 2, 3]
  const double =  numbers.map( number => (2 * number)) // [2, 4, 6]

Use filter() for returning the items that match a criterium.

const numbers = [1, 2, 3]
const double =  numbers.filter( number => (number > 1)) // [2, 3]

Use find() for searching the first item that matches a cirterium.

const numbers = [1, 2, 3]
const double =  numbers.find( number =>  (number > 1)) // [2]

Use forEach() for not returing an array.

     const list = [1, 2, 3] 
     let sum = 0
     list.forEach( number => sum += number) // 6

Do handle situations in which there is no value

Example:

  // ❌ Not that good
  export default function MyForm(value, onSubmit) {

    //...

    const handleOnSubmit => (newValue) => {
      // do whatever other transformations
      onClick(newValue)
    }

    //...

    return (
    {/* this assumes input handles null or empty values correctly */}
      <Input value={value} />
      <Button onSubmit={handleOnSubmit}>Submit</Button>
    }

  // ✅ Better
  const default function MyForm(value, onSubmit) {

    //...

    const handleOnSubmit = () => {
        // It won't do anything BUT won't crash.
        onClick && onClick(values)
    }

    //...

  }

Example 2:

     // ❌ Not that good
    export default function IndicatorsList({sectors}){
    return(
      <ul>
       {sector.indicators.map(indicator => <li key={indicator.id}>{indicator.text}</> )}
      </ul>
    }

    // ✅ Better
    //It receives the indicator list
    export default function IndicatorsList({indicators}) {
    indicators = indicators || []

    (indicators.length == 0) ? (
      <p>No indicators</p>
    ) : (
    <ul>
    {indicators.map ( indicator => <li key={indicator.id}>{indicator.text}</> )}
    <ul>
    )

Be consistent on the order in which you write the code.

Always follow the same order of the imports, variables and functions within the code of the components.For example, I like the folowing order:

imports
state, variables and constants
useEffects
effect handlers (handleOnClick, etc.)
return() function
Prop defaults and PropTypes

Indeed, for the imports, you may even define an actual order:

React related stuff
General such as react-router
External UI related components
Redux actions, selectors
Hooks
Custom Application UI components

Do add validations for fields and handle form errors.

Gererally, when you read a tutorial or watch a video that teaches react or any other library/programming language, they do not manage errors other than display a console message. Their code is simple, but in real applications user may fill unexpected data, there may be network errors, API may have bug, the user may not have permissions to access a resource, or your authentication token may have expired. Your code has to manage all these situations gracefully and display the appropriate feedback to the user so he can recover from them.

Types of errors and how to manage them from the user experience and from the code point of view is something that requires a deep dive, but we will leave that for another article.

Wrapping up

Always keep in mind:

I write code for other people.

So always try to think if a reader would understand it. Code being consistent, using meaninful variables, document the code, and follow some wide spread conventions. developer (human) friendly code will be much easier to maintain, less prone to errors and if a new team member joins, she/he will be on boarded and productive in less time.

Note that the above mentioned dos and don'ts are general guidelines, and some of the recommendationsmay have corner cases in which you can argue not to follow them, in those cases use your common sense.

How to use ML5 with Nodejs and puppeteer step by step

merlos — Wed, 11 Nov 2020 01:10:17 +0000

In this article we are going to train and save a simple model using ML5 and NodeJS.

ML5 is a high level machine learning library that is very easy to use and that behind the scenes uses TensorFlow JS.

One limitation of ML5 is that it was developed to be used within a browser. According to the documentation ML5 will eventually natively support NodeJS, but at the moment of writing this article ml5 requires a browser to run.

The thing is that because it is so easy to use you may still want to use it also in a pipeline or in a NodeJS script.

Thankfully, we have puppeteer to help us overcome that limitation.
For those who do not know puppeteer, it is a headless browser based on Chromium that can be controlled programmatically using NodeJS.
What we will do is create the a simple HTML page with the ml5 script and then call puppeteer to run it.

For this article we are going to train an image classification model. We will develop it using a browser as a normal ml5 script. Then, we will just need to create a node script that will open that page in puppeteer, it will wait till the ml5 script is completed and it will download the output.

Besides this approach is very simple it still may have some limitations. For example, the number of images that can be loaded on the browser is finite, specially if you have many classes and many training samples.

Also, the model we will train is based in MobileNet which is a lightweight model that has low latency on mobile and embedded devices, but it may not be as accurate as you may need.

The ML5 script

As example, using transfer learning, we will train a classification model to differentiate between two types of skateboards: longboards (left) and regular street skateboards (right).

The javascript code for training the modeñ that I will be using here is heavily based on the fantastic ML5 tutorial of The Coding Train by Daniel Shiffman.

Setup

First, we initialize our project

mkdir myproject
cd my project
npm init

When running npm init we will be asked a few simple questions. Don't worry too much about what you fill, if you need to change something you can always edit package.json.

Now let's install a couple of dependencies that we will be using. The first one is puppeteer, our headless browser and the second one is serve, a very simple http server. We will use it for serving the HTML file that is loaded by puppeteer.

npm install puppeteer
npm install serve

Now we are going to create the HTML file that will hold the script to train the model.

mkdir public
cd public
touch public/index.html

Now edit the file public/index.htmland add some code

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Getting Started with ml5.js</title>
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <script src="https://unpkg.com/ml5@0.5.0/dist/ml5.min.js"></script>
  </head>
  <body>
    <h1>Hello ml5</h1>
    <script>
      /* We will add the code to train our model here */
    </script>
  </body>
</html>

Now, let's run the server to validate it works

./node_modules/serve/bin/serve.js ./public/

Open your browser in http://localhost:5000 and you should see the text Hello ml5.

Alternatively, you can import the script using the attribute 'src' in the script tag

<head>
...
...
<script src="script.js"></script>
...
</head>

For this example, we are going to pre-load the images in the HTML, and then we will add them to the classifier. The images will go just after the <body> and before the <script>. In a more realistic environment you can include the images dynamically.

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Getting Started with ml5.js</title>
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <script src="https://unpkg.com/ml5@0.5.0/dist/ml5.min.js"></script>
</head>
<body>
  <!-- images to train the classifier -->
  <img src="./longboard1.jpg" id="longboard1" />
  <img src="./longboard2.jpg" id="longboard2" />
  <img src="./longboard3.jpg" id="longboard3" />
  <img src="./longboard4.jpg" id="longboard4" />
  <img src="./longboard5.jpg" id="longboard5" />
  <img src="./longboard6.jpg" id="longboard6" />

  <img src="./skateboard1.jpg" id="skateboard1" />
  <img src="./skateboard2.jpg" id="skateboard2" />
  <img src="./skateboard3.jpg" id="skateboard3" />
  <img src="./skateboard4.jpg" id="skateboard4" />
  <img src="./skateboard5.jpg" id="skateboard5" />
  <img src="./skateboard6.jpg" id="skateboard6" />

  <!-- images to test -->
  <img src="./d.jpg" id="longboard" />
  <img src="./skateboard.jpg" id="skateboard" />
  <script>
     /* We will add the code to train our model here */
  </script>
</body>
</html>

Now, we have to write the code we will use to train the cad-longboard classifier. The steps we will follow are:

Get the classifier from the pre-trained model (MobileNet).
Add the images to the classifier.
Train the classifier with the new classes.
Download the trained model.

Below you have the code. It is fairly commented but if you need more info you can refer to the ml5.featureExtractor documentation.

<<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Getting Started with ml5.js</title>
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <script src="https://unpkg.com/ml5@0.5.0/dist/ml5.min.js"></script>
  </head>

  <body>
    <!-- images to train the classifier -->
    <img src="./longboard1.jpg" id="longboard1" />
    <img src="./longboard2.jpg" id="longboard2" />
    <img src="./longboard3.jpg" id="longboard3" />
    <img src="./longboard4.jpg" id="longboard4" />
    <img src="./longboard5.jpg" id="longboard5" />
    <img src="./longboard6.jpg" id="longboard6" />

    <img src="./skateboard1.jpg" id="skateboard1" />
    <img src="./skateboard2.jpg" id="skateboard2" />
    <img src="./skateboard3.jpg" id="skateboard3" />
    <img src="./skateboard4.jpg" id="skateboard4" />
    <img src="./skateboard5.jpg" id="skateboard5" />
    <img src="./skateboard6.jpg" id="skateboard6" />

    <img src="./longboard.jpg" id="longboard" />
    <img src="./skateboard.jpg" id="skateboard" />
    <script>
      let classifier

      const featureExtractor = ml5.featureExtractor("MobileNet", modelLoaded)

      // Once the model is loaded
      function modelLoaded() {
        console.log("Model Loaded!")

        classifier = featureExtractor.classification()

        // Retrain the network. You can use a for loop too :)
        classifier.addImage(document.getElementById("longboard1"), "longboard")
        classifier.addImage(document.getElementById("longboard2"), "longboard")
        classifier.addImage(document.getElementById("longboard3"), "longboard")
        classifier.addImage(document.getElementById("longboard4"), "longboard")
        classifier.addImage(document.getElementById("longboard5"), "longboard")
        classifier.addImage(document.getElementById("longboard6"), "longboard")

        classifier.addImage(
          document.getElementById("skateboard1"),
          "skateboard"
        )
        classifier.addImage(
          document.getElementById("skateboard2"),
          "skateboard"
        )
        classifier.addImage(
          document.getElementById("skateboard3"),
          "skateboard"
        )
        classifier.addImage(
          document.getElementById("skateboard4"),
          "skateboard"
        )
        classifier.addImage(
          document.getElementById("skateboard5"),
          "skateboard"
        )

        //addImage accepts a third argument that is a callback.
        classifier.addImage(
          document.getElementById("skateboard6"),
          "skateboard",
          imagesLoaded
        )
      }

      // Function that will be called once the images are loaded
      // It trains the model with the new categories
      function imagesLoaded() {
        console.log("do train", classifier.hasAnyTrainedClass)

        // train argument is a callback that has as argument the current lossValue.
        // When lossValue is null, it means the training is finished
        classifier.train(lossValue => {
          console.log("Loss is", lossValue)
          if (lossValue == null) {
            trainFinished()
          }
        })
      }

      // Called once the classifier is trained with the new classes
      function trainFinished() {
        // Get a prediction for that image
        console.log("train finished")

        // Examples to test the classifier
        // Examples to test the classifier
        classifier.classify(
          document.getElementById("longboard"),
          (err, result) => {
            console.log("is longboard?", result, result[0].label) // Should output 'longboard'
          }
        )
        classifier.classify(
          document.getElementById("skateboard"),
          (err, result) => {
            console.log("is skateboard?", result, result[0].label) // Should output 'skateboard'
          }
        )
        // Saves two files model.json and model.weights.bin
        classifier.save()
        // This is the signal to tell puppeteer we are done with the
        done = document.getElementById("done").style.display = "block"
      }
    </script>
    <p id="done" style="display: none;">Done!</p>
  </body>
</html>

What we have done until now is pretty similar to what you'll do using a regular ml5. Now, it's time for the magic.

NodeJS script

The script is very simple, it navigates to the page of our local server, allows to download the files (our model) and wait till the model is trained which is signaled by displaying an element with the id "done" in the HTML.

//index.js
const puppeteer = require("puppeteer")

;(async () => {
  const browser = await puppeteer.launch()
  const page = await browser.newPage()

  // Navigate to the page that trains the model
  await page.goto("http://localhost:5000")

  // if you want to trigger some function in the page use evaluate
  console.log(await page.evaluate("ml5.version")) // prints "0.5.0"

  // Display browser console messages on screen
  page.on("console", msg => console.log(">", msg.text()))

  // This allows to save the model when classifier.save() is called.
  // downloadPath is the folder in which the model will be saved.
  await page._client.send("Page.setDownloadBehavior", {
    behavior: "allow",
    downloadPath: "./",
  })

  //Wait till element with id="done" is visible
  //By default puppeteer will wait 30s and then throw error. `timeout = 0` disables the timeout.
  await page.waitForSelector("#done", { visible: true, timeout: 0 })

  console.log("DONE!")
  browser.close()
})()

To run the script

node index.js

It is important to note that you need to be running serve in port 5000 while running the node script.

If everything goes ok, you should see the text "DONE!" and two new files model.json and model.weights.bin.

The source code mentioned in this article is available in this github repository

Wrapping up

We have trained an image classification model using transfer learning using ml5, then through a Node script using puppeteer we have been able to run this task with just a few lines of code, which is awesome!

DEV Community: merlos

Agent orchestration. The end of coding as we know.

The Rise of the AI Agent

From Code Snippets to Repo Access

The Death of Language Barriers

The Future: Creative Destruction

At the Individual Level

At the Market Level:

A Paradox of Creativity

ChatGPT bot with your own data

Yes, and it is fairly simple.

So, What's the process you need to follow?

What do I need?

Let's bot it!

Collect your knowledge base

Process the data.

Test it

What happens behind the scenes when you ask a question?

Hack the code

Last words

How to setup Metasploitable in a Mac with M1 chip

Intro

Pre-requisites

Install UTM

Install HomeBrew

Download the Metaexploit 3 image

Create the UTM VM

Bonus: Metasploitable 2

How to write a good README

Why is important the README?

Who is your audience?

README format and writing style

README contents

Overview

Install

Usage / Getting started

Documentation

Development

Contributing

Acknowledgements

License

Extra balls

Images

Status badges

Summary

Write code for people: Dos and don'ts to improve your React code

I am writing code for other people.

Why write code for humans?

Dos and don'ts to make : Recipes / Tips

Do use significant names in variables.

Do use consistent names across the app.

Do follow the Don't repeat yourself (DRY) principle.

Do keep files short

Do create a compact code.

Do document your code.

Do use linters and code formatters

Do use on and handle as prefix on event props and handlers

Do not add handler code in the render

Do use const by default

Do use the best maping function in arrays

Do handle situations in which there is no value

Be consistent on the order in which you write the code.

Do add validations for fields and handle form errors.

Wrapping up

I write code for other people.

How to use ML5 with Nodejs and puppeteer step by step

The ML5 script

Setup

NodeJS script

Wrapping up

Do use `on` and `handle` as prefix on event props and handlers

Do use `const` by default