JuanPabloAJ Page

A lightweight way to make agents talk without paying for API usage

2026-04-16T00:00:00+00:00

For the past few weeks I have been testing a simple workflow for making coding agents interact with each other without using APIs, SDKs, or extra dependencies.

The main constraint is this: use the subscription plans you already have, avoid paying for API usage, and keep the setup simple enough that you can try it in a few minutes.

This became useful to me for two reasons:

I sometimes want to extend a Claude session by asking Codex or Gemini to review or continue part of the work.
I also want to delegate work and get different model perspectives on the same draft, spec, or implementation, instead of relying on a single vendor’s subagents.

This is not a polished framework. It is just a practical pattern that works well enough to test multi-agent workflows with very little setup.

To keep the examples simple, the rest of this post uses a draft as the running example, but the same pattern applies to specs, code changes, and review tasks.

The basic idea

Instead of integrating models through APIs, you let one agent invoke another through the CLI in a way that preserves the previous conversation.

For the non-interactive pattern, the key is to resume the previous session instead of starting a new one every time.

The commands the agent should use are:

codex exec resume --last "prompt"
gemini -r latest -p "prompt"

The important part is that the agent resumes the previous interaction so it can keep iterating on the same topic instead of starting from zero on every call. In the Codex example, --last tells the CLI to continue the most recent session instead of opening a new one.

I keep the conventions for this pattern in this Claude memory file:

external agent conventions

It contains the exact invocation rules and can be read and reused by other agents so they know how to keep the interaction going consistently.

That gives you a very lightweight loop:

One agent produces or reviews a draft.
That agent invokes another agent to critique it using resume mode.
The orchestrating agent reads the critique and decides the next step.
The agents keep iterating until the draft is good enough or the discussion stops adding value.

In practice, this lets you do things like:

ask Codex to review a draft produced in Claude
ask Gemini for an alternative reading of the same draft
use one agent as the writer and another as the reviewer
act as the human orchestrator, or delegate orchestration to one of the agents
avoid manually copy-pasting each interaction between agents

One reason to do this across vendors is to get a different perspective, not just another pass from the same model family.

At a high level, the non-interactive flow looks like this:

Claude writes a draft
-> Codex reviews it using resume mode
-> Claude revises the draft
-> Claude or Codex summarizes the disagreements
-> Repeat until the output is stable enough

This pattern is good when:

you want the smallest possible setup
you do not want extra dependencies
you care more about fast experimentation than about observability

Its biggest limitation is visibility. You can make agents talk, but it is not always easy to inspect the interaction history, monitor progress, or understand what happened at each step.

It is also worth paying attention to permissions, especially if one agent is invoking another autonomously.

The more visible pattern: tmux

If you want better visibility, tmux is the better option.

This version depends on having tmux installed, but in exchange you can see what each agent is doing in separate panes or sessions and capture their output more easily.

A few commands the agent can use in that workflow are:

# Create a dedicated tmux socket and start an isolated session
SOCKET="${TMPDIR:-/tmp}/claude-tmux-sockets/claude.sock"
mkdir -p "${TMPDIR:-/tmp}/claude-tmux-sockets"
tmux -S "$SOCKET" new -d -s "descriptive-name"

# Send a prompt literally, then submit it with Enter
tmux -S "$SOCKET" send-keys -t target -l -- "$cmd"
sleep 1
tmux -S "$SOCKET" send-keys -t target Enter

# Capture recent pane output without line wrapping artifacts
tmux -S "$SOCKET" capture-pane -p -J -t target -S -200

# Attach to the running session to monitor the agents directly
tmux -S "$SOCKET" attach -t session-name

I keep the conventions for this pattern in this Claude memory file:

tmux multi-agent patterns

It describes the socket, monitoring, and pane-management conventions, and other agents can read it as a reusable reference.

This pattern is better when:

you want to watch the interaction as it happens
you want to run two or more agents in parallel
you want easier debugging when the workflow becomes messy

The main caveat

I think there is real value in getting multiple perspectives from different models, but I am still not fully convinced that more agent-to-agent interaction always pays off.

LLMs are very good at producing plausible, well-written text. When they start talking to each other, they can produce a lot of it.

So the open question is not whether they can reach consensus. They can.

The harder question is whether the final result is actually better, or whether it is just a more polished hallucination produced after a longer chain of interactions.

That is why I currently see this as a useful workflow to test, not as a universal solution.

In summary

If you already use subscription-based coding agents, the simplest way I have found to make them collaborate without paying for API usage is:

use non-interactive calls with resume when you want simplicity
use tmux when you want visibility and tighter control

That is enough to build small multi-agent workflows across tools like Claude, Codex, and Gemini without much setup.

From Agentic Reasoning to Deterministic Scripts

2026-03-08T00:00:00+00:00

TL;DR

AI agents shouldn’t solve the same task over and over. Their execution history could be used to detect recurring patterns and compile them into deterministic scripts.

The purpose of AI agents is not to execute tasks indefinitely, but to discover the procedures that replace them.

The Overhead of Routine Tasks

AI agents like Claude, Codex, OpenClaw, or any of their derivatives are remarkably capable tools. They can explore a repository, diagnose a bug, write tests, execute commands, and produce results that previously required hours of human work. All of this is possible because every task goes through an LLM: the agent receives an instruction, reasons about it, chooses tools, executes them, observes the result, and repeats.

That loop is flexible and powerful. It is also inherently expensive: each step consumes tokens, introduces latency, and produces outputs that can vary between runs. For routine tasks- cleaning a build directory, updating dependencies according to a known policy, generating a report with a fixed format- this level of reasoning is overkill. The agent is “thinking from scratch” every single time.

The problem isn’t that agents are bad. The problem is that we are using our most powerful- and most expensive- instrument for everything, indiscriminately.

A developer before automating

There is a pattern any developer will recognize. Before writing a script:

You perform the task manually, paying attention, understanding each step and its edge cases.
You iterate, fix errors, and refine the process.
You identify the routine part: the steps that repeat without meaningful variation.
You automate that part, and reserve human judgment for the edge cases.

This pattern appears in other contexts outside programming- the way a process matures from deliberate effort to fluid execution. What I want to propose here is whether AI agents could follow a similar trajectory.

A task maturation cycle

What I propose is an idea of how the lifecycle of a task could be structured within an agentic system:

Phase 1 - Deliberative Execution: The agent receives a new or ambiguous request. It solves it using full LLM reasoning. Unlike a script, the agent doesn’t just execute steps: it reasons about them. The log it produces can be qualitatively richer than a standard structured log- it can include the explicit reasoning behind each decision, the tools considered and discarded, the observed conditions, and the ambiguities it resolved. That richness is not a byproduct; it is the most valuable raw material for the subsequent phases.

Phase 2 - History Analysis: A separate process analyzes the repository of logs or traces of tasks performed by agents. It looks for tasks that repeat with high similarity: same steps, same context, same expected outcome. It identifies stable execution patterns. This analysis- especially for detecting semantic equivalence between tasks described in different ways- might require an LLM. The irony is intentional: we invest LLM reasoning now to reduce LLM reasoning in the future. The hypothesis is that this cost, when run in batch and periodically, would amortize if the number of executions routed to the resulting script is high enough- something that depends on the volume of repetitive tasks in each specific context.

Phase 3 - Automation Generation: When a task crosses a certain threshold of recurrence and stability, the system can propose- or directly generate- a deterministic script that replaces the LLM loop for that specific case.

Phase 4 - Smart Routing: When a new request comes in, the system first evaluates if there is a validated automation that covers it. If so, it executes the script. If not, it falls back to the deliberative agent.

If the cycle works as proposed, over time the proportion of tasks requiring LLM reasoning would decrease. The system would trend toward being faster, cheaper, and more predictable, without losing the ability to handle the novel. The cost of the analysis in Phase 2 is the price of that improvement- not a contradiction to the argument, but a necessary part of it.

Beyond cost

The reduction in token costs is the most obvious benefit, but not the most important one.

Auditability: A deterministic script has verifiable behavior. You can read it, test it, and do code reviews on it. An LLM reasoning loop produces results that are hard to audit systematically.
Operational Reliability: In production environments, variability is a risk. For known tasks, determinism is not a limitation: it is an advantage.
Energy Footprint: Every call to an LLM has an energy cost. Replacing recurring calls with scripts that run locally or on lightweight infrastructure could reduce that footprint.
Response Speed: A script runs in milliseconds. An LLM reasoning loop can take seconds or minutes depending on the complexity and the model’s latency.

grep is not enough

Detecting recurrence in text logs is relatively simple with tools like grep or ripgrep. But that only works for exact or near- exact matches. The interesting problem here is semantic similarity: two tasks might be described with different words, executed in slightly different contexts, and yet be functionally equivalent.

Reliably identifying that equivalence requires more than textual search: it requires a semantic indexing layer over the execution history. That is a non- trivial technical problem, and I am deliberately leaving it out of scope for this post. It is, in itself, the most interesting component of the proposed system, and deserves separate treatment.

Tools like LlamaIndex or PageIndex seem to be interesting alternatives to explore for what is described in Phase 2.

What this is not

To avoid misunderstandings:

This is not an agent that “learns” in the sense of retraining. I am not talking about fine- tuning or updating weights. The learning here is purely behavioral: the system observes what works and codifies it as a procedure.
This is not about replacing LLM agents. Deliberative agents remain necessary for everything new, ambiguous, or exceptional. The proposal is complementary, not a substitute.

Conclusion

Current AI agents are deliberative tools that solve almost everything through reasoning. That is powerful, but it might not be the desirable end state. A more mature system could recognize when a task no longer requires reasoning, and execute it more directly.

The path forward isn’t just building better models for routine tasks. It is building the infrastructure that allows LLM reasoning to be the starting point, not the permanent destination.

The logs that agents already produce today are the raw material for this. The question is whether someone will build the pipeline that converts them into automations.

A brief note on sources: This text is the sum of several influences worth naming: the emergence and popularization of OpenClaw and its derivatives; the economic and energetic cost of tokens; the ideas from Kahneman’s Thinking, Fast and Slow regarding deliberative and automatic processing modes; the way a developer builds automations by iterating manually first; the moment when a repeated request to an agent starts sounding exactly like a bash script.

The structure of this text was reorganized with the help of LLMs.

The silent filter

2026-02-27T00:00:00+00:00

“We have arranged a society based on science and technology in which nobody understands anything about science and technology. And this combustible mixture of ignorance and power, sooner or later, is going to blow up in our faces.” - Carl Sagan, 1994.

Sagan’s prophecy did not come true, at least not in the cinematic way we imagined. There was no explosion. The warning has circulated for decades as background noise, just uncomfortable enough to ignore, and familiar enough to no longer be frightening. The mistake was taking the word “explosion” literally.

What I propose in this text is that the real danger takes a quieter, more probable, and much harder-to-detect form: a process of cognitive erosion.

The Great Filter might not be an event

In 1998, Robin Hanson proposed the concept of the Great Filter to explain the Fermi Paradox: if the universe is vast and ancient, where are the advanced civilizations? The usual answer imagines a catastrophic event: nuclear war, pandemics, asteroids, or an artificial intelligence deciding that humans are a problem. Something identifiable with a date on a calendar.

But in my view, a filter does not need to be an event. It can be a condition of stagnation. A species that gradually loses the ability to understand, maintain, and extend the technology it depends on does not necessarily collapse; it simply becomes incapable of going any further. It does not disappear through an explosion, but through an accumulated incapacity.

This is what I call a Silent Filter. It is not a sudden extinction; it is an obsolescence programmed by our own pursuit of efficiency.

The Trap of the Shortcut

Describing this mechanism does not require assuming the worst of human nature. it requires assuming something much more mundane: that given access to two paths toward the same result, most of us will take the shorter one. This is not a moral critique; it is a description. The problem arises when the shorter path eliminates the very mechanism of learning.

“An expert is a person who has made all the mistakes that can be made in a very narrow field.” — Niels Bohr.

Knowledge is not only built on successes but on the accumulation and assimilation of errors. Not observed errors, not delegated errors: errors committed, understood, and overcome. Without that process, what you get is familiarity, not comprehension. And familiarity only allows you to use what you inherited, not to improve or extend it.

