This week, I reviewed chapter 8 from Learning Java by Building Android Games 3^rd Edition by John Horton. This chapter reviews some of the principles of object-oriented programming, including encapsulation, inheritance, and polymorphism. Interestingly, the principle of abstraction that was named alongside the previous three in the course syllabus is not reviewed in this chapter of the book. I chose to write about this resource because in the last Spring semester, I studied this book in order to create a functional mobile game in Android Studio for my final project in my Operating Systems course. I needed to apply my knowledge of arrays, for and while loops, and Java class design to complete this project. In addition, I needed to learn how to utilize the graphics libraries within Android Studio to visually represent the entities within the game and how they interacted with each other. While this book did help me tremendously in the later stages of the project, I wish I had found it earlier before I began coding. I had begun the project in BlueJ, and was coding a Java app meant to be run on a Windows or Mac system, not an Android mobile device as was the project specification. I completed a functioning version of the game with all the features I wanted to include that ran on my Windows PC, but I found it much more difficult than I anticipated to port the code I had written into Android Studio to produce a version of the game that would function on mobile devices. However, because I had applied the principles of encapsulation, inheritance, and polymorphism to my Java classes and functions, I was able to get the program to a partially functioning state on Android by the final due date. My first challenge in porting the project from PC to Android was addressing how to display the program on the device’s screen. Through this book, I found that constructing my Game class so it would extend Android’s Activity class would be the first step in displaying the desired output. I also applied the principle of inheritance to the Java classes I created to represent the in-game objects represented on screen. As many objects as I could manage inherited from a parent GameObject interface, which would be extended into more specific StaticGameObject and MovableGameObject subclasses, and then from those classes I extended them into specific types of objects like PlayerCharacter, Obstacle, and BonusItem. For my next software endeavor, I want to adhere to these principles more purposefully when coding, as I think that a lot of the challenges and headaches I experienced while creating this video game were self-inflicted.

If you want to try the game I made (I was so pressed for time by the end I never named it), here is a link to my Github repository. The project should be able to opened up and run from inside BlueJ or your Java IDE of choice.

Source: Learning Java by Building Android Games: Learn Java and Android from scratch by building five exciting games, 3rd Edition by John Horton

Github repository: https://github.com/MCummingsWSU/CS373-mobile-app-final-project

From the blog CS@Worcester – Michael's Programming Blog by mikesprogrammingblog and used with permission of the author. All other rights reserved by the author.

Learning a language is really difficult, not only is it really hard to get started with one but once you have a good understanding of the syntax then learning certain methods of how that language can be used can be quite time consuming to learn. The problem I tend to have is that it can be difficult for me to implement a specific method in my work. For example I could go in and look at an example of a design pattern like the factory method, and I could know how it works and what it does, but I would have a hard time trying to implement it in my work.

Now, one of the first patterns that is introduced in Apprentice Patterns puts the reader in the context that they are starting out as a programmer and that they have a shallow understanding of the languages they know. The problems that we are introduced to are that since we have such an unlettered understanding of the language, it is difficult for us to create quality programs and solve problems. The solutions to this is that we must pick a language and take the time to become fluent in the language. The drive of wanting to learn and solve solutions for that language should be enough to guide the learning process.

While reading about this pattern, It was safe to say that this wasn’t the first time I’ve been exposed to this information of how to become fluent in a language. What really captivated me was how the author made a good point in learning the fundamentals and not just syntax, I feel that at this point in programming journey I could string a couple lines of code together because I’m to familiar with the syntax of my language, but the potential that I can create in that language is close to none. I wouldn’t know the first thing to do to start a project. The author put an emphasis on learning fundamentals, learning how to solve solutions with the chosen language, and how to use testing to your advantage. It’s important to open every and any feasible avenue when working to understand the language. As the author mentions, it must click. There is a difference between learning how to write a piece of code and absolutely knowing every purpose of that code. My goal is to find someone that knows more about the language I’m trying to become fluent in and to learn as much as I can from them, almost like a master. It’s a lot easier for me to acquire someone else’s wisdom rather than figuring it out on my own.

Sources:

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Hello! 

For the grand start of my discussion of apprenticeship patterns from “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye, I wanted to begin with the pattern Expose Your Ignorance.

