[DEV] Blockexplorer

General Discussion
#21



The height parameter is for the height to start from. So if you wanted the last 1000 blocks it's be better to just to

http://chain.nem.ninja/api/stats/v2/blocktimes?numBlock=1000

If you don't provide a height you'll get the last numBlock of blocks :)

If you want the 100 blocks after height 1000 you'd do

http://chain.nem.ninja/api/stats/v2/blocktimes?height=1000&numBlock=100


Aha so the values in the output
{"blocktimes": [[1000, 27000], [999, 130000], [998, 67000],....
(1000,999,988...) are not block heights!
So blocks are requested from (height) -> (height + num) but output is sorted in reverse!
I get it now.
Ok thanks.

I can work further with this new API output but i must say i the older output format had one advantage
and this is that you can know exactly what block height had which block time value
and it was easier to spot error in the output for example a missing block or negative value
can be immediately linked to block of height (N) just by looking at the output.

Maybe would be good idea to make also the v2 API output
similar in a way that instead of showing 1000,999,988... the block height value is placed in array like:
{"blocktimes": [[44470, 27000], [44469, 130000], [44468, 67000],....

EDIT:
one small bug i found is that
the api call without any parameter http://chain.nem.ninja/api/stats/v2/blocktimes
returns last 117 blocktime values not 120 like the other api called without parameters.


The 117 error probably comes from the fact that redis doesn't "index" the real height...i can fix that if necessary.

I would have preferred to keep the old json format as well but dicts aren't sortable that's why I had to go with lists. It's the same format only the keys are not the first value of each dict and the value is the second.

I'll look into it though. Maybe there is a solution to keep the old format.
#22


The 117 error probably comes from the fact that redis doesn't "index" the real height...i can fix that if necessary.

I would have preferred to keep the old json format as well but dicts aren't sortable that's why I had to go with lists. It's the same format only the keys are not the first value of each dict and the value is the second.

I'll look into it though. Maybe there is a solution to keep the old format.


Yes please fix the 117 issue if this is not too much trouble to you.

I had similar problem few months ago a  sortable dictionary data was required.
I think i solved it by using OrderedDict class but i had not so much data to sort
thefore i don't know if this will affect performance in your code if you use it.

What would be suitable or enough for me
1) add numBlocks parameter to the blockstats (v1) API call even if you don't manage the sorting
  i will do the sorting as now in my script if otherwise is not possible
OR
2) fix the 117 issue in V2 API call if is not too much trouble to you and leave the output as it is.
I will then calculate the block height in my script to be able to show it in the chart.

#23



The 117 error probably comes from the fact that redis doesn't "index" the real height...i can fix that if necessary.

I would have preferred to keep the old json format as well but dicts aren't sortable that's why I had to go with lists. It's the same format only the keys are not the first value of each dict and the value is the second.

I'll look into it though. Maybe there is a solution to keep the old format.


Yes please fix the 117 issue if this is not too much trouble to you.

I had similar problem few months ago a  sortable dictionary data was required.
I think i solved it by using OrderedDict class but i had not so much data to sort
thefore i don't know if this will affect performance in your code if you use it.

What would be suitable or enough for me
1) add numBlocks parameter to the blockstats (v1) API call even if you don't manage the sorting
  i will do the sorting as now in my script if otherwise is not possible
OR
2) fix the 117 issue in V2 API call if is not too much trouble to you and leave the output as it is.
I will then calculate the block height in my script to be able to show it in the chart.


I was considering OrderedDict but i didn't use it because i usually prefere sticking to the standard and i didn't realize that the new format would be such a problem.
I'll switch to OrderedDict and fix the 117 issue  ;)
#24

Okay v2 API output should have the same output format as v1 now.
About the 117 issue… The API works correctly. You'll see that if you don't start at 0 you'll get the 120 blocks. The problem is the first two blocks aren't in my db. I'll have to look into that some more when I have time. Sorry that i can't fix it immediately.

#25

Okay v2 API output should have the same output format as v1 now.
About the 117 issue... The API works correctly. You'll see that if you don't start at 0 you'll get the 120 blocks. The problem is the first two blocks aren't in my db. I'll have to look into that some more when I have time. Sorry that i can't fix it immediately.


Ok thanks.
the 117 is not an big and urgent issue as I realized that calling the API without parameters  will return data from beginning (first blocks ) and not the last ones. I will use height parameter because i need last blocks so it won't make me any problems.


#26

It would be nice, if from the lists of BlockExplorer could be filtered away the blocks, which have no transactions.
An option: filter away or not.

At least now it would be useful, coz there are too many 0-blocks.

#27


Hello.

@nxkoil
I will check with patmast3r if he can provide such option in the API call.
Anyway maybe is better that you check the transactions then you won't to deal
with empty blocks :wink:

@ALL and  (BloodyRookie)
I have implemented a new chart in the block explorer so the latest version is 0.1.0 (alpha)
I think you will like it! :wink:

@patmast3r:
Please can you update with latest code from github.

BTW: is there an option to search for a block by block height similar to this by hash
"/api/search?q=…"  or  "/api/block?hash=…"
or if there is possbile for you to add this option?

Thanks.

