zwarag

Hi HN,

I have to do a university assignment that is about software engineering. Unfortunately, designing user-interfaces (in the UX sense) is not a concern, even though we all have to write a user interfaces.

For my assignment, one component will have to register the minimum, maximum and most likely cost of building a car. These are just estimates that an engineer will do. The most naive way of doing so would be to put three textboxes that allow the engineer to input whatever he wants. However, only numbers are allowed. Additionally, the manufacturer knows that a car has to cost at least x, and they are not willing to pay more than y. That could all be done with textboxes, placeholders, validators that show error messages and so on. But I think a possibly better way would be to have some kind of slider with 3 "blobs" on it that represent min, max and most likely. The advantages would be that the engineer cannot even select values that are out of bound and having the 3 knobs on the line might even visually represent some skewness to his estimation.

I then went on Google to see if there is any research to "Designing Components" but I'm kinda overwhelmed by "top 10 UI/UX component" answers and MATERIAL.

So I was wondering, how is your process on designing components?

I was browsing the net to see if I could find a good summary on how to write good documentation.

In the team I work now (which works on an internal framework) there are 7 People working on features and everyone is writing some part of the docs and the difference in style is very noticeable.

Some like to write from the personal perspective (I), others in a teaching manner (we, you) [have,could,should]. Some write in an asking manner, other in a commanding manner. Then there is the debate between as concise as possible and "enjoyable to read" as possible ("Go to foo for more information." <-> "If you would like to read more about this topic, head over to the foo section.").

We have a Pull-Request guide that has some review points concerning documentation. But I feel like it's only partially effective. So I was wandering, how is HN approaching their documentation writing.

I have reached a point where I would like to understand more about compilers. The reason for this is that I am working on a JS framework that has become very complex, and I need to find a way to simplify migration of versions for my colleagues.

When my team makes an update, all the teams (which I now call customers) that use our framework have to follow. They might have to look at what functions become deprecated, adapt to new signatures and so on.

So assuming a function is renamed, it should be possible to rename this function automatically at the customers' codebase with a program that builds and AST, finds the function and replaces it with the new function name.

Also, we want to make sure, that our customers do not write smelly code. A trivial example of this would be, to no longer declare variables via "var" but only via "let" or "const". Of course, a tool like ESLint is perfect for this and I would like to write my own rules for ESLint.

My question now is, how do I, as a web developer, learn this domain.

From what I've found, most books about compiler and AST are directed to low level languages like C or higher ones like Java.

But I'm looking for something more directed to web programming. Just to summeraize, my goals are: * Write migration programs that help customer update theyr code automatically. Where no automatic migration is possible, possibly leave a comment and point out that manual adjustments are necessary. * Develop a "DevTool" that helps our customers to follow best practices and not write smelly code.

I'm curious to what you guys think would be a good way to enter this domain. Just to clarify. I'm not against learning this, by going the - what might be considered - proper way and learning how to write a lowlevel compiler for B to learn the basics. And then move on to more specific compilers for higher languages. I just wanted to see if this achivable in a way, that stays closer to the web domain.