tunaoftheland

1. Plimsoll Line for dealing with anxieties from mountains of Reminder items, by surfacing the stress factors and taking small actions such as quick journalling and a breathing exercise. The new version with Widget should be released within the next week or two. Version 1 is currently in the iOS App Store. (https://apps.apple.com/us/app/calm-to-do-list-tasks-plimsoll... Calm To Do List&Tasks-Plimsoll). Made it to help my wife (and me!) not get so overwhelmed with things she has yet to do but hasn't started. Also to make it easy to write down things weighing heavy on her mind to alleviate the vicious cycle of emotional decay.

2. Yet-unnamed and -unreleased weather app for planning outdoor activities at times of the day when the weather will be most favorable (or least bad). Made it so that I can plan when to go out to the back yard to bring in more fire wood for the stove in my house. The weather has been tough this winter in the Northeastern US so it finally made me work on the app.

The main thing that I would like the app to do is to nudge me to take small actions of visually surfacing the emotional impact of the individual items (a todo item or just a thought in my head) rather than them filling up my head. So I would like to be the one driving the app than the app driving me like most todo apps do. I want the app to help me break myself out of being paralyzed with anxiety by taking small actions that are doable and maybe even pleasant. Hopefully that makes sense when users try it. :)

So I'll have to think hard about how to solve the problems you mentioned, they are excellent points. Having fewer configurations and encouraging the user to take control of their emotions through small actions as core principles means some limitations in features...

Anyway, right now the app lets you write a "Quick Journal" into the Notes field in the Reminders app. I have in mind the app encouraging user to break down the items causing lots of stress into sub-items so it becomes more manageable. Or suggesting contacting a trusted friend that the user has selected in configuration beforehand.

Suggestions welcome on how else I can nudge myself and other anxious users! :)

I learned that ships have a "max load" line (or Plimsoll Line) https://en.wikipedia.org/wiki/Load_line_(watercraft) to prevent overloading them with cargos, but my todo list didn't. So I built an app to surface my emotional load and put mental health above raw productivity.

I am experimenting with the concept of giving each item in the iOS Reminders app an impact multiplier between -1.0 and +1.0 to assign them "weights". The net weight of the todo items should indicate my overall mood or emotional burden. If it doesn't maybe I have yet thought about what's making me feel good or bringing me down. The net weight is visually represented by the "water line" that rises the more into the negative the net weight becomes. I'm thinking of adding features to nudge me into addressing the rising water line.

And since I want to lower my own stress and anxiety using this app, there is no signup or subscription. No data collection other than the bare minimum to make the "tip jar" working through the App Store IAP, so no PII collection.

Do you think you'd find this approach to be helpful for managing your own anxiety level?

(Edited to add a bit more clarification)

Knowing myself, though, I don't think I'd keep up with this since it would take mental strength on my part to overthink the data structure for the task entry. I've been thinking about how I might also track emotional impact of my todo items on me. I wonder if the open nature of a txt file would be good for instant journaling about things that give me stress?

I really like having some guardrails when it comes to organizing thoughts so this system might not be for me. Also building up the daily habit to organize the todos at the end of each day is something I'd probably struggle with for a while. I do agree that is a great habit to have, still.

For those who haven't tried it yet, I did couple of test posts on the Simulator to get an idea of what kind of comments I might get. Some of the comments were hilariously close of the real HN ones, and others posed excellent questions and even potential solutions to the UX issues that I had been thinking about.

From what I understand it emerged from a gamedev studio from Sweden (King or something?) so there's commercial release pedigree there. I believe their console platform build/release tooling does cost money for game devs because the platform SDKs themselves impose restrictions. But I get the impression that defold as org does seem to put in earnest effort to be fair to game devs with licensing, etc. like others mentioned here.

EDIT: Some typo fixes, tho many remain, I'm sure :)

I have been thinking about my own experience trying to learn Pharo and GT and came to the conclusion that, because of the nature of smalltalk, written form of teaching materials are not effective and in fact even painful to learn from. Nothing wrong with the smalltalk approach of computing, such as GUI-centric and image-based environment. They are what makes it so interesting and an immersive development environment. But video tutorials and live-session hand-holding are what's needed to teach these environments because of the highly interactive nature of smalltalk. The Pharo MOOC exists, but that requires the type of academic-level time and mental commitment of back when I was in school. And as a hobbyist, I have less-demanding options for learning that are also interesting so I end up pausing my efforts to learn Pharo/GT.

It's a tough situation for smalltalk proponents because interactive instruction material are very costly to produce and maintain. And the smalltalk communities are much smaller and they have don't massive corporate sponsors. Even cheaply-made YouTube videos take time and effort, and I am grateful for those who make them out of their enthusiasm for the technology!. But I'm afraid I've been conditioned to watch slick, engaging video content with clear, well-paced voice tracks and accurate captioning.

I do wonder if the smalltalk community could benefit from a beginner-friendly, simplified version of Pharo UI that starts up in a Jupyter notebook interface and expose only limited tooling, to give the learner a taste of what's possible and has some guardrails to prevent the user getting lost. Gradually revealing the Pharo/GT features that way would keep the learner engaged and motivated. Because of the above-mentioned challenges with producing teaching content, self-guided interactive learning tools would be the best bang-for-buck, I think. I thought the Elixir language manual was excellent and it was the first language reference doc I actually enjoyed reading! (Until it got to the string handling... then I ran out of attention span, lol) Elixir also have Livebook.dev which gives notebook interface. Could be a good inspiration.

Another possibly dumb idea I had was that maybe smalltalk is an ideal companion to current LLM tool/function calling APIs, where an LLM can "guide" a live smalltalk environment for developing an application through an API. Since a smalltalk environment is always running, it can also (maybe) feed relevant live state context back to the LLM with some feedback prompts... I suppose a smalltalk envrion can serve as a sort of memory for LLM as well as an agent for modifying the smalltalk environ?

Sorry, didn't mean for this to sound like "you must do this for free for my mild interest in your passion project!" This has been more of a stream-of-consciousness spillage onto this forum because Grumbledour's excellent comment resonated with me. :) And the mention of notebook interface clicked in my head.

Anyway, sorry for ranting, and thank you GT/Pahro team for making something fascinating! Stuff like this is what keeps me in the technology field instead of totally leaving it out of frustration with the where tech meets business!

I’ve only skimmed it and have started reading but the parts about highlighting/phrasing of one’s marketable skills seems good.

A bit more generous with the system resources, but PICO-8 does have a bigger community and "carts" to download and poke around with.

One example is a Bluetooth-enabled iOS/Android app that I made (but did not publish to app stores). I was able to use a RN library for Bluetooth communication and interact with another device (a bathroom scale) in JavaScript. It was one of those "Wow, this is cool!" and "Man, this is pain!" moments. Note that I did not use create-react-native-app/Expo for this.

Another app, also iOS and Android, simply renders the content of my wife's Etsy store, including the pictures (published to both Apple and Google Play stores). It was done using create-react-native-app/Expo. I didn't like the dependence on the Expo site for building app packages. It's free and there for now but I'll have to "eject" the app in the future if the something were to happen to the site. I used an open-source RN components library which does a good job selecting default typefaces and sizes. There were still fiddly bits I had to poke at to make it look decent, but it was alright for something that I whipped up as quickly as I could. The documentation for the component library was not keeping up with the continuous changes React / React Native / the library itself so that was a pain.

Note that it can get a bit confusing keeping track of what you can and cannot do with create-react-native-app/Expo. You might have to scope the app appropriately until you feel ready to "eject" it from Expo and access the more lower-level RN APIs.

On the web side, I find that I can grok the React API more easily than most other SPA libs. So there's natural affinity for me to keep the API complexity down in the projects that I choose to do by preferring the React-* APIs in general.

I agree with @jqbx_jason's comment and RN was the only sensible (sane?) choice in my case for the 1-man projects. Some background: I have professional experience in Java, C#, C, JavaScript/ES6/TypeScript and few others, but no experience doing fully-native iOS and Android apps.

FWIW, Pinterest seems to be liking RN for their mobile apps: https://medium.com/@Pinterest_Engineering/supporting-react-n...

create-react-native-app works by leveraging Expo

Pretty interesting thinking about the gap between what is possible now and where the human population is with understanding that.

I had briefly considered it to use it as a cross-platform desktop RAD platform, but its integration story was pretty weak. Things like connecting to PostgreSQL could be done, but only using an older protocol. Serialization formats like ProtoBuf were not available. The GUI framework was not easy to parse (for me), though there were inklings of work on easy-to use, high-level GUI builders.

I left with an impression that it was for people smarter than me, though I'd still like to learn it!

BTW, I had heard that software for seaport dock management used to be dominated by SmallTalk. Not how things are now.

(Edited to fix the worst of the grammar errors)

In my particular case, being a solo dev with web background, RN is the only sane option to make an app in Android and iOS in reasonable time.

I'd say it can be a good tech choice, if you plan to focus your work on platforms that React API and ecosystem touch (mobile and web, maybe not desktop).

EDIT: Some grammar cleanup and the bit about styling.

I think the embedding part is certainly a tradeoff. Once the development community settles on a best-practice for things like this, it becomes less of a danger of forgetting. For example, once this sort of config shows up by default in archetypes and boilerplate projects, I feel that the danger is reduced to the level of being manageable. And hopefully the port that the editor uses is blocked by default in the production environment. :)

As much as I want to like Pharo and am amazed by its fast progress, its integration story (to external data source like PostgreSQL) is pretty weak, currently. I'll be tracking the progress of this project to see how it goes, though I've yet to love Clojure.

I want to add that I think it's a beautiful approach to solving the problem; rather than implementing a complicated mechanism for interrogating the application state from a tool running in another process, the author is flipping that around and putting the editor inside application so that it has a very simple access to the application state. Love it.