Yurii Rashkovskii's Blog

While I have discovered RSpec on Rails for a while ago, I haven’t really used it yet.

But today I have moved Frontcamp tests to RSpec specifications, finally. Even without test2spec (it failed to translate my tests for some reason), transition to specs did not took too much time. I’ve accomplished it in 2-3 hours or so.

What should I say? I like it. My tests were completely bad organized before, I’ve found that I’ve missed few bugs in an implementation and I’ve found that my test aren’t covering some important aspects. And for all this, thank you, RSpec team.

To not to change my habit to type `rake’ to run tests I’ve written very simple lib/tasks/rakespec.rake:

1
2
3

task :default do
        Rake::Task["spec"].invoke
end

Also, I’m very excited about `spec -f s’ and `spec -f h’ output.

I have been warned that running tests without rails_spec_server (now it seems to be called rails_spec_runner) could be not very fast. But since I’ve found that I need to restart rails_spec_runner mostly after each rails_spec invocation (probably some bug, or may be I’m missing something), I’ve tried to run `spec’ and I’ve found its speed reasonable and acceptable.

More to report later. Anyway, my specifications are in a trunk already.

I have extracted Caches.rb from Frontcamp finally and made it available to public.

You can fetch it from Subversion repository:

svn co svn://verbdev.com/rubylibs/caches.rb/trunk caches.rb

Or you can install it as Rails plugin

ruby script/plugin install svn://verbdev.com/rubylibs/caches.rb/trunk

ruby script/plugin install -x svn://verbdev.com/rubylibs/caches.rb/trunk

Or you can install it using Gem, either download it or type something like

sudo gem install cachesrb

What is important for us in our Frontcamp projects—it is a high simplicity of web publishing with it. We’re working hard each day on it, dropping unnecessary features and inventing conventions in order to make things easy.

Yesterday we made next step on Frontcamp simplification. We’ve defined very ease naming scheme and defaults for templates.

Let me show it briefly.

(Please note that these screenshots make use of preliminary version of syntax and conventions used in Frontcamp; they are subject to change before launch)

First, we create an index page in a category named ”/” :

It’s a page that will be rendered on a ”/” request.

Then, we define template for it (message named / in a “Templates” category_):

After this, let’s define a template for Blog Entry

Then, we submit a message to Blog Entries:

Let’s see what we’re getting:

Yes, it has rendered index in / with a template for it. No more explicit templates in each page!

Let’s see how it can work for a bit more complicated structure.

Let’s define two pages in /articles:

test:

and list:

Obviously, they should be rendered with different templates:

Let’s look what Frontcamp is able to generate now:

As you can see, we’ve got two different templates. Voila!

We’re going to have a limited preview launch in October. Subscribe to get notified today!

May be somebody will find this useful.

Just few Ruby snippets written within Frontcamp project.

First, fails? It returns true if code in block raises an exception, otherwise false:

1
2
3
4
5
6
7
8

def fails?
        begin
                yield
        rescue
                return true
        end
        false
end

do_something unless fails?{ dangerous_operation } 

Second, with_accumulator. I have found lots of pieces of my code doing something like

1
2
3

output = { }
...
output 

Why don’t write a helper for this? Here you are:

1
2
3
4
5

def with_accumulator(init_value,&block)
        acc = init_value
        block.call(acc)
        acc
end

You can look for a with_accumulator example in a following third snippet, Enumerable#split_by, that splits enumerable into chunks of length N (the last chunk could be less than N):

1
2
3
4
5
6
7
8
9
10

module Enumerable
        def split_by(n)
                chunks = (self.size.to_f/n).ceil
                with_accumulator([]) do |result|
                        chunks.times do |chunk_no|
                                result.push self[chunk_no*n,n]
                        end
                end
        end
end

Here you are an example output of it:

1
2

>> [1,2,3,4,5,6,7,8].split_by 3
=> [[1, 2, 3], [4, 5, 6], [7, 8]]

Nothing complex with these snippets, but may be somebody will find them useful.

Today I will show an early preview of what Frontcamp is about.

(Please note that these screenshots make use of preliminary version of syntax and conventions used in Frontcamp; they are subject to change before launch)

First, we create an index page:

Then, we define Main template

and template for Blog Entry

Then, we submit a message to Blog Entries:

