В данной статье речь пойдет про использование очень маленькой Luckfox Pico Mini. Я расскажу про особенности платы, её настройку, а также о том как запускать на ней нейронные сети для детекции объектов с камеры.
Мне удалось добиться скорости детекции в 15 FPS (или даже 50!), результат, который по силам далеко не каждому одноплатнику.
В документации по UIKit компании Apple можно найти объяснение, что “структура приложений основана на шаблоне проектирования Model-View-Controller (MVC)”.
В материалах Apple по SwiftUI объяснений и даже просто ссылок на паттерны проектирования, похоже, нет. Попробуем сначала разобраться почему. Далее рассмотрим логичные и простые решения для построения как отдельных компонентов, так и уровень приложения с использованием состояний и property wrappers; подход, который логично обозначить как State-Model-View.
Начать статью хочу с цитаты из слов Брайана Кернигана,которую мне посчастливилось найти:
Tcl/Tk придает работе магическую продуктивность, за несколько часов можно достигнуть тех же результатов, что за дни или недели при разработке на C или C++... Tk весьма эффективен для большинства приложений, многие элементы интерфейса (виджеты) реализованы настолько хорошо, что остается только удивляться, как подобная работа могла быть выполнена так качественно... Удачным кажется и то, что разделение задач между Тсl и С/С++ осуществляется достаточно легко, надо только знать, какой инструмент лучше справляется с задачей... Расширение системы дополнительным Tcl-кодом, загружаемым напрямую в Tcl-библиотеку приложения, в полном согласии с оригинальной идеей Остераута, повышает эффективность программы, в целом, упрощает ее структуру и улучшает мобильность... Я не уверен, что Тсl мог бы выжить как самостоятельный продукт - у него слишком много конкурентов. Но у сочетания Tcl/Tk в Unix-мире нет конкурентов... Система исключительно надежна, очень хорошо документирована... свободно доступна... безукоризненно высокого качества
Всем привет, это Денис Вебер.
Герои 3 - это одна из моих любимых игр детства и король пошаговых стратегий. Очередной раз играя в Героев я подумал, а как бы мог выглядеть замок из игры в 3д. Всё, что у меня было - это скриншот не самого лучшего качества. О том получилось ли у меня что-то я расскажу вам в этом видео.
Если вам больше нравится формат видео, ссылку на ролик я оставлю в конце статьи.
Многие из вас, я уверен, слышали о теории игр в какой-то момент своей жизни. Если вы хотите выглядеть умным и произвести впечатление на свою девушку — просто упомяните «игру с нулевой суммой» или «эволюционную стратегию», и ваши шансы отвести её домой сегодня вечером только что подскочили на 50%. Или вы можете использовать теорию игр, чтобы принимать решения в инвестировании своих денег (чтобы их полностью потерять и разориться) или, например решая, на какой девушке жениться (что также очень вероятно вас разорит). Как видите, это очень полезная теория.
Чтобы казаться умным - достаточно выучить эти пару выражений, но чтобы на самом деле что-то понимать - придется разобраться. Оказывается, это не так уж сложно и довольно интересно. Давайте посмотрим.
Если, открывая холодильник вы еще не слышали из него про RAG, то наверняка скоро услышите. Однако, в сети на удивление мало полных гайдов, учитывающих все тонкости (оценка релевантности, борьба с галлюцинациями и т.д.) а не обрывочных кусков. Базируясь на опыте нашей работы, я составил гайд который покрывает эту тему наиболее полно.
Итак зачем нужен RAG?
Руанда. Что приходит вам на ум, когда вы слышите название этой маленькой африканской страны? Наверняка геноцид 1994 года — одно из самых страшных злодеяний второй половины прошлого века.
Но для миллионов африканцев судьба Руанды вызывает огромную зависть. Этой стране удалось построить крайне эффективную для региона экономику, которая по многим ключевым показателям — от рейтинга Doing Business и индекса восприятия коррупции до прироста ВВП и представленности женщин в политике лидирует как минимум в Африке, а порой и обгоняет восточноевропейские страны. Рассказываем о парадоксальном пути развития Руанды.
Здравствуйте Друзья!
Два года назад мною была написана статья, посвящённая разработке в RouterOS.
В рамках того проекта мы управляли устройствами Микротик через Телеграм-бота. Было получено много опыта и много кода, в виде библиотек на языке Mikrotik Script, для работы с API Телеги, функций обработчиков, и всевозможных форм.
Тогда же пришло понимание, что Микротик в связке с Телеграм, это мощно и есть вариант за недорого изобразить сервис. Нужна была идея...
Первая мысль - создание облачного хранилища в Телеграм. Но по-моему такое уже где-то было и не слишком сложно, а хотелось выжать по максимуму из мощностей железа и API Телеги. Отличную идею для реализации подсказал мой друг и даже согласился финансировать данное мероприятие.
Еще один WSPR маяк?
Привет, Хабр! Много ли вы видели различных проектов WSPR маяков? Не знаю, но хочу поделиться с вами своим небольшим проектом который ориентирован в основном на начинающих радиолюбителей.
При освоении новых знаний мы, так или иначе, стараемся связать их с уже освоенными знаниями, в связи с чем при изучении и без того непростых абстракций, в терминах которых заложен свой особый смысл, нередко заходим в тупик.
Такая ситуация имеет место когда начинающий программист знакомится с темами Task, Синхронность, Асинхронность. Ситуация усугубляется тем что зачастую, более опытные коллеги применяют в жаргоне выражения из разряда «Синхронное/Асинхронное выполнение задачи».
Для того, чтобы распутать этот «Гордиев узел», давайте подойдем к проблеме издалека: рассмотрим ее на примере работы симфонического оркестра. Сравним при этом значения проблемных терминов с точки зрения людей, обладающих различной профессиональной ориентацией.
Однажды, смотря на матричное табло, я подумал, что было бы не плохо, если бы смена текста была анимированной. Как раз необходимо было заменить часы дома. Стало интересно попробовать сделать точечный матричный шрифт с анимацией.
Всем привет. После моей предыдущей статьи о Maven плагине, где я предложил новый подход к реализации и создал свою версию для IDEA (вместо того чтобы писать свой мини-мавен, я делегировал всю основную работу ему посредством Maven плагина), меня пригласили работать над Spring плагином в IT-стартап Explyt. Компания занимается автоматической генерацией тестов на базе AI и формальных методов. В процессе работы столкнулся с проблемами, похожими на те, которые решал в своем Maven плагине. У меня возникло некое дежавю, и я подумал: почему бы не использовать подобный подход, чтобы доработать и улучшить Dependency Injection Explyt Spring плагина? Текст для тех, кто работает со Spring-плагинами и хочет разобраться, как эффективно применять готовую логику Спринга для новых задач. Заходите под кат, подробно поделюсь своим кейсом, покажу код, расскажу про итерации и объясню логику.
Изучая криптографию, столкнулся с тем, что часто упоминаются конечные поля. Информации в сети достаточно, но есть много "но". Научные статьи слишком "заумны", в статьях попроще некоторые аспекты попросту не раскрыты. Что будет именно в этой статье: коротко рассмотрим теорию, поставлю под сомнение таблицу логарифмов, и из нового: посмотрим как быстро вычислять остаток от деления полиномов, ответим на вопрос: что такое порождающий полином и научимся генерировать их для конечных полей.
Всем привет. Меня зовут Сергей, я — эксперт компании Bercut. За плечами — более 20 лет работы с различными СУБД (PostgreSQL, Oracle, MS Access, MS FoxPro, Borland InterBase) и высоконагруженными системами на их основе.
В Bercut мы занимаемся разработкой и развитием IT‑продуктов, решений для операторов цифровых услуг и мобильных сервисов. Наши системы работают на различном железе, разных СУБД и обслуживают 24×7x365 в режиме онлайн сотни миллионов абонентов.
Сегодня поговорим о том, как оптимизировать хранение данных в PostgreSQL, снизив объем дискового пространства, потребляемого таблицами и ускорить выборку данных. Это может быть особенно актуально после перевода информационной системы с другой СУБД на PostgreSQL.
Это не лонгрид (как кажется с первого взгляда), а краткое практическое руководство.Есть навигация, можно сразу перейти на нужные пункты.
Привет, меня зовут Никита, я iOS‑разработчик в Яндекс Диске. В прошлый раз я рассказывал, как мы начали свой путь в SwiftUI. Теперь настало время рассказать ещё об одном фреймворке, который мы затащили в свой проект параллельно со SwiftUI, — Combine.
В этой статье разберу проблемы, с которыми столкнулась наша команда, расскажу, как их исправили, а также к каким выводам после этого пришли. А ещё поделюсь библиотекой с фиксами и экстеншенами к Combine.
Привет! Меня зовут Вадим Клеба, я руковожу командой бэкенд-разработки в Телемосте. Последние девять лет я разрабатываю высоконагруженные распределённые системы. Раньше я разрабатывал search-as-a-service-решение с эффективным полнотекстовым поиском с учётом релевантности.
В статье расскажу, как в Яндекс 360 строили API в течение десяти лет без дропа обратной совместимости, выдерживающий сейчас сотни тысяч RPS. Вы узнаете, какие подходы мы изначально закладывали, чтобы наш API прожил так долго.
Привет, меня зовут Юля и я руководитель отдела тестирования. Взаимодействуя по работе с людьми часто вижу, что грамотные в техническом плане специалисты не всегда справляются с непрерывным потоком прилетающих им задач. Когда-то мы с коллегой даже подготовили для нашего отдела небольшую презентацию, посвященную основам тайм-менеджмента.
На мой взгляд, не в выборе конкретной методики суть. О различных подходах говорят много. Но если сильно погружаться в детали на начальном этапе, никакая методика так и не приживется. Чтобы подход заработал, как правило, удобно сделать собственную интерпретацию общих правил, направленную на особенности и специфику своей работы. Также важно понимать, что потребуется потратить время на адаптацию к новой активности и к регулярному её применению.
Этой статьей я попытаюсь немного снизить порог входа в одну из самых полезных (для меня) методик - Getting Things Done. Предложу свою вариацию, которую легко начать применять уже сегодня. Без дополнительных пояснений система будет понятна только тому, кто ее использует. Но зато позволит быстро разгрузить голову, не вникая в детали, изложенные в довольно объемной книге Дэвида Аллена.
Постановка проблемы
На сегодняшний день наиболее известны такие архитектурные паттерны как MVC, MVVM, MVP, Viper, Clean Code.
Все они в той или иной мере работают с тремя основными сущностями - Модель, Вью, Контроллер, добавляя время от времени некоторые дополнительные, например, Presenter.
Вторая общая особенность данных архитектурных паттернов состоит в том, что названные выше сущности выделяются и классифицируются исходя из их технических характеристик. Например, Вью - это то, что отображает данные на экране, Модель - содержит в себе данные и их обработку, а Контроллер осуществляет взаимодействие между ними.
Но эти характеристики не отражают сущности приложения в целом. Это как если бы мы разделили воду на водород и кислород и пытались бы из их особенностей понять сущность воды.
Фрагментарность используемых сущностей и отсутствие целостного видения приложения приводит к общеизвестным проблемам, связанным с трудностями понимания кода и его управлением.
Отсюда, ни один из этих паттернов не гарантирует, что на определённом этапе разработки приложения не возникнет ситуация, когда код станет тяжеловесным и очень сложным для управления.
Именно в такие моменты приходится переосмысливать общую архитектуру проекта и отвечать на вопросы “Зачем нужен тот или иной код, какую задачу он решает?”, “Где расположен код, реализующий ту или иную функциональность и как он работает?”. И т.д.
Продолжая пример с изучением воды следует сказать, что единицей её анализа является молекула воды. Это мельчайшая частица воды, которая тем не менее содержит в себе все её свойства.
В программе такой мельчайшей и одновременно целостной единицей является задача, которую решает тот или иной блок кода.
Отсюда, возникла идея использовать в качестве отправного пункта для организации кода именно те задачи, которые этот код решает.
При этом, задача понимается как бизнес-процесс.
В мире разработки ПО поддержка высокого уровня наблюдаемости (observability) для приложений с архитектурой, управляемой событиями (event-driven architecture, EDA) стало критически важным. Сложность таких систем, связанных с обработкой огромных объемов данных в режиме реального времени, требует надежных инструментов для мониторинга, отладки и анализа. Однако традиционные методы, использующие логи и метрики, часто оказываются недостаточными, когда необходимо глубоко понять взаимодействие между различными компонентами системы и выявить узкие места.
Именно с этой проблемой мы столкнулись в нашей команде, поэтому я, Дмитрий Титаренко (QA-инженер в компании TAGES), решил поделится найденным решением в статье на Хабр. Надеюсь, что будет полезно!
Стопка пластин – это не только оконный стеклопакет – это еще и слои глины и известняка в недрах земли, это «атмосфера» далекой звезды и атмосфера Земли, это живая ткань под микроскопом, тонкие плёнки. И «свет» – это не только видимый диапазон – это и радиоизлучение, и ультрафиолет. То есть, такие спектры интересны геологам, астрономам, биологам.
Математические методы вычисления этого спектра преподаются в ВУЗах. Предмет называется «Матричная оптика».
А я вставил эту математику в веб-страничку – теперь это удобный инструмент – веб-страничка строит график спектра для стопки, составленной Вами из произвольного количества слоев вакуума, стекла, металла, холестерического жидкого кристалла, скрещенных поляризаторов, метаматериалов и всего такого прочего.
И назвал веб-страничку «Калькулятор Прашкевич» (это название – подарок на Первое апреля дорогому мне человеку).
Есть один нюанс со смартфонами. В ссылке смартфоны автоматически приписывают букву "s" к слову "http". Получается "https". С этой припиской ссылка не работает – надо в адресной строке руками удалить эту букву.
Веб-страничку можно использовать как игрушку для детей в образовательных целях (возрастных ограничений нет).
Буду благодарен за отзывы и критические замечания.