DEV Community: Ayoze Barrera

Spren: mi workspace de escritorio para programar con agentes

Ayoze Barrera — Thu, 07 May 2026 15:19:39 +0000

Hace poco escribí sobre cómo Claude Code y un CLI propio (tv) me ahorran 15 minutos de secretariado por ticket. Funcionó tan bien que me destapó el siguiente cuello de botella: aunque ya no copiaba títulos a mano ni creaba ramas manualmente, mi pantalla seguía teniendo abiertas siete ventanas distintas. Timeview en una pestaña del navegador para ver tareas, GitLab en otra para ver el pipeline, terminal con Claude Code corriendo, VSCode al lado, notas sueltas en otra app y Gemini cuando quería mejorar algún texto.

El secretariado por ticket lo había resuelto. El context-switching seguía intacto.

Spren es lo que construí para resolverlo: una app de escritorio que junta en una sola pantalla todo lo que mi día a día necesita. Terminal con tabs, estado de git en tiempo real, el panel de tareas de Timeview, las notificaciones, el estado del pipeline en GitLab, mi cuota de Claude, un widget de Gemini para preguntas rápidas, y un par de cosas más (TODO, pomodoro, recordatorio para beber agua). En este artículo te cuento cómo está montada y, sobre todo, por qué cada decisión de diseño es la que es, por si te da ideas para hacer tu propio workspace.

El problema: la app perfecta no existía

Cada uno tiene su forma de trabajar.

Warp es una buena terminal. Raycast es un buen launcher. Notion es buena para notas. Pero ninguna de estas resolvía mi problema: yo no necesitaba otra app más, necesitaba una app menos. Una que sustituyera a varias.

El problema con las soluciones existentes:

Demasiado generales: dashboards corporativos que muestran 200 cosas que no me importan.
Demasiado específicas: cada app hace bien una cosa, y cuando combinas cinco apps tienes el mismo problema de partida.
Sin integración con mi stack real: ninguna se conecta a Timeview ni a mi GitLab self-hosted.

Quería algo hecho a medida de mi flujo. Y la única forma de conseguirlo, era creando a Spren.

En el Cosmere, los spren son entidades que se manifiestan cuando las necesitas y se vinculan a quien las invoca

Las decisiones de stack que importan

Spren es una app de escritorio para macOS hecha con Electron + React + JavaScript. No TypeScript, no Tauri, no nada exótico. Te explico por qué cada elección.

Electron sobre Tauri: Tauri es más ligero pero su ecosistema de Node es menor. Yo necesitaba node-pty para terminales reales, simple-git para integración nativa con git, chokidar para watching del filesystem, y la API de safeStorage de Electron para cifrar tokens. Todo eso son problemas resueltos en Electron y problemas a resolver en Tauri. Para una app personal, era el camino claro.

JavaScript sobre TypeScript: decisión consciente. Iteración rápida, pocos colaboradores, y una codebase que no espero que crezca a 50.000 líneas. El coste de tipar todo no compensa el beneficio. (Si esto fuera una app pública con equipo, sería TypeScript sin pensarlo).

electron-vite como starter: HMR funcional, configuración mínima, no me peleo con webpack ni con builds.

TanStack Query para todo lo que viene de red: cache, retry, refetch, polling adaptativo. Si tu UI hace peticiones HTTP, TanStack Query te ahorra el 80% del código de estado... y me encanta!

xterm.js + node-pty para las terminales: las terminales son reales, con shell, history, ANSI colors, todo. Cada tab tiene su propio proceso pty.

safeStorage para tokens (no keytar): la primera versión usaba keytar y dio problemas con el code-signing. safeStorage de Electron es nativo, sin dependencias compiladas, y suficiente para uso personal. Los tokens viven cifrados en ~/Library/Application Support/spren/secrets.json.

Sin SQLite: lo consideré pero no lo necesité. Para los datos que persisto (TODO items, settings, code projects, mappings) un JSON plano vía un módulo settingsManager es más que suficiente. Si en el futuro quiero historial de pomodoros con gráficas, ahí sí entrará SQLite.

La arquitectura, en una imagen mental

Spren tiene tres procesos, como cualquier app de Electron:

Main process: todo lo sensible vive aquí — credenciales, llamadas HTTP a APIs externas, ejecución de procesos pty, watchers del filesystem, lectura del Keychain.
Preload: un puente tipado vía contextBridge que expone al renderer solo lo que tiene que poder llamar (window.api.timeview.getMyTasks(...) y similares).
Renderer: solo React, solo UI. El renderer nunca toca tokens, nunca lee archivos del usuario directamente, nunca llama a APIs externas. Todo va por IPC.

Esta separación es innegociable y vale la pena explicarla porque es lo que permite que una app así sea segura. Si el renderer pudiera acceder a tokens, cualquier vulnerabilidad de XSS comprometería tus credenciales de Timeview, GitLab y Gemini de golpe. Como no puede, el peor caso es que un script malicioso pida llamadas a tu API, pero nunca verá los tokens.

El layout: cuatro columnas que cuentan una historia

La pantalla principal (HOME) son cuatro columnas verticales:

TERMINAL (flex)  |  GIT (320px)  |  TIMEVIEW (400px)  |  WIDGETS (400px)

El orden no es casual. Cuenta una historia de izquierda a derecha: dónde estoy escribiendo código, qué estado tiene mi código localmente, qué tengo pendiente y qué está pasando en mi sistema de tareas, y herramientas auxiliares.

Columna 1: TERMINAL

Multi-tab con Cmd+T, Cmd+W, Cmd+1..9. Cada tab es un pty real con su propio shell, su propio cwd, su propio history. Cuando hago cd en una tab, el resto sigue donde estaba.

