Про гарантии я имел ввиду — что возможно трансляция из scala в байткод jvm устроена отличным от траснялции java->байткод и создаёт какие-то дополнительные отношения «предшествования», о которых могут знать те, кто пишет на scala.
(Не силён в Scala)
Подскажите, в addPlayerMsg мы защитили session с помощью lock.
Но, как мне кажется, в GameServer:Loop тоже нужны:
1)Синхронизация: sessions += channel -> actor
2)Барьер: val actor = sessions.get(channel).get.asInstanceOf[ClientHandler] — иначе поток может не увидеть изменений в sessions сделаных другим потоком.
Я прав? или в Scala есть какие-то дополнительные гарантии?
Этот случай — ещё один пример, подтверждающий теорию о том, что «все люди идиоошибаются». Так что какими бы мы не казались себе умными и опытными — не забываем:
1)Возможно архитектура которой мы «гордимся» содержит ошибки.
2)Наш код — совершенно точно содержит ошибки.
2)Делать бэкапы в своих проектах, хранить их «в другом» месте и пробовать из них восстанавливаться)
Подумал ещё немного на эту тему. Возможно использование названий паттернов будет давать пользу при передачи задания от «старшего» к «младшему» в коллективах «я начальник, ты — дурак». Ну т.е. когда даётся явное указание как надо сделать конкретную вещь — то действительно проще сказать «реализуй здесь „мост“». Если же начинается обсуждение вариантов — то выйгрыш сходит на нет — начинается разрисоывавание вараинтов и «компактность» «сделай здесь мост» — пропадает.
Зачем их отключать на «своих» серверах? Писать <?=чтото?> приходится часто, а писать <?='<?xml.....'?> — нет. Вы же не станете в «своих» разработках использовать fsockopen вместо curl (или file_get_contents ) ) под предлогом того, что он может быть (и где-то так и есть) отключен.
Вот поэтому подобные «негласные» правила и кажутся фанатизмом.
Как только это станет важно — гугл начнёт выносить сомнительные аккаунты пачками. Как — довольно просто: гугл знает довольно много даже о пользователях у которых нет аккаунта в службах гугла: через поиск, через счётчики гуглоаналитики, через хостинг популярных js библиотек, через браузеры которые и другеи партнерские каналы. Гугл знает когда обычно человек проводит время в инетрнете, сколько времени, чем интересуется. Более того — у гугла такой статистики тонны — он знает как выглядит распределение всех этих характеристик, что является нормой, а что — нет. И вот очередная программа начинает генерить аккаунты у которых до этого небыло поведения, и после регистрации — или не появилось и оно сильно отклоняется от нормы
Такие аккаунты будут как чорный котэ на снегу. Как минимум гугл может не учитывать влияние таких аккаунтов, а как максимум — выспрашивать мобильный номер и слать смски.
Так что да «регать аккаунты не так уж трудно» — но денег это не принесёт)
Да и зачастую проще и надежней мотивировать посетителей ставить «лайки» традиционными способами.
«А вот если человек работать не хочет, то он и не будет.»
Плавно переходим к мысли что вопрос на собеседовании «Почему вы хотите работать у нас» (и ответ на него) — уже не кажется праздной болтавней)
А так же задаёмся вопросом — что делать и где брать людей, если у нас не яндекс/гугл/мейлрушечка — и вся наша разработка это далеко не rocket science, а просто переливание данных между СУБД и браузером + изучение заблуждений и ошибок тех кто творил это раньше. Предположу что варианта только 1: заманивать взрослых дядей с семьей и ипотекой зарплатой выше рынка + усиливать их джуниорами.
1ый вопрос выглядит некорректным: «Какие два вы выберите?» сделать осознанный выбор можно только проведя пробные компании и посмотрев конверсии («продажи», постоянные пользователи и т.д. в зависимости от того, что нам нужно). Ну пусть вараинт со сми выигрывает сразу — за счёт PR — но выбрать 1 из оставшихся 3х не получится. Поэтому — можно рассказать что мы будим делать чтобы «выбрать», но «выбрать» ничего не делая — не получится.
Да. «В теории» кажется что ТЗ и комплект OMG гостированных документов которые оно за собой влечёт кого-то от чего-то страхуют. Но часто — это не так)
Ситуация: Есть «ТЗ» (в широком смысле комплект проектной документации). Заказчик говорит «это не то, что я хотел», подрядчик говорит «это то что заказывали». Что дальше?
1)Идти в суди там трясти этими документами? Это смешно: юристы обойдутся обеим сторонам дорого, заказчик будет очень долго ждать систему, подрядчик очень долго будет ждать деньги. Судья в наших квадратиках и тсрелочках ничего не понимает — будет привлечёны «эксперты», причём с каждой стороны, которые будут говорить противоположное. Решение не удовлетворит одну из сторон — она его обжалует и всё по новой.
В итоге — у нас есть ТЗ, но и те и другие проиграли.
2)Договариваться и СОВМЕСТНО искать выход из сложившейся ситуации. Но первоначальное ТЗ тут кабэ совсем не причём и опять же никому ничего не гарантирует.
Забавно.
Человек во время работы издаёт звуки (принимает звонки на внутренний телефон, на мобильный телефон, потом говорит по телефону, обменивается репликами по работе, шутит, смеётся, бросает ручку на стол, ставит кружку на стол, размешивает сахар в чае, стучит по кнопкам клавиатуры). Это неизбежно.
Когда людей много в одном помещении — эти «всплески» образуют постоянный звуковой фон — шум.
Если стены опенспейса не покрыты чем-то звукопоглощающим — то всё это ещё и прекрасно отражается от стен.
Это физика.
И тут люди начинают утверждать что нет — у «нас» «всё хорошо», «опенспейс рулит». Ну ладно — «рулит» так «рулит».
Особенно порадовал снисходительный тон реплики: «Я искренно надеюсь, что и вам когда-нибудь повезет.» (хотя казалось бы — причём тут везение. не в казино же)
) ну не только же работа колл-центра связана с разговорами по телефону ведь так)
Даже простым людям время от времени кто-то звонит на внутренний номер, и когда людей много — получаем каждые N минут — звонок и телефонный разговор в эфире опенспейса
я как то «раз» оказался в группе разработки которая делила опенспейс с маркетингом и продаже рекламы — мне НЕ понравилось).
какой бы культура не была и как не организуй рабочее пространство — если это open-space — люди работают и создают шум. больше людей — больше шума — с этим ничего не поделать. А уж если работа некоторых людей связана с коммуникациями с другими людьми — труба.
Подскажите, в addPlayerMsg мы защитили session с помощью lock.
Но, как мне кажется, в GameServer:Loop тоже нужны:
1)Синхронизация: sessions += channel -> actor
2)Барьер: val actor = sessions.get(channel).get.asInstanceOf[ClientHandler] — иначе поток может не увидеть изменений в sessions сделаных другим потоком.
Я прав? или в Scala есть какие-то дополнительные гарантии?
идиоошибаются». Так что какими бы мы не казались себе умными и опытными — не забываем:1)Возможно архитектура которой мы «гордимся» содержит ошибки.
2)Наш код — совершенно точно содержит ошибки.
2)Делать бэкапы в своих проектах, хранить их «в другом» месте и пробовать из них восстанавливаться)
Вот поэтому подобные «негласные» правила и кажутся фанатизмом.
Такие аккаунты будут как чорный котэ на снегу. Как минимум гугл может не учитывать влияние таких аккаунтов, а как максимум — выспрашивать мобильный номер и слать смски.
Так что да «регать аккаунты не так уж трудно» — но денег это не принесёт)
Да и зачастую проще и надежней мотивировать посетителей ставить «лайки» традиционными способами.
Плавно переходим к мысли что вопрос на собеседовании «Почему вы хотите работать у нас» (и ответ на него) — уже не кажется праздной болтавней)
А так же задаёмся вопросом — что делать и где брать людей, если у нас не яндекс/гугл/мейлрушечка — и вся наша разработка это далеко не rocket science, а просто переливание данных между СУБД и браузером + изучение заблуждений и ошибок тех кто творил это раньше. Предположу что варианта только 1: заманивать взрослых дядей с семьей и ипотекой зарплатой выше рынка + усиливать их джуниорами.
Ситуация: Есть «ТЗ» (в широком смысле комплект проектной документации). Заказчик говорит «это не то, что я хотел», подрядчик говорит «это то что заказывали». Что дальше?
1)Идти в суди там трясти этими документами? Это смешно: юристы обойдутся обеим сторонам дорого, заказчик будет очень долго ждать систему, подрядчик очень долго будет ждать деньги. Судья в наших квадратиках и тсрелочках ничего не понимает — будет привлечёны «эксперты», причём с каждой стороны, которые будут говорить противоположное. Решение не удовлетворит одну из сторон — она его обжалует и всё по новой.
В итоге — у нас есть ТЗ, но и те и другие проиграли.
2)Договариваться и СОВМЕСТНО искать выход из сложившейся ситуации. Но первоначальное ТЗ тут кабэ совсем не причём и опять же никому ничего не гарантирует.
Человек во время работы издаёт звуки (принимает звонки на внутренний телефон, на мобильный телефон, потом говорит по телефону, обменивается репликами по работе, шутит, смеётся, бросает ручку на стол, ставит кружку на стол, размешивает сахар в чае, стучит по кнопкам клавиатуры). Это неизбежно.
Когда людей много в одном помещении — эти «всплески» образуют постоянный звуковой фон — шум.
Если стены опенспейса не покрыты чем-то звукопоглощающим — то всё это ещё и прекрасно отражается от стен.
Это физика.
И тут люди начинают утверждать что нет — у «нас» «всё хорошо», «опенспейс рулит». Ну ладно — «рулит» так «рулит».
Особенно порадовал снисходительный тон реплики: «Я искренно надеюсь, что и вам когда-нибудь повезет.» (хотя казалось бы — причём тут везение. не в казино же)
(хотя подозреваю, что убеждаете вы не столько меня, сколько других читателей этого топика)
Даже простым людям время от времени кто-то звонит на внутренний номер, и когда людей много — получаем каждые N минут — звонок и телефонный разговор в эфире опенспейса
какой бы культура не была и как не организуй рабочее пространство — если это open-space — люди работают и создают шум. больше людей — больше шума — с этим ничего не поделать. А уж если работа некоторых людей связана с коммуникациями с другими людьми — труба.