The communications team likes this 
@nikitafuchs.chain is there a video about your Fire Editor? I thought you prepared one, but I can’t find it. We would like to start promoting this.
fun not phone
great news 
http://fireeditor.nikitafuchs.de/ is way better than https://testnet.contracts.aepps.com/
it has a friendly interface and way faster than https://testnet.contracts.aepps.com/ which is reallyyyyyy slow 
and i really love the fact that it autocompiles your code
i can’t stop thanking you @nikitafuchs.chain
2 Likes
Hahahah I’m glad you like it @Goodness ! There is so much more to come, sit tight!
@vlad.chain I made videos on the native token topic for the community, but didn’t have time to edit them yet - maybe I can tell someone from the communications team what I had in mind (nothing crazy) and they can do it? But there will be videos for the editor very soon, too, give me just some time to implement a little more functions.
There are 2 updates today:
1.The code editor is back in place again ! It looks a little nicer now, the biggest part of the magic is still being worked on under the hood. Soon it will be able to generate code from written documentations, for all the SDKs, using some language processing wizardry 
- There is a new feature now warning you if you forgot to include an
init()function into your contract. If you write contract code just to interact with an already existing contract that’s okay (supported soon!), but not for deploying a contract. Now you get a hint on what you did wrong and what to do next:
2 Likes
Alright, this week imma keep it commin: Now you can make the editor interact with contracts that are already existing on chain! You need to have both the correct code (pasted in the editor) and address, and there you go:
Caution: Currently, the SDK does not check whether the address you provided “makes sense” (e.g. is there a contract / the contract you expect?), it does only so if you actually call some function. I Created an issue on this. The check also requires the code having been compiled with the same compiler version I think, but if the issue is being handled the way I suggested this shouldn’t be a big deal anymore.
3 Likes
great work 
Love what u are doing
1 Like
We can help with editing if it is not something advanced. We can also ask the videographers for some support, they are editing pros. Please let me know when you have all of the videos ready, it would be great to put them all in a YouTube playlist.
2 Likes
You da man Nikita!!!
3 Likes
Can you also produce a few short videos where you explain the usage and the process you go through? I think this would help a lot of beginners/startes with the development of Blockchain applications with aeternity.
3 Likes
It’s part of what I’m planning to do, just ordered the last missing piece 
! hold tight.
https://www.amazon.de/Falthintergrund-Hintergrund-Bildschirm-doppelseitig-Zusammenklappbar/dp/B01MSTJ6FJ/ref=sr_1_9?__mk_de_DE=ÅMÅŽÕÑ&keywords=greenscreen+faltbar&qid=1572799567&sr=8-9
2 Likes
Hello @nikitafuchs.chain, is it planned for fire editor to allow dry-running stateful functions, in order to receive better error messages? (e.g Non descriptive error returned from contract call)
If contract call transactions abort it could also automatically be dry-runned in order to show a nice error message to the user.
5 Likes
PROPOSAL [draft]
Note: It’s “draft” because I first would like to hear other people’s opinion here on whether I might have forgotten something important. After a feedback period, I will eventually add/remove/change things and change the state to final.
… … … … … … … … … … … … … … … … … … … … …
People familiar with programming know it’s essential to have an IDE that allows to quickly test and debug functionalities and issues that are specific to a language and/or system you are building on. This editor allows to quickly write error-free contracts, deploy, interact with and debug them. Features like error highlighting, individually generated GUI for every contratedact and console for transaction details are just a few features to mention here. You can even have a boilerplate-dAepp generated, which deploys your contract and calls the function of your choice (thereby showing how to build on aeternity without reading long docs). Around 98,9% of the codebase was written by me, honorable mentions go to @bruteforce.chain for the syntax highlighting.
As now every AE project requires explicit permission to spend work on (just as an info to non-AE people in here), I was asked to put together a list of To-Dos for a release I would consider a 1.0. Here are the things I would like to propose:
- Finalizing the already almost done user registration feature to provide everyone his own dummy testnet accounts (at least as long as we / because we don’t have a sandbox client yet like Cardano or Ethereum)
- That allows me to implement the transaction parameters for value, gas and gas price (not done now because people would empty the public accounts then - still possible though currently if anyone really wants though)
- Supporting all SDKs in the code generator, so we can have them finally easily accessible to the user vs. the current un-unified documentations for all SDKs
- Type Breakdown - Example: If a contract requires input of the datatype “tip”, it’s not easily clear that the input must be, say, an object consisting of an address, a name and an amoun. Currently the editor would show as a hint the
tiptype, afterwards it would tell you what is actually expected:{"recipient": address, "name": string, "amount": int }and you know what to do. - Fixing two known issues: 1. In case of an error, not always the “best plausible” cause of the error is highlighted, 2. Some data types require to be explicitly wrapped in quotation marks, for no reasonable reason. (thanks @martingrigorov.chain for finding this).
- Adding Waellet support, so people can use the Editor for Mainnet operations (purposefully not supported in status quo for obvious reasons), or whatever other (private testing) network, and with their own accounts. This allows for easy interacting with and debugging of live production daepps. I did it like this a ton of times during the old Ethereum days.
- @philipp.chain rightfully asked about implementing the feature to dry-run contract calls, one of our coolest features in aeternity.
For this, the amount of 15 working days will suit.
Additionally: As I put more focus on the functionality, the UI can look / behave unwieldy every here and there. As I talked this over with @keno.chain already and gave him a brief overview on the code structure, I would like to propose that he writes a proposal on polishing the UI’s behaviour and make it state of the art.
Can everyone give a quick feedback on whether this Editor makes building on aeternity easier for you and which features you would like to see ?
AND ALSO: We’re looking for a new name! 
Please suggest ideas !
AEditor is unfortunately taken.
10 Likes
as I already mentioned in another thread I would like to see sth. like https://studio.ethereum.org/ to enable contraect development within the browser and I think you are on the right way and a subset of those features are already present.
more links:
- https://help.superblocks.com/en/collections/1865071-ethereum-studio
- https://superblocks.com/ (company that developed the studio)
what about AEstudio as name then?
what is the current state of the editor regarding custom types created within sophia? what if such type is needed as param in the init-method / constructor?
in my experience it was (and probably still is) often horrible to figure out in what presentation parameters need to be provided to the smart contract methods. it is often a “try and error” path which definitely isn’t a great developer experience.
if however possible I would like to see some kind of typescript integration so that contraect-instances which are used in the frontend application are typed so that the developer knows the format he needs to provide to all methods.
that would be really cool 
5 Likes
I’m usually quite satisfied by using VIM but the run-ins I’ve had with the Fire Editor has been nice!
From the things I’ve seen improving the error-reporting even further and perhaps also giving more hints, etc. would be helpful. I also agree with Philipp that it would be very beneficial to be able to dry-run things, not the least to get run-time errors from FATE while testing.
2 Likes
Unfortunately I am very busy with other projects within aeternity and can therefore not support you with the development effort in the next couple weeks. During this time I am happy to assist you with questions regarding ui/ux topics.
1 Like
@nikitafuchs.chain few things I was missing in trying to use the fire editor.
- choose if I want to dry run or transaction run, sometimes you want to transaction call a non stateful entrypoint, e.g. with remote contract calls
- attach amount to calls
2 Likes
Looks great @nikitafuchs.chain !
For me most the important feature would be the ability to attach an amount to calls, like philipp said.
Thanks for this nice editor. 
:pray:
2 Likes