Тёма Лебедев цинично обрисовал свои ценности: "Долго. Дорого. Ох%енно" - человек не корчит из себя супер-корпорацию, а говорит прямо, как весь процесс устроен.
Я не дизайнер, но знаю, что у Лебедева работать не просто, и что чел он сложный. Тем не менее когда сотрудники идут туда работать, они 100 пудов знают куда идут. И из кожи лезут чтобы попасть туда. Там трудно, но нет сюрпризов - в этом прелесть. И оттуда выходят такие же офигенные дизайнеры.
Так вот мне кажется, что гораздо лучше так - цинично и прямо, чем мылить мозги розовыми корпоративными соплями.
Наконец, это не про мою боль - мне и так норм. Это скорее сочувствие к некоторым искренее убивающимся работодателям, которые по какой-то причине не понимают, что лицемерят, и потому теряют сотрудников.
Мне это очень даже резонирует. Если для меня риск сильно потерять в здоровье - не пойду даже за сто тыщ миллонов люстр.
В статье же я обращаюсь скорее к работодателям. И если у него условия ниже среднего, а исправлять он это не хочет, то ему нечего предложить кроме денег — деньги и только деньги. Тогда возможно и удержит. Возможно.
И уж точно не стоит впаривать печеньки и корп.ценности с бухлом.
В статье говориться в контексте отношений "Работодатель - Разработчик". Вы же говорите, на сколько я понимаю, про отношения "Сообщество - Разработчик". Если разработчик открыл свой код, который приносит пользу сообщесву - значит это его (разработчика) личные ценности, которые этим служением общесвту удовлетворяются. Как это происходит - другой вопрос.
Если вы открывали свой личный код и им пользовались сотни или тысячи людей - вы скорее всего знаете, что вы за это получаете.
И ещё немного. Намерение статьи всё-таки сказать не только про деньги. Она про ценности и про то, что зачастую работодатель пытается впарить свои, вместо денег, в то время как деньги - самое простое и полезное, что можно предложить и не забивать людям голову чушью.
Куда тратить деньги? Но ведь у работодателя не возникает такого вопроса.
Тупая работа отнимает много сил. А ещё есть семья, дети.... в итоге не хватит времени и моральных ресурсов на свой pet-project.
Согласен. Поэтому вопрос весь в ценностях. Если вам важнее деньги - будете искать деньги И хороший проект.
А на дурном проекте я не знаю кто усидит больше года-двух. Как раз только ради "заработать квартиры/машины" и "адью". А семья ради такого, возможно, и потерпит. Зависит же от личных ценностей.
А за 1 млн в месяц? А за 2 млн? Закрыть 90% своих потребностей за год?
Кроме того, при такой тупой работе - кто мешает свой сторонний проект начать попиливать для прокачки? Обычно на сторонних проектах народ больше всего и качается.
P.S.: Конечно помню, Саш! И мой тебе пламенный! :)
Использовал DI в Go в промышленных масштабах, так сказать. Сотни объектов (хотя, возможно уже несколько тысяч). Из моей практики есть 2 аспекта:
(+) DI хорош, когда есть множество зависимостей и всех их нужно связывать между собой. Графо-решалка всё сама подставит куда нужно.
(-) Грабли с Duck-Typing: представим, что конструктор объекта принимает интерфейс, а DI успешно в него подставляет нужный объект по этому интерфейсу. Потом проходит время, вы в совершенно независимом месте добавляете новый метод, а при запуске ловите конфликт зависимостей: DI откуда-то взял 2 объекта, подходящих под этот интерфейс. Почему? Да потому что Duck-Typing: вы случайно написали метод, который вдруг сматчил ещё один объект с этим интерфейсом. И если ваш DI-механизм не умеет показывать, откуда он это взял (а у нас самописный, который по началу не умел), то так сказать "счастливой отладки". :) Простым решением является GoLand, который умеет показывать всех представителей данного интерфейса.
Вообще для больших проектов на Go, где сотни и тысячи объектов, DI является неплохой инвестицией, ИМХО. Потому что ковыряться во всех этих "проводах" уже при сотне объектов становится адом.
К счастью, человечеству достаточно "воодушевительной хрени", чтобы продолжать жить, потому что в сухом рационализме оно пришло бы к простой идее, что рациональнее и оптимальнее всего просто сразу застрелиться, чем тратить свои ресурсы на совершение какой-либо работы, которая в конечном счёте всё равно приведёт к смерти.
Мне кажется, проблема надуманная.
Если хотите работать в Google, Яндекс, %placeholder% — просто будьте готовы вытерпеть пачку "тупых" вопросов, которые, как вам кажется, никому не нужны. Ведь они когда-то закончатся.
Другой вопрос: а надо ли оно вам? Вы уверены, что вам нужно в Google? Тогда терпите. Сомневаетесь? Тогда шлите нафиг. Хотите изменить бюрократический строй организации? Тогда напишите/позвоните руководителю, найдите его профиль в LinkedIn/whatever — и поговорите с ним лично.
Когда я был уверен в желании попасть в нужную команду, мой алгоритм был простой: нужны алгоритмы? ОК, рассказал. Нужны деревья? ОК, рассказал. Рассказал всё. Отлично, а теперь позовите пожалуйста сюда моего будущего руководителя, а лучше всю команду. И мне не отказали, потому что это было бы глупо: после полного собеседования иметь шанс потерять человаека, когда осталось его только нанять. И я задавал технические вопросы, которые интересовали меня, и меня тоже спрашивали, и всем стало куда понятнее, кто есть кто.
Требуется много времени и больше сил? Увы. Но ещё раз: просто спросите себя: вам точно нужно в Google?
Про опечатки.
Обнаруживаем сразу после получения черновых результатов, и исправляем; правда, без фанатизма.
То, что вы описали в качестве самого простого — думаю, вполне себе рабочая идея. Но по-хорошему, это тема для отдельной статьи, поэтому в качестве ориентира привёл ссылку на работу ребят из Майкрософт. Продублирую её здесь.
В таком случае можно насобирать «offline» фактов и весов этих фактов из тех источников, по которым происходит поиск.
Скажем, если вы делаете поиск по порталу научных статей, и хотите сделать для этого поиска подсказки, тогда можно было бы поступить следующим образом:
насобирать заголовков статей — и это были бы тексты подсказок;
посчитать рейтинг этих статей каким-либо известным алгоритмом; скажем, PageRank по ссылкам, которые упоминаются в этих статьях — и это был бы вес подсказки.
В любом случае, если у вас нет online-поведенческих данных, вам придётся каким-то образом насобирать их в offline'е. То есть, как в примере выше, количество ссылок на научную статью, по сути и есть её популярность, оценённая авторами других статей, ссылающихся на первую.
Тёма Лебедев цинично обрисовал свои ценности: "Долго. Дорого. Ох%енно" - человек не корчит из себя супер-корпорацию, а говорит прямо, как весь процесс устроен.
Я не дизайнер, но знаю, что у Лебедева работать не просто, и что чел он сложный. Тем не менее когда сотрудники идут туда работать, они 100 пудов знают куда идут. И из кожи лезут чтобы попасть туда. Там трудно, но нет сюрпризов - в этом прелесть. И оттуда выходят такие же офигенные дизайнеры.
Так вот мне кажется, что гораздо лучше так - цинично и прямо, чем мылить мозги розовыми корпоративными соплями.
Наконец, это не про мою боль - мне и так норм. Это скорее сочувствие к некоторым искренее убивающимся работодателям, которые по какой-то причине не понимают, что лицемерят, и потому теряют сотрудников.
Тогда разработчик должен быть в доле, и "штрафы" с "плюшками" будут автоматизированы.
Фикс зп выгодна бизнесу и подразумевает оплату за профессионализм = "ответственность" = все вытекающие с "посидеть лишние полчаса".
Если чел не профессионал - его "просят" из компании.
Мне это очень даже резонирует. Если для меня риск сильно потерять в здоровье - не пойду даже за сто тыщ миллонов люстр.
В статье же я обращаюсь скорее к работодателям. И если у него условия ниже среднего, а исправлять он это не хочет, то ему нечего предложить кроме денег — деньги и только деньги. Тогда возможно и удержит. Возможно.
И уж точно не стоит впаривать печеньки и корп.ценности с бухлом.
В статье говориться в контексте отношений "Работодатель - Разработчик". Вы же говорите, на сколько я понимаю, про отношения "Сообщество - Разработчик". Если разработчик открыл свой код, который приносит пользу сообщесву - значит это его (разработчика) личные ценности, которые этим служением общесвту удовлетворяются. Как это происходит - другой вопрос.
Если вы открывали свой личный код и им пользовались сотни или тысячи людей - вы скорее всего знаете, что вы за это получаете.
И ещё немного. Намерение статьи всё-таки сказать не только про деньги. Она про ценности и про то, что зачастую работодатель пытается впарить свои, вместо денег, в то время как деньги - самое простое и полезное, что можно предложить и не забивать людям голову чушью.
Куда тратить деньги? Но ведь у работодателя не возникает такого вопроса.
Тупая работа отнимает много сил. А ещё есть семья, дети.... в итоге не хватит времени и моральных ресурсов на свой pet-project.
Согласен. Поэтому вопрос весь в ценностях. Если вам важнее деньги - будете искать деньги И хороший проект.
А на дурном проекте я не знаю кто усидит больше года-двух. Как раз только ради "заработать квартиры/машины" и "адью". А семья ради такого, возможно, и потерпит. Зависит же от личных ценностей.
За личное отношение очевидно. Что же ещё ощущает разработчик, когда запилил и выкатил своё творение в свет?
Да, именно об этом, спасибо.
Тогда по моей теории - дружба задалась: работодатель явно выяснил личную мотивацию сотрудника, и удовлетворяет её.
А за 1 млн в месяц? А за 2 млн? Закрыть 90% своих потребностей за год?
Кроме того, при такой тупой работе - кто мешает свой сторонний проект начать попиливать для прокачки? Обычно на сторонних проектах народ больше всего и качается.
P.S.: Конечно помню, Саш! И мой тебе пламенный! :)
Тогда вопрос - а что было дальше?
А ещё он на основе code generation. Т.е. сначал сгенерить код нужно. Что впрочем тоже неплохо: все косяки будут отловлены ещё в compile time.
Использовал DI в Go в промышленных масштабах, так сказать. Сотни объектов (хотя, возможно уже несколько тысяч). Из моей практики есть 2 аспекта:
(+)DI хорош, когда есть множество зависимостей и всех их нужно связывать между собой. Графо-решалка всё сама подставит куда нужно.(-)Грабли с Duck-Typing: представим, что конструктор объекта принимает интерфейс, а DI успешно в него подставляет нужный объект по этому интерфейсу. Потом проходит время, вы в совершенно независимом месте добавляете новый метод, а при запуске ловите конфликт зависимостей: DI откуда-то взял 2 объекта, подходящих под этот интерфейс. Почему? Да потому что Duck-Typing: вы случайно написали метод, который вдруг сматчил ещё один объект с этим интерфейсом. И если ваш DI-механизм не умеет показывать, откуда он это взял (а у нас самописный, который по началу не умел), то так сказать "счастливой отладки". :) Простым решением являетсяGoLand, который умеет показывать всех представителей данного интерфейса.Вообще для больших проектов на Go, где сотни и тысячи объектов, DI является неплохой инвестицией, ИМХО. Потому что ковыряться во всех этих "проводах" уже при сотне объектов становится адом.
К счастью, человечеству достаточно "воодушевительной хрени", чтобы продолжать жить, потому что в сухом рационализме оно пришло бы к простой идее, что рациональнее и оптимальнее всего просто сразу застрелиться, чем тратить свои ресурсы на совершение какой-либо работы, которая в конечном счёте всё равно приведёт к смерти.
Не принципиально, но первые 2 пункта явно лишние.
А где его (чат-бота), собственно, посмотреть? Или когда?
Мне кажется, проблема надуманная.
Если хотите работать в Google, Яндекс, %placeholder% — просто будьте готовы вытерпеть пачку "тупых" вопросов, которые, как вам кажется, никому не нужны. Ведь они когда-то закончатся.
Другой вопрос: а надо ли оно вам? Вы уверены, что вам нужно в Google? Тогда терпите. Сомневаетесь? Тогда шлите нафиг. Хотите изменить бюрократический строй организации? Тогда напишите/позвоните руководителю, найдите его профиль в LinkedIn/whatever — и поговорите с ним лично.
Когда я был уверен в желании попасть в нужную команду, мой алгоритм был простой: нужны алгоритмы? ОК, рассказал. Нужны деревья? ОК, рассказал. Рассказал всё. Отлично, а теперь позовите пожалуйста сюда моего будущего руководителя, а лучше всю команду. И мне не отказали, потому что это было бы глупо: после полного собеседования иметь шанс потерять человаека, когда осталось его только нанять. И я задавал технические вопросы, которые интересовали меня, и меня тоже спрашивали, и всем стало куда понятнее, кто есть кто.
Требуется много времени и больше сил? Увы. Но ещё раз: просто спросите себя: вам точно нужно в Google?
C++ есть. http://xgboost.readthedocs.io/en/latest/
Только видимо что-то отъехало в хабре — html-код в примерах какой-то полез.
Про опечатки.
Обнаруживаем сразу после получения черновых результатов, и исправляем; правда, без фанатизма.
То, что вы описали в качестве самого простого — думаю, вполне себе рабочая идея. Но по-хорошему, это тема для отдельной статьи, поэтому в качестве ориентира привёл ссылку на работу ребят из Майкрософт. Продублирую её здесь.
Скажем, если вы делаете поиск по порталу научных статей, и хотите сделать для этого поиска подсказки, тогда можно было бы поступить следующим образом:
В любом случае, если у вас нет online-поведенческих данных, вам придётся каким-то образом насобирать их в offline'е. То есть, как в примере выше, количество ссылок на научную статью, по сути и есть её популярность, оценённая авторами других статей, ссылающихся на первую.
Ну, либо я не понял Ваш вопрос.