Перевод статьи Эрика Синка (Eric Sink) — DVCS and DAGs (Part 1 and Part 2).

Прим. переводчика: В этой статье я буду ис­поль­зо­вать ори­гиналь­ные анг­ло­языч­ные сокращения DVCS и DAG для обозначения расп­ре­делён­ных систем контроля версий (Distributed Version Control System — DVCS) и нап­равлен­ных ацикличных графов (Directed Acyclic Graph — DAG).

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

Сейчас, становится очень модной тенденцией переводить предприятие (учреждение) на Систему Электронного Документооборота. Это не только модно, но, и, практично и удобно.

В связи с этим, появляются компании, которые предоставляют свои программные продукты – СЭДы, которые, порой шокируют своими ценами. Однако, не всё так плохо, т.к. благодаря инициативным и некорыстным людям, на свет появляются бесплатные и открытые продукты. Примерами тому, могут является две отличных, на мой взгляд, СЭД: NauDoc и Alfresco.

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

Почему PDF? Формат PDF позволяет создавать документы с целым рядом неоспоримых преимуществ: открытость, кроссплатформеность, распространенность и, что очень важно, точностью и неизменностью передачи данных по цепочке создание, просмотр и печать.

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

Какие преимущества? Возможность создания и быстрого редактирования очень сложных шаблонов в привычных векторных редакторах, таких как Adobe Illustrator, Corel Draw или Inkscape. Простота программирования и использование только бесплатных программных средств. Еще одним важным преимуществом является возможность прозрачно использовать UTF-8 для вставляемых текстов.

Что для этого надо? Для использования данного метода нужен выделенный сервер с возможностью установки своих приложений (Inkscape и GhostScript) и выполнением system-команд. При этом всё будет работать как на Windows платформе, так и на Linux.

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

Файловых менеджеров много, но есть один, о котором, думаю, будет многим интересно узнать. Ведь он двухпанельный, работает в браузере, оснащён редактором (с подсветкой синтаксиса) и консолью, состоит из клиента и сервера, а написан на JavaScript/Node.js.

В этой статье хочу рассказать, а также показать настройку полезного инструмента для удаленной разработки от компании JetBrains встроенное в IDE Pycharm. Такой инструмент есть уже давно, но многие разработчики относятся к этому не серьезно, и для внесения изменений в проект предпочитают разворачивать его локально. Когда намного легче на том-же сервере, сделать копию части проекта и изменять или тестировать на другом порту с помощью встроенных средств удаленного интерпретатора Pycharm. Конечно не во всех ситуациях это хороший вариант, но для правки, и доработки небольших проектов очень даже подходит. А если проект с нуля, то создавая его на удаленном сервере, исчезает потребность в переносе и адаптации его под сервер(хостинг), которые неизбежно ведут к появлению множества багов и несовместимостей.

К тому же такой подход нас избавляет от таких проблем:

• на разных серверах свой Unix и свои приколы, разворачивать локально и подгонять среду под особенности того или иного сервера может занять приличное количество времени;
• разные версии python;
• И если в файле req.txt для Django не указаны все зависимости;
и т.д.

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

• создать паука, выполняющего GET запросы,
• извлекать данные из HTML документа,
• обрабатывать и экспортировать данные.

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

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

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

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

Введение

Как известно, на многих сайтах/веб-приложениях необходимо тем или иным образом реализовать поиск. Все хотят быстрый и качественный поиск. Разработчики помимо всего прочего хотят, чтобы поисковик был прост в установке и использовании. Так как речь идет о django, то перед нами встает ряд ограничений в реализации поиска (при условии, что в сутках 24 часа и дедлайны никто не отменял). Предлагаю вашему вниманию небольшой туториал о том, как поставить и максимально безболезненно интегрировать в django проект такой мощный поисковик, как apache solr. Всех заинтересованных прошу под кат.

О программе Sketch я узнал еще год назад. Скачал демо тогда еще 2-й версии. Признаться, она меня совершенно не впечатлила. Какой-то слишком простой показалась. Я привык к навороченным интерфейсам софта от Adobe, а расположение панелей в стиле Apple iWork (Pages, Numbers, Keynote) мне по какой-то причине не нравится. К тому же мне оказалось комфортнее работать с темным интерфейсом, каковой нынче есть в Photoshop CC. Плюс Sketch 2 был достаточно кривоватый, содержал немало досадных багов, да и вообще впечатления не оказывал скоростью работы. В общем, поигрался с демкой и благополучно забыл. Впрочем, оказалось, что зря…

Моя организация пишет софт под Linux.
Софт предназначен для работы на торговых точках, которые распределены географически.
Изначально ПО предоставлялось клиентам как набор deb пакетов под разные дистрибутивы и архитектуры со списком пакетов, которые нужно установить как зависимости до инсталляции этих deb файлов.
Хочу рассказать, каким был путь эволюции от распространения файлов через ftp до создания репозитория и запуска системы управления конфигурациями и начала внедрения в работу сервера непрерывной интеграции.

Недавно купил вот такую красоту.
Поигрался с Android на ней и решил сделать домашний сервер на замену RaspberryPI.

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

Издательство Питер решило вспомнить о хорошей, но забытой книге Скотта Беркуна «Искусство управления IT-проектами, 2-е изд.»

Вот, что говорит сам автор о своей книге:

«С годами созидательного труда и сопоставления своего личного опыта с опытом других менеджеров, программистов и проектировщиков, я неплохо освоил искусство управления проектами, которое включает в себя подходы к руководству командами, работу над идеями, организацию работы над проектами, выдерживание рабочего графика, улаживание конфликтных ситуаций и достижение конкретных результатов даже перед лицом серьезных испытаний и неблагоприятно складывающейся обстановки. Несмотря на широкое толкование названия этой книги, большую часть своего рабочего опыта я приобрел в технической области, работая, в частности, в корпорации Microsoft. Я проработал в этой корпорации с 1994 по 2003 год, возглавляя команды специалистов, работающих над такими проектами, как Internet Explorer, Microsoft Windows и MSN. Несколько лет я проработал в группе совершенствования разработок корпорации Microsoft, отвечая за обучение и консультации команд в рамках всей компании, и довольно часто получал приглашения выступить с докладами на публичных конференциях, в корпорациях и университетах. Большинство советов, уроков и историй, приводимых в этой книге, являются плодами этого опыта работы. Хотя у меня за плечами богатое прошлое разработчика программного обеспечения и веб-приложений, при работе над книгой я расширил область исследований, обратившись к источникам и технологиям, выходящим за рамки разработки и управления. В книге содержится много полезных сведений для людей, принадлежащих миру бизнеса. Я убежден, что трудности в организации, руководстве, разработке и производстве имеют много общего, независимо от области деятельности. В процессе изготовления тостеров, строительства небоскребов, производства автомобилей, создания веб-сайтов и программных продуктов во многом приходится сталкиваться с одними и теми же трудностями, и эта книга написана в первую очередь о том, как эти трудности преодолеть.В отличие от некоторых других книг о руководстве проектов».

Первые прецеденты совместных поездок известны человеку с незапамятных времен (hitchhiking) — автостоп, когда два незнакомых друг другу человека совершают совместную поездку. Водитель, направляясь куда-либо, видит пассажира — человека (hitchhiker), которого выдает жест (поднятый вверх большой палец) и «подбирает» его. Как правило, такие поездки носят бесплатный характер (но не всегда), да и безопасность такого рода передвижений нельзя гарантировать. Однако, они получили распространение по всему миру и находят применение даже сегодня. Пример такой поездки можно увидеть в Американской комедии 2000 года «Road Trip» (дорожное приключение).

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

Я уже писал о своем опыте работы с WebRTC тут, но учитывая то, что в последнее время всё больше статей на эту тему появляется на хабре и то, что я давно хотел написать о том, как мы добились стабильной работы SIP телефонии через WebRTC на продакшне, я решил написать через что мы прошли.

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

Кому интересно, прошу под кат.

Статья написана по мотивам Синтез и распознавание речи от Google для Asterisk, с не большими изменениями. Для распознавания речи используется платформа Yandex SpeechKit HTTP API.

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

API — это большая сила и большая ответственность. У хорошего API будут благодарные пользователи; поддержка плохого превратится в кошмар.

Публичный API — не воробей, опубликуешь — не уберешь. Есть только одна попытка сделать все правильно, поэтому постарайся.

API должно быть легко использовать, но сложно использовать неправильно. Сделать что-то простое с помощью такого API должно быть просто; сложное — возможно; сделать что-то неправильно должно быть невозможно, или, по крайней мере, трудно.

API должен описывать сам себя. Изучение кода на таком API не вызывает желания читать комментарии. Вообще, комментарии редко нужны.

Перед разработкой API собери требования с долей здорового скептицизма. Осознай общие задачи и реши их.

Оформляй требования как шаблоны использования API. Сверяйся с ними в процессе проектирования.

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

Для меня было ожидаемо, что условие работает так же как и в js, то есть:

if (condition) {
 ...
} else {
 ....
}

В зависимости, что передано — элемент будет скрыт или показан.