Uncategorized - Desarrollo Web en Hidalgo y CDMX | Ferredia https://ferredia.com ¿Buscas empresas de desarrollo web en Hidalgo o crear páginas web profesionales? Soluciones seguras, auditables y orientadas a resultados. Mon, 27 Apr 2026 03:22:06 +0000 es hourly 1 https://wordpress.org/?v=7.0 https://ferredia.com/wp-content/uploads/2025/11/icono3-150x150.png Uncategorized - Desarrollo Web en Hidalgo y CDMX | Ferredia https://ferredia.com 32 32 26 años construyendo la web (y lo que la IA no puede resolver por mí) https://ferredia.com/26-anos-construyendo-la-web-y-lo-que-la-ia-no-puede-resolver-por-mi/ https://ferredia.com/26-anos-construyendo-la-web-y-lo-que-la-ia-no-puede-resolver-por-mi/#respond Mon, 27 Apr 2026 03:18:01 +0000 https://ferredia.com/?p=461
En 1999, cuando publiqué mi primera página web para un cliente, el panorama no se parecía en nada a lo que enseñan los tutoriales actuales. HTML5 no existía, los navegadores no compartían reglas comunes y, aunque CSS ya tenía una especificación oficial, su implementación era tan divergente entre Netscape Navigator e Internet Explorer que, en la práctica, era como si no existiera. Para que un sitio se visualizara de forma aceptable, no bastaba con escribir código ordenado: había que detectar el user-agent, aislar Netscape de IE6 y, en muchos casos, ajustar la lógica en el servidor para forzar una salida que el navegador no rechazara.
 
El resultado era lo que se conocia como  código espagueti: estilos incrustados directamente en etiquetas con style="..." o atributos como bgcolor, align y valign; scripts mezclados con la estructura; y cuando necesitabas replicar un bloque en otra página, la solución era Ctrl+C, Ctrl+V. Pero eso no era desorden por falta de criterio, era la única forma pragmática de que algo funcionara en una plataforma que aún no había definido sus propias reglas.
 

1. 1999–2005: Cuando la plataforma obligaba a mezclarlo todo (y por qué el SAT requería IE6)

Quizás el recuerdo más fiel de esa época no es el código, sino la realidad operativa de mantener sistemas críticos. Yo mismo pasé horas configurando Internet Explorer 6, ajustando zonas de seguridad y instalando complementos de ActiveX solo para que la página del SAT procesara un archivo XML o validara la FIEL. Si no lo hacías, el sitio simplemente fallaba en silencio. No era que la pagina del SAT fuera “mala”; era que la web aún no tenía estándares para criptografía en el navegador, ni APIs para manejo seguro de certificados digitales, ni siquiera un fetch() o WebCrypto. La única vía estable era depender del motor de Microsoft y sus controles propietarios.
 
Limitar la compatibilidad a un solo navegador no era una elección de diseño. Era una decisión de viabilidad. Depurar para Netscape 4, IE5 e IE6 simultáneamente significaba mantener tres ramas de código, usar document.all en un motor y document.layers en otro, y pelear con un box-model que interpretaba padding y border de forma distinta era un caos. No existían herramientas de depuración, no había transpiladores, ni polyfills, ni siquiera un estándar de referencia estable. Si el navegador no soportaba algo, el desarrollador asumía el costo de la inconsistencia.
 
El código spaghetti, los estilos inline y la duplicación manual no eran vicios: eran la única forma de que un sistema no colapsara en producción cuando el tiempo de entrega era finito y el presupuesto no cubría tres equipos de testing. La web era un territorio en disputa, y nosotros éramos los topógrafos improvisados.
 

2. 2006–2015: La separación que nos dio aire

La llegada de CSS2/3 usable, la normalización parcial del DOM en los navegadores y la popularización de include/require en PHP cambiaron la ecuación. Por primera vez, podías separar presentación, lógica y contenido. Un archivo .css externo, una carpeta /js/, y de pronto un cambio visual se reflejaba en decenas de páginas sin tocar el HTML. Aparecieron los primeros resets, los grids manuales basados en float, y los patrones de layout que intentaban simular lo que hoy resuelven flexbox y grid.
 
La web dejó de ser una colección de documentos sueltos para convertirse en un sistema. Pero la abstracción aún era manual: si querías un modal, un calendario o una validación de formularios, lo escribías desde cero o adaptabas scripts de foros y repositorios tempranos. La productividad mejoró, pero la superficie de error seguía siendo amplia. Cada dependencia externa era un punto ciego hasta que no la auditaras línea por línea.
 

3. 2015–2023: Frameworks y estandarización, el costo invisible

