My Best Teaching Is One-on-One

一対一が僕のベスト

Of course, I team teach and do special lessons, etc.

当然、先生方と共同レッスンも、特別レッスンの指導もします。

But my best work in the classroom is after the lesson is over --
going one-on-one,
helping individual students with their assignments.

しかし、僕の一番意味あると思っている仕事は、講義が終わってから、
一対一と
個人的にその課題の勉強を応援することです。

It's kind of like with computer programs, walking the client through hands-on.
The job isn't really done until the customer is using the program.

まあ、コンピュータプログラムにすると、得意先の方に出来上がった製品を体験させるようなことと思います。
役に立たない製品はまだ製品になっていないと同様です。

Showing posts with label whatifIhadmoney. Show all posts
Showing posts with label whatifIhadmoney. Show all posts

Friday, May 4, 2018

Yet Another WIWDIIWTLWPI

This is yet another "What I would do if I won the lottery without playing it" post.

I don't play the lottery, but sometimes I daydream about what I would do if I were able to suddenly have a large amount of discetionary spending money -- millions of dollars worth.

Most of those daydreams have been about rebooting the computer/information industry with better information encoding schemes, better programming languages, better processors, better operating systems, better network protocols, etc.

Lately, my dreams have been a little less extravagant and a little more concrete.

Facebook has evolved, but it's still unstable. It works for a lot of social purposes, and a lot of marketing purposes, but lacks support for the sort of interactions authors helping each other need.

There are several authoring platforms available, but most tend toward rich text, meaning formatting.

When you're in working in the deep internals of a fiction, you don't want to be distracted by formatting. All you want to focus on is constructed of undecorated text -- typing text in, saving it in units of chapters and sections, reading what you've written, comparing what you have with what you had.

Raw text and version control.

Linux and BSD OSses provide raw text tools of various usability. Gedit is what I usually use, but friends tell me Geany is better. In a pinch, there is always vi (vim), and some prefer emacs. Lots of choices.

They also provide version control systems that work quite well with raw text. Git is popular now, and it's my current tool of choice.

Decorated text, by the way, gets in the way of version control. Someday I'll write a post in one of my programming blogs to explain why.

Someday I'll write the tools needed to wrap raw text with proper style definitions. CSS (Cascading Style Sheets) and HTML are not those tools, they just add more fragile layers of fragile decoration. I only hope I'll have the time to write those tools in this life.

In the meantime, text decorated with TEX or markdown gets close to the level of integration with version control that I would like.

So, if I had ten million or so dollars, I'd set up
  • a public repository like github.com or sourceforge.net or osdn.net, 
  • mashed up with social interaction functions like Facebook's -- or, more likely, slashdot.org, 
  • with a publishing platform like Wordpress or Blogger (but better).

And git being as it is, authors could keep local copies of all their versions on their own computer systems.

I'd integrate version control with the publishing platform so that authors and their critique groups would be able to select specific points in the rewrite process to read in context.

And, open source being what it is, authors would be able to replicate the publishing on their own computer systems.

Of course I'd set up domain name services so authors could have novels published as subdomains of their authoring domain name without too much fuss.

For instance, instead of
and such, they could be grouped as
  • book-review.joelrees.reiisi.net and
  • Marriage-of-Inconvenience.joelrees.reiisi.net 
  • Water-and-Earth.joelrees.reiisi.net
or something similar.

I'd set up an interface to the access control mechanisms to make it easy to give read/write and read-only access for specific works to the author's choice of critique groups, writers' communities, and ad-hoc groups.

And I'd include tools to help bundle up specific versions of a work in formats acceptable by the copyright offices of the various countries.

Daydreams.

Back to work. I need to finish six novels -- or is it seven, now? -- while teaching English and working other jobs to put food on the table. C'est la vie.

Monday, August 31, 2015

Why I Can't Use the Phrase "Re-inventing Wheels" as an Insult

Many times you hear someone accuse someone else of "re-inventing the wheel" in a tone of derision.

