D1W1

Policies and Rules

Only 3 days of absence allowed for the entire duration of the program.

  • No well-actually’s
  • No feigned surprise
  • No backseat driving
  • No subtle -isms

The social rules are: (Courtesy of Recurse Center)

Pesto is dedicated to providing a harassment-free learning environment and community for everyone, regardless of gender, sexual orientation, disability, physical appearance, body size, race, religion, or anything else. We do not tolerate harassment in any form.

No well-actually’s

Alice: I just installed Linux on my computer!
Bob: It’s actually called GNU/Linux.

Defn: A well-actually is when you correct someone about something that’s not relevant to the conversation or tangential to what they’re trying to say.

The best rule of thumb is, if you’re not sure whether something needs to be said right now, hold off and see what happens.

No feigning surprise

Dan: What’s the command line?
Carol: Wait, you’ve never used the command line?

Defn: Feigned surprise is when you act surprised when someone doesn’t know something.

A good rule of thumb is that always know that you cannot know the entirety of a subject. Also, there are people from other educational backgrounds studying Programming. Hence, they may not know all the jargon.

No backseat driving

Bob: What’s the name of the string copy function?
Alice: Strncpy.
Eve: (from across the room) You should use strlcpy. It’s safer.

Defn: Backseat driving is when you lob advice from across the room without joining a conversation. Because you haven’t been participating in the conversation, it’s easy to miss something important and give advice that’s not actually helpful.

Even if your advice is correct, it’s rude to bust into a conversation without asking.

If you overhear a conversation where you could be helpful, the best thing to do is to ask to join.

No subtle -isms

Carol: Windows is hard to use.
Bob: No way. Windows is so easy to use that even my mom can use it.

Defn: Subtle -isms are subtle expressions of racism, sexism, ageism, homophobia, transphobia and other kinds of bias and prejudice.

If you see racism, sexism, etc. outside of Pesto, please don’t bring it in. For example, please don’t start a discussion about the latest offensive comment from Random Tech Person Y.

The Learning Phase

The Learning Phase is the first phase of the Pesto Program. It is intended to give you a theoretical understanding of technologies that we are going to work with for the next 12 weeks

The working hours will be divided into two segments.

  • The working hours will begin from 12 PM to 9 PM. There will be 9 hours in total.
  • 5 days learning per week
  • Monday to Friday
  • Each segment will consist of a lecture module followed by an exercise module. The exercises in Segment 2 needs to be done via Pair Programming.
  • The Candidates will be randomly called in 'Office Hours' to explain the programs that they have done.

Note

  • The Major Assessment will be on Monday of Week 3.
  • The pre-lunch schedule is as follows -
  • 9:00 - 9:45 (Soft Skills)
  • 9:45 - 12:45 (3 hours) (Assessment + Feedback + Reflection)
  • Each Major Assessment of a candidate will consist of video-based dialogue of the study materials previously discussed. The duration should be between 15-20 mins.
  • The candidate can expect theoretical and coding-based questions, including but not limited to, JavaScript, Web Development and Computer Science.
  • The Candidate should speak only in English.

Major Assessment

Weekly Projects

  • The project will be disseminated every Monday.
  • You need to present the project on the immediate next Monday.
  • The duration of the presentation will be 2 minutes. Two extra minutes will be given for questions regarding the technologies/techniques used, if any.
  • You can make a video or slide for assistance in the presentation.

This Week's Project

Your Portfolio

  • One team project (aka Major Project in the Second Month)
  • 3-4 small/medium weekly projects. These projects will culminate into your portfolio site.
  • One Loom instruction video. [Sample] 
  • One research paper summary published as an article on Medium in public domain. [Example]
  • Open source apprenticeships
    • Contributions
    • Peer Reviews
  • One medium post reflecting your journey in the Pesto Career Accelerator Program. (Optional but highly recommended)
  • What more can you do?

Sample Portfolios

  • http://dejan.works/
  • https://jacekjeznach.com/
  • http://mattfarley.ca/
  • http://ejosue.com/
  • https://caferati.me/

The Concept of Knowledge

Knowledge is a familiarity, awareness, or understanding of someone or something, such as facts, information, descriptions, or skills, which is acquired through experience or education by perceiving, discovering, or learning.

  • "What makes justified beliefs justified?"
  • "What does it mean to say that we know something?"
  • and fundamentally "How do we know that we know?"

Epistemology addresses such questions as:

A thing about questions

First Task

  • VSCode (Editor) [Include it in path]

  • For macOS

    • iTerm2

  • For Linux (Ubuntu)

    • Terminator or current shell

  • curl (cli http)

  • nvm (node version manager)

  • node using nvm

  • npx

  • yarn

  • git, if not available

Install these software

Link

Common Shell Commands

ls
ls -alF

Lists files in current directory
List in long format

mkdir graphics

Make a directory called graphics

cd tempdir
cd ..
cd ~pesto/web

Change directory to tempdir
Move back one directory
Move into pesto's web directory

rmdir emptydir

