Но если речь зайдёт о soft skills — тут, как правило, ответы будут более размытыми и будут выглядеть как коммуникабельность, грамотная речь, умение находить общий язык и так далее.

В качестве руководителя подразделения мне приходилось подавать заявки на подбор персонала, и в какой-то момент я решил более чётко специфицировать soft skills, которые я ожидаю от кандидата. А после найма ещё и нужно было составлять карту развития этих самых навыков, ведь каждый человек уникален в своём опыте и склонностях. Потому каждому моему сотруднику я рекомендовал подтянуть те или иные навыки, а чтобы рекомендации были более фокусными — я стал рекомендовать им почитать книги, которые прочёл сам и которые помогли мне в развитии того или иного навыка.

В этой статье я решил поделиться своими рекомендациями. Статья эта будет периодически обновляться, так как книги я читаю постоянно и, добавляя их в свою «золотую коллекцию», буду обновлять и эту статью.

Как часто конфликт на работе является проявлением ошибок в организации бизнеса? Когда плохие процессы, постоянные изменения, переработки, избыточная бюрократия приводят к выгоранию сотрудников или росту их конфликтности?

Намного чаще, чем принято считать.

И мы с вами сперва разберём некоторые примеры, когда ошибки в организации приводили к конфликтам.

Затем - разберём, почему же у слишком многих служба HR вызывает вопросы и негатив.

И в итоге обратимся к лучшим практикам организации, а помогут нам в этом с вами наркокартели.

Линус Торвальдс как-то написал в своей книге, что создавал Linux для развлечения, но в итоге это привело к революции. Git, его второе творение, также оказалось «случайной революцией» — и сегодня это стандартный инструмент для людей в ИТ. Однако процесс его создания был уже не таким «весёлым» — по крайней мере, для самого Линуса. 

Hello world!

Представляю вашему вниманию первую часть туториала по Tokio.

• Вторая часть
• Туториал целиком

Tokio — это асинхронная среда выполнения (runtime) кода Rust. Она предоставляет строительные блоки, необходимые для разработки сетевых приложений любого размера.

Часть 1
Часть 2

Ситуация с GUI в Rust просто ужасна

В сообществе Rust ходит шутка, что на 5 игр существует 50 игровых движков; наверно, ещё одна такая шутка нужна про фреймворки GUI. Люди пробуют разные подходы, что, учитывая полную обобщённость Rust как языка, имеет смысл. Но в этой статье мы говорим о разработке игр, и я считаю, что в этой сфере у нас не просто дефицит, а полное отсутствие решений.

Под UI я здесь подразумеваю не UI для создания редактора, а внутриигровой UI. То, что должно быть очень стилизовано и наглядно. По моему опыту, самое сложное при создании игрового UI — это не реализация привязки данных, не реактивное обновление элементов и даже не выбор наилучшего способа описания структуры. Самое сложное — это настройка внешнего вида и стиля UI.

Я даже не касаюсь тем наподобие частиц в UI и различных эффектов, которые могут понадобиться пользователю. Очевидно, что полностью независимая от всего библиотека GUI не может иметь сложных шейдерных эффектов и частиц, но мне кажется, что это тоже стало частью общей проблемы. Библиотеки GUI перекладывают всю эту ношу на пользователя, поэтому каждому пользователю приходится заново изобретать велосипед в выбранном фреймворке/движке.

У руководителей, как и у обычных специалистов, бывают самые разные проблемы: с хардами, софтами, мотивацией и прочим.

Самая неприятная ситуация возникает, когда личные ценности и майндсет человека сильно расходятся с работой, которую ему приходится выполнять. Если работа не подходит человеку из‑за конфликта с личными свойствами и мотивацией, это не исправить обучением. Если такой человек — руководитель, будет страдать он и все вокруг него.

После ошибочных назначений на должность отличные сотрудники демотивируются, выгорают в щепки и демеджат всех своих подчинённых и смежников. Не потому, что они недостаточно умны или старательны, а потому, что им каждый день приходится делать вещи, которые они ненавидят или фундаментально не могут делать.

Если ты уже давно и успешно руководишь командами, эта статья вряд ли откроет тебе что‑то новое. Если ты — инженер и думаешь, стоит ли переходить в управление или руководитель, сомневающийся, стоит ли конкретного человека делать лидом — приходи под кат.

Там я поделюсь мыслями о том, какая мотивация и ожидания от управленческой работы приводят или не приводят людей к успеху. Буду рад, если мой пост снизит количество боли и плохих карьерных решений у классных ребят.

