tag:porta.svbtle.com,2014:/feedJulián Porta2015-06-04T14:21:07-07:00Julián Portahttps://porta.svbtle.comSvbtle.comtag:porta.svbtle.com,2014:Post/theres-more-than-one-way-to-do-it2015-06-04T14:21:07-07:002015-06-04T14:21:07-07:00There's more than one way to do it.<p>Hace unos días, como parte de una <strong>tarea para el hogar</strong> musical, le encargué a <a href="https://twitter.com/poteland">@poteland</a> que escuchara tres versiones distintas del <em><a href="https://open.spotify.com/user/julianporta/playlist/3EEgLYKXiiDjyhtAzg1ybp">Prelude</a></em> de la <em>Suite Bergamasque</em> de Debussy, y eligiera la que más le gustaba.</p>
<p>Y me puse a pensar. </p>
<p>Una pieza musical no es más que una serie de instrucciones sobre notas, silencios y ritmo en un papel pentagramado. </p>
<p>Esta partitura después es ejecutada e interpretada por músicos, y cada uno le agrega sus cosas, su color, su tacto, su gusto. </p>
<p>Y lo mejor es que puede haber varias interpretaciones distintas de la misma obra, y todas ser igualmente bellas, cada una a su manera. Pero sigue siendo la misma pieza.</p>
<p>Y me puse a pensar que, tal vez, con el código pasa lo mismo.</p>
<p>Hace muchos, pero muchos años, leyendo una Guitar Player, no recuerdo quién lo dijo, pero me impactó mucho leerlo, y es lo siguiente.</p>
<blockquote class="short">
<p>Lo importante es la canción</p>
</blockquote>
<p>Creo que lo decían porque los músicos a veces tienden a priorizar la interpretación personal por sobre la obra. Más en una banda, donde algunos pretenden brillar sobre el oscuro firmamento que son los otros.</p>
<p>Y me estoy acordando de eso ahora, porque llevo tiempo viendo cada tanto que alguien escribe sobre la industrialización del software (toda esa cosa de toyota y lean software y el motto de python, y discusiones horribles sobre optimización, etc etc etc).</p>
<p>Y pienso que lo importante es la idea, tu idea.Y no que design pattern usaste o si es tal clase es una factory o si hiciste 20 deploys en un día o uno en un mes. O si tu equipo es ágil o no, o si no tenés equipo, o si tenés tests de integración, o si hacés code reviews todas las mañanas. Esos son accesorios que hacen a la interpretación, pero no a la idea.</p>
<p>Hace años vi un libro de python para computer scientists, o algo así. Y pensé, que horror. Qué obsesión por lo maquinal que hay que tener para aspirar a ser un científico si no estás haciendo ciencia.</p>
<p>Naturalmente, hay sitios donde la ciencia y la programación se cruzan, es innegable. Pero de ahí, a aspirar a la ciencia mientras configurás un wordpress para una lencería parece haber un trecho largo y sinuoso.</p>
<p>No importa cuantas formas de hacerlo haya.</p>
<p>No importa que esté perfectamente optimizado.</p>
<p>No importa si el código es feo.</p>
<p>O Lindo.</p>
<p>O si lo escribiste en Vim.</p>
<p>Ese no es el punto.</p>
<p>Lo importante es tomar una idea, ejecutarla, moldearla, acompañarla mientras crece, entenderla.</p>
<p>Hay diez mil personas que la pueden ejecutar con mayor destreza que vos, seguramente. Pero si es tu idea y sos vos el que la está ejecutando, éso es lo que importa.</p>
tag:porta.svbtle.com,2014:Post/un-castillo-de-cartas-de-la-liga-de-la-justicia2014-10-10T13:13:41-07:002014-10-10T13:13:41-07:00Un castillo de cartas de la Liga de la Justicia.<p>Es sabido que algunos superhéroes usan capa. Unos la usan para hacer facha cuando vuelan, otros como forma de protección y otros porque formaba parte de la vestimenta de su planeta natal.</p>
<p>Algunos humanos también usamos capas. Las usamos en forma de software, a veces para <em>simplificar</em> nuestro trabajo, para evitar la repetición, o sencillamente porque nos gusta como quedan.</p>
<p>Se suman a esta lista las cebollas, que también tienen capas, y cuando uno se mete a revolverlas, pueden hacer llorar.</p>
<p>Una vez estuve a punto de llorar por culpa de una capa de software. Y para empeorarlo, era una capa que puse porque <em>tenía ganas de probarla</em>.</p>
<p>Dejando de lado las analogías, encuentro que muchas veces se agregan capas (de software) porque creemos que nos protegen de algo. De algo complicado, de algo que no entendemos del todo, de algo que no queremos hacer <em>de cero</em>.</p>
<p>De hecho, a veces leo (en listas, foros) gente que si pudiera agregar una capa que le resuelva la aplicación completa, ¡lo haría!.</p>
<p>Es muy fina la línea que separa la practicidad del error garrafal, y suele desdibujarse con frecuencia, creo yo, producto de interpretar mal cosas como “DRY”, “No reinventar la rueda” o directamente “¿Alguien conoce una gema para hacer paginación de usuarios de facebook en un carrito de compras responsive?”.</p>
<p>No digo que las capas sean malas o buenas. Son accesorios que pueden sumar o restar, según cómo se usen. El tema es que cuando se agregan muchas capas, se hace fácil enredarse.</p>
<p>Sí es cierto que cuantas más capas se agregan aumenta el nivel de indirección y dicen que todo problema en computación se soluciona agregando una. Yo no estoy tan seguro, y lo puedo poner simple.</p>
<blockquote class="short">
<p>Aunque la mona se vista de seda, mona queda.</p>
</blockquote>
<hr>
<p>Cuando yo era chico, tenía un mazo de cartas de La Liga de la Justicia.</p>
<p>Cada superhéroe tenía una cantidad de atributos y puntos asignados a cada uno. Flash era el más veloz. Súperman el más fuerte. Y así.</p>
<p>Tener esas cartas, todas juntas en la mano, me hacía sentir poderoso. Porque tenía en mis manos la suma del poder de todos los superhéroes.</p>
<p>A veces, jugaba a hacer castillos con las cartas. Y los castillos, aunque estuvieran sostenidos por superhéroes con increíbles poderes, invariablemente se venían abajo. Porque las cartas hacen juegos y no castillos, y sus capas de nada sirven si no están cumpliendo su cometido.</p>
tag:porta.svbtle.com,2014:Post/menos-es-mas-y-el-dilema-del-espartano-mentiroso2014-10-07T14:42:35-07:002014-10-07T14:42:35-07:00Menos es más y el dilema del espartano mentiroso (+).<p>Acabo de leer, por septuagésima vez, eso de “Less is more”. Debo reconocer que nunca le presté atención, hasta ahora.</p>
<p>Mi primer impulso fue pensar “que estupidez”. El segundo fue preguntarme porqué me parecía una estupidez, El tercero, fue darme cuenta de donde veía el problema. El cuarto fue creer que podía escribir sobre eso.</p>
<p>Muchos de los que programamos hoy en día, de un modo u otro, somos hijos de una generación que valoró la abundancia. Déme dos, auto grande, casa más grande. Dos casas. Dos autos. Dos autos y una moto. Cuanto más, mejor.</p>
<p>Sin entrar en ese debate, creo que siguió esta corriente el “Menos es más”, apuntando al minimalismo, a despojarse de cosas de un modo ascético, espartano (todos calificativos que hoy tienen alguna connotación positiva, curiosamente).</p>
<p>No estoy en contra ni a favor del minimalismo, ni de ninguna corriente de pensamiento. Pero si me interesa que las cosas sean claras y evitar, cuando puedo, la confusión. Así que vamos a ponerlo claro.</p>
<blockquote class="short">
<p>Menos <strong>no es</strong> más. Menos es menos y no hay nada malo con eso.</p>
</blockquote>
<p>El tema es que nos cuesta negar de donde venimos, y aceptar realmente que, aunque a veces (queremos que) nos gusten las cosas de líneas simples y despojadas, por dentro lo que realmente queremos es comernos una vaca rellena con un chancho relleno con un pollo relleno con jamón queso y huevo, todo a la parrilla con papas y panceta.</p>
<p>Creo que de ahí sale esa contradicción. Pedimos algo simple, que podamos entender, pero por dentro queremos mucho porque dentro de nuestras entrañas todavía sentimos que mucho es mejor.</p>
<p>Tal vez, por eso nos fascinan cosas como Rails, porque con <em>sólo</em> algunas pocas líneas en la consola, unos generadores hacen magia y tenemos una aplicación completa, <em>grande</em>, andando y en poco tiempo.</p>
<p>Pero esas <em>pocas</em> líneas de código son una ilusión, una fachada. Y encuentro que esconden algo peor que la complejidad que tienen detrás.</p>
<p>A veces una fachada simple esconde algo complejo y está bien. Porque uno puede decir “lo que está detrás es complejo, pero lo sé, lo entiendo y está contenido”. Eso es practicidad.</p>
<p>Pero a veces una fachada es sacar rápido la ropa sucia de toda la casa y meterla apurado en el balcón, mover la alfombra para tapar el piso sucio, encerrar al perro en el baño y poner un repasador sobre los platos sucios en la pileta. Todo porque tenemos visita y queremos que la casa se vea presentable <strong>ya</strong>. Eso es mentira.</p>
<p>Al <em>menos</em> hay que saber bancarlo. Con lo bueno que tiene abrir el código, leerlo y entenderlo, con lo malo que tiene que no hay magia que nos resuelva lo que no sabemos. Y lidiar con la constante pelea interna que nos hace querer ese <code class="prettyprint">link_to</code> que tanto nos resuelve en Rails pero que escupimos con asco cuando defenestramos a Active… (inserte aquí su parte de Rails menos querida).</p>
<p>Por eso, menos es menos. Y está bien que así sea. O volvete a Java donde más es más y bancate la que te venga. O venite a vivir al campo y dedicate a la agricultura. Para gustos, los helados.</p>
<p>(+) En realidad el mentiroso era el ateniense que decía que todos los atenienses mentían, pero hacía falta meter un espartano… así que <em>disculpas</em> por la licencia.</p>
tag:porta.svbtle.com,2014:Post/err2014-10-04T15:45:41-07:002014-10-04T15:45:41-07:00Err<p>Llevo algunas semanas preguntándome por qué escribo sobre software. No logro responderme, pero en el proceso creo haber descubierto, al menos, desde dónde lo hago.</p>
<p>No soy un gran programador. Ni siquiera estoy seguro de ser uno bueno. No soy un teórico del software, no tengo educación formal en el tema y me ha faltado constancia y método, a lo largo de los años, para hacerme una base sólida. Cuando lo pienso, creo que lo que tengo es un poco de oficio, algunas ideas y otro tanto de experiencia.</p>
<p>Habiendo establecido eso, creo que escribo desde <em>el error</em>. Desde haber tomado incontables malas decisiones, de haberme equivocado fuerte. Pero también, desde poder revisarlo.</p>
<p>De todos los skills que he adquirido en relación a la programación, hubo dos que me costaron enormemente.</p>
<p>Uno fue aprender a reconocer mis limitaciones. A animarme a decir “no sé” en un canal de IRC. A aceptar que nadie nace sabiendo y que lo que no se sabe se puede aprender.</p>
<p>El otro fue a aceptar mis errores, tratar de aprender de ellos y sobre todo a no avergonzarme al cometerlos.</p>
<p>Cuando yo estaba aprendiendo a programar, tuve la suerte de hacerlo con alguna gente que también estaba aprendiendo. Lamentablemente, nuestros <em>superiores</em> (otros programadores con más experiencia) eran esa clase de gente que te hace sentir mal por estar aprendiendo. Al estilo ¿<strong>cómo que no sabés lo que es OLAP</strong>? (miradita cómplice con el compañero, sonrisita socarrona).</p>
<p>De esos tiempos guardo el desprecio por la gente que averguenza a otros por lo que saben o dejan de saber. El tipo que cree que la tiene más larga porque leyó sobre Smalltalk en la facultad. El que se rió cuando no supe que era “bitwise operation”.</p>
<p>También recuerdo de ésas épocas a gente que se ofreció amablemente y sin juzgarme, a enseñarme. A ayudarme a aprender. A entender que más importante que lo que sabés es cuánto estás dispuesto a aprender.</p>
<p>Yo nunca supe suficiente sobre programación para enseñarle nada a nadie. Pero me he equivocado bastante y he pasado algún tiempo revisando algunos errores como para poder escribir sobre ellos.</p>
<p>Ayer leí por ahí algo así:</p>
<blockquote class="short">
<p>Cuando un hombre descubre que su padre tenía razón, ya tiene un hijo que cree que su padre se equivoca.</p>
</blockquote>
<p>Hay cierta recursividad en la idea que me resulta apasionante. Y que resuena fuertemente con lo que me está pasando en relación a la programación.</p>
<p>Dudo que vaya a convencer a nadie de nada con lo que escribo. Sé que hay gente que de tanto en tanto encuentra pequeñas cosas que le hacen click. Puede ser un post en un blog, un pedazo de código que llama la atención. Una charla en una conferencia. </p>
<p>Mentiría si digo que no fantaseo con la posibilidad de que a alguien le sirva lo que escribo, y de poder ayudar, desde el lugar que me pude construir, del mismo modo que me han ayudado. Así que, al menos desde acá, esto es lo que sé hacer.</p>
tag:porta.svbtle.com,2014:Post/tirar-la-moneda-hasta-que-caiga-de-canto2014-09-20T16:00:50-07:002014-09-20T16:00:50-07:00Tirar la moneda hasta que caiga de canto. La triste historia del impuro depurador apurado.<p>Save. Refresh. Error. Refresh. Error. Refresh. Anda. Refresh. Error.</p>
<p>Albert Einstein dijo.</p>
<blockquote class="short">
<p>Locura es repetir lo mismo una y otra vez y esperar resultados distintos.</p>
</blockquote>
<p><em>– Claramente, nunca tuvo que aprender a programar</em></p>
<p>Hay algo enloquecedor cuando estás aprendiendo a programar, y es la sensación de que el universo te está gastando y lo hace moviendo electrones al azar cada vez que ejecutas el código.</p>
<p>(En realidad, el problema no es el azar sino que seguramente hay factores que uno no tiene en cuenta que pueden estar modificando el resultado.<br>
Pero de eso te dás cuenta cuando estás tranquilo sentado en un sillón, tomando un café y mirando el techo. Y no cuando te corre una gota de sudor frío por la espalda y te preguntás <strong>que mierda estaba mal en el tutorial que copypasteaste de un blog de hace dos años</strong>)</p>
<p>Sin ánimo de irme por las ramas, y tomo nota mentalmente escribir sobre el tema, el problema de base es que (muchos) <em>aprendemos copiando y no razonando</em>.<br>
Con la excusa de no reinventar la rueda, copiamos, pegamos, anda/no anda, y así por horas. Porque no sabemos siquiera que la rueda es redonda, qué es un círculo ni cómo se calcula su área. Porque lo que necesitamos es que la rueda ruede, y que lo haga rápido.</p>
<p>Pero, volviendo a la locura de esperar algo distinto cuando sólo hay mucho de lo mismo, el tema sigue así.</p>
<p>Alternativamente, he intentado, fallado, logrado y vuelto a fallar en implementar un login con oAuth usando Devise, <em>sin tener la más puta idea de cómo funciona oAuth</em>, todo en la misma tarde.</p>
<p>Naturalmente el error fue mio por encarar una tarea sin saber realmente lo que estaba haciendo, ni lo que implicaba.</p>
<p>Pero ese momento de frenesí, locura, impotencia y la constante sensación de que me cago en mi puta madre. Ese momento no tiene que ver con saber o no de antemano qué ni cómo lo estamos haciendo, ni con la real capacidad para comprender un problema dado, sino con algo más elemental y mundano.</p>
<p>Y es esto:</p>
<blockquote class="short">
<p>No podemos hacer lo que no sabemos, y no se sabe lo que no se aprende.</p>
</blockquote>
<p>Vamos a darle un momento a la idea para que se asiente. Y vamos a reforzarla.</p>
<blockquote class="short">
<p>Copiar algo no es hacerlo.</p>
</blockquote>
<p>Y con esto le ponemos el último clavo a la tapa del ataúd.</p>
<blockquote class="short">
<p>Se aprende entendiendo.</p>
</blockquote>
<p>Preguntar en un foro/lista, leer Stackoverflow, copiar y pegar código sin siquiera leerlo. Eso no resuelve el problema. Lo traslada del editor de texto en blanco a <em>algo</em> de código que se ejecuta cual gato de Schrödinger, que existe en un estado indeterminado de anda/no anda.</p>
<p>Mi papá despreciaba los plumeros porque decía que no limpiaban, sino que trasladaban el polvo de un lugar determinado <strong>a todos lados</strong>.</p>
<p>Años después, lo entiendo. Y me pregunto si el famoso “tenemos que reescribir la aplicación” que tanto escucho no tiene que ver con eso. Con que se desparramó el polvo por todos lados y ahora todo se siente sucio.</p>
<p>Pero me voy por las ramas.</p>
<p>Hacer algo sin entenderlo y esperar que ande, que no ande y no saber porqué. Que ande y <em>tampoco</em> saber porqué. Son todos síntomas de lo mismo. De creer que se puede aprender algo <em>a la velocidad que toma leerlo de Stackoverflow</em>. No digo que eso no pueda pasar, sólo digo que no aplica a todos los casos, ni a todas las personas.</p>
<p>Por eso, desde este pequeño lugar, digo.</p>
<p>Hay que aprender a hacer las cosas. Y para eso hay que entenderlas primero. Y el conocimiento no es inmediato.</p>
<p>Paciencia.</p>
tag:porta.svbtle.com,2014:Post/de-0-a-100-en-segundos-y-de-vuelta-a-0-en-meses2014-06-06T05:04:15-07:002014-06-06T05:04:15-07:00De 0 a 100 en segundos, y de vuelta a 0 en meses.<p>La primera vez que en una terminal escribí algo como:</p>
<pre><code class="prettyprint">sudo gem install rails
...
rails new blog
...
cd blog
...
./script/server
</code></pre>
<p>Casi me meo en los pantalones de la emoción.</p>
<p>Mi primera sensación fue de estar frente a un cambio fundamental en la forma en que podía programar.</p>
<p>Viniendo de perl y cansado de tener batallas épicas con Fast-CGI y Apache, la simplicidad aparente de Rails me resultó irresistible, y me dejé atrapar.</p>
<p>En el medio pasaron años. Y ahora, a la distancia, si bien no lamento haberme <em>pasado</em> a Rails, me pregunto en retrospectiva si realmente fue una buena decisión.</p>
<p>Hay algo en esas cuatro líneas, que llevan de la nada a un servidor local andando, en las decenas de tutoriales y screencasts que te llevan ciegamente de la mano a implementar (porque, no jodamos, seguir un screencast y terminar con un CMS de juguete andando en tu máquina, <strong>eso no es programar</strong> –es otra cosa), en la abundancia de gemas y librerías que permiten empaquetar funcionalidades que muchas veces ni siquiera se entienden. Decía, hay algo en todo eso que me parece nocivo.</p>
<p>Cuando yo estaba en la escuela primaria, una secretaria nos dijo un día: <em>“ustedes confunden libertad con libertinaje”</em>. Y a mí eso me quedó grabado a fuego en la memoria.</p>
<p>Y es que me pregunto si uno debería usar una librería que resuelve un problema que uno no sabría cómo resolver sin ella.</p>
<p>Naturalmente, todos estamos de acuerdo en que no es necesario reinventar la rueda en cada proyecto. Pero creo (y veo) que hay una tendencia a no tener ni idea de <strong>cómo funciona la rueda que estamos usando</strong>.</p>
<p>Y esto no lo escribo desde ningún lugar de privilegio. He pasado <em>muchas</em> más horas de las que debería buscando errores incomprensibles en librerías enormes que he usado indiscriminadamente por el sólo hecho de que, siguiendo un tutorial de 10 minutos, me permitían implementar funcionalidades que no hubiera sabido cómo programar.</p>
<p>Lo voy a escribir de nuevo.</p>
<p><strong>Muchas veces usé librerías sin saber cómo funcionaban y pagué muy caro creer que la estaba haciendo <em>fácil</em> cuando en realidad me la estaba complicando al cubo.</strong></p>
<p>En algún momento hice un click. Para una idea que tenía para un proyecto, y pensando que necesitaba escribir un API que respondiera lo más rápido posible, descarté incluso Sinatra y probé Cuba. Y no hubo vuelta atrás.</p>
<p>Una cosa llevó a la otra, y actualmente esa idea de proyecto es un proyecto hecho y derecho. Al menos, así lo siento. Y es un proyecto para el cual fui buscando una a una las herramientas que necesitaba, que hicieran bien una sola cosa.</p>
<p>Consecuencia de eso, me puse a mirar el código de esas herramientas que empecé a usar. Y noté otro patrón, pero uno bueno.</p>
<p>Dejé de buscar tutoriales sobre “como hacer X” y empecé a encontrar respuestas en el mismo código de las librerías que estaba usando. (Imagínense hacer lo mismo con <em>ActiveSupport</em>)</p>
<p>Hay años luz de distancia entre que te digan cómo hacer algo y aprender a hacerlo por uno mismo. Seguro, uno no es perfecto y <em>la forma</em> en que se aprende puede no ser la mejor. Pero hay algo en el proceso de aprendizaje que <strong>no puede reemplazarse</strong> siguiendo tutoriales, y es la capacidad para entender cómo funcionan las cosas.</p>
<p>Es la diferencia entre ir a comer al patio de comidas de un shopping y aprender a cocinar. Seguramente al principio la oferta del patio de comidas sea más atractiva y en primera instancia la comida va a <em>parecer</em> mejor. Pero con el tiempo uno crece, cambia la idea de qué es mejor. Y un buen día, la hamburguesa del shopping tiene gusto raro, mientras que en tu casa podés hacer un guiso de lentejas <em>decente</em>.</p>
<p>Y pasaron más cosas. Me animé a colaborar, discretamente, en esas librerías. Pude agregar funcionalidades que yo necesitaba y que los autores encontraron útiles (o al menos, inofensivas).</p>
<p>En toda mi historia laboral he trabajado de áreas muy diversas. Algunas de ellas, relacionadas con la tecnología, y otras completamente alejadas de ella. Una constante que se mantiene es que <em>siempre</em> hay que usar la herramienta apropiada para el trabajo. Y cuando no se sabe qué herramienta es esa, se averigua, se prueba y se aprende.</p>
<p>Me tomó <strong>mucho</strong> tiempo darme cuenta de que Rails (en realidad, esto aplica a <em>cualquier</em> framework, supongo) y todo su ecosistema son las herramientas indicadas para un montón de casos, seguro.</p>
<p>Pero para otro montón, no lo son. Y llevados por la motivación (equivocada, creo yo) de “hacer que ande” terminamos copiando y pegando código que no escribimos, para usar librerías que no entendemos, en aplicaciones que, cuando andan, lo hacen por la inercia del trabajo de otros.</p>
<p>Yo, por lo pronto, prefiero volver a 0, entender las herramientas que tengo, escribir las que necesito y compartir con otros lo que sirva de todo eso.</p>