REST - restful webservices, hateoas, rmm

Richardson Maturity Model - http://martinfowler.com/articles/richardsonMaturityModel.html

• Level 0 - Swamp of Pox
• basically HTTP as a tunneling mechanism for RPI

• Level 1 - Resources
• have more than one endpoint.. start talking to individual resources
• allows you to break one monolithic endpoint down into multiple resources

• Level 2 - HTTP Verbs
• using more than just POST for everything
• allows you to use *standard* verbs

• Level 3 - Hypermedia Controls (HATEOAS)
• start including LINKS to self and other resources
• allows discover-ability and promotes self-documentation and allows you to build services that decouple client and server to a large extent and allow them to evolve independently

More about HATEOS theory -

• https://spring.io/understanding/HATEOAS,
  
• https://en.wikipedia.org/wiki/HATEOAS
  
• A hypermedia-driven site provides information to navigate the site's REST interfaces dynamically by including hypermedia links with the responses.

More about developing HATEOS with Spring -

• http://projects.spring.io/spring-hateoas/
  
• Spring HATEOAS, a library of APIs that you can use to easily create links pointing to Spring MVC controllers, build up resource representations, and control how they’re rendered into supported hypermedia formats such as HAL
  
• Support for hypermedia formats like HAL - more about HAL:  https://en.wikipedia.org/wiki/Hypertext_Application_Language

Book - Influence, the Psychology of Persuasion

This was kinda off track for books I normally get, but I liked it.
Gives insight into the human psyche.

Was gonna write up more details below, but I found this youtube video that basically sums up the whole damn book in 12 minutes:

https://www.youtube.com/watch?v=cFdCzN7RYbw

6 Factors:

1. Reciprocation
2. Commitment and Consistency
3. Social Proof
4. Liking
5. Authority
6. Scarcity

Service Discovery

Consul vs Eureka vs Etcd vs Zookeeper vs RollYourOwn:
  http://www.gomicro.services/articles/service-discovery-overview
 
Consul vs Zookeeper:
  https://www.consul.io/intro/vs/zookeeper.html


And then some really heavy stuff:
http://progrium.com/blog/2014/08/20/consul-service-discovery-with-docker/
http://progrium.com/blog/2014/07/29/understanding-modern-service-discovery-with-docker/
http://book.mixu.net/distsys/single-page.html

A comprehensive solution to service discovery will have three legs:

• A consistent (ideally), highly available service directory
• A mechanism to register services and monitor service health
• A mechanism to lookup and connect to services

Chubby, Zookeeper, etcd, Consul are distributed data stores that are defined by their use of a consensus algorithm requiring a quorum for writes and generally exposing a simple key-value store.
Sometimes also called a 'lock server' or 'config store'.

12 factor apps

Summary:
http://www.clearlytech.com/2014/01/04/12-factor-apps-plain-english/

Full:
http://12factor.net/

The Twelve Factors

I. Codebase

One codebase tracked in revision control, many deploys

II. Dependencies

Explicitly declare and isolate dependencies

III. Config

Store config in the environment

IV. Backing Services

Treat backing services as attached resources

V. Build, release, run

Strictly separate build and run stages

VI. Processes

Execute the app as one or more stateless processes

VII. Port binding

Export services via port binding

VIII. Concurrency

Scale out via the process model

IX. Disposability

Maximize robustness with fast startup and graceful shutdown

X. Dev/prod parity

Keep development, staging, and production as similar as possible

XI. Logs

Treat logs as event streams

XII. Admin processes

Run admin/management tasks as one-off processes

Dryer Failure

So.. the dryer stopped drying today.
Checked lint trap
Check exhaust hose
removed exhaust hose
blower was working...
just seemed to not be producing heat.
first thought was the heater element died, but the internet is smarter than me and it said i should check the thermal cut-off.
multimeter said thermal cut-off was Open.. which means its dead... so ordered a new one.
and ordered a new thermostat too. its recommended to replace em both

Wikipedia says thermal cut-off seems to be able to act as a switch VS a thermal fuse seems to be like a regular electrical fuse:  cook it once and its done. 

Anyhow, found parts online (damn you homedepot, lowes, sears for not carrying that stuff) and hopefully it'll showup within five days.







photo stolen from 'justanswer.com' cuz it just easier

wget - downloading website recursively

So there is this humor & stuff website I like and I wanted to have a push-button approach to getting the posts of the day so I could browse it on the train where the wifi sucks.

Came up with this:

wget --domains=thechive.com,thechive.files.wordpress.com -r -l 1 --restrict-file-names=windows -E -H -k -K -p -e robots=off 'http://thechive.com/'

So all the images get grabbed ..but they have some wonky suffix.
So threw together a shell script to clean em up:

for f in *; do
    z=$(echo "$f" | cut -d"@" -f 1)
    echo "$z"
    mv "$f" "$z"
done

Docker and Beaker (Puppet Testing)

Sooo... we've historically been very bad about testing our puppet stuff.
We don't really do module level testing.
We manually do end-to-end testing.  I guess its been 'good enough' so far...although tedious.

Anyways, I thought we should chart some new territory and attempt to use Beaker to some degree.

Beaker Wiki: link

Anyways...turns out they support Docker.
I thought, yay, finally an excuse to play with Docker a bit.

Turns out it was a pain in the ass to setup though.

1. Get the Ubuntu 14 vagrant box:
   https://atlas.hashicorp.com/ubuntu/boxes/trusty64
    
2. SSH into that box
    
3. Install Beaker on that box
   https://github.com/puppetlabs/beaker/wiki/Beaker-Installation#installing-beaker
    
4. Install Docker on that box
   https://docs.docker.com/installation/ubuntulinux/
    
