Example 1: Modifying a Slice Without Affecting the Original

To understand this better, let's look at the first example. In this example, we have a function called AppendNumber which appends the number 7 to a given slice. However, even though we modify the slice within the function call, we do not affect the original slice because Go creates a copy of the arguments for the function to work with.

func AppendNumber(slice []int) {  
    slice = append(slice, 7)  
}  

func main() {  
    slice := make([]int, 3, 6)  
    for i := 0; i < len(slice); i++ {  
       slice[i] = i  
    }  
    fmt.Println("before", slice) // Print 0 1 2  
    AppendNumber(slice)  
    fmt.Println("after", slice)  // Print 0 1 2  
}

The AppendNumber function only modifies the copy of the slice within its scope, not the original slice, which is very straightforward.

Example 2: Modifying an Element in Slice

Now let's look at the second example. In this example, we have a function called UpdateNumber which updates an element in the slice at index 1 to the value 7. Unlike the previous example, this time we notice that the original slice is modified.

func UpdateNumber(slice []int) {  
    slice[1] = 7  
}  

func main() {  
    slice := make([]int, 3, 6)  
    for i := 0; i < len(slice); i++ {  
       slice[i] = i  
    }  
    fmt.Println("before", slice) // Print 0 1 2  
    UpdateNumber(slice)  
    fmt.Println("after", slice)  // Print 0 7 2  
}

In the main function, we create a slice, assign values to it, and then print the slice before calling the UpdateNumber function. The output shows the original values of the slice, which are 0, 1, and 2. After calling the UpdateNumber function, we print the slice again, and this time the value at index 1 has changed to 7.

Knowing What Values Get Copied in Go

It seems that we still can influence the original Slice given the result of the second example. To think this through, we would need to know exactly what values are copied to the function arguments in Go. When a slice is passed to a function, the slice header (which contains a pointer to the underlying array, its length and capacity) is copied to the function arguments. The underlying array is not copied.

The slice header that is copied to the argument in the examples will look like this:

type sliceHeader struct {
    Data     uintptr // A pointer to the underlying array
    Length   int     // The number of elements it contains
    Capacity int     // The maximum number of elements it can hold
}

In the first example, when we call the AppendNumber function, a copy of the slice header is created so that any changes made to the slice within the function do not affect the original slice.

In the second example, when we call the UpdateNumber function, a copy of the slice header is created. However, since the underlying array is not copied, both the original slice and the copy point to the same array in memory. Therefore any changes made to the slice (changing the value at index 1) will be reflected in both the original slice and the copy.

Conclusion

To conclude, modifying elements of a slice within a function will affect the original slice if the underlying array is shared between the original slice and the function's copy. If a new slice is created within the function (e.g. using append), the original slice is not affected as we have updated the copy of the slice header to the newly created slice.

By understanding what values get copied to arguments in Go, and how changes to the slice header and array elements can affect the original slice, we can write more reliable and maintainable code. If you are interested in more information about Slice in Go, this article is worth a read: https://go.dev/blog/slices

I hope you have found this explanation of slices in Go useful and informative. If you have any further questions or need additional clarification, please feel free to ask.

Thanks for reading!

Discord Bot powered by ChatGPT API

Prerequisites

DiscordGo - provides low-level bindings to the Discord chat client API.

Go OpenAI - provides Go clients for the OpenAI API.

Above are two main packages (dicordgo and go-openai) use to build this ChatGPT Discord Bot. They have great examples of different kinds of use cases that we can build our own logic around.

Things that need to be Handled

Handle Longer Responses from ChatGPT

Due to the character limit on Discord (2000 characters per message at the time of writing), it may be necessary for longer replies from ChatGPT to be split up and sent as multiple messages. It's important to note that when messages are split into multiple parts, the character may be truncated if we don't count the number of characters correctly, especially if we're dealing with languages like Mandarin or Japanese where one character can be multiple bytes. Therefore it's recommended to use the Unicode character count instead of simply counting the number of bytes like len(). This can be done using the utf8.RuneCountInString() function instead. By using this method we can ensure that each part of the message contains complete characters and avoid confusing or misleading messages. It's important to be aware of these language-specific nuances when working with text messages in Golang or any other programming language.

To find out more about managing Strings, bytes, runes, and characters in Go, please visit the Go Blog.

func SendMessageByChunk(message string, chunkLength int, send chan<- string) {
    counter := 0
    lastIndex := 0
    for i, w := 0, 0; i < len(message); i += w {
        counter++
        _, width := utf8.DecodeRuneInString(message[i:])
        w = width

        // We reach the maximum chunk length
        if counter == chunkLength {
            chunk := message[lastIndex : i+w]
            send <- chunk
            lastIndex = i + w
            counter = 0
        }
    }
    // Make sure the last bit of the message is sent
    if len(message) > 0 && lastIndex < len(message) {
        send <- message[lastIndex:]
    }
    close(send)
}

In the above example, we create a function to send messages of a certain length (chunkLength). To handle Unicode characters correctly, we can use utf8.DecodeRuneInString() to decode the first UTF-8 encoded Unicode code point in the given string and get the number of bytes it occupies. We iterate through the string until all the characters (runes) are decoded.

Application Command Timeout on Discord

Another limitation that may arise is Discord's application command timeout, which at the time of writing is set at 3 seconds. This means that if ChatGPT takes longer than 3 seconds to respond, users will receive an error message indicating that the application has not responded. As ChatGPT can take longer than that to respond, the bot needs to delay the response by setting the interaction callback type DEFERRED_CHANNEL_MESSAGE_WITH_SOURCE to acknowledge that the event has been received and that a follow-up will come later. I also think it's good practice for the bot to let users know that their message has been received and is being processed. By implementing these strategies, ChatGPT can provide a better user experience on Discord.

The following code snippet from this project shows how we can defer or delay replies via DiscordGo.

    // If we don't send a response in 3 seconds, the error 'The application did not respond' will appear.
    // To avoid this, we send the following type of response
    err := s.InteractionRespond(i.Interaction, &discordgo.InteractionResponse{
        Type: discordgo.InteractionResponseDeferredChannelMessageWithSource,
    })

Motivation behind the Project

I've been a frequent user of ChatGPT ever since it was launched by OpenAI. Their Chat App has proven to be very useful in speeding up my daily tasks and even occasionally planning my travel itinerary. It has been really powerful and I no longer have to go through the hassle of searching endless websites and connecting the dots myself. Although the app's interface looks nice, with real-time updates, the connection can be unreliable at times. Another drawback I noticed is that users have to log in before they can use the app's features, which may seem like a minor inconvenience but could be a deal-breaker for those who value ease of use.

Conclusion

We did not cover all the details of building this project in this article but feel free to visit the GitHub page to play around with it 😊

The best way of learning about anything is by doing. - Richard Branson

If you're interested in running the bot for your Discord server or contributing to the development of the project, please visit the GitHub page. Welcome any suggestions or ideas for improving the code 💪🏽

Hopefully, you found something useful.

Thank you for reading.

How to Read the Response Body

There are different ways of reading the response body like the following:

resp, err := http.Get("http://example.com/")
if err != nil {
    // handle error
}
defer resp.Body.Close()
body, err := io.ReadAll(resp.Body)
// ...

or

resp, err := http.Get("https://example.com")
if err != nil {
    // handle error
}
defer resp.Body.Close()
// get a copy of the response body as a byte slice
body, err := httputil.DumpResponse(resp, true)
// ...

The examples above basically read the entire contents of an HTTP response body as a byte slice, but take different arguments. We will not go into detail about these measures. There are plenty of resources available to help you.

What if the response bodies are huge and we want to avoid memory and performance problems because the whole response has to be loaded into memory before it can be processed? To avoid this, we could use streaming techniques to process the response body in chunks.

Reading the Response Body in Chunks

resp, err := http.Get("https://example.com")
if err != nil {
    // handle error
}
defer resp.Body.Close()

buff := make([]byte, 10)  
for {  
    var bytesRead int  
    bytesRead, err = resp.Body.Read(buff)
    if err == io.EOF {
        break
    }
    if err != nil {  
        // handle error
    }
    // send the data to the Send function for further processing.
    send(buff[:bytesRead])  
}

As you can see from the example above, instead of reading the response body all at once, we create a byte slice called buff to store our chunks of the response body. Due to the power of the http package, the response body implements the Reader interface, which allows us to stream on demand by calling the Read(b []byte) method. Finally, the last line of code sends the data to read in the previous step to a hypothetical Send function. The [:bytesRead] notation is used to slice the buff slice to contain only the bytes actually read in the previous step.

To read parts of the response body until the whole body has been read, we put it in an infinite loop. The loop will break when the io.EOF error is returned, indicating that the end of the response body has been reached. This may sound familiar, and is pretty much the same as trying to read a file as a chunk using the os package (to read more detail here).

If you're like me, let's look at what could go wrong in the previous example, where we read the response body in chunks, in the next section.

io.EOF Might Not Be What You Think

