Shell wallpaper by manapi

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

Команда Mail.ru Cloud Solutions перевела статью с рекомендациям, благодаря которым вы сможете лучше писать, отлаживать и поддерживать свои сценарии. Хотите верьте, хотите нет, но ничто не может сравниться с удовлетворением от написания чистого, готового к использованию bash-кода, который работает каждый раз.

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

Проекту Lingualeo уже 10 лет. Более 23 миллионов человек из России, Турции, Испании и стран Латинской Америки учат с помощью нашего сервиса английский.

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

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

Проблемы зрелого продукта

«Я пришёл в Lingualeo в августе 2018 руководить бэкэнд разработкой. Тогда бэком занималась команда из 8 разработчиков и 2 админов, которые обслуживали монолит на 1 миллион строк кода преимущественно на PHP. Чтобы внедрить даже небольшую новую фичу, уходило 2 месяца. А затраты на инфраструктуру на 10 000 активных пользователей превышали 1 000 $ в год.

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

Всего у нас в штате было 20 разработчиков, но развивать продукт было невозможно: если что-то добавить, вылезали неожиданные проблемы. У команды уходило 2–3 недели, чтобы всё починить. Разработчики занимались поддержкой кода из 2013 года, и ресурсов на обновление функциональности не было.

В этой статье я хочу рассказать об алгоритме, который помогает ответить на извечный вопрос всех проектов:

Когда проект будет закончен?

Более формально проблема звучит так: "Проект состоит из задач, которые могут зависеть друг друга, а также могут иметь один и тех же исполнителей. Когда проект может быть закончен?"

Npm — это повседневный рабочий инструмент Node.js-разработчиков. Это, в буквальном смысле, нечто такое, чем мы пользуемся ежедневно и по несколько раз на дню. Это — одна из частей экосистемы Node.js, которая привела эту платформу к успеху.

Одним из самых важных и полезных свойств интерфейса командной строки npm является то, что этот интерфейс поддаётся глубокой настройке. Возможности по его настройке поистине огромны. Это позволяет эффективно работать с npm всем категориям пользователей — от крупных организаций до самостоятельных разработчиков.

Одним их механизмов настройки npm является файл .npmrc. Я уже давно наблюдаю за тем, как вокруг этого файла разворачиваются дискуссии. Особенно памятно мне то время, когда я думал, что с помощью этого файла можно поменять имя директории node_modules. В течение длительного времени я не вполне понимал того, насколько полезным может быть .npmrc, да и того, как им вообще пользоваться.



Поэтому сегодня я хочу рассказать о некоторых возможностях по настройке рабочего окружения Node.js с использованием .npmrc. Мне эти настройки помогают быть эффективнее при подготовке Node.js-модулей и при долгосрочной работе над приложениями.

Недавно я делал тест качественных прожекторов Gauss Qplus (habr.com/ru/company/lamptest/blog/506230), но многие выбирают модели подешевле. Я протестировал восемь недорогих прожекторов двух брендов – Старт и Gauss Elementary, продающихся в магазинах Леруа Мерлен.

Если вы хотите знать, как ведут себя пользователи на вашем сайте, надо использовать системы аналитики: они собирают необходимую информацию и предоставляют ее в виде удобных отчетов. Сегодня поговорим о двух из них — Яндекс.Метрике и Google Analytics.

Рассмотрим, какие основные метрики и определения используются в отчетах, расскажем о cookies, выясним, как GA определяет источник трафика и многое другое.

Всем привет! Хочу очередной раз поднять тему про найм. Только я собираюсь поговорить об этом с точки зрения кандидата, а не работодателя. Ведь собеседование, вопреки многим стереотипам, процесс двусторонний — вопросы может задавать не только интервьюер, но и сам соискатель. За прошлый год я провёл порядочное количество собеседований, и абсолютное большинство кандидатов огорчило меня отсутствием вопросов о компании, всего 5 человек стали меня расспрашивать о работе.

Я же считаю, что вопросы на собеседовании должен задавать и сам кандидат, ведь ему предстоит там работать. Из стандартного описания вакансии невозможно понять, что творится в компании, да и на собеседовании принято всё немного приукрашивать. Я думаю, что соискатель должен максимально использовать собеседование для того, чтобы выяснить реальное положение дел в компании. Мало кому захочется попасть в некомфортные условия или в убыточную компанию без перспектив. Если интересно, как во время собеседования получить реальное представление о компании, то добро пожаловать под кат. Я дам список вопросов, которые обычно не ждут интервьюеры, возможно кому-то они помогут принять правильное решение при поиске работы.

Иллюстрация: Юлия Прокопова

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

Поэтому я оптимизирую настройки, чтобы показывать действительно, действительно хорошие буквы. Для этого необходим хороший монитор. Не просто нужен, а ОБЯЗАТЕЛЕН. А под «хорошим» я имею в виду настолько хороший, насколько это возможно. Это мои мысли, основанные на моём собственном опыте того, какие мониторы лучше подходят для программирования.

Redis — достаточно популярный инструмент, который из коробки поддерживает большое количество различных типов данных и методов работы с ними. Во многих проектах он используется в качестве кэшируещего слоя, но его возможности намного шире. Мы в ManyChat очень любим Redis и активно используем его в нашем продукте для решения огромного количества задач. Про некоторые интересные кейсы использования этой in-memory key-value базы данных я расскажу на примерах. Надеюсь, вам они будут полезны, и вы сможете применить что-то в своих проектах.

Рассмотрим следующие кейсы:

• Кэширование данных (да, банально и скучно, но это классный инструмент для кэширования и обойти стороной этот кейс, кажется будет не правильно)
• Работа с очередями на базе redis
• Организация блокировок (mutex)
• Делаем систему rate-limit
• Pubsub — делаем рассылки сообщений на клиенты

Буду работать с сырыми redis командами, чтобы не завязываться на какую-либо конкретную библиотеку, предоставляющую обертку над этими командами. Код буду писать на PHP с использованием ext-redis, но он здесь для наглядности, использовать представленные подходы можно в связке с любым другим языком программирования.

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



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

Здесь представлен фрагмент будущей книги «Основные инструменты и практики для начинающего разработчика программного обеспечения» Бальтазара Рубероля и Этьена Броду. Книга должна помочь образованию подрастающего поколения разработчиков. Она охватит такие темы, как освоение консоли, настройка и эффективная работа в командной оболочке, управление версиями кода с помощью git, основы SQL, инструменты вроде Make, jq и регулярные выражения, основы сетевого взаимодействия, а также лучшие практики разработки программного обеспечения и совместной работы. В настоящее время авторы упорно работают над этим проектом и приглашают всех поучаствовать в списке рассылки.

Содержание

• cat
• head
• tail
• wc
• grep
• cut
• paste
• sort
• uniq
• awk
• tr
• fold
• sed
• Реальные примеры
• Углубляемся: циклы for и xargs
• Итоги
• Что дальше

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

Если вообще не соблюдать правила гигиены, быть токсичным, не последовательным, корыстным, обманывать других, то до первых денег вообще не добраться. Представим, что все хорошо, вы все молодцы и не за горами время, когда пойдет первая серьезная прибыль. Тут рушатся воздушные замки, которые были так скрупулезно выстроены каждым членом команды. Первый думал, что он главный и он заберет 80% прибыли, так как именно он продал машину и на его деньги жила первое время вся команда. Второй думал, что два основателя получат по 50%, так как он программист и создал то самое приложение, на котором все сейчас зарабатывают. Третий и четвертый думали, что они получат долю в бизнесе, как только пойдут деньги, ведь они работали почти круглосуточно и получали значительно меньше, чем могли бы в том же банке.

В итоге бизнес под угрозой развала. А ведь всего бы этого можно было бы избежать, правильно договорившись на берегу. Как?

Привет, Хабр!

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

WebSocket — это прогрессивный стандарт полнодуплексной (двусторонней) связи между клиентом и сторонним сервисом в режиме реального времени. Веб-сокеты используются для организации непрерывного обмена данными без дополнительных HTTP-запросов.

И мы рады сообщить вам, что все это стало возможным в Voximplant благодаря новому модулю VoxEngine, который называется – сюрприз – WebSocket. Отныне вы сможете передавать текст и аудио, пользуясь преимуществами веб-сокетов в полной мере. Проще говоря, у вас появился еще один инструмент, чтобы прокачать ваше приложение.

Из этой статьи вы узнаете, как создать исходящее WebSocket-соединение, передать через него аудиопоток и преобразовать его в текст с помощью Google Cloud Speech-to-Text API.

Вместо предисловия

Vue используется во всех проектах FunCorp. Мы внимательно следим за развитием фреймворка, постоянно улучшаем процесс разработки и внедряем лучшие практики. И, конечно же, мы не могли пройти мимо и не перевести статью Филиппа Раковски, сооснователя VueStorefront, про новые фичи Vue 3, серьёзно влияющие на написание кода.


В прошлый раз мы рассматривали фичи, которые влияют на производительность Vue 3. Нам уже известно, что приложения, написанные на новой версии фреймворка, работают очень быстро, но производительность — не самое важное изменение. Для большинства разработчиков намного важнее то, как Vue 3 повлияет на стиль написания кода.

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

Доброго Хактоберфеста, дамы и господа. Подготовил для вас подборку самых интересных находок из опенсорса за сентябрь 2019.

За полным списком новых полезных инструментов, статей и докладов можно обратиться в мой телеграм канал @OpensourceFindings (по ссылке зеркало, если не открывается оригинал).

В сегодняшнем выпуске.
Технологии внутри: Python, C, Rust, Ruby, JavaScript, Go.
Тематика: веб разработка, администрирование, инструменты разработчика.

Прошлый выпуск.

Голосовые помощники — не далёкое будущее, а реальная действительность. Alexa, Siri, Google Now, Алиса встроены в «умные» колонки, часы и телефоны. Они постепенно меняют наш способ взаимодействия с приложениями и устройствами. Через ассистента можно узнать прогноз погоды, купить билеты на самолет, заказать такси, послушать музыку и включить чайник на кухне, лежа на диване в другой комнате.



Siri или Alexa говорят с пользователями в основном по-английски, поэтому в России они не так популярны, как Алиса от Яндекса. Для разработчиков Алиса тоже удобнее: её создатели ведут блог, выкладывают удобные инструменты на GitHub и помогают встраивать ассистента в новые устройства.

Никита Дубко (@dark_mefody в Твиттере) — разработчик интерфейсов в Яндекс, организатор митапов MinskCSS и MinskJS и редактор новостей в Web-стандартах. Никита не работает в Яндекс.Диалогах и никак не связан с Яндекс.Алисой. Но ему было интересно разобраться, как Алиса работает, поэтому он попробовал применить её навыки для Web и подготовил об этом доклад на FrontendConf РИТ++. В расшифровке доклада Никиты рассмотрим, что полезного могут принести голосовые помощники и построим навык прямо в процессе чтения этого материала.

Классик писал, что счастливые часов не наблюдают. В те дикие времена ещё не было ни программистов, ни Unix, но в наши дни программисты знают твёрдо: вместо них за временем проследит cron.

Утилиты командной строки для меня одновременно слабость и рутина. sed, awk, wc, cut и другие старые программы запускаются скриптами на наших серверах ежедневно. Многие из них оформлены в виде задач для cron, планировщика родом из 70-х.

Я долго пользовался cron поверхностно, не вникая в детали, но однажды, столкнувшись с ошибкой при запуске скрипта, решил разобраться основательно. Так появилась эта статья, при написании которой я ознакомился с POSIX crontab, основными вариантами cron в популярных дистрибутивах Linux и устройством некоторых из них.

Используете Linux и запускаете задачи в cron? Вам интересна архитектура системных приложений в Unix? Тогда нам по пути!

Это исчерпывающее руководство по обеспечению надёжности в JavaScript и Node.js. Здесь собраны десятки лучших постов, книг и инструментов.

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