allenu

I used to be much more precious about notebooks myself. I may have also found tricks or games to play to on myself to force myself to use them without fear of mucking them up with bad sketches or poorly organized ideas.

Eventually I got over it now and just use them as places to scribble ideas and don't care if it's ugly. I find that over the years I just started caring more about getting the thing I wanted to accomplish done than making sure I had a pristine record of the thoughts that led up to it. Maybe it's an age thing.

I stand corrected. I haven't used X in a long time, but I think you're right.

I really hate that change. It's counterintuitive that a shell recognizes mouse clicks to mean "select this option".

Also, the auto-copy selected text feature is awful. That's another thing that is so counterintuitive. I have never seen a UI where just selecting text means auto-copy to the paste buffer. Who is coming up with these awful UX ideas?

On top of that, the scroll "feel" of the new client (at least on macOS) isn't quite as good as their old one. It just feels off and not like a native terminal.

I imagine they're suggesting that so someone who lands on the page and is unaware of Bellard can immediately know what he is (famously) known for instead of having to scroll through the long list of projects.

It sounds like another way to put it: tell people what they want to hear and you'll go far. Most people want their beliefs confirmed, whether what they believe is true or fiction. Unfortunately it can lead to an echo chamber-y world where people only associate themselves with others who have the same core beliefs, which is even easier when communities are online.

It's a common way to phrase a request in the corporate world. It's a bit more of a concrete and explicit than a simple request, something that can be written down in bullet points in a meeting notes summary or an email.

I hate it too (and others like "learnings" when "lessons" would suffice), but I see the purpose it serves. Asking a team "What's the ask?" is a way of explicitly asking what the concrete requests are which can be documented and followed up on (i.e. "circle back"), whereas just asking for "requests" is more like asking for preferences, which may not be binding, or a vague direction to go for planning.

The one on the shelf is probably a Akari paper lantern. I have an orange one that I quite like. You used to be able to buy them from Design Within Reach or the MoMA Design Store, but I can't find them on their sites now but they're on the Noguchi site. [1] The hanging sphere one might be similar.

For those not aware of them, Design Within Reach has a lot of nice famous designed furniture and shelving, but pricey. They often have 15% off season sales though. Good place to shop if you're into the stuff seen in this blog post.

[1] https://shop.noguchi.org/collections/akari-light-sculptures

Very beautiful setup. I'm jealous of the space to do this. I like the idea of making the desk face out into the room, but my office is quite small, so it would end up floating in the middle of the room. Having it in the corner isn't quite as pleasing to the eye, but it makes it so the rest of the room feels larger.

There are bits in here that are a little bit over-designed in my opinion. Do you really need two fountain pens at the ready? Must they be there on the desk at all times? I find I carry my single fountain pen with me when I need it. I also can't see myself always sitting at the desk to read. I have books scattered about the house wherever I was reading last. Also, it's great to have such a wide desk for both digital and analog, but how many of us have the space for that luxury? Anyway, just food for thought if you look at something like this and feel jealous and think whatever space you work in today is now poorer for seeing someone else's nicer setup.

Similarly, I'd write code in BASIC in notebooks before I had a computer. Later on I remember writing up assembly code in my high school library on loose leaf sheets when I had a neat idea and my friends were busy studying. Nothing like solving a problem the old fashioned way.

I have vivid memories of thick dBase manuals on shelves in offices wherever somebody had an IBM PC or compatible computer. As a kid, I had no idea what it was, but the thick grey books made me think they must be a very important thing indeed. Just seeing the name dBase immediately evoked the memory of those books. Eventually I did get into computers and programming languages in my early teens but never did figure out what this whole dBase thing was.

I've been working on an update to my flashcards app for over a year and half now and I'm finally nearing completion. This is for Mac and iOS only and the app uses Core Data with CloudKit for syncing its data, which has been interesting learning the ins and outs of. (For instance, CloudKit can throttle your sync if you have too many objects, so I ended up having to create snapshot objects to carry lots of records in bulk which I then expand in a local SQLite database to get around its limitations.)

The app has a lot of UX details that I've really enjoyed working on. I wrote up some notes about it here: https://www.freshcardsapp.com/3/

Separately, also working on a Zettelkasten notes app that pushes you to make small, atomic notes that you can organize in "collections" to provide structure beyond just hyperlinking in the note text: https://understory.ussherpress.com/ This has been a lot of fun iterating on. I started with a Miller Columns UI, like Finder, to visualize the graph of connections between notes, but I found that it was too overwhelming to use, so I scaled back and went with a more Notational Velocity-like quick search bar with note addressing. The app UI mimics a browser because I found that it works really well for something like this. I need to polish it a bit more and want to find people who will give it a beta test to help me iterate on the ideas some more.

I wonder if there's any relation to the strategy of the Gish gallop or Flood the Zone where you overwhelm your opponent with arguments that they have to engage in. Technically, you don't have to engage in the arguments, but the sheer volume can make it seem like you're losing if you don't.

I can see it happening. It's very easy to drag and drop a file into an Xcode project and when the dialog pops up asking if you want it to be added to the target app bundle you just hit OK, not realizing what you just did. I've done it before with a document file but caught it before I shipped by inspecting the app bundle output.

I like the clean design of the landing page. I downloaded it and started the app and it needs an OBJ file to even do anything, so I wasn't able to play with it at all.

It would be cool if it included sample OBJ files to entice me to find my own later. Otherwise I feel like I just hit a wall immediately in the app will probably not try it again.

I'm in total agreement regarding some designs that seem obvious later but really took several iterations to reach. There's definitely hindsight bias when a design works so well that it feels obvious.

My point was more that I've seen product demos where parts of a product were presented as having been pored over painstakingly when in reality it was decided on day one that it would work that way. However, because it's a prominent feature, it feels cheap to show the reality, so I get that for demos there's a bit of storytelling that goes into it so the audience feels like it was a revelation.

For UX that I've designed myself, I have definitely found that a lot of the great ones required a ton of iteration and almost "courage" to go against my initial bright ideas and look at things from a different perspective. It often required taking away elements that I thought were absolutely required at first but later realized made more sense to go without. If someone were to look at the final result, they would definitely think "Well, obviously that's how it should work." But more likely they'd have go through a similar journey that I did to come up with it if they hadn't seen the solution.

In a way it's like finding out how a magic trick worked. It's only obvious in retrospect.

Sounds like a really cool idea. How do you organize the meetup and promote it to people if it ends up being random people? Do you set it up on meetup.com and have a theme at the minimum?

I've been to a lot of meetups and it's definitely hit or miss and obviously depends on the sociability of the people that show up. The better ones I've attended are generally ones where people aren't trying to network for work purposes and are there literally to just socialize. The networking ones I find very dull as it's people just talking shop and career and if you've nothing to offer them on the career front, they move on quickly.

I love these types of videos because they create this fiction of how design happens, where people sit around a table with drawings and or come up with beautiful mock-ups (the motion sickness glasses is a good example). Often, a lot of design decisions are super obvious and don't require a lot of sweat and collaboration to come up with, but in videos they're made to appear very difficult as it presents better. And other things are super messy, but you're not going to show that as it's hard to communicate.

Copy-pasting is a clever way to do it!

I used to use TheDraw for doing ANSI art, but I also ended up making my own ANSI drawing tool back then. It's stupid to think of now, but one reason I made it was because I had a monochrome monitor, so I couldn't "see" color. I wanted a feature where I could put the cursor over a character and it would tell me the color there when I was drawing so I could still use color in the work.

I wasn't prolific, but did do a handful of ANSI art pieces for local BBS SysOps who liked them well enough. Only later on I realized when I got an actual color monitor that I had a few color mistakes in them and they never told me. lol

Beautiful. Masterfully done. I love all the BBS-era aesthetics and callouts. I hadn't seen FILE_ID.DIZ art in forever.

This project brings back memories. I worked somewhere over 20 years ago where we were working on something just like this (touch displays using cameras). The biggest challenge was definitely the lighting conditions as you mentioned. We tried to rely on natural light but it was too unreliable. Darker skin tones were harder to pick up, and then you had issues with random reflections, light and shadow being cast on the screen, etc., which would make the system detect spurious fingers and touches.

We also had algorithms to detect finger shape to detect location of the pointer and when you were touching the screen. I saw way too many videos of fingers touching screens back then, so it's funny to see similar video clips here.

But if you are running in the wrong direction, speed is of very little value.

I think of it differently. Speed is great because it means you can change direction very easily, and being wrong isn't as costly. As long as you're tracking where you're going, if you end up in the wrong place, but you got there quickly and noticed it, you can quickly move in a different direction to get to the right place.

Sometimes we take time mostly because it's expensive to be wrong. If being wrong doesn't cost anything, going fast and being wrong a lot may actually be better as it lets you explore lots of options. For this strategy to work, however, you need good judgment to recognize when you've reached a wrong position.

It must be a nod to Freud (i.e. id, ego, and super ego)

Watering plants is also super easy once you do it regularly. You get a sense of how much water a plant needs just by looking at it and testing the soil (via moisture meter or just by touch). It's quite rewarding realizing how each plant differs.

Just a guess, but it looks like an IBM Model M but with a German layout, or at least something from that era.

I was being a little facetious, but there are things that most people would find tedious today that we would put up with in the past. Writing anything long by hand (letters, essays), doing accounting without a spreadsheet, writing a game in only assembly language, using punch cards, typesetting newspapers and books manually...

I think you're spot on. It feels like parts were edited with AI and parts were left alone.

This isn't just a Digg problem. It's an internet problem. But it hit us harder because trust is the product.

The statement this is making is presumably the crux of the problem (Digg cannot survive without trust!) but it's worded so poorly that it's hard to imagine someone sat down and figured these three sentences were the best way to make the point.

I was thinking about that recently. Maybe decades from now people will look at things like the Linux kernel or Doom and be shocked that mere humans were able to program large codebases by hand.

I've noticed that too and it's not too different from political discussions. At the end of the day, I think the split is really about different values people have, their identity, and justice.

A lot of developers' identities is tied to their ability to create quality solutions as well as having control over the means of production (for lack of a better term). An employer mandating that they start using AI more and change their quality standards is naturally going to lead to a sense of injustice about it all.

I think the real divide is over quality and standards.

I think there are multiple dimensions that people fall on regarding the issue and it's leading to a divide based on where everyone falls on those dimensions.

Quality and standards are probably in there but I think risk-tolerance/aversion could be behind some how you look at quality and standards. If you're high on risk-taking, you might be more likely to forego verifying all LLM-generated code, whereas if you're very risk-averse, you're going to want to go over every line of code to make sure it works just right for fear of anything blowing up.

Desire for control is probably related, too. If you desire more control in how something is achieved, you probably aren't going to like a machine doing a lot of the thinking for you.

I was using a M1 Mac Mini and only 8GB of RAM on it to build iOS apps for maybe a year. It's absolutely doable, though it very noticeably gets a little less snappy when building projects. When building in Xcode and then switching to Firefox to browse for instance, I could tell it took slightly longer to switch tabs and YouTube playback would occasionally stutter if too much was happening.

I also was using an Intel MacBook Pro with 16GB at the time. Doing the same thing there was much smoother and snappier. On the whole, it actually made me want to just the laptop instead since it "felt" nicer. (This isn't measuring build times or anything like that, just snappiness of the OS.)