Monday, November 5, 2012

Upgrading software

Briefly, upgrade your software only when you want to take advantage of new features or security/stability fixes. That seems obvious, but a lot of people (especially people new to the idea of maintaining a software system) still think that "bleeding-edge" is the way to go, when that just isn't the case. There's nothing to be gained by putting your system in an unstable state at a whim or for the vacuous accomplishment of having the newest thing.

Furthermore, when you do upgrade your software, make sure you have a path back to the previous version so that if something doesn't work well with your system (and there will definitely be times this happens), you can revert without too much hassle. Too many times have I made some install that didn't have a sane un-install procedure--files flying all over the file system, and the only record of where they were supposed to go in a binary executable. Yuck. Avoid using binary executables for setup when you can and it'll save you trouble. And for god's sake, don't make them for your software, but make an install shell script if it wouldn't inconvenience your users. Sure theres the problem of platform incompatibility that comes with that approach, but that's true in any cross-platform system, and there are other ways of dealing with those problems.

Remember, remember the 5th of November...(tee hee)

Saturday, November 3, 2012

Adaptive UX

Adaptive user interfaces (AUI) attempt to change to better suit their users. They typically start in some default state defined by the system designer. A user gradually adapts the interface to himself through a negotiation process undertaken during software usage. My first impulse is to reject this sort of interface for lacking consistency, but let's make a brief listing of the requirements for an adaptive UI in a multi-user system. (The multi-user stipulation is aspirational, but presents some considerations that must be made even in single user systems)

Mainly, my concern with this type of interface is that it doesn't allow for users from one instantiation of the system to use another without recalling to himself the initial set-up for the system. That kind of hiccup may only come up with multi-user systems and public terminals, but I think it would be useful for, say, the military to be able to switch out systems without the users needing to retrain the systems to their particular set of optimizations and preferences. There's also the consideration of establishing a common interface between systems. If each user can change the interface dramatically, there's no hope of standardization. Of course, we can say that each system has its own idioms and should be open to specialization for that system; however, for a class of systems that I'm interested in which may be called "general purpose" there is a great potential for making all uses of the system intuitive with a minimum of training. That is my goal anyway: to accelerate the rate at which we can come upon unfamiliar systems and become adept at manipulating them, removing many of the crude attempts at personalization and real-world analogy that plagued interfaces in the '90s and 2000s when computer use became more widespread.

Friday, November 2, 2012

$300 prosthetic arm

Saturday, October 27, 2012

Country rock is pretty cool

Recently found myself a fan of Jason Charles Miller (youtube, homepage). I think I'll explore this genre a bit more.

On another note, I hope to have more long-form posts pretty soon. Have a few drafted posts that need a rereading/polishing.

Tuesday, October 23, 2012

state and interface

I wonder to what extent you can impose a stateless interface on a system which has an underlying state.

As an example, I might have a "repeat playlist" option built into my music player. There is clearly a state here since when the player is in "repeat mode" it will repeat the track, otherwise not. Typically this would have some sort of toggle item in settings. The other option though is to just give two options "repeat mode on" and "repeat mode off" in the same menu, juxtaposed, with the implication that selecting either one will leave the system in the named state, regardless of what it was before selecting the menu item.

There may be limitations to this when the possible states aren't easily flattened out like in setting some continuous quantity. In general though, I prefer absolute state markers to toggles because they can be engaged with, paradoxically, more certainty and less knowledge of the system-- unlike with mute toggle buttons--what's up with that shit?

Control Your Data

