Это не хитрые, это скорее читерские, или инсайдерские. Это почти как прийти и сломать оппоненту пальцы что бы он не смог управлять кораблем. Стоить разделять понятия (хитрость, подлость, смекалка) на те которые работают внутри игры и вне игры. Если что то вне игры влияет на игровой процесс, то это увы хреного.
Еще интересен тот факт, то на втором видео на 7-8 минуте когда автор в начале запустил стрипмайнер, а потом остановил и перешол к обсуждению как что делать с рудой из трюма.
Не могу понять почему он их остановил. Он мог оставить их, и продолжить объснять. Складывается впечатление что именно вот этот процесс добычи велдьдемарта (или как его там) автору уже не важен, т.е. это копейки для него. Так? Просто интересно. Ведь говорить можно одно, а по факту майнинг это задроство до посинения.
Во втором видео, где то на 1:50 халк варпает сквозь базовую станцию. Вот при всей экономической серьезности игры, данный факт как серпом по яйцам. Ну раз делаете вы эмулятор жизни, ну так сделайте этого по законам физики.
Если честно, первое время было очень трудно — плохо понимал команду, задания вызывали ужас, но я работал часов по 12-13 в день и ходил на работу на выходных — по 6-7 часов.
И как долго это продолжалось?
По поводу алгоритмов. Уже упоминалось что важно не само знание конкретные алгоритмов, а то как человек строит новые. Потому что при построении алгоритма важным шагом является учесть все исключительные и взаимосвязанные ситуации. Лучшее решение не всегда приемлемо, в силу тех исключений которое оно налагает. Когда вы проектируете систему вы строите алгоритм из алгоритмов, и учитываете множество исключительных и взаимосвязанный проблем. Притом алгоритм часто получается уникальным. Поэтому просто «знать его» не получится.
Вот мне интересно, «мы» сейчас находимся в состоянии обсуждения некоторого редизайна нашей системы и мы занимаемся тем, что
1. пытаемся проговорить вариант поведения системы, с учетом проблем из п.2
2. смотрим что не решает предложенный алгоритм и переходим к п.1
Я думаю мы не блещем знаниями алгоритмов. Вот если взять нас, и заменить на тех, кто блещет ими (aka facebook), интересно, что будет:
1. Изменится ли общий процесс принятие решения (проектирования)
2. Будет ли изменения во времени.
Описанное выше это вот IQ(алгоритмика) или опыт(адаптация ранее полученных решений).
3 из 3-х где я работал используют SVN. И я не думаю что доживу до века когда git будет повсеместно использоваться в коммерческих фирмах.
Когда я выкладывал проект, я задумался о git, мол «дайка попробую», потом увидел что там нет понятие ревизия, на которой я привык основывать версию. Погуглил, как люди делают автоверсионирование. Ничего толкового не нашел. Понял, что пока не готов.
Это же не именованные пайпы. Простите не понимаю. Может у вас есть пример. Потому что если это не будет громоздко и решит проблему с сигналами, вот это как раз то что я с радостью добавлю, как минимум для себя.
В предложенном шаблоне я вижу один проект. Меня интересует, что будет выполнять роль общего «солюшена» или «воркспейса» при добавлении зависимого проекта.
Этот проект как раз и нацелен быть корневым. Но опять таки, это не ключ от всех дверей, и все проблемы решить он не может.
Простите но это плохая практика делать билд с локальными изменениями. У нас в один прекрасный момент случился такой билд, и так случилось, что вот именно его признали стабильным и отдали в публичное тестирование. Теперь мы каждый раз вздрагиваем когда нам нужно отдать тот билд. Потому что ни кто не знает, какие локальные изменения там были.
Как бы вы сформулировали цели своего проекта, решаемые задачи и для кого он?
Быстро начать писать прототип. Очень часто прототипы перерастают в рабочие проекты. В первую очередь для меня. Во вторую, для тех кто найдет его структуру полезной для себя. Это не ключ от всех дверей. Это не Boost.
Лицензия — Apache, BSD или MIT.
А сделать «Other Source License», а далее просто не упоминать о ней, нормально? В смысле так сойдет? Просто я плаваю в лицензиях, мне проще вообще не рассматривать этот кусок кода как лицензируемый.
Пофиксить обработчик сигналов, с сохранением текущей семантики, можно при помощи pipe. (В обработчике писать кусок данных в пайп, ждать завершения при помощи чтения. Можно заменить на signalfd в новых линуксах. Или тупо sigsuspend в выделенном потоке.)
В черновом варианте поста была строка: «Я не рассматриваю сложные механизмы останова, такие как посыл команды по сети, SMS или со спутника». Pipe это еще сложнее чем сеть. Работать с ними легко, работать правильно и отказоустойчивость сложно. К примеру если создать Pipe, повиснуть в блокирующем чтении, а потом снаружи удалить файл Pipe — ничего не случится. Вообще ничего. Поэтому я стараюсь не использовать пайпы.
В библиотеках приватные (чисто технические, не торчащие наружу) заголовки по возможности лучше прятать в src/
На счет этого у меня еще не сформировано мнение. Но я не люблю *.h и *.cpp файлы держать в перемешку. Но вот идея про то, что в include должны быть публичные хедеры заставляет задуматься.
А как этот шаблон продолжать наполнять «мясом», то есть библиотеками, содержащими фактический код, а не инфраструктурную обвязку?
Вам рассказывать как программировать? Я не встречал библиотеки которыми можно пользоваться на уровне
глупостьтолстые кошельки и желание реально поиграть aka русская рулетка?Не могу понять почему он их остановил. Он мог оставить их, и продолжить объснять. Складывается впечатление что именно вот этот процесс добычи велдьдемарта (или как его там) автору уже не важен, т.е. это копейки для него. Так? Просто интересно. Ведь говорить можно одно, а по факту майнинг это задроство до посинения.
И как долго это продолжалось?
По поводу алгоритмов. Уже упоминалось что важно не само знание конкретные алгоритмов, а то как человек строит новые. Потому что при построении алгоритма важным шагом является учесть все исключительные и взаимосвязанные ситуации. Лучшее решение не всегда приемлемо, в силу тех исключений которое оно налагает. Когда вы проектируете систему вы строите алгоритм из алгоритмов, и учитываете множество исключительных и взаимосвязанный проблем. Притом алгоритм часто получается уникальным. Поэтому просто «знать его» не получится.
Вот мне интересно, «мы» сейчас находимся в состоянии обсуждения некоторого редизайна нашей системы и мы занимаемся тем, что
1. пытаемся проговорить вариант поведения системы, с учетом проблем из п.2
2. смотрим что не решает предложенный алгоритм и переходим к п.1
Я думаю мы не блещем знаниями алгоритмов. Вот если взять нас, и заменить на тех, кто блещет ими (aka facebook), интересно, что будет:
1. Изменится ли общий процесс принятие решения (проектирования)
2. Будет ли изменения во времени.
Описанное выше это вот IQ(алгоритмика) или опыт(адаптация ранее полученных решений).
Когда я выкладывал проект, я задумался о git, мол «дайка попробую», потом увидел что там нет понятие ревизия, на которой я привык основывать версию. Погуглил, как люди делают автоверсионирование. Ничего толкового не нашел. Понял, что пока не готов.
Этот проект как раз и нацелен быть корневым. Но опять таки, это не ключ от всех дверей, и все проблемы решить он не может.
А сделать «Other Source License», а далее просто не упоминать о ней, нормально? В смысле так сойдет? Просто я плаваю в лицензиях, мне проще вообще не рассматривать этот кусок кода как лицензируемый.
В черновом варианте поста была строка: «Я не рассматриваю сложные механизмы останова, такие как посыл команды по сети, SMS или со спутника». Pipe это еще сложнее чем сеть. Работать с ними легко, работать правильно и отказоустойчивость сложно. К примеру если создать Pipe, повиснуть в блокирующем чтении, а потом снаружи удалить файл Pipe — ничего не случится. Вообще ничего. Поэтому я стараюсь не использовать пайпы.
На счет этого у меня еще не сформировано мнение. Но я не люблю *.h и *.cpp файлы держать в перемешку. Но вот идея про то, что в include должны быть публичные хедеры заставляет задуматься.
Вам рассказывать как программировать? Я не встречал библиотеки которыми можно пользоваться на уровне