St. on IT

The Lovely Future Of RightJS

2011-08-07T16:07:00.001+03:00

Okay, let's make it official, shall we?

Folks, I'm forking RightJS. And before you start screaming like "omg, we all gonna die in here!", calm down, RightJS ain't no going nowhere. The thing I do is future oriented and quite different from RightJS itself. So RightJS will stay where it is, I'm using all the same servers for the fork, so RightJS will be available as long as people use it. And I certainly will apply patches as much as I can.

Just, there will be no RightJS 3.0, RightJS 3.0 will be called lovely.io

So, What's That All Aboot?

Folks, it's not a secret, that monolithic frameworks are dead. Dead as Java. The future is in small, agile and modular libraries and this is where lovely.io starts.

In RightJS we already had kinda modular structure, you could go to the building page and switch off things that you don't need. The problem with this approach is that it is not suitable for the nova-days CDN hosting, all the permutations of a dozen options were blowing the 15k small library into a huge collection of files that weighted several hundreds megabytes and was almost uncacheable. You could host it by uself, but on CDN even if we host it, the chances that another user has the same configurations are slim and it would be pretty much the same as if you host it on your own domain.

Lovely.IO is not really a framework as you might think of a normal javascript framework. It is more like a CDN based package management system. In lovely.io all the RightJS core got split apart on several packages.

* 'core' - basically RigihtJS Class, Events (former Observer), utility functions + some new stuff
* 'dom' - the dom manipulations from RightJS + new jQuery like collections handler
* 'ajax' - new XHR2 based ajax module
* 'cookie' - the cookie module
* 'lang' - JavaScript core extensions
* 'sugar' - syntax sugar for the 'dom' module, things like "something".something() and so on.

Every package is pretty much independent and you can choose what you want. If all you want is 'dom' you just hook it up and it will be just that. If you also like some JavaScript core extensions, then you hook the 'lang' module. Need to do some ajax? Include the ajax module. It's completely up to you what load and what not.

A generic example would look like that

<html>
  <head>
    <script src="http://cdn.lovely.io/core.js"></script>
    <script type="text/javascript">
      Lovely(["dom", "ajax", "fx"], function($, ajax) {
        ajax.load("/some.url", {
          success: function() {
            $('#some-element').html(this.text).highlight();
          }
        });
      });
    </script>
  </head>
</html>

Basically wha happening in there is that you firstly include the lovely.io core package which just 3k of code and provides the modules handling. After that, you can specify the modules you need and once they're loaded (happens asynchronously) your callback function will be called where you can do whatever is it you need to do.

The example above is a bit simplistic. In reality it also automatically handles all internal dependencies, versions and so on. Check out this example, it's a little game, it uses 'dom' and 'cookies', but it also uses another packages like 'timer' and 'hiscore' to function.

This way we are going to have a rubygems like system where anyone can create and share modules, which can relay and reuse each other. All modules including the standard ones will be more or less equal and independent.

Automatic Packages Hosting

Another thing that I'm solving with lovely.io is automatic packages hosting. No more mangling with CDN, demos, documentation and so on. Once you create a package it will be automatically hosted at cdn.lovely.io which sits on Amazon's CloudFront. And it's not just scripts, all your asset images also will be there, automatically and free.

The basic idea is to completely eliminate the process of modules installation. All your package users will have to do is to specify the package name and version in the dependencies, all the reset will be automatically served from the super fast amazon hosting.

Check the mines game I mentioned above. Take a look into the HTML code of the page. It is fairly complex widget, it has some styles and depends on some images, more of that it is a compound widget, the hiscore block is provided by a completely different package. Yet all you have to do to make it working is this

<script type='text/javascript'>
  Lovely(["mines-game-1.0.1"], function(Game) {
    new Game().insertTo('#game-container');
  });
</script>

And it's not all. The micro-modular structure also will provide a big deal of caching optimization. As all the modules are hosted at the same CDN domain, they all will be cached one by one in the user browsers. And because of that the most frequently used packages will be always in cache.

Say a user opens up a page that uses packages A and B, then he goes to a page that uses A, B and C. All he really downloads on the second page is C.

About The Packages

The cool stuff is not over people. Concentrate, because there is more of awesome news!

The other thing is how you actually make the packages. By default there is no JavaScript. Yup, you've heard me. The actual packages code is written in CoffeeScript and SASS (though you can use JavaScript + CSS if you like). Check for example the source code of the mines game from the above. It is all nice and clean now.

How it works? Quite simple. Lovely.IO is not just a hosting. It also has a CLI tool called `lovely` which is much like ruby-on-rails thingy. You can create a project, you can launch a development server and so on.

Then you write your code in whatever you like, and once you're ready do share it with the public, the tool will compile everything in JavaScript, minify using Ugly and push to the lovely.io server. More of that it will automatically use your README and index.html files as landing and demo pages on the server.

You can structure your project as you like, you can have as many files as you like. You can use CoffeeScript or JavaScript, SASS or CSS, or even Stylus. It all doesn't matter for the end result.

Finally you can do the front-side development in a clean and civilized way.

Other Stuff

There is one thing among this awesomeness though. Lovely.IO is an HTML5 oriented thingy, there is no IE < 9 support, not like I couldn't, just it's thankless job to support those old browsers. I don't wanna do that, you don't wanna do that, and the guy next to you don't wanna do that either.

So, in lovely.io there will be no old IE browsers support in the standard packages, plus there is a good chance that I'll be nuking any other packages that will try to provide the old browsers support explicitly.

Basically, this is where I'd like to draw the line between RightJS and LovelyIO. If you need something well tested with old browsers support, use RightJS, it will be around as long as you want it. But, if you're building a modern HTML5/CSS3 application then you might want to consider LovelyIO, this is where all new stuff will go.

Current Status and Future Plans

At the moment Lovely.IO has all the modules from RightJS core + RubyOnRails support module + I've made a bunch of demo projects over here. It appears to be more or less stable (it's based on RightJS after all), but there is no UI yet.

There is also not much of documentation either. I've just opened the registration for early adopters. So if you wanna play with it, please check the main repository, this is where the STL packages live. It's mostly the good old RightJS with a bit of lean towards more standard jQuery behavior for the $ function.

The next step in the project will be automatic documentation hosting for the packages and then I'll start to port UI modules from RightJS, so if you want me to port something specific from RightJS UI, let me know I'll try to make it a priority.

--
Okay, I think that's the whole introduction for now. I'll give you more when I get to the documentation.

Calculating Cubic Bezier Function

2011-05-28T17:30:00.004+03:00

If you ever played with the CSS3 native css-transitions, you know that they use cubic-bezier notation to define the transition formula. Cubic Bezier is a parametric function that allows you to define all sorts of smooth curvatures that looks kinda like that

The reason why it's used instead of sinuses and exponents, is that it allows you to define all sorts of shapes with just a few more or less intuitively understandable parameters. Plus, unlike other mathematical functions it can be computed very fast, because it's a simple parametric function, no sequences no nothing.

In RightJS we support native css3 transitions, but it also has a pure JavaScript fx-engine to handle old browsers. And the thing is that native CSS3 transitions use the cubic-bezier functions, while the pure JavaScript engine uses a bit of mumbo-jumbo with Math.sin() and Math.log(), and what I wanted is to allow the developers to use cubic-bezier notation with the old engine.

The problem is that it's not that simple. The cubic-bezier function itself is pretty much straightforward and you can calculate a set of X and Y coordinates in no time, but it won't make you any good because both x-s and y-s will be related to the third t parameter and therefore unevenly distributed agains the t parameter. What you really need is a straight Y = B(x) function.

And here it gets tricky. That much tricky. But, luckily for us, there is always a better way to do it. All you need is to recall a bit of kindergarden math.

Originally, the cubic bezier function is used in a parametric form, but it also can be converted into a polynomial form, in which case it will look like that (you can google it and find say this document)

a = 3 P0
b = 3 P1
c = 3 P2
c0 = P0
c1 = b - a
c2 = a - 2b + c
c3 = P3 - P0 + b - c

B(t) = c0 + t(c1 + t(c2 + tc3))

In case of CSS3 cubic-bezier definitions, P0 is always 0 and P3 is always 1, in which case the formula gets even simpler

c3 = 3 * P1
c2 = 3 * (P2 - P1) - c3
c1 = 1 - c3 - c2

B(t) = t * (c1 + t * (c2 + t * c3))

Which, in case of of CSS3 x1,y1,x2,y2 parameters, can be written in javascript with two functions, for example this way

var Cx = 3 * x1;
var Bx = 3 * (x2 - x1) - Cx;
var Ax = 1 - Cx - Bx;

var Cy = 3 * y1;
var By = 3 * (y2 - y1) - Cy;
var Ay = 1 - Cy - By;

function bezier_x(t) {
  return t * (Cx + t * (Bx + t * Ax));
}

function bezier_y(t) {
  return t * (Cy + t * (By + t * Ay));
}

There are two reasons why we use the polynomial form of the equation. Firstly, it has less operations and therefore will work faster. Secondly, we are going to use Newton's method to approximate the values and will need a first derivative of one of the functions, which in case of polynomial functions is pretty simple.

Now, to the fun part. We converted the function from one form to another, but the question remains the same, how are we going to get the y = B(x) from x = B(t) and y = B(t)? Quite simple my friends, we will use the kindergarden math, or more exactly the Newton's method to approximate a parametric x value for every t value so that we could get an evenly distributed set of x values and then get a set of y for them using the same bezier_y(t) function.

Newton's method might look a bit scary for those who are not familiar with it, but it is actually very simple. Check this video the guy explains it nicely.

All you need to make it work is to have a derivative to your function, which in our case will look like that

function bezier_x_der(x) {
  return Cx + t * (2*Bx + t * 3*Ax);
}

And after that, we just define a little function that will make several iterations trying to find an x value which came from the current t value. We don't have to be very precise in our case, we just make 5 iterations tops and limit the precision by the 3 digits after the pointer.

function find_x_for(t) {
  var x = t, i = 0, z;

  while (i < 5) {
    z = bezier_x(x) - t;
    if (Math.abs(z) < 1e-3) break;

    x = x - z / bezier_x_der(x);
    i++;
  }
  
  return x;
}

Now you can create a loop and calculate a set of evenly distributed values, just like that:

var result = [];
for (var i=0; i < 1.001; i+=0.1) {
  result.push(bezier_y(find_x_for(i)));
}
console.log(result);

That's basically all of it. You can find the full version of this script in this gist.

Enjoy!

How To Read User Input With NodeJS

2011-05-08T18:29:00.002+03:00

I think it's time for me to join the NodeJS hysteria. So, I'd like to share a bit of things I was tackling today because there is not really much of docs on that matter right now.

Short things short. If you're writing a little console script in NodeJS that supposed to ask the user this and that, here's how you can get it done.

Node's global object process has two properties called .stdin and .stdout, which are essentially streams. You can write things into the stdout and listen to the 'data' event in the stdin stream. A simple example from the api-docs looks like that

process.stdin.resume();
process.stdin.setEncoding('utf8');

process.stdin.on('data', function (chunk) {
 process.stdout.write('data: ' + chunk);
});

You need to call that .resume() method first, it initializes the STDIN reading process.

It is pretty straightforward, but it's almost useless when you need to ask the user several questions, more of that validate the input data and re-ask questions when something was entered wrong.

The basic trouble here is that .on('data' handler that will fire every time the user hits the Enter, so you'll have to figure out which question is currently asked an where to put the data. Given the fact that everything is happening asynchronously, it pretty quickly gets really messy.

Fortunately for us, there is another events handler in NodeJS called .once(.. it's basically same as .on( but it detaches the listener after the first event received. Knowing that, we can write a little helper function like that

function ask(question, format, callback) {
 var stdin = process.stdin, stdout = process.stdout;

 stdin.resume();
 stdout.write(question + ": ");

 stdin.once('data', function(data) {
   data = data.toString().trim();

   if (format.test(data)) {
     callback(data);
   } else {
     stdout.write("It should match: "+ format +"\n");
     ask(question, format, callback);
   }
 });
}

There are two important moments. First of all, don't use console.log to ask the user the question, otherwise it will print a new line at the end, which is kinda sucks. Secondly note that you should call .toString() and .trim() on your data, the first one to convert the data from a stream into an actual string, the second one is needed because the string will have a trailing new line symbol at the end after the user hits the Enter key.

After that, you can ask the user all sorts of questions. For example like that

ask("Name", /.+/, function(name) {
  ask("Email", /^.+@.+$/, function(email) {
    console.log("Your name is: ", name);
    console.log("Your email is:", email);

    process.exit();
  });
});

And don't forget to call the process.exit() when you done, otherwise the script will just hung in there.

That's basically all of it. Enjoy!

Why Make A Run For It

2011-04-28T17:20:00.003+03:00

It has been almost two years since I decided to go public with RightJS and on this occasion I'd like to post some reflections on it.

Those days, thanks to github, it's pretty simple to start an open-source project. You just make a repo, write some awesome stuff and push it under the "I don't owe you shit" license. And I like it, in most cases that's all you really need. But, as fun as it is, there is actually another level to open-source projects. The level, where you decide to get serious about it and go public with your project. With promotions, users, official site, docs, tutorials and so on.

It is not completely necessary to make your project kinda "officially public", in many cases it might be even a bad idea, because that will distract you from the actual programming, but there are several important things in this process, which can be pretty valuable as well. And that's what I'd like to write about today.

It Will Make You A Better Programmer

The trouble with programmers is that we work in this area where most people don't really understand anything. And because of that, at some level, programmers tend to start thinking that they are pretty darn smart and kick ass.

A healthy portion of self-esteem is not a bad thing, it might help you to overcome some small obstacles on your way, but for a programmer as a knowledge worker it is crucial to stay hungry for new information.

And running your project for real, will give you exactly that. If you do something interesting enough, people will respond, they will throw all sorts of ideas at you, they will criticize and they will like (hopefully :)) some parts of your work, which will give you all sorts of new information.

With new information you'll face new problems and discover new ways to solve them, and that will make you better at what you do.

It Will Make You More Organized

It is not a secret that many developers don't like TDD and Tickets. Even the ones that do, often cheat and don't cover everything, don't document bugs and so on.

But, when you start an open project for real, you will have to deal with those things. You will have to handle tickets, document bugs and cover everything you can with tests so that folks who use your code had a hight quality experience.

More of that, most open-source projects, especially individual ones, are just about "scratching your own itch". It is highly doubtful that you will make any real money directly from your project, and as much as you might enjoy the creative process of writing code, at some point, you will have to get pragmatic about what you do.

You will need to start thinking strategically, where is it worth to invest your time and where it's not. And that is a highly valuable skill, not just for developing a software project, but genuinely in life.

It Will Make You Better With People

Well, you know what they say "all programmers are bad with people" :). The thing is, that people are irrational, even the smart ones. And there is only one way to learn how to deal with irrational - by accumulating experience.

One of the hazards of the trade is that programmers spend most of their time with computers, and that's certainly not a good thing for your social skills.

When you run an open-source project you will have to handle contributors and do that nicely. Because contributors are privilege. But as all people have different coding styles, different ways to approach issues and just different personalities, you will learn how to find common grounds with different folks, how to work together and how to coordinate the changes.

Conclusion

I don't want to sound like an open-source project is the most awesome thing that might happen to you. By the end of the day, if you're vicious bastard then all that will help you is an old-fashioned kick in the ass.

But, if you're interested in software-development, if you want to learn why and how the things done, running your own project for real might be very insightful and teach you quite a few things.

Making Tags With Rails And RightJS

2011-04-04T16:12:00.010+03:00

As the tags widget appeared recently on the RightJS UI list, I'd like to write a simple how-to about tags in case of using RubyOnRails.

You can see the tags widget in action on this demo page, and over here you can find a demo rails application that has the tags feature implemented, along with some other right-rails features.

Let's start

The Initial Model

When you need to add a tags feature in a ruby-on-rails project, a standard model would look kinda like that

class Article < ActiveRecord::Base
  has_and_belongs_to_many :tags, :uniq => true
end

class Tag < ActiveRecord::Base
  has_and_belongs_to_many :articles, :uniq => true

  validates_presence_of :name
  validates_uniqueness_of :name
end

As you can see, it's a pretty much straightforward m2m association, articles have many tags and tags have many articles.

Tags To Strings Conversion

The next standard step is usually to add a couple of methods to convert the list of tags into a coma separated string back and forth. The basic reason is that tags are data-base records and it's not much of user-friendly to use integer ids

class Article < ActiveRecord::Base
  has_and_belong_to_many :tags, :uniq => true

  def tags_string
    tags.map(&:name).join(', ')
  end

  def tags_string=(string)
    self.tags = string.split(',').map do |tag|
      unless tag.blank?
        Tag.find_or_create_by_name(tag.strip)
      end
    end.compact
  end
end

After that you can use this proxy property in forms directly, like that

<%= form_for @article do |f| %>
  <p>
    <%= f.label :tags_string %>
    <%= f.text_field :tags_string %>
  </p>
<% end %>

This way the user will always manipulate the tags list as a simple string and your app will automatically create the tag records and associations on fly

Hooking Up RightJS

At this point your rails app will present a kind of a standard and simple case of tags handling. Time to make it look nice and friendly with a bit of javascript.

To hook up RightJS into your Rails application all you need is just add the right-rails gem into your Gemfile

gem 'right-rails'

And run the following code generator

rails g right_rails

Don't worry when you see a tall list of scripts it copies into your public/javascripts directory, right-rails handles most of them automatically, so you won't really need to look inside of those.

Adding The Tags Widget

Ironically, the actual RightJS part of this enterprise is the shortest one. Once you added right-rails into your application, all you need to do is replace 'f.text_field' with 'f.tags_field' in your form

<%= form_for @article do |f| %>
  <p>
    <%= f.label :tags_string %>
    <%= f.tags_field :tags_string %>
  </p>
<% end %>

RightRails handles everything else automatically, it generates all necessary html, includes javascript/css modules, it even switches between minified and source builds of javascript libraries depending on the working environment.

More of that, it can automatically use the google hosted rightjs cdn-server for a superfast, shared scripts delivery.

Adding Autocompletion

By default the f.tags_field will make you a pretty looking tags-field, if you want to add the tags autocompletion feature to it, all you need is to specify a list of known tags in it

....
  <%= f.tags_field :tags_string, :tags => Tag.all.map(&:name) %>
....

There is also a few additional options you can use with tags widgets, you can find them at the rightjs.org documentation

Conclusion

This is a good example to show how RightJS is build with server-side developers in mind. As you have noticed we didn't write a single line of javascript in our little exercise, not like we couldn't, just we don't have to bother with those routine things every time we need a simple form with a bunch of standard widgets.

More of that, if you take a look into your HTML code, you'll see that RightRails didn't write a single line of script either, all it did is added the data-tags attribute to your input field.

<input data-tags="{tags: ['one','two','three'}" value="one, two"
  id="article_tags_string" name="article[tags_string]" />

This way, even if something will go wrong, the user will still see the standard input field with coma separated tags. All your styles and content will remain were it was.

--
Well, this is pretty much the whole story. If you're interested, go check the RightJS UI collection, it has many more useful widgets that you can use in your applications.

Why ==null, Not ===null

2011-03-24T15:38:00.016+02:00

Sometimes in RightJS source code you might see a thing like this

if (value == null) {
  // ...
}

And as every JavaScript optimization tutorial tells you to use '===null' instead of '==null' and JSLint yells at you when do otherwise, people immediately try to change it to the "right" way.

Meanwhile there is a pretty good case when it is much better to use '==null' than '===null'.

The thing is, that in JavaScript we have this ugly thing called 'undefined', which is quite clunky and often weird in use. Like say you might have a piece of code like that

var hash = {a: undefined};
console.log(hash.a); // -> undefined
console.log(hash.b); // -> undefined

console.log('a' in hash); // -> true
console.log('b' in hash); // -> false

Which is a bit strange. So, it is quite often, people use 'null' to predefine keys in hashes and then need to check whether a certain value is not 'null' or 'undefined', kinda like this

if (value !== null && value !== undefined) {
  // ...
}

Another case is that the 'null' thing is an object in JavaScript and sometimes you might need to check if a variable is a plain type value, you go with things like that

if (
  typeof(value) !== 'object' &&
  value !== null && value !== undefined
) {
  // ..
}

There are lots of cases where you need this double check. You also should keep in mind the fact that 'undefined' is a variable in JavaScript and someone actually can define a variable named 'undefined', and in general case you'll need to handle that too. Well, you get the ugly picture.

So, what about that '==null' business anyways?

The trick is that '==null', unlike other boolean comparisons (for example '==true'), returns 'true' only for 'null' and 'undefined' values.

null == null;      // -> true
null == undefined; // -> true

null == false;     // -> false
null == '';        // -> false
null == 0;         // -> false

Which basically means that you can use value == null instead of

value === null || value === unefined

More of that, except being more compact, 'value == null' also will be protected from 'undefined' replacements, and the browser also won't perform a variable name lookup, because null is a keyword and there is nothing besides it. Which will make the things faster.

How much faster? Let's see. I cranked this little script and run it in FF4

function test1() {
  var i=0, t = new Date(), v1 = null, v2 = undefined, r;
  for (; i < 100000; i++) {
    r = v1 === null && v1 === undefined;
    r = v2 === null && v2 === undefined;
  }
  console.log(new Date() - t);
}

function test2() {
  var i=0, t = new Date(), v1 = null, v2 = undefined, r;
  for (; i < 100000; i++) {
    r = v1 == null;
    r = v2 == null;
  }
  console.log(new Date() - t);
}

console.log('--');
10..times(test1);
console.log('--');
10..times(test2);

And here is the result

Well, that's the whole story. Think you can put it in a good use :)

Ruby + Gosu = Fun

2011-03-15T18:36:00.009+02:00

Gosu is a nice simple 2D games engine for Ruby, which I used to work on this little game called pentix.rb. And I'd like to put in some good words for the folks who maintain the project.

What's particularly cool about Gosu is that it doesn't try to jump over its head and do everything by themselves. Gosu is a very small framework specifically made for 2D games, it will help you make things like windows, handle graphics, fonts, sounds and some basic animations. But it also easily integrates with Chipmunk to handle physics and with ImageMagic/OpenGL modules if you need some seriously looking graphics.

If you think about it, Gosu is a very cool thing, you leave all the rendering and heavy stuff to the native modules and use Ruby for what it's good for, for describing logic, units, interactions and so on. And Gosu does it right, it doesn't force you to inherit it's classes all the time, quite on contrary actually. Gosu itself has just a few basic classes to handle media things, like fonts and images, and for the actual units you can write plain Ruby classes, which certainly makes it much easier to implement, test and maintain.

And one more thing. Gosu is not just a Ruby toy. It also has all the C++ bindings, which kinda makes it a pretty interesting choice. You can use the power of Ruby to prototype and do all the R&D things. And later, if you actually make it to the investors, it will be relatively simple for you to port everything to C++ and make it running anywhere. Yup, iPhone is on the list :)

This is basically it. If you ever wanted to write some simple 2D games, but didn't want to deal with C++ check out Gosu, it's pretty awesome!

UPD: Check out also this simple ruby tutorial they have

Super Simple Layout

2011-03-03T14:02:00.004+02:00

I'd like to show you a little css-trickery thing I use on pages where you have a super simple content, like a documentation or a demo page, and all you want is just to make it look kinda decent without bothering with additional HTML scaffolding.

Say you have the following HTML page

<html>
  <body>
    <h1>The Main Title</h1>
    
    <h2>Chapter Title</h2>
    <p>
      bla bla bla
    </p>
    .......
    <div id="footer">Copyright ...</div>
  </body>
</html>

It is super-simple, you've got an H1 for the page head title, you've got a bunch of H2 and P tags with the content and kind of a footer at the end.

And say, you want your page to have some sort of header/footer areas and a bit of paddings on the left and on there right.

Here is how you can do that with pure CSS, without bothering with additional tags

html, body {
  margin: 0;
  padding: 0;
}
html {
  padding-top: 8em;
  padding-bottom: 4em;
  background: gray; /* header and footer background */
}
body {
  padding: 1em 10em;
  padding-bottom: 5em;
  background: white; /* the main area background */
}
h1 {
  position: absolute;
  top: -.6em;
  font-size: 4em;
  color: white;
  margin: 0;
  padding: 0;
}
div#footer {
  position: absolute;
  bottom: 1.5em;
  color: white;
}

As you can see the trick is very simple, you use top and bottom paddings on the HTML tag to create the header and the footer, and left/right paddings on the BODY tag to create, well left and right paddings. After that just move the header and footer elements in their place with absolute positioning and you're done!

That's the whole trick. An example is over here
Enjoy!

If I Would Design A Simple Format

2011-02-18T12:41:00.007+02:00

There is an idea I wanted to spit out for quite a while now. It is about simple formats and to keep the short story short, here is a simple spec I cooked up.

Basically it is a mix of RDoc, Markdown and Maruku, plus some stuff I miss in all of them. The main goal in this one is readability mixed with abilities to handle everyday things, like images, tables, API references and stuff. HTML might be allowed as a fallback.

That's all, let me know what you think about it.


= Head 1
== Head 2
=== Head 3
==== Head 4

# Head 1
## Head 2
### Head 3
#### Head 4

= Head 1  #anchor1
## Head 2 #anchor2


*bold*
~italic~
_underline_
-strike through-
`type text`


http://some.url
</some.url>
<http://some.url>
<Some text:/some.url>

some@email.com
<some@email.com>
<Some email:some@email.com>


API Links

{ClassName#instanceMethod}
{ClassName.classMethod}

Defining a default scope
{-ClassName} after that
{#instanceMethod}
{.classMethod}


<img:/some.url>
<swf:/some.url>

<img:123x234:/some.url>
<swf:123x234:/some.url>

<img:Some title text:/some.url>
<swf:Some title text:/some.url>

<img:Some title text:123x234:/some.url>
<swf:Some title text:123x234:/some.url>


Code formatting


    Just a genuine piece of code
    That is pre formatted


Ruby piece of code

    :ruby
    this.is_a?(Ruby)
    code.which_we do
      paint in some do
        nice(colors)
      end
    end

Javascript code

    :javascript
    this.isA(JavaScript).code();
    that.we(Paint).accordingly();


> This is a quote text
> It will be converted to a block-quote
> > This is and internal quote
> > it will be nested into the original one


 * List item 1
 * List item 2

 - List item 1
 - List item 2


1. Num list item 1
2. Num list item 2


a. Letter list item 1
b. Letter list item 2


I.   Roman number list item 1
II.  Roman number list item 2
III. Roman number list item 3


 * Mixed list 1
 * Mixed list 2

   - Mixed List 3
   - Mixed List 4

    1. Mixed List 5
    2. Mixed List 6

      a. Mixed List 7
      b. Mixed List 8

        I. Mixed List 9
        II. Mixed List 10


Head | Head | Head
-----|------|-------------------
Cell | Cell | Cell
Cell | Cell | Cell
-----|------|-------------------
Foot | Foot | Foot


Head |     Head    | Head
     | Head | Head |
-----|------|------|------------
Cell | Cell | Cell | Cell
Cell |     Cell    | Cell
Cell | Cell | Cell | Cell
     | Cell | Cell |
-----|-------------|------------
Foot |     Foot    | Foot


Right | Left       | Center      |
----->|<-----------|------x------|
    1 | 1          |      1      |
   11 | 11         |     111     |
  111 | 111        |    11111    |
 1111 | 1111       |   1111111   |

RightJS 2.2 RC Public Test

2011-01-09T16:52:00.008+02:00

My dear fellas rightjslings (or whatever the hell we are) I've got some good news for our species! I took a bit of a break from RRTE those holidays and packed ourselves the next major update in the RightJS core, which will go by the number 2.2.0. And I would really like you to play with the thing. Bring some joy and magic in the routine, and start the year with the new shiny toys!

Awrighty, now to the business. You can download the thing from over here (NOTE: there are updates for all the plugins as well).

And as for the changes, there are quite a few of them actually, so let's get through them one by one

Native Fx Support

The first thing that RightJS 2.2 brings is the support of native css-transitions in the visual effects engine. There is not much of changes in the actual API, RightJS will automatically figure everything out and use native features when available.

Currently it runs on Safari, Chrome and FF4. Opera also supports them but I have disabled it for Opera by default, because first of all their thing is buggy (doesn't support say font-size and background-position) and secondly our own, javascript based engine works faster than their native feature :)

Anyhow, if you insist to switch it on in Opera or disable in Webkit/FF4, use the new engine option with your effects, it can be either 'javascript' or 'native'

Class and Wrapper merge

The second biggest change is that the Class and Wrapper units were merged to make an uniformed classes structure where the Class unit is the top parent of everything.

The new Wrapper construction won't work anymore, use the standard new Class calls as you do when you define any other class.

Supercalls On Modules

The other outcome of the Class unit update is that now you can call the $super method not only on inherited classes but with injected modules as well. It kinda looks like that


var Klass = new Class({
  method: function() {
    return "original";
  }
});

Klass.include({
  method: function() {
    return this.$super() + "+module1";
  }
});

Klass.include({
  method: function() {
    return this.$super() + "+module2";
  }
});

new Klass().method(); // -> "original+module1+module2"

This comes very handy when you need to overload some certain methods without using the actual inheritance. Before, we used to use all sorts of old_method hacks, now it's all nice and civilized.

Builtin Mouseenter/Mouseleave Handling

RightJS 2.2 will come with built in mouseenter/mouseleave events handler. As usual it all handled automagically, just use the 'mouseenter' and 'mouseleave' event names and be happy. Works both ways, directly with elements and via UJS.


$('element').onMouseenter('addClass', 'hovered');
$('element').on('mouseleave', 'removeClass', 'hovered');

"div.something".onMouseenter('addClass', 'hovered');

Better UJS

Another major update is that now UJS handlers got triggered by nested elements as well, just like with the normal dom-events. Basically it means that if you say have a structure like that


<div class="something">
   Some text in here
  <div>some inner element</div>
</div>

If you attach your UJS listener like that


"div.something".onClick('toggleClass', 'clicked');

Then it will get triggered no matter if the user has clicked the div.something element itself or any of its internal elements. No more hacking this stuff around.

Pretty Collections Handling

And one more sweet thing the RightJS 2.2 release will bring. I know you all love the String#on method to handle the UJS features, so I had extended it a bit further. Now you can run basically any Element methods from strings, just like that.


"div.something".addClass('red');
"div.something".removeClass('red');
"div.important".highlight();
"div#some-crap".remove('fade');
....

Those basically shortcuts for $$(css_rule).each('method', args); it finds all the elements matching the rule and calls the method on them.

----

There are more fancy things in there, like various performance optimizations, IE8 was kicked out in the olds module, all CSS3 selectors now work everywhere, and so one and so one. I'll describe everything with the actual release.

For now you just have fun with the new sweet features and come back if you have any troubles.

RRTE Public Alpha

2010-12-22T19:47:00.003+02:00

Hey people, sorry for being quiet recently, been busy with work and stuff. I don't have a pretty picture for you today, but Santa didn't come up giftless today, not at all :)

I've got a cute little link for you!

I just pushed RRTE alpha to github, so you could have a sneak pick on what's going on.

It's still an alpha, it doesn't work under IE yet and you might stumble upon some bugs here and there, but generally, generally it all shapes up and should give you some basic overview of the thing.

Anyhow, you know the drill. Checkout, enjoy and come back with feedback! :)

RRTE Status Update

2010-12-01T18:38:00.005+02:00

Hey folks! It's been couple of weeks and some of you started to wonder, where's Nik with his RRTE and the world domination, so here is the status update.

As you can see, we are having some serious progress. Most of the things you see on the picture are already working, but I'm trying to explore some possibilities and features.

What's Wrong With the World?

It seems that the design-mode support in browsers is utterly broken. It's ugly, limited, uncomfortable to use and behaves differently in different browsers. Well, just like the whole JavaScript business :)

There is basically two modes how the design-mode works in browsers, the tags mode and the css-mode, in the first one the browser tries to use tags to style the content, in the other one it tries to use styles. The trouble is that IE supports the tags-mode only and FF supports both, but in any case both of them do that wrong.

You see, in the tag mode say they use obsolete FONT tag to style fonts, but in this case FF doesn't support for example proper selections highlighting, they also for example use STRIKE instead of S tag and there is no way specify it. In the css-mode, the browsers try to use things like style="font-weight:bold" instead of the <B> tag pair, which is quite inflexible if not to say idiotic in terms of CSS. It also incorrectly reacts on all sorts of things, like say it will show the U tool "on" when you put your cursor on a link, and you won't be able to switch it off because it's styled with css.

And so one and so one. There is are lots of small and big fuckups like that, and honestly it is quite a mess.

Time To Fix It!

Being an arrogant idiot, I couldn't just pass by this mess, so now I'm building my own engine, which will do precisely what we need on any browser. Basically there are two sets of tools, one of them allows you to work with the style attribute, the other one allows you to format anything with any tag you want, and, what's more important, with any attribute you need, which means that you can use ids and classes as well.

The formatting setting is not limited to the H1-H6, PRE and ADDRESS tags anymore. You can easily specify say things like that

Rte.Formats = {
  'h2': "Header 2",
  'tt': "Typetext",
  'blockquote': "Block quote",
  'div.blue':   "Blue block",
  'div.green':  "Green block"
};

Etc, etc. The basic plan is to create some sort of a mixed, truly css-oriented mode. We will use SPAN + style attribute for things like custom colors and fonts, but for everything else use normal tags and classes, so that the editor produced a nice and easy to process and support content.

It's a bit tricky, but we will get through it.

Advanced Tools

The other thing which I'm trying to figure out is how small an RTE can be, or how much features can we squeeze in 10k? Advanced OOP features of RightJS are really helpful in this case, because all the inheritance and functionality injection features allow us to create really compact and flexible code. As you can see I already added the color tools, font name and size tools, formatting options and some other things. At the moment all of that weights about 8k of gzipped code (and that includes all the css).

So I'm trying to add more features in the standard package than I originally planed and see where it will lead us. We might drop some of them into the extensions pack later on, or, if everything will go smoothly, we might not need one and all the standard functionality will be available in the basic build, so that we will have just a core and plugins. Or something like that. Will see.

--
Well, this is basically it for the moment.
To be continued...

RightJS RTE Concept

2010-11-12T18:45:00.009+02:00

In case you were wondering why it was quiet around here for last couple of weeks, I'd like to share some stuff I've been secretly working on and what are the future plans.

Basically we are taking a little pause until Mozilla guys sort their stuff out and release FF4 or at least 3.7, which we need to execute our evil plan for RightJS 2.2.

Meanwhile I've been working on this puppy

Yup, it's a RightJS based RTE that will most definitely take over the world, and so you started to want it for xmas, I'd like to put some words in about what's what and stuff.

Meet RRTE The Frameless

One of the major differences from usual RTEs is that our RTE (which goes under the codename RRTE) does not use any frakking frames. Instead, it uses an inlined DIV with contenteditable="true" property.

If now you're wondering what it gives you, then this is what:

Because it's an inlined div, all the content inside of it will follow all the styles on the page, which means no more headache with transferring and applying your styles to some iframe. If you take a look at the picture, you'll see that the header text inside of the editor has exactly the same font and size as the header on the main page. The blockquote and pre tags are also painted through usual CSS right on the page.

Secondly, because it's just a small inlined piece of page, RRTE works and feels much faster than any IFRAME based editors. It is super fast, practically it feels almost like a plain textarea element.

Thirdly, because all widgets in RightJS UI are plain elements, you will be allowed to easily access and manipulate any content right inside of the editor via standard API.

Modular

The second most important feature of RRTE is that it will be modular. Unlike all the other heavy duty RTEs, our RTE, by default will be mainly social networks oriented. It's main purpose will be to work as a lightweight embeddable RTE for all sorts of things like comments and blog posts where you already have all styles in place and just need some nice and shiny thing instead of textareas.

For this reason the default package will contain the main core/engine and provide basic editing tools which you can see on the picture above. Currently it weights just 4k of gzipped code (including stylesheets) and my intention is to keep it under 10k size.

And for all the advanced functionality, like file-pickers, fonts, tables, etc. we will have a separated package, which will turn the editor in a normal heavy duty RTE.

Extendable

As you can see, my plan for RRTE is to extend it via plugins. I don't have any intention to implement everything in it, instead of that RRTE will have a proper OOP design in best RightJS traditions, so that you could make your own tools and extensions, using classes and inheritance. In case if you're wondering how it's gonna look like, here is an example how the Save button is implemented


Rte.Tool.Save = new Class(Rte.Tool, {
  shortcut: 'S',

  initialize: function(rte) {
    this.$super(rte);
    if (!rte.textarea.form()) {
      this.disable();
    }
  },

  exec: function() {
    if (!this.disabled) {
      this.rte.textarea.form().submit();
    }
  }
});

RRTE will provide you with basic tools and open API, so I expect it to be pretty civilized and easy to extend.

What and When

Currently I keep all the fun for myself. This thing is not on github yet, basically because I hack and refactor it alot. Some parts are still quite flimsy and as I don't want you to have a wrong impression about it I'm going to keep it locally for the next week or two.

At the moment it appears to me that I'm done on about 40-50%, but as I'm a bit busy those days it is hard to estimate the exact schedule. Judging by my guts I should push something worth of seeing on github in about couple of weeks and probably will have the first release by the end of November/beginning of December.

This is basically it. Enjoy the news!

--
Oh, and one more thing. I could use some help with a default iconset for this widget. Currently I use some free stuff that I found over the internet, but if you can and willing to draw some particularly cool uber-iconset, that would be much appreciated!

RightJS 2.2 Notes

2010-10-25T18:32:00.009+03:00

I'm cooking a new evil plan for RightJS 2.2 release and would like to share some thoughts and notes, so you knew what's going on and where are we heading.

Native Fx

We are living in an interesting moment. Native CSS transitions are finally becoming reality. Safari does it, Chrome does it, Opera does it, FF4 does it (they promised they will include the feature into the 3.7 release). IE9b does not. Rumors has it, the feature will be in the final release, but I have my doubts it will happen.

Anyways, now, when the majority of sane browsers support the feature, I think it's the right time to start using native CSS transitions as a default option for our dom-morph effects. It is faster, simpler and more reliable.

Better UJS

The current implementation of UJS in RightJS works with an event target property only. The trouble with this solution is that when you have something like

<div id="one">first
  <div id="two">second
    <div id="three">third</div>
  </div>
</div>

and you attach an event listener to say the top one

"div#one".onClick(function() {
  ...
});

it will reacts only if the user clicks on the div#one itself and will successfully ignoring clicks on the inner element. Sometimes that's what you need, but in majority of the cases it creates more confusion than helping.

I'm still thinking about this one, but there is a good chance that the logic will be changed and our UJS will mimic the normal event listeners behavior and react on inner elements as well.

Hey! You will be able to make UJS stuff within UJS stuff! :)

Cookie plugin

At the beginning it seemed like a good idea to have a basic Cookie wrapper out of the box, but later I realized that on majority of my projects I don't use it. Well I assume you have pretty much the same experience.

So I think the cookie module will be kicked out of the core into an officially supported plugin. it's not much, just half a KB of gzipped code, but I guess we can fill this half a K with something more useful in everyday life.

IE8 And Pals

IE8, or as it known in some circles "IE7 on steroids" is kinda of troubling browser. The problem is that on a good half of the pages this darn things automatically falls into IE7 mode and therefore downloads the "olds" module, on the other half, it still has some troubles with native css selectors because some of CSS3 constructions are not supported, which consequentially makes some wonder-people to wonder how "right" right.js exactly is?

Furthermore the change/submit events still don't bubble and we carry quite large chunk of code in the core, to work this thing around.

So I was having that wild thought in my head, that we could ditch IE8 and pals support into the olds module so we could fix those things in there and not bother the core.

Currently, I'm considering the idea of making the line between the old and new browsers right where the CSS transitions support starts, which will effectively drop the whole IE support into the olds module.

That probably will make some jquery folks to moan that we are unfair towards them, but I'm looking into my glass ball and it says that after all the cutting and stitching, RightJS core size could drop below 12k.

Well, at least that the target. Besides there is still a tiny chance that IE9 folks will hear the voice of sanity and add css-transitions into it, then this distinction will be perfectly justified.

---

Anyhow, those are the notes and thoughts. Let me know if you have something on your mind about that

Cloned SELECT elements in IE

2010-10-14T17:42:00.008+03:00

What I love about IE browsers is that genuine feeling of moral superiority that you unavoidable accumulate inside yourself when you're dealing with its features. Found one more "treasure" that killed half of my day.

The story goes like that. Say I have a SELECT element and then you clone it a bunch of times and populate with new content, kinda like that

var original = document.createElement('select');
clone = original.cloneNode(false);
document.body.appendChild(clone);

$(clone).html('<option>boo hoo!</option>');

And that all works fine, but now say you update the content in another function, say an ajax callback or something

var original = document.createElement('select');
clone = original.cloneNode(false);
document.body.appendChild(clone);

setTimeout(function() {
  $(clone).html('<option>boo hoo!</option>');
}, 0);

You would expect that this is no different from the first example and here is where they will get ya. Not only it does not update the options list (it will be empty), but it also somehow manages to show you that the innerHTML property was actually updated and contains all the new data.


// .....

setTimeout(function() {
  $(clone).html('<option>boo hoo!</option>');
  alert(clone.innerHTML); // -> '<option>boo hoo!</option>'
}, 0);

All versions affected 6,7 and 8 (didn't test in 9 though)

In case you really really need to update a cloned SELECT element in an async callback, here is a hack how you can do that


// ....
setTimeout(function() {
  $(clone).html('<option>boo hoo!</option>');

  var dummy = document.createElement('option');
  dummy.text = 'dummy'; // DON'T use innerHTML in here!
  clone.add(dummy);
  clone.removeChild(dummy);
}, 0);

It will fix the problem, but you'll need to add some checks in there to ensure it's actually IE you're dealing with.

That's the whole gotcha. Hope will save someone's day

Making Pretty CLI Applications In Ruby

2010-10-02T18:46:00.007+03:00

Sometimes we need to process large amount of data in Ruby, convert things from one format to another, process a large database, etc. And when you start implementing those things as rake tasks or something like that you need some feedback, say to see the progress and so one. Normally people would use puts

index = 0
count = things.size
things.each do |thing|
  do_something_about thing

  puts "#{index +=1} of #{count}"
end

But when you have several thousands or millions things to process this approach doesn't work, because it will just blow into the console, which is ugly and well... there are ways to do it much better, prettier and more professionally looking.

There are gems and libs that will help you to do it properly, but in this article I'd like to show how it actually works internally.

Strings Rewriting

One of the first things you might want to learn in order to make seriously looking CLI app is how to rewrite strings all over. It is a bit tricky in Ruby so here how it looks like. First of all you need to learn the "\r" symbol, which is called "caret return" and well it returns the caret. A simple example will demonstrate. Say you have a line of code like that

puts "one\ranother"

when you run it, you will see in the console a string like "another" and what's happening is that ruby will print "one" then return the caret and print "another" over it, so that you see the last one only. But the trouble is that if you'll write something like that

puts "one"
puts "\ranother"

It won't work and you'll see two strings in the console "one" and "another", and because of that if you'll put into your loop something like that

puts "\r#{index += 1} of #{count}"

it won't work either and you will see the same ugly roll of strings. To make it working you have to use the a combination of the print and STDOUT.flush calls, kida like that

8.times do |i|
  print "\r#{i}"
  STDOUT.flush
  sleep 0.1
end

In this case it will print a string and stay on it. STDOUT.flush dumps the current stdout into the console, and on the next iteration, it will normally go to the beginning of the string and write it over as you needed.

But it is still not everything. If you run a piece of code like this one

%w{looooong short}.each do |str|
  print "\r#{str}"
  STDOUT.flush
  sleep 0.5
end

You will see that on the second iteration, the previous line won't be entirely overwritten and instead of "short" you will see "shortong", to make it work properly you need to write a long enough string that contains spaces at the end, for example

%w{looooong short}.each do |str|
  print "\r#{str.ljust(80)}"
  STDOUT.flush
  sleep 0.5
end

String#ljust makes a string of the given length by filling the remaining places with spaces. This way you will always overwrite 80 symbols of the line in the console.

To wrap it up nicely you might create a simple function and your loop will look like that

def print_r(text, size=80)
  print "\r#{text.ljust(size)}"
  STDOUT.flush
end

index = 0
count = things.size
things.each do |thing|
  do_something_about thing

  print_r "#{index +=1} of #{count}"
end
puts "\n" # <- a final new line

Displaying the progress

With the trick above you will be able to show a constantly updating status line, but there are still some meat on this bone. Showing the user things like "345 of 87654" is not particularly user friendly, because it might be a bit annoying to calculate the actual progress in your head all the time. Would be nice to show the progress in percents as well. Happily it is very simple to do using placeholders

print_r(
  "%d of %d (%d%%)" %
  [index+=1, count, (index.to_f/count * 100)]
)

The other usual problem with status reports is that you might have particularly large set of things, say several millions of them and your script might process several thousands of them per second. In this case hitting your console several thousands times per second will seriously slow the process down, so you might need a way to skip some steps and print reports in some periods of time. You can do that the following way

index = 0
count = things.size
step   = count / 1000 # 1/10th of a percent

things.each do |thing|
  if (index += 1) % step == 0
    print_r "....."
  end
end

As you can see we defined the step variable and then skip all the non-round iterations. In this particular case it will make the script to update the report every 1/10th of a percent of the job done. Which is in most cases is not a big drawback and still provides the user with progress updates.

You also might think of ETA calculations, but you probably can figure it out on your own now, it's very simple.

Add Some Colors

And the last thing I'd like to show is how to make colors in the console, which might make your application look even cooler. Some developers already know how to do that, but some don't. So here it is.

Basically it is very simple and in some ways similar to HTML tags. You use things called escape sequences which are just some markers like tags, you have an opening one, and you have a closing one, like that

puts "\e[32mGREEN TEXT\e[0m"
puts "\e[31mRED TEXT\e[0m"
puts "\e[36mBLUE TEXT\e[0m"

As you can see, the closing sequence is always the same and the opening one differs only by a number, and this number is basically describes the properties of the following text. It might be a color, or a blinking effect, you can nest them just like normal HTML tags and so one. You can find full list of options on wikipedia

The only trouble with those things is that the format of escape sequences differs from a platform to platform. The example above is for OSX terminal. How to make those things working in DOS and Linux you can find that on the same wikipedia page.

This is about it. Now go and make the world prettier!

Easy Way Out of The STI Hell

2010-09-23T15:47:00.008+03:00

I like the idea of STI (single table inheritance), it is cheap, dodgy but it works and allows you to play with all sorts of sub-types in a civilized way. For example you can redefine things in subclasses, use strategies and so one.

But when you try STI with Rails, you immediately fall into the polymorphic routes hell. Because you have new types, Rails tries to find routes for them, and it doesn't want to use the base model as a fallback. And here, people start to do all kinds of things (I did), define controller level helpers, generators, modules and so one. But then, someone adds a new custom method or a new subtype and it all falls down like a house of cards.

Well, you know what they say, the exit from a hell lays at the very bottom of it. And in Rails it will be routes. Say I want to handle all sorts of User model subclasses, like User::Admin, User::Manager, User::Blocked.

Trololo::Application.routes.draw do
  # here I collect all the User subtypes
  user_types = Dir["#{Rails.root}/app/models/user/*.rb"].map do |name|
    "user_" + File.basename(name).gsub('.rb', '').pluralize
  end

  # and then I put all of them one by one
  (['users'] + user_types).each do |name|
    resources name, :controller => 'users', :path => '/users' do
      member do
        get 'stats'
      end

      resources :comments # we can define nested resources too
    end
  end
end

I use the Rails 3 notation in this case, but I suppose you can figure how to make it work under Rails 2 as well.

It is still a bit dodgy, but it is better and more stable than defining those type-specific routes manually in controllers, you also can automatically handle all the nested routes as well.

That's it, hope that will help

RightJS 2 jQuerysh Plugin

2010-09-09T15:44:00.005+03:00

Hey folks. I had couple of minutes of free time and cooked a fancy plugin for RightJS 2.

It's called 'jQuerysh' and provides the jquery-like behavior for the $() function. You can copypast or build it from over here jquerysh on github

Basically it does three things with the $() function. You can navigate in jquery-style

$('#element-id').onClick('addClass', 'marked');

$('div.class').each('addClass', 'marked');

And you can call the onReady via it, same way as in jQuery

$(function() {
  // will be executed when on ready
});

This is pretty much it, might be useful for people who need to work with both jQuery and RightJS.

And yes, it works with RightJS 2 only. Not like I want to make you switch to RJS2 (which I actually want), RJS1 is simply not built for that.

Cheers

RightJS 1 Chrome Issues

2010-09-09T08:30:00.006+03:00

As much as I like to think about webkit as the world's savior, it constantly produces all sorts of weird stuff in Google Chrome, the last update of which had killed some important feature in RightJS 1 (do those folks even think before they make such changes? because I guess it won't be a problem of RightJS only)

In any case, the shorts and longs of the story is that they screwed the Element#hidden() method, which broke down several UI units, Autocompleter, Calendar, Lightbox, Selectable and Tooltips.

I've published a package for you over here RightJS 1 UI Fixes. It has patched builds of all those widgets, plus a fresh RightJS 1 build with backports from RightJS 2.

If this core-build will cause you troubles, you can patch your own by a simple line of code like that

Element.insert({
  visible: function() {
    return this.getStyle('display') !== 'none';
  }
});

And don't use the Element#hidden() method in your code, use Element#visible() instead.

Also think about moving to RightJS2, it works with wrappers and therefore doesn't have such issues by design.

RightJS 2 Release Plan Updates

2010-08-27T18:27:00.003+03:00

My dear fellas, this lovely Friday's evening I'd like to share with you some updates on the RightJS 2.0 release plan. And yes, by "updates" I mean delays.

No need for dirty swears, because there are two good reasons for that. 1) Rails 3 which should come out any moment now, and 2) upcoming IE 9 beta which is scheduled to September 15th. And as we all know well those funny MS folks, I think you'll agree that it's better to wait couple of weeks rather than pull your hair off later.

And it's not all that bad, there are good news too. I'm almost finished porting the UI modules to RJS 2, which means there well be the RC2 release in about couple of days I think. RC2 will include the core with all the latest updates and all the plugins and widgets ported to the new system. Generally this will be the final version and unless someone find a bug it will go to the actual release as is.

You'll have couple of weeks to play with it until the IE 9 release, and I'll have couple of weeks to brush up the docs, update rightjs.org and rework right-rails. Thinks that should give as a good runaway for a nice and smooth release.

This is about it. Take care!

RightJS UI 2 The Battle Plan

2010-08-17T10:20:00.003+03:00

Hello people. As I'm currently elbow deep in porting rightjs-ui modules to RightJS 2, I'd like to share some ideas and thoughts behind the changes so you knew what to expect.

RightJS 2 With New UI System

First of all the RightJS 2 release will be not just the core release, there are lots of cool new features and some dramatic changes, so I'm porting all the plugins and ui widgets to the new development approach, and with the RightJS 2 release I'll release updates for all the plugins as well.

This way we will have some sort of a clean slate, and you'll be able to start with all new tools right away.

Widgets === Elements

One of the biggest change in RightJS 2 is those really cool object-oriented dom-wrappers feature, and in the RightJS UI 2 we will take full advantage of it. If in the current system all the widgets are classes with some limited interface, in RightJS UI 2, all the widgets will be inherited from the dom-wrappers, so you will be able to manipulate with them as if they were normal elements.

// say you have a calendar unit
var calendar = new Calendar({
  // some options
});

// now you can do anything you want as if it was a normal Element
calendar.insertTo('my-element', 'top');
calendar.addClass('my-calendar');
calendar.set('id', 'my-calendar-id');
calendar.onChange(function() {
  // do something about it
});

// you also will be able to access it through the standard navigation methods
$('my-calendar-id'); // -> the 'calendar'
$('my-element').first('div.my-calendar'); // -> the same calendar

// it will be also follow the general inheritance structure
calendar instanceof Calendar; // -> true
calendar instanceof Element;  // -> true

You've got the picture, everything you can do with any element on the page you will be able to do with the widgets and do that directly.

Unified Initialization

RightJS UI were growing a bit chaotically during the last year and we have some diverse ways to initialize units. With the new release all of them will work via the same initialization process with the same principles. The rel hacks are gone, instead of that we will use the HTML5 data-widget-name attributes.

<input data-autocompleter="{url: '/some.url'}" />

<input data-calendar="{format: 'US', hideOnClick: true}" />

Meta-framework and Modularity

In current incarnation all the RightJS UI widgets are pretty much independent, which means that we have some duplications here and there, same things work slightly different, not really clean styles and so one.

It's time to refactor the mess, with RightJS UI 2 there will be a meta framework which will provide common bits of elements and styles, like say buttons, panels, spinners, various common functionality and so one. This way we will have a consistent elements behavior over the widgets, plus it will be easier to create new widgets with the common blocks of code already existing.

Unified Stylesheets

The stylesheets also will be cleaned up and unified. There will be common classes for buttons, panels, spinners and so one. One of the reasons is that now we will be able to create skins in a civilized way.

There will be no actual skins with the release, we simply do the preparation work, but the skins constructor is one of the first things to do right after the release.

Summary

As you can see with RightJS 2 release we will bring to the next level not just the core, but the ui modules as well.

I've already ported the Autocompleter and Calendar widgets, you can check it out at the 2.0.0 branch on github. I estimate it will take about a week to port the rest of them to RightJS 2.

After that there will be RC2 release where I'll publish RightJS core and all the modules for tests. And in about a week after that (by the end of August) we shall release.

This is about it.

And btw, if you have thoughts about new features for some of the existing rightjs-ui widgets, that's a really good moment to let me know.

Now that's it.
Take care!

DOM-Wrappers In RightJS 2

2010-08-07T14:21:00.003+03:00

Put your tin-foil hats on people, because it's your next brainwashing session about upcoming RightJS 2.

When you heard that RightJS 2 is going to have dom-wrappers instead of direct dom-units access you might think "oh, that's not a big deal, jQuery has dom-wrappers from the very beginning!". And you will be dead wrong! I already touched it a bit in one of my previous articles, now let me show this beauty in details.

DOM-Wrappers == Classes

First of all, dom-wrappers in RightJS are not just a bunch of functions behind a namespace, dom-wrappers in RightJS essentially are normal classes, with inheritance and functionality-injection support. For example you have the basic class Element and two subclasses Form and Input, which means you can say normally call instanceof on them.

$('div') instanceof Element;   // true
$('div') instanceof Input;     // false
$('div') instanceof Form;      // false

$('form') instanceof Element;  // true
$('form') instanceof Input;    // false
$('form') instanceof Form;     // true

$('input') instanceof Element; // true
$('input') instanceof Input;   // true
$('input') instanceof Form;    // false

You also can extend them separately and all the methods will follow the inheritance structure principles

Element.include({
  global_method: function() {
    // this method will appear on all elements
  }
});

Input.include({
  inputs_only: function() {
    // this method will appear on Input elements only
  }
});

You can use polymorphism, redefine the meaning of methods, etc. For example the Element#select will search for matching elements by a css-rule, but Input#select will put the focus on the input element and select its content. No problem, you can do that easily.

Define Your Own Wrappers

The usual extending methods like Element#include, Form#include are fine, but in RightJS you are also allowed to define your own wrappers for certain types of elements. For example you can define a tables-sepecific wrapper

Element.Wrappers.TABLE = new Wrapper(Element, {
  sortBy: function(column) {
    // sort the table body
  }
});

Or you could create a textareas wrapper the same way

Element.Wrappers.TEXTAREA = new Wrapper(Input, {
  spellcheck: function() {
    // spellcheck the content
  }
});

NOTE: we inherited the Element and Input classes as you would normally do with any other classes in RigthJS.

Once you've done that, anytime you access a table or a textarea you'll have those new methods available

$('my-table').sortBy('name');

$('my-textarea').spellcheck();

This feature will let you to adjust and completely redefine the framework itself for the needs of your application.

But this is not the most kick-ass thing yet. Because we have much more!

Private DOM-Wrappers

With RightJS 2 you are not limited to the actual dom-nodes and tags. You can define your very own private dom-wrappers that won't be tied to the framework structure in any way. Why would you need that? The answer is simple - widgets.

How do you normally write a widget? You create some class which aggregates some main element and then you have all the headaches with different contexts and bindings, because half of your logic is in your class and half is in your elements

var MyWidget = new Class(Observer, {
  initialize: function() {
    this.element = $E('div')
      .onClick(this.clicked.bind(this));
  },

  clicked: function() {
     // do something about it.
  }
});

Then more, you'll have to create several proxy methods to delegate the methods to actually insert the widget on the page and do other normal dom-manipulations and so one and so one. In more or less complicated case those things tend to get quite messy.

Well my friends, you don't have to suffer anymore, because now you can define your widget as a private wrapper and inherit any existing dom-wrapper directly just like that

var MyWidget = new Wrapper(Element, {
  initialize: function(widget_id) {
    this.$super('div', {
      'id': widget_id,
      'class': 'my-widget'
    });
    this.onClick('doSomething');

    // build your entire widget over here
  },

  doSomething: function() {
    // do something about the click
  }
});

NOTE: now you never leave the actual element context, don't need to worry about bindings, and then, can manipulate with your widget as a usual element on your page.

var widget = new MyWidget('widget-id');
widget.insertTo('some-element', 'after');
widget.addClass('custom-class');

// more of that!
$('widget-id') instanceof MyWidget; // true!

And there is more! You can inherit your private wrappers as any other and create different versions of your widget!

var MySuperWidget = new Wrapper(MyWidget, {
  initialize: function(widget_id) {
    this.$super(widget_id);

    this.onClick('doSuperThing');
  },

  doSuperThing: function() {
    // do the super thing over here!
  }
});

You can create abstract widgets, share modules between them, do any sorts of crazy things, the possibilities are endless! And at the end, you still have an Element, which you can toss around the page in the usual way.

---

Oh yes my dear fellas, RightJS 2 will help you to kick some serious ass! The right way!

And this is about it. Come over for the next session, it will be fun!

Prepare Your Project For RightJS 2

2010-08-05T15:55:00.005+03:00

Some notes for those lucky of you who already is hooked to RightJS and the ones who think about giving it a try, but afraid that when RightJS 2 will start saving the world, the ones code will go south.

Rule #1 don't panic, despite of all the massive changes in the dom-stack and all the new finest kickassery, the actual API almost didn't change, just instead of real dom-nodes/events/etc you will receive some proxy objects, which have the same exact API. The difference is that you will have no direct access to the dom-unit attributes, so if you want your code to be working both in RightJS 1 and RightJS 2, use the Element#get, #set and #has methods instead.

// instead of this
$(element).id = 'boo-hoo';
var id = $(element).id ? $(element).id : 'default';
  
// write it like that
$(element).set('id', 'boo-hoo');
var id = $(element).has('id') ? $(element).get('id') : 'default';

If you need to access an element innerHTML use a simple patch like that

Element.include({
  html: function() {
    return this.innerHTML;
  }
});

Later, when you will migrate to the actual RightJS 2, just remove it, RightJS 2 will have this method out of box.

Rule #2 don't access `window` and `document` directly, when you need to access some of the RightJS methods, put them through the same `$()` function first as you do with the dom elements

// instead of those
document.onReady(function() { ... });
window.sizes();

// call it like this
$(document).onReady(function() { ... });
$(window).sizes();

Rule #3 don't use `Form.Element` this unit will be renamed to Input in RightJS 2, so don't touch it or create a simple reference like that

var Input = Form.Element;

and work with the Input object instead.

This is about it. If you follow those three simple rules, all your code should be in working condition when you switch to RightJS 2.

The Circus of Web Development

2010-08-01T09:09:00.002+03:00

You might think of the web-development area (or sphere if you will) as some sort of a circus. For example.

Say there is an elephants show of Java developers, they big, slow, but precise. Then there is a exotic pet show of Python developers. Fearless camel riders with the perl guys. JavaScript people will be magicians, weird fellas who make things appear and disappear by some flimsy tricks.

Then there are a bunch of trained monkeys of Ruby kids (yes my agile friends we are :)). ASP.NET folks will be gipsy fortune-tellers, barely connected with the reality and no-one listen to them. And there are bears on monocycles in silly turkish hats, those are the PHP people (you are comrades, you are).

Clowns! Those will be the web-architects. Just like the real clowns, they barely can do a thing properly, and yet, they think they own the circus.

RightJS 2.0.0-rc Is Out

2010-07-31T11:18:00.010+03:00

Okay folks, RightJS 2 came to the point where it has a proper number and the '-rc' suffix in it's name. And here are some notes on the new sweet features we have since the beta release.

You can download the build over here, the archive contains both normal and safe-mode builds.

Generally this is almost the final line, I've finished packing it with new features and this is practically all we will have in the actual 2.0.0 release. There might be some tweaks here and there during the plugins and UI modules porting, but nothing dramatic. So lets check what we've got.

Dom Wrappers

In RightJS 2.0 we have a new kick-ass object oriented dom-wrappers system. Our dom-wrappers are essentially classes, with types, inheritance and all the nice functionality injection features. Currently we have the following wrappers Window, Document, Event, Element, Form and Input, which formerly was known as the Form.Element unit.

Dom-wrappers work transparently and have all the same nice API we had in RightJS 1, the only difference is that instead of the actual dom-element all the methods now operate with dom-wrappers.

$('element-id')  // -> dom wrapper
$$('#css .rule') // -> a list of dom-wrappers

All the dom wrappers are inherited from the same unit called `Wrapper` and have a common property called `_` which refers to the raw dom element, for example

$('element-id')   // -> Element wrapper
$('element-id')._ // -> the actual dom-node

$(window)         // -> Window wrapper
$(window)._       // -> the window object

$(document)       // -> Document wrapper
$(document)._     // -> the document object

So every time when you fill like it, you can always quickly access to the raw unit the same way across all the wrappers.

Dom-Wrappers Typecasting

As you might noticed we have three types of wrappers for dom-elements, the Form and Input classes are subclasses of the Element class and when you access your dom-elements they dynamically typecasted

var element = $('my-form');
element instanceof Element; // -> true
element instanceof Form;    // -> true
element instanceof Input;   // -> false

var element = $('my-input');
element instanceof Element; // -> true
element instanceof Input;   // -> true
element instanceof Form;    // -> false

This way you can check which type of element do you have and you can extend all of them separately


Element.include({
  global_method: function() {}
});

Form.include({
  forms_only_method: function() {}
});

Input.include({
  inputs_only_method: function() {}
});

You even can use polymorphism and use the same method names

And you also can define your own types, for example

Element.Wrappers.TABLE = new Wrapper(Element, {
  orderBy: function() {}
});

Later on there will be also private dom-wrappers which you can use in your app without extending the RightJS core and interfere with other applications.

Bubbling Dom-Events

RightJS also received several fixes for the traditionally problematic dom-events like focus, blur, change and submit, now all of them properly bubble on all the supported browsers.

There is nothing kinky about it I didn't use any special event names, just use the usual ones like nothing happened.

$(element).on({
  focus: ...,
  blur: ...,
  change: ...,
  submit: ...
});

I also added the custom events bubbling. If in RightJS the custom events didn't go anywhere from the node where you fired it, now they properly bubble up to the document object, so you can take advantage of them using the events-delegation technique.

Speaking of which.

New Events Delegation API

In the later releases of RightJS 1.5 we already had some elements of the events-delegation feature support, now it's time to take it to the next level.

First of all the String unit now has all the same API as Element, so you don't need to learn nothing new, just use what you already know.

"#div .span".on('click', function() {...});
"#div .span".onClick(function() {});
"#div .span".onClick('addClass', 'marked');

// you also can make the normal checks
"#div .span".observes('click'); -> true
"#div .span".observes('mouseover'); -> false

// and you can unbind the listeners the usual way
"#div .span".stopObserving('click', function() {});

Then the Event.delegate and Event.behave methods are gone and instead of them we have a proper events delegation API on dom-wrappers which look like that

$(document).delegate('click', '#css.rule', function() {});
$(document).delegate('click', {
  '#css.rule1': function() {},
  '#css.rule2': function() {}
  ....
});

// delegation checks
$(document).delegates('click');
$(document).delegates('click', '#css.rule');

// disabling delegation
$(document).undelegate('click');
$(document).undelegate('click', '#css.rule');

More of that the same API was adde to the Element wrapper so you can attach your delegating listeners at any level of your web-page

$('my-list').delegate('click', {
  'li.one-thing': function() {}
  'li.another':    function() {}
});

This way you can scope the delegation to some block of your document and handle the things locally.

You also can delegate custom events too

$(document).delegate('bingo', {
  '#one':   function() {}
  '#another': function() {}
});

$('one').fire('bingo');
$('another').fire('bingo');

Generally there are no limitations and you handle any sort of events simultaneously via the same api.

$$ Is Back!

As you might noticed I moved the $$ function back. I tried to use the jQuery-like unified $ method but didn't like it and brought the $$ back.

Amen.

Semi-Safe Mode

As you might know RightJS 2.0 will have the safe-mode build, which will hide everything behind a single RightJS object and won't extend a thing on the user's page.

A typical use case would look like that

RightJS.$('element-id').onClick(....);

var MyClass = new RightJS.Class({
  ...
});

There is also a way to access the language unit extensions by passing variables through the RightJS object

RightJS(['boo', 'hoo', 'doh']).filter('includes', 'oo');
RightJS(4).times(function() { .... });
RightJS('boo hoo').endsWith('hoo');

In the RC release I added a semi-safe API for the non-safe builds, meaning you can put your variables through and access the RightJS units via the RightJS object. This way if you need say to write a plugin that supposed to be working in both safe and non-safe modes, you can simply write it for the safe-mode and it will be working in the non-safe mode too.

JSONP Support

In RightJS 2.0 there is the JSONP format support for the Xhr unit. It all works transparently via the same Xhr API with all the same principles, the only thing is that now you have the jsonp option where you can specify your callback name variable, or simply use true for the default 'callback' value.

new Xhr('/some/url', {
  jsonp: 'myCallback',
  onSuccess: function() {
    // ....
  }
}).send();

Xhr.load('/some/url', {jsonp: true});

It even will assign the responseJSON and json varaibles

Xhr.load('/some/url', {
  jsonp: true,
  onSuccess: function() {
    console.log(this.json);
  }
});

New Language Level Methods

There are also several new javascript level extensions were added. Object.each, Array#reject (which is useful with calls by name), Array#min, Array#max, Array#sum

Probably something else that I have forgotten.

The Next Steps

Now when the core is finished, there are quite a lot of work with porting the plugins to the new version and reworking the documentation. The site also needs to be reworked to support the new building system.

At the moment I estimate it like 2-3 weeks of work. So the delivery-day is somewhere by the end of summer.

Okay, think that's all I have for know.
Take care!

Why Albeit Packing Is A Bad Idea

2010-07-30T11:15:00.011+03:00

Okay I did it quite a lot on RightJS, but I've learned my lesson. A quick and self-explanatory example would be like that.

Say you have the following piece of javascript

a1.looooongMethod();
a2.looooongMethod();
a3.looooongMethod();
a4.looooongMethod();
a5.looooongMethod();

Being an optimization junky, you might think, "Oh! I can make it smaller!"

var b = 'looooongMethod';
a1[b]();
a2[b]();
a3[b]();
a4[b]();
a5[b]();

Then you look at the size, the first one weights 104 bytes and the second one 70.

"Woohoo!", you say, "30% optimization!". And will be wrong.

Because when a web-server gzips your code, the first one will weight 61 bytes and your optimized version will be... TADA! 72 bytes. Yup, bigger than it was before 8)

That's the whole story. Gonna go and unoptimize things back now.

Freezing Terminal.app in OS X

2010-07-19T10:57:00.003+03:00

I ran in a strange bug yesterday on my macbook. Suddenly the Terminal.app started to freeze when you lunch it or open another window.

I killed half a day trying to figure out what's wrong with my HDD, and trying to restore parts of the system from a backup, but then found out that the problem was in another place.

So if you run into the same issue the cure is simple.

sudo rm -rf /private/var/log/asl/*

Apparently there is some problem with the log files that cause circular read/write calls, so when you nuke the old logs, it will get just fine

The RightJS DOM-Wrappers Speed

2010-06-29T18:42:00.004+03:00

Okay folks, there is your next brainwashing session to keep you hooked to the right stuff.

When I announced that RightJS is switching to dom-wrappers, some of you seems started to panic. "Oh, no!", you said, "RightJS is going down, because native extensions murk dom-wrappers any day at any time!"

Well people, you just haven't seen the right wrappers yet 8). Here is the shot of the new engine in its raw, not fully optimized state.

FF 3.6.6

And so you didn't think that it's just FF, here is a shot in Opera.

Opera 10.54

Don't have a short for IE though, because didn't quite make it there yet, but you can imagine that it will go sky rocket, because there will be no elements extending anymore.

Some of you, young and sharp, might notice that, the ID access went down for a notch. That's all because of you guys, that's because in RightJS 2, you'll have the same $ method behavior as you have in your beloved jQuery, meaning you'll navigate it like that.

$('#boo-hoo'); // -> an element by id
$('div.boo, div.hoo'); // -> elements by the css-rule

There also will be things like $(window) and $(document), so you'll feel yourself like home.

That's about it. Hold on to the next session!

RightJS Development Status

2010-06-26T10:34:00.004+03:00

Hey folks, to keep in touch, some notes on the RightJS development status.

As you probably already know the next step in the RightJS evolution is coming. Currently I do all the fixes and main feature updates in the 'master' branch and all the dramatic changes go into the 'two.o.o' branch. So if you'd like to see what's going on, go and check it out from github.

So what's actually going on?

New building system

First of all I move the source code building system from the amaturish concatenation of some pieces of code to more serious layouts based builds.

What does it mean?

It's fairly simple. Instead of having all sorts of small isolated pieces of code, now we have one global function which isolates the RightJS initialization process inside. It doesn't mean that RightJS now closes its insides like jQuery does. No, all the crazy monkey patching abilities remain in place and it is still an open architecture, but now we don't need to worry about accidentally polluting the global scope with some temporary variables, plus it gives us a great deal of optimization abilities in speed and size.

Secondly, now we use the google's closure compiler to compact the javascript code. It works a bit faster and provides slightly better results than my FrontCompiler.

I haven't finished yet with all the size optimizations yet, but the layout based builds + google-compiler are already giving us some benefits. Despite that I already added quite a few new features and methods, the size of the builds went down at about 1K and goes like 40K of the minified (not packed) code, which is about 15K in gzip.

Then it seems like I'm going to get rid of the albeit-packed builds. The reason is that most of the web-servers those days use gzip compression and in this case there is no significant difference between the packed and minified versions. And as the packed version initializes slower than the minified one I think there is not much of reasons to continue to support it.

In any case, you'll be able to albeit-pack RightJS with FrontCompiler at any moment by yourself.

The Safe Mode

The are another reason for the layouts based builds - the safe-mode development. And currently there are several directions which the safe-mode development goes.

First of all the name spaced mode. Now as RigthJS initializes inside of a layout, it extends the global scope only at the very end. So you can easily have a name spaced build by removing one line of code from the end of the file and all the RightJS global objects will be available in the scope of the RightJS object.

You still will have all the native and dom object extensions with all the benefits and troubles and your code would look like that


with (RightJS) {
  var MyClass = new Class({
    include: Options,
    
    initialize: function(id) {
      this.element = $(id);
    }
  }
}

Or, if you're against the with calls, like that


var MyClass = new RightJS.Class({
  include: RightJS.Options,
    
  initialize: function(id) {
    this.element = RightJS.$(id);
  }
}

The second direction is so called condom-mode. The idea is that we initialize RightJS in a separated IFrame and then hook up the main window to the functionality via the RightJS object. In this case you have almost complete isolation of the contexts, RightJS won't touch the main window units and you also will have access to the RightJS fancy native extensions like that.


var R = RightJS;

R('boo.hoo').endsWith('hoo');
R(4).times(...);
R(function() { }).bind(...);
R([1,2,3,4]).without(2,3);
R.$('element-id').onClick(....);

RightJS will extend only those dom-elements which you actually work with. So you'll still have the RightJS speed and easy goingness, but you also have the ability to safely implement say widgets on someones page.

The condom mode is mostly ready, it still has some unfinished parts with the window and document access, but all the other things are already working. you can build and play with it in the `two.o.o` branch like so


rake build OPTIONS=safe

The DOM-Wrappers

The condom-mode is just a step to the next level, it is an interesting thing but it still does extend dom-elements you access. So I'm currently working on the next step which is the dom-wrappers.

The idea is to replace the direct dom-elements access with some artificial proxy which will have all the same interface as a normal dom-element but without actually extending the dom-elements themselves. The reasons are obvious, it's a peaceful coexistence with another scripts on the page and better cross-frame scripting abilities/performance.

This feature is still in progress and you'll see the first results in about couple of weeks.

After that, that's it, we release.

The Summary

One way or another, with the 2.0.0 release we should fix the only problem that wrong with the right javascript framework, the safety. We will have normal quick and naughty builds as we have now, but we also will have options with the namespaced and condom modes.

Which means we will have a rock-solid safety against the anxious MSIE or any other browser that will think its smarter than others, and you also will have the ability to use RightJS to develop widgets in the safe-mode.

That's about it.
Have fun!

Postion fixed in IE6

2010-06-02T18:50:00.007+03:00

If you old enough you might remember that wonder of technology we used to admire something like ten years ago, which also known those days as the zombi-browser aka IE6. And if you old enough and unlucky enough to have a need to make something with "position:fixed" under that browser, you might think about the usual approach with hooking up the window.scroll event with some piece of javascript and move the thing manually.

My dear friend, there is a better way to hack the shit out of it. Presenting you the CSS hack which will keep your element fixed at the bottom of the window

div.sweet-div {
  position: fixed;
  bottom: 0;

  /* IE6 position:fixed hack */
  _position: absolute;
  _bottom: none;
  _top:expression(eval(document.compatMode && document.compatMode=='CSS1Compat') ? documentElement.scrollTop +(documentElement.clientHeight-this.clientHeight) : document.body.scrollTop+(document.body.clientHeight-this.clientHeight));
}

Enjoy!

Making a Colorpicker

2010-05-21T10:22:00.004+03:00

The other day I've been implementing this colorpicker widget for RightJS and now I'd like to share some mathematics and mechanics behind the widget.

I won't bore you to death describing the actual layout, just some necessary theory and math. And I also will use RightJS semantics. Well, just because I love it.

The Color Theory

Lets start with a bit of a theory. Every giggling school girl those days knows that any color can be created by a proper mix of three basic colors, red, green and blue. That's a brilliant idea, but the problem is that not many people actually can use it. Personally me, I don't know anyone who can instantly say how much of every color you need to take to create say a color of coffee and milk.

And because of this problem the humanity created another, more natural way of color picking which is based on another three dimensions: tone, saturation and brightness. And the main idea of the colorpicker widget is to convert one system into another.

The Tone Parameter

The tone picker usually looks like a vertical bar and represents the following system of colors.

The principle is that with this tone scale you can have any tints available with full saturation and brightness. Note also that in every point of the scale, one of the colors is always has a zero value, and at least one of them has the full value.

Keep also in mind that this scale is some sort of closed circle, the end on the right is actually joined with the beginning on the left.

The Saturation And Brightness

The saturation and brightness field usually looks like that.

The saturation parameter is zero at the left side and have the full value on the right. The brightness is full at the top and zero at the bottom. This way, you will always have the white color at the top left corner, your current tint color at the top-right corner and a black line at the bottom side.

With those three handlers you also can chose any visible color but in more natural way.

Converting TSB into RGB

The first task of the colorpicker is to convert the tint, saturation and brightness parameters which the user picks into the actual RGB value.

It was proven that the best way of keeping your values in this case is if you keep your TSB parameters in float values of range 0..1 and RGB values in integers of range 0..255. This way you won't have systematic round up errors and it will be working faster.

So your TSB -> RGB script will look like that

var tint = [1, 0.5, 0];
var saturation = 0.6;
var brightness = 0.4;

var color = [0, 0, 0];

for (var i=0; i < 3; i++) {
  color[i] = 1 + saturation * (tint[i] - 1);
  color[i] = (color[i] * brightness * 255).round();
}

The principle is simple, first we combine the tint and saturation which will give as a raw color in range 0..1, then we apply the brightness parameter and convert the float value into a 0..255 integer.

Converting RGB into STB

The backward conversion is a bit trickier. I've drown a simple picture to help you understand the principle

Say you have some RGB color with values in range of 0..255. Remember our tint picture, where one value is always 1 and another is always 0. So this smaller area between the green and red values is the same thing, if you take it and normalize to the 0..1 range you'll have your clear tint values. The brightness parameter will be the proportion between the brightest color and the 255 value, and your saturation is relation between the minimal color to the maximum.

The script looks like that

// the initial RGB value
var color = [200, 100, 50];

// finding the minimal and maximal values
var color_sorted = color.clone().sort(function(a,b) { return a-b; });
var max = color_sorted[2];
var min = color_sorted[0];

// calculating the brightness and saturation
var brightness = max / 255;
var saturation = 1 - min / (max || 1);

// calculating the tint
var tint = [0, 0, 0];
for (var i=0; i < 3; i++) {
  tint[i] = ((!min && !max) || min == max) ? i == 0 ? 1 : 0 :
    (color[i] - min) / (max - min);
}

It is pretty much straight forward, but we also have some failsafe conditions like (max || 1) and (!min && !max) in case if all the RGB values are zeros.

HEX to RGB Conversions

And couple more things which you also will need. Converting your 0..255 colors array into HEX and RGB formatted strings back and forth.

Converting an array to a HEX value is simple

'#'+ color.map(function(c) {
  return (c < 16 ? '0' : '') + c.toString(16);
}).join('');

Converting RGB string into an array of values looks like that

if (match = /rgb\((\d+),(\d+),(\d+)\)/.exec(value)) {
  return [match[1], match[2], match[3]].map('toInt');
}

And converting any HEX color into an array can be done like that

