Можно прямо несколько инстансов браузера открыть и потыкать)))

я сделал и с комнатами, и Vue.js прикрутил. думаю, отказ не с кодом связан

Обычно позиция последнего прочитанного храниться на клиенте и при подключении именно с нее идет запрос не прочитанных сообщений. В этом случае очередь не полходит

В общем менять придется тестовое задание работадателю :)

Ну а что делать..

почему? просто не принимать уже сделанное кем-то...

в смысле - дубликаты

да офигеешь сидеть проверять похоже ли оно на кого то

память надо хорошую

ну, да, там же на хорошую вакансию должно было желающих собраться овер9000. действительно

ты когда делал? вообще они тестовое дают после собеса.  может тебя кто-нибудь перебил по деньгам. я, например.
сейчас на каратине может что-то изменилось.

В реальной жизни сообщения хранятся в БД, в ets хранится кэш последних сообщений.
И тут можно сколько угодно заниматься отработкой того, как их синхронизировать.
Этой задачей можно долго заниматься. Может этим она и хороша? Показывает насколько человек готов погрузиться)

Это прием при наборе джуна имеет смысл

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

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

я тебя по айпи вычислю!!!

кстати, на счет эффективности атомов и байтодрочеров... все мы знаем, что внутри машины ерланга атомы оперируются внутренними идентикаторами, т.е. обычное число из массива строк (условно). также при передаче этих атомов между нодами используется т.н. Header Atom Cache - при первой пересылке атома он говорит соседней ноде "запиши там у себя вот этот атом вот с таки ид, я следом буду тебе слать не атомы, а их ид, так что ты там их транслируй у себя". Тема прикольная и даже на первый взгляд стимулирует ожидания аццкого прироста производительности. Ну, логично же. По факту, опыт показал, что вся эта свистопляска с атомами по сети дает лишь 10-20% прироста производительности, и то, только в части декодирования (т.е. на принимающей стороне). Я когда начал реализовывать у себя в проекте поддержку этой фичи сидел ручки потные потирал в ожиданиях значительного прироста перформанса. А на выходе как-то очень скромно получилось. Хотя, допускаю, в самом ерланге есть от этого польза. Возможно даже и в сетевом взаимодействии они там имеют выигрышь (хотя бы потому, что их ETF encoder/decoder мягко говоря неэффективно написан)

Да писать ими удобней, что уж тут, эти угловые скобки запаривают, что писать что читать

Не совсем так. Он в сообщении прикладывает таблицу атомов, содержащихся в этом сообщении (до 255).
Он не может удаленной ноде сказать какой индекс присвоить атому, т.к этот индекс может быть занят.
http://erlang.org/doc/apps/erts/erl_ext_dist.html#distribution_header

не, не так...