Когда вы работаете в крупной компании, где на рабочих станциях в основном стоит ОС Windows, а вы один из немногих пользователей Linux, то вы тратите определенную долю ваших усилий на преодоление сопротивления недружественной ИТ среды. С годами некоторые проблемы остаются в прошлом, но новые появляются. Так например почти исчезли как класс сайты заточенные только под IE. Все меньше страшных .docx, .xlsx файлов приходит по почте. Куда-то исчезли обязательные для всех чудо-юдо программы, которые написаны только для Windows. Теперь почти все можно открывать и редактировать из веб браузера. Изменилось многое, но не все.

Угадай картинку и получи бейсболку в подарок приз знатока почты. В 2000-м это был почтовик года по версии PC Magazine, и я сам пользовался им пару лет. Только по-честному, без поиска картинок.

Кстати о почте, что с ней? В тех организациях, где используется Exchange Server, постоянно приходят события на календарь и как-то неудобно оправдываться тем, что твой почтовик с не взаимодействует календарем, а Outlook-ом ты не пользуешься, так как его нет на Linux. Как правильно настроить почту, чтобы все работало на Exchange Server: почта, календарь, адресная книга, работа с папками? Статью об этом пишу я эту.

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

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

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

Мне понравилась аналогия, но я не уверен, что готов полностью подписаться на такое; это тот самый тип мышления, который в первую очередь приводит к выгоранию. Хорошо, если вы хотите углубить своё мастерство и расширить навыки, но если делать это непрерывно в течение всего дня — долго не протянешь.

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

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

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

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

Вышел новый релиз блого-социального движка LiveStreet 2.0.

Новые возможности:

• Новая структура файлов движка. Фреймворк полностью отделен от приложения.
• Переработанный фронт на базе компонентов
• Механизм универсальных категорий. Возможность привязки категорий к разным объектам.
• Механизм дополнительных полей (EAV) для различных объектов
• Универсальный механизм управления медиа-файлами
• Управление типами топиков и их кастомизация
• Встроенная поддержка превью-изображений для топиков
• Возможность вставлять в топик несколько опросов
• Система управления правами пользователей
• Центральный крон

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

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

У Lapis Semiconductor есть три линейки FRAM микросхем, которые обмениваются с ведущим устройством по I2C или SPI, либо по параллельному интерфейсу. Преимущества последовательных интерфейсов перед параллельным очевидны. Что же касается I2C и SPI, то скорость передачи данных по SPI в 4 раза выше чем по I2C, но и потребление в связи с этим выше практически в 16 раз.

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

Работа с FRAM памятью очень простая. Любая операция начинается с перевода линии выбора ведомого устройства CS# в низкое состояние. Затем отправляется одна из команд операций, их всего 6:

— Чтение данных(READ)
— Запись данных(WRITE)
— Запись в регистр статуса FRAM(WRSR)
— Чтение из регистра статуса FRAM(RDSR)
— Установка защиты данных от перезаписи(WRDI)
— Снятие защиты данных от перезаписи(WREN)

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

В новогоднем выпуске «Без слайдов» — Максим shafirov Шафиров, CEO компании JetBrains.

Вот о чем мы поговорили с Максимом:

• Важен ли для JetBrains российский рынок?
• Почему Максим не прекращает писать код?
• Насколько помогает догфудинг и в чём его ограничения?
• Почему компания редко закрывает продукты?
• Как появился Kotlin, и какими компания видит его перспективы?
• Почему компания не была продана, несмотря на щедрые предложения?
• Как в JetBrains появилась должность PMM?
• Как JetBrains одновременно конкурируют и сотрудничают с Microsoft?

Как обычно, под катом — полная текстовая расшифровка беседы.

У нас используется система управления проектами и задачами Redmine. Мы продолжаем допиливать ее под свои нужды, чтобы повысить удобство работы и расширить функционал. Очередной задачей стало ускорение поиска.

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

Думаю, всем здесь в той или иной мере известен мессенджер Telegram. Создатель заявляет, что это самый безопасный мессенджер с убойным алгоритмом шифрования собственной разработки, но нас, разработчиков, конечно же, куда сильнее интересует другое. Боты!

Тема эта, конечно, не раз поднималась на Хабре: ботов писали на Python с tornado, Node.js, Ruby со специальным гемом, Ruby on Rails, C#, C# с WCF и даже PHP; ботов писали для RSS-каналов, мониторинга сайтов, удалённого включения компьютера и, вероятно, для многого, многого другого.

И всё же я возьму на себя смелость изъездить эту тему ещё раз и вдобавок к этому показать немного магии Питона. Мы будем писать фреймворк™ для удобного написания нетривиальных диалоговых ботов на основе пакета python-telegram-bot.

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

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

Рис. 1. Порядок отображения группы товаров.

Доброго времени суток, Хабр! Чуть больше года назад была анонсирована ALPHA версия популярной Open Source операционной системы для хранения данных FreeNAS.

На сегодняшний день вышеупомянутый продукт коллективного труда дорос аж до BETA2 и уже неспешно-стремительно движется к своему релизу. Если вам интересно, что же там «напридумывали» разработчики — добро пожаловать под кат.

Здравствуйте, меня зовут Максим и я сотрудник IT отдела одной торговой компании. Как то раз мы с коллегами решили, что нам не хватает в отделе светофора. Мы пока не понимали зачем именно он нам нужен, но непреодолимое "хочу" одолевало нас...

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

Используемые компоненты:

• REACT-CPP;
• AMQP-CPP;
• RapidJSON;
• LevelDB;
• Easylogging++.

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

• player_registered(id,name);
• player_renamed(id,name);
• player_won(id, points).

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

Введение

Последнее время я занимаюсь разработкой настольного Rest API клиента. Довольно большая часть работы состоит во взаимодействии с сервером. Для оптимизации обработки запросов был написан класс Requester, обладающий следующими особенностями:

• возможность отправлять как https, так и http запросы
• использование одной функции для всех типов запросов
• возможность получить все данные по запросу с сервера, а не одну страницу(n записей)

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

Имеется 2 или более устройств на достаточно большом (1-100 метров) расстоянии, между которыми надо передавать данные. Рассмотрев некоторые интерфейсы (rs232/422/485, I2C, Ethernet) пришел к выводу — что они либо не гарантируют однозначную передачу данных, много проводов тоже мне не понравилось, не дают ответ что информация принята. За основу решил взять интерфейс RS485 — из его плюсов он может «далеко идти», 2 провода, можно одновременно подключить кучу приборов, прост, (UART) есть почти на любом контроллере.

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


Один цикл обмена.

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

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

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

В прошлой статье я рассказал об основных понятиях SAN на примере небольших инсталляций. Сегодня копнем глубже и разберемся с построением сетей хранения для крупной организации. Разумеется, одна короткая статья никак не заменит объемные труды Brocade и HP, но хотя бы поможет сориентироваться и выбрать правильный курс при проектировании.

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

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

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

При оценке ботов я использую две группы факторов:

• Юзабилити (удобство использования);
• Создание ценности для пользователя.

Далее в статье я расскажу, как я оцениваю чат-ботов по этим группам.