Enough is enough, i seriously don’t think i’m built to use any online blogging engines. Simply because i’m built to prefer typing in my terminal, using vim, and prefer playing with terminal-interfaced stuff, instead of so called idiot-proof online tools … i guess i’m probably more idiot than idiots.
Moreover, blogspot is blocked by the great wall of china (at least this is what i’ve encountered in shanghai), and though i can continue to access it via some customized proxy settings, it is terribly slow, slow & slow. In fact, i find it amazing that i am able to bear with it for so long …
Anyway, enough is enough, here i am, back to basics, typing my blog in vim, on the engine side, i’m using the git-based blogging engine shinmun, and deploying it at heroku …
Ha, it cannot be any easier than what i have now … what a wonderful world !!
(i'm gradually do the migration to the newer blog, as and when i find time)
{{ ty's engineering log }}
non-optimized bits & pieces of my techincal side
Thursday, August 19, 2010
Friday, August 13, 2010
Benchmarking any rake task
While writing serializable_proc, i wanted to find out how the RubyParser-based implementation fair against ParseTree-based one, here's a rake task i've written to support the following use cases:
And:
And here's the code to acheive the above:
And here's the output i get for the x2 run:
# yield benchmark results by running :spec task x5 (default)
$ rake benchmark[spec]
And:
# yield benchmark results by running :spec task x2
$ rake benchmark[spec,2]
And here's the code to acheive the above:
1 | # Benchmarking |
And here's the output i get for the x2 run:
...
(blah blah, the output of running :spec task x2)
...
===============================================
~ Benchmark Results for Task :spec ~
nth user system total real
#1 0.000000 0.000000 1.030000 1.052567
#2 0.000000 0.000000 1.020000 1.040352
===============================================
Friday, August 6, 2010
Reliably getting a formatted time string in ur desired lang
Today, i'm spent quite abit of time playing with the very simple Time#strftime:
What i want to acheive is to reliably get the chinese version:
I've tried playing with the environment variable $LANG:
Seems good, but nope, Time#strftime still gives me the same english output. I've trying recompiling a different ruby using rvm with the exported $LANG ... nope, doesn't work either. It seems that not matter how $LANG is set (thus affecting LC_TIME), ruby just doesn't care abt it. Yet, i swear that on flyhzm's machine, he has been getting the chinese version, no matter how hard he has tried to get the english version.
Battled, beaten & worn out, i've concluded that the most reliable way (and definitely what most people do), is to use the i18n. Given i already have this /path/to/i18n.yml:
The following works for mri 1.9.1:
Without modication, i got the following unfriendly output for the chinese port under mri 1.8.7, jruby & ree-1.8.7:
After much googling, stumbled across this post abt $KCODE. Here's the final modified code for the 1.8.7 equivalents:
For people doing rails, here are some useful resources:
* http://guides.rubyonrails.org/i18n.html
* http://github.com/svenfuchs/rails-i18n
1 | puts Time.now.strftime("%B %d, %Y %H:%M") |
What i want to acheive is to reliably get the chinese version:
八月 06, 2010 17:24
I've tried playing with the environment variable $LANG:
$ export LANG=zh_CN.utf8
$ locale
LANG=zh_CN.utf8
LC_CTYPE="zh_CN.utf8"
LC_NUMERIC="zh_CN.utf8"
LC_TIME="zh_CN.utf8"
LC_COLLATE="zh_CN.utf8"
LC_MONETARY="zh_CN.utf8"
LC_MESSAGES="zh_CN.utf8"
LC_PAPER="zh_CN.utf8"
LC_NAME="zh_CN.utf8"
LC_ADDRESS="zh_CN.utf8"
LC_TELEPHONE="zh_CN.utf8"
LC_MEASUREMENT="zh_CN.utf8"
LC_IDENTIFICATION="zh_CN.utf8"
LC_ALL=
Seems good, but nope, Time#strftime still gives me the same english output. I've trying recompiling a different ruby using rvm with the exported $LANG ... nope, doesn't work either. It seems that not matter how $LANG is set (thus affecting LC_TIME), ruby just doesn't care abt it. Yet, i swear that on flyhzm's machine, he has been getting the chinese version, no matter how hard he has tried to get the english version.
Battled, beaten & worn out, i've concluded that the most reliable way (and definitely what most people do), is to use the i18n. Given i already have this /path/to/i18n.yml:
1 | en: |
The following works for mri 1.9.1:
1 | require 'rubygems' |
Without modication, i got the following unfriendly output for the chinese port under mri 1.8.7, jruby & ree-1.8.7:
\345\205\253\346\234\210 06, 2010 20:27
After much googling, stumbled across this post abt $KCODE. Here's the final modified code for the 1.8.7 equivalents:
1 | require 'rubygems' |
For people doing rails, here are some useful resources:
* http://guides.rubyonrails.org/i18n.html
* http://github.com/svenfuchs/rails-i18n
Wednesday, August 4, 2010
Bitten by Array#*
Have u tried Array#* ? Its a pretty cool way to return an array, built by concatenating the original array by n times:
However, u should be aware that all elements of the new array actually points to the same instance, as proven by their object_id:
This means that:
1 | a = [1] * 2 |
However, u should be aware that all elements of the new array actually points to the same instance, as proven by their object_id:
1 | x = 'a' |
This means that:
1 | # Reassigning one element does not affect another |
Wednesday, July 28, 2010
Lazy evaluating with Enumerable#any?
Most of us know this:
For some of us who likes Enumerable#any?, this won't work:
That is because :m1 & :m2 are already evaluated before calling Enumerable#any?, to have lazy evaluation, we can do this:
For the perversive ones:
1 | class Awesome |
For some of us who likes Enumerable#any?, this won't work:
1 | # Case 2: |
That is because :m1 & :m2 are already evaluated before calling Enumerable#any?, to have lazy evaluation, we can do this:
1 | # Case 3: |
For the perversive ones:
1 | # Case 4: |
Thursday, July 22, 2010
Everyone should start writing macros
Did some cleaning & catching up of specs for railsbestpractices.com yesterday, added quite a number of spec macros to dry up stuff, as well as cutting down the complexity within the spec files. Personally, i really really & really like macros, because it is fun to write & easy to write, it has many beneficial side effects:
#1. Since it is so simple to use macros, everyone in the team is more willing to participate in spec writing. Personal experience has proven that if specs/tests are hard to write, some developers tend to skip it.
#2. Since it is so easy to read, maintenance becomes much easier
#3. Developers are smart people (and should be paid well, but that's another story), by replacing repeated copy & paste & minor edit-here-and-there with macros-writing-and-usage, they feel smarter, a huge morale boast ~> happier team, & when people are happy, they tend to show more love towards the project, take ownership ~> project in a better state.
Btw, macro writing is no rocket-science, let's get started:
#1. Macro for 3rd party declarative
Ok, we all know that authlogic is well tested, so there is really no point in writing specs for it. Yet, how do we know the model is pulling in authlogic support ?? Here's what i've done:
The usage in the spec file is:
Of course, i can probably remove the include statement altogether & do the auto-including elsewhere, but taking this route, other developers may throw WTF-is-should_act_as_authentic error ~> BAD !!
#2. Macro for project-specific declarative
I wanna make sure the support from the home-baked Markdownable is pulled in. Since it is home-baked, just making sure the module is mixed in is not good enough, i need to ensure the functionality is there as well. Thus (nested within the above mentioned RailsBestPractices::Macros::ClassMethods module):
And the usage:
#3. Macro for any other vanilla functionality
The macro definition:
Finally, the usage:
Of course, it doesn't make sense to define macro for every functionality available. The general thumb of rule is that when similar code appears more than once, u can consider defining a macro for it. However, if similar-code is to appear more than once, u will probably start by extracting the code & placing it inside a module (eg. Markdownable), so this probably falls under #2. Macro for project-specific declarative.
Last but not least, the above macro definition can probably benefit from some refactoring, but i guess i'll leave this exercise to u :]
#1. Since it is so simple to use macros, everyone in the team is more willing to participate in spec writing. Personal experience has proven that if specs/tests are hard to write, some developers tend to skip it.
#2. Since it is so easy to read, maintenance becomes much easier
#3. Developers are smart people (and should be paid well, but that's another story), by replacing repeated copy & paste & minor edit-here-and-there with macros-writing-and-usage, they feel smarter, a huge morale boast ~> happier team, & when people are happy, they tend to show more love towards the project, take ownership ~> project in a better state.
Btw, macro writing is no rocket-science, let's get started:
#1. Macro for 3rd party declarative
1 | class User < ActiveRecord::Base |
Ok, we all know that authlogic is well tested, so there is really no point in writing specs for it. Yet, how do we know the model is pulling in authlogic support ?? Here's what i've done:
1 | module RailsBestPractices |
The usage in the spec file is:
1 | describe User do |
Of course, i can probably remove the include statement altogether & do the auto-including elsewhere, but taking this route, other developers may throw WTF-is-should_act_as_authentic error ~> BAD !!
#2. Macro for project-specific declarative
1 | class Post < ActiveRecord::Base |
I wanna make sure the support from the home-baked Markdownable is pulled in. Since it is home-baked, just making sure the module is mixed in is not good enough, i need to ensure the functionality is there as well. Thus (nested within the above mentioned RailsBestPractices::Macros::ClassMethods module):
1 | def should_be_markdownable |
And the usage:
1 | describe Post do |
#3. Macro for any other vanilla functionality
1 | class Implementation < ActiveRecord::Base |
The macro definition:
1 | def should_have_user_ownership |
Finally, the usage:
1 | describe Implementation do |
Of course, it doesn't make sense to define macro for every functionality available. The general thumb of rule is that when similar code appears more than once, u can consider defining a macro for it. However, if similar-code is to appear more than once, u will probably start by extracting the code & placing it inside a module (eg. Markdownable), so this probably falls under #2. Macro for project-specific declarative.
Last but not least, the above macro definition can probably benefit from some refactoring, but i guess i'll leave this exercise to u :]
Wednesday, July 21, 2010
Relatively unknown Object#instance_exec
Do u happen to know Object#instance_eval's brother, Object#instance_exec ?? Here's a uninteresting way of coding wo Object#instance_exec:
And here's a more interesting way to do it, w Object#instance_exec:
Yet another way to do it can be:
Enjoy !!
1 | Someone = Struct.new(:name, :password) |
And here's a more interesting way to do it, w Object#instance_exec:
1 | Someone = Struct.new(:name, :password) |
Yet another way to do it can be:
1 | Someone = Struct.new(:name, :password) |
Enjoy !!
Subscribe to:
Posts (Atom)