Ask HN: What are you working on? Share what's interesting about the problem?

2 pointsjoddystreet1y ago1 comments

What are you working on? What’s most challenging, interesting about the work or the problem?

Are you using any AI tools? What does your setup/workflow look like? Where do you find it most useful/ least useful.

What other tools are you looking to further explore/excited about?

As for me — I am currently working on building data pipelines, merging data from various sources into our database, finally mapping the data to our entities. The work is pretty straightforward, not very challenging.

The most exciting part for me is just exploring the patterns to build out the solution. I have built integrations 4 times, ground up, until now. Always with a different data processing pattern goal in mind.

And here I find the copilot very useful, the threshold of picking a goal, that is learning about various ways of achieving the same end product goal with different constraints.

I don’t enjoy the `chat`, I don’t use `auto-test` generation, I sometimes use the `explain`, and I am truly grateful for the autopilot when it comes to remembering the syntax.

On the other hand, when I am in the flow, and stop to think about something, I find the autopilot auto-compete to be distracting, and often it’s just more work to review the code it suggests. Now, this could be my shortcomings/skill-gaps, I am open to accept that, have not thought about it quite deeply.

Apart from copilot, I use Claude, to generate throwaway code, and the quick scripts.

I am not using any other tools, I keep exploring though, but didn’t find utility in paying up for other copilots/coworkers/ai-tools.

Non AI-tool that I am trying these days is Zed editor.

After working as a full-stack for quite some years now, the next technology I want to work on is database.

Not sure how long it would take, but I want to switch domain to becoming a database developer, and hopefully with copilot reducing the threshold of experimentation, I might finally be able to!

1 comments

austin-cheney1y ago

I am considering writing a new approach to the concept of a Document Object Model (DOM) in Rust. The DOM is the compile target of the web browser.

I have not started this work yet and may not but I have already thought through the architecture of how it would work, something more refined than this plan:

* Layer 0: Node relationships and access methods.

* Layer 1: Syntax, allow definitions for any scheme like JSON. YAML, XML, markdown.

* Layer 2: Grammar, allow definitions for any static data language like HTML, SVG, TypeScript interfaces/types, XML instance languages.

* Layer 3: Schema, any implementation should have the means to validate any instance of a grammar and then self determine how to handle invalid parts.

The current DOM implementation is both too restrictive in its definitions and yet far too complicated in its implementation. If it were drastically simplified there would present much greater opportunities for scale at much lower costs than currently available. We have 30 years of history and lessons learned, which is exciting.

Key considerations:

* Simple is not easy. This would be designed around concepts of few and a rigid purposeful structure. If the current DOM scares you this should scare you more and easy will never become a determinant.

* Don’t be smart. XML and its supporting technologies were brilliant and powerful, so much so that nobody outside of senior data scientists really made use of it in any meaningful way. This new approach would have a model to allow for scale but the model would be primitive. Let the instances be brilliant and the model both boring and small.

j / k navigate · click thread line to collapse