Marshall International Case Competition Challenger

The dream team from left to right: Abhishek Aggarwal, Joel Joseph, Rehan Haider, and Emilio Setiadarma

This weekend I had the amazing experience of working with an amazing team to compete in the Marshall International Case Competition Challenger. Now despite the fact I was the one of the only non business students competing this weekend, I didn’t let that deter me. If anything it was able to complement the finance heavy nature of the team, with the other 3 members strong financials background complementing my experience pitching startups in the past. Not only could I craft a compelling and logical story about the expansion, but my teams could create the finance projections to back it up.

The business case we worked on this weekend revolved around a company name True Fruits, which brought the smoothie to Germany. Essentially when they started no one in Europe knew what a smoothie was, yet today they are the biggest player in smoothies. The question we were asked to present on was whether it was time to expand internationally, and if so what the ideal markets would be to expand into.

To see the exact case click me.

Now just as important as the final result is the way my team came about our recommendations. Very early on our team’s strategy revolved finding the core question, which in this case was if and how True Fruits should expand its market internationally, and building a story around it. In order to build that story I structured the major questions in the case almost

We first started off with why now was the right reason for the company to expand. Much like how this company picks its fruit at the ripest point, the European Smoothie Market was ripe for the picking. This explained why expansion was necessary.

We then moved on to our analysis of neighboring European countries, and explained why we thought that France, Italy, and Spain were the ideal markets to enter. This explained where the company needed to expand.

We finally ended up on how the company should expand. We believed that the expansion should happen in the core smoothie business as opposed to any of their other juice and fruit products. The reason being is strategically, smoothies are a defendable business. Juices and fruit products have long shelf lives, meaning if a Starbucks or international player wanted to win marketshare overnight they could do it by pouring in money. But the smoothies have a shelf life of a maximum of a week, meaning they need to be produced somewhat locally, giving the business a natural moat against any future challengers.

Moreover my team believed that a staggered expansion was the best, given the fact the company had only 20 employees. The idea was that the company should spend the first year testing out the markets by exporting directly from their German facilities. If the market developed and they had good traction (we had specific numbers we presented to the judges), then we would build local production in that market. If not, we would just continue exporting until the market developed. The core of the strategy was to build optionality, and not overextend the company as the companies culture was steady but solid expansion overtime.

Another thing to note is that this company’s marketing strategy of crude humor in the German market, while effective domestically, would not be appreciated in other countries. In fact many times the marketing campaigns the company put out were frankly sexist and racist. As a result our team realized that not only would be ethically bad to expand these marketing strategies internationally, but it also wouldn’t be the best thing for the company’s bottom line. The way our team mitigated this problem was by suggesting that all marketing for the company in international markets be handled by local advertising firms. This helped make the marketing more tailored to each country.

Moreover we included some partners for the launch. We focused on finding the European equivalent of Whole Foods in each of the markets to sell the smoothies, while also finding a local high end gym to help market our product at least initially. This explained how the company would expand.

Our team thought the background was pretty funny. This was an image we stole from the company website of a woman doing a “line of smoothies.” We thought it fit in because we were presenting a timeline of smoothies.

To see our full slide deck - which was made within 48 hours click me

SCheduler Part 2

My amazing team for the SCheduler project!

This is Part 2 of a Project I worked on this semester. To see Part 1 Click Me

This semester a couple friends and I built a Web Application that helps student schedule their classes. Each student at USC on average takes about 5 different classes which have up to 5 different meeting times each week. When you factor in all the times a class might be offered coupled with all the different permutations of classes you can take in a semester, most students are left with dozens of different schedules to choose from.

Our Web Application makes it extremely simple to know what your options are for the next semester.

The landing page of our Web Application

Step 1: Enter the 5 courses you want to take next semester into the system.

Step 2: See all the different schedules you can take.

If you look back to my earlier post on SCheduler I explained a little bit of the Web Scraping I did off USC’s website. Essentially I scraped class information from USC and populated it into a FireBase cloud-store database, where our web application could access it.

To check out my team’s presentation click me !!!