Expose Your Ignorance is related to the notion that managers and team members expect you to know what you’re doing. For your position, you may know most of what is expected for your role and overall what you need to be doing. However, there are some components that you are bound to not be as familiar with, or have no experience with, like some new technology. The solution to this is that you should reassure them that you’re learning how to deliver to them what they want, and not to pretend that you know how to do it. You would be able to form a reputation of having a great learning ability rather than playing on with fake expectations of what you know.

One way to expose your ignorance is to ask questions. It may be difficult to do so at first, but eventually communicating with team members who are very knowledgeable about the topic won’t be such a tribulation. This would be helpful to give your team members a scope of what you can do and learn, and could also help them understand more about the topic as they explain things to you. The book suggests keeping a list of things you don’t understand related to your work in a place others can see.

I appreciate that this pattern addresses my concerns as someone new and heading into the workforce. I often feel pressure that there are some things that I probably should know how to do, or that I need to do something but it involves something I have not heard of before. But as discussed with the pattern, I do know a good chunk of what I need to be doing, and what I don’t know are just some gaps between them, so I don’t need to feel so pressured. This reminds me that team members I work with have been using this technology and certain methods for a while now, and I just haven’t learned them yet, so I am not too behind. 

 I’m very open to learning and I can reassure them that I’m studying and practicing what I’m learning from them and other sources. I also shouldn’t be afraid to ask questions, because asking someone for help can help put me on track faster to having a better foothold on the technique/technology I’m working on. Of course, I still try to solve things on my own for as much as I can so I won’t have to repeatedly ask for help, but I keep in mind time constraints. I definitely agree that I shouldn’t just specialize in one thing, but aim to branch out and learn more to have a better foothold in different components of technology. I don’t think I have anything I disagree with for this pattern.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

I read Apprenticeship Patterns as per the syllabus and I found a lot of things that resonated deeply with me. Dave talks about giving up on learning to code, or rather to program after being unable to do anything compelling or significant, and only having had mastered Perl on his third attempt. I myself have on multiple occasions traded a language for another when I stop making progress. My thinking was – “Maybe, this isn’t the one for me”. So, I hopped from Python to JS to Scala to Java to C learning only the basics and just enough to satisfy any classes that might’ve required it. I was a jack of all trade, and master of none! Only upon revisiting Python again for a summer fellowship with a professor, and working on learning more than just the syntaxes, idiosyncrasies, and fun facts about the language, was I able to move on to being somewhat competent. Dave’s story tells us how he sought out mentors, took on challenging projects, and continuously challenged himself to improve and grow as a software developer. His story serves as an illustration of the apprenticeship journey and the importance of seeking out opportunities for learning and growth in the software development field.

I also really liked the definitions and the progression in stages – an apprentice, to a journeyman, to a master. Looking at software development as a craft to be honed and mastered like an Archer, or a Swordsman was quite interesting to think about. The third chapter especially was very enlightening. For the pursuit of efficiency, or most likely in service of sloth – my favorite sin, I take shortcuts whenever possible. I have noticed in myself the tendency to bodge things to make do – like putting on a band-aid over a bullet hole, to push perfection for later, to say – “Can’t be bolloxed, this will have to do!”.  Walking the Long Road is quite a departure from that mindset, and one I hope to grow into. Ah! to be able to rip off the band-aid!

All in all, quick fun read. Not bad at all!

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

I read Apprenticeship Patterns as per the syllabus and I found a lot of things that resonated deeply with me. Dave talks about giving up on learning to code, or rather to program after being unable to do anything compelling or significant, and only having had mastered Perl on his third attempt. I myself have on multiple occasions traded a language for another when I stop making progress. My thinking was – “Maybe, this isn’t the one for me”. So, I hopped from Python to JS to Scala to Java to C learning only the basics and just enough to satisfy any classes that might’ve required it. I was a jack of all trade, and master of none! Only upon revisiting Python again for a summer fellowship with a professor, and working on learning more than just the syntaxes, idiosyncrasies, and fun facts about the language, was I able to move on to being somewhat competent. Dave’s story tells us how he sought out mentors, took on challenging projects, and continuously challenged himself to improve and grow as a software developer. His story serves as an illustration of the apprenticeship journey and the importance of seeking out opportunities for learning and growth in the software development field.

