deforciant

github is fine, the package was only pushed into pypi directly

finally a good alternative to e2b. Minor nit - it would be good to also have a screenshot in the docs on how to inspect what agent is working on or how to debug if its stuck

as a primarily backend developer I find cursor and chatgpt/grok (for more compelx components) totally amazing. I can finally build UIs that I want for my projects :) I think I have good taste (lol) I just could never spend those hours and days polishing.

Now I can ask it to do some frontend while I focus on backend in the meantime.

We just need the sales agent now.

going to try on my websites!

I always thought that fine tuning is more like getting a style rather than memorizing information word to word or at least the facts. What are the next steps to ensure that it doesn't start pulling info from the base knowledge and reference the docs instead? How long does it usually take to train? 10-15 minutes on what doc size?

happened to me after riding maybe five times on MT-09 :) Since my iphone was a bit old anyways decided to buy a new one and this time also get the apple insurance just in case. For navigation I now use Beeline. You need to get used a bit more for the way it gives instructions but it's also way less distracting than having a phone on your bike.

Ref: https://beeline.co/pages/beeline-moto

have you tried other models to generate embeddings? I am going to that direction too to create an additional layer of helpers for search. Also, thinking if the document is not too big, it might fit into the initial context with the prompt

Didn't want to sound disrespectful, I did like the UI and liked the idea of self-hosting. Regarding fork vs pr - just putting myself into their shoes I understand why there's probably no will to make the self-hosting easy and potentially make it a bit harder than it should be :)

the problem with cal.com "open source" self-hosting is that they have made it quite difficult to run yourself. For example this https://developer.cal.com/self-hosting/docker actually doesn't provide docker images but you need to build it yourself because for some reason frontend needs hardcoded hostname. In no other app I have seen such limitations :) Also, an older version from a year ago just stopped working, couldn't fix it, couldn't update it either :D

It would be good if someone made a fork with fixed setup and docker images for self-hosting :)

Paying for copilot :) at least in go it’s great to write tests and sometimes some smaller functions :) totally worth paying for it, even from your own pocket if the company wouldn’t allow expensing it

It's great actually, you can run it with pretty much no maintenance overhead. I have been using it in prod in multiple companies for years now

Could you please split it into multiple tickets that we no bigger than 3 points

I self host a ton of things! :) it's really much less hassle than people think. I started with Docker compose and eventually started using my side project https://synpse.net/ for it as it just helps to move things around and update things remotely. I just wish more tools embraced 12 factor app style deployment :)

if you are using regional load balancers or serving traffic directly from nodes then you would be fine :) "only" global LB failed

https://linear.app/ is also down

Looks interesting and installation steps seem to be straightforward, will definitely try it out in my stack!

Mostly good test coverage, uptimerobot, sentry.io and nodered to continuously run various scenarios :) also, get infra from well known cloud providers

GCP console is not working too https://console.cloud.google.com/, however at least the services are still running :) phew

I use similar stack too :)

- GKE kubernetes - Managed Postgres (CloudSQL) - GCS buckets for file storage - Cloudflare for DNS - Countour for ingress - Keel for automating deployment updates - Mailgun - Sentry (errors) - Node-RED various little automations such as healthchecks

Planning to introduce Elasticsearch too, so far I have been testing the operator and it seems to be pretty good quality.

From maintenance perspective GKE is great, as long as the bills are paid, no need to login there pretty much ever. As a one man company this means a lot, I try to never spend any time on ops.

I have it connected to 4 accounts with a lot of data/events, over ~3 years nothing happened. I did encounter crashes initially due to some nvidia driver issue :| and another time due to my ram stick, otherwise it's more stable than macos.

Didn't want to provide spoilers :)

I would recommend these scifi books https://www.goodreads.com/book/show/25499718-children-of-tim...

And https://www.goodreads.com/book/show/40376072-children-of-rui...

Lots of fun reading them, great author :)

Yeah, hate slack as well. I'm working on 16 core/32gb machine and it's still slow, switching between workspaces takes ages and sometimes it completely stops working. The only way then to fix it is do ps aux and kill a bunch of processes... I really wish they paid someone to rewrite their app!

Totally agree. Currently working on a public transport system and constantly pushing not to collect names, surnames and other details when it's not absolutely needed (in some cases it needs to know when discounts are involved). So far so good, I hope I wouldn't even need to raise this points.. Company is a good one, no plans to ever sell or monetize data but what if we ever lose the data :)

I think it's just took us too long to write the product as the scope was really big:

- CLI/UI.

- Main backend for storing projects, user accounts, managing pull requests, forks, runners, deployers, loadbalancers.

- Data backend (dotmesh).

- Auto provisioning of VMs with jupyterlabs running and data synced to GCP, AWS

- Runners that configure environment, install dependencies open up tunnels so users can access them and start working.

- Optimized machine imagine builds so the startup takes ~1min (some of the docker images like jupyter lab are very big)

- Model packaging into docker images.

- Model metrics capturing (a proxy that runs as a sidecar and intercepts requests) and then attaching relevant classes for your models.

- Kubernetes operator to deploy the actual models. User didn't have to worry about creating deployment manifests, services or ingresses (they wouldn't even care about docker images). They would just say which model to deploy and they would get a URL. Models could be deployed in a k8s cluster built from nodes with spot instances so would run pretty cheap :)

- Last component that I worked on was probably one of the most fun - an inference router that could allow canary deployments for models and also shadow deployments where traffic is sent to many models at once but responses are taken only from primary. We got a really nice UI for this as well where you could drag sliders around to configure % of traffic and so on. Unfortunately never managed to write docs for this.

- Terraform to wrap everything and deploy to GCP/AWS.

Our team was always quite small so we were stretched thin. In the end sales were going well as well, probably 6 more months and we would have broken even and then profitable :)

Hi, one of the engineers who created dotscience here. Customers didn't insist on open sourcing anything, we did have some open source components but I don't think they cared about that :) Regarding tracking usage - usually it was just many conversations with customers and having them on our Slack channel. Solutions engineering - mostly development team would be helping with writing anything specific that they need. On the SaaS side we had a lot more analytics, used segment, intercom and internal "audit events" to better understand what's happening.

We also started "Git for data" several years ago but since then pivoted to data science/ML tooling (https://dotscience.com/) by building features that people actually want on the original product. Since then the "git for data" accounts only probably for 5% of the total functionality :)

I guess "Git for data" is not very useful if you don't have the whole platform built around it to actually use the features. We mainly use it for data synchronization between the nodes and provenance tracking so people can see what data was used to build specific models and to track how the project evolves itself without forcing people to "commit" their changes manually (as we have seen that often data scientists don't even use git, just files on their Jupyter notebooks).

Used it many years ago and I must admit that while it's easy to start with you can end up with super weird bugs down the line where the only option can be to fork and fix it (after/if you find the issue) :) wouldn't use it again when there are maintained alternatives. Nowadays I just write these integration tests in Go since quite often it's handy to use api client libs to verify some data or prepare some fixtures.