Bye.

#28

@freigeist : your changes are great, thx. Just one thing: The average seems to have a precision of one second. Can you change that to have a precision of of at least 1/10 (better 1/100) second?

#29


Hello.

@nxkoil
I will check with patmast3r if he can provide such option in the API call.
Anyway maybe is better that you check the transactions then you won't to deal
with empty blocks ;)
...


yes, TXs can be used, but in this case was just tried to check, how many TXs are in blocks, or what could be the maximum number of TXs. ..
That's why the 0-blocks were 'to be ignored' - but they were too many :)
#30

@freigeist: I think it would also make sense to have a minimum range for the average times, say from 55 to 65 seconds.

#31

Account info:
Status:LOCKED<br />Address:TAPPSA2RTKVSZYVA645Q64HACHIL4LDTSGXEGTCL<br />Balance:52496529.959316<br />Importance:<br />Score: undefined<br />Page rank: undefined<br />Height: undefined<br />Public Key:0331df4cf39e26286522d06ef69e2e9b7505876e8e7498fcd576b92853e73a591a<br />Label:null<br />Foraged Blocks:2942<br />Messages:0
When we click on the account info, it shows "Foraged Blocks". Shouldn't it be "Harvested blocks". Please change this :slight_smile:

#32

Account info:
[code]Status:LOCKED
Address:TAPPSA2RTKVSZYVA645Q64HACHIL4LDTSGXEGTCL
Balance:52496529.959316
Importance:
Score: undefined
Page rank: undefined
Height: undefined
Public Key:0331df4cf39e26286522d06ef69e2e9b7505876e8e7498fcd576b92853e73a591a
Label:null
Foraged Blocks:2942
Messages:0[/code]
When we click on the account info, it shows "Foraged Blocks". Shouldn't it be "Harvested blocks". Please change this :)


That's for the core devs to change :)
#33

@freigeist : your changes are great, thx. Just one thing: The average seems to have a precision of one second. Can you change that to have a precision of of at least 1/10 (better 1/100) second?


Ok it has been done on my local copy.
I will check if there is anything else before I submit the code for the update!

#34

@freigeist: I think it would also make sense to have a minimum range for the average times, say from 55 to 65 seconds.


I did not really understood your request.
You mean I should somehow fix the chart to display the averages in that time
range or what?

#35


Account info:
[code]Status:LOCKED
Address:TAPPSA2RTKVSZYVA645Q64HACHIL4LDTSGXEGTCL
Balance:52496529.959316
Importance:
Score: undefined
Page rank: undefined
Height: undefined
Public Key:0331df4cf39e26286522d06ef69e2e9b7505876e8e7498fcd576b92853e73a591a
Label:null
Foraged Blocks:2942
Messages:0[/code]
When we click on the account info, it shows "Foraged Blocks". Shouldn't it be "Harvested blocks". Please change this :)


That's for the core devs to change :)


I have changed the text in the index.html file on my local machine.
What have the core devs do with that issue?!

there is still one request from Bloodie which i will implement when i will get
what he wants  ;D then i will submit the new code with this change.

#36



Account info:
[code]Status:LOCKED
Address:TAPPSA2RTKVSZYVA645Q64HACHIL4LDTSGXEGTCL
Balance:52496529.959316
Importance:
Score: undefined
Page rank: undefined
Height: undefined
Public Key:0331df4cf39e26286522d06ef69e2e9b7505876e8e7498fcd576b92853e73a591a
Label:null
Foraged Blocks:2942
Messages:0[/code]
When we click on the account info, it shows "Foraged Blocks". Shouldn't it be "Harvested blocks". Please change this :)


That's for the core devs to change :)


I have changed the text in the index.html file on my local machine.
What have the core devs do with that issue?!


I thought you're just taking the json (where it's afaik called foraged) and showing the field names :)
#37


I thought you're just taking the json (where it's afaik called foraged) and showing the field names :)



Check this link for example

http://chain.nem.ninja/api/account?address=TA7IZ6KMH4WIOVZW4DHF4T5LAV67V6FQXLNMGMR5

there is a property named foragedBlocks therefore i have put the text "Foraged Blocks" :)
#38


@freigeist: I think it would also make sense to have a minimum range for the average times, say from 55 to 65 seconds.


I did not really understood your request.
You mean I should somehow fix the chart to display the averages in that time
range or what?


Sorry, my formulation was misleading ;)
The larger the number of samples taken to compute the average times, the smaller the range is within it varies. My request is to have a minimum range from 55 seconds to 65 seconds for the Y-axis so that I can see that the oscillation decreases if I choose a large number of samples for averaging.
Btw, would it be possible not to reset the range of blocks used (I mean the slider at the bottom) when I change the number of samples for averaging (upper slider)?
#39

Don't forget to go through the blockchain explorer issues from time to time ;): https://github.com/NewEconomyMovement/blockexplorer/issues

#40

Don't forget to go through the blockchain explorer issues from time to time ;): https://github.com/NewEconomyMovement/blockexplorer/issues


Hello

I have been there and seen your proposal.
I like it but question is will the NIS nodes send some kind of request with online status info
to the block explorer by using an API call that patmast3r should implement? :)