This is just a bit of a reminder to myself to always define my data format manually.
Relying on Ruby to print out hashes in a specific fashion just hosed my test database :{

Monday, October 22, 2012

Golden Rules of Interface Design

Important document. First saw it first semester of my freshman year.
Reproduced below

1 Strive for consistency.
Consistent sequences of actions should be required in similar situations; identical terminology should be used in prompts, menus, and help screens; and consistent commands should be employed throughout.
2 Enable frequent users to use shortcuts.
As the frequency of use increases, so do the user's desires to reduce the number of interactions and to increase the pace of interaction. Abbreviations, function keys, hidden commands, and macro facilities are very helpful to an expert user.
3 Offer informative feedback.
For every operator action, there should be some system feedback. For frequent and minor actions, the response can be modest, while for infrequent and major actions, the response should be more substantial.
4 Design dialog to yield closure.
Sequences of actions should be organized into groups with a beginning, middle, and end. The informative feedback at the completion of a group of actions gives the operators the satisfaction of accomplishment, a sense of relief, the signal to drop contingency plans and options from their minds, and an indication that the way is clear to prepare for the next group of actions.
5 Offer simple error handling.
As much as possible, design the system so the user cannot make a serious error. If an error is made, the system should be able to detect the error and offer simple, comprehensible mechanisms for handling the error.
6 Permit easy reversal of actions.
This feature relieves anxiety, since the user knows that errors can be undone; it thus encourages exploration of unfamiliar options. The units of reversibility may be a single action, a data entry, or a complete group of actions.
7 Support internal locus of control.
Experienced operators strongly desire the sense that they are in charge of the system and that the system responds to their actions. Design the system to make users the initiators of actions rather than the responders.
8 Reduce short-term memory load.
The limitation of human information processing in short-term memory requires that displays be kept simple, multiple page displays be consolidated, window-motion frequency be reduced, and sufficient training time be allotted for codes, mnemonics, and sequences of actions.

Sunday, October 14, 2012

Lake Street Dive

These guys are pretty cool. Nice jazzy/folk style.


Sunday, October 7, 2012

Facebook is like a chair?

Facebook is like a chair mainly in the capacity that I am on a chair when I'm 'on' facebook. The depth of the human connection they pretend to is grossly overstated given that the software is barely above the level of email in terms of usefulness, and further, is geared mainly towards promoting consumption of goods.

Thursday, September 27, 2012

Thursday, September 13, 2012

Tuesday, September 11, 2012

Monday, August 20, 2012

What I've Learned from TagFS

I started TagFS because, first of all, I thought it would be a good idea. What really drove me to keep working on it though, was that I was learning things that I wouldn't have even bothered to look into before. Because this project has been a source and guide for my learning I thought it would be worthwhile to make a list of what I have actually learned over these months. So, without further ado:
  1.  Software design (diagramming and statement of expected program function)
  2. The C language
  3. Memory management--and memory leaks
  4. Trie data structures ("staged" directories)
  5. Developing a types system (tag value types)
  6. Using an issue tracker and public code repository (GitHub)
  7. Using software revision control (git--still learning :P)
  8. Software build process (Makefiles)
  9. Logging program execution with levels of verbosity
  10. User level file system operations on Linux
  11. Code generation (very ad-hoc and a pain to work with, but I am using it)
  12. Input parsing (query interface; doesn't follow the formal (tokenize-> parse) pattern, but it works)
  13. Vim-fu
  14. Data serialization and storage (the database file and proposed xattr data storage formats)
  15. Software testing (made some attempts at automation)
  16. Pacing
  17. Exercise regularly and eat right--you can't code effectively if you're tired and out of shape all the time
  18. Your code won't runaway overnight--turn off the laptop and get a full night's sleep
Lately, I've felt discouraged by this project because even though it's been months since I started, with several breaks in the middle, it still isn't in a very usable state. Thinking about some of the things I've learned gives me some well-needed perspective and reminds me that there was a point to all of the time I've spent working on TagFS. Most likely, I will abandon TagFS indefinitely because, for all that I've gained, the time I lost on it might have been better spent improving my social life.

Regardless, I hope that this brief listing of my learning experience can encourage some others out there who, like me, have wanted to learn a skill independently but felt like making anything complex was too big of a challenge. The only barriers are motivation and knowledge; having a goal--and this is with anything, not just programming--will do wonders for directing your learning and motivating your actions. Find anything you want to do or make, set your goals and pay attention when you've achieved them. That's really all it takes.

Sunday, August 19, 2012

File names? Who needs them?

While trying to work out a problem with name collisions in TagFS, I recalled a somewhat radical idea I had nearer to the start of the project to completely remove user-specified file names from the system. When I initially thought of the idea it was mostly an extrapolation of the ontology I was building for TagFS. It seemed to me that what defined a file was
  1. The tags attached to the file (naturally)
  2. The actual content of the file
and absolutely nothing more. The file name is a kind of metadata which  has at times served as primary data, but I didn't see it as something innate to what it named---it was merely a convenient tag for the data. I back-pedaled from the idea that the system was workable without a dedicated name (à la -booru imageboards) because several situations where the name is important to how a system works with data came to mind: Makefiles, Java source code, C include directives---programming in general really; but also, file extensions, URIs, simple data organization schemes---and the list goes on. Generally, we rely on files having names and having canonical ways of accessing the files based on their names; and so, I compromised my ideology by making 'name' a tag and storing file names in the 'name' value (possible thanks to an extension to my simple tags that was little used elsewhere). Where ever the file name was required, the name tag was read in behind the scenes. From there, I moved on ahead and let the no-file-name idea drop.

Eventually, the special case of the 'name' tag started to create problems in the organization of my code (it was awful), so that kludge, along with a good deal of equally stinky code was replaced. File names became first-class metadata again and things worked relatively well. While I was working in this new system though, I realized that some situations were not covered by simply preserving file names. When I store a file, it gets placed in a sort of bucket for each of its tags. To pick out a file, we have to specify which buckets we want to look in and what the name of the file is that we want to find in these buckets. If the file isn't in any one of the buckets then we return a "not here" value. This generally works by taking a path like "/tag1/tag2/tag3/file_we_want", translating the dirname into a list of buckets, ("tag1", "tag2", "tag3"), to check and checking for "file_we_want" in each bucket. Our problems start when we have files that share some set of tags and a name. There are 3 cases where this happens:
Let, Name(File_a) == Name(File_b)
  1. File_a has tag set A, File_b has tag set B, A is a subset of B
  2. the same, but B is a subset of A
  3. File_a has tag set A, File_b has tag set B, and there exists a tag set C such that C is a subset of A and C is a subset of B
The case where the tag sets of File_a and File_b are equal isn't a problem since that implies that they are the same file.
In all of these cases, there is a set of buckets where the data that we are seeking can't be gotten by knowing only those buckets, but requires knowledge of which order the files were put in the buckets and how that order affects which file you see, or if we're in case 1 or case 2, which file still exists. There are some schemes where most of the user-supplied names would be preserved, and even one I've thought of where files are stored in a stack rather than being overwritten. None of these seem effective or natural, so I don't want to bother with them.  After thinking over this problem I recalled the no-file-name concept and decided to give it another chance.

Setting my earlier misgivings aside, how does removing file names solve my identity crisis? We still keep identifiers, but we just ensure that they are unique. That's easy because every file that's added to TagFS gets a brand-new id number. By identifying files this way we are guaranteed not to have any collisions, so the precondition for my problem cases can't happen (as long as you make fewer files than a 4-byte integer can hold). The only worthy considerations then are, first, how a human user identifies files based only on tags and an id number, second, and more importantly, how can we do all of the things we did with file names, with tags?

I won't answer those questions because I doubt that anything I could come up with would be as worthy a solution as whatever people would come up with while actually using TagFS. Different workflows would have to be designed for some tasks and file management utilities would have to be redesigned. These aren't minor hurdles to overcome (far from), but they don't present a fundamental challenge to the idea of removing file names.

Tuesday, August 7, 2012

It's actually really easy to get five of the planets and the days of the week in Japanese all in one shot as long as you know the Latin roots for these.

To demonstrate, in French and Engilsh the days of the week are
lundi, mardi, mercredi, juedi, vendredi, saturday (EN), dimanche

The planets in English:
(__, Mars, Mercury, Jupiter, Venus, Saturn, __)

and in Japanese, the planets:
(__, 火星, 水星, 木星, 金星, 土星, __)

and the days:
火曜日, 水曜日, 木曜日, 金曜日, 土曜日

I should admit though, that while these help with remembering the connection between these two sets of words in Japanese, recalling this relation probably isn't the best way to learn them unless you know the Latin roots and one of the word sets well enough to use as a basis.


Wednesday, July 25, 2012

How can you say to your brother, 'Brother, let me take the speck out of your eye,' when you yourself fail to see the plank in your own eye? You hypocrite, first take the plank out of your eye, and then you will see clearly to remove the speck from your brother's eye.


Unnamed sound sculpture

Very beautiful.


Tuesday, July 17, 2012

Web Bookmarks

It's a shame how poorly web browsers handle bookmarks. In Firefox, for example, there is the ability to tag bookmarks and even a feature that suggests previously created tags to cut down on duplicates. However, they lack two features which I see as vital. First, they don't allow for convenient viewing of bookmarks on the basis of tags. The only way to see all of the tags is to open the bookmark manager. From the Bookmarks menu, the only tags shown are those most recently modified. Second of their problems, is that there isn't any recursion in the presentation of tagged bookmarks, even in the bookmark manager. Only a single tag can be used to specify the bookmark view at once, but what if the user wanted to limit the the display to bookmarks with two or more tags?

Often these don't pose a problem for users, because they only visit a few different sites which they either have opened in tabs all the time or available in a "quicklist" auto-sorted by the browser according to recent usage. However, when a user needs more access to his past reading, it can become difficult to pick out the data he is looking for from a large list of tags with titles that may not reflect the particular data he's searching for. When doing actual research, having to rely on searching by page titles (which sometimes don't have the pertinent relation to the contents) can be disastrous. While there may only be a few cases where a user runs afoul of the poor organizational structure, the times when he does will irk him and probably cost a lot of time both in the auxiliary work of finding data and in the time taken to get back in "the zone" to work efficiently---and this can even ruin a whole day's work if the distraction is sufficiently upsetting.

Still, there remains the fact that many people won't bother with bookmarks at all. They rely entirely on their browser history and web searches, probably never clearing their history to prevent the loss of their fragile knowledge network. While I would always encourage more active management of information, I tend to see that as the most natural approach. Organizing bookmarks takes time, and even if it's only a little, it's still valuable. Ideally, everything we read would be automatically organized into a well-structured web of information, that we could run through at will with the ease of accessing our own memories---the web would be an extension of our memories. However, science has not yet fulfilled this desire, and we are forced to make do with the tools at hand. I can, however, hope that there is data to be gleaned from user habits while surfing the web, and that those data might help to structure the information we view for later re-view.

Friday, June 29, 2012

TagFS Release 1

It looks like the first version of TagFS is ready to be released. About all of the features you would expect right off the bat are in there.

Zip Archive
Project Page

Friday, June 15, 2012


I found this graphic design blog called NiceFuckingGraphics. It looks pretty cool, so I thought I'd share:
Main page
Page that got me there   pretty cool artist with a hip-hop style (DA)

Thursday, April 12, 2012

TagFS Alpha 1

My first release of TagFS, a filesystem based on tags instead of directories, is out:

You still can't make your own tags intuitively (heh.), but the script lets you demo it.

Tuesday, March 20, 2012

Deja Vu

(x-post from my old blog)

Deja vu, the phenomenon of feeling that events occuring have occured before in exactly the same fashion, can be explained very simply as a matter of timing in the brain's processing of events. It's not hard to imagine that some aspects of a stimulus are processed faster than others. Have you ever raised your head before you "heard" the telephone ring--before your frontal lobes perceived and recognized a sound? Hearing a sudden, unexpected noise will cause an almost reflexive reaction in most humans. They jump and look towards the origin of the sound. It isn't necessary to fully perceive sounds like that prior to responding to them, and because such noises could signal danger, it could be a deadly mistake to rely on the much slower frontal lobes to finish up before a response is coordinated.

A similar system is likely in play during deja vu. A stimulus is perceived and processing begins on it. However, the memory storage process encodes the stimulus just a fraction of a second before the frontal lobes. The frontal lobes, in processing the stimulus, refer to memory, including the memory just encoded for the same stimulus, and therefore recognize the stimulus as something _that already happened_. This out-of-step-processing hypothesis also explains the decay of deja vu. As an episode of deja vu progresses, the two processes of conscious perception and memory gradually return to their proper order, closing the time gap until conscious processing overtakes memory processing. This closing gap agrees with the experience of the deja vu memory becoming progressively less certain until events no longer appear to have happened before.

It's still not clear what causes deja vu or why episodes tend to stick out in a person's memory. Memories are more concrete when the stimulus is very strong or traumatic to the observer, but that doesn't imply that the processing is *faster*, and furthermore the events that surround episodes of deja vu are typically very mundane and in no way emotionally charged. Possibly, deja vu merely shows evidence of the brain's imperfect powers of perception and time gaps result from a race condition in our brain software. The more common explanation, that deja vu arises from the association of long passed or familiar memory traces with present stimuli could provide part of the answer. Assuming that the memory process must precede the conscious proces we have to assume that either the conscious process slows or the memory process accelerates prior to an episode. If the prior-memory-association hypothesis is correct, then it's possible the memory of a past event is substituted into evolving memory and thereby speeds up the process.

My hypothesis comes from a conceptualization of the brain as a sort of neurochemical computer. I assume that certain processes are distinct, identifiable, and observable. I may be wrong and the brain may be organized in ways that I did not anticipate and cannot understand. Even so, my explanation is at least as good as any other I've heard and I beleive it can be tested with in a drug trial.

Sunday, March 18, 2012

Remote access tip with Firefox

I discovered today that if firefox can detect a firefox session running on a remote X server, it will connect to it. This can be disabled by the no-remote option on the command line (as per the man page).

Tuesday, March 13, 2012

Conway's Game of Life in Racket

Since I have some free time right now, I thought it would be cool to try my hand at making a GoL simulator. I would have used C since that's just what I've been using lately, but I ended up doing it in Racket (Scheme).

The grid can be made toroidal or as if the edges are all zero. Putting in new patterns is pretty simple. Display is simple text output.

Source includes glider, lwss, and gosper gun patterns.

Thursday, February 16, 2012

Friday, February 3, 2012

Owning your data

With all of the talk lately about Google consolidating its privacy policies, I've recalled an idea that I had a while ago. Typically we rely on companies outside of our control to collect, store, and use our data to make our use of their services more pleasurable (allegedly). But couldn't we, given the tools and knowledge, collect, store, and use our own data in the manner that we see fit, without the requirement that other entities be trusted with our data? Of course, what our online services do wasn't unheard of before they started doing it. We have often entrusted the administration of tasks too laborious or trivial for us to carry out on our own to specialized professionals. Few people bake their own bread these days except as a novelty, cars are typically serviced by trained technicians (at great expense), and teaching is left to teachers. However, there are features of personal data management, such as the potency of personally identifying data for manipulating users, that suggest benefits in personally managing ones own information.

Presently, I don't know of any tools that would allow a person to completely remove themselves from the many web services they use while keeping the most beneficial parts, but there is value in considering what those parts are to begin with. I don't think what draws people to MySpace, Facebook, Twitter, and all of the web forums and mailing lists is something bound up in the interfaces themselves. Rather, the social benefits conferred by users upon other users is what makes and breaks these microcosms of society. Because they merely act as conduits of social transaction, the value of the transactions is what should be in question. Our most meaningful and rewarding connections are the ones we have with individuals. Social networking sites rarely contribute to those kinds of connections.

Tuesday, January 31, 2012

Why students should memorize dates

This post isn't in in line stated subject of this blog, but I'm not about to make another blog just to post this, so there.

Knowledge of dates is, primarily a tool for the organization of facts. While dates are arbitrary in themselves---for a given event might have fallen the day before or after on chance---when assigned to a collection of events they provide the basis for chronology which then allows for notions of logical progression and from there a story – the most persistent structure for human memory storage. Nassim Taleb’s denunciations of the human fixation on story-making aside, if we want students to learn history, they need, as in all other areas of learning, a meaningful framework on which they can seat new ideas. Stories provide such a framework, and dates are instrumental to their formation when the parts of those stories, given piecemeal in books and lectures, must be put back together.

Friday, January 27, 2012

Dynamo Bit 313-A

Really cool film:

Monday, January 16, 2012

Web bugs

Ever wonder why your email client typically blocks images from loading?
Here's a good reason:

Thursday, January 5, 2012


People who claim they're "moving to Canada" in the face of legislation they oppose (or believe they would oppose if they actually read and understood it) really disgust me. When did the value of your personal freedoms become so cheap that you aren't willing to defend them? That you aren't willing to even face the reality of an ailing nation that you, and others like you, helped to create by consistently blaming others for making mistakes where you might have done worse and in any case wouldn't bother trying?

If you want to forfeit what greater men have fought for all I can do work is harder in your stead. Even so, I implore you, don't shout your cowardice in every forum of your precious Internet -- your time would be better spent packing.