Yurii Rashkovskii's Blog

Recently I’ve got an idea to implement as an own product, though when I’ve looked around for someone to partner on it I’ve discovered that everybody who I communicate on a regular basis are busy until… well, they really don’t know when they will be free enough to join something. But I’m quite enthusiastic kind of person, and I just can’t wait. I also believe that its very booooooring to be alone on the project (and it’s a kind of competitive disadvantage). So, I’m looking for somebody to partner with me on a product creation.

In short, this product is a combination of an issue tracker and GTD planner, something that I definitely need in my daily work. The main concept is already developed, available upon request.

The project is already at its initial stages of development. I’m trying to make its development as much fun as it is possible (I’m on edge Rails, edge RSpec, integrating RBehave, using Lilu, have no other login other than OpenID [ok, I was just lazy], follow RESTful principle, etc.)

I hope that first version could be launched within a month or so.

I’m looking for a partner that will be able to commit in various activities of a project, from A to Z, from design to marketing.

I realize that it might be silly to look for a partner this way. But one that never tries never gets desired. So let me try? :)

Short QA:

Q: Is it a job offer?
A: Nope. I’d rather offer a very fair amount of equity (something around 1/2 seems to be fair enough?)
Q: What if project will fail?
A: It might happen. Startups are a kind of gamble.
Q: Do you have a business plan?
A: Not really yet.
Q: When this project starts?
A: It has been started few days ago already.
Q: More details on a product?
A: Upon request.

Any other questions/interested to talk? Cool! Comment here or drop me a line to yrashk {at} verbdevdotcom.

P.S. This entry is cross-posted in few variations across several communities, number of friends, etc. I’m going to find out a partner shortly!

I have decided to announce some news that were happening in trunk recently.

• Major Rails helpers problem/bug was fixed (thanks to Nicholas Faiz), now error_messages_for() and friends works just fine

• I’ve extended possibilities of at() syntax, now you can do things like:

        update('#username').with text => at('a').text 

which converts

        <div id="username"><a href="#">john doe</a></div> 

to

        <div id="username">john doe</div> 

or

        update(:all,'.user/a').with text => at('..')[:id] 

which converts

        <div id="yrashk" class="user"><a href="#">username goes here</a></div> 

to

        <div id="yrashk" class="user"><a href="#">yrashk</a></div> 

