Forem: charly3pins

Tech Gurus: Don’t Drink All the Kool-Aid

charly3pins — Mon, 07 Apr 2025 17:35:11 +0000

Tech’s got a guru problem—every time a new shiny toy pops up, cheap gurus sprout from under rocks like mushrooms.
Suddenly, everyone’s an expert in generative AI because they watched a YouTube tutorial.
A few years back, it was crypto—everybody had a “system” to make you rich.
Before that, cloud, big data, you name it. If it’s new, an army of instant prophets swears they’ve mastered it.

Spoiler: it’s dumb to buy that.

How? If something’s been around for two minutes, nobody’s an expert—not you, not me, not the guy with 50k followers on X selling a shitty course.

We’ve all seen job postings asking for X years of experience in tech that’s younger than the requirement itself.
Take this gem from Sebastián Ramírez, the creator of FastAPI, a Python framework for building APIs:

I saw a job post the other day. 👔

It required 4+ years of experience in FastAPI. 🤦

I couldn’t apply as I only have 1.5+ years of experience since I created that thing. 😅

Maybe it’s time to re-evaluate that "years of experience = skill level". ♻
— Sebastián Ramírez (@tiangolo) July 11, 2020

It’s not a one-off—we’ve all gotten those weird vibes from recruiters or posts.
But that’s a rant for another day.

The real issue? A species that thrives on this chaos, emerging from the shadows as THE GURU.

"The Guru"

The sector’s exhausted—every hype wave drags in a flood of clowns with half-baked demos and “10x your life” promises.
For folks too busy or lazy to question them, it’s an easy trap—follow the guru (in every sense), buy the hype, and then, not long after, realize it’s all smoke.
The “expertise,” the swagger, the cred they built? Gone overnight.
It’s their game, their hustle—but what about your business, your time, your sanity?
That’s the cost of chasing self-proclaimed saviors, fake experts, wannabe gods.
AI that writes flawless code, frameworks with no bugs, workflows that “just work”—blah, blah, blah.

It’s noise, not signal. And the community’s fed up: we’re done chugging these jokers’ Kool-Aid just because they sound slick.

How to Spot Them

It’s tricky—they latch onto what’s trending, riding the hype train with dummy examples, often without even testing the stuff they’re preaching.
Sure, some are good at something—marketing, mostly.

That’s why people bite: in a sea of lazy thinking, they don’t need to prove squat.
They just say it, and the algorithm does the rest—oh, that sweet algorithm!
They peddle “the solution” without knowing your mess—always in a controlled sandbox, no real-world grit.

Here’s the truth: it doesn’t work that way.

Be critical—test it yourself.
Don’t trust a glossy stream demo; throw it into your terminal, your team, your chaos.
If it can’t survive a sprint in your trenches, it’s junk.
Cheap gurus crumble under real code—you won’t.

Conclusion

If you’re still here, props—you’ve waded through my rant on these fakes.
Tech’s too messy for their “expert” schtick.

Got your own guru fatigue?
Drop your thoughts on LinkedIn or Twitter/X, or subscribe to Tech Trenches for more from the trenches.

Happy coding!

{C3P}

Vibe Coding: A Weekend Hack That's Not Ready for the Real World

charly3pins — Tue, 01 Apr 2025 07:39:06 +0000

Since Andrej Karpathy's tweet blew up in February 2025 —4 million views and counting— vibe coding has been the tech world's shiny new toy.

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper…
— Andrej Karpathy (@karpathy) February 2, 2025

Tools like Cursor and SuperWhisper let you chat with AI, say "build me a game", and bam, you've got a prototype by Sunday night.
It's a fun weekend hack, but it's nowhere near ready for the real world. Let's break it down.

What's This "Vibe Coding" Hype?

It's simple: you tell an AI your idea—"make a retro app" or "fix this messy UI" —and it churns out code while you chill.
Karpathy's line, "see stuff, say stuff, run stuff, copy-paste stuff," sums it up. You feel like a coding wizard, slapping together apps in hours.
I get the appeal—I've messed with it myself.
But it's cool until you realize that AI doesn't care if it actually works tomorrow.
That's where the cracks show.

Why I'm Calling BS on the Revolution

I've led teams through enough production fires to know what holds up—and `vibe coding" doesn't. Here's why it's more hype than help:

It's a Mess Under the Hood: The code looks fine until you dig in. I've seen AI spit out stuff that's insecure—take Lovable's generated code, where sloppy handling of Supabase API keys left tokens exposed for anyone to snatch, ripe for abuse. Good luck finding the bug when you didn't write it.
Guessing Isn't Engineering: You tweak until it "works", but that's not a system—it's a gamble. I've had to clean up worse disasters from less.
Scalability? Nope: That quick app is a nightmare to maintain. I once inherited a codebase so tangled it took weeks to unravel—AI-generated code feels like that on steroids.
You Get Lazy: Lean on AI too much, and you're screwed when it flakes. The AI won't save you when the client calls at 2am.

Prototypes Are Not Products

The LinkedIn crowd loves saying "vibe coding" makes everyone a 10x engineer.
Sure, for a prototype.
But a prototype isn't a product, and a product isn't a business.
This creates a shortcut culture that there is no benefit at all unless for the ones hyped with it.
I've watched startups crash because they thought a weekend hack could scale.
Real engineering—systems that don't buckle, teams that ship—takes depth, not vibes.

My Advice: Play, Don't Pray

If you're into vibe coding, have fun—but keep it in the sandbox:

Hack away on side projects or proofs-of-concept.
Treat the output like a sketch—review it like your job's on the line.
Don't even think about production without a real engineer's eyes on it.

To be clear: I'm not anti-AI; I use it to brainstorm or speed up grunt work.
But I'd rather trust my team and hard-earned skills than bet on a tool that's all flash, no substance.

Conclusion

If you've made it this far, hats off—you've waded through my take on vibe coding.

It's a slick gimmick for a quick prototype, but don't be fooled: it's nowhere near ready for the real stuff—solid systems and businesses need more than AI vibes.

I've laid out why I think it's overhyped and risky, so if you've got a "vibe coding" win or wipeout, I'd love to hear it.

Drop your thoughts on LinkedIn or Twitter/X or subscribe to Tech Trenches for more from the trenches.

Happy coding!

{C3P}

My Neovim setup for Mac for coding (in Go), writing and boosting your productivity in 2024

charly3pins — Fri, 02 Aug 2024 07:11:55 +0000

Introduction

I'm not going to lie, I tried to jump from my editor to Vim many times since I was using Eclipse, then Sublime and the latest VS Code.
I have always been fascinated with Vim and its potential. How something so simple can be so powerful? The reality is that I started several times the Vimtutor and I got stuck.
I tried to edit the text in Vim and I got stuck. I tried to code something and I got stuck. Last year I tried seriously and I spent one or two weeks just using Vim.
I thought it was the moment, but I failed... again. In Q2 this year I decided to take that seriously. I read a lot of posts, watched a few YouTube videos and I also read
Mastering Vim Quickly: From WTF to OMG in no time by Jovica Ilic. Now yes! I am using Vim for almost anything. Sometimes I have to admit
that I'm still using VS Code for tasks that require editing a lot of lines at the same time and I'm still not that good with Vim, but very little.

So today I'm gonna show you my configuration of Neovim and all the plugins that I use every day while coding mainly.

Requirements

I am using MacOS and I use brew for managing my dependencies, so I assume you will too, if not please install it by going to its official website and following the instructions.

Is not mandatory but for the ones interested, I am using the Alacritty terminal, so if you're interested you can download it using the following command in your terminal:

brew install --cask alacritty

I think I will publish a post in future when I explain all my terminal configurations, but let's go back to our Neovim setup.

To install Neovim simply type this into your terminal:

brew install Neovim

File structure

From now on we will see the Neovim config. You can find the full code in my dotfiles. Feel free to clone the repo and manipulate it as you want.

The config will be stored in ~/.config/nvim. In my case, I have a symlink to my dotfiles repo as you probably noticed if you checked the repo, it's not required.

If you don't have the folder created yet, you can do it running:

mkdir -p ~/.config/nvim

and then go inside that directory:

cd ~/.config/nvim

and create the main file for your config using lua as:

touch init.lua

Apart from the main file, I am going to create two folders, one for the core config and the other for the plugins config; and a lazy.lua file to manage the lazy.nvim plugin manager config.

mkdir -p lua/charly3pins/core

mkdir -p lua/charly3pins/plugins

touch lua/charly3pins/lazy.lua

Replace charly3pins with your username.

Core options

For the core options, I have 3 files with different configs in each and 1 that bundles all 3. First of all, move to the core directory.

cd lua/charly3pins/core

Then create the 4 files as follows:

touch autocommands.lua

touch init.lua

touch keymaps.lua

touch options.lua

In the autocommands I have the following code:

-- Highlight when yanking (copying) text
--  Try it with `yap` in normal mode
--  See `:help vim.highlight.on_yank()`
vim.api.nvim_create_autocmd("TextYankPost", {
    desc = "Highlight when yanking (copying) text",
    group = vim.api.nvim_create_augroup("kickstart-highlight-yank", { clear = true }),
    callback = function()
        vim.highlight.on_yank()
    end,
})

That is used when yanking text to highlight what I yank.

The keymaps is where I define all my shortcuts. I use the space as the leader as the trigger and the config of the different plugins:

vim.g.mapleader = " "

local keymap = vim.keymap

-- use jk to exit insert mode
keymap.set("i", "jk", "<ESC>", { desc = "Exit insert mode with jk" })

-- clear search highlights
keymap.set("n", "<leader>nh", ":nohl<CR>", { desc = "Clear search highlights" })

-- delete single character without copying into register
-- keymap.set("n", "x", '"_x')

-- increment/decrement numbers
keymap.set("n", "<leader>+", "<C-a>", { desc = "Increment number" }) -- increment
keymap.set("n", "<leader>-", "<C-x>", { desc = "Decrement number" }) -- decrement

-- window management
keymap.set("n", "<leader>sv", "<C-w>v", { desc = "Split window vertically" }) -- split window vertically
keymap.set("n", "<leader>sh", "<C-w>s", { desc = "Split window horizontally" }) -- split window horizontally
keymap.set("n", "<leader>se", "<C-w>=", { desc = "Make splits equal size" }) -- make split windows equal width & height
keymap.set("n", "<leader>sq", "<cmd>close<CR>", { desc = "Close current split" }) -- close current split window

keymap.set("n", "<leader>to", "<cmd>tabnew<CR>", { desc = "Open new tab" }) -- open new tab
keymap.set("n", "<leader>tq", "<cmd>tabclose<CR>", { desc = "Close current tab" }) -- close current tab
keymap.set("n", "<leader>tn", "<cmd>tabn<CR>", { desc = "Go to next tab" }) --  go to next tab
keymap.set("n", "<leader>tp", "<cmd>tabp<CR>", { desc = "Go to previous tab" }) --  go to previous tab
keymap.set("n", "<leader>tf", "<cmd>tabnew %<CR>", { desc = "Open current buffer in new tab" }) --  move current buffer to new tab

-- Disable arrow keys in normal mode
vim.keymap.set("n", "<left>", '<cmd>echo "Use h to move!!"<CR>')
vim.keymap.set("n", "<right>", '<cmd>echo "Use l to move!!"<CR>')
vim.keymap.set("n", "<up>", '<cmd>echo "Use k to move!!"<CR>')
vim.keymap.set("n", "<down>", '<cmd>echo "Use j to move!!"<CR>')

In the options are the vim options for the basic editor functionalities:

vim.cmd("let g:netrw_liststyle = 3")

