Зашел на автором расхваленный Procreate, и вот что увидел на первой странице.
Скриншот
50% экрана занимает огромный баннер, который предлагает мне скачать что-то для планшета? Текст писать смогу разными шрифтами?
30% занимают баннер мобильной версии (?) и приглашение в Instagram;
ещё по 10% занимают менюшка с кнопкой "зарегистрироваться" и предупреждение о кукисах.
Так собственно чем они занимаются то?
Я с десктопа захожу на сайт, зачем мне рекламируют мобильные приложения?
Знатоки UX, объясните мне, как работает "этот ваш" современный веб? :)
На сколько это "безопасно" для desktop версии с точки зрения глюков и совместимости?
Хочу обновить рабочий комп с 16.04 LTS, но склоняюсь к полной переустановке.
Как то раз делал апгрейд между не-LTS версиями, потом воевал с драйверами, которые видимо остались из предыдущей версии.
Печально, когда весь гугл пишет что всё работает, а у тебя внезапно отвалился тачпэд.
Кто-нибудь наступал на подобные грабли с новой / LTS версией?
Как раз начали разбираться с этой регулой, всё не можем понять, про нас это или нет.
У нас немного нетипичная ситуация: собираем различные данные с датчиков и обрабатываем их. Железяки находятся за пределами ЕС, софт и данные — на Европейском сервере. Пользователи заходят в наш софт через третью сторону (в нашем случае это Auth0), который производит аутентификацию и выдает токен. На своей стороне мы получаем id и fullName пользователя и показываем ему данные с его железяк.
Если не составит труда, подскажите:
данные с железяк (температура, влажность, итд) считаются ПД?
кто обрабатывает пользователя (username, password) — Auth0 или всё-таки мы? Должны ли мы оповестить пользователя, что мы получили его имя через токен? Или всё таки это ответственность сервиса?
Как-то не очень конструктивна получается дискуссия. Попробую объяснить своё видение.
Возьмём абстрактную игру и события во времени:
t(0) — есть некий игрок (И), у которого 10 из 100 ед. жизней ("чуть живой");
t(1) — другой игрок лекарь (Л) жмет кнопку "вылечить И на 10 ед";
t(2) — третий игрок убийца (У) жмет кнопку "ударить И на 10 ед";
t(3) — у У быстрый интернет и его команда прилетает на сервер первой;
t(4) — у Л медленный интернет, его команда пришла второй;
Вопрос: что произойдёт с И?
По вашему получается, что И будет мертв, а Л получит отказ (пытался лечить мертвого).
В итоге игрок с быстрым интернетом получает преимущество.
Я же считаю, что И должен остаться при 10 ед. жизней (10 начальных + 10 вылеченных — 10 ударенных), так как лекарь отправил команду раньше.
Даже если в момент t(3) сервер разослал всем клиентам что у И 0 жизней, он должен иметь некий "grace period" и если позже пришла запоздалая команда, то переиграть историю.
От сервера, я соответственно ожидаю состояния:
t(0) — у И 10 ед. жизней;
t(1) — у И 10 ед. жизней;
t(2) — у И 10 ед. жизней;
t(3) — у И 0 ед. жизней, но он всё ещё жив (ждем немного, авось кто-то опаздывает с лечением);
t(4) — у И 10 ед. жизней;
А если лечение не прилетело, то где-нибудь в t(5) отправляем клиентам что И мертв окончательно.
Или я мыслю слишком утопично? По аналоги можно смоделировать ситуации с движением, выстрелами в дверной проём и прочим.
Так вот что, собственно, меня будоражит: как достоверно сообщить серверу, в какой именно момент произошла отправка команды с клиента?
Как серверу проверить, что Л действительно отправил команду в t(1), а не в t(3) и прикинулся медленным?
Я собственно ссылался на текущую статью, где есть отдельная глава "Согласование на сервере". И на сколько я понимаю это несколько отличается от "компенсации лага".
Но это не меняет сути моего вопроса. Что при согласование на сервере, что при компенсации лага клиент должен как-то сообщить серверу "что он видел" в момент выполнения команды.
Так вот как это сделать наиболее надежно от подделок?
Вами описанный сценарий — это сервер без согласования ("наивная реализация" из данной статьи). То есть как только команда пришла от клиента, она сразу выполняется "окончательно".
И тогда игроки с меньшим пингом имеют преимущество над остальными, что не всегда приемлемо.
Согласование подразумевает, что сервер может "переиграть" историю если более медленный клиент выполнял команды в то время.
Например, это заметно в некоторых ММО: жизни персонажа падают до 0, но умирает персонаж несколько позже, видимо когда сервер дождался всех медленных клиентов.
Сервер получает команды с клиентов и времена их отправления
Сервер обновляет состояние мира
...
Да, читал всё части, но как раз-таки остаётся вопрос: как передать время отправления команд на клиенте таким образом, чтоб его невозможно было подделать?
То есть каким образом сервер может удостоверится, что команда на клиенте действительно была выполнена в заявленный момент.
Просто напрашивается батальный чит: получаем от сервера актуальное состояние S(t), а команды шлем как будто мы видели состояние S(t-1). И всё, мы всегда на один шаг впереди остальных.
Такой вопрос: как в случае с согласованием на сервере бороться с читерами?
Искусственно увеличивая upload задержку можно добиться, чтобы сервер постоянно переписывал историю в нашу пользу. Например, честный игрок делает прицельный выстрел, а читер отправляет, что секунду назад он переместился в другую сторону. В итоге сервер пересчитывает историю и выстрел происходит мимо цели.
Как наиболее надежно сообщить серверу, в какой именно момент на клиенте произошли действия?
Недавно полностью пересел на Убунту, потому тоже изучал этот вопрос.
Вариантов достаточно много, но все они "другие" по сравнению с Win/Mac.
Из того что я попробовал:
Через стандартный Online Accounts можно смонтировать диск как сетевую папку. Притормаживает и нет оффлайн доступа к файлам, но зато можно синхронизировать как простую папку.
overGrive — бывший grive, но рабочий и за 5$. Работает из коробки, но мне очень часто выдавал что превышена квота на количеств скачиваний, потому синхронизация была не очень стабильна.
rclone — как rsync, только в облака. Мощный инструмент, мне показался слишком громоздким, к тому же без специальных настроек может "потерять" данные.
drive — первоначальный автор: сотрудница Google Drive команды, работает по принципу push / pull, что только на первый взгляд кажется не удобным. По умолчанию работает в интерактивном режиме и в спорных случаях предупреждает юзера. На данный момент остановился на нем, так как свой велосипед такого уровня точно писать нет смысла (а там далеко только скачать/загрузить папку, а всякого рода оптимизации, проверки и тд).
Одна проблема с этими утилитами (кроме overGrive): их надо запускать вручную или через крон.
Нашел интересную статью про inotifywait. Его можно использовать для загрузки файлов в облако "сразу после изменений", хочу попробовать на досуге. Для полного счастья надо найти что-то подобное в обратную сторону.
Мне кажется это основная проблема подобных туториалов.
Всё упомянутые инструменты, будь то Gulp, Grunt, bower, browsery или webpack, хороши на простых примерах.
Но как их использовать на реальных проектах, в которых десятки модулей, специфичные требования, какие-нибудь не стандартные библиотеки?
В частности, про webpack мне было бы интересно почитать про:
— как настраивать различные окружения (например, dev для локального запуска, а prod с минификацией и ссылками на реальные бэкенды);
— как собирать готовый билд, который потом можно выкатывать в продукцию (не просто js-бандл, а отдельная директория / zip / jar со всем необходимым);
— как интегрировать всё это с процессами бэкенда (аля, написал «gradlew build» и на выходе получил и фронт и бэк).
У меня есть смутные предчувствия что одним webpack-ом тут не обойтись.
Спасибо, попробую.
Это получается настройки берутся по названию exe-шки?
А как быть если разные файлы с одним названием? Какие-нибудь launcher.exe для различных софтов, или вообще java.exe. Просто любопытно.
Никогда не подумал бы что проект «Странник» до сих пор жив. Лет 10 назад имел возможность пройти их тест без существенных капиталовложений.
Спорные впечатления.
Восприятие цвета действительно очень индивидуально, и как выше упоминали, современные технологии машинного обучения и большой набор данных действительно можно использовать для диагностики.
В то время это было что то из разряда фантастики.
Я всё таки склоняюсь к тому, что система использует известные медицинские наблюдения, но «пускает пыль в глаза» разного рода трюками (например, сильно расплывчатые диагнозы, которые просят уточнить самого пациента).
Зашел на автором расхваленный Procreate, и вот что увидел на первой странице.
Так собственно чем они занимаются то?
Я с десктопа захожу на сайт, зачем мне рекламируют мобильные приложения?
Знатоки UX, объясните мне, как работает "этот ваш" современный веб? :)
На сколько это "безопасно" для desktop версии с точки зрения глюков и совместимости?
Хочу обновить рабочий комп с 16.04 LTS, но склоняюсь к полной переустановке.
Как то раз делал апгрейд между не-LTS версиями, потом воевал с драйверами, которые видимо остались из предыдущей версии.
Печально, когда весь гугл пишет что всё работает, а у тебя внезапно отвалился тачпэд.
Кто-нибудь наступал на подобные грабли с новой / LTS версией?
Как раз начали разбираться с этой регулой, всё не можем понять, про нас это или нет.
У нас немного нетипичная ситуация: собираем различные данные с датчиков и обрабатываем их. Железяки находятся за пределами ЕС, софт и данные — на Европейском сервере. Пользователи заходят в наш софт через третью сторону (в нашем случае это Auth0), который производит аутентификацию и выдает токен. На своей стороне мы получаем id и fullName пользователя и показываем ему данные с его железяк.
Если не составит труда, подскажите:
Может это, конечно, субъективно, но основные:
Несколько примеров (без контекста) :
Не ради холивара…
Мне однажды показали Spock Framework, с тех пор с не могу без боли смотреть на JUnit.
Для чистой Java есть прекрасная библиотека lombok. Ваш длиннющий пример превращается в что-то подобное:
Как-то не очень конструктивна получается дискуссия. Попробую объяснить своё видение.
Возьмём абстрактную игру и события во времени:
Вопрос: что произойдёт с И?
По вашему получается, что И будет мертв, а Л получит отказ (пытался лечить мертвого).
В итоге игрок с быстрым интернетом получает преимущество.
Я же считаю, что И должен остаться при 10 ед. жизней (10 начальных + 10 вылеченных — 10 ударенных), так как лекарь отправил команду раньше.
Даже если в момент t(3) сервер разослал всем клиентам что у И 0 жизней, он должен иметь некий "grace period" и если позже пришла запоздалая команда, то переиграть историю.
От сервера, я соответственно ожидаю состояния:
А если лечение не прилетело, то где-нибудь в t(5) отправляем клиентам что И мертв окончательно.
Или я мыслю слишком утопично? По аналоги можно смоделировать ситуации с движением, выстрелами в дверной проём и прочим.
Так вот что, собственно, меня будоражит: как достоверно сообщить серверу, в какой именно момент произошла отправка команды с клиента?
Как серверу проверить, что Л действительно отправил команду в t(1), а не в t(3) и прикинулся медленным?
Я собственно ссылался на текущую статью, где есть отдельная глава "Согласование на сервере". И на сколько я понимаю это несколько отличается от "компенсации лага".
Но это не меняет сути моего вопроса. Что при согласование на сервере, что при компенсации лага клиент должен как-то сообщить серверу "что он видел" в момент выполнения команды.
Так вот как это сделать наиболее надежно от подделок?
Вами описанный сценарий — это сервер без согласования ("наивная реализация" из данной статьи). То есть как только команда пришла от клиента, она сразу выполняется "окончательно".
И тогда игроки с меньшим пингом имеют преимущество над остальными, что не всегда приемлемо.
Согласование подразумевает, что сервер может "переиграть" историю если более медленный клиент выполнял команды в то время.
Например, это заметно в некоторых ММО: жизни персонажа падают до 0, но умирает персонаж несколько позже, видимо когда сервер дождался всех медленных клиентов.
Да, читал всё части, но как раз-таки остаётся вопрос: как передать время отправления команд на клиенте таким образом, чтоб его невозможно было подделать?
То есть каким образом сервер может удостоверится, что команда на клиенте действительно была выполнена в заявленный момент.
Просто напрашивается батальный чит: получаем от сервера актуальное состояние S(t), а команды шлем как будто мы видели состояние S(t-1). И всё, мы всегда на один шаг впереди остальных.
Такой вопрос: как в случае с согласованием на сервере бороться с читерами?
Искусственно увеличивая upload задержку можно добиться, чтобы сервер постоянно переписывал историю в нашу пользу. Например, честный игрок делает прицельный выстрел, а читер отправляет, что секунду назад он переместился в другую сторону. В итоге сервер пересчитывает историю и выстрел происходит мимо цели.
Как наиболее надежно сообщить серверу, в какой именно момент на клиенте произошли действия?
И это очень позитивно! Опыт лишним не бывает.
Статья в любом случае познавательна, спасибо!
Недавно полностью пересел на Убунту, потому тоже изучал этот вопрос.
Вариантов достаточно много, но все они "другие" по сравнению с Win/Mac.
Из того что я попробовал:
Одна проблема с этими утилитами (кроме overGrive): их надо запускать вручную или через крон.
Нашел интересную статью про inotifywait. Его можно использовать для загрузки файлов в облако "сразу после изменений", хочу попробовать на досуге. Для полного счастья надо найти что-то подобное в обратную сторону.
Мне кажется это основная проблема подобных туториалов.
Всё упомянутые инструменты, будь то Gulp, Grunt, bower, browsery или webpack, хороши на простых примерах.
Но как их использовать на реальных проектах, в которых десятки модулей, специфичные требования, какие-нибудь не стандартные библиотеки?
В частности, про webpack мне было бы интересно почитать про:
— как настраивать различные окружения (например, dev для локального запуска, а prod с минификацией и ссылками на реальные бэкенды);
— как собирать готовый билд, который потом можно выкатывать в продукцию (не просто js-бандл, а отдельная директория / zip / jar со всем необходимым);
— как интегрировать всё это с процессами бэкенда (аля, написал «gradlew build» и на выходе получил и фронт и бэк).
У меня есть смутные предчувствия что одним webpack-ом тут не обойтись.
Я правильно понимаю, что в индустрии сейчас вообще не рассматриваются игры без доната?
Это получается настройки берутся по названию exe-шки?
А как быть если разные файлы с одним названием? Какие-нибудь launcher.exe для различных софтов, или вообще java.exe. Просто любопытно.
Dropbox на пару с GoogleDrive на старте занимают лаптоп на добрых 10 минут.
Спорные впечатления.
Восприятие цвета действительно очень индивидуально, и как выше упоминали, современные технологии машинного обучения и большой набор данных действительно можно использовать для диагностики.
В то время это было что то из разряда фантастики.
Я всё таки склоняюсь к тому, что система использует известные медицинские наблюдения, но «пускает пыль в глаза» разного рода трюками (например, сильно расплывчатые диагнозы, которые просят уточнить самого пациента).