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

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

История о том, как за 6 лет я написал двухтомник, посвящённый искусственному интеллекту и машинному обучению

Давно замечаю, что подавляющее большинство менеджеров (продакты, маркетологи, growth-менеджеры) ограничиваются, в основном, одним статистическим методом — хи-квадратом (Chi-squared test) — что уже неплохо, но это только верхушка айсберга. Методов гораздо больше, и каждый из них может закрывать свои задачи.

Я долго искал, что могло бы стать готовым помощником для менеджеров, но ничего, что отвечало бы всем требованиям, так и не нашёл.

Поэтому собрал свой справочник с методами частотной аналитики. Старался сделать всё максимально просто: без формул, сложных терминов и заумных объяснений. Главное — чтобы было интуитивно понятно, какой метод выбрать и для какой задачи

Сценарное планирование - один из самых недооценённых и редко применяемых инструментов.

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

Ведь план - ничто, планирование - всё.

Самое важное, что характеризует любого менеджера — это то, как он выдерживает собственные обещания. Не то, как он их дает, а то, как выдерживает.

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

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

Это статья про базовый софтскилл который касается и менеджеров и исполнителей: про умение нести отвественность. Если вам интересна тема софтскиллов, читайте другие мои статьи на Хабре и подписывайтесь на мой ТГ канал «Морковка спереди, морковка сзади».

Доступ к файлам через отображение-в-память (mmap) — это способность некоторых операционных систем отобразить содержимое какого-либо файла в адресное пространство программы. Сама программа получает доступ к содержимому файла через указатели, как если бы сам файл был бы целиком загружен в оперативную память. Операционная система прозрачно загружает части файла в оперативную память, и автоматически выгружает их, когда памяти не хватает.

MMAP захватила умы программистов СУБД на многие десятилетия, как альтернатива буферу данных. И вот здесь следует отметить, что в mmap имеются серьёзные проблемы с корректностью и скоростью работы с данными в современных СУБД. В реальности, некоторые известные СУБД сперва использовали mmap для работы с "больше-чем-вмещается-в-память" базами данных, но вскоре обнаружили эти скрытые ограничения, которые принудили их к самостоятельному управлению файловым вводом/выводом, после заметных трат на инженерные исследования. В этом смысле mmap и СУБД подобны сочетанию кофе и острой пищи: неудачное сочетание, которое не очевидно, пока сам не попробуешь.

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

Цель проекта Boson — это разработка встроенного движка базы данных документов JSON, написанный на C++. Основные возможности: стандартное хранилище JSON-документов в формате ключ/значениями с постоянным хранением на диске. Размер документов до 4Gb. Быстрый поиск документов по ID с использованием индекса B+ дерева. Поддержка курсоров для линейного обхода записей. База данных в одном файле, без временных файлов. Простое, чистое и легкое в использовании API. Самодостаточный и не требующий настройки.

В предыдущих двух статьях мы прошли шаги от кэширования файлового ввода/вода (часть I) до построенного на его базе хранилища записей произвольной длины (часть II) с проверкой целостности, возможностью получения записей списком и повторным использованием свободного места. Теперь мы переходим к завершающей части и "сердцу" СУБД - индексу.

Зачем нужен индекс: предположим, что в базе есть 1 млрд не отсортированных записей документов, тогда поиск конкретного документа по ID потребует O(n) операций, то есть до 1 млрд операций в худшем случае. Однако, если бы документы в базе были бы отсортированы по ID, то поиск в сортированной базе, тем же бинарным поиском занял бы O(log n) занял бы 30 операций. Что, теоретически, на базе в 1 млрд записей будет в 33.3 млн раз быстрее.

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

Привет, Хабр!

Меня зовут Максим Ратников, я руковожу отделом системной верификации в компании Аквариус. Моя основная задача – убедиться, что все части микросхемы правильно собраны вместе и действительно функционируют так, как должны. Попутно работаю с теми стажерами в нашей компании, которые интересуются разработкой микросхем. Также преподаю в МАИ и рассказываю студентам про маршрут проектирования, элементы и узлы вычислительных машин. 

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

Когда где-либо заходит разговор про учебники по вычислительной технике и современным компьютерам и то, как это все работает, первое что вам скажут, скорее всего, будет классика как она есть – Эндрю Таненбаум «Архитектура ЭВМ». Версия чем свежее, тем лучше. Здоровенный том на 1000+ страниц, местами очень и очень непростой, но позволяет понять, как работает компьютер в целом.

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

Менее известный, но более радостный, факт: Есть нейронные сети, которые делают это быстрее (пусть и с меньшей точностью).

Споры про проектные нормы, их необходимость или ненужность, их реалистичность и сравнение между собой нанометров разных фабрик всегда были частью микроэлектронного коммьюнити. В России эти споры еще острее, потому что в ход идут доводы про импортозамещение, технологическую независимость и много других очень важных и умных слов. В этих разговорах, правда, постоянно упускается, что размеры транзисторов действительно критичны только для современных цифровых микропроцессоров, а вот для других классов микросхем, “где тонкие нормы не нужны”, техпроцесс должен обладать рядом других полезных свойств, помимо факта своего наличия, чтобы быть нужным и успешным. В разработку и обновление “устаревших” техпроцессов фабриками вкладываются существенные деньги, и более навороченный "толстый" техпроцесс – серьезный довод для разработчика уговаривать начальство сменить фабрику для нового проекта.

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

Привет, архитекторы, разработчики и неопределившиеся! Меня зовут Сергей Врунов. Я работаю в ВТБ и занимаюсь развитием ИТ-архитектуры. Все мы сталкиваемся с религиозными «архитектурными» дискуссиями и производственными конфликтами на ровном месте. Кажется, у вас есть классное решение или предложение, но почему оно так плохо заходит или вообще не заходит? Что делать? Какой профиль успеха архитектора?

Архитектурная психология! Читайте наш «Кодекс архитектора», создавайте на его основе свой и приносите пользу организации.

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

В детстве меня всегда завараживали игры с динамическим ландшафтом: The Castle и Worms Armageddon. В то время я не понимал, как реализована эта удивительная механика разрушения и изменения мира. Позже я узнал, что секрет заключался в использовании растровой графики, но интерес к теме не исчез. В этой статье я хочу рассказать о векторном решении аналогичной задачи.

Профилирование под Linux с помощью Performance Analyzer

Коллеги, считаю полезным рассказать об удобном и бесплатном профилировщике кода для Linux/Solaris. Он входит в пакет Sun/Oracle Developer Studio [1]. По моему мнению, другие части этой среды разработки несколько бесполезны, но профилировщик, который называется Performance Analyzer, очень удачный. Он прост в использовании, наглядно и удобно устроен анализ результатов. На мой взгляд, профилировщик все еще превосходит многие аналоги под Linux. При наличии этого инструмента использование gprof видится странной прихотью и потерей времени.

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

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

Есть в Айти стандартные грейды: Джун, Мидл, Синьор.

И всех руководителей ИТ проектов тоже можно разложить по этим уровням. Мне это помогает четче формулировать требования к сотруднику и куда ему дальше расти. Вам может помочь понять, что надо подтянуть, чтобы достичь нужного уровня, какие есть перспективы дальше. А если вы ищете РП – можете использовать для описания работы в вакансии 😊

Непричеметр (он же дисклеймер): эта статья – мое личное мнение, основанное на большом числе собеседований, которые я провел и прошел (суммарно больше 400). У меня нет статистических данных, я не проводил опросы и так далее. Зато почти каждый год на протяжении 20 лет я ходил по собеседованиям, последние 15 лет я собеседовал РП, а последние три года я непрерывно искал аналитиков и менеджеров, так что сформулировал четкие критерии отбора, которыми и хочу поделиться в статье ниже.

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

Посвящается тем немногим руководителям проектов, кто сумел найти способ получить полномочия и эффективно применять их для управления командой и стейкхолдерами.

Вторая часть описывает фазу "Официального Старта Проекта". В ней я также расскажу про поджидающие вас скрытые возможности, которыми также можно очень удачно воспользоваться. И которые (кто знает) возможно даже обернутся вполне приятными последствиями.