Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
hakunin
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
27 ms
·
361.
▲
by
hakunin
3y ago
Agree with this. Of course because front-end still gets to build business logic, and back-end still ultimately decides the basis on which to build it, the decision making is spread more equally between them. Perhaps calling it "a washe
362.
▲
by
hakunin
3y ago
Arguably, the opposite is true. The view is more washed out across the stack if back-end supplies generic fields, and front-end decides how to use them. Now you no longer know who is responsible for which decisions, and have to look for the
363.
▲
by
hakunin
3y ago
In case of a complete redesign, yes you're right. With a generic API you will have about as much trouble writing the redesign as you did the original design. In practice, a complete redesign is an incredibly rare event, and a good prob
364.
▲
by
hakunin
3y ago
The article doesn't disagree with your second paragraph. It encourages to treat each "page" as a unique snowflake, including forms in it. I should probably do a better job to discourage consistency and standardization of thes
365.
▲
by
hakunin
3y ago
The whole point is that when you need companyName for another thing, you should create a parameter `anotherThing` and backend will set companyName into it as well. It's designed to make it very weird to _not_ do that, so that you don&#
366.
▲
by
hakunin
3y ago
In a way, this article tries to bring the alignment between the frontend and backend closer to the full stack days, while also acknowledging the increased complexity of the front-end, that may be deserving of its own team focused on great U
367.
▲
by
hakunin
3y ago
While this may be true to some extent, I think front end has plenty to deal with even if you do ship them the exact data they need. Primarily, this philosophy encourages you to maintain a strict connection between needed use cases, and the
368.
▲
by
hakunin
3y ago
It may totally be my bad for not making this part clearer in the article, but these structures are never meant to be fed into something that can automatically produce a UI. They are not meant to be consistent. The way I've been describ
369.
▲
by
hakunin
3y ago
> This article advocates for another extreme that I've also seen at work. They invented some UI language in JSON This is called server-driven UI, and not what the article is advocating. I try to make that distinction by calling the
370.
▲
by
hakunin
3y ago
One extra thing I have confirmed after writing this article: it's usually a bad idea to reuse back-end data in multiple places on the front-end. If you think about functions or object constructors in general, it kind of makes sense. On
371.
▲
by
hakunin
3y ago
Author here. We do this for SPA. The POST can be supported just like you explained. Then you can either reload the "page" to see that the checkbox is checked, because backend will include that as part of the page, or (as an optimi
372.
▲
by
hakunin
3y ago
I find a big iPad Pro comes pretty close to the same effect.
373.
▲
by
hakunin
3y ago
Are you asking for good faith, or just faith? A million debunkable/explainable-with-something-else cases is equivalent to zero cases. I mostly see people ask for one, single, hard piece of evidence. In all of the millions. Something th
374.
▲
by
hakunin
3y ago
I agree with this, and some of this does come up in code review questions (point #4). Sometimes you can already predict a question or predict a mistake someone is likely to make, especially knowing your colleagues/context. In those cas
375.
▲
by
hakunin
3y ago
…then I would suggest altering the code to speak for itself. If you can't do that any further, refer to the 4 reasons to leave a comment.
376.
▲
by
hakunin
3y ago
Pasting again my 4 reasons to leave a code comment: 1. An odd business requirement (share the origin story) 2. It took research (summarize with links) 3. Multiple options were considered (justify decision) 4. Question in a code review (answ
377.
▲
by
hakunin
3y ago
https://max.engineer Hosted by amazingly convenient https://blot.im . Articles on software architecture. I'm also looking to make new friends to discuss these topics. Working remotely in my 30s from a not-major-c
378.
▲
by
hakunin
3y ago
This doesn’t work in practice due to typically severe time constraints. You cannot expect a business that has 6 days of life left to wait for such an approval process. These things never happen fast.
379.
▲
by
hakunin
3y ago
It does, but you have to pick up a lot of library-specific knowledge to use it. Here the idea is that you can learn one keyword, and use plain ruby.
380.
▲
Adventures in Ruby-esque type enforcement
(max.engineer)
2 points
by
hakunin
3y ago
|
2 comments
381.
▲
by
hakunin
3y ago
Just an anecdote for those curious about a specific experience. This time I used VSCode for nearly 2 months. Thought it's the end of an era, I'm not coming back to Sublime Text. I decided to push through and customize the configs
382.
▲
Smart home company Eve bought by multibillion-dollar automation giant ABB
(9to5mac.com)
4 points
by
hakunin
3y ago
|
0 comments
383.
▲
by
hakunin
3y ago
In the beginning of your career, I do think well-timed jumps are very effective. But overall yes, in capitalism (whether you like it or not, this is what we got) the most important skill is getting people to agree/compromise with you.
384.
▲
by
hakunin
3y ago
> Lots of big companies have very well-defined salary bands It's true, but I'm not sure that it's good. That's going back to salary being weird. They are making themselves deliberately inflexible, locking themselves o
385.
▲
by
hakunin
3y ago
What I saw happen is “we can’t afford you”, not “we can’t go over the number we posted”. I think that’s fine.
386.
▲
by
hakunin
3y ago
I agree that senior experience is probably important, but also it’s knowing how to negotiate. What does it mean to be negotiated “fairly”? If you don’t like the rate, you come with a counter proposal, for which ideally you have leverage. Th
387.
▲
by
hakunin
3y ago
That's probably more true for simple products like toasters. For products where each one is almost always unique (has tons of optional choices, details) you can't easily shop around and compare apples to apples. You end up narrowi
388.
▲
by
hakunin
3y ago
I see your point, but not sure if a number up front would be honesty, seems more of a gamble. They need to find a number that's not too low, not too high, for an abstract average human. I've managed to detect a lowball danger fair
389.
▲
by
hakunin
3y ago
This is probably going to be controversial. I find salary to be really weird for many reasons. One of them is that I just can't imagine a sustainable world where salary is proactively offered, raised, etc. I think it necessarily must b
390.
▲
Adventures in Ruby-esque type enforcement
(max.engineer)
2 points
by
hakunin
3y ago
|
0 comments
More ›