Just a sec....

⯆

About Me

My name is Samuel Ingram, or Sam as most people call me, and I am a graduate of Purdue University with a Bachelors of Science in Computer Science with a Minor in Music. I absolutely love technology and music. Both fascinate me, and I always enjoy learning more about each subject.


The most effective way to summarize one of my main interests is by calling me a "tech enthusiast." From a very early age, I expressed interest in technology though the one way a young kid knows the best; I loved video games. My earliest memories consist of playing the Super Nintendo, Nintendo 64, and the GameCube. I would delve into the worlds of the video game characters and find strategies behind the levels and moves. An unexplained love grew in me for these games and the technology behind them, and I became interested in video game development and how people could create such games as a job. The allure of technology captured my interest and continued to grow in my mind.


Music has always played a big part in my life, and I have continued to get involved in any way that I can. I have played on multiple bands, and I also continue to expand my knowledge of other instruments in my own time. The current running list of instruments that I can play consists of the acoustic guitar, electric guitar, bass guitar, ukulele, trumpet, piano, and just a bit of drums. Most of the instruments that I play I have taken lessons for, but others like the ukulele, bass guitar, and drums I have all taught to myself using online resources. I have always enjoyed music, and I plan to continue learning more and more throughout my life.

My Start in Technology

To most people building a computer may sound like a drag, but to me building a computer sounds like a fun way to spend my afternoon. I never realized just how much fun I could have with technology until I received my laptop for one of my birthdays. From the moment that that laptop was in my possession, I gained a whole new world of technological possibilities and fun through PC games and the many other applications possible through a PC. It was not long after receiving my laptop that I built a desktop computer for gaming and general media production. My computer has served me well through the games offered and through the fun that I had building it. I knew then that computers were devices that I could have a plethora of fun with, and I knew that I wanted to go into the tech industry as a future job.


Even considering the amount of fun one may have on computers, they are not all fun and games. I quickly became interested in the different production capabilities of computers and how they could create such works as websites and videos. I delved into the depths of the internet and taught myself to code HTML, CSS, and JavaScript. I also picked up skills to edit videos and produce graphics in Photoshop. These skills provided me with small and rewarding jobs that popped up from time to time. I created multiple websites and edited many videos while even being paid for a few of them. Not only did computers provide me with a way to have fun, but they also provided me with a way to make some extra cash.


My Experiences and Projects

Salesforce San Francisco

Salesforce Indianapolis

Salesforce San Francisco

To many, the Bay Area is regarded as the epicenter of Computer Science in the modern day. Being in the industry, I knew that I had to get a taste of the place and the culture in the best way I knew how - through an internship. Having been at Salesforce Indianapolis the year prior, pursuing a return offer for San Francisco was the most straightforward way of realizing such a dream. Thankfully, Salesforce was more than happy to accomodate, and I gladly took the offer to join them for my final internship in the summer of 2019.


While at Salesforce, I joined a team on the Platform Cloud called the “PIES” team. This team owned a number of features on the Salesforce Core, but they were working on creating AWS private connection features while I was there. My project, however, was built on top of a feature that they owned call External Data Sources. In short, External Data Sources are various sources outside of Salesforce that customers can hook into Salesforce such that they can still use the Salesforce platform with this data without having to formally import it all. The code that my team had wrote handles all these hooks and connections to these sources. My project, the OData Tracer, was built on top of this as a tool for customers to investigate issues with their data sources. Some customers would file cases about the External Data Source feature not working properly, but upon further investigation, the problem was with the data source itself and not with any code that Salesforce wrote. The OData Tracer lets customers send various requests to these sources to see the responses and compare them again expected outputs. Once the Tracer is released, it should hopefully cut down on customer cases and make investigations much easier. The project ended up turning out very nice, and I was very happy to have a completed product that was ready to ship along with the rest of Salesforce’s 222 release.


This internship proved to be quite different than others due to the nature of working with Salesforce Core. The main part of the Salesforce code base is a large monolithic chunk of Java code that has many proprietary ways of doing things that cannot be Googled since Salesforce is the only company that works with it. This meant that many solutions required the expertise of those who were more experienced than me. As a whole, I felt that I wrote less code over the span of this internship, but I felt that I ultimately did more work than any of my others. The nature of working with such a code base meant that I had to initiate many conversations over implementation approaches and seek proper approval for a number of different changes. For instance, setting up the proper permissions for this project ended up taking much longer than expected since, on the surface, the permissions were just checkboxes for specific profiles, but underneath, it was much more complex since we had to plan out how to initialize this permission for the release and which profiles even had access in the first place. Coming up with a solution took multiple days with conversations inside and outside of the team with us even needing VP approval for a database script that we had wrote. In the end though, we came up with a great solution that everyone was happy with, and even though hardly any code had to be changed/written, it still took a significant effort from me and a few others on the team.


In the end, I could not be more happy with how my last internship turned out. Experiencing the area and culture of San Francisco was a blast, and the lessons I learned from my project will be incredibly valuable for me in my next steps as I go into full time employment. I am excited to see what the future holds, and I look forward to experiencing the life of a full time employee.

Salesforce Indianapolis

Interning at a big company is one thing, but interning at a big company where my code would be released on that company’s platform shortly after my internship is a whole different experience. Over the summer of 2018, I got to experience what it was like to work alongside a dedicated Agile team on a brand new project. Salesforce, the company in question, had extended me an offer to intern in my home state, and I could not refuse the opportunity to explore what Computer Science looked like closer to home.


At Salesforce, I functioned as a part of the team developing the Analytics app on the Marketing Cloud. It was a brand new project that had started a couple weeks after my arrival that utilized new and exciting technologies such as React.js, Node.js, Redux, and much more. I hardly knew any of these frameworks and technologies coming in, but I did know plain JavaScript and HTML/CSS. Using these as a starting point, I was able to quickly adapt with the help of my mentor and various others on the team. I had initially started on browser automation testing with Nightwatch, but soon moved on to more of a double role with creating React UI components and creating Unit, Regression, and Smoke tests with a combination of Nightwatch, Enzyme, Chai, and Mocha. Each sprint, I would pick up tickets from the backlog that I knew I could deliver quality work on in a reasonable time frame. Outside of my normal dev work, I helped out wherever I could. Sometimes this meant reviewing code from the engineers on my team, and other times it meant working with others on the team to help them close out their sprint work on time. I was proud to be working with the team that I was, and I was excited to be working on code that I knew was going to have a lasting impact well beyond my internship.


Outside of my team, I was able to take a lot away from my experience at Salesforce. I took full advantage of my situation by scheduling multiple coffee chats a week with employees from all over Salesforce, and I made it a point to take initiative on issues that were outside of my team. If an internal dependency we were using was not working properly, I would reach out to whoever was in charge of that and work something out. I worked with someone outside of our team to get our charting library properly implemented, and I also reached out to another person about an issue with Salesforce’s open source SLDS React library we were using. Through this, I was able to make an open source contribution (though it was a very small one) on a public repository and fix an issue that would have affected many users. It was important to me that I not just make an impact on my team, but on Salesforce as a whole.


All in all, I was very happy with my experience at Salesforce, and I will always hold the other companies that I apply to at a higher standard because of it. Being able to integrate myself with a full time team and kickstart a brand new application really gave me a hugely valuable experience. It taught me what it is like to truly care for the code that I write and to truly care for the people that I work with.

BoilerMake VI

Qualcomm

BoilerMake VI

Returning to BoilerMake after having placed first last year brought on a whole set of nerves and pressure to live up to a certain standard. There was no one person who really held this pressure on me, but I certainly felt the pressure from myself. The personal expectation from myself to create something of comparable quality to last year weighed upon me, but what better way to handle all that than to take the same approach of just trying to have fun? At the previous BoilerMake hackathon, my team took the approach of trying create something that we loved and would enjoy making. I very much enjoyed that school of thought the year before, and luckily my new team for BoilerMake VI, which consisted of one of the members from the previous year, decided to take a similar approach.


With this idea in mind, we decided to make a game yet again. A few high level design decisions really influenced this project though in comparison to what we came up with last time. With this new project, we wanted to make sure that many others could actually enjoy and play our game. Last year, the project that we made had some more obscure dependencies and had to be compiled together and played with two external controllers to get the full experience. To mitigate this with our new project, we decided to keep it to a simple two player game that anyone can play in their web browser against their friend. These guidelines transformed our idea into a tower building game in which two people compete to build the tallest tower while they both fire upon each other’s towers using cannons. The nature of this idea meant that it would be fast paced and enjoyable for anyone who would want to take a quick minute to sit down and play our game. This led to a great experience when it was time to demo the projects, but more on that later.


