Deerenaros

Эм, наши глаза видят не то, чтобы двумерно, вовсе не так всё, совсем не так. Они видят отображение трёхмерного пространства светом на "плоскость" неправильной формы, каждый из них, проецируемое с помощью линзы. На самом деле, это важное свойство, так как иначе мы видели бы лишь интенсивность света вокруг, возможно формы, но никак не FullHD картинку. Но это ещё не всё! Это видят глаза, каждый по отдельности, однако чуть дальше нейроны уже оперируют формами, линиями, заливками. Это очень важно, пока сигнал добирается до коры степень абстракций восходит с контраста, линий и форм до цветоощущений, объектов и их имён. Это не менее важно, так глаза один из необходимых условий для полноценного пространственного ориентирования. Я это всё к тому, что мы пространство преспокойно себе воспринимаем в трёх плоскостях. Даже не в двух с половиной, как принято считать, а в настоящих, полноценных трёх плоскостях. Другое дело, что многие в себе эту способность не развивают никак, ибо незачем, да и определённые ограничения всё-таки есть, всё таки видим мы только одну сторону, а не на сквозь. Вообще говоря, если углубляться в терминологию, тогда получается мы видим в трёх с половиной плоскостях. Интересно что это? Цвет? Чем не отдельная ось? Как минимум часть её. Но это уже извращения пошли, правда.

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

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

В любом случае, на этом нет смысла очень сильно зацикливаться. Часто мешает, а толку нуль. Да и собственное представление нередко сложно объяснить другому человеку, начинаются всякие кубы, размазывания и прочая ересь. Конечно, это не является никаким образом четвёртым измерением, это что называется, изображение проекции четырёх измерений на три или даже два. Ничего плохого в этом нет, но просто знать стоит.

Когда речь идёт об обработке удалённых ресурсов критически важным становится стабильность и качество соединения, его производительность, а также производительность удалённых ресурсов. Если реализовать на Си максимально эффективный парсер сайта, который будет жевать его, допустим, за 1мс и точно такой же на каком-нибудь жирнющем пайтоне, у которого на обработку уйдёт, допустим, 15мс, очевидно эти числа ничто по сравнению со временем, которое будет затрачено на подключению и загрузку требуемого документа: 100мс на подключение, 1мб/10мбпс, итого 200мс только на то, чтобы получить документ, который может ещё с ошибками приехать или не не приехать вовсе, а удалённому серверу ещё и время потребуется, чтобы его обработать.

Итого важным становиться максимально асинхронная работа с загрузкой документа, а его обработка может занимать столько же, сколько идёт загрузка, ибо оная является узким горлом быстрее которого обработать не получится. Некоторым выходом может быть запуск параллельных процессов (потоков) на различные ресурсы, но злоупотреблять этим не стоит, так как ваш канал не резиновый и качество соединения может во много раз упасть, да и у системы есть серьёзные ограничения на количество одновременных соединений.

Если нельзя, но очень хочется, то можно. Для 4к супер-критичным является пропускная способность памяти, ибо шейдеры всегда можно выключить, а геометрию - упростить. А вот для 4к надо как минимум 20 гигабит просто на то, чтобы отобразить пиксели на экране. А ведь кроме этого надо и текстуры загрузить, и посчитать, и снова положить, и несколько шейдеров. По правде говоря, low сегмент искусственно ограничен в производительности - память это легко регулируемое горло, практически не поддающееся какому-либо преодолению, ибо гонится она ужасно.

Про SLI многие уже сказали - требуется поддержка от игр, да и качество её оставляет желать лучшего. Но здесь супер-топ и перфоманс нужен просто максимально возможный. В крайнем случае одну карту можно отправить считать физику. Алсо, 1080Ti возможно тоже будет ничего так, ну и по стоимости на порядок дешевле, конечно. По характеристикам 1080 примерно тоже самое, что и Titan.

