Sunday, December 29, 2019

Episode #14 – Wyze home automation hardware review


Last episode recap
  • In the last episode, we discuss artifact repositories and how they are useful tools that can be used in your devops/CICD to enhance your ability to provide value to your business customers…..faster.

Summary of this episode
  • In this episode, I will review the Wyze home automation components that I have purchased and installed. I will cover the pros, cons, and any gotchas that I have experienced with each item. I will also talk about the ordering process, order tracking, shipping, delivery, and customer service.

Episode Content

What’s in it for you?
  • After listening to this episode, you should have a better understanding of many of the Wyze products and the pros and cons of each as experienced by me.

Wyze products
  • Stationary Camera
    • pros
      • small
      • cheap
      • night vision
      • lightweight
      • wide angle
      • 180 degree flip if mounted upside down
      • micro sd card slot – I have a 120 gb card in all of mine
    • cons
      • inside only – there are outside mounts from 3rd party vendors but they might not be waterproof
      • can’t use night vision through a window
      • must have external power

  • Motion Sensors
    • pros
      • very small – a little bigger than a quarter
      • battery operated
    • cons
      • range of motion detection varies from location to location
      • range of detection depends on temperature and weather


  • Contact Sensors
    • pros
      • very small
      • battery operated
      • self stick tape provided
    • cons
      • angle of installation is very important – not unique to wyze
      • alert can be delayed a couple of minutes for some reason

  • Light Bulbs
    • pros
      • adjustable luminosity
      • dimmable
    • cons
      • only one style so far

  • Plugs
    • pros
      • can be controlled remotely
      • has a manual switch on the side of the plug
    • cons
      • bigger than some of the other plugs on the market

  • Automation bridge – allows the use of motion sensors, contact sensors, plugs and light bulbs.
    • pros
      • inserts into an existing camera
      • a single bridge can handle many devices.
      • Can have more than one bridge on your network.
    • cons
      • requires an existing camera to use
      • placement of the camera can cause dead spots in coverage as they communicate directly and apparently not over the WIFI connection.

Ordering
  • Ordering was easy from the wyze website and I paid with my PayPal account. You can also pay with the normal credit/debit card combos.
  • I have also ordered a couple of stand alone cameras from the Amazon website and it was easy start to finish as usual.

Shipping
  • Shipping was prompt once it was initiated.

Tracking
  • I had a problem with this as I could not get the order to show up in my order details on my Wyze account since I was not logged into the Wyze website when I placed my order.
  • I did get the initial “order received” email with the order number and information but even from the Wyze website I could not use it to find or track my order. Their support site talks about a page to track your order based on email address and order number but that actually only linked back to the account login page.

Delivery
  • Delivery was fast once it was processed through their systems. Once again, I can not give accurate time-frames since I could not track my order.
  • The package was surprisingly small. I had 2 cameras, 2 plugs, 1 automation pack (bridge, 1 motion sensor, 2 contact sensors), 4pk of contact sensors, 4pk of light bulbs. The box it all came in was smaller than 1 cubic foot.

Customer Service
  • Customer service was excellent but all they could tell me that the order was still in process. I chatted with a couple of agents and was told that I would get follow up emails from their systems once my order processed. Once again, I got no emails. Not the customer service agents fault…..but a little frustrating at the end of the day.


Recap of this episode
  • In this episode, we discussed the Wyze product suite of home automation that I have purchased as well as some of the pros and cons of each item.


Next Episode: The need for early testing in software delivery

Friday, December 27, 2019

Episode #13 - Artifact Repositories


Last episode recap
  • In the last episode, we discussed the Sarbanes-Oxley law and how it impacts publicly traded companies, what regulatory controls that have to be in place for a company, and what the impact is for non-compliance or fraud.

Summary of this episode
  • In this episode, we are going to discuss where you should store your compiled or “built” artifacts. These tools are referred to as binary repositories or artifact repositories. We will discuss the types of repos that you can create, what artifact types you can store and also the security features for each of the tools.

Episode Content

