Нативный русский язык из Xorg в rdesktop — мелочь, а приятно

У всех людей свой опыт использования Linux десктопа, но лично для меня очень важным является тандем linux desktop + rdesktop в виртуальные машины. Причины тому — определенный софт, который зачастую работает только под Windows, или работает под Windows лучше, а также необходимость тестировать всякие виндовые штуки.

Такая конфигурация рабочего стола ставит назойливую проблему — в Windows свои языки и их переключение, в Linux — свои, соответственно постоянно попадаешь в необходимость 3-4 раза переключиться, пока не получится. Тем более, если в Xorg язык выбирается не пооконно, а глобально.

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

Суть проблемы заключается в том, что технология RDP предполагает передачу сканкодов, а не каких-то конкретных символов. Соответственно в rdesktop есть штатные keymap’ы, которые автоматически выбираются исходя из текущей локали.

Таким образом необходимо:
1. Создать специальную раскладку для Windows, в которой одновременно будут присутствовать как английские, так и русские символы, выбираемые каким-то модификатором.
2. Сделать keymap, который будет передавать русские буквы как сканкод с модификатором. Штатный keymap «ru» сделан так, что он отправляет русские символы как AltGr+сканкод. В нем не хватает только символа «№».

Такие раскладки существуют (например Cyrilock), но ни одной нормально работающей я не нашел, поэтому используя Microsoft Keyboard Layout Creator v1.4 я сделал свою. MKLC собирает dll раскладки и делает ей инсталлятор. На кнопках в ней определены английские символы, русские символы определены как AltGr+кнопка (из цифр определить нужно только 3 — №, остальные передаются корректно).

Для работы нужно два файла:
1. Скачать установщик раскладки, установить ее на Windows и оставить единственной. Если вы будете подключаться не через rdesktop, а через консоль — английский язык работать будет, русские буквы можно набирать через Ctrl-Alt.

В линуксе необходимо положить keymap в глобальный (/usr/share/rdesktop/keymaps) или пользовательский (~/.rdesktop/keymaps) каталог.

Несколько нюансов:
1. В keymap добавлено значение ISO_Next_Group 0x0, чтобы нажатие кнопок переключения языка не передавалось на ту сторону и упомянутый выше знак №.
2. Для справки — у меня переключение осуществляется через Caps Lock, индикатором и пооконным контроллером переключения занимается gxkb.
3. Если вы исправляете раскладку и собираете ее через MKLC — всегда называйте ее по разному и перезагружайте машину, он постоянно цепляет старые версии библиотеки раскладки. Перед перезагрузкой ее лучше всего деинсталлировать.
4. В Windows реальное положение раскладок не всегда соответствует настройкам клавиатуры, иногда там появляются лишние. Верное состояние показывает только панель переключения языка.
5. MKLC зачастую не в состоянии исправить название раскладки, для этого ее надо загрузить из установленных в системе и пересохранить исходный файл.

Ссылки:
1. Инсталлятор готовой раскладки.
2. Keymap rdesktop.
3. Исходник раскладки для MKLC v1.4.


ссылка на оригинал статьи https://habr.com/post/421971/

Генерация последовательности дат и generate_series в PostgreSQL

Велопредупреждение

Данная статья может оказаться сферическим примером велосипедостроения. Если вам известно стандартное или более изящное решение задачи, то буду рад увидеть его в комментариях.

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

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

Для генерации периодов внутри интервала я привычно взял функцию generate_series, которую часто использую для генерации числовых последовательностей. Сверился с документацией насчет возможности генерации последовательности дат, рассмотрел пример, написал запрос и озадачился.

select gs::date from generate_series('2018-01-31', '2018-05-31', interval '1 month') as gs;

gs
31.01.2018
28.02.2018
28.03.2018
28.04.2018
28.05.2018

Результат оказался столь же неожиданным, как и логичным. Функция generate_series по честному итерационно сгенерировала последовательность дат по принципу последовательного прибавления сдвига к предыдущему значению. При этом на каждом шаге проверялась корректность и правка полученной даты. 31 февраля не бывает, поэтому дата преобразовалась в 28 февраля и дальнейшее прибавление месяца сбила всю последовательность на 28 число.

