Reading List: Architecture, Data Stores, IoT / Embedded

General
Role of Architect
Architecture Reviews
Microservices
Services / SOA
Legacy Code Maint.
Relational DBs
NoSQL DBs
IoT / Embedded
Security
Microsoft-specific / .NET

General

  • Paul Ford: What is Code? – The best programmers are artists, not stenographers. Anyone can learn to write code. Creating the code is the easiest part of it. The best programmers see the big picture better — they’re quicker to see their mistakes, and understand the broader consequences of what they’re doing before they have a chance to screw anything up too badly.
  • Richard Hamming: You and your Research (44min vid) – transcription – what matters, whether in research or career, is working on the right problem, at the right time, and in the right way; preparedness: work hard; be open; be introspective; work broadly; know how to communicate: professionally, impromptu and informally
  • Peter Naur: Programming as Theory Building – Jump to “Applying “Theory Building” for a summary… quality as match between theory of problem and theory of solution; designer’s job is to pass along the theories not “the design”; intellectual activity includes theory building not just intelligent applying; three essential areas of theory building view: 1) can explain how; 2) can explain why; 3) can advise on any requested modification; tradeoffs of designing for future flexibility; programmers should have status of responsible managers of the activity, not just developing it; metaphor as theory; tacit knowledge and documentation: purpose of program / arch doc is to jiggle memories in the reader, reminder about experiences and metaphors; its purpose is not to say everything, but to help next programmer build an accurate theory of the system
  • Thoughtworks: Agile Architecture (40min vid) – three aspects: codebase, cluster of functionality, single source of funding; agile architects are more of a team lead role rather than separated; if you’re going to be lead on a development team you have to be doing some programming; city planning is a better metaphor for software architecture than building architecture; id things perceived as hard to change and make them easy to change: e.g., db schema reversability example, consumer-driven contracts; shared understanding in team is single most important thing not diagrams or docs; show aspects of architecture in demos / showcases; mob code review / refactoring; set aside time for commit reviews; help rather than deliver
  • Guy Steele: Growing a Language (53min vid) – text here – Don’t design a small or large language, design a language that can grow; APL did not have a pattern for growth; LISP can be grown by users; A main goal in designing a language should be to plan for growth; Two kinds of growth – change the vocab or change rules that define what vocab means; The cathedral vs the bazaar; for the latter, the plan can change with user input; some cathedrals were built in the bazaar mode; Shopping mall is a good compromise; A good programmer does language design; Any time you create a word, is it worth defining it vs. reusing existing word; Meta means that you step back from your own place. What you used to do is now what you see. What you were is now what you act on. Verbs turn to nouns. What you used to think of as a pattern is now treated as a thing to put in the slot of an other pattern. A meta foo is a foo in whose slots you can put foos.
  • Christopher Alexander: The Search for Beauty – Master plans have two additional unhealthy characteristics. To begin with, the existence of a master plan alienates the users…. After all, the very existence of a master plan means, by definition, that the members of the community can have little impact on the future shape of their community, because most of the important decisions have already been made. In a sense, under a master plan people are living with a frozen future, able to affect only relatively trivial details. When people lose the sense of responsibility for the environment they live in, and realize that there are merely cogs in someone else’s machine, how can they feel any sense of identification with the community, or any sense of purpose there? Second, neither the users nor the key decision makers can visualize the actual implications of the master plan.
  • Mark Cavage: There’s Just No Getting around It: You’re Building a Distributed System: Building a distributed system requires a methodical approach to requirements (acm subscr) – required either by scaling beyond a single machine, or move to cloud service provider; decompose into discrete services on the boundaries of fault domains, scaling and data workload; make as many things as possible stateless; when dealing with state, deeply understand CAP, latency, throughput, and durability requirements
  • Leslie Lamport: Time, Clocks, and the Ordering of Events in a Distributed System – “The concept of one event happening before another in a distributed system is examined, and is shown to define a partial ordering of the events. A distributed algorithm is given for synchronizing a system of logical clocks which can be used to totally order the events. The use of the total ordering is illustrated with a method for solving synchronization problems. The algorithm is then specialized for synchronizing physical clocks, and a bound is derived on how far out of synchrony the clocks can become.”
  • C.A.R Hoare: Communicating Sequential Processes  – “…suggests that input and output are basic primitives of programming and that parallel composition of communicating sequential processes is a fundamental program structuring method.”

Role of Architect

Architecture Reviews

  • Etsy: Multiple Perspectives On Technical Problems and Solutions – “the strategy for causing the best change in a poorly understood or uncertain situation within the available resources”; “We called these “something new” things departures”; “an Architecture Review Working Group, or “ARWG” was developed. The main idea was that such a group could keep the practice going without senior engineering leadership bringing an authoritarian flavor to the meetings, and continually model the behavior the practice needed to encourage the multiple perspectives that departures needed”; “provide a stable and welcome environment where engineers can openly describe how they’re thinking about solving problems with potentially new and novel technology and patterns. This environment needs to support questions and comments from the rest of the organization about trade-offs, assumptions, constraints, pressures, maintenance, and the onus that comes with departures. And finally, documenting how decisions around departures were arrived at, so a sort of anthropological artifact exists to inform future decisions and dialogues”; “Dialogue is about exploring the nature of choice. To choose is to select among alternatives. Dialogue is about evoking insight, which is a way of reordering our knowledge— particularly the taken-for-granted assumptions that people bring to the table. Discussion is about making a decision. Unlike dialogue, which seeks to open possibilities and see new options, discussion seeks closure and completion”; “when an architecture review brings attention to a problem and proposed solutions from multiple perspectives, decisions become less controversial.”; “Engineers (both presenting and participating as audience) need to understand the purpose of the architecture review is to develop better outcomes. That’s it. It’s not to showcase their technical prowess”

Microservices

Services / SOA

Legacy Code Maint.

  • Sandi Metz: Breaking Up the Behemoth – “I’ve been thinking about how applications evolve, and what we might do if we’re unhappy with the results”; design stamina hypothesis; procedural vs. OO code; Churn vs. Complexity; “…we end up with applications where many small, efficient classes coexist alongside one costly, massive, condition-filled behemoth. A series of small, innocent changes turned the application’s most important code into a class so complex that no one could fix it”; “f important classes in your domain change often, get bigger every time they change, and are accumulating conditionals, stop adding to them right now. Use every new request as an opportunity to do a bit of design. Implement the change using small, well-designed classes that collaborate with the existing object”; “Make small objects, and over time, the big ones will disappear”
  • Michael Feathers: Getting Empirical about Refactoring – churn vs. complexity to help guide refactoring decisions
  • Michael Feathers: blog – refactoring / code-maint. themes

Relational DBs

NoSQL DBs

  • Sarah Mei: Why You Should Never Use MongoDB – case study of diaspora social network app which started on MongoDB and was later migrated to PostgreSQL; only thing MongoDB is good at is storing arbitrary pieces of JSON; consider PostgreSQL hstore as an alternative; as soon as you have duplication or links (requiring joins) MongoDB is not a good fit
  • Thoughtworks: Pramod Sadalage: NoSQL Databases: An Overview – Application developers have been frustrated with the impedance mismatch between the relational data structures and the in-memory data structures of the application; Relational databases were not designed to run efficiently on clusters; distribution models; CAP theorem; types: Key-Value dbs, Document dbs, column family stores, graph dbs; ideally suited for config, cms / analytics, cms / blogging / counters / expiring-usage / heavy write volume like log agg., connected data / social networks / spatial data, respectively
  • Hstore vs. JSON – Which to Use in Postgres

IoT / Embedded

Security

Microsoft-specific / .NET

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s