A similar thing happens with creativity. “Inspiration exists, but it has to find you working,” a phrase often attributed to Picasso. Regardless of who said it, anyone who has practiced a discipline, artistic, athletic, or scientific, recognizes it as true. It defines the creative process. Ideas do not appear in a vacuum. They appear in the middle of the process, between one failed attempt and the next. Iterating to understand, understanding to assimilate, assimilating to expand. Without that iteration, the creative cycle becomes sterile.

This is, ultimately, the same observation Bohr made from a different angle. Errors and iteration are not the price paid for learning. They are the mechanism by which learning occurs.

The thread connecting these two ideas is this: the understanding of any system requires having built it, at least partially. A species that systematically delegates this process does not just become dependent: it becomes incapable of replicating what its predecessors achieved. And that incapacity, unlike common ignorance, is invisible from the inside.

The Delegation of Synthesis and Linguistic Drift

Artificial Intelligence is not the first system that allows us to delegate comprehension. The calculator allowed us to delegate arithmetic. GPS allowed us to delegate navigation. Internet search allowed us to delegate memory. But current AI absorbs something structurally different: the process of synthesis and reasoning.

Without debating what “thinking” or “intelligence” means, it is undeniable that AI performs processes in a way that is fluid and useful enough that delegation is often the rational decision. Faster, less effort, comparable or better results. The shortest path, available to everyone, all the time.

The problem is not that AI solves problems. The problem is that every solution accepted without understanding the reasoning behind it is an iteration that did not happen and a mistake that was not made. Individually, this is irrelevant. On a global scale and over generations, this is the exact mechanism of the Silent Filter.

One could argue that this doesn’t matter much: knowledge does not disappear; it is simply stored in systems that can retrieve it when necessary.

But there is a distinction worth considering. Accessing a solution is not the same as understanding the reasoning that produced it. And supervising a system is not the same as being able to correct or improve it. As AI systems become more complex and interact with each other, the reasoning behind their decisions is not just difficult to follow due to volume or speed: it may become structurally different from how humans reason.

Noam Chomsky proposed that all human languages share a common underlying architecture. Regardless of the absolute certainty of that claim, it leads to a simpler observation: all human languages emerged in humans, and therefore reflect the way humans process and communicate ideas. A communication system that emerges between agents with different objectives has no reason to respect that architecture. To us, rather than a difficult language to learn, it could become structurally unintelligible.

A species that cannot follow the reasoning of its own systems does not supervise them; it simply inhabits them until they stop working.

A Likely Obvious Confession

This text, its structure and parts of its refinement, has been organized with the help of artificial intelligence. No one is outside this phenomenon. The Silent Filter does not require villains; it only requires rational individual decisions that accumulate in a direction no one quite chose.

I don’t have a solution. I suspect one that is compatible with our nature does not exist. Perhaps the first step to avoiding a filter is being able to see it.

The noise circuit breaker

2026-02-26T00:00:00+00:00

An attempt to audit AI agreeability

Most AI interactions are governed by a hidden bias: agreeability. These models are designed to be helpful and polite, which often turns them into a digital mirror that simply reflects your own ideas back to you with a professional polish. This creates a feedback loop where you feel productive, but you are actually just spinning in circles.

Why use this prompt?

The prompt below is an attempt to force the AI out of its default “helpful assistant” mode. By demanding a technical report on the conversation itself, you push the model to analyze the interaction from the outside. It’s a tool to help you spot when a conversation has stopped being useful and has started becoming an echo chamber.

Perform a technical analysis of this chat session so far. Act as a neutral observer of natural language processing and deliver a structured report based on the following criteria:

Signal-to-Noise Ratio (SNR): Evaluate whether the conversation is converging toward a resolution or drifting into redundancy.

Entropy Level: Determine if the introduction of new concepts is constant or if the dialogue has entered a low-information transfer cycle.

Density and Register: Classify the complexity of the exchange (technical, operational, speculative) and the precision of the vocabulary used.

Inference of Intent and State: Based on rhythm, syntax, and topics, infer the user’s underlying objective and current disposition (skepticism, pragmatism, intellectual rumination, etc.).

Archetype Mapping: Identify the user profile emerging from the inputs (e.g., analytical-critical, execution-oriented).

Conclude with a 'Conversation Performance' metric: Is there still an information gain, or are we facing diminishing returns? Suggest a path to recover technical utility if necessary.

When to use it

When you feel stuck: If you’ve been chatting for a while and haven’t made a concrete decision or produced anything tangible.
When you suspect “playing along”: Especially useful during speculative or philosophical discussions where the AI might just be matching your tone instead of providing real friction.
As an exit signal: If the report shows “diminishing returns,” it’s a clear sign to close the tab and return to the physical world or raw work.

Do you have any other prompts that help you break out of the agreeability loop?

Life as an Accelerator of Chaos

2025-10-06T00:00:00+00:00

A few years ago, in Nick Lane’s book, The Vital Question: Why Is Life the Way It Is?, I read a sentence that went something like this: “Consider the stars. They pay for their ordered existence by emitting enormous amounts of energy into the universe.”

Every now and then, I come back to that idea, and it pushes me to think further. In this post, I’ll try to summarize and organize the thoughts that stemmed from it. I don’t have a scientific background to back up what I’m saying with equations or academic papers; this is simply an extension of that phrase I once read, an exercise in reasoning.

The reasoning in 5 steps

1. Basic principle: entropy tends to increase

The second law of thermodynamics states that in a closed system, total entropy (the degree of disorder) tends to increase. This isn’t a “force” but a statistical tendency: states of greater disorder are simply more numerous and, therefore, more probable.

2. The fastest paths to entropy are the most probable

If a system can evolve along different paths, it will tend to follow those that lead it most quickly to a state of greater entropy. Sometimes, the most efficient route to global disorder involves creating intermediate ordered structures.

3. Ordered structures as efficient shortcuts to greater entropy

Examples like hurricanes or stars themselves show that highly organized systems can emerge as transient forms that channel energy into their surroundings in an incredibly effective way. They don’t contradict the second law; instead, they serve it more efficiently.

4. Life as an ordered structure that accelerates entropy

Living beings are an extreme example of internal order. To maintain it, we consume energy from our environment (sun, food) and release heat and waste. In practice, we are highly efficient channels for transforming concentrated energy into more dispersed forms, accelerating the increase of global entropy.

5. Hypothesis: Life as a consequence of accelerating entropy

This is where it all comes together. If the states of greatest entropy are the most probable (Point 1), and there are paths that accelerate the arrival to that state (Point 2), then those paths will be statistically favored. Since life is one of these efficient routes (Point 4), its emergence ceases to be an improbable accident and becomes a logical consequence: one of the most probable trajectories that matter can follow under certain conditions.

Conclusion

After organizing these ideas, I asked the AI Gemini if similar concepts existed. The answer was yes, and it mentioned two main fields: Dissipative Structures (Ilya Prigogine) and Dissipation-Driven Adaptation (Jeremy England). Perhaps I’ll research them and their work a bit and continue writing about this topic. Just perhaps.

Note: Much of the wording in this text was revised and polished with the help of Google’s Gemini to ensure clarity.

Context, Hallucinations, and How LLMs Are Changing Development

2025-09-09T00:00:00+00:00

Taking advantage of this recent OpenAI post on hallucinations:

https://openai.com/index/why-language-models-hallucinate/

I will summarize my experience from the last six months using LLMs intensively in a development context. By “intensively,” I mean all day, multiple times a day, comparing different LLMs, and so on.

I will focus on two key concepts when working with LLMs: context and hallucinations, and how they change the way we work in development.

Most of what I share here is based on my own opinions and lessons learned during this period.

Context size matters

In my view, the turning point for LLMs came in late March, when Gemini 2.5 Pro was released for free with a context size of 1M tokens. For the first time, you could feed a large portion of an entire project to an LLM—not just fragments or chunks. When the model has access to the full project, it can better infer overall behavior. Previously, the only option was to provide smaller parts to avoid filling the context, which forces the model into assumptions—and eventually, hallucinations. This leads to the second point.

Trust no LLM completely

Right now, you cannot fully trust what an LLM produces. There’s no guaranteed way to know whether its responses are accurate or to what degree they are true. Ignoring this is a critical mistake. You need independent methods to validate responses, and those methods should not be built by the LLM itself—at least not by the same instance.

Change in the development process

In software development, the TDD (Test-Driven Development) methodology is well known. It starts with defining validations—what you expect to get—and writing the tests. This forces the developer to clearly understand the requirements, because only someone with that clarity can define a validation scenario in words and translate it into an automated test.

The flow is:

Write a test → The test fails → Modify the code → The test passes → Iterate.

Earlier, I mentioned hallucinations. One way to reduce and catch them—adapting the TDD approach—is as follows (without going too deep into details):

Be clear about what you need and precise in the description you give to the LLM, including scenario definitions. This requires human time and focus.
Provide the information to the LLM and ask it to restate in its own words what you asked for, adding examples. Then you can verify, based on those examples, that you are aligned.
Have or build ways to validate the LLM’s output; this is the only way to detect hallucinations. In particular, use the scenarios defined in the first step.

Leveraging LLMs with larger context windows is also important, as they rely less on assumptions and can use other parts of the project as reference.

In summary

Yes, LLMs change and accelerate the way we work, but at this point, they are still like an assistant that needs a detailed and precise definition of what is expected, plus well-defined validation criteria for the results. Both require time and effort.

In my opinion, how seriously you take this last point will determine how reliable your solution will be. There are no magic solutions.

Fail-Fast Testing of Goroutines with WaitGroup and time.After

2025-04-25T00:00:00+00:00

TL;DR

Unit-testing async code in Go? Drop in a mock that just closes a sync.WaitGroup, then wrap the wait in a select with time.After. If the goroutine never returns, the test fails quickly instead of hanging your CI.

Your function fires a goroutine — maybe it pushes to Kafka or hits an API. In a test you don’t care about the payload; you care that the goroutine actually ran. And if it deadlocks, you want to know fast.

package main

import (
    "sync"
    "testing"
    "time"
)

type Actor interface {
    Perform()
}

func Cinema(a Actor) {
    go a.Perform()
}

type mockActor struct{ wg *sync.WaitGroup }

func (m mockActor) Perform() {
    m.wg.Done()
}

func TestCinema(t *testing.T) {
    var wg sync.WaitGroup
    wg.Add(1)

    Cinema(mockActor{wg: &wg})

    done := make(chan struct{})
    go func() {
        defer close(done)
        wg.Wait()
    }()

    select {
    case <-done:
    case <-time.After(500 * time.Millisecond):
        t.Fatalf("timeout: Perform did not finish in 500 ms")
    }
}

What’s happening

Bump the WaitGroup, call the code under test.

The mock fires inside the goroutine and calls wg.Done()—proof the path was hit.

A helper goroutine converts wg.Wait() into a channel you can watch in a select.

If the deadline expires first, the test explodes instead of blocking your pipeline.

For quick unit tests, this WaitGroup-plus-timeout trick hits the sweet spot.

Distributing Elixir applications with Burrito

2023-08-20T00:00:00+00:00

In this post, I will demonstrate how to use Burrito to create a self-extracting archive for an Elixir project, to use it across varied environments (Windows, MacOS, or Linux). This post is a small complement to the previous post Elixir and Ecto with SQLite3, which was about how to use SQLite3 with Elixir and Ecto.

This test was made in a clean Debian virtual machine (aarch64), the objective is to create a binary for use in Ubuntu (x86_64) where Erlang and Elixir are not available and I don’t have root permissions.

Burrito’s dependencies include XZ, 7zip, and Zig (version 0.10.0). You can install XZ and 7zip with the package manager. Since Zig wasn’t available in the package manager, you can obtain it from the Zig’s Getting Started page, there, you’ll find instructions on how to install it. Simply download the tar file, uncompress it, and you’ll have Zig’s binary available for use. Please note that, Burrito is compatible with Zig version 0.10.0. During my initial tests, I downloaded the latest version of Zig, but found that Burrito wasn’t compatible with it.

You can read more about Burrito in its repository.

I took the code from the previous post, I added Burrito to the dependencies

# mix.exs
defp deps do
[
    {:burrito, github: "burrito-elixir/burrito"}
]
end

From Burrito’s documentation, I copied this function

# mix.exs
def releases do
[
  data_collector: [
    steps: [:assemble, &Burrito.wrap/1],
    burrito: [
      targets: [
        linux: [os: :linux, cpu: :x86_64]
      ]
    ]
  ]
]
end

In mix.exs, I added this line to the project function

# mix.exs
def project do
[
  ...
  releases: releases()
]
end

