Posts tagged en español

DISCLAIMER: This post is in Spanish as its potential target are Spanish freelancers struggling with the Electronic Administration. Feel free to use Google Translator to know what the fuss is about.

Algunas declaraciones de la AEAT, creo que las que se ahcen a través de aplicaciones instaladas en el disco duro tipo P.A.D.R.E., requieren una carpeta llamada aeat en la carepeta /Usuarios/fulanito con los siguientes permisos:

• Usuario: Leer y escribir
• Staff: Sólo leer
• Everyone: Leer y escribir <– este hay que ponerlo así, por defecto está en “Sólo leer”

Pero otras gestiones, como por ejemplo el modelo 037 que he tenido que hacer hoy mismo, requieren que la carpeta aeat exista en el DIRECTORIO RAIZ DEL SISTEMA, es decir, para poder hacer todas las gestiones (o al menos a las que yo me he enfrentado por ahora), necesitaremos estas dos carpetas en nuestro sistema:

Macintosh HD/aeat
Macintosh HD/Usuarios/fulanito/aeat

O hablando en términos de consola:

/aeat
/Users/fulanito/aeat <-- cambia *Users* por *home* si estás en GNU/Linux

Los permisos con chmod creo que serían 757, es decir rwxr-xrwx

Francamente, no sé como de seguro es tener una carpeta con permisos de escritura para todo dios en el directorio raíz del sistema, pero tener que dar permisos de escritura en el directorio raíz a una aplicación que se ejecuta en el espacio de aplicaciones del usuario me huele a chapuza gorda. Estaría bien que unificaran los criterios de escritura y todo fuera a parar a la carpeta personal del usuario.

Lo más absurdo de todo es que he averiguado el error de escritura en el raíz a base de mirar el log que el applet de la AEAT escribe en… tachán tachán… la carpeta aeat de mi espacio de usuario, sin ningún tipo de problema. Que alguien me lo explique.

Esta pasada semana tuve la oportunidad de participar junto con la gente de Salumedia en una muy buena sesión de formación sobre la gestión de equipos y proyectos desde el punto de vista del Scrum Master, impartida por José Ignacio Ortiz de Galisteo.

Fue una sesión muy abierta y dinámica, en la que los que ya habíamos trabajado con Scrum alguna vez pudimos hablar de nuestra experiencia y hacer ver mejor a los “no iniciados” cómo se hacen algunas cosas, mientras que estos últimos pudieron preguntar todas sus dudas (e insistir en algunas de ellas) sin límite. Incluso se consiguió no lanzar la “alerta de trauma” ni una sola vez :)

Durante la sesión, y posteriormente, reflexionando y recordando el ciclo “Lunes ágiles” sobre agilismo que David JGurú, Javier Baena y yo dimos en la Universidad de Sevilla a finales de mayo, y en el que precisamente yo cubrí el rol de Scrum Master, me he dado cuenta de que al introducir Scrum a un equipo nuevo siempre acaban apareciendo los mismos lugares comunes.

La ¿panacea? de la estimación en equipo:

Pese a parece algo liosa en principio (¿planning poker? ¿sucesión de Fibonacci?), es bien recibida. La gente está muy cansada de estimaciones irreales que llegan desde arriba, hechas por gente que generalmente ha oído campanas sobre el desarrollo, pero realmente no sabe dónde. Por tanto, es normal que esta forma de “empoderar” al equipo de desarrollo ilusione tanto. Pese a todo, este tipo de estimaciones tienen riesgos y dificultades, a saber

- La sobreestimación y la subestimación. Mientras que la primera puede ser fruto de la inexperiencia (o de un realismo extremo) y las sucesivas iteraciones deberían ir eliminando esta práctica, lo segundo creo que suele venir por influencias externas (“no se puede tardar tanto en tener esto”) y puede ser altamente tóxica para el equipo. Es algo a evitar SIEMPRE. Una estimación bajo presión que acabe con mucha “subestimación” acabará pasando factura anímica (porque el trabajo es el que es y se tarde lo que se tiene que tardar), por no hablar de que malvender las horas de trabajo es nocivo para el negocio de por sí.

