Timm Preetz

A touch-screen remote control for Linn Selekt DSM, using Rust on ESP32

Tue, 19 May 2026 00:00:00 GMT

While engineering the requirements for a client project to build a lighting control app to run on the infotainment / Cabin Management System (CMS) iPads on a Bombardier Global 6000 jet (like this), I came across this integrated screen/rotary dials built into the newest version of these planes.

While such custom hardware and embedded development was not something feasible on the given timeline (and would require physical changes to the aircraft), creating such a purpose-built gadget left me intrigued. Since I have no API-enabled smart lighting system at home, I instead opted to build a remote for my Linn Selekt DSM HiFi system instead. I knew that it does have an API, and having a dedicated piece of hardware seemed so much nicer than having to use the iPhone app (which does not have any live activities or similar to speed up control).

We all have desires, things we want to build, ways to express ourselves, ways that we find joy and meaning.

– Scott Wu

As it turns out you can even get a basic variant of that hardware (IPS instead of OLED, but a solid "scroll wheel" with a ball-bearing around the display) on Amazon[^1]. Unfortunately that device's chip (ESP32-S3) is a little harder to get started with using my preferred Rust toolchain, so I opted for a ESP32-C6 board with an OLED display (but sadly no wheel) instead.

Luckily the overall development environment is stable at this point and the basic setup to get started is well documented. With those docs and Claude I was able to get a basic "app" running on that device in no time at all.

The streamer has a documented control protocol and with a bit of debugging real responses a client class was built in no time. On the UI layer the generated code was a bit convoluted in the "AI does not tire of writing code"-sense, e.g. display and touch handling were entirely distinct, even though of course there should be a close relation between what's rendered on screen and what areas receives touches. But with my previous knowledge of the Flutter rendering stack, I guided the implementation in a direction I felt comfortable with, building small widgets which only redraw their own area of the screen, and having input aligned with the rendering.

One downside of the hardware I picked is that it doesn't have a built-in battery, which would be really cool for a remote. So for now I have to tack one to the back, but I hope that the next generation of ESP32-S31 boards will come in a nicer packaging so that I can revisit this again.
Having the physical rotating knob would be an especially nice upgrade, and overall the displays could always be a bit bigger and higher resolution.

But after a bit of tinkering the whole package works now: It connects to WiFi and can be powered off via the hardware button and thus lasts a long time without needing a charge.


<img class="inline-img" src="/assets/posts/linn_remote/linn_remote_oled_1.jpeg" alt="Linn OLED Remote" />	<img class="inline-img" src="/assets/posts/linn_remote/linn_remote_oled_2.jpeg" />

So overall I am happy about how this turned out and how it made me change my mind on what's possible to build. Looking forward to what's next!

How many ideas does one person have in a day, and how many of those things do they actually get to do? Until that proportion is 100%, you know there is a pretty meaningful bottleneck in terms of the drudgery of execution.

– Scott Wu

The full code is available on GitHub.

[^1]: For that specific board there is even a fully implemented Roon remote control up on GitHub.

Building an Odometer for Playlist Counts in SwiftUI

Sun, 17 May 2026 00:00:00 GMT

For a playlist count feature in an upcoming app I wanted it to update a little more prominently as a feedback when skipping a song or adding new items to the queue. This would also apply to every normal "next song" transition, but in that case few people are likely to watch.

I knew about SwiftUI's .contentTransition(.numericText()) but was dismayed that the number always rolled in from below, which didn't make much sense for the usual case of -1 when the next song started playing. Turns out I was not using it correctly: One just needs to pass in the count as the value parameter, and then the effect would align the direction accordingly.

Unfortunately before finding that tiny fix, I recalled an article by Livsy about building an Odometer in SwiftUI building atop that inbound effect. The main point was that SwiftUI directly goes from current to next, whereas for a more interactive feel it can be nice to count up (or down) to show the intermediate steps. That approach works well and is a nice and compact improvement atop the core behavior.

But what kept bothering me was that SwiftUI would always use a blurred transition between the numbers instead of a real "wrap around wheel" style like we've seen on the iOS date / time picker.

Custom `Odometer`

So I set out to build my own variant based on that effect. While trying out various approaches to handle this, the most important parts were breaking up the number into separate digits to be able to control them individually and then building the animation for each one. Each digit view contains the numbers 0-9 in a wrap around way using a combined effect of rotation3DEffect, offset, scale and opacity. To keep it clean only the active digit is shown on rest, and the adjacent one becomes visible while it animates in place.

Then came a lot of playing around with the widget and adjusting the animation curves. For the default transition (±1) I just let SwiftUI handle it across 1 or 2 digits using .animation(…, value: digit). For bigger changes we step through all the intermediate numbers at a slightly faster clip, but still slow enough that one can make out the individual steps. I capped this at 20 which is plenty for the current use-case and didn't become boring yet (though maybe I am currently too enamoured with this view). For distances beyond that we enter a kind of "reset" where each digit just rotates to the destination in the fastest way possible (not necessarily up or down as given by the count change). Here we step through with aligned timing/distances, so one digit/wheel might settle before the others (which to me makes sense if the distance was shorter). In order to manage this transition and "trust" the animation without stepping through many cases in testing each time I opted to first model the transitional steps on a data layer (which could easily be tested), and then just apply each successive step after a short timeout.

Demo

The final piece looks as follows (at the bottom, with the stock animations shown atop for comparison):

<center> <figure> <video autoplay loop muted playsinline style="max-width: 300px;"> <source src="/assets/posts/swiftui-odometer.mp4" type="video/mp4"> </video> <figcaption> <code>.contentTransition(.numericText())</code>, <code>.contentTransition(.numericText(value: count))</code>, and <code>OdometerView</code></figcaption> </figure> </center>

Source Code

And this is the code to implement this:

Speeding up batch inserts in SQLite using dynamic statements

Sun, 24 Nov 2024 00:00:00 GMT

indexed_entity_store's writeMany used to insert a batch of items in a single transaction, but using n individual REPLACE INTO statements (and then the corresponding index updates). In my testing I saw it take ~10ms for 1000 items with a small JSON payload (which serialization time is included in the total). This is considered best practice and does seem okay for most practical one-time batch imports of data (such that one did not have to resort to an async initial setup to avoid multi-frame drops).

Initially I wondered why, even inside the transaction, we had to loop over the individual inserts and could not execute a single statement which would write all data at once (up to a point I suppose, as there is surely a practical limit on how large a query can get, though than a similar constraint might apply to the in-progress transaction side.)

As it turns out we can insert multiple row just fine in a single statement, it's just a little bit unusual to write as SQLite does not allow binding to lists of values.
So from our single insert compiled statement (REPLACE INTO entity (type, key, value) VALUES (?, ?, ?)) we have to switch to a dynamically generated on that accounts for the number of inserts we want to do: REPLACE INTO entity (type, key, value) VALUES (?1, ?, ?), (?1, ?, ?), … (?1, ?, ?). That way we can call execute this statement with a concatenated parameter list of all the entities we want to write.[^1]

This pattern has been implemented in this PR, and indeed shows some nice improvements for my tests of batch sizes 1,000 and 10,000:

Batch size	Transaction (old)	Single statement (new)
1,000	`writeMany` took 7.41ms<br>`writeMany` again took 17.59ms	`writeMany` took 2.47ms<br>`writeMany` again took 5.38ms
10,000	`writeMany` took 69.68ms<br>`writeMany` again took 134.04ms	`writeMany` took 21.74ms<br>`writeMany` again took 43.21ms

Overall this resulted in a nice 3x speed-up. That is a fine start, but does not really change the ballpark speed of the operation in the general case.

Further I wondered whether the small payload sizes used in the example would benefit either one of the approach. So I ran another test where each entity had a ~10kB payload JSON.

Batch size	Transaction (old)	Single statement (new)
1,000	`writeMany` took 261.57ms<br>`writeMany` again took 474.71ms	`writeMany` took 133.56ms<br>`writeMany` again took 193.89ms
10,000	`writeMany` took 2334.00ms<br>`writeMany` again took 5128.63ms	`writeMany` took 1159.16ms<br>`writeMany` again took 1849.37ms

In this case the new approach still resulted in a 2x speed-up and did not run into any size limits. I did not measure the peak memory usage, but very likely this would have been higher in the new case, were all serialized entities are passed to the SQLite library in 1 call vs. the loop-approach, where Dart's GC has a chance to clean up each individual entity after passing it off.

Lastly I wondered how much of a penalty in these real-life tests was the overall JSON serialization (which one can exchange for a smaller and/or more efficient storage format). So in the last comparison I just saved the primary payload string straight to the database, without any JSON serialization:

Batch size	Transaction (old)	Single statement (new)
1,000 (small)	`writeMany` took 6.27ms<br>`writeMany` again took 12.00ms	`writeMany` took 1.87ms<br>`writeMany` again took 3.29ms
1,000 (large)	`writeMany` took 248.43ms<br>`writeMany` again took 451.07ms	`writeMany` took 86.97ms<br>`writeMany` again took 138.00ms
10,000 (small)	`writeMany` took 59.21ms<br>`writeMany` again took 121.93ms	`writeMany` took 12.74ms<br>`writeMany` again took 32.15ms
10,000 (large)	`writeMany` took 1925.63ms<br>`writeMany` again took 4741.23ms	`writeMany` took 743.32ms<br>`writeMany` again took 1432.79ms

Interestingly this did not result in a big speed-up compared to building the JSON values in the previous test run. But somehow the new approach benefited much more from this than the old one, making it even faster especially for larger payloads.

Overall I would have expected to be able to gain more by doing less transitions from Dart to the SQLite C-library, but this confirms just how fast the in-process ffi approach is and bigger gains would have to come from elsewhere.
The biggest difference in the approach seems to driven by the library's use of indices (to efficiently find entities later). When I disable them for testing, both approaches come very close to each other, but do not get significantly faster than the "single insert with search indices" approach. That suggests that there is a rather penalty being paid for updating the index table individually for each row entry (inside the transaction).

