In versions of Visual Studio before Visual Studio 2022 version 17.0, the maximum length of a string literal is 65,535 bytes. This limit applies to both narrow string literals and wide string literals. In Visual Studio 2022 version 17.0 and later, this restriction is lifted and string length is limited by available resources.
Вообще-то ЗП в большинстве случаев намного меньше, и всё очень сильно зависит от города и компании. Конечно, может в Гугле в Мюнхене, а ещё лучше в Цюрихе, вам могут "отвалить" астрономическую сумму, а в Берлине - спокойно в 2 раза меньше. В остальных городах где-то посередине.
Для общей картины glassdoor и stepstone в помощь. IT-шники частенько зарабатывают хорошо, но в целом разница по сравнению с другими профессиями не очень большая. За услуги придется платить столько же в час сколько у вас ЗП до налогов. Но там ещё хорошо насчитают помимо часов.
В Москве, скорее всего, действительно существенно намного выгоднее.
> Если у вас ПМы гробят разработку из за незнания и непонимания тех деталей означает, что у вас ПЛОХО организовано руководство и неправильная культура в компании.
Полностью согласен! К счастью, у «нас» такого нет, но все приведённое выше к сожалению живые примеры…
Крутая статья, и я рад, что у вас всё работает, но у меня впечатление, что всё определяется адекватностью и квалифицированностью конкретной группы людей, а структура просто подходит для этой конкретной группы. У вас это продуктовые менеджеры, а в другом месте это будут тимлиды, техлиды, кто-то вообще скажет QA или dev-ops и т.п.
Выше уже указывали на нестыковки, но все таки, если с тимлидами понятно, то что случилось с сеньорами и техлидами (в софтверных компаниях), которые упоминаются в тексте и на картинках? А что с архитекторами?
Что-то очень сомнительно, что крутые разработчики находят это лучше. Нет тайтла — нет причин платить им зарплату как тех лидам. Если у вас действительно так, то хорошо, но скорее всего в других местах все будут получать как middle или junior. Если у людей нет возможности роста у вас, то сначала будет демотивация, выгорание и т.п., что вредит всем, а потом они найдут рост сразу в ЗП и тайтле в другом месте.
> команда состоящая не из руководителей и подчинённых
В такой структуре скорее всего продакт менеджеры либо явные, либо неявные руководители. И тут можно почти без изменений переписать «Реальность: проблемы в работе продакт менеджера» и далее по тексту.
К примеру откуда возьмётся «доверие» со стороны технических людей, если ПМы гробят разработку, потому что они не только не знают техническую сторону предметной области, но и с другой планеты, где нет архитектуры, тестов, систем сборок, репозиториев, и т.д. Плюс добавим проблему коммуникации ПМ: " ПМ видит всю картину, а задача какого-то там разработчика закрывать таски".
«Пассивный контроль» — ПМ рассуждает так: «что-то метрики в джире слабоватые, и мои фичи медленно делаются. Нужно узнать, где проблема, а давайте ка соберем метрик побольше». Результат недоверие со стороны ПМ. В итоге недоверие обоих сторон и микроменеджмент.
«Независимость» — с ростом числа людей появляется политика, и конец независимости может прилететь откуда угодно.
Очень интересно! Календарь, конечно, лучше.
Оффтопик:
если перенести daily на 14:30, то у вас будет дольше блок времени в первую половину дня, что позволит работать над новыми категориями задач с утра, при этом не сильно пострадает «после обеда»
что означает «начало работы»
что думают о вашем календаре ваши коллеги и ваш начальник?
Возможно просто минимизируют attack surface.
К примеру, утёкший пароль даёт доступ сразу ко всему, а для каждого token'а, надаюсь можно ограничить доступ только к определённым данным и операциям.
Так же подозреваю, что многие использовали пароль везде, где можно, а теперь github подталкивает к использованию разных token'ов для каждого места. В итоге, если в одном месте что-то пошло не так, то не надо менять пароль (стоит ли все равно обновить все token'ы?..), а так же, надеюсь, что можно будет отследить все операции для конкретного token и выяснить, где дыра.
Ответ: первый шаг — покажете ваш personal development plan. А вообще по ссылке около странной формулировки о 34% все есть. Не поленюсь и тезисно сюда продублирую
обсудите с подчиненными развитие их карьеры, помогите разработать план. От себя добавлю, что как руководитель так же сделайте это возможным
создайте и развивайте культуру изучения нового. С точки срезния сотрудника, особенно ценными будут знания, которые помогут его карьере и вообще росту и развитию во всех направлениях
развивайте соих менеджеров. От себя в пользу этого пункта порекомендую почитать статьи, что люди уходят не с работы или из компании, а от менеджеров. Еще добавил бы, что можно и нанять. Почему-то все слышали байки про индийских программистов и их код, но не часто услышишь подобное про каких-то неадекватных и крайне непрофессиональных менеджеров, а ситуация в точности такая же
diversity and inclusion (не знаю как перевести :D) От себя добавлю, что на практике это не только и не столько про всяких маргиналов и меньшиства. Ни разу не видел такое на практике. Зато полно людей со стереотипами на базе национальных признаков, количества лет в какой-то опреденной компании, знакомства с кем-то, и прочая чушь. Сделате так, чтобы все были равны, вовлечены, и их мнения аргументированно и справедливо учитывались, и все будет ОК
Далее по ссылке в еще более вольной интерпретации
найдите людей, которые будут вдохновлять ваших сотрудников и коллег. Если бюджет позволяет то пригласите извне пообщаться (у меня был такой опыт, и мне этот подход кажется сомнительным), если нет — то дайте возможность обучиться у самого лучшего профессионала, который сейчас у вас работает
сделайте так, чтобы сотрудник поработал над чем-нибудь интересным для не-ё/-го
дайте возможность «рядовым» сотрудникам общаться с высшим руководством, чтобы сотрудники могли спокойно поделиться своими мыслями и переживаниями, и проникнуться целями компании, и как важен их отдел :D
Хочу поделиться небольшим опытом использования LOUDS в задаче нахождения всех строк из заранее заданного набора как подстрок входной строки. Т.е. к примеру, есть 100 000 небольших (3-50 символов) строк-фильтров, их надо компактно хранить и уметь быстро найти все такие строки, которые являются подстрокой тестируемой.
LOUDS действительно сильно помогает даже с накладными расходами, о которых через предложение. К примеру, реализация double array trie потребляла бы раз в 5 больше памяти. На самом деле я использовал Aho–Corasick. Для этого в trie параллельно с массивом битов использовал массивы для хранения данных. К примеру, по тем же смещениям, что и rank1 (c небольшой корректировкой), в еще одном массиве лежат символы (8 bits, типа ASCII (К сожалению, я дальше не исследовал, но мне кажется, что тут можно сделать поддержку UTF-8 с довольно приличными характеристиками, когда в других реализация размер алфавита довольно ограничен.)), а так же в еще одном массиве битов информация о том, является ли данный символ концом какой-либо строки.
Такой же трюк для структуры Aho–Corasick, суффиксные и конечные ссылки (терминология из вики) так же хранятся в массивах, плюс битовые массивы для индикации есть ли у этого узла соответствующая ссылка.
Как можно заметить коэффициент у О-большое уже не такой уж и маленький, как в статье.
Может легко оказаться, что если найти разумный подход с N-граммами, то выгоднее хранить извлеченные подстроки из строк словаря в хеш-таблице, а сами строки отдельно.
В любом случае придется анализировать природу данных и подкручивать тут и там.
Скорость работы при этом может оказаться сравнима, ну или, к примеру, достаточной для текущей бизнес задачи. Кстати, все упирается в select, где в моем случае скорее О(log(N)) (rank9 + бинарный поиск блока), чем O(log(log(N)), SIMD пока не использовали. Кстати, в случае с N-граммами можно относительно легко и дешево модифицировать сам словарь со строками.
К сожалению у меня не было возможности копать дальше, если у кого-то есть опыт, то было бы интересно услышать.
Сколько у вас обычно раундов комментирования в одном код-ревью?
Мы продолжаем отслеживать процесс код-ревью и решать все технические и даже психологические проблемы
Вот на последнем пункте можно поподробнее? К примеру, что вы делаете, когда люди завалены демотивирующими код-ревью? Демотивируют, потому что код, мягко говоря, «пахнет», а автор сопротивляется исправлять.
Как на счет изменения масштаба, смещения (сдвиг) и, возможно, поворота холста?
В онлайн редакторе не помешали бы всплывающие названия контролов, когда курсор над ними.
Когда на тысячи я использую хак (а может так и надо?) в виде пула, но я полностью за Ваш вариант с async-await по сравнению с примером выше с reduce, если нужно именно последовательно.
Это к чему? Тут как раз, скорее всего, async-await не нужен, потому что, скорее всего, нет смысла обрабатывать URL'ы по очереди, было бы лучше «одновременно».
Я совсем не эксперт в функциональном программировании и в async-await в JS, но, на мой взгляд, пример в статье совсем не отражает её суть.
В частности, практически каждый метод имеет побочные эффекты, любой метод может изменить внутреннее состояние аргумента, и, в общем-то, часто именно эти явления и ожидаются. То есть, идеологически полный провал.
Кстати, `isUserValidAsync` было бы лучше назвать assertValidUserAsync или использовать по-другому.
С другой стороны, в случае использования async-await, на мой взгляд, существенно улучшается читабельность кода от чего напрямую зависит его качество и стоимость поддержки. Хотелось бы заметить, что читабельность улучшается за счет меньшего количества всяких скобочек, запятых, вызываемых методов и вообще меньше кода.
При этом никто не запрещает использовать элементы функционального подхода, только без лишних ограничений на способ выражения желаемого. К тому же, наверняка, JS-движок следующей версии сможет существенно оптимальнее представить внутри себя async-await конструкции, чем свалку promise'ов, а программист все так же может продолжать использовать более менее простую модель с выворачиванием этого всего в promise'ы.
Понятно, для телефона можно узнать по крайней мере теоретически поддерживаемые конфигурации, а как узнать, что предоставляет оператор в конкретном районе? Нет ли каких-либо открытых карт с этой информацией и дальнейшими планами и, желательно, не только для России?
Тут та же самая ошибка, если один из потоков использует неконстантные методы доступа, то будет data race.
All member functions (including copy constructor and copy assignment) can be called by multiple threads on different instances of shared_ptr without additional synchronization even if these instances are copies and share ownership of the same object. If multiple threads of execution access the same shared_ptr without synchronization and any of those accesses uses a non-const member function of shared_ptr then a data race will occur; the shared_ptr overloads of atomic functions can be used to prevent the data race.
Как передать в другой тред? — использовать другие неблокирующие структуры данных, например, попробовать неблокирующие очереди, но это пахнет тем же мьютексом на спин-локах. Хотя производительность надо мерить в конкретном случае.
При любых операциях с собственно указателем, например присвоении, мы должны атомарно проверять счетчик и одновременно изменять указатель на контрольный блок, что невозможно используя существующие атомарные примитивы.
Похоже, что так, если только кто-нибудь не придумает какой-нибудь трюк вроде tagged pointer, еще одного уровня вложенности или еще чего.
На самом деле я был бы рад ошибиться, возможно есть что-то, что я не знаю или понимаю неправильно?
А не посмотрите реализацию std::experimental::atomic_shared_ptr?
Вроде, тут нет проблем, объект будет удалён, когда закончится scope для __range.Невнимательно посмотрел, действительно баг.
Просто поделюсь хорошей новостью по поводу #embed, наконец-то в Visual C++ убрали ограничение на длину строки, правда пока все обновятся... https://learn.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-170#size-of-string-literals
И на всякий случай https://learn.microsoft.com/en-us/cpp/c-language/maximum-string-length?view=msvc-170
Вообще-то ЗП в большинстве случаев намного меньше, и всё очень сильно зависит от города и компании. Конечно, может в Гугле в Мюнхене, а ещё лучше в Цюрихе, вам могут "отвалить" астрономическую сумму, а в Берлине - спокойно в 2 раза меньше. В остальных городах где-то посередине.
Для общей картины glassdoor и stepstone в помощь. IT-шники частенько зарабатывают хорошо, но в целом разница по сравнению с другими профессиями не очень большая. За услуги придется платить столько же в час сколько у вас ЗП до налогов. Но там ещё хорошо насчитают помимо часов.
В Москве, скорее всего, действительно существенно намного выгоднее.
Полностью согласен! К счастью, у «нас» такого нет, но все приведённое выше к сожалению живые примеры…
Выше уже указывали на нестыковки, но все таки, если с тимлидами понятно, то что случилось с сеньорами и техлидами (в софтверных компаниях), которые упоминаются в тексте и на картинках? А что с архитекторами?
Что-то очень сомнительно, что крутые разработчики находят это лучше. Нет тайтла — нет причин платить им зарплату как тех лидам. Если у вас действительно так, то хорошо, но скорее всего в других местах все будут получать как middle или junior. Если у людей нет возможности роста у вас, то сначала будет демотивация, выгорание и т.п., что вредит всем, а потом они найдут рост сразу в ЗП и тайтле в другом месте.
> команда состоящая не из руководителей и подчинённых
В такой структуре скорее всего продакт менеджеры либо явные, либо неявные руководители. И тут можно почти без изменений переписать «Реальность: проблемы в работе продакт менеджера» и далее по тексту.
К примеру откуда возьмётся «доверие» со стороны технических людей, если ПМы гробят разработку, потому что они не только не знают техническую сторону предметной области, но и с другой планеты, где нет архитектуры, тестов, систем сборок, репозиториев, и т.д. Плюс добавим проблему коммуникации ПМ: " ПМ видит всю картину, а задача какого-то там разработчика закрывать таски".
«Пассивный контроль» — ПМ рассуждает так: «что-то метрики в джире слабоватые, и мои фичи медленно делаются. Нужно узнать, где проблема, а давайте ка соберем метрик побольше». Результат недоверие со стороны ПМ. В итоге недоверие обоих сторон и микроменеджмент.
«Независимость» — с ростом числа людей появляется политика, и конец независимости может прилететь откуда угодно.
Оффтопик:
К примеру, утёкший пароль даёт доступ сразу ко всему, а для каждого token'а, надаюсь можно ограничить доступ только к определённым данным и операциям.
Так же подозреваю, что многие использовали пароль везде, где можно, а теперь github подталкивает к использованию разных token'ов для каждого места. В итоге, если в одном месте что-то пошло не так, то не надо менять пароль (стоит ли все равно обновить все token'ы?..), а так же, надеюсь, что можно будет отследить все операции для конкретного token и выяснить, где дыра.
Далее по ссылке в еще более вольной интерпретации
- найдите людей, которые будут вдохновлять ваших сотрудников и коллег. Если бюджет позволяет то пригласите извне пообщаться (у меня был такой опыт, и мне этот подход кажется сомнительным), если нет — то дайте возможность обучиться у самого лучшего профессионала, который сейчас у вас работает
- сделайте так, чтобы сотрудник поработал над чем-нибудь интересным для не-ё/-го
- дайте возможность «рядовым» сотрудникам общаться с высшим руководством, чтобы сотрудники могли спокойно поделиться своими мыслями и переживаниями, и проникнуться целями компании, и как важен их отдел :D
- тимбилдинг и fun at work, только не из-под палки
и т.д.LOUDS действительно сильно помогает даже с накладными расходами, о которых через предложение. К примеру, реализация double array trie потребляла бы раз в 5 больше памяти. На самом деле я использовал Aho–Corasick. Для этого в trie параллельно с массивом битов использовал массивы для хранения данных. К примеру, по тем же смещениям, что и rank1 (c небольшой корректировкой), в еще одном массиве лежат символы (8 bits, типа ASCII (К сожалению, я дальше не исследовал, но мне кажется, что тут можно сделать поддержку UTF-8 с довольно приличными характеристиками, когда в других реализация размер алфавита довольно ограничен.)), а так же в еще одном массиве битов информация о том, является ли данный символ концом какой-либо строки.
Такой же трюк для структуры Aho–Corasick, суффиксные и конечные ссылки (терминология из вики) так же хранятся в массивах, плюс битовые массивы для индикации есть ли у этого узла соответствующая ссылка.
Как можно заметить коэффициент у О-большое уже не такой уж и маленький, как в статье.
Может легко оказаться, что если найти разумный подход с N-граммами, то выгоднее хранить извлеченные подстроки из строк словаря в хеш-таблице, а сами строки отдельно.
В любом случае придется анализировать природу данных и подкручивать тут и там.
Скорость работы при этом может оказаться сравнима, ну или, к примеру, достаточной для текущей бизнес задачи. Кстати, все упирается в select, где в моем случае скорее О(log(N)) (rank9 + бинарный поиск блока), чем O(log(log(N)), SIMD пока не использовали. Кстати, в случае с N-граммами можно относительно легко и дешево модифицировать сам словарь со строками.
К сожалению у меня не было возможности копать дальше, если у кого-то есть опыт, то было бы интересно услышать.
PS. спасибо за статью!
Вот на последнем пункте можно поподробнее? К примеру, что вы делаете, когда люди завалены демотивирующими код-ревью? Демотивируют, потому что код, мягко говоря, «пахнет», а автор сопротивляется исправлять.
В онлайн редакторе не помешали бы всплывающие названия контролов, когда курсор над ними.
В частности, практически каждый метод имеет побочные эффекты, любой метод может изменить внутреннее состояние аргумента, и, в общем-то, часто именно эти явления и ожидаются. То есть, идеологически полный провал.
Кстати, `isUserValidAsync` было бы лучше назвать assertValidUserAsync или использовать по-другому.
С другой стороны, в случае использования async-await, на мой взгляд, существенно улучшается читабельность кода от чего напрямую зависит его качество и стоимость поддержки. Хотелось бы заметить, что читабельность улучшается за счет меньшего количества всяких скобочек, запятых, вызываемых методов и вообще меньше кода.
При этом никто не запрещает использовать элементы функционального подхода, только без лишних ограничений на способ выражения желаемого. К тому же, наверняка, JS-движок следующей версии сможет существенно оптимальнее представить внутри себя async-await конструкции, чем свалку promise'ов, а программист все так же может продолжать использовать более менее простую модель с выворачиванием этого всего в promise'ы.
http://wiki.yobi.be/wiki/Forensics_on_Incident_3
boostcon/cppnow 2016/implementing_a_lock_free_atomic_shared_ptr.pdf
И там дальше по ссылке литературы www.1024cores.net differential-reference-counting
http://en.cppreference.com/w/cpp/memory/shared_ptr
Как передать в другой тред? — использовать другие неблокирующие структуры данных, например, попробовать неблокирующие очереди, но это пахнет тем же мьютексом на спин-локах. Хотя производительность надо мерить в конкретном случае.
Похоже, что так, если только кто-нибудь не придумает какой-нибудь трюк вроде tagged pointer, еще одного уровня вложенности или еще чего.
А не посмотрите реализацию std::experimental::atomic_shared_ptr?