Есть небольшой нюанс на счет IoC. Действительно часто его использование не оправдывается, так как реализации не подменяются в процессе жизни системы. Но профит заключается в том, что вы имеете возможность сделать это в любой момент. Никто не может дать гарантий, что завтра «стабильные» зависимости останутся стабильными. По крайней мере на основе личного опыта могу сказать, что можно предположить «условно стабильные» и «условно не стабильные» зависимости, но это все так условно…
Я не хотел Вас рассмешить, возможно, вы не совсем так меня поняли.
Java бесспорно велика. И количеством светлых умов в сообществе, и качеством библиотек и даже синтаксисом. При том не только Java, С#, я, например, тоже очень уважаю. Я понимаю, что у любого умного человека можно многому научиться, и не так важно на каком или на скольких языках он умеет программировать. Дело в том, что ООП != Java; Design Patterns != Java; компонентный подход != Java. Пожалуй, все лучшее, что есть в мире программирования есть и в Java. Давайте разберемся почему так? Я вижу 2 основных критерия: много светлых голов + время. Ту историю, о которой вы говорите создали именно эти 2 фактора. Возможно, я ошибаюсь, поправьте меня.
Теперь вернемся к вопросу «нужно ли хорошему (а именно таким я хотел бы быть) PHP программисту изучать Java?».
Я считаю, что если есть стремление переходить на Java, то да. Во-первых, любые теоретические познания должны быть хорошо подкреплены практикой для достижения максимального эффекта. Эту практику нужно откуда-то брать и решение университетских задачек или написание калькуляторов (читайте велосипедов) будет слишком малым вкладом. На большее, человек, не имеющий основной работы в данной сфере, не будет способен по чисто экономическим показателям. Кушать то хочется… В итоге изучение конкретного языка, если нет цели переходить на него полностью, я, лично считаю малоэффективным. Я конечно не против иметь интересное хобби, но не более того.
Я использую в работе Symfony. Версию 2 этого фреймворка видели? Лично у меня ощущение, что пишу на Java только с синтаксисом PHP и с худшим качеством проектирования. Даже не знаю, стоит ли спрашивать поможет ли вам в работе знание языка, где многое, что *сейчас* добавляется в мир PHP, было придумано и реализовано много лет назад.
Да, я смотрел Symfony 2 и даже подумывал начать на нем новый крупный проект, но все же решил дождаться ZF2, так как я ZF Way программист и ZF мне все таки ближе. Других адекватных причин выбора Symfony для себя я не нашел. Функциональная разница, на мой взгляд, между ними ничтожно мала.
Опять же, вернемся к нашему вопросу. Есть адекватные причины, по которым Вы работаете с PHP & Symfony. Я уверен, что их достаточно много. Что касается Вашего недовольства Symfony (по сравнению с Java), то сейчас нельзя писать Java Way код на PHP. Нужно все таки писать PHP Way код. Живой пример этому — мой проект, о котором написана эта статья.
Откровенно говоря, я не люблю такие фразы. Уж очень они похожи на:
не просто верить в волшебную фразу «facebook написан на PHP».
На текущий момент я сделал выбор вкладывать не в конкретные технологии, а в фундаментальные инженерные знания, которые != даже самым развитым технологиям.
Я сомневаюсь, что у меня будет возможность заняться серьезным языком. Я не жалуюсь на работу с текущими технологиями. И ее достаточно много. И, кстати, я считаю ее серьезной.
Порядок в мире PHP наведут, и будет это не за горами. Сейчас крупные производители фреймворков (Zend, Symfony) готовят удобные качественные решения, которые позволят подняться на более высокий уровень всем использующим их разработчикам. В некоторых областях определяться лидеры, которые займут свою нишу и вряд ли кому-то ее уступят. Отрасль «зреет».
Я не пытаюсь, и никогда не буду, конкурировать с качественными, устоявшимися решениями. И таких как я будет много, когда важные и нужные вопросы безоговорочно решат.
Данный проект был попыткой сделать что-то хорошее и высокоуровневое, то, чего я не встречал и с удовольствием бы использовал. Но он провалился по причинам, описанным выше.
А заниматься самообразованием конечно же нужно, только вот поможет ли мне глубокое понимание Java в моей работе с PHP? Мне кажется, что есть куда более полезные знания для меня… Например, та же документация по unset().
Что касается трансформаций «диаграмма — код» и «код — диаграмма», то они в моей версии остановились на уровне PHP4. Пишут, что все можно настроить, там редактируемые шаблоны, но не занимался этим.
Дело в том, что клиентский код имеет возможность принудительно удалить объект без какой либо обратной связи с коллекцией, в которой хранится «непостоянный» хеш. Первый созданный после удаления объект будет иметь хеш удаленного объекта. При этом поведение коллекции является непредсказуемым.
Считать ли это проблемой? Пожалуй, нет, если выполнять грамотное удаление объекта и всех ссылок на него, но мир PHP далек от этих проблем. По крайней мере, я редко сталкивался с тем, что что-то где-то нужно подчищать.
Я имел ввиду, что шагомер неплохо было бы добавить к походному компасу, и что текущий прибор тяжело назвать походным, так как страшновато доверять ему свою жизнь.
Но я думаю, что если у ребят будет достаточно времени и энтузиазма их прибор выйдет из «теплой комнаты с умеренной влажностью и неограниченным источником питания».
Компас, как навигационная система, должен обладать:
1) Высокой точностью.
2) Высокой отказоустойчивостью.
Что касается точности, то не понял из статьи, как у вас обстоят дела?
С отказоустойчивостью, даже как не специалист, могу сказать, что дела, мягко говоря, средне:
1) Детали в корпусе слабо закреплены.
2) Дисплей можно разбить при падении устройства.
3) Отсутствие тестов на влажность, гидроизоляцию, высокие и низкие температуры.
4) Как устройство будет вести себя при сильном загрязнении?
Отдельный пункт — источник питания. Его ограниченные возможности в любом случае плохо влияют на отказоустойчивость.
Мое мнение, как непрофессионала, что устройство может отлично служить как часть чего-то большего, которое предназначено для стационарной эксплуатации в теплой комнате с умеренной влажностью, и имеет неограниченный источник питания.
Не смотря на все вышесказанное мною, я бы с удовольствием разработал что-то аналогичное в отпуске.
Есть еще несколько идей, которые, возможно, пригодятся:
1) Добавить в прибор шагомер. Мне кажется, что для сферы применения прибора, это будет уместно.
2) Отказаться от лишних функций: измерение температуры и влажности. Мне кажется, что это относится к приборам жизнеобеспечения, что не было целью разработки. Это даст возможность снизить энергопотребление и стоимость. Так же это даст еще одну возможность, описанную в п. 3.
3) Индикатор компаса сделать в виде круга из разноцветных светодиодов. Будет легче подсвечивать север-юг. Энергопотребление снизится. Хрупкость уменьшиться. Диапазон рабочих температур вырастет (дисплей моего старого телефона Samsung C100 отказывался работать при -23С).
Вам и автору ставлю плюс, ждем следующих разработок и модификаций существующих.
Есть небольшой нюанс на счет IoC. Действительно часто его использование не оправдывается, так как реализации не подменяются в процессе жизни системы. Но профит заключается в том, что вы имеете возможность сделать это в любой момент. Никто не может дать гарантий, что завтра «стабильные» зависимости останутся стабильными. По крайней мере на основе личного опыта могу сказать, что можно предположить «условно стабильные» и «условно не стабильные» зависимости, но это все так условно…
Java бесспорно велика. И количеством светлых умов в сообществе, и качеством библиотек и даже синтаксисом. При том не только Java, С#, я, например, тоже очень уважаю. Я понимаю, что у любого умного человека можно многому научиться, и не так важно на каком или на скольких языках он умеет программировать. Дело в том, что ООП != Java; Design Patterns != Java; компонентный подход != Java. Пожалуй, все лучшее, что есть в мире программирования есть и в Java. Давайте разберемся почему так? Я вижу 2 основных критерия: много светлых голов + время. Ту историю, о которой вы говорите создали именно эти 2 фактора. Возможно, я ошибаюсь, поправьте меня.
Теперь вернемся к вопросу «нужно ли хорошему (а именно таким я хотел бы быть) PHP программисту изучать Java?».
Я считаю, что если есть стремление переходить на Java, то да. Во-первых, любые теоретические познания должны быть хорошо подкреплены практикой для достижения максимального эффекта. Эту практику нужно откуда-то брать и решение университетских задачек или написание калькуляторов (читайте велосипедов) будет слишком малым вкладом. На большее, человек, не имеющий основной работы в данной сфере, не будет способен по чисто экономическим показателям. Кушать то хочется… В итоге изучение конкретного языка, если нет цели переходить на него полностью, я, лично считаю малоэффективным. Я конечно не против иметь интересное хобби, но не более того.
Да, я смотрел Symfony 2 и даже подумывал начать на нем новый крупный проект, но все же решил дождаться ZF2, так как я ZF Way программист и ZF мне все таки ближе. Других адекватных причин выбора Symfony для себя я не нашел. Функциональная разница, на мой взгляд, между ними ничтожно мала.
Опять же, вернемся к нашему вопросу. Есть адекватные причины, по которым Вы работаете с PHP & Symfony. Я уверен, что их достаточно много. Что касается Вашего недовольства Symfony (по сравнению с Java), то сейчас нельзя писать Java Way код на PHP. Нужно все таки писать PHP Way код. Живой пример этому — мой проект, о котором написана эта статья.
Откровенно говоря, я не люблю такие фразы. Уж очень они похожи на:
На текущий момент я сделал выбор вкладывать не в конкретные технологии, а в фундаментальные инженерные знания, которые != даже самым развитым технологиям.
Я сомневаюсь, что у меня будет возможность заняться серьезным языком. Я не жалуюсь на работу с текущими технологиями. И ее достаточно много. И, кстати, я считаю ее серьезной.
Порядок в мире PHP наведут, и будет это не за горами. Сейчас крупные производители фреймворков (Zend, Symfony) готовят удобные качественные решения, которые позволят подняться на более высокий уровень всем использующим их разработчикам. В некоторых областях определяться лидеры, которые займут свою нишу и вряд ли кому-то ее уступят. Отрасль «зреет».
Я не пытаюсь, и никогда не буду, конкурировать с качественными, устоявшимися решениями. И таких как я будет много, когда важные и нужные вопросы безоговорочно решат.
Данный проект был попыткой сделать что-то хорошее и высокоуровневое, то, чего я не встречал и с удовольствием бы использовал. Но он провалился по причинам, описанным выше.
А заниматься самообразованием конечно же нужно, только вот поможет ли мне глубокое понимание Java в моей работе с PHP? Мне кажется, что есть куда более полезные знания для меня… Например, та же документация по unset().
получается, что нет способа удалить переменную и все ссылки на нее, кроме как удалять ссылки в их собственных областях видимости?
Написав и запустив этот пример, я понял, что ошибался на счет работы unset(). Получается, что некоторые вещи, которые я написал были чушью.
Виноват, спасибо.
Все работы выполнялись вручную.
Что касается трансформаций «диаграмма — код» и «код — диаграмма», то они в моей версии остановились на уровне PHP4. Пишут, что все можно настроить, там редактируемые шаблоны, но не занимался этим.
Считать ли это проблемой? Пожалуй, нет, если выполнять грамотное удаление объекта и всех ссылок на него, но мир PHP далек от этих проблем. По крайней мере, я редко сталкивался с тем, что что-то где-то нужно подчищать.
Автору:
Уделяйте больше внимания русскому языку. Этот пост тяжело читать. Надеюсь, что следующие будут лучше в этом плане.
Но я думаю, что если у ребят будет достаточно времени и энтузиазма их прибор выйдет из «теплой комнаты с умеренной влажностью и неограниченным источником питания».
1) Высокой точностью.
2) Высокой отказоустойчивостью.
Что касается точности, то не понял из статьи, как у вас обстоят дела?
С отказоустойчивостью, даже как не специалист, могу сказать, что дела, мягко говоря, средне:
1) Детали в корпусе слабо закреплены.
2) Дисплей можно разбить при падении устройства.
3) Отсутствие тестов на влажность, гидроизоляцию, высокие и низкие температуры.
4) Как устройство будет вести себя при сильном загрязнении?
Отдельный пункт — источник питания. Его ограниченные возможности в любом случае плохо влияют на отказоустойчивость.
Мое мнение, как непрофессионала, что устройство может отлично служить как часть чего-то большего, которое предназначено для стационарной эксплуатации в теплой комнате с умеренной влажностью, и имеет неограниченный источник питания.
Не смотря на все вышесказанное мною, я бы с удовольствием разработал что-то аналогичное в отпуске.
Есть еще несколько идей, которые, возможно, пригодятся:
1) Добавить в прибор шагомер. Мне кажется, что для сферы применения прибора, это будет уместно.
2) Отказаться от лишних функций: измерение температуры и влажности. Мне кажется, что это относится к приборам жизнеобеспечения, что не было целью разработки. Это даст возможность снизить энергопотребление и стоимость. Так же это даст еще одну возможность, описанную в п. 3.
3) Индикатор компаса сделать в виде круга из разноцветных светодиодов. Будет легче подсвечивать север-юг. Энергопотребление снизится. Хрупкость уменьшиться. Диапазон рабочих температур вырастет (дисплей моего старого телефона Samsung C100 отказывался работать при -23С).
Вам и автору ставлю плюс, ждем следующих разработок и модификаций существующих.
Расширение SplObjectStorage позволит нам реализовать набор объектов, но никак не повлияет на реализацию карт и последовательных списков.