Skip to main content

Home/ Arquitectura?/ Group items tagged refactoring

Rss Feed Group items tagged

Pablo Lalloni

Alpha list of refactorings - 1 views

  •  
    This is a simple list of refactorings both from the original book and some later sources.
Sebastián Zaffarano

Jan Brauer - Software Guy - 2 views

  •  
    ¿Quién necesita del eclipse para hacer refactoring?
Pablo Lalloni

Download the Milestone - Scala IDE for Eclipse - 1 views

  •  
    This milestone ships with a whole lot of new features for you to try out: implicit highlight, move refactoring, scala debugger and semantic highlight are the most exciting ones. If you are like us, once you start using them you will no longer be able go back. They are simply too addictive!
Sebastián Zaffarano

Cloudreach Dev Blog: Asynchronous Code Reviews as an Efficient Way of Ensuring Code Qua... - 3 views

  •  
    Interesante para probar de ponerlo en práctica y ver qué resulta, ¿no?
  •  
    En github funciona muy muy bien el mecanismo, lo vengo usando bastante. El análisis, comprensión y diálogo que se genera a partir de los pull requests (y los reviews implícitos que esto produce, sumado a que la herramienta es muy muy buena, permitiendo cosas como poder poner comentarios y responderlos directamente en las lineas de código) son sumamente beneficiosos, ágiles y los resultados son muy buenos. Nosotros, localmente, venimos trabajando de manera similar a lo que se propone (y se acostumbra en github), tenemos branches por temas y se hace review y refactoring de las mismas antes de mergear al tronco de avance. Obviamente en este caso se extrañan MUCHO las herramientas de comunicación que provee github y que NO tenemos localmente.
munyeco

Graylog 1.1 Beta is Now Available! - 1 views

  •  
    We are pleased to announce Graylog v1.1 beta is now available and can be downloaded from here. ("All releases" section) The Graylog 1.1 release theme is about usability and ease of management. We refactored parts of the user interface to make it easier to use and faster to search.
Pablo Lalloni

Microservices and PaaS - Part II | ActiveState - 0 views

  • All aspects of deployment, monitoring, testing, and recovery must be fully automated.
  • Refactor database schemas, and de-normalize everything, to allow complete separation and partitioning of data.
  • There should be no sharing of underlying tables that span multiple microservices, and no sharing of data. Instead, if several services need access to the same data, it should be shared via a service API (such as a published REST or a message service interface).
    • Pablo Lalloni
       
      Aleluya!
  • ...5 more annotations...
  • Instead each microservice should have its own scm repository so it can truly be updated and enhanced independent of other services.
  • Gone are the days of a single monolithic database instance that's shared across all parts of an application.
  • Each microservice must have its own manifest and dependencies, instead of maintaining a global dependency list for all services.
  • Containerization brings countless advantages, particularly a consistent, isolated runtime environment that can easily migrate around the datacenter or around the globe. With Docker and other modern containerization approaches, there is very little overhead in running in a container, and considerable upside.
  • Do not build stateful services. Instead, maintain state in a dedicated persistence service, or elsewhere.
munyeco

The Twelve-Factor App - 2 views

shared by munyeco on 20 Jul 14 - No Cached
  • The twelve-factor app is a methodology for building software-as-a-service apps that: Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; Have a clean contract with the underlying operating system, offering maximum portability between execution environments; Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration; Minimize divergence between development and production, enabling continuous deployment for maximum agility; And can scale up without significant changes to tooling, architecture, or development practices. The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).
  •  
    "Introduction In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that: Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; Have a clean contract with the underlying operating system, offering maximum portability between execution environments; Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration; Minimize divergence between development and production, enabling continuous deployment for maximum agility; And can scale up without significant changes to tooling, architecture, or development practices. The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc). Background The contributors to this document have been directly involved in the development and deployment of hundreds of apps, and indirectly witnessed the development, operation, and scaling of hundreds of thousands of apps via our work on the Heroku platform. This document synthesizes all of our experience and observations on a wide variety of software-as-a-service apps in the wild. It is a triangulation on ideal practices for app development, paying particular attention to the dynamics of the organic growth of an app over time, the dynamics of collaboration between developers working on the app's codebase, and avoiding the cost of software erosion. Our motivation is to raise awareness of some systemic problems we've seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. The format is inspired by Martin Fowler's books Patterns of Enterprise Application Architecture and Refactoring. Who should
  •  
    Bueno. Eso. Compartí el que me di cuenta que puso antes Pablo en vez del original por error, pero la idea entre ambos, si la obviedad es tolerable, es idéntica :) Está muy bien estructurado en cuanto que cada factor depende de los demás a la vez que los promueve. Permite un enfoque general que incluye prácticas de arquitectura - y de armado cotidiano de productos - que posibilitan llegar donde yo entiendo - según me voy enterando - que es el lugar a donde llegar. Sin embargo, creo que ni éste departamento en sus sistemas más nuevos cumple todos y cada uno de aquellos factores. Esto, lejos de ser una crítica, es una invitación para que revisemos si es el único método posible - cosa improbabilísima - o el mejor método - también bastante improblable - a seguir. Lo que sí sostengo como un absoluto - quien no lo haría - es que es un método practicable. Mi aporte mínimo es defenderlo como uno bueno.
1 - 7 of 7
Showing 20 items per page