DEV Community: Juan Miguel Rodriguez Ceron

Claude Code Sub-Agents: Orchestration Patterns That Scale (Without the Burnout)

Juan Miguel Rodriguez Ceron — Fri, 07 Aug 2026 15:19:33 +0000

A few days ago I gave an internal talk at Clarity's AI tools Community of Practice about advanced Claude Code usage. It was a live demo, so this is the written, tidied-up version of what I showed, for anyone who wants to come back to it.

This is the companion post to Pi: a Minimal Agent Harness: if that one is about the smallest possible tool and everything you learn because it hides nothing, this one is about squeezing a very complete one for all it's worth.

One heads-up before we start: this is advanced content. It assumes you're already comfortable running Claude in auto mode — that is, you trust the agent enough to let it execute without approving every step. If you're just starting out, do the basic path first — plan mode, iterate, review — and come back later. I say this because almost everything that follows takes that trust for granted.

The normal flow is still 90% of it

Before the flashy stuff, it's worth remembering that the most common flow is still "the usual one", and it's the foundation of everything else:

Describe the task in plan mode.
Iterate on the plan until it makes sense.
Implement/execute the plan.
Review the changes.
Open the MR.

That's literally 90% of the time. The one new rule worth internalizing: if you find yourself repeating the same instructions three or more times, turn them into a repo-specific skill. That single habit gives you more leverage than anything else in this post. In the frontend repo we already have several skills (create MR, remove a feature toggle, remove warnings, debug), and the beauty is that they're adapted to the repo, so the agent already knows where to look and which tools to use without you explaining it every time.

Orchestrating agents: serial or parallel

When a task doesn't fit in a single conversation, you can have Claude split it across several agents. There are many ways to orchestrate that, and picking the right one makes all the difference in control and cost. These are the two most basic models I've tried so far:

The first is serial: a resumable loop where you make one change, wait for its MR to be merged, and only then move on to the next. The state lives in a markdown file, so you can close your laptop and pick it up the next day. This is what you want when you have lots of similar changes but need to review each MR before moving on. It's cheap, because only one task runs at a time, and although Claude does most of the work, a human stays in the loop the whole time.

The second is parallel: Claude launches many sub-agents at once to do independent pieces simultaneously. It's for repetitive work with no ordering dependencies — adding return types to every file, increasing test coverage, migrations... — tasks where each sub-agent can work on its own on a file or module. You can ask Claude to orchestrate the sub-agents, have each one work in its own worktree or make its own commit, and let the main agent handle merging everything and opening the MR. It's much faster, but expensive in tokens. Each sub-agent is like an independent conversation, except this time between the orchestrator and the sub-agent, following the plan you defined earlier. To activate it, just ask with words like "fan out" or "spawn agents" when creating the plan: either one tells Opus to put together a parallel orchestration plan.

⚠️ A tip that can genuinely save you money: explicitly tell it to use Sonnet for the sub-agents. If you don't, it may end up running them with Opus or Fable and burn tokens at a terrifying rate (the classic case is Fable spending "like crazy"). The rule is: orchestrate with Opus, execute subtasks with Sonnet.

Commands worth knowing

Beyond orchestration, there are a handful of commands I showed in the demo and use often:

Deep research. Works like Perplexity or Google's deep search: it spawns agents in parallel, searches sources, and compiles a cited report. Very useful for researching new topics, exploring market alternatives, reviewing the literature on a specific problem... Watch the model again: Opus gets better results but costs more; Sonnet is cheaper.

Handoff. You ask Claude to write a plan in markdown with everything needed to continue in a new session. Perfect when you spot a refactor or subtask you don't want to cram into the current MR, or when you're about to run out of context. There's a well-known skill for this, but it's really four lines: you can just ask Claude directly.

/insights. Analyzes all your sessions and generates an HTML report with statistics, the problems you usually trip over, improvement suggestions, and even "moonshots". Great for debugging your own skills, hooks, and agents. Worth running every now and then.

Remote control. Lets you monitor and pilot an active session from your phone or another browser, while the session keeps running in the terminal. It's documented here. It's a bit buggy — sometimes the connection drops and you have to go back to the terminal — but its real value is that it lets you get up from your chair: approve a plan from the kitchen, go out for a walk. One warning, half legal, half health-related: don't use it outside working hours; in Spain that's literally illegal. Which ties into the next point, and this one is serious.

Don't burn out

These flows are fast and highly addictive. Because they move so quickly, you feel like stopping is losing money or time, and that keeps you glued to the screen. That's a recipe for burnout. Take breaks, stand up, and don't have five agents running all the time just because. This isn't a joke — there are plenty of testimonies about it, and if this was already a problem in the profession, it's going to get much worse.

But how did we get here?

If you stop to think about it, the leap is enormous. I've been writing about this on the blog for a few years, and rereading those posts is a bit dizzying:

In Developing with ChatGPT (April 2023) I told how I asked ChatGPT for code snippets and pasted them by hand, amazed that it would write me a decent Dockerfile or README.
A year later, in LLMs review, one year on, things already looked like a paradigm shift, although still surrounded by skepticism and without a clear sense of where it was heading.
And in 2025 review in 'assisted' development (January this year) I was already talking about entire projects done in days instead of months, and about hand-writing code starting to make no sense.

In less than three years we've gone from copy-pasting snippets from a chat to orchestrating swarms of agents that open their own MRs while we review. What I describe in this post — orchestrating sub-agents, letting them run in auto mode, piloting them from your phone — would have sounded like science fiction when I wrote that first post. And I have a feeling that in a year this will also feel dated. That's why I think it's worth leaving these notes as a snapshot of where we are today.

Where to start

If I had to pick three things to try this week:

Turn an instruction you repeat often into a skill, in a repo you actually work on.
Run /insights once and adopt at least one of its suggestions.
Orchestrate a serial batch over a small set of similar tickets, with sub-agents on Sonnet.

As always, you can leave comments on github or write to me on bluesky. And if you set up your own agent orchestration, I'd love to hear how it went.

Pi: The Minimal Agent Harness That Powers OpenClaw — Run It Safely in Docker

Juan Miguel Rodriguez Ceron — Fri, 07 Aug 2026 15:01:26 +0000

A few weeks ago I gave another internal talk, this time about Pi, a coding agent harness I've been using to experiment. If the Claude Code post was about squeezing a very complete tool, this one is almost the opposite: the smallest possible tool, and everything you can learn precisely because it hides nothing.

Heads-up: this is experimental territory, not a recommendation for your daily workflow. Pi is powerful and dangerous in equal measure, and part of the fun of this post is giving you a template so you can play with it without shooting yourself in the foot.

What Pi is

Pi is the agent harness that actually sits at the core of OpenClaw. It's minimal to the extreme: four tools — read, write, bash and ls — and with that, a model can do anything on a computer. No plan mode, no MCPs, no sub-agents, no Jira integration, no connection to your GitHub repo. Above all, there's no permissions system and no guardrails: you ask it for something and it goes and does it, doing whatever is needed to get it done, including installing global dependencies or writing bash scripts.