Lo más importante: el cwd activo de la tab actual alimenta a las demás columnas. La columna GIT mira al repo donde estoy. La columna TIMEVIEW resalta el proyecto correspondiente. Si cambio de tab, todo se actualiza.

Columna 2: GIT

Lee el repo del cwd actual con simple-git y vigila cambios con chokidar. Muestra:

Branch actual, ahead/behind, tracking de upstream.
Archivos modificados / staged / untracked, con counters.
**Diff: puedo ver que ha cambiado en cada fichero sin abrir el IDE.
Bloque GITLAB: estado del MR de la rama actual (draft / opened / merged), último pipeline del proyecto (running / passed / failed), con botón "open in browser" que dispara shell.openExternal.

Detalle de UX: el bloque GITLAB solo aparece si hay datos relevantes. Si estoy en main sin MR, no aparece. Cero ruido.

Columna 3: TIMEVIEW

Tres bloques verticales:

MY TASKS: lista paginada de mis tareas, con toggle entre "asignadas a mí" y "sin asignar". Cada item muestra estado, id, título, tags y a quién está asignado. Paginación con scroll infinito vía TanStack Query.
UNREADS COUNTERS: cuatro contadores horizontales (rooms / tasks / notifs / docs) que vienen de de Timeview. Sirven como panorama general.
NOTIFICATIONS: lista de notificaciones, con borde izquierdo rojo destacado para las no leídas.

Click en una tarea me lleva al detalle. Y desde el detalle puedo escribir comentarios para "preparar el terreno" antes de delegar la tarea a Claude. Eso enlaza con el punto siguiente.

Columna 4: WIDGETS

Una pila vertical: TODO, Gemini, Claude Usage, Pomodoro, Water. Cada uno hace una cosa y la hace bien. Aquí los más interesantes:

TODO: items locales con done: false/true, ordenados pendientes-arriba completados-abajo, con botón "clear done" para limpiar de golpe. Persistencia en settingsManager.
Gemini: input + send + área de respuesta con streaming. Para "cambia esta frase a algo más profesional" o "tradúceme esto rápido". Modelo hardcoded a gemini-2.5-flash con tier gratuito. Evita salir a otra pestaña.
Claude Usage: muestra mi cuota actual (5h / 7d / opus) leída del endpoint OAuth interno de Claude Code. Barras ASCII, color verde / ámbar / rojo según umbral. Toggleable porque es un endpoint undocumented.

La pieza que cierra el bucle: "Trabaja en esta tarea"

El flujo completo entre Spren y mi CLI tv es esto:

Llega una notificación de Timeview a la columna correspondiente.
Click en la tarea, se abre el detalle.
Si necesito añadir contexto antes de delegar, escribo un comentario directamente desde Spren (pasa por la API de Timeview).
Cuando estoy listo, click en "trabaja en esta tarea".
Spren abre una tab nueva con el cwd en el code project que elija (los tengo configurados en Settings, uno por repo local), ejecuta claude con un prompt que invoca tv tasks work <id>, y a partir de ahí Claude se encarga del resto del flujo descrito en el artículo anterior.

Un detalle interesante es el selector de code project. Una tarea de Timeview no tiene relación 1:1 con un repo. La tarea es "implementar X feature"; el repo donde se resuelve depende de qué área toques (frontend, backend, desktop, mobile). En mi equipo, una misma tarea puede resolverse en timeview/desktop, timeview/app o timeview/api según corresponda. Y cada developer tiene su propia ruta local para cada repo.

Por eso Spren guarda una lista de "code projects" — pares nombre + ruta local que tú das de alta. Cuando le doy a "trabaja en esta tarea", el botón muestra "trabaja en esta tarea en <nombre>" y, si tengo más de uno, aparece un dropdown para cambiar antes de pulsar. Recuerda mi última elección entre sesiones.

Decisiones de diseño que cambiaron el resultado

Tres elecciones que parecen menores pero hicieron mucho:

1. Cero polling agresivo, refresh inteligente.

Mi primera versión hacía polling cada 30 segundos a Timeview, GitLab y Gemini. Resultado: la app consumía mucho innecesariamente y Anthropic / GitLab / Timeview veían tráfico constante mío.

La versión actual usa refetchInterval adaptativo de TanStack Query. Por ejemplo: el pipeline de GitLab se refresca cada 10 segundos si está running, cada 60 segundos si está en estado terminal. Las notificaciones de Timeview, refresh manual con botón. La cuota de Claude, cada 5 minutos.

Misma sensación de "estoy al día", una décima parte del tráfico.

2. Keep-alive vs unmount.

Spren tiene tres secciones (HOME, TIMEVIEW, SETTINGS). Cuando cambias de sección, la anterior no se desmonta. Sigue viva pero invisible (visibility: hidden + position: absolute). Las terminales siguen corriendo, las queries mantienen su estado, no se pierde nada.

Esto resolvió un bug famoso de xterm: si la columna terminal se desmontaba con display: none, al volver el contenedor tenía dimensiones 0×0, fitAddon.fit() calculaba 5 filas, y el pty perdía scrollback. Visualmente parecía que la terminal se había encogido. La solución de visibility: hidden + position: absolute mantiene dimensiones reales todo el tiempo.

3. Errores tipados en cada cliente HTTP.

Cada integración (Timeview, GitLab, Gemini) tiene sus propios errores tipados con un campo .code: TIMEVIEW_AUTH_FAILED, GITLAB_NETWORK, GEMINI_RATE_LIMIT, etc. Los IPC handlers nunca lanzan a través del bridge — siempre devuelven { ok: true, data } o { ok: false, error: { code, message } }.

