Recent submissions

Comment · 6 months ago
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.
Comment · 2 years ago
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.
Comment · 2 years ago
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.
Comment · 2 years ago
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.

Comment · 2 years ago
Agreed, minus the Primsa.
Comment · 2 years ago
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.
Comment · 2 years ago
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.
Comment · 2 years ago
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?
Comment · 2 years ago
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.

Comment · 2 years ago
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.
Comment · 2 years ago
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.
Comment · 2 years ago
What did your startup do?
Comment · 2 years ago
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.

Comment · 2 years ago
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?

Comment · 2 years ago
How did you land that part time gig?

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton