Все верно — 80/20 и 80% работы делают 20% сотрудников. Именно эти 20% я и имел ввиду, когда говорил о хороших специалистах. А на всех остальных (средних специалистов и плохих) в сумме 20% работы приходится.
Вы не поверите, но если это не мелкая студия на 10 рабочих мест, а уже более-менее компания со штатом хотя бы в 50-100 человек, то как раз основной вал работы выполняют эти самые «середнячки»
Как раз в средних компаниях (на 50-100 человек) по моим наблюдениям основной вал работы делают десяток хороших специалистов (если мы об IT говорим). А остальные стоят на подхвате и делают то, чем специалисту заниматься не интересно.
должно же быть хоть какое-то обоснование использования именно этих операторов
Так визуальная составляющая и была основой для выбора. Операторы напоминают стрелку. Собственно для обозначения сдвига они используются ровно по той же причине.
Хотя бы потому, что есть клиенты, которые сидят за натом и это одно из исключений, которыми обрастет ваша идея.
Ну на абсолютную универсальность я не претендую. Это всего лишь эксперимент.
И я его оцениваю, как удачный. Хабраэффект создал некоторую нагрузку (самое главное — разнообразие браузеров и сетевых конфигураций), которую вручную создать было затруднительно. Некоторые ошибки найдены и устранены, проблемы осознаны.
В то же время идею можно считать рабочей — мне и самому удалось сыграть множество партий с разными соперниками, да и другие люди, привлеченные к тестированию, поиграли. Всем понравилось :)
Ну а если по теме, то сервер для связи двух клиентов WebRTC имеет совсем не сложную структуру.
Так вопрос совсем не в сложности кода (он у меня есть и даже работает). А в том, что хочется от лишнего звена избавиться. Логически построение взаимодействия при наличии центрального синхронизирующего элемента намного проще, но привязка к такому центральному элементу делает все решение крайне негибким.
Идеальный вариант это простой html файл, который можно засунуть куда угодно и который будет работать без всякой настройки, конфигов и прочей фигни. И в общем случае ничто не мешает созданию такой сети взаимодействующих друг с другом клиентов, без наличия центрального синхронизирующего элемента. В случае webrtc без сигнального сервера не обойтись, но есть возможность не завязываться на специальный сервер для проекта, а использовать общедоступные ресурсы.
И какое отношение это имеет к указанному топику? Может быть тут написано, что это блог компании? Или сказано, что это компания mail.ru проводила эксперимент?
О состоянии серверов мне ничего неизвестно.
Но вижу ситуацию, когда к одному пиру ломится сразу несколько попыток соединения, и при этом он и отлупов не дает, но и соединение не устанавливает. В результате все «ждут». Что именно в данном случае является критичным я не знаю — не похоже, что проблема в количестве, а вот разные версии браузеров вполне могут быть причиной. А может быть надо озаботиться использованием STUN. Средств диагностики не хватает. Да и отсутствие сервера с его логами тоже мешает :)
Ну от хабраэффекта и не такие поделки падали.
В целом пост, конечно же пятничный. Это скорее эксперимент, но добиться того поведения, которое я наблюдаю сейчас, мне, имея один ноут, не удавалось. Поэтому я и говорю, что тестирование очень удачным получилось.
UPD: Вернее, зачем вы это назвали без сервера и делаете на этом акцент.
Обычно для того, чтобы организовать выбор случайного соперника приходится писать некий серверный код, который отслеживает статус имеющихся пользователей. И соединяет пару свободных друг с другом. В данном случае тот же функционал работает без такого серверного кода. Клиенты случайным образом сами выбирают друг друга.
При этом никаких проблем с накоплением ошибки не будет, если округлять только на последнем шаге
Проблемы могут быть, так как конечное представление чисел в любом случае требует промежуточных округлений. Если длина мантиссы 23 бита, то при перемножении двух чисел имеющих 20-битную мантису ошибки будут появляться.
Можно еще при правке в гранулярном поле просто очищать общее.
Угу. А еще лучше не очищать, а заполнять, составляя его из имеющихся гранулярных полей.
С адресом, в общем-то, аналогично.
Кстати, протестил на паре соседей — оба не догадались, что при неудачном автоматическом разборе можно поправить данные в гранулярных полях вручную. Наверное, стоит оформить это более очевидным образом.
«Племен» у каждого индивидуума много. Самое маленькое — семья, дальше идут родственники, этническая группа, страна, раса, все человечество. Каждое действие в рамках естественного отбора оценивается «ситом» этих племен — самая важная задача — сохранить человечество, как вид. Если виду в целом ничего не угрожает, то надо стремиться к доминированию своей расы в этом человечестве и так далее до «мелкого племени» — семьи. Результатом такого отбора является не только безусловные рефлексы отдельных особей, но и общие культурно-этические нормы.
Если бы не XML, то было бы неплохо. Даже не менее универсальный json выглядит на порядок дружелюбнее, а специализированные форматы значительно удобнее и читабельнее.
Так визуальная составляющая и была основой для выбора. Операторы напоминают стрелку. Собственно для обозначения сдвига они используются ровно по той же причине.
Ну на абсолютную универсальность я не претендую. Это всего лишь эксперимент.
И я его оцениваю, как удачный. Хабраэффект создал некоторую нагрузку (самое главное — разнообразие браузеров и сетевых конфигураций), которую вручную создать было затруднительно. Некоторые ошибки найдены и устранены, проблемы осознаны.
В то же время идею можно считать рабочей — мне и самому удалось сыграть множество партий с разными соперниками, да и другие люди, привлеченные к тестированию, поиграли. Всем понравилось :)
Идеальный вариант это простой html файл, который можно засунуть куда угодно и который будет работать без всякой настройки, конфигов и прочей фигни. И в общем случае ничто не мешает созданию такой сети взаимодействующих друг с другом клиентов, без наличия центрального синхронизирующего элемента. В случае webrtc без сигнального сервера не обойтись, но есть возможность не завязываться на специальный сервер для проекта, а использовать общедоступные ресурсы.
Эксперименты для того и проводятся, чтобы разобраться в технологии.
Но вижу ситуацию, когда к одному пиру ломится сразу несколько попыток соединения, и при этом он и отлупов не дает, но и соединение не устанавливает. В результате все «ждут». Что именно в данном случае является критичным я не знаю — не похоже, что проблема в количестве, а вот разные версии браузеров вполне могут быть причиной. А может быть надо озаботиться использованием STUN. Средств диагностики не хватает. Да и отсутствие сервера с его логами тоже мешает :)
В целом пост, конечно же пятничный. Это скорее эксперимент, но добиться того поведения, которое я наблюдаю сейчас, мне, имея один ноут, не удавалось. Поэтому я и говорю, что тестирование очень удачным получилось.
Обычно для того, чтобы организовать выбор случайного соперника приходится писать некий серверный код, который отслеживает статус имеющихся пользователей. И соединяет пару свободных друг с другом. В данном случае тот же функционал работает без такого серверного кода. Клиенты случайным образом сами выбирают друг друга.
Затем, чтобы получить функционал соединения со случайным клиентом. :)
Угу. А еще лучше не очищать, а заполнять, составляя его из имеющихся гранулярных полей.
С адресом, в общем-то, аналогично.
Кстати, протестил на паре соседей — оба не догадались, что при неудачном автоматическом разборе можно поправить данные в гранулярных полях вручную. Наверное, стоит оформить это более очевидным образом.