// converting the shortified hex in to the full-length version
if (match = /^#([\da-f])([\da-f])([\da-f])$/.exec(value))
  value = '#'+match[1]+match[1]+match[2]+match[2]+match[3]+match[3];

if (match = /#([\da-f]{2})([\da-f]{2})([\da-f]{2})/.exec(value)) {
  return [match[1], match[2], match[3]].map('toInt', 16);
}

Well, that all you need to know to make one cool colorpicker of yours.
Enjoy!

Automatic Records Search in Rails

2010-05-18T08:54:00.007+03:00

There is one neat trick I'd like to share. In many cases, especially when you work on intranet applications, you need say to check some security settings against the data-records before you let the request to access the actual method in your controller. Normally, most folks do that by adding before filters to find the records, like that

before_filter :find_this
before_filter :find_that

def find_this
def find_that

When your application grows and starts having something like a dozen models, plus you might have nested routes where you need to check the security against the nested elements too, those things tend to get really messy.

So here is a simple method which I use on my projects

before_filter :find_restful_units
def find_restful_units
  params.each do |key, value|
    if key == 'id' || key.ends_with?('_id')
      unit_name = key == 'id' ? controller_name.singularize : key.gsub('_id', '')
      unit_class = Object.const_get(unit_name.camelize)
      instance_variable_set("@#{unit_name}", unit_class.find(params[key]))
    end
  end

rescue NameError  # just hung up if there is no such unit
  nil
end

You put this in your ApplicationController and it will automatically find and assign all your models, the actual and the nested ones.

This makes controllers much cleaner and you always have your models extracted and ready to use in the standard way.

RightJS vs. MooTools In The Game of Mines

2010-04-28T17:04:00.004+03:00

This weekend I had some fun implementing the good old game of mines using RightJS. The result is pretty cute, you should check it out. No, really, you will like it.

The thing is that about year and a half ago I implemented the same exact game using MooTools, you can check it out over here, and well, I have some words to say on this regard.

Okay, I certainly did get better during this last year and you might say that I know RightJS better than MooTools, but here are some numbers. (For the sake of a clean experiment I specifically didn't look into the old code before or during the development and eventually gone in a different approach in the implementation.)

With MooTools I was working on the game almost the whole week, I didn't work full time and as I recall it you could say it were good three, three and a half days of work. The result is 14k build of JavaScript + about 5k of CSS, which is about 19k in total.

In case of RightJS it took me about 6 hours to implement the whole thing from top to bottom, and the result built of JavaScript + CSS is just 9K of code.

Yup, a twice as compact result and about four times less time spent. More of that I believe that RightJS implementation has much cleaner and easy to understand code.

The really sweet things in case of RightJS were the number extensions, simplified collections processing and built in Observer unit. It feels so good and natural to implement game logic with them! I really enjoyed those things!

Well, that's about it.

RightJS + Rails = Love

2010-03-29T16:38:00.015+03:00

As the right-rails (the Ruby On Rails plugin for RightJS) was updated recently, lets have another brainwashing session. This time for Rails people.

If you're a kind of a pragmatic developer, you're probably asking yourself "why would I fall in love with this new thing? I already know Prototype and jQuery why would I need something else?", and believe me, I know precisely what you mean.

But ask yourself, being a Rails developer, were you ever happy of doing AJAX features in Rails? No, I mean, not like first two weeks on rails, or things like "it's working". I mean really happy, did you feel funny about Prototype or jQuery? Did they make the butterflies in your stomach fly? Literally.

Think about it. The Prototype support on Rails was always a kind of a flimsy hack and most serious developers don't really use those RJS stuff. And with jQuery you were always left alone to deal with all those kinky JavaScript stuff. That's good if you are a JavaScript guru and know your magic. But what if you are not, and what about the actual Rails business anyway? Did any of the frameworks really helped you in any way to be an actual Ruby/Rails developer?

How Is RightJS Different?

First and most important thing you should know about RightJS is that it was written by a Ruby/Rails developer for Ruby/Rails developers. And despite the fact that from time to time we have all those arrogant promotions and we mock jQuery folks constantly. RightJS is not really about JavaScript itself. It is something quite opposite.

RightJS is all about getting JavaScript off your hair. RightJS is made to help Ruby developers to deal with JavaScript tasks, it reflects Ruby way of handling things, has mostly Ruby syntax and many of its key features are copies of Rails features.

RightJS civilizes JavaScript and brings it closer to Ruby developers.

But we didn't came here to talk about JavaScript, right? What about Rails itself?

Lets Make The Butter Fly

How much time does it take to make a date-time field with a calendar in your framework?

Let me spare you the calculations time and show how it looks like in RightJS + RightRails.

<% form_for(@zing) do |f| %>

   <%= f.calendar_field :dead_line %>

<% end %>

Nope. I didn't forget nothing. `calendar_field` is all what it takes. RightRails automatically includes all necessary JavaScript, CSS and I18n modules on your page and initializes the fields, so you don't need to worry about a thing.

More of that, it will automatically swap between builds and source code for JavaScript in production and development modes.

So, would you like some rater or slider on your form?

<%= f.rater_field :rating %>
<%= f.slider_field :completeness %>

Oh, I know! You'd like some autocompleter, right?

<%= f.autocomplete_field :category, :url => categories_path %>

Would you like the autocompleter to be RESTful design and hard-caching friendly? No problem!

<%= f.autocomplete_field :category, :url => "/categories/%{search}.js" %>

Here you go.

And That's Not All

The fun is not over, not by a long shot. The next feature is that RightRails comes with a brand new RJS generator, and that's not just a collection of dummy functions like in the case of the Rails original RJS templates.

The new generator lets you literally write JavaScript in Ruby and more of that it allows you to mix Ruby and JavaScript calls in one flow escaping and transforming variables on fly.

For example this is how the annoying nested forms look like when you make them with RightRails.

<% form_for(@zing) do |f| >

  <div id="categories">
    <%= render @zing.categories %>
  </div>

  <%= link_to_function 'add' {|page|
     page[:categories].insert(render(Category.new))
  } %>

<% end %>

See, the `insert` method is a JavaScript function, the `render` is the ActiveView method, `Category` is your model. All in one flow with automatic types conversion. And it is not just a list of predefined functions, you can literally do whatever you want.

update_page do |page|
  page[:todos].update render(@todos)

  page[:todos_count].innerHTML = @todos.size + ' Items'

  page[:todos].select('li').each do |item|
    item.onClick('toggleClass', 'marked')
  end

  page.json_variable = @todos.to_json
  page.items_count   = @todos.size
  page.list_updated  = true

  page.alert "There are #{@todos.size} items left on the list"
end

There are no limiatations.

Mommy Look, More Fancy Stuff!

Oh yes mommy, there are! On top of all RightRails has a conventional interface to cover the most common AJAX CRUD operations. Let me show you.

Say here's your remote form

<% remote_form_for(@zing) do |f| %>

  <%= f.text_field :name %>
  <%= f.file_field :picture %>
   
  <%= f.submit 'Create' %>
  <%= image_tag 'spinner.gif', :class => :spinner %>

<% end %>

And here is your controller method

dev create
  @zing = Zing.new(params[:zing])
  if @zing.save
    render rjs.insert(@zing)
  else
    render rjs.replace_form_for(@zing)
  end
end

The `rjs` method provides access to the new RJS generator from the controllers, and `insert` and `replace_form_for` are the AJAX operations interface.

It all works over the Rails conventions, the `insert` method looks for the class of the `@zing` model, finds related partial, renders it and generates a piece of JavaScript that inserts the HTML into an element with the `zings` ID.

The `replace_form_for` method will render a new form with all the error messages for the @zing model and generate JavaScript that will update the form on the page.

RightRails has a collection of such methods for all CRUD operations.

Note also that I've put a file field and a spinner image on the form. RightRails automatically and transparently processes files uploading too, basically there is no difference whether your form has files or not, it all has the same API. And the RightJS when submits a form via AJAX, automatically searches for images with the `spinner` class and uses them as spinners, you don't need to hook them up with callbacks manually.

Summary

I'm not going to indulge you with obvious conclusions, I'll just tell you that I've already used RightJS + RightRails on two production projects and it saved me hell of a lot of time and nerves on JavaScript and AJAX development.

Well, it was designed to.

Supervisor Mode With Authlogic

2010-03-27T15:58:00.004+02:00

Supervisor mode is a feature that allows site admins to quickly switch to any other user (say customers) and take a look at the site the same way the customers see it, may be perform some actions from this user, etc.

So here is a simple tip how you do that using the Authlogic plugin for Rails.

First of all you'll need couple new routes, one to switch to some user, another to get back to the admin mode.

map.super_login '/login/:id', :controller => 'user_sessions', :action => 'super'
map.back_login '/login/back', :controller => 'user_sessions', :action => 'back'

I used two new methods named 'super' and 'back', which are not exactly RESTful, but you can use 'edit' and 'update' if feel particularly evil about it. They are normally not used in the 'user_sessions' controller.

After that on the list of customers you add links to switch under this user, for example like that

....
   %td= link_to 'Supervision', super_login(user)
....

And finally you'll need those two methods in your `UserSessions` controller

class UserSessions
  .....
  # switches under this user
  def super
    raise AccessDenied if !admin?
    session[:original_admin_id] = @current_user_session.user.id
    @current_user_session = UserSession.create(User.find(params[:id]))
    redirect_to '/'
  end

  # switches back to the admin -mode
  def back
    raise AccessDenied unless @current_user_session && session[:original_admin_id]
    @current_user_session = UserSession.create(User.find(session[:original_admin_id])
    session[:original_admin_id] = nil
    redirect_to '/'
  end
  .....
end

The idea is simple, in the first method you stash the original user_id in a session variable, then create new user session with that specific user. And in the second one we restore the original user in the session.

You also might consider to add two methods like `current_user` and `current_user=` in your application controller they are pretty useful and will make your code cleaner.

class ApplicationController
  ...
  # returns the currently logged in user
  def current_user
    @current_user_session.user if @current_user_session
  end

  # assigns the currently logged in user
  def current_user=(user)
    @current_user_session = UserSession.create(user)
  end
  ...
end

That's all. Have fun!

Mechanize and MultiSelect fields

2010-03-05T09:53:00.003+02:00

Mechanize is a little handy tool that allows you to perform all sorts of HTTP requests in Ruby. It automatically emulates all sorts of browsers, handles cookies, headers and stuff, which is really useful when you need to harvest some data from sites that don't have any computer friendly feeds.

I'm using it on my current project and run into a small problem. It doesn't work nicely with array data, like for example multiselect fields emulation, so when you do something like that


agent = Mechanize.new

agent.post('http://boo.boo/boo', {
  'param[]' => ['one', 'two', 'three']
});

In the reality it sends the 'one' value only. I've sent a little patch to the devs, but it seems like it will take time before they do something about it. So here is how you fix it in your rails app.

In any initializers in your `config/initializers/` directory add the following lines.


class Mechanize::Form::Field
  def query_value
    if @value.is_a?(Array)
      @value.collect{ |v| [@name, v || '']}
    else
      [[@name, @value || '']]
    end
  end
end

After that it will be just fine.

My Top 5 on that RightJS vs. jQuery Question

2010-03-02T11:55:00.006+02:00

During the last several months of RightJS promotion, the absolute hit among the questions of 'what?' and 'why?' was understandable the question of what is the difference between RightJS and jQuery.

There were lots of talks about RightJS speed and then more about speed, and then we had some abstract talks about its philosophy and its way among the others and we also have that simple comparison page.

And what I find important in a brainwashing process is systematicness and methodicalness. We did some talks on an abstract matter, we did some talks on the opposite side of scale with performance tests, now lets touch something real. Something in the middle. And probably summarize some previous talks.

So here it is, your next session; my top 5 as I see it at this morning.

1. Syntax

When I'm saying "jQuery is like PHP", first of all I mean the nature of its syntax. When you boil it down to the essence, both of them are just collections of helper functions. And as PHP defines a new kinda language upon C, almost the same way jQuery defines a new language upon JavaScript.

RightJS on the other hand is built right into JavaScript itself. In 90% it is the good old JavaScript, where we bring features from later JavaScript specifications and spice it with some standard features from more serious dynamic languages like Ruby and Python.

As the result, when you learn jQuery, you mostly learn jQuery, I've seen many nice fellas around, who know jQuery quite well, but stuck when they needed to do simplest things in pure JavaScript.

When you learn RightJS, you learn the actual JavaScript, yes we have some funny shortcuts and features that make mature web-developers happily giggling like school girls, but all of them are built upon JavaScript standards.

RightJS makes you do the things in JavaScript and do them right. And because of that, whatever the future brings, your knowledge and skills will remain with you.

2. The Actual STL

When I read someone saying "jQuery is the JavaScript STL", it usually makes me laughing so much, that my neighbors probably think that I've finally went nuts and going to blow off the Kremlin.

Now, don't get me wrong, I have no problems with jQuery's popularity and I respect that. Well, at least, as long as it keeps me away from people who doesn't know the difference between popularity and standards.

jQuery is a DOM DSL at best. First of all it doesn't have anything to do with JavaScript itself, because it's a DOM wrapper, secondly there is nothing standard about jQuery in terms of JavaScript. Take for example a look at the .each() function where the arguments are in just the opposite order than they are in the JavaScript own Array#forEach method.

If you need something that actually follows the standards, you should take a look at RightJS. It brings many standard features from later JavaScript specifications, plus many other none the less standard features from server-side programming languages, for example methods like String#startsWith or Array#random.

The DOM interfaces are just one part of RightJS and it has much more. We even have a build of RightJS without DOM features which you can use on the server-side with Node.js or say writing scripts in Qt.

3. Multiple Paradigms

As jQuery is simply a wrapper over DOM interface, it doesn't give you any alternatives but use its own way of dealing with the things. Yes, you might imagine that you're practicing Lisp in JavaScript, but the reality is that 99% of jQuery code (including jQuery itself) is just a spaghettish pieces of crap.

RightJS on the other hand is not just a DOM wrapper, it is a multi-paradigm framework. We have an advanced OOP stack that allows you to write clean and properly designed applications that are easy to support and refactor. We also have most of the standard FP features, like binding, curring, chains and stuff. We also have some standard native units extensions that are most helpful in procedural programming.

RightJS gives you options and flexibility, so that you could deal with your work in the most effective way.

4. Open Sandbox

Maybe jQuery forces you to write a spaghetti code, but there is a bigger problem. Most of jQuery and its plugins code are closed behind anonymous scopes that makes it impossible to change them part by part.

You know, people are actually already invented OOP, inheritance, functionality injection and other fancy stuff to deal with those sort of things. And that's why in RightJS we have radically opposite architecture.

RightJS is built using proper OOP structures and modules and it represents an open sandbox where virtually everything is accessible and customizable. You can easily bend and tune RightJS for your needs, changing and replacing its parts, adding your own features, methods and so one.

And because of that it is super easy to write any sort of plugins and extensions for RightJS. Take for example a look at the right-rails plugin; couple of dozens of lines of code and RightJS API was completely transformed to have the naming system of Ruby, with underscored syntax and other features.

RightJS gives you the same flexibility and hacker's joy as Ruby or Python.

5. Official Plugins

I'm sure you know what they say "jQuery has a gazillion of plugins that will do everything for you". It kinda reminds me other folks who was saying "Everything in Java has already been done".

Normal people usually add on that "badly".

That gazillion of plugins has actually a pretty nasty back side. The problem is in the closed architecture and inflexibility. For every case there are usually half a dozen of implementations, and quite often the choice is like "bad, bad or bad?". At the end you might spend more time looking for a proper plugin than you could spend writing it yourself, and at the finish your app will look like a Frankenstein, all stitched of different parts.

Yes I know, I know, Frankenstein is a romantic figure in gothic culture, but there is so few romantic in supporting such an app.

With RightJS we don't have the luxury of too many plugins, but we have several good points on that matter too. First of all, many common and frequently used features that you have as plugins for jQuery, are already baked into the RightJS core, like for example, additional form features, Ajax via iframes functionality, cookies and stuff.

Then we have all the standard plugins, like D'n'D, JSON, Behaviors, plus most of the standard UI elements like Calendar, Autocompleter, Tabs, Lightbox, etc. already implemented and served in the official plugins repository.

And what's different about RightJS plugins is that all of them are implemented in the same way, using the same set of rules. All events handling, options, usage principles all are the same. So that if you had experience with one plugin, you will be familiar with the rest of them too.

Then all the plugins follow the open-sandbox principles of the RightJS Core. All of them are implemented using proper OOP approach and can be easily extended using inheritance, functionality injection or even monkey patching if you will.

This way you don't need a dozen of variations of the same plugin, you can easily tweak any standard one to do exactly what you need.

Native Element#classList in FF 3.6 Against RightJS

2010-02-26T20:09:00.009+02:00

As many of you probably aware, FF 3.6 has the HTML5 Element#classList feature implemented natively. And then @DouweM asked if we could add it to RightJS.

Well, I tried, but the thing is that those guys at Mozilla could do it better. They have the test, the picture and yet another 2x times performance improvement, awright.

But lets check it out by ourselves, shall we?

I've created this little script which has two implementations, one uses FF 3.6 native feature, another one uses the same pure JavaScript algorithm we use at RightJS to handle css-classes. And here's a screenshot of my test-run.

Seems like RightJS implementation murks a native feature again. It's more than three times faster on classes adding :)

So how did those guys at Mozilla get their results?

They simply used lousy RegExp based implementation of the feature in their test. Surely it was slower.

This is pretty much it. Hope they will fix it in the next releases of FF.

Recent jQuery Performance Updates

2010-02-20T23:36:00.005+02:00

Now folks, you know, I was always saying "there is nothing like a smell of good statistics in the morning!". Now lets take a look at that 2x speed up claimed over here.

I'm using my Shakker util to perform the tests. You can also read why I don't use Taskspeed anymore.

So to the tests. Lets take a look at the Firefox test

Yea, kind a bit of speed up at claimed `bind`, `html` and `remove` methods, certainly not 2x, and note how it actually got slower at 1.4.1 and then gets back to almost the same values as 1.4.0.

Now lets take a look at the same thing at Safari

A different scale, the same picture, it's getting slower from 1.4.0 to 1.4.1 and then gets back to almost the same values at 1.4.2. No 2x speed up between 1.4.2 and 1.4.1, more of that almost no speed up at all and certainly no 3x speed up agains 1.3.2.

Well, lets get further and take a look at the test in another fine browser, Chrome.

The same exact picture with the `bind`, `html` and `remove` methods, got slower on 1.4.1 and to the same value at 1.4.2.

Now you should get back to that release notes page and ask yourself "why there are no results for version 1.4.0?".

Yup, because there is no speed up, they merely fixed their own fuckups in 1.4.1 and now present it as 2x speed boost.
Awesome! :)

Slowing Things Down Under OS X

2010-02-20T22:38:00.003+02:00

You know what they say "you need to slow down to see some certain things". In case of web-development, sometimes you need to emulate a realistically slow internet connection to see some problems with your project. See how quickly it loads up, how it receives the images, especially it useful to test file-uploads and ajax operations. So here is a little tip how can slow down requests to your local server to test the things properly.

Under OS X you have access to the FreeBSD traffic shaping util ipfw. First of all you need to define some rule which will work on local interactions.

sudo ipfw add 1 pipe 1 src-ip 127.0.0.1
sudo ipfw add 1 pipe 2 dst-ip 127.0.0.1

After that we can set up the connection speed, and also I like to add some delay to emulate a request to a remote server

sudo ipfw pipe 1 config bw 40Byte/s delay 100ms

After that all your local requests will slow down to 40Byte/s speed with a realistic 100ms response delay.

When you have done with your tests, you can remove the rule with the following command.

sudo ipfw delete 1

Now it is all interesting but lets wrap it up in a simple shell script so we didn't need to memorize all the fancy calls.

sudo touch /usr/bin/slowdown
sudo chmod +x /usr/bin/slowdown

After that open the file with your favorite editor and write the following little script


#!/bin/bash

if [ $1 = "clear" ] ; then

  ipfw delete 1
  
else
  
  ipfw add 1 pipe 1 src-ip 127.0.0.1
  ipfw add 1 pipe 2 dst-ip 127.0.0.1
  ipfw pipe 1 config bw $1KByte/s delay 100ms
  
fi

Now you can create and remove pipes just like that

sudo slowdown 40

And to remove the rule call it like that

sudo slowdown clear

That's all about it. Happy testing!

Algorithm Complexity Analysis On An Interview

2010-01-31T12:26:00.005+02:00

I was digging around trying to find what kind of questions Google interviewers ask potential candidates and found some guy story who was asked the following question:

"What is the complexity of searching for existence of all characters from one string into another?"

That guy answered "n*n", and after being rejected was wondering if it was "n*lg(n)". Poor little thing...

IMHO: Rule #1 when you're having an interview (I guess, especially at Google): "never trust the interviewer", it is their job and trade to mislead you and check how you actually think, rather if you know the correct answer.

So, here is how I would answer to that question. (yeah, I'm showing off, but please consider that as me simply exercising)

Okay. First of all the complexity vastly depends on an implementation. I can see at least three of them.

1. A blunt force solution, you just go through every character from the pattern string (p) and check if each of them exist in the text string (t). Strings are essentially arrays and search of any character in them have linear complexity. So that if we have n = |p| and m = |t|, then the overall complexity of the algorithm will be

O(n * m)

2. There might be another solution. If we pre sort the t string with say quicksort algorithm, then we can use the binary search, which has logarithmic complexity and faster than a blunt cell-by-cell search. In this case, considering that the quick-sort complexity is super-linear, the overall complexity will look about like that:

O(m * lg(m) + n * lg(m))

3. One more version. Considering that both strings consist of the same limited number of symbols, we can create two hash-tables, one will contain unique characters from the p string and another one will have characters from string t. As the alphabet is a limited list, finding of the intersection of those two tables will have a constant complexity. Plus we should add the complexity of building the hash-tables, which will be equal to the lengths of the strings. And the overall complexity will be

O(n + m + C) = O(n + m)

Roughly speaking, we can take a look at the case when n = m, then we can say the following about those three algorithms:

1. O(n*n) - quadratic complexity
2. O(n*lg(n)) - super-linear complexity
3. O(n) - linear complexity

I suppose the last one is the winnar.

--

This is about it.

I still do have that feeling that I'm gonna get my ass kicked in the upcoming interview, but at least I won't give up that easily and will throw couple of punches back.

How to Move Folders Between Git Repositories

2010-01-25T17:02:00.007+02:00

Today I needed to move some folders from one git repository to another preserving the history. Evidently it's a tricky business, so here is how do that.

First of all you need to have a clean clone of the source repository so we didn't screw the things up.

git clone git://server.com/my-repo1.git

After that you need to do some preparations on the source repository, nuking all the entries except the folder you need to move. Use the following command

git filter-branch --subdirectory-filter your_dir -- -- all

This will nuke all the other entries and their history, creating a clean git repository that contains only data and history from the directory you need. If you need to move several folders, you have to collect them in a single directory using the git mv command.

You also might need to move all your content into some directory so it didn't conflict with the new repository when you merge it. Use commands like that

mkdir new_directory/

git mv my_stuff new_directory/

Once you've done commit your changes, but don't push!

git commit -m "Collected the data I need to move"

This is all about the source repository preparations.

Now go to your destination repository

cd ../my-repo2/

And here is the trick. You need to connect your source repository as a remote using a local reference.

git remote add repo1 ../my-repo1/

After that simply fetch the remote source, create a branch and merge it with the destination repository in usual way

git fetch repo1
git branch repo1 remotes/repo1/master

git merge repo1

This is pretty much it, all your code and history were moved from one repository to another. All you need is to clean up a bit and push the changes to the server

git remote rm repo1
git branch -d repo1

git push origin master

That's all. After that you can nuke the temporary source repository.

I'm looking for a job

2010-01-25T15:03:00.004+02:00

I'm a seasoned web-developer with almost 9 years of professional experience, looking for a position of Ruby developer/software designer.

I'm an early Rails adopter, started to work with it at the very first versions more than three years ago. Since then worked with Rails on a wide range of applications, blogging, social networks, e-commerce, real estate. I also have experience working with Merb and Sinatra, have several rails plugins and a non-rails application of my own. Before Rails I worked with Python, Groovy, did some Java and quite a lot of PHP (object oriented, no crap)

My specialty is multi-lingual, hi-load and ajax applications. I also pretty good in models, databases and workflow design. And certainly I can do some serious JavaScript work.

I will prefer a permanent position and ready to relocate (have experience working overseas), but also can work as an independent contractor/consultant, including telecommuting (have freelance experience).

If you're interested, please check out my CV, it has my contacts in it.

Terminal Fun, or Why RightJS?

2010-01-24T15:46:00.005+02:00

In this article I'd like to share some backstories and ideas that lead me to the development of RightJS. There are some generic texts on the official site, but in this article I'm going to get into some architectural details, thoughts and philosophy that were used as the basis in the development.

It might start to sound a bit philosophical and like RightJS saves the world, so please, be patient, I'm sure you can find some rational ideas behind.

Disclaimer

Despite the fact that I did quite a lot of JavaScript work lately, I'm not really any sort of JavaScript guru. I mostly work as a software developer/designer on the server side and my weapon of choice is Rails.

What I do with RightJS is a mere attempt to build a tool that will fit Ruby/Python developer habits and will be fun to work with.

Philosophy

That might be an arguable point of view, but to me the world is always trying to find a balance. The third low of mechanics says: "every action causes an equal and opposite reaction", and for this reason opposite forces always find a moment of equilibrium, moment where things are balanced.

For example when a body falls though air, the forces of gravity and air friction eventually gets equal and the body stops gaining speed; reaching its terminal velocity. A simple fact, but those two opposite forces combined make things like flight possible.

You might extrapolate and abstract this principle a bit further and take another two opposite things: "fun" and "safety". Abstractly speaking, I guess it is obvious that the more there is safety the less fun it is, and the more fun it is the more it gets dangerous.

Those two follow the same exact principles. And as much it might be honorable and cool to be at one side, with rebels or with the enterprise; the truth and all the magic things always lay somewhere in the middle. And that's what we are trying to do in here.

With RightJS I'm trying to reach that moment of terminal fun.

Back to The Reality

When it comes to JavaScript and safety I'm sure most of developers will think jQuery. On the other side of the scale probably will be Prototype. And I'm sure everyone who ever worked with JavaScript recently, heard lots of talks about the jQuery safe-mode, and how non conflicting it is, and how it lets you easily write plugins and so one.

But the truth is, that wast majority of the people who does those talks, never did write any plugins, never got in really non-solvable conflicting situations, and as the matter of fact they don't know anything but jQuery. They just heard that prototype extensions are dirty, and probably think that hating them makes them look tougher :).

Meanwhile, people were using Prototype for years, there are hundreds of plugins. And yes, big corporations did and still do use it. The reason why people started to switch from Prototype is because it got too fat and slow, not because it is unsafe.

It kinda reminds me the situation with airports. Someone, somewhere did created that shoe-bomb, and now we all have to stand in queues at security checks, take off our shoes and have a walk on a dirty floor.

Is it safer this way? Indeed it is. But if you are not a bad guy, would you like to skip that procedure?

I bet you do.

Between Safety and Fun

So, what about RightJS and that terminal fun thing?

Yes, RightJS does extend prototypes and we do have several global scope units and functions. That's true. But we don't do that blindly creating a crazy mess.

Most of the native unit extensions simply bring methods that already exist in later specifications. Things like String#trim, Array#map, Object.keys, Function#bind. Yes we do add them to the prototype level. But they all behave strictly in the standard way and they _will_ eventually appear in browsers.

I agreed that there might be some desperate people who had a complicated childhood and might implement a non-standard Array#each method and screw the things up. But IMHO, we should let the people learn on their mistakes and that's certainly not the reason to get scared and hide behind some "safe" interfaces. If someone wants he can screw the safe interface just the same way.

On the other side, adding those methods, will give you several advantages, like first of all you can use all those methods right now, without waiting while obsolete browsers will vanish from the face of the Internet. Secondly it will actually prolong your application life, because those methods only going to get into common use, which means your code will be mostly working in future even when RightJS disappear.

Then we do have several other top-level functions and objects. Functions like isString, isArray, isObject, $A they are extremely handy in everyday work and they are real time savers. Those methods all have clean, standard names and behavior, and you need to be a crazy person who don't know what he does, to re-implement them for some radically different purpose.

Yes we do unsafe things with RightJS, but all of them are strictly managed, organized and helpful. This way we balance between total safety and fun/comfort in work.

Deeper Down The Rabbit Hole

Any security comes with its cost, which is usually freedom and flexibility. Yes, I do agreed that having a non-conflicting interface is safe, but on the other side, it hooks your whole application on that interface. And I'm not talking about ridiculous situations, when you use the safe interface only and there are no potential threads for your application. Yes you are safe, but you're hooked to that interface.

We are living in a pretty dynamic environment, and things do get faster and faster. New superior solutions appear every year. So consider this.

Most of Prototype/Mootools code will work on RightJS after trivial and easily programmatically processable fixes. Same for RightJS, because it sticks to the standards in method names and behaviors, it will be really easy to transform RightJS code into Prototype/Mootools, pure DOM or even jQuery if you will.

In case of a safe interface on the other hand, you don't have to change anything and you won't. 99.9% of applications will stuck with it, continuing to drag it around creating a mess of frameworks and interfaces inside of a single application. Take for example Dojo. An excellent framework, but most of applications are trapped with it, because it is too expensive to migrate.

Okay, tomorrow might be a long shot and many applications don't live that long. What about today? There are also things to think about.

RightJS unlike jQuery is not just a DOM-wrapper, it is an actual framework. RightJS does not leaves you alone with pure DOM/JavaScript when you disagree with what's going on. It supports multiple paradigms of development, OOP, FP, procedural style and at any moment you're free to choose how to do your job.

Then, in similarity with languages like Ruby or Python, the whole structure of the framework is open. Unlike solutions with a safe interface RightJS doesn't hide anything inside of closed functions with spaghetti code. Most of the methods are organized in proper OOP structures and can be easily transformed and adjusted one by one.

Another point is that RightJS helps you utilize things like options, events, dom-manipulations, etc. in a single uniformed way. And that's too the part of the terminal fun idea. There are might be dozens of ways of dealing with things outside of the framework and if there are no regulations those things might cause collisions. RightJS provides you a conventional way of dealing with those things, which at one side reduces the likelihood of troubles, and on the other brings consistency across all the applications, making it easier to work with.

--

There are lots of things that RightJS takes care of, but I think it's all out of this article theme and then you can find all of them on the official site.

So for now I guess that's all. Hope I gave you some sense of perspective and food for thoughts on the topic.

Take care,
Nikolay

So, is really jQuery 1.4 30'000 times faster?

2010-01-15T16:11:00.007+02:00

Okay, I admit that, when it comes to RightJS promotion, sometimes I do behave like a bastard and have no mercy over women and foreigners. But this jQuery 1.4 celebration is well out of my league! :)

I probably should just shut up about them publishing the release saying it weights 24k, and I've seen people today screaming "oh, it like the good old times!", and then they realize that it says in breakers "(gzipped)" and find out that the actual script weight is 70k. For a comparison, minified the same way Prototype weights 72k.

But why I will never get tired of mocking jQuery users is that performance optimization graph John posted over there http://jquery14.com/day-01/jquery-14. In case they will fix it, I've saved a copy over here.

Basically what it says is that jQuery 1.4 makes 30'000 (oh yeah baby, thirty thousands) times less calls than 1.3.2. Well to be honest in just a few operations. Seeing people making things like that I couldn't resist it and fired up my trusty Shakker, which bluntly compares frameworks performance feature by feature.

So what do we see? They did optimized it awright. Certainly not 30'000 times, more like 30% in average. At least it looks okay in FF

But when you run the test in Safari and Opera, you can see that it actually getting slower in some operations

And that's not the end. This test performs comparison on collections handling. And if you take a look inside of the new "fast" jQuery methods, you'll find out that they simply put collections processing in plain spaghetti JavaScript code. That means that it will and is working fast on collections, but when you process single elements (which is the majority of the cases), those methods will work slower.

This is about it. You can find all my tests code over here Shakker

But good luck with the 2 weeks orgy though 8)

Making a gem out of your ruby-on-rails plugin

2009-12-27T16:05:00.009+02:00

Generally, now, when we have the gemcutter service, making a gem is not a brainer. Just find a similar project on github, copypaste its gemspec, then say gem build my.gemspec and gem push my.gem and you're basically done.

But there are some options you might want to know about.

First of all to that gemspec business, as I said, if you never did that before, you'd better just find a famous plugin on github that is more or less close to your project, copy its spec in a file named my-plugin.gemspec in the root of your plugin and fill it up with descriptions of your project.

You might find the gemspec option descriptions here and here. For example if you need to show the user some post install message, use the post_install_message option like that


spec.post_install_message = %Q{
  Warning! Warning! Annoying message!
}

And one more, some gemspecs on github use plain lists of files that should go into the spec, sometimes with several dozens of entries. Don't do that. First of all, it will be pain in the ass for you, because you might just forget to update the list when you create a new file, second of all it will be pain for another people who might be interested in evolving your project. Ruby is a nice language and has everything you need to process those stuff automatically. For example like that


spec.files = Dir['lib/**/*'] + Dir['spec/**/*'] + %w{
  README
  LICENSE
  CHANGELOG
}

For the second thing, you need to understand how rails hooks up plugins and gems.

When you create a ruby-on-rails plugin there is a file called init.rb in the plugin directory. When rails fires up, it adds your plugin lib/ directory to the load-path and then includes this init.rb file. Basically that's a good idea, you can keep the actual code clean in one place, and the dirty monkey patching script in another. This way you can test them separately and use separately, like say you want your module be available as is, outside of the rails stack, say with Rack apps or something.

But when it comes to a gem, it's a bit different story. Gem supposed to be just a standalone piece of code which you require from your application. It doesn't know anything about initialization, and when ruby-on-rails hooks it up, it just requires a file with the same name as the rubygem.

Say you have a plugin named super_duper then you will have a file lib/super_duper.rb, which rails will include when the gem is specified in the config. So, if you want to convert your plugin into a gem, you basically have two options. Include your init script into the super_duper.rb file, probably with some additional dirty conditions, or create another file like lib/super_duper_lib.rb and make your user define the gem in rails config like that


conf.gem 'super_duper', :lib => 'super_duper_lib'

Both are quite dirty and yet pretty common.

But, there is another, nicer option that lets you avoid disadvantages of those two approaches.

The trick is simple. All you need is to name your ruby-gem in a dashed style. Like say you have a plugin super_duper, so you create a ruby-gem named super-duper, after that you just create a file named lib/super-duper.rb with one simple line of code in it


require File.dirname(__FILE__) + '/../init.rb'

When ruby-on-rails hooks up the gem it will load the dashed file, which will load your init script. This way you can share your initialization script between plugin and gem, and you still keep your actual code clean and easily available outside of the rails stack with the standard require 'super_duper' call.

Meet Shakker The Mano-A-Mano JavaScript Performance Testing Suite

2009-12-18T17:07:00.005+02:00

I've started this project after several months of using Peter Higgins's TaskSpeed library as the main regression testing utility during the RightJS framework development.

TaskSpeed is a pretty well done library, but many people (including me) were complaining about its tendency to mix different tasks in one, mainly the css-selectors and stuff, so sometimes it wasn't clear what's going on. Another problem was that it provides just a total time as the summary, which is not an exactly clean way of judging about frameworks relative speed.

So I started my own little script, which become a bit bigger script and that one become even bigger one, and bigger and bigger. And now we have for ourselves practically an alternative solution for the TaskSpeed library.

Meet The Shakker!

The first difference between Shakker and TaskSpeed is that, Shakker has a two-level tests structure, the first one drives the test and keeps the data, the second one keeps the actual framework test. This way we have real-live like data separation on one side, and a blunt feature-to-feature comparison on the other. Shakker counts only the actual feature run-time for every framework, skipping utility operations like elements search, preparing collections, and stuff.

Another difference is that, Shakker not just collects the time summary, it collects differences between framework results for every test and then calculates average values between all the tests. It also let you choose one framework and evaluate it against others. This way you can have an approximated relative frameworks speed comparison.

It also keeps the original by-summary results, so that if your love sucks, you always can choose another result.

So what all this gives to you? See for your self. I'm posting results for all the modern browsers below, browsing through them you can actually see now what's going on. For example, you can clearly see, that say RightJS slows down in the building and finding operations under IE7,6 because it has to extend all the nodes manually on those browsers. You also can see where optimizations for jQuery 1.4 go, and you can see how Dojo fastly unbinds event listeners, because it doesn't have an internal events registry and makes the developer keep all the pointers manually. You also can clearly see how RightJS rips off everything under Chrome and Safari, because it doesn't uses any special proxy for dom operations, and uses common Arrays, which those browsers heavily optimize.

Lots of interesting stuff.

Google Chrome

Firefox 3.5.6

Safari 4.0.4

Opera 10.10

Konqueror 4.3.2 (Ubuntu on VMWare)

Internet Explorer 8 (WinXP on VMWare)

Internet Explorer 7(WinXP on VMWare)

Internet Explorer 6(WinXP on VMWare)

All the tests were performed in OS X 1.6.2, on 2Hz macbook with 4GB of memory.

FrontCompiler With Rubygem And Console Tool

2009-12-13T22:32:00.004+02:00

FrontCompiler is a Ruby based JavaScript/CSS/HTML compressing tool of mine. It can create albeit packed JavaScript, works with DRYed CSS, can inline css in javascript, works as a Rails plugin, etc.

And as I use it quite a lot on my projects, finally, I've created a rubygem for it. It's available at the gemcutter service now.

http://gemcutter.org/gems/front-compiler

So if you use the project, you might just install it from there.


gem sources -a http://gemcutter.org
gem install front-compiler

Along with the rubygem I've added a simple console tool to work with the compressor


$ frontcc file1.js file2.js ....

It will automatically recognize the file type by its extension, so you can feed it with javascript or css or html. It will read them all, compress in a single string and spit it in the stdout. You also can mix javascript and css in one command to make the css be inlined in javascript.

Enjoy!

RightJS vs. jQuery, Mano A Mano

2009-12-12T01:33:00.012+02:00

After the RightJS 1.5 release, there was people hyping about RightJS being 6-8x times faster than jQuery. After that there was quite a fight about that and then funny boy Felix had posted an article which kinda says it's a bull.

Some people got it seriously, some people were complaining about the original test saying that the TaskSpeed util is not really representative case affected by css-selecters and stuff.

So I sat down and had written my own simple test, you can get it over here. This test eliminates any unnecessary disturbances, like elements selection, gets the questionable elements building process to the minimum and creates clean, pure functionality one-on-one performance test results.

The result is predictable and actually correlates pretty closely with the original TaskSpeed based benchmarks.

Google Chrome

Firefox 3.5.6

Opera 10.10

As you can see, in a blunt, face to face performance test, RightJS does murk jQuery several times.

Get use to it.

UPD: As I'm working on the test suite, I've added the pure-dom test and also publishing results for Opera.

RightRails The RubyOnRails Plugin For RightJS

2009-11-20T12:29:00.003+02:00

In case you don't know, some time ago I started a ruby-on-rails plugin for RightJS called right-rails, which was just updated to the next version 0.3.0

There are actually quite a lot of interesting and fancy stuff going on and it tries to solve many of usual headache of ajax applications development.

Like say it transparently handling files uploading for remote forms, so that there is no difference if you have or have no files on your form. Plus there is a simple javascript interface for the most common ajax operations which is super easy in use.

Then there is a new much more powerful RJS scripting replacement, that allows you write javascript in ruby and more of that mix in one flow the serverside and browserside contexts, it has automatic types conversion and lots of other things.

Then small things like transparent Prototype/Scriptaculous helpers replacement for RightJS, plus various helpers for the RightJS own features and modules, plus automatic scripts including handler, etc. etc.

If you like RightJS and do ajax stuff in rails, check it out, you'll find many helpful stuff.

Ajax Files Uploading With RightJS And Rails

2009-09-19T09:41:00.002+03:00

I kinda stuck with the RightJS project for now and mostly write articles for the site.

But there is another interesting articles that lights up some details over the remote forms with files handling using Ruby on Rails and RightJS. There is also a link to a complete ajax photo gallery application that uses the featues.

Please take a look it is over here. I'm sure you might find some interesting stuff over there.

RightJS 1.4.0 Is Out

2009-08-15T16:10:00.002+03:00

And by the way, forgot to mention it in here yesterday. But RightJS was released yesterday with the brand new 1.4.0 version.

Mainly performance optimizations, some bug fixes and clean ups too.

Japanese Alphabet Training Machine

2009-08-15T16:04:00.002+03:00

I'm trying to teach myself some Japanese. Well, sort of.

So I've written the application Happy-Nippo that might help you to memorize the first two, hiragana and katakana Japanese alphabets.

Looks quite nice.

FrontCompiler Updates

2009-08-13T18:26:00.002+03:00

FrontCompiler is a Ruby based JavaScript compression tool of mine. And I've just updated the self-builds feature of it.

Formerly it used a literal based hashes and special markers, and I've reworked it the way it used numbers and arrays, similarly how the Base62 encryption algorithm works.

Anyway. Now both, compression and decompression processes work faster, and the result builds are slightly (3-8%) smaller.

This is pretty much it. Enjoy!

RightJS Now Rocks In IE8 Too

2009-08-09T19:34:00.003+03:00

As you probably know, the new version of RightJS is coming. I've done some optimizations in the native css-selectors support in this version and now RightJS is the fastest one in IE8 too. The only condition, it has to have a correct document definition or to be switched to the XA-Compatible mode manually.

RightJS Rocks In Firefox 3.5

2009-08-06T13:20:00.003+03:00

A newer version of RightJS is coming, it will come with some further native method optimizations and now it beats everyone in the new upcoming Firefox 3.5

HTML Code For A Close Button Icon

2009-08-01T10:29:00.003+03:00

Some people like use chars and html-codes as a default content for buttons and links. The idea is to put some simple character or code which will look like an icon, and later, if necessary, replace it with a real icon at the css-level. A "close" button is a pretty common case and people usually use the "X" character in there. The problem with it is that it has wrong dimensions and doesn't look like a normal cross on a close button. Luckily there is a better way. There is a standard html code for the mathematical multiplication symbol ×.

It looks like that

×

As you see it has the correct shape of the close symbol, and it still a normal character which you can paint with css just as you like, use hover effects, etc.

RightJS Is Faster Than Pure Dom

2009-07-25T18:49:00.003+03:00

Well, I'm cooking a new version of RightJS. I've optimized this and that, tuned here and there. And then I've run the TaskSpeed test and it looks like RightJS works faster than pure dom.

That's not a fake, seriously, I've got this result from Safari 4. jQuery has in this test 883 points.

Sure, that's because of the way the original test was written, but the result is just hilarious 8)

PS: Goin' to publish the new version in the next couple of days

Transparent Dates and Times Internationalization in Rails

2009-07-23T08:43:00.008+03:00

The basic internationalization approach in Ruby on Rails supposes that you translate the dates and times like that


Created at: <%= I18n.localize @model.created_at, :format => :short %>

But most of us use the "to_s" method to format times, like that


Created at: <%= @model.created_at.to_s :short %>

Mostly because you usually don't think much about i18n when a project is just starting up, and then it's kinda sweet, nice and short way of doing that.

So, usually when it comes to the internationalization, the project is already pretty much covered with the to_s methods. If you were lucky you might had created a single helper method which processes all the dates and times in your project and then it's simple, but if you didn't you might think about highjacking the "to_s" method of the Time class. Like that.


class Time
  def to_s(format=:default)
    I18n.localize self, :format => format
  end
end

But if you do so, you will probably broke the things. Because first of all the "to_s" method supposed to work like an alias for the "strftime" method, secondly this method is used to convert times and dates in the :db format and if it was not translated properly it will break your models, thirdly it's naughty when you completely replace such a method.

Okay here is a better way of doing that


[Date, Time, ActiveSupport::TimeWithZone].each do |klass|
  klass.instance_eval do
    define_method :to_s_with_i18n do |*args|
      format = args.first || :default
      if format.is_a?(Symbol) && format != :db
        I18n.localize(self, :format => format)
      else
        to_s_without_i18n(*args)
      end
    end
    alias_method_chain :to_s, :i18n
  end
end

It keeps the original method and doesn't touch the custom and database formats. The ActiveSupport::TimeWithZone class is the Rails class for the UTC times you need to process it too.

Inline IE hacks with SASS

2009-07-20T14:04:00.003+03:00

SASS is a nested css engine written in ruby. It's a pretty powerful and handy tool with lots of features inside, http://sass-lang.com

I'm using it on my current project and find it quite useful. The only thing which was bugging me is that I tend to use inline IE hacks in my css, like that


div.box {
  cursor: pointer;
  * cursor: hand;
}

And it seems like sass doesn't support such a feature, at least I haven't found it in their documentation.

But in reality it does actually has support of the feature, just it is not documented. It looks like that


#my-block
  :cursor pointer
  *cursor: pointer

Note, there should be no space betwen '*' sign and the property name

Customizing The Rails Forms Builder

2009-07-17T16:53:00.006+03:00

The word "customer", usually means someone who come and say "I wanna custom stuff". And because it is their nature they do it all the time. Sometimes several times a day.

I'm skipping here the obvious question "why would I need to customize a forms builder?" and get straight to the point.

So you need to customize your forms. Big time. And if the first what comes on your mind are helper methods and partial templates, this article is for you.

And please don't think about monkey patching rails form-builder. Don't behave like a php developer thinking he can use rails. Lord save their poor souls.

There are better way of doing that.

First of all you should realize that in 99.99% of cases you should not change the default rails templates. Meaningly that


<% form_for(@model) do |f| -%>
  <%= f.error_messages %>
  <p>
    <%= f.label :name %>
    <%= f.text_field :name %>
  </p>
<% end -%>

Despite that it is a simple structure, with a little bit of imagination and css magic you can make it look like anything you need.

Secondly you really should pay a dollar of penalty every time you think about monkey patching. Ruby is not just a monkey patching language it is object oriented too, and rails form builder is a quite well organized structure.

Instead of patching, we will create our own form-builder using advantages of the inheritance and then swap the default builder from the built-in to our own one. This way we can change the logic of the forms building transparently for the templates, you even can have several form-builders which behave differently and swap them depend on the context.

The basic example would look like this. You create another helper module called FormsHelper and save it along with the other helpers in your application


module FormsHelper
  def self.included(base)
    ActionView::Base.default_form_builder = CustomFormBuilder
  end

  class CustomFormBuilder < ActionView::Helpers::FormBuilder
    # your custom methods go here
  end
end

Inside the class you will have access to the form builder context with all its built in methods and variables. For the beginning you should know about the following ones

@template - the template context, you call this variable if you need to call the basic helpers

@object - the current model of the form

@object_name - the string name under which the form knows the model

Okay now lets play with the thing a little. Say the customer says "don't like the <h2> header on the error reports, the one with the number of errors on the form". No problem, we just override the built in method


  def error_messages(options={})
    super options.reverse_merge(:header_message => nil)
  end

Then say you as many other developers usually put your forms in a partial and then depends on the model state change the submit button caption. something like this


form_for(@model) do |f|
  f.submit @model.new_record? ? "Create" : "Save"

This is a little bit annoying. Say I'd like just call it <:%= f.submit %> and want the form automatically set the caption. Here is the code


def submit(caption=nil, options={})
  super(caption || @object.new_record? ? "Create" : "Save"), options
end

Then I got completely lazy and started to want my form builder to build a block of label + text-field in a single call, like this


form_for(@model) do |f|
  f.labeled_text_field :name

# this should build the thing like that
<p>
  <%= f.label :name %>
  <%= f.text_field :name %>
</p>

# you could do it like this
def labeled_text_field(name, options={})
  @template.content_tag(:p, label(name) + text_field(name, options))
end

Then, all the sudden, your customer comes back and says a scary thing "I like this, but I want for this particular controller, there actually was the h2 header saying 'Oh noooo!'. Yes, just for this special case".

No, my friend we are not going to the monkey patchers hell! We just define another form-builder over our own builder, and automatically swap it in the particular controller


class SpecialFormBuilder < CustomFormBuilder
  def error_messages(options={})
    super options.reverse_merge(:header_message => "Oh noooo!")
  end
end

class ParticularController < ApplicationController
  before_filter :swap_form_builder

  def swap_form_builder
    ActionView::Base.default_form_builder = SpecialFormBuilder
  end
end

Think you understand the idea. If you do the things in a serious way, lord will love you and grand you a big deal of flexibility and rapidness.

This is pretty much it. Have a good one!

Decimal to Hex and Hex to Decimal in JavaScript

2009-07-09T22:05:00.002+03:00

Generally JavaScript doesn't have a particular data type or class for hex values but it still provides couple of features which will let you work with hex data.

In similar to Ruby you can keep your hex values in strings and the convert them into decimal values back and forth.


var hex = 'FF';

var dec = parseInt(hex, 16); // -> 255

dec = dec + 255;

hex = dec.toString(16); // -> '1ff'

Psychic Abilities Test

2009-07-07T17:34:00.008+03:00

I've created another toy, Psych Test.

The thing is fairly simple, you've seen it lots of times in movies. You have a standard 36 playing cards deck, and one by one you are trying to guess the next card suit color. Red or black.

Well... I'm not a psychic but I know what are you thinking.

"...50%...", right?

I bet, if you ask any of your friends or colleagues who is occupied in CS, mathematics or physics you'll have the same exact answer. But the thing is not actually that simple, and here is where the fun begins.

If you open up the link above and will click on the same exact prediction button during the whole test, the result will be exactly those 50%, well +/- 1% in some unlucky situations. You might repeat the test several times, it's pretty consistent almost without any deviations.

But if you will have the same test, but will actually try to guess the next card's color, you'll have a different result, usually in range between 40 and 60%. And you almost never will have 50% again.

You should try it to believe, you can check the source code too, there is no back door. Everything is fair.

So what do you think, how is that possible? Do you think it is you actual ability to predict the future affects the result?

I could tell a spooky story about underground CIA laboratories where they study those things since 60s, and that there is a standard measurement for such tests and an exact percentage which defines you as a proven psychic.

Or, if you prefer, we could think about the problem rationally. There are just four practically independent cases and two of them correct, so the result should be close to 50% every time, no matter which button you choose. But yet it's ain't like that.

As you understand this is not the test for a psychic abilities, this is a test for rational thinking.

Okay, I'm not going to marinade you any further, as you come here and read this far I owe you an answer.

The thing is simple but not that obvious. There's no mathematical or logical problem, every time you click any of those buttons, you've got an exact 50% probability to score. But in case when you click the same button all the time, you put your guess against an almost ideal random sequence generated by the computer. And that's why you have this pretty close 50% result every time.

But when you do the "guessing", your brain follows some patterns and tries to predict the next card. Yes, generally that's a random process and every guess as good as any other, but the distribution of those guesses in time is not such good as a random distribution generated by the computer. There are fluctuations and attempts to guess, which affect the quite short 36 cards selection and gives you the non 50% result.

The first time you test the computer's random numbers generator, the second time you test your own.

Call vs. Apply

2009-07-05T18:09:00.005+03:00

Today I'm going to tell you an educational story.


var f = function() {};

var test = function(callback) {
  var time = new Date();
  (10000).times(callback);
  console.log(new Date() - time);
};

var test_with_apply = function() {
  test(function() {
    f.apply(this, [0,1,2,3,4,5,6,7,8,9]);
  });
};

var test_with_call = function() {
  test(function() {
    f.call(this, 0,1,2,3,4,5,6,7,8,9);
  });
};

(10).times(test_with_apply);
console.log('--');
(10).times(test_with_call);

The moral

Sudoku Game In JavaScript and RightJS

2009-07-02T10:01:00.004+03:00

In order to have some show off cases for my RightJS project I've written basic Sudoku Game.

Nothing really special but a quite nice implementation though. Check it out you will like it.

Sudoku Puzzle Generating, Pragmatic Way

2009-07-01T22:06:00.003+03:00

Couple of days ago I described how you could generate a good random sudoku field, today I'm going to advocate for just opposite thing. There's no controversy in really, just there are different cases, when you should and when you should not do that.

You should or could write your own sudoku puzzles generator if you are particularly interested in the field and ready to spend lots and lots of time, getting deep in all the various rules which actually make a good sudoku. Well at least it will keep your self-esteem up.

But if you are just writing some implementation of the sudoku game, you actually better not to do that. And here is why.

Sudoku generating is a random process with generally unpredictable duration. There is a good chance that your generator will get unlucky and stuck. And a hanging over application is the last thing you want your user to see.
The process of generating of a really good, hard sudoku usually takes time, sometimes a few seconds
There are lots of rules you need to get into, implement test over, and then if you are not an expert in sudoku you wont be able to check it out if you have done everything properly
You will probably forget and never use again all the knowledge you gain during the implementation. I don't want to call it a waste of time, but I'm pretty sure there are better ways to actually waste your time.
A good sudoku generator might be quite big and complicated piece of software, which will be hard to test and support.

Luckily there are better ways to do that. Use other people's work to be precise. There are lots and lots of online sudoku generators, or you could use any desktop applications, most of them cache boards in files. I used the gnome-sudoku application, it lets you generate any number of sudoku and saves them in the files in the gnome configuration directory, or you can grab my archive right here puzzles.zip

What about the number of puzzles ask you? You need some storage to keep them and have big enough collection to keep the user happy.

Actually not, and here is the trick of the article. You actually can keep just a few puzzles for each level and then generate new puzzles out of the originals. You can safely do the following things with your puzzles

Rotate them
Flip in any way
Randomly shuffle rows and columns inside the 3x3 boxes
Shuffle rows and columns of the 3x3 boxes

As the result, if you say have initially a collection out of 16 puzzles, then you can rotate and flip it in 5 ways, then you can shuffle rows and columns in 9 ways in each of the nine 3x3 boxes, and eventually you can have 9 combinations of the 3x3 blocks.

16 * 5 * 9 * 9 * 9 = 58320

That's more than enough for your user never see the same puzzle twice in a row. More of that, all of those puzzles will be really consistent by the difficulty level because initially it is just the same puzzle.

And for the end you can see a possible JavaScript implementation right here boards.js

This is pretty much it. Have a good one!

Sudoku Random Field Generator

2009-06-29T14:16:00.003+03:00

The task is simple, to fill up a 9x9 field by the sudoku game rules.

Generally it's not a rocket science and there are lots of simple solutions. For example filling up the field with shifted sequences. Say you have a sequence of numbers from 1 to 9, then you might generate a valid field like that.


1 2 3  4 5 6  7 8 9
4 5 6  7 8 9  1 2 3
7 8 9  1 2 3  4 5 6

2 3 4  5 6 7  8 9 1
5 6 7  8 9 1  2 3 4
8 9 1  2 3 4  5 6 7

3 4 5  6 7 8  9 1 2
6 7 8  9 1 2  3 4 5
9 1 2  3 4 5  6 7 8

As you see, the principle is simple, you start with your basic sequence, and then shift it by 3 positions inside 3x3 box, and by one position between the levels. The principle will still work if you start with any randomly sorted sequence of unique numbers.


3 5 6  2 7 4  1 9 8
2 7 4  1 9 8  3 5 6
1 9 8  3 5 6  2 7 4

5 6 2  7 4 1  9 8 3
7 4 1  9 8 3  5 6 2
9 8 3  5 6 2  7 4 1

6 2 7  4 1 9  8 3 5
4 1 9  8 3 5  6 2 7
8 3 5  6 2 7  4 1 9

After that you might shuffle columns and rows in scope of boxes to make the field more random, you even might shuffle the 3x3 rows and columns as well to have even better results.

But this thing is not really serious and kinda boring. The problem is that all your numbers are grouped by three numbers and those groups in different orders will appear all over the field. And this might be used for cheating. Say you open one of the sequences 4 1 9 and then wherever you open any of those three numbers you immediately know the numbers next to it.

Well for smarty pants like you and me, we need something different, something bigger, better and more bad ass.

After several coups of coffee I've come to the following algorithm.

1. We generate our field row by row
2. For each cell in a row, depends on the other existing numbers in the 3x3 box or the column, we generate a list of options
3. Out of the list of options for each cell we randomly select a value
3.1 When we convert a list of the options into a row we watch for intersections with other options and choose the most optimal collection

For example we have the following thing


1 5 6  9 8 7  4 3 2
9 2 3  4 6 5  8 7 1
8 7 4  3 1 2  6 9 5

4 9 7  6 3 1  5 2 8
5 3 2  7 4 8  1 6 9
? ? ?  ? ? ?  ? ? ?
----------------------
The options will be following

6 1 1  2 2 9  3 4 3
  6 8  5 5    7   4
  8      9        7

----------------------
Out of the options we might create sequences

6 1 8  2 5 9  7 4 3 
6 8 1  5 2 9  4 7 3
......

This way we will have no patterns and truly random valid sudoku field.

The only problem is that it is not exactly working.

As it's a random process, for each valid field there will be about 5-10 cases when there will be no ability to create a correct sequence. But despite the "not exactly" prefix, the algorithm is actually working and creates beautiful truly random fields.

And then you have a choice. Think about the algorithm by yourself and try to make it work every time, or you can make your computer think through the algorithm several times until a fully covered field will pop up.

Yes, I know, for a piece of software it sounds cheesy, but in reality there are not much calculations in the algorithm and make it running 5-10 times is not a big deal, it takes just a few milliseconds in javascript. Besides, if you need a speed, you can always cache the fields and shuffle them later as you shuffle the fields generated by patterns.

And for the grand finale here is a possible solution in JavaScript + RightJS


....
  // generates randomly distributed field
  generateGrid: function() {
    var numbers = '123456789'.split('').map('toInt');
    var matrix  = numbers.map(function() { return []; });
    
    for (var x=0; x < 9; x++) {
      var options = [];
      
      for (var y=0; y < 9; y++) {
        var col_numbers = numbers.map(function(i) { return matrix[i-1][y]; });
        var box_numbers = numbers.map(function(i) {
          var box_x = (x/3).floor() * 3 + ((i-1) % 3);
          var box_y = (y/3).floor() * 3 + ((i-1)/3).floor();
          
          return matrix[box_x][box_y];
        });
        
        options.push(numbers.without.apply(numbers, col_numbers.concat(box_numbers)));
      }
      
      matrix[x] = this.sequenceFromOptions(options);
      
      // drop and start over if there sequence was damaged
      if (matrix[x].compact().length < 9)
        return this.generateGrid();
    }
    
    return matrix;
  },
  
  sequenceFromOptions: function(options) {
    for (var i=0; i < 9; i++) {
      this.cleanOptions(options);
      
      options[i] = [options[i].random()];
      for (var j=i+1; j < 9; j++) {
        options[j] = options[j].without(options[i][0]);
      }
    }
    
    return options.map('first');
  },
  
  cleanOptions: function(options) {
    for (var i=0; i < 9; i++) {
      if (options[i].length == 1) {
        for (var j=0; j < 9; j++) {
          options[j] = options[j].length == 1 ? options[j] : options[j].without(options[i][0]);
        }
      }
    }
  }
....

How Not To Create Rails Plugin

2009-06-20T19:22:00.003+03:00

Another day I needed to handle some task which included communication with a SPARQL service. Quick google search gave me a reference to the ActiveRDF project, which claims to be the thing for ruby and rails.

But the thing is that the darn thing ain't work. As the matter of fact, you won't be able even run the example from the official site. I'm not complying, used the python sparql-wrapper to accomplish the task, but this project is a good example how you should not create a Rails plugin.

And here some tips and lessons you can learn out of it.

1. Location and Versioning Control System

The project was started at the https://launchpad.net service, under the bazaar versioning control system. That's probably a progressive thinking, but still a big mistake.

All the Rails crowd currently, more or less lives on git and github. The reason is obvious, all the people in one place, it is easy to participate in the projects using quick forking and merging. No need to register and set up your account. You do it once and have them all.

I had some experience with launchpad, it's a pretty good system, and if I would start some specific project for Ubuntu, I would probably thought about launchpad, but for Rails related project, if you want the people to participate you should go to github.

2. Implementation

The implementation as well a good example how not to write ruby code.

First of all when you creating an actual plugin or gem, global classes is the last thing which you should do. There should be the only one global name and this is the name of your project. All the rest of the things should be under the namespace.

The second is the API and what the users need to write in order to make it working in their application. With such a beautiful and powerful language as Ruby is, it is quite a shame to make people call the factory method directly. None of the actual rails part do that. There so much opportunities for all the meta-programming magic and you end up calling classes creation manually.

They should do it simultaneously to the existing things, like ActiveRecord or ActiveResource. As the matter of fact they probably should not start a standalone project in the first place and create some extension for the ActiveRecource project, they might make it to the rails codebase and that's huge. Much better than having another rails plugin.

But anyway, with a badly structured project, even if someone would like to participate and help it, that would be really hard and usually almost impossible to change anything, because there are already people who use the project as is, and people don't like to update their application code.

3. Support

I don't think I should mention such basic things, that when you have year and a half old bugs in your bug-tracker, even bugs where people already posted solutions and patches and you still didn't fix the problem, that's quite suck. As well as I should not mention such simple thing like keeping your code actually working, at least with the examples you have got on the front page.

The thing is that despite the fact that you are creating an open-source project and by the license you are not responsible for anything, you actually creating a project for people. Yes I know 90% of OOS just show-off projects by rookies just out of the university. But if you want the people to take you seriously you should support your projects.

Even if you don't want to work on the project anymore and there are no one else, you probably should say something, like "sorry guys the thing didn't fly and I have better things to do". Yes that suck, but that's understandable, and responsible.

If you didn't do that, people will still come and kill their time with your buggy code and will be left pretty much alone. You should warn your customers about such things, because everyone has different situations, someone probably would be happy to spend some hours to make a dead thing walking, but someone might be on a deadline and would expect your project actually working and probably would switch to something else if was warned.

The End

So the thing is simple. Bad location, bad implementation and bad support. This is more than enough to kill almost any project in any area. Think about it when you start your own.

RightJS The First Public Version

2009-06-18T10:13:00.003+03:00

After months and months of hesitations and struggling against my own perfectionistic habits I've eventually released the first version of my javascript library called RightJS.

Basically it's the fastest and compactest JavaScript framework at the day. And the coolest one too. Sure.

Well... Whatever. I wish the thing a long happy live and lots of ass-kicking experience.

Amen.

http://rightjs.org

Dynamic IFrames As Form Targets

2009-06-12T16:37:00.007+03:00

Sometimes you need to submit a form through some hidden iframe, usually when you're trying to monkey an ajax request for a file uploading.

Usually you just render an iframe element along with the form in the html code and assign the target attribute of the form. Something like this


<form target="my-iframe">.....</form>
<iframe name="my-iframe"></iframe>

It works, but in cases when you try do the same thing dynamically with javascript. Say to wire some additional fancy callbacks or something. Say like that.


var iframe = document.createElement('iframe');
document.body.appendChild(iframe);
iframe.id = iframe.name = 'my-iframe';
window['my-iframe'].onload = function() {...};

var form = document.getElementById('my-form');
form.target = iframe.id;
form.submit();

This thing looks generally correct, but unfortunately won't work.

I'm not sure why, but I do know the way how to deal with it.

The trick is simple, dirty and cross-browsing. Just how we like it.


var div = document.createElement('div');
document.body.appendChild(div);
div.innerHTML = '<iframe id="my-iframe" name="my-iframe"></iframe>';
var iframe = document.getElementById('my-iframe');
iframe.addEventListener('load', function() {....}, false);
// or for IE
iframe.attachEvent('onload', function() {....});

var form = document.getElementById('my-form');
form.target = iframe.id;
form.submit();

This thing is perfectly works in all the modern browsers and old IEs.

And for the end, there is even better way. Try the new RightJS framework. Then the same thing will look like this.


$('my-form').send();

This is pretty much it. Have a good one.

Filenames Encoding Conversion Under Linux

2009-06-09T12:21:00.002+03:00

If you need to mass-convert filenames from one encoding to another, say you are migrating from one distro to another and need to move the legacy data, you can do that with the convmv util.


# apt-get install convmv
# convmv -f cp1251 -t utf8 -r --notest /dir/name

Integers To Binary Or Hex Conversion In Ruby

2009-06-09T12:12:00.004+03:00

There are some tips on how you convert integers to binary or hex numbers forth and backwards.


irb(main):019:0> 30.to_s(2)
=> "11110"
irb(main):020:0> 30.to_s(10)
=> "30"
irb(main):021:0> 30.to_s(16)
=> "1e"

irb(main):027:0> '11110'.to_i(2)
=> 30
irb(main):028:0> '30'.to_i(10)
=> 30
irb(main):029:0> '1e'.to_i(16)
=> 30

RightJS Visual Effects

2009-06-02T16:52:00.002+03:00

Continuing having fun with RightJS. I've just published some basic visual effects library on the official site and created some simple playground where you can try this and that. Check it out, there are some fancy stuff.

http://rightjs.org/fx-demo

RightJS Updates

2009-05-31T21:11:00.002+03:00

There was some updates on the RightJS project. It moved to it's own github account, IE6 benchmarks were added and I'm working on some basic visual effects library for the framework. It does lots of fancy stuff and weight just 5k extra. Kinda sweet.

RightJS Kicks The Butts

2009-05-26T08:22:00.002+03:00

RightJS, on the start was real fast on the WebKit browsers and just above average on other browsers. The difference is that on WebKit browsers it was using the native css-selectors. But after an optimization session on the RightJS manual css-selectors, now we can proudly say, that RightJS kicks all the other frameworks on almost any browser and any conditions.

Check it out on the page RightJS Benchmarks, there are tests for all the modern browsers, including IE and Opera. There's no test results for IE6 yet, because it has some memory leaking issues which were not fixed yet and slows the browser down. But rest of the results looks cool

Meet RightJS

2009-05-20T10:18:00.002+03:00

I would not consider it like an official start, but say we are rolling out and so I started the official site for my RightJS prject. Right here.

http://rightjs.org

Being Pragmatic about Agility

2009-05-14T04:27:00.003+03:00

There is a book appeared recently called "Pragmatic Career" and there was a sentence in its annotation saying "when I started to look at my life throw the glasses of agility I started to see agile patterns just everywhere". Ok, that probably not the exact quote but the point is that some people getting the agility too far. They start to worship it almost as a religion and sure see its deeds just everywhere.

Don't get me wrong I'm not against agility and this is not another crapy article a la "agility sucks, I hate it". Nope, agile approach is a wonderful tool and I use it every day and pretty much happy with that. My point is that the agile approach is just a tool, you should use it wisely and be critical about it.

Agile approach works pretty well if you are an experienced developer, a ninja who knows how to give a good punch from almost any position. You don't plan too much, be flexible and if the things go a wrong way, you just adjust. It reduces the entry level, gives you ability to try this and that and see how is it going, etc., etc. You take all the advantages of the technique.

But when you are young, have a lack of experience and good habits, it might lead you to a wrong path. Because of it nature, people quite often start practicing the "shoot first think later" approach. They write crap and hope they will fix it later, don't write tests and documentation. They think that they are agile because they produce a lot of code and kinda buggy features which they gonna make better later. But in reality they go in circles over and over, and eventually spent an ugly amount of time.

Agile approach is not about creating crap now and make it better later, it's not about skip all the things you are too lazy to do or just don't know how to do. As the matter of fact, the original "Pragmatic Programmers" book in one of its tenants says directly opposite "Don't live with broken windows". More of that, any normal professional in any area will tell you the main rule of being effective "Do the things once and only once". If you need to get back and fix your solutions, you are just killing time.

Agility is all about flexibility and rapidness. It is a contradiction to the old fashioned heavy planning approach, a tool which lets avoid painful situations when you at the finish line and realize that you have not what you needed. With agile approach you do small steps, but it doesn't cancel the idea that you should do your steps right. You do small steps but each step should be done in a good way. If you rush to the end target, skipping steps and taking all the possible shortcuts, move by an unpredictable trajectory, at the end you will have something as much painful as if you was sticking to some wrong plan.

And the problem actually, the problem is in ourselves, it is in our brains, in the way it works. The mother nature designs the things the way they were working in the most effective way, consuming as less energy as possible, that's the matter of surviving, and our brains are not an exception. Instead of careful thinking, we tend to jump to conclusions based on our experience, on the things we believe. That's kind of solutions caching mechanism. And the agile approach fits it like a glove, you just make rapid decisions based on current situation and your guts and move forward.

The problem is that if you have right solutions in your cache/experience, you are good, but if you don't you'll go through all the problems and become one big pain in the butt, for yourself, for your colleagues and eventually for your customer.

And here we come to the sake of "evil" old planning.

Planning is getting evil almost the same way as anything else getting evil, including agile approach. When you overuse it. The sake of planning is that it lets you make the reality check, think critically, review your experience cache. You write some simple roadmap and ask yourself a question "How do I know what I know?". It lets you filter out problematic cases, make you aware about problems before you meet them. That's the way to make your brain actually work, not just return some first thing out of the cache.

The bottom line.

I think you've got the idea. Sometimes you should ask yourself what are you actually practicing when you are practicing an agile development? Don't you feel like going circles, getting back and fix the things all the time? How do you know about the decisions you made? Don't you call something useless just because you too lazy or just don't really know how to use it? If you have any hesitations, it's okay to stop, sit down and think about the things for 20 minutes, do some reality check, maybe even take a good old pencil and piece of paper and write down some short plan.

This will make you actually think about the things, which will make you better, and better you will produce a better work.

Who's Your Daddy?

2009-05-11T11:47:00.002+03:00

There's a pet project of mine called "RightJS". Yup as you can see it from the name it's yet another javascript framework. Well kinda. At the moment it provides most of the useful features of Prototype, salted with some features from dojo and spiced with features from jQuery and MooTools. It weights just 28k and wether you know passes the taskspeed test just like that.

There's the test source http://github.com/MadRabbit/taskspeed .

Okay, okay. Don't hold your breath. It's just in WebKit. In FF it's faster than Prototype at about 20% and still slightly faster than jQuery. In Opera it about same speed as jQuery and a little bit slower than Prototype. In IE... Well... Who uses that obsolete browser anyway?

PS: I would not believe tests result for jQuery on the benchmark, case when Prototype and RightJS were honestly loaded with elements building, updating etc. But as jQuery does not have this functionality, tests for it just feed the results with strings of already created html. Kinda cheating, you know.

One Image Round Corners

2009-04-27T16:59:00.005+03:00

I'd like to share with you some fancy idea how you make easily maintainable css-based round corners on your pages. It's quite a common feature those days and if you don't know how to do that it might be quite a headache.

The Idea

The idea is pretty simple. You create an image which contains all four of your box corners. Usually it's just a small circle or a ring. Something like that.

Then you create an html-tags structure, like this.


<div class="box">
  <div class="corners top"><div class="left"></div><div class="right"></div></div>
  
  <div class="data">
    Your text goes here
  </div>
  
  <div class="corners bottom"><div class="left"></div><div class="right"></div></div>
</div>

It is not necessary to have the middle div.data, but it will provide you move flexibility for css-alterations in future, so you'd better have it in there.

And eventually you write some piece of css-code.


div.box {
  padding: 8px;
}
div.box div.corners div {
  height: 8px;
  width: 8px;
  position: relative;
  float: left;
  margin-top: -8px;
  margin-left: -8px;
  margin-right: -8px;
  background: url('corners_image.gif') no-repeat 0 0;
}
div.box div.bottom div { margin-top: 0; }
div.box div.corners div.right {
  float: right;
  background-position: 100% 100%;
}
div.box div.top div.right     { background-position: 100% 0; }
div.box div.bottom div.left   { background-position: 0 100%; }

The stylesheet uses the images shading technique and displays a quoter of the image for each corner, so the pixel sizes in style definition should be equal to a quoter of your corners image. And the box by itself has some nice padding of the same size, so the box was looking visually correct and fit the corners.

This is pretty much it.

Why Do It Like That?

Well. There are several reasons.

a) It gets down the number of server requests to the server. For such tiny images, the actual loading time is the time of request and response to the server. So making it one image instead of four you make your page loading faster and don't bother your server.