What’s in it for you?
  • After listening to this episode, my hope is that you will have a better understanding of what a binary repository is and what it is used for as well as some of the capabilities of 2 of the offerings in the industry.

What is a binary repository?
  • A binary repository is simply a place to store your compiled or “built” artifacts. Some people have in the past used shared network drives or a folder on their laptop. These are not optimal solutions since you can accidentally delete single items or the whole folder itself.

What can you put in it?
  • There is no limit to the items that can be uploaded to a binary repository. Simple rule of thumb, no un-compiled or un-packaged source code should be uploaded to a binary repo.

What are the types of repositories that you can use?
  • Release – release-able artifacts – ready for installation into an environment
  • snapshot – used for builds that are done on a set schedule (daily, hourly, etc.)
  • dependency – used to hold artifacts that your build will need to complete successfully but may not be readily available from another source.

What are the major binary repositories?
  • Sonatype Nexus
  • Jfrog Artifactory

What are remote proxies in a binary repository?
  • Remote proxies are typically sites hosted internally to your organization that points to an external site. This is usually done to enhance security to sites that you cannot verify that the content has been properly secured. Here are some examples:
  • Maven central
  • npm
  • docker hub
  • etc…


What security tools come with the binary repository?
  • Nexus Firewall – add-on product (has a cost)
  • Jfrog Xray – add-on product (has a cost)

What are some of the similarities of the 2 vendor tools?
  • The both allow you to upload various types of artifacts.
  • They both have download mechanisms for existing artifacts.
  • They both support release and snapshot repos.
  • They both can maintain a dependency repo for internal artifacts needed by builds.
  • They both support versioning and tagging of artifacts.

What are some of the differences?
  • They both store the artifacts in a different way
  • They both store metadata in a slightly different method.

What are the pro’s of each tool?
  • Nexus has a built in capability around Maven Central since that company maintains Maven Central itself.
  • In my experience, Jfrog Artifactory was the first to support all the different flavors of remote proxies, but both currently support the majority.

What are the con’s of each tool?
  • Confusing documentation on both parts. I have experienced random documentation updates in the middle of an installation that required that I re-do part of the work I had just completed.

Recap of this episode
  • In this episode, we discussed what binary repositories are, what you can store in them, what the similarities are between the products, and some of the differences.


Next Episode: Wyze home automation hardware review

Monday, December 23, 2019

Episode #12 - Ball and Chain of Custody - Legal Requirements



Last Episode recap
  • In the last episode we discussed Jenkins. We talked about what it is, what it is not and how it can be configured to use in your automation efforts.

Summary of this episode
  • I hope you have seen that I’m trying to do these episodes in what I think is a very specific order. We will build on each episode so that you understand how each topic discussed can be used to enhance your automation effort.
  • In this episode, we will discuss maintaining a software “chain of custody”, why it is important, what happens if you don’t and how your automation can help you do it.

What's in it for you
  • A better understanding of the importance of maintaining good software controls and how it keeps you and your company out of trouble.

