Sunday, June 28, 2009

How Stack Overflow Makes Me Sad

Douglas Adams's novel The Restaurant at the End of the Universe describes a torture device so heinous that the planet where it is located became known as the most evil place in the universe. The device is called the Total Perspective Vortex, and it works by giving the poor soul put into it a glimpse of the entirety of the universe while showing them exactly what the victim is in relation to it. It is reportedly a horrific, mind blasting experience. Recently, I've been thinking about the Total Perspective Vortex often.

Like many programmers I do tend to surf the net while waiting on compile cycles to complete. And since the compile cycles on the product I'm currently working on are... non-trivial, I get the chance several times in the typical day. As a rule, I try to keep myself generally looking at programming topics. It is work time, after all, so I might as well try to expose myself to things that will improve my job skills. This tendency has led me to peruse a site called Stack Overflow. The site sprang from a partnership between Jeff Atwood and Joel Spolsky, both prolific and well known bloggers within programming circles who's work I already read and enjoy. Naturally, when they announced they were teaming up to create a web site where programmers could ask and answer questions, I was intrigued. The idea was sound, the implementation worked well, and their respective audiences gave the site the critical mass it needed to generate a large base of questions and answers quickly. Mr. Atwood even added an XBox 360 inspired achievement system to introduce and encourage behaviors on the site. Stack Overflow to all appearances has been a huge success so far.

As a programmer it's hard not to get excited about a site that allows you to tap the collective knowledge of a large number of people to help you. And since I actually answered a question, I can also say that it's a pretty huge rush to be able to help a random stranger using only the power of your brain. But this is also where things begin to break down a bit. There are a whole bunch of questions posted (over two hundred thousand at the time of this writing). The questions cover all manner of programming languages, platforms, tools, applications, and domains. When I browse through them, I am reminded just how big the programming field is, and how little I really know. Apparently Stack Overflow, to me, acts as a job specific version of the Total Perspective Vortex.

The character in Adams's book who was put into the Vortex just happened to be in a small simulation created just for him, so he survived the event because the machine told him he was actually important. I can take similar consolation from the idea that Stack Overflow was created for programmers like me who know next to nothing of the infinite set of topics out there, and who struggle to be able to write cogently about what little we do know. It's another place to practice the art and to learn new things. And in the end, isn't that what life, the universe, and everything is all about anyway?

Saturday, June 20, 2009

Fusion Reactions and Economic Reactions

In the imaginary sci-fi world that lives in my brain, power is often generated by "micro-fusion" reactors. In the real world, containing fusion reactions requires a massive amount of power and huge electromagnets to create the magnetic fields that keep the plasma fuel where it needs to be. This contributes to the continued failure of fusion plants to produce more power than they consume. A new theoretical discovery may begin to change that, if it works. A different configuration may allow fusion reactors to use magnetic fields an order of magnitued less powerful than current designs. They could also be much smaller, which would be nifty because smaller could also mean cheaper.

Speaking of cheaper, the economy is driving some interesting reactions as well. While these things aren't strickly "green" they have some green side effects. The money crunch in the California government has lead the govenor to call for the use of online textbooks instead of dead tree versions. If I had any sway at Amazon, I'd be attempting to get Kindles into the classrooms right now. Even at nearly $500 a pop for the big, fancy version, it wouldn't take long for them to be cheaper than textbooks. In any case, taking advantage of electronic resources just makes good sense, as long as concessions are made to ensure those resources are available to all students.

Some areas in the U.S. that have been emptied by the decline of manufacturing have started looking into even more extreme greening. They are talking about razing unused sections of cities and allowing them to be reclaimed by nature. This is one of those things that for me sounds both wacky and profound. One way or the other, the economy is certainly going to play a huge part in the changes that come over the next decade or two.

Back to the Usual (Lack of) Business

An impending major deadline at the office, and the resulting crunch mode has shut down work on EAR for the time being, and that means it's back to the normal brand of nonsense found here. But first, something a bit different...

I don't normally find my neighborhood in the local news. Like countless other townhouse communities across the nation, we're a pretty quiet bunch. This changed slightly when the farm animals started roaming around. I'd been hearing a rooster as I leave to go to work in the mornings for a long time, which wasn't a bother. The mocking birds are far louder when they sit on the fence outside my window. Seeing a turkey wandering around one weekday at lunch was an oddity. But it was the cow running past my front window one Saturday morning that really made me take notice (and briefly wonder if I had finally cracked). Mentioning it to a neighbor, I was told about the pony. And the calls to animal control. Things came to a head this week and here's the resulting story. I urge you to also read the comments afterward as the report left several key points out. (There's a reason I don't subscribe to the local newspaper.)

Wednesday, June 17, 2009

Just an Observation

Today I've seen a surprising number of people posting to the Internet via various means whether or not a software update for their phone has been completed. They seem excited. About a software update. For their phone.

Metaphorical Toto, we're not in metaphorical Kansas anymore.

Sunday, June 14, 2009

Analog Go Bye Bye

Did everyone survive the digital television transition?

Wednesday, June 10, 2009

The Summer Project 2009, Part 6: Interface Beginnings and Project Analysis


One of the oddest things about programming is how much work it takes to make something actually visible. Above, you see the beginnings of EAR's primary interface, with the account entry and selection section at the top, the transaction entry section at the bottom, and a swath of nothing in the middle where the register should eventually be. That folks, results from three weeks of spare time programming, mainly because it's been quite a while since I last visited the Java User Interface libraries some four versions ago.

