Вы не поняли, был описан мой опыт, как не грамотные руководители губят процессы внутри компании. Не надо проецировать ваш опыт на мой, и додумывать непонятно что, это был лишь пример. И все описанное мной было ИМХО, что нет токсичности в поведении разработчика, что он что-то хочет улучшить. У людей всегда будут барьеры к новому, и как обычно они были пройдены, но тут не заслуга руководителя, а заслуга времени, некоторым людям нужно время, чтобы понять, осознать, что они что-то не то делают и понять в чем плюсы того или иного решения. Условный пример, вы заказали такси, а вас таксист начинает возить непонятным путем, который вы не знаете и говорит, что так лучше, быстрее, в итоге завозит вас в непонятные дворы, вы начинаете с ним ругаться куда же он вас завез, через пару минут такси выезжает из дворов и проезжает еще чуть-чуть и вы на месте, и понимаете, что таксист был прав, и что вы устроили истерику на ровном месте и не поверили более опытному таксисту. И кстати вы не считаете, что вы себя ведет досточно токсично и даже не даете при этом ответить собеседнику и начали его обвинять? Не это ли токсичное поведение? Где же обратная связь высокого уровня и где грамотный руководитель про которого вы пишете? ))
А вот еще забыл написать. Был в той компании один чудной типок, так вот он каждый день уходил с офиса под предлогом, что его ждет наш клиент для решения проблемы. И еще призрительно говорил, что он давно работает и пусть салаги решают проблемы. По должности был выше его, но он так относился не только ко мне, а так же к другим специалистам выше по должности. Не напоминает вам дедовщину? По факту, у того клиента была сотрудница, которая с утра звонила к нам, и этот типок срывался с работы к ним и ошивался у ней. В ходе корпоративного расследования, почему все так часто ломается у клиента, выяснилось, что у них роман, и никакие проблемы он решает и у клиента проблем нет! Он же был первый на увольнение…
Вы работали когда-нибудь с крупными открытыми проектами типа linux kernel?
В подобных проектах впринципе обычно все жестко. Даже к форматированию придираются. Первый раз делают замечание, просят исправить, не исправляете в адекватный срок, отклоняют пул реквест, или если повезет кто-то перепишет правильно. Сломали коммитом что-то, по головке не погладят… Лично у меня было десятки раз, что даже отклоняли по совсем неадекватным причинам. Не конструктивность codereview решается банально за счет декларации как должен быть оформлен код, что можно делать, а чего нельзя. И в принципе должен быть опытный мейнтейнер.
Должны. Еще как должны. При знании многих языков переход на новый практически моментален, но вот в каждом языке есть свои особенности, которые сильно влияют на производительность кода, и есть unpredictable behavior, которые полезно знать. В принципе их не всегда понимает большое количество разработчиков пишущих на этом языке, но это не значит, что не надо изучать язык.
Так как раз смотрю глобальнее. Разве может быть в ж*пе все хорошо, когда постоянно звонят клиенты на дню и сильно ругаются? Как раз решения многих проблем там были с 0 сложностью и практически нулевыми затратами. И как раз мне там удалось снизить значительно затраты на многие вещи и повысить эффективность. Тут только говорит о руководителе одно, ни что он смотрит чуть выше, а то, что он в принципе не уверен в команде и в своих силах. Руководитель должен быть всегда примером, с которым не страшно пойти в бой, и подбирать команду грамотно, создать условия для работы хороших специалистов, в итоге в офисе никаких удобств, зарплаты не высокие и понаберут незнай кого, а потом удивляются почему все так плохо))
Это вполне естественно. Пассивным людям не дают пассивничить на работе. С нормальными специалистами всегда конструктивный диалог, и они прислушиваются к коллегам. Благо до подобных пассивных компаний, у меня был опыт работы с реальными специалистами с большой буквы, и даже споры с ними всегда проходили в позитивном ключе.
Не согласен с автором, что надо прогибаться. Это не токсичность. Если вы считаете, что правы и это пойдет на пользу, идите до конца. Иначе скатитесь в итоге к пассивной серой массе. Про это есть замечательная книга «Ча́йка по и́мени Джо́натан Ли́вингстон». Выше правильно написал человек «Её снижают токсики. Они же создают настоящие конфликты, плетут заговоры и натурально выживают коллег с работы.». Вам просто не безразлично будущее проекта. Большая часть людей просто не хочет развиваться, и у них профессиональное выгорание, они приходят на работу не с икринкой глазах, развиваться, решать проблемы и получать от этого удовольствие, а просиживать попу и получить за это деньги, написали тяпляп, работает и ладно. В дали от крупных городов довольно сложно найти грамотных программистов, не говоря про знание безовых алгоритмов. Руководитель в статье относится к пассивному типу и впринципе понимает, что найти нормальных разработчиков сложно, поэтому вас просто сделали КОЗЛОМ-ОТПУЩЕНИЯ! И самое главное вам внушили, что вы были не правы. Вы согласились с этим, и все довольны… У меня была подобная ситуация, были так называемые «старички на работе» которые ничего не делали, плюс одни специалисты вечно сваливали проблемы на других, и так бесконечное перекладывание ответственности. Предлагал своему руководителю работать на опережение, добавить мониторинг оборудования и кучу всего полезного, основываясь на опыте прошлой работы, разделить нормально обязательства специалистов, установить сроки решения и ответственных, чтобы не было такого безобразия. Руководитель ничего не делал. Токсичность идет как раз от пассивных людей! В итоге мне это все настолько надоело, что все работает через одно место и на работе саботаж, что пошел непосредственно к директору, благо до этого с ним пересекались по работе, и он заметил меня как специалиста, изложил ему все проблемы и что руководитель ничего не решает, и работает по принципу сломается исправим, что не хочет развивать и улучшать ничего, и если ничего не решится мне придется уйти от них, в итоге директор согласился с моими доводами, бездельников уволили, руководитель получил выговор, коллеги по началу хряхтели и обижались, но уже через пару месяцев решилась большая груда проблем, и количество работы значительно уменьшилось, и в итоге коллеги меня зауважали и начали прислушиваться, а директор мне выписал премию, выдали в грамоту и занесли в трудовую, что получил награду за решением проблем компании. В принципе в нормальных компаниях это все должно было решаться до вас, и должно быть обучение специалистов в корпоративном университете, и должны быть описаны частые проблемы. Но у вас работает принцип какое руководство такие сотрудники… Мне известные случаи, когда такие сотрудники компании топили ко дну, в одной из таких работал, но быстро ушел, понял, что не мое и с этими людьми мне не по пути.
Так это разве мешает C++ развиваться и быстро компилировать? Это только частично упрощает разработку, что принципе нормально для оберточных языков типа Kotlin, где не хотят сильно усложнять язык и сильно вкладываться в разработку, добавить чуть синтаксического сахара, nullsafety и новый язык готов.
Язык в первую очередь должен быть удобен для программирования и не нарушать привычные паттерны, можно сделать совсем радикально и сделать набор кода справа на лево, но это кроме арабов никто не оценит…
1. Preprocessors — Compare CSS processors for parsings, nested rules, mixins, variables and math. Примерно тоже, что 3, но происходит еще разворачивание макросов, миксинов, переменныхи математики, может добавляться большое количество веток дерева, так как некоторые правила разворачиваются в ветки.
2. Просто парсер и постройка AST.
3. Prefixers — Это работа с AST на примере добавления префиксных свойств для браузеров с проверкой по базе совместимости. Т.е. полный пайплайн.
Я такое вижу от всех программистов и в большом количестве языков… Очень низкий уровень подготовки к сожалению у людей. Особенно такое часто на JS во фронтэнде, там программистами могут работать врачи и экономисты, да и программисты не всегда понимают как все это работает…
Согласен с вами на все 100%. Очень сложно объяснить людям, что все проблемы в JAVA и JavaScript и во многих языках, именно из-за безразборного создания объектов, копирования объектов(тут C++ и C, и им подобные с указателями просто выигрывают и программисты хорошо понимают этот процесс, экономят память, в других языках знают про ссылки, но не используют или не до конца понимают) вместо передачи ссылки, работа с текстом очень дорогая, все строковые операции сами по себе очень дорогие, за исключением посимвольного чтения, там от C++ даже разницы в скорости не будет практически, и трансляция практически с 0 оверхедом, но другие операции как раз могут тригерить сборку мусора особенно после циклов, да и сами работают не очень быстро, к примеру в критических участках кода я отказываюсь от regex и replace c regex, и переписываю код на посимвольное чтение и посимвольную работу с текстом, там можно получить ускорения в тысячи раз по сравнению с regex(даже с предкомпиляцией регулярных выражений). Раньше всегда учили, что конкантенация строк в цикле плохо, там создавалась новая копия стрингбуфера, и память утекала, до тех пор пока цикл не завершится, пока код не вышел из контекста, контекст ограничивается фигурными скобками {}, GC не может запустится, в итоге цикл завершается и GC вместо малого количества объектов надо почистить сотни, а то и тысячи объектов, а где-то даже миллионы, такое тоже видел, отсюда к гадалке не ходи будет дикий лаг от GC… Или еще мною любимый антипатер это ресайз масивов…
Так парсинг как раз не проблема, это довольно быстро, медленнее всего работа с AST, оптимизация дерева, к примеру упрощение выражений типа 2+3, и значительно более сложных выражений и конструкций языка, дальше сборка дерева и конвертация в объектные файлы. Те парсеры парсят, строят AST, дальше делают работу с AST, тут уже кому что надо, и потом уже выплевывают измененный css файл, и при желании создают сорсмап. Основное применение это удаление дублирующихся свойств с учетом наследования, проверка на валидность, проверка свойств на совместимость с браузерами, если нет префикса для какого браузера добавляются префиксы и т.д., замена макросов и т.д. Модулями можно написать любой функционал хоть сделать sass и less. Они дают API и строят AST, дальше извращайся как хочешь.
Впринципе да, но только собственный шум в темноте у сенсоров очень высокий. Плюс сама камера дорогая, и сенсоры тоже, для работы с сенсором понадобиться FPGA, если брать чисто сенсоры от камер. Схема значительно сложнее и дороже в реализации.
Вы уверены? Вы знаете кого-то из этих гениальных людей? Мне лично знакомо несколько людей из средних компаний, но там нет HFT и они даже не собираются заниматься HFT… Прична озвучана мной выше и кто разбирается в алго впринципе в большинстве будут солидарны со мной. Когда говорят про HFT и Роботов это имхо разводняк полнейший, чтобы кинуть потом инвесторов и домохозяйк...))
При правильном написании нет таких проблем и не было впринципе, мне лично удавалось значительно ускорить алгоритмы, только засчет уменьшения хранимых данных и переписать алгорим так, чтобы сборка мусора тригерилась меньше и не было долгих пауз. Мне очень нравится читать блоги jvm и nodejs разработчиков, они там не редко делятся секретами и показывают частые кейсы проблем с производительностью, есть так же среди них выходцы из постсоветского пространства, с ними интересно пообщаться и они принципе даже на письма по электронке отвечают очень охотно. Честно говоря я раньше JAVA и JS считал очень убогими и тормозными, но потом мое мнение резко поменялось, когда мне показали, что некоторые инструкции практически с нулевым оверхедом конвертируются в ASM сравнимый по скорости код, как из под компилятора. Когда начинаешь изучать и лучше уходить в принципы работы JVM, JIT, AOT, GC, начинаешь понимать какое сложное это изобретение, и какие гениальные программисты пишут там код. Ну и в принципе для таких как вы пишут такие книги www.piter.com/product_by_id/227095092. Издательство Питер ph_piter не забудьте мне заплатить за рекламу вашей книги.
Лично не принижаю достоинств Rust и он мне нравится как язык, мне просто не нравится когда принижают Java или nodejs, и не достаточно понимают как они работают. Впринципе в целях highload и чтобы избавиться от GC на их приложениях, не редко просто пишут свой алокатор для JAVA, которые оптимально подходит именно под их задачи, что даже видел лет 20 назад. Благо это все делается легко.
Вы плохо читали про объем? Вы никогда не слышали историю про то, как одна довольно крупная компания экперементировала с ВЧ алгоритмам, и благодаря сбою в алгоритме просела за день примерно на 200 миллионов? в итоге они отказались от ВЧ алгоритмов… Даже если на исторических данных алгоритм показывает, что можно заработать, на реальных данных очень часто там будет минус так как на рынок уже оказываете влияние своим объемом. Впринципе объем для HFT необходимый есть во фьючерсе на индекс S&P 500, но там тоже объем где-то на несколько миллионов, а у крупных игроков на миллиарды могут быть позиции. У них большии позиции и к примеру даже 15% годовых для большого количества миллиардов будет лучше, чем 40% годовых от 50 миллионов… Это просто математически не оправдано. Плюс получится так, что впринципе они эксплуатируют сами себя, и переносят свои деньги из одной в стратегии в другую. Им проще делать адаптацию, чтобы не эксплуатировали их, чем вводить HFT. Но я бы его не рискнул торговать, он слишком волатильный — высокая дисперсия, что не вписывается в мою модель риск менеджмента, мне комфортные с алгостратегиями где низкая дисперсия.
В подобных проектах впринципе обычно все жестко. Даже к форматированию придираются. Первый раз делают замечание, просят исправить, не исправляете в адекватный срок, отклоняют пул реквест, или если повезет кто-то перепишет правильно. Сломали коммитом что-то, по головке не погладят… Лично у меня было десятки раз, что даже отклоняли по совсем неадекватным причинам. Не конструктивность codereview решается банально за счет декларации как должен быть оформлен код, что можно делать, а чего нельзя. И в принципе должен быть опытный мейнтейнер.
Язык в первую очередь должен быть удобен для программирования и не нарушать привычные паттерны, можно сделать совсем радикально и сделать набор кода справа на лево, но это кроме арабов никто не оценит…
2. Просто парсер и постройка AST.
3. Prefixers — Это работа с AST на примере добавления префиксных свойств для браузеров с проверкой по базе совместимости. Т.е. полный пайплайн.
Лично не принижаю достоинств Rust и он мне нравится как язык, мне просто не нравится когда принижают Java или nodejs, и не достаточно понимают как они работают. Впринципе в целях highload и чтобы избавиться от GC на их приложениях, не редко просто пишут свой алокатор для JAVA, которые оптимально подходит именно под их задачи, что даже видел лет 20 назад. Благо это все делается легко.