Episode Content:
  • Why does it matter?
    • In 2001, a large corporation named Enron was embroiled in a controversy involving its financial records. It was followed by other controversies with other large publicly traded corporations.
    • In July of 2002, two U.S. Congressmen, Sen. Paul S. Sarbanes and Sen. Michael G. Oxley, sponsored a bill to rein in the fraudulent financial reporting that led to these massive corruption scandals. This bill was titled the Sarbanes-Oxley Corporate Responsibility Act of 2002 (or SOX for short).
    • The bill tightened controls around how a company recorded and reported its financial Information.
    • One of its goals was to provide for structured, consistent and repeatable controls.
    • It was created as a way to for the leaders and employees of a company to create and maintain a culture of corporate financial responsibility.
    • It provided for the officers of a company to “sign” their financial statements. This means that they take personal responsibility that they are accurate and correct with no malfeasance or attempts at fraud against investors.
    • It increased the fines and sentences for individuals that attempt to commit fraud or illegal financial practices.
    • It requires a company to document its internal control processes.
    • It requires a company to to have an external auditor to certify that their internal control processes are being followed and that the financials are accurate.
    • It dictates that all off-balance sheet transactions must be reported.
    • It provides the Security and Exchange Commission more power to perform investigate any company suspected of violations.

  • Who has to comply?
    • All publicly traded companies
    • All subsidiaries of foreign companies in the U.S.
    • All private companies that are preparing for an IPO
  • Fines and Prison Time
    • Non-compliance could result in fines up to $1 million dollars and up to 10 years in jail
    • If a company intentionally defrauds investors, it could result in $5 million dollars in fines and up to 20 years in jail.

  • When should you worry about it?
    • You shouldn’t worry about it too much but,
    • You should make sure that your control processes are well documented, your staff understands why they are in place, and any consequences that they or the company might face if they do not follow the controls.
  • Where should they be implemented in your SDLC?
    • In my opinion, every step of the SDLC, for example:
      • Requirements – should be documented and changes should be tracked.
      • Development – All source code should be in an SCM system so that any changes can be tracked back to why and who made the change.
      • Build – All builds should be documented and all artifacts of the build process should be stored and versioned.
      • Testing – all test cases that are used to verify requirement functionality should be documented and any results of those test cases related to a specific build should be tagged with the build ID and archived after completion.
      • Environments – All changes to an environment used for a specific build should be tagged and documented for approval prior to implementation.
      • Deploy – The reason for the deployment, date and time, and approval should all be documented.
      • Promotion to a higher environment – all approvals should be documented and tracked for each environment promotion.


  • How can your automation help you with all this documentation?
    • By using some or all of the tools that we are discussing, you can have a lot of this documentation done for you automatically by your automation.
    • For Example:
      • Requirements: Jira, Quality Center
      • Development: Github, Bitbucket, SVN, Team Foundation Server
      • Build: Maven, Gradle, Jenkins, CI/CD pipelines
      • Testing: qTest, Quality Center, Bugzilla
      • Environments: CI/CD, Jira
      • Deploy: CI/CD, Jenkins, Ansible, Terraform
      • Promotion: Jira, Remedy, ServiceNow

  • Each of these tools will automatically record the changes that you make, builds that run, tests that are performed, and artifacts that are deployed.
  • Using Jenkins or a similar tool, you can create a pipeline or job that can automatically create the files required by your audit partners to run their reviews.
  • Usually the only changes to be reviewed after automation are any changes that are made to the automation pipeline/jobs themselves.
  • Working with internal and external auditors can be a daunting task since they are trained to ask many probing questions to identify problems with your process.
  • Using automation makes their and your job easier when it is time to perform these control reviews, which is usually monthly, quarterly, semi-annually or annually.

recap of this episode
  • In this episode we discussed what software chain of custody is, why it is important, where it originated, how it is controlled, and how your automation can assist you in financial reporting compliance audits.


Next Episode: Artifact repositories



Thursday, December 19, 2019

Episode #11 - Tools - Jenkins - Not your everyday butler



Last Episode recap
  • In the last episode, we discussed CI/CD and related build topics.  We talked about what good CI should look like and what components make up that CI.  We talked about CD and how that is typically done and also dis-jointed or dis-associated CI and CD.

Summary of this episode
  • In this episode, we are going to discuss Jenkins and how it can be used in your automation.

What's in it for you
  • Once you listen to this episode you should have a better understanding of what Jenkins is and how it can be used, the types of tasks that can be automated, and some of the items that can be configured (plugins) to enable automation.

Jenkins description
  • what is it
    • Jenkins is an automation platform that can perform a variety of tasks to enable your automation.  It can be used to run your CI/CD  pipelines integration your SCM to your automation all the way to your production environment.
  • what's it used for
    • build jobs
    • testing jobs
    • deployment jobs
    • reporting jobs
    • auditing jobs
    • monitoring jobs
  • good use cases
  • types of jobs
    • freestyle
    • pipelines
    • multi-branch pipeline
  • plugins
    • examples:  folders, pipelines ( many different plugins ), git, ansible, artifactory, azure app service, credentials, docker, generic webhook, groovy, mask passwords, nexus artifact uploader, SSH plugin, and many more.
    • when are they useful and when should you use them
      • usually when a vendor has an integration plugin and you can’t put it into your pipeline as code
      • or when it is a very specialized piece of functionality that you cannot easily code
    • when should you not use them
      • when you can easily code the functionality in your pipeline code (ssh to another server perform a task)
  • agent nodes
    • accessing agent nodes
    • ssh creds
  • folder security
    • matrix based security
    • LDAP security
  • Integrations
    • SCM
    • others