The code snippet appears to be correct at first glance, but there is a risk of obtaining arbitrary results when determining the number of chunks received from the remote server if we do not perform a follow-up check after encountering the io.EOF error.

Let's have a look at how the Read method is described in the official documentation of the Reader Interface:

When Read encounters an error or end-of-file condition after successfully reading n > 0 bytes, it returns the number of bytes read. It may return the (non-nil) error from the same call or return the error (and n == 0) from a subsequent call. An instance of this general case is that a Reader returning a non-zero number of bytes at the end of the input stream may return either err == EOF or err == nil. The next Read should return 0, EOF.

Although it may seem feasible to break the loop immediately when the io.EOF error is returned, we may still receive the last chunk of data with a return value such as 5, EOF, potentially losing this chunk of data in the process. To ensure greater robustness, we must modify our code to incorporate a more comprehensive check, as illustrated in the following example:

//...

buff := make([]byte, 10)  
for {  
    var bytesRead int  
    bytesRead, err = resp.Body.Read(buff)
    if err == io.EOF {
        err = nil  
        // There may be one last chunk to receive before breaking the loop.
        if bytesRead <= 0 {  
            break  
        }
    }
    if err != nil {  
        // handle error.
    }
    // send the data to the Send function for further processing.
    send(buff[:bytesRead])  
}

The behaviour we see above is to optimise the HTTP transport code by recycling its connection earlier. We can see this from the code snippet in the http package itself:

...
// If we can return an EOF here along with the read data, do
// so. This is optional per the io.Reader contract, but doing
// so helps the HTTP transport code recycle its connection
// earlier (since it will see this EOF itself), even if the
// client doesn't do future reads or Close.
if err == nil && n > 0 {
    if lr, ok := b.src.(*io.LimitedReader); ok && lr.N == 0 {
        err = io.EOF
        b.sawEOF = true
    }
}
...

For those of you who want to delve deeper, you can find the sourcecode here.

Tests Exercise

Testing is essential to ensure that our code works as intended, and the best way to gain proficiency is through practical application.

Exercise:

Write a test file to test the following function using both a mock HTTP client and a real HTTP server. Share your findings in the comments section below :)

// HTTPClient is an interface for http client.
type HTTPClient interface {
    Do(req *http.Request) (*http.Response, error)
}
// Download downloads a file from a given url and send the data to the send function.
func Download(client HTTPClient, url string, bufferSize int64, send func([]byte)) error {
    // TODO
}

Conclusion

Things are not always as obvious as we think they are, especially what we think they should be based on our experience. There's always a blind side if we can't see it from another angle, just like what we learn about io.EOF, which doesn't mean we've reached the end of the file.

Reading the response body in Go requires a bit of care and attention. You should be aware of pitfalls such as reading the body twice, not closing it, not handling errors properly, and using the wrong decoder. By following best practices and using the right tools, you can avoid these pitfalls and make your HTTP requests more efficient and reliable.

The sample solution to the exercise can be found here. Feel free to clone it, try it out and share your thoughts in the comments below.

I hope you found something useful and that it will save you a lot of valuable debugging time :)

Thank you for reading!

{"resource_type":"payment","action":"confirmed","data":{"amount":100}}
{"resource_type":"customer","action":"created","data":{"name":"john"}}

We have some basic fields like resource_type and action that are the same for all events, but the type of data is different depending on the resource_type. For example, the payment resource has an amount field of type number, and this is obviously different from the other resource type, customer, where it has a name field of type string.

Built-in JSON Unmarshal Method

The json.Unmarshal() method in Golang is used to decode a JSON-encoded data structure into a Golang struct or map. It takes two parameters - a byte slice containing the JSON-encoded data, and a pointer to the struct or map that the decoded data will be stored in. How do we do that with the built-in method json.Unmarshal. Let's take a look an example below:

package main

import (
    "encoding/json"
    "fmt"
)

type Event struct {
    ResourceType string `json:"resource_type"`
    Action       string `json:"action"`
    Data         any    `json:"data"`
}

func main() {
    var jsonBlob = []byte(`[
    {"resource_type":"payment","action":"confirmed","data":{"amount":100}},
    {"resource_type":"customer","action":"created","data":{"name":"john"}}
]`)

    var events []Event
    err := json.Unmarshal(jsonBlob, &events)
    if err != nil {
        fmt.Println("error:", err)
    }
    fmt.Printf("%+v", events)
    // output: [{ResourceType:payment Action:confirmed Data:map[amount:100]} {ResourceType:customer Action:created Data:map[name:john]}]
}

As you can see from the example above, we set the Data field to type any as we don't know what type of data we will get from the notification service. When we let the program decode the data field, we get the value as map[string]interface{}. We may get away with this since we can still access the data in the map by key, depending on the resource type. However, this method has the disadvantage of making the code less readable and maintainable, because we don't know the structure of the data field. In addition, we cannot take advantage of the go package validator, which validates structures and individual fields based on tags. You can see more details about Validator.

We would need to know exactly what type of data we want go to decode, but we don't know that until go has received the data. Is there a way to decode the resource_type field first, before decoding everything, so that we know for sure what type of data we are decoding to? The answer is yes, but we will have to create our own custom UnmarshalJSON method. To see more details about UnmarshalJSON.

Unmarshal Dynamic Data

Here is the example for creating our own custom UnmarshalJSON method:

type Event struct {
    ResourceType string `json:"resource_type"`
    Action       string `json:"action"`
    Data         any    `json:"data"`
}

type Customer struct {
    Name string `json:"name"`
}

type Payment struct {
    Amount int `json:"amount"`
}

func (e *Event) UnmarshalJSON(data []byte) error {
    var inner struct {
        ResourceType string `json:"resource_type"`
    }
    if err := json.Unmarshal(data, &inner); err != nil {
        return err
    }

    switch inner.ResourceType {
    case "payment":
        e.Data = new(Payment)
    case "customer":
        e.Data = new(Customer)
    }

    type aka Event
    return json.Unmarshal(data, (*aka)(e))
}

In this example we define a Customer struct which has a field - Name and a Payment struct which has a field - Amount. We then create an inner struct to get the ResourceType in our custom UnmarshalJSON method, so that we can have a switch statement to decide which struct we want our go program to decode into depending on the resource type. Once we have assigned our data to the appropriate structure, we can call the json.Unmarshal() method to decode the JSON string into the receiver e. You may notice that we declare an alias type aka Event instead of using Event directly, this is because we are trying to avoid an infinite loop with a custom UnmarshalJSON method.

A type alias is a way of defining a new name for an existing type. However, it does not inherit the methods of the Event type, so we can get around that by using an alias.

Let's put them all together and see the result below:

package main

import (
    "encoding/json"
    "fmt"
)

type Event struct {
    ResourceType string `json:"resource_type"`
    Action       string `json:"action"`
    Data         any    `json:"data"`
}

func (e *Event) UnmarshalJSON(data []byte) error {
    var inner struct {
        ResourceType string `json:"resource_type"`
    }
    if err := json.Unmarshal(data, &inner); err != nil {
        return err
    }

    switch inner.ResourceType {
    case "payment":
        e.Data = new(Payment)
    case "customer":
        e.Data = new(Customer)
    }

    type eventAlias Event
    return json.Unmarshal(data, (*eventAlias)(e))
}

type Customer struct {
    Name string `json:"name"`
}

func (c *Customer) String() string {
    return fmt.Sprintf("{Name:%s}", c.Name)
}

type Payment struct {
    Amount int `json:"amount"`
}

func (p *Payment) String() string {
    return fmt.Sprintf("{Amount:%d}", p.Amount)
}

func main() {
    var jsonBlob = []byte(`[
    {"resource_type":"payment","action":"confirmed","data":{"amount":100}},
    {"resource_type":"customer","action":"created","data":{"name":"john"}}
]`)

    var events []Event
    err := json.Unmarshal(jsonBlob, &events)
    if err != nil {
        fmt.Println("error:", err)
    }
    fmt.Printf("%+v", events)
    // output: [{ResourceType:payment Action:confirmed Data:{Amount:100}} {ResourceType:customer Action:created Data:{Name:john}}]
}

Before we try out our new custom UnmarshalJSON method, we add an extra custom String method to these two types, Customer and Payment, so that our result can be printed more nicely. Moreover, we can be certain that they are decoded to corresponding types. Now, we can call the json.Unmarshal() method to decode the jsonBlob variable into events variable. Finally, we print out the events to the console and we get the whole event with our custom type instead of map[string]interface{}.

Conclusion

By writing our own custom UnmarshalJSON method, we have more granular control over how the data is decoded into our own struct, even though the data is dynamic. In addition, we can use the go package validator because we have defined our custom struct for each field and subfield.

We learn how to use aliases to prevent recursion calls to the custom method from causing panic, although the original design of Aliases is to make code more readable by giving a more descriptive name to a type, or to make it easier to refactor your code later. Please let me know what you think and feel free to leave a comment below :)

Hopefully you found something useful and can apply it to your work.

The source code for this tutorial is available here.

Thank you for reading.

Multiple Git configurations

