Pull to refresh
38
Роман Могилатов@rmk

Разработчик

9
Subscribers
Send message
Всегда мечтал о таком
Хотел оставить аналогичный комментарий.

Есть небольшой нюанс на счет 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().
Встречный вопрос:

получается, что нет способа удалить переменную и все ссылки на нее, кроме как удалять ссылки в их собственных областях видимости?
Ох уж эти горячие клавиши…

include '../bootstrap.php';

$map = new Rmk\Collection\StringHashTable('stdClass');

$object = new stdClass();

$map->set('key', $object);

var_dump(spl_object_hash($object));
var_dump($object);
var_dump($map);

// Где-то в клиентском коде.
$object = $map->get('key');
var_dump(spl_object_hash($object));

unset($object);

var_dump($object);
var_dump($map);

$object = $map->get('key');
var_dump($object);
var_dump(spl_object_hash($object));


Написав и запустив этот пример, я понял, что ошибался на счет работы unset(). Получается, что некоторые вещи, которые я написал были чушью.

Виноват, спасибо.
Да, пожалуйста:
Я уверен, что никто не готов. И я в том числе.
Enterprise Architect

Все работы выполнялись вручную.

Что касается трансформаций «диаграмма — код» и «код — диаграмма», то они в моей версии остановились на уровне PHP4. Пишут, что все можно настроить, там редактируемые шаблоны, но не занимался этим.
Дело в том, что клиентский код имеет возможность принудительно удалить объект без какой либо обратной связи с коллекцией, в которой хранится «непостоянный» хеш. Первый созданный после удаления объект будет иметь хеш удаленного объекта. При этом поведение коллекции является непредсказуемым.

Считать ли это проблемой? Пожалуй, нет, если выполнять грамотное удаление объекта и всех ссылок на него, но мир PHP далек от этих проблем. По крайней мере, я редко сталкивался с тем, что что-то где-то нужно подчищать.
Мне понравился пост. Советы, лично для меня, не новы, но вдохновляет.

Автору:

Уделяйте больше внимания русскому языку. Этот пост тяжело читать. Надеюсь, что следующие будут лучше в этом плане.
А вопросы, мне кажется, возникнут. Им же теперь придется каждую вашу статью перечитывать, чтобы выяснить опубликовали ли вы их секреты.
Я имел ввиду, что шагомер неплохо было бы добавить к походному компасу, и что текущий прибор тяжело назвать походным, так как страшновато доверять ему свою жизнь.

Но я думаю, что если у ребят будет достаточно времени и энтузиазма их прибор выйдет из «теплой комнаты с умеренной влажностью и неограниченным источником питания».
Компас, как навигационная система, должен обладать:
1) Высокой точностью.
2) Высокой отказоустойчивостью.

Что касается точности, то не понял из статьи, как у вас обстоят дела?

С отказоустойчивостью, даже как не специалист, могу сказать, что дела, мягко говоря, средне:
1) Детали в корпусе слабо закреплены.
2) Дисплей можно разбить при падении устройства.
3) Отсутствие тестов на влажность, гидроизоляцию, высокие и низкие температуры.
4) Как устройство будет вести себя при сильном загрязнении?

Отдельный пункт — источник питания. Его ограниченные возможности в любом случае плохо влияют на отказоустойчивость.

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

Не смотря на все вышесказанное мною, я бы с удовольствием разработал что-то аналогичное в отпуске.

Есть еще несколько идей, которые, возможно, пригодятся:
1) Добавить в прибор шагомер. Мне кажется, что для сферы применения прибора, это будет уместно.
2) Отказаться от лишних функций: измерение температуры и влажности. Мне кажется, что это относится к приборам жизнеобеспечения, что не было целью разработки. Это даст возможность снизить энергопотребление и стоимость. Так же это даст еще одну возможность, описанную в п. 3.
3) Индикатор компаса сделать в виде круга из разноцветных светодиодов. Будет легче подсвечивать север-юг. Энергопотребление снизится. Хрупкость уменьшиться. Диапазон рабочих температур вырастет (дисплей моего старого телефона Samsung C100 отказывался работать при -23С).

Вам и автору ставлю плюс, ждем следующих разработок и модификаций существующих.
Я на досуге проанализирую все комментарии и составлю план будущего рефакторинга.
Но, к сожалению, не содержит карт.
Можно, но картина все равно не станет целостной.

Расширение SplObjectStorage позволит нам реализовать набор объектов, но никак не повлияет на реализацию карт и последовательных списков.
Извините за оффтоп, но подскажите, пожалуйста, в какие тэги брать текст комментариев?
На счет строк — нужно будет попробовать. Я тоже надеюсь…

Information

Rating
Does not participate
Location
Днепропетровская обл., Украина
Date of birth
Registered
Activity