mmckelvy

Another great use case is piping database output (e.g. psql) directly to HTML. HTML tables can be opened in a browser or directly in Excel. So all you need for a complete BI tool is a database and the command line.

You wouldn't just blindly implement what the LLM generates. You would use it more as an efficient way to go through all the necessary docs. From there you'd sanity check the recommendations and _then_ implement a solution, applying your judgment along the way.

Particularly in the AI assisted era, I'm not sure I understand why you wouldn't just roll your own auth. Learn it once, use it everywhere. Best practices are well documented and now incredibly accessible via your LLM of choice.

Shopify "backing it" means less to me than the maintainers themselves. The Remix maintainers are straight shooters and have been maintaining open source consistently for over a decade now.

I also just like their API and design decisions.

Agreed, minus the Primsa.

They made an announcement that they are merging the projects a little while back: https://remix.run/blog/merging-remix-and-react-router. Obviously things could change, but I think RR v7 will effectively be the next iteration of Remix.

My bet is on Remix (which will eventually just be React Router). I think it's just the right amount of abstraction over native web functionality with a nice, simple API that doesn't deviate too much from web standards. I also think the full stack approach just makes sense for developing on the web.

Not yet. But in the analytics case, suppose you could build a tool that collected data on your own infrastructure, allowed you to write plain SQL against a PostgreSQL database to get whatever analytics data you need, had an AI-driven text-to-SQL option so non-technical users could get whatever analytics data _they_ need, and output everything to a universal interface, i.e. a spreadsheet? No vendor flavored DSL, GUI, or workflows to learn. That product would be tough to beat. It wasn't built in the past because it was hard. But with AI and something like Tembo or Timescale, is it actually hard anymore?

Interesting. I think you're on to something here. I fully agree that a combination of spreadsheets and SQL are the ideal tools for data analysis -- not a SaaS GUI.

> Niching down, if you work in operations at a <50 person startup or SMB and your company relies on a Postgres or MySQL database, Sourcetable is an affordable reporting tool with turnkey data infrastructure that doesn’t require code or engineers to set up.

With the rise of AI, companies like Tembo that help you set up all in one databases, and tools like this, I'm increasingly of the mind that many companies should start bringing things like analytics and observability in-house. I don't see the need to pay Mixpanel or Datadog thousands of dollars per month when a self-serve solution that relies on tried and true tech is more or less at your fingertips.

The workflow I'm trending towards is a design system (e.g. Radix UI) for the bulk of the styling, inline styles for most customizations (shouldn't be too many), and then plain CSS with classes on occasion (e.g. I have an override I need to use in multiple places or an animation). The little CSS you do need can be isolated if you're using a framework like Remix.

As others have said, LLMs still require engineers to produce quality output. LLMs do, however, make those engineers that use them much more productive. If this trend continues, I could see a scenario where an individual engineer could build a customized version of, say, Salesforce in a month or two. If that happens, you could make a solid case that companies paying $1mm+ per year for 12 different SaaS tools should just bring that in house. The upshot is you may still be writing software, but instead of building SaaS at Salesforce, you'll be working for their former customers or maybe as some sort of contractor.

What did your startup do?

Oh, ok, the test and operations case makes sense. As for your questions:

1. It's basic networking tasks such as running a network drop, assigning IPs, making sure the PLCs are on the right subnet, etc. In many cases the PLCs aren't on a network at all and the IT team doesn't really know how to work with the PLCs and the OT team doesn't really know how to work with networks. Sometimes it's been easier to just add external sensors and go over a cellular network and skip the PLC altogether.

2. We use one of Ignition's modules to interface with the control systems directly. They have drivers for Allen-Bradley, Siemens S7, Omron, Modbus, and a few others. The downside is Ignition doesn't have an API, so we have to configure things using a GUI. Beyond Ignition, the other big provider of drivers is Kepware - they probably have a driver for everything, but again, they aren't really set up for use by developers trying to deploy to a Linux box. If the customer has an OPC-UA server set up, we can connect to that using an open source library.

3. What we've learned is that many customers rely on third parties (e.g. the machine manufacturer or a system integrator) to configure their system, so when it comes to extracting the data they want, you're kind of on your own. We're not industrial system experts, so this creates a unique challenge. Larger and more sophisticated customers will have a much deeper understanding of their systems, but these folks are usually going to be using something like Ignition and will already have the dashboards and reports so it's more a matter of integrating with Ignition.