- Compromiso versus contrato. El equipo se tomará las estimaciones como el compromiso que asumen: “en tanto tiempo tendremos tantas cosas”. El problema llega cuando desde el PO/cliente se entiende que una estimación es algo absoluto y escrito en piedra, y que jamás se va a tardar más de lo que se dice porque nunca va a haber imprevistos. Ahi es cuando entra el dolor. Se ha de comprender que hay cosas que hasta que no se está hasta las rodillas en la faena, no aparecen.

- La obsesión con las horas. Esto suele darse entre la gente de las capas “de gestión” que llegan de nuevas. El concepto de puntos de esfuerzo les parece demasiado abstracto, no hacen más que preguntar por la equivalencia en horas. Lo importante es aprender qué implican y significan (y no “cuanto”) para tu equipo tres, cinco, ocho puntos de esfuerzo, y la conversión a horas vendrá sola, gracias al proceso subyacente de auto-conocimiento del equipo que conlleva el adoptar scrum.

Como hacer todo esto de cara al cliente

Esto es más de cara a un PO/comercial que un SM. Por esto es recomendable enlazar aquí la parte que dió David al respecto en el ciclo de agilismo.

Suele ser habitual el “¿como le vendo al cliente esto si no le puedo decir que van a ser 2 meses, tres semanas y cuatro dias JUSTOS de desarrollo?”, “¿como les hablo de sprints? ¿de que en dos semanas van a tener algo que se va a ir transformando en lo que quieren?”, “¿como hago para que cada sprint suponga aumentar el valor del producto, en lugar de pivotar completamente porque el cliente no tiene claro lo que quiere?”.

Todo esto es bastante complicado, concedido, porque requiere en mayor o menor medida reeducar al cliente. Esto es más labor de un PO/comercial si este pertenece a tu organización, en lugar de a la del cliente. Tendréis que aprender a vender proyectos de otra forma (juntos, el PO es parte del equipo, más que un comercial al que solo se le ve de higos a brevas por la ofi y con una bolsa cargadita de marrones). Aprovechad el factor iterativo y el de “más resultados, más pronto”, e involucrad al cliente más en el proceso. Abandonad la mentalidad de “desarrollos caja negra”, y trabajad más codo con codo con el cliente a base de implicarle.

Si toda vuestra organización va a ser ágil, pero vuestros clientes no van a cambiar con vosotros, aquí sólo va a haber DOLOR. Llegará ese momento en el que habrá que decir “no somos los desarrolladores que buscas”. Y sí, perder un cliente es doloroso, pero más doloroso es tener a un equipo encabronado en un ambiente tóxico, un cliente encabronado, y estar tú en medio.

Y si el PO que tenéis es del lado del cliente, y no entiende esto, entonces necesitáis quitaros a esa persona de encima, porque no ha entendido nada de nada.

Conclusión

En definitiva, adoptar Scrum no es cosa de un día. Requiere un aprendizaje, un sacrificio y tiempo de adaptación para todos los roles implicados. Son necesarios paciencia, comprensión y apertura mental.

Pero merece la pena. Porque implica una cultura organizacional diferente. Porque da poder al equipo de desarrollo, y porque nos reeduca a todos, poniéndonos en el sagrado camino de ser felices mientras trabajamos (que al final es lo más importante).

Y porque bueno, cuando lo echas a andar, Scrum funciona y todo.

De vez en cuando, alguien aparece con la misma pregunta:

¿Qué necesito para poder programar en Rails? ¿Qué recursos me recomendáis?

Como ya he respondido lo mismo más de una vez, y se que volverán las oscuras golondrinas, he decidido hacer un pequeño post explicando por donde empezar, qué libros mirar, etcétera. Todo opinionado, como Rails: todo basado en mi gusto y experiencia personal.

##El ecosistema Rails, cosas que interesa saber:

1. El Sistema Operativo
2. RVM/RBENV
3. Ruby
4. Rails
5. Git
6. IDE
7. Base de datos
8. Testing
9. El Alto Camino del Frontend
10. El Oscuro Camino del SysOps
11. Otros recursos

1 El Sistema Operativo

Esto es fácil: OS X o GNU/Linux. Nunca me he aventurado a desarrollar Rails en Windows, y por lo que he leído, es algo que no quiero hacer salvo que me ofrezcan MUCHA pasta por ello. Tanto para desarrollo como para despliegue.