My favorite metaphor: Pi is to agent harnesses what vim is to IDEs. It's the bare minimum, and you can add whatever you want on top. Just like you can build your own IDE on top of vim, you can build your own Claude Code on top of Pi.

Minimal as it is, it's not without opinions. It has three very specific traits that make it interesting:

Transparency. The model's entire thought process, every tool call, every command and its output are visible in the session output.
Session export. It generates an HTML file with the complete session that you can share.
Tree navigation. You can jump to any point, resume the session from there, and open a new branch in the session tree.

Why transparency matters so much

This is what really hooked me. When you work with Claude Code and spawn sub-agents, all you see is "working…" and then a result; with the new versions you can jump into the sub-agent's session, but all of that is lost once the agent finishes its work. With Pi you see exactly what the model is doing at every step. If you want sub-agents, you ask pi to create them using pi, in tmux or as background processes — and you can save those sessions too.

The HTML export lets you review everything with a small UI: a sidebar with navigation where you can filter to only the user prompts, see everything with or without tool calls, and jump to any point. (Claude's export, by comparison, is the bare console text.)

What's that good for in practice? Learning how a model behaves given a specific prompt. Whether the model gets something wrong or tries several times, whether it starts "reading" files it shouldn't, whether it misinterprets your prompt (you also see the full "thinking" output).

I ran the same task — replacing some percentages with bars in a dashboard — with Claude using Opus and with Pi using an open-source model, and comparing the two sessions side by side was the most instructive part of the whole experiment: where it needs an example, where it forgets to write tests (both forgot, by the way).

Running it safely

Pi runs in YOLO mode by default. No permission prompts, no questions, it does what it thinks it needs to do. Installing it globally on your machine is very risky and totally inadvisable — one bad prompt or one hallucination and you have the agent running bash with your credentials and your whole filesystem within reach.

One solution is to put it in a Docker container. For the agent, the whole world is that empty container with a project folder and nothing else. It doesn't see your environment variables (only the ones you pass), doesn't see your system, and can't touch the network unless you explicitly allow it. The risk of it doing something destructive drops massively.

You can use this Dockerfile as a template: it installs pi globally, copies your provider extension if you use LiteLLM or ollama, and gets everything ready to run as an unprivileged user.

FROM node:24-bookworm-slim

# Basic tools + pi installed globally
RUN apt-get update && apt-get install -y --no-install-recommends git ripgrep fd-find \
    && apt-get clean && rm -rf /var/lib/apt/lists/* \
    && ln -sf /usr/bin/fdfind /usr/local/bin/fd
RUN npm install -g @mariozechner/pi-coding-agent

# Pi config structure under the node user's home
RUN mkdir -p /home/node/.pi/agent/extensions && chown -R node:node /home/node/.pi

# Pass whatever config you want, like your provider extension,
# your settings and the model list
COPY --chown=node:node extensions/ /home/node/.pi/agent/extensions/
COPY --chown=node:node .pi/settings.json /home/node/.pi/agent/settings.json
COPY --chown=node:node .pi/agent/models.json /home/node/.pi/agent/models.json

# Non-root user (UID 1000): no sudo, and files keep your permissions
USER node

WORKDIR /workspace
ENTRYPOINT ["pi"]

Build it with docker build -t pi-agent . and, once you have the image, run it interactively:

docker run -it \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  -e API_KEY=$YOUR_API_KEY \
  -v "$(pwd):/workspace" \
  pi-agent

--cap-drop ALL removes all Linux capabilities and --security-opt no-new-privileges prevents privilege escalation inside the container.
In the Dockerfile the agent runs as the node user (UID 1000, not root), so it has no sudo and the files it creates have user 1000 permissions — usually the first user on the system, so it probably matches yours.
-v "$(pwd):/workspace" mounts only the current directory: the only thing the agent can read, edit or execute.
Only the environment variables you pass with -e reach it, normally nothing more than the API key.

One detail worth mentioning: I put an AGENTS.md in the image telling the agent it's inside an isolated sandbox, that it should not try to inspect the environment (DNS, installed tools, network…) because what it sees doesn't correspond to your real machine, and that it should instead give you instructions so you can check things yourself. Without that, small models start running dig and whois inside the container and confuse themselves.

With an alias you're two keystrokes away:

alias pi='docker run -it --cap-drop ALL --security-opt no-new-privileges -e API_KEY=$YOUR_API_KEY -v "$(pwd):/workspace" pi-agent'

Easy as pi.

Models: from cloud proxies to open source

Pi talks to any OpenAI-compatible provider, and adding one is a few lines in an extension. The structure looks like this (you register a provider with its baseUrl, its key and the model list):

import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";

export default function (pi: ExtensionAPI) {
  pi.registerProvider("My proxy", {
    baseUrl: "https://your-litellm-proxy/v1",
    apiKey: process.env.API_KEY,
    api: "openai-completions",
    models: [
      {
        id: "glm-5",
        name: "GLM 5",
        input: ["text"],
        contextWindow: 200000,
        maxTokens: 32768,
        reasoning: false,
        cost: { input: 1, output: 3.2, cacheRead: 0, cacheWrite: 0 },
      },
      // ...more models
    ],
  });
}

Pointing at a proxy like LiteLLM you can use both frontier models (Claude and friends) and open-weight ones, which is where the fun part is. Of what I've tried, GLM 5 is the best by far — I'd say it's around Sonnet level — and you can do a lot with it; Minimax 2.5 and Kimi K2.5 also hold up well. I wouldn't use it for everything (you miss the MCPs, integrations, memory, sub-agents…), but running them a couple of times while watching the whole session teaches you a lot about where open models stand today.

Local models with Ollama

Another option is running the model on your own machine, without sending anything anywhere. Pi connects to Ollama just like any other OpenAI-compatible provider (pointing at http://127.0.0.1:11434/v1).

Using an Ollama model for agentic tasks isn't entirely plug-and-play: you need to create a variant with the right configuration using a Modelfile. The key is lowering the temperature and tuning the context window and output tokens. The Gemma4 models have their own recommended parameters for agentic tasks; for qwen I've tested with:

FROM qwen3.5:9b

# Config for coding tasks: low temperature, contained context
PARAMETER temperature 0.1
PARAMETER top_p 0.8
PARAMETER top_k 20

PARAMETER num_ctx 32768
PARAMETER num_predict 4096

# Number of CPUs (leave headroom to keep working)
PARAMETER num_thread 8

To create the model:

ollama pull qwen3.5:9b
ollama create qwen-coding -f Modelfile

On which model to choose, my experience on a Linux box with 32 GB of RAM and no GPU:

The 9B (Qwen) is the reasonable minimum. It takes over a minute to warm up and is slow, but it handles small tasks and answers questions about the repo.
The 4B hallucinates out of control: it makes things up and keeps derailing the conversation.
On a Mac, you can go for 27/30B models, which land somewhere between Haiku and Sonnet in terms of capability.

Pi has one decisive advantage over Claude Code for small models: Claude Code's system prompt is thousands of lines with a ton of tools, and that overwhelms small open models. Pi's minimalism is exactly what lets them work.

There's something special about being offline — on a train or wherever — and still being able to ask your repo questions and get changes made by just asking the agent.

In summary

Pi as a test bench is unbeatable: you see everything the model does, compare behaviors, and can run open-source and local models that wouldn't even start under a heavier harness. If you're interested in understanding how agents work on the inside, instead of just using them, it's well worth setting it up over a weekend. Just make sure: inside a container. If you're interested, I have a small repo with this setup for local models on github.

As always, you can leave comments here or on github or write to me on bluesky. And if you set up your own Pi configuration, I'd love to hear how it goes.

Using the Socratic method for mentoring

Juan Miguel Rodriguez Ceron — Wed, 28 Jun 2023 21:04:47 +0000

Using the Socratic method in the workplace can be a powerful tool for mentoring junior coworkers, guiding team meetings, and encouraging critical thinking and problem-solving skills.

Marcello Bacciarelli, CC BY-SA 4.0, via Wikimedia Commons

I specially like when a coworker or team lead challenges my opinion with the right question, it makes me think about possible solutions instead of feeling attacked or contradicted. This is why I am trying to learn how to do it and apply it myself when I have the opportunity.

Disclaimer: The Socratic method is a very general term to describe the different techniques that Socrates used for teaching, encouraging critical thinking and discussion. In this post we will use it describe an approach about leading and mentoring at work.

The Socratic method involves asking open-ended questions that encourage coworkers to think deeply and critically about the topic at hand, rather than simply telling them what to do. By giving them space to think and explore their own ideas, you'll be helping them become more confident and independent workers.

Using Socratic questioning effectively

When using the Socratic method, it's important to actively listen to your coworker's responses and ask follow-up questions to clarify their thinking. This will help you understand their thought process and guide them towards a deeper understanding of the topic. Additionally, it's important to demonstrate that you're actively listening and engaged in the conversation by maintaining eye contact, using nonverbal cues, summarizing key points, and avoiding interrupting.

Ask open-ended questions that encourage deep and critical thinking

Actively listen to coworker's responses and ask follow-up questions

Demonstrate active listening and engagement through nonverbal cues and summarizing key points

Example 1: Pairing

As any other method or technique, knowing the theory is not enough, practicing is key to know which is the right question and when to do a new question or when to wait and give space to the other person. For example, this are some questions you could use while pairing or reviewing code:

What's your understanding of the problem we're trying to solve here?
How would you approach this problem if you were working on it alone?
What are some potential solutions you've considered so far?
What are the pros and cons of each solution?
How would you test your solution to make sure it works as expected?
Are there any edge cases or potential issues we should consider?

Try to use them when you are pairing or discussing a topic with a coworker or friend and observe how they react, if you surprised them or they feel that their opinion is important. Observe also yourself, asking this questions when you think that you know the right answer is difficult. Were you able to be patient while your mentee was trying to find the right words? Did you look calm and encouraging? Were you listening actively?

Example 2: In team meetings

In team meetings, it's important to encourage participation from all team members by creating a supportive and inclusive environment. Acknowledging the contributions of different team members and using visual aids to participate (like boards or post-its or any of the multiple virtual tools that we have for meetings) can help to create that collaborative environment.

So, for example, if you have a board where every member of the team has to add an idea or a concern (maybe anonymously, depending on the topic) and then you read them aloud and comment each of them with the team, each team member will feel that they have been listened and they had the opportunity to express themselves.

As a senior developer, it's important to participate in team meetings and contribute your expertise without dominating the conversation or imposing your point of view.

Asking questions, providing context, sharing examples, encouraging collaboration, being neutral, and listening actively are all ways to participate without giving a direct opinion.

So, if you are one of the seniors members of the team, maybe you should try to lead some meetings using these practices, or simply offer yourself to take notes and lead the meeting from there. The person taking notes can summarize aloud what it has been said and remember any commitment or follow up actions that have been discussed.

Key points to remember:

Encourage participation from all team members
Listen actively and ask follow-up questions
Summarize key points and ask for feedback
Avoid dominating the conversation and encourage collaboration
Keep an open mind and remain neutral
Acknowledge contributions
Use visual aids to encourage participation
Follow up individually if needed

Conclusion

Using the Socratic method in the workplace can be a powerful tool for mentoring junior coworkers and guiding team meetings. You can help your team members become more confident and independent workers, and encourage the generation of new ideas and solutions as a team.

Learn more!

Some links to keep learning about the topic:

Socratic questioning
Asking good questions
LinkedIn Learning has many videos and courses about active listening that can be great to learn by example, f.e. this video about active listening

This post was created and edited by me with help of AI and Google, I was learning about the topic and I thought that it may be useful to share a summary on the topic.

Developing with ChatGPT

Juan Miguel Rodriguez Ceron — Mon, 24 Apr 2023 08:55:24 +0000

Are you curious about the possibilities of ChatGPT and how it can be used in your own projects? With the recent exciting advancements in language models and generative AI, there's never been a better time to dive in and start experimenting. In this blog post, I'll be sharing my own journey of developing a personal assistant using ChatGPT - from the challenges I faced to the solutions I discovered along the way.

As someone who has been following the exciting advancements in language models, generative AIs, and artificial intelligence, I couldn't wait to dive into the world of ChatGPT. It represented a paradigm shift in the way we think about natural language processing.

For me, it was a clear sign that I needed to start taking learning about these topics more seriously, so I embarked on a personal project to create my own personal assistant using ChatGPT. I wanted to experiment and learn at my own pace, without the constraints of a directed course.

My ultimate goal was to develop an assistant that really knew me - one that would remember our previous conversations and run on my own personal computer. Even if I never quite achieve this lofty ambition, I knew that working on this project would be a fantastic way to immerse myself in the topic.

To make things even more challenging, I decided to use Python - a language I wasn't particularly proficient in - and to always rely on ChatGPT instead of turning to Google or external documentation. This created a project that was not only challenging and exciting, but also incredibly meta. By using ChatGPT to develop tools that will ultimately replace it with my own personalized version.

For now the experience is great. I develop new functionality very quickly, ChatGPT unlocks me very often and keeps me much more in the flow than having to read documentation or search Google and in general the feeling of speed and satisfaction is great. I also believe that this is because I'm using ChatGPT in the ideal scenario:

A new and small project, a command-line app, so adding functionality is very easy, you don't need frameworks or components or big architectures
In a language I don't master, ChatGPT is very useful to solve doubts, and the domain itself is ChatGPT's specialty.
Python is a language especially suitable for LLMs because it has less syntax and is dynamic. Properties that make it ideal for humans and LLMs because right now it's the closest thing we have to programming in natural language.

Without all these factors, the usefulness of ChatGPT starts to degrade for me. In fact, at work I use it much less often, it's just harder to explain what I want than to do it myself. But that's why I think we will all end up with our own personal or company assistant who knows the ins and outs of our projects and can help us with more context...

But let's get to the point, I'm going to list some examples of how I've used ChatGPT in this project and when I can I'll link to specific conversations about that topic that I had with ChatGPT. These are some things I've done with ChatGPT to work, not just to explore what it knows, learn or try to play or entertain myself:

Readme: The first version of the Readme was written by ChatGPT, I edited it and have been expanding and improving it since then.Read the conversation here
Dockerfile: I asked ChatGPT for a dockerfile because to be honest I don't know the syntax by heart and I always end up copy-pasting. At first it gave me a completely functional dockerfile and the command to execute the assistant from the dockerfile. Then I edited it a bit to remove some things I didn't need and change the order of the commands a bit to better use docker's cache.Conversation
TTS: The assistant has a text-to-speech option so you can listen to its responses, although by default I have it disabled (it's faster to read and the code doesn't make sense to listen to). The first version was again its own, then I tried several voices and libraries, and in the end I settled on one that wasn't the one ChatGPT suggested.
Upload conversation to a gist. I also asked ChatGPT for the upload file, then I put the code into a function to use it from the app instead of as a script.Conversation
Retrieve a conversation parsing the markdown file. This is not integrated yet, but I've already played with ChatGPT and have the initial code that should make it possible.Conversation
Refactors. I've done several refactors where I've given it a big function and asked it to split it into smaller functions.
Tests. The first tests of the ChatGPT class were done by ChatGPT, and the ones for the actions module were done with copilot's help.

In general ChatGPT has helped me throughout the process. from outlining solutions, consulting how libraries work, writing tests... The pattern is similar every time, and that's why I think it's especially useful if you don't master the language, because if you do, you'll take the same time or less to write it yourself. But if you don't know the available libraries and modules, asking ChatGPT how it would do it saves a lot of time in trial and error and research and reading documentation.

Besides, for me this process is usually a rabbit hole: I start looking for a library to do X and there are 10's, and now I have to see which ones are more popular and why, and I want to see a little how they work... and when I realize it's been 2 hours and I haven't done anything. With ChatGPT all that process is much more immediate and fluid, even if I end up using another library or heavily editing or discarding its first solution. It keeps me more in the flow and more focused on the problem than all those websites full of ads and cookie popups, videos and other distractions.

I'm sure I'm only scratching the surface here. LLMs seem to have a lot of potential at various levels, and little by little we'll be integrating them into IDEs and user interfaces, but even in this rudimentary form and without knowing very well what I'm doing I think I gain a lot of productivity and the development process is much less frustrating.

Thanks a lot for reading, if you got this far please tell me what you think in the comments. Have you used ChatGPT for programming? Do you have a specific setup or workflow? I would love to know about it!

This blog post was translated by ChatGPT from the original Spanish one which you can read here

Introducción a Node.js

Juan Miguel Rodriguez Ceron — Mon, 16 Jul 2018 22:06:13 +0000

(Este post fue publicado inicialmente en mi blog, pásate para ver más contenido sobre desarrollo, javascript y tecnología: Por amor al código)

Node.js es un entorno de ejecución de JavaScript que utiliza el motor V8 de Google. La historia de JavaScript y de Node.js es curiosa porque casi parece que todo surgió por accidente. JavaScript es conocido por haber sido diseñado en 10 días por Bredan Eich y por sus inconsistencias, pero aun así, se ha convertido en el el lenguaje de facto de la web. La imposición tecnológica de los navegadores, unido a la bajísima curva de aprendizaje han hecho de JavaScript el lenguaje con más crecimiento de los últimos tiempos. Herramientas como jQuery, Mootools y Backbone, Lodash, Angular, React... Han ido evolucionando la arquitectura de un lenguaje dinámico en principio carente de estructura. JS es en la actualidad uno de los lenguajes más utilizados y de mayor crecimiento. Con lo que era inevitable que los desarrolladores de JavaScript quisieran usar el lenguaje fuera de los navegadores. Como dice la Ley de Atwood:

Any application that can be written in JavaScript, will eventually be written in JavaScript ver más

Antes de Node.js hubo varios intentos de establecer un entorno de ejecución para JavaScript fuera de los navegadores. Los programadores querían sacar JavaScript del corsé del navegador, querían poder hacer aplicaciones, modificar ficheros y acceder al hardware. Una historia muy entretenida sobre los inicios de Node.js y npm la cuenta el propio Issac Z. Schlueter (creador de npm) en su blog

TLDR: Node.JS y npm se convirtieron en el entorno de ejecución de JavaScript en el servidor. Ahora podemos utilizar el mismo lenguaje para desarrollar en el servidor y en el cliente en el caso del desarrollo web, aunque también hay gente usando Node para ioT, para robots, para herramientas de línea de comandos, etc.

Instalación y el REPL

Para instalar Node.js en Windows o en Mac, basta con ir a la página principal y descargar el instalador. Si usas Ubuntu, solo necesitamos un par de comandos:


curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
sudo apt-get install -y nodejs

Si usas otra distribución de Linux, mira aquí.

Una vez instalado podemos comprobar que la versión es la correcta (actualmente la versión LTS es la 6.x) escribiendo


node -v

Para ejecutar el intérprete de Node, el REPL, simplemente escribimos el comando node y el terminal pasará a ser una consola de JavaScript en la que podremos ejecutar nuestro código.

El REPL (siglas del inglés Read Eval Print Loop) es una consola que ejecuta cada expresión en JavaScript que le demos y devuelve el resultado de la expresión inmediatamente. Por ejemplo si escribimos:


> 2 + 2
4

4 es el resultado de la expresión 2 + 2, otro ejemplo


> console.log('Hola Mundo')
'Hola Mundo'
undefined

'Hola mundo' es la salida que produce console.log('Hola Mundo') y undefined es lo que devuelve la función. También podemos definir funciones y variables globales que podremos usar a continuación:


> var factorial  = function(x) {
...   if ( x <= 1 ) return x
...   return x * factorial(x-1)
... } 
undefined
> factorial(4)
24

En las versiones actuales de Node.js tenemos soporte de prácticamente la totalidad de la especificación de ES2015, con lo que podríamos escribir la función de arriba de otra forma:


> const factorial  = x => ( x <= 1 ) ? x : x * factorial(x-1) 
undefined
> factorial(4)
24

El REPL es muy útil para probar pequeñas funciones y expresiones, yo cada vez lo utilizo más a menudo y los ejemplos de este blog suelen estar escritos de forma que sean fáciles de probar en el REPL. La ventaja de tener una respuesta inmediata a una duda de código es invaluable y normalmente no nos damos cuenta de eso hasta que lo probamos.

Módulos y npm

Node no es solo el REPL, también podemos ejecutar ficheros. Solo tenemos que crear un fichero con el código javascript que queramos ejecutar y pasárselo al comando node


echo 'console.log("Hello Node")' > hello.js
node hello.js
// Hello Node

Cada fichero JavaScript es un módulo para Node.js y si queremos usar alguna función definida dentro del fichero primero tendremos que exportarla. Por ejemplo creemos el fichero factorial.js con el siguiente contenido:


const factorial = x => ( x <= 1 ) ? x : x * factorial(x-1)

module.exports = factorial

Si ejecutamos ese fichero veremos que no pasa nada.


node factorial.js

Nuestro módulo no hace nada a parte de definir una función y exportarla, pero desde el propio REPL o desde otro fichero Node.js podremos importar esta función y utilizarla:


> const factorial = require('./factorial.js')
> factorial(5)
120

¿Mola eh? Ya tenemos un mecanismo para escribir código, encapsularlo en módulos y ejecutarlo. Esta es la base del desarrollo en Node, tan sencillo como eso.

Node trae una serie de módulos básicos que podemos utilizar a modo de librería estandard Pero uno de los puntos fuertes de Node.js es el haberse mantenido flexible gracias a tener una librería estandar muy pequeña.

Ese es también el punto fuerte de npm. npm es un repositorio centraliazdo de módulos para Node.js En la comunidad de Node.js y npm la filosofía también es la de módulos pequeños que hagan una sola cosa, parecido a lo que ocurre con los comandos de Unix. Esto hace el lenguaje más fácil de componer, reordenar y modificar y tiene un gran potencial. Ahora mismo npm es el repositorio con mayor número de módulos de código abierto de todos los lenguajes y su número sigue creciendo a mayor velocidad que todos los demás.

npm se instala en nuestro sistema junto con Node.js y podemos usarlo para instalar cualquier paquete de forma global o local a nuestro proyecto. Un proyecto es simplemente una carpeta donde hemos ejecutado npm init:


mkdir hello
cd hello
npm init

Al ejecutar este comando el programa nos hará algunas preguntas sobre el proyecto y creará un fichero package.json con la configuración mínima. Si solo queremos probar a instalar algunos paquetes podemos ejecutar npm init -y para crear este fichero y npm usará la configuración mínima por defecto y el nombre de la carpeta como nombre del proyecto.

Ahora podemos instalar cualquier paquete del registro ejecutando npm install Por ejemplo podemos instalar expressjs, una serie de librerías para crear un servidor web:


npm install --save express

El modificador --save indica a npm que queremos que guarde esta dependencia en el fichero del proyecto. Con express instalado localmente, podemos crear nuestro fichero index.js con este contenido:


const express = require('express')
const app = express()

app.get('/', function (req, res) {
  res.send('Hola desde Node!')
})

app.listen(3000, function () {
  console.log('Servidor creado y escuchando en el puerto 3000!')
})

Y ejecutarlo en la consola:


node index.js

Servidor creado y escuchando en el puerto 3000!

Si abres un navegador y vas a 'localhost:3000' verás el mensaje 'Hola desde Node!'

Esas son las herramientas básicas de desarrollo en Node.js. Módulos, un entorno de ejecución, el repositorio central de npm y JavaScript. Con lo que sabes ya puedes ir a explorar un poco el registro de npm o la documentación de express y comenzar a desarrollar tu propio servidor web :D

Great github threads

Juan Miguel Rodriguez Ceron — Sat, 30 Jun 2018 22:26:44 +0000

My favourite part about Github are the discussions. Like Twitter, Github allows you to watch the comments and code of well known software developers and have a pick of their way of thinking. The code is interesting, but a lot of times the code lacks the WHY. Why the team or the developer chose to use a pattern or a design or why a feature made it to a language or not.

You can see how big projects evolved thanks to issues, commits and PRs, and you can even participate in the debates and of course in the code. Before Github, all this information was in projects' newsletters, forums, chats... The information was more difficult to find and it would last less.

Below there are a list of some Github threads that I considered interesting and worth of bookmarking. All of them, except for the last one, are about JavaScript, because it is my main language right now. Do you know any other great Github threads? Issues, PRs or maybe a gist that created an good discussion? Please leave it in the comments, I really love learning from others' points of views and their arguments.

Promises are not monads Promises could have been very different if it wasn't for some opinionated developers that really wanted them to be like they are.
Promisify/awaitable in node Another one about promises and why the promisify function was added to node.
Immutable issue about typescript Discussion of ways of creating immutable data structures that work with typescript.
About ngrx/store and immutable.js Immutable.js has trade offs as any other library. Immutability is great, but in JavaScript it is not idiomatic and it creates some friction...
Browserify and webpack Browserify can do most of what webpack does, and even more in some cases, great gist and good discussion about the two tools.
One line modules Sindre Sorhus about one line modules and why npm made the "utils scripts" folders irrelevant.
Node-chakracore About adding the Microsoft core for JavaScript into Node.
Linus Torvalds being... Linus Torvalds The last pearl in the list is not about JavaScript and not about a great discussion. Sometimes github allows you to see the bad parts of software development too. Linus is famous for being rude and coarse, this is just one of the multiple examples.

Generadores en JavaScript

Juan Miguel Rodriguez Ceron — Wed, 27 Jun 2018 22:35:27 +0000

Los generadores son una herramienta de programación muy poderosa, pero difícil de entender cuando la vemos por primera vez. En este artículo trataré de definir de forma lo más sencilla posible qué son y como se usan los generadores y pasar a varios ejemplos prácticos en los que los generadores nos permiten simplificar código o directamente hacer cosas que no pensábamos que se pudieran hacer en JavaScript como funciones de evaluación perezosa y corutinas.

¿Qué es un generador?

Un generador es una función especial en JavaScript que puede pausar su ejecución y retomarla en un punto arbitrario. Para definirlos utilizamos dos nuevas palabras reservadas del lenguaje: function* y yield.

Este es uno de los casos más claros en los que he encontrado que la barrera del idioma a veces dificulta la comprensión de ciertos conceptos. yield es una palabra poco habitual en inglés, y para un no-nativo como yo, me suena totalmente fuera de contexto. Se traduce como producir o ceder

Trataré de explicar su funcionamiento con un ejemplo de código:


function* counterGenerator() {
  let i = 0
  while (true) {
    yield i
    i++
  }
}

var counter = counterGenerator()

counter.next() // { value: 0, done: false }
counter.next() // { value: 1, done: false }
counter.next() // { value: 2, done: false }
... // hasta el infinito y más allá!

Este sencillo ejemplo muestra el funcionamiento de un generador. El uso más habitual de los generadores es crear Iteradores. Un Iterador es un objeto que devuelve un elemento de una colección cada vez que llamamos a su método .next. counterGenerator devuelve un iterador que asignamos a la variable counter.

Los generadores siempre devuelven un iterador y en el momento en el que llamamos al método .next del iterador, éste ejecuta la función del generador hasta llegar al primer yield que encuentra, que detiene la ejecución de la función y produce un resultado, o dicho de otra forma, produce un elemento de la colección.

El resultado es siempre un objeto con dos propiedades, value y done, en la primera está el valor producido por yield y la segunda es para indicar si el iterador ha terminado, es decir, si ese era el último elemento de la colección.

En la siguiente llamada a .next la función continúa desde el yield y hasta el siguiente yield, y así hasta encontrar un return que devolverá true como valor de done.

El iterador devuelto por counterGenerator Puede usarse a su vez dentro de un bucle for of, ya que estos bucles utilizan el interface del iterador para obtener el valor de cada iteración:


for(var c of counter) { 
  console.log(c)
  if(c > 10) break // break detiene el bucle for como si hubiera encontrado done === true
}

// 1
// 2
// 3
// ...
// 10

Bucles infinitos y evaluación perezosa

En el ejemplo anterior hemos usado todo el tiempo un bucle while (true) sin bloquear o saturar la cpu y sin ninguna alerta por parte de node. Esto es así porque yield pausa la
ejecución de la función, y por lo tanto, pausa el bucle infinito, cada vez que produce un valor.

Esto es lo que se llama evaluación perezosa y es un concepto importante en lenguajes funcionales como Haskell. Básicamente nos permite tener listas o estructuras de datos "infinitas" y operar sobre ellas, por ejemplo podemos tener un operador take(n) que toma los N primeros elementos de una lista infinita:


function* oddsGenerator() {
  let n = 0
  while (true) {
    yield 2*n + 1
    n++
  }
}

function take(n, iter) {
  let counter = n
  for ( c of iter) {
    console.log(c)
    counter--
    if(counter <= 0) break
  }
}

var oddNumbers = oddsGenerator() // TODOS los números impares 

take(5, oddNumbers) // toma 5 números impares
// 1
// 3
// 5
// 7
// 9

La evaluación perezosa permite construir este tipo de estructuras "infinitas" o completas sin producir errores de ejecución y también son más eficientes en algoritmos de búsqueda, recorrido de árboles y cosas así, al evaluar el mínimo número de nodos necesarios para encontrar la solución. Para ver más usos y ventajas de la evaluación perezosa puedes ver este hilo de stackoverflow

Como añadido en JavaScript, los generadores nos permiten crear una sintaxis más legible en el uso de arrays. Podemos obtener los valores producidos por el generador en ES6 mediante el spread operator:


function* range (limit) {
  let c = 0
  while ( c < limit ) {
    yield c
    c++
  }
}

[...range(5)]
// [ 0, 1, 2, 3, 4 ]

Pero cuidado con utilizar el spread operator o los bucles for con listas infinitas como la de arriba:


for(let c of oddNumbers) { // bucle infinito!!
  console.log(c) 
}

[...oddNumbers] // bucle infinito y 'out of memory', no podemos crear un array infinito en la memoria!!

Async/await y corutinas

Además de la generación de iteradores, los generadores nos permiten controlar la ejecución de funciones asíncronas gracias al mecanismo de pausa de la función de yield. Para explicar por qué esto es importante, vamos a desviarnos un momento y hablar de async/await

Una de las funcionalidades más coreadas de ES7 son las nuevas construcciones async y await, que nos permiten ejecutar código asíncrono pero escribiéndolo de forma lineal, sin necesidad de pensar en callbacks o promesas. Veamos cómo funciona:


function helloDelayed() {
  return new Promise((resolve, reject) => {
    setTimeout(() => resolve('Hello'), 5000)
  })
}

async function hi() {
  const greeting = await helloDelayed()
  console.log(greeting)
}

hi()

// a los 5 segundos aparece 'Hello'

Lo genial de async/await es que el código de la función async es lineal, le hemos pasado una promesa a await y nos devuelde directamente el valor con el que se ha resuelto, esperando y deteniendo la ejecución de la función.

No me voy a detener más en explicar cómo funciona, eso lo dejo para otro post, pero async/await en realidad no es más que un uso concreto de los generadores, azúcar sintáctico para usar un generador y evaluar una promesa, podríamos replicar esta funcionalidad, para una sola llamada (más adelante veremos la generalización) así:


function helloDelayed() {
  return new Promise((resolve, reject) => {
    setTimeout(() => resolve('Hello'), 5000)
  })
}

function hi(gen) {
  const iterator = gen()
  iterator.next()

  helloDelayed.then(res => iterator.next(res))
}

hi(function* () {
  const greeting = yield;
  console.log(greeting)
})

Esta solución es más difícil de leer y de escribir, sobre todo por el doble .next necesario para que funcione, y por la poca legibilidad del comando yield en si mismo. Pero muestra una parte importante del funcionamiento de los generadores.

Lo que está pasando aquí es que hi recibe un generador como parámetro, lo ejecuta y llama una vez a .next para ejecutar el generador hasta el yield y luego lo vuelve a llamar cuando tiene el resultado de la promesa para revolver el resultado al yield.

Hasta ahora no habíamos hablado de esto para no complicar más, pero podemos añadir a la llamada a .next un parámetro, que a su vez podemos capturar en una variable asignándola a yield. Esta, para mi, es la funcionalidad más confusa de los generadores, pero es la clave para usarlos para ejecutar llamadas asíncronas o corutinas como veremos en los siguientes ejemplos. Veamos un pequeño ejemplo de como funciona:


function* counterGenerator() {
  let i = 0
  while (true) {
    const str = yield i
    console.log(str)
    i++
  }
}

var counter = counterGenerator()

counter.next('hi') 
// { value: 0, done: false }
// el primer 'next' no imprime nada porque el generador se ejecuta solo hasta el yield
counter.next('ho') 
// ho
// { value: 1, done: false }
counter.next('hu') 
// hu
// { value: 2, done: false }

Este mecanismo nos da una forma de comunicarnos con el generador, algo muy potente, aunque en mi opinión con una sintaxis difícil de leer y nada clara. Los generadores no son una herramienta que hay que usar con moderación, pero nos permiten hacer cosas que estarían fuera del alzance de JavaScript si no fuera con ellos, como el ejemplo que veremos a continuación.

Generalizando el código de helloDelayed, se puede construir una función que controle la ejecución de funciones asíncronas prácticamente igual a como hace async/await, veamos un ejemplo que lee dos ficheros (ejemplo tomado de este post de TJ HoloWaychuck, que recomiendo leer, el código original usa callbacks, pero lo he modificado para usar promesas, dos ejemplos por el precio de uno ;)):


const fs = require('fs')

function thread(fn) {
  var gen = fn()

  function next(res) {
    var ret = gen.next(res)
    if (ret.done) return
    ret.value.then(next)
  }

  next()
}

thread(function *(){
  var a = yield read('README.md')
  var b = yield read('index.html')
  console.log(a)
  console.log(b)
})


function read(path) {
  return new Promise(resolve => fs.readFile(path, 'utf8', (err, res) => resolve(res)))
}

Este código, sí se parece mucho más al de async/await, es más, si cambiamos thread por async y imaginamos que yield es await es prácticamente igual:


async(function *(){
  var a = yield read('README.md')
  var b = yield read('index.html')
  console.log(a)
  console.log(b)
})

Este ejemplo básico es una simplificación de la librería Co, que nos permite escribir este tipo de código asíncrono de forma lineal y con la seguridad de que captura todas las excepciones de forma parecida a como hacen las Promesas.

Técnicamente esto no son corutinas. En realidad, cuando hablamos de generadores, hablamos de 'semicorutinas' porque los generadores no son tan flexibles como las corutinas de lenguajes como Go, pero diremos que son equivalentes a corutinas, aún sabiendo que estamos simplificando, porque es la herramienta que tenemos para esta función en JavaScript a nivel nativo.

En cuando a otras librerías para corutinas, fibjs y node-fibers son implementaciones de 'fibers' que podríamos traducir como "fibras" o "hilos ligeros" que es más flexible que los generadores y que algunos desarrolladores quieren incluir en el núcleo de Node.js.

Los generadores y las corutinas son herramientas avanzadas del lenguaje que seguramente no tengas que utilizar directamente a no ser que hagas desarrollo de sistemas o librerías, pero de las que podemos sacar provecho en nuestro código con librerías como Co, node-fibers o el nuevo async/await nativo. Espero que estos ejemplos hayan resuelto algunas dudas y generado aun más dudas e interés por el lenguaje y sirva como introducción a todo este tema.

Otra lectura recomendada para profundizar en los Generadores es el libro de Kyle Simpson ES6 and Beyond, y en concreto el capítulo sobre Iteradores y Generadores.

Tests unitarios en JavaScript con Jasmine

Juan Miguel Rodriguez Ceron — Thu, 07 Jun 2018 21:54:12 +0000

Los tests unitarios son una herramienta excelente para prevenir bugs en ejecución y para describir el comportamiento que debe tener el código. Además, y sobre todo si se realizan antes que el código de la aplicación (lo que se conoce como TDD), los test unitarios ayudan a estructurar mejor el código, hacerlo más modular e independiente y además ayudan a dividir los problemas y hacerlos más sencillos de programar.

En JavaScript, Jasmine es un framework de test que permite crear tests fáciles de leer de forma que sirven también de documentación para el código. Así, usando Jasmine, si queremos escribir una suit de tests para una función que suma dos números llamada 'add' la escribiríamos así:


  describe('add function', function() {

    it('should add two numbers', function(){
      // código del test
    });

    it('should throw an error if you try to add strings', function(){
      // código del test
    });

    ...

  })

Vamos a ver algunos ejemplos de código y sus correspondientes tests. El proyecto es una sencilla calculadora en JavaScript, pero es diferente a los típicos ejemplos de calculadoras en javascript, ya que en esta no se utiliza eval para calcular los resultados, sino que el input se valida y las operaciones están limitadas a las que están definidas. Para ello he creado dos pequeños módulos, uno para la lógica y otro para el interface.

El proyecto es un ejemplo sencillo, según las especificaciones de cada proyecto serán pertinentes más o menos tests y habrá que controlar casos más concretos, espero que este proyecto sirva de ejemplo aunque no sea muy exhaustivo ni tenga muchos requisitos.

Empezaremos con los test de la clase que controla el funcionamiento de la calculadora por ser más sencillo. Cuando tienes una clase que no realiza operaciones de entrada salida, ni modifica el DOM o interacciones del usuario es mucho más sencillo escribir los tests. A eso me refería antes con que escribir los tests primero te ayuda a separar el código y a promueve mucho el principio de que cada función se encargue sólo de una cosa. En problemas fáciles como este de la calculadora, es fácil verse tentado a poner todo el código junto, meter un par de funciones en el código que maneja el interface y listo.

El problema viene a largo plazo, cuando el cliente dice que además de calcular tiene que mostrar el resultado intermedio y luego te dicen que al meter un símbolo que no debería hacer nada la calculadora da un error muy feo, o que debería poder guardar en memoria un resultado... Y empezamos a poner más código en esas funcioncitas en medio del interface y esas funcioncitas van creciendo hasta tener cientos de líneas de código y... seguro que ya sabes por donde voy. Nuestra sencilla calculadora, que habíamos programado en un par de horas, crece hasta convertirse en una pesadilla de mantener y de modificar. Y además nuestro jefe no entiende cómo puede ser que hicieramos la calculadora en un día pero ahora para añadir una funcionalidad obvia tardemos una semana.

Por eso es por lo que en esta ocasión vamos a usar TDD y vamos a escribir primero unos tests de lo que queremos que nuestra calculadora haga:


// Calculator.spec.js
describe('Calculator', function() {

  it('should have a storeAction function', function() {
    expect(Calculator.storeAction).toBeDefined();
  });

  describe('storeAction', function() {

    beforeEach(function() {
      Calculator.storeAction('RESET');
    });

    it('should return the last result for unkown actions', function() {
      expect(Calculator.storeAction('HI')).toEqual(0);
      Calculator.storeAction('1');
      expect(Calculator.storeAction('HI')).toEqual(1);
    });

    it('should add numbers', function(){
      Calculator.storeAction('1');
      Calculator.storeAction('ADD');
      Calculator.storeAction('1');
      expect(Calculator.storeAction('RESULT')).toEqual(2);
    });

    it('should multiply numbers', function() {
      Calculator.storeAction('2');
      Calculator.storeAction('MULTIPLY');
      Calculator.storeAction('4');
      expect(Calculator.storeAction('RESULT')).toEqual(8);
    });

  }); 

});

Bien, ya sabemos lo que queremos, una calculadora que sume y multiplique, y que no admita cualquier cosa por la entrada. Para implementar esto nuestro Módulo calculadora debe tener una función storeAction que será la que utilizaremos para introducir la siguiente operación o número sobre el que la calculadora debe operar, imitando el funcionamiento normal de una calculadora clásica. La functión beforeEach es una función de Jasmine que se ejecutará antes de cada función it y que nos sirve para asegurarnos de que antes de cada test partimos del mismo estado inicial.

Estos tests están bien para comenzar, pero si nos fijamos veremos que hay muchos más casos que controlar, como ¿qué pasa si añado dos números seguidos? ¿y si añado dos operaciones? ¿Donde está el test para la función de RESET? Todos estos test deberán ir añadiendose y satisfaciéndose en el código.

Si solo tenemos los tests y los ejecutamos en la línea de comandos o en el navegador, veremos que fallan. Para ejecutarlos lo más sencillo es crear un fichero html en el que añadiremos los scripts de jasmine que están alojados en el CDN de jsdeliver. A continuación añadimos los ficheros js de nuestra aplicación y los ficheros que contienen los tests para los diferentes módulos:

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Sample Unit tests runner</title>

  <link rel="stylesheet" href="https://cdn.jsdelivr.net/jasmine/2.4.1/jasmine.css">

  <script src="https://cdn.jsdelivr.net/jasmine/2.4.1/jasmine.js"></script>
  <script src="https://cdn.jsdelivr.net/jasmine/2.4.1/jasmine-html.js"></script>
  <script src="https://cdn.jsdelivr.net/jasmine/2.4.1/boot.js"></script>

  <script src="calculator.js"></script>
  <script src="calculator.spec.js"></script>

</head>
<body>


</body>
</html>

Al abrir este fichero en el navegador, Jasmine creará un pequeño interface y listará los tests junto con los resultados y los errores que hayan ocurrido. En este caso, si sólo tenemos el fichero de especificaciones, todos los tests fallarán.

Para satisfacerlos, deberemos crear el módulo Calculator y añadir la función storeAction con la funcionalidad suficiente para que satisfaga los tests:


// Calculator.js
var Calculator = (function(){
  'strict mode';

  var store = '',

  lastResult = 0,

  setLastResult = function(num) {

    lastResult = parseFloat(num);

  },

  exports = { 

    isNumeric: function(n) {

      return !isNaN(parseFloat(n)) && isFinite(n);

    },

    storeAction: function(action) {

      if(exports.isNumeric(action) && !exports.isNumeric(store)) {

        var num = parseFloat(action);
        switch(store) {
          case 'ADD':
            setLastResult(lastResult + num);
            break;

          case 'MULTIPLY':
            setLastResult(lastResult * num);
            break;

          default:
            store = action;
            setLastResult(action);
            break;
        }

        store = '';

      } else { // new operation

        store = action;

        if(exports.isNumeric(action)) {

          setLastResult(action);

        } else if(action == 'RESET') {

          setLastResult(0);

        }

      } 

      return lastResult;
    }

  };

  return exports;

})();

Este código satisface los tests de arriba y algunos más. Aún nos quedaría añadir la funcionalidad para restar, dividir, limpiar el input, etc. Puedes ver el ejemplo algo más completo en este thimble. Para ver el resultado de los tests haz click en el fichero 'test.html'.

Si te fijas, en ese projecto no hay tests para la parte del interface de la calculadora. Hay funciones del interface que no tiene mucho sentido testar, el markup puede cambiar sin alterar la funcionalidad y no tiene mucho sentido escribir tests para algo así. Pero sí que podemos escribir tests que verifiquen que, cuando hago click en un botón o pulso una tecla, se llama a la función adecuada. Estos tests son algo más complicados ya que tenemos que capturar los eventos y espiar las funciones que estos deben llamar.

Thimble es una buena herramienta para practicar TDD ya que el proyecto se va guardando y la vista se actualiza de forma automática. Pero necesitamos de conexión a internet y no tiene la velocidad y las ayudas de editores como Sublime o VSCode. Para conseguir que la vista se actualice automáticamente como en Thimble en nuestro proyecto en local podemos utilizar varias herramientas diferentes. En el siguiente artículo me centraré en cómo añadir Karma a nuestro proyecto y utilizarlo para trabajar con TDD.

Ámbito léxico y de bloque en JavaScript

Juan Miguel Rodriguez Ceron — Thu, 07 Jun 2018 21:45:27 +0000

El ámbito de las variables en JavaScript puede ser un poco confuso a veces, pero en realidad sólo hay que seguir un par de reglas para saber a qué ámbito pertenece una variable.

En JavaScript las funciones tienen su propio ámbito léxico, lo que quiere decir que depende de cómo son declaradas en el código y no de cuando se ejecutan.
Sólo las funciones pueden crear un nuevo ámbito y como excepción, los bloques catch también crean su propio ámbito. Con la introducción de las variables let y const en ES6, también tenemos a nuestra disposición ámbito de bloque, ver más abajo para ver qué significa esto.

¿Cómo funciona este ámbito léxico de las funciones?

A la hora de decidir a qué ámbito pertenece una variable, el compilador de JavaScript comprueba si la variable está declarada dentro de la función donde se invoca (ámbito local de la función) si no es así, busca en el ámbito de la función que la contenga y así hasta llegar al ámbito global. Si la variable no fue declarada en ningún momento, el compilador la declara como variable global.
En 'Strict mode' el compilador no creará la nueva variable en ámbito global sino que devolverá un error por variable no declarada.

La mejor forma de ver cómo funcionan estas reglas es probándolas en directo:


//'use strict'; // descomentar para ver el error al usar la variable bye

var hi = 'Global: I am global. '
var ObjectWithPrivateVariables = function ObjectDefinition() {

  // Esta variable está definida dentro del ámbito de la functión ObjectDefinition
  var hi = 'Object: Hello. '
  //var bye; // descomentar para arreglar la fuga de la variable bye al ámbito global

  return {
    sayHi: function returnsAGreeting() {
      // El ámbito de esta función está dentro del ámbito de OnjectDefinition
      return hi
    },

    sayBye: function byes() {
      bye = "Good bye!"
      return bye
    }
  }
}

var newObject = new ObjectWithPrivateVariables()
var content = document.getElementById('content')
content.innerHTML += newObject.sayHi()
content.innerHTML += hi // Accede a la variable Global
content.innerHTML += newObject.sayBye()
content.innerHTML += bye // Esta variable se ha declarado como global y podemos acceder a ella, cuidado!!
content.innerHTML += sayHi // sayHi es undefined

Editar en jsfiddle

Es interesante jugar un poco con el script, mover las declaraciones de sitio y ver que pasa.

Ok, lo he pillado y ahora ¿Qué es eso del ámbito de bloque?

En ES6 se introdujeron los tipos de variable let y const que no funcionan como las variables var sino que tienen ámbito de bloque (block scope). Esto significa que estas variables existen dentro del bloque donde son declaradas, independientemente de si ese bloque es una función, una condición o un bucle. Además, las variables declaradas con let y const no se pueden utilizar antes de ser declaradas.

Esto es muy útil para declarar variables dentro de bucles o condiciones y que estas variables no se "filtren" al ámbito de la función. Siempre es más fácil explicarlo con un poco de código:


function countTo(n) {

  // console.log(i) // descomentar dará un error, i no está definida
  console.log(x) // undefined

  for(let i = 0; i < n ; i++) {
    console.log(i)
  }

  // console.log(i) // descomentar dará un error, i no está definida
  var x = 10
  console.log(x) // 10
}

countTo(5)

Editar en jsfiddle

Algo muy curioso de este pequeño código es el diferente resultado de los dos primeros console.log Las variables let y const no permiten ser usadas antes de ser declaradas, pero las variables declaradas con var sí. Esto es debido a una propiedad que se llama hoisting, que quiere decir que el compilador de JavaScript hace una primera pasada por todo el código para ver qué variables y funciones hemos definido y asignarles su ámbito. Hasta que la ejecución no llegue al punto de la asignación la variable tendrá el valor undefined. Esto no ocurre con let y const, que no son creadas hasta que la ejecución no llega al punto donde son declaradas. Así, si creamos una variable de bloque dentro de una condición que no se cumple, nunca se creará, y estaremos ahorrando ese tiempo y esa memoria.

Estas propiedades hacen que las variables let y const sean consideradas más fáciles de entender, que es lo importante, y actualmente las guías de estilo de código recomienden su uso sobre var. Si usas un linter, lo más seguro es que, si usas var, te lo marque como un warning o un error.

La diferencia entre let y const es que las variables const no se pueden reasignar, con lo que en el caso de valores escalares (cadenas, números y booleanos) son efectivamente constantes.


let x = 10
const y = 15
const pt = { x: 0, y: 10 }

x = 8 // ningún problema
// y = 8 // Error, 'y' no puede volver a asignarse por ser una constante

// pt = 'otracosa' // Error, pt no puede volver a asignarse

pt.x = 15 // sin problema, ahora pt.x vale 15 en lugar de 0

En el ejemplo de código puede verse que no ocurre así con los objetos, porque lo que no se puede modificar es la referencia que contiene esa variable, pero sí podremos modificar las propiedades internas del objeto, (a no ser que estén congeladas, pero de eso hablaremos otro día).