До выхода в Бразилию с нашим продуктом, мы знали только, что эта страна — родина языка Lua, которым мы делаем свои "модные" логи.

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

Факт 1. У бразильских айтишников есть самобытные комиксы

Один из популярных комиксов называется “Жизнь программиста”, и по стилю похож на то, как если бы Дилберт был разработчиком.

Менеджер: Эта система нужна как можно скорее. Если отложить все остальное, когда ты ее допишешь?

Разработчик: Если не случится ничего непредвиденного, через неделю.

Менеджер: А если назвать срок без этого вот “непредвиденного”?

Разработчик: Тогда два года.

Менеджер: Как два года? Мы только что говорили про неделю!

Разработчик: Но это было без учета форс-мажоров. Вот представьте: я начинаю работу над проектом, но тут происходит несчастный случай — и я оказываюсь в коме. 3 месяца вы ждете, что я очнусь. Но чуда не происходит. Тогда вы решаете нанять кого-то и месяц закрываете вакансию. Еще месяц уходит у новичка, чтобы разобраться с системой. Следующие два месяца он делает вид, что работает. Еще месяц вы решаете, увольнять его или нет… И вот, после нескольких неудачных попыток заменить меня, кто-то стирает проект. Тут я выхожу из комы и приходится начинать все с нуля…

Часть комиксов выдумана. А часть — основана на ситуациях, в которые попадал сам автор (с 2002-го он писал на Pascal и C, затем перешел на PHP и Python), его коллеги или читатели сайта.

Вот одна из реально произошедших историй:

Менеджер: Я прочитал, что Microsoft знает все, что мы делаем в Windows, Google — что мы делаем в Android, а Apple — в iOS.

Разработчик: Да, я тебе давно об этом говорю.

Менеджер: Но пользователям Linux тогда вообще приходится хуже всех, верно? Там же OPEN SOURCE…

За пять лет “Жизнь программиста” выросла в популярный в местных ИТ-кругах сайт (тут, например, рекламируют вакансии и новые продукты) и большое — свыше 180 тысяч подписчиков — сообщество на фейсбуке.

Теперь они даже выпускают свой кофе и футболки:

При этом сам проект стартовал как ответ на появление бразильского веб-комикса “Жизнь техподдержки”.

Факт 2. В остальном, у бразильцев не так уж много своих сервисов

«Лет 15 назад в Бразилии начался бум интернетизации. Тогда у нас был свой поисковик — как ваш Яндекс или Рамблер. Назывался Cade — от слова „где“. Они стартовали в середине девяностых и к началу 2000-х были очень, очень популярны, но… Они почти прекратили развивать движок и просто вкладывались в рекламу.

В то же время Google и Yahoo сделали свои локализации — и результаты у них были объективно лучше. Необходимость в местном поисковике отпала — Cade был куплен Yahoo и превратился в витрину для их поиска».

По оценке агентства Nielsen, та сделка позволила Yahoo дотянуться до 52% бразильских интернет-пользователей. И как замечает Карлос, людям часто нет разницы — местный продукт или иностранный.

Факт 3. В Бразилии Google удалось построить популярную соцсеть

Что было до Google+? Правильно, Orkut. В середине 2000-х эта соцсеть пользовалась популярностью в двух местах — Бразилии и Индии. Правда, на закрытие гугловского проекта востребованность в отдельно взятых странах не повлияла.

Сегодня основная соцсеть для бразильцев — Facebook (по данным Social Bakers, скрин за 2012-й год)

«Иногда я завидую россиянам: у вас есть свои соцсети, созданные местными специалистами для местной аудитории. В Бразилии, по сути, кроме чатов-»кроваток", когда интернет был еще для гиков, не было ничего своего социального".

К середине 2000-х местные компании сдали часть вкусных потребительских сегментов иностранным игрокам. Нишу интернет-аукционов, например, захватил Mercado Libre — аргентинский проект, в 1999-м быстро сделавший португальскую локализацию, а затем поглотивший основных конкурентов — тоже, кстати, иностранных.

Любопытно, что в то время конкуренцию иностранным интернет-компаниям лучше оказывали люди из оффлайна:

Например, Netshoes, онлайн-платформа для продажи спортивных товаров, которая теперь работает на трех рынках (Бразилия, Аргентина, Мексика) выросла из магазина спортивной экипировки, открытого в Сан-Паулу в начале 2000-х. Это их распределительный центр.

Факт 4. Чисто бразильские компании нашли свои ниши

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

Спрос на ИТ в промышленности объясняется местным железом: в стране развито производство электроники, например, для самолетов и нефтяных вышек. Причем есть строгое требование, какой процент всего производства должен быть размещен внутри страны: в зависимости от отрасли, он может доходить до 80%.

Госорганы давно стараются поддерживать локальных разработчиков ПО через госзакупки. С 2014 года тут даже действует закон, по которому преференции при тендерах отдаются именно местным разработчикам. Например, они могут предложить цену выше, чем у конкурента, и выиграть. Так что, хотя в Бразилии все ИТ-компании регистрируют местные юрлица — это с связано с приемом платежей, — иногда можно быть более местным.

N.B.: При этом, даже местные компании должны платить дополнительные отчисления в казну, если закупают иностранное ПО или пользуетесь услугами дата-центров за пределами Бразилии. C налогами тут вообще интересно.

Факт 5. В Бразилии много “ИТ-компаний одного человека“

К началу 2010-х на бразильском рынке ПО, ИТ-услуг и телекома работало около 9 тысяч компаний. Среди них числилось 43,9% микро-предприятий — часто, компании из одного или пары человек. Причем, не только стартапы, которые в то время начало поддерживать государство.

«Одно время микро-компании часто заводили те, кто по факту работал не на себя, а на другую небольшую ИТ-компанию. Делалось это, чтобы наниматель заключали контракты не с человеком, а с его фирмой — таким образом работодатель перекладывал налоговую нагрузку со своей головы на вашу. Я слышал, что в странах СНГ тоже можно встретить такую практику, но у нас, по ощущениям, она приобрела масштаб отраслевого бедствия. Поэтому работать в штате, а не как-бы-фрилансить — это уже было карьерным достижением”.

По результатам исследования PwC и Всемирного банка, в Бразилии самый “времязатратный” налоговый режим

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

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

А сколько же они получают? У бразильцев нет своего “Моего круга”, зато есть что-то вроде “ХедХантера”:

Для удобства и компактности отображения, мы перевели Гуглом блок сортировки вакансий.

Чаще встречаются предложения от 1 до 3 тысяч реалов — это начальный уровень, когда вас нанимают, например, после института. Руководитель службы техподдержки, хороший специалист по информационной безопасности или опытный разработчик могут рассчитывать на 8-10 тысяч реалов.

В переводе на доллары, диапазон зарплат составляет $300-3000 (сейчас за доллар дают около 3,6 реалов). При этом, как показывает история, курс реала к доллару может ощутимо меняться. Вот динамика с 1995 (реал в Бразилии ввели в 1994-м) по 2011 годы:

Курс рубля к бразильскому реалу тоже здорово менялся со временем. Сейчас это где-то 19 рублей за реал:

Соответственно, зарплаты в местном ИТ-секторе в пересчете на рубли варьируются от 20 до 200+ тысяч.

Факт 6. Бразильские айтишники могут дольше отдыхать

Даже отпуск у них дольше — 30 дней.

“Официально у нас в стране всего пять праздничных выходных. Но, как и у вас в России, есть больше новогодние каникулы — они начинаются перед католическим Рождеством и кончаются после Нового года. Плюс, конечно, карнавал — это такой аналог ваших майских праздников, когда работа останавливается и все уходят в отпуска”.

Еще в Бразилии есть интересная традиция насчет праздников: если выходной выпадает, например, на вторник, то понедельник сделают нерабочим. Кажется, пока все выглядит знакомым? Но — устраивать рабочую субботу по поводу переноса, как у нас в России, никто не будет.

Тут стоит развеять популярный стереотип, что “бразильцы ленивые”. Во многом, корни мифа растут из времен отмены рабства: многие местные отказывались работать на плантациях, и нишу заняли эмигранты из Европы. Они-то обычно и называли бразильцев “ленивыми”.

И скажем честно, те же аргентинцы по числу праздничных выходных сильно впереди Бразилии — у них их 19.

Факт 7. Бразильцы нанимают аргентинских программистов

Сейчас в ИКТ-секторе Бразилии занято около миллиона человек. А по подсчетам отраслевых ассоциаций и чиновников, нужно еще 900 тысяч специалистов.

Лысый человек: Главная проблема с рынком ИТ в Бразилии — не хватают квалифицированных профессионалов. Эй,​парень, у нас вафельница не работает, ты не можешь посмотреть?

Сотрудник техподдержки: Я с таким оборудованием не работаю.

Лысый человек: Видите? Он даже не умеет починить вафельницу, как он может разбираться в компьютерах??

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

Свои кадры, конечно, тоже растят. Карлос говорит, что хотя в Бразилии много вузов с ИТ-направлением, хорошими считаются только 4 из них. Это Unicamp, UNESP, Университет Сан-Паулу и ITA (что-то вроде бразильского МАИ) — все они расположены в одном городе или неподалеку от него. Поэтому в Сан-Паулу открывается больше всего ИТ-вакансий.

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

Факт 8. Бразилия — все же главный ИТ-рынок в Южной Америке

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

ссылка на оригинал статьи https://geektimes.ru/post/273658/

Привет друзья! Как и было заявлено, 26-27 февраля состоялась конференция сообщества под славным именем C++ Russia 2016. Мероприятие прошло на берегах Невы в стенах, холлах и залах отеля Park Inn by Radisson Прибалтийская.

Что там и как? Вперед — под кат!

Конференция

Флагман Russia C++ — конечно же докладчики и доклады (блокноты и тусовка само собой, но все же…). На этот раз программная часть количественно подросла по сравнению с Москвой 2015 — получилось 2 дня, 3 трека, 25 докладов. Программа вышла крайне разнообразной по темам:

• стартовали с увлекательной повести от Gor Nishanov (Coroutines)
• уроки английского вспоминали на докладах гостей Joel Falcou (Boost.SIMD), Kirk Shoop (Reactive programming), Dori Exterman (Parallel computing strategy)
• учились разным штукам от тертых докладчиков Александра Фокина (Рефлексия) и Дмитрия Нестерука (Паттерны)
• внимали инсайдерской информации от Антона Полухина (Boost)
• играли в бейсбол с питчером Михаилом Матросовым (Повседневный С++)
• а также многое, многое, многое другое

Слайды презентаций выложены, видео выпустили в эфир буквально на днях — смотрите, изучайте, радуйтесь!

Закусить доклады можно было хорошей порцией общения с собратьями по призванию, коих набралось около 400 человек, а также c докладчиками и представителями компаний на стендах, благо пространство отеля и кофей позволяли.

От бизнеса были Лаборатория Касперского, JetBrains, Artec 3D, СиПроВер, Luxsoft и Яндекс. Команды на стендах радовали общением, фишками и плюшками, а также старались нагрузить трещавший от информации мозг олимпиадным программированием!

Аперитив

Накануне конференции домашние мероприятия в питерских офисах организовали компании JetBrains и Яндекс.

Компания JetBrains собрала народ на вечеринку JetBrains C++ night. Здесь можно было пообщаться на тему продуктовой линейки компании непосредственно с разработчиками, мини-инсайд, как-никак. Также JetBrains представила вариации на тему Resharper, CLion и HPC в виде докладов.

Яндекс, в свою очередь, провел ток-шоу Что происходит в C++, пригласив на беседу зарубежных гостей конференции C++ Russia. Говорили долго и интересно. Много и оптимистично (ох) про С++ 17, про модули и корутины, про модули и концепты, про модули и нехорошие макросы и про многое другое конечно.

Аперитив удался весьма качественным. Спасибо компаниям за здоровские мероприятия, погонять чаи в офисе Яндекса было интересно )

Итак, он же итог

Настоящий C++ марафон выдал Питер в последние дни зимы. Похоже, что С++ в нашей стране любят, ценят и знают (чуть-чуть). А себя показать, других посмотреть, познакомиться, пообщаться, научиться чему-то, посмотреть на мастеров своего дела, на людей, что делают библиотеки и язык, создают компетенции и мастерство, делятся находками и приемами — все это позволила делать отлично организованная конфа С++ Russia. Для всего этого у нас есть сообщество неравнодушных программистов и компаний. Ура!

С другой стороны, привозить отличных докладчиков со всего мира — оказывается — совершенно реально. Gor Nishanov, на мой взгляд, стал звездочкой конференции — и по докладу, и по открытому общению, и по русскому языку. А Joel Falcou, судя по функциям и исходникам Boost.SIMD, в сговоре с темными силами метапрограммирования. Ну и не каждый день видишь как Dori Exterman рассказывает в коридоре, как чертовски сложно реализован IncrediBuild и почему компания не боится появления модулей в C++.

Спасибо организаторам и участникам — было классно! sermp, спасибо за работу, спасибо за сообщество!

А что дальше?

Впереди в планах — брать Казань встречей сообщества, брать Сибирь — конференцией.

В комментариях делимся впечатлениями, спрашиваем вопросы, отвечаем ответы и все такое.

P.S. За все ошибки, недочеты, переучеты, обиды и оскорбления в посте ответственность несет кто угодно, но только не автор (вот какие приемы можно нарыть в книжках по алгоритмам)!

P.P.S. С++ на Урале! Если ты есть, отзовись, организуйся и активизируйся! Пока регион выпадает из географии активного С++ сообщества.

ссылка на оригинал статьи https://habrahabr.ru/post/280628/

«Зачем?», «Что за бред?», «Извращение!», «Фу-фу-фу» — вот некоторые из многих высказываний, которые мы услышали, когда выпустили плату Iskra JS на ядре Espruino.

Зачем

Когда правильный электронщик слышит, что что-то сделано на Arduino, температура его тела поднимается примерно на полградуса: «взяли годный микроконтроллер и вместо того, чтобы фигак-фигак и регистрами выжать из него все соки, опошлили всё на свете… нет слов, одна ненависть».

Но ведь можно пойти ещё дальше. Взять микроконтроллер Cortex M4, который в десятки раз богаче того, что стоит на той же Arduino Uno, запихнуть туда интерпретатор JavaScript и делать проекты на JavaScript!

Думаю, что на этом моменте те, кто не готов к такому надругательством над святыми микросхемами, уже лопнули. Я продолжу для остальных.

В хобби-электронике для подавляющего большинства проектов Arduino Uno хватает за глаза. И даже не важно будет она работать на штатных 16 МГц или на 4 МГц: включится ли подсветка кровати или насос на даче за 1 мс или за 10 мс не имеет значения.

Что имеет значение, так это то, что C++ — сложный и деревянный. Да, он близок к железу, но именно поэтому требует глубокого понимания этого железа и информатики. Добавим к этому синтаксис с кучей нюансов, который является суммой ошибок 30-летнего развития языка. Затем лишим то, что получилось адекватных массивов, строк, словарей, а ещё лучше — вообще лишим динамической памяти. Вот, наконец мы получили Arduino.

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

Похожий процесс я наблюдал много лет пока работал в разработке игр. В 2003-м году представить было нельзя, что игру можно писать на чём-то кроме C/C++. Потом в движках появились встроенные скрипт машины. А затем и создание полноценного продукта стало возможным без единой строки на Си. Только Java, C#, Ruby, Python, JavaScript. Это логично, потому что железо стало тянуть «медленные языки», а засчёт в разы более быстрой разработки и большего количества доступных программистов, стало возможным больше ресурсов тратить на интересность игры, а не на поиск утечек памяти.

На что похоже программирование микроконтроллеров на JavaScript

Программирование похоже на… JavaScript. На разработку для браузера или Node.js. Вот пример:

// SMS var sim = require('@amperka/Sim900r').connect(); sim.powerOn(); sim.on('sms', function(sms) {     var rgb = sms.text.split(' ');     var r = +rgb[0];     var g = +rgb[1];     var b = +rgb[2];     if (isNaN(r + g + b)) return;     fadeTo(r, g, b); });  // Лента SPI2.setup({baud:3200000, mosi:B15}); var LED_COUNT = 150; var colors = new Uint8ClampedArray(LED_COUNT * 3);  function fadeTo(r, g, b) {   var n = 0;   var ivalID = setInterval(function() {     colors[n*3 + 0] = b;     colors[n*3 + 1] = r;     colors[n*3 + 2] = g;     SPI2.send4bit(colors, 0b0001, 0b0011);     if (n++ >= LED_COUNT) {       clearInterval(ivalID);     }   }, 50); } 

Эта программа занимается тем, что принимает SMS’ки и в зависимости от их текста бегущим огоньком меняет цвет подключённой RGB-ленты. Мы делали такой проект для нашей новогодней ёлки, но на классической Arduino. Кода было в 4 раза больше.

Ядро Espruino

Итак, у компьютера есть движки V8 и SpiderMonkey для JavaScript. А у микроконтроллеров есть движок Espruino.

Если говорить грубо, движок Espruino — это прошивка (скетч, скетчище) для микроконтроллеров, который в свою очередь может исполнять JavaScript-код, который вы передаёте на плату через serial-соединение, например по USB.

Espruino — это open source проект, фаундером которого является Gordon Williams. Человек, который в одиночку реализовал большую часть всей экосистемы и успешно сходил с ней на KickStarter.

Эта экосистема состоит из нескольких основных частей:

• Espruino Web IDE — среда программирования;
• Espruino Firmware — JavaScript-машина, которая крутится на микроконтроллере;
• Железо — сами платы, которые совместимы с Espruino;
• Стандартная библиотека и внешние библиотеки;
• Документация.

Обо всём по порядку.

Среда программирования

Написание JavaScript-кода, загрузка его в плату и наблюдение за выводом происходит в Espruino Web IDE. Это приложение для Google Chrome, поэтому оно ставится в 1 клик и работает под всеми настольными операционками.

Для пользователя эта среда заменяет Arduino IDE.

По функционалу Espruino IDE, конечно, много проще полновесных Eclipse или Visual Studio, но она более продвинута, чем Arduino IDE.

Если окинуть окно среды одним взглядом, увидите окно для кода (справа), окно консоли (слева) и кнопку для загрузки кода в плату.

Консоль — это как Serial Monitor в Arduino IDE, но в отличии от него он не только выводит, но и принимает: можно прямо налету, без ресета и загрузки новой программы, вызвать функцию, посмотреть значение переменной, прервать цикл и т.п.

Поработав плотнее, вы столкнётесь с отладчиком (ага, step-by-step исполнение, breakpoint’ы), подсказками редактора, подсвечиванием ошибок налету и прочими приятными фишечками.

Кроме того, прямо из IDE можно обновить версию самой Espruino Firmware до последней. Среда сама сама скачает последний доступный релиз и зальёт его через USB.

Firmware

Сердце системы — прошивка, которая крутится на микроконтроллере. Она написана на чистом Си, загружается единожды в отдельное место флеш-памяти микроконтроллера и занимается тем, что исполняет пользовательский JS-код, который приходит через последовательное соединение или находится в пользовательской области флеш-памяти.

Если схематично изобразить расклад флеш-памяти для Iskra JS, получим такую картину:

Загрузчик

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

Загрузчик делает довольно простую вещь:

• Если не нажата пользовательская кнопка BTN1, тут же передаёт управление интерпретатору.
• Если кнопка была нажата при старте, он зацикливается на себе и ждёт либо пока кнопку нажмут ещё раз, чтобы таки выйти в интерпретатор, либо ждёт пока через USB загрузят новую версию интерпретатора. В этом случае bootloader перепишет область флеш-памяти с Espruino Firmware, а мы получим на плате свежую версию интерпретатора.

Интерпретатор

Итак за загрузчиком следует интерпретатор, который и делает основную работу.

Когда он стартует, проверяет с помощью проверки волшебного байта, есть ли в пользовательской флеш-памяти сохранённый код JavaScript. Если есть, принимается его исполнять.

Если кода нет или же, если мы вручную с помощью BTN1 вышли из загрузчика, ничего слёту исполнено не будет, мы просто получим готовую к работе JS-машину.

Свободная память

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

Пользовательский код

Здесь хранится та JS-программа, которую выполняет интерпретатор. Программа лежит там в обычном текстовом виде, одним брикетом, как есть.

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

Вернее, всю работу делает не IDE, а её GUI-независимая составная часть EspruinoTools, у которой есть интерфейс коммандной строки и точка входа для использования в качестве Node.js-модуля. Поэтому при желании вы можете использовать Vim, Atom, Eclipse или чего вам удобнее для разработки.

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

Библиотеки

Библиотеки можно разделить на 3 вида: стандартная, встроенные и внешние.

Стандартная библиотека

Стандартная библиотека — это функции и объекты, которые можно слёту использовать. Среди них, как привычные и прописанные в стандарте языка `Date`, `JSON`, `Math`, `Object`, `setInterval`, `setTimeout` и прочие-прочие, так и специфичные для Espruino функции для работы с пинами, интерфейсами, памятью.

Среди функций вы найдёте привычные ардуинщику `pinMode`, `digitalRead`, `digitalWrite`, `analogRead`, `analogWrite`, а ещё не столь привычные `setWatch` для наблюдения за входными пинами, `digitalPulse` для точной генерации последовательности цифровых импульсов и ещё много разных штук для работы с периферией.

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

Чего вы не найдёте в стандартной библиотеке, так это `delay`. Mamma Mia, как я благодарен за это! Достаточно немного перестроить мышление и становится ясно, что всё решается через `setInterval`, `setTimeout` без всякого `delay`.

В благодарность вы получаете асинхронность исполнения: можете мигать двадцатью светодиодами независимо, каждым со своей частотой. А ещё вы получаете энергоэффективность: `delay` — это прожигание процессорного сремени, а без `delay` процессор может мирно спать пока нечего делать. В Espruino пока нет работы процессор засыпает и потребляет в десятки раз меньший ток.

Встроенные библиотеки

Встроенные библиотеки — это такая же часть стандартной библиотеки в том смысле, что они жёстко вшиты в Espruino Firmware, но для доступа к их функционалу требуется синтаксически их подключить с помощью знакомой JavaScript-программистам функции `require`.

Среди таких библиотек вы найдёте, например, `fs` для работы с файловыми системами SD-карт, `http` для создания web-интерфейса к своему устройству, `Waveform` для записи/воспроизведения аудиосигналов и другие.

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

Вы и сами можете реализовать на Си что-то, на что JavaScript сказал бы «нет, спасибо», а наружу вывести только несколько необходимых для запуска хвостов.

Внешние библиотеки

Внешние библиотеки — это то, что формирует богатство экосистемы. Их пишут на JavaScript авторы Espruino, мы пишем, пишут пользователи Espruino.

Храниться они могут на локальном диске, в песочнице текущего проекта, могут быть в интернет-репозитории, могут быть на GitHub’е, могут лежать на NPM’е.

Подключаются библиотеки, традиционно, с помощью `require`.

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

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

Железо

Вот мы и подошли к самому осязаемому компоненту экосистемы Espruino. Это платы, которые могут исполнить Espruino Firmware.

К ним относятся оригинальные Espruino Board, Espruino Pico, а также выпущенная Амперкой Iskra JS. На перечисленных платах всё уже установлено на заводе, они сразу готовы к работе.

Вы можете несколько раз стукнуть в бубен и самостоятельно поставить Espruino-ядро на STM32 Discovery, Nucleo и, внезапно, на ESP8266.

Документация

Нет ничего грустнее, чем что-то очень крутое и мощное, но без документации.

У Espruino — неплохая документация. На www.espruino.com/Reference вы найдёте много справочных и обучающих статей.

Мы хотим сделать ещё больше и лучше. Поэтому создали отдельный раздел: js.amperka.ru, снимаем видеоуроки. Работа пока в процессе, но многое уже освещено.

И традиционно для тех, кто любит коробочные решения, мы создали набор «Йодо». В нём Iskra JS, модули и цветная книга.

Вот такая петрушка. Загадкой остаётся лишь то, смог ли хоть один правильный электронщик дочитать до этой строки?

ссылка на оригинал статьи https://geektimes.ru/post/273664/

Зачем AdBlock Plus и другие расширения, если все интегрировано?

Одним из наиболее неожиданных шагов корпорации Microsoft в свое время стал полный отказ от наследия Internet Explorer в пользу нового браузера Edge. Развивается Edge не очень быстро, но вскоре должно выйти крупное обновление, которое будет включать ряд интересных элементов.

К примеру, возможность добавления JavaScript расширений, подобных тем, что давно уже радуют пользователей Google Chrome. Сейчас эта функция доступна в превью-релизах, причем одно из первых расширений — AdBlock Plus. Но это не все. В планах корпорации — убрать необходимость в сторонних блокировщиках рекламы. То есть, планируется интегрировать функционал блокировщика рекламы прямо в Edge. Никаких расширений, все нативно.


«Дорожная карта» работы по Edge

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

Сейчас блокировка рекламы стала мейнстримом — многие крупные компании стали встраивать нечто подобное в свои продукты. Та же корпорация Apple добавила возможность блокирования рекламы в Safari для мобильных устройств.

Пока что не совсем ясно, когда появится новый Edge со встроенным блокировщиком. Скорее всего, летом этого года, после выхода крупного обновления для Windows 10.

ссылка на оригинал статьи https://geektimes.ru/post/273662/

Кратко о главном

В Apple Developer Center с незапамятных времен применяется довольно мудреная система подписи ваших приложений на каждом из основных этапов — разработка, тестирование и публикация.

Зачастую при первом погружении в эту систему у начинающих (и не только) разработчиков возникают серьезные проблемы с пониманием того, как функционирует Apple Developer Center (будем называть его «девцентр» для простоты). В результате, мне в процессе профессиональной деятельности не раз приходилось наблюдать на новых местах работы огромные свалки из профилей и сертификатов в девцентре, в результате чего приходилось приступать к «разбору завалов».

При этом, в сети довольно не такой большой выбор материалов на эту тему. Конечно, в официальной документации Apple все хорошо структурировано и очень подробно описано, но зачастую просто не хватает времени на изучение такого количества материала. Как правило, хочется быстро понять, что именно и в каком порядке нужно сделать для корректной работы приложения на этапах разработки, тестирования и при публикации его в магазин App Store. В русском же сообществе подобных материалов, собранных в одном месте и в удобном доступе, я не видел вовсе, поэтому и решил написать эту статью. Для всех интересующихся — добро пожаловать под кат.

Что мы будем разбирать?

Мы разберем процесс управления вашим приложением в Apple Developer Center от его создания до публикации в магазине App Store. Мы будем говорить только о базовых вещах, таких, как разработка, тестирование и публикация, а также обсудим APNs (Push Notifications).

Отмечу тот факт, что далее я буду описывать принцип работы девцентра по состоянию на 31 марта 2016 года, поэтому если вы читаете эту статью позднее — все уже могло измениться.

Что нам понадобится?

Собственно, для работы нам нужно следующее:

• Рабочий Mac, либо PC с виртуальной машиной и установленной на ней Mac OS.
• Действующий Apple ID. Его всегда можно бесплатно зарегистрировать на официальном сайте компании Apple.
• На вашем Apple ID (либо у одной из компаний, которая добавила ваш Apple ID в свою команду) должна быть активирована так называемая Apple Developer Program — оплачиваемая раз в год «подписка», дающая вам доступ к Apple Developer Center и возможность публиковать ваши приложения в App Store. На текущий момент стоимость в пересчете на год невелика и составляет в районе $99 за год пользования.
• И, конечно же, навыки разработки под iOS.

Ориентировка по разделам

В девцентре для полноценной работы с вашими приложениями нам понадобятся только два пункта:

• Certificates, Identities & Profiles.

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

• iTunes Connect.

  Дает доступ к внутреннему и внешнему тестированию через TestFlight, а также к управлению публикацией ваших приложений в App Store.

Терминология

Давайте подробно разберем понятия, лежащие в основе функционирования девцентра Apple.

Сертификаты (Certificates)

Этот раздел дает доступ к управлению сертификатами, которыми обладает ваша учетная запись Apple ID. Каждый из этапов, которые вы будете проходить, будь то разработка, тестирование или публикация, включая все значимые составляющие экосистемы Apple вроде Push Notifications, требует обязательного наличия актуального (действующего, Active) сертификата. Говоря проще, ваше приложение не сможет даже чихнуть, не имея на то разрешения из Apple Developer Center. Чуть подробнее о подразделах:

• Pending.

  Запрошенные вами сертификаты, находящиеся в процессе обработки от Apple. Для дев (Development) и прод (Production) сертификатов конкретно в моем случае этот подраздел чаще всего пустует.

• Development.

  Дев-сертификаты, обеспечивающие возможность отладки вашего приложения на конкретных девайсах (одном либо нескольких) через Xcode. Более подробно поговорим о них чуть ниже.

• Production.

  Прод-сертификаты, обеспечивающие работоспособность приложения при тестировании в TestFlight и при публикации в магазине App Store.

Теперь разберем типы сертификатов.

Сертификаты типа «Development»

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

Инструкция по этому процессу будет показана вам в девцентре Apple при начале создания сертификата, там все расписано очень подробно и понятно, по шагам, сложностей возникать не должно. Если вкратце, то после выбора типа сертификата (iOS App Development, для отладки приложения, либо APNs Sandbox, для отладки пушей) вам придется создать файл запроса к бюро сертификации (Certificate Signing Identity Request), на основе которого и будет сгенерирован девелоперский сертификат. Если вы хотите и отлаживать приложение, и отлаживать пуш-нотификации в «песочнице», то вам потребуются оба этих сертификата. Забегая вперед, упомяну, что аналогичный процесс применяется и при создании прод-сертификатов.

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

Сертификаты типа «Production»

Для начала на всякий случай поясню, что сборкой iOS-приложения называют *.ipa-файл, архив, выпускаемый с соблюдением правил сертификации Apple через команду Project — Archive в Xcode.