There may be a situation where you need to switch between different git repositories, each of which has its own set of credentials (or ssh keys). Even if you only have one set of credentials for all repositories, at least for your personal git account(for side or open source projects), it is always good for security to have them different from the ones you use at work. We don't want our work to be compromised, do we? 😇

Let's start by setting up your Git profile, assuming we need to set up two profiles, one for work and one for personal use.

Custom Git configurations for individuals

Set up a personal profile by creating a file called .gitconfig-personal in your home directory ($HOME) and filling it with the following content. Make sure you use your own username and email for your git account.

[user]
    name = <put your personal username here>
    email = <put your personal email here>

We will configure the profile for your work and save it under a different name, such as .gitconfig-work, just as we did in the previous step. Also put it in your home directory like this $HOME/.gitconfig-work.

[user]
    name = <put your work username here>
    email = <put your work email here>

Git global configurations

Last but not least, we will use the includeIf sections to specify which profiles we want git to use in which directories. This will allow us to seamlessly switch between git profiles depending on your working directory or workspace. The only thing we would need to do is edit the following content with the appropriate values, depending on what you need, and put it in .gitconfig in your home directory ($HOME). You are ready to go.

[includeIf "gitdir:~/personal/"]
      path = ~/.gitconfig-personal

[includeIf "gitdir:~/work/"]
      path = ~/.gitconfig-work

Assuming that we don't have any local level configurations for Git that would override the global level we've just set (to see more detail here), we can now try to verify that by running the command git config -l.

$ cd ~/personal/personal_git_repo
$ git config -l | grep user
user.name=<personal username will appear here>
user.email=<personal email will appear here>

$ cd ~/work/work_git_repo
$ git config -l | grep user
user.name=<work username will appear here>
user.email=<work email will appear here>

Ta-da 🥳 We can now switch between a number of different custom git configuration files, depending on the path of the git repository we are working with.

Named profiles for the AWS Command-line interface (CLI)

I always feel that if we can find a way to quickly move between different cloud-native environments, it can make our life a lot easier. It can also prevent us from accidentally breaking things.

What is a named profile?

A named profile is a collection of settings and credentials that we can apply to a AWS CLI command. When we specify a profile to run a command, the settings and credentials are used to run that command. Multiple named profiles can be stored in the config and credentials files.

In the following example we specify user1 except for the default profile one and save it as ~/.aws/config

[default]
region=eu-west-2
output=json

# Include the prefix "profile" only when configuring a named profile in the config file
[profile user1] 
region=us-east-1
output=json

AWS credentials

Next thing is to configure credentials and allow the AWS CLI tool to know which credentials should be used for each specified profile. We save it as ~/.aws/credentials

[default]
aws_access_key_id=<put your access key id here>
aws_secret_access_key=<put your secret access key here>

[user1] # Do not use the prefix "profile" here in crendetials
aws_access_key_id=<put your access key id here>
aws_secret_access_key=<put your secret access key here>

Verify that the profile is successfully added by aws configure list-profiles. You should now see 2 profiles like below:

 default
 user1

To switch between different AWS accounts, set the environment variable AWS_PROFILE at the command line with export AWS_PROFILE=<put your profile name here>. Setting the env variable will change the default profile until the end of your shell session or until you set the variable to a different value.

Use the aws configure list command to list your current profile and show the details of it as shown below:

      Name     Value             Type    Location
      ----     -----             ----    --------
   profile     user1              env    ['AWS_PROFILE', 'AWS_DEFAULT_PROFILE']
access_key     ****************FPFQ shared-credentials-file
secret_key     ****************a5K9 shared-credentials-file
    region     us-east-1          env    ['AWS_REGION', 'AWS_DEFAULT_REGION']

We can go further by running aws sts get-caller-identity to get the identity of the caller and make sure you are using the correct identity to run the command.

Account: 'aws_account_id'
Arn: arn:aws:iam::aws_account_id:user/user1
UserId: ****************KPM7

Great! Now you can switch between the different name profiles with ease 🎉

Conclusion

This article has given us some tips on how to optimise the tools we use to speed up our workflow.

Hopefully you found something useful and can apply it to your work.

Thank you very much for reading.

Here is the task we would like our program to achieve

Create a pipeline that reads text files, finds the number of occurrences of a given phrase in each text file, and calculate the total number of occurrences of the phrase in all files.

The first part of the code is the most straightforward one where we pass file paths and a phrase to the program as the command-line argument, so the program knows which files to look for for the given phrase. A for loop is used to iterate each file, and we are going to create goroutines to read and count the number of occurrences in each one. Finally, we will gather results from all goroutines and sum up the total.

