* Мелкий баг в MinBy (в похожих методах тоже может быть, не проверял). Для значений с null-ключом побеждает последний элемент, для всех остальных значений — первый.
UPD:
* Только сейчас заметил. У нас есть копии типов из фреймворка для совместимости с .net 4.0 и младше. В сборках под старшие версии для них надо type forwarding указать. Надо будет поправить.
DONE:
* Методы Code.BugIf() / DebugCode.BugIf(). Смысл такой: регулярно в процессе разработки закладываешься на какой-то факт, если надежды обломались — всё, приплыли.
В общем, тот же Code.AssertState, но вина не пользователя API, а самого разработчика. Почему не использовать сам AssertState? Чтоб проще было отличать.
* EnumCode.Xxx() — ассерты для энумов. Полный аналог Code, содержит методы-ассерты для всех методов из EnumHelper, исключения в классе EnumCodeExceptions. Нудятина страшная, наверно сам сделаю.
* Поправить ConcurrentLazyDictionary. Подробнее — см реквест
Здравствуйте, Jack128, Вы писали:
J>Сильно похоже на Seq.Unfold
Ага, оно. Только название надо подобрать так, чтобы оно у большинства разработчиков под шарп вопросов не вызывало.
Здравствуйте, Sinix, Вы писали:
S>1. Методы Code.BugIf() / DebugCode.BugIf(). Смысл такой: регулярно в процессе разработки закладываешься на какой-то факт, если надежды обломались — всё, приплыли.
Тогда лучше Code.BugIfNot, чтобы поведение было аналогично AssertState.
S>В общем, тот же Code.AssertState, но вина не пользователя API, а самого разработчика. Почему не использовать сам AssertState? Чтоб проще было отличать.
Удивил. Я срабатывание AssertState как раз рассматриваю как вину разработчика, ибо Assert в других языках используется именно для диагностики внутренних ошибок логики, а не неверного использования API.
У меня тоже пара хотелок образовалась:
1) Code.ValidCount — по сути тоже самое, что ValidIndex, но явно видно, что проверяется длина.
2) Возможность в лоб создать TempFile без создания самого файла. Сейчас мне для этого приходится самому реимплементить функцию создания пути временного файла, чтобы скормить путь в констуктор TempFile.
Здравствуйте, Lexey, Вы писали:
S>>1. Методы Code.BugIf() / DebugCode.BugIf(). Смысл такой: регулярно в процессе разработки закладываешься на какой-то факт, если надежды обломались — L>Тогда лучше Code.BugIfNot, чтобы поведение было аналогично AssertState.
Не, там двойное отрицание тогда получится в 99% случаев. Сам попробуй вспомнить типовые примеры, у меня оно выглядит обычно как-то так:
Если у тебя наоборот — накидывай свои примеры, может, оба варианта сделаем
L>Удивил. Я срабатывание AssertState как раз рассматриваю как вину разработчика, ибо Assert в других языках используется именно для диагностики внутренних ошибок логики, а не неверного использования API.
Ну вот у меня AssertState, насколько помню, везде используется для сообщения о том, что объект используется извращённым способом. Ну, например, попытка закоммитить откаченнную транзакцию или получить результат ещё не запущенного теста. А BugIf, наоборот, для ситуаций, которые в теории возникнуть не могут вообще, а на практике лучше сразу упасть, чем продолжать работу. Т,е. для стопроцентных багов.
L>У меня тоже пара хотелок образовалась: L>1) Code.ValidCount — по сути тоже самое, что ValidIndex, но явно видно, что проверяется длина.
Принято вместе с названием
L>2) Возможность в лоб создать TempFile без создания самого файла. Сейчас мне для этого приходится самому реимплементить функцию создания пути временного файла, чтобы скормить путь в констуктор TempFile.
А оно было вроде. Или это для Dictionary такое делалось. Не вспомню. В общем — да, конечно.
L>Могу сам добавить, если не будет возражений.
Ага, давай
Здравствуйте, Sinix, Вы писали:
S>>>1. Методы Code.BugIf() / DebugCode.BugIf(). Смысл такой: регулярно в процессе разработки закладываешься на какой-то факт, если надежды обломались — L>>Тогда лучше Code.BugIfNot, чтобы поведение было аналогично AssertState. S>Если у тебя наоборот — накидывай свои примеры, может, оба варианта сделаем
ОК, убедил. Моя идея была только в том, чтобы можно было спокойно заменить AssertState на BugIf, не переворачивая условия. Но, это не принципиально.
L>>Могу сам добавить, если не будет возражений. S>Ага, давай
ОК.
P.S. Посмотри, кстати, методы, которые я там для SuffixTree добавил, pls.
Заодно подправил там слегка CreateTempFile и CreateTempDirectory, чтобы файл/директория удалялись финализатором, если что-то пойдет не так в процессе выполнения самого метода.
Здравствуйте, Lexey, Вы писали:
L>Заодно подправил там слегка CreateTempFile и CreateTempDirectory, чтобы файл/директория удалялись финализатором, если что-то пойдет не так в процессе выполнения самого метода.
Ага, отписался там уже. Всё по мелочи, если самому лень / неудобно — не вопрос, поправлю после мержа.
Здравствуйте, Sinix, Вы писали:
L>>Заодно подправил там слегка CreateTempFile и CreateTempDirectory, чтобы файл/директория удалялись финализатором, если что-то пойдет не так в процессе выполнения самого метода. S>Ага, отписался там уже. Всё по мелочи, если самому лень / неудобно — не вопрос, поправлю после мержа.
Thnx. Сегодня вечером постараюсь поправить.
BugIf кто будет писать?
Поправил — добавил в фабрику перегрузку с LazyThreadSafetyMode вместо булевого флажка. Важно: поведение старого метода со значением флажка true изменилось — теперь возвращается реализация, в которой создание значения синхронизировано, т.е. гарантирует строго один запуск, но ценой блокировок и возможного дедлока.
Мне это не очень нравится, так как вариант без блокировок в большинстве случаев, имхо, предпочтительнее. Но консистентность с конструкторами Lazy<T> все таки важнее.
Просьба поревьювить — из-за нехватки времени пришлось делать подход к снаряду несколько раз, мог что то упустить.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Lexey, Вы писали:
L>Удивил. Я срабатывание AssertState как раз рассматриваю как вину разработчика, ибо Assert в других языках используется именно для диагностики внутренних ошибок логики, а не неверного использования API.
В том числе и для неверного использования API. Например отладочные версии STL. Может конечно там не непосредственно assert, а что-нибудь другое — но суть та же, отключаемые проверки.
Гхмм... какой-то неправильный awesome-dotnet. Не, часть претензий вполне законна, про документацию нам писали все. А вот агитация за копипасту с SO выглядит забавно Да, а товарищ вообще автор репо, или на огонёк зашёл?
Второе возражение, про слишком много всего — частично тож справедливо.
Я бы разнёс чисто bcl-штуки (enumerable extensions, ассерты, operators и тыды) и бизнес-вещи типа маппинга, csv, service provider по разным пакетам.
Это в порядке предложения, воевать за него я не готов
Здравствуйте, Sinix, Вы писали:
S>Второе возражение, про слишком много всего — частично тож справедливо. S>Я бы разнёс чисто bcl-штуки (enumerable extensions, ассерты, operators и тыды) и бизнес-вещи типа маппинга, csv, service provider по разным пакетам. S>Это в порядке предложения, воевать за него я не готов
Вот не далее как вчера пришла такая мысль. Так что я поддержу предложение
Ассерты годная вещь и вполне самостоятельная, так что его даже в отдельный пакет засунуть можно
Здравствуйте, rameel, Вы писали:
R>Вот не далее как вчера пришла такая мысль. Так что я поддержу предложение R>Ассерты годная вещь и вполне самостоятельная, так что его даже в отдельный пакет засунуть можно
Не знаю, меня идея кучи микропакетов не радует. Разве что сделать один кумулятивный.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, rameel, Вы писали:
R>Вот не далее как вчера пришла такая мысль. Так что я поддержу предложение R>Ассерты годная вещь и вполне самостоятельная, так что его даже в отдельный пакет засунуть можно
Не, это уже перебор.
А вот разделить чисто базовые вещи, которые должны по уровню соответствовать BCL и остальные штуки, к которым требования не такие строгие было бы классно.
Кстати, польза от awesome list уже есть. Камрад zihotki не поленился написать про косяк с лицензиями.
Временную быструю заглушку я закинул, теперь надо определиться, что делать дальше. Я бы решил проблему кардинально и выкинул ObjectPool к чертям.
Вроде бы у нас больше нет кода под Apache.
Во-первых, в дотнете планируются куда более интересные Span<T>/Memory<T> + ArrayPool<T>.
Во-вторых, одно дело включать код для таргетинга под 4.0 и совсем другое — скидывать чужой код в свой namespace.
Идея насчёт ObjectPool вроде была моя, но я первый готов признать, что получился неудобняк
Здравствуйте, AndrewVK, Вы писали:
AVK>Не знаю, меня идея кучи микропакетов не радует. Разве что сделать один кумулятивный.
Идея бить на микропакеты мне тоже не нравится, да и все равно вряд ли получится, так как один пакет у нас будет завязан на один, а то и два других, вот так весь CodeJam и подтянется
Идея была разбить библиотеку отдельно для утилитарных вещей, скажем базовую и расширенную, которая будет содержать Mapping, TableData, ServiceProvider и т.п.
А выделить ассерты в отдельный пакет я думал потому как, что ни библиотека так свой велосипед с Guard, Ensure, Require. С отдельным пакетом для ассертов, будет шанс, что люди быстрее согласятся ее использовать, чем писать свой недовелосипед, и детских страхов не будет, что там ой как много всего, что я не хочу. Но это так мысли вслух
Здравствуйте, rameel, Вы писали:
R>Частично есть еще InterlockedOperations: InterlockedOperations.cs
R>Хотя... кода там одна строчка, и который сам собой напрашивается
Ну да. Там отсылка не к конкретной реализации, а к алгоритму. Как пруф, что должно работать.
То же самое можно из исходников фреймворка или из сгенеренного кода для событий вытащить.
В общем, если нам нужно принципиально отвязаться от кода под апач-лицензией, код можем из другого источника взять. Ну, или переписать (хотя там и переписывать-то нечего).
Здравствуйте, Sinix, Вы писали:
S>Временную быструю заглушку я закинул, теперь надо определиться, что делать дальше. Я бы решил проблему кардинально и выкинул ObjectPool к чертям.
А это разве не ты его предложил добавить? Лично мое имхо — штука очень специфичная.
S>Идея насчёт ObjectPool вроде была моя, но я первый готов признать, что получился неудобняк
Ну тогда просто выкинуть и все. Тем более что там и с доккоментами все довольно печально.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>А это разве не ты его предложил добавить? Лично мое имхо — штука очень специфичная.
Предлагал вроде я, по логу — добавил rameel.
S>>Идея насчёт ObjectPool вроде была моя, но я первый готов признать, что получился неудобняк AVK>Ну тогда просто выкинуть и все. Тем более что там и с доккоментами все довольно печально.
Ок, если rameel не против.
Здравствуйте, Sinix, Вы писали:
AVK>>Ну тогда просто выкинуть и все. Тем более что там и с доккоментами все довольно печально. S>Ок, если rameel не против.
Здравствуйте, Sinix, Вы писали:
S>Да, CodeJam.Main.FW35.csproj вообще актуален? Там часть путей (как минимум к Algorithms.EqualRange.Comparer.cs и тыды) старая.
Это отладочный проект, если для таргетинга в 3.5 надо много править и нужна поддержка студии.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
S>>Да, CodeJam.Main.FW35.csproj вообще актуален? Там часть путей (как минимум к Algorithms.EqualRange.Comparer.cs и тыды) старая.
AVK>Это отладочный проект, если для таргетинга в 3.5 надо много править и нужна поддержка студии.
А, ну тогда как будет время — сравни его диффом с основным проектом. Я не хочу туда лезть, т.к. не знаю, что в этом проекте нужно, что нет.
Ну, если честно, я рад, что в awesome нас пока нет — офигенный стимул довести проект до ума.
Потому что замечания-то по делу. Документация ёк, примеры ёк, overbloated — во все поля, развитие... ну пока я один отдуваюсь. Как-то не совсем awesome.
Единственный странный аргумент — про "по отдельности всё это есть". Проблема в том, что каждый мелкий хелпер даёт кучу положительного эффекта и новые пишутся буквально не думая. Тот же свежедобавленный interval tree — все ошибки выловили ассерты, тесты по сути как интеграционные тесты сработали.
Здравствуйте, Sinix, Вы писали:
S>Потому что замечания-то по делу.
Там, по сути, одно замечание — лучше копипастить, чем использовать готовый вылизанный код. Остальное родилось, имхо, исключительно чтобы поспорить.
S> Документация ёк, примеры ёк
Это было понятно и без.
S>overbloated — во все поля,
Можно конкретнее?
S> развитие... ну пока я один отдуваюсь.
Я тебе уже говорил — для конкретно этого проекта это нормально, что нет огромного количества изменений.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Там, по сути, одно замечание — лучше копипастить, чем использовать готовый вылизанный код. Остальное родилось, имхо, исключительно чтобы поспорить.
Ну да, позиция у zihotki своеобразная, но это не значит, что косяков у нас нет
S>>overbloated — во все поля, AVK>Можно конкретнее?
Сейчас CodeJam — всё и обо всём, если разбить (имена условные), получается
* CodeJam.Core — дополнения к фреймворку и таргетинг (отсутствующие типы для младших версий .net)
* CodeJam.Enterprise — все фишки, которые нафиг не нужны для единичной библиотеки, но нужны авторам приложений или своих фреймворков.
Куча проблем уходит. Начиная с моего ворчания по поводу качества кода — оно критично только для базовых вещей, дополняющих готовый код из фреймворка
S>> развитие... ну пока я один отдуваюсь. AVK>Я тебе уже говорил — для конкретно этого проекта это нормально, что нет огромного количества изменений.
Это _не_ нормально. В здоровом проекте есть всегда свободные work items. Т.е. мелкие ошибки типа того, что в начале темы, чинятся сразу, а не как настроение будет.
Ну и нет деления в духе "я правлю только свой код". Нашёл место, которое не устраивает — поправь сразу или с обсуждением в issues.
А, да, насчёт стандартов, можно всё-таки const (и поля, и переменные) с заглавной сделать? Пожалуй единственный пункт, который резко отличается от всех остальных проектов. Раздражает
Здравствуйте, Sinix, Вы писали:
S>Сейчас CodeJam — всё и обо всём,
Он таким и задумывался.
S> если разбить (имена условные), получается S>* CodeJam.Core — дополнения к фреймворку и таргетинг (отсутствующие типы для младших версий .net) S>* CodeJam.Enterprise — все фишки, которые нафиг не нужны для единичной библиотеки, но нужны авторам приложений или своих фреймворков.
Как то слишком нечетко и искусственно, имхо.
S>А, да, насчёт стандартов, можно всё-таки const (и поля, и переменные) с заглавной сделать?
Приватные?
S> Пожалуй единственный пункт, который резко отличается от всех остальных проектов. Раздражает
Это где приватные поля с заглавной буквы?
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
S>>Сейчас CodeJam — всё и обо всём, AVK>Он таким и задумывался.
Ну это не совсем ок, потому что у нас с позиционированием проблемы.
Библиотека для "хелперы к фреймворку" — одно, библиотека для "сделай свой фреймворк" — другое, надо бы разнести.
AVK>Как то слишком нечетко и искусственно, имхо.
Ну да, это общий критерий, который позволяет быстро ответить на вопрос "что выбрать?". По факту точно надо вынести папки Services, Mapping, Metadata, TableData.
S>>А, да, насчёт стандартов, можно всё-таки const (и поля, и переменные) с заглавной сделать? AVK>Приватные?
Ага.
S>> Пожалуй единственный пункт, который резко отличается от всех остальных проектов. Раздражает AVK>Это где приватные поля с заглавной буквы?
Как пример: corefx, поискать "private const" в кавычках. Ссылка:
Здравствуйте, Sinix, Вы писали:
S>Библиотека для "хелперы к фреймворку" — одно, библиотека для "сделай свой фреймворк" — другое, надо бы разнести.
Так а какой бенефит в итоге получится от этого? Вот геморой от двух разных сборок и двух разных пакетов очевиден.
S>>> Пожалуй единственный пункт, который резко отличается от всех остальных проектов. Раздражает AVK>>Это где приватные поля с заглавной буквы? S>Как пример: corefx, поискать "private const" в кавычках. Ссылка: S>
Здравствуйте, AndrewVK, Вы писали:
S>>Библиотека для "хелперы к фреймворку" — одно, библиотека для "сделай свой фреймворк" — другое, надо бы разнести. AVK>Так а какой бенефит в итоге получится от этого? Вот геморой от двух разных сборок и двух разных пакетов очевиден.
С моей точки зрения —
1. Явное разделение зависимостей на слои. Если хелперы начинают тянуть за собой код из, скажем, маппинга, то что-то явно пошло не так
2. Никаких вопросов на тему "ок, мы берём хелперы, но нам не нужна работа с csv, потому что у нас есть своя единственно верная реализация". Таки реальный отзыв. Обоснование было примерно такое: ну вот берёшь ты библиотеку-провайдер для СУБД, а с ней в нагрузку — свой ORM. Впечатление, как будто защитник от mail.ru впаривают Конец цитаты.
3. Меньше борьбы за "весь код должен быть отличным". Ну есть косяки в дизайне отдельных вещей — пусть себе лежат в библиотечке для авторов фреймворков и конечным пользователям не мешают.
Про версии — нет никакого геммороя, главное чтоб релизы обоих сборок выпускались одновременно. Я ж 4 сборки для перфтестов как-то обновляю и ок.
AVK>Кто в лес, кто по дрова.
Ага, есть такое дело. Но с заглавной гораздо чаще встречается. Проверил в репо рослина — тож самое. Во всех проектах, где работал, в другом кейсе писал в основном народ, пересевший с других языков. Выборка не факт что репрезентативная, поэтому за аргумент не катит
S>>Ну и не поля, а константы. То, что константа как поле хранится — это чисто деталь реализации. AVK>https://github.com/dotnet/corefx/search?utf8=%E2%9C%93&q=%22private+static+readonly%22 AVK>Семантически очень близкие сущности выглядят совершенно по разному. Нафига нам этот геморой?
Ухтыж, забавно. В смысле, с моей точки зрения константы гораздо ближе к enum members чем к полям. Если рассматривать константы как поля — то да, твой вариант логичнее. Если остальных устраивает — ок.
S>> Приватные Enum-ы ж с заглавной — норм. AVK>Енум это тип, а не поле.
Я про enum members. Не, понятно, что под капотом у enum member — public const field, но это чисто деталь реализации.
AVK>Какие то хвосты остались. Поправил
Ок, спасиб!
Здравствуйте, Sinix, Вы писали:
S> 1. Явное разделение зависимостей на слои. Если хелперы начинают тянуть за собой код из, скажем, маппинга, то что-то явно пошло не так
У нас в качестве одного из основных design goals заявлена минимальная связность. Поэтому такое маловероятно, по крайней мере в текущем составе контрибьюторов.
S> 2. Никаких вопросов на тему "ок, мы берём хелперы, но нам не нужна работа с csv, потому что у нас есть своя единственно верная реализация".
Да нет, вопросы все равно будут — всего два пакета их не снимут. Чтобы их не было, нужно чуть ли не каждую фичу в отдельный микропакет пихать.
S> Таки реальный отзыв. Обоснование было примерно такое: ну вот берёшь ты библиотеку-провайдер для СУБД, а с ней в нагрузку — свой ORM.
Это — другое. Вероятность что понадобится драйвер и не понадобится ОРМ — очень высока. А вот в случае предложенного деления — я в подобном сильно не уверен.
S> 3. Меньше борьбы за "весь код должен быть отличным".
Это — плохо.
S>Про версии — нет никакого геммороя, главное чтоб релизы обоих сборок выпускались одновременно. Я ж 4 сборки для перфтестов как-то обновляю и ок.
Тебе деваться некуда из-за зависимостей.
S>Ухтыж, забавно. В смысле, с моей точки зрения константы гораздо ближе к enum members чем к полям.
enum members это тоже поля. И они таки пишутся точно так же, как и поля. Просто они приватными быть не могут.
S>>> Приватные Enum-ы ж с заглавной — норм. AVK>>Енум это тип, а не поле. S>Я про enum members.
Они не бывают приватными.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
AVK>У нас в качестве одного из основных design goals заявлена минимальная связность. Поэтому такое маловероятно, по крайней мере в текущем составе контрибьюторов. AVK>Да нет, вопросы все равно будут — всего два пакета их не снимут. Чтобы их не было, нужно чуть ли не каждую фичу в отдельный микропакет пихать.
Окей, тогда остановимся на том что есть. Саммари: я за разделение, знакомый народ говорит что мы переборщили с фичами, rameel в теме тож за разделение, ну, т.е. реальные запросы есть и я их донёс надеюсь
AVK>Это — другое. Вероятность что понадобится драйвер и не понадобится ОРМ — очень высока. А вот в случае предложенного деления — я в подобном сильно не уверен.
Ну вот я в жизни не представлю, чтоб типовой дотнет-библиотеке понадобилась запись в csv, mapping или что-то в таком духе. Это всё ответственность хоста, т.е. приложения (фреймворка).
Остальные части кода обычно не используют подобное API напрямую, а используют вариант, предоставленный хостом.
К примеру, у нас serviceProvider.GetService<T>() может возвращать null.
В проектах, в которых за дизайн отвечать мне, метод в public API с таким поведением будет называться TryGetService<T>() и никак иначе. Мелочь, но когда такая мелочь систематически выстреливает NullRefException быстро понимаешь, что мелочи решают.
Т.е. нашу реализацию я если и буду использовать, то только спрятанной под капотом.
И что самое прикольное, что поправить тут ничего нельзя. Если мы поменяем поведение и serviceProvider.GetService<T>() будет бросать исключение, то тут же взбунтуется вторая половина пользователей, которым NullRefException не страшны (к примеру, весь код решарпером на null проверяется) и важнее совместимость с фреймворком.
Короче, такие холиварные вещи, для которых есть куча равноправных решений, лучше делать opt-in. Чтобы не следить за тем, что в проекте случайно заюзалась "неправильная" реализация.
S>> 3. Меньше борьбы за "весь код должен быть отличным". AVK>Это — плохо.
Это хорошо. Потому что "энтерпрайзный" код у нас в основном весь уже написан в одно лицо и у каждого одноголица свои привычки и свои критерии отличного кода. К примеру код от ув. IT почти весь использует выравнивание пробелами.
Имеет смысл бороться за одинаковое форматирование? Для мелочей типа тех что я добавляю — безусловно да, т.к. там нет никакой особой магии и поправить или написать подобное может любой с полпинка.
Для того же маппинга мы не получим никакого эффекта, только минус — маппинг по-прежнему будет оставаться ответственностью IT, а вся помошь от нас сведётся к "мы тебе оформление поменяли"
S>>Про версии — нет никакого геммороя, главное чтоб релизы обоих сборок выпускались одновременно. Я ж 4 сборки для перфтестов как-то обновляю и ок. AVK>Тебе деваться некуда из-за зависимостей.
Так и тут то же самое будет, не вижу смысла разносить версии обоих библиотек.
S>>Я про enum members. AVK>Они не бывают приватными.
Ну ок, точку зрения я донёс, дальше спорить не буду.
Здравствуйте, Sinix, Вы писали:
S>Окей, тогда остановимся на том что есть. Саммари: я за разделение, знакомый народ говорит что мы переборщили с фичами, rameel в теме тож за разделение, ну, т.е. реальные запросы есть и я их донёс надеюсь
Здравствуйте, _NN_, Вы писали:
S>>т.е. реальные запросы есть и я их донёс надеюсь
_NN>Может опросом решить ?
Неа. Опрос хорош как сбор реквестов от пользователей, но не как способ принятия решений в команде. Я терпеть не могу демократию внутри проекта — она в итоге ни к чему хорошему не приводит. Всегда должен быть лид, который и принимает конечное решение.
У нас это AndrewVK как автор проекта и человек, добровольно взваливший на себя всю организационную тягомотину
Здравствуйте, Sinix, Вы писали:
S>Неа. Опрос хорош как сбор реквестов от пользователей, но не как способ принятия решений в команде. Я терпеть не могу демократию внутри проекта — она в итоге ни к чему хорошему не приводит. Всегда должен быть лид, который и принимает конечное решение.
У меня пока определенного мнения нет, так что опрос не помешает.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>У меня пока определенного мнения нет, так что опрос не помешает.
Ок. Заведёшь сам? Если нет — подскажи, как вставить голосование в пост?
Здравствуйте, Sinix, Вы писали:
AVK>>У меня пока определенного мнения нет, так что опрос не помешает. S>Ок. Заведёшь сам? Если нет — подскажи, как вставить голосование в пост?
Да просто ссылку на него добавляешь и все.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>