Community

"init, just some testing" -- a look back at the past year

NodeBB Blog

Suggested Topics

  • julianJ
    ●

    Bringing Back Better Bootswatch!

    NodeBB Blog
    2 Votes
    3 Posts
    187 Views

    oplik0O

    @gotwf The themes are from Bootswatch, so I suspect you should contact them with suggestions 🙂

  • Jay MoonahJ
    ●

    NodeBB v1.16.0 - One Last Release For A Weird Year

    NodeBB Blog
    6 Votes
    1 Posts
    303 Views

    Jay MoonahJ

    It's not news to say 2020 has been... challenging. In Toronto, the home of NodeBB HQ, we've gone from a spring lockdown to a cautious summer reopening, to lockdown again — sigh. But the team has never stopped working, and have managed to squeeze out one last release before we thankfully turn over the calendar.

    Click here to see the full blog post

  • julianJ
    ●

    A decade in the industry; a ten year retrospective

    Moved NodeBB Blog
    11 Votes
    11 Posts
    1803 Views

    gotwfG

    @julian One may hope not. Leastwise.... what is special about those dates? I know not. Mayhaps were you referencing the 2038 Unix Epochalypse? I think this has potential to be far more problematic. I have been aware of this since the great Y2K "crisis" but kind of forgot about it until this thread since 2038 was a "long ways off yet". I also thought this would be no big deal in future modern times due to the prevalence of 64 bit processors and os platforms. Alas, I seem to be in error:

    There is no universal solution for the Year 2038 problem. For example, in the C language, any change to the definition of the time_t data type would result in code-compatibility problems in any application in which date and time representations are dependent on the nature of the signed 32-bit time_t integer. For example, changing time_t to an unsigned 32-bit integer, which would extend the range to 2106 (specifically, 06:28:15 UTC on Sunday, 7 February 2106), would adversely affect programs that store, retrieve, or manipulate dates prior to 1970, as such dates are represented by negative numbers. Increasing the size of the time_t type to 64 bits in an existing system would cause incompatible changes to the layout of structures and the binary interface of functions. [emphasis added]

    Could be in for some interesting times, eh? 😜

  • julianJ
    ●

    Looking ahead to NodeBB v2.x

    Moved NodeBB Blog
    8 Votes
    4 Posts
    358 Views

    a632079A

    ps enhancements：

    types support（via @types），which can improve developers' exp just by npm i @types/nodebb etc
  • julianJ
    ●

    Reflections on 4 years of upgrade scripts

    NodeBB Blog
    5 Votes
    1 Posts
    1446 Views

    julianJ

    The first commit to NodeBB was nearly four years ago, and in that time, many changes have been made to the core code itself, from feature additions and bug fixes, to bundling of must-have plugins for all installations.

    As with any code that matures, schema changes needed to be made over time to ensure that stored data was kept in an ideal manner, so as to reduce the use of anti-patterns such as god tables and XYZ. The second reason schema changes are made are due to revisions in the original implementation. Perhaps a design decision from before could have been done in a more efficient way, and that may need a migration of active data from one data type to another (e.g. a list to a sorted set).

    Click here to see the full blog post

| | | |
Copyright © 2023 NodeBB | Contributors