Latest Entries »

A Mountain and a Talk

Climbing the “contributor mountain” is by far the most interesting thing I have done so far throughout my college career.  Not only has it opened my eye as to what I can do to help improve my own programming abilities but also to be able to help others at the same time.  My mind is filled with new ideas of how I should go about solving problems and a craving to do something more with myself as both a programer and as a scientist.  Now the only question is to go with game development or artificial intelligent research for my main focus?  Back on topic of contributor mountain.  I feel as I progress to the top that I feel more like a seeker then a collaborator or contributor.  I guess this is mostly due to the limited time we have to do things during a semester with other obligations.

On another note, we had a guess speaker come in Thursday, December the 8th of 2011.  His name was Tom Callaway; He was the one that came up with “How to tell if a FOSS project is doomed to FAIL”.  His talk was about  “This is why you FAIL and how to avoid it”.  He explained a little about himself and some of the projects he worked on that led him into making his “chart” of how to tell if a FOSS project is going to fail.  He made the talk very entertaining with some jokes and stories about some of the projects he worked on that related to different parts of his chart.  One of the funny ones I remember was about how this one guy made his own build tools to build this “cool program” of his, but he had his build tools in the same format which needed said build tools to build it from source.  Oh the funny things some people do as developers that end-up drive people insane at times.

I guess the main idea am getting from Tom’s talk is to keep your projects clean and neat as possible if you plan on making a FOSS project or contributing to one.  I know Tom’s “fail chart” was made mostly for FOSS projects, but it seems it can be used on other programming projects as well.

Link to Tom Callaway’s  “How to tell is a FOSS project is doomed to FAIL” if you would to check it out

http://www.theopensourceway.org/wiki/How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL

The Long Road of Learnning Design

Information overload is what I feel when going over all the different design for software engineering. There is the software architecture design which is completely new to me. It’s very strange, yet useful. However, trying to figure out how to make an architecture design is not simple at all. To make things more troublesome in understanding it there is a list of different kinds of architecture that are used for different situations. Oh well, I got to start somewhere in all this waterfall of information. The only question is where to start. Perhaps I should look into something simple to help me in understanding how one goes about making a software architecture from scratch. If that is not helpful I can always go over the in class readings for my computer science class till I can find something that would seem like a good start to Google for information.

Now software UML,(Unified Modeling Language), diagrams are another story. I learned about them from the last time I took this classes, so I have a slight understand of how they work and how they are used. There still little confusing to get use too, but I can see how they help when it gets down to programming the code. The only thing that is difficult about UML is when working in groups every one has a different idea as to how something should be displayed, or I should say how each person see how something is written in UML compared to another person. This is really tricky trying to learn UML and working with a group when you are trying to implement it for the first time. It might be easier if I try to make UMLs on my past programming assignments to eliminate the group factor in learning how to implement UMLs better with out the confusion.

Last week, October 6 2011, we had a guess speaker come into class to help us better understand the subject material on both Xfce and magnifier software. The speaker’s name was Joanie Digg from the GNOME A11y community. There was a lot of information on visually impaired people as well as some insight on magnifiers. I didn’t expect to be thrown so much information at once on both subjects. Kind of funny, I should be use to information overflow by now.

Any way, it seems that I may have overlooked some important part of the project, or more likely I thought something different then what is actually needed. I thought the project was to make a web-cam application that can zoom in on reading materials to make it easier to read. However, this was not the case. The project was about making a software application to replicate the abilities of a hardware magnifier. I didn’t even know what a hardware magnifier was until later that night.

Like I said before, I didn’t know what a hardware magnifier looked like at all till later that night. Joanie Digg was giving a more detail talk that night with an actual hardware magnifier to help us better understand what we where trying to replicate. While looking over and trying to understand what I was going to try and replicate in software, Joanie was going over how to install this interesting piece of software that we could use to view different states of an application. The program was called accerciser, and man did I have trouble getting that thing to work. I did get it to work a few minutes after Joanie’s talk was over, but I still don’t understand how to use accerciser or what it is used for. I went and looked it up on the GNOME web site to try and understand it better in hopes of learning how to use it. Yet still I have no clue at all of what it is used for besides allowing me to see different states of application.

For any one interested in learning more about Acceriser here is the link to it: http://live.gnome.org/Accerciser

IRC and GNOME Mailing list

Next assignment was to observe an IRC(Internet Relay Chat) channel for 24 hours and look at some GNOME mailing list that I might like to join. Man was this tricky to do. The mailing list, easy; watch IRC  for 24 hours, hard. Rather then leave my laptop on for 24 hours nonstop, I broke up the time I would watch the IRC down to a few hour each day. The first few days, nothing. There were people in the IRC channel, but no one was talking. It was like this up till the second day when some one was asking for help on some python. The person didn’t get a response for a very long time. I was around 17 hours into the IRC on my 4th day when all of a sudden an explosion of chatter. Most of the early parts of the IRC that day was on GTK, but the rest was on bugs from Bugzilla. I noticed that Orca and Nautilus were mentioned, so I looked them up to discover that Orca is a screen reader and Nautilus is a filing system. Oh ya, back to what I was observing. There was a small window of time where no one was talking at all. I assumed they were getting lunch or looking at something else for a while as some people added dinner as part of their nicks. I was done at this point, being at 24 hours, but decide to leave it on for a little longer to see what would happen next.

