Monday
Snap challenge – create a basic class.
Planning Poker & Asana discussion to get us started with our teams.
A field trip to gather data for our project.
Tuesday
We started talking about basic css. Most of my brilliant insights for that ended up incorporated in the styles sheet for this site rather than my notes. (The brilliant part is a joke.)
Also had a talk from somebody from a local software company called RSI. This sounds like an interesting company that I probably need to learn more about.
Wednesday
Snap Challenge – git flow
The snap challenge was to describe and list the 5 types of git branches in git flow. The second part was to create a patch file and apply it.
The five branch types in git flow
The master branch – production
The master branch is the official version of working code that is currently distributed or ready for immediate distribution. It should be stable and well-tested.
The dev branch
The dev branch is where changes and new features go after their development is complete. It incorporates all fixes and new changes that are being staged to go to the next update to master (via a release branch of course!).
Release branch
The release branch is a place for code that is almost ready to be released. It is made by getting the most recent code from Master and merging the dev branch. Testing occurs before it is merged back into master.
Feature branches
Feature branches are the place to actually develop new features and add functionality. They start by branching from the dev branch and then working from there. Once a feature is ready it is then merged back in with dev.
Hotfix branches
Hotfix branches are made to fix mission-critical bugs in master. They branch from master, fix the bug, go through testing and then merge back into master. These should only be used under extreme circumstances.
The life of a ticket
- The code from one ticket will start out with a branch from the dev branch.
- The code for it will have several commits along the way.
- If there are changes to dev along the way, it may be merged with the feature branch several times during development of the feature.
- When the feature is ready, the dev branch will be merged with the feature branch.
- After solving any merge problems, the feature branch is then merged into the dev branch.
- When it is time for a new release, the dev branch will be merged into the release branch.
- Once the release version has passed testing, it will be merged into master.
Git Patches
Git patches were an interesting thing to learn about as part of the snap challenge. They allow one to take one commit from a remote source (an email snippet of code from someone) or a branch with other commits you don’t want and apply that one patch to your branch.
This can also be used to manage features in releases and allow one to create a feature they can add back to a project whenever they want. For example, if a person wanted to add a feature to an open source package just for their own use or the use of their company, a patch file would let them add that change to every new released version.
Thursday
Debugging Code- soft skills
Zoom out and look at the big picture
Look for other ways to accomplish the same thing
Look at pre-conditions and post-conditions
Rubber Duck
Comes from a guy who had a rubber duck on his desk and would explain his problems to his duck when he had coding issues.
It helps to just talk things through. And you might see something new when you go to explain it.
Step away
Get a drink. Take a walk. Take a break. Get some sleep. Look at it again in the morning.
The big picture
Nobody is going to die if we have a bug in our software. (Unless you’re working on a self-driving car, or software for a hospital, or the military.)
But mostly we just have to keep perspective. Life is good.
Move on
Is this really a priority? Is it time to move on and work on something else?
Get someone else to look it over
Technical skills
Comment out code to see how it runs without it
Comment every single line to explain what it does
Forces you to trace through everything and put things in context. Plus it means you have good comments for later.
Copy code somewhere else and rewrite it
It’s easy to miss typos if you’re looking at code for too long. Sometimes just retyping helps, but it’s easy to include the same typos if you’re still looking at the original.
Test little chunks of code outside of the application to make sure it is doing what you expect.
Console log/print to screen
Use lots of console logs to track what is going on, what functions the program has called, values of variables, etc.
PHP: var_dump Dumps information about an object
(DON’T leave this in your code)
Google the error in whole or in part
Look @ the line number
Look at PHPStorm suggestions
xdebug
An extension for PHP to assist with debugging & development. Overkill for our class, but good to know about.
Makes it so you can put breakpoints and step through code line by line.
Browser Dev tools
Console
This is where console.log output goes. Plus displays errors.
Network
This shows all network calls.
Elements
Let’s you see all elements on the code & you can play with css & formatting.