SteemWorld ~ Weekly Support ~ #4

steemchiller in #steemworld • 6 years ago (edited)

[EN]

This post is intended to cover the server costs for SteemWorld.org and to enable me to continue my development in the future.

In case you missed the first part:
SteemWorld ~ Weekly Support ~ #1

[DE]

Dieser Post ist dafür gedacht die Serverkosten für SteemWorld.org zu decken und mir in Zukunft weitere Entwicklungen zu ermöglichen.

Falls du den ersten Teil verpasst haben solltest:
SteemWorld ~ Weekly Support ~ #1

Working naked under the roof

Since my apartment is on the top floor of this house and we are experiencing a really hot summer here in Germany I had to forgo my work wear in the past days... ^^ The temperature in my room is currently ~29° Celsius, even if it is midnight already. The fan which is standing on my desk is my best friend in these days... 😌

Nevertheless it has been a very busy week for me, not all went as expected, but I'm glad to be able to show you a few new things on SteemWorld.

New features

Settings now in tabs

Vote amount and rshares in all pie charts

User reputation next to the account's name

Account tooltips

By moving the mouse over an account's name and waiting for a few seconds the following tooltip will show up:

Thanks to @aiyumi for reminding me of the missing tabindex-attribute for some of the buttons on the site and the very interesting article about creating better HTML solutions for people with limited eye sight, who need to use screen readers when browsing the web.

I'm already thinking about a solution for being able to open the new tooltip without the need of a mouse ;)

Duplicate account operations fixed

I've made an interesting discovery regarding the field 'id' in the received account operations. One may think that the field contains a unique number for each operation but that is not always the case. It's an op index for one node and can sometimes even change in there, when the node's configuration changed and re-indexing has taken place. Other nodes may have completely different operation IDs for the same operations. Thanks to Steem master @vandeberg for the detailed explanation! The man is a machine... 😁

In the last time there was an issue regarding duplicate operations after switching to a different node and now it's clear to me why that happened. So instead of using the field 'id' I am now building my own IDs by hashing the operations data and adding the ~~block number~~ timestamp to it.

Caching the uncacheable

Sadly the planned caching feature for account operations can not be used. My solution works and SteemWorld would start ~ 3 times faster but there is a problem regarding to the default maximum local storage space of browsers (5 MB). I tried my best and added a string compression algorithm for the op data but it would not be fast enough for all devices/browsers.

One can change the browser setting 'dom.storage.default_quota' (by visiting 'about:config' in Firefox) and set it to a higher limit but I can't do it programmatically. Since I'm now storing all settings in local storage there is a risk of losing the main configuration, therefore I can't activate the new caching logic yet. If I should find a way for separating the config from the other cached data (maybe through coming HTML5 methods) I will activate the feature in future.

Local storage instead of cookies

All settings are now being stored in the browser's local storage and I'm (by default) no longer using cookies on SteemWorld. The conversion happened a few days ago and I hope that nobody has lost his config during the process. For older browsers I've added a fallback to further use cookies.

Why the CSI is 'NA'

The CSI calculation works but I've found a way to trick the algorithm and influence the CSI by voting older posts. I think it is impossible to have a fast, reliable solution on the client side, therefore I need to implement it on my server. I currently have a lot of other more important stuff to realize but I will definitely bring the CSI back to life in future.