Я бы пошёл ва-банк и брал бы AMD. Ну, правда через пару месяцев. Всё таки, мне интересна именно VEGA, а то что есть сейчас... Даже не дешевле, внезапно. Ну а так, у nVidia есть множество плюшек софтварных, да и карточки технологически... Интересные, супер-скаляр и всё такое. Да и сама по себе компания годная, даже без серьёзной конкуренции двигает область вперёд, в отличии от Intel, которая совсем с ума сошла.

Что. За. Диск?

smartctl пишет ошибки, но не всегда они адекватны. Хотя в подавляющем большинстве стоит на них обращать внимание. Если вместе с ошибками S.M.A.R.T. диск проявляет нестабильность, значит ждём приказов долго жить. Если нет, то внимательно читаем данные, идём к вендору и смотрим особенности реализации. Вообще, никакой критерий ещё не достиг своего дна. Что до ошибок, то они могут быть по разным причинам (питание, особенности прошивки, глупость контроллера), попробуйте записать диск полностью нулями (рандомом), а потом отформатируйте.

vim+javac

С моей колокольни я вижу бред. На самом деле RSA не используется для прямого шифрования ровно по двум причинам.

Дорого. Дороговизна обусловлена высокой стоимостью операций. Взятие по модулю и возведение в степень - не самые простые операции для CPU, сложнее (из примитивных) разве что деление. К тому же, используя самые эффективные алгоритмы, сложность шифрования где-то O(n log(n)), возможно даже выше, но даже так на огромных данных логарифм портит всю малину. Как следствие - низкая производительность. Тут даже специализированные схемы не очень помогает, ибо их сложность слишком большая и стоимость производства - также высокая. Можно вспомнить про кредитные карты, которые есть почти у всех, но их производительность очень низкая, просто её хватает, но едва.

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

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

Например? Не забываем про w3c. Возможно стоит научиться пользоваться гуглом?

