Totoro

Я вот тут задумался, а как быть с интернационализацией (и локализацией) программ? Когда программа становится достаточно большой и популярной, возникает мысль выложить её на каком-нибудь иностранном ресурсе. Ну или просто какой-нибудь чувак приходит и говорит: "I like your program very much, but I don't understand russian at all". Свой голографический редактор, например, я поддерживаю в двух версиях одновременно - русской и английской. По сути два отдельных клона программы. Это не очень удобно. Отсюда вопрос - как запилить удобную систему локализации программ? 1) Клоны программы на разных языках Самый дубовый способ. То как я делал до недавнего времени. Выпускаете программу, делаете несколько копий, каждую переводите на разные языки. Не очень удобно для вас - потому что надо клонировать и переводить каждую новую версию. Не очень удобно для тех, кто хотел бы вам помочь с переводом - они не разбираются в вашем коде, и искать в нём, что надо перевести им будет не удобно. Эту задачу можно облегчить, если вынести все фразы в табличку в начале программы: local text = { greetings = "Приветствую!", ... } Тогда можно будет не копаться в поисках отдельных строк по всему коду, а только перевести эту табличку. 2) Файлы локализации Делаем отдельный файлик, наподобие конфига. В него записываем такие же пары значений, например: greetings = Приветствую! И потом считываем его из программы при старте. Можно сделать дефолтные значения, которые прописаны прямо в коде, и будут использоваться, если программа не нашла файлы локализации. Сами файлики могут лежать рядом с программой, или в папке /etc/my-project/..., или ещё где-то. Если заливать программу в репозиторий, тоже возникают варианты. Мы может создать несколько пакетов, например: holo-ru, holo-en. Это как-то немного нелогично. Установка программы будет выглядеть так: hpm install holo-en Другой способ - это дублировать версии пакета, и дописывать им языковой суффикс: 0.1.0-en, 0.1.0-fr. Вроде получше. Установка будет выглядеть так: hpm install holo@0.7.1-ru Недостаток - нам всегда придётся указывать версию полностью. То есть нельзя будет как раньше - просто указать название пакета, а репозиторий сам выдаст самую свежую версию. Ещё один способ - это держать файлы локализации отдельными пакетами от основного проекта: проект holo и локализационный пакет holo-lang-en например. Тогда саму программу можно будет установить как раньше. Но если мы захотим сменить дефолтный язык, придётся указывать дополнительный пакет: hpm install holo, holo-lang-en Тоже не совсем юзерфрендли. Предлагаю обсудить эту тему, и придти к какому-нибудь удобному стандарту. Какие варианты решения проблемы приходят вам на ум?

Какое модифицирование мода? Там на C++ вроде только генератор шрифта. Генеришь его и используешь потом через обычную прогу.

А ещё, если бы ты был подписан на нашу группу, ты бы знал о существовании вот такой прикольной либы.

Дело не только в протоколе, а в том, что Windows - это сложная структура с закрытым кодом. Комплексная. Там много разных программ, служб и утилит, каждая со своими косяками, и то как они сочетаются вместе на конкретном компьютере порождает ещё больше уникальных дыр и косяков. Весь этот зоопарк простоянно прощупывают и исследуют разными способами хакеры. ВаннаКрай - это просто один вирус, который вышел из под контроля (ну либо хакеры обнаглели наконец =)) и стал заметен. А другие уязвимости, которые используют один-два человека, могут оставаться незаметными годами.

Обновления часто происходят "пост-фактум". То есть: 1) хакеры нашли дыру 2) хакеры ей воспользовались 3) общественный резонанс 4) Microsoft заштопал дыру То есть обновления безопасности защитят от уже найденных дыр, но никак не спасут от обилия дыр никому не известных.

Ну веб в нашем случае - меньшее из зол. К тому же, теоретически, можно вообще не выполнять вычислений на вебе, а просто запомнить точное время предыдущего запроса и состояние счёта на тот момент. Когда клиент снова захочет узнать состояние счёта - мы рассчитываем разницу во времени между запросами, конвертируем её по обменному курсу к валюте и прибавляем к состоянию счёта в последний раз. Вуаля. Сервер вообще не нагружен, если не считать собственно обработки запросов. =)

@Alex Сбрасываем в корзину? Тема вроде особой актуальности не несёт. Один флуд. Автор я так понимаю решил таки доработать проект.

Цветные линии создадут много визуального шума, имхо.

Вообще не надо ничего заменять. Как когда-то давно заметил Фингер, писать операционную систему для OpenComputers - занятие сомнительной нужности. А вот запилить крутую графическую оболочку - это другое дело.