The main point is that at() got some methods like (#[] and #text) and could now be used as value. Previously you was required to use lambdas for such kind of functionality.

This is quite new and experimental functionality, though I already make use of it and find it interesting.

• Now when integrated with Rails, Lilu makes use of .erb.html templates as well (if .html was not found)

  What was the reason for this? Well, quite simple. I just felt sick typing those stylesheet links, forms, ajax stuff in plain HTML. If

  you or your designers could use these little nice Rails helpers, then why not? The main thing is to understand what to use and what to not to use. Also it could be helpful for transitioning from ERB to Lilu.

  At the moment, mockup_server does not support this feature though. I think I will prepare some workaround soon (it is in progress)

I’m reorganizing my development hosting stuff, and Lilu subversion got new home.

Subversion repository is located at http://svn.verbdev.com/lilu

You can also browse it with Warehouse

Lilu’s issue tracker will probably change its address (and most likely, software) soon.

Best development practices state that you should keep your changeset comments meaningful. Comments like “another small fix” or “HTML updated” or (empty comment) aren’t very descriptive. I’ve even discovered that using ticket number (“fixes #4”) as a comment is neither good idea (it may happen that you will decouple your repository browser from issue tracker, like I did, when started using Warehouse).

Though lots of developers don’t write descriptive comments on changesets or do it rarely. I am not an exception — I have this sin, too. Some of my comments have no real sense. For years, I was lazy enough to not to read svn book or to google a bit. Now I’ve decided to spend that 10 minutes, and voila — now I can update my comments when they are already made. That’s pretty simple.

First of all, make sure you have copied repo/hooks/pre-revprop-change.tmp to repo/hooks/pre-revprop-change (or just created simple `exit 0’ sh script with this name) and made it executable.

Then you could do something like:

$ svn propset svn:log --revprop -r <REVISION> "My corrected log message" <URL> 
# or
$ svn propset svn:log --revprop -r <REVISION> -F <file-with-corrected-log-message.txt> <URL> 
# or
$ svn propedit svn:log --revprop -r <REVISION> 

If you use Warehouse, you fill find that first of all, it does not syncs it automatically, so you have to copy that post-commit hook behavior to pre-revprop-change or run it manually. Though 1.0.4 doesn’t work well with that kind of changes (it will not sync them), so you have to apply this patch

As you may know, nice Warehouse subversion browser was released recently. While being not a hosted service, it is a downloadable Rails application that is not free (per-domain license costs $30). I’ve decided to spend that money while reorganizing my VERBDEV server structure completely.

If you feel you would like to sponsor further application development, you should definitely pay guys for their job. If you expect to get absolutely stable and easily configurable application for your money, then try to wait for something more mature.

Few tips for those who have decided to try Warehouse now.

1. You can configure your Apache2 using this example (it is not perfect but it works):

<Proxy balancer://warehouse>
  # cluster member 1
  BalancerMember http://127.0.0.1:3000
  BalancerMember http://127.0.0.1:3001
</Proxy>

NameVirtualHost *:80

<VirtualHost *:80>
 ServerName svn.verbdev.com
 <Location />
              DAV svn

              # any "/foo" URL will map to a repository /var/repos/foo
              SVNParentPath /var/repos/

              # try anonymous access first, resort to real
              # authentication if necessary.
              Satisfy Any
              Require valid-user

              AuthzSVNAccessFile /var/warehouse-1.0.4/config/access.conf

              # how to authenticate a user
              AuthType Basic
              AuthName "Subversion repository" 
              AuthUserFile /var/warehouse-1.0.4/config/htpasswd.conf

 </Location>
</VirtualHost>

<VirtualHost *:80>
  ServerAdmin yrashk@verbdev.com
  ServerName dev.verbdev.com
  ServerAlias *.dev.verbdev.com
  ProxyPass / balancer://warehouse/
</VirtualHost>

2. Don’t expect that your access configuration will be delivered automatically from the very start. Pay attention to this documentation bit

3. You will need to install post-commit hooks in order to browse up-to-date repositories

4. Do not expect that it will tune your svnserve configuration. At least I haven’t found it at a brief look into. All this stuff is for subversion over http.

5. If you will experience problems running rake warehouse:build_config CONFIG=config/access.conf, try using this patch

6. You have a chance to experience some level uncertainty when adding/removing permissions: http://forum.activereload.net/forums/8/topics/154

7. You will be able to find few minor typos

As a conclusion: I’d rather buy this piece of software (and I actually did), as a kind of sponsorship for further development. If you hate rough edges, wait a bit.

I had a short discussion on a kind of “philosophic” subject recently. The issue is whether to use ActiveRecord API to manipulate model’s logic, like

@user.friendship.create(:friend => @friend)

or to define simplistic domain-specific methods, like:

@user.add_friend(@friend)

or

@friend.add_to_friends_of(@user)

While first approach has its own benefits (having strict and simple API, just like in RESTful approach), I think that it has two downsides:

1. It’s hardly readable comparing to domain-specific approach. I believe that application’s “language” should be as close to user’s dictionary and semantics. I don’t think users think about adding friends like “oh, I’d like to create friendship with that user!”, it rather sounds “I’d like to add him/her as friend” or something like that.

2. It will work quite fine until you will change your database/application structure; you will need to modify your friendship creation code everywhere. In case of using domain-specific method, you should usually end with just modifying your #add_friend/#add_to_friends_of code.

What do you think about these approaches?

As some of you (mostly those that I have met in Oslo/Copenhagen) may know, I’m going to attend RailsConf Europe in Berlin this year. Despite of the sad fact that I will not present anything on Lilu (I was too late submitting my papers), I still would like to meet with ruby hackers, talk on interesting things, arrange some short hack sessions, etc.

Though visiting RailsConf Europe is somewhat expensive, I expect it to be something like 1500-2000EURO. That’s why I’m announcing that I’m going to provide Ruby/Rails consultation services until I will earn 2000EURO (lets assume that this will be enough). My hourly rate is roughly 40-50 EURO, depending on what I will be supposed to do.

You can also fund Lilu or, say, Caches.rb futher development, there are lots of things to do still. This money will be spent on visiting RailsConf Europe as well.

If you are interested, feel free to contact me at yrashk at verbdev dot com.

Thank you in advance!

Think about your future. From “Stupid Posts” series.

Roughly 1,5 years passed after I have quit my last job. And I should say that I’m totally happy with this choice. Understanding that now you are protecting your own interests only is worth that complexity of being independent. My schedule is now quite flexible, I commit to various areas of interest (including no profit ones, like Lilu or Protonio). What is important, I have way wider choice now.

Lessons I have learnt are as follows:

• Mostly any vision of future is erroneous. Things are likely to change.
• Expectations are failing. Estimations are completely wrong :)
• Do not underprice yourself
• Choose right clients
• Try strange ideas
• Get real.

Being free is really nice. I’ve finally came to committing to my own business rather than to others.

I’ve just released Lilu 0.1.3.

IT IS NOT BACKWARD COMPATIBLE WITH 0.1.2.

The changes are:

• New sub-nodes lookup syntax

  You need to update your instructions in the following way. If you had something like:

update('#blog-entry').with :id => "blog-#{@blog.id}", 'a' => { :href => @blog.url } 

you will need to rewrite it to something like

update('#blog-entry').with :id => "blog-#{@blog.id}", at('a') => { :href => @blog.url }

or

update('#blog-entry').with 'id' => "blog-#{@blog.id}", at('a') => { 'href' => @blog.url } 

That means that now you can use both String and Symbol to refer attributes

• `self’ is deprecated in favor of `text’

  You need to update your instructions as well. If you had something like:

update('#blog-entry').with at('a') => { :href => @url, self => @title } 

you will need to rewrite it to:

update('#blog-entry').with at('a') => { :href => @url, text => @title } 

You can use Lilu either as a plugin at svn://dev.railsware.com/lilu/lilu/tags/0.1.3 or svn://dev.railsware.com/lilu/lilu/trunk (be cautious when on trunk!) or from gem (lilu, -v 0.1.3 or just the latest version).

If you need to stay on an old syntax for some reason, please use 0.1.2 (svn://dev.railsware.com/lilu/lilu/tags/0.1.3 or gem install lilu -v 0.1.2).

I’ve found that there are already some discussions about Lilu going on around on the internets so I’ve decided to launch a mailing list for it. Ok, here it is: Lilu Google Group