Why do most desktop blog editors suck?

• First, what are they truly good for:
  • You won't lose your content due to keyboard muscle-memory which differs between windows and mac users or because of hotkey mappings which often differ between browsers like Firefox and Safari. What am I talking about?
    • I'm talking about the tears I've shed when I tried to undo my last change via (ctrl+z or cmd+z) inside blogger/blogspot's web editor and it blew away ALL of my content! Was it safari, firefox, mac or windows conflicting key mappings that caused this? I don't know ... but its an evil concoction that I don't care for.
  • Worst of all is the mapping for the backspace key. It move you back to the previous page in your browser when you are editing your blog instead of simply deleting a character ... thus causing you to lose all your work!
  • Just having the comfort of knowing that your content won't be lost because of a dumb keystroke ... is just about the only thing that these desktop blog editors are good for.
• Onwards & upwards ... lets look at all the reasons desktop blog editor SUCK ... which pretty much boils down to the fact that you still have to manually edit HTML because the simplest usecases aren't automatically handled. What are these usecases? Images and embeds!
  • Is it really that hard for the desktop-blog-editor manufacturing industry (yes that is sarcasm) to grasp the fact that folks might want their images to float to the right or left and their content/text to simply flow around them? There's not a single tool that handles this via a WYSIWYG toolbar.
  • Embeds mean different things to different people. For a developer, it means embedding code-blocks (gists for example) which will have their own space and your own content would flow around and not clash/overlap with them.
  • Seriously, the desktop blog editors out there today (year 2013) are just a big disappointment :(

Inkscape - Some discoveries are only made on mac

For those who leave the comfortable realm of Windows behind and enter the rather strange and initially maddening world of the Mac, the only thing that can possibly hit harder than not being able to use the keys and shortcuts like before, has to be the glaring lack of some MSPaint like utility.

Well, you may quickly find solace by going out and downloading either Gimp or Inkscape.

My personal vote would lean heavily towards Inkspace because of the abundance of excellent resources and tutorials when it comes to getting started with this tool:

1. inkscape-class-day-1
2. inkscape-class-day-2
3. inkscape-class-day-3
4. inkscape-class-day-4

A lot of screencasts are available as well.

Afterwards to get your creativity flowing use the following two awesome tutorials to create some mac/iPhone icons of your own:

• http://cocoawithlove.com/2009/11/creating-iphone-and-mac-icons-using.html
• http://cocoawithlove.com/2009/11/creating-iphone-and-mac-icons-using_06.html

Wish List: Integrate openssl and/or keytool funtionality into Windows Right-Click context menu

Techies have it real good. So much that we need is already out there in the world and to top it all off there's Google so that we may find what we need! Yet, sometimes I come across problems that make me wonder: "Do we really have it all?"

I have had my fair share of banging my head bloody against the computer screen ... trying to re-learn keytool & openssl syntax, again! It takes 1 month to remind myself of all the caveats and for another month I enjoy expert status. Then the vicious cycle begins again where I don't need to use them and the 10 month hibernation strips away my facilities from me. That's my year right there .... happy new year? I think not!

So what's on my wish list?

1. Establish a 3 letter extension syntax to honor what's what for public/private keypair based security. It is far too loose today and makes the creation of tooling more challenging than it needs to be.
   1. Public/Private Keypairs: should at least end with pem or der
      • filename.pem
      • filename.der
   2. Certificate Signing Requests: should end with csr
      • filename.csr
   3. Keystores should clearly define their own format
      
      • filename.jks
2. Tools or widgets or plugins ... something should be available which makes life easier by allowing the user to right-click a file and take any valid action supported by openssl or keytool.

I don't want to make it seem like "the sky is falling" ... to be fair, it is not like the security space is completely without tooling. Some decent solutions exist that make key and certificate management simpler:

1. Portecle: is a user friendly GUI application for creating, managing and examining key stores, keys, certificates, certificate requests, certificate revocation lists and more.
   • Wrapping Portecle with Jar Bundler works well for mac. And if you need to run it as root, you can use "sudo open portecle.app" to launch it.
2. KeyStore Explorer: is a free GUI replacement for the Java command-line utilities keytool, jarsigner and jadtool. KeyStore Explorer presents their functionality, and more, via an intuitive graphical user interface

Hudson, Tomcat and cacerts

Setting up a secure connection for any application, doesn't really require too much effort in terms of the process involved. It is supposed to be simple. Yet one often gets stuck on the simplest of steps simply because there is no tool or no simple answer other than trial & error.

What if someone asks you to import the server certificate into your application server's truststore. Simple right? Well no! There never seems to be a simple and straightforward answer to the question: "Well, where exactly is the current truststore?"

Where is the cacerts being used by a Tomcat instance that runs Hudson?
Navigating to Hudson > Manage Hudson > System Information will enlighten you to two possibilities:
1) the value for java.home (C:\Program Files\Java\jre6) under the "System Properties" table is a starting point, and
2) the value for JAVA_HOME (C:\Program Files\Java\jdk1.6.X_XX) under the "Environment Variables" table is another.

But not knowing which one exactly can be a bit frustrating because you need to stop and start your Tomcat again and again until you get it right. One could just import the server certificate into the cacerts file under both these locations but then you will still not know which was the right one.

Well if you are starting Tomcat as a Windows Service then the answer is use the file at ${java.home}\lib\security\cacerts. Otherwise if you use the start/stop scripts then the ${JAVA_HOME}\jre\lib\security\cacerts is your best bet.