Haz que funcione, entonces hazlo hermoso, entonces si real, realmente tienes que hacerlo, hazlo rápido. El 90% del tiempo, si lo haces hermoso, será rápido. Así que realmente, ¡tan solo hazlo hermoso! Fue una de las frases que nos dejó Joe Armstrong pero, ¿sabes a qué se refiere?
Leer más =>>
Cuando comencé a utilizar git intentamos emplear también gitflow. Lo comentaba como algo factible en un artículo de 2012. En estos momentos y tras 9 años de trabajo con git, tengo que admitir que no emplearía gitflow, ¿quieres saber mis motivos?
Leer más =>>
Hace unos días pregunté a unos amigos ¿cómo estimáis un proyecto de software? queriendo saber no las tarifas, precios o costes específicos a tener en cuenta sino el proceso y los factores a tener en cuenta y comprobar si lo hacía bien o mal, ¿cómo lo estimáis vosotros?
Leer más =>>
En 2012 escribí un artículo sobre el lenguaje Go y desde entonces no me tomé mucho en serio esa plataforma. Esta última semana después de 6 años y viendo el auge que está teniendo me he propuesto hacer un proyecto. ¿Lo revisamos?
Leer más =>>
Al construir nuestro sistema de chat nos encontramos ante un problema: los dispositivos móviles no son confiables. No mantienen una conexión constante a Internet y pierden la conexión fácilmente. Por otro lado XMPP está ideado para conexiones permanentes y confiables a Internet. ¿Cómo podemos usarlo sin perder información?
Leer más =>>
Uno de los grandes problemas al hacer una aplicación de chat para el móvil es la poca fiabilidad de las redes móviles. XMPP no fue diseñado para este tipo de escenarios pero las últimas versiones de ejabberd y MongooseIM vienen a darnos la solución, ¿implementamos nuestro chat?
Leer más =>>
El pasado 22 de julio estuve dando una charla a un grupo de estudiantes de un curso de programación dado por Fernando de Sopinet y surgió la pregunta de ¿cómo mejorar en la programación? ¿qué podemos hacer para mejorar nuestra forma de programar?
Leer más =>>
Este mes he revisado las empresas a las que he ayudado a implementar sistemas de chat basados en ejabberd o MongooseIM, son ya 9 las empresas que han confiado en mi para ayudarles en España, Francia, UK, Luxemburgo, Finlandia y Estados Unidos. Todos intentan copiar los pasos de WhatsApp, ¿cómo montan sus sistemas?
Leer más =>>
De vez en cuando la gente se reúne y medita sobre las acciones que se están llevando a cabo para el desarrollo de software. Esta actividad de reflexión es muy positiva y nos proporciona estudios o manifiestos muy interesantes. En este caso quiero hablar de uno llamado The Twelve-Factor App para aplicaciones web que se ofrecen como servicio (Software as a Service, SaaS), ¿de qué se trata?
Leer más =>>
Uno de los avances más grandes en el desarrollo del software fue el intento de estandarizar, industrializar o sistematizar el proceso de creación del software. Este esfuerzo nos ha llevado a disponer de técnicas de gestión del tiempo, procesos y tareas. Ha evolucionado la generación de software. ¿Qué debemos hacer? Indica el análisis. ¿Cómo lo hacemos? Indica el diseño... pero, ¿Por qué lo hacemos?
Leer más =>>
En proyectos actuales como Android donde Microsoft ha perdido terreno contra este sistema operativo abierto deja presente que el software desarrollado por una comunidad activa suele tener una calidad y un ritmo de crecimiento mientras que el software propietario crece únicamente según la inversión económica que se le destine. ¿Aún piensas que hay ventajas en el software propietario?
Leer más =>>
Una de las cosas que más parecidas puede tener un juego de rol con la actividad de un programador son las destrezas. En los videojuegos, las destrezas básicas de un personaje suelen ser: velocidad, fuerza, agilidad e inteligencia. ¿Cuáles serían las destrezas a medir entre los desarrolladores y administradores de sistemas?
Leer más =>>
Hace tiempo escribí una entrada sobre la posibilidad de utilizar XMPP como elemento para SOA (service oriented arquitecture, arquitectura orientada al servicio), hoy vuelvo de nuevo con la idea y amplio un poco más gracias a este artículo (en inglés) que me ha llamado la atención sobre el hecho, ya no solo como sistema SOA, sino también como ESB (enterprise service bus, bús de servicio empresarial), para mantener comunicación entre todos los recursos de un sistema de la información.
Leer más =>>
Al entrar en mi nueva empresa me topé con un cambio drástico en la forma en la que los elementos de la infraestructura se comunican entre sí. Para entenderlo mejor, mi compañero Iván me dejó el libro XMPP: The Definitive Guide, escrito por Peter Saint-Andre , Kevin Smith y Remko Tronçon.
Leer más =>>
Hace poco que comencé a trabajar de forma activa con git. Antes había tenido algunas incursiones para saber qué era, pero sin quedarme del todo claro hasta entrar en la práctica con proyectos como ecomponent u otros internos que desarrollo dentro de la empresa en la que trabajo.
Leer más =>>
Una de las bases de las metodologías de desarrollo de software es definir cuándo una tarea ha sido realizada o terminada. Parece algo obvio pero muchas veces se fracasa debido a una mala estimación a causa de estimar tareas basadas en el tiempo medido entre su inicio y cuando se dice que se ha terminado.
Leer más =>>
Hace un tiempo (ya unos años), escribí algo que había leído del blog de Joe Armstrong acerca de websocket, hoy retomo el tema después de leer un email de la lista de ErlAr, de un mensaje de Mariano Guerra en el que nos da estos datos sobre un banco de pruebas realizado con varias librerías, en varios lenguajes, sobre el uso de websocket:
Leer más =>>
Una de las potencias de Erlang y el framework OTP, son los comportamientos (o behaviours), estos se basan en la [Inversión de Control][1], es decir, que existe un código base que se autocompleta a través de la implementación de unos callbacks definidos en la plantilla, que deben de ser implementados para que todo funcione correctamente.
Leer más =>>
Una clase, una responsabilidad, fue uno de los textos que se me quedó grabado tras la lectura del libro Diseño Ágil con TDD de Carlos Blé.
Leer más =>>
El servidor Node.js vió la luz de manos de Ryan Dahl en 2009, la motivación, según la entrevista que BostInno le realizó en enero de 2011, es la arquitectura de E/S orientada a eventos.
Leer más =>>
Bueno, ya tocaba, después de dedicar varios apartados al desarrollo web, toca dedicarle un pequeño, aunque importante apartado a una herramienta de comprobación (tests) como es Selenium.
Leer más =>>
Hace tiempo que vamos encontrándonos de forma recurrente con este problema… ¿cómo conseguir que PHP realice un trabajo en background e ir consultando cuánto le falta o cuando ha terminado dicho trabajo?
Leer más =>>
Siempre he dicho que cada lenguaje tiene su potencia, si PHP son sus estructuras de datos (arrays) que permiten formas heterogéneas y de fácil administración y presentación, Perl es la versatilidad y potencia que proporciona su sintaxis escueta y orientada al resultado, Ruby es la reescritura en tiempo de ejecución… Python, sin duda, es la elegancia.
Leer más =>>
Después de leer varios artículos sobre Erlang, algunos defendiéndolo y otros criticándolo, me doy cuenta de que, realmente, no todo el mundo entiende lo que es y significa este lenguaje. En sí, no es el lenguaje, sino la metodología que hay detrás la que está moviendo el hecho de que los lenguajes funcionales sean como son y sirvan, de la forma correcta, a los propósitos para los que fueron creados.
Leer más =>>
Llevo un tiempo interesado en los analizadores léxicos y sintácticos para poder crear ficheros de configuración más amigables o sistemas de interfaces de usuario basados en consola que puedan emplear un formato libre de construcción de instrucciones (algo más complejo que el típico comando y argumentos). Eso sumado a mi afición por Erlang dio como resultado el encontrar: leex y yecc; un analizador léxico y sintáctico respectivamente.
Estas búsquedas, igualmente, dieron con una serie de lenguajes nuevos, que han sido desarrollados usando estos analizadores, sobre Erlang, por lo que aprovechan sus ventajas, y salvan algunos de los inconvenientes que tienen algunas personas al ver Erlang por primera vez, con respecto a la sintaxis del lenguaje y la asignación única de variables.
Leer más =>>
Repasando un poco la bibliografía básica para el lenguaje Perl, topé con este libro, que tienen muchos programadores como base para la escritura de código en este lenguaje. El libro tiene una extensión considerable, pero se hace bastante ameno. Insta a escribir el código de una forma ordenada y que se refactorice todo lo que huele para mejorar el mantenimiento del mismo.
Leer más =>>
Hace tiempo que llevo pensando que quizás, la retribución de un programador por horas, sea tirar el dinero. Esto no quiere decir que sea algo bueno o malo, ya que hay programadores de todo tipo, de los que cada hora que se les paga es muy invertida de forma muy provechosa para la empresa, y otros que es todo lo contrario.
Leer más =>>
Tal y como reza su web The Cloud Language (el lenguaje de la nube), este lenguaje sale como una solución a la programación de sitios web cumpliendo con unas necesidades concretas. La empresa MLState ha puesto como su bandera a este lenguaje, sobre el que está orientando toda su actividad comercial.
Leer más =>>
Hace un tiempo, Juanse, un compañero de trabajo, me envió un enlace de un framework desarrollado por Evan Miller que se llama ChicagoBoss. Este framework ha sido concebido con Ruby on Rails en mente, no es de extrañar cuando a lo largo de toda la documentación, se hacen referencias a cosas de Ruby on Rails, y las similitudes son tan extraordinariamente grandes, para ser dos lenguajes bastante diferentes.
Leer más =>>
Hay momentos en los que vemos que la carga de una página tarda demasiado, o que el uso de un recurso, que en principio habíamos creído que era menor, sube y su tiempo de ejecución hace que nuestro servidor sufra. Trazar estos problemas a simple vista o a través de trazas no es más que complicar el código y hacer que varíe su línea de ejecución y, con ello, el rendimiento en sí del mismo, por lo que, nos hace falta una herramienta a alto nivel, que no implique cambiar el código, que nos permita realizar este tipo de comprobaciones sobre el código. Esta es Xdebug.
Leer más =>>
Durante unas pruebas en el trabajo, enseñando a mi mujer (Marga), cómo funciona Ruby con su mayor potencia, la reescritura de código y los yield, pensé: con lo que me ha costado... mejor lo guardo en el blog. Y esto es :-)
Leer más =>>
Leyendo un artículo de Martin Fowler, sobre el tema Inversión de Control (en inglés), comenzando por el final, la etimología de la frase (entendido como el origen del concepto), se comenta que, en un principio (sobre los años 80) la gente se refería a una nueva forma de hacer las cosas como el Principio de Hollywood, teniendo presente la famosa frase de los cineastas: “no nos llames, nosotros te llamaremos”.
Si pensamos en las librerías, en cualquier lenguaje, ya sean módulos, paquetes u objetos, siempre alcanzamos una funcionalidad encapsulada dentro de una forma específica a la que se la puede llamar para realizar una acción. Pero esto cambia radicalmente en los frameworks, u entornos de desarrollo, ya que estos entornos, normalmente, realizan un cierto trabajo, y te permiten extender esa funcionalidad base, con ciertas reglas, a través de código que se escribe.
Leer más =>>
Después de haber dado una vuelta por la versión estable de rails, he reparado en que, por defecto, se instala bundler y un fichero llamado Gemfile en la raiz de cada proyecto rails que se genera nuevo.
La verdad es que, en el momento que vi el fichero de Gemfile, queda clara la misión de dicho fichero, ya que viene con una colección básica de gemas que se suelen instalar de forma base cuando se trabaja con rails (out of the box) y unos comentarios de gemas que aconsejan para ciertos usos cotidianos (opcionales).
Leer más =>>
Hay muchas veces que nos encontramos con el problema de que queremos extender la funcionalidad de nuestro programa por extensiones, plugins, addons o como los queramos llamar. Estas extensiones tienen el problema de que pueden afectar al funcionamiento del resto del programa si lo ejecutamos directamente desde el core del programa que estemos haciendo, quedando el mismo en una situación inestable o nada funcional.
Leer más =>>
En estos últimos días, hablando con colegas del tema de realizar proyectos/productos en los que pudiésemos tener mayor visibilidad, mayor participación, ya que somos la mano de obra que se encarga de su realización, llegamos a la redacción de esta carta:
Leer más =>>
Hace ya más de un año que escribí una entrada sobre ETL, donde comentaba los principios que lo fundan y algún que otro software disponible para realizar ETL. Revisando la entrada, me he dado cuenta de que el software que entonces encontré, ha cambiado bastante, incluso uno de ellos ha desaparecido como tal.
Leer más =>>
Cuando comencé a leer libros sobre Extreme Programming, me llamó la atención una de las propiedades de esta metodología de desarrollo, que era la propiedad del código.
Por mi parte he sido siempre muy comunista con respecto al código, no tengo el menor reparo en mirar, ampliar y corregir código de otras personas y dejo que los demás vean, opinen y corrijan y/o agreguen cosas a mis códigos… es la mentalidad del software libre.
Pero en las empresas ocurre lo contrario. Es muy normal, yo diría que incluso enfermizo, llegar a ver cómo cuando entras en una empresa en la que hay más de tres programadores, cómo cuando algo falla, cuando hay que hacer una nueva mejora, ampliación, adaptación, siempre dice uno en voz alta: ese código es de fulanito; indicando que ni lo va a ver, ni lo piensa modificar.
Leer más =>>
Una de las personas que más ha aportado al mundo del desarrollo de software es, sin duda, Martin Fowler.
Esta es una práctica que realicé (y comenté) en diciembre de 2008 para la asignatura de Programación III de la UNED.
La práctica se basaba en realizar un sistema para resolver tableros de shikaku, mediante el algoritmo de vuelta atrás. Mi solución es óptima pero no del todo correcta desde un punto de vista académico, ya que el uso del algoritmo (de backtracking) es menos usado de lo que debería.
Leer más =>>
El tema de la calidad ha llenado páginas y páginas de la literatura informática en todos los idiomas. Es tal la necesidad de la búsqueda de la calidad, que hay estudios, técnicas y departamentos dentro de empresas e incluso empresas dedicados a establecer parámetros de calidad a los productos y proyectos que se realizan en las empresas de desarrollo de software.
Dentro del tema de la calidad, visto como un amplio abanico de elementos que la conforman, nos topamos con uno bastante confuso y complejo al principio: la calidad interna.
Leer más =>>
Mi amigo Guillermo me remitió un email hace poco en el que detallaba un concepto que ya conocía hace tiempo, pero que no había visto tan bien explicado hasta el momento (sí, tenía que haber leído antes a Cunningham), el tema era: La deuda técnica en scrum, ¿lo revisamos?
Leer más =>>
Actualizado: se ha corregido el concepto, ya que se confundía con la definición de glosario, cuando se quería detallar que era algo más que un glosario.
En todas las empresas en las que he trabajado, siempre surge el problema de que, cuando sale algo nuevo o se crea un cierto programa, un sistema o una forma de trabajo, si la persona que la ha motivado no sabe su nombre: se la inventa.
Leer más =>>
Hace tiempo, en reuniones mantenidas por todo el departamento técnico, sobre todo la parte de I+D, de la empresa en la que trabajo, mi compañero Juan Sebastián me comentó: podemos hacer la documentación en un blog.
Leer más =>>
Hoy he reparado en una web (que he agregado a mis enlaces) que trata sobre temas de la programación y, en definitiva, se centra en hacer buen software.
Es algo complejo determinar qué es buen software y qué no lo es, por lo que estos siete consejos pueden ayudar a detectar lo que se puede considerar buen software y lo que no. En definitiva y después de muchos años desarrollando, así como leyendo a gente que al igual que yo lleva también muchos años en esto, la clave para hacer buen software es programar lo único necesario para cumplir el objetivo marcado, ni una línea más. Y como dice Alberto: no hay problemas difíciles, solo soluciones difíciles.
Leer más =>>
Hace poco me he encontrado con un problema. Tengo un entramado de servidores y comunicaciones entre cada uno de ellos. Cada servidor puede notificar, ya sea vía SOAP, HTTP, XMPP o mediante cualquier otro protocolo, un evento o una información a otro servidor del entramado, con lo que cada servidor se configura de una forma específica, con una serie de nombres de dominio o IPs.
El problema viene al querer aplicar escalabilidad al proyecto. Cuando no solo hay un equipo implicado, sino que existen dos o tres, los cuales hay que configurar bajo ciertas circunstancias.
Leer más =>>
La empresa en la que trabajo hace unas semanas ha comenzado a moverse para obtener una medición del coste de los desarrollos realizados internamente en el departamento. Es positivo y sirve para obtener datos de costes útiles para el desarrollador, programador y obviamente para los directivos que podrán tomar mejores decisiones basados en estos datos.
Leer más =>>
El manifiesto ágil fue fruto de una reunión que se mantuvo en Salt Lake City en marzo de 2001. Diecisiete críticos de los modelos de mejora del desarrollo del software basado en procesos, convocados por Kent Beck, padre del Xtreme Programming, escribieron el siguiente manifiesto:
Leer más =>>
La web concurrente, a prueba de fallos y distribuida ya va siendo más fácil de desarrollar gracias a dos iniciativas paralelas. Una de ellas es Erlyweb, el entorno desarrollado por Yariv Sadan que permite realizar de forma fácil sitios web en lenguaje Erlang. La otra es Lift, un framework de desarrollo web para otro lenguaje funcional: Scala.
Leer más =>>
Leyendo un artículo de una página de una empresa suiza (Crisp), he visto a lo que se refiere la planificación de póker. Voy a traducir gran parte del artículo para explicarlo.
Leer más =>>
Desde hace unos meses, he estado envuelto en algunos proyectos, en los que he intentado dar un enfoque basado en patrones y estándares, para facilitar y simplificar los problemas. Solo que, hay patrones y sistemas, o frameworks, que son algo incompatibles entre sí.
Por ejemplo, el uso de un sistema BPM, puede ser compatible con un sistema REST como Ruby on Rails, mientras se mantenga la idea de REST… en cambio, si se modifica por intentar realizar un poco interoperatibilidad entre otros sistemas, a los cuales no se les quiere cambiar mucho la forma… se convierte en un infierno.
Leer más =>>
Cuando tenía doce años, comencé a programar en Basic, en un ZX Spectrum de 128K… en esos momentos, y los años siguientes, hacer un programa, para mi, era sentarme delante de mi ordenador, durante unas cuantas horas, incluso echando noches en vela, para al final ver el resultado… un pequeño programa de gestión de contactos, un juego de puzzle, tetris, plataformas 2D… y eso, a lo largo de los años… y de los lenguajes, pasando por Basic, C, C++, Modula-2, Pascal, Java, Perl, PHP, Python, Ruby, Erlang…
La programación se convierte, en mi vida, en mi tiempo libre y, después, en mi trabajo, en una forma de realizar programas de ideas que me surgen, de forma <em>heróica</em>, y sin una fuerte organización que me permita ver el resultado de mi esfuerzo, ni las horas que voy a invertir, ni si merece la pena hacerlo de una cierta forma u otra.
Leer más =>>
Las herramientas CASE (Computer Aided Software Engineering, Ingeniería del Software Asistida por Ordenador), son herramientas diseñadas para dar soporte al programador a través de una interfaz intuitiva y gráfica que le permita, mediante el posicionamiento de objetos gráficos concretos, relacionados entre sí siguiendo una nomenclatura específica, desarrollar la base de un programa automáticamente.
La programación siempre ha estado respaldada por el diseño de gráficos que, de un solo vistazo, den una imagen gráfica de lo que hace un programa, como se estructuran los datos que maneja, o cómo se organiza el código que se está escribiendo. Esto se hace mediante diagramas como los de flujo de datos, organigramas, entidad/relación, jackson, OMT y UML, entre otros.
Leer más =>>
En este cuento voy a intentar explicar lo que significa programar rápido y lo que significa programar de forma ágil. La primera forma sería la que se considera comenzar lo antes posible, para terminar lo antes posible... pero ciertamente, sin planificación, dar palos de ciego a ciertos niveles de implementación, es más lento que planificar la estrategia de desarrollo a priori. Vamos a verlo con el cuento de...
Leer más =>>
Al igual que en Java se pueden ejecutar lenguajes scripting tales como Ruby (JRuby), Python (Jython), Groovy... es posible hacer esto mismo en otros lenguajes, como C y Erlang.
Leer más =>>
Este término, ETL, se acuña a la mayoría de transformaciones de datos que deben de realizar empresas para compatibilizar sus datos con los de sus proveedores y/o clientes.
Leer más =>>
Después de haber estado adentrándome en TDD, muy poco a poco, he visto que el primer paso para hacer más fácil esta doctrina, son las pruebas unitarias.
Las pruebas unitarias son pruebas que se realizan sobre unidades aisladas de código, generalmente objetos, para asegurar que, con unos ciertos valores de entrada, siempre se reciben los mismos valores de salida, o los valores de salida que se esperan.
Leer más =>>
Mi última entrada sobre Scrum, hablaba de la implementación del gráfico Burndown, de esto hace ya casi 3 meses, aunque realmente, comenzamos la andadura en algo antes.
En principio, tengo que tener presente que he estado usando algunas otras metodologías, como la Espiral de Boehm y Metrica-3, con lo que, he podido ver y sufrir en mis propias carnes, lo que significa e implica usar una metodología ágil, las ventajas que aporta y lo fáciles que tienden a ser, realmente.
Leer más =>>
Citando a Kent Beck, de su libro Extreme Programming Explained:
Leer más =>>En La Gente del Bosque y La Gente de la Montaña, el antropólogo Colin Turnbull dibuja el contraste de dos sociedades. En las montañas, los recursos eran escasos y la gente estaba siempre al borde de la hambruna. La cultura a la que evolucionaron era horrible. Las madres abandonaban a sus bebés, los entregaban a hordas de niños salvajes errantes en cuanto tenían opciones mínimas de sobrevivir. Violencia, brutalidad y traición estaban a la orden del día.
Después de haber usado durante unos años sistemas RPC para la compartición de la información, XML-RPC, SOAP y Elm; llego a REST, un concepto que mencionó primero un compañero de trabajo, Juanse, y después vi en profundidad en un curso de Ruby on Rails que se organizó en la empresa en la que trabajo (gracias Dani por ese curso tan completo).
Leer más =>>
Cuando se pensaba en MVC, la capacidad para dividir las tareas obvias de tratamiento de datos, en lógica de negocio (el modelo), control de flujo de ejecución (el controlador) y la presentación de datos (la vista), aún quedaban en el aire muchos problemas en lo que respecta a las interaces, propiamente dichas, entre estas tres capas.
Centrándonos en la vista, existen miles de soluciones, para alejar al diseñador del código y al programador del diseño, pero aún así, cuando se habla de AJAX y desarrollos específicos... el programador tiene que tocar diseño y el diseñador preocuparse de lo que hará el código de servidor.
Leer más =>>
En estos últimos días he visto los nuevos lanzamientos, o lo que se espera lanzar en varios "mundos" del desarrollo del software. Por un lado, hay varios puntos donde la interfaz pasado-futuro corre bastante peligro.
Los desarrolladores de ciertos lenguajes han creído conveniente romper con el pasado de uso de dichos lenguajes para acogerse a los progresos y prácticas más usadas actualmente. Haremos repaso.
Leer más =>>
Revisando los tipos de lenguajes de programación existentes, llego a esta clasificación de los mismos:
Todos estos lenguajes de programación obedecen a una necesidad y/o ideología subyacente, que motivó el desarrollo del lenguaje con la metodología y sintaxis específica. A continuación describiré algo más en detalle cada uno de los anteriores.
Leer más =>>
Entre los patrones de diseño que ya comenté en otro post, quiero agregar uno que dejé pasar, y al que he retomado hace poco, tanto de forma teórica, como para implementación en algunos desarrollos. Es el patrón de diseño Proxy.
Este patrón es usado para agregar una capa de seguridad sobre un sistema ya desarrollado y que es totalmente ajeno a este aspecto. Es decir, podemos desarrollar un sistema de control de almacén en el que solo tendremos en cuenta el stock en sí del almacén y, para agregar los usuarios, permisos y demás, entonces, agregamos el la capa proxy que se encarga de asegurar el acceso solo a los usuarios que deban de poder acceder.
Leer más =>>
Hace tiempo, comenté acerca del desarrollo web en plataformas como Java, PHP, Erlang, Python... en ese momento, veía la maraña en la que está tejida la red de redes, el abanico de posibilidades a la hora de desarrollar una aplicación web y comenzaban a sonar términos como CRUD, SOA, MVC, ActiveRecord, Scaffolding...
Es una verdad que cada entorno, en cada lenguaje, ha ido implementando una serie de características que facilitasen y acelerasen la creación de entornos web, de toda índole, en poco tiempo y, una vez aislada la idea base, dado un nombre e incluso un acrónimo de tres letras (como el buen Jargon file manda :-) ), se convierte en un concepto de estudio e implementación en el resto de lenguajes.
Leer más =>>
Desde hace tiempo, la tendencia de uso de los sistemas de control de versiones, ha sido el uso centralizado mediante sistemas tan populares como CVS o Subversion. Ahora, desde que muchos grandes proyectos optaran por los sistemas de control de versiones distribuidos, cada vez hay más gente que se va cambiando a ellos y, sobre todo, proyectos grandes.
¿Será que es mejor el enfoque distribuido al centralizado?
Leer más =>>
En estos días, después de haber pasado más de 24 horas en el último Sprint, sin descansar, donde comenté la experiencia de haber usado Scrum y XP en [otro artículo][1], volvemos a la carga.
Esta vez, con dos semanas de Sprint, bastante más tiempo, podemos realizar algunas técnicas más para poder medir cuánto vamos a tardar realmente en terminar el proyecto que tenemos entre manos.
Leer más =>>
Realizando una práctica de la asignatura de programación 3, de la Universidad Nacional de Educación a Distancia (UNED), he podido comprobar la diferencia, en coste computacional y rendimiento, que supone realizar un algoritmo mediante un algoritmo heurístico, como puede ser el de vuelta atrás (backtracking) y un algoritmo voraz (reducción).
Leer más =>>
Hace un tiempo escribí sobre Srum y XP, en ese mismo artículo, comentaba que estas técnicas, tanto Scrum como XP, eran dos técnicas que me gustaban mucho y que probaría en un futuro... bueno, pues ese futuro ya es presente :-)
La semana pasada, tuvimos, en la empresa en que trabajo, la presión de entregar un proyecto de forma rápida. Pensé que, en estos casos, lo que más se necesita es, como no, la organización. No se puede estar haciendo una actividad de desarrollo entre varias personas y estar con la cabeza preguntando siempre: ¿qué queda por hacer?; así que, me lancé, cogí dos tacos de post-it, uno de tamaño normal para las partes a desarrollar y otro de tamaño más pequeño, para las tareas que hay dentro de cada una de las partes.
Leer más =>>
Al desarrollar un programa, normalmente, el desarrollador elige un paradigma de programación y algún patrón de diseño, ya sea desarrollado por él, por su forma de trabajo a través de los años de experiencia, o tomado de alguna teoría o grupo de trabajo que lo haya conseguido transmitir.
Los grandes paradigmas de programación han llevado a que existan lenguajes de propósito general orientados únicamente a uno de estos paradigmas, o lenguajes que permiten, de una forma muy flexible, usar uno u otro de estos paradigmas.
Leer más =>>
Después de darle un repaso al libro Scrum y XP desde las trincheras, he visto que muchas de las técnicas en las que se basa, son como las que usaban nuestros profesores dinámicos en el colegio para motivarnos a participar en clase.
En esencia, es eso, que cada analista/programador se involucre en lo que está haciendo, llegue a un diseño y una finalidad y, sobre todo, que la información sobre lo que se hace, fluya sin que las interrupciones hagan que el trabajo se pare.
Leer más =>>
Desde siempre, cuando una empresa apuesta por software privativo frente a software libre o de fuente abierta, lo hace por tener cubiertas las espaldas, por tener garantías y saber que hay una empresa que responde por ese software, tanto en mantenimiento, como en incidencias graves, que pueden llegar a pagar indemnizaciones.
Este es el principal motivo de que se abogue por software propietario, simple y llanamente. Cualquier otro motivo es un mito, como cualquiera de los siguientes:
Leer más =>>
La popularización de los lenguajes de programación, hace que muchas veces, una aplicación que se desarrolló en otro lenguaje, sea portada a ese nuevo lenguaje, para demostrar su potencia, sencillez o capacidades.
Algunas veces, esos nuevos lenguajes, resultan ser muy buenas herramientas que nos permiten trabajar más rápido sin necesidad de centrarnos mucho en problemas típicos y ya salvados desde hace tiempo (como las cadenas de texto y los tamaños de memoria han sido un gran problema a la hora de escribir programas en C/C++).
Leer más =>>