tl;dr В порядке убывания релевантности: Любой, Unity (JS/C#), Web (PHP/JS), Other (Python/Lua/C++/...)

Программист геймплея... Программист геймплея! Геймплея, Карл!

Что за? Что это за зверь вообще? Не могу знать, не могу понять.

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

Конечно, можно делать на от@$%, однако это не путь, это так... Хлеб. Возможно. Но мы вообще не об этом сейчас. Тут надо сказать, что разработка игр очень хорошо распределена по ролям. Именно что благодаря своей монструозности становится возможным элементарное делегирование задач. Но и тут возникают большие сложности.

Есть два типа людей. Одни просто берут и е#$%. Они не думают о потраченном времени, не думают о структурах данных, просто берут. И делают. Классно быть ими, я, к сожалению, не такой. Однако с обратной стороны игры выходят багованными, ужасно медленными (2D платформер официально требующий 2Гб RAM и два ядра, WUT?), но зато проработанный геймплей увлекает и затягивает. А есть люди, которые сначала десять лет думают, а потом пишут одну строчку кода, которая максимально быстрая и эффективная и на ней держится половина всей игры... Однако таких строк надо пара тысяч, а со временем возникает такая лапша зависимостей, которая убивает любое масштабирование. Конечно, надо делать как-то средне.

Но в тоже время, в таких заголовках как World of Warcraft уже чувствуется не только эпичность и масштабность, но и почти неограниченные ресурсы: всё равно существует пачка багов, которые не закрываются годами. Про них все всё знают, в Интернетах по дцать вариантов обойти оные, но... Они есть!

К чему я это? К тому, что независимо от инструмента можно сделать игру. Независимо, хоть на голом C# с managed directx (terraria), хоть на жирнющем python (eve), хоть на хардкорных плюсах (doom), в любом случае результат зависит от профессионализма.

А вам же... Скорее всего хочется в идеи. Но идеи... Они ни#$% не стоят. И уж работая на дядю последнее, что вам придётся - это придумывать геймплей. Причём в небольших компаниях придумывать-то в общем-то нечего, а экономические f2p игры и вовсе прорабатываются отдельными гейм-дизайнерами во всевозможных екселях.

И единственный выход, вроде бы, делать всё самому (или небольшой кучкой людей), однако раз уж этот вопрос был задан, значит вряд ли у вас что-то получится. Хотя, как знать. Удачи.

Двигайся вперёд не смотря ни на что. Сам не сходился с начальством, не сходился и с коллективом. Бывали и задержки на ЗП, бывало и кидали, бывало и работа просто не подходила, бывало и выкидывали, так как сам не подхожу им. Поиск как работы, так и работника, особенно в IT это очень и очень сложное дело. Специфика работы у каждого своя, где-то люди работают с круглыми суммами и любая оплошность может дорого стоит, а где-то работа идёт с тяжким матаном в области обработки сигналов. Где-то требуется отличное знание устройства ядра Linux, а где-то придётся работать в ужасном стрессе. А где-то всё и сразу, но компенсация соответствующая.

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

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

И да, пока не работаете на дядю работайте над собой. Очень важно не просиживать штаны, а развиваться.

Ну в общем-то ответов много. Могу кое-что добавить от себя.

Во-первых, голова не бесконечна во всех смыслах. Запихнуть в неё больше чем 10 объектов одновременно вряд ли получится, у многих начинаются огромные проблемы уже с 5. Лично я испытываю ДИКУЮ больше если собственный код становится больше чем большой. Для меня это где-то 15~20 сущностей, причём чем сильнее они связаны, тем сложнее они даются, так как становится сложно абстрагироваться. Что примечательно, при работе с чужим кодом таких проблем практически нет, ну у меня по крайне менее. Всё дело в том, что чужой код изначально воспринимается чёрным ящиком, поэтому если он не представляет из себя дикую лапшу, аккуратная работа с ним с минимальным вмешательством в проект получается легко.

Во-вторых, не стоит делать код пушистым. Однообразность воспринимается лучше. Массивы некоторых объектов надо называть $названием_объекта + 's'. Классы с большой буквы, любой объект стоит называть так же, как класс, но с маленькой буквы. Конечно, если семантически прям просится по другому, то стоит правило нарушить, но в общем случае никаких выдумок не надо. Временная строка - str, временное число - tmp, временный объект - obj. И пробелов не жалей, внутри файла разделяй разные структуры двумя-тремя пробелами, стоит обособлять регионы, например, "глобальные" функции наверху, по середине структуры, потом классы. В C# есть #region.

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

В-четвёртых, внутри монолита также надо делать максимально растянуто, никаких супер-синглетонов бдящие за всем и вся. Равно как и с микросервисами, внутренние объекты должны иметь минимум точек входа. Они должны быть просты и понятны. Если какой-то класс выполняет слишком много задач, часть из них надо делегировать другим классам, возможно новым. Это по сути цикломатическая сложность, о которой упомянул Ivan Sokolov, но мне не нравится эта формальность. Да и некоторые вещи сложно формализовать ребром на графе.

В-пятых, иерархия должна быть логически правильной, наивной, без выпендрёжа. Тоже самое, что и в третьем, плоское лучше объёмного.
Плохо:

Лучше:

Пример немного утрирован, но суть, навроде, ясна. Не надо наследовать всё и вся от чего угодно, если есть возможность включить внутрь - включай. Всё остальное от лукавого и только в крайних случаях.

В-шестых, используй UML, mind maps, блокнот и таск менеджеры. Эти инструменты словно манна небесная спасают дедлайны от полного уничтожения. Хотя UML спорен, им очень удобно следить за структурой проекта, представлять картину с высока, рисовать его стоит самому, учитывая неявные связи и убирая рудиментарные. Mind maps помогут собрать мысли в кучу. Блокнот банально запишит то, что постоянно забывается. Таск менеджеры сформируют привычный график, отобразят прогресс, помогут фокусироваться на текущих задачах, не растекаясь по проекту.

В-седьмых, изучи декларативное программирование. Шикарная вещь, которая позволяет сконцентрироваться на задаче, а не на решении. Из коробки в функциональных (erlang) и логических (prolog) языках, однако многие элементы существуют и в монстрах вроде C#/Java, Python, особенно JavaScript. Насчёт Go не знаю, но на первый взгляд весьма декларативный.

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

Ещё пара абзацев. Ну про вредные советы: методы надо делать ровно такими, какие они должны быть. 20 строк - это что-то вроде лакмусовой бумажки, однако это лишь один из параметров. Очень часто требуется сделать громадную функцию для работы со сложным API или подробить много разных чисел в циклах. Поэтому ориентироваться на это плохая идея. Равно как и папки-подпапки-подпапками погоняемы, максимум - два уровня в чрезвычайно сложных проектах. Иначе будет очень сложно ориентироваться. Ещё происходит странный возврат к комментариям. На мой взгляд, если это не продаваемая за большие деньги библиотека - нах*й надо. Документация в комментариях - рудимент кода, он нигде не используется, зато требует поддержки, на что приходится распылять внимание. Если нет условного рефлекса править комментарий после кода - выбрасывайте и не жалейте. Везде! Без исключений. Ещё есть много "архитектурных" паттернов. Снова вред, если вы не работаете в Google, где вашу зарплату надо оправдать умными словами. Самый эффективный способ - программировать наивно. Чем проще для вас сейчас, тем лучше для вас потом. Если думаете больше десяти минут - плохо думаете... Но об этом позже. Паттерны это некая систематизация неких знаний, причём совершенно не понимаю, зачем её вообще сделали. Да, архитектура в некотором роде нужна, но постоянно искать какой паттерн здесь надо использовать, если это не проект на 100500 лет вперёд - нельзя. Почти всегда будет дешевле в случае неуспеха отрефакторить всё и вся, чем переписывать с нуля или тратить месяцы на продумывание архитектуры... В которой также могут быть ошибки.

И последнее. Отдыхайте. Если чувствуете, что задыхайтесь - пройдитесь, подышите. Если чувствуете, что мозги плывут - отвлекитесь, подумайте о другом. 8 часов в день для программиста - это дикость, но это реальность. Для разных людей наибольшая эффективность поддерживается где-то 3~6 часов, причём некоторым требуются перерывы каждые пол часа, другому хватит обеденного перерыва, а третьему вообще нельзя сегодня никаких отвлекающих факторов, ибо "волна". На самом деле, человек существо динамичное, так что будут разные дни. Но если не получается сейчас - не бесите самого себя. Отдохните, перекусите, пробежитесь, покурите, проверьте почту, послушайте музыку, почитайте статью. Не тратьте время бездарно и, что интересно, проблемы будут решаться, усилия будут прикладываться аналогичные, но вот ощущения от работы станут совершенно другими.

Так-с. Дайте-ка подумать. Гравитация, сильное взаимодействие, слабое взаимодействие, третий закон Ньютона, преобразования Лоренца, квантовая неопределённость, стандартная модель... Эм, не знаю в общем никаких физических законов, которые не позволили бы изучать какую-либо технологию в процессе работы с ней. Даже более того, это единственный эффективный способ начать её изучать.

Си++, C#, Java, Python, JavaScript... Да как вы надоели с этой хренью, честно. Никто не удивится, если ты понятия не имеешь, что такое рефлексия, зачем нужны лямбда-функции, почему так много споров о сборщике мусора. И тем более такие мелочи, как порядок инициализации или особенности области видимости в VC++98. Вопрос не то, чтобы плохой. Он глупый и неправильный. Unity это про иерархию объектов на сцене, их менеджемент, операции с матрицами, работа с графикой в реальном времени, однако, в основном - это про то, как перетащить объект из ассетов на сцену и поколдовать над его свойствами. Unity это про стейт-машины и формальную логику (например, предикаты), UI/UX и оптимальное программирование, но в большей степени это артисты рисующие модельки, текстуры и спрайты, озвучивающие и анимирующие их. Наконец, надо разбираться в предметной области в сфере, по которой создаётся игра, но для хэлоу ворлдов хватит и восьмого класса.

Так что хватит загрязнять тостер с этой фигнёй. Тут очень слабое ранжирование хороших вопросов в отличии от stackoverflow, таких вопросов уже тьма задавали. Хватит!