As for the more technical side of the project, it was a web app built out of mostly a bunch of JavaScript. The main game on the frontend used the HTML5 Canvas to display the graphics, and the backend of the project made use of Socket.io and the p2 physics engine powered by an Express server. I ended up touching most points of the code base, but much of my efforts were focussed on UI design and making the Canvas interactions work properly. As such, I ended up writing a good mix of HTML, CSS, and JavaScript. Most of the initial design and programming was rather straightforward after we had all our ideas laid out, so luckily we ended up having a decent amount of time to playtest the game and hone in on the elements that actually made it a fun and enjoyable experience.


Towards the end of the hackathon, it finally came time to present and have all of our projects judged. Many times, the judging period can be one of the most stressful points in the whole hackathon. All the blood, sweat, tears, and sleep deprivation that was poured into the project get judged in a short period of time, and the fate of the project lies in the hands of a few judges. Our experience, however, was quite a different one. The judging period turned out to be a whole lot of fun since we had an exciting game that got people to interact with each other and have fun. While demoing, we had the absolute joy of seeing the excitement on people’s faces as they played our game, and we even had a number of them come back to play our game again after they had seen other projects.


At the end of it all, we weren’t sure what to expect in terms of judging, but we knew we had something that we were proud of nonetheless. As fate would have it, though, we were notified that we were to present at the ending ceremony, and during the announcement of the final placings, we were told that our project had received second place! Thus, the story of BoilerMake VI had ended on a high note. My team and I put together a project that we loved, and despite focussing on having fun, I was still able to be a part of a project that had lived up to the personal expectations that I had put upon myself. I am incredibly grateful to my team and to the BoilerMake team who helped make the event so amazing once again, and I look forward to what the future holds in terms of me and BoilerMake!

Qualcomm

In the summer of 2017, I had the amazing opportunity to take part in Qualcomm’s summer intern program. I gained a ton of experience through it and really learned a lot about what exactly computer science entails outside of school. While working at Qualcomm I had the opportunity to actually apply my knowledge in a work environment, and that really helped solidify my passion for computer science.


Along the way I got to work with some great people and make some amazing friends. I worked directly with another intern, Kevin, on the same project, and I worked indirectly with five other interns who were also on the team. During the project Kevin and I mainly consulted with three other full time Qualcomm engineers to get a grasp on the existing code and what our project should exactly entail.


The project that Kevin and I worked on mainly consisted of a front end web interface for a server that controlled SIM card profiles. The project was an internal tool, but the Qualcomm engineers made sure to stress just how important this project would be for them to be able to test and debug various issues that come up. The front end was programmed using HTML, CSS, and Javascript, and we utilized Bootstrap for a lot of the layout and design work. The backend consisted of a lot of pre-existing Java code, but we had to add a lot to it to provide the various functions that we wanted to be run from the interface. By the end I was incredibly proud of what we put together and what we had accomplished in three months.


My experience as an intern at Qualcomm is one that I will never forget. I am incredibly grateful for the opportunity Qualcomm gave me to work with them, and I look forward to seeing what possibilities await me in the future!

BoilerMake V

Hello World

BoilerMake V

As a child, I loved video games and always dreamed of the day that I could call myself a game developer. BoilerMake V led to a realization of that dream in a way that I never would have imagined. My team and I constructed a game within thirty six hours and managed to take first place on the home turf of Purdue University at BoilerMake V.


The idea started off simple; why not just make something fun that we are passionate about rather than trying to go overboard and end up with a half baked idea? This led us to decide to make a video game. The concept that we came up with was that a player and his other three friends are all car valets. The objective of the game was for the player to park more cars than his friends while everyone sped around the parking lot and crashed into one another. The gameplay concept was meant to be fun and fast paced, and it turned out to be exactly that! Through some trial and error, we were able to put together the base game with some time to spare, so we went through and playtested everything and added features to really polish the game beyond its base layer.


A lot of pieces went into putting the game together, but in its simplest form, the game was built with Java using both LWJGL and dyn4j as the base layer game engine platforms. For my part, I worked mainly with the graphics of the game and also put together some of the logic behind the game objects and their interactions. Throughout the course of the hackathon, I mainly worked in tandem with one of the other teammates who had worked with a lot of graphics while the other two teammates worked on the lower level aspects such as physics and integrating controller support. Though there were a few headaches along the way, we managed to put together a project that were really proud of within the time given.


