Всем привет! Меня зовут Лёха, и я работаю бэкенд-разработчиком в FunCorp. Сегодня мы поговорим про реактивное программирование, библиотеку Reactor и немного про веб.

Реактивное программирование часто «подвергается упоминанию», но если вы (как и автор статьи) всё ещё не знаете, что это такое — устраивайтесь поудобнее, попробуем разобраться вместе.

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



В заключительной части мы рассмотрим как Consul работает с протоколом DNS, разберем основные запросы к HTTP API, посмотрим какие виды Health Checks мы можем использовать и, конечно, разберем для чего нужен K/V storage. И что самое важное, ближе познакомимся с некоторыми особенностями на практике.

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



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

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

Но почему бы не дать ему второй шанс? Технологии шагнули вперед и теоретически мы можем получить очень качественный продукт. В данной статье мы рассмотрим на практике как разработать библиотеку для IOS/Android на языке Golang и посмотрим с какими ограничениями и проблемами мы столкнулись в процессе разработки.

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

Всем привет! Мы разрабатываем сервис для сбора, доставки и анализа логов, серверная часть которого написана на Go. В этой статье мы расскажем о проблеме, с которой мы столкнулись при подключении нашего проекта к платежной системе PayPal и о решении, которое мы разработали и успешно внедрили.

Предисловие переводчика: В мире написано столько книг по личной эффективности и тайм-менеджменту, что берясь за этот перевод я безусловно задавал себе вопрос: «А есть ли здесь вообще что-то новое, ради чего эту статью стоит переводить, и главное читать»? Сначала мне казалось, что я ответил на этот вопрос «да», однако реальность оказалась несколько сложнее. 

Сейчас я думаю, что сказать что-то новое человеку, который прочитал хотя бы 2-3 книги по тайм-менеджменту и личной эффективности практически невозможно. Однако существует огромная пропасть между тему, что люди знают, и тем, что люди делают. Поэтому если у вас уже есть какой-то багаж знаний по личной эффективности, я советую вместо вопроса «это что-то, чего я не знаю?» задавать другие вопросы:

1. Согласен ли я с написанным?
2. Если да, поступаю ли я так?
3. Если нет, почему и что я могу сделать чтобы начать поступать правильно? 

Уверен, так статья принесет вам гораздо больше пользы.

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

Также хотел бы сделать замечание для любителей красивого русского языка. Я довольно долго думал, менять ли «продуктивность»  на более близкие родному уху «производительность» и «личную эффективность», но в итоге решил оставить всё как есть – главным образом из-за невозможности использования одного и того же слова в разных контекстах.

В качестве последнего пожелания – это довольно длинная статья, поэтому читайте продуктивно: не переключайтесь между задачами в процессе чтения; делайте перерывы если ощущаете усталость и потерю концентрации; записывайте полезные мысли, не надеясь на память.

Приятного чтения!

На данный момент около 11-12% из 100 000 самых посещаемых сайтов — адаптивны, и нет сомнений, что в ближайшие несколько лет их количество возрастёт.

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

• Адаптивная модернизация.
• Адаптивные мобильные сайты.
• Адаптивный дизайн изначально для мобильных устройств.
• Стратегия поэтапности.

Адаптивная модернизация

Адаптивная модернизация — это процесс, при котором берется существующий сайт, предназначенный только для настольных компьютеров, и «переделывается в адаптивный» по факту.

Как часто вам приходится разрабатывать и запускать приложение локально и упорно искать проблемы, потому что на продакшене приложение ведёт себя не совсем так, как вы этого хотели? А как часто вам присылают тикеты для решения проблемы в приложении, хотя на самом деле проблема именно в несовместимости версий разных приложений? А как долго вам приходится ждать виртуалку, когда для запуска новой версии приложения недостаточно ресурсов локальной машины? Для нас эти вопросы были довольно больными, и мы сломали тысячи копий в спорах, стараясь решить их. Практика показывает, что одним из вариантов для решения этих проблем может стать Vagrant.

Как только мы сделали первую версию iOS приложения, я начал упорно приставать к людям на футбольных полях и баскетбольных площадках с просьбой установить Topic и пощелкать его прямо при мне.

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


Изображение №1: поиск игр (Find a game в меню приложения)

Вступление

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

Я думаю, всем должно быть известно, что JIRA — открытая система для внешней разработки дополнительных плагинов (это кстати очень хорошо). Т.е. умея разрабатывать на java + maven + eclipse, зная хорошо вебдизайн, и т.д и т.п., к JIRA можно приделать все, что только хочется: делай плагины, устанавливай и пользуйся. Более того, можно эти плагины продавать и даже на это жить.

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

Решение есть!

Так вот, есть один плагин, хотя и платный, но умеющий очень многое

Добрый день, дорогие Хабра-читатели. В этот раз в рубрике IT я хотел с вами немного помечтать о будущем. Об эпохе, когда искусственный интеллект не будет диковинкой, и роботы станут нашими близкими друзьями…

Но зачем мечтать, — подумал я. Лучше я расскажу вам об одном таком создании.

Встречайте VIQA WTL – Virtual Intelligence Quality Assurance Web Testing Tool, или по-простому Вика.

Вика — инструмент с Виртуальным Интеллектом для тестирования Web UI (сайтов, по-просту говоря) на языке, понятном пользователю. Инструмент представляет из себя обертку вокруг Selenium и позволяет описывать тестовые сценарии, используя такие понятия как: кнопки, текстовые поля, чеклисты и выпадающие списки, сайт, страницы и блоки. Т.е. использует популярный паттерн PageObjects.

В дополнение к реализации этой концепции, инструмент обладает широким спектром сопутствующих возможностей и большой приспосабливаемостью к конкретному окружению (о чем речь пойдет ниже).

Инструмент, используемый мною в работе в i-Free, был представлен на конференции SQA Days 15 (текст презентации и видео будут выложены в ближайшее время организаторами). В презентации Вика описывалась формате сравнения с наиболее популярным инструментом в этой области Yandex QA Tool. В данной статье я постараюсь более подробно рассказать о самом инструменте без выделения его сильных и слабых сторон (желающим разобраться в этом предлагается сделать это самостоятельно в комментариях и/или послушать видео с конференции).

Virtual Intelligence

Начну с названия. Я думаю, вам интересно узнать, причем здесь Виртуальный Интеллект, и что под этим я подразумеваю?

В последнее время мы успели разобраться со множеством аналитических систем, построить экономическую модель и провести несколько экспериментов по оптимизации конверсий в регистрацию и активацию. Благодаря Илье Красинскому(ex. LinguaLeo product chief) мы научились правильной настройке и анализу данных Google Analytics, узнали как строить экономические модели интернет проектов. Далее мы стали разбираться с event based аналитикой и настройкой mixpanel. Теперь мы решили поделиться этими знаниями с хабросообществом.


В этой статье мы рассмотрим:

• Построение экономики продукта с помощью Google таблиц
• Формирование отчета Google Analytics по когортам и каналам
• Создание таблицы анализа эффективности платных каналов

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

Объемы покупок и продаж, совершаемых компаниями в режиме онлайн, постоянно растут. Обычные пользователи сети покупают в интернете много, а бизнесы — и того больше. В 2012 году Forrester Research прогнозировал объем заказов американских компаний и правительственных агентств, совершаемых в интернете, на уровне $559 млрд — в два раза больше прогнозируемого объема B2С-трат.

Тем не менее, по многим направлениям B2C-сегмент опередил B2B в таких аспектах, как простота совершения покупок и слаженность процессов. Но все меняется. К примеру, 46% руководителей компаний, работающих в B2B-сфере электронной коммерции, заявили в ходе опроса Forrester Research, что ожидают прихода в онлайн до трети своих клиентов в течение трех лет. В ходе того же опроса 67% руководителей заявили, что IT-бюджет их компаний в текущем году увеличится, а 49% уверили в том, что в течение 18 месяцев ecommerce-платформа компании будет полностью переработана для обеспечения продаж другим компаниям, правительственным агентствам, образовательным учреждениям и прочим бизнесам.

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

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

Тем, кто работает с Git, хорошо знаком способ отредактировать последний коммит командой git commit --amend. Это удобно для мелких правок (изменить комментарий к коммиту, поправить строчку в коде и т.п.), потому что частенько хорошие мысли по поводу коммита приходят в голову уже после того, как этот коммит сделан.

Но с данным способом правки коммитов следует быть осторожным в случае, когда вы работаете с удалённым репозиторием и ещё более осторожным, когда вы работаете над исходным кодом в составе команды. Область безопасного использования опции --amend заканчивается там, где начинается область использования команды git push.

Привет, Хабрапользователи!
Я продолжаю свое погружение в пикантности automation-а и configuration management-а, параллельно пытаясь делится опытом с community.

Речь пойдет опять об инструменте автоматизации разрешения зависимостей Сhef cookbook-ов, которым наша компания пользуется, а именно — Berkshelf.

При сборке проектов для Android Gradle позволяет указать некоторые параметры, позволяющие собрать и подписать пакет, готовый для загрузки в Google Play. Однако, вряд ли стоит загружать некоторые данные, такие как пароль от приватного ключа в публичный репозиторий. В статье, перевод которой ниже, автор рассматривает способы ввода приватной информации, такой как пароли, во время сборки проекта.

Gradle позволяет получить доступ к консоли с помощью метода System.console(). Консоль предоставляет метод для чтения паролей, поэтому для ввода пароля можно использовать:

def password = System.console().readPassword("\nPlease enter key passphrase: ")

Теперь можно использовать пароль в любом месте скрипта сборки, и все готово… ой, тогда это будет слишком короткий пост, поэтому теперь поговорим о проблемах.

Я как-то писал про частую ошибку проектировщиков, когда мы совсем забываем про пользователей, считая, что знаем как они думают и как им удобнее.
Понятно, что пользовательское тестирование сильно помогает при проектировании интерфейсов и целых продуктов, но чтобы что-то протестировать, нужен готовый продукт или как минимум прототип.
Создание прототипа хоть и сильно удешевляет тестирование, но тоже требует немалых сил и времени. Да и перед созданием прототипа часто возникают варианты концепции интерфейса, которые хорошо бы тоже протестировать, не затратив при этом больше получаса времени. В этом случае проектировщику может помочь так называемое «коридорное тестирование». На хабре этой теме было уделено не так много внимания, поэтому я решил поделиться несколькими приемами из своего опыта.

С момента создания Интернет-агентства ALTWeb в 2004 году, я всегда с большим интересом смотрел на различные технологии и сервисы для автоматизации Интернет-маркетинга. Я всегда стремился создать удобные средства автоматизации, которые бы позволяли экономить время и повышать эффективность.

В то время всех клиентов интересовало только SEO, так как это был самый простой и быстрый способ получить массу клиентов. Тогда рынок сервисов по автоматизации различных SEO-процессов был практически пустой. Для поискового продвижения существовали только сервисы автоматической регистрации в каталогах и линкаторы. Позднее, в 2006 году пришла эра ссылочных бирж, а в 2008 году — сервисов автоматизации продвижения.

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