Интересно как поведет себя операция сложения с несколькими месяцами сразу? Что будет если мы будем прибавлять интервал не итерационно, а «оптом»?

select '2018-01-31'::date +interval '1 mons' 28.02.2018  select '2018-01-31'::date +interval '2 mons' 31.03.2018

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

Если известно количество месяцев, то очень просто:

select '2018-01-31'::date +make_interval(0, i) as gs from generate_series(0, 4, 1) as i

gs
31.01.2018
28.02.2018
31.03.2018
30.04.2018
31.05.2018

Что делать если известны только дата начала и дата конца?
Данную задачу можно довольно просто решить написанием хранимой функции и простым циклом в ней, однако нас интересует вариант реализации когда нет возможности или желания засорять структуру БД лишними объектами.
Попробуем свести задачу к предыдущей.

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

/* Вводим что-то типа переменных, чтобы в едином месте можно было вводить входные данные, когда нет возможности использовать параметры */ with dates as (     select '2018-01-31'::date as dt1, '2018-05-31'::date as dt2  ), /* Вычисляем разницу между датами в "иерархических" единицах */ g_age as (     select age( (select dt2 from dates), (select dt1 from dates)) ), /* Считаем сколько месяцев в полученной разнице (годы*12 + месяцы) и добавляем +1 месяц на возможную потерю при округлении  */ months as (     select (extract(year from (select * from g_age))*12 +        extract(month from (select * from g_age))+1)::integer ), /* Количество посчитано, генерируем последовательность и добавляем проверку на выход из первоначального диапазона из-за возможного лишнего месяца, который мы добавили как корректировку округления */  seq as(   select ((select dt1 from dates) + make_interval(0, gs)) as gs   from  generate_series (       0,       (select * from months),       1   ) as gs    where ((select dt1 from dates) + make_interval(0, gs)) <= (select dt2 from dates) ) /* Ну и собственно смотрим что у нас получилось */ select * from seq

gs
31.01.2018
28.02.2018
31.03.2018
30.04.2018
31.05.2018

Решение получилось достаточно громозким, но рабочим и его достаточно просто интегрировать в другие запросы через механизм with.
Отчет мы реализовали, однако мысль что этот запрос мало того, что громоздкий, так еще и ограничен в своем использовании только шагами по целым месяцам не давал покоя.

Вариант 2.
Спустя время меня осенило, что последовательная генерация дат по сути рекурсивная процедура. Только не в чистом виде, так как в нашем случае расчет следующей даты от предыдущей приводит к первоначальной проблеме. Зато на каждом шаге мы можем увеличивать интервал, прибавляемый к началу нашего периода:

/*  Снова определяем наши псевдопараметры-псевдопеременные, расширив их тип до timestamp */ with recursive dates as (     select             '2018-01-31'::timestamp as dt1,             '2018-05-31'::timestamp as dt2,            interval '1 month' as interval ), /* Реализуем рекурсивный запрос в котором на каждом шаге увеливается целочисленный счетчик, а каждая следующая дата получается из первоначальной путем прибавления интервала, умноженного на счетчик. Останавливается генерация, когда вновь полученная дата выходит за границу периода*/ pr AS(     select         1 as i,         (select dt1 from dates) as dt     union      select          i+1 as i,          ( (select dt1 from dates) + ( select interval from dates)*i)::timestamp as dt     from pr     where ( ((select dt1 from dates) + (select interval from dates)*i)::timestamp) <=(select dt2 from dates) )  select dt as gs from pr;

gs
31.01.2018
28.02.2018
31.03.2018
30.04.2018
31.05.2018

Данный запрос корректно работает с любыми входными временными отрезками и интервалами.


ссылка на оригинал статьи https://habr.com/post/421969/

Детская игрушка на логических элементах

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

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

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

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

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

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

