Согласен. Я старался ответить тем, кто в комментариях выражал разочарованность Вашим разочарованием, которое, в свою очередь, мне показалось преувеличенным, так как "кодеров" нужно существенно меньше, чем "инженеров".
Ощущение такое, что получилось "из пушки по воробьям". Но качество Ваших опросника и статьи меня восхитили!
Думаю, численность "Офиса языка GO", может состоять из 1-2 человек, проводящих семинары для "инженеров" и, возможно, ревью кода. И тогда им нужно обладать еще массой других качеств, уже даже не технических.
"найти человека, который сможет задать и поддерживать высокий уровень профессионализма в применении языка Go"
Звучит (в купе с содержимым и размером опросника), как поиск человека не на конкретные проекты, а в так называемый "Офис языка GO" по аналогии с "Проектным офисом", который не реализует конкретные проекты, а следит за корректностью и (возможно?) эффективностью применения практик управления проектами.
В своей практике найма я разделял разработчиков на "инженеров", которые могут решать задачи клиентов, системно мыслить, и на "кодеров", которым нравится именно кодить решения, искать "красивые" в их понимании формы записи решений на языке программирования. Совмещение и того и другого в одном человеке не так уж редко, но бывает. Опросник в этой статье больше подходит для отбора "кодеров", на мой взгляд.
Это алгоритм поиска, который работает только в отсортированном списке. На вход отдаём отсортированный список, а на выходе получаем позицию нужного нам элемента, если он присутствует в списке.
Только что выше определили структуры данных массив и связный список, а алгоритм поиска вводим на «списке»… Думаю, не-Java программистов это собьёт с толку.
Ваша оценка стоимости труда FPGA разработчика несколько занижена. Во-первых, уровень оплаты того, кто способен качественно и быстро решить (самостоятельно качественно спроектировать и запрограммировать, учитывая риски и планы развития и т.п.) задачу стоит дорого независимо от используемой технологии. Во-вторых, сложность/скорость разработки под FPGA в несколько раз (по нашим оценкам — около 6) выше. Поэтому в совокупности стоимость FPGA решения получается существенно выше.
Как показывают наши замеры HFT вполне может существовать в мире C/C++. Но в то же время, наши замеры показывают, что достаточно на 500 наносекунд быстрее реагировать на сигналы с биржи, чтобы она обрабатывала заявки раньше других (пришедших позднее) в 75% случаев. Таким образом, вложив несколько десятков или сотню тысяч долларов (стоимость сервера, сетевой карты и разработчиков) можно получить решение с задержкой 2-4 микросекунды и встать в один ряд с множеством других, кто может себе позволить такие же расходы (справедливости ради нужно признать, что еще необходимы правильные знания и опыт, чтобы сделать или организовать разработку действительно быстрого решения в разумные сроки). Но чтобы вырваться из этой достаточно многочисленной когорты нужно переходить на FPGA.
Вы правы. PureFPGA — это реализация ВСЕЙ стратегии в FPGA на языке проектирования аппаратуры, например, на Verilog. Этот вариант самый быстрый с точки зрения задержек, но и самый долгий и дорогой с точки зрения разработки. CEPappliance имеет свой язык HLL, который упрощает программирование, но платой за упрощение является некоторое увеличение задержки. В этой статье мы сравниваем по задержкам варианты реализации простого алгоритма на HLL и на Verilog.
Да, у нас опыта работы с Altera больше. Мы хорошо знаем сильные и слабые стороны их чипов/плат/софта. Хотя Xilinx, по нашим оценкам, несколько дешевле, мы предпочли не менять проверенного в бою коня.
1. Мы не разглашаем эту информацию.
2. Скорость реакции переменная, так как во входящем сообщении может быть переменное число обновлений стакана.
Один такт составляет какое-то не круглое число наносекунд. Количество тактов — тоже не круглое число. Одно на другое и дает нам число с единицами наносекунд.
Сроки и стоимость реализации проверок (логики?), а также скорость их работы, зависят от сложности проверок и того, кто их будет реализовывать. Не существует обобщенной адекватной оценки.
Согласен с тем, что стратегия должна быть не только быстрой, но еще и умной. Насколько нам известно, HFT стратегии довольно просты и стремятся быть безрисковыми. А зарабатывать с малым риском хотят многие. Отсюда и высокая конкуренция, высокие скорости. И, как отмечено в конце статьи, при торговле на Московской бирже даже полмикроскунды дает преимущество. Это мы затронем в нашей следующей статье.
Сроки и стоимость реализации проверок (логики?), а также скорость их работы, зависят от сложности проверок и того, кто их будет реализовывать. Не существует обобщенной адекватной оценки.
Согласен с тем, что стратегия должна быть не только быстрой, но еще и умной. Насколько нам известно, HFT стратегии довольно просты и стремятся быть безрисковыми. А зарабатывать с малым риском хотят многие. Отсюда и высокая конкуренция, высокие скорости. И, как отмечено в конце статьи, при торговле на Московской бирже даже полмикроскунды дает преимущество. Это мы затронем в нашей следующей статье.
Почему же вы так упрощаете отношения людей? Человек это объект с неизвестным иррациональным поведением.
В общем случае — да, действительно, не так просто.
Но человек в коллективе, с которым Вы договорились играть по определенным правилам, как бы встроили в систему, подключили, не так уж и иррационален. Он знает, что от него ждут и что он может ждать от других. И он может через это сам себя оценивать (обратная связь) и корректировать свои действия. Далее все зависит от его/ее опыта, эмоциональной зрелости, воспитанности. Не нужно забывать, что не только руководитель может предъявить претензии о несоблюдении правил игры, но и члены коллектива могут предъявить их руководителю и другим членам команды (иногда такие отношения обретают даже формализованный вид, называются ретроспективами — чтобы коллектив не забывал о своих правах). Если человек идет сознательно (понять это — задача руководителя) на нарушение правил, то справедливо может ожидать, что в отношении него будут применены какие то корректирующие действия. Важно, чтобы правила были прозрачны. И одинаковы для всех. Обеспечение этого — задача руководителя.
Часто за иррациональным поведением (как нам оно видится со стороны) скрывается непонимание/незнание/неумение (тех. навыки), неудовлетворенность.
Итак, коллектив — это система. Процессы — юзкейсы. Строим организацию коллектива — проектируем систему, разбиваем ее на подсистемы (разработка, тестирование и т.п.), модули (команды) и объекты (люди). Инкапсуляция — запрет на микроменеджмент, взаимодействие через интерфейс желательно с известными пред- и постусловиями, инвариантами (контрактное программирование). Нагрузка на команду высокая — вводим балансировщик. Команда продуктовая (должна жить долго) — внедряем DR, дублирование…
Рассматривайте работу Вашего коллектива как совокупность юзкейсов или процессов, а людей — как объекты, которые их реализуют.
Процессы — это правила игры, а Ваш коллектив — группа людей, которая в нее играет. Все должны знать правила и следовать им. Вы создаете эти правила, как отражение накопленного Вами и командой опыта, и обеспечиваете их соблюдение, наблюдаете с судейской вышки и думаете, нужно ли что-то менять…
Разработка и внедрение процессов — вполне технические задачи. Согласны?
Например, то что я описал в предыдущем комментарии о доверии, можно рассматривать как юзкейс/процесс «Адаптация новичка» («Внедрение нового модуля/функционала в работающую систему»).
Как обеспечить соблюдение правил? Следование правилам — это в некотором смысле естественная потребность людей, потому что при наличии правил понятно, что ждут от тебя и что ты можешь ждать от других. Нужно только убедиться, что правила разумны, честны, понятны и подъемны. И не бояться их менять, если пришло время.
И где то там в облаках летают мотивация, эмоциональная зрелость, навыки Ваших людей и т.п. Без учета всего этого будет трудно поддерживать боевой дух в коллективе.
Управлять одному такой командой можно, если больше ничего делать не нужно (например, взаимодействовать с заказчиком), но сложно, так как объём задач, выполняемых такой командой, вряд ли уместится в одной голове.
Идеальный вариант — две команды с тимлидами, чтобы обеспечить одинаковую приближенность к руководителю (себе). Опять же возможность карьерного роста в коллективе (если корп. культура позволяет).
Оценкой своих людей и подбором новых людей в свою команду должны заниматься тимлиды. Иначе вряд ли его/ее будут воспринимать, как руководителя. Про доверие уже поговорили ниже: )
Мне кажется, чем быстрее хорошие технари приходят к тому, что их тех.навыки применимы и в управлении людьми, тем быстрее они становятся хорошими руководителями.
Например, вопрос доверия… Какому ПО мы доверяем больше? Которое успешно прошло тестирование. Особенно, если сценарии написали мы сами (как самые опытные, знающие и т.п.) или кто-то, кому мы доверяем. Так и с человеком. Новичку можно дать задачу и выяснить, как он с ней справляется. Конечно, наши первоначальные ожидания о качестве работы человека, сформированные в ходе собеседования, должны подсказать насколько критична должна быть задача и какой контроль нужно обеспечить на период тестирования новичка.
Трудно сходу довериться новичку. Да и доверие ценится сотрудником выше, если оно заслужено. Поэтому начинать путь к доверию нужно с малого.
Про «как» все же немного есть, как мне кажется. Это слово можно было бы взять в скобки, занизив тем самым его значимость, но не в заголовке. А ничего лучше не придумали, хотя и потратили на это время — опыта еще мало.
Как получили ровно в 2 раза медленнее при деградации на 1% в день за 100 дней?
Согласен. Я старался ответить тем, кто в комментариях выражал разочарованность Вашим разочарованием, которое, в свою очередь, мне показалось преувеличенным, так как "кодеров" нужно существенно меньше, чем "инженеров".
Ощущение такое, что получилось "из пушки по воробьям". Но качество Ваших опросника и статьи меня восхитили!
Думаю, численность "Офиса языка GO", может состоять из 1-2 человек, проводящих семинары для "инженеров" и, возможно, ревью кода. И тогда им нужно обладать еще массой других качеств, уже даже не технических.
Звучит (в купе с содержимым и размером опросника), как поиск человека не на конкретные проекты, а в так называемый "Офис языка GO" по аналогии с "Проектным офисом", который не реализует конкретные проекты, а следит за корректностью и (возможно?) эффективностью применения практик управления проектами.
В своей практике найма я разделял разработчиков на "инженеров", которые могут решать задачи клиентов, системно мыслить, и на "кодеров", которым нравится именно кодить решения, искать "красивые" в их понимании формы записи решений на языке программирования. Совмещение и того и другого в одном человеке не так уж редко, но бывает. Опросник в этой статье больше подходит для отбора "кодеров", на мой взгляд.
Только что выше определили структуры данных массив и связный список, а алгоритм поиска вводим на «списке»… Думаю, не-Java программистов это собьёт с толку.
2. Скорость реакции переменная, так как во входящем сообщении может быть переменное число обновлений стакана.
Один такт составляет какое-то не круглое число наносекунд. Количество тактов — тоже не круглое число. Одно на другое и дает нам число с единицами наносекунд.
Согласен с тем, что стратегия должна быть не только быстрой, но еще и умной. Насколько нам известно, HFT стратегии довольно просты и стремятся быть безрисковыми. А зарабатывать с малым риском хотят многие. Отсюда и высокая конкуренция, высокие скорости. И, как отмечено в конце статьи, при торговле на Московской бирже даже полмикроскунды дает преимущество. Это мы затронем в нашей следующей статье.
Согласен с тем, что стратегия должна быть не только быстрой, но еще и умной. Насколько нам известно, HFT стратегии довольно просты и стремятся быть безрисковыми. А зарабатывать с малым риском хотят многие. Отсюда и высокая конкуренция, высокие скорости. И, как отмечено в конце статьи, при торговле на Московской бирже даже полмикроскунды дает преимущество. Это мы затронем в нашей следующей статье.
В общем случае — да, действительно, не так просто.
Но человек в коллективе, с которым Вы договорились играть по определенным правилам, как бы встроили в систему, подключили, не так уж и иррационален. Он знает, что от него ждут и что он может ждать от других. И он может через это сам себя оценивать (обратная связь) и корректировать свои действия. Далее все зависит от его/ее опыта, эмоциональной зрелости, воспитанности. Не нужно забывать, что не только руководитель может предъявить претензии о несоблюдении правил игры, но и члены коллектива могут предъявить их руководителю и другим членам команды (иногда такие отношения обретают даже формализованный вид, называются ретроспективами — чтобы коллектив не забывал о своих правах). Если человек идет сознательно (понять это — задача руководителя) на нарушение правил, то справедливо может ожидать, что в отношении него будут применены какие то корректирующие действия. Важно, чтобы правила были прозрачны. И одинаковы для всех. Обеспечение этого — задача руководителя.
Часто за иррациональным поведением (как нам оно видится со стороны) скрывается непонимание/незнание/неумение (тех. навыки), неудовлетворенность.
Итак, коллектив — это система. Процессы — юзкейсы. Строим организацию коллектива — проектируем систему, разбиваем ее на подсистемы (разработка, тестирование и т.п.), модули (команды) и объекты (люди). Инкапсуляция — запрет на микроменеджмент, взаимодействие через интерфейс желательно с известными пред- и постусловиями, инвариантами (контрактное программирование). Нагрузка на команду высокая — вводим балансировщик. Команда продуктовая (должна жить долго) — внедряем DR, дублирование…
Процессы — это правила игры, а Ваш коллектив — группа людей, которая в нее играет. Все должны знать правила и следовать им. Вы создаете эти правила, как отражение накопленного Вами и командой опыта, и обеспечиваете их соблюдение, наблюдаете с судейской вышки и думаете, нужно ли что-то менять…
Разработка и внедрение процессов — вполне технические задачи. Согласны?
Например, то что я описал в предыдущем комментарии о доверии, можно рассматривать как юзкейс/процесс «Адаптация новичка» («Внедрение нового модуля/функционала в работающую систему»).
Как обеспечить соблюдение правил? Следование правилам — это в некотором смысле естественная потребность людей, потому что при наличии правил понятно, что ждут от тебя и что ты можешь ждать от других. Нужно только убедиться, что правила разумны, честны, понятны и подъемны. И не бояться их менять, если пришло время.
И где то там в облаках летают мотивация, эмоциональная зрелость, навыки Ваших людей и т.п. Без учета всего этого будет трудно поддерживать боевой дух в коллективе.
Идеальный вариант — две команды с тимлидами, чтобы обеспечить одинаковую приближенность к руководителю (себе). Опять же возможность карьерного роста в коллективе (если корп. культура позволяет).
Оценкой своих людей и подбором новых людей в свою команду должны заниматься тимлиды. Иначе вряд ли его/ее будут воспринимать, как руководителя. Про доверие уже поговорили ниже: )
Например, вопрос доверия… Какому ПО мы доверяем больше? Которое успешно прошло тестирование. Особенно, если сценарии написали мы сами (как самые опытные, знающие и т.п.) или кто-то, кому мы доверяем. Так и с человеком. Новичку можно дать задачу и выяснить, как он с ней справляется. Конечно, наши первоначальные ожидания о качестве работы человека, сформированные в ходе собеседования, должны подсказать насколько критична должна быть задача и какой контроль нужно обеспечить на период тестирования новичка.
Трудно сходу довериться новичку. Да и доверие ценится сотрудником выше, если оно заслужено. Поэтому начинать путь к доверию нужно с малого.