The Beginning... When I first started my Computer Science degree program, I remember the various discussions on how and when to comment code. Each text book that I read had different views on when and why someone should comment their code. On top of the different textbook teachings, each of my professors seemed to have different standards on comment requirements: ranging from some not mentioning comments to some deducting points if comments were not present. One common trend was that the quality of code comments did not matter. My internal thoughts were that commenting in school was simply a lot of noise. We were shown practices where we would comment everything and not necessarily in a good way. I would see things such as: [code language="java"] // declare counter
int counter;
// initialize counter
int counter = 0; // loop printing numbers
while (counter < 10){
System.out.println("Number: " + counter + ".");
counter++;
}//end while loop [/code] While this code is communicative, it's also busy and the extra markup is distracting (in my humble opinion). More so, any programmer would know exactly what this code is doing without the comments. Of course, this is pretty basic stuff, what struck me was that the comments that we were required to write in school, went against my natural inclination to communicate decisively and not just because I could. Wait what? Let me clarify a little. I believe that communication is important in many situations, but sometimes communication can be more confusing when it's not clear, concise and free of extra irrelevant information. It's like someone trying to tell you that they are ready for dinner by singing the National Anthem while inserting the words "I'm ready for dinner" somewhere within the song -- it's just extra unneeded noise. I personally feel as though unneeded comments can play the same role within our code. So, what now? I vividly remember my Google searches on a standard for commenting code and what I found was troubling for a new developer at the time. Within one forum or within a single resource there were many different opinions broadcasting why their means of commenting was the best. There were folks lobbying that code should be self documenting and that comments were unnecessary in many cases. There were others that felt that more communication didn't hurt and whatever meta data could be added to the code base would only benefit the project, not harm it -- specifically for new members to development teams. The two sides warred with many people also falling in between at different areas of the spectrum. The one thing that was clear was that there was in no way a specification when it came to commenting code. With experience, came clarity... It wasn't until I started working on a development team, that I started to find my own practices for code comments. First and foremost, I tend to lean towards code that is self documenting. I use explicit comments when there is business logic specific to that code that may not be abundantly clear to the person that is maintaining the code. I am also primarily a Java developer so I believe in commenting in order to get all of the benefits from the Javadoc functionality. I've found that usually if there is a need to comment sections for flow, there is a better design that can be accomplished without using comments such as breaking the code out into different classes or using private or helper methods and descriptive variable and method names to add concrete metadata to the code. This methodology is not new and can be found in well-known software books such as Clean Code by Robert C. Martin. I've found that taking more time to think about the design of the code, leads to fewer comments being needed. Many may think that comments aren't hindering the program in any way since the compiler ignores comments. This is true, but comments can be easily ignored by the programmer, as well. I've seen situations where code was changed to fit a new business need, but the comments for that code was not updated. This leaves very deceptive code that can be more confusing than helpful. In some situations, the original comment was necessary and the developer updating the code should have been more careful. But I've also seen in some cases where the newly-deceptive comment was simply meta data that could have been placed in an external documentation source such as a wiki. In this situation the wiki was updated, but the source code documentation was not. All-in-all, I believe that it's important to find the standard on the project that we are working on. Having a specification is a helpful means of determining how code should be commented, for a project may have a specific standard that should be followed. However, in many cases, it's up to the developer to find a happy medium in the spectrum of commenting paradigms that exist today. I suppose that one test we can use for ourselves is to return to code that we wrote say, 6 months ago and see if we could follow it. Is there enough information to understand the flow and purpose of the code? Would refactoring the code make it far more clear to a new comer? There's always room for improvement, moreover, returning to our old code is a great way test our own system of commenting. I'll leave you with this: what I can say is that my current standard for commenting is completely different than what I was taught in school. However, it feels really good to have a personal standard, developed through my own research and experience.
At the beginning of the summer, I decided to purchase a Raspberry Pi module, for no particular reason other than my love of everything tech. After reading a few reviews, I realized the potential of having something that's completely hack-able - and decided to jump on the Raspberry Pi wagon. At the time, I was happy to be able to ssh in and use my Mac's monitor and keyboard to connect to it remotely. I ran a few python scripts and delighted in the ability to make things blink and to tap into the GPIO board's API. Excitement, reborn... The novelty died off a bit as I didn't have an actual purpose of having the unit, apart from simply playing around with it and forcing it to do my bidding. But recently, a friend of mine received a Raspberry Pi unit for her birthday and thus a new opportunity was born -- the chance to find an actual project to work on, this time, with a friend! My mission, if I choose to accept it... I spent my weekend reading blogs about projects that can be accomplished with the Raspberry Pi and I was excited all over again. There were projects involving sound, media, web, servers, and so much more. After some deliberation, I decided to get a Sense HAT and my plan is to collect data and aggregate it with numpy. I recently started taking a data science course online, so I thought this would be a great way to collect my own data and do something fun with it. This will be my first real project where I'm taking hardware and coding it directly so I'm really excited about that in general. Filling the gap... Ever since I decided to take the plunge to learn software development, there has been somewhat of a gap between how software communicates with hardware. This semester, I took Computer Architecture which helped fill in a lot of questions on how what we create in code, translates to the 1s and 0s that the machine understands. But it wasn't until playing around with the Raspberry Pi that things really started to click into place. So, I'm ready to get to work and turn my RPi into my own personal data logging superstar :)
In the past, I have spent hours watching tutorials on how to use Unity, and I've also attended a Game Jam where the engine we used was Unity. So, although I do not consider myself a complete noob, I feel as though I do lack some fundamental knowledge that I would like to dig deeper into. With that said, I decided to start the Complete Unity 5 Developer course on Udemy. I purchased this course when it was on sale, at the beginning of the summer and only used it as a reference when I needed some assistance in a particular area. But after a recent decision I made to streamline my focus (I may write a post on that later), I decided to really sit down and take this course from start to finish. I'm extremely happy about my decision thus far Usually, whenever I sit through a programming tool's training, I want to pull my hair out because of the elementary concepts that are covered in the content. I always feel the urge to skip around and sometimes I feel as though I'm missing out on small nuggets of information that I could really benefit from. This leaves me with a dilemma, do I sit through the boring stuff for the possibility of some new piece of information? OR do I skip around and forgo the hair pulling in exchange for the ability to learn at a rapid pace? However, I find that the way that this particular course is structured, I don't feel as though I'm missing out on anything if I just play it in the background while I go on my own. If I hear something that piques my interest, I tab over and check it out, otherwise I go on my merry way. Also, there are some good nuggets there about Game Design Documents and how to properly ask questions, which I found really beneficial. How will I share what I've learned? By no means are the things I'm learning things that I would want to put in my portfolio. But I want to share them, so I will do that through my blog :). After just a couple of hours (mostly spent feeling out the tools), I was able to build my first full game from an empty project to a build uploaded to my website. The game concept is straight from the tutorial and the dialog is rather dry (I can't deny it). But I'm proud of my little game and I can not wait for what's to come in the near future. Want to check it out? Make sure you're in a browser other than Chrome :) and click below! Prison GameWhere to now? I'm not a game writer lol. So, I'm partnering up with a good author friend who has agreed to help me create a new Text Adventure game. He'll do all of the writing (thank God) and I will do the programming. I totally can not wait. Stay tuned, as always :) Want to get your feet wet with game development? You really should try Unity, it's free for personal use.
The situation... Recently, I have been preparing to get another internship to replace my Administrative position. I am aiming to submerge myself into programming and put as many hours into coding as I possibly can. I currently have a "spare-time" Internship on a game development team, as well as a part-time Administrative position that allows me to work from home or anywhere with an Internet connection. But since I changed careers two years ago, I have felt as though I wanted even more exposure to coding, so lately I have been preparing to obtain a programming position to replace my current part-time Administrative position. (Don't worry, my boss knows and supports me completely lol.) My fears... Over the past few years, I have read so many horror stories of hiring managers conducting interviews with recent Computer Science graduates, only to discover that they aren't able to code their way out of a paper bag. I have heard stories of the dreaded programming tests that accompany many programming positions. These fears, in part, are what drove me to do self-learning on top of my degree program. Above all else, I read (A LOT) and practice 10 times as much as I read. However, no amount of practice has been able to squash my fears around the dreaded programming interview test. What's my solution?... More practice. lol. However, I have been practicing with a purpose. I have been focusing on interview-specific algorithms and timeboxing myself to overcome the shakes that I get with just thinking about programming on the spot. I spend a few hours a day implementing different data structures, practicing kata on code wars, looking at the implementation of different data structures within different programming languages, and pretty much living and breathing programming. So, what about Python?... Yes, python. I originally fell in love with C++ as my favorite language after taking a C++ last year. But after a few different events, I was exposed to Python. First, there was me joining Code Wars, which didn't have C++ as a language option for code katas. Then, there was my interest in scripting languages in general after reading requirements of different job openings. Finally, there was the announcement of one Maryland's major Computer Science programs moving to Python to teach new students. Armed with this information, I started to practice Python about 4 months ago. I have read a bunch of resources for interview tests and just yesterday I made a repo for my solutions to these problems. This repo is my means of tracking changes and bugs and making improvements along the way! If you haven't gathered yet, my primary means of preparing for these types of interviews is lots and lots of practice. Personally, I don't think there is a better way, and I also believe that Python is a great language to use for this purpose! Happy Coding :)
It's that time again... the usually dreaded time to return to classes. This time around, I have mixed feelings regarding the start of my final Fall semester. On one hand, I am holding on to the tiny bit of my summer vacation. But on the other hand, I am more than excited to begin this semester, if only because of the classes that I will be taking this time around. Here's my Fall semester lineup:
Data Structures and Analysis
Computer Systems Architecture
Linear Algebra
Advanced Programming Languages
Object Oriented Concurrent Programming
I also plan to supplement my learning with a couple of free MOOCs:
Algorithms 1
Software Testing
As usual, I have piled my semester with tons of fun and plenty of things to learn. This semester will be special to me because I will be taking the bulk of my Computer Science core classes. As I took some time to re-read the course descriptions, I could feel the excitement rising because much of the gaps I've felt lately, will be addressed this semester. Let's discuss these "gaps"... A huge part of my studies has been self-taught. Although I am attending a university in order to get my degree, a large portion of what I know now, has come from countless hours of practice, reading, and completing MOOCs online. While stumbling working my way through my self-learning, there have always been areas that I felt would have been more clear had I gotten to that point in my formal education. Or, in many cases, the resources available teach a watered-down version of a subject, which left gaps in general understanding. In these situations, I found myself seeking different sources of information to fill in the gaps, but sometimes, the information still was elusive at best. I know that school will not fill in all of the gaps, but I do feel as though this semester will provide me with a more in depth guideline to follow in order to deepen my understanding, specifically around data structures and algorithms. So, onward I go to my next to last semester of school!
We've all been there before. We pull a fresh copy of our project and now it's not working. If you're on a team project, trying to pinpoint where the issue started can seem like a nightmare. Well, for the first time since I started working on our game project (my internship), I was unable to run the game, and there were roughly a month's worth of commits between the fresh pull and the last time that the game worked properly on my computer. My first instinct was to perform an expertly executed table flip and walk out of the room. But instead, great tips from my friend helped me through a pretty awesome bit of functionality of git, git-bisect. So what is this git-bisect thing you speak of? Well, it's a way to step through your commits while git determines which commit was the culprit. Groovy, huh? Git bisect will automatically figure out which commits need to be tested in order to pinpoint which commit is causing your program to fail. So, how does this work? First, you have to let git know that you are about to begin bisecting the code. [code language="python"]
$ git bisect start
[/code] This toggles the "bisect mode" and starts the bisecting process. Next, you have to let git know which commit is bad: [code language="python"]
$ git bisect bad
[/code] Usually this is on the current commit. After this, you have to find and checkout a commit roughly near the last working commit. This does not have to be the exact last working commit, git will help determine this info, you just need to find a previously working commit to flag. In my situation, it had been awhile, so I just moved the HEAD back 50 commits. [code language="python"]
$ git checkout HEAD~50
[/code] Then I tested the game and determined that it worked. So now I have a rough point, again in my case, it had been quite some time, you may either know the commit or only have to go back a few commits to test. Either way, now it's time to flag the working commit so that git has a range to bisect. For the first working commit, you have to tell git the actual commit, git rev-parse HEAD will give you the current commit, and then you can pass it through to git using the "git bisect good" command. [code language="python"]
$ git rev-parse HEAD
$ git bisect good [commit]
Bisecting: 14 revisions left to test after this (roughly 4 steps)
[/code] Note that if your shell supports it, you can combine the above commands to one: git bisect good $(git rev-parse HEAD) Now git tells us that it has determined which commits needs to be tested, after each bisect, you have to recompile and test your code to see if the problem still exists. In my case, the code was still not working so I flagged that commit as being bad. [code language="python"]
$ git bisect bad
[/code] Git will continue going through the steps, each time you run your code to see if the problem exists, each time entering the command "git bisect good" if it is working, or "git bisect bad" if it's not. Finally, you will run out of steps and git will spit out information about the culprit commit that is causing you so much heartache. After you've noted the offending commit, you have to let git know that you are done bisecting and it will reset you back to the commit prior to beginning the bisecting process: [code language="python"]
$ git bisect reset
[/code] I found this process pretty awesome. In my situation, when the game did not run, I expected that there was an issue in the very last commit and that everyone else shared the same issue. But after verifying that we were all on the freshest copy of the game and no one else was able to duplicate my issue, I was left trying to determine a system-specific bug, and only I could handle that. This git functionality was very useful in helping me determine the origin of my issue.
Photo Source I've made it to Day 3 of learning the programming language, Swift. So far, I have to say that I have been enjoying the syntax. I still type random ";" out of habit, even though I have experience with scripting languages like Lua and Python, I still tend to click the good old ";" out of habit. There are some features that I found interesting such as the way strings and variables are concatenated using the \() formatting. At first I found it obnoxious, but when I had to do stuff with the variables, I found this syntax much easier to read and less confusing when manipulating the variables. Another feature that I'm enjoying is the function syntax. In this particular example, you're able to pass through a series of numbers just by simply using Int... I found this a pretty cool and useful feature. [code language="python"]
func sum(numbers: Int...) -> Int
{
var sum = 0 for number in numbers { sum += number }
return sum
}
sum()
sum(100, 200, 300)
[/code] I am also enjoying that some of the things that I loved about Python are similar in Swift, like the "for" loop syntax. However, in Swift it's even better, in my opinion, because the loops have brackets as opposed to colons. The familiarity of brackets always makes me feel welcome in any new language that I'm learning. Overall, I'm having more fun than I should discovering and learning Swift so far. Soon, I'll get to the point where I'll begin to experiment with Swift in creating an iOS app. Stay tuned!
As a part of my Summer's Goal List, I have decided to learn Swift for iOS. Swift is Apple's relatively new programming language, optimized for iOS and OS X development. Through figuring out ways to accomplish learning Swift, I found that learning Swift's library was my best bet at learning the new language in a way that would not leave me frustrated. Every tutorial that I have come across seems to assume that Swift is their target audience's first programming language. Sitting through the painstakingly frustrating explanations of what a loop is has lead me to realize that reading Swift's API is probably my only way of learning Swift for the time being. Xcode's playground mode makes learning Swift's library a breeze Before I get into Xcode's playground mode, I want to talk a bit about my experience with using Xcode in general. When I first started to learn C++, my professor wanted us to use Visual Studio so that his students were all using the same IDE. This made troubleshooting issues a bit easier because we were all using the same environment to code in. I quickly fell in love with Visual Studio's robust features and used it for all of my C++ projects. However, recently Microsoft's student developer system fails to validate that I'm a student, so I recently switched to Xcode for C++. I found Xcode to be really helpful in learning OpenGL + GLUT and Xcode began to grow on me. Whenever I used Xcode and created a new project, I would always see "playground" as a file type option and never really understood the difference between a playground file and a project file. I'd even did a web search and just as I suspected, the playground mode was a way to practice one of the Xcode's supported languages in a rapid manner. In playground mode, you can type your code, Xcode validates the syntax and puts the output immediately to the right of where you're typing. This allows you to practice code without having to build and run as you go. I have been able to go through the Swift tutorial book rapidly while practicing and executing the tutorial's "experiments" in order to gain additional understanding of the syntax. This has been greatly beneficial and what's cooler is that I am able to use comments to organize my code with key words so that I can use my own playground as my own personal API for when I start to develop using Swift. I've done this while practicing other programming languages, but using the playground functionality makes what happening within the code, abundantly clear. As simple as this functionality is, I can't imagine that Xcode is the only tool out there with this functionality, but this is my first experience with technology like it and I've been extremely pleased with the results thus far. Here's a screenshot of a snippet of the playground that I've been using for learning Swift: Overall, I'm really happy that tools such as these exist. Having the ability to rapidly see the output of my code as I practice and type out the tutorials, have really made learning faster and more rewarding than waiting to rebuild and run code in chunks in order to text functionality.
It's been a month since school let out and I have had a chance to recuperate from a vigorous semester full of... Math... Now that I'm not longer seeing integrals in my sleep, I've had the change to devise some set goals to accomplish this summer. The realization that this will be the last summer where I will have a considerable amount of free time, I decided that it would be best to spend my time wisely. Although there are no plans of forgoing sleeping in and reading Word of Radiance for hours, I do have a plan to add a substantial amount of productivity to my summer vacation. So, what are my goals, you ask? Well, before I get into my goals, another epiphany was that although I have learned quite a bit in the past couple of months, I don't really have any way of showing what I've learned. Apart from cheesy homework assignments, I haven't really had the time to work on any resemblance of a portfolio. To add insult to injury, my website, at the time, looked like a drunken toddler made it in the midst of a temper tantrum. In other words, I really have no way to showing what I've learned, nor do I have concrete representations of what I would like to do with my programming knowledge upon graduation. What a nasty web I have woven for myself... But, this summer I aim to change the status quo. The first step was to update my drunken toddler website, which I'm in the process of doing now. But, there are some other major tasks that I really want to get to which are: Unity 5 Training & C# Learning Swift for iOS Learning Android Studio Blender Maya UX Design Foundation Sass I know... a lofty list. I will probably get to possibly 1-2 things off of this list, but I believe that it's good to have aggressive goals, even if I only get to a quarter of this list, it would be greatly beneficial to me. Either way, I plan to blog throughout the summer, sharing my experiences with what I learn. It should be an interesting ride. :)
Overall, I'm really happy that tools such as these exist. Having the ability to rapidly see the output of my code as I practice and type out the tutorials, have really made learning faster and more rewarding than waiting to rebuild and run code in chunks in order to text functionality.