Loan Ranger

Status

Haven’t posted anything in a long time. College is hectic. My bad.

So I’m taking a course about mobile application development, in particular for the Android platform.  I’m working with two other students to make an application for use by Farm Credit Financial Partners (FPI)‘s loan officers. It’s called Loan Ranger (credit to my roommate Dan) and will assist loan officers working in the field by allowing them to collect property information and upload it to a central location (their offices). It’s very exciting as I also am planning on talking with them about summer internship opportunities, and then maybe they’ll be nice enough to give me a job someday (here’s hoping).

Project updates to follow!

Dec 22

Pattern Recognition Final Project for AI

Posted on by

I spent about 25 hours or so on my final project for Artificial Intelligence this semester, so I wanted to at least show it off a little. It is called PARTY: PAttern Recognition utiliTY (lame) and can be trained to recognition 26 distinct 9×9 pixel grid patterns.

ScreenshotIt uses a Perceptron-style learning algorithm to determine which pattern class the test pattern most closely resembles. To enhance its recognition ability, the system is trained with each pattern a total of 20 times: once with the original pattern, such as the one above, and 19 copies with single randomly-selected pixels to be changed. Please read the included Documentation.doc file for instructions on using the program.

Download link (source included): Perceptron.zip

An executable Party.jar is included, so just double-click it to run the program. Or, run “java Party” in your command prompt from the folder where you’ve extracted the archive.

Dec 06

Tom Callaway’s visit to Western New England University

Posted on by

On Tuesday night, December 1, 2011 Western New England University received a visit from Tom Callaway, Fedora Engineering Manager. He came to speak to our CS-490 Software Engineering class and a collection of other individuals to help us further explore the world of open source software development. After he introduced himself, he handed out a number of “Exploring Open Source” flyers (and stickers) with application biographies over a number of fields such as graphic design, photography, and music production. Both teams from our class had representatives from their groups their at this point so we each briefly introduced our class projects, and it was refreshing to see that Tom was familiar with both the Xfce desktop environment (pertaining to our project) and GNOME Cheese (to the other group’s).

“This is why you FAIL and how to avoid it”

Presented by
Tom “spot” Callaway
Fedora Engineering Manager

I. Success

First, Tom talked about success. Namely, he stated that the basis of success in open source development lies in the ability for others to join you in your work. “Having users is a success, but what you really want is people helping to make it better”, alluding to the fact that there are different criteria for a project to be successful. He particularly stressed how it’s cool and reinforcing to have real people using your product, but in open source development you also want to sway people to join in and help you make it better. He outlined a “healthy community” of FOSS developers working on a project together entailed users helping each other, regularly-scheduled and significant releases, and people willing to help and contribute to the project as a whole. This doesn’t mean just contributing code, though: there are many other ways to help out, such as by writing documentation, reporting bugs, or even maintaining a web site/wiki/forum for the developers to communicate using.

II. Points of FAIL

The second part of Tom’s presentation talked about the potentials for a project to falter in its establishment and growth. He has created a point system called “Points of FAIL” that attempts to serve to be a heuristic of how likely a project is to succeed; not that it just gets “finished”, but to also attract other developers and contributors. This point system was proposed not only to measure your own project’s faring on his scale, but also other existing projects that you may be thinking of becoming involved in.

Some particular areas in which a project can “FAIL”:

  • Size of the codebase: “The bigger it is, the harder it fails”
  • Source control: “There is no good reason for a FOSS project to not have public source control” (e.g. Gitorious or GitHub)
  • Using some obscure/made-up method of compression (mind-boggling).
  • Not doing releases.
  • Not having a web site.
  • “Your code depends on Microsoft Visual Anything”

Honestly, his presentation was pretty hysterical because I’m sure everyone else in the room have run into mind-blowing scenarios in code exploration that makes then ask “Why would anyone ever do things this way?”
However, while “Points of FAIL” outlines a lot of good “don’ts”, it is a bit discouraging as far as immersing yourself in a project. There are a lot of obvious pitfalls that would sink any FOSS project. Seriously, someone wrote their own compression program and used that for their code? That’s clearly something to avoid when looking for a project to contribute to. But as far as things like projects not having web sites or public source control not set up, these aren’t necessarily red flags saying the project is doomed to fail. Actually, I think those could be some of the best projects for people just getting started in FOSS. As Tom says, these are the basics that are needed by any project, so maybe they don’t exist in FAIL projects because people don’t have the practice or experience using them? Someone needs to make the web site and document it and write the licensing, and these are very important (basically necessary) skills to have to maybe the best time to get used to it is before jumping in and fixing technical problems in the code.
Specifically, I think these points of FAIL are good things for people to fix in a project before getting too involved programming/design/bug fixing -wise (again, here is the list), and are not necessarily points of FAIL at all unless the project has been around and is already well-set in its ways:
  • Everything in the “Source Control” section
  • There is no documentation on how to build from source
  • If documentation exists on how to build from source, but it doesn’t work
  • Your code has no “make install”
  • Everything in the “Communication” section
  • Everything in the “Licensing” section
  • Everything in the “Documentation” section

Granted not all of these things are the best choice for someone to fix as their first contribution to a new project, but imagine you have a bit of writing and legal experience: You can knock of several hundred points of FAIL without having to even know how to program. If you know anything about making a web site, which is really easy nowadays, you can make even a couple simple web pages with the project information and the contact information of those working on it.

Tom Callaway’s presentation was awesome, but I think his “Points of FAIL” would be better off shortened and more-so as a checklist of dangerous project pitfalls. Also, being in the position of just getting started in FOSS and contributing to a large, well-established project has made me realize that there are a lot of details and components that must be in sync, including the people involved.

Tom Callaway on LiveJournal: http://spot.livejournal.com

Nov 09

Design in the FOSS World

Posted on by

Since my team and I have been working on our project, Voiceboxx, for our software engineering class, I’ve been getting a crash course in learning about software development in the open source world. We chose our project (more on that on the projects page) without having any kind of idea how we would implement it, without knowing if what we wanted to accomplish would be possible, and largely without exposure to the various elements of our endeavor. However, such was the point, so my group members and I have accepted the challenge of being more or less tossed into a scenario with just some basic tools and collective skills. But the point isn’t necessarily to fix or create anything, but rather to learn about the atmosphere of developing in an open source environment.

Technical skills have been learned: GIT repositories, Linux file system structure, terminal use. I’m learning about shell scripting, something I’ve certainly never touched before, and our team anticipates having to program in Python in order to interface correctly with a third party application. None of us know how to use Python, but still we press on with our project, unsure about most of the details and entirely unsure if what we want to accomplish will ever really happen. So why are we so optimistic? We’ve all agreed that this should be possible, but most of the team is in over our heads. So why do we think we’ll really be able to accomplish our goals and implement Voiceboxx into a desktop environment that, again, none of us had ever heard of, let alone attempted to develop for?

The hospitality and openness of the FOSS community. Namely, those Xfce developers that have (without any real reason to, really, other than dedication) gone out of their way to answer our various questions. One person in particular answered about five of our questions we posted to the “Xfce-dev” mailing list (in less than half an hour nonetheless) in lengthy, detailed email including links to the specific resources that we were looking for… that we didn’t know we were looking for… until this person told us so.

What I’m saying is I haven’t learned much in the realms of technical ability (programming, repositories, operating system structure) in comparison to my new perspective on software development in the FOSS community. I’ve learned that even if there are gray areas in the next step of the project, it is less of a matter of specifically figuring out what needs to be done rather than documenting what has been done and knowing where to find information that will lead you in the right direction. In our team’s case, we’ve learned to use the mailing lists and IRC channels as invaluable resources of knowledge. Even if there is no one on the mailing list, for example, that has a solution to your problem, they might know where to look to find even one piece of information that is relevant. It’s a step in the right direction, which is helpful when you’re standing still. Even if it’s a step in the wrong direction, now you know:  you’ve ruled out a potential solution and in that lessened your search space for the correct one.

Without the care, motivation, and helpful nature of FOSS community members, open source software likely would not exist, certainly not as what it has evolved to today. This in itself is motivating to work on projects like this: instead of it being you versus the problem you are trying to solve, you have a community of dedicated individuals behind you, many of whom are more than happy to make an extra effort on their own part because they know this is how open source should be.

