Зашел на автором расхваленный Procreate, и вот что увидел на первой странице.

• 50% экрана занимает огромный баннер, который предлагает мне скачать что-то для планшета? Текст писать смогу разными шрифтами?
• 30% занимают баннер мобильной версии (?) и приглашение в Instagram;
• ещё по 10% занимают менюшка с кнопкой "зарегистрироваться" и предупреждение о кукисах.

Так собственно чем они занимаются то?
Я с десктопа захожу на сайт, зачем мне рекламируют мобильные приложения?
Знатоки UX, объясните мне, как работает "этот ваш" современный веб? :)

$ sudo do-release-upgrade -d

На сколько это "безопасно" для desktop версии с точки зрения глюков и совместимости?
Хочу обновить рабочий комп с 16.04 LTS, но склоняюсь к полной переустановке.

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

Кто-нибудь наступал на подобные грабли с новой / LTS версией?

Как раз начали разбираться с этой регулой, всё не можем понять, про нас это или нет.

У нас немного нетипичная ситуация: собираем различные данные с датчиков и обрабатываем их. Железяки находятся за пределами ЕС, софт и данные — на Европейском сервере. Пользователи заходят в наш софт через третью сторону (в нашем случае это Auth0), который производит аутентификацию и выдает токен. На своей стороне мы получаем id и fullName пользователя и показываем ему данные с его железяк.

Если не составит труда, подскажите:

• данные с железяк (температура, влажность, итд) считаются ПД?
• кто обрабатывает пользователя (username, password) — Auth0 или всё-таки мы? Должны ли мы оповестить пользователя, что мы получили его имя через токен? Или всё таки это ответственность сервиса?

Может это, конечно, субъективно, но основные:

• создание Mock-ов просто и наглядно,
• assert-ы средствами языка
• (edited) числа сразу BigDecimal, особенно актуально в финансах, где почти все данные — различные суммы.

Несколько примеров (без контекста) :

def "should get person by id"() {
  given:
    def repository = Mock(PersonRepository) {
      findById("100") >> Optional.of(new Person(id: "100"))
      findById("200") >> Optional.empty()
    }    
  when: "existing person"
      def bean = service.getPersonById("100")
  then:
      bean.id == "100"
  when: "not existing person"
      service.getPersonById("200")
  then:
      thrown NotFoundException
}

def "should find all by order id"() {
    when:
        def list = repository.findAllByOrderId(orderId)
    then:
        list.size() == size
        list.collect { it.id } == ids
        list.any { it.totalAmount == 123.45 }
    where:
        orderId | size | ids
        "ord-A" | 2    | ["100", "300"]
        "ord-B" | 1    | ["200"]
        "ord-C" | 0    | []
}

Не ради холивара…
Мне однажды показали Spock Framework, с тех пор с не могу без боли смотреть на JUnit.

Для чистой Java есть прекрасная библиотека lombok. Ваш длиннющий пример превращается в что-то подобное:

@Data
@Builder
public class ImageSets {
    Boolean inCircle = false;
    Boolean needFit = false;
    Size size = null;
    int defaultDrawableResource = -1;
}

Как-то не очень конструктивна получается дискуссия. Попробую объяснить своё видение.

Возьмём абстрактную игру и события во времени:

• 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. Его можно использовать для загрузки файлов в облако "сразу после изменений", хочу попробовать на досуге. Для полного счастья надо найти что-то подобное в обратную сторону.

Допустим, мы пишем простую страницу...

В игре реализован биллинг и принимаются платежи