Я не понимаю, как на это реагировать. Некий товарищ полгода спрашивает у меня советы как начать с Verilog/FPGA/ASIC, но при этом ничего не начинает, хотя его вопросы становятся все более экзотическими. Чтобы было понятнее, опишу как бы это выглядело для программирования. Предположим к вам пришел молодой человек и спрашивает как научиться программировать. Вы ему говорите что-нибудь типа:

"Сесть за компьютер, написать и запустить программу Hello, world. Одновременно скачать книжку с описанием языка и базовых приемов и читать ее в общественном транспорте, перед сном и в приемной у зубного врача. Периодически садиться за компьютер, написать и отладить программы: сортировки массива, игры Жизнь, ханойских башень итд. С выводом на текстовый терминал, окно в GUI или веб-страницу - по вкусу. Далее вы поймете в какую сторону копать или не идти в это дело вообще."

Молодой человек вас горячо благодарит и уверяет как он сильно хочет стать настоящим программистом. Потом он Hello, world не пишет и никакой книжки читать не начинает, но последовательно спрашивает у вас:

Это перевод одной из глав книги Game programming patterns Роберта Найстрома. Так как книга по сути состоит из подробного описания шаблонов проектирования, каждая глава может рассматриваться как самостоятельная статья, чем я и воспользовался и перевел, как мне кажется, статью с самым важным паттерном в игростроении — Game loop.

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

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

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

Файловая система xv6 предлагает Unix-подобные файлы, директории и пути и хранит данные на virtio-диске.

Глава расскажет, какие задачи решает файловая система xv6.

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

В далеком 2002 году, когда многие из нас еще тусовались на IRC и мечтали о широкополосном интернете, Нитеш Чавла и его команда представили миру SMOTE. Этот алгоритн решал реальную и больную проблему — несбалансированность классов в обучающих данных.

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

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

Привет, Хабр! Меня зовут Николай, я разработчик С++ в SimbirSoft. В этой статье я хочу поделиться своим опытом применения алгоритмов. 

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

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

Прежде чем перейти к примерам, необходимо отметить основное преимущество алгоритмов: они позволяют упростить код и повысить читаемость (или самодокументирование, которое позволяет на основании названия алгоритма понять, что делается), обобщить код. Начиная с C++17, алгоритмы могут выполняться параллельно, реализация алгоритма может быть жестко с оптимизирована компилятором по сравнением с обычным кодом.

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

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

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

В процессе разработки почти любого приложения необходим удобный механизм по работе с данными из БД. В данной статье речь пойдет о таком расширении для СMS Bitrix, как alexpr94/bitrix-models, устанавливающийся с помощью пакетного менеджера composer.

Данный пакет привносит слой модели(Model Layer) и позволяет сгенерировать классы моделей для основных сущностей CMS Bitrix, таких как инфоблоки, разделы инфоблоков, highload-блоки и пользователи.

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

В результате Вам предоставляется возможность использовать встроенную в редактор кода(IDE) систему подсказкок возможных полей и свойств класса.

Информационная безопасность (ИБ) или кибербезопасность – это одна из самых важных и актуальныхобластей современной науки и технологий. В условиях постоянного развития интернета, киберпреступности и глобальной информатизации, специалисты по информационной безопасности востребованы как никогда. 

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

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

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

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

Всем привет!

Пришла, значит, мне в голову идея - сделать свою игру по типу Vampire Survivors и Brotato, а потом я подумал, что можно еще и цикл статей написать про то, как я ее разрабатываю, вдруг кому-то это покажется полезным (ну или хотя бы смешным).

Ну, собственно, вот - первая часть. В ней я покажу, как я создал персонажа и научил его бегать.

Вероятно, вы уже слышали о соревновании под названием "The One Billion Row Challenge" (1brc), если же нет, то предлагаю ознакомиться с репозиторием 1brc Гуннара Морлинга.

Моё участие в проекте было мотивировано присутствием в нём двух моих коллег, которые достигли лидирующих позиций.

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

Решил потренироваться на ассемблере под x86 и выбор мой пал на KolibryOS. Ведь как-никак это ОС была написана на ассемблере и для использования ассемблера. И я хотел именно из самой KolibriOS писать код. Но... Наверное, зря я это всё затеял.

Как оказалось, примеров кода не мало и не много. А так как я привык к Dos, Windows или Linux, то и ожидал что-нибудь в этом роде. Код, код и ещё раз код. Макросы не так часто встречаются. Ну и уж точно не весь код из одних макросов (утрирую).

Пример кода из «официального источника» вносит больше сумятицы, чем понимания, что происходит в данном коде. И... там нет никакого объяснения этим «буквенным значениям». Есть только то, что ссылаются на файл «macros.inc». Если просматривать источники интернета, то где‑то более понятно написано и даже рассказывают, что взять «macros.inc» (и многие другие файлы можно на SVN KolibriOS и, как оказалось, ещё можно на GitHub (дублируется?).

Покопавшись в файле «macros.inc», а так же на просторах интернета и найдя пример (смотрите код Fasm), я понял, что всё становится на свои места и более‑менее проясняется.

Tiny Core Linux около 15 лет, и он до сих пор актуален, обновляется и модифицируется своими авторами. Правда, с момента выхода версии 1.2 он немного «поправился» — сейчас его объём составляет 24 Мб вместо 10 Мб. Но всё равно это исчезающе малый «вес» по сравнению с другими дистрибутивами и операционными системами, хоть современными, хоть не очень. Подробности о новой версии — под катом.

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

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

Эти советы универсальны, они никак не касаются типа разработки. Чек‑лист скорее направлен на сбор информации и материалов, которые позволят создать конверсионный ресурс и отразить в нем необходимые ценности и миссии бренда. Теперь обо всем по порядку.

Я думаю, что вы не раз уже гуглили, заглядывали в статьи, манифесты IT-гигантов о лучших практиках проектирования API. Я тоже.

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

Я работаю тимлидом направления системного анализа в X5Tech и за все время развития карьеры сталкивалась с большим количеством кейсов проектирования Web систем. IT продукты в большинстве очень динамичны: постоянно изменяются требования, появляются новые, итеративно улучшается пользовательский опыт (по принципу 20% усилий на 80% результата, а остальное доделаем потом).

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

В этой статье предлагаю спроектировать контракт по шагам, и на каждом из них я расскажу про общие рекомендации из копилочки “Полезное”, а также про личные правила и практики, полученные долгим опытом работы над постоянно меняющимися ИТ-продуктами, которые помогут для “дальновидного” проектирования GET REST API.

В основном я учился программированию самостоятельно. Когда у меня появлялась захватывающая идея, я разбирался, что необходимо для решения этой задачи. Например, когда я заинтересовался работой поисковых движков, то начал читать о вычислительной эффективности множеств. Так я обнаружил задачу «как понять, что я уже выполнил краулинг этого URL?», если их уже были тысячи. Чтобы ускорить ответ на этот вопрос, я использовал множество, поиск по которому занимает O(1), а не O(n).

Изучение того, что нужно для решения задачи, увлекательно, но при движении по собственному пути в кодинге в твоих знаниях остаются пробелы. Мне кажется, что если постоянно ставить перед собой сложные задачи, то эти пробелы будут заполняться по ходу. (Даже если это займёт больше времени, чем при прохождении курса. Интерес — важный мотиватор движения вперёд; стремитесь к тому, что любопытно вам.)

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

Я решил составить собственный список проектов, поддерживающих мой интерес к программированию. Это список в стиле серии Challenging projects every programmer should try Остина Хенли.

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