For example:

package main

import (
    "bufio"
    "fmt"
    "os"
    "sync"
    "sync/atomic"
)

var wg sync.WaitGroup
var ops int32

func main() {
    if len(os.Args) < 2 {
        fmt.Println("Need at least one phrase and file parameters!")
        return
    }
    phrase := os.Args[1]
    for i := 2; i < len(os.Args); i++ {
        fn := os.Args[i]
        // TO-DO: Reads the file and finds the number of occurrences of a given phrase
    }
    // TO-DO: Calculate total numbers of occurrences
    fmt.Println("total occurrences:", total)
}

Before we go to the next stage, we need to figure out how goroutines communicate with each other. Golang provides a communication mechanism called “Channel” where goroutines can exchange data with others. Therefore, we can leverage Channel to collect outcomes from other goroutines like the code segment below. It takes whatever inputs from the channel(chan keyword) in and sums them up.

func sum(in <-chan int) int {
    total := 0
    for x := range in {
        total += x
    }
    return total
}

The last thing is to read files and count the total occurrences of the given phrase. In the third part of the code, you can find a function scanFile that takes three arguments to specify file path(fn), given phrase(phrase) and channel(out). So far, you probably have an idea what Channel here is used for? In order to communicate to other entities or goroutines, we need to send out messages to the channel. There is one tiny but very important thing to mention here which is the <- symbol found on the right of the chan keyword. It indicates a write-only channel where you can only send messages to it. On the contrary, if the <- symbol is found on the left side of the chan keyword, then it denotes that the channel can only be used for reading only like we did with the function sum. In the following code segment, we read all the words from the given file and count the numbers of occurrences of the given phrase. The total occurrences count will be sent to the out channel which indicates the in channel in function sum.

func scanFile(fn, phrase string, out chan<- int) {
    f, err := os.Open(fn)
    if err != nil {
        fmt.Println(err)
        return
    }
    defer f.Close()
    scanner := bufio.NewScanner(f)
    scanner.Split(bufio.ScanWords)
    count := 0
    for scanner.Scan() {
        if phrase == scanner.Text() {
            count++
        }
    }
    fmt.Println("file:", f.Name(), ", occurrences:", count)
    // send to the channel
    out <- count
    if err := scanner.Err(); err != nil {
        fmt.Println(err)
        return
    }
}

Now, we can connect all the dots and finish our main function like the code snippet below. Basically, we finish most of the logic and it should work as expected. However, if we attempt to execute this program, we will get an error message like: fatal error: all goroutines are asleep - deadlock!. This is because we forgot to close the channel where the function sum was reading messages from and because of that, the program doesn't know when to stop reading messages from the channel and then causes a deadlock.

func main() {
    if len(os.Args) < 2 {
        fmt.Println("Need at least one phrase and file parameters!")
        return
    }
    phrase := os.Args[1]
    A := make(chan int)
    jobNumbers := len(os.Args) - 2
    for i := 2; i < len(os.Args); i++ {
        fn := os.Args[i]
        // Reads the file and finds the number of occurrences of a given phrase
        go scanFile(fn, phrase, A)
    }
    // Calculate total numbers of occurrences
    total := sum(A)
    fmt.Println("total occurrences:", total)
}

How do we resolve it and make sure that we close the channel properly when every goroutine finishes their jobs? It is worthwhile to mention that we cannot close a closed channel in golang, therefore, only the last goroutine which finishes its jobs can close the channel. Let’s imagine that channels are serving stations where we hold food and goroutines are the staff who serve the food. Let's say we would like to close the cafeteria, those serving stations need to be properly closed. Therefore, we have to assure that only the last person who finishes the serving can close the serving station, otherwise - hypothetically - others might not be able to serve food in the future.

Let's get back to the main function here below to see how we can refine it. We would need a counter which can be accessed by multiple goroutines, so that we could keep track of how many goroutines are still working and will need to use the channel. However, how do we manage states between goroutines without causing race conditions? Well, this is where sync/atomic comes in handy. We can setup a new variable ops and leverage the package atomic to control our state across goroutines and prevent race conditions.

var ops int32
func main() {
    if len(os.Args) < 2 {
        fmt.Println("Need at least one phrase and file parameters!")
        return
    }
    phrase := os.Args[1]
    A := make(chan int)
    jobNumbers := len(os.Args) - 2
    atomic.AddInt32(&ops, int32(jobNumbers)) // to keep track of total numbers of goroutines
    for i := 2; i < len(os.Args); i++ {
        fn := os.Args[i]
        // Reads the file and finds the number of occurrences of a given phrase
        go scanFile(fn, phrase, A)
    }
    // Calculate total numbers of occurrences
    total := sum(A)
    fmt.Println("total occurrences:", total)
}