recap of this episode
  • Description
  • Use cases
  • Job types
  • Plugins
  • Agent Nodes
  • Security
  • Integrations



Tuesday, December 17, 2019

Bonus Episode #1 - 10 Episodes in and still going

They say that the hardest thing about a podcast is getting through the first 10 episodes without giving up.  Well, I made it.  I would like to thank everyone that has taken the time to listen and provide feedback.  And I will say Thank you to all those that listen to my podcast in the future as well.

I would like to take a couple of minutes to summarize some of the things that I have had to do and learn to get this going.

So here goes:
- Here are the things that I have learned by putting together this podcast.

- No matter how educated you think you are there is always something left for you to learn.

- Take broadcasting for example.  I had to learn recording, hardware choices, sound quality, audio editing, marketing and advertising, and pretty much how to speak.

- If you have never recorded yourself and then listened to your voice on playback, try it.  Record at least 5 minutes of yourself talking and then when you listen to the playback you will be amazed at how many so's, and's and um's that you don't realize that you are saying.  I take some of those out in post-edit.....but not all of them.

- I learned all about Audacity, the open source recording and editing software.  I know about half of the features and probably could benefit from about half of those that are left.

- I learned about marketing.  Social media channels, Search Engine Optimization, and how to generate feedback.

So, once again thanks for tuning in and not tuning out.


Next Episode:  Jenkins - Not your everyday butler!

Sunday, December 15, 2019

Bonus Link #1 - Slack Channel for Scott Talks Tech podcast

Check out my new slack channel for the Scott Talks Tech podcast:

Scott Talks Tech on Slack

Episode #10 - CICD Basics - Continuous Integration - Continuous Delivery

In this episode, I cover the basics of what CI/CD is and how it can be implemented.  Hopefully, once we are done you will have a greater understanding of CICD and how it can be implemented in your company.

Description of CICD - It is the process of automatically building and deploying your application when a commit is made by a developer.

Process
- Requirements definition with business partners.
- Jira ticket entry.
- Code Modification and commit to SCM.
- Webhook fires to start the CI/CD process.
- The software is checked out of SCM by your build tool.
- The software is tested, compiled and packaged.
- The software is uploaded to a binary repository.
- The software is moved/copied to a target environment.
- The software is installed in target environment.
- Automated regression tests are run on the target environment.
- The software is promoted to the next environment.
- The promotion and test phases are repeated until the software is running in the production environment.

How i've done it

Some tools that enable it
- BitBucket/GitHub/SCM of your choice
- Automated build tools
- Automated unit tests
- Jenkins

dis-jointed or dis-associated CI and CD
- CI is done and once a build is completed and your artifact is in your artifact repository of choice, then the CI ends. 
- Another tool like Spinnaker is set up to poll your artifact repository and will pick up the artifact and deploy it to the appropriate testing environment.


Next Episode:  Jenkins - Not your everyday butler!

Thursday, December 12, 2019

Episode #9 - Tools - BitBucket vs GitHub

BitBucket is Atlassian's offering that encapsulates Git.  They have an entire suite of products that enable end-to-end collaboration.

It has a lot of the same features as GitHUb:
-----------------------------------------------
- It is built on top of Git.
- It is used for source code mgmt.
- It has pull requests to facilitate code reviews.
- It has branching and merging.
- It has forking.
- It has webhooks.

But it also has other features as well:
---------------------------------------
- It is directly integrated with Atlassian's other tools (Jira (task tracking), Confluence (Collaboration), Crowd (LDAP)).
- It provides a tighter structure to its repositories.
- It provides tighter security through it's integration with Crowd.
- It facilitates collaboration through its integration with Jira and Confluence.
- It provides end-to-end tracking when a branch is created from a Jira ticket.

