Ну, мопед не мой, а по футеру так и текст переводной.
Про аннотации — мне самому они очень нравятся, особенно в роли описания кеша/темплейтов/и т.п., но порой действительно вынос роутингов в дерево yaml дает большую гибкость, особенно в больших проектах. По крайней мере, ищется нужный даже в большой команде легко, роуты видно в одном месте (и на одном экране, что важно),
и самое главное — для Symfony — проще делать иерархию роутинга (чтобы все роутинги /api/ были описаны в другом файле, при этом префикс задается в одном месте).
Хотя, когда писали самодокументируемый REST-сервис с помощью NelmioApiDocBundle, многое было на аннотациях и было очень вкусно и красиво, даже описание парамтетров, передаваемых в query, и принимаемых в POST сущностей.
На самом деле, основные плюсы кроются не в том, что контроллер можно реюзать, а скорее, наоборот, тонкий клиент и связывание дает кунштюки:
— Можно заменить сервис, реализующий ту или иную плюшку (например, подменив EntityManager доктрины часть самых тяжелых методов перепишется на максимально быстрый нейтив)
— С инъекциями проще потом поверх нужных методов подцепить что-то еще. Например, логгер.
— Замена некоторых зависимостей полностью — не такой уж частый, но важный кейс в разработке хоть сколько-то дольше месяца,
— Наконец, позволяет тестировать сервисы модульно, в своих контекстах, так что контроллер, который тянет за собой все окружение, тестировать или не надо, или просто, или достаточно пары функциональных стандартных тестов.
Магазин заключает публичный договор о безвозмездном предоставлении услуг по хранению своих вещей со своими посетителями и если посетители сдают свои вещи добровольно на хранение, то на основании глава 47 ГК РФ в обязанность хранителя будет обеспечение возврата вещи с полной ее сохранностью во время ее хранения.
Как перфекционист (в душе), ставлю вам плюс. Но, к сожалению, надо быть реалистами и раскладывать все по полочкам:
1. Студент может быть любого курса. Я написал свою первую программу лет в 8. Помоглал брату делать мун лендер (баловался параметрами) — чуть позже, когда поменяли спектрум то ли на тройку, то ли на четверку. И потом игры писал. И мне, и моим друзьям было плевать, как она написана.
2. Лунная посадка это, или змейка-тетрис, или даже башни — чем раньше человек начнет писать красивый код, тем лучше. А увлеченный паренек в любом случае напишет или игру, или очередной таск-менеджер, это неизбежно.
3. Откуда он может взять. Вы говорите — язык оригинала и чужой код. Да, действительно, это порой лучше, т.к заставляет думать и мучитьься в процессе. Но на родном языке неофиту проще понять, что до него пытаются донести. Признаюсь честно, я не все места из русской-то версии банды четырех понимал, а английский текст приводил меня в замешательство попыткой ввести саенс в простые вещи.
4. Доступность — не только в виде понимания, но и привлечения внимания неофитов к материалу, который им будет полезен. Считайте проявлением честолюбия с моей стороны.
5. Игры — не только ААА-индустрия и клоны, и заезженные механики. По моему опыту, инди часто пишут молодые разработчики, имеющие идеи. Да и маленькие игры тоже чаще требуют необычных механик и отхода от канона, что хорошо. Хорошие игры могут быть написаны плохо, что мешает авторам фиксить баги и добавлять фичи.
6. Накноец, хороший код и профессионализм — не самоцель вообще. Хороший код нужег:
а) скорость разработки. Замедляя сначала, он дает выигрыш в разработке и тестировании. Его просто изменять, если совсем уж казуально.
б) он нужен для унифицированности в командной разработке. Действительно классный проект пишется несколькими людьми или просто очень долго (пример — underrails, braid..)
в) его можно использовать повторно — хотя мы все сами насчет этого пункта давно понимаем
г) чтобы было не стыдно показывать код и проще устроиться на работу
И так далеее, и так далее. И да, я считаю, что не знающий английский программист может быть крепким джуниором или девом, помогать новичкам надо и мы не утонем в лавине тауердефенсов и казуалок хотя бы потому, что поиск совершенствуется, а благодаря им в том числе мы получили FTL, minecraft и вообще — пис, мэн.
Чтобы стать хорошим программистом, возможно, надо пройти через говнокод, лапшу и начальника «запили-ка мне быстро». Но мне, кажется, многие вещи стоит учить гораздо раньше. И если в нашей стране большинство студентов даже на четвертом курсе не успевает освоить английский язык в том качестве, чтобы читать свободно такие книги на английском, то ничего поделать нельзя. Я реалист.
Ну и, кроме того, я считаю (хотя и не славянофил), что терминология должна входить в язык также, как и остальные слова — т.е. не всегда прямым и грубым заимствованием. Это тоже важно.
С меня — обещание перевести на достойный русский язык (так, чтобы текст не вызывал ощущения «что я сейчас только что прочитал»). Кроме того, хотелось бы объяснить, почему я так ухватился за эту книгу:
1. По моим ощущениям в инди-индустрии все очень плохо с паттернами. Да даже с вменяемым кодингом плохо — хорошо хоть наши дизайнеры не берутся писать игры (а может, плохо — тот же багованный Fez написан дизайнером, да и крутейший Braid)
2. В отличие от самоучителей и тому подобного, практики программирования приятней читать с литературными отступлениями и на великом могучем.
3. В университетах студенты часто задают вопрос преподам — «Скажите, а ряды Фурье — они для чего?», а те молчат, хотя с помощью них даже музыка в mp3 кодируется. Так и здесь — мне импонирует, что автор сразу дает практику использования паттернов, да еще и в «индустрии» игр, что, конечно, уже плюс в глазах любого студента. У нас, например, был целый семестр, в который мы писали игру — и я очень хотел бы, чтобы хотя бы студенты будущего могли прикоснуться к проектированию архитектуры кода сразу, попытавшись пропустить тот этап, когда пишется лапша даже без отступов.
Ну и персональный довод для вас — если вы, как и я, читаете техническую литературу свободно, вы можете потратить совсем немного своего времени для того, чтобы те, кто этого лишен (по тем или иным причинам) тоже смогли прочитать это. Разве это вообще не достаточный повод?
1. Составить словарь для редактуры
2. Изображения перевести отдельно, исходя из перевода текста
3. После перевода перейти на github — сохранить структуру (выноски, абзацы, рисунки) и, возможно, предложить сообществу написать код примеров на разных языках (аналогично вики)
Т.к. Боб не указал лицензию, написал-спросил у него разрешения.
А он и не делался под ДОС. Вот совместимая с совеременными реализация www.gog.com/game/the_temple_of_elemental_evil (правда, можно ли ставить фанатские патчи, которые много что исправляли, не знаю)
Вообще, стандартный эксплорер использовал примитивный вариант этой техники уже давно. Тоже довольно примитивное изложение применено в свежем конкуренте Джиры — Targetprocess (помимо этого, они используют доски с настраиваемыми осями, что тоже довольно круто).
Но, конечно, хочется большего, особенно, в эпоху респонсив дизайна, который как раз о зум-ориентированных интерфейсах.
Про аннотации — мне самому они очень нравятся, особенно в роли описания кеша/темплейтов/и т.п., но порой действительно вынос роутингов в дерево yaml дает большую гибкость, особенно в больших проектах. По крайней мере, ищется нужный даже в большой команде легко, роуты видно в одном месте (и на одном экране, что важно),
и самое главное — для Symfony — проще делать иерархию роутинга (чтобы все роутинги /api/ были описаны в другом файле, при этом префикс задается в одном месте).
Хотя, когда писали самодокументируемый REST-сервис с помощью NelmioApiDocBundle, многое было на аннотациях и было очень вкусно и красиво, даже описание парамтетров, передаваемых в query, и принимаемых в POST сущностей.
— Можно заменить сервис, реализующий ту или иную плюшку (например, подменив EntityManager доктрины часть самых тяжелых методов перепишется на максимально быстрый нейтив)
— С инъекциями проще потом поверх нужных методов подцепить что-то еще. Например, логгер.
— Замена некоторых зависимостей полностью — не такой уж частый, но важный кейс в разработке хоть сколько-то дольше месяца,
— Наконец, позволяет тестировать сервисы модульно, в своих контекстах, так что контроллер, который тянет за собой все окружение, тестировать или не надо, или просто, или достаточно пары функциональных стандартных тестов.
1. Студент может быть любого курса. Я написал свою первую программу лет в 8. Помоглал брату делать мун лендер (баловался параметрами) — чуть позже, когда поменяли спектрум то ли на тройку, то ли на четверку. И потом игры писал. И мне, и моим друзьям было плевать, как она написана.
2. Лунная посадка это, или змейка-тетрис, или даже башни — чем раньше человек начнет писать красивый код, тем лучше. А увлеченный паренек в любом случае напишет или игру, или очередной таск-менеджер, это неизбежно.
3. Откуда он может взять. Вы говорите — язык оригинала и чужой код. Да, действительно, это порой лучше, т.к заставляет думать и мучитьься в процессе. Но на родном языке неофиту проще понять, что до него пытаются донести. Признаюсь честно, я не все места из русской-то версии банды четырех понимал, а английский текст приводил меня в замешательство попыткой ввести саенс в простые вещи.
4. Доступность — не только в виде понимания, но и привлечения внимания неофитов к материалу, который им будет полезен. Считайте проявлением честолюбия с моей стороны.
5. Игры — не только ААА-индустрия и клоны, и заезженные механики. По моему опыту, инди часто пишут молодые разработчики, имеющие идеи. Да и маленькие игры тоже чаще требуют необычных механик и отхода от канона, что хорошо. Хорошие игры могут быть написаны плохо, что мешает авторам фиксить баги и добавлять фичи.
6. Накноец, хороший код и профессионализм — не самоцель вообще. Хороший код нужег:
а) скорость разработки. Замедляя сначала, он дает выигрыш в разработке и тестировании. Его просто изменять, если совсем уж казуально.
б) он нужен для унифицированности в командной разработке. Действительно классный проект пишется несколькими людьми или просто очень долго (пример — underrails, braid..)
в) его можно использовать повторно — хотя мы все сами насчет этого пункта давно понимаем
г) чтобы было не стыдно показывать код и проще устроиться на работу
И так далеее, и так далее. И да, я считаю, что не знающий английский программист может быть крепким джуниором или девом, помогать новичкам надо и мы не утонем в лавине тауердефенсов и казуалок хотя бы потому, что поиск совершенствуется, а благодаря им в том числе мы получили FTL, minecraft и вообще — пис, мэн.
Ну и, кроме того, я считаю (хотя и не славянофил), что терминология должна входить в язык также, как и остальные слова — т.е. не всегда прямым и грубым заимствованием. Это тоже важно.
С меня — обещание перевести на достойный русский язык (так, чтобы текст не вызывал ощущения «что я сейчас только что прочитал»). Кроме того, хотелось бы объяснить, почему я так ухватился за эту книгу:
1. По моим ощущениям в инди-индустрии все очень плохо с паттернами. Да даже с вменяемым кодингом плохо — хорошо хоть наши дизайнеры не берутся писать игры (а может, плохо — тот же багованный Fez написан дизайнером, да и крутейший Braid)
2. В отличие от самоучителей и тому подобного, практики программирования приятней читать с литературными отступлениями и на великом могучем.
3. В университетах студенты часто задают вопрос преподам — «Скажите, а ряды Фурье — они для чего?», а те молчат, хотя с помощью них даже музыка в mp3 кодируется. Так и здесь — мне импонирует, что автор сразу дает практику использования паттернов, да еще и в «индустрии» игр, что, конечно, уже плюс в глазах любого студента. У нас, например, был целый семестр, в который мы писали игру — и я очень хотел бы, чтобы хотя бы студенты будущего могли прикоснуться к проектированию архитектуры кода сразу, попытавшись пропустить тот этап, когда пишется лапша даже без отступов.
Ну и персональный довод для вас — если вы, как и я, читаете техническую литературу свободно, вы можете потратить совсем немного своего времени для того, чтобы те, кто этого лишен (по тем или иным причинам) тоже смогли прочитать это. Разве это вообще не достаточный повод?
В планах:
1. Составить словарь для редактуры
2. Изображения перевести отдельно, исходя из перевода текста
3. После перевода перейти на github — сохранить структуру (выноски, абзацы, рисунки) и, возможно, предложить сообществу написать код примеров на разных языках (аналогично вики)
Т.к. Боб не указал лицензию, написал-спросил у него разрешения.
Но, конечно, хочется большего, особенно, в эпоху респонсив дизайна, который как раз о зум-ориентированных интерфейсах.