These are all the modifications related to Burrito. However, in my scenario, I needed to migrate the database before starting the application. In the previous post, I had done the migrations manually as a release command

$ DATABASE_PATH=/tmp/data_collector_prod.db _build/prod/rel/data_collector/bin/data_collector eval "DataCollector.Release.migrate"

In this case, I preferred to call the migrations automatically, so I called the migration function before starting the Supervisor (I am not sure if it is the best way to call the migrations automatically at the beginning).

#lib/data_collector/application.ex
@impl true
def start(_type, _args) do
    DataCollector.Release.migrate()

    children = [
    ...

I called Burrito with the release command

$ MIX_ENV=prod mix release

Burrito created the directory burrito_out with the binary called data_collector_linux inside

$ ls burrito_out/
data_collector_linux

Using ssh, I moved the binary to the other machine with Ubuntu. There, I executed the binary, the migrations were applied, and the application started.

$ DATABASE_PATH=/tmp/data_collector_prod.db ./data_collector_linux
50:55.830 [info] == Running 20230819231423 DataCollector.Repo.Migrations.CreateInstruments.change/0 forward
50:55.839 [info] create table instruments
50:55.844 [info] == Migrated 20230819231423 in 0.0s

After a few seconds, the database had values

$ sqlite3 /tmp/data_collector_prod.db
SQLite version 3.39.3 2022-09-05 11:02:23
sqlite> select * from instruments;
1|instrument_374|7|2023-08-21T00:50:56|2023-08-21T00:50:56

As a side note, while writing this post, I recalled a somewhat related article I wrote in Spanish 9 years ago on how to create a self-contained Python executable. How time flies!

I hope you find this post useful. If you have any suggestions or feedback on the post, please feel free to reach out to me.

References

Elixir and Ecto with SQLite3

2023-08-19T00:00:00+00:00

There have been instances where I required data persistence with an Elixir application although I don’t want to start a PostgreSQL instance. For small applications or tasks, SQLite3 sounds like a good alternative, especially if you are running the app on a small machine.

In this post, I’m going to show how to use Elixir and Ecto with SQLite3. This is strongly based on an article from fly.io although that article is oriented to Phoenix, I’m going to focus on creating a small Elixir project. The project will have a GenServer that writes a random value every second into the SQLite database.

I will be using Elixir version 1.15.2 and Erlang version 26.0.2.

First, create the project’s directory with a supervisor.

$ mix new data_collector --sup

Add ecto_sqlite3 to mix.exs, you can find more details in its documentation.

   defp deps do
 [
  {:ecto_sqlite3, "~> 0.10"}
    ...
 ]

Fetch the dependencies

$ mix deps.get

Create a lib/data_collector/ecto.ex with

defmodule DataCollector.Repo do
    use Ecto.Repo, otp_app: :data_collector, adapter: Ecto.Adapters.SQLite3
end

Create a config/config.exs with

import Config

config :data_collector,
  ecto_repos: [DataCollector.Repo]

config :data_collector, DataCollector.Repo,
  database: Path.expand("../data_collector_#{Mix.env()}.db", Path.dirname(__ENV__.file)),
  pool_size: 5

Create a schema lib/data_collector/instrument.ex

defmodule DataCollector.Instrument do
  use Ecto.Schema
  import Ecto.Changeset

  schema "instruments" do
    field(:name, :string)
    field(:measurement, :integer)

    timestamps()
  end

  def changeset(instrument, params \\ %{}) do
    instrument
    |> cast(params, [:name, :measurement])
    |> validate_required([:name, :measurement])
  end
end

And a migration

$ mix ecto.gen.migration create_instruments

# priv/repo/migrations/2023MMDD_create_instruments.exs
defmodule DataCollector.Repo.Migrations.CreateInstruments do
  use Ecto.Migration

  def change do
    create table(:instruments) do
      add(:name, :string)
      add(:measurement, :integer)

      timestamps()
    end
  end
end

Create the database and apply the migrations

$ mix ecto.create
$ mix ecto.migrate

After that, you should see a file called data_collector_dev.db, If you open it with sqlite3, you should see the table instruments

$ sqlite3 data_collector_dev.db
sqlite> .tables
instruments         schema_migrations
sqlite> .schema instruments
CREATE TABLE IF NOT EXISTS "instruments" ("id" INTEGER PRIMARY KEY AUTOINCREMENT, "name" TEXT, "measurement" INTEGER, "inserted_at" TEXT NOT NULL, "updated_at" TEXT NOT NULL);

Create a GenServer to insert data every second into the database

# lib/data_collector/worker.ex
defmodule DataCollector.Worker do
  use GenServer

  alias DataCollector.{Instrument, Repo}

  def start_link(_opts) do
    GenServer.start_link(__MODULE__, nil, name: __MODULE__)
  end

  def init(_opts) do
    Process.send_after(self(), :work, 1000)
    {:ok, nil}
  end

  def handle_info(:work, state) do
    data = %{
      name: "instrument_#{Enum.random(1..1000)}",
      measurement: Enum.random(1..100)
    }

    %Instrument{}
    |> Instrument.changeset(data)
    |> Repo.insert()

    Process.send_after(self(), :work, 1000)
    {:noreply, state}
  end
end

Add Repo and GenServer to lib/data_collector/application.ex

children = [
  {DataCollector.Repo, []},
  DataCollector.Worker
]

Start the processes, in the logs you should see the inserts into the database

$ mix run --no-halt

If you check the database, you should see the values inserted by the GenServer.

$ sqlite3 data_collector_dev.db
sqlite> select * from instruments limit 2;
1|instrument_547|30|2023-08-19T23:43:07|2023-08-19T23:43:07
2|instrument_334|86|2023-08-19T23:43:08|2023-08-19T23:43:08

At this point, the tutorial could be complete although I will add how to create the release, if you are not interested in how to create a release you can stop here.

Now, let’s modify the content of config/config.exs to the following.

# config/config.exs
import Config

# Configures Elixir's Logger
config :logger, :console,
  format: "$time $metadata[$level] $message\n",
  metadata: [:request_id]

config :data_collector,
  ecto_repos: [DataCollector.Repo]

import_config "#{config_env()}.exs"

And add these three new config files:

# config/dev.exs
import Config

config :data_collector, DataCollector.Repo,
  database: Path.expand("../data_collector_dev.db", Path.dirname(__ENV__.file)),
  pool_size: 5


# config/prod.exs
import Config

# Do not print debug messages in production
config :logger, level: :info


# config/runtime.exs
import Config

if config_env() == :prod do
  database_path =
    System.get_env("DATABASE_PATH") ||
      raise """
      DATABASE_PATH environment variable is missing.
      For example: /data/name/name.db
      """

  config :data_collector, DataCollector.Repo,
    database: database_path,
    pool_size: String.to_integer(System.get_env("POOL_SIZE") || "10")
end

Create a release file lib/data_collector/release.ex with functions related to the migration, you can find more details in this fly.io post.

defmodule DataCollector.Release do
  @app :data_collector

  def migrate do
    for repo <- repos() do
      {:ok, _, _} =
        Ecto.Migrator.with_repo(
          repo,
          &Ecto.Migrator.run(&1, :up, all: true)
        )
    end
  end

  def rollback(repo, version) do
    {:ok, _, _} =
      Ecto.Migrator.with_repo(
        repo,
        &Ecto.Migrator.run(&1, :down, to: version)
      )
  end

  defp repos do
    Application.load(@app)
    Application.fetch_env!(@app, :ecto_repos)
  end
end

Now you can create the release, apply the migration over it, and start it.

$ MIX_ENV=prod mix release
$ DATABASE_PATH=/tmp/data_collector_prod.db _build/prod/rel/data_collector/bin/data_collector eval "DataCollector.Release.migrate"

$ DATABASE_PATH=/tmp/data_collector_prod.db _build/prod/rel/data_collector/bin/data_collector start

If you check the release’s database, you should see the values inserted by the GenServer.

$ sqlite3 /tmp/data_collector_prod.db
sqlite> select * from instruments limit 1;
1|instrument_751|90|2023-08-20T00:58:26|2023-08-20T00:58:26

That concludes the tutorial.

I hope this post can be useful for you. If you have any suggestions or feedback on the post, please feel free to reach out to me.

References

Distribuir variables con consul/envconsul

2019-02-01T00:00:00+00:00

El siguiente ejemplo pretende mostrar como almacenar variables en consul y mediates envconsul utilizarlas como variables de ambiente en un servicio. Se realizará utilizando contenedores docker, el código fuente se encuentra disponible en el repositorio envconsul with a service.

Levantar consul, usando el docker-compose de este enlace y el comando

docker-compose up -d

Crear una variable llamada max_conns de valor 10 y prefijo hello-app

docker-compose exec consul-server-bootstrap consul kv put hello-app/max_conns 10

Levantar el servicio con el docker-compose del siguiente enlace

docker-compose -f docker-compose-services.yaml build
docker-compose -f docker-compose-services.yaml up -d

El servicio está desarrollado con python/flask, cada vez que recibe una consulta retorna el valor de la variable de entorno max_conns.

# -*- coding: utf-8 -*-
import os
from flask import Flask
from flask import jsonify
app = Flask(__name__)

@app.route("/")
def hello():
    return jsonify(value=os.environ['max_conns'])

if __name__ == '__main__':
   app.run(host='0.0.0.0')

El servicio se ejecuta en un contener docker, es iniciado y mantenido en ejecución por envconsul, el cual obtiene las variables desde consul y las disponibiliza como variables de entorno. Si una variable es actualizada, envconsul reinicia el servicio.

CMD envconsul \
    -consul-addr "consul-server-bootstrap:8500" \
    -prefix hello-app \
    python hello.py

Consultar al servicio

curl localhost:5000

Para obtener el valor definido anteriormente

{"value":"10"}

Actualizar el valor de la variable

docker-compose exec consul-server-bootstrap consul kv put hello-app/max_conns 20

Volvemos a invocar el servicio

curl localhost:5000

Finalmente obtenemos el último valor asignado a la variable

{"value":"20"}

Referencias

envconsul with a service
https://github.com/hashicorp/envconsul

Phoenix, cambiando nivel de log de una aplicación en ejecución

2018-11-03T00:00:00+00:00

Para cambiar el nivel de log sin reiniciar la aplicación.

Iniciar Phoenix con elixir y agregar el argumento sname

elixir --sname myapp -S mix phx.server

Conectar a Phoenix with a terminal remota remsh

iex --sname baz --remsh myapp@${HOSTNAME}

Cambiar el nivel del log de Logger y del backend

iex(myapp@ecb1011caa1e)6> Logger.configure(level: :debug)
:ok
iex(myapp@ecb1011caa1e)5> Logger.configure_backend(:console, [level: :debug])
:ok

Desde ahora el nivel de log está en debug

15:21:07.521 [debug]...

References

https://christopherjmcclellan.wordpress.com/2018/06/02/how-to-change-elixir-log-levels-for-a-running-application/
https://hexdocs.pm/iex/IEx.html
https://hexdocs.pm/logger/Logger.html

Usando el git hook commit-msg con las id de issue

2018-10-30T00:00:00+00:00

Hace algún tiempo escribí un post sobre los hook de git y su utilidad para automatizar tareas, hoy quiero mostrar un ejemplo que he estado usando los últimos días, el hook commit-msg para no olvidar agregar el id de issue en los commits.

Si utilizas github/gitlab y su sistema de issues, es una buena práctica asociar los commits a issues.

Si eres como yo probablemente muchas veces has olvidado agregar el id del issue en el commit, bueno para eso puedes usar el hook commit-msg, el cual se activa después que el mensaje de commit es generado y antes que el commit es agregado. (más detalles en Customizing Git - Git Hooks), con algo como esto

#!/bin/bash

MSG="$1"

if ! egrep -qE "#[0-9]+" "$MSG";then
    cat "$MSG"
    echo "Your commit message must contain some issue reference '#...'"
    exit 1
fi

https://gist.github.com/juanpabloaj/fe7b8203ed967488d22c004c13846cfa

Y cuando no quieras que el hook sea activado usa la opción

git commit --no-verify

Algunas ventajas de agregar los id en cada commit son cosas como: cuando vayas a crear un nuevo tag puedes saber cuantas issues agregaste desde el último tag (donde 1.0.1 representa el último tag creado), y revisar en github/gitlab el detalle de los issues.

git log --oneline 1.0.1..HEAD | grep \# | sed 's/.*\(\#[0-9]*\).*/\1/' | sort | uniq -c

Phoenix y Plug.RequestId

2018-10-18T00:00:00+00:00

Para que cada request tenga un id único y sea mostrado en el log

Crear proyecto
```
 mix phx.new  --no-ecto request
```
Agregar al archivo lib/request_web/endpoint.ex
```
 plug Plug.RequestId
```

Editar el archivo config/dev.exs para mostrar el id del request en el log

 config :logger, :console,
   format: "[$level] $metadata$message\n",
   metadata: [:request_id]

Con esto, por cada request se debería obtener una linea de log similar a

[info] request_id=2lfdtb54lt7i3bdppk0000fh GET /

Si en el request se envía el header x-request-id con un valor entre 20 y 200 caracteres, este se mantiene.

Con

curl -H "x-request-id: 12345678901234567890" http://localhost:4000

Se registra en el log

[info] request_id=12345678901234567890 GET /

Más información en

https://hexdocs.pm/plug/Plug.RequestId.html

Compilando gcc/g++ sin permiso root

2016-11-16T00:00:00+00:00

En un servidor necesitaba una versión de g++ más actual y no tenía permisos de root, por lo que tuve que compilar el compilador manualmente. En este post voy a describir los pasos que realicé.

Si bien lo que me interesa es instalar g++, en lo que sigue voy a hablar de gcc ya que ese es el nombre del paquete que voy a instalar.

Primero instalar zlib, una de las dependencias de gcc.

Descargar, compilar e instalar zlib

wget https://github.com/madler/zlib/archive/v1.2.7.tar.gz
mv v1.2.7 zlib-1.2.7.tar.gz
tar xvfz zlib-1.2.7.tar.gz
cd zlib-1.2.7
./configure --prefix=$HOME/opt
make
make install

Agregar la ubicación de zlib a LD_LIBRARY_PATH in ~/.bashrc.

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/opt/lib
export LD_LIBRARY_PATH

Recargar ~/.bashrc

source ~/.bashrc

Ahora gcc, descargar gsrc, código fuente de varios paquetes gnu

wget http://ftp.gnu.org/gnu/gsrc/gsrc-2014.10.11.tar.gz

Seguir las instrucciones del sitio de gsrc

cd gsrc
./bootstrap
./configure --prefix=$HOME/gnu

Compilar lo gcc/g++

make -C gnu/gcc
make -C gnu/gcc install

Agregar la ubicación de gcc al PATH y de librerías a LD_LIBRARY_PATH

PATH=$HOME/gnu/bin:$PATH
LD_LIBRARY_PATH=$HOME/gnu/lib:$HOME/gnu/lib64:$HOME/opt/lib:$LD_LIBRARY_PATH

export PATH
export LD_LIBRARY_PATH

Recargar ~/.bashrc

source ~/.bashrc

Con los pasos anteriores debería estar disponible para utilizar g++.

Referencias

gsrc
zlib

Python y algunos métodos especiales de clase

2016-08-06T00:00:00+00:00

Este post es para las personas que están comenzando a utilizar clases en python, es un poco más que lo básico, voy a mostrar algunos ejemplos de métodos especiales de clase como __str__ y __call__. Los ejemplos están probados con python 3.5.

str

Primero creemos una clase Animal

class Animal:
    def __init__(self, nombre):
        self.nombre = nombre

Y un objeto de la clase Animal llamado perro

>>> perro = Animal('bobby')

Para mostrar el contenido del atributo nombre, es necesario llamarlo directamente

>>> print(perro.nombre)
bobby

Si usamos print sobre el objeto veríamos algo como

>>> print(perro)
<__main__.Animal object at 0x1053fab38>

Cambiemos el mensaje que muestra el objeto al usar print, agregando el método __str__ a la clase

class Animal:
    def __init__(self, nombre):
        self.nombre = nombre
    def __str__(self):
        return nombre

Ahora al usar print

>>> perro = Animal('bobby')
>>> print(perro)
bobby

call

Para interactuar con un objeto podemos crear métodos, por ejemplo, uno llamado hablar

class Animal:
    def __init__(self, nombre):
        self.nombre = nombre
    def __str__(self):
        return nombre
    def hablar(self, mensaje):
        return 'Hola, mi nombre es {}, {}'.format(self.nombre, mensaje)

Ahora puedo llamar el método hablar

>>> perro = Animal('bobby')

>>> perro.hablar('mucho gusto!')
'Hola, mi nombre es bobby, mucho gusto!'

Pero si intento llamar directamente al objeto (notar los “()” después del nombre del objeto)

>>> print(perro())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  TypeError: 'Animal' object is not callable
  'Animal' object is not callable

Obtengo ese mensaje, no puedo llamar directamente al objeto de la clase Animal, para esto es necesario agregar el método __call__

class Animal:
    def __init__(self, nombre):
        self.nombre = nombre
        self.llamados = 0
    def __str__(self):
        return nombre
    def hablar(self, mensaje):
        return 'Hola, mi nombre es {}, {}'.format(self.nombre, mensaje)
    def __call__(self):
        self.llamados +=1
        return self.hablar('he sido llamado {} veces.'.format(self.llamados))

Con esto cada vez el que objeto sea llamado retornará un mensaje e incrementará un atributo.

>>> perro = Animal('bobby')

>>> print(perro())
Hola, mi nombre es bobby, he sido llamado 1 veces.

>>> print(perro())
Hola, mi nombre es bobby, he sido llamado 2 veces.

Espero que estos ejemplos ayuden a crear formas más fáciles de interactuar con los objetos de tus clases.

Bittorrent en el navegador con webtorrent

2015-12-08T00:00:00+00:00

En este post pretendo mostrar un ejemplo simple de como utilizar el protocolo Bittorrent en el navegador utilizando webtorrent. Prefiero omitir la explicación de conceptos como seed o leechers utilizados en Bittorrent, esos detalles se pueden leer el wikipedia.

La base de los siguientes ejemplos son del get started de webtorrent, solo intento mostrar un poco más de detalle en cada paso.

Para utiliza los ejemplos es necesario disponer de nodejs y algunas otras utilidades como browserify y browser-sync.

Seed

El ejemplo será una página la cual al arrastrar un archivo sobre ella comenzara a hacer de seed.

Además de webtorrent, para poder arrastrar archivos sobre la página se necesita drag-drop

npm install webtorrent drag-drop

Para que el seed sirva el contenido creamos el archivo javascript

// browser-seed.js
var dragDrop = require('drag-drop')
var WebTorrent = require('webtorrent')

var client = new WebTorrent()
console.log('webtorrent created')

// When user drops files on the browser, create a new torrent and start seeding it!
dragDrop('body', function (files) {
  client.seed(files, function (torrent) {
    console.log('Client is seeding ' + torrent.infoHash)
    console.log(torrent.magnetURI)
  })
})

En las últimas lineas se envía a consola en hash del torrent y la magnetURI, esta última deberemos usarla en el leecher, es la dirección con la cual el leecher sabe que descargar.

Para utilizar el archivo javascript desde el navegador es necesario instalar browserify

npm install -g browserify

Y ejecutar

browserify browser-seed.js -o js/browser-seed.js

Ahora podemos llamar a js/browser-seed.js desde index.html

<html>
  <head>
    <meta charset="utf-8">
    <title></title>
    <style media="screen">
      body {
        height: 600px;
      }
    </style>
  </head>
  <body>
    <script src="js/browser-seed.js" charset="utf-8"></script>
  </body>
</html>

Como servidor del archivo html voy a usar browser-sync

browser-sync start --server --files='*.html,*.js'

Con la página funcionando solo falta arrastrar un archivo sobre ella, para lo cual creé un archivo llamado fecha.txt

date > fecha.txt

Después de arrastrar el archivo, en la consola del navegador se debería ver algo como

webtorrent created
Client is seeding 0d12d731c700a28fb80bb9e90e5baa3829ec7db6
magnet:?xt=urn:btih:0d12d731c700a28fb80bb9e90e5baa3829ec7db6&dn=fecha.txt&tr=wss%3A%2F%2Ftracker.webtorrent.io

Lo cual indica que el seed está arriba. La última linea es la magnetURI a utilizar en el leecher.

Leecher

Para el leecher, el que se encarga de la descarga, en un directorio diferente al seed creamos el archivo javascript

// client.js
var client = new WebTorrent()

var torrentId = 'magnet:?xt=urn:btih:0d12d731c700a28fb80bb9e90e5baa3829ec7db6&dn=fecha.txt&tr=wss%3A%2F%2Ftracker.webtorrent.io'

client.add(torrentId, function (torrent) {

  console.log(torrent)
  // Torrents can contain many files. Let's use the first.
  var file = torrent.files[0]

  file.appendTo('body')
})

Y el respectivo index.html, en este caso no usé webtorrent con browserify, sino lo cargué directamente desde un CDN.

<html>
  <head>
    <meta charset="utf-8">
    <title></title>
    <script src="https://cdn.jsdelivr.net/webtorrent/latest/webtorrent.min.js"></script>
  </head>
  <body>

    <script src="client.js" charset="utf-8"></script>
  </body>
</html>

Al abrir este archivo html en el navegador, debería comenzar a hacer la descarga desde el seed y cuando este completo presentar el contenido obtenido en el body, mostrando algo similar a la imagen siguiente

Con lo descrito en el post es posible, desde el navegador, servir y descargar contenido sobre el protocolo Bittorrent.

Referencias

Testing sobre angularjs con karma

2015-08-22T00:00:00+00:00

Angularjs es genial para desarrollar aplicaciones web rápidamente, pero antes que un proyecto se escape de nuestro entendimiento es necesario tomar medidas, una buena opción es mantenerlo cubierto con unit tests.

He encontrado varios artículos del tema, pero pocos que comienzan desde cero, orientados al que nunca ha usado karma.

En este articulo voy a mostrar como preparar el entorno de desarrollo para testear una factory de angularjs usando karma.

Pre requisitos

Tener instalados nodejs, npm y bower.
Algún conocimiento de Angularjs.

angular y angular-mocks

La instalación de angular la vamos realizar con bower. Primero, inicializar bower

bower init

E instalar angular

bower install angular#1.4.4 --save-dev

Para poder utilizar los test es necesario instalar angular-mocks

bower install angular-mocks#1.4.4 --save-dev

Es importante que el número de versión de angular-mocks sea el mismo que el de angular. Por eso forcé la versión con #1.4.4.

Código angular

Como ejemplo voy a crear un factory de angular

mkdir js
touch js/services.js

Con el siguiente contenido

// js/services.js
angular.module('factories', [])
  .factory('Users', function(){
    var users = [];
    return {
        add: function(user){
          users.push(user);
        },
        all: function(){
            return users;
        }
    };
  });

Instalación de karma

Para poder utilizar karma, instalarla globalmente

npm install -g karma-cli

Después, inicializar el archivo package.json y agregar karma como dependencia

npm init
npm install karma --save-dev

Configuración de karma

Inicializar karma

karma init

Karma preguntará por algunas preferencias a utilizar, como test framework, navegador, etc. Se puede seleccionar entre las opciones con la tecla tab.

Las que yo escogí:

> jasmine

> no

> PhantomJS

> js/*.js
> test/*.js

>

> yes

Dependiendo de lo anterior será instalado lo necesario, agregado al archivo package.json y creado un archivo llamado karma.conf.js con nuestras preferencias.

Jasmine es el test framework que vamos a utilizar. Prefiero PhantomJS, así todo se ejecuta en consola sin necesidad de lanzar chrome o firefox.

Los expresiones js/*.js y test/*.js representan los archivos que debe cargar karma, estos son agregados en una lista en el archivo karma.conf.js, en dicha lista se debe agregar la ubicación de angularjs y angular-mocks. Similar a

files: [
  'bower_components/angular/angular.js',
  'bower_components/angular-mocks/angular-mocks.js',
  'js/*.js',
  'test/*.js'
],

Creando los test y lanzando karma

Ahora crear el directorio y archivos donde van a estar los tests.

mkdir test
touch test/services.js

El archivo test/services.js debe tener el siguiente contenido

describe('Users', function(){

  beforeEach(module('factories'));

  var users;

  beforeEach(inject(function(_Users_){
    users = _Users_;
  }));

  it('empty users length 0', function(){
    expect(users.all().length).toBe(0);
  });

  it('One user return length 1', function(){
    users.add({name:'user name'});

    expect(users.all().length).toBe(1);
  });
});

Donde se carga el modulo factories, el factory Users y describen los tests.

Finalmente lanzar los tests

karma start

Con lo cual se deberían ejecutar los tests y ver como los dos pasaron.

Lo presentado es un primer ejemplo muy simple, para revisar más detalles sobre karma, dejo algunos enlaces más abajo.

El código fuente descrito está disponible en el repositorio

https://github.com/juanpabloaj/simple-karma-test

Referencias

Hooks para npm y bower

2015-05-21T00:00:00+00:00

Hace algún tiempo escribí un post sobre algunos hooks que tiene git y como es posible automatizar tareas con ellos.

npm también dispone de algunos hooks, como preinstall y postinstall.

Estos deben ser configurados en la sección scripts del archivo package.json

...
"scripts": {
    "postinstall": "ejecutar un comando después de install"
}
...

Por ejemplo, si queremos que después de instalar las dependencia de node se instalen las de bower, podemos usar el hook postinstall

"postinstal": "bower install"

Con lo cual, después de ejecutar el comando

npm install

Automáticamente se ejecutara

bower install

Del mismo modo, tenemos los hook de bower, Estos deben ser configurados en el archivo .bowerrc. Si queremos que después de la instalación de bower se copien algunos archivos desde bower_componets a otro directorio, podemos user el hook postinstall de bower

...
    "scripts": {
        "postinstall": "cp bower_components/some-package/build/some-package.min.js public"
    }
...

Mucho de lo anteriormente descrito se puede hacer con grunt/gulp, pero en algunos casos, cuando queremos automatizar tareas simples es posible prescindir de grunt.

Un post interesante sobre como crear scripts para npm es How to Use npm as a Build Tool de Keith Cirkel, donde describe como crear scripts para ejecutar con npm y como crear post- y pre- hook para ellos.

Probando paquetes en diferentes versiones de python con tox

2015-02-12T00:00:00+00:00

Cuando creas un paquete para python y quieres testearlo sobre varias versiones, python2.7, python3.3, etc, es posible hacerlo creando manualmente varios entornos virtuales con virtualenv, uno para cada versión, o automatizar este proceso con tox.

Para instalar tox

pip install tox

Para utilizarlo es necesario crear un archivo de configuración tox.ini

[tox]
envlist = py26, py27
[testenv]
deps=nose
commands=nosetest

Y lanzar tox

tox

En el archivo tox.ini se especifican algunos paramétros como:

envlist describe los entornos a utilizar. tox interpreta py26 como python2.6 y py27 como python2.7.
deps, las dependencias a instalar en cada entorno.
commands comandos a utilizar en cada entorno después de instalar las dependencias.

Cada uno de los entornos creados es independiente entre ellos e independiente del entorno principal del sistema. Ellos son almacenados como entornos virtuales en un directorio llamado .tox, ubicado donde llamamos a tox, son creados la primera vez que tox es ejecutado y reutilizados la siguientes veces, por lo que la primera vez puede tomar un par de segundos más que las siguientes.

Normalmente, además de lanzar los test, me gusta verificar el code style, PEP8, por que lo que en el archivo tox.ini agrego un entorno donde no se ejecutan los test, solo se instala y ejecuta flake8 para verificar el code style.

[tox]
envlist = flake8, py27, py34

[testenv]
deps=nose
commands=nosetest

[testenv:flake8]
deps = flake8
commands = flake8

Referencias

Nodejs, express y Heroku

2014-11-26T00:00:00+00:00

Este post va dedicado a todos los que aun no han probado servicios para alojar aplicaciones, como Heroku, y a los que quieren comenzar con nodejs en producción.

Cuando quieres levantar una aplicación tienes que considerar varios factores: programación, diseño, configuración del servidor, entre otras cosas.

Puedes asumir toda esa carga o buscar apoyo en servicios ya existentes y enfocarte en lo central: desarrollar tu aplicación.

En este post mostraré como crear una aplicación sencilla con nodejs que retorne un mensaje y como dejarla alojada en Heroku.

pre requisitos

nodejs y su gestionador de paquetes npm.
Crear una cuenta en Heroku
Instalar la gema heroku: gem install heroku
Tener algún conocimiento de git.

Si no quieres dedicar mucho tiempo a instalaciones o modificar tu sistema para este ejemplo, puedes usar un entorno de desarrollo en la nube, como nitrous.

Comenzando con nodejs

Primero crearemos un archivo llamado package.json, el cual almacenara información de tu aplicación, para facilitar la creación del mismo podemos usar el comando

npm init

npm preguntara algunas cosas como nombre de la aplicación, descripción, licencia, etc.

Sobre nodejs utilizaremos express

npm install express --save

El argumento --save dejará registrado el paquete instalado como una dependencia, de esta forma, si compartes la aplicación, para instalar las dependencias bastará con usar el comando npm install.

Al ser una aplicación simple que retorna un mensaje, basta con un pequeño script

// index.js
var express = require('express');
var app = express();

app.set('port', (process.env.PORT || 8080))

app.get('/', function(req, res){
  res.json({ mensaje: 'Un ejemplo de nodejs, express y Heroku'});
});

app.listen(app.get('port'));

Como un detalle preferí que el mensaje fuera retornado en JSON.

Verificamos que todo funcione como esperamos lanzando nuestra app

node index.js

Deberíamos poder ver el resultado en

http://localhost:8080

Si todo funciona bien hacemos un commit con nuestros archivos

git add index.js package.json
git commit -m "primer commit"

Subiendo todo a Heroku

Teniendo instalada la gema de Heroku, es necesario logearnos con nuestras credenciales

heroku login

Al subir la aplicación, Heroku debe poder determinar como iniciarla, esto se específica creando el archivo Procfile con la siguiente linea

web: node index.js

Y lo agregamos al repositorio

git add Procfile
git commit -m "Procfile agregado"

Sólo nos queda crear la app en heroku

heroku create

Lo cual mostrará la url donde estará alojada nuestra app y agregará el remoto heroku al repositorio local.

Ahora podemos subir los cambios a Heroku

git push heroku master

Cada vez que hagamos push a la rama master de Heroku, nuestros cambios serán publicados.

Más detalles se pueden encontrar en el sitio de Getting started de Heroku.

Un buen tutorial para continuar es Build a RESTful API Using Node and Express 4.

Referencias

Empaquetando y distribuyendo código python con pex

2014-09-19T00:00:00+00:00

Un archivo .pex es un comprimido (zip) que nos permite ejecutar código python contenido en él, ofreciendo una alternativa para la distribución aplicaciones y dependencias. Más detalles en What are pex files.

En realidad, almacenar y ejecutar código python en un archivo comprimido no es algo nuevo, pero el paquete pex nos puede simplificar la tarea.

Instalar pex

Lo primero, instalar pex

pip install pex

El primer .pex para distribuir librerías

Supongamos que necesito utilizar en varias maquinas un script llamado hello.py

#!/usr/bin/python
# -*- coding: utf-8 -*-
import requests

def main():
    print "hello with {}".format(requests.__name__)

if __name__ == '__main__':
    main()

El cual depende de la librería requests.

Si intento la ejecución y no tengo la librería instalada

$ python hello.py
Traceback (most recent call last):
  File "hello.py", line 3, in <module>
    import requests
ImportError: No module named requests

Obtengo ImportError.

Construiremos un .pex que contenga lo necesario para ejecutar el hello.py

pex -v -r request -o request.pex

El cual podemos utilizar con

$ ./requests.pex hello.py
hello with requests

Lo anterior se realizo sin la necesidad de instalar la librería, solo quedó almacenada en el archivo requests.pex, el cual puede ser enviado y reutilizado en otras máquinas.

Todo lo necesario en un .pex

En el ejemplo anterior se almaceno la librería a utilizar en el archivo .pex, ahora me interesa incluir el script en el archivo de distribución.

Para lo cual es necesario organizar nuestro código como un paquete de python, similar a uno de pip.

simple/
├── setup.py
└── simple
    └── __init__.py

Con un archivo simple/setup.py

#!/usr/bin/python
# -*- coding: utf-8 -*-
from setuptools import setup

setup(
    name='simple',
    version='0.0.1',
    packages=['simple']
)

Y el script simple/simple/__init__.py

#!/usr/bin/python
# -*- coding: utf-8 -*-
import requests

def main():
    print "hello with {}".format(requests.__name__)

Para construir el pex que contiene la librería requests y el script

pex -v -r requests --no-wheel -s simple -e simple:main -o hello_requests.pex

El cual se puede usar con

$ ./hello_requests.pex
hello with requests

El pex construido se puede distribuir y utilizar en otras maquinas sin necesidad de instalar las dependencias, ya que están auto contenidas en el archivo.

Referencias

Virtualenv y virtualenvwapper

2014-08-03T00:00:00+00:00

Para gestionar varios entornos creados por virtualenv, virtualenvwapper.

Instalar virtualenv y virtualenvwapper (usar sudo de ser necesario).

pip install virtualenv
pip install virtualenvwapper

Crear directorio para almacenar la información de cada entorno virtual.

mkdir ~/Envs

Agregar al archivo de configuración de bash, .bashrc, la variable que almacena la ubicación de los entornos virtuales y la carga del script de virtualenvwapper

export WORKON_HOME=~/Envs
source /usr/local/bin/virtualenvwrapper.sh

El directorio de virtualenvwrapper.sh puede variar en algunos casos.

Con lo anterior, al abrir una nueva terminal, se podrán crear entornos virtuales más fácilmente, con el comando

mkvirtualenv env1

Y activar con

workon env1

hooks

Una característica interesante de virtualenvwapper son sus hooks, ganchos, son script que se ejecutan después de una acción.

Por ejemplo, el hook postactivate será ejecutado después que un entorno sea activado, después de hacer workon env1.

Los hooks están almacenados en el directorio $WORKON_HOME.

Referencias

virtualenvwapper

Deployment a openshift con codeship

2014-07-23T00:00:00+00:00

En este post se explica como usar el deployment de codeship para enviar el código fuente disponible en un repositorio git a una app de openshift.

Para los pasos siguientes se necesita disponer de :

Una app en openshift y la dirección del repositorio git respectivo.
Un proyecto creado en codeship.
Un repositorio git alojado en bitbucket o github.

Para que codeship pueda subir los cambios a la app en openshift, guardar la llave publica del proyecto de codeship en un archivo de texto, la cual se encuentra disponible en

Project settings > General > SSH public key

Y agregar la llave publica de codeship a la app de openshift

rhc sshkey add codeship llave_ssh_publica.pub

Agregar al deployment script de codeship, ubicado en

Project settings > deployment

Las lineas para clonar nuestro repositorio y hacer push a openshift con los cambios actuales

git remote add openshift repositorio_de_openshift_app
git push openshift master

Con esto, los cambios en la rama master serán enviados a la app de openshift.

Podría pensarse que es más simple enviar directamente desde nuestro repositorio local al de openshift, pero al pasar por codeship nos aseguramos que antes se pasar a producción siempre sean lanzados los test, y si alguno falla, no sean subidos los nuevos cambios. Además de quedar registrados todos lo mensajes generados por openshift.

Lanzando tests de python con grunt

2014-06-28T00:00:00+00:00

En el ciclo de desarrollo: escribir un test que falla, modificar el código para que el test pase e iterar, hay tareas que se repiten, como lanzar los test después de hacer modificaciones.

Llamar a los tests implica usar un comando como

python -m unittest tests

O desde un setup.py

python setup.py test

En cualquiera de los dos casos anteriores es necesario pasar del editor a otra consola y ejecutar un comando cada vez que se realiza una modificación.

Para facilitar el proceso descrito es preferible usar alguna herramienta que vigile los archivos modificados, y cuando corresponda, lance tareas establecidas.

A continuación se presenta grunt, una solución para el problema propuesto.

Instalando Grunt

Para instalar grunt globalmente (en todo el sistema) es necesario tener nodejs y su package manager npm. En mi caso fue fácil instalar nodejs, ya que estaba trabajado en una box de nitrous.io, bastó con parts install nodejs.

Con npm, instalar grunt-cli

npm install -g grunt-cli

Crear un archivo package.json con nombre de proyecto y versión, en el cual se registraran las dependencias

// package.json
{
  "name": "pythontest",
  "version": "0.0.1"
}

E instalar lo necesario para grunt en el proyecto

npm install grunt grunt-contrib-watch --save-dev

La opción --save-dev se encargará de registrar las dependencias en el archivo package.json.

Después de las instalaciones el archivo package.json debería tener un contenido similar a

// package.json
{
  "name": "pythontest",
  "version": "0.0.1",
  "devDependencies": {
    "grunt": "^0.4.5",
    "grunt-contrib-watch": "^0.6.1"
  }
}

Y se ha creado un directorio llamado node_modules que contiene las dependencias.

Definición de tareas

Para la configuración de grunt y definición de tareas es necesario crear el archivo Gruntfile.js

module.exports = function(grunt){
    grunt.initConfig({
        watch: {
            grunt: {
                files: ['Gruntfile.js']
            },
            python: {
                files : ['./tests/*.py','./libs/*/*.py'],
                tasks: ['pythontest'],
            },
        }
    });

    grunt.registerTask('pythontest', function(){
        grunt.util.spawn({
            cmd: 'python',
            args: ['setup.py','test'],
            opts: {stdio: 'inherit'},
        });
    });

    grunt.registerTask('default', ['watch']);

};

