Вопрос как удобнее во многом субъективен. Мне лично клавиатурный ввод нравится больше, т.к. сразу пропадают проблемы с распознаванием чужого почерка и повышается удобство редактирования(чтобы вписать пару слов не нужно стирать всю строку или впихивать галочками). А стрелочки и мышкой на ура рисуются.
Для тех, кто не любит клавиатуры, есть графические планшеты, по которым можно писать пером, гораздо удобнее чем маркером, т.к. писать ручкой привычно с детства, а маркер даёт избыточно толстую линию, да ещё и без возможности регулировать эту толщину.
Ещё есть обычные планшеты и touch-экраны, рисуйте по ним хоть пальцем, хоть стилусом. Кстати, онлайн-доски тоже на любой вкус есть, для любителей рукописного ввода может хватить чего-то типа AWW или WebWhiteboard. Конечно планшет или touch-экран для такого использованию будут необходимы, но это решаемо.
По большому счёту, для онлайн-обсуждений всё есть и со временем удобство будет только расти… На мой взгляд, реальные проблемы могут быть только из разряда фетишизма, ну типа вам хочется касаться доски, прёт от запаха маркера и его скрипа по доске и т.д.
Онлайн-доска — это тоже не проблема… Посмотрите RealtimeBoard и аналоги. Если уж по-честному, то они гораздо удобнее, чем обычные доски… площадь доски не заканчивается в самый неподходящий момент, никто не изрисует её случайно перманентным маркером, стикеры не отлетают, кол-во досок не ограничено и т.д.
А вот общение по туманный перспективам, которые превратятся в эксперимент, а потом пойдут в продакшн — идет через Скайпы/Слэки крайне тяжело.
С чего вдруг? Если только вы привыкли жестами по туманным перспективам общаться, попутно дымя собеседнику в лицо… А вербальная информация нисколько не страдает от скайпов/слэков.
Переписка же ещё более мощный драйвер роста, удалённо Вы можете пообщаться практически с любым человеком в мире, а не ограничены уровнем сотрудников своей фирмы.
Сидючи в одном кабинете или встречаясь несколько раз в день — вы сможете прийти с консилиуму на пару порядков быстрее.
Справедливости ради, прийти можно к консенсусу, а консилиум можно собрать. Причём в IT его можно собрать по скайпу или любому аналогу для конференц-связи. Поэтому соглашусь, что Вы выдумывали себе несуществующую проблему.
не должен один человек писать и на sql, и на java, и на js, и на html, и на css
Почему нет? В крупных проектах с богатым фронтом будет конечно разделение по специализациям, но веб-студии из 2-3 программистов, про которые Вы упомянули, занимаются обычными типовыми сайтами. Глупо от них ожидать найма отдельного человека, который будет адаптировать шаблоны с TemplateMonster к хотелкам заказчика, и ещё одного человека для прикручивания плагинов к jQuery.
Мне на них тупо пофиг, если они не пытаются ко мне лезть.
Ни фига себе, двойные стандарты… Сами то предпочитаете именно лезть — отрывать от работы на мгновенную обратную связь. По факту мгновенная обратная связь нужна от силы пару раз в год.
Хм, тут проблема не в отвлекающем человеке, а в Вас… Как Вы предупредили, что работаете? закрыли межкомнатную дверь? поставили рядом с собой табличку "Work in progress"? или хотя бы на словах предупредили, что заняты работой? А учитывая, что Вы обычно ходите в офис, необходимость предупреждения возрастает раз в 100, по сравнению с ситуацией, когда Вы постоянно работаете из дома. А посылать людей за то, что они не имеют мощных экстрасенсорных способностей, действительно невежливо.
Так формирование отчёта по уже выбранным данным не требует гигабайтов оперативки, если это не отчёт на несколько тысяч листов. SQL для того и существует, чтобы из БД только нужные для отчёта цифры достать. Или Вы имеете в виду, что можно косячно формировать отчёт, но вынести это в микросервис и уже будет не так заметно, что отчёт формируется чёрти как?
А я понял, Вы про роуты, которые для всех методов подходят. В таком случае в Rails будут просто игнориться все последующие дубликаты этого роута с указанием конкретного HTTP-метода. Хотя допускаю, что где-то роутинг может искать best match до победного конца, но имхо это странный вариант… first match будет всегда работать быстрее.
Я не понимаю, почему у Вас каждый запрос обязательно добавляет N мегабайт…
Возможно, у Вас какие-то очень специфичные задачи… У меня график занятого ОЗУ в течении дня обычно больше похож на горизонтальную линию, при том, что максимальная нагрузка в 20 с лишним раз больше минимальной.
Линейный рост потребляемого ОЗУ это норма, а часто идеал, которого не могут достигнуть.
Т.е. у Вас по графику потребления ОЗУ на сервере можно сразу видеть, где были пиковые нагрузки? Ни CPU, ни Network I/O, а именно ОЗУ?
Грубо, если запрос пользователя обрабатывается 100 мс, то 16000 одновременных пользователей означает 160000 запросов в секунду — в каждый момент времени обрабатывается 16 000 запросов.
Такое количество запросов (популярность на уровне Twitter) никто в здравом уме не будет одним инстансом обрабатывать, т.е. как-то мимо начального вопроса получилось. На всю ферму серверов и 256 Gb нормально будет, а вот 16 Gb на один инстанс (а инстансов и на одном сервере может быть много) всё равно дичь получается.
Естественно сопоставление роутов идёт с учётом метода. Это не значит, что из-за этого проверять придётся все. Но в память загрузятся все — это да… несколько десятков килобайт займут )))
Отчёты обычно формируются на основе сложных запросов к БД. Поэтому на порядок лучший профит получится, если формировать отчёт запросами к реплике БД, а не от того, что основная БД будет также загружена запросами из другого процесса.
Да, я думал про такой вариант, но отбросил его, т.к. делать это на уровне своего приложения нелогично, когда уже есть ffmpeg, imagemagick и т.д.
Вопрос же был не в общем кол-ве занятой памяти на сервере, а исключительно про занятую под монолитное приложение.
Под одновременными реквестами Вы имеете в виду в секунду или в минуту? Вообще, когда говорят про пользователей, обычно подразумевается, что в предыдущие N минут были какие-то запросы от 16 тыс. уников. Где N — время, исходя из которого границы визита определяются, для GA и Метрики — это 30 минут iirc. Напрямую rps из этого вывести сложно, не зная специфики приложения.
Кстати, роуты в Rails проверяются по порядку, так что если у Вас реально проблема с тысячами неиспользуемых роутов, то вынесите десяток реально используемых на самый верх routes.rb и остальные роуты будут отнимать ресурсы на проверку раз в году, или когда там до них дело дойдёт )
Вопрос как удобнее во многом субъективен. Мне лично клавиатурный ввод нравится больше, т.к. сразу пропадают проблемы с распознаванием чужого почерка и повышается удобство редактирования(чтобы вписать пару слов не нужно стирать всю строку или впихивать галочками). А стрелочки и мышкой на ура рисуются.
Для тех, кто не любит клавиатуры, есть графические планшеты, по которым можно писать пером, гораздо удобнее чем маркером, т.к. писать ручкой привычно с детства, а маркер даёт избыточно толстую линию, да ещё и без возможности регулировать эту толщину.
Ещё есть обычные планшеты и touch-экраны, рисуйте по ним хоть пальцем, хоть стилусом. Кстати, онлайн-доски тоже на любой вкус есть, для любителей рукописного ввода может хватить чего-то типа AWW или WebWhiteboard. Конечно планшет или touch-экран для такого использованию будут необходимы, но это решаемо.
По большому счёту, для онлайн-обсуждений всё есть и со временем удобство будет только расти… На мой взгляд, реальные проблемы могут быть только из разряда фетишизма, ну типа вам хочется касаться доски, прёт от запаха маркера и его скрипа по доске и т.д.
Онлайн-доска — это тоже не проблема… Посмотрите RealtimeBoard и аналоги. Если уж по-честному, то они гораздо удобнее, чем обычные доски… площадь доски не заканчивается в самый неподходящий момент, никто не изрисует её случайно перманентным маркером, стикеры не отлетают, кол-во досок не ограничено и т.д.
Речь шла об общении с коллегами, а не с клиентами.
С чего вдруг? Если только вы привыкли жестами по туманным перспективам общаться, попутно дымя собеседнику в лицо… А вербальная информация нисколько не страдает от скайпов/слэков.
Переписка же ещё более мощный драйвер роста, удалённо Вы можете пообщаться практически с любым человеком в мире, а не ограничены уровнем сотрудников своей фирмы.
Справедливости ради, прийти можно к консенсусу, а консилиум можно собрать. Причём в IT его можно собрать по скайпу или любому аналогу для конференц-связи. Поэтому соглашусь, что Вы выдумывали себе несуществующую проблему.
Почему нет? В крупных проектах с богатым фронтом будет конечно разделение по специализациям, но веб-студии из 2-3 программистов, про которые Вы упомянули, занимаются обычными типовыми сайтами. Глупо от них ожидать найма отдельного человека, который будет адаптировать шаблоны с TemplateMonster к хотелкам заказчика, и ещё одного человека для прикручивания плагинов к jQuery.
Ни фига себе, двойные стандарты… Сами то предпочитаете именно лезть — отрывать от работы на мгновенную обратную связь. По факту мгновенная обратная связь нужна от силы пару раз в год.
Хм, тут проблема не в отвлекающем человеке, а в Вас… Как Вы предупредили, что работаете? закрыли межкомнатную дверь? поставили рядом с собой табличку "Work in progress"? или хотя бы на словах предупредили, что заняты работой? А учитывая, что Вы обычно ходите в офис, необходимость предупреждения возрастает раз в 100, по сравнению с ситуацией, когда Вы постоянно работаете из дома. А посылать людей за то, что они не имеют мощных экстрасенсорных способностей, действительно невежливо.
Наоборот, это ближе к традиционному формату школьных записочек… важное — запомнится, а неважное — прочитал и забыл.
Так формирование отчёта по уже выбранным данным не требует гигабайтов оперативки, если это не отчёт на несколько тысяч листов. SQL для того и существует, чтобы из БД только нужные для отчёта цифры достать. Или Вы имеете в виду, что можно косячно формировать отчёт, но вынести это в микросервис и уже будет не так заметно, что отчёт формируется чёрти как?
А я понял, Вы про роуты, которые для всех методов подходят. В таком случае в Rails будут просто игнориться все последующие дубликаты этого роута с указанием конкретного HTTP-метода. Хотя допускаю, что где-то роутинг может искать best match до победного конца, но имхо это странный вариант… first match будет всегда работать быстрее.
Да, я имел в виду случай, когда кронтаб формируется приложением, для вызова самого себя с определенными параметрами в определенное время.
Я не понимаю, почему у Вас каждый запрос обязательно добавляет N мегабайт…
Возможно, у Вас какие-то очень специфичные задачи… У меня график занятого ОЗУ в течении дня обычно больше похож на горизонтальную линию, при том, что максимальная нагрузка в 20 с лишним раз больше минимальной.
Т.е. у Вас по графику потребления ОЗУ на сервере можно сразу видеть, где были пиковые нагрузки? Ни CPU, ни Network I/O, а именно ОЗУ?
Такое количество запросов (популярность на уровне Twitter) никто в здравом уме не будет одним инстансом обрабатывать, т.е. как-то мимо начального вопроса получилось. На всю ферму серверов и 256 Gb нормально будет, а вот 16 Gb на один инстанс (а инстансов и на одном сервере может быть много) всё равно дичь получается.
Естественно сопоставление роутов идёт с учётом метода. Это не значит, что из-за этого проверять придётся все. Но в память загрузятся все — это да… несколько десятков килобайт займут )))
Отчёты обычно формируются на основе сложных запросов к БД. Поэтому на порядок лучший профит получится, если формировать отчёт запросами к реплике БД, а не от того, что основная БД будет также загружена запросами из другого процесса.
Какая-то ложная дихотомия получается… Этак, если в проекте используется cron, то он уже микросервисным резко становится? xD
Да, я думал про такой вариант, но отбросил его, т.к. делать это на уровне своего приложения нелогично, когда уже есть ffmpeg, imagemagick и т.д.
Вопрос же был не в общем кол-ве занятой памяти на сервере, а исключительно про занятую под монолитное приложение.
Под одновременными реквестами Вы имеете в виду в секунду или в минуту? Вообще, когда говорят про пользователей, обычно подразумевается, что в предыдущие N минут были какие-то запросы от 16 тыс. уников. Где N — время, исходя из которого границы визита определяются, для GA и Метрики — это 30 минут iirc. Напрямую rps из этого вывести сложно, не зная специфики приложения.
Кстати, роуты в Rails проверяются по порядку, так что если у Вас реально проблема с тысячами неиспользуемых роутов, то вынесите десяток реально используемых на самый верх routes.rb и остальные роуты будут отнимать ресурсы на проверку раз в году, или когда там до них дело дойдёт )