По этому поводу я уже свою позицию озвучивал — историю надо по учебникам учить.
На ресурсе, где кто угодно их может отредактировать их ценность сомнительна.
Здесь же разговор совершенно о другом, со стороны властей был шаг на встречу, со стороны вики как-то не очень, вопрос почему. При этом раскрученные скандалы на тему блокировок уже даже для идиотов становятся не такими однозначными.
Т.е. возможно что часть личностей, которые там продавали всякое полуработающее гавно на левые симки, внезапно для самих себя теперь найдутся? Ну а что, даже позитивненько :)
Вон оно как получается, свобода это хорошо, но не всякая свобода.
Оказывается когда что-то банит кто-то со стороны наших властей — это ужас кошмар и вообще.
А как только есть попытка пойти на встречу, понять, договориться — ну вы поняли да?
Ток не надо тут про всякое, не имел право, использовали бы в грязных целях, показали бы по телеку.
Те кто право имел как бы тоже могли сходить, похоже. Но вот что-то не пошли.
Видимо очень заняты исправлением статей про нашу историю, ну чтоб тут вообще никто ни в чем не сомневался.
Привет всем полоумным, которые пытались внушать, что мой мозг промыт телевизором.
>глюкометр
Это типо браслет будет временами ласково прокалывать руку иголочкой?
>кардиомонитор
Его разве реально в браслет вставить?
>Хотя ценности для врачей фитнес-трекеры не несут,
А они вообще какую-то ценность несут?
>Сегал отмечает их пользу для конкретных людей, которых гаджеты заставляют быть более активными.
Ну да, с тем же успехом можно и телефон в кармане потаскать, по первости, возможно интересно сколько в день нашагал.
Да там вся «фишка» была, что типа только специальные полезные люди могу с помощью этих палочек найти место для колодца. Суть то на самом деле в том, что эти специальные люди получали за это бонус, а вода обычно в любом случае есть, если она есть в округе, ну глубина только меняется. С трубой хз, вроде только специальная «наука», которую на рентв уважают, такое объяснить может.
>По мнению Безоса, идеальная команда не должна включать больше людей, чем можно насытить двумя пиццами.
Хм, а если я могу в одиночку сожрать две пиццы?
>Если он потратит пару недель своей работы на то,
>чтобы сэкономить на установку целого сервера, это окупится за полгода.
Откуда такие цифры как пара недель и целого сервера? Обычно речь идет о процентах, ну мыж не говорим о системе которую писали джуниоры и ни разу не проверяли под нагрузками?
>Т.е. в тех задачах, где можно было просто оптимизировать код, вы предлагаете не просто забить
>на оптимизацию, а поставить уже даже не дополнительный сервер, а целую ферму.
Нет я лишь говорю что вы асбоютно не правы, и что в нормальном проекте для еще десятка серверов не придется заводить в два раза больше админов.
>Мне кажется, экономическую часть вашего диплома вы в своё время завалили :)
А вы похоже сдали с отличием?) Похвастайтесь в каком вузе так пофиг на дипломы)
Впрочем если без стеба тут хватит школьной математики:
Мой опыт показывает, что сервис на java дольше разрабатывается, раза в два, прогеры в целом стоят больше, а в результате выйгрыш на серверах раза в два в лучшем случае. Если говорить о проекте, который изначально заведомо успешный, то согласен, php я бы для него не выбрал, однако обычно рулит скорость старта. Ну и также покупать серваки смысл есть не всегда, есть аренда, а там окупаемость совсем другая. Возможно у вас другой опыт, но без цифр и предметной области это будет всего лишь тупой спор.
>Ну да, только это будет для следующего запроса, а не тех, которые были на железке в момент сбоя.
Чтото я туплю, но разве повысится статистически шанс потерять запрос при увеличении количества серверов и таком же количестве запросов? Учитывая что время обработки сильно отличаться не будет.
>Ничего странного. Любой коннект к базе — это значительные
>накладные расходы на сам коннект плюс на поддержание пользовательской сессии в СУБД.
Коннект по сравнению со всем остальным это копейки обычно, опять же непонятно что вы такое делали? Да и что за база была? Ну ни разу даже не слышал про проблему с такой стороны. У вас был пучок пхп скриптов запущенных как демоны? Вообще обычно узкое место — это хранение данных, т.е. сколько можем записать прочитать, какой язык это уже дело второе.
> Это только кажется, что сервер дешевле программиста.
Так можно посмотреть на цены, ну и мы же не имеем ввиду джуниоров работающих за еду в роли программиста?
> Обычно оценивают только стоимость самого сервера, но при этом забывают,
> что на чашу весов сервера надо положить ещё его установку,
>конфигурирование и далее эксплуатационное обслуживание,
>причем тоже живыми людьми с вполне недешевым рабочим временем.
Сочувствую, что вам приходится работать с людьми, которые забывают столь важные вещи)
Впрочем я про то, что 10 или 20 серверов разницы по поддержке почти нет, они же типовые будут. Все разворачивается и настраивается почти автоматом, если, конечно, все профессионально делать. Сейчас огромная куча разных программных средств, которые очень сильно облегчают работу. По сути добавление сервера сводится к загрузке образа и запуску установочного скрипта. Для мониторинга также есть куча всяких средств.
>Плюс, новый сервер — новая точка отказов.
Это вы вообще про что?) Ну как бэ банально балансер же можно настроить, чтоб он дальше запрос перекидывал, если какое-то железо сдохло)
Ложился только от коннектов? Странно. Или вы так что-то вроде кеширования намутили?
Если речь идет про то что база не справлялась, то понятно дело, что PHP тут не причем.
Если же про то что application сервер падал, ну т.е. там где PHP крутится — то тут у нас все делается по другому, таких серверов ставится несколько, добавляются по мере необходимости, пока их пара десятков это выгодно, т.к. железо в целом стоит дешевле программистов :)
Да там небось обычная ситуация, «а ну давай те вон тех наймем на пхп, они занедорого напишут».
А далее парят мозг, каждый день что-то заставляя менять, либо внезапно окажется, что проблема вообще не в пхп, а в том что кто-то не сказал, что верстка под мобильные устройства, например нужна.
Ну да так повелость, что парни на с# — java обычно и берут сильно больше и договор грамотно составляют, так что бы потом на просьбу «поиграться со шрифтами» выставить нифиговый счет.
Только это не проблема в языке, это проблема в мозгу всех причастных.
>Просто интереса ради почитайте про HFT
Ок спасибо, просто в некоторых задачах на практике c++ показал себя сильно намного лучше, возможно я что-то делал не так.
>И скрипт не грузится перед каждым выполнением заново?
Да это давно уже нет, nginx воркеры все такое, а есть еще hhvm
>Вот прям не велосипеды и не Mongo/etc, а прямо сервер приложений/ядро оного на языке,
>способные обслуживать множество запросов?
Можно и так сделать, только смысла особого не имеет, реализации общей памяти да, могут показаться надстройкой, однако для решения задач вполне себе хватает и пользоваться в целом удобно.
>Перед каждой переменной нужно ставить дополнительный символ, которы набирается с шифтом. Это раздражает.
Ну детский сад, ну IDE уже наконец настройте чтобы он за вас это делал. Вы еще скажите что по пять мегабайт кода в день пишите, что от лишнего нажатия на шифт устаете.
>Закат солнца вручную? Да, приходится иногда делать. Но лучше, когда язык делает за тебя.
Ну да, а вот в той же java многих бесят постоянные и временами ненужны пляски с типами, да и со многим чем другим.
Ага вот, поэтому появляется что-то вроде scala, которая как java, но не совсем. Почему-то никто не плодит всяких «улучшенных пхп»
>Есть удобный механизм для хранения разделяемых ресурсов в памяти?
>Чтобы, например, каждый запрос использовал один и тот де коннекшн к БД?
Это т.е. несколько хттп запросов к пхп и конекшен один? А зачем так? Берем тогда phpDaemon, производительность у него на уровне nodeJS. Если именно ресурсы как данные, то apc есть.
>Есть поддержка многопоточности? Прямо concurrency?
Сыплете терминами всякими, прям как гуманитарий какой. Мы то люди простые, вы задачу опишите, которую хотите решить, там и понятно будет может это пхп или нет. На счет же всяческих указателей компилятору что оптимизировать что нет, тут конечно же нет.
>Если проект новый, то java (дажа java) даст рост производительности в разы.
Ну да, правда есть такой огромный шанс, что когда его на java напишут он уже нафиг никому не нужен будет.
С пхп все несколько веселее, прототип — за месяц на коленке, тут главное опыт иметь и чтот-то вроде архитектуры придумать. Далее можно тупо кусками тяжелые моменты запиливать, например, демонами на с++. На больших данных и тяжелых манипуляциях с ними — с++ джаву сделает только в путь.
>Есть язык программирования С на котором написано на порядки больше, чем на php.
>Никто, однако, (кроме разве что Линуса Торвальдса) не спорит, что у него есть объективные недостатки.
Фигня в том, что PHP прост, а вот изучить нормально С «обсирателям» уже не получается, поэтому гавнакод на С кажется им адски крутой магией.
На nodeJS большой проект писать и поддерживать дороже, там не только с ООП проблемы, их там еще оч много, пока все допилят и привыкнут, те же лет пять точно пройдут а скорее намного больше.
>* Когда достала необходимость ставить доллары перед каждой переменной.
Ну это прям мега довод) Или это изза нынешней финансовой ситуации и ипотеки в валюте?))
>Нужен удобный механизм хранения разделяемых ресурсов в оперативной памяти.
Он там есть.
>* Нужна поддержка многопоточности.
Тоже есть.
>* Нужна выская производительность.
Если нужна высокая производительность то тогда не php надо бросать, а учить с++ и писать частично на нем именно те части, которые требуют высокой производительности, java тут будет не полноценным выходом.
>* Хочется исключить ошибки, которые можно исключить системой статической типизации.
выше написали про php 7, но в целом никто не мешает запилить например ассёрты уже сейчас.
Во-первых я написал «как вариант», это сильно отличается от какого либо категоричного заявления.
И как я писал выше, в большинстве случаев там где есть генерация и тд — используется минимум всех возможностей субд, и использование субд выглядит странным и неоправданым, т.к. на данный момент существует огромное множество различных хранилищ на любую вкус цвет и запах.
> Какая, по-вашему, связь между способом описания схемы данных и, например, необходимостью иметь транзакции?
У вас очень странные вопросы, из серии «какая по вашему связь между теплым и зеленым», я не знаю какой вы ответ хотите увидеть.
На ресурсе, где кто угодно их может отредактировать их ценность сомнительна.
Здесь же разговор совершенно о другом, со стороны властей был шаг на встречу, со стороны вики как-то не очень, вопрос почему. При этом раскрученные скандалы на тему блокировок уже даже для идиотов становятся не такими однозначными.
Оказывается когда что-то банит кто-то со стороны наших властей — это ужас кошмар и вообще.
А как только есть попытка пойти на встречу, понять, договориться — ну вы поняли да?
Ток не надо тут про всякое, не имел право, использовали бы в грязных целях, показали бы по телеку.
Те кто право имел как бы тоже могли сходить, похоже. Но вот что-то не пошли.
Видимо очень заняты исправлением статей про нашу историю, ну чтоб тут вообще никто ни в чем не сомневался.
Привет всем полоумным, которые пытались внушать, что мой мозг промыт телевизором.
Это типо браслет будет временами ласково прокалывать руку иголочкой?
>кардиомонитор
Его разве реально в браслет вставить?
>Хотя ценности для врачей фитнес-трекеры не несут,
А они вообще какую-то ценность несут?
>Сегал отмечает их пользу для конкретных людей, которых гаджеты заставляют быть более активными.
Ну да, с тем же успехом можно и телефон в кармане потаскать, по первости, возможно интересно сколько в день нашагал.
Хм, а если я могу в одиночку сожрать две пиццы?
>чтобы сэкономить на установку целого сервера, это окупится за полгода.
Откуда такие цифры как пара недель и целого сервера? Обычно речь идет о процентах, ну мыж не говорим о системе которую писали джуниоры и ни разу не проверяли под нагрузками?
>Т.е. в тех задачах, где можно было просто оптимизировать код, вы предлагаете не просто забить
>на оптимизацию, а поставить уже даже не дополнительный сервер, а целую ферму.
Нет я лишь говорю что вы асбоютно не правы, и что в нормальном проекте для еще десятка серверов не придется заводить в два раза больше админов.
>Мне кажется, экономическую часть вашего диплома вы в своё время завалили :)
А вы похоже сдали с отличием?) Похвастайтесь в каком вузе так пофиг на дипломы)
Впрочем если без стеба тут хватит школьной математики:
Мой опыт показывает, что сервис на java дольше разрабатывается, раза в два, прогеры в целом стоят больше, а в результате выйгрыш на серверах раза в два в лучшем случае. Если говорить о проекте, который изначально заведомо успешный, то согласен, php я бы для него не выбрал, однако обычно рулит скорость старта. Ну и также покупать серваки смысл есть не всегда, есть аренда, а там окупаемость совсем другая. Возможно у вас другой опыт, но без цифр и предметной области это будет всего лишь тупой спор.
>Ну да, только это будет для следующего запроса, а не тех, которые были на железке в момент сбоя.
Чтото я туплю, но разве повысится статистически шанс потерять запрос при увеличении количества серверов и таком же количестве запросов? Учитывая что время обработки сильно отличаться не будет.
>накладные расходы на сам коннект плюс на поддержание пользовательской сессии в СУБД.
Коннект по сравнению со всем остальным это копейки обычно, опять же непонятно что вы такое делали? Да и что за база была? Ну ни разу даже не слышал про проблему с такой стороны. У вас был пучок пхп скриптов запущенных как демоны? Вообще обычно узкое место — это хранение данных, т.е. сколько можем записать прочитать, какой язык это уже дело второе.
> Это только кажется, что сервер дешевле программиста.
Так можно посмотреть на цены, ну и мы же не имеем ввиду джуниоров работающих за еду в роли программиста?
> Обычно оценивают только стоимость самого сервера, но при этом забывают,
> что на чашу весов сервера надо положить ещё его установку,
>конфигурирование и далее эксплуатационное обслуживание,
>причем тоже живыми людьми с вполне недешевым рабочим временем.
Сочувствую, что вам приходится работать с людьми, которые забывают столь важные вещи)
Впрочем я про то, что 10 или 20 серверов разницы по поддержке почти нет, они же типовые будут. Все разворачивается и настраивается почти автоматом, если, конечно, все профессионально делать. Сейчас огромная куча разных программных средств, которые очень сильно облегчают работу. По сути добавление сервера сводится к загрузке образа и запуску установочного скрипта. Для мониторинга также есть куча всяких средств.
>Плюс, новый сервер — новая точка отказов.
Это вы вообще про что?) Ну как бэ банально балансер же можно настроить, чтоб он дальше запрос перекидывал, если какое-то железо сдохло)
Если речь идет про то что база не справлялась, то понятно дело, что PHP тут не причем.
Если же про то что application сервер падал, ну т.е. там где PHP крутится — то тут у нас все делается по другому, таких серверов ставится несколько, добавляются по мере необходимости, пока их пара десятков это выгодно, т.к. железо в целом стоит дешевле программистов :)
А далее парят мозг, каждый день что-то заставляя менять, либо внезапно окажется, что проблема вообще не в пхп, а в том что кто-то не сказал, что верстка под мобильные устройства, например нужна.
Ну да так повелость, что парни на с# — java обычно и берут сильно больше и договор грамотно составляют, так что бы потом на просьбу «поиграться со шрифтами» выставить нифиговый счет.
Только это не проблема в языке, это проблема в мозгу всех причастных.
Ок спасибо, просто в некоторых задачах на практике c++ показал себя сильно намного лучше, возможно я что-то делал не так.
>И скрипт не грузится перед каждым выполнением заново?
Да это давно уже нет, nginx воркеры все такое, а есть еще hhvm
>Вот прям не велосипеды и не Mongo/etc, а прямо сервер приложений/ядро оного на языке,
>способные обслуживать множество запросов?
Можно и так сделать, только смысла особого не имеет, реализации общей памяти да, могут показаться надстройкой, однако для решения задач вполне себе хватает и пользоваться в целом удобно.
Ну детский сад, ну IDE уже наконец настройте чтобы он за вас это делал. Вы еще скажите что по пять мегабайт кода в день пишите, что от лишнего нажатия на шифт устаете.
Ну да, а вот в той же java многих бесят постоянные и временами ненужны пляски с типами, да и со многим чем другим.
Ага вот, поэтому появляется что-то вроде scala, которая как java, но не совсем. Почему-то никто не плодит всяких «улучшенных пхп»
>Есть удобный механизм для хранения разделяемых ресурсов в памяти?
>Чтобы, например, каждый запрос использовал один и тот де коннекшн к БД?
Это т.е. несколько хттп запросов к пхп и конекшен один? А зачем так? Берем тогда phpDaemon, производительность у него на уровне nodeJS. Если именно ресурсы как данные, то apc есть.
>Есть поддержка многопоточности? Прямо concurrency?
Сыплете терминами всякими, прям как гуманитарий какой. Мы то люди простые, вы задачу опишите, которую хотите решить, там и понятно будет может это пхп или нет. На счет же всяческих указателей компилятору что оптимизировать что нет, тут конечно же нет.
>Если проект новый, то java (дажа java) даст рост производительности в разы.
Ну да, правда есть такой огромный шанс, что когда его на java напишут он уже нафиг никому не нужен будет.
С пхп все несколько веселее, прототип — за месяц на коленке, тут главное опыт иметь и чтот-то вроде архитектуры придумать. Далее можно тупо кусками тяжелые моменты запиливать, например, демонами на с++. На больших данных и тяжелых манипуляциях с ними — с++ джаву сделает только в путь.
>Никто, однако, (кроме разве что Линуса Торвальдса) не спорит, что у него есть объективные недостатки.
Фигня в том, что PHP прост, а вот изучить нормально С «обсирателям» уже не получается, поэтому гавнакод на С кажется им адски крутой магией.
Ну это прям мега довод) Или это изза нынешней финансовой ситуации и ипотеки в валюте?))
>Нужен удобный механизм хранения разделяемых ресурсов в оперативной памяти.
Он там есть.
>* Нужна поддержка многопоточности.
Тоже есть.
>* Нужна выская производительность.
Если нужна высокая производительность то тогда не php надо бросать, а учить с++ и писать частично на нем именно те части, которые требуют высокой производительности, java тут будет не полноценным выходом.
>* Хочется исключить ошибки, которые можно исключить системой статической типизации.
выше написали про php 7, но в целом никто не мешает запилить например ассёрты уже сейчас.
Раз так ненавидят, значит боятся! правильным путем двигаемся!
И как я писал выше, в большинстве случаев там где есть генерация и тд — используется минимум всех возможностей субд, и использование субд выглядит странным и неоправданым, т.к. на данный момент существует огромное множество различных хранилищ на любую вкус цвет и запах.
> Какая, по-вашему, связь между способом описания схемы данных и, например, необходимостью иметь транзакции?
У вас очень странные вопросы, из серии «какая по вашему связь между теплым и зеленым», я не знаю какой вы ответ хотите увидеть.