Una lista de repositorios no explica qué problema resuelve cada proyecto ni cuánto del trabajo hiciste tú. Organiza tu perfil para que alguien pueda elegir una demostración, entender su alcance y encontrar el código público o una explicación técnica cuando corresponda.
Qué debe contener una ficha de proyecto
Puedes preparar una ficha breve con esta estructura:
Proyecto: agenda para un equipo de pruebas. Problema: coordinar disponibilidad sin intercambiar hojas. Mi aportación: interfaz y API de reservas. Estado: demo con datos ficticios. Prueba: abrir la agenda y crear una reserva de demostración. Límites: no envía mensajes ni admite pagos.
Es un ejemplo ficticio. Sustituye cada dato por el alcance real de tu trabajo. Si participaste en un equipo, distingue implementación, diseño, mantenimiento y decisiones ajenas. Un curso o una plantilla de partida pueden formar parte del proceso; atribúyelos cuando corresponda.
| Destino | Para qué sirve | Qué comprobar |
|---|---|---|
| Demo pública | Probar el recorrido principal | Datos de ejemplo, disponibilidad y estados de error |
| Repositorio público | Revisar implementación | README, instrucciones y ausencia de secretos |
| Caso técnico | Entender decisiones y límites | Autoría, contexto y afirmaciones verificables |
| Contacto | Consultar un proyecto o candidatura | Tipo de oportunidad que estás buscando |
Una demo no debe parecer producción
Indica cuándo utiliza datos ficticios o funciones desactivadas. No pidas a visitantes que introduzcan información personal real para probarla. Si necesitas autenticación, utiliza el mecanismo de demo diseñado para ello; no publiques credenciales de producción ni una cuenta con acceso a otros usuarios.
Abre la demo desde un dispositivo nuevo. Comprueba la acción que anuncias, sus errores y el comportamiento si el servicio no está disponible. Si un proveedor suspende instancias inactivas, explica la espera real o enlaza una grabación identificada como tal. No llames «app disponible» a una captura estática.
Qué hacer con proyectos privados
Un repositorio privado no se vuelve accesible por enlazarlo desde tu perfil. Si no puedes compartir el código, presenta una explicación permitida de tu responsabilidad y el resultado entregado. Elimina detalles internos, datos de clientes y arquitectura sensible que no tengas derecho a publicar.
No inventes métricas de rendimiento o escala. Si muestras una medición, incluye entorno, operación, muestra y fecha. «Responde en 100 ms» sin explicar qué se midió puede describir una prueba local y no la experiencia pública.
Monta el recorrido en mii.page
Usa una tarjeta o enlace de GitHub para el repositorio y otro destino explícito para la demo. No hagas que «Ver proyecto» conduzca indistintamente al código o a una presentación. Añade contexto junto a la captura y coloca el contacto después de la muestra pertinente.
Las integraciones describen las capacidades de los bloques; no equivalen a alojar tu aplicación en mii.page. El perfil reúne tus proyectos, mientras la demo vive en su infraestructura. Para casos más largos puedes enlazar documentación o utilizar páginas adicionales con PLUS.
Antes de enviar el portfolio, prueba todos los destinos sin tu sesión y revisa el móvil. Los clics del perfil muestran interés en un enlace, no uso correcto de la aplicación ni una contratación. Evalúa esas acciones en sus sistemas respectivos.
Preparar un perfil para desarrolladores puede empezar con un proyecto bien explicado. Añade otros cuando demuestren una capacidad diferente que quieras que el visitante valore.
