Comments 335
Про Люксофт и.т.п. — все сильно упрощено. Бывает и не так, и совсем не так. Я как работал в первом, так и нанимал из второго на проекты. Но как ориентир чего следует ждать — наверное годится.
для меня в Люксофте основным перпятствием был английский язык. С письменным у меня хорошо, но проверяли устный по телефону на бытовые темы (проверяли не программисты, а преподавательницы английского). А по телефону, с низким качеством звука, не очень-то разберешь, о чем спрашивают.
ну как бы и в реальной жизни довольно много общения будет по каналам связи, так что обстановка приближена к боевой
Это все решается на раз два, вам нужна неделя-две практики и воспринимать на слух станет куда проще. (если компания международная то внутри нее наговорить не проблема) Кстати это вам никак не поможет если у вас не было опыта разговора с индусами или англичанами, с ними еще плюс столько же.
Ищутся онлайн курсы, где лектор — индус и воспринимать становится значительно проще.
Вот то, что с английским делают французы, это действительно боль.
Вот то, что с английским делают французы, это действительно боль.
Большинство англоязычных бесплатных курсов по BigData читают индусы, причём с разными акцентами — отличная практика (практически всегда — с субдитрами на английском).
Заодно и расширить границы познания.
Заодно и расширить границы познания.
Испанский и китайский варианты английского, имхо, ещё грустнее.
Испанский не слышал, но японский вариант куда хуже китайского, вживую довелось пообщаться с японцем и китайцем, с китайцем мы довольно быстро нашли общий язык и примерно в равной степени не понимали английский друг друга, а вот что говорит японец я ну никак не мог понять, сказывается их привычка перекладывать английский на звуки японского алфавита.
Они серьезно говорят что-то вроде «Са-ба», или это из разряда городских айтишных баек?
Да, server — сарва (ну или са-ва, да), database — дэтабейсу, client — кураянт и т.д. и т.п. Еще сильно мешало то, что начинаешь переспрашивать — входит в ступор, но это может особенность конкретного японца :)
если они говорят на японском — да, так слова заимствуются.
Если два класса японцев: те, которые общались с нэйтив спикерами, и те которые не общались.
У них просто в языке в принципе не бывает две согласлых подрят (за исключением «н», кажется). И все слога открытые. Ну и «л» и «р» — это один звук.
И при этом английские слова они любят… но странною любовью. Вот возьмите To Love-Ru. Что это вообще может значить? А это, оказывается «Trouble».
Вот для вас «To Love-Ru» и «Trouble» похожи? Хотя бы отдалённо? А для японца — они вообще одинаково читаются…
Но это если они в японской фирме работают. Если они найтив спикеров слышат (работают в Google или Microsoft), то уже через год говорят почти без акцента.
У них просто в языке в принципе не бывает две согласлых подрят (за исключением «н», кажется). И все слога открытые. Ну и «л» и «р» — это один звук.
И при этом английские слова они любят… но странною любовью. Вот возьмите To Love-Ru. Что это вообще может значить? А это, оказывается «Trouble».
Вот для вас «To Love-Ru» и «Trouble» похожи? Хотя бы отдалённо? А для японца — они вообще одинаково читаются…
Но это если они в японской фирме работают. Если они найтив спикеров слышат (работают в Google или Microsoft), то уже через год говорят почти без акцента.
Все японцы, с которыми я общался, принципиально говорили только на японском. Возможно. повезло.
del
Самая жесть — это нэйтивы из разных окраин GB. Шотландцы и всякие такие товарищи. Ну просто ужас. Говорят быстро, употребляют сложную лексику, и совершенно непонятно. У иностранцев с неродным английским лексика беднее и говорят проще — там достаточно врубиться в акцент. А тут и акцент и все в одном флаконе.
Индусы вполне нормально говорят. Самое сложное было с итальянцами, т.к. они и на английском говорят очень быстро и ты просто не успеваешь осознавать что он говорит. Помогает только полное отключение мозга и полное забывание всех остальных языков, ибо на это уже времени не остается.
а меня как-то собеседовала по телефону рекрутер из Великобритании. А у них как будто совсем другой телефонный кодек используется и звук в телефоне звучит очень непривычно.
В общем, не взяли меня туда.
В общем, не взяли меня туда.
Для Люксофта собеседование велось (по состоянию на два года назад, как сейчас обстоят дела — не знаю) на конкретный проект его менеджером и тимлидом (или старшим специалистом). Технические интервью были по технологиям, использующимся на проекте, и о том, насколько кандидат ими владеет. Спрашивали о конкретных задачах, которые решал кандидат на прошлых проектах. Впрочем, какие вопросы задавать решал интервьюер. На некоторых проектах могли и по теории погонять, и задачки позадавать.
Что важно — в компаниях такого рода собеседование ведется руководством проекта и на конкретный проект. Переброска между проектами, о котором здесь говорилось (т.н. Internal Mobility) по сути мало отличается от приема на работу внешнего кандидата: те же собеседования и с теми же людьми.
Что важно — в компаниях такого рода собеседование ведется руководством проекта и на конкретный проект. Переброска между проектами, о котором здесь говорилось (т.н. Internal Mobility) по сути мало отличается от приема на работу внешнего кандидата: те же собеседования и с теми же людьми.
UFO just landed and posted this here
с завидной периодичностью возникают посты от возмущенных программистов, которые справедливо (наверное) негодуют, почему на собеседовании никто не спросил про их прошлые проекты, не посмотрел их код,
Код который программист выложит для просмотра работодателем, может быть написан кем угодно. И даже если написан самим кандидатом то может в корне отличатся от того что тот заливал в прод каждый день.
… но задавал шаблонные справочные вопросы или заставлял решать алгоритмические задачи, которые, скорее всего (в 99%), не будут применяться на вакантной работе.
Я вот очень долго над этим думал и пришёл к выводу что тут всё логично. Вопросы по алгоритмам задаются не от хорошей жизни. Работодатель может не знать того фреймворка с которым работал кандидат. Потом, у работодателя скорее всего другой фреймворк. Получается что работодатель не может правильно оценить кандидата в немного другой сфере, которую он не знает. А кандидат скорее всего не ответит на вопросы о фреймворке работодателя. Итого, рассказывать\спрашивать что то о вещах из повседневной работы рискованно. Можно не найти общий язык.
Поэтому, среди возможных остаются вопросы по тонкостям языков программирования и по теоретической базе, которая должна быть у любого кто серьёзно изучал программирование. А те кто изучал несерьёзно нафиг не нужны. ФормоШлёпов и своих обычно хватает.
Большинство того что спрашивают на собесах это не rocket science, а умещается всего в 2-х книгах на темы: паттерны ООП, алгоритмы. Надо всего лишь осилить две книги, чтобы пройти 60-70% собеседований. И это не обязательно должны быть самые сложные книги в своём роде.
Код который программист выложит для просмотра работодателем, может быть написан кем угодно.
Да ладно? Три уточняющих вопроса на собственно собеседовании прояснят это за 60 секунд.
И даже если написан самим кандидатом то может в корне отличатся от того что тот заливал в прод каждый день.
Компания должна создать кандидату именно что условия, в которых он пишет тот код, который понравился. И компании это нужно гораздо больше, чем самому кандидату.
Работодатель может не знать того фреймворка с которым работал кандидат.
Я не представляю себе фреймворк (да, даже язык, если честно), на котором я не смог бы разобрать и оценить код, предоставленный кандидатом, которого я собеседую.
теоретической базе, которая должна быть у любого кто серьёзно изучал программирование.
У хаскелиста, джаваскриптовика, шарписта и эмбедщика эти базы имеют примерно ноль пересечений. Глубокое знание ООП для наших задач, например, я бы вообще отнес в минусы (как и склонность гоняться за наносекундами у эмбедщиков).
Я не представляю себе фреймворк (да, даже язык, если честно), на котором я не смог бы разобрать и оценить код, предоставленный кандидатом, которого я собеседую.
Например если вы не работали с Qt то вам будет сложно с разбегу понять всякие делегирования, модели данных и пр. залёты. Это всё даже разрабы с опытом иногда не понимают.
У хаскелиста, джаваскриптовика, шарписта и эмбедщика эти базы имеют примерно ноль пересечений.
Было бы неплохо если все они будут знать сложность алгоритмов. Иначе могут влепить какой нибудь алгоритм который, вроде как работает в тестах, но в проде завешивает весь сервис.
Было бы неплохо если все они будут знать сложность алгоритмов. Иначе могут влепить какой нибудь алгоритм который, вроде как работает в тестах, но в проде завешивает весь сервис.
Я уже много беседовал на эту тему со свидетелями Священной Big O, и мне довольно-таки надоело, но напишу еще раз тут: для фронтэндера, например, вопрос знания сложности алгоритмов в лучшем случае примерно третий по важности, и на собеседовании особо не значим. Почему? Потому что высокая алгоритмическая производительность на фронтэнде иногда нужна, но весьма редко; а вот знать, как браузер грузит ресурсы и рендерит страницу — нужно практически для любого реального проекта. Быстродействие будет определяться именно этими двумя вещами, а не тем, что вы где-то там внутри дуболомно изобразили O(n!), вот только n всё равно выше десятка не вырастет даже в теории.
ЗЫ: Я, к слову, уже встречался в реальности со свидетелями Священного Big O, которые ради того, чтоб нарисовать таблицу ячеек так на 10К, фигачили собственные хешмапы (дело еще было до того, как в JS появился стандартный) и прочую порнографию. Таблица при этом нещадно тормозила, потому что в big O пацаны смогли, а в оптимизацию рендера нет. И перерисовывали все 10К ячеек по любому изменению.
Я уже много беседовал на эту тему со свидетелями Священной Big O, и мне довольно-таки надоело,
Я по большому счёту не утверждаю хорошо это или плохо. Мой поинт был в том что всё это вполне можно осилить даже несмотря на очевидную ненужность.
Мой поинт был в том что всё это вполне можно осилить даже несмотря на очевидную ненужность.
Осилить можно что угодно — от лямбда-исчислений до борьбы с компилятором за каждый байт памяти. Беда только в том, что этого настолько много, что на осиливание всего вам не хватит всей жизни. А на освежение памяти относительно того, что вы осилили — так и еще меньше. И когда вы с каким-то набором знаний приходите на собеседование, а там у собеседующего очень даже свои представления о том, что, как ему кажется, кандидат мог бы осилить — вот там и начинаются нестыковки.
Эх, как с языка сняли!
Лично у меня было около 20-и собеседований по теме С++ за последние три года. На английском, русском, заочно, с работодателями, заказчиками и всяким мудачьём, которое просто хотело получить консультацию бесплатно.
Большинство этих собеседований успешно прошёл. И на основании этого сделал выводы, что нужно знать что бы пройти. Собсно этими выводами я и поделился выше.
А вы мне пытаетесь доказать как оно должно быть. Да мне оно без разницы, как это всё должно выглядеть. Я не собираюсь изменять мир трудоустройства к лучшему и кого то персонально убеждать.
Не нравится моё личное мнение — пожалуйста.
Большинство этих собеседований успешно прошёл. И на основании этого сделал выводы, что нужно знать что бы пройти. Собсно этими выводами я и поделился выше.
А вы мне пытаетесь доказать как оно должно быть. Да мне оно без разницы, как это всё должно выглядеть. Я не собираюсь изменять мир трудоустройства к лучшему и кого то персонально убеждать.
Не нравится моё личное мнение — пожалуйста.
Большинство того что спрашивают на собесах это не rocket science, а умещается всего в 2-х книгах на темы: паттерны ООП, алгоритмы. Надо всего лишь осилить две книги, чтобы пройти 60-70% собеседований. И это не обязательно должны быть самые сложные книги в своём роде.Ну вот вы написали «умещается в 2-х книгах». Можете хотя бы назвать, в КАКИХ книгах? Или это некие гепотетические книги, которые мог бы написать человек с уже имеющимся 10-летним опытом?
Про «паттерны ООП» это одна книга — ru.wikipedia.org/wiki/Design_Patterns на худой конец можно и википедию поштудировать.
Про алгоритмы и структуры данных книг много. Есть даже видеолекции на английском. Это тема сложная, поэтому попробуйте все что найдете. Самой простой книгой считается «Грокаем алгоритмы. Иллюстрированное пособие для программистов и любопытствующих»
Я бы НЕ советовал книги Седжвика по алготитмам. У него язык изложения и переводы ИМХО читаются очень плохо.
В процессе изучения можно подглядывать на youtube по отдельным темам, если совсем тяжело доходит.
Про алгоритмы и структуры данных книг много. Есть даже видеолекции на английском. Это тема сложная, поэтому попробуйте все что найдете. Самой простой книгой считается «Грокаем алгоритмы. Иллюстрированное пособие для программистов и любопытствующих»
Я бы НЕ советовал книги Седжвика по алготитмам. У него язык изложения и переводы ИМХО читаются очень плохо.
В процессе изучения можно подглядывать на youtube по отдельным темам, если совсем тяжело доходит.
Что про Скиену скажете? Кнута я не осилил, искал лайт-версию.
Что про Скиену скажете?
Даже не слышал про такого. А «лайт-версий» вполне достаточно. Надо только найти, которая из них влезает в голову.
Я вот про эту говорил, если вдруг кому интересно. Доступно, понятно, с примерами из практики, жаль, что обзор популярных библиотек подустарел.
Вообще говоря, применительно к собеседованиям все в одной книге помещается: «Cracking the Coding Interview» Gayle Laakmann McDowell. Плюс несколько сотен задач с leetcode.com.
свидетелями Священной Big O
Омг, я вас цитировать буду) Я их адептами называл, но так гораздо лучше)
И перерисовывали все 10К ячеек по любому изменению.
А это самая частая ошибка на фронте и по сей день. И даже крутые фреймворки не спасают, хотя уже все сделали, чтобы этого было поменьше.
Может быть как раз изза того, что ребятки, которые ваяют классные фронты, не проходят собеседования с выкрутасами вроде: «отсортируйте пузырьком имея только каменный топор и березу», расплодилось такое дикое количество сайтов с фронтом, писанным левой пяткой пушистых тапочек.
отсортируйте пузырьком имея только каменный топор и березу
Мощно задвинул! :)
Как-то я эти страхи не разделяю, о том что вот кандидата не спросим ничего по алгоритмам и он нам повесит весь прод. Если у вас код ревью в принципе нет, то так, конечно, может случиться, но в реальной жизни, с нормально поставленной разработкой такого не стоит бояться.
Да и подавляющее большинство задач, которые реально решаются, не требует оптимизации. Выгрести данные запросом, протащить их по всем слоям сервиса, отмаппить их в DTO и отдать через API наружу… Обычно там все шаблонно и данных на каждом этапе немного (ибо пагинация) — сложно так налажать что-бы все ну совсем плохо стало.
Насчет «большинства задач»… Ну не знаю… Сильно зависит от предметной области. Мне в этом смысле «везло» (или везло — тут как посмотреть). Долгое время работал в промавтоматизации — там постоянно сталкиваешься с жесткими таймаутами. Не уложился — тебя послали. Разрыв соединения, реконект, перепосылка пакета и все такое прочее. Посему — будь добр извернуться, но все необходимые действия уложить в отведенное время.
Сейчас работаю с высоконагруженными системами. Не сказать что 100%, но есть отдельные задачи, которые должны быть оптимизированы до предела. Иначе… Ну вот из недавнего — у одного из банков в период предновогоднего пика транзакций на пару часов перестали проходить платежи по пластику.
Хорошо это для банка? Очень нехорошо. Нет, денег ни у кого не пропало. Ни копейки. Все в конечном итоге отработало, но репутационные потери налицо. Клиенты недовольны — пришел в магазин перед НГ закупиться, а расплатиться картой на кассе не можешь…
И там тоже вопрос был в оптимизации одного модуля.
Понятно, что такое не везде и не всегда, но есть области где налажать неоптимальным кодом можно запросто и достаточно серьезно. И этот момент приходится постоянно держать в подсознании когда что-то пишешь. Т.е. первый проход — как написать чтобы работало, второй — а можно написать чтобы работало быстрее и с меньшим ресурсопотреблением?
Сейчас работаю с высоконагруженными системами. Не сказать что 100%, но есть отдельные задачи, которые должны быть оптимизированы до предела. Иначе… Ну вот из недавнего — у одного из банков в период предновогоднего пика транзакций на пару часов перестали проходить платежи по пластику.
Хорошо это для банка? Очень нехорошо. Нет, денег ни у кого не пропало. Ни копейки. Все в конечном итоге отработало, но репутационные потери налицо. Клиенты недовольны — пришел в магазин перед НГ закупиться, а расплатиться картой на кассе не можешь…
И там тоже вопрос был в оптимизации одного модуля.
Понятно, что такое не везде и не всегда, но есть области где налажать неоптимальным кодом можно запросто и достаточно серьезно. И этот момент приходится постоянно держать в подсознании когда что-то пишешь. Т.е. первый проход — как написать чтобы работало, второй — а можно написать чтобы работало быстрее и с меньшим ресурсопотреблением?
Ну, оно очевидно, что там, где жесткие таймауты и требования к быстродействию, есть смысл спрашивать и про большое О и про аппаратные заморочки всевозможные и про опыт оптимизаций…
Мой спич был о том что все это часто требуют на вакансиях, где будешь месяцами перенаправлять байты из БД в REST, с помощью фреймворков, и где даже постаравшись будет очень сложно все это сильно замедлить использованием кривого алгоритма.
Мой спич был о том что все это часто требуют на вакансиях, где будешь месяцами перенаправлять байты из БД в REST, с помощью фреймворков, и где даже постаравшись будет очень сложно все это сильно замедлить использованием кривого алгоритма.
Согласен, что на собеседованиях часто просто тупо лупят по взятому откуда-то шаблону, абсолютно не задумываясь насколько этот шаблон применим к специфике работы в данной конторе.
Вообще, попасть на хорошее собеседование та еще удача, как я понял. И, опять же, иногда если не прошел через собеседование, то думаешь — вот и слава богу что не прошел. Не хочу я тут работать.
Было у меня такое один раз…
Вообще, попасть на хорошее собеседование та еще удача, как я понял. И, опять же, иногда если не прошел через собеседование, то думаешь — вот и слава богу что не прошел. Не хочу я тут работать.
Было у меня такое один раз…
Ой, можно у Вас стащить "левую пятку пушистых тапочек"? https://cv1.pikabu.ru/video/2020/01/26/1580040782263219333_458x658.webm
И перерисовывали все 10К ячеек по любому изменению.
Но ведь это и называется "не смогли в Big O".
Это классическое «к пуговицам претензии есть?!». У них в коде — всё прекрасно и минимальная алгоритмическая сложность, а что происходит за границами их кода — им не очень интересно было. Самое забавное, что я одного из этих прошлых авторов лично спрашивал — мол, а зачем это всё, если у вас перерисовка кривая? На что мне было сказано, что чёт всё медленно было, а значит надо было улучшить сложность! Ну и улучшили, только быстрее не стало. Отчитались, что они молодцы, а проблемы все на стороне браузера.
Ну так и проблема-то, получается. именно в этом подходе "к пуговицам претензии есть?!", а не в Big O.
Тем более что на самом-то деле именно их код был алгоритмически неоптимален.
Вот я знаю про Big O, а при этом уже сколько времени работаю, но каждый раз когда на проде обнаруживается какой-то завтык — у меня инстинктивное желание вопить про «неэффективную структуру данных» и что нам нужно немедленно всё останавливать и денормализовать всю структуру в БД для оптимизации под чтение (прямо как нас в универе учили!), а опытные коллеги вместо этого просто вставляют очередной индекс, получают 10-кратный прирост к производительности и спокойно работают дальше. Уже сколько раз себя по рукам бил, а до сих пор желание не проходит.
Так что да, алгоритмы в вакууме — это хорошо, но практическое понимание мест, которые *имеет смысл* оптимизировать — всё-таки важнее.
Так что да, алгоритмы в вакууме — это хорошо, но практическое понимание мест, которые *имеет смысл* оптимизировать — всё-таки важнее.
Ну, индекс-то, если рассмотреть его уровнем ниже, и есть денормализация структуры хранения для оптимизации "под чтение"...
и что нам нужно немедленно всё останавливать и денормализовать всю структуру в БД для оптимизации под чтение (прямо как нас в универе учили!)
Извиняюсь, за глупый вопрос, последний раз базы трогал именно в универе. А как там можно ускорить чтение, помимо индексов?
Денормализация и избавление от джойнов в hot path часто помогают ускорить чтение. Но это после добавления всех возможных индексов, естесвенно.
Ps: Это не руководство к действию. Это тема для поговорить.
Спасибо за ответ. Что джойны лучше убрать, где можно, это понятно. Под денормолизацией понимается ввиду хранение не 2 таблиц, которые нужно джойнить, а сразу сджойненную? Извиняюсь за ещё один глупый вопрос.
К слову, у SQL Server есть индексированные представления, которые как раз и позволяют хранить сразу сджойненную таблицу. А в Enterprise-редакции он ещё и использует такие представления при оптимизации запросов, что превращает их во что-то вроде индекса по двум таблицам.
если это тема поговорить — то partitioning, clustering, parallel reading from different nodes, etc…
в некоторых базах данных нет явных индексов вообще, что не мешает читать со скоростью много гигабайт в секунду…
в некоторых базах данных нет явных индексов вообще, что не мешает читать со скоростью много гигабайт в секунду…
Типовой случай из Википедии да. На практике иногда достаточно одно поле перенести из одной таблички в другую. Или как уже написали materialized view сделать (если ваша база позволяет)
Как я понимаю, stanislav888 говорит не об умении работать с красно-чёрными деревьями, а о базовом понимании, что for внутри for внутри for это плохо.
Я уже много беседовал на эту тему со свидетелями Священной Big O, и мне довольно-таки надоело, но напишу еще раз тут: для фронтэндера, например, вопрос знания сложности алгоритмов в лучшем случае примерно третий по важности, и на собеседовании особо не значим. Почему? Потому что высокая алгоритмическая производительность на фронтэнде иногда нужна, но весьма редко; а вот знать, как браузер грузит ресурсы и рендерит страницу — нужно практически для любого реального проекта. Быстродействие будет определяться именно этими двумя вещами, а не тем, что вы где-то там внутри дуболомно изобразили O(n!), вот только n всё равно выше десятка не вырастет даже в теории.
Главное, чтобы потом не надо было отобразить табличку, в которой более 100 элементов. А ведь иногда ещё и 1000 может прийти. Очень не каждый выдержит такое. Jira и confluence вот не всегда справляются.
Я даже не представляю, как при отображении таблички получить что-то хуже n^2. А n^2 отобразит сколько угодно информации, сколько вообще имеет смысл показывать человеку за один подход; и узкое место опять таки будет не в n^2, а в рендере, если только вы каждую ячейку не заполняете чем-то вычислительно сложным, рассчитываемым прямо в клиенте. Впрочем, для этого уже даже wasm завезли.
Так в том-то и дело, что для рендера это самое n^2 на каждую перерисовку — это уже много. Даже n — и то иногда может оказаться много.
Скажу еще проще: в браузере рендер DOM-дерева таблицы на N ячеек в общем случае имеет очень плохую вычислительную сложность (потому что допускает многократный ре-рендер части таблицы, в максимально плохом случае при рендере каждой новой строчки произойдет ре-рендер всех предыдущих) с очень большой константой, против чисто вычислительных операций в JS. В частном случае (table-layout: fixed) — линейную, со всё так же большой константой. Чтоб ваши вычисления со сложностью m*N^2 стали более узким местом, чем браузерная перерисовка со сложностью M*N (M сильно больше m) — вам придётся очень сильно постараться. И это только table-layout: fixed, что уместно далеко не всегда.
Это всё, конечно, прекрасно, но я работал с табличками на 10000 строк. Да, грузятся они долго, конечно — но зато потом их листать можно быстро и нужное место находится легко.
А вы зайдите, пожалуйста, сюда и попробуйте пролистать вот это вот… не хочу ругаться матом.
А ведь там всего-навсего порядка 2000 картинок.
Так что, может, и нужно «очень постараться» — но почему-то людям, не умеющим в Big O это удаётся с трогательной регулярностью.
Причём чем «феншуйнее» страница и чем более модные технологии там использованы, тем больше шанс, что всё это будет тормозить нещадно и жрать память как не в себя.
Так что вы уж извините, но я останусь при своих: если человек не умеет писать программы без применения алгоритма маляра Шлемиэля — то его не нужно брать никуда. На на фронт, ни на бэк, никуда вообще.
Про фибоначчиевы кучи и алгоритм Шёнхаге — Штрассена при этом знать, в общем, необязательно…
А вы зайдите, пожалуйста, сюда и попробуйте пролистать вот это вот… не хочу ругаться матом.
А ведь там всего-навсего порядка 2000 картинок.
Так что, может, и нужно «очень постараться» — но почему-то людям, не умеющим в Big O это удаётся с трогательной регулярностью.
Причём чем «феншуйнее» страница и чем более модные технологии там использованы, тем больше шанс, что всё это будет тормозить нещадно и жрать память как не в себя.
Так что вы уж извините, но я останусь при своих: если человек не умеет писать программы без применения алгоритма маляра Шлемиэля — то его не нужно брать никуда. На на фронт, ни на бэк, никуда вообще.
Про фибоначчиевы кучи и алгоритм Шёнхаге — Штрассена при этом знать, в общем, необязательно…
А вы зайдите, пожалуйста, сюда и попробуйте пролистать вот это вот… не хочу ругаться матом.
Мы уже обсуждали это — убогая бесконечная лента на патреоне убогая как раз потому, что авторы не смогли в понимание, что там у них и как перерисовывается. И перерисовывается оно всё каждый раз с нуля при каждой догрузке ленты. Вот вы нажали на кнопочку «Load more» — и у вас вся лента сверху донизу перерисовывается, просто чтоб вместо кнопочки load more показать спиннер. А потом оно догрузится — и еще раз столько же.
При этом я почти уверен, что авторы не без основания считают, что в их собственном коде с алгоритмической сложностью всё прекрасно. Там наверняка ничего сложнее O(n) ;-)
При этом я почти уверен, что авторы не без основания считают, что в их собственном коде с алгоритмической сложностью всё прекрасно. Там наверняка ничего сложнее O(n) ;-)А вот это как раз и есть «неумение в Big O», как вам уже писали.
Вот вы нажали на кнопочку «Load more» — и у вас вся лента сверху донизу перерисовывается, просто чтоб вместо кнопочки load more показать спиннер. А потом оно догрузится — и еще раз столько же.Что, собственно, и является классическим «Шлемиэлем». И если уж люди такое допускают — то это действительно, не люди, умеющие в алгоритмы, а «свидетели Священной Big O».
Да, мне от «знания алгоритмов» нужно, чтобы человек умел избегать алгоритма маляра Шлемиэля (или умел доказывать что это невозможно там, где это невозможно). И все задачи, которые я даю — всегда именно на это.
А вовсе не на знание хитромудрых алгоритмов из вумных книжек.
А вот это как раз и есть «неумение в Big O», как вам уже писали.
Я бы не называл это «неумением в big O», потому что вполне может статься что при попытке это выяснить (каким-нибудь условным собеседованием или экзаменом) вы от такого человека услышите про big O в её академическом понимании больше, чем сами знаете.
Это неумение пользоваться выбранными инструментами — процессором, про что пишет Джоэл, или реактом, что наблюдается в ленте патреона. При этом совсем даже не стоит исключать того, что какими-то другими инструментами все эти же люди умеют пользоваться гораздо лучше. И еще не стоит забывать о том, что в зависимости от инструментов и создаваемого софта — будет вполне допустимо определенными инструментами не владеть или владеть крайне плохо, без каких-либо видимых последствий.
Я даже не представляю, как при отображении таблички получить что-то хуже n^2.
Ну уже n^2, в начале было факториал. :)
А вообще всё зависит от задачи и сценариев использования. Допустим у нас данных даже 10000, допустим даже таблица строится за квадрат (т.е. 10^10), это для процессора, который может выполнять десятки миллирдов операций (как раз таки 10^10) несколько секунд (если не считать рендеры, я не знаю, как они работают, туда не лезу). А потом кому-то надо с этой таблицей работать и на каждой перезагрузке получаем уже k*N^2, где k — число перезагрузок, что вызывает уже боль. А не дай бог, потребуется сделать операцию над каждой ячейкой и она будет перересовываться именно после каждой ячейки. Уже получаем куб. В общем я согласен с вами, что знание рендера очень важно, но квадраты пихать тоже не стоит.
Ну уже n^2, в начале было факториал. :)
Факториал был как абстрактный пример крайне плохой сложности, которая, однако, на малых n едва ли будет значима.
А потом кому-то надо с этой таблицей работать и на каждой перезагрузке получаем уже k*N^2, где k — число перезагрузок, что вызывает уже боль.
Лично у меня глагол «работать» не вызывает никаких ассоциаций с «давайте заново перестроим таблицу по квадратичной сложности». Что вы имеете в виду?
Глас вопиющего в пустыне… Людям, которые работают с простыми, очевидными, и прекрасно контролируемым условиями в back end, никогда не понять хаоса и дикого Запада front end.
Вы так говорите, как будто я front end не делал. Делал. И не раз. Нет там никакого хаоса. Хаос есть только в одном, всем известном месте — и он не имеет никакого отношения ни к back end'у, ни к front end'у.
До back end'а он недобирается исключительно в силу того, что люди, способные его устроить о его сушествовании не знают…
До back end'а он недобирается исключительно в силу того, что люди, способные его устроить о его сушествовании не знают…
До back end'а он недобирается исключительно в силу того, что люди, способные его устроить о его сушествовании не знают…
Нет, до бэка вся эта классика меньше доходит просто потому, что в бэке деление на «работает» и «не работает» чуть более определенное, в то время как на фронте прекрасное промежуточное состояние «работает в правильную фазу луны, при должных жертвоприношениях, и если не трогать красную кнопку» — оно частенько длится весь жизненный цикл продукта, и вполне себе удовлетворяет бизнес (а кого не удовлетворяет — перетопчутся).
Вы так говорите, как будто я front end не делал. Делал. И не раз. Нет там никакого хаоса.
При всём уважении, ваши слова только подтверждают разницу между "делал, и не раз" и "занимаюсь этим постоянно". Вы этот хаос или намеренно игнорировали, или просто не успели заметить.
Если даже не вдаваться в поэзию, то самый поверхностный анализ ситуации позволяет увидеть, что благодаря наличию:
- Различных браузеров, разных версий
- Различных платформ и устройств
- Абсолютно неконтролируемых сетевых условий
- Абсолютно неконтролируемых условий среды в браузере
… и т.д., и т.п., поверхность потенциально проблемной области в front end разработке в разы больше, чем в back end. Если не на порядки.
Просто для примера, из свежего: у вас в практике часто бывало, чтобы на серверной стороне в код без спросу внедрился случайный третьесторонний модуль и начал блокировать вызовы к каким-либо микросервисам? И его не убрать никак. А у нас это норма жизни, ad blockers или какие-нибудь расширения в браузере могут в любой момент поломать что угодно. И объясняй потом бизнесу, почему их интеграция с каким-нибудь Appcues не работает и как её починить (а починить нетривиально).
И таких ситуаций, факторов, ошибок, особенностей, да просто багов — сотни, тысячи их. И каждый день что-то новое.
Мы из Хаоса (tm).
Просто для примера, из свежего: у вас в практике часто бывало, чтобы на серверной стороне в код без спросу внедрился случайный третьесторонний модуль и начал блокировать вызовы к каким-либо микросервисам?
Забавно, но именно на бэке я с этой ситуацией и столкнулся впервые. KIS что-то портил в запросах к чужому серверу по HTTPS со сжатием (которое Content-Encoding), пришлось добавить настройку для отключения этого самого сжатия.
Это всё же не совсем то, о чём я говорил. Прокси-сервисы и middleware тоже ломаются иногда, настройки слетают, и всё такое.
Но в back end практически не бывает так, чтобы без каких-либо изменений в вашем коде/настройках/Dockerfile/K8s/whatever, вдруг внезапно всё сломалось и перестало работать.
А на frond end — легко. Домен третьесторонней интеграции кто-то добавил в чёрный список, и привет. Узнать об этом, кроме как из разъярённых воплей обиженных клиентов, вообще никак нельзя. Это не хаос?
А на frond end — легко. Домен третьесторонней интеграции кто-то добавил в чёрный список, и привет. Узнать об этом, кроме как из разъярённых воплей обиженных клиентов, вообще никак нельзя. Это не хаос?Нет, хаос — это когда вы начинаете на это реагировать. Нет, понятно, что если это список Роскомнадзора и у всех ваших клиентов ничего не работает — то придётся на это реагировать. Но тут явно не выполняется критерий «Узнать об этом, кроме как из разъярённых воплей обиженных клиентов, вообще никак нельзя».
А если этих пользователей — полпроцента и, в принципе, всё равно всё работает… то так ли уж важно и нужно на это реагировать?
Гугл какой-нибудь отлично «забивал» на пользователей Opera даже тогда, когда Opera была лидирующим браузером, а Гугл отчаянно боролся за российский сегмент (у них тогда даже пара центров разработки в России была).
И ничего — это не помешало ему вытеснить сначала Рамблер, а потом и Яндекс.
UFO just landed and posted this here
В России Яндекс как лидировал, так и остаётся лидером.Проснитесь, посмотрите на календарь, вдохните, выдохните… Уже довольно давно Яндекс не лидер.
Не без помощи ФАС, но даже на мобильниках стали.Уже нет. У вас сведения устарели. Идут споры о том когда Гугл обошёл Яндекс (в 2018м или 2019м), но факт уже зафиксирован фактически всеми.
Причём тут Рамблер, тоже непонятно.Рамблер вообще-то был лидером до Яндекса. А потом отошёл на второе место в списке поисковиков. И Google вначале должен был обойти его, потом уже только Яндекс.
Но в back end практически не бывает так, чтобы без каких-либо изменений в вашем коде/настройках/Dockerfile/K8s/whatever, вдруг внезапно всё сломалось и перестало работать.
Да регулярно. Просто на фронте — это адблоки и сотоварищи, а на бэке — это сисы, баги и кривые деплои у сторонних сервисов, проблемы у облаков, ДЦ, хостеров и т.п. В последний раз поперло куча падений по таймауту при обращении к базе в облаке на обновление записей, последний релиз за месяц до, последний деплой за неделю до. Ничего не делали, примерно 10% запросов падают по таймауту.
Нет, не то. Я не об этом говорю. Баги бывают, таймауты, переполнение базы, всё что угодно. Но это контролируемые условия. Есть проблема — вы её решаете, и всё работает взад. Баг можно пофиксить, базу можно подчистить или ещё ноду накатить, в сети QoS подвинтить или в чём там проблема была.
В front end нормой жизни является непредсказуемое и неконтролируемое изменение условий. Вот как с тем примером с Adblock. Вы на самом деле ничего не делали, правда! — а оно бац, и поломалось. Совсем. И не починить, потому что юзера не заставишь отказаться от Adblock, а домен не убрать из списка. Это не баг и не проблема с сетью. Это именно изменение ТЗ, на лету, постоянно.
Я же не пытаюсь выпендриться крутизной, я просто объясняю, что front end это очень особенная область в разработке софта. Тут царит хаос и непредсказуемость, которая требует выдержки и определённого склада характера. Если вам нравятся чётко поставленные задачи в CS стиле: ввод -> алгоритм -> вывод, а изменение ТЗ вызывает беспричинную раздражительность, то лучше во front end не заходить. Шишек набьёте, ЧСВ синяками покроется, и будете потом всем с умным видом рассказывать, какие они идиоты и как надо было всё делать вообще не так.
Но это контролируемые условия. Баг можно пофиксить, базу можно подчистить или ещё ноду накатить, в сети QoS подвинтить или в чём там проблема была.
Вы меня не поняли. На бэке неконтролируемые условие — это тоже обыденность, и по влиянию они точно такие же, как и adblock. Где-то кто-то что-то поменял и больше оно у вас не работает. И вы тоже не можете просто починить это, ибо чужой сервис не заставишь работать так, как хочется вам, приходится пложить костыли, вплоть до лютых извратов. Вся фишка в том, что баг может быть не у вас, база лагает по совершенно неопределенным причинам (с подозрением, что что-то наконфигурировали чужие админы, но никто в этом никогда не признается), а у вас на всем этом завязано куча десктпного софта, который пользователи обновляют когда рак на горе свиснет.
я просто объясняю, что front end это очень особенная область в разработке софта
Но вам все равно кажется, что на бэке трава зеленее, ибо там нет адблока. Забывая про других личностей, которые делают ровно ту же грязь, и имя им легион.
Если вам нравятся чётко поставленные задачи в CS стиле: ввод -> алгоритм -> вывод, а изменение ТЗ вызывает беспричинную раздражительность, то лучше во front end не заходить.
Неужели вы думаете так только на фронте? Даже когда софт пишется внутри компании, ровно те же самые проблемы: алгоритмы недодуманы, одна фича конфликтует с другой, таски переписываются и перетасовываются, требования меняются прямо на релизе, и т.д.
Шишек набьёте, ЧСВ синяками покроется, и будете потом всем с умным видом рассказывать, какие они идиоты и как надо было всё делать вообще не так.
Поздно советовать, был я там. И не только там был, и везде проблемы по независящим от тебя причинам. А сейчас рад быть там, где даже консольное окошко вижу не каждый день. Поверьте, любая третья сторона создает абсолютно одинаковые проблемы, хоть адблоком она называется, хоть админом Йоханом из Дели, хоть юзером Мартой из Бостона.
Вы меня не поняли. На бэке неконтролируемые условие — это тоже обыденность, и по влиянию они точно такие же, как и adblock. Где-то кто-то что-то поменял и больше оно у вас не работает.
В таком случае я не вижу, как это противоречит заявлению "front end это хаос". Даже более: поздравляю, у вас тоже хаос. :))
Но вам все равно кажется, что на бэке трава зеленее, ибо там нет адблока. Забывая про других личностей, которые делают ровно ту же грязь, и имя им легион.
Дался вам этот adblock, это просто один пример был. :) Мысль-то была очень простая: в front end разработке настолько часто встречаются неконтролируемые изменения условий, приводящие к кардинальным изменениям в софте и процессах, что это является нормой вещей. Делали приложение для десктопа и современных браузеров? Поздравляю, мы вчера подписали контракт на $1005000 с XYZ и им надо IE11. Упс, а Chrome пять минут назад обновился и теперь скроллинг не работает, срочно фиксить. А что, у вас сайт на телефонах не работает? Какая разница, что в ТЗ было, это вчера было! Что? Гугл поднял расценки на внедрённые карты, а у нас на них весь интерфейс завязан?
Ну и т.п. Куда уж тут до чуточку недопереоптимизированных алгоритмов, выкатить бы что-нибудь. :)
Неужели вы думаете так только на фронте? Даже когда софт пишется внутри компании, ровно те же самые проблемы: алгоритмы недодуманы, одна фича конфликтует с другой, таски переписываются и перетасовываются, требования меняются прямо на релизе, и т.д.
Я вам даже больше скажу: так вообще везде. Помнится, в начале 2000х, когда ВТБ по случаю прикупил себе Гута-банк, мне пришлось разворачивать колл-центр ВТБ24 с оборудования Гуты, но на площадке ВТБ. Сроки сжатые, нужное количество E1 пробросить не успевали, поэтому можно было только Voice-over-IP, новинку по тем временам. За неделю прошли все инстанции (в ВТБ! представляете?!), всё подписали, всё согласовали — стыковали сети, пограничку настроили, всё работает. Ещё за неделю телефоны развернули, сценарии прописали, всё готово к сдаче.
А потом накануне запуска безопасники ВТБ такие: а мы тут вот затылок почесали, короче, не нравится нам RTP этот ваш, небезопасный он. Вы там что-нибудь придумывайте, а мы вам порты на файрволле зарубили. Всего хорошего.
Вот 15 лет назад было, а до сих пор помню. Потому что такое резкое и несовместимое с разумом изменение внешних условий всё же не такое частое явление… Вне front end. :)
Поверьте, любая третья сторона создает абсолютно одинаковые проблемы, хоть адблоком она называется, хоть админом Йоханом из Дели, хоть юзером Мартой из Бостона.
Да ладно, ну что вы в самом деле. Проблема же не в разнородности проблем, а в их количестве. Как кто-то когда-то сказал, Quantity is a quality of its own. :)
В общем, не хочу показаться невежливым, но мне кажется, что дискуссия себя исчерпала. Давайте на том и закончим, всего хорошего.
Если бекэнд просто подготавливает статику для показа в витрине — наверное, вы правы.
У нас бекэнд общается с овердохрена сторонних сервисов, каждый из которых тоже апдейтится и может вдруг повести себя неадекватно. Прислать курс валюты в научной нотации с мантиссой, например, или поменять формат, или перестать слать контрольные суммы, или что угодно еще. И бекэнд должен адекватно вычистить мусор, консолидировать все данные, и испечь пирожок, который без проблем покажет фронт.
Причем, если отвалилась кнопка в витрине — мы узнаем об этом от раздасадованного клиента. А если мы вдруг курс валюты не проверим (по эвристикам и прочим ИИ) перед совершением транзакции — можно влететь на десятки миллионов евро.
Поэтому проблемы визуализации — это неприятно, но гораздо проще и безопаснее, чем проблемы бизнес-логики на бекэнде.
У нас бекэнд общается с овердохрена сторонних сервисов, каждый из которых тоже апдейтится и может вдруг повести себя неадекватно.
Может. Но это сторонние для вас сервисы. Этот замусоленный уже до дыр пример с Adblock был о другом: представьте, что у вас в своём облаке, своих контейнерах, своих сборках и своей JVM всё открыто нараспашку и можно внедрить любой сторонний код. Ну т.е. вообще любой, и в любой момент.
А если мы вдруг курс валюты не проверим (по эвристикам и прочим ИИ) перед совершением транзакции — можно влететь на десятки миллионов евро.
Ну вот именно об этом я и талдычу уже который день: вы контролируете эти условия. Вы можете реагировать на внешние события и нейтрализовать их в своём коде или ещё как-нибудь. Что-то сломалось? Починили. Ненадёжный источник данных? Обложили эвристиками, проверками и перепроверками. Это контроль над средой. Не идеальный, но контроль.
А у нас иногда проблему можно решить, а иногда нет. Вот никак. В гугле правила SEO тихо поменялись, и всё, вашему стартапу пришёл он самый, белый и пушистый. Лично знаю людей, которые на этом потеряли миллионы зелёных денег, и повезло, что не весь бизнес.
Поэтому проблемы визуализации — это неприятно, но гораздо проще и безопаснее, чем проблемы бизнес-логики на бекэнде.
Эту старую песню о главном можно продолжать очень долго, но front end это не только визуализация данных.
Вообще говоря, эта дискуссия ни о чём, и ни к каким выводам не приведёт, а обед давно уже остыл. Честно, давайте правда уже закончим. Всего хорошего.
Но в back end практически не бывает так, чтобы без каких-либо изменений в вашем коде/настройках/Dockerfile/K8s/whatever, вдруг внезапно всё сломалось и перестало работать.
Да ну?
Не, ну наверное, если весь бэк состоит из одного вашего кода, то оно да…
Но ведь бывает и так, что бэк — это сотни а то и тысячи задач, крутящихся на одном мейнфрейме и так или иначе между собой взаимодействующих. И ваша задача может прекрасно работать до тех пор, пока то-то не скатил свой патч, который сломался сам и сломал вашу и еще десяток других задач.
Чтобы этого избежать существует т.н. «интеграционное тестирование» (помимо компонентного, нагрузочного и бизнес).
Но ведь бывает и так, что бэк — это сотни а то и тысячи задач,
Бывает, конечно бывает. И так бывает, и сяк бывает, хаос и энтропия никого не оставят в покое. Просто я всё время наблюдаю со стороны, как жизнь идёт у наших back end/platform/devops товарищей, которые всё время ужа с ежом скрещивают… Спокойнее у них там, гораздо. :)
Иногда даже подумываю, а не плюнуть ли на всё, натянуть Golang какой-нибудь на голову и податься через забор. Но скучно там всё же, когда привык к адреналину, размеренная жизнь как-то не цепляет уже. Да и плюшки с этой стороны вкуснее. :)
Ну я не знаю за ваш бэк, а у нас голангом не обойдешься. Будте любезны для начала RPG освоить, да еще научиться читать свободно чужой RPG код на древнем fix формате, потом желательно C/C++ потом вникнуть во все «нефункциональные требования» — что можно а что нельзя сточки зрения эффективности.
А чтобы стать действительно хорошим рабаботчиком на бэке, забдте про все фреймоворки — из тут нет и учите потроха AS/400 — что там и как работает. Ибо одним языком тут не обойдешься, придется вникать в системные API.
Ну и примите во внимание, что на сервере кроме вашей еще тысячи задач крутятся и все они между собой взаимодействуют так ли иначе. Один журнальный монитор чего стоит…
Ну и внешние сервисы, да… Скажем, получили некоторую строку, закинули ее в таблицу, она оттуда автоматом через очередь улетает на парсинг в некйи внешний сервис, оттуда опять через очередь прилетает обратно вам… И не дай бог в этом внешнем сервисе что-то поменялось… Вдруг. Разгребать придется опять вам.
Так что везде свои тараканы. Эт только со стороны кажется что все тихо и спокойно.
А чтобы стать действительно хорошим рабаботчиком на бэке, забдте про все фреймоворки — из тут нет и учите потроха AS/400 — что там и как работает. Ибо одним языком тут не обойдешься, придется вникать в системные API.
Ну и примите во внимание, что на сервере кроме вашей еще тысячи задач крутятся и все они между собой взаимодействуют так ли иначе. Один журнальный монитор чего стоит…
Ну и внешние сервисы, да… Скажем, получили некоторую строку, закинули ее в таблицу, она оттуда автоматом через очередь улетает на парсинг в некйи внешний сервис, оттуда опять через очередь прилетает обратно вам… И не дай бог в этом внешнем сервисе что-то поменялось… Вдруг. Разгребать придется опять вам.
Так что везде свои тараканы. Эт только со стороны кажется что все тихо и спокойно.
А у нас это норма жизни, ad blockers или какие-нибудь расширения в браузере могут в любой момент поломать что угодно. И объясняй потом бизнесу, почему их интеграция с каким-нибудь Appcues не работает и как её починить (а починить нетривиально).И вот мы снова возращаемся к источнику хаоса. И нет, это не ad blockers и не расширения. Это бизнес (или, вернее, менеджеры), который всё время «хочет странного». Нет проблем в том, чтобы составить список браузеров, которыми пользуются 95% пользователей и список расширений, которыми, суммарно, пользуются не более 10-15% пользователей — и забить на них. Вот просто забить большой болт и всё.
Но почему-то заявление о том, что наш back end работает с MySQL или PostgreSQL, но никак не с mSQL — воспринимаются нормально… а заявления о том, что HuyanPinyanBrowser не поддерживается — приводят к истерике. Хотя доля у того HuyanPinyanBrowser'а меньше, чем у mSQL… но он предустановлен на любимом ноуте директора — и потому получает самый высокий приоритет.
Это бизнес (или, вернее, менеджеры), который всё время «хочет странного».
С точки зрения этого бизнеса (или, вернее, менеджеров), вы тоже всё время хотите чего-то странного. Зарплаты, например.
Вот просто забить большой болт и всё.
Я хочу вдаваться в подробности на тему, почему "забить большой болт и всё" нельзя. Это отдельная большая тема.
Я вам о другом говорю: забить большой болт не работает. Можно забивать сколько угодно, это не поможет. Никак. Потому что у 95% пользователей всё равно будут разные браузеры, разные платформы, и разные устройства. От мощных десктопов до туповатеньких Chromebook, от последних iPhone до дешёвых китайских клонов какой-нибудь младшей модели Samsung Smartwatch. Какие критерии вы предлагаете использовать для исключения тех и этих, чтобы ваша жизнь была попроще? Назад в будущее, к This site is best viewed in IE6?
По вашим словам мне очевидно, что вы просто не владеете предметной областью. Так и должно быть, front end не ваша специализация. Это моя специализация, и я отлично знаю из опыта и толстой мозоли на лбу, почему нельзя "просто взять и сделать" сайт, чтобы всё работало и все были довольны.
Я стараюсь не вспоминать о битвах с нативным скроллингом документа, который есть сущее, адское зло — а виртуальный скроллинг это тоже сущее, адское зло. У меня в печёнках сидят поля ввода в HTML, обработка фокуса, маски и валидирование значений. Меня тошнит от touch events, от распознавания жестов по таймауту и ловли утёкших таймеров (ручками, всё ручками!). Я молча посылаю пламенные лучи ненависти и поноса в сторону HP, Lenovo и прочих умников, выпускающих лаптопы с тачскринами, которые никак особенно не определяются в браузере и потом к чертям ломают всю обработку событий, потому что смешать pointer events и touch events это — а чо, у нас в Windows работало? Я плачу кровавыми слезами каждый раз, когда мне нужно лезть в caniuse.com и подтверждать, какие фичи из CSS3 работают в последнем мобильном Сафари, а какие нет. И т.д. и т.п., конца и края этому нет (и не будет).
Можно всё это игнорировать, для личных проектов сойдёт — кому они нужны, кроме вас. А для коммерческих проектов не сойдёт, и игнорировать уже не получится. Добро пожаловать в добрый, светлый мир front end. :)
С точки зрения этого бизнеса (или, вернее, менеджеров), вы тоже всё время хотите чего-то странного. Зарплаты, например.Зарплата была моим условием при заключении контракта, извините. А бонусы редко когда бывают сравнимы с теми, которые получают люди, умеющие эффективно выводить деньги из фирмы в свой карман.
Так с какого перпугу я должен перед этими людьми бить чечётку?
Я хочу вдаваться в подробности на тему, почему «забить большой болт и всё» нельзя. Это отдельная большая тема.Ну так если хотите — так и сделайте. Кто мешает? Вдавайтесь…
Потому что с одной стороны — я вижу рассказы про то, что нужно вот обязательно делать всё «феншуйно» с использованием кучи костылей, а то, не дай бог, отпадут три с половиной пользователя, который пользуются странным антивирусом на ноуте Lenovo с тачскриром… с другой стороны — наблюдаю не работающий уже неделю в Firefox ESR 68.4 интерфейс перевода денег с карты на карты в Yandex.Money… ну и как это сочетается, извините?
Я работал в конторах, которые стремились поддерживать все эти «странные» браузеры и «странных пользователей»… и таких, которые этого не делали.
Практическая разница — во вторых работать гораздо спокойннее… и не скажу, чтобы с сильной потерей зарплаты. А если они существуют «в количестве» (а они таки существуют) — то «забивать болт» вполне можно.
Какие критерии вы предлагаете использовать для исключения тех и этих, чтобы ваша жизнь была попроще?А очень простой критерий — делайте всё так, чтобы оно работало. И всё. И не пытайтесь добиваться попиксельного совпадения с кем-то придуманной «концепцией».
Назад в будущее, к This site is best viewed in IE6?То, что реально нужно для реализации функциональности большей части сайтов отлично отрендерит и IE6. Напоминаю что в 2004м, когда появился GMail — это был самый популярный браузер… и уже тогда там был и приличный интерфейс и загрузка писем в фоне и многое другое.
Для всего этого не нужно использовать «модные» фишки новейших фреймворков и кучу транспайлеров, порождащих в итоге мегабайты кода, с которыми потом еще-еле работают даже топовые системы.
Это моя специализация, и я отлично знаю из опыта и толстой мозоли на лбу, почему нельзя «просто взять и сделать» сайт, чтобы всё работало и все были довольны.И почему же? Вот конкретно: почему в 2004м со всеми этими MS IE 5 и Netscape 4.8 это было сделать можно, а потом вжух — и сразу стало нельзя?
Ответ: потому что в те времена ответ от службы поддержки на тему «ваш сайт работает на моей загаженной системе со 150 расширениями и кучей добра» был простым: «пожалуйста, воспроизведите проблему на чистой установке Windows и без установленных расширений в браузере». И всё. Нет никакого хаоса.
Просто все забыли старую истину:
If users are made to understand that the system administrator's job is to make computers run, and not to make them happy, they can, in fact, be made happy most of the time. If users are allowed to believe that the system administrator's job is to make them happy, they can, in fact, never be made happy.
Вот фронтендер — он сейчас исполняет роль тогдашнего администратора. Если он чётко решает задачу: сделать определённые операции возможными и удобными — это можно сделать легко, а никакого излишнего хаоса на этом пути не возникает. Если же он пытается сделать так, чтобы «все были довольны» — то в конечном итогде довольных не будет совсем. Все будут чем-то всё равно недовольны — просто разными вещами.
А для коммерческих проектов не сойдёт, и игнорировать уже не получится.А почему не получится, собственно? Вы так уверенно про всё это рассказываете, как будто я не могу зайти на какой-нибудь lwn.net с этого самого вашего ноутбука с тачскрином и почитать там новости. Могу прекрасно.
А вот на сайты, сделаннаые профессионалами типа вас — не могу. Они разваливаются и глючат.
И не потому что профессионалы плохо знают фичи CSS3… а потому что в попытке провести семь перпендикулярных линий, придуманных заказчиком — они наворачивают такого… добра, что потом это никакое количество костылей не в состоянии заставить работать без глюков.
Вот, собственно, и всё.
На бекэнде можно такой же бардак и гемор себе устроить. Легко. Разрешите вашим контрагентам присылать данные в
.xlsx и трахайте бекондерам (а не контрагентам) мозги, когда что-то работает неправильно… только почему-то этот подход — непопулярен, а вот десять слоёв костылей, нужных для того, чтобы документ вёл себя не так, как хочет разработчик браузера, а так, как хочет левая пятка младшего помощника — это нормально.Зарплата была моим условием при заключении контракта, извините.
Так с какого перпугу я должен перед этими людьми бить чечётку?
В вашем контракте не написано, что вы работаете работу за зарплату? Или вам просто так платят, за красивые глаза? Вам ставят задачи, вы их решаете. Не будете решать — уволят, наймут другого.
Ну так если хотите — так и сделайте. Кто мешает? Вдавайтесь…
Это очепятка была. Не хочу я вдаваться в эти подробности.
с другой стороны — наблюдаю не работающий уже неделю в Firefox ESR 68.4 интерфейс перевода денег с карты на карты в Yandex.Money… ну и как это сочетается, извините?
Да легко: кто вообще пользуется этим дурацким Firefox? Полтора пользователя, которые никому не нужны?
То, что реально нужно для реализации функциональности большей части сайтов отлично отрендерит и IE6.
Ваша самоуверенность вполне типична для back end разработчика, который заглядывал во front end пару раз, не осилил, и теперь делает очень категоричные заявления о том, что реально нужно для большей части сайтов.
Нет, ну ей-богу, скучно. На том давайте и закончим, всего хорошего.
В вашем контракте не написано, что вы работаете работу за зарплату?Нет — про «работать работу» там не написано. И про «исполнение всех хотелок» — тоже.
Вам ставят задачи, вы их решаете. Не будете решать — уволят, наймут другого.Вы знаете — в контору, которая так ставит вопрос я и сам работать не пойдут. Потому что, как я уже сказал, 90% «хотелок» — просто бессмысленны. И нужно не думать как их сделать, что сделать вместо них. Как в в известной статье:
Хороший дизайнер интерьера постоянно приносит эскизы клиенту и вещи, из которых он может выбрать. Но они никогда не обсуждают с клиентом расположение посудомоечной машины. Она находится рядом с умывальником и не важно, чего хочет клиент. Нет смысла тратить время на обсуждения, где должна находиться посудомоечная машина — она должна быть рядом с умывальником, даже не начинайте разговор об этом; пусть клиенты изливают свои дизайнерские потуги делая какие-то безвредные вещи вроде изменения своего мнения 200 раз о том, нужно ли использовать для столешницы итальянский гранит или мексиканскую плитку, или норвежскую древесину.
Вот то же самое и с фронтэндом (да и с бекэндом и с чем угодно): если у заказчика возникают странные идеи (типа установки этого этой самой машины на чердаке), потому что он вычитал что это будет клёво — вы это просто игнорируете. Через неделю он всё равно всё забудет. Если клиент дотошный и всё перепроверяет — делаете так, чтобы всё было по спецификации, но работать с этим было невозможно. Он сам откажется.
Делать нужно то, для чего вы понимаете какова будет конечная цель. И нет, «так написано в документе, который мы согласовали после трёх совещаний» — это нифига не конечная цель. Конечная цель — она от бизнеса зависит. От того, как он деньги зарабатывать собрался. Если у вас нет цепочки, связывающей заработанные деньги с теми требованиями, что у вас на столе — то это всё вообще не требования, которые нужно исполнять, а «хотелки».
Это очепятка была. Не хочу я вдаваться в эти подробности.А надо бы. Потому что хаос возникает там и только там, где вы допускаете его возникновение.
Да легко: кто вообще пользуется этим дурацким Firefox? Полтора пользователя, которые никому не нужны?Принимается. В рамочку и на стену. А теперь посчитаем: Firefox пользуются 9.92% пользователей. И на них забили. То есть «порог отсечения» у нас — что-то в районе 3-5%. Теперь вы тут рассказываете про «мозоль на лбу»… у какого процента пользователей эти самые ноутбуки с тасчринами от HP или Lenovo? 0.1%? 1%? Вряд ли больше.
Ну а тогда они отлично идут туда же, куда и пользователи Firefox. И всё. И нет хаоса.
Если бизнес принесёт статистику, где покажет, что вот конкретно у вас таких пользователей 50% (ну например вы делаете сайт для школ, а им централизованно такие лапотомы закупили) — тогда да, придётся корячиться.
Но у вас не могут быть одновременно 50% пользователей с лаптопами HP или Levono, 50% пользователей iPhone и 50% пользователей Android. Математика, знаете ли.
Так что снова никакого хаоса.
Разруха — она не в клозетах, разруха — она в головах.
Ваша самоуверенность вполне типична для back end разработчика, который заглядывал во front end пару раз, не осилил, и теперь делает очень категоричные заявления о том, что реально нужно для большей части сайтов.С вашей самоуверенностью в том, что никаких других программистов, кроме фронтэндеров и бакэндеров в природе не бывает — это всё равно не сравнить.
Видимо компиляторы или, скажем, софт для вашей стиральной машины — они самозарождаются. Ну или может их эльфы в другой вселенной пишут.
Если вы относите в категорию «не осилил» отказ от игры в игру «чего изволите» — то вы на 100% правы.
А так — я и фронтэнд делал, для стартапа, который потом купили за неплохие деньги и Win32 GUI (для другого стартапа) и пролжоения для мобильных устройств (нет, не для сотовых), лет пять назад пилил порт GCC на одну интересную архитектуру… и нет, «не осилил» — нигде не было. Но и «чего изволите» — не было тоже.
Один только проект был, когда я был «молодой и зелёный» и когда я одну кнопку добавлял две недели (потому что её мог налисовать, там где этого хотел заказчик, только драйвер, а он не имел доступа к GUI, а API изначально не предполагал передачу данных в эту сторону по инициативе приложения, так что его пришлось менять… в общем много чего там было).
Когда я это всё обсудил с заказчиком, то он, конечно, мне всё это оплатил (совестливый был человек, мы с ним потом ещё много лет работали), но задал разумный вопрос: «а почему, когда выяснилось, что это — задача не на два часа, а на две недели… я, чёрт побери, не обсудил это со мной?»
Мой ответ «ну так же было в техзадании написано» его, мягко скажем, не воодушевил. Именно тогда, задолго до чтения статьи Джоела — я понял, что заказчик, в общем-то нифига не понимает что ему реально нужно.
Чуть позже я обнаружил, что есть-таки случаи, когда заказчик твёрдо уверен в том, что он знает что ему нужно… это тогда, когда заказчик — это не конечный заказчик, но посредник (ваш менежер или продажник или, может быть, менеджер со стороны закачика)… но тут ещё смешнее: все эти люди продают мою, ещё не сделанную работу — и берут за это деньги.
Ну так в этом случае это они у меня на крючке, а не я у них: деньги-то они уже получили (или считают, что получили), а работу-то я не сделал. И если я её не сделаю — то вся их долгая деятельность по уговору реального заказчика и подписанию договоров — полетит коту под хвост.
Единственный вариант, когда с заказчиком в принципе никак нельзя договорится, потому что он может вас уволить и нанять на ваше место «дядю Васю с улицы» — это когда то, что вы делаете, может сделать любой дядя вася надёргав кусков куда со StackOverflow… но стоит ли за такую работу держаться?
Вот интересно, вы призываете игнорировать требования заказчика и сами выбираете, что делать, а что нет (зачастую втайне от него). Но когда у Вас кто-то написал sql запрос не за логарифм, а за O(n), то это мгновенно повод для увольнения. Как так то?
«Друзья мои, делайте как я говорю, а не как я поступаю» ©
Тут ещё полным-полно людей, которые доказывают, что настоящий погромист должен писать код в максимально ручном режиме, а все эти ваши автоформы и готовые решения это баловство для тупых, но при том сами не знают не то что ассемблера, но даже паскаля, потому что это другое.
Тут ещё полным-полно людей, которые доказывают, что настоящий погромист должен писать код в максимально ручном режиме, а все эти ваши автоформы и готовые решения это баловство для тупых, но при том сами не знают не то что ассемблера, но даже паскаля, потому что это другое.
Как ни странно оба эти качества необходимы для того, чтобы получить качественный результат. И как и все банальности, касающиеся IT они обсосаны давным давно.
Если коротко, то игнорировать требования заказчика необходимо, так как он не знает чего хочет (знал бы — был не заказчиком, а вашим коллегой) — и делать это нужно тогда, когда заказчик явно требует вещей, которые ему не нужны. Ссылку на этот опус я Джоеля уже давал.
Sql-запрос за логарифм, а не зна O(n) — это в 99% случаев существенное замедление программы на ровном месте. И да, нужно уметь замечать, когда такое происходит и исправлять. И про это Джоел писал (он вообще, похоже успел описать все «банальные истины», какие существуют в мире IT… но они их можно крутить как угодно — но это всё равно истины).
Я вообще не понимаю что вас удивляет. Ну вот рассмотрите человека более традиционной, всем понятной, профессии. Ну, например, плотника. Приходит к вам кто-то и заказывает табуретку с ногами разной длины. Объяснений нет: «Вам ставят задачи, вы их решаете». Плотник, естественно, говорит вам, что это не табуретка, а чёрт знает что и требует пояснений. Оно нормально или нет? Или нормально сделать табуретку, а потом получать от клиента жалобы, что даже несмотря на ноги разной длины она на его кривом полу стоять отказывается?
Иногда можно убедить плотника сделать «что-то странное» произнеся магические слова «под мою ответственность» и дав ему чертежи… но в целом отказ делать вещь, которая потом принесёт ему только головную боль — в случае с плотником сомнений не вызывает.
С другой стороны, если тот же плотник сделает табуретку использовав для этого золотые гвозди или, наоборот, какою-нибудь дешёвую, но токсичную деревеплиту — вряд ли он заслужит эпитета «хороший», ведь так?
Так почему тот же самый подход к программированию вызывает вопросы?
Если коротко, то игнорировать требования заказчика необходимо, так как он не знает чего хочет (знал бы — был не заказчиком, а вашим коллегой) — и делать это нужно тогда, когда заказчик явно требует вещей, которые ему не нужны. Ссылку на этот опус я Джоеля уже давал.
Sql-запрос за логарифм, а не зна O(n) — это в 99% случаев существенное замедление программы на ровном месте. И да, нужно уметь замечать, когда такое происходит и исправлять. И про это Джоел писал (он вообще, похоже успел описать все «банальные истины», какие существуют в мире IT… но они их можно крутить как угодно — но это всё равно истины).
Я вообще не понимаю что вас удивляет. Ну вот рассмотрите человека более традиционной, всем понятной, профессии. Ну, например, плотника. Приходит к вам кто-то и заказывает табуретку с ногами разной длины. Объяснений нет: «Вам ставят задачи, вы их решаете». Плотник, естественно, говорит вам, что это не табуретка, а чёрт знает что и требует пояснений. Оно нормально или нет? Или нормально сделать табуретку, а потом получать от клиента жалобы, что даже несмотря на ноги разной длины она на его кривом полу стоять отказывается?
Иногда можно убедить плотника сделать «что-то странное» произнеся магические слова «под мою ответственность» и дав ему чертежи… но в целом отказ делать вещь, которая потом принесёт ему только головную боль — в случае с плотником сомнений не вызывает.
С другой стороны, если тот же плотник сделает табуретку использовав для этого золотые гвозди или, наоборот, какою-нибудь дешёвую, но токсичную деревеплиту — вряд ли он заслужит эпитета «хороший», ведь так?
Так почему тот же самый подход к программированию вызывает вопросы?
Вы хорошо описали, почему не стоит слушаться заказчика (с этим я в принципе согласен), но не описали, почему нужно слушаться Вас.
> Один только проект был, когда я был «молодой и зелёный» и когда я одну кнопку добавлял две недели
А если бы вы sql запрос 2 недели оптимизировали, это было бы правильнее?
Просто поймите, что для рядового программиста Вы и есть тот самый заказчик. И естественно, этот программист Вам как заказчику не верит. Ну не верит он, что в этом sql нужен O(logn), что делать? Также, как Вы не верите, что в этом месте нужна красивая кнопка.
Программистам тоже нужно на чем-то учиться. Я наверно вызову у Вас волну гнева, но изредка я сознательно допускаю какой-то технический промох в задаче, чтобы увидеть, что от этой части кода что-то действительно зависит. «Ошибся» где-то, передал тестировщикам, а они говорят — «тут ошибка». Ну круто, значит они досюда добрались. А если бы я все сделал правильно, то тестировщик бы мне ничего не сказал. И откуда я знаю, добрался он до этой части кода или нет. (Вместо тестировщика сюда можно подставить и пользователя)
Поймите, рядовым программистам тоже нужно откуда-то получать фидбек
> Один только проект был, когда я был «молодой и зелёный» и когда я одну кнопку добавлял две недели
А если бы вы sql запрос 2 недели оптимизировали, это было бы правильнее?
Просто поймите, что для рядового программиста Вы и есть тот самый заказчик. И естественно, этот программист Вам как заказчику не верит. Ну не верит он, что в этом sql нужен O(logn), что делать? Также, как Вы не верите, что в этом месте нужна красивая кнопка.
Программистам тоже нужно на чем-то учиться. Я наверно вызову у Вас волну гнева, но изредка я сознательно допускаю какой-то технический промох в задаче, чтобы увидеть, что от этой части кода что-то действительно зависит. «Ошибся» где-то, передал тестировщикам, а они говорят — «тут ошибка». Ну круто, значит они досюда добрались. А если бы я все сделал правильно, то тестировщик бы мне ничего не сказал. И откуда я знаю, добрался он до этой части кода или нет. (Вместо тестировщика сюда можно подставить и пользователя)
Поймите, рядовым программистам тоже нужно откуда-то получать фидбек
Вы хорошо описали, почему не стоит слушаться заказчика (с этим я в принципе согласен), но не описали, почему нужно слушаться Вас.А с этим всё проще — меня не нужно слушаться если со мной не работать. А если работать — то вопрос, как бы, отпадает.
Просто поймите, что для рядового программиста Вы и есть тот самый заказчик.А! Вы в этом смысле. Я даже как-то не подумал, что тут можно так понять.
Ну не верит он, что в этом sql нужен O(logn), что делать?Делать свою версию, если он в ней уверен. Только потом ему нужно будет доказать, что она лучше.
Понимаете — у любого заказчика (и у меня в том числе) всегда есть в запасе опция «не принять работу». И мне это сделать гораздо проще, так как в отличие от менеджера с его семью красными линиями я могу это всё сделать и сам.
Ну а если у вас не примут работу раз, два, три… десять… то тут уже и об увольнении можно говорить — так ведь?
Поймите, рядовым программистам тоже нужно откуда-то получать фидбекТого, что они от своих коллег и заказчиков получают — недостаточно?
И откуда я знаю, добрался он до этой части кода или нет.А почему это для вас, в принципе, важно? У нас есть компоненты, которые начинают использловаться и через год после написания. И человек, написавший этот компонент — может и уволиться (или просто перейти в другой отдел), к моменту, когда этот компонент кто-то, кроме автотетестов «пощупает».
И обнаружить закладки такого рода — было бы очень неприятно.
Да и не нужно это: если у вашего компонента никогда ничего не ломается без этих ваших закладок, то я вам завидую белой завистью.
Вот, из свеженького: наши очередные правки подобрали… и наш компонент поломал всем, кто его использует, билд. Ну кто мог предположить что макрос
CHECK можно использовать в constexpr-выражении… но только если ты не используешь clang-tidy?Пришлось забивать костыль. Upstream, надо сказать должное, отреагировал быстро, в следующей версии костыль можно будет убрать.
И вот такого… хватает безо всяких искусственно вставленных проблем.
А с этим всё проще — меня не нужно слушаться если со мной не работать. А если работать — то вопрос, как бы, отпадает.
Вы бы своё реальное имя в профиль добавили, что ли. И название копании, в которой вас нужно слушаться.
Страна должна знать своих героев. :)
Как единственный человек в этом треде с подробно заполненным профилем, имею сообщить: анонимность не может влиять на качество аргументации; если вам кажется, что влияет — вы на полшишечки от использования ad hominem.
Да ну ладно, о чём вы в самом деле? О какой анонимности тут речь идёт, когда товарищ авторитарно так заявляет, что его нужно слушаться ну вот нипочему? Мне просто любопытно, что это за птиц такой, всезнающий, всеумеющий и в истину в последней инстанции вхожий. А то чем чёрт не шутит, соберёшься этак собеседоваться в $куда-нибудь, а там как раз слушаться надо. А пацаны-то и не знали.
Что касается профиля на этом сайте, то мне он не настолько важен, чтобы время тратить. Какое там качество аргументации, хабр это наискось за обедом полистать и языком почесать между делом, пока код в голове варится. А если вам интересен мой профиль, то в гугле вторая ссылка на мой полудохлый бложек, а четвёртая на Github. В отличие от, кстати.
Для всего этого не нужно использовать «модные» фишки новейших фреймворков и кучу транспайлеров, порождащих в итоге мегабайты кода, с которыми потом еще-еле работают даже топовые системы.
Золотые слова.
Вообще, что-то менять без крайней на то необходимости, да еще использовать при этом какие-то новомодные фичи, которые будут работать только на самых последних версиях клиентских девайсов — классическая чешижопица от нечего делать.
Править только дефекты, допиливать только те фичи, которые реально необходимы.
А по поводу новых фреймворков — в одном месте, где работал, было правило — все новые разработки тестируются на откровенно слабом и старом железе. И если там оно работает и не тормозит, тогда уже переход к тесту на железе реальном. Очень дисциплинировало в плане написания нормального кода. Не борьбы за наносекунды, но просто вдумчивого подхода к тому что делаешь и как делаешь.
Ваша самоуверенность вполне типична для back end разработчика, который заглядывал во front end пару раз, не осилил, и теперь делает очень категоричные заявления о том, что реально нужно для большей части сайтов.
Ну на бэке свои проблемы, поверьте :-) И их хватает.
Например если вы не работали с Qt то вам будет сложно с разбегу понять всякие делегирования, модели данных и пр. залёты. Это всё даже разрабы с опытом иногда не понимают.
Давно работаю с Qt, но не смог расшифровать ваше сообщение.
О каком делегировании речь?
Модель данных — это про Qtшную реализацию ModeViewAdapter? Так вроде такие вещи надо знать безотносительно Qt или не Qt…
«Делегирование» и «делегаты» это про один из паттернов ООП, который применяется в Qt виджетах. Там много классов которые кончаются на *Delegate. Например QAbstractItemDelegate.
Да, надо. Это «паттерны ООП», о которых вполне логично спрашивают на собесах. Но вот рассказать хотя бы про Model (которые наследники QAbstractTableModel)из всего этого набора, для большинства будет проблемой.
Собсно я об этом и говорю, не надо обижатся на вопросы, надо вего лишь изучить всё это заранее.
Модель данных — это про Qtшную реализацию ModeViewAdapter? Так вроде такие вещи надо знать безотносительно Qt или не Qt…
Да, надо. Это «паттерны ООП», о которых вполне логично спрашивают на собесах. Но вот рассказать хотя бы про Model (которые наследники QAbstractTableModel)из всего этого набора, для большинства будет проблемой.
Собсно я об этом и говорю, не надо обижатся на вопросы, надо вего лишь изучить всё это заранее.
Ясно. ТО есть речь про базовый(он даже в википедии первый в списке) паттерн для коллбэков. Есть специалисты, которые не умеют в делегаты?
Да дело даже не в этом, пример можно привести и поизящней, но я все равно сомневаюсь, что интервьюер не разберется в ключевом вопросе: хороший тут код, или плохой.
Речь же про то, что проверяющий читает код под сигаретку и вискарик на диванчике, тут можно и среду развернуть, и с отладчиком / реплом поиграться, если уж совсем что-то полузабытое.
Ну всё. Собеседование не пройдено.
Скорее всего речь идет о реализации MVC в QML, там в дополнение к стандартному ModeViewAdapter есть концепция делегатов, таких элементов, которые сначала где-то описываются, а потом экземплярами создаются во вьюхе, тогда вью становится чем-то вроде контейнера для делегата.
UFO just landed and posted this here
ну так если нужен спец на Qt, может лучше спрашивать кандидата про его опыт именно с Qt, а не про эти сферические алгоритмы?
Насколько я понимаю логику работодателей. Иногда конторе работающей с Qt проще взять просто C++ программиста, который освоит этот Qt за пару месяцев. Ну и что в этом случае остаётся спрашивать кандидата? Если ему ещё только предстоит работать с Qt?
Qt достаточно простой и отлично документированный, спрашивать про него особого смысла нет. Максимум — поинтересоваться сталкивались/не сталкивались.
Иначе могут влепить какой нибудь алгоритм который, вроде как работает в тестах, но в проде завешивает весь сервис.
А как же code review? Ведь то, что человек знает алгоритмы, еще не гарантирует, что в нужный момент он их в нужном месте применит.
Предлагаете для тех, кто кнопку «аппрув» в ревью нажимает собеседовать отдельно, и уже их гонять по алгоритмам и Биг-О?
С апруверов спрос больше, логичнее, что их выбирать надо строже.
Но мне кажется, что апруверов чаще назначают, а не набирают с улицы.
Впрочем, если ведется именно набор, то логично для будующего апрувера подготовить несколько задач, где нужно провести код ревью и найти потенциальные затыки, а не просто заставлять цитировать сложности алгоритмов на память.
Но мне кажется, что апруверов чаще назначают, а не набирают с улицы.
Впрочем, если ведется именно набор, то логично для будующего апрувера подготовить несколько задач, где нужно провести код ревью и найти потенциальные затыки, а не просто заставлять цитировать сложности алгоритмов на память.
Чаще проблемы и фризы возникают вообще без всякого O. Мой личный топ:
1. Context.SaveChanges для EF (и прочих ORM) внутри цикла: типичная история из цикла «хорошо висим». Часто бывает при сложной цепочке внутренних вызовов.
2. Грузим весь CSV/Text в память и там его уже парсим. Типичная история падений по памяти и «хорошо висим». Тестовые файлы были мелкими, в таске ни слова, а в реале летают монстры. Про потоковую обработку файлов и буфферы чтения половина разрабов не слышала, вторая половина пользовалась ей в последний раз еще в школе. А для WebAPI и WWW вообще обычная история с их таймаутами и тенденцией переносить туда десктопный софт.
3. Сложные табличные fixed-size файлы запихиваем в БД для простой работы с ними (привет от файлов в гигобайт с миллионами записей). Фризы на импорте, фризы на экспорте, да еще и базой носителем часто бесплатная ограниченная версия выступает и падает по размеру файла базы.
4. У нас многоядерность, все надо параллелить! В итоге пара тысяч потоков сидят на ботлнеке с монитором, в лучшем случае с семафором.
5. Мой любимый маркетинговый фриз: эта операция выполняется слишком быстро, надо обязательно сделать задержку и повесить иконку ожидания!
1. Context.SaveChanges для EF (и прочих ORM) внутри цикла: типичная история из цикла «хорошо висим». Часто бывает при сложной цепочке внутренних вызовов.
2. Грузим весь CSV/Text в память и там его уже парсим. Типичная история падений по памяти и «хорошо висим». Тестовые файлы были мелкими, в таске ни слова, а в реале летают монстры. Про потоковую обработку файлов и буфферы чтения половина разрабов не слышала, вторая половина пользовалась ей в последний раз еще в школе. А для WebAPI и WWW вообще обычная история с их таймаутами и тенденцией переносить туда десктопный софт.
3. Сложные табличные fixed-size файлы запихиваем в БД для простой работы с ними (привет от файлов в гигобайт с миллионами записей). Фризы на импорте, фризы на экспорте, да еще и базой носителем часто бесплатная ограниченная версия выступает и падает по размеру файла базы.
4. У нас многоядерность, все надо параллелить! В итоге пара тысяч потоков сидят на ботлнеке с монитором, в лучшем случае с семафором.
5. Мой любимый маркетинговый фриз: эта операция выполняется слишком быстро, надо обязательно сделать задержку и повесить иконку ожидания!
Context.SaveChanges для EF
Где же тут "без всякого O"?
Грузим весь CSV/Text в память и там его уже парсим
То есть не учли "O" по используемой памяти.
Где же тут «без всякого O»?
Так сложность как была O(N), так и остается O(N). Сложность операции сохранения одной записи там O(1) получается, т.к. задержки на обращение к бд фиксированны для каждого запроса. Для сохранения всех записей сложность O(N). O(N)+O(N)=O(N).
То есть не учли «O» по используемой памяти.
С одной стороны:
В первом случае оно О(N).
Во втором случае оно O(N): N < K, O(1): N >= K
Пока размер файла не превышает K записей, обе реализации идентичны.
С другой стороны:
Для предупреждения этой проблемы вычислять O совершенно не нужно (не считая того, что далеко не все разработчики вообще помнят про кусочно-непрерывные функции и что такие вообще бывают), просто надо заранее бить шлангом по пяткам за использование потоков данных для затаскивания всех данных в память, когда этого можно избежать. А если при поточной обработке памяти все равно не хватает, то скорее всего проблема с утечками, а не с О.
Все же, сделать File.LoadToString несравнимо проще, чем правильно собрать потоки. Потом ещё окажется, что нужен случайный доступ к записям и придётся ещё что-то изобретать. Конечно, когда речь идёт о миллиардах записей, это все имеет смысл. Но бывает что там файлец-то в пару килобайт, а вы человека шлангом отмудохали. Неудобно как-то.
Где файл на пару килобайт, в один момент запихнут файл на гиг-другой. Проверено на практике. Как и где ждешь файлов на диске, обязательно подсунут либо сетевой путь, либо примонтируют папку с внешнего сервера.
А правильно собрать тот же StreamReader для поточной обработки — это дело минуты. Ничего сложного там нет, даже логика обработки данных не изменяется. Это так же естественно, как триммить строки и проверять их на null.
А правильно собрать тот же StreamReader для поточной обработки — это дело минуты. Ничего сложного там нет, даже логика обработки данных не изменяется. Это так же естественно, как триммить строки и проверять их на null.
А потом вам запихнут файл из одной строки на пару гигабайт.
Совершенно реальный случай.
Совершенно реальный случай.
Такие случаи — это чаще работа QA по вправлению мозгов юзеров. От Zip — бомбы мы тоже не должны прикрывать пользователей, если нам надо ZIP распаковать.
На серверной стороне согласен, там лучше быть больным на всю голову параноиком и продумывать все самые бредовые случаи. А еще лучше, когда данные для сервера готовит десктопный софт, пусть даже это свои проблемы создает, за-то защищает сервак от камикадзе.
На серверной стороне согласен, там лучше быть больным на всю голову параноиком и продумывать все самые бредовые случаи. А еще лучше, когда данные для сервера готовит десктопный софт, пусть даже это свои проблемы создает, за-то защищает сервак от камикадзе.
Не защищает. Я помню лет 10 назад мы декомпилировали клиент Утконоса и написали свой, так как штатный был неудобен — не скриптовался и всё такое.
Там было много интересного, но так как занимался этим не я, то врать не буду про внутренности.
Но просто как пример: наличие клиента ни от чего не защищает.
Там было много интересного, но так как занимался этим не я, то врать не буду про внутренности.
Но просто как пример: наличие клиента ни от чего не защищает.
Юзеру надо показать разумную ошибку в таком случае. А не ронять по ООМ весь сервис. С zip бомбой аналогично. QA тут вообще при чем?
В современном мире нет десктопного софта. Есть клубок сервисов и браузер. И часто даже не знаешь кто тебе данные дает: скрипт на питоне или живой человек через интерфейс.
В современном мире нет десктопного софта. Есть клубок сервисов и браузер. И часто даже не знаешь кто тебе данные дает: скрипт на питоне или живой человек через интерфейс.
Я не представляю себе фреймворк (да, даже язык, если честно), на котором я не смог бы разобрать и оценить код, предоставленный кандидатом, которого я собеседую.
Не мог не вспомнить в ответ вот это.
Во мой знакомый, синьёр, переходил с core power management одного широко известного в мире производителя мобильных процессоров на отладку видеокарт другого не менее известного производителя (а здания у них через дорогу). И о чём с ним можно было говорить на собеседовании? Без нарушения всех подписок о нераспространении? Только алгоритмика.
Я помню он рассказывал про две задачи: первая — в области памяти, заполненной указателями, как можно быстрее найти все закольцованные цепочки указателей.
Вторая — в динамическом массиве, по запросу, за наименьшее количество тактов, а лучше мгновенно, выдать элементы с наибольшим и наименьшим значениями. Изменение размерности массива и перезапись элементов может происходить каждый такт без ограничения по количеству добавляемых\удаляемых\переписываемых элементов, причём никакой отдельной информации о том что менялось — нет.
Надо отметить, что решать эти задачи в ходе собеседования не требовалось. Это было задание на дом. Решение, с описанием найденного алгоритма на разговорном языке, отправлялось по электронной почте.
Я помню он рассказывал про две задачи: первая — в области памяти, заполненной указателями, как можно быстрее найти все закольцованные цепочки указателей.
Вторая — в динамическом массиве, по запросу, за наименьшее количество тактов, а лучше мгновенно, выдать элементы с наибольшим и наименьшим значениями. Изменение размерности массива и перезапись элементов может происходить каждый такт без ограничения по количеству добавляемых\удаляемых\переписываемых элементов, причём никакой отдельной информации о том что менялось — нет.
Надо отметить, что решать эти задачи в ходе собеседования не требовалось. Это было задание на дом. Решение, с описанием найденного алгоритма на разговорном языке, отправлялось по электронной почте.
И о чём с ним можно было говорить на собеседовании?
Если ко мне лично придет человек, про которого мне столько известно (в нашем мире все немного иначе, тут нет «три года в core power management в гиганте через дорогу», но аналогий построить можно овердофигища) — я с ним буду разговаривать о жизни за ланчем.
Возможно ближе к кофе мы придумаем вместе три новых «алгоритма на разговорном языке», ему даже писать ничего не придется. Так же, как и я, — выбрасываю, не читая, предложения, отличающиеся от: «Здравствуйте, я — CTO, давайте поговорим за обедом».
Но тут в топике, вроде, речь шла про соисканта без известного в сообществе имени?
UFO just landed and posted this here
del
А можно уточнить про книги. Можно и погуглить, но может вы, что то конкретное имел в виду.
Интересно для себя почитать.
Интересно для себя почитать.
Многие программисты хотят попасть в такие компании, потому что там сухо и тепло (и корпоративные ипотеки под низкие проценты). Поэтому компании просто завалены резюме от кандидатов со всех концов страны (или мира). Чтобы хоть как-то отбирать кандидатов, компании приходят к фильтру по алгоритмическим задачам.
Я за прошлый год был завален предложениями из Яндекса, на которые после первого собеседования уже перестал отвечать и положил следующие письма прямиком в спам.
«Вас много, а я одна!»
Так вот кандидат, проходивший собеседование в Яндексе, может смело говорить «вас много, а я один!». Поскольку собеседование проходит по 5-12 раз, с разными оппонентами по одному и тому же шаблону — сидим и пишем программу на листочке. В результате, вы общаетесь как с людьми, которые вас давно ждали, вы начинаете уже в процессе решений понимать друг друга, вплоть до читать мысли и уже готовы устроиться. Так и с людьми, которые уже при встрече начинают мстить вам, как будто вы им в прошлой жизни все загадили — и как результат общего собеседования «Негоден».
Тем не менее, как для любой фирмы есть много кандидатов, так и для любого кандидата есть много фирм, и почему-то ни кто на эту ситуацию не хочет смотреть объективно.
Чтобы уменьшить поток этих публикаций (святая простота), ниже будет краткий, но лаконичный справочник по типам собеседований, которые вам стоит ожидать от конкретного типа компании. Справочник основан на личном многолетнем опыте.
Резюмируя. Не знаю как в остальных макрософаках. Но мне нафиг такое ненужно. Потому как в остальном, также в любой фирме (от мала до велика), хватает неадекватов и неадекватных правил, чтобы на каждый год хватало тем для новых статей — из личного опыта.
UFO just landed and posted this here
хахаха :)
Да сейчас та-же ерунда, сразу вызывают решать задачки, меня недавно без тестового позвали, и да, я теперь так-же теперь их предложений не принимаю (а они продолжают звать) только время терять впустую.
Да сейчас та-же ерунда, сразу вызывают решать задачки, меня недавно без тестового позвали, и да, я теперь так-же теперь их предложений не принимаю (а они продолжают звать) только время терять впустую.
Меня как-то HR из Я через L-In пыталась схантить. Объясняю что не ищу работу в настоящее время. Не отстает. «Ну хотя бы просто поговорить, может интересно станет...» Ну ладно, поговорить согласился, вдруг действительно интересно.
Назначили время на скайп разговор. Так мало того, что «переговорщик» из Я на полчаса перенес разговор, так еще и начал его со слов «я вам сейчас тестовое задание подготовлю...» Сразу ответил, что тестовые задания мне неинтересны, я не ищу работу в настоящее время, и договоренность была исключительно смогут ли ли они меня чем-то заинтересовать, а уж потом, если да, то смогу ли их чем-то заинтересовать я. На том и расстались.
Назначили время на скайп разговор. Так мало того, что «переговорщик» из Я на полчаса перенес разговор, так еще и начал его со слов «я вам сейчас тестовое задание подготовлю...» Сразу ответил, что тестовые задания мне неинтересны, я не ищу работу в настоящее время, и договоренность была исключительно смогут ли ли они меня чем-то заинтересовать, а уж потом, если да, то смогу ли их чем-то заинтересовать я. На том и расстались.
Как забавно, тут все рассказывают, как они закрываются от назойливых HR Яндекса. А от меня, наоборот, Яндекс закрылся — сначала отвечали мол «вы нам не подходите», а потом просто совсем перестали отвечать.
UFO just landed and posted this here
Ниже правильно сказали — это разные люди. А еще ниже тоже правильно — хантеры получают плюсик за каждого, кого они доведут до собеседования.
Именно с яндексом была полностью аналогичная ситуация — когда искал работу, отправлял им резюме. Ответ «сейчас вы нам не нужны, будем иметь ввиду...» в общем, стандартное «пошел ты...» в вежливой форме.
А вот когда уже работу нашел и в LinkedIn появилась текущая позиция, так из того же яндекса полезли хрюшки с призывами пособеседовать…
Именно с яндексом была полностью аналогичная ситуация — когда искал работу, отправлял им резюме. Ответ «сейчас вы нам не нужны, будем иметь ввиду...» в общем, стандартное «пошел ты...» в вежливой форме.
А вот когда уже работу нашел и в LinkedIn появилась текущая позиция, так из того же яндекса полезли хрюшки с призывами пособеседовать…
У меня тоже с ними была подобная ситуация: оттуда обращались ко мне по LinkedIn, когда я не искала работу. Когда искала, то увидев вакансию, которая мне подходила, обратилась к одной из рекрутерок, которые ко мне стучались, и спросила у неё актуальна ли эта вакансия. Она сказала, что да, и попросила резюме у меня. Очень быстро она ответила, что я им не подхожу. Ладно. Процесс поиска работы не затянулся надолго. Уже через пару месяцев после того, как я обновила свой LinkedIn с новой записью, ко мне снова постучались из Яндекса :).
Очень хорошая классификация, на мой взгляд.
Средний срок жизни разработчика в Гугле — 1 года 1 месяц. Это как бы показатель того, что люди там особо не задерживаются. Причины:
1) За счет «магии» бренда получают большой поток наивных разработчиков. Вроде деньги предлагают неплохие, но условия всякие типа: вот тебе небольшая зп, вот там раз в год будет бонус огромный (если пройдешь перфоманс ревью), вот тебе акции (которые сможешь получить через 5 лет). Как итог, пообещали много, и по факту хрен это все возьмешь. Как итог, разработчики прикидывают, что лучше свалить в какой-нибудь стартап, который делает мобильные игры и лутать деньги, чем работать в гугле.
2) Сидение на каком-то самописном легасе говне. Как правило, в больших компаниях куча своих каких-то инструментов. И если ты потратил свое время, чтобы их изучить, то при переходе в другую компанию твой опыт просто обнуляется.
3) Уже давно из компании добра это превратилось в галеры, где менеджеры за счет наивных разрабов решают какие-то свои задачи. То, что там разрабы ночами не спали пили какой-то проект под большим давлением, а потом это все дело похерилось, когда менеджер перевелся куда-то — никого не волнует. Ну и потом на перфоманс ревью еще зп срежут, типа проект заруинился.
4) Ну и самая вишенка. Вот такие компании, на всяких собеседованиях относятся к тебе, как говну. Вот тебе задача какая-то олимпиадная решай, вот тебе белая доска, напиши нам все типы из Python и прочее. И то, что ты там все это сделал (потратил куча времени), вообще не факт, что тебя возьмут.
В общем, во всяких конторах типа Яндекса, либо работают наивные дурачки после универа, которых и хвост и в гривы, либо уже опытные разрабы с опытом 10-15+, которых взяли за большие деньги на какой-то проект, ибо молодняк не тянет.
__
Обычному разработчику, который хоть как-то любит себя и ценит свою работу, лучше идти в в ту же галеру, пилить бизнес логику за хорошие деньги в спокойной обстановке, чем вот эти все яндексы.
1) За счет «магии» бренда получают большой поток наивных разработчиков. Вроде деньги предлагают неплохие, но условия всякие типа: вот тебе небольшая зп, вот там раз в год будет бонус огромный (если пройдешь перфоманс ревью), вот тебе акции (которые сможешь получить через 5 лет). Как итог, пообещали много, и по факту хрен это все возьмешь. Как итог, разработчики прикидывают, что лучше свалить в какой-нибудь стартап, который делает мобильные игры и лутать деньги, чем работать в гугле.
2) Сидение на каком-то самописном легасе говне. Как правило, в больших компаниях куча своих каких-то инструментов. И если ты потратил свое время, чтобы их изучить, то при переходе в другую компанию твой опыт просто обнуляется.
3) Уже давно из компании добра это превратилось в галеры, где менеджеры за счет наивных разрабов решают какие-то свои задачи. То, что там разрабы ночами не спали пили какой-то проект под большим давлением, а потом это все дело похерилось, когда менеджер перевелся куда-то — никого не волнует. Ну и потом на перфоманс ревью еще зп срежут, типа проект заруинился.
4) Ну и самая вишенка. Вот такие компании, на всяких собеседованиях относятся к тебе, как говну. Вот тебе задача какая-то олимпиадная решай, вот тебе белая доска, напиши нам все типы из Python и прочее. И то, что ты там все это сделал (потратил куча времени), вообще не факт, что тебя возьмут.
В общем, во всяких конторах типа Яндекса, либо работают наивные дурачки после универа, которых и хвост и в гривы, либо уже опытные разрабы с опытом 10-15+, которых взяли за большие деньги на какой-то проект, ибо молодняк не тянет.
__
Обычному разработчику, который хоть как-то любит себя и ценит свою работу, лучше идти в в ту же галеру, пилить бизнес логику за хорошие деньги в спокойной обстановке, чем вот эти все яндексы.
UFO just landed and posted this here
Средний срок жизни разработчика в Гугле — 1 года 1 месяц.
Эта статистика верна только для Mountain View.
вот тебе небольшая зп, вот там раз в год будет бонус огромный (если пройдешь перфоманс ревью), вот тебе акции (которые сможешь получить через 5 лет).
ЗП в Google зависят от региона. В Цюрихе, к примеру, вполне можно получать 165.000 CHF на старте (что уже ощутимо выше рынка). Плюс ежегодный бонус 15-20% от зарплаты. Акции выдают не через пять лет, а каждый квартал. В сумме может запросто получится в 2 раза выше рынка уже через год.
Как правило, в больших компаниях куча своих каких-то инструментов.
Инструменты в Google такие, что индустрии до них ещё десятилетие расти. К примеру, после Critique (код-ревью тула в Google) от код-ревью на GitHub просто люто, бешено бомбит.
при переходе в другую компанию твой опыт просто обнуляется
Я бы не сказал. Умение готовить Protobuf и gRPC много где нужно. Ну и C++ в Google хороший.
Уже давно из компании добра это превратилось в галеры, где менеджеры за счет наивных разрабов решают какие-то свои задачи.
Краски сильно сгущены. Политики много, но по ночам никто не работает, и зарплаты никто не снижает.
Вот такие компании, на всяких собеседованиях относятся к тебе, как говну.
У меня такое только с Amazon было. От собеседований в Facebook и Google впечатления были очень положительные.
Яндекса
Я работал в Яндексе (в Картах), мне там очень понравилось. Много умных талантливых коллег и интересные задачи.
В Цюрихе, к примеру, вполне можно получать 165.000 CHF
А есть ли публичное подтверждение? Это не к тому, что я сомневаюсь. Мне хочется ссылку для торговли по зарплате.
Какого подтверждения вы хотите? Бумагу от гугла что да мы столько платим?
Могу лишь подтвердить, как варящийся на рынке Цюриха, что слышал о больших суммах.
Публичного официального нет, есть публичное неофициальное: https://www.levels.fyi/salary/Google/
Там после раздела "о компании" и графиков есть фильтрация, можно ввести Zurich и указать L3 или L4 в зависимости от самооценки. :)
165000 франков — скорее всего, L5 в среднем по сложности проекте, или L4 в суровом, серьёзном. L3 (самый массовый уровень) вряд ли будет получать больше 130 тысяч.
Ах да, в Яндекс меня не взяли — видимо, я плохо решил задачку на тервер и фигово ответил олимпиаднику-интервьюверу.
Инструменты в Google такие, что индустрии до них ещё десятилетие расти. К примеру, после Critique (код-ревью тула в Google) от код-ревью на GitHub просто люто, бешено бомбит.
Я объективно понимаю, что мой уровень программиста даже близко не дотягивает до уровня гугл, но дико интересно, что такого может быть в коде, что индустрии расти ещё десятилетие.
Может вы смогли бы пояснить, дать ссылку или привести примеры, что так координатно выделяет инструменты гугл.
Ну тут сложный вопрос. Но можно показать на примерах. Ничего не буду говорить про Critique (ибо не сталкивался), но можно показать примере открытых вещей.
Как известно Gerrit — это отстой, качмар и ужас. «Новое поколение» так считает, по крайней мере — ибо там с градиентами и модными стилями всё плохо (недавно, правда, сделали новый UI… который безбожно томозит… MaximKulkin будет доволен, я так понимаю — раньше всё работало шустро, хотя выглядело как «привет из 90х», да).
Однако если глянуть на то, как происходит, собственно, код-ревью с использованием Gerrit… то можно увидеть кой-какие интересные вещи.
Ну вот давайте на примере. Вот, например, такое изменение. Что можно увидеть сразу. Две группы CL'ей в правом верхнем углу. Один из них (самый верхний) помечен красным словом «Merged», ещё четыре — чёрным словом «Merged». Почему такая разница? Потому что эти четыре (пять, но об этом дальше) — объединены в общий «topic». Что обозначает, что они должны включаться в репозиторий вместе (или не включаться вместе). А последний CL (с тестом) — он отдельный, его необязательно «подбирать» вместе с другуми.
Теперь о том, почему я говорю про про пять CL'ей, хотя вроде как их там четыре? Потому что пятый — вот он. Он идёт в другой репозиторий, но при этом он связан с четырьмя другими — и боты не будут пытаться брать версии в которых его нет (а четыре других есть).
Как это сделать в GitHub? Ну вот как мне сделать связанные изменения в Vulkan-Docs, Vulkan-Headers, и в Vulkan-Samples? Я таких способов не знаю. Максимум — можно в описаниях перекрёстные ссылки добавить. Но их GitHub корректировать не будет.
Ладно. Идём дальше. Смотрим дальше на то же самое изменение. Обратите внимание на строчку «Patchset 13». Это вообще что такое? А очень просто: этот набор CLей не сразу так, мгновенно, появился. Его долго обсуждали. Если глянуть на «Patchset 1», то видно что вся эта история началась аж в ноябре месяце. И всё это время рассматривалась не большая «каша», а несколько, связанных друг с другом, изменений.
Ну обсуждалось, ладно… комментарии друг другу писали, да. Кстати на главной странице вы можете увидеть сразу же и замечания от Lint'а и результаты работы тестов и кучу всего ещё.
Из интересно — можно увидеть вот подобные вот ссылки.
Где можно обнаружить отдельную, «вложенную» дискуссию даже не по поводу отдельной строки, а по поводу отдельного слова на этой строке (если нужно, конечно).
Ну и, конечно, если изменение будет включено не только в одну ветку, а куда-то ещё, то это тоже будет видно (вот пример).
Ну вот как-то так. Посмотрев на это — понимаешь: у Гугла — это код-ревью тул. Для того, чтобы аккуратно и вдумчиво обсуждать изменения в код.
А вот GitHub и прочием модные штуки… это «социальная сеть», «клуб по интересам», собственно код там дотошно обсуждать не получится. Лишь чуть-чуть более удобно, чем просто в переписке по почте это сделано.
Но зато градиенты, стили… это да. Тут всё у GitHub'а отлично.
Как известно Gerrit — это отстой, качмар и ужас. «Новое поколение» так считает, по крайней мере — ибо там с градиентами и модными стилями всё плохо (недавно, правда, сделали новый UI… который безбожно томозит… MaximKulkin будет доволен, я так понимаю — раньше всё работало шустро, хотя выглядело как «привет из 90х», да).
Однако если глянуть на то, как происходит, собственно, код-ревью с использованием Gerrit… то можно увидеть кой-какие интересные вещи.
Ну вот давайте на примере. Вот, например, такое изменение. Что можно увидеть сразу. Две группы CL'ей в правом верхнем углу. Один из них (самый верхний) помечен красным словом «Merged», ещё четыре — чёрным словом «Merged». Почему такая разница? Потому что эти четыре (пять, но об этом дальше) — объединены в общий «topic». Что обозначает, что они должны включаться в репозиторий вместе (или не включаться вместе). А последний CL (с тестом) — он отдельный, его необязательно «подбирать» вместе с другуми.
Теперь о том, почему я говорю про про пять CL'ей, хотя вроде как их там четыре? Потому что пятый — вот он. Он идёт в другой репозиторий, но при этом он связан с четырьмя другими — и боты не будут пытаться брать версии в которых его нет (а четыре других есть).
Как это сделать в GitHub? Ну вот как мне сделать связанные изменения в Vulkan-Docs, Vulkan-Headers, и в Vulkan-Samples? Я таких способов не знаю. Максимум — можно в описаниях перекрёстные ссылки добавить. Но их GitHub корректировать не будет.
Ладно. Идём дальше. Смотрим дальше на то же самое изменение. Обратите внимание на строчку «Patchset 13». Это вообще что такое? А очень просто: этот набор CLей не сразу так, мгновенно, появился. Его долго обсуждали. Если глянуть на «Patchset 1», то видно что вся эта история началась аж в ноябре месяце. И всё это время рассматривалась не большая «каша», а несколько, связанных друг с другом, изменений.
Ну обсуждалось, ладно… комментарии друг другу писали, да. Кстати на главной странице вы можете увидеть сразу же и замечания от Lint'а и результаты работы тестов и кучу всего ещё.
Из интересно — можно увидеть вот подобные вот ссылки.
Где можно обнаружить отдельную, «вложенную» дискуссию даже не по поводу отдельной строки, а по поводу отдельного слова на этой строке (если нужно, конечно).
Ну и, конечно, если изменение будет включено не только в одну ветку, а куда-то ещё, то это тоже будет видно (вот пример).
Ну вот как-то так. Посмотрев на это — понимаешь: у Гугла — это код-ревью тул. Для того, чтобы аккуратно и вдумчиво обсуждать изменения в код.
А вот GitHub и прочием модные штуки… это «социальная сеть», «клуб по интересам», собственно код там дотошно обсуждать не получится. Лишь чуть-чуть более удобно, чем просто в переписке по почте это сделано.
Но зато градиенты, стили… это да. Тут всё у GitHub'а отлично.
Потому что эти четыре (пять, но об этом дальше) — объединены в общий «topic».
Угу. В GH «топик» называется «пулл реквест», но это слишком молодежно, наверное.
Ну вот как мне сделать [в GH] связанные изменения вVulkan-Docs,Vulkan-Headers, и вVulkan-Samples?
О, да, давайте вопросы версионности сборок будет решать система контроля версий кода, а не пакетный менеджер. (Если обязательно нужно, чтобы это решала система контроля версий — зонтичный проект с подмодулями пойдет).
Посмотрев на это — понимаешь: у Гугла — это код-ревью тул.
Или не понимаешь. Вот я, например, не могу взять в толк, зачем бы мне замечаниями от линта замусоривать страницу обсуждения, на которой я хочу увидеть (вот сейчас будет прямо сюрприз: обсуждение). Например, обсуждение внезапно может не быть привязано к коду.
Так что, спасибо, но нет. GH далек от идеала, но вот эту кашу из ста восьмидесяти пяти разных типов информации, впихнутых на один экран просто потому, что можем (я удивлен, что температура в Антананариву там не указана где-нибудь в уголочке) — я искренне мечтаю не увидеть больше никогда в жизни.
(Если обязательно нужно, чтобы это решала система контроля версий — зонтичный проект с подмодулями пойдет).И как в этом «зонтичном проекте» увидеть как изменения в разных проектах между собой связаны?
GH далек от идеала, но вот эту кашу из ста восьмидесяти пяти разных типов информации, впихнутых на один экран просто потому, что можем (я удивлен, что температура в Антананариву там не указана где-нибудь в уголочке) — я искренне мечтаю не увидеть больше никогда в жизни.Увидите ещё. Когда-то этот же путь прошли IDE. От лаконичных редакторов без излишеств — вот к примерно такому же нагромождению тулбаров и панелей.
Например, обсуждение внезапно может не быть привязано к коду.Если, внезапно, ваше обсуждение не привязано к коду — то его можно хоть в WhatsApp вести. А вот если привязано — то Gerrit (и вышеопомянутый Critique, я думаю) — такие средства предоставляет, а вот GitHub — нет. Ну или, по крайней мере я не нашёл таких способов, чтобы можно было ткнуть в конкретную строчку и спросить «а что, собственно, тут происходит?»… ну или сравнить 5й patch в наборе в той версии в какой он был год назад с тем, что случилось сейчас.
Что самое забавное — ведь изначально именно под это Git был заточен. Ради подобных обсуждений Линус его вообще сделал. Хотя у разработчиков ядра всё заточено под работу через почту, что несколько, слишком хардкорно всё же.
Вместо того, чтобы ткнуть в конкретное непонятное место приходится устраивать дискуссиию… чего на практике мало кто делает, потому что для подхода «тяп-ляп и в продакшн» — этого действительно не нужно.
Увидите ещё. Когда-то этот же путь прошли IDE.
Лишняя причина никогда не использовать никаких IDE.
по крайней мере я не нашёл таких способов, чтобы можно было ткнуть в конкретную строчку и спросить «а что, собственно, тут происходит?»
Ну так вы попробуйте разок-другой code review в GH сделать, сразу и найдете, это не рокетсайнс.
Ну так вы попробуйте разок-другой code review в GH сделать, сразу и найдете, это не рокетсайнс.Ссылок, я так понимаю, не будет? Следов от этой деятельности не остаётся?
Что это за код-ревью система тогда такая тогда?
P.S. И нет, я не говорю, что в GH это сделать невозможно. Вопрос в том — насколько это удобно и насколько легко человек может потом что-то с этим замечаниями сделать. Ведь если это code review (в переводе «пересмотр кода») — то, логичено, что после дискуссии что-то с этим кодом нужно делать (а иначе зачем его reviewить?).
Ссылок, я так понимаю, не будет?
Мне неохота, знаете ли, ради каждого невежды — скриншоты ходить делать, да ссылки аккуратно выискивать. Но вот там ниже товарищ не такой ленивый, пользуйтесь.
Ну тогда такой невежда, как я, просит помощи клуба в сравнении, потому что ну тоже очень интересно.
Возможность комментария к каждой строчке помечена «New!» — значит, для них действительно рокетсайнс ещё совсем недавно. Когда оно появилось-то?
Как насчёт получить разницу между несколькими версиями предложения одного и того же изменения (patchsetʼами в терминах Gerrit; например, 3-м и 8-м), и с комментариями к ним?
Как насчёт автоопределения типа изменения (по сути, rebase, поправлено только сообщение...) сервером? (писать это в commit message самого автора — не просить)
Как насчёт увидеть в одном диффе, какое из различий патчсетов вызвано разницей в их диффах, а какое — сменой базового коммита? В сложных случаях это очень критично.
Найдётся кто-нибудь достаточно неленивый, чтобы хотя бы сказать «нет, не умеем» или «это будет через год»?
Возможность комментария к каждой строчке помечена «New!» — значит, для них действительно рокетсайнс ещё совсем недавно. Когда оно появилось-то?
Как насчёт получить разницу между несколькими версиями предложения одного и того же изменения (patchsetʼами в терминах Gerrit; например, 3-м и 8-м), и с комментариями к ним?
Как насчёт автоопределения типа изменения (по сути, rebase, поправлено только сообщение...) сервером? (писать это в commit message самого автора — не просить)
Как насчёт увидеть в одном диффе, какое из различий патчсетов вызвано разницей в их диффах, а какое — сменой базового коммита? В сложных случаях это очень критично.
Найдётся кто-нибудь достаточно неленивый, чтобы хотя бы сказать «нет, не умеем» или «это будет через год»?
Возможность комментария к каждой строчке помечена «New!»
Не уверен, что значит «помечена», но я ей пользуюсь уже несколько лет точно.
получить разницу между несколькими версиями предложения одного и того же изменения
WAT? Зачем? Если это нужно, то весь процесс разработки никуда не годится, менять надо всю команду, а не систему контроля версий.
автоопределения типа изменения
Не очень понял, что это, и зачем. Никто в здравом уме ребейзы пустыми обратно не коммитит, это очевидный антипаттерн.
В сложных случаях это очень критично.
См. комментарий выше. Патчсеты — зло, экспоненциальная сложность на пустом месте, их просто не должно быть как таковых. Если они нативно поддерживаются кем-то, значит у кого-то серьезные проблемы (у Г — их уж точно вагон).
Очень надеюсь, что ничего и близко похожего в GH мы никогда не увидим.
> Не уверен, что значит «помечена», но я ей пользуюсь уже несколько лет точно.
«Помечена» — тыкаю и появляется «New! Suggest specific code changes that the pull request author or assignees can immediately commit. You will be attributed in the commit.»
«Несколько лет» это сколько? Я последний раз активно смотрел где-то года 4 назад — ещё не было, в то время как в Gerrit это давно стало банальностью.
> WAT? Зачем? Если это нужно, то весь процесс разработки никуда не годится, менять надо всю команду, а не систему контроля версий.
Прошу объяснить причины такого вывода. Я, наоборот, считаю, что без этого нормальной работы нет. Например, к patchset 1 сделано несколько орфографических замечаний. Я пишу «всё ok, кроме орфографии, исправьте», помечаю места. Автор выкатил patchset 2. Я открываю дифф между ними и вижу, что орфография исправлена и больше ничего не трогалось => мне не нужно его пересматривать заново.
Что вы плохого видите в таком подходе? Почему вдруг это «процесс разработки не годится»? Объясните.
> Не очень понял, что это, и зачем. Никто в здравом уме ребейзы пустыми обратно не коммитит, это очевидный антипаттерн.
Что значит «обратно»? Есть цепочка, например, из 3 коммитов. Первый надо было править, 2 и 3 — не нужно, там всё нормально. В новом предложении 2 и 3 оказываются только rebased, изменений в их сути нет.
> атчсеты — зло, экспоненциальная сложность на пустом месте, их просто не должно быть как таковых.
Сейчас это выглядит как чистейшая религия. У вас есть обоснование этому тезису?
«Помечена» — тыкаю и появляется «New! Suggest specific code changes that the pull request author or assignees can immediately commit. You will be attributed in the commit.»
«Несколько лет» это сколько? Я последний раз активно смотрел где-то года 4 назад — ещё не было, в то время как в Gerrit это давно стало банальностью.
> WAT? Зачем? Если это нужно, то весь процесс разработки никуда не годится, менять надо всю команду, а не систему контроля версий.
Прошу объяснить причины такого вывода. Я, наоборот, считаю, что без этого нормальной работы нет. Например, к patchset 1 сделано несколько орфографических замечаний. Я пишу «всё ok, кроме орфографии, исправьте», помечаю места. Автор выкатил patchset 2. Я открываю дифф между ними и вижу, что орфография исправлена и больше ничего не трогалось => мне не нужно его пересматривать заново.
Что вы плохого видите в таком подходе? Почему вдруг это «процесс разработки не годится»? Объясните.
> Не очень понял, что это, и зачем. Никто в здравом уме ребейзы пустыми обратно не коммитит, это очевидный антипаттерн.
Что значит «обратно»? Есть цепочка, например, из 3 коммитов. Первый надо было править, 2 и 3 — не нужно, там всё нормально. В новом предложении 2 и 3 оказываются только rebased, изменений в их сути нет.
> атчсеты — зло, экспоненциальная сложность на пустом месте, их просто не должно быть как таковых.
Сейчас это выглядит как чистейшая религия. У вас есть обоснование этому тезису?
«Suggest specific code changes» ≠ «Возможность оставлять комментарии к каждой строке кода».
Я открываю дифф между ними и вижу
Это пожалуйста, «изменения, которых вы не видели» называется, с незапамятных времен есть. Сравнивать третий и восьмой патчсеты не нужно никому.
2 и 3 оказываются только rebased
Кошмар какой. А сто человек вокруг уже черри-пикнули коммит 2. Я бы убил человека, который так делает.
У вас есть обоснование этому тезису?
Нет.
> Это пожалуйста, «изменения, которых вы не видели» называется, с незапамятных времен есть.
Оно само определяет, какие изменения я видел? Это же не фейсбук, для которого AI с функцией «этого котика он ещё не видел, давайте покажем» помогает в 99% случаях, а на 1% можно и наплевать.
> Сравнивать третий и восьмой патчсеты не нужно никому.
Использую несколько раз в неделю при анализе чужих ревью, потому что нормально, например, что 4 и 5 возникли как rebase от автора, а остальные — в ответ на комментарии других ревьюеров, а я в это время был занят чем-то более важным/срочным и не мог реагировать на каждый новый патчсет (хотя я его открыл и увидел, что идёт какая-то полезная возня).
> Кошмар какой. А сто человек вокруг уже черри-пикнули коммит 2. Я бы убил человека, который так делает.
Зачем им черипикать чужой коммит, который ещё только на рассмотрении и не одобрен? Вы вообще пытаетесь понять контекст?
> Нет.
Ну тогда от меня только соболезнования, но вы ничего не смогли доказать. Спасибо за участие.
Оно само определяет, какие изменения я видел? Это же не фейсбук, для которого AI с функцией «этого котика он ещё не видел, давайте покажем» помогает в 99% случаях, а на 1% можно и наплевать.
> Сравнивать третий и восьмой патчсеты не нужно никому.
Использую несколько раз в неделю при анализе чужих ревью, потому что нормально, например, что 4 и 5 возникли как rebase от автора, а остальные — в ответ на комментарии других ревьюеров, а я в это время был занят чем-то более важным/срочным и не мог реагировать на каждый новый патчсет (хотя я его открыл и увидел, что идёт какая-то полезная возня).
> Кошмар какой. А сто человек вокруг уже черри-пикнули коммит 2. Я бы убил человека, который так делает.
Зачем им черипикать чужой коммит, который ещё только на рассмотрении и не одобрен? Вы вообще пытаетесь понять контекст?
> Нет.
Ну тогда от меня только соболезнования, но вы ничего не смогли доказать. Спасибо за участие.
Я не пытался ничего доказывать.
Я отвечал на бессмысленные (с моей точки зрения) вопросы, местами неверные (как про построчные комментарии, которым сто лет), местами требующие от кофеварки умения бегать за пивом (у вас rebase собственных коммитов → вызывает нужду сравнивать 3 и 8 патчсеты, и вы спрашиваете, почему ни то, ни другое не доступно в GH).
Зачем им черипикать чужой коммит, который ещё только на рассмотрении и не одобрен? Вы вообще пытаетесь понять контекст?
Я-то как раз в контексте. Зачем мне может потребоваться чужой коммит, — это мое (и автора) сугубо интимное дело. Система контроля версий предназначена для того, чтобы мне такую возможность дать.
Оно само определяет [...]
Оно показывает изменения с момента вашего последнего ревью. Этот кейс покрывает 99% нужд при правильном использовании инструментов.
То, что всегда можно высосать из пальца проблемы, которые решает система, которая нравится вот тем людям — для меня не секрет. Я просто не вижу смысла эффективно решать надуманные несуществующие проблемы. That simple.
> Я просто не вижу смысла эффективно решать надуманные несуществующие проблемы. That simple.
Ну вот в этом, видимо, и суть. Вы создали себе какой-то очень непонятный, как минимум мне, workflow, для которого важные реальные вопросы объяылены «надуманными» и «несуществующими». Я честно не понимаю, как без такого можно работать над чем-то посерьёзнее откровенно детской песочницы. Остальное в обсуждаемом — это уже следствие подобного подхода. Нет, конечно, I've seen various shit, где и никакая система контроля версий не использовалась, и принципиально использовался CVS в 2015-м году, и где запрещали именовать переменные длиннее одной буквы, так что меня это не удивляет, но продолжаю не понимать.
Если хотите внести какой-то реально конструктивный вклад в эту ветку дискуссии — попробуйте конструктивно с примерами объяснить, как с этим всем можно вы ухитряетесь реально работать над чем-то существенным. Без этого, действительно, лучше поставить точку.
Ну вот в этом, видимо, и суть. Вы создали себе какой-то очень непонятный, как минимум мне, workflow, для которого важные реальные вопросы объяылены «надуманными» и «несуществующими». Я честно не понимаю, как без такого можно работать над чем-то посерьёзнее откровенно детской песочницы. Остальное в обсуждаемом — это уже следствие подобного подхода. Нет, конечно, I've seen various shit, где и никакая система контроля версий не использовалась, и принципиально использовался CVS в 2015-м году, и где запрещали именовать переменные длиннее одной буквы, так что меня это не удивляет, но продолжаю не понимать.
Если хотите внести какой-то реально конструктивный вклад в эту ветку дискуссии — попробуйте конструктивно с примерами объяснить, как с этим всем можно вы ухитряетесь реально работать над чем-то существенным. Без этого, действительно, лучше поставить точку.
Ну или, по крайней мере я не нашёл таких способов, чтобы можно было ткнуть в конкретную строчку и спросить «а что, собственно, тут происходит?»…Например типа такого?
«New! Suggest specific code changes that the pull request author or assignees can immediately commit. You will be attributed in the commit.»
Сколько лет гитхабу и когда это реально появилось, если это «New!»?
Сколько лет гитхабу и когда это реально появилось, если это «New!»?
Это suggestions, которые автор может одним кликом принять, к возможности комментирования кода построчно отношения не имеет вовсе.
Кроме того, если вы хотите сравнивать по состоянию на 2010 год — я к вашим услугам.
> Это suggestions, которые автор может одним кликом принять, к возможности комментирования кода построчно отношения не имеет вовсе.
Тогда в чём по-вашему разница между suggestion и комментарием? Особенно, если они делаются построчно?
> Кроме того, если вы хотите сравнивать по состоянию на 2010 год — я к вашим услугам.
Какое-то отставание в оценках есть всегда, это неизбежно. Только не надо сразу про 2010, это начинается уже намеренное Imago.
Тогда в чём по-вашему разница между suggestion и комментарием? Особенно, если они делаются построчно?
> Кроме того, если вы хотите сравнивать по состоянию на 2010 год — я к вашим услугам.
Какое-то отставание в оценках есть всегда, это неизбежно. Только не надо сразу про 2010, это начинается уже намеренное Imago.
в чём по-вашему разница между suggestion и комментарием
Это уже начинает напоминать троллинг. Suggestion — это код, который автор исходного реквеста может в один клик коммитнуть. Комментарий — это текст, в котором на плохом английском языке кто-то кому-то пытается донести какую-то мысль. Как их вообще можно сравнивать?
Только не надо сразу про 2010
Не я начал, не вам решать, когда мне закончить. Вы тут разбрасывались «сколько лет гитхабу и когда это реально появилось» (хотя и не понимая вообще, о чем разговор) странными аргументами про возраст, когда внезапно оказалось, что по аргументу «такой возможности нет» произошел слив.
> Это уже начинает напоминать троллинг. Suggestion — это код, который автор исходного реквеста может в один клик коммитнуть.
> троллинг
Ни капельки. Когда кто-то начинает играть со словами в стиле Шалтая-Болтая — «я сам определяю, что мои слова значат» — другой в лучшем случае будет удивляться. Suggestion — настолько многозначное, что требуется явное определение для конкретного случая.
> Как их вообще можно сравнивать?
Вот так и сравнивать — сначала разобравшись в каждом местном жаргоне.
> хотя и не понимая вообще, о чем разговор
В другом случае я бы оценил незамутнённость ваших домыслов и качество справочника «потолок» в их добывании, но сейчас это тупо бессмысленно.
> когда внезапно оказалось, что по аргументу «такой возможности нет» произошел слив.
Почему слив? Вы только что сами показали, что этого функционала нет, потому что к строке можно добавить suggestion, но не комментарий к строке. Или там ещё какой-то хитрый вариант что-то нажать, которого нет в обычном хелпе (да, я перед этим всем таки пытаюсь гуглить их инструкции, но не анализирую их перекрёстно, потому что 99% пользователей этого не делает)? Тогда расскажите. Пока что выглядит, что вы сами себя опровергли.
> троллинг
Ни капельки. Когда кто-то начинает играть со словами в стиле Шалтая-Болтая — «я сам определяю, что мои слова значат» — другой в лучшем случае будет удивляться. Suggestion — настолько многозначное, что требуется явное определение для конкретного случая.
> Как их вообще можно сравнивать?
Вот так и сравнивать — сначала разобравшись в каждом местном жаргоне.
> хотя и не понимая вообще, о чем разговор
В другом случае я бы оценил незамутнённость ваших домыслов и качество справочника «потолок» в их добывании, но сейчас это тупо бессмысленно.
> когда внезапно оказалось, что по аргументу «такой возможности нет» произошел слив.
Почему слив? Вы только что сами показали, что этого функционала нет, потому что к строке можно добавить suggestion, но не комментарий к строке. Или там ещё какой-то хитрый вариант что-то нажать, которого нет в обычном хелпе (да, я перед этим всем таки пытаюсь гуглить их инструкции, но не анализирую их перекрёстно, потому что 99% пользователей этого не делает)? Тогда расскажите. Пока что выглядит, что вы сами себя опровергли.
Suggestion — это такая практически бесполезная фича в которой можно предложить патч для одной строчки кода.
Комментировать конкретную строчку кода можно было давно.
Возможность комментировать несколько строк кода завезли несколько месяцев назад.
Возможность комментировать произвольный регион кода (например, кусок строки) не завезли и вряд ли завезут в ближайшее время.
Suggestion — это такая практически бесполезная фича [...]
Несколько раз в день использую, нарадоваться не могу.
Очень редко можно поправить одну строку кода так, чтобы результат компилировался и не огорчал форматтер кода.
Я разве что опечатки так правлю.
В остальных случаях это просто способ оставить комментарий к части длинной строки, что является просто убогим хаком ввиду отсутствия возможности комментировать произвольный регион кода.
Очень редко можно поправить одну строку кода так, чтобы результат компилировался и не огорчал форматтер кода.
А, у вас в ревью попадает код, который не компилируется и не проходит линтер? Тогда вам GH не подойдет, да. Word — вот это подходящий инструмент.
Например, обсуждение внезапно может не быть привязано к коду.
А вот это вообще мясо в GH. Обсуждение, не привязанное к коду нельзя склеить в один тред. Остаётся только квотить весь тред в каждом комменте, удобненько!
В Critique (помимо комментариев к кускам кода) есть специальные треды per file и один глобальные тред на весь патч.
что так координатно выделяет инструменты
Простота, эффективность и интеграция.
Взять, к примеру, ревью тул.
Я прихожу на работу, открываю глагне cr/ и вижу все свои входящие и исходящие ревью. Те, что требуют моего внимания ("мяч на моей стороне"), помечены жирным. Сразу понятно, куда смотреть и что делать.
Вот посылаю я diff на ревью. Кому послать? Добрый автокомплит показывает мне наиболее подходящих кандидатов, учитывая временные зоны и отпуска. Он так же подсказывает, какие условия нужно удовлетворить до полного комплекта ревьюеров (что-то вроде "я смотрю вы не сильны в JavaScript, и ваш ревьюер тоже, добавьте эксперта, например, x@").
Если ревьюер вдруг уходит в отпуск, срабатывает линтер. Если ревью горит, можно легко найти замену через тот же автокомплит.
Если поставить пару галочек в ревью, система автоматически смёржит ваш код в мастер когда ревьюеры поставят LGTM все комментарии будут отвечены, а тесты пройдены, делая ребейз по мере необходимости (ala mergify.io, только гораздо лучше).
Весь код живёт в одном большом репозитории. Можно делать сквозные изменения в проектах нескольких команд, каждый коммит на мастере сохранит билд всех команд зелёным (за редким исключением длинных тестов, исполняемых асинхронно после коммита). Это не избавляет вас о необходимости релизить в правильном порядке, но всё равно устраняет огромное количество попоболи.
Есть куча ботов, для которой конфиги в репе являются источником правды, они автоматически обновляют состояние внешних систем так, чтобы оно соответствовало конфигам (к примеру, при изменении настроек репликации данных бот сам переложит данные туда, где они должны быть).
Недавно сделали удобное решение для Stacked Diffs ala Differential.
Об эргономике код ревью
Ключевая проблема GH для меня: на сколь нибудь серьёзных код ревью очень сложно понять, какие из комментариев остались без внимания. Как только код изменился, GH помечает комментарии как Outdated. Чтобы убедиться, что ты ничего не пропустил, нужно постоянно прыгать между вкладками и пытаться понять, изменился ли код нужным образом.
Комментирование кода в Critique работает только в "пакетном" режиме. Пишешь себе комментарии, когда просмотрел весь код, нажимаешь кнопку и все комментарии уходят разом. Это означает что
- Ревьюер получит только один e-mail, а не по сообщению на каждый коммент.
- Ревью-тула поймёт, что теперь теперь мяч на стороне автора, и пометит ревью жирным в его дашборде.
- У ревьюера будет возможность удалить или поменять комментарии после того, как он увидит весь код (очень часто некоторые вопросы разрешаются сами собой).
У GH тоже есть "пакетный" режим, он частично решает проблемы (1) и (3), но там много странностей и багов. Например,
- На странице Conversation нет возможности объединять комментарии в "пакеты". Поскольку отвечают все там, GH спаммит нотификациями.
- Ответы в тредах, сделанные в "пакетном" режиме, появляются в Conversation дважды (sic!).
- Поскольку треды, относящиеся к "старым версиям", исчезают из "Files Changed", на них можно отвечать только отдельно.
Все комментарии в Critique относятся к конкретному снэпшоту кода. Critique понимает алгебру патчей и показывает ваш комментарий в новых версиях кода в правильном месте.
Для сравнения, GH поднимает лапки кверху и помечает комментарий Outdated. Особо радует, когда пишешь комментарий, а автор решает сделать rebase. Отослать комментарий в GH будет нельзя: нужно скопировать текст, обновить страницу, снова найти нужное место и вставить комментарий. Удобненько.
В Critique есть удобные ползунки, которые позволяют вам видеть эволюцию версий на код-ревью, система автоматически выставляет их так, чтобы показывать только непросмотренные изменения (на GH можно выбирать отдельные отрезки коммитов для просмотра, но комментировать старые версии обычно нельзя, Viewed там тоже есть, но его нужно тыкать вручную).
В общем, у меня есть документ с двумя страницами багов и странностей GH.
Большинство предпочитает жевать кактус и делать вид, что GH является удобной системой для код-ревью, но на мой взгляд это просто Стокгольмский синдром.
За счет «магии» бренда получают большой поток наивных разработчиков.В геймдеве это ещё сильнее выражено. Там огромный поток желающих не просто «работать в крутой компании» а «творить в команде, от которой фанател с детства». В результате, много кто наблюдает, что чем больше и именитее компания, тем больше там переработок и меньше зарплата. Потому что «а зачем?», поток вьюнош пылких со взором горящим не иссякает, почему бы и не воспользоваться.
UFO just landed and posted this here
А, теперь я понял, почему у них приложение батл.нет работает, как будто его студенты писали.
Шикарно оно у них работает и интерфейс приятный. Вы батенька, видимо от мылору и проих юбисофтов ланчеров не видели, сразу, я вам скажу, перестаешь быть таким требовательным.
Каюсь, не видел. Но и других приложений, которые подвисают аж до проявления белой границы формы, когда кликаешь внутри этого приложения на ссылку, я тоже не видел уже довольно давно.
А это разве не поведение IE по умолчанию?
Они «профессионально» с настройками прокси работают
> Вроде деньги предлагают неплохие, но условия всякие типа: вот тебе небольшая зп, вот там раз в год будет бонус огромный (если пройдешь перфоманс ревью), вот тебе акции (которые сможешь получить через 5 лет).
Акции тебе дают после прохода испытательного, каждые 3 месяца после финансового отчета четверти. Бонус дают всегда, 2 раза в год, его размер зависит от перформанса только процентно, но не бывает ниже 80%.
> Сидение на каком-то самописном легасе говне. Как правило, в больших компаниях куча своих каких-то инструментов. И если ты потратил свое время, чтобы их изучить, то при переходе в другую компанию твой опыт просто обнуляется.
В такой компании как правило ты учишься не конкретному фрэймворку или еще чему-то, ты учишься подходу к работе.
> Ну и самая вишенка. Вот такие компании, на всяких собеседованиях относятся к тебе, как говну. Вот тебе задача какая-то олимпиадная решай, вот тебе белая доска, напиши нам все типы из Python и прочее. И то, что ты там все это сделал (потратил куча времени), вообще не факт, что тебя возьмут.
Оплата перелета, отеля, еды и прочего это как к говну? Задачи не олимпиадные, а вполне из практике работы в этих компаниях, а не берут если не можешь решить простенькие алгоритмы.
Акции тебе дают после прохода испытательного, каждые 3 месяца после финансового отчета четверти. Бонус дают всегда, 2 раза в год, его размер зависит от перформанса только процентно, но не бывает ниже 80%.
> Сидение на каком-то самописном легасе говне. Как правило, в больших компаниях куча своих каких-то инструментов. И если ты потратил свое время, чтобы их изучить, то при переходе в другую компанию твой опыт просто обнуляется.
В такой компании как правило ты учишься не конкретному фрэймворку или еще чему-то, ты учишься подходу к работе.
> Ну и самая вишенка. Вот такие компании, на всяких собеседованиях относятся к тебе, как говну. Вот тебе задача какая-то олимпиадная решай, вот тебе белая доска, напиши нам все типы из Python и прочее. И то, что ты там все это сделал (потратил куча времени), вообще не факт, что тебя возьмут.
Оплата перелета, отеля, еды и прочего это как к говну? Задачи не олимпиадные, а вполне из практике работы в этих компаниях, а не берут если не можешь решить простенькие алгоритмы.
В такой компании как правило ты учишься [...] подходу к работе.
Который не только нигде кроме ФАГМАН не применим, а еще и попросту губителен для хорошего инженера.
Оплата перелета, отеля, еды и прочего это как к говну?
Это все только на туземцев действует, как бусы. Ну и да, так ведут себя все компании, которые вообще имеет смысл рассматривать.
Который не только нигде кроме ФАГМАН не применим, а еще и попросту губителен для хорошего инженера.А с этого момента — поподробнее. Что изменилось с момента возникновения этих компаний в индустрии? Она все, вроде, достаточно «новые», сказать, что они существуют ща счёт задела, сделанного в XIX веке никак не получится…
UFO just landed and posted this here
Идея классификации хорошая, но сама классификация уж больно коротка…
Как будто кроме гуглояндексов и аутсорсинговых контор мало «стандартных» примеров.
Вот, из моего личного опыта, то, что встречается на территории России:
1. Всяческие корпорации, сиречь большие конторы. Они ищут очередную шестерёнку. От них чаще всего можно ожидать изрядное число формальностей и анкет (апогей — вопрос о том, почему вы хотите у нас работать, да...), и стандартизованного собеседования с замашками на мировых лидеров, т.е. как у гугла или яндекса.
2. Вендорские фирмы (те, которые разрабатывают софт на продажу и хвалятся топовым местом в нише размером с 5% рынка). Тут, в зависимости от рыночной ситуации, либо рабочую лошадку ищут, либо скакуна-чемпиона. Но от обоих ожидают верности на века. Спрашивают ближе к делу, но часто имеют мутные схемы поощрения, и любят сбивать самооценку кандидата, ради чего придумывают ломовые вопросы для собеседования. Да, кстати, эти чаще все балуются такой формулировкой, когда звонят после собеседования: «вы нам/директору очень понравились, приходите прям завтра на -10% от вашего минимума».
3. Рога и копыта. Тут чаще всего сами не очень знают, кто им нужен и сколько это стоит. Почти всегда ищут через кадровые агентства. Вполне реальный вариант для проведения собеседования пригласить студента, друга директора. Сей «студент», наверняка, будет пытаться подловить вас хоть на чём-то, дабы самому не выглядеть лохом.
Как будто кроме гуглояндексов и аутсорсинговых контор мало «стандартных» примеров.
Вот, из моего личного опыта, то, что встречается на территории России:
1. Всяческие корпорации, сиречь большие конторы. Они ищут очередную шестерёнку. От них чаще всего можно ожидать изрядное число формальностей и анкет (апогей — вопрос о том, почему вы хотите у нас работать, да...), и стандартизованного собеседования с замашками на мировых лидеров, т.е. как у гугла или яндекса.
2. Вендорские фирмы (те, которые разрабатывают софт на продажу и хвалятся топовым местом в нише размером с 5% рынка). Тут, в зависимости от рыночной ситуации, либо рабочую лошадку ищут, либо скакуна-чемпиона. Но от обоих ожидают верности на века. Спрашивают ближе к делу, но часто имеют мутные схемы поощрения, и любят сбивать самооценку кандидата, ради чего придумывают ломовые вопросы для собеседования. Да, кстати, эти чаще все балуются такой формулировкой, когда звонят после собеседования: «вы нам/директору очень понравились, приходите прям завтра на -10% от вашего минимума».
3. Рога и копыта. Тут чаще всего сами не очень знают, кто им нужен и сколько это стоит. Почти всегда ищут через кадровые агентства. Вполне реальный вариант для проведения собеседования пригласить студента, друга директора. Сей «студент», наверняка, будет пытаться подловить вас хоть на чём-то, дабы самому не выглядеть лохом.
UFO just landed and posted this here
Да, и это часто хороший вариант! :)
Т.е. сами по себе такие конторы не обязательно плохие.
Т.е. сами по себе такие конторы не обязательно плохие.
Я знаю людей которые не знают и не умеют практически ничего, но с легкостью прошли бы такое собеседование потому что у них раздутая самооценка и они думают что знают все. Плюс, например, индусы по моему опыту всегда отвечают «да, знаю», «да, умею» даже если не имеют ни малейшего представления — их этому где-то учат, видно.
Опасный метод проведения собеседований, на мой взгляд.
Опасный метод проведения собеседований, на мой взгляд.
Обычно просто начинаешь говорить «за жизнь».
Что делал, какие были проблемы. Почему делали так, а не эдак.
Обычно если сам более менее в теме, то сможешь оценить насколько глубоко копал соискатель ту или иную тему.
Что делал, какие были проблемы. Почему делали так, а не эдак.
Обычно если сам более менее в теме, то сможешь оценить насколько глубоко копал соискатель ту или иную тему.
Вот именно такого плана у меня было собеседование в альфе. Но, во-первых, у меня был опыт в разработке 25+ лет, причем, на достаточно объемных проектах, причем, с нуля, с формирования архитектуры. Во-вторых, брали на бэкенд, причем, самый глубокий. Под разработку на платфрме IBM i которую в РФ знает очень ограниченное количество людей (и все они сосредоточены в альфе, райфе, росбанке и еще паре-тройке компаний). Т.е. интересовало не знание каких-то фреймворков, а способоность быстро и глубоко вникнуть в особенности платформы (а она очень особенная, с виндой и никсами общего очень и очень мало) и уметь писать эффективный код под высоконагруженные системы (сейчас это порядка 3млрд изменений бд в сутки и постоянно растет).
В общем, был разговор «за жизнь» с теми, с кем сейчас работаю без каких-либо синтетических тестов.
А потом 3 месяца испытательный срок, фактически обучение и проверка «сработаемся — не сработаемся».
В общем, был разговор «за жизнь» с теми, с кем сейчас работаю без каких-либо синтетических тестов.
А потом 3 месяца испытательный срок, фактически обучение и проверка «сработаемся — не сработаемся».
А хитрая система от IBM – случайно не мейнфреймы какие? z9 или z11?
Мейнфреймы, ага. PowerS9 сейчас. Были 828 на проме и 824 на тесте, сейчас 924 на тесте и, видимо, 928 на проме. Стоит там IBM i, бывш. AS/400
Эх, у меня весь опыт общения с живыми мейнфреймами был только в виде пары лабораторных работ в институте через 3270 терминал. Я так и не понял их ценности, хотя у них внутри всё задублировано, вплоть до системы охлаждения.
Тут общение через эмулятор терминала 5250, т.н. «зеленый экран».
Ценность… Очень цельная система. В нее встроено все — БД (DB2), компиляторы языков (CL, COBOL, RPG, C/C++). Очень нравится концепция ILE (Integrated Language Environment) — исполняемая программа может быть собрана из модулей, каждый из которых написан на разных языках. У нас широко используется RPG и C/C++. В рамках одной программы можно писать часть функций на RPG, часть на C/C++ и все это будет работать, главное правильно интерфейсы прописать.
Очень много концепций, которые просто не имеют аналогов в других системах. Те же группы активации в рамках процесса (JOB'а). Много не имеющих аналогов системных объектов типа DTAARA, USRSPC, DTAQUE, USRIDX и т.п.
Сситема изначально объектно-оринтированная. Т.е. основной постулат — «все есть объект». причем, заложено все это на самом глубинном уровне.
Ну и производительность… Тестовый сервер — это SMT8 процессор на 18 ядер, 1800Гб оперативки, два SSD дисковых массива 87 и 15 Тб.
На боевых серверах стоит 4 «книжки» по 4 12-ядерных SMT8 процессора (т.е. в сумме 192 ядра, каждое из которых работает в 8 потоков).
И при всем этом очень жесткие требования к оптимизации кода. Есть целый список «нефункциональных требований» как нужно делать и как делать нельзя. Ну и те задачи, что много работают в фоне, обязательно проходят нагрузочное (помимо компонентного, интеграционного и бизнес) тестирование. А там могут вернуть с замечениями типа:
Т.е. решение некоторых задач требует некоторой изворотливости ума и придумывания хитрых алгоритмов Например, замена order by по неиндексированным полям в sql запросе на предварительное занесение результатов выборки в автосортируемый по нужному ключу массив может дать выигрыш по времени в 5-6 раз. Или разделение запроса на несколько частей с использованием высокоселективной предвыборки с использованием частотного словаря вместо агрегатной listagg в запросе как-то позволило сократить время работы процедуры с 3 сек до 150-200мсек :-)
Ценность… Очень цельная система. В нее встроено все — БД (DB2), компиляторы языков (CL, COBOL, RPG, C/C++). Очень нравится концепция ILE (Integrated Language Environment) — исполняемая программа может быть собрана из модулей, каждый из которых написан на разных языках. У нас широко используется RPG и C/C++. В рамках одной программы можно писать часть функций на RPG, часть на C/C++ и все это будет работать, главное правильно интерфейсы прописать.
Очень много концепций, которые просто не имеют аналогов в других системах. Те же группы активации в рамках процесса (JOB'а). Много не имеющих аналогов системных объектов типа DTAARA, USRSPC, DTAQUE, USRIDX и т.п.
Сситема изначально объектно-оринтированная. Т.е. основной постулат — «все есть объект». причем, заложено все это на самом глубинном уровне.
Ну и производительность… Тестовый сервер — это SMT8 процессор на 18 ядер, 1800Гб оперативки, два SSD дисковых массива 87 и 15 Тб.
На боевых серверах стоит 4 «книжки» по 4 12-ядерных SMT8 процессора (т.е. в сумме 192 ядра, каждое из которых работает в 8 потоков).
И при всем этом очень жесткие требования к оптимизации кода. Есть целый список «нефункциональных требований» как нужно делать и как делать нельзя. Ну и те задачи, что много работают в фоне, обязательно проходят нагрузочное (помимо компонентного, интеграционного и бизнес) тестирование. А там могут вернуть с замечениями типа:
Из PEX статистики работы XXX видно, что 33% времени и 36% ресурсов CPU тратится на выполнение YYY в программе ZZZ, т.е. парсинг статических выражений при подготовке SQL запроса,
Сократить данные русурсозатраты практически до нуля можно путем описания параметров sql запросов через SQL Descriptor Area (SQLDA).
Поскольку TTT один из наиболее активно используемых сервис модулей, необоснованное повышенное ресурсопотребление является малодопустимым. Просьба инициировать доработку ZZZ.
Т.е. решение некоторых задач требует некоторой изворотливости ума и придумывания хитрых алгоритмов Например, замена order by по неиндексированным полям в sql запросе на предварительное занесение результатов выборки в автосортируемый по нужному ключу массив может дать выигрыш по времени в 5-6 раз. Или разделение запроса на несколько частей с использованием высокоселективной предвыборки с использованием частотного словаря вместо агрегатной listagg в запросе как-то позволило сократить время работы процедуры с 3 сек до 150-200мсек :-)
концепция ILE (Integrated Language Environment)
CLR без IL и JIT? это как(=
Э-э-э… Что есть CLR?
Там речь о CL — Command Language в AS/400. Системный язык, часть команд (полный референс порядка 2300 страниц в pdf) может использоваться в интерактиве в терминальной сессии, но можно и программы писать на нем (что характерно, программа на CL компилируется командой того же CL).
Там речь о CL — Command Language в AS/400. Системный язык, часть команд (полный референс порядка 2300 страниц в pdf) может использоваться в интерактиве в терминальной сессии, но можно и программы писать на нем (что характерно, программа на CL компилируется командой того же CL).
Вот что значит, когда встречаются представители разных вселенных(= Common Language Runtime — это .NET-овская среда, которая может выполнять программы, собранные из dll, так же написанных, например, на C#, F#, VB и т. д. Но за счет 2-этапной компиляции сначала в Intermediate Language, а затем уже JIT-ом в машинный код. Что-то общее с вашим случаем чувствуется, но у меня, к сожалению, не хватает знаний, чтобы осознать.
Что-то общее с вашим случаем чувствуется, но у меня, к сожалению, не хватает знаний, чтобы осознать.Собственно CLR и сделан по образу и подобию TIMI («Technology Independent Machine Interface») — только более убого… потому что Microsoft не имеет такого контроля.
Это только кажется, что Microsoft контролирует всё и вся в Windows. А вот убить нативный код… не может. Потому что System/3, System/32, System/34, System/36, System/38 и так далее поставляются только IBM, а потому «доктор сказал в морг — значит в морг».
Поэтому IBM может сказать «начиная с System/38 праямой доступ к машинному коду отсуствует»… всё. А Microsoft приходится доказывать что «managed code» в чём-то лучше, потому что Win32 API никто ж не отменял (один раз попробовали отменить в особой версии Windows — так в результате она сама отменилась).
Да, одна из особенностей AS-ки — есть граница, ниже которой нет доступа никому, кроме собственно разработчиков самой ОС. Вообще. Совсем нет. Никак.
Я не настолько силен в глубинных потрохах AS-ки, но, как понимаю, все компиляторы со всех поддерживаемых в ILE языков (а они все встроены в саму ОС) генерируют модули (аналог объектных файлов), которые и есть набор MI инструкций. Т.е. на этапе модуля уже неважно на каком языке он был написан.
А дальше эти модули уже собираются в единый исполныямый объект (PGM).
Собственно, если у нас программа из одного модуля (один исходник), то можем сразу вызвать CRTBNDPGM и получить на выходе PGM объект одной командой.
А если исходников несколько, то сначала для каждого CRTMOD — создаем модуль, а потом CRTPGM из этих модулей (на этом же этапе происходит разрешение внешних ссылок на функции, располложенные в сервисных программах — SRVPGM — некий аналог виндовых DLL)
у нас основной язык RPG, но многие вещи пишутся на С/С++. Там, где это проще и быстрее. И часто бывает что или программа лепится из нескольких модулей — основной на RPG, вспомогательные функции (ну, скажем, парсинг JSON строк) — на С/С++.
Или на С/С++ пишутся сервисные программы (работа сописками, наборами и т.п. к примеру) функции из которых потом используются в RPG программах.
Там все еще веселее — можно использовать функции из C RTL просто правильно объявив прототип для вызова из RPG — оно само их находит.
Так испоользуем memcmp, к примеру, qsort/bsearch, функции для работы с файлами на IFS (интегрированная файловая система — альтернативный доступ к файлам на AS/400).
В общем, тут много всякой специфики, это свой мир и достаточно занимательный.
Я не настолько силен в глубинных потрохах AS-ки, но, как понимаю, все компиляторы со всех поддерживаемых в ILE языков (а они все встроены в саму ОС) генерируют модули (аналог объектных файлов), которые и есть набор MI инструкций. Т.е. на этапе модуля уже неважно на каком языке он был написан.
А дальше эти модули уже собираются в единый исполныямый объект (PGM).
Собственно, если у нас программа из одного модуля (один исходник), то можем сразу вызвать CRTBNDPGM и получить на выходе PGM объект одной командой.
А если исходников несколько, то сначала для каждого CRTMOD — создаем модуль, а потом CRTPGM из этих модулей (на этом же этапе происходит разрешение внешних ссылок на функции, располложенные в сервисных программах — SRVPGM — некий аналог виндовых DLL)
у нас основной язык RPG, но многие вещи пишутся на С/С++. Там, где это проще и быстрее. И часто бывает что или программа лепится из нескольких модулей — основной на RPG, вспомогательные функции (ну, скажем, парсинг JSON строк) — на С/С++.
Или на С/С++ пишутся сервисные программы (работа сописками, наборами и т.п. к примеру) функции из которых потом используются в RPG программах.
Там все еще веселее — можно использовать функции из C RTL просто правильно объявив прототип для вызова из RPG — оно само их находит.
Так испоользуем memcmp, к примеру, qsort/bsearch, функции для работы с файлами на IFS (интегрированная файловая система — альтернативный доступ к файлам на AS/400).
В общем, тут много всякой специфики, это свой мир и достаточно занимательный.
У TIMI еще один плюс — в исполняемом коде хранится также и набор MI инструкций и метка для какой платформы из этих инструкций собран исполняемый код. Меняем платформу (скажем с 824 на 924), переносим исполняемый модуль. при первом запуске система сравнивает на какой платформе оно запущено и под какую собрано. если не совпадает, то происходит автоматическая пересборка MI инструкций под текущую платформу.
Т.е. исполняемый код при переносе будет оптимизирован под новую платформу. Это и есть TI.
Т.е. исполняемый код при переносе будет оптимизирован под новую платформу. Это и есть TI.
UFO just landed and posted this here
Ну в региональных рогах и копытах индусы, я думаю, большая редокость.
3 вариант у меня реально был :)
UFO just landed and posted this here
Спасибо!
Как по мне, идеально было бы просто начать с методологии обучения работников для проведения собеседования. В крупных конторах будет все плюс — минус как по учебнику, и далее этих стандартов будет просто меньше… В мелких же, как повезет, от простых разговоров, до чего угодно… Тк, как правило, собеседование проводит обычный менеджер, который, просто погуглил что спросить у программиста на собеседовании )
Задачки на собеседовании очень хорошо закрывают негодование "они там в HR вообще резюме кандидатов читают"?
Добавлю еще один способ, который несколько раз попадался при поиске работы в Германии — алгоритмические задачки в онлайн-компиляторе. Все полностью автоматизировано — система дает задачу и полчаса-час времени, в конце результат также автоматически прогоняется тестами (оценивается правильность и скорость работы алгоритма) и отсылается работодателю. Цель та же, первичный отсев.
В целом согласен кроме одного пункта:
Гораздо страннее, когда такие же методы применяет «молодая динамично развивающаяся компания» в которую приходит по 5-6 резюме в месяц.
Поверьте, если бы можно было как-то иначе найти хорошего кандидата из сотни посредственных, то крупный бизнес бы искал по-другому.У отсева по алгоритмам цель не «найти хорошего» а «не пропустить плохого». Просто когда у тебя сотни соискателей на место, ты можешь себе позволить отбраковать «не глядя» 3/4 хороших кандидатов, ведь и из оставшихся 1/4 будет кого выбрать.
Гораздо страннее, когда такие же методы применяет «молодая динамично развивающаяся компания» в которую приходит по 5-6 резюме в месяц.
На самом деле всё ещё смешнее. Если у вас большая компания, то хитрую борьбу c таблицей, о которой так плачет JustDont — найдётся кому сделать. А вот если вы наивно сотворили O(N!) заложившись на то, что «n всё равно выше десятка не вырастет даже в теории»… а оно таки выросло… до пятнадцати (что привело к тому, что ваша страничка стала реагировать на нажатия буквально часами)… это кому-то придётся переписывать. И, скорее всего, в авральном порядке… а им это надо?
А в стартапе да — там замены для человека нет и потому важно не только, чтобы он дров не наломал, но и, чтобы он собственно умел работать с теми технологиями, с которыми он столкнётся… без помощи со стороны «старших товарищей».
А в стартапе да — там замены для человека нет и потому важно не только, чтобы он дров не наломал, но и, чтобы он собственно умел работать с теми технологиями, с которыми он столкнётся… без помощи со стороны «старших товарищей».
Если у вас большая компания, то хитрую борьбу c таблицей, о которой так плачет JustDont — найдётся кому сделать.
Не знаю как вы, но я бываю в публичном вебе достаточно часто, чтоб знать, что увы, таки нифига не находится. Равно как и на весь гугл не нашлось никого, кто б мог сделать гуглопочту размером меньшим, чем 6.7 Мб, исключая, конечно, тех мастодонтов, что написали plain-html версию (она очень-очень старая).
Наверное это потому, что всех бросили на тщательные проверки того, чтоб O(N!) нигде не было. А гуглопочту на плохом интернете грузить — ну, наловчитесь и в простую версию ткнете.
Собственно, адекватный человек в состоянии понять что требуется изучить и, соответственно, изучит. Опять же, если он хочет устроиться в Гугл.
Добавлю, с точки зрения маленькой продуктовой компании, почему и зачем мы даём тестовое задание, и как повысить ваши шансы на устройство. Дисклеймер: последние несколько месяцев мы очень неспешно расширяемся, и собеседуем кандидатов удалённо. И, конечно, это всё личное мнение, не более.
Зачем вообще давать тестовое. Первая причина — отсеять хлопцев, рассылающих резюме «на удачу». Может это мне не везло, но иногда попадаются кадры с уровнем «вчера купил книжку по программированию».
Вторая причина — посмотреть, как вообще человек идёт на контакт, как он всё оформит, зафигачит ли он весь код в одном спагетти-стайл файле или все-таки сделает хотя бы зачатки архитектуры. Формальная корректность решения тут на последнем месте, потому что это — неважно. Ошибку в коде поправить легко, а вот научить «делать хорошо» уже гораздо сложнее.
Как повысить ваши шансы на трудоустройство: напишите readme к тестовому заданию. Среднее тестовое с нормальным readme ценнее идеального кода без единого комментария. Потому что становится понятно, как вы думали, какие допущения сделали, почему выбрали A вместо B, какие варианты вообще рассматривали, как вы бы сделали в идеале, если бы это был реальный проект и т.д.
Я понимаю, что на тестовые задания не всем хочется тратить время — и уважаю это. Но если уж вы взялись его сделать, лучше потратить ещё 10 минут на нормальное оформление.
То же самое касается вашего кода на Гитхабе — я вижу ваш профиль, ваши репозитории, ваш код, но не вижу какую задачу вы решали. Как я могу оценить вашу крутизну? У меня нет отправной точки. Серьёзно. Добавляйте readme, вы сразу вырастете в глазах нанимателя.
Зачем вообще давать тестовое. Первая причина — отсеять хлопцев, рассылающих резюме «на удачу». Может это мне не везло, но иногда попадаются кадры с уровнем «вчера купил книжку по программированию».
Вторая причина — посмотреть, как вообще человек идёт на контакт, как он всё оформит, зафигачит ли он весь код в одном спагетти-стайл файле или все-таки сделает хотя бы зачатки архитектуры. Формальная корректность решения тут на последнем месте, потому что это — неважно. Ошибку в коде поправить легко, а вот научить «делать хорошо» уже гораздо сложнее.
Как повысить ваши шансы на трудоустройство: напишите readme к тестовому заданию. Среднее тестовое с нормальным readme ценнее идеального кода без единого комментария. Потому что становится понятно, как вы думали, какие допущения сделали, почему выбрали A вместо B, какие варианты вообще рассматривали, как вы бы сделали в идеале, если бы это был реальный проект и т.д.
Я понимаю, что на тестовые задания не всем хочется тратить время — и уважаю это. Но если уж вы взялись его сделать, лучше потратить ещё 10 минут на нормальное оформление.
То же самое касается вашего кода на Гитхабе — я вижу ваш профиль, ваши репозитории, ваш код, но не вижу какую задачу вы решали. Как я могу оценить вашу крутизну? У меня нет отправной точки. Серьёзно. Добавляйте readme, вы сразу вырастете в глазах нанимателя.
Вот не поверите. Не так давно (менее полгугода назад) брали на работу человека. Опыта — ноль. Алгоритмическое мышление отсутствует напрочь. Но в разговоре за жизнь уловилась в нем некая целеустремленность и желание постичь глубины.
Взяли стажером на полгода. Через три месяца уже посовещались и перевели в штат. Ибо прогресс невообразимый. Первые задачи мы решали просто за него. Ну то есть разжевывали как и с какой строны браться, человек сидел и старательно ушами хлопал. Но потом вгрызался в тему и добивал до победного. И все, что ему хоть раз говорили, все оседало в голове, устаканивалось там и потом шло в дело. Сейчас уже вполне самостоятельный разработчик, коммуникативный, пройдет еще год и будет классным спецом в своей области.
Но на любом формальном тесте посыпался бы в том время. только в разговоре смогли потенциал разглядеть.
Взяли стажером на полгода. Через три месяца уже посовещались и перевели в штат. Ибо прогресс невообразимый. Первые задачи мы решали просто за него. Ну то есть разжевывали как и с какой строны браться, человек сидел и старательно ушами хлопал. Но потом вгрызался в тему и добивал до победного. И все, что ему хоть раз говорили, все оседало в голове, устаканивалось там и потом шло в дело. Сейчас уже вполне самостоятельный разработчик, коммуникативный, пройдет еще год и будет классным спецом в своей области.
Но на любом формальном тесте посыпался бы в том время. только в разговоре смогли потенциал разглядеть.
Проблема в том, что далеко не все могут и хотят вот так растить человека внутри своей компании. Нет ресурсов, нет менторов. Велика вероятность, что вместо возврата инвестиций на обучение он потом просто возьмет и упорхнет куда-то, где платят больше. И нет, не всегда возможно просто взять и заплатить больше, чтобы не упорхнул — на рынке всегда найдется кто-то богаче вас, кто предложит лучшие условия, особенно если вы — маленькая контора из пары человек.
Поэтому несмотря на весь потенциал, таких людей многим компаниям тоже целесообразно отсеивать. Что они и делают.
Поэтому несмотря на весь потенциал, таких людей многим компаниям тоже целесообразно отсеивать. Что они и делают.
Согласен. Тут вопрос подхода. Но в нашем случае готового специалиста, знающего AS/400 и RPG найти малореально. Так что все равно готовить человека пока он сможет работать самостоятельно. Так что все равно первые три месяца — обучение. Обычно через полтора два месяца человек уже выходит на несложные боевые задачки (поначалу подбирается что-то небольшое).
Бывают и ошибки, конечно. Второй кандидат, тоже из недавних, на собеседовании полный восторг и радужные надежды, а сейчас вопросы — что с ним делать дальше. То ли попытаться найти подход, то ли распрощаться.
Бывают и ошибки, конечно. Второй кандидат, тоже из недавних, на собеседовании полный восторг и радужные надежды, а сейчас вопросы — что с ним делать дальше. То ли попытаться найти подход, то ли распрощаться.
Видел такое. На соседний проект собеседовали кандидата. Двое тех. спецов сказали: "он не умеет в программирование", ПМ сказал: "но есть у него какая-то жилка, возьмем". Прошло три года. Насколько мне известно, до сих пор за ним коллеги код правят...
Ну дык клаcсика жанра же:
Он вообще отличный специалист — только не в той области в которой его коллеги.
Он вообще отличный специалист — только не в той области в которой его коллеги.И это тоже верно.
В нашем случае от этого два барьера — во-первых, в очень сомнительном случае предлагается не штат, а стажировка на полгода (20 часов в неделю, т.е. условно полставки). Часто такой вариант бывает интересен студентам старших курсов.
По результатам стажировки уже предлагается или переход в штат (возможно до окончания стажировки), или… Просто окончание стажировки за которой не последовало никаких предложений.
В любом случае, каждый новый сотрудник берется с испытательным сроком в три месяца. Зарплата на испытательном сроке полная, но плюшки типа ДМС и страхования НС не оформляются.
На испытательный срок ставятся конкретные цели. Фактически это срок обучения (напомню — платформа очень специфическая, готовых спецов по ней найти малореально). К концу срока человек уже должен уметь решать несложные (ну так скажем, типовые) боевые задачи (и иметь уже одну-две поставки, хотя бы на уровне бизнес тестирования).
По окончании срока оценка, там уже решается будет человек работать дальше здесь или нет.
Собственно говоря, я к тому, что «конвеерное тестирование» на собеседовании путем раздачи тестовых заданий решение очень простое (для HR), но в качестве фильтра далеко не самое лучшее.
В нашем случае от этого два барьера — во-первых, в очень сомнительном случае предлагается не штат, а стажировка на полгода (20 часов в неделю, т.е. условно полставки). Часто такой вариант бывает интересен студентам старших курсов.
По результатам стажировки уже предлагается или переход в штат (возможно до окончания стажировки), или… Просто окончание стажировки за которой не последовало никаких предложений.
В любом случае, каждый новый сотрудник берется с испытательным сроком в три месяца. Зарплата на испытательном сроке полная, но плюшки типа ДМС и страхования НС не оформляются.
На испытательный срок ставятся конкретные цели. Фактически это срок обучения (напомню — платформа очень специфическая, готовых спецов по ней найти малореально). К концу срока человек уже должен уметь решать несложные (ну так скажем, типовые) боевые задачи (и иметь уже одну-две поставки, хотя бы на уровне бизнес тестирования).
По окончании срока оценка, там уже решается будет человек работать дальше здесь или нет.
Собственно говоря, я к тому, что «конвеерное тестирование» на собеседовании путем раздачи тестовых заданий решение очень простое (для HR), но в качестве фильтра далеко не самое лучшее.
Но почему такого работника там держат? И как он испытаательный срок прошел? За три года и менеджеры могли сообразить, что взяли не того человека.
Эээээ… А с чего это сотни соискателей на место? Я когда резюме выкладываю, мне раз пять сам Яндекс звонит, а потом еще конторы хедхантинговые в яндекс пытаются устроить. Про Сбербанк я ваще молчу, они мертвого задерут.
Поэтому вот прям про армию желающих лучше не писать.
Поэтому вот прям про армию желающих лучше не писать.
Тут автор ошибся насчёт Яндекса. Т.к. ему приходится конкурировать со всем аутсорсом в России. Кандидатов там конечно не сотни на место.
Но в случае с Microsoft, Google и т.п. конторами, кандидатов только из Азии могут быть сотни. Причём, вы не представляете азиатский менталитет. Там любой кто навалял «Hello World» будет слать заявки на Senior -ов.
Но в случае с Microsoft, Google и т.п. конторами, кандидатов только из Азии могут быть сотни. Причём, вы не представляете азиатский менталитет. Там любой кто навалял «Hello World» будет слать заявки на Senior -ов.
Я не думаю, что гугл платит дофигилиард баксов разработчикам, потому что их просто навалом и девать некуда…
Вы вообще читаете хотя бы иногда тексты, на которые отвечает? Да, разработчиков мало, Senior'ов, наваявших в своей жизни пару «Hello World»ов (один — на DB2, другой — на Tkinter) — много.
Вопрос: что со всем этим делать? Всех этих Senior'ов хотя бы билетами для бесплатного путешествия обеспечивать — можно разориться…
Вопрос: что со всем этим делать? Всех этих Senior'ов хотя бы билетами для бесплатного путешествия обеспечивать — можно разориться…
Еще раз: либо дефицит кадров, либо профицит. И да если нужны программисты, а на рынке мильон шоферов, то это не спасает.
Если кадров дефицит, то зарплаты повышаются, если профицит, то зарплаты снижают. У гугла зарплаты большие и это значит им разработчиков требуемого уровня не хватает. А в начале статьи написано, что наоборот поток соискателей большой.
НУ и логично, если у вас золота мало на тонну грунта, то не стоит ставить на входе микросито, которое откинет 99% золота? Сначала крупные фильтры, потом дробилки, потом фильтры мельче и мельче.
И да я пониманию, что среди них много «брака», но это все равно нелогично вышвыривать всех кто не может написать квиксорт на бумажке без ошибок, верно?
PS Если вы крупнейшая технологичная компания, что ж у вас код такое гавно, что там только сеньоры разобраться могут?
Если кадров дефицит, то зарплаты повышаются, если профицит, то зарплаты снижают. У гугла зарплаты большие и это значит им разработчиков требуемого уровня не хватает. А в начале статьи написано, что наоборот поток соискателей большой.
НУ и логично, если у вас золота мало на тонну грунта, то не стоит ставить на входе микросито, которое откинет 99% золота? Сначала крупные фильтры, потом дробилки, потом фильтры мельче и мельче.
И да я пониманию, что среди них много «брака», но это все равно нелогично вышвыривать всех кто не может написать квиксорт на бумажке без ошибок, верно?
PS Если вы крупнейшая технологичная компания, что ж у вас код такое гавно, что там только сеньоры разобраться могут?
Есть такой эффект: кто умеет программировать — давно нашли себе работу, кто не умеет — ходит по собеседованиям. Вот и получается "парадокс": специалистов на рынке дефицит, а поток соискателей огромный.
я не спорю. Если поток огромный поставь сначала грубые фильтры, потом тонкие. А то тонкие быстро забьются, а их дорого менять.
Если поток маленький можно сразу поставить тонкие. У гугла стоят сразу тонкие — на алгоритмы. Значит поток соискателей невелик.
Если поток маленький можно сразу поставить тонкие. У гугла стоят сразу тонкие — на алгоритмы. Значит поток соискателей невелик.
А то тонкие быстро забьются, а их дорого менять.Дак как раз алгиритмические задачи — это нифига не «тонкий» фильтр. Тесты и алгоритмические вопросы очень дёшевы для рекрутеров — потому и применяются. Их легко оценивать и времени на то, чтобы принять на их основе решения нужно немного.
А что они часть «хороших» соискателей отсекают — не наша проблема. Если кандидат реально хороший — он в другом месте найдёт работу, если он только в кавычках «хороший» — ну так и вообще непонятно зачем он нам…
Но алгоритмы — это как раз "толстый" фильтр. "Популярных" алгоритмов довольно ограниченное количество, и их все можно просто выучить.
Вы однобоко рассматриваете ситуацию. Да, условному гуглу нужны толковые разработчики, которых среди соискателей мало. Но помимо этого им еще надо не нанимать войти-вайтишников, которые программировать-то толком не умеют, зато могут показать условный код с гитхаба и часами рассказывать, какие клевые задачи у них были на прошлой работе (полностью решенные их коллегами). Найм такого работника стоит гуглу гораздо больше чем лишний месяц без разработчика, потому что он был отсеян по ошибке.
ну так не трахай мозг. Первый фильтр — английский язык и чтоб не воняло от соискателя, второй фильтр — как работает hashMap, третий фильтр как работает classLoader и gc, потом уже идут в зависимости от специализации базы данных, алгоритмы или еще чо-нить. А они сразу юзают хорошего спеца, чтоб тестить всякое дерьмо про алгоритмам.
Первый фильтр — английский язык и чтоб не воняло от соискателяАнглийский язык вообще автоматом проверяется, так как на нём интервью проходит. А чтобы узнать — воняло от кандидата или нет… с ним, как минимум, нужно живьём встертится, что дорого и сложно.
второй фильтр — как работает hashMap, третий фильтр как работает classLoader и gc,Вы берётесь объяснить девочке-рекрутеру, как задавать про это вопросы так, чтобы человек, готовый «часами рассказывать, какие клевые задачи у них были на прошлой работе (полностью решенные их коллегами)» — не проскочил? Нам это сделать, извините, не удалось.
А они сразу юзают хорошего спеца, чтоб тестить всякое дерьмо про алгоритмам.Ну дык хороший спец всё равно нужен, а оценивать ответы на задачки про алгоритмы — гораздо проще.
НУ и логично, если у вас золота мало на тонну грунта, то не стоит ставить на входе микросито, которое откинет 99% золота?Если у нас достаточно много грунта и фильтр откидывает ещё и 99.99% руды — то нормально. Так как он всё равно повышает содержание золота в 100 раз.
То же самое и с наймом.
И да я пониманию, что среди них много «брака», но это все равно нелогично вышвыривать всех кто не может написать квиксорт на бумажке без ошибок, верно?Почему нелогично? Их хороших кандидатов квиксорт сможет написать явно не 1%. А вот из плохих — не сможет его написать никто (понятно что может зазубрить, но подобных задачек много, всегда можно найти такую, которую кандидат наизусть не помнит).
Так что это как раз такой фильтр, который повышает содержание золота в породе.
PS Если вы крупнейшая технологичная компания, что ж у вас код такое гавно, что там только сеньоры разобраться могут?А кто вам сказал, что могут разобратья только сеньоры? Студенты тоже могут. И разбираются, когда интернами работают. Но, знаете ли, мы нанимаем людей, чтобы они код не читали, а писали. А это — совсем другое дело. Один придурок может столько дерьма накостылять, что потом потребуется десять сеньоров, чтобы за ним этот код чистить… а оно нам надо?
P.S. Почему студенты ничего не могут напортачить? А потому что у каждого из них есть «host» — человек, который обязан следить за тем, чтобы это не происходило. Иногда код правится студентом «до готовности», иногда host принимает код «как есть» и немного его «рихтует» — это не регламентировано. Но отвечает за качество кода не студент, а его «host». А у обычных программистов «host»а нет, они всё сами должны делать…
UFO just landed and posted this here
Чем проще собеседование и чем душевнее подход, тем больше шанс, что я захочу работать в этой компании.
Не раскрыта тема приятности в общении. Человек может ответить на все вопросы и прорешать все задачки, но вот предложения ему не дождаться, потому что запах изо рта, в общении тяжёлый, плохо реагирует на критику (а как тогда его код ревьюить), стесняется критиковать сам (а как тогда он джунов будет учить), а ему ещё в джире надо в тикетах отписывать и на митингах что-то предлагать, и вообще, не хочу я его видеть по 8 часов в офисе рядом с собой.
Если эту тему в посте задевают — тут же приходят легионы тех самых людей и начинают орать в коментах и лепить всем минусы. Вообще топики про собеседования на хабре — это такая специальная олимпиада, где все воюют против всех. Так как у каждого, наверное, есть какой-то негативный опыт и душевные травмы от собеседований (причем с обеих сторон баррикад, рекрутеры и собеседующие страдают от процесса не меньше)
Есть книга «Cracking the Coding Interview» или «Карьера программиста» на Рус.
Так вот в ней целых 2-3 страницы автор отвечает на вопрос — процесс собеседования, почему так? Кому интересно посмотрите.
Так вот в ней целых 2-3 страницы автор отвечает на вопрос — процесс собеседования, почему так? Кому интересно посмотрите.
Всегда с интересом читаю о всяких тестах, задачах и т.д.
На данный момент я проработал на 3 фирмы (в Германии), на две разрабом, и на одну (сейчас) разрабо-девопс-архитект. Все компании «маленькие», 30-60 человек.
Интервью проходило как-то так:
1. На первую работу, юниором взяли ещё без диплома — экзамен предстоял через несколько месяцев, резюме было с глав. директором, зав по ИТ отделу и Проджект Мэнэджер — после стандартных вопросов о понимании JSON, HTTP, PHP и т.д. и прощупыванием моих качеств по умению учится и т.д., мы расстались, а затем чере пару часов получил договор на мыло…
2. На второй, я продовал себя как мог, ибо рост зарплаты на 25% нужно как-то выбивать (думал я). Однако дальше вопроса, а точнее рассказа о проделанных работ/проектов и пару общих вопросов, знаю ли я jQuery, JSON, HTTP, PHP — также получил контракт на мыло через пару дней.
3. Пришёл, рассказал АЙТИ-Лиду и Проджект М. что делал, что умею, указал на ошибки и сказал как их можно избежать/исправить, покачал головой на это и на то…
Позвали ещё раз, где были только HR и Глав. Директор/хозяин, попили кофе, поговорили о целях и пожали руки, на след. день договор на мыло прилетел.
Тенденция такая, что с опытом и шаганием по лестнице, становится проще себя продать (знаешь то больше), но блин, боюсь я этого момента, если мне при след. резюме тест на какое-нибудь дерево или баблсорт подкинут — я сломаюсь.
На данный момент я проработал на 3 фирмы (в Германии), на две разрабом, и на одну (сейчас) разрабо-девопс-архитект. Все компании «маленькие», 30-60 человек.
Интервью проходило как-то так:
1. На первую работу, юниором взяли ещё без диплома — экзамен предстоял через несколько месяцев, резюме было с глав. директором, зав по ИТ отделу и Проджект Мэнэджер — после стандартных вопросов о понимании JSON, HTTP, PHP и т.д. и прощупыванием моих качеств по умению учится и т.д., мы расстались, а затем чере пару часов получил договор на мыло…
2. На второй, я продовал себя как мог, ибо рост зарплаты на 25% нужно как-то выбивать (думал я). Однако дальше вопроса, а точнее рассказа о проделанных работ/проектов и пару общих вопросов, знаю ли я jQuery, JSON, HTTP, PHP — также получил контракт на мыло через пару дней.
3. Пришёл, рассказал АЙТИ-Лиду и Проджект М. что делал, что умею, указал на ошибки и сказал как их можно избежать/исправить, покачал головой на это и на то…
Позвали ещё раз, где были только HR и Глав. Директор/хозяин, попили кофе, поговорили о целях и пожали руки, на след. день договор на мыло прилетел.
Тенденция такая, что с опытом и шаганием по лестнице, становится проще себя продать (знаешь то больше), но блин, боюсь я этого момента, если мне при след. резюме тест на какое-нибудь дерево или баблсорт подкинут — я сломаюсь.
Тенденция такая, что с опытом и шаганием по лестнице, становится проще себя продать (знаешь то больше), но блин, боюсь я этого момента, если мне при след. резюме тест на какое-нибудь дерево или баблсорт подкинут — я сломаюсь.
Вот именно. Я могу рассказать про различные подходы обмена данными между процессами (от тривиальной многопоточки до гетерогенных распределенных систем), сейчас могу рассказать про некоторые аспекты эффективного кода под AS/400 (с учетом особенности работы групп активации, ресурсоемкости работы с USRSPC по сравнению с DTAARA) и т.п… Но вот тот же баблосорт реально не вспомню на память :-)
UFO just landed and posted this here
Проблема в том что собеседования где спрашивают много теории заточены на студентов, которые мечтаю попасть в «крутую компанию» типо ЯндексаПроблема собеседования в том, что рукрутеры получают бонус за то, что привлекли крутых сеньоров, а на самом деле, в большинстве случаев, вчерашних выпускников (но хороших выпускников) — более, чем достаточно.
Нет, если вы человек с именем и можете привести с собой команду в 100 человек… то вы же и не будете обычное собеседование, скорее всего, проходить — всё будет проходить в совсем другом месте и на совсем других условиях.
Это компании ищут этих специалистов. И пытаются предложить такие условия что бы переманить к себе.Условия предлагаются для того, чтобы люди не уходили, как бы. А не для того, чтобы кого-то переманить. Заниматься переманиванием, предлагая всё больше плюшек — довольно дурацкое занятие, на самом деле. Будут расти расходы, а качество результата — вряд ли.
И когда ты нужен работодателю больше чем он тебе, подобное полоскание мозга вызывает раздражение.То что вы нужны конкретному рекрутеру для получения бонуса — вовсе не значит, что вы нужны компании. Поверьте: если бы вы были нужны работодателю больше, чем он вам — вас бы собеседовали совсем по другому.
Это вообще самая большая ошибка всех, кто куда-либо устраиваться пробовал: они считают, что если рекрутер «телефоны обрывает» — то вы очень нужны компании. Нет — это просто значит, что за вашу голову условный Google может выдать рекрутеру условные $1000, а конторая «Рога и Копыта» больше, чем на условные $100 не расщедрилась.
При этом как раз конторе «Рога и Копыта» вы нужны позарез, а Google и без вас обойдётся… но рекрутер ведь не враг сам себе, ведь правда? $1000 это же гораздо больше, чем $100!
UFO just landed and posted this here
Вот вам и ответ на вопрос «откуда берется только глючного тормозного софта, жрущего ресурсы как не в себя».
Один вчерашний студент почитал пару страниц stackoverflow и написал некий «продукт». Протестировал его в стиле «вроде сразу не упало — значит работает»
Другой вчерашний студент почитал пару страниц stackoverflow и настроил прод так что «вроде не падает».
Юниттесты? Не, не слышали — зачем это надо, оно и так работает, мамой клянусь!
Оптимизация? Да нафига время тратить — оно и так работает.
Нагрузочное тестирование? А что это такое? А зачем? Походу само понятно станет.
Один вчерашний студент почитал пару страниц stackoverflow и написал некий «продукт». Протестировал его в стиле «вроде сразу не упало — значит работает»
Другой вчерашний студент почитал пару страниц stackoverflow и настроил прод так что «вроде не падает».
Юниттесты? Не, не слышали — зачем это надо, оно и так работает, мамой клянусь!
Оптимизация? Да нафига время тратить — оно и так работает.
Нагрузочное тестирование? А что это такое? А зачем? Походу само понятно станет.
А бывает еще так что:
— А запилите-ка ребята мне вот эту фичу, которую по хорошему надо месяц делать, за неделю, так-то оно уже вчера надо было, но хотя-бы так…
…
— Оптимизация? Тестирование? Да бросьте страдать ерундой, давайте быстрее в прод!!! Потом оптимизируете и потестите!
…
— Что? Залили? Отлично! Тут есть еще одна задачка, которую по хорошему полгода надо пилить, но у вас три недели на всё про всё!..
— А запилите-ка ребята мне вот эту фичу, которую по хорошему надо месяц делать, за неделю, так-то оно уже вчера надо было, но хотя-бы так…
…
— Оптимизация? Тестирование? Да бросьте страдать ерундой, давайте быстрее в прод!!! Потом оптимизируете и потестите!
…
— Что? Залили? Отлично! Тут есть еще одна задачка, которую по хорошему полгода надо пилить, но у вас три недели на всё про всё!..
UFO just landed and posted this here
Один ответ на оба коммента.
Ситуации бывают разные. Одно дело, когда развлекательный сайт тормозит — ну тормозит и бог с ним по большому счету
А вот когда встает некое производство т.к. в системе уравления компоненты начинают по таймауту отваливаться из-за неоптимального в каком-то месте кода или у банка в период пиковой нагрузки из-за одного неоптимального модуля на несколько часов встает процессинг пластика по всей стране — это уже совсем другое дело. Тут уже бизнесу по карману бьет.
По большому счету опыт разработчика в том и есть, чтобы понимать, какой кусок кода можно сделать побыстрее, но чтобы работало, а какой надо вылизать до блеска котовых причиндалов чтобы не просто работало, но работало максимально быстро.
Ситуации бывают разные. Одно дело, когда развлекательный сайт тормозит — ну тормозит и бог с ним по большому счету
А вот когда встает некое производство т.к. в системе уравления компоненты начинают по таймауту отваливаться из-за неоптимального в каком-то месте кода или у банка в период пиковой нагрузки из-за одного неоптимального модуля на несколько часов встает процессинг пластика по всей стране — это уже совсем другое дело. Тут уже бизнесу по карману бьет.
По большому счету опыт разработчика в том и есть, чтобы понимать, какой кусок кода можно сделать побыстрее, но чтобы работало, а какой надо вылизать до блеска котовых причиндалов чтобы не просто работало, но работало максимально быстро.
UFO just landed and posted this here
Работаю в финтехе. Можете мне не рассказывать про надежность процессинга, он слезы вызывает. По факту всем пофиг. Главное платежи не потерять, а пройдут на 20 минут позже, да и черт с ним.
Ну не знаю… У нас с этим сильно строго. И по надежности и по нагрузке.
Загрузка серверов мониторится постоянно, регулярно аудиты проводятся по потреблению ресурсов. Те задачи, что крутятся в фоне постоянно без нагрузочного тестирования вообще в бой не уходят.
И в промавтоматизации (точнее, близкой к ней области — система мониторинга инженерного оборудования заданий) работал долго. Там тоже все жестко было и по надежности и по таймингам. И все очень просто — плилетела посылка — не успел в таймаут уложиться — все, удаленная сторона считает что ты не получил. Идет перепосылка. После трех перепосылок считается что ты умер, разрыв сессии, реконнект и опять все сначала. Поставить систему колом можно на раз-два просто неоптимальным кодом.
А плохо работающую систему никто не купит, пойдут к конкурентам.
Вон, недавно кое-какой банк переходил на свежую версию oracle database и не запустили регресс-тесты (все тестеры поразбежались, мвахаха) — процессинг почти всё воскресенье лежал — ичо, думаете, много ушло в другие банки?
Тут вопрос не сколько ушло, а сколько не пришло. Хотя, если банк имеет преференции в виде принудительного загона всех бюджетников на зарплатные проекты, то им, конечно, можно особо не дергаться.
Или когда через него в обязательном порядке всякие госзаказы идут.
А если банк работает сам и сам зарабатывает (ну насколько это возможно в наших условиях), то ему приходится заботиться о том, чтобы все работало.
Ну вот из последнего…
От нагрузочного тестирования прилетело
А дальше началось…
Ну и так далее… «Подрядчик» — ваш покорный слуга. По факту внутри два SQL запроса. Оба содержат WHERE VAR IN (<список значений>). Такие запросы внутри RPG (точнее, SQLRPG — тот же RPG, но с возможностью внутри использовать SQL напрямую) программ не параметризируются (в отличии от запросов типа WHERE VAR =? которые можно один раз подготовить (prepare), а потом многократно открывать OPEN… USING :var с разными параметрами.
В результате все переписано на «нативный» RPG c использованием функций чтения по логическому файлу (индексу).
Сложность только в том, что один запрос простой, просто с JOIN, а второй содержит GROUP BY… HAVING COUNT(*) = MAX(CNT) — вот тут пришлось еще индексированный список (сортированный список с поиском по ключу) подтянуть. Но в результате на тестовом юните старая версия работала 21мсек, новая — 7мсек. Сейчас ждем результаты нагрузочного теста — что они скажут, пропустят или нет…
Это лишь один пример, из последнего. И он сильно не единичный, такое сплошь и рядом у нас. После очередного (ежегодного) аудита на производительность составляется длинный список задач на оптимизацию с замечаниями что не устраивает.
Или когда через него в обязательном порядке всякие госзаказы идут.
А если банк работает сам и сам зарабатывает (ну насколько это возможно в наших условиях), то ему приходится заботиться о том, чтобы все работало.
Ну вот из последнего…
От нагрузочного тестирования прилетело
Из PEX статистики видно, что 33% времени и 36% ресурсов CPU тратится на выполнение QSQRPARS, т.е. парсинг статических выражений при подготовке SQL запроса,
Сократить данные русурсозатраты практически до нуля можно путем описания параметров sql запросов через SQL Descriptor Area (SQLDA).
Поскольку это один из наиболее активно используемых сервис модулей, необоснованное повышенное ресурсопотребление является малодопустимым. Просьба инициировать доработку.
А дальше началось…
необходимо, что-то решать в срочном порядке, т.к. до выявления данного дефекта, информация была о том, что доработка будет установлена на бой до нового года. В свою очередь для бизнеса мы стали отдавать требования по продуктам с учетом данной доработки и многие уже перешли, это может вылиться в негатив на стороне клиентов и бизнеса (прецеденты уже есть).
срочность и критичность доработки обозначена подрядчику?? на недели только планы… прогнозно можно понять сроки самого устранения дефектов??
Ну и так далее… «Подрядчик» — ваш покорный слуга. По факту внутри два SQL запроса. Оба содержат WHERE VAR IN (<список значений>). Такие запросы внутри RPG (точнее, SQLRPG — тот же RPG, но с возможностью внутри использовать SQL напрямую) программ не параметризируются (в отличии от запросов типа WHERE VAR =? которые можно один раз подготовить (prepare), а потом многократно открывать OPEN… USING :var с разными параметрами.
В результате все переписано на «нативный» RPG c использованием функций чтения по логическому файлу (индексу).
Сложность только в том, что один запрос простой, просто с JOIN, а второй содержит GROUP BY… HAVING COUNT(*) = MAX(CNT) — вот тут пришлось еще индексированный список (сортированный список с поиском по ключу) подтянуть. Но в результате на тестовом юните старая версия работала 21мсек, новая — 7мсек. Сейчас ждем результаты нагрузочного теста — что они скажут, пропустят или нет…
Это лишь один пример, из последнего. И он сильно не единичный, такое сплошь и рядом у нас. После очередного (ежегодного) аудита на производительность составляется длинный список задач на оптимизацию с замечаниями что не устраивает.
Там был не с производительностью и нагрузкой затык, а просто сломалась интеграция — недотестили, ибо тестеры разбежались, а свежие ещё не поняли, что и где нужно внимательно смотреть.
Или не успели — ежедневно могло быть до 7 совещаний, на которых обязательно личное присутствие, даже если будет обсуждаться количество гвоздик на подарок кому-то.
PS не проще ли в запросах с большим количеством параметров в var in () делать временную таблицу с этими var /sha1(var) и фильровать с помощью inner join на эту таблицу вместо var in?
Или не успели — ежедневно могло быть до 7 совещаний, на которых обязательно личное присутствие, даже если будет обсуждаться количество гвоздик на подарок кому-то.
PS не проще ли в запросах с большим количеством параметров в var in () делать временную таблицу с этими var /sha1(var) и фильровать с помощью inner join на эту таблицу вместо var in?
Тут с производительностью есть особенности чисто AS/400. Там есть понятие «группа активации». Например, в рамках одной задачи (JOB) некая программа вызывается несколько раз. В первый раз для нее создается группа активации (можно ими управлять — наследовать от вызывающей программы, всегда создавать новую, создавать, если еще не создана, именованую под конкретную программу и т.п.)
Фактически группа активации есть некий контейнер внутри задачи, в котором сохраняются все статические и глобальные переменные. Т.е. при первом вызове программы они проинициализаируются, а при втором (если группа активации не была принудительно закртыта) они будут иметь те значения, что остались от предыдущего вызова.
Посему, у каждой программы всегда есть кусок кода, который вызывается только один раз, при создании группы активации. Туда вынгосятся (по возможности) всякие «тяжелые» процедуры, которые можно не делать каждый раз. Если рассмотреть наш вариант с SQL запросом
где var — переменный параметр, определяемый при каждом запуске.
В SQLRPG это делается так:
тут var — переменная, содержащая параметр для поиска, fld1 и fld2 — переменные в которые получаем результат из очередной строки выборки.
Так вот. В данном случае exec SQL prepare и exec SQL declare выносятся в тот блок кода, который вызывается один раз при создании группы активации. А в той части кода, что вызывается при каждом запуске программы остается только open с текущим значением параметра, fetch и close.
Но. Беда в том, что с массивом переменных это не работает. Т.е. в случае с
конструкция
не пройдет.
и приходится при каждом вызове перестраивать запрос:
Именно это и вызвало возражения со стороны сопровождения — вызов prepare/declare при каждом вызове программы. Причем, той, которая вызывается очень часто (она входит в комплекс проверок клиента)
Т.е. дело не в таблицах, а в невозможности правильного создания динамического параметризированного запроса.
А «нативный» RPG имеет набор функций поиска-чтения-записи-изменения-удаления. В данном случае он работает безо всяких подготовок, просто с разбега фигачит по индексу, а дальше только разгребай результаты.
Хотя в общем случае считается так — если нужно найти одну запись в таблице по индексированным полям, то быстрее использовать нативный chain (чтение записи по значению ключа), а если множественная выборка — использовать SQL. Но бывают и исключения…
Фактически группа активации есть некий контейнер внутри задачи, в котором сохраняются все статические и глобальные переменные. Т.е. при первом вызове программы они проинициализаируются, а при втором (если группа активации не была принудительно закртыта) они будут иметь те значения, что остались от предыдущего вызова.
Посему, у каждой программы всегда есть кусок кода, который вызывается только один раз, при создании группы активации. Туда вынгосятся (по возможности) всякие «тяжелые» процедуры, которые можно не делать каждый раз. Если рассмотреть наш вариант с SQL запросом
select FIELD1, FIELD2 from TABLE where FIELD3 = varгде var — переменный параметр, определяемый при каждом запуске.
В SQLRPG это делается так:
strSQL = 'select FIELD1, FIELD2 from TABLE where FIELD3 =?';
exec SQL prepare stmtSQL from :strSQL;
exec SQL declare curSQL cursor for stmtSQL;
exec SQL open curSQL using :var;
exec SQL fetch next from curSQL into :fld1, :fld2
exec SQL close curSQL;тут var — переменная, содержащая параметр для поиска, fld1 и fld2 — переменные в которые получаем результат из очередной строки выборки.
Так вот. В данном случае exec SQL prepare и exec SQL declare выносятся в тот блок кода, который вызывается один раз при создании группы активации. А в той части кода, что вызывается при каждом запуске программы остается только open с текущим значением параметра, fetch и close.
Но. Беда в том, что с массивом переменных это не работает. Т.е. в случае с
select FIELD1, FIELD2 from TABLE where FIELD3 int ('val1', 'val2', 'val3',...)конструкция
select FIELD1, FIELD2 from TABLE where FIELD3 int (?)не пройдет.
и приходится при каждом вызове перестраивать запрос:
strSQL = 'select FIELD1, FIELD2 from TABLE where FIELD3 in (' + varlist + ')';
exec SQL prepare stmtSQL from :strSQL;
exec SQL declare curSQL cursor for stmtSQL;
exec SQL open curSQL;
exec SQL fetch next from curSQL into :fld1, :fld2
exec SQL close curSQL;Именно это и вызвало возражения со стороны сопровождения — вызов prepare/declare при каждом вызове программы. Причем, той, которая вызывается очень часто (она входит в комплекс проверок клиента)
Т.е. дело не в таблицах, а в невозможности правильного создания динамического параметризированного запроса.
А «нативный» RPG имеет набор функций поиска-чтения-записи-изменения-удаления. В данном случае он работает безо всяких подготовок, просто с разбега фигачит по индексу, а дальше только разгребай результаты.
Хотя в общем случае считается так — если нужно найти одну запись в таблице по индексированным полям, то быстрее использовать нативный chain (чтение записи по значению ключа), а если множественная выборка — использовать SQL. Но бывают и исключения…
То есть курсоры, обычно — один из самых медленных инструментов SQL — в AS используется как стандартный вариант при выборках?
Любопытная архитектура.
Любопытная архитектура.
ну вообще здесь речь идет о SQLRPG — туда возможно засунуть любой SQL запрос.
Ну и никто не заставляет использовать именно SQL. Повторюсь — есть «нативные» функции для доступа к данным. Там вообще хитрая история (описана одним из «отцов-основателей» AS-ки Френком Солтисом в книга «Основы AS/400» — книга сама по себе занимательная т.к. там от истории эволюции System/3 — System/36 -System/38 — AS/400 до описания ее внутреннего мира, что как устроено и как работает) — было две команды, работающие над DB2/400. Одна разрабатывала концепцию DDS (Data Defenition Specifications) — язык описания данных, позволяющий достаточно единообразно описывать физические файлы (хранилища), логические файлы (способы доступа к хранилищам), дисплейные файлы (экранные формы) и принтерные файлы (формы для вывода на печать). Эта команда разработала т.н. «нативный» интерфейс позволяющий получать доступ к данным посредством функций типа read write update delete (в RPG несколько усеченный вариант, полный вариант содержится в RECIO — специфическое расширение C RTL для AS/400 — www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/rtref/recioh.htm)
Вторая команда работала над SQL/DB2.
И о чем-то они не договорились. В результате сделали и то и это.
В каких-то случаях удобнее пользоваться SQL, в каких-то нативом, хотя там чтобы написать простенький запрос с парой join'ов, конечно, приходится написать прилично кода.
В ряде случаев натив оказывается быстрее и менее ресурсоемким, в каких-то наоборот.
В том случае, что описываю я, старое решение (на SQL, не прошедшее нагрузку) отрабатывало на тестовом юните за 21мс. А написанное мной нативное решение (хотя и более длинное по коду) там же и на тех же данных — 7мс.
Сейчас вот ждем что нагрузочники скажут. Сам не имею доступа к PEX (инструмент, позволяющий анализировать загрузку процессора).
Ну и никто не заставляет использовать именно SQL. Повторюсь — есть «нативные» функции для доступа к данным. Там вообще хитрая история (описана одним из «отцов-основателей» AS-ки Френком Солтисом в книга «Основы AS/400» — книга сама по себе занимательная т.к. там от истории эволюции System/3 — System/36 -System/38 — AS/400 до описания ее внутреннего мира, что как устроено и как работает) — было две команды, работающие над DB2/400. Одна разрабатывала концепцию DDS (Data Defenition Specifications) — язык описания данных, позволяющий достаточно единообразно описывать физические файлы (хранилища), логические файлы (способы доступа к хранилищам), дисплейные файлы (экранные формы) и принтерные файлы (формы для вывода на печать). Эта команда разработала т.н. «нативный» интерфейс позволяющий получать доступ к данным посредством функций типа read write update delete (в RPG несколько усеченный вариант, полный вариант содержится в RECIO — специфическое расширение C RTL для AS/400 — www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/rtref/recioh.htm)
Вторая команда работала над SQL/DB2.
И о чем-то они не договорились. В результате сделали и то и это.
В каких-то случаях удобнее пользоваться SQL, в каких-то нативом, хотя там чтобы написать простенький запрос с парой join'ов, конечно, приходится написать прилично кода.
В ряде случаев натив оказывается быстрее и менее ресурсоемким, в каких-то наоборот.
В том случае, что описываю я, старое решение (на SQL, не прошедшее нагрузку) отрабатывало на тестовом юните за 21мс. А написанное мной нативное решение (хотя и более длинное по коду) там же и на тех же данных — 7мс.
Сейчас вот ждем что нагрузочники скажут. Сам не имею доступа к PEX (инструмент, позволяющий анализировать загрузку процессора).
Есть много причин почему так.Это так кажется. В 90% случаях (если не в 99%) причина одна — менеджменту нужна «движуха», чтобы оправдывать свои бонусы.
Достаточно сказать что половина если не больше софта для CI/CD и т.д. который на всех конференциях облизывают и все тащат в прод все ещё в бета версиях зачастую)Понятие alfa, beta и прочее имели смысл, когда продукт нужно было распростналять на физических носителях и выпуск обновлений влетал в копеечку. Сегодня, когда релиз зачастую глючит не меньше, чем beta, но это никако не волнует, потому что всегда ж можно horfix выпустить… это просто ярлыки.
UFO just landed and posted this here
Вот сейчас фейсбук ужасен и все это знают. Но никому не нужен хороший аналог фейсбука, ибо все уже сидят в нем.А теперь сходите в Википедию и почитайте — когда был основал MySpace и когда — Facebook.
1) ты должен быть на ранке первым. Второй а тем более 3 и 4 уже никому не интересен, рынок к тому моменту будет занят и лезть туда бесполезно.И потому сейчас все пользуются для поиска AltaVista и Excite, редактируют текст в WordStar и WordPerfect, а бухгалетра считают зарплату в VisiCalc… ой, не так? Всё-таки пользуются даже не вторым, а 3-4м? А почему так?
Инвесторам же не интересно что у тебя штат программистов там оптимизирует сортировку что бы на 0.5 секунд быстрее все работало пол года. Им нужен продукт который можно увидеть и который будет уже продвигаться на рынке.Не нужен им продукт. Им хайп нужен. Чтобы на IPO выйти и денег срубить. Да — есть такое дело. Только даже им не нужна «движуха», когды вы что-то делаете за три дня, а не за месяц. Инвесторы с такими временными промежутками не работают.
Разработка 2 года условно стоит 2 миллиона, 5 лет условно стоит 5 миллионов. Узнать же навярника стрельнет твой продукт или нет. Можно только выпустив его на рынок. Никто не захочет вложить 5 лямов что бы узнать что вы сделали никому не нужную фигню. Пусть и идеально. Предпочитают пальнуть за 2 и посмотреть есть или нет спрос.Вот как раз если вы будете всё переворачивать с ног на голову каждые 2-3 дня — у вас и будет разработка длиться 5 лет. И получите вы в результате глючное дерьмо.
Вот кстати ещё один «никому не нужный продукт номер 3»: Chrome. И вышел на рынок позже всех (после Netscape, MS IE, и
IT мир и рынок быстро меняется. Лет 10-20 назад все пилили на монолит. Сейчас все пилят на микросервисы. Изменилось архитектура и т.д. Постоянно нужно дорабатывать.Ну это уже движуха ради двужухи. Что вам и почему нужно «постоянно дорабатывать»? Вот прям так, что вы не можете план составить на полгода-год, а нужно всё в авральном порядке кромсать?
Зачастую куда актуальнее, через 10 лет накопив критическую массу костылей выкинуть все что было написано до этого и сделать что то на более современных средствах.До-до-до. Вы много вообще таких примеров знаете? Назовите парочку, хотя бы. На каждый случай, когда этот «финт ушами» проходил приходятся десятки случаев, когда в момент, когда вы, наконец, решаете переписать всё «по феншую» — вас обходят конкуренты и вы либо становитесь номером два, либо вообще становитесь никем.
На эту тему есть много разных статей, самая разумная — пожалуй вот эта: иногда вы можете развивать новую версию как отдельный, успешный проект, который, через много лет, заменяет старый (классический пример — это переход от MS DOS к Windows NT через Windows 3.1, Windows 95 и вот это вот всё), но это — крайне сложное (и затратное мероприятие).
Попытка «срезать круг» и всё сделать в один шаг — приводит к катастроф (см. Windows Phone), а сделать всё правильно вам не дадут всё те же самые менеджеры, которым нужно показывать «движуху».
Чем тащить легси и искать программистов на условном делфи на рынке которые будут его поддерживать и дорабатывать.Вот как раз Delphi, Visual Basic и многие другие от этого феномена пострадали очень сильно. У них была развитая экосистема, но они попытались «сделать что то на более современных средствах». Результат — фактически полная катастрофа. Visual Basic .NET начал понемногу набирать популярность в последнее время — но для этого потребовалось в него вливать ресурсы больше десяти лет (то же самое с Firefox — компания, в результате, таки умерла, хотя браузер выжил).
Время жизни твоего продукта как концепта может просто составить всего несколько лет в IT. Потом кто то придумает что то более интересное и твоя компаний просто закроется.А это — точно про «эффективных манагеров». Какая разница, что будет с компанией, с который вы уже все деньги выжали, «эффективность» показали и ушли в другую?
Нужно просто понимать что по итогу наверное где то 80% всех продуктов на фиг не кому не нужны.Я бы даже сказал 99% (если включить сюда не только «коробочные» продкты, но и всё то, что разрабывается для «внутреннего» потребления… а потом тихо выкидывается).
Из ярких примеров куда вкинули тонну бабла, без выхлопа это например гугл плюс.И вот как раз Google Wave, Google Plus, Google Hangouts и прочие продукты Гугла, которые в модном «молодёжном» стиле ежедневной движухи делали — провалились. А какой-нибудь Google Drive, который пилили буквально годами (вышел через пять лет после Dropbox) — вполне себе существует… потому что соотвествует ожиданиям.
Вся эта движуха по одному шаблону развивается: поднять кучу хайпа, получить от начальства бонусы (как вариант — вывести компанию на IPO и свалить), оставить всё вот это расхлёбывать кому-то другому.
Вы много вообще таких примеров знаете? Назовите парочку, хотя бы.
Твиттер, нетфликс, ченджорг, шопифай (наполовину).
И там вот прямо всё выкинули и с нуля написали? Где про это почитать?
Мне всё-таки кажется, что там корабль Тесея был.
Но вообще если кто-то из них действительно «выкинул все что было написано до этого и сделал что то на более современных средствах» — то это круто, действительно круто.
P.S. Я, кстати, сам-то такие примеры знаю. Например Microsoft Multiplan был подобным образом на Excel заменён. Но там было много факторов, это обеспечивавших: переход с DOS на Windows, одновременно с этим — много хайпа вокруг Macintosh (первой версии Excel под Windows не существует) и многое другое. Уже попытка сделать то же самое с Microsoft Word провалилась: разработка затянулась, завершить её всё никак не удавалось… пришлось возвращаться к «кораблю Тесея».
Мне всё-таки кажется, что там корабль Тесея был.
Но вообще если кто-то из них действительно «выкинул все что было написано до этого и сделал что то на более современных средствах» — то это круто, действительно круто.
P.S. Я, кстати, сам-то такие примеры знаю. Например Microsoft Multiplan был подобным образом на Excel заменён. Но там было много факторов, это обеспечивавших: переход с DOS на Windows, одновременно с этим — много хайпа вокруг Macintosh (первой версии Excel под Windows не существует) и многое другое. Уже попытка сделать то же самое с Microsoft Word провалилась: разработка затянулась, завершить её всё никак не удавалось… пришлось возвращаться к «кораблю Тесея».
Твиттер довольно подробно рассказывал, как они с рельсов на скалу переходили, там вряд ли можно что-то было сохранить из существующео кода.
change.org перешли с рельсов на эликсир/финикс, на прошлогодней ElixirConfEU довольно внятный доклад.
Про остальных затрудняюсь вспомнить, откуда дровишки, но я просто слежу за всякими блогами и т. п. и вряд ли это у меня такая аберрация в мозгу приключилась.
А шанс?
Для простоты ситуации.
В Гугле открыта ровно 1 позиция, которая отдана аутсорсинговой компании Айтипиплы.
В местной компании ООО «Биллинговые решения для всех» открыта ровно 1 позиция, которая также отдана той же компании.
А теперь давайте прикинем, с каким шансом рекрутер из Айтипиплы сможет найти человека, который пойдет на собеседование, пройдет все этапы, получит оффер и выйдет на работу. И с каким шансом все тоже самое произойдет если рекрутер из Айтипиплы будет подбирать человека в ООО «Биллинговые решения», которым вот прямщас надо заменить ушедшего, по смешному совпадению, в Гугл ведущего программиста.
Для простоты ситуации.
В Гугле открыта ровно 1 позиция, которая отдана аутсорсинговой компании Айтипиплы.
В местной компании ООО «Биллинговые решения для всех» открыта ровно 1 позиция, которая также отдана той же компании.
А теперь давайте прикинем, с каким шансом рекрутер из Айтипиплы сможет найти человека, который пойдет на собеседование, пройдет все этапы, получит оффер и выйдет на работу. И с каким шансом все тоже самое произойдет если рекрутер из Айтипиплы будет подбирать человека в ООО «Биллинговые решения», которым вот прямщас надо заменить ушедшего, по смешному совпадению, в Гугл ведущего программиста.
Знаете, если бы HR умели в логику, то они бы писали программы (и зарабатывали бы куда больше денег), а не обрывали бы вам телефоны.
А так-то да, всё верно — Гугла именно потому и платит больше за вакансию, что закрыть её труднее.
А так-то да, всё верно — Гугла именно потому и платит больше за вакансию, что закрыть её труднее.
Они, похоже, это просекли, и таки начали «писать программы»… Вот, из недавнего: AI «просматривает» по миллиону интервью за 90 дней, и, по сути, принимает решение, брать ли вас на работу
Про это даже xkcd нарисовано.
Недавно проходил тех резюме в Aliexpress на позицию разработчика, думал буду общаться с китайцем и будет очень "больно" в плане понимания китайско-английского)), в итоге общался с русским парнем, но интервью все тех вопросы были на английском (политика компании), после уже перешли на русский.
В общем главное не беспокоится в таких моментах. Всем удачи на интервью.
Офтоп P. S: Кому будет интересно, напишу список вопросов
Хотел бы добавить вариант собеседования в маленькой компании:
Главным вопросом может стать ваш знак зодиака :)
(из личного опыта)
Главным вопросом может стать ваш знак зодиака :)
(из личного опыта)
Автор (несомненно автор), вы слишком (очень-очень) много (часто, а не редко) пишите в скобках (вот таких, даа). Стиль изложения (пишем когда) страдает от этого (ему очень-очень плохо:)) и читать такой (вот такой вот, как этот) текст :) неприятно (неприятно ведь). Особенно когда ещё и смайлики (смешные скобочки) :) вставлены :))
У меня был интересный случай. Проходил собеседование по скайпу. Туда созвали 3х молодых чуваков меня собеседовать. С виду явно разработчики. В резюме соответсвенно указал, то с чем я работал как full stack разработчик с ASP.NET с MSSQL, ну и всякие Angular-ы. С самого начала заметил какую то ненависть в глазах ребят. Начали спрашивать у меня отличие кластерного индекса от не кластерного. У человека который работает с СУБД через различные прослойки типа Hibernate или Entity Framework подобные знания как то нахрен улетучиваются через 8 лет активной работы. Ну я ответил как смог. На что услышал фразу от одного из троих: «Так он XXX тысяч ЗП хочет и не знает что это такое?»
Это кстати тоже да.
И бывает не только с молодыми, которые просто ещё не столкнулись с собственным ростом опыта и забыванием всяких мелочей — но и от вполне опытных людей, которым просто жалко денег. Они смотрят на сумму, их немного начинает придавливать жаба и они принимаются задавать энциклопедические вопросы.
И бывает не только с молодыми, которые просто ещё не столкнулись с собственным ростом опыта и забыванием всяких мелочей — но и от вполне опытных людей, которым просто жалко денег. Они смотрят на сумму, их немного начинает придавливать жаба и они принимаются задавать энциклопедические вопросы.
Вы уж меня, конечно, извините, но если вы вообще работаете с базами данных — то должны понимать чем отличается кластерный индекс от некластерного.
Вот просто должны и всё.
Если вы вдруг не в курсе — я могу попробовать на пальцах объяснить. Предствьте себе, что у вас в базе данных хранятся не письма там или проводки, а внезапно, автомобили. То есть эта база данных — это такая куча гаражей, где стоят траки и легковушки, трактора и самосвалы… всё вперемешку.
Так вот можно — все самосвалы поместить в один гараж, а все легковушки — в другой. Это будет кластерный индекс «тип автомобиля». А можно, наоборот, собрать в одном гараже все авто синего цвета, а в другом — зелёного. Это кластерный индекс «цвет».
Это, собственно, основа вашей базы. Принципиальное решение, меняющее всё. Потому что если у вас кластеризация по типу автомобилей, то собрать стильную тройку из красного мотоцикла, красного самосвала и красного экскаватора — для вас будет проблемой. А вот зато пару экскаваторов разных цветов — вы «подгоните» легко.
Поскольку речь идёт о том, что мы физически гоняем машины из одного гаража в другой — то мы можем иметь только один кластерный индекс… и если мы его выбрали неверно, то у нас будут-таки проблемы. Зато если мы выбрали его хорошо — то может быть многократная экономия на серверах!
Поскольку у нас всё-таки в базах данных не авто — то в некоторых патологических случаях может оказаться полезным даже иметь две одинаковые базы с разными кластерными индексами. Ну, типа, закупить всех машин в двух экхемплярах — и поставить в один гараж разные экскаваторы, а в другой — всю технику красного цвета. Хотя это и не рекомедуется (если один экскаватор пропал, а другой остался — беда будет).
А вот что andyDufresne ответил на этот вопрос и как именно к нему придираются — сказать без подробностей нельзя. То ли он увяз в объяснениях того до какой степени разные базы готовы «копировать данные по диску», чтобы ускорить работу кластерного индекса, то ли он в принципе не смог объяснить чем кластерный от некластерного отличается… то он вообще всё правильно объяснил, просто использовал вместо слов «кластерный индекс» слова «первичный индекс» (в этом случае это уже точно придирки, так как практически случаев, когда их нужно различать, скорее вы не встретите).
Вот просто должны и всё.
Если вы вдруг не в курсе — я могу попробовать на пальцах объяснить. Предствьте себе, что у вас в базе данных хранятся не письма там или проводки, а внезапно, автомобили. То есть эта база данных — это такая куча гаражей, где стоят траки и легковушки, трактора и самосвалы… всё вперемешку.
Так вот можно — все самосвалы поместить в один гараж, а все легковушки — в другой. Это будет кластерный индекс «тип автомобиля». А можно, наоборот, собрать в одном гараже все авто синего цвета, а в другом — зелёного. Это кластерный индекс «цвет».
Это, собственно, основа вашей базы. Принципиальное решение, меняющее всё. Потому что если у вас кластеризация по типу автомобилей, то собрать стильную тройку из красного мотоцикла, красного самосвала и красного экскаватора — для вас будет проблемой. А вот зато пару экскаваторов разных цветов — вы «подгоните» легко.
Поскольку речь идёт о том, что мы физически гоняем машины из одного гаража в другой — то мы можем иметь только один кластерный индекс… и если мы его выбрали неверно, то у нас будут-таки проблемы. Зато если мы выбрали его хорошо — то может быть многократная экономия на серверах!
Поскольку у нас всё-таки в базах данных не авто — то в некоторых патологических случаях может оказаться полезным даже иметь две одинаковые базы с разными кластерными индексами. Ну, типа, закупить всех машин в двух экхемплярах — и поставить в один гараж разные экскаваторы, а в другой — всю технику красного цвета. Хотя это и не рекомедуется (если один экскаватор пропал, а другой остался — беда будет).
А вот что andyDufresne ответил на этот вопрос и как именно к нему придираются — сказать без подробностей нельзя. То ли он увяз в объяснениях того до какой степени разные базы готовы «копировать данные по диску», чтобы ускорить работу кластерного индекса, то ли он в принципе не смог объяснить чем кластерный от некластерного отличается… то он вообще всё правильно объяснил, просто использовал вместо слов «кластерный индекс» слова «первичный индекс» (в этом случае это уже точно придирки, так как практически случаев, когда их нужно различать, скорее вы не встретите).
Здесь немного другие уровни абстракции. Обычный прикладной программист строит модель данных исходя из бизнес процессов которые эту модель затрагивают. Ему абсолютно монопинесуально, используется ли индексация физическая или вирутальная. Если в БД 10 таблиц. 5 из которых обычные справочники, то знания о том как эти справочники хранятся нужно только задротам. А для построения высоконагруженных БД есть отдельные специалисты, которых DBA зовут. И там модель Code First никто никогда не использует. А по поводу ответа на собеседовании, тогда я сказал, что для меня разница между типами индекса заключается лишь в том, что кластерный работает быстрее, но может быть только один — в общем ответил с практической точки зрения. На тот момент конечно напрочь забыл все определения.
Обычный прикладной программист строит модель данных исходя из бизнес процессов которые эту модель затрагивают.Ну и в этот момент, собственно, и возникает вопрос: а за что платить-то?
А для построения высоконагруженных БД есть отдельные специалисты, которых DBA зовут.Далеко не всякая нагруженная база имаеет такие масштабы и далеко не каждая фирма имеет такой штат, чтобы выделенного DBA содержать. Очень многие хотили бы, чтобы сеньор — тоже мог в такое.
И да, сразу предупреждаю — я, например, не смогу. Последний раз базы оптимизировал много лет назад, почти сразу после универа… так что наверняка делал всё это неправильно и на подобную вакансию даже претендовать не стану.
Но про разницу между кластерным и некластерным до сих пор не забыл…
Ну и в этот момент, собственно, и возникает вопрос: а за что платить-то?
Т.е. если человек создал оптимизированную БД, но при этом уже не помнит почему он так делает, по вашему ему не надо платить? По моему тут просто оценка знаний должна происходить, а не сопоставление этих знаний с запрошенной суммой. Это уже работа не технического интервьювера, а менеджера. Ну по крайней мере я так себе это представляю…
Очень многие хотили бы, чтобы сеньор — тоже мог в такое.
Ну да, все хотят сэкономить, но я то тут причем?
Т.е. если человек создал оптимизированную БД, но при этом уже не помнит почему он так делает, по вашему ему не надо платить?Если он «не помнит почему он так делает», то велик шанс, что в слегка изменившейся остановке база станет не совсем оптимизированной, а то и совсем не оптимизированной. И да — такая работа стоит явно дешевле, чем что-то, что сделал человек, готовый «отвечать за базар».
Это уже работа не технического интервьювера, а менеджера.Менеджер уже высказал всё, что было нужно до начала интервью: если вакансия на определённый набор навыков и определённую сумму открыта — то дальше чловек либо соотвествует ей, либо нет. Иногда открыты несколько вакансий и тогда может быть выбор — на какую из них человек подходит… но из вашего описания ну вот совершенно неясно — была ситуация такой или нет…
Ну да, все хотят сэкономить, но я то тут причем?Ну как бы вы же на эту вакансию пытались устраиваться, не я… если вы предполагали, что схему базы будет разрабатывать DBA, а от вас ожидали, что это сделаете вы… то вы «не сошлись характерами» с вакансией, вот и всё.
Может, стоит лечить где болит и сначала сделать слегка неоптимальную, но рабочую БД, а потом брать в руки профайлер и искать/лечить болевую точку?
Знаю пару компаний, в которых эти точки найдены и задокументированны, и могут ускорить производительность раз в 20.
Но пока лежат в виде документа: менеджмент решил, что сейчас заказчик доволен скоростью — пусть так и будет. А через годик-два база распухнет и заказчик перестанет быть довольным — тогда и стоит выкатывать фикс, всё ускорится и заказчик снова будет счастлив.
Знаю пару компаний, в которых эти точки найдены и задокументированны, и могут ускорить производительность раз в 20.
Но пока лежат в виде документа: менеджмент решил, что сейчас заказчик доволен скоростью — пусть так и будет. А через годик-два база распухнет и заказчик перестанет быть довольным — тогда и стоит выкатывать фикс, всё ускорится и заказчик снова будет счастлив.
Извините, но я даже не знаю чего от вашего рассказа убавить или чего прибавить.
Вы-то сами понимаете, что людей, выращенных в таких компаниях, в местах, в которых нужна работа с базой не для того, чтобы ублажать заказчика и тянуть из него деньги, а чтобы самим как-то использовать — стараются не подпускать в принципе?
Да, это отличная схема. Позволяет тяуть деньги из заказчиков, грубо говоря, вечно. Но если вы это делаете для себя… зачем оно вам?
Вы-то сами понимаете, что людей, выращенных в таких компаниях, в местах, в которых нужна работа с базой не для того, чтобы ублажать заказчика и тянуть из него деньги, а чтобы самим как-то использовать — стараются не подпускать в принципе?
Да, это отличная схема. Позволяет тяуть деньги из заказчиков, грубо говоря, вечно. Но если вы это делаете для себя… зачем оно вам?
Ну и в этот момент, собственно, и возникает вопрос: а за что платить-то?
Как за что? За код.
Ну собственно в этот момент и возникает непонимание. Есть компании, где платят за решения задач. А есть те, где платят за код… и это разные компании.
Рассказ вашего коллеги вот буквально чуть выше — это же прекрасная иллюстрация…
Рассказ вашего коллеги вот буквально чуть выше — это же прекрасная иллюстрация…
Яндекс нельзя сравнивать с Google/Facebook/Amazon в плане интервью, я сейчас в процессе со всеми этими компания. В Я задачки только в начале, потом они хотят конкретных знаний. Все, с кем я общался, очень узкие спецы с очень узким кругозором и ожидают того же. Это куда ближе к ЕПАМ чем к Tier-1 (и даже не Tier-3) компаниям на западе.
Так же в Я мне встретились только 2 типа: или старые хардкорные динозавры с 10+ лет опыта (большую часть в том же Яндексе) или совсем молодые. Видимо все лучшие и активные уехали на запад или нашли лучше варианты в современых и более динамичных компаниях с лучшей компенсацией.
Так же в Я мне встретились только 2 типа: или старые хардкорные динозавры с 10+ лет опыта (большую часть в том же Яндексе) или совсем молодые. Видимо все лучшие и активные уехали на запад или нашли лучше варианты в современых и более динамичных компаниях с лучшей компенсацией.
Видимо все лучшие и активные уехали на запад или нашли лучше варианты в современых и более динамичных компаниях с лучшей компенсацией.а какие сегодня более динамичные?
Так же в Я мне встретились только 2 типа: или старые хардкорные динозавры с 10+ лет опыта (большую часть в том же Яндексе) или совсем молодые. Видимо все лучшие и активные уехали на запад или нашли лучше варианты в современых и более динамичных компаниях с лучшей компенсацией.
«Динозавры» сидят еще со старых времен, когда собеседования, видимо, были более гуманные. А молодые просто привычнее к решению абстрактных, оторванных от реальности задач, они их совсем недавно решали, в школе или в ВУЗе, да и время/желание есть натаскиваться на их решение.
Те что посередине… Вот я недавно активно искал работу, сам себе выделил на это не больше двух-трех недель. Всё это время было заполнено общением с потенциальными работодателями по телефону, по скайпу, по эмейлу, просто в реальной жизни. Времени, сил и желания, надр… ать решение олимпиадок перед одним из многочисленных этапов собеседований в Яндекс у меня не было. Не стоит оно того. Если бы там было как везде — одно техническое собеседование (нормальное, без всей этой олимпиадной дичи в Блокноте) и одно с руководителем, то, возможно, и подумал бы над таким вариантом.
Вот оттого там и получилось такое распределение, ИМХО.
Я не очень уверен, но порой кажется, что те компании, где на собеседованиях упирают на решение олимпиадных задач, в итоге получают соответствующих сотрудников-«олимпиадников». Олимпиадные задачки они решать могут, а вот заниматься коммерческой разработкой (со всей ее рутиной, workflow, нечеткими формулировками FSD, ответственностью не только за «пуговицы», но за всю задачу целиком) у них не очень получается.
Не получается аж настолько, что прибыли у них — куда больше, чем у любых других.
И Яндекс и Google — так-то вполне себе нормально существует, прибыли хорошие, обороты тоже.
Вот если бы они вдруг убытки начали получать — тогда стон про «людей, не могущих заниматься коммерческой разработкой» был бы уместен.
И Яндекс и Google — так-то вполне себе нормально существует, прибыли хорошие, обороты тоже.
Вот если бы они вдруг убытки начали получать — тогда стон про «людей, не могущих заниматься коммерческой разработкой» был бы уместен.
Не уверен, что прибыль в данном случае непрямую связана с качеством разработки. Она от рекламы идет. И тормозной сайт, перегруженный трекерами и рекламой может приносить неплохую прибыль, несмотря на то, что с точки зрения кода там все ниже плинтуса.
И никаких стонов, не стоит на свой счет принимать. Просто давно живу, много видел. В том числе и вундеркиндов, блиставших на олимпиадах, но неспособных в срок и без проблем довести до прома несложную задачу.
И никаких стонов, не стоит на свой счет принимать. Просто давно живу, много видел. В том числе и вундеркиндов, блиставших на олимпиадах, но неспособных в срок и без проблем довести до прома несложную задачу.
Да ещё проще, прибыль там идёт за счёт монополии. «Начальная раскрутка».
Условно говоря, бывает место прибыльное и нет. Если вы поставите ларёк на вокзале, то как бы ни был плох там товар, он будет приносить прибыль.
Так и здесь.
Крупная компания раскручена и за счёт этого живёт и кормится. «Кому заказ давать? Ну вот есть яндекс / майл и т.д.»
Да что уж там говорить, тот же майлру весь свой гешефт поимел ИСКЛЮЧИТЕЛЬНО за счёт доменного имени.
Условно говоря, бывает место прибыльное и нет. Если вы поставите ларёк на вокзале, то как бы ни был плох там товар, он будет приносить прибыль.
Так и здесь.
Крупная компания раскручена и за счёт этого живёт и кормится. «Кому заказ давать? Ну вот есть яндекс / майл и т.д.»
Да что уж там говорить, тот же майлру весь свой гешефт поимел ИСКЛЮЧИТЕЛЬНО за счёт доменного имени.
А давайте не будем про «начальную раскрутку». Потому что есть очень хороший контрпример: смартфоны. Они, так-то, появились четверть века назад.
И когда «вундеркинды» из Apple и Google туда полезли примерно лет десять назад — все над ними смеялись. Ну… допускали, что Apple отберёт процентов 5-7 от грандов, которые «грамотно пилили» Symbian, Windows CE, Maemo (а позже — Bada, Tizen, далее везде). Но чтобы больше? Там двузначные цифры в предсказаниях появились ex post facto… Ну посмотрите хотя бы на предсказания тех лет. И это уже через два года после выхода iPhone и через год после запуска Андроида!
А насчёт имени — то это тоже смешно: есть ведь и mail.com и mail.fr какие-нибудь. Имена у них — вроде не хуже… а пользуется ли ими кто-то?
На самом деле всё просто: вот эта вот структура («старые хардкорные динозавры с 10+ лет опыта» и «молодые вундеркинды») — достаточно оптимальна. Вундеркинды делают меньше технических ошибок, но да, легко могут не разобраться с «нечеткими формулировками FSD, ответственностью не только за «пуговицы», но за всю задачу целиком»… но им это и не нужно. Если в команде — один «динозавр», то его опыта легко хватит.
P.S. Единственное чего «вунеркинды» не могут сделать — «перескочить» через господдержку. Скажет КПК, что iPhone покупать не нужно, а нужно покупать Huawei — значит так и будет. Но тут, как вы понимаете, качество софта уже совсем небольшую роль играет.
И когда «вундеркинды» из Apple и Google туда полезли примерно лет десять назад — все над ними смеялись. Ну… допускали, что Apple отберёт процентов 5-7 от грандов, которые «грамотно пилили» Symbian, Windows CE, Maemo (а позже — Bada, Tizen, далее везде). Но чтобы больше? Там двузначные цифры в предсказаниях появились ex post facto… Ну посмотрите хотя бы на предсказания тех лет. И это уже через два года после выхода iPhone и через год после запуска Андроида!
А насчёт имени — то это тоже смешно: есть ведь и mail.com и mail.fr какие-нибудь. Имена у них — вроде не хуже… а пользуется ли ими кто-то?
На самом деле всё просто: вот эта вот структура («старые хардкорные динозавры с 10+ лет опыта» и «молодые вундеркинды») — достаточно оптимальна. Вундеркинды делают меньше технических ошибок, но да, легко могут не разобраться с «нечеткими формулировками FSD, ответственностью не только за «пуговицы», но за всю задачу целиком»… но им это и не нужно. Если в команде — один «динозавр», то его опыта легко хватит.
P.S. Единственное чего «вунеркинды» не могут сделать — «перескочить» через господдержку. Скажет КПК, что iPhone покупать не нужно, а нужно покупать Huawei — значит так и будет. Но тут, как вы понимаете, качество софта уже совсем небольшую роль играет.
UFO just landed and posted this here
Любая из четырёх, в зависимости от патриотических чувств говорящего.
Объективно Я и близко не стоит с другими компаниями в этом списке. Капитализация 15B против ~1T у ит-гигантов, количество и охват аудитории, технологии. Я был в 3х из 4х этих компаниях и субъективно Я так же совершенно другая лига ;-(
Просто их продукты на слуху для тех, кто живет в РФ и много лет формировался бренд, который засел у вас в головах. Но, по факту, это уровень EPAM, Dropbox, Cloudflare, Yelp (что, конечно, тоже круто).
Просто их продукты на слуху для тех, кто живет в РФ и много лет формировался бренд, который засел у вас в головах. Но, по факту, это уровень EPAM, Dropbox, Cloudflare, Yelp (что, конечно, тоже круто).
UFO just landed and posted this here
цель любой аутсорсной компании — продать ваше время разработчика задорого, а потом забирать себе часть вашей зарплаты (половину). Это основная бизнес модель.
Небольшая поправочка. Заплатить работнику меньше, чем он принес компании — это принцип работы любой компании.
Работникам всегда отдают меньше, чем они принесли компании.
еще один тип:
Собеседование в говнофирму (разработчиков раз два и обчелся)
Количество кандидатов максимум одно резюме в неделю
Тип собеседования комфортная беседа, предложет кофе
Ожидаемые вопросы немного поспрашивают про опыт, совсем чуть-чуть про технологии с которыми работали.
В принципе и тут не плохо, главное, чтоб платили… но застревать на долго не советую. Правда потом надо приготовить обосновательный ответ HR крупных компаний «а почему Вы так часто меняли работу?». За то не надо отвечать на вопрос «А что Вас не устраивало на прежнем месте работы?»
Собеседование в говнофирму (разработчиков раз два и обчелся)
Количество кандидатов максимум одно резюме в неделю
Тип собеседования комфортная беседа, предложет кофе
Ожидаемые вопросы немного поспрашивают про опыт, совсем чуть-чуть про технологии с которыми работали.
В принципе и тут не плохо, главное, чтоб платили… но застревать на долго не советую. Правда потом надо приготовить обосновательный ответ HR крупных компаний «а почему Вы так часто меняли работу?». За то не надо отвечать на вопрос «А что Вас не устраивало на прежнем месте работы?»
Кстати, умение решать алгоритмические задачи тупо показывает что человек решал много алгоритмических задач. Ни больше ни меньше. Пруф от Um_nik, Codeforce Legenderay grandmaster.
Справочник по собеседованиям для тех программистов, которые их не понимают