Mate honestly, if i wasn’t busy, I feel confident I could find a lot of problems in this project just from a quick glance.
By the time I’ve run it through the sns-testing repo, my comments would really be proper fuddy.
Understood, I’ll try to glean something valuable from your full feedback when it’s ready, just like the team did with Jerry’s video. We’re all ears for feedback right now!
2 Likes
Yes mate, attitude is everything and if you wanna make it good we will help make it good. I just want high value SNS services.
Everyday I’m just refactoring into patterns, backend we are getting there but frontend we are a long way off say juno but we will get there - this repo is one of the best frontend ones to reference.
We have a lot of SNS related code you should check out, just implementing that might indicate how we break up code to make it more maintainable and therefore less prone to errors (I say less :P)
Agreed, David’s work is stellar. I had to turn him down last year because I was working on Taco Dao, otherwise I might have been working on the Juno frontend with him! I’m 100% sure he would not be as forgiving with the frontend as I am, but he also has the resources to work on Juno full time, I do not have that luxury with Taco Dao (yet)
1 Like
Also, to save you looking, here is a canister under DAO control, it has our implementation for the custom generic functions etc within the data canister within Football God.
I was too scared to mention him 
1 Like
He might look at my frontends and shred me like I just did you but legit I do not feel my current patterns are finalised so have held off from further SNS’, let staff go and had a hard time - I would only do my golf SNS when I feel like i can justify my svelte patterns to the likes of @peterparker.
1 Like
I used to be a consultant, going around to teams and helping them with their code bases. I have also been in software so long that I have been on dozens of teams. And over time, I have seen a clear pattern emerge.
In my experience, I would classify teams and their code bases into two groups. The ones that do have a strong, opinionated lead dev (or sometimes just a team member) that cares deeply for code quality and that makes everyone write code with a consistent style, and those who don’t.
The first observation I would then make is: The code bases of the teams with an opinionated team member are certainly easier to read and get into, and having someone like that on the team is usually a good thing. In other words, your team is lucky to have you!
But the second observation that really only became clear over time is that the opinionated devs rarely have the same opinions as each other - and it doesn’t really seem to matter much for team success which opinions they adhere to, more important is that they have them at all.
To some extent they may share opinions, because there are not an infinite number of ways to do things, so there’ll be some given set of camps that the opinionated devs belong to where the pigeon hole principle applies, but there are a lot of things to have opinions on (it starts with tabs vs spaces) and every opinion maker will typically have their own, unique combination of such little (but fierce!) opinions, such that every new team you visit will have a code base remarkably different from the other, even if their respective opinion makers get on famously over beers.
Eventually, you stop caring about styles, the current attempts at taming complexity with yet new patterns, and even what languages to use. You just go with the tools that seem to fit the team you have and the task at hand. When consulting, coming in to some team following one set of patterns and style guidelines and trying to convince them to follow yours instead is almost always a waste of everyone’s time.
In the end, I would say the only thing that is even better than having a strong, opinionated dev on the team, is managing to figure out a style that comes natural to the team, and then settle on that.
So, with all this said, my first impulse when trying to get familiar with this code base is not to rewrite all the patterns to my own favorites, but to try to pick up on the patterns the authors used, and use them as tools to understand the code.
Too many comments, too few comments, naming idiosyncrasies, all are things I have come to see past as noise, but since you are into DDD I will end by bringing up something you might find interesting, and that can be seen as a special off-shot from the early DDD days. There is a solution to all this, which is Projectional Editing. I spent a decade and a half working with it, and it makes all discussions like these moot. With a projectional editor, you hide or show comments, or flip them between what aspect of the code they comment, verbose or compact, etc etc. The code can be projected and reprojected in any language, with any coding styles and even reprojected into refactored versions on the fly, or as diagrams or charts or in prose.
Basically, every user can access the whole code base and comments in the formats that fit them best, and all disagreements about code style and best practices go away, finally allowing everyone to focus on the core concepts of the business idea. It’s still a bit ahead of its time, but I have no doubt we will get there, especially with AI helping us build it. Until then, I will remain thankful and appreciative for your comments, but in the interest of saving everyone’s time I will say that I am especially interested in your observations as they pertain to actual security or scalability issues (rather than coding style, where I am sure you have great ones, and might even be ones we end up using, but it will depend more on the team we end up assembling what they prefer).
4 Likes
See the two are linked, style and delivery.
Understanding can be expressed through execution.
I don’t pretend to know all the answers but I have a lot of experience. In 15 years of dev the problems always boil down to a lack of understanding the domain problem and accurate articulation of the domain has always been the solution, for me.
An interesting article maybe:
As you realise where your code violates principles you will see where your domain is badly designed.
I’ve never worked on a code base that violates basic principals but is also refactored into its most efficient format.
Defining the domain accurately is always step one.
honestly this is a very important point
2 Likes
Or if the token has little to no value, it’s fine for somebody to come along and take the DAO and repurpose it 
6 Likes
Maybe this could be plan C.
Where do you see inaccurate articulation of the domain?
“violates principles”
You have been taking screen shots of code comments.
This really does come off as a very transparent attempt at bad mouthing a competitor, reaching for things to criticize in an exaggerated way, while at the same time trying to derail the forum thread about TACO DAO SNS launch into an ad for yourself and your product.
Let’s behave like professionals and see if we can’t both launch great products that people enjoy!
7 Likes
Just to point out: We recently had our lead developer actually disappear. Like we dont know what happened but he hasnt responded to the team in over a month. I will write a longer post about this at another time.
Point is that we (our code) has survived trial by fire and will only continue to improve with @Snassy-icp and @ericrosedev hard at work.
3 Likes
@BIKETACO @Snassy-icp @ericrosedev
Thank you for taking time to respond to everything here. I’m now a taco dao swap participant. Good luck!
For what it’s worth I think @jamesbeadle was trying to be helpful here. His tone just came off a bit, abrasive. But I think he means well! Looking forward to all of you guys building great things.
3 Likes
Thanks! Its great to have you in the DAO!
1 Like
For the people who are always curious about what really important questions to ask prior to:
Q) What were the results of back-testing this strategy? How was this strategy back-tested? How did you derive the time/price data?
+80% of developing any algo-trading strategy is back-testing. This way it can be shown that the strategy is not only profitable, but also is good at capping losses. Just remember, if a strategy cannot be back-tested, then your money gets to forward-test it.
My answer has two parts but you may not be satisfied with either:
-
Although we have a trading algorithm, the main point of the algorithm is to maximize trust and transparency while minimizing market impacts and trading fees. Our trading algorithm is something like a VWAP in tradfi (volume weighted average price) in that the VWAP allows someone to enter or exit a position in an orderly (not profitable) fashion. Our trading algo is well tested and fit for this purpose.
-
If we were a ‘trading algorithm’ meant to specifically buy and sell when certain technical criteria were met, then we would actually be running a ‘max extract’ on the best projects in the ecosystem rather than supporting them.
Our core strategy is use the Wisdom of the Crowd to avoid scams, find opportunities and determine the right balance of allocations to each trusted asset together. I plan to post more extensively on this concept in a separate post shortly.
If our experiment is successful then we will have create a self regulating index of ICP ecosystem tokens that makes a tasty entry point for those new to the ecosystem. If we can grow the ecosystem, our portfolio is likely to increase in value as a consequence.
Thanks for the great question and for taking the time to learn about us!
4 Likes
Overall Taco Dao creates a game around their smart contract where a portfolio is managed using collective intelligence. I advise the DAO & dev team to start with coins like ckBTC, ICP, ckUSD*, TCycles, GLDT in the beginning and slowly add other tokens with limits in max allocation, max trade per day and a scoring algorithm. Every contract has some trade-offs, for AMMs that’s impermanent loss ↔ fees and it looks like this new contract will also have some. What the goal should be is to create a non-zero sum game where everyone wins or looses and not a zero-sum game where part of the DAO can win, while others loose.
Just ease in with small part of the treasury, a few tokens in the portfolio, add transparency, analytics, let things play out and improve the rules. Give the DAO some time to process what is going on and work on these contracts - that’s what DAOs are good at.
If you don’t rush it, there’s a good chance you’ll create something great. That’s why I contributed some ICP to support your launch, DeFi innovation deserves it.
7 Likes
They are sick and tired of conventional fixed style governance.
The work, which becomes a new model itself… will be called ‘WOTC DAO.’