Вот бывает же так, собираешь команду ребят, вкладываешь деньги и/или привлекаешь партнера-инвестора в свой проект, денно и ночно трудишься почти год, чтобы предложить миру, в моём случае конечно же городу своё уникальное изобретение и вуаля!

Приходишь такой со своим проектом в виде работающего прототипа защищаться на краш-тест организованный какой либо предпринимательской тусовкой и тебе там говорят — «Ребят, да вы чё, такое уже есть, в Европе аналогичное мобильное приложение „meetap“ распространенно и все ими пользуются, зачем вы вообще что то делаете по своему, просто берите и копируйте!

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

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

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

Эту статью написал программист из Италии Валентино Гаглиарди. Он говорит, что сразу после выхода Puppeteer его заинтересовала автоматизация тестирования веб-интерфейсов с использованием данной библиотеки и Jest. После этого он приступил к экспериментам.



Здесь речь пойдёт об основах работы с Puppeteer и Jest на примере тестирования веб-формы. Также тут будут рассмотрены особенности использования Chromium с пользовательским интерфейсом и без него, и некоторые полезные мелочи, касающиеся различных аспектов тестирования веб-страниц и организации рабочей среды. Валентино полагает, что, хотя Puppeteer — инструмент сравнительно новый и его API вполне может подвергаться изменениям, у него есть шанс занять достойное место в арсенале веб-разработчиков.

За пять дней, с 24 по 28 июля 2017 года, я прошел собеседования в LinkedIn, Salesforce Einstein, Google, Airbnb и Facebook; все пять компаний предложили мне работу. Это был замечательный опыт и я понимаю, как мне повезло, что мои усилия оправдали себя, поэтому решил написать об этом. Здесь я расскажу о том, как готовился к собеседованиям, как они проходили и какое впечатление произвели на меня компании.

Как все началось

Я отработал в Groupon почти три года. Это моя первая работа, там были и прекрасные люди, и отличные проекты. Мы делали всякие интересные штуки, вводили перемены внутри компании, публиковали материалы и все в таком духе. Но со временем я стал ощущать, что темп моего самообразования стал затухать (попросту говоря, замедляться), мне не хватало пищи для ума. К тому же, как и всякого разработчика ПО из Чикаго, меня тянуло в Область залива Сан-Франциско — ведь там столько известных компаний.

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

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

Итак, что же это такое?

(Осторожно, в статье чрезвычайно много картинок и анимаций!)

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

У нас беспокойная работа — с сайтами, которые мы поддерживаем, постоянно что-то происходит, и на любую аварию мы должны среагировать за 15 минут — все это в режиме 24/7, семь дней в неделю. Задачи для админов невозможно запланировать — сложно представить себе такой план на неделю: случится 25 аварий, и мы их устраним одну за другой. О том, как мы пытаемся с этим жить, я и хочу рассказать.

Является продолжением предыдущих публикаций. Основное назначение публикаций — демонстрация возможностей R по решению различных "рутинных" задач по обработке данных, возникающих в бизнесе. Основной акцент ставится на создание законченного решения для конечного пользователя, а не на принципиальное решение частной задачи набором команд в консоли. Схематический прототип и продукт с конвейера имеют больше различий чем сходства.

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

Kubectl — основной консольный интерфейс для взаимодействия с Kubernetes и, безусловно, важный инструмент в руках любого администратора/DevOps-инженера, причастного к эксплуатации таких кластеров. Если вы пользуетесь им каждый день и делаете это по-настоящему активно, то, как это свойственно ИТ-специалистам, наверняка задумывались о способах упрощения/автоматизации своих манипуляций. Благо, это мир сисадминов, Open Source и консоли, так что в нём, конечно, уже нашлись и те, кто не только задумывался об этом, но и воплотил свои потребности в жизнь — в виде утилит, доступных теперь и всем «коллегам по цеху». О них и пойдёт речь в этом небольшом обзоре.

Некоторое время назад я начал делать утилиту, которая упростила бы мне жизнь. Она называется gomodifytags. Утилита автоматически заполняет поля структурных тегов (struct tag) с помощью имён полей. Пример:

Эта утилита облегчает управление многочисленными полями структуры. Она умеет добавлять и удалять теги, управлять их опциями (например, omitempty), определять правила трансформации (snake_case, camelCase и пр.) и многое другое. Как эта утилита работает? Какие Go-пакеты она использует? Наверное, у вас есть много вопросов.

В этой очень длинной статье я подробно расскажу о том, как написать и собрать такую утилиту. Здесь вы найдёте много советов и хитростей, а также кода на Go.

