Thursday, July 30, 2009
Wednesday, July 29, 2009
Sunday, July 26, 2009
author's software principles
Make software that discusses its methods with the user.
Example:
At the heart of basically every application are functions that draw dots, lines, and other geometries. Are these ever discussed in software documentation? To me, this looks like a market niche.
At present, with little to go on but this idea (very limited knowledge of languages, etc.), what I can do is write about it. Since the idea is to inform, anyway, that might do double duty, informing while developing.
That's one principle with an application of it illustrated. Here's another:
Treat virtual reality not as a computing application but as the essence of what computing is and how it's done.
I want to work on the first principle before I tackle the second. The first principle is an approach to the building blocks of virtual reality. The statement of the second principle can stand, here, as an expression of the next larger goal.
Example:
At the heart of basically every application are functions that draw dots, lines, and other geometries. Are these ever discussed in software documentation? To me, this looks like a market niche.
At present, with little to go on but this idea (very limited knowledge of languages, etc.), what I can do is write about it. Since the idea is to inform, anyway, that might do double duty, informing while developing.
That's one principle with an application of it illustrated. Here's another:
Treat virtual reality not as a computing application but as the essence of what computing is and how it's done.
I want to work on the first principle before I tackle the second. The first principle is an approach to the building blocks of virtual reality. The statement of the second principle can stand, here, as an expression of the next larger goal.
Friday, July 24, 2009
happiness
I'm happy. That's pretty much true 100% of the time. That hasn't always been something I would say, although always leaned towards happiness. It's true, now, though, because of my method. What I do is, I always have something in mind TO DO. If there's a moment when I don't have something in mind to do, that'll make me feel a little bit of unhappiness, or, maybe, more than a little, until I adjust. As soon as I start to feel fretful in that kind of way, I search my thoughts for things to do. If nothing comes to mind, I make something up. If something that comes to mind seems so outrageous as to be impractically difficult to accomplish, I make up ways to get it done. Those things in themselves are often outrageous, but I can feel them beginning a process that will work.
Just that makes me happy. And it has beneficial side effects, too. Things start to happen. Things do happen. The underlying conditions for happiness develop, so happiness and conditions develop together.
It may be that to move from a state of accustomed unhappiness, or even accustomed sometimes moodiness (moving from that within reason), to a state of constant happiness requires more than a logical prescription. One may be in a kind of other space or place from the other. If that is the case, the reader may be able to apply a some supplemental practices. For example, earlier in my life, I pursued happiness by studying macrobiotics. Happiness, its value as a goal, is at the very heart of macrobiotics, explicitly ... "key to health and happiness." Perhaps, though, practitioners have been too serious, treating macrobiotics as about doing something right, and forgetting that well being may be its essence. Still, to me, that essence made complete sense, and I pursued it with complete confidence, and total enthusiasm. One result: I've always had something to do (cooking being the fundamental practice, with philosophizing, gardening, editorializing, teaching, business, being other examples).
You could try that. Just think of it as cooking. Dedicate yourself to cooking and happiness, and you will have health and abundance to support them.
Another story has to do with medicine I took. I'll write about that later.
Just that makes me happy. And it has beneficial side effects, too. Things start to happen. Things do happen. The underlying conditions for happiness develop, so happiness and conditions develop together.
It may be that to move from a state of accustomed unhappiness, or even accustomed sometimes moodiness (moving from that within reason), to a state of constant happiness requires more than a logical prescription. One may be in a kind of other space or place from the other. If that is the case, the reader may be able to apply a some supplemental practices. For example, earlier in my life, I pursued happiness by studying macrobiotics. Happiness, its value as a goal, is at the very heart of macrobiotics, explicitly ... "key to health and happiness." Perhaps, though, practitioners have been too serious, treating macrobiotics as about doing something right, and forgetting that well being may be its essence. Still, to me, that essence made complete sense, and I pursued it with complete confidence, and total enthusiasm. One result: I've always had something to do (cooking being the fundamental practice, with philosophizing, gardening, editorializing, teaching, business, being other examples).
You could try that. Just think of it as cooking. Dedicate yourself to cooking and happiness, and you will have health and abundance to support them.
Another story has to do with medicine I took. I'll write about that later.
deliverables
I went with your "deliverables" topic, and got, I think, interesting results.
I want to do near term deliverables. The conference itself is a deliverable. Then, the first two days are essentially spent working on - planning - deliverables. The thing is, why wait. Anything we do immediately will only add to what we can do at the conference. My awareness swung to the absurd aspect of my plan. I thought "maybe we should plan it for October." Then I thought "let's plan it for August and October and January."
I have long wanted to do a graphics programming environment. We'll use that to build rendering functions. Another aspect of my plan: I want the user to fully understand the code behind the product. I want the product to teach users about itself. I'm seeing the content of our discussions in the course of building the product as a medium for beginning that project of teaching user about the product's methods. I'm mentioned similar ideas in earlier letters. I think I can map out an incremental build that will make the process intelligible for anyone, and everyone.
The next bit is a draft of the beginning step.
I want JavaScript for a page that displays a picture area and surrounds it with controls.
Let’s make the picture area 4 by 6 inches.
A white field.
Make the rest of the window sky blue.
Let’s do a command line!
The command line is a white field in the blue background with a cursor when you click in it, and you type in a command "drawpoint(number between 0 and 100, including decimal fractions if desired, the x value, similar y value, positive number of any size representing the size of the point in pixels, hexadecimal color value)". Pressing enter calls the drawpoint function and passes its parameters.
I have detailed some code for the drawpoint function here. I'm working things out as I go through part of it, but I think at the end I rework it into something fairly rational.
Paragraphs 4 and 5 of another post at my just revived blog respond another issue you raise, and record the emergence of my new process, and the post after that expands on the latter point, and introduces an example (since discovered to be flawed) of it application.
I am going to define the first step even more narrowly and write to you with that shortly.
Virtual Arcosanti is definitely part of my plan ... my version is low tech/no tech. I've just noticed how it fits in with another part of my Arcosanti plan that I'll detail for you shortly.
You could comment for me about how you would do these functions (back to the programming) in Web 2.0. I'd like to know something about that ... up to now, I haven't had a clue.
I want to do near term deliverables. The conference itself is a deliverable. Then, the first two days are essentially spent working on - planning - deliverables. The thing is, why wait. Anything we do immediately will only add to what we can do at the conference. My awareness swung to the absurd aspect of my plan. I thought "maybe we should plan it for October." Then I thought "let's plan it for August and October and January."
I have long wanted to do a graphics programming environment. We'll use that to build rendering functions. Another aspect of my plan: I want the user to fully understand the code behind the product. I want the product to teach users about itself. I'm seeing the content of our discussions in the course of building the product as a medium for beginning that project of teaching user about the product's methods. I'm mentioned similar ideas in earlier letters. I think I can map out an incremental build that will make the process intelligible for anyone, and everyone.
The next bit is a draft of the beginning step.
I want JavaScript for a page that displays a picture area and surrounds it with controls.
Let’s make the picture area 4 by 6 inches.
A white field.
Make the rest of the window sky blue.
Let’s do a command line!
The command line is a white field in the blue background with a cursor when you click in it, and you type in a command "drawpoint(number between 0 and 100, including decimal fractions if desired, the x value, similar y value, positive number of any size representing the size of the point in pixels, hexadecimal color value)". Pressing enter calls the drawpoint function and passes its parameters.
I have detailed some code for the drawpoint function here. I'm working things out as I go through part of it, but I think at the end I rework it into something fairly rational.
Paragraphs 4 and 5 of another post at my just revived blog respond another issue you raise, and record the emergence of my new process, and the post after that expands on the latter point, and introduces an example (since discovered to be flawed) of it application.
I am going to define the first step even more narrowly and write to you with that shortly.
Virtual Arcosanti is definitely part of my plan ... my version is low tech/no tech. I've just noticed how it fits in with another part of my Arcosanti plan that I'll detail for you shortly.
You could comment for me about how you would do these functions (back to the programming) in Web 2.0. I'd like to know something about that ... up to now, I haven't had a clue.
Suddenly ...
Suddenly, the blog is alive.
Suddenly, it fits, as the place for ALL THIS MATERIAL I've been accumulating. I struggled so with photos, earlier, but now I have a plan for that, too, which is putting them up one at a time. It's primitive. It's simple. It's just right.
At the very same time, I find myself embarked upon yet another new adventure with old friends. I begin my document here. I suddenly realized it was vital to capture these screens. Always click the picture for additional information. Always go to the next post to follow the story.
Always click the pictures for more information.
Suddenly, it fits, as the place for ALL THIS MATERIAL I've been accumulating. I struggled so with photos, earlier, but now I have a plan for that, too, which is putting them up one at a time. It's primitive. It's simple. It's just right.
At the very same time, I find myself embarked upon yet another new adventure with old friends. I begin my document here. I suddenly realized it was vital to capture these screens. Always click the picture for additional information. Always go to the next post to follow the story.
Always click the pictures for more information.
Back To The Blog
Christian,
Your comment "deliverables" got me thinking about ... well, first I thought let's you and me begin working on deliverable this very minute. Also, another of your comments has me questioning my inclination towards secrecy.
I worked on some ideas in a draft letter. They turned out overly complicated. Later, I got an idea for something simpler. I found - this was really exciting - that I was working on a long-treasured concept, shelved for some time: a graphics programming workshop. The user can experiment with graphics algorithms.
I then composed a short essay describing something very rudimentary, in the above way, in enough detail to illustrate the basic architecture.
The question is, what will attract users to such rudimentary thing. The answer is, the documentation. The user will come to the product through a series of descriptions of its workings. That series of documents starts to exist (I wrote about this in an earlier e-mail) as soon as we exchange letters about it.
Then, almost to my horror, I was confronted with the importance of getting those documents on line. For a moment, I despaired. Then, to my amazement, I remembered my blog, abandoned for some time, and realized: it will work.
Another question will be, how does this relate to my mapping concept? It is deep underlying structure for that ... is my contention. Here's a logical proposition: the purpose of software is empowerment of the user. The most fundamentally empowered state for a user is being able to write code. The truest software design parameter, then, is to teach the user how to write code. My plan is to integrate this function into all my products, so that the user is constantly learning about the code behind everything she is using. We begin, here, at the opposite end, by building basic components, and documenting the process.
Your comment "deliverables" got me thinking about ... well, first I thought let's you and me begin working on deliverable this very minute. Also, another of your comments has me questioning my inclination towards secrecy.
I worked on some ideas in a draft letter. They turned out overly complicated. Later, I got an idea for something simpler. I found - this was really exciting - that I was working on a long-treasured concept, shelved for some time: a graphics programming workshop. The user can experiment with graphics algorithms.
I then composed a short essay describing something very rudimentary, in the above way, in enough detail to illustrate the basic architecture.
The question is, what will attract users to such rudimentary thing. The answer is, the documentation. The user will come to the product through a series of descriptions of its workings. That series of documents starts to exist (I wrote about this in an earlier e-mail) as soon as we exchange letters about it.
Then, almost to my horror, I was confronted with the importance of getting those documents on line. For a moment, I despaired. Then, to my amazement, I remembered my blog, abandoned for some time, and realized: it will work.
Another question will be, how does this relate to my mapping concept? It is deep underlying structure for that ... is my contention. Here's a logical proposition: the purpose of software is empowerment of the user. The most fundamentally empowered state for a user is being able to write code. The truest software design parameter, then, is to teach the user how to write code. My plan is to integrate this function into all my products, so that the user is constantly learning about the code behind everything she is using. We begin, here, at the opposite end, by building basic components, and documenting the process.
Subscribe to:
Comments (Atom)
