Последнее время тематика интернета вещей становится все более и более горячей — однако в большинстве случаев, если речь заходит о работе с какими-то базовыми аппаратными решениями, то беседа сводится либо к готовым модулям, либо, реже, к чипам выпуска прошлых лет. Тем временем, в 2015 году компания Texas Instruments выпустила очередную линейку систему на кристале CC13xx-CC26xx — крайне интересных с точки зрения соотношения производительности, энергопотребления и возможностей. Эти випы имеют на борту основное ядро ARM Cortex-M3, второе ядро Cortex-M0, эксклюзивно обслуживающее радиочасть, и… да, ещё и третье ядро — собственное 16-битное ядро TI для работы с периферией, так называемый Sensor Controller. При этом и по энергопотреблению комбайн получился крайне скромным — даже радиочасть значительно убавила по сравнению с чипами предыдущего поколения, CC2538.

Мы уже писали обзор существующих стандартов связи, в котором остановились на наиболее современном стандарте 6loWPAN. Данный стандарт описывает сетевой и транспортный уровни модели OSI, а физический и канальный уровни стандартизованы IEEE 802.15.4. Texas Instruments позаботились о нас, и отдали обработку MAC-уровня отдельному ядру Cortex-M0. Остальные уровни нужно обрабатывать на Cortex-M3. И тут нам на помощь приходит операционная система реального времени Contiki, в которой реализована поддержка стека 6loWPAN.



Однако традиционная проблема с новыми чипами — нехватка «коллективного опыта», то есть подробных описаний работы с ними, обхода багов и тому подобных вещей.

Что ж, будем его восполнять. Начнём с базового — сборка и отладка операционной системы Contiki для чипов CC2650. Допустим, мы еще любим красивые графические среды и отладку в них. Поэтому мы будем собирать Contiki под TI Code Composer Studio 6. Я пользуюсь Ubuntu 14.04 X86_64 для разработки, шаги под Windows будут очень похожи, за исключением установки тулчейна. В конце есть немного вкусностей...

Дано: есть устройство, с ARM926E-JS (Cypress FX3) на борту. Устройство находится на другом континенте. Устройство подключено (JTAG+USB+COM) к Linux компу. На комп есть SSH доступ (и больше ничего, только SSH порт).

Проблема: Устройство нужно отлаживать и писать под него код. И делать это, желательно, удобно.

Решение с использованием OpenOCD, GDB и Qt Creator, а так же описание пути к нему, под катом.

Здравствуй, Хабрахабр. В настоящий момент я работаю над созданием движка чата в основе которого лежит библиотека SignalR. Помимо увлекательного процесса погружения в мир real-time приложений пришлось столкнуться и с рядом вызовов технического характера. Об одном из них я и хочу с вами поделиться в этой статье.

Введение

Что такое SignalR — это свое рода фасад над технологиями WebSockets, Long polling, Server-send events. Благодаря этому фасаду можно единообразно работать с любой из этих технологий и не беспокоиться о деталях. Кроме того, благодаря технологии Long polling можно поддерживать клиентов, которые по каким-то причинам не могут работать по веб-сокетам, например IE-8. Фасад представлен высокоуровневым API, работающим по принципу RPC. Кроме того, SignalR предлагает выстраивать коммуникации по принципу «publisher-subscriber» что в терминологии API называется группами. Об этом и пойдет речь далее.

Вызовы

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

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.

Публикую на Хабр оригинал статьи, перевод которой размещен в блоге Codingsight.
Вторая часть доступна здесь

Необходимость делать что-то асинхронно, не дожидаясь результат здесь и сейчас, или разделять большую работу между несколькими выполняющими ее единицами была и до появления компьютеров. С их появлением такая необходимость стала очень ощутимой. Сейчас, в 2019, набирая эту статью на ноутбуке с 8 ядерным процессором Intel Core, на котором параллельно этому работает не одна сотня процессов, а потоков и того больше. Рядом, лежит уже немного потрепанный, купленный пару лет назад телефон, у него на борту 8 ядерный процессор. На тематических ресурсах полно статей и видео, где их авторы восхищаются флагманскими смартфонами этого года куда ставят 16ти-ядерные процессоры. MS Azure предоставляет менее чем за 20$/час виртуальную машину со 128 ядерным процессором и 2 TB RAM. К сожалению невозможно извлечь максимум и обуздать эту мощь не умея управлять взаимодействием потоков.

Публикую на Хабр оригинал статьи, перевод которой размещен в блоге Codingsight.

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

Содержание

• О разделяемых ресурсах
• Возможные проблемы при работе в многопоточной среде
  • Deadlock
  • Race-Condition
  • Busy-Wait
  • Thread Starvation
• Средства синхронизации
  • Interlocked
  • Monitor.Enter, Monitor.Exit, lock
  • SpinLock, SpinWait
  • Monitor.Wait, Monitor.Pulse[All]
  • ReaderWriterLockSlim
  • Семейство ResetEvent
• Выводы

Приветствую хабрасообщество!

Не так давно мне в руки попала отладочная плата STM32F429I-DISCO на базе контроллера STM32F429ZI.
Пожалуй главной ее отличительно особенностью является помимо достаточно производительного процессора Cortex M4 — интегрированный экран на 2,4'' дюйма, которого вполне хватает для многих экспериментов.
Первым делом я естественно начал искать по нему документацию и примеры. Хорошая документация вместе с примерами нашлась прямо на сайта st.com, но естественно хотелось большего, туториалов и прочего. То чего так не хватает начинающему программисту под ARM. Но детальный поиск не дал каких то больших результатов. Поэтому пришлось собирать информацию по крохам, анализировать, пересматривать и тестировать ее.

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

Тем кому это может показаться интересным, добро пожаловать под кат.

Материал статьи взят с моего дзен-канала.

Все статьи цикла

Статья 1
Статья 2
Статья 3
Статья 4
Статья 5
Статья 6
Статья 7
Статья 8
Статья 9
Статья 10
Статья 11
Статья 12
Статья 13

Книгу на основе статей можно свободно скачать по ссылке: pdf-файл.

Введение

Эта статья является началом цикла статей о реалтайм обработке медиаданных с помощью движка Mediastreamer2.

В ходе изложения будут задействованы минимальные навыки работы в терминале Linux и программирования на языке Си.

Mediastreamer2 это VoIP-движок, лежащий в основе популярного open-source проекта программного voip-телефона Linphone. В Linphone Mediastreamer2 реализует все функции связанные со звуком и видео. Подробный список возможностей движка можно увидеть на этой странице Mediastreamer. Исходный код находится здесь: GitLab.

Функциональное программирование — это очень забавная парадигма. С одной стороны, про неё все знают, и все любят пользоваться всякими паттерн матчингами и лямбдами, с другой на чистом ФП языке обычно мало кто пишет. Поэтому понимание о том, что же это такое восходит больше к мифам и городским легендам, которые весьма далеко ушли от истины, а у людей складывается мнение, что "ФП подходит для всяких оторванных от жизни программок расчетов фракталов, а для настоящих задач есть зарекомендовавший себя в бою проверенный временем ООП".

Хотя люди обычно признают удобства ФП фич, ведь намного приятнее писать:

int Factorial(int n)
{
    Log.Info($"Computing factorial of {n}");
    return Enumerable.Range(1, n).Aggregate((x, y) => x * y);
}

чем ужасные императивные программы вроде

int Factorial(int n)
{
    int result = 1;
    for (int i = 2; i <= n; i++)
    {
        result *= i;
    }
    return result;
}

Так ведь? С одной стороны да. А с другой именно вторая программа в отличие от первой является функциональной.

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

Коллеги нашли свежий кейс, который замечательно иллюстрирует необходимость оформления прав на код сотрудников до наступления конфликта (Постановление Суда по интеллектуальным правам от 01.08.2019 по делу № А40-202764/2018).

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

Зачастую, профинансировав создание программного продукта, компания остаются ни с чем, приобретая в лице бывших программистов-работников новых конкурентов. Проиллюстрируем на конкретном кейсе, в чем основная ошибка работодателя в оформлении прав на «программный код».

Разбор дела под катом.

Наконец-то в России вышел учебник по SystemVerilog уровнем выше чем для начинающих. Учебник описывает технологии и приемы, которые спрашивают на интервью в NVidia, Intel, AMD, Apple и другие электронные компании: использование concurrent assertions и functional coverage, что сейчас требуют не только от инженеров по верификации, но и от дизайнеров микросхем; алгоритм работы симулятора с дельта-циклами; вменяемое объяснение static timing analysis; схемы коммуникации аппаратных блоков через аппаратные очереди; реализацию этих коммуникаций с помощью конечных автоматов с трактами данных и т.д.

В главе про последнее российского читателя может озадачить упоминание «политкорректной системы». Что бы это значило? Это вероятно намек на казус, который произошел в округе Лос-Анжелес в 2003 году. Чиновники Лос-Анджелеса попросили производителей, поставщиков и подрядчиков прекратить использование терминов «master/slave» («хозяин» и «раб») в отношении компьютерного оборудования, так как одному из работников округа эти термины напомнили про рабовладельческое прошлое.

Сейчас авторы технической литературы избегают терминов master/slave. В современной Америке работают и афро-американские инженеры (например София Мвокани из Камеруна — на фото слева), и использование старых терминов выглядит архаично, как выглядели бы например термины «пан/холоп» в украинской технической литературе вместо принятых «провідний/ведений» (рус. «ведущий/ведомый»).

Это не первый раз, когда в российском электронном образовании появляется тема борьбы афро-американцев за гражданские права. Например Татьяна Волкова, известный специалист по образованию в электронике, носит маечку с эмблемой «Черных Пантер», калифорнийского движения, которое в свое время сочло мирный протест недостаточным, и занялось вооруженным протестом.



Полное изображение эмблемы под кожанкой Татьяны Александровны — под катом, но в основном я буду рассказывать про дельта-циклы и конечные автоматы:

Привет!

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

Давным-давно я прочитал статью 2004-го года авторства Эрика Рэймонда, и всегда в карьере неукоснительно ей следовал. Она довольно большая, и заточена скорее под системных администраторов. Мне же приходится помогать людям, зачастую вообще не имеющим опыта в разработке, стать джуниорами и начать свою карьеру.

Тем, кто уже стал, или еще только мечтает стать начинающим разработчиком, я могу дать следующие рекомендации:

• Изучайте проблему самостоятельно
• Сначала сообщайте цель, потом озвучивайте проблему
• Пишите грамотно и по существу
• Задавайте вопросы по адресу и делитесь решением
• Уважайте чужое время
• Смотрите шире

А теперь подробнее.

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

В предыдущих статьях и их обсуждении я не раз утверждал: никакими современными методами не удается достоверно обнаружить влияния величины естественного радиационного фона в достаточно широком его диапазоне на здоровье людей. Но есть один естественный радиационный фактор, влияние которого относительно хорошо заметно. Это — радиоактивный инертный газ радон, прозванный охочими до красного словца журналистами «невидимым убийцей».

Managed код и .NET Framework – совершенно замечательная вещь с точки зрения программиста, которому надо кровь из носу выдавать максимально стабильно работающие программы. Использование .NET позволяет очень сильно сократить затраты на разработку, тестирование и сопровождение программных продуктов, особенно по сравнению с C++ или Delphi.

Однако, managed код имеет одну очень серьезную родовую травму, которая прямо проистекает из его достоинств – он изначально несовместим с unmanaged средой, в которой вынужден работать. Boxing, поля памяти, отсутствие прямой адресации и прочие ухищрения, призванные облегчить жизнь программисту, приводят к тому, что взаимодействие managed и unmanaged кода становится проблемой.

Однако нет такой проблемы, которую нельзя решить (пусть даже с помощью топора и лома). Сегодня у нас краткий обзор возможностей организации взаимодействия между managed и unmanaged кодом. Многие C# и особенно VB.NET программисты боятся этого, но на самом деле в этом нет ничего страшного. Начнем мы с самых примитивных методов, которые будут интересны разве что новичкам (поэтому матерые волки .NET могут с чистой совестью первую часть статьи пропустить), и закончим описанием того, что делать, если хочется написать программу на .NET, но сделать это невозможно (а такое тоже бывает). Естественно, к каждому случаю будут приведены конкретные примеры, быть может, хабрачеловеки расскажут мне о моей собственной велосипедности. Параллельно я скажу пару слов о подводных камнях при работе с VSTO и Windows Shell.

Продолжая серию статей о «подводных камнях» не могу обойти стороной System.Net.HttpClient, который очень часто используется на практике, но при этом имеет несколько серьезных проблем, которые могут быть сразу не видны.