Remove directory (must be empty)

rm file1.bak 

Remove or delete file

clear

clear the terminal

man ls

Manual (help) about command

grep <str><files>

grep "bad word" *

Find which files contain a certain word

chmod <opt> <file>

chmod 644 *.html
chmod 755 file.exe

Change file permissions read only
Change file permissions to executable

ps <opt>

ps aux
ps aux   |   grep abc

List all running processes by #ID
List process #ID's running by abc

kill <opt> <ID>

kill -9 8453

Kill process with ID #8453

find

find -iname "MyCProgram.c"

find ~ -empty

Find files using file-name ( case in-sensitve find)

Find all empty files in home directory

pwd

pwd

tells you where you currently are

lsof

lsof -i :8000

list open files

Signals

Signals are software interrupts.

Signals provide a way of handling asynchronous events—for example, a user at a terminal typing the interrupt key to stop a program or the next program in a pipeline terminating prematurely.

These names all begin with the three characters SIG.

  • The terminal-generated signals occur when users press certain terminal keys.
  • Hardware exceptions generate signals: divide by 0, invalid memory reference, and the like.
  • Software conditions can generate signals when a process should be notified of various events.

Numerous conditions can generate a signal:

Disposition of the signal, or the action associated with a signal.

  • Ignore the signal. This works for most signals, but two signals can never be ignored: SIGKILL and SIGSTOP.
  • Catch the signal. To do this, we tell the kernel to call a function of ours whenever the signal occurs. In our function, we can do whatever we want to handle the condition.
  • Let the default action apply.

Terms

  • Programmer
  • Software Developer
  • Software Engineer
factorial 0 = 1
factorial n = 
    n * factorial (n-1)
function factorial(num) {
  function loop(acc, _num) {
    if (_num === 1) {
      return acc;
    }
    return loop(acc * _num, _num - 1);
  }
  return loop(1, num)
}
int main() {
   int product = 1;
   for(int i = 2; i <= 10; i++) {
      product = product * i;
      if(i == 7) {
        goto answer;
      }
   }

   answer: 
    printf("%d", product);
}

The Language Equivalence Fallacy

According to W O Quine

no unique interpretation is possible, because a 'radical interpreter' has no way of telling which of many possible meanings the speaker has in mind.

Example: Doubling a list

def createDoubleList(ls):
  i = 0
  doubledList = []
  while i < len(ls):
    doubledList.append(2 * ls[i])
    i += 1
  
  return doubledList
def createDoubleList(ls):
  doubledList = []
  for el in ls:
    doubledList.append(2 * el)
  return doubledList
def createDoubleList(ls):
  return [ 2 * el for el in ls ]

Why is everyone in such a rush? (by Peter Norvig)

Felleisen et al. give a nod to this trend in thier book How to Design Programs, when they says 

"Bad programming is easy. Idiots can learn it in 21 days, even if they are dummies."

  • In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using C++ syntax, but you couldn't learn what C++ is actually good (and bad) for.
  • So what's the point?

Alan Perlis once said: "A language that doesn't affect the way you think about programming, is not worth knowing".

  • A powerful programming language is more than just a means for instructing a computer to perform tasks.
  • The language also serves as a framework within which we organize our ideas about processes.
  • Thus, when we describe a language, we should pay particular attention to the means that the language provides for combining simple ideas to form more complex ideas.

Every powerful language has three mechanisms for accomplishing this:

  • primitive expressions, which represent the simplest entities the language is concerned with,
  • means of combination, by which compound elements are built from simpler ones, and
  • means of abstraction, by which compound elements can be named and manipulated as units.

Evaluating Languages

Modularity

  • It is now generally accepted that modular design is the key to successful programming.
  • When writing a modular program to solve a problem, one first divides the problem into subproblems, then solves the subproblems, and finally combines the solutions.
  • The ways in which one can divide up the original problem depend directly on the ways in which one can glue solutions together.

Example: QuickSort (Strict Sense)

class QuickSort 
{ 
    int partition(int arr[], int low, int high) 
    { 
        int pivot = arr[high];  
        int i = (low-1); // index of smaller element 
        for (int j=low; j<high; j++) 
        { 
            if (arr[j] <= pivot) 
            { 
                i++; 
  
                int temp = arr[i]; 
                arr[i] = arr[j]; 
                arr[j] = temp; 
            } 
        } 
  
        int temp = arr[i+1]; 
        arr[i+1] = arr[high]; 
        arr[high] = temp; 
  
        return i+1; 
    }
} 
void sort(int arr[], int low, int high) 
    { 
        if (low < high) 
        { 
            int pi = partition(arr, low, high); 
            sort(arr, low, pi-1); 
            sort(arr, pi+1, high); 
        } 
    }
quicksort :: (Ord a) => [a] -> [a]  
quicksort [] = []  
quicksort (x:xs) =   
    let smallerSorted = quicksort [a | a <- xs, a <= x]  
        biggerSorted = quicksort [a | a <- xs, a > x]  
    in  smallerSorted ++ [x] ++ biggerSorted  
quicksort [] = []
quicksort (x:xs) = 
  quicksort [a | a <- xs, a <= x] 
    ++ 
  [x] 
    ++ 
  quicksort [a | a <- xs, a > x]

Segment 2

Version Control

 

 

Git and GitHub

Link

Version Control

A version control system, or VCS, tracks the history of changes as people and teams collaborate on projects together.

Developers can review project history to find out:

  • Which changes were made?

  • Who made the changes?

  • When were the changes made?

  • Why were changes needed?

Centralized Version Control Systems

These systems (such as CVS, Subversion, and Perforce) have a single server that contains all the versioned files, and a number of clients that check out files from that central place.

Distributed Version Control Systems

  • In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files; rather, they fully mirror the repository, including its full history.

  • Thus, if any server dies, and these systems were collaborating via that server, any of the client repositories can be copied back up to the server to restore it.

  • Every clone is really a full backup of all the data.

Centralised and Distributed VCSs

  • With the intent that there is One True Source
     

  • All developers work (checkout) from that source, and then add (commit) their changes

  • Systems are designed with the intent that one repository is as good as any other, and that merges from one repository to another are just another form of communication.
     

  • Any semantic value as to which repository should be trusted is imposed from the outside by process, not by the software itself.

Git Basics

Git has three main states that your files can reside in: committed, modified, and staged:

  • Committed means that the data is safely stored in your local database.

  • Modified means that you have changed the file but have not committed it to your database yet.

  • Staged means that you have marked a modified file in its current version to go into your next commit snapshot.

This leads us to the three main sections of a Git project: the Git directory, the working tree, and the staging area.

  • You modify files in your working tree.

  • You selectively stage just those changes you want to be part of your next commit, which adds only those changes to the staging area.

  • You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.

The basic Git workflow goes something like this:

What’s a repository?

A repository, or Git project, encompasses the entire collection of files and folders associated with a project, along with each file’s revision history.

You typically obtain a Git repository in one of two ways

  • You can take a local directory that is currently not under version control, and turn it into a Git repository, or

  • You can clone an existing Git repository from elsewhere.

Initializing a Repository in an Existing Directory

Do

cd /home/user/my_project

and type:

git init

This creates a new subdirectory named .git that contains all of your necessary repository files — a Git repository skeleton.

If you want to get a copy of an existing Git repository — for example, a project you’d like to contribute to — the command you need is git clone.

Recording Changes to the Repository

The main tool you use to determine which files are in which state is the git status command.

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

Tracking New Files

In order to begin tracking a new file, you use the command git add. To begin tracking the README file, you can run this:

$ git add README

Ignoring Files

Often, you’ll have a class of files that you don’t want Git to automatically add or even show you as being untracked.

In such cases, you can create a file listing patterns to match them named .gitignore. Here is an example .gitignore file:

$ cat .gitignore
*.[oa]
*~

git diff

  • What have you changed but not yet staged? And what have you staged that you are about to commit?
  • Although git status answers those questions very generally by listing the file names, git diff shows you the exact lines added and removed — the patch, as it were.

To see what you’ve changed but not yet staged, type git diff with no other arguments.

If you want to see what you’ve staged that will go into your next commit, you can use git diff --staged.

Committing Your Changes

The simplest way to commit is to type git commit:

$ git commit

Alternatively, you can type your commit message inline with the commit command by specifying it after a -m flag, like this:

$ git commit -m "Story 182: Fix benchmarks for speed"
[master 463dc4f] Story 182: Fix benchmarks for speed
 2 files changed, 2 insertions(+)
 create mode 100644 README

Removing Files

To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit.

The git rm command does that, and also removes the file from your working directory so you don’t see it as an untracked file the next time around.

If you modified the file and added it to the staging area already, you must force the removal with the -f option.

Undoing Things

  • One of the common undos takes place when you commit too early and possibly forget to add some files, or you mess up your commit message.
  • If you want to redo that commit, make the additional changes you forgot, stage them, and commit again using the --amend option.
  • $ git commit --amend

If you’ve made no changes since your last commit and all you’ll change is your commit message.

  • Forking and cloning and the difference between them.

  • How to create repositories.

  • What are README files?

  • How to read other people's repositories.

Repositories on GitHub

  • Why commit often and in a logically coherent units

  • Conventions to follow during a commit

  • Searching through a commit

    • git log --author="Arfat Salman"

    • git log --grep="db"

Commit

Commit Message conventions

  • Separate subject from body with a blank line

  • Do not end the subject line with a period

  • Capitalize the subject line and each paragraph

  • Use the imperative mood in the subject line

  • Wrap lines at 72 characters

  • Use the body to explain what and why you have done something. In most cases, you can leave out details about how a change has been made.

References

Source

References

Exercises

  • https://www.katacoda.com/courses/git
  • https://gitexercises.fracz.com/
  • https://www.atlassian.com/git/tutorials/learn-git-with-bitbucket-cloud
Made with Slides.com