I work for a YC company in the industrial maintenance space and we've been looking at integrating machine data drive and automate certain maintenance workflows. The most difficult aspects of integrating machine data have been (i) networking and (ii) translating whatever protocol (Ehternet/IP, Profinet, Modbus, etc.) the machine's control system uses into familiar formats. In many cases, PLCs aren't connected to a network, the customer doesn't know which tags point to the data they need, IT has concerns about security, and the list goes on. How are you guys thinking about these networking and protocol translation issues?

Second question. The main platform in this space is Ignition. Do you consider yourself a competitor to Ignition or are you aiming for a different use case?

How did you land that part time gig?

Is there a version of Lemon Squeezy for SaaS companies?

This is great. I find I'm using Figma in place of other tools more and more. I could see using Figma instead of Word / Google docs pretty soon as well.

This is the way.

One of the frequently raised concerns is that soon we will be drowning in AI generated blog posts, articles, presentations and emails, and most of this AI generated content will be meaningless noise.

I wonder if the opposite may be true. With the advent of AI, will there actually be _less_ meaningless noise?

When I was in finance, we would regularly produce 100 page decks for client meetings. Usually only 2 or 3 pages of the 100 page deck would really matter. The rest was what I call "proof of work". _Look at how much work we did for you. Isn't it impressive_? With AI, that kind of proof of work no longer makes any sense, so maybe all those 100 page decks, marketing blog posts, investment memos, and white papers will slim down to only the salient points and in many cases vanish altogether.

What kind of work do you do?

Phenomenal news. Hope to see more of it across the globe.

Ah, ok. So the "ve" was just a placeholder for the value in the "amount" column for each entry.

How does this handle the fact that credits increase the value of some accounts (e.g. sales, equity) but decrease the value for others (e.g. assets)?

What do "-ve" and "+ve" denote?

I live in West Los Angeles and have been by this encampment, as well as many others throughout West LA. The article portrays the encampment as some sort of "community" where people who have made a few bad decisions or caught a few bad breaks have come to "get back on their feet".

The reality is this encampment, like many others, is pretty close to hell on earth. It's a site of abject misery, squalor, and violence. People regularly get stabbed, beaten, and raped there. The people in the camp set fires, scream wildly at all hours of the day and night, fight with the fire department, consume hard drugs openly (i.e. meth and fentanyl), and destroy the surrounding environment with an astounding amount of trash and human waste. The park they occupy as well as the nearby library are now unusable by the general public.

There are some rural areas that fit your description, but many that do not, and are quite nice places to live.

Also, urban areas generally have very high concentrations of uneducated, addicted, and poverty stricken individuals as well, and the proportion of the population that fits this bill has increased dramatically in the past few years.

I've found Weather Spark to be a useful tool for researching ideal climates: https://weatherspark.com/. It has detailed temperature breakouts by time of day and year, wind speed, humidity, rainfall, etc.

One thing I've started to pay a lot more attention to is rainfall. The temperature in Southern California (where I currently live) is certainly pleasant, but that comes with the tradeoff of very limited rainfall, which seems to be having an increasingly negative impact as the years wear on.

I haven't had a chance to check out Remix yet, but I've certainly been impressed with the creators' (Ryan Florence and Michael Jackson) work on React Router and their React Training series. They design very good, easy to learn, low surface area APIs. I suspect Remix will be more of the same.

Regarding frameworks in general, the common lament is that it's all churn with no progress. In my experience this certainly hasn't been the case. It was much easier to work with jQuery than with the old web APIs, and it's light years easier to work with React than with jQuery or some of the older frameworks like Backbone and Ember. Each step built upon the previous one and unlocked a completely new set of capabilities.

I find it a bit odd that we always seem to ignore a very important cost when it comes to producing goods: the cost to (ultimately) dispose of them. Disposing of goods certainly isn't free, and it's a cost that both producers and consumers should probably share instead of just foisting it on the general public as a negative externality.

Will adding this disposal cost make certain products prohibitively expensive? Sure. But if no one can (or will) pay for your product after all the associated costs are baked in, then that's just the market's way of telling you that you shouldn't be making that product.

I think a lot of the "problems" with using large scale spreadsheets can be somewhat ameliorated by moving the underlying data to a proper database and then using the spreadsheet as a GUI / interactive analytical tool. Now that you can make external API calls in Excel[1], this actually seems doable.

[1] https://docs.microsoft.com/en-us/office/dev/scripts/develop/...

Which state?