All About Programming

A Brief Introduction to Modern Cryptography

This semester, I took a class called Discrete Mathematics for Computer Science. We learned a variety of important concepts for mathematics and comp sci, including set theory, propositional logic, proofs, and trees. One interesting topic we covered was the RSA algorithm, the basis for modern cryptography. One part of our final project involved writing code to implement the RSA algorithm. In this blog post, I’ll attempt to explain how the RSA algorithm works, and how it keeps all of your passwords and credit card numbers and personal information safe.

Before jumping into the algorithm, it’s worth discussing why encryption is important. When you try to load a webpage, you send the URL you want to load off to the router, and after a surprisingly large number of hoops, you get back a response that your browser can display to you. When you log into a website, or enter your credit card information, that data has to be sent to the server to be processed. Without encryption, anyone on the same WiFi network as you could look at the data you’re exchanging with all of the websites you’re visiting. When you go to log in, a malicious actor could see you send your username and password, and then they can access your account with little effort. When your internet traffic is encrypted, the hacker could still know which websites you’re visiting, but the data you send would look like gibberish, and thus, the hacker couldn’t steal your information. The challenge is to create a system where your computer and the server you’re accessing can exchange information privately without a third party being able to know what information is being sent. Some sort of initial information has to be conveyed to establish the cryptosystem (the cryptographic function and any associated values), and this information cannot be encrypted. This is where prime numbers come in.

It may seem rather surprising, but the whole of modern cryptography is based on the assumption that it’s hard to factor numbers into a collection of prime numbers (ex. 12 = 2 * 2 * 3). If some could devise an algorithm or device that could easily perform prime factorizations, all of modern encryption would be broken in an instant. However, decades of research and proofs have shown that prime factorizations of large numbers take millions of years of computer time to compute, and so we are safe for now. Let’s look at how prime numbers are used by the RSA algorithm to encrypt and decrypt messages.

First, we will need two prime numbers, which we will call p and q. In everyday situations, p and q would be hundreds of digits long, but for the purposes of this explanation, we will choose small values for p and q, namely 43 and 59 respectively. Once we have these values, we compute n = p * q and k = (p – 1) * (q – 1). In this case, we get n = 2537 and k = 2436. As we will see soon, if a hacker could reverse the value of n to get the individual terms p and q, they could encrypt and decrypt any message in this cryptosystem. It is clear, then, that our choices of p and q are extremely insecure, because it would not take long for a computer to discover them from the given value of n (because n is so small). Although it may seem counterintuitive, when p and q are very large, it becomes infeasible to discover them them from their product n.

Next, we must computer two special numbers, the encryption number e and the decryption number d. To find e, we must find a number such that the greatest common divisor of e and k (which is (p – 1) * (q – 1)) is 1. In practical terms, e is a number that has no factors in common with k. To do this computation, we can use the Euclidean algorithm, an algorithm that efficiently computes the greatest common divisor of two numbers. To find values of e, we consider every number starting at 2 and compute the gcd of e and k. For many values, the gcd will be 0, meaning e is a factor of k. For example, if we compute gcd(2, 2436), we find that 2436 = 2 * 1218 + 0, and thus the remainder is 0. For some special values, we find the gcd to be 1. For example, if we compute gcd(5, 2436), we find that 2436 = 5 * 487 + 1, and thus there is a remainder of 1. This tells us that 5 is not a factor of 2436 (as is probably obvious from inspection), and thus it is a valid choice for e. For the purposes of this demonstration, we will choose e = 13, noting that the following chain of operations shows that gcd(13, 2436) = 1:

2436 = 13 * 187 + 5
13 = 5 * 2 + 3
5 = 3 * 1 + 2
3 = 2 * 1 + 1

Now that we have our encryption number e, we must find out decryption number d. This will be the inverse of e modulo k; that is, the number that, when multiplied by e, gives a remainder of 1 when divided by k. To find this number, we can use the extended Euclidean algorithm, which essentially works backwards from the Euclidean algorithm to find two coefficients such that, when the original numbers are multiplied by those coefficients and the results are added together, the sum is the gcd. I know this is probably confusing, but consider the following string of operations that essentially work backwards from the set of operations above:

1 = 1 * 3 + -1 * 2
1 = -1 * 5 + 2 * 3
1 = 2 * 13 + -5 * 5
1 = -5 * 2436 + 937 * 13

We have found our two coefficients, -5 and 937. We find that if we multiply 2436 (one of our original numbers) by -5, and 13 (the other original number) by 937, we get 1 (the gcd we found previously). Thus, we know that our decryption number is the coefficient for the smaller number, 937 in this case. Although this may be confusing, the math isn’t as important as the basic understanding that we now have a few key numbers that we can use for our encryption and decryption. If you are in my CAS class, this is what I was doing on the board on Wednesday morning.