Sometimes I say that someone is re-inventing the wheel.

But, from me, that can't be an insult.

You see, if I could find someone to sponsor me, I'd be re-inventing the entire information industry infrastructure.

Information encoding? Yeah. I want to replace Unicode with an encoding standard that would encompass the functionality of asn.1 and sgml in one rational, accessible whole, not to mention make embedding binary data in text work much more smoothly. And reduce or eliminate glyph aliasing with out-of-context characters. And separate the international encoded sets from the national encoded sets, to help reduce such aliasing and make regular expressions work better in local contexts.

That's definitely re-inventing a lot of things perceived as wheels, not presently worth the attention of further refinement.

Programming languages? Yeah. I want to re-invent the language C, the runtime, add a couple of storage classes to reduce the problems of overwriting local variables and controlling concurrent access from separate threads, and add little bits to function declaration and call syntax. And I want to reinvent a language called FORTH, so it would be more amenable to being used as a user interface shell language, among other things. And re-invent Unix with a new executable object format supporting all this. That's going to be equivalent to an earthquake in userland, not to mention in the system itself.

Networking? Of course. I want to get rid of IPv6 and implement nested IPv4 addressing. Make NATted addresses optionally visible externally, to open up more static addresses and reduce the incentive for ISPs to charge through the nose for a static address, for starters.

CPUs? Those too. Intel has been burning up resources building their monopoly on the CPU market for far too long. ARM helps, but too many manufactures are too willing to play games trying to lock their customers in. And no one really supports proper separation of user resources in current CPUs. We need to focus away from raw speed and more on stability and securability.

And so on.

Yeah, I want to re-invent wheels. So, if I merely note that someone is re-inventing wheels, that, in and of itself, is not evil. And I do not intend insult by it.

Re-inventing wheels is good for many reasons, and not just to provide churn for the sales crew to work.

(Re-inventing wheels solely for sales churn is somewhat evil, but it can be better than keeping the world as it is. I should rant about that sometime, too.)

Sunday, October 23, 2011

Back-Seat Driving Apple

Or, perhaps, trying to drive from outside the car.

