можно просто не пользоваться мышкой. Почти всё кроме рисования и веба можно вполне удобно и быстро делать с клавиатуры.
Не уверен что рисование мышкой удобнее чем рисование с граф планшетом или на худой конец тачскрина. А на вебе у нас почти каждое второе приложение (привет electron). Даже в ide притащили, ну или оно с того началось… В таком случае можно ли сказать что практически везде нужна мышка ? Как много людей пользуются только клавой ?
Если все привыкнут пользоваться стандартной клавиатурой
Наверное мы проснемся в чудном дивном мире где каждый гражданин пользуется стандартной клавиатурой, ездит на стандартной машине, и работает стандартную работу… Ну получается кому то лень привыкать, вот играются с формфакторами. Ничего зазорного в этом не вижу.
Но почему-то нет ни одной статьи, где машинистка жалуется на раскладку клавиатуры
Не уверен что сейчас осталось много машинисток и они активно пишут на Хабр, хотя черт его знает кто по ту сторону экрана ;)
Хотя для неё, в отличие от нас, это основной рабочий инструмент.
Ура, дожили до визуального программирования Согласен, у нас сначала идет голова на плечах, и только потом клавиатура. Ну а если попробовать серьезно на это ответить. То можно найти достаточно кол-во тредов где люди жалуются на qwerty, делятся впечатлением от других раскладок, даже опенсорсят кастомные клавы, которые потом не плохо тиражируются.
Переучиваться не придётся никогда
Да и в случае с сплитами тоже. Сел, пописал, адаптировался, руки стали уставать меньше. На стандартную qwerty обратно переучиваться не надо, клава оно как велосипед, один раз научился писать, и все. Переключение между разными клавами не вызывает проблем. Это как с переходом от Mac к linux, пару раз meta нажмешь вместо ctrl и все или “>” вместо “ё” . Почему то каждый раз снова учиться не приходиться. Но я не знаю детали вашего кейса, может быть есть нюанс.
вы не сможете работать на чужом компе удалённо
Думаю что такая фича нужна не всем, собственно как и кастомные клавы.
Вот этого никогда не мог понять. Почему нельзя закрывать ненужные табы?
Уверен что можно :) но чаще вижу ситуацию когда куча вкладок все они “очень нужны, пока не знаю за чем”. Просто у людей другой паттерн использования браузера, так бывает )
привыкнете к странному, будет трудно пользоваться стандартным
Думаю что есть какой то пласт людей с кем это правило работает. Но в полной его универсальности сомневаюсь. Много общаюсь с любителями сплинов, еще не встречал тех кто жаловался что не может набирать текст на ноутбучной клаве. Но это наверное они какие то неправильные раз могут так легко переключить контекст.
всегда можно приделать к bash через PS1
Вот так, с помощью нехитрых приспособлений буханку белого (или черного) хлеба можно превратить в троллейбус… Но зачем ?
Спасибо за оценку. Код в статье это просто демо, ни в коем случае не продакшен. Протекающие абстракции в демо-коде допустимы, дабы не размывать суть примера чистым кодом. Понятное дело клиент который дергает GRPC метод не получает в случае ошибки sql`ный error. В проде если мы не получили данные с шарда на пакетный запрос, в зависимости от бизнес требований мы можем вернуть ответом
Обозначить что не смогли получить данные по ID
Вообще не обозначать никак ошибку при получении данных, прикинутся что такого ID не существует и вернуть пустое поле
Обозначить что при попытке получения данных по ID мы получили ошибку
По поводу ретраев и ограничений, у нас собственный фреймворк scratch (можете найти доклады с конференций о нем, даже когда то Авито вдохновились и сделали свой scratch). Там встроенная поддержка ретраев, рейтлимитов и CircuitBreaker`ов. На стороне приложения надо просто настроить, далее интерфейсный слой сделает все за вас. То же самое с точки зрения Storage, в нашей платформенной библиотеке для работы с sql базами есть встроенный рейтлимимтер, который на уровне sql дравйвера не дает приложению по ошибке заDDoSить базу. Тут с точки зрения архитектуры я бы придерживался позиции что сервисный слой не должен думать о том что он может положить базу, пусть об этом забоится sql драйвер, в крайнем случае верхнеуровневая имплементация интерфейса storage / repository.
Конкретно в сервисах нашей команды мы эту задачу не решали. Нам повезло. У нас достаточно держать данные консистентными в рамках одного шарда. Вопросом бекапов самих баз у нас занимается выделенная команда.
Консистентный бекап это проблема которой стоит избегать, стараясь создавать такую схему данных, которая позволит определять шард как нечто автономное. Например нам надо шардировать БД с карточками товара, которая содержит инфу о товаре, цену, комментарии. В случае если мы шардируем карточку по слоям - инфу о товаре на один шард, цену на второй а коменты на третий. То встает вопрос консистетного бекапа. А если мы шардируем по принципу id-товара%кол-во шардов = номер шарда на котором лежит и инфа о товаре и цена и коменты, то достаточно решить проблему надежного бекапирования каждого шарда отдельно.
Если есть возможность без боли перейти на шардируемую БД, то конечно лучше сделать так. Но расширение стека это довольно больная тема, и чем больше компания, тем больнее. Надо будет ответить на ряд вопросов: а какие гарантии у БД, а как долго будет происходить миграция, а кто будет это администрировать, а как быстро и за какую сумму можно найти экспертизу на рынке труда (разработчики, админы) ? Если есть возможность в приемлемые сроки для бизнеса решить эти вопросы, то конечно стоит рассмотреть варианты с шардируемой БД.
Очень хорошо про логи подмечено, логи как правило это небольшие записи но они делаются очень часто, читаются редко. Логи к тому же редко хранятся в реляционных базках, о которых и шла речь в статье. А вот когда у тебя много данных пишется и читается, причем с произвольным доступом, и ко всему к этому есть еще не функциональное требование "надо что бы отвечало менее 30мс". То шардинг тут не не сказать что избыточен, это классический путь размазывания нагрузки по железкам. Синхронные реплики помогут растащить читающую нагрузку, безусловно, но в записи нам это все еще ничего не прибавит. И тут как всегда мы начинаем искать компромисс. И шардирование порой проще чем внедрение условного KV, особенно в больших компаниях. С тезисом что в подавляющем большинстве случаев шардинг избыточен можно согласится, потому что наверное большая часть приложений в мире не имеет больших нагрузок и жестких требований к отзывчивости.
Если БД поддерживает нативное шардирование, то конечно лучше использовать его. В случае с postgresql к сожалению нативного шардирования нет.
На воторой вопрос - в решардинге самая главная боль это перераспределение данных, особенно когда их много и за ними часто ходят. Оставлять эту задачу на автоматику откровенно говоря страшно. А если речь идет о том что на этапе проектирования надо закладывать пространство для маневра шардирования, это так, вопрос в том что считается "достаточным" пространством для маневра. Просто мапинг бакета на шард или сценарий переноса данных который запускается по кнопке, а будет ли он актуален на момент нового решардинга ? Например может изменится инфраструктура или требования к приложению, из за чего предыдущий подход к решардингу будет не оптимальный. Коротко говоря, все хотели бы иметь какой то универсальный набор правил для построения систем с быстрым решардингом, но у всех слишком разные приложения и требования к ним.
>> Хороший уровень навыков, связанных с хранилищами данных
Я бы заменил на "высокий уровень экспертизы в инфраструктурных технологях"
Хранилища данных это малая часть тех инфровых вещей, которые должны попадать в кругозор техлида. Ведь именно он в большинстве случаев решает какой стек техонолоий использовать для решения бизнес-задач.
Тот же стек ci/cd включая коробочные решения для кубов, например. Базы данных, реверс-прокси. Опять же тулкит разработки тоже скорей всего будет выбирать тех-лид, включая библиотеки, транспорт, протоколы etc...
Можно уточнить вопрос, что имеется под "размером хранилища", оверхед на хранение данных + сами данные ? Если так, то думаю вопрос скорее стоит в выборе реализации хранилища (софт + железо). В таком случае Ceph будет хорошим решением, он может. Держать большое количество данных в себе с минимально деградацией (боюсь давать точные цифры). В том или ином случае, если стоит вопрос хранения файлов в сервисе/приложении то объектные хранилища это наверное в первую очередь инструмент создания границы (в ее роли выступит API выбранного вами решения) между файлами и бизнес логикой.
Такое отделение позволит закладывать масштабируемость. Например у нас будет несколько инстансов приложения, которое ходит через сеть в наш сторадж за данными, причем они могут находится на разных железках.
Не уверен что рисование мышкой удобнее чем рисование с граф планшетом или на худой конец тачскрина.
А на вебе у нас почти каждое второе приложение (привет electron). Даже в ide притащили, ну или оно с того началось…
В таком случае можно ли сказать что практически везде нужна мышка ?
Как много людей пользуются только клавой ?
Наверное мы проснемся в чудном дивном мире где каждый гражданин пользуется стандартной клавиатурой, ездит на стандартной машине, и работает стандартную работу…
Ну получается кому то лень привыкать, вот играются с формфакторами. Ничего зазорного в этом не вижу.
Не уверен что сейчас осталось много машинисток и они активно пишут на Хабр, хотя черт его знает кто по ту сторону экрана ;)
Ура, дожили до визуального программированияСогласен, у нас сначала идет голова на плечах, и только потом клавиатура. Ну а если попробовать серьезно на это ответить. То можно найти достаточно кол-во тредов где люди жалуются на qwerty, делятся впечатлением от других раскладок, даже опенсорсят кастомные клавы, которые потом не плохо тиражируются.
Да и в случае с сплитами тоже. Сел, пописал, адаптировался, руки стали уставать меньше. На стандартную qwerty обратно переучиваться не надо, клава оно как велосипед, один раз научился писать, и все. Переключение между разными клавами не вызывает проблем. Это как с переходом от Mac к linux, пару раз meta нажмешь вместо ctrl и все или “>” вместо “ё” . Почему то каждый раз снова учиться не приходиться. Но я не знаю детали вашего кейса, может быть есть нюанс.
Думаю что такая фича нужна не всем, собственно как и кастомные клавы.
Уверен что можно :) но чаще вижу ситуацию когда куча вкладок все они “очень нужны, пока не знаю за чем”.
Просто у людей другой паттерн использования браузера, так бывает )
Думаю что есть какой то пласт людей с кем это правило работает. Но в полной его универсальности сомневаюсь.
Много общаюсь с любителями сплинов, еще не встречал тех кто жаловался что не может набирать текст на ноутбучной клаве. Но это наверное они какие то неправильные раз могут так легко переключить контекст.
Вот так, с помощью нехитрых приспособлений буханку белого (или черного) хлеба можно превратить в троллейбус… Но зачем ?
Спасибо за оценку.
Код в статье это просто демо, ни в коем случае не продакшен. Протекающие абстракции в демо-коде допустимы, дабы не размывать суть примера чистым кодом.
Понятное дело клиент который дергает GRPC метод не получает в случае ошибки sql`ный error. В проде если мы не получили данные с шарда на пакетный запрос, в зависимости от бизнес требований мы можем вернуть ответом
Обозначить что не смогли получить данные по ID
Вообще не обозначать никак ошибку при получении данных, прикинутся что такого ID не существует и вернуть пустое поле
Обозначить что при попытке получения данных по ID мы получили ошибку
По поводу ретраев и ограничений, у нас собственный фреймворк scratch (можете найти доклады с конференций о нем, даже когда то Авито вдохновились и сделали свой scratch). Там встроенная поддержка ретраев, рейтлимитов и CircuitBreaker`ов. На стороне приложения надо просто настроить, далее интерфейсный слой сделает все за вас.
То же самое с точки зрения Storage, в нашей платформенной библиотеке для работы с sql базами есть встроенный рейтлимимтер, который на уровне sql дравйвера не дает приложению по ошибке заDDoSить базу.
Тут с точки зрения архитектуры я бы придерживался позиции что сервисный слой не должен думать о том что он может положить базу, пусть об этом забоится sql драйвер, в крайнем случае верхнеуровневая имплементация интерфейса storage / repository.
Конкретно в сервисах нашей команды мы эту задачу не решали. Нам повезло. У нас достаточно держать данные консистентными в рамках одного шарда. Вопросом бекапов самих баз у нас занимается выделенная команда. Консистентный бекап это проблема которой стоит избегать, стараясь создавать такую схему данных, которая позволит определять шард как нечто автономное. Например нам надо шардировать БД с карточками товара, которая содержит инфу о товаре, цену, комментарии.
В случае если мы шардируем карточку по слоям - инфу о товаре на один шард, цену на второй а коменты на третий. То встает вопрос консистетного бекапа. А если мы шардируем по принципу id-товара%кол-во шардов = номер шарда на котором лежит и инфа о товаре и цена и коменты, то достаточно решить проблему надежного бекапирования каждого шарда отдельно.
Если есть возможность без боли перейти на шардируемую БД, то конечно лучше сделать так. Но расширение стека это довольно больная тема, и чем больше компания, тем больнее. Надо будет ответить на ряд вопросов: а какие гарантии у БД, а как долго будет происходить миграция, а кто будет это администрировать, а как быстро и за какую сумму можно найти экспертизу на рынке труда (разработчики, админы) ?
Если есть возможность в приемлемые сроки для бизнеса решить эти вопросы, то конечно стоит рассмотреть варианты с шардируемой БД.
Очень хорошо про логи подмечено, логи как правило это небольшие записи но они делаются очень часто, читаются редко. Логи к тому же редко хранятся в реляционных базках, о которых и шла речь в статье.
А вот когда у тебя много данных пишется и читается, причем с произвольным доступом, и ко всему к этому есть еще не функциональное требование "надо что бы отвечало менее 30мс". То шардинг тут не не сказать что избыточен, это классический путь размазывания нагрузки по железкам. Синхронные реплики помогут растащить читающую нагрузку, безусловно, но в записи нам это все еще ничего не прибавит.
И тут как всегда мы начинаем искать компромисс. И шардирование порой проще чем внедрение условного KV, особенно в больших компаниях.
С тезисом что в подавляющем большинстве случаев шардинг избыточен можно согласится, потому что наверное большая часть приложений в мире не имеет больших нагрузок и жестких требований к отзывчивости.
Если БД поддерживает нативное шардирование, то конечно лучше использовать его. В случае с postgresql к сожалению нативного шардирования нет.
На воторой вопрос - в решардинге самая главная боль это перераспределение данных, особенно когда их много и за ними часто ходят. Оставлять эту задачу на автоматику откровенно говоря страшно. А если речь идет о том что на этапе проектирования надо закладывать пространство для маневра шардирования, это так, вопрос в том что считается "достаточным" пространством для маневра. Просто мапинг бакета на шард или сценарий переноса данных который запускается по кнопке, а будет ли он актуален на момент нового решардинга ? Например может изменится инфраструктура или требования к приложению, из за чего предыдущий подход к решардингу будет не оптимальный. Коротко говоря, все хотели бы иметь какой то универсальный набор правил для построения систем с быстрым решардингом, но у всех слишком разные приложения и требования к ним.
>> Хороший уровень навыков, связанных с хранилищами данных
Я бы заменил на "высокий уровень экспертизы в инфраструктурных технологях"
Хранилища данных это малая часть тех инфровых вещей, которые должны попадать в кругозор техлида. Ведь именно он в большинстве случаев решает какой стек техонолоий использовать для решения бизнес-задач.
Тот же стек ci/cd включая коробочные решения для кубов, например. Базы данных, реверс-прокси. Опять же тулкит разработки тоже скорей всего будет выбирать тех-лид, включая библиотеки, транспорт, протоколы etc...
Поддерживаю позицию что для более серьезных решений Ceph будет лучшим выбором
Можно уточнить вопрос, что имеется под "размером хранилища", оверхед на хранение данных + сами данные ? Если так, то думаю вопрос скорее стоит в выборе реализации хранилища (софт + железо). В таком случае Ceph будет хорошим решением, он может. Держать большое количество данных в себе с минимально деградацией (боюсь давать точные цифры). В том или ином случае, если стоит вопрос хранения файлов в сервисе/приложении то объектные хранилища это наверное в первую очередь инструмент создания границы (в ее роли выступит API выбранного вами решения) между файлами и бизнес логикой. Такое отделение позволит закладывать масштабируемость. Например у нас будет несколько инстансов приложения, которое ходит через сеть в наш сторадж за данными, причем они могут находится на разных железках.