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

• Objects on the stack are much more likely to be in the cache than arbitrary heap lines.
• Closure - When a function closes over the area it is defined in so it can access variables that are not in its parameter list.
• Anonymous functions (ECMAScript) - Functions that do not have a name associated with them. Used to manage the scope of objects, modules, and namespaces.
• Control Technique (testing) - A method by which you control your test by factoring out the portion of your program which has side effects outside the scope of control of the code you intend to test. You need to control the side effects when testing. Example: stubbing external dependencies.
• Mutable - Can change contents without changing identity.
• Immutable - Cannot change contents without changing identity. Values are unchangeable once they are created.
• Good C++: Avoid mutation, avoid side effects, don’t use raw loops, avoid class hierarchy and inheritance (aka be more functional).
  • The worse case is side effects with global scope.
  • Same principal apply to fields, properties, parameters, and variables. Don’t mutate unless you have a good reason.
  • Increase reliability by removing side effects so the code is easier to compose and integrate. Side-effect free code works in all environments!

Mark Trostler has a great presentation on creating testable JavaScript.

• Create all of the objects the system will ever need at the start (composition root) by building a tree of dependencies.
  • Create general objects at application start and user/session specific objects at the request start.
    • Use an IOC/DI framework that is configured once at the start to constructor inject the dependencies.
• Cross-cutting concerns - Concerns that affect many areas of your application. They cut across your application and do not align with modules.
  • Keep orthogonal responsibilities separate.
  • Examples: Logging, validation, auditing, caching, security, profiling, exception handling, retry logic, authentication, authorization, encryption, etc.
  • Use decorator pattern to create wrappers around your business objects that handle the cross-cutting concerns.
  • Use your IOC container to wire up decorator chains.
• Run-time (short-lived) dependancies - Can’t pass into constructor because we don’t know what they will need until run-time (user has to pick).
  • Pass run-time values into a factory pattern to get dependencies.
  • Factory implementation is created at composition root and injected as a dependency via the constructor.
• Program and test to interfaces.
  • Interfaces are the API.
  • Don’t worry about hiding via closures (revealing module pattern) just use the interfaces.
  • Create many small interfaces that have a single responsibility.

Presentation Link

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

• An entity is identified by an ID whereas a value object is identified by its value.
• Enumerators flatten a collection so that the members can be accessed sequentially.
• The heart of OO is the encapsulation of data and members in a coherent class/object.
  • A class should fulfill the contact implied by its interface(s) so the caller need not know how it’s implemented.
  • Objects communicate by sending each other messages through method calls.
• Critique code, not people. Teach people they are not their code.
• Null return values should be avoided. It leads to null guard clauses at the top of every method which clutters the code.
• String and int make good hashmap keys because they are immutable. If the key could be altered in a way the changed its hashcode we wouldn’t be able to find the object in the hashmap anymore!
• Building software is the process of finding solutions to complex problems, which involves perspective (understanding the problem) and heuristics (a means of solving it). Experts tend to have similar viewpoints while novices bring new ways of thinking.
• Give novices projects that involve:
  • Autonomy - Something to be responsible for. Don’t just leave novices alone in the corner to “figure it out”.
  • Mastery - People are incentivized by a challenge.
  • Purpose - a meaningful part of the project. Not just a pile of IE6 bugs to slog through.
• Cache Lines - Get the byte you asked for and the rest of the 64-byte block for free.
• Async/Await gives the illusion of sequential behavior. Await marks the position where a task should resume. It may not resume on the same thread of execution which causes GUI to blow up.

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

• Information-theoretic security - Derives security from informational theory instead of computational complexity. It cannot be broken even when the adversary has unlimited computing resources as they do not have enough information to break the encryption.
  • Example: Onetime pad.
• Computationally secure - Secure assuming adversary is computationally limited.
  • Example: RSA, Diffie-Hellman
• API Design
  • Don’t make the return type of method depend on the value of an argument. It makes it hard to figure out relationships.
  • Avoid flag arguments intended to change the behavior of a method in some way. The call is more readable if the API has two separate methods.
  • Avoid confusion as to whether a method returns a new object or modifies (mutates) an object in place. Show intent!
    • Ex: foo.sort() doesn’t return value so it must modify in place.
• When to assert
  • Defensive programming
  • Run-time checks on program logic (poor man’s unit testing)
  • Checking contracts (pre-conditions/post-conditions)
  • Program invariants
  • Check for “won’t happen” edge cases
  • Confirm documentation
  • Never use if failure is likely because asserts will get compiled away in release builds.