Discovering (Re-discovering) Computer Science

Hi again and welcome back to my blog. If this is your first time here, my name is Anthony. I like to talk about different technologies, projects, and for the first time in this blog, my experience finding Computer Science. 

This will be part one of a two-part series (much like the Slack series). And don’t worry, it’s not another super technical post. Even the best of us need a little break from just reading about how to create X with Y technology. Here, I will be talking about my background and what led me to Oregon State’s Post-Bacc Computer Science program. In the second part, I will be discussing my experience at OSU and what helped me improve and overcome the feeling of not knowing what you are really doing (imposter syndrome). 

My Background

There’s a lot to my background as I would guess is the case with most people. I was born in Lima, Peru and immigrated with my mother at age 6. I lived in Miami, Florida for a few years, but mainly grew up in a small town called Rancho Cucamonga within Southern California. Life in Rancho was very similar to any other stereotypical suburban town, yet I still hold my upbringing close to my heart and find myself reminiscing about the small gems in the city. But anywho, growing up I was never really interested in computer science or even computer science adjacent topics. You usually hear about how some of the brightest software engineers were coding by the age of 11 or something like that (yes, like Elon). Funny enough, I was quite the opposite. I got pretty frustrated every time I used my desktop because it was really slow and thought that it was not something I would ever find myself using everyday. I even remember timing my computer to see how fast it would load something. So, yeah, I was definitely not naturally attracted to the field, however, life seems to have had other plans in mind. 

Java by Unsplash

Highschool Days

Fast-forward to senior year in highschool and I found myself taking this new class called AP Computer Science because some of my best friends wanted to take another AP class for college admissions (real go-getters). In this class, I was introduced to the Java programming language. Let me tell you, this class felt like it was another foreign language course for me. The first few lessons were okay, but as it advanced and we began learning object oriented programming, I began to struggle. Coupled with the fact that it was my senior year and I was in the middle of sending out college apps, doing sports, and working part-time, I just about gave up on the course. I ended up getting like an A- or something in the course, but I knew that there was NO way that I would be pursuing this topic as a major in college the following year. 

UCSD-Geisel Library by UCSD Political Science Dept.

Bachelor’s Degree 1.0

The following year, I enrolled at the University of California, San Diego and majored in Physics. Yep, physics. Why physics? I had always been into different areas of physics growing up whether it be reading books like The Elegant Universe or Michio Kaku’s newest book. That year I found myself having a difficult time keeping up with my classmates in the Honors track for Physics. I also spent most of my time in the library trying to maintain a good enough grade for graduate school. Towards the middle of my second year, I realized that this was not the life I wanted to lead. I wanted to live my life.

That quarter I took a break by taking some social science classes (part of my college requirement). One of the classes was a class on power and justice. Learning about the power structures in different organizations and how life was influenced by such institutions piqued my interest. I took additional courses in Political Science and by the end of my sophomore year, I decided to change majors. Fast forwarding again to the end of my senior year, I decided to study abroad in Paris at one of the best Political Science schools in the world: Sciences Po. I had the idea of going to law school and took courses in contracts law and behavioral politics while applying to law school. Aaaand, I got into a few law schools with pretty massive scholarships. However, my time in Paris made me realize that law school wasn’t something I was truly passionate about. 

OSU by
Sciences Po by Sciences Po


Post-Grad Life and Direction

After the realization, I scrambled to find a new job and luckily was able to find a position at a consulting firm in San Francisco. Surprisingly the hours were okay, but the job was mundane at best. I kept remembering how much of a challenge physics was and almost missed the feeling of being challenged. This feeling grew more as I spent time hanging out with my friends that worked in the Tech industry as software engineers and always heard about what they were working on. I was getting the scoop on how their teams contributed to their company mission and almost always it had a direct impact on people. That was it. I wanted to be challenged in my work and be able to work on things that could directly impact people. It was both my experience during my stint in physics and my interest in understanding institutional impact on society while studying political science that made me realize that I should look into Software Engineering. 

Leap of Faith

Shortly after, I found myself taking MOOC courses in SQL and Python and really enjoying it. I realized that if I wanted to really make this career switch, I’d have to look at all avenues on how to achieve just that. I researched on how to make the switch and read a lot on other people’s experience coming from an untraditional background. From what I gathered, there are 3 main paths: self-taught, bootcamps, and college. The bootcamp route seemed like the shortest path to the career I wanted, however I realized that my goal was not to just land a job. I wanted to really dive into computer science. I wanted to learn broadly so I could learn in depth. My decision to pursue a 2nd bachelors at Oregon State was mainly because I wanted to be able to learn the fundamentals in computer science while not having to move cities/states. 

