Joined May 2012

Krzysztof Hasiński


Symfony2 uses something called Incenteev ParameterHandler which generates config (yml files) on the fly. I've ported it to ruby:

You basically ship .dist (like .sample) files and during build it will ask for missing parameters. Useful for development (new developer doesn't have to guess where to look for config files and what else is there to configure). It copies missing parameters when you run it in non-interactive environment.

In Symfony2 they use Incenteev/ParameterHandler, which creates config YAML files from templates called .dist files. Basically it checks for the missing params (which is nice considering that most projects introduce more config params as they evolve) and asks for them during build process. Feel free to take a look at

I also change my config for vim, bash and many other things. It's still your account on the remote server. If it isn't you're using verbose, long commands and do not have aliases anyway. And that's when you type git pull --rebase ;)


No it isn't. You can set it up per repository, you can have your global settings changes. It's your account. If you switch a lot between different machines it's nice to have your config shared between them anyway.

Alias way is good too, but autorebase is in no way dangerous.

You can always bring back merge by doing git pull --no-rebase

Besides - it's git. If you haven't pushed it to a remote repository you can always fix it ;)

Pull with rebase wont push changed history unless you have multiple remote repositories in which case you should know git better. You never have to use rebase, you can always do a revert commit. But it makes your repositories unreadable and sharing code so much more difficult.


git pull --rebase locally and then pushing to remote branches won't change anyone's history except yours. :) It's OK to do it. In fact - you should do it. Are you talking about people pulling using public (remote) branch (resolving pull requests)? Pull requests should demand that the said code apply in a clean manner (demand rebasing PR code against current HEAD) and use merge -no-ff option to indicate resolved request.

It's about git pull --rebase, not any other kind rebasing. It's pretty clear it's local. ;) But I'll add a notice to the original note.


It's a popular misconception that git rebase destroys history. It rearranges it into something else. Context isn't as important as you might think and rebase is a tool for LOCAL rewriting of history, not REMOTE rearrangements. That's the basic difference between SVN-likes and a distributed VCS.

Remember - you're only rebaseing your own code, often on a feature branch. It's your own history (until you push it somewhere).

If you don't understand that you're going to have a bad time with any DVCS and have ugly, hairy history that is basically unreadable to anyone bisecting, looking for bugs.

It's your option (feature branches with merges) that's available to SVN users. Making history useful is something available only to DVCS.

Don't limit your git to a subversion clone with better merging, produce useful commit history.


Because sometimes you can work on something for a couple days and you don't want to diverge so much from the original branch. Keeping codebase synchronised is often cheaper than solving lots of conflicts when you want to push.


Check man git, you'll see it's 'the stupid content tracker' ;)

Posted to Coffeescript, is worth to learn it! over 1 year ago

CS is fully OO, JS is fully OO. How much more convincing do you need? ;) If you need class keyword to program OO then you do not understand OO enough

Posted to Coffeescript, is worth to learn it! over 1 year ago

I see you haven't clicked the link so I'll paste it here: Multi-paradigm: scripting, object-oriented (prototype-based), imperative, functional. It fully supports EVERY aspect of OO programming. Classes are also just a special case for prototypes.

Posted to Coffeescript, is worth to learn it! over 1 year ago

And JavaScript IS an object-oriented language. Arguing that it's not just because it doesn't have a 'class keyword' is silly. <- Paradigm - object oriented.

Prototypes are a very a powerful concept. If you understand them and read Design Patterns again you can easily see that those patterns are just some special cases for prototypes.

If you're using -m when committing it's probably simpler most of the time to just press up on the keyboard and add --amend at the end.

Posted to OOP in C ... kinda over 1 year ago

Kevlin Henney had a really good lecture about whether you can do OOP in Java, which also demonstrated programming OO in ANSI C.

I can't find the link at the moment, but here is stackoverflow answer with demonstration of OOP in C:

Still, it's possible (and often expected) to do OOP in C .

Posted to Segmentation fault over 1 year ago

It isn't mine ;) I never posted any, I just like @stnly 's post ;)

Nevertheless the post is still true. I haven't found a way to cause a segfault with gcc cranked up with -Wall -Werror -O shorter than

int main(){return main();}
Posted to Segmentation fault over 1 year ago

@lokiastari: It doesn't compile with gcc -Wall -Werror -O

Posted to Learning JavaScript Design Patterns over 1 year ago

It's not function-oriented, it's object-oriented, it's just prototype-based

Posted to Colorful json in terminal over 1 year ago

How about using httpie?

cjson is nice when you have local scripts outputting json, httpie is suited for testing webservices and AJAX pages.

You can get even shorter version as I described here:

2,507 Karma
587,479 Total ProTip Views
Interests & Skills