Now that we have p, q, n, k, e, and d, we can construct two keys: a public key that we send to the client (n, e), and a private key that we keep on the server (n, d). The client, who knows n and e, and encrypt any message. The server, which knows n and d, can decrypt any message. But the client knowing e is not enough for it to find d, because finding d required knowing k, and to know k you must know p and q, and as we stated, it is computationally infeasible to extract p and q from n when n is sufficiently large (hundreds of digits). This is the key to RSA cryptography, and if nothing else makes sense, hopefully this will. The server transmits just enough information for the client to encrypt any message, but to figure out the decryption key, it would take millions of years of computer time.

Now, let’s encrypt the message STOP. To do so, we must first convert each letter to a number representation. We will use the numbers 00 through 25 to represent each letter, where 00 = A and 25 = Z. In this case, STOP becomes 18191415. The next step is to split the number up into a series of blocks of a certain length. The formula for calculating the length is unimportant, so it will suffice to say that the block length here is 4. Thus, we have two blocks: 1819 and 1415. We encrypt each block separately using the encryption function c = m^e (mod k) where c is the encrypted message and m is the numerical form we found. We can use an algorithm called fast modular exponentiation to quickly compute this value for large values, but in this case we will find that 1819 becomes 2081 and 1415 becomes 2182. Thus, our encrypted message is 20812182. We can send this message through potentially unsafe territory, because if we trust the basis of RSA cryptography, a hacker would have no hope of decrypting that message given just the values of the public key (n, e).

Now, let’s decrypt a message on the server side. Suppose the server has received the message 09810461. The first step is to split the input up into blocks. Again, we will find that the block length is 4, so we have two blocks: 0981 and 0461. For each block, we use the decryption function m = c^d (mod k) where c is the encrypted message and m is the unencrypted form. Again, we can use fast modular exponentiation to find that 0981 becomes 0704 and 0461 becomes 1115. Finally, we just convert each chunk of two numbers to its corresponding letter. We find that 07 becomes H, 04 becomes E, 11 becomes L, and 15 becomes P. Thus, the encrypted message turned out to be HELP.

This was just a brief (although not as brief as I wanted it to be) introduction to the underpinnings of modern cryptography. Although it can be confusing at first, it really just boils down to this: if you can figure out how to factor a huge number into a series of primes, you can destroy modern cryptography as we know it and plunge the world into chaos. Until then, we will trust in our prime numbers to keep our precious data safe.

Chordinate: Get Guitar Chords for your Spotify Music, Automagically

This past weekend, I had the opportunity to compete in Penn State’s hackathon, HackPSU, for the second time. Two friends and I worked over the course of 24 hours to build a web-based service from scratch. Because I love Spotify almost as much as I love Blu-rays, and because we used Spotify in our last hackathon project and loved the outcome, my team decided to use it again.

I’ve been playing the ukulele for about a year and the guitar for about 6 months, and every so often I love to grab an instrument and play along to my favorite music for an hour or two. I have a playlist on Spotify for my guitar and ukulele songs, and I usually put it on shuffle and play whatever comes on. I don’t have most of the songs memorized, so I have to look up the chords online. It can be kind of frustrating to sift through my bookmarks or Bing the chords (yes, I use Bing; maybe I should write a passion blog post on that…) and then have to restart the song. I had the idea of an automatic chord finder kicking around in my head for a few weeks, and when it came time to pick a project idea, that’s what we settled on.

The goal was to build a web-based service that would allow users to log in with their Spotify accounts, and then the website would automatically display chords for the currently-playing song. That’s exactly what we did. After struggling with Spotify’s authentication API (code that lets us communicate with Spotify’s services), my friend Will implemented the login function. Users could log in with their Spotify accounts and then we could poll Spotify to figure out what song they were currently listening to. Then, we used Ultimate Guitar’s API to search for the currently-playing song and grab the chords for guitar or ukulele. Finally, we display information about the currently-playing song, basic playback controls (pause/play, previous song, next song), and the chords. When the user changes song, the website is notified within a few seconds and it automatically updates all of the information. We named the service Chordinate, a play on chord and coordinate. I wish I could claim that I came up with the name, but the best I could think of was Spotichord (and I’m glad that we didn’t settle on that).

When it came time to demo, the service worked great! I selected a few songs that had good chords, but some people requested songs and, thanks to Ultimate Guitar’s large database, the chords were found without issue. I took my ukulele out in the crowded demo area and played for the judges as we explained our project. The feedback we got was very positive, especially from guitarists and ukulele players. Personally, I was happy that we managed to build a genuinely useful tool in just a few hours (we only ended up spending around 6 hours out of the 24 actually working on the project).

Last night, I decided to grab my ukulele and play some music, as I do every so often. After I put my ukulele playlist on shuffle, it occurred to me to use Chordinate; after all, it worked, and it solved an annoyance I had had for awhile. It worked, of course, and it was really cool. I didn’t have to spend time searching for chords anymore, I could just sit back and play and let Chordinate do the work. I enjoyed using Chordinate, and I’m excited to work on improving it over the summer. My main goal is to sync the chords with the music so that the current line and next line can show in big text, and the display can automatically update as the song plays. My plan is to allow users of the website to contribute timings by simply listening to a song and hitting the spacebar every time the line changes. Once one user syncs a song, everyone can access the data.

Unfortunately, those plans will have to wait a few weeks because I simply have too much going on right now. However, the current (fully-functional) version is available right now at chordinate.net. If you have a Spotify account (free or premium) and want to try it out, just head over and take a look. I might be biased, but I think it’s pretty cool.

The other side of the college application process

I absolutely hated the college application process. The essays were a pain, I felt like I was being forced to feign interest in a school to woo them into send me an offer of admission, and all of the college visits and tours I went on blurred together into one boring, painful mess. It’s no small wonder, then, that I decided to get involved in the other side of the college application process: giving tours.

I’ve been heavily involved in recruitment for the Schreyer Honors College since I began my time here at Penn State. A few times a month, I would sit on a panel at a prospective student presentation and answer questions from students and parents. These events were not terribly interactive, but it was nice to share my perspective with prospective students and give them an idea of what it’s like to be a student here.

Admissions decisions for Schreyer went out a few weeks ago, and since then, recruitment has been in full swing. Schreyer hosts a bunch of accepted student programs (ASPs), where accepted students and their families are invited to come to campus to learn about Schreyer and get a tour of Atherton Hall. That’s where I come in. For the past few weeks, I’ve volunteered to give tours to prospective students. The tours are pretty short; we discuss the amenities of Atherton hall (computer lab, Grandfather Clock Lounge, Career Services office, etc.) and look at a sample room and bathroom. I always add my own personal anecdotes and opinions to my tours, because my primary goal is to be genuine (if I hear one more tour guide yell “We Are!’–which nobody does outside of tours and football games–I might flip). Of course, I always leave myself open for questions, and try my best to answer any question that isn’t too personal.

So far, I’ve given a few tours to accepted students and a few tours to high school juniors and their families. It’s always a lot of fun to show them around and give them a feel for life here. I really enjoy myself here, so I’m glad that I can present that to other people. I also appreciate that we as tour guides aren’t given a rigid script to stick to. We have a route that we follow in order to ensure that all of our talking points are hit, but we are encouraged to “be genuine, and try to end on a positive note.” I don’t feel like I’m lying or deceiving anyone on my tours, and I’m not afraid to point out issues or pain points of life here. Recruitment season is still in full swing, and will be for the next few weeks, so quite a bit of my free time will be spent walking backwards around Atherton Hall.

As we are encouraged to do, I always end my tours on a positive note, saying something like this:

I was pretty apathetic during the whole college admissions process. All of the schools seemed the same, and I honestly wasn’t too thrilled to have to spend another four years in school. I didn’t visit Schreyer until I was accepted, like many of you [the students I’m talking to]. When I arrived, I didn’t know what to expect, but by the time I left, I was 99% sure that I wanted to come here, and I was kind of excited to come. I hope that the same thing happens for all of you here, or somewhere, but regardless of where you decide to go, you’ll make the right decision.

I Love Blu-rays

I honestly couldn’t think of anything to write this week, but I have a strange passion for Blu-rays (and physical media in general), and since I’ve ordered quite a few Blu-rays recently, I figured I would write on the subject.

I’m sure you already know, but in case you don’t, Blu-ray is a disk-based storage technology that stores far more content on a disk that’s the same size as a DVD. While a single-layer DVD can hold 4.7 GB of content, a single-layer Blu-ray can hold a whopping 27 GB [1]. This has two consequences: Blu-rays can store more data, and they can store better data. For example, I own Scott Pilgrim vs. the World, my favorite movie, on Blu-ray (and it’s the first Blu-ray I ever bought). A single Blu-ray disk contains the original movie along with hours of extra content: deleted scenes, commentary from directors and actors, mini-docs, and more. I appreciate being able to watch this extra content and learn more about the movie I love. I also get to watch this movie in full quality. Movies on DVD are typically presented at 480p or less (worse than HD quality, looks blurry or pixelated on a nice display), while movies on Blu-ray are presented in 1080p (so-called “Full HD”) and sometimes even 4K (4x the resolution of 1080p). Blu-rays simply provide more content in higher quality, and for movies, they completely obsolete DVDs.

