Two Email Accounts => Can Only Keep Up With One

If I have more than one email account - e.g. work (Outlook) and gmail (personal) I can only ever keep up with one of them. I can only regularly drive one of them to zero, in the GTD manner.



Any of the various "unified mailboxes" {c,w,sh}ould help



- except that my employer doesn't want me to have corporate email outside their control, and I don't want personal email on my employer's email system.



And even if that were not the issue, using separate email systems avoids embarassing errors, like cross forwarding.



It would be nice if unified email systems had some sort of "Are you really sure that you mean to forward a TOP SECRET company email to a public mailing list?" filter/query applied to outgoing email.  Actually, for that matter, applying to saving email to the filesystem "Are you sure that you want to save your tax refund message from the IRS on a company share drive?"



Keeping separate email systems reduces the chance of such an error.  But it comes at the cost, of having two email systems.  And it seems that I can never keep up with two at the same time.  I am either keeping up with work, or with personal.



One of the costs of keeping two email systems is - what do they call it, cognitive overload?  Gmail does some things one way, Outlook a different way.  Or not at all, Or vice versa.  Two different tagging and folder systems. Two...  Using both regularly educates me as to their relative strengths and weaknesses - e.g. I recently accessed Gmail through IMAP on my personal copy of Outlook, because Outook is much better a handling large amounts of accumulated email than Gmail is - but I really don't want to become an expert in comparative email systems.



Another "advantage" of two email systems is scheduling.  E.g, I can try to restrict myself to never look at personal email during work hours, and vice versa. But...  well, how many of us can get away with not looking at work email on the weekend? Or overnight?  During a project crunch?



EMACS Gnus solved this years ago with mail reading topic modes.  You might have one order for reading messages, both in inboxes and folders, at work, one after work, one for "quick check", one for handling your mailing lists...   Two email systems is just a hack, a kluge, a poor approximation.



Plus, not reading personal email at work means that my wife and others have to use text messaging as the "high priority" emal equivalent.  Which means that thee is a third messaging system.



So perhaps I am wrong when I say "If I have 2 email systems I can only stay caught up with one of them."



Perhaps it is that if I have 3 messaging systems - Outlook, Gmail, and SMS Text Messaging  - I can only stay caught up with 2 of them.  Or maybe it is N, N-1.

Agile Documentation and Manuals - Testing

Should The User Manual Be Agile:



'via Blog this'



I have spent far too much time writing and maintaining manuals (for computer architecture) in the last year.



Since I have drunk the koolaid of Agile Development in software (test driven design, refactoring, pair programing) and have tried to evangelize Agile Methodologies for hardware development and computer architecture (with limited success - e.g. Intel has adopted something like scrum, although I hesitate to call it agile), I naturally think about how to design Agile principles to writing and maintaining technical documentation, computer architecture manuals, etc.



Of course, Ward's wiki has some pages on this: Should The User Manual Be Agile. WriteTheUserManualFirstIsWaterfall, ManualAsSpecification, WriteTheUserManualAsYouGo...  Of course, Ward's wiki is very stale. I recall discussions on agile mailing lists such as the [XP] mailing list.

But quick googling does not find much in the detail that I am thinking about.



A big frustration in my current work is that I had more automation in the documentation and manusl in my undergraduate RAMM/RISC/SEISM computer project in 1985 than I do now. I generated much of the manuals from high level descriptions of instruction encodings, and so on - in fact, I actually generated the instruction encodings.



However, over time I encountered much resistance to tools that generate correct documentation. So in some ways I have switched to emphasizing tools that can VERIFY that handwritten documentation is correct. Although I am still happy to generate whatever can be generated.



Of course, either of these approaches - generate or verify, automatically - requires the ability to automate. It is easy to automate text based markup - nroff, LaTeX, XML, SGML. Wiki markup. It is harder to automate when you are dealing with obsolete versions of binary formats like FrameMaker's binary .fm files.  (MIF helps, but is limited.)  Semantic markup helps a lot, as do wirdprocessing macros with meaningful names.



As many of the references point out, testing manuals and other documentation can be challenging.  There is simple stuff - spell checking, automatically checking table of contents.   Literate Programming techniques can be fruitful.  I believe the Itanium manuals defined instruction semantics in terms of pseudocode that could be extracted and run in a simulator.



But there are other steps.

More hassle switching sound devices ...

More hassle switching sound devices this morning:



In a Fuse meeting.  Started up using the internal speakers and microphone on my tablet PC - NOT the headset mike that I prefer to use.



Manually changing default audio device via Control panel did not switch over - apparently Fuse reads the default devices when it starts, and uses those for the rest of the session.



In the past I have been able to find a clickable way in Fuse to change the active audio device - but could not find it today.



Exiting and reentering Fuse would probably have worked - but the meeting was running, and I did not want the interruption.



---



Later, after undocking and returning, I received a Google Voice call.  Made the mistake of picking it up on my PC using Google Hangouts.  Same problem.



The default sound devices had changed back to the internal speakers when undocking disconnected the headset mike.



---



There are many apps to change or switch sound devices, e.g. audioswitch - Switch between default audio input or output + change volume - Google Project Hosting:( 'via Blog this')



All that I have tried change the DEFAULT audio device.



What I want is to change the ACTIVE audio device. Possibly on a per-app basis, although personally I have not seen the need.



I also want the DEFAULT sound device to change according to what sound devices are plugged in. Rather like the way Windows remembers that if I have a particular set of monitors plugged in, I want one arrangement of resolution and orientation.  I.e. software configuration dependent on hardware configuration.



I.e. when undocked with no headset, use the internal sound devices.



When docked, I get a headset, plus external speakers.  In my case, make the headset the default.



I also wish that my sound devices, like a headset, had a button that did something like "signal OS to make this the default or active sound device". And mute and volume control...

Lumo Lift arrives - no app - annoying proprietary charging interface

A while back I bought a LumoBack - a QS device that detected posture.  Work on a lightweight strap with velcro strap around waist. Overall I liked it - especially when I realized that it counted steps pretty well, better in many ways than my Basis watch.



Unfortunately, I lost mine - I found it annoying to have the lightweight strap around my waist, when wearing an actual belt.  I determined that I could take the LumoBack off the strap, and put it on my actual belt.  Unfortunately, after a few days of doing this, with occasional buzzing reminded me to maintain good posture, I realized that the LumoBack had fallen off my belt.  I conjecture that the plastic loops were stressed by the real belt, in ways they had not been with the original.



I would have bought a replacement, except the LumoBack was no longer for sale.  It was replaced by the LumoLift, worn at the collar.



Received my LumoLift yesterday.  First impressions:



---+ Overall Good



Nice small device.



Magnets hold it on through clothes.



Worn just under collar bone.



Advised not to wear on loose shirts.  Has worked okay on all the shirts I have tried so far.



Magnets hold tightly enough that twice I have stripped off a shirt and tossed it into laundry hamper, forgetting to remove the LumoLift - and had to go dig in the hamper when I realized I was no longer feeling the occasional buss when slouching.



User interface on actual device good:  double click to "snapshot", i.e. calibrate, triple buzz acknowledge; press and hold to toggle enable/disable buzzing when slouching, single buzz to acknowledge on, double buzz off.



In this respect better than LumoBack, where I frequently had to recalibrate using the Android app.  Actually, the LumoBack had similar UI on the device, but I seemed to use the Android app most.   It is a good thing that the LumoLift does not depend on the app as much as LumoBack did - since there is no LumoLift app yet.



The LumoLift seems less sensitive, out of the box, than the LumoBack was.  Fewer false alarms; necessary because no Andoid app to control sensitivity.  But it accepts slouched postures - I have to stand almost upside down to make it start buzzing. Perhaps when the app is available...



---+ No App Yet :-(



No Android app.



iOS app possibly available (unclear, I have no incentive to investigate).



Windows desktop app available "real soon now".



No Android app supposedly because Google Android's BLE (BlueTooth Low Energy) support is immature and unreliable.  This may be consistent with the flakiness of the LumoBack, which required frequent resets.



---+ No Pedometerr ... ?



At least not until the app is available.



I liked the LumoBack enough that I would recommend getting it instead of an activity watch.



But the LumoBacl cannot play there.



---+ Non-standard USB Charging cradle



* I am annoyed that the LumoLift has a custom charging station - USB, sure.  But this means that I cannot simply plug the LumoLift into whatever USB charger I have close at hand with a standard micro-USB cable  - at my desk at work, at home, in car.   Instead, can only charge up at one place.



Carrying around the charging station is suboptimal: since I have several such devices.  E.g. my Basis watch.



Indeed, one of the reasons that I liked the LumoBack so much was that it used a generic microUSB charging connector.  On several occasions I was able to charge it up, when my Basis watch was out of charge.  Now my LumoLift and Basis watch are equally non-functional.



Buying extra charging stations - perhaps. After all, I have a total of 4 chargers for my laptop, albeit one being a universal (home, work, cottage, backpack). I used to buy multiple cell phone chargers, back when cell phones had proprietary chargers.  But now that most cell phones have standard USB chargers, I just buy multiple USB chargers.



Perhaps it is good "gouge the consumer" marketing to require extra charging stations be bought by those of us who want ubiquity.  Although, at the moment, you cannot purchase extra charging stations from Lumo. (I think Basis does sell extra charging stations, for a "gouge the consumer" price).



Although "do not ascribe to malice too quickly that which can be explained by stupidity". Or lack of standards.



Perhaps the designers of LumoLift and the Basis Watch realized that USB micro connectors are unreliable.  Certainly an impediment to a QS deviced, that you might want to wear into the shower after a workout. (Easy to do so accidentally - I haven't yet forgotten to take off my Basis watch, but already, in les than one day of wearing my LumoLift, I have changed shirts twice without taking it off the old shirt.  Which I think means that the LumoLift is non-obtrusive.



Micro-USB is unreliable.  The Basis watch has 4 metal pads, the LumoLift two.  Probably these connectors are more reliable.  But they need pressure to make contact: on the Basis watch provided by a wraparound plastic cradle, on the LumoLift provided by magnets.



I am not aware if the LumoLift and Basis watch's power contacts are standard.  Not found in a quick google.



I do rather wish that the LumoLift and Basis Watch had chosen to use the same sort of TRS connector (headphone jack, TRRS, Tip/Ring*/Sleeve, mini 3.5mm Apple, submini 2.5mm).  Not standard USB, but reasonably common.  Good enough that iPods can be made waterproof for swimmers.



I can understand that such a "shaft" may be a pain to design around.  And that it is annoyingly thick.  Still, I wish that the LumoLift and Basis watch used connectors that were reasonably widely available.

Neat website with microbenchmarks

Measuring Stuff « Blog:



'via Blog this'

These course notes are broken

'via Blog this'



Looks like course notes for a computer architecture parallel programming course.



Stupid quote: "LL, SC ... Unlike the RMW instructions, there is no need to lock the bus, yet it implements an atomic operation".



Apparently does not know that most advanced microprocessors have not "locked the bus" to implement atomic RMW instructions for decades.



Also does not know that a smart implementation of an atomic RMW is guaranteed to make forward progress - at ;east, the RMW instruction itself will complete - whereas LL/SC implementations are plagued by forward progress problems.



Instruction like this is one of the big reasons parallel programming advances so slowly.