Sunday, April 29, 2018

How to scale your services with session affinity on docker in 5 minutes!

Assumes you know docker, docker swarm concepts and can understand something easy about node.js
Developing services with an eye on scalability? Who isn't right! This should give you some ideas on how to minimally setup and run a load balancer with your docker swarm to create sticky sessions where you want them.
I have two example Node.js services in this use case running, one of which I wish to track application state, and the other running stateless.
  1. Create two of these index.js files in separate directories, service1 and service2.
  2. Change the src root /serviceX and the res.end(`<h1> I'm serviceX.... to service1 and service2 to match the aforementioned directory naming
  3. In each service dir run npm init, then npm i S cookie-parser express express-session
  4. run node index.js and test each out individually by hitting localhost:8080/serviceX, you should see each subsequent reload increment a counter.
var express = require('express');
var cookieParser = require('cookie-parser');
var session = require('express-session');
var os = require('os');
var app = express();

app.use(cookieParser());

app.use(session({secret: "Shh, its a secret!"}));

app.get('/service1', function(req, res){

   if(req.session.page_views){

      req.session.page_views++;

   } else {

      req.session.page_views = 1;

   }

     res.writeHead(200, {'Content-Type': 'text/html'});

     res.write(JSON.stringify(req.headers));     

     res.end(`<h1>I'm service1 on ${os.hostname()} non unique visits ${req.session.page_views}</h1>`);

});

app.listen(8080);

Now dockerize each service like this in directories service1, service2, with a Dockerfile.
FROM node

RUN mkdir -p /usr/src/app

COPY index.js /usr/src/app

COPY package*.json ./

RUN npm install

EXPOSE 8080

CMD ["node","/usr/src/app/index"]
  1. Add a .dockerignore file in each to leave behind the modules.
node_modules

npm-debug.log
2. Build a docker image in each directory docker build -t serviceX .
3. Build a docker compose file, one level up from the service dirs, here it is
version: '3'

services:

  service1:

   image: service1 

   ports:

     - 8080

   environment:

     - SERVICE_PORTS=8080

     - COOKIE=connect.sid prefix nocache

     - VIRTUAL_HOST=*/service1

   deploy:

     replicas: 2

     update_config:

       parallelism: 5

       delay: 10s

     restart_policy:

       condition: on-failure

       max_attempts: 3

       window: 120s

   networks:

     - web



  service2:

   image: service2 

   ports:

     - 8080

   environment:

     - SERVICE_PORTS=8080

     - VIRTUAL_HOST=*/service2

   deploy:

     replicas: 2

     update_config:

       parallelism: 5

       delay: 10s

     restart_policy:

       condition: on-failure

       max_attempts: 3

       window: 120s

   networks:

     - web



  proxy:

    image: dockercloud/haproxy

Only two replicas, make it whatever you want. What's really interesting about this are two things, BOTH javascript files build a session but only one in the compose file is affinity assigned, service1.
- COOKIE=connect.sid prefix nocache
That's the default cookie name given by express-session you can of course make changes to that, prefix adds the server routing and nocache is uh, no cacheing it.
The other thing interesting is this entry, virtual hosts, these must match the /root of your services for routing purposes, both services must have this unless you are serving from a plain root e.g. "/"
 - VIRTUAL_HOST=*/service1
Run this command to launch the replicated services with affinity on service1.
  1. docker swarm init
  2. docker stack deploy --compose-file=docker-compose.yml test
  3. docker service -ls
  4. point to localhost/serviceX for results, service1 will be sticky and incrementing each time, service2 you will see a new service and session each time. Clear cookies to get over to another server1.
Here are the official options for haproxy.
http://cbonte.github.io/haproxy-dconv/1.9/configuration.html#7.1
I'd add this to git but five min was up ten minutes ago.

Saturday, September 12, 2015

Summit Everest! Surviving the engineering death zone.




The lifecycle of a software product can seem mysteriously vague,  complex, or overly simplified depending on the audience.  I liken it to a climb with the highs, lows, and ultimately a conquest or defeat.

Base Camp

The beginning of a new project and the buzz of fresh energy throughout the team is palpable.  Ideas, roles, and a vision of the possible emerges from every situation or get together. The morale and excitement is at an all time high! Every creature comfort is available and the team starts off as well rested and prepared as they will ever be.

Camp One

