Mindset by Carol Dweck. I feel that I'm stuck in a fixed mindset in some areas, so I want to explore ways of dealing with that.
779 karma · joined July 16, 2009
I try to download the Photos data regularly via their takeout tool, but the process is cumbersome. I wish there was an automated way of doing that. I'd even pay for that.
I moved from Gmail to Fastmail, but I still haven't found a good replacement for Google Photos.
2. Yes, and also grids and Google's Material Design. The MD spec is the most coherent document on a design language I have ever read. While it's not necessary to follow it to the letter, studying it would be definitely helpful.
3. Figma is better (and free for a single user).
Matterlist's recurring task descriptors ("Schedule Items") essentialy define infinite sequences of recurring events, which are not represented in the database, but are visible and editable via the same UI, just as the regular, non-recurring tasks.
Here's how we deal with the problems you outlined:
1) When a user deletes a specific instance, we create an "exclusion" record for that day, so that the function that generates an endless sequence of recurrences doesn't generate one for that day.
2) When a user edits a specific instance of a recurring task, we also create an "exclusion" record for that day (because otherwise we would have two tasks on that day, the edited instance, now with a database record, and the virtual instance), and we create a database record for the edited instance, so it just becomes a regular task.
3) We don't have shared tasks yet, but that would be handled via the same framework, as outlined in 1 and 2 above. We'd just de-virtualize an instance and add/remove users to it.
Creating a database entry for each instance of a recurring task was unacceptable for us, because we wanted infinite forward visibility, and because when a user edits the parameters of a recurring task (e.g. changes it from daily to weekly), we'd have to delete all the old records and create the new records.
BTW, we have finally released an Android app, so you can see our recurring tasks in action: https://matterlist.com/#apps
For example, I need multiple spaces where each space is "dedicated" to a single Google account -- it has multiple tabs open that are logged into that particular Google account.
I tried to create that setup, but the accounts "leak" between spaces: logging into a Google account in one space doesn't allow tabs in other spaces to be logged into a different Google account.
If you ever implement proper account isolation per space, please notify me: I'd like to be a beta tester.
This is oddly comforting. As Tim Ferris said in Tools of Titans, every successful person is dysfunctional in some way. I guess the trick is to work around your own personal deficiensies, and that's something everyone must figure out on their own.
This absolutely works for me when I'm writing technical specs. Leaving some trivial bits for the next day helps to start it off faster.
Here's a good picture that highlights the differences: https://en.wikipedia.org/wiki/File:Homology.jpg
However, there's a synergy between their on-chip ML cores and their raytracing engine: they use ML cores (which are typically useless in graphic workloads) to de-noise ray-traced images.
Not yet. However, this is something I'd absolutely like to see implemented, including for my own personal use. Alternatively, we could use optional LastPass-style encryption based on a master password for task texts, which should be easier to implement (though it will restrict search by task text to client-only).
> How come it is so expensive?
We'll need to be self-sustained for the long term. The app is 100% bootstrapped and there will be no external funding. Plus, a to-do app just cannot afford to be unsustainable, because its closure will hurt a lot of its users. So we'd prefer to scare off some part of our potential user base, but in exchange gain better financial stability and thus longevity.
Also, it may be just me, but the app, as it currently is, with all its rough corners, provides much more value (at least by a couple of orders of magnitude) to me than it's planned monthly cost.
> Also, you state "Try our native apps now! It's free!". I would, but apparently it's "coming soon"
Sorry for that. We haven't publicly announced the app yet, but the site is written and designed as if the app is already available for download, hehce the mismatch.
Evernote (https://evernote.com) - a store-and-forget tool for information of any kind that I might need at some point.
Matterlist (https://matterlist.com) - to-do lists, recurring tasks, calendar. (Full disclosure: it's my own Wunderlist alternative, currently in alpha testing.)
No working hours at all. Full vacation mode. No direction, no purpose, no obligations.
Someone else may do that for you. Example: revenge porn. Here's a relevant experiment:
The key was to get off the grid, shed all responsibilities, take long walks in the woods, avoid dopamine loops, and let my mind wander without purpose.
Here's how the assertion of commutativity would look in F*:
val f : int -> int -> Tot int
let f a b = a + b
let commutative = assert (forall a b. f a b = f b a )One of my teams is currently using a mesh colorization system for our game, which we developed in-house. E.g. we have a game level where each mesh is assigned some color ID, such as "primary accent" or "background1" (but not an actual RGB color); and there are color schemes which we can apply to the level according to these color IDs to get different looks.
The first version of the color scheme system was "clearly superior": it offered a lot more possibilities for assigning color schemes to meshes, but it needed about 80 color values for each color scheme.
The second version of the same system was "clearly inferior" -- just 28 color values, and much less creative control over the resulting look of the level.
Guess which system was adopted? Right, the second, simple one. Despite offering less creative possibilities, the second system was smaller and thus could fit more easily into artists's heads, which produced better-looking results overall.
To sum up, "superior" is multidimensional. Dvorak can offer better typing speed, but it offers much less "habit compatibility" with existing keyboards in the real world, and thus is a worse time investment. Or, Haskell offers much better maintainability, refactorability and reliability, but dynamic languages offer faster time-to-market and easier-to-hire coders.