# Golang Video Tutorials (Evatix)

## Video 02. Code Review Guide, Function Writing Best Practices.

### Best Practice
* Attention to details
* Documentation should be beautiful
* Documentation
* Code
* Running methods
* Readme
* local makefile
* Run

### Func writing best practices
* No new line after function start
* Use tab (no single space)
* Operation should have gaps (not a+b , rather a + b)
* if only return statement no newline
* if other statements more than 2 lines, newline before return
* if/else/for after block use newline
* if/else/for before block newline optional
* double new line is a red flag
* no comment out codes
* you can have comments
* function parameter should not be more than three-four, three is standard. Use instead of parameter:
* interface (preferable)
* struct
* name should be self explanatory and meaningful
* short OpenMail
* Full OpenSMTPProtocolMail (Use this instead of short)
* Avoid writing combined functions
* No // ReadWriteFile, instead WriteFile, Read File
* Single Responsibility
* ReadFile
* WriteFile
* If class/struct is File then
* Read
* Write
* First Write draft code, write immediately, dont worry to much about the structure, it will get fixed overtime. It will click by practicing more and more.
* Function should not be more than 15 lines. (can have exceptional cas, worst case 25)
* struct/class/file should not be more than 120 lines
* return one item (good practice) with error (error,somefield)
* return interface/struct rather than sending direct array/map ... wrap these in struct
* rather than somefunc(array[0],array[1]) use struct.fieldname instead

### Variable naming
* private should start with lowercase, public with uppercase (same for functions)
* do not use _
* name should be meaningful

## Video 03. Code Review Enhanced

* Never submit with commented out codes
* No magic string/number
* Instead make consts for each magic field
* Comment should have space after `//`
* correct `// comment`
* wrong `//comment`
* every variable should be assigned only once (best case), worst case (can be loop through/slice assigns) also, if variable changed follow same methodology
* one way to solve is use getter/setter
* Ignore : Remove, drop then ignore ( for existing files)
* No new line after return statement
* if function name starts with is/has/should.... always returns bool

## Video 10. Package organize, Github desktop use, Goland use efficeiently, Gostruct create from json

### When we create a project (General)
* GitIgnore
* Readme
* Makefile

### GO Project
* Go Mudule initialize with github url without adding the http/https part
* main.go
* Must ignore IDE files by adding `.idea/*.*` to gitIngore
* If making go package the codes should be on the root level (Convention)
* modfile should be on the root level
* Company convention, there should be a package.go file inside every package
* Use shortcuts to move/rename structs... (Goland)
* Rename `Shift+F6`
* Menu>Find>Replace Path
* Before changing always commit (replace might cause unexpected behaviour)
* Settings>keymap>search>edit/check the shortcuts
* Not sure about the JSON file (What is the JSON file for? My guess the user will modify the file and set different parameters to get warning or error ?)
* Check out `Viper` on your own
* json-to-go , for json to go struct

### Makefile common
* BinariesDirectory
* build
* run

## Video 12. UnitTests AAA, Mutation, UnitBest Practices

### Unit Tests
* AAA : Arrange (setup), Act(running), Assert(verify what is expected)
* Test Driven Development
* Behaviour Driven Development (Bigger number of developers)
* Unit Testing (Small group of developers)
* Naming Convention `Test+MethodName+what we are verifying`

## Unit tests
* Doesnt run complex parts
* Check mocking libraries
* Mocking is the most important part in unit testing
* Arrange Defines Expected
* Act Defines Output
* Assert Checks / validates
* Coverage : Should Cover at least 80% of the codes in the block/method
* If there are branches (...if/else conditions), create multiple unit tests for each
* Mutation Testing. Auto changes things inside, (lets say a+b => a*b)if the unit test fails then the code is successful

# Video 20. Golang Gitlab package starter, issue create, clihelper, organize file

## Communication between processes
* By Sharing Resource
* Shared Files ( one process writes another reads)
* Shared Memory
* Flags

* By message passing (between process in different machine)
* Simple message passing
* Synchoronous communication
* Asynchronous communication
* Rendezvous methods
* Semaphores

* Console Output
* Cli1 -> cli2(Task1, task2 requests cli3) -> cli3
* Clie (until cli2 finished) __Bubble Up__
* cli2 (until cli3)
* cli3 (until cli4)
* cli4
* Cli1
* CliTaskrunner -flag (task1)
* CliTaskrunner -flag (task2)

## Gitlab
* Create Repository
* Create Issue
* Create Milestone
* Name of file is name of file (Convention)

## Branch Management
* Create draft/develop (Push into this, upto practice or needed/ then remove)
* Then push/merge into develop
* then finally into master

**Package exposed method should be on the root**

## Video 21. Cli Basics golang

* os.Args gets from cli

### Make file
* target : command line
* by default runs all

## Video 22. Code Review on Mutex and lazycode

* when using map in struct use `somecollection` in struct name
* Regular expressions should be outside of function use var (expr1,expr2 ....)
* mutex should be created outside of function

## Video 23. Code Refactoring v2

* No need to comment for enums, they are self explanatory
* Not implemented methods should have panic inside to let other users know asap
* Create issues for not implemented method and put the link in panic also in the comment
* Rather than returning raw fields use struct instead
* for example ([]string, error) -> put it in somestruct and now return should be something like this *somestruct
* dont repeat codes, instead make a separate function and use it wherever you need

## Video 24. Expectations from gopackaages (Gitlab)

* Common issues
* Copy git common items
* update readme properly
* create logo for the package , consult Romel bhai
*
* Create Multiple issues
* Common ones : project structure, logo create ....
* Features
* Assign to people
* Create milestones

## Video 25. CLI Helper Q&A v1

## Video 26. Code-Dry-Os-Related ......

* For different OS
* Methods can be like methodForWindows, methodForMacOS, methodForLinux (Not Go recommended)
* Best approach methodname should be methodname but should have different files with suffix of OS having `_` like MethodName_windows.go, MethodName_darwin.go, MethodName_linux.go
* Never send raw array/ map, use struct instead which has the array

## Video 27. Mutex issues, global, parallel

* Global mutex
* Parallel mutex (within the struct), or we can say personal mutex ....

type someStruct struct{
    mu sync.Mutex
}

## Video 28. nginx ds v-3, constructor, attacher

* Sharebale simple struct should go into packagecore folder/package... example if package is nginxconf then into the package nginxconfcore.

## Video 29. slice training