Cuando el ecosistema maduró, llegaron las herramientas que normalizaron la entrega de interfaces profesionales. Bootstrap no solo trajo una rejilla responsiva; estandarizó la forma en que equipos pequeños colaboraban, reduciendo la fricción entre diseño, frontend y backend. SweetAlert reemplazó los alert() bloqueantes por diálogos accesibles, personalizables y consistentes. FullCalendar abstrajo semanas de lógica de renderizado, navegación por fechas y gestión de eventos en una API predecible.
 
El beneficio fue innegable: velocidad de entrega, coherencia visual y menor carga cognitiva. Pero el costo, que muchos ignoraron durante años, fue estructural: dependencias pesadas, superficie de ataque ampliada, y la tentación de cargar “por si acaso” funcionalidades que nunca se usaban. Mientras tanto, el navegador maduraba en silencio. flexbox, grid, <dialog>, constraint validation API, :has(), @layer y variables CSS resolvieron directamente problemas que antes justificaban librerías de muchas lineas.
 
Hoy, muchas de esas herramientas siguen siendo válidas, pero su uso debe ser estratégico, no automático. Bootstrap acelera un dashboard interno; SweetAlert mejora flujos críticos de confirmación; FullCalendar resuelve gestión compleja de turnos. Pero para un catálogo estático, un formulario de contacto o un hero informativo, los estándares nativos ya cubren el 80% del caso con menos código, mejor rendimiento y menor superficie de mantenimiento.
 

4. 2024–2026: La IA no reemplaza el criterio, solo acelera la ejecución

Hoy, herramientas de IA generan componentes, validaciones y layouts en segundos. Pero la web sigue siendo un sistema de restricciones, no un lienzo infinito. La IA no aplica hashes de integridad (integrity) por defecto, no configura Content-Security-Policy restrictivas, no audita dependencias comprometidas, ni prioriza la simplicidad estructural sobre la acumulación de features. Tampoco responde por el mantenimiento a 3 años, la compatibilidad con navegadores legacy o el impacto en Core Web Vitals.
 
Mi rol ya no es “escribir más rápido”. Es verificar, estructurar y retirar lo que sobra. Por eso integro scripts ligeros en Python que validan cabeceras, hashes y recursos externos, por eso prefiero soluciones nativas cuando cubren el caso y por eso documento límites, no solo ventajas.
 
La IA es un multiplicador de productividad, pero la responsabilidad de la sigue siendo humana. Un prompt bien redactado no sustituye un código de manifiesto de integridad, una CSP explícita ni una política de actualización de dependencias.
 

Conclusión: la evolución no es descarte, es criterio

No abandoné los estilos inline porque fueran “malos”. Los abandoné cuando @layer y variables CSS resolvieron el mismo problema con menos acoplamiento. No rechazo Bootstrap por principio; lo rechazo cuando añade 2500 lineas para un bloque que se resuelve con min-height: 100dvh y object-fit. Y no confío ciegamente en la IA, porque la velocidad de generación no equivale a estabilidad estructural.
 
Para una PyME en CDMX o Hidalgo, la diferencia entre un sitio que convierte y uno que solo “se ve moderno” rara vez está en la cantidad de librerías instaladas. Está en la capacidad de elegir lo que resuelve un problema real, medir su impacto en rendimiento y mantenimiento, y retirar lo que ya no aporta valor. La web ya maduró. Los estándares nativos cierran brechas que antes justificaban abstracciones masivas. Ahora nos toca usarlos con criterio, verificar lo que se despliega y recordar que la simplicidad no es primitiva: es el resultado de haber eliminado lo superfluo.
]]> https://ferredia.com/26-anos-construyendo-la-web-y-lo-que-la-ia-no-puede-resolver-por-mi/feed/ 0 UTF-8: El estándar invisible que sostiene la web https://ferredia.com/utf-8-el-estandar-invisible-que-sostiene-la-web/ https://ferredia.com/utf-8-el-estandar-invisible-que-sostiene-la-web/#respond Thu, 04 Dec 2025 20:43:20 +0000 https://ferredia.com/?p=366

UTF-8: El estándar invisible que sostiene la web (y por qué nació de una crisis global de incompatibilidad)

El problema que nadie vio venir: la Torre de Babel digital

A finales de los años 80, el mundo del software enfrentaba una crisis silenciosa: cada idioma, cada región y cada sistema operativo usaba su propia codificación de texto.

  • En EE.UU., dominaba ASCII (7 bits, 128 caracteres).
  • En Europa Occidental, ISO-8859-1 (Latin-1).
  • En Rusia, KOI8-R o Windows-1251.
  • En Japón, Shift-JIS o EUC-JP.
  • En China, GB2312 o Big5 (para el chino tradicional).

