Насчете forever, думаю, это больше вопрос вкуса. Все же ничего особо страшного этот макрос не делает (более того, делает ровно то, то написано).
Про «безопасный вызов» — меня уже ткнули носом в реальную проблему. Касательно спорности, я нахожусь под впечатлением идеи Null propagating operator для C#.
Спасибо за подробный разбор. Я уже все осознал и исправился.
К сожалению (конечно же, для меня, а не для проектов), при его использовании подобных проблем у меня не возникало.
Да, Вы правы. Но и без макроса Вы не избавитесь от необходимости сохранить указатель. Другое дело, что макрос скроет потенциально проблемное место от использующего его программиста.
foo(i++) — вполне легальная конструкция, если foo — это метод или функция.
Зато нелегально foo(i++, i++), так как здесь i изменяется дважды до точки следования (я, правда, не уверен, не изменились ли как-то точки следования согласно C++11).
А макрос плох тем, что «скрывает» это, маскируясь под функцию с параметром.
Ничего не имею против статьи, но, все же, вынужден заметить, что список
iOS, Android, BlackBerry, Windows XP/7, Mac OS X, Linux, ReactOS, Windows 8, Windows Phone 8.1
почти полностью перекрывается Unity. А делать игру на Unity намного быстрее и удобнее, чем писать свой движок. И для 2d игр там в бесплатной версии есть практически все, что необходимо, даже GUI они наконец сделали приличный. И скриптовый язык основной там тоже C# (в то время как сам движок написан на C++).
Я оппонирую статье, там под заказчиком понимается именно заказчик. И если заказчику мы не можем каждую неделю демонстрировать посадку спутника на комету, то все, скрам не применим.
И, на мой взгляд, скорее, не геймдиз, а продюсер является product owner'ом в реальности. Геймдиз — человек подневольный. Другое дело, что часто продюсер — это лицо из руководства компании, и скрам ему до лампочки.
Я не настолько разбирался с канбаном, чтобы рассказать про отличия самостоятельно, но на английском есть описание в этом документе (страница 14).
Однако, есть на русском.
Не могу полностью согласиться со статьей, и даже отчасти с комментариями.
Представьте себе геймдев на самообеспечении. То есть, заказчик отсутствует как класс. Российская компания, то есть руководство все эти новомодные скрамы интересуют мало. Отдел состоит из 1 гейм-дизайнера (он же начальник отдела), 2 программистов и нескольких художников. Про scrum в отделе не знает никто (возможно, кроме начальника, который его и ввел, и то я не уверен), но он успешно применяется этим отделом.
Это история из жизни, если что. Происходила на моей первой работе в качестве программиста.
Как это работало. В роли заказчика и скрам-мастера выступал начальник отдела в одном лице. Как заказчик, он сам создавал задачи. Их он получал от вышестоящих начальников, придумывал сам (геймдиз как-никак) и даже опрашивал нас, программистов, на предмет внутренних задач. Кроме того, он оценивал и приоритет задач. В качестве же скрам-мастера он проводил митинги и заставлял сразу обоих программистов оценивать задачи по времени. В начале недели был митинг, на котором мы разбирали задачи на неделю. В конце недели мы отчитывались перед гейм-дизом и самими собой о проделанной работе. За этот период у нас была только пара факапов связанных с оценкой времени.
То есть, scrum можно рассматривать как ролевую игру. Совсем не обязательно иметь реального заказчика, отдельного скрам-мастера и даже ставить в известность руководство. Достаточно, чтобы хотя бы один человек знал, что, как и зачем нужно делать, а остальные ему хотя бы не мешали и просто выполняли свою работу.
Можно, конечно, сказать, что мой пример иллюстрирует фразу
При этом совершенно необязательно отказываться от каких-то элементов процесса, которые ассоциируются с Agile, но работают везде.
Особенно, если я добавлю, что у нас не было доски для скрама — мы использовали basecamp, и не было ежедневных сборищ, так как команде из трех человек, сидящих рядом, они мало нужны.
Однако, я хочу акцентировать внимание на том, что управление проектами — процесс творческий, и не нужно слепо следовать инструкциям. Нужно переосмысливать agile под конкретные команды и проекты.
Поэтому к означенным посадке зонда на комету и прошивке телефона agile вполне применим. Просто в роли заказчика будет выступать не реальный заказчик, а, например, начальник отдела или тим-лид.
А вот про поддержку полностью согласен, это не место для скрама, там относительно сложно что-либо планировать.
И еще один тип проектов, где scrum'у точно не место, это хобби-проекты, и, в частности, опенсурс, создаваемый силами сообществ. Там тоже сложно что-либо планировать, так как человек может быть занят чем-то другим или просто ничего не делать, если не хочет.
Тема не раскрыта. Весьма поверхностно. Как выбирать — непонятно.
Вы имеете полное право поставить статье минус. А за конструктивную часть критики — спасибо.
LGPL — это надстройка над GPL, и требует ее наличия в проекте.
Чего-чего требует?
Поправил, спасибо.
В лицензии это не оговорено. Различия между динамической и статической линковкой — это фантазии FSF, которые не были обоснованы в суде. Есть альтернативные мнения, в том числе мнение Линуса.
Поправил.
Лицензией MPL заражаются файлы, а не проекты, в отличие от (L)GPL. Если изменить файл, он должен остаться под MPL. Если добавить — ограничений нет.
Добавил в описание.
Также стоит добавить в проекта файл LICENSE с текстом лицензии.
И мной это явно указано для всех лицензий, кроме тех, где я даю внешний линк на инстуркцию по их применению.
И вполне подходит для небольших проектов.
Очень смешно звучит подобное ограничение в свете большого количества крупных проектов под MIT.
Поправил.
Забыли про деление на 2-clause и 3-clause (есть не только старая 4-clause).
Добавил в статью упоминание 2-clause BSD.
Ещё Unlicense есть. Для прагматичных минималистов. CC0 тоже не все любят.
Добавил Unlicense, спасибо. Но, она таки проблемна.
По остальной части Вашего комментария. Я так понял, что Вы не любите копилефтные лицензии, и любите разрешительные. Это Ваше право. В статье я не ставил перед собой задачи пропагандировать те или иные лицензии. Каждый может выбрать сам, что ему больше подходит. Для этого я привел список наиболее известных лицензий (и добавил к ним озвученные в комментариях) и постарался кратко описать, какие требования они накладывают, как их применять и какие проблемы с ними существуют.
А меня интересует несколько иное. Предположим, у меня есть проект, который содержит код, и, скажем, изображения. Я создаю в проекте файл LICENSE и копирую туда текст лицензии (интересует, в общем-то, для всего списка лицензий из статьи), нигде не уточняя, к чему именно в проекте применяется лицензия. Будет ли в таком случае лицензия распространяться и на изображения? И как в этом случае понимать фразу про «исходные коды», если она упомянута в лицензии? Должен ли я буду с исходным кодом распространять исходники изображений (проекты Gimp или Photoshop)?
Про «безопасный вызов» — меня уже ткнули носом в реальную проблему. Касательно спорности, я нахожусь под впечатлением идеи Null propagating operator для C#.
К сожалению (конечно же, для меня, а не для проектов), при его использовании подобных проблем у меня не возникало.
Зато нелегально foo(i++, i++), так как здесь i изменяется дважды до точки следования (я, правда, не уверен, не изменились ли как-то точки следования согласно C++11).
А макрос плох тем, что «скрывает» это, маскируясь под функцию с параметром.
почти полностью перекрывается Unity. А делать игру на Unity намного быстрее и удобнее, чем писать свой движок. И для 2d игр там в бесплатной версии есть практически все, что необходимо, даже GUI они наконец сделали приличный. И скриптовый язык основной там тоже C# (в то время как сам движок написан на C++).
И, на мой взгляд, скорее, не геймдиз, а продюсер является product owner'ом в реальности. Геймдиз — человек подневольный. Другое дело, что часто продюсер — это лицо из руководства компании, и скрам ему до лампочки.
но на английском есть описание в этом документе (страница 14).Однако, есть на русском.
Представьте себе геймдев на самообеспечении. То есть, заказчик отсутствует как класс. Российская компания, то есть руководство все эти новомодные скрамы интересуют мало. Отдел состоит из 1 гейм-дизайнера (он же начальник отдела), 2 программистов и нескольких художников. Про scrum в отделе не знает никто (возможно, кроме начальника, который его и ввел, и то я не уверен), но он успешно применяется этим отделом.
Это история из жизни, если что. Происходила на моей первой работе в качестве программиста.
Как это работало. В роли заказчика и скрам-мастера выступал начальник отдела в одном лице. Как заказчик, он сам создавал задачи. Их он получал от вышестоящих начальников, придумывал сам (геймдиз как-никак) и даже опрашивал нас, программистов, на предмет внутренних задач. Кроме того, он оценивал и приоритет задач. В качестве же скрам-мастера он проводил митинги и заставлял сразу обоих программистов оценивать задачи по времени. В начале недели был митинг, на котором мы разбирали задачи на неделю. В конце недели мы отчитывались перед гейм-дизом и самими собой о проделанной работе. За этот период у нас была только пара факапов связанных с оценкой времени.
То есть, scrum можно рассматривать как ролевую игру. Совсем не обязательно иметь реального заказчика, отдельного скрам-мастера и даже ставить в известность руководство. Достаточно, чтобы хотя бы один человек знал, что, как и зачем нужно делать, а остальные ему хотя бы не мешали и просто выполняли свою работу.
Можно, конечно, сказать, что мой пример иллюстрирует фразу
Особенно, если я добавлю, что у нас не было доски для скрама — мы использовали basecamp, и не было ежедневных сборищ, так как команде из трех человек, сидящих рядом, они мало нужны.
Однако, я хочу акцентировать внимание на том, что управление проектами — процесс творческий, и не нужно слепо следовать инструкциям. Нужно переосмысливать agile под конкретные команды и проекты.
Поэтому к означенным посадке зонда на комету и прошивке телефона agile вполне применим. Просто в роли заказчика будет выступать не реальный заказчик, а, например, начальник отдела или тим-лид.
А вот про поддержку полностью согласен, это не место для скрама, там относительно сложно что-либо планировать.
И еще один тип проектов, где scrum'у точно не место, это хобби-проекты, и, в частности, опенсурс, создаваемый силами сообществ. Там тоже сложно что-либо планировать, так как человек может быть занят чем-то другим или просто ничего не делать, если не хочет.
Вы имеете полное право поставить статье минус. А за конструктивную часть критики — спасибо.
Поправил, спасибо.
Поправил.
Добавил в описание.
И мной это явно указано для всех лицензий, кроме тех, где я даю внешний линк на инстуркцию по их применению.
Поправил.
Добавил в статью упоминание 2-clause BSD.
Добавил Unlicense, спасибо. Но, она таки проблемна.
По остальной части Вашего комментария. Я так понял, что Вы не любите копилефтные лицензии, и любите разрешительные. Это Ваше право. В статье я не ставил перед собой задачи пропагандировать те или иные лицензии. Каждый может выбрать сам, что ему больше подходит. Для этого я привел список наиболее известных лицензий (и добавил к ним озвученные в комментариях) и постарался кратко описать, какие требования они накладывают, как их применять и какие проблемы с ними существуют.
И, Ваш комментарий я не минусовал.