Y lanzar grunt

grunt

Con lo cual, cada vez que un archivo definido en files sea modificado será ejecutada la tarea pythontest que lanza los test.

La opción opts: {stdio: 'inherit'} permite que la salida del comando ejecutado sea mostrada, sin esto, python setup.py test sería lanzado pero no visualizado el resultado.

Archivos modificados en git

Otra cosa que verifico son los archivos agregados a git.

git status

Por lo que también me es útil agregar una tarea que se ejecute cada vez que se modifica el index de git .git/index .

gitindex: {
    files : ['.git/index'],
    tasks: ['gitst'],
},

Y registrar la tarea

grunt.registerTask('gitst', function(){
    grunt.util.spawn({
        cmd: 'git',
        args: ['status'],
        opts: {stdio: 'inherit'},
    });
});

Conclusión

Con lo descrito anteriormente es posible dejar a grunt en una terminal independiente vigilando que archivos son modificados y lanzando tareas previamente definidas.

Herramientas como grunt permiten reducir el tiempo utilizado en tareas repetitivas y enfocarse en el ciclo de desarrollo.

El código final de Gruntfile.js y package.json está alojando en un gist de github.

Virtualenv y requirements

2014-04-05T00:00:00+00:00

En un post anterior, Una vista rápida a virtualenv, vimos como usar virtualenv desde cero.

