nicholashagen

Five Star Architecture

Being apart of several different architecture teams throughout my career, I have learned alot about data organization from the core data to the frontend interfaces to everything in-between. Generally, every single architecture survives off what I am coining as the Five Star Architecture (FSA). The FSA essentially encompasses five different tiers, each with their specific resposibilities and methodologies.

The following is a high-level diagram of the tiers including the communication protocol(s):

nicholashagen

// Use Gists to store code you would like to remember later on
console.log(window); // log the "window" object to the console

nicholashagen

Metrics Library

About

• Originally developed at Yammer by Coda Hale
• Released as an open source metrics library implementation under Coda Hale
• Considered one of the more prominent instrumentation libraries
• Composed of core metrics library and set of growing plugins
• Core library supports variety of metric gathering tools and health checks
• Plugins support exposing core metrics (jmx, graphite, etc)

nicholashagen

Download Source

#> wget http://download.silicondust.com/hdhomerun/libhdhomerun_20130117.tgz
#> tar zxvf libhdhomerun_20130117.tgz 

Install Tools

nicholashagen

package com.devchat.lambdas.examples;

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.nio.charset.Charset;
import java.nio.file.FileSystems;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.ArrayList;
import java.util.Arrays;

nicholashagen

Currently, there are several implementations that provide JSON to object binding in Java. Several actually use the existing JAXB annotations that are XML driven. This results in oddities that you are exposing JSON binding rules with annotations that target XML (ie: @XmlType, @XmlValue, etc). As a result, there is a future spec coming for an official JSON bindings recommendation. This will most likely result in a new set of annotations (ie: @JsonType, @JsonValue). This will end up requiring double annotations leading to metadata bloat. The problem is that despite the two being very closely tied together, there are several differences. One could argue that JSON is a subset of XML, although that is not entirely accurate.

I would propose that indeed we have two separate annotations and two separate specifications that are aligned as consistently as possible (similar named annotations for common use cases such as @XmlValue and @JsonValue). I would propose a third joint effort spec that creates an aggregat

nicholashagen

@Path('/:sport/:league/events')
class EventResource {
     String sport
     String league
     
     @Path('/:year/:month/:day')
     EventResponse getEventsForDate(Integer year, Integer month, Integer day) { ... }
     
     @Path('/today')
     EventResponse getTodaysEvents() { ... }

nicholashagen

/* ASSUME FOLLOWING OBJECT MODEL

class Address {
    String street
    String city
}

class Role {
    boolean admin
    String type

nicholashagen

@Grab(group='org.codehaus.groovy.modules.http-builder', module='http-builder', version='0.6' )
 
import groovyx.net.http.*
import groovyx.net.http.RESTClient
import static groovyx.net.http.ContentType.URLENC
import static groovyx.net.http.ContentType.*
import static groovyx.net.http.Method.*

// this fails
try {

nicholashagen

public class LoadTest {

    public static void main(String[] args) {
      // int count = 5000;
    	int count = 25000;
    	// int count = 100000;
    	// int count = 250000;
    	
    	long s = System.nanoTime();
    	for (int i = 0; i < 1000; i++) {