После некоторых раздумий в голове образовалась схема, в которой тактовый сигнал с помощью трех последовательно подключенных JK-триггеров преобразовывается в двоичный код, а затем с помощью логических схем — в восьмеричный. Детально о данном виде триггеров можно почитать хотя бы на Википедии. Если коротко, то у него есть два входа (J и K) и два выхода (Q и Q̄ ), а также вход синхронизации (CLK). При подаче логической единицы на один из входов при следующим импульсе синхронизации единица отобразится на соответствующем выходе и сохранится на нем независимо от того, будет ли снова подаваться синхронизирующий импульс и будет ли меняться значение на выбранном вводе при условии, что на втором вводе будет оставаться ноль. Если подать единицу на второй ввод, а на первый ноль, то при следующем импульсе синхронизации значение первого выхода поменяется на ноль, а второго на единицу. А вот если на оба входа триггера подать единицу, то при каждом импульсе синхронизации единица будет попеременно появляться на одном из выходов. И если взять два триггера, на синхронизирующий вход первого подать тактовый импульс, а на синхронизирующий вход второго выход сигнал с выхода Q̄ первого, то в результате выход Q1 будет выводить единицу каждые два такта, а Q2 — каждые четыре. Таким образом получится двухразрядный двоичный счетчик. И если добавить таким же образом третий триггер, то за счет третьего разряда можно досчитать бинарным кодом до восьми — то, что надо.

image

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

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

Решением стала микросхема памяти. Для моей задачи хорошо подходила память EEPROM (Electrically Erasable Programmable Read-Only Memory) — программируемая память с возможностю электрического стирания с параллельным вводом/выводом. У памяти есть насколько адресных входов, которые, по сути, являются разрядами бинарного адреса ячеек памяти. То есть, если у памяти n адресных входов, можно запрограммировать 2^n ячеек. Количество выводов памяти — это так называемая "длина слова", или же фактическая длина бинарной строки, которую можно записать в каждую ячейку. Произведение количества ячеек на длину слов определяет объем памяти в битах.

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

И опять отсутствие опыта не дало мне адекватно оценить сложность процесса. Ведь память нужно запрограммировать, а для этого нужен программатор — прибор ощутимо дорогой для того, чтоб приобрести его для разовой игрушечной поделки. Гугление показало, что теоретически можно было сделать это с помощью Arduino. Но для программирования нужно одновременно подавать сигналы и на адресные входы чипа памяти и на выводы, которые в последствии должны воспроизводить сигнал. А еще нужны сигналы управления записью чипа. То есть, опять больше, чем доступно пинов. Дополнительное гугление открыло для меня сдвиговый регистр — чип, который запоминает задаваемую последовательность нулей и единиц и отображает их на параллельных выходах. Зачастую такие чипы работаю еще и как буфер и имеют выход, который может последовательно воспроизвести сигналы на входе. То есть, если подключить к нему следующий такой же регистр, то можно параллельно отобразить в два раза большую последовательность, чем для одного. По мере ввода строки, первая ее часть пройдет через первый регистр как через буфер на второй, а остальная часть останется на первом регистре. Добавив третий регистр, можно утроить длину строки и т.д. Для реализации этого нужно было написать скетч на незнакомом мне языке программирования. Но имея некий опыт в Python и множество примеров в интернете, после череды проб и ошибок эта задача оказалась вполне выполнима. Скетч можно взять на гитхабе.

И вот скетч написан, микросхема подсоединена, запуск и… ничего — память не программируется. Несколько проб, изменение параметров записи, и никаких результатов. Микросхема у меня была W27C512-45Z. Внимательное чтение мануалов показало неприятный момент. Для записи на определенный контакт микросхемы необходимо подать ток 0.03А напряжением 12В. Я подумал, что просто купил не совсем подходящий чип. Но прошерстив прилавки местных магазинов электро компонентов, я убедился, что 12В нужно всем. Лабораторного блока питания у меня не было. Блоков на 12В в доме полно, но все они импульсные, к тому же ток порядка 1А. Да простят меня опытные инженеры за такое кощунство, но отчаявшись, я решил попробовать, не случится ли чуда с теми блоками, что были под рукой. Не случилось. Первые два прохода записи не дали ничего, а после третьего микросхема перестала подавать признаки жизни.