NOTA: por preguntas que me han hecho, añado un par de links que pueden ser interesantes: Developing Rails in Windows, seriously, y Deploying Rails to Windows Server.

2 RVM y RBENV

Son gestores del entorno para Ruby/Rails y sus gemas (librerías). Cada uno funciona de una forma y sirven para controlar que version de Ruby hay instalada, que librerías y en qué versión están visibles para tal o cual proyecto, etc.

Para despliegues en producción, me gusta Rbenv, no lo conocía hasta hace poco y mola bastante. Para mi máquina local, trabajo con RVM por que fue el primero que conocí y ya es costumbre. Este post (en inglés) viene muy bien para enterarse de como funciona RVM.

Llegar a comprender como funcionan y sacarle partido es comprender como se organiza el ecosistema, como interactúan y son dependientes entre sí Rails, Ruby y las gemas que se usen.

• Rbenv
• RVM

3 Ruby

El lenguaje en sí. Ruby es a Rails lo que Python a Django o PHP a Laravel. Hay dos formas de enfocar esto: aprender Ruby conforme aprendes Rails, o aprender primero Ruby.

Yo hice lo primero por necesidad, y bueno, se tira para adelante, pero cuando sepas más Ruby, volverás a ver código antiguo y te avergonazarás al ver los pifostios que montabas para resolver cosas que con una sola buena línea de Ruby haces ahora más elegante y rápidamente. Es normal.

A mi me gusta mucho el Why’s (Poignant) guide to Ruby, que por cierto recomienda otros libros que son muy buenos también.

4 Rails

El framework. El esqueleto de tu aplicación. El conjunto de herramientas, comandos, estructuras y funcionalidades que te ayudarán a crear sitios web molones en dos patadas (bueno, quizá algo más). Una lista de recursos:

Rails Tutorial

Este lo hemos hecho casi todos, es básicamente el “Hola mundo” del Rails

Las guías Rails

Con esto hemos empezado todos a pegarnos con Rails. Explicaciones, soluciones y consejos básicos y rapidos para empezar a andar, algo así como “The Rails Way in a nutshell”. Imprescindibles!

• Rails Guides
• Rails API

The Rails Way

La BIBLIA de Rails. Aqui te explican como funciona todo y porqué (cosa bastante importante, no todo va a ser “magia”).

Ojo, que existen varias versiones: el original para Rails 2, el que salió para Rails 3, y el que ha salido hace poco para Rails 4. El problema de este libro es que algunas partes se te pueden quedar algo obsoletas por ejemplo si estás trabajando en Rails 3.2, ya que el libro cubre Rails 3.0, pero en términos generales, está todo ahí.

5 GIT

Es un sistema de control de versiones, que es muy popular y casi está considerado ahora mismo como el estándar de facto. Aquí está la manteca:

Adicionalmente, en Github podrás guardar tus proyectos (o en Bitbucket si necesitas que sean privados) y estar en contacto con la comunidad de desarrolladores, creando gemas, ayudando a mejorarlas, y averiguando como funcionan. Colaborar y aprender, los pilares del FLOSS.

Ojo, esta parte es algo fundamental en el desarrollo y aprendizaje (contínuo) de Rails. Cuando estés más pendiente de lo que pasa Github que de lo que pasa en Facebook, estarás en el buen camino :P (de ser un m4m3r70 pr0, pero hey tiene su aquél, ¡en serio!)

6 IDE

Hay algunos IDES para Rails funcionando que no he probado. Por lo que sé, la forma más habitual de trabajar es consola de comando, un editor de textos potente (TextMate2, SublimeText2, Vim, Gedit o Emacs) y varios navegadores en los que probar.

Todo lo demás que puedas conseguir con GUI para ayudarte si tienes miedo a la consola no te vendrá mal: clientes gráficos de Git, el JewelryBox para la RVM, SequelPro o PgAdmin para tus bases de datos, etc. Usa lo que necesites, con lo que te sientas más cómodo, y lo que tu máquina pueda correr (algunos de los softwares citados solo existen para OS X).

Personalmente, tiro de TextMate2, 4-5 terminales abiertos por proyecto (servidor Rails, IRB, SassWatch, RSpec y una “libre”). Uso la app de Postgres de Heroku para gestionar el servicio de PostgreSQL, PgAdmin o SequelPro para GUI de la BD. Raras veces uso JewelryBox y SourceTree, ya que suelo tirar casi siempre de consola para operaciones de Git y RVM.

7 Base de datos

¿PostgreSQL? ¿MySQL? ¿SQLite? Para el día a día, es complicado que tengas que llegar a pegarte con tu base de datos cara a cara, consulta a consulta, picando SQL ‘a pelo’, salvo que estés trabajando en algo MUY GORDO (¿qué haces leyendo esto, entonces?). Rails ofrece ActiveRecord, una interfaz de consultasa base de datos bastante potente que te facilitará el trabajo (y es legible por humanos!).

Aun así, conocer SQL no te vendrá NUNCA NADA mal (perogrullada). No, en serio, es una de esas cosas básicas que hay que conocer en esto del desarrollo web. Aunque también es cierto que la gran parte de las veces solo te tendrás que pegar con tu SGBD para importar o hacer dumps de la base de datos o crear usuarios :P

8 Testing

Rails viene con TestUnit (creo recordar) para tests unitarios. Yo por mi experiencia recomiendo RSpec, Capybara y Cucumber para cubrir TODOS los ámbitos de testing, desde unitarios hasta aceptacion y features (hablando ya también de BDD y no sólo TDD). En Rails Tutorial lo explican bastante bien de qué va todo, al menos lo básico.

• Test Driven Development
• Behaviour Driven Development

9 El Alto Camino del Frontend

CoffeeScript A grandes rasgos es una versión de la sintaxis de Javascript que hace que se parezca un poco  a Ruby, para tener código más legible y claro. Una forma más bonita de escribir Javascript, vaya. Pero tiene más, yo sigo aún descubriéndolo :D

De Javascript y jQuery pues, qué decir a estas alturas. Llevan funcionando tanto tiempo que resulta manido hablar de ellos :) Si estás leyendo esto ahora, seguro que sabes de qué van, o incluso te manejas con ellos.

10 El Oscuro Camino del SysOps

Capistrano Es un sistema de despliegue automatizado para Rails. Facilita la vida porque si te montas bien los scripts en tu máquina de desarrollo, con cuatro comandos de tu consola LOCAL (él solo se conecta por SSH y hace todo) pones la aplicación a funcionar desde cero, teniendo solo el servidor recién contratado.

Instalar las bases de datos, librerias, ruby, rails, gemas, el código, todo con cuatro comandos. El arte está en hacer bien los scripts, claro, y saber como funciona el SO sobre el que vas a desplegar. Por ejemplo no es igual el tratamiento de servicios de sistema en Debian que en Ubuntu, de ahi que tengas que tener nociones de administración de sistemas.

En mi opinión, es una herramienta FUN-DA-MEN-TAL. También he de decir que yo soy más ducho en el camino oscuro del sistemero, pero bueno. Cierto es que permite a gente sin mucha noción de sistemas configurar un servidor de forma rápida y sencilla para tareas básicas, gracias a que hay quien cuelga sus recetas (scripts) en Github. Solo necesitas saber leer y entender qué hacen, para ver si te interesa usarlas.

10 Otros recursos

Otros Tutoriales En Udemy tienen un tutorial bastante completo. Aqui

Cursos online Son muy interesantes y amenos de hacer los de CodeSchool. Prueba los gratuitos, y si te molan ya vas a los de pago. Como complemento, los de jQuery, Coffeescript y Sass ayudan también.

Yo no los he hecho todos (alguno de pago he pillado cuando les da por ponerlos un día gratis). No te van a enseñar nada que no puedas averiguar con los recursos gratuitos y escritos que hay por la red, pero están muy bien presentados y son muy entretenidos de seguir.

Railscast

Videos cortos en los que Ryan Bates explica de forma corta, amena y con la consola por delante como hacer cosas con Rails y el uso de gemas (librerías) populares. Esto no es para verlo desde el 1 al ultimo, al menos no después de los básicos. Estos son de consumir conforme necesites info: buscar cuál habla sobre lo que te interesas y te miras el que necesites.

