Yurii Rashkovskii

One Day in Toronto

Weird iPhone Application Idea

I am not sure whether it is really feasible to implement this (or at least make it work reasonably fast & accurate), but here is an idea for an iPhone app I would definitely buy:

Whenever I shop at supermarket, I would like to point my iPhone at Nutrition Information of another package (here camera gets involved), press a button to scan it and get alerted if this product is bad for me for some reason (in general, or for my diet).

It definitely should have built-in alerts presets, like "General", "Low carbohydrate diet", "Low sugar diet", etc.

Why is it weird? Well, because you can actually read this nutrition information by yourself. But wouldn't it be fun & hi-tech to scan nutrition information (though it would be easier if this information was also printed in a form of a 3d barcode or something like that).

What's wrong with DSL?

Wow. I finally bothered to get a learner's driver's license and will have my first lesson in less than 12 hours. In three years, I'll get my full license, skills-permitting.

Now, Domain Specific Languages. It looks like I finally can explain what could be wrong with them. As a part of tradition, I would like to warn you that all my thoughts posted below could be completely wrong since I am typically incompetent in whatever subject I talk and rant about.

First of all, good news. Basically, there is nothing bad with DSL. In theory. It is a pretty nice concept that could boost your development productivity, lead to less error-prone code and turn you into a real guru. Just don't get too snobby if you can use Ruby tricks or Lisp macros. 

Because here is the thing. The bad news thing. 

The bad news about DSL is that in order to design a really sustainable and useful domain specific language you should be either good at designing programming languages or just have enough stamina to rough all edges and maintain a true consistency both within created language and your host language.

So, the idea is that you can't just make up some syntax sugar over your language of choice (such as Ruby, Lisp or, say, Io). Um, well — technically, you can. But that doesn't necessarily mean you (or your colleagues) would benefit from that DSL. Heck, there is even no promise you won't be screwed by it at some point.

So, what would I advise to do (but don't take my advices too seriously)?

1. Let your DSL extension be "logically compatible" with your host language. Or, another definition is to keep it intuitive enough so other developers would easily figure out how can they use your DSL without looking into your examples every time they want to do something with it. Here is an example (Ruby, derived from a real code):

can [:read_about], User do
 user.public?
end

can [:remove], [Comment, Post], &if_matching(:created_by)

While it is a valid code I don't personally think it is a good example of DSL use. In fact, it is a DSL concept misuse to some extent. Why? In this particular example, Ruby idioms would define these statements as something like:

1. With "can read about users" do ask... user (where did it appear by the way, there is no |user| block parameter definition?) about its publicity. Hm.
2. Can remove comments and posts and use if_matching(:created_by) proc... somehow. Basically, it is way better than 1, it is just the &if_matching thing that I wouldn't expect here (I mean &proc syntax) — but basically this construct is not as bad as first one.

  

And yes, I understand that it is possible to figure out the real meaning of the above code examples by reading these examples, but that's definitely not the most intuitive way. And it is definitely not very consistent with the host language.

Clearly enough (well, I just know what this code is doing) those do blocks and &procs above are about some conditions to be met at some point.

How would I improve the above example? Well, while I am no perfect at this, I'd try to do something like this:

 can [:read_about], User, :if => proc {|user| user.public? } # or
 can [:read_about], User, :if => :public? 

 can [:remove], [Comment, Post], :if => proc {|posted| 
     posted.created_by == User.current } # or
 can [:remove], [Comment, Post], :if => matching(:created_by) 

 def matching(attribute)
 proc {|obj| obj.send(attribute) == User.current }  
 end

Why the above example could be better? Let me explain. 

1. Here we 1) use Ruby's "do something if true" idiom 2) use well-established :if notation used by other DSLs (which might not be ideal but used in lots of projects, see third section of this article) c) uses well-known Ruby's proc construct which is less likely a subject to a non-immediate execution (well, at least I feel it this way)
2. The same arguments as for 1. just some syntax sugar added on top. Literally it is a re-use of Ruby's "can read users if user.public?"  
3. The same arguments as for 1, and here we have a better control over (and better understanding!)  what we're actually checking
4. It is actually the same as 3., just sweetened with matching() helper, which is doing the same thing, just a _little_ bit more generalized :)   

  Again, as I said, my improvement might not be perfect (and it is 1AM already, omg) — but you get the idea, right?

2. Maintain your DSL consistency. Ideally you would need to be a programming language designer with an extensive experience :) But of course this is really naive to expect. So what would I advise is simply to 1) reduce a number of constructs and their variations possible 2) define each construct clearly — what's the purpose & intention, what's the expected behavior behind it 3) try to maintain a documentation. Most popular programming languages do. Why your DSL should be an exception?