El resultado: archivos de texto se volvían ilegibles al cruzar fronteras. Un correo electrónico japonés llegaba como “テスト” en una terminal estadounidense. Un documento alemán mostraba “Müller” en lugar de “Müller”. Esta fragmentación amenazaba con convertir internet en un archipiélago de islas lingüísticas incompatibles.

El intento fallido: Unicode y UTF-16

En 1991, el Unicode Consortium lanzó Unicode 1.0 con una idea ambiciosa: asignar un número único (code point) a cada carácter del mundo. Pero su implementación inicial, UCS-2, usaba 2 bytes fijos por carácter (16 bits) —suficiente para 65,536 símbolos, pero insuficiente para los miles de ideogramas chinos, históricos y técnicos.

Peor aún: UCS-2/UTF-16 rompía la compatibilidad con ASCII. Un archivo ASCII leído como UTF-16 mostraba caracteres basura (¡porque interpretaba cada byte como parte de un par!).

La solución elegante: UTF-8 (1992)

En septiembre de 1992, en el Plan 9 from Bell Labs (el sucesor experimental de Unix), Ken Thompson diseñó UTF-8, con aportes clave de Rob Pike. Su propuesta se publicó formalmente en el RFC 2279 (1998) y luego en el RFC 3629 (2003), que definió el estándar moderno.

UTF-8 resolvió tres problemas críticos:

  1. Compatibilidad total con ASCII: Los primeros 128 code points (0–127) se codifican exactamente igual que en ASCII, byte por byte.
  2. Eficiencia variable: Usa entre 1 y 4 bytes por carácter, asignando menos espacio a caracteres latinos comunes y más a ideogramas o símbolos raros.
  3. Autosincronización: Cada byte de inicio tiene un patrón único (0xxxxxxx, 110xxxxx, 1110xxxx, 11110xxx). Si se pierde un byte, el parser puede encontrar el siguiente carácter válido sin descarrilarse.

¿Dónde se usa UTF-8 hoy (2025)?

  • Web: 98.2% de los sitios web (W3Techs, noviembre 2025).
  • Linux y macOS: UTF-8 es la codificación predeterminada del sistema.
  • Bases de datos: PostgreSQL, MySQL (desde 4.1), SQLite —todos usan UTF-8 por defecto.
  • Protocolos: HTTP, JSON, XML, SMTP —todos asumen UTF-8 si no se especifica lo contrario.
  • Git: Almacena todo en UTF-8; los commits con otras codificaciones causan advertencias.
  • Incluso Windows: Desde 2019 (Windows 10 v1903), permite UTF-8 como “ANSI code page”, aunque con advertencias.

¿Y lo que viene? ¿Habrá una actualización o ruptura de UTF-8?

No. UTF-8 no será reemplazado, ni está planeada ninguna ruptura. De hecho, su posición es más sólida que nunca. Pero la razón no es solo técnica, sino estructural: UTF-8 es infraestructura crítica global, y cualquier intento de sustituirla sería comparable a querer reemplazar el sistema métrico o TCP/IP.

El estándar actual de UTF-8, definido en el RFC 3629 (2003), limita la codificación a 4 bytes máximo, lo que permite representar code points desde U+0000 hasta U+10FFFF —el rango completo del Unicode Standard.

El Unicode Standard v15.1 (2023) define 149,186 caracteres asignados, de un total de 1,114,112 puntos posibles en el espacio actual. Y el Unicode Consortium ha declarado reiteradamente que no hay planes de expandir más allá de U+10FFFF, porque el espacio actual es suficiente para todos los usos conocidos, incluyendo idiomas muertos, emojis, notación matemática y glíficos mesoamericanos.

Existen variantes marginales como CESU-8 o Modified UTF-8, pero son soluciones de nicho para sistemas legados (como Java antiguo) y no son UTF-8 válido ni interoperables con la web.

La verdadera evolución no está en cambiar la codificación, sino en cómo se interpreta el texto: manejo de grapheme clusters, algoritmos bidireccionales (bidi), y motores tipográficos como HarfBuzz. UTF-8 es solo el transporte; la inteligencia está en las capas superiores.

Conclusión: UTF-8 es para siempre (hasta que el mundo cambie de civilización)

UTF-8 no está “obsoleto”, ni en riesgo. Al contrario: es uno de los pocos estándares verdaderamente universales en la historia de la computación. Su diseño anticipó fallos, respetó el legado y escaló sin romper nada.

No habrá una “ruptura”. Lo más probable es que en 2100, si existe internet, aún use UTF-8 —igual que seguimos usando ASCII para los primeros 128 caracteres, 60 años después.

