Вообще, как по мне, основная мысль здесь вообще не про микросервисы а про следствие одного давно озвученного наблюдения о том, что структура кода очень часто согласуется с организационной структурой проекта. И это не следствие какого-то волшебного и контринтуитивного эффекта - при повторении в коде орг структуры (ну или наоборот, при структурировании организации вокруг кода) проще эффективно организовать работу. Никто не любит тратить время на всякие согласования между подразделениями и, в итоге, модули в коде имеют тенденцию максимально изолироваться, что ускоряет разработку и поставку фич. Само собой, иногда и перегибы случаются и мы получаем странных кентавров с невнятнымы АПИ, но тут ведь не только деление на модули определяется орг структурой, но и наоборот тоже и результат получается вполне сносным.
>Компилится хер знает сколько Меня вот, если честно, всегда это веселит. Компилятор, вообще, за нас делает кучу работы по проверке кода. Эту работу, при растаскивании монолита на микросервисы часто, в итоге, приходится делать каждый раз "руками" (в смысле головой), о чем, как правило, на этапе растаскивания никто не думает - волшебное слово "микросервис" оно ведь даже лучше чем "пожалуйста", все контракты после этого начинают соблюдаться автоматически :)
Плюсую, после мака у меня везде Ctrl и Alt поменяны местами. В приложениях где Ctrl шорткаты преобладают неизмеримо удобнее иметь Ctrl под большими пальцами.
Я так понимаю под "удобно" они понимают прозрачно для пользователя в отличие от других вариантов с шифрованием почты. Я пробовал, в клиенте чата всё выглядит просто как обычный чатик. А с точки зрения MITM, боюсь, без доверяемой третьей стороны проблема не решается.
На счет валидации - в целом, фича хорошая - статической типизацией нужно пользоваться. Только, ИМХО, реализовывать это нужно было бы немного по-другому. Но тут стреляет другая проблема мэйнстримовых ЯП, мало кто дает выполнить какой-то свой код на этапе "компиляции" чтобы проверить, что все поля запроса на месте и типы данных у них совместимы с кодом.
Не совсем так. Я имел ввиду то, как клиент работает с данными у себя в памяти. Клиенту приходится значительно больше внимания уделять тому как данные у него в памяти размещены, какие ему понадобятся вспомогательные стурктуры и т.д. А уж переключить алгоритм выборки в зависимости от условий запроса он никак не может - это всё перекладывается на разработчика, а это, чаще всего, слишком сложно для реализации в конкретном случае.
Именно с этой точки зрения SQL более высокоуровневый - он скрывает сильно больше деталей реализации и избавляет клиентов от большого кол-ва рутины.
На счет встроенной миграции - соглашусь. В мире БД с этим есть проблемы. На счет кэширования - скорее нет. Пусть лучше будет больше кэша в самой БД чем entity level кэш в ОРМ со всем прилагаемыми проблемами. Просто потому, что проблем с инвалидацией кэшэй в БД я не припоминаю, а вот в ОРМ - вполне себе.
Организацию данных в памяти приходится учитывать при реализации алгоритмов их обработки. То есть, мы на клиенте сразу решаем, что, например, идем по списку сотрудников, подтягиваем для каждого "расшифровку" статуса из рядом лежащей мапы и название отдела из еще одной (заранее сформированной) мапы. При этом может получится так, что в некоторых случаях (например, в случае фильрации по отделу) быстрее будет не перебирать всех сотрудников а иметь дополнительную мапу сотрудников по отделам и вытаскивать сотрудников сразу из нее - а мы уже прибили гвоздями конкретный алгоритм, завязанный на нашу структуру данных в памяти.
В случае с SQL, сервер сам решает как ему наиболее эффективно получить нужные данные по сотрудникам, обходить ему весь список или не стоит, и т.д. Понятно, что в случае с БД иногда приходится включать голову и создавать индексы, но при этом, как минимум, мы не рискуем ничего сломать в плане состава получаемых данных.
Вот мне интересно, как думают люди которые пишут про "низкоуровневый SQL". В реальности SQL, как правило сильно выше уровнем чем тот код, который его использует. SQL реально абстрагирует клиентов от того как хранилище в конкретной БД реализовано. А вот клиентский код, как правило, "прибит гвоздями" к представлению данных в памяти процесса.
LINQ, пожалуй, первая попытка подтянуть средства современных языков до уровня SQL. Остальные же ОРМ предлагают нам вместо относительно универсального SQL, привязанное к конкретному языку кривое подмножество этого самого SQL. Ну и кучу разных веселых проблем в качестве бонуса :(
Вот мне тоже очень интересно. Я буквально позавчера удалял из яндекс музыки 1.5к неудачно загруженных треков - выяснилось что google takeout потерял теги у половины треков. И вот на фоне того, что мне пришлось удалять эти треки по одному (!!!) никак не получается воспринимать анимацию как какую-то полезную, или пусть, хотя бы, прикольную фичу :( Кстати, при загрузке около 100 треков тупо зависли и мне пришлось их "руками" догружать, тоже по одному фактически. На фоне таких недочетов грустно читать уже вторую статью о том как разработчики занимаются второстепенными с точки зрения пользователя вещами.
Ну там, так или иначе, в какой-то момент, всплывает необходимость скорректироваться на 365ый день (и на високосный тоже).
Мне кажется разумным решение данной проблемы введением "несистемного" дня, который ни к неделе, ни к месяцу не относится. Только пока не могу сообразить какие проблемы могут вызвать эти самые несистемные дни, и не будут ли это проблемы хуже тех от которых хотелось бы избавится (разные размеры месяцев и кварталов, необходимость каждый год корректировать производственное расписание и т.д.)
Вообще, как по мне, основная мысль здесь вообще не про микросервисы а про следствие одного давно озвученного наблюдения о том, что структура кода очень часто согласуется с организационной структурой проекта. И это не следствие какого-то волшебного и контринтуитивного эффекта - при повторении в коде орг структуры (ну или наоборот, при структурировании организации вокруг кода) проще эффективно организовать работу. Никто не любит тратить время на всякие согласования между подразделениями и, в итоге, модули в коде имеют тенденцию максимально изолироваться, что ускоряет разработку и поставку фич. Само собой, иногда и перегибы случаются и мы получаем странных кентавров с невнятнымы АПИ, но тут ведь не только деление на модули определяется орг структурой, но и наоборот тоже и результат получается вполне сносным.
>Компилится хер знает сколько
Меня вот, если честно, всегда это веселит. Компилятор, вообще, за нас делает кучу работы по проверке кода. Эту работу, при растаскивании монолита на микросервисы часто, в итоге, приходится делать каждый раз "руками" (в смысле головой), о чем, как правило, на этапе растаскивания никто не думает - волшебное слово "микросервис" оно ведь даже лучше чем "пожалуйста", все контракты после этого начинают соблюдаться автоматически :)
Плюсую, после мака у меня везде Ctrl и Alt поменяны местами. В приложениях где Ctrl шорткаты преобладают неизмеримо удобнее иметь Ctrl под большими пальцами.
Вот чтобы не говорили про "обмылки" - s4 mini в кармане лежал вообще идеально, да и в руке тоже был удобен и экрана вполне хватало.
Блин, с4 мини - идеальный формфактор!!!! хочу такой с современным железом унутре!!!
Ностальгично. У меня такой был в начале 90ых. Подключал его к своему УКНЦ. Помню даже сам под него драйвер написал ради интереса.
Поддерживаю. ИМХО, идеален по форме и размеру.
А тарелки телескопов в кратеры помещаются по принципу "Снаряд дважды в одну воронку не попадает"?
простите, не удержался :)
Автор, а скажите, чем решение с редисом лучше чем просто докинуть эту память буферам постгреса?
Я так понимаю под "удобно" они понимают прозрачно для пользователя в отличие от других вариантов с шифрованием почты. Я пробовал, в клиенте чата всё выглядит просто как обычный чатик.
А с точки зрения MITM, боюсь, без доверяемой третьей стороны проблема не решается.
А чем обмен ключами по почте отличается от обмена ключами при установке того же TLS соединения?
На счет валидации - в целом, фича хорошая - статической типизацией нужно пользоваться. Только, ИМХО, реализовывать это нужно было бы немного по-другому. Но тут стреляет другая проблема мэйнстримовых ЯП, мало кто дает выполнить какой-то свой код на этапе "компиляции" чтобы проверить, что все поля запроса на месте и типы данных у них совместимы с кодом.
Не совсем так. Я имел ввиду то, как клиент работает с данными у себя в памяти. Клиенту приходится значительно больше внимания уделять тому как данные у него в памяти размещены, какие ему понадобятся вспомогательные стурктуры и т.д. А уж переключить алгоритм выборки в зависимости от условий запроса он никак не может - это всё перекладывается на разработчика, а это, чаще всего, слишком сложно для реализации в конкретном случае.
Именно с этой точки зрения SQL более высокоуровневый - он скрывает сильно больше деталей реализации и избавляет клиентов от большого кол-ва рутины.
На счет встроенной миграции - соглашусь. В мире БД с этим есть проблемы.
На счет кэширования - скорее нет. Пусть лучше будет больше кэша в самой БД чем entity level кэш в ОРМ со всем прилагаемыми проблемами. Просто потому, что проблем с инвалидацией кэшэй в БД я не припоминаю, а вот в ОРМ - вполне себе.
Организацию данных в памяти приходится учитывать при реализации алгоритмов их обработки. То есть, мы на клиенте сразу решаем, что, например, идем по списку сотрудников, подтягиваем для каждого "расшифровку" статуса из рядом лежащей мапы и название отдела из еще одной (заранее сформированной) мапы. При этом может получится так, что в некоторых случаях (например, в случае фильрации по отделу) быстрее будет не перебирать всех сотрудников а иметь дополнительную мапу сотрудников по отделам и вытаскивать сотрудников сразу из нее - а мы уже прибили гвоздями конкретный алгоритм, завязанный на нашу структуру данных в памяти.
В случае с SQL, сервер сам решает как ему наиболее эффективно получить нужные данные по сотрудникам, обходить ему весь список или не стоит, и т.д. Понятно, что в случае с БД иногда приходится включать голову и создавать индексы, но при этом, как минимум, мы не рискуем ничего сломать в плане состава получаемых данных.
Вот мне интересно, как думают люди которые пишут про "низкоуровневый SQL".
В реальности SQL, как правило сильно выше уровнем чем тот код, который его использует. SQL реально абстрагирует клиентов от того как хранилище в конкретной БД реализовано. А вот клиентский код, как правило, "прибит гвоздями" к представлению данных в памяти процесса.
LINQ, пожалуй, первая попытка подтянуть средства современных языков до уровня SQL. Остальные же ОРМ предлагают нам вместо относительно универсального SQL, привязанное к конкретному языку кривое подмножество этого самого SQL. Ну и кучу разных веселых проблем в качестве бонуса :(
Да, ситуация знакомая :)
Только вот запрос на фичу удаления группой на их сайте хотелок висит уже 2 года без движения.
Вот мне тоже очень интересно. Я буквально позавчера удалял из яндекс музыки 1.5к неудачно загруженных треков - выяснилось что google takeout потерял теги у половины треков. И вот на фоне того, что мне пришлось удалять эти треки по одному (!!!) никак не получается воспринимать анимацию как какую-то полезную, или пусть, хотя бы, прикольную фичу :(
Кстати, при загрузке около 100 треков тупо зависли и мне пришлось их "руками" догружать, тоже по одному фактически.
На фоне таких недочетов грустно читать уже вторую статью о том как разработчики занимаются второстепенными с точки зрения пользователя вещами.
Ну там, так или иначе, в какой-то момент, всплывает необходимость скорректироваться на 365ый день (и на високосный тоже).
Мне кажется разумным решение данной проблемы введением "несистемного" дня, который ни к неделе, ни к месяцу не относится. Только пока не могу сообразить какие проблемы могут вызвать эти самые несистемные дни, и не будут ли это проблемы хуже тех от которых хотелось бы избавится (разные размеры месяцев и кварталов, необходимость каждый год корректировать производственное расписание и т.д.)
В данном контексте я, скорее, к ней равнодушен. А в практическом плане - месяца все равно не совпадают с лунными циклами.
Вот мне тоже кажется, что месяц конструкция лишняя - много проблем возникает от попыток его в том или ином виде сохранить. Я бы оставил только недели.