А казино? Ну не сложно же анонсировать, раз дальше дизайнов всё равно дело не пойдёт.

«REPL, скрипты, F#: интерактивный подход к прототипированию и дебагу приложений Генри Ковалевский», ведущий разработчик, LC Group

"Генри Ковалевский" нужно вынести из кавычек. Стыдно хоть?

1. «REPL, скрипты, F#: интерактивный подход к прототипированию и дебагу приложений

2. Генри Ковалевский», ведущий разработчик, LC Group

лол. Стыдно хоть?

Когда говорят слово "микросервисы", часто забывают уточнить о каких именно аспектах микросервисности идёт речь. Независимые билды/деплойменты? Изоляция разных команд друг от друга? Использование разных ЯП для разных сервисов?

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

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

Одна о

Зачем кодить, если можно не кодить?

Что за идиотский вопрос

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

Как вы там в 2012-ом?

А громадное количество строковых значений по смыслу не могут быть "какими угодно". И чё? :-)

Уточните пожалуйста, речь про "Disrupted: My Misadventure in the Start-Up Bubble" by Dan Lyons?

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

Сидящий за Маком человек, потому что традиция. Компьютером человек, как правило, пользоваться не умеет. Базовые идеи вроде файлов и директорий понимает с трудом, потому что think different.

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

Слово "дизайнер" очень широкое и включает в себя в том числе и иллюстрации. То, о чём вы пишете - это может быть например UI designer - человек, который специализируется на кнопочках.

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

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

UX занимается непосредственно опытом, UI — интерфейсом. Без сомнения, эти специальности так или иначе пересекаются.

UX и UI - это просто булшит, который пишет себе каждый первый дизайнер. Раньше было например "веб дизайнер", теперь это называется "UI/UX designer". Проблема UI/UX дизайнеров в том, что они часто плохо умеют в компьютеры (хуже, чем в цвета) - и там где сто лет есть какое-то традиционное решение ("паттерн") - они с радостью увидят новую уникальную проблему и будут её уникально решать.

Вот например вы первый раз пользуетесь каким-то софтом, вам там всякие подсказки вылазят. И вы думаете, блин, я олд скул, я лучше сам, как это убрать. А никак. Нету "настроек", нету в настройках галочки "показывать мне подсказки". Через сутки оно само исчезнет. Или не через сутки, а через 5 часов использования. Знаете почему? Потому что дизайнеры так придумали.

Но чтобы парк получился действительно красивым и любимым, все элементы должны быть в гармонии, в сетке, удобно и понятно интуитивно для пользователя. В общем, UX/UI друг друга понимают и дополняют.  Для рынка интересен человек, который разбирается и в том, и в другом.

Человеку в принципе как ни сделай, ему если софт нужен, он привыкнет. Что делают дизайнеры - пытаются сделать так, чтобы домохозяйка из Джерси смогла написать песню и получить лайки. Т.е. вот вы например грузчик из Воронежа. Учитесь быть домохозяйкой из Джерси.

Этапы работы дизайнера над проектом:

Анализ задачи. Выявление проблемы, построение гипотез и сценариев использования. Прототип. Создание прототипа и проработка структуры будущего продукта. Дизайн. Работа с визуальной частью. Создание графической концепции.

Это полнейшая глупость, потому что дизайн никогда не делается "по вотерфолу". Любой жизнеспособный процесс будет включать в себя что-то типа: подумать-сделать-проверить-гоу ту начало. В зависимости от богатства внутреннего мира дизайнера это может превратиться в нечто более развесистое. Например популярный "Design thinking" подход:

Сейчас, чтобы стать дизайнером, нужно много знать.

Ба-дум-тсс.

Существует определённый набор навыков, которые, в отличие от живописи, дизайнеру точно нужны. Это работа с инструментами.
...
Figma
...
Через пару месяцев добавите 3D иллюстрацию, через год доберётесь до интерактива. Именно интерактив и анимация сейчас в тренде.

Читатель конечно заметил как внимание уделяется изучению Фигмы, а не способности применить критическое мышление, порезать задачу-проблему на кусочки, выстроить систему, описать её, как-то вообще выстроить весь этот "мир" в котором решается задача. Не, начнём с Фигмы, позже добавим 3D иллюстрации. Помним как выше разбирали "дизайнер - не иллюстратор", да?

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

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

Самая большая (и смешная) проблема дизайнеров в том, что те представители, которые скорее "только визуальный дизайн", совершенно не понимают насколько большая пропасть в плане ценности/важности/рискованности лежит между радиусом кривизны кнопок и сущностями, процессами, данными, техническими ограничениями, и т.д.

О чём вы думаете, когда вам кто-то говорит про дизайн?

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

а цель у нас одна - задеплоить уже наконец этот **** проект!

...

то была огромная "простыня" текста, читать которую было слишком долго.

That's the spirit! Может и не лезли бы тогда делиться мудростью?

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

Project project = Mockito.spy(Project.class);    
Mockito.when(project.getExtensions()).thenReturn(...);
Mockito.when(project. ...).thenReturn(...);

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

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

В этой статье будут описаны малоизвестные, но полезные, функции Python.

Вы конечно хотели сказать "Я тут начал читать первую книжку по питону и во второй главе наткнулся на ..."

Я имел в виду более прямую связь между GraphQL-фасадом и источником данных. Например программист определяет источник данных на уровне "select * from BankAccounts", а SPQR берёт на себя управление частями "where", "order by" и "skip/limit".

Вот у вас написано:

GraphQL — это язык запросов к API-интерфейсам. Он отображает предоставляемые сервером данные, чтобы клиент смог выбрать именно то, что ему нужно.

Что именно SPQR делает для того, чтобы "клиент смог выбрать именно то, что ему нужно"?

@GraphQLQuery(name = "getAllBalance")
public List<BankAccountDto> getAll() {
  return service.getAll();
}

Ненене, погодите, а паджинация, фильтрация, сортировка - это все руками надо делать чтоли?

Маппинг полиморфных JSON-объектов достаточно прост с проектом Hibernate Types. Поскольку вы способны кастомизировать Jackson ObjectMapper так, как вам захочется, с помощью этого подхода можно решать самые разные задачи.

Всё то же самое делается ещё проще через написание своего AttributeConverter, в котором точно так же можно какой угодно кастомизированный ObjectMapper использовать.

Жопа с ушами :-)