TSSJS Day 3: Neward’s Ruminations on Pragmatic Architecture

One of Ted’s first slide:  “Architecture is not to provide retirement for programmers…”

See http://www.joelonsoftware.com/articles/fog0000000018.html but the basic gist is that Java has way too many layers connected with XML.

Architecture definition: building design, building style and structuring a computer system.

First, we have to recognize the differences between a simple and a complex design.  What to expect in a good architecture: the “ities” (Reliability, Maintainability, Scalability, etc.). Make it easy for developers to make the right decisions by default…build an architecture that makes it easy for a developer to fall into the pit of success.

Good architects understand, reassess and explore.  They understand goals that back up the “ities” and they understand the constraints (money, time, resources, domain, ability of the team) that can work against those goals.

Goals – changing business climate changes goals; same with constraints. You constantly have to reassess and adapt to these changes.  An architect needs to explore…understand the viability of new technologies to fit the needs of current systems at least to a 2-sentence story.  If you can’t explain that to your boss, he may consider talking the IBM Rep. (Websphere wise-crack…LOL).

Three kinds of architects:

  • Infrastructure Architects: design of datacenter, network, app servers, etc.
  • Enterprise Architecture: concerned about the strategic vision of application and services within the entire organization
  • Solution Architect: writes code!  Lead for one or more projects.  Focused on building solutions usually in the scope of a division, and Explores new technology.  This is the area where Ted desires to be.

Patterns and architecture: Patterns failed! Patterns should describe architectural elements not the architecture itself.

Technology-architectural decisions should revolve around progress.  Start with the big ones and move from there.

Architecture elements to consider:

  • Communication/Distribution: Transport, Exchange and Format for RCP; tailor the exchange to the situation
  • Presentation/Interaction: style, implementation, perspectives and composites; perspective is what’s important to the actor using the system…important to consider!
  • State Management: Durable v. Transient state, Relational v. Object v. Hierarchical; Context-based v. Process-based state.
  • Processing: Implementation, Concurrency/Parallelism, and Transactional; functional languages address concurrency very nicely.
  • Resource Management: Locator/Registry, Discovery, Injection,
  • Tools: Languages, Code manipulation, etc.

In summary, architecture is an explicit action, if you don’t do it, it will be defined implicitly for you! It represents a higher perspective and defines a style for the system, and lastly defer decisions to the last reasonable minute, but not forever!

Very good talk and recommend taking a look at the slides for more details.  As a solution architect, I think I do some of these things but I certainly will fine-tune my own approach based on what I learned here…Bravo!


TSSJS Day 3: Ted Neward’s ECMAScript Talk

Ted gets back to the basics with JavaScript (JS)…I mean ECMAScript (ES)!

Numbers are all 64-bit floating point…no ints!  Strings are 16-bit Unicode. JS doesn’t use typed references…”var” is just for the parser to know a variable is about to follow.  If you don’t use var, it’s global (anti-pattern). Coercion is always possible…the var is typeless but the object it points to are typed, just not very strongly. ES is a classless system.

In Java6, they introduced “jrunscript” uses the JSR-223 to figure out by extension what script you’re trying to run (e.g., JS, Groovy, Python, etc.).

Boolean expressions are false if false, null, undefined, “”, 0 and NaN.  Truth is everything else.  In JS, you always return something (undefined if nothing else). == always attempts coercion, but the triple equals (===, !==) behaves how Java devs think it should work.

JS has 3 types that you should care about, Object, function and undefined. , [] () are “refinement” operators.  Any use of () evaluates into function object (aka functor).  You can do this:

var alertType = typedef(alert)
if (alertType === 'undefined')
    alert = println

For functions, “this” is a reference which its contents vary with invocation pattern. Defined parameters are completely unnecessary.  You can use “arguments” to get the arguments passed in from the calling function.

JS is bound to function scope not block scope.  This means you should do var declarations at the top of the function not the top of the block, like in C/Java.

Objects are really just HashMaps or key/value bags.

Beyond this point Ted’s talk blew my mind.  He brought up some pretty interesting examples with closures, currying and Fibonacci example.  It’s probably better to just check out his slides here as I won’t do it justice.