Вот я смотрю на свои пальцы и вижу - двигаться вверх-вниз для них не сильно более естественно чем наискосок. Каждый палец двигается по дуге, у каждого пальца радиус этой дуги разный, эти дуги еще и не параллельны друг другу. В плане эргономики ортолинейка ровно такой же фэйл как и обычная клава - даже если клавиши вертикально смещены под каждый палец. Опыт пользования ортолинейкой это подтверждает - она ничем особо не лучше.
Учился дестипальцевому на Microsoft Natural. Перепрыгнуть потом на обычную было совсем не сложно - я даже проблем конкретных сейчас не помню. Значительно больше проблем недавно вызвала ортолинейная клавиатура - было тяжело, особенно с нижним рядом. А подумав какое-то время я вообще стал сомневаться в том, что эта ортолинейность что-то дает.
Простите мне мое невежество, объясните пожалуйста, что такое "плотная и потная катка". Хотел поначалу проигнорировать как очепятку, но воображение не перестает рисовать странные вещи :)
Чтобы назвать функцию понятно и описательно необходимо как-то обобщить происходящее в ней чтобы у нас название было короче самого кода. Здесь абстракция, как правило, и появляется. Или не появляется, тогда название получается непонятным и неописательным.
Проблема с большим количеством мелких функций в том, что создавая отдельную функцию ты создаешь новую абстракцию, а создание абстракции не такая простая задача как многим кажется. В итоге, часто получается, что разбив "большую" - едва влезающую в экран функцию на десяток мелких мы можем многократно усложнить восприятие этого кода за счет неудачных абстракций.
Вообще, как по мне, основная мысль здесь вообще не про микросервисы а про следствие одного давно озвученного наблюдения о том, что структура кода очень часто согласуется с организационной структурой проекта. И это не следствие какого-то волшебного и контринтуитивного эффекта - при повторении в коде орг структуры (ну или наоборот, при структурировании организации вокруг кода) проще эффективно организовать работу. Никто не любит тратить время на всякие согласования между подразделениями и, в итоге, модули в коде имеют тенденцию максимально изолироваться, что ускоряет разработку и поставку фич. Само собой, иногда и перегибы случаются и мы получаем странных кентавров с невнятнымы АПИ, но тут ведь не только деление на модули определяется орг структурой, но и наоборот тоже и результат получается вполне сносным.
>Компилится хер знает сколько Меня вот, если честно, всегда это веселит. Компилятор, вообще, за нас делает кучу работы по проверке кода. Эту работу, при растаскивании монолита на микросервисы часто, в итоге, приходится делать каждый раз "руками" (в смысле головой), о чем, как правило, на этапе растаскивания никто не думает - волшебное слово "микросервис" оно ведь даже лучше чем "пожалуйста", все контракты после этого начинают соблюдаться автоматически :)
Плюсую, после мака у меня везде Ctrl и Alt поменяны местами. В приложениях где Ctrl шорткаты преобладают неизмеримо удобнее иметь Ctrl под большими пальцами.
Я так понимаю под "удобно" они понимают прозрачно для пользователя в отличие от других вариантов с шифрованием почты. Я пробовал, в клиенте чата всё выглядит просто как обычный чатик. А с точки зрения MITM, боюсь, без доверяемой третьей стороны проблема не решается.
На счет валидации - в целом, фича хорошая - статической типизацией нужно пользоваться. Только, ИМХО, реализовывать это нужно было бы немного по-другому. Но тут стреляет другая проблема мэйнстримовых ЯП, мало кто дает выполнить какой-то свой код на этапе "компиляции" чтобы проверить, что все поля запроса на месте и типы данных у них совместимы с кодом.
Не совсем так. Я имел ввиду то, как клиент работает с данными у себя в памяти. Клиенту приходится значительно больше внимания уделять тому как данные у него в памяти размещены, какие ему понадобятся вспомогательные стурктуры и т.д. А уж переключить алгоритм выборки в зависимости от условий запроса он никак не может - это всё перекладывается на разработчика, а это, чаще всего, слишком сложно для реализации в конкретном случае.
Именно с этой точки зрения SQL более высокоуровневый - он скрывает сильно больше деталей реализации и избавляет клиентов от большого кол-ва рутины.
На счет встроенной миграции - соглашусь. В мире БД с этим есть проблемы. На счет кэширования - скорее нет. Пусть лучше будет больше кэша в самой БД чем entity level кэш в ОРМ со всем прилагаемыми проблемами. Просто потому, что проблем с инвалидацией кэшэй в БД я не припоминаю, а вот в ОРМ - вполне себе.
Организацию данных в памяти приходится учитывать при реализации алгоритмов их обработки. То есть, мы на клиенте сразу решаем, что, например, идем по списку сотрудников, подтягиваем для каждого "расшифровку" статуса из рядом лежащей мапы и название отдела из еще одной (заранее сформированной) мапы. При этом может получится так, что в некоторых случаях (например, в случае фильрации по отделу) быстрее будет не перебирать всех сотрудников а иметь дополнительную мапу сотрудников по отделам и вытаскивать сотрудников сразу из нее - а мы уже прибили гвоздями конкретный алгоритм, завязанный на нашу структуру данных в памяти.
В случае с SQL, сервер сам решает как ему наиболее эффективно получить нужные данные по сотрудникам, обходить ему весь список или не стоит, и т.д. Понятно, что в случае с БД иногда приходится включать голову и создавать индексы, но при этом, как минимум, мы не рискуем ничего сломать в плане состава получаемых данных.
Вот я смотрю на свои пальцы и вижу - двигаться вверх-вниз для них не сильно более естественно чем наискосок.
Каждый палец двигается по дуге, у каждого пальца радиус этой дуги разный, эти дуги еще и не параллельны друг другу. В плане эргономики ортолинейка ровно такой же фэйл как и обычная клава - даже если клавиши вертикально смещены под каждый палец.
Опыт пользования ортолинейкой это подтверждает - она ничем особо не лучше.
При этом сплит - да, ощутимо лучше.
Чем же?
Учился дестипальцевому на Microsoft Natural. Перепрыгнуть потом на обычную было совсем не сложно - я даже проблем конкретных сейчас не помню.
Значительно больше проблем недавно вызвала ортолинейная клавиатура - было тяжело, особенно с нижним рядом. А подумав какое-то время я вообще стал сомневаться в том, что эта ортолинейность что-то дает.
Простите мне мое невежество, объясните пожалуйста, что такое "плотная и потная катка". Хотел поначалу проигнорировать как очепятку, но воображение не перестает рисовать странные вещи :)
Чтобы назвать функцию понятно и описательно необходимо как-то обобщить происходящее в ней чтобы у нас название было короче самого кода. Здесь абстракция, как правило, и появляется. Или не появляется, тогда название получается непонятным и неописательным.
Есть противоположный взгляд на труды Мартина. https://qntm.org/clean
Проблема с большим количеством мелких функций в том, что создавая отдельную функцию ты создаешь новую абстракцию, а создание абстракции не такая простая задача как многим кажется. В итоге, часто получается, что разбив "большую" - едва влезающую в экран функцию на десяток мелких мы можем многократно усложнить восприятие этого кода за счет неудачных абстракций.
Вообще, как по мне, основная мысль здесь вообще не про микросервисы а про следствие одного давно озвученного наблюдения о том, что структура кода очень часто согласуется с организационной структурой проекта. И это не следствие какого-то волшебного и контринтуитивного эффекта - при повторении в коде орг структуры (ну или наоборот, при структурировании организации вокруг кода) проще эффективно организовать работу. Никто не любит тратить время на всякие согласования между подразделениями и, в итоге, модули в коде имеют тенденцию максимально изолироваться, что ускоряет разработку и поставку фич. Само собой, иногда и перегибы случаются и мы получаем странных кентавров с невнятнымы АПИ, но тут ведь не только деление на модули определяется орг структурой, но и наоборот тоже и результат получается вполне сносным.
>Компилится хер знает сколько
Меня вот, если честно, всегда это веселит. Компилятор, вообще, за нас делает кучу работы по проверке кода. Эту работу, при растаскивании монолита на микросервисы часто, в итоге, приходится делать каждый раз "руками" (в смысле головой), о чем, как правило, на этапе растаскивания никто не думает - волшебное слово "микросервис" оно ведь даже лучше чем "пожалуйста", все контракты после этого начинают соблюдаться автоматически :)
Плюсую, после мака у меня везде Ctrl и Alt поменяны местами. В приложениях где Ctrl шорткаты преобладают неизмеримо удобнее иметь Ctrl под большими пальцами.
Вот чтобы не говорили про "обмылки" - s4 mini в кармане лежал вообще идеально, да и в руке тоже был удобен и экрана вполне хватало.
Блин, с4 мини - идеальный формфактор!!!! хочу такой с современным железом унутре!!!
Ностальгично. У меня такой был в начале 90ых. Подключал его к своему УКНЦ. Помню даже сам под него драйвер написал ради интереса.
Поддерживаю. ИМХО, идеален по форме и размеру.
А тарелки телескопов в кратеры помещаются по принципу "Снаряд дважды в одну воронку не попадает"?
простите, не удержался :)
Автор, а скажите, чем решение с редисом лучше чем просто докинуть эту память буферам постгреса?
Я так понимаю под "удобно" они понимают прозрачно для пользователя в отличие от других вариантов с шифрованием почты. Я пробовал, в клиенте чата всё выглядит просто как обычный чатик.
А с точки зрения MITM, боюсь, без доверяемой третьей стороны проблема не решается.
А чем обмен ключами по почте отличается от обмена ключами при установке того же TLS соединения?
На счет валидации - в целом, фича хорошая - статической типизацией нужно пользоваться. Только, ИМХО, реализовывать это нужно было бы немного по-другому. Но тут стреляет другая проблема мэйнстримовых ЯП, мало кто дает выполнить какой-то свой код на этапе "компиляции" чтобы проверить, что все поля запроса на месте и типы данных у них совместимы с кодом.
Не совсем так. Я имел ввиду то, как клиент работает с данными у себя в памяти. Клиенту приходится значительно больше внимания уделять тому как данные у него в памяти размещены, какие ему понадобятся вспомогательные стурктуры и т.д. А уж переключить алгоритм выборки в зависимости от условий запроса он никак не может - это всё перекладывается на разработчика, а это, чаще всего, слишком сложно для реализации в конкретном случае.
Именно с этой точки зрения SQL более высокоуровневый - он скрывает сильно больше деталей реализации и избавляет клиентов от большого кол-ва рутины.
На счет встроенной миграции - соглашусь. В мире БД с этим есть проблемы.
На счет кэширования - скорее нет. Пусть лучше будет больше кэша в самой БД чем entity level кэш в ОРМ со всем прилагаемыми проблемами. Просто потому, что проблем с инвалидацией кэшэй в БД я не припоминаю, а вот в ОРМ - вполне себе.
Организацию данных в памяти приходится учитывать при реализации алгоритмов их обработки. То есть, мы на клиенте сразу решаем, что, например, идем по списку сотрудников, подтягиваем для каждого "расшифровку" статуса из рядом лежащей мапы и название отдела из еще одной (заранее сформированной) мапы. При этом может получится так, что в некоторых случаях (например, в случае фильрации по отделу) быстрее будет не перебирать всех сотрудников а иметь дополнительную мапу сотрудников по отделам и вытаскивать сотрудников сразу из нее - а мы уже прибили гвоздями конкретный алгоритм, завязанный на нашу структуру данных в памяти.
В случае с SQL, сервер сам решает как ему наиболее эффективно получить нужные данные по сотрудникам, обходить ему весь список или не стоит, и т.д. Понятно, что в случае с БД иногда приходится включать голову и создавать индексы, но при этом, как минимум, мы не рискуем ничего сломать в плане состава получаемых данных.