Менеджеров проектов можно классифицировать тысячей разных способов: по опыту, по навыкам, по вовлеченности или по сфере работы. Но мы выбрали самый сложный — классифицировать по их манере управления. Один PM на всё готов и вписывает команду в любой движ, другой — напротив, отказывается от активностей и всячески оберегает «своих» от перегруза. В общей сложности мы насчитали 16 ярких типажей. Попробуем разобрать плюсы и минусы каждого.

Нас зовут Аня Ионова и Миша Дырма, мы оба уже много лет работаем в AGIMA, оба прошли путь от линейного проджекта до руководителя проектного офиса. За эти годы мы вырастили десятки РМ-ов, а общались, наверное, с сотнями, если не с тысячами. Мы поняли, что это хороший материал для — немного субъективного — обобщения. В этой статье мы описываем те типы управления, которые видели собственными глазами. А заодно — даем рекомендации, как выявить и грамотно применить скиллы каждого PM.

Всем привет! Я Сергей, работаю в B2B-команде Яндекс Маркета последние 3,5 года. Как уже понятно из заголовка, сейчас я вам расскажу про yet-another-миграцию с базы на базу, которая началась в середине 2021 года и заняла почти год. Получается, мемуары.

Вас ждёт рассказ о том, как мы:

- несколько месяцев чинили тесты и делали трансформер;

- десятки раз переливали данные;

- чинили баги незаметно для пользователей;

- заставили сервис работать на PostgreSQL быстрее, чем он работал на Oracle.

На тему тайны переписки есть шутка про школьника, который не прочел письмо Онегина к Татьяне, поскольку это нарушение статьи 138 УК. Однако ранее везде действовал противоположный негласный закон — вскрывать и просматривать любую корреспонденцию. Для этого в XVII веке во Франции, а следом и во всей Европе были созданы специальные подразделения со зловещим названием «черные кабинеты» (cabinet noir). Попутно их деятельность подстегнула бурное развитие и выход криптографии на государственный уровень. 

Мы побеседовали с Анастасией Ашаевой, кандидатом исторических наук и старшим научным сотрудником московского Музея криптографии. Она рассказала о начале эпохи «черных кабинетов» и том, что это были за структуры, какой вклад они внесли в государственные дела, дипломатию и вообще жизнь людей. Зашла речь и о шифрах того времени, а также интересных случаях, когда работа cabinet noir повлияла на ход истории. 

1. Зависимости пакетов, как и импорт модулей, формируют направленные графы.
2. Интернет — это граф, состоящий из ссылок между веб-страницами.
3. При проверке моделей анализ выполняется путём изучения «пространства состояний» всех возможных конфигураций. Узлы — это состояния, а рёбра — это допустимые переходы между ними.
4. Реляционные базы данных — это графы, в которых узлы являются записями, а рёбра — внешними ключами.
5. Графы — это обобщение связанных списков, двоичных деревьев и хэш-таблиц.¹

Когда в бизнес приходят «эффективные менеджеры», стоит ждать беды. С программами урезания расходов, подкручиваниями KPI и прочими странными решениями бизнес может в краткой перспективе получить даже какую‑то выгоду для себя, но довольно быстро сталкивается с проблемами: сложно продать или просто угробить курицу, несущую золотые яйца, и ожидать, что золотые яйца продолжат появляться.

Иногда решения этих эффективных менеджеров и вовсе приводят к техногенным катастрофам: крупным авариям с большим количеством пострадавших или даже погибших. В этой и следующей публикации мы с вами разберём больше дюжины подобных случаев, чтобы понять, какие ошибки, решения и системные проблемы к этому привели. Чтобы выделить, что не должен делать и чего должен остерегаться бизнес, чтобы не допускать воплощения критических рисков? Ведь для любого бизнеса могут сложиться обстоятельства, которые фактически мгновенно прекратят его работу, и в руках руководства — возможности и инструменты, которые бы предотвратили такой печальный исход.

Конечно, крушение ИТ‑компании, логистического оператора или юридической консалтинговой фирмы не будут так же эффектны или так же опасны, но вряд ли от этого собственники и адекватные руководители захотят наступления своих критических рисков и краха всего бизнеса.

Жадность и глупость - два всадника "Эффективного Менеджмента", из-за которых произошли многие техногенные катастрофы, аварии и банкротства.

В этой публикации вы сможете узнать, как компании могут противодействовать критическим рискам как из-за собственных ошибок, так и из-за внешних угроз:

Как можно внедрить систему управления критическими рисками в несколько простых этапов. И какие при этом могут возникать когнитивные ошибки.

Публикация будет интересна и тем, кто хочет избежать катастроф в управлении компанией, и тем, кто хочет лучше понимать про ментальные ошибки и их влияние на бизнес на конкретном примере.

Доброго времени суток, дорогие читатели! Сегодня я затрону одну интересную тему — графические дисплейные сервера и протоколы в Linux. В этой статье я расскажу вам о архитектуре X11 и Wayland, историю их создания и наконец-то сделаем вывод: Иксы на мороз, или вейланд на помойку?

Еще в далеком 2016 году вышла Fedora 25 с окружением GNOME 3.22 на базе дисплейного сервера Wayland. А в RHEL 10 выкинут X11 на мороз. Релиз RHEL 10 намечен на 2025 год, CentOS Stream 10 — на 2024 год. Для обеспечения работы приложений, требующих X11, будет использоваться XWayland. Таким образом, в 2029 году (к моменту окончания первого этапа поддержки RHEL 9) стоит ожидать появление первого аппаратного обеспечения, не поддерживающего X11.

И как я думаю — будущее за Wayland. Но пока X11 является стандартом. Давайте разберем это!

Иллюстрации к статье подготовлены нейросетью freepik.com.

Многие люди на планете играют в видеоигры. Игры помогают улучшить когнитивные способности, провести приятно свободное время. Данная статья посвящена тому, как запустить Windows-игры под Linux в Wayland.

Эта статья могла бы быть: ставим Wine(Proton) и XWayland, запускаем игры, успех, но нет. В данном материале мы будем сами собирать Wine, решать проблемы, а так же наш Wine будет работать напрямую с Wayland композитором без прослойки в виде XWayland. Плюсы такого метода — лучшая производительность и меньше инпут лаг. Благодаря Wine 9.0 это стало возможно, но не все так просто, как может показаться читателю с первого взгляда. Для примера мы запустим игры: Overwatch 2 через Battle.net клиент и Aimbeast, KovaaK's, Apex Legends через Steam.

Если вас заинтересовала статья, то добро пожаловать под cut.

В настоящее время искусственный интеллект (ИИ) стремительно развивается. Мы являемся свидетелями интеллектуальной мощи таких нейросетей, как GPT-4 Turbo от OpenAI и Gemini Ultra от Google. В Интернете появляется огромное количество научных и популярных публикаций. Зачем же нужна еще одна статья про ИИ? Играя с ребенком в ChatGPT, я неожиданно осознал, что не понимаю значения аббревиатуры GPT. И, казалось бы, простая задача для айтишника, неожиданно превратилась в нетривиальное исследование архитектур современных нейросетей, которым я и хочу поделиться. Сгенерированная ИИ картинка, будет еще долго напоминать мою задумчивость при взгляде на многообразие и сложность современных нейросетей.

Привет, Хабр. Меня зовут Дима и я разработчик, тимлид и по совместительству наставник на курсе «Мидл Python-разработчик» в Практикуме. Сегодня, с вашего позволения, я вставлю свои пять копеек и поделюсь опытом по такой заезженной теме, как технические собеседования. Много слов сказано, статей написано и копий сломано на сей благодатной почве, потому постараюсь быть максимально кратким.

Не буду писать много о себе, скажу лишь одно: я провёл много часов по обеим сторонам стола. Уповаю на то, что смогу кому-то быть полезным в этом нелёгком и, кажется, поднадоевшем деле. Я практически не буду затрагивать другие этапы, сконцентрируюсь только на техническом собеседовании и процессе подготовки к нему.

TL;DR: Внимательно читайте вакансию и анализируйте результат собеседования. Говоря о себе, фокусируйтесь на релевантном для слушателя. Будьте готовы ответить за обозначенный опыт. Задачи совсем не про код. Задавайте вопросы, интересуйтесь. И помните — «г-г-главное  н-н-не бояться». Успехов!

Это ответ на статью, что алгоритмические собеседования не нужны. Простите за кликбейтный заголовок, но он такой и в статье, на которую я отвечаю.

Сразу скажу, что моя статья относится лишь к условному ФААНГу. Многие аргументы из этой статьи теряют значимость в других случаях: если у вас маленькая фирма, мало кандидатов или у вас всего 10 пользователей.

Я утверждаю, что алгоритмические интервью - лучший вариант для ФААНГа из всех пока придуманных.