Аналогично делал раньше — это единственное приложение, полностью равноценной замены которому не нашёл при смене платформы. Однако toshl finance теперь мне тоже подходит. Дизайн мне даже больше нравится, и в целом всё устраивает.
Мне кажется, макароны и сыр — неудачный пример «левой» покупки, т.к. и то, и другое относится к категории «еда» (я пользуюсь категориями и вы, наверное, тоже), и рано или поздно вы всё это съедите.
Впоследствии я обленился до ещё большей степени — категориями теперь выступают магазины, в которые я захожу. Лента, ОКей, и всякая такая фигня. Зато по итогам месяца можно посмотреть где сколько потратил.
Пользуюсь твиттером несколько лет, фоловлю примено 60 человек. ИМО, 100 — это нифига не новичок, да и «новичок» понятние индивидуальное — что, если человеку не интересно больше никого читать?
1 совет — непонятно зачем так делать, ну допустим, мы уверены, что валидацию напишем с багами, что дальше? — перекладывать часть валидации на уровень бд? Ок, валидация прошла, а в бд запись не сохранили, что будет с приложением? Надо дополнительно отлавливать исключения. ИМХО, проще написать нормальную валидацию и протестить это.
2 совет — имеется в виду, что можно не следовать конвенциям, а писать что угодно как угодно и прикручивать это к фреймворку? Конечно, можно, только «назачем»
3 совет — да это ж вёрстка, это должно быть в шаблоне, а не хелпере
Последняя рекомендация вообще относится к workflow — итого, топик бы я охарактеризовал как «вредные советы». Хотя автор оригинальной статьи честно написал в предисловии, что он
а также немало прочитал и написал плохого кода на Ruby
Видимо, да :) Тут есть несколько вариантов — можно закрыть статистику, можно ввести человеческий «рейтинг сексуальности цыпочек», а то сейчас всё ранжируется по количеству просмотров.
Вот вы сказали «люди из Groupon,… Zeptolab» — оплачивали ли их участие сами компании? Ну и, более интересный вопрос: вести курс будет тимлид из групона, и core commiter (странная регалия, честно, фактически можно даже с 1 коммитом в кор любого раскрученного продукта N себя так именовать) — неужели они не поделились своими знаниями с коллегами безвозмездно?
Бегло просмотрел программу: haml, sass, coffeescript, денормализация бд, много слов про tdd/bdd (полагаю будет Test::Unit, rspec, cucumber) — информации на эти темы с избытком в свободном доступе, не только текстовой, но и скринкастов. К тому же всё это, что называется, «не ново» большинству разработчиков, хотя заявлено
Brainwashing будет полезен уже опытным Ruby on Rails разработчикам, архитекторам и тимлидам
Ни одного инструмента, перечисленного в секции «профилирование» я не знаю. Что же делать? — а гугл всё отлично подсказывает, везде есть документация. Которую, не смотря на посещение ваших курсов, всё равно придётся читать — невозможно же за 2 дня уложить кому бы то ни было в голову такой объём разноплановой информации. Поэтому и хочется узнать, чем же оправдана и подкреплена такая высокая стоимость обучения, чем именно довольны все эти люди и где они :)
И что, получается этот курс (не хочу никого обидеть) для проф. непригодных что ли? ИМХО, в любом случае не для опытных разработчиков, которые не тратя такие суммы сами в состоянии прочитать доки. Хотя опять же, если фирма платит — сходил бы с удовольствием.
Неполные заголовки выдаёт. В игре угадал «Подросток, чья мама умерла, а папа давно в больнице, найден» — нажал прочитать полностью, редиректнуло на новость с уточнением «Подросток, чья мама умерла, а папа давно в больнице, найден повешенным». Видел бы сразу такой заголовок, даже кликать бы не стал…
«Поругаешь не по делу я сразу заявление на стол» — это очень трудная позиция для восприятия новых знаний, да и вообще очень трудная позиция(для окружающих). Я бы не хотел с вами работать :) Все мы считаем свой код хорошим, насколько это правда может сказать только более опытный и авторитетный коллега, не обязательно сотрудник.
Насчёт «полурефакторинга» не совсем ясно, его просто не бывает. Рефакторинг — процесс итеративный и постоянный, постепенное улучшение качества кода. То есть он != переписыванию всего с нуля и по-новой. И проводить его лучше сразу, ведь не даром существует знаменитая мантра red/green/refactor (и тут), откладывая его *до нужды* можно хорошенько запустить проект. Это как раз описанные выше случаи.
Конечно, многое зависит от культуры сообщества, в модных ruby-python-комьюнити это само собой разумеется и приветствуется. А масштабирование я имел в виду функциональности.
А может вы просто слишком распыляетесь? Такие случаи, по-моему, описывали и до этого. Как вариант — можно уменьшить нагрузку, сконцентрировавшись на более узком кругу задач.
«ты ничего не понимаешь и тебя просто ругали мало, но ничего я исправлю.» — звучит нахально, но это работает. В такой манере можно делать код-ревью. Да, более опытный сотрудник будет совершать акт глумления над кодом менее опытного, тут уж ничего не поделать, в сфере IT сарказм является привилегией опытных. Но ведь это мотивирует догнать его по уровню знаний, перегнать, а потом, при удобном случае, ещё и пиздюлей навалять.
Иначе откуда брать знания? Книги все по рефакторингу не перечитать, за блогами всеми не уследить, все самые свежие 3rd-party-решения в книгах не описаны — а ведь именно это всё помогает работать наиболее продуктивно.
В статье фактически говорится «не нужен рефакторинг» — я сейчас работаю над проектом, где очень много функциональности реализовано, и всё работает, а вот масштабировать его крайне хреново, приходится много и с болью рефакторить. И до этого такие проекты попадались, и на разных работах, и явно не у меня одного.
Впоследствии я обленился до ещё большей степени — категориями теперь выступают магазины, в которые я захожу. Лента, ОКей, и всякая такая фигня. Зато по итогам месяца можно посмотреть где сколько потратил.
2 совет — имеется в виду, что можно не следовать конвенциям, а писать что угодно как угодно и прикручивать это к фреймворку? Конечно, можно, только «назачем»
3 совет — да это ж вёрстка, это должно быть в шаблоне, а не хелпере
Последняя рекомендация вообще относится к workflow — итого, топик бы я охарактеризовал как «вредные советы». Хотя автор оригинальной статьи честно написал в предисловии, что он так что всё соответствует :)
Бегло просмотрел программу: haml, sass, coffeescript, денормализация бд, много слов про tdd/bdd (полагаю будет
Test::Unit, rspec, cucumber) — информации на эти темы с избытком в свободном доступе, не только текстовой, но и скринкастов. К тому же всё это, что называется, «не ново» большинству разработчиков, хотя заявленоНи одного инструмента, перечисленного в секции «профилирование» я не знаю. Что же делать? — а гугл всё отлично подсказывает, везде есть документация. Которую, не смотря на посещение ваших курсов, всё равно придётся читать — невозможно же за 2 дня уложить кому бы то ни было в голову такой объём разноплановой информации. Поэтому и хочется узнать, чем же оправдана и подкреплена такая высокая стоимость обучения, чем именно довольны все эти люди и где они :)
И что, получается этот курс (не хочу никого обидеть) для проф. непригодных что ли? ИМХО, в любом случае не для опытных разработчиков, которые не тратя такие суммы сами в состоянии прочитать доки. Хотя опять же, если фирма платит — сходил бы с удовольствием.
Хитрую нумерацию пунктов списка вы тоже унаследовали из своего юридического прошлого?)
НАХУЙ.
ЭТО.
ДЕРЬМО.
(хотя точки после каждого слова смотрятся странно)
Насчёт «полурефакторинга» не совсем ясно, его просто не бывает. Рефакторинг — процесс итеративный и постоянный, постепенное улучшение качества кода. То есть он != переписыванию всего с нуля и по-новой. И проводить его лучше сразу, ведь не даром существует знаменитая мантра red/green/refactor (и тут), откладывая его *до нужды* можно хорошенько запустить проект. Это как раз описанные выше случаи.
Конечно, многое зависит от культуры сообщества, в модных ruby-python-комьюнити это само собой разумеется и приветствуется. А масштабирование я имел в виду функциональности.
«ты ничего не понимаешь и тебя просто ругали мало, но ничего я исправлю.» — звучит нахально, но это работает. В такой манере можно делать код-ревью. Да, более опытный сотрудник будет совершать акт глумления над кодом менее опытного, тут уж ничего не поделать, в сфере IT сарказм является привилегией опытных. Но ведь это мотивирует догнать его по уровню знаний, перегнать, а потом, при удобном случае, ещё и пиздюлей навалять.
Иначе откуда брать знания? Книги все по рефакторингу не перечитать, за блогами всеми не уследить, все самые свежие 3rd-party-решения в книгах не описаны — а ведь именно это всё помогает работать наиболее продуктивно.
В статье фактически говорится «не нужен рефакторинг» — я сейчас работаю над проектом, где очень много функциональности реализовано, и всё работает, а вот масштабировать его крайне хреново, приходится много и с болью рефакторить. И до этого такие проекты попадались, и на разных работах, и явно не у меня одного.