Первоначально опубликовано в /r/freelance на Reddit, но выкладываю здесь для потомков.

Я занимаюсь фрилансом довольно долго и могу поделиться крупицами знаний, которые я услышал или узнал сам, зачастую нелегким путём.

Типичный штатный сотрудник обходится компании в 2-3 раза дороже его номинальной зарплаты

Используй это в качестве основы для расчёта своих тарифов. $90 в час может показаться дорогой альтернативой сотруднику, который получает зарплату $30 в час, но в реальности это эквивалент $90, и расходы прекращаются сразу по окончании проекта.

Если клиент просит 6+ часов в день, ты потратишь 8 часов

Ты не сделаешь ничего полезного (читай: оплачиваемого) в оставшиеся два часа. Они отняли у тебя целый день, но заплатили только за 75%. В таких ситуациях взимай дневную ставку.

После того, как вы проверили, что функциональность реализована нормально, она выкатывается в эксперимент, чтобы узнать, нравится ли новая версия пользователям.

Замечали, что обычно люди, ответственные за эксперименты, в итоге говорят, что данных недостаточно для решения? Часто это действительно так, но нередко всё дело в поломках системы экспериментов и учёта пользовательской статистики.
 
В этой статье мы рассмотрим типичные поломки, которые там встречаются, и у вас появится возможность, вернувшись на рабочее место, немножко побыть data scientist'ами и найти ошибки у себя в компании. Какие-то из них там наверняка есть.

В основе материала — расшифровка доклада Романа Поборчего с нашей декабрьской конференции Heisenbug 2017 Moscow.

Все думают, что программист большую часть своего рабочего времени пишет код. Кроме самих программистов. Они знают, что большую часть времени они этот код читают. Читают, силясь понять, как же он работает, зачем он здесь написан и что с ним теперь делать.

Дольше всего приходится вычитывать не хитрые алгоритмы, и не решения с алгебраическими типами данных и монадами, а огромные куски простого кода: методы на 500 строк, скрипты на 1000 строк, классы на 1500 строк. Все они доставляют индустрии проблем не меньше, чем печально известное NullPointerException.

WebRTC, технология голосовых и видеозвонков в браузерах (а еще realtime передачи произвольных данных, peer-to-peer пробивания NAT и захвата экрана) никогда не была простой. Долгая история, несовместимости между браузерами, запутанная документация, множество решаемых задач и используемых протоколов. Возможность позвонить и принять звонок из браузера всегда была одной из ключевых «фишек» нашей платформы Voximplant, и так как мы в этом неплохо разбираемся, то стараемся следить за интересными статьями и адаптировать их для аудитории Хабра. Под катом перевод свежей статьи от ребят из callstats.io — сервиса сбора статистики по качеству звонков для браузера. В небольшой статье они рассказывают о протоколе RTP с помощью которого, собственно, браузер и передает пакеты с голосом или видео.

ОС Windows долгое время попрекали за медлительность её файловых операций и медленное создание процессов. А почему бы не попробовать сделать их ещё более медленными? Эта статья покажет способы замедления файловых операций в Windows примерно в 10 раз от их нормальной скорости (или даже больше), причём способы эти практически не поддаются отслеживанию обычным пользователем.

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

Изображение: Pexels

Банк HSBC в своем недавнем отчете назвал переход на безналичные средства платежа одним из главных трендов текущего года наряду с развитием технологии блокчейна. Во многих странах эта тенденция видна уже сейчас — существуют даже рейтинги стран, в которых безналичные платежи наиболее развиты.

Однако не все так гладко, и в стабильно занимающей одно из первых мест в таких рейтингах Швеции разгорелась общественная дискуссия о том, стоит ли обществу стремиться полностью отказаться от наличных. Историю об этом опубликовало издание Guardian, главные тезисы материала читайте в нашей статье.

Привет. Меня зовут Максим Винников, я Vice President of Product Management в компании Aurea Software. В той же самой компании, на которую работает Слава Кулаков, знакомый многим по истории, как он стал фрилансером, получающим $200 000 в год. Вопросы и комментарии к тому посту продолжают идти до сих пор, поэтому сегодня, уже на своём примере, я расскажу, что из себя в повседневном режиме представляет уже непосредственно работа, за которую платят такие гонорары — и постараюсь ответить на вопросы по теме живьём.

[update] В прямом эфире ответил на вопросы, появившиеся в комментариях за день:



Согласно стандартам Aurea и ESW Capital каждый сотрудник должен отработать 40 часов в календарную неделю. Я, исходя из своей позиции и физических возможностей, придерживаюсь графика 5/2. Моё основное рабочее окно расположилось в промежутке с 14:00 до 19:00, это суммарно 5 часов в день. Ещё 3 часа в день дорабатываются тогда, когда мне удобнее: в один день я могу поработать поздним вечером, в другой — приступаю с самого утра, чтобы освободиться пораньше.

Так как команда на 100% децентрализована и у нас нет офисов, то всё взаимодействие между сотрудниками переходит в онлайн. Я, как VP (а это менеджерская позиция), вовлечён в различные рабочие процессы множества людей сильнее, чем среднестатистический разработчик. Это тоже стоит учитывать.

Итак, продолжаем разговор о ФЗ-54 и онлайн-кассах. Предпринимателям, которых ждет вторая волна автоматизации, будет полезно узнать о требованиях к оформлению кассового чека, какая информация в них должна содержаться, и как это связано с фискальными накопителями разных версий. В этой статье мы расскажем подробнее о форматах фискальных документов (ФФД), нюансах перехода с версии на версию и подводных камнях оформления и передачи данных о кассовых операциях в ОФД.

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

Предлагаю вашему вниманию сводную таблицу-сравнение под кодовым названием «Лучшая страна для программиста», которую я подготовила с помощью IT-блогеров из разных стран. В список попали Германия, США, Испания, Канада, Австралия и Австрия, а также добавила в список Англию, Швейцарию и Нидерланды.

В этой статье страны сравнивались по следующим параметрам:

1. Зарплаты программистов
2. Налоги
3. Стоимость жизни
4. Социальное обеспечение
5. Развитость рынка IT

Проблематика

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

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

Представьте, что у вас есть всего один тест с использованием Selenium. Что может сделать его нестабильным? Как его ускорить? Теперь представьте, что тестов стало два. Теперь представьте сотню. Как заставить быстро отработать такую кучу тестов? Что произойдет, если количество тестов продолжит расти?

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

Прототипом этой статьи является доклад Саймона Стюарта на Heisenbug 2017 Moscow. Саймон — создатель WebDriver, технологии, которой сейчас почти 11 лет. Он стал руководителем проекта Selenium около 9 лет назад. В Google занимался масштабированием Selenium, от нескольких десятков тысяч до нескольких миллионов тестов каждый день, на их инфраструктуре. Затем перешел в Facebook. В данный момент занимается разработкой спецификации WebDriver для W3C, которая входит в группу тестирования и тулинга в W3C. Можно сказать, что на основе WebDriver и создается стандарт.

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

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

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

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

Многие уже слышали о проекте WebRTC, некоторые даже используют его (или пытаются применять в существующих проектах), а кто-то злобно потирает руки, предвкушая постепенную расправу со Skype и Flash.

Погуглив в Хабре (хе-хе) я почему-то не нашел статей, которые углублялись в техническую сторону WebRTC, показывали бы примеры его использования.

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