3. Let DSL be at least somewhat familiar to your users. This is one of the simplest things to advise. It is definitely easier for people to use DSLs that make use of constructs they might have seen in other popular DSLs. For example, ActiveRecord's has_many/has_one are well known by all Rails programmers. And, clearly, DataMapper's "has n" syntax is flexible and awesome, but it might be somewhat surprising for those who switch to DM. While they definitely should keep this awesome syntax, why not add two aliases (has_many and has_one)? Well, may be they do, I haven't really used DM extensively yet ;) But again, you get the point, right?

4. Keep number of DSLs per project to a minimum. It might be a nightmare to have logically different DSLs for all this stuff: ORM, permissions, views, factories, controllers, specs, RESTful goodness... all 13 of them. Just don't overuse something just because you can. 

Pheew, I did it. Thanks for your attention!

Politics 2.0 and Why You Shouldn't Care Anyway

Warning: you should not really read this. I am completely incompetent in things I am talking about below. 

Political parties are no fun. Leaving aside a lot of aspects (probably, both positive and negative), one of  most important factors for me is that any party is likely to have some set of ideological "beliefs". Say, "restricted abortions, free market, no gay marriage" or "renewable energy investments, progressive tax, affordable healthcare". What really puzzles me is the necessity to choose either one. What a nonsense! I'd rather vote for particular beliefs rather than the whole platforms!

That does not mean parties should not exist. They probably should, after all they are just a product of the society. Though in order to let voters make more deliberate decisions, they shouldn't be able to vote "Party A or Party B", but they rather should vote for or against every current belief promoted by either party.

Something like...

• (Yes/No/Have no idea) Restrict abortions
• (Yes/No/Have no idea) Invest in renewable energy
• (Yes/No/Have no idea) Free market
• (Yes/No/Have no idea) No gay marriage
• ...  

certainly, without traces to either party. And then we can count popularity of each belief and basing on these numbers there is a chance to build a balanced government consisting of both parties. But it is a kind of utopia, I know. Just a technological view on a way more complex social thing. So do not expect it anytime soon.

I observe an enormous number of people who believe that they should care about these particular elections this Fall. This is the second time I actually see such a high level of civil activism (first time it was in Ukraine 2004).

And you may also strongly believe that it is a Right Thing to act this way, and you even maybelieve that it is your genuine conviction. Whatever. It isn't really important. 

Lets look at the problem this way: one of the most important things for mere mortals is the economy of their country. A number of countries are experiencing a recession (or should we call it panic? depression?) these days. But hey! Isn't economy supposed to be a boom-bust wave? The length of each sector might be quite long (sometimes decades), I guess. But after all, after each bust boom will come, and having either president or party ruling the country will not impact this huge wave significantly — these party-a to party-b waves are just too short and have a low amplitude to be able to. And yes, there are always exceptions about rules, and that means that there is a small chance to have a higher amplitude presidential wave accidentally.

So should you care? You can't really affect the bigger boom-bust economy wave, and you can't really increase odds of "exception miracle". But you can wait...

...and care about tangible things: your family and your community — your close-knit circles. Real politics begin at your front door and your efforts could actually change something.

Please re-read the disclaimer at the beginning of this rant.

P.S. Sorry for no blogging for more than two months. I am guilty without any doubts.

P.P.S. I am not even closely eligible to participate in these elections, and don't plan to become eligible anytime soon; this rant is just a consequence of two beers & 1,5 hrs talk on this & other topics with someone in a bar's patio.

StrokeDB: what's up?

I must confess. We've committed a serious sin. We haven't had a single commit in StrokeDB repository for almost two months. Sorry.

So... one may wonder whether StrokeDB is still alive. Well, yes it is. Though we have significant changes in our plan and approach.

As for now, we consider existing StrokeDB as a first prototype — it has both cool things and a lot of crappy code. So most probably the existing version will perish.

However, we are learning lessons of that awesome development cycle and trying to produce something more clean, both conceptually and code-wise. One of the versions we've started working on, is Oleg's strokedb-core, an attempt to minimize StrokeDB's essential core functionality and therefore get a way more modular and simpler thing.

That said, I am still trying to assemble my thoughts about my initial StrokeDB experience and come out with cures for some problems. That might mean yet another "rewrite" branch I can start anytime soon in order to consolidate my updated vision.

Another change we're working on is getting rid of our custom storages and usage of more proven things, like TokyoCabinet. As far as you can understand that leads to elimination of skiplist and therefore less code. Which is pretty good anyway.

So, to recap, our plan is to:

• Modularize core
• Consolidate updated data organization vision
• More reliable storage

Unfortunately, the deadline date is open. We have no idea when it will be done.

