Одна из вечных тем в среде специалистов 1С, это тема "убийцы 1С". На мой взгляд, в основе этого лежит то, что никто не "любит" так платформу 1С, как мы, разработчики. Когда пользователи рассказывают мне о своих проблемах с 1С, я только тихо вздыхаю. Знали бы они, что такое настоящие проблемы с 1С! В этих условиях размышления о том, что это когда-то закончится становятся настоящей отдушиной. Но надо сказать, что размышления эти как правило бесплодны. Появляется на горизонте нечто, претендующее на статус "убийцы 1С", а после проверки оказывается, что разработчики предлагают нам не что-то принципиально новое, "переворачивающее доску", а примерно то же, что есть и сейчас. Все "убийство 1С" сводится к тому, что мы будем иметь все тоже самое, только профит будут получать другие ребята. Попробую предложить вашему вниманию нечто действительно новое.
Что происходит, когда мы отправляем сигнал приложению на node.js? Когда вызываются обработчики? А где хранятся? Во всем этом мы разберемся в данной статье, начиная от пользовательского кода на javascript и до встречи с операционной системой.
Недавно я поехал на море с другом. Во время пути мы узнали, что YouTube собираются блокировать (или замедлять). Тут в моей голове родилась идея: почему бы не сделать видеохостинг в Telegram? Я поспорил с другом, что сделаю его по дороге, но ноутбук сел. Поэтому мы договорились, что я сделаю это за день (спойлер: получилось, но кривовато).
По традиции делимся подборкой ярких ИБ-инцидентов прошедшего месяца. В августе успели случиться: кошмар для фанатов League of Legends, крупнейшая утечка в истории США, а также очередной сбой в работе Microsoft.
Сейчас довольно тяжело устроиться в IT, если ты новичок. Это уже ни для кого не секрет. Есть много историй, где люди годами ищут первую работу, откликаются на тысячи вакансий и даже не имеют шансов просто попасть на собеседование.
Все более популярным становится вариант с накруткой опыта. Так хотя бы есть шанс показать себя, пройти собеседование и получить заветный оффер. Конечно, это не было бы так популярно, если бы существовали другие, достаточно простые варианты без накрутки. Не каждый готов тратить много лет на обучение и наращивание какого-то плюс-минус релевантного опыта через бесплатные проекты для друзей и знакомых. В результате довольно много людей решаются на легкий путь. И далеко не все задумываются о последствиях.
В этой статье я не буду осуждать накрутку опыта и людей, решившихся на это. Я просто хочу рассказать одну реальную историю, которую наблюдал своими глазами, а затем проанализировать случившееся и сделать выводы.
Автоматизация работы с JSON в Swift с помощью Codable
Когда вы работаете с данными в Swift, особенно при взаимодействии с API, вам часто приходится разбирать JSON-ответы и преобразовывать их в структуры данных. Это может быть утомительной и повторяющейся задачей, особенно если у вас есть сложные или вложенные JSON-структуры. Для решения этой проблемы в Swift существует мощная и удобная библиотека — Codable.
Для чего нужна система сохранений?
Какие задачи решает система сохранений?
Какие процессы происходят внутри?
Как реализовать систему программно?
Какие варианты реализаций существуют?
Как обеспечить гибкость и масштабируемость?
Зачем и когда нужны гибкость и масштабируемость?
Эта обзорная статья расскажет какие есть прехватчики трафика среди десктопных и мобильных приложений, о доступности и преимуществах решений, а также что мы можем сделать хорошего для проекта с помощью снифферов.
Давайте узнаем, как хватать и чем траффик.
Частенько пользуюсь CAN-Hacker'ом. Ну и как ожидаемый результат, понадобилось проверить свою(и) теорию(и) в машине а не на столе, по быстренькому. По быстренькому не получилось, далее история.
В наличии имеется пакет кан-бриджей с известного Али-базара
add rax, rbx соответствует симкоманда rax += rbx.next()!
На написание и публикацию этого текста меня побудила необходимость быстро объяснить, как определять текст от больших языковых моделей (БЯМ). Важно, что речь идёт только про выявление очевидных случаев, а не бронебойное детектирование.
В голове инструкция выглядела как три коротких пункта. Списочек немедленно разросся обширным введением, замечаниями и примерами. Грех этой инструкцией не поделиться.
Каждый раз, когда начинаешь новый проект, никогда не знаешь, какие сюрпризы он может принести. На первый взгляд, простая задача по настройке Google Формы может превратиться в увлекательное путешествие с неожиданными поворотами. Сегодня я хочу рассказать вам историю одного такого заказа, в котором мы не только справились с вызовами, но и нашли оригинальное решение.
Обработка потоковых данных стала крайне важна в настоящее время. И на это есть веские причины, такие как:
Компании жаждут получать данный как можно быстрее, и переход на потоковую обработку будет хорошим способом уменьшить задержки.
Объемные неограниченные наборы данных, все чаще встречающиеся в современных бизнес процессах, могут быть легче обузданы применением систем, специально спроектированных для таких объемов информации
Обработка данных по мере их поступления распределяет нагрузку более равномерно по времени, приводя с стабильному и предсказуемому потреблению вычислительных ресурсов.
Несмотря на существенный интерес к потоковой обработке данных со стороны бизнеса, львиная доля таких систем оставалась относительно незрелой по сравнению с аналогичными системами, ориентированными на пакетную обработку данных, так что это привело к недавнему всплеску вдохновляющих разработок в этой сфере.
Как тот, кто работал над крупно‑масштабной системой потоковой обработки в Google на протяжении последний пяти с лишним лет (MillWheel, Cloud Dataflow), я, мягко говоря, в восторге от сложившихся тенденций. Я все также заинтересован в том, чтобы люди понимали, что именно системы потоковой обработки в состоянии выполнять, и как их использовать наилучшим образом, в частности, закрыв нехватку знаний, оставшуюся между существующими системами пакетной обработки и потоковыми. С этой целью замечательные ребята из O»Reilly пригласили меня предоставить письменную версию моего доклада «Say Goodbye to Batch» с конференции Strata + Hadoop World London 2015.
Основная задача любой операционной системы - предоставить приложениям возможность унифицированного способа доступа к ресурсам оборудования, а пользователю - запускать и останавливать работающие приложения.
Murmulator OS (далее MOS) не является исключением. Как намекает название, данная ОС разработана для Murmulator https://github.com/AlexEkb4ever/MURMULATOR_classical_scheme (далее просто Мурмулятор), который основан на ультрабюджетной плате Raspberry Pi Pico (процессор-микроконтроллер RP2040) + специальная плата расширения, подробнее про которую можно почитать на сайте https://murmulator.ru. Таким образом, Murmulator - полноценный ультрадешевый (бюджетная версия которого обходится не дороже $5) микрокомпьютер.
В ранние годы развития компьютеров программисты могли лишь мечтать о портируемости. Все программы писались непосредственно в машинном коде для каждой компьютерной архитектуры, на которой они должны были работать. Языки ассемблера с мнемоническими именами каждой команды CPU и другие удобства сильно упростили жизнь программистов, но программы по-прежнему были привязаны к архитектуре. Тогда ещё не изобрели операционных систем, поэтому программа не только управляла всей компьютерной системой, но и должна была инициализировать всю периферию, а также управлять ею. На самом деле, такие низкоуровневые программы реализовывали драйверы для каждого используемого ими устройства. И каждый раз, когда программу нужно было перенести на оборудование с другой архитектурой, она в буквальном смысле переписывалась с учётом различий архитектуры набора команд CPU, структуры памяти и так далее.
Именно так произошло с Unix, который изначально был написан Кеном Томпсоном на языке ассемблера более пятидесяти лет назад. Первые версии Unix писались для платформы PDP-7, а для портирования его на PDP-11 нужно было переписывать код. Когда Дэннис Ритчи создал язык программирования C, и вместе с Томпсоном они переписали на нём основную часть кода Unix, внезапно оказалась возможной портируемость ПО. Тому были две главные причины. Во-первых, код, написанный на языке высокого уровня, не зависит от платформы, потому что компиляторы транслируют его в язык ассемблера целевой архитектуры. Это ещё важнее для целевых платформ на основе процессоров RISC, так как они требуют написания гораздо большего количества ассемблерных команд, чем процессоры CISC. Даже при портировании Unix на другую платформу основная сложность заключалась лишь в адаптации зависящих от архитектуры частей кода. С другой стороны, сама операционная система абстрагирует все особенности оборудования от пользовательской программы.
Программистам не нужно реализовывать многозадачность, управление памятью и драйверы для используемых ими устройств, потому что всё это часть ядра ОС и работает в адресном пространстве ядра. Пользовательские программы работают в пользовательском адресном пространстве и получают доступ ко всем предоставляемым ОС функциям при помощи интерфейса системных вызовов. В ОС реального времени, например, в Zephyr OS ситуация немного отличается, но принцип изоляции и защиты памяти для пользовательских программ сохраняется. Это приводит к двум выводам:
Сегодня я собираюсь продолжить рассказ про свой 3D рендер в командной строке Windows и разобрать те темы, которых не коснулся в 1 Части.
На этот раз в статье будет больше кода и меньше математики (а также много скриншотов).
13 августа стартовал 13-й игровой джем js13kGames (JS13K) для разработчиков веб-игр на JavaScript. За месяц участникам предстоит написать браузерные игры, размер которых не должен превышать 13 килобайт при сжатии до формата ZIP. Темой JS13K этого года выбрали «Трискайдекафобию» — боязнь числа «13».
