How to migrate from the MySQL Extension to PDO

My team's start-up has a web application that is currently using MySQLi Extensions.

Switching to PDO has many advantages:

• offers a consistent API to work with a variety of databases
• exposes high-level objects for the programmer to work with database connections
• low-level drivers perform communication and resource handling with the database server

Basic Workflow

The basic workflow for working with a database can be thought of as a 5-step process:

1. Establish a connection to the database server and select the database you’ll be working with
2. Construct a query to send the server
3. Send the query
4. Iterate over the returned result rows
5. Free the resources used by the result and possibly the database connection

With PDO, the same process can be followed and looks like this:

<?php // Step 1: Establish a connection $db = new PDO("mysql:host=localhost;dbname=testdb", "testusr", "secretpass"); // Step 2: Construct a query $query = "SELECT * FROM foo WHERE bar = " . $db->quote($zip); // Step 3: Send the query $result = $db->query($query); // Step 4: Iterate over the results while($row = $result->fetch(PDO::FETCH_ASSOC)) {     print_r($row); } // Step 5: Free used resources $result->closeCursor(); $db = null;

How to create a StackStorm Pack

What is a Pack?

Pack is the unit of deployment for integrations and automations in order to extend StackStorm. Typically a pack is organized along service or product boundaries e.g. AWS, Docker, Sensu etc. A pack can contain Actions, Workflows, Rules, Sensors.

It is best to view a pack as the means to extend StackStorm and allow it to integrate with an external systems such as Git, Google. AWS, Jenkins, etc.

Create and Contribute a Pack

Packs have a defined structure that is prescribed by StackStorm. It is required to follow this structure while creating your own pack and is also helpful to know while debugging issues with packs.

# contents of a pack folder
actions/
rules/
sensors/
config.yaml
pack.yaml
requirements.txt

In the classic Proto-Hack fashion, let's just dive right in and build your first pack!

My first pack

If you would like to create a pack yourself then follow these simple steps. In the example below, we will create a simple pack named hello-st2. The full example is also available atst2/contrib/hello-st2.

First, let’s create the pack folder structure and related files. Let’s keep the metadata files such as pack.yaml, config.yaml, and requirements.txt empty for now.



# Use the name of the pack for the folder name.
mkdir hello-st2
cd hello-st2
mkdir actions
mkdir rules
mkdir sensors
touch pack.yaml
touch config.yaml
touch requirements.txt

How to continuously integrate, test and deploy

This post will walk through the steps of setting up a continuous integration server starting with a codebase from Github, automated by StackStorm.

Step 1: Deploy stackstorm on a server, following this guide.

• There are many ways to install/deploy stackstorm, I'll be using vagrant.
• I'm using my Windows based work computer to act as the server for this example, so vagrant is a great choice for getting things up and running.
• First things first, clone the project, cd to the vagrant folder within, and "vagrant up" to get started!

And we're off!

Whoops, looks like vagrant was updated since I cloned the project! Let's fix that...

Great success! It's installed!

This will install all StackStorm components along with the Mistral workflow engine on Ubuntu 14.04 virtual machine. The setup will download additional packages from the internet. While waiting, check out StackStorm 101 Video for quick intro. If setup is successful, you will see the following console output.

Step 2: Create a sensor to integrate with repository commits.

Step 3: Create a rule to merge all branches into the master branch.

Step 4: Create a rule to run all test cases, and if successful, deploy to production server.

event-driven automation architecture

Here's some original artwork by yours truly. 

Nothing much, just my take on event-driven automation architecture.

This is my personal take on modular orchestration, each node represents a partition or VM.

This bundling draws noticeably strong parallels to hypervisor technology because that's where orchestration (event-driven automation) was born.

Here's an example of setting up infrastructure for a project.

PHYSICAL INFRASTRUCTURE

• only 1 user? -> pick an architecture, install an operating system
• >= 2 users? -> pick an architecture, install a hypervisor, install additional operating systems 

VIRTUAL INFRASTRUCTURE

• only 1 role? -> pick an architecture, install a wizard
• >= 2 role? -> pick an architecture, install an emperor, install additional wizards

Seems simple enough!

How to build a custom relay

Relays are awesome little devices that allow small voltages to open and close a circuit, enabling a more powerful current to flow to it's destination.

The parts we'll need are...

• 1" x 1" proto-board
• 1k-1.5k ohm resistor
• red light emitting diode (LED)
• junction boxes
• small relay
• RCA jack
• solder

The tools we'll need are...

• soldering iron

CC Debugger

The CC Debugger is primarily used for Flash programming and debugging software running on CCxxxx
8051-based System-on-Chip (SoC) devices from Texas Instruments. The PC tools available for these
purposes are the SmartRF™ Flash Programmer from Texas Instruments and IAR Embedded
Workbench® for 8051 from IAR Systems.

When connected to the debugger, the SoC devices can be controlled directly from SmartRF™ Studio.
SmartRF Studio is also able to control supported CCxxxx RF transceivers (CC2520, CC2500, CC110x,
CC11xL, CC112x, CC120x) when they are connected to the debugger.

LeoPhi pH sensor

If you're seeking a complete pH, temperature, and humidity solution, look no further.

It seems Sparky has our backs, and has done a lot of the PCB work for us!

Easily interfacing with Arduino technology through multiple protocols, the LeoPhi is a great option for monitoring pH data in real-time.