Forem: Ayoze Barrera

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 ☺