Some back story and Care Plans

The Short Backstory…

from DOS to (An)Droid

I’ve been plugging away at computers since Microsoft introduced MS-DOS.  During the DOS days I worked through technologies supporting Novell networks and Paradox Databases.  Along the way,  Windows 3.11 came on the scene and killed Paradox.  Paradox for Windows was very slow.  MS-Access had matured enough.  Made the switch.

 

Software and coffee…

A new gig with a crazy programmer from Quebec.  I learned that F***-All was a useful expression when dealing with ObjectStar, especially after several Quad Espressos.

Thankfully the gig was translating ObjectStar into DTS packages.  The transition to Microsoft Server, SQL Server and DTS was a marked improvement and called for more Espressos.

After Y2K,

I thought my COBOL days were done and I could focus on moving MS Access databases to SQL, along with VB and VBA. When the choice to move to .NET presented itself, VB was traded in for C#, HTML and JavaScript.

 

DOT.Bust happened.

Alcatel decided they didn’t need any more fiber optic cable from Oregon.  Great job, great boss then dotcom went bust.

The core of the job  was a deep dive into performance enhancing large stored procedures handling large amounts of data.  Submerging fiber optic cables required mapping the construction of the cable.

The make up, where the outer armor changed or splices occurred had to be precisely recorded.  This data was generated by several machines within the assembly line.  The records had to be accurate.

The data was imported into several SQL databases through DTS packages.  The data had to be processed and staged into the reporting database.  While not quite a data warehouse, it was about 3/4s of the way there.

If an error occurred in the circuit, the ship going out to repair it needed the accurate information.

Most of the improvements, code wise, came from reducing and de-cursor-fying lengthy stored procedures.  The procedures tended to fill the transaction log.  The enhancement improved performance and transaction log management.

DB2 to Data warehouse in three(easy?) steps

The dot-com bust, left the employment landscape fairly barren for new web technology.  COBOL came back.

The web was dead, long live the web

Business stopped focusing on the web front and some looked to modernizing their DB2 data into SQL databases.  While the web market may have taken a hit, the supporting technologies were being deployed and data warehouse technology was rapidly improving.

A medical company needed to convert COBOL reports against DB2 to Crystal Reports and SQL Server.  It involved ETL from DB2 to SQL, stored procedure development and designing Crystal Reports with in-line SQL

COBOL formed the bridge into building a prototype data warehouse using the “new” Microsoft server technologies, SSRS, SSIS and SSAS for the Oregon Department of Transportation.

Who would have guessed that using Lotus123 to generate business reports lead to a data warehouse.  Along the journey, the need to understand and use web technology increased.  Most of the projects had a web application component.  The new frameworks and responsive design have made the web interface more flexible than ever.  The border between application and website has blurred considerably.  More components…more devices.

The Web of Devices

The smart phone has brought both the web and instant communication to a huge audience.  For many, the only access to the web they have is through their phone or tablet.  This landscape continues to grow.   Your smart watch records your biometrics which talk to your phone.  Your phone then talks to the “application” in the cloud.  From work, you log into the secure web site.

Technology continues to change rapidly…

Perhaps your site uses a widget that allows the site to gather user data.  Besides needing to look good on a phone or a monitor, it includes external code.  Managing websites means looking after all the parts and pieces.  Technology continues to change rapidly.  This pace also drives the pace of updates to the components that make up your site.

That requires a care plan…

What better way to go through a care plan than to take a basic site and add all the pieces that create a solid framework to support your site.  A large portion of Websites are powered by WordPress.  That was the choice for this site.

Setting up the site

Behind the scenes, this site is a WordPress installation hosted on Godaddy.com.  The following focuses on the individual site management.  WordPress sites are comprised of retail and custom themes.  Each theme can employ any number of widgets.  The point is, all of these “parts” need to be maintained and backed up.

Step One – Create and update(repeat weekly)

WordPress publishes updates frequently.  The following link provides the latest  WordPress notifications of releases.

This screen will be visited a lot throughout the life of a site.  Staying current keeps your site more secure.

Next…Plugins

Plugins add features.  That is one of the attractions of choosing a framework like WordPress.  The selected theme came with plugins already attached and set to inactive.

After reviewing each, the initial choice was:

Anti-Spam was a given.  Hello Dolly needs more review and limiting login attempts is a step towards hardening the site.

Because there are only a few plugins so far, you get two “Apply” buttons.  Both do the same thing but convenient when the list gets long.

Once the plugins have been applied, they need to be set up.  These steps will also become part of the Care Plan.  Each plugin may have additional requirements or provide important information that needs to be reviewed.

This installs plugin code into your site.  This code will need to be updated on a regular basis.  How often?  We’ll find out.

Once installed, you are issued an API key.  This is a key that is a secret key for your site.  Anytime you are presented with credentials, even if it is for a service you may only log into once, I have found it best practices to store a copy of the credentials in a secure credential store that is backed up.  There are many products that provide this.  I use KeePass2.

I set up a folder to hold the entries for the site.  Now that I have the API key, I set up a new entry to hold the key.

1. The Title – clearly identify the service
2. User Name – use it to further identify the service
3. Password – store

   

   the passkey from the Akismet site:

4. Click on Show on the Password field, paste the new API Key and save the entry.
5. Using the API key, log into Akismet and update your settings.

   

    

   More plugins and settings to come. In Part II.