Group items tagged

"Effective Go provides guidelines for naming packages, types, functions, and variables. This article expands on that discussion and surveys names found in the standard library. It also discusses bad package names and how to fix them."

"What is the reason to quote at all? Consider it. It shouldn't be to allow people to scroll down to see all earlier discussions. If the news client is a bit smart, fetching the older articles from the server should be just as easy as to "scroll down". If a thread goes forth and back some times and earlier quotes accumulate, an article including all those quotes might get five-ten times larger than a posting without quotes, this wastes bandwidth and hard disk space. Therefore, IMHO, no quotes are far better than a posting at the top of all old quotes."

This article is a basic list of best practices that our Grails projects follow, gathered from mailing lists, Stack Overflow, blogs, podcasts and internal discussions at IntelliGrape.

Graham Tackley discusses how The Guardian switched all new development from Java to Scala, why they did that, what were the benefits and the problems, and why they did not choose Python+Django.

Rich Hickey discusses simplicity, why it is important, how to achieve it in design and how to recognize its absence in the tools, language constructs and libraries.

Data.js is a data representation framework for Javascript. It is being developed in the context of Substance, a web-based document authoring and publishing engine. It took some inspiration from various existing libraries such as the Google Visualization API or Underscore.js.  You can report bugs and discuss features on the GitHub issues page, on Freenode IRC in the #_substance chann el, post questions to the Google Group, or send tweets to @_substance. With Data.js you can: Model your domain data using a simple graph-based object model that can be serialized to JSON. Traverse your graph, including relationships using a simple API. Manipulate and query data on the client (browser) or on the server (Node.js) by using exactly the same API. 

"Most internal REST APIs are one-off APIs purpose built for a single integration point. In this article, I'll discuss the constraints and flexibility that you have with nonpublic APIs, and lessons learned from doing large scale RESTful integration across multiple teams."

"Microservices based architectures are not new but are suddenly in the spotlight due to their powerful and sophisticated practices enabling streamlined application development and deployment. However, transitioning from a monolithic approach to a microservices-based architecture requires not only technical expertise, but organizational buy-in as well. In a recent ActiveState webinar, John Wetherill and Phil Whelan discussed a number of tips and tricks to help companies transition to and get the most out a microservices-based approach."

"OpenStack and Docker will continue to dominate the open source cloud discussion. But Docker may prove to gain the most as it is also breeding a diverse ecosystem of open source projects. OpenStack is primarily contained (no pun intended) to the development of its own cloud operating system. It does integrate with OpenShift, for example, but for the most part the different groups within OpenStack do the lion's share of development. Docker's influence is such that it is affecting the overall open source community. The projects that are closely tied to Docker, such as Ansible, will continue to grow as developers seek tools to use with the fast growing container technology."

"Podio is an online work platform with a new take on how everyday work gets done. Podio gives people more power than ever before to manage their work in their own way and is trusted by thousands of teams, companies and organizations worldwide. Podio users create workspaces to collaborate with specific groups of people, use an Employee Network for company-wide communication across departments and locations, and get their work done using Podio Apps. Anyone can build their own Podio Apps without any technical skills, and can choose from hundreds of readily available, free apps in Podio's App Market. These apps add structure to any business process or project and are connected to social, collaborative activity streams used for commenting and discussion."

"In this article, we discuss the three-way relationship between three such desirable features - fairness, isolation, and throughput (FIT) - and argue that only two out of the three of them can be achieved simultaneously."

Excelente la discusión (en los comentarios) de los autores de Vaadin y de SmartGWT (ojo, no de SmartClient).

"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.