ripperdoc
And it's a darn messy problem to try and solve even in small actionable steps, because I think most of the choices that lead to bloat are choices that make sense at that point in time. E.g. "use a dependency instead of code it myself", "use AI instead of thinking through every angle", "write 2 unit tests instead of the 20 that would give full coverage", "don't write extra tools to measure the speed of everything, it seems fast enough". Taking the route that minimizes bloat can be very time-consuming and demanding on the individual average developer. And any solution we come up with will not give us security guarantees - but any solution that moves the average one point in the right direction is still a good thing!
I sometimes find these type of question fall into old tropes like "it's Javascript's fault, better go back to C". But I think that is a fallacy. Javascript in a browser can easily run millions of ops a second. The big time offenders come from elsewhere, most likely network operations and the way they are used.
Some things that I think would help (and yes, some of them exist, but not as mainstream tools for the common tech stacks)
Tools that analyze and handle dependency trees better. We need better insights than just "it's enormous and always change". A tool that could tell me things like: - "adding this package will add X kb of code" - "the package you are adding has often had vulnerabilities" - "the package you are adding changes very often" - "this package and pinned version is trusted by many and will not likely need to change" - "here are your dependencies ranked by how much you use them and how much bloat they contribute with" - "your limited usage of this package shows that you would be better off writing the code yourself"
Tools that help us understand performance better. Performance monitoring in production is a complicated task in itself (even with stuff like Sentry) and still is poor at producing actionable insights. I would want tools that tell me things like: - This function you are writing is likely to be slow (due to exponential complexity, due to sequential slow/network operations, etc) - This function has this time distribution in prodution, as reported from your performance monitoring system - There are faster versions of this code (e.g. reference jsperf) - This library / package / language feature has this performance characteristic - Here are outliers in the flamegraph generated by this function or line - This code is X% slower than similar solutions - Making developers load their apps at the average speed users access them (e.g. throttling) - Bots that can produce PRs to open source projects to find common low hanging fruits in reducing complexity or increasing performance
Tools to evaluate complexity and tech debt over time: - Can a tool tell us what the lifetime cost of a solution is? How can a development organization make tradeoffs between what's fast to get out the door vs what it takes to maintain over time?
But it just hurts my programmer soul that it is somehow more effective to record an app, that first renders (semi-)structured text into pixels, then record those millions of pixels into a video, send that over the network to a cloud and run it through a neural network with billions of parameters, than it is to access the 1 kilobyte of text that's already loaded into the memory and process locally.
And yes there are workflows to do that as demonstrated by other comments, but it's a lot of effort that will be constantly thwarted by apps changing their data-structures or obfuscating whatever structure they have or just because software is so layered and complicated that it's hard to get to the data.
location ~ ^/([a-z0-9_-]+)/ {
proxy_pass http://internal-$1:8000;
}
We pickup the service name from the URL and use it to select where to proxy_pass to. So /service1 would route to the docker container named internal-service1 . We can reach it via the name only as long as Nginx is also running in Docker and on the same network.The main thing I want to improve is to not use one big compose file for all services, as it would be cleaner to have one per service and just deploy them to the same network. But I haven't figured the best way to auto-deploy each service's compose file to the server (as the current auto-deploy only updates container images).
We're startup building a platform using conversational AI to enable practice, recruiting, coaching and tutoring of employees, students, and individuals. Use cases such as sales, customer support, patient care and more. We have also been given a grant to help those that struggle to use and understand digital government services.
We are looking for experienced engineers to form the core of the tech team and evolve our beta product. Be prepared to solve whatever needs solving, but the focus is LLMs, ML, optimize audio streaming, latency and optimizing Unity apps across web and other platforms.
Stack: Generative AI, ML, mixed reality, Unity, WebGL, iOS, Android, WebRTC, Python, React.
Culture: Honesty, teamwork, and freedom to work and live the way you want.
https://thehub.io/startups/fictive-reality or [email protected]
Such as the wind not matchig with the lack of tree movement, the way the camera moves, the repetitiveness of the walking sound, how the wind sound doesn't reflect how it would be blocked and dampened by buildings and snow, how snow doesn't pile up, how the tires look blocky, etc. (and the final challenge, hold out your hand and look at the snow flakes ;) )
The second shortcoming is that that I have to switch over to ChatGPT and it's messy to give it my existing code when it's more than just toy code. It would be a lot more effortless if it was integrated like Copilot (if we ignore the fact that this means sending all your code to OpenAI...).
Still, it's great for boilerplate, general algorithms, data translanslation (for small amounts of data). It's a great tool when exploring.
Don't think that requires blockchain per se, or even human verification. It would work quite well just for me to assign my trust to various identities (Github accounts, LinkedIn accounts, etc) and for that trust to be used when ranking or filtering content.
There could be a paid model, or you could imagine a credit system where you also offer your own expertise and time to others in equal measure. That could still lead to finding things to work together on, but could also lead to learning, consulting gigs or just networking - with the added benefit of being immediately useful at work. But that maybe already exists somewhere?
(unfortunately, the trimmed video won't get the same metadata, so I also needed to use exiftool -TagsFromFile oldvid.mp4 -all:all newvid.mp4 )
I'd guess every percentage point less bad outputs costs more than the previous, because it entails testing the output on more or better trained humans, or it entails using humans to filter the training data better.
I think in the end, knowledge in the collective human sense means not that you are just smart, but that you can judge, filter and trust sources - and even then, you will easily find n+1 acclaimed experts disagreeing on something fundamental. So being right, either morally or factually, isn't a deterministic thing either. Of course, humans aren't deterministic, but we can reason about what to say and not to say depending on the context.
Of course, the nature of running various commands on virtual machines and shells is inherently messy, but GHA could have done a lot to hide that. Instead I feel like I'm forced mix YAML, bash, Powershell and various higher-level scripting languages (that came with the projects) in an unholy concoction that is hard to get right (return codes, passing values and escaping directly comes to mind) and that is even harder to debug, due to the nature of running somewhere else (act helps, a little, but it doesn't properly replicate the GHA environment).
I kind of wished I could write all my workflows cross-platform from start with some well known but fullfledged scripting language. (Which of course I could, and just use GHA to call that script). What options are out there to make this whole thing less brittle?
a) User has to wait many minutes for email
b) User never finds the email
c) User clicks to get another email, invalidating the first, then clicking the first
d) User tries to re-use old sign-in emails to get in again many days later
e) User gets confused as to whether they are supposed to have a password or not, or other forms of sign-in vs passwordless
At best, these problems amount to some support work and user friction. But in the worse case, for the not so tech-savvy users, they become a complete blocker to using the product.
Of course, we cannot track deliverability when the emails are sent by Firebase so we can't really see how often there are problems. Are we just unlucky, missing something obvious or is passwordless a poor bandaid on the auth problem (hey, webauthn?)
Issues like runaway compiler threads, slow response times, OmniSharp frequently losing the mono-path and requires restart (this is some config issue and interaction with Unity, but could have been handled automatically).
It's sensible to improve the C# experience on VS Code, but not saying the way MS is doing it here is the best way.