* Array
* []string{"a",b"....}
* [2]string
* fixed length
* to modify some type (everything works with array or linked list under the hood)
* array stays together in memory (sequential)
* superfast when accessing data by index
* cannot modify length or whole structure
* Vector
* vector (length, capacity)
* index position starts at 0
* Slow comparatively to array BigO(n)/worstcase
* lets say vector(0,10)
* if capacity crosses, resizes to double
* **delete,add,resize :b=BigO(capacity)/n**

* Vector equivalent in Golang is slice
* Array to slice array[:], array[startIndex:Length]
* use make([]type,length)
* makr([]type,0,cap) -> starting position is 0
* use slice when length is dynamic
* better approach make([]Type,0,cap)
* it is better to be clear than clever

* Linked List
* Solves the problems of array
* Add, remove lenght
* cannot access item randomly
* works with node
* next points to next node
* single item accessing is too slow
*

## Video 31. Jsoner and interfaces

### Interface
* Its a contract
* Doesn't care how its implemented
* only have the functions, what it takes and what returns/outputs
* Easy to test, easy to maintain
* interface naming name+er ... lets say json(er) even if the word doesn't make sense
* only the related functions should be inside interface
* best practice Single interface single method
* sometimes convention will be broken for some cases
* As(methodname) + self injector makes it forcefully implement interface

### Reflection
* Use when necessary
* do not abbuse it

## Video 32. How to import cycle fix

## Video 33. ReflectHelper

## Video 34. Core Basics
* All custom data structures
* some of it will be changed after go release in august (when it will support generics)

## Video 35. Errorwrapper basics

## Video 36. How to review

* Be carefull when using waitgroup
* waitgroup is costly and complex

# Code-Review Latest : (Be clear not clever)

* Code should be as dumb as possible
* Even though we have multiple options but should always go for the simple and understandable one
* Try to use private methods as less as possible. Use more Public
* try to avoid method calls when looping, or expensive conditions
* core level code should be optimized
* business level priority is beautiful code rather than optimizing
* avoid using panic on package level, return error -> client(cli/UI) will decide what to do with error
* try avoiding type casting
* business level code should never be more than 15 lines

# Cimux Videos

## Package manager cli

* Hosting using linux commands is difficult
* Alternative approach CPanel
* Short CLIs to complete specific delegations
* Among these clis package manager cli is the most important
* why making own package manager cli (when there are available ones like scoop, homebrew.....)
* Licensing Issues
* different os uses different package manager (for example ubuntu uses apt, CentOS uses yum.....)

### Cli Explained

* Expected command :

pkgmanager install @username/packagename@version
pkgmanager install packagename

* Steps To Perform
* Search Package
* Validate Package
* Call Downloader CLI
* Check homebrew formula json file (check for reference)
* Downloader cli downloads recipe (json)
* Confirming dependency installs
* if not found dependencies recall (Seacr Package...../itself)
* OS specific package binary download
* Run specific commands to install
* Pre execution
* Script
* SH
* Bash
* Powershell
* Node/python/golang

* Post execution
* Script
* SH
* Bash
* Powershell
* Node/python/golang
* Reinstall
* Reinstall all packages
* Create
* Send to server / REST
* Server will save and create package

pkgmanager create --name="ex" --config:jsonFilePath --userauthToken="" ...

## Video 2 : How to proceed with goals solid, kanban, ethernet, mac, release dates.

* DHCP auto, machine request and router assigns
* MAC - Physical address
* Lan Card has unique id, its fixed, this id is Mac/ Physical address
* From router fixed IP can be set by MAC address
* Ip Address, Subnet Mask, Default Gateway
* Default gateway is medium to communicate with outside world
* IP address is for identifying each machine
* Public IP / Real IP => Multiple IPS
* ICP has MAC address
* MAC address can be cloned/re assign
* But Theres a match of IP with MAC and can be traced back
* Ethernet Package Target OS (Ubuntu18.04>= ; CentOS)
* First Manual Configuration and then golang package
* [Goals](https://goals.keepsolid.com)
* August 1, Alpha release.

## Video CIMUX Basics, Introduction by NurSarowar

* System Development For Customers who will have other customers (Like CPANEL)
* Control Panel API
* To handle activities like account creation...
* Combined Billing System. For Internal and also customer can use.
* Expose API, For Us and for even customer
* First Priority is Control panel
* Control Panel needs multiple packages
* WIll have separted UI
* Also user can execute from command line
* Formulas will be downloaded OS Specific

## CIMUX Configuration Intro, Deadlines v-1

* Idea is to create brand value like amazon
* Instead of multiple commands running in linux, configurations can be done with a few clicks
* Control Panel
* Target for initial release CentOS and Ubuntu 18.04 >=
* Design the system such as a couple of tweak should work for new flavours or operating system
* History Of each cofiguration, so that can be rolled back
* For Ethernet try manual configuration first
* Make github issues
* Issue should have mind mapping/ Brain storming
* Weeks of programming can be saved by hours of planning / brain storming.
* Integration Test to make sure everything works perfectly

## Task Organizer Excel Sheet

* History of version changes
* Use Filter view rather than create filter

## Nginx Package Intro v1

* Goal is to parse nginx.conf file
* Line Example
* command args1 args 2 argsn ....; ## comment

* capture command with each arguments without space
* Block of code
* Nameoftheblock args... { // start of block

* Goals
* detect change
* discard white spaces
* detect invalid edits and notify user
* maintain history of changes
* conf to json
* json to conf

## Schedular package intro

* Task Collection
* Map of tasks
* Add
* Remove

* Each task should run asynchronously
* Scheduler Contains collection of taskcollection
* Error Handling
* Log
* Send Error (Bubble)
* Panic

## Nginx Intro 2

## DNS Record Setting

* Nameserver is important
* Create A Record and point it to public IP
* Public Ip generally hits on port 80
* Forward port from router to internal ip
* change host from etc/host
* To make it work ipconfig /flushdns

## Nginx v5

* Use struct as function parameter if needed.
* Regex to detect some pattern
* Use regex when code becomes too complex
* If it can be solved without regex in easy manner, then solve without using regex

## Nginx v6

* Try to create less variable in loops
* If loop condition comes from another method call, use variable prior to declaring loop and use it as condition
* var length := getLen(...something)
* i := 0 ; i < length ; i++

* Best practice is to set limit for recursion
* Do not process in New() function
* lets say NewSomething() *something
* Do not process but use to initialize

*