Tag: technology

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!

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.

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.

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” – 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]

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

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.

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.

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

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?

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.

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