В интернете я нашел упоминания о некой микросхеме ST662AB — преобразователе 5В-12В — который в сборе с нужным набором конденсаторов должен давать необходимые ток и напряжение. По факту найти микросхему оказалось непросто. В результате заказал ее из Китая, еще и SMD. А что же делать от четырех до шести недель доставки? Правильно, учиться. Пролистывая статьи по программированию памяти, я натолкнулся на упоминание о микросхеме, которую можно программировать при 5В. Речь шла о AT28C256. И действительно, в даташитах к ней никакого упоминания о 12В не было. Нужно брать! Правда микросхема для моих нужд была немного избыточна, так как позволяла сохранить 256Кб: 8-битный выход для 32К адресов, что с учетом занятых трех адресных пинов для сигналов синхронизации строк, оставляло возможность закодировать аж 4096 изображений (мне бы хватило и 10). Кроме того, доставку пришлось сделать аж из Великобритании. Но других вариантов я не нашел, и в конце концов, память можно повторно перепрограммировать, и когда игрушка утратит актуальность, чип можно будет использовать где-то еще. Так через четыре дня память была у меня. Тестовый прогон скетча, и счастье — все работает.

Осталось последнее — решить, сколько будет кнопок, нарисовать картинки 8х8 и реализовать добавление сигналов от кнопок в схему. Прикинув место на доске, я остановился на пяти кнопках. Учитывая никчёмный спрос в сравнении с ресурсом памяти, самым простым способом было подавать сигнал от каждой кнопки напрямую на отдельный вход, не применяя никакого кодирования. Правда, пришлось решать еще задачу переключения между картинками. Можно было использовать кнопки с фиксацией нажима. Но такая реализация не подходила для использования годовалым ребенком, ведь тогда перед нажатием на следующую кнопку надо было отжать работающую, да и была достаточно примитивна сама по себе. Хотелось придумать схему для кнопок без фиксации, при которой нажатие каждой кнопки бы сохранялось, да еще и отменяя нажатие предыдущей. Я читал про особенности применения разных видов триггеров, надеясь что какой-то из них может решить эту задачу самостоятельно, но увы. Посидев немного с листком и карандашом, я придумал следующую схему (пример для трех кнопок).

Вначале необходимо все кнопки подключить на некий коллектор, который на выходе будет давать единицу при нажатии на любую из кнопок. Для этого подойдет OR ключ. Так как чаще всего микросхемы ключей имеют только два входа, необходимо подключить первые две кнопки на один ключ, далее его выход подключить на первый вход второго ключа, а на его второй вход — третью кнопку. Таким способом можно продолжить подключать больше кнопок, добавляя новый ключ для каждой последующей. Кроме того, каждую кнопку нужно подключить на отдельный XOR ключ и на J вход отдельного JK-триггера. На второй вход XOR ключей подключить выход OR буфера, а выход каждого XOR ключа — на K вход соответствующего JK-триггера. Таким образом, нажимая, например, на кнопку 1, на J1 будет подаваться единица, а XOR1 срабатывать не будет, так как на него подается единица и от кнопки, и от OR буфера. На выходе Q1 также появится и будет сохраняться единица. В то же время сработают XOR2 и XOR3, подавая единицу на K2 и K3. И если на Q2 или Q3 до этого была единица, она сменится нулем.

image

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

image

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

Для сборки всей схемы я хотел заказать готовую плату. Но из списка доступных фирм, предлагавших услуги по изготовлению плат по макету, самый дешевый вариант двусторонней платы мне предложили почти за $25. Не знаю, может это и нормальная стоимость, но мне показалась многовато. Кроме того, у меня совсем нет опыта проектирования макетов. И еще я нахожу процесс пайки очень приятным и успокаивающим. Поэтому я купил универсальную плату, рулон разноцветной проволоки, необходимые компоненты и на несколько вечеров засел за сборкой. Так как все компоненты работают от напряжения от 5В до 12В. Для удобства, я сделал питание от батарейки 9В.

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

Спасибо за внимание.


ссылка на оригинал статьи https://habr.com/post/421967/

«Кроме работы я еще работаю» — 10 вопросов программисту, третий выпуск

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


