Никто давно не пытается выводить теорий о том как правильно писать код.

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

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

Во время отпуска в Турции я наткнулся на древнегреческую надпись в руинах Фаселиса и использовал ChatGPT для расшифровки и реконструкции текста. Статья про то, как нейросети позволяют поиграть в археологические исследования, которые ранее требовали работы узких специалистов.

Что если я скажу, что можно создать прошивку для ПЛИС на языке Verilog (VHDL), не написав ни одной строчки кода?

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

Что объединяет частицу в воде, биржевой курс и кота Барсика, бродящего по району в поисках ларька с рыбой?

Всё это — примеры случайного блуждания. Эта простая модель из теории вероятностей помогает описывать самые разные явления: от диффузии молекул до принятия решений и работы алгоритмов. Она кажется интуитивной — но за ней скрывается множество нетривиальных и красивых свойств.

Мы начнём с истории открытия броуновского движения — от наблюдений Роберта Броуна до формулы Альберта Эйнштейна, которая связала наблюдаемое явление с атомной гипотезой. Покажем, как идея случайного движения превратилась из гипотезы в надёжный инструмент научного анализа.

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

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

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

Привет, Хабр! Я Настя, редактор YouGile — мы делаем систему управления проектами. Когда-то мы выяснили, что первыми закрываются компании, где ставится много задач. Теперь поговорим, реально ли работать над несколькими задачами одновременно и что об этом говорят исследования.

Каждый день мы тонем в потоке информации: статьи, заметки, идеи, детали проектов, важные задачи — всё перемешано между вкладками браузера, записями в телефоне и разными приложениями. Но когда что-то действительно нужно, найти это бывает непросто. Мы снова тратим время на поиски или начинаем с нуля.

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

Метод «Второй мозг» разработанный Тьяго Форте, представляет собой подход к управлению персональными знаниями, который помогает не только собирать информацию, но и эффективно ее использовать. Особенно интересно, что этот метод можно реализовать с помощью Telegram.

Telegram — это не только мессенджер. Его функциональности достаточно, чтобы превратить этот инструмент в полноценную систему управления знаниями. В статье я расскажу, как настроить «Второй мозг» внутри Telegram, приведу простые примеры и поделюсь практическими советами.

puts "ПЛИС-культ привет, FPGA / RTL / Verification ХАБ!"

Последние несколько месяцев я плотно сижу в Vivado и Tcl и вот решил с вами поделиться своими "открытиями" в области отладки Tcl скриптов, которые вероятно не многие из вас вообще пишут или используют в своей работе.

Несмотря на свою архаичность, Tool Command Language все же остается самым востребованным языком управления средой проектирования для ПЛИС и ASIC. ЕМНИП все эти инструменты управляются через Tcl, Vivado так уж точно, поэтому было бы не плохо научиться или хотя бы посмотреть какие инструменты отладки этих самых пресловутых Tcl-сценариев вообще существуют или существуют ли они вообще, кроме православного puts

В этой заметке, я постараюсь вам показать, что advanced tcl debugging - это не миф, а вполне реальная сущность, которая была создана еще на заре двухтысячных и не то что бы эта сущность как-то изменилась за эти 20 с небольшим лет.

Эта статья — краткая заметка о двух связанных друг с другом эмпирических правилах.

Поднимайте If вверх

Если внутри функции есть условие if, то подумайте, нельзя ли его переместить в вызывающую сторону:

// ХОРОШО

fn frobnicate(walrus: Walrus) {

... }

// ПЛОХО

fn frobnicate(walrus: Option<Walrus>) {

let walrus = match walrus {

Some(it) => it,

None => return,

};

...

}

В подобных примерах часто существуют предварительные условия: функция может проверять предусловие внутри и «ничего не делать», если оно не выполняется, или же может передать задачу проверки предварительного условия вызывающей её стороне, а при помощи типов (или assert) принудительно удовлетворить этому условию. Подъём проверок вверх, особенно в случае предварительных условий, может иметь лавинообразный эффект и привести к уменьшению общего количества проверок. Именно поэтому и возникло это правило.

Вот так учишь-учишь английский, думаешь, что ты все знаешь и на коне, а потом приходишь в IT-компанию после ВУЗа и осознаёшь, что, по сути, не знала ничего.

Какие открытия я сделала для себя в английском, когда начала делать первые шаги в technical writing и переводах 13 лет назад? Я тогда тщательно фиксировала всё интересное - и делюсь этим списком с вами. Кстати, он будет полезен не только тех. писателям, но и тестировщикам, аналитикам и вообще всем, кто пишет ТЗ, отчёты и test cases.

Мои последние тексты не случайно про софты. Это не просто модная тема для HR-брендов, а реально то, что решает: будет у тебя команда или “песочница по интересам”.

Я - фаундер проекта и живу им почти 24/7, управляю двумя командами - рекрутинг и продукт. У каждой - свой характер, задачи и темп. И за годы работы и линейником, и управленцем я понял главное: hard skills запускают, а soft skills удерживают. Особенно в шторм.

Теория по менеджменту хороша, но решает всё опыт и набитые “шишки”. Если вы только начинаете путь менеджера - вот концентрат того, что помогает не срываться, не терять команду и не утонуть самому.

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

Всем привет. Меня зовут Михаил и на данный момент времени я работаю тимлидом в крупной IT‑Компании.

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

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

Привет, Хабр! Меня зовут Катя, я лидирую Gramax, open source-платформу для управления технической документацией.

О Gramax мы писали ранее тут. В этой статье расскажу о Gramax Check — сервисе для автоматических проверок текста на базе LLM. По сути — нашей версии «Главреда», но с настраиваемыми правилами.

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

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

Просили нас тут рассказать про протокол технологию XHTTP в контексте XRay, VLESS и прочих. Просили — рассказываем!

Для начала немного истории. Классическое использование VLESS и подобных прокси‑протоколов (в том числе с использование XTLS‑Reality) предполагает подключение клиента напрямую к прокси‑серверу, который крутится на каком‑нибудь VPS. Однако во многих странах (и в России тоже) под блокировки (или замедления) начали попадать подсети популярных хостеров целиком, а в других странах цензоры начали отслеживать подключения к «одиночным» адресам с большим объемом трафика. Поэтому еще с давних времен обдумывались и проверялись идеи подключения к прокси‑серверам через CDN (сети доставки контента). Чаще всего для этого использовался websocket‑транспорт, но у этого варианта есть два больших недостатка: у него есть один характерный признак (не буду указывать его тут, чтобы не облегчать работу РКН), а во‑вторых, число CDN, которые поддерживают проксирование вебсокетов, не так уж велико, и хотелось бы иметь возможность проксироваться и через те, что не умеют.

Поэтому сначала в известном проекте Tor для бриджей (мостов) придумали транспорт meek, который позволял передавать данные с помощью многочисленные запросов‑ответов по HTTP, и таким образом позволял подключаться к мостам (прокси) через любые CDN. Чуть позже этот же транспорт реализовали в ненадолго воскресшем из мертвых V2Ray. Но у meek есть два очень существенных недостатка, которые вытекают из его принципа работы: скорость работы очень низкая (по сути дела у нас полудуплексная передача и огромный оверхед на постоянные запросы‑ответы), и из‑за огромного количества GET/POST‑запросов каждую секунду, бесплатные CDN довольно быстро могут нас выгнать на мороз, а платные — выкатить солидный счет.

Сжатие IPv4 заголовков C++ или как не потерять скорость связи с ограниченной пропускной способностью. В статье описано создание универсальной библиотеки сжатия ipv4 заголовков для повышения производительности сетевых систем. Наверное лучший способ "расширить" узкое горлышко при маршрутизации.