Semester in Review

Well, as I’m about 6 hours in* into a 14 hour bus+train journey to Massachusetts I figured this would be a good time to reflect and respond to the past semester which seems to have flown bye.

The Blogs

I really enjoyed the blog assignment. Even though I wasn’t able to write a reply to every post I felt a lot more in sync with how the class as a whole was progressing. When there was confusion or frustration regarding a particular assignment, or just towards the class in general, I was able to respond quickly (I hope!). I feel I learned much more about how the material in ECE2524 was connected both to other courses and to events that interested you outside of coursework (open source gaming, personal server setups, commentary on Ubuntu as a general purpose OS).

There are a couple things I plan to change with the blog assignment with the end goal of adding a little more structure to the syndicated class blog, and hopefully encouraging more of a discussion.

  • enforce “category” and “tag” rules. If you look down the right sidebar of the mother blogyou will see a list of all the categories posts have been made under. The current list is too long and not focused enough to be of any amount of use to someone trying to sift through the many posts for a particular topic. Most of the words used for “categories” should have been “tags” instead, so spending a little time up front talking about the difference I think would be helpful in the long-term organization and usefulness as an archival tool of the blog. Some categories I’ve thought of are:
    • Introspective: reflect on the course itself, whether it be assignments, discussions or structure.
    • Extrospective: explore connections between course material and using *nix systems or applying Unix design philosophy to other courses or events.
    • Social Network: comment on and continue the discussion taking place at VTLUUG and VTCSEC meetings.
    • Instructional: Discussing personal setups and/or workflows. Posts here will have sort of a “tutorial” or “howto” feel.

    There are a couple optional assignments I want to offer that would be linked to blog posts:

    • Learn a Language: There are many benefits to learning a new programming language. From The Pragmatic Programmer, Tip #8 “Invest Regularly in Your Knowledge Portfolio”:
    • Learn at least one new language every year. Different languages solve the same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getting stuck in a rut. Additionally, learning many languages is far easier now, thanks to the wealth of freely available software on the Internet

      Throughout the semester those opting to do this assignment would document their progress with their language of choice and share any new ways of thinking or problem solving gained by thinking outside their language comfort zone.

    • Explore an Environment: An assignment suggested (I need to go through the list to recall who made it) has participants try out an alternative desktop environment and/or window manager. Learners participating in this assignment would make regular blog posts documenting their experience with a particular DE.
    • VTLUUG/VTCSEC: There were some issues with the attendance implementation at VTLUUG (in particular) and VTCSEC meetings that frustrated a lot of people and made my life a little more difficult. In addition, an attendance count isn’t really a good metric for the success of this assignment since the purpose isn’t simply to sit in a room for an hour, but to engage with a larger community. Next semester credit will be counted towards the VTLUUG/VTCSEC assignment for blog posts containing targeted discussion and thoughts of the specific topics covered at each meeting.

Assignments

I noticed several people commented that the Inventory Management assignment was about the time when python and the motivation behind assignments started to “click”. I don’t mind that it takes a few assignments in before connections start clicking, but I would like to try and provide more motivation up front about where each assignment is headed, so that earlier along there is at least a notion of “this is going somewhere”. So I’ve been penciling out a clear, focused progression of assignments that goes from basic text parsing up to something like Inventory Management. That project in particular I am also going to make into a group project so that there is some exposure to using git as a collaborative tool before the final project. It also easily breaks up into sub-modules:

  • Data Parser
  • Command Parser
  • Controller

As the name implies the two parsers make use of text parsing concepts, while the controller is more of an exercise in logical program flow. I think with clear enough specs on what the internal data structures should look like, the three parts should be able to be written mostly independently and then combined into one project.

I would also like to start C/C++ development earlier in the semester. I am going to try and restructure exercises and lecture slides so that C/C++ and Python assignments are interwoven throughout the semester. I hope that this will prevent the feeling that I got that the semester was split into two distinct phases, the “python” phase and “C++” phase. That way the content can follow a logical flow and touching on the merits of each language. A brief example of what I’m thinking about:

  • simple line parsing (one primitive type, e.g. double/int per line)
    • in python
    • in bash
    • in C++
  • processing command line arguments
    • in python
    • in bash
    • in C++
  • parsing text lines into an array structure
    • you get the picture
  • parsing text lines into a hierarchical structure (e.g. command parser)
    • probably drop bash for this case
  • manipulating lists
    • python list comprehension
    • C++ stl algorithms
  • Inventory Management (python)