That’s all well and good, but movies can be streamed online for around the same price (or sometimes free with a subscription), and there’s no need to go to the store or wait for a movie to arrive in the mail. And indeed, all of the movies I own on Blu-ray I also own in digital form. For me, I like Blu-rays because they are a physical object that you can put on your shelf and look at. I’m very passionate about the movies that I like, so I like to have physical versions of them. After streaming a movie and enjoying it, and perhaps watching it a few times, I order a Blu-ray off of eBay to add to my collection. A friend could look at my Blu-ray collection and see what movies I like. They could pick one up and read the back. I could even pop the disk into a Blu-ray player and watch it. Plus, I just like looking at the spines and thinking about the movies. I know it sounds dumb, but it makes me happy.

There are, of course, drawbacks to Blu-rays. They require a Blu-ray player, which can be expensive, and the Blu-ray disks themselves can be expensive, too. And of course, there’s the burden of owning a physical thing: it could get lost, broken, or stolen. Putting the last point aside, the first two drawbacks aren’t as much a problem now as they were when Blu-ray was in its infancy. Modern Xbox and Playstation consoles can play Blu-rays, and Blu-ray technology has been around for long enough that inexpensive Blu-ray players can be purchased, especially pre-owned. Blu-rays themselves can be had for relatively cheap on eBay. I generally buy older movies (8-15 years old), and each Blu-ray costs me around $5. This is less expensive than purchasing the movie on iTunes or Google Play, albeit less convenient. For me, though, convenience isn’t a concern.

It probably wouldn’t surprise you that I buy physical copies of all of my Nintendo games instead of using the online eShop. I also buy CDs or vinyls of my favorite albums (even though I don’t have a record player and my sister doesn’t like me using hers). I just like to have a physical collection of the things I like, a collection that I can look at and share with my friends. And to be completely honest, Blu-rays are far from the dumbest things to collect.

The Mom Test

I’m going to take a break from talking about CodeLM because, although I put 25+ hours into it over the past two weeks, most of the work I did is interesting only to me, and doesn’t warrant another post. However, CodeLM is not the only thing I’ve been doing these past few weeks.

Down on S. Frasier street, there’s a building with a large orange cube on it. That building belongs to LaunchBox, an organization that works with startups in Penn State and the surrounding community. They are funded by PNC Bank (they recently got $1M), and use that money to put on a few programs: the Idea TestLab for groups who are developing an idea, the FastTrack Accelerator for startups who are looking to build and launch a product, and the Summer Founders Program, which gives teams $10k to work on a project over the summer.

A few friends and I had an idea, so we submitted it to LaunchBox and got accepted to their Idea TestLab for Spring 2018. The program takes place over four Wednesday evenings, two hours per meeting. So far, we have had one meeting (the next one is tonight), and it was at this meeting that we discussed the Mom Test.

The Mom Test is a book written by Rob Fitzpatrick which explains how to go about asking questions to decide if the problem you are trying to solve actually exists, and if your solution would solve the problem that people have. One of the main ideas of the book is that people will lie to you in their reactions to your questions if you give them the chance. Most people do this without thinking, and most do it to protect the asker, because once they put their ego on the line, people are more likely to agree with them so they don’t get upset. The name comes from the idea your questions should be phrased in such a way that even your mom, the person who is most likely to agree with you for the sake of making you happy, can’t lie to you.

The key is to ask questions grounded in reality, and to avoid hypotheticals, what-ifs, and future commitments. Questions like, “Would you use a product that can do X, Y, and Z” and “How much would you buy a product that did X” are bad because they deal with hypothetical situations. Most people would answer that yes, they would buy a product that does X, Y, and Z, and they would pay for it, but when it comes time for them to hand over the money, many simply won’t do so. The best questions are centered around the problem you are trying to solve, but focused on real-life past experiences.

My product is focused in the area of improving textbooks, so I ask questions about past experiences with textbook buying. Questions like “How did you go about buying your textbooks this semester?” and “Did you compare prices online, and if so, was that worth your time” are good questions because they get at the root of the problem I’m looking into, but they are backed by real experiences. If I’m trying to build a website for textbook buying, I could ask people “would you use a website that would buy all of your textbooks for the cheapest prices in an instant”, and everyone would say yes, but if I asked people who don’t compare textbook prices online why they don’t, I may find out that many people simply don’t care, and I’d realize that perhaps my solution wouldn’t work quite as well as I had hoped.

So far, I’ve interviewed three people using the Mom Test, and I’ve learned a few things about my potential business. Certain aspects that I may have emphasized aren’t as important to potential users, and those potential users brought up other aspects about which I hadn’t really thought. Of course, three people hardly make a representative study, but seeing as we have to interview 10 people each week, I will learn quite a bit before I’m finished. With that said, if you are a Penn State student, or you know a Penn State student, and you are interested in answering some questions, I would greatly appreciate it.

The Mom Test has given me some great advice on how to get real, as-unbiased-as-possible feedback for a potential idea. It’s a quick read, and I highly recommend it to anyone who may one day want to create something and be able to back up their claims with real, useful customer interaction data.

CodeLM 2018: The Hype is (Almost) Real

On March 8th, 2018, hundreds of students, teachers, and professionals will gather for CodeLM 2018. CodeLM is a programming competition I started at my high school four years ago. Teams of up to three compete to solve algorithm challenges as quickly and accurately as possible, and the best teams win.

CodeLM began as my AP Computer Science final project. I had competed in a programming competition at the University of Pennsylvania, and I was impressed that they had an online system that automatically tested and graded code submissions. I wanted to try and create my own system, and I managed to have a working demo within a few hours of starting. I then decided to build it out into a system capable of facilitating a programming competition. The first version of the CodeLM dashboard was written in PHP (shudder), and it was fairly simplistic. My Computer Science teacher agreed to organize an in-school field trip for his students so that I could run a competition on the website I built. I wrote 20 questions, ran them by my CS teacher, and then one morning, we had about 30 or so students compete in the first-ever CodeLM. The problems were a bit too hard overall and the website had some issues, but the general reactions were extremely positive. My CS teacher was excited to hold CodeLM again next year, and some of my friends expressed interest in helping me run it.

The next year, we hosted CodeLM 2016, and it was a million times bigger than I could ever have imagined. First, we opened the competition up to other area high schools, and had about 10 high schools represented. Second, we got a corporate sponsor: SIG, a local technology-oriented trading firm. They provided us with food, prizes, and programmers to serve on our judging team. Third, the CodeLM family grew substantially. It was no longer just me running the show, I was now joined by a few of my friends and some mentors from SIG. I rewrote the dashboard (again in PHP (yes, it was a phase, and yes, I’m over it)), and we even produced an intro video. The event was a huge success; everyone enjoyed and everyone was excited to come back next year.

CodeLM 2017 was even bigger than 2016’s event, if you can believe that. This time, we built the competition around a story (a fictitious company was hiring security experts (the competitors) to recoup after they were hacked by a competitor). This was reflected in the website (rewritten in Python), the snazzy intro video (catch me in a suit), and even the questions themselves. SIG sponsored us again and even provided shirts for everyone involved. And even more students came, this time representing 13 area high schools.

After 2017’s event ended, the future of CodeLM was murky. Most of the CodeLM team, myself included, would be graduating. Putting on this event is a huge undertaking and it requires the commitment of a dedicated and motivated team. However, I didn’t want to let CodeLM die out. It was becoming bigger and bigger every year, everyone loves it, and each event is a highlight of my year. The outgoing CodeLM team recruited some underclassmen, and after some discussion with my CS teachers, we agreed that we would be able to put it on again.

We are currently well on track to host CodeLM 2018 on March 8th. I have been working in my spare time to build a brand-new dashboard (the fourth iteration, this time on the MEAN stack), and the new CodeLM team has been working with our CS teacher to write questions and figure out the logistics. We have no plans to scale back this year. SIG has agreed to host the event, so CodeLM 2018 will take place in their headquarters instead of our high school. We plan to have another storyline this year, most likely related to last year’s, and I plan to make a cameo in the intro video. I am so incredibly excited for CodeLM 2018, and I am so incredibly thankful that so many people are willing to put in so much time to make this a reality.

I plan to post again about CodeLM one more time before the event and then one time after to debrief. Until then, I’ll be hard at work getting everything ready.

PS: I forgot to mention the title of this post. Back in 2016, I wrote “The hype is real” on the CodeLM website as a joke, but SIG saw it and thought it was our tagline, so they printed it on the check-in sign. After that, it became our slogan, and it’s printed on our 2017 t-shirts. We are considering a new slogan for this year.

Groupify: A 21st Century Jukebox

This past weekend (the weekend of January 19th), I had the opportunity to compete in PennApps 2018w. PennApps is a well-known hackathon, and a hackathon is an event where teams of programmers get together for 24-48 hours straight and code something cool from scratch. PennApps was a 36 hour event, starting at 8pm on Friday night and ending at 8am on Sunday morning. On Friday afternoon, I drove down to Penn to meet my friends Max and Will. The first order of business was to decide what project to work on. We tossed a few ideas around, and eventually settled on Groupify, an idea I’d had about a week earlier.

Groupify is a service that allows other people to add songs to your Spotify queue. If you’re hanging out with friends, instead of fighting over the aux chord, you can have one device plugged into the speaker, and everyone else can push songs to that device. If you’re an Uber driver, you can let your passengers control the music in the car without you having to touch your phone. When the passengers leave, Groupify goes back to playing your personal music.

The initial plan was to have three components: a website where hosts could configure Groupify for their Spotify accounts, a text-messaging chatbot that users could use to queue songs, and a server backend that would tie the two pieces together. Will worked on the chatbot while I started to work on using the Spotify API (a tool that lets developers interface with Spotify) to control a user’s playback. After a bit of research, I realized that I couldn’t control a user’s queue through the API, so we would have to try something else.

