Я конечно понимаю, что реклама, и все такое. Но серьезые конторы берут и без опыта. Я в теме, по крайней мере в одной компании из списка работал, а еще в одной собеседовался. Так вот про конкретные технологии не спрашивали ни там, ни там. Спрашивают базу: алгоритмы, глубокое знание java core, логические задачи.
Честно говоря, я так и не понял чем то, что вы написали, лучше, чем ZeroMQ? Что значит нет абстракции от сети? Вообще-то там достаточно большой слой абстракции, например там нет понятия у сокета подключен/не подключен, это скрыто от пользователя. А какие у вас тут абстракции?
>Из корпоративного сегмента, насколько мне известно, есть только один продукт: TIBCO Rendezvous (если кто посоветует альтернативы, буду очень признателен).
Ultra Messaging от Informatica (ранее оно называлось LBM, а еще до этого — 29west)
Лично моя практика показывает, что студенты знают эти алгоритмы и структуры данных скорее поверхностно. При этом знакомые мне мощные архитекторы как раз таки в теме алгоритмов чаще как рыба в воде, так как под высокую нагрузку порой приходится реализовывать свои структуры данных ну или в любом случае понимать как работают готовые.
Вы не обижайтесь, но без вашего реального кода перед глазами ничего нельзя сказать об эффективности, и в голову лезут мысли вроде того, что у вас там сотни серверов потому, что вы не умеете сортировку пузырьком сделать.
Конечно, возможно я ошибаюсь, и у вас там все хорошо с вашими проектами, но собеседование оно такое — скорее не возьмут хорошего, чем возьмут не хорошего, так что если пойдете на собеседовании, лучше википедию с пол-часа почитать, что бы не вызывать лишних подозрений.
P.S. Что касатеся миллиона запроса в сутки с 10 кратным запасом, то это примерно 100 запросов в секунду, что увы не является выдающимся показателем. Выдающийся показатель, это например 10 000 запросов в секунду.
Ну так а кто говорит, что нужно на собеседованиях заставлять кодить нетривиальные структуры данных вроде btree? Но понять знает ли кандидат общие принципы и отличия базовых структур необходимо — это же наша азбука.
Абсолютно согласен, скорее именно у ленивого менеджера вечно некогда «точить пилу», он же ленивый. А у трудолюбивого пилы наточены, и люди не тратят силы на борьбу со внешними условиями.
Естественно может. Но я надеюсь что приведенный метод написан хорошо и не вызывает блокиурющих методов :) Иначе другие горутины тоже могут блокировать поток, короче все будет как в обычном многопоточном приложении без горутин.
Позвольте попридираться к формулировкам, а тот тут в каментах уже задают вопросы. Я вот про этот утверждение «region.GetRegionByLbs асинхронно ходит в серсис геобазы и Lbs». Думаю правильней сказать, что этот метод все-таки синхронный (т.е. пока он не отработает, последующий за ним код не начнет выполняться), но он неблокирующий, в том смысле, что он не блокирует поток ОС за счет использования goroutines.
А вы программируя никогда не делаете ошибок? Мне кажется все ошибаются, и что бы это как-то компенсировать и нужны безопасные средства программирования вроде статического анализа. И очевидно программы таки становятся лучше, если исчезает сразу целый класс ошибок. Например если в языке нет null, то никаких null pointer exception случиться не может. А если null есть, то какой бы программист не был прокаченный, он рано или поздно забудет проверить на null и будет баг. Конечно проблема качества решаются с двух сторон, и программистом, и анализаторами. Но анализаторы практически не ошибаются, в отличии от человека.
А почему вы считате, что правильнее хранить баланс в кеше? Если вы используете транзакции, то никаких проблем с созданием транзакции и обновлением баланса быть не должно.
Монга практически всегда быстрее постгреса с полной сохранностью на запись, так как там действительно нельзя настроить полную сохранность :). Но все же можно добиться и хорошей скорости и надежности сделав кластер из монг. А вот сделать кластер из постгресов уже сложнее. Все таки на монгу нужно смотреть как на кластерную бд.
Совершенно верно. Кроме того, ничего не мешает устроить «аутсорс» внутри компании — ИТ-отдел рассматривается как самостоятельная единица, взаимодействие с которым ведется через взаимные обязательства, стратегией развития продукта ИТ-отдел не занимается.
Вот читаю уже вторую статья… Может вы лучше сразу перейдете к хардкоку, и напишите про управление памяти в Rust? А как циклы работают, ну это и так все очень просто…
Дайте побрюзжать и сказать, что map/flatMap позволяют делать for-compehension, но строго говоря не являютя монадическим интерфейсом. Монадический интерфейс это unit/flatMap. Кстати map получается комбинацией unit и flatMap, так что это скорее некое следствие из монадического интерфейса
Ultra Messaging от Informatica (ранее оно называлось LBM, а еще до этого — 29west)
Конечно, возможно я ошибаюсь, и у вас там все хорошо с вашими проектами, но собеседование оно такое — скорее не возьмут хорошего, чем возьмут не хорошего, так что если пойдете на собеседовании, лучше википедию с пол-часа почитать, что бы не вызывать лишних подозрений.
P.S. Что касатеся миллиона запроса в сутки с 10 кратным запасом, то это примерно 100 запросов в секунду, что увы не является выдающимся показателем. Выдающийся показатель, это например 10 000 запросов в секунду.