There are quite a few competitors in this space, trying to figure the best way about this. I've been recently playing with the Jentic MCP server[0] that seems to do it quite cleanly and appears to be entirely free for regular usage.
I used langchain in one project and I do regret choosing it over just writing everything over direct API. I feel their pain.
It had advantage of having standardized API, so I could switch local LLM to OpenAI and just compare results in a heartbeat, but when I wanted anything out of ordinary (ie. get logprobs), there was just no way.
20 year experience with software development. Experience with various systems development (configurable workflow system, logistics system, printing/voting tracking system, internal tools etc.).
Past few months I worked on RAG system (Python, FastAPI, local LLMs, vector databases).
Experience in international teams (worked for companies in Switzerland, USA).
Looking for IC position.
Location: Budweis, Czechia
Remote: Yes
Willing to relocate: No
Technologies: Full stack - C# + Asp.net or Python + FastAPI, React + TypeScript. Willing to do other sensible stacks.
Vehicle by definition can't be connected to the house constantly. I can imagine this lowers need for house battery size, but not need for it's existence.
House power consumption is very random.
There is typically good connectivity between houses. That means even if your EV isn't home, the other EV's in your street can send your house a lot of energy.
Unfortunately anti-islanding rules from power companies generally disallow you using the power lines between your house and a neighbours while the grid connection is disconnected elsewhere.
These rules could be adjusted though - although it would take a lot of systems design work to ensure power system stability and re-synchronizability even with every possible combination of islands.
It's more about safety than reconnection: when repairing lines, it's much more manageable to "lock and tag out" the upstream side than all the distributed generation, especially in emergencies.
Any lines being worked on will be shorted (ie. all conductors joined together and to ground).
As long as that is always done, islanding doesn't present any human safety concerns.
That is normally done anyway, because plenty of utility breakers will automatically try to reconnect every few minutes (allowing some grid scale failures to repair themselves with no human involvement).
But when the vehicle is connected, the user is typically at home. So there's a convenient relation there.
House power consumption is random because it's not designed to be predictable. It's trivial to have a washing machine and heating that prioritize energy consumption whenever the EV is connected, or grid energy is affordable.
Unless you have more than one person in the house…
But in general, yeah, when you _need_ the battery, maybe you just need to figure out that you don't need to drive that day/hour.
The other advantage of a car, is that it would allow you to bring in power "from the outside", go to somewhere where the grid is still working, charge up, then come back. Of course, you'd hope to be back on power before this was needed!
Of course! Is there's anything in particular you're interested in or a topic you want me to cover let me know. This tech is powerful by itself. Hoping to empower people with knowledge of all this works too :)
By now, making UI with (by now not completely) SPA frameworks specifically made for that task is just better developer experience. I won't go back to pretty much html string concation via templates. Why do people keep pretending it's better in any way is lost on me.
Using a traditional templating engine is not treating HTML more as a string than React based frameworks do. Maybe even lass so, because of the separation of concerns. Traditional tenplating engines can separate part of HTML into named components without problem. Check for example Jinja2 or its clones in other languages. There is really no need to treat HTML in a plain PHP string concattenation style. There has not been for decades.
If you want something more structured data, look at sxml (see Racket or Guile). Then implement that in a library and use it in place of the default of most (all?) SPA frameworks.
It's well understood that the reason people drag in these unnecessary frameworks is often because they prioritise their developer experience over the user experience, and you're just proving the point ;)
For what it's worth, the developer experience is also highly subjective.
I remember when NextJs could not properly watch files and rebuild when files are changed, because it has a problem with emacs backup files. It would crash and the I would have to restart the watch, defeating the whole purpose. An issue exists/ed on Github, but no real interest was there to fix it. Just to name one example of dev XP that was worse.
The need to deal with whole NPM ecosystem is another point, that significantly negatively impacten my dev XP compared to rendering plain old school templates in other ecosystems.
Yeah the backlash against SPAs doesn’t make any sense. Server side rendering is fine for documentation etc. but full applications don’t want to be simulated on a server, client-server makes complete sense.
Webservers shall create and provide the readily HTML so browsers can render the website without JavaScript. Actually text-browsers should render it and also allow disabled persons using it without hassle.
Instead SPA (or more direct JavaScript) is used to force the browser to assemble the HTML and it is slow and waste resources. Creating website which create load on the client-site is bad because we’ve power on the server dedicated for this task - not so on client.
Looking back web-developers need something imperative and more direct than CGI, PHP or JSP. The initial backslash against JS was right. I sadly shipped JS.
When a powerful application is needed? Make a native application and use an appropriate toolkit (Gtk or QT).
I agree you’re right in that the current tech stack is bad. But the answer is to fix that, and I think (very) slowly we will.
JS was a terrible language but nowadays it is pretty good in some areas, passable in others, with some horror shows left in. The ecosystem and tooling are the real problems. I don’t understand why these issues haven’t been addressed by Google et al.
Native applications are just so much more expensive to develop and maintain. Given the nuances of different platforms, it’s also very difficult to keep different versions in sync. People expect collaboration as table stakes, which makes that task even harder.
I agree accessibility is a problem.
Ironically the Java applet had the right idea, as a compromise between our positions, but wrong time and maybe wrong language? Its Swiss cheese security didn’t help either.
> Native applications are just so much more expensive to develop and maintain.
Quality isn't free, yes.
> Given the nuances of different platforms, it’s also very difficult to keep different versions in sync.
Don't tightly couple applications and backend service versions (where a backend is even needed, otherwise make it all local) and this is not a problem. You should be using open (relatively stable) protocols wherever possible anyway.
Web apps "solve" platform differences by completely disregarding them and expecting users to adapt to the application instead. This does not make them better.
Quality isn’t free and native applications provide quality (reliance, performance, integration, usability).
The platform issues just moved to WebKit, Blink and Gecko. New platform issues and the web developers complain like application developers ;)
Companies favor the web usually to lower their own cost, give them control over users and being free of rules. Users pay for it. With higher hardware requirements (Electron), loss of data, loss of control and the absence of usability. And as states above, a website shall not stress my CPU or RAM.
The worst example is Microsoft Teams.
The best example is your preferred Matrix client application.
Theres about zero websites I use that I want to be "full applications". For things that should be applications I prefer native (open source) desktop programs.
If you are concatenating strings of HTML, you are basically asking for an injection attack.
There are lightweight frameworks (like knockout) that keep things simple but keep you safe with bindings, without giving up control to a bigger framework.
reply