So here’s the basics.

.offlineimaprc:

[general]
metadata = ~/.offlineimap
accounts = GmailMain
ui = Noninteractive.Quiet
 
[mbnames]
enabled = yes
filename = ~/.mutt/muttrc.mailboxes
header = "mailboxes "
peritem = =%(foldername)s
sep = " "
footer = "\n"
 
[Account GmailMain]
localrepository = GmailLocal
remoterepository = GmailRemote
 
[Repository GmailLocal]
type = Maildir
localfolders = ~/.mail/GMAIL
 
[Repository GmailRemote]
type = Gmail
remoteuser = yourname@gmail.com
remotepassfile = ~/.mailpass

.msmtprc:

account default
host smtp.gmail.com
port 587
from yourname@gmail.com
tls on
tls_starttls on
# you can google on how to find this
tls_trust_file /home/webframp/.mutt/certs/Thawte_Premium_Server_CA.pem
auth on
user yourname
password yourpassword
logfile ~/.msmtp.log

relevant bits of .muttrc:

set mbox_type=Maildir                                   # mailbox type
set hostname=gmail.com                                  # This is my domain.
 
# GMAIL+OFFLINEIMAP settings
set imap_user=sean.escriva@gmail.com
set folder=$HOME/.mail/GMAIL
set spoolfile=+/INBOX
set postponed="+[GMAIL].Drafts"
set record="+[GMAIL].Sent Mail"
 
# Mailboxes via offlineimap
source $HOME/.mutt/muttrc.mailboxes
 
set sendmail="/usr/bin/msmtp"               # Sendmail alternative

I find running offlineimap via my crontab provides a nice solution to that
compulsive mail check impulse that can easily develop. Of course I also have a
Maildir check in my dzen xmonad statusbar using the ppExtras setting of my
pretty printer:

...
  , ppExtras = [logMail]
  }
where
 logMail = dzenColorL colorPink "" . wrapL mailIcon "". padL $ maildirNew mailDir
 mailIcon = "^i(/home/webframp/.dzen/icons/dzen_bitmaps/envelope.xbm)"
 mailDir = "/home/webframp/.mail/GMAIL/INBOX"

Maybe you can glean something useful from my setup

The very first problem is rather simple:

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.

Find the sum of all the multiples of 3 or 5 below 1000.

And a potential solution is haskell is could be to define the following:

isMultOf x n = mod n x == 0
 
sumList xs = foldr (+) 0 xs

After which the answer could be obtained with a simple:

sumList [a | a <- [1..1000], isMultOf 3 a || 
                             isMultOf 5 a, 
                             a < 1000]

And we have a list comprehension. Beautiful, and immediately expressive of exactly what’s happening for such a simple problem. The amazing thing is that properly written haskell maintains this same clarity and expressivity in even large scale programs. Sometimes it’s the little things in a language that makes you really appreciate it.

Hopefully wordpress hasn’t screwed up the formatting for you.

Sadly this is not the state of computing for most users. The most popular metaphors in computing today – the desktop, the start menu, folders – and commonly learned ways of interacting with them – point and click with the mouse – actually discourage productivity and break concentration/focus from a task. The implementations of these ideas further this interruption. True most users now have been trained to reach for the mouse and their hand eye coordination is good enough to accomplish any given step within a reasonable time frame.

How though does the switch-tasking our brain does to accomplish these steps affect the flow of thought for the current project? Clearly the less divergent thoughts and less steps required for any single step, the less the thought process is diverted from the main task. Further while few people struggle to make the required movements with a mouse, what affect does the repetitive nature of the movement have on long term health and usage? No doubt anyone who uses a mouse on a daily basis for several hours has personally felt the strain on their wrist that naturally comes with such usage.

The modern computing user interface has become cluttered and distracting, albeit a composited, semi-transparent glossy distraction. The initial appeal of such common interface elements hides the distraction, disguises the intrusive elements. It’s as if the computer were telling you, “never mind this modal dialog that just interrupted your thought process, it’s so glossy it must be helpful”.

Consider the average means of launching a program. Is it really ideal to require the user to graphically navigate to some onscreen coordinate that receives instructions before thought is transferred to action? Doubtful. How much screen real estate is essentially wasted for interface elements that support this idea? And how much time is spent arranging or re-arranging the frequently less than ideal placement of windows within this paradigm? Most daily computer users quickly outgrow the nagging tedium of these interfaces, but have no option to adjust the defaults.

I personally prefer an interface that is minimal and stays out of the way. An interface that handles much of what we have come to think of as routine automatically. And one that is fully configurable and flexible enough to support interaction in the manner that works for best me. The tiling window managers available on Linux and specifically Xmonad support this beautifully.

With Xmonad window management is automatic. I do not have to think about window placement as every window is automatically arranged to take the best advantage of screen real estate based on simple rules that I have configured. I can call applications with a single keystroke and they appear exactly where and how I want them. I can send them away or bring them back to the current screen with little more than a gesture, not once having to remove my hands from their comfortable perch above the keyboard. Many applications do not play nicely with this idea though and try to force certain window behavior. For these few troublesome programs it a simple thing to always “float” them, so that they behave in much the same as with traditional window managers. All of it is easily configurable in Haskell, an advanced purely functional programming language that is truly a joy to work with. Because of it concise syntax and clarity, I have been able to easily configure Xmonad to behave as I like, and it’s completely stable.

What is more, the means in which information is communicated is extremely configurable. I chose a minimal status bar using dzen, based on example scripts on the dzen wiki. Information when, where, and how I want it.

I encourage everyone that is using Linux to try it. After just a short period of time, I’m sure you will agree that you are able to work in manner that is both non-intrusive and more productive.

• My Xmonad configuration
• A screenshot of the setup:
• 

• 

  Arch+Xmonad = Crazy Delicious

It’s likely it won’t work.

No doubt this won’t be an issue once the Chrome Announcement is over.

Live video of Chrome Annoucement is available here

So I switched. To Arch.

Lately it seems like every useful tip I’ve gleaned has been from either the gentoo or arch wiki, so I had narrowed it down to one of the two. Both are appealing for their BSD style init systems and simple script based pacakge systems. Gentoo is full source though which, while not really a negative for most modern systems, was something I didn’t want to be restricted to. Arch allows a flexible binary or source build system, although the actual repo’s are binary. I love the rolling kernel too, no more waiting 6 months to get the latest, risking a broken system by upgrading in between.

In the process of switching I have fine-tuned things to the extreme. One of the tweaks is the battery status bar I use. It’s just a simple shell script that outputs formatted text to dzen2. It always bugged me that the script didn’t notice the charging state. After a simple little change, it does.

#!/bin/sh
#
# original script by lyon8 <lyon8@gmx.net>
# modifications from original by <sean.escriva@gmail.com>
# show your laptop battery state in dzen
 
BG='#1c2636'  # dzen backgrounad
FG='#99ffff'  # dzen foreground
W=150         # width of the dzen bar
GW=50         # width of the gauge
GFG='#33ccff'  # color of the gauge
GH=7          # height of the gauge
GBG='#333'    # color of gauge background
X=1770        # x position
Y=1200        # y position
FN='snap'     # font
 
STATEFILE='/proc/acpi/battery/BAT0/state' # battery's state file
INFOFILE='/proc/acpi/battery/BAT0/info'   # battery's info file
 
LOWBAT=25        # percentage of battery life marked as low
LOWCOL='#ff4747' # color when battery is low
CHGCOL='#60da11' # color when battery is charging
TIME_INT=1       # time intervall in seconds
 
PREBAR='^i(/home/webframp/.dzen/icons/dzen_bitmaps/battery.xbm) ' # caption (also icons are possible)
 
while true; do
# look up battery's data
BAT_FULL=`cat $INFOFILE|grep design|line|cut -d " " -f 11`;
STATUS=`cat $STATEFILE|grep charging|cut -d " " -f 12`;
RCAP=`cat $STATEFILE|grep remaining|cut -d " " -f 8`;
 
# calculate remaining power
RPERCT=`expr $RCAP \* 100`;
RPERC=`expr $RPERCT / $BAT_FULL`;
 
# draw the bar and pipe everything into dzen
if [ $RPERC -le $LOWBAT ]; then
GFG=$LOWCOL;
fi
if [ $STATUS = 'charging' ]; then
GFG=$CHGCOL;
else
GFG='#33ccff';
fi
#echo -n $PREBAR #uncomment for an icon
eval echo $RPERC | gdbar -h $GH -w $GW -fg $GFG -bg $GBG
sleep $TIME_INT;
done | dzen2 -ta c -tw $W -y $Y -x $X -fg $FG -bg $BG -fn $FN

I honestly did not understand the full scope of this until recently returning to a corporate environment after several years of independent consulting. The clear dependence on html formatted emails, what some refer to as “rich text”, is entirely wasteful of internet bandwidth. As an example, using emails I have actually received. Given the same message located on my imap server, one saved using evolution with full html formatting intact; the other saving a plain text copy thanks to mutt (my MUA of choice):

$ du -h mail.msg.txt
4.0K    mail.msg.txt

$du -h mail.msg.html
24K     mail.msg.html