And I am toying with the idea creating a similar progression (overlapping mostly) that will cover fork/exec, basic IPC with pipe and lead to a simple shell. As I mentioned in the “Think about it” of the pipeline assignment, all were missing to create a basic shell program was a string parser that would parse something like “generator | consumer” into an array. Along those lines, I may adjust example code in the “Make a Makefile” assignment to use flex/bison to generate a simple command parser instead of an arithmetic parser.

As those of you familiar with bash are aware, as the complexity of the algorithms and data structures we work with increase, at some point bash will become overly cumbersome. At this point, it will be relegated to the task of writing unit tests of sorts for each assignment (Thanks to George for the suggested assignment.) This will make bash a more integral part of the course material, there was a notable lack of bash this past semester, which I regret.

Classroom Time

I’ve been doing a lot of thinking about how to use the classroom time effectively in a way that makes everyone want to come. I think it’s really important that everyone shows up regularly, not just those that feel they need some extra guidance, but also those who have been programming in a *nix environment for 10 years. It’s really important because both the novice and expert can learn a lot from each other if they’re in the same room. It also makes my job easier. There are 60 people enrolled in the class in the Spring: it will be nearly impossible for me to check with everyone individually every time there is a typo in an entered command. Getting a second set of eyes looking at everyone’s commands and code will help people avoid extended debugging sessions and make people more aware of common typos and bugs. To that end I would like to do more collaborative discussions in the classroom, and less of me talking. Regarding assignments, I’d like them due and committed to a network accessible git repo at the beginning of class. Then, in class people will pair up, fork each others’ assignment, review, make edits, and initiate a pull request so that the original author can merge in any bug fixes. The grade for the assignment will be determined by a combination of the functionality of the original commit and the merged changes. This probably won’t take place after every assignment, but at least a view of them.

Depending on how efficient we become at fork/review/merge, I’d like to have more discussions like the one we had about the Process Object assignment. I will try to come up with 3 or 4 “make you think” type questions for each assignment and then in class break up into groups, each discussing one question in depth, then come together as a full class and share the response each group had.

Reflection

I think this post turned into more of a “What I plan to do next semester” more than the reflection I had intended. Because it’s probably already too long I’ll try and come to a close. The first semester I taught this course I pretty much followed the supplied lecture slides and exercises that were given to me. The second semester suffered from “all this stuff should be changed but I don’t have any rhyme or reason to it” syndrome (not unlike second system syndrome that Raymond talks about with regard to Multix). The next couple semesters, ending on the most recent, I have been tweaking and polishing and streamlining. There were still some bumps this past semester that I would like to eliminate (issues with VTLUUG attendance, problems submitting the midterm, lack of clarity on some of the assignments, much too long a delay on returning some of the graded assignments, to name a few), but I’m optimistic that the next revision will address many of them and hopefully provide a smoother and more enjoyable experience for all. Remind me to write another post about my vision for the class :)

*and now I’m 10 hours in… only 4 more to go!

Last Post – Goodbye World!

Okay, not really goodbye, but this is where my blog for this class comes to an end. Yeah, they were kinda cramped and totally all at the end (sorry), but it was seriously good to sit down and reflect on what, throughout the semester, was REALLY worth writing about. Thinking back may be good, but writing about it really helps you think about what you got out of the semester. If it wasn’t particularly significant, you realize it because there’s nothing to write about it.

Improvements? Well for one, I know that physical attendance in class was lackluster at best. Maybe offer an incentive to actually show up? There were quizzes, yes, but they were all online and doable from home, as us college slackers are so quick to figure out. Class was interesting enough, but unfortunately that doesn’t guarantee attendance. I’m not blaming the class itself for this, but a change may be needed. Just a suggestion.

Office hours should be more convenient. There were many times that I feel like I should have gone, but it was only possible to meet on friday–and on friday, I didn’t want to or forgot. Maybe that’s just my issue, but it would have been more convenient to have it on a day that I was going to be on campus, and not ready to crash and go home. Sometimes physical presence is more helpful than gchat? I don’t know, something to think about.

Anyway, I had fun in the class. Writing is a bit cumbersome to me usually (which results in procrastination), but the things learned in class is definitely going to be useful later.

Thanks, and have fun with next year!

-Brian Chen

Posted in Uncategorized

VTLUUG

Surprisingly, this was not the first semester that I have been to VTLUUG meetings. I had heard about and attended VTLUUG meetings last year, when I knew one of the officers and another friend that attended as well. The officer graduated, so alas me and my friend stopped going. When I found out that going to meetings got us class credit, I was more than willing to go back. While many of the people I knew were no longer there, it was nice to know that the club wouldn’t be completely new, and that I wasn’t just going for class. Granted, the knowledge of most of the people far surpassed my own, so I felt a sort of disconnect between what I could contribute and what they were discussing, but it was better than nothing. They were talking about things that I had no understanding of, so unfortunately meetings could get dull. When they brought up things I had just explored from class, however, it was cool to see how much they knew and how deep that particular thing could get. They also touched on other things, being so technologically inclined, so I learned about a bunch of other things that weren’t necessarily Unix or Linux related, such as tor. Did you know that VT hosts a tor node? I didn’t.

 

Posted in Uncategorized

Learning the Unix Commands

This is post I should’ve written at the beginning of the year, about the way we learned a good amount of the shell commands we were going to have to take advantage of over the course of the year. That would be, of course, Unix Command School. The fact that Unix took individual commands preprogrammed to do certain things reminds me of last year, when I used to have to program in assembly. Assembly works in much the same way, with individual commands that would  move around registers or bit values. Now, as I began to learn more and more about commands, the more parallels I drew. Registers were kind of like the unix file system, where you could move bits around to different registers and check what was in them, like you can move files around in folders in Unix and list their contents.

Learning everything at the beginning was definitely a good idea, like reading a manual or instruction sheet before a project. While I’m sure I could have just jumped right into the first homework assignment without doing this, it would have taken much longer to search, individually, for every command i think I would need. Actually, the best thing was that Unix Command School told me what I COULD do, and thus I knew what I needed to do when it came time to do it.

Posted in Uncategorized

VMware/VirtualBox

So we have to run Ubuntu. I tried to dual boot, but for some reason the bootloader is freezing somewhere along the line, both with a live cd and with a live usb. My computer’s boot time is too slow to bother, anyway. I’m going to run a virtual environment.

I’ve used VMware before to emulate ubuntu before, so I before looking at alternatives I just went ahead and booted up my old environment. I thought it was tedious to load up VMware and then boot into it by loading the .iso, so I looked for a more elegant solution. The current most popular solution, which I did not know existed when I looked last, was a piece of software known as VirtualBox, a virtual environment preloaded with all current, most popular freeware operating systems. Choosing Ubuntu from a drop-down list took all of 10 seconds, and within 2 minutes I was up and running. I dedicated about 8 gigabytes to this environment, and it saved everything I as it was when I booted up and shut down, just like  a real system. Not only that, but I could seamlessly switch between Ubuntu for class and windows for everything else whenever I wanted to. I couldn’t do that if I was dualbooting. I was actually pretty surprised with how refined virtualbox was, as if there was a whole community of people that only kinda wanted to use Ubuntu but still didnt want to dualboot. In any case, it really was a great tool to use.

Posted in Uncategorized

Midterm Test

Well, that was interesting. It was certainly given in the most unique form I’ve seen so far at tech. It took a little bit just to get into it and understanding what I needed to set up simply to begin the assignment, but once I understood, the midterm really wasn’t bad. I guess my initial confusion came from the two hour time constraint, being that I heard it takes every minute that we’re given, so I didn’t really read the preface closely.

Anyway, that test was actually pretty fun, save for the last part. Part 2 through 4 though, where it asked what certain commands accomplish, felt like an easter egg hunt, except I had to think of a command and test it until I found what it does. More or less what I normally have to do for an assignment, except I had a ticking clock bearing down on me. Still, I didn’t really mind those parts. There were two questions that I simply could not figure out, but I’ll chalk that up to the fact that there are so many commands.

The last part was pretty tough. Debugging the program was simple enough, I think I just changed a parentheses or an indentation and it seemed to work. I spend the remainder of the time trying to figure out the second choice of three, but unfortunately time ran out. Still, I didn’t feel too bad as I hit the submit button. I think that test wasn’t too easy, but was too bad either.

Posted in Uncategorized

Recap plus Final Project