Cuando veo un error en Spren, se exactamente qué pasa: "TOKEN no es válido" en lugar de "Network error". Y el código de UI puede mapear cada code a un mensaje específico y a una acción ("ir a Settings", "reintentar", "abrir Claude Code").

Lecciones inespereadas

Tres cosas que no esperaba al construir Spren:

1. El context-switching no se mide en clicks, se mide en pestañas abiertas.

No es solo el coste de cambiar de Timeview a GitLab. Es el coste acumulado de tener N pestañas abiertas todo el día, cada una pidiéndote atención visual aunque estés en otra. Ir cambiando cada cierto tiempo por si no has visto alguna notificación. Reducir mi número total de pestañas de 7 a 2 (Spren + el navegador) tiene un impacto en concentración que no esperaba.

2. Construir tu propia app te obliga a definir tu propio flujo.

Igual que escribir el CLAUDE.md me obligó a documentar reglas implícitas, construir Spren me obligó a definir qué información necesito ver constantemente y cuál no. Resultado: descubrí que no necesitaba ver "todas las tareas" — necesitaba ver "las mías". No necesitaba ver "todos los pipelines" — necesitaba ver "el último del proyecto en el que trabajo". El proceso de decidir qué meter en cada columna fue el ejercicio de productividad más útil que he hecho en mucho tiempo.

3. Una app personal no necesita ser perfecta; necesita ser tuya.

Spren no es accesible. No tiene tests automáticos. No tiene auto-update. No está firmada para distribución. No funciona en Windows ni Linux. Es deliberadamente cruda: tema oscuro hardcoded, fuente monoespaciada para todo, casi sin animaciones, una densidad de información que asustaría a un diseñador.

Precisamente por eso me funciona. Cada decisión está optimizada para mi caso y solo el mío. No hay tradeoffs con casos de uso que no son los míos. Esa es la diferencia entre una app personal y un producto.

Y me encanta abrirla, me encanta saber que todo lo que tengo delante es útil y cada vez que salto al navegador con frecuencia, pienso si puedo incluirlo en Spren, porque yo decido.

Lo que viene

Lo siguiente que he pensado incluir es agent harness: un panel "AGENTS" en Spren donde pueda lanzar varias instancias de Claude Code en modo no interactivo (claude -p) sobre distintas tareas, y monitorizar su progreso desde Spren — qué archivos están tocando, cuánto llevan, si terminaron OK o con error, con notificación nativa cuando completan.

La idea es pasar de "lanzo Claude en una tab y miro su output, tomando decisiones" a "delego cinco tareas en paralelo y vuelvo cuando estén listas". Si funciona, escribo el siguiente artículo, pero para conseguir eso, es necesario darle a los agentes skills, tools y tareas muy claras.

Cierre

No te voy a decir que tienes que construir tu propia app de escritorio. Lo que sí te digo es: si te encuentras con siete pestañas abiertas y notas que pierdes foco saltando entre ellas, el problema no es disciplina personal. Es que tu herramienta de trabajo está fragmentada en N apps diseñadas por personas distintas con prioridades distintas.

A veces la solución no es encontrar la app perfecta. Es construirla.

Si quieres ver el código de Spren, escribeme. Es deliberadamente personal — no busco contribuciones ni mantenimiento — pero las ideas son "robables". Si construyes algo similar, cuéntame!

De ticket a deploy sin tocar nada: cómo Claude Code orquesta mi flujo entero

Ayoze Barrera — Thu, 23 Apr 2026 11:45:08 +0000

Lunes por la mañana. Abro Timeview — mi gestor de tareas — y hay un ticket nuevo: migrar un listado de scroll virtual a paginación tradicional. Hace unos meses, este momento significaba 10 o 15 minutos de fricción antes de poder siquiera pensar en el cambio. Copiar el título, crear la issue en GitLab, etiquetarla, asignarla, crear la rama, abrir el MR en draft, hacer checkout, abrir VSCode. Secretariado.

Ahora escribo tres palabras:

"Trabaja en la tarea 6283"

Me voy a por un café. Cuando vuelvo, la issue está creada en GitLab con las mismas etiquetas que tenía en Timeview, hay un MR en draft enlazándola, la rama está activa en VSCode, y Claude Code me espera con un análisis del componente actual y un plan de cambios. Yo reviso lo que propone, ajusto un detalle, y lo implementa.

No es magia. Es @timeview/cli — un CLI que escribí con Ink y React, el mismo stack que usa Claude Code — y un CLAUDE.md que le enseña a usarlo. En este artículo te cuento cómo funciona y, sobre todo, cuánto tiempo me ahorra de verdad.

El problema: 15 minutos de secretariado por ticket

Mi flujo manual, paso a paso:

Leer el ticket en Timeview
Copiar título y descripción
Ir a GitLab self-hosted, crear la issue, etiquetas, milestone, asignación
Crear la rama desde develop con naming consistente
Abrir MR en draft enlazando la issue
Hacer checkout en el terminal
Abrir VSCode en esa rama
Por fin: empezar a pensar en el problema
Desarrollar
Mergear, checkout a develop, pull, borrar rama local
Volver a Timeview, estado a completado, registrar tiempo, comentario resumen con link al MR

Los pasos 1–7 son 10 o 15 minutos. Los pasos 10–11, otros 5. Son 15 o 20 minutos de overhead por ticket, multiplicado por 3 a 5 tickets al día.

Pero el coste real no se mide en minutos. Cada salto entre Timeview, el navegador, el terminal y el editor rompe el foco. Cuando llegas al paso 8, ya no estás al 100% — estás llegando cansado antes de empezar.

La idea: darle manos al agente fuera del editor

