у моей подруги-журналиста появился подобный синдром. В результате правая рука стала практически нефункциональна, т.к. любое напряжение или поворот запястья приводил к серьёзным болям. Не то что печатать - супа поесть нормально не получалось. Несколько месяцев лечения у разных врачей плюс оборудование нормального рабочего места - и вроде как помогло.
Кстати, не так сложно гуглится российский производитель эргономичных клавиатур.
а подскажите, плиз, название производителя. "Не так сложно" для меня оказалось таки сложно =(
По основному выводу полностью согласен. В своё время собрал кастомную клавиатуру в деревянном корпусе - штука прикольная и приятная, но работу работать на ней грустно - то клавиша не печатает, то прошивка подвисла, то ещё какая беда. То слои поправишьь и переучиваешься вместо работы. Хотел попробовать такую-же, но заводского производства - цены как на чугунный мост, так и не собрался купить, благо от тунельного синдрома не страдаю.
дело даже не в системе, дело в софте. Настроил ты свой линукс энергоэффективно, а потом юзер поствил какой-нибудь софт, который не даёт телефону заснуть, да ещё вайфай ищет, да ещё в фоне что-то делает. И всё, батареечка закончилась. В iOS, насколько я вижу эта проблема как-то решается, за счет особенностей системы или за счет правил написания софта - не уверен, но результат есть.
Так-то EInk бывает цветной и достаточно быстрый. Но для энергосбережения EInk увы не панацея, потому что огромную часть батарейки съедает процессор. И чтобы этого небыло - нужно систему и строго все приложения сделать энергоэффективными. И тут два варианта - "вылизанный" и настроенный Андроид с ограниченным набором 100% проверенных приложений, либо iOS, в которой уже всё стараниями эппла заоптимизировано как надо. Ну тоесть чтобы не ограничивать пользователя - нужно взять материнку от Айфона, прикрутить к ней батарею двойной ёмкости и EInk экран. И если с батареей более-менее ясно, то с экраном вот вообще неочевидно - как это можно сделать с текущей политикой Эппла на использование оригинальных з.ч.
ну, у меня не банк и в моей задаче общую сумму считать не понадобится никогда. Всегда с данными работает только пользователь и только со своими данными. Добрые люди тут уже подсказали, что для таких случаев есть готовые паттерны, нормальные =)
давайте обсудим проблемы безопасности и поддерживаемости? =) Очень интересно, какие проблемы вы видите как специалист. Для этого наверное нужно рассказать не только о базе, но и о том, как она используется в проекте. У меня есть условный "фронт-энд", который формирует запросы от пользователей и отсылает их на "бэк-энд" (программа на сервере). Бэк проверяет поля запроса на соответствие, формирует SQL запрос и закидывает в БД, ответ отсылает обратно во фронт. Пользователь и программист фронта с базой не контактируют вообще. Для программиста бэка ID пользователя идет либо как одно из полей данных, либо как название таблички, вся остальная разница спрятана внутри БД. Какие могут возникнуть проблемы с поддерживаемостью или безопасностью, если у нас ID пользователя переедет из данных в название таблицы?
эм. Вижу прям недопонимание. Я считаю что объяснения в стиле "ты ничего не зниешь" и "так никто не делает" - это недостаточный аргумент. Ну да, я многого не знаю и действительно так никто не делает. Для меня объяснение - это когда указывают причину, почему это не будет работать. Если причину в литературе (и в каментах) найти не удалось - значит нужно проверить - будет работать или нет, потому что возможно вот с этим конкретным случаем люди просто не сталкивались, именно поэтому так никто не делает - им было не нужно. А мне было нужно и я проверил идею. Вот проверил и убедился что да, в большинстве случаев - так не работает, о чем написал. Потому что раньше про такой сценарий никто не писал; вдруг кому-то понадобится или будет интересно. Про "гениальность идеи", ну хз, у меня про это нигде не написано. Выводы у меня достаточно чёткие - чаще всего не работает, я этим пользоваться не буду.
А вы уверены, что всё так однозначно? Вот выдержка из документации к Postgres: "Сначала планировщик/оптимизатор вырабатывает планы для сканирования каждого отдельного отношения (таблицы), используемого в запросе." Выглядит так, как будто работа оптимизатора наоборот должна ускориться, потому что ему не нужно по индексу собирать данные пользователя, я ему сразу указываю таблицу, в которой лежат все нужные данные, причем лежат упорядоченно.
задача не подразумевала запросов типа "выбрать каких-то пользователей". Всегда каждый пользователь работает только со своими данными, и всё. Пользователи не взаимодействуют между собой вообще никак. Соответственно никаких костылей и никаких прав для пользователя не нужно - пользователь обращается к бэкенду, бэк на основе логина обращается к нужной табличке и возвращает пользователю ответ.
Сильно этот сценарий уникальный или нет - я не знаю, в той пачке книжек по БД, которую я прочел в поисках ответа такого сценария небыло. Я обычно ищу инструмент для решения определенной задачи, а не подгоняю задачи под известные инструменты. Моя задача вот такая. Минусы в карму это наверное печально, но я пост сделал не для кармы, а потому что в ходе решения своей задачи сделал что-то, чего в популярных книжках и статьях из интернета - небыло, поэтому поделился с сообществом. Просто потому что мне было интересно.
ну вот эта концепция ответа на вопрос "почему?" - "потому что." и привела меня к идее тестирования. Например "потому что появляются большие накладки на работу с файлами" - это понятно, а "потому что никто так не делает" - ну не особо понятно, может у людей просто сценарии использования не такие как у меня.
а подскажите плиз, где взяли такие обои с Эльзой?
а что, пастильду до сих пор можно купить?
у моей подруги-журналиста появился подобный синдром. В результате правая рука стала практически нефункциональна, т.к. любое напряжение или поворот запястья приводил к серьёзным болям. Не то что печатать - супа поесть нормально не получалось. Несколько месяцев лечения у разных врачей плюс оборудование нормального рабочего места - и вроде как помогло.
а подскажите, плиз, название производителя. "Не так сложно" для меня оказалось таки сложно =(
По основному выводу полностью согласен. В своё время собрал кастомную клавиатуру в деревянном корпусе - штука прикольная и приятная, но работу работать на ней грустно - то клавиша не печатает, то прошивка подвисла, то ещё какая беда. То слои поправишьь и переучиваешься вместо работы.
Хотел попробовать такую-же, но заводского производства - цены как на чугунный мост, так и не собрался купить, благо от тунельного синдрома не страдаю.
дело даже не в системе, дело в софте.
Настроил ты свой линукс энергоэффективно, а потом юзер поствил какой-нибудь софт, который не даёт телефону заснуть, да ещё вайфай ищет, да ещё в фоне что-то делает. И всё, батареечка закончилась.
В iOS, насколько я вижу эта проблема как-то решается, за счет особенностей системы или за счет правил написания софта - не уверен, но результат есть.
Так-то EInk бывает цветной и достаточно быстрый. Но для энергосбережения EInk увы не панацея, потому что огромную часть батарейки съедает процессор. И чтобы этого небыло - нужно систему и строго все приложения сделать энергоэффективными. И тут два варианта - "вылизанный" и настроенный Андроид с ограниченным набором 100% проверенных приложений, либо iOS, в которой уже всё стараниями эппла заоптимизировано как надо.
Ну тоесть чтобы не ограничивать пользователя - нужно взять материнку от Айфона, прикрутить к ней батарею двойной ёмкости и EInk экран. И если с батареей более-менее ясно, то с экраном вот вообще неочевидно - как это можно сделать с текущей политикой Эппла на использование оригинальных з.ч.
Еще раз огромное спасибо!
К сожалению плюсик в карму поставить не могу, поэтому только словами. Тем не менее, спасибо действительно ОГРОМНОЕ!
ну, у меня не банк и в моей задаче общую сумму считать не понадобится никогда. Всегда с данными работает только пользователь и только со своими данными. Добрые люди тут уже подсказали, что для таких случаев есть готовые паттерны, нормальные =)
блин, да.
Понял, спасибо!
спасибо!
вот я тупанул конечно, нужно было про паттерны почитать.
прога-бэкенд.
Когда приходит запрос от фронта на регистрацию нового пользователя.
давайте обсудим проблемы безопасности и поддерживаемости? =)
Очень интересно, какие проблемы вы видите как специалист.
Для этого наверное нужно рассказать не только о базе, но и о том, как она используется в проекте.
У меня есть условный "фронт-энд", который формирует запросы от пользователей и отсылает их на "бэк-энд" (программа на сервере). Бэк проверяет поля запроса на соответствие, формирует SQL запрос и закидывает в БД, ответ отсылает обратно во фронт. Пользователь и программист фронта с базой не контактируют вообще. Для программиста бэка ID пользователя идет либо как одно из полей данных, либо как название таблички, вся остальная разница спрятана внутри БД. Какие могут возникнуть проблемы с поддерживаемостью или безопасностью, если у нас ID пользователя переедет из данных в название таблицы?
ну блин, в ней, родимой. Вот есть прекрасный ответ, почему оно так не работает: https://habr.com/ru/articles/764224/#comment_26013286
божечки, спасибо!!!
Вот без всякого сарказма - спасибо огромное!!
не могли-бы посоветовать хорошую книжку, где про это прочитать можно?
эм. Вижу прям недопонимание.
Я считаю что объяснения в стиле "ты ничего не зниешь" и "так никто не делает" - это недостаточный аргумент. Ну да, я многого не знаю и действительно так никто не делает. Для меня объяснение - это когда указывают причину, почему это не будет работать. Если причину в литературе (и в каментах) найти не удалось - значит нужно проверить - будет работать или нет, потому что возможно вот с этим конкретным случаем люди просто не сталкивались, именно поэтому так никто не делает - им было не нужно. А мне было нужно и я проверил идею.
Вот проверил и убедился что да, в большинстве случаев - так не работает, о чем написал. Потому что раньше про такой сценарий никто не писал; вдруг кому-то понадобится или будет интересно.
Про "гениальность идеи", ну хз, у меня про это нигде не написано. Выводы у меня достаточно чёткие - чаще всего не работает, я этим пользоваться не буду.
А вы уверены, что всё так однозначно?
Вот выдержка из документации к Postgres: "Сначала планировщик/оптимизатор вырабатывает планы для сканирования каждого отдельного отношения (таблицы), используемого в запросе." Выглядит так, как будто работа оптимизатора наоборот должна ускориться, потому что ему не нужно по индексу собирать данные пользователя, я ему сразу указываю таблицу, в которой лежат все нужные данные, причем лежат упорядоченно.
задача не подразумевала запросов типа "выбрать каких-то пользователей". Всегда каждый пользователь работает только со своими данными, и всё. Пользователи не взаимодействуют между собой вообще никак.
Соответственно никаких костылей и никаких прав для пользователя не нужно - пользователь обращается к бэкенду, бэк на основе логина обращается к нужной табличке и возвращает пользователю ответ.
Сильно этот сценарий уникальный или нет - я не знаю, в той пачке книжек по БД, которую я прочел в поисках ответа такого сценария небыло. Я обычно ищу инструмент для решения определенной задачи, а не подгоняю задачи под известные инструменты. Моя задача вот такая.
Минусы в карму это наверное печально, но я пост сделал не для кармы, а потому что в ходе решения своей задачи сделал что-то, чего в популярных книжках и статьях из интернета - небыло, поэтому поделился с сообществом. Просто потому что мне было интересно.
проблема была в том, что на фразе "потому что." ответ и заканчивался
ну вот эта концепция ответа на вопрос "почему?" - "потому что." и привела меня к идее тестирования. Например "потому что появляются большие накладки на работу с файлами" - это понятно, а "потому что никто так не делает" - ну не особо понятно, может у людей просто сценарии использования не такие как у меня.