Out with singtel’s adsl, in with m1’s cable broadband … even though my original plan is to go for fibre broadband, unfortunately opennet told me my home’s fibre termination point won’t be ready until 6mths later, i have no choice but to temporarily settle for a 6mths contract with m1’s cable broadband service.
This is dead simple, yet i never know it, till i saw the *.gemspec generated using ‘bundle gem’:
This is a quick follow-up of the original How to Test IRB Specific Support ?. If u don’t mind shelling out stuff:
Yippie, Sourcify is going to support Proc#to_source even in IRB !! Yup, many thanks to @alexch & Florian Groß’s RubyQuiz SerializableProc solution. BUT, how the hell am i supposed to test this IRB-specific support ?
Out of the box, capybara runs firefox for selenium-webdriver. It may be fun to see firefox popping up, and automating all user interaction with the browser. I would say that it is a very impressive demonstration of automated testing to non-technical people (eg. my ex-boss). BUT, it is really getting quite irritating for me, most of the time.
Ruby 1.9.* comes with Proc#source_location, which according to the documentation, returns the ruby source filename and line number containing this proc, or nil if this proc was not defined in ruby (i.e. native):
I really like my latest PS1, it shows my current:
In testing how well sourcify can handle codes in the wild, i need a way to collect all procs from the ObjectSpace, and check if Proc#to_source works as expected. Yet, JRuby’s ObjectSpace is turned off by default to avoid unnecessary creating of extra objects.
Hey, let’s build a serializable proc today !! But before we do that, let’s 1st define what is a serializable proc. A serializable proc differs from a vanilla proc in 2 ways:
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.
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:
Today, i’m spent quite abit of time playing with the very simple Time#strftime:
Have u tried Array#* ? Its a pretty cool way to return an array, built by concatenating the original array by n times:
Most of us know this:
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:
A few days back, cross-stub version 0.2.0 has been released, with this release, cross process instance method stubbing is now possible. While doing review of zan’s work, we’ve discussed the possibility of having more control on which exact instance the stub should be applied to, as illustrated below:
Do u happen to know Object#instance_eval’s brother, Object#instance_exec ?? Here’s an uninteresting way of coding wo Object#instance_exec:
In the specs suite of cross-stub, i’ve built a custom echo server using this approach to support testing of stubbing in another process. Nothing wrong with it, except that it is not so fun & clean. Anyway, over the weekend, i’ve extracted out the echo server code, and put it inside a new & fun project otaku.
In writing cross-stub, i need to write specs to ensure cross process stubbing indeed work as expected. This is achieved by building a simple server/client using eventmachine, here’s how echo_server.rb looks like: