механизм языка интересный, а вот «пример» и «мотивация» использования (на примере той же сортировки и компаратора — «решение» заменить явную связь неявной ради экономии 1 аргумента при вызове) пока не убеждает (за восторженным текстом видно скорей желание внедрить чего-нибудь ещё нового, чем решить реальную проблему)
«И ещё нужно помнить все эти прикольные названия для в общем-то одной типовой задачи.» — обычная софистика. Понв глубокий смысл принципов SOLID отпадает необходимость помнить и знать эти «прикольные» названия.
А вот создание неявных зависимостей в коде — как раз потребует или помнить или каждый раз читать от начала до конца код, когда создаешь или меняешь implict объект.
В таком виде это всё же не «inline-тесты» — а всё же ближе к программированию по контракту, в том смысле что в комментариях да без аквтокомплита имеет смысл записывать только короткие проверки. Те же самые проверки с тем же успехом может быть внесено в код метода + в php есть assert
С «антикризисным управлением» проектом с неограниченным бюджет всё достаточно очевидно.
много правильных слов было сказано, но мне больше интересно другое: каким образом в компании с взрослым западным подходом РП смог спалить почти весь бюджет, прежде чем все спохватились и начали рисовать картинки в одной из модных нотаций, и размахивать «хлыстом».
Если вброса не произойдет — есть вариант с автобусами Москва- > Спб
И небольшой лайфхак для любителей приключений: Москва->Малые Вишеры (станция с палисадником и фантанчиком) ->Спб
Если мест на нормальные поезда из вишер до спб не будет — там утром отходит электричка как раз до города Петра, но тут уж на конференции без кофе будет сложно.
Вместо Вашер можно посмотреть ситуацию с Бологое, но там спасительной электрички не будет.
Больше всего позабавило:
«Но как выяснилось позже, он действовал исключительно в своих целях. И как только ему стало невыгодно»
Вот так сюрприз.
Человек всегда делает что-то в своих интересах. И если проекция вектора интересов компании на интересы человека велика — он заинтересован в достижении целей компании/команды. Если вдруг по каким то причинам проекция начинает стремиться к нулю — сотрудничество заканчивается. Не считайте обманчивый период сотрудничества альтруизмом.
И избавьтесь уже от идеализации «принимаем решения» и «ответственность» — ваш же пример наглядно демонстрирует, что решения по критически важным вопросам вы принять оказались не в состоянии, а уж об «ответственности» просто смешно говорить — чуть не угробили полтора года работы из-за того, что кто-то на кого-то косо посмотрел, кто-то с кем то о чём то не смог договориться — ничего не скажешь — «ответственные» работники.
Уф. Внесу свои 5 копеек. Да действительно — питание в этом году было организовано лучше.
Доклады от TheShade и Walrus прошли более организовано, чем в прошлом (когда излишнее количество шуток Алексея привело, к тому, что один из парных докладов получился скомканным — не хватило времени)
К организаторам вопрос — зачем так много иностранных докладчиков, при том, что в российских ораклах огромное количество специалистов. Для примера — история с ADF, которому было посвящено несколько докладов и мастер-класс. Да — приехали иностранные докладчики, и рассказали про основы (причём имхо достаточно однобоко. Могло сложиться ощущение, что ADF является продолжением OracleForms, что вовсе не так). Как мне кажется было бы больше пользы, если бы в оракле подготовили некое обобщение существующего опыта и больше внимания уделили историям успеха и методологии. Сам по себе adf как инструмент для «клепания формочек» — мало интересен. Но всё меняется если начинать рассматривать adf в комплекте с JDeveloper в контексте полного цикла разработки ПО. При правильном использовании это инструмент позволит пустить вход артефакты аналитиков (которые раньше зачастую были просто картинками в visio): они породят модель данных, различные срезы, сервисы для манипуляции этими данными, пользовательские сценарии могут быть представлены в виде taskflow, прототипы пользовательского интерфейса станут основой для полнофункциональных форм. А это уже значительная часть той работы, которую раньше приходилось раз за разом кодировать «руками». Оставшееся часть работы может масштабироваться (может ли?) почти линейно. Есть ощущение, что возможно сэкномить бюджет за счёт более низких требований к квалификации
В общем подозреваю в этом инструменте большой потенциал (Вспомнились забытые ощущение от model driven и историй времён инстурментов линейки Rational *), но блин — почему обо всём этом ни слова?
Или т.н. «стандарты кодирования» описаны их автором в виде настроек для IDE которой пользуется вся команда или это потеря времени, а т.н. «лиду» рановато пока быть «лидом».
Это, если честно так странно…
Получается сапожник без сапог.
Похоже на историю с другим «экспертом» от UX — Сатиным. Он тоже любит цитировать книжки и всячески теоретизировать. А как дошло дело до UX нового интерфейса банкоматов сбербанка — мыльный пузырь и «конкурс дизайна на хабре»
В большей степени меня интересуют улучшения от внедрения проектирования по-контракту вообще, нежели этой конкретной библиотеки.
Понятно, что многие все эти книги и статьи читали, и слышали, что это «хорошо и правильно», но меня инетресует именно прагматическая сторона вопроса.
Применимость CI во многом обусловлена пригодностью системы к авто-тестирвоанию. Так что тут вас просто повезло в том смысле, что если бы унаследованная система оказалась спагетти — то и от CI было бы мало толку в силу невозможности/неэффективности автотестов
Посмотрел картинку изобретенного процесса — не совсем понял, что же «нового».
Кроме того — в тексте формулируются 3 «проблемы» которые возникли перед проектной командой, которые и решил новый способ организации. Не совсем понятно как предложенный способ решает 3ю проблему и в чём преимущество перед традиционными итерационными методами с очередями заданий и обратными связями.
Сложилось ощущение, что автор находится во власти «предвзятости выжившего», указывая причиной успеха «новую» методику.
Это да. Но просто у «программистов» часто ярко выражен аналитический склад ума и собственно склонность к анализу. Так что «уболтать», как представителей некоторых других профессий, не получится (даже если вдруг тебе кажется, что ты его «уболтал» например на нереальные сроки с помощью фразочек «ну ты же профессионал» — на самом деле — это не так, это просто ещё один гвоздик в крышку гроба продуктивных отношений)
По поводу вопроса "– Почему ты хочешь у нас работать?".
Попытаюсь объяснить в чём тут смысл.
Необходимые условия для этого вопроса: описание вакансии должно быть достаточно подробным и, помимо прочего, содержать описание проекта.
Итак — приходит человек. Мы с ним беседуем о том-о сём. И тут этот вопрос. Я бы его озвучил немного под другому, но смысл остается тот же: Чем Вас привлекла наша вакансия. Ну действительно — на рынке сейчас не кризис, адекватный специалист средней квалификации может выбирать из многих примерно одинаковых компаний. Почему он откликнулся на нашу вакансию.
Зачем это мне? Что мне даст ответ на этот вопрос?
Всё очень просто: не смотря на распространенное заблуждение многих горе-руководителей — «мотивировать» человека невозможно. Мотив к работе у человека «внутри». У него есть некоторый внутренний вектор интересов. И Одна из главных задач собеседования — выяснить чего человек хочет. И чем выше скалярное произведение векторов интересов человека и компании больше — тем лучше и это и есть та самая «мотивация».
Мы знаем (ну или думаем, что знаем) ) чего мы хотим, но чего хочет кандидат? Ответ на исходные вопрос и даёт представление о том, чего человек хочет.
Кого-то привлекла зарплата
Кого-то близость к дому/учебе
Кого-то амбициозность проекта, который начинается с нуля
Кому-то нужна «стабильность крупной компании»
Кто-то говорит, о профессиональном росте
Кто-то говорит о карьерном (административном)
насколько хорошо/долго/продуктивно/деструктивно будет работать кандидат зависит от того, насоклько наша вакансия соответствует его ожиданиям.
Вот и всё. всё просто. Если человек говорит, что его привлекла зарплата, то через год мы его скорей всего потеряем. В каких-то проектах это плохо, в каких-то не так важно.
Если у нас новый проект с нуля, и человеку нужна история успеха — то как минимум этот проект он постарается до успешного запуска, потому что это соответствует и его интересам тоже.
И т.д. и т.п. ищем общие интересы.
А дальше всё просто — если мы понимаем, что эта вакансия соответствует ожиданиям кандидата — то всё хорошо, а если не соотвствует — то ну какой смысл? Ведь он будет несчастлив и при первой возможности уйдёт в другое место.
Правда есть значительный пласт людей, которые задают этот вопрос, потому что так «принято». Это печально, но всё-равно — ИМХО лучше честно ответить в т.ч. и себе на этот вопрос «чем меня привлекла эта вакансия», чем ходить на работу как на каторгу и потом плюнуть и уволиться.
Ещё одним важным практическим следствием этого «профессионального заболевания» является «последовательность». Если кому-то приходится «руководить» такими специалистами — присмотритесь к себе вот в каком ключе:
Часто бывает так, что сначала «программистам» «заказали» одно, а когда заказ был приготовлен, выяснилось, что нужно совсем другое. Так бывает потому, что все люди идиоты и потому, что мир меняется — это норма. Так вот — если в этот момент не признать, что они молодцы и сделали всё как надо, но ситуация изменилась и теперь нужно другое. А ну например пытаться их «уболтать» и «убедить „что они “сами идиоты ничего не поняли»… это дерьмо они заметят очень быстро, и в какой-то момент просто решат, что с вами не о чем говорить больше. И всё. Конец. Затягивание сроков, отсутствие мотивации и внезапные увольнения, которые они с вами откажутся обсуждать.
Всё это слишком тонкие материи, чтобы результаты синтетических тестов распространять на все ситуации.
То, что переиспользовать объекты в моменте «быстрей» чем создавать — да. Это было и так ясно без тестов.
Но с другой стороны:
1)мы лишаемся возможности сделать их immutable. Есть много ситуаций где потребуется бОльшая аккуратность и это чревато ошибками с многопоточностью
2)Собирать молодые объекты легко и быстро, но если их много и мы решим их переиспользовать — они быстро станут «старыми» и это приблизит наступление full gc и сделает его более медленным. Так что не очевидно. Опять же когда мне надо несколько миллионов объектов переиспользовать — это может повлиять на соотношение размеров памяти между областями разных поколений.
Так что — надо смотреть в конкретной ситуации и в реальной работе.
«Кстати, а вам самим-то нужен неопытный руководитель...?»
Судя по кейсам — там как раз уже и есть один такой «эффективный менеджер». И «Боливар не вынесет двоих»
> Паттерны — это лишь частное и не всегда самое удачное решение на базе ООП принципов.
ИМХО более правильно былобы сказать, что большинство т.н. «паттернов» это не более чем применение принципов SOLID к проектированию. Сами по себе базовые принципы ООП (не знаю, почему именно они названы базовыми и почему именно для ООП. Ведь инкапсуляцию и делегирование — это достаточно общие принципы и не являются эксклюзивными для ООП) не обязательно приведут к «хорошим» решениям.
А так — с мыслью в заголовке согласен.
В качестве продолжения примеров надуманности т.н. «паттернов» можно рассмотреть как обычная зависимость благодаря применению принципов SOLID сначала превращается в «паттерн заместитель», а после по мере развития системы — в «паттерн цепочка обязанностей», и в особо запущеных случаях «кровавого энтерпрайза»- в «паттерн бизенсс-делегат»
«И ещё нужно помнить все эти прикольные названия для в общем-то одной типовой задачи.» — обычная софистика. Понв глубокий смысл принципов SOLID отпадает необходимость помнить и знать эти «прикольные» названия.
А вот создание неявных зависимостей в коде — как раз потребует или помнить или каждый раз читать от начала до конца код, когда создаешь или меняешь implict объект.
много правильных слов было сказано, но мне больше интересно другое: каким образом в компании с взрослым западным подходом РП смог спалить почти весь бюджет, прежде чем все спохватились и начали рисовать картинки в одной из модных нотаций, и размахивать «хлыстом».
И небольшой лайфхак для любителей приключений: Москва->Малые Вишеры (станция с палисадником и фантанчиком) ->Спб
Если мест на нормальные поезда из вишер до спб не будет — там утром отходит электричка как раз до города Петра, но тут уж на конференции без кофе будет сложно.
Вместо Вашер можно посмотреть ситуацию с Бологое, но там спасительной электрички не будет.
«Но как выяснилось позже, он действовал исключительно в своих целях. И как только ему стало невыгодно»
Вот так сюрприз.
Человек всегда делает что-то в своих интересах. И если проекция вектора интересов компании на интересы человека велика — он заинтересован в достижении целей компании/команды. Если вдруг по каким то причинам проекция начинает стремиться к нулю — сотрудничество заканчивается. Не считайте обманчивый период сотрудничества альтруизмом.
И избавьтесь уже от идеализации «принимаем решения» и «ответственность» — ваш же пример наглядно демонстрирует, что решения по критически важным вопросам вы принять оказались не в состоянии, а уж об «ответственности» просто смешно говорить — чуть не угробили полтора года работы из-за того, что кто-то на кого-то косо посмотрел, кто-то с кем то о чём то не смог договориться — ничего не скажешь — «ответственные» работники.
Доклады от TheShade и Walrus прошли более организовано, чем в прошлом (когда излишнее количество шуток Алексея привело, к тому, что один из парных докладов получился скомканным — не хватило времени)
К организаторам вопрос — зачем так много иностранных докладчиков, при том, что в российских ораклах огромное количество специалистов. Для примера — история с ADF, которому было посвящено несколько докладов и мастер-класс. Да — приехали иностранные докладчики, и рассказали про основы (причём имхо достаточно однобоко. Могло сложиться ощущение, что ADF является продолжением OracleForms, что вовсе не так). Как мне кажется было бы больше пользы, если бы в оракле подготовили некое обобщение существующего опыта и больше внимания уделили историям успеха и методологии. Сам по себе adf как инструмент для «клепания формочек» — мало интересен. Но всё меняется если начинать рассматривать adf в комплекте с JDeveloper в контексте полного цикла разработки ПО. При правильном использовании это инструмент позволит пустить вход артефакты аналитиков (которые раньше зачастую были просто картинками в visio): они породят модель данных, различные срезы, сервисы для манипуляции этими данными, пользовательские сценарии могут быть представлены в виде taskflow, прототипы пользовательского интерфейса станут основой для полнофункциональных форм. А это уже значительная часть той работы, которую раньше приходилось раз за разом кодировать «руками». Оставшееся часть работы может масштабироваться (может ли?) почти линейно. Есть ощущение, что возможно сэкномить бюджет за счёт более низких требований к квалификации
В общем подозреваю в этом инструменте большой потенциал (Вспомнились забытые ощущение от model driven и историй времён инстурментов линейки Rational *), но блин — почему обо всём этом ни слова?
Получается сапожник без сапог.
Похоже на историю с другим «экспертом» от UX — Сатиным. Он тоже любит цитировать книжки и всячески теоретизировать. А как дошло дело до UX нового интерфейса банкоматов сбербанка — мыльный пузырь и «конкурс дизайна на хабре»
Понятно, что многие все эти книги и статьи читали, и слышали, что это «хорошо и правильно», но меня инетресует именно прагматическая сторона вопроса.
1)Кто внедрял на своём проекте?
2)Улучшение каких показателей было отмечено на проекте? Какова величина улучшений была отмечена
Кроме того — в тексте формулируются 3 «проблемы» которые возникли перед проектной командой, которые и решил новый способ организации. Не совсем понятно как предложенный способ решает 3ю проблему и в чём преимущество перед традиционными итерационными методами с очередями заданий и обратными связями.
Сложилось ощущение, что автор находится во власти «предвзятости выжившего», указывая причиной успеха «новую» методику.
Но ничего страшного — «езда на дохлой лошади» продолжается
Попытаюсь объяснить в чём тут смысл.
Необходимые условия для этого вопроса: описание вакансии должно быть достаточно подробным и, помимо прочего, содержать описание проекта.
Итак — приходит человек. Мы с ним беседуем о том-о сём. И тут этот вопрос. Я бы его озвучил немного под другому, но смысл остается тот же: Чем Вас привлекла наша вакансия. Ну действительно — на рынке сейчас не кризис, адекватный специалист средней квалификации может выбирать из многих примерно одинаковых компаний. Почему он откликнулся на нашу вакансию.
Зачем это мне? Что мне даст ответ на этот вопрос?
Всё очень просто: не смотря на распространенное заблуждение многих горе-руководителей — «мотивировать» человека невозможно. Мотив к работе у человека «внутри». У него есть некоторый внутренний вектор интересов. И Одна из главных задач собеседования — выяснить чего человек хочет. И чем выше скалярное произведение векторов интересов человека и компании больше — тем лучше и это и есть та самая «мотивация».
Мы знаем (ну или думаем, что знаем) ) чего мы хотим, но чего хочет кандидат? Ответ на исходные вопрос и даёт представление о том, чего человек хочет.
Кого-то привлекла зарплата
Кого-то близость к дому/учебе
Кого-то амбициозность проекта, который начинается с нуля
Кому-то нужна «стабильность крупной компании»
Кто-то говорит, о профессиональном росте
Кто-то говорит о карьерном (административном)
насколько хорошо/долго/продуктивно/деструктивно будет работать кандидат зависит от того, насоклько наша вакансия соответствует его ожиданиям.
Вот и всё. всё просто. Если человек говорит, что его привлекла зарплата, то через год мы его скорей всего потеряем. В каких-то проектах это плохо, в каких-то не так важно.
Если у нас новый проект с нуля, и человеку нужна история успеха — то как минимум этот проект он постарается до успешного запуска, потому что это соответствует и его интересам тоже.
И т.д. и т.п. ищем общие интересы.
А дальше всё просто — если мы понимаем, что эта вакансия соответствует ожиданиям кандидата — то всё хорошо, а если не соотвствует — то ну какой смысл? Ведь он будет несчастлив и при первой возможности уйдёт в другое место.
Правда есть значительный пласт людей, которые задают этот вопрос, потому что так «принято». Это печально, но всё-равно — ИМХО лучше честно ответить в т.ч. и себе на этот вопрос «чем меня привлекла эта вакансия», чем ходить на работу как на каторгу и потом плюнуть и уволиться.
Часто бывает так, что сначала «программистам» «заказали» одно, а когда заказ был приготовлен, выяснилось, что нужно совсем другое. Так бывает потому, что все люди идиоты и потому, что мир меняется — это норма. Так вот — если в этот момент не признать, что они молодцы и сделали всё как надо, но ситуация изменилась и теперь нужно другое. А ну например пытаться их «уболтать» и «убедить „что они “сами идиоты ничего не поняли»… это дерьмо они заметят очень быстро, и в какой-то момент просто решат, что с вами не о чем говорить больше. И всё. Конец. Затягивание сроков, отсутствие мотивации и внезапные увольнения, которые они с вами откажутся обсуждать.
То, что переиспользовать объекты в моменте «быстрей» чем создавать — да. Это было и так ясно без тестов.
Но с другой стороны:
1)мы лишаемся возможности сделать их immutable. Есть много ситуаций где потребуется бОльшая аккуратность и это чревато ошибками с многопоточностью
2)Собирать молодые объекты легко и быстро, но если их много и мы решим их переиспользовать — они быстро станут «старыми» и это приблизит наступление full gc и сделает его более медленным. Так что не очевидно. Опять же когда мне надо несколько миллионов объектов переиспользовать — это может повлиять на соотношение размеров памяти между областями разных поколений.
Так что — надо смотреть в конкретной ситуации и в реальной работе.
Судя по кейсам — там как раз уже и есть один такой «эффективный менеджер». И «Боливар не вынесет двоих»
ИМХО более правильно былобы сказать, что большинство т.н. «паттернов» это не более чем применение принципов SOLID к проектированию. Сами по себе базовые принципы ООП (не знаю, почему именно они названы базовыми и почему именно для ООП. Ведь инкапсуляцию и делегирование — это достаточно общие принципы и не являются эксклюзивными для ООП) не обязательно приведут к «хорошим» решениям.
А так — с мыслью в заголовке согласен.
В качестве продолжения примеров надуманности т.н. «паттернов» можно рассмотреть как обычная зависимость благодаря применению принципов SOLID сначала превращается в «паттерн заместитель», а после по мере развития системы — в «паттерн цепочка обязанностей», и в особо запущеных случаях «кровавого энтерпрайза»- в «паттерн бизенсс-делегат»