Somewhat off topic, as someone who hasn't used PostgreSQL and only has experience with mysql/MariaDB... I've never liked writing queries with numbered parameters from an array with placeholders like $1 in this example. I find them much easier to read and debug when I pass them with string keys, basically:
`UPDATE t SET x=:x WHERE 1`
`{x:42}`
I found that the original node-mysql didn't even allow this, so I wrote my own parser on top of it. But I don't see this style of binding used in examples very often. Is it frowned upon for some reason?
A sometimes easier solution now in TS/JS is to use a simple template interpolation function (template tag) to inline the parameters and let the library autonumber them.
const x = 42
const id = 'example'
const { rows } = pgquery`Update t set x = ${x} where id = ${id}`
The pgquery function can convert that into the $1 and $2 that Postgres expects, but the source code is a little easier to read and has named parameters.
Of course, it potentially makes debugging the query from the database side a little harder because the query itself in its running form is still going to show the $1 and $2 placeholders so you'd have to count "holes" to figure which is which when trying to grep which source line is generating that query. I know that's why some frown on this template-based auto-placeholders because they want the code to better resemble the queries as they run in Postgres.
(Also yeah, it might be nice if Postgres also supported named placeholders like some of the other SQL databases do.)
PostgreSQL uses the format $1, $2 in the protocol, so I think it's just that nobody has bothered to implement named parameters in clients.
In another style, postgres.js uses calls such as sql`select * from t where id = ${variable}` (which is safe because it's a tagged template, not string interpolation).
Clorinde does this. It lets you write raw sql (with keyword arguments) and generate strongly typed Rust API (that deals with things like Option for nullable columns, etc)
This is basically how we do it in .NET. With Dapper it’s particularly neat sometimes because you can just pass an object that you were using anyway, and it will match parameter names to its properties case-insensitively.
I.e.
Query("select * from MyTable where Id = @Id", myEntity)
The idiom is to use anonymous objects which you can new up inline like “new { id, age = 5 }”, where id is an existing variable that will automatically lend its name. So it’s pretty concise.
The syntax is Sql Server native (which supports named params at the protocol level), but the Npgsql dat provider converts it to PG’s positional system automatically.
Ah, yeah. I spent the early 2010s writing front-ends in AS3, so imagine how that turned out. I wrote my own event system too when I was forced to head to javascript, but in the end I mostly just used jquery's, and it's still what I use. I agree the event-driven paradigm leads to sloppy code, but static event names are enough of a clue to what's invoked most of the time, even in relatively large projects. And most things can sensibly just be promisified now anyway, besides user interactions.
I thought it was funny that you wrote this way back when:
>> I've often seen projects where I think "what talks to what and how? What is the separation of concerns and where does this code live?"
The color lightening/darkening is new to me. I have a bunch of older sites that still accomplish the same thing with Sass and Compass, but the Compass toolchain has been fiddly to keep running. Nice to see that as a new creature comfort.
As right as this may be, it elides the crucial difference between asking LLMs and all the other methods of asking questions you enumerated. The difference is not between the quality of information you might get from a friend or a blog versus an LLM. The difference is the centralization and feeding of the same poor quality information to massive numbers of people at scale. At least whatever bonkers theory someone "researches" on their own is going to be a heterodox set of ideas, with a limited blast radius. Even a major search engine up-ranking a site devoted to, like, how horse dewormers can cure covid, doesn't present it as if that link is the answer to how to cure covid, right? LLMs have a pernicious combination of sounding authoritative while speaking gibberish. Their real skill is not in surfacing the truth from a mass of data, it's in presenting a set of assertions as truth in a way that might satisfy the maximum number of people with limited curiosity, and in establishing an artificial sense of trust. That's why LLMs are likely the most demonic thing ever made by man. They are machines built to lie, tell half-truths, obfuscate and flatter at the same time. Doesn't that sound enough like every religion's warning about the devil?
But nothing has changed there. People have been posting intelligent-sounding gibberish on social media and blogs for years before LLMs.
The problem with centralisation isn’t that it gobbles up data. It’s that it allows those weights to be dictated by a small few who might choose to skew the model more favourably to the messaging they’ve want to promote.
And this is a genuine concern. But it’s also not a new problem either. We already have that problem with new broadcasters, newspaper publications, social media ethics teams, and so on and so forth.
The new problem LLMs bring to human interaction isn’t any of the issues described above. It’s with LLMs replacing human contact in situations where you need something with a conscience to step in.
For example, conversations leading to AI promoting negative thoughts from people with mental health problems because the chat history starts to overwhelm the context window, resulting in the system prompt doing a poorer job of weighting the conversation away from dangerous topics like suicide.
This isn’t to say that the points which you’ve addressed aren’t real problems that exist. They definitely do exist. But they’ve also always existed, even before GPT was invented. We’ve just never properly addressed those problems because:
either there’s no incentive to. If you are powerful enough to control the narrative then why would you use that power to turn the narrative against you?
…or there simply isn’t a good way of solving that problem. eg I might hate stupid conspiracy theories, but censoring research is a much worse alternative. So we just have to allow nutters to share their dumb ideas in the hope that enough legitimate research is published, and enough people are sensible enough to read it, that the nutters don’t have any meaningful impact on society.
I think you're right. And it's going to be loads of fun to watch.
Not go say there haven't also been very good coders who weren't outsourcing anything, who still got out over their skis with stuff they promised on Kickstarter. I worked on Star Citizen and saw the lure of inflating project scope, responding to the vox populi, go to someone's head in realtime. Where they could still at some point conceivably have done what they had promised if they could just resist promising more stuff.
I find it odd that industrial designers wouldn't have a firmer grasp on what was involved in shipping a product than coders do, since code seems much more prone to mission creep than a physical product would be. But I totally agree that if you're used to outsourcing the build phase of whatever you do, AI is going to be the ultimate mirage.
God bless the Ruffle project, but it's so frustrating that they've covered almost everything in AS3 except the NetConnection class (and the .connect() call).
Lots of wonderful single player games were made in Flash, and it's awesome that there's a way to play them again. But almost all of my work was multiplayer or relied on amfphp or other Flash versions of XHR to draw in data for levels, multiplayer, music or graphics after my engine loads. I still have all the server code... but all we can resurrect still are games that are entirely self-contained. That's still alright but it relegates Flash to a museum.
Hi, one of Ruffle maintainers here. AFAIK, we do have most of NetConnection API implemented; but direct socket connections are just impossible in browsers. The games should (hopefully) work and connect when run via the desktop player. We also implemented socket emulation in the browser via WebSockets, so they should also start working there if you put a WebSockify proxy on your server (no need to touch the game server code).
Hi! You have done amazing work, and I'm ever grateful to your team for keeping AS3 alive!
I used sockets in some of my multiplayer games, but that's not where I ran into problems with Ruffle. Since those games only upgraded to sockets after an initial HTTPS connection, I haven't even gotten to the point of trying sockets yet. I mainly just used NetConnection.connect() for routine API calls, not to open a socket. AFAIK .connect() didn't open a socket, although I guess it had some two-way capabilities with Flash Media Server, but that's not how I used it. I just used it to initialize the NetConnection instance with the URI of a server endpoint that could receive AMF messages (usually translated on the backend with AMFPHP). I don't think it really left any sort of connection open. After that, you'd just make RESTful calls over that connection using netconnection.call(...args), and could send complex objects - even SQL result sets - back and forth without going through JSON or XML. But it was just a bunch of HTTP calls sending that data in Flash's own serialized format. You'd listen for NetStatusEvent or SecurityEvent to handle the results or errors. No sockets were involved. In conjunction with AMFPHP it was basically like a URLRequest without any structuring or destructuring needed to parse the results into AS3-friendly data types.
It would be amazing if only the RESTful kinds of NC connections and calls could work again through Ruffle, I think it might be all that's stopping my old games from running!
As far as I've seen, Ruffle never even makes the call out to the server... so at this point I don't think it's a serialization issue although some of what's in that list could potentially cause problems. The Ruffle compatability docs still say that NetConnection has 90% coverage... except for the .connect() call itself, which kinda makes me wonder why bother covering it at all?
That documentation, for stubs, can be somewhat misleading. It just looks for the presence of an avm2_stub_method function call anywhere in the method, which may mean a method that's entirely a stub, or as is the case for NetConnection.connect, a method that is stubbed under specific conditions. NetConnection.connect is stubbed for specifically non-null, non-http commands (generally this is RMTP/RTMFP). See https://github.com/ruffle-rs/ruffle/blob/df11c2206bc6be0a329...
Yeah, it's weird but I have an initial API call near the start of a program that makes a NetConnection.call() to an http address. The program should not run at all beyond that point until it gets a result from the server, after which it initializes a bunch of client-side variables and starts the main loop. With Ruffle, I see nothing go over the wire to that http address, but it's as if the client does get a result, because the rest of the program proceeds through the function defined in the Responder and onto the main loop. But it does so as if the server returned an undefined value, so then it just starts throwing errors related to those master values being undefined. Unfortunately there was no error-checking on the client side for that call; it assumed it either got some values or it failed to connect.
Maybe for some reason Ruffle thinks it's not a plain http call. I can start a GH issue if it would help.
I mean I could decommission them but they're educational websites related to DNA and bioinformatics with interactive animations and my boss has a certain fondness for keeping them running if we can, as we used to get a number of grants that funded creating them in the first place as a nonprofit educational and research institution.
Also a Ruffle developer here, though less involved with the actual emulation and more with the JS for browser integration. I'll add to Adrian's response that instructions for setting up the websockify proxy (by the webmaster of the site) can be found here: https://github.com/ruffle-rs/ruffle/wiki/Frequently-Asked-Qu....
I assume this is because web API's don't allow such connections.
However with the source code and server code it seems like a perfect task to set an AI agent (IE. Please patch out these API's and replace them with websockets on both client and server, then recompile)
Okay. I have been through this many times. What you need to tell them is that they own the right to the finished product, that is the research, documentation, source code, and any binaries you give them. But that you will retain the right to reuse any code you find useful for future projects.
If they reject those terms, don't work for them.
I once built a project on those terms, and was paid about $120k for it over six months (back in 2008). The startup founder business guys who financed the project sold it to Fox for around $1M. It had gone viral. Fox put a team of 10 coders on it. They had my code but didn't fully understand it, so they wanted to hire me back. My rate was $100/hr at the time and Fox wanted to pay me half of that. I said I would consult with them at my normal rate, even though I don't like their politics.
They then sent me a contract which said that they would own all copyright to my code, and anything else I did while I was working for them. I told them there was no way I would sign that. If they wanted my help they could have it. Their people told me no.
I understand that they spent $5M trying to get my code to work on their platform before deciding to shut it down, without making any money from it at all. Too bad for them. It was a victory for me. If they had not been so greedy, they could have had their program and its programmer, too.
So in short, unless you are becoming a full-time employee of this company and everything you do at work belongs to them, you should never ever sign anything which gives them the exclusive rights to your code. You can give them the right to take it, re-sell it, modify it or whatever. But not the right to prevent you from using it.
And the most important reason for this is that everything you write will become part of your toolkit that you take forward with yourself to sell to new clients, to make it easier for you the next time you're asked. And reasonably if you are asked to do the same work again, you would write the same code again. So it is unreasonable for anyone to tell you that you cannot re-use your own work.
Honestly, I couldn't care less about the rights to my code in today's world. What you're describing probably really bothered me a couple of years ago. But today, I'm not even sure what programming language my next project will be in. Everything has changed so much and is changing so rapidly that perhaps in a couple of years, corporations will be worried about their huge and important products.
What if, in a couple of years, you can create your own Photoshop with video editing capabilities? Maybe that will be possible too.
For background, what I mean by my code that I saved by keeping my rights to reuse it, is basically two full front-ends, one a platform for SPAs with all the screens/dropdown/module/component architecture you can imagine (think of React, except a lot cleaner and easier to read) [originally written in AS3 and then completely ported to Typescript around 2018], and another that's a complete page-based CMS for businesses, only better than Wordpress because it has hierarchical permissions over every writable field on pages distributed over franchised businesses. Those, plus custom back-ends [originally in PHP] with auths and modern security to back them; database schema to support those; a full set of hand-written UI components and SCSS; a complete form rendering and validation language in my own DSL that works on both platforms; a NodeJS version of all of this; and lots of other stuff... Since I've written these all for various clients over 25 years and cobbled them together into my own platforms, it makes it very easy for me to spin up a new app or service or site. One that actually works and doesn't have any unknown security holes or garbage code.
Okay, so I did an experiment with Claude a few weeks ago. I asked it to write one fundamental piece of my SPA framework from scratch, without looking at it. The piece that manages memory, creates and disposes of current screens and their sub-components. I spent about 10 hours coaching Claude until it was able to write something quite similar to the 500 lines of code that I had written that sit at the heart of that system. Questions were like, "hey, don't you think maybe you should create a cleanup function for that component before destroying it?" You know, basic stuff like that.
Its code was crap.
Every time I corrected it, it said, "oh, you're right! That's so smart!" But at the end I had to debug the whole thing myself. And this was without even trying to tie anything to a back-end service or API.
So what if, in a few years, this is unnecessary and anyone who wants Photoshop with video capabilities can just will it into existence by asking an LLM to write it? Maybe that'll happen. I'll still have my proprietary frameworks and, unlike that thing you vibe-coded, they're battle-tested and I know everything they do. That's why the advice I'm giving to the OP is solid.
Every piece of code you write yourself is something you fully understand and it gives you the power to do more on top of it the next time. Saying that it doesn't matter because LLMs will take over, and no one will need to code, is just some kind of resignation, or laziness, or solipsism, or wanting to watch the world burn, or whatever. But whatever it is, it's not useful work and it won't profit the person who is writing code now and wants to keep their rights and not get screwed.
When people are sandboxing new vibe-coded copies of Photoshop - and asking an LLM why the colors are all messed up, which it can't see or understand - someone will still be asking for us to come make things and fix things.
At work, I meet many people with similar experiences. But the number of people who are able to use new tools is gradually increasing. I myself spent many hours learning how to make my AI work and make workable code. Moreover, I treated it as something important and new. So much so that I began to view my own old code differently. Not as something with sentimental value. But at the same time, it can easily become obsolete in the face of new realities.
I don't mean to devalue your feelings about your code. But I myself I went through devaluing my own work. Perhaps people who did carpentry in the old days treated their tools with care, creating beautiful engravings for the hard-polished handles. But now you can saw a board with a power tool, and we have lost the culture of these craftsmen.
AI is changing the attitude toward code. It may sound painful, but the value of old work has diminished. On the other hand, the main goal of developers has not changed. We're still solving problems, not writing code for the sake of code.
Like, it's quite nice looking, and the design is clean. But I wish there were something on the page that made me say "oh ...how did he do that?" It could be something very subtle in the white background, or it could be some small game in one of the blog link / grid positions. The positions make for very dense reading, and are named in very technical ways. Which is okay, but some excitement and levity is what is called for.
As a veteran web designer since 1996 until now: I think the photo at top is very powerful, actually rather brilliant, and it is one thing I have never seen before as a personal website header. It's fresh, it projects a lot of confidence and personality, and that is 99% of your sales pitch.
How hard would it be to sell a solution that makes it easy for a consumer to set up on-site recording? Ship a small box loaded with Tailscale and some software that connects to cameras over a LAN, and runs a webserver that allows user logins through a web interface. Nothing needs to go into the cloud. Yes, then you sell it once to a customer and that's it. No subscription or planned obsolescence. Fine, so factor that into the price. Make your money and go on to do other good things.
It’s called an NVR and there’s a whole industry of companies catering to this, though you rarely hear about it in the news. There are plenty of consumer options in the space too.
They have been selling NVR based camera systems for decades. It's clunky. It takes a network savvy person to open up their home network to allow remote access. It takes an even savvier person to not do that in a way that guarantees getting their network pwnd.
Having a cloud based solution from an ethical company would be the consumer friendly solution people are actually wanting. Lots of people are willing to spend money to make problems go away.
I know businesses that have these setups and outside tech support to maintain them. I've also seen them have all kinds of issues when routers are replaced or they change ISPs. That's why I was saying a company could sell a box preloaded with Tailscale and a custom installer that walks a non-technical person through it. The default setup for a tailnet is pretty safe. Yeah you could have your own signaling servers or whatever, but TS usually manages to punch right through most NAT issues. They don't need a reverse proxy to login to their private webserver, although I guess you could provide that as an add-on service. They just need TS on their phone.
[edit] To my mind, the biggest hurdle wouldn't be networking to allow this box to host its own app that was accessible to the user from elsewhere. The hurdles would be things like lack of "smart" reporting / facial recognition, backup power, backup connectivity, etc..But in theory, a repurposed smartphone as the platform could solve the backup power and connection issues.
This isn't an inherently unsolvable problem. Peer-to-peer file sharing and video calls have been able to work around it for ages.
The same approach could be used for cameras - see for example Home Assistant's remote access. Sure, you'd still need a cloud-based STUN-like discovery service, but a small one-time fee should easily cover operating it.
Right..Or instead of STUN/TURN just use Tailscale for now. I think the reason no one's packaged this into a slick Ring-like plug-and-play probably comes down to corporate greed and how hard it is to raise money if your intention is to start a business that doesn't have ever-expanding verticals. Like, this is a set of solved problems. They just need to be smoothed and packed for the user.
You seem pretty sure of yourself. So when will you be releasing this product that you claim is such low hanging fruit? Right, now you know why this product doesn't exist.
He just explained why. Because packaging, QA, setting up a storefront, customer service, the sum total requires significant up front investment to get off the ground. Good luck raising money when your pitch is "we won't be greedy and do the things that could make even more money".
Or was your intent merely to taunt him for failing to be independently wealthy?
Like, thank you. Obviously. This is why I don't want to start a public facing business and why it's almost impossible for a person with some good ideas and a modest savings account who could build something better to do it without putting themselves in a compromised position by taking investment. If you go it alone, you basically have to put your entire net worth on the line to see whether something works, and then the second it takes off, God help you you are going to be litigated or bullied into the ground. But I still kind of have some of that old 90s / early 2000s faith that I will one day hit upon the Big Idea that I can code and bootstrap myself, and turn a profit from day one when I launch it, and never need investors. I doubt a home camera system is the one. But I have a whole wall in my office with taped-up post-its and index cards and papers, each with hand-written startup ideas. Any of which I could conceivably code and profit from if I wasn't afraid to spend 6-12 months on it and thought it could survive the regulatory environment and everything else that might come with releasing it onto the world. And that's not my job - I just keep those up there and add to them for inspiration. I just want to make shit, not deal with the business of navigating the whole corrupt world of funding and kosherizing it.
> Any of which I could conceivably code and profit from if I wasn't afraid to spend 6-12 months on it and thought it could survive the regulatory environment and everything else that might come with releasing it onto the world.
The problem is, you have to be young and dumb and oblivious enough to think that your idea is golden, while also being old and wise enough to be able to implement the idea. You don't want to wake up one day, a decade later, and someone's independently thought of the same idea, and gotten rich, and you're still driving a taxi. My email address is on my profile page. Email me.
Friend, while I was driving a taxi in 2001, I conceived of a system that would let anyone directly order a taxi driver from a pool of drivers who signed up through a central SMS messaging system and updated their zip code when they were waiting for a fare. The main problem with that idea was that it was completely illegal because it was outside the licensed taxi system.
When Bitcoin emerged, I wrote a gambling site. That also was illegal in America, so I kept it closed to the US but tried to get my original games licensed in Nevada, which was a fool's errand since it takes $500k just to get them to look at a game and there's a 3 year waiting list, mostly Bally. And look where we are now with online gambling.
The lesson of my life isn't that I need ideas with a bigger moat. It's that being able to code my ideas well is meaningless compared to having half a billion dollars to buy off a legislature. I'm a coward, I guess, because I never wanted to break the law. Now I live in a timeline where every major company in those two sectors achieved market dominance and legality because the people who started them were willing to flout the law, raised enough capital and fought off lawsuits long enough to bribe their way into legitimacy.
I have a fantastic idea for an AI service, too, and it wouldn't be hard to implement... but it will almost certainly raise dozens of legal issues until someone with more balls than me comes along and just does it. Money is nice but I don't need that kind of trouble. That's why those ideas stay on the wall.
hey dude, it's a free idea, you're more than welcome to it. I just thought of it a couple hours ago as I was writing that. I thought it was pretty good - especially the part about using an old smartphone with Tailscale as the hub because it has backup connectivity and power. Maybe I'll throw a prototype together this weekend if I have nothing better to do. Or maybe you should. You could be that guy.
I never had to use a "network savvy person" to have people connect to their TP-Link or Reolink cameras at home. The cameras record to SD cards (or NVRs) just fine.
`UPDATE t SET x=:x WHERE 1` `{x:42}`
I found that the original node-mysql didn't even allow this, so I wrote my own parser on top of it. But I don't see this style of binding used in examples very often. Is it frowned upon for some reason?
reply