I’ve tried many e-readers since early Kindle but I keep coming back to two fundamental problems with e-ink, both relevant to education.
First, extremely cumbersome and error-prone to type compared to swipe-typing on a soft keyboard. Even highlighting a few sentences can be problematic when spanning across a page boundary.
Second, navigation is also painful compared to a physical book. When reading non-fiction, it’s vital to be able to jump around quickly, backtrack, and cross-reference material. Amazon has done some good work on the UX for this, but nothing is as simple as flipping through a physical book.
Android e-readers are better insofar as open to third-party software, but still have the same hardware shortcomings.
My compromise has been to settle on medium-sized (~Kindle or iPad Mini size) tablets and treat them just as an e-reader. (Similar to the “kale phone” concept ie minimal software installed on it … no distractions.) They are much more responsive, hence fairly easy to navigate and type on.
The current top HN post is for moltbook.com seven hours ago, this present thread being just below it and posted two hours hence
We conclude this week has been a prosperous one for domain name registrars (even if we set aside all the new domains that Clawdbot/Moltbot/OpenClaw has registered autonomously).
This is a little more of what I was expecting with AI work if I'm gonna be honest. Stuff spins out faster than people can even process it in their brains.
Very cool idea since ffmpeg is one of those tools that has a few common tasks but most users would need to look up the syntax every time to implement them (or make an alias). In line with the ease of use motivation, you might consider supporting tab completion.
Correct. Fortunately a number of streaming services are available in many regions nowadays, e.g., Netflix, Apple TV, Disney, HBO Max or whatever it’s called now.
The content may vary between regions though, e.g., you open Netflix in another country and no longer see a show you’re watching while see other ones appear. This can sometimes feel like a feature more than a bug.
Yes and combine with a travel router so you don’t have to endure logging into a wifi portal with a soft keyboard on the TV, if the stick OS even allows it. Then having to repeat the process daily due to expiration times, or as soon as you remove the key card from the hotel room slot, causing the router to power down and the TV stick to time out.
Top tip, if you're in a hotel room you can often put any card like item (e.g. loyalty card) into the slot and it still works.
This works at a lot of chain hotels. Not every hotel, but a lot of them. In the UK this works in most Premier Inns and Travelodges, doesn't work in Point A hotels from experience.
Alternatively ask for two or more cards at the desk.
If the room is cleaned daily the cleaners have a tendency to remove them though. The chain hotels only tend to clean if you ask though, or on a certain few days after check-in.
Helps if you want to keep the air con on or devices powered up.
A major advantage of pure models is testability. If your conception of a "model" is perversely a user-facing widget, congratulations, you'll need to write UI tests that simulate button presses and other such user actions, and maybe even inspecting pixels to check resulting state. Tests like that are a pain to compose and are fragile since the UI tends to evolve quickly and may also be vulnerable to A-B experiments. Juice ain't worth the squeeze in most cases.
In contrast, pure model components tend to evolve slowly, which justifies the investment of a comprehensive test suite which verifies things like data constraints, business logic, persistence. If automated testing were seen as a priority, this would be a no-brainer for any serious app. However, testing tends to be underappreciated in app development. This goes some way to explaining why frameworks carelessly fold in M, V, C to the same component.
Yes to all of this with the provisos that a) there’s enough meat in terms of business logic and validation to justify the indirection of a separate object and b) you’re under a language or CI regime that can validate the boundary between the two classes for basic flubs like function misnames or bad arguments.
Testing by "simulating" button presses and other actions like that, including inspecting pixels, is part of so-called "black-box" testing, and offers merit(s) of its own. At least because software is used by people who click buttons which may modify pixels, and these people are not concerned what your model is, they don't even know anything about the way you may have implemented the latter. In the end everything is run on a fairly RISC-y CPU, it either works or it doesn't (from user's perspective) -- replicating the user's workflow is useful in that it it uncovers issues that matter to users and thus normally affect your bottomline.
I don't think people called it a "model" but back in Windows VisualBasic/Delphi/C++Builder days the path of least resistance was to set up your GUI in a visual editor by laying out all your widgets in the window. Classically Qt can also be used this way. So you have this UI, you can launch the application and the UI displays and basically works, but none of the buttons do anything. But all the widgets have a great API that you can use to set permissible value ranges, set and query state, etc. And the widgets would fire events when things changed. In other words, the widget contains a model, and implements the Observer design pattern.
If you wanted to implement MVC with a separate application data model you had to do work to set up a separate model, and keep it in sync with the UI. None of this class of old tools provided any built-in assistance for defining models separate from Widgets, except for some support for binding UI to database queries/results. Of course this was separate from the Smalltalk world, where there were frameworks for building up models out of pre-defined model "atoms" such as an observable number model that you could bind to various views.
This is especially true for sleep since we can be pretty good at incorporating external sounds into our dreams. It's been shown in controlled experiments. Seems likely that certain noises are generically easier to integrate into dreams than other noises, which could just cause you to wake up or have your sleep otherwise impaired.
I wish someone could solve the problem at the receiver end, i.e., invent noise-cancelling headphones/earplugs that actually cancel noise as effectively as eye-masks cancel light.
In addition to sleep needs, the world has gotten noisier now that people are habitually using speakerphones in public in the most obnoxious ways.
Gets you some pretty good quiet for sleep. It's not active noise cancelling, but they work pretty well.
Anecdotally if you wear a pair of westone solids, and then a pair of earmuffs on top of that, you are basically just hearing through your bones, which can't be avoided (with passive or active).
First, extremely cumbersome and error-prone to type compared to swipe-typing on a soft keyboard. Even highlighting a few sentences can be problematic when spanning across a page boundary.
Second, navigation is also painful compared to a physical book. When reading non-fiction, it’s vital to be able to jump around quickly, backtrack, and cross-reference material. Amazon has done some good work on the UX for this, but nothing is as simple as flipping through a physical book.
Android e-readers are better insofar as open to third-party software, but still have the same hardware shortcomings.
My compromise has been to settle on medium-sized (~Kindle or iPad Mini size) tablets and treat them just as an e-reader. (Similar to the “kale phone” concept ie minimal software installed on it … no distractions.) They are much more responsive, hence fairly easy to navigate and type on.
reply