I recently applied for an internship with a company called Premier which has a site 10 minutes from my house back home in Charlotte, NC. This company makes medical equipment for hospitals around the US. I was in contact with this company last summer but I was unqualified for the internship position because I had yet to be exposed to shell script. Unix has so far prepared me and exposed me to shell and bash scripting which I would be using this summer during this internship. I will hopefully obtain this internship so that I can further expand my knowledge with scripting.
Monthly Archives: October 2012
difference between students
I think that one of the main things that separates a good student from a great student is one who is motivated to find out why an answer is what it is; to understand the problem and how to arrive to the solution. This may be hard for students with time management problems but managing your time is a very essential skill that will also help you in your later life.
Intro to Unix ECE 2524 Entry #7
It’s been a while since my last post so need to get back on it to be sure I get 10 in before the end of the semester. Haven’t had any assignments in Unix lately which has been a nice break. I ended up getting the futures paper done to get me some added points to my total grade. I’ve also gotten a fair amount of work done on our battleship final project. I’ve gotten most of the text based part of the game done and implemented in Qt; this should give us a good base should we have time and choose to implement a GUI. Error checking is always one of the things I hate most about programming because there’s just so many stupid things that a user could input that you have to check for and handle. I think I’ve gotten everything covered in terms of inputting bad coordinates and so on. Currently the ships are only one size big, and they need to be re-implemented to the correct size, and error checking needs to be done in terms of placement, i.e. checking for overlap or run off over the screen.
As for 3574, we had our first test this past Thursday which seemed to go pretty well to me. Most of the information was easily found in the book or online slides from the book, and I can’t imagine getting a poor grade on this test. The past homework has been quite difficult, and it took me awhile to get the thing of moving back and forth between different UI forms via signals/slots, and hiding/showing different widgets. It has however been a lot more fun to write than previous assignments. Getting used to QtDesigner took me a few minutes, but it is very intuitive, and makes creating GUI’s so much easier than coding them by hand. As part of the assignment we had to implement tic-tac-toe and write our own algorithm for the computer. I think I have gotten pretty close to if not an unbeatable computer player. Hopefully the homeworks will remain interesting, but now that I believe we are done with GUI’s, I’m afraid I will lose a lot of my interest.
Some thoughts on Debugging C++ using QtCreator in Ubuntu
As of right now, we haven’t covered Unit testing so I don’t have much to say about that although I have heard from CS friends that it is a very important tool.
However I have noticed a few things from doing C++ programming in QtCreator.
1) The compiler will usually spit out an error that pertains to what you did wrong, and should be a big enough hint fix it
2) The program compile, but exit with no error code
Having 2 happen is very frustrating, but after several months of working with Qt I can now confidently say that this usually only happens when some sort of memory is attempting to be accessed that does not exist or has not been initialized.
For example, for most projects in Qt some sort of List (QList) will need to be used. In order to use a QList, the type of data members stored in the List must be specified (i.e. QList<QString>). However, one must be very careful not to try to members in a List if they do not exist.
If a QList called listName exists, it is always preferable to used either listName.front() or listName.back() if there aren’t many things in the list and you just need one or two things. If you need to cycle through the list, and get everything out of it, it can be helpful to make a temporary list, and pop_front() within a while loop that runs only while listName.size() > 0.
Before I figuerd this out, I would just use array-like functions to get to the data I wanted (ie listName for the front). However this is not good code because there can be unforseen consequences when you exist the list to have at least 2 or 3 members at all times. By doing what I mentioned above, at least the program won’t quit on you without telling you what went wrong.
Workings in Ubuntu and C++
I haven’t posted in a while because yet again, I have been slammed with projects and tests. But after our meeting last week to discuss our ideas for a group project, I have been thinking about how to best update it. Our original design is pretty good, but there are several features that we have the choice to add or not. However, just adding one part and not another in some cases doesn’t make logical sense. Therefore, I have been trying to figure out which functions would best be implemented so as to minimize the amount of coding clutter and maximize the abilities of our program. It seems to be an extremely interesting balancing act so far.
ECE 2524: C++
Hi everyone, This week we started on C++. We learned about G++ and GCC compilers.
I programmed in C++ before but using MS Visuals. So the commands like -Wall -g were
new to me. However, I found it simple. ‘-Wall’ just turns on the warning when
compiling the c++ code. We also learned about argc and argv. The thing that I was confused on was
that argv is an array of arguments including the name of the executable cpp file. I
thought it was just the arguments. However, it was arguments with the name of the
first post in a long while
Unfortunately, I’ve had a massive workload over the last couple of weeks and as a result I’ve completely forgotten about this blog and haven’t posted to it. I will try to post as much as possible over the next couple of weeks to make up for this. Since I do alot of coding for my classes, I usually have a large amount of subjects to blog about. The first subject, I would like to talk about is commenting code. As everyone knows, comments can make or break the code. It allows the reader to know exactly what you’re doing and how each part of your code contributes to the whole. Since comments are so important, I’m finding the lack of standardization on comments a little disturbing. While there are various guidelines to how one should comment code, I firmly believe that there should be some sort of industry standard on code commenting, especially between different programming languages. Even in the same programming language, there are so many different ways to comment your code and every person has a completely different way of doing it. For example, when coding in C, I prefer to add a short comment at the end of a line with // where I need to explain anything. However, some of my professors like to use /* */ blocks on top of the code section, even when very little explanation is required. I find that this sometimes disrupts the flow of the code. You may be reading something and all of a sudden a big comment block pops up out of nowhere, and it potentially might not tell you anything important. Additionally, different commenting styles can result in random placement of code that results from differences in indentation. Someone may be using tabs and // after lines to comment and it may look perfectly fine in one development environment, but someone else opening the file up may have skewed commenting due to different screen sizes and tab/space differences. Without some sort of standardization, individual commenting styles can be cluttered and messy. I also think there should be some sort of standardization across programming languages. For example, python coding uses #, C coding uses either // or /**/, and I believe HTML uses <!– –>. While it is understandable that they are all different for different reasons, if all coding languages had the same comment markers, it would streamline the process. Adding that to a commenting standard that specifies where, when, and how to comment, it may potentially allow any programmer to read code in any programming language. This can be good for both education and practical purposes.
C++ in the Unix Environment
So this week we started getting into creating and compiling C++ in Unix. I’m kind of glad because this is material that I am familiar with (at least the C++ part). I’ve done some work with C++ in Unix in ECE 3574 which I am taking now. But most of that work is in Qt IDE, so it is a little different.
I’m actually surprised at how much time I am spending using Ubuntu rather than windows. Between 3574 and this class, I probably spend an equal amount of time in both. And I find that when I am done working on a project in Ubuntu, I tend to stay there and use it. It’s pretty crazy that after a little more than half a semester, I feel almost as comfortable in Ubuntu as I feel in Windows, which I have been using all my life.
I have added a quick reference to tmux session pairing in the Resources and References section under the Week 9 section. Please note it is not a detailed guide of all the aspects and security implications of using tmux to share your terminal session; make liberal use of Google or another search engine to get more details.
ECE 2524 Post #9
Last week we met with our ECE2524 TA and discussed our final projects. My group wanted to either do a GUI based calculator (with more than just the basic functions) or a text based shoots and ladders game. We discussed how each of these ideas could implement UNIX's programming rules/laws. With the calculator we use the coding with modularity idea by splitting GUI part of the calculator and the actual calculations part. With the shoots and ladders game we could use different rules and such depending on difficulty.
After discussing as a group throughout this week, we decided to do the shoots and ladders game, because we figured we'd have more fun with it even if its initially a little more complicated. Also we decided we will be doing this project in python. Initially I wanted to do it in C++, just because it'd be easier because it's what I'm more familiar with, but I think doing it in python will be good. I need more practice with python and this will be good practice.
I look forward to starting on this project, and beginning the planning phase next week!