b) When you have one image, you don't need to deal with each corner separately, you can unify and compact the styles, and then if you need, you can replace all the corners really easy but replacing just one image. It provides you really good flexibility in terms of css-based design. Take a look in here One Image Corners Example, I've created some demo for you. See how it's easy alterable for various cases. You just change the background color and image url and have another box ready to go.

c) With such approach in most cases your boxes will be still looking consistent if there is some problem with the image loading. User doesn't see unprofessionally looking cases when you have four separated images and one of them was lost or just when they are getting loading one by one. With one image the user will have all the corners at once, and if the image was lost, he will still see appropriate looking box on the page.

PS: If you need transparent backgrounds at the outer angles of the corners, you can have them on the same exact tags structure, but you will need some additional mambo jumbo in your stylesheet, which I didn't intend to cover in the article. But in 99.9% of good modern designs you won't need that anyway.

PPS: This certain css example does not work correctly on IE6, although it is entirely possible to make it working there, just I don't want to spend my free time on that zombie. If you need to support it you just put some additional adjustments into you css file with IE patches.

FrontCompiler Updates

2009-04-05T06:47:00.002+03:00

Finally I've found some time and implemented a new feature for the FrontCompiler project.

This feature compresses your javascript code by using the tokens dictionary mechanism and then create another javascript which will recompose your original javascript code on the users browser.

Reconstruction happens pretty quick, almost unnoticeable. And this gives you extra 20-40% of compression over the usual front-compiler compression, which as we all know is already better than the YUI compressor's.

Say the latest Prototype v1.6.0.3 was compressed from 138 kB to 59 kB. MooTools was compressed from 98k to 50k, etc.

You can grab the latest, already compressed files here http://stcamp.net/share/prototype/

Try it, it's just awesome!

MySql CaseSensitive Select Trick

2009-03-06T04:06:00.003+02:00

By the default, mysql compares the strings case insensitively


INSERT INTO users (email) VALUES ('some@email.com');
INSERT INTO users (email) VALUES ('SoMe@EmAiL.cOm');

--- The following two selects both will return two records

SELECT * FROM users WHERE email = 'some@email.com';
SELECT * FROM users WHERE email = 'SoMe@EmAiL.cOm';

--- Even LIKE select will return the same two records

SELECT * FROM users WHERE email LIKE 'SoMe@EmAiL.cOm';

But there's a trick how you can run a case sensitive select on mysql, you should use the binary comparison for the strings like this.


SELECT * FROM users WHERE email LIKE BINARY 'some@email.com';
SELECT * FROM users WHERE email LIKE BINARY 'SoMe@EmAiL.cOm';

The first select will return the first record only, the second will return the second one.

Mommy Look, new Plugin!

2008-11-22T15:45:00.003+02:00

I've launched new simple plugin for Rails/ActiveRecord.

This one extends the belongs_to associations between models and allows you to assign related units by one (or several) fields for the model. Say you have got a message which belongs to a user, and you would like to assign the user to the message by his login name. That's our case. Use the plugin and everything will be fine! 8)

http://github.com/MadRabbit/assign_by/tree/master

SearchableBy, the ActiveRecord plugin

2008-11-06T00:50:00.002+02:00

I've created some simple plugin for Rails/ActiveRecord, which you can use for search methods definitions.

It is a simple stuff which just creates some named_scopes which you case use as various search methods.

Take a look at the README file at the repository http://github.com/MadRabbit/searchable_by there are some examples.

Writting own Form Helper for Rails

2008-10-10T17:21:00.012+03:00

The plot of the story is following. Say I've got some simple models, like


Country
 - name

City
 - name
 - country

Customer
 - city

