Ya se acabaron las vacaciones, es hora de volver a nuestros posts.
Tengo bastante ideas para esta nueva temporada, pero voy a empezar con un ‘quiz’.
Se te pide clasificar una aplicación según su tamaño, el número de líneas de código (LOC) o el número de objetos. ¿Cuál es tu estimación de una pequeña aplicación? Cuando dices que una aplicación es grande? Con qué valores crees que es ‘monstruosa’ o atípica?
En mi post anterior, he explicado el concepto de elasticidad como la capacidad de mover los recursos dentro de una infraestructura virtual para cumplir con las demandas de negocios y los picos de actividad, estos últimos no siempre predecibles.
Pero la elasticidad no significa unicamente la capacidad de «inflar» la infraestructura mediante la adición de recursos, pero – y sobre todo – poder «desinflarla» mediante la reasignación de esos recursos en otra parte.
Como un globo, más elástica la infraestructura, más fácil de inflar y desinflarla.
También es necesario que las aplicaciones están programadas con la elasticidad en los objetivos.
Como hemos visto en un post anterior – La calidad en el cloud – la reducción de costes sigue siendo la principal motivación para la virtualización y el Cloud, luego la capacidad de entregar la capacidad.
Cuando se trata de dimensionar la infraestructura física y un presupuesto operativo, el modelo es el siguiente:
Tengo que hacer una confesión: siempre desconfié de la noción de deuda técnica. Siempre me ha parecido un concepto de marketing.
Es como si decides comprar un coche, el vendedor te da las llaves y añade con una sonrisa: «Usted debe ya $ 10 000». Y él no habla del crédito para el auto, no, simplemente quiere decir que el coche que acabas de comprar tiene ciertos defectos que van a volverse cada vez más aparentes con el tiempo, cansarán el motor, la carrocería, incluso probablemente el conductor.
¿Cómo reaccionarías si un vendedor te dijera esto? ¿Comprarías este coche?
He sido invitado esta semana a un evento con mesas redondas entre usuarios expressando sus problemas en el mundo del Cloud y de la virtualización.
Me enteré no sólo de muchas cosas, pero sobre todo descubrí la visión de la producción sobre la calidad de las aplicaciones.
Aviso a los equipos de desarrollo: pan para hoy, mañana… Sigue leyendo
Hemos visto en el post precedente ‘Casos de uso – Encajar a la perfección‘ cuales casos de uso son aplicados más a menudo con una herramienta de análisis de código, y permiten conseguir el beneficio más alto:
Hemos visto en los dos últimos posts una serie de casos de uso muy frecuentes que requieren un número limitado de métricas, entre 10 y 20 de ellas. Estos casos de uso son l0s siguientes:
La pregunta en comentario del primer post es : ¿cuales son esas 10/20 métricas más importantes? Sigue leyendo
Siempre me sorprenden los comparativos de herramientas de análisis de la calidad de código que pretenden definir los criterios para dicha elección, cuando la única respuesta exacta a esta cuestión es que ‘esto depende’.
Si deseas comprar un coche, por supuesto efectuarás tu elección según unos criterios que van a depender del uso futuro del vehículo. Un cupé descapotable o un coche deportivo son unos objetos por cierto muy atractivos pero poco prácticos si se trata de transportar una familia numerosa, ir a la playa con tu plancha de surf o ayudar a mudar tu vieja tía.
Lo mismo ocurre con la selección de una plataforma de análisis de la calidad de las aplicaciones.
El Año Nuevo es siempre una buena oportunidad de reanudar contactos y me ha llamado alguien a quien no había estado hablando durante bastante tiempo. Como tenemos el mismo trabajo de consultoría, compartimos nuestros puntos de vista sobre cómo van las cosas y le pregunté acerca de una empresa en la que habíamos trabajado juntos.
Me dijo que sus proyectos habían ido tan caóticos que decidieron externalizar sus aplicaciones. Reconocieron que no pudieron mantener el código fuente: demasiado complejo, muchas dificultades para implementar cualquier evolución sin generar una gran cantidad de defectos, no cumplen presupuestos y la imagen y la credibilidad del departamento TI muy dañadas.
Mi primer pensamiento fue que habían dado un gran paso adelante: saben que no saben. Sigue leyendo
Christmas soon, and every year the same concern: what gifts to offer? Ideally, the one that will please most and that will not ruin us.
I was on a forum trying to find information about an MP3 player when a post caught my attention: someone had a problem with a game console and asked if replacing the faulty component would extend the life of the console.
I was surprised: I did not know you could even replace a component on a console. If some component on your PC fails, you change the motherboard. And most often, you end up completely changing the machine if it is a bit old. Beyond 3 years of age, it becomes difficult to find spare parts, and in any case, it is often more attractive financially to buy a newer model. Sigue leyendo