Hey there! Back when the pandemic was in full swing, I stumbled upon a comment that shared a link to a website with a title quite like this post. I can't quite recall if I saw the comment on Reddit, the orange site, or even here. The site was quite basic, and claimed to have a list of jobs from companies that understood that its workers would like to have a life outside of work

The job market has changed a lot since the pandemic, but if any of you awesome folks happen to know where I can find a good part-time software development job, I'd be seriously grateful.

I was fortunate enough to grab a discounted 4090 while on my travels and just got everything installed. Already having a lot of fun pumping all my games to max settings, but I'm also interested in running generative AI stuff locally to really take advantage of all that VRAM.

Do you have any newbie-friendly Windows 11 software to recommend for getting started? Thanks!

Hey Tildes, with the renewed interest in the site, it got me thinking that we should hold a fundraiser for the not-for-profit company—which currently consists of just one person—that runs Tildes. It's overdue.

Disclaimer: These are my words as a member of the community. I haven't run this message by the admin before posting. I may have gotten some details wrong.

Where to donate

• GitHub Sponsors: https://github.com/sponsors/Deimos
• Patreon: https://www.patreon.com/tildes

History

A bit of history: The site admin, @Deimos ran the first three years of the site working full-time on it, paid only by donations, plus a $5000 GitHub sponsor match one year, which I'm not even sure was fully achieved, or only just barely.

For that time period 2018-2020, a lowball salary as a software engineer with his experience would have been $100,000 USD per year not including benefits.

If he received $5000 in donations per year (almost certainly an overestimate for more recent years) plus the $5000 GitHub match for the first year—for the 5 years of Tildes' life, that's about $30,000.

The remaining opportunity cost of $270,000 was essentially paid out of pocket by himself, as a donation to the community. Plus remember there are server expenses, legal incorporation expenses, etc. And, y'know, rent.

In recent years he had to take a full-time job because the situation was, of course, unsustainable.

App?

I announced in April that a mobile app is under development. Originally, I was planning to take my time and release a first alpha by the end of 2023.

How about if we struck a deal: get the donation numbers up and I will devote more time to the app, as opposed to splitting my time between it and contract work and other projects.

What's the deal?

• 150 active donors combined on GitHub Sponsors and Patreon—I'll release an alpha by November.
  GOAL REACHED
• 300 active donors—I'll release an alpha by October.
  GOAL REACHED
• 500 active donors—I'll release an alpha by September.

The dollar amounts don't matter.

As of writing, we are at 46 active donors.

What's in it for you, though?

Feeling like I did a good deed, I guess? I'm not looking for a "slice of the pie," to be clear. In some sense I'd be matching your donations with my time, aka opportunity cost.

If I donate, can I bother the admin to work more on the site?

No.

Again, I haven't run this fundraiser by the admin. He will certainly keep his full-time employment for the foreseeable future, and will not magically have more hours in the day to devote to Tildes.

With a sustainable budget, though, a lot can happen in the future. Contracting out work to others, for example.

But the point of this fundraiser is more to make a small dent in the past debt we owe the admin, not making any promises whatsoever on the future of the site and how it's run.

Let's go, my fellow Tilderinos!

• GitHub Sponsors: https://github.com/sponsors/Deimos
• Patreon: https://www.patreon.com/tildes

Bevy just released their version 0.11, so I figured it would be a nice opportunity to ask the Tildes gamedevs if they were using it :)

Bevy is a rust game engine - more like a set of libraries actually - that's been gaining popularity the last few years. It has become the de facto toolset if you want to make a game in rust. It is very opinionated towards Entity-Component-System (ECS), and uses the pattern to facilitate parallelism and multi-threading.

Personally, I'm using the bevy-ecs lib (not the whole engine) to write a roguelike and hone my skills in rust. I enjoy it but it's not really beginner-friendly. The official docs are lacking, and you'll have to dig in the auto-generated api docs to make the most out of it. However, I appreciate that each release not only brings new features, but also refines existing ones. The engine is getting better - not only bigger - release after release.

Want to contribute a theme to Tildes but don't know where to start? Let's fix that.

Before we start, get yourself a development environment setup and do a quick read through of the general development info to get acquainted with how Tildes works (or at least the HTML and CSS section).

For this walkthrough I'll be using tildexample as the example name for the theme, but if you decide to contribute a theme for real, make sure it uses the proper name of your theme. :P

Step 1: Sassy _Sass

Open the Tildes codebase using your text editor of choice and navigate to the themes directory at tildes/scss/themes. Then create a copy of _default.scss at _tildexample.scss. The default White theme is the canonical source of all colors used, so it's the best place to start from.

Below is an annotated example of all the things you need to change in your new theme file.

// Add a small description of the theme here with maybe a link to its website.
// Check the other themes for examples. https://example.org/tildexample

// Change the theme variable to $theme-tildexample
// ↓ ↓ ↓ ↓ ↓ ↓ 
$default-theme: (
  // A whole bunch of color definitions, edit as your theme demands.
  // ...
);

// Append ".theme-tildexample" to the body selector.
// ↓ ↙
body {
  // Don't forget to update the theme variable here too.
  //                  ↓ ↓ ↓ ↓ ↓ ↓ ↓
  @include use-theme($default-theme);
}

@include theme-preview-block(
  // Change the text to tildexample.
  // ↓ ↓
  "white",
  // And again update the theme variable here.
  //       ↓ ↓ ↓ ↓ ↓ ↓ ↓
  map-get($default-theme, "foreground-primary"),
  map-get($default-theme, "background-primary")
  //       ↑ ↑ ↑ ↑ ↑ ↑ ↑
);

Once that's done, head to tildes/scss/styles.scss and at the bottom of the file add your theme import:

@import "themes/tildexample";

Step 2: Hardcoding a TheMe coLor

Boy that title is a stretch just to say, we need to add 2 lines to the HTML base template.

Inside the tildes/tildes/templates/base.jinja2 file is a section of if/elif/elif/elif/... statements to set the theme color meta element. Add yourself an elif block and add your theme color.

For this you probably want to use the background-primary color you used in your theme definition. I've used #ff00dd below because it spells food. I'm such a jokester.

{% elif request.current_theme == "tildexample" %}
<meta name="theme-color" content="#ff00dd">
{% endif %}

Step 3: Snakey Wakey

Finally the last step is to grab your trusty pungi and give it a blow.

Head to tildes/tildes/views/settings.py and find the THEME_OPTIONS constant. Here you want to add the theme class you used in body.theme-<this part> and a proper name that will be shown in the theme dropdown.

THEME_OPTIONS = {
    "white": "White",
    # Many other themes...
    "tildexample": "Tildes Theme Example",
}

Once that's all been done, check it out in your development site and see if it works.

Now git!

Commit. Push. Merge request. Have some water. Deimos reviews, merges and deploys your theme. Job's done.

If I have a quick Tildes dev question, where should I ask it?

Been lurking for a week on tildes now and I am really glad this place exists. The crow here is exactly what I have been missing on Reddit for a while now.

Having said that, the whole Reddit situation has some-what motivated me to get the balls rolling on an idea that I have had for a while and I am looking for advice on the same.

I have often heard this phrase "Learn programming by building" but whenever I dive in to the resources, I fall flat due to the information overload and the general abstractness that the field has (I appreciate abstractness but here it demotivates me) and I have never found a proper resource that I could follow to actually build something instead of just blindly following tutorials and playing with them.

So, my question is how do I translate "learn by building a project" into a practical framework.

I know of 100 days of swift and I really like that approach however I don't think I want to start with swift or build an iOS app right now.

The vast majority of free and open source software available is well known for being clunky, having very unintuitive UI/UX and being very inaccessible to non-nerds.

We can see this in Linux distros, tools, programs and even fediverse sites.

I understand that a lot of it is because "it's free", but I also feel like a lot of people who make and use FOSS don't actually value user-friendliness at all. I feel like some of it is in order to gatekeep the less tech savvy out, and some of it is "it's good enough for me".

What are the best theories for why this is the case?

EDIT: A lot of replies I've been getting are focusing on the developers. I'm asking more why the users seem okay with it, rather than why the developers make it that way.

I'm having some trouble getting the local developer environment set up on Apple hardware, specifically it seems because Virtualbox, which is used as the provider, is not properly functioning on Apple hardware.

Is there anyone here who has managed to get it up and running?

Someone mentioned elsewhere that they signed up for Tildes “years ago during the beta”. That reminded me: Tildes hasn’t reached beta-testing yet.

Officially, Tildes is still in alpha-testing phase.

The login page says “Tildes is currently in invite-only alpha...” And the Contact page says “To request an invite to the Tildes alpha...”

We’re still in alpha-testing. Alpha-testing of software usually happens on an incomplete product before it is released to the customer.