Camp one is reached in record time, the time to market forecast is being wildly exceeded as sheer energy and momentum lifts the team seemingly without effort. Prototypes and functionality appear weekly out of nowhere.  Checkins litter the git history from what looks like 24/7 output people trying to write as fast as their brains can think.  Product management is struggling to keep track of all the new work.
   

Camp Two

Camp two is also quickly reached but the renaissance of creativity yields to the thinner air of coalescing effort. Some time is now being spent acclimatizing instead of rapidly moving forward, fewer feature branches appear as product management steers a unified course up the mountain.  Some re-planning and adjustment are implemented.

Camp Three (Lhotse wall)   

Arrival at camp three is signaled by the teams progress velocity returning to real world numbers. It took longer to get here then expected, maybe a lot longer. A unified codebase along with the requisite build and test process has appeared. Creativity is scaled back to solving many of the initial hand waves done earlier in the climb that kept the forward momentum at the expense of problem solving each detail.  Some doldrums will set in and those truly in shape will seem less affected,  leaders may rise and fall here.

Camp Four (The death zone)

You have reached the death zone, this is the 10% of remaining work that will take 90% of the projects total effort to complete.  The go to market schedule which was insanely optimistic and ahead of schedule now suddenly seems to be behind.  The engineering progress as been reduced to a crawl. Any small change in requirements,  code refactoring, or new feature development has wide ranging implications that can tie up the team for days to sort out.  As people sip oxygen from what remains in the tanks it takes supreme confidence and leadership to overcome the fear and exhaustion for the final push to the summit.  Lingering at camp four seems to go on forever,  you must have confidence.

At this point it can sometimes be necessary to bring in finishers to help with the final push. Finishers are fresh eyes and legs that can give some perspective to the team that is not tunnel visioned or snow-blinded from fighting up every inch of the trail to this point,  A fresh perspective can help chart the easiest path to the summit, it can also lead you into an avalanche so the right guide is CRUCIAL.

Summit 

What needs to be said here really, pop a champagne and take a picture. But don't tarry or bask too long on the top of the world its dangerous to do so. Quickly get back down to basecamp to rest and rebuild the team, and begin to prepare for the next climb.

Thursday, June 12, 2014

Google Web Toolkit (GWT) Event Bus

Recently doing some GWT development and wanted to expand an example of the toolkit's event bus.
This contrived example doesn't involve widgets, or UI handling and is only meant to highlight the principle using simple example/pseudo-code. This assumes some knowledge on the internal workings of the GWT Event Bus or observer design pattern, treated as a black box here.

Imagine a virtual restaurant where you have a cook, waiter, and a customer.

The business process is, "The waiter takes the customer's order and gives it to the cook."
In this familiar scenario you have; cook, waiter, order, and customer.

In the GWT Event Bus world you have Events, Event Handlers, and Entities(Widgets, Objects etc).

Mapping to our little scenario thusly.

Events {OrderPlacedEvent}
Event Handler {OrderPlacedEventHandler}
Entity {Waiter, Customer, Order}

The real question is, how to design for an event bus, or, what to design first?

Handlers are used by entities that need to "handle" events.  Our waiter is interacting directly with the customer and so doesn't need to handle an order "event", he's the interface (virtually maybe) taking/constructing the orders. The cook on the other hand is in the kitchen and busy doing non customer related tasks, but he's very interested in orders so he can do his job of making the food.

So, the cook wants to be informed of orders being placed, and what they are, and the waiter will be the one to inform. With the event bus ANYONE can be informed about the order immediately as it's placed, cooks, managers, supply systems, etc.

First thing is to create the Handler. The reason is that the Event will actually need to register the Handler Type in the Event bus, and your Event will also reference it.

/**
 *
 */
public interface OrderPlacedEventHandler extends EventHandler {

     void onOrderPlaced(OrderPlacedEvent event);

}

Now we have a handler interface with a method to invoke with an event IF one occurs.

Next we create OrderPlacedEvent,  but first the order would be helpful.

/**
 *
 */
public class Order{ 

      private List<FoodItems> items;          

      public Order(FoodItems...items){
            items = new ArrayList<>(Arrays.asList(items));
      }

      public List<FoodItems> getItems{
             return this.items; 
      }
      ...
}

The actual Event, conventions as per GWT plus a reference to the order.

/**
 *
 */
public class OrderPlacedEvent extends GwtEvent<OrderPlacedEventHandler>{

       public final Order order;
       public static final Type<OrderPlacedEventHandler> TYPE =
                                     new TYPE<OrderPlacedEventHandler>();

        public OrderPlacedEvent(Order order){
              this.order = order;
        }

        public Order getOrder(){
              return this.order;
        }

       @Override
        public Type<OrderPlacedEventHandler> getAssociatedType() {
              return TYPE;
        }

        @Override
        protected void dispatch(OderPlacedEventHandler handler) {
               handler.onOrderPlaced(this);
        }

}


The cook needs to register the handler and do something with the return value, in this simple case he adds it to the internal list of orders he's working on. The event bus listens for the TYPE to arrive and then iterates through every registered handler calling it's implementation as defined in dispatch.

/**
*
*
*/
public class Cook{

     private List<Order> orders = new ArrayList<>();

     public Cook(EventBus bus){
                eventBus.addHandler(new OrderPlacedEventHandler(){
                                void onOrderPlaced(OrderPlacedEvent event){
                                                   addOrder(event.getOrder);
                                                   }}, OrderPlacedEvent.TYPE);
     }

     public addOrder(Order order){
              orders.add 
     }     
}


Waiter will be the one to "fire off" an order placed event to let everyone know at the end of his order taking process.


/**
 *
 */
public class Waiter{

    private EventBus eventBus;
    
    public Waiter(EventBus eventBus){
            ...

     }

     public void takeFoodOrder(Order order){ 
           ...
         eventBus.fireEvent(new OrderPlacedEvent(order));

      }

}



That's it! Hope it clears up some of the design and workings using this simple scenario.  I highly suggest using the EventBinder when coding in GWT proper instead the classes you see here, does all the same things but it's less coding!






Tuesday, March 4, 2014

This is easy!

Wondering why your software product / project is taking so long or has quality issues, then ask yourself these simple to answer questions.

1. Using an Agile methodology? 

2. Enforcing testing and code review? 

3. Using continuous integration? 

4. Branching and tagging code by development, bug fix, and release versioning? 

Don't waste time trying to figure out what's wrong until you can answer YES to every one of those questions. This is easy until you make it hard. :)

Friday, September 6, 2013

JPA 2.0 and Guice, one way to do it.

I was recently creating some JPA 2.0 code in a project using google-guice as the dependency injection framework. I found it slightly interesting as there was no real documentation I could find on how to tackle it so here is what I came up with.

For starters I knew I wanted the standard generic DAO pattern which in my case I will be referring to as JPADataServices for clarity in this project which uses several data store types and accessor patterns.

The generic DAO pattern looks like this.

/**
 * Generic entity methods
 *
 */
public interface JPADataService<K, T> {
 
 /**
  * Returns the entity matching the given id
  * @param id the id
  * @return the entity
  */
 public T get(K id);

 
 /**
  * Returns all entities
  * @return List of entities
  */
 public List<T> getAll();

 ...

}


/**
 * basic implementation for all entities
 *
 */

public abstract class JPADataServiceImpl<K, T> implements JPADataService<K, T> {


 protected Class<T> entityKey;
 protected Class<T> entityClass;
 protected EntityManager em;

 protected static Logger LOGGER = LoggerFactory.getLogger(JPADataServiceImpl.class);

 protected JPADataServiceImpl(TypeLiteral<K> key,TypeLiteral<T> entity) {
   entityKey = (Class<K>) key.getRawType();
   entityClass = (Class<T>) entity.getRawType();
 

  // Injected via guice @Provides, see below
  @Inject
  public void setEm(EntityManager entityManager){
        this.em = entityManager;
  }

  /**
   * {@inheritDoc}
   */
  public T get(K id) {
      T result = em.find(entityClass, id);
      return result;
  }

 ...


} 


The EntityManager injected above comes from a guice @Provides binding.

@Provides
EntityManager provideEntityManager(){
     try {
         logger.info("creating entity manager 'auction-test'"); 
         return Persistence.createEntityManagerFactory("auction-test").createEntityManager();
     }catch(Throwable ex){
         logger.error("Cannot create EntityManagerFactory.");
         throw new ExceptionInInitializerError(ex);
     }
}



Continuing with the generic pattern for concrete DAO's where you need more functionality then basic CRUD.

/**
 *  More interesting methods needed
 */
public interface JPAUserDataService extends JPADataService<Long, User> {

