Ну насчет «все» это преувеличение, скорее если ты не звезда по принципу один из миллиона, не джуниор, или не ищешь место где будешь сидеть на попе ровно.
Для большинства крепких, уже состоявшихся разработчиков, у больших компаний типа гугла хватает недостатков: медленное движение по карьерной лестнице, правая рука не знает что делает левая и нужно ли то что делают эти руки — голове, оплата зачастую не сказать чтобы прям «вау», скорее ближе к «работать в нашей компании почетно, у нас желающих — вагон маленькая тележка на это место», тяжелый и затратный по времени процесс найма, зачастую очень далекий от предстоящих задач. Бюррократия, большая цепочка ответственных за какие-то решения, зачастую невозможность как-то повлиять на принимаемые решения.
Даже не смотря на отсутвие Go и неудобное время проведения раундов решил зарегистрироваться. Но после формы регистрации в XX полей решил, что я не настолько мотивирован.
Хотелось бы поучаствовать, но настораживают правила…
«Основной персональной
целью каждого волшебника является сбор максимально возможного количества баллов. Звание победителя
игры, а также все остальные места распределяются в соответствии с количеством набранных баллов».
Я так понимаю в классической MOBA идет борьба за выигрыш команды. Здесь же с одной стороны надо действовать командой, с другой стороны получается «каждый сам за себя».
Приплюсовывая сюда разделение на «защитную» — «атакующую» стратегию, не получится ли так что при «защитной» стратегии или при «неудачной» команде верховного мага особо баллов не наберешь?
Еще этот верховный волшебник… который командует команде, где каждый заинтересован в персональном успехе, а не успехе команды… Не говоря о том, что твой успех будет зависеть от другого игрока…
Компетенция редко меняется в худшую сторону, в крайнем случае не растет, что не всегда воспринимается негативно.
И компетенцию довольно легко объекивно оценить и как-то повлиять на ситуацию. Грубо говоря — компетенция — это рабочий момент.
Дело в том, что если человек перестал по пятницам со всеми ходить пиво пить и стал более сосредоточенным и рассудительным — он может еще успешнее выполнять свою работу, но как личность он уже поменялся. Но если его наняли как раз из-за того что он «зажигалка» и «душа компании», то он потерял качества, которые давали ему ценность.
То есть как по мне, смотреть на личность надо, но не надо задавать вопросы — «Кто ты?», «Какая твоя страсть?». Надо оценивать именно то, что человеку помогает уживаться в коллективе — поиск компроммиса, восприятие критики, желание помочь, поделиться своими знаниями и т.д.
А там будь он хоть Джеком Воробьем. Это приятный бонус в качестве ярких красок к будням, но завтра он может вдруг придти Челевеком-Пауком, а может придти и просто вместо Джека Воробья обычный парень в футболке и шортах.
Был на таких собеседованиях, и прямо скажем не в восторге остался.
Человек меняется. Даже если конкретно сейчас вы его взяли и он «вливается» в коллектив, завтра он поменяется, и в что вы с ним делать будете?
Мне показалось, что те кто сильно делают перекос в сторону личности на работе — на выходе получают команду «как на подбор», в которую очень сложно интегрировать новых людей, с другим мышлением, другими амбициями, другими интересами. Хорошо если этот «как на подбор», — команда мечты и выше некуда, а если эта команда способна завалить проект?
Если у человека есть какие-то базовые качества, как честность, отзывчивость, желание помогать и т.д., то есть он сеет доброе и вечное, и он хорош в техническом плане — разве важно вам, кто он?
Я так понимаю вам фильтровать надо, чтобы потом дальше передавать куда-нибудь? Во View, или куда-нибудь в др. место?
Расскажите как вы будете это делать если у вас один компонент допускает только br в name сущности, другой компонент допускает только b в name сущности. Сущность одна, приемников несколько, но в пропертях вы можете задать только один фильтр. Ваши действия?
Лично мое мнение, подобные преобразования должны происходить ближе к «выводу» и знания, как будет модель преобразовываться точно должны быть не в модели. Например View знает, что что-то надо показывать raw, а что-то с escape.
Дык можно решить, или трансформеры задачу не решают?
Насчет понимания я бы поспорил. Валидация в двух местах теперь, рано или поздно это где-нибудь аукнется. Насчет быстрой разработки, тут спорить не буду, но быстро не всегда значит правильно.
Тут не может быть нехоливарного ответа, но динамика развития и внедрения Go говорит в его пользу.
Go действительно хорош, как сказал один человек на митапе: "как language энтузиаст я не люблю Go, но как CTO я в восторге". Вот у многих такие чувства.
Go сильно ломает шаблоны, особенно тем кто привык к широким возможностям ООП, и поэтому вызвает отторжение.
А потом система ушла в продакшн, данных стало не мегабайт а под сотню, и вдруг сетка чего-то стала загружена, и вдруг памяти стало не хватать. И приходит другой программист, смотрит на ваше решение и вы икаете.
Я не верю что три таблицы суммарно мегабайт весом нельзя взять запросом, да еще и чтобы построить какой-то график. Как бы там запросы тоже по собой имеют по сути все те же алгоритмы.
Согласен с выводами, но мне кажется тема "с точки зрения PHP программиста" не совсем раскрыта.
Когда садишься писать на Go после PHP, а особенно Symfony, думаешь о Layers, Abstractions, Interfaces, продумываешь архитектуру и заботишься о том, как этот код будет поддерживаться в дальнейшем, и в большинстве случаев… упираешься в простоту Go и приходиться опять искать другую реализацию архитектуры. В итоге главное принять и поверить — что очевидное и самое простое решение — в Go будет самым правильным, и не надо пытаться вот тут вот сделать интерфейс, а вот тут вот убрать повторение кода, чтобы следовать DRY. Мне показалось что Go диктует простую архитектуру, проблемы поддержки которой решаются именно немонолитностью кода, и после возможностей PHP в плане ООП как решения проблем монолита в это трудно поверить :)
И я бы не сказал что это минус, в выводах очень правильная мысль — PHP вначале, и когда дозрели — выносить в Go.
Все верно и я это все понимаю. Но тут встает проблема разделения ответственности. Если core team не справляется, то надо делегировать ответственность. Сейчас получается так — сори, у нас нету на это времени, до ваших PR и issue мы дойдем нескоро.
То есть с одной стороны страдающая от нагрузки core team везде просит — помогите нам. С другой — извините, у нас нет времени на понять, а помогли ли вы нам.
Это путь в никуда. Если рост core team не будет успевать за ростом проекта — это беда.
Добавлю свои 5 копеек: основная проблема с которой я столкнулся в Symfony — твои изменения могут дожидаться своего часа месяцами, отсюда начинаются все проблемы и пропадает мотивация учавствовать на регулярной основе.
С одной стороны жаль, тоже думал, что они давно в прибыли. С другой стороны добавить немецкий язык просили уже года три назад, до сих пор его нет, и видимо уже не появится.
Для большинства крепких, уже состоявшихся разработчиков, у больших компаний типа гугла хватает недостатков: медленное движение по карьерной лестнице, правая рука не знает что делает левая и нужно ли то что делают эти руки — голове, оплата зачастую не сказать чтобы прям «вау», скорее ближе к «работать в нашей компании почетно, у нас желающих — вагон маленькая тележка на это место», тяжелый и затратный по времени процесс найма, зачастую очень далекий от предстоящих задач. Бюррократия, большая цепочка ответственных за какие-то решения, зачастую невозможность как-то повлиять на принимаемые решения.
«Основной персональной
целью каждого волшебника является сбор максимально возможного количества баллов. Звание победителя
игры, а также все остальные места распределяются в соответствии с количеством набранных баллов».
Я так понимаю в классической MOBA идет борьба за выигрыш команды. Здесь же с одной стороны надо действовать командой, с другой стороны получается «каждый сам за себя».
Приплюсовывая сюда разделение на «защитную» — «атакующую» стратегию, не получится ли так что при «защитной» стратегии или при «неудачной» команде верховного мага особо баллов не наберешь?
Еще этот верховный волшебник… который командует команде, где каждый заинтересован в персональном успехе, а не успехе команды… Не говоря о том, что твой успех будет зависеть от другого игрока…
И компетенцию довольно легко объекивно оценить и как-то повлиять на ситуацию. Грубо говоря — компетенция — это рабочий момент.
Дело в том, что если человек перестал по пятницам со всеми ходить пиво пить и стал более сосредоточенным и рассудительным — он может еще успешнее выполнять свою работу, но как личность он уже поменялся. Но если его наняли как раз из-за того что он «зажигалка» и «душа компании», то он потерял качества, которые давали ему ценность.
То есть как по мне, смотреть на личность надо, но не надо задавать вопросы — «Кто ты?», «Какая твоя страсть?». Надо оценивать именно то, что человеку помогает уживаться в коллективе — поиск компроммиса, восприятие критики, желание помочь, поделиться своими знаниями и т.д.
А там будь он хоть Джеком Воробьем. Это приятный бонус в качестве ярких красок к будням, но завтра он может вдруг придти Челевеком-Пауком, а может придти и просто вместо Джека Воробья обычный парень в футболке и шортах.
Человек меняется. Даже если конкретно сейчас вы его взяли и он «вливается» в коллектив, завтра он поменяется, и в что вы с ним делать будете?
Мне показалось, что те кто сильно делают перекос в сторону личности на работе — на выходе получают команду «как на подбор», в которую очень сложно интегрировать новых людей, с другим мышлением, другими амбициями, другими интересами. Хорошо если этот «как на подбор», — команда мечты и выше некуда, а если эта команда способна завалить проект?
Если у человека есть какие-то базовые качества, как честность, отзывчивость, желание помогать и т.д., то есть он сеет доброе и вечное, и он хорош в техническом плане — разве важно вам, кто он?
Расскажите как вы будете это делать если у вас один компонент допускает только br в name сущности, другой компонент допускает только b в name сущности. Сущность одна, приемников несколько, но в пропертях вы можете задать только один фильтр. Ваши действия?
Лично мое мнение, подобные преобразования должны происходить ближе к «выводу» и знания, как будет модель преобразовываться точно должны быть не в модели. Например View знает, что что-то надо показывать raw, а что-то с escape.
В общем на мой взгляд спорное решение.
Насчет понимания я бы поспорил. Валидация в двух местах теперь, рано или поздно это где-нибудь аукнется. Насчет быстрой разработки, тут спорить не буду, но быстро не всегда значит правильно.
Тут не может быть нехоливарного ответа, но динамика развития и внедрения Go говорит в его пользу.
Go действительно хорош, как сказал один человек на митапе: "как language энтузиаст я не люблю Go, но как CTO я в восторге". Вот у многих такие чувства.
Go сильно ломает шаблоны, особенно тем кто привык к широким возможностям ООП, и поэтому вызвает отторжение.
Я не верю что три таблицы суммарно мегабайт весом нельзя взять запросом, да еще и чтобы построить какой-то график. Как бы там запросы тоже по собой имеют по сути все те же алгоритмы.
Когда садишься писать на Go после PHP, а особенно Symfony, думаешь о Layers, Abstractions, Interfaces, продумываешь архитектуру и заботишься о том, как этот код будет поддерживаться в дальнейшем, и в большинстве случаев… упираешься в простоту Go и приходиться опять искать другую реализацию архитектуры. В итоге главное принять и поверить — что очевидное и самое простое решение — в Go будет самым правильным, и не надо пытаться вот тут вот сделать интерфейс, а вот тут вот убрать повторение кода, чтобы следовать DRY. Мне показалось что Go диктует простую архитектуру, проблемы поддержки которой решаются именно немонолитностью кода, и после возможностей PHP в плане ООП как решения проблем монолита в это трудно поверить :)
И я бы не сказал что это минус, в выводах очень правильная мысль — PHP вначале, и когда дозрели — выносить в Go.
PS. Насчет времени инициализации и т.п., http://symfony.com/blog/new-in-symfony-2-8-symfony-as-a-microframework
То есть с одной стороны страдающая от нагрузки core team везде просит — помогите нам. С другой — извините, у нас нет времени на понять, а помогли ли вы нам.
Это путь в никуда. Если рост core team не будет успевать за ростом проекта — это беда.
Делаем карту переходов, возможных между id.
Таким образом отбрасываем необходимость работы со строками, остаемся наедине с цифрами, задача переводится немного в другую плоскость.
Дальше напрашивается построение графа и поиск пути между вершинами, ну или деревья. Я думаю с числовыми значениями алгоритм проще будет найти.