I would like to use the Solidity language to write a code of smart-contracts.
My code should be about a transfer of real estate`s assets, by spares the middlemen as much as possible.
My questions:
What are my options to create GUI and combine solidity code with it?
My GUI should be similar as much as possible to JavaFX.
Haim
You have to create Distributed Application to interact with the Smart Contract. For the development of GUI I used the Truffle Framework with the Angular Box. Truffle framework provides boxes for different technologies. The Angular box has the basic files to start with. Angular App also help you to organize your code well.
For interacting with the Smart Contract you need the Web3 libraray. The web3 library provides you interface to interact with the blockchain.
You can use React to create UI. As using react with ethereum has lot of advantages
Related
I'm trying to learn and use Fuchsia for fun, and a pretty basic concept is keeping me from progressing.
I thought that, as a learning experience, I could write a simple HTTP client that prints the content of some random URL to the log. Really nothing fancy.
As I understand, using the network (in my case I'd like to utilize fuchsia.net.http.Loader) is a capability, which has to be granted to a running component. Makes sense, that's pretty much the core of the OS.
I also understand that the initiating component, the one that runs my component, needs to grant this capability to my component. That's fair.
What I don't understand, and I'd very much appreciate any additional information (pretty please!) is how I can grant this to my component?
Specifically all demos and examples I saw had a custom client & server under a realm, which talked to each other. That's a good practice, but it doesn't bring in any capability that's built in.
What am I missing? Thanks in advance!
I'm trying to learn and use Fuchsia for fun, and a pretty basic concept is keeping me from progressing.
Thanks for your interest in Fuchsia! First of all, if you haven't already gone through Fuchsia Fundamentals I would strongly suggest that as a starting point for many of the foundational concepts.
Specifically all demos and examples I saw had a custom client & server under a realm, which talked to each other. That's a good practice, but it doesn't bring in any capability that's built in.
This is primarily because there's isn't necessarily a concept of any set of components or capabilities being "built in" to the system. The capabilities available to components in the system are entirely dependent on the rest of the components in a particular product build and how they are organized (this is called the component topology).
I thought that, as a learning experience, I could write a simple HTTP client that prints the content of some random URL to the log. Really nothing fancy.
The answer has a few sharp edges to it at the moment, as Fuchsia is a rapidly evolving open source project. Hopefully some of the details below will help you move forward.
Determine the capability routes
So you'll have to do a bit of work to figure out where the capability you need is provided and routed. In fact, one of the components exercises shows you how to do this for the fuchsia.net.http.Loader capability. Knowing where a capability is offered/used allows you to determine where your component would need to be instantiated to obtain the necessary capability.
You might also find some of the content in the Connect components developer guide useful in accessing the capability.
Run the component
Knowing where a capability is routed allows you to determine how to run your component. The most straightforward way of instantiating a component in the topology is to do so dynamically using ffx component. However, this requires a collection somewhere on the system with the capabilities you need. The ffx-laboratory realm where most examples are run has a very limited set of capabilities that does not include fuchsia.net.http.Loader.
You'll likely need to add your component statically to the topology using a core realm shard so that the necessary routes can be declared explicitly between the components that offer fuchsia.net.http.Loader and your component. With the component included statically in your product build, you can execute it using ffx component commands.
For more details on component execution, check out the Run components developer guide as well.
Run a CLI binary
Since this is a learning exercise, another option is to build your code as a binary that runs within the context of a component that already has the capabilities you need vs. creating and running an entirely new component. This is commonly used for CLI tools. With the ffx component explore command you can run your code as a binary inside the existing component that provides the HTTP capability you are looking for using the --tools argument, without the need to work through all the capability routing pieces described above.
For more details on ffx component explore, see Explore components.
I'm aware of Etherscan's capability for interactions with smart contracts on the Ethereum network, but I wonder if there is any other way to read and write from smart contracts.
I'd expect an improved UI/UX usability, allowing input validation, adding documentation on top of the contract etc, yet I couldn't find any other service providing it.
You could use https://remix.ethereum.org/
There is no service that I know that can provide documentation on top of the contract.
But, it's possible to develop one. Are you interested in how it can be done?
The only one I know of is Remix. This is a great tool for smart contract testing and interaction
And if you are planning to develop your own UI with an API. This is not the exact solution but check out drizzle. It has some good built in features which will get you started on the front-end parts and showing blockchain data
Both tools presented below load the ABI automatically from the contract address.
eth95.dev
There is one that looks like old Windows 95 app. Pretty cool.
https://eth95.dev/
mycrypto.com
https://app.mycrypto.com/interact-with-contracts
I want to ask this because I want to know developer perspective about developing from scratch mobile games.
Let's say the project is already going to start its development.
I am already aware of the specification of the project example.
Logic, Browser/devices to support, IDE to be used.
What should be the first thing to do.
Create the UI/UX designs for all devices with no functionality
and after the designs are finalized then integrate functionality
Create functionality logic then do design
Do design and functionality together
which of these will save much more time.
please share your experiences about this development and how to make out of it
so that failure of delivering the project will be at its minimum errors
Every of these aproaches may work, however I will tell you about my experience.
I did a lot of different projects using points you provide in the question, but for me the easiest and most successful approach was logic first, design second.
How to start using this approach?
Think about use case at first. For example, user should be able to register in the game.
Implement database structure(if needed). For example, create table 'Users'.
Implement data access logic. For example, write code that saves a username and a password.
Create service layer with use case's (business) logic implementation . For example, you can write saveUser method.
Create a simple(ugly) UI that allows you to feel the use case and to test it.
Pay guru designer to create clean design. For example, a design of the registration page.
Сontinue with step 1.
Advantages?
Allows to create really working MVP with ease.
UI manipulates only real and dynamic data.
Allows you to build foundation first.
To start with, please be sorry, I just start developping applications on AWS and I have some question that could be easy for you but not really for me... But impossible to find any response about web integration of a java website on SWF...
I'm also a new user of the spring framework, I need to do some tutorials about it (or not? SWF documentation can be enough?). But my questions are for those who have already passed time on it and can say what is the best aproach in my case. (And why?)
What is the good approach in UI design to have a web based application with ui dynamic changes? (like content slide, menu, etc... the most scalable choice)
Having the view (GWT web interface running on Elastic Beanstalk for example, or a CloudFront PHP interface using a good MVC PHP Framework?) separated from the model running on SWF? All linked by the API's.
Or having my complete web application using Flow FrameWork and GWT? (or another technology? For now I chosed this even if I have to work tutorials too, but why not using the new Dart Google's solution?)
What is the easiest approach to do it efficiently?
I understood the SWF logical approach, and I have all my project's architecture (so the scalable SWF Model) in my head, but clearly, if I want to add a new service in my project and if this service wants to get a list of existing objects (stocked in DynamoDB for example), i'd like to show this information easily because I already did it for this object.
And so, with a copy of the model on the PHP interface, I imagine I could associate methods to show this object, and so concentrate the PHP projet for showing my objects and start workflows with PHP (search and read-only?), and SWF to have a good working model launching those WF. Is it a good approach? Is there a PHP framework really adapted to do this? Rather, I do it on a non-swf java UI application?
Finally I found what I was searching about. To connect an UI interface, we have just to use good classes of the SDKs :
http://docs.amazonwebservices.com/AWSSDKforPHP/latest/index.html#i=AmazonSWF
http://docs.amazonwebservices.com/AWSJavaSDK/latest/javadoc/index.html
My question was really simple, but I wasn't able to understand the entire SWF architecture.
So the solution is to implement the application's MODEL-CONTROLER with the SWF Flow FrameWork, and after that, we can connect the VIEWs with any of the SDK to start workflows. We can also connect an Android or iPhone application easily with the good SDK.
We maintain a system that has over a million lines of COBOL code. Does someone have suggestions about how to migrate to a GUI (probably Windows based) without losing all the business logic we have written in COBOL? And yes, some of the business logic is buried inside the current user interface.
If it was me I would look into something like this:
NetCobol for Windows
It should be fairly easy to wrap your COBOL with an interface that exposes the functionality (if it isn't already written that way) and then call it from a .NET application.
It took us about 15 years to get off of our mainframe, because we didn't do something like this.
Writing a screen scraper is probably your best bet. Some of the major ERP systems have done this for years during a transition from server based apps to 3-tier applications. One i have worked with had loads of interesting features such as drop down lists for regularly used fields, date pop ups and even client based macro languages based on the scraping input.
These weren't great but worked well for the clients and made sure the applications still worked in a reliable fashion.
There is a lot of different ways to put this together, but if you put some thought into it you could probably use java or .net to create a desktop based application and with a little extra effort make a web based implementation.
Microfocus provide a tool called Enterprise Server which allows COBOL to interact with web services.
If you have a COBOL program A and another COBOL program B and A calls B via the interface section, the tool allows you to expose B's interface section as a web service.
For program A, you then generate a client proxy and A can now call B via a web service.
Of course, because B now has a web service any other type of program (command line, Windows application, Java, ASP etc.) can now also call it.
Using this approach, you can "nibble away at the edges" to move the GUI to a modern, browser based approach using something like ASP while still utilising the COBOL business engine.
And once you have a decent set of web services, these can be used for any new development which provides a way of moving away from COBOL in the longer term.
You could use an ESB to expose the back-end legacy services, and then code your GUI to invoke the services via the ESB.
Then you can begin replacing the legacy services with implementations on your new platform of choice.
The GUI need not be aware of the cut-over of back-end service implementation, as long as the interface to the service does not change - minor changes may hidden from the GUI by the ESB.
Business logic that resides in the legacy user interface layer will need to be refactored by extracting the business logic and exposing it as new services on the new platform to be consumed by the new GUI via the ESB.
As for the choice of platform for the new GUI, why not consider a web-based UI rather than a native windows platform, then at least updates to the UI will only need to be applied to the web-server rather than having to roll-out changes to each individual work-station.