a t e v a n s . c o m

(╯°□°)╯︵ <ǝlqɐʇ/>

I've been trying to find a good WYSIWYG editor for simple CMS I'm building. My project just needs to make static pages - you know, /about, /faq, etc. The idea was that even if a developer had to write the HTML, anyone could go in and fix a typo or add a paragraph. My requirements for the html editor were pretty simple, I thought:

  • Produces mostly clean HTML (no <font>, <span style="ugly: yes;">, etc )
  • Forces Word, RTF, and HTML paste into plaintext, or at least something not horrible
  • Assigns classes for p, h1, hr, etc (or has hooks so I can add it in)
  • In-place editing mode
  • Minimal dependencies

Of course, you can't just use contentEditable directly. The Guardian has a great run-down of inconsistencies they found while building their back-end.

As has ever been the case, there are dozens of js libraries to do this sort of thing, and figuring out which ones are even worth investigating is a huge and draining process. Unfortunately my go-to for this sort of thing was out. Readactor is excellent, with a good API, good documentation, and readable code. But it's not free, and I want to release this as open-source.

  • TinyMCE - I got burned badly enough by this back in the PHP era
  • CKEditor - if anyone can show me a list of configuration options and their variations for this beast, I'll be impressed. A list of events I can hook into, and I'll be stunned. Some of the worst documentation I've ever dealt with. And look at the freakin' Rails plugin - better hope you use CanCan, Pundit, Mongoid, and want to slap in an extra controller.
  • WYMeditor - sounds interesting, but the mid-90's design isn't inspiring
  • Etch - backbone
  • Summernote - bootstrap
  • jQuery Text Editor - bare bones, and kinda crap docs
  • Hallo - links plugin isn't working. wut?
  • SmallEditor - angular
  • jQuery Notebook - can't even guess what requirements this will / won't need from reading the page and the docs - also needs font-awesome
  • Trumbowyg - wtf is with that name? "semantic" option is still in alpha
  • Morrigan - their demo page has scantly clad women! This must be a great editor! Yes, I played Dragon Age as well, but come on. Also v0.1-beta
  • Azexo Composer - drag and drop Bootstrap components, not quite what I wanted
  • Aloha Editor - beautiful page, but it really doesn't tell me a damn thing about how to use it, and their API docs are nil
  • Medium.js - no support for messing with classes or styles in the content
  • Scribe - not an editor, but a toolkit for building one. Built as AMD js modules, distributed via Bower, and everything is a plugin. Try building on this in a Rails engine, and you're gonna have a bad time.

The bottom line is that WYSIWYG editors for HTML are awful, and have been ever since Dreamweaver. I never thought about why it was an impossible concept until I read Nick Santos' article about Medium's editor.

Now I'm trying to figure out if I should accept an ugly, duct-taped-together interface for my CMS or just screw it and use Markdown.

Update

Got an email from the folks at Froala, which frankly looks pretty awesome. Good docs, html cleaning and class assignment. There is a distributable open-source version, so theoretically you could package it in to a project like this. But like Redactor, the "real thing" and un-minified source code are paid products.

WYSIWYG editors are hugely complicated, and this is one place I can totally justify paying for development tools and software. Compared to the time-sink black hole that is trying to roll your own, it's a steal.

Other post-checkout hooks try to auto-run migrations or bundling for you, but I feel like those are pretty error-prone. On the other hand, just getting notified is pretty helpful.

Copy + paste into project/.git/hooks/post-checkout

Very helpful. Difficulty not addressed: load testing in production.

Javascript is an interesting language. While Ruby has a style guide, and Python has a few (including Google's, they are not critical to how your code functions. They just help avoid those "strip whitespace" commits that touch every line in your repo and permanently ruin git blame.

With Javascript, the style is the substance. Take these two for example:

var object = {
    method: function(data){ ... },
    _variable: 3
};

object2 = {
    method: function(datae){ ... },
    _variable: 2
}

var Klass = function(){
    this.method = function(data){ ... };
    this.variable = 4;
    return this;
}

These seemingly small differences might not affect how a short script works, but they are critical to how your app works as a whole. The first declares a single object. The second declares a global variable. The third declares effectively a factory function.

Newlines can result in syntax errors for strings. Missing semicolons can ruin your JS after compression. Using reserved words as object keys can break your code in some browsers. Failing to use === can result in unexpected behavior.

It is essential to use a Javascript style guide. Frameworks like Express and Angular can help standardize things like object and module declarations, and CoffeeScript can provide syntax sugar to cover simple issues.

Otherwise, AirBnB's style guide is comprehensive and helps show best practices. Pick something, and stick with it, especially if you are working on a team.

This is funny XD

=>    hashrocket
<=>   spaceship
~>    twiddlewaka
->    stabby lambda

Some random things I built to help deal with timezones in Ruby / JS

Update: Extracted this into a gem (in beta): HappyTime

Finally! A way to get a truly, really random number in Ruby. Forget rand(), messings with seeds, etc. This gem uses the real thing - true randomness. Amazing.

String#remove_formatting , from the StringEx library. Gets rid of unicode griefer chars, html entities, basically any BS you can think of.

This function is THE BEST THE BEST THE BEST THE BEST THE BEST THE BEST THE BEST THE BEST THE BEST THE BEST THE BEST THE BEST

Fred Wilson:

What you might miss, and I missed until recently, is that Tweetstorming has some unique characteristics, which I outlined in my storm, that make it different and possibly better in some respects.

What you also might have missed: tweet storms are annoying as hell, in that they clog up the receiver's timeline with a bunch of stuff they may or may not care about, and as a bonus are difficult to read in sequence / context.

Get a tumblr. Post an essay. Post a link to essay on Twitter. I hate that "let's monopolize all my follower's timelines" is gaining legitimacy by giving it a name.

Creating a Bucket Policy:

You use the AWS Policy Generator to generate a Bucket Policy. There are several examples online and Amazon has a ton of examples.

Allow viewing & downloading of S3 objects directly via a browser. If, for example, you send attachments via email and also want to link to them on S3.

AWS is so full of its own jargon at this point - set an S3 bucket policy and ACL, but make sure you have the right IAM key, and also CORS doesn't conflict. And that's just for S3. Don't even look at Route 51.

Everything you know about Unix server administration has been reinvented on AWS with slightly different names and parameters, so none of the knowledge is transferrable outside of Amazon's infrastructure. Heavy lock-in. I don't like it.