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.
It has been almost a year... I have to say that this is the longest that I have ever gone without updating my blog. I could say that I became very busy in the past year, as I finished out the final year of my degree program while working full time. I could say that life just became a whirlwind as I got a new job, graduated, and moved to a new place. I could say that I barely knew what sleep was as I pushed myself far past the limits of what I thought I was ever capable of before. Each of these statements would be true, but none of them would really capture why I have neglected to write a blog update. The Truth... I'm going to toss aside the concrete reasons and jump into something that's a little more wishy washy. I felt as though there were many fragments and nothing substantial that I wanted to write about. I became super critical of the topics that were coming across my mind as I filtered through the euphoria and frustrations that came with finally snagging a job in my desired field. With many situations happening rapidly, I realized that there were many fluctuating thoughts, so much so, that my blog would seem like the title should be changed to: The Chronicles of an Indecisive Person. Indecision has never been an issue for me, in fact decisiveness is one of my best qualities, so I had to chalk the temporary change to being a product of changing careers. I guess I have been feeling the growing pains of moving into a new career and a new field, and I have wholeheartedly loved every second of the journey. Catching Up... A lot has happened in the past year so I'm going to run through it in a few sentences. I snagged an interview with a tech company, was hired as an intern; short time later I was hired as a Software Engineer. I graduated Summa Cum Laude and just recently I moved into a new place. Over the year, I've added quite a bit of technology to my toolkit, but above all else, I feel a sense of purpose in what I do and that's a great feeling. So, what now? I won't make promises on updating my blog regularly, but I do have a list of interesting topics that I'd like to chime in on. I'm currently working on a side project in Python with the purposes of really getting into different libraries and frameworks that Python has to offer. This project is just a fun nerd project to sharpen skills and deepen knowledge, so I can see myself writing a bit about that as the project progresses. I also plan to share my thoughts around Machine Learning, because that just fascinates me so very much.
Photo Source My Summer break has been wonderful and although I'm sad to see it go, I'm also extremely excited for what this Fall Semester has in store. School starts tomorrow for me and I wanted to do a quick recap of what I was able to accomplish this summer. I published an aggressive To-Do list earlier this summer and I thought it would be cool to see how much of it I was actually able to accomplish :) Here are the items that I wanted to accomplish this summer: Unity 5 Training & C# Learning Swift for iOS Learning Android Studio Blender Maya UX Design Foundation Sass Here are the items that I actually accomplished this summer: Learning Swift for iOS Learning to Test Code Effectively Practicing Data Structures + Algorithm Design Sass Foundation Speed Reading Techniques Memory Enhancement Techniques PHP Wordpress Development As you can see, I took some liberties with the list that I originally intended to complete. Mid-Summer, I felt that I needed to work on my foundational learning abilities. I have always had issues with my memory and I take copious notes to overcome that issue. I have also always had the desire to read more rapidly, although I never really thought that I could effectively become a "speed" reader, I discovered that improving my reading speed is actually a goal that I could reasonably accomplish. Since these are baseline skills, I felt that it was a great idea to work on them before the new school year began. Learning to test my code more effectively fell within the same category of foundational learning, because I felt as though enhancing this skill will be beneficial for my current internships and future ones as well! Although I didn't quite get done what I originally set out to do, I was still able to end my Summer break with a decent set of new tools that will help me along the way!
I often like to read through some of Google careers information for insight into what I should be focusing on learning while still in school. Recently, I stumbled upon Google's Technical Development Guide, targeted towards Computer Science students that are looking to get a job at Google. This guide gives online supplemental resources for students. In my opinion, this guide is intended to ensure that CS students understand that they will not likely be successful while relying solely on school curriculum to gain the knowledge necessary to be a developer. Let's take a peek at what they suggest... To say the very least, this guide is extensive with action items ranging from taking an Introduction to CS course to learning Artificial Intelligence, to learning Parallel Programming. Their list seems to approach being a well-rounded developer from two angles: 1) Gathering technical skills and broadening programming language knowledge and 2) Gaining experience working in team environments and on teams outside of usual school structure. What does this list entail?
Take an Into to CS Course
Code in (at least) ONE object-oriented programming language (C++, Java, Python)
Develop logical reasoning and knowledge of Discrete Math
Develop a strong understanding of algorithms and data structures.
Develop a strong understanding of operating systems.
Learn UX design
Learn Artificial Intelligence
Learn how to build compilers
Learn Cryptography
Learn Parallel Programming
Work on projects outside of the classroom
Work on projects with other developers
Practice your algorithmic knowledge and coding skills
Work on a small piece of a large system (code base), read and understand existing code, track down documentation, and debug
Become a Teaching Assistant
Gain internship experience in software engineering
You may be thinking, "this list would take a life time to master". In many cases, that is the truth, but I think the goal is to have a decent understanding of all of these areas then use that knowledge determine an area to master. For instance, I plan to specialize in Artificial Intelligence in grad school, but it's still important for me to understand the other areas because they all work together. Regardless, this list gives us a glimpse into what Google expects from future Software Engineer applicants. Google accompanies their list with links to online resources that students can use to accomplish these tasks. I've highlighted in blue the tasks that I have worked on since beginning my CS degree program. I did this to demonstrate just how obtainable this list is, especially when tackled over time. Bottomline... I believe the biggest takeaway in this situation is that students shouldn't rely solely on their school's curriculum to give them all of the knowledge they need. I have been an advocate of supplemental learning and have mentioned it in many blog posts before this one. What's more interesting is that supplemental learning has gone from being a way to be competitive while job hunting, to being an expectation for many successful organizations. As technology advances, developers will need to have a broader skill baseline in order to be successful. Personally, I believe this Technical Development Guide is a tool that any aspiring developer should use, not just ones that want to snag a job at Google!
Want a job at Google? Google’s Technical Development Guide!
Photo Source Two months ago, I spent a week or so learning how to build a Wordpress site. As a part of my post-mortem, I identified some performance issues and things that I would have done differently. As I'm taking some time to review previous projects, I am taking the time to tackle a big issue of my site so far -- performance. A major part of the lessons I learned after creating my site was how quickly a Wordpress (or any) site can become bloated and have bad performance. I'd noticed that my site took a lot longer to load than I'd like, so this weekend, I am carving out some time to tackle the issues with the site so far. My benchmark... I was pleased that Google rated my site 99/100 for User Experience. This was a pleasant reward considering I had user experience in mind the entire time that I was building the site. However, my Speed results were an abysmal 43/100. One of the major issues was render-blocking CSS and JavaScript, with a few images that were uncompressed and unoptimized. I was able to fix the image issues immediately, which bumped my score to 59/100 on both mobile and desktop. However, the other issues require a big of digging on my behalf. Where to go from here... Now that I've identified the issues, I feel as though I am well on my way to correcting them. Here are some tasks things that I will be doing in hopes of improving performance overall: 1) Reformatting my stylesheets: I have one gigantic stylesheet that is a mess of issues, which was identified in my post mortem. Although I usually code neatly and with a purpose, much of the piece-meal formatting of my style sheets came from me not fully understanding how Bootstrap + Wordpress works together. 2) Testing my CSS: I installed CSS Lint to run tests on my CSS code and the first test revealed 3 errors and 143 warnings. I will fix these warnings and errors, but I will also take this time to re-organize my style sheets to make far more sense than it does currently. 3) Broken JavaScript files: I have a couple of errors in my JavaScript files caused by updates to some plug-ins. I will work on getting these errors corrected. I believe this is a really good place to begin. From there I will continue to use Google Page Insights to increase my page speed. I believe there is some serious refactoring to be done on my part, and use the knowledge that I've gained over the past few months. Very exciting times, indeed!
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 :)
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.
My epic quest to encounter more math... Math, really? Yes! I have come to the point in my studies that I feel the need to brush up on my math skills. I have been reading many resources and on multiple occasions I have discovered that a pitfall some may succumb to is not taking enough math when pursuing a degree in Computer Science. Apart from this research, many of the books I've been reading mention that although an extensive background in math is not necessarily a requirement, it helps. Some of these resources even add that the better programmers have backgrounds in Mathematics as well.
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.