Claude Code ya es un buen pair programmer dentro del editor. La pregunta que me hice fue: ¿y si le doy manos fuera del editor también?

No un plugin, no una integración oficial. Un CLI propio — tv — que habla con Timeview, con GitLab y con git local. Claude Code tiene permiso para invocarlo. Le explico el flujo en un CLAUDE.md y el agente decide cuándo leer la tarea, cuándo abrir el MR, cuándo mergear, cuándo actualizar Timeview.

Yo solo apruebo.

El flujo, seis fases

Todo empieza con una frase: "Trabaja en la tarea 6283". A partir de ahí, el agente ejecuta esto:

Fase 1 — Leer la tarea

tv tasks work 6283 --status

Devuelve un JSON con título, notas, estado, etiquetas y MR vinculado si existe. Claude lo digiere.

Hay una regla de esta fase que tardé un par de iteraciones en dejar bien: las notas tienen prioridad sobre el título. Un ticket se abre con un título rápido y luego la conversación lo refina en los comentarios. Esa regla vive en el CLAUDE.md y evita que el agente trabaje sobre un enunciado obsoleto.

Fase 2 — Iniciar el trabajo

tv tasks start 6283

Un único comando que:

Crea la issue en GitLab self-hosted copiando las etiquetas desde Timeview (bugfix, feature, new…)
Abre el MR en draft y lo enlaza a la issue
Crea la rama con naming consistente
Hace checkout automático

El detalle de las etiquetas parece cosmético pero no lo es. Cuando preparo una release, el changelog se genera agrupando por etiqueta. Mantenerla sincronizada entre Timeview y GitLab significa que clasifico el ticket una sola vez, al crearlo, y la clasificación viaja sola hasta las release notes.

tv tasks work <id> --status   # Ver estado actual de tarea + MR
tv tasks comment <id> <texto> # Añadir nota por ID (desde cualquier rama)
tv tasks state <id> <stateId> # Cambiar estado por ID (desde cualquier rama)
tv tasks new --title <título> # Crear nueva tarea en Timeview + GitLab
tv notes <texto>              # Nota en la tarea de la rama actual
tv spend <minutos>            # Registrar tiempo en la tarea actual
tv status                     # Ver contexto: proyecto, rama, tarea, MR

Fase 3 — Analizar con el código delante

Aquí pasa algo que no diseñé consciente, pero que resultó clave: Claude propone los cambios después del checkout, no antes. Con la rama activa, puede leer los archivos reales del repo y solo entonces me presenta:

Qué archivos va a tocar
Qué cambios propone y por qué

Si le pidiera el plan antes del checkout, sería un plan a ciegas sobre suposiciones. Con el código delante, es un plan sobre hechos. Yo apruebo o corrijo.

Fase 4 — Implementar

Claude Code haciendo su trabajo habitual: edita el código según lo acordado. Nada nuevo aquí; lo relevante es que llega con todo el contexto del ticket ya cargado, no con un prompt genérico que yo haya tenido que improvisar.

Fase 5 — Commit, push, merge

git add <archivos>
git commit -m "refactor: migrar listado a paginación"
git push origin <rama>

tv tasks work 6283 --merge

El --merge es mi favorito. Mergea el MR, cierra la issue de GitLab, hace checkout a develop, pull, borra la rama local y limpia la referencia del config. Cinco pasos aburridos en uno.

Fase 6 — Cerrar la tarea

tv tasks comment 6283 "Añadida paginación a la página de noticias. Cambiado de listado virtual con filtrado client-side a query paginada server-side. Destacados se obtienen en query separada. Búsqueda y filtro por tags resetean a página 1. Componente Pagination integrado. MR: <url>"
tv tasks state 6283 completed

Comentario con el resumen, URL del MR, estado a completado. Fin del ciclo.

La arquitectura, en una imagen mental

Tres piezas:

@timeview/cli (invocado como tv): el CLI propio. Hecho con Ink + React — el mismo stack que usa Claude Code. Wrappea la API de Timeview, la API de GitLab y los comandos de git locales. Una sola responsabilidad: traducir intenciones de alto nivel ("trabaja en la tarea 6197") en las llamadas concretas que hay debajo.
Claude Code: con permisos para ejecutar tv y git.
CLAUDE.md del proyecto: el runbook del agente. Describe el flujo, los comandos, el orden y las reglas que no puede romper (como la de "las notas tienen prioridad").

Autenticación local: nada que desplegar

Un detalle importante si otro dev del equipo quiere usarlo: la autenticación es local. Para Timeview, el usuario introduce sus credenciales una vez y el CLI guarda el token. Para GitLab, un access token personal. Todo en ~/.timeview/config.json.

No hay servidor intermedio, no hay credenciales compartidas, no hay infraestructura que montar. Un compañero instala el paquete, se autentica con lo suyo y tiene exactamente el mismo flujo en su máquina. Esa es la diferencia entre una herramienta personal y una que puede adoptar el resto del equipo sin pedir permisos ni levantar nada.

Los números

Separo por tipo de tarea porque el ahorro es muy distinto.

Bug

Antes: ~10 min de setup antes de empezar + 20–60 min de resolución = 30–70 min totales
Ahora: 1–5 min leyendo el ticket en Timeview + 1–2 min revisando el plan + ~1 min de ejecución = 3–8 min totales

Ahorro por bug: entre 25 minutos y una hora larga.

Feature nueva

Antes: 4–16 horas según tamaño
Ahora: hasta 1 hora siendo precavido con las pruebas

Ahorro por feature: varias horas. En las más grandes, casi un día entero.

Caso real: la tarea 6283 de este artículo

Las capturas que ves en este post son de una tarea real — el ticket #6283, migrar un listado de scroll virtual a paginación tradicional. La completé en 5 minutos de trabajo efectivo.

Los otros 10 minutos que me llevó la sesión los gasté recolocando datos de prueba y esperando el momento adecuado para pulsar "captura". El cronómetro no miente: el trabajo en sí fueron 5 minutos de punta a punta.

Dónde paro de prometer

Estas cifras son estimaciones basadas en mi experiencia, no medidas cronometradas. Comparan cómo trabajaba antes y cómo trabajo ahora sobre tickets parecidos. El ahorro real será algo menor en los casos buenos y algo mayor en los malos, pero el orden de magnitud es sólido.

Tampoco incluyen el tiempo de pensar, revisar y decidir. Y eso es lo que quería: el agente se come el secretariado, no el diseño.

Lo que no aparece en los números pero se siente todos los días es el fin del context-switching. Antes saltaba varias veces por ticket entre cuatro ventanas. Ahora el único salto es leer el plan y aprobarlo. No sale en el cronómetro, pero al final del día queda más energía.

Lecciones no obvias

Tres cosas que no esperaba al construir esto:

1. El cuello de botella no eran los minutos, era el foco. Lo pensaba como un problema de tiempo; resultó ser un problema de atención. Eliminar los saltos entre herramientas tiene más impacto que los minutos que ahorra.

2. Dar manos al agente te obliga a documentar tu propio flujo. Para que Claude supiera qué hacer, tuve que escribir el CLAUDE.md. Para escribirlo, tuve que explicitar cosas que hacía por intuición y nunca había puesto por escrito. Reglas como "las notas tienen prioridad sobre el título" no existían en ningún sitio hasta que tuve que enseñárselas a una máquina. El proceso de documentar, por sí solo, ya mejoró el flujo.

3. Las etiquetas compartidas cierran el ciclo hasta el changelog. Que la etiqueta viaje de Timeview a GitLab y de ahí a las release notes parece un detalle. No lo es: clasificar el ticket una sola vez y ver esa clasificación llegar intacta al documento que lee el cliente es uno de los beneficios más infravalorados del sistema.

Una nota antes de seguir: este patrón no es exclusivo de Claude Code. Cualquier agente con permisos de shell podría invocar un CLI así — Cursor, Aider, Codex CLI, lo que uses. Lo interesante no es qué agente eliges, sino que dejes de usarlo solo dentro del editor.

Qué viene después

Browser-agent. Quiero que Claude pruebe él mismo los cambios de UI antes de pedirme review: que abra el navegador, cargue la pantalla, haga clic entre páginas, verifique que la paginación responde como debe. Hoy esa parte todavía la hago yo. Cuando esté, el bucle entero — desde el ticket hasta el "funciona de verdad" — estará cerrado sin que yo tenga que abrir una sola pestaña.

Cierre

No voy a decirte que esto es el futuro del desarrollo. No lo sé, cada día que pasa, algo cambia. Lo que sí sé es que el desarrollo tiene un porcentaje sorprendentemente alto de trabajo de secretario: mover tickets, crear ramas, rellenar formularios de estado, escribir comentarios resumen. Ese trabajo nunca me hizo mejor ingeniero.

Darle ese trabajo a un agente no me convierte en un dev mejor. Me convierte en un dev que pasa más minutos del día pensando en código y menos rellenando casillas.

Con eso me vale.

Como crear una guía de estilo con Figma

Ayoze Barrera — Sun, 01 Mar 2020 14:54:29 +0000

La imagen de un proyecto es súper importante, y va a influenciar al usuario directamente para que siga utilizando la aplicación y la identifique rápidamente o para que salga huyendo confuso y asustado.

Cuando trabajan varios diseñadores o programadores en un proyecto muy grande, lo mejor es crear una guía de estilo para que nadie se salga del guión y acabe diseñando algún componente fuera de tono en comparación al resto.

Para evitar esto, existen las guías de estilos.

Así que cuando llega alguien nuevo al proyecto, le podemos dar la bienvenida con una bonita guía de estilos.

Que es una guía de estilo

Una guía de estilos, como bien dice su nombre, es una guía para saber que materiales se deben de usar para seguir construyendo, como por ejemplo, que tipografía usar en los títulos, cuáles son los colores principales de la aplicación, que sombras utilizar, y cualquier aspecto que queramos definir.

En nuestra empresa, hemos creado una guía de estilos muy simple para una aplicación que llevamos desarrollando cuatro años: Fleetview.

Nuestra guía de estilo ha servido a otros compañeros para poder crear manuales y vídeos sobre la aplicación.

Hemos decidido hacerla en Figma ya que es una aplicación increible y nos permite exportar cualquier elemento en vectorial.

Que elementos añadir

Podemos añadir los elementos que consideremos más importantes, y en nuestro caso fueros los siguientes:

Branding

Los logos de la aplicación y sus variantes. Cualquier otra variante que no esté aquí definida no estará permitida.

Paleta de colores

Colores principales y secundarios.

Tipografía

La tipografía que usamos en el logo, en los títulos y en los párrafos. De cada uno de ellos definimos la familia, peso, tamaño, altura de línea, espaciado entre letras, color y un ejemplo.

Iconos

El sistema de iconos que usa la aplicación. Si hay que diseñar un icono nuevo, debe tener el mismo tamaño y mismo el grosor en las líneas.

Componentes

Los componentes más importantes que utilicen algunos de los aspectos anteriores.

Y todo junto pues se vería así:

Hasta la próxima batalla!

🖖

Mapeando tus movimientos con React y Leaflet

Ayoze Barrera — Mon, 24 Feb 2020 12:12:45 +0000

