I am still learning. I have built a web3/js based front end that deploys and interacts with a contract where others can contribute ETH (a kickstarter-type contract). Everything works fine, with MetaMask kicking in for any payable transaction. I then built a front/back end app using Go. I deployed the same Solidity contract and ran it through abigen to produce a Golang bindings file. I can interact with the contract bind file only by hard-coding my private key, or passing it through the front end.
What I can't find info on is how to integrate MetaMask with the bindings, so other folks can contribute to the contract. I'd very much appreciate knowing if this is even possible, and if so, could you point me in the right direction? I've got this far but I'm stumped!
Thanks very much.
Related
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
There's no doubt to the benefits of API Gatway+Lambda for a micro-services.
My concern is what would happen if we decide to move off API Gateway+Lambda to ECS/Fargate, or even another Cloud.
There seems to be a consensus on using one Lambda function per route/action.
I have some theories about how to design using this approach such that the code can be unplugged from Lambda and plugged-in some where else.
I would also like to know what others in the community have done to achieve this? Has anyone attempted to move the API off Lambda and was able to successfully do it using XXXX design? What are the lessons there?
The language should not really matter to this discussion but we are using python3
What you're facing right now has a name. It's called "vendor lock in". Pretty much nothing you can do about it.
However, I find it useful to treat AWS Lambda handler function as a controller in your web server. What would you do in your controller? You'd validate incoming data, pass it to service layer and then serialize response from the service and pass it back to API Gateway. Long story short, your handler function should not contain business logic, which makes it easy to migrate even from serverless to servers. It's also can be good because it leaves some place for optimization. If you end up seeing that your service layer architecture adds significant time to cold start, then just denormalize it to a single file. It'll work faster, but you'll sacrifice code maintainability. There is no silver bullet, software has always been about trade offs. :)
I want to do Behavior Driven Development (BDD) on Google Cloud. I've written out my BDD stories and it looks like a basic web app will satisfy the requirements. I'd like to use AngularJS for writing client code and Java for the server because these are what I'm most familiar with. I'm also somewhat familiar with Maven.
How do I get started in a way that allows me to focus on writing the code?
1] Select a Google Cloud Service (App Engine, Compute Engine, Container Engine)?
2] Find and copy a Hello World example for any technology that also has as many of the other components as I want to use (JBehave for BDD, AngularJS, Java, a Google Cloud service above)? But which component's getting-started guide should I start with so that the other components integrate easily?
3] Find a suitable Maven archetype?
4] Investigate Spring.io? I've heard that Spring.io tries to make it easy for developers to focus on coding. But I don't know much else about it.
I'd like to spend as little time as possible setting up the project so that I can start doing Behavior Driven Development as quickly as possible. What I normally find happens with a project like this is I lock down one of the decisions about which technology to use, follow their getting started guide, but then run into a brick wall when I start integrating the other components.
How do I start this project so I can spend the least amount of time on non-coding aspects as possible?
Personally, I would not focus on where to execute the system. I my world, development is done on a local computer. CI is done somewhere else and the final artifacts are executed somewhere. This somewhere must be possible to deploy to from your CI build so you can verify that it actually works before deploying.
I would start by building something that works local on my computer, then move forward. I would not spend any time searching for a Maven archetype, I would slowly build my project manually. This may sound as a slow way of doing it, but it will give me knowledge about what is happening. The magic added is magic I have added and therefore no magic.
Where should you start then? I suggest to start by cloning https://github.com/cucumber/cucumber-java-skeleton and extend it with the business functionality you need. If you need more technology, add it when you need it. Not before you need it. My experience is that I usually need less technical stuff than one could imagine from the start. And definitely not the tooling I could think of before I started the project.
One approach is to think front to back or back to front. Thinking front to back means starting with the user interface and once that's built, create the middle tiers, and finally the back end.
The problem with starting with the user interface though is that you can't really verify that it works without a backend. But I believe that's a problem Dependency Injection (DI) solves. You build the user interface and wherever it needs to call the next layer down in the stack (e.g. the server APIs), you instead give it a mock server to call. You can implement enough of the mock server to make the BDD stories pass for the user interface. When every BDD story passes for the user interface, you can then build the next layer down in the stack.
It should be possible to get started with developing the user interface by finding a Hello World example for the front-end technology (AngularJS). Look for a Hello World example that incorporates the two necessary pieces for testing: BDD and Dependency Injection. If you can't find one, then just start with the AngularJS Hello World, get it running. Then as a separate task go do a Hello World for BDD and hopefully it will be apparent after learning how to get BDD working to get BDD working with the AngularJS project. Then do the same for Dependency Injection. Hopefully, that gets you to the point of having an AngularJS fully implemented front-end that you can verify works with BDD and Dependency Injection.
Then you can work on the middle tier. You could set it up as a separate project, independent of the AngularJS project so that you don't have to worry about the hassles of combining code from two layers of the stack into one project. Maven should be able to do that but documentation for Maven tends not to be as easy to use.
To develop the middle tier, find a Hello World example for developing a REST-based API server that runs on Google Cloud. You don't need the front or the back end at this point. The front end can be simulated by the BDD stories and the back end can be simulated by DI. Once all of the BDD stories pass for the middle layer, then you can build the back-end.
Developing the back-end is similar to building the middle-layer. Find a Hello World example for developing a database application that runs on Google Cloud. Most likely the relevant technology is the Google Datastore using Objectify as an Objected Oriented wrapper. But let's call this layer the service layer because there should be a layer of abstraction between the REST API and the datastore. The complication here is might not be very straightforward to develop this layer independently of the middle-tier, but try if possible to do that. In other words, create a separate project that's based on a Google Datastore Hello World example. Use BDD to simulate the middle-tier. You might not need DI anymore because you're at the bottom of the stack, just call the datastore directly. But DI might be useful anyway if it's not possible to run the datastore on your local machine where you're developing.
Now that you have BDD stories functioning on all three layers (User Interface front-end, REST API middle-tier, service layer back-end), now start making it work on the production servers. I'm not confident this is the best approach though because it seems like a lot of complications could arise in this final step. Theoretically, if each layer passed the BDD tests, then it should all zip up together nicely. But integrating it all together might not go that smoothly. One strategy for making sure it goes smoothly is to map each layer onto its own dedicated production system. If each piece ran smoothly on a development machine, shouldn't it run smoothly on a production machine?
Well hopefully, but I'm hoping someone else will propose a better approach that allows someone to spend an even higher proportion of time on coding and a lower proportion of time on this DevOps stuff.
I've built an app using arrowDB for the backend. Is there a simple way to duplicate development data to production?
Seems like an oversight not to be able to do this, have an app going through review process and just realised all our test data won't be accessible
As far as I know, there is no feature like this right now.
You could probably build your own using their REST API. I haven't seen a solution like this built yet but I definitely think it is possible. If I get some free time, I will try to put one together and will post a link here.
First off, The Problem:
We have a Web App with a Flash front-end that talks to our ASP.NET web service via SOAP which then deals with all of our server side code (C#).
Right now, we implement a simple user sign on in our application, storing the info in our MSSQL DB.
A client has requested what I understand to be Windows authentication through our application using the currently logged in user.
So, I have been tasked with investigating this. Nobody, including myself, has any experience in this area.
I have been reading up on some basic Active Directory information, and some simple tutorials. I understand how to get access to the directory using ADSI through code. What I'm really interested in seeing is how the entire thing should be architected. I don't want to throw together a hacky solution.
Does anyone know of a good tutorial for this kind of thing or have any advice on getting started? More importantly, does this even sound viable?
I know I haven't given much information, but feel free to ask and I will provide answers.
Thanks.
Edit:
Will, to give you an idea of the scope of this, the network will include every computer in a large hospital. So yes, this is huge. Clearly I need to start small. I would like to come up with something that will work at my office first. Maybe ~10 Windows computers on a single domain. One Domain Controller.
I am also open to any good books on the subject.
If you are going to tie into Active Directory you will want to take a look at the System.DirectoryServices namespace. The implementations can vary wildly depending on your system architecture, but this should give you a good starting point.
Enjoy!