Posts

Showing posts from August, 2022

Reflection Summary

 My summer internship as a summer analyst in the core engineering division for Goldman Sachs has been the most intense and motivational experience I have had as a student at Berea College. Having been part of the Foundational Infrastructure, FI, a team of the core engineering division, my project was solely backend - most specifically building a Syslog API to help my team troubleshoot and monitor the Linux hosts within the firm. In this paper, I will provide more details about what I worked on, my reactions to the different experiences I faced, some insights I got from these challenges, and how these insights will help me cope and change my approach to similar difficulties in the future.  From a project’s perspective, I was required to develop an API that accumulated the Syslog data of over 140K Linux host names across the firm. The primary purpose of the API is to enable my team to easily monitor and troubleshoot the Linux host issues whenever they occur. Among the tech tools...

WEEK 10: ENTRY 3

  At my internship today, I gave my final project presentation to the firm’s Unix Global Team. Prior to my presentation, I did practice my slides a couple of times that morning to get over the nervousness and get more familiar with the flow of my presentation. So too, I was informed that the presentation was going to be held on zoom, so I made some speakers notes so that it would  help me remember what to say when I present. From my previous powerpoint presentation,. I learned that slides work best when I don't cram too much information - especially too much text onto them.  Although the initial plan from the team was to present on zoom, it got changed 30 minutes before the scheduled time. The reason why this change was made was because unlike otherwise anticipated, all the employees in the Jersey City office that work in my team came into the office today. Usually only 15-20% of the team comes in on the same day to work. Therefore, I had to mentally prepare myself becaus...

WEEK 10: ENTRY 2

  At my internship today, I worked on finalizing my powerpoint presentation for my final Global Team presentation. For the powerpoint slides, I was supposed to follow the generic engineering slide template format. Therefore, I requested to have a look at the previous intern powerpoint slides so that I can have an idea on how to structure and outline my slides. After receiving the design template, I was surprised that it had little or no graphics. For me, the design template was not appealing and had less standardized colors and styles. As a result, I decided to incorporate more graphics and standardized colors to my slides.  Although I used the designed template I was handed, I tried to only include necessary information as well as used colors that contrast and complement each other. So too, I made sure that my powerpoint had a coherent flow of ideas. For instance, I made sure that with an introductory slide, an agenda slide, an overview of what my project is, the problem my p...

WEEK 10: ENTRY 1

  At my internship today, I worked on cleaning my code and handing off my project to my team. Having worked on this project for the past nine weeks, it felt so satisfying and fulfilling that I had the opportunity to finally meet the project deliverables and hand off my project. My code was not the best written code because it was the first time programming in Golang for me; however, now that I looked at how much logic and functionalities my codebase does, it is truly intriguing.   So what does it really mean for me when I say clean my code. Well, as I mentioned earlier, this was my first time programming in Golang. Therefore, I did have a lot of print statements for debugging. I integrated these print statements because they helped me to easily find bugs as well as know the stage of my logic. Another code refactoring I had to do was removed commented out chunks of code. Since these code was no more needed in my codebase, I had to get rid of them so that it’d be more organized ...

WEEK 9: ENTRY 3

At my internship today, I continued on completing the merging and outputting the final result on my server. Yesterday I was able to successfully compare the hostnames from the Elasticsearch API and Big Query API in the form of struct; however, I could not combine the two struct and transform the struct data type into a readable format, for instance Json. As a result, I spent my whole today resolving that issue. In simple terms, I have these two structs that I needed to merge after making the comparison and display the one merge data on my browser. To make sure the comparison I was making from yesterday was correct, I loop through the merge data and create a map. Maps are great choices because of its keys and values; however, it was not the best choice because my server is to display the final output into a json format and apparently using a struct makes that way more dynamic and easier. With a struct, I could easily convert the struct into a json format by unmarshalling it.  Althou...

WEEK 9: ENTRY 2

  Today at my internship, I worked on merging the two data outputs I got from Elasticsearch API and Big query API calls I made. Basically, both these chunks of data have metadata of the hostnames and the hostnames itself. So too, they are in all byte format and thus I would have to change their format before being able to merge them together. As I have worked previously with converting bytes into a human readable form, I would think that it would be easier with me this time around. However, it was the total opposite because my case total was not only to convert the data format, but also to merge them.  So what did it pan out? I was successful in making it work, but it took me longer and more difficult to implement the logic. Prior to my implementation, I wrote a pseudocode to make it easier to follow. The logic I created was to unmarshall these two data into structs so that I can access the common hostnames in each struct, check if they are the same. And when they are alike, I...

WEEK 9: ENTRY 1

  At my internship today, I continued working on resolving the query size limit that the olivere package poses. As I mentioned in one of my previous posts, the olivere elasticsearch package only returns 0-10 documents by default. This default of the size is an issue because my data pool is over hundred thousand of data. So too, the package does not allow a Bulk Https API request. Therefore, I had to come up with a solution to how to make multiple API calls and combine the chunks into one readable data structure. The idea is to break my hostname arrays into chunks and use each chunk to make the api call.  Although I had an idea of what I was supposed to do, I did not have any idea how to implement it in Go programming. Thus, I had to google it. After doing a couple of searches, I saw a similar logic on Stackoverflow, which gave me a better idea on how to implement the logic. As usual, I replicated a similar logic on the Go online IDE. Using the online IDE helps me troubleshoot ...