Showing posts with label self-help. Show all posts
Showing posts with label self-help. Show all posts

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.

Friday, November 29, 2019

Episode #3 - Why am I doing this and How

  1. Main Reason is Self-Improvement
    1. If you teach something to someone, you get better at that thing yourself.
  2. It is also a form of continuous learning and keeping your knowledge up to date.
  3. What I have learned:
    1. It is form of broadcasting which means that there is work involved in getting each episode published.
    2. Each episode consists of recording, post-edit, and publishing.
    3. I bought a desktop microphone and have a hand-held coming on Monday.
    4. I use Audacity, free software, for editing and combining all the tracks for the episode.
      1. Noise reduction.
      2. Normalization
      3. Apply Equalizers
      4. Clip out bad segments
    5. I use Buzzsprout for my publishing platform.  It will send the rss feed out to the major directories.
    6. I use Blogger for my show notes for each episode (you are looking at one of them now).
    7. Advertising:  Facebook, LinkedIn, Twitter, etc.
    8. Legal Considerations:  Artwork, music (full or clips), royalties, voiceovers, commercial use licenses.
  4. I mean to start with short episodes and get longer when the content merits the time (5-20 minutes).
  5. I will have longer episodes when I have guests (30-45 minutes).

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...