Disclaimer

The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Tuesday, October 02, 2012

handheld calendar

using android calendar on handheld.

want geo so can detect nonoverlap but too much travel time

want selectable colors

want calendar groups, act/deact together:

eg oceanside tides, surf, weather

eg woods, fire report

Monday, October 01, 2012

Importance of Non-Blocking User Interface

It's a real pain that Outlook has a blocking interface: while a slow command like running rules manually is running, I cannot switch to another folder and get work done processing other email.

(Instead I switch to my blog and complain.)

Testing Mail Sorting Rules

I used to depend heavily, very heavily, on email sorting rule.  Back in the old days, when I used MH on UNIX. I can't even remember the mail filters programs I used.

As I was forced, against my will, to use Outlook, I used rules less.  Not because I wanted to - but because (1) Outlook's rules are much less reliable, and (2) the "development environment" for Outlook rules is much less good than text files on UNIX.  No version control.  No diff.

Basically, I tried using Outlook rules.  But they were so much hassle, so I gave up.

(Anecdote: at Intel I kept pestering IT for help with rules.  After I exhausted them, they told me about this power user they had heard about, who knew all about Outlook rules.  IT person #1 did not know who it was, so sent me to IT person #2, who sent m to ... Eventually we found this power user.  It was me, myself, and I. As incarnated before I left Intel for AMD. My reincarnation after I returned from AMD to Intel was referred to my original incarnation.)

GMail was better for a while.  The rules are slightly better than Outlook's.  But, mainly, the Bayesian importance filter was able to help a lot.

But the email onslaught grows.  So I am back thinking about emal rules again.  In both Outlook and Gmail.

---

Minimum requirement: version control.  It is necessary to track what works, and what doesn't.  Comments.

---

Thinking about why email rules are such a hassle:

Testing.

Outlook rules in particular are a pain, because it is had to create a test input set.   The rules that move items to a particular folder, well, move them.   Thus destroying the test input set.

I suppose the rules could be tested in a special account, and then copied.  But that has hassles.

If the rules could be made conditional - only optionally moving....

 Having the rules apply labels or categories rather than move helps.  

Gmail's folders, of course, are really just labels or categories.

===

What I really want is multiway Bayesian classification: not just important/unimportant, but applying tags other than important.  Machine learning to learn what labels and categories I want to apply.

---

For now, though I am stuck with Outlook.

:-(

Sunday, September 30, 2012

Is Google Sites a wiki? I think not.

I went to Ward's oriogional wiki, http://c2.com/cgi/wiki?WikiDesignPrinciples, seeking ammunition to blast Google Sites (http://sites.google.com) with.

Although http://en.wikipedia.org/wiki/Google_Sites says that Google Sites is a wiki, I don't think it is.  Or, at least, Google Sites is a lot harder and more painful to use than most of the wikis I am familiar with (Ward's original, mediawiki, twiki, moinmoin, zwiki, ...)

I think Google Sites, née JotSpot, is really one of those CMS that started independently, and then tried to adopt the wiki moniker after the fact.  Or else was developed by someone unfamiliar with wiki, who put a wiki-like cast over something else.
     Overall, in terms of my least favored, most hated, wiki faker sites,  Google Sites is less than Atlassian Confluence, and roughly equivlant to Microsoft's FlexWiki.

My main complaint: Google Sites makes it hard to create links to pages that do not exist yet.

Actually, Google Sites makes it hard to create links period:  There is no quick syntax like WikiWord or [[double bracket links]].  The keyboard shortcut alt-I gets you to a place where you have to choose from a too-ling list of link tyes.

But, worst IMHO: there doesn't seem to be a way to create a link to a page that does not exist yet.  At least not that I have found.  In creating a link I can create a new page - but there's a big difference between a link to a page that does not exist, and a link to a newly created page.

---

I *want* ti like Google Sites as a wiki.  But IO can't.

===

Google dpcs is even less wiki-like.

Tuesday, September 25, 2012

emacs kill limited to 64K across frames (copy-region-as-kill / yank)

I just realized that cutting and pasting more than 64K bytes does not work in emacs 24.1.1

... if I cut in one frame and paste (yank) in a different frame

It is truncated at 64K.

It works if I cut and paste in the same frame.

--

I have encountered this bug when cutting and pasting from emacs to X.  Not sure if it is related here.


Improving Test Pass Rate and Correlation

I prefer to do TDD, Test Driven Design - heck, often the original term, Test First Programming.

It's nice to write a test that fails, write the code, pass the tests including the new one (getting a green bar on your testing widget, or a count of tests failed=0 if not so GUI), rinse, lather, and repeat.

Sometimes I write a bunch of tests in advance, but comment, ifdef, or if out all bit the first test that I do not expect to pass.  Get the green bar of all current tests passing, enable an already written test, and repeat.  This gives me an idea of where I am going overall, preventing getting bogged down as tests proliferate for minor details.

It is important, useful, good, to incrementally enable such tests, rather than enabling them all at once.

a) It's nice to get the green bar when all tests pass.  Positive reinforcement.  If a whole slew of tests are written in advance and are mostly failing, it can be too easy to lose sight of the progress you are making.  Or to go backwards without noticing - e.g. 2 tests start working and 1 fails, looks like +1 started working, so you may miss the new failure.

b) on a more mundane level, this allows you to sketch out tests, in languages like C++, that do not even compile yet.  It is a waste of time to write a whole slew of tests in advance, spend ages getting them to compile, only to realize that there was a design flaw along the way that becomes evident as you get some earlier tests to run.

OK: TDD good.  Keeping tests mostly running, good.

...

But unfortunately sometimes we work in less Agile organizations.  Or in Agile teams, coupled to an ordinary Q&A team.  The sort of Q&A team that writes a thousand test cases in the first week, and then goes off and does something else while you take months to implement.  (It is especially easy to write such test cases if there is a random pattern stress tester, or some automation that creates many similar tests, slightly different.  A maze of twisty little tests, all slightly different.)


Worse: the QA team may be working concurrently. So, yesterday you had 100 tests passing, 900 failing.  Today you have 110 passing, 990 failing?  Is that an improvement, or did they just write some tests that test already implemented features?


It is depressing to have a thousand tests failing. And to have to pass/fail stats vary almost randomly.

Beyond depressing, it doesn't help you decide what to work on next.  Some of the test failures are expected - unimplemented features.  Some may be the feature you are coding now - higher priority.  Some are for features that were working, but which regressed - possibly higher priority to fix.

Faced with such an amorphous mass of tests, it seems a good idea to carve out a subset that is known good, and grow that.

Also, to do a preliminary triage or failure analysis, and create an simple automated tool that classifies the failures according to expected fail/pass, type of error, etc.   This way, you pick a class of failing tests, write the code to make them pass, and then repeat - always choosing a class of failing tests that are incrementally easy to write the code to make pass, rather than arbitrarily choosing a test that may require much blind coding before it can pass.

Run that regularly.  Use it to guide your work.

Or, at least: I'm using it to guide MY work.


And, along the way... yes, I'll also do some TDD test-first of my own. In my experience, the QA tests often stress, but often do not test the most basic features.


Monday, September 24, 2012

What I want in PIM software


http://wiki.andy.glew.ca/wiki/What_I_want_in_PIM_software

I confess:
I keep trying to use [[PIM (Personal Information Managemernt)]] software,
but I keep getting disappointed.
I keep falling back to low tech solutions,
such as index cards.

* In 1997 Moshe Bach, seeing me using the paper ScanCard system years ago, said that he had lost all respect for me as a hacker. :-(
* See [[Organization, technology, evolution of]]


But... I know the advantages of computer.

This page for notes on what I want in such a system.

Perhaps I should keep these notes in private, and secretly developer a killer app.
In my copious free time.
(:-()

= Embedded in a Log =

My overall vision:
* smart stuff embedded in what is overall a log, a diary.
* i.e. overall unstructured, with structured nuggets embedded in it.

Actually, a log has some structure: timestamped items.
But further specialized structure embedded in such items:
[[to-do lists]],
[[checklists]],
[[trackers]].

I envision this as XML, but am not religious about XML.
JSON, however, I think is too stupid to represent what I want
without a lot of extra work.



= Checklists =

== Transcludable checklists ==

Checklists should be hierarchical. More: embeddable. [[Transcludable]].

Nearly everything should be transcludable, both as source and destination.
E.g. text blocks should be transcludable into checklists, and vice versa.


E.g. the checklist I use to remind me what not to forget when I go to the coast
may have my PC travel checklist and my kayaking checklist transcluded into it.

Checklists and to-do lists are closely related.

== Tracking partial progress ==

In my [[GTD]] [[tickler file]], I have many repetitive items like
"Check that all of my many email accounts" are working.
I try to automate as much as possible, but manual checks are still worthwhile.
E.g. "check that I can log int to all of my password manager accounts".
"Check that I can log into my password manager".

I have tried making the check of each account an individual tickler item.
Overwhelming.

But making a single item a to-do for checking that all of my many email accounts is working is equally overwhelming.

I want to create a single repetitive checklist.
Listing all of the things I want to check.

Repeating with an overall frequency.

A checklist to remember what I have finished on the current iteration,
and, more important, what I have left to do.

Supports activities that you do at a low boil, such as checking one account per day.

= Projects =

Following [[GTD]], there are projects, separate from tasks.

I divide my projects into
* [[Current Projects]]
** things I am currently working on. Things that I am trying to actively drive.
and
* [[Background Projects]]
** things I may work on for months or years
** accumulating info as I go.

= Scrubbing =

One of the most important things about a PIM is scrubbing.
Ensuring that information is revisited periodically.

Tasks need to be revisited on next action dates.
Ditto current projects.

Background projects may not have next action dates
- although revisiting as time allows is a good idea.

Revisit all reference items?  All assets like checklists?

= Reminders =

It is often useful to have not just an agenda for the day,
but also a next reminder.
Many items seem too unimportant to put on an agenda or calendar,
but are importahnt enough to create a reminder for.

When completed, the reminder can be automatically logged.

It is often important to create reminders not just for the beginning of a meeting,
but also for the end.
That way, you can choose not to allow your  meeting to run longer than planned, even if nothing is scheduled next.
(I assume that there are always jobs that can be fit into unscheduled tgime).

= Calendars - min time =

It should be possible for a calendar to reserve, not just specific blocks of time, but specific amounts of time at no particular instant.

E.g. "I want to reserve 8 hours per week for 'sharpening the saw' - it doesn't matter when, but must be in blocks of >2hours".
Accept meeting requests uip to that point...

= Exercise Trackers =

I have been enjoying Android exercise trackers that count situps, pushups, etc.
But many are too specific.
It should be possible to have a simple counter app that can count...  whatever you want.
E.g. sun salutations in yoga.

Basically, name of thing being counted,
and generic count trigger: shake, touch, etc.

= Trackers =

Should be automatically logged.


=====


Did I mention, again, that I want same formatting in wiki blog log etc.