Pros:
-----
- It can be hosted in Atlassian's cloud environment or it can be on-prem at your company.
- It has a high availability Data Center version.
- It has unlimited repositories for free for up to 5 users.
- Is is supposed to have better searching but we have found it lacking in regards to wildcard searches.
- You can import your code from more SCM systems than GitHub.
- Powerful Jira integration can update Jira ticket status on BitBucket commit.
- Offers in-line comments directly in the code review window.
- Integrates directly with Trello.
- Integrates with Slack.
- Better pricing (GitHub private repos can be pricey).
- Powerful ACL thanks to integration with Crowd (think LDAP server with groups).

Cons:
-----
- Smaller community
- Fewer plugins
- Wildcard searches

My Take:
------------
Using the Atlassian suite enables you to have end-to-end tracking of source code changes that starts with the entry of the requirement into a Jira ticket.

Next episode:  CI/CD Basics

Tuesday, December 10, 2019

Episode #8 - Interim - Target Audience

A brief discussion about who my target is, what I can provide to them, how they can benefit from it, and a funny story about education.

Monday, December 9, 2019

Episode #7 - Tools - Github

Description of GitHub
- hosted platform for managing your source code from creation/ideation to production
- built-in actions and workflows to control your code build and deploys while not leaving GitHub's platform.

GitHub Project Structure
- It can be as varied as the languages that you can code in.

readme files
- how to tell the world about your GitHub project
- uses markdown for formatting

Pros/Cons of using GitHub
- Easy access for anyone with an internet connection
- Built-in process to enhance automation
- Its in the cloud....always a risk
- Only as good as what you put into it
- Concerns about Intellectual Property
- Concerns about security tokens, passwords, IDs, SSH keys, etc.

Workflows
- automate tasks directly in GitHub

Webhooks
- Used to drive automation tasks with other systems (or within GitHub itself)

GitHub Pages
- a website for your project....done right from your GitHub repo
- can use a custom domain name that you own

Integrations
- Integrates with almost any tool via Webhooks
- GitHUb has developed a lot of their own offerings around certain technologies

Code Review
- It all starts with a pull request
- diffs, history, blame
- embedded chat
- conflict resolution
- Integrations with other code review tools

GitHub Actions (or features/workflows)
- automation workflows built into GitHub
- run on any event
- hosted runners for most major OS flavors
- parallel builds for different OS or browser combination
- supports many languages
- users can build their own runners
- live logging for real-time build debugging
- built in secrets management

GitHub Products
- Atom - IDE
- Electron - Open source cross platform development with javascript, html, and css
- GitHub LFS - Large file storage offering
- IDE Plugins
- Mobile App
- GitHub Marketplace
- GitHub Security Lab

Git Merge Conference in March 2020 - Sponsored by GitHub

Coming up next - A look at BitBucket - Atlassian's Git offering.

Friday, December 6, 2019

Episode #6 - Tools - Git from Asheville-NC

Episode #6 - Tools - Git from Asheville-NC
--------------------------------------------------------------

Where I am podcasting from - Asheville, NC

Target Audience - Technology resources that are new to development or to this tool in particular

SCM description

Git description

Git terminology
-init - Create a new repository (from empty dir or existing source folders).

-config - Set the user.name and user.email config settings for the current user.

-origin - This indicates the starting point of the current branch.

-remote - This indicates where the push command will try to send your changes on the remote system.

-branch - This is an isolated work area for you to make your changes.

-types of branches - master, develop, development, feature, release, hotfix.

-checkout - This is the act of copying the selected branch to a working area where you can make your changes.

-local branch - A branch that is created on your local machine from the remote source.  It can be a new branch created locally that you will then commit and push to the remote.

-status - This command shows the current status of any files in your local workspace that have been modified, staged for commit, ready to push to the remote.....or any errors.

-add - This command readies your modified files to commit.  It is typically used when you create new un-committed files that are not currentlyin git.

