General approach to site development

1. Set up test site
2. Sketch sitemap
3. Sketch data schema from initial sitemap
4. Create data, load database
5. Determine the areas to be placed on the front page, compile
6. ???
7. Profit.

iPhone tester

A useful way to test iPhone compliance without an iPhone.

jQuery

jQuery is pretty ubiquitous, but ... link, just in case.

Raphael Javascript drawing library

Again: an open-source drawing component that's both grist for a component-database mill, and for a pattern-mining mill.

Draw Anywhere

DrawAnywhere.com is a fascinating concept: with a free account, you can log in and define drawings, from anywhere, using a Flash diagramming tool. You can upgrade to a premium account to have their link taken off your drawings, and the usual.

That's cool. Semantic programming should allow me to throw together a concept site like this in minutes. That's the goal. So: target.

Open-source Flash chart

So this open-source Flash chart component is interesting for a couple of reasons.

First, a database of useful components must be part of the semantic programming toolkit. How would one organize that?

Second, it's Flash, and open source. There's probably a boatload of useful patterns to be mined from it.

Programmer/journalists

An article about how journalism is finding that some stories are best told with databases. I'd like to be doing stuff like that.

Higher-order Perl

Might as well use this blog for bookmarking programming-related things.

So: Higher-Order Perl.

BUT errors can happen

A process can always fail. The meaning of the process will include its expected outcome (e.g. "I open file -> file IS open") but we know, as a general principle, that processes can fail.

One of the failings of formal logic (as far as I'm concerned) is the need to account for this sort of global knowledge on a very repetitive local basis. Since we know attempts to do something may fail, it's difficult and bothersome to have to say so, every time.

But this begs the question: how do we define the semantics of error checking? Where do we put it? When the engine is actually writing a script, will patterns take care of error checking?

Since this is informal logic, actually all of the above can apply at the same time, so maybe I'm getting ahead of the game here. But it's an important notion.

Trust, but verify. Trust that a file can open, but verify that it actually did so. Trust that our script will work, but verify it using unit testing. The point is to describe the semantics of good programming, right?

Informal logic defined

This is the current definition of "file", then:

term "file" (n):

- CONTAINER for data
- HAS name
- either (data IS text) or (data IS binary)

- IN filesystem
- IN directory
- IN path

- ACTOR reads data FROM file [BUT R1]
- ACTOR writes data TO file [BUT W1]

- ACTOR opens file -> file IS open
- [R1] ACTOR reads data FROM open file [BUT mode MUST BE read]
- [W1] ACTOR writes data TO open file [BUT mode MUST BE write]

- open file IS "stream" (n)

- ACTOR opens file "for writing" (adv) -> (file IS open for writing) AND (mode IS "write" (adj))
- ACTOR opens file "for reading" (adv) -> (file IS open for reading) AND (mode IS "read" (adj))
- ACTOR CANNOT (write data TO file open for reading)

Note several things:

• [BUT ...] syntax denoting informal logic, the "zoom-in overrides".
• MUST BE/IS, and CANNOT
• [R1] and [W1] marking specific statements within a definition.
• -> denoting the outcome situation of a process, basically.
• ACTOR is kind of jargon. Maybe "I" would be better? Actually I kind of like that.
• "" defines a term. A parenthetical remark after it defines its part of speech.

Also, we're kind of defining terms on the fly here. This is fine, but it leads to a sort of "virtual definition". We should maintain a table of these virtual definitions, and if they end up being large, the author should consider a separate definition page.

By convention, the front page of a domain Wiki should have a list of links to all terms defined. This allows the compiler to spider without a great deal of trouble. On Wikispaces, pages can be tagged, making the capitalization of term pages somewhat superfluous. If all the term pages are linked in some way (Wikispaces allows us to define a page link list by tag) then that's not necessary. I'm not going to use it for now.