Este gigabit switch con refrigeración pasiva es un switch de bajo costo (apenas €32 me costó adquirirlo) pero que ofrece algunas funcionalidades bastante avanzadas para ese precio: trae soporte para VLANs, soporte para LAG y hasta ciertos niveles (básicos eso sí) de QoS.

Este post se concentrará sobretodo en la capacidad de configurar los VLANs ya que es justamente el objetivo para lo cual adquirí estas unidades.

Las que me llegaron fue la v4 y el último firmware disponible para estas unidades en mi caso era el firmware 1.0.0 Build 20181120 Rel.40749.

En el post previo, hablé de forma muy general sobre algunas exigencias que tengo con un sistema de domótica casero. En este post, explicaré bastante más en detalle cuáles son mis exigencias y en base a cuáles valores siempre aceptaré o recharazé una solución.

Básicamente, mis requerimientos son los siguientes:

• Fácil de usar. Lo ideal es que no se note que es IoT.
• A prueba de fallos. Aunque no haya conectividad con la red, el sistema tiene que hacer lo que sea que tenga que hacer.
• Seguro. No me gusta filtrar nada hacia el exterior de qué aparatos tengo ni cuáles son las capacidades del mismo.
• No destruir la casa en el intento.

Haz click en el título de esta entrada para leer la entrada completa.

Hace 3 años, 1 mes, 1 semana y 6 días (aproximadamente) fue el último post de este blog. Si bien es cierto tuve muchas ideas para postear en todo este tiempo, la verdad es que no me acompañaban dos cosas:

• Tiempo. El tiempo disponible siempre es un factor que afecta a la hora de querer crear cualquier cosa, ya sea para probar esa nueva receta de cocina o para crear un pequeño pedazo de código que haga una cosa en específico.
• Motivación. Esta segunda razón en cambio fue el más fuerte: simplemente me faltaba la motivación para poder escribir. Me explico: mi blog se trataba principalmente de temas en PHP y de cómo resolver estos. Al día de hoy, sigo trabajando en PHP todos los días, y como tal, cuando llego a la casa y tengo el tiempo para escribir, la verdad es que no tengo ganas de ver algo que tenga que ver con programación en sí. Y cuando lo tengo, pues prefiero dedicar ese tiempo y ganas en proyectos como la API de Telegram y la librería para comunicarse con MQTT.

Y es justamente este último punto al que desde ahora en adelante quisiera dedicarle más tiempo y de esa forma, mantener de alguna forma este blog un poco más activo.

Sucede un pequeño problema con PHP: Al cabo de un par de años, siento que las cosas nuevas que aprendo son “obvias” y que debería haber sabido de ellas hace muchísimo tiempo. El otro problema es que cada vez lo nuevo que aprendo es más y más específico, por lo que es muy difícil crear un post de más de 3 líneas, y con la cual apuntaría mucho más al código fuente de PHP en sí, puesto que ahí es donde se explica de mejor manera lo que quiero entender. Por el otro lado, tampoco puedo crear algo generalizado sin tener que explicar un libro de teoría previa, que nadie va a tener ganas de leer tampoco.

Así que después de pensarlo mucho, voy a cambiar la temática de este blog. A partir de hoy, no será más un lugar para aprender de PHP (aunque lo más probable es que siga ocupándolo a modo de ejemplo o como implementación de algo), sino para aprender de domótica e IoT o Internet of Things: es un tema relativamente nuevo para mi, interactúa con cosas físicas e implica tener que soldar circuitos, combinándolo con programación!

Así que bienvenidos a una nueva temática que espero poder rellenar con muchísima información sobre la marcha.

En la casa estoy montando un servidor y hoy le quise agregar un nuevo disco duro. Sin embargo, cada vez que intentaba hacer algo con pvs, vgs o lvs me salía el siguiente problema:

  Parse error at byte 969 (line 58): unexpected token
  Error parsing metadata for VG vg_home.
  Cannot process volume group vg_home
  Internal error: VG lock centos must be requested before vg_home, not after.
  Can't get lock for centos
  Cannot process volume group centos
  Internal error: VG lock vg_gdrive must be requested before vg_home, not after.
  Can't get lock for vg_gdrive
  Cannot process volume group vg_gdrive
  Internal error: Volume Group vg_home was not unlocked

Haz click en el título de esta entrada para ver la entrada completa.

Hace poco cambié mi sistema de hace 5 años (quizás más) por uno nuevo y como tal, aproveché de instalar todo desde cero, algo que no había hecho hace ya muchos años. Como tal, se perdieron también un montón de plugins y tweaks que le había hecho a mi querido Firefox.

Tuve que ir de nuevo a la máquina antigua y revisar cosa por cosa qué había instalado y qué había cambiado a este tan versátil navegador. La lista de las cosas importantes es bien poca, pero cada una tiene sus detalles. Partimos con:

