A blog about software and making.

Odds & Ends - December 2012

Thoughts, terms, and ideas I’ve come across over the last few months.

  • Write in terms of services - independent, concurrent objects behind well-defined, consistent interfaces.
  • Eliminate effects between unrelated things - Design components to be self-contained, independent, and have a single well-defined purpose.
  • Program close the problem domain - Design and code in your user’s language.
  • Test state coverage, not code coverage - Identify and test significate program states. Just testing lines is useless.
  • Test early, test Often, test automatically - Tests that run with every build are much more effective than test plans that sit on a shelf.
  • Always design for concurrency - Cleaner interfaces with fewer assumptions.
  • Put abstractions in code, details in metadata - Program fro the general case, and put specifics outside the compiled code base (config files).
  • Keep knowledge in plain text - Won’t become obsolete.
  • Use blackboards to coordinate workflow - Use to coordinate disparate facts and agents, while maintaining independence and isolation among parts.
  • Use a project glossery - Single source for specific terms and vocabulary for a project.
  • Find bugs once - Once a human finds a bug, it should be the last time a human finds that bug. Automated tests should check for it from then on.
  • Crash early - A dead program normally does less damage than a corrupt one.
  • Organize teams around functionality - Build teams the way you build code (designers + coders + testers + data modelers).
  • Design to contracts - Use contracts to document and verify code does no more and no less than it claims.
  • Don’t use return values for errors - Eventually a component will ignore a value and an error will silently be ignored. Dead software doesn’t lie.

Returning ptr to stack vs. heap allocated instance in C++ 

1
2
3
4
5
6
7
8
9
10
11
12
13
class Thingy;

Thingy* foo()
{
  int a; // Stack
  Thingy b; // Created on stack
  Thingy *ptr_to_b = &b;  // Points to address on stack
  Thingy *ptr_to_c = new Thingy(); // Points to address of thingy created on heap

  return pointer_to_c; // Safe - Thingy lives on heap and outlives foo().  Remember to delete.

  return pointer_to_b; // BOOM! Because b lives on stack and will be deleted when foo() returns.

Odds & Ends - September 2012

Thoughts, terms, and ideas I’ve come across over the last few months.

  • The three virtues of programmers - Hubris, Impatience, and Laziness. src
  • The curse of the gifted - A tendency to lean on your natural ability too much, because you have always been rewarded for doing that and self-discipline would take actual work. src
  • Classic 3 Tier - Presentation / Buisness Logic (rules) / Data Source (queries)
  • Typing Types
    • Exact typing - Only ducks are ducks
    • Interface typing - If it says it’s a duck,
    • Duck typing - If it quacks like a duck then we don’t care as long as it has the fields/methods we need.
  • Mark and Sweep GC - Pause, find all variables in current scope, find all resources that are reachable from variables in scope and free the rest. AKA “stop the world GC”.
  • Reference counting GC - Each resource has a count of # of places it’s being used (references). When the code is done with the resource, the count will decrease to zero so it can’t be freed. Vulnerable to circular references because counts will never reach zero.
  • Dynamic Dispatch - Not knowing what function you will call until runtime.
  • Encoding Scheme - Encodes data for a specific purpose (easier to transmit, read, convert to new format).
  • More code = Harder to fit in IL cache so more cache evictions and harder to inline.
  • More branches = more branch predictions = more branch mispredictions.
  • Dependancy Inversion Principle - program to interfaces or abstract base classes.
  • System call - Userspace request of a kernel service.
  • High Cohesion - Keeping parts of a codebase that are related to each other in single place.
  • Low coupling - Separating unrelated parts of the codebase as much as possible.
  • Domain Event - Anything that happens that is of interest to a domain expert.
  • You call a library, a framework calls you. A library is a tool … A framework is a way of life. src
  • Pure functions > Functions with state > Functions with side effects > Factory functions.
  • A member function has a hidden argument called ‘’this’’ that is the specific object we are operating on (the context of the function call).

Blog Ingredients

⅓ notebook ⅓ bookmarks ⅓ random

Tag Cloud

Algorithms Books C++ Complexity Concurrency Conferences Courses DIY Data Orientated Design Data Science Data Structures Databases DevOps Distributed Systems ECMAScript Electronics Empirical Studies Exploring Failure Functional Programming Game Engines Gamification Interviewing MOOC Machine Learning Makerspace Making Math Meetup Natural Language Processing Odds & Ends Optimization Presentations Purposeful Practice Random React Reduction Reviews Software Architecture Software Development Practices Testing User Experience Design Visual Learning Web μReview

Tags