Pend(ay eight)o

Yes, naming scheme machine broke. 

So, for the last time (at least here), what did I do today? Well, I started off today in a pretty normal fashion, I entered the office and got to work on statusbot. I left off yesterday trying to figure out how to run and test the application locally without having direct access to the Google Cloud services that it made use of, which I was able to figure out pretty quickly. It turns out that actually getting a decent amount of rest overnight does in fact make it easier for someone to solve problems in the morning. Who knew? But yes, statusbot — as of right now it’s not currently in a deployable state, which to me seems like a failure, however it’s extremely close to being considered working, which is definitely a success to me. Honestly when starting this internship I didn’t really know that much about what I’d be working with, in that I had minimal experience with Go as a programming language, and I definitely didn’t have experience working with the services I got to work with. Even though I didn’t ultimately achieve the initial goals that I set out for myself, it seems like the people I worked with were satisfied with what I was able to accomplish, which is definitely great. Although, there’s still hope for statusbot! I’m actually returning to Pendo tomorrow after school in order to try and finish some things up, which might lead to me being able to deploy the bot!

jira

Probably what the logo for statusbot will look like. It’s just the Jira logo…

I mean even if I don’t actually get to deploy it tomorrow, I can still pretty much expect that the bot will be finished. One of the things that I did today was talk with Riley (the summer college intern) about continuing to work on the bot. As I mentioned yesterday, she will be the one to continue to work on what I’m leaving behind. So today we went through all of the code that I’ve written so far as well as how some of the APIs that statusbot uses are supposed to work, given that it’s honestly quite nonintuitive when starting to work on it. I’m definitely going to try and make sure that it’s as easy as possible for her to pick up where I left off, to further increase the possibility that the bot will survive and thrive. But that brings up another interesting problem that I probably should have seen coming earlier — I didn’t really document my code that well, to be honest. Granted, I don’t think it’s that hard to understand for the most part, and I did make sure to write comments for some of the weirder stuff that it’s doing, but there are still probably fewer comments than there should be. So because of that, one of my other objectives for tomorrow has become clearer — I should probably write some better documentation for what things should be doing.

the slowest build speed

Let’s just say that some of the cloud builds took… a while.

I know that it would normally make sense for the last post to be longer than the others, as it should be retrospective, but I really don’t have that much to say that I haven’t brought up in any of my other posts. I’ve definitely learned a lot about many development pipelines: I’ve worked with the tools that are professionally used (GAE, various APIs, etc), I’ve spent time working with the actual development team (scrum meetings, jirabot has exposed me to more of the workflow, the scrum demo showed me how different teams work), and I’ve spent time working on projects that I’ve enjoyed. Ultimately, I think that this has been a great experience and I’ve gotten a lot out of it. I’m glad that I got to work at Pendo, solve challenging issues, and work on fun projects. Thanks a lot!

~John

Instead of a large gopher image, have some open source gophers.

Pend(ay seven)o

The day I gave up on the title naming scheme

Ok, to cut straight to the chase this time — what did I do today? The quick and simple answer to that is that I spent a lot of my time continuing to work on improving statusbot and trying to add in as many features as possible before I have to go. The long answer? Well, that’s going to be quite interesting…

Pizza time

“Pizza time” – Spider-Man

So, at the start of the day, I was anticipating yet another perfectly normal workday. I’d come in, get my work station set up, boot up my computer, and find a new problem/feature to solve/implement. But then the first thing arose — the monthly(?) scrum demo session. I’ve had this on my work calendar for a while, but I definitely did not understand what it would be at first glance. I mean, what do you think a scrum demo session would be? Well, it turns out that it’s a pretty interesting event where all the various teams at Pendo (Ion Chefs is a team, for example), all get together and demo what they accomplished over the past sprint. So some of the teams had “physical” products to show such as improved analytical software, and some groups had slightly less tangible things to show, such as the Perf Serfs (another backend team focused on performance), which simply had “33% speedup of [something] for desktop clients”. Honestly the presentations let me more clearly see the difference between the Ion Chefs and other teams, given that the Ion Chefs operate on a Kanban system instead of scrum. The key difference was that the other teams all worked towards their own features to implement, however the Ion Chefs, in a similar way to the Perf Serfs, seem to work towards more arbitrary goals or scattered tasks that don’t really fit in other categories. Because of that, they have less physical products that can be shown, however they in turn can say that they directly touched a lot more of the code and implemented many fixes.

But moving on — the second obstacle of the day — project ownership migration. As all good things do, this temporary internship must come to an end. Because I have to leave on Friday, Pendo has to figure out what to do with the code that I’ve been working on. Obviously I can’t continue to work on it, and it’s pretty hard to just give it to someone already on a team and say to just continue working on it, so the obvious solution it to relegate it to a summer intern. And that’s where the next major challenge comes into play for me — remember how it took a while for me to actually get used to and fully understand the codebases that I’ve been working with? I now need to help make sure that it’s easy for Riley, the summer intern, to pick up where I’m leaving off and keep the ball rolling on the project. Interestingly enough, Riley actually was an intern for some time last year, so she already has some experience with the codebases that I’ve been working on — she originally implemented one of the commands that I had to reimplement for statusbot! But back to the project transition: my goals for tomorrow will be drastically different from what they’ve been in the past, as I’ll not only need to get as much done with statusbot as possible, but I’ll also need to make sure that Riley knows enough about the codebase to pick up smoothly from where I’ll be leaving off. But that’s all boring human stuff. I’m sure you’re here for the [TECHINCAL STUFF WARNING]

obfuscated code

Here’s literally everything I’ve written for statusbot, but obfuscated because I suck at screenshots and this definitely isn’t intentional.

So, what’s the issue of the day that I get to talk about? I mentioned this yesterday, but webhooks pretty much completely rely on JSON and HTTP POST requests. Now, when the parser you use to actually handle the inbound POST requests doesn’t like the data that it’s getting, your entire codebase usually hits the fan pretty hard. And, of course, the parser isn’t usually able to provide verbose information about whatever issue arises, so you end up only knowing that there was an error parsing payload. I mean, given all of that, what do you do? Well, I decided that in order to avoid the (on average) 4m deploy cycle to the Google Cloud in order to test the application, that it would be a pretty good idea to instead figure out how to locally host the application. But that in itself leads to even more issues — locally you don’t have access to the tokens that you need (except I fixed that before with the hidden JSON file), you don’t have access to the Appengine’s DataStore (so you don’t have the real testing data), and you definitely don’t have access to the internet, so you can’t even connect to the services you’re testing in thee first place. But, as it turns out, the solution to all of those were pretty easy — take the lazy route. I mean the only real issue that can’t be fixed by just sending hardcoding the solution is handling the inbound webhooks or outbound API calls.

So what’s the easiest solution to that problem? Pretending to be Slack/GitHub, of course. Basically when you run the application in a testing environment, it turns into a mini version of the cloud server that it’ll be deployed to and ultimately run on. That then means that you can actually still send requests to the application running in the local testing environment. So, how do you do that? A few jankily written scripts that are soon made defunct as soon as you remember that curl is able to make POST requests. But what I basically ended up doing was log all of the inbound packets to the cloud application, download and process them, and then send them to the local testing application. It’s definitely a (probably over)complicated solution to the problem, but it works. And that’s what software development is about, after all.

Some fun stats:

Preemptive end results of internship (if you care about stats):

  • Lines of code written (statusbot): ~1350
  • Lines of code debugged (in pankbot): ~950
  • Commits authored (total): ~20
  • Enjoyment (total): ∞
  • Words written for this entry: too many

~John

gopher

Pend(ay six)o

The day the naming scheme fell apart

You already know the drill — it’s time to answer the question nobody everybody has been waiting to have answered: what did I do today? I might as well start off by answering with the more human readable part before devolving into talking about the code project that I’ve been working on. So while at Pendo, I haven’t directly been working with the Ion Chefs (the dev team I’m with), however I have attended a significant number of their scrum (project management) meetings. Today was a slightly more special meeting than usual — it’s retrospective day! Basically that means that after the initial part of the meeting, where we go through all of the issues and features on Jira (project management software), we talk about what was accomplished during this most recent sprint (a two week period, considered to be a key unit when dealing with scrum). The retrospective meeting was divided into a few parts. First, our scrum master (god-emporer manager of the scrum software) laid out a few questions that people then brainstormed about:

  • What are you proud of?
  • Something I forgot and will hopefully remember before posting
  • What improvements can be made?