What a semester.  Finally done with all finals and I finally have free time.  This semester in Into to Unix was quite interesting.  I expected the class to be somewhat like ECE1574 or 2574 where we simply just code in a unix environment.  It turned out to be somewhat of a surprise as I learned much more than that.  I didn’t even know what piping was before coming into class.  I’m also much more knowledgeable on many aspects of the Ubuntu.  I might be using bash commands a good number of times in the future.  Learning python was also a good refresher.  I had only known about simple python programming beforehand.  Learning about the history of unix and its impact on the world today was also a big eye opener.

I also realized that c++ on unix is very different from a windows environment.  I had only used visual studio before on windows.  The coding itself is the same, but using g++, gdb, makefiles, etc, makes it a completely different process.  Very enlightening.

With regards to the Final Project, we will be fixing it up soon.  We’ve read the comments and appreciate the feedback.  All of us had many finals so there hasn’t really been much time to edit the project. We will be getting to that soon.  Don’t think we were ignoring comments. =)

Hope everyone has a good break.  I’m out.

Final Project

So a big part of this semester is the Final Project. My group is doing a room reservation manager, where a properly implemented system will allow students and staff of Virginia Tech to choose any room on campus, a date, and a time frame. Assuming there are no errors, pressing “book” will book that room. Simple, easy, and hopefully useful. A room cannot be reserved twice at the same time, and cannot bridge dates. Admittedly there aren’t very many bells and whistles, but at it’s very core, we believe that it does what it should. By the principles of Unix and it’s rules of clarity and transparency, our project is very straightforward and easy to understand. It’s also find that it’s very adaptable, in that it would also be easy to add any bells and whistles we (or any potential clients) may want added. We realized that some rooms on campus have two room numbers or can be split in half, so adding that functionality would be one of the things we could appreciate in the future.

I appreciate the group I’m in. All five of us have contributed to the project, and it doesn’t feel like we’ve left anyone out. I know that not all groups are this fortunate, so I can appreciate everyone’s help–particularly based on groups I’ve had for other classes in the past. All five of us are friends, which made completing the project nothing short of enjoyable either, giving us a chance to hang out after work was done. I also hope that we all feel the work was evenly distributed, and we all contributed on the paper as we had on the code. All I can say was that it was one of the better projects I’ve been a part of.

Posted in Uncategorized

Github Talk

Well, how convenient. After having to deal with Github a few times, Virginia Tech’s very own ACM announces that a speaker from Github will be giving a presentation in mcbryde. ACM stands for Association of Computing Mechanics, and is primarily a computer science majored club, but either way they always bring in speakers form companies to give talks that I enjoy going to.

In any case, github is way deeper than I had imagined. It’s not just simply a code bank, but it is useful for many other purposes as well. They have offshoot services called Gist and Gauges that the speaker talked about, as well as showing us how to manage files through the shell alone. They way they ran the talk was also pretty unique, where he didn’t just stand on the podium and speak to us with a few visual aids. Instead, the speaker had his computer connected to the projector and showed us what he was doing on-screen while explaining it at the same time. He answered questions while typing out examples, and even had another window up that gave a visual indication of what was going on. I brought my laptop, as they encouraged, to follow along, but unfortunately I got lost about halfway through. Still, I thought the explanations were good enough to understand what was going on. It really was interesting, which is more than I can say for many of these talks.

Posted in Uncategorized

Github

What to say about Github. It certainly seems like a good idea. I mean, a central repository of open code that anyone can see and review is a great way to collectively improve a product that works in everyone’s benefit. There are a great many online businesses that serve a demographic that have their code open for review on Github, such as reddit. This move, I know for a fact, has resulting in an influx of improvements to the website since it’s adoption. Not only could the more code-savvy of their users go in to look for problems, they could actually write the code for an idea they had before proposing it to reddit’s creators, significantly boosting the chance of that idea being realized. While this might not always be that effective, a website such as reddit has a devoted enough userbase that keeping the base code open source has brought nothing but good for the community in general.

For my purposes, though, Github is a little confusing. While I do admit that I can see why it would be useful, it seems like a strange middleman. I realize that having everything in a central location makes it easy to look for and grade homeworks, which is totally fine–however, pushing code to github behaves in strange ways. Whenever something works one time and not another, and I didn’t know what I did differently, Einstein’s famous quote tells me I’m insane. In any case, git push sometimes brings me to a comment screen, while other times it will just say that it was successful. I’m baffled, but I’ve at least been able to figure out that if I try enough times, it will work. I know that I don’t understand it well enough, so I’m not blaming the system, but it seems complicated. It is, however, really fun to see and explore the sheer volume of code on their servers, though.

 

Posted in Uncategorized