Pesadilla en Laravel Street, capítulo 1

Voy a hablar un poco de mi trabajo, con permiso.
Casi llevo un año aquí, y hace pocas semanas heredé cierto proyecto gordo. Uno de los más importantes de la empresa. Un CRS que no para de crecer. Mi reacción fue agridulce, pues ya me habían hablado de este proyecto anteriormente, notablemente mal. Pero todavía no entendía por qué. Pronto empecé a sentirme así: http://www.commitstrip.com/en/2016/02/15/our-companys-greatest-project/

El proyecto en sí no es viejo. Por no decir que está basado en Laravel. El problema es que su primer programador (que ya no se encuentra entre nosotros) o no entendía Laravel, o no le gustaba nada. Era un veterano muy acostumbrado a una plantilla de back-ends en PHP nativo, propia de la empresa. Todavía se utiliza de vez en cuando en proyectos sencillos.

Esta plantilla tiene páginas y librerías comunes, listas para generar nuevas páginas fácilmente en base a los campos de cualquier tabla de la base de datos. Para que funcionase a la primera había que seguir una serie determinada de convenciones y reglas. Sino, tocaba apañar parches con Javascript, o muchos IFs en el núcleo.
Cuando el primer programador empezó, se empeñó en replicar esa funcionalidad, ignorando lo que Laravel podía hacer para simplificar el proceso y dejarlo limpito.

Para empezar, lo normal en un sistema CRUD de los de toda la vida es aprovechar el sistema de plantillas de Laravel, perfectamente anidables, y generar vistas para index, create, edit y show. Cada una tendría sus campos necesarios, sus validaciones, etc.
¿Para qué? Dejemos solo una vista para el index de cada sección, que recoga un par de parámetros, y el resto que venga de plantillas. Para cosas más complicadas pues sí, habrá que empezar de cero.

Pero vaya, no sé cómo leer automáticamente en Laravel qué campos tiene esta tabla en la base de datos, ni de qué tipo son, para utilizarlos en el create y en el edit. Podría de alguna manera añadir esta información en su respectivo modelo...
¿Para qué? Voy a inventarme una función en cada controlador, donde listar los campos para mostrar. En cuanto a los tipos... Me inventaré un helper, al cual le pido el tipo de campo, y me devolverá el input HTML necesario. Así es como lo hacíamos antes, más o menos. :-D

Seguiré en otro capítulo. Tengo para rato.

Esta rutina matutina te ahorrará 20 horas a la semana (artículo ajeno)

Durante mi presentación de este blog mencionaba un artículo sobre productividad, el cual me recordó las bondades de presumir públicamente qué he aprendido últimamente. El artículo (en inglés) es este, de Benjamin Hardy:
https://medium.com/@benjaminhardy/this-morning-routine-will-save-you-20-hours-per-week-a05c68b8e73c

Me encantaría traducirlo al castellano (no es la primera vez que lo hago), pero es larguito y hay bastante miga que sacar de ahí. Y prefiero invertir ese esfuerzo hoy en abrir este blog nuevo, así que me limitaré a resumir lo que me ha parecido relevante.

updateOrCreate (Laravel Eloquent)

En los meses que llevo usando Laravel, me he ido maravillando a cada momento con cada pequeño descubrimiento, especialmente para funciones habituales que estaba acostumbrado a que en PHP requiriesen varias líneas rudimentarias.
Si hay una función de Eloquent que recuerdo con cariño, es updateOrCreate.

Más me sorprende que sobre ella exista tan poca documentación. Oficialmente lo único que hay se encuentra en la documentación de API. Y la verdad: la miro, y apenas la entiendo. Pero como ya la he usado un par de veces, a ver si lo sé explicar bien.

Presentación obligada de este blog

Buenos días, señores lectores. No recuerdo cuántos blogs llevo ya creados. Bastante ha llovido desde que creé el primero para anunciar mis primeros pinitos en la programación. Qué vergüencita.

Quien no me conozca todavía, puede mirar aquí. Mucho gusto. [reverencia]

Estuve leyendo ayer otro de tantos artículos sobre productividad. Sigo sin tener un nivel demostrable de productividad, pero siempre me inspiran y acabo sacando alguna idea interesante. Profundizaré sobre él más tarde, pero entre otras cosas me recordó los beneficios de escribir sobre lo que he aprendido.

Es algo que bastantes programadores hacen, bien para acordarse ellos mismos en un futuro, bien para ayudar indirectamente a otros programadores que tropiezan con la misma piedra y no encuentran la salvación en StackOverflow (bendito sea).

También lo quiero usar para demostrarme a mí mismo cuánto he ido creciendo como desarrollador, y como persona, desde que me mudé de Ibiza a Mallorca hace casi un año, dejando atrás varios años de Sistemas. Sí, cuando picaba código, como podía en mi tiempo libre, mantenía un Diario del Programador. Actualmente son 28 páginas, y en las primeras escribía "X líneas escritas, X líneas eliminadas" junto a cada pequeño detalle. (No, todavía no sabía nada de Git, así que las contaba a mano)

Puede que escriba de vez en cuando sobre otros temas de mi interés. O que incluya alguna locución propia (otra de mis vocaciones perdidas).

Espero que este blog le resulte útil a alguien. Y que Blogger no sea tan espantoso como lo recordaba antaño. Gracias por leer hasta el final, y hasta lugo.