Кладбище мессенджеров, на котором обязательно должны оказаться Skype, Viber, WhatsApp, Hangouts, ooVoo, Apple iMessage, Telegram, Line, Facebook messenger и еще сотни мессенджеров, которым только предстоит выйти в ближайшее время.

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

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

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

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

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

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

Я смирился с мыслью, что мой лучший код уже написан — в прошлом. Мне было уже 54 года (немало!) и я, вероятно, уже не мог писать код так же хорошо, как и раньше. Кто знает — может быть у меня уже начала отказывать память, ну или я просто выучил всё, что был способен в жизни выучить. Мой настрой подкреплялся наблюдениями окружающей меня реальности. Все новые технологии выглядели для меня чудаковато. Я ненавидел Node.js. Я считал все фреймворки для веб-разработки ужасными. И я сетовал на то, что классические способы разработки ПО разрушились и превратились в набор клише, которые нынче впариваются под умными названиями типа Agile или «экстремальное программирование». Я скучал за днями, когда люди писали спецификацию на будущее ПО, программировали, а затем тщательно тестировали его. И когда в каждой статье не было тысячи жаргонных словечек.

Содержание

1. Что такое тензор и для чего он нужен?
2. Векторные и тензорные операции. Ранги тензоров
3. Криволинейные координаты
4. Динамика точки в тензорном изложении
5. Действия над тензорами и некоторые другие теоретические вопросы
6. Кинематика свободного твердого тела. Природа угловой скорости
7. Конечный поворот твердого тела. Свойства тензора поворота и способ его вычисления
8. О свертках тензора Леви-Чивиты
9. Вывод тензора угловой скорости через параметры конечного поворота. Применяем голову и Maxima
10. Получаем вектор угловой скорости. Работаем над недочетами
11. Ускорение точки тела при свободном движении. Угловое ускорение твердого тела
12. Параметры Родрига-Гамильтона в кинематике твердого тела
13. СКА Maxima в задачах преобразования тензорных выражений. Угловые скорость и ускорения в параметрах Родрига-Гамильтона
14. Нестандартное введение в динамику твердого тела
15. Движение несвободного твердого тела
16. Свойства тензора инерции твердого тела
17. Зарисовка о гайке Джанибекова
18. Математическое моделирование эффекта Джанибекова

Введение

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

1. Окончательно определимся с тем, как использовать параметры Родрига-Гамильтона для описание ориентации тела в пространстве
2. Рассмотрим формы представления уравнений движения свободного тела: покажем как тензорные уравнения можно превратить в матричные и компонентные.
3. Выполним моделирование движения свободного твердого тела при различных соотношениях между главными моментами инерции и покажем, как проявляет себя эффект Джанибекова.

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

Поразительным оказалось то, что практически все операторы, куда обращались журналисты — просто не смогли дать ответы на поставленные вопросы. Единственной компанией, которая согласилась помочь, оказались представители «МТС Украина». Оператор Life :) — вообще не дал ответа на направленный запрос, а в «Киевстар» ответили, что не являются экспертами в таких вопросах, и что с такими вопросами нужно обращаться в специальные госслужбы (читайте, МВД, СБУ, и т.д.) В статье ниже была так же использована информация о прослушивании мобильных телефонов, полученная из публичных источников.

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

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

Именно таким было начало нашего будущего поста об угрозах, которые возникают в сети GSM. Но совсем недавно на Хабре был опубликован пост про историю с дубликатами. В комментариях шло бурное обсуждение вопросов безопасности на уровне SIM и даже предложение создать бизнес на продаже «номеров, которые нельзя украсть». Мы в Tottoli GSM тут же приняли решение немного изменить публикацию и рассказать подробно не только об угрозах, но и о простом методе защиты, который уже придуман и успешно используется.

На Хабре половина участников постоянно пугает другую порабощающим всех и вся СОРМом, который круглосуточно мониторит трафик, сохраняет все торренты, которые вы качаете, а потом когда-нибудь — «к вам выедут» (с)

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

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

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

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

Последнее время мне всё чаще задают вопрос как выбрать тот или иной элемент в DOM'е, и данный пост будет сплошь посвящен селекторам в jQuery, возможно большинство из них Вы видели в различных источниках, но собрать их воедино все же стоит…

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

Множество сайтов требуют от пользователя ввода адреса электронной почты, и мы, как крутые и щепетильные разработчики, всегда стремимся проверять формат введенных адресов строго по стандартам RFC. Благодаря этому наши приложения и сайты проверяют формат e-mail корректно и не имеют проблем с юзабилити, а мы сладко спим, потому что уверены, что все работает как надо.

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

Сегодня хочу поговорить о такой интереснейшей ORM, как peewee. Система лёгкая, быстрая, синтаксис запросов немного сложнее, чем у Django ORM, однако позволяет потенциально следить за тем SQL кодом, который получается на выходе.

Поскольку я работал над Python приложением, соединяющимся с БД, выбор пал на простое решение, которое позволило бы стандартизировать обращения к базе данных. До этого коллеги в аналогичных приложениях использовали Django, но его установка делала бы application излишне громоздким (тем более, что в его requirements и так значилось слишком много зависимостей).

Через недельку работы над проектом, руководитель попросил добавить в базу несколько полей и, соответственно, возник вопрос: как делать migrate. Миграции в peewee есть. их механизм описан тут. Однако, каким образом нам производить эти миграции — не понятно.

Мне довелось продолжительное время работать менеджером-админом (эдакий играющий тренер) на большом 1С-Битрикс веб проекте: более 40 сайтов для разных организаций холдинга из разных стран, Oracle БД, редакция «Веб-Кластер», более 100 Гб файлов, несколько лет истории, более 20 правок ядра переживших множество обновлений Ядра, параноидальный режим безопасности и… прямые изменения функционала «руками» на боевом сервере без каких либо намёков на версионный контроль…
Очень грустная картина, вызывающая множество «несчастных случаев на производстве», которую после очередного инцидента была приказано исправить.

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

Менеджер многопоточных закачек на GO.

http://loafter.github.io/godownloader/
https://github.com/Loafter/godownloader

Вступление

Давным-давно, в году этак 1998, для выхода в интернет я использовал модем на работе у отца. Он его включал вечером после работы и я мог наслаждаться просторами сети интернет на скорости аж 31.2 кбит/c. В то время не было истеричных блогеров, страницы не весили по мегабайту, а в новостных сайтах говорили только правду. Естественно основной интерес представляли ресурсы. Картинки, программы, всякие дополнения к играм, вроде машинок. Как сейчас помню качать через IE было сущим адом. Скачать файл весом больше 500 кб было просто невозможно, древний осел был намного упрямей.

В сентябре прошлого года была опубликована последняя статья о Центрифуге — сервере с открытым исходным кодом для обмена сообщениями в режиме реального времени. Теперь в списке хабов, в которые публикуется этот пост, присутствует Go. И неспроста, как можно понять уже из заголовка, Центрифуга была портирована с Python на Go — так появилась Centrifugo. О причинах миграции, о плюсах и минусах Go, а также о том, как эволюционировал проект с момента предыдущей публикации – читайте под катом.

Википедия о ДРАКОНе.

ДРАКОН иногда называют правильными блок-схемами. Но в первую очередь он отлично подходит для записи алгоритмов.
Внутри НПЦ АП (Научно-производственный центр автоматики и приборостроения) ДРАКОН используется с помощью закрытой технологии ГРАФИТ-ФЛОКС.

За рамками НПЦ АП есть открытые общедоступные среды, на которых можно писать реальные программы на так называемых гибридных языках, например: ДРАКОН-Си, ДРАКОН-JavaScript, ДРАКОН-Java, ДРАКОН-C#, ДРАКОН-Python, ДРАКОН-Tcl, ДРАКОН-ASM и т.д.



Доклад представлен на Международной научно-технической конференции «Системы и комплексы автоматического управления летательных аппаратов», посвящённой 105-летию со дня рождения академика АН СССР Н.А. Пилюгина. Конференция проводилась 21 мая 2013 в Институте проблем управления РАН.

Текстовая версия доклада (более подробная)

Это вторая статья цикла, посвященного разработке, управляемой моделями. Сегодня мы создадим метамодель, основанную на метаметамодели Ecore. Вскользь затронем моделирование данных, а именно Anchor, 6НФ и концептуальное моделирование.

Года полтора назад встал вопрос совместимости написанного кода с Python3. Поскольку уже стало более менее очевидно, что развивается только Python3 и, рано или поздно, все библиотеки будут портированы под него. И во всех дистрибутивах по умолчанию будет тройка. Но постепенно, по мере изучения, что нового появилось в последних версиях Python мне все больше стал нравится Asyncio и, скорее, даже не Acyncio а написанный для работы с ним aiohttp. И, спустя какое то время, появилась небольшая обертка вокруг aiohttp в стиле like django. Кому интересно что из этого получилось прошу под кат.

Вторая часть

Введение
Краткий обзор других фреймворков на базе aiohttp
1. Структура
2. aiohttp и jinja2
3. aiohttp и роуты
4. Статика и GET, POST параметры, редиректы
5. Websocket
6. asyncio и mongodb, aiohttp, session, middleware
7. aiohttp, supervisor, nginx, gunicorn
8. После установки, о примерах.
9.RoadMap

От переводчика: когда я начал разбираться с MVC-фреймворками для фронт-энда, каким-то чудом попалась на глаза эта статья Henrik Joreteg. Сейчас дошли руки перевести ее для Хабра, тем более, что об AmpersandJS на Хабре вообще не слышно. Попробую организовать цикл статей по этому инструменту ребят из &yet, мне кажется, он достоин внимания.



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

Angular.js

за

1. очень легко начать использовать. можно просто вставить тег script, добавить немного ng- атрибутов в ваше приложение, и вы волшебным образом получаете нужное вам поведение
2. Angular хорошо поддерживается его основной командой разработчиков, многие из которых работают в Гугле на постоянной основе
3. большая аудитория/сообщество

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