    public User getUserByEmail(String email);
    public Collection<User> getUserByEmployer(Employer employer);

}


/**
 * Implementation class
 *
 */
public class JPAUserDataServiceImpl extends JPADataServiceImpl<Long, User> implements JPAUserDataService{

    public JPAUserDataServiceImpl(){
        super(new TypeLiteral<Long>(){}, new TypeLiteral<User>(){});
    }

    @Override
    public User getUserByEmail(String email) {
        return null;  //todo
    }

    @Override
    public Collection<User> getUserByEmployer(Employer employer) {
        return null;  //todo
    }
}


Now that the implementation handles assigning all the generics you can fall back to the basic binding examples provided by guice.

 /**
  * guice binding
  */
 @Override
 protected void configure() {

      bind(JPAUserDataService.class)
              .to(JPAUserDataServiceImpl.class)
              .in(Scopes.SINGLETON);

       ...

}


Seems to be working well for me! You don't get the most out of DI this way as you end up with a one to one relationship of interface to implementation instead of the one to many. That being the case, this really only serves to simplify clients usage especially across multi-module project with as I noted, more then one data store SQL & NoSQL. I am thinking about another approach, a way to bind the more generic JPADataService to all the entities that don't need more then CRUD without having to extend for each type, AND while still allowing for more functional interfaces when needed (as shown).

Thursday, September 27, 2012

A dangerous development approach

When you are working in a time boxed iterative environment and before the time box has elapsed you are already self-correcting based on changing or unclear requirements, incorrect assumptions, or misunderstood goals STOP!!!!

The goal at the end of each iteration in agile is to have working code based on the design and requirements given/created at the start of that time box.  If  requirements are misunderstood or changing faster then your time box can complete, you have to re evaluate your approach by adjusting either the time box or the way in which you gather requirements and plan a design.

Common causes:

  1. Time boxing too long.
  2. Requirements too broad, or too vague!!
  3. Customer goals or business cases are not well understood.
  4. Implementation technology not well understood. 
Common cures:
  1. Break down the problems further.
  2. Shorten the time boxes and adjust goals accordingly.
  3. KNOW what the use cases are and what the customer expects (at that moment).
  4. Train on new technology in iterative cycles, just like development cycles.



Friday, April 13, 2012

Spring has arrived!

The most beautiful time of the year in New England has officially arrived! Enjoy the views outside my home.

Sunday, March 18, 2012

MapReduce For Dummies

I dumbed down the MapReduce functional programing model (for my required purposes) to a critically small set of resources and summary page.

Google Code University's MapReduce

Hadoop MapReduce Tutorial

Download the PDF here (much better)  that contains the diagrams, txt only portion follows.
MapReduce for Dummies

--------------------

Map Reduce for DUMMIES!

Map or f1(arg)->list: Takes single K,V pair and outputs a list with single K,V pair, multiple KV pairs, or none.  Input Key and Output Key need not be the same and are generally not!

Combine: If reduction (f2) is commutative and associative, i.e. doesn’t care which order it sees thing in. Generally this means result is same type as inputs which are also the same type (see f2 below) or a combine f(x) is built to handle differences. Do this if you have multiple identical Key here (can speed up reduction).

Sort:  Same K value are sent to the same reduce process, thus requiring K reduce processes running in parallel.  Done by mapper so this is being done distributed fashion.

Group: Key, Value lists! Keys from Sort with list of Values  (reduction is done per key)!

Reduce or f2(newValue, oldValue)->  nextOldValue, due to Group step, reduction is done per Key. Output is a Key and the accumulated values which are then passed back to be combined.


Credit (for everything correct) goes to UC Berkley’s Brian Harvey, PhD. for his excellent CS undergraduate lecture series.

http://www.cs.berkeley.edu/~bh/

------------------

You may require to logically join tables in Hadoop, how to do it?

MapReduce for Table Joins

A =Topic / B =DocEntityID / C = EntryDate / R = PLSA / S = MD

Join two relational sets with common key
R(A,B) x S(B,C)

Combine tuples from R & S that have same B value.

Map Process: 1
R tuple (a,b) -> (b,{a R})
(001,1234AX)   ->   (1234AX, {001,PLSA})
(002,1234AX)   ->   (1234AX, {002, PLSA})
(003,1234AX)   ->   (1234AX, {003,PLSA})
(001, 3279VC)  ->   (3279VC, {001,PLSA})
…        
Map Process: 2
S tuple (b,c)  -> (b,{c,S})
(1234AX, 20120316)  -> (1234AX, {20120316,MD})
(3279VC, 20120120)  -> (3279VC, {20120120,MD})
Sort Process for Map1:
1234AX,
            {001,PLSA}
            {002,PLSA}
            {003,PLSA}
              …
3279VC,
{001,PLSA}
               ...
Sort Process  for Map2:
1234AX, {20120316,MD}
3279VC,  {20120120,MD}
        … ,          …

Group1:
1234AX:
            {001,PLSA}
            {002,PLSA}
            {003,PLSA}
            {20120316,MD}

Reduce Process1:
 Store every value  under this key Key,List<Value>
   
Group2:
3279VC:
{001,PLSA}
{002,PLSA}
{003,PLSA}
{20120120,MD}

Reduce Process 2:
Store every value under this key Key,List<Value>


Credit (for anything correct) goes to Stanford’s Jeffery Ullman and Foto N. Afrati and their brilliant paper along with all credits and acknowledgements contained therein, “Optimzing Joins in a MapReduce Environment”.

Thursday, February 23, 2012

Scrum can lead to BAD software and engineering too....

Scrum


Scrum if you didn't know by NOW, is essentially micro-managment of software engineering at a  high level and of software engineers; work on these small prioritized tasks within estimated time constraints ranging only in hours, report daily on the progress and any issues so that they can immediately be addressed.  Cue up a variety of metrics that attempt to get more from the process then is put into it,  violates fundamentals of thermodynamics but keep trying: Velocity is killing Agile! This falls out from several principles of what is known as the "Agile manifesto" where Scrum was formed as an empirical process control model covering each principle in it's own way.  There is of course much more to it but boiled down that's the 1000 ft view on purpose and history.  I say micro-management in a good way here, it's tough to build complex software while forecasting delivery under modulating customer requirements if everything is allowed to run amok.  The rest of what Scrum promises however (product mgmt with a more accurate gauge of release and feature dev control) and BETTER ENGINEERING is highly debatable.

I'm pro Agile and Scrum really, but I don't think it's the answer to every problem or is in fact even an SDLC though many treat it as one.  There are also agile engineering practices to consider which Scrum does NOT address though it's great at measuring SOME of the results.

Scrum evangelism,  borderline idiocracy


Most of what you hear from Scrum advocates (esp newly minted ones) are some pretty broad characterizations about more traditional SW engineering practices that fall outside of what they have come to perceive as "agile".  Scrum offers a relatively easy to understand and implement process that can work.  The downside is evangelism behind Scrum that must somehow include as example by contrast the myriad of bad engineering practices and flawed management models that must have existed before; or anything else used today for that matter.  The truth is that MANY very large, robust, and successful projects have been built and sustained using Waterfall, Spiral, or something simply done using solid system engineering practices, RUP comes to mind.

What's worse is that many Scrum practitioners confuse engineering activity and practices with the Scrum process control, NOT THE SAME!  It should be clear that "value" in the Scrum sense relies primarily on practices not outlined in any manner by Scrum itself.  A  lot of what is in the engineering domain that Scrum proscribes, comes from XP (Extreme Programming) another Agile methodology.


Scrum is better then....


 Usually it's the dreaded waterfall, bane of all human endeavors! I challenge anyone that claims "Waterfall" as a failed model to describe it and point out that it must be anything other then employment of proven design, analysis, and development techniques that can be iterative and "agile" in many respects. I'll explain....

Waterfall is an SDLC, and Scrum is not!!  SCRUM is not an SDLC or project management methodology!

The proof of this is that it simply doe not illustratively inform on, design, architecture, release planning, QA process, and maintenance.

 In fact take a look at wikipedia's page on waterfall and you will find that the model described, requirements->design->implementation->verification is essentially what ALL development models adhere to no matter what they exactly call themselves.  It's only the level of scope and iteration between phases that defines a more agile approach.  Despite some shuffling with the verification you can't very well implement software without having some design that must have come from requirements, no? Even breaking down a goal or user story to something that can be developed is in effect design though it may not include specific technology.

Here is an SDLC that looks pretty much Waterfallish and I think it's easy to see how Scrum could be used inside such a lifecycle Design->Implement->Test.



If I were to make those arrows bi-directional and collaborative across roles I end up with something akin to Kanban, another agile process for software development.

Scrum is a tool realizing Agile principles but not the only one. 


There is a fair amount of largely non descript software development methods in industry leveraging from various methodologies while avoiding what doesn't fit.  I was recently turned on to Steve Yegge's (Google) blog post  good-agile-bad agile  demonstrating successful emergent practices.  In another more recent article agile-hybridization Christopher Goldsbury discusses not only hybrid approaches using Agile philosophy, but some great examples where Scrum is not a good fit for adoption or success.