For this example, using real world sample emails, the html email is SIX TIMES larger than the plain text version. Assuming a large amount of correspondence for any given day, about 100 individual messages, the difference between 400k and 2400k starts to be noticeable, html email generating 2MB a day more of traffic. Now in all honesty, with the bandwidth available today that amount is negligible, but there are many other valid arguments against html email worth considering. Plain text email is immune to viruses, common spammer tricks like html tables and hidden text are negated, security risks from inline images and other html elements are removed, accessbility for is increased for people using screen readers and anyone who can not use a graphical interface.

Thankfully I’m not the only person who feels this way. This issue has been around for several years and deserves much more attention than it gets. The folks at the Ascii Ribbon Campaign have a nice one page overview as well more links and instructions for configuring your email client to send plain text emails.

My favorite summation of all the reasons (taken from George Dillon): HTML email can be dangerous, is not always readable, wastes bandwidth and is simply not necessary.

Not convinced? (and why would you be?). Take a look at some of the following links:

• Email is not a platform for design – Jeffrey Zeldman
• When is e-mail like a bad website? – also Jeffrey Zeldman
• HTML E-mail is STILL evil – George Dillon
• Force mail.app to display plain text by default – maxosxhints.com

Thanks for reading.

                       _
ASCII ribbon campaign ( )
 against HTML e-mail   X
                      / \

Also wishing I was more connected with the portland tech community, there’s all these great people around here and I have no idea who they are.

that’s all there is.

*update: WordPress 2.5 is really, really nice. I haven’t been able to explore all the features yet obviously, but they have improved everything for an overall better experience. The new dashboard is excellent. The default editor feels incredibly improved, with much better support for inserting various media into posts. the downside is that none of my existing plugins work, as expected. I’m sure that will be fixed rather quickly as I don’t use anything uncommon. For now I’ll keep the testing installation around until they get updated. Don’t bother looking there, you won’t find anything interesting.

   Don’t get me wrong, I’m not against social networks, or even their transference to the web and various sites that with them. In fact I see the amazingly huge growth in web 2.0 social apps, and related companies even, as a natural evolution of the internet and even computing. For years there have been technologies that allowed an ever increasing level of community and group identity and I hope that people will continue to innovate and introduce new and exciting applications to support this idea. I still remember learning about the "wall" command on my first ever public access unix account and thinking just how great it was to be able to be in touch, however slight, with others on the very same system. Others may not have felt the same when it was misused but for the most part that initial odd feeling of camaraderie was shared by fellow users, at least the ones I met personally. Laughable? Maybe. Subsequent personal discoveries such as email, usenet and irc heightened my excitement for the possibilities of connecting with a new group of friends and contacts. These like minded ones, I imagined, would be a new support group. They could support the interests I had and hopefully teach me much more about these very same interests. In the end they did so to varying degrees.

   Now survey the modern landscape of interconnected people, applications and api’s. It’s left a single machine. It’s not defined by it’s access protocol. Myspace and Facebook have changed what it means to be in touch, redefined even who is worth adding as a "friend". Weblogs have given more individuals the ability to voice their ideas to whoever wants to listen and syndication methods have made it easier to follow the ramblings of more and more individuals, myself included. Incredible collaboration has taken place on sites like Wikipedia, which itself has developed a huge community and has active discussion surrounding much of the changes taking place. I personally spend entirely too much time wasted on Twitter, one of a new group of supposed micro-blogging services to start up in the last few years. There are of course the numerous social news sites, like digg, reddit and others, as well as social bookmarking at del.icio.us. Then there’s the numerous photo sharing sites with their own communities and it can go on and on, ad nauseam.

   Ten years ago I would not have imagined that 90% of the pages I visit on a daily basis would allow the type of comment/response feedback that has become the norm, and that it would be commonplace to get a response quickly. Nor could I see that there would exist the wealth of interesting communities that have grown around such interesting social apps started in this web 2.0 era. Does any of this mean Myspace or Facebook will slowly fade in usage, replaced by an application better suited to enabling the most basic of human needs communication? Only further time will tell, but if there is a point to this rambling it is this:

   As time moves forward and people become accustomed to the pieces of community afforded them by the current standard applications, they naturally desire more. They want a more meaningful community that is useful to them and wherein they can feel useful. It has to function naturally and be so unobtrusive in it’s overall design that it blurs the distinction between what is a "real" conversation, in person, and what takes place over these new evolving channels. Imagine going back to a single machine, sending a broadcast message to every logged on user who chose to allow it or could accept it. How restrictive and limiting is it compared to todays options. Now picture yourself looking back ten years from now with that same feeling, only now it’s Myspace that is restricted and limited.

Broadcast Message from sean@webframp.com
        (/dev/ttys000) at 3:23 PDT...

I look forward to your comments