Если их устраивает, пускай платят :)
Всякое бывает. :)
Я себе не могу позволить арендовать мощный сервер из-за пиков в 30-50 раз от средней посещаемости.
Если посещаемость плавная, то этот момент не так заметен, необходимость увеличения с ростом посещаемости кажется очевидной.
1. Уже все знают, что Yii 1.1 :)
2. Я всегда говорил, что самопись использую только для себя. :) А поддерживать ядро нужно в любом случае, ибо на фреймворках всего этого нету. :)
3. 1 проект.
4.1. Но вы же хотите платить по часам :) На самом деле все эти часы — ерунда: их легко можно нарисовать (и мои менеджеры их рисовали :) )
4.2. Я не о клиенте. Сама система бронирования уже есть? Оно уже где-то работает? Или бронируют в бумажном журнале? :)
Прикрутить в этом случае API к работающей системе как бы не сложно.
Но нужно понимать, почему не устроили существующие решения.
Ведь они имеют интеграцию с другими процессами компании.
4.3. Ну и я не знаю, что вы хотите видеть в своем приложении. :) Поставьте требование разработчикам приложения, они поставят нам.
4.5. >адекватность, инициативность
Вы хороший клиент.
Большинство заказчиков настаивают, чтобы делать бред, который они хотят. :)
А потом часто просят сделать так, как им говорили.
Только как вы это будете определять?
На цену вопроса внимания не обращаете?
4.7. Если нету необходимости в этих технологиях, то это только удорожит разработку. А еще неизвестны перспективы этих технологий.
Нужно иметь конкретную задачу и решать ее самым простым способом.
Вот тут где-то для отдачи статики предлагали нагородить огород, который якобы будет держать большие нагрузки.
Но при этом не учитывалось, что спрос ограниченный и этот огород не может реализовать требования ТЗ. :)
Всех оппонентов прошу сделать то же самое.
У Вас почему-то 2 раза 1 :^)
1. Иссесина. Всегда работал в команде, самопись — это личное.
Конечно, были опытнее.
Использовали то, что и все: mysql / php / memcached
Размер микрокоманды — 6 человек. Размер всей команды — хз, больше 20 человек, я всех не видел. :)
Бложик, по большому счету, я не писал специально. :) Все было готово, прикрутил только вывод на главную.
2. Кроме меня этими проектами никто не занимается.
Вот с начала лета точно в ядро ни разу не лез :)
3. Нет, у меня 60к хостов влезало в шаред хостинг и не выходило за лимиты процессора.
Зачем меряться количеством серверов? :)
Это показатель крутости?
Хм, но лучше меньшее кол-во серверов: и по цене и по поддержке.
На работе порядка 15 серверов.
4. Я никому свой код не продаю. :)
Вам нужно API для МП или система бронирования полностью?
Что такое «асайнить»? Назначать/бронировать?
Нужно знать, какие методы нужно предоставить.
Вы платите по часам / по строкам кода / по результату? :)
Какие критерии выбора подрядчика?
А вообще, больше времени уходит не на написание кода, а на чтения замудрого кода, где шибко умные программисты ерунду писали, или просто кода, по которому плачет рефакторинг. :)
Ничего особенного использовать не буду. Зачем технологии ради технологий? :)
То есть, Вы таки признаете, что на фреймворках есть баги? :)
А проблема, конечно, надуманная.
Разработчики платят за сервера не из своего кармана.
Разработчики не могут оптимизировать код и поют бизнесу сказки о высоких нагрузках и покупке новых серверов.
И скажите, что неправда.
То есть ООП — ерунда (я не адепт ФП, если что :) ).
Весь этот пафос по поводу повторного использования кода, и 3-ех китов в жизни — ерунда. :)
Свой код можно как угодно писать. Можно все на интерфейсах.
А как с таким успехом использовать внешнюю библиотеку?
Она тоже нам должна предоставить только интерфейс, а каждый обязан сам свелосипедить реализацию? :)
Решение простое:
Никаких приватных элементов. Потом даже в наследнике будут проблемы при переопределении.
То, что хотели делать приватным, делать защищенным. При этом можно придерживаться соглашения, что элементы, начинающиеся на "_" — защищенные.
Если нам как бы реализация не нужна, а мы просто хотим придерживаться какого-то контракта, используем интерфейсы.
А также лучше предусмотреть события в базовом классе, чтобы не нужно было городить огород из ООП-наследования.
Подписался на события и имеешь профит :)
А можно использовать декоратор с __call() (PHP): можем скопом добавить поведение всем методам, можем для какого-то метода добавить другое, можно вообще переопределить.
А также вопрос:
Стоит ли использовать фреймворки, где в основном все реализовано, а не интерфейсы (PHP)? :)
Да и снова у вас какая-то путаница с терминами: хит и есть посещение))))
facepalm.
В рамках одного посещения (сессии) может быть 100500 хитов, минимум будет 1 в выродженном случае. :)
P.S.: о, увидел прогресс! Значит не все веб-проекты являются «сайтами», есть все-таки приложения?!)))))
Все веб-проекты — сайты, если смотреть широко, так как они на HTML и их смотрят через браузер.
Если смотреть узко, то ресурс, используемый в частной сети предприятия, или предоставляющий доступ ограниченному числу лиц (к API), где главное не рюшечки, а функционал.
Это сайт, реализующий ф-и приложения.
Сайтики — это действительно не моя парафия уже года 4 как. Распределенные web системы — это то, чем я занимаюсь.
Распределенным может быть как «сайтик», так и «приложение», также как и не быть :)
Высокопосещаемый новостной ресурс или ИМ — это всего лишь сайт.
Да, там может быть куча интеграций.
Ну и что?
Сейчас на всех сайтиках куча интеграций. :)
А также приложениями в широком смысле могут называться все готовые программные продукты, в т.ч. все сайтики :)
С другой стороны в 90-x и начале 00-х пришло время бесплатных компиляторов и интерпретаторов, и очень многие хорошие ЯП (Smalltalk, Delphi, etc.)
Продавали не язык, а IDE (Delphi). Да и какая альтернатива Delphi? MCVC? Но он платный. :)
Также, как сейчас под бесплатный PHP продают PHPStorm и PHPEd, ибо бесплатные ИДЕ унылые.
Всякое бывает. :)
Я себе не могу позволить арендовать мощный сервер из-за пиков в 30-50 раз от средней посещаемости.
Если посещаемость плавная, то этот момент не так заметен, необходимость увеличения с ростом посещаемости кажется очевидной.
2. Я всегда говорил, что самопись использую только для себя. :) А поддерживать ядро нужно в любом случае, ибо на фреймворках всего этого нету. :)
3. 1 проект.
4.1. Но вы же хотите платить по часам :) На самом деле все эти часы — ерунда: их легко можно нарисовать (и мои менеджеры их рисовали :) )
4.2. Я не о клиенте. Сама система бронирования уже есть? Оно уже где-то работает? Или бронируют в бумажном журнале? :)
Прикрутить в этом случае API к работающей системе как бы не сложно.
Но нужно понимать, почему не устроили существующие решения.
Ведь они имеют интеграцию с другими процессами компании.
4.3. Ну и я не знаю, что вы хотите видеть в своем приложении. :) Поставьте требование разработчикам приложения, они поставят нам.
4.5. >адекватность, инициативность
Вы хороший клиент.
Большинство заказчиков настаивают, чтобы делать бред, который они хотят. :)
А потом часто просят сделать так, как им говорили.
Только как вы это будете определять?
На цену вопроса внимания не обращаете?
4.7. Если нету необходимости в этих технологиях, то это только удорожит разработку. А еще неизвестны перспективы этих технологий.
Нужно иметь конкретную задачу и решать ее самым простым способом.
Вот тут где-то для отдачи статики предлагали нагородить огород, который якобы будет держать большие нагрузки.
Но при этом не учитывалось, что спрос ограниченный и этот огород не может реализовать требования ТЗ. :)
1. Это замеры вместе с сетевыми задержками + сервер :)
2. Главная страница там не доходит до php :)
Всех оппонентов прошу сделать то же самое.
У Вас почему-то 2 раза 1 :^)
1. Иссесина. Всегда работал в команде, самопись — это личное.
Конечно, были опытнее.
Использовали то, что и все: mysql / php / memcached
Размер микрокоманды — 6 человек. Размер всей команды — хз, больше 20 человек, я всех не видел. :)
Бложик, по большому счету, я не писал специально. :) Все было готово, прикрутил только вывод на главную.
2. Кроме меня этими проектами никто не занимается.
Вот с начала лета точно в ядро ни разу не лез :)
3. Нет, у меня 60к хостов влезало в шаред хостинг и не выходило за лимиты процессора.
Зачем меряться количеством серверов? :)
Это показатель крутости?
Хм, но лучше меньшее кол-во серверов: и по цене и по поддержке.
На работе порядка 15 серверов.
4. Я никому свой код не продаю. :)
Вам нужно API для МП или система бронирования полностью?
Что такое «асайнить»? Назначать/бронировать?
Нужно знать, какие методы нужно предоставить.
Вы платите по часам / по строкам кода / по результату? :)
Какие критерии выбора подрядчика?
А вообще, больше времени уходит не на написание кода, а на чтения замудрого кода, где шибко умные программисты ерунду писали, или просто кода, по которому плачет рефакторинг. :)
Ничего особенного использовать не буду. Зачем технологии ради технологий? :)
А проблема, конечно, надуманная.
Разработчики платят за сервера не из своего кармана.
Разработчики не могут оптимизировать код и поют бизнесу сказки о высоких нагрузках и покупке новых серверов.
И скажите, что неправда.
Берите Симфони.
Посмотрите, как тупит блаблакар. :)
Я тоже не ведусь на моду. :)
Собственно, поэтому выступаю против фреймворков в PHP.
ООП — это тоже мода.
С таким подходом нужно покрывать тестами весь PHP :)
А ручные поверхностные тесты никто в любом случае не отменял.
Весь этот пафос по поводу повторного использования кода, и 3-ех китов в жизни — ерунда. :)
Свой код можно как угодно писать. Можно все на интерфейсах.
А как с таким успехом использовать внешнюю библиотеку?
Она тоже нам должна предоставить только интерфейс, а каждый обязан сам свелосипедить реализацию? :)
Решение простое:
Никаких приватных элементов. Потом даже в наследнике будут проблемы при переопределении.
То, что хотели делать приватным, делать защищенным. При этом можно придерживаться соглашения, что элементы, начинающиеся на "_" — защищенные.
Если нам как бы реализация не нужна, а мы просто хотим придерживаться какого-то контракта, используем интерфейсы.
А также лучше предусмотреть события в базовом классе, чтобы не нужно было городить огород из ООП-наследования.
Подписался на события и имеешь профит :)
А можно использовать декоратор с __call() (PHP): можем скопом добавить поведение всем методам, можем для какого-то метода добавить другое, можно вообще переопределить.
А также вопрос:
Стоит ли использовать фреймворки, где в основном все реализовано, а не интерфейсы (PHP)? :)
Другие примеры дурного использования ООП http://blog.kpitv.net/article/ооп-может-способствовать-лапше-трудному-пониманию-кода-15417/.
Отказаться от наследования — это отказаться от лошади в пользу автомобиля :)
facepalm.
В рамках одного посещения (сессии) может быть 100500 хитов, минимум будет 1 в выродженном случае. :)
Все веб-проекты — сайты, если смотреть широко, так как они на HTML и их смотрят через браузер.
Если смотреть узко, то ресурс, используемый в частной сети предприятия, или предоставляющий доступ ограниченному числу лиц (к API), где главное не рюшечки, а функционал.
Это сайт, реализующий ф-и приложения.
цитата
Распределенным может быть как «сайтик», так и «приложение», также как и не быть :)
Высокопосещаемый новостной ресурс или ИМ — это всего лишь сайт.
Да, там может быть куча интеграций.
Ну и что?
Сейчас на всех сайтиках куча интеграций. :)
А также приложениями в широком смысле могут называться все готовые программные продукты, в т.ч. все сайтики :)
:)
А как его провести, если проект не покрыт тестами? :)
Это как раз правильная оптимизация.
И
Продавали не язык, а IDE (Delphi). Да и какая альтернатива Delphi? MCVC? Но он платный. :)
Также, как сейчас под бесплатный PHP продают PHPStorm и PHPEd, ибо бесплатные ИДЕ унылые.
Есть анализаторы кода на предмет совместимости с 7.
А почему, собственно, таким дорогим стал DOM? :)
Это ж не большие данные/таблицы.
Хотя вот у меня новая Опера на 5 вкладках (2 из них одинаковые) съедает 1.3GB :)
Хотя, возможно, это из-за этих оптимизаций все :)