 Scrum succeeds in being easy to understand and fairly rapid to put into place.  At the same time, the failure of Scrum to achieve desired results might be more nuanced and difficult to pinpoint.  On considering the Adoption of Scrum, I work in a highly matrixed environment where we move between projects ranging from pure research to near production level.  Thank God becasue it keeps me away from full time Scrum and endless Sprints.  The diversity of people's roles  and their locations are also in flux at MIT, no one size fits all methodology is going to succeed there.  Ken Schwaber's book, "Agile Project Management With Scrum" has some great stories about the failures encountered in bringing Scrum to new clients.  However;  it seemed that every failure listed was was attributed ONLY to mistakes in implementing Scrum and no exploration of other possibilities, admittedly it's a book about Scrum after all.

Monday, February 20, 2012

Accumulo on Mac OSX

Quick point of interest for anyone wishing to run Apache Accumulo on a mac.  You need to have three Apache projects (Accumulo, Hadoop, Zookeeper) installed for this to work, and luckily they all work flawlessly on mac.

Download Accumulo incubation src here, build using Maven as directed in the README. Move the distro someplace you will run everything from, /usr/local; /opt; or whatever you pefer.  A hadoop user is usually created to run all the services but I'm just using my local self and directories.

accumulo

Next get hadoop version 0.20.2 as also recommended by the accumulo team in the README.

For the user you select to run hadoop, zookeeper, and accumulo you will be setting the following common variable for the shell that will be used to start all the services. There is an option to add this to each of the services config so you must know the value in any event.

Add this line to (or its output) to the file $HADOOP_HOME/conf/hadoop-env.sh


export JAVA_HOME=$(/usr/libexec/java_home)

I chose to run in pseudo distributed mode as it mirrors cluster setup somewhat (cluster of 1). For that you will need to modify three files in the hadoop config directory $HADOOP_HOME/conf

*NOTE This caused a race condition that ran my processor at 90%, suggest if this occurs to use non distributed approach.


core-site.xml
======================

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>


<!-- Put site-specific property overrides in this file. -->


<configuration>
   <property>
     <name>fs.default.name</name>
     <value>hdfs://localhost:9000</value>
   </property>
</configuration>
~


mapred-site.xml
=======================

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>


<!-- Put site-specific property overrides in this file. -->


<configuration>
  <property>
     <name>mapred.job.tracker</name>
     <value>localhost:9001</value>
  </property>
</configuration>
~              



hdfs-site.xml
========================

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>


<!-- Put site-specific property overrides in this file. -->


<configuration>
   <property>
      <name>dfs.replication</name>
       <value>1</value>
   </property>


</configuration>


~

Make sure the both masters, and slaves, list localhost as the only value.

You will need password-less ssh configured for your "nodes" to talk to one another. Since the node is the same host, we enable that here only. Open up system-preferences and change the following setting under Sharing. I am  running all this as myself for dev purposes but normally there is a hadoop user as previously mentioned, if you did it that way obviously set up ssh for him.



