Patch it up!
This week we learned all about patches. What is a patch? A patch shows changes that have been made (line-by-line). This is shown with either a '+' to represent additions and '-' to represent removals in the code. When submitting changes to a FOSS project, patches are the preferred method.
Our first exercise was to diff two files we had been working with in the text without using the -u flag. With the -u flag, a patch was printed out in my terminal in great detail: showing which files were involved, printing out the entire code and showing +'s and -'s where code was changed. When the -u flag was removed, the terminal printed a "<" along with whatever line was modified and then it printed out a ">" with whatever that line was modified to. For some reason, my output was not the same as the text's, but if I flipped the file order in which I diffed them, then the output was the same:
The books instructions:
My results:
My results when switching file order:
Weird. I'll have to remember when I'm diff-ing files to put the original one in first.
Our next exercise involved creating a patch for a new file. To be honest, I'm still not sure I did this right. Here is the exercise:
Create a patch file that represents a new file, foo being created with the contents bar. Hint: on Linux systems, the file /dev/null represents an empty file -- use that as one of the files you are comparing.
My outlined thought process:
- I have to create a patch file...I'll name it "exercise-7-8.patch"
- I have to create a new file "foo" with the contents "bar"
- ?!?!?!?!?!?!?!?!?!?!?! ...maybe I could.... ?!?!?!?!?!?!?!?!?!
So I ended up consulting good 'ol stackoverflow and came up with this:
I created a file in my text editor, "foo", and saved it with the contents "bar". I then ran this command. After running the command I have a "exercise-7-8.ptach" file with these contents:
So that's right...right?! That's what this exercise wanted? Yes? Cool.
The last exercise is titled "Patch echo".
Patch the echo command from the coreutils project so that it echoes out arguments in reverse order.
Huh? Well luckily there were step-by-step instructions to follow, so I did, hoping to understand the objective of the exercise as I delved deeper.
It was all going smoothly until the last two instructions:
$ ./configure$ make
and
$ src/echo is this reversedreversed this is
I was silly and entered the first command in the command line not once, but three times before I realized it was not one, but two commands. *shakes head in shame*
$ ./configure
and
$ make
The last one also needed to be split in two.
This is the command:
$ src/echo is this reversed
This is the output:
reversed this is
That's just sassy.
The article I read was "The Second-Order Effects of Steve Jobs" and this was taken from the January 2012 Computer magazine.
"For 20 years, Steve Jobs provided us with a gift- technology from the future."
This article gives examples of how Jobs pushed the industry forward. One example the author gives is when the Mac II came out in 1993 with 256 color levels and IBM was telling its customers "You don't need color: we've already provided it. You have four of them- black, [yellow], cyan, and magenta." That sentence made me chuckle.
Steve Jobs was an innovator and when he left Apple because the board and management "valued top-down, business-style control over a relentless, quirky, unpredictable and seemingly risky quest to push the envelope of feasibility", the company suffered. So when Jobs returned, he made it clear that Apple's purpose was to innovate.
It's amazing how far technology has come. I remember dreaming about products that I actually do own today...because they aren't fantasy...they are reality. How crazy is that?
````````````````````````````````````````````````````````````````````````````````````````````````````````````````
The next required reading was an article written by Peter Wayner titled "12 predictions for the future of programming".
````````````````````````````````````````````````````````````````````````````````````````````````````````````````
The next required reading was an article written by Peter Wayner titled "12 predictions for the future of programming".
- GPU's will be the next CPU's.
- I've already encountered this GPU-muscle-flexing in our very own computer lab, so I can definitely agree with this prediction.
- Databases will perform increasingly sophisticated analysis
- There is more data now than ever and this data is helping companies make big decisions. Agree.
- JavaScript for everything
- They have valid points. Seeing as I've never coded a line in javaScript, I immediately went to codeacademy and I'm happy to report they have a javaScript course- which I'm starting the moment this blog is finished.
- Android on every device
- Literally everything is going to have Android.
- The Internet of things -- more platforms than ever
- Literally everything is going to have internet.
- Open source will find new ways to squeeze us
- This is sad. I don't like it, but it's the way the world works.
- WordPress Web apps will abound
- I need to tinker with WordPress- I've meant to for a while now.
- Plug-ins will replace full-fledged programs
- Don't build from scratch
- Long live the command line
- I've grown to really like the command line. Plus I feel like a bad-ass when it's up on my screen.
- Dumbing it down will fail
- Agree
- Outsourcing and insourcing will remain deadlocked
- Management will continue to misunderstand coder and coding
- Communication is key!
I enjoyed reading this article. This field is so exciting! Maybe the rest of today should be spent learning javaScript or working with WordPress rather than getting under the covers and taking a nap.
No comments:
Post a Comment