Дима Трабо, 22 года, андроид-разработчик днем, музыкант и звукорежиссер ночью. Выпускник ИГЭУ, основной язык — Java, но еще знает C, Kotlin, Assembler, C# и JS.

1. Расскажи о фиче, которую ты реализовал и которой гордишься.

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

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

Ну и помню как в универе гордился, что получилось сделать некое подобие стробоскопа, реагирующего на определенный диапазон частот. Хоть это и было развлечением с Ардуинкой на пару вечеров, но код был знатный. Преобразование Фурье – сила!

2. А теперь — про самый лютый факап.

Факапов постоянно много. Все же стабильность андроида — тема бесконечная. Самые ненавистные траблы появляются при интеграции сторонних продуктов (пальцем показывать не будем) или из-за аппаратных ограничений. Решение подобных проблем уже мутирует в отдельный вид искусства.

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

В самом начале, на самом первом проекте, когда не понимал происходящего, ленился и любил копипастить из stack overflow — накосячил в одном приложении. Скажем так, в условной ленте новостей в определенные лунные сутки посты начинали повторяться через каждые 5-6 постов. При тестировании аномалию не выявили, и все пошло в релиз.

Конечно, никто в тот день не умер. Кроме рейтинга приложения.

3. Опиши свое рабочее пространство: от кресла и монитора до сред программирования и любимых утилит.

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

Рабочий ноут: i5 7-го поколения, 8 ГБ ОЗУ, Windows 10, второй монитор. Все довольно шустро, приятно, хорошо, жалоб нет, только с эмуляторами надо аккуратней. Периодически бывают мысли о маке, потому что UNIX, iossdk + еще несколько фишек.

Из софта — ожидаемая AndroidStudio. Полностью устраивает и радует (хотя может просто сравнить не с чем) + встраиваемые плагины устраняют все недостатки. GitHub — способ скоротать свободное время. Боготворю GitKraken. Ну и вспомогательные: Postman, SublimeText, DBeaver.

4. По какому принципу ты выбираешь работу? Стек, продукт, бытовые условия, деньги?

Это мое первое рабочее место в IT. Я учился на третьем курсе ИГЭУ на кафедре «Пром. электроника и микропроцессорные системы». По традиции на лето мы должны были найти себе практику на распределении и поехать куда-нибудь в места столь отдаленные (на АЭС например). Все, кроме IT компаний выглядело удручающе. Опыта у меня не было, знаний тоже, было только желание.

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

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

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

5. Что в технологиях и языках, которые ты используешь, ты бы хотел исправить?

  • Самое очевидное — кроссплатформенность. В решениях, которые актуальны сейчас, слишком много всевозможных «но». По факту это невыгодно производителям, но хочется верить…
  • Капризы gradle и стабильность при обновлении студии. Увидев оповещение об обновлениях хочется испытывать интерес, а не традиционное «ну охереть теперь».

6. Где лучше перенимать чужой опыт — в вузе, на конфах, на Хабре? Еще где-то?

Самое эффективное – совместная работа с толковыми чуваками. Тут сразу все необходимое: новости, советы, идеи, «так не делают, делают вот так», подзатыльники, линки и т.д.

В вузах, как мне кажется, опыта нет — там есть дешевая столовка. Преподаватели старше всего того, что они преподают. Они знают истоки (канон), а все новое — красиво переделанное старое. Поэтому в универе только методические знания, отдельные науки, но не прикладной опыт.

Конфы — интересно, но поверхностно в большинстве случаев.

Хабр — «почитать перед сном». Полезностей много, но и воды тоже.

Книги очень помогают, если написаны человеком.

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

7. Будь у тебя неограниченные ресурсы (время, деньги, мощности, люди), каким проектом ты бы занялся?

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

Из чего-то далекого: интересует био-нейро-кибернетика. Штука фантастическая, но реальная. Да и звучит романтично…

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

8. Как ты отдыхаешь? Что делаешь кроме работы?

Кроме работы я еще работаю. Есть подработка звукорежиссером в кавер-группе. Очень помогает отвлечься. Частые поездки, новые лица, иногда просто фантастические мероприятия не дают появиться ощущению, что сижу на одном месте.

Я люблю музыку, но IT-сфера более обширна, стабильна и независима. Заработать опыт крутого звукаря, сделать имя и цену набить в РФ — это подвиг.

9. Расскажи про три любимые книги — учебную, научно-популярную и художественную.

Учебная: Мне почему-то кажется, что они все почти одинаковые, но пусть будет Шилдт «Java8. Полное Руководство», «Паттерны проектирования в Java» (автора не помню).
Сейчас начал Блох «Effective Java», но рано еще давать оценку.

Научпоп: в голову приходит Эриксон «Искусство Эксплойта». Очень громкое название, но перечитывать точно буду. Я еще нигде не видел, чтобы в таком маленьком объеме так много всего было. Красивая подводка, основные фишки С и программирования вообще, дальше основы ассемблера и, что наверное самое крутое, взаимосвязь одного с другим. Основы сетей, основные хакерские приколы и т.д. Просто очень крутая книга.

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

10. Если прямо у тебя на глазах в ИИ проснется сознание, что ты ему скажешь?

Я бы спросил, чем хорошее отличается от плохого. Ну а дальше скинул исходники на гитхаб.

Вопрос от предыдущего героя: зная, что обратно не вернуться, полетел бы ты на Марс в первой экспедиции?

Это как если бы ты не доделал старый проект, а тебе уже дали новый.

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

Раз уж люди-человеки заселяют Марс, то пусть заселение начнется не с технических новшеств, а с человечности.

Бонус: задай вопрос другому разрабу

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


ссылка на оригинал статьи https://habr.com/post/421965/

Умный город изнутри — взгляд Huawei

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

В теории все выглядит просто, но на деле тем, кто развивает идеологию умного города, приходится сталкиваться с массой барьеров, как типичных для крупных IT-проектов, так и индивидуальных, например, для ЖКХ. И это серьезно усложняет процесс.

Некоторое время назад мы представили свое видение умного города — концепцию Smart/Safe City. Под катом — детальный взгляд на нее с позиции бизнеса и технических специалистов.

Идеи и компоненты

Концепция умного города (Smart/Safe City) включает в себя компоненты из самых разных областей жизнедеятельности, потребителями которой являются как бизнес и госорганизации, так и сами жители городов. И прежде чем говорить о деталях идеи, пройдемся по ее основным составляющим.

Умный транспорт

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

Что может дать бизнесу и городскому хозяйству умный транспорт:

  • управление движением городского транспорта;
  • работы служебных автопарков и таксопарков.

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

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

Безопасность и полиция

Один из наиболее востребованных и проработанных сценариев умного города на сегодняшний день — это безопасность (в контексте защиты от преступности).
Улицы городов по всему миру оснащаются камерами видеонаблюдения, подключенными к единой системе сбора и обработки информации, что позволяет снизить объем преступлений. Хорошо иллюстрирует перспективность этой концепции пример Кении, где по мере развертывания современных сетей связи и реализации проекта «Безопасный город» уровень преступности в среднем по стране за один только 2015 год упал на 46%.

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

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

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

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

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

Умное потребление ресурсов

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

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

В мире есть примеры городов, активно внедряющих умное потребление ресурсов. В частности, Барселона внедрила автоматизированное управление уличным освещением с учетом времени суток и погодных условий. Учитывая благоприятные климатические условия (и серьезные проблемы с загрязнениями городского воздуха), здесь активно используется солнечная энергия — для нагрева воды в зданиях, а также питания интерактивных табло остановок общественного транспорта. При участии города разрабатывается модульная open source платформа Sentilo, собирающая и анализирующая информацию со счетчиков потребления основных ресурсов, датчиков погоды, окружающего шума и т.п. (система работает уже более трех лет, ее работу можно оценить на официальном сайте sentilo.io). В 2015 Барселона удостоилась звания «самого умного города на планете».

Еще один пример — китайский город Шеньчжень (IT-столица Китая), где на базе нашей системы умного города был оснащен датчиками городской водопровод. В общей сложности в системе расставлено порядка двух миллионов датчиков, собирающих информацию с разных точек и позволяющих в режиме реального времени управлять ситуацией с подачей воды.

Другие сферы

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

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

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

Стоит отметить, что разделения отраслей в данном перечне весьма условно. Множество задач решаются на стыке, к примеру, анализа ресурсов и логистики. Хороший пример такого проекта — интеллектуальный сбор мусора в Dubai Silicon Oasis (свободной экономической зоне в Dubai, где активно внедряются технологии умных городов).

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

Кроме того, есть идеи, собирающие в себе решения сразу из нескольких сфер. К примеру, умные офисные здания, являющиеся частью умного города. Smart building внедряет учет и интеллектуальное управление потреблением основных ресурсов на своем уровне, что в конечном счете влияет и на эффективность «работы» систем всего города.

Проблемы внедрения

С точки зрения бизнеса для развития реальных проектов в рамках концепции умного города существует несколько серьезных барьеров, над устранением которых еще предстоит работать.

Барьер 1: неясная экономика

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

Основной камень преткновения — сроки окупаемости проектов. Бизнесу нужны рыночные стратегии, которые дадут прибыль в ближайшие пять лет (в России с учетом экономической ситуации — в течение трех лет), а умный город — это инвестиции в более отдаленные перспективы. И нестыковка бизнес-кейсов — серьезный тормоз развития умного города; это один из основных факторов, из-за которых smart city развиваются пока не так активно, как могли бы.

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

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

Барьер 2: сложности с тиражированием

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

Кстати, в России стоимость основных ресурсов относительно других стран мира сравнительно низкая, что выливается в несколько иную экономику проектов сбережения. Отчасти поэтому концепция умного города у нас начинается с другой стороны — с безопасности. Да, Санкт-Петербург и Москва, в определенной степени, уже оснащены камерами видеонаблюдения. Но в других городах-миллионниках и, тем более в регионах, ситуация с ними много хуже.

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

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

Барьер 3: информационная безопасность

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

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

Барьер 4: legacy

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

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

Концепция Huawei

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

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

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

В теории решение, аналогичное умному городу Huawei, можно построить и на базе открытых или сторонних компонентов. Но тут придется уделить дополнительное внимание вопросу трудозатрат (стоимости), а также последующей поддержке решения. Ведь разработанную инфраструктуру необходимо не только развернуть, но и превратить в работающий инструмент. По опыту других отраслей, где внедряются крупные IT-решения, opensource-проекты живут ровно до того момента, пока не придут серьезные промышленные конкуренты.

Платформа агрегации и анализа данных

Сердцем системы является mediation-платформа агрегации и обработки данных OceanConnect, обеспечивающая работу с миллионами конечных устройств.

В ее задачи входит сбор показаний с большого количества конечных устройств, их анализ и хранение в распределенном хранилище на базе Hadoop.

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

Сетевая инфраструктура

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

Аппаратная составляющая решения подбирается под конкретный проект, у самой Huawei предусмотрен целый класс собственных DCP-решений (развитие Huawei AR с интегрированными стандартами и протоколами IoT), но могут использоваться и сторонние продукты.

Конечные устройства

Для всевозможных датчиков, терминалов и контроллеров мы предлагаем свой чипсет и коммуникационный модуль, а также ОС LiteOS, созданную на базе Linux и ориентированную на IoT. Конечную сборку, производство корпуса и подготовку схемы электропитания, а также разработку ПО на базе официального SDK мы оставляем локальным партнерам.

Конечные приложения

Со стороны приложений у OceanConnect есть открытый API взаимодействия с внешними системами.

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

Взгляд в будущее

Умным городам предрекают большое будущее. Однако когда оно наступит, пока не ясно. Технологически для этого все готово: есть инструменты анализа Big Data, соответствующее серверное оборудование, датчики, способные работать по десять лет без подзарядки аккумулятора, и соответствующие стандарты связи. Но этому рынку очень не хватает технологической стабильности — окончательного выбора доминирующих стандартов и формирования бизнес-моделей, когда станет понятно, как здесь можно работать и зарабатывать.

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

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


ссылка на оригинал статьи https://habr.com/post/421937/