After brainstorming answers to each of the questions, the answers were then posted on a shared document for the team to view. From there, people normally would vote on the ones that were top priorities or most important, but since there were so few and we quickly reached a consensus on them, we just picked a few responses and ran with them. We took those responses and tried to figure out what could be done to either address the issue (if it was an issue), or keep up the good work. Just to get a feel for what the team culture as well as the intent of the exercise, one of the popular suggestions was to have a team vote every few weeks for who would best satisfy team decided “superlatives”. But that’s enough human stuff for now — it’s time for me to either a: spiral into insanity talking about the Go mascot or b: spend way too much time talking about something irrelevant. Let’s go with option b today.

[TECHNICAL STUFF WARNING, as is tradition]

So remember how I said that Pankbot was finally working up to specs yesterday, well it turns out that there might be a small issue with it that I completely missed… It does in fact work perfectly in the eyes of any user (and I think that someone actually mentioned that it was working well today on Slack 🙂 ) but the backend has a minor issue — it’s sending an extra HTTP 200 header over to Slack’s API endpoint. I spend a pretty decent amount of time looking over the code as well as the libraries before ultimately deciding that it’s not really worth trying to find a solution. I mean, if the users think it’s working perfectly, and it’s not throwing any substantial errors, then it’s going to be perfectly fine forever, right, right?

PNC Building

We ate at a BBQ place next to the PNC building for lunch today.

So what about the status of Statusbot? For the most part, the development of Statusbot has been going pretty smoothly — all the boilerplate is in place and the libraries as well as APIs that it’ll be using have been tested and confirmed to work. I spent the first half of today setting up the testing environment for it as well as writing some more unit tests, which should allow for me to rigorously test it without having to set up all of the APIs and deal with the permissions required to make it work properly. I think it’s not terrible practice to store API keys in a local JSON file that is .gitignored, but I’m honestly not sure. I mean, it’s not being sent up to GitHub or anything so all of the API keys are safe from being used by a non-me user ヽ( ̄~ ̄  )ノ.

After lunch, I consulted with mkj again to see what he wants implemented, which turned out to be pretty much what I was expecting. For the most part I’m migrating code from an older bot, Jinfo, which was used to fetch information from both Jira and GitHub to keep an eye on the production pipeline. I’ve been reimplementing commands from it which help with ensuring that that process works smoothly — the reimplementation is extremely important because it’s using API calls that are a few years old, meaning that it’s completely possible for some things to be deprecated, leaving this bot unable to function.

Github "Logo"

GitHub has kind of carried me through these projects, so it’s time for me to pay tribute to it. By drawing it’s logo!

I guess if you want to know about the technology in a bit more detail, read on. Basically the bot is using what are called “webhooks” to communicate with GitHub and receive messages whenever something happens. A webhook is a type of service that basically allows for a user to get another website, in this case GitHub, to HTTP POST JSON or other content to another service whenever an action occurs. They’re quite important for what Statusbot is supposed to be able to do because it needs to keep an eye on the status of actions that take place inside of the GitHub repo. But it turns out that webhooks contain a lot of information. Like it’s pretty hard for me to even quantify how much there is — I’ll just link to an example webhook payload. Yeah, that’s long. And I really don’t feel like writing code that will go through that and parse out the things that are needed. Oh yeah, did I mention that we are receiving 6 different types of those payloads? Obviously it’s a challenge, and as many things are in programming, the easiest solution is to download a library for it. So, thanks to the kind folks over at the Golang playground for providing a library that does it all for me.

But yeah, as I approach the thousandth word right now, I’m realizing I probably should wrap this up quickly. So as always, you’ll (maybe) see another one of these next time. In the meantime learn Go!

~John

the ceremonial Gopher

Pend(ay cinc)o

So yet again, I’m here to answer the question that’s definitely been on everybody’s mind — what did I do today? The short answer? I wrote a lot of code. The long answer? Well, that’s probably why you’re actually reading this.

[TECHNICAL STUFF WARNING] (you should probably be accustomed to it by this point)