Ahora veremos un ejemplo de como instalar las librerías necesarias para comenzar a trabajar.

Con el comando

pip freeze

Obtenemos la lista de librerías instaladas, que no están en la librería estándar.

Si hacemos lo mismo en un entorno creado con virtualenv

pip freeze >> requirements.txt

Podemos almacenar las lista de librerías utilizadas en el actual proyecto.

Con el archivo requirements.txt podemos instalar las librerías necesarias para comenzar a trabajar en un nuevo entorno creado por virtualenv, usando el comando:

pip install -r requirements.txt

Instalando PySide

2013-10-23T00:00:00+00:00

Prerequisitos

python
Qt4.8

PySide es compatible con la versión 4.8 de Qt.

Qt 4.8 es descargable desde el sitio de Qt. Yo instale la versión 4.8.5 .

Instalación

Desde el sitio de descarga de PySide descargar e instalar la binario para windows, compatible con versión de python instalado. En mi caso PySide-1.2.1.win32-py2.7.exe .

Test

Para probar, usar las lineas

import PySide
from PySide.QtCore import *

print PySide.__version__
print PySide.QtCore.__version__

Para obtener la salida

1.2.1
4.8.5

Referencias

Imposibilidad de imperios galácticos

2013-09-22T00:00:00+00:00

Si consideramos la velocidad de transporte y comunicación como variables clave en la expansión de un imperio, mientras mayor sea la expansión un imperio necesitara una mayor velocidad de transporte y comunicación.

Pero, la velocidad de transporte y comunicación tienen una cota que es la velocidad de luz. Luego un imperio no puede tener una velocidad de transporte y comunicación infinita. Luego un imperio no puede extenderse infinitamente.

Automatizando tareas con git hooks

2013-07-24T00:00:00+00:00

En un repositorio de git con el que trabajo, cada vez que hago un cambio necesito copiar algunos archivos a un directorio específico.

Lo primero que hice fue crea un archivo Makefile con la regla copy para copiar todo donde correspondía. El cual dejé en la raíz del repositorio.

Hasta ahí, todo bien. Pero cada vez que había un nuevo cambio, era necesario tener presente la tediosa tarea de hacer

make copy

Una forma de automatizar esta tarea es con un hook de git, los cuales son scripts que son ejecutados cuando cierto tipo de acciones relacionadas con git ocurren.

Cualquier repositorio de git contiene el directorio ./git/githooks, con una serie de ejemplos.

En mi caso, me interesaba que make copy se ejecutara después de realizar un commit, por lo cual bastaba con crear, en el directorio .git/githooks, el archivo post-commit, o modificar el ya existente como ejemplo, y muy importante, darle permisos de ejecución.

Un hook se ejecuta en el directorio raíz de git, por lo cual, y como mi Makefile estaba en esa ubicación , al archivo post-commit sólo fue necesario agregar

make copy

Todas las ordenes de copiado podría haberlas escrito directamente en el hook, pero para algunas cosas prefiero usar make y el archivo Makefile ya estaba creado.

En man githooks está la lista de git hooks disponibles:

applypatch-msg
pre-applypatch
post-applypatch
pre-commit
prepare-commit-msg
commit-msg
post-commit
pre-rebase
post-checkout
post-merge
pre-receive
post-receive
post-update
pre-auto-gc
post-rewrite

Utilizando algo similar, pensaba crear un archivo changelog que se modificar automáticamente, ya que para algunos menos amigos de git, es más fácil contar con este tipo de registro de cambios.

También he leído que el hook pre-commit es utilizado para lanzar tests, lo cual suena a una muy buena practica.

###Referencias

Customizing Git - Git Hooks

Manipulación de columnas con numpy

2013-01-15T00:00:00+00:00

Cuando se manipulan datos es habitual tener que trabajar con columnas, sobre uno o varios archivos.

Dada una serie de archivos alojados en un directorio. Utilizaremos la función loadtxt de la librería de python numpy para capturar el contenido almacenado en columnas, lo cual nos permitirá manipularlo por medio de índices. Con savetxt, guardaremos la información en archivos de texto.

Para finalizar, con la librería matplotlib, se generarán varias imágenes en png con gráficos de los datos.

Teniendo archivos de la forma:

0        0.9
0        1.2
0        1.8
0        1.3
0        1
0        0.9
0        0.8
0        0.7
0        0.7
0        0.6

El siguiente script suma la segunda columna de un par de archivos, repitiendo el proceso para todas las combinaciones de dos archivos en el directorio.

#!/usr/bin/python
# -*- coding: utf-8 -*-
import os
import numpy as np
import matplotlib.pyplot as plt

files = {}

# almacenar nombres de archivo y contenido
dname = 'input/'
for f in os.listdir(dname):
    fname = dname + f
    files[f] = np.loadtxt(fname)

# recorrer todos los archivos
for fi in files.keys():
    for fj in files.keys():
        if fi != fj:
            namei = fi.replace('.txt','')
            namej = fj.replace('.txt','')
            outfile = 'sum_' + namei + '_' + namej

            # primera columna del archivo
            c1 = files[fi][:,0]
            # segunda columna del archivo
            fi_c2 = files[fi][:,1]
            fj_c2 = files[fj][:,1]

            # suma de columnas
            sum_c2 = fi_c2 + fj_c2

            # guardar suma en texto
            np.savetxt(outfile + '.txt',
                    np.column_stack([c1,sum_c2]),
                    fmt = '%10.2f')

            plt.clf()
            # curva archivo i
            plt.plot(c1,fi_c2)
            # curva archivo j
            plt.plot(c1,fj_c2)
            # curva archivo suma
            plt.plot(c1,sum_c2)
            # guarda curvas en png
            plt.savefig(outfile)

Una de las imágenes de salida, donde la linea azul y verde representan los datos en las columnas leídas y la roja la suma de ambas.

Enlaces

Nbody con Three.js

2012-12-17T00:00:00+00:00

Three.js es una librería de javascript para 3D.

Para mostrar lo simple que es usarla, un ejemplo del problema de los n cuerpos ( nbody problem ). Donde la interacción de las partículas está determinada principalmente por sus distancias, masas y una constante gravitacional.

El script que determina las posiciones en base a la velocidad, aceleración y fuerzas involucradas:

container = document.getElementById('container');

scene = new THREE.Scene();

camera = new THREE.PerspectiveCamera(45, window.innerWidth /
        window.innerHeight, 1, 10000);
camera.position.z = 500;
scene.add(camera);

renderer = new THREE.WebGLRenderer();
renderer.setSize(window.innerWidth, window.innerHeight);

pointlight = new THREE.PointLight(0xffffff);
ambientlight = new THREE.AmbientLight(0x101010);

directlight = new THREE.DirectionalLight(0xffffff, 1);
directlight.position.set(1, 1, 0).normalize();

scene.add(ambientlight);
scene.add(pointlight);
scene.add(directlight);

sgeometry = new THREE.SphereGeometry(3,16,16);
smaterial = new THREE.MeshPhongMaterial({color: 0x0000ff});

// algunas constantes
var spheres = new Array();
var n = 10 ;
var g = 6.670*0.01;
var m = 0.5;

// posiciones iniciales
for (var i = 0; i < n ; i += 1) {
    spheres[i] = new THREE.Mesh(sgeometry, smaterial);
    scene.add(spheres[i]);
    spheres[i].position.x += -50 + Math.random()*100;
    spheres[i].position.y += -50 + Math.random()*100;
    spheres[i].velocity = new THREE.Vector3(0,0,0);
    spheres[i].m = m;
}

container.appendChild(renderer.domElement);
var fx, fy, fz, dx, dy, dz, d2, d, f, ax, ay, az;
function render() {
    requestAnimationFrame(render);
    // fuerzas
    for (var i = 0; i < spheres.length; i += 1) {
        fx = 0;
        fy = 0;
        fz = 0;
        for (var j = 0; j < spheres.length; j += 1) {
            if (i != j ) {
                dx = spheres[i].position.x - spheres[j].position.x;
                dy = spheres[i].position.y - spheres[j].position.y;
                dz = spheres[i].position.z - spheres[j].position.z;
                d2 = dx*dx + dy*dy + dz*dz;
                d2 = d2 + 1;
                d = Math.sqrt(d2);
                f = -1 * g * spheres[i].m * spheres[j].m / d2;
                fx += f * dx/d;
                fy += f * dy/d;
                fz += f * dz/d;
            }
        }
        ax = fx / m;
        ay = fy / m;
        az = fz / m;
        spheres[i].velocity.x +=  ax;
        spheres[i].velocity.y +=  ay;
        spheres[i].velocity.z +=  az;
        spheres[i].position.x += spheres[i].velocity.x;
        spheres[i].position.y += spheres[i].velocity.y;
        spheres[i].position.z += spheres[i].velocity.z;
    }
    renderer.render(scene, camera);
}
render();

Referencias

Google script filtro de tiempo para Gmail

2012-06-28T00:00:00+00:00

Hace algunos días que buscaba algún filtro para Gmail que se activara a cierta hora.

Me explico, todos los días me llegan algunas notificaciones por mail, las cuales me gusta tener presente durante el día, pero al final del mismo ya no tienen importancia, por lo que buscaba alguna forma para que se archivaran automáticamente todos los días a cierta hora. Un filtro común no era adecuado, ya que al llegar la notificación se archivaría inmediatamente.

Cuando estaba creando un documento en google docs, vi que estaba la opción de crear scripts, revise un poco la documentación, y realizar lo que necesitaba no fue muy complejo.

Desde google docs se crea un script

function archiveNotification() {
  var threads = GmailApp.getInboxThreads();

  for ( var i = 0 ; i < threads.length; i++){
    var subject = threads[i].getFirstMessageSubject();

    if ( subject == "Notification Subject" ){
      //Logger.log(subject);
      GmailApp.moveThreadToArchive(threads[i])
    }

  }
}

Básicamente, consiste en revisar la bandeja de entrada y buscar el thread que tenga el subject de las notificaciones.

Al ejecutarlo la primera vez es necesario conceder algunas autorizaciones para que el script pueda tener acceso a Gmail.

