Maintainable Python Applications: a Guide for Skeptical Java Developers · Code Without Rules

Maintainable Python Applications: a Guide for Skeptical Java Developers · Code Without Rules: "When you've been writing Java for a while switching to Python can make you a little anxious. Not only are you learning a new language with new idioms and tools, you're also dealing with a language with far less built-in safety. No more type checks, no more clear separation between public and private.

It's much easier to learn Python than Java, it's true, but it's also much easier to write unmaintainable code. Can you really build large scale, robust and maintainable applications in Python? I think you can, if you do it right.

The suggestions below will help get you started on a new Python project, or improve an existing project that you're joining. You'll need to keep up the best practices you've used in Java, and learn new tools that will help you write better Python"

'via Blog this'

infoQ: Architecture: Technologies for the Future of Software Engineering

Technologies for the Future of Software Engineering: "The Cloud, infrastructure as code, federated architectures with APIs and anti-fragile systems: these are technologies for developing software systems that are rapidly coming into focus, claimed Mary Poppendieck. She spoke about the future of software engineering at GOTO Berlin 2016.

If you have too much data to fit on one computer, you have two options: scale up or scale out. Scaling up by using a bigger computer is usually not the right direction to take, argued Poppendieck. You need to scale out by getting more computers and build systems of computers.

Poppendieck mentioned different ways to scale out:

Scale out files: an example is the approach that Google uses for searching. Files are split up into small pieces which are copied to multiple servers. Then the searching is done in parallel, and the results from all servers are combined into one search result.
Scale out architecture: Amazon does this by breaking transactions into services and using specific servers to do the services. If there’s a bottleneck, then you can replicate the service on multiple servers. Each service is owned by a semi-autonomous "two pizza" team.
Systems are moving more and more towards the cloud; there is a cloud in your future, said Poppendieck"

Having one central database creates a dependency problem as all applications depend on the database, and changing the database can impact many applications. Poppendieck stated that "the enterprise database is a massive dependency generator". Individual teams cannot deploy autonomously as their work has to be coordinated with all other teams sharing the database. Instead of having one database, you need a federated architecture where you split into local data stores appropriate to the needs of individual modules or services, and accessed only through APIs. APIs are replacing central shared databases and they enable the internet of things. You have to learn to do software engineering with APIs, argued Poppendieck. Look at APIs as products which are owned by a responsible team, and focus on the API customers to evolve and develop new capabilities.

We need to stop trying to make systems failure free and start thinking differently, said Poppendieck. Many of our current systems are fragile; they started as robust systems but over time they have become difficult to maintain. Systems nowadays need to be anti-fragile, and able to embrace failure, claimed Poppendieck. When things go wrong, systems should be capable of limiting damage and recovering from failures.

You get anti-fragile systems from the way you test systems, which is by failure injection to make something go wrong. Poppendieck mentioned that your systems need to isolate and automatically recover from failure, in order to achieve today’s expected levels of availability and robustness.

Poppendieck mentioned aspects that are essential nowadays for developing software. She said that you need a deployment pipeline to be able to do continuous delivery, and you need cross-functional teams including product management, testers, and operations to get the benefits promised by continuous delivery. The deployment pipeline depends on automated processes for testing, migration, and deployment. Continuous delivery requires all teams to communicate through the codebase by doing continuous integration to the trunk. Teams keep the software always production-ready; if that’s not the case you have to stop and make it so. While deployment is continuous, release is incremental by toggle or switch whenever a useful increment or capability is ready.

'via Blog this'

GitHub - heathermiller - Programming Models for Distributed Computation

GitHub - heathermiller/dist-prog-book: "Source repo for the book that I and my students in my course at Northeastern University, CS7680 Special Topics in Computing Systems: Programming Models for Distributed Computing, are writing on the topic of programming models for distributed systems.

This is a book about the programming constructs we use to build distributed systems. These range from the small, RPC, futures, actors, to the large; systems built up of these components like MapReduce and Spark. We explore issues and concerns central to distributed systems like consistency, availability, and fault tolerance, from the lens of the programming models and frameworks that the programmer uses to build these systems."

'via Blog this'

process - Why Agile Works

Why Agile Works: "In this podcast, recorded at Agile 2016, Shane Hastie, InfoQ Lead Editor for Culture & Methods, spoke to David Benz and Michael de la Maza about their minibook Why Agile Works, which is available at InfoQ.com."

'via Blog this'

non-O(n) musings: How to translate a large C project to Rust

non-O(n) musings: How to translate a large C project to Rust: "In October, I started working on translating CVS from C to Rust, and today I'd like to answer these questions about how that's going:
How does a Corrode-aided porting effort work, in practice?
How much progress have I made on CVS, and how hard would it be to do the same for other projects today?"

'via Blog this'

Death to JIRA | TechCrunch

Death to JIRA | TechCrunch: "I promised a better way. It is astonishingly simple. We already have an extremely powerful descriptive system which can be used to specify complex systems while including ambiguities, uncertainties, interwoven relationships, iterative levels of success, and an arbitrarily broad spectrum of scale and detail. It is called “prose.”

For some reason many companies today seem to be terrified of the prospect of writing more than a couple of paragraphs of clear and simple prose. But a well-written 8-page document can define the nuances of a complicated system far better than a whole cumbersome flotilla of interlinked JIRA tickets.

Indeed it’s easy to envision an automated system which takes a simple text document, parses it into sentences, bullet points, paragraphs, sections, and chapters, and tracks the estimation and progress of those elements — at whichever scale makes sense in that context — instead of tickets. (I suppose you could even automatically render them into JIRA tickets, if you really had to; but the point is that the master specification would be a single coherent prose document.)"

'via Blog this'

List of Consistency Models for Cloud Storage Services - CloudRail

List of Consistency Models for Cloud Storage Services - CloudRail

This article compares consistency models of all major cloud storage providers. The CloudRail Unified API makes integrating different cloud storage services into your code easy. It provides easy to use, abstracted interfaces that allow you to treat groups of those services similarly by using the exact same methods. Yet, the services are not 100% the same and one important distinctive attribute is the service’s consistency model. It can impact how you write your code and is thus something every developer should be aware of.:

'via Blog this'