Reading List: Architecture, Data Stores, IoT / Embedded

General
Role of Architect
Microservices
Services / SOA
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 program 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

Microservices

Services / SOA

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