WEEK 4: ENTRY 1

 At my internship today, I was tasked to restructure my code and deploy it to Gitlab. As part of my project, I will be querying Big Query, Google Cloud Platform, to generate a weekly report of certain logs. To make sure that I query from the Big Query, I must first of all establish connectivity to the Big Query API, which is the first step. Thus, the goal today was making sure that I was able to use the GET request that I learned last week and test it on a web server before creating the connectivity to the Big Query API. So too, I had to refactor my code so that I can only have one main to call and run all the different files and functions.  


Initially, I was running my code locally and printing to the Intellij terminal. I was also running each Go file independently. This was of course for testing but it was not great practice. I thought that by doing this, it would be easier to eventually call all these functions on my main.go file at last. But, it was quite a hassle today when I had to call these functions. I had two files: request.go and main.go. Just like how python files end with .py, Go programming files also end in .go. However, unlike python, where you would have to  import every function to another python file by using the keyword import,  go does a pretty great job with that differently. As a pythonista moving to Go, I carried the same ideology until I had to be reminded by my manager that Go does this in a more efficient manner. I spent almost two hours calling each function in the main.go file hoping that it would work, but it never did. In Go programming, one needs a directory that houses all the other program files, while the main.go file resides outside that directory. This way, the main.go would contain only one function, let’s say Execute(), which has all the calls of the functions in the app directory. Thus, all other files in the app directory will only contain code but the calling and executing happens in the main.go. I must confess that it was a very new concept and I had to struggle  with the function calls before my manager spotted it. 


Another insight I got today was how vital it is to continuously test and integrate to my Gitlab. I was busy coding my GET request function without continuously pushing and committing at successful intervals. I was so overwhelmed when I had to revert one of my commits  to a previous commit because a bug caused my most recent commit not to run correctly. Therefore, it is a lesson I learned and I intend to frequently push and commit code because that way when I have an unresolved bug fix, I can easily track which commit might have caused it, where the code was executing perfectly. . Basically today I learned how important it is to restructure my Go code and calling functions in Go in a more efficient manner. Thus, in the next days and weeks, I would be looking forward to applying this knowledge, while also paying attention to all the details I am given with regards to adhering to good coding practices.

Comments

Post a Comment

Popular posts from this blog

WEEK 4: ENTRY 3

  Today at my internship, I was assigned the issue of troubleshooting why my GET request Golang code is unable to generate the data from my http server. Since it was a combination of k8s deployment and Golang go, it was trickier and harder than I envisioned. The k8s was mainly used to orchestrate the objects that are needed to generate keytab from my pods. After several debugging: comparing and contrast the referred file I used as a source code coupled with looking up the errors on Stack flow (suggested me to delete my deployment and redeployed), I was still unable to fix the issue. Partly was because I did not understand what the error message was pointing at. Thus, I had to consult a member of the k8s team, who figured out that my deployment.yaml file was missing some configurations that needed to generate my key-tab. Simply, I needed the key-tab in order to be able to make the HTTP Get Request get my desired data.   Although the recommended solution from my consultation wor...
Read more

WEEK 6: ENTRY 3

  At my internship today, I continued unmarshalling the Json data I got back from Big Query API. Having tried replicating the data on the Go playground and using the Go unmarshall function yesterday, I did develop a better understanding of the json structure. I used Go’s struct to do the unmarshalling. Unlike the json data I got from my query, the documentation’s json data does not have any schema metadata and so I thought the same approach would not work. Little did I know that the schema data can be ignored when unmarshalling json data and that you can only concentrate on the part of the Json you want to unmarshall. When I consulted my buddy, he hopped on a zoom call with me and we did pair programming. I was the driver while he was the navigator, basically explaining what we were doing because he has more knowledge on Go and Json data manipulation. Working with him gave me more skills and confidence in what I was doing. He helped in not just using the Go struct, but also in tryi...
Read more

WEEK 7: ENTRY 1

  It sometimes feels like we are not good enough when our tries don’t work. Well at my internship today, I worked on resolving the json unmarshalling issue I was stuck with last Friday. After several back-and-forth consultations with my buddy and manager, I finally got a better understanding of how they wanted me to present the data. Basically, the data should be in a simple json array that could be manipulated easier. This is because as the json comes in key:pair format, I would need to extract all the keys and use those keys to send an HTTPS request to Elasticsearch Rest API.  Even though the approach was well defined and clear to me, I still struggled to implement it using the Golang Struct and Maps. One of the obstacles I had was because after unmarshalling the json data, the output was in a Golang interface type, which was not iterable like say a slice. A Golang slice is the equivalent  of a python array. Therefore, to overcome that barrier, I created an empty slice ...
Read more