YJL

I don't want to take away the effort which the developer of markdown-here (seen via GitHub Explore) has put into this browser extension and addon, but I found it's unbelievable to spend a lot of time for a solution when there is a very simple one already lies around within arm's reach.

First of all, he gets it all wrong. Having Markdown support in webmail client is not a solution for his problem which he describes in the README:

Writing email with code in it is pretty tedious. Writing Markdown with code in it is easy. I found myself writing email in Markdown in the Github in-browser editor, then copying the preview into email. This is a pretty absurd workflow, so I decided create a tool to write and render Markdown right in the email. [emphasis mine]

He is right, that workflow is tedious, however the problem is not the workflow, but why chose a workflow isn't necessary in the first place. Hacking Markdown into webmail client is not a solution, but another problem, this reminds me of that two problems. Just to see the first #1 to #6 issues, he is only troubling himself. Hacking someone's web interface is never be a good idea, a lot of element ID or class may change in any time, eventually your hack becomes useless, then you need to push another silly patch for the name changes. And such changes are relatively easy to fix, sometimes, you need to intercept for timing. It is all nasty hacks, not worth doing it. To describe its worthiness if you must, one word: "fancy."

Take a look at Markdown code in the screenshot, whether you know about Markdown syntax or not, don't you agree Markdown code is fairly human-readable? So, one solution has already presented itself: simply writing an email in Markdown in plain text.

The only (and actual) problem remains is the variable-width font. Many webmail clients don't have options for fonts, which is the real problem.

I have fixed that issue with Pentadactyl, simple user style resolves the whole issue easily. You don't need an extension go through all sorts of problems and it may break anytime. Just change the font to fixed-width font. I have Gmail and Google Groups use fixed-width font, it's much easier to read about technical content. It's lightweight, no need for a big extension, inserting a CSS rule solves the problem.

In my honest opinion, rich formatting has never been good for writing emails just as if you try to write in word processor. You spend a lot of time on messing around the typesetting with nothing actually written. But mind you, by no means that I am saying you should avoid them, please don't misunderstand.

Many of emails looks like being painted by a 3-year-old. So are some blogs, have you ever seen a blog which has each post written with different fonts and text sizes? That's just horrible and they has more colors than a rainbow in single post.

People wants to write an attractive and/or professional looking email, catching your eyes whatever the word they want you to read twice, so they mark it bold, make it italic, highlight with red color, brush with white background. At this moment, nothing is going to stop them going further, font size goes up 2 scales, then one scale more, change font, draw a underline, prefix and append a smiley, align to center, make font size even bigger until they fill up the entire width. That's a hell of email, literally.

If you are saying some people just can't the important parts of your email, therefore you need to use rich formatting. Then, either you such at writing or that person is not a good reader when the email has 100 words. To be honest, how many times you have written emails longer than that?

Plain text is good enough to speak up your mind, learn to use *, _, indentation, and footnoting. That's enough to write a good and clear email, even for topics like coding. You don't even need to write in Markdown, just write an email as you usually do. Heck, just write an email as if you are writing a real-life letter if you still do.

One thing important to remember is email is a general communication tool. If you want to talk about code, that's fine, but you need to know the limitation, know when to stop, know when to move on to the right platform for continuation, such as an issue tracker. Pasting a whole code in email body for discussion only shows you don't know what you are doing, use the right tool.

Reading is as important as writing, and it's not hard, the only thing you need is time. Just sit down and read a word after another, that's it.

Reading a good-written email is like reading a good article, have you ever read a story on front page of newspaper with bold type, italic type, etc? Do they read unclear or confusing? A good writer doesn't need those to emphasize his or her points, the words already do. (Hench, I am not one)

Back to markdown-here, again, I don't want to take away his effort. So if you like coding or trying new stuff, go ahead to install it and help develop it. I am sure it's a good extension and if you get asked 'why,' you can answer 'because I can.'

If you agree with me, share your tips of writing emails; if not, feel free to express, I am looking forward to reading why my points are wrong.