The last part of the scanFile function is as follows:

func scanFile(fn, phrase string, out chan<- int) {
    defer func() {
        atomic.AddInt32(&ops, -1)
        if atomic.LoadInt32(&ops) == 0 {
            close(out)
            return
        }
    }()
    f, err := os.Open(fn)
    if err != nil {
        fmt.Println(err)
        return
    }
    defer f.Close()
    scanner := bufio.NewScanner(f)
    scanner.Split(bufio.ScanWords)
    count := 0
    for scanner.Scan() {
        if phrase == scanner.Text() {
            count++
        }
    }
    fmt.Println("file:", f.Name(), ", occurrences:", count)
    // send to the channel
    out <- count
    if err := scanner.Err(); err != nil {
        fmt.Println(err)
        return
    }
}

Here we add an anonymous function to manage the counter ops we mentioned previously. Basically, what it does is to check whether it can close the channel or not after decreasing ops by 1. Furthermore, use the defer keyword to make sure that each goroutine will remember to manage the counter when it finishes its jobs, so we can keep ops in-sync across goroutines. As a result, only the last goroutine to finish can scan the document and close the channel.

The source code for this tutorial is available here

Thank you for reading this article.

According to Wikipedia:

“Solidity is an object-oriented programming language for implementing smart contracts on various blockchain platforms, most notably, Ethereum. It was developed by Christian Reitwiessner, Alex Beregszaszi, and several former Ethereum core contributors. Programs in Solidity run on Ethereum Virtual Machine.”

I was drawn to this technology where we can write a piece of immutable code that can be executed automatically without any middleman involved. To put it simply, we don’t have to worry about whether we can trust a centralised authority to claim that the services or software they provide are legit or verified. This kind of trustless characteristic is the core notion of blockchain where smart contracts are stored and run.

Now, we know smart contracts are programs where you can automate them to execute agreements when predefined criteria are met, therefore, we can get one step further to automate workflows that need to be done in our daily life. These could be things such as retrieving stock market reports when there are huge fluctuations in the market or tracking shipping when there are orders made. Essentially, almost everything that happens in the real world can be seen as contracts or agreements to achieve a certain goal under certain conditions like turning on lights when the sky gets dark. The only missing puzzle is how we convert these contracts to smart contracts in practical manners.

Unsigned Integers

Signed integral types (int) can represent both positive numbers and negative numbers, whereas Unsigned ones (uint) can only represent positive integers

Size of Integers

The default size of integers is 32 bytes, which can be declared as uint. Also, we can explicitly specify the size of integers by adding the trailing number of bits such as uint8 which can store in 8 bits allowing 256 combinations (0 through 255).

What if we try to store the result of some arithmetic that falls outside of the declared range? In other programming languages, like Golang, the software may panic and disable the action ( causing an exception in the program), but it's not the case in Solidity(before version 0.8). It will still be runnable without failing the action, but the result won’t be what we expected, it will roll over to the next digit it can represent or store.

Feel free to try the code snippet below and see if you can overflow or underflow integers.

pragma solidity >=0.6.0 <0.7.0;

contract Overflow {
    // value range : 0 ~ 255
    uint8 public balance;

    function maxTheBalance() public {
        balance = 2 ** 8 - 1;
    }

    // if the balance was 0, after decreasing it by 1, the balance will become 255
    function decrease() public {
        balance = balance - 1;
    }

    // if the balance was 255, after increasing it by 1, the balance will become 0
    function increase() public {
        balance = balance + 1;
    }
}

A good example we use every day

As long as you have coding experience you should be able to work with version control systems such as Git, which is a good example of event sourcing pattern. Every commit you push to Git is stored as an event representing a change state that can be added, edited or removed from files or code. This is the core concept of event sourcing where you can source back all the events that have happened in the past. As a result of this, we can revert the changes that have been made in the code from git whenever needed - Just like a time machine isn’t it ;)

The sooner you master Git the quicker it makes your life easier. It had my back a few times in my career and saved a lot of time :) I highly recommend git to those who want to work as a developer and spend some time cultivating it. I digress a little bit here. Let's talk about when to use event sourcing. It’s not a silver bullet that allows you to solve any problem, it really does add complexity to your system, so make sure you think through the goal you want to achieve that can be solved by it before adopting it.

Audit trails

