Комментарии 299
Посмеялся, спасибо.
Над чем? Через какое-то время фреймворк опубликую, который решает проблемы автоматической настройки и эффективного использования ресурсов.
А по поводу Google — почитайте доступные Papers.
А по поводу Google — почитайте доступные Papers.
Над чем? Без обид, у вас каждое предложение — в мемориз можно, поднимать настроение в грустные дни. Мы радуемся всем отделом.
Конкретнее, с технической точки зрения ценность каждого второго предложения минимальна, а в целом весь пост выглядит крайне сумбурно, будто ведро с гайками на пол вывалил — нате, собирайте. Скачете с темы на тему, по разным уровням — тут же и про OpenVZ, и про SQL-select-ы.
>> Через какое-то время фреймворк опубликую
Я вас за язык не тянул, оповестите, пожалуйста, как появится.
Конкретнее, с технической точки зрения ценность каждого второго предложения минимальна, а в целом весь пост выглядит крайне сумбурно, будто ведро с гайками на пол вывалил — нате, собирайте. Скачете с темы на тему, по разным уровням — тут же и про OpenVZ, и про SQL-select-ы.
>> Через какое-то время фреймворк опубликую
Я вас за язык не тянул, оповестите, пожалуйста, как появится.
Вы правы, но я ведь написал что тема обширна. По-хорошему, каждое предложение надо заменить на страницу текста, но тогда вы бы наверное сказали что многобукв, да и читать не особенно интересно было бы.
— Конкретнее, с технической точки зрения ценность каждого второго предложения минимальна, а в целом весь пост выглядит крайне сумбурно, будто ведро с гайками на пол вывалил — нате, собирайте. Скачете с темы на тему, по разным уровням — тут же и про OpenVZ, и про SQL-select-ы.
Сразу вспомнил как мой преподаватель когда-то сказал: «Это как взять кучу дерьма, бросить на мозги и смотреть как оно впитается».
Сразу вспомнил как мой преподаватель когда-то сказал: «Это как взять кучу дерьма, бросить на мозги и смотреть как оно впитается».
… Из зала подсказывают, что вы, вероятно, не на papers, а poppers налегали. Евпочя.
↓↓ Ахтунг! Холивары! ↓↓
вопрос? а почему вы выбрали именно то, что выбрали? при разработке высоконагруженных систем нельзя полагаться просто на слова. нужны какие то графики тестирования нагрузке, а может oracle лучше справится? а может постгре? а почему не используете фиксы фейсбука для мемкеша, так будет быстрее?
слишком много вопросов возникает.
слишком много вопросов возникает.
Oracle и PostgreSQL это реляционки, у них свои проблемы.
Патчи можно использовать, но это спичечные оптимизации, а не архитектурные.
Патчи можно использовать, но это спичечные оптимизации, а не архитектурные.
Oracle и PostgreSQL — реляционки, у них свои проблемы.
Фиксы можно использовать, но они относятся к спичечной оптимизации, а не к архитектуре. Если бы я затронул все спичечные оптимизации каждого из продуктов, надо было бы писать книгу, а не статью, которая призвана дать верное направление для размышления.
Фиксы можно использовать, но они относятся к спичечной оптимизации, а не к архитектуре. Если бы я затронул все спичечные оптимизации каждого из продуктов, надо было бы писать книгу, а не статью, которая призвана дать верное направление для размышления.
неужели если от Гугла — то значит «правильно»?
Интересно, кстати, по поводу phpDeamon — Вам удалось его запустить? Так как это продолжение предыдущего проекта — phpTrueFastCGI (Или примерно так), и не все еще перенесено, то есть по мануалу не получится его запустьи. Я сам делаю примерно такую же систему (и фреймворк), но пока основываюсь на Redis+Net_Server+signal/slot архитектура
Поясните почему выбран php и такой тяжеловестный контейнер приложений.
Фактически, разрабатывать можно на чем угодно, важно лишь соблюдать концепцию. PHP удобен. OpenVZ подходит для того чтобы оградить приложения друг от друга.
PHP удобен.
Можно конкретные примеры чем он удобнее к примеру python, perl, java
OpenVZ подходит для того чтобы оградить приложения друг от друга.
Вам не кажется что технология слишком тяжела для такой простой вещи? Чем хуже запуск сервиса от отдельного пользователя?
НЛО прилетело и опубликовало эту надпись здесь
К примеру у python есть модели для FastCGI и WSGI из коробки, есть такая замечательная штука как twisted. В случае если код выносится в модули, то он может быть прекомпилирован и при интерпретации не потребуется трансляция в байткод. У perl опять же есть модели для FastCGI и аналогичные twisted фреймворки. У java есть такая штука как servlet и большое количество различных фреймворков. Какой резон выбирать php в данном случае?
А в PHP есть phpDaemon::FastCGI ;-)
НЛО прилетело и опубликовало эту надпись здесь
А вот в пхп кэшировать опкод нельзя, да?:)
Прям из коробки есть только в 5.3. В остальных только расширениями.
Для всех фреймворков и buzzwords явы жизнь слишком коротка.
А строить велосипеды на php не коротка? Вы вот посмотрите Spring.
если в команде никто толком не видел эту яву, какой смысл её выбирать?
А какой смысл выбирать php?
Ява слишком многословен (Map m = new Map(), так кажется?), php лаконичней (а Руби еще лаконичней к слову).
Блииин! Парсер порезал угловые скобки!
Ява: Map [String, Int ] m = new map [String, Int]; — сказывается уродливый Си++ подобный синтаксис
PHP: $m = array(); — тоже не очень
Руби: m = [] — самое то!
А уж если мы коснемся таких вещей, как замыкания, анонимные блоки кода, тут у Руби нет конкурентов, на нем просто писать приятней же. Плюс все объекты выглядят как объекты, например можно сделать print 'yes' if somestring.startsWith(); Плюс с массивами удобно работать, через методы типа map: new_array = old_array.map { |x| x*x; }
p.s Мануал по Руби читал давно, мог и напутать немного :)
Ява: Map [String, Int ] m = new map [String, Int]; — сказывается уродливый Си++ подобный синтаксис
PHP: $m = array(); — тоже не очень
Руби: m = [] — самое то!
А уж если мы коснемся таких вещей, как замыкания, анонимные блоки кода, тут у Руби нет конкурентов, на нем просто писать приятней же. Плюс все объекты выглядят как объекты, например можно сделать print 'yes' if somestring.startsWith(); Плюс с массивами удобно работать, через методы типа map: new_array = old_array.map { |x| x*x; }
p.s Мануал по Руби читал давно, мог и напутать немного :)
сказывается уродливый Си++ подобный синтаксис
Сказывается статическая типизация. Не путайте теплое с мягким.
А уж если мы коснемся таких вещей, как замыкания, анонимные блоки кода, тут у Руби нет конкурентов, на нем просто писать приятней же.
Я уже спрашивал, но все же как с производительностью?
НЛО прилетело и опубликовало эту надпись здесь
В свое время Бобук говорил рубистам: — Вот когда руби догонит хотя бы питон по скорости тогда и приходите.
Перефразируя его скажу:
-Когда php по производительности догонит java вот тогда и приходите.
Насчет лаконичности это сильно зависит от того что вы там писать будете.
Перефразируя его скажу:
-Когда php по производительности догонит java вот тогда и приходите.
Насчет лаконичности это сильно зависит от того что вы там писать будете.
Насчет скорости, вы абсолютно правы, это единственное, что удерживает меня от того чтобы бросить php. Но писать полотна кода ради того, что делается в Руби 2 строчками — надоедает, сколько уже можно это терпеть? Самые часто используемые вещи требуют много нажатий клавиш — массивы ($x = array('a' => 'b')), обращения к полям объекта ($this->field), анонимные функции, операции со строками и массивами используют уродливые конструкции типа str_replace($find, $replace, $string);
Другой пример, например мы хотим сделать объект БД для выполнения операций в рамках транзакции. Процедурный (уродливый) подход:
$db->startTransaction();
try {
$db-->doSomething(1);
$db-->doSomethingOther(2):
…
}
catch (Exception $e)
{
$db->rollback();
throw $e;
}
$db->commit();
А вот функциональный подход:
db->transaction { |db|
db->doSomething();
db->doSomethingElse();
…
}
Надо ли говорить, какой подход лучше? А если завтра вам понадобится поменять что-то в обработке исключений, к примеру, с первым подходом — вам придется лазать по всему коду. Дублирование кода — зло, а именно оно и и меет место в первом случае.
Также, очевидно, что читать и ориентироваться в лаконичном коде общем проще, да и на экран его помещается больше.
И ведь самое главное, ничто в общем-то не мешает сделать хороший синтаксис в Яве/PHP или даже старичке Си, но почему-то никто этим не занимается, значит ни кому не нужно?
Также, очевидно, что читать и ориентироваться в лаконичном коде общем проще, да и на экран его помещается больше.
> Насчет лаконичности это сильно зависит от того что вы там писать будете.
Не лукавьте, что ни пиши — все на Руби проще получается.
Кстати, что касается Явы — она у меня почему-то ассоциируется с огромными полотнами кода, страшными (в плане дизайна) западными корпоративными сайтами, нечитаемыми XML-конфигами, и дурацкими УРЛ типа /UnReadableServiceName.jsp?someparameter=1&someotherparameter=2. Или может сейчас что-то поменялось, но раньше было так.
Другой пример, например мы хотим сделать объект БД для выполнения операций в рамках транзакции. Процедурный (уродливый) подход:
$db->startTransaction();
try {
$db-->doSomething(1);
$db-->doSomethingOther(2):
…
}
catch (Exception $e)
{
$db->rollback();
throw $e;
}
$db->commit();
А вот функциональный подход:
db->transaction { |db|
db->doSomething();
db->doSomethingElse();
…
}
Надо ли говорить, какой подход лучше? А если завтра вам понадобится поменять что-то в обработке исключений, к примеру, с первым подходом — вам придется лазать по всему коду. Дублирование кода — зло, а именно оно и и меет место в первом случае.
Также, очевидно, что читать и ориентироваться в лаконичном коде общем проще, да и на экран его помещается больше.
И ведь самое главное, ничто в общем-то не мешает сделать хороший синтаксис в Яве/PHP или даже старичке Си, но почему-то никто этим не занимается, значит ни кому не нужно?
Также, очевидно, что читать и ориентироваться в лаконичном коде общем проще, да и на экран его помещается больше.
> Насчет лаконичности это сильно зависит от того что вы там писать будете.
Не лукавьте, что ни пиши — все на Руби проще получается.
Кстати, что касается Явы — она у меня почему-то ассоциируется с огромными полотнами кода, страшными (в плане дизайна) западными корпоративными сайтами, нечитаемыми XML-конфигами, и дурацкими УРЛ типа /UnReadableServiceName.jsp?someparameter=1&someotherparameter=2. Или может сейчас что-то поменялось, но раньше было так.
Рекомендую вам посмотреть Spring :)
Поменялось. 90% конфигураций почти везде заменяются аннотациями, дизайн тоже исправляется (возьмите хотя бы сайт Yota), url — это уже лет 5 как не проблема.
Хотите совсем Java-вого Ruby — попробуйте Groovy, он практически так же лаконичен, как и subj.
Еще один вариант — Scala, но там другие правила, и риск заработать ФП головного мозга.
Хотите совсем Java-вого Ruby — попробуйте Groovy, он практически так же лаконичен, как и subj.
Еще один вариант — Scala, но там другие правила, и риск заработать ФП головного мозга.
> Хотите совсем Java-вого Ruby — попробуйте Groovy, он практически так же лаконичен, как и subj
Да, посмотрю, хотя мне уже этап installation не нравится — как-то все заморочно, непортабельно, и криво:
> There is currently an issue where you cannot have spaces in the path where Groovy is installed under windows.
Позор. Не обрабатывать пробелы в именах файлов в 21 веке —это позор.
Есть еще какой-то Jruby, тоже гляну.
Да, посмотрю, хотя мне уже этап installation не нравится — как-то все заморочно, непортабельно, и криво:
> There is currently an issue where you cannot have spaces in the path where Groovy is installed under windows.
Позор. Не обрабатывать пробелы в именах файлов в 21 веке —это позор.
Есть еще какой-то Jruby, тоже гляну.
Если вы занимаетесь вебсайтами, то руби будет работать не медленнее чем РНР. А когда надо, то руби может быть гараздо быстрее (thin + capistrano или rails metal без БД держат несколько тысяч RPS).
Ну так мы договоримся до того, что Perl лучший язык.
Но если вы будете писать на нем слишком лаконично, то никто из вашей команды не поймет, а через полгода и сами забудете, что написали.
На мой взгляд золотая середина лаконичности — Python — такст очень короткий, но читается идеально.
Но если вы будете писать на нем слишком лаконично, то никто из вашей команды не поймет, а через полгода и сами забудете, что написали.
На мой взгляд золотая середина лаконичности — Python — такст очень короткий, но читается идеально.
> Но если вы будете писать на нем слишком лаконично, то никто из вашей команды не поймет, а через полгода и сами забудете, что написали.
Лаконичность — это когда массив создается таой строкой: array = []; (в ср-и с другими языками), это описано в правилах языка, так что не представляю как об этом можн забыть.
Лаконичность — это когда массив создается таой строкой: array = []; (в ср-и с другими языками), это описано в правилах языка, так что не представляю как об этом можн забыть.
Чрезмерная лаконичность это вот такие програмки:
Пока не выполнишь не поймешь, что это такое. Да уже поздно будет.
Это, конечно, гипербола. Но близкий к такому код в вашем проекте — это кошмар для команды, потому что при смене разработчика, новому придется долго вникать.
Вот за это я не люблю перл, что так каждый пишет как хочет, в итоге — горы нечитаемого и трудноподдерживаемого говна.
echo "test... test... test..." | perl -e '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see'Пока не выполнишь не поймешь, что это такое. Да уже поздно будет.
Это, конечно, гипербола. Но близкий к такому код в вашем проекте — это кошмар для команды, потому что при смене разработчика, новому придется долго вникать.
Вот за это я не люблю перл, что так каждый пишет как хочет, в итоге — горы нечитаемого и трудноподдерживаемого говна.
баян, и подписали бы что это rm -rf /. И невежливо постить без описания это дело.
Да, это очень старый известный баян. Поээтому не нуждается в подписи. Здесь он приведен как пример какое нечитаемое гавно может быть. Вот тут он детально разобран: ru.wikipedia.org/wiki/Perl
Я тоже не люблю Перл. Руби, поверьте, до такого не доходит, а массив и правда удобнее скобками писать, без ключевых слов (в яваскрипте к слову тоже так).
ну вот война религий началась…
Имхо, сравнивать ту же Java и PHP — это как сравнивать иномарку и жигули. Не пытаюсь разводить холивар, но лично для меня в PHP такое большое кол-во минусов, что писать на нем желания не имею с тех про как начал писать на Java.
Хотя хороший Java программист, к коим я себя никак отнести не могу, может найти много минусов в этой технологии. Но как-то там все логичнее, стройнее и красивее. И меньше былокодеров из-за более высокого уровня вхождения.
Хотя хороший Java программист, к коим я себя никак отнести не могу, может найти много минусов в этой технологии. Но как-то там все логичнее, стройнее и красивее. И меньше былокодеров из-за более высокого уровня вхождения.
НЛО прилетело и опубликовало эту надпись здесь
Когда я начал писать на Java, я постоянно видел насколько мне не хватает знаний языка и смежных технологий. Лезть в мануалы приходиться постоянно. Уже полгода пишу ней дома свой проект. До сих пор браузер с мануалами постоянно активизируется через alt+tab.
А на PHP написать средненький сайт пытается и новичок со стажем один месяц. Когда я начинал писать на нем, у меня не возникало ощущения катастрофической нехватки знаний.
И проблема тут отнюдь не в том, что я вырос как разработчик.
А на PHP написать средненький сайт пытается и новичок со стажем один месяц. Когда я начинал писать на нем, у меня не возникало ощущения катастрофической нехватки знаний.
И проблема тут отнюдь не в том, что я вырос как разработчик.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Я как работодатель страдаю от огромного кол-ва неадекватных пхпешников на рынке труда, которые не стоят и 10к рублей в месяц.
Вы бы видели какой недавно сайт сделал один сотрудник. Внешне — нормально, но внутри такой ужас… И он даже ни разу не задумался о том, что лучше отказаться от разработки, чем плодить кучу говна.
Понимаю, язык тут не причем. Но из-за легкости освоения, такие вот «кадры», уворовав в легкость разработки, оседают именно в нем.
Кстати, заметьте, проблему тупых разработчиков я обозначил только как одну из.
Вы бы видели какой недавно сайт сделал один сотрудник. Внешне — нормально, но внутри такой ужас… И он даже ни разу не задумался о том, что лучше отказаться от разработки, чем плодить кучу говна.
Понимаю, язык тут не причем. Но из-за легкости освоения, такие вот «кадры», уворовав в легкость разработки, оседают именно в нем.
Кстати, заметьте, проблему тупых разработчиков я обозначил только как одну из.
НЛО прилетело и опубликовало эту надпись здесь
И не говорите, сам тут пытался народ набрать. Это кошмар какой-то. Повезло что заинтересовался человек, с солидным уже стажем и ему интересно было поучаствовать не столько за деньги, сколько за опыт и интересность проекта.
Прав был Джоэл, говоря, что хороших программистов можно найти либо через личное знакомство, либо через отлов их еще на этапе обучения.
У вас в России с этим легче, уж поверьте. У нас тут вообще мрак — все сидят на аутсорсе и толковых больших проектов, требующих хороших знаний — единицы. В основном аутсорс это Java/C++. Мне повезло, по знакомству собственно и попал. И то знакомый мне 2-3 года в IRC'е помогал на #php канале с проблемами и глупыми вопросами, а сейчас свалил вообще в Испанию :)
Хотя вру, работал пол года в конторе, которая занималась системами управления предприятиями на PHP. Я к сожалению ушел, т.к. к тому времени я совсем слез с PHP4 (они только новые системы делали на PHP5), да и ездить приходилось далеко. Но делали толково и очень серьёзно, некоторые Java/.NET девелоперы позавидовали бы тем системам, которые они создали. А их фреймворк хочется до сих пор повторить, да вот только сил не хватит :)
Хотя вру, работал пол года в конторе, которая занималась системами управления предприятиями на PHP. Я к сожалению ушел, т.к. к тому времени я совсем слез с PHP4 (они только новые системы делали на PHP5), да и ездить приходилось далеко. Но делали толково и очень серьёзно, некоторые Java/.NET девелоперы позавидовали бы тем системам, которые они создали. А их фреймворк хочется до сих пор повторить, да вот только сил не хватит :)
Ну знаете ли, я вот 4-й год на PHP работаю, и до сих пор лажу в мануал хотя бы раз в день, постоянно его переодически перечитываю мануалы, читаю Internals — и знаете, за те 4 года работы с разными людьми (в том числе и так называемыми «зубрами») не считаю, что я знаю PHP на отлично. Потому что мне ещё учится и учится правильному PHP. А вообще знания конкретного языка — это не показатель. Важен весь пласт технологий и вообще базовое IT образование. Программистов на PHP хорошо если 5-10% от общей массы. Я программистом для себя буду тогда, когда у меня опыта лет 10 будет и я закончу ВО и щедро приправлю его большим кол-вом дополнительных знаний, как теоретических, так и практических.
Вообще любой программист без ВО по компьютерным наукам в любой области — это кодер. У нас к примеру в стране официально по законам программистом является лицо имеющее ВО по компьютерным наукам или его получающее. Остальное кодеры — низкоквалифицированная профессия. И правильно, хотя конечно в реальности каждый второй лобзик себя считает программистом, а как начинаешь спрашивать базовые вещи — сдуваются, потому что дальше CMS'ок не лазили.
Вообще любой программист без ВО по компьютерным наукам в любой области — это кодер. У нас к примеру в стране официально по законам программистом является лицо имеющее ВО по компьютерным наукам или его получающее. Остальное кодеры — низкоквалифицированная профессия. И правильно, хотя конечно в реальности каждый второй лобзик себя считает программистом, а как начинаешь спрашивать базовые вещи — сдуваются, потому что дальше CMS'ок не лазили.
У java выше порог вхождения, как результат быдлокодеров на ней меньше. Опять же в отличии от PHP java это не язык для веба. PHP больше именно для работы с веба, как только вылазим из этой песочницы все становится плохо.
Чем отличается язык для веба от языка не для веба? Мне вот кажется, что Java для веба даже больше подходит. Может, я просто вырос из сайтов аля «новости, фотогалерея, гостевая»?
В первую очередь php создавался для создания динамических веб-страниц. Отдельный CLI там появился намноого поздже. И ПО на php которые не занимаются именно этим раз два и обчелся. На java к примеру таких систем существенно больше.
SVN тоже создавался под лозунгом «улучшим CVS», но, почему-то, сейчас становится модным GIT, у которого лозунг «ни в коем случае не так, как в CVS»
Проблема в том, что неважно для чего создавался язык. Главное — что получилось. А в случае с PHP получился слабый язык с кривой и нелогичной стандартной библиотекой.
Если уж на то пошло, изначально PHP — PersonalHomePage, но никак не язык для веба:)
Я просто не понимаю как можно писать динамично развивающиеся веб приложения на языке, который:
— Не умеет нормально работать с кодировками (и не надо мне рассказывать про iconv — уже намучился с разными нюансами)
— Не имеет нормальных средств для мета программирования
— < тут пошли мелочи, которые меня тоже достают >
Проблема в том, что неважно для чего создавался язык. Главное — что получилось. А в случае с PHP получился слабый язык с кривой и нелогичной стандартной библиотекой.
Если уж на то пошло, изначально PHP — PersonalHomePage, но никак не язык для веба:)
Я просто не понимаю как можно писать динамично развивающиеся веб приложения на языке, который:
— Не умеет нормально работать с кодировками (и не надо мне рассказывать про iconv — уже намучился с разными нюансами)
— Не имеет нормальных средств для мета программирования
— < тут пошли мелочи, которые меня тоже достают >
но, почему-то, сейчас становится модным GIT, у которого лозунг «ни в коем случае не так, как в CVS»
Кроме него становится модным mercurial и bazaar. Становятся модными распределенные системы ревизии кода. И они становятся модным именно из-за своей распределенности.
Если уж на то пошло, изначально PHP — PersonalHomePage, но никак не язык для веба:)
А вы что Personal Home Page смотрели чем-то отличным от браузера? :)
Я просто не понимаю как можно писать динамично развивающиеся веб приложения на языке, который
Это все лечится костылями. Их там великое множество :)))
Про костыли… Расскажите мне как вы AOP на PHP будете делать.
Ситуация с замыканиями тоже забавная. Они, конечно, в 5.3 появились, но до Javascript все равно не дотягивают.
Пхпешники, которые ничего кроме него не знают, меня, конечно, будут минусовать, ну и пусть. Не я первый, не я последний:)
Ситуация с замыканиями тоже забавная. Они, конечно, в 5.3 появились, но до Javascript все равно не дотягивают.
Пхпешники, которые ничего кроме него не знают, меня, конечно, будут минусовать, ну и пусть. Не я первый, не я последний:)
Я это делать не буду. AOP как бе я лучше буду в java юзать :)
Вот так:
code.google.com/p/php-aop/
www.phpclasses.org/browse/package/3215.html
только сначала скажите, ЗАЧЕМ это в веб-приложениях?
code.google.com/p/php-aop/
www.phpclasses.org/browse/package/3215.html
только сначала скажите, ЗАЧЕМ это в веб-приложениях?
Для AOP модифицировать исходники. Увольте. Риски слишком большие.
Что значит зачем это в ВЕБ-приложениях? А зачем это не в веб приложениях? А зачем нужны события в программах?
В конце-концов о том, что такое AOP, где может быть полезно и т.п. расскажет гугл. Есть куча хороший статей, авторы которых умеют излагать свои мысли куда лучше меня.
Что значит зачем это в ВЕБ-приложениях? А зачем это не в веб приложениях? А зачем нужны события в программах?
В конце-концов о том, что такое AOP, где может быть полезно и т.п. расскажет гугл. Есть куча хороший статей, авторы которых умеют излагать свои мысли куда лучше меня.
А зачем оно так нужно, кстати? Я в примерах видел только логгирование или авторизацию, что в веб-приложениях можно сделать и без аспектов.
> Для AOP модифицировать исходники. Увольте. Риски слишком большие.
в каком месте Вы увидели модификацию исходников?
> В конце-концов о том, что такое AOP, где может быть полезно и т.п. расскажет гугл.
то есть с практической применимостью AOP лично Вы не знакомы. так и запишем: snob mode on ;-)
в каком месте Вы увидели модификацию исходников?
> В конце-концов о том, что такое AOP, где может быть полезно и т.п. расскажет гугл.
то есть с практической применимостью AOP лично Вы не знакомы. так и запишем: snob mode on ;-)
Мне было не лень открыть первую ссылку и потратить 10 минут на изучения кода. А вам?
AOP в PHP возможно тремя вариантами (скажу спасибо, если кто дополнит):
— Получать все экземпляры классов через специфическую фактори, либо сделать какой-нибудь IoC контейнер. Серьезные проблемы, которые можно решить только соглашениями о кодировании, все равно остаются
— Использовать расширения, позволяющие модифицировать классы/функции. Нестабильно, не поддерживается байт-код кешерами, не распространено на хостингах
— Модификация исходников, склад модифицированных файлов в отдельную директорию и их подключение когда надо. Каждый раз проверять по времени изменения файла не надо ли перестроить эти самые исходники.
В этом случае мы избегаем минусов двух первых способов, но приобретаем либо зависимость от расширения tokenizer (не на всех хостингах есть), либо от своего парсера, то не является надежным.
AOP в PHP возможно тремя вариантами (скажу спасибо, если кто дополнит):
— Получать все экземпляры классов через специфическую фактори, либо сделать какой-нибудь IoC контейнер. Серьезные проблемы, которые можно решить только соглашениями о кодировании, все равно остаются
— Использовать расширения, позволяющие модифицировать классы/функции. Нестабильно, не поддерживается байт-код кешерами, не распространено на хостингах
— Модификация исходников, склад модифицированных файлов в отдельную директорию и их подключение когда надо. Каждый раз проверять по времени изменения файла не надо ли перестроить эти самые исходники.
В этом случае мы избегаем минусов двух первых способов, но приобретаем либо зависимость от расширения tokenizer (не на всех хостингах есть), либо от своего парсера, то не является надежным.
Эээ. Как зачем? Использовать. Просто у java слегка другая модель для веба. Она ближе к FastCGI т.е. сервлет запускается один раз и работает пока ему не пошлют сигнал об остановке.
Понимание «зачем» приходит, когда проект вырастает далеко за рамки простого «сайтика» и появляется необходимость думать о транзакциях или юнит-тестах.
А раньше она не появляется? Простые «сайтики» пускай будут бажные и без целостной БД?
В смысле? Вы меня спрашиваете, почему некоторые полагают, что для небольших сайтиков можно не заморачиваться целостностью БД (или копипастить по коду управление транзакциями и отказами)?
Полагаю, что так быстрее. ПРОФИТ!
Полагаю, что так быстрее. ПРОФИТ!
Зачем копипастить? повторное использование кода не зря придумали
Как же вы организуете управление транзакциями (на различных уровнях приложения), без «размазывания» однотипного кода по всему приложения и без AOP?
Зависит от задачи поставленной и перспектив развития системы. Простейший способ, даже без всякого ООП, который приходит в голову — вызывать запросы к БД с параметром TransactionMode, указывающим нужно ли начинать новую транзакцию перед запросом, коммитить её после или просто выполнить запрос (еснно при всех вариантах с генерацией исключения и откате при ошибке)
И вы находите такой подход уместным для действительно больших систем (обсуждение ведь с этого началось)?
А можно посмотреть примеры живых проектов, которые построены по такому принципу? Сколько в них задействовано разработчиков и какое у вас соотношение расходуемого времени на багфикс/импрувы/рефакторинг?
А можно посмотреть примеры живых проектов, которые построены по такому принципу? Сколько в них задействовано разработчиков и какое у вас соотношение расходуемого времени на багфикс/импрувы/рефакторинг?
Такой подход я нахожу (находил вернее будет сказано) уместным для систем уровня «новости, галерея, комменты» в процедурном стиле практически без перспектив развития. Уж лучше так, чем копипастить повторяющиeся try catch или вообще откатывать операции с БД «вручную».
Мои живые проекты в интранете (информационная система для клиники, система бронирования для гостиницы), далеко не хайлоад, я единственный разработчик, но поверьте на слово, что там нет кучи повторяющегося кода или незавершенных транзакций с БД. Больше всего времени, пожалуй (точную статистику не веду), уходит на рефакторинг с целью избавления от повторяющегося кода, если под багфиксами понимать исправление явных ошибок, когда пользователи «генерируют» баг-репорты.
Не хочу сказать, что я супер-пупер гуру в PHP и Ruby, но PHP мой основной язык разработки еще с тех времен, когда PHP4 на российских хостингах днем с огнем не найти было. С Ruby знаком недавно, меня он поразил своей элегантностью, красотой и т. п., но вот повода применить его на практике не встречал. Скорее всего, человек активно использующий руби много лет и сможет написать на нем что-то быстрее, чем я, но уж точно на PHP я напишу это что-то быстрее, чем если буду писать на Ruby и мне довольно сложно будет объяснить заказчику, почему сроки разработки выросли. Не говоря о том, что гуру Ruby назовут мой код говнокодом :) потому что мало знать собственно язык, нужно знать его библиотеки и фреймворки, особенности трансляторов и т. д., и т. п., а главное их активно использовать, а я, пытаясь сократить сроки, буду писать в PHP-стиле, так что мой Ruby код можно будет перевести в PHP чуть ли не через поиск и замену в редакторе.
Мои живые проекты в интранете (информационная система для клиники, система бронирования для гостиницы), далеко не хайлоад, я единственный разработчик, но поверьте на слово, что там нет кучи повторяющегося кода или незавершенных транзакций с БД. Больше всего времени, пожалуй (точную статистику не веду), уходит на рефакторинг с целью избавления от повторяющегося кода, если под багфиксами понимать исправление явных ошибок, когда пользователи «генерируют» баг-репорты.
Не хочу сказать, что я супер-пупер гуру в PHP и Ruby, но PHP мой основной язык разработки еще с тех времен, когда PHP4 на российских хостингах днем с огнем не найти было. С Ruby знаком недавно, меня он поразил своей элегантностью, красотой и т. п., но вот повода применить его на практике не встречал. Скорее всего, человек активно использующий руби много лет и сможет написать на нем что-то быстрее, чем я, но уж точно на PHP я напишу это что-то быстрее, чем если буду писать на Ruby и мне довольно сложно будет объяснить заказчику, почему сроки разработки выросли. Не говоря о том, что гуру Ruby назовут мой код говнокодом :) потому что мало знать собственно язык, нужно знать его библиотеки и фреймворки, особенности трансляторов и т. д., и т. п., а главное их активно использовать, а я, пытаясь сократить сроки, буду писать в PHP-стиле, так что мой Ruby код можно будет перевести в PHP чуть ли не через поиск и замену в редакторе.
Спасибо за развернутый ответ.
Я пытался сказать о том, что использование AOP может позволить прозрачно разделить описание бизнес-объектов и таких общих вещей как управление транзакциями. Поверьте, в крупных долгосрочных проектах, где занято несколько разработчиков, а бизнес-объекты хочется переиспользовать между проектами, это очень упрощает жизнь.
При этом, как правило, все настройки этого транзакционного управления собираются в одном файле. И не надо оглядываться на крики в духе «ааа, килобайты иксэмэля, мы все умрём», потому что современние IDE с подсказками и автокомплитом превращают его редактирование в простеишую задачу.
Я пытался сказать о том, что использование AOP может позволить прозрачно разделить описание бизнес-объектов и таких общих вещей как управление транзакциями. Поверьте, в крупных долгосрочных проектах, где занято несколько разработчиков, а бизнес-объекты хочется переиспользовать между проектами, это очень упрощает жизнь.
При этом, как правило, все настройки этого транзакционного управления собираются в одном файле. И не надо оглядываться на крики в духе «ааа, килобайты иксэмэля, мы все умрём», потому что современние IDE с подсказками и автокомплитом превращают его редактирование в простеишую задачу.
А чем ваше AOP поможет то? Оно только позволяет воткнуть что-то перед/после вызова функции и все.
Правильное решение должно выглядеть как-то так, имхо:
db.transaction { |db|
db.query1();
db.query2();
…
}
Правильное решение должно выглядеть как-то так, имхо:
db.transaction { |db|
db.query1();
db.query2();
…
}
> — Не умеет нормально работать с кодировками (и не надо мне рассказывать про iconv — уже намучился с разными нюансами)
Неправда. PHP может работать как со строками *символов* в разных кодировках (функции mb_*()), так и со строками из байтов (без кодировки, функции типа str_*()). Использование вторых иногда может быть выгоднее с т.зр. производительноти.
Зачем вы использовали iconv() — искренне не понимаю. Вы строите сервис по перекодировке текста? Или вы этот кривой подход из Явы пытаетесь на PHP перенести?))
UTF-8 в PHP поддерживается замечательно.
> — Не имеет нормальных средств для мета программирования
Вам аннотаций не хватает что ли? А так ли они нужны?
> — < тут пошли мелочи, которые меня тоже достают >
Повторю свой предыдущий комментарий: по количеству лишних букв в коде: Ява многословней php, php многсловней Руби. Посмотрите на Руби — вообще расхочется другими языками пользоваться.
Неправда. PHP может работать как со строками *символов* в разных кодировках (функции mb_*()), так и со строками из байтов (без кодировки, функции типа str_*()). Использование вторых иногда может быть выгоднее с т.зр. производительноти.
Зачем вы использовали iconv() — искренне не понимаю. Вы строите сервис по перекодировке текста? Или вы этот кривой подход из Явы пытаетесь на PHP перенести?))
UTF-8 в PHP поддерживается замечательно.
> — Не имеет нормальных средств для мета программирования
Вам аннотаций не хватает что ли? А так ли они нужны?
> — < тут пошли мелочи, которые меня тоже достают >
Повторю свой предыдущий комментарий: по количеству лишних букв в коде: Ява многословней php, php многсловней Руби. Посмотрите на Руби — вообще расхочется другими языками пользоваться.
Расширение mbstring я имел ввиду когда писал про iconv. Неправильно выразился, признаю.
Вот есть у вас внутри программы строка. В какой она кодировке? В Java все строки будут в одной. А в PHP какой угодно. Отслеживать это — морока страшная.
Да и невозможность явно указать в какой кодировке происходит ввод информации — тоже минус.
Кстати, стандартные функции str_* заменяются на соответствующие из mbstring при нужных настройках PHP.
Про UTF-8. А символы порядка байтов тоже поддерживаются? А с регулярками как? Постоянно флаг указывать? :) Еще MySql до сравнительного недавнего времени с utf-8 толком работать не мог.
Да и не все функции из стандартной библиотеки заменяются на аналоги из расширения mbstring.
А я и нигде не писал про то, что Java — лаконичен. Это не так. Он логичнее, стройнее, хз как описать. Там нет приколов типа «0» == false.
Я, вполне возможно, поливал бы Java таким же кол-вом грязи, если бы знал Ruby. К сожалению, это не так.
В каждом инструменте я пытаюсь искать не только плюсы, но и минусы. В Java для меня такие уже есть. Но я слишком плохо ее знаю, чтобы их обсуждать. А вот PHP знаю хорошо. На тему его плюсов и минусов говорить готов.
Вот есть у вас внутри программы строка. В какой она кодировке? В Java все строки будут в одной. А в PHP какой угодно. Отслеживать это — морока страшная.
Да и невозможность явно указать в какой кодировке происходит ввод информации — тоже минус.
Кстати, стандартные функции str_* заменяются на соответствующие из mbstring при нужных настройках PHP.
Про UTF-8. А символы порядка байтов тоже поддерживаются? А с регулярками как? Постоянно флаг указывать? :) Еще MySql до сравнительного недавнего времени с utf-8 толком работать не мог.
Да и не все функции из стандартной библиотеки заменяются на аналоги из расширения mbstring.
А я и нигде не писал про то, что Java — лаконичен. Это не так. Он логичнее, стройнее, хз как описать. Там нет приколов типа «0» == false.
Я, вполне возможно, поливал бы Java таким же кол-вом грязи, если бы знал Ruby. К сожалению, это не так.
В каждом инструменте я пытаюсь искать не только плюсы, но и минусы. В Java для меня такие уже есть. Но я слишком плохо ее знаю, чтобы их обсуждать. А вот PHP знаю хорошо. На тему его плюсов и минусов говорить готов.
Ваша информация устарела. Если у вас страницы в utf-8 и код всех файлов php в utf-8, то прийдет вам строка только в utf-8, и никак не иначе.
Тоже самое с регулярками. Вообще нигде не использую флаг /u
С mySQL и utf-8 тоже никаких проблем нет, причем давненько.
С 2005 года перешел на utf-8 в проектах и еще не видел особых проблем с кодировками в PHP. Проблемы возникают с кодировками только у нубов, как показывает моя практика.
Тоже самое с регулярками. Вообще нигде не использую флаг /u
С mySQL и utf-8 тоже никаких проблем нет, причем давненько.
С 2005 года перешел на utf-8 в проектах и еще не видел особых проблем с кодировками в PHP. Проблемы возникают с кодировками только у нубов, как показывает моя практика.
А файлы вы как читаете? Можете указать кодировку файла один раз при создании потока чтения?
Про маркер порядка байтов в начале файла что же не возразили?
Проблемы у MySql с utf-8 были. Давно. Сейчас это выражается в том, что до сих пор используют win1251. Это, конечно, — не единственная причина, но свой небольшой вклад тоже внесла.
Я не говорю что все ужасно, просто не жить. Я говорю о том, что танцев с бубном не избежать. Со временем к ним привыкаешь, пишешь свои костыли и т.п., но это не значит, что теперь не надо трезво смотреть на вещи.
Про маркер порядка байтов в начале файла что же не возразили?
Проблемы у MySql с utf-8 были. Давно. Сейчас это выражается в том, что до сих пор используют win1251. Это, конечно, — не единственная причина, но свой небольшой вклад тоже внесла.
Я не говорю что все ужасно, просто не жить. Я говорю о том, что танцев с бубном не избежать. Со временем к ним привыкаешь, пишешь свои костыли и т.п., но это не значит, что теперь не надо трезво смотреть на вещи.
Да вы же сударь упоротый! Вы что, место на диске экономите, создавая файлы в разной кодировке?? Если серьезно — решение — простейший класс-обертка для чтения файлов в разных кодировках через iconv() — пишется за полчаса максимум со всеми подводными камнями (подводные камни будут, если читать файл не строками, а блоками фикс. размера — может ломаться utf-8).
> Я не говорю что все ужасно, просто не жить. Я говорю о том, что танцев с бубном не избежать.
Подозреваю, что вы просто не очень разбираетесь в кодировках, не?
> Я не говорю что все ужасно, просто не жить. Я говорю о том, что танцев с бубном не избежать.
Подозреваю, что вы просто не очень разбираетесь в кодировках, не?
Знаете, я сайты для людей создаю. А они могут захотеть слать файлы в любой кодировке с возможностью указать ее. Именно так думали создатели OpenOffice. А вот в MS Office файлы открываются только в кодировке винды.
Безусловно, можно сделать обертку. Можно даже сделать ее так, чтобы читать все это через потоки(под этим и подразумевались танцы с бубном). Но это разве отменяет то, что в языке не заложена работа с кодировками?
Кстати, расскажите как вы обертки для чтения из сокетов или иных мест писать будете.
Так что пишите обертки и дальше, а я выучу другой язык, где таких проблем нет. А в качестве бонуса получу возможность рассматривать проблемы с разных сторон и искать более подходящие технологии для решения своих задач.
Про знания о кодировках и пытаться возражать ничего не буду.
Безусловно, можно сделать обертку. Можно даже сделать ее так, чтобы читать все это через потоки(под этим и подразумевались танцы с бубном). Но это разве отменяет то, что в языке не заложена работа с кодировками?
Кстати, расскажите как вы обертки для чтения из сокетов или иных мест писать будете.
Так что пишите обертки и дальше, а я выучу другой язык, где таких проблем нет. А в качестве бонуса получу возможность рассматривать проблемы с разных сторон и искать более подходящие технологии для решения своих задач.
Про знания о кодировках и пытаться возражать ничего не буду.
Чем перешел вам дорогу BOM?
Про него не отписал только потому, что не вижу с ним проблем — многие IDE и редакторы кода позволяют удалять эту маркировку.
Кроме того, если вы используете шаблонизатор — вы можете сами написать префетчинг с удалением BOM при чтении PHP-файла.
Решений с данной проблемой — достаточно много, причем оно один раз делается и забывается. «Взула и забула»
Вы же это описали чуть ли не проблемой, которая мешает вам каждый день программировать на PHP и хорошо спать.
Проблем у мускуля и пхп с utf-8 нет уже лет 5 как. Вы бы еще древнее проблему вспомнили. Например ту, что в пхп4 ООП каличное. Это будет аналогично.
Не увидел от вас достойной аргументации пока что, что ж такого плохого в пхп. Да, я видел много статей, где авторы распинались и плювались слюной по поводу пхп и указывая, чем язык Х лучше. При ближайшем рассмотрении оказывалось, что авторы уже давно не видели пхп в глаза и притензии у них к языку — 3-4 летней давности устаревания.
Вот если бы вы мне назвали то, что функции названы как попало в ядре — я бы с вами согласился, т.к. это действительно недостаток.
А вот эти плюшки по типу BOM или проблемы с юникодом (которые ну совсем не проблемы при ближайшем рассмотрении) — это не то, о чем стоит рассказывать. Юникод уже в 6.0 будет полноценный, а вот с функциями так пока ничего и не решили, что очень жаль.
Про него не отписал только потому, что не вижу с ним проблем — многие IDE и редакторы кода позволяют удалять эту маркировку.
Кроме того, если вы используете шаблонизатор — вы можете сами написать префетчинг с удалением BOM при чтении PHP-файла.
Решений с данной проблемой — достаточно много, причем оно один раз делается и забывается. «Взула и забула»
Вы же это описали чуть ли не проблемой, которая мешает вам каждый день программировать на PHP и хорошо спать.
Проблем у мускуля и пхп с utf-8 нет уже лет 5 как. Вы бы еще древнее проблему вспомнили. Например ту, что в пхп4 ООП каличное. Это будет аналогично.
Не увидел от вас достойной аргументации пока что, что ж такого плохого в пхп. Да, я видел много статей, где авторы распинались и плювались слюной по поводу пхп и указывая, чем язык Х лучше. При ближайшем рассмотрении оказывалось, что авторы уже давно не видели пхп в глаза и притензии у них к языку — 3-4 летней давности устаревания.
Вот если бы вы мне назвали то, что функции названы как попало в ядре — я бы с вами согласился, т.к. это действительно недостаток.
А вот эти плюшки по типу BOM или проблемы с юникодом (которые ну совсем не проблемы при ближайшем рассмотрении) — это не то, о чем стоит рассказывать. Юникод уже в 6.0 будет полноценный, а вот с функциями так пока ничего и не решили, что очень жаль.
1. BOM
Сколько времени у вас уйдет на отладку бага с этим? Вы ведь, похоже, даже не знали о том, что это есть такое.
У меня все IDE сохраняют файлы в UTF-8 без BOM. Но ведь коллективная разработка никуда не делась, верно?
2. Старые версии
Вы про эти проблемы расскажите создателям Битрикса, которые до сих пор php4 поддерживают. К счастью, в их число не вхожу (а то стыдно было бы)
К тому же стереотипы исчезают только со временем. Опять же вспоминаем про коллективную разработку.
3. Про кривую стандартную библиотеку было написано много комментариями выше
4. Кстати, о мета программирование
В той же Java оно отнюдь не ограничивается аннотациями. Чего только стоит модификация байт-кода в памяти.
AOP в веб разработке может быть очень удобно. Но PHP не дает никаких средств для реализации аспектов. А расширения, которые позволяют это, несовместимы с кешерами байт-кода.
5. О PHP6
Во-первых, выйдет он не скоро.
Во-вторых, еще дольше он не будет распространен на хостингах
В-третьих, я не рискну сразу на шестую версию переходить, чтобы потом баги на продакшене отлавливать.
— Проблемы важны не тогда, когда все нормально.
Проблемы важны, когда завтра сдача проекта, а у вас вылез баг неожиданный.
Проблемы важны, когда у вас денег много на сайте завязано. Каждая маленькая проблема важна будет.
Вот когда вы будете отлавливать в срочно порядке какую-нибудь неожиданность, тогда вспомните много раз создателей PHP. Мне хватило бреда, что «0» == false (строка с символом 0).
Сколько времени у вас уйдет на отладку бага с этим? Вы ведь, похоже, даже не знали о том, что это есть такое.
У меня все IDE сохраняют файлы в UTF-8 без BOM. Но ведь коллективная разработка никуда не делась, верно?
2. Старые версии
Вы про эти проблемы расскажите создателям Битрикса, которые до сих пор php4 поддерживают. К счастью, в их число не вхожу (а то стыдно было бы)
К тому же стереотипы исчезают только со временем. Опять же вспоминаем про коллективную разработку.
3. Про кривую стандартную библиотеку было написано много комментариями выше
4. Кстати, о мета программирование
В той же Java оно отнюдь не ограничивается аннотациями. Чего только стоит модификация байт-кода в памяти.
AOP в веб разработке может быть очень удобно. Но PHP не дает никаких средств для реализации аспектов. А расширения, которые позволяют это, несовместимы с кешерами байт-кода.
5. О PHP6
Во-первых, выйдет он не скоро.
Во-вторых, еще дольше он не будет распространен на хостингах
В-третьих, я не рискну сразу на шестую версию переходить, чтобы потом баги на продакшене отлавливать.
— Проблемы важны не тогда, когда все нормально.
Проблемы важны, когда завтра сдача проекта, а у вас вылез баг неожиданный.
Проблемы важны, когда у вас денег много на сайте завязано. Каждая маленькая проблема важна будет.
Вот когда вы будете отлавливать в срочно порядке какую-нибудь неожиданность, тогда вспомните много раз создателей PHP. Мне хватило бреда, что «0» == false (строка с символом 0).
1. Я знаю про BOM и выше написал даже пути решения вопроса. Вы не внимательны. У меня нисколько не занимает времени вопрос BOM.
На BOM попадаются только новички в PHP. И поделом, пусть учатся.
2. Мне всеравно на недопроекты по типу Битрикса и еже с ними, которые поддерживают до сих пор 4, ущербную ветку PHP. Это их личные проблемы, а не разработчиков языка. Пусть поддерживают и выгребают новые и новые грабли.
Вы еще попросите Microsoft поддерживать IE4.0, т.к. отделение в Зулуссии до сих пор сайты верстает с поддержкой IE4.0
3. Согласен, но ведь это основная проблема, поэтому с нее и надо начинать, а не с бомов и кодировок.
А то, что пхп — слаботипизированный язык — вас тоже не смущает?
4. Думаю, что до тех пор, как АОР станет полезным и реально и реально удобным для применения на веб-проектах — создатели PHP что-то придумают. Пока в веб-разработке это не столь необходимо, чтобы мыслить аспектами.
5. Я к тому, что пхп6 решит проблемы, для которых вы сейчас стесняетесь применять нормальные решения. И это далеко не костыли.
Рисковать ставить или не ставить — дело каждого. Мне пока пхп6 не нужен, т.к. проблем с юникодом вообще не ощущаю, либо ощущаю мало и тут же решаю, т.к. чаще всего все решается через mb_* и прочие вещи.
>Мне хватило бреда, что «0» == false (строка с символом 0).
Чем же это бред? PHP слаботипизированный язык, поэтому следовало применять не ==, а ===. Ошибка на уровне детсада, не знаю, что вас тут удивило.
Видимо раздел про типы и их приведение в PHP — вы не осилили.
Это не неожиданность, а нежелание читать документацию к языку.
На BOM попадаются только новички в PHP. И поделом, пусть учатся.
2. Мне всеравно на недопроекты по типу Битрикса и еже с ними, которые поддерживают до сих пор 4, ущербную ветку PHP. Это их личные проблемы, а не разработчиков языка. Пусть поддерживают и выгребают новые и новые грабли.
Вы еще попросите Microsoft поддерживать IE4.0, т.к. отделение в Зулуссии до сих пор сайты верстает с поддержкой IE4.0
3. Согласен, но ведь это основная проблема, поэтому с нее и надо начинать, а не с бомов и кодировок.
А то, что пхп — слаботипизированный язык — вас тоже не смущает?
4. Думаю, что до тех пор, как АОР станет полезным и реально и реально удобным для применения на веб-проектах — создатели PHP что-то придумают. Пока в веб-разработке это не столь необходимо, чтобы мыслить аспектами.
5. Я к тому, что пхп6 решит проблемы, для которых вы сейчас стесняетесь применять нормальные решения. И это далеко не костыли.
Рисковать ставить или не ставить — дело каждого. Мне пока пхп6 не нужен, т.к. проблем с юникодом вообще не ощущаю, либо ощущаю мало и тут же решаю, т.к. чаще всего все решается через mb_* и прочие вещи.
>Мне хватило бреда, что «0» == false (строка с символом 0).
Чем же это бред? PHP слаботипизированный язык, поэтому следовало применять не ==, а ===. Ошибка на уровне детсада, не знаю, что вас тут удивило.
Видимо раздел про типы и их приведение в PHP — вы не осилили.
Это не неожиданность, а нежелание читать документацию к языку.
1. Перепутал вас с другим юзером, прошу прощения.
2. Придет заказчик и скажет: «плачу много бабла, чтобы вы поправили баги на моем сайте, написанном на php4». Вы ему откажите?
3. Об этом я написал выше, но поскольку возразить мне было нечего, то ярые фанаты PHP стали просто ставить минусы:):)
Я тоже не ощущая проблему с юникодом. Потому что на кривой PHP было написано расширение, немного его выпрямляющее — mbstring.
Но проблемы ощущаются в мелочах. И на этих самых мелочах идут потери времени.
Про «0» == false. Это такой же бред, как и разделение пространства имен через "\". Это банально непривычно.
Почему в юзабилити есть понятие user experience, а в языках программирования нету? Я в кружок программирования пошел с 7 класса. Успел поразвлекаться с кучей языков. Зачем создателям PHP было городить такие нюансы?
Почему обычно строку к логическому типу преобразовывают по длине (пустая строка — false и наоборот), а в PHP — по-другому?
2. Придет заказчик и скажет: «плачу много бабла, чтобы вы поправили баги на моем сайте, написанном на php4». Вы ему откажите?
3. Об этом я написал выше, но поскольку возразить мне было нечего, то ярые фанаты PHP стали просто ставить минусы:):)
Я тоже не ощущая проблему с юникодом. Потому что на кривой PHP было написано расширение, немного его выпрямляющее — mbstring.
Но проблемы ощущаются в мелочах. И на этих самых мелочах идут потери времени.
Про «0» == false. Это такой же бред, как и разделение пространства имен через "\". Это банально непривычно.
Почему в юзабилити есть понятие user experience, а в языках программирования нету? Я в кружок программирования пошел с 7 класса. Успел поразвлекаться с кучей языков. Зачем создателям PHP было городить такие нюансы?
Почему обычно строку к логическому типу преобразовывают по длине (пустая строка — false и наоборот), а в PHP — по-другому?
1. Принято, бывает. Но вы так и не пояснили, что ж такого мерзкого в BOM и чем же это большая проблема. Либо я чего-то не понимаю, либо эта проблема не стоит выеденного яйца.
2. Естественно откажу. Более того — я его отправлю к тому, кто писал ему этот проект. У меня хватает работы, чтобы еще копаться в гавнокоде заказчика, написанном непонятно кем и непонятно когда. Это его проблемы, а не мои. А деньги тут не главное. Главное получать удовольствие от своей работы, а не работать как раб только за деньги.
3. Что тут можно сказать. Троллей тут хватает. Я люблю PHP, я знаю его недостатки и достоинства. Это не повод пинать инакомыслящих.
Почему и зачем начали городить огороды — я не знаю, это вопрос не ко мне. PHP довольно старый язык, очень динамично развивавшийся. Язык, который был призван строить простые формы на сайте и из которого сделали ИНСТРУМЕНТ для создания веб-проектов и веб-приложений.
История языка прямо говорит о том, что у разработчиков не было достаточно времени на проектирование, им нужен был рынок, т.к. он фактически был пуст, в вебе не было на тот момент кроме перла ничего для веб-разработки (си++/с не берем во внимание, как и SSI, т.к. это извращения под веб).
Поэтому за быстрый взлет приходится расплачиваться несовершенностью архитектуры. Но я уверен, что многие вещи — будут исправлены. Впрочем это уже видно еще с миграции на пхп5.
Возможно авторам не хватало самим опыта. Причин может быть миллион.
2. Естественно откажу. Более того — я его отправлю к тому, кто писал ему этот проект. У меня хватает работы, чтобы еще копаться в гавнокоде заказчика, написанном непонятно кем и непонятно когда. Это его проблемы, а не мои. А деньги тут не главное. Главное получать удовольствие от своей работы, а не работать как раб только за деньги.
3. Что тут можно сказать. Троллей тут хватает. Я люблю PHP, я знаю его недостатки и достоинства. Это не повод пинать инакомыслящих.
Почему и зачем начали городить огороды — я не знаю, это вопрос не ко мне. PHP довольно старый язык, очень динамично развивавшийся. Язык, который был призван строить простые формы на сайте и из которого сделали ИНСТРУМЕНТ для создания веб-проектов и веб-приложений.
История языка прямо говорит о том, что у разработчиков не было достаточно времени на проектирование, им нужен был рынок, т.к. он фактически был пуст, в вебе не было на тот момент кроме перла ничего для веб-разработки (си++/с не берем во внимание, как и SSI, т.к. это извращения под веб).
Поэтому за быстрый взлет приходится расплачиваться несовершенностью архитектуры. Но я уверен, что многие вещи — будут исправлены. Впрочем это уже видно еще с миграции на пхп5.
Возможно авторам не хватало самим опыта. Причин может быть миллион.
С причинами полностью согласен.
Но это все равно не отменяет того факта, что PHP — отнюдь не лучший в своей области. На данный момент — точно.
Тем не менее, из-за его популярности, есть куча разработчиков, которая смогла осилить только PHP и считают что лучше ничего нет.
ЗЫ: Ни в коем случае не буду отрицать, для каких-то задач PHP подходит хорошо. И с точки зрения маркетинга он хорош — огромная распространенность на хостингах.
Но это все равно не отменяет того факта, что PHP — отнюдь не лучший в своей области. На данный момент — точно.
Тем не менее, из-за его популярности, есть куча разработчиков, которая смогла осилить только PHP и считают что лучше ничего нет.
ЗЫ: Ни в коем случае не буду отрицать, для каких-то задач PHP подходит хорошо. И с точки зрения маркетинга он хорош — огромная распространенность на хостингах.
> что ж такого мерзкого в BOM
То, что он невидим и иногда вставляется редакторами по умолчанию. Сам помню, как в одном из php-файлов оказался BOM и из-за этого картинка, генерируемая в php, в одном браузере отображалась, а в другом — нет. Искать причину пришлось долго :)
То, что он невидим и иногда вставляется редакторами по умолчанию. Сам помню, как в одном из php-файлов оказался BOM и из-за этого картинка, генерируемая в php, в одном браузере отображалась, а в другом — нет. Искать причину пришлось долго :)
> Если у вас страницы в utf-8 и код всех файлов php в utf-8, то прийдет вам строка только в utf-8
— Код файлов php как раз не обязательно должен быть в utf-8. Пример — вордпресс
— Код файлов php как раз не обязательно должен быть в utf-8. Пример — вордпресс
> Вот есть у вас внутри программы строка. В какой она кодировке?
В utf-8 очевидно. Поскольку разрабатывемые мной сайты обычно поддерживают русский язык, использовать 8-битные кодировки не вижу смысла. А вообще, у меня есть параметр в конфиге charset (вдруг завтра война и срочно придется менять кодировку).
> А в PHP какой угодно. Отслеживать это — морока страшная.
Ну тут можно схитрить, сказав, наоброт, php дает разработчику свободу выбора, просто выбрать надо сразу и не пытаться писать часть исходников в cp1251, а другую — в CJK к примеру. Юзайте utf-8 и проблем не будет.
> Кстати, стандартные функции str_* заменяются на соответствующие из mbstring при нужных настройках PHP.
Что создает двусмысленность, глядя на исходники не поймешь, что за функция использована, это как раз дурацкий подход.
> Да и невозможность явно указать в какой кодировке происходит ввод информации — тоже минус.
Мы говорим про веб-приложения? Так есть такой HTTP-заголовок Content-Type, в нем указывается кодировка страницы. Формы с такой страницы отправляются в той же кодировке вроде. Если вы используете utf-8 — перекодировки не нужны.
В MySQL есть команда SET NAMES utf8; (именно так, utf-8 не прокатит).
> А символы порядка байтов тоже поддерживаются?
Не сталкивался (( Они просто передаются на вызод программы в неизменном виде, так что это зависит скорее от браузера.
> А с регулярками как? Постоянно флаг указывать? :)
Увы ((. Это все же влияет на производительность.
> Я, вполне возможно, поливал бы Java таким же кол-вом грязи, если бы знал Ruby. К сожалению, это не так.
Вот тут я написал с примерами, почему Руби удобнее в плане синтаксиса: habrahabr.ru/blogs/webdev/74589/?reply_to=2160114#comment_2159965, посмотрите пример с реализацией транзакций.
В utf-8 очевидно. Поскольку разрабатывемые мной сайты обычно поддерживают русский язык, использовать 8-битные кодировки не вижу смысла. А вообще, у меня есть параметр в конфиге charset (вдруг завтра война и срочно придется менять кодировку).
> А в PHP какой угодно. Отслеживать это — морока страшная.
Ну тут можно схитрить, сказав, наоброт, php дает разработчику свободу выбора, просто выбрать надо сразу и не пытаться писать часть исходников в cp1251, а другую — в CJK к примеру. Юзайте utf-8 и проблем не будет.
> Кстати, стандартные функции str_* заменяются на соответствующие из mbstring при нужных настройках PHP.
Что создает двусмысленность, глядя на исходники не поймешь, что за функция использована, это как раз дурацкий подход.
> Да и невозможность явно указать в какой кодировке происходит ввод информации — тоже минус.
Мы говорим про веб-приложения? Так есть такой HTTP-заголовок Content-Type, в нем указывается кодировка страницы. Формы с такой страницы отправляются в той же кодировке вроде. Если вы используете utf-8 — перекодировки не нужны.
В MySQL есть команда SET NAMES utf8; (именно так, utf-8 не прокатит).
> А символы порядка байтов тоже поддерживаются?
Не сталкивался (( Они просто передаются на вызод программы в неизменном виде, так что это зависит скорее от браузера.
> А с регулярками как? Постоянно флаг указывать? :)
Увы ((. Это все же влияет на производительность.
> Я, вполне возможно, поливал бы Java таким же кол-вом грязи, если бы знал Ruby. К сожалению, это не так.
Вот тут я написал с примерами, почему Руби удобнее в плане синтаксиса: habrahabr.ru/blogs/webdev/74589/?reply_to=2160114#comment_2159965, посмотрите пример с реализацией транзакций.
Про ввод информации ответил выше. Это может быть не только HTTP запрос, но и чтение файла, сокеты, shared memory и еще много всего.
Про BOM (маркер порядка байтов) посмотрите дату этого бага: bugs.php.net/bug.php?id=22108
Мне понравился ваш пример с Ruby. Сейчас я хочу изучить какой-нибудь функциональный язык. На данный момент — Lisp.
Про BOM (маркер порядка байтов) посмотрите дату этого бага: bugs.php.net/bug.php?id=22108
Мне понравился ваш пример с Ruby. Сейчас я хочу изучить какой-нибудь функциональный язык. На данный момент — Lisp.
> Про BOM (маркер порядка байтов) посмотрите дату этого бага: bugs.php.net/bug.php?id=22108
Сталкивался сам, поверьте, злило, но сторого говоря. в utf-8 BOM не нужен — он сделан для отличия Big Endian от Low Endian UTF-16 (спасибо идиотам, которые придумали несколько юникодов сразу). Отключите у себя в редакторе вставку BOM и забудьте об этой проблеме.
> Про ввод информации ответил выше. Это может быть не только HTTP запрос, но и чтение файла, сокеты, shared memory и еще много всего.
Если вы используете разные кодировки для разынх компонент приложения — проблемы вам гарантированы в любом языке, хотя бы потому, что наборы символов в разных кодировках разные и не всегда можно без потерь перевести из одной в другую. Бросайте эту дурь, или пишите обертки для перекодировки, если не можете.
> Мне понравился ваш пример с Ruby. Сейчас я хочу изучить какой-нибудь функциональный язык. На данный момент — Lisp
Мда… ну если хотите писать скобками — удачи. имхо практической пользы от лиспа ноль.
Сталкивался сам, поверьте, злило, но сторого говоря. в utf-8 BOM не нужен — он сделан для отличия Big Endian от Low Endian UTF-16 (спасибо идиотам, которые придумали несколько юникодов сразу). Отключите у себя в редакторе вставку BOM и забудьте об этой проблеме.
> Про ввод информации ответил выше. Это может быть не только HTTP запрос, но и чтение файла, сокеты, shared memory и еще много всего.
Если вы используете разные кодировки для разынх компонент приложения — проблемы вам гарантированы в любом языке, хотя бы потому, что наборы символов в разных кодировках разные и не всегда можно без потерь перевести из одной в другую. Бросайте эту дурь, или пишите обертки для перекодировки, если не можете.
> Мне понравился ваш пример с Ruby. Сейчас я хочу изучить какой-нибудь функциональный язык. На данный момент — Lisp
Мда… ну если хотите писать скобками — удачи. имхо практической пользы от лиспа ноль.
Внутри приложения, конечно, должна быть одна кодировка. Но что там придет из вне и в какой кодировке — вопрос.
Lisp'ом заинтересовался после прочтения www.nestor.minsk.by/sr/2003/07/30710.html вполне возможно, что он меня тоже бесить будет:)
Lisp'ом заинтересовался после прочтения www.nestor.minsk.by/sr/2003/07/30710.html вполне возможно, что он меня тоже бесить будет:)
Ну почему же ноль? Программистам на лиспе платят довольно приличные деньги. Другое дело, что их трудно найти (хороших).
У лиспа довольно хорошая область применения в области 3D разработок, он там очень силен. В частности куски кода, насколько я знаю, на лиспе есть в 3D Max и других средах.
У лиспа довольно хорошая область применения в области 3D разработок, он там очень силен. В частности куски кода, насколько я знаю, на лиспе есть в 3D Max и других средах.
меня именно в это в руби убивает, если в си я могу читать код и прерасно все понимать, он почти на анг языке там написан :)
А можно я тоже отвечу?
Хз, из чего вы выросли, но язык для веба подразумевает вот что:
— краткое время жизни выполняющейся программы; эти уши тянутся еще из CGI, в модели «запустился-сделал-умер» (все, что вне, к php прикручено костылями) как следствие, в php не сильно заморачиваются на утечки памяти и прямоту архитектуры.
— небольшой размер самих программ (ибо нефиг шаблонизаторам страниц быть большими); как следствие, можно не сильно заботиться о мозге программера, который копает код — он не закипит.
— hot start: поправил, сохранил, вуаля. Все, что требует deployment'а, остается далеко позади, потому что стереотипичному php-style-программисту некогда разбираться, он пишет методом проб и ошибок.
Java для «большого» веба подходит больше исключительно благодаря стараниям Sun, JBoss и иже с ними, выпустившими нормальные контейнеры для web-приложений и прямыми руками собравшими человеческую архитектуру обработки web-запросов.
Хз, из чего вы выросли, но язык для веба подразумевает вот что:
— краткое время жизни выполняющейся программы; эти уши тянутся еще из CGI, в модели «запустился-сделал-умер» (все, что вне, к php прикручено костылями) как следствие, в php не сильно заморачиваются на утечки памяти и прямоту архитектуры.
— небольшой размер самих программ (ибо нефиг шаблонизаторам страниц быть большими); как следствие, можно не сильно заботиться о мозге программера, который копает код — он не закипит.
— hot start: поправил, сохранил, вуаля. Все, что требует deployment'а, остается далеко позади, потому что стереотипичному php-style-программисту некогда разбираться, он пишет методом проб и ошибок.
Java для «большого» веба подходит больше исключительно благодаря стараниям Sun, JBoss и иже с ними, выпустившими нормальные контейнеры для web-приложений и прямыми руками собравшими человеческую архитектуру обработки web-запросов.
> — небольшой размер самих программ
А это плохо? По моему, так скорее хорошо.
> — краткое время жизни выполняющейся программы; эти уши тянутся еще из CGI, в модели «запустился-сделал-умер» (все, что вне, к php прикручено костылями) как следствие, в php не сильно заморачиваются на утечки памяти и прямоту архитектуры.
А вот некоторые Ява-приложения, я слышал, по минуте запускаются. Это по-вашему более прямая архитектура. И не плетите, что мол долго запрягать — быстро ехать, просто Ява-разработчики тоже не такие гуру, каких пытаются из себя строить.
> — hot start: поправил, сохранил, вуаля
Поверите ли, так удобнее. А как должно быть по-вашему?
И да, в связи с кратким временем жизни, разработчикам php приходится изощряться, делать программу как можно оптимальнее, подключать только нужные модули, и т.д., а Явовцы пишут монстров, кое-как слепленных и считают это «прямой» архитектурой.
А еще у вас уродливый Xml, и плохо с шаблонизаторами, так ведь?))
А это плохо? По моему, так скорее хорошо.
> — краткое время жизни выполняющейся программы; эти уши тянутся еще из CGI, в модели «запустился-сделал-умер» (все, что вне, к php прикручено костылями) как следствие, в php не сильно заморачиваются на утечки памяти и прямоту архитектуры.
А вот некоторые Ява-приложения, я слышал, по минуте запускаются. Это по-вашему более прямая архитектура. И не плетите, что мол долго запрягать — быстро ехать, просто Ява-разработчики тоже не такие гуру, каких пытаются из себя строить.
> — hot start: поправил, сохранил, вуаля
Поверите ли, так удобнее. А как должно быть по-вашему?
И да, в связи с кратким временем жизни, разработчикам php приходится изощряться, делать программу как можно оптимальнее, подключать только нужные модули, и т.д., а Явовцы пишут монстров, кое-как слепленных и считают это «прямой» архитектурой.
А еще у вас уродливый Xml, и плохо с шаблонизаторами, так ведь?))
>> А это плохо? По моему, так скорее хорошо.
Я не говорил, что это плохо, я говорил, что это — факт. И что из него есть следствие — очень короткую и простую программу можно написать абы как, задней ногой, лишь бы при заказчике не падало.
Плохо это или нет для пхп, я не знаю, я на пхп ни разу не писал :)
>>А вот некоторые Ява-приложения, я слышал, по минуте запускаются. Это по-вашему более прямая архитектура.…
Нет.
По моему, прямая архитектура никак не связана с временем запуска программы. Я же в предыдущем комменте написал, почему так важен hot-start для php — потому что де-факто средний разработчик на пхп забивает и на дебаггер, и на логгирование, а дефекты ищет прямо на продакшене.
>> просто Ява-разработчики тоже не такие гуру, каких пытаются из себя строить.
Ну и наброс, я даже комментировать не стану :)
>>в связи с кратким временем жизни, разработчикам php приходится изощряться, делать программу как можно оптимальнее
Именно. В ущерб читаемости, поддерживаемости, расширяемости. Проблема в этом, а не в коротком времени жизни as is.
>> А еще у вас уродливый Xml, и плохо с шаблонизаторами, так ведь?
Если вы про «нас», т.е. про меня, то у нас в .NET все прекрасно с и с xml, и с шаблонизаторами :) Полно разных на любой вкус — хоть Spark, хоть Asp.Net MVC, хоть Monorail, хоть NVelocity.
Я не говорил, что это плохо, я говорил, что это — факт. И что из него есть следствие — очень короткую и простую программу можно написать абы как, задней ногой, лишь бы при заказчике не падало.
Плохо это или нет для пхп, я не знаю, я на пхп ни разу не писал :)
>>А вот некоторые Ява-приложения, я слышал, по минуте запускаются. Это по-вашему более прямая архитектура.…
Нет.
По моему, прямая архитектура никак не связана с временем запуска программы. Я же в предыдущем комменте написал, почему так важен hot-start для php — потому что де-факто средний разработчик на пхп забивает и на дебаггер, и на логгирование, а дефекты ищет прямо на продакшене.
>> просто Ява-разработчики тоже не такие гуру, каких пытаются из себя строить.
Ну и наброс, я даже комментировать не стану :)
>>в связи с кратким временем жизни, разработчикам php приходится изощряться, делать программу как можно оптимальнее
Именно. В ущерб читаемости, поддерживаемости, расширяемости. Проблема в этом, а не в коротком времени жизни as is.
>> А еще у вас уродливый Xml, и плохо с шаблонизаторами, так ведь?
Если вы про «нас», т.е. про меня, то у нас в .NET все прекрасно с и с xml, и с шаблонизаторами :) Полно разных на любой вкус — хоть Spark, хоть Asp.Net MVC, хоть Monorail, хоть NVelocity.
НЛО прилетело и опубликовало эту надпись здесь
Все это так когда у вас многомиллионный бизнес и вы готовы вкладывать любые средства в программистов. В Российских реалиях такое есть отнюдь не всегда.
Когда у вас небольшая веб студия, то вам не нужен мега успешный и крутой лид. Вам нужны просто пара толковых программистов. Не обязательно опытных, но именно толковых. Они могут не знать языка на высоком уровне, но интуитивно чувствовать, что пишут лажу.
В будущем эти толковые программисты либо уйдут, либо войдут в долю в фирме.
Как искать таких среди PHP'шников я не знаю. И это проблема.
Когда у вас небольшая веб студия, то вам не нужен мега успешный и крутой лид. Вам нужны просто пара толковых программистов. Не обязательно опытных, но именно толковых. Они могут не знать языка на высоком уровне, но интуитивно чувствовать, что пишут лажу.
В будущем эти толковые программисты либо уйдут, либо войдут в долю в фирме.
Как искать таких среди PHP'шников я не знаю. И это проблема.
Java язык специально спроектированный для быдлокодеров. Там все сделано так чтобы даже мартышка не смогла отстрелить себя яйца. И это замечательно. В результате чтобы написать работающий проект нужно 10 специально обученных обезьянок и грамотный архитектор надсмотрщик. И это прекрасно, это требования промышленности.
и опять — война религий…
если Ява так хороша, почему РНР ее вытеснил в WEB программировании?
если Ява так хороша, почему РНР ее вытеснил в WEB программировании?
Подскажите где он его вытеснил а? :) Я вот не припомню ни одной системы на java которую бы сменили на php. Может примеры приведете?
ну думаю в области бложиков и мелких магазинчиков он вытеснил все что было до этого написано на яве
А если переформулировать — почему до сих пор не вытеснил PHP? Даже предложения хостеров проанализировать — много хостингов с Java?
По той же причине, что самосвалы не вытеснили малолитражки.
Не совсем удачное сравнение — никто в здравом уме не будет использовать малолитражки для промышленных перевозок грунта или песка, а если и попробует, то быстро разорится, даже если будут заказчики, которым главное, чтобы доставили за конкурентную сумму, а вот PHP используют вполне успешные компании.
Вполне удачное. Ни одна из крупных компаний не использует PHP в больших системах с сложной логикой. Используют или Java или C#.
Что есть сложная логика? И большой проект? Примеры всемирно известных (а занчит, по-моему, и высоконагруженных) сайтов на PHP я могу привести и даже статистику поискать, но вот оценить их размер и сложность — увы :(
Facebook, ICQ, vkontakte, ФСБ, несколько платежных систем и куча поисковиков вроде nigma. Кстати, MySQL тоже. Список можно продолжать до бесконечности. Достаточно крупные компании?
так к слову, мне нравится С++, он быстрый и лаконичный,
но есть задачи, где лучше и менее трудозатратней все-же далать на РНР
и вообще Программисту с большой буквы, выбор языка не должен быть камнем преткновения. Он должен одинаково хорошо знать и Яву и Си и разбираться в РНР. Может быть в чём-то лучше или в чём-то хуже… Я вот РНР программист, но вынужден патчить сишные модули и запускать явские классы.
но есть задачи, где лучше и менее трудозатратней все-же далать на РНР
и вообще Программисту с большой буквы, выбор языка не должен быть камнем преткновения. Он должен одинаково хорошо знать и Яву и Си и разбираться в РНР. Может быть в чём-то лучше или в чём-то хуже… Я вот РНР программист, но вынужден патчить сишные модули и запускать явские классы.
Например, тем что без виртуализации нельзя нормально разграничить ресурсы между сервисами.
Вообще текущий шудлер linux много что позволяет. В том чмсле и разграничивать ресурсы между сервисами.
возможностей lxc было мало?
Вообще это тоже самое.
Вообще это не тоже самое. То что из openvz kernel часть понемногу перетекает в mainline под названием lxc не делает его тем же самым.
Я в плане того что и OpenVZ и lxc являются системами контейнеров. Вы кстати lxc пользовали? Меня интересует где более подробно почитать о развитии, а то OpenVZ как-то стагнирует.
>Вы кстати lxc пользовали?
нет
>Меня интересует где более подробно почитать о развитии, а то OpenVZ как-то стагнирует.
в списках рассылки
нет
>Меня интересует где более подробно почитать о развитии, а то OpenVZ как-то стагнирует.
в списках рассылки
Каждому удобно что-то своё. Удобство вообще штука весьма относительная.
jails и zones в массы :)
Ну что за глупые вопросы, конечно же потому что гугл написан на php.
Хочу сразу огорчить. Даже у гугла есть уязвимая точка хранилища — сервер метаданных, он один дабы исключить коллизии.
И для надежности он полностью файловерный — на аппаратном уровне.
Прежде чем охватывать все — давайте сделаем действительно надежное избыточное хранилище.
И для надежности он полностью файловерный — на аппаратном уровне.
Прежде чем охватывать все — давайте сделаем действительно надежное избыточное хранилище.
Я предлагаю использовать для этого безтрекерный вариант торрентов и грузить на каждую ноду torrent, а уже алгоритм выбирает путем голосования на каких нодах пойдет закачка.
Если какие-то ноды умирают, то алгоритм ставит закачку на живых нодах.
При увеличении числа нод автоматически коррелируется распределение.
Звучит неплохо?
Если какие-то ноды умирают, то алгоритм ставит закачку на живых нодах.
При увеличении числа нод автоматически коррелируется распределение.
Звучит неплохо?
В MongoDB это называется config-server, почитайте про это.
Снобизма в ваших комментариях хватит на 3 гугла. Если вы считаете, что автор вам был что-то должен — то вы ошиблись.
TravisBickle, я вот пытался читать код как твоего phpFastCgi, так и твоего phpDaemon, но наткнулся на небольшую, но очень раздражающую проблему.
это однопробельный отступ / отсутствие документации.
если бы отступы были нормальные, я обошёлся бы без документации и читал бы все по исходникам, но так их читать сложно. если бы документация была, то я бы вообще исходников не читал (или читал бы их намного меньше). опять же, можно всё переформатировать, но при попытке сделать svn up получу кучу проблем.
я не оставляю попытки все-таки разобраться в коде phpDaemon, потому что это действительно очень круто и полезно, но каждый раз натыкаюсь на пробелы.
посоветуйте, пожалуйста, кто-нибудь что-нибудь.
это однопробельный отступ / отсутствие документации.
если бы отступы были нормальные, я обошёлся бы без документации и читал бы все по исходникам, но так их читать сложно. если бы документация была, то я бы вообще исходников не читал (или читал бы их намного меньше). опять же, можно всё переформатировать, но при попытке сделать svn up получу кучу проблем.
я не оставляю попытки все-таки разобраться в коде phpDaemon, потому что это действительно очень круто и полезно, но каждый раз натыкаюсь на пробелы.
посоветуйте, пожалуйста, кто-нибудь что-нибудь.
так, я непонял
> путь Microsoft — каждый сервис разрабатывается независимо, при этом каждая группа разработчиков делает собственные решения
во первых вы наверно упускаете .NET как единую платформу для решений(тьма продуктов, лекций, технологий), во вторых разброс в бизнес решениях исторически обусловлен процессом получения этих решений. Покупается компания с продуктом, разработчиками и.т.д. и логично что они некоторое время будут «вливаться» в общий поток работая отстраненно.
> путь Microsoft — каждый сервис разрабатывается независимо, при этом каждая группа разработчиков делает собственные решения
во первых вы наверно упускаете .NET как единую платформу для решений(тьма продуктов, лекций, технологий), во вторых разброс в бизнес решениях исторически обусловлен процессом получения этих решений. Покупается компания с продуктом, разработчиками и.т.д. и логично что они некоторое время будут «вливаться» в общий поток работая отстраненно.
Это лишь платформа разработки, а не общая инфраструктура. Достаточно послушать самих представителей Microsoft, когда они говорят об оптимизации сервисов.
> путь Google — существует единая платформа и единая система, в которой живут приложения
Единая OS:
Windows
Единая платформа для приложений:
SharePoint Server
Enterprise Services
Единая БД:
SQL Server
Единая среда разработки:
Visual Studio
Где разрозненность? Может 2 Азура? Или лайф сервисы?
Единая OS:
Windows
Единая платформа для приложений:
SharePoint Server
Enterprise Services
Единая БД:
SQL Server
Единая среда разработки:
Visual Studio
Где разрозненность? Может 2 Азура? Или лайф сервисы?
Microsoft Bing:
Java
Hadoop
HBase
Java
Hadoop
HBase
я уже выше описал причину почему приобретенные технологии и продукты так отличаются от остальных решений Microsoft. Подождите пару лет и Java станет .NET, HBase станет Microsoft Huge Data Services, а Hadoop Азуром
Если вас не затруднит, можно ссылочку про архитектуру Бинга, где указано что он основан на этих технологиях?
Именно! Самая что ни на есть инфраструктура.
> Первый подход чаще используется в поисковых системах со сравнительно небольшим количеством поисковых запросов.
Просто оставлю это здесь:
Архитектура Яндекс.Поиска
Просто оставлю это здесь:
Архитектура Яндекс.Поиска
В действительности, сделать такую систему вовсе не сложно. Тем более, я работаю над соответствующим фреймворком для простого создания подобных систем.
над этой фразой тихо плакал :D
над этой фразой тихо плакал :D
>Акцент будет поставлен практическую разработку и жареные факты, а не на сухую теорию.
Ну да. В итоге туча теории и ничего на практике. Перечислить софт и хард, который надо юзать якобы для высокопроизводительных приложений — это сильно да, это практика :-)
Ничего личного — но это такая же теория, от которой автор отнекивался в «Вступлении».
Ну да. В итоге туча теории и ничего на практике. Перечислить софт и хард, который надо юзать якобы для высокопроизводительных приложений — это сильно да, это практика :-)
Ничего личного — но это такая же теория, от которой автор отнекивался в «Вступлении».
не понятно что такое «Сервис блокировок» оч скудно
не понятно — почему в качестве хранилища данных взята MongoDB
чем оно лучше сторадж-сервера, который напрямую отдает контент
А надежность Ж два сервера включаем в пару: с шарда1 люем одновременно данные на шард2 и наоборот. В случае отказа одной из шард — автоматически данные будут браться со второй. ngx_upstreem рулит
с Сервером приложений вообще муть…
Единственное, с чем я согласен — Поиск, да, надо использовать специализированные средства, типа сфинксва, яндекс-машины или мутить какой-нибудь asearch.
не понятно — почему в качестве хранилища данных взята MongoDB
чем оно лучше сторадж-сервера, который напрямую отдает контент
А надежность Ж два сервера включаем в пару: с шарда1 люем одновременно данные на шард2 и наоборот. В случае отказа одной из шард — автоматически данные будут браться со второй. ngx_upstreem рулит
с Сервером приложений вообще муть…
Единственное, с чем я согласен — Поиск, да, надо использовать специализированные средства, типа сфинксва, яндекс-машины или мутить какой-нибудь asearch.
и еще с чем я согласен — все тяжелые процессы надо валить в бэдграунд,
и тянуть из них информацию по аяксу (если нужно)
… страницы должны отдаваться на ура, ни одного запроса с джоином!!!
и тянуть из них информацию по аяксу (если нужно)
… страницы должны отдаваться на ура, ни одного запроса с джоином!!!
интересно — минусуют ламеры или профессионалы
если не согласны с моими утверждениями — то должно быть обоснование.
лично я Hiload занимаюсь более года и имею хоть не большой, но опыт в построении высоконагруженных систем.
если не согласны с моими утверждениями — то должно быть обоснование.
лично я Hiload занимаюсь более года и имею хоть не большой, но опыт в построении высоконагруженных систем.
Слишком расплывчато написали. Мысль, вроде, логичная, но в такой формулировки может быть понята как угодно.
что расплывчато?
все тяжелые процессы надо валить в бэдграунд — так делается во всех известных мне нагр системах
если требуется показывать прогресс, то не проблема — используем аджакс
так делается и при аплоадинге и при генерации кучи данных (система лотерейных билетов) и при обработки графических данных — автоматическое выделение фрейма при нарезке отсканированных отображений (в частности были комиксы) и еще много где… я указал то, где это приходилось использовать лично.
страницы должны отдаваться на ура, под этим понимается, что время генерации страницы должно быть минимальным. А для этого:
Если используется БД, то должен использоваться только запросы не сложнее SELECT * WHERE без всяких джоинов. Вся доп логика уходит в бэдграундовские процессы. Для этого существует технология «вечных скриптов», которые подготавливаютнужные нам данные и быстро их отдаем фронт-процессом.
куда уж яснее…
все тяжелые процессы надо валить в бэдграунд — так делается во всех известных мне нагр системах
если требуется показывать прогресс, то не проблема — используем аджакс
так делается и при аплоадинге и при генерации кучи данных (система лотерейных билетов) и при обработки графических данных — автоматическое выделение фрейма при нарезке отсканированных отображений (в частности были комиксы) и еще много где… я указал то, где это приходилось использовать лично.
страницы должны отдаваться на ура, под этим понимается, что время генерации страницы должно быть минимальным. А для этого:
Если используется БД, то должен использоваться только запросы не сложнее SELECT * WHERE без всяких джоинов. Вся доп логика уходит в бэдграундовские процессы. Для этого существует технология «вечных скриптов», которые подготавливаютнужные нам данные и быстро их отдаем фронт-процессом.
куда уж яснее…
Не все тяжелые процессы можно легко вынести в бекграунд. Само по себе это предложение в такой форме выглядит странным. Вместо того, чтобы убирать join'ы из кода, возможно, дешевле поставить новый сервер.
За публичное выражение нелюбви PHP, пусть и аргументированное, на хабре быстро улетаешь в минус. Так что минус поставить я не мог — карма отрицательная. Просто высказал предположение.
А, может, ваше высказывание где-то кому-то не понравилось и он решил пройтись минусами по вашим комментариям…
За публичное выражение нелюбви PHP, пусть и аргументированное, на хабре быстро улетаешь в минус. Так что минус поставить я не мог — карма отрицательная. Просто высказал предположение.
А, может, ваше высказывание где-то кому-то не понравилось и он решил пройтись минусами по вашим комментариям…
да, люблю поострить, есть такой грех
>За публичное выражение нелюбви PHP, пусть и аргументированное, на хабре быстро улетаешь в минус.
так я пропитый до мозга костей РНРник с десятилетним стажем. Все хочу соскочить с этого наркотика, да не получается. Чисто по экономическим причинам.
так я пропитый до мозга костей РНРник с десятилетним стажем. Все хочу соскочить с этого наркотика, да не получается. Чисто по экономическим причинам.
хочу предупредить: обратной дороги не будет — соскочив с PHP вернуться к нему нереально.
Сомневаюсь. PHP мой не первый и не последний язык, однако я его уважаю, хоть и знаю его недочеты и знаю как он работает внутри. Просто я научился их обходить.
Сомневаешься в чем? что соскочу или что есть обратная дорога?
соскочить трудно по экономическим причинам,
сам понимаешь, сколько получает чел с 10 летним стажем. А на других языках — я буду новичек.
хотя мне было предложение на Сях равноправное РНР, но что-то я не поспешил с ним. Просто сейчас в очень интересном проекте, где кроме знания РНР много чего требуется от меня. Вот, по этому и трудно соскачить.
соскочить трудно по экономическим причинам,
сам понимаешь, сколько получает чел с 10 летним стажем. А на других языках — я буду новичек.
хотя мне было предложение на Сях равноправное РНР, но что-то я не поспешил с ним. Просто сейчас в очень интересном проекте, где кроме знания РНР много чего требуется от меня. Вот, по этому и трудно соскачить.
да меня явно не любят в этом топики — одни минусы…
все — покидаю,
удачных проектов!!!
все — покидаю,
удачных проектов!!!
Согласен, что по экономическим сложно, но тут можно и «затянуть ремень» на некоторое время, но вот найти работу куда возьмут скажем Java программиста с резюме «10 лет на PHP, изучил синтаксис Java», по-моему, еще труднее.
теперь о Джоинах… когда речь идет об одном доп сервере — то можно джоины и не трогать… а если речь идет о трех десятков серверов. Это сколько доп серверов нужно???? Еще три десятка…
А в чем особенность джоинов, чем они отличаются от select-а where простого если надо нормализовать базу по полю города например.
в этом случае базу надо денормализовать
дисковое пространство — дешевое
экономия на месте — это экономия на времени отдачи
это простой, процессов, это доп сжираемая память, доп обращение к дисковому пространству в случае свопинга и тд и тп…
дисковое пространство — дешевое
экономия на месте — это экономия на времени отдачи
это простой, процессов, это доп сжираемая память, доп обращение к дисковому пространству в случае свопинга и тд и тп…
я имел ввиду — в чем разница? почему плохо делать
SELECT user FROM users u
LEFT JOIN cities c ON u.city=c.id
WHERE userId=123456
SELECT user FROM users u
LEFT JOIN cities c ON u.city=c.id
WHERE userId=123456
для поиска используется поисковые машины аля сфинкс, яндекс-энджине или что-то своё…
причем тут полнотекстовый поиск?
ответ: при чем тут джоины…
про полнотекстовый не было ни сказано ни слова…
любой поиск по полям.
про полнотекстовый не было ни сказано ни слова…
любой поиск по полям.
вы сказали что джоины плохо, мне интересен ваш опыт с пояснением, вот на моем на примере.
«сфинкс, яндекс-энджине» — это серверы для полнотекстового поиска. я не понял зачем вы их тут привели.
«сфинкс, яндекс-энджине» — это серверы для полнотекстового поиска. я не понял зачем вы их тут привели.
и не только полнотекстового. Это прежде всего машины построения индекса, по которому можно осуществлять быстрый поиск. Яндекс-машина плохо управляема, сфинкс более оптимальное решение. Мы используем сфинкс. Я с ним не работал, ничего не подскажу.
что тебе мешает добавить поле City?
много место оно не съест, а вот засвопить таблицу cityes он сможет. Ладно, будем надеяться, что у нас сервер достаточно по ресурсам мощный, но вместо одного буфера — будет выделено два — это доп память, потратится время на слияние. микросекунды… но когда речь идет о нагрузках — то боремся и за микросекунды.
много место оно не съест, а вот засвопить таблицу cityes он сможет. Ладно, будем надеяться, что у нас сервер достаточно по ресурсам мощный, но вместо одного буфера — будет выделено два — это доп память, потратится время на слияние. микросекунды… но когда речь идет о нагрузках — то боремся и за микросекунды.
думаю вы загибаете :) я проверил, у меня джоин работает быстрее.
При добавлении поля City в varcar(100) к примеру оверхед на строку будет 96 байт. Если у нас 40000 строк в таблице то это оверхед в 3,84 мегабайта. Таблица на 1000 адресов будет занимать мегабайт и причем с увеличением количества строк в другой таблице оверхед увеличиваться не будет. За счет денормализации можно существенно сэкономить память, в результате чего даже с операцией слияния все будет работать быстрее.
>А, может, ваше высказывание где-то кому-то не понравилось и он решил пройтись минусами по вашим комментариям…
а не кажется тебе, что это очень низко… и неужели есть такие люди среди программистов???
а не кажется тебе, что это очень низко… и неужели есть такие люди среди программистов???
а я гадаю, почему все мои статьи пошли в минус… надоже какое бывает.
лично я минусов почти не ставлю.
лично я минусов почти не ставлю.
Мне недавно прошлись по комментариям, минусы проставить. Красиво так по -1 стояло.
Людей с низкой самооценкой, неспособных признать собственную неправоту, к сожалению, хватает.
Ну и пофиг. Единственное неудобство — писать раз в 5 минут. Зато обдумать мысль успеваешь:)
А статью, если захочу написать, я всегда найду через кого опубликовать.
Людей с низкой самооценкой, неспособных признать собственную неправоту, к сожалению, хватает.
Ну и пофиг. Единственное неудобство — писать раз в 5 минут. Зато обдумать мысль успеваешь:)
А статью, если захочу написать, я всегда найду через кого опубликовать.
Думаю nginx нужен не для того чтобы быстро отдавать фронтом, а чтобы быстро забирать с бэка фронтом что бы апач меньше лочить.
забудь слово аппач
а что тогда для php и persistent-коннектов?
>persistent-коннектов — что ты под этим понимаешь?
php-fpm
php-fpm
под persistent-коннектами я подразумеваю что при работе, например, с базой данных обмен разных запусков скрипта осуществляется в пределах одной tcp-сессии.
вот тут пишут что разницы в нем и mod_php нет, а тут он себя сообще плохо проявил. А вот спецы по битриксу сравнивали и тоже там php-fpm уступает.
вот тут пишут что разницы в нем и mod_php нет, а тут он себя сообще плохо проявил. А вот спецы по битриксу сравнивали и тоже там php-fpm уступает.
Слова «Битрикс» и «спец» несоместимы. Там нет спецов, ибо спецам будет просто стыдно работать с этой поделкой, единственное достоинство которой — маркетинг. На 100% уверен, что тестирование проводилось не с php-fpm и столкнулись с проблемами, описанными тут: dklab.ru/chicken/nablas/49.html
svyaznoy.ru, eldorado.ru — bitrix, mod_php
Это еще ниочем не говорит. Битрикс — гавнокод. Его программисты — гавнокодеры.
ну вы на статистику сайтов посмотрите, и на качество самих сайтов — сайты работают (продают в данном случае) и делают это хорошо.
вот еще rt.ru
вот еще rt.ru
Это не аргумент. Мне достаточно было заглянуть в код Битрикса, чтобы понять, что писать такой лапшекод нормальный программист не будет.
Сайты работают, да. Потому, что их поддерживают.
Качество сайта для меня не только дизайн и функционал, а еще и код системы, на которой он построен.
Что лучше, проще поддерживать — нормальный, наследуемый код, аккуратный, структурированный или перловку из кода, где сам черт ногу сломит?
Если не смотрели код Битрикса — то советую посмотреть на досуге. Для ловления лулзов.
З.Ы. Похоже задел нежные чувства кого-то из битриксоидов — минуснули карму. Да, большего я от вас, битриксоиды, не ожидал. Нечем крыть, кроме как нажать кнопочку слива кармы — это сильно ;)
Сайты работают, да. Потому, что их поддерживают.
Качество сайта для меня не только дизайн и функционал, а еще и код системы, на которой он построен.
Что лучше, проще поддерживать — нормальный, наследуемый код, аккуратный, структурированный или перловку из кода, где сам черт ногу сломит?
Если не смотрели код Битрикса — то советую посмотреть на досуге. Для ловления лулзов.
З.Ы. Похоже задел нежные чувства кого-то из битриксоидов — минуснули карму. Да, большего я от вас, битриксоиды, не ожидал. Нечем крыть, кроме как нажать кнопочку слива кармы — это сильно ;)
49 набла была раскритикована спецами по хайлоаду, в частности А.Рыбаком и А.Нигматулиным. если вам ничего это не говорит, то я не спорю. и вообще жалею, что влех в этот топик…
А слабо дать ссылки на критику?
мне тоже интересно
я не нашел, критику апача, все что нашел вот тут — там первым предложением:
Andrei Nigmatulin
Ну по большому счету автор все-таки прав — FastCGI не ускоряет php ;-)
Вы это имели ввиду?
Andrei Nigmatulin
Ну по большому счету автор все-таки прав — FastCGI не ускоряет php ;-)
Вы это имели ввиду?
что вы имеете ввиду под сторадж-сервером? ext3?
шардинг это про базы данных и uniqeu ключи насколько я понял, а не про http, причем тут nginx.
шардинг это про базы данных и uniqeu ключи насколько я понял, а не про http, причем тут nginx.
вопрос ко мне? очевидно да.
сторадж сервер — это сервер, на котором хранится контент: фото/видео/аудио/просто файлы
тип файловой системы — это вторично. Скорее всего ext3, но возможно есть что-то более быстрое. Это уже вопросы к админу. конкретную конфигурацию сервера устанавливает админ.
в данном контексте — шардинг про файлы, хотя БД тоже устроена по принципу шардинга. В своих статьях (кажется статья про ленту друзей) в комментах я рассказывал как устоен шардинг БД.
первый nginx — выступает как прокси
второй отдает контент, если вылетает один из стораджей, отдача автоматически проксируется на другой.
Вы единственный, кто заметил этот комментарий. В конце обсуждения я сделал вывод, что публика Хабра еще не готова к теме высоких нагрузок.
сторадж сервер — это сервер, на котором хранится контент: фото/видео/аудио/просто файлы
тип файловой системы — это вторично. Скорее всего ext3, но возможно есть что-то более быстрое. Это уже вопросы к админу. конкретную конфигурацию сервера устанавливает админ.
в данном контексте — шардинг про файлы, хотя БД тоже устроена по принципу шардинга. В своих статьях (кажется статья про ленту друзей) в комментах я рассказывал как устоен шардинг БД.
первый nginx — выступает как прокси
второй отдает контент, если вылетает один из стораджей, отдача автоматически проксируется на другой.
Вы единственный, кто заметил этот комментарий. В конце обсуждения я сделал вывод, что публика Хабра еще не готова к теме высоких нагрузок.
Тип файловой системы на сторадж сервер вторично? В mongodb вы конечно прочитали про gridfs?
Вы чо :) шардинг в хайлоаде это распределение данных одной базы данных по разным инстансам — горизонтальное партицирование.
то что вы называете шардингом это проксирование :)
Вы чо :) шардинг в хайлоаде это распределение данных одной базы данных по разным инстансам — горизонтальное партицирование.
то что вы называете шардингом это проксирование :)
мухи отдельно, котлеты отдельно. забыли слово проксирование.
если вопрос про mongodb — то это к автору топика.
я делюсь информацией, как это делается в проектах деци-миллионниках.
шардинг — это распределение данных на разных физических носителях. распределение может быть по разным признакам. В данной теме БД я не затрагивал, а имелось ввиду файловое хранилище. Хочешь обсуждать шардинг БД, wellcome в соседний топик.
контент льется на два стораджа одновременно. Для надежности. А забирается с одного. В случае выхода одного из серверов — он забирается с другого. что тут непонятного!
ну, а теперь предложи схему, как забирать контент, если выйдет файловый-сервер?
если вопрос про mongodb — то это к автору топика.
я делюсь информацией, как это делается в проектах деци-миллионниках.
шардинг — это распределение данных на разных физических носителях. распределение может быть по разным признакам. В данной теме БД я не затрагивал, а имелось ввиду файловое хранилище. Хочешь обсуждать шардинг БД, wellcome в соседний топик.
контент льется на два стораджа одновременно. Для надежности. А забирается с одного. В случае выхода одного из серверов — он забирается с другого. что тут непонятного!
ну, а теперь предложи схему, как забирать контент, если выйдет файловый-сервер?
непойму, как шардинг связан с failover.
failover в такой ситуации можно сделать, ну, например, зеркалированием блочного устройства по сети с DRDB и heartbeat.
failover в такой ситуации можно сделать, ну, например, зеркалированием блочного устройства по сети с DRDB и heartbeat.
я про А, ты про Бэ…
ни какой лишней информации по сети
она и так будет перегружена
она и так будет перегружена
а какая лишняя информация может возникнуть?
качать информацию со стороджа на сторадж или что ты там предлагаешь…
ладно — я спать,
ладно — я спать,
так ну так и так придется на сервер информацию закачивать, или что?
или что…
ничего не надо лишнего перекачивать.
информация заливается на один сервер и дублируется на второй. В случае отказа берется со второго, не увиличивая и не задействуя какие-то дополнительные сетевые схемы.
Наша задача, как можно быстрее отдать контент.
и вообще мне надоело с пеной у рта доказывать как надо делать. делайте — как считаете нужным.
ничего не надо лишнего перекачивать.
информация заливается на один сервер и дублируется на второй. В случае отказа берется со второго, не увиличивая и не задействуя какие-то дополнительные сетевые схемы.
Наша задача, как можно быстрее отдать контент.
и вообще мне надоело с пеной у рта доказывать как надо делать. делайте — как считаете нужным.
ну failover ha и lb я бы для файлсервера на linux сделал бы так —
на сервере1 и сервере2 вставил бы по блочному устройству.
вставил бы по две сетевые карты, соединил бы оба сервера друг с другом и с сетью прокси сервера. запись была бы с прокси на мастер-сервер drbd, одновременно с записью на него мастер синхронно бы сливал файл по второму интерфейсу на второй сервер и к моменту аплоада на один сервер файл был бы уже на двух. тем самым нагрузка на коммутатор со стороны прокси сервера была бы в два раза ниже.
а вы?
на сервере1 и сервере2 вставил бы по блочному устройству.
вставил бы по две сетевые карты, соединил бы оба сервера друг с другом и с сетью прокси сервера. запись была бы с прокси на мастер-сервер drbd, одновременно с записью на него мастер синхронно бы сливал файл по второму интерфейсу на второй сервер и к моменту аплоада на один сервер файл был бы уже на двух. тем самым нагрузка на коммутатор со стороны прокси сервера была бы в два раза ниже.
а вы?
извращенцы :-)
нормальная статья
компоненты можно менять
человек сам думает а не только копирует
компоненты можно менять
человек сам думает а не только копирует
я написал вчера статью про отладку, вернее рассмотрел один практический пример поиска бага в сложной системе (а на взляд — простой), так ее заминусовали. Лично у меня сложилось впечатление, что нужно писать статьи «Для чайников», тогда они будут иметь бешенный рейтинг.
Бурное обсуждение — уже показатель не плохого материала, хотя я много с чем в этой статье не согласен… и не для Хайлоада она
Бурное обсуждение — уже показатель не плохого материала, хотя я много с чем в этой статье не согласен… и не для Хайлоада она
У автора есть интерес к теме высокодоступных-высоконагруженных серверов, и это очень хорошо. Главное не останавливаться и продолжать разбираться/набираться опыта.
С практической точки зрения представленный хлам никуда не годится. Я имею ввиду что каждый программный модуль в отдельности конечно вещь стоящая, но вот всё вместе оставляет ощущение… хмм… некоторого бардака.
По идее нужно плясать от конкретной задачи, представить архитектуру, выяснить требования к каждому модулю, а уж затем рассуждать что они будут из себя представлять. А у вас — подход микрософт, подход гугл… Да грамотный архитектор вообще об этом не думает, какие у кого подходы! Он аргументы в пользу того или иного решения проверяет, proof of concepts мастерит. А эти решения ему опыт его даёт.
Универсальную архитектуру при жёстких требованиях не сделать — то там косяк вылезет, то там модуль отвалится. Видеть надо всю систему глобально, не упуская конечную цель.
И ещё, реально работающая высоконагруженная система, решающая определённую задачу, она выверяется годами. Речь конечно не идёт о случае когда вы копируете чью-то исходную задачу — тогда конечно её решение кто-то за вас уже выверил.
Мне доводилось участвовать в разработке подобных комплексов. Чутьё приходит с годами серьёзного опыта, причём от задачи к задаче решения могут быть разные в силу специфики контекста.
Эх, тема настолько обширная, что тут можно рассказывать очень долго…
Желаю вам дело это не забрасывать, ведь именно там, где мы решаем трудные задачи, мы обогащаем свой опыт бесценными знаниями.
С практической точки зрения представленный хлам никуда не годится. Я имею ввиду что каждый программный модуль в отдельности конечно вещь стоящая, но вот всё вместе оставляет ощущение… хмм… некоторого бардака.
По идее нужно плясать от конкретной задачи, представить архитектуру, выяснить требования к каждому модулю, а уж затем рассуждать что они будут из себя представлять. А у вас — подход микрософт, подход гугл… Да грамотный архитектор вообще об этом не думает, какие у кого подходы! Он аргументы в пользу того или иного решения проверяет, proof of concepts мастерит. А эти решения ему опыт его даёт.
Универсальную архитектуру при жёстких требованиях не сделать — то там косяк вылезет, то там модуль отвалится. Видеть надо всю систему глобально, не упуская конечную цель.
И ещё, реально работающая высоконагруженная система, решающая определённую задачу, она выверяется годами. Речь конечно не идёт о случае когда вы копируете чью-то исходную задачу — тогда конечно её решение кто-то за вас уже выверил.
Мне доводилось участвовать в разработке подобных комплексов. Чутьё приходит с годами серьёзного опыта, причём от задачи к задаче решения могут быть разные в силу специфики контекста.
Эх, тема настолько обширная, что тут можно рассказывать очень долго…
Желаю вам дело это не забрасывать, ведь именно там, где мы решаем трудные задачи, мы обогащаем свой опыт бесценными знаниями.
у автора есть интерес к теме высокодоступных-высоконагруженных серверов — это плюс
но нет опыта — это минус
автор эксперементирует — это плюс
но не правильно трактует результаты экспериментов — это минус
нельзя статью назвать плохой, он и удачной тоже.
статья вызвала резонанс — это плюс
но нет опыта — это минус
автор эксперементирует — это плюс
но не правильно трактует результаты экспериментов — это минус
нельзя статью назвать плохой, он и удачной тоже.
статья вызвала резонанс — это плюс
Что, вообще нет? Мета-поисковик я уже не писал значит? Кластерами не занимаюсь за деньги?
Думаю, такое может утверждать лишь человек со значительно большим опытом, чем мой.
Думаю, такое может утверждать лишь человек со значительно большим опытом, чем мой.
Василий, мой опыт значительнее твоего, поверь мне.
Ты, молодец и я тебя за твои стремления и знания уважаю, ты знаешь это.
читай мои комментарии внимательнее, я тебя не ругаю, а даю конструктивную оценку. Ну, грешу, сострил в одном посту, про кол-во использований в проектах PHPDaemon.
как я тебе говорил пару лет назад, тебе надо поработать годик в сильной команде хорошего проета. У тебя есть все потенциальные возможности.
Ты, молодец и я тебя за твои стремления и знания уважаю, ты знаешь это.
читай мои комментарии внимательнее, я тебя не ругаю, а даю конструктивную оценку. Ну, грешу, сострил в одном посту, про кол-во использований в проектах PHPDaemon.
как я тебе говорил пару лет назад, тебе надо поработать годик в сильной команде хорошего проета. У тебя есть все потенциальные возможности.
> статья вызвала резонанс
Да, тема похоже для многих тут наболевшая :)
Правда споры в основном идут не о том — большинство отстаивают то, что лучше знают. Чёрт побери, столько шуму, а по сути — так несерьёзно…
Вот начиная с задач в десятки тысяч транзакций в секунду вся эта шелуха что в статье описана и осыпается, начинается реальный technical challenge.
Да, тема похоже для многих тут наболевшая :)
Правда споры в основном идут не о том — большинство отстаивают то, что лучше знают. Чёрт побери, столько шуму, а по сути — так несерьёзно…
Вот начиная с задач в десятки тысяч транзакций в секунду вся эта шелуха что в статье описана и осыпается, начинается реальный technical challenge.
Транзакций? Во-первых, в предлагаемой СУБД нету транзакционной модели. Во-вторых, обратите внимание на шардинг, модель выдержит любое количество операций в секунду, хоть триллион, надо лишь дать ей достаточное кол-во серверов, и с настройкой не накосячить.
согласен
бессмысленные религиозные войны…
еще не хватало взять наболевшую тему Win против *nix
спрос на тему есть, открытой информации мало. Кто может ее написать — сильно занят. Вот и появляется куча шарлотанских статей.
Начинаешь раскрывать профф. секреты высоких нагрузок- тебя минусуют. Не готова публика к теме Высоких нагрузок, не готова.
бессмысленные религиозные войны…
еще не хватало взять наболевшую тему Win против *nix
спрос на тему есть, открытой информации мало. Кто может ее написать — сильно занят. Вот и появляется куча шарлотанских статей.
Начинаешь раскрывать профф. секреты высоких нагрузок- тебя минусуют. Не готова публика к теме Высоких нагрузок, не готова.
поделитесь секретом? какая интенсивность чтения/записи в операциях/байтах на вашей инсталляции мемкешбд? как вы решили проблему с мьютексом треда мемкешбд при checkout-е?
про интенсивность мемкеша не скажу — не замерял
да, мемкеш имеет болезнь на запись — это заметно. Боремся расширением, у нас под него отдельный сервер. И еще мы его пропатчили, так что каждое последующее чтение прлонгирует жизнь элемента кеша на тоже время. Смешно, но это всего три строчки кода. Может когда-нибудь напишу статью про это.
а сразу сетов на порядок меньше стало.
А статья вам моя про мемкеш смотрю не понравилась, еще один минус появился…
да, мемкеш имеет болезнь на запись — это заметно. Боремся расширением, у нас под него отдельный сервер. И еще мы его пропатчили, так что каждое последующее чтение прлонгирует жизнь элемента кеша на тоже время. Смешно, но это всего три строчки кода. Может когда-нибудь напишу статью про это.
а сразу сетов на порядок меньше стало.
А статья вам моя про мемкеш смотрю не понравилась, еще один минус появился…
Так и есть, Вы совершенно правы. Хотя бардак вещь весьма субъективная… для меня всё представляется очень последовательно и логично.
Исследуя резюме автора, напрашивается вывод, что у автора PHP мозга :)
Технический директор, программист, системный архитектор.
* Опыт — 10 лет.
* Профессионально занимаюсь проектированием и разработкой компьютерных систем, защитой информации, аудитом IT-безопасности, кластеризацией, оптимизацией.
* Могу писать и пишу на всем — от спектрума до Java 6.0.
* Блестяще владею следующими языками программирования, список в порядке излюбленности:
Java (SE), PHP (начинал с PHP 3 в 1999), PCRE (на уровне дьявола), C(++), ECMAscript (JS), VB(S), Brainfuck.
* Положительный опыт руководства командой.
* Огромный положительный опыт работы (изнутри и снаружи) с:
Linux, FreeBSD, MySQL (InnoDB), nginx, Memcached, MemcacheDB, Subversion, Wowza Media Server.
* Знаком с:
Ruby, PostreSQL, MS SQL, Oracle, TDB, Perl, AS 3.
* Неплохо знаком с квантовой информатикой (пока на эмуляторе), создаю нейронные сети, занимаюсь прикладной криптографией.
* Проектирую и создаю сети распределенных вычислений, пишу под них программы, автор IMemcacheClient и IMapReduce.
* Профессионально занимаюсь аудитом IT-безопасности, автор ряда статей.
* В WEB-разработках в качестве frontend чаще всего использую собственную платформу, написанную на PHP (куда, в том числе, входят Quicky, SmartDB, fastgeoip).
* Имею большой опыт разработки систем под нагрузкой и с повышенной отказоустойчивостью и защиты от DDoS-атак (на всех уровнях).
* Опыт разработки и поддержки meta-поисковых машин, различных платежных систем и др.
* Опыт настройки и администрирования серверов, проектирования High-Availability кластерных систем хранения информации и распределенных вычислений.
* Опыт работы с огромными High-Availability БД, поисковыми механизмами (Sphinx, Lucene, ...).
* Опыт работы с медиа (опыт разработки с нуля медийного хостинга (tube) и сервиса социального онлайн-телевидения)
* Опыт в интеграции с WebMoney, E-Gold, Rupay, PayPal, Liberty, Pecunix, E-Bullion и др. платежными системами, опыт разработки сервера мерчанта.
* Автор множества opensource-проектов, из последних:
phpFastCGI, IMemcacheClient-PHP, Quicky, SmartDB, mctop, phpthread, cutebind
* Хорошее знание сетевых протоколов как высокого уровня (HTTP, FTP, DNS, BGP, OSCAR v9...), так и низкого (IP, TCP, UDP).
Технический директор, программист, системный архитектор.
* Опыт — 10 лет.
* Профессионально занимаюсь проектированием и разработкой компьютерных систем, защитой информации, аудитом IT-безопасности, кластеризацией, оптимизацией.
* Могу писать и пишу на всем — от спектрума до Java 6.0.
* Блестяще владею следующими языками программирования, список в порядке излюбленности:
Java (SE), PHP (начинал с PHP 3 в 1999), PCRE (на уровне дьявола), C(++), ECMAscript (JS), VB(S), Brainfuck.
* Положительный опыт руководства командой.
* Огромный положительный опыт работы (изнутри и снаружи) с:
Linux, FreeBSD, MySQL (InnoDB), nginx, Memcached, MemcacheDB, Subversion, Wowza Media Server.
* Знаком с:
Ruby, PostreSQL, MS SQL, Oracle, TDB, Perl, AS 3.
* Неплохо знаком с квантовой информатикой (пока на эмуляторе), создаю нейронные сети, занимаюсь прикладной криптографией.
* Проектирую и создаю сети распределенных вычислений, пишу под них программы, автор IMemcacheClient и IMapReduce.
* Профессионально занимаюсь аудитом IT-безопасности, автор ряда статей.
* В WEB-разработках в качестве frontend чаще всего использую собственную платформу, написанную на PHP (куда, в том числе, входят Quicky, SmartDB, fastgeoip).
* Имею большой опыт разработки систем под нагрузкой и с повышенной отказоустойчивостью и защиты от DDoS-атак (на всех уровнях).
* Опыт разработки и поддержки meta-поисковых машин, различных платежных систем и др.
* Опыт настройки и администрирования серверов, проектирования High-Availability кластерных систем хранения информации и распределенных вычислений.
* Опыт работы с огромными High-Availability БД, поисковыми механизмами (Sphinx, Lucene, ...).
* Опыт работы с медиа (опыт разработки с нуля медийного хостинга (tube) и сервиса социального онлайн-телевидения)
* Опыт в интеграции с WebMoney, E-Gold, Rupay, PayPal, Liberty, Pecunix, E-Bullion и др. платежными системами, опыт разработки сервера мерчанта.
* Автор множества opensource-проектов, из последних:
phpFastCGI, IMemcacheClient-PHP, Quicky, SmartDB, mctop, phpthread, cutebind
* Хорошее знание сетевых протоколов как высокого уровня (HTTP, FTP, DNS, BGP, OSCAR v9...), так и низкого (IP, TCP, UDP).
автор забыл указать возраст
но для его возраста — это вполне отличные результаты
но для его возраста — это вполне отличные результаты
как знать, как знать… у меня подобное резюме вызывает настороженность, особенно заявления вида «пишу на всем», «блестяще владею [перечисление более трех языков]».
Вы потенциальный работодатель, который может перебить мою текущую ставку? Если да, мы можем это обсудить в личной переписке. Если нет, не вижу смысла обсуждать этот offtopic.
P.S. Да, я могу сходу писать на любом языке, глянув примеры. Однажды за выходные выучил Java на достаточном уровне чтобы писать threaded-приложение с ConcurrentHashmap'ами, которое применялось в виде модуля к медиа-серверу. Но опять же, какое отношение это имеет к делу?
Для настоящего программиста язык роли не играет, это лишь примитивный инструмент через который программист выражает свои мысли.
P.S. Да, я могу сходу писать на любом языке, глянув примеры. Однажды за выходные выучил Java на достаточном уровне чтобы писать threaded-приложение с ConcurrentHashmap'ами, которое применялось в виде модуля к медиа-серверу. Но опять же, какое отношение это имеет к делу?
Для настоящего программиста язык роли не играет, это лишь примитивный инструмент через который программист выражает свои мысли.
> Вы потенциальный работодатель, который может перебить мою текущую ставку?
Кому нужен человек, изгалающий мысли одинаково на разных языках?
> Для настоящего программиста язык роли не играет, это лишь примитивный инструмент через который программист выражает свои мысли.
Настоящие Программисты вообще не пользуются редактором, потому что программируют бренное железо сразу в опкоде, воткнув мизинец в USB-порт.
Никогда не посещала мысль, откуда взялось такое разнообразие языков программирования и почему продолжают появляться новые языки?
P.S. Тему, если интересно, предлагаю перенести в личку, дабы не разбрасывать тут фекалии на вентилятор.
Кому нужен человек, изгалающий мысли одинаково на разных языках?
> Для настоящего программиста язык роли не играет, это лишь примитивный инструмент через который программист выражает свои мысли.
Настоящие Программисты вообще не пользуются редактором, потому что программируют бренное железо сразу в опкоде, воткнув мизинец в USB-порт.
Никогда не посещала мысль, откуда взялось такое разнообразие языков программирования и почему продолжают появляться новые языки?
P.S. Тему, если интересно, предлагаю перенести в личку, дабы не разбрасывать тут фекалии на вентилятор.
Оффтоп, но невольно складывается впечатление, что это говорит человек, считающий себя достигшим больших результатов чем я. Так ли это? ;-)
Да у меня еще и Java мозга, и Javascript мозга, и ANSI C мозга и много чего еще :-)
А вообще, товарищ, попрошу не оффтопить, тема тут никак не обсуждение моей скромной персоны. И уж тем более не копипаст чужих резюме, могли бы просто дать ссылку.
А вообще, товарищ, попрошу не оффтопить, тема тут никак не обсуждение моей скромной персоны. И уж тем более не копипаст чужих резюме, могли бы просто дать ссылку.
если автор тот о ком я думаю,
то я знаю его лично…
что-что а мозга у автора работает…
и выступал он на HiLoad не плохо
но есть у него и свои недостатки,
о которых неэтично говорить вслух
то я знаю его лично…
что-что а мозга у автора работает…
и выступал он на HiLoad не плохо
но есть у него и свои недостатки,
о которых неэтично говорить вслух
судя по той белибирде, которая изложена в топике, либо автор — не тот, о ком вы думаете, либо на HL вы были слабо знакомы с темой HL как таковой и купились на buzzwords.
с первым суждением я согл
второе обдумываю
второе обдумываю
есть конечно третий вариант: после выступления на HL, у автора снесло крышу и он начал гнать охинею ;-)
нет в авторе я не ошибся… проверил его проекты — это он.
как его пропустили на Ни++, я даже не представляю,
с темой HL я знаком не по наслышке и мои замечания можно найти в этом посте, хотя я как любитель флуда, немного пофлудил и здесь. Полночь, Луна в зените… а почему и не по размышлять…
Но, что я замечу — автор, действительно оригинал (я имею ввиду в жизни ).
как его пропустили на Ни++, я даже не представляю,
с темой HL я знаком не по наслышке и мои замечания можно найти в этом посте, хотя я как любитель флуда, немного пофлудил и здесь. Полночь, Луна в зените… а почему и не по размышлять…
Но, что я замечу — автор, действительно оригинал (я имею ввиду в жизни ).
Статья — самопиар, много о себе и ничего людям.
Автор просто написал список инструментов, которые ему нравиться использовать, не более. Ещё, в добивку, в описании использовал сокращения с которыми многие попросту не знакомы, как я могу понять что такое «DNS round-robin, либо по BGP с получением статуса AS.»? Эта фраза должна прибавить мне знаний данной тематики?
Автор просто написал список инструментов, которые ему нравиться использовать, не более. Ещё, в добивку, в описании использовал сокращения с которыми многие попросту не знакомы, как я могу понять что такое «DNS round-robin, либо по BGP с получением статуса AS.»? Эта фраза должна прибавить мне знаний данной тематики?
дык это и доказывает, что автор в достаточной мере владеет «широтой и мастшабом модели»
кто незнаком — пусть пропустят, кому надо — возьмет на заметку )
кто незнаком — пусть пропустят, кому надо — возьмет на заметку )
Что на заметку брать? Если автор знаком, то пусть передаст знания — напишет статью побольше (или серию) в которой нормально раскроет все аспекты данной проблемы и предложит разные варианты решений (лучше всего с аргументами по поводу производительности).
Сам факт того, что автор чем-то владеет пользы хабранароду не даст.
Сам факт того, что автор чем-то владеет пользы хабранароду не даст.
из хабранарода:
пусть автор форкает еще проект — мы за, но второй гугл (русский?) строить… не подымутся
пусть автор форкает еще проект — мы за, но второй гугл (русский?) строить… не подымутся
Цель данного материала не разжевать всё для людей не знакомых с мат. частью, описывая к примеру что такое AS и BGP, Zebra, и т.д.
Sapienti sat. Человек, которому это надо — в любом случае пойдет и прочтёт о каждом пункте не один десяток экран, тот которому это не надо, не будет тратить своё хабравремя на чтение таких вещей и пойдет дальше.
Сколько бы статей вы ни прочли, сколько бы лекций не выслушали… Вы ничего не добьетесь, пока не научитесь думать и исследовать САМОСТОЯТЕЛЬНО.
Подумайте как сделать хорошо, напишите, поймете что вы придумали на самом деле плохо. Повторите сначала раз 5-10 учитывая свои ошибки, и вот тогда вы сделаете что-то по-настоящему хорошее. Со временем конечно количество итераций будет уменьшаться, однако не бойтесь ошибаться и начинать с чистого листа.
Плохой учитель преподносит истину, хороший учит ее находить. — А. Дистервег
Sapienti sat. Человек, которому это надо — в любом случае пойдет и прочтёт о каждом пункте не один десяток экран, тот которому это не надо, не будет тратить своё хабравремя на чтение таких вещей и пойдет дальше.
Сколько бы статей вы ни прочли, сколько бы лекций не выслушали… Вы ничего не добьетесь, пока не научитесь думать и исследовать САМОСТОЯТЕЛЬНО.
Подумайте как сделать хорошо, напишите, поймете что вы придумали на самом деле плохо. Повторите сначала раз 5-10 учитывая свои ошибки, и вот тогда вы сделаете что-то по-настоящему хорошее. Со временем конечно количество итераций будет уменьшаться, однако не бойтесь ошибаться и начинать с чистого листа.
Плохой учитель преподносит истину, хороший учит ее находить. — А. Дистервег
хороший пост.
Не бери все близко к сердцу,
меня тоже вчера статью про то как я искал где и почему падает мемкеш раскритиковали и наминусовали. А я так, попутно методики поиска еще и раскрыл протокл мемкеш и как его использовать для отладки. Многи не способны увидеть в статье главное.
ну а остальное — оффтоп
Не бери все близко к сердцу,
меня тоже вчера статью про то как я искал где и почему падает мемкеш раскритиковали и наминусовали. А я так, попутно методики поиска еще и раскрыл протокл мемкеш и как его использовать для отладки. Многи не способны увидеть в статье главное.
ну а остальное — оффтоп
Я не против искать информацию самостоятельно, но зачем тогда был этот сумбурный пост? ИМХО в нём нет даже начального толчка для качественных самостоятельных исследований, нет даже примеров проблем с которыми люди обязательно столкнуться, которые вы уже решили. Я всегда думал что текст существует для накапливания информации, вы же его использовали в качестве самопиара и информационного шума.
Вот какой смысл мне знать что вы использовали? Если я захочу узнать о том как построить гугл я прочту о архитектуре гугла.
Вот какой смысл мне знать что вы использовали? Если я захочу узнать о том как построить гугл я прочту о архитектуре гугла.
здесь нечего брать
дык тема cloud computing раскрыта или не?
Как-то не согласуется у меня информация из вашего хомяка с внешним видом и манерой подачи материала докладчика на хайлоаде про пхпдемона.
там были вы или не вы?
там были вы или не вы?
Файлы хранятся в базе данных по методологии GridFS, существует реализация в виде FUSE-модуля.
Хотелось бы подробнее об этом узнать. Скажем загрузил пользователь аватарку (а может вам надо хранить favicon для поисковика). Файл этот надо будет раздавать через nginx. Как?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Делаем правильную платформу или Как повторить Google