Hablemos de LARAVEL
Taylor Otwell built Laravel to make PHP development simple, not fast. He came from COBOL and .NET but chose PHP as the easiest language he knew. The framework wraps Symfony components into tools like Eloquent ORM, Blade, and Artisan, and became popular enough to raise 57 million dollars.
Chapters
Hoy vamos a hablar de un programador de COBOL.
¿COBOL? Pero, ¿no tocaba el capítulo prometido a los miembros del canal? Ya sabes, los cronistas y los historiadores, que nos piden que hablemos del ARABEL.
Exacto, hablamos de lo mismo.
No creo, pro. El creador del ARABEL se llama Taylor Otwell.
Exacto.
Pero Taylor es programador de PHP.
Exacto, pero incompleto. Taylor comenzó su trabajo como programador de COBOL.
¿Tan viejo es?
No tanto, pero parece que en su arcángel natal. Cuando fue a buscar trabajo solo encontró una empresa con más de 100 años en el sector de transporte en mitad de ninguna parte y que comenzó en la computación con un mainframe y COBOL, como los bancos. ¿Recordáis nuestro vídeo sobre COBOL?
¿Cómo olvidarlo?
Vaya, ¿cómo llega un programador de COBOL a tener contacto siquiera con PHP?
No solo de COBOL, también era programador de .NET.
¿En serio crees que eso lo aclara?
Nope, pero te lo cuento en un rato. ¿Inciso?
Inciso. Antes de continuar, un inciso.
¿Te gustaría apoyar a nuestro canal?
No te olvides de darle a me gusta y, si no lo estás, suscribirte para no perderte futuro contenido. También puedes apoyarnos si quieres uniéndote al canal o enviándonos un gracias aquí abajo en el botoncito, nosotros te lo agradeceremos igualmente y os avisaremos de ofertas y promociones del canal.
Y además también podemos acompañarte desde tu plataforma de podcast favorita.
Ahora sí, continúa.
Taylor y PHP. Como decíamos, el pasado de Taylor está plagado de COBOL y .NET, principalmente páginas web desarrolladas con ASP.NET.
¡ASP! Esas son las Active Server Pages, desarrolladas en una mezcla entre HTML y C# a través de etiquetas ASP.NET.
Exacto. Aunque nacieron con la idea de emplear cualquier lenguaje, son muy conocidas entre programadores de C# y Visual Basic .NET principalmente.
Entonces Taylor desarrollaba en COBOL y hacía páginas web con esta tecnología. ¿Cómo llegó a PHP?
Pues estaba pensando en crear una startup.
Arkansas está algo lejos de Silicon Valley.
Sí, pero es un sentimiento muy americano de intentar crear tu propia empresa. Vivir el sueño. ¿Es que hay algo que sea más estadounidense que montar tu propio negocio tecnológico?
Bro, Arkansas, que solo encontró trabajo en COBOL.
Y ahí lo tienes, en Arkansas, y no en el glamuroso Silicon Valley o el mundano Nueva York. Un hombre hecho a sí mismo.
Con tan solo sobrevivir como emprendedor podríamos considerarlo un unicornio.
Él quería cambiar las reglas del juego. Usar un lenguaje no para los académicos de élite ni para las megacorporaciones, sino para los soñadores, los creadores, aquellos que buscaban la libertad en la web.
¿Libertad? ¿No sería más bien un hosting barato y que hasta un becario pudiera trabajar?
Java también se estudiaba en las universidades y es muy parecido a C#. ¿No era una opción?
¿Un programador de C# usando Java? No creo que fuese una opción para Taylor.
Finalmente Taylor decidió usar PHP porque era el lenguaje más simple que había aprendido durante sus años de universidad.
No es una gran historia finalmente.
A veces lo simple gana a lo elaborado. Taylor y la web.
A ver, pro. CodeIgniter fue lanzado en 2006. ¿Por qué no usarlo?
CodeIgniter se basó en CakePHP y Ruby on Rails. Sí, tenía como principal foco la velocidad.
¿Y a Taylor no le parecía suficiente y creó otro sistema más rápido?
No, de hecho Laravel es más lento que CodeIgniter.
¿Estás seguro? Que hay muchos seguidores de Laravel, a ver si se van a enfadar.
No es un secreto, hay muchas comparaciones que posicionan a CodeIgniter como la solución si quieres crear un sistema pequeño y rápido.
Vale, entonces la velocidad no fue uno de los objetivos. ¿Cuál fue la motivación?
Taylor ha comentado en muchas entrevistas que su principal objetivo era hacer el sistema más fácil.
¿Más fácil en qué sentido? CodingKnighter no parece muy complejo.
CodingKnighter nació cuando aún se programaba con PHP 4, y la salida de PHP 5 trajo consigo muchos, muchos, muchos avances. ¡Ah!
Entonces es el problema de no poder cambiar todo el framework desde cero. CodingKnighter estaba atado a hacer las cosas como en PHP 4, y cambiar a otro modelo sería reescribir todos los proyectos.
¡Exacto! Avances como los espacios de nombres o las mejoras en la orientación a objetos como la reflexión, que facilitan enormemente construir sistemas que hagan consultas a bases de datos, no eran fáciles de introducir en CodeIgniter. Pero ese no era el problema.
Pues yo lo veo suficiente.
¡No, Chip! Esas mejoras en la base de datos podrían haberse introducido y de seguro muchas de ellas lo harían en posteriores versiones. No sería suficiente para crear un nuevo framework.
Entonces, la autenticación y autorización de usuarios.
Eso lo proporcionan los frameworks.
El de Django desde luego no, ¿verdad, Chip? ¿Verdad?
Pues sí, hay muchos frameworks que proporcionan una forma rápida y simple de realizar páginas de inicio de sesión, registro, recuperación de contraseña, cambio de clave... Eran acciones muy comunes.
Pero se puede instalar externamente, no tiene por qué venir en el framework. Yo no lo veo una necesidad tan grande como para crear algo nuevo.
En verdad, Taylor no estaba creando Laravel porque quisiera hacer un framework para la comunidad. Él estaba creando una solución para sí, para crear sus páginas, y quería hacerlo de la forma más simple y rápida.
Lo que en entorno de producto llaman usar lo que vendes o cubrir tus propias necesidades.
En verdad, las frases en inglés son mejores: scratch your own itch, rascarte lo que te pica, o Eat your own dog food. Comerte—
Vale, lo pillamos. Y mis frases, aunque no tan rítmicas, en español suenan mejor.
Parece que accidentalmente se hizo popular.
¡Qué accidente tan conveniente!
Vayamos al framework. Fue creado en 8 meses.
¿8 meses? No es mucho para un framework de estas características.
Sería una versión muy reducida.
Exacto. De hecho, él lo consideraba un microframework y parece que reescribió la capa de acceso a datos unas 3 veces.
La parte más sensible.
Ciertamente, pero me asalta una duda: ¿por qué le puso el nombre de Laravel?
Taylor y Laravel, eloquent. En un documental sobre Laravel—
¿Hay un documental hecho sobre Laravel?
Sí, lo agregaremos en las fuentes, en la descripción, como siempre.
Vale, perdona.
Como decía, en ese documental Taylor dice que estaba jugando a rimas o palabras encadenadas e iba por Laravel Y de repente lo rimó con Laravel y ante la sonoridad dijo: esto es algo que podría usar.
¿Estaba activamente buscando un nombre?
Seguramente. Es una de las labores más difíciles junto con la invalidación de caché. Pero a diferencia de esta última, la primera se hace de forma muy frecuente.
¿Cómo de frecuente?
Pues cada vez que hay que escribir un código hay que elegir nombres para las variables, constantes, funciones, módulos, clases, ficheros...
Vale, vale. Nombrar es muy frecuente, pero habías dado dos nombres en el título. Laravel y Eloquent. ¿Por qué?
Para dar una idea de que cada subsistema o paquete creado en Laravel tiene su nombre.
¿Subsistema? ¿Eloquent entonces es un subsistema?
¡Por supuesto! Vamos a ver los subsistemas más empleados. En principio tenemos Eloquent ORM.
¡Ah! Un ORM, es decir, Object Relational Mapper, o un sistema para hacer de interfaz entre los objetos de PHP y las tablas de las bases de datos.
Este fue el subsistema que tuvo que reescribir tras veces. Tendrá que ser muy bueno.
Exacto. También tenemos Blade, el motor de plantillas.
¡Un momento! ¿Me estás diciendo que en un lenguaje de plantillas como es PHP hay un motor de plantillas? ¿Esto qué sentido tiene?
En verdad, que Laravel disponga de un subsistema no quiere decir que tengas que usarlo.
Es opcional, pero aquí estoy con Chip. ¿Qué sentido tiene?
Blade tiene muchas ventajas sobre PHP como una sintaxis más limpia, herencia de plantillas...
Suena a lo que hacen las plantillas de Django.
Sí, y dispone de protección contra cross-site scripting o XSS, además de otras ventajas de seguridad.
Bueno, si es por usar algo como DTL en PHP, lo veo coherente.
Sigamos. Teníamos Eloquent, Blade... También está Envoy para desplegar código.
¿Algo como Ansible?
Similar. También puede asemejarse a Capistrano, que es muy popular en entornos de Ruby on Rails. Seguimos. Tenemos Artisan para generar código en la línea de comandos.
Este tiene que ser similar al comando rails o al manage de Django.
Exacto. También tenemos Queue como un sistema de colas para tareas en segundo plano.
Este nombre no se lo pensó mucho.
También Scheduler para tareas recurrentes.
Sí, nombres del Capitán Obvio.
Tenemos Passport para la autenticación usando el estándar OAuth 2.0, Socialité para la autenticación con Google, Facebook y GitHub, entre otros. Cashier para pagos usando Stripe, Telescope para monitorización.
Hay muchos y nos queda claro que la comunidad de Laravel está haciendo un gran trabajo en este framework. Pero tengo entendido que no partió desde cero.
No, no hizo todo esto desde cero, usó muchos componentes de Symfony.
¿Qué componentes exactamente?
Pues creó HTTP Foundation para manejar las solicitudes y respuestas, Console fue empleada para crear Artisan, Routing para las rutas, Event Dispatcher para los eventos obviamente, Translation para las traducciones, FileSystem para el sistema de ficheros, Casi que podemos decir que Laravel fue una ramificación de Symfony. No, porque la base fue muy diferente. Symfony es un sistema muy configurable, pesado y difícil de aprender. Su curva de aprendizaje es muy pronunciada, mientras que Laravel es mucho más amigable.
Vale, parece que Symfony es más empresarial y Laravel más de startups.
Entonces, la comunidad de Laravel ha podido beneficiarse de lo producido también para Symfony.
No solo la comunidad. Taylor fundó una compañía en 2011 llamada Laravel Holdings Inc. y todos los desarrollos están ofrecidos desde su página web.
Un momento, ¿dijiste que Laravel en principio no se ofrecía como producto?
No, fue un desarrollo interno desde 2010 hasta su publicación en 2011.
Y justo cuando lo publica fundó una empresa con ese mismo nombre.
Bueeeen...
Tranquilo, yo comienzo la siguiente sección. ¿Qué? Taylor y sus polémicas.
Pero no tiene polémicas.
¿No? ¿Seguro? ¿Hablamos de sus Lambos?
Cada uno gasta su dinero en lo que quiere y el Lambo se ha convertido en parte de la marca personal de Taylor.
¿Cómo fue que salió ese meme? Porque se ha convertido en un meme. Taylor bailando mientras conduce su Lambo.
Parece que fue a una conferencia llamada ZendCon sobre PHP a Las Vegas y decidió alquilar un coche caro cada día que estuviese fuera.
Solo para llamar la atención.
Sí, de hecho tenían muy claro que si alguien les preguntaba la típica frase de ¿a qué os dedicáis para conducir este coche?, ellos dirían: somos programadores de PHP.
Pero entonces el Lambo no era suyo.
En los inicios no, más tarde sí. Pero no tiene nada de malo tener un Lambo.
No, tener un Lambo no, pero poner en su matrícula FASAD...
Es discutible que sea un mal patrón de diseño.
Parece que tal y como se implementa en Laravel hay gente que considera que es un antipatrón.
Discutible.
Parece que alguien puso un listado bastante extenso sobre los problemas técnicos con respecto a la calidad de Laravel.
Tailor implementa de forma libre cómo funciona Laravel y hay gente a la que no le gusta, pero termina siendo una forma muy amigable y no hay problema con ello. Cambiamos de tema. Laravel. Laravel es un framework web.
Eso quedó claro.
Como la mayoría de frameworks, sigue el patrón de Modelo-Vista-Controlador o MVC, donde el modelo implementa todo lo relacionado con la base de datos.
Esta sería la parte cubierta por Eloquent ORM.
¡Exacto! No creo que pueda decir mucho más. Empleando Artisan podemos generar código y adaptarlo a nuestras necesidades.
¡Nos quedamos sin tiempo! Conclusiones.
Desde 2011, la empresa de Laravel ha tenido buena tracción. Tiene bastantes empleados y ha ido lanzando productos poco a poco. Muchas empresas usan Laravel y los programadores que trabajan con Laravel están encantados de la facilidad del framework.
¡Vaya! Este mismo año han levantado una ronda de financiación de 57 millones de dólares.
No les va nada mal.
Habría mucho que decir de Laravel, pero en verdad lo ideal sería mostrarlo en lugar de seguir hablando.
Una demo vale más que mil palabras. Pero no será hoy. Ahora el turno es para vosotros.
¿Qué frameworks usáis? Y si es PHP, ¿empleáis Laravel? ¿Qué opinión os merece?
¿Creéis que tal y como dice Taylor se puede comprar un Lambo trabajando de PHP?
No creo, Violeta, pero si vosotros creéis que sí, ¿para qué empresa habría que trabajar?
Déjanos tu comentario. Chicos, hemos hablado de lenguajes antiguos y nuevos. Parece que atraen más los nuevos. ¿Alguna idea de por qué los vídeos sobre COBOL o FORTRAN no gustan tanto?
Supongo que a los programadores les gusta más ver los lenguajes en los que programan.
¿Seguro?
Si fuese así, el vídeo de JavaScript no sería el peor del canal.
Puede que sea porque Pro está en la miniatura. ¿Lo quitamos para probar?
Mi foto está genial, ¿no? No debe ser por ese motivo.
Hmm... El vídeo de Linus Torvalds tampoco atrajo mucho la atención. Se ve que las monografías de personalidades tampoco gustan demasiado.
Es una pena, aunque de pasada hablamos de personalidades como Ken Thompson o Tony Hawk en nuestros vídeos, así que está bien.
Entonces, si a la gente no le gusta saber sobre los lenguajes antiguos, ¿el nuevo libro de Altenwald no será comprado por nadie? ¿Es que nadie lee en estos días?
No lo sé. Esperemos que alguien a quien le interese y haya llegado hasta el final apoye y compre algún libro. Sería un detalle, ya sabéis.
Continuará.
More from Manuel
Historia de los Lenguajes de Programación: años 1960-1969 #basic #apl #simula #lisp #logo
¿Compilador o intérprete? La historia de una rivalidad que comenzó en los años 40
