User
Решил опубликовать исходный код C# для работы с форматом конфигураций 1С: Предприятие.
https://github.com/elisy/MdInternals
MdInternals понимает формат cf, cfu, epf, erf, распаковывает содержимое в удобочитаемые Xml и текстовые файлы и загружает обратно. Позволяет программно обращаться к внутренним файлам и свойствам объектов.
Проект состоит из частей:
use <имя_БД>;
go
create schema inf;
Провайдеры Российской Федерации, в большинстве своем, применяют системы глубокого анализа трафика (DPI, Deep Packet Inspection) для блокировки сайтов, внесенных в реестр запрещенных. Не существует единого стандарта на DPI, есть большое количество реализации от разных поставщиков DPI-решений, отличающихся по типу подключения и типу работы.
Нет, это не коммерческое предложение, такова стоимость комплектующих системы, которую Вы сможете собрать после прочтения статьи.
Немного предыстории:
Некоторое время назад я решил завести пчел, и они таки появились… на целый сезон, но не вышли из зимовки.
И это несмотря на то, что вроде все делал правильно — осенний прикорм, утепление перед холодами.
Улей был классический деревянный системы "Дадан" на 10 рамок из 40-мм доски.
Но в ту зиму из-за температурных "качелей" даже опытные пчеловоды потеряли куда больше, чем обычно.
Так пришла идея системы мониторинга состояния улья.
После публикации нескольких статей на Хабр-е и общения на форуме пчеловодов, решил идти от простого к сложному.
Вес — единственный бесспорный параметр, но как правило, существующие системы мониторят только один "эталонный" улей.
Если с ним что-то идет не так (к примеру вылет роя, болезнь пчел), то показатели становятся неактуальны.
Поэтому решено было следить за изменением веса сразу трех ульев одним микроконтроллером, а прочие "плюшки" добавить после.
В итоге получилась автономная система со временем работы около месяца на одном заряде батареи 18650 и отправкой статистики раз в сутки.
Конструкцию старался максимально упростить, дабы ее можно было повторить даже без схем, по одним фотографиям.
Логика работы следующая: при первом запуске/сбросе запоминаются в EEPROM показания датчиков, установленных под ульи.
Дальше, каждый день, после заката система "просыпается", считывает показания и отправляет СМС с изменением веса за сутки и от момента включения.
Кроме того передается значение напряжения батареи, а при снижении до 3.5В выдается предупреждение о необходимости зарядки, ибо ниже 3.4В модуль связи не включается, да и показания веса уже "уплывают".
site:https://habr.com getfattr, равно как и по ЛОРУ: site:https://linux.org.ru getfattr ничего толком не дал. «Значит» — подумал я — «эта тема еще особенно не обсуждалась». — Что же, тогда пришло время ее обсудить, но для начала пришлось немного по-исследовать. И вот что я обнаружил:
Летом 2018 года я уже писал о том, как мы создавали настольную электротехническую игру "Не закороти Цепь!", которая тогда готовилась к изданию. В настоящий момент работа над игрой завершена, она успешно собирает средства на издание на площадке CrowdRepublic, но мы решили рассказать об её "движке", его создании и с проблемами, с которыми мы столкнулись при этом.
Казалось бы, что сложного. Батарейка, провода, светодиоды и лампочки — собирай цепочку, смотри, что зажглось, получай очки и штрафы, если замкнул плюс на минус без нагрузки. Резистор уменьшает число очков, диод пропускает или не пропускает ток в определенном направлении, цепь "считается" от плюса к минусу. Но...
Игра детская (8+ рекомендация) и необходимо, чтобы дети (и взрослые) не сломали мозг на определении работоспособности цепи. И пришлось пойти на упрощение правил. Главное, чем пришлось пожертвовать и где "движок" расходится с реальной цепью — это параллельные и последовательные соединения. Обычно игроки создают цепочки, где все элементы расположены последовательно, но увы на тестах они умудрялись подключать лампочки параллельно. Тогда элементы получают одинаковое напряжение и раз у нас число очков дается за "силу свечения", то очки начислять надо было не так, как при последовательном соединении. Казалось бы ничего сложного, но как только в цепи появляются еще резисторы и светодиоды, мозг начинает "кипеть".
Изображение взято из Викимедии, автор – Gil. Распространяется на условиях лицензии Creative Commons Attribution 2.0 Generic license
Привет, Хабр! Меня зовут Андрей, я юрист в сфере интеллектуальной собственности и IT-технологий.
Некоторое время назад на Хабре была опубликована история andrei_mankevich — автора мобильного приложения — реализации игры «Балда», которое было удалено по жалобе правообладателя соответствующего товарного знака. Судя по комментариям к этой истории, многим было интересно, можно ли как-то восстановить справедливость и наказать тролля.
В связи с этим я хочу рассказать о возможностях, которые предоставляет российский закон для защиты от таких действий.
На заметку: «патентные тролли» («patent troll») — это лица, осуществляющие покупку или регистрацию патента на изобретение, полезную модель или промышленный образец исключительно для того, чтобы требовать с других лиц вознаграждение за использование патента под угрозой предъявления судебного иска. Такие лица, как правило, не производят какой-либо полезный продукт на основании купленного патента.
В отношении лиц, осуществляющих аналогичную деятельность с товарными знаками и объектами авторских прав, используются, соответственно, термины «trademark troll» (можно перевести как «брендовый тролль») и «copyright troll» («копирайтный тролль», «копитролль»).
Далее я буду говорить о брендовых троллях — лицах, которые регистрируют или покупают товарные знаки, для того чтобы заработать на предъявлении претензий и судебных исков.