Spotify also has an iOS SDK (software development kit) that lets developers connect to Spotify from their apps, so we decided to make a simple iOS app that would receive queued songs from the server and add them to the queue in the Spotify app. The app would be very bare-bones; it would run in the background, receive songs, and add them to the Spotify queue. Max and I coded a quick demo to test the functionality. We hit the play button and… the music started playing within our app. I had thought that the SDK would control the Spotify app, but instead, it streamed the music directly to the app. We now had to pivot again. We abandoned the website and built out the iOS app to allow users to register and change settings.

During the next 10 or so hours, I fought with a lot of technology. Getting the Spotify SDK to behave correctly was a bit of a hassle, and pushing queued songs to the host’s phone involved a mess of digital certificates that took an hour or two to resolve. But by 4 am on Sunday morning, Groupify worked. You could choose a default playlist to start playing, then have someone text the chatbot to queue a song, and sure enough, that song would show up in the app’s queue. When the current song ended, if the queue had a song in it, that song would play. Otherwise, the default playlist would resume.

After about an hour and a half of sleep, we presented our product to the judges and fellow hackathon competitors. The app worked flawlessly, and people were at least interested if not impressed. In the end, we didn’t place in the top 30, but we learned a lot and had a lot of fun, and now we have a cool, genuinely useful product at our disposal.

So what’s next for Groupify? Well, nothing.

I did some market research after we built it and realized that we were not the first person to come up with this idea. On the party / hanging out with friends side, an app already exists on the App Store that does exactly what Groupify does. On the Uber driver side, Uber and Lyft both have similar functionality integrated into the driver apps, and Lyft even owns a patent for a “driver jukebox system”. Oh well.

Although nothing will ever come of Groupify, I had a great time working with my friends on a really cool project in such a short amount of time. I am still amazed that we managed to turn around a solid, well-coded, minimum viable product given the limited time we had and all of the issues we ran into. The drive back to Penn State only made me more tired, and it took a bit of time to catch up on my sleep, but I would do it again any weekend.

If you want to see a demo of Groupify, you can watch my video here. Screenshots and other images are included below.

    

App Developer For Hire

About two months ago, a family friend reached out to me and said his company was looking for a custom app to be developed. The app would allow employees to scan barcodes, create a list of scanned items, and then submit the list to a server for ordering. The app would also interface with a database, so information about each item would appear when a barcode is scanned. I didn’t have much experience with iOS app development, but I thought the idea didn’t seem too difficult and I like a challenge, so I got to work.

The first step was to make sure that I could actually scan barcodes. While that may sound like a difficult task, iOS and Android both have built-in APIs (code provided to you by someone else) for scanning barcodes from the built-in camera. I wrote the barcode scanning code in both iOS and Android and found it was very simple. In each case, I just had to start the camera recording, and then I would be notified of the barcode numbers of any barcodes detected.

Once I knew I could handle barcode scanning, I knew everything else would be relatively easy. My contact and I agreed to start with the iOS app and worry about the Android app later. I then set to work integrating the barcode scanning code with other code to handle storing a list of scanned items, interfacing with the database, and submitting finished reports, among other features.

As I worked through the various bugs and features, I posted beta versions of the app through Apple’s TestFlight system. This system allows specified people to test the app before it goes live in the App Store. With each beta, I provided a list of changes, the testers did their testing, and then they reported back with issues they found or features they wanted to see.

This experience has been different from most of my other programming experiences in that the product will be used by people other than me. Most of the things I code are for my own use, so I design them myself with myself in mind as the user. For this project, I had a list of required and requested features, and I received feedback from various people testing the app. I also had to design the app to work with many different devices. Although the app might work on my phone, it might have an issue on someone else’s device.

I also had a chance to have a Skype call with many of the employees of the company, in which I explained the app and answered any questions and feature requests that the employees had. One employee showed me a barcode scanning device that’s older than I am, and told me that’s what my app would be replacing. It was kind of funny, but it also proved to me that my app was useful and that I was doing meaningful work.

At this point, the app is live in the App Store and is mostly finished. I plan to move on the Android version within the next week or so, and continue to refine the iOS version over time. Overall, it’s been a great experience so far. I’ve gotten real-world experience working as a contractor for a company, I’ve created an app that will make a measurable difference in multiple peoples’ lives, and last but certainly not least, the pay isn’t half bad ?.

AlphaGo Zero: The Next Step in the Next Step for Game-Playing AI

For as long as artificial intelligence has been studied, its classic application has always been games. Games work perfectly for artificial intelligence because they are structured and discreet. A game has a clear set of rules, and operates within a confined space, usually a game board. Programmers can write algorithms that take into account the rules and game space and play the game in ways that humans simply can’t. Computers can try more permutations, evaluate more complex formulae, and they don’t let emotion get in the way.