I have a bit busy summer and I still can't work full-time on StrokeDB (and will not be able for a substantial period, unfortunately), but be assured, I am definitely not going to throw this stuff away. Neither does Oleg.

Stay tuned! :)

Is "save" obsolete?

Leaving my hangover apart, I want to talk about some recent "realization" I had. I am not sure it is necessarily a good idea, but it might be worth some investigation. So here we go.

In those ORMs I know (I do not pretend to know all of them, and I had an extensive experience only with few of them, mostly in Ruby) your way to operate with your objects' persistency is basically a read-edit-save loop (RESL). There is nothing bad about this way, especially given that you have no built-in versioning in typical relational databases and ORMs.

But as you may know, we at idbns team are experimenting with some weird ideas and prototypes (like StrokeDB) and one of the things we definitely love about our approach to data management is a built-in versioning.

At this moment, StrokeDB implements this RESL thing, too. It is a quite common approach, but it isn't any fun. It does work with versioning pretty well — it just increments document version once you save — nothing really tricky.

But there is one thing. My own viewpoint that I've developed within past few years is that your persistency mechanism should not let you "separate" your objects from your programming environment. So why the hell should I remind my programming environment to persist object's change every time I modify it? Wouldn't it be nice to persist data transparently?

May be. There is nothing new about this idea, but as far as I understand, there is not much public use of it in the industry.

Let's try to see where will it lead us to. Given we have built-in versioning, every change (like slot's value change) will cause versions change quite frequently, and, what is more important, these versions will be pretty much pointless. You will have a great history of every single change, but you wouldn't be able to say "and here we did that" for any more-than-one-slot update.

Unless you describe it explicitly. What if we'll make a record for every "business operation", something like a document that says:

• this operation was performed at Jul 13, 2008 04:17AM PST
• this operation was "week expenses adjustment"
• this operation was performed on document 61fe324e-3e6e-49e8-9427-6ebab7c31ff9
• this operation starts at version 164c2a4b-294a-4253-97e7-124cc1e4a1cc and ends at version 9d888a2a-7f69-40ae-83c6-c55262d89d99

It seems that having such kind of an explicit records will also allow us to run some kind of smart and safe compaction on a database.

I am not sure about the whole idea, but it still sounds interesting for me. What do you think?

I love Vancouver

That's probably just a matter of being new here, but I am really impressed — it is really a nice and well-balanced city where I do really feel comfortable.

Let's see what I will be thinking about it in a month ;)

Seagull decided to support my radio:

Major blog cleanup

Hey, I am kind of back from nowhere.

This blog is undergoing major cleanup — I will try to re-publish select articles to save some bits of history from 2006 to 2008.

Oh, by the way, I am in BC

By the way, my time is PST these days and I live in Vancouver’s downtown until September — so if anybody wants to meet — drop me a comment or email.

We Don't Need a "Database"

I’ve been trying to formulate what StrokeDB is recently. And here is my summary: StrokeDB is not a database; it is a programming environment on top of Ruby (until we’ll have it ported to other languages). And here are my thoughts about “database” concept.

Do we really need “databases”? Well, I mean, we surely need some toolset to be able to store and retrieve data, but who said we need it in a form of pure datasets to be stored and retrieved? Who said that there should be a database server to interact with? Who said we might need special domain languages designed to manipulate arbitrary data?

What we really need is a persistence-aware programming environment, aren’t we? We just need to be able to store and retrieve data no matter how its persistence handled internally. There is nothing new about it, actually — MUMPS and GemStone/S (or even PL/SQL) were around for decades. What we really might need is to be able to create your-application-data-domain specific languages without any hassles — since we need to manipulate application’s data, not just any data (like you basically do with SQL).

It is quite popular in Rails world to say that we need a stupid database, just a kind of storage and let Ruby do the rest. Basically, they have a point. They use RDBMS as a data storage layer and their database is actually smart, because what is really important for data handling is actually implemented in Ruby. It is still usually limited by RDBMS design constraints, though.

My point is that your data should be as close to your main programming environment as it is possible. Your structures should be as native as it is possible — and they should be handled within the same environment. That’s reminds things like PL/SQL. Basically, PL/SQL is not THAT bad, but the thing with it is that usually you was using not ONLY PL/SQL, but, say, some Java code to interoperate with Oracle database.

Your application itself IS a smart database. So, I’d say we’re in the beginning of the long way “back to the future” — persistence-aware programming environments, not just databases.

Viva smart databases!

P.S. I am going to blog about data organization concepts within such environments soon — that’s an interesting topic to talk about and it is surely more concrete than this one :)

P.P.S. This article got 17 comments initially, so to not to lose them after my major blog cleanup, you can enjoy comments at google's cached version