Теперь о сертификации. Прод-сертификаты обеспечивают функционирование различных подсистем приложения в «боевых» условиях, то есть в магазине App Store, а также на устройствах, где выполняется внутреннее и внешнее тестирование приложения через TestFlight. Здесь, по аналогии с Development-сертификацией, есть тип App Store & Ad Hoc Production, а также тип APNs Production, использующийся веб-сервером для рассылки push-уведомлений. Если вы планируете выпустить приложение, поддерживающее работу с пушами, то вам понадобятся оба сертификата, как App Store & Ad Hoc (на основе которого вы сделаете сборку и отправите приложение в iTunes Connect), так и APNs Production (его вы отдадите серверу, а тот воспользуется им для получения прав на рассылку пушей). В довесок к уже упомянутым подсистемам есть еще несколько других, обеспечивающих доступ к Wallet, Apple Watch и так далее, но их обзор выходит за рамки данной статьи.

Очень часто возникает вопрос о том, в чем же разница между App Store и тем самым Ad Hoc. Ранее они были представлены разными сертификатами, с некоторого времени Apple объединила их в единое целое, за что им большое спасибо. Чуть подробнее об этих разновидностях:

• Выпуск сборок типа App Store.

  Обеспечивает возможность тестировать приложение в TestFlight, как в режиме внутреннего, так и в режиме внешнего тестирования. Также дает возможность опубликовать приложение в App Store.

• Выпуск сборок типа Ad Hoc.

  Термин «Ad Hoc» можно перевести как «специальный», «для конкретной цели». Такой тип сертификации обеспечивает возможность запускать ваше приложение (включая все нужные подсистемы типа APNs) в боевых условиях, но только на конкретных девайсах, и без участия Xcode в процессе запуска. Другими словами, Ad Hoc необходим, если вы захотите поставить ваше приложение на стороннее устройство, не имея к нему прямого доступа (то есть не подсоединяя его проводом к вашему Mac, так как в этом случае вам бы хватило Development-сертификата), но при этом и не выкладывая приложение в iTunes Connect. Такой сертификат используется при создании специального Ad Hoc-профиля, о котором пойдет речь чуть позже.

Intermediate Certificates

Некоторое время назад Apple внесла изменения в логику работы девцентра и своей системы сертификации, после чего на большинстве компьютеров пропала возможность делать сборки приложений, несмотря на наличие активных дев- и прод-сертификатов и актуальных профилей. Причина этого была в том, что Apple добавила дополнительное требование, чтобы на вашем Mac в связке ключей был установлен специальный сертификат под названием «Worldwide Developer Relations Certificate Authority». Он устанавливается автоматически с новыми версиями Xcode, но те, у кого Xcode уже был установлен ранее, просто должны были установить этот сертификат вручную, скачав его по прямой ссылке из секции Intermediate Certificates в девцентре Apple, после чего проблемы со сборками исчезали. Больше никакой смысловой нагрузки этот сертификат не несет.

Идентификаторы (Identities)

Данный раздел обеспечивает управление идентификаторами. Для вашего приложения в минимальном исполнении понадобится App ID, управление которыми доступно в одноименном подразделе.

В буквальном переводе «App ID» означает «идентификатор приложения», что полностью отражает его суть. Любое ваше приложение, которое вы хотите отлаживать на устройстве Apple, тестировать через TestFlight и/или публиковать в магазин App Store, должно обладать собственным уникальным именем, по которому его можно однозначно идентифицировать среди тысяч других приложений. При добавлении нового App ID вам будет предложено ввести несколько элементов:

• App ID Description.

  Имя вашего приложения. К примеру, если ваше приложение называется Mail Printer, то прямо так его и записываем в это текстовое поле.

• App ID Prefix.

  Префикс вашего приложения, он выдается вам автоматически и будет общим для конкретной команды Apple Team, где подключена и активна Apple Developer Program.

• App ID Suffix.

  Здесь нам понадобится выбрать Explicit App ID, чтобы указать бандл (bundle) приложения. Это идентификатор, обычно имеющий вид com.mycompany.myappname, где mycompany — имя вашей компании или вашего домена. Например, com.homecompany.MailPrinter. Обращаю ваше внимание, что точно такой же бандл должен быть выставлен в настройках таргета (Target) вашего приложения в Xcode (секция настроек General, поле Bundle Identifier).

• App Services.

  Здесь вам нужно отметить те сервисы, которые вы планируете использовать в вашем приложении. По умолчанию там отмечены только Game Center и In-App Purchase, их использование обязательно, удалить их нельзя. Остальные сервисы подключайте по мере необходимости.

После создания App ID вы можете использовать его для генерации любых типов профилей, об этом чуть позже.

Устройства (Devices)

В этом разделе размещено управление всеми устройствами Apple, которые вы можете использовать в рамках вашей Apple Developer Program. Есть ограничение, максимум 100 зарегистрированных девайсов на одну учетную запись в год, обычно этого более чем достаточно. При необходимости отладки на устройстве или выпуска Ad Hoc-сборки просто добавляйте сюда UDID нужных вам девайсов и используйте их при генерации профилей.

Профили (Provisioning Profiles)

