“When HF24?”
Software never gets developed as fast as anyone would like, unless it’s rushed out the door too quickly, which only leaves a bad taste in everyone’s mouth when the resulting software is full of bugs. I’ve seen this happen many times over the years, and I’ve even been guilty of it myself once or twice, so I’m very much opposed to releasing software before it’s adequately tested. This doesn’t guarantee there still won’t be bugs, but it usually prevents the obvious ones.
All that’s a preamble to saying that most of the coding work for HF24 itself is done by now, but we’re still working very hard on creating tests, running those tests, and fixing bugs that those tests expose.
First, a tentative prediction: I’m hoping we can successfully update the mainnet to using HF24 rules within about 30 days from now. Here’s what needs to happen in that time to achieve that, along with time estimates for the tasks:
Remaining work on hived (the 1st layer blockchain code)
Yesterday @howo submitted a merge request for the code that will periodically convert Hive stored in the hive.fund account to HBD at prevailing market feed prices. After discussion with the community, he’s designed the code to convert 0.05% of the Hive in hive.fund once each day. At this rate, assuming no new Hive was added, all the hive there would be converted in 2000 days (100% / 0.05 = 2000) which is approximately 5.48 years. He’s also added code to exclude HBD stored in the hive.fund from debt ratio calculations. Currently, this is the last functional change planned for hived in HF24.
A couple of BlockTrades team members are currently working on developing and running more tests for hived.
I expect all the above work to be completed within the next week. The above work represents the blocking tasks for HF 24 in the blockchain code.
After the blocking tasks are completed, the same BlockTrades team members currently doing testing will also be doing follow-on work to fully measure and document the various speed and memory improvements associated with Eclipse software. Some of that is done already, but not all such measurements have been made on the same machines, we’ve had changes since those measurements, and making some of these measurements can take several days. Since this isn’t a blocking task, and we already are confident from previous measurements that we only have improvements in performance, full measurement of the performance improvement is a lower priority task.
Remaining work on hivemind (the 2nd layer microservice for social media information)
We have 2 devs working full-time and one additional dev that spends about ½ his time working on hivemind. We also have two more devs who occasionally provide design and technical help and do code reviews from time to time (I’m one of the latter).
Hivemind is pretty much feature complete for HF24 and we’re currently in the testing phase. Despite that, there’s actually more work left to do on hivemind than on hived, because there’s more things to test, and the testing framework was incomplete and considerably out-of-date when we started working on it. I don’t know for sure, but from what I can see and recall, I think there was only one dev (@roadscape) assigned to it when Steemit was developing it, so I think he had his hands full.
Some of the same guys recently assigned to testing hived will also be helping out with testing of hivemind. Due to the sweeping nature of the changes to hivemind, we do expect to find a reasonable number of bugs in hivemind that will need to be fixed (we’ve already found outdated tests that are arguably bugs themselves since they report false positives). Fortunately, the tests we’re developing are pretty good at isolating where the bugs are, so the bugs should be relatively easy to fix.
I am somewhat optimistically estimating that we’ll be able to complete the tests and fix the bugs we find in about a week. This work proceeds in parallel with hived work, so I’m currently estimating 1 week for complete testing of hived and hivemind, but my 30 day estimate allows for this taking up to 2 weeks.
As is the case for hived, we’ll also do some follow-on work to make measurements of final performance improvements after the testing is completed, but this is also not a blocker for HF24.
Update documentation and scripts to help node operators take advantage of new Hive features
Several features such as saving/restoring state information were introduced into hived that ease the burdens of node operators (including exchanges that want to support Hive). There’s also been several changes in how to optimally configure an API node and run it with fewer resources.
Since @gtg is one of our primary technical liaisons to exchanges, and he’s familiar with the recent changes, he has begun to review the documentation for hived and make appropriate changes to the associated docs, scripts, and config files.
Setup of testnet API nodes for library and 2nd layer application testing
We currently have an Eclipse node connected to the mainnet that can be used by 2nd layer applications for integration testing. However, this node currently only supports 1st layer API calls (i.e. blockchain API calls supported by hived). It’s being used for updating Hive API libraries like hive-js, beem, dhive, etc, mainly to support the rebranding changes (e.g. SBD → HBD) that have been made to the API. As of today, I think a good number of the libraries have completed their updates for this.
After we’ve completed testing of hived and hivemind (currently estimated at 1 week), we’ll need to setup one or more Eclipse testnets with a full API node that supports the API of both services. At this point, 2nd layer applications will be able to use this testnet to update their code to support Eclipse. Setting up a testnet node isn’t too difficult, so I don’t think this will take more than a day.
Updating 2nd layer applications
There’s quite a number of 2nd layer applications, so it’s hard to predict how long each team will take to make their updates. So I’m factoring in two weeks for the majority of the apps to be ready after the testnet is deployed.
We’ll also likely add a hivemind node to the Eclipse node that’s currently connected to the mainnet, so that 2nd layer applications will also be able to test against an Eclipse API server connected to the mainnet.
That’s only 3 weeks worth of work, why 30 days to HF24?
The idea is simple: we release a well tested version of the core blockchain code in one week from now. Exchanges then ideally have 3 weeks to setup up their Eclipse nodes in preparation for the hardfork (even though we only think they will need 2 weeks). During this same 3 weeks, 2nd layer applications can be completing their updates to work with Eclipse nodes. We essentially have one week of “slack”, in case we discover an error in the Eclipse core code, which will still leave exchanges and 2nd layer apps at least 2 weeks to upgrade.
Nonetheless, there’s never any guarantees with software, so it’s possible unexpected problems may come up and force us to delay more than 30 days. Our priority remains to ship a solid platform update, even if it means we have to miss our current estimated delivery date.
Wouldn't it take longer than that? If 0.05% of it is converted each day, then the next day will have less converted than the previous day, and that happens each day, meaning it'll take longer than 2,000 days to fully convert it. Or is it a fixed amount of the HIVE thats getting converted each day(but the
assuming no new Hive was addedpart makes me think that it's not a fixed amount, but from balance).Yep your reasoning is correct, It's my bad I didn't communicate properly to @blocktrades, the idea is to convert everything in 2000 days, but the ratio will have to change from time to time as we convert.
I figured it would be the better solution because converting a set amount each day wouldn't take into account the fact that new hive could be added to the dao. (I actually have an almost completed version of the feature that works like that and I dropped it when I realized it would not be the best way forward)
Your reasoning is sound, but I haven't inspected the code yet to say exactly how it behaves. The 2000 day period and 0.05% is what he relayed to me. Maybe it is a fixed amount of the current balance, as you suggest, and I described it wrong. I or someone else will review it in the next few days to find out for sure, if @howo doesn't comment here in the meantime.
Sounds good, thanks for keeping us updated.
Any comment on this @howo?
Do we have documentation on where to start on hive development, if someone wants to develop on hive blockchain ?
https://developers.hive.io/
Thank you a lot for the quick response, do not see anything on Java, but that's ok. Probably I will learn python a bit and try doing some experimentation. And by the way, I still see some steem references, which I think, should be changed. I hope someone is working on that.
Yeah that needs to be fixed.
@inertia is the one that maintains those documentation pages.
Yep, that's on my TODO list.
Good work @blocktrades. Thanks for the substantial update.
To be honest, I do mind doing it here, since it's unrelated to my post, and I prefer comments on my posts to relate to the post. But I think this just points to a problem with the platform as it stands now, as there's no clear place for people to leave a message for someone without randomly posting a reply to them somewhere, and usually everyone's favorite place is that person's most recent post. Sorry, it's just a pet peeve of mine.
But I did weigh-in a few hours ago, FWIW. You can find some of my comments here: https://hive.blog/hive/@cryptofinally/your-slack-has-more-than-one-leak#@blocktrades/qda8nu
My apologies. I hadn't realized you had already addressed it and will edit it out of my comment, as that is a legitimate gripe. Thanks for the reply.
A global chat client would be nice.
Thank you. Always good to know what's going on.
Excellent. Thanks for all the hard work and time you are doing getting us moving forward.
It sounds like there is a comprehensive level of testing which is good. Do you have any dedicated testers or is it all Devs?
All our testers are coders (i.e. devs), because the tests we use are pretty much all "automated tests" driven by software which has to be coded.
Manual testing is useful for testing a user interface to see how it "looks and feels" (also sometimes called UX testing for "user experience"), but comprehensive testing is best done by software. Doing it in software means you have tests that you can re-use over and over again too, to detect if something gets broken. Human testers won't remember to test everything, and they ultimately become too expensive if you want to do tests every time the software changes.
Yes indeed, I am very familiar with all types of test. I suspected it was largely automated as that would make most sense for repeatable tests on iterative builds.
I think it sounds good, relative to old forks on the bygone chain.
The pedant in me of course would like to counter the comprehensive testing best done by software. In my experience comprehensive testing is best using automated testing backed up by manual for edge cases and the like :0)
It could be we're using two different definitions of manual test. When I was referring to manual tests, I was referring to tests that are manually done by directly entering inputs to the software, either thru a GUI or a command-line, then observing the results visually. This is very "old school" testing, which I did a lot of in my early software career. Now we only use this kind of testing for UX testing (well, except for one project where the manager is still very old school and more of an engineer than a computer science guy).
But another view of automated versus manual is one where any test where the inputs which are generated by testing software are considered automated tests (and this testing software explores the input space in some way), whereas humans specifying the inputs are considered manual tests, with these latter tests being used to test edge cases that weren't explored by the less intelligent but larger set of inputs generated by the automated software.
If that's what you meant by manual (which is what I was led to believe by your use of the phrase "edge case"), then I think most of Hive's current tests are manual in this sense, but we code those sets of inputs into automated tests that can be re-run over and over again.
For the most substantial tests, the automated testing system then applies the same inputs to a golden reference model (which generally is the old version of the code) and to the current code under development, and reports differences in the results as potential problems.
I did a lot of that old school manual testing myself back in the day. It is surprising how prevalent it still is in the industry. I am currently working with a global organisation who pride themselves on being cutting edge when it comes to software delivery and yet when you scratch the surface of what they do everything is old school/waterfall-esque in nature and advocating automation beyond the old school automation (e.g. tests run on a tool on a local install) in something like a CI/CD framework is simply baffling for them.
But yes, I digress. The latter part of your reply is what I meant by manual. I often don't express myself best when I type on my phone!
You're doing pretty well. I hate composing on a cell phone...
Great
Thanks for the update!
The new APIs and making it easier for exchanges to transact with Hive should propel things into the big leagues. Very encouraging development indeed.
A huge hug 🤗 and a little bit of !BEER 🍻 from @amico!
Un caro abbraccio 🤗 e un po' di BEER 🍻 da @amico!
Congratulations @blocktrades! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :
You can view your badges on your board And compare to others on the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPTo support your work, I also upvoted your post!
Do not miss the last post from @hivebuzz:
I can't transfer my Hive to block trades, is there a problem.
"Software never gets developed as fast as anyone would like, unless it’s rushed out the door too quickly"
So true.
Thank you blocktrades for keeping us informed about the Hive Hardfork 24 and how your efforts are to make this a platform better and better. I love the work you and the developers do!
It is interesting and very important to be informed about the update of the platform, your initiative is always positive when it comes to progress on Hive Hardfork 24. You all make a great team.
The efforts they make for platform improvements are very important. The work they do is excellent
An interesting reading.. Thnks for share!
Less than 1 month! You can do it... How many workers you have?
Counting me, BlockTrades currently has 12 developers working on hive.
12 is more enough with a fast computer! Others 7 people only and hired another contractor if they cant do it alone. (^_^)
More power to you! Stay safe always!
Great times are coming! First HF without Steem luggage)
Hey @blocktrades, I'm sorry to bring this up here but I don't know how to contact you. We just got a big downvote on one of our curation posts, and we're a bit puzzled about it. @neyxirncn, our Spanish curator, was a bit puzzled too, because she's not sure what she's done wrong, and nor am I. That particular curation is supporitive of the Hispanic community, and 5 percent each week goes out to a member of the community to support excellent content and help with user retention. All the other rewards go out in challenges and to pay curators and to do what we can for Hive prosperity. Since we've started supporting the spanish community through Adiwa Thrive curation and Colmena Curativa, we've really helped onboard new users in South America and Spain too. We have been working SO hard for the last two years to build a solid reputation and support community on HIVE that I'm quite shocked we have had this downvote. Please can you get in touch with me on Discord riverflows4691? Thanks @riverflows.
Check and see if you also got an even larger upvote from ranchorelaxo. I have a bot setup that reduces the power of his random upvotes.
Yes, I did - I can see that now. Thanks for letting me know. It would have been nice to have let us know the reason why. The Spanish community was quite upset about it as they didn't know what they may have done wrong. As far as they see, the downvote signifies disapproval of the worst kind. I'll let them know it wasn't personal towards their efforts.