Finally, Frontcamp can automatically render the following web page:

I hope that this peek will help you to understand, what Frontcamp is for!

Subscribe to get notified about launch today!

I’ve updated Caches a bit.

invalidate_all_caches :except => :name

invalidate_all_caches :except => [:name, :name1]

Also, it seems that I’ve fixed few bugs.

It is still not tested much, but should work.

You can find it here (as always)

Awesome

No comments.

While working on Frontcamp we’ve found that we need to cache some methods.

You can find out quick hack solution there

ActiveRecord::Base.extend Caches::ClassMethods

in your config/environment.rb and you will be able to specify

caches :method_name

caches :method_name, :timeout => 2.minutes

in your models.

Default timeout is 60 seconds.

What is important is that this solution caches calls with arguments. For example, if you will make a method_name(“Hello”) call you’ll get next method_name(“Hello”) cached, but method_name(“Bye”) will not be cached.

Also you will be able to invalidate cache explicitely with invalidate_method_name_cache and invalidate_all_method_name_caches calls.

Here are you some updates.

• We’ve almost finalized developing an easy-to-learn template language. Publishing with Frontcamp should be really easy. I’d rather prefer to tease you ;) before I will show an ease of this template language. I want to keep some secrets until private beta launch.
• Now you can chat with Frontcamp authors before launch (Campfire-based).

Stay tuned!

If you are using OpenStruct to mimic some objects (like I do) and rely on object’s ID (that could be important for ActiveRecord programming, or when you’re using Basecamp.rb, for example), then you’ll find this useful:

class OpenStruct ; undef id ; end

This autumn I plan to launch one of my projects, Frontcamp. I don’t want to disclose much details of it right now, but I can say that it is a CMS for those who enjoy Basecamp.

If you’re interested to participate in a private beta launch soon, consider to register for launch notifications. If you want to be sure that you’ll be invited, consider dropping a short message to my e-mail:

Thank you in advance and let’s do interesting things!

If you need some very simple settings for your RoR model, that are stored in a serialized field, you can try my very simple solution

Basically, it sucks. But it works for simple needs. All you need is to write something like

 has_settings :login, :password, :etc

And, yeah, you need to add_column :settings. :text. Of course, I could improve my solution to let it store settings in a separate table, but I was too lazy today.

I was playing with an idea of synchronizing labeled GMail messages to Basecamp. I liked this idea. You can label your messages with your project name, or setup automatic rules for labeling and get your conversations with customers be synchronized to your Basecamp account. Nice? Definitely.

I’ve even wrote some simple code that uses GMailer library. But, first of all, it’s a kind of hack. GMail does not offer any official API except “preview” Atom feeds and POP3. First seems to be not very viable because it previews only few latest messages and, AFAIR, cutted message content. The second approach is definitely inefficient.

Second, GMailer library will be broken instantly when Google will change Gmail web interface.

Third, it seems that it is just illegal to use GMailer’s approach.

So, adding small but (as for me) useful features for such a good web application as Google is in fact rejected. I’ve found myself thinking about Premium Gmail accounts with full access API enabled. I’m ready to pay a reasonable fee for this feature.

But is it interesting for Google? I don’t know.

After I’ve received an invitation to join EC2 I got a vision of hourly subscription services.

Why do I need to pay, say, $49 monthly fee for Basecamp account that is used only 8hrs/day? Why don’t pay $16.32 for 240 hours instead? Or if it is an August dead-time, and I use my web application even less?

Paying for actually spent resources? Definitely.

Deep in thought.

P.S. EC2 still seems to be a limited preview beta, but I suppose it will be public some day?

Imagine that you have a small company and want to use Basecamp for managing your project, Blinksale or FreshBooks for invoices.

But do you like the fact that you need to keep all your information about clients in sync among two systems? I do not. And what if you will add one more system for your business? Two more systems?

Basecamp and Blinksale are known to have their own APIs. You can develop your own synchronization bot for them. Will it work for you? Most probably, yes. This approach seems to work even if you will have one more system with its own API. But is it nice? I doubt.

Is there any nicer solution for this problem? Well, unfortunately, not without owners of our favourite services.

IA-32-INSTRDB is available again after moving my blog from VERB.ORG.UA. Freshmeat links are fixed as well. Sorry for the inconvenience!