This is a very important point. Tildes is not feature-complete yet: there are literally hundreds of feature requests yet to work on before Tildes will be what people want it to be – and even that list is far from complete. In Agile software development terms, Tildes is a minimum viable product, or, in other words, “a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development”.

Tildes works as it is, but it’s a bare-bones forum: you can post, and comment… and that’s about it. It’s a proof of concept. There are a few minor tweaks here and there, which give the impression that Tildes is more complex than it is, but they’re misleading. There are plans to make Tildes a more complex website but, right now, most of that complexity of Tildes exists only in people’s imaginations (and there have been some very imaginative people contributing to that list of future features!).

Most questions about “Why doesn’t Tildes do X?” or “Can Tildes do X?” can be answered simply by saying “Tildes is incomplete and X hasn’t been built yet.” There are some questions about missing features which can be answered by saying “Tildes was never intended to do X”, but those are far and away in the minority. Most flaws, drawbacks, and problems with Tildes exist because Tildes is still a proof of concept, rather than a finished product.

It’s also worth noting that Tildes’ current feature set is absolutely not up to the task if the user base and site activity increase too quickly. There’s too much manual tinkering required at the moment to make things work properly: for one thing, there are no significant moderation tools on Tildes (that’s almost all done manually at the moment). There are still a lot of features yet to be built - and we don’t even know what some of those features are yet!

To pre-empt the people who will rightly point out that Tildes is 5 years old: Tildes’ feature set was intended to grow gradually over time, in line with a gradual growth in users, activity, and the need for those features to exist. However, Tildes has not undergone much growth over the past few years, so the existing features were sufficient to manage the existing activity. Basically, the site didn’t need a lot of fancy features to handle the low traffic here.

This sudden surge of new users might change that. But it will take time to build more features. That was always the intention, and it hasn’t changed now.

Until then: Tildes is still in alpha-testing. It’s an unfinished product. Set your expectations accordingly.

EDIT:

If you're one of the many people who seem to be replying to this topic, saying "it's okay, I like this simple bare-bones site as it is"... then you're probably not part of my original intended audience for this topic. This topic was aimed at all the people who are arriving here, being taken aback at how simple Tildes is, and wondering where the advanced features are.

However, we can still take the "set your expectations accordingly" message and apply it to you: "Tildes is an unfinished product, so you can expect it to change in the future. It won't be like this forever."

Either way, "set your expectations accordingly" is the message here, whether you're expecting more features and not finding them, or whether you're expecting simplicity and enjoying what you see. Either way, you should know that things will change around here. Maybe slowly. Maybe quickly. Maybe they'll get better from your point of view. Maybe they'll get worse from your point of view. But, change they will.

A common theme in web development, and the crux of the so-called "Web 2.0" is scrolling through dynamic lists of content. Tildes is such an example: you can scroll through about 50 topics on the front page before you reach a "next" button if you want to keep looking.

There's a certain beauty in the simplicity of the next/previous page. When done right it's fast, it's easy, and fits neatly into a server-side rendered model. However, it does cause that small bit of friction where you need to hit the next button to go forward -- taking you out of the "flow", so-to-speak. It's slick, but it could be slicker. Perhaps more importantly, it's an interesting problem to solve.

A step up from the next/previous button is to load the next page of content when you reach the end of the list, inserting it below. If the load is pretty fast, this will hardly interrupt your flow at all! The ever-so-popular reddit enhancement suite does precisely that for reddit: instead of a next button, when you reach the bottom, the next page of items simply plops into place. If the loading isn't fast enough, perhaps instead of loading when they reach the last item, you might choose to load when they hit the fifth from last item, etc.

To try to keep this post more concrete, and more helpful, here's how this type of pagination would work in practice, in typescript and using the Intersection Observer API but otherwise framework agnostic:

/**
 * Allows the user to scroll forever through the given list by calling the given loadMore()
 * function whenever the bottom element (by default) becomes visible. This assumes that
 * loadMore is the only thing that modifies the list, and that the list is done being modified
 * once the promise returned from loadMore resolves
 *
 * @param list The element which contains the individual items
 * @param loadMore A function which can be called to insert more items into the list. Can return
 *   a rejected promise to indicate that there are no more items to load
 * @param triggerLoadAt The index of the child in the list which triggers the load. Negative numbers
 *   are interpreted as offsets from the end of the list. 
 */
function handlePagination(list: Element, loadMore: () => Promise<void>, triggerLoadAt: number = -1) {
    manageIntersection();
    return;

    function handleIntersection(ele: Element, handler: () => void): () => void {
        let active = true;
        const observer = new IntersectionObserver((entries) => {
            if (active && entries[0].isIntersecting) {
                handler()
            }
        }, { root: null, threshold: 0.5 });
        observer.observe(ele);
        return () => {
            if (active) {
                active = false;
                observer.disconnect();
            }
        }
    }

    function manageIntersection() {
        const index = triggerLoadAt < 0 ? list.children.length + triggerLoadAt : triggerLoadAt;
        if (index < 0 || index >= list.children.length) {
            throw new Error(`index=${index} is not valid for a list of ${list.children.length} items`);
        }

        const child = list.children[index];
        const removeIntersectionHandler = handleIntersection(child, () => {
            removeIntersectionHandler();
            loadMore().then(() => {
                manageIntersection();
            }).catch((e) => {});
        });
    }
}

If you're sane, this probably suffices for you. However, there is still one problem: as you scroll,
the number of elements on the DOM get longer and longer. This means they necessarily take up
some amount of memory, and browsers probably have to do some amount of work to keep
track of them. Thus, in theory, if you were to scroll long enough, the page would get slower and
slower! How long "long enough" is would depend mostly on how complicated each item is: if each one
is a unique 20k element svg, it'll get slow pretty quickly.

The trick to avoid this, and to get a constant overhead, is that when adding new items below, remove the same number of items above! Of course, if the user scrolls back up they'll be expecting those items to be there, but no worries, the handlePagination from before works just as well for loading items before the first item.

However, this simple change is where a key problem arises: inserting elements below doesn't cause any layout shift, but inserting an item above ought to--right?

The answer is: it depends on the browser! Back in 2017 chrome realized that it's often convenient to be able to insert items into the dom above the viewport, and implemented scroll anchoring, which basically ensures that if you insert an item 50px tall above the viewport, then scroll 50px down so that there's no visual layout shift. Firefox followed suite in 2019, and edge got support in 2020. But alas, safari both on mac and ios does not support scroll anchoring (though they expressed interest in it since 2017)

Now, there's two responses to this:

• Surely Safari support is coming soon, they've posted on that bug as recently as April! Just use simpler pagination for now
• Pshhhh, just implement scroll anchoring ourself!

Of course, I've gone and done #2, and it almost perfectly works. Here's the idea:

• Right before loadMore, find the first item in the list which is inside the viewport. This is the item whose position we don't want to move. Use getBoundingClientRect to find it's top position.
• Perform the DOM manipulation as desired
• Use getBoundingClientRect again to find the new top of that item.
• Insert (or remove) the appropriate amount of blank space at the top of the list to offset the change in client rect (note that if there's scroll anchoring support in the browser this should always be zero, which means this effectively works as progressive enhancement)

Now, the function to do this is a tad too long for this post. I implemented it in React, however, and combined it with some stronger preloading object (we don't need all the items we've fetched from the API on the DOM, so we can use before, onTheDom, after lists to avoid getting a bunch of api requests just from scrolling down and up within the same small number of items).

What's interesting is that it still works perfectly on chrome even with scroll-anchoring disabled (via overflow-anchor: none), but on Safari there is still, sometimes, 1 frame where it renders the wrong scroll position before immediately adjusting. Because I implemented it in react, however, my current hypothesis is I have a mistake somewhere which causes the javascript to yield to the renderer before all the manipulations are done, and it only shows up on Safari because of the generally higher framerates there

If it's interesting to people, I could extract the infinite list component outside of this project: I certainly like it, and in my case I do expect people to want to quickly scroll through hundreds to thousands of items, so the lighter DOM feels worth it (though perhaps it wouldn't if I had known, when starting, how painful getting it to work on Safari would be!).

What do you think of this type of "true" infinite scrolling for web? Good thing, neutral thing, bad thing? Would you use it, if the component were available? Would you remove it, if you saw someone doing this? Are there other questions about how this was accomplished? Is this an appropriate post for Tildes?

I'm thinking about increasing the level of my open source contributions a bit. Instead of searching blindly until I stumble upon an issue that:
A) Piques my interest
B) I feel somewhat qualified to implement

I figured I'd check with the tildes community. Is there any Open Source software that you use that is missing a feature/capability? Can you give a brief description of it (bonus points for links to an issue tracker with an open ticket :))?

Can't of course promise anything will come of it, but if I do pick up your suggestion at least I'll give you a ping if I make any progress!