I also really liked the definitions and the progression in stages – an apprentice, to a journeyman, to a master. Looking at software development as a craft to be honed and mastered like an Archer, or a Swordsman was quite interesting to think about. The third chapter especially was very enlightening. For the pursuit of efficiency, or most likely in service of sloth – my favorite sin, I take shortcuts whenever possible. I have noticed in myself the tendency to bodge things to make do – like putting on a band-aid over a bullet hole, to push perfection for later, to say – “Can’t be bolloxed, this will have to do!”.  Walking the Long Road is quite a departure from that mindset, and one I hope to grow into. Ah! to be able to rip off the band-aid!

All in all, quick fun read. Not bad at all!

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

I read Apprenticeship Patterns as per the syllabus and I found a lot of things that resonated deeply with me. Dave talks about giving up on learning to code, or rather to program after being unable to do anything compelling or significant, and only having had mastered Perl on his third attempt. I myself have on multiple occasions traded a language for another when I stop making progress. My thinking was – “Maybe, this isn’t the one for me”. So, I hopped from Python to JS to Scala to Java to C learning only the basics and just enough to satisfy any classes that might’ve required it. I was a jack of all trade, and master of none! Only upon revisiting Python again for a summer fellowship with a professor, and working on learning more than just the syntaxes, idiosyncrasies, and fun facts about the language, was I able to move on to being somewhat competent. Dave’s story tells us how he sought out mentors, took on challenging projects, and continuously challenged himself to improve and grow as a software developer. His story serves as an illustration of the apprenticeship journey and the importance of seeking out opportunities for learning and growth in the software development field.

I also really liked the definitions and the progression in stages – an apprentice, to a journeyman, to a master. Looking at software development as a craft to be honed and mastered like an Archer, or a Swordsman was quite interesting to think about. The third chapter especially was very enlightening. For the pursuit of efficiency, or most likely in service of sloth – my favorite sin, I take shortcuts whenever possible. I have noticed in myself the tendency to bodge things to make do – like putting on a band-aid over a bullet hole, to push perfection for later, to say – “Can’t be bolloxed, this will have to do!”.  Walking the Long Road is quite a departure from that mindset, and one I hope to grow into. Ah! to be able to rip off the band-aid!

All in all, quick fun read. Not bad at all!

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

I read Apprenticeship Patterns as per the syllabus and I found a lot of things that resonated deeply with me. Dave talks about giving up on learning to code, or rather to program after being unable to do anything compelling or significant, and only having had mastered Perl on his third attempt. I myself have on multiple occasions traded a language for another when I stop making progress. My thinking was – “Maybe, this isn’t the one for me”. So, I hopped from Python to JS to Scala to Java to C learning only the basics and just enough to satisfy any classes that might’ve required it. I was a jack of all trade, and master of none! Only upon revisiting Python again for a summer fellowship with a professor, and working on learning more than just the syntaxes, idiosyncrasies, and fun facts about the language, was I able to move on to being somewhat competent. Dave’s story tells us how he sought out mentors, took on challenging projects, and continuously challenged himself to improve and grow as a software developer. His story serves as an illustration of the apprenticeship journey and the importance of seeking out opportunities for learning and growth in the software development field.

I also really liked the definitions and the progression in stages – an apprentice, to a journeyman, to a master. Looking at software development as a craft to be honed and mastered like an Archer, or a Swordsman was quite interesting to think about. The third chapter especially was very enlightening. For the pursuit of efficiency, or most likely in service of sloth – my favorite sin, I take shortcuts whenever possible. I have noticed in myself the tendency to bodge things to make do – like putting on a band-aid over a bullet hole, to push perfection for later, to say – “Can’t be bolloxed, this will have to do!”.  Walking the Long Road is quite a departure from that mindset, and one I hope to grow into. Ah! to be able to rip off the band-aid!

All in all, quick fun read. Not bad at all!

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

I read Apprenticeship Patterns as per the syllabus and I found a lot of things that resonated deeply with me. Dave talks about giving up on learning to code, or rather to program after being unable to do anything compelling or significant, and only having had mastered Perl on his third attempt. I myself have on multiple occasions traded a language for another when I stop making progress. My thinking was – “Maybe, this isn’t the one for me”. So, I hopped from Python to JS to Scala to Java to C learning only the basics and just enough to satisfy any classes that might’ve required it. I was a jack of all trade, and master of none! Only upon revisiting Python again for a summer fellowship with a professor, and working on learning more than just the syntaxes, idiosyncrasies, and fun facts about the language, was I able to move on to being somewhat competent. Dave’s story tells us how he sought out mentors, took on challenging projects, and continuously challenged himself to improve and grow as a software developer. His story serves as an illustration of the apprenticeship journey and the importance of seeking out opportunities for learning and growth in the software development field.

