Tag: TIL

  • Lets GO!

    I am by trade and tutelage, a PHP developer. I can also work in JavaScript, TypeScript, and React. The bulk of my work has been done in PHP. As someone pretty heavily entrenched in WordPress ecosystem, this served me well.

    However, as I am looking to new horizons, it is becoming apparent to me that I will need to stretch my language skills even further. So let’s start with Go. Please enjoy my ramblings as I learn πŸ™‚

    I am starting with a really basic w3schools.com tutorial to see what the differences in syntax are.

    A Go file consists of the following parts:

    • Package declaration
    • Import packages
    • Functions
    • Statements and expressions
    https://www.w3schools.com/go/go_syntax.php

    From a PHP perspective, this sounds pretty similar.

    • Package declaration => PHP Namespaces. It gives the program or file scope or limitations
    • Import packages -> In PHP, this was done by the use statements. It allowed you to pull in functions from other namespaces, classes, or even just a single function
    • Funcations => This is pretty self explanatory
    • Statements and expressions => I am intrigued…

    Syntax

    In Go, statements are separated by ending a line (hitting the Enter key) or by a semicolon “;“.

    Hitting the Enter key adds “;” to the end of the line implicitly (does not show up in the source code).

    https://www.w3schools.com/go/go_syntax.php

    ❓ Does this mean there are hidden semicolons throughout the code, or does the complier read a new line as a semicolon?

    The answer seems to be yes, under certain conditions. I guess for now, I will continue to explicitly write out my semicolons to avoid confusion until I am more comfortable working in Go. Also, to avoid causing myself grief when I switch back to other languages.

    Comments

    • Single line comments start with //
    • Multiline comments are encased in /* {your comment here} */

    Creating variables

    • Use var
      • Benefit: this allows you to specify the type of the variable (e.g. var test string = "some words";)
      • This notation can be used within a function or without
      • Allows for value assignment to be done separately from declaration
      • Always requires at least a type or value
        • βœ… var test string = "string";
        • βœ… var test string;
        • βœ… var test = "string";
        • ❌ var test;
    • use :=
      • This is a new notation to me, I would have easily mixed it up for a logic statement if I had run into it in the wild
      • Benefit: It is a shorthand and so it may be faster to use
      • Like Typescript, the compiler infers the type of the variable based on the value
      • This notation can only be used within a function
      • Value must always be assigned at declaration
      • It is not possible to declare a variable without a value using this notation (which makes sense)
        • ❌ test string := "string"; (I think this would set a variable string as "string")
        • ❌ test := null; (null and empty strings both throw an error)
        • βœ… test := "string";
    • Declaring multiple vatiables
      • Similar to a mathematical matrix, you can declare multiple variables and values at the same time
        • So, for example var a, b = 6, "Hello!"; is the same thing as declaring var a = 6; var b = "Hello!";
        • If you declaring multiple variables at the same time only supports one type
          • βœ… var a, b string = "A", "B";
          • ❌ var a string, b int = “A”, 2;

    Go variable naming rules:

    • A variable name must start with a letter or an underscore character (_)
    • A variable name cannot start with a digit
    • A variable name can only contain alpha-numeric characters and underscores (a-z, A-Z,Β 0-9, andΒ _Β )
    • Variable names are case-sensitive (age, Age and AGE are three different variables)
    • There is no limit on the length of the variable name
    • A variable name cannot contain spaces
    • The variable name cannot be any Go keywords
    https://www.w3schools.com/go/go_variable_naming_rules.php

    Variable names support camel case, pascal case, and snake case.

    Constants

    Seems constants work as expected, they should be declare once, are unchangeable and read-only, can be typed or have the type inferred from the value. To make constants easy to identify, they should be written in uppercase letters (e.g. “USER_AGE”, not “userAge”, or “UserAge”, or “user_age”)

    Output

    • Print()
      • Prints out the value only, can have multiple comma separated arguments passed in (e.g. Print( "Hello", " ", "World");) Reminds me of the Google Sheets function Concatenate.
    • Println()
      • Adds whitespace between arguments and new line at the end. So Println( "Hello", "World"); prints out Hello World.
    • Printf()
      • Allows integrating the type or value of a variable into a string.
    package main;
    import ("fmt");
    
    func main() {
       var userName string = "Jane";
    
       fmt.Printf( "Hello %v!", userName ); 
       // Prints "Hello Jane!"
       fmt.Printf( "The name %v is a %t", userName, username ); 
       // Prints "The name Jane is a string"
    }
    

    The values are integrated into the string using formatting verbs.

    I’m stopping here for today. The next item up in the tutorial are arrays, and they are definitely different than how they work in PHP. I’ll save that for next time.

  • TIL: Dropping commits and search replace

    I have been working on a project where my access rights to the original repo have recently changed. Before, I was able to push directly to the repo. Now, I am pushing changes as an OSS Citizen and making pull requests from a fork.

    This means that I needed to pull my original WIP branch into my local fork, continue making changes and then push it to a new pull request.

    However, as I was trying to keep things up to date, a rebase from trunk polluted my forked PR with ~260 commits which I didn’t need πŸ™ˆ

    Stackoverflow to the rescue! I found a similar question which suggested running git rebase -i HEAD~n.

    When I ran git rebase -i HEAD~270, vi opened the file with the listed commits. That’s when reality hit. I would need to make ~260 edits to change each pick to drop. There had to be a better way.

    There is! vi has a search and replace function.

    To search and replace for a single instance of a string run this: :s/search-key/replace-key. It will replace the first instance in the file.

    To search and replace for multiple instances of a string, add in %

    The command now becomes :%s/search-key/replace-key

    So in my case, I ran :%s/pick/drop

    This allowed me to mark all of the commits as dropped and then go back and manually select the 10ish commits I wanted to keep back to pick.

    I finished up the process by running git push --force (you could also use --force-with-lease).

    Now my PR is cleaned up and ready for review.

    Something to consider for the future, if I dropped a commit I actually needed, how would I get it back?