Случилось так, что езжу я в командировки и отпуски не настолько часто чтобы пользоваться какой-то международной телефонией или виртуальным провайдером, но и не настолько редко чтобы вообще не забивать себе этим голову и пользоваться роумингом не заморачиваясь на расходах.
Езжу я не в те страны и не так надолго чтобы покупать симку местного оператора, зато в те страны где вай-фай есть почти везде.
Так уж вышло что в последнее время я плотно познакомился с программной АТС asterisk и перед очередной поездкой подумал о том как было бы классно воткнуть свою сим-карту в качестве входящего транка в asterisk, стоящий в остающейся позади снежной Москве, а самому цепляться к нему sip-клиентом по интернету. Это же и сам звони не хочу, был бы интернет, и звонки принимай на свой же номер, что важно для тех у кого много контактов (всех не оповестишь, да и половина забудет) — сотовый-то с сим-картой фактически стоит в домашнем регионе.

Как это реализуется — под катом.

В свое время, так как я много времени проводил в командировках, мной была приобретена замечательная игрушка — usb модем Huawei e1550. Но времена лихой молодости прошли, и необходимость в использовании данного девайса по прямому назначению отпала. Так он и пылился у меня на полке в течении нескольких лет. И пылился бы и дальше, но возникла задача сделать систему оповещения. Тут я и вспомнил про модем. Рассмотрев поставленную задачу — был вынужден отказаться от SMS оповещения в пользу голосового дозвона по причине невозможности получить уведомление о прочтении SMS. Решения на базе Asterisk показались мне несколько громоздкими, и почитав доку по модему я решил написать звонилку самостоятельно.

Причина публикации.

Несмотря на обилие статей по работе с USSD и SMS запросами, я не нашел ни одной реализации голосовых вызовов на скриптовых языках (таких как Perl, PHP, Node.js). Надеюсь данная статья будет для Вас хорошим подспорьем.

Многим уже надоело лазить по куче сайтов и скачивать js библиотеки и плагины. Да и таскать когда-то скачанные, но уже давно протухшие версии не очень круто. Эти проблемы решает bower.

Но с ним тоже многое нужно делать вручную: следить за components каждого проекта, руками дёргать bower install. После pip с requirements.txt это делать даже как-то лень.

Поэтому представляю вам django-bower, который берёт на себя установку и обновление bower пакетов по списку из settings и прозрачную работу с staticfiles.

Конец 2012 года прошел в суматохе, и каким-то образом я упустил из внимания две важные новости: в декабре вышел GitLab 4.0, а на середину ноября пришелся релиз GitLab Continuous Integration Server.

GitLab — это замечательное FOSS решение для хостинга git-репозиториев внутри закрытой инфраструктуры. Функционал во многом аналогичен GitHub, в частности доступны базовые возможности администрирования и разделения полномочий между пользователями, issue трекер, вики, code review и мердж реквесты (аналог пулл-реквестов на GitHub). И внеочередной плюс теперь, как по мне — это интеграция с GitLab CIS.

GitLab CIS — если GitLab послужит Вам заменой GitHub, то GitLab CIS призван стать заменой Travis CI. Набор фич соответствующий: запуск по git push, отдельные билды под бранч, интеграция с любыми git-репозиториями и бейджик со статусом текущего билда.

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

Что примечательно, работу ведут и курируют скромные украинские парни Дмитрий Запорожец и Валерий Сизов.

Хотите поднять клон Github на своём собственном сервере с приватными репозиториями за корпоративным файрволом? Теперь вы можете это сделать благодаря появлению open source проекта GitLab. Он является хорошей альтернативой для корпоративной версии Github стоимостью до $5000 в год.

По сравнению с Gitorious, система GitLab отличается приятным интерфейсом и гораздо проще в установке.

13 октября вышла версия 1.0, через неделю обещают выкатить 1.1, а затем новые релизы GitLab 1.2, 1.3 и т.д. будут выходить каждый месяц.

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

Итак, что же умеет Celery:

• Выполнять задания асинхронно или синхронно
• Выполнять периодические задания(умная замена crond)
• Выполнять отложенные задания
• Распределенное выполнение (может быть запущен на N серверах)
• В пределах одного worker'а возможно конкурентное выполнение нескольких задач(одновременно)
• Выполнять задание повторно, если вылез exception
• Ограничивать количество заданий в единицу времени (rate limit, для задания или глобально)
• Routing заданий (какому worker'у что делать)
• Несложно мониторить выполнение заданий
• Выполнять подзадания
• Присылать отчеты об exception'ах на email
• Проверять выполнилось ли задание (удобно для построения Ajax приложений, где юзер ждет факта завершения)

Заинтересовало? Просим под кат.

Приветствую!
Думаю, большинство разработчиков Django слышали о Celery — системе асинхронного выполнения заданий, а многие даже активно её используют.

Около года назад на хабре была довольная хорошая статья, рассказывающая о том, как использовать Celery. Однако, как было упомянуто в заключении, уже вышла Сelery 2.0 (на данный момент стабильной версией является 2.2.7), где интеграция с django была вынесена в отдельный пакет, а также произошли другие изменения.

Данная статья будет полезна прежде всего новичкам, которые начинают работать с Django, и им требутся что-то, способное выполнять асинхронные и/или периодические задания в системе (например очистку устаревших сессий). Я покажу как установить и настроить Сelery для работы с Django от начала до конца, а также расскажу про некоторые другие полезные настройки и подводные камни.

Сегодня мы посмотрим на то, как можно использовать директивы ngShow и ngHide в Angularjs.

Зачем они нужны

ngShow и ngHide позволяют отображать или скрывать различные элементы. Это помогает при создании Angular-приложений, так как наши SPA, скорее всего, будут иметь много частей, которые, в зависимости от состояния нашего приложения необходимо скрывать или показывать.

Большим преимуществом этих директив является то, что нам нет необходимости скрывать или показывать элементы при помощи CSS или JavaScript. Это все обрабатывает старый добрый Angular.

Использование

Чтобы использовать ngShow или ngHide, нужно просто добавить директиву к элементу, который вы хотите показать или скрыть.

В Ангуляре, дочерняя область видимости обычно прототипически наследуется от родительской. Единственным исключением является директива, в которой используется scope: { ... }, создающая «изолированную» область видимости, не наследуемую прототипически. Такая конструкция часто используется при создании директив для компонентов «многоразового использования»

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

Dokku — это мини-Heroku, сделанный на базе Docker и состоящий из менее чем 100 строк на Bash.

После установки Вы сможете публиковать свои приложения простым git push. Каждое приложение будет запущено в изолированном контейнере. В конечном итоге у Вас будет своя Heroku-подобная платформа.

Компания DotCloud разработала и выложила в открытый доступ систему Docker — высокоуровневые интерфейсы для доступа к Linux-контейнерам (LXC). Это идеальный инструмент для работы с контейнерами на любом сервере x64, для развёртывания крупномасштабных веб-инсталляций, кластеров БД, частных PaaS и т.д.

LXC — система виртуализации на уровне операционной системы для запуска нескольких изолированных экземпляров Linux на одном компьютере. LXC не использует виртуальные машины, а создаёт виртуальное окружение с собственным пространством процессов и сетевым стеком. Все экземпляры LXC используют один экземпляр ядра ОС.

Ключевые особенности Docker

• Изоляция файловой системы: каждый контейнер процесса работает полностью отдельной корневой файловой системе
• Изоляция ресурсов: системные ресурсы, как CPU и память, можно выделять по-разному для каждого контейнера процесса, используя cgroups
• Сетевая изоляция: каждый контейнер процесса работает в своём собственном пространстве имён, с виртуальным интерфейсом и собственным IP-адресом

Многие знают, что у Диска уже достаточно давно есть API на WebDAV. Он достаточно узко заточен под работу с файловой структурой, а у его реализации на разных платформах часто бывают некритичные, но не очень приятные недостатки. Поэтому в дополнение к WebDAV мы запускаем REST API, который позволит разработчикам делать всё то же и немного больше.

Например, при использовании нового API все приложения, которым просто нужно хранить свои файлы в Диске, смогут получать доступ только к своей папке, лежащей в Диске пользователя в папке «Приложения». В WebDAV API сервису для этого придётся получать у пользователя разрешение на запись/чтение всего Диска, а не только конкретной папки.



В этом посте я хочу рассказывать не о структуре или об операциях, которые умеет выполнять наш API — там всё довольно очевидно — а сразу перейду к интересным вещам: что такое Hypermedia и Machine-readable and Self-describing API, и как мы все это реализовали.

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

За долгое время работы в Яндексе нам удалось систематизировать все наши знания и огромный опыт в создании фронтенда веб-сервисов. Результатом этого осмысления и длительной работы стала первая Школа разработки интерфейсов, занятие которой шли в московском офисе Яндекса. Вся практическая часть обучения проходила в реальных проектах Яндекса. Теоретическая же состояла из лекций, которые читали ведущие разработчики интерфейсов Яндекса: Сергей veged Бережной, Михаил mishanga Трошев, Алексей doochik Андросов, Михаил azproduction Давыдов и другие.



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

Здравствуйте всем!

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

Удобочитаемый синтаксис, прост в обучении, высокоуровневый язык, Объектно-Ориентированый язык программирования (ООП), мощный, интерактивный режим, масса библиотек. Множество иных плюсов… И это всё в одном языке.
Для начала окунёмся в возможности и узнаем, что же умеет Python?

Доброго всем времени суток!

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

Сегодня я хочу рассказать о том, как добиться подобного результата, но сначала немного теории.
Как известно, операционная система Linux Debian будучи установленной на HDD состоит из 4 достаточно независимых компонентов, каждый из которых можно подобрать или настроить по своему вкусу, а именно:

1. Загрузчик — то, что отрабатывает после BIOS и загружает Debian. По умолчанию используется «GRUB», но можно использовать любой другой. Мы будем использовать Syslinux, т.к. умеет грузить ОС с флешки, CD-диска и по сети.
2. Kernel или «ядро» — собственно центральная часть ОС, вокруг которой все крутится. Будем использовать то, что идет в составе дистрибутива.
3. initrd — промежуточная файловая система, которая помогает ядру найти RootFS. Требует небольшой модификации, к счастью не ручной.
4. RootFS — корневая ФС. Вот ее то нам и предстоит преобразовать так, что бы ОС могла грузиться в режиме RO.

Google Web Starter Kit — конструктор и шаблоны для быстрой разработки отзывчивых мобильных сайтов, которые хорошо работают на любой платформе и почти в любом браузере (кроме самых старых). Такие сайты везде выглядят, как нативные приложения.

Основные особенности:

• HTML-шаблоны, оптимизированные для мобильного применения;
• отзывчивый макет для разных мобильных устройств
• руководство по стилю визуальных компонентов;
• поддержка Guilp.js (по умолчанию), Node.js, Ruby и Sass.

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

Вопрос умной категоризации чего-либо встаёт остро при разработке очень многих сайтов. Конечно, всегда можно отдать это на заполнение человеку и результат поначалу будет куда лучше машинного, но, что если категоризировать нужно в реальном времени сотни и тысячи «товаров».
Придется отдать это на откуп машине. Тут вариантов не так много, а написание собственного ИИ для 99.9% задач пустая трата времени.

Заинтересовавшимся как это решить с помощью ElasticSearch прошу под кат.

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

Вводные условия

Предпосылки:

• Один клиент (заказчик) — один юзер в системе на сервере.
• Все проекты клиента — в одной файловой иерархии.
• Virtualenv — это хорошо и must use.
• Ftp — зло, используем современные средства (sftp).
• Количество файлов для управления проектами должно быть сведено к минимуму.

Используемый софт:

• nginx
• uwsgi
• cron
• virtualenv
• openssh