Pull to refresh
74
0.1
Александр Щепановский @Suor

User

Send message
Большинство языков, которые используются на сервере, динамически типизированы и это никому не мешает. А перенести — легко, просто использовать часть кода и там, и там. Что может быть естественнее? Намного лучше, чем любые вышеперечисленные костыли.
А можно на сервере реализовать на Javascript-е и не извращаться так
И потом искать в каждой статье несколько десятков тысяч регекспов? Не.
Так тут-то не виртуальный хостинг, тут дофига серверов, а нагрузки всего ничего.
И кстати, более интересно сколько запросов выполняется за день
Ну один выделенный сервер точно удержит 100 человек онлайн и больше. Что вы там делаете с этими людьми онлайн, что требуется такая развесистая архитектура?
2000 хостов в день это мало. Справиться один сервер, по крайней мере для обычного сайта.
А как вы считаете количество человек онлайн?

Нашёл тут у вас одну неэффективность — на странице tactoom.com/interest/Tactoom-Feedback при наведении на подпись (Tactoom-Feedback, например) делается POST Ajax запрос для каждой ссылки заново.
Ну если ты используешь что-то подобное для изменяемых объектов, то ты должен понимать, что ты делаешь. В некоторых случаях это даже полезно, Borg pattern, например, частный случай.

Если ты не знаешь, что ты делаешь, ну что ж, делать глупости не запретишь. На самом деле, запрещать делать глупости скорее вредно, чем полезно.
Такие фабрики для immutable объектов, а для них всё равно один это объект или два одинаковых
1) Набрала новая популярность новая мобильная платформа. Выпустить свой мобильный клиент под него будет проще? Сомневаюсь. Поддерживать кучу клиентов тоже сложно. Плюс даже если вы всё это сделали, то более общий клиент скорее окажется у пользователя, чем ваш, минус лишняя установка.
2) Большинство сайтов не имеет мобильных версий, мобильных клиентов, какой-то ещё функциональности из-за того, что руки не доходят. В то же время, прикрутить стороннюю систему комментариев от Disqus или даже просто из Вконтакте — плёвое дело.
3) Если проект не развивать, то он умрёт. То что делается для заказчика без поддержки — не серьёзный проект, по крайне мере, не настолько насколько проект, делающийся для себя и для людей. Если, конечно, нужно сделать что-то что не требует развития и требует минимальной поддержки, то это действительно повод сокращать зависимости. Всякий подход имеет свои ограничения, подход интеграции, который я предлагаю, действительно не блещет в таком случае.
Ничто не вечно, и нет совершенных решений. Ваш интерфейс без стороннего сервиса устареет гарантированно
Ну да, они бы ответили — мне нужно загрузить файлы
Наверное, треть пользователей не знает, что такое жёсткий диск, половина не знает, что такое сервер. Это действительно не то, что нужно пользователю.
Ну пока Flickr и Dropbox не стали повсеместными, видимо, придётся и обычную загрузку обеспечить. Тем не менее, даже если человек изначально не использовал эти сервисы, когда ему понадобится дополнительная функциональность, вы сможете ему её предоставить с помощью них, а не реализуя её самостоятельно.

Ещё один пример, на некоторых сайтах Gravatar — единственный способ получить аватар и ничего, народ пользуется. Через некоторое время даже оценивает удобство.
Загружать файлы — это не то, что нужно юзеру
Если речь о синхронизируемой папке, то никто не мешает отобрать и обработать до того как туда складывать. В любом случае, бац и оно уже там — очень удобно. Если бы Google Docs требовал вручную подтверждать отправку или подгрузку изменений он был бы значительно менее удобен.
Если ты добиваешься чужой, ты потратишь кучу времени, поймёшь, что это тебе не нужно и только потом придёшь к состоянию «нет цели»
Смотрел, там сильно недостаточная инвалидация. Кеш запроса сбрасывается только когда один из объектов из его результатов изменяется. Например, выборка последних новостей так и зависнет если их никто не будет редактировать, а при добавлении новых новостей кеш сбрасываться не будет.
Johnny Cache, насколько я знаю, инвалидирует сразу все запросы к модели поэтому просто неприменим если изменения часты. В тех же случаях когда он применим он должен быть быстрее потому как проще.
Тоже когда переходил с iPhone на HTC Desire S беспокоился насчёт того, что кнопки сенсорные. На самом деле, обнаружил, что в большинстве случаев они удобнее и нажимать их куда быстрее (просто лёгкое касание вместо заметного вжимания как на iPhone). Относительно неудобно пользоваться только в темноте.

Information

Rating
3,219-th
Location
Красноярск, Красноярский край, Россия
Date of birth
Registered
Activity