• 목록
• 답변
• 글쓰기
• 게시판 리스트 옵션
  • 수정
  • 삭제

이 문제를 해결하고 더 나은 하위 키를 선택하기 시작한 후(ID와 수정된 타임스탬프를 추가하는 것이 실제로 필요한 전부입니다. Rails 러시아 인형 캐싱과 동일) UI가 상당히 깔끔해졌습니다. 저는 Rails를 좋아하고 이를 사용자 지향 웹 애플리케이션에 사용하지만, 증권 거래소를 구축하는 데에는 Rails가 올바른 선택이 아닙니다. DHH는 내가 가장 좋아하는 스택(Javascript가 포함된 Rails)의 최적 지점을 "일부 동적 요소가 포함된 문서"라고 설명합니다. 나는 그 모델을 정말 좋아하지만 거래 인터페이스를 설명하지는 않습니다. 우리는 또한 특히 양적 거래보다는 일반적인 엔지니어링 기술에 주로 관심이 있습니다. 그렇다면 예를 들어 Sinatra 대신 Go를 서버로 사용하는 이유는 무엇입니까? 왜? 글쎄, 거래에서 많은 재미있는 엔지니어링 문제는 실제로 주문을 보내는 경우가 안정적이지 않고 "가격"에 문제없이 일치하기 때문에 발생합니다. 시장은 분산 시스템입니다. 그렇다면 왜 금융업을 시작해야 할까요? 나의 공동 창업자인 Thomas와 Erin은 경력 동안 실제 증권 거래소를 확보하는 데 상당한 노력을 기울였지만 나는 금융에 대한 특별한 배경 지식이 없습니다. 예를 들어 RPG나 전략 게임 등을 만들 수는 없었나요? 다른 거래가 반응하기 전에 세계 시뮬레이션에서 생성된 뉴스에 대한 정서 분석이나 거래와 같은 작업을 시도해 볼 수 있습니다. 하지만 에헴, 엄밀히 말하면 우리 레벨에서 만든 모든 것이 합법적인 것은 아닙니다. 우리 거래 레벨의 설계된 작업은 "플레이하고, 끔찍하게 지고, 프로그램을 작성하고, 레벨을 재설정하고, 프로그램을 실행하고, 버그로 인해 충돌이 발생하고, 수정하고 다시 실행하고, 김프 적당히 지고, 접근 방식을 조정하고, 다시 시작하는 것입니다. 레벨을 맞추고, 프로그램을 실행하고, 승리하세요." (사람들은 우리가 이 문제를 당신에게 고소할 것인지 물었습니다.

서버가 맹렬한 불 속에서도 쓰러지지 않을 것이라는 신호를 보낸 후 즉시 공개적으로 출시할 것입니다. 소품 가게가 많아요. 하이브리드 기술/금융 회사는 회사의 돈을 사용하여 알고리즘 방식으로 거래합니다. 이는 나노초 단위가 아닌 며칠 단위의 시간 척도를 갖습니다. 우리의 주문서와 교환 서버는 작동해야 하는 것처럼 작동하므로 구현 세부 사항에 대해 알려드리게 되어 기쁩니다. 실제 레벨을 발견하는 것은 매우 재미있기 때문에 자유롭게 실제 레벨을 망치지 않고 설정, 인프라 및 디자인 목표에 중점을 둘 것입니다. CTF 개발의 일반적인 패턴은 "이 장난감 인터페이스에 맞는 프로그램을 만드는 것"입니다. 플레이어 측의 많은 작업에는 해당 인터페이스(그리고 종종 문서화되지 않은 단점)를 이해하는 것이 포함됩니다. 대부분의 CRUD 앱보다 더 많은 일이 진행되고 있기 때문에 우리는 React에서 UI를 만들었습니다. 시장은 가격 신호를 모으는 메커니즘이며, 상대적으로 정교하지 않은 개별 행위자로 구성되어 있어도 놀랍도록 정교한 동작을 보입니다. 시장이 내부 논리에 맞춰 춤을 추는 것이 중요하지만 그 논리가 특별히 복잡하다는 것은 덜 중요합니다. 그들의 개별 명령(및 그 이면의 논리)은 인간이 합리적으로 따를 수 있는 것보다 빠를 수 있지만 여전히 HFT는 아닙니다. GM의 레벨 오케스트레이션 로직은 실제로 Ruby로 쫓겨났습니다. 주로 Go를 개발하는 것보다 Ruby를 훨씬 빠르게 개발하고 이 코드가 증권 거래소보다 성능 집약적이지 않기 때문에 어느 정도 유연성이 있었기 때문입니다. 버튼을 누르고 주문이 거래소에 도달하는 사이에 봇이 REST API를 눌러 주문을 취소했습니다.