I want to see the performance between with and without C extension. I downloaded the latest 2.1.3 version. And make three builds using Python 2.6.6:

1. rm -rf build ; python setup.py build && rm build/lib*/simplejson/_speedups.so
2. rm -rf build ; python setup.py build
3. rm -rf build ; CFLAGS="-march=core2 -O2 -pipe -fomit-frame-pointer" python setup.py build

The first one removes the compiled C extension, the second one is normal, then third one uses the current CFLAGS I use in emerge. And the following lines is how C extensions got compiled:

Without customized CFLAGS
x86_64-pc-linux-gnu-gcc -pthread -fPIC -I/usr/include/python2.6 -c simplejson/_speedups.c -o build/temp.linux-x86_64-2.6/simplejson/_speedups.o
x86_64-pc-linux-gnu-gcc -pthread -shared build/temp.linux-x86_64-2.6/simplejson/_speedups.o -L/usr/lib64 -lpython2.6 -o build/lib.linux-x86_64-2.6/simplejson/_speedups.so

With customized CFLAGS
x86_64-pc-linux-gnu-gcc -pthread -march=core2 -O2 -pipe -fomit-frame-pointer -fPIC -I/usr/include/python2.6 -c simplejson/_speedups.c -o build/temp.linux-x86_64-2.6/simplejson/_speedups.o
x86_64-pc-linux-gnu-gcc -pthread -shared -march=core2 -O2 -pipe -fomit-frame-pointer build/temp.linux-x86_64-2.6/simplejson/_speedups.o -L/usr/lib64 -lpython2.6 -o build/lib.linux-x86_64-2.6/

I use the following code to do the test,

import timeit
t = timeit.Timer('json.loads(json_str)', 'import simplejson as json;json_str=open("test.json","r").read()')
print t.timeit(100)

The test.json is http://googleblog.blogspot.com/feeds/posts/default?alt=json&max-results=500, over 3 MB, 500 entires.

The results is:

Tests	Elapsed time for 100 loads()
Without C extension	126.230s
json 1.9 in Python 2.6.6	060.616s
With C extension	009.945s
With C extension (CFLAGS)	007.555s

With C extension is at least 10 times faster. I also put the simplejson 1.9 which in Python 2.6.6 in the result. Without extension, 1.9 -> 2.1.3, twice more slower. I didnt download simplejson 1.9 to double check, but I dont think its modified for being shipped with Python.

Google announced the preview of upcoming Web Store and there is a few changes to the developer dashboard.

• You can now select up to 3 predefined categories and with some customized.

• The terribly extremely limited character length of 2,000 has been lifted to 16,000. But still no markup, you cant highlight or link your words to other place.

• You can select a verified site from your Google Webmaster Tools account, it will show users that this extension is published from the site you set instead of your developer display name.

  

• In preview, it shows the extension is free but nothing yet for normal page. Obviously, we can set a price when Web Store is ready.

  

Your extension now needs logo and at least one screenshot in order to publish, I have to create them for my silly extension.

Keep Last Two Tabs is my first Chrome Extension, I wrote this post because the Extension page is only allowed 2,000 characters in description.

This is a silly extension. Its made to prevent Chrome quits when you close last tab. But its not really work as you may expect. It keeps you Chrome has at least two tabs. Because intercepting last tab closing is not possible, therefore this is one possible way to get around.

The chart below is the weekly users of Keep Last Two Tabs, a Chrome Extension of mine. This extension does what it claims, its silly and amazingly to see the number of users is actually growing up.

A week ago, I stumbled upon Flot, a pure JavaScript plotting library for jQuery. It produces nice and pretty chart comparing to Google Visualization APIs Annotated Time Line, a Flash based. Here is a post about how I used it.

I feel Annotated Time Line is more easier (or less customizable) to use because you dont need some functions, but Flot is more comprehensive library (and its Open Source), you can have more types of chart and make the chart do whatever you want if you know JavaScript.