Как делать бекапы и т.п. описано в мануале вполне понятным языком.
В теории, кроме отказов винтов, вы теряете изменения максимум за 60 секунд (время по-умолчанию для fsync'a). На практике же я встречал посты о том, что операция repair может испортить базу. Как с этим обстоит сейчас — не знаю.
Короче, мне кажется, если у вас только 1 сервер, то стоит дождаться версию 1.8.
Знаете что меня удивляет? Вот вы работаете тимлидом. Вместо того, чтобы вводить стандартные (в понимании многих других разрабов) вещи, которые помогут ускорить обучение, вливание в команду нового работника, вы пишите свой велосипед, который имеет серьезные минусы в плане возможностей документирования.
Было бы вас 1-2 стартапера-партнера — без проблем. Но ведь вам с подчиненными работать надо.
Конечно, «если все используют, то и мы должны» — не аргумент. Но область его применения, точнее его опровержения, не бесконечна. Должны же быть некие стандарты в корпоративной разработке.
Что я хочу сказать? На каждом углу сейчас пропагандируется ООП. Джуниоры с этого обычно и начинают. Да, используется ООП с надобностью и пониманием и без. Если у вас маленькая, слаженная и сильная команда, то можно придумывать что угодно, но если у вас есть хоть небольшая текучка кадров, то....?
Если меня подчиненный спрашивает как сделать что-то, то я расскажу ему о наиболее близком для него решению. И дам ссылок на статьи, где это описывает кто-то помимо меня, т.к. у меня могу быть проблемы с выражением мыслей.
Если в работе так и напрашивается паттерн IoC, то рассказывать я буду именно о нем. Расскажу в общем, потом дам ссылку на доку по Symphony и, возможно, покажу примеры в других языках, откуда это и пришло. Но писать собственный велосипед, по сути делающий тоже самое, лично мне бы в голову не пришло.
После прочтения резюме на вашем сайте по поводу «быдло-разработчика» беру свои слова назад.
Как мне кажется, сильный разработчик при написании такого топика начал бы его в стиле: «т.к. мне сильно не хватало таких-то фич, тут у меня появилось набор идей, но поскольку я предпочитаю доводить дела до конца, то свои идеи я оформил в следующий фреймворк и даже опробовал его на паре мелких проектах. приглашаю людей к обсуждению». На данный момент ваш текст скорее близок к «40 способам ускорить PHP».
В том, что вы выложили, я вижу попытку изобрести свою альтернативу IoC и AOP (это я про фичу с ACL, хотя тут не обязательно именно AOP). Зачем? Есть привычные всем термины и реализации. Если уж изобретаете альтернативу, то она должна быть значительно лучше, чтобы не просто оправдывать свое использование, но и оправдывать затраты на обучение. Но лично мне, дураку, совершенно не видится плюсов вашего решения в сравнении с названными паттернами. А вот минусов видится много.
И, да, в команде должен быть человек, способный сказать своему начальнику «ты мудак». В противном случае у вас слабая команда.
Поскольку пишу раз в час, то отвечу в этом комментарии на все.
> Но я люблю PHP. Я не хочу уходить с него. Да и куда?
Прекрасно, но зачем превращать PHP непонятно во что?
Я сейчас пишу одновременно и на PHP, и на Java. Для меня, как программиста, преимущества жавы очевидны. Но также для меня, как не полного идиота, очевидно, что помимо моих чисто программистких симпатий существуют рынок труда, стоимость освоения технологии, кол-во известных заказчику CMS (привет ненавистному мною Битриксу, который так легко продается благодаря бренду 1С) и т.п.
> Может быть, быдло это те, кто без автокомплита как слепые котята?
Вот есть у меня класс с названием в ~10 символов и в нем константа еще в ~20 символов. При написании кода в блокноте я должен держать еще одну табу с этим классов, чтобы быстро копи-пастить. А теперь представим, что надо писать высокоуровневую логику, где задействовано много классов. Вы их все вплоть до символа помните? В Eclipse же набираю первые символы класса, жму enter, выбираю константу и списков члена класса и снова жму enter. При этом PHPDoc помогает мне совершать меньше ошибок несоответствия типов.
> имхо человек просто ищет свой путь, вот ему в данный момент понравилось поработать с таким решением, пройдёт время он найдет другие пути и постигнет свой дзен (ну или не постигнет)
Как написано выше, об этом надо было бы сказать в начале. И не предлагать это как фреймворк к разработке, обосновывая тем, что он уже опробован на паре проектах.
> Что это за современные тенденции программирования — все усложнять
Есть такое. Сильно проявляется в мире Java. И это есть плохо. Для простенького сайта с несколькими сервлетами подключать огромный фреймворк типа Spring — идиотизм. Очень часто это не оправданно. Ровно тоже самое относится и к PHP.
> Если AOP и IOC не являются простыми и очевидными в каком-то языке, то это уже проблема языка, что нужны костыли для реализации простых идей.
Проблема языка, да. Но зачем костыли? Альтернатив много, вместо написания костылей, лучше развивать гибкость мозга, чтобы работать с тем что есть. Регулярно встречаются библиотеки для реализации «классов» на JS. Нахрена?
PHP- такой, какой есть. Хреново спроектированный, с кучей быдло-кодеров, с абсолютно большинством фич спертых из других языков с опозданием лет в 5, как минимум. Это надо либо принять, либо сменить язык. Совершенно не представляю как можно находиться посередине и чувствовать себя комфортно.
Очередной быдло-похапе-разработчик… Почитайте хотя бы про современные тенденции программирования, которые (неужели?!) начали потихоньку проникать и в мир PHP. Про тот же самый IoC.
Если вам не хватает AOP или иных, опять-таки современных, фич многих языков, то пора, наконец, осознать, что PHP — не единственный язык и дааааааалеко не лучший. Даже для web разработки.
Не надо требовать от языка того, на что он не способен. Не надо писать код с дикими извращениями вместо смены языка.
Проект надо обязательно писать на PHP и без AOP (к примеру) обойтись очень трудно? Либо поставьте модуль к PHP (а такие есть) и хоститесь как минимум на VDS, либо делайте сборщик вашего проекта с парсером исходных кодов и используйте все прелести подхода continuous integration.
ЗЫ: Как может тимлид (инфа из вашего профиля) не осознавать насколько может повысить скорость разработки хороший редактор и использование его фич — лично для меня загадка. PHPDoc, autocomplete и т.п. Понимаю, настоящие PHP разработчики пишут только в блокноте, но, бля, попробовать-то хотя бы стоило!
Чтож, перефразирую вопрос. Чем ваше решение, за которое, очевидно, надо платить денежку (как минимум за поддержку) лучше упомянутого мною решения с открытым исходным кодом? Тем более, что создавалось оно в Sun и это как-никак дает некую уверенность…
Кому-то дано строить свой бизнес и управлять людьми, а кому-то — нет. Причем последних намного больше. Всему этому никто научить не способен, поэтому придется набивать шишки самому. А без способностей такое набивание шишек может растянуться на многие-многие годы. А на что жить в это время?
Это не практик, а дурак. Знать про «галочку», но не знать что она делает — это ппц.
Давайте не будем утрировать. Если человек администрирует также, как блондинка работает в ворде, то это — некомпетентность. Если он только слышал про OSI, то это может говорить о чем угодно.
Тогда еще раз повторю: единственно верной статьей по оптимизации PHP может быть описание как пользоваться профайлером и описание где искать информацию по оптимизации базы и кеширования.
Раз приходится делать подобные микро-оптимизации, у вас узкое место — PHP. Смените язык и не страдайте фигней. Много кода, слишком долог будет перенос на другую технологию? Ок, напишите модуль к PHP на С.
Та же самая Java, если ее знать, ничуть не медленнее для разработки сайтов, а вот в плане отладки и скорости выполнения обгоняет PHP на *порядки*.
Вы работаете с языком очень высокого уровня. Основные оптимизации — алгоритмы, архитектура, смена языка. Микро-оптимизации не принесут достаточного эффекта, чтобы о них даже задумываться.
Что вам, что автору сего топика советую прочитать Макконнелла «Совершенный код», раздел про оптимизацию. Там очень хорошо показано почему рулит профайлинг живого кода и почему никогда не следуют делать синтетические тесты для попыток что-то там померить.
Что в вашем понимании «стиль» применимо к оптимизации? Писать «simplexml_load_string( file_get_contents ('file.xml') )» вместо «simplexml_load_file('file.xml')»? Без дополнительного комментария рядом это — WTF.
Поймите: единственно верной статьей по оптимизации PHP может быть описание как пользоваться профайлером и описание где искать информацию по оптимизации базы и кеширования.
Бля! Да вы сначала добейтесь такого кол-ва хитов, а потом говорите о производительности. Посещаемость сайтов обычно увеличивается экспоненциально. И оптимизировать вы станете не такие мелочи, а реально узкие места.
Использование разных хитрых конструкций для мнимого увеличения производительности ухудшает читабельность кода, не давая никаких плюсов на 99% сайтов.
Как делать бекапы и т.п. описано в мануале вполне понятным языком.
В теории, кроме отказов винтов, вы теряете изменения максимум за 60 секунд (время по-умолчанию для fsync'a). На практике же я встречал посты о том, что операция repair может испортить базу. Как с этим обстоит сейчас — не знаю.
Короче, мне кажется, если у вас только 1 сервер, то стоит дождаться версию 1.8.
Было бы вас 1-2 стартапера-партнера — без проблем. Но ведь вам с подчиненными работать надо.
Конечно, «если все используют, то и мы должны» — не аргумент. Но область его применения, точнее его опровержения, не бесконечна. Должны же быть некие стандарты в корпоративной разработке.
Что я хочу сказать? На каждом углу сейчас пропагандируется ООП. Джуниоры с этого обычно и начинают. Да, используется ООП с надобностью и пониманием и без. Если у вас маленькая, слаженная и сильная команда, то можно придумывать что угодно, но если у вас есть хоть небольшая текучка кадров, то....?
Если меня подчиненный спрашивает как сделать что-то, то я расскажу ему о наиболее близком для него решению. И дам ссылок на статьи, где это описывает кто-то помимо меня, т.к. у меня могу быть проблемы с выражением мыслей.
Если в работе так и напрашивается паттерн IoC, то рассказывать я буду именно о нем. Расскажу в общем, потом дам ссылку на доку по Symphony и, возможно, покажу примеры в других языках, откуда это и пришло. Но писать собственный велосипед, по сути делающий тоже самое, лично мне бы в голову не пришло.
Как мне кажется, сильный разработчик при написании такого топика начал бы его в стиле: «т.к. мне сильно не хватало таких-то фич, тут у меня появилось набор идей, но поскольку я предпочитаю доводить дела до конца, то свои идеи я оформил в следующий фреймворк и даже опробовал его на паре мелких проектах. приглашаю людей к обсуждению». На данный момент ваш текст скорее близок к «40 способам ускорить PHP».
В том, что вы выложили, я вижу попытку изобрести свою альтернативу IoC и AOP (это я про фичу с ACL, хотя тут не обязательно именно AOP). Зачем? Есть привычные всем термины и реализации. Если уж изобретаете альтернативу, то она должна быть значительно лучше, чтобы не просто оправдывать свое использование, но и оправдывать затраты на обучение. Но лично мне, дураку, совершенно не видится плюсов вашего решения в сравнении с названными паттернами. А вот минусов видится много.
И, да, в команде должен быть человек, способный сказать своему начальнику «ты мудак». В противном случае у вас слабая команда.
Поскольку пишу раз в час, то отвечу в этом комментарии на все.
> Но я люблю PHP. Я не хочу уходить с него. Да и куда?
Прекрасно, но зачем превращать PHP непонятно во что?
Я сейчас пишу одновременно и на PHP, и на Java. Для меня, как программиста, преимущества жавы очевидны. Но также для меня, как не полного идиота, очевидно, что помимо моих чисто программистких симпатий существуют рынок труда, стоимость освоения технологии, кол-во известных заказчику CMS (привет ненавистному мною Битриксу, который так легко продается благодаря бренду 1С) и т.п.
> Может быть, быдло это те, кто без автокомплита как слепые котята?
Вот есть у меня класс с названием в ~10 символов и в нем константа еще в ~20 символов. При написании кода в блокноте я должен держать еще одну табу с этим классов, чтобы быстро копи-пастить. А теперь представим, что надо писать высокоуровневую логику, где задействовано много классов. Вы их все вплоть до символа помните? В Eclipse же набираю первые символы класса, жму enter, выбираю константу и списков члена класса и снова жму enter. При этом PHPDoc помогает мне совершать меньше ошибок несоответствия типов.
> имхо человек просто ищет свой путь, вот ему в данный момент понравилось поработать с таким решением, пройдёт время он найдет другие пути и постигнет свой дзен (ну или не постигнет)
Как написано выше, об этом надо было бы сказать в начале. И не предлагать это как фреймворк к разработке, обосновывая тем, что он уже опробован на паре проектах.
> Что это за современные тенденции программирования — все усложнять
Есть такое. Сильно проявляется в мире Java. И это есть плохо. Для простенького сайта с несколькими сервлетами подключать огромный фреймворк типа Spring — идиотизм. Очень часто это не оправданно. Ровно тоже самое относится и к PHP.
> Если AOP и IOC не являются простыми и очевидными в каком-то языке, то это уже проблема языка, что нужны костыли для реализации простых идей.
Проблема языка, да. Но зачем костыли? Альтернатив много, вместо написания костылей, лучше развивать гибкость мозга, чтобы работать с тем что есть. Регулярно встречаются библиотеки для реализации «классов» на JS. Нахрена?
PHP- такой, какой есть. Хреново спроектированный, с кучей быдло-кодеров, с абсолютно большинством фич спертых из других языков с опозданием лет в 5, как минимум. Это надо либо принять, либо сменить язык. Совершенно не представляю как можно находиться посередине и чувствовать себя комфортно.
Если вам не хватает AOP или иных, опять-таки современных, фич многих языков, то пора, наконец, осознать, что PHP — не единственный язык и дааааааалеко не лучший. Даже для web разработки.
Не надо требовать от языка того, на что он не способен. Не надо писать код с дикими извращениями вместо смены языка.
Проект надо обязательно писать на PHP и без AOP (к примеру) обойтись очень трудно? Либо поставьте модуль к PHP (а такие есть) и хоститесь как минимум на VDS, либо делайте сборщик вашего проекта с парсером исходных кодов и используйте все прелести подхода continuous integration.
ЗЫ: Как может тимлид (инфа из вашего профиля) не осознавать насколько может повысить скорость разработки хороший редактор и использование его фич — лично для меня загадка. PHPDoc, autocomplete и т.п. Понимаю, настоящие PHP разработчики пишут только в блокноте, но, бля, попробовать-то хотя бы стоило!
На самом деле сейчас думаю ровно на эту же тему. Как и вам, совершенно не хочется отдавать 50-75% куда-то на сторону…
Давайте не будем утрировать. Если человек администрирует также, как блондинка работает в ворде, то это — некомпетентность. Если он только слышал про OSI, то это может говорить о чем угодно.
Раз приходится делать подобные микро-оптимизации, у вас узкое место — PHP. Смените язык и не страдайте фигней. Много кода, слишком долог будет перенос на другую технологию? Ок, напишите модуль к PHP на С.
Та же самая Java, если ее знать, ничуть не медленнее для разработки сайтов, а вот в плане отладки и скорости выполнения обгоняет PHP на *порядки*.
Вы работаете с языком очень высокого уровня. Основные оптимизации — алгоритмы, архитектура, смена языка. Микро-оптимизации не принесут достаточного эффекта, чтобы о них даже задумываться.
Поймите: единственно верной статьей по оптимизации PHP может быть описание как пользоваться профайлером и описание где искать информацию по оптимизации базы и кеширования.
Использование разных хитрых конструкций для мнимого увеличения производительности ухудшает читабельность кода, не давая никаких плюсов на 99% сайтов.