I’ve been spending some time learning about different languages and paradigms, which introduces me to terminology I’ve never heard before. I am not a “classically trained” computer science major – my programming and design skills are mostly self-taught. When I was staying mostly in my own space (building line of business applications in .Net, and VB (and some dBase) before that) I did not get exposed to any of this crazy terminology.

So, mostly as notes to myself, I am writing down what these terms I keep hearing mean (in my own words), instead of just glossing over them in my head and hoping the rest of the context clues will keep me going. If you get any value from this, great! :)

Memoization is a term I keep hearing in the various functional programming/distributed systems videos I’ve been watching. I figured it has something to do with remembering things and not put too much more thought into it. And, indeed, it does have to do with “remembering”, but a fairly specific case of it.

Memoization is keeping the results of past computations so that you can refer to them again without having to take the time to do the computation. It shows up often in recursive solutions. Basically, if you have a deterministic (a word I do know, since I did study a good amount of statistics WAY back in college) function, you can store the result in a dictionary keyed with the input value(s) (or a hash of them), and just use it in the future instead of recalculating.

I’m Back


I moved my blog to Github Pages using OctoPress. I thought it would be a better experience, but after nearly 2 years and only one post (which wasn’t worth much, so I didn’t bring it over), I realized I preferred WordPress so that I could just post stuff and not worry about the mechanics of it all. It also means I can post from pretty much any device at any time, so hopefully that helps.

So, my blog is back on WordPress (it actually never left – has always worked, but it was out of date). Hopefully I will post more.

My thoughts on what it means to be an architect

Architecture, Improvement, Techniques

An architect is like an Army Ranger, or an Old West scout. Their job is to go ahead of the main force to determine the best paths and clear obstacles when appropriate. This means it is up to them to figure out what technologies and architecture patterns to use. It is their job to find what the risky parts of the application or system will be and prototype them enough to remove the risks. If these prototypes are meant to become part of the production software (and let’s be honest, they always become part of the production software) they have to be built to the same standards as production code, which means good automated tests (unit, functional, and integration, as appropriate). They need to be prepared to discover that the approach they wanted to take is not the correct approach and abandon it before a lot of time and effort is spent trying to make the wrong tools or technologies work. Sometimes the seemingly obvious path is not the best path. You may have to attack a problem from an unusual direction to get to the best solution.

In order to do this, architects need to be able to see the big picture yet still write good code quickly. Good code is code that is easily understood and maintained, which means code with tests and low complexity and coupling. Not every developer can see the big picture – it is easy for us to get lost in the details or try to create the perfect solution instead of just doing enough to satisfy the requirement with solid code. This is not a bad thing if it can be kept under control, and the person qualified to keep it under control is an architect. A manger will want the developer to stop at satisfying the requirement.

Architects need to be concerned about the -ilities of a system. They need to keep an eye on performance – will the system be able to handle the expected number of peak users while still being responsive? Will it handle user load while background processes are under heavy load as well? Can it handle securing it’s data from malicious users and outside attack? The person qualified to make sure good technologies and development techniques are used to produce the system may not be qualified to define performance tests or security. This is why you often need a team of architects each specializing in one or more areas. Of course, this does not absolve an architect from knowing anything about these other concerns – an architect should know enough about these thing to call bullshit on bad ideas. But you need to have people with deep experience and knowledge in these important areas, and it is extremely unlikely that one person will be able to do the job. This is why you need an architecture team for any project of significant size.

Architects should not be treated in any special way. They will have knowledge that other people do not, but they should not horde this knowledge. They need to accept that other people may have good ideas as well and be ready to hear them out and employ these ideas when possible. In order to make this possible, they need to be approachable and respectful of these opinions and ideas. They should document decisions with the ideas considered and the reasons why they were not used as well as a compelling story for the idea that is being used. This provides a level of transparency and over time will give others an understanding of what values the organization holds when considering technologies and architectures.

Done properly, being an architect is still a very hands on job. You have to maintain your coding skills and keep in contact with other developers, or else you will stagnate and become of little value to your organization. You need to have solid teamwork skills because modern software requires lots of experts to get to a solidly built, long-lived result. The days when architects could hide in an ivory tower are completely gone, if they ever really were here.

CodeMash 2013 Day 4 Session 4


# Full Stack Integration Testing in Node.js
Mike Swift @swiftalphaone

