Данная статья является продолжением ряда статей опубликованных здесь ранее и посвященных этапам:

1. Постановке требований
2. Проектированию
3. Реализации. Service Layer

В ней описано каким образом мы организовали процесс разработки привлекая разработчиков из собщества Magento с момента старта проекта в середине прошлого лета и с чем мы подошли к General Availability релизу сделанному на прошлой неделе.

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

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

UPD: альтернативный вариант перевода вы можете найти на rsdn (спасибо flamingo за ссылку).

Все, кто работал с seo-продвижением ни раз слышал утверждения: “Сайту нужно семантическое ядро (СЯ)”, “Нет семантического ядра – нет и продвижения”, “СЯ – это основа сайта” и т.д. и т.п. Вскоре начали говорить, что СЯ – это, конечно, хорошо, но нужна ещё и “карта релевантности” (она же карта перелинковки, карта вхождения ключевых запросов). Но с определением этого понятия творится какая-то неразбериха. Даже подробные гайды по составлению карты релевантности от ведущих агентств ясности не добавляют. Сложно понять как с тем, что они показывают в примерах можно работать системно.

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

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

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



Ниже изложено то, чему руководства по CSS меня не научили.

Участники Saint TeamLead Conf назвали доклад Александра Зизы одним из лучших вероятно потому, что от навыков коммуникации тимлида зависит многое, а развиты они, как правило, не очень хорошо.

Рассказ будет состоять из четырех смысловых блоков:

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

1. Высокоэффективные коммуникации: 4 типа позиционной коммуникации. Эта часть посвящена техническим вопросам, связанным с построением высокоэффективной коммуникации. Грубо говоря, что нужно делать в конкретной ситуации, для того чтобы коммуникация была эффективна.
   

1. Мастерство: 4 уровня развития компетентности. Здесь поговорим про личное мастерство руководителя, который осуществляет свое управленческое воздействие через коммуникацию.
   

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

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

Всем привет!

Мы продолжаем давать открытые уроки по нашему курсу «Разработчик Java». Сегодня мы хотим поделиться второй частью посвящённой многопоточности. Если в первой части рассматривались базисы многопоточности плюс был написан Ping-Pong с применением synchronized-notifyAll, то в новой части уже идёт более углубленное изучение, а Ping-Pong переписали в разных вариациях уже без synchronized-notifyAll


Ждём комментарии и вопрос, которые можно задать тут или зайти к Виталию на день открытых дверей.

Введение

С момента первого релиза прошло достаточно много времени (ссылка на предыдущую статью). Что изменилось?

• улучшена стабильность системы в целом;
• реализована ленивая загрузка компонентов;
• встроена базовая система слушателей;
• встроена поддержка аспектно-ориентированного программирования (для средней сложности решения задач, в остальном все же советую использовать — AspectJ библиотеку)
• новый загрузчик RequestFactory
• встроена работа с кешем на базе EhCache, Guava
• встроена работа с потоками (как инициализация посредством аннотации @SimpleTask, так и прямая работа с пулом)

**Модули

• модуль работы с базой (легковесный ORM с поддержкой JPA, Transactions, NO-SQL Driver — Orient, Crud methods, repository system и автогенерацией запросов из функции класса-репозитория)
• модуль работы с веб-мордой (маппинг линков посредством аннотаций, поддержка кастомных producers/consumes, Velocity Template Rendering Page, Basic Security Requests, Sessions, Cookies, SSL) на базе Netty 4.1.30.Final

Структура фреймворка

"Это конечно же все хорошо,"- скажите Вы, -"но по факту работает ли это все?".
"Да, работает. Прошу под кат".

Процесс реализации примера

Для реализации примера я буду использовать Maven 3 и Intelijj Idea 2018.2.

1) Подключаем зависимости:

Всем привет!

На прошлой неделе провели открытый урок по курсу «Разработчик на Spring Framework», где преподаватель Юрий Дворжецкий знакомил с возможностями Spring Boot 2.0, рассказывал и показывал разработку веб-приложений с его помощью и разобрал работу Spring Boot Actuator.


Как всегда ждём вопросы, предложения и прочие тапки :)

Эта статья рассказывает о времени выполнения и о расходе памяти большинства алгоритмов используемых в информатике. В прошлом, когда я готовился к прохождению собеседования я потратил много времени исследуя интернет для поиска информации о лучшем, среднем и худшем случае работы алгоритмов поиска и сортировки, чтобы заданный вопрос на собеседовании не поставил меня в тупик. За последние несколько лет я проходил интервью в нескольких стартапах из Силиконовой долины, а также в некоторых крупных компаниях таких как Yahoo, eBay, LinkedIn и Google и каждый раз, когда я готовился к интервью, я подумал: «Почему никто не создал хорошую шпаргалку по асимптотической сложности алгоритмов? ». Чтобы сохранить ваше время я создал такую шпаргалку. Наслаждайтесь!

На Хабре совсем нет информации про TestContainers. На момент написания этой статьи, в поисковой выдаче есть анонсы наших же конференций, и всё. Между тем, в проекте на GitHub у них уже более 700 коммитов, 54 контрибьютора и 5 лет истории. Похоже, все эти пять лет проект тщательно скрывался спецслужбами и НЛО. Настало время выйти из тени на свет.

Чукча — читатель, а не писатель. Поэтому, вместо написания своего текста, я попросил разрешения на перевод соответствующей статьи из блога RebelLabs.

Итак, здесь мы поделимся парой слов о наимоднейшей Java-библиотеке для интеграционного тестирования — TestContainers. Кроме этого, будет немного о том, почему интеграционное тестирование настолько важно для ZeroTurnaround и их требования к интеграционным тестам. И конечно, будет полнофункциональный пример интеграционного теста для Java-агента. Если кто-то никогда в глаза не видел код Java-агента, то сейчас самое время. Добро пожаловать под кат!

Сервис-ориентированная архитектура (service-oriented architecture, SOA) придумана в конце 1980-х. Она берёт своё начало в идеях, изложенных в CORBA, DCOM, DCE и других документах. О SOA написано много, есть несколько её реализаций. Но, по сути, SOA можно свести к нескольким идеям, причём архитектура не диктует способы их реализации:

• Сочетаемость приложений, ориентированных на пользователей.
• Многократное использование бизнес-сервисов.
• Независимость от набора технологий.
• Автономность (независимые эволюция, масштабируемость и развёртываемость).

SOA — это набор архитектурных принципов, не зависящих от технологий и продуктов, совсем как полиморфизм или инкапсуляция.

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


Конструирование идей как инновационный магический кристалл

– Наша Лена уходит в декрет, – сообщил начальник, – поэтому нам надо искать замену на время ее отсутствия. Часть задач мы распределим, а вот как быть с задачей перенаправления обращений пользователей?

Лена – это наш сотрудник технической поддержки. Одна из ее обязанностей – распределение поступающих на электронную почту обращений между специалистами. Она анализирует обращение и определяет ряд характеристик. Например, «Тип обращения»: ошибка системы, пользователю просто нужна консультация, пользователь хочет какую-то новую функциональность. Определяет «Функциональный модуль системы»: модуль бухгалтерии, модуль паспортизации оборудования и т.д. Проставив все эти характеристики, она перенаправляет обращение соответствующему специалисту.

– Давай я напишу программу, которая это будет делать автоматически! – ответил я.

На этом увлекательный роман заканчиваем и переходим к технической части.

Некоторое время назад я рассказывал про свой проект Не звони!, где при добавлении своего номера телефона в реестр необходимо подтвердить, что это твой номер.

Операционная система Android предоставляет мощный фундамент для разработки приложений, которые отлично работают на множестве разнообразных устройств и форм-факторов. Теперь, как говорится, мы услышали жалобы разработчиков: трудно создавать "безглючные" приложения в условиях сложных циклов жизни объектов и отсутствия рекомендованной архитектуры приложения.

Нам, создателям Android, надо сделать простым и веселым написание устойчивых приложений, чтобы перевести усилия разработчиков в те области, в которых можно создавать инновации. Сегодня мы аннонсируем путеводитель по архитектуре Android-приложений и превью библиотек Architecture Components. Вместо того чтобы изобретать колесо, мы признаем работу, сделанную авторами популярных сторонних Android-библиотек (прим. пер.: WAT?).

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

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

Можно, конечно, воспользоваться услугами агентств и бизнес-аналитиков попроще или самим составить анкету и выйти на улицу… Но как мы все знаем, everybody lies, и данные могут быть сильно искажены. То есть толку от такого исследования будет ноль.

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

Мой вариант – это «многоходовочка», но выполнение только первого этапа, о котором пойдет речь, уже хорошо отвечает на указанный выше вопрос.

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

В первой части статьи мы говорили, что основным препятствием при использовании микросервисной архитектуры является то, что модели предметной области (domain model), транзакции и запросы удивительно устойчивы к разделению по функциональному признаку. Было показано, что решение заключается в реализации бизнес-логики каждого сервиса в виде набора DDD-агрегатов. Каждая транзакция обновляет или создает один единственный агрегат. События используются для поддержания целостности данных между агрегатами (и сервисами).

Во второй части статьи мы увидим, что ключевой задачей при использовании событий является атомарное изменение состояния агрегата и одновременная публикация события. Посмотрим, как решить эту проблему с помощью Event Sourcing — используя событийно-ориентированный подход к проектированию бизнес-логики и системы сохранения состояния. После этого опишем, как микросервисная архитектура затрудняет реализацию запросов к базе данных, и как подход, называемый Command Query Responsibility Segregation (CQRS), помогает реализовывать масштабируемые и производительные запросы.

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

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

Однако микросервисы являются не таким уж простым и универсальным решением. В частности, модели предметной области, транзакции и запросы удивительно устойчивы к разделению по функциональному признаку. В результате разработка транзакционных бизнес-приложений с использованием микросервисной архитектуры является довольно сложной задачей. В этой статье мы рассмотрим способ разработки микросервисов, при котором эти проблемы решаются с помощью паттерна проектирования на основе предметной области (Domain Driven Design), Event Sourcing и CQRS.

Я выступал на DomCode в ноябре 2015 года (отличная конференция, кстати; проходила в маленьком красивом городке) и рассказывал о своем списке правил для построения open source сообществ. Один человек позже попросил меня объяснить, почему я советую мерджить патчи быстро, не дожидаясь завершения тестирования непрерывной интеграции (Continuous Integration) и без перепроверки кода. Я буду называть эту стратегию optimistic merging (ОМ). И сейчас я расскажу о некоторых ее плюсах.

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

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

Один из аспектов профессии разработчика — посвящение профанов в особенности процесса разработки ПО.
С. Макконнелл, Совершенный код

Цель этой публикации — поделиться опытом работы над проектом со сложной историей и тяжёлым наследием. После ухода из очередного т.н. «стартапа», я решил что хочу попробовать новых ощущений: enterprise, legacy, etc. Для этого взялся за работу над корпоративным приложением для транснационального концерна. Разработка на тот момент шла уже третий год, приложение пережило несколько поколений разработчиков, но стабильного релиза так и не было.

Полагаю публикация будет полезной:

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

Затрагиваемые в статье вопросы:

• Низкая компетенция разработчиков, и что с этим можно поделать?
• Какие аргументы убедительны в глазах заказчика для нефункциональных изменений в проекте?
• Почему работа аналитиков и QA очень важна с точки зрения разработки в частности и для проекта в целом?