Now because our team was relatively new to building Web Applications we had to learn some new technologies off the bat like : Flexbox, Maven, JGraphT, FireBase.

Cool Extras:

1) Login Functionalities - Using Google Login. This allows users to save schedules that they like in case they want to come back later.

2) Search Capability - By typing in your friend’s name, you can see any schedules he or she has saved which is perfect if you want to take classes with them

3) Multithreaded Notifications - Every time someone creates a schedule using the platform every user on the platform is notified. Behind the scenes this required the use of server sockets which added another layer of skill building to this project.

I really enjoyed working on this project with my team! It was really fun building something that I actually used to make my class schedule for the upcoming Spring.

Mentoring @ Hour of Code

With finals season in fall swing a couple friends and I took a couple hours off today to do an hour of code with K-12 kids from South Central Los Angeles. I was paired up with an elementary schooler named Hunter, and we were supposed to be spending the evening working on an ipad doing some really basic programming on ScratchJr.

Now while Scratch Jr. does have a pretty intuitive interface, it ended up boring Hunter within a couple minutes. He even asked me why I would code on Scratch Jr. all day since it seemed really boring.

Seeing that I was losing him on the Scratch Jr, I decided to pivot and show him some of the projects I’ve been working on. We started off with a hangman game I had made in Java which utilized multi-threading and networking. I explained how all the games he played on his I-pad which were multiplayer used a similar set up - in a water down elementary school level way of course.

After seeing his excitement I then asked him if there were any games he liked playing. He said he really liked the game “snake.” So we spent a decent amount of time building the game in javascript.

The game of snake I coded with Hunter

After coding up the game of snake, and him going around the room showing it off to his friends. He asked me if we could create the game “Pong,” he had heard his dad talk about. So we went off and after a couple of google searches and keystrokes we had a working version of Pong going.

We made sure to have the ball colored in Cardinal and Gold, because GO USC colors!

After building out Pong, he asked me how he could build a game that would give him different recipes to help his mom out in the kitchen. So I got started working on my Virtual Machine, walking through the steps to code a recipe bot in C++ that could get recipes from a recipe API. We only got a couple minutes to work on it though, before Hunter had to go home (so its a project for another day for him)

But more importantly I had a lot of fun talking about what a CS student. Now while I seriously doubt Hunter will be able to program like a “hacker” as he calls it by tomorrow. I think that working through the projects with him, showed him how cool it is to be a CS major. When I first asked him what he wanted to be when he grew up he said a policeman for the LAPD. After the evening coding with him he now wants to be a "cyber policeman" for the NSA.  

2nd Place: Boeing Design Competition

From left to right: Jonny, Aaron, Joel, and Laurence

I had the opportunity to spend the night with some of my friends working on a design challenge presented by Boeing. At the end of the night we took second out of the dozens of other teams that presented.

As part of the challenge my team had to manage the different complexities from a cost, viability, and design stand point to put a communications drone into the sky. We then had to present our case to an audience of a couple hundred people.

The first step for our team was to understand the problem. See the information we were given in the opening presentation here.

Once we were given the problem we needed to put it into a form where we could analyze different solutions in a different way. Check out the spreadsheet our team built to figure out the best solution here. — (Like actually its a really amazing spreadsheet)

Once we understood and could quantifiably define our problem. Our team divided and conquered our objectives by playing to our respective strengths. For example Laurence, an Astronautical engineer, knew the ideal shape of our structure to make it as aerodynamic as possible. Aaron was very knowledgeable about composite materials as a Chemistry and Applied Math major, so he worked on making sure the drone met the weight specifications using cutting edge composites. And with my experience in Electrical Engineering I worked on some of the communications payload with my friend Jonathan another CS student.

Now even though I’m not an electrical engineer, some of my hobby reading and past projects exposed me to error detection and correction coding, along with compression. It was the extra components I thought to add to our communications payload that made our system so unique and placed us on the podium.

