2020-06-05
This is a beginner-level course on how to write SQL code to "talk" to a relational database system (e.g., MySQL, Oracle, Microsoft Access). I eventually get into showcasing a hands-on demonstration of creating SQL queries using Microsoft Access, which you can use this knowledge to also apply to more serious database systems like: MySQL, Oracle, PostgreSQL, Microsoft SQL Server, IBM Db2, and so forth. However, before I get to that portion, I initially explain some general concepts and I give a slide-based overview of how to write various SQL syntax.
2020-03-28
Learn the basics concepts of programming in Java! I will be going over a lot of content in an easy to understand fashion. Though, please know that this video lecture follows my other lecture on YouTube called: Orientation to Java Programming (IDEs, JDK vs. JRE, "Hello, World!"). So, you may want to start with the previous video first to get yourself up and running before trying to dive into Java coding.
2020-03-24
This is a somewhat advanced course on how to write SQL multi-table queries on relational databases (e.g., MySQL, Oracle, Microsoft Access) that essentially allows you to recombine your data tables back together to find useful information. If you are new to SQL, please watch my other video titled Basic SQL Queries before watching this lecture.
2020-03-22
Get your feet wet with programming in Java! I'd recommend starting with this video first before moving onto my next video lectures on the subject.
Git Choosy
2020-02-07
I have been playing around with creating a new Git codebase strategy which I call Git Choosy. It is designed to have the following features:
- Simple: As in it is less complicated than the Git Flow strategy.
- Flexible: Can be used by any Git-managed codebase project.
- Adaptable: Can be used to manage multiple forked codebases that have different agendas.
- Allows for time travel and parallel histories: It's like an unwanted commit never happened! Or... maybe later you decide that commit was fine but another one was the source of the headache. No problem! Let's get choosy and pick what we want!
- Aligns with standard Agile/Scrum and DevOps practices.
I plan to explain the details more thoroughly, but so far in my experiments the strategy works quite well. The basic premise is as such:
- Essentially, at the start of the sprint, the codebase is started from a set commit that serves as a baseline (B) for the rest of the sprint.
- Next, you branch from the baseline to create a sprint branch (S) which will grow/die as needed.
- Afterwards, each feature/bugfix/hotfix are simplified to what I refer to as ticket branches (T) to avoid worrying about the semantics of the differences between a user story vs. bugfix vs. hotfix and such, while still allowing you to categorize them how you want in something like Jira or Taiga. When a ticket branch (T) is ready to be committed, it merges into the current sprint branch (S).
- If all goes well at the end of the sprint, you can just simply merge the sprint branch (S) into the baseline (B), which then this will become the new baseline for the next sprint. Yet, if you decide that a particular ticket branch (T) is unwanted, such as T-123, then you can recreate a new sprint branch (S-2) from the original baseline (B) and rebuild S-2 with everything except T-123. Simple, right? Finally, when the latest, greatest sprint branch is ready, just merge that into the baseline.
