Coincidentally, I wrote an article today on how I use it for similar scenarios. It can fetch from S3, multiple databases at once, and so on.
And you get all the benefits of a database when you need to join or postprocess data from multiple sources.
3,852 karma · joined March 27, 2016
Coincidentally, I wrote an article today on how I use it for similar scenarios. It can fetch from S3, multiple databases at once, and so on.
And you get all the benefits of a database when you need to join or postprocess data from multiple sources.
Not sure what changed, but now it just redirects me to x.com.
High-level techniques were never a problem. You could Google tens of articles on this topic. They are useless too, it's like learning how to drive a racing bicycle from reading a book. Sure, you will know a lot about nuances, but you will fail miserably when it comes to a real race.
Hard tasks require a lot of guidance and code reviewing, unless you are creating another throw away project where correctness, maintainability and code understanding does not matter.
1) Don't ask LLMs for big changes
2) Review everything and point them in the right direction
Large models still suck at big changes, they produce questionable architecture and you still have to review the code, if your project is serious enough.
The codebase quickly become a mess, if you don't pay enough attention. Does not matter which model.
So why bother with big models, when flash models are 10x cheaper and much faster to iterate under guidance? Large models can be used for security and bug audits. Flash models work almost the same for changes under 300 LOC when you dictate how you want your code to look.
Your syntax highlighting is very basic as well. Just ask LLMs to provide tests where it would fail to render correctly.
The first thing that comes to mind after looking at it: print("# not a comment")
Here are some numbers roughly in the right ballpark: during the Disney era, which lasted about 10 years, FiveThirtyEight published about 20 stories a week. Let’s say that each story took about 20 hours to produce between research, writing, graphics and editing.3 Do the math, and that works out to about 200,000 person-hours of work that ABC News just deleted.Just look at one of the comments from j04chim on Github:
This project IS an "elaborate hoax".
The "WiFi CSI sensing survey (IEEE, 2019)" reference is actually called "Effects of Video Encoding on Camera-Based Heart Rate Estimation" and is about, well, video encoding.
"WiPose: Human pose estimation with WiFi (ACM, 2020)" is actually called "Exploring LoRa for Long-range Through-wall Sensing" and is not about "pose estimation", but if you follow this paper you could indeed sense human activities through walls. Its explain that LoRa can sense farther than Wi-Fi. If you had really read that paper, you would probably have used LoRa instead of Wi-Fi.
"DensePose from WiFi (Carnegie Mellon, 2022)" is the real name of the paper but only show that you can estimate human poses with Wi-Fi and CSI with somewhat good confidence, and the paper compare the idea to image-based pose estimation. So... Not a lot of "through walls vision" going on there.
These three papers alone you present as "references" shows that you project demonstrate impossible capacities and you AI(s) seems to have mixed the second and the third papers to create this non-sense.
If you discovered some new capacities, unexplored by DensePose and forgotten by LoRa Sensing which allow such a high degree of confidence, maybe you should present your discoveries to the scientific community.
Lastly, on the "scientific" part, Channel state information, also known as CSI is not a mysterious technology available only on a few shady Wi-Fi chips. It is, as written in the DensePose paper "the ratio between the transmitted signal wave and
the received signal wave".
On the "Github repo" part, your project is badly organised. You seem to rely on AI for the organisation of the files/folders, which shows. The code is badly organised, and, as someone pointed out in a previous issues, the tests are non-sense (in fact, they are not even tests).
Your Readme is a freaking book, the documentation misleading and finally, which is I think why most people are sceptical about your project, you never present any real use of your program in real life, with the results it gives in real condition and real terrain. Yeah, your AI generated fake values for your fake AI generated tests looks shiny and all, but, have you even tested your product ?? You have an API, auth system, docker, and all and it's supposed to work on an ESP32 ?? How are you supposed to even flash your program on the ESP ?? With the power of love and friendship ? The ROM of this micro-controller is so smol you could not even fit 1% of your code on it. (the README is badly organised, I followed the "table of content" but the AI putted the ESP building process above everything and never mentioned it after, the code for the ESP is anyway, from my point of view, bad, and I don't understand why you would need FreeRTOS for something like that)
Maybe I'm wrong and I'm just a sceptical moron, but, to me you don't seem really knowledgeable on the topic of IT, as you don't even seem to be able to correctly cite a reference or to search on the internet for what "CSI" is. You just sell overpriced AI formations to desperate people and I think this repo is just an ad campaign for that, as most of your other projects.
If you truly believe this project and code is fully functional and could save life (as you seem (or your AI seem) to present it this way), you are either way smarter than me (I'm not really smart, it's not really hard) or really delusional. And I'd gladly be the wrong and stupid one.
And I could also talk about the fake Discord invite link, the fake support e-mail (I checked, there is no TXT or dkim records registered for this domain name, so there is no e-mail servers configured, or at least correctly configured) at the bottom of the README file, but, well... I guess you got the picture.I, personally, don't think there will be a better time for researchers to make so much money in a few years in any future of LLMs.
Tigebeetle devs spend 90% time working on stability, safety, tests and so on. They don't need new features, they need reliable software. Their database is pretty simple in terms of features and their goal was always stability and speed. Bun devs spend the majority of the time adding new features.
It takes like 5 minutes to spot garbage PRs manually. LLM can flood you with a wall of text where only half of the stuff make sense. Also, they can't really spot bad architecture. It's a compiler in an unpopular language, don't forget that.
When you search, Zed opens a new tab, which I hate. Sometimes I just want to have a quick glance at some code and close the search using escape.
Telescope style search in vim, helix or JetBrains tools is so much better.
One pharmacy shop that sells generics or unlicensed casino can make tens of thousands of dollars per day. So even one week is enough to make a lot of money.