С другой же стороны, это может быть удобно — хотя и не берусь утвердать, что такой подход правильный — разработчику, который проводит большую часть времени за пыхой, и недоволен скудностью хелперов ванильного JS. Ведь когда твой любимый язык позволяет проще решать рутинные задачи — это бросается в глаза.
Сходным образом думали авторы Sugar JS, портировав в JavaScript красоту и элегантность Ruby. Кстати, если думать только о расширении стандартного функционала, то я бы отдал предпочтение именно Sugar JS.
Это не решает проблемы с тем, что названия переменных могут не следовать соглашениям, смыслу содержимого или контексту. Пример из жизни на руби:
partner = PartnershipProfile.find(profile_id)
if partner && @order.available_for_partner?(partner) # на самом деле в качестве аргумента для available_for_partner? подразумевался partner.user
@order.mark_with_prid partner.id
end
Есть такое распространенное соглашение, что переменная с объектом называется снейк кейсом от класса. В этом примере соглашение изначально не соблюдалось (лень сделала свое дело), и в аргументы ушел PartnershipProfile, хотя должен был уйти User содержащийся в любом PartnershipProfile. Привело к ошибке на живом сервере.
Передовики практического применения ruby, несмотря на все предрассудки, рассматривают RubyMotion всерьез. thoughtbot рассказали в рассылке, что в ближайшее время в AppStore появится их первый продукт на RubyMotion www.stattleship.io/fanboat.html
Под флешмобом Вы подразумеваете всю 24-дневную затею, или пост на хабре? В первом случае PR замечательно будут отсеяны большим выбором репозиториев. Во втором случае — будет хорошо если хотя бы 10% прочитавших займутся этой инициативой. И точно так же, равномерно разбегутся по задачам. Я себе это представляю именно так.
codetriage.com/ — инициатива, на самом деле, не нова. Никто еще не умер.
Согласен, это одна из самых больших проблем — необходимость сообщать унаследовавшему код человеку предпосылки существования этого кода. Это тоже обсуждается в посте. Мое мнение таково — в коде этому не место, но место в репозитории. Каждый коммит по возможности должен быть привязан к соответствующей задаче (багу, таске, фиче) в трекере, быть атомарным и сопровождаться кратким емким описанием. Порой даже автор коммита не может назвать причину его существования, и комментарий в коде поможет в таком случае разве что самую малость. В остальном — инлайновые комментарии мне кажутся визуальным шумом, осложнявшим чтение кода.
Я думаю Вам поможет эта и та ссылка. Но прямых аналогов я, к сожалению, не знаю.
Действительно, курс появился как нельзя кстати. Широкое поле для применения. Это я и люблю в их курсах.
Замечу, что можно зарегистрироваться с помощью аккаунта github или facebook.
С другой же стороны, это может быть удобно — хотя и не берусь утвердать, что такой подход правильный — разработчику, который проводит большую часть времени за пыхой, и недоволен скудностью хелперов ванильного JS. Ведь когда твой любимый язык позволяет проще решать рутинные задачи — это бросается в глаза.
Сходным образом думали авторы Sugar JS, портировав в JavaScript красоту и элегантность Ruby. Кстати, если думать только о расширении стандартного функционала, то я бы отдал предпочтение именно Sugar JS.
Есть такое распространенное соглашение, что переменная с объектом называется снейк кейсом от класса. В этом примере соглашение изначально не соблюдалось (лень сделала свое дело), и в аргументы ушел PartnershipProfile, хотя должен был уйти User содержащийся в любом PartnershipProfile. Привело к ошибке на живом сервере.
Надеюсь не притянуто за уши*
В Rubymine внедрили поддержку RubyMotion.
Индустрия не боится, индустрия пробует.
codetriage.com/ — инициатива, на самом деле, не нова. Никто еще не умер.