Это Теория симуляции, над которой я работаю уже какое-то время. Решил поделиться своими фантазиями, чтобы позабавить вас. Я строитель, без высшего образования, так что не ждите дифференциальных уравнений...
Все началось с Тихо Браге, который провел свою жизнь в DDoS атаках на Солнечную систему... добытые данные аккуратно помещал в таблицы.
Приехал ко мне брат. Отдохнуть, повидать родственников, посмотреть на родной город. А ему на машине заднее стекло разбили. Прямо во дворе нашего дома. Неприятно.
Вдохновившись парой статей на Хабре, посвященных созданию блокчейна на коленке, я и сам решил ввязаться во все это, написав блокчейн на C#. Если вам интересно, что получилось, добро пожаловать.
Работая с типовыми клиентскими задачами, мы в CreativePeople достаточно быстро столкнулись с ограничениями Google Analytics (версия Universal Analytics), которые не позволяли нам решать их качественно. Чтобы их решить, нам пришлось изменить подход к сбору данных.
Дисклеймер: Эта публикация скорее крик души... я не буду говорить, что являюсь выдающимся экспертом в базах данных, а тема данного поста не для того, чтобы мериться размером дампа. Мне просто больно раз за разом слушать на комитетах о русскоязычных кандидатах, что он нам не подходит потому что...
Очень много ресурсов можно найти на просторах интернетов на тему собеседования Software Engineer'ов в FAANG, куча теоретического материала, список готовых задач с интервью, как готовится к System Design вопросам и т.п., но лично для меня было огромной болью искать что-то, чтобы быть готовым к интервью на роль Database Engineer. Проблема в основном в том, что разброс вопросов по этой теме невероятно огромный. Отмечу, что это касается именно FAANG компаний, потому что на собеседовании туда Вас, как SWE / SRE, не будут просить "написать синглтон" или спрашивать в чем проблема многопоточности в питоне, всё довольно прозаично в подготовке на эти роли.
Поэтому хотелось бы немного осветить, на чем проваливается большинство русскоязычных кандидатов.
Звук в кино — неотъемлемая часть повествования. В полней мере задумку режиссера помогают раскрыть системы объемного звучания. Сегодня мы подготовили компактную подборку фильмов, сцены которых помогут оценить возможности аудиосистемы домашнего кинотеатра [например, в шоуруме перед покупкой].
Авторы картин собрали большую команду саунд-дизайнеров и использовали интересные эффекты, поэтому их работы заслуживают внимания. [Ссылки на отрывки мы поставили, конечно же, для удобства поиска контента и наглядности.]
Согласитесь, что название статьи звучит немного странно. Зачем же избавляться от этих милых, слегка занудных, но в основном весьма безобидных людей?
Как их только не называют: техписы, техрайтеры, документаторы... Хорошо, хоть не архивариусы!
Если мы избавимся от технических писателей, кто же будет разрабатывать пользовательскую документацию на наши системы и приложения? Да и зачем лишать работы профессионалов, которые могут грамотно и понятно описывать всё, что было спроектировано и запрограммировано, каким бы сложным оно не было?
— Кто за сутки до отправки заказчику во всей инструкции заменил manual на manul?!
Пару лет назад я пришел к выводу, что нынешний общественный строй в технически развитых странах нужно называть бюрократическим социализмом. Но человечество развивается стремительно; социализм утвердился не так давно, а в нем уже проявляются черты следующей общественной формации. Ее предвидели 80 лет назад и назвали «информационным обществом». Сейчас я попытаюсь на базе классового подхода обрисовать его сущность и основные проблемы.
В этой статье я собрал обобщающую информацию по некоторым программным эмуляторам советских компьютерных систем - начиная от больших ЭВМ типа БЭСМ-6 и заканчивая микропроцессорными электронными играми.
Ниже я попробую обобщить сведения об имеющихся эмуляторов, сделаю небольшие описания и дам ссылки на сами эмуляторы и многочисленные форумы, где есть их описание. Все написанные эмуляторы описать сложно, и я остановлюсь только на самых интересных или значимых.
Почему хаос и фракталы так тесно связаны с криптографией? Предлагаю разобраться с этим на примере нового алгоритма хаотического шифрования изображений с помощью особых фрактальных матриц.
У Flutter есть серьёзный логический нюанс, который можно упустить, а это может привести к слабому качеству продукта. State management Как? Когда? Почему? Каким способом? Лучше всего изменять состояние виджета? Сейчас можно увидеть большое кол-во различных библиотек и подходов для решения данной задачи. Нюанс настолько большой, что библиотеки, которые помогают с управлением состояний становятся Архитектурными подходами, паттернами, а статей про то какой подход лучше еще больше. Данное решение подойдет к любому проекту, ему не нужна библиотека и вовсе не обязательно использовать данный виджет.
И снова здравствуйте!
Первая часть. Обзор Рынка
Вторая часть. Внешние и внутренние противоречия
Третья часть. Основные действующие лица
Итак, на данный момент мы рассмотрели телеком рынок России, выявили основные тенденции его развития, а также обозначили главных действующих субъектов. Теперь пришло время чуть пристальнее посмотреть на предмет локализации – сам конечный продукт с технической точки зрения.
Что из себя представляют базовые станции 5G, какова их роль в сетях связи, каковы основные компоненты и кто их производит, какие технологические вызовы будут стоять перед новым производителем, который решит войти на этот рынок? Давайте попробуем разобраться!
Как обычно - буду рад конструктивной критике, обратной связи и дискуссии. На базе Ваших предложений – сможем «углУбить и расшИрить» материал!
Сейчас мне сорок пять, и я наконец получил нормальную фултайм позицию аналитика данных. У меня первый диплом - Провизор по специальности Фармация. Я успел поработать таксистом, разнорабочим на складе лекарственных трав, заготовщиком, владельцем цеха металлообработки и одновременно рабочим в этом цеху. Был фармацевтом за кассой, заместителем заведующей аптекой, владельцем аптеки. Никогда не думал, что буду работать в IT, хотя всегда интересовался этой темой.
По договоренности с Райффайзенбанком, турнир должен был состоять из двух частей: отборочного тура и финала. Для отборочного тура планировалось выделить 6 задач, которые публиковались бы в течение трех месяцев. Результат решения этих задач служил бы допуском к финалу. Вторая, основная часть по задумке должна была выглядеть как один из турниров, которые проводились на braingames более восьми лет назад: турнирные задачи размещаются одновременно, ответы можно отправлять в течение отведенного времени, а жюри не сообщает, верно ли решена задача.
Первая проблема, с которой мы столкнулись, - это дефицит разнородных интересных задач в очереди на публикацию. Искать нужно было там, ведь все задачи отборочного тура останутся на сайте, когда турнир закончится. Поэтому они должны проходить по текущим критериям отбора на сайт: набирать нужный перевес голосов за публикацию среди модераторов, иметь окончательное условие и хорошо разобранное решение. Целью отборочного тура было, прежде всего, привлечь как можно больше участников к главному мероприятию. Мы делали ставку на то, что отборочные задачи будут решать активнее, чем обычные. Поэтому важно было соблюсти еще 2 критерия: отборочные задачи должны быть не слишком сложными, но и не слишком устными, при этом достаточно интересными. Формулировка должна цеплять своей доступностью и в то же время провоцировать игрока на быстрый поиск решения, а потом обескураживать тем, что результат, оказывается, еще можно улучшить. На самом деле, мы всегда стараемся публиковать именно такие задачи, но сейчас нужны были самые интересные из них. А чтобы гарантировать равные условия всем участникам, нужно было отсеять задачи, которые уже "светились" за пределами модераторской части форума. Так была забракована очень хорошая задача про развертку куба, которая уже находилась в разделе "Отбор", доступном VIP-игрокам. Она примечательна тем, что эталонный ответ держался несколько лет, после чего результат смог улучшить один из пользователей, чем сильно удивил модераторский коллектив.
Промышленное проектирование алгоритмов для бюджетных микроконтроллеров, как правило, учитывает время выполнения критических участков программы.
Ожидаемое время выполнения машинной команды на процессорах с архитектурой RISC — один такт. Так же очевидно, что даже простейшие операторы языка "C", после перевода в двоичный, машинный код, требуют больше времени, чем один такт.
Вопрос: "Больше, чем один такт" — это сколько?
Когда речь заходит про права доступа в приложении, то из этой ситуации появляется два результата:
Либо в коде приложения появляются привязки к неким ролям/scope’ам;
Либо разработчик обрастает бородой и начинает сыпать фразами вроде abaс, xacml и матрица доступа;
Если вам интересно как можно из подручных средств собрать RBAC на любой сервис соблюдающий REST, то добро пожаловать.
Каждый, кто когда-либо пробовал собрать программу на C/C++ через кросс-компиляцию знает, насколько болезненным может быть этот процесс. Главными причинами столь печального положения вещей являются недружелюбность систем сборки при конфигурации кросс-компиляции, а также запутанность процесса настройки набора утилит (тулчейна).
Одним из основных виновников этих проблем, по моему опыту, является тулчейн GNU — древний мамонт, на котором много десятилетий строится весь мир POSIX. Подобно многим компиляторам былых времён, семейство GCC и binutils никогда не ориентировалось на поддержку множества различных целей сборки в одной установке, и единственным способом хоть как-то добиться желаемого была настройка полной кросс-билд-системы для каждой целевой платформы на каждом хосте.
