Как стать автором
Обновить
19
0
Андрей Куприков @Andrey_Kuprikov

Пользователь

Отправить сообщение
Пользовался подобной системой в Москве. Основных минусов два:
1. Ограничение на срок записи. Нельзя записаться сильно заранее. Из-за этого начинаются проблемы записи к популярным врачам. В момент открытия записи (ночью) все разбирается за минуты. И получается, что надо напрягаться, а то вообще не попадешь.
2. Повторный прием. На него надо записываться в общем порядке. При таком раскладе пройти, например, диспансеризацию или подготовить карту ребенку для детского сада — нереальная задача. Приходилось идти без талона.

Но в целом это прогресс. Немного доработать — и будет все отлично.
Добрая половина приемов — это эдакий привет из 90-х. И главное — совершенно неверный подход к вопросу. Есть несколько простых правил:
1. Преждевременная оптимизация — зло! Сначала сделай, чтобы работало качественно и правильно, а потом оптимизируй.
2. Не оптимизируй без профайлера! Сначала собери статистику по скорости работы, а потом оптимизируй то, что действительно тормозит. Пункт 2 делается в цикле до того момента, как скорость работы станет достаточной.
3. Помни, что на дворе 21 век и компилятор / операционная система / железо умеют оптимизировать выполнение команд. Всякие там кеши жестких дисков, NCQ, оптимизаторы компиляторов и многое многое другое позволяют не делать лишней работы и оставить приложение в понятном виде.
4. Иногда надо добавить ресурсов на сервер. Например, если докинуть памяти, чтобы ее было с избытком, операционка начнет сама кешировать ввод-вывод.

Для справки, обычное .NET MVC приложение (RESTful api), работающее с БД при использовании указанных трех правил удалось оптимизировать на 2 порядлка. И при этом никакие foreach, if и прочая муть не трогалась вообще. Достаточно было прекомпилировать запросы, кешировать некоторые данные в Hashtable и отказаться от Newtonsoft JSON сериализатора в сторону стригбилдеров (что, кстати, дало проирост процентов 15, но было самым геморойным). Итого с двух ядер ноутбука приложение стало выдавать около 1000 запросов в секунду вместо 20-35 до оптимизации.
А мне одному кажется, что подобные штуки только мешают т.к. изменение света по бокам привлекает внимание, туда автоматически переходит взгляд, а там ничего нет. Т.е. как-бы пытаешься там что-то увидеть, а там — ничего. И приходится наоборот сосредотачивать взгляд на картинке и пытаться не уводить его в сторону на подсветку?
Объясните мне, зачем надо писать сервис прям там? Можно ведь схитрить и сделать все заранее?
Как подобные читы отслеживаются? Или это просто «на честность»?
Да, с Chromium на Ubuntu нам пока не удалось подружиться. Рfботаем над этим.
Первая версия сайта была сделана за 4 месяца. Как такового прототипа не было.
Посмотрел — сами файлы идут у нас так же как и с vk.com через userapi.com. По идее домен один и тот же. Если на vk все работает, то и у нас должно.
Мне кажется, что качество контента в плейлистах, созданных именно пользователями значительно выше, нежели в радио. Поэтому усилия, потраченные на поиск хорошего плейлиста компенсируются тем, что его потом можно будет слушать не один раз.
О, поправили, спасибо. Пробуйте.
Есть в списке неуловимых багов. Будем бороться.
Это неправильный regex шаблон. Поправим. Наши извинения.
Не ожидали если честно. Но сейчас все ок — добавили ресурсов.
Положили нам бэкэнд. Увеличили с 1 ядра до 4. Наши извинения.
Верно, лишняя строчка.
Это наверное взаимовыгодное сотрудничество. Но в целом, учитывая, что мы делимся кодом, наверное мы поддерживаем сообщество.
Кстати, это очень распространенный косяк — во всех трех ДЦ где я обслуживался можно было так сделать. Иногда чуть сложнее, иногда чуть проще, но в целом несложно, если четко знать что ребутаешь.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность