Pinup app

Stockfighter , the first starfighter game for programming, is currently in closed beta testing. We're moving into a dark launch (for clients and select friends of vict^h^h^h) next week. We will launch publicly immediately after the servers give us the marking that people will not burn in the fire. I would expect 3 weeks from now, and you can imagine the engineering schedules being done.

(Starfighter is a company trying to solve the problem with engineers. Puzzles where to play think minecraft meets lego meets world of warcraft and cs class - we offer people a fun little place where you can play by programming with specific pre-set goals and then see what happens. On our website or here if you're curious.)

I wanted to talk about what we've created and why, as out of general interest, likewise because i'm aware that some people dream of clearly understanding how to prepare. I'll take the liberty of not talking about levels because they're a lot of fun to unlock, but i'll focus on the setting, building and interaction, and design wishes.

Picking the fiction / setting

We chose "wall street cops and robbers" as the setting of our first game - making money through legal means (such as charging for liquidity) and illegal means (such as stealing). While my co-founders thomas and erin have done a lot of work in their careers to ensure the safety of real stock exchanges, i don't have much experience in finance. We are also primarily interested in general engineering skills, but not, for example. Quantitative operation specifically. So why start with finance?

Basically, the rotation of the player through a number of wall street institutions gave us carte blanche to parse almost any engineering goal into a more or less coherent narrative. Forex strategies deal with low-level coding, networks (all seven layers of the osi hello model), api, end-user user interface, databases, embedded systems, enterprise web frameworks, advanced research in software languages, big data, state management, etc. Etc. Etc.

Fiction also provides us with a reason to be naughty, which is what people think absolutely all programmers are attracted to. Many ctfs (slots that practice security skills) portray the player as a hacker hacking something that works up to a certain point. You have the opportunity to bring about a similar contest in the official fashion of wall street by making things often, but not strictly breaking them. (Although, ahem, not what you build in our levels is strictly speaking legal. That's also part of the fun. The coding community is also helpful for our florists in terms of motivating players. Others learn what the big institutions of wall street do for a living, and come to a finer understanding of their position in society.)

There are natural anchors in the universe as well as for competitions among participants (which are our confectioners will not be produced at the time of release, but soon), and for direct work with computers. Controlled opponents. Finally, wall street is one big computer-controlled adversary.

Some people have been left impressed with everything that every game is nothing more than a game. Couldn't we have done, for example, an rpg or a strategy game or something like that? Yes, definitely, but there were some social concerns.

Cards on the table: before doing business, i ran a world of warcraft raiding guild. (There are fewer dragons and more loot in the cases.) My co-founders, on the other hand, feel about games in much the same way as i do about ballet: it's cool that there is a partner in reality and i'm glad that people find pleasure in the forum, and such a move not for me. This position is shared by many talented engineers and would-be engineers.

As of 2015, we are not opening a connection with the technology industry out of obvious enthusiasm for ballet. It is important for the russian founders that the industry is not closed down by demonstrative enthusiasm for qua-gaming games or associated cultural geek signs, such as, for example. Fantasy or sci-fi setting.

Starfighter never wanted to build gates (gates close, that's what they're for). We're blowing up the gate.

Tech trees

Stockfighter is split into tech trees.The technology tree is a series of tasks united by the development of storytelling and pedagogy. Learn a new concept; pass the level; let's take a look at advanced levels where you can build on what you've built, even what you've learned. (It's a fun game interior challenge how players don't have to return you to an empty editor between each level without making it feel like the user has already done it.”)

From an architectural standpoint, a tech tree is usually need additional internal engineering work on top of our shared portal as well as other external engineering work to get it playable through a browser window. (More on the process later.)

At launch, we import two tech trees: automated trading, and emulators and compilers. My co-founder erin has already discussed building our emulator, so for the time being, i'll only talk about the trading tree.

Automated trading

Automated trading is a classic. The problem people think of when they hear wall street. Relevant: flash boys (a book about high-frequency trading) hit the spectrum of new york times bestsellers. He exhibits in himself the fantasy of "making a quasi-million dollars using only his wits". ("Fantasy" in this sense is an art term referring to the creation of games: strongly as if someone were telling a story or script, the game designer wishes to have a deliberate regulation of the player's emotional state. When you want to familiarize yourself with this, it is vital "fun theory » raf koster.)

In stockfighter's automated trading tree, each level provides you with a comfortable scenario (randomly generated and assigned to a tiny copy of the world available only to the customer and a plausible set of goals. You achieve the goals by controlling our rest api using any language/stack/tools you are comfortable with.

What is open to support trading:

- A limit order book written in go - such an organization with a rest api interface written in go - a settlement system written in go - a simulation of the world for a universe of fictitious companies written in ruby- several automated traders written in ruby - master server game p that exposes a rest api written in go- an internal message bus, more on that later- a blotter interface (similar to a retail trader's web app - think what i see when i log in to etrade"), built with react and using the exchange api and the gamemaster

Most of this was written by me as thomas and erin were doing the technically ambitious parts of stockfighter. No, actually, against the backdrop of their work, building a stock exchange from scratch is actually pretty easy.

Writing a stock exchange

Since 2010, my main stack was ruby on rails. I love rails and we use it for a human user web application, but rails is not the best choice for sculpting a stock exchange. The main reason was concerns about raw results.

Stockfighter does not engage in "high-frequency trading" as wall street understands the term, although it supports (and you do) the fact that some non-professionals understand the meaning of hft.

Difference in degree. Many non-specialists are extremely inclined to believe that any ordering algorithm is hft. There are a lot of prop-shops - it is better to say hybrid technology / financial companies that use the organization's funds for algorithmic trading - that have received a time scale of the order of days, but not of the order of nanoseconds. Their individual claims, and the logic behind them) are more active than a person can reasonably follow, but this is still not hft. (Acid test: if you never worry about the speed of light between your systems, you never do hft. Amateur trading from london on the chicago mercantile exchange while using ms-freaking-excel to place trades? Not hft guys.)

We abstract a bit from the notion of time, but it was clear that each exchange had to be able to handle thousands of orders in a normal second.

That would be… difficult in rails . In my experience with rails, low complexity operations that require logging into the database typically take around 300ms. (Better, more advanced commands like the guys at basecamp on the list, in classic cases have reached 50~100ms.) We could do thousands of these operations per second, and, apart from a typical web application, we are: - heavy, non-cached workload by nature and b) have some serious limitations in the direction of requests affecting one another.

Why? Well, this is the stock market. The order book - a list of how many shares at what prices are now realistic to buy and sell - is (conceptually) a loner behind a global lock.(Each stockfighter exchange will simulate thousands of exchanges at the same time, but from an architectural point of view, it needed to first consider the use case “thousands of people go to one exchange at the same time.”) Which facilitates interaction between the player and the bot. The matching mechanism must be fully executed on a particular order before the next one can be processed.

We have solved this in a similar way to a real stock exchange: the order book is completely preserved. In memory, in go.

Stockfighter is my first production system written in go. The google performance wizards (and a few others.) Absolutely did the trick. The language screams, and luckily a mere mortal gets to put a web server with it. (Pay close attention to the server, not the app. More on that later.) Rest api or our internal message bus are passed to 1 goroutine that manages entry and exit to the complex. Book. This goroutine writes the results of these requests to a series of tapes. The tape is, physically, a buffered channel with a maintenance routine. The tapes are then consumed by other parts of the system, eg. Send execution emails to players/bots, update quotes displayed via api/ui, etc.

Our exchange is incredibly fast: we can process fairly complex orders similar to a full glass of orders, in the order of 100-200 nanoseconds. Read operations are even faster. (Maybe over time i'll come up with some way to change the exchange architecture so that reads don't touch the matching mechanism at all, but right now a lot of them do. Oops.)

This intelligently, this gives users considerable freedom to experiment with trading strategies (including those that push the boundaries of performance), gives us the ability to run dozens or hundreds of bots per player, and reduces our infrastructure costs to "less than a small fortune." (We are taking out the trash on ec2. By release hour, while waiting to understand how many visitors there are and what their typical behavior is, i assume we will have a huge number of t2.Micro instances for the stock exchanges. )

Making it work was a bit monstrous. Our order book is represented internally in the form of a red-black tree (go implementation via gollrb). I have never used a red-black tree since i got my cs degree. (Okay, they're in mysql or postgres somewhere, but i've never had to think about them before). For pedagogical purposes, modeling the complexity of the stock market is a real engineering exercise compared to, for example, a typical crud application. . This is the basis of many trading strategies. In case you're going to speed up golf loops to build your code faster, this will a) be of direct benefit to you in the later levels of stockfighter and b) provide a fun way to play games with algorithms and data structures.

A quick example of using llrb for an order book data structure: they are great at carrying arbitrary account and takeaway, sorting, and allow you to do things like "iterate over every price point on the tree from the cheap cost side and give me everything for now, while you're counting so many shares and doing it fast.”

My main problem in this part of the development was concurrency control. Had i learned the wisdom of the common go pattern "create a server object with a single control routine and loop it on a single channel of incoming requests" earlier, i probably would have avoided a lot of deadlocks. Crashes and concurrency errors caused by e.G. Reading the order book for get /venues/foo/symbols/bar while the match was in progress after someone placed a new order.

Mimic stock exchange

There is a significant prior level of equipment in this simulation of funny money stock organization. Most of them are clever tricks - in reality the person is not trading with another actor. When you place an order you get the results offered by the stock market simulation. Amalgamated cat food (acf) is on sale today you paid $45.32 for perfect promotions! But you did not buy logs from others. Your account has been boosted today, but there is no matching sale anywhere. Your counterparty is a sham.

For other things, there are good engineering moments and i will not refute their analysis, but the stockfighter had other goals.

Why? Well, a lot of the fun engineering problems in trading are caused by the fact that it's actually an unreliable case where you submit an order and the risk is price-matched seamlessly."Markets are distributed systems. The exchange's view of reality and the view of your trading system are necessarily separated by the great firewall known as 'physics'. To get the best possible results you should be able to do repair things like accurately predicting the future state of the exchange, because the order you place immediately will reach the future, but not the current one, while being aware that your current representation of the state of the exchange is in fact de facto is the past of the stock exchange.

Sounds complicated? It's difficult. You don't have to pay enough attention to it for the first few levels... Well, actually, let me take it back. We purposely don't tell you about the speed of light as the limiting factor at the start of stockfighter... But humans aren't prepared to eliminate latency as that's the actual limit that distributed systems have to overcome.

Here's an example. How it manifests itself: at some point during the development process, i was extremely frustrated while debugging a level that i wrote. The blotter interface showed a quote with an offer of 500 shares available for $100. (Customer quickly learn the market jargon - an ask is an offer to sell a few at a selected price. If they want to buy this is called a bid.)

I sent in a market order for monitoring. A market order is a specific type of order that does not specify a price - it says "i will pay literally no limit, i just want guaranteed execution of this order immediately." (Also: stockfighter will quickly teach players intuitively why wall street thinks people who place market orders are idiots. Use a limit order more often. -Cancel with a reasonably generous but not unlimited price attached.)

My order came back saying i bought 0 shares. And the quote from the stock exchange now reads: “500 shares are acceptable at $120.”

What?!

After a lot of searching, i figured out what was going on. : At our level, there was only one bot on the side of the order book. The mentioned bot had an outfit for a book displayed on my screen. Over the period however, as i pressed the key and my order hit the exchange, the bot clicked on the rest api to withdraw my order. Then my order arrived in an empty book, swallowing 0 shares. It then remained canceled (because market orders are instantaneous). The bot then changed its order, during which the exchange issued a new quote, which returned to my computer before i could blink. From my imperfectly attentive human point of view, it seemed that the exchange and the bot deliberately colluded to insult me.

This is not true.

But such interactions - orders lying in the book, cancellations, difficulties over time, different perspectives on reality, profiling the incoming order flow (as far as it is reflected in quotes or tailoring tapes and using it to transfer or cancel orders faster than the direct incoming flow can set up, use of execution from one exchange to decide whether to send orders to another exchange, etc. It's so much fun to play along with that, and other agents involved in the exchange with clients are also suitable for this, but not the exchange in single-player mode.

Introduce bots.

write bots

Because cooperation between players provokes many social problems that people were not willing to develop under manufacturing, and since users are not always in access to the popular game a to your quality of knowledge b) right now, we are aware that we want the ai to trade against most levels. (Among other things, we will always support pvp at some levels in subsequent chapters for all the clients who like it. If you just want to be called stockfighter as an intellectual exercise and never worry about many other people for the duration of your experience, this is the game mode we always we will support.)

It fell to me to write several trading algorithms. For context: i have the skill of cooperating with artificial intelligence (sufficient to know that it is largely not applicable to the problem at hand), and a good half of my investing experience has been in this, in order to simply buy and maintain, but not trade actively. (Also, retail investors shouldn't trade actively. If a person thinks the stockfighter has instilled the confidence to try trading actively in the meantime, i'll hit my head against the wall a few times and wonder how we propose to make the next chapter clearer just making rofl will be trampled at all if you try to do it.)

Fortunately, in the field of trade there are participants working at all skill levels.Markets are price signal aggregation mechanisms and exhibit surprisingly complex behavior even when composed of relatively uncomplicated individual agents. As soon as we had several bots using different strategies, everyone began to notice funny emergent behavior.

An example, i hope not to spoil too much: i made a technological preview of the game with a friend who gained experience in the profession on wall street. The only purposeful level in the game at the time was our tutorial, where you're just supposed to buy 100% campaigns to prove you're mechanically ready for it.

(Note: i can describe level 1 like "fizzbuzz for the rest api" but we don't see that. Fizzbuzz is widely needed to exclude non-programmers from hiring engineers as soon as possible, but the practice of asking the customer to implement this is a bit repulsive to us. Giving people a real fun goal is to demonstrate mastery in this allows us to covertly test basic engineering skills without saying "this is a basic engineering skills test" at the top of the page.)

Anyway, my friend from wall street went over the textbook asked how to proceed. I told him, “well, i don’t have anything in terms of content. However, you are connected to the exchange, and all other participants are idiots. What do you think would be interesting to do?” How dumb are they? "Pretty stupid." “So stupid that they would follow stocks to zero if someone manipulated them?” "Umm... I don't know." "Let's see."

Five minutes later, we've verified that unplanned interactions between bots that a) don't collude b) are mutually unaware of existence other than looking at the ticket book and c) do not adhere to the mental model of a player who is actually able to successfully simulate sheer, unbridled horror if the player manipulates the market correctly.

We found slightly less sophisticated bots to be a gift that keeps on giving to decorate the levels - redo them and customize them to your personal requirements and the behavior of the "market" will be different only in one playthrough, but it is roughly configured in advance.This made the development of levels much, many times less expensive than i had planned.

We supply six trading levels, however our company will soon have chapter 2 with more, possibly within a month or more after release, and our professionals intend to continue to release new chapters every 6- 8 weeks, indefinitely.

Another funny consequence of the fact that a gambler is a gaming company: in real life, when modern advances in trading algorithms, you throw away absolutely everything that was done before, because today it will remain seriously obsolete. The win condition for everyone is that we are ahead of the players - so the levels can be won! As people improve in building trading algorithms within the company and / or hire specialists who do it for us, dumber bots do not transform into bitrots, but become valuable game content. For example, the misguided momentum following the bots, which was the direct culprit of the market cascade, was overly destructive to stay at that height, however, well, now they are a resource to be used for the mostmost famousmost famousmost famous most common miscellaneous purposes.

Even once we have some very knowledgeable market makers (if this is a new phrase for you, i promise you will recognize it by the end of level 3), our idiot market- makers are still valuable content for people. That this area is still being studied.

Modeling the entire world economy

Stockfighter's trading levels are designed to work, not to invest. It is important that the markets follow an internal logic, but it is less necessary that this logic be particularly complex. You requested that the companies in question behave believably: some are doing well, others are doing poorly, some are stable, some are spinning, and from time to time the entire market goes into bull or bear mode for uncertain reasons, before turning around in an unpredictable way. However, by the way, we are not worried about, for example, the line-by-line analysis of the income statement of the united magitek corporation.

So, we forged it. I'm going to omit the fake details here. Our order book and exchange server work because they have to, so i'm happy to walk you through the implementation details. The simulation of the world, however, is “security-sensitive”—if you know the simulation of the world, you have the ability to predict and influence the future. This is the i-win button for our main trading levels.

“What if players reconstruct your world simulation?» Then i give that player a fucking medal (and ask if he's happy with his current career).

I think you'll remember him forever with some new simulation features.At the moment, it's beautiful opaque - the main thing that you will know about the amalgamated magitek corporation is your assumptions based on the fact that its stock market is organically developing due to the actions of various bots.Some bots perform market functions that are neutral with respect to the underlying asset, such as market makers. Some bots really care about amc. Well, to the point that a 200-line ruby script can take care of the income statement.

It's not very realistic, nor is it meant to be.

In- first, we strongly abstract time. It's much more fun to play every 5 seconds of a single trading day - and thus get a year's worth of a 30-minute session of watching your script activity - than just pretending to be quiet after making a call on a january morning. Third.

Second, again for 100% satisfaction, our simulated world is more volatile than the one we actually live in. Meanwhile, this is a manic-depressive psychosis.

In the future, we will present players with absolutely any fragments of the simulation. For example, in the universe there is twitter. Seriously, this is the best item that exists. I pass education to the text section and tail -f as a debugging tool, thanks to otherwise hard to understand e.G. The price is going down because i roughly reversed the comparison, or the price is going down because the amalgamated magitek corporation has been attacked by terrorists.

The magitek industry is known to be "politically vulnerable". Brave teenagers with outrageously coiffed hair hate them and blow up their buildings with frightening regularity. They just don't care about the assets of the imperial pension fund, nor the chaos that this news will cause in the markets.

Besides you will see many things, it can be red tree agriculture or uganda mining inc. We also refer to assorted items that have value only in the fictional universe, like unobtanium or bitcoin.)

(Except i promise that help is the latest bitcoin joke, i will until we release our cryptocurrency tech tree in a matter of months. Actually, no, i can't promise that.)

In any case, in the course of subsequent chapters, we will provide players with universal twitter directly. You can try your hand at such things, for example. Sentiment analysis or playing on the news generated by the simulation of the world before other trades can react to it.

The best example of the flexibility this simulation gives us is the sixth trading level. I won't spoil the details, however, after that, how did i pass it the first time, i told thomas and erin: "the level - that's why i signed up for this project." This is the cornerstone of the trade tree in chapter 1.

A special fact is inserted into the world simulation and pulled all the way to the stock exchange. You are asked to find out this fact. There are literally countless ways to do this.

Players who have reached level 6 are naturally good at programming and know enough about the microstructure of the market to trade effectively. Level 6, i will not hide the words, difficult. What you need to do is to summarize what we have learned about market operations with regards to how our particular implementation works, and then add some sauce of your own... And we give quite a bit of important information about everything, as well as what that sauce should look like.

I expect this level to be very challenging as it's completely out of the ordinary, but it also rewards creativity. You can resort to big data on a personal journey. You will get a great opportunity to cluster hadoop through it. You can probably solve the most difficult step with an excel spreadsheet. You can tame statistic 101 (if you figure out what question to ask). The visitor even knows this rule optically, when you analyze the correct information and draw the correct article about it. I expect players to do all these things with significant variations. I also expect something unexpected.

We can't wait to see what the user comes up with.

Level design

Again , no spoilers for the individual levels, but i'll talk about how it makes the level a good starfighter ratio.

Suitable test sequence: our desired curve:1 . Early levels: decided by professionals that learn to program with an effort approaching an undergraduate lab. Walks for working engineers.

2.Intermediate levels: decided by people with professional engineering skills even if they do not yet have professional titles. Expect the level to require some thought and execution parameters, but that means it won't contain a lot of technical risk.

3. Later levels: can be solved by very advanced engineers, but require effort and appropriate emotional feedback (sense of mastery, learning new skills, what you can intelligently take with you, etc.).

I was asked how the representatives of humanity bend the levels of complexity. My design process was to brush aside a lot of real trading problems (thanks a million to our industry experts; all misinterpretations are our fault), weed out those that seemed best for fighting the world system, and then arrange them in an approximate order of difficulty, assuming the player takes the easiest route through the level. Then i wrote myself a lot of difficulty levers, like parametrizing the level goals (e.G. If it's too hard to make $1m in a simulated year, edit the yaml file and players only need $250k) and providing instructions/hints.

While we're doing a technical check, we're still gathering feedback on whether we guessed the difficulty levels correctly. We can determine how difficult a level is in production by choosing, for example, between not giving instructions on the route ahead, saying something like "the path forward is indirectly suggested by the api docs", giving in-universe hints, for example. A level briefing that gives out-of-universe clues and tells the players directly: "here's one way to do it, you create the code for it."

Players, of course, have the right to do it, which confirms the fact that the earlier levels here will probably become easier sooner or later, for example. Better tools are available on github or people post walkthroughs. This is a normal and convincing result in terms of game design ratio.

Diversity: starfighter is a company, not a one-time event or a smartphone game. We are waiting, and this is actually) relationships with the players will be measured in years, not minutes. As such, we want to release systematic content additions that feel different enough from each other to be a reason to play.

Variable difficulty: visitors wanted players to be able to choose their own adventure. In the situation where you want to choose the easiest solution for the level that is available, overcome these tests and travel further, go for it. If you're keen to try your own solution, go ahead.

One of the rather funny things i once got with another command's ctf was a third ctf stripe where automatic detection, for example, program speed was maintained a thriving optimization metagame. Example: some users looked at the fly like people at "the o(n^2) loop that word-for-word compares text against a loud list." And abandoned the "o(n) loop that compares to a hash table" flyswatter. In favor of the orbital ion gun, for example "pre-compile the dictionary into an executable file as a trie or bloom filter".

We have top ratings could feel comfortable on our site, could enjoy listening to favorite levels that have people a great number to play golf. , And, among other things, there is the right to your taste (automatically or against the background of human verification) to award additional badges for passing the level higher and further. We also agree to do this outside the layers - i can imagine releasing icons for those that, for example, leave oss clients for the human api, submit documentation fixes, responsibly report privacy annoyances, etc.

set targets. Uncertain decisions. A common pattern in ctf creation and promotion is: "create a program appropriate for this toy interface." A lot of work on the part of the player has involved endorsing this interface (and often its undocumented features). The interface often dictates exactly how your algorithms/structures/general approach should appear.

We prefer to simulate real engineering practice, in the case where you're building things not to spud an arbitrarily defined interface, but to achieve a realistic motivating goal. Figuring out what a phenomenon needs to be built in order to achieve a goal is a significant detail of complex engineering activities and it's a lot of fun! (Besides, companies hiring engineers right now are often looking for people who can, given an underdetermined goal, successfully reduce it to working computer code.)

This allows us to trivially maintain multiple solutions, as long as we choose targets that are reasonably robust. Fortunately, the fiction of wall street gives us plenty of options. I mean, when in doubt, it's “here is the world; earnings, but things can be arbitrarily rich.

This also has some unintended advantages from our internal engineering point of view. The orchestration of the modal level for russian trading levels will be about ~50 lines of ruby code. Most victory conditions can be computed in a function of less than ten lines. (Level six? The most fun i've ever had was judged by a single line comparison.)

Level orchestration

A person has a gm server ( " quest master is a rpg term that combines world simulation, referee, npc organizer (bots) and self-assured fun maker.

Our gm server is written in go and provides rest api .(In fact, you can dive into stockfighter's entire world via curl if someone told you which urls to hit. That would be pretty neat. Tell me if you can do that.) It takes commands such as post /levels/foobar which generates a new foobar level instance.

The gm level orchestration logic is actually ported to ruby, mainly since i develop ruby much faster than go, and because code like this is less picky about performance than the stock exchange, there was some flexibility. Good old ruby heavily influenced by rails in design - configuration convention, lots of reflections used to find videos with predictable naming schemes etc. They also have a yaml configuration that allows us to customize e.G. What bots are present in the level, what instructions are given to the player, etc.

Bots…well…every project shipped comes with one solution you think you need to say: “look, i know i i know, pin up casino download it really worked.” All our bots are written in ruby. The goroutine that controls the level instance on the gm server periodically wakes up, opens a ruby subprocess, analyzes the state of the simulation of the world and bots, makes the bots update their roundness in strict adherence to the state of the exchange through the rest api, receives the necessary bots. Orders, makes insects via the rest api, analyzes the state of the simulation and bots, and then falls asleep until the workflow instantly starts again.

Why? The combination of "this allows me to write levels and bots in my best language", "i wanted to release in 2016" plus "if i made a little more obvious substance, and non-stop kept many of our levels and bots in memory, but didn't cut them. 500ms of server attention every n seconds, then our memory requirements at startup will be measured in terabytes and go up from there.”

Why then use go for the server, but not, for example, sinatra? Since go has a much better concurrency history than ruby.

Foreground injection

The main goal of developing stockfighter is to be able to take it quickly and buy, directly through the browser, without requiring the installation of a complex chain of tools.

Why? First of all, from a strict position of conversion optimization, i expect a big, extremely big gap between being entered into the registry and completing level 1, if my first instruction is good, install a fully functional c toolchain on a personal pc. Now clone this repository." Or even "download the vagrant image".

Secondly, this is most difficult for less experienced engineers. They have not proven to be the foundation of our enterprise in any way, but my priority is to support them whenever possible. My priority is that the cs101 class can play stockfighter together. Many practicing engineers don't remember this, but the cs101 classroom finds a setup, e.G. The complete rails toolchain to be a difficult, frustrating, failing experience. (I'm a professional engineer using rails for the last 8 years. If you could give me a clean macbook and a date i could install rails... Last week.)

Therefore a tough requirement for our two technology trees were, say, to run through the browser window. After the players invest, they can take advantage of this stack by working locally on the stack of their choice, building tools on top of our systems, or even, for example. Deploying code to ec2 or heroku or whatever, but batteries had to be included here in the shipments.

Thomas and erin create a whole chain of c development tools through the browser that compiles into a build and after runs on a farm of emulated arduino processors.I had a comparatively easier task: figure out how the simplest working version of automated trading works?”

Answer: it's manual trading! So, we have made a blotter interface, in fact, a stripped-down retail day trader interface for monitoring the market, placing orders and controlling their execution. You can use the ui to click on any of our levels and calculate what is "normal" market behavior given that level is loaded with bots and promotions. You can also use this movie as a springboard for bootstrapping your first programs - no need to write eg. A cipher to poll if your orders have achieved something, due to the fact that we have already taken care of this for you, in this regard, absolutely all you need to do is to tune in to the production of the correct orders to send. If you prefer, you can even completely replace the interface with your own web app - wow.

Another awesome option: if you're confident in your trading ability, you can at least theoretically beat many of our trading levels the old fashioned way - by running the math in your head and enrolling your orders more actively than the other guy. It's a huge mode since the other guy is using ruby code, however taking advantage of ufarozaopt.Ru putting him to sleep 80-90% of every trading day is at least possible.

Custom the interface also includes controls. To work on the level, for example, restarting the level if you get stuck.

It was you see that with goals like making a million dollar profit online! Be in a no-win state, for example. Loss of 95% of your starting capital. The designed work of our trading levels is: “take part in them, lose horribly, write a program, reset the level, run the program, crash it wrong, fix it and restart it, lose modestly, change the personal approach, restart.” Level, run the program, win." (People have asked if we would hold this against an individual. Just a little, of course not. We log everything in life, but the plan is to lose/restart levels. This chance is an advantage of doing it in a rich simulation and not in real life - you can go to knight capital as many times as you need, and no one will lose their job!)

We made the interface in react, because there is much more going on in it than most of the crud application.

Dhh describes the optimal place for my favorite stack (rails-with-some-javascript) as documents with other dynamic inclusions. I really like this model, but it does not describe the trading interface. You have an incoming stream of events, many per second, updating a part of the dom, potentially hundreds of open orders, the state of which must change at any time and the exact display of which matters, and a bunch of actions available to you at any time.In addition to the mandatory learning, since this is my first react application, i love react and the flux architecture. (We use flummox, which alas was eol however, how we chose and run it. I swear, all the jokes about js frameworks are true. But, from the options offered, it seems that a minimum number of templates was required, which can be further reduced. With a reasonable agreement about names.)

Our blotter interacts directly with the exchange api (unlike most piece trading software that interacts with a brokerage that interacts with a new side that interacts with the exchange). Extremely needed, as i was doing parallel development on both systems. By forcing me to write very hard human api software, i got rid of a lot of inconvenience by using before you were introduced to the players. (Oh, don't worry, you'll find a lot more.)

Requirements generated by the blotter like "order status polling is really huge, in case you have hundreds of them - we need some kind of system publish/subscribe via websocket" made the exchange more interesting for all sorts of trading applications.

Here's an image, although it's a little more fun when quotes are flowing and things are posted regularly.

Big challenges for making react, besides the learning curve, were state management when switching between levels (finally solved by rethinking the design of this supermarket) and commercial activities with sports events are also a lot of ui redrawing.

At some point, i was playing on the level with a hundred bots. Each of these bots sent approximately 1,000 orders per minute. Any bid changes the stock quote by triggering a separate web socket message.Each websocket message caused my entire table of orders to be updated.

100,000 table updates with a thousand items per minute will melt your poor little macbook pretty reliably.

We ended up solving this problem using built-in react functions such as shouldcomponentupdate (almost everyone started getting very granular with regards to performance-sensitive components, ticket type, and quotes to make sure movies would literally render the same when given the same starting parameters). Prop and states, and then cancel rendering if their features/states were equal) and using keys on child objects.

Fun fact about child keys: even if each child is spontaneously immutable. If you don't select the keys enough (e.G. Just create a unique id when you get a child ui element), updating one order of them in a lifetime of 1000 will update the whole table, and when your child's key is different from the key behind the same element in given version of the table, the magical react dom-diffing technology. Method will not save you. Instead, your bacon sizzles in unison on your favorite macbook.

After i thought about this and started choosing the best child keys (adding an id and a modified timestamp is all that really matters to you - just like in rails russian -doll caching), our user interface is quite fast. I log into my everyday staging environment (amazon datacenter near oregon) from tokyo and can't tell it's not on localhost...Except when the speed of light decides to play a trick on me.

Support technology

Our web application (registration/login/leaderboards, etc.) Is a standard rails 4 application with little technical interest, but the site is open for you, yes, it could be written quickly - in front of you is exactly what rails wants.

Do you know whose place this is definitely not the most pleasant place? Go. I tried, really tried, but at this point it would be very difficult to recommend go for a web application. Maturity of activerecord, and in order to get its (valuable!) Set of features, the candidate will need to endure, and) the denial of most of the advantages of using a type-safe language, and b) programming errors that cause statements that definitely look like as if the wallpaper should generate sql requests lightly silently do not generate sql queries. More specifically, go's database partnership was so painful that to replace it, i either a) hit the rest endpoint in a hidden api to have rails log out to the db, and then return formatted json (which go actually can in decent enough to consume) or b) sending information to nsq.

I fell in love with nsq, a corporate message bus for the person who never wants to have a corporate message bus. The elevator step for this is: write an sms, tag it with the business side - and send it to your local nsq daemon. On some other machine, which also doesn't know the viewer exists, another program says, "by the way, i'm a member of channel $foo and i want to recover messages from topic $bar, which also weren't handled by channel $foo. . $Foo not yet? This is https://nuevamuseologia.net/ being done now. Hit me." Nsq does all the magic to make this happen.

We're using it for modern. Rails controllers need a way to log events in the spirit of analytics? Pass that to nsq - we'll accept the analytics provider verdict later, in the meantime, while nsq_to_s3 will just store them for us.Our settlement system has a need for executions from the exchange?Open a settlement channel on the topic of executions;done.Executions should also be logged in others?Of course, open the dumptolog channel on this issue and use the provided nsq_to_file utility; done.Do you even need a registry of historical ui actions taken by each player by level?Certainly don't worry, ask the gm server to put levelactions in the topic, open a peristtodb channel in this section, and work on nsq_to_http so that they go to the internal api in here a rails application that takes care of this.

the best part? Having nsq all over the place, you don't have to think about all the data, removing more instances of a certain service in your own infrastructure, routing requests, etc. Etc. You can easily fire and forget about the bus.

Actually, this is not the best segment of nsq .The best part is the fact that stockfighter comes with about seven microservices and if they all understood every available http destination it would be cumbersome. Instead, we've standardized a small set of common json object representations, followed by topic names. It allows us to do such things, for example. Let our arduino emulator gobble up quotes from the stock market just saying, "hey, i need quotes too" without the stock exchange knowing the arduino is a thing.

For their services which communicate via http, for example, for example. Exchanges, we have to be even smarter about routing, because we can't treat nsq for the magic oracle that delivers messages. The short version of this story is consul.Io, the longer version is the full infrastructure post because it gets more complicated.

Documentation

We used readme.Io for our documents for users. I also didn't run our documentation (lots of spoilers), but i like our resource.

- Documents always look nice and i don't need to do more css-processing. - Ux of documents is fine to, for example. Stripe or twilio, but not the markdown file.- The browser has an api explorer, so you can (to) copy/paste your api key from the page describing e.G. Our post /venue/foo/symbol/bar/order endpoint, actually place a valid order on a common of our live stock exchanges. It displays http headers and a categorical review in search.

Readme.Io is incredibly funny. We will release the documentation when the game becomes public.

More trading information

We promised players a reading list that players will enjoy with an understanding of wall street for a wide variety of players. Profile. Here's a brief digression into my amazon history over the past few months:

Flash boys, michael lewis: i find this book to be irresistible when discussing automated trading, and yet hard to recommend. Lewis is an exceptionally talented writer. I think that often starfighter players will leave some of our levels saying, "michael lewis, i was really trying to do what the viewers said the bad guys did, and that, for engineering reality, is really impossible." But, we completely tear off some levels from his very entertaining) narrative. I mean, they named a computer program after a greek god. How can we not turn this into a level.Flash boys: not so fast: a much clearer take on hft by someone whose salary depended on being able to turn an education into real engineering artefacts.Dark pools: the rise of machine traders and the falsification of the us process, scott patterson: if the title does not explain the essence of the game, spoiler warning: patterson hardly thinks he is better than engineers capable of conducting algorithmic trading, is a victory for truth and justice. (Certainly it is! At least consider it self-defense training.) However, unlike the flash boys, the discussion of problems/attacks seems to me (and our advisors) to be more closely based on accepted reality. This book also includes an excellent history of the development of computerized resources in america from about the nineties to the present day. It was especially wild when i realized that every cute little toy featured on t2.Micro was an engineering project worth x0 or y00 million dollars in living memory. - I hesitate to recommend it because of the price, and if you want to deal with this issue professionally after the stockfighter, the bible in this company of thomas was trading and exchanges: market microstructure for practitioners.

That's all i have for today. Let's return to us in the cave of the code. See you in a few weeks!

Written: august 20, 2015

About the author

Older view archive (574 )

Money talk

Twitter is buzzing today with those #talkpays sharing their paychecks. The movement is more marxist in nature, but this capitalist urges you to look further, as it is in the common interest of those who have already worked for wages or wages to understand what the market is.

newer

Developing in stockfighter with no trading experience

Starfighter is a company that specializes in fun programming challenges. One of our goals is to inspire engineers to solve situations that they say are “too difficult for me.” Both level sets for the russian first game, stockfighter, provide ample opportunity for this in one set you are an algorithmic trader, but in the other — low-level coding in c and assembler, reverse engineering and security research.