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

В настоящее время всё больше компаний переводят свою инфраструктуру с железных серверов и собственных виртуалок в облака. Такое решение легко объяснить: нет необходимости заботиться о железе, кластер легко конфигурируется множеством различных способов… а самое главное — имеющиеся технологии (вроде Kubernetes) позволяют просто масштабировать вычислительные мощности в зависимости от нагрузки.

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

Написание чистого кода — это навык, который становится обязательным на определённом этапе карьеры программиста. Особенно этот навык важен тогда, когда программист пытается найти свою первую работу. Это, по существу, то, что делает разработчика командным игроком, и то, что способно либо «завалить» собеседование, либо помочь его успешно пройти. Работодатели, принимая кадровые решения, смотрят на код, написанный их потенциальными сотрудниками. Код, который пишет программист, должен быть понятен не только машинам, но и людям.



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

Очень долго хотел написать статью, но не хватало времени. Нигде (в том числе на Хабре) не нашёл такой простой альтернативы munin, как описанная в этой статье.

Автор материала, перевод которого мы публикуем сегодня, говорит, что ему очень и очень часто приходилось видеть, как веб-разработчики бездумно пользуются современными фреймворками вроде React, Angular или Vue.js. Эти фреймворки предлагают много интересного, но, как правило, программисты, применяя их, не учитывают главнейшей причины их существования. Обычно на вопрос: «Почему вы используете фреймворк X», можно услышать следующие ответы, среди которых, однако, нет самого главного:

• Этот фреймворк основан на компонентах.
• У него имеется мощное сообщество.
• Для него разработано множество сторонних библиотек, которые помогают решать различные задачи.
• Существуют полезные дополнительные компоненты для этого фреймворка.
• Имеются расширения для браузеров, которые помогают отлаживать приложения, созданные с помощью данного фреймворка.
• Этот фреймворк хорошо подходит для создания одностраничных приложений.

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

Добрый день, уважаемые читатели Хабрахабра!

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

Статья может быть интересна как новичкам в программировании — увидеть, сколько препятствий стоят на пути у готового продукта, так и более продвинутым специалистам — где-то посмеяться, где-то поплакать, где-то написать комментарий «жизненно».

Преамбула

И так, что же может сделать один программист за 4 дня?

За последнее десятилетие я реализовал много проектов, связанных с агрегацией и анализом контента. Часто агрегация включает в себя снятие данных со сторонних сайтов, то есть скрапинг. Хотя я стараюсь избегать этого термина. Он превратился в некий ярлык, с которым связано много заблуждений. Основное заблуждение в том, что веб-скрапинг можно заблокировать с помощью X, Y, Z.

tl; dr; Нельзя.

С точки зрения бизнеса

На прошлой неделе я встретился с высокопоставленным руководителем из отрасли, в которой развиваю свой бизнес GO2CINEMA. Без сомнения, это один из самых умных и знающих людей в киноиндустрии.

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

Я посоветовался с этим человеком насчёт поиска инвестиций. Он предложил свою помощь и попросил подготовить анализ всех способов блокировки моего текущего бизнеса, включая скрапинг контента (с технической и юридической точек зрения). Я подготовил необходимые документы и поделился с ним перед нашей встречей. Его реакция была примерно такой:

Да, тщательное исследование. Но всё-таки есть способы, чтобы тебя заблокировать. *ухмыляется*

Нет, парень, нет таких способов.

«Начало — более чем половина всего».

Это очень древний GTD-принцип: возраст его, вероятно, исчисляется тысячелетиями. (Например, Викицитатник в настоящее время приписывает его Аристотелю, хотя и без подтверждающего указания на первоисточник.) Суть его в том, что с чистого листа начинать какой-либо проект бывает очень трудно (и даже приходится заставлять себя); а вот если есть несколько простых начальных шагов, выполнение которых приводит к появлению частично готового проекта, то продолжить работу над ним «по инерции» становится куда проще — так просто, как если бы проект этот ужé был не только начат, но и готов даже более, чем наполовину. А кроме того, когда заранее хорошо знаешь, какими должны быть начальные шаги, то тогда трудно бывает допустить ошибку, совершая их.

Мне довелось сочинить более десятка модулей для Node.js с открытым исходным кодом и опубликовать их в качестве пакетов npm. Чем больше модулей я делал, тем сильнее понимал (в том числе путём проб и ошибок), что начальные шаги для их создания могут быть одинаковыми и даже могут совершаться в одном и том же порядке. Сегодня я публикую этот порядок в надежде на то, что он станет подспорьем в работе программистов, сочиняющих свой код на языке JavaScript для движка Node.

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