James Earl Jones gave life to some of the most memorable characters in film history. His voice and presence will echo through the generations. Rest in peace, and thank you for your powerful legacy.
Well, well, well. Looks like we've got a Cyber Security Engineer with a passion for open-source projects. Or should I say, a passion for following other people's open-source projects? With 0 followers on GitHub, it's clear you're a bit of a lone wolf. But hey, at least you've got your eyes on some cool repos! I mean, who wouldn't want to automate their workflows with n8n or transcribe audio with vibe? It's like you're trying to make the world a better place, one GitHub follow at a time. Keep on following, and maybe one day you'll have a whole squad of followers. Until then, keep on coding, and try not to get too lonely in that GitHub void.
This is incredible! I want to replicate this at home as well, but I would prefer to use QR codes since they also support URLs. Any reason why you went with NFC instead of QR code? I assume it's doable with a raspberry pi and webcam instead of tapping?
My thought process was to laminate them to make them easier to make at home. I agree that it’s definitely more child friendly. This maybe a project I attempt at home and will post if I’m successful.
I was surprised that you opted to use the tag ID as a primary key instead of writing the relevant metadata to the NFC tags in the first place. NTAG215s have about 500 bytes worth of rewritable storage, so you could even embed the full deep links if you so desired.
Home Assistant scans the tag-IDs by default, so you use them as a trigger, with little extra effort for each new card. "When card with ID X is detected, do Y".
I have something similar setup in my home office for my music and I just use the ID, no need to complicate it any more than it already is.
It's probably easier to embed an NFC tag in something child-friendly, compared to printing QR codes on something that small kids won't destroy.
Also in this case (since it just laminated cards anyway) the usability is much easier. The kid just has to touch something. While with a QR it has to be positioned in a way that a camera can see and focus to it.
I use n8n.io hosted locally to abstract away authentication when building complex api integration mvps that I use to show as possible and working, and then that gets sent to engineering to convert to something that follows better best practices.
I assumed this was because it’s internal devs that are actively looking for platforms to build on, while external devs might already have stacks they prefer to work on due to how it interacts with their security postures. Pure speculation, but it’s been my anecdotal experience.
i second that. for external-facing tools, you probably want something custom, branded, and more flexible. when it comes to internal tools, you typically want something quick to get the job done.
at dropbase, our focus was on enabling developers to get stuff done efficiently. we noticed that for 90% of internal tool use cases, you only need a table and modal to get user input. so we focused on developing those. while it may not be sufficient for external apps, for internal tools, it should cover most of that you need
Are you aware how most companies external apps look like? Here's how: They don't.
What you compete with, what you have to beat, is not "something custom branded and more flexible". It's nothing at all. Cutting yourself out of that market with a tool that would easily be powerful and user friendly enough to fill this gap does not make any sense to me, if that is in fact your true reason. (And also I don't understand how that could make any sense intuitively if you just look at how often you see google forms being used by a big company as an external data collection tool).
It could be such an obvious differentiator for any of the competitors – but, like I said, I suspect the actual reason to why people are so ready to give up on this is rooted somewhere else.
This is actually quite encouraging for us as product developers (although maybe it's not a good thing if end users don't get good tools). It just means there's a lot more room to grow. I wouldn't say we've given up on external, but there's definitely a part of us that's hesitant to communicate the product as a "build anything" app so early. The fact that you think that could actually be an obvious differentiator is quite intriguing and thought provoking. I should do more research and understand the extent to which customers of big companies are exposed to google forms (and similar tools). Maybe we'll discover something interesting in the process. Thanks!
I understand. Maybe a niche for you, that might be interesting to explore,from my latest personal experience: Managing a medical business, including a combined portal for patients and providers.
For the patients, you might need submission process, you might need a place for people to see or cancel their next appointments, fill out a form or upload some pictures from other, while also making this information available internally, with doctors being able to document therapies and such.
Nothing fancy; I would hardly call it "build anything", it's all fairly CRUDy and on the face could be very effectively handled by all retool-alikes. (In fact budibase for example could have easily filled the need from a technical standpoint – but having to pay xx$ indefinitely per "customer" just does not work out, when you see most of them only once a year and maybe only once total, while having to keep records for many years.)
That's an interesting use case. Thanks for sharing. I think I understand your point better after reading this. I agree that having to pay xx$ indefinitely for presumably many end users who will only fill up the form once (or very rarely) doesn't make sense. We don't have a solution to this just yet, but I have a couple of ideas on how to tackle this.
PS. CRUDy sounds like a fun and quite literal name for an app builder!