The way we sold it to the judges - Boeing employees who worked on a similar project - was that we built a project that exceeded all the project specifications (Structural, Propulsion, Etc) and proposed a software update which incorporated compression coding that would increase the data throughput of the communications payload. This would allow our client, the Federal Government, to get a lot more use out of the communications drone for a little bit higher of a price. And this update would come at virtually no cost to Boeing as a company, since it could be deployed fairly easily.

Now while we didn’t win first (the team that did were all aerospace engineers) what we did learn was how to work together in a multi-disciplinary team. Almost none of the members of our team had any skills overlap - which meant that we had to take full ownership of the piece of the project we were assigned. Moreover the experience gave me a really in depth crash course of what it is to be a Product Manager working with different teams at a highly technical level to manage many different facets of a project.

Overall I loved the experience and thought it was a really interesting problem to solve!

Check out our final Presentation here!

SCheduler Part 1: Web Scraper

The SCheduler Team (from left to right : Justin, Jillian, Luis, Joel, and Jincheng)

This semester I am working on a web application to help USC students schedule their classes.

My job right now is to figure out a way to get course information from the USC website. The way I went about that was using python specifically the Beautiful Soup Library in order to scrape data from the USC website into our database (FireBase).

Now some challenges I ran into - the fact that USC’s website is almost entirely rendered in Javascript - ie in order to get the course times and section numbers some one has to click on the class on the website. I found a really janky work around to this which essentially meant triggering all the javascript responses on the page before scraping it.

Another challenge I ran into was actually cleaning the data and standardizing it so it could be sent to the database. The number of course sections that I scraped numbered in the high thousands - so of course there were going to be variations in the way the courses were displayed (ie Wednesday vs Wed vs W or professor names being hyperlinks to webpages or just like stray commas that would mess up the delimiter which was going through all this data). What I think made this a challenging project was the fact that one small problem that I couldn’t see - could mess up how the data got read and sent to the database. That meant that on top of random spot checks - I had to devise a way to go through all the data I had collected in the database and verify that a stray delimiter or something did not mess up which field the data.

3rd Place: UCLA IdeaHacks

This project was made at the IDEA Hacks hardware hackathon hosted at UCLA - this year’s theme revolved around household appliances.

The night the hackathon began - I was grabbing dinner at the In-n-out with the rest of my team and remarked “I wish i made burgers like these back at home, but lets be honest I’d probably burn down the dorms at USC by accident” My buddies knowing how bad of a cook I am first hand continued on with all the bad times I’ve had with cooking and concluded that I should never be allowed any hot surface. And it was right there that the Safe Stove was born.

The SafeStove revolves around the idea that there are certain people (ie kids, Joel’s of the world, etc) who should never be in front of a flame.

Cool Features:

1) Facial Recognition Technology - We actually trained the camera using a facial recognition API on our raspberry pi to detect my face using a couple photos of me. Essentially when I wander around the stove (as seen in the demo) the stove notices and automatically turns off the stove.

2) Ultrasonic Sensors - Sometimes you forget to leave the stove on, you’re a human and it happens. We put ultrasonic sensors on our stove so it can detect when you are no longer in the kitchen - and automatically turn off the stove.

3) Capacitive Sensors - When your hands get too close to the stove, the fire is automatically turns off

4) Interfacing between 2 Arduinos and a Raspberry Pi - This was my first time hooking up two different systems together and it was a pretty interesting experience. My team spent an hour troubleshooting why signals were not being communicated between the boards before I realized the boards were not sharing a common ground line.

5) Completely Joel Proof - Like this is probably the most impressive feature if we are being honest. I could not figure out a way to get burned on this stove even when I tried. And if I couldn’t figure out a way to get hurt on this stove I can almost guarantee no one else would.

Here’s a video of the first round presentation we gave (click here)- keep in mind we had gotten something like 8 hours of sleep over like 3 days:

If you’d like to see the pitch deck click here!

