Не так давно одному из авторов этого поста довелось интервьюировать Майка Кларка, который, в частности, сказал: “…вот увидите, какой принципиальный прогресс готовит нам будущее в виде процессора Zen 6, хотя, на самом деле, все условия для этого были заложены ещё на этапе Zen 5». На той же конференции по архитектуре, посвящённой Zen 5 выступил и Марк Пейпермастер, генеральный технологический директор AMD, высказавшийся так: «Zen 5 — это основательная переработка всей архитектуры Zen». Всё дело в многочисленных и принципиальных изменениях в устройстве ядра, которые обогатили процессор именно в этой версии.

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

Вкратце, для тех, кто ещё не слышал о новом скандале на IT рынке: Крупнейший автомобильный дилер «‎Рольф» увольняет айтишников без компенсаций.

В профсоюз обратились несколько сотрудников из компании и описали происходящее: +- 50 человек решили уволить потому что для них нет работы. Сотрудников по одному вызывали в кабинет где сидели 4 коллеги и рассказывали им о жизни, понятиях и отношениях: «ну мы же как семья». Всё ради того, чтобы получить подпись в соглашении о расторжения трудового договора одним днём. Без каких либо выплат. Спойлер — почти все сотрудники повелись на манипуляции и их уже уволили.

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

Бобер-HRобер: я увидела как грызете дерево в соседнем лесу, не хотите перебраться к нам? У нас деревья синие и потолще ваших, зеленые деревья нынче не в моде.
Бобер-погромист: хм, наверное нет, толщина текущих деревьeв меня устраивает.

Бобер-HRобер: ну вы всё-таки приходите, мы заложили пару делянок, где самые опытные бобры будут распиливать очень старую монолитную сосну с ветками длиной 98 см, на доски очень модной нынче длины 23 см, а еще у вас также будет возможность повлиять на толщину досок длиной 26 см.
Бобер-погромист: а вот это интересно, отправляйте соловья.

Через неделю, на комфортабельной полянке где-то в синем лесу.

Senior-Бобер: Итак, вы считаете себя хорошим бобром?
Бобер-погромист: Всё верно. Грызу деревья разной толщины уже лет двадцать.

Lead-Бобер: А ветки какой длины предпочитаете?
Бобер-погромист: Ветки 17см самые вкусные

Бывает так, что в продуктовой IT-компании выстраивается иерархия, в которой верхние уровни работников компании совершенно не понимают как производится продукт, который компания производит и продаёт. По сути руководители знают как продать, но не знают как произвести. Для производства, что логично, нанимаются исполнители с опытом. Это нормальная практика. Но дальше в зависимости от того, как выстроены процессы внутри компании могут быть проблемы. О некоторых проблемах я бы хотел написать в этой статье.

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

Приветики. Надеюсь, все отошли от новогодних, и можно писать и читать дальше. Как хозяин умного дома, я состою в чатике по Home Assistant, там прекрасное ответчивое комьюнити,
но периодически задаётся вопрос по тому, как собственно выставить свой веб сервис в интернет. И оказывается, что в двух словах тут не ответишь, а вменяемой инструкции на которую можно дать ссылку - нет. Так что теперь она будет здесь.

Рокет сайнса здесь не встретите, и в целом все эти вещи справедливы и работают уже минимум лет 10, просто не так тривиально понять, какой именно запрос нужно задать в гугл, и что делать.

Мы рассмотрим здесь несколько сценариев - статический белый айпи, динамический белый айпи, и серый. Для серого рассмотрим варианты с готовыми сервисами, с помощью Keenetic и с помощью ssh туннеля. Погнали!

В кульминационный момент Второй мировой войны ЦРУ выпустило потрясающую книгу Simple Sabotage. В ней изложены различные способы, которыми диверсанты могут снижать продуктивность компании. Некоторые из этих советов не стареют, например, раздел «Общие помехи организациям и производству»:

1. Настаивайте на том, чтобы всё выполнялось через «каналы». Не допускайте того, чтобы для ускорения реализации решений выбирались кратчайшие пути.

2. Делайте «доклады». Говорите как можно чаще и пространнее. Иллюстрируйте свои «идеи» долгими историями из жизни и ссылайтесь на личный опыт. С готовностью делайте «патриотические» комментарии.

3. По возможности отправляйте все вопросы в комитеты для «более глубокого изучения и рассмотрения». Стремитесь делать комитеты как можно больше, не менее чем из пяти членов.

4. Как можно чаще поднимайте вопросы о несущественных проблемах.

5. Спорьте о чётких формулировках в общении, протоколах, резолюциях.

6. Возвращайтесь к темам, по которым было принято решение на последнем совещании, и пытайтесь повторно открыть вопрос о целесообразности этого решения.

7. Советуйте «быть аккуратными». Будьте «разумны» и подталкивайте других участников совещаний к «разумности», к тому, чтобы они избегали спешки, которая может в будущем вызвать неудобства или сложности.

8. Беспокойтесь о правильности каждого решения, поднимайте вопрос о том, будет ли рассматриваемое действие относиться к юрисдикции группы или оно может вызвать конфликт с политикой какого-то более высокого эшелона.

Меня всегда поражало, насколько хорошо эти советы прошли проверку временем.

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

Да, уже были статьи про собеседование и даже в эту же структуру, некоторые из них я видел, но не во всём с ними согласен, к тому же конкретно С++ разработчиков я там не видел.

Меня зовут Аят, я Android-инженер команды антифрода в inDrive. Эта статья не связана с продукционной разработкой, но будет касаться программирования. Я расскажу о Dynamic Programming (DP) и о том, как эффективно использовать предыдущий computation-опыт. Надеюсь, будет интересно. 

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

Знаете, однажды в какой-то статье я наткнулся на интересное высказывание, которое гласило, что фронтенд-разработчик может стать последним рубежом, который может предотвратить создание «неюзабельного» UI. И это чертовски меткое и выразительное высказывание, которое отчасти и привело меня к созданию этой статьи про базовые принципы UX, которые не помешало бы иметь на вооружении каждому фронтенд-разработчику.

Дизайн превью: Марина Четвертакова

Помните Буратино, перед которым было две дороги — в школу или в кукольный театр? Он решил повернуть к развлечениям, и вскоре начались его несчастья. Закончилось всё хорошо, но это сказка, а в реальной жизни последствия неправильного решения могут быть более плачевными. Почему так происходит и можно ли этого избежать?

Искали работу в интернете? Находились в поиске идеального метода заработка? Перечитали тысячи материалов? Получили специальность data-scientist после курсов по рекламе с youtube? Сомневаетесь между вебкамом, и трейдингом? Хватит это терпеть! Создай свой криптоскам, и уедь наконец-то. Если повезет — на Канары. Если не повезет, то в места поближе.

Привет! Меня зовут Андрей Шмиг, я разработчик платформы DataHub, платформа для совместной работы над данными - своего рода GitHub для данных. В этой статье покажу на что способен веб-редактор MySQL хранилища и почему это отличный инструмент для работы тем, кто изучает SQL.

Многие слышали про Midjourney, но про то, что есть локальная Stable Diffusion, которая может даже больше, знает уже куда меньше людей, или они не знают, что она локальная. И если они пробовали её онлайн, то быстро приходили к выводу, что она сильно хуже чем Midjourney и не стоит обращать на неё более внимания. И да, SD появился раньше Midjourney. Для запуска хватит и cpu или 4гб видеопамяти.

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

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

Для начала определимся с термином «чайка-менеджмент». Чайка-менеджмент - это стиль управления, при котором менеджер, внезапно «налетев», поднимает много шума, а затем так же внезапно «улетает», оставив после себя полный беспорядок, с которым должны разбираться другие. Проще говоря, если убрать оценочные суждения и эмоции, то чайка-менеджмент - это когда руководитель регулярно вмешивается в ход работы над поставленными им же ранее задачами. Чайка-менеджмент часто путают с микроменеджментом. Микроменеджмент - это постановка простых коротких задач, превращающая сотрудников в биороботов. Метод хорошо подходит для работы с низкоквалифицированным и низкомотивированным персоналом, а также в критических ситуациях, требующих быстрых решений. То есть микроменеджмент предполагает, что руководитель делегирует полномочия, хотя и в очень ограниченном объеме, в отличие от чайка-менеджмента, который является ярким примером нарушения принципов делегирования.

Почему руководитель может себя так вести? У этого есть культурные и исторические причины. Если верить Акунину и Прохорову, то после татаро-монгольского ига в России распространилась авторитарная система единоначалия, в противовес европейским принципам вассалитета: «вассал моего вассала не мой вассал», которые и легли в основу местного самоуправления, а затем переросли в правила делегирования в офисе. Но нас интересуют не все руководители в России разом, а конкретный Иван Иваныч, который может быть умный мужик, читал умные книги по менеджменту, но все равно занимается такой вот херней.

Предотвращение когнитивной перегрузки программиста — это ключ к недопущению ошибок и ускорению разработки.

Среди подкастов, которые я обычно слушаю, один называется «Никаких дурацких вопросов». В минувший понедельник я с большим интересом прослушал выпуск «Когда простота становится избыточной?». В нем авторы бросили вызов пресловутой «бритве Оккама» и продемонстрировали предвзятое отношение людей к простейшему объяснению по сравнению с более сложным. Несмотря на то, что в физике зачастую самое простое объяснение оказывается единственно верным, в других науках, таких как экономика или психология, ситуация может измениться. Почему пала Римская империя, или отчего преступность в последние десятилетия пошла на спад — причин тому не одна, а несколько. Авторы подкаста ясно показали, что, несмотря на любые факты, люди предпочитают иметь дело только с одним, а не с несколькими объяснениями случившегося. Это поразило меня.

Почему ИТ специалисты на самом деле не любят выполнять тестовые задания? Почему меньше откликов на вакансии без указания зарплаты? Простые ответы на сложные вопросы.

Про бритву Оккама хоть раз слышал каждый: во многих статьях и книгах встречается призыв не множить сущности без необходимости. Но не все знают, что в науке есть и другие «бритвы», которые помогают избавиться от лишнего. Термин «бритва» используется для обозначения метода, который помогает отбрасывать что-то ненужное, маловероятное, неправдоподобное. Принцип «бритвы» или «лезвия» — это на удивление универсальный инструмент, который помогает не только в процессе научного познания, но и в работе, и в повседневной жизни.

В этой статье я перечислю несколько известных «именных» бритв (про Оккама тоже не забуду) и покажу, как их можно использовать в работе IT-специалиста. Заодно я сформулирую несколько правил, которые сам стараюсь соблюдать при применении этих самых «бритв», чтобы ненароком не ошибиться и не получить результат, противоположный ожидаемому.

Официальная легенда Маска, она же легенда Гейтса, Делла, Джобса, Цукерберга и Дурова, гласит, что прогресс движется гениями и вознаграждается богатством. Соответственно, богатство превращается в индикатор гениальности, а его размер — в меру. Чем богаче, тем гениальнее. Получается идеальная в своей нефальсифицируемости основа для религиозной веры. Если человек готов в это поверить изначально, то абсолютно все факты реального мира будут служить только подтверждением изначального допущения.

Если же изначально ставить под сомнение, что богатство является главным индикатором гениальности или, точнее, значимости вклада индивида в прогресс цивилизации, то становятся видны проблемы веры в прогресс, творимый богачами-демиургами. Главная из которых — вопрос умножения результатов. Если прогресс движется демиургами, то где нам взять новых демиургов?