[^1]: The ?1 in all these cases is the entity type, which is the same across all rows, and thus we provide it only once to keep the parameter list length a bit down.

File storage in Flutter apps (Part 2)

Sun, 17 Nov 2024 00:00:00 GMT

Last week's article looked at various implementations of how to store files with metadata in SQLite using the package indexed_entity_store. This time, let's look at cases where you want to have the actual files on disk, with only its metadata stored in a database. Reasons for this might be that the files are very large, accessed often (e.g. for sharing, uploading), or need to be edited in place.

To get consistency across the files and their metadata, let's implement a store that exposes a subset of the usual operations, but which takes care of the file management in addition to the metadata storage.

The final interface should look something like this:

class FileStore<T> {
  // The directory this store is managing, and where it places its copy of the files
  final Directory baseDirectory;

  // Creates or updates an entry for T, backing it with the contents of `file`
  // If `file` is not "owned" by this store (e.g. not in its managed directory),
  // it will copy the file to take ownership of a copy of it.
  void write(T metadata, File file);

  // Returns a list of metadata + files matching the given query
  // The caller gets access to the files as they are managed by this store (e.g. residing in `baseDirectory`)
  // The caller may modify the files in place, but must not delete them on disk directly. For that they must use `delete` on this store in order to clean up the metadata as well.
  List<(T, File)> query(…);

  // Deletes the entry `metadata` refers to, as well as the backing file
  void delete(T metadata);
}