Hoy en día usamos mapas para todo… para buscar direcciones, consultar cuál es el mejor camino a tomar para llegar a un punto en concreto, para promocionar un local, o simplemente viajar desde casa (asi es, he visto a youtubers que se pasan horas dando vueltas por paises gracias a los mapas… y hacen visitas!)

Pues por ese motivo vamos a ver cómo podemos hacer un mapa con nuestros movimientos.

Moves app

Moves

Para registrar los movimientos, aunque hay otras, he usado la aplicación moves.

Moves se ejecuta en segundo plano y nos permite importar tus movimientos en diferentes formatos, y uno de ellos es geojson.

Para empezar nos vamos a la página web de moves. Allí nos permitirá importar lo registrado desde nuestro dispositivo.

Configuración

Lo primero será instalar los paquetes de leaflet y react-leaflet:

$ npm -i S leaflet react-leaflet

React-leaflet lo que hace es cargar componentes pero sin renderizar nada, simplemente usa los métodos de leaflet en el lifecycle del componente.

Podríamos conseguir nuestro mapa sin react-leaflet pero lo he usado anteriormente y ayuda mucho.

El mapa

Ya estamos listos para empezar así que lo primero será importar los paquetes que vamos a necesitar.

import { Map, TileLayer } from 'react-leaflet';
import L from 'leaflet';

De momento solo he importado dos componentes de react-leaflet: Map y TileLayer. Esto es lo básico que necesitarás para mostrar un mapa.

También he importado leaflet porque vamos a usar el método circleMarker para poder tratar los puntos de los geojsons de nuestros datos.

Map

Capa principal del mapa que controla el zoom, bordes y el centro. Lo que vayamos a representar en el mapa, lo pasaremos como hijos.

TileLayer

Componente que se encargará de mostrar los tiles correspondientes en base al zoom y al centro.

Este componente necesita la propiedad url que será al montarse.

Para este ejemplo, voy a usar un mapa en blanco y negro, pero puedes encontrar mas urls aquí.

https://stamen-tiles-{s}.a.ssl.fastly.net/toner/{z}/{x}/{y}{r}.png

Ah! Antes de poder usar nuestro mapa, necesitaremos importar el css de leaflet, que puedes encontrar en su apartado de descargas.

Configurados estos dos componentes, deberíamos de tener algo muy parecido a esto:

Tanto rollo para tener un mapa vacío?

Calma… ahora viene lo bueno 😁

Nuestros movimientos

Moves, aparte de ofrecerte muchos formatos, también te separa los datos en movimientos diarios, semanales, mensuales, anuales y por último, todos en un mismo fichero. Yo voy a utilizar mis lugares visitados separados por años. En concreto los de 2016, 2017 y 2018.

Para ello voy a usar una capa de GeoJSON de leaflet, que como no, también lo tenemos como componente en react-leaflet:

import { Map, TileLayer, GeoJSON } from 'react-leaflet';

El siguiente paso sería importar los datos de nuestros movimientos:

import places2016 from './data/places_2016.js';
import places2017 from './data/places_2017.js';
import places2018 from './data/places_2018.js';

Después, tenemos que usar el componente GeoJSON como un children más en nuestro component Map:

<Map style={styles.map} center={props.center} zoom={props.zoom}>
  <TileLayer url={props.url} />
  <GeoJSON
    data={places2016}
  />
</Map>

Además de pasarle los datos a la capa GeoJSON, el componente necesita la propiedad style, que es una función que usará internamente para aplicar el style que queramos a cada elemento de nuestro geojson:

function getStyle(feature, layer) {
  return {
    weight: 1,
    opacity: 1,
    color: '#000'
  }
}

Cuidado! La función anterior solo te servirá para elementos que NO sean de tipo Point.

Dentro de mis geojsons, solo tengo elementos de tipo Point, asi necesitaré utilizar una propiedad extra: pointToLayer.

const geojsonMarkerOptions = {
  radius: 4,
  fillColor: "#EE4266",
  color: "#000",
  weight: 0,
  opacity: 1,
  fillOpacity: 0.4
}

function pointToLayer(feature, latlng) {
  return L.circleMarker(latlng, geojsonMarkerOptions);
}

En mi caso, el componente GeoJSON se queda de la siguiente manera:

<GeoJSON
  data={places2016}
  pointToLayer={pointToLayer}
/>

Ya casi terminamos!

Como voy a representar tres geojsons diferentes, y quiero representarlos con diferentes colores, tengo que crear tres funciones diferentes de pointToLayer

<Map style={styles.map} center={props.center} zoom={props.zoom}>
  <TileLayer url={props.url} />
  <GeoJSON
    data={places2016}
    pointToLayer={pointToLayer2016}
  />
  <GeoJSON
    data={places2017}
    pointToLayer={pointToLayer2017}
  />
  <GeoJSON
    data={places2018}
    pointToLayer={pointToLayer2018}
  />
</Map>

Este es el resultado final del componente:

Voilá, nuestro mapa estaría listo:

Nos vemos en la próxima batalla!

🖖🏼

Cómo crear un paquete de Node

Ayoze Barrera — Fri, 14 Feb 2020 10:02:24 +0000

Cuando vamos a crear un proyecto nuevo, nos pasamos una gran parte del tiempo copiando y pegando código de antiguos proyectos… ¿para que vamos a reinventar la rueda?

El nacimiento de nuestra librería personal

Para empezar, creamos una carpeta con el nombre del paquete, yo lo llamaré capua-package-sample, y dentro ejecutamos el siguiente comando de npm para generar nuestro package.json:

$ npm init --yes

Este comando te creará un package.json básico extrayendo información de la carpeta donde se ejecuta.