By the end of the hackathon, my team knew we put something truly special together, but I do not think any of us were expecting to take home first place in the competition. Despite the expectations, we were called to present on stage with two other teams and were declared to be the first place recipients shortly after. This whole event was really special to me and my team, and I am truly grateful to the Purdue Hackers for deeming our project so special. I am proud of what we managed to accomplish, and I look forward to what BoilerMake VI has in store for us in the future. While my interest in Computer Science has expanded beyond just game development, BoilerMake V was the realization to my childhood dream of creating a fun game in a rather unexpected and special way.



Hello World

Before coming to Purdue the concept of a hackathon was a daunting one to me, but little did I know that attending one would be one of the best programming experiences I would ever have. I mean, I had worked with other people before and was comfortable with what I knew, but coming up with an idea and successfully hashing it out in a little amount of time with people that I was unfamiliar with sounded a bit crazy to me. Nevertheless I was determined to sign up and make the most of this new experience.


Once I had arrived to the opening ceremony, I sat around for a while surveying the room and looking for anyone that looked even vaguely familiar that I could team up with. Before long Arun, one of the students in my lab section that I had talked to a few times, walked in and sat next to me. I thought that we could make a great team as I knew that he had experience in web development, so we quickly teamed up. Soon after the ceremony, we met another guy named Jarett who also knew a good deal about web development, so we all got together and decided that we would make a web application during the twenty-four hours of the hackathon.


The beginning was slow with us throwing ideas back and forth. We tried to find something fun, but at the same time difficult enough for us to be able to learn something. We had come up with a few good ideas, but we eventually settled on the idea of making a program inspired by Conway’s Game of Life. We wanted to stick to rules similar to the original, but with one major spin; we wanted to make the game board use hexagons instead of the usual squares.


After settling on an idea that we were all happy with, we immediately began researching and planning for how we were going to make everything actually work. Using hexagons provided a big technical problem for us because representing a grid of hexagons in code instead of a grid of squares isn’t very straightforward. Arun with some help from Jarett spearheaded the task and came up with a solution using some Javascript wizardry. I, on the other hand, took on the task of trying to represent everything happening in the code through a grid on the webpage. As it turns out, making a hexagonal grid graphically is also not so straightforward. After searching the web for some time, I ran across a bit of code that built a hexagonal grid through using a canvas element on a webpage. I had to heavily modify and add to the code to support all the different features that we wanted, but in the end it worked out better than I would have ever thought it would. After Arun had finished his code, Jarett mainly worked on writing game rules and all the logic and functions that would be needed to simulate the game correctly. We all worked a bit in each of the areas of the program.


As is normal with programming just about anything, we came across quite a few problems as we were developing certain features. Bugs would pop up from time to time, or someone would just get absolutely stuck on a certain problem. Problems were not met with anger or frustration, but rather, we just simply helped each other solve them no matter what they were. A few times the whole team had to go into full on debug mode just to smash some critical bugs, but when the solution was found, we all rejoiced and were filled with a new sense of determination to keep going. The greatest moment during the whole hackathon was when we finally got the program to work correctly for the first time. We had made the graph, wrote the code, and set the rules, but it still was not working properly. The wrong hexagons would be displayed on the graph, and the code at least did something but not what we expected it to do. After a good while of everyone troubleshooting and looking over the code, Jarett found that we were just sending the wrong parameters to the main code. The program suddenly worked as expected once Jarett had fixed the parameters. Our team was so excited to see it actually working! The moment just felt so magical to me for lack of better words.


In the end, I was incredibly proud of my team and the work that we had accomplished. Jarett and Arun turned out to be some of the best people that I have worked with, and I am incredibly glad to have worked with them. We took on a task that I was initially wondering if we could complete on time, but we finished the base program earlier than expected. I even got four hours of sleep that night, which may not sound like much, but comparatively to what others got, that was pretty good. I was initially a bit apprehensive about joining a hackathon, but I loved it and would certainly be open to joining another in the future.

The project that we made was a web application based off of Conway's Game of Life that uses hexagons rather than squares. Feel free to check out the Github repository or the final product. Mess around with different patterns and just see what happens!

Night-In

SwoleMate

Pictophone

Music in Games