Well after a long day of looking at my lucky day on IRC, I figure that am actually getting the hang of understand what is going on. People from different FOSS projects jump in and out asking questions. Some from the same FOSS community and others from different ones wishing to get help. I’m still lost as to whats going on, but I’m getting the idea of how IRC is used and how it can help me later in my software engineering class. I observed the IRC channel in GNOME a11y for about 27 hours and 10 minutes. The time was well worth it in the end to see how people actual use IRC. I might jump into the GNOME game IRC and lurk there to get a better understanding in an area that I wish to work in.

The other part of the assignment was to look at the GNOME mailing list. I took a quick look for anything that would be interesting for me to sign up and try my hand at getting into a community. I was able to find three which two of them being game related. One was about Python AT-SPI bindings, but I thought that might be a little out of my skill level to get into at the moment. The second one was games on GNOME. This one I joined right away knowing it was for the development of games. The third was wiican which is about getting the wii remote to work in GNOME. I find it interesting, but I lack the extra wii remote and free time to try this out at the moment.

Now that this assignment is over am going to go and find the GNOME game IRC channel and lurk there form time to time.

Blog about Cheese vs. Ekiga

Before Tuesday’s class, one of the FOSS(Free Open Source Software) community members, Mel, who we meet in class today using IRC(Internet Relay Chat), wrote a blog about our observations on Cheese and Ekiga. It was interesting to have some one besides the professor give us feed back on what we learned. As I read it and saw the things other student in the class notice that I didn’t; it made me think as to how we all came up with different findings. Did I go about it the right way in looking into both Cheese and Ekiga?

As I continued to read I was learning that there is far more to both GNOME Cheese and Ekiga then I realized. I knew I didn’t find everything on the assignment, but there is so much more. It is actual far more interesting to me now that I think about it. I spent so much time on getting Cheese to work on my VM(Virtual Machine), that I didn’t take the time to look into its history more deeply. Ekiga on the other hand is fare more then what I originally thought. Ekiga being about 10 years old for a FOSS project did not occur to me as being very old.

Overall, I guess what I learned from reading Mel’s blog is that there is a lot more to the FOSS community and it takes time to get use to it all. Looks like I got a long way to go till working in FOSS start to become second nature to me.

Here is a link to Mel’s blog if you wish to find out more on the subject: http://blog.melchua.com/2011/09/12/cheese-vs-ekiga-for-software-engineering-class-responses-to-student-notes/

Today in my software engineering class we got to use IRC(Internet Relay Chat) to help us try and solve an important problem. Our project for the semester is currently to make a zoom feature for a webcam application. The problem is GNOME Cheese, one of the application were looking at for the project, will not work in a VM(Virtual Machine). The other option is to use Ekiga, a Skype like program, instead of GNOME Cheese. With Ekiga we don’t need to use a VM to use it. However, the problems with using Ekiga is that it may all ready have a zoom feature. After doing some quick looking around on goolge I found Ekiga does indeed have a zoom feature… So Ekiga is out.  I’m beginning to see us stuck inside a pickle jar at the moment.

All is not lost yet, for we still have a few options left for us.

1) Set up 2 machines in the CS/IT lab to have Linux distributions with GNOME Cheese.

2) Switch to another project called XFCE.

Looks like its going to be a difficult call. One would be fun to work on, Cheese, while the other would give me some new experience in something I’ve never delta with before. So little time, and only one FOSS project that we can work on. Ether way, my vote may determine what one we will be work on for the class. Pick the one that is best for me, or pick the one that is best for the class and my team. Oh boy, this is going to be hard… I guess I’ll look more into XFCE before I make my choice.

2nd Attempt

This fall semester is going to be an interesting one for I am retaking software engineering. I originally took the class back in fall semester of 2009, but needed to take time off to deal with some issues that were interfering with my studies. Now with the problem resolved with a quick fix of me moving back on campus, my studding habits have almost gone back to normal. Now all I need to do is just work on my focus and keep it from jumping from one programming project to the next.

This time around I have some important goals for myself to accomplish before the class is even over.

Goal number 1: learn how to make and keep good clean documentation for programming projects.

Goal number 2: gain a better understanding of how to work in small groups on programming projects.

Goal number 3: teach my self not to think in java code for all pseudo coding related documents (I still don’t understand how I even got into this habit).

Goal number 4: pick up as many interesting ideas that I can apply to my own programming projects.

Wow, didn’t think I was going to have this many goals to tackle this semester now that I think about it. Guess that side project with Max might need to be put on hold till after the semester in favor of picking up python.

What do I expect to accomplish this time around? That is a good question. I don’t really know to tell you the truth. However, there is one thing I wanted to accomplish that I was not able to do the last time: work on an interesting programming project that seems fun. Well, I mean all projects are fun in there own ways, but I want to work on something with more interaction. The last project was a copy and past function… boring in my eyes. This time however were going to add a zoom function into an OSS(Open Source Software) webcam application. Now that is what I view as fun.

Lastly, what do I want to learn from this course? I want to learn how to break a project down into manageable chunks to find what the requirements are and how to go about designing the code. If I could learn that I could start to go about making my own side projects a little more professional, or at least make them easier to jump back and forth for my sake.

Well, that is all I have to report for this segment.

Systems Operational

Systems operational as of 9-11-2011, or at least my blog is.

Any way, quick introduction as to what my blogs are going to be about:

1) School work and life (college at the moment)

2) Personal projects (my side work)

3) Random thoughts (anything that comes to mind that I feel like posting about)