Вообще мы в Voximplant занимаемся голосовой автоматикой. Принять звонок с сотового телефона, запустить JavaScript сценарий клиента – там пара тысяч строк логики что с этим звонком делать, включая исходящие на веб-браузеры и мобильные приложения – вот эта вся история. Отдельная история – видео. Образование, телемедицина, совещания. Тот же SIP, те же кодеки, только данных передается в сотню раз больше. При этом браузеры любят зависать и падать, когда им не нравится полученный с другой стороны WebRTC SDP пакет, а мы их от этого отучаем.

Но, как оказалось, голоса и видео клиентам мало: “Мы не хотим сами писать чатик, уже два раза все переписывали и три питониста уволилось. Дайте нам стек unified communications, чтобы всё было на одной платформе, и мы не парились”. И на прошлой неделе мы стали этим самым “Unified Communications”. Теперь на нас можно собрать “Skype for Web” целиком: не только голосовые и видеозвонки, но и обмен сообщениями. Под катом я хочу показать как работает сделанный нами мессаджинг и, надеюсь, получить от вас фидбек – насколько хорошим получилось API и все ли с помощью него можно сделать?
Читать дальше →

Юнит тесты помогают нам удостовериться, что код работает так, как мы этого хотим. Одной из метрик тестов является процент покрытия строк кода (Line Code Coverage).

Но насколько корректен данный показатель? Имеет ли он практический смысл и можем ли мы ему доверять? Ведь если мы удалим все assert строки из тестов, или просто заменим их на assertSame(1, 1), то по-прежнему будем иметь 100% Code Coverage, при этом тесты ровным счетом не будут тестировать ничего.

Насколько вы уверены в своих тестах? Покрывают ли они все ветки выполнения ваших функций? Тестируют ли они вообще хоть что-нибудь?

Ответ на этот вопрос даёт мутационное тестирование.

Читать дальше →

Некоторое время назад я написал интерпретатор лиспоподобного языка, который назвал Liscript. Опубликовал несколько статей на Хабре, посвященных особенностям реализации ядра, TCO, GUI, REPL-ботов и т.п. Недавно добавил web-интерфейс REPL-у (ссылка в конце статьи).

При чем здесь поцелуи и экскаваторы? Думаю, большинству известны такие аббревиатуры, как KISS (keep it simple stupid — делай это проще, дурачок), YAGNI (You ain't gonna need it — Вам это не понадобится), а также высказывания людей разной степени великости про архитектурных астронавтов, «все должно быть сделано так просто, насколько возможно, но не проще», и т.п.

Допустим, перед вами стоит задача — выкопать яму. Какие есть варианты решения? Взять лопату и выкопать самому — дешево и сердито, но долго и возможно неоптимально (зависит от вашего уровня владения лопатой и размеров ямы). Отдать на аутсорс таджикам (не будем рассматривать здесь этот вариант, хотя я должен был его упомянуть). Взять экскаватор — быстро и эффективно, но затратно: бензин/аренда, плюс не факт, что он проедет в вашу садовую калитку, значит надо сносить/восстанавливать забор и т.д. Также, необходимо определиться с моделью (порой из 100500 вариантов), а если вы будете управлять им самостоятельно, надо разобраться во всех его рычагах и педалях.

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

В общем, про выбор инструментов под задачи, и конкретные (подозреваю, что спорные) решения, которые я выбирал в процессе реализации проекта, под катом.
Читать дальше →