Достаточно частая проблема в программировании — то, что разработчики сфокусированы только на функциональных возможностях того или иного компонента, при этом совершенно не учитывают очень важную нефункциональную составляющую, которая может влиять на производительность, масштабируемость, легкость восстановления в случае сбоев, безопасность и т.д. Например, тот же HttpClient — вроде бы и элементарный компонент, но есть несколько вопросов: сколько он создает параллельных соединений к серверу, как долго они живут, как он себя поведет, если DNS имя, к которому обращался ранее, будет переключено на другой IP адрес? Попробуем ответить на эти вопросы в статье.

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

Подобных проектов в интернете уже море, но практически все они показывают законченные программы, в которых разобраться крайне непросто. Вот, например, очень известная программа рендеринга, влезающая на визитку. Очень впечатляющий результат, однако разобраться в этом коде очень непросто. Моей целью является не показать как я могу, а детально рассказать, как подобное воспроизвести. Более того, мне кажется, что конкретно эта лекция полезна даже не столь как учебный материал по комьпютерной графике, но скорее как пособие по программированию. Я последовательно покажу, как прийти к конечному результату, начиная с самого нуля: как разложить сложную задачу на элементарно решаемые этапы.

Внимание: просто рассматривать мой код, равно как и просто читать эту статью с чашкой чая в руке, смысла не имеет. Эта статья рассчитана на то, что вы возьмётесь за клавиатуру и напишете ваш собственный движок. Он наверняка будет лучше моего. Ну или просто смените язык программирования!

Итак, сегодня я покажу, как отрисовывать подобные картинки:

Привет!

Сегодня мы немного поговорим про EntityFramework. Совсем чуть-чуть. Да, я знаю что к нему можно относиться по-разному, многие от него плюются, но за неимением лучшей альтернативы — продолжают использовать.

Так вот. Часто ли вы используете в своём C#-проекте с настроенным ORM-ом прямые SQL-запросы в базу? Ой, да бросьте, не отнекивайтесь. Используете. Иначе как бы вы реализовывали удаление/обновление сущностей пачками и оставались живы…

Что мы больше всего любим в прямом SQL? Скорость и простоту. Там, где "в лучших традициях ORM" надо выгрузить в память вагончик объектов и всем сделать context.Remove (ну или поманипулировать Attach-ем), можнo обойтись одним мааааленьким SQL-запросом.
Что мы больше всего не любим в прямом SQL? Правильно. Отсутствие типизации и взрывоопасность. Прямой SQL обычно делается через DbContext.Database.ExecuteSqlCommand, а оно на вход принимает только строку. Следовательно, Find Usages в студии никогда не покажет вам какие поля каких сущностей ваш прямой SQL затронул, ну и помимо прочего вам приходится полагаться на свою память в вопросе точных имён всех таблиц/колонок которые вы щупаете. А ещё молиться, что никакой лоботряс не покопается в вашей модели и не переименует всё в ходе рефакторинга или средствами EntityFramework, пока вы будете спать.

Так ликуйте же, адепты маленьких raw SQL-запросов! В этой статье я покажу вам как совместить их с EF, не потерять в майнтайнабильности и не наплодить детонаторов. Ныряйте же под кат скорее!

“Разработка API сложна, Postman делает её лёгкой” © Postdot Technologies, Inc

Когда видишь описание инструментов Postman — захватывает дух, просыпается чувство всевластия над своим будущим детищем. Кажется, что и взрощенные в прошлом "монстры" наконец-то падут перед тобой!

В этой статье мы расскажем о Postman и попробуем написать свой первый скрипт.

Lock-free list является основой многих интересных структур данных, — простейшего hash map, где lock-free list используется как список коллизий, split-ordered list, построенный целиком на списке с оригинальным алгоритмом расщепления bucket'а, многоуровневого skip list, являющегося по сути иерархическим списком списков. В предыдущей статье мы убедились, что можно придать такую внутреннюю структуру конкурентному контейнеру, чтобы он поддерживал thread-safe итераторы в динамичном мире lock-free контейнеров. Как мы выяснили, основным условием для того, чтобы lock-free контейнер стал итерабельным, является стабильность внутренней структуры: ноды не должны физически удаляться (delete). В этом случае итератор суть просто (быть может, составной) указатель на ноду с возможностью перехода к следующей (оператор инкремента).

Можно ли такой подход распространить на lock-free list?.. Посмотрим…