Noted 
DevOps topic for dapp
1 Like
Yeah that would be great indeed!
I would recomment to look at test tooling automation more than the Tezos cycles
Automated testing only finds issues, it doesnāt do the research for you to figure out what the solution is, or write the code for you. When protocols like Edo go through, my issue is not detecting that the michelson has changed. Its having to re-write libraries in 3-4 languages, thinking about edge cases, how to try and future proof the code, integrating it in multiple frontends and then multiple full regression tests on top of that with bug fixing ā¦ while the only support given is āheres a link to a michelson whitepaperā.
This is one hell of a massive burden to have every 3 months, while your end users are begging for new features, improvements and bug fixes. We have been blocked from adding new features that our users wanted a year ago, because indexers keep delaying features due to the massive scale of work needed to keep their code functional. This has often resulted in frontend apps trying to fix these problems themselves, which often leads to buggy/inefficient solutions.
With all due respect, this comment is completely devoid of the reality of maintaining multiple frontend apps with a dozen integrations
3 Likes
Hey, Marigold has a Learn section now : Learn
I am migrating the dapps training one by one to taqueria (will finish next week) . This is the new hard hat for Tezos. Really cool!
These trainings will be on YouTube on next weekās too
Trainings are done in jsligo and typescript, so more or less there is only JavaScript to know to build either smart contract and Frontend
Btw, the part that is still difficult in Tezos is the process to upgrade a contract. Training 4 gives solutions and implementation about it. I still believe that tzip18 would require this feature at protocol level and not on hands of developer. I have proposed a solution for that that need to be refined with core team
Also I recommend to use Ghostnet now. It is a persistent testnet with iso production protocol
1 Like
This is the correct take. I can count on my hand the amount of teams who actually run more than one dapp on mainnet.
The 3 month updates are obviously awesome, but I usually still have to reserve a week to react to any and all breaking changes up and down my infrastructure.
Obviously the core chain will work, but I have to trust that the upstream devs tested perfectly and found all potential issues.
A Herculean task when you think about how complex tezos core is.
But there is a simple solution! Just fund people to do the work beforehand lol
Huge fallacy lol. I wish it was actually true but in the big leagues the contract is almost the easiest part.
3 Likes
Can you post an architecture of your solution to see where are the dependencies , please ?
Great news on the learn section!
I am migrating the dapps training one by one to taqueria (will finish next week) . This is the new hard hat for Tezos. Really cool!
Out of curiosity, any particular reason why you prefer Taqueria over Chinstrap from @ant4g0nist ?
Chinstrap deploy process is also described on OpenTezos while I cant find Taqueria.
Another thing why I am wondering about the selection is this warning on taqueria github:
WARNING: This project has not officially been made public. Congratulations on finding it. Have a look around, but be aware, itās not yet ready for public consumption.! CLIs and APIs are unstable and likely to change.
- Donāt have mac for homebrew
- Donāt want to use or install python
- Donāt have VS code plugin
- I already use taquito on frontend, so I can reuse it for deployment script if needed
- I cannot generate .ts classes from backend code
All trainings ādapp for jsligoā are taqueria-ready here : Learn
If you want to give an eye
ps : I will post a proposition for TZIP-18 in another thread, please vote for it if you like the new proposition
1 Like
I think something worth mentioning is the speed of releases and breaking changes with releases is bound to go down over time. Thereās no way weāll be passing 3-4 proposals a year in 2024+. Once all parts of the stack are more fully evolved and in reasonable design shape, some L1 ossification is bound to happen.
I encourage all devs to brave the changes for now and keep suggesting creative ways to ameliorate the tail of issues.
3 Likes
Also here adding this:
Lets add the sudden, without a further warning or notice, kill of PascaLigo.
Thats really rough and does not help Tezos to gain more developers.
You are just letting them down.
But let me be clear, If a certain entity cut the funding then SHAME ON YOU!
The community is working hard to convince users and devs onto Tezosā¦
The statement read for yourself:
Hi all,
About PascaLIGO
The documentation is broken. This is a bug from the doc website, we are currently fixing it.
We do not intend to remove past things that worked, and will obviously not remove PascaLIGO from previous versions.
It is being deprecated.
Starting from V1 (next version), it wonāt be part of the compiler any more. We will of course keep the docs and PascaLIGO in older versions.
All of this was going to be explained in the next versionās changelog + Twitter announcement, where we communicate all of our changes, as usual. But V1 has been postponed by two weeks. As you can imagine, there are a lot of breaking changes, and will bring with it V1 of LIGO.
Why PascaLIGO is being deprecated?
This was asked to us many times by our funders. The preferred strategy was to focus solely on CameLIGO and even more so on JsLIGO. Similarly, the PyLIGO project is also cancelled for now.
The main reasons are:
ā¢ There is a regular feedback that too many syntax is confusing
ā¢ Thereās a cost to maintaining extra syntaxes
ā¢ It is better to focus resources, training, documentation on fewer syntaxes to maximize adoption
ā¢ PascalLIGO had very quirky syntax and did not make for a good onboarding language
ā¢ A major reason for why PascaLIGO still had use was the presence of imperative features, which have since then been ported to JsLIGO
Furthermore, we did it in the past for ReasonLIGO a while ago, given the low relative usage. Similarly, our latest poll shows that CameLIGO and JsLIGO are the main choice by far (90%) new projects
*While we historically were against the removal of PascaLIGO, this is a period of bear market, accompanied with budget cuts, and we must focus. *
More on this last point: major changes are coming on V1, which will significantly improve onboarding and dev experience. Porting them to PascaLIGO will delay it
ā
We understand this is hard for many users. To help the transition, we will help any project written in PascaLIGO to migrate to JsLIGO.
Source: Telegram: Contact @LigoLang
