Achshar

I believe skills are much more than a simple markdown file with instructions. They are a very powerful script engine. How I organize it is that of course there's a markdown with instructions but I split the work in a hybrid of script + instructions. So all the work that can be deterministic is a python script api surface and all the logical or thinking work is in instructions. and agent is also instructed on how to use the api of the python helper functions. This makes it almost like a normal script but the runtime is a harness and the business logic can be any combination of code + human-level intelligence.

So I like to do all the edge case handling and validation etc via a helper function, and the agent is simply instructed to call the function to do something. It is extremely powerful and a completely different way of automating things. I am constantly forced to re-think how computers are supposed to work and its limitations.

I believe the knowledge of multiple languages brings something onto the table that having narrow language knowledge does not. The LLM will be able to better generalize a problem, apply universal concepts and avoid mistakes that would otherwise be too "echo chambery". Even as a human, knowing multiple languages has made me better at my primary language.

I am working on a vs code extension for antigravity that will let me designate one thread as a "controller" and it can spawn and chat with multiple other agents in ag. I have a separate extension that lets me control any chat agent in ag from a telegram bot. So that should ideally allow me to replace my human work of checking on agents. It should also allow me to pit claude against gemini and use low models for less smart tasks and costlier models for tasks that require more thinking. I have more or less defined my development workflow in stages where first I write a comprehensive wiki + empty test files with descriptions, then I write the code and then recursively fix the code to meet the test criteria set earlier. I want to automate this with the "controller" thread. I have come to realize a knowledge graph via wiki is the only way I am able to get AI to generate production ready stuff, otherwise its too flaky.

I feel like I am living in a bubble, no one seems to mention Antigravity in these discussions and I have not had any issues with Ultra subscription yet. It seems to go on forever and the Interface is so much better for dev work as compared to CC. (Though admittedly my experience with cc is limited).

I strongly believe google's legs will allow it to sustain this influx of compute and still not do the rug-pull like OAI or Anthropic will be forced to do as more people come onboard the code-gen use case.

I also have a small dev team of 25 that wants to move to gitlab paid model but the upfront cost is too much. We need a monthly payment plan even if it costs more than annual one because I can't justify a high upfront cost to my ceo. We're rapidly expanding and expect to be 100 within 2021.

The auto update certainly falls in the former you mean? These (older, less tech savvy) people clearly lack the imagination. That's why auto update has to be mandatory. This is again for consumer facing OS and not for the server infra.

Disagree. “If I had asked people what they wanted, they would have said faster horses.” - Henry Ford. Customer is mostly right. Not always. Use your best judgement as a business owner. Innovate where necessary and stick to customer feedback where you think it makes sense.

I use cmder on windows. It's pretty good you should check it out.

No. Just no. Don't install a library and two others just to show a tree view. Make your own with whatever features you need and just those features, nothing else. Less than 200 lines of code and one day's work for a competent developer. Don't install three libraries in your webpage just to show a tree view.

How does once check for the presence of a VM from inside the VM? Doesn't that defeat the purpose of the VM to begin with?

We do a bunch of stuff superset doesn't. Mostly related to filters and how they're implemented. We never mess with user's query. We only supply filters to it. Superset doesn't let users write optimized queries. We replaced superset for one of our largest clients and they are extremely happy with the move. This is pure js as well, nothing like superset tech stack wise.

Out of those I only have substantial experience working with Superset. We replaced Superset for one of our biggest client a few months ago. We built a ton of features in the process. My take was that they ended up meddling with the user's query which raised issues with SQL injection and performance. For example filters only going on the end of the query.

In Kato filters can be replaced anywhere. Plus we offer a ton of integration and data manipulation features. One of the biggest things that the client really liked over Superset is the ability to set up drilldowns where when you click on a bar chart on any graph you can see further details about that bar chart in a table, or any other graph. And this drilldown can go however many levels deep. We can link different reports from entirely different datasources with drilldown. I don't think that's available in any of those mentioned above and it completely changes the user experience.

