[{"id":"0","title":"Measuring Corporate Knowledge Concentration in the Linux Kernel","url":"/posts/measuring-corporate-knowledge-concentration-in-the-linux-kernel/","description":"The research proposal I'm starting at IME-USP: measuring how corporate knowledge, not just activity, concentrates in the Linux kernel using cregit's token-level authorship, and what happens when a dominant company withdraws.","contentExcerpt":"--- title: \"Measuring Corporate Knowledge Concentration in the Linux Kernel\" date: 2026-07-01 layout: layouts/post.njk language: en place: brazil description: \"The research proposal I'm starting at IME-USP: measuring how corporate knowledge, not just activity, concentrates in the Linux kernel using cregit's token-level authorship, and what happens when a dominant company withdraws.\" tags: - open source software - linux - kernel development - research - USP --- Linux Kernel is one of the biggest collaborative software projects of the world. Mainly created by hobbists and enthusiats the Linux Kernel has become today a key project for so many devices that depend on it, that more than 80% of the contributions to kernel today are done by employees paid to contribute (!back by https://www.linuxfoundation.org/press/press-release/the-linux-foundation-releases-linux-development-report). Open source is no longer a volunteer effort. It has become a way of companies to develop and make accessible products, such as Analog Devices with iio drivers, AMD with processors and gpus and others. Measuring corporate knowledge One gap for the existing literature is clearly understanding how companies acquire, manage and update their knowledge about the Linux kernel. The existing papers are vast in defining who is the most active, but they lack a vision directly related to the concentration of knowledge. Knowledge itself it's impossible to be directly measured. So we can only use proxyes to it: concentration of commits on files; authorship of code submitted; and even participation in mailing lists. The proposal here describe touches 4 dimensions: 1. Measurement. How concentrated is source-code knowledge at the company level, and how does a company-level truck factor compare to the classic individual one? 2. Divergence. Does corporate activity dominance line up with corporate knowledge dominance, or do they split apart? 3. Fragility. Does measured knowledge concentration actually predict what happens when a firm withdraws: files orphaned, absorbed by another company, or retained? 4. Governance. Does the concentration of maintainer authority track the concentration of code knowledge and of mailing-list participation? Do the different axes agree? Measuring knowledge with cregit To measure knowledge rather than activity directly, I build on cregit, a tool that had been dormant since 2023, so getting it to run again was a project in itself, which I wrote about in my notes on contribut"},{"id":"1","title":"DSL - #8 Cregit - working to contribute to the kernel's token tracking tool","url":"/posts/cregit-open-source-contributions/","description":"Notes on cregit, the token-level blame tool for the Linux kernel, and how my group worked to modernize it, contribute fixes, and collaborate with its maintainer.","contentExcerpt":"--- title: \"DSL - 8 Cregit - working to contribute to the kernel's token tracking tool\" date: 2026-06-26 layout: layouts/post.njk language: en place: brazil description: \"Notes on cregit, the token-level blame tool for the Linux kernel, and how my group worked to modernize it, contribute fixes, and collaborate with its maintainer.\" tags: - linux - cregit - MAC0470 - MAC5856 - USP - open source software - oss --- As part of the second evaluation of my classes on Open Source Software (OSS) my whole class is contributing to an OSS project which each group can choose. This post is a follow-up of my notes on our first contribution to the Linux Kernel and part of this series. As my master's will be about corporate contributions to the kernel's source code and cregit is one of the tools tied to the Linux Foundation's CHAOSS project for open source health analytics, I will also use it in this part of the discipline. What (exactly) is cregit? Cregit is a tool that lets you see exactly when and by whom a specific token was added. It works kind of like a git-blame for tokens. It was created by Daniel M. German and colleagues, and the idea is described in detail in their paper cregit: Token-level blame information in git version control repositories (Empirical Software Engineering, 2019). Tokens are just any sequence of non-blank chars that is meaningful for a language. For most of the kernel code, this means any sequence of chars. Why not just use git blame ? Regular git blame works at the granularity of a whole line, and that granularity breaks down surprisingly often. Reindent a block, wrap a long line, split a function signature across two lines, or run a formatter over the file, and git blame will happily attribute all of those lines to whoever touched the whitespace last, even though the actual code was written years earlier by someone else. Cregit sidesteps this by attributing each individual token, so a reformat that moves code around without changing it keeps the original authorship intact. That distinction is exactly what I care about for my master's: if you want to measure how much of the kernel a given company actually wrote, line-level blame will quietly credit the wrong people every time the code is reshaped, while token-level blame stays honest. Take a look at how cregit works: !Cregit attributing each token to the commit and developer that introduced it In the image above, every token is colored and labeled with the commit and developer that introduced"},{"id":"2","title":"LKD - #7 Notes on our contribution to the Linux Kernel","url":"/posts/notes-on-the-contribution-for-the-linux-kernel/","description":"The journey of how we (attempted) to contribute to the linux kernel, the changes we made, how we analyzed and evolved them and the state of the reviews.","contentExcerpt":"--- title: \"LKD - 7 Notes on our contribution to the Linux Kernel\" date: 2026-04-21 layout: layouts/post.njk language: en place: brazil description: \"The journey of how we (attempted) to contribute to the linux kernel, the changes we made, how we analyzed and evolved them and the state of the reviews.\" tags: - linux - kernel development - MAC0470 - MAC5856 - USP - open source software - patch --- As part of my classes on Open Source Software (OSS) my whole class is starting to work on Linux Kernel Development. This post is a series of my experiences throughout the class related to kernel development. This post is a follow-up of this previous post and part of this series. Throughout the whole series of posts we were learning how the kernel works and understanding how we could make smart changes to the Linux kernel. In this post we will talk about what we submitted, how and the statuses of the submissions until today. My group My group was made by me: Ellian Carlos, Ricardo Kojo and Gabriel Braga, all masters students from the \"Sistemas de software e aplicações de sistemas computacionais\" research group. We didn't talk much before starting working in the submissions, but when we started finding what to contribute to we talked more and focused most of the communication via a telegram group. Choosing a submission Since this would be the first submission of a major part of the class, the professor together with the teaching assistants made a curated list of places to work, they were: 1. A curated list of 100% duplicated code inside functions in the IIO subsystem created by the ArKanjo tool; 2. A curated list of 90% duplicated code inside functions in the IIO subsystem created by the ArKanjo tool; 3. A curated list of 100% duplicated code inside functions in the AMD subsystem created by the ArKanjo tool; 4. A curated list of 90% duplicated code inside functions in the AMD subsystem created by the ArKanjo tool; 5. The possibility to change from mutex lock(&lock) and mutex unlock(&lock) functions to use the macros guard(mutex)(&lock) and scoped guard(mutex)(&lock) where we find it would be best; 6. The possibility to change from bitfield operations of hexadecimal numbers to use the FIELD GET() , FIELD PREP() and FIELD MODIFY() . 7. Improvements in the IIO area of staging. 8. Update IIO drivers to be Include-What-You-Use compliant (IWYU) 9. Convert logging to drm\\ \\ functions with drm device parameter 10. Read and expand the subsystem documentation All explanations"},{"id":"3","title":"LKD - #6 Notes on how the iio subsystems work","url":"/posts/how-the-iio-module-works/","description":"A summarized view of the IIO subsystem, a subsystem inside the Linux kernel with the purpose of providing support for devices that in some sense perform either analog-to-digital conversion (ADC) or digital-to-analog conversion (DAC) or both.","contentExcerpt":"--- title: \"LKD - 6 Notes on how the iio subsystems work\" date: 2026-04-17 layout: layouts/post.njk language: en place: brazil description: \"A summarized view of the IIO subsystem, a subsystem inside the Linux kernel with the purpose of providing support for devices that in some sense perform either analog-to-digital conversion (ADC) or digital-to-analog conversion (DAC) or both.\" tags: - linux - kernel development - MAC0470 - MAC5856 - USP - open source software - iio --- As part of my classes on Open Source Software (OSS) my whole class is starting to work on Linux Kernel Development. This post is a series of my experiences throughout the class related to kernel development. This post is a follow-up of this previous post and part of this series. > Note: This post is a companion to the > The iio simple dummy Anatomy > and > IIO Dummy module Experiment One: Play with iio dummy > tutorials from FLUSP. I recommend following the tutorials first and then > coming back here for my notes and troubleshooting tips. In the last post we discussed how to submit linux patches. In today's post we will investigate and dive deep into the IIO subsystem. What is the IIO subsystem in linux kernel? > The main purpose of the Industrial I/O subsystem (IIO) is to provide support > for devices that in some sense perform either analog-to-digital conversion > (ADC) or digital-to-analog conversion (DAC) or both. The aim is to fill the > gap between the somewhat similar hwmon and input subsystems. Hwmon is directed > at low sample rate sensors used to monitor and control the system itself, like > fan speed control or temperature measurement. Input is, as its name suggests, > focused on human interaction input devices (keyboard, mouse, touchscreen). In > some cases there is considerable overlap between these and IIO. > > Devices that fall into this category include: > > - analog to digital converters (ADCs) > - accelerometers > - capacitance to digital converters (CDCs) > - digital to analog converters (DACs) > - gyroscopes > - inertial measurement units (IMUs) > - color and light sensors > - magnetometers > - pressure sensors > - proximity sensors > - temperature sensors > > Usually these sensors are connected via SPI or I2C. A common use case of the > sensors devices is to have combined functionality (e.g. light plus proximity > sensor). This excerpt was extracted from Industrial I/O Introduction. That's what the IIO subsystem is for, supporting real hardware related to Industrial "},{"id":"4","title":"LKD - #5 Notes on how the linux patch submission works","url":"/posts/how-linux-kernel-submissions-work/","description":"A summarized version of how change revisions work at the linux kernel, how to send patch emails with git and how to see linux threads.","contentExcerpt":"--- title: \"LKD - 5 Notes on how the linux patch submission works\" date: 2026-04-12 layout: layouts/post.njk language: en place: brazil description: \"A summarized version of how change revisions work at the linux kernel, how to send patch emails with git and how to see linux threads.\" tags: - linux - kernel development - MAC0470 - MAC5856 - USP - open source software - mailing list - patch --- As part of my classes on Open Source Software (OSS) my whole class is starting to work on Linux Kernel Development. This post is a series of my experiences throughout the class related to kernel development. This post is a follow-up of this previous post and part of this series. > Note: This post is a companion to the > Sending patches by email with git > and > Sending patches with git and USP email > tutorial from FLUSP. For specifically this post, you don't need to check the > companion ones unless you want. In the last post we created and deployed a custom module to our VM. In this post we will talk about how patch submissions work and how to submit a patch by email with git How changes are reviewed in the Linux Kernel? If you're familiar with modern software development chances are you are probably used to tools like github, gitlab or bitbucket which offers some of submitting your changes to a peer review to be: tested, commented, approved and merged into some stable branch. This way of reviewing changes is a modernized version of the Linux process. Linux predates all of the tools which offer this type of revision, Linux changes are actually submitted and reviewed using git patches sent by e-mail. All of the changes made in the kernel are actually kept public in the lore, so you can actually see what a code submission looks like, one patch example is this one: Use guard() and scoped guard() for handling mutex and spin locks instead of manually locking and unlocking. This prevents forgotten locks due to early exits and remove the need of gotos. Signed-off-by: Ricardo H H Kojo Co-developed-by: Ellian Carlos Signed-off-by: Ellian Carlos Co-developed-by: Gabriel B L de Oliveira Signed-off-by: Gabriel B L de Oliveira --- drivers/block/null blk/main.c | 74 +++++++++++++------------------ drivers/block/null blk/null blk.h | 1 + 2 files changed, 32 insertions(+), 43 deletions(-) diff --git a/drivers/block/null blk/main.c b/drivers/block/null blk/main.c index f8c0fd57e041..fbe34e8a6c93 100644 --- a/drivers/block/null blk/main.c +++ b/drivers/block/null blk/main.c @@ -423,"},{"id":"5","title":"LKD - #4 Notes on char device drivers","url":"/posts/intro-linuxkernelchardevdrivers/","description":"A personal log of writing and exercising a char device driver inside the Linux kernel, with notes from my Open Source Software class at USP.","contentExcerpt":"--- title: \"LKD - 4 Notes on char device drivers\" date: 2026-03-24 layout: layouts/post.njk language: en place: brazil description: \"A personal log of writing and exercising a char device driver inside the Linux kernel, with notes from my Open Source Software class at USP.\" tags: - linux - kernel development - MAC0470 - MAC5856 - USP - open source software - kw - kernel workflow - char devices --- As part of my classes on Open Source Software (OSS) my whole class is starting to work on Linux Kernel Development. This post is a series of my experiences throughout the class related to kernel development. This post is a follow-up of this previous post and part of this series. > Note: This post is a companion to the > Introduction to Linux kernel char device drivers > tutorial from FLUSP. I recommend following the tutorial first and then coming > back here for my notes and troubleshooting tips. In the last post we created and deployed our own module inside the IIO subtree. This time we are writing a char device driver! Tutorial This tutorial is about writing an actual char device driver and exercising it from user-space. The driver, simple char , implements the basic file operations ( open , release , read , write ) through a struct file operations , allocates a major number, and registers a cdev so that once the module is loaded it shows up in /proc/devices . From there you create a device node with mknod and read/write to it like any other file. So the tutorial is pretty good to get a grasp of how a read / write syscall actually gets routed to a driver, and on how file operations , cdev , and major/minor numbers fit together. Problems Similar to the previous one, NixOS did not really get in the way here. The same disk-locking issue from mounting the built module into the VM came back, so the workaround from the previous post was still needed, but nothing char-drivers-specific caused trouble. Conclusion If in the future you need to connect with something that does not have Linux support, just build it :P. Jokes aside, this was another pretty great experience and a natural next step from the modules tutorial. References \\[1\\] Introduction to Linux kernel char device drivers FLUSP, IME-USP \\[2\\] Tanenbaum, Andrew S., Modern Operating Systems \\[3\\] Linux Device Drivers Development Course for Beginner, freeCodeCamp.org. \\[4\\] Kernel Workflow."},{"id":"6","title":"LKD - #3 Notes on creating and deploying custom module","url":"/posts/intro-linuxkernelbuildconfigandmodules/","description":"A personal log of creating and deploying a custom Linux kernel module inside the IIO subtree, with notes on disk locking issues and NixOS compatibility from my Open Source Software class at USP.","contentExcerpt":"--- title: \"LKD - 3 Notes on creating and deploying custom module\" date: 2026-03-23 layout: layouts/post.njk language: en place: brazil description: \"A personal log of creating and deploying a custom Linux kernel module inside the IIO subtree, with notes on disk locking issues and NixOS compatibility from my Open Source Software class at USP.\" tags: - linux - kernel development - MAC0470 - MAC5856 - USP - open source software - kw - kernel workflow --- As part of my classes on Open Source Software (OSS) my whole class is starting to work on Linux Kernel Development. This post is a series of my experiences throughout the class related to kernel development. This post is a follow-up of this previous post and part of this series. > Note: This post is a companion to the > Introduction to Linux kernel build configuration and modules > tutorial from FLUSP. I recommend following the tutorial first and then coming > back here for my notes and troubleshooting tips. In the last post we talked about kernel modules and built the IIO subtree and deployed it. This time we are creating our own modules inside the IIO subtree! Tutorial This tutorial is about creating your own module and deploying it to the VM in order to see changes. This should be the easier one, since there is no more setup or installation needed. The module is a dummy module that just prints a hello from the module name. So the tutorial is pretty good to get a grasp of how modules are set up with things like init and exit and also, on how to use dmesg which prints and controls the kernel ring buffer. Problems In fact, NixOS did not interfere with this one and the only problem I had was with a disk locking issue for the VM. This meant that when I was mounting the built modules, I couldn't because the disk was locked, so I had to: bash 1. Kill any hidden QEMU processes locking the disk sudo pkill -9 qemu sudo pkill -9 guestmount 2. Clear the stale mount point (Lazy unmount) sudo umount -l \"${VM MOUNT POINT}\" 2>/dev/null 3. Mount the CORRECT partition (you need to check your correct partition in the last tutorials) sudo guestmount --rw -a \"${VM DIR}/arm64 img.qcow2\" -m /dev/sda2 \"${VM MOUNT POINT}\" Aside from this, the module was built, deployed and tested successfully. Conclusion The experience was pretty good and now we can create our own kernel modules. This was a pretty great experience and by far the most NixOS friendly tutorial. References \\[1\\] Introduction to Linux kernel build configuration and mo"},{"id":"7","title":"LKD - #2 Notes on how to build and boot a custom Linux kernel for ARM using KW","url":"/posts/howbuilding-custom-arm-linux-kernel-with-kw/","description":"A personal log of building and booting a custom ARM Linux kernel using Kernel Workflow (kw), with notes on NixOS cross-compilation setup and VM networking issues from my Open Source Software class at USP.","contentExcerpt":"--- title: \"LKD - 2 Notes on how to build and boot a custom Linux kernel for ARM using KW\" date: 2026-03-22 layout: layouts/post.njk language: en place: brazil description: \"A personal log of building and booting a custom ARM Linux kernel using Kernel Workflow (kw), with notes on NixOS cross-compilation setup and VM networking issues from my Open Source Software class at USP.\" tags: - linux - kernel development - MAC0470 - MAC5856 - USP - open source software - kw - kernel workflow --- > Note: This post is a companion to the > Building and booting a custom Linux kernel for ARM using kw > tutorial from FLUSP. I recommend following the tutorial first and then coming > back here for my notes and troubleshooting tips. As part of my classes on Open Source Software (OSS) my whole class is starting to work on Linux Kernel Development. This post is a series of my experiences throughout the class related to kernel development. This post is a follow-up of this previous post and part of this series. Kernel types Linux kernel is a Monolithic kernel, this means it is just a very huge binary all together in the kernel space. This also means that the whole code of the kernel is together in the same place. So even highly scoped changes, like updating a device driver for an NVIDIA graphics cards issue would take you to build the whole kernel. This also means, that, the code for everything in the kernel is in the same repository and, theoretically, any part of the kernel code could access any other part of it, of course, keeping the limitations of languages in mind. The opposite of a monolithic kernel is a Microkernel, which has a limited \"core\" which runs in kernel space while other functionalities like specific device drivers, file systems, etc are kept in the user space. Monolithic kernels are usually faster than Microkernels since everything runs in kernel mode and requires less context switching between kernel and user modes. This comes with a price of: 1. Security: a problem in any part of the kernel becomes a level 0 threat, while in a Microkernel a compromised device driver would be isolated in user space. 2. Modularity: adding a new driver or module will require the addition of a whole new organization into the kernel source code. 3. Stability: a kernel panic can happen inside a device driver's code, while in the microkernel this panic would be limited to the device driver in the user space. Nonetheless, Linux development is so well done, that it outperforms most o"},{"id":"8","title":"LKD - #1 Notes on how to set up a Linux kernel development environment","url":"/posts/how-to-setup-lkd-notes/","description":"A personal log of setting up a Linux kernel development environment using QEMU and libvirt, with notes on NixOS-specific hurdles and workarounds from my Open Source Software class at USP.","contentExcerpt":"--- title: \"LKD - 1 Notes on how to set up a Linux kernel development environment\" date: 2026-03-17 layout: layouts/post.njk language: en place: brazil description: \"A personal log of setting up a Linux kernel development environment using QEMU and libvirt, with notes on NixOS-specific hurdles and workarounds from my Open Source Software class at USP.\" tags: - linux - kernel development - MAC0470 - MAC5856 - USP - open source software --- > Note: This post is a companion to the > Setting up a test environment for Linux Kernel Dev using QEMU and libvirt > tutorial from FLUSP. I recommend following the tutorial first and then coming > back here for my notes and troubleshooting tips. As part of my classes on Open Source Software (OSS) my whole class (not shy of 50 students) is going to start working on Linux Kernel Development. This post is a series of my experiences throughout the class related to kernel development. This is a really exciting opportunity because Linux is the biggest open source project of all time and one of the most important pieces of software history, it is a big part of my life as being my most important OS since I was 16 years old, which was already 10 years ago. I never imagined attempting to make a change in the more than 30 million lines of code that is the Linux repository. What is Kernel Development? > \"If you wish to make an apple pie from scratch, you must first invent the > universe\" - Carl Sagan, Cosmos In a student oversimplification , the kernel itself is a piece of executable code that sits just above hardware. It is a critical part of the operating system which exposes certain user actions through interfaces (syscalls) to connect directly with all computer hardware through architecture-specific binaries (device drivers). !kernel modes This means that everything executed in the kernel is highly sensitive, it directly connects with hardware and runs with kernel-level permissions. If you want to know more about the kernel, how syscalls work and how device drivers are constructed, check the Modern Operating Systems book by Tanenbaum, section 1.6. Why does this matter? Kernel development means writing C code that runs in that privileged space, be it in device drivers, file system modules, scheduler patches, or even just fixing a bug. A mistake doesn't crash your program, it crashes your entire OS. That's the reason we need the VM setup described below and the strongest argument which leads all kernel developers to always use ano"},{"id":"9","title":"How to Succeed in AI Assisted Interviews","url":"/posts/how-to-succeed-in-ai-assisted-coding-interviews/","description":"What they are, how to nail them, and how to behave in AI-assisted interviews.","contentExcerpt":"--- title: \"How to Succeed in AI Assisted Interviews\" date: 2026-02-09 layout: layouts/post.njk language: en place: brazil locale: en translationKey: how-to-succeed-in-ai-assisted-coding-interviews description: \"What they are, how to nail them, and how to behave in AI-assisted interviews.\" tags: - ai - career --- Over the last year many companies have started evaluating candidates' Agentic AI and GenAI proficiency, for example Meta, Brex, and Canva. These new interviews assess competency in developing software with LLMs and Agentic AI. See: Meta's AI-enabled coding interview, Brex's AI-assisted coding interview, and Canva's AI-assisted coding interviews. These interviews usually take place in either Data Structures and Algorithms coding interviews or interviews where the candidate builds a very simple app, backend, website or fullstack functionality. But they have a different flow; if you're not used to how these specific interviews work, you might get lost even if you're familiar with Agentic AI and DSA interviews. Another main way these interviews differ from classic ones is that they're usually much more complex. If before you were expected to code a frontend and backend in-memory create-and-read with just the scaffolding project, now you're expected to deliver results very similar to production-ready code for a full application: unit tests, integration testing, frontend UX, backend validation, API contract and protocol definition, database schema creation, and other requirements your interviewer might have. However, AI will be faster than the average developer at delivering all of that; issues arise such as: How do you review every file? How do you guarantee the lack of bugs? How do you debug the application when showing your results if you didn't build it yourself? In this blog post I'll share some tips on how to handle those interviews (as an interviewer myself) and how to get the best results out of this interview, some for both DSA and \"Fullstack\" style interviews as well as other general tips at the end. TL;DR: Define a cycle for working with the agent, plan before building, review by risk and priority, be vocal about your choices, and practice with the tool beforehand. Contents: Create a working cycle of development · Time management · Planning and Reviewing Plans · Building · Reviewing the built code · Demo and Debug · After the demo: next steps · Tool handling · General tips · Your checklist · Conclusion Create a working cycle of development Ev"},{"id":"10","title":"One Lesson From Building Microservices","url":"/posts/one-lesson-from-building-microservices/","description":"Why microservices are an organizational decision, not just an architectural one. Key lessons from Sam Newman's Building Microservices and Conway's Law.","contentExcerpt":"--- title: \"One Lesson From Building Microservices\" date: 2026-01-07 layout: layouts/post.njk language: en place: brazil description: \"Why microservices are an organizational decision, not just an architectural one. Key lessons from Sam Newman's Building Microservices and Conway's Law.\" tags: - microservices --- Happy 2026! One of the goals I had last year was reading more, and although I closed the year with a shy number of 3 books read, it is an improvement over the number of 1 book in 2024. One of the books I read that I learned a lot from was Building Microservices (2nd Edition) by Sam Newman. I could go over the hundreds, if not thousands, of lessons I drew from the book, but there is especially one that I think should stick with everyone building systems right now: why adopt microservices. Microservices are usually said to scale better than other service-oriented architectures or monoliths, but the complexity they bring with them is often greater than the complexity needed to scale monoliths. The choice of microservices is much more an organizational decision than an architectural one. It allows teams to independently deliver value to customers from end to end. It empowers teams to own one or more product value pipelines, increasing product decoupling, team responsibility, and, if done correctly, delivery speed. Observation: To know more about delivery speed I would recommend reading the book, there are great insights on deployment decoupling and delivery health throughout the book. This reflects how companies like Netflix and Amazon divide their teams into small groups of very capable people with multidisciplinary skills (front-end, back-end, infrastructure, networking, etc.) who are responsible for a very small part of the overall system. This structure decouples teams from one another in a way that empowers them to decide what is best for the customer within their microservice. Of course, this comes with a long list of pros and cons, and if you really want to explore them, I would recommend reading the book. A great illustration of this is Conway's Law itself: Image credit: “Conway’s Law” — Sketchplanations by Jono Hey When teams are separated into autonomous, domain-focused units, they naturally create independent and uncoupled architectures. This structure makes them owners of a specific domain, which in turn simplifies and accelerates the delivery of value to customers and stakeholders."},{"id":"11","title":"Self-Learning Japanese","url":"/posts/self-learning-japanese-2025/","description":"My journey learning Japanese through self-study using Wanikani, Anki, Duolingo, and other effective tools for mastering a non-Indo-European language.","contentExcerpt":"--- title: \"Self-Learning Japanese\" date: 2025-11-09 layout: layouts/post.njk language: en place: brazil description: \"My journey learning Japanese through self-study using Wanikani, Anki, Duolingo, and other effective tools for mastering a non-Indo-European language.\" tags: - japanese --- I've been trying to learn a new language with a different writing and grammar, something different than any Proto-Indo-European languages. My first take at this was learning japanese a few months ago with Duolingo, but I had little to no success. Don't get me wrong, Duolingo is great for learning a few very basic words and to kickstart you on the basic writing of a language, but it won't get you much further than that for months. So I asked tips for two colleagues of mine that speak a rather decent japanese to help me out and give tips and searched the web for a few recommendations and I ended-up with a bunch of tools that can help me get to a basic level at my own. They are: 1. Wanikani for learning words, kanji and vocabulary in a fun and fast way. It might seem slow at the start, but trust me, it isn't. 2. Jlab's beginner course in Anki is a GREAT Anki deck and extension to nail japanese N5 and some N4 stuff. 3. Duolingo, the bird is still better than nothing and it will eventually slip in new content in a way none of the previous ones do, so it is good to do it as well. 4. Tae Kim's Guide to Learning Japanese grammar, grammar is not the most important thing to learn a language, but it helps speeding up the process if you understand what you're doing. 5. Jisho dictionary, essential to learning a language. Wanikani, Duolingo and Anki are things you should do everyday! Tae Kim and Jisho Dictionary should be tools you use when you need to understand a word, kanji or concept in the language, kind of a self-service learning class. Other than those tools I tend to watch anime and japanese movies with english subtitle, but focus on hearing. I'm also planning to change the games I play and my computer and phone language to japanese to have some kind of \"immersive\" experience in it, but I don't think I can just yet. That's all I'm doing at this start and I do plan to eventually enter a beginner class in the next year or so. Happy learning and じゃあね!"},{"id":"12","title":"Tools I've been using - 2025","url":"/posts/my-tools-2025/","description":"An updated look at my 2025 development toolkit, including improvements to my setup with NixOS, Hyprland, Neovim, and new AI tools.","contentExcerpt":"--- title: \"Tools I've been using - 2025\" date: 2025-07-13 layout: layouts/post.njk language: en place: brazil description: \"An updated look at my 2025 development toolkit, including improvements to my setup with NixOS, Hyprland, Neovim, and new AI tools.\" tags: - tools --- Since last year, I did not upgrade my setup of tools too much. But I made some improvements. What I've been using in 2025? - NixOS for declarative builds and reproducible environments. - Hyprland on xwayland as my Desktop Environment. With Waybar, Wofi and the Hypr Ecossystem - Neovim with Lazy Vim as my developer environment. - Intellij for Kotlin and Java development. - Firefox and qutebrowser. - Oh my zsh on Kitty. - Gemini Pro as main LLM. - Ticker to get updates on stocks. - Cline as a code agent and crewai to build multi-agents workflows. If want to know exactly what I've been using and how, check my .dotfiles."},{"id":"13","title":"Tools I use 2024","url":"/posts/my-tools-2024/","description":"A look at the development tools and software I've been using in 2024, including NixOS, Hyprland, Neovim, and more.","contentExcerpt":"--- title: \"Tools I use 2024\" date: 2024-06-25 layout: layouts/post.njk language: en place: brazil description: \"A look at the development tools and software I've been using in 2024, including NixOS, Hyprland, Neovim, and more.\" tags: - tools --- I love testing and using new tools, in this year I've decided I'm gonna give it a go to many different tools and programs that I've always wanted to try and discover. I've been having an incredible experience and mostly been having fun configuring and setting up my environments. What I've been using in 2024? - NixOS for declarative builds and reproducible environments. - Hyprland on xwayland as my Desktop Environment. With Waybar, Wofi and the Hypr Ecossystem - Neovim with Lazy Vim as my developer environment. - Intellij for Kotlin and Java development. - Firefox and qutebrowser. - Oh my zsh on Kitty If want to know exactly what I've been using and how, check my .dotfiles."}]