"Cuando logras terminar los pendientes sales sintiéndote bien; pero cuando algo nomás no te sale y ya tienes que irte, terminas con un poco de frustración y puede afectar tu actitud por el resto del día…". Hace poco platicamos (Gabriel Flores y yo) sobre el estado de ánimo después del trabajo. Comentamos sobre las causas, una vez que pasa como remediarlo y también de como podríamos prevenir esa frustración.
Al iniciar un proyecto es más fácil conocer las necesidades del cliente teniendo una junta en persona (o por lo menos virtualmente, voz y quizás video). De ese modo cuando leemos el documento con los requerimientos o detalles de lo que se necesita se puede entender fácilmente a que se refiere cuando habla de ciertos conceptos. La conversación con voz ayuda a reducir los malentendidos. Sin embargo también es fácil de olvidar los detalles después de la junta. Además de la junta en “persona” es bueno tener todo lo que se trato por escrito, ya sea en notas o una minuta para poder consultar lo que se habló.
Durante el desarrollo del proyecto puede haber detalles que discutir… y es de esos casos de los que quiero hablar (escribir, mejor dicho [escrito]).
Me ha pasado que me llega un correo preguntándome cuando podemos hablar. Propongo una fecha y hora, quedamos en llamarnos y momentos antes de la junta se tiene que posponer porque alguno de los dos ya no pudo. Se mueve la junta, total que pasa una semana y por fin tenemos la llamada. Al estar en la llamada, me doy cuenta que si desde el primer correo me hubieran escrito lo que necesitaba de mi, para ahora probablemente ya tuviera listo lo que se necesita y pudiera contestar mejor a sus preguntas. Además de que no hubiera tenido que reservar el tiempo para la junta (además del tiempo perdido en ponernos de acuerdo).
En ocasiones tengo mensajes instantáneos del tipo “Hola Mario”. Que no puedo atender al momento, después de buen tiempo contesto con un “hola” también; pero la otra persona ahora esta ocupada. Ya para cuando me contesta, espera que estemos los 2 en la conversación para ahora sí explicarme lo que necesito saber o para preguntarme lo que necesita saber. ¿Por qué no escribirlo desde el principio? o ¿Por qué no simplemente mandar un correo con lo que se necesita?
He pensado que esto ocurre por pereza para ordenar las ideas y expresarlas de una manera escrita. Es más fácil hablar y hablar sin ordenar los pensamientos y que la otra persona sea quien lo organice y le de sentido. He visto la pereza incluso para mandar el correo para hablar, con títulos como “Llamada”, “Mario”, “Pregunta”. Ni siquiera se menciona el tema sobre el que quieren hablar.
No seamos flojos para pensar, no hablemos sólo por pereza. Organicemos las ideas de tal forma que podamos expresarlas en un mensaje escrito y evitar tanto ida y vuelta de mensajes sin contenido.
Leyendo blogs he encontrado diferencias entre ambos términos. Se dice que el programador es la persona que escribe el código (nomas) y el desarrollador hace algo más. Según el desarrollador de software tiene otras habilidades además de escribir código. Se involucra en todo el proceso, como análisis, diseño, evaluar marcos de trabajo (Frameworks), lenguajes, arquitectura, etcétera. ¿Acaso el programador no tiene esas habilidades?
Un programa se elabora en incrementos, es decir, un programa puede ir cambiando con el tiempo, agregándole características. No se construye de la misma forma en que se construye un edificio, por ejemplo. No se hace una casa pequeña y después se modifica para convertirla en un rascacielos. Pero un programa puede crearse para una necesidad pequeña y después modificarse para que haga una cosa más. Por eso no decimos construcción, sino desarrollo de software. No es por las habilidades de la persona que lo desarrolla. Es por la forma en que se elaboran los programas.
Hay de programadores a programadores, los hay con mucha preparación, habilidades, profesionalismo y también los que leyeron un manual e hicieron unos programas para ellos mismos, los que solo copian y pegan código del internet. Algunos solo conocen un lenguaje de programación o un IDE. No por eso nos vamos a llamar de una manera diferente. Así como hay constructores que hacen rascacielos y otros que solo casas para mascotas. Si te dedicas a elaborar programas, eres un programador. Si no te gusta que te digan programador y prefieres que te llamen desarrollador (palabra que no existe), esta bien, yo también lo hacia; pero recuerda que un(a) programador(a) se dedica a desarrollar software.
 |
