• Начальник, хочу работать из дома
    0
    Работаю полностью удаленно уже в третьем месте. В первых двух недолго удерживался. Самая большая проблема — составить себе мнение об удаленных сотрудниках, кто чего стоит, какой характер, стоит ли обращаться за помощью, кто что знает и кто за что отвечает. Соответственно и о тебе не складывается законченного мнения, и как результат, возникает непонимание и недоверие.
    В случае 100% удаленки я бы собирал сотрудников хоть со всего света раз в несколько месяцев на 1-2 недели, чтобы совместно поработали и получше узнали друг друга.
  • Наглядное объяснение чисел с плавающей запятой
    +4
    Это вы увидели только первый слой граблей. А там внизу еще целая куча. И основная — поддержка точности. Точность теряется на всех этапах вычислений, так что конечный результат может не иметь ничего общего с действительностью, несмотря на то, что все используемые в расчетах формулы были правильными.
  • Наглядное объяснение чисел с плавающей запятой
    0
    операции с плавающей запятой присутствовали в компьютерах с самого начала. Их не было только в специализированных компьютерах и самых дешевых компьютерах общего назначения.
  • Послевкусие от Kotlin, часть 2
    0
    а чем отличаются
    val list1: List?
    и
    var list9: List?
  • Четыре типажа программистов
    –4
    Рок-стар таких долгих объяснений не выдержит. Так что приходится ему говорить «твой код-говно», в надежде, что он и сам это знает. Он же рок-стар, должен знать.
  • Путешествие за бугор и обратно: как не надо устраиваться работать за рубежом
    +8
    Интересно. Я тоже Алексей, из Академгородка (почти), живу в Питере, устраивался в Xored, не попал, о чем жалел, но теперь не жалею.
    Xored в роли бодишопа — это вообще за гранью моего понимания. Столько понтОв, при этом заниматься такой пошлостью? Не могу поверить.
  • Объединяем акторов и SEDA-подход: зачем и как?
    0
    Да и фиг с ней. Идея так себе. Если тормозить акторы C, D, E, чтобы они не перегружали B, то они сам окажутся перегруженными. Надо смотреть на корневой источник нагрузки, например, подключения клиентов по сети, и уже этот источник подтормаживать.
  • Объединяем акторов и SEDA-подход: зачем и как?
    0
    «что делать в случае акторов Хьюита» — да ничего вы не сделаете. Признайтесь себе, наконец, что акторы Хьюита не годятся для задач сложнее студенческой курсовой. Подключите Akka Streams, например.
  • Объединяем акторов и SEDA-подход: зачем и как?
    0
    А общее число акторов нам знать и не нужно. Мы его нигде не используем.
    Это в хардверном dataflow количество вычислительных сущностей известно заранее, в силу естественных причин. А в софтверном нам никто не запрещает генерить акторы динамически.
    Не акторов, я уточнил — входов. Еще точнее — выходов. И запрос у нас не типа X, а запрос на резервирование места под запись. Такие запросы не нужно отсылать более одного раза — достаточно в запросе указать количество запрашиваемых мест.
  • Объединяем акторов и SEDA-подход: зачем и как?
    0
    И что, это вас развеселило? Не оправдавшиеся ожидания обычно огорчают.
    Я же написал: «ясно любому, кто пытался реализовать и то, и другое». Пытался. Не обязательно довел до совершенства. Потому что идейная сущность (то, что actor Хьюита — частный случай dataflow), она становится ясной довольно быстро. После чего становится скучно. И это не бог весть какое открытие, именно на уровне студенческой курсовой. А вы что, вообразили, что у нас спор кандидатов на премию Тьюринга?
  • Объединяем акторов и SEDA-подход: зачем и как?
    0
    первая ссылка — да, тестовое задание, но не в люксофт. Им требовалась именно квалификация в многопоточности. Решение их не устроило, сказали что некорректное. А теперь поделитесь, что именно вас развеселило.
  • Объединяем акторов и SEDA-подход: зачем и как?
  • Объединяем акторов и SEDA-подход: зачем и как?
    0
    Асинхронный, естественно. А отличается тем, что общее число таких запросов ограничено общим числом акторов. Отсюда и решение — пусть актор (точнее, один из его входов) сам выступает в качестве запроса, а очередь запросов сделать в виде списка, а не массива. Тогда постановка такого запроса не потребует дополнительной памяти и не сможет вызывать перегрузку.
  • Объединяем акторов и SEDA-подход: зачем и как?
    0
    Есть и практические реализации акторов с N входами, например, TPL dataflow, Intel Threading Building Blocks.
    А в Akka вроде уже добавили защиту от перегрузок, во всяком случае, понятие back-pressure упомянуто в http://doc.akka.io/docs/akka/2.5.3/scala/stream/stream-flows-and-basics.html
  • Объединяем акторов и SEDA-подход: зачем и как?
    0
    С таким же успехом вы могли бы утверждать, что рекурсивных функций на практике не существует, поскольку вы программируете на Фортране IV.
  • Объединяем акторов и SEDA-подход: зачем и как?
    0
    «Проблема в том, что вы выдвинули тезис о том, что actor model — это частный случай dataflow».

    Не вижу здесь никакой проблемы. Узлы dataflow сети названы акторами уже в 1975 году, в одной из первых работ по dataflow: Jack B. Dennis, “First Version of a Data Flow Procedure Language”. То, что actor model Хьюита — частный случай dataflow, ясно любому, кто пытался реализовать и то, и другое.
  • Объединяем акторов и SEDA-подход: зачем и как?
    +1
    аналогия не всегда демагогия. В данном случае аналогия самая прямая. Акторы — это асинхронные функции. То есть, функции, исполняющиеся, когда есть все необходимое для их исполнения — входные данные и вычислительные ресурсы. И выделять акторы с 2 входами в отдельную категорию так же наивно, как выделять сложение и умножение из всего множества математических функций только на том основании, что у них 2 аргумента. Да, это может иметь педагогический смысл, но вы же не хотите оставаться на уровне начальной школы?
  • Объединяем акторов и SEDA-подход: зачем и как?
    0
    этот вход акторам C, D и E нужен, чтобы вести себя прилично в обществе. И закладывать его надо при описании, а не в рантайме. Если же, как вы сказали, ссылку на B актор C получает в сообщении, то здесь есть разные варианты. Например, обязать посылающего, чтобы он зарезервировал у B место для приема сообщения от С. Или разбить актор С на 2 стадии — первая получает ссылку на B и делает запрос к B на резервирование места, посылая в запросе ссылку на вторую стадию. Когда у B освобождается место, он оповещает вторую стадию. В любом случае, у акторов необходимо размещать дополнительные управляющие входы, которые блокировали бы их работу до получения необходимого набора ресурсов.
  • Объединяем акторов и SEDA-подход: зачем и как?
    0
    Вероятно, вы и арифметические операции с 2 параметрами не рассматриваете как частный случай математических функций со многими параметрами?
  • Объединяем акторов и SEDA-подход: зачем и как?
    0
    от актора B на акторы C, D, E, а если найдется узел, питающий C, D, E, тогда на него.
  • Объединяем акторов и SEDA-подход: зачем и как?
    0
    1. A STRUCTURED DESCRIPTION OF DATAFLOW ACTORS AND ITS APPLICATION. Johan Eker J¨orn W. Janneck
    2. Robust Workflows for Science and Engineering. David Abramson, Blair Bethwaite, Colin Enticott, Slavisa Garic, Tom Peachey Anushka Michailova, Saleh Amirriazi, Ramya Chitters

    Собственно проблема в том, что при описании dataflow и workflow сетей (а по большому счету, это одно и то же) узлы этих сетей обычно называют не акторами, а как-нибудь по другому, хотя они именно акторы и есть.
    Так что читайте все подряд по dataflow и workflow.
  • Объединяем акторов и SEDA-подход: зачем и как?
    0
    Акторы можно классифицировать по многим признакам, но самым важным является допустимое количество входов. У акторов — идейных наследников сетей Петри (workflow, dataflow) количество входов не ограничено. У акторов Хьюита (Akka) входа ровно два — для входящих сообщений и для внутреннего состояния.
    Почему-то авторы, пишущие об акторах, как правило, знакомы только с моделью Хьюита. Отсюда утверждения типa «акторы не защищены от перегрузки». Акторы Хьюита — да, не защищены, потому что нельзя увеличить число входов. Dataflow актор защитить от перегрузки легко — стоит лишь добавить обратную связь по переполнению и завести ее на добавочный вход.
  • Антипаттерны для поиска соискателей
    +2
    про паттерны я обычно отвечаю, что я как господин Журден, который не знал, что разговаривает прозой. Но как-то удосужился просмотреть список паттернов и нашел в нем только полтора, которые следовало бы изучать — Visitor и MVC. Остальные нормальный программист переизобретет, как только они ему понадобятся.
  • Каково это — быть разработчиком в России, когда тебе сорок
    +1
    они все думают, что в 46 станут большими начальниками. А кто не стал тот лузер.
  • Персона. Джон Бэкус — создатель первого языка программирования высокого уровня
    0
    «Идеи, использованные в языке FP, были использованы при создании языка LISP» — это ж надо было такое написать. FP — 1977, LISP -1958 год.
  • Советские «Эльбрусы» — обзор архитектуры
    0
    Я сам слушал лекцию Бабаяна, где он говорил про переименование регистров, то ли в Э-1, то ли в Э-2. А вы про который рассказываете?
  • Закат Stack Overflow
    +3
    Это вы тут пытаетесь передергивать, утверждая, что якобы «отрицать наличие» это не то же самое, что «утверждать отсутствие».
  • Закат Stack Overflow
    0
    Я полагаю, проблема 95/5 настолько сложна, что одним каким-то способом ее решить невозможно. Если «отторжение дефективных» в каком-то виде поможет ее решить, его надо применять. Например, минусовать ръяных минусователей с пометкой, чтобы всем было видно, что это тролль. И вообще, я за то, чтобы свою схему расчетов репутаций и прав могло ввести любое достаточно значительное подмножество пользователей, не лишаясь доступа к общей базе вопросов и ответов.
  • Однажды программисты погубят этот мир
    0
    «Сколько недо-продуктов будет нас окружать?»
    Так уже.
    Домашний компьютер, Windows 10: выдает тихий звук. Переустановка драйвера возвращает звук в норму. На следующий день опять тихо.
    IDE Eclipse for Java Developers: раз в несколько дней зацикливается, приходится убивать процесс.
    Лифт в здании, где я работаю: иногда отказывается везти на 4 этаж.
    Накачал музыкальных обучающих программ — ни одна не работает как следует.
  • JIT-компилятор оптимизирует не круто, а очень круто
    –7
    А они и работают быстро. Отстают от С++ в 1.5...2 раза: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=gpp
  • Война задержек: Почему низкая задержка так важна?
    0
    Нет, не из-за спекулянтов. Успешный спекулянт покупает на минимуме цены и тем самым минимальную цену поднимает, продает на максимуме и тем самым максимальную цену сбивает. То есть, без спекулянтов скачки были бы еще больше.
  • Война задержек: Почему низкая задержка так важна?
    +1
    Раз случайное блуждание, то с вероятностью 50% будет выигрыш, и 50% проигрыш.
    Если же вы почти гарантированно совершаете сделку на невыгодных условиях, то вот вам алгоритм: совершайте обратную сделку, покупку вместо продажи и наоборот. Если вам именно необходимо продать, то сделайте покупку бОльшего объема, и покроете убытки с лихвой.
  • Война задержек: Почему низкая задержка так важна?
    +1
    Любой запрет на торговлю приводит к тому, что либо повышается цена покупки, либо понижается цена продажи, либо то и другое вместе. Ваше «исправление ошибки» ударит по карману продавцов и/или покупателей. Соответственно, нынешний заработок спекулянтов можно рассматривать как компенсацию за то, что они улучшают цены.
  • Как не стать программистом или… тебе здесь не место
    +1
    статистический анализ, было сказано. Анализируется статистика выполнения программы в рантайме и под нее модифицируется машинный код, например, инлайнятся процедуры.
  • Использование android.os.Binder для организации асинхронного взаимодействия в Андроиде
    0
    а способ, описанный в github.com/stephanenicolas/robospice — он что, некорректен или неуниверсален?
  • Реактивные расширения
    0
    CRP у вас это что?
  • Реактивные расширения
    +1
    «В процессе развития программного обеспечения возникла потребность, чтобы система умела реагировать на множество источников данных, была устойчива и чтобы разные модули не были тесно связаны».

    Можно подумать, в первые 50 лет развития программного обеспечения не было потребности, чтобы системы могли реагировать на множество источников данных и т.п.

    Во всей этой reactive движухе, кроме болтологии, единственная здравая мысль — это мысль о необходимости backpressure, то есть обратной связи для предотвращения переполнения памяти в случае, если поставщик работает быстрее потребителя.
  • Как я нашел лучший в мире язык программирования. Часть 2
    0
    Только вот запустить и передать данные в изолят накладнее, чем в другой процесс ОС.
  • Как я нашел лучший в мире язык программирования. Часть 2
    +11
    За троллинг ему надо было влеплять заслуженный плюс.
  • Как я нашел лучший в мире язык программирования. Часть 2
    0
    пареллелизма в них нет настоящего.