Deberíamos de tener algo parecido a esto:

{
  "name": "capua-package-sample",
  "version": "1.0.0",  
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "Ayoze Barrera",
  "license": "ISC"
}

Fichero principal

Ahora que tenemos el package.json, necesitamos crear el fichero que se usará cuando se importe nuestro paquete. Este fichero se especifica en la propiedad main, y por defecto es index.js.

En este fichero, para nuestro ejemplo, exportaremos cualquier cosa, como por ejemplo una función sencilla:

exports.myAwesomeFunction = function () {
  return 'b' + 'a' + + 'a' + 'a';
}

Esta función debería de devolver «baNaNa».

Ahora solo faltaría subirlo a nuestro repositorio o publicarlo en npm!

Instalando nuestro paquete

Si has publicado el paquete sabrás como instalarlo, pero si no lo has hecho, quizás no sepas… pues es muy fácil, solo tienes que ejecutar el siguiente comando:

$ npm install <git-service>:<git-user>/<repo-name>

Si no rellenamos el servicio, buscará en github por defecto, pero soporta muchos otros… para saber más mira la documentación de npm install.

$ npm install -S github:capua/capua-package-sample
└── capua-package-sample@1.0.0  (git://github.com/capua/capua-package-sample.git#e5903fa2a1e4ee1e751a53fb0aa420cba07e949a)

Y ya solo tendríamos que importarlo:

import { myAwesomeFunction } from 'capua-package-sample';

myAwesomeFunction(); // => "baNaNa"

Nos vemos en la próxima batalla!

Mapeando con Javascript

Ayoze Barrera — Mon, 10 Feb 2020 16:56:11 +0000

Este post fue publicado originalmente en julio del 2015

Hablaremos de Mapbox y aprenderemos a manejar y reproyectar nuestros datos geoespaciales con QGIS, para añadirlos a un mapa estilizado por nosotros.

El mundo de la cartografía es enorme, y puedo decir que me queda mucho por descubrir. Este artículo es parte de la experiencia que he obtenido en un proyecto reciente.

Antes de trastear con nuestros datos geoespaciales, primero necesitamos nuestro lienzo, el mapa.

Mapbox es una plataforma para crear y usar mapas, y está basada en la librería de LeafletJS. Tiene un buen abanico de herramientas, datos y servicios que se conectan muy bien entre sí, por ejemplo, podemos estilizar un mapa con Mapbox Studio, una aplicación que usa CartoCSS para darle vida a nuestro mapa junto con otras utilidades, para luego conectarlo con la librería Mapbox.js para jugar con nuestros datos vía Javascript.

Y eso amigos, en resumen, es lo que haremos hoy 🤗.

El plan starter nos permite estilizar un mapa y guardar 100mb de datos en los servidores de Mapbox. Si subes los datos a los servidores de ellos, luego podríamos usarlos en Mapbox Studio para estilizarlos junto a nuestro mapa, pero en nuestro caso no lo haremos así, lo haremos con js usando geojsons a través de la librería Mapbox.js.

Tarifas de Mapbox

Mapbox Studio

Mapbox Studio está disponible para OS X, Windows y Linux. Incluso tenemos acceso a su código en github.

Hablemos de sus posibilidades.

Datos

Gran Canaria con la vista previa a la izquierda y vista de datos a la derecha

Nos permite añadir nuestros propios geodatos, además de todos los datos que nos ofrece por defecto, como calles, terreno, satélite… con la posibilidad de controlarlos y de inspeccionarlos a nuestra merced.

Estilo

Podemos darle colores y formas a nuestro mapa gracias al preprocesador de estilos CartoCSS desarrollado por Mapbox. También tenemos acceso a una coleccion de iconos llamados Maki que están optimizados para tres tamaños diferentes y a un catálogo de tipografías con la posibilidad de añadir la nuestra propia.

Las posibilidades de la aplicación son mayores, pero con esto nos bastará para cumplir con el objetivo del artículo.

Empecemos

Vamos a crear nuestro mapa.

Nuevo proyecto en Mapbox Studio.

Cuando vamos a crear un nuevo proyecto, tenemos la posibilidad de elegir un mapa o de añadir datos propios para luego usarlos en algún mapa. En nuestro caso, como nuestros datos irán de la mano con js, vamos a experimentar un poco con CartoCSS. Elegiré el de Run, Bike and Hike.

Lo primero que vemos al elegir el mapa es que además de éste, tenemos la hoja de estilos a nuestra derecha separadas en varios ficheros. En estos ficheros tenemos todo el estilo que forma Run, Bike and Hike y será el que modifiquemos para conseguir nuestra “obra”.

Empezaré por cambiarle el color al mar. Para cambiar el aspecto de un elemento del mapa, debemos saber su identificador. Simplemente tenemos que ponernos en la vista de datos haciendo click en el botón que está a la derecha del zoom.

En esta vista, si hacemos click en algún punto del mapa, aparecerá un tooltip con la información de todos los datos de ese lugar. También podemos irnos a la sección Layers (Capas) del menú lateral izquierdo, el cual nos desplegará una ventana con la lista de todos los elementos que tenemos actualmente en nuestro mapa. Si os fijáis en la parte superior de esta ventana, veremos que los datos están bloqueados. Eso se debe a que se necesita un orden específico de capas para que el mapa funcione bien y en el caso de que quisiéramos añadir datos nuestros no podríamos, a menos que editemos el fichero project.yml y borremos el listado de capas. En nuestro caso no necesitamos desbloquearlo.

Una vez que sepamos el identificador del agua tenemos que identificarlo en nuestro proyecto. Lo encontraremos en el fichero bg.

#water {
  polygon-fill: @water; //relleno del polígono
  polygon-gamma: 0.5; //gamma, para reducir huecos entre polígonos
  ::shadow { //symbolizer
    polygon-fill: @water; //otro relleno
    opacity:0.9; //opacidad
    comp-op: screen; //operación de composición. efecto screen
    image-filters: agg-stack-blur(10,10); //sombra del agua(costas)
  }
  [zoom>12] { //estilo para zoom superior a 12
    polygon-gamma: 0.75; 
  }
}