Remember Pankbot? Well, the test workspace was finally set up, so I was able to test my changes and ensure that they didn’t break anything before they were moved onto the prod environment. I don’t actually think I’ve explained how most development pipelines work — I’ll quickly do that then. (This will be fairly Pendo specific, but a lot of other places do it this way as well) So pretty much every company uses something called version control (VCS), a piece of software that allows for users to, well, keep track of different versions of software. There are many flavours of VCS, but most companies use what is known as Git. So the actual Git software manages local repositories (codebases) on someone’s computer — that means that if you want to share the code with someone else, you have to use another service. That’s where websites like GitHub and GitLab come into play, basically they host a remote version of your git repository so that it can be accessed and manipulated from any computer. When a company makes software, they often want to make sure that it consistently works — if you’re making a bunch of changes and testing it, then there’s a pretty decent chance that it will not consistently work. Branches exist to make it easier to manage that — most repositories have a master branch as well as some kind of working branch. (I won’t go into too much detail here but basically you can move and ‘merge’ code between various branches) Basically, you keep the functional, (hopefully) bug-free codebase, prod(uction), in one branch, test and stage code to move it to prod in a another branch, and keep a working copy of the code in another branch. Pretty logical, right? I hope you took notes because I’m definitely going to go over this again later as it directly relates to the other project I’ve been working on.

A working Pankbot!

A working Pankbot.

But yeah, back to Pankbot. I spent a decent portion of last week working on it, and it was finally ready to be tested and be staged to be deployed onto the prod server. On Friday, one of my coworkers set up the testing environment, so today I finally got to run the code and see if it actually worked or not. Fun fact — it worked. I mean, to be fair, most of the changes I did were pretty small and were just small changes to the API calls being made, but I’m quite happy that it worked — I mean, jumping into an ~1500 line codebase and being told “hey there’s an issue somewhere in here” is pretty hard IMO. But after rigorously testing it to make sure that it passed expectations, I finally got to run the command to deploy it to prod, which is exactly where it’s sitting, idling, right now, just waiting for somebody to use it. Fun!

Because I can't take pictures.

So it turns out I’m bad at remembering to take photos. Have a street view photo of where the Ion Chefs ate.

