В поле (или теле) нельзя определить такую бинарную функцию, обратную к умножению (a : b = d(a,b) <=> d(a,b)*b = a), чтобы в её область определения входил 0 по второму аргументу:
Для любого a != 0, d(a,0)*0 = a, но с другой стороны d(a,0)*0 = 0, т.е. a=0 - противоречие
А d(0,0)*0 = 0 - подходит любое число, т.е. не получится сделать функцией
Это как раз неявное заявление, когда ты выносишь что либо в общество, т.к. шансы что кто-то другой начнет это делать — падают.
С чего вы взяли, что шансы на то, что кто-то другой займётся изготовлением собственного open source решения подобной задачи падают от того, что некто начал делать своё? Как минимум, пока этот некто своё решение не доведёт до пригодного к использованию состояния, на других он не влияет. Да и потом. Некоторые вещи (программы, утилиты, библиотеки и пр.) делаются (в т.ч. в open source) в десятках вариантов, и никого почему-то не останавливает наличие других.
Это вообще какое-то популярное заблуждение, что существует некий закон сохранения вклада в open source, благодаря которому, если кто-то делает одно, то другой это делать не будет, или наоборот, что если кто-то прекратит делать что-то одно, то тут же бросится делать что-то другое. Это, например, часто выражается в более радикальных утверждениях вроде: "Зачем вы делаете X?! Прекратите, т.к. уже есть подобное Y, или потому, что мне не травится X. Займитесь лучше более полезным Z!". Как будто если человек не будет делать это самое X, то тут же бросится делать, то, что от него хочет говорящий.
Это ерунда же. Любые попытки что-нибудь поменять стоит начинать (и обычно начинают) с популяризации соответствующих идей. И статья в популярный ресурс — отличный вариант, как это сделать. Идею, опять же, стоит проработать, перед тем как пытаться применять, и публичное обсуждение — очень хороший вариант, как это можно сделать.
Устройтесь в какую-нибудь токсичную компанию менеджером и продвиньте там свою гуманистическую культуру.
Для этого надо кого-то в этой компании убедить, что так будет лучше, а для этого надо это им рассказать. Хорошо бы заранее подготовить тезисы и проработать аргументы и возможные контраргументы. Как ни странно, всё это можно сделать подготовив и опубликовав статью, а потом поучаствовав в её обсуждении.
И с остальными предложениями (своя компания или депутат) тоже самое: полезно сначала проработать идею и посмотреть реакцию на неё. Если реакция будет исключительно негативная, например, то может не стоит и начинать делать что-то значительно более сложное вроде попытки из этой идеи соорудить политическую программу.
Тут ещё важно учитывать, что интересность работы не так просто оценить извне. При устройстве часто говорят о современных технологиях, высоких нагрузках, технических вызовах и пр. динамично развивающихся молодых коллективах. А по факту всё обычно сводится к ковырянию в тоннах легаси при попытке пробросить куда-нибудь новое поле или условие в логику.
Поэтому многие предпочитают соглашаться только на повышение з/п, чтобы если с интересом не повезёт, то хоть з/п поднять.
А что именно является интеллектуальной собственностью? Если формулировка задания, то не достаточно ли переформулировать задачу своими словами? И можно ли эту собственность оспорить, если найти соответствующую задачу в каком-нибудь задачнике, откуда её скорее всего взяли?
Имхо, это всё полная ерунда: название coq — "петух" по-французски, созвучно с "cock" по-английски, что тоже значит петух. Т.е. язык назван по имени известной всем птицы мужского пола, и созвучный вариант по-английски ничем в этом плане не отличается. В чём вообще может быть проблема? Мало ли, что и где используется как эвфемизм к чему-нибудь? Давайте ещё вспомним, что в России (в блатной среде) у слова "петух" есть негативные коннотации. Так можно любое слово рано или поздно заклеймить.
А вот логотип действительно так себе. Да ещё и невзрачный. Я, например, до сих пор даже не обращал на него внимания ни на сайте, ни в coqide, и не думал даже, что там что-то осмысленное нарисовано, а не просто бледное пятно какое-то.
Зато срубили хайпа. Даже вон на Хабре статью впервые с 2013го года написали!
Там есть несколько вариантов переименования, в которых coq можно будет считать сокращением и оставить в именах утилит и пакетов, так что может не так уж и страшно. Ну или сделают migration tool.
Я вам больше скажу. Не редки ситуации, когда уже сотрудники Яндекса уходят из надоевшего проекта наружу, а не ротируются в другую команду внутри, из-за того, что при ротации (по крайней мере при смене бизнес-юнита) тоже надо пройти почти такой же набор собесов, а они не хотят тратить на это столько сил и/или не уверены, что смогут их успешно пройти.
Наверное, и автор комментария, с которого статья начинается, и автор статьи под словом "резюме" имели в виду слово "вакансия". Или это я что-то не понимаю?
Наоборот, это что они (порекомендованные) сначала долго ждут, когда с ними свяжутся, и не всегда даже дожидаются, а потом их отправляют на тот же стандартный набор секций.
Собственно, это даже логично, учитывая, что рекомендовавшему за нанятого по рекомендации дают приличный бонус.
А то, что стараются нанимать по рекомендации, вовсе не противоречит необходимости решать при этом задачки.
Прошу прощения. Конечно, я имел в виду "все бэкендеры". А писать SQL, HQL или Criteria собирать — это уже дело десятое. Один фиг, если тормозить будет, то придётся посмотреть, какой SQL генерируется и какой у него план выполнения.
Таки вот тут выше был пример с "найти общие элементы в двух списках". Вот вы как предпочитаете: написать "очевидный" для тех, кто не в курсе про асимптотическую сложность, квадратичный алгоритм, а потом ловить проблему бенчмарком, или таки воспользоваться библиотечной функцией для пересечения множеств и больше не вспоминать об этом никогда?
Нагрузочное тестирование конечно никто не отменял, но его делают далеко не так часто, а ещё реже добиваются высокого покрытия по коду, а подобная взрывная штука может спрятаться где угодно.
Ну и писать бенчмарки на любой кусочек кода — тоже странная идея. Они всё-таки обычно применяются, когда уже понятно по другим признакам, что конкретный кусочек кода работает слишком медленно, и не видно очевидных опять же проблем с асимптотикой, поэтому придётся писать что-то сложное, которое надо и протестировать досконально, и производительность с другими вариантами сравнить.
Ситуация в Яндексе, кстати местами именно такое впечатление и производит. Все умеют проходить алгоритмические секции, а практически любое решение переделывают каждые несколько лет, т.к. оказалось, что архитектура достаточно жёсткая, чтобы проще было с нуля переписать. Или под конец моей там работы был случай, когда ради оптимизации в одном из компонентов решили кардинально поменять его АПИ, чем вынудили всех клиентов этого компонента переписывать довольно много кода. И ни у кого ничего не "звякнуло" ведь. Хотя теоретически, если есть сомнения по архитектуре, то можно сходить на специальный "Архитектурный комитет" и там её обсудить. Просто сомнений обычно нет, да и "зачем время тратить?" — лучше потом два раза переделать)
По теме могу только сказать, что писать квадратичные алгоритмы вместо линейных — это таки большое зло. И стреляет потом очень больно, и разбираться и чинить придётся в дикой спешке и, возможно, в нерабочее время, ибо прод горит, а деньги улетают в трубу тоннами в секунду.
Что конечно никак не обосновывает необходимость задротства на литкоде
Это парадоксально, конечно, но прокрастинация часто возникает как раз как защитная реакция при попытке взвалить на себя больше, чем нужно.
В поле (или теле) нельзя определить такую бинарную функцию, обратную к умножению (a : b = d(a,b) <=> d(a,b)*b = a), чтобы в её область определения входил 0 по второму аргументу:
Для любого a != 0, d(a,0)*0 = a, но с другой стороны d(a,0)*0 = 0, т.е. a=0 - противоречие
А d(0,0)*0 = 0 - подходит любое число, т.е. не получится сделать функцией
С чего вы взяли, что шансы на то, что кто-то другой займётся изготовлением собственного open source решения подобной задачи падают от того, что некто начал делать своё? Как минимум, пока этот некто своё решение не доведёт до пригодного к использованию состояния, на других он не влияет. Да и потом. Некоторые вещи (программы, утилиты, библиотеки и пр.) делаются (в т.ч. в open source) в десятках вариантов, и никого почему-то не останавливает наличие других.
Это вообще какое-то популярное заблуждение, что существует некий закон сохранения вклада в open source, благодаря которому, если кто-то делает одно, то другой это делать не будет, или наоборот, что если кто-то прекратит делать что-то одно, то тут же бросится делать что-то другое. Это, например, часто выражается в более радикальных утверждениях вроде: "Зачем вы делаете X?! Прекратите, т.к. уже есть подобное Y, или потому, что мне не травится X. Займитесь лучше более полезным Z!". Как будто если человек не будет делать это самое X, то тут же бросится делать, то, что от него хочет говорящий.
Вы, вероятно, про Thompson Hack
Это ерунда же. Любые попытки что-нибудь поменять стоит начинать (и обычно начинают) с популяризации соответствующих идей. И статья в популярный ресурс — отличный вариант, как это сделать. Идею, опять же, стоит проработать, перед тем как пытаться применять, и публичное обсуждение — очень хороший вариант, как это можно сделать.
Для этого надо кого-то в этой компании убедить, что так будет лучше, а для этого надо это им рассказать. Хорошо бы заранее подготовить тезисы и проработать аргументы и возможные контраргументы. Как ни странно, всё это можно сделать подготовив и опубликовав статью, а потом поучаствовав в её обсуждении.
И с остальными предложениями (своя компания или депутат) тоже самое: полезно сначала проработать идею и посмотреть реакцию на неё. Если реакция будет исключительно негативная, например, то может не стоит и начинать делать что-то значительно более сложное вроде попытки из этой идеи соорудить политическую программу.
Тут ещё важно учитывать, что интересность работы не так просто оценить извне. При устройстве часто говорят о современных технологиях, высоких нагрузках, технических вызовах и пр. динамично развивающихся молодых коллективах. А по факту всё обычно сводится к ковырянию в тоннах легаси при попытке пробросить куда-нибудь новое поле или условие в логику.
Поэтому многие предпочитают соглашаться только на повышение з/п, чтобы если с интересом не повезёт, то хоть з/п поднять.
Есть опасение, что это максимально быстро приведёт к выгоранию
А что именно является интеллектуальной собственностью? Если формулировка задания, то не достаточно ли переформулировать задачу своими словами? И можно ли эту собственность оспорить, если найти соответствующую задачу в каком-нибудь задачнике, откуда её скорее всего взяли?
Имхо, это всё полная ерунда: название coq — "петух" по-французски, созвучно с "cock" по-английски, что тоже значит петух. Т.е. язык назван по имени известной всем птицы мужского пола, и созвучный вариант по-английски ничем в этом плане не отличается. В чём вообще может быть проблема? Мало ли, что и где используется как эвфемизм к чему-нибудь? Давайте ещё вспомним, что в России (в блатной среде) у слова "петух" есть негативные коннотации. Так можно любое слово рано или поздно заклеймить.
А вот логотип действительно так себе. Да ещё и невзрачный. Я, например, до сих пор даже не обращал на него внимания ни на сайте, ни в coqide, и не думал даже, что там что-то осмысленное нарисовано, а не просто бледное пятно какое-то.
Зато срубили хайпа. Даже вон на Хабре статью впервые с 2013го года написали!
Там есть несколько вариантов переименования, в которых coq можно будет считать сокращением и оставить в именах утилит и пакетов, так что может не так уж и страшно. Ну или сделают migration tool.
Я вам больше скажу. Не редки ситуации, когда уже сотрудники Яндекса уходят из надоевшего проекта наружу, а не ротируются в другую команду внутри, из-за того, что при ротации (по крайней мере при смене бизнес-юнита) тоже надо пройти почти такой же набор собесов, а они не хотят тратить на это столько сил и/или не уверены, что смогут их успешно пройти.
Наверное, и автор комментария, с которого статья начинается, и автор статьи под словом "резюме" имели в виду слово "вакансия". Или это я что-то не понимаю?
Наоборот, это что они (порекомендованные) сначала долго ждут, когда с ними свяжутся, и не всегда даже дожидаются, а потом их отправляют на тот же стандартный набор секций.
Собственно, это даже логично, учитывая, что рекомендовавшему за нанятого по рекомендации дают приличный бонус.
А то, что стараются нанимать по рекомендации, вовсе не противоречит необходимости решать при этом задачки.
Вы уверены? Я слышал ровно наоборот от коллег, которые пробовали кого-то рекомендовать.
Прошу прощения. Конечно, я имел в виду "все бэкендеры". А писать SQL, HQL или Criteria собирать — это уже дело десятое. Один фиг, если тормозить будет, то придётся посмотреть, какой SQL генерируется и какой у него план выполнения.
Таки вот тут выше был пример с "найти общие элементы в двух списках". Вот вы как предпочитаете: написать "очевидный" для тех, кто не в курсе про асимптотическую сложность, квадратичный алгоритм, а потом ловить проблему бенчмарком, или таки воспользоваться библиотечной функцией для пересечения множеств и больше не вспоминать об этом никогда?
Нагрузочное тестирование конечно никто не отменял, но его делают далеко не так часто, а ещё реже добиваются высокого покрытия по коду, а подобная взрывная штука может спрятаться где угодно.
Ну и писать бенчмарки на любой кусочек кода — тоже странная идея. Они всё-таки обычно применяются, когда уже понятно по другим признакам, что конкретный кусочек кода работает слишком медленно, и не видно очевидных опять же проблем с асимптотикой, поэтому придётся писать что-то сложное, которое надо и протестировать досконально, и производительность с другими вариантами сравнить.
Вообще-то SQL обычно пишут все. И никаких отдельных специалистов по нему нет. В том же Я у меня была секция с вопросами про SQL, когда я устраивался.
Ситуация в Яндексе, кстати местами именно такое впечатление и производит. Все умеют проходить алгоритмические секции, а практически любое решение переделывают каждые несколько лет, т.к. оказалось, что архитектура достаточно жёсткая, чтобы проще было с нуля переписать. Или под конец моей там работы был случай, когда ради оптимизации в одном из компонентов решили кардинально поменять его АПИ, чем вынудили всех клиентов этого компонента переписывать довольно много кода. И ни у кого ничего не "звякнуло" ведь. Хотя теоретически, если есть сомнения по архитектуре, то можно сходить на специальный "Архитектурный комитет" и там её обсудить. Просто сомнений обычно нет, да и "зачем время тратить?" — лучше потом два раза переделать)
По теме могу только сказать, что писать квадратичные алгоритмы вместо линейных — это таки большое зло. И стреляет потом очень больно, и разбираться и чинить придётся в дикой спешке и, возможно, в нерабочее время, ибо прод горит, а деньги улетают в трубу тоннами в секунду.
Что конечно никак не обосновывает необходимость задротства на литкоде
Тем же, что и везде. Работал в Маркете бэкендером на Java. Когда устраивался, описанное выше ещё задачками на сообразительность разбавляли. Писал всякие API, "перекладывал JSON'ы", добавлял в БД таблички и писал к ним запросы, иногда писал и фронт (с минимальным опытом в этом, но на внутренние проекты фронтов часто не дают), иногда что-то ковырял в местном map-reduce, настраивал местный недо-кубер, настраивал всякие графики (rps, тайминг, ошибки и пр.) и мониторинги по ним (тоже всё в основном самописное: "на наших масштабах готовые решения не тянут" ©), чинил баги и разбирался со всякими неожиданными (и иногда мистическими) проблемами с производительностью или неожиданными багами, когда при отключении одного ДЦ ложится вся, казалось бы устойчивая к этому, конструкция.