Когда говорят слово "микросервисы", часто забывают уточнить о каких именно аспектах микросервисности идёт речь. Независимые билды/деплойменты? Изоляция разных команд друг от друга? Использование разных ЯП для разных сервисов?
Если всё гарантированно пишется на джаве, лежит в одном репозитории, билдится и деплоится как монолит - можно просто сразу делать монолитную кодовую базу, в которой взаимодействие между модулями, в зависимости от профиля сборки, либо "напрямую" (обычные вызовы внутри ЯП), либо "через транспорт".
Такой подход упрощает разработку, потому что программируется фактически монолит - легко переиспользовать код, легко рефакторить, легко заставить работать локально, легко отлаживать, легко писать интеграционные тесты, а "микросервисность" появляется только при деплойменте.
Не нужно переносить таблицу с десктопа на телефон. Нужно посмотреть какие задачи таблица решала на десктопе - и придумать как те же задачи можно хорошо решить на телефоне.
Представляется сидящий за дорогим и мощным компьютером человек, который много лет учился в художественной школе, потом где-то ещё и целится, как минимум, в британку.
Сидящий за Маком человек, потому что традиция. Компьютером человек, как правило, пользоваться не умеет. Базовые идеи вроде файлов и директорий понимает с трудом, потому что 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! Может и не лезли бы тогда делиться мудростью?
По существу. Руками ничего делать не надо. Никогда. Надо писать скрипты и запускать их. Вот хотите с нуля сконфигурировать машину - пишете скрипт, кладёте в гит. Запускаете его. Получаете сконфигурированную машину. Хотите задеплоить версию сайта из гита - пишете скрипт, кладёте в гит. Запускаете его. Получаете новую задеплоенную версию. Это позволяет добиться прозрачности и воспроизводимости. Под скриптами понимается что угодно от баша на коленке до всяких там терраформов.
Делать моки на чужой код - плохая идея. Вы не контролируете как тот код работает, поэтому делать высказывания вида "когда - тогда" - это как в таких розовых очках ходить, и убеждать всех, что всё хорошо.
Как правильно предложили выше, надо писать инт тесты. Юнит тесты - это если у вас там есть какая-то логика, которую в изоляции от внешних зависимостей можно протестировать.
Я имел в виду более прямую связь между GraphQL-фасадом и источником данных. Например программист определяет источник данных на уровне "select * from BankAccounts", а SPQR берёт на себя управление частями "where", "order by" и "skip/limit".
Вот у вас написано:
GraphQL — это язык запросов к API-интерфейсам. Он отображает предоставляемые сервером данные, чтобы клиент смог выбрать именно то, что ему нужно.
Что именно SPQR делает для того, чтобы "клиент смог выбрать именно то, что ему нужно"?
Маппинг полиморфных JSON-объектов достаточно прост с проектом Hibernate Types. Поскольку вы способны кастомизировать Jackson ObjectMapper так, как вам захочется, с помощью этого подхода можно решать самые разные задачи.
Всё то же самое делается ещё проще через написание своего AttributeConverter, в котором точно так же можно какой угодно кастомизированный ObjectMapper использовать.
В каждом топике про фейл большой компании одни и те же комментарии: попытка представить большую компанию как одного недостойного человека. Не надоело?
Хозяева и их агенты бывали разные; некоторые говорили мягко, потому что им было тяжело делать то, что они делали; другие сердились, потому что им было тяжело проявлять жестокость; третьи держались холодно, потому что они давно уже поняли: хозяин должен держаться холодно, иначе ты не настоящий хозяин. И все они подчинялись силе, превосходящей силу каждого из них в отдельности. Некоторые ненавидели математику, которая заставляла их прийти сюда, другие боялись ее; а были и такие, кто преклонялся перед этой математикой, потому что, положась на нее, можно было не думать, можно было заглушить в себе всякое чувство. Если землей владел банк или трест, посредник говорил: банку, тресту нужно то-то и то-то; банк, трест настаивает, требует... - словно банк или трест были какие-то чудовища, наделенные способностью мыслить и чувствовать, чудовища, поймавшие их в свою ловушку. Они, агенты, не отвечали за действия банков и трестов,- они были всего лишь люди, рабы, а банк - он и машина, он и повелитель. Кое-кто из агентов даже гордился тем, что они в рабстве у таких холодных и могучих повелителей. Агенты сидели в машинах и разъясняли людям: вы же знаете, земля истощена. Сколько лет вы здесь копаетесь, и не запомнишь.
А казино? Ну не сложно же анонсировать, раз дальше дизайнов всё равно дело не пойдёт.
"Генри Ковалевский" нужно вынести из кавычек. Стыдно хоть?
лол. Стыдно хоть?
Когда говорят слово "микросервисы", часто забывают уточнить о каких именно аспектах микросервисности идёт речь. Независимые билды/деплойменты? Изоляция разных команд друг от друга? Использование разных ЯП для разных сервисов?
Если всё гарантированно пишется на джаве, лежит в одном репозитории, билдится и деплоится как монолит - можно просто сразу делать монолитную кодовую базу, в которой взаимодействие между модулями, в зависимости от профиля сборки, либо "напрямую" (обычные вызовы внутри ЯП), либо "через транспорт".
Такой подход упрощает разработку, потому что программируется фактически монолит - легко переиспользовать код, легко рефакторить, легко заставить работать локально, легко отлаживать, легко писать интеграционные тесты, а "микросервисность" появляется только при деплойменте.
Одна о
Что за идиотский вопрос
Не нужно переносить таблицу с десктопа на телефон. Нужно посмотреть какие задачи таблица решала на десктопе - и придумать как те же задачи можно хорошо решить на телефоне.
Как вы там в 2012-ом?
А громадное количество строковых значений по смыслу не могут быть "какими угодно". И чё? :-)
Уточните пожалуйста, речь про "Disrupted: My Misadventure in the Start-Up Bubble" by Dan Lyons?
Сидящий за Маком человек, потому что традиция. Компьютером человек, как правило, пользоваться не умеет. Базовые идеи вроде файлов и директорий понимает с трудом, потому что think different.
Слово "дизайнер" очень широкое и включает в себя в том числе и иллюстрации. То, о чём вы пишете - это может быть например UI designer - человек, который специализируется на кнопочках.
Дизайнеры уже давно решили все проблемы. Пользователь приходит, думает чего он хочет, и система ему это делает. Этот вариант совершенно реалистичен, потому что дизайнеры в принципе не знают что возможно, а что невозможно. Прочитать мысли? Нельзя? Ну ладно, ещё итерация. Передать гигабайтный файл из Европы в Америку за секунду? Нельзя? Ну ладно, ещё итерация.
UX и UI - это просто булшит, который пишет себе каждый первый дизайнер. Раньше было например "веб дизайнер", теперь это называется "UI/UX designer". Проблема UI/UX дизайнеров в том, что они часто плохо умеют в компьютеры (хуже, чем в цвета) - и там где сто лет есть какое-то традиционное решение ("паттерн") - они с радостью увидят новую уникальную проблему и будут её уникально решать.
Вот например вы первый раз пользуетесь каким-то софтом, вам там всякие подсказки вылазят. И вы думаете, блин, я олд скул, я лучше сам, как это убрать. А никак. Нету "настроек", нету в настройках галочки "показывать мне подсказки". Через сутки оно само исчезнет. Или не через сутки, а через 5 часов использования. Знаете почему? Потому что дизайнеры так придумали.
Человеку в принципе как ни сделай, ему если софт нужен, он привыкнет. Что делают дизайнеры - пытаются сделать так, чтобы домохозяйка из Джерси смогла написать песню и получить лайки. Т.е. вот вы например грузчик из Воронежа. Учитесь быть домохозяйкой из Джерси.
Это полнейшая глупость, потому что дизайн никогда не делается "по вотерфолу". Любой жизнеспособный процесс будет включать в себя что-то типа: подумать-сделать-проверить-гоу ту начало. В зависимости от богатства внутреннего мира дизайнера это может превратиться в нечто более развесистое. Например популярный "Design thinking" подход:
Ба-дум-тсс.
Читатель конечно заметил как внимание уделяется изучению Фигмы, а не способности применить критическое мышление, порезать задачу-проблему на кусочки, выстроить систему, описать её, как-то вообще выстроить весь этот "мир" в котором решается задача. Не, начнём с Фигмы, позже добавим 3D иллюстрации. Помним как выше разбирали "дизайнер - не иллюстратор", да?
Я совершенно уверен, что где-то есть дизайнеры, которые понимают границы своих знаний и навыков, знают как работать с ограничениями реальности - но эти люди не будут типичными представителями профессии. Типичный представитель - это раскрашивальщик кнопок, который почему-то убеждён, что знает как лучше для пользователя.
За словом "дизайн" скрывается очень многое - от радиуса кривизны углов кнопок до собственно "солюшен дизайна" - где нужно глубоко въехать в проблему, учесть всякие ограничения, и выдумать решение - как оно будет работать, из каких частей состоять, и т.д.
Самая большая (и смешная) проблема дизайнеров в том, что те представители, которые скорее "только визуальный дизайн", совершенно не понимают насколько большая пропасть в плане ценности/важности/рискованности лежит между радиусом кривизны кнопок и сущностями, процессами, данными, техническими ограничениями, и т.д.
Об эмпатии, глупости, отсутствии логики и десятках итераций "у вас ошибка в 3-ей строчке". О радиусе скругления углов у кнопок. О подходах, ориентированных на сценарии, а не на целостную картину происходящего. О слезах, соплях и обидах на всю жизнь.
That's the spirit! Может и не лезли бы тогда делиться мудростью?
По существу. Руками ничего делать не надо. Никогда. Надо писать скрипты и запускать их. Вот хотите с нуля сконфигурировать машину - пишете скрипт, кладёте в гит. Запускаете его. Получаете сконфигурированную машину. Хотите задеплоить версию сайта из гита - пишете скрипт, кладёте в гит. Запускаете его. Получаете новую задеплоенную версию. Это позволяет добиться прозрачности и воспроизводимости. Под скриптами понимается что угодно от баша на коленке до всяких там терраформов.
Делать моки на чужой код - плохая идея. Вы не контролируете как тот код работает, поэтому делать высказывания вида "когда - тогда" - это как в таких розовых очках ходить, и убеждать всех, что всё хорошо.
Как правильно предложили выше, надо писать инт тесты. Юнит тесты - это если у вас там есть какая-то логика, которую в изоляции от внешних зависимостей можно протестировать.
Я имел в виду более прямую связь между GraphQL-фасадом и источником данных. Например программист определяет источник данных на уровне "select * from BankAccounts", а SPQR берёт на себя управление частями "where", "order by" и "skip/limit".
Вот у вас написано:
Что именно SPQR делает для того, чтобы "клиент смог выбрать именно то, что ему нужно"?
Ненене, погодите, а паджинация, фильтрация, сортировка - это все руками надо делать чтоли?
Всё то же самое делается ещё проще через написание своего AttributeConverter, в котором точно так же можно какой угодно кастомизированный ObjectMapper использовать.
Жопа с ушами :-)
В каждом топике про фейл большой компании одни и те же комментарии: попытка представить большую компанию как одного недостойного человека. Не надоело?