The API endpoint is: https://etherchain.org/api/gasnow
And a typical response is:
{
"code": 200,
"data": {
"rapid": 25455811243,
"fast": 22752911470,
"standard": 11000000000,
"priceUSD": 3035.06,
}
}
So how can I convert those rapid, fast, or standard values to an estimated USD cost.
Also: I am just trying to show an estimated gas cost for ETH on a website so if anyone has a different API/way to accomplish this that would work.
Thanks for any help.
These are prices per gas unit in wei.
A regular transaction to a non-contract address costs 21 thousand gas units.
So with the "rapid" example of 25455811243 wei per gas unit, that's 534572036103000 wei (or ~0.00053 ETH) for a regular transaction. Multiplied by the 3035.06 USD per 1 ETH, that rounds to $1.62.
Related
I want to write data to CloudWatch using the AWS-SDK (or whatever may work).
I see this:
The only method that looks remotely like publishing data to CloudWatch is the putMetricData method..but it's hard to find an example of using this.
Does anyone know how to publish data to CloudWatch?
When I call this:
cw.putMetricData({
Namespace: 'ec2-memory-usage',
MetricData: [{
MetricName:'first',
Timestamp: new Date()
}]
}, (err, result) => {
console.log({err, result});
});
I get this error:
{ err:
{ InvalidParameterCombination: At least one of the parameters must be specified.
at Request.extractError (/Users/alex/codes/interos/jenkins-jobs/jobs/check-memory-ec2-instances/node_modules/aws-sdk/lib/protocol/query.js:50:29)
at Request.callListeners (/Users/alex/codes/interos/jenkins-jobs/jobs/check-memory-ec2-instances/node_modules/aws-sdk/lib/sequential_executor.js:106:20)
at Request.emit (/Users/alex/codes/interos/jenkins-jobs/jobs/check-memory-ec2-instances/node_modules/aws-sdk/lib/sequential_executor.js:78:10)
at Request.emit (/Users/alex/codes/interos/jenkins-jobs/jobs/check-memory-ec2-instances/node_modules/aws-sdk/lib/request.js:683:14)
at Request.transition (/Users/alex/codes/interos/jenkins-jobs/jobs/check-memory-ec2-instances/node_modules/aws-sdk/lib/request.js:22:10)
at AcceptorStateMachine.runTo (/Users/alex/codes/interos/jenkins-jobs/jobs/check-memory-ec2-instances/node_modules/aws-sdk/lib/state_machine.js:14:12)
at /Users/alex/codes/interos/jenkins-jobs/jobs/check-memory-ec2-instances/node_modules/aws-sdk/lib/state_machine.js:26:10
at Request.<anonymous> (/Users/alex/codes/interos/jenkins-jobs/jobs/check-memory-ec2-instances/node_modules/aws-sdk/lib/request.js:38:9)
at Request.<anonymous> (/Users/alex/codes/interos/jenkins-jobs/jobs/check-memory-ec2-instances/node_modules/aws-sdk/lib/request.js:685:12)
at Request.callListeners (/Users/alex/codes/interos/jenkins-jobs/jobs/check-memory-ec2-instances/node_modules/aws-sdk/lib/sequential_executor.js:116:18)
message: 'At least one of the parameters must be specified.',
code: 'InvalidParameterCombination',
time: 2019-07-08T19:41:41.191Z,
requestId: '688a4ff3-a1b8-11e9-967e-431915ff0070',
statusCode: 400,
retryable: false,
retryDelay: 7.89360948163893 },
result: null }
You're getting this error because you're not specifying any metric data. You're only setting the metric name and the timestamp. You also need to send some values for the metric.
Let's say your application is measuring the latency of requests and you observed 5 requests, with latencies 100ms, 500ms, 200ms, 200ms and 400ms. You have few options for getting this data into CloudWatch (hence the At least one of the parameters must be specified. error).
You can publish these 5 values one at a time by setting the Value within the metric data object. This is the simplest way to do it. CloudWatch does all the aggregation for you and you get percentiles on your metrics. I would not recommended this approach if you need to publish many observations. This option will result in the most requests made to CloudWatch, which may result in a big bill or throttling from CloudWatch side if you start publishing too many observations.
For example:
MetricData: [{
MetricName:'first',
Timestamp: new Date(),
Value: 100
}]
You can aggregate the data yourself and construct and publish the StatisticValues. This is more complex on your end, but results in the fewest requests to CloudWatch. You can aggregate for a minute for example and execute 1 put per metric every minute. This will not give you percentiles (since you're aggregating data on your end, CloudWatch doesn't know the exact values you observed). I would recommend this if you do not need percentiles.
For example:
MetricData: [{
MetricName:'first',
Timestamp: new Date(),
StatisticValues: {
Maximum: 500,
Minimum: 100,
SampleCount: 5,
Sum: 1400
}
}]
You can count the observations and publish Values and Counts. This is kinda the best of both worlds. There is some complexity on your end, but counting is arguably easier than aggregating into StatisticValues. You're still sending every observation so CloudWatch will do the aggregation for you, so you'll get percentiles. The format also allows more data to be sent than in the option 1. I would recommend this if you need percentiles.
For example:
MetricData: [{
MetricName:'first',
Timestamp: new Date(),
Values: [100, 200, 400, 500],
Counts: [1, 2, 1, 1]
}]
See here for more details for each option: https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/CloudWatch.html#putMetricData-property
What is the proper JSON syntax to update a multi-choice list item field using the Microsoft Graph?
Multi choice fields return a json array of strings like:
GET: /v1.0/sites/{siteId}/lists/{listId}/items/{itemId}
"CAG_x0020_Process_x0020_Status": [
"Proposed Funding - Customer Billed",
"Proposed Funding - Sales Funded",
"SOW - Needed"
]
However, when using the same syntax to update the field a 400 invalid request is returned.
PATCH: /v1.0/sites/{siteId}/lists/{listId}/items/{itemId}/fields
"CAG_x0020_Process_x0020_Status": [
"Proposed Funding - Customer Billed",
"Proposed Funding - Sales Funded",
"SOW - Needed"
]
Error returned:
{
"error": {
"code": "invalidRequest",
"message": "The request is malformed or incorrect.",
"innerError": {
"request-id": "2251e25f-e4ce-491f-beb9-e463c7d8d5af",
"date": "2018-05-16T15:16:23"
}
}
}
I am able to update all other fields requested, but this last field is holding up a release of the application.
To elaborate on what #muhammad-obaidullah-ather wrote in the comments, for string multiple choices you need to define the type as Collection(Edm.String) and then his solutions works for me. Repeating what he wrote as complete answer.
This should be sent as a PATCH like this:
PATCH /v1.0/sites/{SiteId}/lists/{ListId}/items/{ItemId}/fields
{"*FieldName*#odata.type":"Collection(Edm.String)","*FieldName*":["*Value1*","*Value2*"]}
This works for me
graph.api(url)
.version('beta')
.post({
'fields': {
'AssignedToLookupId#odata.type': 'Collection(Edm.Int32)',
'AssignedToLookupId': [5,13]
}
});
Unfortunately, a number of column types, including MultiChoice, cannot be updated via Microsoft Graph today. I would recommend adding this to the Office Dev UserVoice so it remains on the radar of the SharePoint/Graph team.
1) a) You have a list of addresses. Use Google APIs to calculate the timezones of each location object and then return output as this same array of objects, with each object comprising of following values -
[{
"id":"1",
"address":"Plot 5, CDCL Building, Chandigarh"m
"latitude":"30.123123",
"longitude":"76.123213"
"timezone":"-330", //in minutes
"UTC_time":"2016-10-18 5:30:00 AM"
}]
b) Now write an algorithm, to divide this array into least no. of sub-arrays, such that difference between the minimum UTC_time and maximum UTC_time in that array is less than or equal to 4 hrs.
2) Parse the attached html file and generate a JSON file as output, which contains all the key
FORMAT
Test Duration- 5 Hours
Test Date -27 October,2016
Format to be send in : "Student name- college name -roll number- 2016"||
Email Id - kunal#tookanapp.com ( All the students need to send their test on the mentioned email ID in the mentioned format )
Start Time - 11.00 AM
End Time - 4.00 PM
Just go through this link.You will get the answer.
https://developers.google.com/maps/documentation/timezone/intro
This is an algorithm not a program::--
initialise i, ar [100],d ;
MAX UTC_time= +14:00(150°);
Min UTC_time=-12:00 (180°);
for min UTC_time initialise to -12:00;
min UTC_time <=+14:00
If min UTC_time > +10:00
Then d=max UTC _time - min UTC_time;
And then print d;
Else
Min UTC_time++;
Link is :--
https://maps.googleapis.com/maps/api/timezone/json?location=39.6034810,-119.6822510×tamp=1331766000&key=YOUR_API_KEY
{
"dstOffset" : 0,
"rawOffset" : -28800,
"status" : "OK",
"timeZoneId" : "America/Los_Angeles",
"timeZoneName" : "Pacific Standard Time"
}
In html language......
OK
-28800.0000000
0.0000000
America/Los_Angeles
Pacific Standard Time
time_zone_name>
Me and my colleague are working on REST API. We've been arguing quite a lot whether status of a resource/item should be a string or an integer---we both need to read, understand and modify this resource (using separate applications). As this is a very general subject, google did not help to settle this argument. I wonder what is your experience and which way is better.
For example, let's say we have Job resource, which is accesible through URI http://example.com/api/jobs/someid and it has the following JSON representation which is stored in NoSQL DB:
JOB A:
{
"id": "someid",
"name": "somename",
"status": "finished" // or "created", "failed", "compile_error"
}
So my question is - maybe it should be more like following?
JOB B:
{
"id": "someid",
"name": "somename",
"status": 0 // or 1, 2, 3, ...
}
In both cases each of us would have to create a map, that we use to make sense of status in our application logic. But I myself am leaning towards first one, as it is far more readable... You can also easily mix up '0' (string) and 0 (number).
However, as the API is consumed by machines, readability is not that important. Using numbers also has some other advantages - it is widely accepted when working with applications in console and can be beneficial when you want to include arbitrary new failed statuses, say:
status == 50 - means you have problem with network component X,
status > 100 - means some multiple special cases.
When you have numbers, you don't need to make up all those string names for them. So which way is best in you opinion? Maybe we need multiple fields (this could make matters a bit confusing):
JOB C:
{
"id": "someid",
"name": "somename",
"status": 0, // or 1, 2, 3...
"error_type": "compile_error",
"error_message": "You coding skill has failed. Please go away"
}
Personally I would look at handling this situation with a combination of both approaches you have mentioned. I would store the statuses as integers within a database, but would create an enumeration or class of constants to map status names to numeric status values.
For example (in C#):
public enum StatusType
{
Created = 0,
Failed = 1,
Compile_Error = 2,
// Add any further statuses here.
}
You could then convert the numeric status stored in the database to an instance of this enumeration, and use this for decision making throughout your code.
For example (in C#):
StatusType status = (StatusType) storedStatus;
if(status == StatusType.Created)
{
// Status is created.
}
else
{
// Handle any other statuses here.
}
If you're being pedantic, you could also store these mappings in your DB.
For access via an API, you could go either way depending on your requirements. You could even return a result with both the status number and status text:
object YourObject
{
status_code = 0,
status = "Failed"
}
You could also create an API to retrieve the status name from a code. However returning both the status code and name in the API would be the best from a performance standpoint.
I have such problem with couchbase design: Query for view returns 40000 records. I need to add additional filter on them and get "top 100 order by".
I made such filtration/sorting in my application code this means I must fetch 40000 records from Couchbase (and this is time-consuming). Is there a way to execute filter/sort onto couchbase node (without fetching whole 4000 records to appserver)?
My data is touristic tours ie
{
"OT": "tour",
"dd": 20140720,
"city": 1206,
"hotel": 9656,
"stars": 2,
"resort": 23415,
"country": 34,
"price": 24139,
"priceType": 1,
"tickets": "QQYY",
"nights": 5,
"food": 4,
"oper": 18,
"adult": 1,
"ch": 0,
"ch1": 0,
"ch2": 0,
"ch3": 0,
"avail": 1,
"stop": "Q"
}
and i need to select top 10 cheapest tours from London to turkey between 20140622 and 20140710 in 4 or 5 stars hotel...
My view looks like:
function (doc, meta) {
if(meta.type==='json' && doc.OT==='tour'){
emit(["A",doc.country,doc.city,doc.adult,doc.ch,doc.priceType,doc.dd,doc.price]);
emit(["R" + doc.resort,doc.country,doc.city,doc.adult,doc.ch,doc.priceType,doc.dd,doc.price]);
}
}
RESORT+COUNTRY+DEPARTURE_CITY+ADULT_COUNT+CHILD_COUNT+PRICE_TYPE+DEPARTURE_DATE allows me to select ~ 40000 records from 3000000+ (for DEPARTURE_DATE range) but sometimes (according user input) I still need to filter out them by Stars (stars IN (4,5) for example). Also view sorting is "BY Date,Price" this is'nt applicable, for example I got
20140101 110$ <- top but not cheapest
20140101 120$
20140102 100$ <- cheapest but not top
20140102 105$
At other side sometimes I also need to fetch N cheapest tours where DepartureDate BETWEEN x and Y and Price BETWEEN A and Z.
All those scenarios require additional filters to filter out from HUGE dataset (even high-selective VIEW as shown above still produce HUGE dataset in my case) and I do not want fetch whole dataset to client (AppServer) for such processing... I realize processing on Couchbase nodes will consume more CPU on them but I prefer to add more Couchbase nodes to cluster...
Anyway someone need to do this filtering work, I believe it's much more optimal to do it where data actually placed without additional network overhead...
Dimzon,
You can sort on the value of the key emitted by the view using the descending parameter. There is also a limit parameter that will restrict the number of responses you obtain per query.
Anon,
Andrew