Никольно не принижаю качество проекта - штука охрененно крутая. =) На скрине написано: "ОС - это первый и основной набор программ, загружающихся в компьютер". Первый и основной у нас как раз и идёт OpenOS. А MineOS потом загружается поверх. Ничего плохого в этом нет, первые версии Windows так же работали (как уже кто-то выше упомянул).

В случае реальных криптовалют - майнинг имеет прямое практическое значение. При майнинге пользователи подтверждают транзации. То есть валюта держится на майнерах. Они - её основной двигатель и заодно гарант безопасности. В твоём случае именно модель майнинга имеет только ролевое значение - можно "отыграть" роль "майнера криптовалют". Но это можно сделать проще, и с меньшими нагрузками на сервер. То есть на практике у тебя просто есть набор аккаунтов, на которые, с большими лагами начисляются виртуальные монетки. Всё. Может тогда взять модель криптовалюты Nimses? Пользователь создаёт аккаунт и просто получает монетки за просто так. С какой-то фиксированной скоростью. Нуль нагрузки на сервера - а эффект такой же.

Не надо обощать. P.S. И вообще, почему вы называете MineOs "операционной системой"? Строго говоря - это DE ("desktop environment"). Графическая оболочка.

Справедливости ради, как раз это оправдано. Называется - "избавиться от магических констант". Когда каждое число (или любое другое значение) в коде сохранено в переменную - оно имеет название. А название - поясняет, что это за число. Например, что понятнее? if x > 0 and x < WIDTH then ... end или if x > 0 and x < 19 then .. end В первом случае очевидно идёт проверка по попадание координаты по ширине. Во втором - не обязательно. Приходится приглядываться к этому фрагменту внимательнее. К тому же, когда ширина вынесена в отдельную переменную, ты можешь изменить её значение сразу в сотне мест в коде. Просто поменяв одну строку. А если бы везде использовались просто числа, пришлось бы лопатить код, и надеяться, что ты не забыл где-то что-то поменять.

При всём уважении к чувствам автора, это что-то странное. Типа: "у меня тут внезапно зачезались руки и я пять минут писал на языке, который похож на Луа; вот, держите, теперь вы сами разбирайтесь что это за хренотня".

А в чём фишка системы тогда вообще? Это просто сервер с базой данных, где записано число монеток для каждого ника? Или там даже базы данных нет?

Лагодромщики, сэр.

В предложении @Appo я одобряю только аватару.

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

UT - это UT, всё таки. У него уже сложившийся формат. Это арена, где программисты показывают свои скиллы, выпуская сражаться заранее запрограммированных ботов. А вот после UT можно будет запустить что-нибудь новенькое и под новым названием. Какой-нибудь хацкерский челлендж, где участники будуть ломать друг друга по сети, например. Или гонки за летучими коровами на хряко-коптерах, управляемых через OpenGlasses. Любую хренотень. =)

Конечно! Это добавит веселья и непредсказуемости. Можно будет сидеть на базе весь раунд, а потом за две минуты до таймаута совершить стремительный налёт и подмять 55% территории под себя. Победа! Да, я думаю такой механизм тоже будет. Это ведь логично. Например на точку навалилось трое вражеских дронов. У меня нет ресурсов чтобы противостоять им, но я могу выделить одного дрона из своей команды, чтобы замедлить захват, и задержать их до момента, когда подоспеет подкрепление. Хорошая идея. 1) Вот тут я согласен. Это будет удобно. 2) В эфире конечно какофония будет, но почему нет. 3) + Насчёт зарядников, я думаю они будут определены конфигурацией карты. То есть будут, как и спавны дронов, находиться в постоянных, более менее сбалансированных, всем известных местах. P.S. @Alex, @qwertyMAN. Да, мы вкладываем много усилий, и всё можно было бы организовать по другому, правильнее и проще, и может быть это было бы популярнее. У нас не лига CodeForces, увы, и участники не всегда пишут красивый и оптимальный код, и не всегда всё идёт по плану. Но может мы кого-нибудь вдохновим на проведение своего эвента, с учётом возникшей критики и предложений?

Именно так. А теперь спросим себя - какие именно скиллы мы хотим развить в участниках? Скиллы программирования, или скиллы быстрого клацанья мышью и клавой? Я бы всё таки хотел ориентироваться на первый вариант. Для фана же. =) Куда веселее и менее предсказуемо зайти на сервер и потусоваться с остальными зрителями, наблюдая - чья одолевает. А если слишком скучно наблюдать со стороны - становись участников, и болей за своего бота!

Что за пессимизм тут такой? =) У нас прошло уже два этапа, и недостатка в участниках и зрителях пока не было.

True

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

Чот мне кажется у Лорда Хаоса обстановочка поскучнее =)