5. Create a 'beaker hosts config file' on that box
   example file:  "beaker_hosts.cfg"
   
   HOSTS:
     ubuntu-12-10:
       platform: ubuntu-12.10-x64
       image: modified_ubuntu
       hypervisor: docker
   CONFIG:
     type: foss

6. Do a simple 'docker run' to get docker to download the Ubuntu Container Image:
   sudo docker run ubuntu:12.10 /bin/echo 'shit'
    
7. Modify the Ubuntu Container Image by installing 'ssh' onto it:
   sudo docker run ubuntu:12.10 apt-get install -y ssh
    
8. Find the 'container id' after the previous step finishes.
   sudo docker ps -l
    
9. Commit the changes to the container
   sudo docker commit someFriggingUglyContainerId modified_ubuntu
    
10. Confirm that 'ssh' is installed:
    a) open an interactive session with the new container thingy:
    sudo docker run -i -t modified_ubuntu /bin/bash
    b) start the 'ssh' service on the new container thingy:
    service ssh start
    c) quit the new container thingy:
    exit
     
11. Run beaker on the VM !!
    sudo beaker --log-level debug --hosts beaker_hosts.cfg
    
12. Happy Dance.

The following images MAY have differently named files/settings... so just use your brain:

MongoDB - Authentication

system.users collection  associates a user+database with 1+ roles
{http://docs.mongodb.org/v2.6/reference/system-roles-collection/}

system.roles collection  associates a role+database with 1+ privileges and/or 1+ roles to inherit
{http://docs.mongodb.org/v2.6/reference/system-users-collection/}

• user
  {http://docs.mongodb.org/v2.6/reference/command/#user-management-commands}
  MongoDB scopes a user to the database in which the user is created.

• role
  {http://docs.mongodb.org/v2.6/reference/built-in-roles/} 
  {http://docs.mongodb.org/v2.6/reference/system-roles-collection/} 
  {http://docs.mongodb.org/v2.6/reference/command/#role-management-commands}
  role is a collection of privileges (privilege is a resource and 1+ actions)
  role applies to database on which its defined
  MongoDB stores all role information in the admin.system.roles collection in the admin database.

1. Database User Roles
   {http://docs.mongodb.org/v2.6/reference/built-in-roles/#database-user-roles}
   {read, readWrite}
2. Database Admin Roles 
   {http://docs.mongodb.org/v2.6/reference/built-in-roles/#database-administration-roles}    {dbAdmin, dbOwner, userAdmin}
3. Cluster Admin Roles 
   {http://docs.mongodb.org/v2.6/reference/built-in-roles/#cluster-administration-roles}    {clusterAdmin, clusterManager}
4. Backup & Restore Roles 
   {http://docs.mongodb.org/v2.6/reference/built-in-roles/#backup-and-restoration-roles}    {backup, restore}
5. All-Database Roles 
   {http://docs.mongodb.org/v2.6/reference/built-in-roles/#all-database-roles}{readAnyDatabase, readWriteAnyDatabase, userAdminAnyDatabase, dbAdminAnyDatabase}
6. SuperUser Roles
   {http://docs.mongodb.org/v2.6/reference/built-in-roles/#superuser-roles}
   {root, userAdminAnyDatabase, and (dbOwner or userAdmin)when scoped to admin database}

• privilege 
  {http://docs.mongodb.org/v2.6/reference/privilege-actions/}
  privilege is a resource and 1+ actions

• resource 
  {http://docs.mongodb.org/v2.6/reference/resource-document/}
  {Database, Collection, Cluster}

• action 
  {http://docs.mongodb.org/v2.6/reference/privilege-actions/}
  define the operations a user can perform on a resource
1. Query & Write actions 
   {http://docs.mongodb.org/v2.6/reference/privilege-actions/#query-and-write-actions}   
   {find, insert, remove, update}
2. Database Management actions 
   {http://docs.mongodb.org/v2.6/reference/privilege-actions/#database-management-actions}
   {changeCustomData, changeOwnCustomData, createCollection, createIndex, createRole, createUser, enableProfiler, killCursors, unlock, etc etc}
3.   Deployment Management actions 
   {http://docs.mongodb.org/v2.6/reference/privilege-actions/#deployment-management-actions}
   {authSchemaUpgrade, cleanupOrphaned, cpuProfiler, inprog, killop, planCacheRead, storageDetails, etc etc}
4. Replication actions 
   {http://docs.mongodb.org/v2.6/reference/privilege-actions/#replication-actions}   
   {appendOplogNote, replSetConfigure, replSetGetStatus, resync, etc etc}
5. Sharding actions 
   {http://docs.mongodb.org/v2.6/reference/privilege-actions/#sharding-actions}
   {addShard, enableSharding, flushRouterConfig, listShards, moveChunk, shardingState, etc etc} 
6. Server Admin actions 
   {http://docs.mongodb.org/v2.6/reference/privilege-actions/#server-administration-actions}
   {closeAllDatabases, collMod, compact, convertToCapped, dropDatabase, dropIndex, hostInfo, logRotate, repairDatabase, shutdown, touch, etc etc} 
7. Diagnostic actions 
   {http://docs.mongodb.org/v2.6/reference/privilege-actions/#diagnostic-actions}
   {collStats, connPoolStats, cursorInfo, dbStats, getLog, indexStats, listDatabases, netstat, serverStatus, top, }  
8. Internal actions 
   {http://docs.mongodb.org/v2.6/reference/privilege-actions/#internal-actions}
   {anyAction, internal}

Cape Cod 2015 - Part 3

 

 

 

 

 

 

 

 

 

Cape Cod 2015 - Part 2

Cape Cod 2015 - Part 1

 

Docker - finding canned images to use

https://registry.hub.docker.com/

Images for Ubuntu,  Redis, Wordpress, Mongo, NGinX, NodeJS, etc etc