Las posibilidades son muy amplias: cambiar bordes, sombras, añadir patrones, aplicar efectos entre los elementos, pero no me complicaré mucho (ya me luciré mas tarde jaja) así que simplemente cambiaré algunos colores y la tipografía. Tal vez en algún artículo escriba sólo de CartoCSS y sus posibilidades, pero de momento podéis consultar la documentación para aprender todo lo que ofrece CartoCSS.

Mapa antes y después del cambio

Una vez tengamos nuestro mapa, tenemos que subirlo al servidor de Mapbox para generar un ID el cual usaremos más tarde porque de momento, tenemos que hablar un poco de los datos geoespaciales.

Datos geoespaciales

Los datos geoespaciales o datos espaciales sirven para representar features (puntos, líneas o áreas) en una superficie. Estos datos pueden tener una tabla de datos con información.

Para poder tratarlos, usaremos un GIS (Geographic information system) donde podremos hacer una infinidad de cosas relacionadas con la geografía, como administrar los datos de cada punto, representar los datos o cambiarles la proyección, por nombrar algunas.

El GIS que usaremos se llama QGIS, de código abierto, el cual aparte de tener las herramientas típicas de un sistema geográfico, tiene una buena comunidad de plugins muy interesantes. Ya le dedicaremos un artículo en el futuro.

Hagamos lo que hagamos con nuestros datos, lo que nos interesa es, recordad, un fichero geojson.

En el caso de que no tengamos a mano ningún fichero, podéis generar uno entrando en geojson.io, un editor a tiempo real, con la posibilidad de agregar features fácilmente y con muchas opciones para la exportación. También lo uso para visualizar ficheros y saber si están bien proyectados.

En la siguiente parte cargaremos nuestros datos en un mapa con la librería de javascript mapbox.js o leaftlet.js.

Github también tiene un buen API de mapas. Subid algún fichero a Gist y lo podréis comprobar. Éste es el mío

Lo vamos a dejar por aquí!

En la siguiente parte cargaremos nuestros datos en un mapa con la librería de javascript de mapbox o leaftlet.

🌎

Que comiencen los juegos

Ayoze Barrera — Mon, 03 Feb 2020 16:39:11 +0000

Capua es un blog de desarrollo & experiencia de usuario.

Tras una lucha “sangrienta” para conseguir el nombre de usuario capua en GitHub, ya no tenemos excusas para compartir nuestras locuras. Hace mucho tiempo que teníamos en mente este proyecto, pero al fin nos hemos puesto las pilas.

Capua

Por contar un poco de donde procede el nombre del blog, nos gusta la temática romana, y Capua, antigua capital de Campania, tuvo el primer anfiteatro del mundo romano, donde los gladiadores dominaban la arena.

Los desarrolladores, desde siempre, tienen que reciclarse diariamente pues cada día salen nuevas tecnologías u otras se van actualizando, y para conseguir eso creemos que debemos ser como los gladiadores de la antigua Roma, capaces de enfrentarnos a cualquier bestia que se nos ponga por delante.

Si has visto o si eres fan de spartacus, es posible que te suene todo esto de Capua. También te será familiar nuestro grito de guerra:

“Por Capua!”

Nuestra intención es compartir artículos interesantes de las cosas que hemos ido aprendiendo o que nos han enseñado a lo largo de los diferentes proyectos que hemos realizado.

Quiénes somos…

Ayoze BarreraFollow

Javascript freak 🤓 · Loving React ⚛· Fixie user 🚲 · Patriots fan 🏈!

Mario Blas 🇮🇨Follow

Web app developer • JavaScript • React • Expo

…y donde estamos

Las Palmas, Canary Islands, Spain ☺

Contenido

Nuestros artículos se centrarán principalmente en dos campos, desarrollo y diseño. No descartamos hablar alguna vez de tecnología… o algún juego, quien sabe!

Desarrollo

Estamos constantemente desarrollando aplicaciones con frameworks, servicios y plataformas de última hora.

Nuestro mundo gira principalmente en torno a Javascript y todas las tecnologías relacionadas con éste lenguaje.

Actualmente, nuestra librería principal es React.

Diseño

Le damos mucha importancia al diseño de la experiencia de usuario (UX). UX es la calidad de experiencia que tiene un usuario cuando usa un diseño concreto.
Algunas tecnologías de las que usamos nos permiten tener mayor flexibilidad en nuestra aplicación para así conseguir una UX más elaborada…

Probablemente hablemos de todo un poco, pero intentando no aburrir ☺.

Objetivos

Somos algo novatos en el mundo de los blogs, pero intentaremos estar a la altura.

Unos de los objetivos que pretendemos conseguir con Capua es crecer como redactores. No queremos tener un blog de textos copiados, y puestos para rellenar simplemente por tener muchos artículos y visitas.

Le dedicaremos tiempo a cada artículo para intentar conseguir lo mejor de nosotros mismos. Y eso nos ayudará a conseguir otro de nuestros objetivos, la creación de nuestro propio imperio, nuestro lugar. Tenemos muchas ideas que llevamos guardando mucho tiempo.

Ya veremos hacia donde crece esto y con quien.

Dicho esto… Capua queda inaugurado!

Hasta el próximo artículo ☺