I built this project a few years ago with a Django back-end and and Angular as a SPA front-end. The component that shows the 3-D Earth was built with d3.
The goal of the project (Unitarity) is to make crowdsourcing forecasts for various event outcomes easier and more intuitive. Coming from a background in finance and tech, I always had this unsettled feeling that so much time, energy, talent and money is spent in the world of finance to win a basically zero-sum game. It's hard to quantify the positive externalities that are generated from this game, but if I had to guess, they wouldn't be that much. Think of all the stories of Physics PhDs who leave academia to use their skills to work in finance. At some point, the more energy you put into a zero-sum game, there is a net loss of productivity. What if we could redirect those skills to a game that has positive externalities and benefits society?
The site was initially seeded with a few challenges to demo the different types of events and forecasting scenarios. For more info on the workings check out the guide (https://www.unitarity.com/app/docs/guide).
When I first started the project, I wrestled with what frameworks to use. As a Rails dev, I really wanted to use Ruby for the back-end. However, Python is more familiar to those in academia and data science. I ended up choosing Django (which I really like in a lot of ways). IMHO, it has better (and intuitive) support for DB migrations than Rails. On the downside Django, has really bad documentation and the community of 3rd-party modules is not as big as the Rails one. I really disliked writing tests in Python compared to Ruby. I really got used to RSpec and came to like it quite a bit, so testing in Python wasn't so fun.
Before I jumped into using a JavaScript front-end, I tried simple html templates. However, Django is not as good as Rails when it comes to templating. In Rails, one has a plethora of formats to choose from (erb, haml, etc.), that Django is missing. SPAs were all the rage around the time I started coding and since I had some experience with Angular, that's what I went with. The app has quite a bit of UI interactions so going with an SPA made a lot of sense. Angular gets a lot of bad press, I found it to have an intuitive framework that uses dependency injection (it was familiar to me coming from a Java/Spring background). Also, Typescript was a real joy to use. I originally started as a Java developer 20-odd-years-ago, so having a typed language meant less testing to make sure things were working.
Overall, it was a fun and challenging project to work on, and I learned a lot. However, I still wrestle with some of the technical decisions. For example, whether-or-not I should have built it as an SPA, since this was quite a learning curve and had some unforeseen consequences. SPAs are a helluva lot more complicated than just building a bunch of html templates. In many ways, doing an SPA can make you feel like it's Groundhog Day. You are basically building a parallel front-end application that can be more complicated than the back-end. The SPA will have many of the same models and routes that the back-end does and coding it will sometimes feel like you are going through a boring routine of repetitive tasks.
There's more I can go into, but I wanted to keep this brief.
The goal of the project (Unitarity) is to make crowdsourcing forecasts for various event outcomes easier and more intuitive. Coming from a background in finance and tech, I always had this unsettled feeling that so much time, energy, talent and money is spent in the world of finance to win a basically zero-sum game. It's hard to quantify the positive externalities that are generated from this game, but if I had to guess, they wouldn't be that much. Think of all the stories of Physics PhDs who leave academia to use their skills to work in finance. At some point, the more energy you put into a zero-sum game, there is a net loss of productivity. What if we could redirect those skills to a game that has positive externalities and benefits society?
The site was initially seeded with a few challenges to demo the different types of events and forecasting scenarios. For more info on the workings check out the guide (https://www.unitarity.com/app/docs/guide).
When I first started the project, I wrestled with what frameworks to use. As a Rails dev, I really wanted to use Ruby for the back-end. However, Python is more familiar to those in academia and data science. I ended up choosing Django (which I really like in a lot of ways). IMHO, it has better (and intuitive) support for DB migrations than Rails. On the downside Django, has really bad documentation and the community of 3rd-party modules is not as big as the Rails one. I really disliked writing tests in Python compared to Ruby. I really got used to RSpec and came to like it quite a bit, so testing in Python wasn't so fun.
Before I jumped into using a JavaScript front-end, I tried simple html templates. However, Django is not as good as Rails when it comes to templating. In Rails, one has a plethora of formats to choose from (erb, haml, etc.), that Django is missing. SPAs were all the rage around the time I started coding and since I had some experience with Angular, that's what I went with. The app has quite a bit of UI interactions so going with an SPA made a lot of sense. Angular gets a lot of bad press, I found it to have an intuitive framework that uses dependency injection (it was familiar to me coming from a Java/Spring background). Also, Typescript was a real joy to use. I originally started as a Java developer 20-odd-years-ago, so having a typed language meant less testing to make sure things were working.
Overall, it was a fun and challenging project to work on, and I learned a lot. However, I still wrestle with some of the technical decisions. For example, whether-or-not I should have built it as an SPA, since this was quite a learning curve and had some unforeseen consequences. SPAs are a helluva lot more complicated than just building a bunch of html templates. In many ways, doing an SPA can make you feel like it's Groundhog Day. You are basically building a parallel front-end application that can be more complicated than the back-end. The SPA will have many of the same models and routes that the back-end does and coding it will sometimes feel like you are going through a boring routine of repetitive tasks.
There's more I can go into, but I wanted to keep this brief.