Developeando

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 t

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ña

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

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

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 q

Tengo varios años leyendo y subscrito a blogs. Los leo principalmente a través de FeedDeemon (que se conecta a Google Reader ) y desde mi teléfono. Por lo que no tengo que necesariamente visitar el sitio para leer el artículo. Aun así hago clic en el link de algunas entradas para leer el articulo desde el sitio del autor y así ver los comentarios. Los comentarios enriquecen el contenido, la idea que el autor quiere expresar. Pueden aportar otra perspectiva que complementa o que incluso invalida la sugerencia del autor. Si sólo leyera el articulo sin los comentarios, me quedaría con la perspectiva del autor sin conocer las otras opiniones. Es por eso que últimamente me he puesto a pensar en el fenómeno de la “descentralización” de los comentarios. En ocasiones algunos buenos comentarios (opiniones) se pierden en twitter como respuestas a quien compartió el link. Lo mismo ocurre cuando el artículo se comparte en otras redes sociales. Puede haber buenos comentarios en las entradas que

Uno de los primeros grupos de usuarios que conocí de cerca fue el de la comunidad .net Tijuana. Antes había escuchado del grupo de usuarios de Linux ; pero nunca me acerque a ellos. Recuerdo que sentí que era algo en lo que todo desarrollador profesional debería participar . Por eso mismo empecé a asistir a las reuniones mensuales a las que tenia oportunidad y sobre todo a los eventos grandes que la comunidad organizaba. Por ese mismo tiempo comencé a suscribirme a varios blogs y sitios que trataban sobre el desarrollo de software. Noté que varios de los temas, que trataban en las reuniones de la comunidad, eran presentaciones que ya había conocido a través de esos sitios que seguía. Aun así me gustaba participar en las reuniones e invitaba a colegas a asistir. Me preocupaba que otros sintieran que no les aportaba algo nuevo una presentación que quizás podían ver en línea. Decidí participar dentro de la comunidad presentando, tratando de cambiar las presentaciones de PowerPoint por pr

En Tijuana, donde vivo, hay varios grupos de usuarios (comunidades de desarrolladores de software). Son organizados sin fines de lucro, con el fin de compartir el conocimiento entre colegas. Algo que he notado, en algunas de estas comunidades, es la falta de participación de los desarrolladores. En varias reuniones de los diferentes grupos se ve a las mismas personas participando, ya sea como presentador o asistente. Hay ocasiones que las reuniones son organizadas en escuelas y es entonces cuando se ve una gran asistencia; pero principalmente formada por estudiantes. ¿Por qué no asisten más profesionales a las reuniones? Una razón puede ser que no les gusta el horario . O es muy temprano y por lo tanto es en hora de trabajo o es tarde y prefieren ir a casa a descansar que tener que esperar a que sea la hora de la reunión. Parece que el horario “ideal” es justo saliendo del trabajo y no es el mismo para todos. No saben que existe la comunidad . Si no saben que el grupo de usuarios ex

En ocasiones, me ha tocado trabajar con clientes que constantemente están preguntando sobre el avance de alguna característica que (prácticamente) se acaba de solicitar. No se refieren al progreso del proyecto o algún modulo, sino a la tarea individual que puede tomar unas cuantas horas solamente. Problema Por un lado, esto llega a ser cansado para el equipo. Es molesto que te pregunten una y otra vez lo mismo, más aun si el tiempo que te tomas en contestar hace que la tarea sencilla te tome un poco más (esto a su vez provoca más preguntas sobre el estatus). El “¿Cómo vas?” constante desmotiva porque pone bajo estrés al equipo, evitando la creatividad. No permite que busquen nuevas y mejores soluciones para los problemas que se tratan de resolver. Esto puede llevar a que crezca la deuda técnica del proyecto, que a la larga puede resultar en costo de tiempo y dinero. Por otro lado, puede causar frustración en el cliente porque siente que no se avanza en lo que se necesita. Al estar pr