Налейте кофе и начинайте читать!

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

Предыстория

В двух словах — вступление о мониторинге и аппеляционности убеждений. Как многим известно, я сопровождаю Riemann — инструмент обработки потоков событий для мониторинга распределенных систем. В моей книге, посвященной мониторингу, я использовал Riemann, как основной инструмент для изучения новых подходов и паттернов мониторинга, и описал архитектуру whitebox-мониторинга (с выборочным blackbox-мониторингом), используя push модель.

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

В свою очередь, whitebox-мониторинг сфокусирован на том, что происходит внутри сервиса или приложения. Приложение, обладающее соответствующим инструментарием, возвращает состояние самого себя или внутренних компонентов, результат выполнения транзакций или событий. Эти данные отвечают на вопрос “как работает приложение”, а не на вопрос “работает ли приложение”. Whitebox-мониторинг передает события, логи или метрики в специальный инструмент для мониторинга или предоставляет информацию наружу для последующего сбора инструментом мониторинга.

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

Так родился проект loghouse, и я рад представить его альфа-версию DevOps-инженерам и системным администраторам, которым знакомы обозначенные проблемы.

Недавно мне позвонили и попросили помочь разобраться с очень странными симптомами на сайте. А симптомы выглядели вот так. Cовершенно разные клиенты звонили и рассказывали, что они на сайте попадают в личные кабинеты других случайных клиентов. Логинятся под собой. Входят в свой аккаунт, а потом бац – и уже в аккаунте другого клиента. Правда они не догадывались, что кто-то другой так же мог оказаться в их личном кабинете.

Давайте я расскажу «историю неуспеха», чтобы другие на эти грабли не наступали.

Работа с Docker не самая простая задача. В этой статье хотелось бы рассказать что нас подтолкнуло с созданию DockStation проекта и что у нас уже реализовано на данный момент.

Начало

Я работаю разработчиком уже больше 8 лет, и для меня всегда была болью настройка dev окружения для разработки при переходе на другую OС или смене рабочей машины.

В предыдущей хабрастатье я показал, что если сервис умеет интегрироваться по SIP и RTP, то с ним можно делать много интересных штук. Например, приглашать в видеоконференции Zoom участников с мобильных телефонов. Но наше облако Voximplant — это не только телеком и телефоны. Еще мы любим и умеем SDK, чтобы звонить и принимать звонки из неожиданных мест: с веб-страниц, из приложений (звонки через интернет намного дешевле, чем через голосовой канал) и даже из VR/AR Unity решений. В этой статье я покажу, как с помощью нескольких строк фронтенд JavaScript создавать «звонящие» страницы, с помощью которых участники смогут делать видеозвонок в конференцию. И да, благодаря последнему обновлению от Apple звонить теперь можно и с веб-страниц на iPhone!

Эта статья также есть на английском.

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

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

Под катом — дюжина приемов в командной строке — из личного опыта.

WebRTC позволяет реализовать real-time аудио/видео связь через браузер ( и ).

В этом топике я расскажу как реализовать простейшее WebRTC приложение.

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

Зная местоположение человека, можно сделать тысячу полезных и не очень вещей: предложить правильный товар и заранее назвать цену доставки, показать ареал обитания покемонов, вывести локальные новости или посоветовать кафе неподалеку.

Местоположение — это важно.

Дизайнерам бывает сложно переводить анимированный ролик в gif и подстраиваться под ограничения анимации для Behance и Dribbble.

Есть много статей о том, как быстро сделать анимацию в Principle, Flinto и других редакторах, но нет ничего о том, как её готовить конкретно для Behance и Dribbble.

Мы протаптывали эту тропинку сами и поняли, какой способ для нас оптимальный. Статья будет полезна тем, кто ещё не разобрался.

Недавно довелось прочитать статью под названием «Мы уволили самого талантливого сотрудника. Это лучшее решение, которое мы когда-либо делали». [Очень популярная статья, которая получила массу положительных оценок на Medium — прим. пер.]

Давайте присядем, вы и я. Нужно поговорить. Если вы не читали статью по ссылке, то уделите 10–15 минут и прочитайте, впитайте её целиком.

Готовы? Отлично. Теперь разберём этот текст, потому что он значит гораздо больше, чем там написано. Если вы прочитали статью, то понимаете, что автор описывает проблемного сотрудника под вымышленным именем «Рик». Рик — это местный гений с огромным количеством знаний в предметной области, он входит в состав ключевых разработчиков продукта.

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