Привет, Хабр! Меня зовут Денис Зеленых, я дизайнер, арт-директор, а также ревьюер в Яндекс Практикуме. В этой статье хочу поделиться универсальными рекомендациями по написанию промтов для нейросетей.

Прочитал и посмотрел почти все статьи и видео по Obsidian, которые вышли недавно (в среднем не более 1-2 ух месяцев назад). Дал каждому источнику субъективную оценку и написал короткий комментарий.

Меня зовут Женя, я главный разработчик в компании ITFB Group. По долгу службы я общаюсь с большим количеством разработчиков: собеседую, помогаю в развитии, выступаю наставником, иногда оказываю психологическую поддержку. Кому-то советую книги, предлагаю использовать те или иные популярные процессы или просто стараюсь подсказать что-то, что опытный инженер считает фундаментальным. 

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

Вот один из карьерных путей в разработке ПО:

1. Проведите несколько первых лет в небольшой компании, не понимающей технологий. Теперь вы единственный программист или один из немногих.

2. Случайно создайте очень плохую систему, но чтобы компания этого не понимала. Вы тоже пока этого не понимаете.

3. Потратьте кучу времени на эксплуатацию этой критичной для бизнеса системы, которую, похоже, понимаете только вы. Начните считать, что система, возможно, неидеальна из-за того, что постоянно ломается.

4. Освойтесь в устранении неполадок и в возврате системы в строй. Получите несколько повышений в зарплате и должности, пока в ней не появится слово «Senior»; скорее всего, это произойдёт не позже чем спустя три года после того, как вы начнёте устранять неполадки системы.

5. Оставайтесь в компании много лет, солидную часть своей карьеры, пытаясь устранять ошибки, которые совершили в первоначальной системе.

6. Каждые несколько лет получайте ещё одно повышение и красивое дополнение к названию должности.

Для всех джунов в разработке и тех, кто хочет ими стать.

Так бывает в жизни, что периодически каждый оказывается в роли джуна. Это не только про начало карьерного пути, но и про новые навыки: изучить новую технологию, язык программирования. А вдруг кто-нибудь из вас захочет резко сменить карьерный вектор и залететь в ИТ, например, из HR, как это сделала я?

Привет! Меня зовут Даша, я iOS-разработчик в Точке.

Так сложилось, что я побывала по обе стороны баррикад, причём, как ни забавно, в обратном порядке: пришла в разработку из HR. 

Изначально я была IT-рекрутером: брала джунов в Точку и помогала командам выстроить процесс их адаптации так, чтобы они смогли вырасти в дальнейшем. А потом, по законам кармы, сама оказалась в роли джуниор iOS-разработчика и попробовала всё ранее придуманное на своей шкуре. 

Жизнь длинная, и всё бывает: ещё вчера ты был уверенным в себе профессионалом, а сегодня стал беспомощным младенцем. И это не очень приятное ощущение. Хочется как можно быстрее превратиться обратно в самостоятельного человека. 

Лови 9 советов, которые помогут тебе сделать это легче.

Эффективно управлять можно только той собственностью, которую мог бы создать сам.
Кто не может создать, – будет только разрушать!
И.А. Дедюхова, Кодекс Хамурапи

Краткое содержание

Новый директор себе в подчиненные и советники пригласит своих «проверенных людей». Увеличение штата топ-менеджеров в условиях фиксированного ФОТ повлечет за собой сокращение рядовых сотрудников на значительный процент.
Новый директор в первую очередь будет сокращать те подразделения, работу которых он не понимает. Под прессом психологического давления руководители этих подразделений возмут на себя обязательства самостоятельно разработать планы по сокращению и принять на себя все риски их реализации.
Сокращения пройдут под флагом повышения эффективности, но для «непонятных директору» подразделений не смогут сформулировать критерии этой эффективности, кроме «минимизации затрат». Цель по минимизации затрат без дополнительных обоснованных ограничений – это цель по уничтожению, и не имеет отношения к настоящей оптимизации.
Отсекая непонятные ему части компании (выводя в аутсорс и т.п.), директор попытается превратить компанию в ту, работу которой он полностью способен понять, которой он в полной мере способен управлять.
Проблему нехватки знаний в технической области новый директор и его команда компенсируют «помощью» от западных консалтинговых компаний. Это приведет к ситуации внешнего управления, причем без всякой ответственности за диктуемые извне решения.
Внешняя и внутренняя отчетность о работе компании до самого конца не будет показывать никаких признаков проблем, т.к. тому, кто принес плохие вести не выдают премию, а рубят голову.

Лирика

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах