Am I a Foodie?

Wikipedia definition of Foodie

A foodie is a person who has an ardent or refined interest in food and alcoholic beverages. A foodie seeks new food experiences as a hobby rather than simply eating out of convenience or hunger. 

Google Dictionary Foodie

a person with a particular interest in food; a gourmet.
synonyms: gourmet, epicure, gastronome, gourmand 

During lunch last week someone at work asked me if I had any food aversions. I said I would pretty much eat anything. Then I was asked if I was a foodie. I did not know what to say. I have never considered myself a foodie. Mostly because when I think of foodie I think of men in black turtlenecks drinking wine and eating expensive small plated meals. The Google definition of Foodie is definitely not me.  But Wikipedia describes me perfectly.

I have eaten $1.50 Van De Camp Fish sticks and a meal at a Michelin Star restaurant.

So you decide. These are some of the great meals I have had over the last month.

Van de Camp Fish Sticks with Ketchup @ Home
$1.50
Brings back memories of being a kid.

Sashimi @ Kinoshita Restaurant in Sao Paulo Brazil
$25.00

Wagyu Beef @ Kinoshita Restaurant in Sao Paulo, Brazil

Lamb Osso Bucco @ Josephine's in Sao Paulo Brazil
$23.00

Gnocchi Ragu @ Josphine's in Sao Paulo Brazil
$18.00

Tempura Soft boiled egg in Tokyo, Japan
$1.50

Raman Noodles with Boiled Egg and Pork in Tokyo Japan
$7.50

Traditional Japanese Lunch in Tokyo, Japan.
$12.00

BBQ Beef, Poutine and Fries @ Montreal Airport, Canada
$12.00

Cheese Potatoes and beef Foil Dinner
@ 11 year old scout campout
$2.00

Tokyo 1st Ward - An Expat story

Another trip abroad and another visit to church on Sunday. I am so grateful that I have the Church in my life. I enjoy attending church when I travel; it gives me a feeling of belonging no matter where I am. This time I am in Tokyo, Japan. I got onto lds.org and found the nearest church building to my hotel. It was Tokyo 1st Ward, an English speaking expat Ward. Expat Wards are very different from the typical Ward because of their transient nature. Most Expats are in country for 2-3 years and then go back home to the United States or their home country. That means that there is a 1/3 turn over every year in the Ward. Imagine being the Bishop in a Ward like that when all of your volunteers for teachers, youth programs and music are changing every year. Must be hard to have any consistency in the Ward.

I sat next to a family and started talking about their experience in Tokyo. This time a young family with four little kids under the age of 10. They love Tokyo, so much so that they want to extend their stay from 2 years to 3 years. They said the city is clean, very safe and the people are very nice and friendly. Especially helping them figure out the basic day to day things in life, like grocery shopping.  One of the biggest changes has more to do with Suburban American living compared to Urban living in Japan. "Driving a Car".