This implementation already incorporates some design choices, which could be adapted for different use-cases. Here the store will make sure that it always "owns" the underlying file. Thus when a file is added which does not reside in the directory managed by this store, it will copy it there and store a reference to that new location. On the flip-side (the reading) part, it will hand out Files referencing its internal storage paths, such that the caller might modify the file in place. This introduces a trade-off though, such that the store itself does not get notified of in-place file modifications (which may or may not be relevant to know about). This could be alleviated by e.g. always copying the files to a temporary location for reading, and expecting the outside to call write again after each change (at which point a copy would be written to the store's internal directory)[^1].

An approach like the one outlined above is implemented as an example here.

For brevity only the delete method is shown below, but write is similarly the reverse as described above (copying the file into the store's realm if needed), and get and query are just straightforwards read from the store to get the metadata and file path.

class DiskFileStore<Metadata, Key> {
  final IndexedEntityStore<FileWithMetadata<T>, K> _store;

  /// Remove the entry identified by [key] from the store, and deletes the backing file
  void delete({
    required K key,
  }) {
    final existingEntry = _store.readOnce(key);
    if (existingEntry != null) {
      File(existingEntry.filepath).deleteSync();

      _store.delete(key: key);
    }
  }
}

That's it. By combining the metadata writes with the files, we can now ensure that the pair of them is always up to date, and we have a single, simple interface to manage them together.

The upcoming 2.0.0 version of the package will furthermore introduce some additional enhancement for this use-case: As a file usually belongs to some other entity and doesn't exist by itself, it will allow you to reference that "parent entity" from the file's metadata via an index, for example a mail attachment might reference the parent like this: index((e) => e.metadata.mailId, as: 'mailId', referencing: 'mails');. This ensures that all file entries point to a valid parent. And if the parent gets deleted, its files must be cleaned up beforehand.

The above excerpt and the example in general make a lot of assumptions and design choices which might not be ideal for every use-case. But since the full "file store" is only 100 lines of code, I think it's clear that it can be easily adapted to suite one's needs (e.g. handing out temporary files, or using async file operations, ensuring notifications for file changes, etc.).

[^1]: On modern copy-on-write filesystems, though would not even need to incur performance penalty for the cases where the file is not modified after all.

Storing binary data in Flutter

Sun, 10 Nov 2024 00:00:00 GMT

Data storage in a Flutter app initially usually focuses on storing some domain objects (e.g. chat messages), whereas binary data (files) are often either loaded on demand (e.g. attachment downloads) or cached transiently with something like cached_network_image (e.g. for profile images).

But what is to be done when one needs to permanently store files with the app, either as a local cache to reduce network usage across app runs, or to support offline functionality?

Let's look it this from the perspective of persisting profile images, as these would generally be small enough to allow this thought experiment and to not force us into any specific storage medium by default.

Local files with pointers from the entities

Imagine a user class like typedef User = ({int userId, String name, String? profileImagePath }). The profileImagePath can be used to refer to a file on disk. This is easy enough to start with and populate initially, it would just be important to remove this file every time the that specific User object is either removed or updated to point to a new profile image path.
Because when looking into the "file folders" afterwards (in some clean up operation), it's probably not easy to identify which files are actively in use, and which are not and thus could be removed.

Storing files separately in the database

If we just need to store some files by known keys (e.g. profile_image_123), we could set up an IndexedEntityStore like this that stores the image like this:

typedef ProfileImage = ({int userId, Uint8List data});

/// Stores the profile images by user ID,
final profileImageConnector = IndexedEntityConnector<ProfileImage, int, Uint8List>(
  entityKey: 'profile_images',
  getPrimaryKey: (t) => t.userId,
  getIndices: (index) {},
  serialize: (t) => t.data,
  deserialize: (s) => (userId: -1, data: s),
);

The problem with this approach is approach is similar to the file storage above. While we can easy check whether we have a specific profile image stored for a user and then retrieve it, we can not (with the current library methods) get a list of all the profile images with their user IDs as the key is only used for storage but then not returned in deserialize or available to be queried (e.g. there is no getAllKeys).
This minor limitations could of course alleviated in the store's API (though it's questionable whether this would be a broadly useful extension of it), but when we work with what is available right now, we would still have to manually clean up each profile image when the user is deleted.

In a purpose-built SQLite-based storage for this use-case, one could of course have a foreign key from the profile images to the user, to ensure that they are removed in unison – or just make the profile image a column in the user table.

Storing the file with the entities

Another approach would be to store the file alongside the entity in whatever object storage the app uses. This introduces some obvious limitations, like the maximum file size (which is probably fine for a profile picture, not so much for a home video), and the amount of files any entity could refer to (is it 1 or 2, or n?).

It would probably not be advisable to put the profile image directly on the User object using any approach (like typedef User = ({int userId, String name, Uint8List? profileImage })), as that would leave no way to pass around the User without the image data. Also when serializing this, one would have to handle the primitive data and the user image separately, as the usual toJSON would not be satisfactory by default.

Storing files with metadata

So, if one still wants to store the files in the database, but not directly with the containing entity (such that also one-to-many relationship would also be possible without building bigger and bigger BLOBs), one might choose to save the file plus some metadata as its own entity.

The constraint of our chosen storage solution is though, that we only get one database field to write everything into. Thus we have to implement a storage format that can handle both the metadata and the binary data. In this case we'll assume that the metadata is much smaller than the actual data, and will prepend the metadata (as JSON in this case) in front of the Uint8List binary data.

The storage inside the database would look like this:

-------------------------------------------------------------
| Metadata length | Metadata JSON |       Binary data       |
-------------------------------------------------------------
     4 bytes        $length bytes           * bytes

The implementation of that storage approach might looks like this:

typedef ImageWithMetadata = ({ImageMetadata metadata, Uint8List data});

final imageWithMetadataConnector =
    IndexedEntityConnector<ImageWithMetadata, int, Uint8List>(
  entityKey: 'user_profile_image',
  getPrimaryKey: (t) => t.metadata.userId,
  getIndices: (index) {
    index((t) => t.metadata.userId, as: 'userId');
    index((t) => t.metadata.fetchedAt, as: 'fetchedAt');
  },
  serialize: (t) {
    final metadataJSON = JsonUtf8Encoder().convert(t.metadata.toJSON());

    final lengthHeader = Uint8List.view(
      // uint32 is enough for 4GB of metadata
      (ByteData(4)..setUint32(0, metadataJSON.length)).buffer,
    );

    return (BytesBuilder(copy: false)
          ..add(lengthHeader)
          ..add(metadataJSON)
          ..add(t.data))
        .takeBytes();
  },
  deserialize: (s) {
    // Get the lenght of the metadata
    final metaDataLength = ByteData.view(s.buffer).getUint32(0);

    final jsonDecoder = const Utf8Decoder().fuse(const JsonDecoder());
    final metaData = ImageMetadata.fromJSON(
        // pass a view into the metadata into the JSON decoder
      jsonDecoder.convert(Uint8List.view(s.buffer, 4, metaDataLength))
    );

    return (
      metadata: metaData,
      // Pass out the binary data as a read-only view into the raw value retrieved from the database
      data: Uint8List.view(s.buffer, 4 + metaDataLength).asUnmodifiableView(),
    );
  },
);

class ImageMetadata {
    final int userId;
    final DateTime fetchedAt;
    final Uri fetchedFrom;

    // […] implementation of toJSON/fromJSON etc. is omitted for brevity
}

With this approach we can just retrieve the profile image with it's metadata whenever we need it. As we stored the userId and fetchedAt properties as indexed columns, we can also easily query it for

no longer known user IDs (in case there was a bug and not all profile images where cleaned up when the user was deleted)
remove stale images (say fetchedAt is older than 7 days)
Check the metadata's original request URL upon read and re-fetch the image if the server has a new version available

A full-fledged example of this approach is available in the repository here.

Next steps

For the last example it would be super beneficial if we could add a foreign key constraint between the profile image entity and the known users, thus ensuring that the images get cleaned up when a user gets deleted.
This is a further direction to explore in the library, as it seems universally useful, and guarding against this from every possible angle seems cumbersome in the application code (as only the database can reliably enforce such an invariant).

Another abstraction to build on top of foreign key approach could be to combine disk file storage with such an external metadata storage, where insertions and deletions automatically handle the underlying file operations.
This seems much easier to get right on a single file basis for just read/write instead of handling it for various entity types whenever they get updated in the database.

Designing repositories for Flutter apps on top of `IndexedEntityStore`

Sun, 03 Nov 2024 00:00:00 GMT

IndexedEntityStore is a new synchronous database package to handle your Flutter app's persistent storage in an easy way, with a focus on simplicity and development speed.

Though it handles data management and efficient querying, it's only a small building block in the app architecture. For most use-cases one wants to probably build repositories on top of this storage – in combination with one's backend APIs – to put a full data-layer in place.

Let's now consider 3 examples approaches for how to do this. The API and usage of the package itself is not documented in detail, instead refer to the documentation if needed.

All the data, all the time

Consider a simple todo list app, where all the data is available all the time. If the app has a syncing capability, that might still run initially and throughout the usage of the app, but once these jobs complete 100% of the data of the app is available locally. This approach can lead to a very simple design.

class TodoRepository {
  TodoApi remoteApi;

  IndexedEntityStore<Todo, int> store;

  // Depending on the application's needs, this would either run initially before the user can interact with the app, or in the background
  Future<void> fetchAll() async {
    // This could be extended to only get new todos on subsequent calls, and then insert those locally
    final todos = await remoteApi.getTodos();

    store.insertMany(todos);
  }

  /// Return a live-updating query to the list of open todo items
  QueryResult<List<Todo>> getOpenTodos() {
    /// while the column access uses `String`s, it's still checked at runtime to refer to an indexed column
    return store.query((cols) => cols['done'].equals(false));
  }

  // Returns a "view" onto a stored todo item
  // The caller will automatically receive updates through the `ValueListenable` interface whenever the stored todo was changed in the database
  // The returned todo item is optional (nullable), as we assume that it might not have been synced to the local database when the request is made (e.g. because a todo detail page was opened via a deep link).
  // If the user could only navigate to existing/known items in the app, we could make it non-optional, which would simplify the usage site a bit.
  QueryResult<Todo?> getTodo(int id) {
    return store.get(id);
  }

  Future<void> updateTodo(Todo todo) {
    store.insert(todo);

    // Failure handling for this is left as an exercise to the reader. Depending on whether the app is offline-first or requires connectivity and instant updates on the server,
    // we could either store the todo with some "sync pending" flag locally and try again later, or roll back the local update in case the server call failed.
    await remoteApi.updateTodo(todo);
  }
}

Both read methods above (getOpenTodos and getTodo) return a QueryResult<T> which implements ValueListenable<T>. In a Flutter Widget one could use a subscription to these results in combination with a ValueListenableBuilder like this:

class _TodoListState extends State<TodoList> {
  late final openTodos = widget.repository.getOpenTodos();

  @override
  Widget build(BuildContext context) {
    return ValueListenableBuilder(
      valueListenable: openTodos,
      builder: (context, openTodos, _) {
        return Column( // or ListView.builder etc.
          mainAxisSize: MainAxisSize.min,
          children: [
          for (final openTodo in openTodos)
            CupertinoListTile(
              title: Text(openTodo.text),
            ),
          ],
        );
      },
    );
  }


  @override
  void dispose() {
    // important to unsubscribe here, so the database does not send any more updates into the `QueryResult`
    openTodos.dispose();

    super.dispose();
  }
}

On-demand data loading with offline storage

Next let's image a use-case where the data is not (or can not) all be known beforehand, and we need to fetch it on demand. This could be the case for example with an event-planning app, where event details are fetched on first view and which would from then on be available locally (with potential background updates from the server to communicate new changes).

class EventRepository {
  EventApi remoteApi;

  IndexedEntityStore<Event, int> store;

  // The list of events in a category is handled ephemerally in this case and not persisted in the database
  // For simplicity's sake we're using a `Future` here (and thus likely a `FutureBuilder` in the `Widget`)
  Future<List<EventsSummary>> getEventsInCategory(int categoryId) {
    return remoteApi.getEvents(categoryId);
  }

  // Returns a "view" onto an event detail (containing more information than just the summaries above)
  QueryResult<EventDetail?> getEventDetails(int id) {
    final event = store.get(id);

    if (event.value == null) {
      // event is not yet loaded into the store, so we need to fetch it
      remoteApi.getEvent(id).then((event) => store.insert(event));
    }

    return event;
  }
}

The simple method signature of getEventDetails hides one important fact though: While we can distinguish between "loading" and "loaded" (null vs. an non-null), the caller will not get notified if the remote loading fails.
To expose this further information we could change the signature to DisposableValueListenable<AsyncValue<EventDetail>>, but merging the local state with the latest API result is a little bit more involved and thus not part of this introduction. But a full example showing that approach is available here. Once this is abstracted and a common pattern in the repository implementations, this could likely become just second nature though.

On-demand data (alternative)

For the practically asynchronous data on-demand case as in getEventDetails above, a nicer signature might be FutureOr<DisposableValueListenable<EventDetail>>, as that clearly distinguished between "has the data been loaded successfully" and "here is a view to the latest local data" (non-null even, as we then expect it to stay available).

This could be implemented like this:

import 'package:value_listenable_extensions/value_listenable_extensions.dart';

class EventRepository {
  …

  Future<DisposableValueListenable<EventDetail>> getEventDetails(int id) async {
    final event = store.get(id);

    if (event.value == null) {
      try {
        final remoteEvent = await remoteApi.getEvent(id);

        store.insert(remoteEvent);
      } catch (e) {
        event.dispose(); // failed to load the data, close view to database

        rethrow;
      }
    }

    // If we reached this, we now know that we have a value in the local database, and we don't expect it to ever be deleted in this case, and thus can "force unwrap" it.
    return event.transform((e) => e!);
  }
}

To me this signature looks better, but we have to be careful when using it. It's important to always dispose the query result view (which is now wrapped inside a Future), so we'll have to keep that in mind. Especially since the Widget using it could already be dismissed before the Future resolved (e.g. when the data loading was so slow that the user went back), in which case we still have to clean up the query result should it become available.

class _EventDetailState extends State<EventDetail> {
  late final event = widget.repository.getEventDetails(widget.eventId);

  @override
  Widget build(BuildContext context) {
   return FutureBuilder(
      future: event,
      builder: (context, data) {
        if (!data.hasData) {
          return const CupertinoActivityIndicator();
        }

        return ValueListenableBuilder(
          valueListenable: event.requireData,
          builder: (context, event, _) {
          return EventTitle(event: event);
          },
        );
      },
    );
  }


  @override
  void dispose() {
    // Imporant to cancel the underlying value listenable here when it has finished loading, even if that may happen after the widget is already disposed.
    event.then((eventResult) => eventResult.dispose());

    super.dispose();
  }
}

If Dart had something like Swift's structured concurrency we might be able to cancel the work "inside" the Future in a more straightforward way, but while that is not the case an approach like the one shown above must be taken.

Both usages inside build and dispose can be greatly simplified though by the use of some helpers. We can easily imagine a FutureValueListenableBuilder that handles both the unwrapping of the future and listening to the changes inside it, as well as an extension method on Future<DisposableValueListenable<T>> which would make the clean up shorter.

Receiving File Drops on macOS (and iOS) with SwiftUI

Sat, 09 Jan 2021 00:00:00 GMT

<div class="note">A complete example of the code to be used on iOS and macOS is available <a href="https://github.com/tp/demo-FileDropTests">on GitHub here</a>.</div>

Starting Point

<figure> <img src="/assets/posts/file-drops-on-macos-and-ios-with-swiftui/ios_after_drop.png"> <figcaption>Example of the drop behaviour on iOS/iPadOS</figcaption> </figure>

While porting a pure SwiftUI app, I noticed that the onDrop file import handler used for the iOS app does not work as expected on macOS:

<figure> <img src="/assets/posts/file-drops-on-macos-and-ios-with-swiftui/mac_using_ios_implementation_file_url.png"> <figcaption>macOS app receiving a URL with a different path & content than the dragged file</figcaption> </figure>

providers.first!.loadFileRepresentation(forTypeIdentifier: UTType.item.identifier) {
  url, _ in
    message = describeDroppedURL(url!)
}

At first I thought it was just an issue with file names being erased / hidden, e.g. .com.apple.Foundation.NSItemProvider.MpBDqm.tmp instead of notes.txt, but upon closer inspection the file contents were also different. Instead of the expected data, the file read from the initial URL contained another URL in the form of file:///.file/id=6571367.2773272/.

Adaptation for macOS

Eventually I came to find out that these are known as File reference URLs, and this post offered a good reference on how they had to be handled historically (with NSURL), and that they should work out of the box with Swift's URL.

In order to avoid having the system to create temporary files which then need to be read & referenced to get to the final file, I switched the macOS implementation to read the dropped file URL from the NSPasteboard item itself:

providers.first!.loadObject(ofClass: NSPasteboard.PasteboardType.self) {
  pasteboardItem, _ in
    message = describeDroppedURL(URL(string: pasteboardItem!.rawValue)!)
}

<figure> <img src="/assets/posts/file-drops-on-macos-and-ios-with-swiftui/mac_with_nspasteboard.png"> <figcaption>macOS app after the updated: Being able to read the correct file name and contents</figcaption> </figure>

Bonus

One last finding I made during testing was that the dropped data was different from whether the item was dragged from within the Finder's tree view compared to when it was dragged from the title bar 🤔

Luckily the final implementation works just fine with either of these 🤗

`usePromise`: A React hook for async data loading with server-side rendering (SSR) support

Sun, 29 Sep 2019 00:00:00 GMT

<div class="note"><b>Out now:</b> This post explores the background behind a new library, usePromise, that is now <a href="https://www.npmjs.com/package/@timm/use-promise">available on NPM</a>. The source code and examples are available on <a href="https://github.com/tp/use-promise">GitHub at tp/use-promise</a>.</div>

React hooks can help build components made up of re-usable smaller helpers while still staying readable and clear even when a bunch of features are combined. This is a nice contrast to the previous lifecycle methods across in which multiple "extensions" wheren't always clearly visible - might it be because they only appeared in some methods, or because they appeared in a different order in each one and hence weren't as easily scannable.

So when looking at a component design that would allow for 100% custom components to be injected into an app skeleton, fetching data via hooks seemed like a great solution. In contrast to render props and similar approaches, it doesn't limit the consumer to what is provided by the outside helper in one pattern, and then force one to use a possibly different approach to load further data. (Or use nested render props components, which IMHO don't read that well and still require manual passing of the props.)

So I was a little surprised to find out that as of now (React 16.8) one couldn't easily compose a new hook for async data loading (with SSR support) for 2 reasons:

State managed using the setState hook couldn't be read out and be transferred to the client
Loading data asynchronously, and hence calling setState after the initial render on the server, doesn't work with the current default model, which only renders once.

Point #2 seems like a reasonable general limitation, because when you trigger the data loading in the component to be rendered, one for sure needs to attempt to render that component again after the data has been loaded. Rendering n + 1 times (n for each data loading operation and then once for the final render to find out that there is nothing new to fetch) is an overhead not to take lightly, but luckily React is working on a remedy to make this more lightweight with Suspense in the future.

So while waiting on React to support #2 by default and at the same time adding a solution for #1 for the specific context of data-loading which does not require learning and setting up any state-management solution, I looked into building a small hook that would accomplish this.

The challenge, as mentioned before, is that any component in the tree could trigger a data-fetching operation, and then rendering would need to halt until that Promise is resolved. In lieu of Suspense the best I could come up with was to use the approach of rendering the whole tree again (something I also observed Apollo do) after each individual data loading operation has completed. Taking another page from the current Suspense playbook, whenever a component wants to load data via this new hook, it throws that Promise, which the library then awaits before attempting to render again. Once a render completed without any new Promise being scheduled (thrown), that rendering is taken as the final result and sent to the client.

In standard hooks fashion the library builds up an array holding the data of the single ongoing and potentially many completed Promises. This data is then distributed on each rendering attempt to the hooks in order. Since this is only needed on the server (in an unchanging render tree) and then once for rehydration on the client, there is no issue with using this one global array (scoped to the current request) for the whole page (instead of a per component array which React itself uses).

The final data of all Promises is then serialized into the HTML send to the client, where it's used for the initial rehydration, after which it switches to rely on React's setState for managing further mutations.

In then end the usage looks like this:

function WhatToWear() {
    const {loading, error, data} = usePromise(() => weatherApi.getCurrentWeatherAsync());

    if (loading) {
        return <div>Loading…</div>
    }

    if (error) {
        return <div>An error occured…</div>
    }

    return <div>Recommended outfit: {weather.temp > 19 ? '👚' : '🧥'}</div>;
}

The plan is now to take the usePromise helper and build up hooks for the specific domain, so the consumer wouldn't have to deal with providing the Promise creating function herself.

In the end the resulting API is really small, just one line to pull in a some fully typed data and have the library taking care of data loading on the server. Additionally the consumer now has to take care of rendering the loading and error cases, but that would be something they will have to deal with in any case, unless they're fine with rendering some default message, which could easily be achieved with a helper component.

Overall I am quite happy how this turned out on the usage side, even though the implementation has some rough edges and overhead at the moment. Possibly the overhead can be reduced in the future with Suspense – if this library will not be made obsolete outright by it. In either case, the transition to some future React version should be smooth, very likely allowing us to keep the same outside API.

For now this is exactly what was needed and building up on so much great technology and inspiration I was happy to see how it could be achieved in a short amount of time.

Thoughts on API design

Initially the library followed the useState approach and returned an array of type [boolean, T, unknown], which could be used for example as [completed, weather, error] (in the example case of fetching the current weather). The interesting bit here is how the array model doesn't even suggest default names, and the user is forced to pick some for his use-case. But just having the types might be confusing in 2 cases: When not using / seeing the types immediately in the editor, or when the return type is boolean or anything unspecific like the unkown error type. In those cases it might not be obvious at which index the result is stored, especially if the library is not very familiar to the user (unlike setState which one probably interacts with daily in a hooks-using codebase).

The array approach was then debated, and since the primary use case was data loading, the API was changed to match Apollo's useQuery (the actual types are more specific than the example below):

{
  loading: boolean;
  data: T;
  error: Error;
}

As you can see, it's now an object which provides explicit names for each field. completed flipped to loading, which makes writing early returns much nicer. error is now limited to Error, but that might just be a temporary solution. What I wanted to achieve there was that error could be checked with a simple if, and if it was falsy the Promise would have resolved successfully and data would contain the result.

Remapping the names to something specific is still easily possibly.

One further consideration was how use the hook multiple times in a row. Then having multiple loading and error states might get very cumbersome, especially since you musn't return early for any Promise rejection.

In the end the current design and documentation hopefully leads people to write a single helper function loading all relevant data for a component. This is a lot more efficient with the current implmentation detailed above, as well as making the component clearer as it has less states to think about.

If you have any feedback on the API design, for example feeling it's now to focused on data loading, or any other suggestions feel free to open a ticket with your feedback.

Closing Thoughts

One thought that always pops up in my head when working on components which trigger or manage their own data loading – especially whenn this done across multiple layers of components – is whether it's desirable and should be done that way at all.

I think it's always worth to imagine what the alternative design of having a storage & side-effect solution outside of the component tree would look like and what benefits one might gain from it. Compared to the above example, one clear benefit would be that one could do the data loading first, and then be done after a single render. On the other hand that forces one to combine all data-fetching logic into a single step on this "other side" – which might or might not be a good thing.

In the end this boils down to picking what's right for the problem at hand. In the above case the goal was to make it easy to insert 1 or 2 data loading hooks across a page, and for that it seems far more approachable than learning any specific store system and hooking into it.

<div class="alert">👨🏼‍💻If you strive to make life developing web applications easier and enjoy exploring beyond the known solutions <a href="https://corporate.aboutyou.de/de/jobs/senior-frontend-developer">this might job might fancy your interest</a>.</div>

Rendering a combined list view from multiple list using Flutter's `SliverList`s

Fri, 20 Sep 2019 00:00:00 GMT

The previous post showed how to flatten grouped data with a header above the items so it can be rendered in a single ListView widget. Now I want to look at a diffent use-case: Rendering lists from distinct data sources after each other. This implementation will use a CustomScrollView and SliverLists. If you're unfamiliar with slivers, I would recommend reading Slivers, Demystified first, as the below example will just focus on this one narrow use-case, while the overall setup supports much more.

The Example

For this demo I want to render a single list showing the user's favorite items, then some static content, and below that recommendations of similiar things. Since this simple example only has 3 row types, we could implement it using the ListView approach shown before. But as the row types are never mixed together and since in this example there are only 3 sections (favorites list, static content, recommendations list) I think it's a good case to create a widget for each section of the scroll view and then combine those into one scrollable list using CustomScrollView.

<div class="note">The demo app and code for is available on <a href="https://github.com/tp/nested_listviews">GitHub at tp/nested_listviews</a>.</div>

On the top-level, the widget that sets up the list as a CustomScrollView is nicely readable and gives a nice overview of what will be shown in it:

Widget build(BuildContext context) {
  return CustomScrollView(
    slivers: <Widget>[
      Favorites(),
      Static(),
      Recommendations(),
    ],
  );
}

Now onto each sliver itself:

Favorites renders a SliverList with a SliverChildBuilderDelegate; so it could handle a large amount of items
Static uses a SliverChildListDelegate in its SliverList as it renders just one very simple widget
Recommendations uses the same approach a Favorites, just with a different widget for its rows

So the Favorites and Recommendation builder methods look both roughly like this:

Widget build(BuildContext context) {
  return SliverList(
    delegate: SliverChildBuilderDelegate(
      (context, index) {
        return XyzRow(data: index); // might be `data[index]` in practice
      },
      childCount: 100, // might be `data.length` in practice
    ),
  );
}

Overall the whole source code for this example looks to me a lot simpler than what we had in the previous case even though it seems like a more niche use case than rendering a grouped list. I think that stems from the fact that this "lists below each other" is nicely supported by the framework, while the grouped display was not.

In a real app one might need to combine the 2 approaches: Render a grouped list view from a flattened list with a SliverChildBuilderDelegate inside a CustomScrollView which also contains other lists. That is left as an exercise to the interested reader though 😉

<div class="alert">👨🏾‍💻 If you love working with Flutter and like to dig deep to find the best approach to each problem, <a href="https://corporate.aboutyou.de/de/jobs/dart-developer-shop-applications">we might just have the perfect job for you</a>.</div>

Nested `ListView`s in Flutter

Wed, 18 Sep 2019 00:00:00 GMT

If you've ever tried rendering a simple ListView inside the itemBuilder method of another ListView you'll most certainly have encountered the Vertical viewport was given unbounded height. exception.

The simple fix (which ranks up top on Google) is to add the shrinkWrap: true property to the inner ListViews. Once that is changed the initial screen renders fine, until you try to scroll the overall list, which is not possible because any drag actions on top of the inner ListViews just scrolls them (even though they might be "fully" rendered). The fix for that issue is then to add physics: ClampingScrollPhysics() to the innner ListViews.

With those 2 lines added to the inner ListView the initial issue is solved and one might consider it done. I would like to disagree and suggest some alternatives. In this I'll article explain why there is no need to nest ListViews in the first place, how nesting them can be misleading about their performance characteristics (which are bad in practice), and how SliverList is a better approach should you ever have the need to render multiple list below one another.

<div class="note">The demo app and code for each approach is available on <a href="https://github.com/tp/nested_listviews">GitHub at tp/nested_listviews</a>.</div>

Performance characteristics of nested `ListView`s

All of the nested ListView code I have seen in the wild recently used the seemingly performant ListView.builder constructor for the outer and inner ListViews. So it seems like developers are aware that it exists and should be used, and the documentation clearly states the advantages of it:

This constructor is appropriate for list views with a large (or infinite) number of children because the builder is called only for those children that are actually visible.

Unfortunately though, that is not true anymore for the inner ListViews. Because the outer view needs to know how tall the inner ListViews are, the inner ones will get rendered in full until the height is filled. But at the very least the first list view will get rendered in full, which is already bad should that contain many items. This behavior can easily be verified by putting a print in the itemBuilder of the inner ListView:

As you can see in the example above, the 1000 items for the first inner ListView were build, even though only 50 are visible on the screen.

Whether or not this is an issue in your application depends on the maximum amount of items in the inner ListViews. Just from reading the code one might think though that it behaves efficiently – meaning it really only renders visible items – which it does not. Hence I would find it more honest to use a Column and plainly map the items to widgets. Also in the general case that reads nicer than retrieving the item by index from the underlying storage as has to be done with the itemBuilder:

// [... wrapping ListView.builder omitted]
return Column(
  children: <Widget>[
    ...List.generate(
      1000,
      (innerIndex) {
        return Text('Outer = $outerIndex, Inner = $innerIndex');
      },
    ),
  ],
);

The flattened list approach

So far we've only seen how a nested ListView is as much work to render as a Column or a similar widget. One approach I would like to suggest, for most cases, is to unnest the rendering and make do with a single list view. This can be achieved in a variety of ways, but the simple approach of flattening the data structure into a single array should work up to a huge number of items. Just make sure not to compute that flattened array in the builder method, but rather once initially and on updates and keep it stored in some state.

Suppose we'd wanted to build a todo app. Let's assume our API returns us a list of sorted groups (for example by day) in some kind of Section type:

@immutable
class Section {
    Section(this.title, this.items);

    final String title;

    final List<String> items;
}

Now instead of rendering the outer ListView with the Sections as items and then an inner ListView for each section, we can flatten the Sections into a list of Rows (a new type we define for this case).

@immutable
abstract class Row {} // approximation of a union type in Dart

class HeaderRow implements Row {
  HeaderRow(this.title);

  final String title;
}

class ItemRow implements Row {
  ItemRow(this.description);

  final String description;
}


// tasksByDay is a List<Section>
final items = tasksByDay.expand<Row>((section) {
  return [
    HeaderRow(section.title),
    ...section.items.map((item) => ItemRow(item)),
  ];
}).toList();

And then that items list can be rendered with a single ListView which renders a specific widget dependening on each item's type:

ListView.builder(
  itemBuilder: (context, index) {
    final item = items[index];

    if (item is HeaderRow) {
      return Text(item.title,
          style: TextStyle(fontWeight: FontWeight.bold));
    }

    if (item is ItemRow) {
      return Text(item.description);
    }
  },
  itemCount: items.length,
);

With this approach a little upfront work is required, but then only the rows visbile on screen (+ some small amount of extra rows rendered by the framework) are built:

`SliverList`s inside a `CustomScrollView`

The above approach of flattening the list is in my opinion a good approach to render such a grouped list view, but it's only suitable for lists that have few row types. Should you ever have the need to render lists from different domains in a single list after another, then a CustomScrollView with SliverLists for each specific type of list seem like a better approach in my opinion. I'll write up an explanation and code example on those in a follow up post.

Recap

I hope I was able to show how nesting ListViews inside one another might not be a good idea for the problem at hand, and what other implementations are available. You can either use a Column or any other "simple" widget for the inner lists, or flatten the whole list for rendering and by through that achieve the ListView.builder's promise of only rendering items which are visible on screen.

<div class="alert">👩‍💻 If you love working with Flutter and enjoy sweating the details, <a href="https://corporate.aboutyou.de/de/jobs/dart-developer-shop-applications">we might just have the perfect job for you</a>.</div>

Making HTTP Requests in Flutter Tests

Fri, 03 May 2019 00:00:00 GMT

By default all HTTP request made in a test invoked with flutter test result in an empty response with status code 400.

Generally that seems like a good default behavior to avoid external dependencies and hence reduce flakyness in tests. But what if you really want to make HTTP requests in your tests?

<div class="note">HTTP requests are disabled for a good reason. Before enabling them, think about whether you have an even better reason to revert that behavior.</div>

Since making outgoing requests in tests is discouraged, the usual advice is to use a mock client (for example MockClient from the http package).

But how does one then efficiently and correctly create mock responses and assertions for incoming requests? For that we've written a request/response recording HTTP client.

Tests get run once with recording enabled, which writes the requests and responses as JSON files to disk. On subsequent runs the recording can then be disabled and all requests will be served form those files.

So that's why we needed to enable HTTP requests during tests in this specific case. How does one go about enabling them?

Turns out there is a discussion about this exact behavior on Flutter's GitHub Issues which I was lucky to find after some searching. The simplified version of that solution, shown here as part of a test, is this:

import 'dart:io';
import 'package:http/http.dart' as http;
// [...] other testing imports

Future<void> main() async {
  HttpOverrides.global = _MyHttpOverrides(); // Setting a customer override that'll use an unmocked HTTP client

  testWidgets(
    'Test with HTTP enabled',
    (tester) async {
      await tester.runAsync(() async { // Use `runAsync` to make real asynchronous calls
        expect(
          (await http.Client().get('https://www.google.com/')).statusCode,
          200,
        );
      });
    },
  );
}

class _MyHttpOverrides extends HttpOverrides {}

Page Generator TypeScript Rewrite

Sun, 06 Jan 2019 00:00:00 GMT

After switching away from Jekyll (since I have no familiarity with Ruby and was running into limitations of how to structure this site), I wrote my custom static page generator in Swift. I choose Swift because I had been meaning to explore the language, but had no Apple-platform project on the horizon and thought it might be as good as any language to convert Markdown and write some static files.

But after the initial creation I never touched it much. Development always felt a little heavy and slow and I wasn't content with the libraries and approach I picked.

So this weekend I took the to rewriting the page generation to TypeScript. Since it's currently my main development environment, it was quick to get the basics up and running. For now it's just a static site generation, with no client side rendering.
Though I'd love to add that in the future to have a personal project with SSR + CSR to better explore different approaches here.

I was delighted how for every problem I had (React instead of templating, Markdown, code syntax highlighting, file access) there were already solid libraries to choose from. Some I'd liked to be a little different, but overall this toolset is extremely practical.

In the end the whole code base is just 515 lines (in its first draft, without any code-level compression applied) and contains all the flexibility and customization I desire. And I can build and run the application to generate all pages in under a second 😀.

<div class="note">All code is available in <a href="https://github.com/tp/page/tree/master/src">this GitHub repository.</a></div>

TypeScript: `ReturnType` for `async` `function`s

Mon, 27 Aug 2018 00:00:00 GMT

Since the introduction of the ReturnType in TypeScript 2.8, we can build up types based on the results of functions, without mentioning the types explicitly:

function createContext<T extends () => any>(
  configProvider: T,
): { config: ReturnType<T> } {
  return {
    config: configProvider(),
  };
}

function apiConfig() {
  return {
    endpoint: "https://www.example.com",
  };
}

/**
 * context has type `{ config: { endpoint: string; }; }`
 */
const context = createContext(apiConfig);

Playground

Now that async functions are becoming more prevalent in the code I work with, I have been wondering whether a similar helper can be employed to get the type of a successfully resolved Promise.

As a first building block I wrote a type to extract the Promise's resolved type:

type PromiseResolvedType<T> = T extends Promise<infer R> ? R : never;

// Type is currently Promise<number>
const promise = Promise.resolve(3);

// value has type `number`, will stay in sync with type of `promise` variable
let comparisionValue: PromiseResolvedType<typeof promise> = 5;

promise.then((value) =>
  console.log(`Value equal to comparison?`, value === comparisionValue),
);

Playground

That works nicely to limit our comparision value to the same type as the Promise instance might eventually resolve to. That way we can ensure consistency. If the types were not matching, the comparison will definitely fail, so we get faster feedback by moving that first check to the compile time of the program.

The final step is now to return the ReturnType with the PromiseResolvedType to access the success value of a Promise returned by a function:

type PromiseResolvedType<T> = T extends Promise<infer R> ? R : never;
type ReturnedPromiseResolvedType<T> = PromiseResolvedType<ReturnType<T>>;
// or flattened: type ReturnedPromiseResolvedType<T> = T extends (...args: any[]) => Promise<infer R> ? R : never;

async function random(): Promise<number> {
  return Math.random();
}

type RandomFuncResolvedType = ReturnedPromiseResolvedType<typeof random>; // number

Playground

Custom Cursors: Creating CUR Files from Canvas

Sat, 21 Apr 2018 00:00:00 GMT

A recent product design required switching various custom, dynamic cursors at runtime. These were prepared at runtime and drawn onto a Canvas:

In Chrome and Firefox those canvases can be used as a cursor by setting the cursor property in CSS to url(canvas.toDataURL()). The data URL is guaranteed to contain a base64 encoded PNG image of the canvas.

Edge though currently only supports CUR files. Those files wrap the cursor image, optionally at different sizes, with some metadata. Luckily for us, a newer version of the CUR file format allows embedding PNG file data directly.

So I wrote a small library that reads a canvas into PNG blob and then inserts this data into a new Blob that builds up the CUR file. We can then create an "object URL" of that CUR file which can be used in CSS similarly to the above method.

Example:

// call the `curObjectURLFromCanvas` function to retrieve an object URL pointing to a `CUR` file containing the canvas' image
const cursorObjectURL = curObjectURLFromCanvas(canvas);

// Use this URL in your inline style (or in a programatically created `StyleSheet`)
body.style.cursor = `url(${cursorObjectURL}), pointer`;

The library is called cursor-utilities and is available on npm, and the source is on GitHub.

WebGL: Smooth Edges on Transparent Canvases

Sun, 18 Mar 2018 00:00:00 GMT

Task

For a client project I needed to draw text on a transparent WebGL canvas, which was overlaying a video playing in the background of the page.

After having a hard time with some of the more elaborate Three.js based examples, I was able to quickly gain an initial understanding of the underlying plumbing when studying this WebGL-from-Scratch example.

The effect came together quickly and looked great, but unfortunately it didn't render the same across all browsers. In Safari the partially transparent edges of the text where leading to while artifacts, as to can see here around the highlighted arc of the letter e:

At first I thought the alpha property of the contextAttributes hadn't been honored, but when switching to a partially transparent font I would be able to see through the letters just fine.

Solution

Since I was already investigating the context properties, I tried my hand at the next one that could be related related to the transparency issue: premultipliedAlpha.

Simply changing this from false to true didn't improve anything for me in Safari. That was not entirely unexpected, since I assumed that I would have to actually "pre-multiply" the alpha for the setting to work correctly.

I didn't know how to actually do this, and whether or not this could even be done with information from the canvas alone (or whether it would require knowing what is underneath it), so I just implemented this first attempt in the shader:

vec4 pixel = texture2D(tex0, uv).xyzw;

gl_FragColor = vec4(pixel.x * pixel.w, pixel.y * pixel.w, pixel.z * pixel.w, pixel.w);

Luckily that did indeed solve the white marks on the edges, which are now very smooth:

Next Steps

While the edges are now smooth across the 3 browser listed below, you can see that the rendering color differs across them:

Next, I'll have to look into how not only to achieve smooth but also color correct renderings.

7 Days Without Recreational Media

Fri, 23 Feb 2018 00:00:00 GMT

If I didn’t write this today—right now even—I’d never do it.

Over that last 7 days I’ve been going on a “recreational media hiatus”—meaning not reading, listening to, or watching anything that is not directly applicable to the work at hand.

While there is a current trend to ignore specific social networks for a while, this included every single leisurely used[^0] information source, such as:

Books not concerned with the current day’s task
Any Blogs, News Site, Aggregators ("push" content)
Podcasts and Audio Books
E-Mail Newsletters[^1]
TV, Movies, and Radio when alone

The only two exceptions I allowed myself was using the Calm app's sleep stories, and the Pema Chödrön meditations collection. I anticipated that I wouldn’t want to spent every minute alone doing work or nothing at all, so getting deeper into meditation seemed like a worthwhile endeavor, one that would hopefully further unclutter and calm my mind.

I made the decision to try this for a week, while sitting on a train and skipping into the third audiobook on 1 hour ride. I somehow felt that something must be wrong when I couldn’t even keep my attention on an audiobook that I chose myself and wanted to, or at least aspired to, listen to.

Similarly I noticed that while taking a break during work (🍅), I would often get lost on a tangent like some interesting but obscure technology or some new open source project, which would then far exceed the 5 minute goal time.
While getting input from outside my immediate area of work and interest is generally an inspiring source, oftentimes nothing sticks out and I wouldn’t have been able to recite half of the topics I scratched that day when asked about it before bedtime.

Here are some unordered observations I made throughout the week:

As there were much less inputs, every single one of them left way more of an impression, and got more time and thorough thought than in any previous week
The meditation felt much easier, more fruitful as my mind was not cluttered with technical trivia. Instead I was able to better listen to the teachings and myself
A lot of times at night I had neither energy to work on anything specific nor the willingness to listen to mediations, so I just ended up doing nothing—just sitting and thinking
In the course of the week, snacking emerged as an alternative distraction/feel good mechanism. Apparently there were some voids to fill
Every bit of personal interaction got more valuable. Before I was often so focused on my reading etc. that I would view everyone else nearby as a distraction. Now I was grateful for conversations
The insights I gained during meditation and the “just sitting” times were profunder than anything I have ever experienced. Instead of just hearing the teachers opinions/experiences/facts, I had some very deep insights emerge from within[^2]

If I ever get to do this again (who knows, maybe by this time tomorrow I am so exhausted from my “cheat day”, that I'll plan doing this regularly), I will definitely prepare myself to not fall into the next trap, i.e. stock up on healthy, boring food.

Other than that I appreciated the change this week, and how it allowed me to reevaluate my day-to-day behavior and see this media consumption in a more honest light: it's primarily distractions and rewards, which I was voluntarily seeking out–craving even. Only secondarily were they are source of information, often neither actionable or acted upon.

[^0]: This is an important distinction to make. While often those media are deeply technical in some field, aspirational, or otherwise of importance to some, I often would just read them for recreational purposes: satisfaction and distraction.

[^1]: Yep, it’s not enough these days to ignore specific apps and not visiting specific sites, somehow I justified for a while now to clutter my inbox with non-critical information. If some site only offers e-mail updates, I will not subscribe to them anymore. The overall downside just outweighs any single of those sources. Side-note: Feedbin has a great service where you can have newsletters/mails shown alongside your RSS subscriptions.

[^2]: I think this stems from a mix of the longer time spent doing meditation as well as the different style used on the above mentioned audio collection. It’s meditation practices framed by teachings into hour-long sessions. This additional time compared to the short 5-15 minute sessions others offer might’ve been a major contributor to this.

An Asynchronous Web API in 1994

Tue, 12 Dec 2017 00:00:00 GMT

After going down a Hacker News initiated rabbit hole, I crossed Donald Knuth's 2017 Christmas Lecture and from there ended up on the Online Encyclopedia of Integer Sequences.

For every integer sequence you provide, it lists the known occurrences and, if available, formulae that can be used to generate them.

One interesting detail is, that every page still had a "generated in N seconds" footer, where N often was > 5s for my test queries. So it seems like searching 295.000 possible sequences still takes a little computing time, even on modern hardware.

But while getting an answer on modern hardware in a few seconds is acceptable, let's image how much longer this might've taken a few year back.

In order to offer advanced searches and explain sequences a new service was established in 1994: "Superseeker". As this services does some "serious computing", we can take a guess at how much longer it must've taken to complete a query.

So in order to offer this at that time (where homes still had per-minute dial-up), the search API was implemented on top of plain e-mail.

That way the server could take as long as it needed to generate a response, and the sender would be notified as soon as possible once the calculation was done. What a beautifully simple approach.

Software based on the original bunch of shell scripts from back then is still in use and it's source code is available here.

Sam Harris: Lying

Sun, 27 Aug 2017 00:00:00 GMT

"We often behave in ways that are guaranteed to make us unhappy."

Q: What is lying?
A: "To lie is to intentionally mislead others when they expect honest communication."[^1]

At this point it is important to differentiate between telling the truth and being truthful. In my understanding of Harris' text, one is lying when "believing one thing while intending to communicate another" (i.e. not truthful). I am unclear on what is made of uttering statements one believes to be true, but which are objectively false.

Harris further advocates for telling the truth, as it is just easier. Instead of keeping track of a made-up story, "we can simply be ourselves".

2 Types of Lies

Acts of comission: "Bad things we do"
Acts of omission: "Good things we fail to do"

According to Harris the former are viewed more harshly than the latter. Also it could be impractical or infeasible to clarify every (unimportant) misunderstanding in which case an act of omission might be justifiable.

On "White Lies"

Often times people think they're helping by telling these, but Harris lists a plethora of examples were white lies have a detrimental effect not only on the receiver, but also the sender.

A common area of this seems to be around medical issues, where family members keep each other in the dark about the actual situation, leading to lost "opportunities for deepening love, compassion, forgiveness, and understanding".

"Children do not learn to tell white lies until around the age of four, after they have achieved a hard-won awareness of the mental states of others."
"False encouragement is a kind of theft: it steals time, energy, and motivation a person could put toward some other purpose."[^2]

Illusory Truth Effect

"[...] people will recall [something] as fact [...] even if they were first exposed to it in the context of its debunking."

"By lying, we deny others a view of the world as it is. Our dishonesty not only influences the choices they make, it often determines the choices they can make — and in ways we cannot always predict. Every lie is a direct assault upon the autonomy of those we lie to."

The whole book is a short read.

[^1]: According to studies quoted in the book, "10% of communication between spouses is deceptive", and "38% of encounters among college students contain lies".

[^2]: This to me is currently a major argument against acts of omission, and forces my conscience to consider clarifying implicit but also incorrect understandings and assumptions.

Rich Hickey: Step Away from the Computer

Sat, 26 Aug 2017 00:00:00 GMT

Also known as Hammock Driven Development

Opening Question: When was the last time you thought hard about something for

an hour?
a day?
over the course of a month?

"Key Note" talk by Rich Hickey focussing on the problem solving aspect of programming, which in his experience is influenced and successful due to a lot of thinking without the computer at hand.

He starts out with the well-established data point that bugs are most costly when they have to fixed in production and that it would be preferable to fix them during development.
Then he goes backwards one step further and suggest that bugs are least expensive to prevent in the design of the software.
Relating to this, it is his understanding that "the biggest problems in software are problems of misconceptions". When not the actual problems at hand are solved, but rather an attempt is made at solving perceived problems or problems arising solely from the suggested "solution".

Another interesting section was about tradeoffs, a word often used to justify a rushed or not fully tested implementation. According to Hickey a real tradeoff requires at least 2 possible solutions, which are then weighed and, finally, one is picked. Once you made a tradeoff, he suggests to record your reasoning and the decision in writing.

The major problem this talk focuses on, going back to the opening question, is that not enough thought is put into the problem solving aspect of software development (which after all is the whole purpose of writing programs commercially).

Speaking of the mind Hickey starts out describing it as two parts: the "Waking Brain" and the "Background Brain". According to Hickey the first one is very tactical, while the second one is strategical, abstracts, has a great ability to synthesize. Unfortunately the "Background Brain" can't be used directly, but rather will work on what is most prominent in the "Waking Brain". The way to get the "Background Brain" to work on what one desires, is to "load it up".

In order to do this, one foremost has to be aware that the "Background Brain" can only work on 7±2 problems. So how does one deal with designs that have more than 9 parts? According to Hickey a limited subset of problems should be picked and focused on those.
Once the problems to be uploaded are picked, the currently proposed solution (from the "Waking Brain") should be written down.

Then one should go over the picked problems in varying orders.

With all this preparation done, now the hammock comes into play. This "mind's eye time" — lying down with your eyes closed and thinking uninterruptedly — is an integral part of the process.

Whenever you "hear back" from your "Background Brain", depending on the situation you might want to act on it immediately, or just take note of the proposed solution. Preferably in writing.

Fetching Potentially Compressed Webpages That Might Not be UTF-8 Encoded in Rust

Sun, 07 Aug 2016 00:00:00 GMT

TL;DR This write-up explains how I build my first Rust crate to fetch compressed, non-UTF-8 encoded webpages. If you want to get straight to the code grab the final fetch crate on crates.io or view the source on Github.

For a side-project I needed to download some arbitrary webpages (HTML or plain text only). In absence of a targeted shipping date, I decided to use this opportunity to write this piece of software in Rust which I have interestedly observed for a long time but never actually used.

Preparation

Since there is no http client in the Rust standard library I picked the currently most popular http library on crates.io: hyper.

The basic client example looked fine initially but quickly turned out to be insufficient when testing with a variety of sites. Many sites send compressed or non-UTF-8 encoded data, and while the former could often be solved by setting the Accept-Encoding header to identity, the latter required some more changes to the program since strings are always UTF-8 encoded in Rust and thus needed to be converted.

So I expanded my list of dependencies to the following set of crates:

hyper: http client to retrieve the data from the server
flate2: compression library that is used to decode gzip and DEFLATE compressed responses
encoding: character set conversion from various encodings to Rust strings

Implementation

First let's look at how easily the current implementation make it to fetch a pages body as String:

let body = fetch::fetch_page("https://www.rust-lang.org/en-US/");

The final project used for the prototype and this blog post is available on Github at tp/fetch-rs. It has also been publish as the fetch crate on crates.io.

Like alluded to above, I started out with a simple hyper client that worked fine for the first few manual fetches. I could just read the response into a string using:

let mut body_buffer = String::new();

response.read_to_string(&mut body_buffer);

But this would fail when the page was not encoded in UTF-8 or would just return garbled output for compressed content.

So I went looking for an encoding and a decompression library, which let me to encoding and flate2.

Now things became a little more involved since I had to explore the 2 new crates, which had to be done differently from how I would normally approach this, since full autocompletion for crates is not yet available. But thanks to the pervasive use of rustdoc there is a good amount of documentation on every crate that I encountered.

So after a while of reading the API documentations, I was able to unzip the response body

let mut unzipped_body_buffer = Vec::new();
GzDecoder::new(body_buffer.as_slice());
d.read_to_end(&mut unzipped_body_buffer);

and also convert the given charset to UTF-8:

let decoder = encoding_from_whatwg_label(charset).unwrap();
return decoder.decode(&unzipped_body_buffer, DecoderTrap::Strict)

[Please note that the examples above are abbreviated excerpts from the actual source code and do not contain proper error handling. Please look at the source to see how errors are currently handled.]

Once my spot checks succeeded, I wanted to try the Rust testing facilities to ship some tests with the library. As it turns out, testing your code is super easy: Just annotate test functions in your library with #[test] and run cargo test.

Currently I just check whether the fetch returns a success value, but as a next step I want to setup a test server and compare the whole response body to a reference file.

#[test]
fn fetch_deflate_compressed_page() {
    fetch_page("http://httpbin.org/deflate").expect("Fetch to succeed");
}

After all tests passed[^1] I was satisfied with the initial scope of library and went on to publish it to crates.io.

This turned out to be a little bit trickier than it probably should have been, due to me initially naming the crate “http-fetch”.

When integration testing the crate with another project I soon found out that while your crate name on crates.io can contain a hyphen, you have to import it with a different name when using it in Rust code. Not wanting to explain this (confusing) behavior in the README I decided to rename the crate (which I had already published). Since it was not possible to rename from “http-fetch” to “http_fetch” for some reason (cargo would not allow this), I created a new crate named “fetch”.

Retrospection

Though this project is small and in a functional state right now, there are already a number of points that I need to dig into deeper before writing more complex programs in Rust:

Error handling: In order to return errors from fetch using the Result type which requires a common interface for all possible errors I am currently transforming all errors and replace them with a string containing a short description of where the error occurred. Sadly this looses the original error, which the call side might want to evaluate to help with debugging etc.

Borrowing and Ownership: When reading into the buffer a second time I would get error E0506 reported by the compiler. While I don't yet fully understand the reason for this, the suggested solution of just scoping offending code in its on { } block works.

A lack of understanding lifetimes has also so far prevented me from breaking the code up into smaller functions, which would require some special annotations (I assume).

All in all I was highly rewarded for this experiment by being exposed to new concepts and different approaches to API design and programming altogether. Furthermore I was positively surprised how quick I could pursue and find my way around the crates given the lack of full code completion. Thanks to great documentation being available for all crates used, this was not as big of a slowdown as I would have expected initially.

Now I am looking forward to writing more code in Rust and get a better understanding of and write future-proof solutions for the issues mentioned above.

[^1]: Which was did not succeed immediately, since I had an error with DEFLATE compressed responses. Turns out you have to run them through the ZlibDecoder instead of the DeflateDecoder which I assumed at first (given the name). So, lesson learned, always test your code 🤗

Using RubaXa Sortable with Ember.js

Thu, 16 Apr 2015 00:00:00 GMT

Sortable by RubaXA is a great library for visually sorting elements in HTML apps. Sadly it has no built-in support for Ember.js, so I thought I would elaborate here how I added it to a client's Ember.js app.

Creating a SortableList component

app/components/sortable-list.js:

import Ember from "ember";
import Sortable from "npm:sortablejs"; // this requires Ember CLI with ember-browserify, which is great!

export default Ember.Component.extend({
  init: function () {
    this._super();

    Ember.assert(
      "required `viewModels` param is set",
      !Ember.isNone(this.get("viewModels")),
    );
  },
  tagName: "ul",
  classNames: ["sortableList"],
  actions: {
    removeItem: function (index) {
      this.sendAction("removeItem", index);
    },
  },
  didInsertElement: function () {
    console.debug("Setup Sortable in didInsertElement");

    let s = Sortable.create(document.getElementById(this.get("elementId")), {
      draggable: ".sortableTopicListItem",
      onSort: (evt) => {
        if (evt.type !== "sort") {
          console.debug("Skipping event that is not sort.");
          return;
        }

        if (evt.oldIndex === evt.newIndex) {
          console.debug(
            "NOOP, evt.oldIndex === evt.newIndex; not sending action; not removing element",
          );
          return;
        }

        console.debug(
          `evt.oldIndex = ${evt.oldIndex} -> evt.newIndex = ${evt.newIndex}`,
        );

        let dragItem = evt.item;
        dragItem.parentNode.removeChild(dragItem);

        this.sendAction("itemMoved", evt.oldIndex, evt.newIndex);
      },
    });

    this.set("Sortable", s); // for later destruction
  },
  willDestroyElement: function () {
    console.debug("destroying Sortable in willDestroyElement");
    this.get("Sortable").destroy();
  },
});

app/templates/components/sortable-list.hbs:

{{#each viewModels as |viewModel index|}}
  <li class="sortableTopicListItem">
    {{viewModel.displayName}}
    <i {{action removeItem index}} class="remove">✖</i>
  </li>
{{/each}}

Using the SortableList component

Showing items with a SortableList is now very easy. All you have to do is supply some viewModels which have displayName property.

{{sortable-list
  viewModels=viewModels
  itemMoved="moveItem"
  removeItem="removeItem"
}}

It get's a little more complicated, when you want to reflect the actions that took place in the DOM in your internal data model.

For this the work the enclosing component has to implement moveItem and removeItem actions where it recreates the changes in it's internal store.

This is the relevant part from one of my enclosing components:

actions: {
  moveItem: function(oldIndex, newIndex) {
    Ember.assert('required `oldIndex` param is set', !Ember.isNone(oldIndex));
    Ember.assert('required `newIndex` param is set', !Ember.isNone(newIndex));

    console.debug(`oldIndex = ${oldIndex} -> newIndex = ${newIndex}`);

    let references = this.get('value'); // Your underlying array

    let movingReference = references.objectAt(oldIndex);

    references.removeAt(oldIndex, 1);
    references.insertAt(newIndex, movingReference);
  },
  removeItem: function(index) {
    Ember.assert('required `index` param is set', !Ember.isNone(index));

    let references = this.get('value');
    references.removeAt(index, 1);
  }
}

I hope this is helpful for everyone looking to solve a similar problem.

Increase Video Playback Speed on Netflix

Wed, 04 Mar 2015 00:00:00 GMT

Like some other people on the internet I was frustrated that I couldn't speed up the playback speed of Netflix videos like I got used to on YouTube.

With this little peace of code one can easily increase the playback speed of the main video:

document.getElementsByTagName('video')[0].playbackRate = 1.2

Turns out it is not as generally useful as increasing podcast playback speeds, though.
While speedier dialogues are great, the unnatural fast body movements at higher speeds distract me a lot.

Waterproof Running Shoes

Tue, 03 Mar 2015 00:00:00 GMT

No more bad-weather-excuses. Get out and run.

Alex Payne on Mindfulness as a Performance Enhancing Tool

Thu, 26 Feb 2015 00:00:00 GMT

why do I want to be better at my job?
who benefits if I’m more productive?
does my labor reduce suffering more than sitting in mindful contemplation?

— from Meditation and Performance by Alex Payne

Image (File) Input Component for Ember.js

Mon, 23 Feb 2015 00:00:00 GMT

In order to enable a great user experience I wanted to show the user's newly selected profile picture in one of our clients web apps right after she choose the desired file in her browser's file picker dialog.

Unfortunately this is not yet as easy as a simple <input type="file" file={{file}}>.

Having found this pure JavaScript implementation of similar behaviour on HTML5 Rocks, I set out to port it to Ember.

Since I was not able to find any recent Ember-compatible code solving this problem, I created my own version using the latest Ember conventions: a component.

app/components/file-input.js:

import Ember from "ember";

export default Ember.TextField.extend({
  type: "file",
  change: function (e) {
    let self = this;

    var inputFiles = e.target.files;
    if (inputFiles.length < 1) {
      return;
    }

    let inputFile = inputFiles[0];

    let fileInfo = {
      name: inputFile.name,
      type: inputFile.type || "n/a",
      size: inputFile.size,
      date: inputFile.lastModifiedDate
        ? inputFile.lastModifiedDate.toLocaleDateString()
        : "n/a",
    };

    var fileReader = new FileReader();

    fileReader.onload = function (e) {
      let fileReader = e.target;
      fileInfo.dataURL = fileReader.result;

      self.sendAction("fileChanged", fileInfo);
    };

    let firstFile = e.target.files[0];
    fileReader.readAsDataURL(firstFile);
  },
});

app/components/image-input.js:

import Ember from "ember";

export default Ember.Component.extend({
  file: null,
  actions: {
    fileSelectionChanged: function (file) {
      this.set("file", file);
    },
  },
});

app/templates/components/image-input.hbs:

<strong>Image Input</strong><br />

{{#if file}}
<img src="{{file.dataURL}}" width="300" />

<ul>
  <li>Name: {{file.name}}</li>
  <li>Type: {{file.type}}</li>
  <li>Size: {{file.size}} bytes</li>
  <li>Last modified: {{file.date}}</li>
</ul>
{{/if}}

<br />

{{ file-input fileChanged="fileSelectionChanged"}}

Now usage is as easy as {{image-input}}!

The result looks like this:

<img src="/assets/posts/ember.js_image-input_component.png" width="314">

Increased Podcast Playback Speeds

Sun, 22 Feb 2015 00:00:00 GMT

Just a quick thanks to Marco Arment for his Smart Speed feature in Overcast.

Smart Speed combined with regular playback speed-ups allows me to easily listen to interview podcasts at speeds greater than 1.5x.

For example I was able to listen to these two parts of the Tim Ferriss Show (2h07m total) and this episode of the James Altucher Show (1h04m) both interviewing Tony Robbins about his new book in the same amount of time than just listening to the former at 1x.

For me personally I can confirm Marco’s assumption, that listening to podcasts faster just makes me listen to more podcasts.

Making HTTP requests beyond the 32MB urlfetch limit on Google App Engine

Thu, 15 Jan 2015 00:00:00 GMT

Since Google App Engine's urlfetch service imposes a 32MB response size limit on each request, one has to roll their own http.Client implementation using appengine/socket to make requests exceeding that limit.

Sadly the appengine/socket implementation is not working with HTTP calls inside the local development server, such that one can not use the same solution and code in development and production.

The two issues made me create the fetchall package, a simple drop-in replacement for urlfetch that gives you a http.Client implementation that handles arbitrarily large HTTP requests (within the time limits of Google App Engine).

When running in the development server, the implementation will simply use Go's net package instead of appengine/socket in order for request to work locally as well as in the cloud.

To use this package simply replace urlfetch.Client with fetchall.Client in your Go code.

GitHub: github.com/tp/fetchall
GoDoc: godoc.org/timm.io/fetchall

Simple App Engine Datastore Entity Versioning With Go

Mon, 20 Oct 2014 00:00:00 GMT

In a recent project we needed the ability to save every version of a User's profile (type UserProfile) in our database, so that we are able track changes over time and restore or review previous versions.

Since there does not seem to be a standard way to do entity versioning with App Engine Datastore entities, I wrote up a quick sample below of how I solved this.

I think there are two basically two way to achieve this whithout data normalization (i.e. storing the latest version in a special place):

Store an ever increasing version number with the entities. Pick the one with the highest version number when querying. Optionally this can be used to only allow successive saves (from version 3 to 4 to 5 etc.).
Store the creation/save date with each entity. Pick the entity with the most recent creation date when querying.

(I won't delve into delta compression here, which may be worth considering if your entities are sufficiently large or change a lot.)

I opted for a solution based on the entity creation time instead of a entity versioning solution that requires successive entities versions since those can be created without reading the previous entities' version number from the datastore.

This also has the benefit that we’re able to restore the state of the whole database for any point in time since all changing entities are tagged with their creation date.

And because writes to a single entity group (in our case the User) are strongly consistend and guaranteed to be executed before the next read of entities in that group, we are always seeing the most recently created UserProfile in our queries.

Implemenation & Tests

main.go

package main

import (
	"fmt"
	"time"

	"appengine"
	"appengine/datastore"
)

const (
	KindUser        = "user"
	KindUserProfile = "userprofile"
)

func main() {}

type CreatedAtStruct struct {
	CreatedAt time.Time
}

func (c *CreatedAtStruct) SetCreatedAt(t time.Time) {
	c.CreatedAt = t
}

type CreationDateSetter interface {
	SetCreatedAt(t time.Time)
}

type User struct{}

type UserProfile struct {
	CreatedAtStruct

	Counter int
}

func putVersioned(c appengine.Context, kind string, parent *datastore.Key, v CreationDateSetter) (*datastore.Key, error) {
	if parent == nil {
		return nil, fmt.Errorf("parent must be set")
	}

	v.SetCreatedAt(time.Now())

	return datastore.Put(c, datastore.NewIncompleteKey(c, kind, parent), v)
}

func getLatest(c appengine.Context, kind string, parent *datastore.Key, v interface{}) error {
	q := datastore.NewQuery(kind).Ancestor(parent).Order("-CreatedAt").Limit(1)

	_, err := q.Run(c).Next(v)

	return err
}

main_test.go

package main

import (
	"testing"

	"appengine/aetest"
	"appengine/datastore"
)

func TestVersionedStorageAfterEachPut(t *testing.T) {
	c, err := aetest.NewContext(nil)
	if err != nil {
		t.Fatal(err)
	}

	userkey, err := datastore.Put(c, datastore.NewIncompleteKey(c, KindUser, nil), &User{})
	if err != nil {
		t.Fatal(err)
	}

	for i := 0; i < 10; i++ {
		p := &UserProfile{Counter: i}
		_, err := putVersioned(c, KindUserProfile, userkey, p)
		if err != nil {
			t.Fatal(err)
		}

		outputProfile := new(UserProfile)
		err = getLatest(c, KindUserProfile, userkey, outputProfile)
		if err != nil {
			t.Fatal(err)
		}

		if outputProfile.Counter != i {
			t.Fatalf("Expected Counter to be %d but it was %d", i, outputProfile.Counter)
		}
	}
}

func TestVersionedStorageAfterAllPuts(t *testing.T) {
	c, err := aetest.NewContext(nil)
	if err != nil {
		t.Fatal(err)
	}

	userkey, err := datastore.Put(c, datastore.NewIncompleteKey(c, KindUser, nil), &User{})
	if err != nil {
		t.Fatal(err)
	}

	upper := 10
	for i := 1; i <= upper; i++ {
		p := &UserProfile{Counter: i}
		_, err := putVersioned(c, KindUserProfile, userkey, p)
		if err != nil {
			t.Fatal(err)
		}
	}

	outputProfile := new(UserProfile)
	err = getLatest(c, KindUserProfile, userkey, outputProfile)
	if err != nil {
		t.Fatal(err)
	}

	if outputProfile.Counter != upper {
		t.Fatalf("Expected Counter to be %d but it was %d", upper, outputProfile.Counter)
	}
}

See Gist on GitHub

Timm Preetz

A touch-screen remote control for Linn Selekt DSM, using Rust on ESP32

Building an Odometer for Playlist Counts in SwiftUI

Custom Odometer

Demo

Source Code

Speeding up batch inserts in SQLite using dynamic statements

File storage in Flutter apps (Part 2)

Storing binary data in Flutter

Local files with pointers from the entities

Storing files separately in the database

Storing the file with the entities

Storing files with metadata

Next steps

Designing repositories for Flutter apps on top of `IndexedEntityStore`

All the data, all the time

On-demand data loading with offline storage

On-demand data (alternative)

Receiving File Drops on macOS (and iOS) with SwiftUI

Starting Point

Adaptation for macOS

Bonus

`usePromise`: A React hook for async data loading with server-side rendering (SSR) support

Thoughts on API design

Closing Thoughts

Rendering a combined list view from multiple list using Flutter's `SliverList`s

The Example

Nested `ListView`s in Flutter

Performance characteristics of nested ListViews

The flattened list approach

SliverLists inside a CustomScrollView

Recap

Making HTTP Requests in Flutter Tests

Page Generator TypeScript Rewrite

TypeScript: `ReturnType` for `async` `function`s

Custom Cursors: Creating CUR Files from Canvas

WebGL: Smooth Edges on Transparent Canvases

Task

Solution

Next Steps

Further Reading

7 Days Without Recreational Media

An Asynchronous Web API in 1994

Sam Harris: Lying

2 Types of Lies

On "White Lies"

Illusory Truth Effect

Rich Hickey: Step Away from the Computer

Fetching Potentially Compressed Webpages That Might Not be UTF-8 Encoded in Rust

Preparation

Implementation

Retrospection

Using RubaXa Sortable with Ember.js

Creating a SortableList component

Using the SortableList component

Increase Video Playback Speed on Netflix

Waterproof Running Shoes

Alex Payne on Mindfulness as a Performance Enhancing Tool

Image (File) Input Component for Ember.js

Increased Podcast Playback Speeds

Making HTTP requests beyond the 32MB urlfetch limit on Google App Engine

Simple App Engine Datastore Entity Versioning With Go

Implemenation & Tests

Custom `Odometer`

Performance characteristics of nested `ListView`s

`SliverList`s inside a `CustomScrollView`