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.
If you follow my personal blog, then you already know that I started tutoring about a month ago. Tutoring has been a rewarding endeavor and I can see me continuing to do it as long as I breathe. But with tutoring comes a lot of confusion in the techniques used to teach newcomers to programming, such as pseudocode. Pseudocode has its place in technology... The only time in my studies have I found pseudocode to be useful has been in my software engineering course. In this course, pseudocode was used to explain snippets of code to executives and customers so that they can get a feel for what the program would do and to get a bit more technical without using actual code. In these situations, syntax is not as much of a concern as getting the functionality across to the client. Where pseudocode doesn't belong is teaching people how to code... I understand the desire to take baby steps to teach newcomers how to code. We do not want to overwhelm them and have them running for the hills before they have even gotten their feet wet. But I wholeheartedly believe that using pseudocode fosters more confusion than necessary. I tutor students from 4 different Intro to Algorithm and Design classes. Some professors have their students translate their code from pseudocode to C code and have them practice it in an IDE. I find that these students often mix the syntax between the two and it leaves them more confused. Where is the breakdown? In one class, it's like learning two different languages. If pseudocode is to be used, I personally believe that professors should chuck syntax out of the window. Let them type whatever they want, as long as they understand the concept, who cares if the student types "Set count to zero", as opposed to "count equals zero". Let them get the concept that they have to assign a value to a variable without the added issue of worrying about syntax. Pseudocode should not be it's own language, in my opinion. Why? because it varies across text books, and even in the same class, it's taught in different ways. Also, a student can not run pseudocode to check to see if what they did was correct. For the first week or two, let them logically write out what steps they are taking in the program without fake syntax. I have found that since they are so caught up on syntax, they skip over the logic generating portions of coding because they are so worried that their professors will take off points from fake code. I suppose I believe that pseudocode is helpful, but only when used as a logic-generating tool in order to get the student thinking about their program without focusing on syntax and actual code. The other part of learning needs to be using a language that is easy to use. There are many languages that I think would accomplish this. I like Python, personally, but I don't care what the language is really, as long as they are learning syntax with an actual language. An actual programming language should be used to teach the syntax portion of learning to code, not pseudocode. By using an actual language, the student has access to a developer's API to use as a learning resource. They should be allowed to learn while using a language that can be compiled in order to get immediate feedback on their errors. An actual language should be used so that students can do web searches and watch tutorials in order for them to solidify concepts in the way that they learn best. Bottomline Using an actual language to teach syntax is best because the student is then able to play around in an IDE, make changes, and get a feel for how programming works. Pseudocode, more times than not, leaves students more confused and frustrated. It was no surprise to me that students were able to pick up on using C much quicker than using pseudocode, and it's not because they learned pseudocode first. They were more successful with using C, because they were able to get feedback from the compiler, research online, and use developer documentation to correct their errors.
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.