Никогда не понимал возни с Settings (или как там этот класс зовут) и вообще использование словарей для хранения/доступа к настройкам…
Пишется свой класс, расставляются аттрибуты, сериализуется/десериализуется чем вам больше нравится (json.net, XmlSerializer, ...) в куда вам необходимо (в MemoryStream -> byte[] -> db или же в FileStream)… Если конфигурация одна — синглтон, несколько — доступ через менеджер (Config.Active, Config.Load, etc.).
Все вышеперечисленное занимает буквально десяток строк (если не реализовывать что-то слишком навороченное, к примеру версионинг).
Имхо нет смысла в надстройке над чем-то дефолтовым и кривым. Плюс я не очень понял чем же лучше
хорошие игры развлекают — значит, This War of Mine должна оказаться «весёлой», правда ?
Логика зашкаливает.
«Развлечение» это слишком общий термин, кто-то любит хорроры (фильмы с бензопилой), кто-то головоломки, кто-то хороший сюжет, а кому-то достаточно пройтись по парку и все, «развлекся». Суть в эмоциях, радость — это лишь один из вариантов.
Поэтому это будет непросто, и нам нужно больше игр, подобных This War of Mine, не «развлекающих» в традиционном смысле, а захватывающих внимание игрока
Опять двадцать пять. Суть любой игры — захватить внимание, вызвать интерес, не надоесть. И т.к. у людей разные вкусы, нам попросту нужно много разных игр. Меня в This War of Mine играть вообще не тянет (я больше фанат Terraria ну и как все не брезгую AAA играми). Главное в новых играх — разнообразие, взять тех же покемонов на мобильнике в прошлом году, смогли ведь! С другой стороны в стиме куча недоделанных клонов Террарии (некоторые довольна неплохие, тот же Starbound) и это хорошо, потому что мне нравятся игры такого типа.
К чему я все это? К тому что у статьи полезность где-то 1/1000. Зачем было это писать/переводить в сюда? Непонятно…
У EEPROM время жизни скажем ~100 тысяч циклов, если обновлять одну и ту же ячейку раз в секунду, то хватит примерно на сутки. Идея заключается в том, чтобы использовать новую позицию для записи каждый раз, 1К памяти хватит на 3 года.
Простейший алгоритм реализации — это ввести некий счетчик, который увеличивается каждый раз при сохранении структуры (содержащей данные и сообственно счетчик). Если счетчик дошел до 100.000 — инкрементируется позиция структуры (которую можно хранить по фиксированному адресу, т.к. запись туда происходит редко).
Вряд ли в этом вся суть, скорее всего это просто такой стиль арт… Гляньте на Magicite, там просто огромные пиксели, что не мешает наслаждаться рогаликом и придает игре некий олд-скульный хардкорный шарм.
Это для инди-игр в стиле pixel graphics. Они все еще выходят, популярны и я в них играю Оо… Посмотрите, к примеру, Terraria (и ее многочисленные клоны) и Stardew Valley. Они жутко интересны, затягивают и к ним вырабатывается привыкание.
Генератор спрайтов, я думаю, сэкономит кучу времени разработчикам, особенно если он, как я понял, работает в реальном времени и что-то там с цветами еще понимает (я сам не разработчик игр).
Почему вы решили, что это в компетенции переводчика? Перевести технический текст, буду слегка в теме, это одно, а добавить что-то новое в перевод — совсем другое. Тоесть да, нельзя было.
Это проблема любой системы перевода (не относится к решению предлагаемому в статье). Проще всего в локализируемую строку поместить токен, который программа подменяет на значение в run-time, в простейшем случае можно тупо использовать "{0}" и string.Format(localizedString, someValue), хотя вы понимаете, чем это чревато.
А по-поводу статьи (далее обращаюсь к ТС), извините, но вводить новый тип для строк и использовать что-то вроде
var fu = new MultiCulturalString(ru, "Шоколад Алина").SetLocalizedString(en, "Chocolate Alina");
вообще не круто. Интересно будет посмотреть как это выглядит в конце. Плюс вы не привязываетесь ни к winforms, ни к wpf (ни к чему-то еще?). А это как раз представляет больший интерес, чем простая возможность хранить строки для MessageBox.
В данный момент мы используем решение, где локализируемые строки выглядят как простой класс с «константами»:
public static class Lng
{
public static class Login
{
public static string Disconnect { get; private set; } = "Disconnect";
...
}
...
}
а «локализация» происходит за счет рефлексии. Для WPF это легко обернуть в MarkupExtension где нужные строки возвращаются по ключу (ключ — это путь к свойству, к примеру Login.Disconnect).
Проблемы с конкатенацией (на которой вы делаете упор, обьясняя необходимость нового типа) решается элементарно конкатенацией предложений или фраз с независимым от культуры разделителем (например, перевод строки). Понятно, что обьединять слова/фразы в предложение не получится (в русском, например, нужно правильно построить окончания).
Возвращать null на неизвестную строку? Боже упаси! Если строка отсутствует в файле локализации, то вернется значение по умолчанию (в нашем случае это псевдо-english, который по-хорошему следует локализовать в en-US/en-GB). Если неверен ключ, но вернется значение ключа "!!!" + key (в этом случае пользователь/тестер сможет оперативно сделать багрепорт, а программист — с легкостью найти ошибку).
Чем плох словарь «каждый раз при обращении» со string ключами (в которых банально можно сделать ошибку) или необходимость перезагружать форму при смене языка? За 10+ лет работы с winforms у меня было несколько версий более удобных велосипедов: генераций ключей в виде типа с константами (для исключения run-time ошибок из-за опечаток в ключе), перевод форм рефлексией с авто-генерерируемым списком ключей (по именам контролов, что-то вроде FormLogin.panelLeft.labelLogin.Text=«Login»), генерацией текстовых файлов для локализации «на лету» и т.д.
Хорошая альтернатива, по крайней мере для текста, это разовая загрузка констант через рефлексию из обычного текстового файла и обращение к локализированному тексту посредством констант (нельзя ошибиться, удобно находить ссылки или не используемые более строки). Это сообственно то, что используется в моих последних программах на winforms.
Раскрытие этой темы тянет на полноценную статью. Для winforms пожалуй уже поздно что-то выкладывать, впрочем у wpf аналогичная проблема тоже имеется, плюс в xaml локализацию через кастомные xaml markup extension удобно делать, уверен просто, что подобное уже написано.
Код для статьи можно было бы и почистить. Вы же орфографию и синтаксис текста проверяете? А код, значит, можно просто так «сырой вываливать»?
Я не понимаю принципа «писалось на скорую руку». Если с технологией опоздали, куда со статьей спешить-то? И да, сейчас что-то ниже WPF серьезно снижает полезность материала.
Про возраст я не совсем удачно выразился (потому и минусы наверное), имелось в виду вступление, в котором вы как бы заранее извинитесь за свой уровень что ли. Представьте, вы выходите на сцену перед разношерстной аудиторией (включая и профи). Если вам, к примеру, 10 лет, то вы автоматически получаете перк «Отключить сарказм 40+ летних профи». Вы же наоборот, упомянули, что ранее писали уже программы (сколько лет? 10? 20?), это как минимум перк «Расценивать как равного и ожидать равного»… а тут winforms /разочарование /боль…
Не расценивайте мой комментарий как укор или ненависть там, это просто немного критики (с которой видимо не согласны, так что скорее меняться нужно мне, а не вам). Мне статья в принципе понравилась. ;)
Полностью согласен с «лапшей», ну не солидно это, делится таким кодом (закомментированный отладочный код и стиль уже о многом говорят). Было бы неплохо, если бы первый абзац был вступительный, в стиле «Здравствуйте, меня зовут Алекс и я программист. Мне 10 лет ...». ;)
Статья, кстате, неплохо написана (идея, последовательность, подача материала, совместимость, ...). Единственная претензия — это winforms в 2016. Серьезно? Подобное было актуально лет 10+ тому. Локализация эта через ж… сателиты… аж коробит, извините.
Хакатон в «обычных» условиях — это не хакатон. Изначально термин связан с тем, что нужно куда-то пойти/поехать: должна быть новая обстановка (не ежеденевная рутинная), ограниченость инструментария, импровизирование, случайные люди для кооперирования…
То, что вы делали — это маркетинговый ход руководства… «Бесплатные фичи» или как-то так. Я так и не понял разницы между обычным рабочим днем и описанными выходными в данном случае.
Задался вопросом, что означает «закопайте стюардессу»:
… Самолёт терпит крушение над океаном, в живых остаются трое: пилот, помощник пилота и стюардесса, — им удаётся выбраться на необитаемый остров. Через месяц жизни втроём пилот сказал: «Долой разврат!» — и убил стюардессу. Ещё через месяц он опять сказал: «Долой разврат!» — и закопал стюардессу. Ещё через месяц он сказал: «Долой разврат!» — и откопал стюардессу...
А по теме… Сколько времени было затрачено на статью? Где примеры? Ну вот реально, подумайте, какая польза от статьи с сухими перечислениями? Те, кто это знают — пролистнут и забудут, те, кто не знает — прочтут и тут же забудут. Для кого/чего это пишется? Для кармы?
Почему ссылка на полиморфизм взята для PHP (который я не знаю)? От фонаря (та статья еще хуже чем эта, начинается с растянутого примера, в конце сухо чуток теории)? Зачем тег C# тогда?
P.S.: справедливости ради признаюсь — про паблик Морозова не знал, рассмешило слегка.
Похоже, что в веб разработке дизайнер это еще и пол-архитектора. Я не дизайнер, но ожидаю от дизайнера в основном картинку (desktop application): правильные цвета, шрифты, размеры, иконки… Usability это наполовину моя (не дизайнерская) проблема. Она как-раз и зависит от нюансов (заполнить данные асинхронно? подождать, заблокировав UI? и тд). Любое решение дизайнера должно быть одобрено архитектором или руководителем проекта, т.к. те решения, что на бумаге, могут подчас требовать в 100 раз больше человеко-времени и это сложный выбор — сделать «идеально» для пользователя или же съэкономить. Дизайнер — не программист, чтобы принимать такие решения самостоятельно.
Статья не понравилась. Интрига есть (я «почти» согласился, что null — это «однозначно ошибочное решение, бездумно скопированное из более ранних языков»), но в «исторической альтернативе» все как-то, извините, «сдулось» в один маленький абзац.
Нет примеров, видно, что автор знает больше, но рассказывать явно не собирается (ссылки — хорошо, но примеры никто не отменял, кстате, некоторые из ссылк на ru-ru msdn, некоторые на en-us). Сухие перечисления без примеров — бесполезны, никто не будет «заучивать» их наизусть, без понимания почему так.
Почему ?. называют Элвисом (кстате, правильно использовать в качестве термина словосочетание «null-coalescing», а не глалог «coalesce)?
Почему if(something != null) вдруг „антипаттерн“? „Единственное назначение которого — выбросить исключение поближе к месту предательства“ — никто не выбрасывает NullReferenceException и никто не отменял валидацию параметров метода (InvalidArgumentException) или ошибочных сценариев (InvalidOperationException). Или имелось в виду что-то другое?
Перед тем, как показывать код кому-то, следовало бы немножко подготовиться (в частности прочитать вот это). Если вы пишете о чем-то специфическом, то может быть не следует отвлекать читателя, к примеру, деталями реализации чего-то отвлеченного (в частности XML сериализации). Стиль комментариев тоже «необычный», к тому же присутствует полное отсутствие комментариев в коде.
Извините за придирки, но вы сами попросили отзывов, а меня лично такой стиль исходников немного раздражает (возможно потому, что в моей команде из 4 программистов два пришли из С и продолжают забивать болт на C# стиль и коментарии, уже накипело).
По данным CB Insights, только 5% стартапов прогорают по причине слабой технической реализации
Простите, а где там такое написано? Друг интересуется, я было обрадовался, смотри мол, пофиг на твой левел, главное — маркетинг. А по ссылке какой-то мутный перечень, без сводки. Запросил там отчет, получил сводку. В ней тоже нет 5%.
Поэтому резонный вопрос, откуда взята цифра? От верблюда?
Browser/rendering engine — резанул уши «механизм браузера» — звучит отвратительно (browser mechanism, представляется эдакий тормознутый 30км/ч трактор). В профессиональной среде (где использовать слэнг между коллегами разрешено) engine переводится как «движок» (например, unreal engine, game engine, rendering engine — все движки). «Браузер» ведь почему-то оставили (не стали «переводить» его как «просмотрщик» там или еще как)…
Пользуюсь SO 3 года, отличная идея и реализация. Из-за появление SO множество других тематических сайтов потеряло свою актуальность (к примеру, RSDN).
Недавно узнал, что есть локализированные версии SO (русская, португальская и тд.). И мне не дает покоя вопрос: зачем? Кто туда ходит? Это связано с локализированной же версией Carrier (предложения работы)? Искать ответы на вопросы имхо лучше на английском, как уже заметили в другом комментарии, у русского все «неоднозначно», для одного термина может быть несколько распространенных рускоязычных же терминов, понятно, что поисковую систему можно обучить, но все же я предпочитаю вбивать в гугл оригинальное название (к пример, thread, а не «поток», «трэд», «тред» и тд).
У SO уже существует огромная база знаний (по сути, 99% от задаваемых вопросов это дупликаты, в некоторых случах проблему сложно выявить в «wall of code», после — это тот же дупликат). Локализированные версии SO (русскоязычная) по сути будут заниматься накоплением базы ответов на своем языке. Звучит как мартышкин труд, вместо ссылки на дупликат ответ это: 1) перевести вопрос на английский 2) найти ответ 3) перевести ответ на русский.
Какой еще смысл (кроме поиска/предложения работы) несет русскоязычный SO?
Пишется свой класс, расставляются аттрибуты, сериализуется/десериализуется чем вам больше нравится (json.net, XmlSerializer, ...) в куда вам необходимо (в MemoryStream -> byte[] -> db или же в FileStream)… Если конфигурация одна — синглтон, несколько — доступ через менеджер (Config.Active, Config.Load, etc.).
Все вышеперечисленное занимает буквально десяток строк (если не реализовывать что-то слишком навороченное, к примеру версионинг).
Имхо нет смысла в надстройке над чем-то дефолтовым и кривым. Плюс я не очень понял чем же лучше
особенно доставляет dynamic и (на внимательность) «StmpSettings».
Управление гормонами осуществляется гипофизом.
Шта? Какой такой коры?
и вдруг ни с того, ни с сего
Логика зашкаливает.
«Развлечение» это слишком общий термин, кто-то любит хорроры (фильмы с бензопилой), кто-то головоломки, кто-то хороший сюжет, а кому-то достаточно пройтись по парку и все, «развлекся». Суть в эмоциях, радость — это лишь один из вариантов.
Опять двадцать пять. Суть любой игры — захватить внимание, вызвать интерес, не надоесть. И т.к. у людей разные вкусы, нам попросту нужно много разных игр. Меня в This War of Mine играть вообще не тянет (я больше фанат Terraria ну и как все не брезгую AAA играми). Главное в новых играх — разнообразие, взять тех же покемонов на мобильнике в прошлом году, смогли ведь! С другой стороны в стиме куча недоделанных клонов Террарии (некоторые довольна неплохие, тот же Starbound) и это хорошо, потому что мне нравятся игры такого типа.
К чему я все это? К тому что у статьи полезность где-то 1/1000. Зачем было это писать/переводить в сюда? Непонятно…
Простейший алгоритм реализации — это ввести некий счетчик, который увеличивается каждый раз при сохранении структуры (содержащей данные и сообственно счетчик). Если счетчик дошел до 100.000 — инкрементируется позиция структуры (которую можно хранить по фиксированному адресу, т.к. запись туда происходит редко).
Генератор спрайтов, я думаю, сэкономит кучу времени разработчикам, особенно если он, как я понял, работает в реальном времени и что-то там с цветами еще понимает (я сам не разработчик игр).
А по-поводу статьи (далее обращаюсь к ТС), извините, но вводить новый тип для строк и использовать что-то вроде
вообще не круто. Интересно будет посмотреть как это выглядит в конце. Плюс вы не привязываетесь ни к winforms, ни к wpf (ни к чему-то еще?). А это как раз представляет больший интерес, чем простая возможность хранить строки для MessageBox.
В данный момент мы используем решение, где локализируемые строки выглядят как простой класс с «константами»:
а «локализация» происходит за счет рефлексии. Для WPF это легко обернуть в MarkupExtension где нужные строки возвращаются по ключу (ключ — это путь к свойству, к примеру Login.Disconnect).
Проблемы с конкатенацией (на которой вы делаете упор, обьясняя необходимость нового типа) решается элементарно конкатенацией предложений или фраз с независимым от культуры разделителем (например, перевод строки). Понятно, что обьединять слова/фразы в предложение не получится (в русском, например, нужно правильно построить окончания).
Возвращать null на неизвестную строку? Боже упаси! Если строка отсутствует в файле локализации, то вернется значение по умолчанию (в нашем случае это псевдо-english, который по-хорошему следует локализовать в en-US/en-GB). Если неверен ключ, но вернется значение ключа "!!!" + key (в этом случае пользователь/тестер сможет оперативно сделать багрепорт, а программист — с легкостью найти ошибку).
Хорошая альтернатива, по крайней мере для текста, это разовая загрузка констант через рефлексию из обычного текстового файла и обращение к локализированному тексту посредством констант (нельзя ошибиться, удобно находить ссылки или не используемые более строки). Это сообственно то, что используется в моих последних программах на winforms.
Раскрытие этой темы тянет на полноценную статью. Для winforms пожалуй уже поздно что-то выкладывать, впрочем у wpf аналогичная проблема тоже имеется, плюс в xaml локализацию через кастомные xaml markup extension удобно делать, уверен просто, что подобное уже написано.
Я не понимаю принципа «писалось на скорую руку». Если с технологией опоздали, куда со статьей спешить-то? И да, сейчас что-то ниже WPF серьезно снижает полезность материала.
Про возраст я не совсем удачно выразился (потому и минусы наверное), имелось в виду вступление, в котором вы как бы заранее извинитесь за свой уровень что ли. Представьте, вы выходите на сцену перед разношерстной аудиторией (включая и профи). Если вам, к примеру, 10 лет, то вы автоматически получаете перк «Отключить сарказм 40+ летних профи». Вы же наоборот, упомянули, что ранее писали уже программы (сколько лет? 10? 20?), это как минимум перк «Расценивать как равного и ожидать равного»… а тут winforms /разочарование /боль…
Не расценивайте мой комментарий как укор или ненависть там, это просто немного критики (с которой видимо не согласны, так что скорее меняться нужно мне, а не вам). Мне статья в принципе понравилась. ;)
Статья, кстате, неплохо написана (идея, последовательность, подача материала, совместимость, ...). Единственная претензия — это winforms в 2016. Серьезно? Подобное было актуально лет 10+ тому. Локализация эта через
ж… сателиты… аж коробит, извините.То, что вы делали — это маркетинговый ход руководства… «Бесплатные фичи» или как-то так. Я так и не понял разницы между обычным рабочим днем и описанными выходными в данном случае.
… Самолёт терпит крушение над океаном, в живых остаются трое: пилот, помощник пилота и стюардесса, — им удаётся выбраться на необитаемый остров. Через месяц жизни втроём пилот сказал: «Долой разврат!» — и убил стюардессу. Ещё через месяц он опять сказал: «Долой разврат!» — и закопал стюардессу. Ещё через месяц он сказал: «Долой разврат!» — и откопал стюардессу...
А по теме… Сколько времени было затрачено на статью? Где примеры? Ну вот реально, подумайте, какая польза от статьи с сухими перечислениями? Те, кто это знают — пролистнут и забудут, те, кто не знает — прочтут и тут же забудут. Для кого/чего это пишется? Для кармы?
Почему ссылка на полиморфизм взята для PHP (который я не знаю)? От фонаря (та статья еще хуже чем эта, начинается с растянутого примера, в конце сухо чуток теории)? Зачем тег C# тогда?
P.S.: справедливости ради признаюсь — про паблик Морозова не знал, рассмешило слегка.
Нет примеров, видно, что автор знает больше, но рассказывать явно не собирается (ссылки — хорошо, но примеры никто не отменял, кстате, некоторые из ссылк на ru-ru msdn, некоторые на en-us). Сухие перечисления без примеров — бесполезны, никто не будет «заучивать» их наизусть, без понимания почему так.
Почему ?. называют Элвисом (кстате, правильно использовать в качестве термина словосочетание «null-coalescing», а не глалог «coalesce)?
Почему if(something != null) вдруг „антипаттерн“? „Единственное назначение которого — выбросить исключение поближе к месту предательства“ — никто не выбрасывает NullReferenceException и никто не отменял валидацию параметров метода (InvalidArgumentException) или ошибочных сценариев (InvalidOperationException). Или имелось в виду что-то другое?
Извините за придирки, но вы сами попросили отзывов, а меня лично такой стиль исходников немного раздражает (возможно потому, что в моей команде из 4 программистов два пришли из С и продолжают забивать болт на C# стиль и коментарии, уже накипело).
Поэтому резонный вопрос, откуда взята цифра? От верблюда?
Недавно узнал, что есть локализированные версии SO (русская, португальская и тд.). И мне не дает покоя вопрос: зачем? Кто туда ходит? Это связано с локализированной же версией Carrier (предложения работы)? Искать ответы на вопросы имхо лучше на английском, как уже заметили в другом комментарии, у русского все «неоднозначно», для одного термина может быть несколько распространенных рускоязычных же терминов, понятно, что поисковую систему можно обучить, но все же я предпочитаю вбивать в гугл оригинальное название (к пример, thread, а не «поток», «трэд», «тред» и тд).
У SO уже существует огромная база знаний (по сути, 99% от задаваемых вопросов это дупликаты, в некоторых случах проблему сложно выявить в «wall of code», после — это тот же дупликат). Локализированные версии SO (русскоязычная) по сути будут заниматься накоплением базы ответов на своем языке. Звучит как мартышкин труд, вместо ссылки на дупликат ответ это: 1) перевести вопрос на английский 2) найти ответ 3) перевести ответ на русский.
Какой еще смысл (кроме поиска/предложения работы) несет русскоязычный SO?