A city belongs to a country and a customer belongs to a city. And then on the customer form I would like to have a select box of cities with selection groups by country.

Well, that's not a problem, we can do that.


<%= select_tag "user[city_id]",
      option_groups_from_collection_for_select(
        Country.all, :cities, :name, :id, :name, @user.city_id
      ), :id => "user_city_id" %>

Not pretty but works. But then we add another unit


Office
 - name
 - city

Customer
 - office

Now each customer belongs to an office, and we would like to write another drop-down list with groups on the customer's form.

We have already got some not-pretty stuff on the form. So, what you gonna do about that?

Obviously we should wrap this puppy up.
How?
Well, that's the question.

Certainly we can write yet another method in our helpers, and be happy, but I would like to be not just happy, but feel myself kinda sexy as well. So, I would like to write it in such a way that it was look like a standard form-element. Like that.


<%= f.grouped_collection_select :city_id, Country.all, :cities %>
<%= f.grouped_collection_select :office_id, Countries.all, :offices %>

How can we achieve such a beauty?
Simple.
You just need to know some simple things.

First of all, you should know about the existence of the class ActionView::Helpers::FormBuilder. This class is the class which instance you use in the forms building with rails. And that's the class we are going to extend.

The second thing you should know is the existence of the instance variables of the FormBuilder class, which you can use when you are building your own methods

@template - this is a reference to the current template processing object. Each helper method you call in your templates can be called as the variable method inside the FormBuilder class.
@object - a reference to the current model instance which the form covers.
@object_name - the name of the model variable you use to build your form.

The third thing you should know is how to extend classes and modules on fly. Say we create a special separated helper for our new form elements.


module FormHelper
  def self.included(base)
    ActionView::Helpers::FormBuilder.instance_eval do 
      include FormBuilderMethods
    end
  end

  module FormBuilderMethods
    def grouped_collection_select(method, collection, sub_name,
            group_method="name", unit_id="id", unit_name="name")
      @template.select_tag "#{@object_name}[#{method}]",
         @template.option_groups_from_collection_for_select(
            collection, sub_name, group_method, unit_id,
            unit_name, @object.send(method)
         ), :id => "#{@object_name}_#{method}"
    end
  end
end

We define some module of ours, where new form-methods will be defined and then we include the module inside the FormBuilder class when our helper will get included to the system. And I've added some default values to the method, case my models all have uniform "name" method, so I didn't need to repeat that things over and over.

And voila, this is it. Enjoy!

Nested Styles with Ruby and FrontCompiler

2008-09-21T21:08:00.005+03:00

Nested styles is a feature which some people dream about for quite a long time. The idea is pretty simple and beautiful.

Say you have got some css like that.


div.article div.title {
  font-weight: bold;
}
div.article div.title a.author {
  padding-left: 12px;
  background: url('user.png') no-repeat left;
}
div.article div.text {
  border: 1px solid #EEE;
  background: #FEF;
}

And now imagine that you could write it with nested constructions like that.


div.article {
  div.title {
    font-weight: bold;
    
    a.author {
      padding-left: 12px;
      background: url('user.png') no-repeat left;
    }
  }
  div.text {
    border: 1px solid #EEE;
    background: #FEF;
  }
}

See the difference? How much more simple, clean and DRYish your css could be! Unfortunately current browsers don't support such things. At lest not yet.

So, does anybody want to sit down and wait for the future coming?

No, say 'no', you don't need tell such terrible things, because we have added the feature emulation in the FrontCompiler project. Which is a JavaScript/CSS/HTML processor written in Ruby and which can be used as a Rails plugin.

From now one, each time when you process a css file with FrontCompiler, it will automatically convert your nested styles in the way browsers can understand. So you can easily and safe use the nested styles advantages.

Have fun!

FrontCompiler Update

2008-09-15T20:51:00.002+03:00

I have updated the JavaScript part of the the presented recently FrontCompiler. I've improved the compression algorithm, got rid of some old bugs, rewritten the code in a more clear way and made it work several times faster.

So now, it's better, faster, cooler, nicer, whatever.

And I have compressed the Prototype / ScriptAculo stuff, with the new compressor and shared them at here.

Try it, that's nice and free! 8)

Javascript/CSS/HTML Compiler in Ruby

2008-08-21T19:34:00.001+03:00

I have backed some pretty tasteful cookie in here!

Met FrontCompiler!

It's a collection of scripts which allows you to compact your JavasScript, CSS and HTML code to reduce the loading time, and it can be used with Rails/Merb/Whatever.

NOTE: in test of compacting the Prototype library the script beats famous YUI compiler on about 1 KByte.

Enjoy! 8)

The Mines Game in JavaScript

2008-08-06T10:08:00.003+03:00

I have been playing a cool javascript hacker this weekend and as the result have implemented the well known game of mines in pure JavaScript/CSS/HTML. Take a look it's pretty nice.

JSMiner Game

Ubuntu HDTV fix

2008-07-26T21:04:00.003+03:00

I had a problem with Ubuntu on my old notebook with Intel Mobile 915GM video-card. It didn't want to play hdtv files, rips and some .mkv files. It had been crashing with an insufficient resources error.

The issue is simple, the video card uses the system memory for its own purposes, and ubuntu has wrong default xorg configuration for the videocard. Add the following three lines to your /etc/X11/xorg.conf file into the Section "Device" section (search for the Driver "i810" line).


Option  "VideoRam" "65536"
Option  "CacheLines" "1980"
Option  "LinearAlloc" "32768"

This will fix the problem.

TestCase 2.0.2 is out

2008-07-22T13:08:00.004+03:00

TestCase - the kickass javascript testing framework has got new release with version 2.0.2

And I've launched the official support resource for the project, take a look, there is lot of interesting and useful stuff.

Rails + Gettext Crash Course, Part 2

2008-07-20T10:26:00.009+03:00

This is the second part of the first rails+gettext article. In this part we will take a look at some advanced points of using gettext and its bind to ruby/rails. Generally there is nothing "advanced", just say we move a little bit beyond elementary _('some text') calls.

Interface

Except the _(String) method, there are several more standard methods to define messages for gettext. Generally there are two parts of them, for singular and plural forms. The first ones take as the main argument your usual message string, the second ones two more arguments, singular form of the message, plural form of the message and an optional number which helps to determinate when it is a singular form and when it is a plural form.

Singular methods

String _(String) - the standard method as we now it. The method takes a string and returns its translated version.

String s_(String message[, String div="|"]) - this one for the cases when you need to define a scope for the message, say you have just the same message in two different context which might have different translation. So you write a string like s_('context|phrase'), your message will be splat by the divider ('|' by default) and if there is no translation the last part of it will be returned. Simple example s_('gender|sex') and s_('activity|sex'), by default both of them will return 'sex', but you may have two different translations of the word in different languages depend on the context.

String N_(String) - this one might look a little bit strange. It tells gettext to define in its base the given string as a message, but does not translate anything and returns the given string as is. Generally it does just nothing, it is a dummy method and just a marker for the gettext parser. You will be given some examples of its usage below.

Plural methods

n_(String msg, String msg_plural, Integer number) - this one is same as _(String) but for the plural cases. The first argument is a singular version of the message the second is the plural version of the message. And the last argument the current lets call it plurality marker by which gettext will define which message use. NOTE: despite that you pass here only two messages, when you translate your .po files you may define several (more than two) translations of the messages which will depend on the plurality marker.

ns_(String msg, String msg_plural, Integer number[, String div='|']) - same as s_(String[, div]) but for plural forms

Nn_(String msg, String msg_plural) - same as the N_(String) method but for plural forms

That's all about the message definition methods.

Models Internationalization

GetText by default has all the standard error messages translations for most of the languages inside the package. And the parser will automatically define translations for your model fields which are in the database (meant field-names translation). So you don't need to worry about that.

But sure you have got your special cases and you can follow the next instructions. Say the usual case, a user model where you have got some virtual fields


class User < ActiveRecord::Base
  has_one :profile
  has_many :comments

  attr_accessor :password, :password_confirmation
  
  # we can define the virtual fields translation like that
  N_("User|Profile")
  N_("User|Comments")
  N_("User|Password")
  N_("User|Password confirmation")

  # we can create custom error-messages in this way
  validates_uniqueness_of :login, :message => N_('The login-name is already taken')

  def validate
    errors.add("password", _("%{fn} is wrong!")) unless password == password_confirmation
  end
end

As you see we have used the method N_(String) for class initialisation calls and the method _(String) inside the custom validation method. The point is simple, in the first case you don't really need the translation result, you just need to define some messages and the second case works in runtime so you need an already translated version of the message.

And another moment, we have used the 'User|' prefix in the field name definitions, this is to determinate in the translation which model the field name belongs, so you could have different translations of the field names for different models. By default it will be splat by '|' and the last token will be taken.

If you don't want to translate some particular field names, you may define to skip them by calling the untranslate(*names) method like that


class User < ActiveRecord::Base
  untranslate :login, :email
  # or
  untranslate_all
end

Templates Internationalization

In most cases of templates internationalization you just use the standard gettext methods, like <%= _('Some label text') %>, but there is another way.

Sometime templates contain lots of text with big descriptions, so it is more comfortable to have another template file special for a particular language rather than put big pieces of text in the _(String) function. It is simple, just create another file next to existing one but with a name which have a suffix named after the locale you want. For example


app/views/pages/
  about.html.erb
  about_de_DE.html.erb
  about_ru.html.erb

If the current locale is 'ru', then the about_ru.html.erb file will be used, if there is no matching file, the default about.html.erb file will be used.

Language Switching Tactics

And at the end some points about the language switching tactic. If you are experienced developer you probably do not need this part, but I would like to spell some words about it.

The best way here I think is to follow the general ideology, separate parameter variables and the urls formatting, just as you do with say same ID parameter. A good solution would be define a parameter name which will point to the desired language, say params[:lang], then as I showed in the previous article, you can use it in your application controller to switch the locale by a before filter.


class ApplicationController < ActionController::Base
  init_gettext 'my_site'

  before_filter :define_language

  def define_language
    case params[:lang]
      when 'fr': set_locale 'fr_FR'
      when 'ru': set_locale 'ru_RU'
      else       set_locale 'en_EN'
    end
  end
end

and then you left some options for youself how present it at your urls. You may use a simplest way like and left the gings as is


/articles/show/1             <- English
/articles/show/1?lang=fr     <- French

or you can handle the language by routes so your pages were more caching friendly


map.connect ':controller/:action/:id'
  
map.connect ':lang/:controller/:action/:id',
  :requirements => {
    :lang => /(ru|de|fr)/
  }, :lang => nil

----
/articles/show/1     <- English
/fr/articles/show/1  <- French

or later you may handle them by subdomains or something like that, whatever you choose your application code will not need changes.

--

Okay, think that is all what I had to say about using gettext with rails. Good luck!

Rails + Gettext Crash Course, Part 1

2008-07-18T18:16:00.011+03:00

This article is a short guide to how use gettext with ruby-on-rails. If you do not know gettext is the standard internationalisation (i18n) library of the GNU project http://en.wikipedia.org/wiki/Gettext. And this is the first part of the two articles. The second one might be found here.

Since there are some of i18n plugins for rails why should you chose gettext?

For some reasons.

First as I said it is the standard for GNU. Standard means wide support several tools to work with it, optimisation, documentation, etc. Most of Linux programmes use gettext.

Second, one of the key features of gettext is ability to use real, correct strings. You don't write strange keys in your code, you just put usual English phrases instead, like that


<p><%= _('Some text here') %></p>
<p><%= _('Length: <i>(%{min} min)</i>') % { :min => @min_chars } %></p>

As you see this allows you easily use any placeholders or html formatting tags in here if you need so. Another point for gettext is that you don't have to keep in mind the translation issues during the development time. You just put your text as nothing happened and always have a default translation with normal usual looking strings.

After you have done with the development you can parse out all the strings which need to be translated with special util. You will have standard formed .po file which you can then translate with some special programs, where you can use spellchecking versioning and all the civilize life advantages.

Third, this stuff can do lots of things, localize numbers, dates, currencies, work with pluralization on native languages and so one. Take a look at the official site for getting more information http://www.gnu.org/software/gettext/gettext.html

So how do we use the stuff with rails?

Quite simple.

First of all you need to install gettext by itself and rubysupport aka gem. Installation of gettext depends on your platform. With linux it's pretty simple. Say something like


# emerge gettext
or
# apt-get install gettext

Once you have installed gettext support, you need to install the gettext gem.


# gem install gettext

After it is done, you need to include it into config/environment.rb file of your rails project.


require 'gettext/rails'

After this you can start develop your project and use the _('text') constructions where you need to put some text.

If you are using Rails 2.1, there's a bug which have not fixed yet. But you can easily fix it by saving the following code into a file config/initializers/gettext.rb


# the gettext missed method fix
module ActionView
  class Base
    delegate :file_exists?, :to => :finder unless respond_to?(:file_exists?)
  end
end

Once you have done with the development and want to create some translation you need to do some preparations.

First you need to add two simple tasks to your Rakefile.


require 'gettext/utils'
desc "Update pot/po files to match new version."
task :updatepo do
  GetText.update_pofiles(
    "my_site",
    Dir.glob("{app,lib}/**/*.{rb,rhtml,erb,rjs}"),
    "my_site version"
  )
end

desc "Create mo-files for L10n"
task :makemo do
  GetText.create_mofiles(true, "po", "locale")
end

The first one will scan though your source code and parse out all the strings which need to be translated and put them all into a .po file. The second one will compile all your translations into a standard .mo files which gettext can use.

So, you say 'rake updatepo' in your console and this will create for you the file named 'po/my_site.pot', this is template of your internationalisation. You copy the file in translation directories like that.


po/
  de_DE/my_site.po
  fr_FR/my_site.po
  ru_RU/my_site.po
  my_site.pot

Then you translate the .po files with one of the translation programmes, say this one http://www.poedit.net. Under Linux and KDE you can use standard KBabel programme, or under Gnome you can use the gtrasnlator project. Certainly you can edit those files just as plain text if you like so. Many texteditors support them.

Once you have done with the translation, run the 'rake makemo' task in your console and it will create the 'locale' directory in your rails project folder with a standard structure like that


locale/
  de_DE/LC_MESSAGES/my_site.mo
  fr_FR/LC_MESSAGES/my_site.mo
  ru_RU/LC_MESSAGES/my_site.mo

This is almost it. You only need to initiate it in your application controller now.


class ApplicationController < ActionController::Base
  GetText.locale = 'en_EN' # <- default locale
  init_gettext 'my_site'

  before_filter :define_language

  def define_language
    # here you can switch the locale on fly
    # say like that

    case params[:lang]
      when 'de': set_locale 'de_DE'
      when 'fr': set_locale 'fr_FR'
      when 'ru': set_locale 'ru_RU'
      else       set_locale 'en_EN'
    end
  end
end

As you see we have used non existing locale 'en_EN', if there is no some locale your default strings from the source code will be used. So you always have a fallback language.

This is pretty much it for the start.

But remember with gettext you not only put some translated text-labels in your application, you easily can create translations of whole template files, you can translate models, values, format numbers, dates and do lot of another useful things.

TestCase 2.0 is out

2008-07-03T09:38:00.002+03:00

After several month of development, finally I have released the tool version 2.0

There is the release notes and short changelog

Download page

And now you can watch the project's demo

Making Quicktime work in Ubuntu

2008-06-28T10:43:00.004+03:00

There is a common issue with quicktime videostreams under linux. So this is a simple trick how you can make it working under the Ubuntu linux.

1) Uninstall all the video plugins you have got with your firefox installation (for example the vlc plugin)

2) Install the mplayer package and the quicktime extentions for it.

3) Install the mozilla-mplayer plugin

4) Reinstall firefox.

That's it. Go to apple.com/trailers, it should get working now

JavaScript Diff Function Implementation

2008-06-16T15:55:00.004+03:00

Since I have not ever done it before, I have found it was not obvious to me how to create a lists diff function in JavaScript, so I feel like should public the solution.


function diff(first, second) {
  var diff = [], start_k = 0;
    
  // calculating the diff
  for (var i=0; i < first.length; i++) {
    var same_found = false;
    var pluses = [];
    for (var k=start_k; k < second.length; k++) {
      if (first[i] == second[k]) {
        same_found = second[k];
        start_k = k+1;
        break;
      } else {
        pluses.push(second[k]);
      }
    }
    if (same_found) {
      for (var j=0; j < pluses.length; j++) {
        diff.push({plus: pluses[j]});
      }
      diff.push({same: same_found});
    } else {
      diff.push({minus: first[i]});
    }
  }
  
  // pushing down the trailing elements
  for (var k=start_k; k < second.length; k++) {
    diff.push({plus: second[k]});
  }

  return diff;
};

this function will return a sequention of hashes with keys 'minus', 'plus', 'same' which represents the differences and similarities between the two incomming arrays

Tried KDE4 on Kubuntu

2008-05-14T10:55:00.005+03:00

I've been testing Kubuntu with KDE4 today and have learnt two lessons.

1) There's nothing to be eager about KDE4. I mean, seriously, the guys do a good job, but this is still the same good old kde3. Those plasma and dolphin stuffs, doesn't change much, that's like a good version of the superkaramba project, it looks nice but practically doesn't change the workflow at all. And as 99% of applications still from KDE3, if don't mention internal changes, in really you've got a new nice theme for kde.

I'm little bit disappointed, the fourth version was anounced for good couple of years ago and then been delayed several times and as the result we've got something pretty raw and almost nothing new.

Yup, that's it, there's nothing in really why you should migrate to kde4 so far.

2) The quality of kubuntu is lower then the quality of ubuntu. Sorry gus, but that's true. There are several things which works out of box in ubuntu, but doesn't work in kubuntu. Several things are left behind in order to keep the kde-purity, that left a bad feeling.

Order By Aggregations With ActiveRecord

2008-05-05T10:53:00.007+03:00

The issue is following, say you have got a classical structure in two models


class Order < ActiveRecord::Base
  has_many order_items

  def total_due
    order_items.to_a.sum(&:total_price)
  end
end

class OrderItem < ActiveRecord::Base
  belongs_to :order

  # and it has two principal fields
  # decimal :price
  # integer :quantity

  def total_price
    price * quantity
  end
end

As you see the orders don't have own total_due fields, instead of this each order can calculate the value depend on the aggregated items. So, that's cool, we follow all the good design habits and keep the things clean.

But when you retrieve/display the orders list there might be a situation when a customer would like to order the list by the total_due value. Quite a natural desire, but there's the problem, we don't have the total_due field in really. It's virtual and depend on the aggregated objects.

Yes, you may reorder the items after retrieving, manually, but if you have quite a lot of orders and use a pagination you'll get back to the problem anyway.

The example is pretty simple, but you see, there might be lots of similar situations when you have some calculations on an aggregated data and would like to order your lists depends on the virtual fields.

So, how do we handle that?

We use the :select option for the ActiveRecord find method. Usually with the option you specify a number of fields you would like to extract, to not suck up heavy ones when you don't want them. But with the same option you may specify additional fields to extract and use all the power of SQL expressions. Those new fields will be added to the instanced object temporary, you can read them but you can't save them.

In our case this might be something like that


:select => "SUM(order_items.price * order_items.quantity) as total_due"

In the case we are using the SQL function SUM, calculate the total-due for each order, and then each selected order will obtain the total_due attribute after extraction and you may use it for your sorting options.

Then, as you see we mentioned the 'order_items' column in the select option, to make it working we should add a tables join and the items grouping options. The overall instruction might look like that.


Order.find(:all,
  :select => "SUM(order_items.price * order_items.quantity) as total_due, orders.*",
  :joins => "INNER JOIN order_items ON order.id = order_items.order_id",
  :group => "order.id",
  :order => "total_due"
)

After this you will need to fix your Order model a little, to make it use the temporary field when it appears


class Order < ActiveRecord::Base
  def total_due
    self[:total_due] || order_items.to_a.sub(&:total_price)
  end
end

Yes, that looks a little bit sqlish dirty for a rails application, but then it works and does what you need.

And there's another issue with the solution. You actually cannot use the :include option with the :select option at the same time. That's usually not a big issue, just note, if you specify the :include option, your :select option won't work.

I think stories need chapters

2008-04-18T18:13:00.004+03:00

This rspec's stories stuff is quite nice, I like it. But when I'm trying to write more or less complex story it turns out to a nightmare. It's quite hard to stay on the DRY way with the stories, you always need to repeat the stuffs again and again. Even if you organize your code in good and handy steps, you'll have to repeat them in the scenarios anyway.

So, I think it would be cool to have in the stories another level aka Chapter. Think even nested chapters. I could look like that.


Story "an item live-story" do 
  Chapter "items index" do 
    Given "two items"

    Scenario "anonymous gets the index" do 
      Given "an anonymous user"
      When "he GET /items"
      Then "he should be redirected to the login_path"
    end

    Scenario "registered user gets the index" do 
      Given "a logged in user"
      When "he GET /items"
      Then "he should see the 'items/index' page"
      And "both items should be on the page"
    end

    Then "something in common happens"
  end
end

The idea is that the chapters were working like scopes for the inside subchapters and scenarios. You may specify there common givens and thens which will be applied to the internal parts. May be it could be useful to be able to attach additional steps for particular chapters.

Ajaxload - The Spinners Generator

2008-04-16T08:59:00.002+03:00

Found today the resource ajaxload.info, you can generate your custom ajaxload spinners there.

The guys did pretty well I should say. There are lots of patterns, you can choose a transparent background and custom colors.

Nice stuff.

Displaying GIT Branch Name In Your Console

2008-04-15T14:16:00.003+03:00

So, if you had been taken the gateway drug of GIT recently, then you probably feel the sake of branches and there's a little trick for you dear fellow.

Put (or change) the following stings in your ~/.bashrc file and you'll get a nice enhancement on your console prompt which will show your current git-branch when you're in a directory which is under git.


function git_branch {
  git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1) /'
}

PS1='\[\033[0;37m\][\[\033[01;36m\]\W\[\033[0;37m\]] \[\033[0;32m\]$(git_branch)\[\033[00m\]\$ '

This is quite handy when you use the branches feature actively.