Когда на работе я присоединялся к новой команде, мне потребовалось некоторое время, чтобы подумать о том, какой вклад я хочу внести в команду. Очевидно, что некоторые пункты будут зависеть от контекста команды, в которой я работаю, но я решил поделиться с вами своими принципами качества. Сейчас именно они определяют мой подход к качеству и тестированию.
Существует множество мнений о возможности применения ООП подходов и паттернов в Rust. Кто-то считает, что полноценного ООП в Rust нет и быть не может. Другие разработчики, наоборот, высказывают мнение, что элементы языка позволяют использовать приёмы из ООП именно так, как их видели создатели этой парадигмы.
В данной статье я постараюсь продемонстрировать, какие идеи и принципы из ООП позволяет реализовать Rust, и как это работает на простых примерах.
В связи с тенденцией перехода организаций, практикующих системную инженерию, к так называемой "системной инженерии на основе моделей" (MBSE), существуют различные точки зрения по поводу того, что подразумевается под MBSE. Подобно тому, как в старой притче о слепцах и слоне, MBSE не может быть эффективно применена на практике, если рассматривать ее только с одной точки зрения (требования, модели, шаблоны, стандарты, профильное приложение и т.д.). Чтобы успешно применять MBSE на практике, грамотные системные инженеры определяют и используют каждую из перспектив в соответствии со своими специфическими потребностями. Исходя из этих запросов, они выбирают соответствующие возможности, инструменты и визуализации, которые удовлетворят их требования. Универсального решения не существует.
Это не так. PHP не умер. Он жив, и до “конца жизни” ему еще очень далеко. На этом все. Как бы некоторые ни хотели, чтобы он исчез, этого не произойдет. По крайней мере, в обозримом будущем уж точно.
Каждому из вас наверняка знакома ситуация, когда через полгода работы над проектом команды из нескольких человек, вы внезапно обнаруживаете, что в разных частях проекта используется разные правила оформления кода, тесты написаны, но отчеты по ним не собираются и не анализируются, в виджетах встречается бизнес-логика и вычислительно сложные задачи вызываются непосредственно в методе build. Кроме этого появились гигантские классы и методы, в коде избыточно много использования типа dynamic или в функциях отсутствует тип возвращаемого результата. И у вас возникает желание открутить маховик времени в начало проекта и сделать все необходимое, чтобы вероятность возникновения такого хаоса была минимальной. В этой статье мы рассмотрим некоторые удобные механизмы анализа кода и результатов тестов для Flutter.
Привет от Technology Enthusiast! Сегодня речь пойдет о сервисах интеграции данных, их функциональных возможностях и ограничениях. Рассмотрение будем вести на примере сервиса myBI Connect, опираясь на который я реализовал с десяток аналитических проектов за последние несколько лет.
Отмечу, что с конца февраля ребята сделали значительные шаги в сторону развития отказоустойчивости и масштабируемости своего решения. Заглядывайте под кат, если стоите перед выбором коннектора или хотите выжимать максимум из доступного:
• Требования и ожидаемые результаты
• Функциональные возможности
• Сценарии использования и бизнес-ценность
• Планы развития, продвинутое моделирование и BI
За то время, что я работаю PHP-разработчиком, способ написания и доставки кода сильно изменился. В ранних приложениях Symfony и Zend Framework группы PHP-FIG не существовало, а стандарты кодирования определялись на усмотрение того, кто их писал. На протяжении тех лет, когда мы наблюдали широкое распространение стандартов PSR, надежные инструменты статического анализа были несколько разрозненными. Так было до настоящего времени, пока не вышла версия 1.0 PHPStan. Давайте отметим это событие, ознакомившись с некоторыми ее возможностями.
Сколько раз, приходя в новую компанию, вы получали в руки “большой комок грязи“, к которому каким-то образом нужно прикручивать новый функционал?
Без документации.
Без контроля версий.
Без какой-либо надежды на душевное равновесие в будущем.
Мы продолжаем нашу серию статей, связанных с байесовскими методами, один из которых — Байесовские Сети Доверия (БСД). Теоретическую основу БСД вы можете найти в этой статье.
В этой статье мы сначала вкратце вспомним теорию. Дальше будет, что называется, только хардкор: на примере данных “Титаника” мы будем строить БСД.
Статья расскажет о практическом аспекте при использовании инструментария, который позволяет производить исследование программного обеспечения с минимальным порогом вхождения и максимальной информативностью. Рассмотрим следующие инструменты:
• эмуляторы
• библиотеки для разбора форматов файлов
• интерактивные дизассемблеры
• документация
• динамическая инструментация
Сравним коллекции Java по следующим параметрам:
На чем основана — какая структура данных или коллекция используется под капотом.
Дубли — разрешены или нет в коллекции повторяющиеся значения.
Null — позволяет ли коллекция вставлять null.
Синхронизированность — все ли методы коллекции синхронизированы.
Потокобезопасность — безопасно ли использовать коллекцию в многопоточной среде.
Тип итератора — поведение итератора в многопоточной среде.
Чтобы помочь вам найти лучшее программное обеспечение, мы расскажем об основах программ отслеживания проблем, включая их преимущества, особенности и то, как выбрать лучшую программу для вашей команды. Также поделимся списком из 15 лучших программ для отслеживания проблем.
В этом посте раскрывается эксплойт CVE-2022-27666, уязвимость, позволяющая добиться локального повышения привилегий на последней версии Ubuntu Desktop 21.10. Изначально мы приберегли ее для pwn2own 2022, но она была пропатчена за 2 месяца до начала конкурса. Поэтому было решено обнародовать наш эксплойт и опубликовать PoC в конце поста.
Наше первичное исследование показало, что эта уязвимость затрагивает последние версии Ubuntu, Fedora и Debian. Наш эксплойт был создан для атаки на Ubuntu Desktop 21.10 (последняя версия на момент написания эксплойта).
В данной статье я постараюсь подробно рассказать о том, как написать небольшую игру, используя в качестве инструментов язык программирования Rust и библиотеку macroquad.
Итак, Вы работаете с Большими Данными:
– Обработка этих данных требует значительного времени (и затрат 💰).
– Исторические данные не меняются (или не должны меняться) - как правило, это свершившиеся факты.
– Если Вам удается не делать повторную обработку исторических данных - Вы экономите время и затраты.
Технологии контейнеризации в последние годы получили широкое распространение и наиболее известным решением по управлению контейнерами по праву считается Kubernetes, или, сокращенно, K8s. Kubernetes это система автоматизации развертывания и масштабирования контейнеризированных приложений и управления ими. Данная система построена на базе программного обеспечения с открытым исходным кодом. Изначально решение разрабатывалось специалистами Google, начиная с 2014 года и предназначалось для решения внутренних задач корпорации. Однако, впоследствии Kubernetes стал решением Open-Source и получили широкое распространение по всему миру.
Kubernetes, как система управления кластерами из контейнеров, является динамическим решением, которое позволяет в режиме реального времени реагировать на события, оживлять “упавшие” сервисы и масштабироваться по запросу. Особенно преимущества Kubernetes в части живучести оценили разработчики. В качестве примера можно привести историю, когда у помещенного в контейнеры приложения начала “течь” память. Однако, разработчики узнали об этом только через несколько месяцев, когда заинтересовались, логами приложения. А все это время Kubernetes исправно следил за контейнерами с этими приложениями и в случае их “подвисания” тут же рестартовал их. Так что живучесть контейнеризированным приложениям данная система обеспечивает на “отлично”.
В целом, K8s можно назвать стандартом для современных DevOps-сред в организациях различного уровня. Например, Kubernetes используется в таких облачных сервисах, как: AWS, Microsoft Azure или Google Cloud.
В этом туториале описан алгоритм поиска в глубину (depth first search, DFS) с псевдокодом и примерами. Кроме того, расписаны способы реализации поиска в глубину в C, Java, Python и C++.
“Поиск в глубину” или “обход в глубину” — это рекурсивный алгоритм по поиску всех вершин графа или дерева. Обход подразумевает под собой посещение всех вершин графа.
Разрабатывая новые продукты, мы зачастую выводим нашу операционную систему — Linux — за рамки общепринятых возможностей. Распространенной темой было использование eBPF для создания технологии, которая в противном случае потребовала бы модификации ядра. Например, мы создали систему защиты от DDoS и балансировщик нагрузки и используем ее для мониторинга нашего серверного парка.
Это вторая статья из серии статей о стратегии платформ. Ознакомиться с первой статьей можно по этой ссылке.
Предыдущая статья была посвящена проблеме, которую стратегия платформы призвана решать, и преимуществам для вашей платформы от определения границ программного обеспечения, основываясь на бизнесе, для которого оно разрабатывается.
В этой же статье я подробно расскажу о двух широких категориях возможностей платформы, поделюсь некоторыми подходами к определению этих границ и приведу несколько примеров.