In more human friendly news, two new interns joined our team today! Because they just arrived today, they got to do a lot of fun things, such as getting backpacks and other Pendo swag (wait i didn’t get anything) and have a Pendo funded lunch at a nice Italian restaurant next to our workplace (why not me ;(), but they also got to attend the super fun HR entry meeting (but i missed that. was it worth it?) I did get to talk to one of them at lunch, and it turns out that he’s actually from Utah, which I found to be really neat, as it’s quite cool that I’ve been able to work with people from all over the world. Thanks to Pendo for that! I also got to meet a former person from another FRC team, who made it to worlds a few years back. Sadly their team didn’t have the required funding to stay alive and died.

But on a more positive note! Statusbot! Thanks to the amazing nature of the open source community, I was able to quickly and efficiently find all of the libraries I’ll need to use to make Statusbot work! I started working on writing some prototype code to make sure I understand the API as well as test out some ideas that I’ve had. One of the things I’m using is GraphQL, but I see that I’m already well over the word limit again, so I’ll save that for next time. Until next time:

~John

The daily Gopher

Pend(ay f)o(ur)

snacks-1 Here’s the snack section on my floor of the building

In all honesty, today was quite uneventful compared to the other days — but that doesn’t mean that nothing was worked on. Today I actually started to work on a new Slack bot from the one I had been debugging — Statusbot. Because Statusbot is a completely new project, I had to spend some time setting up the codebase by implementing some of the required boilerplate code. For the most part I just reused a lot of the code from Pankbot, which I don’t think I’ve fully explained yet. Basically at Pendo there’s a tradition where people will give people “Panks” if they live up to one of the company’s core values. Originally the Panking system was implemented in a physical manner, as people had jars and custom poker chips so that all someone had to do was put a poker chip into someone else’s jar. However, probably because Pendo’s full of programmers, someone decided to reimplement the system as a Slack bot — and thus Pankbot was created. More recently during a hackathon, Stav decided to improve the existing bot so that it was more interactive and user friendly. So what I’ve been working with Pankbot has basically just been debugging the existing code and making sure that it performs up to specs properly.

dino-rawr Rawr — here’s a dinosaur to help fight product extinction!

Statusbot’s intended goal is to make it easier for people to understand where various build pipelines stand — there’s obviously a pretty big difference between the two in intended function. However, because they are both Slack bots, there’s a lot of code that can be reused between the two, such as functions allowing for it to send a receive messages. Basically the code that makes both bots do those basic features but still requires some kind of implementation is considered to be “boilerplate” code, and what I’ve been doing with Statusbot is implementing that code. I also spent some time writing what are called unit tests, which basically are ways to test and ensure that the “units” that make up a codebase are working properly. Another important thing that had to be reimplemented was the way in which the bot interacts with Google App Engine (GAE) — the platform it’s hosted on. I’m sparing some of the details here but Slack bots hosted on GAE are basically a type of web service that receives HTTP POST requests, process them internally, and then respond to the request over HTTP again. The data sent in the case of the bot I’m working on is encoded using JSON, which is a pretty simple format for storing and labeling data. I also worked on this with one of my aforementioned coworkers from Israel who is now in New York, Stav — today she worked on setting up the GAE test platform so that it would be easier to isolate the prod and testing environments.

snacks-2 Here’s part of one of the mini food prep areas that Pendo has.

Honestly I really enjoy working on this product, and I’ll probably continue to work on it through the weekend. In retrospect, I’ve learned a lot about a lot of things in the first week — I’ve learned about technologies like GAE and gotten experience with some APIs, I’ve learned more about project management, and I’ve learned a lot more about Pendo. But most importantly, I’ve learned that Go is definitely one of the best programming languages, and that I need to find a way to get one of those gophers. Until next time, when I might have an actual plan to get a gopher

~John

gopher

Pend(ay tr)o(i)

So, I heard that the people at SAS had M&Ms on Wednesday, that’s pretty cool. But you know what’s even cooler than that? Having access to M&Ms, chips, gummies, coffee, and multiple bowls of candy every day. But yeah, so it’s time to answer the daily question — what did I do today?

the battlestation

My desk soon to be battlestation needs a bit more RGB lighting. I’ll figure something out.

Well, as it seems that I’ve pretty much been given free reign to work on the Slack bot project at this point, I spent most of my time working on parts of it. To start off the day, I continued to work on debugging this one bot that’s been having some, um, interesting issues (to say the least).

A bit of background on Slack Bots [TECHNICAL STUFF AHEAD]

  • So Slack has what’s called a REST API which is driven using something similar to webhooks, meaning that for the bot to do anything, Slack’s servers have to send it a command.
  • That makes it pretty easy for the developers of the bots, as it turns out that Slack’s servers send a lot of useful information about any command issued.
  • One of the key features of Slack is the ability to enter a private channel with anybody in your workspace, or server, which no user should be able to enter.

Now, one of the things that the ‘bot’ I’m debugging is supposed to be able to do is enter and interact with people in private message rooms. Normally bots should automatically have that permission enabled by default, as they aren’t technically a user. Here’s the catch: the ‘bot’ that I’ve been debugging isn’t actually a bot — it’s a workspace app. There aren’t really that many differences in terms of what it can practically do in theory, however the tricky thing is that an app is actually given two ways to access Slack: one way that treats it like a bot and one that treats it like a user. Now the thing is that the bot has been using both methods, meaning that sometimes it’s able to enter private channels and do things, and sometimes it isn’t. So basically what I had to do was figure out why that was the case. I mean, evidently I figured something out given I was able to explain the problem, so I implemented a pretty simple solution — just make it behave like a bot. I’ll save you from the technical details (ignoring the rest of pretty much every other blog post I’ve made), but I just had to unify all the methods sending data to Slack and make sure they were using JSON to be treated as a bot. Interestingly enough, I actually traced the issue back to an upstream library, meaning that it wasn’t really the fault of whoever wrote the bot originally (who I’ll talk about in a bit), but it was partially an issue caused by something someone else wrote and pushed into a reputable lib. Assuming I interpreted the problem correctly, I might end up writing a fix for that particular piece of (non-Pendo) open source software, meaning that it could impact hundreds of other users and companies. Yay open source software! But yeah, even though I did a lot of that on my own, I still had help from someone at Pendo — Stav. Stav’s an employee that used to work from the Pendo location in Israel, but she moved to New York to another Pendo location. So, for the most part, I’ve been communicating with her online. I’ve found the whole online communication of Pendo really interesting, in that it seems to be that most employees communicate through Slack, which makes sense given the startup nature and spread of the company.

programmer street cred

Here’s some programmer street cred. I might need to set up a GitHub organization for the robotics team to increase my quantity of it.

But just to cover a few other things that I did throughout the day:

  • I attended the daily stand up meeting, presenting what I did and learning more about the company in the process
  • Pendo had a community lunch event which I attended, where they had a sort of ‘make your own’ food bowl type thing. IMO it was pretty good food
  • I worked a bit with Google App Engine while searching through log files for potential bugs. I’ll probably look into dumping some of my money into that as it seems like a good product
  • I used Golang and have continued to increase my obsession with Go

If anybody is willing to spot me some money to buy a stuffed gopher, please give me money. I really want one now, and it looks like a lot of people have them at Pendo. But yeah, for real I would love to get one of these. I almost forgot to mention this, but my supervisor mentioned that he’d be able to tell if the internship was successful if I was persuaded to use Go in the future. Let’s just say that that target has been met pretty early.

~John

go-meme pt1

Pend(ay tw)o

Skyline Here, have a photo of questionable quality taken from where I sit. You can probably see me in the reflection.

So, yet again, it’s time for me to answer the most important of questions — what did I do today? Well, in my opinion today was a lot more straightforwards compared to yesterday. I started off by continuing to review the code that I was assigned to look at yesterday while waiting for the most important part of the day — the stand up meeting. Actually, I’m kidding about that. Stand up meetings are an essential part of the scrum/really any project management system that are, if anything, supposed to be as unobtrusive as possible. Or so people say; from my experience in robotics and from what I’ve seen at Pendo that’s not really the case. Nevertheless, they’re a pretty great way for people (specifically me) to see what people are up to and what they’ll be working on throughout the day. It also seems like it’s a great time for the people on each team (I think I mentioned I’m with the Ion Chefs, a fellow group of geeks backend engineers).

I swear this isn't filler I swear this isn’t a filler image

But again, that wasn’t really the most interesting part of the day for me. Today just happened to be the day of a Town Hall at Pendo, which is an event that’s pretty similar to the ones that we have at CA. Basically a few representatives of the company got up and talked about the company for a while in a very transparent (that’s one of Pendo’s core values~!) way. There was this one segment where people were basically able to submit any question to the CEO (Todd) and have it answered, which led to some candid answers that surprised me. Overall, I think the Town Hall was a pretty neat experience that I got to be a part of, as it let me learn more about how the company operates.

[TECHNICAL STUFF WARNING AGAIN]

So for the rest of the day I continued to work on one of Pendo’s Slack bots, affectionately called Pankbot, which is designed to let people give commendations to people. For the most part I spent my time tracking down and trying to fix various bugs in the existing software, including this one input sanitization problem. Personally I think that working with this codebase has been quite enjoyable in that some of the code has been pretty difficult for me to understand. The scope and size of the codebase is probably the root cause of that, as for the most part I only work with things that are usually less than 1.5k lines. To be fair, this one is around that size, but I don’t have that much experience in the language it’s written in, Go (one trick Python user here…). Either way, I think I really like Go as a language, and I might have onset symptoms of an unhealthy obsession with the Gopher (which I still don’t know the official name of). Welp, that’s it for now. Until next time — have a Gopher as my obsession with Go grows.

~John

The Golang Gopher and my spiral into insanity

Pend(ay)o(ne)

Pendo @Raleigh

So, today was my first day at Pendo, a tech startup located in Raleigh. And (hopefully) this post will answer the most essential of questions — what did I do?

[TECHNICAL STUFF INBOUND]

So, I started off the day by talking with my supervisor and some people on the team I’ll be working with (the Ion Chefs, they do backend stuff) about my project — a slackbot which will help streamline announcements for a build pipeline. The very first thing that as a part of that was look into the libraries that it will use, which are intended to communicate with a tool called Jira, using the language Go. Side note: I found it hilarious that most of the libraries are called something like Go-Jira, which just happens to be the word that Jira is derived from (Godzilla in Japanese) in the first place.

Go-Jira!

After that, I got to attend part of my team’s scrum stand up meeting, where I was not only introduced to the people on it, but I was also introduced to all of the bugs that they had. We took a lunch break and went to a nearby deli in downtown Raleigh, which I personally really enjoyed. I think it was called Manhattan Cafe or something like that?

Well, once I returned back to Pendo’s office, I got to start working on the first part of my project — installing Linux onto my machine. How difficult. You see, the thing is that programmers are highly opinionated about operating systems and IDEs. One wrong choice and you might have ruined any chance you had of being respected by them. Luckily, I think I avoided the most common pitfalls and did not say that nano was the best editor, so I should be safe. (we all know that it’s actually echo 'code' > tmp.go && go build tmp.go :wink:)

After finishing up my nice new copy of Fedora (a Linux distro), I finally had access to the start of the codebase that I’ll be working on. Honestly, right now I should really be reading over it to fully understand what I’ll be working on. I’m definitely excited to see what challenges and successes I’ll have throughout the next two weeks as I work on the project. That’s all for now; until next time.

Skip to toolbar