As a west coast American, driving is like breathing. We have to do it to survive. We love our cars in California's central valley. And not having a car would be very difficult. I even have a hard time when I travel and don't rent a car. No I did not rent a car in Tokyo. :( I found out from this family that they felt the same way and originally got a car when they got here to Tokyo. But quickly returned it after a couple of weeks. A couple of things caused them to stop driving and start riding bikes and taking the trains.

First, they drive on the left hand side of the road. Thanks to the British, the Japanese drive on the "wrong" side of the road. Second, Tokyo is an ancient city and was designed to confuse and disorient invading armies. So the streets are more like a maze than a grid of streets like we have in the western United States. The labyrinth of one way single lane roads is hard to navigate. Tokyo's subway system is extensive and easy to access any part of the city. Therefore, taking the subway and riding bikes is the way that this family has decided to go.  Can you image going to the local grocery store on your electric bike with two kids in tow? That is what happens in Tokyo. :)

Overall, another great visit to church. And I got a bonus. The church I went to was right next to the Tokyo Temple so I got to see the small but impressive Temple Grounds.

I hope to calm down the travelling the next couple of months. I don't want my home ward (or my wife for that matter) to think I have disappeared.

DWP

Bouquet Binary

I recently dusted off an old project of mine called Bouquet. It basically helps me quickly

architect and design systems. See my original blog here. This blog focuses on the Command Line Interface (CLI) aspect of the Bouquet Project.  The project is hosted on GitHub here. https://github.com/madajaju/bouquet

Binary setup

There are several different kinds of binary files that are used in the bouquet pattern.

1. Top Level Command script - "projectName"
2. Actor Command Script - "projectName-actorName"
3. Subsystem Command Script - "projectName-subsystemName"
4. Command Script - "projectName-actorName-command", "projectName-subsystemName-command", or "projectName-command"

The goal here is that we have a consistent command line interface. For example in the project named caade the following are some commands

# caade init // High level scenario
# caade stack up // Subsystem Command
# caade dev ps // Actor Command

Top Level Command Script

There should be one system command that contains all of the commands for the system using the commander package.

• The name of the file should be "projectName" in the bin directory.
• The for each actor there should be a command for the actor. This will give a command line interface for each actor
• There should be a command for each subsystem as well. This will give the ability for each subsystem to have a CLI.
• There should be a command for each of the top level scenarios for the system. The following is an example of this top level command file

In this case "caade"

#!/usr/bin/env node

var program = require('commander');

program
  .version("0.2.0")
  // Actors
  .command('app <command> <applicationName>', 'Work with applications')
  .command('stack <command> <stackName>', 'Work with applications')
  .command('adm <command> <stackName>', 'Work with applications')
  // SubSystems 
  .command('policy <command> <policyName>', 'Work with Policies')
  .command('cloud <command> <cloudName>', 'Work with Clouds')
  .command('environment <command> <EnvironmentName>', 'Work with applications')
  .command('service <command> <EnvironmentName>', 'Work with servioes')
  .command('user <command> <UserName>', 'Work with Users')
  // Scenarios
  .command('init', 'initalize Caade on your machine')
  .command('up [service-name]', 'Launch an application in a specific environment')
  .command('update [service-name]', 'Update web service with new code')
  .command('run <command>', 'Run a command in specified environment')
  .command('ps <command>', 'List processes for the application')
  .command('kill <serviceName>', 'Kill specific service for the application')
  .command('logs [serviceName]', 'Get logs of the application')
  .command('deploy', 'Deploy an application')
  .parse(process.argv);

Actor Command Script

This is very much like the Top level command script but limits the commands to the actor The file is named "projectName-actorName" a simple example follows.

In this case "caade-app"

#!/usr/bin/env node

var program = require('commander');

program
  .version("0.2.0")
  .command('create <application name>', 'Create an application')
  .command('get <application name>', 'Create an application')
  .command('ls', 'List my applications')
  .command('remove <application name>', 'Remove my application')
  .command('show <application name>', 'show details about my application')
  .parse(process.argv);

The Controller for this might look something like this AppController.js

module.exports = {

  create: function (req, res) {
    var name = "";  // Default
    var stackName = "";  // Default
    if (req.query.name) {
      name = req.query.name;
    }
    else {
      // Return Error "No Application Name specified"
      return res.json({error: "No Application Name specified!"})
    }
    if (req.query.stack) {
      stackName = req.query.stack;
    }
    else {
      // Return error with "No Application Stack specified"
      return res.json({error: "No Application Stack specified!"})
    }
    return Application.find({name: name})
      .then(function (app) {
        res.json({application: app});
      });
  },
  get: function (req, res) { ... },
  delete: function (req, res) { ... },
  list: function (req, res) { ... },
  show: function (req, res) { ... },
  ps: function (req, res) { ... },
  up: function (req, res) { ... },
  kill: function (req, res) { ... }
};

Subsytem Command Script

This is very much like the Top level command script but limits the commands to the subsystem The file is named "projectName-subsystemName" a simple example follows.

In this case "caade-cloud"

#!/usr/bin/env node

var program = require('commander');

program
  .version("0.2.0")
  .command('create <cloudName>', 'Attach a Cloud')
  .command('ls', 'List the Clouds attached')
  .command('remove <cloudName>', 'Remove a Cloud')
  .command('show <cloudName>', 'Show details about a Cloud')
  .parse(process.argv);

Command Script

Command scripts are where everything really happens. The previous scripts just setup for accessing the command scripts. The naming convention of the command scripts follows the actor and subsystem nomenclature "projectName-actorName-command", "projectName-subsystemName-command", or "projectName-command". The trick of the command is to connect to the rest interface of the system. This should coorespond to the controller with a simalar name. For example if you have actor command script then there should be a cooresponding controller for the actor. This way the REST and CLI APIs are consistent.

The following is an example of a simple Command Script that accesses the rest interface. In this case it shows information about a stack in the system

#!/usr/bin/env node

var program = require('commander');
var Client = require('node-rest-client').Client; // Needed to access the REST Interfacce.
var config = require('./system-config'); // Contains the URL to connect to for the REST Interface
var _ = require('lodash');

var client = new Client();

program
  .option('-v, --version <versionNumber>', 'Show an application stack with version')
  .parse(process.argv);

var name = program.args;

// Create the REST Command
var url = config.caadeUrl + "/stack/show?";

if(name) {
  url += "name=" + name[0];
}

if (program.version) {
  url += "&version=" + program.version;
}
// Call the REST Interface via HTTP Client.
client.get(url, function (data, response) {
  // parsed response body as js object
  if(data.error) {
    console.error(data.error);
  }
  else {
    console.log(data.stack);
    console.log("Name:" + data.stack.name + "\tVersion: " + data.stack.version);
  }
});

Another thing that I found useful was having the ability to include the ability to allow the user to add a file as an argument to the CLI. This is good for passing in yaml or json files that can be passed into the Controller. In this case I am passing in a yaml file.

#!/usr/bin/env node

var program = require('commander');
var Client = require('node-rest-client').Client; // Access the REST interface
var config = require('./caade-config');
var YAML = require('yamljs'); // Parse a YAML file

var client = new Client();

program
  .option('-f, --filename <filename>', 'Create an application stack from file')
  .option('-e, --env <environmentName>', 'Create an application stack for the environment')
  .parse(process.argv);

var name = program.args;

var url = config.caadeUrl + "/stack/create";
// Taking a YAMLfile and converting to JSON and then passing it into the REST interface.
var args = { headers: {"Content-Type": "application/json"}, data: {} }

if(name) {
  args.data.name = name[0];
}

var definition = {};
// Load the YAML file from the local drive and convert it to JSON.
if (program.filename) {
  args.data.definition = YAML.load(program.filename);
}

if (program.env) {
  args.data.env = program.env;
}

client.post(url, args, function (data, response) {
  // parsed response body as js object
  if(data.error) {
    console.error(data.error);
  }
  else {
    console.log("Stack " + data.stack.name + " has been created for environment " + program.env);
  }
});

Look for more information on my blog. DWP

A Friend, a Parent and Mission Presidents

Serving together forms bonds between people that draw them closer together that last for years. These bonds are typically found in fellow soldiers.  I have not served in war or even in the military; So I cannot understand or even fathom the bond that these soldiers feel one with another. But this last week I got a small glimpse of that feeling form the bonds I have created in serving with others in my church.

A Friend

I had the opportunity to serve with Loren Dalton, (Now President Dalton) in Tracy, California over 20 years ago. There I served as an Elder's Quorum President for the newly called Bishop Dalton. 

A Mormon Bishop is a volunteer position in the Church that is in charge of a congregation of about 300 church members. They are responsible for the spiritual and physical needs of the congregation. An Elder's quorum president works with the Bishop as well as others and is focused on families whose parents are typically between the age of 18 - 45 to 50 years old. 

So back to my story. A worked with Bishop Dalton for about 2 years and enjoyed the friendship that we built working together. Recently I was traveling in Sao Paulo Brazil and found out that Bishop Dalton had been called to be a Mission President in Sao Paulo Interlagos Mission. 

Mission Presidents are asked to serve for 3 years. During the 3 years they take their families and leave behind work and their livelihoods and live in the mission. Mission Presidents are in charge of about 200 missionaries in a geographical area.

It was great meeting with President Dalton and his wife, and after 20 years we had a lot of catching up to do. We talked about kids, families, careers and the ups and downs of life. I was most excited to hear what mission life was like and we talked about how their mission has changed their lives and strengthened their testimonies of Christ and his work. It was great to spend an evening with them. I was impressed at how much the Dalton's cared for their missionaries in the mission. They helped their missionaries through tough times at home, person trials and triumphs during their missions. 

This was somewhat self serving for me because my son Jacob was called to serve in that same mission starting in June. The Dalton's will be leaving before Jacob actually arrives in the mission :(.

In part of our conversation President Dalton asked me who my mission president was 28 years ago when I served in Brazil. I mentioned it was President Paulo Grahl. To my surprise he knew President Grahl and told me he was serving as the President of the Mission Training Center in Sao Paulo. He told me I had to go see him.

A Parent

It might be strange for people that have not served a mission to understand the strong bond that missionaries have with their mission presidents. As a missionary you write a weekly letter to the president of the mission telling them how things are going. Some weeks the letters are just complaining about the work other weeks sharing great experiences. This is your direct line to the president. Additional about every 2-3 months you get to have a 1 on 1 interview with the president to talk about things going on in the mission. The President and his wife quickly become the your leaders/parents for those two years. It is a special bond. One that, as I would soon find out, last a life time.

I took President Dalton's advise and went to the MTC to visit President and Sister Grahl. My missionary parents from almost 30 years ago. When I arrived at the MTC I did not realize, something I would find out later, that this was the day that new missionaries arrived to start their 6 week training in Sao Paulo. So President Grahl was busy working with these new missionaries. I patiently waited for outside of the gates of the MTC to see if they would let me in. About 20 minutes later, a slightly grayer, slightly heavier, man walked out of the MTC. We recognized each other immediately and almost like a scene from a movie we ran up and gave each other a big hug.

I was quickly transported to 28 years earlier when this great man hugged me for the first time, a lost and confused missionary in the Brasilia Brasil airport after a 15 hour trip from California to Brazil to start my mission. All of the feelings of two years of working with this great man came back. The shared experiences, the good and the bad. His great big bear hug is what transported my so quickly back. It was a strong loving hug that a parent gives to a child after years of being away.

I felt like I needed to give him a report about my life, my family, my career, my service in the church. I wanted him to be proud of me. The good kind of proud. We got to talk briefly about our mission time together and I got a great tour of the MTC. Again self serving because Jacob would be living in the MTC in Sao Paulo for about 6 weeks while he is learning Portuguese. I mentioned this to President Grahl and he was excited to have one of his "Filhos" have a child server under him. The first from the United States that would be serving in Sao Paulo.

Next President Grahl surprised Sister Grahl who at the time was talking to the new missionaries about what she always talked to us about. Cleanliness and Obedience. Brings back memories of several missionary conferences where she taught us the importance of having clean apartments and keeping the mission rules.  She took about 30 seconds and remembered my name. I was floored. I could not imagine that someone would remember me so well even after white hair and about 60 lbs. What a great couple of hours I got to spend with my Mission Mom and Dad.

Mission Presidents

Many people don't really understand the value that a mission president has on the lives of the Elders and Sisters that server under them. This last week I got a small glimpse into what Mission Presidents do and the impact they have had on my life. I cannot wait for my son Jacob to form those kind of lasting bonds with his mission president in the next couple of years.

DWP

Resurrecting Bouquet

Bouquet

In the 1990s I started dabbling with a new kind of system analysis. Object Oriented System Analysis. I quickly became familiar with all of the great OOA/D tools. The one that stood out for me was Rational Rose. I dove right in and over time became quiet proficient in using the tool. I quickly started writing scripts to to make my life easier and automate repeated tasks. This was the birth of a project named Bouquet.

Move forward 20 years. I am still using UML to design and architect systems, but I also use rapid prototyping technologies like sails, rails and grails. Most recently I am focusing on NodeJS/SailsJS development. I dusted off my old Bouquet specs and started working on resurrecting Bouquet with the latest technologies.

These are the technologies that I am leveraging this time.

• PlantUML - Textual way of describing UML diagrams
• SailsJS - MVC framework for NodeJS development
• Commander - npm module for command line programming for NodeJS
• GitHub MD - Markdown language for projects in GitHub.

The tools by themselves are very useful. Bringing all the tools together is where I found the most benefit.

PlantUML

PlantUML is a component that lets you quickly write several UML diagrams using Text instead of a drawing tool. It is great for many but not all of the UML diagrams. I have found that it covers everything that I typically need to do for Architectures of systems. UseCase, Component, Class, Deployment, Scenarios, and Activity Diagrams.

One of the benefits of using PlantUML that the text files that your create (*.puml) can be checked in to GitHub. You can also generate image files (png) from the text files (puml) and check in the image files as well. I do this so my design documents in GitHub (Markdown language is used) can reference the images that have been generated. Generating the image (png) files is as easy as typing in a command line.

# java -f design/plantuml.jar myDiagram.puml

Because I am using NodeJS. I can use a npm script command to actually generate all of the my images. Basically I put another target in my package.json file in the root directory that searches all of my design directories and generates the png files.

  "scripts": {
  ...
  "design": "java -jar design/plantuml.jar design/*.puml design/**/*.puml",
  ...
  }

Now you can generate png files for all of your design diagrams, just type.

# npm run-script design 

To find out more about PlantUML click here You can download the latest jar file for quick image generation here. There is also a Plugin for PlantUML for Intellij and several other IDEs.

SailsJS

SailsJS is a MVC convention over configuration framework for NodeJS applications. This uses a common pattern that can be found in several programming languages today. Examples include Ruby o Rails, and Groovy on Grails.

Commander

Commander is a nodejs module for command-line processing. I use this to develop command line interfaces for the systems that I architect. This gives me a quick and dirty way of providing a command line interface with very little lifting.

GitHub MD

MD - Markdown language is used to quickly and easily document a git hub repository. The language allows for simple text based documentation to make it quick and easy.

Bouquet

Using the concept of convention over configurability of SailsJS, I extended the same concepts that already exist in SailsJS and created a design and bin directory in the project root directory. This gives me a place to put the design of the architecture as well as the CLI (Command Line interface) of the system being architected. This is important because most of the architectures I am working have a Web, REST and CLI .

Directory Hierarchy

After a SailsJS project is created a standard directory hierarchy contains several directories and files. I added two additional directories to the top level (bin, design, and test). Next, I add corresponding subdirectories in the design directory as shown below.

• api - Standard SailsJS directory
• assets - Standard SailsJS Directory
• bin - Contains commander binaries
• config - Stanard SailsJS Directory
• design - Contains Architecture and Design of the system
  • Actors - Actors of the system
    • README.md - ReadMe for all of the Actors
    • < Actor Name > - Directory for each Actor of the system
  • UseCases - Use Cases of the system
    • README.md - ReadMe file for all of the UseCases
    • UseCases.puml - PlantUML file for all of the Use Cases and Actors
    • < UseCase Name > - Directory for each Use Case of the system
  • Systems - System Components
    • README.md - ReadMe for all of the sub-systems
    • < Sub System Name > - Directory for each sub system.
  • README.md - Top ReadMe for the Architecture and Design
  • Architecture.puml - Top level architecture plantUML diagram
  • plantuml.####.jar - plantUML jar file used to generate png files.
• tasks - Standard SailsJS Directory
• test - Contains test for the system.
  • bin - Test the CLI
  • Actors - Test the Actor interactions One Test Suite per Actor with each use case
  • UseCases - Test the Scenarios as described. One Test Suite per Scenario with tests for each different path through the scenario
  • System - Test of each subsystem. One Test Suite for each SubSystem, a test for each of the interface calls.
• views - Stand SailsJS Directory

Future 

I know as I start using this I will add more generated artifacts to the system. So if you have any ideas please let me know. You can find more at the github project

Additional Blogs in a series of Bouquet Blogs

• Bouquet Binaries