Периодически в приватных разговорах клиенты/потенциальные клиенты мне задают вопрос «А что вы будете делать, когда прекратится санкционное давление и вернутся западные вендоры, в вашем случае Jira, YouTrack, Confluence и др. (далее по тексту просто Jira?». Я как любитель простого и практичного подхода всегда отвечаю «А что изменится? Будем работать дальше, как и работали и на основании обратной связи делать лучший продукт в мире».

Но вопрос требует перевода на прямолинейный язык «Акула бизнеса вернётся в море, где она доминировала, вы в зоне риска — возможно (скорее всего?) у вас не будет новых проектов, ваш бизнес стагнирует или ещё того хуже. Как вы собираетесь со всем этим бедствием справляться?»

И тут потребуется, наверное, более сложный ответ, чем просто «Работать дальше, больше, лучше».

Собственно, следующие размышления позволяют не сильно заботиться о наступлении дня X (вообще зачем чего‑то бояться? «Не заботьтесь о завтрашнем дне, завтрашний день сам о себе позаботится», приоритет — делать пользу миру вне зависимости от обстоятельств)

Размышление 1. Самые большие потребители западного ПО, которые составляли большую часть пользователей/рынка уже перешли, либо находятся в процессе перехода. Обратного пути, возврата к «как было» не будет.

Потрачены бюджеты на покупку лицензии, внедрение, миграцию и адаптацию пользователей, проекты шли по 1–2 года. Как и зачем это можно откатить обратно? Кто разрешит?

Для объектов Критической Информационной Инфраструктуры (КИИ) существуют приказы и постановления об использовании российского ПО, которые, с большой долей вероятности, не отменят. Тренд существовал задолго до введения санкций, а санкционная политика не дружественных стран стала катализатором. Это безопасность государства. Под определение КИИ попадают практически все предприятия сегмента Enterprise и практически все индустрии. Не только крупные. При любой политической ситуации, цель — технологический суверенитет останется, как основная цель развития ИТ‑индустрии. Сегодня одна администрация в США, а завтра другая. Мы же не можем, как суверенное государство, надеяться на исход выборов в другой стране?

В структуре веб-сервисов типичным базовым набором операций над экземплярами сущностей(объектами) является CRUD (Create, Read, Update и Delete). Этим операциям в REST соответствуют HTTP методы POST, GET, PUT и DELETE. Но зачастую у разработчика возникает необходимость частичного изменения объекта, соответствующего HTTP методу PATCH. Смысл его состоит в том, чтобы на стороне сервера изменить только те поля объекта, которые были переданы в запросе. Причины для этого могут быть различные:

Надо “SELECT * WHERE a=b FROM c” или “SELECT WHERE a=b FROM c ON *” ?

Если вы похожи на меня, то согласитесь: SQL — это одна из тех штук, которые на первый взгляд кажутся легкими (читается как будто по-английски!), но почему-то приходится гуглить каждый простой запрос, чтобы найти правильный синтаксис.

А потом начинаются джойны, агрегирование, подзапросы, и получается совсем белиберда. Вроде такой:

SELECT members.firstname || ' ' || members.lastname
AS "Full Name"
FROM borrowings
INNER JOIN members
ON members.memberid=borrowings.memberid
INNER JOIN books
ON books.bookid=borrowings.bookid
WHERE borrowings.bookid IN (SELECT bookid
  FROM books
  WHERE stock>(SELECT avg(stock)
    FROM books))
GROUP BY members.firstname, members.lastname;

Буэ! Такое спугнет любого новичка, или даже разработчика среднего уровня, если он видит SQL впервые. Но не все так плохо.

Легко запомнить то, что интуитивно понятно, и с помощью этого руководства я надеюсь снизить порог входа в SQL для новичков, а уже опытным предложить по-новому взглянуть на SQL.

Япония считается одной из худших стран в плане баланса между трудом и отдыхом. По уровню удовлетворенности людей своей работой, если верить опросам, у неё худшие результаты в мире (6.1 балла). У России, для сравнения, 6.8, в США – 7.7, даже у Китая 7.1. Это огромная и широко известная проблема. От сотрудника ожидают, что он будет трудиться, пока его босс остается в офисе, а совещания часто проводятся уже после окончания рабочего времени. Даже после работы ожидается, что сотрудник пойдет в кафе со своими коллегами, где пройдет небольшая сессия тимбилдинга за пивом или сакэ.

Но даже в Японии некоторые компании идут в другую сторону. Они снижают нагрузку на сотрудников, проверяя, какой это даст результат. Три месяца назад такой тест провела Microsoft Japan, японское подразделение «Майкрософт». В рамках своего проекта Work-Life Choice Challenge 2019 в течение одного месяца в августе компания ввела четырехдневную рабочую неделю для 2300 своих сотрудников. К стандартным выходным добавили пятницу.

Привет, Хабр. В этой статье я кратко расскажу о деталях реализации микросервисной архитектуры с использованием инструментов, которые предоставляет Spring Cloud на примере простого концепт-пруф приложения.

Код доступен для ознакомления на гитхабе. Образы опубликованы на докерхабе, весь зоопарк стартует одной командой.

Небольшая статья с примерами использования Stream API в Java8, которая, надеюсь, поможет начинающим пользователям освоить и использовать функционал.