We have 3 different levels of storages to avoid hitting remote. Redis cache for query, storing the results on our server and letting users edit the data as well and finally front end cache with service workers.

I think I'll start writing out the feature comparisons.

That... would be the marketing team for you. We do spend quite a bit of our time adding stuff that I don't think I've seen anywhere else but is extremely useful for some of our biggest clients.

Yes we probably lie close to Superset and Mode than we do to Tableau but I believe the data transformations, access level (sharing) and deep integration put us apart from those. Tableau's quite bit more mature than we are but we already support self hosted service, OAuth based auth integration, sophisticated user access level based sharing for all resources (reports, connections, users, dashboards, visualizations, product features, etc). We don't cost an arm and a leg either.

The target market is anyone who has any kind of data. CSV, mysql, etc. Basically Tableau but much cheaper and customisable.

We already have a few small business using Kato. They seem to enjoy that.

Looks like HN hugged it too hard. We have a limit of once every 3 seconds.

Me and My team have been working on a Looker alternative for a couple of years. Hope this is the right time to give a pitch. We as a company love to assist our clients with a free consultation in understanding their data better. This will take you to the direct demo: https://demo.katoai.co/login?email=demo@katoai.co&password=k...

I can talk a lot about it if anyone is interested.

Just go the electron route and find a way to make it snappy in-spite of electron (ala vs code)

Vanilla javascript (Yes I said it). Build a PWA and either PHP 7 or node for backend. Anything else is for you if you already have a preference.

None, go vanilla.

El.style.backgroundColor = Foo;

That works. Js automatically allows use by camelCase.

Here's a demo:

https://demo.katoai.co/login?email=demo@katoai.co&password=k...

We can really use some feedback.

Babelified code sits in another directory, I hotswap it if I think they are not on a modern browser (IE or older version of mordern browsers). So any normal Joe using chrome or ff or edge will not get a bundle. But if I'm not sure, the backwards compatible version is sent instead. So I think I can claim that there's no bundle since most of my users don't get one.

I don't have a ton of experience leading team's using react, angular etc but I assume you are referring to the fact that there are multiple ways of doing things in vanilla js world whereas only one way in react world. That can make things easier for teams but I believe that's a lazy excuse. Choice is never a bad thing and it's literally the job of a tech lead to establish conventions, tell devs what flow to follow. If that turns out to be too difficult then it's not the code or framework's fault. Staying strict about how to do things is a concept that exists irrespective of framework or no framework.

My only advice would be to stay consistent, find patterns and genralize stuff. I do see the irony of making a framework of my own in the process of doing all that. I just embrace that. Everything is exactly how we want it and we know each line that executes on the machine. Makes development a breeze. There is nothing that react can do that vanilla js can't with reasonably same amount of effort. But stay open-minded. What helped me was that I worked with angular first to see how not to do front end (angular.js). I also regularly check out how react, angular, Vue, etc handle the same problems that I have. That usually gives an inspiration.

In the end it's hard to believe how fast JavaScript can be even on smaller devices.

Es2018 all the way. Web workers, classes, Isomorphic code, generators, async await, etc with a splash of Babel Devs have never been happier. Everything just works and online documentation is Rich and plentiful.

Plus as I said, core logic works on both server and client and we have offline support as an added bonus.

I have a team of 4 devs working for me. It took them a week to get up to speed with and work with full efficiency. Everyone knows JavaScript. It's nothing new, we're just using it without any added syntax. Everything is familiar.

I find myself defending myself a lot these days here. I use vanilla js. Never had any trouble, I literally have no bundle, no dependencies, the amount of code I have to write is basically the same either way, no trouble syncing state with DOM either. Have done so in two moderate projects (40k, 15k). Everyone I meet looks at me like I'm crazy. But in the same breadth say the site feels so smooth and responsive. No shit.

Catch being you he to learn how to write js but that's true for any framework as well. And frameworks have smaller shelf life anyways.

I always find it curious that almost no one is talking about not using a framework to begin with. I have been writing complex UI with vanilla js for some time now, never had any issues or took longer than I expected to get a job done.