Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
kaelig
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
8 ms
·
31.
▲
by
kaelig
2y ago
> Is the goal to be able to change a design token and see that change reflected across all your various UIs? That's exactly it! (with various degrees of immediacy: depending on the tooling it can be in real time, or deferred via a P
32.
▲
by
kaelig
2y ago
It's first and foremost a methodology that plays into your design infrastructure. Whatever tooling floats your boat is absolutely fine, but the difficulty comes when you have to scale your design decisions across SVG, Sass, Tailwind, R
33.
▲
by
kaelig
2y ago
The reserved prefix $ answers the question: "how can we let people name, structure, and nest their tokens however they want, while future proofing the spec?". More on that rationale: https://tr.designtokens.org/for
34.
▲
by
kaelig
2y ago
Hi, I'm the founder of the Design Tokens W3C Community Group, we are writing a spec to help with interop across design and developer tooling [1] There's a whole movement bringing DevOps and SRE thinking to design/UX, essentia
35.
▲
by
kaelig
2y ago
"wonderful and awful" is such a brilliant way to capture this. Thank you
36.
▲
by
kaelig
3y ago
I'd go as far as saying: use both Storybook and MSW! They're both amazing tools, solving intersecting but different needs. As part of your SPA (or MPA) development, UI state complexity will inevitably grow, and shipping seemingly
37.
▲
by
kaelig
3y ago
That would have been a fun one, but rem stands for "root em"!
38.
▲
by
kaelig
4y ago
A sushi chef told me it was called "California roll" because CA = Crab + Avocado, so I've been spreading that around... I feel cheated!
39.
▲
A Figma plugin that imports and syncs UI components from code
(story.to.design)
1 points
by
kaelig
4y ago
|
0 comments
40.
▲
by
kaelig
5y ago
No, but that's a fair question as a lot of content of this type that's out there has an underlying commercial call to action.
41.
▲
by
kaelig
6y ago
I feel like these articles gloss over the fact coding, vlogging, etc. in our free time isn't always about "advancing the craft" and "career advancement". People like painting, baking, brewing beer, playing music or
42.
▲
by
kaelig
6y ago
I made https://www.read.hn/ , for users of Instapaper. Clicking a link to a story opens it in Instapaper. It's styled using my personal Instapaper theme, so reading HN feels like I'm on the same site whether I'
43.
▲
by
kaelig
6y ago
We have 20 internal podcasts, and they're actually really good, especially the Context podcast mentioned by OP.
44.
▲
by
kaelig
6y ago
Daft Punk might be an exception to the rule, then.
45.
▲
by
kaelig
6y ago
I championed the rollout of Figma at my company and what this article mentions is true: this is a tool for design, not just for designers. We initially thought we'd need to provision the same number of licenses as we did for Sketch
46.
▲
by
kaelig
7y ago
I lead the team who built one of the public documentation sites mentioned in this article ( https://polaris-icons.shopify.com/ ), ask me anything!
47.
▲
by
kaelig
7y ago
I am French. This "start with no" attitude has been an issue when I started working with other cultures. First, when I worked in London, and even more so when I started working in California. At the first California-based company
48.
▲
by
kaelig
7y ago
Thanks for answering, I see other folks had concerns similar to mine regarding your comment. I understand better where you’re coming from. (Where I work) I find there is something to be gained by showing interest and asking about the parts
49.
▲
by
kaelig
7y ago
On large projects, it becomes impossible for anyone to understand how each line of code works and what the best solution should look like. In such a complex area, assertive code review comments could be counter-productive. In most cases, sh
50.
▲
by
kaelig
7y ago
It's possible that this would be an okay tone to use toward a junior developer or an intern. Could it sound patronizing toward a peer, or a more senior developer?
51.
▲
by
kaelig
7y ago
"assume good intent" is a good rule of thumb, but there are ways the author of the code review can also communicate in a way that's inviting a constructive conversation, rather than potentially leading the author of the code
52.
▲
by
kaelig
7y ago
Here's how I have approached it lately. Would love to know what people think: >My mind goes towards using X to achieve this. Curious to know if it's something you've explored and how it might not be the best fit for this u
53.
▲
by
kaelig
7y ago
Related, in French: https://www.letelegramme.fr/finistere/morlaix/roscoff-une-ma...
54.
▲
by
kaelig
7y ago
One of the issues with feature branches is that long-lived feature branches easily go stale, and each day that passes by makes it riskier to merge them into master. While I agree with the author on the general idea of trunk-based developmen
55.
▲
by
kaelig
8y ago
This is exactly why I moved from the iPhone to an Android phone about a year ago: I couldn't use Siri to play things on Spotify – that's pretty much the only thing that really bugged me about iOS.
56.
▲
by
kaelig
8y ago
I used to work at the Guardian. My understanding is that the font was commissioned specifically for the Guardian, and they had exclusive usage rights for a few years only.
57.
▲
by
kaelig
8y ago
I am the author of this file. As one of the comments guessed, I was making them for my team. Agreed about the butter, very important! That's why the recipe mentions "paint the crêpe with butter". This is a family recipe carri
58.
▲
by
kaelig
9y ago
I love Algolia. I worked with them for a week to make DocSearch accessible to screen readers and had a lot of fun. I'm especially grateful for their commitment to open source. Go Algolia!
59.
▲
How I Made Search in Technical Documentation Accessible to Blind Developers
(medium.com)
11 points
by
kaelig
10y ago
|
0 comments
60.
▲
Omakase: A CSS Preprocessor in Java Built by Salesforce
(github.com)
2 points
by
kaelig
10y ago
|
0 comments
More ›