I need to submit an article on smart contracts but it requires a section for a block of code describing how to create smart contracts for liquidity farming
Stack overflow was my first go to since I don't exactly have a solid background in coding, I only write articles for publication and I needed an executable block of code describing what I've written on 'Smart Contracts For Liquidity Farming'
Related
I'll be frank, I made a stupid mistake. In polygon network I deployed a NFT smart contract. I forgot to add withdraw function in my smart contract. Can we add this function to my smart contract that already deployed.
You can see the smart contract code in here:
https://polygonscan.com/address/0xeCd093eD38449d8d64bb015D97072BdcaA594832#code
Unfortunately, you cannot.
Upgrading smart contracts is not possible on EVM chains unless the contracts were designed for it. You can read more on the topic on Ethereum StackExchange.
I also suggest you test you minimally unit tests contracts before deploying.
I am just learning BPMN 2.0 modeling language.
I have to design a call center process where an operator asks several questions to a customer.
I am wondering if I need to model a message flow between customer and operator for every question (as the exchange information) or if a message flow is only needed if real documents are exchanged (e.g. an invoice is sent).
Thanks!
Let's look at the definitions in the BPMN 2.0.1 specifications (highlighting from me):
Message: An Object that depicts the contents of a communication between two Participants. A message is transmitted through a Message Flow and has an identity that can be used for alternative branching of a Process through the Event-Based Exclusive Gateway.
Message flow: A Connecting Object that shows the flow of messages between two Participants. A Message Flow is represented by a dashed lined.
So the message is not necessarily a business document that is exchanged, but any kind of communication, including spoken exchange.
The granularity of the messages depends on what you want to show in the model:
If the question/answer is just a detail in a larger process, you may want to show one summary interaction corresponding to the questions and another in reverse direction for the answers, and consider that all the questions are asked at once and all the answers provided at once, even if this does not fully correspond to reality.
If you're interested exactly in the details of the question/answer because for example different participants are involved at different stages of the Q&A, you may well single out each question and each answer separately according to the real flow. But be careful, since too detailed flows might be difficult to maintain, so some degree of abstraction is recommended.
If your interest is in very detailed dialogue scripts between a customer and the same operator, BPMN might not be the best tool: more specialised conversation flows, job stories or intent based scripts could be more appropriate (see more about the topic in this article on chatbot requirements)
I am looking for a good resource for solidity advanced smart contracts development free resource or books.
Scenarios like
- Crowdsale
- Insurance sector
- Banking
I have done some research on Open Zepplin which is a good resource for smart contracts but there is not a good explanation.
Any resource related help from the community will be appreciated.
I've made 2 videos but the demand on such content is still not really high so I stopped recording new ones.
Part 1
Part 2
And I also have a repository which contains working contracts of token and kind of advanced crowdsale which is using Oracles, whitelist, bonuses, referall program, etc. It is pretty easy to start to play with because we've put everything into docker containers
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
How can I differentiate a Workflow system from a normal application that automates some work? Are there any specific feature a system must have to be categorized as a workflow system?
Workflow systems manage objects (often logically or actual electronic replacements for documents) that have an associated state. The state of an object in the system is node in a state machine (or a Petri net).
State transitions move an object from one state to another. The transitions can be triggered by people, automated events, timers, calendars, etc. Usually the transitions represent steps in a process in the real world.
That's pretty abstract, so consider an example: bug tracking software. A bug report probably starts out unvalidated, and as such is in a QA tester's queue. The QA tester will validate the report and make sure the steps are clear, grade the report for severity etc., and assign it to a developer or developer group. It is then in the developer's queue, who will ultimately fix or decide not to fix the bug, which will send it back to QA for validation. If there's a dispute over the bug, it might go into a state in which it bubbles up the management stack.
A trivial implementation of the above is to use an enumeration for the state associated with every object, and make everybody's inbox be a query for objects with a state of a particular enumeration value.
That's the gist of it, but things can get more complex, such as splitting off new objects, reacting to non-human events such as timing, internal or external (i.e. third-party) services, etc.
A workflow management system pushes users through a process that hops across more than one function within a system and potentially more than one participant in the workflow. The workflow engine knows about the state of the process, and stashes this in its own storage, which may or may not be a part of the main application database.
Workflows can be modelled using state machines, petri nets or various other constructs, including plain old scripting languages. An independent orchestration system can be used to manage workflows across multiple applications. Many (but not all) support BPEL (Business Process Execution Language) as a standard description language for workflows. If your applications are set up as a service-oriented architecture the workflow system can control the application functionality to do this. The other feature of a workflow engine is that it should be possible to abort the workflow and undo any state changes while maintaining database consistency.
www.workflowpatterns.com has a collection of documents about workflow systems, along with a library of patterns.
Examples of applications for workflow systems:
Insurance Claims Administration. Essentially the grand-daddy of them all. Typically this process will have rules covering who can authorise how much, who can process claims on different classes of business, what documents need to be present and linked to provide an audit trail, issuing and tracking the issue of payments and authorising loss-adjustment work. A typical claims workflow would track a claim from notification to authorisation of reserves and payments, through to issuing the payment, with side-processes for arranging loss-adjustment work (possibly through third parties), holding payment authority until this is finished and issuing and paying loss-adjusting expenses. In practice, these processes can get quite complicated.
Ordering, quoting and configuration management of a complex product such as a computer system.
One unusual example was a system developed by a pharmaceutical manufacturer that tracked the approval process for a new pharmaceutical product. This also incorporated an expert system that had the regulatory framework coded in it and could pick a shortest path through the regulatory hoops. This dropped their average R&D life-cycle time to market from 9 years to 5.5 years.
I would consider the application a workflow system if the user is guided through the business process without to the need to refer to any external documentation of that business process.
Expanding on Barry's bug tracking example I would say your bug tracking application is a workflow application if for example there is a button called "Close" that when pressed transitions the bug into a closed state, maybe allows the user to enter a closing comment, records the timestamp and user name and then sends an notification e-mail.
It is not a workflow system if the user has to pick the new state from a drop down and then send a notification e-mail himself.
I don't thing there is a precise definition. Here are some loose criteria:
coordinates the work of more then one person (but not groupware),
in a complex, organizational setting,
usually as part of a managed business process (as in BPM).
What is workflow?
The automation of a business process,
in whole or part, during which
documents, information or tasks are
passed from one participant* to
another for action, according to a set
of procedural rules.
*participant = resource (human or machine)
In my opinion, there are two types of workflow in terms of software. Static (or built-in) workflow and dynamic (programmable) workflow. Many document management, bug tracking, or even blog software have built-in workflow using simple state transition.
When people say "workflow," I think they generally mean the ones that you can program business logics into some existing software, like if the inventory is short on carrots, call sysco automatically.
For a real-life example of workflow feature, see Microsoft Dynamics CRM.
What is the best practice for writing a rather large wcf service, containing a lot of OperationContracts and DataContracts?
How would I separate functional areas into several contracts, would it be best to create an endpoint for each functional area?
Is there any way to keep the source for the different parts apart, but still use only one service for all of them?
Where do I get good information how to plan the contracts, what to include, how to split...?
That's been a big question surrounding services since their inception. SOA done successfully is SOA planned to the extent you're talking about. Having said that, I've always leaned more toward splitting services out, but using them in a composite manner. That is, several endpoints when you have several contracts, but most of them are only consumed by a few endpoints that are consumed by non-service callers. (wow, that was a mouthful, did it even make sense?)
Also, I would advise to have as few contracts as possible. Too many contracts can lead to poor manageability. Good contract design will help limit the number of endpoints and service calls. Removing OO concepts from contract design is one way of doing so. Contract design is a massive topic in itself, but suffice it to say that through good contract planning (up front), comes good service design.
Maarten Mullender writes a great blog on WCF design, and is a must read. There are also some great SOA/WCF books emerging as well.
Some good books:
Pro WCF: Practical Microsoft SOA Implementation
Programming WCF
I'll go off the track here and say I've used monolithic WCF contracts, functionally separated contracts (with a maximum of ten methods along Juval's guidelines in his book), and I've also tried a message handling architecture where a service has a single method that takes a base message, and handlers that 'know' how to unwrap and process the message after it crosses the wire.
I'm a big fan of the latter if you've got .NET on both sides of the fence. Oren has a screencast on the idea with code. I don't know what your needs are but this is working for me.
http://ayende.com/Blog/archive/2008/03/30/Hibernating-Rhinos-8--Going-Distributed-amp-Building-our-own.aspx
That said if you're already coming from "I need a large WCF service" then going to one method is probably not going to cut it for you. If that's true then Juval Lowy's Programming WCF Services is the standard you should uphold in your design.
This has been helpful to me it comes from the idesign.net website and it was authored by Juval Lowy:
WCF Coding Standard
I have a post here about how individual operations should differ from traditional code operations:
http://www.iserviceoriented.com/blog/post/Introduction+to+Service+Oriented+Architecture.aspx
You should end up only with operations for actual business events. If you ever stop and think "I need to enable transaction support on my web service" that means you haven't designed the operation with a wide enough scope. You should never have to enable web service transaction support.
I highly recommend Bill Poole's blog for higher level SOA concepts. Here's a post to get started:
http://feeds.feedburner.com/~r/BillPoolesCreativeAbrasion/~3/328955489/service-contract-stability.html
I know this is an old post but I am thinking of services in the same way as I think of objects in programming.
Keep them to their bare minimum for what they must do. Of course not to go to the extreme, but I am making my decisions based on data entities.
One service for Account, one for Product etc.
Not sure what anyone would think of that though...