I'm definitely not showing a sense of social protocol here, but I've been daydreaming about this for a long time, since well before I knew Steve Jobs was losing his battle with cancer. (This is more-or-less what I would have posted back in October, but didn't have time to.)

(If the reports of Steve's last diatribe against Android are accurate, I'm inclined to think respect for the dead means something a little different in this case.)

But here's what I'd do, were I in a position to do so, to try to avoid Apple following Bill and Microsoft down the hill:

Start two sister companies, called, maybe, AppleSeed and Crabapple.

The "Appleseed" company would take over from Apple most infrastructure intellectual assets, including the continued development of the OSses and fundamental hardware.

Apple itself would stay focused on customer/end-user issues and on designing and selling the current and next models.
 The Appleseed company would also be tasked with setting up and supporting a true open source community around both Darwin and iOS. Not the non-community archival site at opensource.apple.com, nor the para-community you find at www.macosforge.org. A true community, something like the Fedora community that Red Hat supports. Around both Darwin and iOS.

And the Appleseed company would be tasked with moving discontinued products, both software and hardware, into a community supportable state, mostly under the Apple Public License, GPL, and so forth. Include hardware and circuit diagrams for the old 68k and PPC stuff. Part of that would be clearing "intellectual property" issues and releasing the old Macintosh system and (Apple's) application code from the original Mac through Mac OS 9 under open source licenses. And clearing the "IP" issues for re-implementing a desktop manager based on the old Mac UI.

The "Crabapple" company would be a community based prototyping company, where one would be able to buy such things as PPC, ARM, and ColdFire motherboards running DarwinOS and iOS-sans-UI, and other DIY gadgets. You would also be able to buy current AMD x86 processor based systems pre-loaded with DarwinOS and open source desktops like KDE or XFCE. (No need for INTEL systems, Apple itself can maintain its relationship with INTEL for as long as it seems prudent to do so.)

The Crabapple company would also be tasked with maintaining security level updates for the Mac OS X versions that Apple has EOLed. This would not be a free service, but would not be overly expensive, either, perhaps $25 a year as a subscription. And they could provide other fee-based services, such as providing several versions of non-warranteed Aqua UI to load on top of the most recent DarwinOS.

Or, instead of actually maintaining the down-level systems, the Crabapple company could support the MoL/MoM community, officially allowing the old systems to be run under emulation on newer hardware under current OSses.

The Crabapple company would also publish open source hardware drivers for use in the Linux and BSD communities, under appropriate licenses

Why? end-user buzz is not enough, and Apple is too big already.  This would help keep Apple small and competitive.

The licensing would allow non-Apple companies to compete with the Crabapple company, which would also build the community.

And the future is in communities, made of small companies.


Thursday, April 9, 2009

daydreams

Okay, so I'm having trouble getting out of the daydream mode. I have to go back to work tomorrow, and I have accomplished none of the projects I had lined up for myself over the break -- drupal, finishing my shiftJIS ctype project, getting my BIF dialect of figFORTH moved to C so I can port it to whatever I use, fixing RanBunHyou and extending it for scrambles, etc.

I did almost get Drupal up on my portable. And I sort of got a start on rebooting the shiftJIS ctype project.

Too many things I want to do.

So, I'm going to list the things I daydream about here and see if that helps me get a better grip on my prioities.

So --

First big dream. Buy Apple. (Where do I come up with a cool 60 billion or so?)
  1. Bring back PowerPC Macs, starting with a dual-G4 Mac Mini. (Let's see just how much "better" Intel's core really is.)
  2. Start a line of ARM Macs, not just iPhone and iPods, but netbooks and ARM Minis.
  3. Add one more ethernet port to all Mac Minis.
  4. Start a line of Macs for tinkerers, cheap, slots for additional ports, breadboard cards.
  5. Start a line of Mac Word Processors, essentially netbooks with built-in thermal or light-weight ink-jet printers.
  6. Etc.
Second big dream. Take over Microsfot. Microsoft, I mean.
  1. Freeze all current products, except for security and other serious bug fixes.
  2. Split it down the product lines. (Some guy who calls himself joudanzuki blogged about this.) Make the APIs all open and free.
  3. Fund the Wine project and a couple of others, and add paid engineers.
  4. Start a new OS product, MSWindows Mars, based on BSD code and Wine, under whatever license Wine is under for the MSWindows interface layers, and keeping the BSD license(s) for the BSD infrastructure. But ACLs (Access Control Lists) will be an add-on. The security model will be based on the Unix model.
  5. Make a real mail system somewhat compatible with Outspook, I mean, Outlook, but designing out the intentional holes. Put the thing under a true open source license, preferably GPL, but at least as open/free as Apple's APL v. 2.
  6. Etc.
Third big dream. (My real dream.)

Start an open source computer company to compete with Apple and Microsoft.
  1. Build and sell systems with free/open hardware design, with drivers licensed under a two-clause BSD-class license so they can be used in either Linux or BSD OSses. Netbooks, home and small office NAS/routers/servers using low power processors (most likely not Intel).
Once that company is up and running, start a new OS project that would borrow significantly from Unix.

  1. The run time would explicitly separate the program flow stack from the parameter stack, and explicitly provide a hierarchical local address space access mechanism (with the means to close it off).
  2. Users in said OS would be effectively virtual systems of their own, running their web, mail, and other external resource browsers as separate (sub-)users not privileged enough to access the primary user's data space or even other browser's data space.
  3. As a benefit of the user model, secure special-purpose browsers would be implemented to access banks and share credit information with stores, etc.
  4. Said OS would need a CPU that would cache the stacks efficiently and efficiently implement the address space separation in hardware, so I'd need to design a family of processors optimized to that kind of run-time.
  5. I'd need to build a language back-end that would take advantage of the OS, run-time, and CPU.
  6. And then build various front-end languages, post-fix, in-fix, and pre-fix. (Yeah, I like FORTH and C.)
  7. Etc.
And while I was balancing those two projects, current information encoding schemes are really messy. That's okay, but the URIs and other stuff that computers process need an encoding that is less ambiguous. So,
  1. Design a new standard for information encoding that would have an international encoding and international display/parsing context for use in things like URIs, and include most of the current encodings shifted, so that you could work with just about any language in its own context and not fight the production rules of all the other languages.
  2. It would also include a binary encoding, so that burying binary data would be less of a problem.
  3. And it would include separate tag characters so that parsing tags would not be such a headache.
  4. Extensible IP type addresses would also be defined in the encoding, although I suppose it's too late to replace IPv4 and IPv6 with extensible IP addressing. High-bit extension could be used, although it would require re-possessing most of the current IP addresses. Another possibility might be to start appending the internal, NATted addresses to the router address to get longer addresses, although that would require some standards beyond NAT to allow nested addresses to be physically independent of the router.
  5. Something like ASN.1 would be built into the encoding, as well.
And while that's eating my lunch and taking more time than a guy my age can manage out of every day, I'd set up a personal data service that would provide e-mail and web sites with a few more guardrails than we presently have. Specifically,
  1. Customers would have their own domains, and the personal data server would provide dynamic DNS mapping, so that the customers could even run their own domains on their own servers if they chose to do so.
  2. Customers would by default be routed IPv6, although I would prefer to use an extensible system, now that the processing resources are available to support an extensible numeric (index) addressing scheme.
  3. A mail system that would take advantage of the customers' private domains, to allow them to define their own mail addresses as they choose. This would help with spam problems, because the customer could even make up new addresses on the spot for new contacts, then go home and register filters for those addresses, and know who is trying to do what with his or her personal information.
  4. An on-server mail viewing system that assumes that the user wants to sort most of the mail before looking at it, and lets the user sort based on header and envelope contents, setting up persistent sorting rules that would, for instance, send all posts with variants of "viagra" and the like in the subject or sender headers to a folder labeled "fraudulent medical ads", and so forth: select the text, right-click for a list of context elements to trigger on, left click to commit the rule, and the sorting rule remains in effect until the user edits it. And the destination folders have rules like, hold one week and then dump, or dump oldest first when the folder hits a limit on size or number of messages. (Google mail does get close to this kind of thing, but, yet, not so close after all.)
  5. Web sites are where I get lost, but the point here is to refrain from restricting the knowledgeable customer, but not expose the less knowledgeable customer to the dangers of letting machines be their proxies. Domain management for customers hosting their own, web hosting for customers who want that, and bulletin boards and blogs for customers who want that. Google already does this one, pretty well, given the technology that's available to them.
Looking back on that, Apple and Microsoft are responsible for their own problems. So I really don't benefit from daydreaming about fixing their problems.

The web services companies, if the technology were available, Google, Yahoo, etc. would be able to do the things I'd like to do. The only issue is whether we can get the ISPs to quit trying to hold domain names and IP addresses for ransom, but I think competition would eventually take care of that.

The biggest problems are
  1. that the underlying information encoding is too cluttered by kludges to efficiently process in the way we need to get this kind of stuff to work,
  2. that the run-times of the various OSses are too cluttered by kludges and cruft from technologies that lead in other directions,
  3. that the programming languages we have are at once too inflexible in expression and too loose in semantics to support the kind of systems I'm trying to describe here.
  4. I'm not sure whether the current crop of CPUs can efficiently run this kind of system. I'm pretty sure the Intel CPUs have too much cruft, and not enough memory support for efficiently managing memory. Most of the other CPUs are oriented towards the limited execution model that the 8086 supported too efficiently, too, as a result of having to compete in a market where the 8086 was seen as the leader.
Hmm. Do I see anything in the above that would help me weed out daydreams I can't or shouldn't reach for, but leave me something to work on?

Can't say that I do.