This is cool! I looked into building a slack app myself, I'm curious: how are you liking the slack store and its policies? Was starting out difficult? I vaguely remember having to have your app installed in multiple workspaces already before being listed in the store
Nice! The site looks very clean, good job! I recently bought a Garmin and I was looking into analytics-heavy training platform since I'm doing a lot of different sports so I can't just go for a 10k training plan or something. I ended up going with intervals.icu, how is tredict different from it? It appears a little tighter on the visual maybe? Anyway good job!
Thank you. Tbh I cannot tell too many difference to intervals.icu, last time I had a look was 2 years ago or so. I remember it lacked some things, but this could have changed. I think Tredict is a little bit more on the straight forward site, just looks cleaner, visually and also from the workflow, also more performant. But this is of course opinionated as I am the inventor of Tredict. I have deep respect for Intervals too. You just could use both for a certain amount of time to see which one fits better for you. :-)
This is so cool! As someone who loves trying out new restaurants I need to ask: why would I go with you guys instead of going to the restaurants myself with a friend or partner? Looking around your website it seems to me that there's very large attendance, which in my mind means generally less focus on the food itself. Do you think one of the main factors is meeting new people/the sense of community? Anyway good job! I'm not sure what your margins are but it's probably more than 500/month! Congrats!
I think there’s quite a few reasons people come. I’m just going to bullet some of them out in no particular order:
- We do the work to find the restaurant and curate a menu, story, and theme. E.g., we might go to an Indian restaurant and focus the event on only the southern regional dishes.
- Many times we have dishes that are off menu specially for our event.
- Sense of community. We have quite a few regulars who have gotten to know each other. In 2025, 45 people reached their 20th or 30th event with us. Since we take over the whole restaurant there’s a little more freedom in how the space is used. Lots of new friendships have been forged.
- When you go to a restaurant with a friend or small group, you can only order so much. We’ve had events with upwards of 25 different bites. There’s really no better way to sample everything the restaurant has to offer.
- There’s a few people who say their partner are picky eaters, so they come to our event each month to have the opportunity to be a bit more adventurous. It’s an incredibly diverse group with a lot of different reasons to attend.
Just to add my own observation here: some cuisines are really optimized for sharing in larger groups… certainly a lot of the regional Chinese cuisines assume many people at a table, with large (i.e. higher priced) servings. If it’s just 2 or 3 of you, you end up getting only 1 or 2 dishes, often with a lot left over.
So, this is a genius way of optimizing for that!
I totally want something like this here in Sydney.
I'm from mobile so I can't see much more but I can spot that the url contains the _gl parameter. That's the parameter (and cookie) used by Google Analytics to perform cross-domain tracking so I believe your assumption that GA is active is correct.
I think this blog post covers a lot of ground while not really diving deep into any of the points it tries to make. I just want to highlight a couple of them because they are particularly important to me.
The concept of "you can desire only what you don't have" coupled with "you borrow your desires". Every thought in our head comes from a previous input, a lot of the same kind of inputs will spark a lot of the same thoughts and naturally they will spawn desires. I was on a work trip last year with two of my colleagues. They are into music (I'm not) and naturally a lot of the conversations were around singing and producing. I left that trip feeling an intense desire of trying out mixing/DJing for the first time in my life. I definitely attribute that to talking intensely about music for a few days for the most part.
The other one is: there's value in being wrong and in experiencing negative things. I'm not going out seeking traumatic experiences or anything but I yearn for new experiences for a variety of reasons. Even smaller ones such as a new restaurant to try out sometimes can suck, can be a waste of time/money but as long as the negatives aren't that impactful I think that the small gems you find a long the way paired with the funny stories you get about the bad ones are very much worth the potential negative experiences. I often talk to people that "feel stuck" or on "autopilot" and I do think that always doing the same things over and over has diminishing returns on happiness and joy. Trying out new things I'd say is generally a good idea (common sense applies, as always).
I'm always curious on how you guys use your note taking apps? I tried multiple (obsidian, notion, logseq ecc..) but always struggled to find a real use/need for them outside of work.
Am I missing something on going straight to applying my knowledge, after having found a solution to whatever problem I'm facing from a variety of sources, and not writing down many notes outside code comments/README.md ecc..? E.g: I'm currently building a mobile app with flutter, would you guys suggest that I log what I'm learning, even considering it's pretty basic stuff due to the fact that it's my first encounter with flutter/dart?
Now that I think about it, writing notes during the process could perhaps help me have more material for my blog posts
I basically live in my notes all day. I have two main categories:
1. General knowledge: Anything I want to be able to look up again, for me mainly how to do certain tasks in software, which is things like keyboard bindings, steps to achieve a result (e.g., something like "remove the background from a photo"), and flags for a command line program. I also add more abstract things, like computer science, and music theory concepts, but I find these concepts are usually easier to recall from memory once you know them (I've read before that memory works like a web, so if you're attaching new concepts to existing concepts, they'll be easier to remember), so I don't have many notes like that.
2. Projects: Tasks related to a project, and things I've learned along the way. For example, if I'm diagnosing a bug, maybe I found an important code snippet, so I'll cut and paste it to the project file. Also useful commands, e.g., if there's a single test I'm working on, I'll save the command to run just that test in isolation.
The general principle here is I usually find it easy to remember if I've ever done something before, but hard to remember exactly how to do it. (Research indicates that if something doesn't fit into the web, then if you don't do it enough, you won't remember it, so the notes compensate for that.)
I find this helps me stay in flow because just looking something up quickly from my notes is much less disruptive than searching to find it again (or trying to think to reconstruct it). If you don't mind searching again later for something you know you once figured out, you probably don't need notes, but if that drives you crazy, like it does for me, than notes are helpful. For me, it feels like I'm constantly expanding the number of things I can do easily without having to depend on my memory, which I know from experience is fallible for these tasks.
It's similar for context switching between projects, when switching tasks, being able to look at your note for a project, and being able to see both exactly where you left off, and documentation of everything you've learned so far, makes it easier to move forward again.
I've found its helpful to divide notes into two separate categories: notes & logs. Anything that is not a log is a note. This includes recipes, people, tools, reading list, etc.
Logs are meant to serve as a labnote book. Each entry is saved in a daily journal & with a date and simple description header. What I'm doing, why, how its going, checklist, etc. Basically a dumping ground for everything I could possibly have a use for re-using later. This help eliminates entire categories of notes(e.g. call with mechanic), and give you a chance to leverage smaller notes with backlinks to the individual experiences using it. The effort to keep notes evergreen is very difficult when the content keeps changing.
Zettelkasten. It's an incredibly simple idea. Obsidian, Logseq, Roamresearch, Org-Roam - they all are based on that simple idea.
I used to spend a lot of time, thinking how should I organize my notes? Tried many different methods - categorizing them; grouping them by dates - years, months, days; putting them in multiple files and folders; using a single file with many (collapsible) headings, etc.
After switching to Zettelkasten method (I use Org-Roam), I realized - whenever I write any note, the only question that I really need to ask: "in what context should I re-discover this stuff later?".
A practical example: I would be discussing a session-related security vulnerability with my teammate, let's call them Jimmy. I would start a note with a meaningful title. Then add links to [[Jimmy]] [[session]] [[vulnerabilities]]. For simplicity, let's assume I already have these nodes in my system. 'Jimmy' is a node that has all the info about my teammate, their role, their contact info, etc. The node may also have its own tags, e.g., [[front-end-team]].
Now, months later, whenever a similar thing comes up, I wouldn't be scratching my head thinking "haven't I discussed that with Jimmy last year in October? Let me go through my October notes...". No, I would open Jimmy's node then lookup for all the backlinks and surely, I would find the relevant notes. I may even forget that I spoke to Jimmy, then I would find the notes through other nodes - [[front-end-team]] [[vulnerabilities]] [[session]].
I tried Org mode and used it for a year or two. I liked its integration of notes and task tracking. The Org Agenda works well. Ultimately I found it a bit chaotic to have tasks scattered amongst text files though. I acknowledge that I probably could have made Org work for this and my current solution (Omnifocus) is better in some ways, worse in others.
For the notes though, I just write plain text notes using Windows Notepad or Mac TextEdit and I put them in an appropriate folder. I have various folders - some for "projects" and others for "reference". I like the folders because I can put other things in them, such as PDFs, emails, spreadsheets, etc. Sometimes I have a single text file for a project that has chronological notes; other times, it's appropriate to add additional files to capture particular ideas, lists, etc.
The note-taking apps don't wind up doing much for me.
> I just write plain text notes ... and I put them in an appropriate folder
So I guess that means you hardly reuse any of those notes at all? I just can't really imagine the process of having to fish for some creative ideas from those buckets.
I use them every single day. Because I maintain the folder hierarchy, I remember how to descend the folders to find what I need.
Years of experience has taught me that relying on loose tagging webs and searching mechanisms and fancy tools does not work for me, not for notes, not for emails, not for anything else. I organize things into nested hierarchies. This takes maintenance, but so does maintaining tag webs and using the tools to maintain and mine them.
For something that espouses some of these principles (though I do not use this system):
Writing down the simple stuff can be nice if you want to:
* Stop doing stuff in that field for months and have previously processed notes to reload in your head when you come back.
* Give feedback to maintainers on what worked/what didn't when you entered their ecosystem.
* Communicate to newbies how you overcome X problem when learning Y. Not everyone may have your particular insight. You could roll it into a blog post or other communications.
* Provide stepping stones for you to relate other frameworks and languages back to what you've already seen and know, to solve challenges in different domains.
I find that most more specific ideas for using the data come at random periods throughout my life. The questions are usually non-obvious when just staring at the data. I write them down as little notes themselves and come back to them when I have interest/motivation.
Can you share an example of a use case you have in mind of this "explainer + RAG" combo you just described?
I think that RAG and RAG-based tooling around LLMs is gonna be the clear way forward for most companies with a properly constructed knowledge base but I wonder what you mean by "explainer"?.
Are you talking about asking an LLM something like "in which way did the teams working on project X deal with Y problem?" and then having it breaking it down for you? Or is there something more to it?
I'm not the OP but I got some fun ones that I think are what you are asking? I would also love to hear others interesting ideas/findings.
1. I got this medical provider that has a webapp that downloads graphql data(basically json) to the frontend and shows some of the data to the template as a result while hiding the rest. Furthermore, I see that they hide even more info after I pay the bill. I download all the data, combine it with other historical data that I have downloaded and dumped it into the LLM. It spits out interesting insights about my health history, ways in which I have been unusually charged by my insurance, and the speed at which the company operates based on all the historical data showing time between appointment and the bill adjusted for the time of year. It then formats everything into an open format that is easy for me to self host. (HTML + JS tables). Its a tiny way to wrestle back control from the company until they wise up.
2. Companies are increasingly allowing customers to receive a "backup" of all the data they have on them(Thanks EU and California). For example Burger King/Wendys allow this. What do they give you when you request data? A zip file filled with just a bunch of crud from their internal system. No worries: Dump it into the LLM and it tells you everything that the company knows about you in an easy to understand format (Bullet points in this case). You know when the company managed to track you, how much they "remember", how much money they got out of you, your behaviors, etc.
One of the big challenges with clinical trials is making this information more accessible to both patients (for informed consent) and the trial site staff (to avoid making mistakes, helping answer patient questions, even asking the right questions when negotiating the contract with a sponsor).
The gist of it here is exactly like you said: RAG to pull back the relevant chunks of a complex document like this and then LLM to explain and summarize the information in those chunks that makes it easier to digest. That response can be tuned to the level of the reader by adding simple phrases like "explain it to me at a high school level".
I see a lot of negativity in this thread about GraphQL. As someone that's gonna be building a backend API soon, what's your favourite article/guide to build a REST API at scale assuming that GraphQL is overly complicated for our use case? I'm probably going to have to explain the main differences or at least contribute my own opinion so any link would be appreciated.
We mainly use python and we're probably stuck with MSSQL. I've built simple stuff with FastAPI and even Flask before but nothing serious.
The best recommendation I can give is to pick a standard like JSON:API, and stick to it. Not to make the standard wonks happy, but to save your team from discussions on how to structure a given response. Less bike shedding, essentially.