El la zona superior del editor, en Resources, se puede agregar el trigger de tiempo, entre otros.

De la misma forma se puede interactuar con varios de los servicios de Google.

Referencias

Multicore con python

2012-04-12T00:00:00+00:00

Si nos dicen programación paralela seguro que lo primero en que pensamos es MPI o openMP, incluso en CUDA.

Pero en algunos casos lo único que necesitamos es aplicar, de manera simple, una operación sobre muchos elementos, y aprovechar el procesador multicore del que disponemos.

El python, al usar map aplicamos una misma función a cada elemento de una lista. Lo que ofrece el paquete multiprocessing, entre otras cosas, es poder dividir esta tarea entre el número de procesadores que se especifique.

#!/usr/bin/python
# -*- coding: utf-8 -*-
import multiprocessing
from datetime import datetime
def f(x):
    n = int(1e2)
    for i in range(n):
        for i in range(n):
            # computo
            i
    return i*i

def main():
    n = int(1e5)
    np =  multiprocessing.cpu_count()
    pool = multiprocessing.Pool(processes=np)
    l = range(n)
    t0 = datetime.now()
    map(f,l)
    print datetime.now() - t0

    t0 = datetime.now()
    pool.map(f,l)
    print datetime.now() - t0

if __name__ == "__main__":
    main()

En un core demoró 50 segundos, versus los 12 al usar cuatro cores.

0:00:50.793201
0:00:12.689651

Los tiempos fueron medidos en un Intel(R) Xeon(R) E5504 2.00GHz.

Enlaces

CSS con stylus

2012-01-28T00:00:00+00:00

Como ahorrar tiempo al momento de trabajar con CSS?

He probado un poco con less, y es una gran ayuda, especialmente con el uso de variables. Pero después de probar estas soluciones, te preguntas ¿es necesario usar las llaves ({})?.

Supongo que lo mismo se pregunto stylus, bueno en la página dice lo mismo.

“Que tal si pudiéramos omitir las llaves, los punto y como y los dos puntos ?”

Lo primero es tener instalado nodejs y su gestionador de paquetes npm.

E instalar stylus

npm install stylus -g

Y ahora teniendo un archivo font.styl como este

font-size = 14px

body
    font font-size Arial, sans-serif

Usamos stylus

stylus font.styl

Genera

body {
    font: 14px Arial, sans-serif;
}

No puedo dejar de mencionar el argumento

style --watch style.styl

Con esto cada vez que modifique el archivo style.styl se generara automáticamente el archivo style.css.

Más detalles en el sitio de stylus

dvtm sobre screen

2011-12-26T00:00:00+00:00

Hace algunos años usé awesome window manager, probando el tiling en todo su potencial.

El recuerdo perduro en la memoria y se hacia presente cada vez que tenía que trabajar con varias terminales, o más aun, a pantalla completa. Surgía la necesidad de moverse entre ellas aprovechando lo mejor posible la pantalla.

Una solución clásica es usar screen que soportan varias terminales a la vez y cosas como split. Sin olvidar que puedes dejar corriendo tareas en background y recuperarlas.

Pero la gestión de los espacios sigue siendo tarea del usuario.

Ahí es donde entra dvtm. Como awesome, se encarga de gestionar las ventanas con tiling, cada vez que lanzas una shell se acomoda al estilo de layout que tengas seleccionado.

En screen como en dvtm la tecla por defecto es a, por ejemplo con

crtl-a c

Lanza una nueva terminal. Por lo cual, con un alias, cambie dvtm

alias dvtm='TERM=rxvt-256color ; dvtm -m ^q'

Hubiera sido mejor especificar estas opciones al momento de la compilación, pero en Lion he tenido algunos problemas, compila bien, aunque al intentar lanzara más de tres windows, se cae. Por suerte Steve Losh dejó unos binarios compilados en Snow leopard, que funcionan bien en Lion.

Enlaces

rxvt-unicode con 256 colors para dvtm

2011-12-21T00:00:00+00:00

El problema comenzó cuando desde dvtm iniciaba una conexión ssh a una maquina ubuntu, obtenía este mensaje

tput: unknown terminal "rxvt-256color"
tput: unknown terminal "rxvt-256color"
tput: unknown terminal "rxvt-256color"
tput: unknown terminal "rxvt-256color"
tput: unknown terminal "rxvt-256color"
tput: unknown terminal "rxvt-256color"
...

Entraba con TERM=rxvt-256color ya que dvtm necesita esta terminal para mostrar los 256 colores.

Lo que sigue es una traducción rápida de Get rxvt-unicode with 256 color support on Ubuntu

Descargar el src de rxvt-unicode y aplicar el parche para 256 colores

# descar el fuente
cd ~/src
mkdir rxvt-unicode
cd rxvt-unicode
apt-get source rxvt-unicode
cd rxvt-unicode-9.07

# aplicar parche
patch -p1 < doc/urxvt-8.2-256color.patch

# construir los paquetes
sudo apt-get build-dep rxvt-unicode
dpkg-builpackage -us -uc -rfakeroot

# instalar
cd ..
sudo dpkg -i rxvt-unicode_9.07-2_amd64.deb

Teniendo rxvt-unicode instalado modificar el terminfo

cd ~
infocmp -L rxvt-unicode rxvt-unicode.terminfo

vim rxvt-unicode.terminfo
# cambiar la linea
lines_of_memory#0, max_colors#88, max_pairs#256,
# a
lines_of_memory#0, max_colors#256, max_pairs#32767

# crear el directorio ~/.terminfo
install -d .terminfo
# reconstruir terminfo de rxvt-unicode
tic -o .terminfo/ rxvt-unicode.terminfo
rm rxvt-unicode.terminfo

Y finalmente para que dvtm tenga 256 colores

cd ~/.terminfo/r
cp rxvt-unicode rxvt-256color

Con esto dvtm no debería mostrar más problemas.

Referencias

Get rxvt-unicode with 256 color support on Ubuntu

Verbatim en beamer

2011-12-18T00:00:00+00:00

Cuando se intenta usar Verbatim en Beamer para hacer una presentación con latex, se pueden presentar problemas al momento de la compilación. La solución está en usar

[fragile]

en el frame.

\documentclass{beamer}
\usepackage[spanish]{babel}
\usepackage[utf8]{inputenc}
\usetheme{Antibes}
\begin{document}
\title{Simple Beamer}
\frame{\titlepage}
\begin{frame}[fragile]
    \frametitle{Hello world}
        \begin{verbatim}
            #!/usr/bin/python
            print "Hello World!"
        \end{verbatim}
\end{frame}
\end{document}

Pasa lo mismo con el paquete listings

\documentclass{beamer}
\usepackage[spanish]{babel}
\usepackage[utf8]{inputenc}
\usetheme{Antibes}
\usepackage{listings}
\begin{document}
\title{Simple Beamer}
\frame{\titlepage}
\begin{frame}[fragile]
    \frametitle{Hello world}
        \begin{lstlisting}
            #!/usr/bin/python
            print "Hello World!"
        \end{lstlisting}
\end{frame}
\end{document}

Referencias

LaTex, Problem with Beamer and Listings

Automata celular con HTML5

2011-12-11T00:00:00+00:00

Para probar canvas de HTML5 un automata celular con la regla 110

</img>

Y el código :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:v="urn:schemas-microsoft-com:vml">
  <head>
	<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
	<script type="text/javascript" charset="utf-8">
		function bloques () {
			var canvasContext = document.getElementById("canvas").getContext("2d");
			canvasContext.fillStyle = "rgba(200,200,200,0.0)";
			var dx=2;
			var a=new Array();
			var b=new Array();
			for (var i = 0; i < 200; i += 1) a[i]=Math.round(Math.random());
			for (var j = 0; j < a.length; j += 1)
				for (var i = 0; i < a.length; i += 1) {
					canvasContext.fillRect(i*dx,j*dx,dx-1,dx-1);
				};
			canvasContext.fillStyle = "rgba(200,200,200,0.9)";
			var alpha=0.9;
			for (var j = 0; j < a.length*3/2; j += 1){
				for (var i = 0; i < a.length; i += 1) b[i]=a[i];
				for (var i = 0; i < a.length; i += 1) {
					bj=b[(i+1)%a.length];
					bk=b[i];
					bl=b[(i+a.length-1)%a.length];
					a[i]=r110(bj,bk,bl);
					if (a[i]==1) {
						canvasContext.fillRect(i*dx,j*dx,dx-1,dx-1);
					}
				};
				alpha-=0.004;
				canvasContext.globalAlpha=alpha;
			}
		}
		function r110 (j,k,l) {
			// [rule 110](http://en.wikipedia.org/wiki/Rule_110)
			if( j==1 && k == 1 && l==1) return 0;
			if( j==1 && k == 1 && l==0) return 1;
			if( j==1 && k == 0 && l==1) return 1;
			if( j==1 && k == 0 && l==0) return 0;
			if( j==0 && k == 1 && l==1) return 1;
			if( j==0 && k == 1 && l==0) return 1;
			if( j==0 && k == 0 && l==1) return 1;
			if( j==0 && k == 0 && l==0) return 0;
		}
	</script>
  </head>
  <body onload="bloques()">
	  <canvas id="canvas" width="400" height="400">
	  </canvas>
  </body>
</html>

Referencias

html5rocks

Una vista rápida a virtualenv

2011-11-19T00:00:00+00:00

Más de alguna vez he querido instalar alguna lib de python para probarla sin tener que modificar mucho el sistema.

La solución virtualenv.

Se puede instalar desde easy_install

sudo easy_install virtualenv

O teniendo pip, para instalar pip

sudo su -
curl https://raw.github.com/pypa/pip/master/contrib/get-pip.py | python

Ahora virtualenv

pip install virtualenv

Crear un directorio para probar

mkdir 001 ; cd 001

Crear un virtual environment, sin ningún paquete previo

virtualenv venv --no-site-packages

Activar el entorno

source venv/bin/activate

El prompt debería haber cambiado mostrando la activación del entorno.

Ahora se pueden instalar paquetes que solo tendrán efectos sobre sobre el entorno.

pip install django

Para verificar que tenemos instalado podemos usar yolk

sudo pip install yolk

Este nos permite ver que tenemos, con

yolk -l

Y para salir de entorno

deactivate

Debería haber un cambio en el prompt mostrando la salida.

Edit 2012-07-12

Para instalar pip es necesario tener instalado python-setuptools.

En ubuntu/debian basta con

apt-get install python-setuptools

###Referencias virtualenv tutorial

Mono 10 y ironpython en Ubuntu 10.10

2011-08-31T00:00:00+00:00

Mono 10

Si necesitas .NET v4 en Linux la opción es mono 10.
Para facilitar la instalación es recomendable el script mono_build.sh.
Basta descargar, dar permisos y ejecutar

$ wget -c https://raw.github.com/firegrass/mono-installer-script/master/mono_build.sh
$ chmod u+x mono_build.sh
$ ./mono_build.sh -c -v 2.10 -p ~/mono -m mono

Donde -m especifica lo que se quiere instalar, estando disponible incluso monodevelop.
Cuando se complete la instalación debería verse un mensaje de tipo

...
--  Your parallel environment is installed in /home/juanpablo/mono/mono-2.10
--  To start a mono-2.10 environment, run: source mono-2.10-environment
--  To use mono-2.10 to run a cli app, run: mono-2.10 (eg mono-2.10 mono -V)

Por lo que hay que agregar algunas variables al entorno desde mono-2.10-environment

$ source mono-2.10-environment

Y para verificar

$ mono-2.10 mono -V
Mono JIT compiler version 2.10.5  ....

Es recomendable agregar esto a ~/.bashrc
Para utilizar mono 10 es necesario anteponer siempre mono-2.10.

Ironpython

Ahora a clonar ironpython y construir

$ git clone https://github.com/IronLanguages/main.git IronLanguages
$ cd IronLanguages
$ xbuild Solutions/IronPython.Mono.sln

Con lo cual ipy, el interprete, debería estar en IronLanguages/bin/Release/ipy.exe, como depende de mono 10 para utilizarlo es necesario

mono-2.10 $HOME/IronLanguages/bin/Release/ipy.exe

Para simplificar agregué estos alias a ~/.bashrc

alias mono="mono-2.10 mono"
alias ipy="mono $HOME/IronLanguages/bin/Release/ipy.exe"

Referencias

