For my first portfolio project (CLI Application), I created an app that allows the user to retrieve the match history for a player (known as a ‘summoner’) of the popular video game League of Legends. I am a longtime player of the game, and I felt that working within a domain that interests me, and I have high knowledge of, would help set me up for success with the project.
The first step in the process was familiarizing myself with the Riot Games (developer of League of Legends) API. This was an arduous task for myself, and for somebody who is not familiar with the products that Riot Games offers, would likely have been near impossible. One of the challenges of learning to play League of Legends is becoming familiar with the terminology of the game, and being able to navigate the API is no different.
Once I had determined the necessary API calls that I would need to make to retrieve the information needed for CLI_League_Stats, I set out upon the software engineering process. I took a very iterative design approach here, with the first step being to get a functioning program that had no actual features. Once I could successfully launch the program I slowly added features one by one, with frequent testing in between, until I had a shell of what I wanted to create.
It was at this point that I needed to return to the API documentation and begin familiarizing myself with the data structures that were being returned by my API calls. This was in and of itself challenging for many reasons. One such challenge was that the champion, or character, that the summoner played for a given game is provided via championID, which is an integer, and I wanted to display that champion’s name in the app. To get to the champion’s name you have to enter the Riot Games ‘Data Dragon’, which are collections of JSON objects that relate to in-game information. Due to API call rate limits placed upon keys by Riot, I manipulated the Data Dragon JSON objects with some scripts that I wrote in order to distill them down to the information I needed, then created global data objects within my application to make that information accessible. For example, one of my global data objects is a hash of all of the championIDs as keys, and the champion name as the key’s value. This allowed me to retrieve the match history for a given player, and display the champion that they played without having to make multiple API calls for each match in the history, and risk exceeding the API call rate limit of 20 requests per second or 100 requests per 2 minutes.
Another challenge was that I could only generate an API key that lasted for 24 hours. Luckily, I was able to submit an application for a non-expiring API key via the Riot Games developer portal, and after providing some brief explanation as to the function and structure of my app, was granted an API key that would not expire. There is a higher tier of API key available that is intended for developing applications that will be for public use that have much greater increased call rate limits. To obtain one of the ‘production’ keys, you must submit your app’s code and undergo a code review with a member of the Riot Games API team, and the process can be very lengthy. I found this project very interesting, and it is something that I wish to continue building upon and I may eventually submit a production key application. This will not only give me the ability to build more features into my application, but will also give me experience with doing a code review with a professional software engineer.
Once I had developed all of the features I wanted to have I began refactoring my code. One of the things I noticed is that many of my methods belonged to classes that did not make sense for a proper object oriented approach. For example I may have had a method in my Summoner class that was outputting information to the console, whereas it should belong to my CLI class. Once I had refactored all of my code of object oriented structure, I did a second refactoring process that sought to increase code efficiency, readability, and simplicity. Finally, after completing the second refactoring, I added functionality to my code that accounted for invalid user inputs, and provided feedback to the user regarding their input.
Overall I found the entire process extremely interesting and exciting. I learned a lot throughout the development of CLI_League_Stats, including both things specific to my project and overall programming concepts. I learned about dealing with Unix Epoch Timestamps and converting them into regular time objects so that they are readable by humans. I learned a great deal about proper object oriented design, and how if you let yourself get away from it your code can quickly become difficult for an outsider to read and understand. I learned about overall design concepts such as accounting for an intended user flow, and adapting that design to allow for actions that may not have been accounted for originally. That is something that will be very important in a professional setting as software that I work on is tested, and even used in production, and I receive user feedback on their experience and look to incorporate it into my design. Overall I felt this project was an excellent learning experience and a great first step on my journey to become a Software Engineer.