Monday, November 5, 2012
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
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
Saturday, October 27, 2012
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
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?
Monday, October 22, 2012
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
Friday, October 12, 2012
Sunday, October 7, 2012
Thursday, September 27, 2012
Thursday, September 13, 2012
Tuesday, September 11, 2012
Monday, August 20, 2012
- Software design (diagramming and statement of expected program function)
- The C language
- Memory management--and memory leaks
- Trie data structures ("staged" directories)
- Developing a types system (tag value types)
- Using an issue tracker and public code repository (GitHub)
- Using software revision control (git--still learning :P)
- Software build process (Makefiles)
- Logging program execution with levels of verbosity
- User level file system operations on Linux
- Code generation (very ad-hoc and a pain to work with, but I am using it)
- Input parsing (query interface; doesn't follow the formal (tokenize-> parse) pattern, but it works)
- Data serialization and storage (the database file and proposed xattr data storage formats)
- Software testing (made some attempts at automation)
- Exercise regularly and eat right--you can't code effectively if you're tired and out of shape all the time
- Your code won't runaway overnight--turn off the laptop and get a full night's sleep
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
- The tags attached to the file (naturally)
- The actual content of the file
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)
- File_a has tag set A, File_b has tag set B, A is a subset of B
- the same, but B is a subset of A
- 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.
Tuesday, July 17, 2012
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
Friday, June 15, 2012
Thursday, April 12, 2012
Tuesday, March 27, 2012
Tuesday, March 20, 2012
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
Tuesday, March 13, 2012
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
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
Friday, January 27, 2012
Monday, January 16, 2012
Thursday, January 5, 2012
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.