Over time the cost of developer time gets more expensive if you don’t have tests. You can get away with it on a small code base – in fact small code base one or two devs testing probably adds cost.
So many kinds of tests – Unit, Regression, Integration, Acceptance, Visual
Integration tests – tests that go from start to finish using your actual product. You don’t isolate components.

## What makes good tests? Everything covered? A 2:1 code to test ratio?
1. Don’t make assumptions
2. Test sufficient (and the right inputs)
3. Maintain clear goals
4. Isolate the things you are testing
5. Optimize for developer happiness

Test boundaries and an element in the middle.
Don’t forget about the zero case – what if there are no users/orders/etc.
If you can’t tell what you are testing with a test, it is not a good test.
Improper isolation can cause random failures, which reduces the effectiveness of your test suite (and the confidence of your developers)
If you are writing tests for the sake of writing tests, you are probably doing it wrong.

“Writing bad tests is way worse than not writing tests.”

## Writing Better Tests
What does “Full Stack” mean?
Load the app in a browser and test as a user would use it
Phase 1 – Load the page in a browser*
Phase 2 – Perform the necessary actions (and verfiy)
Phase 3 – Profit
*Simulated browers are acceptable

Complexity + More & more tests = Wasted Dev Time
Time waiting for build to run
So integration tests can be expensive

There are “cloud based” testing services – Selenium Grid, browserlin, saucelabs
Basically headless browers running in the cloud that can run various brower versions
Only work for client-side code – can’t test server side code

node.js is good for testing because all of your developers can write javascript, it has the libraries you need, and it runs fast

PhantomJS v. Selenium v. jsDOM
jsDOM is not a browser at all – it is just an implementation of a DOM – give it HTML and it creates a DOM that you can use.

Zombie.js works as headless brower and is written on top of jsDOM. It gives you a cleaner API based on jQuery selectors.

Vows, Jasmine, and Cucumber are potential testing libaries to use.

The nice part of testing with a brower is the brower resets the state of your system with every page load. Even a headless browser.

Step definitions become reusable for other tests of the feature.

## The Tool Belt
Nock is a javascript mocking framework that mocks out API calls (AJAX calls). Has to run in the same process as the page, which can be done with node.
It allows you to assert that the expected calls were made.

Forgery (not sure why you would use this – I missed the explanation – it’s been a long week)

Travis is a very simple CI server that can integrate with github.

## Demo time
Testing a Sinatra app
You should start from an empty data store state (so you’d want to use an empty database or clear out your data in the test init (which is better for a demo :) ))
You create a world object as your starting point for your test suite (basically a context). You should start your app/site there.

Testing a C# app

CodeMash 2013 Day 4 Session 3


# Effective Actors
Jamie Allen @jamie_allen

Actors are concurrent lightweight processes that communicate through asynchronous message passing
NO state sharing

Note – this is focused on Akka which is a Scala actor framework

A set of Actors live in an ActorSystem

Supervisor Hierarchies – specifies handling mechanisms for groupings of actors in parent/child relationship
Actors can be remote to each other – in a different JVM or even a different machine.
Worker Supervision – supervisors hold critical data and pass it to workers ala Map/Reduce.
You can scale by creating multiple instances of an actor – no order can be assumed – they might run in any order
Define routing to determine how to spread work across actors – there are various routing algorithms
Actors share threads – they are not tied to threads.

1 – Actors should only do one thing (same as SRP)
Use Actors with abandon – an actor only has 300 bytes of overhead
2 – Block only when you have to
Blocking leads to actor starvation, resource waste, and horrible performance
Database access will be blocking – use specialized actors that only retrieve data – once it gets the data it should throw that to another actor
You get better async performance if you push data than if you pull it. (This is essentially event-driven programming)
3 – Do not optimize prematurely
Don’t parallelize until you have proof you need it (profile, runtime logs, etc. – Some Measurement)
Be prepared for race conditions – things will happen in an indeterminant order. You have to expect that things will not be the way you wanted them to be.
Provide all of the necessary information required to process a message in the message
4 – Be explicit in your intent
Name your actors – provides a means to find them and better logging
Never publish this or a real reference to an actor – only deal with actors via actor references and send messages to them
Avoid closures over the “sender” in an actor – it will probably be completely different at the time that the code is executed.
Use immutable messages – it enforces which actor owns the data