Что бы сменить пароль надо 20 секунд максимум.
За 2 часа к этому топику больше полутросотни коментариев, среди которых единственного чего нет — это только «ну все, пойду повешусь». Я даже не заметил как пролетела эта формочка — ну надо сменить пароль — сменил. Всё.
Еще раз. Что бы сменить пароль надо 20 секунд максимум. Обычно хватает 5-ти.
А Бюро Пирогова кладет на клиентов из провинции :-) Как и многие другие кстати. Не в их инетересах работать с клиентами, которые себе нормальный инет обеспечить не могут.
Да, не очень внимательно прочитал. Но тем неменее мысль остается — в большинетве случаев поиск или нужен с дополнительными параметрами или не нужен вообще ибо как вы правильно высказались он тутже прямиком из яндекса приводит туда куда нужно.
Интересно, а существует хотя бы один разработчки php, который НЕ неписал бы своей цмс?.. Я вот их 4 штуки написал :-)
Конечно, это полезно. Но по секрету скажу, еще лучше написать систему, которая бы была орентированна на конкретные задачи, ибо почти все ныняшние ЦМС обладают бы сходными функциями (кого еще тошнит от слов «Новости», «Статьи», «Галерея», «О компании», «Главная» итдитп?).
Поясню свои слова. Вот напрмер сделать систему, которая нужна строго для сайтов визиток. Но сделать её проактически идеальной? Просто думаете да? Ничего подобного. Тут до такой степени дофига надо всего учесть, что тривиальная задача становится очень сложной. Хотя бы парсинг экселевских файлов для автоматической загрузки прайсов и/или формирование этих экселевских прайсов.
Бытует мнение, что хороший сайт должен иметь свой поиск. Вы заказчикам расскажите что поиск на сайте будет через яндекс :-) Их эта идея не вдохновит, уверяю вас.
Поиск часто бывает специализированным, т.е. с дополнительные параметрами, а вот про это вы не слова не сказали. И тут поисковикам делать нечего совершенно. А как правило именно такой поиск и бывает действительно нужен. Что же касается поисковых систем, то вы сначала должны как-то прийти на этот сайт, а вот это уже задача последних.
Вобщем, вы все правильно изложили, но только тогда когда у нас сайты состоят только из набора статических страниц или статей.
Прграммирование — это ваще никак не наука, это искусство создания программ. Похоже, вы не читали Кнута, если даже не обратили внимание как называны его книги. :-)
А наука о алгоритмах так и называется «Теория алгоритмов».
Предложения в русском языке начинаются с большой буквы. Фамилии людей тоже пришутся с большой буквы. Это так слову, если вы уж о Дейкстре заговорили.
К сожалению, в данное время наличии знаний математического программирования и сопутствующих наук не делают из вас хорошего программиста. Ранее математика и программирование очень сильно соприкасались, сейчас уже почти нет. Поэтому время и прошло.
Как и всегда — работать и совершенствоваться. Решать различные задачи, в различных предметных областях различными методами. Приходить с работы домомой и снова садиться за комп для изучения уже чего то принципиально другого. И как можно больше впихивать в себя новую информацию.
Зачем?
Потому что пытаясь изучить, то что будет пользоваться спросом завтра, вы неизбежно проиграете. Самое лучшее что можно развить в себе прежде всего (и наверно единственное) — это пыстро разбираться в новом материале. Если достигнете этого, то неизбежно, что не стало бы пользоваться спросом, вы всегда это сможете быстро в себе развить. Именно этому и учат в институтах — интеллекту и скорости мышления, а не дифурам и культорологии как думают многие. Поэтому в ВУЗе на самом деле все предметы важны, потому что важны не сами знания, а те способности, которые вы приобретаете изучая эти знания.
Но достигнуть этого можно только при том условии, что профессия вам действительно нравится.
Раз уж вы «рады любым отзывам, идеям и замечаниям», то позволю еще чуть-чуть докапаться. :-)
> 1. Когда программа недостаточно быстро получает данные и растёт время простоя. Например,
> при генерации красивого графика можно одним потоком получать данные из СУБД
> (выполняется тяжелый запрос), а во втором потоке производить отрисовку.
Пример несколько неудачен, так как график можно построить только из результатов выборки. Если конечно мы не строим с десяток графиков, но об этом чуть позже. Кстати, параллелить процессы во время работы сайта — это как правило не очень умно, поскольку нормальная система кеширования делает простои минимальными.
> 2. Когда нужно выполнить несколько операционных задач, и более эффективно
> задействовать процессор.
Еще б уточнить, что это за «операционные задачи» и тогда вообще все шоколадно. Более эффективно задействовать процессор тоже хорошо, но к сожалению не всегда реализуемо, ибо время работы процессора в большинстве случаев крайне ничтожно, а основное время работы — это опреции ввода-вывода.
А теперь действительно ГДЕ это может быть примерено и почему.
1. В создании «демонов» на php. Изредка приходится с этим сталкиваться, пример тому различные обработки очередей, сервисы типа flashpolicyd, обслуж.ивание сайтов (например очистка кеша при излишнем его разрастании и др.). Воббще, демон часто способен решить задачи, которые простые скрипты будут решать менее эффективно. А без pcntl демона нормально не напишешь.
2. При задачах, где требуется одновременно обработать большое количество однотипных объектов, которые обрабатываются достаточно долго. Например, рассылка писем, поисковая индексация, «сбор» RSS-лент и др. С графиками тут тоже пример хороший: если надо сделать этак десятка два сразу, то можно при генерации страницы запустить постройку этих графиков и отрендерить страницу. Пока страница дойдет до клиента, браузер её отрендерит и сделает запрос по ссылкам на эти самые графики, то они будут уже построены. Можно легко обойтись и без pcntl, но это действительно будет менее эффективно.
3. В случаях, когда требуется выполнить действитя, котоыре занимают достаточно продолжительное время, но не влияют на результат. Напрмер, копирование больших файлов, которые загрузил пользователь или работа с большими изображениями и т.д. Тогда в одном процессе можно генерить страницу дальше, а другом запустить обработку, благо нам не нужен результат от неё немедленно. Опять же: можно обойтись и без pcntl, но будет хуже.
Вот как-то так. Со всеми этими случаями сталкивался лично на практике, и распараллеливание приносило хорошие результаты
Ну про «эмуляцию» многопоточности на php писали очень много. Например, в качестве «другого» метода может быть непосредственный вызов скрипта в фоновом режиме с отправкой вывода в dev/null. Чем не эмуляция? Да, я знаю что это намного хуже но работает много где, в отличие от pcntl который далеко не на каждом хостинге установлен.
За 2 часа к этому топику больше полутросотни коментариев, среди которых единственного чего нет — это только «ну все, пойду повешусь». Я даже не заметил как пролетела эта формочка — ну надо сменить пароль — сменил. Всё.
Еще раз. Что бы сменить пароль надо 20 секунд максимум. Обычно хватает 5-ти.
Далее идет график, в котором присутствует все браузеры, кроме IE.
Конечно, это полезно. Но по секрету скажу, еще лучше написать систему, которая бы была орентированна на конкретные задачи, ибо почти все ныняшние ЦМС обладают бы сходными функциями (кого еще тошнит от слов «Новости», «Статьи», «Галерея», «О компании», «Главная» итдитп?).
Поясню свои слова. Вот напрмер сделать систему, которая нужна строго для сайтов визиток. Но сделать её проактически идеальной? Просто думаете да? Ничего подобного. Тут до такой степени дофига надо всего учесть, что тривиальная задача становится очень сложной. Хотя бы парсинг экселевских файлов для автоматической загрузки прайсов и/или формирование этих экселевских прайсов.
Поиск часто бывает специализированным, т.е. с дополнительные параметрами, а вот про это вы не слова не сказали. И тут поисковикам делать нечего совершенно. А как правило именно такой поиск и бывает действительно нужен. Что же касается поисковых систем, то вы сначала должны как-то прийти на этот сайт, а вот это уже задача последних.
Вобщем, вы все правильно изложили, но только тогда когда у нас сайты состоят только из набора статических страниц или статей.
Единственное к чему можно придраться это «многопоточность в OS», хотя по смыслу тут более подходит «многозадачность в OS».
А наука о алгоритмах так и называется «Теория алгоритмов».
К сожалению, в данное время наличии знаний математического программирования и сопутствующих наук не делают из вас хорошего программиста. Ранее математика и программирование очень сильно соприкасались, сейчас уже почти нет. Поэтому время и прошло.
Зачем?
Потому что пытаясь изучить, то что будет пользоваться спросом завтра, вы неизбежно проиграете. Самое лучшее что можно развить в себе прежде всего (и наверно единственное) — это пыстро разбираться в новом материале. Если достигнете этого, то неизбежно, что не стало бы пользоваться спросом, вы всегда это сможете быстро в себе развить. Именно этому и учат в институтах — интеллекту и скорости мышления, а не дифурам и культорологии как думают многие. Поэтому в ВУЗе на самом деле все предметы важны, потому что важны не сами знания, а те способности, которые вы приобретаете изучая эти знания.
Но достигнуть этого можно только при том условии, что профессия вам действительно нравится.
> 1. Когда программа недостаточно быстро получает данные и растёт время простоя. Например,
> при генерации красивого графика можно одним потоком получать данные из СУБД
> (выполняется тяжелый запрос), а во втором потоке производить отрисовку.
Пример несколько неудачен, так как график можно построить только из результатов выборки. Если конечно мы не строим с десяток графиков, но об этом чуть позже. Кстати, параллелить процессы во время работы сайта — это как правило не очень умно, поскольку нормальная система кеширования делает простои минимальными.
> 2. Когда нужно выполнить несколько операционных задач, и более эффективно
> задействовать процессор.
Еще б уточнить, что это за «операционные задачи» и тогда вообще все шоколадно. Более эффективно задействовать процессор тоже хорошо, но к сожалению не всегда реализуемо, ибо время работы процессора в большинстве случаев крайне ничтожно, а основное время работы — это опреции ввода-вывода.
А теперь действительно ГДЕ это может быть примерено и почему.
1. В создании «демонов» на php. Изредка приходится с этим сталкиваться, пример тому различные обработки очередей, сервисы типа flashpolicyd, обслуж.ивание сайтов (например очистка кеша при излишнем его разрастании и др.). Воббще, демон часто способен решить задачи, которые простые скрипты будут решать менее эффективно. А без pcntl демона нормально не напишешь.
2. При задачах, где требуется одновременно обработать большое количество однотипных объектов, которые обрабатываются достаточно долго. Например, рассылка писем, поисковая индексация, «сбор» RSS-лент и др. С графиками тут тоже пример хороший: если надо сделать этак десятка два сразу, то можно при генерации страницы запустить постройку этих графиков и отрендерить страницу. Пока страница дойдет до клиента, браузер её отрендерит и сделает запрос по ссылкам на эти самые графики, то они будут уже построены. Можно легко обойтись и без pcntl, но это действительно будет менее эффективно.
3. В случаях, когда требуется выполнить действитя, котоыре занимают достаточно продолжительное время, но не влияют на результат. Напрмер, копирование больших файлов, которые загрузил пользователь или работа с большими изображениями и т.д. Тогда в одном процессе можно генерить страницу дальше, а другом запустить обработку, благо нам не нужен результат от неё немедленно. Опять же: можно обойтись и без pcntl, но будет хуже.
Вот как-то так. Со всеми этими случаями сталкивался лично на практике, и распараллеливание приносило хорошие результаты