There you have it! That’s my origin story 🙂 

Slack Development: Part 2

This is part 2 of creating a Slack app! Here I will be discussing how to set up a Bolt for Javascript backend with Node.js and what steps are necessary for your app to receive events and respond back to them. This again will serve as a compressed version of existing documentation and as a way to better explain certain topics. 

If you have not read part 1 of this series, feel free to take a look at that first and then come back here to continue the journey! If you’re familiar with creating a Slack app and just need a refresher for how to set up the server, then come along for the ride! 

What is Bolt? 

Our definition here will be the definition found in the Bolt for Javascript documentation. Bolt is a Javascript framework that allows the user to build Slack apps with the latest platform features.

So what does this mean for us? It means that Bolt allows us to create a Slack app that listens to the “slack/events” endpoint to get all incoming requests. This is important because when we set up request URLs for our events, we should set it to end in “slack/events”. So when we do an action in the app and the action fires off an event, that event request is sent to the request URL that we set it to. Our app will be able to receive that request, and as a result we will be able to respond to it. 

Now that we know this, we also want to know what type of events we will have access to. Well we will be describing this in the “How to subscribe to events” section, but for now let’s get our backend set up. 

Steps to get set up:

We start off with installing Node as shown here

Next we will do an npm init and create our app. 

We can install Bolt with:

Npm install @slack/bolt

We will then take the example code from the documentation: 

const { App } = require('@slack/bolt');
const app = new App({
signingSecret: process.env.SLACK_SIGNING_SECRET,
token: process.env.SLACK_BOT_TOKEN,
/* Add functionality here */
// start the app
await app.start(process.env.PORT || 3000);
console.log('⚡️ Bolt app is running!');
async () => {
/ Start the app
 await app.start(process.env.PORT || 3000);
console.log('⚡️ Bolt app is running!');

Now we will create an env file to store our environment variables which in this case are the signing secret and bot token. We can go back to our app’s management page and get these from the Basic Information page and OAuth & Permissions page, respectively. 

With those two parts stored, we can now start our app by running:

node [app_name]

But, now that we have a working app, how do we make it communicate with Slack? Our app is currently running locally, so we will need a tunnel such as ngrok to be available to share the app publicly. Here is the link to download it or we can just do npm install ngrok in the command line. 

When installed, we can create a tunnel by running on your terminal:

./ngrok http [custom_port_number]

Source: tunneling with Ngrok (

Then we can use the response url given in our next step “how to subscribe to events”. 

How to subscribe to events: 

We currently have a running app, so now we want to add some functionality to it. 

As I previously mentioned, our app is able to listen to any event requests and with this information, we can now take a look at the various event types that are available within a Slack app, here

After taking a look, we can enable event subscription by heading over to our app management page and clicking on “Event Subscriptions”. 

When we get there, we will toggle the switch and we will see the following: 

We can enter our ngrok response URL and concatenate “/slack/events” for all our subscribed event requests to be sent over to the URL we just input. 

Since we know our app listens to any event types with the request url ending in “slack/events”, then we know our app will now be listening to the events we just subscribed to. 

How to respond to events: 

Now that we have subscribed to events, we want our app to not only listen to the request but also be able to respond to them. Here we will go over a single event type and will provide links to API docs for the others. This is due to the large number of events and the subtle but important differences that come with every one of them. 

Anyways, we will now jump into responding to the “‘app_home_opened” event, which is the most used event type. This event type fires off a request every time a user navigates to either the home, about, or message tabs. I will provide the structure and then explain them one by one. 


app.event('app_home_opened', async ({ event, client, context }) => {
  try {
    /* view.publish is the method that your app uses to push a view to the Home tab */
    const result = await client.views.publish({

      /* the user that opened your app's app home */
      user_id: event.user,

      /* the view object that appears in the app home*/
      view: {
        type: 'home',
        callback_id: 'home_view',

        /* body of the view */
        blocks: [
            "type": "section",
            "text": {
              "type": "mrkdwn",
              "text": "*Welcome to your _App's Home_* :tada:"
            "type": "divider"
            "type": "section",
            "text": {
              "type": "mrkdwn",
              "text": "This button won't do much for now but you can set up a listener for it using the `actions()` method and passing its unique `action_id`. See an example in the `examples` folder within your Bolt app."
            "type": "actions",
            "elements": [
                "type": "button",
                "text": {
                  "type": "plain_text",
                  "text": "Click me!"
  catch (error) {

The first thing you see is the app.event(), this means that our application is listening for events instead of, for example, app.command() which listens to commands. 

Then in the first parameter position we see “app_home_opened”, which is the type of event that it is.

In the second position we see async({event, client, context})=>{}); which is an async function that describes what will happen as a response to the app event type. Inside the JSON object within the async function, we see three variables: event, client, context. Event will hold the attributes type (specific name of event), event_ts (event timestamp), user (user ID of user that created this action), ts (timestamp of what the event describes), and item (data specific to the underlying object type being described). Usually, you will only care about the user here, but feel free to read up more on “event”: here. The client is the web api client which serves as a way for us to publish new content or to respond to someone in a group message, etc. The context here is the event context. 

In the example above, the user is using the client to publish a new view and then grabs the user id. Inside the view, the user uses Slack blocks to create the UI for the view. We can see that in this case, context is not used so it can be left out. This is also true of event, since the user never utilizes the user id grabbed from event. 

As you can tell, with any event, we will receive a certain set of parameters that we will use inside our response. Here is a list of parameters and descriptions of each. 


To summarize the above, we can use Bolt for Javascript to make our app be able to listen and respond to events. To do this we install node, @slack/bolt, and ngrok. We use ngrok as a way for our app to be publicly shared so Slack’s event requests can get to our app. We subscribe to events by going to our app management then heading over to Event Subscriptions and toggling Enable App Events. After this, we can input our ngrok url + “/slack/events” so that our app knows to send the event requests to this URL. We scroll down and pick the events we want to subscribe to. Finally, we can respond to the requests inside our app. We see that the structure will be “app.event([event_type], async({param1, param2, param3,..,etc} =>{ functionality and response});”. Inside functionality, we can create new views, update views, message someone back, and a plethora of other actions. 

What’s next?

This will conclude my series on getting a Slack app up and running. At this point, you can create any functionality needed by understanding what each event type will send in each request fired to your app. Additionally, you can learn more about different requests like actions, commands, etc and use these to make your app more dynamic, however all of these are similar in nature and explaining these will become redundant. 

I hope you all have liked this series and learned more than things listed in the documentation given by Slack. I will be updating these two parts at some point, but for the meantime, I will be exploring different topics in this blog. See you all soon! 

Slack Development: The Journey

This will be part 1 of my Slack Journey where I will be covering the following:

  • Background with Slack 

  • How to set up a Slack app

  • How to enable home tab and slash commands

  • How to distribute the app so that the app shows in the app directory

  • How to add long descriptions for the app in the about page and app directory
  • What is Slack?

    If you’ve made it to this post then that means you know what Slack is! Well, I hope at least. However if you don’t, then here is a refresher straight from the source: Slack is a proprietary business communications platform owned by Salesforce. 

    If you’re like me, you would ask well then what is a business communications platform and how is this different from a regular communications platform like Discord or Facebook Messenger? 

    Well, Slack is more focused on organizations than communities. For example, there exists pricing tiers where organizations have access to more tooling that allows administrators to provision users and handle security aspects of your organization’s configuration. 

    If all that did not make sense and you do not know what Slack is yet, here is more information that will help you understand: click me!  


    Now that you are back (if you left to read about the joys of Slack), I want to give a little background about my experience with Slack app development. 

    This past summer, I was a full-stack software engineer intern at Salesforce and became a Slack certified developer. My main intern project was to create a Slack app that would be able to integrate a natural language processing (NLP) chat bot, and have all the functionalities that the bot would provide the user. 

    So now that you know my background let’s jump straight into getting up and running with building a Slack App!

    What do we want

    For this part of the journey, we will follow this guide a bit but will diverge from it as we get deeper and deeper into the subject. Some things are bound to be the same regardless of how you want to get started and this is one of them! However, I hope that my explanations and descriptions help you better understand how to do these steps. I know I needed something like this when following the guide! 

    Our goal is an app that has a Home page, About page, Messages page, and an App Directory page. We want an enabled home page. In the about page, we want a long description of what the app is and also slash commands enabled (shortcuts for functions). In the messages page, we want to be able to send messages to users (need scope). In the app directory, we want images for our app and a long description of our app.

    Create an App

    The next step is to click on “create an app” and fill out your app name and pick the workspace you want your app on. 

    Credit: My own app (Slack)

    Your next step is to give your app the necessary scopes for it to do what you want it to do. In this case, we simply want to give it the ability to post to channels in your workspace so we go to OAuth & Permissions -> Bot Token Scopes -> Add an OAuth Scope -> Select chat:write. 

    Other scopes are also available depending on the situation. You can read more about them here

    Install Your App

    Go to OAuth & Permissions -> Select Install App -> Click Allow

    After this, you get redirected back to the OAuth & Permissions page. However, now you have a Bot User OAuth Access Token. This token is basically the installing user’s “okay” to all the requested scopes that your app asks during the OAuth flow (installation process). More on the OAuth flow here

    Enable App Home

    Since your app will use the home tab, you will need to enable App home in the App Management page.

    After this we can also enable slash commands by going to App Home -> Messages Tab -> check on “Allow users to send Slash commands and messages from the messages tab”. Slash commands are basically a shortcut to getting a response from your app in the messages tab. The slash commands are located in the about page and will look like the below: 

    Credit: My own app (Slack)
    Credit: GreetBot app inside CodePath Workspace

    When you click on the button, it will redirect you to the messages tab where you will have the option to add parameters to the command. These parameters help your backend understand what response to issue. Once you click on the arrow to send the message, your app will respond with the appropriate response indicated by your app’s backend. 

    Distribute App

    To be able to add long descriptions to the app’s about page and app directory page listing, we need to do a couple of things. The first is to check that there is no hard coded information like OAuth tokens in your app. We confirm this by going to Manage Distribution -> Share Your App with Other Workspaces -> Remove Hard Coded Information. 

    Second, we have to add an OAuth redirect URL. This allows other workspaces to authorize use of your app. Manage Distribution -> Share Your App with Other Workspaces -> Add OAuth Redirect URL. This URL will be where Slack sends the events your app subscribes to. Think of these events like the events in a web app such as “on click” or “on submit”. This URL will almost always come from your app’s backend. This will be the url that your app is hosted on. We add “/slack/events” to the URL because Bolt for Javascript listens to all incoming requests are this route. 

    Credit: My own app (Slack)

    Once we have that done, we can subscribe to events. We will be walking through this in the next part! 

    Finally, we can go to Manage Distribution -> click on Activate Public Distribution. 

    Now we can add long descriptions to the App directory page and About page. 

    Add Long Descriptions

    After the tsunami of steps in the previous section, I can safely assure you that this last section is probably the easiest and most satisfying. Looking back, I actually wish I had the previous section when creating my intern project. You’d be surprised how long it really takes to figure all these steps out (about 4 hours 🙂 ). 

    Onto the last step we go! Maneuver over to “Basic Information”->Display Information-> Long Description. Here we can add our app’s description. Below this, we can also add images to our app and other fun things.

    Wrapping it up (aka TLDR)

    I know what you’re probably thinking: “Anthony, this is way too much information all at once” aaaaand yes it is. At this point I have thrown terms like Access Token, OAuth flow, Bot Tokens, Scopes, and Slash commands at you and you might be wondering if you can even make an app in addition to all of these configuration steps. Well this is probably the most confusing part of creating an app. After this, you will mostly be trying to try different Slack APIs together to make sense of what you want your app to do. 

    Here is how all the concepts are tied together:

    We create an app by naming it and deciding where the app will live. Then, we need to give permission (scopes) to our app to be able to do things like post in a channel or send a user a DM. After, we install the app so that we can get an access token that indicates the user is okay with you taking the actions that you are allowed to do (scopes) in the app. We then move to adding more content to our app by enabling the home app and slash commands. We also want to subscribe to our app to any events that happen inside the app with a redirect URL. This URL is where your app is hosted. We also want to avoid security concerns so we remove any hard coded info. Moving on, we want our app to have a long nice description so we have to publicly distribute it. After enabling distribution, we can then add long descriptions to our about page and app directory page. 

    And, that’s it! You made it! Part 2 will be out next week. We will discuss setting up a Bolt JS backend and subscribing/responding to events.