P.S. Я молчу про кучу мелких удобностей, к которым привыкаешь, а потом после них Android ощущается как "они забыли добавить мне половину телефона". Например, если сильно нажать на клавиатуру, она превращается в тачпад и можно точно установить курсор в тексте, ужасно удобно, не понимаю, почему андроиды так не могут.
В эпл сильно ощущается "они решили за меня и это даже не настроить". В андроиде клавиатура — это отдельное пользовательское приложение, при необходимости оно может сделать что угодно (например, свайп-клавиатура изначально появилась именно в андроидах, а эпл несколько лет считал, что свайп не нужен, как и кастомные клавиатуры.)
P.P.S. А еще мне не сильно хочется платить деньги людям за плагиат и отсутствие хоть каких-нибудь ресечей и введение новых технологий,
Забавно, но своей гибкостью андроид позволяет делать всякие нестандартные штуки и потому он является "инкубатором" для идей. Можно почитать, как для ios пытаются делать что-то выходящее за рамки — получается боль. пример.
А что зеркала? Они всё равно оставляют "мёртвые зоны" — например, по бокам или ровно за спиной. Во время поездки я хочу получать максимум информации об происходящем вокруг. В наших условиях, когда вместо отдельных велодорожек в лучшем случае есть обочина дороги или пешеходная дорожка, ездить на велосипеде довольно опасно и этот риск надо снижать всеми доступными способами.
Пробовал ездить в наушниках — не понравилось. Машины и людей вроде бы слышно, но на самом деле мелкие детали теряются. Например, если рядом со мной едет велосипедист, я по звукам цепи/шелесту покрышек хорошо слышу где он. Если он останет/решит меня обогнать, для меня это не будет неожиданностью. Если ехать компанией, то такая слышимость просто must have. В наушниках (даже без музыки) пространство позади превращается в "чёрный ящик" и приходится регулярно вертеть головой. Аналогично с машинами/пешеходами — без наушников их можно услышать на бОльшем расстоянии и эта информация может пригодиться.
Спасибо! Мне и в голову не приходило, что в MPC можно так легко взять и добавить свои шейдеры. Это же какой простор для велосипедостроения экспериментов с алгоритмами цветокоррекции/повышения резкости/убирания артефактов сжатия!
Можно какой-нибудь пример? Я не понял, как особенности пролога помогут писать квесты.
Вот я могу императивно написать что-то типа:
quest.isAvailable = player.level in 10..20 && questsFinished(a, b, c)
quest.reward += Gold(100 + 50 * player.level + 10 * sigmoid(player.karma))
if questA.isFinished && questA.isPlayerChosenSmth
quest.reward += Weapon.random(sword, level=player.level)
Что изменится при появлении пролога?
Мне кажется, что примитивность квестов — просто косяк тех, кто их придумывал. В том же ведьмаке практически все квесты можно по-разному пройти c разным результатом и с разным порядком прохождения самих квестов. Мне кажется, такой подход требует большего бюджета на разработку и отладку квестов, но ничего принципиально нового не содержит.
Вот за это я не люблю windows. Практически на всех ноутбуках предустановленна винда, но если копнуть чуть поглубже — выясняется, что она кастрирована и многих приятных плюшек в ней не хватает, хотя с точки зрения железа ограничений не должно быть.
Предварительно метки можно расставить скриптом, но потом это все равно должен вычитать человек.
Да не надо ничего вычитывать, если где-то и ошибётся на предложение/параграф, ничего страшного не произойдёт. Человек же читает только одну версию, а в другую только подглядывает, если на что-то реально сложное наткнётся. (По крайней мере, я себе это так представляю)
P.S. Я могу написать такой скрипт, но я хочу чтобы он был реально полезным и им пользовались больше чем полтора анонимуса.
В идеале вижу это как сайт или бот для телеграмма.
P.P.S Хм, бота я и сам могу написать. В общем, если кто хочет поучаствовать, пишите в личку.
Факт: мои близорукие глаза быстро устают от чтения с экрана планшета/смартфона, и долго не устают от читалки.
Забавно, но у меня наоборот. И от книг глаза тоже устают. У читалки постоянные проблемы с освещением, на телефоне можно практически любую яркость выбрать. Ну и fullhd экран на телефоне это сказка — пиксели разве что с лупой разглядеть можно.
Напомнило реализацию в человеке-пауке: https://habr.com/post/424827. Но в форзе, хоть и сделано практически то же самое, результат выглядит на порядок симпатичнее и проработаннее.
Имхо, в будущем такой эффект будет использоваться во всех играх, где есть окна. Для окон вдали, а таких окон на сцене большинство, этот способ изумительно подходит. Для окон вблизи при стремлении к реализму можно рисовать честный объёмный интерьер.
Я не говорю, что всё решит тупо уплата налогов. Я говорю, что неуплата ничего не решит, а ещё и усугубит.
Да ничего она не усугубит. Если куча косвенных налогов типа НДС, акцизов, пошлин на ввоз автомобилей и просто грабежа в виде внезапных падений рубля. От них практически никуда не деться. Вдобавок, государство имеет доход от продажи природных ресурсов типа нефти/газа/металлов/леса. Если человек "сэкономил" деньги на явных налогах, он всё равно потратит их здесь (если он конечно, не недвижимость в Англии покупать собрался) и эти деньги останутся в экономике РФ.
Про бесплатные медицину/образование можно не рассказывать, львиная доля расходов идёт совсем не на них, да и по-факту для потребителя они всё равно получаются платными.
В блендере есть аналогичный node editor для шейдеров. Поначалу я думал, что это наглядно и удобно, но потом понял, что реализация сколько-нибудь сложной функции занимает кучу места и оказывается сложной для восприятия. Переиспользовать код тоже неудобно — приходится создавать подграфы и переключаться между ними.
Эта строчка легко читается, быстро печатается и занимает мало места: на экране без проблем поместится ещё 50-100 таких же. Если я захочу добавить зеркальное отражение — допишу ещё одну строчку.
А в нодах — выщеописанная функция уже содержит 5 операций и использует 5 переменных и одну константу. Т.е., в граф придётся добавить ещё 6 новых вершин и потом соединить их друг с другом и с пятью внешними вершинами. Это уже громоздко выглядит, не говоря уж о чём-то реально сложном.
Никакими культурными словами не выразить эту боль. Несколько замечательных примеров:
Едешь электричками А-...-Б-С, покупаешь билет А-С и обратно. (Кстати, билеты А-Б и А-С стоят одинаково.) Обратно по некоторым причинам пытаешься сесть сразу на Б — не пускают. Где логика? Я же меньше проеду. Приходится пользоваться телепортом покупать самый дешёвый билет, просто чтобы зайти на платформу.
Есть А-Б-...-С, на Б могут продать билет до С и обратно, а вот обратно до А — не могут. Не смотря на то, что билеты С-А и С-Б стоят одинаково, по билету "Б-С и обратно" тебя не выпустят в А (электрички вечером часто пропускают станцию Б и получается быстрее доехать до А и оттуда пешком дойти, чем ждать электричку, которая останавливается в Б). В итоге просто дольше стоишь в кассах и покупаешь билет отдельно для каждой поездки.
Есть такой закон в usability: Fitt's law
Вкратце — чем проще «целиться» курсором в элемент на экране — тем удобнее пользоваться интерфейсом. А если элемент находится вплотную к границе экрана — целится еще проще. И Apple исходила в том числе из этого закона при проектировании главного верхнего меню.
С точки зрения Fitt's law абсолютным идеалом является контекстное меню по ПКМ, которое вообще не требует двигать мышь для его открытия.
По упомянутому вами закону надо оценивать расстояние, делённое на размер кнопки. Тянуть мышку через пол-экрана неудобно. Если экранов несколько, я оказываюсь в ситуации, когда надо тянуться вдаль от окна к одинокой узкой по высоте кнопке, рискуя "проскочить" её и оказаться мышкой на другом экране. А если на нижнем экране приложение открыть в полноэкранный режим, то эта панелька скрывается, и чтобы она появилась, надо проявить изумительную точность прицеливания точно в верхние пиксели нижнего экрана.
Отсутствие дефолтного просмотрщика картинок, в котором можно было бы листать картинки.
Кстати, можно в finder выбрать картинку, нажать пробел и потом стрелочками переключаться. Фишка вроде прикольная, но и тут косяк — если в finder картинки отображаются не списком, а сеткой, то нажатие кнопки "вправо" доходит до самой правой картинки в строчке и на следующую строчку уже не прыгает.
Во времена Half-Life 1, когда начала использоваться эта технология, каждая вершина связывалась только с одной костью. В наши дни могут присоединяться даже к четырём костям, при этом каждой кости придаётся вес, от которого зависит степень влияния кости на вершину.
К сожалению, в РПГ играх по неизвестной мне причине части доспехов привязываются к нескольким костям сразу, из-за чего железный доспех крайне неестесственно растягивается или мнётся при каждом движении персонажа.
А что вас так сильно выбесило в макоси, если не секрет?
У меня получился довольно длинный список
Возможно, это мелочи и всё фиксится и настраивается, но дефолтное поведение мне точно не нравится:
Меню, которое прицеплено не к окну, а расположено вверху экрана. Если использовать несколько маленьких окошек, то к тому меню приходится далеко тянуться мышкой. Можно, конечно, сказать, что активное окно только одно, но если вы подключите второй экран, то вверху каждого экрана будет менюшка для своего приложения. Ещё получается крайне тупо, если на одном экране открыты два окна одной и той же программы.
Нет режима, который в винде называется "полноэкранным", тот который в макоси скрывает менюшки и панель с программами внизу, которые могут быть нужны.
Нет замечательной возможности развернуть два приложения на левую и правую половину экрана. (В винде и линуксе ставится win+стрелками, в макоси пришлось какое-то приложение ставить, но сочетания клавиш менее очевидные) Аналогично нет "прилипания" окон к сторонам. В итоге я крайне нерационально использую площадь экрана, тасуя по нему маленькие окошки.
Finder:
вверху нет панели, на которой можно было бы выбрать любую из вышестоящих папок. Вдобавок, в винде можно так прыгнуть на три папки вверх, что-то сделать, а потом нажатием кнопки "назад" прыгнуть обратно. Вариант с тыканьем три раза cmd+вверх неудобен, да и обратно вернуться тоже быстро не получится.
Так как полный путь не пишется, если есть места с похожей структурой папок, то их легко перепутать.
Finder создаёт скрытые файлики .DS_Store, которые при упаковке папок в архив или прочих штуках "внезапно" появляются.
Если переименовать файл со сменой типа файла, то вылазит окошко с вопросом типа "нет не надо" или "всё-таки переименовать", нажатие на enter вроде бы возвращает назад, и я не нашёл способа с помощью клавиатуры выбрать вариант, чтобы файл был переименован как я хочу. В идеале этот вопрос вообще должен отключаться, а на практике ответ приходится тыкать мышкой.
я не могу просто так взять и открыть консоль прямо из finder в нужной папке. (В линуксе это мегаудобно сделано, в винде достаточно в поисковике написать cmd.) Терминал открывается кажется, в папке Desktop, и оттуда приходится уныло переходить по папкам к нужной.
Нельзя настроить масштаб при отображении файлов. В винде можно, например, сделать фотографиям большие превьюшки, чтобы их влазило 4-5 штук по ширине экрана, и потом быстрой найту нужную.
перемещение файлов сделано не через ctrl+x, ctrl+v, а менее очевидным образом.
Стандартный софт. Не знаю, какой гений додумался назвать программу для работы с таблицами "Numbers", но попытки нагуглить, как в ней для float чисел сделать разделителем именно точку, а не запятую, ни к чему хорошему не привели. Там ещё какой-то софт есть с не менее феерическими названиями.
Терминал: (вернее, сам терминал не виноват, но в макоси по-дефолту так) вывод программ одного цвета. В линуксе из-коробки команды типа ls или grep дают красивый разноцветный вывод, который намного проще читать. В макосе терминал цвета рисовать тоже умеет (например, если зайти по ssh в линуксовый комп), но стандарные утилиты этим не очень пользуются.
Кажется, при обновлении питона (или ещё чего-то через brew) сталкивался с крайне тупой ситуацией — я не мог поставить софт, пока не обновлю ИЛИ не удалю XCode. Вот это "или" удивило меня больше всего. Впрочем, как и вообще какая-то зависимость от Xcode.
мягкие ссылки по работе больше похожи на ярлыки (ну или это были не ссылки), если перейти по ссылке и потом пойти по папкам вверх, то можно оказаться не в том месте, откуда пришёл.
Если на мышке есть доп кнопки, в винде/линуксе работают "из-коробки" и позволяют с удобством переключаться между вкладками в браузере или прыгать по коду в IDEA. В макоси по-дефолту они какую-то ненужную фигню делают. Да и вообще макось какая-то однокнопочная, правая кнопка мыши редко используется и приходится лезть в меню вверху экрана для простых операций типа создания папки.
Я не делаю особой разницы между запуском программы и её компиляцией в контексте выявления ошибок. Какая разница будут сыпаться ошибки при исполнении или при компиляции?
Разница огромна, если программа работает дольше времени компиляции или на удалённом компе. Очень печально осознавать, что обучаемая несколько часов нейронная сеть не была сохранена просто из за-того, что в какую-нибудь функцию передали не то количество параметров или ошиблись с их типом.
Причём может быть, что в одной ветке ветвления всё хорошо, а в другой — нет. И вроде бы работающая программа может оказаться не очень работающей, если что-то не совпало.
Рефакторить более-менее большой проект на питоне или на java/scala — тоже огромная разница. В статических языках та же IDEA хорошо справляется и можно совершенно свободно менять что хочется. Если не справляется — я узнаю об этом во время компиляции и тут же поправлю. С питоном среда разработки от тех же разработчиков справляет плохо и банальное переименование переменной/поля оставляет в различных местах "сюрпризы" на будущее.
В эпл сильно ощущается "они решили за меня и это даже не настроить". В андроиде клавиатура — это отдельное пользовательское приложение, при необходимости оно может сделать что угодно (например, свайп-клавиатура изначально появилась именно в андроидах, а эпл несколько лет считал, что свайп не нужен, как и кастомные клавиатуры.)
Забавно, но своей гибкостью андроид позволяет делать всякие нестандартные штуки и потому он является "инкубатором" для идей. Можно почитать, как для ios пытаются делать что-то выходящее за рамки — получается боль. пример.
А что зеркала? Они всё равно оставляют "мёртвые зоны" — например, по бокам или ровно за спиной. Во время поездки я хочу получать максимум информации об происходящем вокруг. В наших условиях, когда вместо отдельных велодорожек в лучшем случае есть обочина дороги или пешеходная дорожка, ездить на велосипеде довольно опасно и этот риск надо снижать всеми доступными способами.
Пробовал ездить в наушниках — не понравилось. Машины и людей вроде бы слышно, но на самом деле мелкие детали теряются. Например, если рядом со мной едет велосипедист, я по звукам цепи/шелесту покрышек хорошо слышу где он. Если он останет/решит меня обогнать, для меня это не будет неожиданностью. Если ехать компанией, то такая слышимость просто must have. В наушниках (даже без музыки) пространство позади превращается в "чёрный ящик" и приходится регулярно вертеть головой. Аналогично с машинами/пешеходами — без наушников их можно услышать на бОльшем расстоянии и эта информация может пригодиться.
Есть ещё s8. Взял его вместо сони — одним из критериев было наличие разъёма для наушников.
В моём случае помогало поставить минимальную громкость в наушниках и максимальную в телефоне.
Спасибо! Мне и в голову не приходило, что в MPC можно так легко взять и добавить свои шейдеры. Это же какой простор для
велосипедостроенияэкспериментов с алгоритмами цветокоррекции/повышения резкости/убирания артефактов сжатия!Можно какой-нибудь пример? Я не понял, как особенности пролога помогут писать квесты.
Вот я могу императивно написать что-то типа:
Что изменится при появлении пролога?
Мне кажется, что примитивность квестов — просто косяк тех, кто их придумывал. В том же ведьмаке практически все квесты можно по-разному пройти c разным результатом и с разным порядком прохождения самих квестов. Мне кажется, такой подход требует большего бюджета на разработку и отладку квестов, но ничего принципиально нового не содержит.
Вот за это я не люблю windows. Практически на всех ноутбуках предустановленна винда, но если копнуть чуть поглубже — выясняется, что она кастрирована и многих приятных плюшек в ней не хватает, хотя с точки зрения железа ограничений не должно быть.
Да не надо ничего вычитывать, если где-то и ошибётся на предложение/параграф, ничего страшного не произойдёт. Человек же читает только одну версию, а в другую только подглядывает, если на что-то реально сложное наткнётся. (По крайней мере, я себе это так представляю)
P.S. Я могу написать такой скрипт, но я хочу чтобы он был реально полезным и им пользовались больше чем полтора анонимуса.
В идеале вижу это как сайт или бот для телеграмма.
P.P.S Хм, бота я и сам могу написать. В общем, если кто хочет поучаствовать, пишите в личку.
Забавно, но у меня наоборот. И от книг глаза тоже устают. У читалки постоянные проблемы с освещением, на телефоне можно практически любую яркость выбрать. Ну и fullhd экран на телефоне это сказка — пиксели разве что с лупой разглядеть можно.
Напомнило реализацию в человеке-пауке: https://habr.com/post/424827. Но в форзе, хоть и сделано практически то же самое, результат выглядит на порядок симпатичнее и проработаннее.
Имхо, в будущем такой эффект будет использоваться во всех играх, где есть окна. Для окон вдали, а таких окон на сцене большинство, этот способ изумительно подходит. Для окон вблизи при стремлении к реализму можно рисовать честный объёмный интерьер.
Да ничего она не усугубит. Если куча косвенных налогов типа НДС, акцизов, пошлин на ввоз автомобилей и просто грабежа в виде внезапных падений рубля. От них практически никуда не деться. Вдобавок, государство имеет доход от продажи природных ресурсов типа нефти/газа/металлов/леса. Если человек "сэкономил" деньги на явных налогах, он всё равно потратит их здесь (если он конечно, не недвижимость в Англии покупать собрался) и эти деньги останутся в экономике РФ.
Про бесплатные медицину/образование можно не рассказывать, львиная доля расходов идёт совсем не на них, да и по-факту для потребителя они всё равно получаются платными.
В блендере есть аналогичный node editor для шейдеров. Поначалу я думал, что это наглядно и удобно, но потом понял, что реализация сколько-нибудь сложной функции занимает кучу места и оказывается сложной для восприятия. Переиспользовать код тоже неудобно — приходится создавать подграфы и переключаться между ними.
Например, простейшая модель освещения:
Эта строчка легко читается, быстро печатается и занимает мало места: на экране без проблем поместится ещё 50-100 таких же. Если я захочу добавить зеркальное отражение — допишу ещё одну строчку.
А в нодах — выщеописанная функция уже содержит 5 операций и использует 5 переменных и одну константу. Т.е., в граф придётся добавить ещё 6 новых вершин и потом соединить их друг с другом и с пятью внешними вершинами. Это уже громоздко выглядит, не говоря уж о чём-то реально сложном.
Никакими культурными словами не выразить эту боль.Несколько замечательных примеров:пользоваться телепортомпокупать самый дешёвый билет, просто чтобы зайти на платформу.С точки зрения Fitt's law абсолютным идеалом является контекстное меню по ПКМ, которое вообще не требует двигать мышь для его открытия.
По упомянутому вами закону надо оценивать расстояние, делённое на размер кнопки. Тянуть мышку через пол-экрана неудобно. Если экранов несколько, я оказываюсь в ситуации, когда надо тянуться вдаль от окна к одинокой узкой по высоте кнопке, рискуя "проскочить" её и оказаться мышкой на другом экране. А если на нижнем экране приложение открыть в полноэкранный режим, то эта панелька скрывается, и чтобы она появилась, надо проявить изумительную точность прицеливания точно в верхние пиксели нижнего экрана.
Попробовал: в OSX --color не поддерживается, вместо него -G
Кстати, можно в finder выбрать картинку, нажать пробел и потом стрелочками переключаться. Фишка вроде прикольная, но и тут косяк — если в finder картинки отображаются не списком, а сеткой, то нажатие кнопки "вправо" доходит до самой правой картинки в строчке и на следующую строчку уже не прыгает.
К сожалению, в РПГ играх по неизвестной мне причине части доспехов привязываются к нескольким костям сразу, из-за чего железный доспех крайне неестесственно растягивается или мнётся при каждом движении персонажа.
Возможно, это мелочи и всё фиксится и настраивается, но дефолтное поведение мне точно не нравится:
Разница огромна, если программа работает дольше времени компиляции или на удалённом компе. Очень печально осознавать, что обучаемая несколько часов нейронная сеть не была сохранена просто из за-того, что в какую-нибудь функцию передали не то количество параметров или ошиблись с их типом.
Причём может быть, что в одной ветке ветвления всё хорошо, а в другой — нет. И вроде бы работающая программа может оказаться не очень работающей, если что-то не совпало.
Рефакторить более-менее большой проект на питоне или на java/scala — тоже огромная разница. В статических языках та же IDEA хорошо справляется и можно совершенно свободно менять что хочется. Если не справляется — я узнаю об этом во время компиляции и тут же поправлю. С питоном среда разработки от тех же разработчиков справляет плохо и банальное переименование переменной/поля оставляет в различных местах "сюрпризы" на будущее.