Con la salida de PHP7 me dieron bastantes ganas de empezar un nuevo proyecto y con la coincidencia de que ya comenzaba el nuevo año, qué mejor para partir este año nuevo con mucho aprendizaje de por medio? Fue así como se dio el nacimiento a una nueva class que aprovecha algunas de las características nuevas de PHP7 y que me sirvió también para aprender acerca de otras nuevas tecnologías de las cuales ya había escuchado pero que no había tenido tiempo de estudiarlas.

Esta nueva class implementa la API completa del bot de Telegram, que está ganando fuerza a un ritmo increíble, ya que en el último año se ha innovado bastante, permitiendo por ejemplo la adición de Stickers, o los Inline Bots que son simplemente increíbles (he hecho la prueba, y si: se puede tener una conversación usando sólo @gif’s). Todavía no están convencidos? Pues revisen esta amplia lista de links para que se convencan. Todavía no? También pueden hacer una simple búsqueda en Google y podrán leer en profundidad el por qué deberían desinstalar Whatsapp en favor de Telegram.

En fin: pueden pasar a revisar mi class en mi GitHub, probarla, mejorarla y todo eso. Esta vez quise un enfoque algo distinto y monté una Wiki con información adicional, documentación más que suficiente y todo lo más apegado posible a los mandamientos de la PHP-FIG. Queda algo de trabajo más adelante, pero vamos bien.

Nuestro repositorio es un repositorio privado, montado con Gitolite (de lo cual pueden leer algo más por acá) y lo bueno es que nos permite obtener un control absoluto sobre nuestro código como del acceso.

Sin embargo, esto también nos puede proporcionar dolores de cabeza: últimamente habíamos estado teniendo algunos problemas cuando nos tocaba subir symlinks, ya que por alguna extraña razón nuestro validador de XML y JSLint denegaban el commit diciendo que el archivo no compilaba.

Este post tratará justamente sobre ese caso y de cómo lo resolvimos.

Desde hace un buen tiempo que el mundo de PHP en general se está profesionalizando a un ritmo inigualable. Después de la creación de composer y PHPFIG es que todo cambió para bien y de esta forma se están creando y adaptando estándares que prometen hacer todo mejor.

Uno de estos estándares es el tema de este post y tiene que ver con Semantic Versioning, o semver para hacerlo más corto. El objetivo es bastante simple: nos permite saber rápidamente si cuando nos toca actualizar alguna parte de un package podemos hacerlo de forma segura o no, sin tener que preocuparnos de posibles problemas de retrocompatibilidad que pudieran surgir.

La idea detrás de esto suena bastante bien y la verdad es que después de haberlo probado en algunos sistemas de producción; funciona. En muy resumidas cuentas, podemos ver que una versión tendrá siempre 3 componentes:
X.Y.Z

Y qué significan cada uno de ellos? Pues eso también es bastante simple:

X representa la versión mayor.
Y representa la versión menor.
Z representa la versión de parches.

Que quede una cosa clara desde el principio! Yo no soy un fan de compilar software! Encuentro que hoy en día, compilar ya es cosa del pasado, a menos que quieras probar software que todavía no está listo para funcionar en producción. Como tal, quise probar qué tal andaba PHP7 con el código de la empresa, a raíz de las tantas maravillas que se ha dejado entrever de esta nueva versión.

Algunas de estas maravillas son que incluyeron PHPNG (PHP Next Generation), que mejora el uso de recursos (su aplicación ocupará MUCHO menos RAM), y ahora también se activó un JIT Engine (que aceleraría las llamadas recurrentes a funciones y métodos). Entre esas dos mejoras, deberían ver un incremento de velocidad del orden de 25% a 150% comparado con PHP 5.6, dependiendo del caso obviamente.

Esto quiere decir básicamente que en una instalación default de WordPress, la cantidad de instrucciones de CPU se redujeron de 9.413.106.833 a 2.483.106.468 y que el tiempo que ocupa generar 1000 veces el homepage se redujo de 26.756 segundos a 11.081 segundos (Como pueden verificar acá). En ambos casos, es un incremento de velocidad importante y está casi a la par (y actualmente en muchos casos aún más rápido) que HHVM de Facebook.

Este post fue originalmente publicado en capa9.net. Este post sirve como una copia de respaldo para futura referencia personal.

Hola estimada comunidad!

Tanto tiempo que no escribía para un sitio que no fuera mi cof cof blog.unreal4u.com cof blog cof ! Pero como todo en la vida, ya era hora que me dedicara a escribir un par de líneas, contribuyendo de esa forma con mi granito de arena a la comunidad Open-Source, y por supuesto celebrando el nuevo capa9.net (junto con todos los viejos estandartes)!

El tema de hoy será composer, y cómo esta aplicación ha cambiado por siempre el cómo se escribe código PHP, dando una madurez increíble al eco-sistema donde por primera vez ya nos podemos dedicar a escribir código profesional, modular y sobretodo, simple. Sí, lo leyeron bien: SIMPLE.