Jan 14, 2006
Topic: My technological 'itch'
I suppose if I had to pick an itch, it would be web content. I often work on/around/with the internet through content group, various positions I hold with companies, and the Earlham Word. I like making webpages, altering webpages, learning about and using CSS, and eventually XML. I also enjoy working with online databases and PHP programming. While I am not an expert in any of the above, I work with them often and am constantly learning in doing so.
My second itch would be game programming. In fact, I've done a little bit of it working with Josh McCoy in his development group. While I haven't been as active with it as I would have liked, it's an interesting topic and I contribute with my ideas and suggestions as I can. I would definitely enjoy a final project based around some kind of game programming.
Jan 27, 2006
Topic: Soylent Green is People!
First, to briefly touch on the topics we've been discussing... I'm intrigued. I wholeheartedly support the basic principles of XP (although certain elements I'm a little iffy on) and want to try using them. I feel that they would be particularly helpful for me, because I'm not the best coder in the world. Most of the CS people around here have been coding for the good majority of their lives, it seems, whereas my first genuine experience with coding was right here at Earlham. I love working with people who have a lot more experience because that really is how I learn. Often when I'm by myself, I'll get caught up by some miniscule bug or error based on some poor style choices based on the language, and just spin my wheels with frustration. In the end, the only thing I learn from the experience is how to not get that same bug. A lot of the actual learning from the part of the code that works gets clouded in frustration, caffeine, and lack of sleep.
As for the actual questions posed by our fearless leaders, they follow now...
-What is my favorite programming language and why?
Well, I suppose that would be C++ simply because that's the one I know the best and can work with the most without looking stuff up. Most recently, I've been dealing extensively with PHP and SQL code so I've been becomming fond of that. I like the power that PHP gives me with regards to internet coding. I'm a big fan of making webpages and such, so that's probably where most of my interest lies in the long run. I haven't encountered many other languages enough to have retained any info from them.
-When and how has coding style most benefited or hurt my software
engineering experiences?
Heh, funny you should ask. Currently, I'm trying to co-write/design a website for the Gamers United club found here. His lack of coding style and grace and even just plain old commenting has made it difficult for me to work through his code to add functionality I want. Likewise, since we don't really collaborate a whole lot on the project, he can sometimes have trouble parsing my code. So the code is pretty darn ugly and needs a desperate overhaul, but we were in a hurry to get it up and running. Eventually, it needs a swift kick in the style maker.
-How do I interpret clarity, simplicity, generality, and
automation?
Eh....probably with a dictionary. Not sure what kind of deep answer you're looking for here. Obviously, all are pretty important coding principles. But I don't see any one as being better than another.
-Open Source Query-
Hmm...An open source query... Who's to say that the continued popularity of
open source software won't potentially kill the programming industry? As open
source continues to become well known and the projects developed on open source
begin to get supported by companies and users alike, some companies may go out
of business. If company A employs 20 people to write a program that gets
created, for free, by the open source community, suddenly 20 people are out of
the job. If you aren't charging for your product, you're giving it away free.
If you're giving it away free, you aren't making an income. If you aren't
making an income, you live on the street. If you live on the street, your
iBook will probably get stolen.
My open source project ideas...
| Thunderbird Send Mail Upgrade | Send Tools |
| I wouldn't mind doing this little gem because it was my favorite Thunderbird extension before 1.5 was released. The original author doesn't appear to be updating it anytime soon. | |
| GAIM Bug | Smiley Bug |
| I use GAIM on linux quite a bit, and this is a relatively small bug that I can only imagine is a pretty easy fix.... I'd hope. | |
| phpMyAdmin | SQL query window too wide bug |
| Well, if I do this one, I won't have to worry much about a graphical interface.... | |
Feb 6, 2006
The School Network Sucks
Well, if there's anything this project has taught me, it's that if you ever want to be a Mozilla developer, find yourself a broadband connection. And not one hosted on an Earlham network with lots of packet throttling and too many people for the total bandwidth to sustain effectively. I started on this project early. Saturday afternoon, in fact, I began downloading and researching how to fix Mozilla bugs. I spent a good hour or so figuring out..."Hey, this is what I need here, that's what I need there, blah blah blah." I got all of the info from this handy dandy little guide, here....
See Make Run.
Nothing really beyond my scope, and I learned a few things too. I learned how to manipulate the Windows file path, did some Windows cmd navigating...all in all, it was good. By Sunday, I'd finished up to step 13. I'd downloaded all of the components, tested that they worked, and even played around with how to package a Mozilla Extension .xpi package. I even fixed a bug that immediately made itself obvious to me. This bug/update is crucial because it allows me to install the mod onto Mozilla 1.5, despite the fact that none of the actual functionality works. So to make a long story short, it's Sunday night and I've spent of and on about 5 hours compiling and downloading and installing all of this crap, and I go to bed with step 13 running. It's making a build of Thunderbird for me by extracting all of the proper files through CVS, it seems. As I write this, the damn make file is still running.
So now I'm kinda forced to blindly hunt and peck through this code to see if what is causing the incompatibilities is real simple. I can test it on my current running version of Thunderbird, but I don't have all the files and I don't have any of the debug info that would come with the source build that I'm attempting to make. As frustrating as this experience has been at times, I can't say I haven't learned from it and have actually enjoyed certain aspects of it. I appreciate going through all this now, because Mozilla is actually something I'd love to contribute to more often anyways :)
I just don't know if I'll have this thing completed by Tuesday. I had assumed this would be a 4 hour project...in truth, it is turning into a 10-12 hour project. That doesn't even include the waiting for downloads. Oh yeah, and I'm learning a little bit of Javascript too. That's what Sendtools was written in... I'd never seen it before now =/ (Well, never analyzed it...)
Feb 11, 2006
The Simplest Bug Fix Ever
After wrasslin' with Mozilla for far too long, I decided to find a very simple bug to fix in order to officially submit the bug and have that kind of ethereal experience. So, I picked quite possibly the simplest bug in the world:A Spelling Error. Here's the diff file: Bug Fix.txt. It's not glamorous, but I think it's a start on future, more significant contributions to the myPhpAdmin project. Also, I didn't find a "submit bug fix" button, so I just posted a comment with a link to a public directory in my filespace that people could get to. Hope that works.
Hey, somebody had to do it.
Feb 14, 2006
Mmm...coffee
Here's my finished assignment 4: Here
Here's a bonus bug fix I did because I reaaaaaaly like this project. I will probably use this project for future assignments: Shoutbox Project
As for the actual journal assignment, what I think is the single most important is the user interface. I like what the book says about making things simple for the user, not necessarily simple for the programmers. In other words, we should type out explanations as to why something broke or how to use something as opposed to cryptic codes that we made for our own debugging purposes. I guess the next two would be detecting errors at a low level yet handling them at a high level and do the same thing everywhere if only because they're blatantly obvious.
Feb 24, 2006
Testing...testing...
So how many test cases would you need? Well, that seems entirely
dependant upon what the thing you're testing is. When I make a Hello
World, the only test case I have is whether or not the output appears. So
I suppose the way to find out how many test cases you need is to walk
through the code step by step and ask, "How could this f up?"
As you walk
through code, look at the line and determine whether or not it is a
critical one. You could even do some critical path analysis to make sure
the critical path is especially tested. But if you get to a line that is
something like "var gar = important thing", you probably want to
test that
the important thing is always getting put into gar properly. Well, the
assignment is safe, but you need to make sure gar is the value you think
it is. However, the line "cout << "crap"" doesn't
need much debugging.
I think when testing, you should test like a machine. Mechanically, and logically.
March 3, 2006
Tippity Type
Project Update: It's coming along. Not as fast as I'd like, but this broken hand thing slowed me down more than I'd thought it would. The good news is that it is settling well and doesn't need a cast. Hopefully within a week I'll be good as gold. As for the project itself, I've finish creating an XML file and now am trying to parse it for my map. I have a basic map now but none of the right points are on it. I'm taking some extra time because I'm reading a lot too. This XML/perl/Javascripting to streamline and make dynamic webpages is right up my alley... so I'm distracted a little more than usual as I try to learn this stuff. I feel confidant that I can provide to the group even having not completed the program, just because I've read a lot of documentation thoroughly. Don't need two hands to read! :)
As for the journal topic, I've had slightly experience in this recently as I helped plan a handheld version of the website Advanced Media Network. It's a gamer thing. I didn't code any of it, but we discussed a lot of things important to handheld browsing. Small images and streamline interface, for example. Much better to set things up vertically than horizontally, because the user can't see the whole screen at once. If you have long vertical columns, they can traverse the top of them without missing anything (except older articles) below. I feel like this kind of thought is critical because everything really is getting smaller. Both of the latest handheld gaming machines have web browsers and so do most modern PDAs. The only thing left is to make WiFi free and open to the public. Heh...maybe we have a few years left....
March 12, 2006
Back from San Fran
So my trip to San Francisco was pretty fun, but it also was a bit of an educational experience as well. I got to spend some serious time actually sitting down and talking to the developers and the programmers. One of the things I talked about with them was the case of the EA spouse. Basically, to sum it up, the EA Spouse was the wife of a developer who worked for EA. She wrote about the terrible working conditions for her developer husband, talking about long extended periods of crunch time, and excessive overtime without compensation (he was salaried). It was pretty huge and EA got a lot of flack for it. Of course, it was a problem with the programming industry in general, not necessarily just EA.
So I was curious. I wanted to hear from the horse's mouths exactly what went down after the EA Spouse blog caught fire. I also asked them about XP Programming and if they knew what it was, and if it had been implemented. I talked to too creative directors and one actual developer about this and what they felt about it, and all of them said they thought the EA Spouse was a little overboard and they hadn't ever really found themselves in a similar situation. They did say that some management changes were made, hourly employment became available, and that they had played with XP Programming as well. They said they even dedicated an entire project to XP Programming. In the end, they took elements from XP, but didn't stick with the whole package. Basically, they reaffirmed my desire to possibly get into the industry. It was good.
As for the journal question, I have the perfect example but it's not extremely historical in that not many know of it, but it's a good example of something where a better data set would have been much better. Sorry Chris. The Earlham Word website is an example of bad data managing. The data managing is clever enough, but it involves file parsing, file creating, and file storing that creates huge directories, difficult site maintenance, and poor readability for the next generation of editors. Basically, the site is created by copying and pasting each story into a file with some proper headers. You then use an admin script to convert each file into an html file that is stored in the appropriate issue folder, then the index page is automatically changed to point to the correct index file. It works pretty well when it works, but it's buggy and fragile. Everything must be formatted precisely. Also, searchability is poor. You search for a phrase like 'pranks' and get results from most articles, even if the word doesn't appear. Had this been done with a relative database, it would be so much easier to interact with, so much easier to maintain, and a lot less difficult for me to pick on Chris. (He was one of the ones to design it, back in the day. Summersault is even still listed as the site creator because I can't find where in his scripting that little piece is automatically added!)
March 28, 2006
Testing....
Links to my stuff
April 4, 2006
No clever title
High performance - Kind of depends on what you're programming. If you have a simple script that parses some random do-dad and gives you info that isn't necessarily timely, the program doesn't have to be tweaked for high performance. But for gaming and large applications that are resource intensive? Oh yeah.
Ease of use - This one is definitely global. Everything you ever program should be easy to use.
Attractive appearance - Bah, humbug to this. Apple is way too obsessed with looks, in my opinion. Their obsession with glossy white is stale and their Mac OS X uses way too many resources for special effects that aren't really necessary. I think programs should be attractive in that they aren't difficult to look at and interpret, but too many bells and whistles just brings down overall reliability in my opinion.
Reliability - Also very important. If your program doesn't run and run correctly every time you need it to, then you have no need to have the program.
Adaptability - Program dependant, I think. Personal programs aren't too big of a deal.
Interoperability - Uh...had to look this one up.
Interoperability
n : (computer science) the ability to exchange and use information (usually in
a large heterogeneous network made up of several local area networks)
Program dependant. My script will not necessarily need to communicate with others.
Mobility - This is always nice. Always good to take a good program and put it on another computer.
April 6, 2006
Just in Time
I think our group worked well. As far as my role, I guess I was the
labrador retriever and focusing lens. I went out and retrieved a lot of the
data sets (Skylar claims credit on the drugs site, go figure) and helped bring
the group back to focus when we strayed off on random topics like South Park.
Specific answers to the specific questions:
Overall I feel like I'm enjoying the project although we're not always entirely certain exactly what we're doing or the direction we're heading in. It's been pretty loose though, so I've had fun with it.
April 11, 2006
Whoops
Forgot to put this up last week.