 Now that is done, create the keys for you user in the user home dir and add them to the keyring as follows.


$ ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa
Generating public/private dsa key pair.
Your identification has been saved in /Users/cwyse/.ssh/id_dsa.
Your public key has been saved in /Users/cwyse/.ssh/id_dsa.pub.
The key fingerprint is:
c6:60:39:90:d7:d4:08:43:7e:d0:f1:5e:00:e4:1d:f5 cwyse@Chris-Wyses-MacBook-Pro-2.local
The key's randomart image is:
+--[ DSA 1024]----+
|    .o=*==o..    |
|    .o.=+o.o .   |
|     .* o o . E  |
|     . = . .     |
|        S .      |
|       .         |
|                 |
|                 |
|                 |
+-----------------+

$ cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys



Now when you $ssh localhost you will be connected without prompt for a password.

Next format the name-node using the following command from $HADOOP_HOME

$ $HADOOP_HOME/bin/hadoop namenode -format


You'll see some positive output listing your storeage directory and a shutdown, mine was.


Storage directory /tmp/hadoop-cwyse/dfs/name  


Now run 
$HADOOP_HOME/bin/start-all.sh


Some more good happy things happen, then go to this URL; http://localhost:50070/ and you will see something akin to this.






Congrats, we are half way there!


Now you will need zookeeper version  > 3.3.0


zookeeper


Installing zookeeper OOB is easy, I'm sure there are a ton of configurations in both hadoop and zookepper but this is just to get up and running with an accumulo shell so that you can being basic development on a cluster like setup. 


In $ZOOKEEPER_HOME/conf there is a sample config file, I copied it to zoo.cfg and ran with that option no changes.  


Quick connect to the service then shut it down.



$ZOOKEEPER_HOME/bin/zkServer.sh start
$ZOOKEEPER_HOME/bin/zkCli.sh -server 127.0.0.1:2181
Zookeeper will only need to be running in standalone mode.

The accumulo setup itself is straight out of the README.
Modify $ACCUMULO_HOME/conf/accumulo-env.sh by copying the *.example file and changing your env variables to JAVA_HOME and the locations you installed hadoop and zookeeper in. Copy the accumulo-site.xml, master and slave examples in place as well. Make sure hadoop and zookeeper are both running as described above.

Run 
$ACCUMULO_HOME/bin/accumulo init
to initialize the accumulo hdfs structure and setup instance and credentials.
Output upon should look like this.
$ACCUMULO_HOME/bin/start-all.sh 
Starting tablet servers and loggers .... done
Starting tablet server on localhost
Starting logger on localhost
Starting master on localhost
Starting garbage collector on localhost
Starting monitor on localhost
Starting tracer on localhost
I've yet to play with this much beyond writing this out so please let me know if there is something amiss.

Credits really go out to the Accumulo, hadoop, and zookeeper documenters as well as Chuck Lam's excellent "Hadoop In Action" Manning publication.  


Wednesday, December 7, 2011

Everything Connected

Stand on the beach and look out on the ocean. The water as far as you can see, and further still as you imagine it is. The waves roiling at your feet; gently rising swells secretly concealing their perceptible power until the land intrudes. The vast sheet of water from the surface to the depths, visible and invisible, all encompassing appearing before you. The familiar patterns, temperature, and feel of each totally unique experience just moments apart from one another.

We know that each molecule of water is touching each other one seamlessly throughout. The basics of the hydrogen bond. A foot in the water 10,000 miles away is directly connected to your foot. Every bit of solid matter pushes against this fabric in the way you might lay down individual objects onto a sheet before sorting them.

A child takes a bucket of water from the sea in play, this water is separated now? This water is still connected. It's connected to the air, or ground, or vacuum that is connected to the edge of the water somewhere again. And so throughout there exists this connection of everything to everything else. If you can see it in water first......

Tuesday, May 31, 2011

Memorial Day-Fourth of July 60K run! Supports SOWF!

Starting the weekend of Memorial Day (completed) to the Fourth of July I will be running a 10K each weekend to raise funds and awareness for the Special Operations Warrior Foundation.  My training partner and co-conspirator is another Veteran Mr. Jeff Fuqua.

The fundraising page can be found here, please donate in any way you see fit, by the mile, the kilometer, number of runs, whatever!

http://www.firstgiving.com/fundraiser/chriswyse/60KRun


View Larger Map

Dates and Times:

Monday  5/30     9:30 AM (COMPLETED)
Sunday    6/5      9:30 AM (COMPLETED)
Saturday  6/11    9:30 AM (COMPLETED)
Saturday  6/18    9:30 AM (COMPLETED)
Saturday  6/25    9:30 AM (COMPLETED)
Monday   7/4      9:30 AM (COMPLETED)

Thursday, April 7, 2011

Moment of Zen

/**
 * Before we create a user entry we get the CN loaded into the DRENUser DTO from the CAC card
 * You can only ever be who you really are....
 */
  public function before_create(){
  ...

Friday, January 28, 2011

Agile Architecture ©

In an upcoming paper on road mapping an Enterprise Architecture I am outlining the principles behind an Agile Enterprise Architecture delivery method.  Before the paper is completed I want to discuss the fundamentals of the agile approach and the reasons I am  motivated to develop it.

The fundamentals of this delivery method encompass a fusion of best practices from agile software development, and a hybrid of the architecture delivery methods as outlined in DoDAF 2.0 and TOGAF 9.0 architecture frameworks. I am not redefining or changing agile techniques, nor altering architecture delivery methods in the established frameworks.  This is a marriage of  industry proven processes and principles that brings the benefits of agile software development methodologies to enterprise architecture development.

The motivations behind tying agile methodologies to architectural delivery method (ADM) are listed below in no particular order.

  1. Bring continuous process improvement to all phases of the ADM.
  2. Introduce metrics and KPI's from lean systems engineering and agile methodologies into ADM.
  3. Insure the most suitable architecture addressing the problem domains is being developed.
  4. Speed time to deployment of actual architecture.

Philosophically I am striving to create the most usable end products from a complex problem set.  We have a rich and complete set of models in DoDAF, delivery method in TOGAF, and an empirical process control model exercised through agile methodology.

How best to tie these together is the quest, and I am traveling iteratively and aggressively towards this goal.

Saturday, January 15, 2011

Jazz and Computer Science?

I love this recent quote from American master musician Wynton Marsalis regarding his skills and the complexity of the music he plays. His attitude  resonates with me as a computer scientist and lover of challenges.

I like pressure, I like that, I like the challenge, I don't have a problem with it at all. I like the feeling of nervousness, I like the feeling that something counts, and I like to be tested 
-Wynton Marsalis 

I thought this was inspiring, you can see the entire interview linked below. Includes links to a Part II filmed in Havana Cuba.

Wynton Marsalis Interview

Thursday, January 13, 2011

Business Rules and SOA Policy

Blogger Randy Heffner posted an interesting piece on business rules and SOA policy. The takeaway for me is a focus on both domain specific languages that allow business users (non programmers)access to logic that used to reside in source code, and the tools, governance, and policies surrounding making changes in that logic.

If  I'm the Captain of a ship at sea and I desire a change in the way a system behaves or process executes, how can I change it NOW.


Business 2011 Gets Faster; Business Rules And SOA Policy Get More Important
Posted by Randy Heffner on December 7, 2010

Can you remember a year when your business both (1) grew in a healthy way and (2) changed more slowly than the year before? Besides a company’s early startup years, such would be the exception, not the rule. So, in 2011, your business is likely to continue accelerating its pace of change. A recent Forrester report, The Top 15 Technology Trends EA Should Watch: 2011 To 2013, named both business rules and SOA policy as items for your watch list — because both of them help accelerate business change.

Back in the mainframe days — and even into minicomputer, client/server, and Web applications — nearly all of the business logic for every application was tightly wrapped up in the application code. A few forward-thinking programmers might have built separate parameter files with a small bit of business-oriented application configuration, but that was about it. But, business changes too quickly to have all of the rules locked up in the code.

Some have tried the route that businesspeople ought to do their own programming — and many vendor tools through the years have tried creatively (though unsuccessfully) to make development simple enough for that. But, business is too complex for businesspeople to do all of their own programming.

Enter business rules, SOA policy, and other ways to pull certain bits of business logic out of being buried in the code. What makes these types of approaches valuable is that they are targeted, contained, and can have appropriate life cycles built around them to allow businesspeople to change what they are qualified to change, authorized to change, and have been approved to change.

Although neither makes the headlines like cloud and such, 2011 will see continued adoption and growth of business rules and SOA policy. Business rules technology is much farther along in adoption than SOA policy — as it should be. SOA policy requires much more architectural work, particularly when (a) used beyond its core of security policy and management policy or (b) set up to allow businesspeople to do their own change.

But here's the crux of the matter: Both business rules and SOA policy are part of a much broader trend to build software around flexible business design focal points. Do you need to start or expand your adoption of them in 2011? Perhaps, but only if you do your homework so that you'll get the value. The important things to focus on are (1) understanding where and how your business most needs flexibility and (2) using business rules, SOA policy, business process flow, and other techniques and technologies to accelerate your ability to change the business.

- Randy Heffner

Sunday, January 2, 2011

Enterprise Decision Management Screencasts in HD on YouTube

Screen casts are also available in HD on YouTube directly. Hope you enjoy, Part III is being worked on.

www.aeitg.com