Дословно название этого раздела переводится как «Профили обеспечения». Чуть более развернуто я бы описал понятие «профиль» как «Специальный файл, обеспечивающий доступ к некоторой функциональности в конкретной сборке вашего приложения». В данном разделе девцентра вы можете управлять вашими профилями, обеспечивая себе возможность выпускать сборки приложения для различных целей, то есть «профилировать» его. По сути, профиль является результатом объединения двух (иногда трех) компонентов:

• Активного сертификата определенного типа (раздел Certificates). С помощью сертификата профиль подтверждает, что ваше приложение имеет право на выполнение определенной группы действий.
• App ID (раздел Identities). Определяет конкретное приложение, для которого выпускается профиль.
• В некоторых случаях, еще нужен список зарегистрированных устройств (раздел Devices). Определяет перечень устройств, на которые разрешено устанавливать вашу сборку. Используется только с некоторыми типами профилей.

На выходе как раз и получаем профиль для выпуска сборок с определенными целями. Давайте рассмотрим разновидности профилей.

Профили типа «Development»

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

• iOS App Development.

  Требует указания перечня разрешенных устройств из раздела Devices.
  Используется для отладки iOS-приложений.

• tvOS App Development.

  Аналогично, только используется для tvOS-приложений.

Профили типа «Distribution»

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

• App Store.

  Используется для тестирования (как внутреннего, так и внешнего) в TestFlight, а также для выпуска приложения в App Store.

• tvOS App Store.

  Аналогично предыдущему, только для tvOS.

• Ad Hoc.

  Требует указания перечня разрешенных устройств из раздела Devices.
  Используется, если вы хотите выпустить сборку, которую можно будет поставить в режиме «Production», но только на некоторых устройствах. Реальная ситуация, когда это может понадобится, например, следующая. Вы разрабатываете приложение, а в процессе работы заказчик попросил у вас «дать ему пощупать приложение» на своем Apple-устройстве. В iTunes Connect для активации внешнего тестирования вы еще выходить не готовы, но просьбу заказчика нужно выполнять — вот тут как раз и пригодится Ad Hoc-профиль, сгенерированный на базе прод-сертификата App Store & Ad Hoc Production Certificate.

• tvOS Ad Hoc.

  Аналогично предыдущему, только для tvOS.

Вкратце об iTunes Connect

Этот сервис предоставляет вам возможность управлять внутренним и внешним тестированием в TestFlight, а также выкладывать приложение в App Store. Рассмотрение этого процесса выходит за рамки данной статьи, упомяну лишь тот факт, что для корректной работы этому сервису необходимы сборки, созданные на базе профиля типа Distribution — App Store (для iOS либо tvOS). Другие типы профилей здесь не поддерживаются.

Резюмируем

По сути, ваш алгоритм действий должен сводиться к следующему:

1. Определиться, с каких конкретно машин будет производиться прямая отладка на устройствах через Xcode. Сгенерировать для каждого из этих Mac сертификаты группы Development (генерировать их нужно на базе Certificate Signing Identity Request, который вы должны получить с каждого нужного вам Mac).
2. Узнать, с какой машины планируется собирать сборки для тестирования и/или публикации в App Store. Сгенерировать для нее (или них, если их несколько) сертификат группы Distribution.
3. Проконтролировать наличие нужного идентификатора приложения в App ID и соответствие указанного там бандла соответствующему Bundle Identifier в проекте в Xcode, при наличии несоответствия — устранить его либо в девцентре, либо в Xcode (где именно это править — зависит от вашей конкретной ситуации).
4. Убрать (Revoke/Delete) все сертификаты, а затем и профили, которые обладают пометкой Expired (истекший сертификат) или Invalid (некорректный профиль). Также отмечу, что, в отличие от сертификатов, профили можно редактировать. То есть, сгенерировав новые сертификаты, вместо удаления старых профилей вы можете просто отредактировать их, указав им новые сертификаты в качестве подписи.
5. Если профилей нет, либо не хватает нужных, то сгенерировать необходимые профили.
6. Скачать и установить нужные для вашей машины сертификаты и профили на свой компьютер. Установка производится двойным кликом на файле. Сертификаты будут установлены в Связку Ключей (Apple Keychain), профили — в Xcode.
7. Установить в настройках проекта Xcode нужные вам сертификаты в секции Build Settings — Code Signing Identity — Development/Distribution, а также указать необходимый Provisioning Profile.

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

• Произвести запуск в режиме отладки (Project — Run) через Xcode на разрешенном устройстве, используя дев-профиль.
• Создать сборку (Project — Archive с выбранным целевым устройством Generic iOS Device) на базе продакшн-профиля Ad Hoc для установки на конкретные устройства (такую сборку можно будет выслать, например, по электронной почте заказчику, чтобы он установил ее на свое разрешенное устройство).
• Создать сборку аналогично предыдущему пункту, но на базе продакшн-профиля App Store. Это будет сборка для внутреннего и/или внешнего тестирования, а также для выкладки в App Store, которую можно использовать в iTunes Connect.

Надеюсь, это подробное описание поможет вам разобраться в специфике функционирования системы сертификации приложений Apple, а также поможет навести порядок в Apple Developer Center.

ссылка на оригинал статьи https://habrahabr.ru/post/280626/