Очень странные какие-то примеры функций и их использования в документации:
set_header($name, $value) и пример его использования: Output::set_header('Content-type', 'Content-type: application/pdf');
Мне как-то кажется проще сразу написать header('Content-type: application/pdf');
Или функция send_headers(), которая, насколько я понял, повторяет родную php'шную flush().
Cookie::get() — очень забавная вещь. Как сказано в документации, позволяет читать переменную $_COOKIE. Интересно, что мне мешает читать ее самому.
Фреймворк, который вместо предоставления готовых функций и алгоритмов дает синонимы стандартным функциям, вызывает улыбку, но никак не желание его использовать.
Накатал за пару часиков. Правила конечно же не все заложил, да и это работа не одного дня. Но все же: dvx-dev.ru/plural.php
Вводим слово в именительном падеже (в ед. числе, разумеется). Можно добавить прилагательное впереди.
ООП ради ООП?
А функции mysql_ все еще актуальны, как ни странно, т. к.
а) не везде mysql собран с поддержкой mysqli
б) mysqli дает больше возможностей, но какая разница, если эти возможности нет нужды использовать?
Насколько я понял, суть всей реорганизации описана в самом топике. Т. е. выставили суровые планы по увеличению прибыли с нереальными при данной организации мерами и сроками.
Если смогу получить от EMS больше информации — сообщу либо здесь в каментах, либо отдельным постом.
Утилитка — это конечно хорошо. Но написать подобную утилиту ничуть не проще, чем прописать конфиг в DNS-сервере. Другое дело, если утилитка будет наподобие денверовской — сканировать папки и создавать сразу и в Апаче виртуальные хосты. Избавить от разработчика от необходимости править конфиги вообще раз и навсегда — хорошая затея. Но тогда остается открытым вопрос с поддержкой wildcard — в нем иногда появляется необходимость, если человек работает над крупными проектами.
Третий вариант, но только потому, что разработка идет в процессе учебы (хотя опытное и разумное руководство в любом проекте не лишнее). Поскольку студенты не имеют достаточного опыта и знаний о разработке ПО и конкретных технологиях, то должен быть человек, который будет руководить проектом и указывать на ошибки в архитектуре/коде и требовать их исправления.
В противном случае проект либо не будет закончен либо не будет нести никакой пользы. И уж точно не будет развиваться в дальнейшем.
Но само по себе участие студентов в разработке «живых» проектов будет очень полезно. Как для развития этих проектов, так и для студентов, ведь они смогут получить бесценный опыт. Плюс это было бы очень полезно для развития Open Source в целом.
Причем это касается не только студентов-программистов, но и менеджеров и управленцев, потому как любой проект необходимо продвигать, поддерживать (не только код), развивать (кто-то должен проводить анализ рынка и находить пути развития проекта, чтобы поддерживать его спрос). Кто-то в конце концов должен управлять разработкой и продвижением.
Кстати, насчет граблей с NetworkManager, когда resolv.conf прописывается.
Если нет возможности или не хочется прописывать DNS ручками в параметрах IPv4, а хочется так и оставить все полностью на DHCP, можно поступить следующим образом:
Запускаем любимый текстовый редактор с правами суперпользователя (sudo gedit, например) и открываем файлик /etc/dhcp3/dhclient.conf. Далее нам нужно раскомментировать (или добавить, если отсутствует) строку: prepend domain-name-servers 127.0.0.1;
Поднимал у себя на локальной машине DNS для разработки. Только у меня мотивы были другие — в ряде проектов требуется wildcard-поддомены. Для простого проекта, который крутится на одном домене прописать в /etc/hosts одну строчку несложно. Но когда у на сайте должно быть что-то вроде company1.myproject.lh, company2.myproject.lh и т. д. до бесконечности (или как поддомены профилей пользователей здесь — на хабре), то /etc/hosts прописывать уже неудобно.
С одной стороны для простых проектов практически нет разницы, прописывать домен в /etc/hosts или в конфиге DNS, с другой — свобод и возможностей DNS дает больше.
Идея хороша, да :-)
Вообще я имел ввиду случай, когда домен предоставляется в пользование третьему лицу на какой-то срок.
Аналогично тому, как я могу доверить управление своей машиной соседу, но ведь если сосед въедет в кого-нибудь на дороге, отвечать за это ведь не мне, хоть и машина была моя. Примерно по такому же принципу и здесь.
Кстати, в собственной жизни имел случаи, когда владелец домена и сайта — не совсем одно и то же.
Я, если честно, слабо понимаю, как доменное имя связано с нарушением авторских прав. Во-первых, ссылаться оно может на любой IP, любой сервер. Во-вторых, факт размещения на этом сервере объектов авторских прав без согласия владельцев нужно доказывать. Три — в этом случае нужно отключать хостинг, но не домен (а если домен вообще принадлежит не владельцу сайта?). Четыре — если контент размещают пользователи и есть соглашение/дисклеймер/публичная оферта, где сказано, что пользователи несут ответственность в случае чего? Пять — файл торрента непосрественно не содержит в себе ничего, кроме адреса трекера и списка файлов. Скачивается все фактически с пользователей вне домена, так почему бы не вести следствие именно в сторону выяснения кто из пользователей незаконно предоставляет определенный контент?
А так тут и нарушение договора со стороны РуЦентра, и необоснованное требование (хотя это вовсе даже и не требование, что во многом смягчает недоумение по поводу действий органов) следствия.
Фактически таким образом можно приостановить деятельность абсолютно любого сайта.
вообщем-то подобную вещь можно просто кешить… и без разницы, делает это квик, сделал это разработчик, или же реализован какой-то другой механизм на php.
да и в реальных проектах не так уж часто встречаются подобные конструкции.
в любом случае хочется увидеть конкретные сравнения с другими продуктами. не только в общих словах, т.к. реализации сильно отличаются, насколько я понимаю.
Было бы интересно увидеть конкретные цифры в сравнении производительности.
А заодним можно сравнить и с Блитзом (хоть Блитз и не на пхп написан, но раз уж тут заявляют про быстрее «php native» :-)
По моему мнению, основная часть проблемы вовсе не в простоте и нетребовательности синтаксиса и не в том, что новичка книги и крайне поверхностные статьи не учат использовать MVC и фреймворки (это может быть даже хорошо, новичку это не к чему, ему основы надо выучить).
Проблема в том, что многие новички не могут или не хотят вникать в то, что в действительности делает машина при выполнении той или иной конструкции языка. И из-за этого непонимания и рождается куча быдлокода. Решение — научить людей думать, а начинающих программистов «заставить» понять, как работает машина.
В то же время, новички еще не сталкиваются с крупными проектами, разрабатываемыми в команде и поддерживаемыми третьими лицами (или ими же, но на протяжении длительного времени). И потому не понимают (или не хотят понять), что код должен быть понятен не только им и не только сейчас.
Если сразу начать учить всех работе с фреймворками, впихивать в головы MVC и т. д., ничего хорошего мы не получим. Заставив новичков работать через фреймворки мы лишим их главного — возможности научиться разрабатывать самостоятельный код и понимать принципы его работы (это проявится как только такого программиста мы посадим писать крупный проект, где функциональности фреймворка не хватит, а то и вовсе его использование будет неоправданным или ненужным).
Разрекламируем MVC еще больше и подсадим всех на него? Получим другую крайность.
Ведь все это не панацея.
Надеюсь, что там действительно будут эти карточки… ИМХО только нормальной видеосистемы простым макбукам сейчас нехватает, поиграть-то хочется во что-нибудь не очень старое, а получается что игры нормально потянет только Pro-версия…
WinXP SP2, 3.0.3. Работает.
Но если все же в зависимости от платформы система может терять работоспособность — это совсем не плюс владельцам ресурса (непонятно, зачем блокировать ресурс для определенных браузеров под определенными системами и в чем для них сложность сделать систему рабочей — онлайн ведь с HTML'ом :-)
set_header($name, $value) и пример его использования: Output::set_header('Content-type', 'Content-type: application/pdf');
Мне как-то кажется проще сразу написать header('Content-type: application/pdf');
Или функция send_headers(), которая, насколько я понял, повторяет родную php'шную flush().
Cookie::get() — очень забавная вещь. Как сказано в документации, позволяет читать переменную $_COOKIE. Интересно, что мне мешает читать ее самому.
Фреймворк, который вместо предоставления готовых функций и алгоритмов дает синонимы стандартным функциям, вызывает улыбку, но никак не желание его использовать.
Вводим слово в именительном падеже (в ед. числе, разумеется). Можно добавить прилагательное впереди.
я думал, алгоритм подстановки слова в нужной форме уже ни для кого не секрет :-)
А функции mysql_ все еще актуальны, как ни странно, т. к.
а) не везде mysql собран с поддержкой mysqli
б) mysqli дает больше возможностей, но какая разница, если эти возможности нет нужды использовать?
Если смогу получить от EMS больше информации — сообщу либо здесь в каментах, либо отдельным постом.
В противном случае проект либо не будет закончен либо не будет нести никакой пользы. И уж точно не будет развиваться в дальнейшем.
Но само по себе участие студентов в разработке «живых» проектов будет очень полезно. Как для развития этих проектов, так и для студентов, ведь они смогут получить бесценный опыт. Плюс это было бы очень полезно для развития Open Source в целом.
Причем это касается не только студентов-программистов, но и менеджеров и управленцев, потому как любой проект необходимо продвигать, поддерживать (не только код), развивать (кто-то должен проводить анализ рынка и находить пути развития проекта, чтобы поддерживать его спрос). Кто-то в конце концов должен управлять разработкой и продвижением.
Если нет возможности или не хочется прописывать DNS ручками в параметрах IPv4, а хочется так и оставить все полностью на DHCP, можно поступить следующим образом:
Запускаем любимый текстовый редактор с правами суперпользователя (sudo gedit, например) и открываем файлик /etc/dhcp3/dhclient.conf. Далее нам нужно раскомментировать (или добавить, если отсутствует) строку: prepend domain-name-servers 127.0.0.1;
С одной стороны для простых проектов практически нет разницы, прописывать домен в /etc/hosts или в конфиге DNS, с другой — свобод и возможностей DNS дает больше.
Вообще я имел ввиду случай, когда домен предоставляется в пользование третьему лицу на какой-то срок.
Аналогично тому, как я могу доверить управление своей машиной соседу, но ведь если сосед въедет в кого-нибудь на дороге, отвечать за это ведь не мне, хоть и машина была моя. Примерно по такому же принципу и здесь.
Кстати, в собственной жизни имел случаи, когда владелец домена и сайта — не совсем одно и то же.
А так тут и нарушение договора со стороны РуЦентра, и необоснованное требование (хотя это вовсе даже и не требование, что во многом смягчает недоумение по поводу действий органов) следствия.
Фактически таким образом можно приостановить деятельность абсолютно любого сайта.
да и в реальных проектах не так уж часто встречаются подобные конструкции.
в любом случае хочется увидеть конкретные сравнения с другими продуктами. не только в общих словах, т.к. реализации сильно отличаются, насколько я понимаю.
А заодним можно сравнить и с Блитзом (хоть Блитз и не на пхп написан, но раз уж тут заявляют про быстрее «php native» :-)
Проблема в том, что многие новички не могут или не хотят вникать в то, что в действительности делает машина при выполнении той или иной конструкции языка. И из-за этого непонимания и рождается куча быдлокода. Решение — научить людей думать, а начинающих программистов «заставить» понять, как работает машина.
В то же время, новички еще не сталкиваются с крупными проектами, разрабатываемыми в команде и поддерживаемыми третьими лицами (или ими же, но на протяжении длительного времени). И потому не понимают (или не хотят понять), что код должен быть понятен не только им и не только сейчас.
Если сразу начать учить всех работе с фреймворками, впихивать в головы MVC и т. д., ничего хорошего мы не получим. Заставив новичков работать через фреймворки мы лишим их главного — возможности научиться разрабатывать самостоятельный код и понимать принципы его работы (это проявится как только такого программиста мы посадим писать крупный проект, где функциональности фреймворка не хватит, а то и вовсе его использование будет неоправданным или ненужным).
Разрекламируем MVC еще больше и подсадим всех на него? Получим другую крайность.
Ведь все это не панацея.
Но если все же в зависимости от платформы система может терять работоспособность — это совсем не плюс владельцам ресурса (непонятно, зачем блокировать ресурс для определенных браузеров под определенными системами и в чем для них сложность сделать систему рабочей — онлайн ведь с HTML'ом :-)