The Modern Programmer

In some scenarios, calculating the hash of a piece of data is useful, for instance when you only need to know that something in the dataset has changed, no matter what. Calculating a hash is moderately computing consuming but has some advantadges: Avoids checking the changes field by field of the dataset Allows storing only the data hash instead of the whole dataset In Golang, calculating MD5 hashes of structs can be achieved by using a code piece as this: import ( "bytes" "crypto/md5" "encoding/gob" "encoding/hex" "fmt" ) // Random struct, just for demo purposes type MySubStruct struct { Zaz *bool } type MyStruct struct { Foo int Bar []string Baz MySubStruct } func main() { // Hasheable struct myBool := false myStruct := MyStruct{ Foo: 67372388, Bar: []string{"b", "ar", ""}, Baz: MySubStruct{ Zaz: &myBool, }, } // Crea...

This is the second article of a series analyzing Go concurrency, ie, parallel execution of different threads using Go. The series is composed of these articles: The Go concurrency foundation: goroutines . This one, in which synchronization between subprocesses, specifically by using Go waitgroups , is analyzed. Data exchange between subprocesses: Go channels Why synchronization between subprocesses The first article of the series exposed an example that clearly demonstrated why the subprocess synchronization is needed specifically in go: package main import ( "fmt" "time" ) // mySubprocess sleeps for a second func mySubprocess() { fmt.Println("Entering to mySubprocess") time.Sleep(1 * time.Second) fmt.Println("Exiting from mySubprocess") } // main program process func main() { fmt.Println("Calling mySubprocess from main()...") go mySubprocess() fmt.Println("mySubprocess finished!...

This is the first article of a series analyzing Go concurrency, ie, parallel execution of different threads using Go. The series is composed of these articles: This one in which the Go concurrency foundation, the goroutines , are analyzed. Synchronization between subprocesses: Go waitgroups Data exchange between subprocesses: Go channels Goroutines In brief, a goroutine is a standard Go function that is processed in parallel (concurrently) to the main Go process. Let's see an example. The execution of the next code is quite predictible: The main Go process (that code in the main() function) will execute, then it will pause while the function mySubprocess() is running and then it will finish. Just one process, no concurrent execution. package main import ( "fmt" "time" ) // mySubprocess sleeps for a second func mySubprocess() { fmt.Println("Entering to mySubprocess") time.Sleep(1 * time.Second) fmt.Pr...

Learn how to apply test coverage to your Typescripts projects.

In Node, process.env property gives you access to the user environmental variables. Opposite to what you could think, these variables are always treated as strings , no matter the nature of your environment or the way you defined them. Misunderstanding of that said above can give you unpredictible behaviours, as that shown in the next code snippet regarding the usage of a presumably boolean env variable: process.env.FALSY = false; let evaluation = process.env.FALSY ? "This is imposible" : "This is the expected result"; // Since process.env.FALSY is returned as string, // and the bool value of a non empty string is true // it is evaluated not as falsy but as truthy The problem is not just related to boolean values, but also to numeric values, as shown the next code snippet: process.env.ONE = 1; let mustBeSix = process.env.ONE + 5; // Though you could expect mustBeSix being 6 // its result is the string concatenation // of '1' and '5' ie, ...

To put it simple, Agile methodology is based on quick iterations. That approach implies that:  We must be fast coders to complete each iteration in the scheduled time Soon or later we'll go back to that code we quickly wrote in the past If we only focus in the first statement ( be faster, my friend ), codebase quality tends to degrade, code entropy -or the codebase maintenance complexity- increases, bugs start to consume more and more time in every sprint and, in last term, software components must be fully re-coded, what can consume great part of the benefits we got by becoming agile. However if we have in mind that, in coming iterations, we'll have to refactor the code we are working on right now, we can document the technical debt we intentionally create with the purpose of fixing it in the future. In that way, when planning every iteration (or sprint) we can schedule a percentage of the coding effort to fix that debt we left, theref...