Today spent some time to customize Atom user stylesheet to display the background image for editor.
Background image is a feature that I expected so much in either TextMate or Sublime.
Now finally I have it in Atom.

Finding the class for each html component is a little bit tricky
My theme is seti-ui.

Stylesheet to display background image

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

//.react is needed to avoid impact on mini-editor
.editor.react {
  // Fix the color strip between gutter and the editing area.
  background: #0e1112;
  .scroll-view {
    // Align the Background Image with Editing Area
    padding-left: 0;
    margin-left: 10px;
    // I put the background image under ~/.atom/images
    background: url('/Users/timnew/.atom/images/batou.jpg') no-repeat fixed;
    // Stretch the image
    // I tried to set it in with other background properties,
    // but it doesn't work. Looks like a bug in Chrome.
    background-size: cover;
  }
  .cursor-line {
    // Set cursor-line semi-transparent to make background visible.
    // Adjust the alpha value to fit your taste.
    background: rgba(90,90,90,.4) !important;
  }
  .overlayer {
    // Set overlayer semi-transparent to make background visible.
    // Adjust the alpha value to fit your taste.
    background-color: rgba(21, 23, 24, .7) !important;
  }
}

Screenshots

Without TreeView

With TreeView

Atom is general purpose text editor brought to us by GitHub guys, which is empowered by the loved Node.js and Chrome.

Someone said Atom is just another clone of Sublime. Well, I don’t quite agree with the saying. I’d like to say Atom learnt a lot from Sublime.
And I’d like to explain why.

I think Sublime itself is a great text editor, powerful to use, easy to learn, ready to be hacked, matured community, tons of plug-ins… almost unlimited possibilities…

But on the other hand, I think, Sublime is too sticky to “Text”. Yes, it is a text editor, but it doesn’t mean everything in the editor could only be text-based.
Implementing custom UI in Sublime isn’t a easy job to do. Benefits from HTML based technologies, Atom has a lot more rich features, CSS3 effects, CSS3 Animations, SVG, and a lot more…

Along with Brackets, C9, Atom is the important candidates of next-gen editors. But among them, only Atom is a general purpose editor.

Since Atom is still in the eary stage, there are a number of flaws and issues in it. Besides these bugs, the biggest problem of Atom is performance.
Loading a several MB text file or thousands pages document will kill the editor in no time. (Atom blocks user to load file larger than 2MB.)

But still, these issues won’t block me from loving it. As a node.js and Ruby developer, it is an awesome companion to my work. ❤️

This post is a celebration for the migration from Octopress to Hexo

Octopress has done an excellent job on filling the gap between jekyll and full function repo based blog engine. But because of the tech stack it is based on. It isn’t really a awesome framework to use.

The first time I got pissed off by Octopress was by the end of 2012. Then I come up the idea to rewrite it in Node.js. But I wasn’t able to make it happen, because I was held by the new project assignment, and didn’t have too many spare time on the blog engine.

To save effort, I began to customize Octopress by rewriting some code in Octopress and Jekyll, which started the long march of Octopress customization.

I did a number of customization on Octopress, from erb template to Jekyll generators, from Rake script to TextMate bundles.

Before I switch to Sublime, I uses TextMate for quite long time. So I customized the Rake script and TextMate bundle, which enables me to invoke almost every rake command in TextMate with hotkey. I can even rename the blog post file name according to the title in front-matter without leaving TextMate. Besides the functionality, I also customized the templates and the widgets a lot to get better visual effects and reading experience.

I’ve benefited from these customization a lot. On the other hand, these deep customization blocks me from migrating to Hexo, a better alternative. Even I have found Hexo in the early 2013, and believe it is a better blog platform. But it is really costy for me to migrate the blogs away from the Octopress.

Luckily, after years development, a bunch of tools and libraries came up, which has minimized the gap between Octopress and Hexo.
After several days effort, finally retired the Octoress engine, and completed the journey of moving from Octopress to Hexo.

Today I found a super annoying issue about IE. Our website works perfectly in any browser except IE. The page isn’t rendered properly in IE 9. Well, this is common, this is the nature of IE. The mysterious issue I found is that once you opened or ever opened the developer tool, open the page or refresh the page, the problem is gone magically!!!!

As a conclusion, opening the developer tool changes the browser behavior!!!!! What a hell! So you know there is something wrong, but once you try to figure out the error message, you have to open developer tool. Once you open the developer tool, the bug is gone! DEAD END!!!

Because I cannot open developer tool, so I have to debug with alert. It is really a horrible experience to me, and feels like inspecting nuclear reaction with a plain optical magnifier or fixing a high-tech spacecraft with stones and clubs.

Since it is client-rich page, a lot of javascript is introduced. So I cannot go through the scripts line by line, instead I have to make an assumption to explain the phenomena spotted, then validate it with experiments, finally correct or extend the assumption according the validation result.

During the process I invalidated a couple of assumptions, some of them are seems very close to the “right answer”, such as “some script is loaded and executed before its dependencies, and developer tool load all the scripts first because it displays all the scripts”.

After spending a couple of hours on it, I put on eye on a line of code that is really out of my expectation: console.warn.

1
2
3

console.warn('__proto__ is not supported by current browser, fallback to hard-copy approach');

I displays a warning message to console when a workaround is applied. But a tricky fact about IE 9 is that console isn’t available until developer tool is opened (MSDN reference here))!!!

The fact that console is not available until developer tools is opened really blows my mind away! (Maybe it is because I have little experience work with IE). As a chrome user, I take console as the universal log system for javascript. But in IE, according to the document), the code should check the existence of console every time print a log.

There is another pitfall here, and I saw someone really post it as answer on StackOverflow:

1
2
3
4
5

if (typeof console == "undefined") {
    this.console = { log: function (msg) { alert(msg); } };
}

We usually access console as console.log, feels like console is a global instance to access. But actually console is an member of window, its full name should be window.console. When console exists, we can definitely reference to it via console. But if it doesn’t exist, the statement console cause script error! So the following code doesn’t work:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

if (typeof(console) === 'undefined'){ // Break the script execution
  console.log('Never got executed');
}
if (console != null) { // Break the script execution
  console.log('Never got executed');
}
if (console) { // Break the script execution
  console.log('Never got executed');
}
if (window.console) {
  console.log('this works!');
}

To avoid console issue, a ployfill could be very useful. Here is a great implementation available as bower package: console-polyfill