Much appreciation and special thanks to Jannis Pohlmann for all the help via the xfce-dev mailing list.

Oct 01

Voiceboxx for Xfce

Posted on by

For the Software Engineering course I’m currently taking, I will be working with three classmates in collaboration on an open-source project for Linux. Previously, the debate was between the Photobooth-inspired Cheese and the “softphone” application called Ekiga, however our team has taken interest in working on text-to-speech accessibility for the Xfce desktop environment (Xubuntu). Specifically, we have brainstormed an idea for an extension that we call “Voiceboxx”, an alternative method of interaction between a visually impaired user (VIU) and his or her computer. This will be accomplished by providing a collection of keyboard shortcuts for reading lines from the terminal, and allowing the user to establish user-defined functionality by defining custom hotkeys for common tasks.

The team, appropriately titled “Killer Bees” is in very early stages of development, but most the goal of the project is to gain experience in the software development cycle and learn from other developers in the FOSS community. Updates to follow!

Sep 14

Reponse to Mel’s “Cheese vs Ekiga for Software Engineering class: responses to student notes”

Posted on by

Mel Chua is assisting our Software Engineering class in choosing a FOSS project to work with this semester, and even nice enough to blog a response to the class’s collective thoughts on the two proposed projects, Cheese and Ekiga. She not only gives feedback on our own analyses but also shares many useful pieces of advice that she has gained in her experiences.

Do be watchful, though, of the difference between “the project looks like” and “the project is.”

Here, Mel is talking about the way each project is presented on its particular web site and how even though first impressions are incredibly important, the way a project appears at first does not always accurately reflect its current status and other important but subtle aspects. For example, a project could appear to have its act together but upon closer inspection could be only sporadically updated or mostly dead. Or, there could be underlying communication difficulties resulting in unresolved bugs and spotty documentation.

I thought this particular part was funny…

The contrast between the next two notes (from different people) made me smile:

A the time of writing there are 261 known, unsolved bugs for Ekiga.

As a project, Ekiga does not have many known bugs with only 4 noted by Bugzilla.

I’m not saying one person is wrong and the other right — but it’s probably worth the two of you getting together and saying “well, why did we come up with two different answers here, and which one should we believe?” Conversations to explore.

… However, this does pose a question about the Ekiga team’s ability to accurately track and document reported bugs. From these two sub-quotes one could suspect that maybe there were two bug trackers being used at some point, perhaps before migration to the Bugzilla application. Regardless, there is still this inconsistency that is confusing to those attempting to learn about involvement in the project.

One question that is often raised when FOSS is discussed is funding: If the software is to be used and worked on for free, then why would anyone want to work on it as more than a hobby? In our society, people expect compensation for their work (typically in the form of a paycheck), with some exceptions:

What, do you think, motivates those individuals and companies to make such donations? What do they get in exchange? (Yes, some people open their wallets solely out of the goodness of their hearts. Most don’t.)

As Mel points out, the funding for FOSS projects can come from a variety of places, but this is also what makes working on an open source project great practice with hands-on learning for computer science students. In exchange for their contributions to the project, students gain valuable experience in being involved in the project as well as meeting new contacts that can teach them even more.

Thanks, Mel, for your feedback on our responses!

Sep 12

First entry for CS 490

Posted on by

My blog has been re-purposed: at least for now, I’ll be using it mostly to reflect on progress in CS 490: Software Engineering. This is good because it has been a while since I’ve used this thing.

The focus of the class is involvement in a free, open source software (FOSS) project to gain experience in the software development cycle on a scale much larger than having to start from scratch on a class project. As of right now, it has yet to be determined whether we will be working on Ekiga or Cheese, but right now I’m hoping we can work on Ekiga because it seems generally more organized and overall more broad in technical specifications.

Ekiga LogoCheese Logo

(images property of their respective owners)

 

From this experience, I hope and expect to gain hands-on experience with working with a group on a large-scale open source application. In the past, we have only worked on small programming projects that seem to serve little purpose other than practice with Java syntax, so I am very excited to work on something that is supported by an active community and will be used by real people.

I’ve also submitted my blog to the Teaching Open Source Planet.

 

Jun 06

DevilE off the ground!

Posted on by

