• Made my first small PRs to indieweb-utils to pin requirements and introduce pytest. There's a few more I'd like to do e.g. black / flake8 / mypy, but all in due time.
  • Bookmark of Can Matt Mullenweg save the internet?

    He's turning Automattic into a different kind of tech giant. But can he take on the trillion-dollar walled gardens and give the internet back to the people?
    While I agree with Matt that decentralization and individual ownership are central to a Web3, the crypto/blockchain aspect of it is a technological farce.

    Following the principles of IndieWeb on your own domain will allow you, today, to own all of your data and to interact with other people absent of any intermediary service and without melting the arctic.

    A major motivator for building Tanzawa was individual ownership. It's not enough to have your data, but have it stuck in a in serialzied blob in a Wordpress plugin data column somewhere. It's too difficult and cumbersome to reuse. It must be in a proper relational schema. So far the fruits of my indieweb journey have allowed me to not only own my data, but to actually use it toΒ  build upon it. Both trips and maps wouldn't have been possible without Tanzawa.
  • Response to Announcing indieweb-utils

    After some thought, I decided to build indieweb-utils, a Python library with building blocks that will assist developers in building IndieWeb applications.
    indieweb-utils looks like a lovely library to help with some of the faff of html parsing for the IndieWeb.

    I originally planned to do something similar using Tanzawa Indieweb module for Django-Indieweb stuff, but now I'm less convinced that'd be useful outside of the Tanzawa context.Β 

    I'd love to see the Python/Indieweb "consolidate" a bit on a single library so we aren't duplicating effort. I'll have to open some PRs. Great work, James!
  • How to Split Commits

    Sometimes in a rush developing, I'll commit two distinct changes in a single commit. From a code perspective, this isn't an issue because the code works. But from a systems perspective you can no longer split changes from A and B. They're forever married.Β 

    Splitting those changes into two commits will allow us to keep a better history of the system and allow our pull request to "tell a better story".

    We can fix combined commits with an interactive rebase. I use PyCharm for part of this in my regular workflow at work, so rather than providing a concrete example, I'll instead summarize the procedure.

    • git rebase -i origin/mainΒ  (or whatever branch you rebase on to) to start an interactive rebase.
    • Find the commit you want to split and mark it as "edit"
    • git reset HEAD~1
    • Add the files / changes for change A, commit
    • Add the files / changes for change B, commit
    • git rebase --continue

    The "secret" is that when you edit stops the rebase after the combined commit. By resetting HEAD~1, we effectively undo that commit. But since it's a soft reset, the changes are not rolled back, just the commit. This allows us to tweak and commit individual parts separately as desired before continuing to the next commit in our branch.
  • Response to GNUstep: Open-source, Object-oriented, Cross-platform Development Environment

    GNUstep is a mature Framework, suited both for advanced GUI desktop applications as well as server applications. The framework closely follows Apple's Cocoa APIs and is portable to a variety of platforms and architectures.
    Reading this comment really brought back memories of being an Objective-C developer in the early MacOS X days. One thing I lamented in those days was that whatever I wrote was stuck on the Mac and GNUstep gave me hope that it didn't need to be.

    High school me used to think how cool Objective-C and Cocoa was and how it was the future. And thanks to the iPhone, for a long time I was right.

    But the web won the war for Cross-platform development and most days I'm glad it did.
  • I’ve been starting on a refactoring of Tanzawa to help improve maintainability.

    I’m taking a layered approach where each package is broken down into a data layer (models) at the bottom, queries (data access) above that,Β  application (business logic) above that and finally your views at the top.

    The idea being that the top layers can go down the stack, but upper layers can’t go up. I’m not sure if I’m going to enforce it via linting, but I probably will, eventually.

    We’ve been using a similar structure at work and once you get used to it, it’s quick to find the code you’re looking for and keeps things tidy. And linting helps enforce it when we forget or want to be lazy. πŸ˜€
  • Plugins can now be enabled and disabled in production (when running in gunicorn/uWSGI) without bringing the server down πŸ˜€.

    The issue was that only a single process (the one that handled the request) got the plugin dynamically enabled. When the other processes tried to lookup urls/templates from the plugin, it didn't exist as it's not enabled and returned an error.
  • How to Gracefully Restart A Parent Process

    When enabling or disabling plugins in Tanzawa, for urls to register correctly across all sub-processes, you must restart all processes, not just fiddle with the process that made the request.

    The complete changes are in PR #121, but the line of interest is below.

    import os
    import signal
    
    os.kill(os.getppid(), signal.SIGHUP)

    Where getppid gets the process id of the parent process (gunicorn, uwsgi, etc...) and sends it a HUP signal.
  • Bookmark of Digital esthetics, environmental change and the subcultures of computer art

    For decades, the development of information technology has been characterized by a very strong growth orientation, which is now coming to an end with the fading of Moore's Law and environmental change. Academic research in computing has only recently begun to wake up to the fact that there are limits to growth, and that a more fundamental paradigm shift is required to achieve sustainable computing; mere technical tinkering is not enough.

    Growth-centricity has also dictated the development of digital esthetics, which will thus need to change as well. I suggest that the guidelines for this change should be sought in subcultures of computer art whose esthetic ideals are very different from the mainstream Maximalism and Virtualism – the self-serving glorification of the big and plentiful and the hiding of the technical basis of things. I have chosen demo art, chip music, pixel graphics and glitch art as examples of these subcultures. The ideals of "digitality" are also being challenged by post-digitality, so I will also look at these subcultures through this concept.

    I will conclude with reflections on the possible impacts of environmental change on digital esthetics and computing more generally, and on the ways in which computer art subcultures could play a pioneering role in these developments.
    I haven't actually read all of this, but from what I have I'm completely on board. Mostly a reminder for myself to finish reading this.
  • Bookmark of SerenityOS

    SerenityOS is a love letter to ’90s user interfaces. Andreas Kling demos some of the best aspects of his new operating system.
    Maybe it's just nostalgia, but SerenityOS looks great. As the big OSes integrate into opaque web services, the mental model of your PC has become too complex. In many ways it feels like usability is getting worse. SerenityOS is such a breath of fresh air.
1 of 10 Next