It's been over 24 hours since the launch of Ape Mining Club. As expected there were a few obstacles, some minor UI issues and some payout issues. If interested, I'll talk about them at the end.
Interesting Statistics
- 21,768.589 APE was purchased off Hive-Engine
- 5,513.2 APE was burned
- 121 users have APE
- 79 users own equipment
- 1,370.524 STEM was used to boost
- 9,724 STEM was used to steal ownership
- 11,159.634 STEM (~$1,600) is set to burn (there is only ~10,000 STEM inflated weekly)
Top Thieves
| User | Times Stolen | Amount Burned to Steal |
|---|---|---|
 | 2 | 2,650 STEM |
 | 9 | 2,368 STEM |
 | 2 | 1,024 STEM |
 | 1 | 1,024 STEM |
 | 1 | 1,024 STEM |
Top Boosters
| User | Times Boosted | Amount Burned to Boost |
|---|---|---|
| 15 | 476 STEM |
| 3 | 220.89 STEM |
 | 1 | 100 STEM |
| 1 | 100 STEM |
 | 1 | 100 STEM |
Top Stake Holders in each pool
| Pool | User | Amount |
|---|---|---|
| CPU | | 365 |
| Cloud |  | 40 |
| GPU | | 16 |
| Asic | | 18 |
Technology Stack
I am using Vuejs for the front end, this is my first Vuejs project and I really love it. The backend I decided to go with Javascript, even though Python is my preferred language on Hive. Interestingly, almost half of the code is database stored procedures.
The reason for this is the resource intensive nature of trying to calculate who is holding APE everytime someone makes a purchase. This is extremely resource intensive, it takes almost 10 seconds to query for all the STEM holders for example and more than one miner may be purchased in the same 3 second block. This poses a big problem, so I had to think differently.
The solution was to maintain real-time state of all APE holders as it happens. This way the query is simply an UPDATE join, a very lightweight operation that can complete in a few milliseconds.
Conclusion
As mentioned above, a few issues came up during the launch.
The first was an issue with the slider for selecting how much equipment you wanted to purchase. Originally I had a text box where you enter how much APE you wanted to spend, and then later I changed it to how many miners you wanted to purchase with a slider. The purpose was to prevent user errors as much as possible and make the experience as easy to use. When I switched to the slider I set the max of the slider to be based on total amount spent, so this locked the slider at 0 on the larger equipment preventing people from buying it. As with the next problem, I was trying to be extremely clever to make the UI as smart as possible, but I had a small oversight when I changed direction in code.
Second problem was the same dialog to purchase equipment. I was disabling the buy button if the amount selected wasn't equal to at least one miner, this way people wouldn't try to send amounts that wouldn't result in equipment purchases.
The last two problems were in regards to the daily payout. The first issue was with the code I used to batch multiple transfers (custom json) into groups so they are not all sent one at a time. Was related to asyncronous javascript code not behaving properly in a loop. This is something that is a known issue with Javascript but as a Python dev it didn't behave as expected.
When I did get payout working, and then went to take a nap, I woke up to find out all but two different transfer. Looking at account history I noticed they all failed due to symbol precision error. I was sending an amount with 8 decimal places but the token only had 3. I adjusted the payout script to round to 3 digits and re-ran it skipping the two and all worked perfectly.
Things were suppose to go better and fixing on the fly is no fun but it's all working good now.