¿Me dejo algo? ¿Crees que este post es mejorable? ¿Quieres rebatirme o aconsejarme? ¿Contratarme? ¡Comenta!

Hace poco tuve el placer de impartir junto a mis amigos y “camaradas del metal” David “JGurú” Rodríguez y Javier “Javo” Baena, con los que formo el tridente denominado “Bonobo Squad” unas charlas sobre agilismo y Scrum en la Escuela de Ingeniería Informática de Sevilla.

Dividimos la charla en tres partes:

• El papel del Product Owner - David JGurú
• El papel del Scrum Master - Julio Antequera
• Caso de éxito de aplicacion de agilismo y Scrum: SocialBro - Javier Baena

La presentación completa está disponible en speakerdeck.

Disfrutadla.

DISCLAIMER: being a post about a local event, I’ve decided to write it in Spanish. This should help me to finish it fast and publish it while the impressions from the event are still fresh in our heads. If you still want an English version, help yourself with the Google Translation apps.

Este fin de semana acudí a mi primer sarao profesional, el #OpenSpaceSevilla. Lo primero, como debe ser siempre, es agradecer el esfuerzo, dedicación y atención a los organizadores. No faltó de nada, y gracias a ellos y a los asistentes hubo muy buen ambiente en todo momento :)

Web Security por Pedro Laguna

Pese a lo improvisado, es un tema que nunca falla. Siempre hay anéctodas, prácticas y discusiones que salen a la palestra, en especial sobre la valoración que hace el cliente sobre ésto. ¿Debe la seguridad ser un valor añadido, o una core feature del software/servicio que ofrecemos? Personalmente soy más partidario de la segunda opción: la seguridad debe estar ahí, la pida el cliente o no. Esto puede requerirnos más esfuerzo como desarrolladores, o jugárnosla al ser más caros, pero creo que usando buenas metodologías y frameworks de desarrollo el impacto no debería ser tan dramático.

Hablando de frameworks, se hizo hincapié en una cuestión interesante: ¿confiamos demasiado en los frameworks que usamos? ¿los auditamos? ¿o es mejor encargarnos de todo nosotros mismos? Creo que para sustentar mi opinión en el apartado anterior, es obvio que soy partidario de delegar en los frameworks que usamos. La comunidad de usuarios y/o desarrolladores se encargará de mantener seguro el framework, simplemente es cuestión de estar al día de versiones y parches (esto ultimo es muy importante, y no siempre se sigue).

Aplicaciones tipo revista para iOS y Android por Javier Alonso

Bastante interesante por la relativa facilidad para crear este tipo de aplicaciones, me ha dado una idea para algún proyecto personal :) En cuanto a lo negativo: lo de Android era más un “reclamo publicitario” que otra cosa :P

También me gustaría comentar que se preguntó sobre como subir aplicaciones al Market de Apple desde un “Hackintosh”, y la verdad, me parece un absurdo. Si quieres jugar a ser dev de iOS porque mola Apple, sigues las reglas de Apple, pasas por el aro, pagas y te quitas de tonterías. Ah, ¿que es caro? Pues desarrolla para Android. Analogía: si quieres ser guay y moderno y fardar de zapatillas Converse, te compras unas puñeteras Converse originales. Si no te quieres gastar la pasta, te compras la Beppi de imitación cutres de la tienda de tu barrio, PERO NO LES VAYAS A PEGAR EL ICONO DE LAS CONVERSE, MIARMA, NO ME SEAS UN CUTRE.

Garajes en Andalucía, propuesta por José Manuel Beas

Esta charla comenzó muy muy bien, con muy buenas ideas y una muy buena dirección, hasta que fué acaparada por uno de los asistentes y desviada de la dirección original hacia un lamento continuo, un lloro y un solo ver lo negativo. No se consiguieron abordar ideas como la madurez del mercado en la región (se impuso la idea de que hay que irse a buscar el cliente en otro sitio, aun estando situados aquí), ni, -porque no-, la propia madurez de los profesionales del sector que empiezan su carrera profesional en Andalucía.