I also really liked the definitions and the progression in stages – an apprentice, to a journeyman, to a master. Looking at software development as a craft to be honed and mastered like an Archer, or a Swordsman was quite interesting to think about. The third chapter especially was very enlightening. For the pursuit of efficiency, or most likely in service of sloth – my favorite sin, I take shortcuts whenever possible. I have noticed in myself the tendency to bodge things to make do – like putting on a band-aid over a bullet hole, to push perfection for later, to say – “Can’t be bolloxed, this will have to do!”.  Walking the Long Road is quite a departure from that mindset, and one I hope to grow into. Ah! to be able to rip off the band-aid!

All in all, quick fun read. Not bad at all!

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

I read Apprenticeship Patterns as per the syllabus and I found a lot of things that resonated deeply with me. Dave talks about giving up on learning to code, or rather to program after being unable to do anything compelling or significant, and only having had mastered Perl on his third attempt. I myself have on multiple occasions traded a language for another when I stop making progress. My thinking was – “Maybe, this isn’t the one for me”. So, I hopped from Python to JS to Scala to Java to C learning only the basics and just enough to satisfy any classes that might’ve required it. I was a jack of all trade, and master of none! Only upon revisiting Python again for a summer fellowship with a professor, and working on learning more than just the syntaxes, idiosyncrasies, and fun facts about the language, was I able to move on to being somewhat competent. Dave’s story tells us how he sought out mentors, took on challenging projects, and continuously challenged himself to improve and grow as a software developer. His story serves as an illustration of the apprenticeship journey and the importance of seeking out opportunities for learning and growth in the software development field.

I also really liked the definitions and the progression in stages – an apprentice, to a journeyman, to a master. Looking at software development as a craft to be honed and mastered like an Archer, or a Swordsman was quite interesting to think about. The third chapter especially was very enlightening. For the pursuit of efficiency, or most likely in service of sloth – my favorite sin, I take shortcuts whenever possible. I have noticed in myself the tendency to bodge things to make do – like putting on a band-aid over a bullet hole, to push perfection for later, to say – “Can’t be bolloxed, this will have to do!”.  Walking the Long Road is quite a departure from that mindset, and one I hope to grow into. Ah! to be able to rip off the band-aid!

All in all, quick fun read. Not bad at all!

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.

I read Apprenticeship Patterns as per the syllabus and I found a lot of things that resonated deeply with me. Dave talks about giving up on learning to code, or rather to program after being unable to do anything compelling or significant, and only having had mastered Perl on his third attempt. I myself have on multiple occasions traded a language for another when I stop making progress. My thinking was – “Maybe, this isn’t the one for me”. So, I hopped from Python to JS to Scala to Java to C learning only the basics and just enough to satisfy any classes that might’ve required it. I was a jack of all trade, and master of none! Only upon revisiting Python again for a summer fellowship with a professor, and working on learning more than just the syntaxes, idiosyncrasies, and fun facts about the language, was I able to move on to being somewhat competent. Dave’s story tells us how he sought out mentors, took on challenging projects, and continuously challenged himself to improve and grow as a software developer. His story serves as an illustration of the apprenticeship journey and the importance of seeking out opportunities for learning and growth in the software development field.

I also really liked the definitions and the progression in stages – an apprentice, to a journeyman, to a master. Looking at software development as a craft to be honed and mastered like an Archer, or a Swordsman was quite interesting to think about. The third chapter especially was very enlightening. For the pursuit of efficiency, or most likely in service of sloth – my favorite sin, I take shortcuts whenever possible. I have noticed in myself the tendency to bodge things to make do – like putting on a band-aid over a bullet hole, to push perfection for later, to say – “Can’t be bolloxed, this will have to do!”.  Walking the Long Road is quite a departure from that mindset, and one I hope to grow into. Ah! to be able to rip off the band-aid!

All in all, quick fun read. Not bad at all!

From the blog Zed's Blog by Lord Zed and used with permission of the author. All other rights reserved by the author.