Разное

Да, согласен ситуация меняется, однако, проекты вроде wikipedia и facebook во-первых единичны, во-вторых постоянно дополняются и переписываются - не на PHP3 они работают - поэтому можно сказать, что код и в них живёт не долго. Проекты на PHP могут жить долго - код пока нет.

+
соглашусь во многом.

Тоже присоединюсь к благодарностям, действительно очень хорошо что вы есть)))
Особенно радует наличие форума и изумительной поддержки оного. Книга "PHP5 Практика создания WEB сайтов", достаточна тяжела для восприятия, абсолютным новичком. Но на форуме всегда найдутся знающие люди,в том числе и авторы(что особенно радует) готовые пролить свет на темные пятна. Так же не могу не отметить, тот факт, что это вторая книга из моей достаточно обширной библиотеки, которая себя окупила и даже принесла небольшой доход))
По этому поводу родился небольшой экспромтик))

Спасибо вам за то что есть,
Учить других, у вас желание
И не сочтите стих, за лесть,
Тем кто уже достиг признания

Спасибо вам за то что есть
У вас терпение, время, силы
Писать учебники, и здесь
Учить ленивых имбицилов

Спасибо вам за то что есть
LiteForum и скриптов немного
И постов всех не перечесть
С готовым и полезным кодом

Спасибо вам за то что есть
На форуме, злой модератор
Следит внимательно, чтоб честь
Свою, не уронил шальной оратор

Спасибо вам за всё Софттайм
Пускай и впредь, все будет также
Пусть лучшим будет ваш дизайн
И не будет места лаже

PS Может не очень суперский стишок, но как умею))

Рискую опять начать вечный спор о жизнеспособности и применимости пхп, но всё же.

> который живёт от нескольких месяцев до полугода.
facebook, flikr и т.д. несколько лет живут с нехилой нагрузкой.
> не мы его выдумали и не мы взяли моду так писать
А кто?
> выполняющаяся, как правило, одним человеком
Ну это, в современных условиях (SVN), скорее не так.
> причём разработчики языка ещё и масла в огонь подливают
Вот это вообще мне не понятно. В чём в пятой версии пхп заключается масло? По-моему наоборот всё идёт в направлении увеличения стройности и мощности языка.

PS Я перешёл на пхп после 7-ми лет паскаля и дельфи. И мне не показался он каким-то вычурным и непонятным. Хотя с++ я тогда боялся как огня :) Зато сейчас, после 4 лет php, изучение с++ идёт как по нотам.

Требования к книгам всегда противоречивые - они должны быть читабельны, не утомлять и в то же время помогать читателю понять ту или иную область быстрее. Попробуйте написать книгу в соответствии с гостом, модой и широкой функциональностью - скорее всего ничего не получится, или это не будет продаваться.

PS Промышленный код и книги - две большие разницы - промышленную систему описать в деталях в книге просто не выйдет или её будут читать только разработчики системы. Задача книг (наших по крайней мере), подготовить человека к работе с промышленным кодом.
PPS Книгу, которую вы хотите видеть я бы тоже с удовольствием почитал бы (даже может и написал бы), однако издательство скорее всего столкнётся с тем, что продаваться она будет со скорость 40 экз. в месяц. Это просто нужно выпускать компакт диск или дистрибутив - причём код разрабатывать сразу с прицелом на Гост и спец.оформление, а не на PHP-разработчиков. Сам язык (PHP) неортогонален - слишком уж грязно сделан. PHP - это ответ на огромный спрос Web-разработки - он позволяет быстро разрабатывать медленный скриптовый код, который живёт от нескольких месяцев до полугода. Он вообще не заточен на "потом" - это язык "сейчас" (не мы его выдумали и не мы взяли моду так писать - я в свое время, как C++ разработчик, тоже был шокирован PHP-стилем - в Perl это хотя бы стиль - тут просто окрошка, выполняющаяся, как правило, одним человеком - причём разработчики языка ещё и масла в огонь подливают).

Мне кажется надо понимать аудиторию книг от софттайма.
Это, в основном(!), начинающие. И забивать голову такими advanced вещами, как документирование кода, на начальном этапе вряд ли стоит.

Если удержишься в профессии, то сам рано или поздно дойдёшь до осознания необходимости ООП, модульного тестирования, документирования и т.д. Это уже промышленное программирование. Тут и требования другие и литература.

http://mycontent.tv/books/

Увы, если бы так было в этом мире просто. Приходилось ли Вам сталкиваться с таким архаизмом как
ГОСТ 19.701-90
--------------------------------------------------------------------------------
Группа Т5
--------------------------------------------------------------------------------
Единая система программной документации
СХЕМЫ АЛГОРИТМОВ, ПРОГРАММ, ДАННЫХ И СИСТЕМ

Или оформлять авторские свидетельства на созданный Вами программный комплекс?
"Коль взялся за гуж, то не говори, что не дюж".
Люди учатся по книгам SoftTime. И рано или поздно им (читателям) придется заниматься серьезными вещами, а значит, и оформлять свои продукты по определенным правилам. И чем раньше начать придерживаться этих правил, тем проще потом будет.
Относительно моей персоны, я (боже упаси) не навязываю свое мнение и тем паче ничего для себя не требую. Просто мысли вслух, в кругу единомышленников.

Поэтому, мне кажется, что в моих сентенциях есть доля истины.

никто вам ничего не обязан, каждый вправе считать свое мнение более правильным чем у остальных, ваше личное право и право всех остальных оформлять документацию, файлы и тд. так как они считают нужным...

>> Мир не без злых людей
Не помню, чья цитата: «… Для дела гораздо важней иметь одного поперечника, чем сто соглашателей». Поэтому надо быть осторожней с «наклеиванием» ярлыков. А в целом коль сотрудники СофтТайма взвалили на себя ношу делиться своими знаниями, то давайте это делать еще профессиональней. В целом всем ВАМ спасибо, за книги, за сайт, но в жизнь не только бочка с медом, но и ложка дегтя имеет место быть:
Итак, о ложке дегтя. Чъяо Пхядьяо высказал до сих пор актуальную мысль: «…Только глупец полагает, что его предшественники оставили после себя, только свои ошибки и заблуждения»:
1. Итак есть общепризнанные правила документирования:
• Каждый скрипт оформленный в виде отдельного файла начиная со второй строки должен иметь раздел документирование (назначение, описание функционального алгоритма, в зависимости от сложности, описание входных/выходных параметров, аварийные завершения).
• Перед каждой функцией, методом – должны быть строки комментариев (см. пункт выше).
• Отдельные модули группировать в библиотеки в виде файла (действительно не всегда разумно модуль в «пару строк» заталкивать в отдельный файл) или использовать каталоги с файлами общей тематики.
• PEAR-соглашениях, также настойчиво рекомендуют перед функциями, методами обрамляя символами /** ….**/ помещать описание (назначение, входные, выходные параметры, аварийные выходы). (см. раздел «аппарат отражений» - метод getDocComment()). Кстати, при проектировании модулей явно (на листке бумаги или в электронном документе) или неявно (держим в голове) это приходится делать любому программисту.
• Список можно продолжить (предлагаю это сделать сообществу)….
Последствия пренебрежения этим правилам налицо. Это обилие повторяющегося кода в различных файлах. Причем обвинять в этом системных аналитиков и тесторов не совсем справедливо. Удержать все коды в голове (а их получается за сотню) и выявить все повторы – нереально. А вот если бы скрипты были документированы. То даже при беглом просмотре документации насторожил бы факт – наличие повторяющихся описаний для различных файлов.
2. Оформление незначительного количества измененных скриптов осуществляется, как правило, осуществляется виде патчей (fix pack), которые (эти скрипты) собираются в одну установочную библиотеку, а не весь пакет (т.н. последние изменения в LiteForum 5.0.2 коснулись лишь 8 файлов). Предлагалось скачать все.
3. Что лучше “абсолютная или относительная адресация»? В Ваших скриптах отдается предпочтение (../../ и т.д.) не вспомню в какой из книг по администрированию Unix этот подход разбили в пух и прах. Действительно если ненароком переместишь файл с использованием этого подхода. То ... караул.
Эта мысль о порочности комбинации (../../ и т.д.) проскальзывает и в книге Д.Котеров, А Костарев «PHP 5». Их решение – использование функция ini_set() в конфигурационном файле.
(фрагменты текста книги)
«….Пример смены конфигурации
# добавить путь поиска библиотек
ini_set("include_path", getenv("DOCUMENT_ROOT")."/lib");
#....
# теперь можно подключать библиотеку
requere_once "library_name.php";

Листинг 31.2 Файл lib/config.php
<?php ##Главный конфигурационный файл сайта
//Подключается ко всем сценариям (автоматически или вручную)
if (!defined("PATH_SEPARATOR"))
define("PATH_SEPARATOR", getenv("COMSPEC")? ":" : ";"); // windows/unix
ini_set("include_path", ini_get("include_path").PATH_SEPARATOR.dirname(__FILE__);
?>
Расписался. Закругляюсь. Лишь пару фраз:
• От Сент-Экзюпери: « …Мы ответственны за тех, кого приручили …».
• У Вас не плохие книги. Их читают. Но, пора, наверное, готовить третье издание с учетом этой темы и полученным резонансом от участников форума.

Присоединяюсь к благодарностям! Благодаря тем знаниям, которые я получил из книжки PHP5. Практика создания WEB-сайтов мне предложили (меня САМИ ПОЗВАЛИ :)) перевести простенький сайт с html на php. + добавить все что смогу и оптимизировать.
Это моя ПЕРВАЯ подработка в той сфере в которой мне ДЕЙСТВИТЕЛЬНО НРАВИТСЯ работать :)
Надеюсь остаться работать в этой же сфере! :)
Спасибо Максиму Валерьевичу Кузнецову, Игорю Вячеславовичу Семидянову, Сергею Вячеславовичу Голышеву и всем остальным участникам проекта SoftTime!