So my project for the summer, DevilE, finally is starting to take form. This is my first professional experience in open source programming, and the fact that it is a project that I have (so far) created entirely on my own from the ground up is very exciting. See the projects page for more information about DevilE.

So far, it consists of a “Feed” class that will represent each XML feed that is to be handled by the application. As of right now, the XML file can be retrieved from the source URL and parsed into posts (so far, only the titles of the posts can be retrieved), which are represented as objects of the “Post” subclass. Posts will be stored in an array that is returned to the code using the Feed class, which eventually will be able to display components of the post.

It doesn’t look too exciting yet, but I’m saving any HTML/CSS design stuff for later on. There will also have to eventually be a profile structure that will contain feeds, user information, etc.. There’s also a lot of documentation to be doing, but progress can still be tracked on the SoftHum Wiki. I’m currently working on the second build, which will be officially referred to as devile_indev_2.

Jun 04

Western Massachusetts Tornado 2011

Posted on by

What seemed like a normal day with exceptional weather made an unexpected turn on Wednesday afternoon. Springfield and surrounding cities were hit by a series of bad storms including a couple tornados, hail, and generally bad weather:

http://www.masslive.com/news/index.ssf/2011/06/live_updates_western_mass_torn.html

Since I had the day to myself, I decided to drive to the library at school to get some work done. Well, that didn’t quite work out how expected. At least I have a valid excuse for why my work wasn’t getting done. Here’s a recap:

Wednesday, June 1, 2011

2:30pm
Arrive at work. Nothing out of the ordinary here.

4:00pm
Get a text from Mom saying that there have been storm warnings in West Springfield and to be careful… okay, Mom.

4:20pm
Outside taking a break when one of the librarians comes out. She asks if what she sees in the horizon were birds flying, but we determined it was probably debris that was blown towards campus from the storms. Visual contact with the tornado confirmed this notion.

Library worker makes an announcement that anyone in the building should make their way to the library basement in an “orderly but quick” fashion. A little worried at this point.

4:40pm
Trapped in the basement of the library with the most random group of people and I don’t really know any of them. Boring. One guy is borderline panicking due to worry over his mother and his cats as we hear that a tornado has damaged parts of downtown Springfield.

5:10pm
Told we can go back upstairs to resume work. Things look okay outside, so I go back up into my little work room.

5:40pm
Second announcement over the intercom at the library: back to the basement real quick. This time we have to stay down there until public safety comes and tells us we can leave… let’s hope they don’t get blown away before that happens, starting to get bored again.

6:30pm
Public safety comes into the basement of the library to tell us the storms have passed, but most roads were closed between WNE and surrounding cities to the south. Inconveniently, all of my possible roads home are blocked with wreckage and downed telephone and power lines as I soon find out.

Me and a questionable older fellow (QOF) went back outside to see what we could see… which was lots of leaves, downed traffic, but no visible damage on campus, which still had power (we were reading stories on the news about the tornado as the second one(s) was/were happening.

6:35pm
QOF has a great idea: Since there seemed to still be power in our area, we should go watch the first game of the Stanley cup at Sophia’s sports bar across the street. Deal. We show up and enjoy a much needed refreshment.

8:00pm
Realizing just how messed up everything got, I realize that there’s not much I can do other than have a couple drinks, watch the game, and try to talk to people and find out which roads are open. Bruins lost 0-1 with 18 seconds last, dammit.

10:30pm
First attempt at escape. Bradley road is closed at the first intersection, which took almost a half an hour to get to (normally, this would take 2 or 3 minutes). Turned around and headed back to Sophia’s and checked in with home, which did not have power (turns out, most towns in the area were out of power for over a day and I think some might even still not have it back at the time of writing this). Oh well, back to the bar.

1:00pm
Ran into a former member of the country club that I work at. Talked to him for an hour or so, but he creeps me out so I eventually left.

1:10am
Second attempt at making it home. Bradley road is now totally closed off at the main intersection and all of the traffic lights are still out. I decide to attempt Tinkham road and Parker street only to get turned around by cops or find myself unable to pass due to downed trees and other debris.

1:45am
Found out Bradley road was re-opened, drove home past a huge tree suspended over the road with downed power lines all over the place near Plum Tree road. Finally make it home after a crazy night.