#Create new git repo
At the same level as manage.py
#Create Heroku account
Go to http://heroku.com and get a free account.
#Install Heroku Toolbelt
| Add code examples to each of this. Add more questions with things you are stuck on with code examples. | |
| Add examples only when you don't remember or get stuck on how to do something. This is a cheat sheet. | |
| #Variables: | |
| What is a variable? | |
| What is the difference between a variable and a string? |
| wget https://bootstrap.pypa.io/get-pip.py | |
| if you don't have wget | |
| curl https://bootstrap.pypa.io/get-pip.py > get-pip.py | |
| sudo python get-pip.py |
| https://github.com/new | |
| - Create Public Resources | |
| Using ssh | |
| https://help.github.com/articles/generating-ssh-keys/ |
#Create new git repo
At the same level as manage.py
#Create Heroku account
Go to http://heroku.com and get a free account.
#Install Heroku Toolbelt
| Using | |
| import sqlite3 | |
| Open a database | |
| filename = "test.sqlite" | |
| conn = sqlite3.connect(filename) | |
| Create Table |
| Blog Create Form: | |
| We are going to create a html form that accepts data from the user and creates a new blog entry/model. | |
| When a user enters a url in Chrome like /blog, Chrome sends a request to the server for that url with the HTTP verb or action | |
| of GET. | |
| The http request will look like this | |
| GET /blog .... |
| #Create a new directory | |
| mkdir test | |
| #cd into that new directory | |
| cd test | |
| #look for all files including hidden | |
| ls -la |
I bought this deck of cards from a company called Unstuck Box. Each card has a mental model like Pareto Principle, Hanklons's razor, etc. When you are stuck on a problem you can grab a card randomly and try to apply that model to the problem.
Had the idea to apply that to tech problems.
Ultimately the way to get unstuck is to get more data to build a better mental model of the problem.
There are times when working on critical or complex systems where issues manifest but it is difficult to pin down the source.
A set of code may write data and succeed with no issues but then another pieces comes along to read and finds that the data is wrong or incompatible. That is not horrific but when there are several actors it can be difficult to test all those scenerios and when things go south figure out which part introduced the issue.
Functional tests can help but with complex system it is impossible to create test cases for all scenerios.
The ultimate goal of debugging is to try and find the truth of the situation. Something is off. You expect the code or system to do x and it is off doing y. As we deploy code in different environments, running at crazy scale, or running distributed you can't always step through the code in a debugger or reproduce perfectly but you still need to be able to make progress.
At the end of the day there is code running somewhere in some order. Your goal is to figure out what is actually running. In a perfect universe you could pause and step through all the code running on every cpu in the system until then we are trying to get as close as possible to that level of understanding.
Obvisouly if you can run something locally and step through it in a debugger you should but for many systems this is not possible.