Пользовался подобной системой в Москве. Основных минусов два:
1. Ограничение на срок записи. Нельзя записаться сильно заранее. Из-за этого начинаются проблемы записи к популярным врачам. В момент открытия записи (ночью) все разбирается за минуты. И получается, что надо напрягаться, а то вообще не попадешь.
2. Повторный прием. На него надо записываться в общем порядке. При таком раскладе пройти, например, диспансеризацию или подготовить карту ребенку для детского сада — нереальная задача. Приходилось идти без талона.
Но в целом это прогресс. Немного доработать — и будет все отлично.
Добрая половина приемов — это эдакий привет из 90-х. И главное — совершенно неверный подход к вопросу. Есть несколько простых правил:
1. Преждевременная оптимизация — зло! Сначала сделай, чтобы работало качественно и правильно, а потом оптимизируй.
2. Не оптимизируй без профайлера! Сначала собери статистику по скорости работы, а потом оптимизируй то, что действительно тормозит. Пункт 2 делается в цикле до того момента, как скорость работы станет достаточной.
3. Помни, что на дворе 21 век и компилятор / операционная система / железо умеют оптимизировать выполнение команд. Всякие там кеши жестких дисков, NCQ, оптимизаторы компиляторов и многое многое другое позволяют не делать лишней работы и оставить приложение в понятном виде.
4. Иногда надо добавить ресурсов на сервер. Например, если докинуть памяти, чтобы ее было с избытком, операционка начнет сама кешировать ввод-вывод.
Для справки, обычное .NET MVC приложение (RESTful api), работающее с БД при использовании указанных трех правил удалось оптимизировать на 2 порядлка. И при этом никакие foreach, if и прочая муть не трогалась вообще. Достаточно было прекомпилировать запросы, кешировать некоторые данные в Hashtable и отказаться от Newtonsoft JSON сериализатора в сторону стригбилдеров (что, кстати, дало проирост процентов 15, но было самым геморойным). Итого с двух ядер ноутбука приложение стало выдавать около 1000 запросов в секунду вместо 20-35 до оптимизации.
А мне одному кажется, что подобные штуки только мешают т.к. изменение света по бокам привлекает внимание, туда автоматически переходит взгляд, а там ничего нет. Т.е. как-бы пытаешься там что-то увидеть, а там — ничего. И приходится наоборот сосредотачивать взгляд на картинке и пытаться не уводить его в сторону на подсветку?
Объясните мне, зачем надо писать сервис прям там? Можно ведь схитрить и сделать все заранее?
Как подобные читы отслеживаются? Или это просто «на честность»?
Мне кажется, что качество контента в плейлистах, созданных именно пользователями значительно выше, нежели в радио. Поэтому усилия, потраченные на поиск хорошего плейлиста компенсируются тем, что его потом можно будет слушать не один раз.
Кстати, это очень распространенный косяк — во всех трех ДЦ где я обслуживался можно было так сделать. Иногда чуть сложнее, иногда чуть проще, но в целом несложно, если четко знать что ребутаешь.
1. Ограничение на срок записи. Нельзя записаться сильно заранее. Из-за этого начинаются проблемы записи к популярным врачам. В момент открытия записи (ночью) все разбирается за минуты. И получается, что надо напрягаться, а то вообще не попадешь.
2. Повторный прием. На него надо записываться в общем порядке. При таком раскладе пройти, например, диспансеризацию или подготовить карту ребенку для детского сада — нереальная задача. Приходилось идти без талона.
Но в целом это прогресс. Немного доработать — и будет все отлично.
1. Преждевременная оптимизация — зло! Сначала сделай, чтобы работало качественно и правильно, а потом оптимизируй.
2. Не оптимизируй без профайлера! Сначала собери статистику по скорости работы, а потом оптимизируй то, что действительно тормозит. Пункт 2 делается в цикле до того момента, как скорость работы станет достаточной.
3. Помни, что на дворе 21 век и компилятор / операционная система / железо умеют оптимизировать выполнение команд. Всякие там кеши жестких дисков, NCQ, оптимизаторы компиляторов и многое многое другое позволяют не делать лишней работы и оставить приложение в понятном виде.
4. Иногда надо добавить ресурсов на сервер. Например, если докинуть памяти, чтобы ее было с избытком, операционка начнет сама кешировать ввод-вывод.
Для справки, обычное .NET MVC приложение (RESTful api), работающее с БД при использовании указанных трех правил удалось оптимизировать на 2 порядлка. И при этом никакие foreach, if и прочая муть не трогалась вообще. Достаточно было прекомпилировать запросы, кешировать некоторые данные в Hashtable и отказаться от Newtonsoft JSON сериализатора в сторону стригбилдеров (что, кстати, дало проирост процентов 15, но было самым геморойным). Итого с двух ядер ноутбука приложение стало выдавать около 1000 запросов в секунду вместо 20-35 до оптимизации.
Как подобные читы отслеживаются? Или это просто «на честность»?