At the end of the Hackathon my team of USC freshman and sophomores took 3rd - the two teams above us were made up entirely of UCLA graduate students :(

But over all it was an amazing experience building this and really having fun with the rest of my team.

Our team mate Jan, had to leave early bc she caught a cold at the hackathon. But honestly I loved my team so much. From left to right (Chris Hailey, Joel Joseph, Ishan Shah, Aditya Bellathur).

Wall-E By Blockchain

I present the WALLE outfitted with sensors that allows it to drive autonomously and not crash into things

Inspiration

When walking over to the hackathon yesterday morning our team noticed how many parked cars there were on the side of the road not being used. It made us really think about how much cars are actually used and if going further into the 21st Century if we as college students would really need to buy a car in the future.

After all in an age of Uber and Lyft its now a hassle to own your own car. But the problem is everytime we call a car a decent amount of our fare doesn't actually go to the price of the car and gas - but instead to the companies Lyft and Uber. This added price could be the difference between someone buying a car they rarely use for convenience and a world with less cars on the road.

So we thought of a way to almost run this autonomous car sharing service with accountability or trust in a way that was decentralized and immutable.

What it does

Essentially we have a pool of autonomous cars (Wall-E's) essentially in waiting scattered through out a community or a city. When someone wants to use a car to get to a place - they simply log onto our WebApp which is tied into the blockchain - and rent out the car. From there the car is now under their control from the WebApp. They have the ability to move it wherever they want - keep in mind though the car is continuously collecting data from sensors (ie Ultrasound, GPS, Sound) - so if you crash the car it will be clearly logged in the Block Chain in a way that cannot be tampered with. When you are done with your car simply tell the Web App and the car is no longer your responsibility.

Now we wanted a system that did not need a centralized body controlling everything - because we believe that in a sharing economy, no one person or entity should be making the lion-share of profits.

How we built it

The server is responsible for handling all the data that is sent from the sensors on the car and saving it to the blockchain. Further, the web server is responsible to serve the web app to show the data and manage the ownership of the car.

Blockchain. All the data is saved on our Ethereum blockchain using Smart Records. One checkout is considered to be one entity in the contract. We save the checkout and return time as well as the sensor data as part of one contract.

We ran a python script with a GPIO Library to access the pins on the raspberry pi for standard time processing, location gathering, sending get requests, etc. We then used an Arduino to run the motors for the car in a way that allowed it to read data from the ultrasound and run autonomously.

Challenges we ran into

1. Security. The CCI talk made it very clear that things like DDOS attacks were now a reality in a world of IOT. So we needed a solution in order to solve these types of extremely serious attacks and we found our answer in the blockchain. With BlockChain the data is always accessible and distributed meaning if they take down our node the entire system will still function.

2. Saving data as part of the smart contract was really tricky. I ran into the issue of mining and getting some ethers transferred into the main account. Developing a simple smart contract was easy, however creating all the events - checkout, return and adding sensor data was tricky.

3. Getting the Arduino and Raspberry Pi to talk to each other. Troubleshooting and working through the interfacing.

4. Working with WALL-E and getting him to move and talk the way we wanted him to could be pretty difficult at times.

One of the things that took away from the complexity of the project was the fact that we only had one WALLE so that made things just a little bit easier to implement for this project.

Accomplishments that we're proud of

In terms of technology we are really proud we built something on the blockchain. It was a lot of fun creating smart contracts on the online IDE - Remix. We are proud of the fact that we have a scalable solution to get cars off the road in a way thats cheaper and more sustainable than the way the world currently runs ride shares. Our team seriously sees this as a mobility solution not only for common people in cities but for the elderly, and disabled who currently have a hard time moving around cities with current public transportation.

What we learned

How to build WALL-E. Developing smart contracts using Solidity. How to get cars off the road while making public transport more available to people who really need it.

What's next for WALL-E By Blockchain

Next steps are spending a little bit more time and creating a mobile application that would work a little bit like a lyft or uber application making it really easy to request cars. We could also add more WALL-E's or actual cars to this system. We also think working with AI we could get these cars running purely autonomous meaning we can lower the price point and make it more affordable to anyone who wants to use this car service.

Built With

• raspberry-pi

• arduino

• servo

• blockchain

• webserver

• python

• flask

• bootstrap

My team and I taking over a TV in the building to set up our Raspberry Pi for the WALLE

A side shot of our WALLE