-commit - This is the act of telling git that you want to copy your modified files to the branch on your local machine that you have checked out.  You will still need to issue a push command to send the changes to the branch on the remote server.

-commit message - always add a descriptive message of what changes were made and why.  It is useful to put any reference ticket number from your issue tracking system in the commit message.

-merge - This is the act of combining two branches that have different sets of code.  It is done automatically if there are no conflicts.

-merge conflict - This occurs when the same file is modified by two or more developers and their changes involve the same lines of code in the files.

-diff - This is a utility that can be used from the command line to compare two files to display the conflicting differences.

-pull requests - The act of having another developer or team lead review your changes before it is merged into another branch.

-push - This command will copy our changes from your local branch to the remote branch as long as there are no conflicts.  This conflict check can be over-ridden with a command flag.

-pull - This is the command that will pull all the up-to-date information from git regarding your source code respository (branches, tags, etc.)

-clone - This is the act of copying a remote repositort to another workspace where you can make your modifications in isolation from other developers.

-fork - This command allows you to create a copy of a repository that you will not be merging back into the remote for some time (or in certain cases, not at all).

-tags - This is a command line utility that allows you to mark certain sets of files with an identifying tag (numeric, alpha-numeric, or alphabetic).

-branching methodology - This is the decision made by your team on how you will handle parallel development that will involve merging your code from branch to branch before you finally promote it to production (master).

-gitFlow - A commonly used branching methodology.

-log - This command line utility can be used to view changes to a file or set of files.

-revert - This command is used to undo a commit.

-reset - This command is used when you wish to discard all your local changes and revert back to the latest on the remote server. It is not recommended if you follow your branching methodology.

Tuesday, December 3, 2019

Episode #5 - Build Tech and Value Stream

Episode 5 - Build Tech and Value Stream
---------------------------------------
So you have your code, what do you do with it?
- Bad idea - keep it on your laptop or a network drive

What SCM tool do you use to store your source code?
- SCM - Software Configuration Management
- Also called version control
- It's where you put your code so that nothing bad happens to it (like being deleted).

What build tool you use will depend on the platform and language that you are writing your code in.
- Java, .net, C++, C#, nodeJS, etc.
- Linux, AIX, Solaris, Windows, Docker, Mainframe, etc.

First you will need to understand your build process.
- Automation enables your process to go faster and smoother but it does not replace the process.
- You need to sit down and document the entire process from Requirements definition to having an artifact that can be installed into an environment.
- Value Stream Mapping
-example:
- Document the requirement (including acceptance criteria).
- Check out code (if existing).
- Modify code to meet the acceptance requirements as written in the requirement.
- Check in / Commit your code to your SCM system.
- Update and parameter or config files as needed.
- Run automated/manual unit tests (this will be another podcast).
- Run your packaging utility (this will depend on the language that you are writing your code in).
- Ant, Maven, Gradle, Make, etc.
- Upload Artifact to server (host).
This step will be replaced when automation is written.  The artifact will be uploaded to an artifact repository (binary repository).
- Install artifact into testing environment on this host.

Sunday, December 1, 2019

Episode #4 - Podcast with a question

Hi all,

 Thanks for checking out this episode of Scott Talks Tech.

I need to find a way to record remote interview sessions with multiple tracks. This will allow me to normalize the volume levels so that the conversation sounds natural.

Here is my setup and what I have tried so far:

Linux Laptop - PopOS 18.04 (Ubuntu based)
Blue Yeti Microphone
SkypeForLinux installed
Open Broadcast Studio installed
Audacity installed

 I have tried to use all the tips and tricks from google and youTube to get this to work but the only thing I have accomplished is to raise my frustration level and record my audio and skype to a single track.

 I was trying to not spend a bunch of money on an external audio recorder but that may be the best option with a Linux laptop. I did find a review on youTube today for Zencastr, so I'm going to check that out tonight.

 Thanks for checking this out, Scott

24 – Tools - Docker

     Date: 6/8/2020 Guests: None Welcome and greetings Recap of last episode In our last episode we contrasted a few different container man...