TrueCaller — это сервис по определению имени абонента при входящих звонках, а также блокировка спама. На смартфонах с CyanogenOS 12.1 он вшит в штатную звонилку. Также можете установить себе TrueDialler/TrueCaller с GooglePlay/AppStore/BlackBerryWorld/WindowsPhoneStore.

Если вы активировали данный функционал в вашем смартфоне, то ваша книга контактов полностью слита на сервера Truecaller'а? Проверить, есть ли ваш номер в базе можно по ссылке, например: https://www.truecaller.com/ru/74996813210 (необходима аутентификация).
 
На данный момент сервис насчитывает 1.6 миллиарда номеров по всему миру. Выписать свой номер из базы возможно по ссылке https://www.truecaller.com/unlist.

Tabris.js — еще один кросс-платформенный (Android, IOS) мобильный фреймворк. От подавляющего большинства подобных инструментов он отличается тем, что это не обертка над стандартным или Chrome-based WebView. Tabris предоставляет собой набор нативных компонентов, доступный из javascript. Ближайшие аналоги из мне известных это: Telerik Native Script, Appcelerator и React Native.

Случайно попалось упоминание о хостинге Scaleway.

Плюсы:

• 4 ядра
• 2 гигабайта оперативки
• 50 гигабайт SSD диск
• bare-metal! (то есть, нет никаких, даже чисто теоретических накладных расходов на виртуализацию)
• за все это всего 3 евро в месяц! Очень дешево!

Но есть особенность: это ARM процессор. Да-да! Это 4-ядерный ARM процессор.

В деле удалённого вызова процедур дела уже давно обстоят в точности как в известном комиксе «14 стандартов» — чего только тут ни напридумано: древние DCOM и Corba, странные SOAP и .NET Remoting, современные REST и AMQP (да, я знаю, что кое-что из этого формально не RPC, для того чтобы обсудить терминологию даже вот специальный топик недавно создали, тем ни менее всё это используется как RPC, а если что-то выглядит, как утка и плавает, как утка — ну, вы в курсе).

И конечно же, в полном соответствии со сценарием комикса, на рынок пришел Google и заявил что вот теперь наконец он создал ещё один, последний и самый правильный стандарт RPC. Google можно понять — продолжать в 21-ом веке гонять петабайты данных по старому и неэффективному HTTP+REST, теряя на каждом байте деньги — просто глупо. В то же время взять чужой стандарт и сказать «мы не смогли придумать ничего лучше» — совершенно не в их стиле.

Поэтому, встречайте, gRPC, что расшифровывается как «gRPC Remote Procedure Calls» — новый фреймворк для удалённого вызова процедур от Google. В этой статье мы поговорим о том, почему же он, в отличии от предыдущих «14 стандартов» всё-таки захватит мир (ну или хотя бы его часть), попробуем собрать билд gRPC под Windows + Visual Studio (и даже не говорите мне, что инструкция не нужна — в официальной документации упущено штук 5 важных шагов, без которых ничего не собирается), а также попробуем написать простенький сервис и клиент, обменивающиеся запросами и ответами.

Не так давно к нам обратился клиент, который занимается видео-трансляциями аукционов и лошадиных скачек в прямом эфире. Сами мероприятия проходят в Австралии, а вот ставки на них делаются игроками в Макао — игровой столице Юго-Восточной Азии. Разумеется, он столкнулся с задержкой сигнала — как без неё. Задержка — это время между взятием кадра и его появлением на экране конечного устройства. И если обычному зрителю задержка в 5 или даже 10 секунд не критична, то тем, кто ставит на тотализаторе, подобная разница может стоить огромных денег. Отсюда возникла задача — свести к минимуму время прохождения видео от источника к зрителю.

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

Мы подумали, что некоторые техники, которые мы применили, будут интересны не только нам.

Итак, цепочку доставки видео схематично можно разделить на 6 этапов: съёмку, сжатие, передачу по локальной сети от энкодера к медиа-серверу, передача через интернет, декодирование и отображение на устройстве пользователя.



Посмотрим, чем определяются издержки на каждом из этапов и как их можно сократить.

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

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



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

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

В популярной платформе для быстрого создания веб-приложений скоро появится официальная поддержка SQL. Ранее разработчики неоднократно отказывались это делать, мотивируя тем, что SQL не вписывается в философию проекта. Однако, настойчивость сообщества сделала своё дело и уже сейчас вы можете попробовать предварительную реализацию поддержки SQL в Meteor. Все подробности — под катом!

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

Начнем.

Используется Debian 7.8, Samba 4, Squid 3, Kerberos 5.

Книги.
Я считаю, что важнейшим инструментом получения скилов системного администрирования являются именно они — книги.
Нет специальных факультетов, обучающих «админству» — каждый постигает это самостоятельно. Путем проб, ошибок и боли, потере важных данных различных злоключений.
В начале пути сложно определиться, что же нужно прочесть — ведь массив информации столь огромен!
В данном посте я хочу собрать наиболее важные и значимые труды для системных администраторов.
Уклон будет на *nix админство, но, надеюсь тема окажется небезынтересной и для Windows коллег и в комметариях они заполнят мои пробелы.
Пост субьективен и отражает лишь мой собственный опыт — я раскажу о книгах, которые помогли моему становлению.

TL;DR

Чтобы просто установить и изолировать зависимости проекта, virtualenv часто оказывается слишком тяжелым решением. Предлагаем простую альтернативу:

1. добавить ./.pip в переменную окружения PYTHONPATH,
2. установить пакеты локально с помощью pip install -t .pip,
3. запускать python из папки проекта.

От переводчика.
Это перевод статьи Филипа Бернарда с сайта css-tricks.com. Часть статьи, содержащую описание работы с созданным им сервисом, я позволил себе опустить. Если вы найдете ошибки, просьба сообщить о них в личном сообщении.

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

Фавикон был представлен в 1999 году, в Internet Explorer 5 (источник) и стандартизирован W3C несколько месяцев спустя. Это была маленькая иконка, представляющая сайт.



С тех пор большинство настольных браузеров следуют тенденции и используют фавикон тем или иным способом. Это очень просто, не так ли? Создать маленькую картинку и добавить в любой интернет-проект, чтобы сделать его «завершённым». Ничего сложного.

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

Основные проблемы, которые встречаются в библиотеках валидации данных

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

Проблема №2. Процедурное описание правил валидации. Я не хочу каждый раз думать про алгоритм валидации, я просто хочу описать декларативно, как должны выглядеть правильные данные. По сути, я хочу задать схему данных (почему не «JSON Schema» — в конце поста).

Проблема №3. Описание правил валидации в виде кода. Казалось бы, это не так страшно, но это сразу сводит на нет все попытки сериализации правил валидации и использования одних и тех же правил валидации на бекенде и фронтенде.

Проблема №4. Валидация останавливается на первом же поле с ошибкой. Такой подход не дает возможности подсветить сразу все ошибочные/обязательные поля в форме.

Проблема №5. Нестандартизированные сообщения об ошибках. Например, «Field name is required». Такую ошибку я не могу показать пользователю по ряду причин:

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

То есть, нужно возвращать не сообщение об ошибках, а стандартизированные коды ошибок.

Проблема №6. Числовые коды ошибок. Это просто неудобно в использовании. Я хочу, чтобы коды ошибок были интуитивно понятны. Согласитесь, что код ошибки «REQUIRED» понятней, чем код «27». Логика аналогична работе с классами исключений.

Проблема №7. Нет возможности проверять иерархические структуры данных. Сегодня, во времена разных JSON API, без этого просто не обойтись. Кроме самой валидации иерархических данных, нужно предусмотреть и возврат кодов ошибок для каждого поля.

Проблема №8. Ограниченный набор правил. Стандартных правил всегда не хватает. Валидатор должен быть расширяемый и позволять добавлять в него правила любой сложности.

Проблема №9. Слишком широкая сфера ответственности. Валидатор не должен генерировать формы, не должен генерировать код, не должен делать ничего, кроме валидации.

Проблема №10. Невозможность провести дополнительную обработку данных. Практически всегда, где есть валидация, есть необходимость в какой-то дополнительной (часто предварительной) обработке данных: вырезать запрещенные символы, привести в нижний регистр, удалить лишние пробелы. Особенно актуально — это удаление пробелов в начале и в конце строки. В 99% случаев они там не нужны. Я знаю, что я до этого говорил, что валидатор не должен делать ничего кроме валидации.

3 года назад, было решено написать валидатор, который не будет иметь всех вышеописанных проблем. Так появился LIVR (Language Independent Validation Rules). Есть реализации на Perl, PHP, JavaScript, Python (мы на python не пишем — фидбек по ней дать не могу). Валидатор используется в продакшене уже несколько лет практически в каждом проекте компании. Валидатор работает, как на сервере, так и на клиенте.

Samba4 имеет встроенный интерфейс на Python. Многие утилиты (samba-tool, например) полностью реализованы на Python с применением этого интерфейса.

Все, что делалось из LDAP-интерфейса, можно сделать на Samba 4 Python Scripting. Преимущества — файловый доступ, значит высокая скорость, некоторые фичи, которых нет в LDAP. Например, можно взять хэш паролей пользователей из одной базы и перекинуть в другую. Да и самих пользователей с их SID-ами, паролями и всем прочим перекинуть в другой домен (без заморочек с SID-history).

Всем привет, с вами команда Wiren Board!

Нас часто спрашивают: «Что можно подключать к вашему контроллеру? Как на нём собрать “умный дом”?»
Чтобы немного прояснить этот вопрос, мы покажем стенд, где к Wiren Board 4 подключены периферийные устройства. На его примере расскажем про типовые варианты подключения устройств и датчиков.

На стенд можно посмотреть на него через онлайн-трансляцию и зайти в демонстрационный веб-интерфейс.

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

Для статьи я подобрал наиболее полезные дополнения «на все случаи жизни».

Гибкость Javascript позволяет создавать объекты множеством способов. Но как это нередко случается, разнообразие таит в себе множество подводных камней. Из этой статьи Вы узнаете о том, как разглядеть и обогнуть эти опасные рифы.

О чем статья?

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

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

Существует пара наиболее распространенных способов оповещения пользователя. С одной стороны, социальные сети Facebook, Twitter и LinkedIn указывают определенное число, которое соответствует количеству обновлений. С другой стороны, Trello отображает небольшой красный кружок поверх favicon.


Оповещения Trello, Facebook и Twitter

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

Посмотреть на GitHub
Демо (рус.)

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

Здравствуйте, меня зовут Александр, и я пишу велосипеды по выходным программист.



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

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