O lo que es lo mismo: la gente que va a dedicarse a esto, ¿sale imbuida del “espiritu garajero a.k.a. emprendedor” de donde quiera que ha sido instruido? La respuesta, en mi opinión, viene a ser que no, y creo que es algo que viene directamente de los métodos de formación y evaluación, desde mi experiencia, en la universidad. Luego ya está lo de que cada uno debe ser consciente de sí mismo y su entorno, pero es otra faceta más del mismo problema, creo yo.

Al final se atisbó algo de luz, al hablar de la dificultad de hacer comunidad, en concreto en Sevilla. La dificultad de montar eventos y charlas (que nos lo digan a los Wombytes) y que acuda el personal. De nuevo me remito a lo anterior. Me hubiera gustado que se ahondara más en ciertas recomendaciones que iban surgiendo para dar visibilidad a eventos y hacer algo de piña y masa, pero el tiempo no lo permitió.

Yo te la mido (la campaña), por David JGurú y Rubén Teijeiro

Me gustó mucho el planteamiento temático (en torno al surf) de la presentación, la idea, la motivación, toda la explicación del por qué y el como, el equipo, y el insistir y volver a insistir en opensource y el “lo damos gratis y libre”, una auténtica rara avis en éste evento.

Si debo decir que la parte en la que se muestra código me pareció algo floja, perdiendo la atención de muchos asistentes. Creo que es simplemente cuestión de seguir desarrollando la demo y poder mostrar más chicha en acción.

JS’s varios para hacer de todo, propuesta por Javier Alonso

Dada mi inexperiencia con las tecnologías tratadas (no me he pegado de verdad con node.js aún), éste fue el coloquio en el que estuve más perdido, aunque creo que sí que fue el más “open” de todos. Cada uno fué contando su experiencia y sus ideas respecto a los diferentes “js” tratados, consejos, mitos desmontados, referencias, documentaciones, un auténtico ejercicio de compartir conocimientos.

Historias de usuario, por José Manuel Beas

Sin lugar a dudas, la mejor ponencia de las que asistí. Hace poco que sigo a Beas en Twitter, y he leído algo de su blog, y la verdad es que sus intervenciones en el resto de charlas me gustaron mucho, pero me resultó impresionante verle “en acción” llevando realmente la batuta en una ponencia, y hablando de lo que más sabe. En cuanto a las historias de usuario, es algo con lo que tengo contacto en mi trabajo (llevo cuatro meses trabajando en un equipo ágil), y cada vez creo más firmemente que el agilismo es el camino para hacer las cosas bien, y hacerlas a gusto.

Obviamente las inquietudes sobre el mapeo de requisitos no funcionales, el catálogo de requisitos y demás parafernalia proveniente de la metodología tradicional es algo que a todos nos preocupa/ha preocupado en algún momento, pero creo que en muchos casos son cosas que por experiencia van saliendo solas. Me gustó mucho el hincapié que se hizo en el tablón físico, en el “yo soy el que mueve la tarjeta”, el “veo el tablón y de un vistazo tengo una impresión de como va la cosa”, me sentí muy identificado, me gusta tener las cosas apuntadas en papel, y por ejemplo, tachar una tarea realizada en un papel resulta infinitamente más gratificante que marcar un check en una aplicación móvil. Creo que trasladar a lo físico ciertos aspectos de nuestro trabajo, por muy IT que seamos, es esencial, a muchísimos niveles.

Y hasta aquí en cuanto al contenido de las charlas (me salté la última y la retro, soy mala persona).

En cuanto a la experiencia, tremendamente positiva. Al ser la primera vez, considero en global todo, y repetiría sin pensármelo. Quizá en cuanto a contenidos y charlas, podría mejorarse tal o cual cosa (contenido más técnico, o no; más control sobre determinadas actitudes), pero creo que simplemente es cuestión de estar ahí en la próxima ocasión, y aportar/proponer yo mismo algo, callar menos y participar más (aunque soy de natural observador, qué voy a hacer), y adaptar así el evento más a mis gustos y preferencias. Es así de simple y así de bonito. Lo mismo si fuera la cuarta o quinta vez que acudo a un sarao de estos no quizá estaría tan contento, pero la verdad es que me siento muy satisfecho.

Y la verdad, por 12€ un día y medio de conocer a personas, profesionales y absorber tanto conocimiento, los amortizas y amortizarás más y mejor que cualquier Máster de tres al cuarto de esos que hay por ahí.