Ironía final: El único “problema” de UTF-8 hoy es que muchos desarrolladores aún no entienden la diferencia entre bytes, caracteres y graphemes… pero eso no se resuelve con un nuevo encoding, sino con mejor educación.

Y es ahí donde radica el verdadero desafío geek de hoy: no en inventar nuevos formatos, sino en dominar con rigor los cimientos que ya sostienen el mundo digital. Porque mientras todos persiguen IA generativa, metaversos o blockchains, el 98% de la web sigue en pie gracias a una idea brillante nacida en 1992 en los pasillos de Bell Labs.

 

Fuentes académicas y técnicas:
  • Pike, R., & Thompson, K. (1993). Hello World or Καλημέρα κόσμε or こんにちは 世界. Plan 9 paper.
  • RFC 3629: UTF-8, a transformation format of ISO 10646 (2003).
  • W3Techs: Usage statistics of character encodings (2025).
  • Unicode Consortium: The Unicode Standard, v15.1 (2023).
 
Utf 8
]]> https://ferredia.com/utf-8-el-estandar-invisible-que-sostiene-la-web/feed/ 0 WordPress y ACF: La fórmula para portafolios y sitios corporativos dinámicos https://ferredia.com/wordpress-y-acf-la-formula-para-portafolios-y-sitios-corporativos-dinamicos/ https://ferredia.com/wordpress-y-acf-la-formula-para-portafolios-y-sitios-corporativos-dinamicos/#respond Thu, 25 Sep 2025 00:33:44 +0000 https://ferredia.com/?p=64 Introducción

En el mundo corporativo moderno, la agilidad y la automatización son clave. WordPress, combinado con Advanced Custom Fields (ACF), permite crear sitios web altamente flexibles donde los contenidos, proyectos y portafolios se actualizan automáticamente sin necesidad de tocar el código cada vez.

Si trabajas en desarrollo web o gestionas proyectos para PyMEs, este enfoque te ahorra tiempo y garantiza consistencia visual y funcional en todos tus proyectos.

Instalación y configuración básica de ACF

  1. Instala el plugin Advanced Custom Fields desde el repositorio de WordPress.
  2. Crea un grupo de campos para tus proyectos (por ejemplo: nombre del proyecto, descripción, fecha de inicio, imágenes, URL).
  3. Asigna este grupo de campos a un tipo de contenido personalizado o a “Entradas” si deseas usarlo en posts de blog.

Creación de un portafolio dinámico

  1. Crea un Custom Post Type (CPT) llamado “Proyectos”.
  2. Añade los campos de ACF al CPT “Proyectos”.
  3. Usa un template de WordPress para mostrar los proyectos:
<?php
$proyectos = new WP_Query(array('post_type' => 'proyectos'));
if ($proyectos->have_posts()) : 
    while ($proyectos->have_posts()) : $proyectos->the_post(); ?>
        <h2><?php the_field('nombre_del_proyecto'); ?></h2>
        <p><?php the_field('descripcion'); ?></p>
        <img src="<?php the_field('imagen_del_proyecto'); ?>" alt="">
    <?php endwhile;
endif; wp_reset_postdata();
?>

Esto crea un portafolio que se actualiza automáticamente cuando agregas nuevos proyectos en WordPress.

Buenas prácticas corporativas

  • Mantén consistencia en los nombres de campos y categorías.
  • Usa imágenes optimizadas para mejorar la velocidad del sitio.
  • Configura ACF para campos obligatorios y previsualización de contenido.

Caso práctico

Para un cliente PyME del sector logístico, desarrollamos un portafolio de proyectos que incluye fotos de instalaciones, documentación de procesos y enlaces a reportes automatizados. Antes de implementar ACF, cada actualización requería editar el código. Con ACF, el cliente ahora sube información directamente desde el panel de WordPress en menos de 5 minutos.

Tips

  • Combina ACF con Elementor para maquetación visual sin tocar código.
  • Usa repeater fields para mostrar múltiples imágenes o etapas de un proyecto.
  • Configura reglas condicionales para mostrar ciertos campos solo en proyectos específicos.

¿Quieres implementar un portafolio dinámico para tu empresa o tus proyectos? Contáctame o prueba mis scripts de automatización para WordPress y Python, diseñados para PyMEs y desarrolladores que buscan eficiencia real. Contactame:

Por favor, activa JavaScript en tu navegador para completar este formulario.
Nombre
]]> https://ferredia.com/wordpress-y-acf-la-formula-para-portafolios-y-sitios-corporativos-dinamicos/feed/ 0