Krzysztof Hasiński

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

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 https://github.com/khasinski/fillparams

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 ;)

@steffex

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.

@losinggeneration

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.

@losinggeneration
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.

rconklin

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.

montas

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.

clockworkelves

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

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
.

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.

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

http://en.wikipedia.org/wiki/JavaScript <- 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.

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: http://stackoverflow.com/questions/2181079/object-oriented-programming-in-c

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

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();}

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

It's not function-oriented, it's object-oriented, it's just prototype-based http://en.wikipedia.org/wiki/Prototype-based_programming

How about using httpie? https://github.com/jkbr/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:
http://coderwall.com/p/yf5-0w