Comments 21
Хидео Кодзима
Самый известный геймдизайнер в мире
А почему не Джон Ромеро, Клифф Блежински или Виктор Антонов? ))
Это сказал Джефф Кили:
А я думал, это сказал Хидео Кодзима ))
Погуглил сейчас, это оказался создатель чего-то приставочного под названием Metal Gear. (Я сначала решил, это тот чел, который делал Сайлент Хилл — из всех японцев знаю только его и Миямото, который придумал Марио).
А я думал, это сказал Хидео Кодзима ))
Кодзима – это японский геймдизайнер, а не отечественный IT-блогер.
Я не являюсь ярым фанатом Кодзимы и не отношусь к числу тех, кому посчастливилось поиграть в оригинальный Metal Gear на компьютерах Yamaha YIS-503IIIR (КУВТ2). Также мне не удалось сыграть в NES-порт на оригинальном железе, т.к. во время популярности приставки Dendy картридж с этой игрой был дефицитным товаром.
Но я очень хорошо помню время, когда вышел первый Metal Gear Solid. Чтобы не быть голословным предлагаю вам ознакомится с тем, что писали об игре и ее создателе в отечественном игрожуре:
Metal Gear Solid в отечественном игрожуре
Я не люблю мем «Кодзима — гений», который придумали отечественные блогеры. На мой взгляд, этот мем обесценивает вклад Кодзимы в историю видеоигровой индустрии и заставляет людей думать о его творчестве как о чем-то попсовом. Но я не отрицаю того, что он гений.
Мем «Кодзима — гений» в действии
Вообще, если меня спросят о том, кто для меня величайший геймдизайнер в истории, то я однозначно отвечу - Йосики Окамото.
В чем-то вы, действительно, правы. Миф о гениальном и всемирно известном геймдизайнере является продуктом различных медиа. Раньше создавать подобные мифы могли лишь крупные видеоигровые компании, имеющие большие PR-службы и влияние на прессу. В наше же время, благодаря социальным сетям и блогосфере, этим могут заниматься и компании поменьше.
Вполне очевидно мне кажется проблема. Функционал который ранее выполнялся на слабых ПК сейчас требует солидных ресурсов. Я помню как на учебе обходился нетбуком, вроде asus eee pc 900. с той же почтой - the bat прекрасно работала. А сейчас на нём даже попытка открыть сайт в браузере вызовет дикое торможение.
Win32/64 приложения заменились на брузер как тонкий клиент и это привело к существенному росту требований к ПК. Даже при выполнении задач которые ресурсов не требуют от слова совсем (чтение книги, например).
Яркий пример сайт sberauto.com
Открываете главную, клик по синей кнопке "к поиску" и все... виснет наглухо нагружая процессор, хоть на андроиде, хоть на свежем core i7
Как владея такими ресурсами, людскими и материальными, сбер умудрился выпустить в продакшен этот отстой - я не понимаю.
Вангую - ничего не изменится. Наоборот- появится куча следующих фраймворков поверх существующих. И так по нарастающей будет и дальше. И нас через несколько лет даже и беспокоить не будет, что простая html-страничка гигабайт весить будет.
Ещё хуже будет. Фреймворки покажутся детским садом, когда ИИ прочно займёт свое место в конвеере разработки ПО. Ладно ещё использование API к большим моделям в рантайме - пусть оператору приложения приходят счета, это не проблемы пользователя (и да, в "перекладывание" костов на конечного юзера я не верю, ибо на ИТ продукты никто прайс по формуле расходы + маржа не формирует).
Но вот написание клиентского кода большими моделями - это уже будет больно и пользователю тоже. Пока вывод всяких копайлотов ревьювится кодером, но, вангую, год-два и мы придём к генерации блекбоксоподобных целостных модулей, которые решают таск из беклога целиком, и их корректность будет проверяться лишь юнит-тестами, которые тоже эта же штуковина и написала (ибо, зачем вообще лезть вовнутрь, если оно работает, если можно этот класс задач решать парой аналитик-тестировщик, где аналитик пишет ТЗ, а тестировщик уточняет юнит-тесты за машиной, вообще не тратя время программиста).
Наверно всё изменится лишь тогда, когда браузеры станут не нужны. В том виде, в котором сейчас, имею ввиду. Хотяаааа, там же и nodejs имеется. Значит и операционки должны видоизмениться полностью. Этакие голографические 3d-лица из фантастики, говорящие с пользователем и исполняющие все его распоряжения. Вот тогда и наступит крах js :)
Да "ничего не ново под луной".
Винда в своё время тоже с каждой версией жирнела и тормозила - вспомним висту. Сейчас майки пытаются этим процессом управлять. Причина - на винде можно и на старой работать (да, это Windows XP), тем более если компьютер "не тянет" (нет продаж нового). Появляются реальные альтернативы (в том числе спонсируемые правительствами и т.п.), когда можно вообще уйти с винды (продажи падают). Вот майки и зашевелились.
Здесь будет также: сайт - это же и рекламная площадка. Если площадка не работает, то кто-то теряет деньги. Если для остановки потери денег нужно джунов убрать вместе с навороченным фреймворком - это будут потихоньку делать.
Тут есть проблема, что, условно, у фанудера, и C-level могут быть предпоследние и последние айфоны, у которых как раз производительность исполнения js запредельная. Соответственно, у них тормозить не будет. У топ-платящих юзеров в зависимости от ниши могут быть такие же девайсы. Между напилить ещё фич для топ 5% платящих юзеров и довести до ума для топ 50% юзеров с самыми медленными девайсами невидимая рука рынка вполне может проголосовать за первое
Одна из самых серьезных проблем в разработке программных средств — их тучность, или раздутость. Программы просто становятся слишком большими. Это может быть связано с неразумным выбором функций, но чаще всего становится следствием плохой архитектуры. Популярное средство повторного использования кода — наследование, но его работа оставляет желать лучшего, поэтому вместо него зачастую применяются копирование и вставка кода.
Не скажу насчет фронта, на беке (java) с которым я работал много где, обычно главная проблема - это неоправданное переусложнение логики.
Например - использование мудреной, в особо запущенных случаях самописной, кодогенерации, когда тебе для каких-то простых доработок приходится изучать какой-то легаси формат конфигурационных файлов, писать на них новые конфигурации, запускать кодогенерацию и молиться что-бы сборка отработала правильно и ты получил в итоге то что хотел. Это пример из реального проекта, там я помню больше бился с проблемами этого инструмента, который по замыслу авторов должен был облегчить жизнь разработчиков, а по факту добавлял много лютой боли на ровном месте, там где было намного проще и быстрее написать обычный типовой код руками.
Другая тема - использование паттернов там где они не нужны. В том-же проекте, помню использовали стратегии, которые по факту заменяли собой два-три ифа в сервисах, но ради этой замены приходилось городить разлапистую иерархию интерфейсов и их реализаций, которая выглядела как лабиринт из кода, в котором было довольно сложно разобраться и в котором было сложно искать ошибки, потому что обычно было неясно какой кусок кода в каком случае будет исполняться, это зависело от массы разных вводных и по факту без прогона отладчиком было не обойтись. При этом запуск всего этого монстра был тоже нетривиальной задачей, локально окружение надо было долго и кропотливо настраивать что-бы сервер просто стартовал корректно, и потом еще долго надо было пытаться выполнить те действия, которые дергали нужные сервисы.. В общем это был натуральный ад разработчика из-за которого я чуть вообще не выгорел к черту..
Сейчас вот, попроще, но тоже наткнулся на больной проект - все запросы к БД за каким-то чертом запихали в конфигурационные файлы. Сами запросы с активным использованием шаблонов, так что данные выгребаются из базы после того как код по хитрому алгоритму преобразует запрос выдернутый из конфигов.. В итоге все работает криво и с массой трудноотлаживаемых проблем, при том что написать все это на стандартных крудах было бы вполне легко и проект был бы простым, понятным и не содержал такой лютый набор багов.
В общем на беке все зачатую выглядит как "горе от ума" - переусложнение на ровном месте, которое не нужно было совершенно.
вот да.
плюс - отсутствие связи между уровнями абстракции, когда есть два низкоуровневых АПИ (например - получение кадров из камеры в буфер в памяти и отправка буфера в сокет), написанных так, что невозможно передать данные между ними напрямую (т.е. чтобы это был один и тот же буфер в памяти), а только через два копирования (из буфера1 в структуру а потом из структуры - в буфер2) на ровном месте. Или только при помощи сериализации-десериализации через второй-третий язык высокого уровня (складывая в структуры питона или джаваскрипта), как будто это не одно и то же приложение а какой-то набор микросервисов %)
Да и микросервисы это зачастую отдельный круг ада. Вроде по идее они должны упрощать отдельные темы, но на практике получается что для реализации какой-либо ерундовой фичи, которую на классическом монолите, без выпендрежа написанном, ты за день запилишь, на микросервисах будешь месяц долбаться создавая в каждом сервисе кучу таблиц, АПИ между сервисами, всякие там распределенные транзакции и проч. подобное.
Безкультурие во всем. В датах хаос - ведь память ничего не стоит. Сайты жирные - скорость ведь всё больше и больше. Никакой документации нигде - так и софты не живут долго итд. И так по спирали.
Его имя затмило даже таких известных геймдизайнеров как: Сигэру Миямото, Йосики Окамото, Алексей Пажитнов, Джон Ромеро, Эд Бун и Джон Тобиас.
В списке нет Джордана Мехнера!!!
И ещё когда пытаются в локальной разработке запихнуть в простое grud приложение питон, php, postgres и браузер и потом все это тормозит и глючит у юзеров просто потому что это модно или хочется прикоснуться к "современным продвинутым технологиям" то становится очевидно что весь это огород нужен лишь для пополнения опыта этих разработчиков а реально система не работает хорошо. Потом этих разрабов уже нет в компании, а проблемы есть.
Высказывания трех известных людей о проблемах современной разработки ПО