Oleg Andreev

[idea] Cloning subdirectory from a git repository

Apparently, there’s no conceptual problem with cloning a subdirectory like:

$ git clone git@server:project.git/docs/howto

You should just keep track of those tree objects referencing to “/”, “/docs” and “/docs/howto”, but fetch no references except children of the “/docs/howto” tree.

Better package system

There’s a problem in Ruby: what if your application requires two libraries and both of them require incompatible versions of another library?

API designers who are smart enough create a namespace for each major version (MyLib::API1, MyLib::API2 etc.) so that you can have multiple versions of the same code in run time.

There’s a better solution however. Io language does not make you to modify the global state: source code can be loaded in any other object. This means that you don’t have to pollute library code with a version-based namespaces but you still able to load as many instances of the library as you want. Just make sure you keep them in your private objects.

Dreams come true:

MyParser := Package load(“XMLParser”, “e1fc39a02d786”)

Exceptions

Exceptions are meant to be… ehm… exceptional. Exceptions are thrown when the code could not be executed further. They are meant to be thrown right at the point where something went wrong and passed up the stack till the program termination. Programmer should only provide “ensure” (in Ruby; or “finally” in Java) block to clean up. Programmer should never use “catch”/“rescue” block. Never.

There’s one little thing, however.

Sometimes you run your program and get silly exceptions like “connection lost” or “division by zero”. You become unhappy about it and you decide to implement an interface to deal with such errors. For example, when connection is lost you could show a message or do something smart (depends on the purpose of your program, of course).

But please remember: never ever catch exceptions you don’t know about (no “rescue nil” or “rescue => e”!). You should be very picky at what you are catching. Uncaught exception simply pops up in a system message or a log entry, so you can learn it. But silently caught exception might hide some nasty error from your eyes. And you wouldn’t be able to see in a stack trace what had happened few milliseconds before.

Re: Stop picking on alias_method_chain

Both Ben and Yehuda are wrong. They both use messy metaprogramming where Ruby has a nice solution already. It is a chain of modules and a super method. If the base functionality is provided in a module it looks like this:

module BaseFeatures
  def hello
    "Hello, world!"
  end
end

module AnyGreetingPlugin
  def hello(arg = "world")
    super.sub(/world/, arg)
  end
end

class MyConfiguration
  include BaseFeatures
  include AnyGreetingPlugin
  include AnotherPlugin
end

class MyConfiguration < BaseFeatures
  include AnyGreetingPlugin
  include AnotherPlugin
end

Now let me respond to each point from the Ben’s article:

1. “The method names don’t properly describe what is going on”. Module name describes what particular functionality it adds to the methods it contains.

2. “The base method shouldn’t care what other modules are doing, modularity is broken”. That’s not the case when you use regular modules.

3. “Logic is not 100% contained”. Logic is 100% contained: no magical macros anywhere.

4. “Promotes messy code”. Again, nothing to even seem messy.

5. “Exposes a documentation flaw”. When you think modules it is easy to separate concerns and understand how every little aspect of functionality affects everything else. You don’t have to speak any other language except Ruby. You think of module chains and message passing: no structure is created dynamically where not necessary. Only thing you have to do: describe in the documentation what this particular class or module is supposed to do. Then provide examples of a default configurations (when some modules are included in a single class) to make the picture complete. Respect the language. Keep it simple, stupid.

Re: refactoring data models

class User < ActiveRecord::Base; end
class Artist < User; end
class Investor < User; end


I don’t understand why this would be a very bad idea ? All the users are stored in a same table as they have a lot of attributes and not much differ…

This starts with a naming of a user. As i wrote you recently, “User” name completely hides “role” from you, so it seems natural to put all the roles into User model. However, huge models tend to become harder and harder to modify and understand.

If you think of it that way:

- Person - holds authentication info
- Artist - holds info about music and albums
- Investor - holds info about artists and finance
the following becomes easy to play with:

- Person has many Artists (say, i can create several accounts for a number of my bands)
- Artist info can be edited by a group of People (my band members would like to update the news page/wiki/whatever)
- I (as a person) can represent several investors, or none at all.
- Investor can manage a number of artists, and/or a single artist can have several investors.

The reason to separate models by tasks is the very same as to separate objects from the top global Object class into more specific ones.

Speaking scientifically, it is just about “normalization” of a relational database.

If you have duplicating attributes, you have three equally good options (depending on your situation):

1. Mix them in using a module (e.g. “EntityWithTitleAndDescription”) if the duplication is just a coincidence, not a big deal (just to put some duplication into a single file to keep things cleaner).

2. Implement a separate model and associate it with appropriate models (e.g. “Account” could mediate between Person and Project to manage wikis/pages/documents/artists/etc. to avoid hardcore polymorphism between Person and Project). This is the case in a Basecamp-like app, where people have individual data as well as data, shared by a group (project).

3. Leave duplication as is: Coincidence pattern

Sometimes you have to have STI, but i believe this is not the case. E.g. i have PublicFolder and Inbox subclasses of a class Folder because they are a little special per se, not by their association to other folders.

Statistics-based optimization strategy

Process consists of a number of phases. Each phase provides a feedback on its performance.

Instead of defining some performance threshold for each phase to start optimization at and asking ourselves “when should we start optimizing this?”, we should rather ask ourselves “which phase is to be optimized now?”. That is, we should collect all feedback, sort it and start optimizing most important phases first. Naturally, we end the process when we are not getting any visible performance gains anymore.

This strategy can be applied to dynamic programming language runtime as well as to any other controllable process.

Method dispatch: hotspot metric

At each callsite (source code point, where method dispatch happens) we can count

1) number of calls to a method

2) time spent inside the method

3) time spent in callsite (total time across all methods called at the point).

Time can be measured either in byte code instructions, machine instructions or in microseconds.

Lets look at possible situations:

In real code, we don’t meet frequently called very slow methods: it is often done by bad design and could not be efficiently optimized in runtime. But this chart helps us to define a metric for “hot spot” identification: the place in the code, where we start runtime optimization.

Such “hotspot” metric would be callsite time * number of calls. The higher this number, the higher priority should be given to such callsite at optimization phase.

Why don’t we just start with a top-level method? If we start from the very top, we would spend enormous amount of time optimizing the whole program instead of really interesting parts.