Если вы сделали опечатку, когда вводили имя ветки, вам поможет вот такая команда.

Приветствую! 

Каждый раз, когда начинаешь решать какую-либо большую задачу, то на пути появляется множество маленьких. И найденные или не найденные решения маленьких подзадач превращаются в то, что мы в дальнейшем называем опытом. Но к сожалению, если не пользуешься чем-то постоянно, то когда-то найденные оригинальные решения со временем начинаешь забывать, а когда необходимо, начинаешь вспоминать и с удивлением, а иногда и с не пониманием долго смотришь на свои же шедевры. 

Статья рассчитана на тех кто уже знаком с Си, а все примеры ориентированы на ОС Linux. Мои познания Windows закончились на «WinXP», после которой в Windows стало уже очень много политики ("безопасности") и коммерческой составляющей, но я сейчас не об этом и надеюсь, что здесь вы найдёте для себя полезные моменты, а если я в чём-то не прав или заблуждаюсь, то поправите.

Итак, я решил попробовать писать в стиле объектно ориентированного программирования (далее ООП) на Си без плюсов. Многие скажут, что писать в стиле объектно ориентированного программирования (далее ООП) не для Си, и разные приёмы написания это - «псевдо-ООП». Но лично я считаю ООП всего лишь абстрактной парадигмой, определяющей стиль написания ПО и не более чем. А Си очень мощный и самодостаточный язык программирования.

Так сложилось, что изучать традиции ООП я начал с Delphi и Java, являющихся, как считается, на 100% объектно ориентированными языками программирования, а потому аналогия решений у меня ассоциируется именно с ними. И далее в тексте я иногда буду на них ссылаться, что надеюсь не испортит суть полного понимания.

Иногда важно не только содержание документации, но и процесс ее подготовки. В некоторых проектах с этим процессом связана львиная доля работы, а его нарушения могут приводить к ошибкам, утрате информации и в конечном итоге к временным и финансовым потерям. И даже если обозначенная тема не является вашей основной задачей, правильная организация этого процесса поможет вам улучшить качество документации и сэкономить время.

Метод, описанный ниже, отличается низким порогом вхождения: фактически уже завтра вы сможете начать работать по-новому.

Всем привет. Тетработ – название линейки разрабатываемых нами роботов и название нашего стартапа в сфере мехатроники и робототехники. Мы изобретаем и создаем роботов на новом принципе передвижения.

Друг предложил мне поработать над проектом для нашей кафедры. ТЗ пока не сформулировано, но точно известно, что это будет бот в телеге. Я хоть и питонист, но с ботами дел никогда не имел, поэтому пишу эту статью, как заметку, для себя и молодых перспективных ребят, чтоб у них было от чего оттолкнуться. Постараюсь писать максимально понятным и простым языком. Профессионалам тут особо делать не чего, хотя, может и придёт какая-нибудь идея.

В статье разберемся, что нужно знать про ПО как объект авторского права и как не нарваться на проблемы — как разработчикам, так и пользователям программы.

1.    Истоки правового регулирования персональных данных на западе и России;

2.    Виды персональных данных и основные понятия ФЗ № 152;

3.    Ответственность за нарушение персональных данных;

4.    Судебная практика.

В последние десятилетия мы часто слышим в новостной ленте о том, как слили персональные данные, о так называемом «пробиве» информации о человеке. Роскомнадзор постоянно объясняет: как не стать жертвой мошенников, а эксперты дают нам рекомендации по цифровой  гигиене.

Вроде как все понимают, что такое персональные данные и многие даже с уверенностью скажут, что к ним относятся паспортные данные, пароли, личная и семейная тайна. Однако, кто знает точные перечень персональных данных? Откуда вообще пошло правовое регулирование этих данных? Какую ответственность несут нарушители права на защиту персональных данных? Как воспринимают персональные данные суды?

Сегодня поговорим обо всём этом и попытаемся конкретизировать эту текучую субстанцию – персональные данные.

Как говорил доктор Хаус: Все врут.

Я решил написать данный текст после прочтения недавнего поста на хабре от "скептика" а так же после длительных дискуссий с разными людьми, которые уверены что все это фейк и даже больше. В данном тексте я не оцениваю политизированность темы, ошибочность принятых решений или необходимость каких-то действий. Цель данного текста исключительно в развеивании мифов, которыми люди бросаются либо из-за невежества, лени, злости или с целью ввести оппонента в заблуждение. Я так же стараюсь не касаться вопросов кому это нужно и какова цель, так как прекрасно понимаю, что если у вас параноя, то это не значит, что за вами не следят.

Текст разделен на две части: Ковид в частности и вирусология в общем.

Если у вас есть дополнения или исправления, пожалуйста - пишите их в комментариях с аргументацией и, если необходимо с приведением источников.

Если у вас есть вопрос или утверждение которое вы хотите добавить, постарайтесь написать его в таком же формате (вопрос, объяснение, источники) и так же оставляйте во комментарии я постараюсь добавить все по мере возможностей.

Оглавление

1. Введение
2. Инициализация приложений Prism
3. Управление зависимостями между компонентами
4. Разработка модульных приложений
5. Реализация паттерна MVVM
6. Продвинутые сценарии MVVM
7. Создание пользовательского интерфейса
   
   1. Рекомендации по разработке пользовательского интерфейса
8. Навигация
   1. Навигация на основе представлений (View-Based Navigation)
9. Взаимодействие между слабо связанными компонентами

Так сложилось, что за последние 18 лет, не приходилось писать на C/C++. На работе использовалась Java, да и ввиду должностей деятельность больше была связана с предпринимательством - переговоры, корпоративные продажи, выстраивание производственных операций и структурирование инвестиционных сделок. Захотелось в свободное от работы время восстановить навыки, размять часть мозга которую не напрягал все 18 лет и, естественно, начать с самых основ. Осталось придумать себе задачу.

В универе преподаватели, молодость которых приходилась на 70-80е годы, до объектно-ориентированного программирования убивались по теме разработке собственных языков (интерпретаторов, компиляторов) под предметные области. Всё это казалось мне невостребованным "старьём", но появление новых языков за последнее десятилетие (Go, Kotlin и множества других) повысили мой интерес к этой теме.

Решил в качестве хобби написать 32-bit стековую виртуальную машину и компилятор C подобного языка под неё, чтобы восстановить базовые навыки. Такая классическая Computer Science задачка для заполнения вечеров с пивом. Как предприниматель, я четко понимаю, что она никому не нужна, но такая практика нужна мне для эстетического инженерного удовольствия. Плюс когда об этом рассказываешь сам понимаешь глубже. С целью и мотивами определился. Начнём.

Так как это виртуальная машина, мне нужно определиться с её характеристиками:

CPU: 32-bitный набор команд, так как машина стековая, в основном операнды команд храним в стеке, из регистров только IP (Instruction Pointer) и SP (Stack Pointer), пока работаем с целыми числами со знаком (__int32), позже добавим остальные типы данных.

RAM: пусть памяти пока будет 65536 ячеек по 32-bit`а. Которую организуем просто. С нижних адресов в верх будут идти код (code/text) и данные (data, heap), а с верхних адресов вниз будет расти стек (stack). Дёшево и сердито.

По ходу разработки генератора кода для виртуальной машины понял, что виртуальная машина не готова к полноценным вызовам функций, с передачей аргументов и хранению локальных переменных функций. Поэтому её необходимо доработать. А именно, нужно определиться с Соглашением о вызовах (calling convention). Есть много разных вариантов, но выбор конечный за разработчиком. Главное - это обеспечить целостность стека, после вызова.

Соглашение о вызовах (calling convention) - это правила по которым при вызове функции передаются аргументы в вызываемую функцию (стек/регистры, порядок), кто и как очищает стек после вызова (вызывающий/вызываемый) и как возвращается результат функции в точку вызова (стек/регистр). Ко всему прочему, вызываемые функции могут создавать локальные переменные, которые будут хранится в стеке, что тоже необходимо учитывать, особенно, чтобы работала рекурсия.

На сегодняшний день, наиболее знакомое мне Соглашение о вызове (calling convention), регулирующее правила передачи аргументов функции, очистки стека после вызова, а также логика хранения локальных переменных - это C declaration (cdecl, x86/64) и pascal. Попробую применить эти знания с небольшими модификациями, а именно без прямого доступа программы к регистрам виртуальной машины (она же всё таки стековая, а не регистровая). Итак, логика будет следующая.

К старту курса о машинном и глубоком обучении мы решили поделиться переводом статьи с наглядным объяснением того, как работают CNN — сети, основанные на принципах работы визуальной коры человеческого мозга. Ненавязчиво, как бы между строк, автор наталкивает на размышления о причинах эффективности CNN и на простых примерах разъясняет происходящие внутри этих нейронных сетей преобразования.

Привет Хабр! С вами Горшков Максим, специалист по информационной безопасности Cloud4Y. Мне выпала честь первому протестировать новый инструмент киберразведки: OSINT-SAN. Разрабатывал его мой коллега по ИБ Максим Пономарёв (Bafomet).

Умные весы Picooc с нашей подачи широко известны в России. Они измеряют вес и состав тела, помогают следить за здоровьем и поддерживать форму. Это действительно работает: доказано командой Madrobots и десятками тысяч пользователей Picooc в нашей стране. 

В начале 2021 года произошел апгрейд всей коллекции. На смену первому поколению пришли вторые версии моделей: точнее и с дополнительным набором метрик. Какие новые технологии внедрили разработчики и не превратятся ли модели V1 в тыкву?

В этой статье поделюсь опытом, как уменьшить размер приложения, написанное на C# и независящее от сборки, в 2 – 4 раза.

По натуре своей многие разработчики слишком ленивые не любят делать одно и то же действие много раз. Нам проще научить компьютер, чтобы он делал монотонные действия за нас.

Как только кто-либо из нашей команды вносит изменения в код (читай «мерджит feature-ветку в develop»), наш билд-сервер:

• Собирает исходный код и установщик приложения
  
  • проставляет номер сборки, каждый раз увеличивая последнюю цифру. Например, текущая версия нашего ПО 3.3.0.202 – часть 3.3.0 когда-то ввёл разработчик (привет, SemVer), а «202» проставляется в процессе сборки.
  • В процессе анализирует качество кода (с использованием SonarQube) – и отправляет отчёт во внутренний SonarQube,
• Сразу после сборки запускает автотесты (xUnit) и анализирует покрытие тестами (OpenCover),

Также, в зависимости от ветки, в которую были внесены изменения, могут быть выполнены:

• отправка сборки (вместе с changelog-ом) в один или несколько телеграм-каналов (иногда удобнее брать сборки оттуда).
• публикация файлов в систему автообновления ПО.

Под катом о том, как мы научили Gitlab CI делать за нас бОльшую часть этой муторной работы.