local opt = vim.opt

-- line numbers
opt.relativenumber = true
opt.number = true

-- tabs & indentation
opt.tabstop = 2 -- 2 spaces for tabs
opt.shiftwidth = 2 -- 2 spaces for indent width
opt.expandtab = true -- expand tab to spaces
opt.autoindent = true -- copy indent from current line when starting new one

-- line wrapping
opt.wrap = false -- disable line wrapping

-- search settings
opt.ignorecase = true -- ignore case when searching
opt.smartcase = true -- if you include mixed case in your search, assumes you want case-sensitive

-- cursor line
opt.cursorline = true -- highlight the current cursor line

-- appearance

-- turn on termguicolors for nightfly colorscheme to work
-- (have to use iterm2 or any other true color terminal)
opt.termguicolors = true
opt.background = "dark" -- colorschemes that can be light or dark will be made dark
opt.signcolumn = "yes" -- show sign column so that text doesn't shift

-- backspace
opt.backspace = "indent,eol,start" -- allow backspace on indent, end of line or insert mode start position

-- clipboard
opt.clipboard:append("unnamedplus") -- use system clipboard as default register

-- split windows
opt.splitright = true -- split vertical window to the right
opt.splitbelow = true -- split horizontal window to the bottom

Last the init file is where I bundle all of them as lua will execute the init first for each directory, so the content is simply this:

require("charly3pins.core.options")
require("charly3pins.core.keymaps")
require("charly3pins.core.autocommands")

Lazy config

As I said, I use lazy.nvim as the plugin manager for Neovim so the next step is to go up one directory and edit our lazy.lua file to add the following:

local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    "git",
    "clone",
    "--filter=blob:none",
    "https://github.com/folke/lazy.nvim.git",
    "--branch=stable", -- latest stable release
    lazypath,
  })
end
vim.opt.rtp:prepend(lazypath)

require("lazy").setup({ { import = "charly3pins.plugins" }, { import = "charly3pins.plugins.lsp" } }, {
    change_detection = {
        notify = false,
    }
})

For more details, you can find the documentation in the GitHub page.

Wrap the initial config

Once you have the core configuration files in place and the lazy.nvim config there is one step more you need to do before you can start playing around with the plugins.

Go to the root folder:

cd ~/.config/nvim

and edit your init.lua file and add the following:

require("charly3pins.core")
require("charly3pins.lazy")

Now you just need to restart the terminal, and if you open again your Neovim, you will be able to type :Lazy and see the plugin working.

Your folder structure should look like this:

  lua
    charly3pins
      core
    │ │  autocommands.lua
    │ │  init.lua
    │ │  keymaps.lua
    │ └  options.lua
      plugins
    └  lazy.lua
   init.lua

My plugins

Here I will share the list of all the plugins that I use and their configuration. For more details please refer to each documentation or ask me a question below.

Each plugin needs to have a file with its name (the title in each section) .lua, like alpha.lua.

alpha

A lua powered greeter.

return {
  "goolord/alpha-nvim",
  event = "VimEnter",
  config = function()
    local alpha = require("alpha")
    local dashboard = require("alpha.themes.dashboard")

    -- Set header
    dashboard.section.header.val = {
      "                                                     ",
      "  ███╗   ██╗███████╗ ██████╗ ██╗   ██╗██╗███╗   ███╗ ",
      "  ████╗  ██║██╔════╝██╔═══██╗██║   ██║██║████╗ ████║ ",
      "  ██╔██╗ ██║█████╗  ██║   ██║██║   ██║██║██╔████╔██║ ",
      "  ██║╚██╗██║██╔══╝  ██║   ██║╚██╗ ██╔╝██║██║╚██╔╝██║ ",
      "  ██║ ╚████║███████╗╚██████╔╝ ╚████╔╝ ██║██║ ╚═╝ ██║ ",
      "  ╚═╝  ╚═══╝╚══════╝ ╚═════╝   ╚═══╝  ╚═╝╚═╝     ╚═╝ ",
      "                                                     ",
    }

    -- Set menu
    dashboard.section.buttons.val = {
      dashboard.button("e", "  > New File", "<cmd>ene<CR>"),
      dashboard.button("SPC ee", "  > Toggle file explorer", "<cmd>NvimTreeToggle<CR>"),
      dashboard.button("SPC ff", "󰱼 > Find File", "<cmd>Telescope find_files<CR>"),
      dashboard.button("SPC fs", "  > Find Word", "<cmd>Telescope live_grep<CR>"),
      dashboard.button("SPC wr", "󰁯  > Restore Session For Current Directory", "<cmd>SessionRestore<CR>"),
      dashboard.button("q", " > Quit NVIM", "<cmd>qa<CR>"),
    }

    -- Send config to alpha
    alpha.setup(dashboard.opts)

    -- Disable folding on alpha buffer
    vim.cmd([[autocmd FileType alpha setlocal nofoldenable]])
  end,
}

auto-session

A small automated session manager for Neovim.

return {
  "rmagatti/auto-session",
  config = function()
    local auto_session = require("auto-session")

    auto_session.setup({
      auto_restore_enabled = false,
      auto_session_suppress_dirs = { "~/", "~/Dev/", "~/Downloads", "~/Documents", "~/Desktop/" },
    })

    local keymap = vim.keymap

    keymap.set("n", "<leader>wr", "<cmd>SessionRestore<CR>", { desc = "Restore session for cwd" }) -- restore last workspace session for current directory
    keymap.set("n", "<leader>ws", "<cmd>SessionSave<CR>", { desc = "Save session for auto session root dir" }) -- save workspace session for current working directory
  end,
}

bufferline

A snazzy bufferline for Neovim.

return {
  "akinsho/bufferline.nvim",
  dependencies = { "nvim-tree/nvim-web-devicons" },
  version = "*",
  opts = {
    options = {
      mode = "tabs",
      separator_style = "slant",
    },
  },
}

colorscheme

Scheme of colors for Neovim.
I've been using the gruvbox for so long but I discovered a few weeks ago the craftzdog`s one and I am still using it, so I will share these 2 plus the tokyonight built by the one and only folke.

nvim -- return { -- "ellisonleao/gruvbox.nvim", -- priority = 1000, -- make sure to load this before all the other start plugins -- config = function() -- vim.cmd("colorscheme gruvbox") -- end, -- } -- return { -- "folke/tokyonight.nvim", -- priority = 1000, -- Make sure to load this before all the other start plugins. -- init = function() -- -- Load the colorscheme here. -- -- Like many other themes, this one has different styles, and you could load -- -- any other, such as 'tokyonight-storm', 'tokyonight-moon', or 'tokyonight-day'. -- vim.cmd.colorscheme("tokyonight-night") -- end, -- } return { "craftzdog/solarized-osaka.nvim", lazy = false, priority = 1000, opts = {}, config = function() vim.cmd("colorscheme solarized-osaka") end, }

comment

Comment plugin for Neovim.

`nvim
return {
"numToStr/Comment.nvim",
event = { "BufReadPre", "BufNewFile" },
dependencies = {
"JoosepAlviste/nvim-ts-context-commentstring",
},
config = function()
-- import comment plugin safely
local comment = require("Comment")

local ts_context_commentstring = require("ts_context_commentstring.integrations.comment_nvim")

-- enable comment
comment.setup({
  -- for commenting tsx, jsx, svelte, html files
  pre_hook = ts_context_commentstring.create_pre_hook(),
})

end,
}
`

dressing

Neovim plugin to improve the default vim.ui interfaces.

nvim return { "stevearc/dressing.nvim", event = "VeryLazy", }

formatting

Lightweight yet powerful formatter plugin for Neovim.

Here I have the configuration for my most used programming languages like go, python and web development. Also for the config files like json and yaml and my writing in markdown.

`nvim
return {
"stevearc/conform.nvim",
event = { "BufReadPre", "BufNewFile" },
config = function()
local conform = require("conform")

    conform.setup({
        formatters_by_ft = {
            css = { "prettier" },
            html = { "prettier" },
            json = { "prettier" },
            yaml = { "prettier" },
            markdown = { "prettier" },
            lua = { "stylua" },
            python = { "isort", "black" },
            go = { "goimports", "gofmt" },
        },
        format_on_save = {
            lsp_fallback = true,
            async = false,
            timeout_ms = 1000,
        },
    })

    vim.keymap.set({ "n", "v" }, "<leader>cp", function()
        conform.format({
            lsp_fallback = true,
            async = false,
            timeout_ms = 1000,
        })
    end, { desc = "Format file or range (in visual mode)" })
end,

}
`

gitsigns

Git integration for buffers.

`nvim
return {
"lewis6991/gitsigns.nvim",
event = { "BufReadPre", "BufNewFile" },
opts = {
on_attach = function(bufnr)
local gs = package.loaded.gitsigns

  local function map(mode, l, r, desc)
    vim.keymap.set(mode, l, r, { buffer = bufnr, desc = desc })
  end

  -- Navigation
  map("n", "]h", gs.next_hunk, "Next Hunk")
  map("n", "[h", gs.prev_hunk, "Prev Hunk")

  -- Actions
  map("n", "<leader>hs", gs.stage_hunk, "Stage hunk")
  map("n", "<leader>hr", gs.reset_hunk, "Reset hunk")
  map("v", "<leader>hs", function()
    gs.stage_hunk({ vim.fn.line("."), vim.fn.line("v") })
  end, "Stage hunk")
  map("v", "<leader>hr", function()
    gs.reset_hunk({ vim.fn.line("."), vim.fn.line("v") })
  end, "Reset hunk")

  map("n", "<leader>hS", gs.stage_buffer, "Stage buffer")
  map("n", "<leader>hR", gs.reset_buffer, "Reset buffer")

  map("n", "<leader>hu", gs.undo_stage_hunk, "Undo stage hunk")

  map("n", "<leader>hp", gs.preview_hunk, "Preview hunk")

  map("n", "<leader>hb", function()
    gs.blame_line({ full = true })
  end, "Blame line")
  map("n", "<leader>hB", gs.toggle_current_line_blame, "Toggle line blame")

  map("n", "<leader>hd", gs.diffthis, "Diff this")
  map("n", "<leader>hD", function()
    gs.diffthis("~")
  end, "Diff this ~")

  -- Text object
  map({ "o", "x" }, "ih", ":<C-U>Gitsigns select_hunk<CR>", "Gitsigns select hunk")
end,

},
}
`

indent-blankline

Indent guides for Neovim.

nvim return { "lukas-reineke/indent-blankline.nvim", event = { "BufReadPre", "BufNewFile" }, main = "ibl", opts = { -- indent = { char = "┊" }, indent = { char = "│", tab_char = "│", }, } }

init.lua

As with other directories, this is not a plugin it's just the entry file that lua looks for in each directory.

nvim return { "nvim-lua/plenary.nvim", -- lua functions that many plugins use "christoomey/vim-tmux-navigator", -- tmux & split window navigation }

lazygit

Plugin for calling lazygit from within Neovim.

To make sure this works, install it using brew first:

sh brew install jesseduffield/lazygit/lazygit

nvim return { "kdheepak/lazygit.nvim", cmd = { "LazyGit", "LazyGitConfig", "LazyGitCurrentFile", "LazyGitFilter", "LazyGitFilterCurrentFile", }, -- optional for floating window border decoration dependencies = { "nvim-lua/plenary.nvim", }, -- setting the keybinding for LazyGit with 'keys' is recommended in -- order to load the plugin when the command is run for the first time keys = { { "<leader>lg", "<cmd>LazyGit<cr>", desc = "Open lazy git" }, }, }

linting

An asynchronous linter plugin for Neovim complementary to the built-in Language Server Protocol support.

`nvim
return {
"mfussenegger/nvim-lint",
event = { "BufReadPre", "BufNewFile" },
config = function()
local lint = require("lint")

lint.linters_by_ft = {
  go = { "golangcilint" },
  python = { "pylint" },
}

local lint_augroup = vim.api.nvim_create_augroup("lint", { clear = true })

vim.api.nvim_create_autocmd({ "BufEnter", "BufWritePost", "InsertLeave" }, {
  group = lint_augroup,
  callback = function()
    lint.try_lint()
  end,
})

vim.keymap.set("n", "<leader>l", function()
  lint.try_lint()
end, { desc = "Trigger linting for current file" })

end,
}
`

lualine

A blazing fast and easy to configure Neovim statusline plugin written in pure lua.

`nvim
return {
"nvim-lualine/lualine.nvim",
dependencies = { "nvim-tree/nvim-web-devicons" },
config = function()
local lualine = require("lualine")

local colors = {
  blue = "#65D1FF",
  green = "#3EFFDC",
  violet = "#FF61EF",
  yellow = "#FFDA7B",
  red = "#FF4A4A",
  fg = "#c3ccdc",
  bg = "#112638",
  inactive_bg = "#2c3043",
}

local my_lualine_theme = {
  normal = {
    a = { bg = colors.blue, fg = colors.bg, gui = "bold" },
    b = { bg = colors.bg, fg = colors.fg },
    c = { bg = colors.bg, fg = colors.fg },
  },
  insert = {
    a = { bg = colors.green, fg = colors.bg, gui = "bold" },
    b = { bg = colors.bg, fg = colors.fg },
    c = { bg = colors.bg, fg = colors.fg },
  },
  visual = {
    a = { bg = colors.violet, fg = colors.bg, gui = "bold" },
    b = { bg = colors.bg, fg = colors.fg },
    c = { bg = colors.bg, fg = colors.fg },
  },
  command = {
    a = { bg = colors.yellow, fg = colors.bg, gui = "bold" },
    b = { bg = colors.bg, fg = colors.fg },
    c = { bg = colors.bg, fg = colors.fg },
  },
  replace = {
    a = { bg = colors.red, fg = colors.bg, gui = "bold" },
    b = { bg = colors.bg, fg = colors.fg },
    c = { bg = colors.bg, fg = colors.fg },
  },
  inactive = {
    a = { bg = colors.inactive_bg, fg = colors.semilightgray, gui = "bold" },
    b = { bg = colors.inactive_bg, fg = colors.semilightgray },
    c = { bg = colors.inactive_bg, fg = colors.semilightgray },
  },
}

-- configure lualine with modified theme
lualine.setup({
  options = {
    theme = my_lualine_theme,
  },
})

end,
}
`

markdown-preview

Markdown preview plugin for Neovim.

`nvim
return {
"iamcco/markdown-preview.nvim",
cmd = { "MarkdownPreviewToggle", "MarkdownPreview", "MarkdownPreviewStop" },
ft = { "markdown" },
build = function()
vim.fn"mkdp#util#install"
end,
config = function()
local keymap = vim.keymap

    keymap.set("n", "<leader>mp", "<cmd>MarkdownPreview<cr>", { desc = "Markdown Preview" })
    keymap.set("n", "<leader>ms", "<cmd>MarkdownPreviewStop<cr>", { desc = "Markdown Preview Stop" })
    keymap.set("n", "<leader>mt", "<cmd>MarkdownPreviewToggle<cr>", { desc = "Markdown Preview Toggle" })
end,

}
`

mini

Neovim Lua plugin to visualize and operate on indent scope. Part of 'mini.nvim' library.

nvim return { "echasnovski/mini.indentscope", version = false, opts = { symbol = "│", }, }

nvim-cmp

A completion plugin for Neovim coded in Lua.

`nvim
return {
"hrsh7th/nvim-cmp",
event = "InsertEnter",
dependencies = {
"hrsh7th/cmp-buffer", -- source for text in buffer
"hrsh7th/cmp-path", -- source for file system paths
{
"L3MON4D3/LuaSnip",
-- follow latest release.
version = "v2.*", -- Replace by the latest released major (first number of latest release)
-- install jsregexp (optional!).
build = "make install_jsregexp",
},
"saadparwaiz1/cmp_luasnip", -- for autocompletion
"rafamadriz/friendly-snippets", -- useful snippets
"onsails/lspkind.nvim", -- vs-code like pictograms
},
config = function()
local cmp = require("cmp")

local luasnip = require("luasnip")

local lspkind = require("lspkind")

-- loads vscode style snippets from installed plugins (e.g. friendly-snippets)
require("luasnip.loaders.from_vscode").lazy_load()

cmp.setup({
  completion = {
    completeopt = "menu,menuone,preview,noselect",
  },
  snippet = { -- configure how nvim-cmp interacts with snippet engine
    expand = function(args)
      luasnip.lsp_expand(args.body)
    end,
  },
  mapping = cmp.mapping.preset.insert({
    ["<C-k>"] = cmp.mapping.select_prev_item(), -- previous suggestion
    ["<C-j>"] = cmp.mapping.select_next_item(), -- next suggestion
    ["<C-b>"] = cmp.mapping.scroll_docs(-4),
    ["<C-f>"] = cmp.mapping.scroll_docs(4),
    ["<C-Space>"] = cmp.mapping.complete(), -- show completion suggestions
    ["<C-e>"] = cmp.mapping.abort(), -- close completion window
    ["<CR>"] = cmp.mapping.confirm({ select = false }),
  }),
  -- sources for autocompletion
  sources = cmp.config.sources({
            { name = "nvim_lsp" }, -- lsp
    { name = "luasnip" }, -- snippets
    { name = "buffer" }, -- text within current buffer
    { name = "path" }, -- file system paths
  }),

  -- configure lspkind for vs-code like pictograms in completion menu
  formatting = {
    format = lspkind.cmp_format({
      maxwidth = 50,
      ellipsis_char = "...",
    }),
  },
})

end,
}
`

nvim-tree

A file explorer tree for Neovim written in lua.

`nvim
return {
"nvim-tree/nvim-tree.lua",
dependencies = "nvim-tree/nvim-web-devicons",
config = function()
local nvimtree = require("nvim-tree")

-- recommended settings from nvim-tree documentation
vim.g.loaded_netrw = 1
vim.g.loaded_netrwPlugin = 1

nvimtree.setup({
  view = {
    width = 35,
    relativenumber = true,
  },
  -- change folder arrow icons
  renderer = {
    indent_markers = {
      enable = true,
    },
    icons = {
      glyphs = {
        folder = {
          arrow_closed = "", -- arrow when folder is closed
          arrow_open = "", -- arrow when folder is open
        },
      },
    },
  },
  -- disable window_picker for
  -- explorer to work well with
  -- window splits
  actions = {
    open_file = {
      window_picker = {
        enable = false,
      },
    },
  },
  filters = {
    custom = { ".DS_Store" },
  },
  git = {
    ignore = false,
  },
})

-- set keymaps
local keymap = vim.keymap

keymap.set("n", "<leader>ee", "<cmd>NvimTreeToggle<CR>", { desc = "Toggle file explorer" }) -- toggle file explorer
keymap.set("n", "<leader>ef", "<cmd>NvimTreeFindFileToggle<CR>", { desc = "Toggle file explorer on current file" }) -- toggle file explorer on current file
keymap.set("n", "<leader>ec", "<cmd>NvimTreeCollapse<CR>", { desc = "Collapse file explorer" }) -- collapse file explorer
keymap.set("n", "<leader>er", "<cmd>NvimTreeRefresh<CR>", { desc = "Refresh file explorer" }) -- refresh file explorer

end
}
`

surround

Add/change/delete surrounding delimiter pairs with ease.

nvim return { "kylechui/nvim-surround", event = { "BufReadPre", "BufNewFile" }, version = "*", -- Use for stability; omit to usemainbranch for the latest features config = true, }

telescope

A fuzzy finder over lists offering the following options: Find, Filter, Preview, Pick.

`nvim
return {
"nvim-telescope/telescope.nvim",
branch = "0.1.x",
dependencies = {
"nvim-lua/plenary.nvim",
{ "nvim-telescope/telescope-fzf-native.nvim", build = "make" },
"nvim-tree/nvim-web-devicons",
},
config = function()
local telescope = require("telescope")
local actions = require("telescope.actions")

telescope.setup({
  defaults = {
    path_display = { "smart" },
    mappings = {
      i = {
        ["<C-k>"] = actions.move_selection_previous, -- move to prev result
        ["<C-j>"] = actions.move_selection_next, -- move to next result
        ["<C-q>"] = actions.send_selected_to_qflist + actions.open_qflist, -- send selected items to quickfix list
      },
    },
  },
})

telescope.load_extension("fzf")

-- set keymaps
local keymap = vim.keymap

keymap.set("n", "<leader>ff", "<cmd>Telescope find_files<cr>", { desc = "Fuzzy find files in cwd" })
keymap.set("n", "<leader>fr", "<cmd>Telescope oldfiles<cr>", { desc = "Fuzzy find recent files" })
keymap.set("n", "<leader>fs", "<cmd>Telescope live_grep<cr>", { desc = "Find string in cwd" })
keymap.set("n", "<leader>fc", "<cmd>Telescope grep_string<cr>", { desc = "Find string under cursor in cwd" })

end,
}
`

todo-comments

Highlight, list and search todo comments in your projects.

`nvim
return {
"folke/todo-comments.nvim",
event = { "BufReadPre", "BufNewFile" },
dependencies = { "nvim-lua/plenary.nvim" },
config = function()
local todo_comments = require("todo-comments")

-- set keymaps
local keymap = vim.keymap -- for conciseness

keymap.set("n", "]t", function()
  todo_comments.jump_next()
end, { desc = "Next todo comment" })

keymap.set("n", "[t", function()
  todo_comments.jump_prev()
end, { desc = "Previous todo comment" })

todo_comments.setup()

end,
}
`

treesitter

Highlighting plugin.

Here are my most used languages as before with an extra config for using with templ.

`nvim
return {
"nvim-treesitter/nvim-treesitter",
event = { "BufReadPre", "BufNewFile" },
build = ":TSUpdate",
dependencies = {
"windwp/nvim-ts-autotag",
"vrischmann/tree-sitter-templ",
},
config = function()
vim.treesitter.language.register("templ", "templ")

    local treesitter = require("nvim-treesitter.configs")

    -- configure treesitter
    treesitter.setup({
        highlight = {
            enable = true,
        },
        indent = { enable = true },
        autotag = {
            enable = true,
        },
        ensure_installed = {
            "json",
            "yaml",
            "html",
            "css",
            "go",
            "templ",
            "markdown",
            "markdown_inline",
            "bash",
            "lua",
            "vim",
            "dockerfile",
            "gitignore",
            "query",
            "vimdoc",
            "dart",
            "python",
        },
        incremental_selection = {
            enable = true,
            keymaps = {
                init_selection = "<C-space>",
                node_incremental = "<C-space>",
                scope_incremental = false,
                node_decremental = "<bs>",
            },
        },
    })
end,

}
`

trouble

A pretty diagnostics, references, telescope results, quickfix and location list to help you solve all the trouble your code is causing.

nvim return { "folke/trouble.nvim", dependencies = { "nvim-tree/nvim-web-devicons", "folke/todo-comments.nvim" }, keys = { { "<leader>xx", "<cmd>TroubleToggle<CR>", desc = "Open/close trouble list" }, { "<leader>xw", "<cmd>TroubleToggle workspace_diagnostics<CR>", desc = "Open trouble workspace diagnostics" }, { "<leader>xd", "<cmd>TroubleToggle document_diagnostics<CR>", desc = "Open trouble document diagnostics" }, { "<leader>xq", "<cmd>TroubleToggle quickfix<CR>", desc = "Open trouble quickfix list" }, { "<leader>xl", "<cmd>TroubleToggle loclist<CR>", desc = "Open trouble location list" }, { "<leader>xt", "<cmd>TodoTrouble<CR>", desc = "Open todos in trouble" }, }, }

vim-maximizer

Maximizes and restores the current window in Vim.

nvim return { "szw/vim-maximizer", keys = { { "<leader>sm", "<cmd>MaximizerToggle<CR>", desc = "Maximize/minimize a split" }, }, }

which-key

Helps you remember your Neovim keymaps, by showing available keybindings in a popup as you type.

nvim return { "folke/which-key.nvim", event = "VeryLazy", init = function() vim.o.timeout = true vim.o.timeoutlen = 500 end, opts = {}, }

Conclusion

If you got here, congratulations because the list, as you can see, is quite extensive.

As you probably know, the list of plugins for Neovim is tremendously huge and sometimes it can make us anxious and generate doubts about how we can start and which plugins can help us.

I hope that with this list of mine and the ready-to-use configuration that I have left you, you can have a starting point and start creating your own editor to your liking little by little until you reach the perfect configuration for you.

If you have plugins that you have not seen on my list that you think are interesting for me to try, please share them with me since I always like to discover and try new things, I would really appreciate it.

I hope everything that I have tried to explain in this post has been clear, and please if there is any part that has not been completely clear or there are parts that I have not covered that you would like me to do, leave me a comment right here or through my social networks that you have on my profile and I will be happy to respond.

Happy coding!

{C3P}

Maps in Go

charly3pins — Mon, 22 Jul 2024 12:48:57 +0000

Intro

Go incorporates a native type that implements hash tables called map. It is a data type made up of a collection of unique keys and a collection of values for each of those keys.
It can be compared to a dictionary in other languages, for example, which stores key-value pairs. These values are accessed using keys, in the same way as arrays and slices as we saw in the previous post.
The indexes are not limited to a number as in arrays or slices and the elements are not ordered, so if we print a map it will return a random order, if we do nothing to override its printing and force the desired order.

Map declaration and initialization

To declare a map it is done with map[key]value, where key will be the type we want our key to be (it must be of a comparable type https://go.dev/ref/spec#Comparison_operators) and value will be the type that we want the map to be stored in each of the keys, whatever type it is, from an int to a struct, or another map, whatever we want.

As with slices, maps are referenced types, which means that the zero value of a map will be nil.
This happens because underneath it there is a hash table which stores the keys and values, and they are simply an envelope, abstraction, of them.

If we declare it as:

var m map[int]int

its value will be nil.

If we want it to have a zero value, we can use the declaration:

m := map[int]int{}

And we can even initialize it just like the slices, using the make function.

m := make(map[string]string)

Doing this will initialize a hash map with the appropriate memory pool for it, thus returning a map that points to that data structure.

Adding and reading values from a map

Adding values to a map is done by using curly braces [] and the curly brace, just like with arrays or slices. In this example we will create a map with the keys being strings and the values being integers, to store names and ages.

ages := make(map[string]int)

ages["John"] = 33
ages["Charly"] = 27
ages["Jenny"] = 45
ages["Lisa"] = 19

If we want to add the values to it when we declare the map, we can use the short declaration and do it all in the same step:

ages := map[string]int{"John": 33, "Charly": 27, "Jenny": 45, "Lisa": 19}

To read the values, we simply have to indicate the key to our map and it will return that value. For example, to find out Lisa's age, we can do:

fmt.Println(ages["Lisa"]) // 19

If we try to access a key that does not exist, the value obtained will be the zero value of the type, in this case it would be "", since it is a string.

In order to check if an element exists in the map, we can check if the type is the default, but it is not very reliable, since perhaps it exists but its value is an empty string or 0 in the case of int, which would match with its zero value, so Go helps us with the following:

val, ok := ages["Randy"]

If we equal the map to two values, the first will be the value of that element accessed through the key, in this case "Randy" which does not exist, and the second will be a boolean, which will indicate whether it exists or not.

If we are not interested in the value and simply want to check for the existence of a key, we can use _ to ignore the value as follows:

_, ok := ages["Randy"]

As with arrays and slices, we can use the len function to find out how many elements there are in the map.

fmt.Println(len(ages)) // 4

If we want to modify a value, it is as simple as accessing said value using a key and matching it with another, and it will be modified.

If we declare a second map pointing to the first, if we modify the value of the second, since it is a referenced type, we will be modifying the value of the first, because both share the same hash table underneath.

ages := map[string]int{"John": 33, "Charly": 27, "Jenny": 45, "Lisa": 19}
agesNew := ages
agesNew["Bryan"] = 77
fmt.Println(agesNew) // map[Bryan:77 Charly:27 Jenny:45 John:33 Lisa:19]
fmt.Println(ages) // map[Bryan:77 Charly:27 Jenny:45 John:33 Lisa:19]

Removing values from a map

To delete elements from a map, Go provides us with a delete function with the following signature delete(m map[Type]Type1, key Type) which receives a map and the key to be deleted.
In the previous case, if we wanted to eliminate "Lisa" we would do it:

delete(ages, "Lisa")

Looping through maps

If we want to go through the content of a map, we can do it using a for with the variation of range that we already saw in the post on arrays and slices.
As then, the first element will be the index, therefore the key, and the second the value.

for key, value := range ages {
    fmt.Printf("%s: %d\n", key, value)
}

// Output:
// Jenny: 45
// Lisa: 19
// John: 33
// Charly: 27

As with arrays and slices, if we are only interested in the value, without the key, we can omit it by using _.

for _, value := range ages {
    fmt.Println(value)
}

// Output:
// 19
// 33
// 27
// 45

And if what interests us is simply the key, we can assign the range to a single variable to obtain it:

for key := range ages {
    fmt.Println(key)
}

// Output:
// John
// Charly
// Jenny
// Lisa

Sort a map

As I mentioned in the introduction, in a map the information is not ordered, so when looping through it we cannot specify what order it follows, nor can Go guarantee that the order between executions is the same.
As we saw with arrays and slices, in the standard library there is a sort package which helps us sort elements: https://pkg.go.dev/sort

Following our example with ages and using sort, we can sort the keys of the map before traversing it and thus guarantee that it will be accessed in order.

ages := map[string]int{"John": 33, "Charly": 27, "Jenny": 45, "Lisa": 19}
keys := make([]string, 0, len(ages))
for k := range ages {
    keys = append(keys, k)
}
sort.Strings(keys)
for _, k := range keys {
    fmt.Println(k, ages[k])
}

// Output:
// Charly 27
// Jenny 45
// John 33
// Lisa 19

We declare our ages map with the short declaration as we saw before.
We create a string slices to store the keys and use the make method with 0 length, since we do not have any keys at the moment, but we do reserve the capacity it will have using the len method for the length of our map.
We go through the ages map to keep its keys and add them to the created slice.
We sort the keys alphabetically with the sort.Strings function.
We go through the slice of keys, already ordered, and access the map with the key in question.
This way we will access the map in an orderly manner and we can do the logic that our program needs.

Problems with Concurrency

Something to keep in mind with maps is that they are not safe to use concurrently. If these are concurrent reads, either accessing a value or through a for with a range, there is no problem with multiple goroutines accessing it at the same time.
The problematic case is when you want to update the value of a map concurrently, either by adding or removing elements from it, and at the same time you are reading it from another side, for example.
To solve this situation there are several possible solutions, which I will not go into much detail, I will simply mention and leave it to your choice to delve deeper into them.

If we use the sync package: https://pkg.go.dev/sync from the standard library, we can control the synchrony between the different goroutines.
A possible use is the RWMutex type which allows us to lock and unlock reads and writes to a type. So if we have a type that contains a sync.RWMutex and a map we can control when it can be accessed.
Another interesting type to investigate within the same sync package is Map, which already offers us a series of functions that will help us work with our map, which in the end we will not be able to work with natively, as with the previous solution.
Depending on the use case we are implementing, one or the other will be more useful to us, and there is no one better than the other, it will always depend on what we need.

Arrays and slices in Go

charly3pins — Mon, 13 May 2024 07:47:19 +0000

Intro

When we want to group a series of elements of the same type we can do it in Go in two ways, using arrays or slices.
Arrays have the particularity that their size is fixed and cannot be modified.
The slices, on the other hand, have a dynamic size, so we can modify them according to our needs.

Let's see an example of using slices with a "game" and thus understand why arrays are important if we are talking about slices.

a := []int{1, 2, 3}
fmt.Println(a)

b := append(a[:1], 10)
fmt.Println(b)

// print original slice
fmt.Println(a)
/// WTF???

Arrays

Arrays are nothing more than a type of data to store information of the same type, sequentially, accessing it in an indexed manner.
Arrays are values, so if we assign one array to another, all the elements from one to the other will be copied. The same thing happens in functions, you will not receive a pointer to the array, but a copy of it. The size of the array is part of its type, so [2]int is different from [10]int.
The memory representation of an array can be seen in the following image, where it is stored in as many positions as the type indicates and in adjacent positions for that type.

Using arrays

There are several ways to declare an array, let's see how we can do it.

var languages [5]string

Thus we will have an array with zero value, and as we observe we will have 5 positions with empty text, since it is the zero value of the string type that we have chosen.

To initialize the elements of the array we can do so by accessing each position by its index and indicating what value we give it:

languages[0] = "English"
languages[1] = "Spanish"
languages[2] = "Japanese"
languages[3] = "German"
languages[4] = "French"

We can also use the short statement and do it all in the same step:

languages := [5]string{"English", "Spanish", "Japanese", "German", "French"}

The same applies to arrays of other types, for example with integers.

var nums [10]int
fmt.Println(nums) // [0 0 0 0 0 0 0 0 0 0]
// init values
nums[0] = 7
nums[1] = 444
nums[8] = 38
nums[9] = 60
fmt.Println(nums) // [7 4444 0 0 0 0 38 60]

To access the elements, we use the braces [ and ] indicating the index of the position to which we want to assign the value.

There are two functions that come in Go that help us work with arrays.
len() to know its length and cap() to know its capacity.

If we use them with the previous example we will see that in both cases it returns 10.

fmt.Println(len(numeros)) // 10
fmt.Println(cap(numeros)) // 10

In the case of arrays, the capacity is not used because it is equal to the length, so len() is enough for us. Its most recurrent use is in loops to indicate that it must increase the index to the maximum -1 (the first index is 0) and access the different elements. We will see it later.

Multidimensional arrays

Arrays can have more than one dimension. To do this, you must add the braces [ and ] and the number of elements of that dimension again.

We can declare a multidimensional array to store animals and their sounds in the following way:

animalSounds := [5][2]string{
    {"lion", "roar"},
    {"dog", "barks"},
    {"cat", "meows"},
    {"frog", "croaks"},
    {"elephant", "trumpets"},
}

De esta forma le hemos indicado al compilador que nuestro array va a tener 5 elementos, con 2 elementos cada uno, es decir una matriz de 10 elementos, de tipo string.

Looping through arrays

We have seen that to access the arrays we can use the keys [] so if we make a loop that increases the value of the index it will return its values.

languages := [5]string{"English", "Spanish", "Japanese", "German", "French"}

for i:=0;i<len(languages);i++ {
    fmt.Println(languages[i])
}

This is very good, but Go offers us a specific function that simplifies this for us, the range. With range, known in other languages as foreach, the array is automatically traversed without having to worry about incrementing the index in the following way.

languages := [5]string{"English", "Spanish", "Japanese", "German", "French"}

for index, value := range languages {
    fmt.Println(index)
    fmt.Println(value)
}

As we see, it is much simpler than not working with indexes if we do not have any extra requirements regarding access to it.

If we are only interested in the value, and not the index, we can omit it using the _ operator.

languages := [5]string{"English", "Spanish", "Japanese", "German", "French"}

for _, value := range languages {
    fmt.Println(value)
}

On the other hand, if we are only interested in the index, we can set the range equal to a single variable, and this will be the index.

languages := [5]string{"English", "Spanish", "Japanese", "German", "French"}

for index := range languages {
    fmt.Println(index)
}

Search in arrays

If what we want is to know if there is an element in an array, that is, to do a search to find it, we can use the loops as we have seen previously and check each value if it is the one we were looking for, to return it or do whatever we need .

languages := [5]string{"English", "Spanish", "Japanese", "German", "French"}
pattern := "Japanese"
for _, value := range languages {
    if value == pattern {
        // DO LOGIC
        break
    }
}

In this example we have introduced the word break which breaks the loop and exits it. It seems reasonable in the example that if we find the language we are looking for, we leave the array, but perhaps it is not what you want, so it is not mandatory to use it.

Add or remove elements in arrays

As we have seen before, an array has a fixed type which indicates a length that cannot be changed. If we want to add or remove elements we can only do so by creating another array with the desired length, whether greater or less than the original.

This makes it a data type that is inflexible and sometimes annoying to work with. Luckily the Go geniuses thought of everything and created another type that solves many of these problems, the Slice.

Slices

Slices can be defined as arrays of dynamic length. In reality, what happens is that slices are an abstraction created on top of arrays, offering us greater control and flexibility to work with them.

What happens below is that every time we define a slice, an array is created below that we do not see, and the slice points to it using a pointer.
For this reason, the zero value of the slice will not be N elements with zero value, with N being the length, as was the case with arrays, but will be nil, since there will be no array below to point to, so we will not have initialized pointer.

Using slices

To declare a slice it is done in the same way as we have seen previously with arrays, with the only difference that we do not specify the length.

animals := []string{"dog", "cat", "bird", "horse"}

As I said before, if we do not pass values, the zero value will not be empty strings, since since it does not have a length, how many should it have? So the zero value will be nil.

To create slices there is also the make function which has the following signature:

func make([]T, len, cap) []T

T is the type of elements we want in the slice, len is the length, and cap is the capacity, which is optional. If a capacity is not passed, by default the length is taken as the value.

Another way to create a slice is to "cut" it. To do this, an open midrange is used with two indices separated by two points.
In the animals example above, if we were to do animals[1:3], it would create a slice including elements 1 through 3 of animals, so "horse" would not be included in the new slice.

The start and end in the indexes of a slice are optional so we can call it in these 3 ways:

fmt.Println(animals[:2]) // [dog cat]
fmt.Println(animals[3:]) // [horse]
fmt.Println(animals[:])  // [dog cat bird horse]

To create a slice from an array we can use the last form [:]:

languages := [5]string{"English", "Spanish", "Japanese", "German", "French"}
sLanaguages := languages[:]

What must be taken into account using this method is that a copy of the array is not made below the slice, access to it is simply limited according to the range of the new slice.
This means that if we have a slice with 1000 elements, and we make a new one with a range of 10 elements [:10], what will happen is that in the new slice we will only have 10 elements, but the array below will still have the 1000.
Occasionally, this can cause the program to keep all of the data in memory when only a small portion is needed.

Add elements to a slice

As we saw before, an array cannot modify its length since it is part of its type, but the same does not happen with slices. To do this we have to create a new slice that is longer and copy the elements of the original slice to the new one.
To do this, Go provides us with a function called copy(dst, src []T) int which makes this task easier for us:

languages := []string{"English", "Spanish", "Japanese", "German", "French"}
newLanguages := make([]string, len(languages))
copy(newLanguages, languages)

Sometimes what we will need is to add elements to the slice in a more or less dynamic way depending on the case, beyond creating an entire copy of the slice while maintaining both slices at the same time.
Go helps us again with its function append(s []T, x ...T) []T, which adds the element x to the end of the slice, which will grow the capacity of the slice if necessary. Every time this happens, the array below the slice doubles its length, so it is something to keep in mind if we have to do optimization work.

languages := []string{"English", "Spanish", "Japanese", "German", "French"}
languages = append(languages, "Chinese")

In addition to this, we can also add one slice to another with ... as follows:

myNums := []int{1, 2, 3}
yourNums := []int{4, 5, 6}
myNums = append(myNums, yourNums...) // equivalent to append(myNums, yourNums[0], yourNums[1], yourNums[2])
fmt.Println(myNums) // [1 2 3 4 5 6]

Multidimensional slices

Just like with arrays, we can declare multidimensional slices by adding more dimensions by simply adding [] as [][]int.

animalSounds := [][]string{
    {"lion", "roar"},
    {"dog", "barks"},
    {"cat", "meows"},
    {"frog", "croaks"},
    {"elephant", "trumpets"},
}

Loop through slices

As with arrays, we can loop through the slices using the different types of loops.

languages := []string{"English", "Spanish", "Japanese", "German", "French"}

for i:=0;i<len(languages);i++ {
    fmt.Println(languages[i])
}

We can also use range to cycle through the slices.

languages := []string{"English", "Spanish", "Japanese", "German", "French"}

for index, value := range languages {
    fmt.Println(index)
    fmt.Println(value)
}

If we are only interested in the value, and not the index, we can omit it using the _ operator.

languages := []string{"English", "Spanish", "Japanese", "German", "French"}

for _, value := range languages {
    fmt.Println(value)
}

On the other hand, if we are only interested in the index, we can set the range equal to a single variable, and this will be the index.

languages := []string{"English", "Spanish", "Japanese", "German", "French"}

for index := range languages {
    fmt.Println(index)
}

Remove elements from a slice

Unlike arrays, with slices it is possible to eliminate elements from them, using the slicing method that we saw previously.
We must take the slice we want and cut it in part up to the index of the element to be eliminated, and add the same slice but with the remaining part +1, to eliminate the element from the index position.

languages := []string{"English", "Spanish", "Japanese", "German", "French"}
indexToRemove := 3
languages = append(languages[:indexToRemove], languages[indexToRemove+1:]...)

Sort a slice

You can sort the elements of a slice with the Go package sort https://pkg.go.dev/sort.

slice := []int{12, 2, 90, 6, 88, 5, 28, 4}
sort.Ints(slice)
fmt.Println(slice) // [2 4 5 6 12 28 88 90]

languages := []string{"English", "Spanish", "Japanese", "German", "French"}
sort.Strings(languages)
fmt.Println(languages) // [English French German Japanese Spanish]

I recommend checking out the sort package to understand all the options there are.

Search and filter items

As with arrays, to find elements of a slice we must recreate them and check the values of each position and detect if it is what we are looking for.
Additionally, with the slices we can filter these elements, creating a new slice without or with the elements found, depending on what we want.

ages := []int{11, 16, 23, 38, 45}
adults := []int{}
for _, age := range ages {
    if age > 18 {
        adults = append(adults, age)
    }
}

Tips and tricks to code in Go in a clean, functional and effective way

charly3pins — Wed, 08 May 2024 19:30:56 +0000

Variable names

Go manages the visibility with lowercase for unexported and uppercase for exported. These concepts are valid in the context of a package, so if you declare a variable in a package X with the following code:

package X

var foo int // unexported
var Bar int // exported

You will be able to call the variable foo and Bar while you're inside that package, but if you are in another package, you will have access only to the Bar variable.

Package names

Regarding the package names is not recommended to use the underscore _ in the naming, and usually a single word, although it's just a recommendation, so follow them if it makes sense for you.
Also, the package names are used to reference the variables, constants, and types of a package, so having:

package player

type Player struct {}

and calling it from our main package will look like this:

package main

import "player"

myPlayer := player.Player{}

So we see that there is too much player verbosity, so maybe it's better to rethink the name of the package or the name of the struct.

Don't use Getters

If we have a type like:

type Player struct {
    Name string
    Dorsal int
}

don't create getters for each field:

func (p Player) GetName() string {
    return p.Name
}

func (p Player) GetDorsal() int {
    return p.Dorsal
}

Access directly to each field like Player.Name or Player.Dorsal or if you need a function do it without the Get prefix.

Interfaces

The convention for the interfaces says that they should be a single method and named with the method name + -er suffix or similar.

For example, if we want to create an interface for our defenders or strikers in our Team, following the convention we would do it like this:


type Defender interface {
    Defend() error
}

type Striker interface {
    Strike() error
}

Interface composition

When you have a single-methods interface like the ones above, you can create another interface, composing it by those interfaces. So our Player interface will be:

type Player interface {
    Defender
    Striker
}

CamelCase vs snake_case

In Go Camel Case it's the one most used. It's strange to find a snake case in any variable or constant name. In packages I already mentioned that is not recommended but sometimes you need to do it.

Constants

Constants are like variables, but with a constant value. They should not be declared all in upper case like you do in other languages. The unique upper case you should add is the first letter if you want to export it (like variables) or not.

const Minutes = 90
const minutes = 90
const MINUTES = 90 // not recommended

Grouping variables and constants

If you are declaring more than one variable or more than one constant, you can do it as we did here, or you can group them to improve the readability of your code:

const (
    parts = 2
    players = 22
)

var (
    fizz = "fizz"
    buzz = "buzz"
)

This is super useful when you're writing a new function and at the beginning you declare the variables grouped like:

func fn() error {
    var (
        x int
        y byte
        z string
    )
    // Logic here
    return nil
}

Enums

In Go the concept of enums doesn't exist but they can be replicated using constants and a type iota which is an integer enumerator. To do it, you can define your enum as:

type Position int

const (
    Goalkeeper Position = iota
    Defender
    Mid
    Striker
)

With that, you can work with the constants as usual, and they will be of type Position, instead of iota (int).
Declaring it like this is enough most of the time but it introduces a possible bug in your code. The zero-value of the iota is 0, the same as the int, and we know that Go has zero-values by default.
So if you define a new position but you don't initialize it with any of the constants, Since the default position is Goalkeeper, your new default position will be Goalkeeper, and perhaps it is not the behaviour you want the application to have.

You can solve that in 2 ways. The first one is by simply adding +1 to the initial value, so the 0 value will not be any of the ones you defined.

type Position int

const (
    Goalkeeper Position = iota + 1
    Defender
    Mid
    Striker
)

That's OK, but it still has the problem of, which Position is the value 0. To solve this, the common solution is to define the zero value as an Unknown or Default or similar value like:

type Position int

const (
    Unknown Position = iota
    Goalkeeper
    Defender
    Mid
    Striker
)

With these 2 tricks, you are now ready to work with your Position enum. What if you want to print those? They are int, so you will see just numbers... maybe that's not something you care about, but if you do, here is a trick that you can do to work with strings.
Go has the Stringer() interface with its method String() string that you can satisfy with any type you want. Taking advantage of that we can do this:

func (p Position) String() string {
    switch p{
    case Goalkeeper:
        return "Goalkeeper"
    case Defender:
        return "Defender"
    case Mid:
        return "Mid"
    case Striker:
        return "Striker"
    }
    return "Unknown"
}

Constructors

Sometimes the zero value of a type isn't enough and you want to initialize your type. For that, you need to use constructors.

package player

type Player struct {
    Name string
    Dorsal int
}

func NewPlayer(name string, dorsal int) *Player {
    return &Player{
        Name: name,
        Dorsal: dorsal,
    }
}

With the NewPlayer function we initialize the Player values with the information provided as an argument instead of the zero values that would be "" and 0.
Following the naming recommendation that we described before, we can refactor this into something more idiomatic, because now to call that constructor from main would look like this:

package main

import "player"

myPlayer := player.NewPlayer("gopher", 666)

Better if we do a small refactor like:

package player

type Player struct {
    Name string
    Dorsal int
}

func New(name string, dorsal int) *Player {
    return &Player{
        Name: name,
        Dorsal: dorsal,
    }
}

so in our main the readability will be improved as:

package main

import "player"

myPlayer := player.New("gopher", 666)

Multiple return values

In Go, any function or method can return multiple values, from 0 to N. The error usually is returned as the latest value.

// 2 values return
func (Player) Shoot() (int, error) {
    return 99, nil
}
// single value return
func (Player) Refill() error {
    // do logic
    return
}
// no return value
func (p *Player) Substitute(name string) {
    p.Name = name
}

Don't use panic

Most of the time simply returning errors is enough, but what if the error is unrecoverable and the program cannot continue? For that case exists the panic.

The recommendation is to not use panics, but if you need to, the convention says to call the function with the prefix Must. Let's see an example:

// without panic
func ParseFiles() error {
    // do logic
    if err != nil {
        // handle error
        return err
    }
}

//with panic
func MustParseFiles() {
    // do logic
    if err != nil {
        // handle error
        panic()
    }
}

Order declaring functions for a specific type

When you have a new type, as we saw before, most of the time you're going to create a function that acts as a constructor, and probably a list of methods for that type, maybe exported, maybe unexported.

What's the best order to declare each function? Let's see what the convention says.

// first, declare the type
type Shape strut {
    x int
    y int
    color int
}

// next, the constructor
func NewShape(x, y, c int) *Shape {
    return &Shape{
        x: x,
        y: y,
        color: c,
    }
}

// next, the exported methods
func (s *Shape) Paint(c int) {
    s.color = c
}

// last, the unexported methods
func (s *Shape) reset() {
    s.x = 0
    s.y = 0
    s.color = 0
}

Why Go?

charly3pins — Wed, 06 Dec 2023 11:54:34 +0000

First contact

It's been about 8 years since I started playing with Go. At that moment I met a colleague who had left my workplace to try his luck at a new challenge in his professional career. One day talking to him he told me that they had decided to use a programming language called Go and that he was delighted with how easy it was to do things that with Java, the language we were used to using, was tremendously crude and sometimes complex, due to to the number of layers and repetitions you have to add. That's when I told him to show me how it worked and where I met Go.

I tried making some API with an HTTP server and in a matter of minutes, I had it running and launching curls without any problem. That same year, a few months later, I had the opportunity to participate in an operational automation project where he worked and we did it by setting up several APIs in Go. Communicating between them, also with some AWS tools like AWS Lambda coded in Go as well. The project was a success and the biggest company decided to buy that.

After that I continued working with Go in my next (current) company where I worked, building a truly microservices environment with Go as the main language in Backend replacing a Typescript monolith.

Why we have chosen Go? Let me try to number a few things that made us choose Go versus other programming languages.

Manifest

Go code is very obvious, there is the joke that it is a boring code, and that's fantastic.

Go is a really fast language. Because Go is compiled, it will naturally outperform languages that are interpreted or have virtual runtimes. The compiling time is extremely fast, and the resulting binary is very small. That allows you to deploy several times every day, so that follows the DevOps methodology perfectly.

Go's syntax is small but powerful, so it's easy to learn. You can fit most of it in your head, which means you don't need to spend a lot of time looking things up. It's also very clean and easy to read. Non-Go programmers, especially those used to a C-style syntax, can read a Go program and usually understand what's going on.

Go is a strongly, statically typed language. There are primitive types like int, byte, and string. There are also structs. Like any strongly typed language, the type system allows the compiler to help catch entire classes of bugs. Go also has built-in types for lists and maps, and they are easy to use.

Go has interfaces, and any struct can satisfy an interface simply by implementing its methods. Go also has first-class functions, which open up the possibility to write your code in a more functional style.

Go has a nice standard library, so usually the Go programs have few external dependencies. It provides handy built-in functions for working with primitive types. Some packages make it easy to set up a web server, handle I/O, and data manipulation. JSON serialization and deserialization provided by the standard library is trivial.

Go makes concurrency easier than in other languages. Using goroutine(s) and channel(s) it's almost trivial, while more complex patterns are possible.

Go provides out-of-the-box testing support in its standard library. There is no need for an extra dependency. If you have a file called thing.go, write your tests in another file called thing_test.go, and run "go test". Go will execute those tests automatically.

Go static analysis tools are numerous and robust. One in particular is gofmt, which formats your code according to Go's suggested style. Since there is a single code format and a great standard lib, you can focus on creating business value, not discussing where to put this condition or how to define that data structure.

Go provides a memory safe allocating dynamic objects and garbage collecting them, all that is made simpler than C and C++. Also, it makes using pointers much safer because it doesn't allow pointer arithmetic. It also gives you the option of using value types.

Bonus
Go coding style follows the line of sight: the idea is that down the edge of your function, should be the happy path, so it's in the left edge. Anything else, being an error or an edge case, it's not the happy path, so you should indent it. With that, the code is super readable and easy to follow, and you don't need to use else in probably 99% of the cases. When you have in front of you the Go code and you see there is a part of the code indented, you know that's the exit of the function and the happy path it's on the left edge.

Simple, clean, great, GO!

I generated my CV using Go templates

charly3pins — Sat, 23 Sep 2023 09:48:22 +0000

Introduction

If you need to present any kind of data in a structured and formatted way you could find this article interesting. Go provides a way to do this in an easy and effective manner with two packages, text/template and html/template. The first one is focused on formatting texts in general and I am using it to generate my README page in GitHub. You can find the details in https://github.com/charly3pins/charly3pins. In this article, I am going to cover the second one, the templating for HTML pages. It's true that at the end I will generate a PDF from it but let's go step by step!
I recommend you read the documentation page since I'm not going to cover the whys and whats about the package, only showing you how I organized the templates and how I generate my Resume using it.

CV Template

First of all I created a YAML file where I will store all my CV information called me.yaml. The structure that I decided on was the following one:

Name:
Role:
Email:
Web:
Location:

Mission:

Skills:

Experience:
- Role:
  Entity:
  Started:
  Stopped:
  Location:
  Details:

Projects:

Education:

Languages:

Keywords:

(I removed all the data to make it readable but you can get an idea of what is inside each key).

After that, I started creating the base template for the HTML page that I wanted to generate. I stored it inside tmpl/base.html

{{ define "base" }}
<!doctype html>
<html lang='en-US'>
<head>
    <title>{{.Name}} | {{.Role}}</title>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>
<body>
  <main>
  </main>
</body>
</html>
{{ end }}

This is the base only, so there is no data displayed yet, only the Name and the Role.

For maintainability reasons, I split each section of my CV into a partial template. All partial templates I stored inside tmpl/partials/. So for example, I created the about.html that is as simple as:

<div id=about>
  <h1 id=name style='grid-area: name'>{{.Name}}</h1>
  <div id=role style='grid-area: role'>{{.Role}}</div>
  <div id=contact style='grid-area: contact'><a href="mailto:{{.Email}}">{{.Email}}</a> • <a href="{{.Web}}">{{.Web}}</a></div>
</div>

And other(s) with more logic like the experience.html:

<div id=experience>
<h2>Experience</h2>
{{ range .Experience }}
<div class=employer>
  <div class=role>
    <div><strong>{{.Role}}</strong></div>
    <div class=dates>{{.Started}} - {{if .Stopped}}{{.Stopped}}{{else}}Present{{end}}</div>
  </div>
  <div class=entity>{{.Entity}} <span class=loc>({{.Location}})</span></div>
</div>

<ul class=deets>
{{ range .Details }}
  <li class=deet>{{- . -}}</li>
{{end}}
</ul>

</div>
{{end}}

After creating all the needed ones, I added them inside the base one created before using the {{template}} action to invoke the partials in the place that I desired. The resulting base.html looks like:

{{ define "base" }}
<!doctype html>
<html lang='en-US'>
<head>
    <title>{{.Name}} | {{.Role}}</title>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>
<body>
  <main>
    {{ template "about.html" . }}
    {{ template "mission.html" . }}
    <br>
    {{ template "skills.html" . }}
    <br>
    {{ template "experience.html" . }}
    <br>
    {{ template "projects.html" . }}
    <br>
    {{ template "education.html" . }}
    <br>
    {{ template "keywords.html" . }}
    <br>
    {{ template "languages.html" . }}
  </main>
</body>
</html>
{{ end }}

I have chosen this order but you can order the partials however you want and repeat them as many times as you want, there is no limitation in that regard.

Generating the HTML page

Cool! At this point, we have our "Database" in our YAML file, and we have our base template invoking our partial templates, so the only point we are missing is to combine the data with the templates and generate our HTML page to have our CV published.

I created a main.go in the root of the project and I added the following code:

package main

import (
    "log"
    "os"
    "html/template"

    "gopkg.in/yaml.v3"
)

const (
    datafileName   = "me.yaml"
    resumeFileName = "resume.html"
)

func main() {
    files := []string{
        "./tmpl/base.html",
        "./tmpl/partials/about.html",
        "./tmpl/partials/education.html",
        "./tmpl/partials/experience.html",
        "./tmpl/partials/keywords.html",
        "./tmpl/partials/languages.html",
        "./tmpl/partials/mission.html",
        "./tmpl/partials/projects.html",
        "./tmpl/partials/skills.html",
    }

    templates, err := template.ParseFiles(files...)
    if err != nil {
        log.Print(err.Error())
        return
    }

    data := map[string]interface{}{}
    buf, err := os.ReadFile(datafileName)
    if err != nil {
        log.Println("err reading data file", err)
        return
    }
    err = yaml.Unmarshal(buf, &data)
    if err != nil {
        log.Println("err unmarshaling data", err)
        return
    }

    out, err := os.Create(resumeFileName)
    if err != nil {
        log.Println("error creating file", resumeFileName, err)
        return
    }
    err = templates.ExecuteTemplate(out, "base", data)
    if err != nil {
        log.Print(err.Error())
    }
}

I used the gopkg.in/yaml.v3 library to work with YAML easily but you can find probably others that serve your purpose but I'm used to working with this one.

Then I declared the constants for the YAML and HTML filenames.

After that inside the main() I have that slice of strings where I indicate all my templates and its path. I think this can be simplified in the future using another function from the package but for now, I wanted to have it as simple as possible.

The next step is to parse the files I want to use as templates. The package provides the function func (t *Template) ParseFiles(filenames ...string) (*Template, error), so I just passed my slice to it and then all the templates are ready to be used at any point.

The other piece that I needed was to parse the YAML file and for that, I simply read the file where I have all the information and then used the lib mentioned before unmarshaling it to a map[string]interface{}{}.

Having the templates parsed and the information loaded, the third file that comes to the table game is the final HTML. I just used the function func Create(name string) (*File, error) to create that.

Lastly, I glued all the parts with the executino of the template with the following function func (t *Template) ExecuteTemplate(wr io.Writer, name string, data any) error

The first argument is an io.Writter so our HTML file.
The second one is the name of the template that we want to execute. In our case we only defined one template (even though we created multiple partials, we only defined the base one with the command {{ define "base" }}).
The last one is the data we want to pass (if any) to our template, so our loaded YAML file.

To generate the resume.html file, I run from the root directory:

go run main.go

Conclusion

I hope that this easy and simple example has helped you learn or expand your knowledge in the use of templates in Go and that it has given you ideas on how to generate your pages in HTML or in text to format your texts in an organized and structured way without having to worry about anything beyond generating the template and the data structure to satisfy said template.

You can find the complete source code in https://github.com/charly3pins/cv where I added some CSS and more fancy stuff to improve virtually the Resume and where I will be adding updates in the future.

Tech Book Club

charly3pins — Sat, 15 Apr 2023 08:51:26 +0000

What is that?

The purpose of any club is to bring a group of people together to learn and discuss something that matters to them, have fun doing it, and end up having a positive impact on them. A book club is no different.

Why did we start one?

In AREX we have a team that loves to explore and talk about different technical ideas to improve our code base, ways of working, methodologies, culture and so on. We have a strong learning culture and we constantly encourage our employees to improve themselves. So what happened before creating the club was that some people were exploring different topics individually but after that the discussion with the other members was not possible since the level of knowledge was not the same (except in some occasions that could be the case). So as engineers that we are, we started to think how we can solve that gap and we ended up deciding to create the Tech Book Club.

The main points for us are:

Have a common space where we can discuss with the same knowledge base.
Sharing ideas is the key to success. 2 people can read the same thing and understand something completely different. So it is very important for us to share those ideas and discuss them to reach agreements.
The previous technical knowledge you have is not important. Everyone is welcome to join the reading and discussion in a respectful and inclusive way.
All club members are improving, so the level of the company improves as well.
We learn in a fun way.

How does it work?

We have a dedicated Slack channel for the club, so everything related to it is posted there. Before we start a new book, we ask the members to propose the next book(s) they consider interesting to read and a brief description of why we should read it.
Then we put all the books in a poll and we vote during a few days and the book with more votes will be the one selected.
We use the O'Reilly Media platform for that. There we have a playlist in the website where we add the books that we are reading and the members have access to that list, so we can share the same links between us in order to facilitate the communication.
Every 2 weeks we have a meeting where we have a discussion about what we have read, what we liked, what we don't like, if we can apply something to our company. At the end of the session we agree on the number of pages / sections / chapters for the next session. Sometimes it's difficult to calculate what's the right
After each meeting we log the session into a Confluence page for keeping track of the highlights. So at the end of the book we have all the highlights summarised in one place.

One idea that we have for the future (because currently we don't have time) is to send out a survey after each session. This will help us to know from the members, what worked and what didn't work and improve for the next session.

The books

The Tech Book Club started in December 2021 and we've read completely 3 books:

Microservices Patterns, by Chris Richardson
Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems, by Steve Krug
Test Driven Development: By Example, by Kent Beck

Currently we are reading Software Engineering at Google, by Titus Winters, Tom Manshreck, Hyrum Wright.

Conclusion

A Tech Book Club is a great way to level up your team in an inclusive, safe and fun way. That will have a positive impact on them, but also at the company level. Also, don't neglect inviting other departments to the club as it will help build social connections and improve collaboration between them, so don't make it private just for your team.

I hope everything that I have tried to explain in this post has been clear and please if there is any part that has not been completely clear or there are parts that I have not covered that you would like me to do, leave me a comment right here or through my social networks that you have on my profile and I will be happy to respond.

Club de Lectura de Tecnología

charly3pins — Sat, 15 Apr 2023 08:51:18 +0000

¿Qué es eso?

El propósito de cualquier club es reunir a un grupo de personas para aprender y discutir algo que les importe, divertirse haciéndolo y terminar teniendo un impacto positivo en ellos. Un club de lectura no es diferente.

¿Por qué empezamos uno?

En AREX contamos con un equipo al que le encanta explorar y hablar sobre diferentes ideas técnicas para mejorar nuestra base de código, formas de trabajar, metodologías, cultura, etc. Tenemos una fuerte cultura de aprendizaje y animamos constantemente a nuestros empleados a mejorar. Entonces lo que pasó antes de crear el club fue que algunas personas estaban explorando diferentes temas individualmente pero después de eso la discusión con los otros miembros no era posible ya que el nivel de conocimiento no era el mismo (excepto en algunas ocasiones que podría ser el caso). Entonces, como ingenieros que somos, comenzamos a pensar cómo podemos resolver esa brecha y terminamos decidiendo crear el Tech Book Club.

Los puntos principales para nosotros son:

Tener un espacio común donde podamos discutir con la misma base de conocimiento.
Compartir ideas es la clave del éxito. 2 personas pueden leer lo mismo y entender algo completamente diferente. Entonces es muy importante para nosotros compartir esas ideas y discutirlas para llegar a acuerdos.
Los conocimientos técnicos previos que tengas no son importantes. Todos son bienvenidos a unirse a la lectura y la discusión de una manera respetuosa e inclusiva.
Todos los miembros del club están mejorando, por lo que también mejora el nivel de la empresa.
Aprendemos de una manera divertida.

¿Como funciona?

Tenemos un canal de Slack exclusivo para el club, por lo que todo lo relacionado con él se publica allí. Antes de comenzar un nuevo libro, les pedimos a los miembros que propongan los próximos libros que consideren interesantes para leer y una breve descripción de por qué deberíamos leerlo.
Luego ponemos todos los libros en una encuesta y votamos durante unos días y el libro con más votos será el seleccionado.
Usamos la plataforma O'Reilly Media para eso. Allí tenemos una lista de reproducción en el sitio web donde agregamos los libros que estamos leyendo y los miembros tienen acceso a esa lista, por lo que podemos compartir los mismos enlaces entre nosotros para facilitar la comunicación.
Cada 2 semanas tenemos una reunión donde tenemos una discusión sobre lo que hemos leído, lo que nos gustó, lo que no nos gusta, si podemos aplicar algo a nuestra empresa. Al final de la sesión acordamos el número de páginas/secciones/capítulos para la siguiente sesión. A veces es difícil calcular qué es lo correcto
Después de cada reunión, registramos la sesión en una página de Confluence para realizar un seguimiento de los aspectos más destacados. Así que al final del libro tenemos todos los puntos destacados resumidos en un solo lugar.

Una idea que tenemos para el futuro (porque actualmente no tenemos tiempo) es enviar una encuesta después de cada sesión. Esto nos ayudará a saber de los miembros directamente, qué funcionó y qué no funcionó y mejorar para la próxima sesión.

Los libros

El Club de Lectura de Tecnología comenzó en diciembre de 2021 y hemos leído 3 libros completos:

Microservices Patterns, de Chris Richardson
Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems, de Steve Krug
Test Driven Development: By Example, de Kent Beck

Actualmente estamos leyendo Software Engineering at Google, de Titus Winters, Tom Manshreck, Hyrum Wright.

Conclusión

Un Club de Lectura de Tecnología es una excelente manera de subir de nivel a su equipo de una manera inclusiva, segura y divertida. Eso tendrá un impacto positivo en ellos, pero también a nivel de empresa. Además, no olvide invitar a otros departamentos al club, ya que ayudará a establecer conexiones sociales y mejorará la colaboración entre ellos, así que no lo haga privado solo para su equipo.

Espero que todo lo que he intentado explicar en este post haya sido claro, y por favor si hay alguna parte que no ha sido del todo clara o hay partes que no he cubierto que te gustaría que hiciera, déjame un comentario aquí mismo oa través de mis redes sociales que tienes en mi perfil y estaré encantado de responderte.

Estructura de proyecto para Go con Arquitecturas Limpias y DDD

charly3pins — Thu, 09 Dec 2021 15:21:09 +0000

Introducción

Durante los últimos 5 años he trabajado a tiempo completo con Go. Algunos de ustedes ya sabrán que estoy enamorado de este lenguaje por la simplicidad que tiene pero con mucho potencial para construir cualquier cosa. La principal pregunta a la que me he enfrentado desde el principio es ¿Qué estructura debo usar para mi proyecto? Yo diría que todavía hoy no lo sé y como siempre en nuestra industria... depende. Depende de si está creando una libreria, depende de si está creando una aplicación monolítica (como MVC), depende de si está creando un pequeño servicio (también conocido como microservicio), etc. No hay nada escrito y no hay muchos frameworks (afortunadamente) que te obligan a hacer las cosas a la manera del mismo (tenga en cuenta que esa es una de mis partes favoritas, especialmente viniendo de Java, donde Spring parece ser la forma estándar de hacer proyectos en Java). Para los principiantes, a veces eso es lo difícil porque no sabes cómo empezar y necesitas investigar y leer/ver algunos tutoriales y tratar de imitar esos diseños sin saber si estás haciendo las cosas correctamente. Lo bueno de esto es que, como no existe un estándar, "todo" lo que hagas estará bien (aunque a veces es peligroso).

Primer enfoque

Cuando comencé, busqué muchos repositorios en GitHub usando la etiqueta #Go y ver cómo las personas estaban organizando sus proyectos. Comprobando desde los más pequeños hasta los más grandes de la industria como Docker, Kubernetes, AWS, ... Mi primer enfoque fue usar la todavía popular doble carpeta:

/cmd
/pkg
archivos de configuración (Makefile, docker, etc.)

Este fue el enfoque inicial que estaban adoptando algunos proyectos de Go, donde dentro del pkg usted define todo su código y en el cmd simplemente crea su main.go el cuál arranca su aplicación desde el pkg. Esto comenzó a ser tan popular porque se utilizaron algunos ejemplos de Go del equipo de Go. Algunos meses / años después, algunas personas comenzaron a preguntarse si la carpeta pkg era simplemente eso, una carpeta, y no contribuía en nada al proyecto, por lo que debería eliminarse. En ese momento yo era un claro defensor del diseño cmd, pkg porque era un "estándar" para la industria y para mí estaba claro dónde mirar el código (pkg) y dónde mirar la inicialización de la aplicación (cmd). Esto sigue siendo cierto, pero defendiendo la simplicidad de Go, tendemos a eliminar los paquetes que son solo carpetas y darles también un nombre significativo, ya que son parte de nuestro código (importándolos y usándolos en tipos, funciones, etc.).

Momento Ahá

Hace unos años comencé a leer sobre DDD debido a la popularidad que ha adquirido en los últimos años y quería saber de qué se trata. No quiero extenderme en este post sobre ese tema (si desea que escriba uno específico para él, envíeme un mensaje aquí o a través de mis redes sociales y estaré feliz de hacerlo) pero básicamente a lo que apunta es a concentrarse al diseñar en el dominio en lugar de en el código. Le ayuda a comprender mejor el problema al brindarle un conjunto de herramientas para trabajar con los expertos en el dominio de su empresa a fin de diseñar la mejor solución posible para el problema que desea resolver. Hay dos grupos principales, los patrones estratégicos y los patrones tácticos. Ambos son importantes, pero aquí, como quiero hablar sobre el diseño del proyecto, solo hablaré de los tácticos. Cuando leí esos, comencé a internalizar que todo el diseño de dominio que estaba haciendo con los patrones estratégicos, todas las preguntas que le hacía a los expertos en el dominio, el lenguaje ubicuo que estábamos definiendo y todas las sesiones de tormenta de eventos que estábamos haciendo, todo eso debería reflejarse en mi código. ¿Cómo puedo hacer eso? Hay muchas posibilidades, pero una posibilidad es usar Clean Architectures.
En ese momento fue cuando leí el libro de Robert C. Martin 'Arquitectura limpia: Una guía del artesano para la estructura y el diseño del software: Una guía del artesano para la estructura y el diseño del software'. Entendiendo los objetivos de DDD y las ideas transmitidas en el libro y después de un refinamiento con los compañeros de mi equipo, terminamos creando un diseño de proyecto en el que intentamos reunir todos esos conceptos y los más importantes con los que nos sentimos cómodos trabajando. Esto no es para seguir una tendencia o una imposición de ningún marco, por lo que si no estamos contentos con él, lo repetimos nuevamente y retocamos las partes que consideramos para facilitar nuestra vida y especialmente nuestro yo futuro cuando lo necesitemos. algunas correcciones o agregar nuevas funciones.

El diseño

Teniendo en cuenta todo lo que mencioné antes, permítanme presentarles el diseño del proyecto. Como ejemplo, usaré una aplicación que tiene salientes y pagos recibidos. Ambos con sus propios agregados y reglas comerciales que deben satisfacer y exponer los endpoints a través de grpc en este caso.

/payments-svc
| - app /
| - cmd /
| - docs /
| - grpc /
| - incoming /
| - internal /
    |- logger/
    |- postgres/
    |- slack/
| - k8s /
| - outgoing /
docker-compose.test.yml
go.mod
go.sum
Makefile
README.md

Intentaré ser breve y explicar un poco qué partes contiene cada carpeta y por qué adoptamos ese diseño.

Como dije, este servicio es responsable de los pagos, por lo que queremos que el dominio se exponga primero, por lo que mostramos incoming y outgoing como las partes principales de la aplicación. Entraré en detalle unas líneas después, no se preocupe.

En app es donde tenemos el main.go para arrancar todas las aplicaciones (básicamente donde importamos los paquetes incoming y outgoing y algunos internal si es necesario).

En cmd es donde definimos las herramientas de línea de comando que necesitamos para el servicio. En este caso tenemos un cli que interactúa con nuestro servicio.

En docs es donde colocamos la documentación relevante para este proyecto.

Como mencioné antes, los endpoints se exponen a través de grpc, por lo que la carpeta es responsable de implementar las interfaces proporcionadas por la compilación de nuestro protobuffer.

En internal es donde tenemos la implementación de las interfaces que usamos en el proyecto pero que no son parte del dominio; básicamente las cosas de la infraestructura como la base de datos, las colas, los servicios externos (Slack), el logger...

En k8s se refiere a los archivos de configuración de Kubernetes para la implementación.

Como se mencionó antes, incoming y outgoing son nuestros paquetes de dominio, así que ahí es donde ocurre toda la magia. Describiré un poco uno de ellos porque el otro es similar pero con las particularidades de su dominio.

/outgoing
app_service.go
app_service_test.go
display_payments.go
display_payments_test.go
execute_payments.go
execute_payments_test.go
flow_service.go
flow_service_test.go
instruction_repository.go
instruction_repository_test.go
instruction.go
instruction_test.go

Recogí el "saliente" para la explicación. En primer lugar tenemos el app_service. Aquí es donde definimos el tipo Application Service de nuestro paquete, entonces lo que significa es que tendrá todas las dependencias para el paquete y un método para cada Caso de Uso. Nota: las dependencias son interfaces. El app_service_test es básicamente donde mockeamos todas las interfaces necesarias para el app_service para poder reutilizarlas en todos los archivos *_test.go.

Los ficheros display_payments y execute_payments son casos de uso para este dominio. Las test simplemente prueban los diferentes escenarios para cada caso de uso.

El flow_service es un servicio de dominio que nos ayuda a ejecutar los pagos en función del flujo definido para cada tipo de pago. Básicamente, el test consiste en probar el servicio de dominio.

El instruction_repository es donde definimos todos los métodos contra nuestro repositorio, en este caso nuestra base de datos en PostgreSQL. En el test se compara con una base de datos de prueba si todas las consultas están bien.

Por último, pero no menos importante, en realidad lo más importante el agregado instruction. Dentro de ese archivo es donde ponemos todo lo importante para este paquete. El agregado está a cargo de hacer cumplir las reglas de negocio por lo que todas las validaciones, verificaciones, cálculos, conversiones, etc. deben estar aquí. (Es cierto que dependiendo de la conversión o manipulaciones de datos o otras operaciones más complejas, es mejor tener factorías u otros helpers, pero no quiero complicar demasiado este ejemplo).

Flujo de la aplicación

Para finalizar este largo post, permítanme describir cómo funciona el flujo de nuestra aplicación:

app es la responsable de poner en marcha el servicio
grpc será el que reciba la solicitud y responda los resultados
una vez que grpc asigna la solicitud a nuestros tipos internos, llamará a app_service
dentro de app_service se llamará al caso de uso correspondiente
dependiendo del caso de uso se debe llamar algún servicio de dominio, se llamará algún repositorio, o ambos, o más de 2 ... ¡Depende!

Conclusión

Espero que todo lo que he intentado explicar en este post haya sido claro, que fue mucho, y por favor si hay alguna parte que no ha sido del todo clara o hay partes que no he cubierto que te gustaría que hiciera, déjame un comentario aquí mismo oa través de mis redes sociales que tienes en mi perfil y estaré encantado de responderte.

Go project layout with Clean architectures and DDD

charly3pins — Thu, 09 Dec 2021 15:19:28 +0000

Introduction

During the last 5 years I have been working full time with Go. Some of you may already know that I'm in love with this language because of the simplicity it has but with a lot of potential to build anything. The main question I have faced since the beginning is Which layout should I use for my project? I would say still today I don't know and as always in our industry... it depends. It depends on if you are building a library, it depends on if you are building a monolithic application (like MVC), it depends on if you are building a small service (aka microservice), etc. There is nothing written of and we don't have a lot (luckily) frameworks that force you to do things in the framework's way (note aside that's one of my favorite parts especially coming from Java where Spring seems to be the standard way of doing projects in Java). For the beginners sometimes that is difficult because you don't know how to start and need to do research and read/watch some tutorials and try to mimic those layouts without knowing if you're doing the correct things. The good point on that is as there is no standard, "all" you do will be okay (however it's dangerous sometimes).

First approach

When I started I tried to check a lot of repos on GitHub using the tag #Go and see how people are organizing their projects. Checking smaller ones or checking the big players in the industry like Docker, Kubernetes, AWS, ... My first approach was to use the still popular double folder:

/cmd
/pkg
config files (Makefile, docker, etc.)

This was the initial approach that some Go projects were adopting where inside the pkg you define all your code and in the cmd you simply create your main.go which bootstraps your application from the pkg one. This started to be so popular because some Go examples from the Go Team were used. Some months/years later some people started to question if the pkg folder was simply that, a folder, and it was not contributing anything to the project so it should be removed. For that time I was a clear defender of the cmd, pkg layout because it was a "standard" for the industry and for me it was clear where to look at the code (pkg) and where to look at the initialization of the application (cmd). This is still true, but advocating the simplicity of Go we tend to remove the packages that are just folders and give them also a meaningful name as they are part of our code (importing them and using in types, functions, etc.).

Ahá moment

Some years ago I started reading about DDD due to the popularity it has acquired in the last years and I wanted to know what that about. I don't want to be extenze on this post about that topic (if you would like that I write one specific for it please ping me here or through my social networks and I will be happy to do it) but basically what it aims for is to put your focus when designing in the domain instead of in the code. It helps you to better understand the problem by giving you a toolkit to work with the domain experts in your company in order to design the best possible solution for the problem you wanna solve. There are two main groups, the strategic patterns and the tactical patterns. Both are important but here as I want to talk about the project layout I will talk only about the tactical ones. When I read those I started to internalise that all the domain design that I was doing with the strategical patterns, all the questions that I was asking to the domain experts, the ubiquitous language we were defining and all the event storming sessions we were doing, all of that should be reflected in my code. How can I do that? There are a lot of possibilities but one possibility is using Clean Architectures.
At that moment it was when I read Robert C. Martin's book Clean Architecture: A Craftsman's Guide to Software Structure and Design: A Craftsman's Guide to Software Structure and Design. Understanding what DDD aims for and the ideas conveyed in the book and after some refinement with my team colleagues we ended up creating a project layout in which we tried to gather all those concepts and the most important which we are comfortable working with. This is not to follow a trend or an imposition from any framework, so if we are not happy with it, we iterate it again and we tweak the parts we consider in order to facilitate our lives and specially our future selves when we need to do some fixes or add new features.

The layout

Taking in consideration all I mentioned before, let me present to you the project layout. As an example I will use an application that has outgoing and incoming payments. Both with their own aggregates and business rules that need to satisfy and expose endpoints via grpc in this case.

/payments-svc
|- app/
|- cmd/
|- docs/
|- grpc/
|- incoming/
|- internal/
    |- logger/
    |- postgres/
    |- slack/
|- k8s/
|- outgoing/
docker-compose.test.yml
go.mod
go.sum
Makefile
README.md

I will try to be brief and explain a bit what parts each folder contains and why we adopted that layout.

As I said this service is responsible for payments so we want to have the domain first exposed so we display incoming and outgoing as the main parts of the application. I will go back after a few lines, don't worry.

The app is where we have the main.go to bootstrap all the applications (basically where we import the incoming and outgoing packages and some from the internal if needed).

The cmd is where we define the command line tools we need for the service. In this case we have a cli that interacts with our service.

The docs is where we put the relevant documentation for this project.

As I mentioned before the endpoints are exposed via grpc so that folder is responsible for implementing the interfaces provided by the protobuffer compilation.

The internal is where we have the implementation of the interfaces we use in the project but are not part of the domain; basically the infrastructure things like the database, queues, external services (Slack), the logger...

The k8s one is referred to the Kubernetes config files for the deployment.

As mentioned before the incoming and outgoing are our domain packages so that is where all the magic happens. I will describe a bit of one of them because the other is similar but with the particularities of that domain.

/outgoing
app_service.go
app_service_test.go
display_payments.go
display_payments_test.go
execute_payments.go
execute_payments_test.go
flow_service.go
flow_service_test.go
instruction_repository.go
instruction_repository_test.go
instruction.go
instruction_test.go

I've picked up the outgoing for the explanation. First of all we have the app_service. This is where we define the type Application Service of our package so what it means is that it will have all the dependencies for the package and one method for each Use Case. Note: the dependencies are interfaces. The app_service_test is basically where we mock all the interfaces required for the app_service so we can reuse them in all the*_test.go files.

The display_payments and execute_payments are use cases for this domain. The tests are simply testing the different scenarios for each use case.

The flow_service is a domain service that helps us to execute the payments depending on the flow defined for each payment type. The test is basically testing the domain service.

The instruction_repository is where we define all the methods against our repository, in this case our database in PostgreSQL. The test is checking against a testing database if all the queries are okay.

Last but not least, actually the most important is the aggregate instruction. Inside that file is where we put everything important for this package. The aggregate is in charge of enforcing the business rules so that all the validations, checks, calculations, conversions, etc. needs to be here. (It's true that depending on the conversion or manipulation of the data or complex operations, it's better to have factories or other helpers, but I don't want to overcomplicate this example).

Application flow

To finalize this long post let me describe how the flow of our app works:

app is the responsible of starting up the service
grpc will be the one receiving the request and answers the results
once the request is mapped into our internal types by grpc it will call the app_service
inside the app_service the corresponding use case will be called
depending on the use case some domain service should be called, some repository will be called, or both, or more than 2... It depends!

Conclusion

I hope everything that I have tried to explain in this post has been clear, which was a lot, and please if there is any part that has not been completely clear or there are parts that I have not covered that you would like me to do, leave me a comment right here or through my social networks that you have on my profile and I will be happy to respond.