| Al leer código de alguien más. |
 |
| Leyendo código. Foto de Gabriel Flores. |
Existen formas de usar tu editor local y sincronizar archivos; pero opté por usar el editor y la consola en línea. Es una ventana en el navegador donde esta un editor de texto con un árbol mostrando tus archivos y una ventana con la terminal. Con eso es suficiente para empezar a trabajar sin necesidad de tener archivos locales, ni software instalado localmente. |
| Polo Polo. |
 |
| Presionar ALT + T, N, O. ¡Son muchas teclas! |
 |
| Una vez abierto puedo usar CTRL + TAB y con las flechas seleccionarlo, es tardado. |
En varias ocasiones al estar haciendo algo de difusión sobre las reuniones de los grupos de usuarios (en particular con tijuana.js). Me han sugerido que transmitamos o grabemos las presentaciones para poder verlas sin asistir a la reunión. He considerado esa opción aunque no le he dado seguimiento. Principalmente porque no lo veo como una prioridad para la organización del grupo. Incluso he llegado a pensar que tal vez no sea buena idea.
Para mí, la meta del grupo es ser un lugar donde personas con un interés común (JavaScript en el caso de tijuana.js) se reúnan para compartir conocimiento, ideas, experiencias, etcétera; es decir, donde se puede hablar de eso que tienen en común. También, es un espacio para conocer a "colegas" de la región.
Como parte de esa meta, uno de los objetivos del grupo es tener una presentación de calidad cada mes para que tanto asistentes como presentador puedan aprender, comentar, discutir y estar al tanto de los temas. Tomando esto en cuenta se podría pensar que al grabar las sesiones se beneficia al grupo porque podría lograr que el conocimiento se compartiera con más gente. Aunque se cumpliría con el objetivo quizás eso no contribuye a que se cumpla con la meta del grupo. Las presentaciones son un medio, no un fin, son para tener algo de que platicar en la reunión. Sin asistentes no habría razón para la existencia del grupo. En cuanto al material visto en las reuniones, si de verdad te es importante tenerlo, es fácil encontrarlo en línea. Puede ser en el blog del mismo presentador o en sitios similares.
En conclusión, no es prioridad grabar las presentaciones de los grupos porque considero que no ayuda a la meta: reunirnos, conocer “colegas” de la región, comer pizza, tomar sodas y hablar de tecnología cada mes.
Una de las ventajas de dedicarme al desarrollo de software es que se puede hacer (casi) desde donde sea y (en la mayoría de los casos) a cualquier hora. Lo único que se necesita es una computadora y motivación.
La mayor parte del tiempo que llevo como desarrollador lo he hecho desde casa y hasta el momento me ha funcionado bien. He escuchado comentarios de personas donde dicen que ellos no podrían trabajar desde casa. Una de las razones mencionadas son las constantes interrupciones. Si bien es cierto que en la oficina también ocurren, en casa pueden llegar a ser más estresantes. La diferencia al estar en casa es el tipo de interrupción, la persona que nos interrumpe y sobre todo nuestra actitud al atenderla o posponerla.
Cuando he trabajado desde la oficina de la empresa, la mayoría de las interrupciones eran por compañeros de trabajo, consultas de trabajo, preguntas del cliente, invitaciones a ir por un café o simplemente platicar. No se sienten como interrupciones, a menos que tenga algo urgente que entregar, se sienten más bien como actividades que forman parte del día laboral. Al estar en la oficina no siento la obligación de estar todas las horas de trabajo pegado en la computadora produciendo código, el simple hecho de estar presente en la oficina me hace sentir que estoy trabajando. Además mi mente sigue de alguna forma en el mismo contexto. Puedo estar platicando con mis compañeros de oficina de cosas relacionadas con el trabajo o con lo que ocurre en la oficina.
Al estar trabajando en casa las interrupciones son distintas. Hubo un tiempo en que mi esposa no trabajaba, y era sólo yo el que trabajaba desde casa (hoy ambos trabajamos desde casa). Toda mi comunicación con la oficina era a través de la computadora (chat, email, etc.). Cuando mi esposa me interrumpía, para preguntarme cualquier cosa relacionada con la casa, era algo estresante. Incluso pasaba con preguntas sencillas que no me tomaban más de unos segundos contestar. Ese “estrés” no ocurría cuando trabajaba desde la oficina de la empresa con las interrupciones ¿por qué?.
Creo que esto se debe a que las interrupciones en casa son distintas porque en lugar de ser un compañero de trabajo quien te habla, ahora es tu familia (hijo, esposa, pariente) quien te interrumpe y eso saca a tu mente del ambiente laboral. Al principio esto puede llegar a ser más estresante que las interrupciones en la oficina por el cambio de contexto. Dejas de pensar en lo que pasa en el trabajo para pensar en lo que pasa en la casa. Cambias de unos pendientes a otros y parece que tienes más cosas en que pensar (lo del trabajo y lo de la casa). Además al hablar de cosas de la casa, en la casa, sentía la urgencia de regresar al trabajo, sentía la necesidad de estar las ocho horas pegado al monitor escribiendo código.
Una forma de lograr una separación de contextos fue crear una “oficina” en casa. Utilizar un lugar en la casa donde la familia pueda ver que estas trabajando. Y por lo tanto saber que no estas disponible en ese momento, a menos que sea realmente necesario. También fue necesario un cambio de actitud de mi parte y darme tiempo para salir de ese cuarto de vez en cuando en horas de trabajo. Ya sea por agua o café y platicar un poco con la familia como lo haría con mis compañeros de oficina. No tenia que fingir que no estaba en casa para evitar interrupciones, al contrario, aprovechar que estaba en casa para estar en casa. Con esto la familia sabe que sí estas y que no tiene que interrumpirte en cuanto algo se ofrece porque seguramente no tardaras en salir y si no sales es porque estas muy ocupado. Para esto puede ayudar la técnica pomodoro.
Creo en conclusión que algo que ayuda a lidiar con las interrupciones, cuando se trabaja desde casa, es que en lugar de tratar de impedir las interrupciones en el día las incluyo como parte del día laboral. Cada cierto tiempo salgo de la “oficina”, mi mente se distrae del trabajo, atiendo las posibles interrupciones en ese momento cuando ya no estoy pensando en trabajo. Estas “interrupciones programadas" evitan el estrés por el cambio continuo de contextos. Al regresar a la computadora mi mente esta lista para empezar otro periodo de trabajo continuo, sin interrupciones sorpresa.
El pasado sábado 27 de Julio las comunidades tecnológicas de Tijuana (grupos de usuario) realizaron su reunión mensual el mismo día como parte de un mismo evento. Cada grupo contó con una hora para realizar su presentación. Uno de los objetivos del evento fue, para quienes no pueden asistir a todos los grupos cada mes, en esta ocasión pudieran asistir a las presentaciones de los otros grupos. En mi caso, cada mes asisto a la reunión de tijuana.js y trato de asistir a la de Tijuana .Net. Quisiera asistir a las demás; pero no puedo dedicar tantos días al mes para vistas a user groups. El hecho de que todos se reunieran el mismo día hizo que pudiera reservar el día entero para dedicarlo a las comunidades y así fue que pude asistir a reuniones de grupos a los que no había podido asistir antes.
El evento se realizó en las instalaciones del bitcenter, el cual se a vuelto “el lugar de reunión de las comunidades” (gracias a Ricardo Rosales que nos ayuda con eso). Inició a las 8 de la mañana y a tijuana.js le tocó la primera presentación. Pensé que por ser los primeros (a las 8:30 am) iba a estar casi sin asistentes; pero la realidad fue que ya había gente, quizás más que en una reunión mensual por separado.
(Presentación "Plain old Vanilla JavaScript" por Yves Mancera)
El programa fue:
8:30 tijuana.js : "Plain old Vanilla JavaScript" por Yves Mancera
9:30 RubyTij : ¿Cómo pensar en BDD? por Javier Murillo
10:30 Google Developer Group Tijuana : Instalar Ubuntu en una Chromebook
11:30 gultij.org : Introducción a Vagrant
--- descanso de 12:30 a 14:30 ---
14:30 DefConGroup Tijuana : Intervención de llamadas VOIP
15:30 Comunidad .NET Tijuana : Xamarin (desarrollo multiplataforma con .NET)
Conforme pasó el tiempo fue llegando más gente (después de esa foto fuimos por 20 sillas más). Al final se cumplió uno de los objetivos. Que las personas pudieran conocer a los otros grupos a los que por lo general no pueden asistir. Eso fue algo que me gustó porque todos somos una sola comunidad tecnológica, sin importar las herramientas especificas que a veces utilizamos. Todos podemos aprender de todos.
Con este evento pude darme cuenta que hay más gente (además de quienes participan mes con mes) que les gustaría asistir a las reuniones de la comunidad; pero que por motivos de horario y/o distancia (había gente fuera de Tijuana) no logran asistir. Este tipo de eventos les da la posibilidad de participar en la comunidad. Algo a tomar en cuenta es que al ser un evento que reúne a varios grupos, es difícil tratar temas de nivel intermedio o avanzado. Por lo que se llegó a la conclusión de seguir con las reuniones mensuales por separado y una vez cada ciertos meses realizar la reunión en conjunto.
Aunque la mayoría de la promoción se realizó con el evento en Facebook, las fotos del evento se publicaron en Google+. Échenles un vistazo y nos vemos en el siguiente inter-comunidades Tijuana.
Desde hace algún tiempo, cuando un proyecto necesita acceder a una base de datos relacional, lo común es utilizar un ORM. El ORM se encarga de realizar la conversión desde objetos/colecciones en el lenguaje de OOP a registros/tablas en el modelo relacional y viceversa. En otros proyectos se ha optado incluso por usar una base de datos no relacional (NoSQL), donde no es siquiera necesario el mapeo entre clases y tablas. El uso de estas herramientas (ya sea ORM o NoSQL) nos ayuda a trabajar en un nivel más alto de abstracción. Ya no vemos SQL directamente, ahora trabajamos con objetos (entidades) como nuestros datos.
Si seguimos con el ejemplo del artículo anterior, donde se nos pide que un usuario pueda ingresar a un sistema usando su nombre y contraseña. Al usar herramientas como EntityFramework (un ORM) podemos cambiar nuestra capa de acceso a datos.La cual pudiera usar EF para realizar las consultas y actualizaciones. De esta forma no necesitamos escribir SQL y seguimos con nuestra misma arquitectura en 3 capas. Quedando el código algo así:
public User FindByUsername(string username){var db = new MySampleAppContext();return db.Users.SingleOrDefault(user => user.Username == username);}
Pero nuestro objetivo no es tener 3 capas, ese era solo un medio para un fin. Recordemos para qué tenemos nuestra capa de acceso a datos. La capa de acceso a datos existe para que la capa de reglas de negocios no tenga que ”pensar” en detalles de tablas, registros y SQL. Es la misma razón por la que existen los ORMs, para abstraer el acceso a datos. Entonces… nuestra capa de acceso a datos es una abstracción del ORM que a su vez es una abstracción del acceso a datos, una abstracción redundante. Debemos de limitar nuestras abstracciones por lo que podemos utilizar el ORM directamente en nuestra capa de negocio. De ese modo podemos aprovechar mejor las características de la herramienta y nos ahorramos el trabajo de mantener una capa ya innecesaria. Comparemos el código de la capa de negocios con y sin una capa de acceso a datos.
//con capa de acceso a datospublic bool ValidateUser(string username, string password){var userRepository = new Dal.UserRepository();var user = userRepository.FindByUsername(username);if (user == null) return false;var cryptoService = new CryptoService();return cryptoService.ComputeHash(password) == username.Password;}
//Usando ORM en la capa de negociospublic bool ValidateUser(string username, string password){var db = new MySampleAppContext();var user = db.Users.SingleOrDefault(x => x.Username == username);if (user == null) return false;var cryptoService = new CryptoService();return cryptoService.ComputeHash(password) == username.Password;}
Podemos ver que el código es muy similar; pero usando EF ya nos ahorramos una capa (un proyecto). Podemos hacer uso de características de EF desde nuestra capa de reglas de negocio (como lazy loading, entre otras) sin tener que tratar de replicarlas en nuestra capa de acceso a datos.
En conclusión podemos decir que ahora, con el uso de herramientas como ORM (o una base de datos no relacional), ya no es necesario crear una capa de acceso a datos porque las herramientas cumplen con el propósito que tenia esa capa. La capa de acceso a datos tenia sentido cuando escribíamos SQL directamente en nuestra aplicación; pero ya no.
Artículo relacionado: Sobre arquitectura en capas – parte 1
El pasado Sábado 27 de Abril asistí al octavo SHDHTJ en las instalaciones de MindHub. Inicio a las 9 am aunque hubo quienes llegaron desde antes. Después de que llegó algo de gente se hizo una presentación sencilla por parte de Gabriel Flores sobre de lo que se trata el evento. Hubo caras nuevas y algunas ya conocidas.
Una buena noticia que nos dieron al iniciar el evento fue que MindHub, por el gusto de haberlos elegido como sede del evento (sus palabras), nos quisieron regalar las pizzas para los asistentes. Lo cual fue un buen detalle que fue bien recibido. Además los asistentes cooperaron con sodas, cervezas, vino, queso y botanas. También Octavio Álvarez llegó con lo que había quedado del code retreat que había sido una semana antes.
En esta ocasión hubo menos interrupciones externas, por lo que tuvimos más oportunidad de trabajar en el proyecto que teníamos en mente. Trabajé haciendo pair programming con Gabo en lo que pretendemos será el nuevo sitio para la Comunidad .Net Tijuana. La idea es trabajar con algo nuevo y ligero como WebMatrix que es algo que no utilizo.
(Foto por Gabriel Flores)
Hubo buenas platicas en el transcurso del día y conocí a gente nueva. Al final no hubo presentación de proyectos como la edición pasada pero sí platicamos sobre ellos. Algo nuevo para mi en este tipos de eventos fue que, en lugar de programar con cerveza y papás fritas, ahora lo hicimos con vino tinto, queso, tomates secos y pitas (cortesía de Javier Aguilar). Ahora no podrá faltar el vino en los siguientes SHDHTJ.
Fue una experiencia muy agradable, al final del día había ganas de seguirle en un after party.
Aun veo proyectos que separan los componentes de la aplicación en capas, utilizando el viejo modelo de 3 capas, el cual siento que ya no es la mejor opción ya que la forma de desarrollar software ha cambiado. En esta serie de artículos pretendo explicar porque ya no es necesaria una separación en 3 capas al momento de desarrollar un nuevo proyecto de software.
Primero debo empezar por definir qué es es la arquitectura en capas para mi, así que esta primera parte trata sobre eso.
¿Qué es la arquitectura en capas?
La arquitectura en capas consiste en separar las responsabilidades de nuestra aplicación de una manera horizontal. Esto se hace con la intención de elevar el nivel de abstracción. Ocultar la plomería de la aplicación poniendo una capa de abstracciones sobre ella. Las típicas capas de esta arquitectura, iniciando de abajo hacia arriba, se describen a continuación.
Capa de acceso a datos (también conocida como DAL por sus siglas en ingles): Es donde se escribe el código que habla con la base de datos. Es en esta capa donde se definen las consultas a la base de datos (el SQL). No realiza validaciones entre entidades, sólo las validaciones que van hacia la base de datos. La intención de esta capa es que el resto de la aplicación no se preocupe de los detalles (en cierta medida) de la estructura de la base de datos y trabaje a un nivel de objetos. Es la encargada de la entrada y salida de datos hacia y desde la base de datos. Ya que no debe de preocuparse de las reglas de negocio el código de la capa debería de ser fácil de seguir y de mantener. Las capas construidas encima de esta (es decir que usen esta capa) deben de dejar de pensar en tablas y registros para pensar en objetos y colecciones.
Capa de reglas de negocio (BL): Una vez que tenemos la abstracción de la capa de acceso a datos, sobre ella se construye una capa. En esta capa es donde se escriben las reglas de negocio, validaciones que involucran varias entidades, validación de estados y condiciones definidas en los requerimientos. Usa a la capa de acceso a datos para realizar las consultas y actualizaciones a la base de datos. La capa de negocio no sabe cómo es presentada la información al usuario o de cómo fue capturada por él. Al no preocuparse de como se presenta la información (UI) o de como es que se almacena (DAL), en el código solo deben observarse que las reglas (de negocio) definidas en los requerimientos se cumplan.
Capa de presentación (UI): Lo que el usuario ve. Es la capa donde se crean los componentes de la interfaz de usuario. Esta capa utiliza a la capa de negocio para realizar la tarea que el usuario requiera. La capa de negocio validará y regresará el resultado o error y la capa de presentación los mostrará al usuario. Entonces el código en esta capa sólo se encarga de pasar valores a la capa de negocio y de desplegar información, en la interfaz de usuario, que viene de la capa de negocio.
Hagamos un ejemplo para entender mejor a que se refiere cada capa. Supongamos que se nos pide que en la aplicación que estamos desarrollando un usuario pueda ingresar al sistema con un nombre de usuario (username) y contraseña validos. Separando nuestra aplicación en capas como las definidas anteriormente tendríamos las siguientes clases (en C#).
Primero la capa de acceso a datos
namespace Dal{public class UserRepository{public User FindByUsername(string username){User user = null;var sql = "SELECT * FROM User WHERE Username = @Username";using(var connection = new SqlConnection(Config.ConnectionString)){var cmd = new SqlCommand(sql, connection);cmd.Parameters.AddWithValue("@Username", username);connection.Open();using(var reader = cmd.ExecuteReader()){user = reader.read() ?new User(username, reader["password"]) : null;}return user;}}}}
Ahora la capa de reglas de negocio:
namespace BL{public class UsersService{public bool ValidateUser(string username, string password){var userRepository = new UserRepository();var user = userRepository.FindByUsername(username);if (user == null) return false;var cryptoService = new CryptoService();return cryptoService.ComputeHash(password) == username.Password;}}}
Por último la capa de presentación:
...void LoginButton_Click(object sender, EventArgs e){var usersService = new UsersService();if (usersService.ValidateUser(usernameTextbox.Text, passwordTextbox.Text))MessageBox.Show("Bienvenido");elseMessageBox.Show("Usuario o contraseña incorrectos");}...
Aquí puede verse la separación de la lógica en capas. En lugar de hacer la consulta a la base de datos directamente en el método de clic del botón, la capa de presentación delega la validación del usuario a la capa de negocio. La capa de negocio a su vez delega a la capa de acceso a datos la creación y ejecución de las consultas en SQL sobre la base de datos.
Así era como desarrollábamos una aplicación hace años; pero ya no.
Artículo relacionado: Sobre arquitectura en capas – parte 2
