Извините, сжимать данные для ускорения - первый раз встречаюсь с такой идеей со времен модемов на 2400 бод. Реально где-то такое сейчас применяется?
Например, на этой странице. Content-Encoding: gzip.
Если диск - реально узкое место (а это чертовски вероятно), то сжатие однообразных строк (то есть в несколько раз), несомненно, ускорит процесс.
Причем я сильно подозреваю, что в Java это сжатие обойдется программисту в одну-две строчки (создание сжимающей обертки вокруг потока вывода).
Евгений, да нет, все у него в порядке. На самом стуле опрокинуться, действительно, трудно. А вот если, откинувшись на спинку, оттолкнуться от стола... ну, или на шкаф залезть ;))
Евгений, если развернуть на 180 градусов - ручка газлифта (она же затычка качалки) окажется с противоположной стороны. А она должна быть под задницей, иначе регулировать высоту не получится.
Вот про закручивание упругости - это я, действительно, забыл. Подкрутил, стало приятнее. Спасибо за напоминание.
Я примерно на таком сижу. Не очень советую.
Ручки нельзя снять, если захотелось - на них держится спинка.
Пробки, закрывающие винты в ручках, постоянно вываливаются, так как ручка деформируется под тяжестью откинувшегося седока.
Механизм качания был бы прикольным, если бы его фиксация не вываливалась сама, а откинувшись на стуле, седок не рисковал перекувыркнуться - центр тяжести в крайней точке выходит за пятиугольник, образованный роликами. По факту, через раз, когда откидываешься на спинку, фиксация выскальзывает и приходится быстро вернуться в сидячее положение. Только дергаешься вместо того, чтобы расслабиться.
Сиденье длинное, с моими короткими ногами я лично не могу сесть так, чтобы спина прилегала к спинке до самого копчика и при этом не пережимались сосуды под коленями. Вешаю пластмассовую хрень из фикс-прайса для подпорки...
Все это, конечно, мелочи - и я таки продолжаю на нем сидеть. Но как вариант нового - не советую.
Поставить Вагрант вместо ОпенСервера. Заодно избежать следующего вопроса: "помогите кто-нибудь, у меня в виндах все работало, а на сервере посыпалось, уже мылят веревку".
Максим Федоров, вы витаете в теоретических облаках. На практике никакой рынок не диктует спроса на хорошие и правильные решения, быдлокод и велосипеды из говна и палок по-прежнему в большинстве.
Да, специалисты востребованы. Но обычный работодатель не может уверенно оценить скиллы программирования, как вы не задрючивайтесь на абстрактных олимпиадных задачах. А вот оценить готовое портфолио из написанных для людей программ куда легче. Тем более, что, внезапно, работая программистом, нужно решать именно реальные задачи. А олимпиадные хаки, позволяющие в частном случае ускорить вычисления, оказываются заложенной под проект бомбой, срабатывающей при обновлении требований.
Максим Федоров, затем, что заработки, внезапно, зависят от работодателей НАПРЯМУЮ.
Олимпиадный уровень - это не только хорошие, но и плохие навыки.
При этом опыт хаков вместо опыта архитектуры в современном мире - два минуса сразу.
1. Работодателям нужны люди с опытом работы, умеющие сделать готовую вещь самостоятельно.
2. Никому на хрен не нужны олимпиадники, часами колупающиеся в некритичных алгоритмах и при этом не написавшие ни одной законченной и сколько-нибудь полезной программы.
Ничего не понимаю в Шарпе, но у нас, крестовиков, создание соединения с БД в каждом запросе - прямой путь к гибели под канделябрами. Особенно если у него потом почему-либо не отрабатывает деструктор.
m0nym, проблема ТС - асинхронность работы команд. Микросервис, как я написал выше, позволяет команде, его написавшей, оттестировать его и выкатить релиз, не дожидаясь команды, работающей над кодом, обращающимся к этому микросервису. Потому что старая его версия продолжает работать столько, сколько нужно для миграции.
Ну, и как вы перепишете на другой язык пару методов из одного класса, не трогая всего остального - я даже представлять не собираюсь...
m0nym, если вам не нужно развивать проект и никогда не понадобится переписать часть этих наборов на другом языке или, скажем, вынести на другой сервер - может быть, и ничем...
Anubis, смысл в оптимизации может быть, просто делается она на этими циферками, а правильным выбором типа.
Но если реально многомиллионных записей не будет, то вся возня с прописыванием таких подробностей будет экономией на спичках.
если не меняется API, дима, только тогда "без проблем". А это фантастика для развивающегося проекта
Микросервисы тем и хороши, что к ним обращаются известным образом. Нужно сменить API - делаем новую версию микросервиса, вешая ее на новый адрес, после чего потихоньку переводим использующие этот микросервис модули на новую версию, не трогая старую до самого окончания миграции. Тоже могут быть сложности, конечно, но по сравнению с монолитом...
Например, на этой странице. Content-Encoding: gzip.
Если диск - реально узкое место (а это чертовски вероятно), то сжатие однообразных строк (то есть в несколько раз), несомненно, ускорит процесс.
Причем я сильно подозреваю, что в Java это сжатие обойдется программисту в одну-две строчки (создание сжимающей обертки вокруг потока вывода).