Sunday, December 22, 2013
GPG audit
GPG is, of course, an important piece of software in the security world. It's kinda crufty and old. It probably needs an audit. Tptacek on HNN says more than that, it needs some decent code documentation, hence my idea of an exegesis, a deliteralization of sorts.
Anyway, multilevel code understanding and presentation.
Anyway, multilevel code understanding and presentation.
Turbulenz
Free game engine. Makes my laptop sound like a jet engine warming up for takeoff - but then essentially anything does that, so it's not really an antifeature.
StupidFilter
An attempt (abortive, apparently) to use Bayesian techniques to detect stupidity. Obviously, this can't detect stupidity at the semantic level, but it might be able to pick up on syntactic markers of stupidity. It's an interesting exercise.
cdecl.org
A translator between English descriptions of C type declarations, and the type declarations. Pretty fascinating!
The Architecture of Open-Source Programs
Online book. I think I linked it already - well, it deserves multiple linking.
Ginko: tree-shaped organization of text
An interesting perspective on document organization: hierarchical, two-dimensional organization of text into successive layers of detail. I kinda like it.
Ginko.
Ginko.
Brilliant vs. insane code
Here's an odd little ditty musing about a line of Python Stavros Korokisthakis (perhaps HNN's StavrosK?) ran across:
It's clockwork, and quite clever - and not the way people think (well, except insofar as people build clockwork and this Python in order to do things like this of course). In terms of code understanding this code is not self-documenting in any way. To determine programmer intent, we have to simulate what it does and see why it does that.
It's kind of like a syntactic artifact of a semantic reasoning process, one that we can recover (hopefully!) with careful reasoning. But the original reasoning is gone.
Interesting.
def GetContourPoints(self, array): """Parses an array of xyz points and returns a array of point dictionaries.""" return zip(*[iter(array)]*3)Hmm. Like it says on the label, it takes an iterable of points and returns an iterable of triples in order. But as Stavros notes, it's not at all obvious how it does that. You have to reason your way through it.
It's clockwork, and quite clever - and not the way people think (well, except insofar as people build clockwork and this Python in order to do things like this of course). In terms of code understanding this code is not self-documenting in any way. To determine programmer intent, we have to simulate what it does and see why it does that.
It's kind of like a syntactic artifact of a semantic reasoning process, one that we can recover (hopefully!) with careful reasoning. But the original reasoning is gone.
Interesting.
Random user generator
Randomuser.me gives you a random user profile - "Lorem ipsum for people". (See how this ties back to the contact management thing?)
So here's a semantic pole for ya: people. They just keep coming up all over the place. And they often share a lot of things with one another. So why don't we have a range of tools like this one, for people, for companies, etc.?
Sort of a semantic toolbox kinda thing.
So here's a semantic pole for ya: people. They just keep coming up all over the place. And they often share a lot of things with one another. So why don't we have a range of tools like this one, for people, for companies, etc.?
Sort of a semantic toolbox kinda thing.
Contact management
A recurring problem for everybody who deals with people. Which is ... everybody. [musings] [hnn]
Seems to me that part of the problem is that not every application of contact management requires a full-on heavy-artillery solution. So - as with many, many other domains - there is a kind of sliding scale of complexity that could be modeled using a set of mapped semantic domains.
I really think this concept is going to pay off once I have it clear in my head.
Seems to me that part of the problem is that not every application of contact management requires a full-on heavy-artillery solution. So - as with many, many other domains - there is a kind of sliding scale of complexity that could be modeled using a set of mapped semantic domains.
I really think this concept is going to pay off once I have it clear in my head.
September
By the way, that was the first post from stuff I bookmarked in September. I seem to have a 3-month lag that is more or less constant, at this point.
Funny vs. LOL
UI patterns
So I've come back quasi-full circle, finding myself thinking of Wx-enabled smart widgets based on the wftk (seriously, it's like it's 2002 again), and last night after the laptop was off, I scribbled down the following note:
This kind of pattern-based "architectural" programming could and should be carried down to the lowest possible levels of programming. That's a semantic mode of conceptualizing software.
Anyway, so I looked up "UI patterns", thinking that would get me that Yahoo effort (YUI, already noted elsewhere on this blog) - but instead it turned up UI-patterns.com, a short-lived effort by Danish web developer Anders Toxboe, an attempt to develop a UI pattern gallery/database/article focus site that seems to have gone on for 2010 and 2011 and stopped. Plenty of spam in the comments sections, but otherwise a ghost town. Too bad, because it's pretty much what I'd like to start from in this attempt to come up with a language of UI pattern design.
Some good grist for the mill, anyway.
Filed under UI design, patterns, and architectural patterns, because I suspect the UI design has to be based on some conceptualization of the data that would be reflected in the system architecture.
Basic mail UI against repo. Define mail-like queues as a thing.The first sentence is a UI pattern (basic mail reader, with groups, then messages, then a document view for the mail itself), and the second is the data pattern it presents to the user (the concept of a message queue, possibly with threads, certainly with some kind of topic grouping).
This kind of pattern-based "architectural" programming could and should be carried down to the lowest possible levels of programming. That's a semantic mode of conceptualizing software.
Anyway, so I looked up "UI patterns", thinking that would get me that Yahoo effort (YUI, already noted elsewhere on this blog) - but instead it turned up UI-patterns.com, a short-lived effort by Danish web developer Anders Toxboe, an attempt to develop a UI pattern gallery/database/article focus site that seems to have gone on for 2010 and 2011 and stopped. Plenty of spam in the comments sections, but otherwise a ghost town. Too bad, because it's pretty much what I'd like to start from in this attempt to come up with a language of UI pattern design.
Some good grist for the mill, anyway.
Filed under UI design, patterns, and architectural patterns, because I suspect the UI design has to be based on some conceptualization of the data that would be reflected in the system architecture.
Subscribe to:
Posts (Atom)