The first scenario where you might use event sourcing is when you want full audit trails in your system, like in payment or banking. This is also the main reason why I use it in my work. We have various records and transactions including financial, accounting and medical that need to be tracked and verified.

Reporting

The second is reporting. With event sourcing you have much more insight into your data and you can report retrospectively. Just like data mining, where you extract meaningful information from a collection of data.

Parallel processing

The third scenario is parallel processing. Each microservice communicates via event messages, so they are loosely coupled without interdependence. Suppose you are looking for a highly scalable solution, this could potentially satisfy horizontal scalability and resilience to system failures.

Summary

We have gone through some use cases can be resolved by event sourcing such as audit trails, reporting or parallel processing. Are there other problems that can be solved with event sourcing? Tell me what you think and I hope this blog inspires you to explore solutions for your use cases.

Health informatics or medical informatics is the intersection of information science, computer science and health care. It deals with the resources, devices and methods required to optimize the acquisition, storage, retrieval and use of information in health and biomedicine.

You might be wondering why I didn’t choose computer science? Well…the truth was computer science was not the only thing that I was really into but also health care. I remember I asked my sister about what the tech guys did in the hospital because she worked there after graduating. I kept asking questions which were quite hard to answer, such as “how do the programs work to store the data in the database?” and “how do people upload their medical records to the system?”. What piqued my curiosity was how the doctors used information technology to examine the patients. Apparently, I didn’t get the answer from her in the end, because this wasn’t my sisters’ speciality, therefore I ended up finding the answer by myself.

To be honest, it wasn't an easy route to master both computer science and health care. Even though I had to pull many all-nighters or go through a lot of tough times, I still did it eventually and felt fulfilled and fruitful in the end.

At a later time, I didn't start my career in the hospital or healthcare industry, even though my expertise was in the health informatics area. The reason was that the technology in medical care was lagging behind. It was hard to grow quickly and to be able to learn a lot of sophisticated technology. It turns out the time I spent outside of the healthcare industry was worth it, I learned a lot about the full lifecycle of the software design process, including requirements definition, prototyping, proof of concept and object-oriented programming etc.

I feel like the knowledge I studied at school, more specifically an educational institution, was very different from the knowledge I learned in the corporation or open-source community. Institutionalized education normally provides a well-structured learning experience, so you do not only need to learn the courses you like but the courses you are not very into, not to mention the majority of the courses are about theory. However, the training you gain in the enterprise is mainly practical and work-related which I enjoyed most. I quite applaud the saying that, “the secret of learning is the desire to learn” - this is how you cultivate the skill, gain the ability and increase your knowledge. This was my journey towards becoming an excellent developer.

I hope you will find something useful through my journey and if you have any questions or feel that I kept something up my sleeve😉, feel free to email me or create issues here. I would love to share😄.

For most children, including me, the most exciting part of computers is using them to play video games. We did have some programming classes in school, besides, who cannot be attracted by those fancy and interesting gaming experiences? Those games transport us to new realities and satisfy our needs for achievement and recognition. These are how I started to immerse myself in the digital world.

After I built my own PC (well… technically I assembled it), I discovered that building computers was way more fun than the games I was playing on them. There is always an end to the game, but this is not the case when building your PC, which has nearly endless outcomes. By the way, I was not talking about the open-world games like Minecraft, which had not come out yet back then or at least very few of them.

I started to do all kinds of research about computers and the principles behind them. So I assisted people in building their PC and even became their consultant to practice what I have learned. This process made me realise that I am very into tech and want to become tech-savvy.

Next part would be to tell you about the rest of the journey🚀.

Cheers!

But the truth is people (at least in my experience) won’t always remember the username/password when needed. This can become a huge disaster.

Well, it’s time to build my:rocket: chrome extension called Clean Captain.

Before we jump in and get our hands dirty, we have to understand the pain point.

How to clear cookies without extension

I used to practice the following steps to clear cookies before I rolled out this extension, which turned out to be not so user-friendly.

1. Select the lock icon next to website URL in the Address bar.

2. Click Cookies with numbers identified how many cookies in use.

3. Scroll down and locate the site that you'd like to clear the cookies.

4. Click Remove will only delete the cookies from the site you selected in the previous step.

Clean Captain

Clean Captain is a lightweight extension that enables you to remove the cookies from most websites that need cookies enabled to work properly. Protect your privacy and delete all activity from specifying websites. You can keep sessions or cookies from those websites you trust.

Where to get it

• Clean Captain from Chrome Web Store

• Loves to get your hands dirty, check out the Source Code

I hope you will find this guide useful and if you have any questions about how to create your chrome extensions, I'd be glad to answer them.

Cheers!