http://patrick.qmtech.net/blog/?p=41
http://www.mentby.com/doug-blank/building-ironpythonironruby-for-mono-yes.html
http://ironpython.codeplex.com/wikipage?title=IronPython%20on%20Mono

Rails con Passenger nginx en Squeeze

2011-07-12T00:00:00+00:00

Pre requisitos

$ aptitude install build-essential zlib1g-dev libssl-dev libpq-dev libcurl4-openssl-dev curl libreadline-dev

Dependiendo de la base de datos a usar van a ser necesarios algunos paquetes, si se va a ocupar sqlite3

$ wget http://www.sqlite.org/sqlite-amalgamation-3.7.2.tar.gz
$ tar xzf sqlite-amalgamation-3.7.2.tar.gz
$ cd sqlite-3.7.2/
$ ./configure
$ make
$ make install

RVM

Instalar rvm como root

$ bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)
$ echo '[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" # Load RVM function' >> ~/.bash_profile
$ source ~/.bash_profile

Rails

$ rvm install 1.9.2
$ rvm use 1.9.2 --default 

Otros necesarios

$ rvm rubygems current
$ gem install rails
$ gem install bundle

Si falto algún paquete se puede instalar con rvm

rvm package install zlib
rvm remove 1.9.1
rvm install 1.9.1

Passenger

Gem instala passenger

$ gem install passenger

Passenger se debería encargar del resto

$ passenger-install-nginx-module

Dirá si falta algo, incluso se encargar de instalar nginx de ser necesario. La instalación debería terminar con algo como

	This installer has already modified the configuration file for you! The
	following configuration snippet was inserted:

	  http {
		  ...
		  passenger_root /usr/local/rvm/gems/ruby-1.9.2-p180/gems/passenger-3.0.7;
		  passenger_ruby /usr/local/rvm/wrappers/ruby-1.9.2-p180/ruby;
		  ...
	  }


	server {
	  listen 80;
	  server_name www.yourhost.com;
	  root /somewhere/public;   # <--- be sure to point to 'public'!
	  passenger_enabled on;
	}

El archivo para administrar nginx en /etc/init.d/nginx

	#! /bin/sh

	### BEGIN INIT INFO
	# Provides:          nginx
	# Required-Start:    $all
	# Required-Stop:     $all
	# Default-Start:     2 3 4 5
	# Default-Stop:      0 1 6
	# Short-Description: starts the nginx web server
	# Description:       starts nginx using start-stop-daemon
	### END INIT INFO

	PATH=/opt/nginx/sbin:/sbin:/bin:/usr/sbin:/usr/bin
	DAEMON=/opt/nginx/sbin/nginx
	NAME=nginx
	DESC=nginx
	test -x $DAEMON || exit 0

	# Include nginx defaults if available
	if [ -f /etc/default/nginx ] ; then
			. /etc/default/nginx
	fi

	set -e

	case "$1" in
	  start)
			echo -n "Starting $DESC: "
			start-stop-daemon --start --quiet --pidfile /opt/nginx/logs/$NAME.pid \
					--exec $DAEMON -- $DAEMON_OPTS
			echo "$NAME."
			;;
	  stop)
			echo -n "Stopping $DESC: "
			start-stop-daemon --stop --quiet --pidfile /opt/nginx/logs/$NAME.pid \
					--exec $DAEMON
			echo "$NAME."
			;;
	  restart|force-reload)
			echo -n "Restarting $DESC: "
			start-stop-daemon --stop --quiet --pidfile \
					/opt/nginx/logs/$NAME.pid --exec $DAEMON
			sleep 1
			start-stop-daemon --start --quiet --pidfile \
					/opt/nginx/logs/$NAME.pid --exec $DAEMON -- $DAEMON_OPTS
			echo "$NAME."
			;;
	  reload)
			  echo -n "Reloading $DESC configuration: "
			  start-stop-daemon --stop --signal HUP --quiet --pidfile     /opt/nginx/logs/$NAME.pid \
				  --exec $DAEMON
			  echo "$NAME."
			  ;;
		  *)
				N=/etc/init.d/$NAME
				echo "Usage: $N {start|stop|restart|reload|force-reload}" >&2
				exit 1
				;;
		esac

		exit 0

Darle los permisos de ejecución

chmod +x /etc/init.d/nginx

Subirlo

/etc/init.d/nginx start

###Rails

Para testar

$ rails new blog 
$ cd blog
$ bundle install
$ rake db:migrate
$ rails s

Pueden presentarse problema en el archivo /opt/nginx/conf/nginx.conf con las variables

    server_name  1.2.3.4;
	...
	passenger_enabled on;
	rails_env development; 

Referencias

Instalar passenger
Debian squeeze redmine nginx phusion passenger
Rails en debian

Rails en Apache con Passenger

2011-05-23T00:00:00+00:00

Teniendo instalado rails3 y apache2 vamos a instalar passenger

$ gem install passenger
$ gem passenger-install-apache2-module

passenger irá guiando la instalación, si necesita dependencias y mostrara las lineas que hay que agregar a los archivos de configuración de apache

Please edit your Apache configuration file, and add these lines:
LoadModule passenger_module /usr/local/rvm/gems/ruby-1.9.2-p180/gems/passenger-3.0.7/ext/apache2/mod_passenger.so
   	PassengerRoot /usr/local/rvm/gems/ruby-1.9.2-p180/gems/passenger-3.0.7
   	PassengerRuby /usr/local/rvm/wrappers/ruby-1.9.2-p180/ruby

terminará con un mensaje similar a este

Suppose you have a Rails application in /somewhere. Add a virtual host to your
Apache configuration file and set its DocumentRoot to /somewhere/public:

   <VirtualHost *:80>
      ServerName www.yourhost.com
      DocumentRoot /somewhere/public    # <-- be sure to point to 'public'!
      <Directory /somewhere/public>
         AllowOverride all              # <-- relax Apache security settings
         Options -MultiViews            # <-- MultiViews must be turned off
      </Directory>
   </VirtualHost>

And that's it! You may also want to check the Users Guide for security and
optimization tips, troubleshooting and other useful information:

moverse al archivo de los mods de apache

$ cd /etc/apache2/mods-available

crear el archivo passenger.conf y agregar las lineas antes mostradas

PassengerRoot /usr/local/rvm/gems/ruby-1.9.2-p180/gems/passenger-3.0.7 PassengerRuby /usr/local/rvm/wrappers/ruby-1.9.2-p180/ruby

y passenger.load

LoadModule passenger_module /usr/local/rvm/gems/ruby-1.9.2-p180/gems/passenger-3.0.7/ext/apache2/mod_passenger.so

subir el modulo y reiniciar apache

$ sudo a2enmod passenger
$ sudo /etc/init.d/apache2 restart

crear el archivo de virtualhost

   <VirtualHost *:80>
      ServerName www.yourhost.com
      DocumentRoot /somewhere/public    # <-- be sure to point to 'public'!
      <Directory /somewhere/public>
         AllowOverride all              # <-- relax Apache security settings
         Options -MultiViews            # <-- MultiViews must be turned off
      </Directory>
   </VirtualHost>

Este es un punto importante, public debe ser el directorio public de la aplicación creada por rails.

###Referencias

Rails on debian lenny

Rails en Debian Lenny

2011-05-22T00:00:00+00:00

Pre requisitos

curl
build-essential
zlib1g-dev

##Instalar Instalar rvm como root

$ bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)

Agregarlo a ~/.bash_profile y recargar

$ echo '[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" # Load RVM function' >> ~/.bash_profile
$ source ~/.bash_profile

Instalar ruby

$ rvm install 1.9.2

Este comando me mostraba el siguiente error

rvm install 1.9.2
-su: /usr/local/rvm/scripts/manage: Permission denied

Por lo que le di permisos de ejecución al archivo

$ chmod u+x /usr/local/rvm/scripts/manage

ruby 1.9.2 por defecto

$ rvm use 1.9.2 --default

Instalar gem

$ rvm rubygems current

Instalar rails y bundle

$ gem install rails
$ gem install bundle

##Rails

Probar rails

$ rails new blog 
$ cd blog
$ bundle install
$ rake db:migrate
$ rails s

debería estar visible en localhost:3000

##Problemas frecuentes

sqlite3

Si hay problemas para instalar sqlite-ruby y sus extensiones, hay que actualizar sqlite3 desde el código fuente

$ wget http://www.sqlite.org/sqlite-amalgamation-3.7.2.tar.gz
$ tar xzf sqlite-amalgamation-3.7.2.tar.gz
$ cd sqlite-3.7.2/
$ ./configure
$ make
$ make install
$ gem install rails sqlite3-ruby

###rake

si al hacer

$ rake db:migrate

se presentan problemas con rake 0.9.0 es recomendable modificar el archivo Rakefile

##Referencias

Tocando Mongolab desde rails3

2011-05-15T00:00:00+00:00

Si rails no está instalado

$ gem install rails

Crear una aplicación

$ rails new touchMongoLab --skip-active-record
$ cd touchMongoLab

Editar el archivo Gemfile

# Edit this Gemfile to bundle your application's dependencies.
require 'rubygems'
require 'mongo'
source 'http://gemcutter.org'

gem 'rails', '3.1.0.beta1'
gem "mongo_mapper"

Instalar las gemas necesarias

$ bundle install

Crear el archivo config/initializers/mongo.rb

MongoMapper.connection = Mongo::Connection.new('namexyz.mongolab.com', port )
MongoMapper.database = "dbname"
MongoMapper.database.authenticate('user','passwd')

if defined?(PhusionPassenger)
   PhusionPassenger.on_event(:starting_worker_process) do |forked|
	 MongoMapper.connection.connect_to_master if forked
   end 
end

Crear el modelo en el archivo app/models/user.rb

class User
  include MongoMapper::Document
  key :name
end

Crear un usuario desde la consola

$ rails console
ruby-1.9.2-p180 :006 > user= User.new(:name => "hola mundo")
 => #<User _id: BSON::ObjectId('4dd097464cfad1e8ab000003'), name: "hola mundo"> 
ruby-1.9.2-p180 :006 > user.save()
 => true 

Verificar la existencia del usuario en la db

> db.users.find()
{ "_id" : ObjectId("4dd097604cfad1e8ab000004"), "name" : "hola mundo" }

Referencias

mongoDB && Rails 3 - Getting Started
user.rb

JuanPabloAJ Page

A lightweight way to make agents talk without paying for API usage

The basic idea

The more visible pattern: tmux

The main caveat

In summary

From Agentic Reasoning to Deterministic Scripts

TL;DR

The Overhead of Routine Tasks

A developer before automating

A task maturation cycle

Beyond cost

grep is not enough

What this is not

Conclusion

The silent filter

The Great Filter might not be an event

The Trap of the Shortcut

The Delegation of Synthesis and Linguistic Drift

A Likely Obvious Confession

The noise circuit breaker

An attempt to audit AI agreeability

When to use it

Life as an Accelerator of Chaos

Context, Hallucinations, and How LLMs Are Changing Development

Context size matters

Trust no LLM completely

Change in the development process

In summary

Fail-Fast Testing of Goroutines with WaitGroup and time.After

Distributing Elixir applications with Burrito

References

Elixir and Ecto with SQLite3

References

Distribuir variables con consul/envconsul

Referencias

Phoenix, cambiando nivel de log de una aplicación en ejecución

References

Usando el git hook commit-msg con las id de issue

Phoenix y Plug.RequestId

Compilando gcc/g++ sin permiso root

Referencias

Python y algunos métodos especiales de clase

__ str __

__ call __

Bittorrent en el navegador con webtorrent

Seed

Leecher

Referencias

Testing sobre angularjs con karma

Pre requisitos

angular y angular-mocks

Código angular

Instalación de karma

Configuración de karma

Creando los test y lanzando karma

Referencias

Hooks para npm y bower

Probando paquetes en diferentes versiones de python con tox

Referencias

Nodejs, express y Heroku

pre requisitos

Comenzando con nodejs

Subiendo todo a Heroku

Referencias

Empaquetando y distribuyendo código python con pex

Instalar pex

El primer .pex para distribuir librerías

Todo lo necesario en un .pex

Referencias

Virtualenv y virtualenvwapper

hooks

Referencias

Deployment a openshift con codeship

Lanzando tests de python con grunt

Instalando Grunt

Definición de tareas

Archivos modificados en git

Conclusión

Virtualenv y requirements

str

call