Functionally, adding and renaming accounts works, as does adding transactions to accounts. (Of course, you can't see the results of that last bit in the UI.) User interface code consists of creating the little fiddly bits that make up the visible part of the program, and telling them where to put themselves and how to behave. The hard part is making sure they do what the user expects, making sure the data they produce is valid, and generally making the UI connect to the underlying data model in a way that is robust. After all, you don't want someone to be able to enter an amount of Thursday in a transaction. (In the interest of full disclosure, at the moment, you can type an amount of Thursday in EAR, and it will cause any attempt to add the transaction to quietly fail.) Unfortunately, I can't really think of much generally interesting to write about the details of this work. Unless you want to discuss the different forms and functions of the Java widgets or how they are laid out or how to use a Java enumeration to populate a drop-down selection box, there isn't really much to say here. Fortunately, I have something else to write about.

Periodically during the development of a project, it's a good idea to take a step back, evaluate, and see if things are moving in the right direction. Here's what I've learned so far.
  1. Sun has done a magnificant job with the Java documentation. Between the API specs and the tutorials, it's extremely easy for someone with a minimal amount of experience with the language (e.g. me) to answer questions without resorting to Google. Kudos.
  2. Yes, I can still program at home, and it's still fun. What I can't do is string three or four hours together to do it. That has severe productivity consequences.
  3. Writing about programming takes longer than programming. (This one hopefully reflects more on my writing ability than my programming ability.)
I'll admit, the last two are more germane to the discussion, but I couldn't let the first one pass without mention. Good documentation is a rare and beautiful thing. Anyway, the EAR is making progress steadily, but slowly. I set out on this project primarily to discover something about myself, and I've learned what I needed to know. Along the way I've picked up some new Java tricks. For me, the project has already accomplised its mission. Don't worry though, I can't quit until we at least make an attempt at displaying transaction registers, saving, and loading. That empty grey expanse in the middle of the UI is just ugly.

PS: Extra points if you are paying close enough attention to notice what part of the data model I've left off the user interface.

They Still Haven't Found What They're Looking For

It's been a while since I looked at the search terms that lead people to this site. (I'm small time, so looking doesn't take very long.) Someone actually searched on "javac ear" and ended up here. They didn't stick around. I guess my summer project wasn't what they were after. I'm not so sure how "norman matloff new york times" even directs here. Shockingly, they didn't stick around either. My favorite one for the past month has got to be "informal stream of consciousness." You can't get any better than that at describing what's going on here. Oddly, that person didn't stay long either. Maybe I wasn't informal enough?

Saturday, June 6, 2009

The Summer Project 2009, Part 5: a Data Model and a Screenshot

Writing code at last. First, we implement the pieces discussed in part 3. With our design in hand it's a fairly mechanical process, but already there are details to be filled in. I chose for now to go with simple things that would get me started but that may need to change later. For instance, here's the Portfolio class so far:


import java.util.*;

public class Portfolio{
public Portfolio(){
accountList = new ArrayList<account>();
categoryList = new ArrayList<string>();
}

public void addAccount(
Account theAccount
){
accountList.add(theAccount);
}

public ArrayList<account> getAccounts(){
return(accountList);
}

public Account getAccount(String accountName){
Account result = null;
for (Account anAccount : accountList){
if (accountName.equals(anAccount.getName())){
result = anAccount;
break;
}//if
}//for
return(result);
}

public void addCategory(
String theCategory
){
categoryList.add(theCategory);
}

public ArrayList<string> getCategories(){
return(categoryList);
}

private ArrayList<account> accountList;
private ArrayList<string> categoryList;
}


I'm representing the categories as strings (a simple, liner group of characters) rather than giving them their own class. Since the categories don't have any attribute other than their name, it seems OK for now, but it does have some implications. Without giving them some level of existence beyond just the text of their name, the rename operation becomes meaningless. Changing the contents of a string creates a new string, but changing the name of a category doesn't create a new category. It's a good example of the trade-off between complexity and functionality. Simple code is always better, except when it fails to deliver a needed capability. Whether this particular choice becomes a problem will depend on how often we need to rename categories.

This Portfolio object and the collection of objects it contains form the underlying representation of the program's data. It is, in theory, everything EAR needs to keep track of. In programming parlance, it's the data model. And while the data model is the core of the code, it's not the whole story. We still need a way to show the data to the user, and a way for the user to manipulate it. We need a User Interface, or UI for short.*

The skill of making a good user interface goes beyond what it takes to write good code. Once you bring in other people into the equation, you get into the realms of design, usability, and aesthetics. Programmers, being programmers, generally tend toward making legendarily bad user interfaces. However, I'm all we've got for this project, so we'll just have to see how it goes. I tend to start off with a couple of pencil sketches debating how to organize things before I dive in, and EAR is no different. But before we can even get to the main program, we have to decide what actually happens when the program is run. It seems to me we have to do one of three things when the program starts (not counting run in fear):
This piece is actually fairly easy to do. Java provides a built-in mechanism for asking a question with three possible responses. It's just a custom version of the yes/no/cancel dialog you've probably seen before. As always, there are some subtleties, such as making sure that the option to open the last portfolio used is selected when the program runs so you can just hit the space bar or enter to get on with things. Unfortunately, not all of these buttons are going to work right away. We haven't actually thought about saving and loading data yet, and we won't for a while. So for now, we'll have to stick with the third option. Next time, we'll start in on the main UI so we can have something to display when that third option is chosen.

* Formally, the data Model is joined by a Controller and any number of Views. These pieces respectively provide representation, manipulation, and presentation of data. They aren't necessarily separated in a program's code, but they can be, and it often makes for a better program. In practice, this pattern gets used often enough to have its own acronym: MVC for Model-View-Controller. Naturally, I will be taking the lazy approach by combining the controller and the views for EAR in the User Interface.