In 1996, IBM’s Deep Blue chess computer played six games of chess against world chess champion Garry Kasparov. Although Kasparov came out on top with a final score of 4-2, Deep Blue won the first match against Kasparov, marking the first time a computer had ever beaten a world champion. Even before this, we can look to the popular 1983 movie WarGames, in which an AI plays itself in tic-tac-toe, never making a mistake, and realizes that “the only winning move is not to play.”

As artificial intelligence moves from algorithms to machine learning, by which AI can learn in a similar way to humans, the scope of games that AI can tackle has grown. The latest game that AI has tackled is more than 2,500 years old, is considered the oldest board game still played today, and is highly complex; it is the ancient Chinese game of Go. The rules are simpler than chess, but the strategy is far more complex.

I’ve never played Go myself, but here’s what I understand the rules to be: two players (black and white) take turns placing stones of their color on a 19×19 space board. If one player can completely surround a chain of stones of the other player, the other player’s stones in that chain are removed from the board. Here is what would happen if white played  a stone at position A:

At the end of the game, scoring is determined by adding up the number of stones each player has on the board (although some scoring methods take other things into account), and a winner is determined. Although the rules are simpler than chess, there are a few things about Go that make it far more challenging than chess: the board is much larger, there are many more moves a player could make on a given turn, and there are more legal board permutations than there are atoms in the visible universe.

A game of this scope is certainly a challenge, and it’s exactly the challenge that DeepMind, an AI research company owned by Google, took on. They build an AI named AlphaGo that used the latest in machine learning hardware and software and taught it how to play Go using hundreds of millions of past Go games. Then, they gave their algorithm a challenge: play against an eighteen-time Go world champion and win.

From 9 March 2016 to 15 March 2016, AlphaGo played fives games against Lee Sedol, widely considered one of the best players in the history of Go. It won four of them. The first match, which AlphaGo won, was another huge step for artificial intelligence, comparable to Deep Blue’s first win 20 years ago. AlphaGo played with an unorthodox style, making moves many considered at first to be blunders, but turned out to be smart in hindsight. After game three, Sedol said, “I misjudged the capabilities of AlphaGo and felt powerless.”

I remember staying up late at night to watch the live stream of each game, commentated by Michael Redmond, the highest-ranked Go player in the Western Hemisphere. Each night, Redmond explained the moves each player made, how they were playing, and what they would have to do to win. I felt like I was witnessing history as excitement grew towards the end of the first game, until Sedol finally resigned and AlphaGo achieved victory.

After these great victories, DeepMind has not stopped their work. Earlier this week, they announced AlphaGo Zero: a brand-new version of AlphaGo that taught itself how to play. While the older version used tens of millions of previous games to learn, this version learned entirely by playing against itself. It started off knowing the rules, but having no strategy whatsoever. As it placed stones down and won matches, it began to learn.

After three days of continually playing itself, it played the version of AlphaGo that beat Lee Sedol and won all 100 of its games. After 40 days of playing itself, AlphaGo Zero had a 90% win rate against the most powerful previous version of AlphaGo. Because AlphaGo Zero doesn’t use previous games as starting data, it is able to create its own strategy, employing moves and tactics that humans had never thought of. The new version also requires far fewer resources, using only 4 TPUs (tensor processing units, special processors for machine learning algorithms), compared to the previous version, which used 48.

DeepMind has a bold mission: it wants to “solve intelligence [and] use it to make the world a better place.” There’s no telling what DeepMind will be able to accomplish next, and there’s no telling what game will be conquered by AI next. But we’ll be there to see it happen, and it will be incredible.

My Summer at Lockheed Martin / Part 3: The Rest of It

This past summer, I had the opportunity to work at Lockheed Martin as a High School Student Tech. While I would describe the experience as overall positive, it was not at all what I had expected, and there were quite a few issues I encountered along the way. I’m not trying to dissuade anyone from interning at Lockheed Martin, but I think applicants deserve to know realistically how their experience might be.

I’m going to be honest with you: there really isn’t a lot more that happened during my internship at Lockheed Martin. Once I finally got my computer set up, I would come in every day, work on my assigned projects, and then leave. I’ll end my saga by sharing some snippets from my month at Lockheed and wrapping up the pros and cons.

First off, the projects themselves. I can’t imagine there would be any issue with me describing the projects, but I’ll try to be vague just to play it safe. Our team had three large projects which we divided up and completed over the course of the internship. Each project had a “client”, someone within the company who would be using the tool we developed. Each day, we would conference with the client over Skype for Business and discuss our progress and get feedback. The first project was a command-line tool that would help IT staff to easier interface with Lockheed’s policy provisioning system. The second was a tool which would analyze roaming cellular data plans and alert users who weren’t using their plans to cancel them. The third was a mobile app called LMEngage (available in the App Store and Play Store), which allows potential hires to engage with Lockheed in the hopes of getting hired.

By the time I started at Lockheed, everyone else had been there for weeks or even months, meaning that significant progress was already made on all of the projects. I felt like I was trying to jump onto a train that was already moving. I didn’t really know where to start, so I took a look at the code for the policy provisioning tool. No offense to whoever wrote that code, but it was bad. I think the person who wrote it had never worked with Python before, which is totally fine, but it showed in the code quality. I tasked myself with cleaning up the codebase, and spent a day or two refactoring code, deleting duplicate code, and simplifying overly complex algorithms. I didn’t really understand the purpose of the tool, but I was still able to contribute. After pushing all of those changes, a team member explained the purpose of the tool to me and tasked me with adding some new features, which I did. In the end, I ended up contributing quite a bit to that project, although that wasn’t my main project.

Work on the LMEngage mobile app hadn’t really started when I joined, so I was able to start working on that project in its earlier phases. One feature of the app is a “challenges” section, where users can answer STEM-related multiple choice questions. My job was to make an internal website which would allow employees to submit challenge questions, which could then be approved by our client (the person who would be responsible for the app once we left) and pushed to the app. I had a decently amount of experience with web development, but I was tasked with learning a web framework called Angular to develop this website.

Angular is a cool JavaScript-based web framework which aids in the development of large and complex websites by allowing developers to easily organize and reuse code. I had never worked with Angular or another web framework, so I took a few days to learn how to use Angular from online tutorials. I quickly discovered just how awesome Angular is. After developing that website, I have used Angular in a variety of other personal projects, and I am seriously considering specializing my Computer Science career in full-stack web development.

One last thing, and I don’t know how to say this without sounding like an ass: in a room of my peers, I am used to being the smartest when it comes to Computer Science. It’s not that everyone else isn’t just as capable as I am, but I have a lot of experience (both depth and breadth) relative to my age. That changed at Lockheed. The guy sitting next to me, Will, was clearly more knowledgable than I was at programming. While I was learning Angular, which he already knew, he was able to step in and fix issues that I wasn’t sure how to fix, like I had done for many of my friends and peers. Beyond that, it was great to have another person to chat with about Computer Science (and share in-jokes).

Ok, let’s wrap this up with a list of pros and cons:

Pros

1. Everyone on my team was very nice and helpful. I made a few friends to whom I still talk today.
2. I learned new technologies (especially Angular) which I use today.
3. My manager and the rest of the staff at Lockheed were very chill. They gave us free reign over our room and our time, as long as we got the work done (which we did).
4. I got paid.
5. I have a great item to put on my resume (as much as I hate talking about that stuff).
6. The food was really good, and pretty inexpensive. They had a grill station where you could ask the chef to make you pretty much whatever you wanted, and that was where I fell in love with ham and cheese melts (especially on a pretzel bun).

Cons

1. I was trapped in limbo for nearly a month, waiting to start. If I had known in advance how long it would take, I would have been much better off.
2. It was way too much of a hassle to get my laptop set up for work once I finally got started.
3. By the time I joined, the rest of the team was already familiar with each other and had already started working on the projects. It was difficult to get up to speed.
4. We had to wear button-down shirts and slacks. If you haven’t noticed (not that I expect you would have), I wear sweatpants and a t-shirt every day. Not the best-looking outfit, but comfortable as anything.
5. I honestly felt that the projects weren’t very meaningful. It was difficult to motivate myself to work because I genuinely felt that the project were contrived and wouldn’t have any actual use. I could certainly be wrong though.

At the end of the day, as I’ve been saying in the heading of each post, I would describe my experience as positive. Most of the cons were easily avoidable, and I think that if Lockheed works to improve the onboarding and starting process, I wouldn’t have much to complain about. I am currently considering going back this summer, but I might try to work somewhere else to get a different experience.

At the end of the day, my internship and Lockheed Martin was not at all what I had expected, but I’m glad I got to have the experience. It’s certainly something I won’t forget.

---

Since you read this far, here’s one more bonus story: While developing the cell phone data plan web application, my coworker Will wanted to include the Lockheed Martin logo. Rather than grab it off of Google or LM’s website, he designed an–erm–artistic version in Microsoft Paint. I thought the logo was hilarious, so I copied it and put it in my challenge collection web app. Will was told by the rest of the team to remove the logo and replace it with the real logo, but we couldn’t let the MS Paint logo die. Will hid the logo and added code to the website so that if the user enters the Konami code (up, up, down, down, left, right, left, right, B, A, enter), the official Lockheed logo gets replaced with his logo. I was also told to remove the logo from my website, but I’m not sure if I ever did. For my birthday this year, Will sent me his logo printed on a piece of glass. It is one of my most prized possessions.

Here’s the logo in all its glory, which can be found today somewhere in the depths of Lockheed Martin, with the real logo below it: