last week | last month | last year | all entries
There are three real ways to drill down into them:
This Google Calendar settings menu that I have open is wonderful; it's document-style with a table of contents, and all of the settings have beautiful visual metaphors to help you understand how to navigate the page.
The Apple menu? Not so great, especially because they try to 'own' technical language and obscure actual features, like saying 'pro display' instead of 120hz or similar. This creates Apple tribalism and helps some die-hard fans feel more integrated - but choosing different names for products and settings from the colloquial standard basically alienates any casual user - which, IMO, is bad for a product like a MacBook that should be a tool usable by everyone. I don't want to have to look up what an 'epic pro max XDR ultra' is - just use the language everyone else does. Please!
Major shoutout to the browser company shader this morning. When you first open the app, the full-screen blob and intro animation with music is so, so beautiful - maybe the best animation I've seen from software in a long time. That intro sequence is immaculate. I'm blown away by the work that these teams are doing on MacOS native apps. Developing those tools to be mac-native is feeling awfully tempting... wondering how easy it would be to port beautiful animated features like this back to Linux and wayland.
Using this Mac has helped me develop a new appreciation for my Linux setup though. All of the animations are beautiful and expressive on MacOS, sure, but my minimal Sway setup feels cold and efficient. Everything happens pretty much instantly without 'affordances' or motion blur or 120fps animations - it 'just works'. The machine feels functional, efficient, and responsive. I would love to build more beautiful apps that feed into this 'feel' while taking some of the innovative visual cues from programs like MacOS. ** 10:16 Writing and recording these daily notes is probably - for better or worse - the highlight of my day. This is great practice. Keep noticing details and working on it! ** 11:10 Made another classic prioritization mistake today. Always make the minimum viable changes necessary to release a usable product for other people. I prioritized doing more 'in-depth' work before preparing a deployment of our product at work. Be more careful next time - propose a minimum viable plan, finish that plan, and iterate, adding more if we need. Do not do more up front than is necessary.
These devices shouldn't be limited to controlling audio; they might be able to channel into some intermediary that can automate, send visual feedback back to the controller, and so on... a device could control a visual and a synthesizer at the same time, displaying art that reacts live to tactile knobs... the ability to touch something and for that thing to give visual and vibrational feedback is so, so important. Musicians know that how a tool feels changes how you think. Everyone should have the power to plug in new tools and change the way they think about problems.
Keyboard artisans know this too, in a different way; they 'optimize' or make pretty keyboards, play with knobs and ideas, itching to find this new input device of the future - or the one that works best for them. It's silly to me that this laptop has one keyboard and screen glued to it that can't be changed. Having good defaults is good - sure - so that the system can always be interacted with, but I should be able to swap these things out and keep the brain behind them. A 'complete' device that can't be customized or plugged into other things feels terrible. Same with battery power. All of these TE devices have built-in microphones, batteries, etc, each with different abilities and qualities, then they promote the idea of putting all of these tools together. They seem fixated on beauty and size at the cost of functionality - I cannot DJ or record with their TP-7 because the disk is too small and the microphone is so poor - but that beautiful brushless motor and notch on the side provide such seamless tangible and visual feedback, acting as the world's most polished tape deck. The knobs on their mixer are far too small - and that mixer has no business hosting expressive audio effects - but it works and works well.
To me, the failures of these physical audio devices are more interesting - like the OP-Z. The thing doesn't have a good way to provide visual feedback for most of its controls and its labels are too domain-specific for how general the device is meant to be. The thing has no screen! A sequencer needs lights under the buttons to show you when they're triggered. A disc needs lights or a screen to show you how that pot is tweaking your system on the fly. This visual feedback has to be built into the controller itself in some way. The Elektron model:cycles looks and feels like a toy, but the rubbery feel of those buttons - the way they light up - and the screen's waves shifting and responding to your changes to the sequencer - are brilliant design decisions for such a budget device. The mouse shows a cursor. Keys show text on the screen. Controls on any sort of device should do the same - or htey're confusing and do nothing. Audio feedback is not enough.
All of these grooveboxes work because they feature software tightly integrated with hardware - and the developers behind them do a brilliant job - but ultimately my laptop is a far more powerful and expressive piece of kit than dedicated 'hardware' (implemented in software as custom firmware). Limits like 24 samples, 256 tracks, whatever - what? My laptop has 16 gigs of RAM and a terabyte of storage. It can probably run the software of every sampler or 'groovebox' on the market combined and look better doing it. ** 11:52 Someday I'll make the clothes that I want to wear every day. Right now I'm focused on computer interaction. Income doesn't feel as stable and developing clothes seems like it costs big bucks - especially clothes without compromises. I have a whole life ahead of me to do that. ** 14:18 Incredibly frustrating that most high-quality hardware products have software built-in. Music tools are no different from SaaS platforms in this way - it's nearly impossible to purchase great hardware pots, knobs, and other buttons without them including some mediocre hardware in the box and gluing the tool to it. I understand wanting to control the complete experience, and that stepping away from a laptop is somehow an obsessive selling point for many people, but controllers should be just that - instruments that connect to powerful programs that run on your computer. Those distractions you have in your laptop are a software problem, not a hardware one that can be fixed with more money and more modulars; the bigger problem is that you do not have control over your computer and the ways in which the software should interact.
I want more companies like Monome that ship beautiful, high-quality, modular tools. Thankfully NI controllers can be hacked, and they have decent hardware, but that's not the point - we deserve better tactile tools for human-computer interaction that don't have to be the complete package. TE takes one step towards making no-compromise, beautiful products, but they aren't substantive or modular in the most important ways. The missing piece of this puzzle to empowering hardware is free software - we need to get there as well. ** 17:28 WebGPU is good, but starting a framework by implementing the GPU rendering is bad because this introduces a barrier to entry.
Using this macbook feels so clean and seamless though. Everyone deserves high-quality basic tools like this. I'm noticing that programs aren't as expressive for developers as the MacOS defaults, though. I am determined to make compelling, developer-oriented software that everyone can use - that can be ported back to MacOS with no issues.
Less configuration is better. Pick beautiful defaults and they'll be used. (Gnome doesn't have the best...)
Also realizing how important it is to be able to move a window around, to resize it and see how the website reacts, vertically and horizontally, on many different screen sizes. Getting some new insights for my website - like how important a responsive sidebar is. ** 19:51 One of the most beautiful things that anyone can do is make a tool that helps people express themselves - especially in a way they weren't able to before
AmanecΓ y llegamos a la tarde con alegrΓa con [[AG]], y despuΓ©s comimos y caminamos con [[Diego]] y [[Dominic]].
Clojure really isn't useful here though. Fun but bad decision. JVM has slow start and doesn't really matter - we don't need to run cross-platform and the libraries we would use for that are implemented in many other languages. Should have used javascript - code would have run much faster. Clojure lost because it wasn't useful on the web.
Also, the stack traces are terrible... (I can't see any sort of program trace within my code? No syntax highlighting? What's up with that?). I'll wrap this project up but I'm feeling a strong rewrite it inclination. ** 13:45 Depending on a file means a few things things:
Solution:
This means that if you depend on any file, you'll have the information about what you need to make your current component run at any time. You'll know what you have to build in order to make that component work. References to that component will have a real, semantic connection to the component itself.
This also allows the file to be interpreted in different ways! I can assemble a list of imports dynamically, then use an interpreter to resolve them. I can use a compiler to set up everything statically. I can make 'meta-components' that transform other components to augment them in clear ways. Good solution. ** 14:01 Watched some tiktoks (reels lol) this morning. Really clever tricks with the soundtrack - some reels through subtle discord, snapchat, iMessage, etc... sounds on in the background to stimulate attention. Really devious strategy. I'm kind of afraid of watching these things now. ** 14:41 For the site - need a way to figure out remote dependencies! Both at access time and at build time. These are network requests. (:type network? :type https? something like that.)
(Live dependencies would be really cool...) ** 19:46
https://www.youtube.com/watch?v=Xa_fNuaSE_I: A good test for cross-platform software - would a top company rely on that software to build beautiful products? React Native, Flutter, QT, Xamarin...
The answer is no because there are so many stopgaps and edge cases between platfomrs that have to be healed over. That cross-platform challenge is so incredibly difficult. The APIs are just too high-level to build technology that interoperates! ** 20:28 No GC is necessary for fluid UI. A single GC pause in the wrong place can kill a fluid animation. This is why Apple is behind Swift - and why Swift apps feel so much more fluid than other web tools, even Java - Swift apps have fine-grained control over their memory, which allows them to make UI animations feel incredibly polished. Brilliant!
My site is becoming more and more 'reflective' though. The more I iterate on it, the better the features tend to 'flow together'; I have a bunch of ideas that seem unrelated, but over the course of a couple of days they combine to reveal some super powerful primitives, and those primitives can hten be used throughout the application to make the framework both faster and more expressive. Clojure's "for" laziness bit me today - but I can see laziness being super useful, like to retrieve git log information or to get information about files that are supposed to be dependent on one another. I'll see where that takes me. ** 18:14 The bit of isolation I hear feels lonely, but it's been really valuable; I'm very quickly finding an understanding of what I want to do with my life and how I want to go about it. I want ot make, to build creative tools, to make using a computer better; I want those tools to be freely available to anyone and for them to be the best tools available, so there is no decision between paying Adobe or Capture One or whoever else is adding artificial scarcity to limited commodities; I want to build tools that people both admire as objects and that can be used every day.
Progress isn't made with good work, not entirely; it's assembled between people making connections in the real world. Balue Coffee's pop-up was wonderful; he was so welcoming, the coffee was so good, and the community of people that Justin (?) seems to have fostered is beautiful. Some poeple drove or flew out from fairly far out to spend time hanging out in a parking lot to support this business; to support him. I love doing this for others, but am not sure how to foster a community quite like he has. Life could be so, so rich. Maybe San Francisco or New York would help; maybe I can change myself to foster such a community here.
[[Read]]: [[The Entropy of Capitalism]]
[[Watched]]: [[Vesna Manojlovic - The Environmental Impact of Internet: Urgency, De-Growth, Rebellion]]
Client-side and server-side rendering are both necessary to make the best websites.
The most important role of a website is to communicate and present data in the best way possible. The best tool is often a static document; this allows you to communicate information that doesn't frequently change to a user.
The ability to take a snapshot - to download a single HTML file and have access to all of the information you'd like to see - allows users to save web documents for themselves and access them whenever they'd like. It's really important for websites to provide static data with the lowest lift possible. This allows snapshot tools to perfectly capture their state, giving the users of a website the ability to communicate data online or offline.
What if that information frequently changes, though?
I've written before about the 'three stages' of information on the web. Information can be retrieved at three times: at site deployment time (the developer deploying the site to a server), at user access time (when the user requests to see the information from the server by clicking a link), and at runtime (updating data while the user is viewing a page).
We know the user wants the most up-to-date information, but each stage comes with a performance penalty; delivering information at access time and runtime can introduce significant lag if not approached properly, as the live data has to be retrieved.
We can load data in 'after the fact' by having the browser request live data again after a page loads. This is a super common React strategy, and improves load times for the user - but means that the page served to the user initially is often kind of useless (it has none of the relevant data until a user spends some time on it!), preventing any sort of archival tool from properly preserving the site at a point in time.
This also may be irresponsible - do I want to render the data on my one computer or on the computers of every single one of my visitors? One clearly is much more expensive. We need to give users the most relevant live data though!
When considering how a platform is built, strive to store all information at site deployment time. If information might change between user access times, that data will have to be dynamically retrieved. If information might change when a user accesses the page, the data will have to be dynamically rendered by a client.
This also calls for three different ways of rendering a website. The first stage is supported by a compiler from source files to target files. The second stage is supported by a service that pulls in live data, sticks that data into a compiler pipeline, and sends the output over the wire. The third uses JavaScript to continuously request and render data from the user's computer.
Because rendering information at different times has these tradeoffs, switching between different rendering strategies for particular portions of the website should be as easy as possible. If I want my data to render statically but update live, I will have to render that data in two places - on the server and on the computer of the user. I will also need to obtain that data in both of those places - ideally from the same source.
How do we solve this?
Cool. The UI development language has to either be javascript or support javascript.
What about alternative rendering strategies? What if I want my app to render easily on desktop and web?
If we want to draw with pixels, we can 'sideload' rendering on the web in with the HTML canvas. This would allow users to program in their language of choice. This also sacrifices all of the tools that the web browser provides and prevents static rendering entirely (it is not possible to draw a canvas statically).
If we want to draw with the GPU instead of just putting pixels on the screen, a presumably faster strategy, we can program against the WebGPU API on both the web and the desktop - but again we lose all of those advantages of HTML on the web.
Cool, maybe we can bring the web to us. Let's wrap our app in a web browser and have users download our application code, then tell the browser to render that.
Some problems:
Because our documents are glued to the browser - the most expressive document viewer ever - everyone expects their applications to be accessible there, too. Links are really powerful. Requiring a user to download software to try it out simply is not a good option nowadays.
This is why comprehensive rendering solutions are so difficult. There are two APIs we have to glue into if we want both fast and browser-optimal code to be available everywhere, both with very large surface areas.
We have two paths to move forward:
Things that are not up for discussion:
All I'm saying is that reinventing the wheel is looking really good right now...
Why can't we just target HTML/CSS with business logic in JS / WebAssembly?
We always want accessibility hints, and we always want debuggability - a document flow is ideal for those. A lot of the time, though, the web presents problems to us. The DOM cannot render pixel-perfect documents without the canvas.
Google Docs moved to render entirely with canvas recently, and though they didn't state why, I have some suspicions:
The docs team also added a feature to support static web rendering via the DOM. This allows those live, view-only previews and snapshots to be taken, efficiently rendering a static site that is served to others without the issues discussed. Unfortunately, they have to write all of the same code twice - one for the static doc that's distributed to others and another for canvas editing version.
Thankfully, the canvas doesn't sacrifice all of the browser tools - its api does offer some accessibility tags and primitives: https://pauljadam.com/demos/canvas.html.
This means that if we want to give application developers expressive and fast tools, we cannot rely on DOM rendering to support every use case. There must be a seamless way for them to fall back to pixels. The canvas API, I'd argue, is not seamless - those accessibility hints and tools cannot be rendered statically in documents, for one (unless you count images and SVGs - but then you sacrifice the interactivity that makes HTML docs so brilliant to an opaque image).
The conclusion here is basically that we need to be able to develop custom, pixel-perfect tools within the canvas that the browser will render statically to a document, but that can be interactive when that document is open. I haven't explored why static HTML - rather than JS augmented HTML - is important, but mostly because JS is a mess and is too expressive for what we want it for most of the time. Documents should be usable without executing a general purpose programming language - users should never have to incur that performance hit.
I'll have to rewrite this whole article when formalizing it.
are.na... hundreds - maybe thousands - of people see what I curate on the platform, but
** 23:28
Nah... getting more exposure always seems good. I've put so much effort into the site - and am so glad that Tommy loves my web design. : )Almost-quote of a language: "Developing a language could be just like discovering a game. A game is designed to teach you how to play it - to discover new tips and tricks without realizing that the system is teaching you how to progress. The process of using a language - from the starting process, the error messages, and so on - should be designed like a game, to inform the user to navigate the language and teach them features."
All computer programs are the same; a program is a tool that a user has to learn. Choosing the right way to help your users is vital to helping your users understand how to use your program.
Do I provide a manpage? A --help flag? Good error messages? A website with a great search bar? An interactive tutorial? A supportive Discord community? How do I determine what the best way is to teach my users to use my software?
Today I've also been testing out the Helix editor, software that claims to be a modern replacement from neovim. The program claims to be a complete rewrite, but effectively rewrites and compiles in expressive neovim packages and configurations to produce the best source code editing experience out of the box. The best aspecf of this is the help menu, though - as soon as I started typing and saw a keybind that I didn't expect, I was (1) shown a menu of all possible keyboard shortcuts, and (2) shown an English explanation of my action in a pop-up. I felt encouraged to play - trying more keyboard shortcuts helped me understand more about the system! - and it was incredibly easy to find tools like the file browser and to start using the modal editing features. It's still a bit confusing to open the program to an empty buffer - but their onboarding experience is doing a lot of things right.
At work, a principle design focus is killing any sort of product tour. We include one as a crutch - it allows us to explain features we're quickly adding support for to the platform because we're building a product without clear competitors or comparators - but making UX feel seamless - teaching the user to use the product as they explore - is our primary focus. Presenting information-dense views with affordances to attract the eyes to particular aspects of the interface encourages the user to look at - and interact with - parts of the screen, and in doing so, I hope they learn. ** 13:40 Test for my website's sidebar hierarchy:
home ββ΄pages ββ΄c ββ΄c-style ββ΄ helpers ββ΄making-c ββ΄journals ββ΄2020-10-10 ββ΄2020-10-05 ββ΄files
and questions:
Some pros:
ascii art. It's a wonderful pattern to reuse.Thoughts on the framework so far:
Goal 0: A great framework for building desktop applications.
Goal 1: The best made GUI Linux desktop applications for everyday business applications. Text editor, calendar, email, and so forth.
Goal 2: An everyday software suite that users of Apple devices are compelled to use instead. Apple is a direct competitor. Our tools are more seamlessly interoperable, open source, more consistent, and just as beautiful. You want your computer to feel like our system. No data moats - but we seamlessly wrap and distribute beautiful free software services.
Goal 3: A toolkit for any user to develop ** 13:24 nushell: when creating the signature struct for a command, if the command is 'main', replace 'main' with the name of the file
(Later/harder: if i write a bunch of commands with the same name as the file i'm writing them in - i.e. 'hey $cmd' in the file 'hey' - the command to execute hey $cmd should be hey $cmd, not hey hey $cmd)
also, if 'help @' command fails, try to execute @ --help to see what happens?
Nix is getting better and better. This new Emacs interface - running on Wayland and natively compiled - feels so, so fast compared to earlier today. Glad I rebuilt.
Nushell is the easiest tool I've ever used to write comprehensive shell scripts. I'm incredibly impressed - casual-looking comments fit the 'vibe' of an ad-hoc script but they're instantly used as documentation for their associated commands. Crazy! Check jakeisnt/nixcfg on github at today's date - the hey command was rewritten from an 85mb clojure bundle to a 'free' (because we're already using nushell) shell script that's a third of the number of lines of code and far, far easier to understand - while preserving the same kinds of type information that clojure was (just under the hood). JT and the rest of the nushell crowd are brilliant creators of user interfaces.
Can't wait to see how I can get interactive polling commands working and similar - would love to make reactive tables.
Zig feels just as modern. Still sort of undecided on the Rust vs. Zig spectrum, but I've gotten quite tired with the typed baggage of Rust while Zig lets me goof off and do more or less whatever I'd like (for good or bad). My flipbook project is definitely rendering a raw pointer instead of the buffer that it's supposed to right now, but we'll figure it out.
Blown away by the comptime feature and how dynamic it feels. I've never been able to create a data structure on the fly before and use it in normal code with a strongly typed language such as this - but comptime feels magical, automatically shifting 'meta' code to the compile time step to interpret normal Zig code and bake in the results. I've used it to create rendering engine that uses a fixed-size buffer - without any heap allocations! The buffer struct definition is inlined (? i think) up front at compile time so that the instantiation can be so seamless.
I'm lacking the proper programming language words to describe this, but I also love the build system and how seamlessly I can integrate with C code - a process that's quite difficult for C <-> Rust, javascript <-> typescript, etc... both systems that claim to be easy to do but that, in practice, require modifying the build system of your project and introducing typed headers (which can be real or fake).
Zig builds Clang into its own compiler and simply has all of the information from the C headers and their types available, and has a memory model that maps cleanly to the same LLVM types that clang's C code uses. Brilliant. I don't have to learn Bazel's Python dialect after all - I can just get to work.
Wondering if Rust or Zig with hot reloading would be possible. Zig's anytype annotation is lovely - letting you wing it with systems code and test solutions fast - but not sure how well systems like that scale. Rust is slow with binaries that are too big - Trying to get my launch program - a simple egui app - to work on my computer was a disgusting mess when having to build from source. We'll stick to Zig and stick to boring libraries that can be dynamically linked (when necessary) or my own code (when possible) to make transpilation from scratch a fast process for as long as we can. Fast compile times are so, so wonderful for creating and distributing software. No messing around with caches or storage. You can send someone the source code and they can change it and compile their own tool. Simply brilliant.
** 23:33
Software keeps getting better and better, but only as a result of the significant amount of effort put behind making open-source software faster and more useful for the prople on the other side of the screen. Incredibly reassuring to see great projects succeed and to feel my computer become faster and use resources with greater optimality.
Hurts me how slow darktable is. I'm not sure why it's that way but I want it to be faster. that tool is the weakest link of my graphics programs and I'd love a replacement - or for the developers of that software to make it better and faster and more beautiful. The code runs and works for sure, but does not look great - and you can feel that pain as an end user. The external interface and feel of software closely mirrors the structure of the code and the organization of the team behind it.
Just opened my web browser. Half the websites I open feel like software going backwards. Feels like web software gets slower no matter how fast my computer is. Upsetting.
Back at ilcaffe drottninggatan. Great place to work.
This puts Our Legacy's lyocell experiments out of the picture. Unsustainability aside, the fabrics so quickly stretch and reform and are so so fragile - I don't want to have something else to take care of. Linen is a beautiful fabric for sheets - and feels great as a garment - but doesn't look like it's robust. I don't want something I wear to tear and fall apart as I live daily life.
Clothing that wears texturally without losing color also seems important. Denim wear is visible in the dye; as the cotton stretches, color is lost in some places and gained in others. In the meantime, the clothes are absurdly uncomfortable. 'Futuristic' fabrics, by contrast, stretch and contract and scratch - and these blemishes are visible in the texture of the items but not in the color. Paint and stains show, sure - but those are added, not removed from the garment.
Also loving neutral and deep blues. Beige is great for sheets but doesn't feel like it fits me - something to do with my skin tone. Warm blues match the eyes. AFFXWRKS work is brilliant - futuristic workwear. A bit too colorful and too Prada-infused to like most of the items - but some of the pants are masterpieces. They nail the workwear pant construction but use futuristic-feeling breathable, robust fabric. More of that please. ** 16:53 How do I know whether other people are open to being reached out to? How do I reach out to them?
This is easy in New York or Italy or Portland or Seattle or Boston - it was so easy to approach people and ask questions about them, their outfit, what they were up to, and so on... but here people feel far more reserved and the language barrier is difficult.
Conclusions:
Other thoughts:
Yesterday I submitted my final output for [[YXM830]]!
Reading [[Capital is Dead]] (again, didn't finish last time) and loving it. I really like [[McKenzie Wark]]'s writing style in this. I'm finding the argument about there now being an information-based [[Vectoralism]] - something even worse than capitalism - quite compelling, though I know many disagree.
Used the borrowed orbital sander to sand down garden table and chairs that are a bit weather beaten.
We're starting with SDL2.
Why?
We need a library to manage window manager events to write code that runs on multiple platforms. Our two options here are GLFW and SDL2. (Other options are immature. Rolling our own is a waste of time and impossible to keep up with.)
For simplicity's sake, we also want to be able to access the framebuffer and all of its information. GLFW makes the assumption that you will be passing its framebuffer directly to a supplementary graphics library for you that will query information such as window dimensions. GPU drivers and APIs are a proprietary mess, so we will not be using them. SDL2 gives us all of the information we need about the window we open. Hell yeah!
Later, we might want to underpin the interfaces that are developed for software rendering with GPU code for performance. This will not happen unless there is a significant performance bottleneck. For now, we'll use SDL2's framebuffer to handle everything. ** 21:16 I've been waffling around minimal computing for awhile now - and now I've got it. Largely inspired by ideas from 100 rabbits - https://100r.co/site/uxn.html - but considering that their approach butts heads with everything I know about programming language and user interface design, I couldn't entirely buy in. I wanted to learn more first.
We're starting with a simple Zig experiment - render an 8x8 grid of pixels with a moving animation. From here, we'll explore fonts,
Small teams building in this space are then contractually required to build those features - they have to reproduce the work of a major player, but with much less time and with many fewer resources. Because everyone who operates in the space sees a clear target - 'we have to build from zero to Lyft' - they think they can do all of that and improve on the platform UX and customers expect that of them.
Companies in this space have to learn to disappoint in some ways, compromising on feature set instead of functional quality. The social problems that get them into the space to begin with - maintaining the bikes or scooters, improving the relationship the company has with the people who maintain the vehicles, and ensuring that all of the items are in good condition - are far more important than the technical issues that have to be solved. I'd advocate for eschewing the map at first - the app can open the default map app on the mobile device - in favor of focusing on perfecting all of the non-technical tools and ensuring that my small featureset works. Companies in this space reach for the technical issues - those seem easy to solve and measurable - but this is precisely why they shouldn't focus on them. Because these goals are so tangible, accomplishing them does not solve new problems; it just makes the companies less differentiable, in doing so both sacrificing vehicle operating quality and losing any sort of identity to begin with.
Sponsored by the failure of the Stockholm E-bike service. ** 14:19 Corporate identity merchandise
Do not require it. People have the right to choose their own clothing and express themselves the way they want - especially as employees of your company. The strength of a company is not in operating as an island; rather, it's in ** 16:58 Dad called a few hours ago. My grandfather died last night.
What business do I have being so far away from home? What does being here do for me? What does being here do for the people I care about?
I can't come up with a good enough answer.
Lunch today was spent discussing the merits of sustainability of company merchandise. I regret even contributing to the discussion and prolonging the meeting. I'd never use a t-shirt but ultimately the t-shirts don't matter. I wish I could have redirected that hour of life to helping reduce climate emissions. Be more judicious about what you invest your time and energy into. The time you have really matters.
What's the point of life if your time isn't spent caring about the people you love? In a perfect world, your work should care for them just as much as your time does.
I didn't know what questions to ask my grandfather - about growing up in Chicago as a Swedish immigrant, about how he met and felt about my grandfather, about their beautiful cabin in Wisconsin, about train engineering, about his life growing up - and I'm ashamed that I didn't try before this January - which was far too late. I'll never get back a second of the time I spent playing with fucking trading cards instead of doing things with family. I have no idea what game I was playing at the time or what activity I was doing on my DS or the family iPad or whatever the hell I was up to when at their Boise house. I can't remember that time at all, but I can absolutely remember not spending more time with them, learning about or learning from them.
I realized how useless the days I spent felt when I found out that Isaac died. I didn't change anything about the way I lived my life. I have to change now.
Want some kind of 'active memory' - audio, video - recorded around you that you can reference. Words aren't good enough ** 13:45 "The goal of the interview is to set the interviewee up for success." When someone is hired, they bring their expertise. Give them the kind of work that they would be doing every day anyways! They can pair program through the repository so that I can show you how we work? Brilliant.
Worth looking into this document: https://t3-tools.notion.site/Technical-Interview-Dan-Abramov-9aa6d8e9292e4bd1ae67b44aeeaabf88.
Bring your own interview plan? Show that you've been interviewed in a particular way?? Incredible! People work in different ways, and the decision to force just one method on people can give a potentially excellent employee a bad experience.
Give more interviews! This is the best way to learn what you want from someone. ** 14:38 Now that I have a good foundation for project work, this journal will become a bit more of a devlog. This journal is a space for recording day-to-day progress and learning as I learn to build beautiful applications from the ground up, from component systems nad libraries to graphics technique experiments to fast, reactive systems.
What am I working on?
The short of it is that the GPU on your computer - either 'integrated' (built into the CPU as an optimised subsection) or 'discrete' (a separate card entirely) hold a data structure called a framebuffer that represents the pixels that will be written to the screen. This information is written to a buffer then sent to the screen. The framebuffer is a data structure that represents the pixels of a monitor.
Cool, so I can just turn pixels on the framebuffer on and off?
No.
First, the framebuffer isn't just exposed. Whatever windowing system you're using does not allow you to write to the framebuffer at will. That would be a security vulnerability at best - applications could write pixels into one another to make you see something - and at worst make your computer unusable without a standard protocol that tells them how to write to the framebuffer and where. (If you aren't in a graphical session, you can get raw access to the framebuffer: https://seenaburns.com/2018/04/04/writing-to-the-framebuffer/).
You'll want to use a windowing library that abstracts requesting this framebuffer for you over various windowing systems (as Windows, MacOS, etc. have all concocted slightly different ways of doing this, nad they love making extra work for programmers) and gives you a reference to it. GLFW is historically the most popular, but systems like SDL2 and winit (Rust) provide similar functionality. You can then write pixels to this buffer following a standard, straightforward protocol nad they'll show up on the screen.
Unfortunately, though, the framebuffer doesn't live on the CPU or in the screen or whatever you think would be sane. Yes, screens have framebuffers, but it's your operating system's job to mediate between its representation and the data the screen is given. It lives on the GPU. GPUs are not optimized for drawing pixels on screens. They're complex mathematical hardware with complex APIs, optimized for rendering lines and rays and curves for modern 3D graphics, originally created to optimize for rendering perfect fonts with PostScript rather than in a bitwise fashion. The good news: they make playing video games fast, performing complex application tasks in parallel. How they do this is to be learned and probably under NDA. The bad news: GPUs expose complex, proprietary APIs that are inelegant and expose very large surface areas to program against. This makes learning to program for optimal graphics a mess, mostly because you're protecting corporate secrets. CUDA - the fundamental API exposed to empower parallel programming on the GPU - is not open. This makes computing a complex, ugly, mess - you'll always be programming against this nasty, abstracted API that's been artificially created, rather than being able to write to the machine and have the machine just render the text. This makes leveraging modern computing power a disgusting mess.
The good news here is that you can just ask GLFW for a reference to the framebuffer and write to it.
My goal with learning computer graphics has been to build small, beautiful applications that people - people who don't know much at all about using computers - can use every day to accomplish things in their life more seamlessly. Two paths to move forward:
Whoah - Mach Engine solved this. https://github.com/hexops/mach-gpu.
Why do I want more?
I only like two of my shirts. Three or four on a good day. The rest feel uncomfortable. Why did I buy this one?
It's beautiful - but unnecessarily. I don't want to stand out, to balloon or showboat or stunt or whatever you'd like to call it. I don't want to baby my clothing, spending too much money on a garment then having to carefully treat it. I don't want to be flashy. I just want comfort and consistency. This elaborate shirt is giving me a headache.
[[taixu]]
git clone with a single command in 1 minute max. It's insane that Rust takes so long and pulls in gigs of information. This just isn't sustainable. My launch software didn't even work on my own system by default, even when using nix, when working in isolation... I'm missing some dynamic linking package that needs to be part of the path.There are two paths we can take here;
HumbleUI and Clojure desktop apps will have a future in industry at large.Zig is probably the way to go here. It'll take longer to get started, but the toolchain is fast and has a promising future. I'll be able to write very fast code and learn a lot about systems programming in the process. It'll allow me to help build good infrastructure, work with games code to make beautiful desktop apps, and contribute to a fresh ecosystem.
I will show you the shape of my [[heart]] if you want to.
Then types - types add names to values wherever they go. The value of TypeScript doesn't come from the language's capabilities and static errors. There are some benefits to transpilation and to compile-time errors, sure - but far more important is the ability to see definitions on hover and receive competent suggestions from the typechecker. The better your types, the better you become at writing in the language that the code speaks - and the less discipline you have to have when revisiting and maintaining it. Your own types - your own language - is pushed back on you. ** 17:40 This ikea mirror is both the best fit for my home and a super affordable. Incredible combination! I love the oblong porthole look. (Stockholm curved mirror). The porthole is a brilliant touch - adds visual interest from the side and depth from the front. Shadows are worth exploring. ** 18:18 𦧠Awesome emoji ** 18:38 Some American-accented tea specialist is consulting with a future manager of a tea company in front of me. He's younger than me and is dressed very functionally - but he's a tea expert. She's bringing him in as a professional to work on and with tea, and he's extremely assertive about his work; I'm impressed by his level of expertise and control over the subject. He's able to explain tea to everyone here, and is making suggestions in both an assertive and an incredibly friendly manner. ** 18:45 "You would not love to meet [the people who will work under you at the restaurant]. You have to." Assertive!
omljud on the fly). I'm excited to have the apartment finished and start working under this new umbrella to make something real. We'll start with an email sign-in box : )Spending time online I can't help but wonder what I'm missing out on by not living in one of these innovation epicenters: San Francisco, New York, Berlin. San Francisco is the most beautiful place in the world but I've never seen a world so adulterated by tech that the fabric of the city outside of the office is ruined. Culture in San Francisco stinks - it's commodified and distilled into Blue Bottle and Allbirds, turning self-expression into a series of checkboxes, a manual, and the number on your bank account. The big players in SV, from my understanding, are brilliant and analytically stubborn to a fault, unwilling to consider 'unquantified' or 'soft' benefits to their lives - why do you think San Francisco looks like it does outside of the office? They need to learn to remove metrics from aesthetics and revert to their psychadelic dreams of the 70s. The wage gap is too broad there to ever realize this without proper housing. The only way to live in the valley is to live in a bubble and to curate the right bubble for you.
Cool - that leaves NYC and Berlin. Is Berlin monocultural? I haven't made friends with enough Berliners to know. I do know that enough people I keep in touch with online frequently commute between the three (SF included) to make them each a place where you'll be able to meet and know everyone. My work and ego aren't yet strong enough, though, to enter those spaces. I'll have to work twice as hard in Stockholm before leveraging the reputation I'm going to force my work to build. ** 13:28 Completely forgot to write about interiors. They're difficult! You don't notice the details until you really dedicate yourself to making a place home - why are the countertops like this? How are the tiles misaligned just slightly? Why is this asymmetric? Earlier I ranted against symmetry - but like all things symmetry is a balance. The four potted plants on my windowsill, all different breeds, were in radically different pots - and this looked absurd. Normalizing the pots - using four of the same pot and replacing terra-cotta with glass to better highlight the plants themselves - improved the room demonstrably. Terra-cotta feels uncomfortable to the touch. Caring for your belongings is more difficult if you don't enjoy them.
And the carpet! Generally the same rules of outside apply to inside. As you look from the ground to the sky, colors should get lighter and more vibrant. The really bright colors should be sparse and carefully curated - these are the areas that the eyes of a visitor should focus on when they enter the room. Everything else should be plain and muddy and pastel or black or white or anything that could blend into the background as a tool should. Surfaces should be distinct from the items on them without distracting from them - marble is too detailed and places the focus on the table ratether than the items on top of it, much like the wood grain of the table my laptop rests on as I type this.
Adorning the walls is just as important. Smell is more important than sound, and sound is more important than light; smell can indicate immediate or lasting danger, while sound implies near-term danger and light just controls whether something could be present or absent. It's therefore far more important to consider sound and echo than the details of furnishings in the house. (Segway: wow, these IKEA panels are brilliant: https://www.ikea.com/us/en/p/oddlaug-sound-absorbing-panel-gray-00427366. Design that is functional and accessible to anyone is far more important than design that is beautiful. More later.) The more detail you introduce to the home, the less noise you hear.
Finding the perfect furniture is incredibly difficult. I can picture the particular table that I want but I can't make it - I don't have access to metal fabrication facilities to cut the table to size and acquiring the raw materials would be super difficult. The process reminds me of why I love computers - digitally, anything I can imagine or picture I can make real. Experimenting with physical spaces is expensive and carries with it far more material limitation than the infinite computing power that I've become accustomed to having access to! + it's so difficult to imagine something filling in a space without having it. My walls are empty and I can hear it throughout the apartment.
Still don't understand: