Changes are coming
I’ve found a few lines of code that make use of Rails’ method returning. I’ve seen it on the Errtheblog before and thought that it can be useful but someone will misuse it for sure. So here it is.
def feeds_list returning([]) do |feeds| BLOGS.each do |blog| feeds < < feed_url_for(@app_name, blog) end end endWhy do people do such things if there’s Array#collect
def feeds_list BLOGS.collect do |blog| feed_url_for(@app_name, blog) end endI’ve caught myself on coding something for a few days before I even run it first time. But when I do run it the first time it pretty much finished and the only changes I do a simple fixes like typos or minor logic corrections. Maybe some optimizations.
So I’m wandering if other do the same way or if they follow different methodologies in their work like “ship early, release often”.
Get Flash to see this player.
Так сказать, экскурс в историю музыкального творчества Amon'а Tobin'а.
Обосновывая свою точку зрения, в первую очередь, надо полагаться на состоятельность своих аргументов, а не на неточности в трактовках оппонента. Я так полагаю.
Миша Клишин рассказывает о Git’е, Mercurial’е (и Darcs’е) и FUD‘е. В двух словах: он рассказывает о том, как фенбои Mercurial’а его нервируют, как они критикуют Git за его сложность и некоторую недружелюбность к Windows (должен заметить, оправдано). И рассказывает, что Hg очень медлителен и никогда не доберется по скорости до Git’а (который даже быстрее файловой системы: “Git is faster than your file system”). Он приводит пример: конвертацию проекта в 800 Мб из Darcs в Mercurial, что заняла на его MBP 7 часов.
Интересно было бы посмотреть сколько заняла бы конвертация из Darcs в Git. Так, для сравнения. Потому, что данный пример всего-лишь говорит о скорости работы Hg, но никак не о том, что он намного медленнее Git’а. Да и выбранная задача очень актуальна. Например, я по несколько раз на день конвертирую большие репозитории.
Правда, он говорит пару слов о том, что стоит выбирать инструмент, который удовлетворяет твои нужды. Например, мои нужды удовлетворяет Bazaar. И делает он это гораздо лучше, чем Git. Наверное, потому, что я не ворочаю репозитории по гигу размером и мне не жалко двадцать три сотых секунды для дифа.
В последнее время поднимается все больший ажиотах вокруг DVCS‘ов. Многие (по крайней мере в рельсово-рубевой среде) склоняются к Git‘у. Ну, вот я и решил попробовать.
Скажу честно, я о нем слышал давно уже. Он используется для разработки линуксового ядра и xmms2. В отличии от своих ближайших соперников - Mercurial‘а и Bazaar‘а он написан на C, а не на python и потому очень быстрый. Но, наверное, по той же причине Mercurial и Bazaar имеют гораздо более дружелюбній интерфейс. Bazaar, например, даже обзавелся графическической оболочкой, которая позволяет делать все необходимое.
Но не о них речь, а о Git’е. Я уже говорил, что он не очень дружлюбен. Вот несколько примеров. Сразу говорю - я пришел с Subversion’а и никапли не стараюсь быть объективным, а даже наоборот.
Поскольку Git очень хочет быть DCVS, то неотъемлемой частью работы есть бранчевание и мержи. Вот о мержах и поговорим. А вернее о конфликтах, как неотъемлемой их части.
При пуле конфликты показываются так:
Auto-merged app/models/event.rb CONFLICT (content): Merge conflict in app/models/event.rbА вот в статусе нифига не понятно:
unmerged: app/models/event.rb modified: app/models/event.rbЧто самое плохое, автоматически не может смержить одинаковый код. Видимо, это связано с тем, что он не может понять кому в таком случае приписывать это изменение. Это связанно с тем, что Git хранит полную историю изменений при мержах, в отличии от того же Subvrsion’а.
< <<<<<< HEAD:config/initializers/google-geocoder.rb Geocode.geocoder = Graticule.service(:google).new GOOGLE_MAPS_API_KEY ======= Geocode.geocoder = Graticule.service(:google).new GOOGLE_MAPS_API_KEY >>>>>>> 14edde15cb190ebef2ef73e7ecf458c5b47853fd:config/initializers/google-geocoder.rbЕще у него страшные проблемы с интуитивностью интерфеса.
Вот как зарезолвить конфликты? У SVN’а есть resolve. У Bazaar’а есть resolve. А у Git’а - update-index. Это рекомендовали на kerneltrap’е.
Edit so the files have sensible content
then use
git update-index
to tell git that that particular conflict has been resolved.
Это при том, что update-index вообще-то предназначен совсем для другого.
Вот несколько моментов. Однако, я намерен избавиться от Git’а очень скоро. Я не хочу больше возиться с такой непонятной штукой. Потому, как мержить придется часто и я не хочу, чтобы это было так тяжело.
Eventune
Firefox
Gentoo
Gnome
Google
Songbird