zemlan.in

On Code Reviews

Sun, 08 Dec 2024 17:00:00 GMT

The code is done, now to the hard part

Maybe, I’m the only one, but I’m annoyed by jokes like this:

10 lines of code = 10 issues.

500 lines of code = "looks fine."

Code reviews. </blockquote> </a>
I Am Devloper on Twitter
</a> </figcaption> </figure>

I mean, the joke by itself is fine — i-know-that-feel.png</code>, #relatable</code>, all that. But it contains several examples of a bad behavior both of code authors and of code reviewers:
surface-level comments;</li> huge patches;</li> lack of context;</li>skimming/reading “diagonally”</li> </ul> So, if code review problems are so widespread, then we should not just point at them, but also try to address them somehow. One could do that either via external requirements/limitations or via internal motivation To require “be better” is dumb. Automatically rejecting code review because of metrics — not an option, because “understandability” can’t be measured by a script. So we’ll disregard “improve code reviews via external requirements/limitations” One could influence another’s internal motivation by an example, but after years of attempts, this seems too slow and not that reliable. Maybe, a personal example can be better communicated in a post… Aside: this post was originally written as a</a> series</a> of</a> posts</a> in Ukrainian in the beginning of 2021. Many things have changed since then (like I'm currently working in a smaller company and a team than in 2021), but the general message and advice still seems relevant (albeit somewhat meandering) Also, to make writing process easier, this post pretends as if Git and Github are the only ways to collaborate while writing code. If you’re lucky enough to use Fossil or Phabricator or Gitea or whatever… Okay… What Are Code Reviews For?</h2> Time and Place</h3> I’ve only worked</a> in rather mature product companies. When a company works on a products for years, the time and effort investment into code review is justified not only because “that’s a correct thing to do”, but also because it’ll make future support easier Really young companies, who might never get to that “future”, are taking a risk that, after all those reviews, they’ll remain with a “correct” but useless code I don’t know how it is to work at an agency/outsource/outstaff. On one hand, if a client will return for a follow-up work, previous code reviews should help to remember the codebase faster. On the other, client might never return So, code reviews might be completely useless (or even harmful) on your current workplace. Or they were on your new colleague’s previous workplace… Motivation</h3> Okay, let’s assume you’re working in a relevant team, at a relevant time, and you really want to get better at writing and commenting pull requests. To know the direction of improvements, you’ll need to understand what’s the goal of code reviews So, what’s the goal of code reviews? I was told that’s what we do here </blockquote> “Due to historical reasons” is a bad path to improvements. It’ll lead you to where you’ve started. There even won’t be a story to tell (unless you like stories where nothing happens) So that idiots won’t break anything in my perfect project </blockquote> Those “idiots” have opened a PR because they need to fix or to improve something. If your perfect project is holding on together only thanks to your gatekeeping, you should invest some time into writing tests and setting up linters To catch what’s difficult or impossible to cover with tests </blockquote> Warmer… But “opinions leaders” will soon get tired of staring at hundreds and thousands of line of code, looking for the same problems that trip colleagues unfamiliar with the repo At the same time, novices of the repo (the repo specifically — they might have a lot of experience outside of it) might not know that {placeholder}</code> will create problems, while experts have encountered {placeholder}</code> so many times that they instinctively avoid it </video> So, the goal of code reviews is to let authors and reviewers to share their understanding of the project with each other: authors, explicitly and implicitly, point out weirdness in existing code. For example, the fact that to achieve a simple task, they need to do a lot of manual/boilerplate work</li> reviewers share and communicate project’s foundational assumptions, stuff like “on errors, you’ll need to expect HTTP 200 with a error</code> key because that was a decision made long ago and around which a lot of code was written”</li> </ul> In other words, you need two to tango</del> have a good code review Opening a Pull Request</h2> The Repo With A Thousand Faces When writing a pull request (PR), it’s useful to be guided by the idea of “invest as much time and/or effort as you want others will invest into reviewing” If the author won’t invest time into gathering everything in a nice package, then reviewers would need to do that themselves. Even if reviewers know about a project’s quirk, they might not remember about it when reading the PR, because their mind is busy with connecting the dots that author decided not to connect Github Stories</h3> If the goal of code reviews is to share and get others’ thoughts and opinions, first your colleagues need to understand what’s happening. Knowing that, you might arrive at a bad and a good conclusion: a bad conclusion: “if colleagues understand — great, if not — that’s their problem”</li> a good conclusion: “I can make PR less or more understandable”</li> </ul> To make it easier for colleagues to understand a PR and to share their relevant experience, they need to know “how it was”, “what’s changing”, “why it has to change”, “how it changes”, and “what it becomes”. Changes in the code itself tells about some of these For example, the left/red part of a diff tells us “how it was”, while the right/green one — “what it becomes”. The rest of the questions we’ll need to address in prose If that prose is a collection of dry facts, then reviewers would have to connect them themselves. To make it easier, PR’s author can unite these facts into a transformation story</a> in which PR’s repo is the main character We understand stories and can “extract” their gist, because we’re listening/reading/watching them our whole lives. Plus, our brain perceives code as a puzzle</a>, so we might accidentally ignore consequences of a change — a puzzle is solved, the end, nothing will happen to it… Because of that, it makes sense to tell stories while writing a PR. You’ll have ample opportunity to so do1</a> Words Mean Things</h3> You can start writing the tale long before pressing the “New pull request” button — in the code itself. Even without comments, you can describe “the main cast” in the names of files, functions, and variables. A good name of a thing will describe what and why it is, will show its connection with other parts of the code, and will help with discussing it That’s why it is important to avoid generic names (like utils/data.js</code>), same names for unrelated things, and to pay attention to existing names — if feature is already called wunderwaffle</code>, don’t begin suddenly calling it terrifictiramisu</code> The name of the branch will help you to focus the PR and to avoid distracting both you and reviewers with “extras”. For example, if you’re in the branch named JD-48/speed-up-uploads</code>, it’ll be easier to stop yourself from updating all dependencies of the JD project or from changing uploads in the ER project The Medium is the (Commit) Message</h3> If you’ve messed up and the branch already includes too many unrelated changes (which would still be helpful in this or another project), you can play with the content of the commits. Instead of including all of the file’s changes in the same commit, nothing stops you from adding changes line-by-line. Fans of CLI can do it with git add --patch</code></a> or git add --interactive</code></a>; personally I got used to Tower’s</a> GUI for that How to understand which lines belong to one commit, and which — to another? Think about where these lines happen in the PR’s “story” and describe that in the title of the commit, while limiting yourself to git-recommended 50 symbols</a>2</a>. Maybe, that story is a short anecdote and fix A when B</code> will be enough. Maybe, it has multiple “characters” and you should first introduce them to the reader (add X to do Y</code>), and then to each other (use X in Z</code>) Describe your changes in imperative mood, e.g. «make xyzzy do frotz» instead of «[This patch] makes xyzzy do frotz» or «[I] changed xyzzy to do frotz», as if you are giving orders to the codebase to change its behavior. Try to make sure your explanation can be understood without external resources. Instead of giving a URL to a mailing list archive, summarize the relevant points of the discussion. — SubmittingPatches - The core git plumbing</a> </blockquote> Additionally, many projects have set up an integration between Git and their ticket manager, so that commits/branches linked to tickets and vice versa. Because of that, it usually makes sense to mention the ticket number in the title of the commit, for example, #JD-48 cache responses from X</code>. Format (XX-00</code>, $XX-00</code>, #XX-00</code>) depends on your project, but any prefix before numbers is enough for Github to display ticket links in its UI</a> Many projects also follow conventional commit</a> and use tags like feat</code> and chore</code>. I personally think these tags are quite useless for a product without public CHANGELOG, but the habit of categorizing change might help with keeping PRs and commits focused Retelling the Story</h3> If you’ve confused the order of the commits, you can change it with git rebase --interactive</code></a> which will make it easy to reorder/rewrite/combine/delete altogether commits by editing a text file with a list of operations and commits For example, you’ve been working in the JD-48</code> branch, where you’ve made five commits. Local commit history currently looks like this (git log --graph --oneline --all</code>, newer commits at the top) : * f4593f9 (HEAD -> JD-48) add tests for X-Y integration * 04d0fda optimize Y * ba46169 integrate X with Y * fa1afe1 tests for X * 5928aea setup X * 300a500 (master, origin/master, origin/HEAD) … </code></pre> git rebase --interactive "5928aea^"</code> will open these lines in your text editor3</a> pick 5928aea setup X pick fa1afe1 tests for X pick ba46169 integrate X with Y pick 04d0fda optimize Y pick f4593f9 add tests for X-Y integration </code></pre> Each line is an operation to do when creating a new version of the branch. By default, rebase takes and applies every commit (pick</code>). Additionally, you can skip a commit (drop</code>), combine it with the earlier one (squash</code>), apply it with an edit (fixup</code>); you can reorder commits (by reordering lines in the file) and execute arbitrary shell-commands (exec</code>) For example, if you want to: move the tests commit (fa1afe1</code>) to the end of the branch;</li> combine it with the integration tests one (f4593f9</code>);</li> and delete the optimizations of the unrelated part of the project (because this PR is about new feature, not optimizations)</li> </ul> you’ll need to edit the “script” generated by git rebase --interactive</code> to be that: pick 5928aea setup X pick ba46169 integrate X with Y drop 04d0fda optimize Y pick fa1afe1 tests for X squash f4593f9 add tests for X-Y integration </code></pre> Or you can stop boasting and just use your mouse to rewrite the history, for example in aforementioned Tower</a> After the branch and the commits are polished, it’s time to work on the title and the description of the PR. They are written, more or less, similarly to commits, but with more of a bird view What to Write in Pull Request’s Description?</h3> Usually, the most difficult part of the description for me is to begin. Blank page</del> <textarea></code> blocks a lot of people Some repos have PULL_REQUEST_TEMPLATE.md</code>, which can help with writer’s block, but private projects frequently either lack it or it is rather useless as a prompt: # Summary ... --- - [ ]  ci-bot, do something </code></pre> Titles and descriptions of commits also might help with the blank <textarea></code>. If they are not enough, begin with “So, there’s noun</code> and it is verb</code>” and extend this intro with context That context might include: causes for the change (less “i was asked by manager”, more “users have a problem”)</li> weird lines, where it seems you could do better, but you don’t know how and/or too lazy to. Maybe, the lines aren’t weird at all, maybe your colleagues know a good approach, maybe somebody will motivate you to power through the laziness</li> links to related tickets and PRs; to the documentation of new/strange functions; to the answer on StackOverflow from which you’ve copied that snippet…</li> </ul> Speaking of links… Ten minutes learning Markdown4</a> will help you with readability/writability of the description. For example, compare how different link styles read: There’s [`<input type="color">`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/color), but we [can’t use it](https://caniuse.com/#feat=input-color) yet in all of [our supported browsers](https://kb.example.com/supported-browsers) </code></pre> There’s `<input type="color">`, but we can’t use it yet in all of our supported browsers Links: - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/color - https://caniuse.com/#feat=input-color - https://kb.example.com/supported-browsers </code></pre> There’s [`<input type="color">`][mdn], but we [can’t use it][caniuse] yet in all of [our supported browsers][kb] [mdn]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/color [caniuse]: https://caniuse.com/#feat=input-color [kb]: https://kb.example.com/supported-browsers </code></pre> Pull Request Assignees</h2> When all the prose is written, it needs an audience. And you should know your audience You are Reviewer Zero</h3> Author of the PR is the reviewer zero. Of course, nobody stops you from switching to another task immediately after you’ve passed the baton to your colleagues, but reading familiar code in another environment (in code review UI instead of the code editor one) or at another time (when all the “obviously” are forgotten) will help you notice an mistake or some weird thing on your own I sometimes do this as well – after publishing my PR, I review it myself (on GitHub, you can comment on your own PR, but without approving it). This allows me to add comments/context specifically to the code that it's related to — a good comment to the previous section </blockquote> It’s especially comfortable to do in a draft pull request</a>, which already kinda exists and has CI checks ran against, but hasn’t announced itself to code owners</a> Who to Assign to</h3> In small projects with a tight team, the question of “who to assign review to” answers itself — you either assign it to everyone (because there are not many of you), or you know the person responsible for this or that part of the codebase and assign it to them In more… dynamic projects and teams, due to scale and worse communication, answering that question is more difficult. Often, it’s solved by including either whole teams or “opinion leaders” (team/tech leads, senior engineers, etc.) in the code owners list. But either option creates its own problems Teams</h4> Assigning a team risks making every team member think that reviewing your pull request is someone else’s task. Having a rotating “on call” person doesn’t save you — for example, if the pull request was opened Friday evening, when I was on call, Monday morning I’ll ignore it thinking that it’s now Julia’s problem because she’s on call today. At the same time, Julia might just as justifiably ignore it herself — pull request is from Friday, and on Friday she wasn’t on call Plus, new team members might be too shy to comment — what if they won’t notice something or will ask a “stupid” question. If the PR is assigned to the whole team, they can just wait one out Assigning to a team might also have the reverse effect, when everyone is trying to quickly write a comment without going into details5</a>. In theory, pull request’s author could spend time and effort to answer every single passerby, but it’s hard, exhausting, and might lead to conversations with management if it thinks that “your task is to solve problems with the code, not to mentor junior developers in other teams” Opinion leaders</h4> Having a dedicated person who reads through every pull request has its positives, of course, stuff like more consistent style and higher chance to notice a conflict with project’s implicit assumptions But it’s absurdly to expect (or require) one person to thoughtfully go through everything at the same speed, with which the rest of the team writes code. It’s impossible to get all three in the “quantity/speed/quality” triangle. You’re lucky even if you’ll manage to get two… I don’t know who to decidedly solve issues of either/both approaches. But I’m sure that: it’s better to assign individual people instead of the whole team, even if their lone contribution will be re-assigning PR to someone more relevant</li> it’s very important to avoid creating a “bottleneck person”, who won’t last long under the pressure of superiors and peers</li> reviewing pull requests should not only leads/senior people, but junior developers too. Otherwise, without junior’s “what’s happening here?”, everything will fly off on abstractions upon abstractions, and it’s easier to simplify code during code review than after it</li> </ul> Code review & response</h2> So, your colleague has written and described the code, you’ve gotten a notification about her pull request. What’s next? To Listen</h3> Every pull request has reasons it exists. Aside from obvious external “fix a bug”, “add a feature”6</a>, and “update dependencies”, the reason might be internal, for example: intermediate step to fix a bug/add a feature (“this function is exported but never used here because it’ll be used it not-yet published code/PR”)</li> align existing code with author’s mental model (“it was difficult for me to follow, I rewrote it so that it’s more understandable”)</li> improve the ease of development (“i use grep</code>, but this file made it harder to do”)</li> </ul> Reviewers might disagree with pull request’s reasons or how they were handled, but for a good code review, they need to know them and to align them with project’s goals if necessary. So you should think about what reasons guided the author. For external reasons, you can look at the ticket description or background conversations. Internal ones can be deciphered from commit history or pull request’s description If author didn’t leave you with much breadcrumbs, you can help yourself by filtering files</a>, looking author’s past changes</a>, doing a local checkout of the branch, attempting to rewrite “a strange solution” with all your “this shouldn’t be like that”… Or, as the laaaaaast resort, you can just ask them To Speak</h3> Just like every change in the pull request, its every comment has its reasons. For example, comments can be written… To Learn</h4> The closest to the main goal of code review “genre” of comments is “why is it written precisely like that?”, but it isn’t used often enough. Even if all participants already know the reason, but it wasn’t mentioned explicitly anywhere, the need to formulate the answer to the question will spotlight accidental excessive complexity If they think they know the reason, then explicitly writing your point of view might highlight when that “know” was only an assumption. Assumptions lead to bugs, so sometimes it’s better to clarify even something “obvious”. If that “obvious” was already written down somewhere, it’s completely okay to get a link to a comment that has the answer or to a commit with an explanation Sadly, this genre is also the most dangerous. After reading “why is it written precisely like that?” in a bad mood, I might wind myself up thinking “how can they doubt my work?” and/or “seem like here, I can’t do this precisely like that, so I’ll rewrite everything ASAP”. Because of that, it’s important to let pull request’s author know that the question doesn’t have any hidden meaning It’s really difficult to transmit the tone/intonation in the text alone, so, to make sure the text reads closer to how it sounds in your head, you’ll need to somehow compensate that lack of tone/intonation. For example, by rephrasing the question, emphasising with italics, just writing “I’m sorry, I’m not implying anything here”, or by adding a drop of emotions with emoji </a> Sarah's Scribbles </a> Tumblr Blog </figcaption> </figure> To Correct</h4> A much more popular genre of pull request comments is “that’s wrong”. Many people think that these comments are the point of reviewing the code. Agreed, an additional pair of eyeballs will help discovering problems sooner, but before critiquing the changes it’s important to first understand the reasons behind them. Without that, both sides of code review will make each other’s mood worse — either with bad advice or with surface-level changes to resolve that annoying comment Chesterton's Fence: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it." </blockquote> </a> Lars "Sweet Leaf" Doucet on Twitter </a> </figcaption> </figure> Even if you know, what was the reason behind this change, you don’t have to ask to fix every single line in which you’ve noticed a problem Firstly, it might not be an actual problem, so asking “why?” would work better. Secondly, one remembers their own experience better than someone else’s, so if a problem isn’t critical and/or will quickly show itself in runtime and/or simple to hide from users, ten minutes of panic would teach code author a lot. For example, that’s how young me learned to hide new features behind feature toggles</a> and to invalidate caches When problem is actually worth a comment, it’s better to leave similar comments all at once, to lessen the time until the whole pull request is merged/closed. In other words, prefer “comment-comment-fix-fix” over “comment-fix-comment-fix” In addition to pointing at a problem, reviewer can also suggest a solution, be it just text, pseudocode, ```suggestion```</code></a>, or something else </li> </li> </ul> If you have a good relationship with pull request’s author and you are secure about each other’s skills, you could checkout pull request’s branch and make suggestions in a form of commits. Where to push those commits — to the new branch (with a PR to a PR7</a>) or to the same branch — depends on original branch’s author. This path, just like “let them make mistakes”, is risky, but it does exist Returning to the lack of tone in text… If a person might misread an innocent “why?”, then “I’ve written code for your pull request” or bright red “@username</code> requested changes” will be taken personally sooner or later. So you need to intentionally soften them, or, at least, remind everyone that this is critique of the code, not of the person But even “@username</code> requested changes” is better than silence To Format</del></h4> What you shouldn’t comment are semicolons, indents, and other formatting. If formatting is really important, then, instead of writing a “we put spaces inside the curly braces”, spend your time on setting up simple automatic formatter8</a> and on running linter on CI9</a> Without those, reviewer has to work to keep their focus on the pull request’s gist, instead of getting districted by surface-level and usually useless for a user things like “sort imports alphabetically” To Bear in Mind</h4> Reviewers’ comments don’t have to address exclusively pull request’s author, but other colleagues too For example, to bring attention to difficulties when integrating with some other system’s API. Or to more-than-appropriate amount of manual/boilerplate changes where refactoring/types/automation would simplify and shorten future pull requests. Or to similarities between the new code and code in another project (with a possibility of code share) Immediately addressing those comments, in the same pull request, would probably over-blow its scope, but, after a few of such reminders, it’ll be easier to remember about them during a future spring planning To Encourage</h4> If opening a pull request only ever leads to neutral and relatively negative comments, then of course people would avoid code review — “I’ve tried so hard, coded, worked around roadblocks, just to get so close to the finish line and get drowned with ‘that’s strange’, ‘that’s wrong’, ‘that’s bad’…” To counterbalance all that, it’s useful to, at least occasionally, praise good changes, whether it’s a particularly clean solution, a good idea, or a banal “thank you, it’s been annoying me too, but I couldn’t get myself to address it” Without comments, code review is just a rubberstamping. Only with “that’s wrong, fix that” comments — harmful gatekeeping. I hope that this post showed that with some care, both side of code review can be a little bit nicer and useful Thank you for your attention I want to emphasis that everything here are opportunities to make pull requests better, not requirements for them. If personal communication and a few words in title work for your PR, nobody insists on you spending hours to write an epic about a three lines change 🙏 ↩︎</a> </li> When 50 symbols is not enough, you could and should extend the title with additional description (by adding a line break in git</code> CLI or by using a dedicated text input in a GUI), whether it was written manually or generated from a template</a> (thanks to Mark</a> for the advice) ↩︎</a> </li> If vi</code> is not your preferred text editor, you can change $EDITOR</code> in your ~/.bashrc</code>/~/.zshrc</code>/~/.config/fish/config.fish</code></a> to launch, for example, Sublime Text (subl -w</code>) or any other text editor ↩︎</a> </li> Whether it’s Gruber’s “original”</a>, more detailed GitHub Flavored Markdown</a>/CommonMark</a>, or another language altogether (as long as it’s the language your code review tool’s using) ↩︎</a> </li> Thanks to Katya</a> for reminding about this case ↩︎</a> </li> Performance and documentation are features too ↩︎</a> </li> BRAAAAM</a> ↩︎</a> </li> Preferably with minimum configurations, to not get tempted into hours long discussion of vital questions like “double quotes or single one?”. For example, check out eslint:recommended</code></a>/prettier</code></a>/standard</code></a> in Javascript’s ecosystem, black</code></a> in Python’s, gofmt</code></a> in Go’s, and .editorconfig</code></a> almost everywhere ↩︎</a> </li> And, please, don’t let git hooks justify the lack of linter on CI. Hooks might not be ran because of one reason or another, for example if the commit was created in Github’s web UI. So, without linter on CI, your main branch will have broken formatting more often than you’d like (and you’d probably like it to be “never”) ↩︎</a> </li></ol></div>

Server-side Rendering: CDN and Caching Wed, 17 May 2023 17:40:00 GMT aka “The Other Servers” Previously, I wrote about why</a> Nebula</a> decided to implement server-side rendering (SSR) for its web app and what</a> it took to do so in the web app’s codebase. And now it's time to explain the last part of delivering server-side rendered pages to the browser — Content Delivery Network (CDN) CDN</h2> CDN is a network of proxy servers (also known as “edge” servers) all over the globe. These servers can: route users’ requests to different servers (for example, route dynamic /jetlag</code> to our SSR server and static /index.2c3.js</code> to S3 storage)</li> modify the HTTP headers that server receives from and sends to a browser</li> run “serverless” functions (like AWS Lambdas)</li> cache server responses</li> </ul> And, because they are all over the globe, your request for a video page doesn’t have to go under the ocean if there’s an edge server close to you and somebody else close to the same server has just loaded the same page CDN has a huge impact on how optimized the server has to be — every request cached and served by CDN saves us a lot of server time. The Internet is crawling with bots, both benign and nefarious, so even if you aren’t operating at huge scale, at least some server caching (be it CDN or just a properly configured nginx/Caddy/whatever) will help dealing with those critters There are several big companies providing CDN services, but nebula.tv uses Amazon’s CloudFront1</a>. I will try to keep this post generic enough for developers outside of Amazon’s influence, but AWS specifics will pop up here and there And by “here” I mean “here is some CloudFront’s terminology”: Distribution — a version of edge server configuration, used to route, cache, and other stuff for a specific domain</li> Viewer request — original HTTP request coming from a browser or other client (native app, curl</code>, etc.)</li> Origin request — HTTP request sent from an edge server to wherever the distribution routes (aka “to origin”)</li> Origin response — HTTP response from origin to an edge server</li> </ul> </a> Scheme of user request with CDN in the middle 1. Viewer request 2. Origin request 3. Origin response </figcaption> </figure> Caching</h2> So, the main point of adding a CDN layer to your architecture is caching, but it isn’t limited to CDNs — browsers also cache2</a>. In both cases, the caching is controlled by Cache-Control</code> and Vary</code> origin response headers At its most basic, Cache-Control</code> is an origin response header with a list of comma-separated directives: max-age={number}</code> indicates to both browser and CDN to cache the response to this URL and re-use it if there are viewer requests in the next {number}</code> seconds</li> s-maxage={number}</code> is similar, but for CDNs only — browsers just ignore it</li> public</code> indicates that response isn’t specific to a user/session, so can be stored in a shared cache</li> there’s also no-cache</code>, no-store</code>, private</code>, immutable</code>, and others. The post is already getting long, so just read about those on MDN</a></li> </ul> Why would you want cache on CDN and not in a browser? Mostly3</a>, to recover from errors — if server responded with broken code or data, and browser cached it for an hour, for that hour user will see the broken site4</a>. On the other hand, if CDN has previously-broken-but-now-fixed response in its cache, there’s usually a button or an API to invalidate caches on edge servers, forcing them to load the latest version of whatever While Cache-Control</code> tells browser/CDN whether or not to cache a particular response, Vary</code> tells what in viewer request will invalidate that cache. You see, by default, the browser’s “cache key” (identifier for data in cache) is the viewer request’s HTTP method and URL. But if a server can respond differently to requests with the same URL depending on viewer request headers (for example, user-specific data if there’s a session token in Cookie</code>), these headers can be listed in Vary</code>. Support for Vary</code> header on CDNs is spotty — for example, CloudFront does understand it (albeit with some gotchas</a>), CloudFlare basically ignores</a> it5</a> AWS Specifics: Policies</h2> if you aren’t interested in CloudFront minutia, you can skip to the next section</a> To better control the “cache key”, CloudFront has two “policies” that can finely tune distribution’s default and custom endpoints’ behavior Cache policy</a> describes what’s included in the “cache key” for each particular viewer request. By default, it's only URL pathname, but we can add all/allowlisted/blocklisted query params, headers, or cookies. For example, we can ignore fbclid</code> and ref</code> query param, and/or include only session</code> cookie. That way these requests will have the same “cache key”: https://nebula.tv/search?q=coconut Cookie: session=patrick https://nebula.tv/search?q=coconut Cookie: session=patrick; analytics=dave-the-agent https://nebula.tv/search?q=coconut&ref=gmtk Cookie: session=patrick </code></pre> Origin request policy</a> describes what query params/headers/cookies have to be added to the request from CDN to SSR when the request's "cache key" is "missed" (= "not in CDN cache"). These query params/headers/cookies don't affect the “cache key", leading to possible issues — for example, if the cache policy ignores User-Agent</code> header6</a>, but the origin request policy includes it, Firefox users might get cached responses for Chrome, if Chrome was the first to hit a particular endpoint first. So use origin request policies very carefully Everything outside of these policies won’t reach your server/origin </a> Example of how cache and origin request policies limit what data from viewer request goes into cache key and what reaches the origin </figcaption> </figure> AWS has a list of predefined (“managed”) cache</a> and origin request</a> policies, which one can use by simply modifying the CloudFront distribution. If those aren’t enough for your needs, you can create your own If you do create your own policy, avoid allowlisting query params. We learned the hard way that ignoring everything but a predefined list of params leads to nasty bugs if somebody7</a> forgets to update that list What and How</h2> What and how to cache depends a lot on your web app’s needs and what types of responses it serves. For nebula.tv, the needs are: Public assets</h3> In other words, version-controlled and uploaded as-is files, for example favicon.ico</code> We don’t cache those. Maybe, we should cache them on edge servers, but don’t — these files don’t block load of the web app, so S3 is fast enough Built assets with hash in the filename</h3> After a built tool (like vite</code>) has done its job, output files usually have the file’s hash in their name (for example, 2c3</code> in index.2c3.js</code>). Once the file is uploaded it’ll never change8</a>, so both CDN and browser can cache it for a long time So, when adding9</a> files like this to S3, we use --cache-control max-age=86400,public</code> option of S3 cli</a> HTML responses with hardcoded metadata</h3> These are HTML pages returned from SSR server that don’t change without a code deploy. In the case of Nebula, that’s pages like Classes</a> or Videos</a> We don’t want to cache those in a browser, CDN can cache them for long10</a>, and these pages don’t have data specific to a user So, easy-peasy! When sending a response renderedHtml</code> in SSR server, we’ll add Cache-Control</code> with public</code> and s-maxage</code>: res.writeHead(200, { 'Content-Type': 'text/html', 'Cache-Control': `public, s-maxage=${MAXAGE_IN_SECONDS}`, }); res.end(renderedHtml); </code></pre> Content-specific metadata HTML responses</h3> Crap, I shouldn’t had used a constant in res.writeHead</code>… These are pages like a video page — it has, for example, the video’s thumbnail in <meta property="og:url"></code> and video creator can change that thumbnail whenever. To account for that, these pages are cached for five minutes. Yeah, it isn’t instantaneous, but it also doesn’t complicate our content management system (CMS) with “cache invalidation” API calls to CloudFront To change the default MAXAGE_IN_SECONDS</code> for these pages, we’re using the context</code> property</a> of React Router’s <StaticRouter></code>11</a>. This property is an object that gets automatically passed to route components as staticContext</code> and can be modified in those components. So, whenever a page includes CMS-defined metadata, we’re passing a smaller value for s-maxage</code> via that object: // server.jsx const routerContext = { cacheDuration: undefined }; const renderedHtml = ReactDOMServer.renderToString( // ... <StaticRouter location={url} context={routerContext}> <App /> </StaticRouter> // ... ); res.writeHead(200, { 'Content-Type': 'text/html', 'Cache-Control': `public, s-maxage=${routerContext.cacheDuration ?? MAXAGE_IN_SECONDS}`, }); res.end(renderedHtml); </code></pre> // pages/Video.jsx const STATIC_CACHE_DURATION = 300; // 5 minutes export function Video({ staticContext }) { if (staticContext) { staticContext.cacheDuration = STATIC_CACHE_DURATION; } // ... } </code></pre> Error responses</h2> But that’s when everything goes smoothly. But it never</del> not always does If something goes “wrong”, for example user loads a video page a minute before it’s published, we don’t want to serve cached 404 error for the next four minutes. So treat responses with 4XX or 5XX HTTP codes differently — either don’t cache them entirely, cache them for a shorter time, or something AWS Specifics: Failover</h3> Once again, click here</a> to skip CloudFront has a notion of failover</a>, for when the origin can’t be reached or if it returns some error code. SPAs frequently use fallbacks for a client-side routing: CloudFront receives a request for /something</code>, goes to SSR, gets a HTTP 500</code> from it, and falls back to serving /index.html</code>, which is (hopefully) present on S3 nebula.tv uses fallbacks to hide 5XX errors from users by doing basically the same — if SSR can’t be reached (HTTP 502</code>) or can’t process the request due to code error (HTTP 500</code>), it’ll just serve index.html</code> from S3. That way, SSR errors only affect bots while humans visitors will have the same experience as before12</a> // cloudfront-distribution.json { // ... "CustomErrorResponses": { "Quantity": 2, // oh yeah, CloudFront can't count `Items` by itself "Items": [ { "ErrorCode": 500, "ResponsePagePath": "/index.html", "ResponseCode": "500", "ErrorCachingMinTTL": 0 }, { "ErrorCode": 502, "ResponsePagePath": "/index.html", "ResponseCode": "502", "ErrorCachingMinTTL": 0 } ] } } </code></pre> While this is quite handy, it does create problems with JSON endpoints on the same distribution — if such endpoint returns HTTP 500</code> with some data in JSON response, CloudFront will helpfully replace that response with index.html</code>. Not sure how to solve that, but maybe something will come up… How it went</h2> After all that work was done, I think it was worth it: requests with warm13</a> CDN cache sped up from 1-1.5 seconds to 20-50ms</li> Google discovered that Nebula has videos</a></li> more messengers started to show nice link previews</li> the server component specifically for the web app is great to have in the tool belt14</a></li> </ul> Although, requests with cold CDN caches — loading an unpopular page can take seconds to finish. At some point, I hope we’ll skip more API requests on the server and/or share the React Query cache between SSR processes, but not today Thank you</h2> Thank you for your attention. If you liked these posts, please consider supporting Ukraine</a> Thanks to Sam Rose</a> for the help with writing this. Photo by Taylor Van Riper</a> Also Fastly and, since recently, CloudFlare, but that’s not important for this post ↩︎</a> </li> As well as servers, databases, processors, and almost everything else computer’y, but don’t worry about that now ↩︎</a> </li> And, less mostly, to better control when new features become accessible ↩︎</a> </li> If you’re looking for a comment section to type out “But they can reload with cache disabled!”, don’t bother ↩︎</a> </li> Do I hate that two CDNs we’re using share the “CF” abbreviation! ↩︎</a> </li> Which is a good idea, since this header rarely affects the HTTP response but has so many variants that cache will rarely be warm ↩︎</a> </li> </video> ↩︎</a> </li> Assuming there are no hash collisions ↩︎</a> </li> Because we want to have older assets available to avoid 404s if browser has stale cache or if we did a version rollback ↩︎</a> </li> Although, nebula.tv caches them for a day, which is longish, but not that long. Can’t remember why… Maybe, just to be safe?.. ↩︎</a> </li> We’re still on react-router@5</code> because, until recently, the sixth version had a few issues that made it harder to migrate without a performance hit ↩︎</a> </li> Unless they are developers who browse with an open Web Inspector 😅 ↩︎</a> </li> Cache is warm when it has data to respond without reaching to the origin, and cold when it doesn’t and needs to wait on the origin to respond ↩︎</a> </li> For example, to have a better experience for feature toggles</a> — client-side-only web app has to wait on fresh flags to load. Or risk the UI flashing ↩︎</a> </li></ol></div> Server-side Rendering: The Server Sat, 03 Dec 2022 12:40:00 GMT Backstory was boring. How about some code this time? In the previous part</a> I described how Nebula</a> arrived at the decision to implement server-side rendering (SSR) for the web app. Then came the hard part: actually doing it Goal</h2> Route requests to our server, render the React app as static HTML, and serve that To achieve this goal, the server needs to do just three things: Determine what page is requested</li> Query HTTP APIs for data to render</li> Render HTML</li> </ol> Because the web app is already built on React, react-router</code></a>, and react-query</code></a>, all three were taken care of: react-router</code> picks a page component depending on location.href</code></li> react-query</code> loads data</li> ReactDOMServer.renderToString</code> renders everything to HTML</li> </ol> Wrap everything into an express</code> server, bundle that into a Docker container — and we’re done, easy-peasy Browser APIs</h2> There’s no location.href</code> in Node, just like there’s no window</code>, document</code>, nor navigator</code>. In the case of react-router</code>, it’s not much of a problem, because Node’s request.url</code> does basically the same job. But what about things like window.addEventListener</code>? Usually, a React app would access these APIs only in hooks</a>1</a>, which partially solves the problem — one of the basic hooks, useEffect</code>, isn’t called when a page is rendered to a string (e.g. “on a server”). So it's safe to call Browser APIs there There are still other common patterns of accessing Browser APIs, like initial values for the useState</code> hook or defining some global constant2</a> that won’t change after page load. For these, one has to either mock browser APIs with tools like jsdom</code></a> or check for globals to be defined. The former is rather heavy to do for SSR, so we opted to using window?.</code>/typeof window === 'undefined'</code>, wrapped into a self-explanatory isSSR</code> function Checks</h3> The Nebula web app is written in TypeScript (TS) and it would be nice to express “window</code> might be undefined, but it’s always defined in useEffect</code> body” with its type system. As far as I know, it’s not possible at the moment, so we can’t rely on TS to catch all uses of the Browser API without taking a hit in development experience (“why do I need to check for window</code> in effects?! boo, typescript is bad!”) So we’re checking it with good ol’ smoke tests. Loop over a list of the web app’s URLs, request HTML, check if the response status code is either 200 or 404, and throw a stack trace if the status code is 500. Simple. Two things that complicate things: Some URLs depend on the environment, e.g. a video can be in production but not in staging, and vice versa. Because of these pages, “list of web app’s URLs“ is actually “list of async</code> functions that return URLs” — if a page has consistent URL across environments, it would just return a string, otherwise it can access API to get some video and return its permalink</li> SSR has to return correct HTTP codes. More on that later</li> </ol> Queries and Cache</h2> Okay, next; loading data react-query</code> is a wonderful collection of hooks that greatly simplify working with HTTP APIs3</a>. But, since useEffect</code> isn’t called on a server, SSR has to do querying itself. Thankfully, react-query</code> provides methods to do just that When using react-query</code>, the app has a QueryClientProvider</code></a> somewhere in the React virtual DOM with a QueryClient</code></a> object. This object keeps track of all the API queries created by the child components and holds their state and data. To run those queries in the absence of useEffect</code>, the server has to: Render the page without API data</li> Fetch queries</li> Render the page with API data</li> </ol> The first step is straightforward Running queries is a bit more tricky because they can be disabled (or already loaded/failed, more on that later), but a pair of filter</code>s does the job — one for enabled</code>, another for idle</code> status (= “needs to be fetched”)4</a> function getIdleQueries(queryClient) { const queryCache = queryClient.getQueryCache(); const queries = queryCache.findAll(); return ( queries .filter((q) => q.options.enabled !== false) .filter((q) => q.state.status === 'idle') ); } </code></pre> After we’ve got the queries to run, we create a Promise</code> for each of them and wait for them to settled (i.e. be either resolved or rejected): async function extractAndFetchQueries(queryClient) { const queries = getIdleQueries(queryClient); const fetchPromises = queries.map(async (q) => { const { onSuccess } = q.options || {}; const queryResponse = await queryClient.fetchQuery(q.queryKey, q.options); onSuccess?.(queryResponse); }); const promiseResults = await Promise.allSettled(fetchPromises); // ... } </code></pre> Now queryClient</code> has data for initial render, but some promises might have been rejected. That’s why we’ve saved them in values</code>. If there’s a failed query, we need to get the error for future use on the CDN and clean up them from cache: async function extractAndFetchQueries(queryClient) { // ... const queryError = promiseResults .find(({ status }) => status === 'rejected')?.reason; if (queryError) { queryClient.removeQueries({ predicate(query) { return query.state.status === 'error' }, }); throw queryError; } } </code></pre> After all that, the server does what it needs to do, resulting in this humble virtual DOM root: const renderedHtml = ReactDOMServer.renderToString( <QueryClientProvider client={queryClient}> <StaticRouter location={url}> <App /> </StaticRouter> </QueryClientProvider> ); </code></pre> Are we done?</h3> In theory, now we have our web app rendered with API data — we just insert it into <div id="root"></div></code> in a barebones index.html</code> In practice, Nebula does steps “2. Fetch queries” and “3. Render page with API data” two more times to make sure there are no more idle</code> queries. For example, when loading /jetlag?tab=playlists</code></a>, we first ask API for the channel and, if it was found, for playlists associated with it. But even if the server doesn’t do enough repeats to load everything, it’s okay — the static HTML will include placeholders or default values for a browser to overwrite Additionally, queryClient</code>’s cache is kept for a minute in the server’s memory to skip API requests for frequently needed data, like the list of video/channel categories Plus, the server response is not just HTML, but also… HTTP codes</h2> What if there’s an error from the API? The one that we found in promiseResults</code> and throw queryError</code>? In that case the server should respond with a non-200</code> HTTP code and render whatever HTML is ready. Doing this is important for the CDN layer, web crawlers (to let them know that crawled URL isn’t available), and for our smoke tests mentioned before For the Nebula web app, if the queryError</code> is an AxiosError</code>5</a> with 4XX status, we just pretend that the page is not found: try { await extractAndFetchQueries(queryClient); } catch (e) { if ( axios.isAxiosError(e) && e.response && e.response.status >= 400 && e.response.status < 500 ) { res.writeHead(404, { 'Content-Type': 'text/html' }); res.end(html); return; } throw e; } </code></pre> If the API responded with 5XX or if the SSR server failed to render the page, we just return a 500 status code with Internal Server Error</code> as the body (and a stack trace when not in the production environment). But neither human nor bot visitors will see these three words because we’ll handle that on the CDN Other common HTTP codes are 3XX for redirects. For those, we need to pass a routerContext</code> object to the <StaticRouter></code> component and check if routerContext.action === 'REPLACE'</code> after the virtual DOM is rendered. If so, then react-router</code> would set routerContext.url</code> to the redirect destination User sessions</h2> For several hundred words I’ve avoided mentioning an elephant in the room. Even on a streaming service without The Algorithm, there are personalized pages: Watch History, Watch Later, settings. Surely, SSR should deal with user sessions and authentication, right? Not really Since the app uses react-router</code>, page navigation after initial load is done client-side and SSR wouldn’t be used. Search engine and social network crawlers won’t be authenticated So why bother when rendering session-specific <body></code> on a server would be beneficial only when a human arrives at the site6</a>, while adding: costs — personal responses wouldn’t be cached as often as anonymous ones, so SSR would require more compute resources</li> lag — responses aren’t as cacheable, so there’s an almost a zero chance that local CDN would be used</li> risks — having responses for multiple users in the same runtime attracts awful bugs. Just ask Steam</a>, which had an issue with showing user X data cached for user Y</li> and, obviously, complexity and more code</li> </ul> Updated goal</h2> Waaaaait… If we don’t bother with the individual part of the page, we can also cut the rest of the <body></code>! SSR in Nebula started as a project for search engines and link previews. Both can read the <head></code> tag for all the necessary metadata (and, in the case of Google, can execute JS to compute <body></code> for fuller descriptions and following links) At the same time, cutting the <body></code> tag from the SSR response works around the need to hydrate HTML and CSS after browser executes JS — if there’s nothing inside <div id="root"></div></code>, nothing would flash or jump around because server thought that visitor has a bigger/smaller screen than they actually do. Also, video streaming without JS is possible, but very limiting (both for visitors and developers), so “strict <noscript></code>” folks are kinda on the outside?..7</a> So we can safely update SSR’s goal from Route requests to our server, render the React app as static HTML, and serve that </blockquote> to Route requests to our server, render the <head></code> tag of the React app to static HTML, and serve that </blockquote> We still need to render the virtual DOM and query APIs for the <head></code> tag because it’s rendered with a <Helmet></code> component</a>. But we can throw away renderedHtml</code> value and do this after we’ve done ReactDOMServer.renderToString</code>: const helmet = Helmet.renderStatic(); const renderedHtml = barebonesIndexHtml .toString() .replace(/<html/, '<html ' + helmet.htmlAttributes.toString()) .replace(/<title>[^<]*<\/title>/, helmet.title.toString()) .replace(/<\/head>\s*<body>/, [helmet.link, helmet.meta].join('') + '</head><body>'); </code></pre> This HTML will render <body></code> with an empty <div id="root"></div></code>, but page-specific <title></code> and Open Graph <meta></code> tags. Perfect for bots, basically-the-same-as-before for humans Deployment</h2> Now that we have (almost) complete server, we need to deploy it. This topic is outside of the scope of these blog posts. I mean, it’s either “create a Dockerfile</code>” or “do whatever your custom workflow requires you to do”. Docker is boring and written to death, and I have no idea about your custom workflows 🤷 But, if your workflow includes serving static assets with hashed filenames (like index.2c3.js</code>) from S3 or some other object storage, make sure that these both old and new assets are available during server deployment. You wouldn’t want to have a server respond with HTML that mentions index.2c3.js</code> when it hasn’t been uploaded yet (or have been just removed from S3) To avoid this problem, Nebula’s web deploy workflow keeps static assets on S3 for two calendar years (so, in 2022, there are assets from 2021 and 2022 in the S3 bucket) Also, if your JS bundle depends on the build .env</code>/ENV</code> (for example, create-react-app</code>’s REACT_APP_*</code> environment variables), you’ll need to make it the same when compiling server and client, because while different order of environment variables won’t affect the runtime, it might affect the hash of compiled files, leading to a server expecting index.8ae.js</code> file on S3 instead of just uploaded during the CI/CD pipeline index.2c3.js</code>. Approach that worked for us was: Generate .env</code> during CI/CD setup step with the alphabetically ordered keys</li> Don't use job-specific environment variables</li> </ol> Are we done now?</h2> Kinda?.. The server works, bots get the metadata, developers can forget about the parallel repo and focus on the main one when implementing new pages But have you noticed “(almost)” and multiple mentions of CDN in previous sections? There are more SSR-related things outside of a Node server, and I will talk about CDNs</a> in another post Thank you for your attention Thanks to Sam Rose</a> for help with writing this. Photo by Taylor Vick</a> Hooks are a way to update parts of React app’s layout on user or external signal, like “HTTP request is done“. Without them (or old-style “class components” with predefined methods), layout would be either static or updated fully, after receiving and handling a signal at the root element ↩︎</a> </li> IMO, this even without SSR is a code smell, after dealing with a lot of bugs because the “it won’t ever change” constant did change — user connected new input device, changed some browser/system setting, etc. ↩︎</a> </li> Speaking as the one who’s rewritten API layer from extremely bolierplate-y Redux ↩︎</a> </li> Even though the Nebula web app is written in TypeScript, code snippets here will be in JavaScript for brevity ↩︎</a> </li> Axios</a> being our preferred HTTP client, which, before fetch</code> became a part of Node</a>, was crucial for sharing query loader function across browsers and the server ↩︎</a> </li> Also, when they reload pages and open internal link in new tabs ↩︎</a> </li> Although, some (without any interactivity or video playback) <noscript></code>-friendly layout might be useful. For example, to preview a video page for those who do enable JS on site-by-site basis?.. 🤔 ↩︎</a> </li></ol></div> Server-side Rendering: Backstory Wed, 02 Nov 2022 11:03:00 GMT </iframe> The Whys and Hows of Server-side Rendering • BarcelonaJS </a> About implementing SSR at Nebula </figcaption> </figure> Where I write about the project few months after the fact Video</a> and slides</a> from the BarcelonaJS talk </blockquote> It all started before I’ve joined Nebula</a>. During my job interview there, we’ve discussed benefits and problems of Nebula being a single page application. I, who spent some time</a> dealing with Open Graph</a> for link previews, raised the point that naively implemented, all pages would have the same metadata, which isn’t great for SEO or social sharing. Yeah, Google has enough servers to run JS and compute page’s <title></code> and <meta></code> tags, but I doubted that that’s the case for all messengers, social networks, and blogs1</a> But Twitter and Slack did show those links with nice thumbnails and stuff. Maybe, social networks do run client-side code for Open Graph?.. Aside: some basics</h2> Nebula is a video and podcast streaming service with clients on several platforms. All of them are built on top of common HTTP APIs, some (like Content) are maintained by Nebula team, some (like payments) are third-party Web version is a React</a> application that uses React Router</a> for rendering the correct page content depending on the URL and React Query</a> for dealing with HTTP APIs. The application consists of static files, that are built once during release, uploaded to S3</a>, and served to visitors via CloudFront</a> CDN So, back to social networks. Do they run JS to compute Open Graph data? Nah</h2> Nope, they don't. How, then, was Twitter showing thumbnails in Nebula's link previews? Well, CloudFront distribution from a few lines before wasn’t only serving static files. It also checked request’s User-Agent</code> header and, if it matched the /bot|crawler|spider|crawling|facebook|twitter|slack/i</code> regex, would forward the request to a nebula-meta</code> server application, which would do necessary requests to Content API and return a barebones version of the page, without any client-side code but with URL-specific <title></code> and <meta></code>: </a> Nice class page for humans </figcaption> </figure> </li> </a> Brutalist class page for bots </figcaption> </figure> </li></ul> The fact that nebula-meta</code> existed was largely forgotten, because APIs still worked, Open Graph didn’t change, and its original developer moved on to other parts of the company. But keeping it was problematic: when meta</code> was originally written, Content API was a third-party one (let’s call it Y). Since then, the API became first-party, but we still uploaded images and descriptions to Y, which, at some point, had lead to a head-scratching “stale thumbnail” bug</li> it knew nothing about then-upcoming Nebula Classes</li> it knew nothing about WhatsApp, Telegram, random blogs, and other crawlers that might be interested in Open Graph data</li> it knew nothing about /.well-known/</code> URLs, that both Android</a> and iOS</a> use to associate domains with applications (for things like password suggestions, deeplinks, and SharePlay)</li> having a separate codebase for bot requests just asks for bugs</li> </ul> What then?</h2> So we’ve decided to: start rendering application's pages on a server (i.e. implement Server-side Rendering aka SSR) to keep crawler data in sync with browser data, and to make it easier to tweak and to test crawler-first parts of the site</li> quickly fix small but critical things in meta</code> before diving into 1.</code></li> disable meta</code> after first two points are done</li> </ol> Doing the 2.</code> was a good idea not only because we'll make visible improvements sooner, but also because most of this post was happening in winter of 2021/2022 and russia's invasion of Ukraine would move dates a bit In the next part</a> I’ll talk about how SSR was actually done Thank you for your attention it for sure isn’t for this blog ↩︎</a> </li></ol></div> Thu, 24 Feb 2022 05:57:00 GMT </iframe> The Prodigy - Invaders Must Die (Official Video) • The Prodigy </a> Tour Dates -http://www.theprodigy.comStream or buy all music by The Prodigy - https://prdgy.lnk.to/musicOfficial Prodigy merch - https://prdgy.lnk.to/store S... </figcaption> </figure> ∞</a> Рекомендации, Алгоритмы и Пространство Tue, 24 Aug 2021 15:00:00 GMT Людям, которым нравится Рекомендации</code> также нравятся: Ненавидеть_рекомендации</code> и Диссонанс</code> Автоматические рекомендации, вроде главной страницы Ютуба или персонализированных плейлистов Спотифая, создали в моей голове две противоречащих мысли. Сначала наступила "все видели/слышали то же самое, что и я", которая со временем дополнилась "никто не видел/слышал то же самое, что и я" С первой относительно понятно, особенно если у рекомендованного видео миллионы просмотров. Так "рекомендации" начинают путаться с "популярным", из-за чего думается, что все вокруг уже посмотрели это видео и теперь к нему можно спокойно отсылаться в разговорах Но после пары сотен</del> таких отсылок и последующих непонимающих взглядов собеседников, осознаётся смысл слова "персональные" в сочетании "персональные рекомендации". А раз рекомендации уникальны для меня, то смысл даже пытаться цитировать слова из песни, если в чужом Спотифае этой песни никогда не было?..1</a> Эти диссонанс и трудности с отсылками2</a> настолько напрягают, что решил сформулировать их в текст. И в процессе написания, кажется, нашёл какое-никакое решение… Первая мысль, "все видели/слышали то же самое, что и я", путает автоматические рекомендации с популярностью, потому что традиционные/человеческие рекомендации работают именно так. Если люди в общем со мной пространстве (физическом или цифровом), упоминают XYZ, то, чтобы понимать и быть понятым, XYZ стоит посмотреть/послушать Алгоритмы рекомендаций, конечно, используют физическую (страна/город) и цифровую (фолловинги) локацию, но есть более эффективное пространство для извлечения максимума внимания/времени/денег: ментальное В ментальном пространстве, идею которого я подцепил в замечательной There Is No Antimemetics Division</a>, близость людей определяется близостью мыслей. Люди поблизости в физическом пространстве будут соседями, люди поблизости в ментальном — единомышленниками. Чтобы быть единомышленниками необязательно лично знать друг друга или знать про друг друга. Достаточно иметь общие или схожие идеи. Например, "мне нравится пёсики" или "я боюсь иного"</a> Да, мне могут быть интересны местные новости или видео определённых каналов. Но что то, что другое закончится намного быстрее, чем идеи и настроения. Плавная трансформация от "игра X" к "speedrun'ы</a> игры X" к "speedrun'ы игры Y" более уместна для рекомендаций, чем трансформация от "новости Киева" к "новости Житомира" к "новости Ровно" Взглянув на алгоритм рекомендаций как на нечто, оперирующее в первую очередь именно в ментальном пространстве, диссонанс развеивается. Все в моём ментальном пространстве видели/слышали XYZ, в отличии от людей в физическом/цифровом уголке, в котором я оказался в данный момент Если это, конечно, песня не из начала-середины нулевых. Тогда цитата находится one step closer to the edge</del> understanding ↩︎</a> </li> Которыми зачастую мыслю ↩︎</a> </li></ol></div> If you want to drive a submarine, you gotta join the Navy Sun, 27 Jun 2021 11:23:00 GMT </iframe> Halt and Catch Fire - Intro/Opening song • TheWalkingMan19 </a> The intro to amc's new series halt and catch fireHalt and Catch Fire is an American period drama television series created by Christopher Cantwell and Christ... </figcaption> </figure> If you want to drive a submarine, you gotta join the Navy. Yeah, you might have to salute somebody every once in a while, but... it's better than buying a rickety old diesel boat that sinks you to the bottom of the ocean. </blockquote> За шесть лет с выхода финала второго сезона</a> Halt and Catch Fire</a>, эта цитата оттуда продолжает периодически всплывать на ум Сериал следует за историей и конфликтами вымышленной группы разработчиков и “managerial types”, которые работали где-то рядом с важными для IT событиями в восьмидесятых-девяностых годах: IBM clones, вирусы, онлайн игры, сообщества и коммерция, поисковики и веб-директории… Цитата в начале записи принадлежит managerial co-founder Донне, которая убеждает engineering co-founder Кэмерон в том, что их компании Mutiny лучше партнёриться с провайдерами (и терпеть их повышения цен), чем покупать себе (полурабочий) сервер. И, пожалуй, она права — когда сервера стоят миллион долларов, то жадные партнёры оправданы… Но я думаю об этой реплике не в контексте “необходимое оборудование”, а в контексте работы, где “submarine” — это крупный и известный проект, а “Navy” — компания, разрабатывающая этот проект. И, глядя на прошлые несколько лет, быть в подлодке мне неприятно. Да, сами по себе они интересны (одни только атомные реакторы</del> многомиллионные толпы пользователей чего стоят), но внутри них слишком клаустрофобично, да и задачи они решают сомнительные (или сомнительными средствами) Так что фраза в заголовке этой записи провоцирует вопрос “Do I though?..”. Надёжных недорогих/бесплатных инструментов достаточно, возможных задач на небольшую команду (даже из одного человека) уйма. И когда нравится открытое “море” разработки, на поверхности им наслаждаться лучше, чем запертым в металической трубе. Возможно, иногда заплывая в порты для подзарядки и/или ныряя за богатствами… everywhere is undefined Thu, 03 Jun 2021 20:00:00 GMT Используя скриптовую часть джаваскрипта </iframe> Everywhere is undefined: используя скриптовую часть JavaScript [ru] / Антон Веринов • fwdays </a> Видео с онлайн-конференции JavaScript fwdays'21, которая прошла с 1 по 8 июня 2021 года.Описание доклада:Начав свой путь в браузере, джаваскрипт просочился н... </figcaption> </figure> (адаптировано из выступления на JavaScript fwdays’21</a>. слайды</a>) Я, как и многие разработчики, склеиваю коллажи из старых систем, нового кода, хотелок пользователей и требований бизнеса. Сами по себе, эти коллажи плохо держатся, поэтому их нужно чем-то скреплять. Так сложилось, что я для этого использую джаваскрипт We aimed to provide a “glue language” for the Web designers and part time programmers who were building Web content from components such as images, plugins, and Java applets. We saw Java as the “component language” used by higher-priced programmers, where the glue programmers — the Web page designers — would assemble components and automate their interactions using JS — The A-Z of Programming Languages: JavaScript - Computerworld</a> </blockquote> Это «скрепляющее» свойство было в языке с самого начала, когда с его помощью добавляли щепотку интерактива на страницы. Когда JS был быстро-быстро написан в конце 1995 года, уже существовал способ создания интерактивных элементов на страницу — java applet’ы были представлены несколькими месяцами ранее Но эти апплеты жили в своём отдельном мирке внутри волшебного HTML-тега и требовали отдельной разработки, тогда как джаваскрипт активно пользовался тем, что браузеры неплохо делали даже двадцать шесть лет назад 1995: Browser</h2> (все исходники доступны на гитхабе</a>) <style> body { max-width: 12em; margin: 1em auto; } #lastRoll { font-size: 4em; margin: 0.5em; } </style>  <h1 id="lastRoll">⚃</h1> </code></pre> Представь, что ты написала лучший вебсайт</a>. Да, «вебсайт», потому что до «веб-приложений» социум тогда ещё не созрел. Та и приложения тогда «программами» называли… Короче, лучший вебсайт 1995 года — симулятор бросков кубика. Когда ты его писала, ты фокусировалась на главном — как предоставить посетителям самый случайный кубик — а за «доставку» симулятора и за его графический интерфейс пусть отдувается браузер <style> body { max-width: 12em; margin: 1em auto; } #lastRoll { font-size: 4em; margin: 0.5em; } </style>  <h1 id="lastRoll">⚃</h1> <input type="button" id="roll" value="🔄"></input> <script> roll.onclick = function () { lastRoll.innerText = ["⚀","⚁","⚂","⚃","⚄","⚅"][parseInt(Math.random() * 6)] } </script> </code></pre> Через некоторое время ты слышишь, что многие посетители разоряются на телефонных счетах, потому что ради свежего рандома им нужно держать соединение к Интернету активным. И конечно же, вместо реимплементации и логики, и UI в джава апплете, ты добавляешь кнопку и небольшой скрипт</a>, который дружит её с текстом на странице 20XX</h3> За последующие годы, ты понемножку рефакторишь теперь-уже-веб-приложение — добавляешь историю бросков, немного динамизма, начинаешь использовать новые фишки джаваскрипта, вроде классов и модулей — но его главный принцип, «статическая страница с щепоткой интерактива», продолжает отлично работать</a> const R = (n) => parseInt(Math.random() * n); class Core { static symbols = ["⚀", "⚁", "⚂", "⚃", "⚄", "⚅"]; constructor(options) { options = options || {}; this.symbols = options.symbols || Core.symbols; this.lastRoll = typeof options.lastRoll === "number" ? // 0 < options.lastRoll < this.symbols.length Math.max(0, Math.min(options.lastRoll, this.symbols.length - 1)) : R(this.symbols.length); this.history = options.history || []; } roll() { this.lastRoll = R(this.symbols.length); this.history = [this.lastRoll, ...this.history].slice(0, 10); } pretty() { return { lastRoll: this.symbols[this.lastRoll], history: this.history.map((e) => this.symbols[e]), }; } clear() { this.history = []; } } export default Core; </code></pre> </iframe> mo-dice </figcaption> </figure> То, что браузеры следуют более-менее общему стандарту ECMAScript’а</a>, обусловлено, кроме всего прочего, тем, что им надо показывать одни и те же сайты и, следовательно, запускать одни и те же скрипты. Если какой-то популярный сайт не работает, то тухлые помидоры полетят не только в его сторону, но и в сторону браузера. Если сайт достаточно популярный, то это разработчики браузера кому придётся адаптировать движок под сайт, а не наоборот. Как это делают, например, разработчики Вебкита, "исправляя" движок под кучу сайтов</a> Но не у всего софта, который запускает джаваскрипт, есть требование универсальности. Скрипты под этот софт пишутся только под этот софт, так что где-то можно проигнорировать синтаксический сахар, где-то можно предоставить другие глобальные объекты Одним примером такого софта является nginx. nginx — это веб-сервер, который часто служит как reverse proxy, прослойка между диким интернетом и компьютерами, на которых крутятся веб-приложения. Это прослойка может раздавать статические файлы, направлять запросы на наименее нагружённые сервера, управлять правами доступа вроде «пускай на этот секретный адрес только посетителей с этих айпишников», и заниматься прочими «сисадминскими» штуками Традиционно, если пользователям nginx’а не хватает стандартных средств конфигурации, они используют lua</a> для написания кастомной логики. lua отлично для этого подходит, но её с ней знакомо намного меньше народу, чем с джаваскриптом. Поэтому команда nginx’а добавила в свой сервер поддержку рантайма и диалекта джаваскрипта под названием njs</a> Lua is a good tool in this area, but it’s not as widely known as some other languages. — Launching nginScript and Looking Ahead - NGINX</a> </blockquote> В теории, они могли бы использовать один из браузерных рантаймов и автоматически получить все прелести современного джаваскрипта. Но браузеры больше оптимизированы под долгоживущие страницы, а не под короткие сниппеты кода, выполняемые на пути перед основным сервером. Поэтому</a> команда nginx сделала свой рантайм, в котором реализовала отдельные фичи стандарта 2015: nginx</h2> Будучи ранним адоптером веба, ты, конечно же, завела блог, он же «набор статических файлов, спрятанных за nginx’ом». Из-за твоего прошлого успеха с симулятором кубика, ссылка на блог попадает в круг "успешных" людей, которые начинают спамить комментариями о том, как купить крипту и стать такой же успешной. Чтобы спрятаться от всего этого успеха, ты решаешь пускать к блогу только самых невезучих. Тех, кому кубик всегда показывает единичку Ты берёшь ядро симулятора кубика и делаешь на его основе революционную схему авторизации. Так как джаваскрипт у nginx’а отличается от браузерного, тебе понадобится немного напильника… Так, например, nginx вполне неплохо справляется без классов</a>. А действительно, зачем классы, когда для обработки «куда отправить запрос?» не нужны сотни объектов, каждый со своим стейтом и десятками методов. А если уже приспичит, то и олдового прототипного var Class = function() {}</code> + Class.prototype</code> хватит. В то же время, разделение кода с помощью ES модулей более оправдана даже для короткоживущих скриптов (конечно, большую часть напильника можно заменить автоматической транспиляцией, но это выступление не о настройке вебпака) После адаптации ядра под другой джаваскрипт, нужно и самим немного адаптироваться под реалии сервера</a>, где у каждого из десятков посетителей своя история и ей неплохо жить между перезагрузками нашего сервера. Ядро отлично сериализируется в строку, так что можно сохранять его у куки каждого посетителя Для загрузки состояния из кук нужно парсить эти самые куки. К сожалению (или к счастью) njs не заморачивался с поддержкой npm</code> и node_modules</code>, поэтому придётся копипастить всякое</a>. Лиииибо, можно воспользоваться тем, что предоставляет окружение, и достать уже распаршенное значение из nginx’овых переменных</a> </video> 2017: Google Docs</h2> Продав свой Dice-as-a-service многотриллионой корпорации за миллиарды денег, но оставив за собой права на использование бесценного ядра, ты начинаешь осваивать бухгалтерию. Так как именно веб оплатил твой бутерброд с маслом, бухгалтерию ты ведёшь в Google Таблицах Ты активно используешь кучу стандартный функций</a> Таблиц, для банальной арифметики, обработки текста, статистики, удалённых запросов к гугловым сервисам (GOOGLEFINANCE</code></a>) или сервисам в остальном интернете (IMPORTXML</code></a>) Однако, точность формул в таблицах тебе со временем надоедает. Ты хочешь вернуться во времена шального рандома… Поэтому ты открываешь Tools > Script editor</code> и создаёшь там два файлика — один с любимым ядром</a>, другой — с кастомной функцией ROLL</code></a>… То, что MS Office делает Visual Basic’ом, Google Docs делает джаваскриптом. С его помощью можно генерировать слайды презентации, делать автозамены в текстовых документах, или создавать кастомные функции для вычислений в таблицах В целом, функции в Таблицах вызываются так же, как в джаваскрипте (и других Си-подобных языках), за парой исключений: префикс =</code>, чтобы дать гуглу понять, что у ячейки именно вычисляемое значение, а не текст</li> в качества переменных используются имена (A1</code>) и диапазоны (B2:C3</code>) ячеек</li> </ul> Каждая функция может вернуть либо один результат, либо двухмерный массив значений (тогда изменится значение текущей и прилегающих к ней ячеек) /** * Rolls a die with custom faces. * * @param {string|Array<Array<string>>} faces The value or range of cells * to use as a die faces. * @return A die roll. * @customfunction */ function ROLL(faces) { let symbols; if (Array.isArray(faces)) { symbols = faces.reduce((acc, row) => [...acc, ...row], []).filter(Boolean); } else if (faces) { symbols = faces.toString().split(""); } const core = new Core({ symbols, }); core.roll(); return core.pretty().lastRoll; } </code></pre> Функция ROLL</code> будет принимать в качестве аргумента либо строку со всеми гранями кубика, либо двухмерный массив граней. Так как кастомные скрипты запускаются в V8 на серверах Гугла, то можно использовать довольно современный синтаксис и фичи джаваскрипта, вне зависимости от твоего браузера. За исключением модулей, которые здесь заменены глобальным неймспейсом для всех файлов «скрипта» Теперь, если указать в ячейке значение =ROLL("fwdays")</code>, то функция наградит тебя случайным допамином на основе "fwdays"</code>’а. Или javascript</code>’а Как можно заметить, кастомная функция никак не взаимодействует с прошлыми бросками. Так как кастомные функции каждый раз запускаются в чистом окружении, состояние ядра нельзя сохранить «в памяти», как это делалось в браузере Кроме стандартной библиотеки, у скриптов есть доступ к дополнительным сервисам</a>, вроде HTTP-запросов, парсинга XML’я, или чисто-гугловых переводов и навигации В теории, можно было бы использовать сервис кэширования</a>, который представляет из себя хранилище ключей-значений, привязанных к скрипту и/или документу и/или пользователю Но он довольно бесполезен для кубиков, потому что, насколько я знаю, кастомные функции запускаются только на изменения входных параметров (будь то константы или значения ячеек), а не каких-то внешних (или внутренний) триггеров вроде «эта функция была вызвана в другой ячейке» 2018: iOS</h2> Остановившись на «незапоминающихся» бросках кубиков и насладившись случайными таблицами, ты подвела бюджеты и поняла, что можешь позволить себе айфон. Ты слышала про чрезвычайно умную Siri и, сразу после распаковки и настройки, попросила её бросить кубик. И снова. И снова. Весь этот допамин! Но после того, как телефон дважды подряд выбросил тройку, ты поняла, что тебе не хватает поздравлений с удачей, а Siri оказалась слишком забывчива. Старенькое ядро умеет хранить историю бросков. Ах, если бы была возможность подружить его с Siri… Нативный софт на большинстве эппловых платформ имеет доступ к JavascriptCore</a> рантайму, которым активно пользуются все приложения на React Native. К счастью, этот рантайм подходит не только для кривого повторения нативного UI, но и для взаимодействия с нативными API вроде виджетов</a>, Share Sheet’а, Shortcuts.app, или Siri. Приложение Scriptable</a> занимается именно этим, запуская произвольный джаваскрипт в окружении с байндингами к нативным функциям iOS JSC, а значит и Scriptable, поддерживает современный синтаксис, так что ядро можно скопировать из браузера как есть, за исключением export</code>’а, который надо будет заменить на типа-CommonJS’овый module.exports =</code>, чтобы потом импортировать ядро предоставленной Scriptable’ом функцией importModule()</code> const Core = importModule("core.js"); const fileManager = FileManager.local(); const cachePath = fileManager.joinPath( fileManager.documentsDirectory(), "modice.json" ); function load() { const symbols = [ "единицу", "двойку", "тройку", "четвёрку", "пятёрку", "шестёрку", ]; if (fileManager.fileExists(cachePath)) { try { return new Core({ ...JSON.parse(fileManager.readString(cachePath)), symbols, }); } catch (e) { console.error(e); } } return new Core({ symbols }); } function save(core) { fileManager.writeString(cachePath, JSON.stringify(core)); } function getSpokenRoll(core) { let nth = 0; for (const entry of core.history) { if (core.lastRoll === entry) { nth = nth + 1; } else { break; } } const numeralWord = [ "", "", "второй", "третий", "четвёртый", "пятый", "шестой", "седьмой", "восьмой", "девятый", "десятый", ][nth]; return numeralWord ? `Кубик ${numeralWord} раз показал ${core.pretty().lastRoll}` : `Кубик показал ${core.pretty().lastRoll}`; } const core = load(); core.roll(); save(core); const response = getSpokenRoll(core); console.log(response); if (config.runsWithSiri) { Speech.speak(response); } </code></pre> Для сохранения состояния ядра между запусками, можно читать/писать в локальную файловую систему или в iCloud. Из-за того, что доступа к iCloud’у может не быть Далее, необходимо собрать фразу, которой Siri будет отвечать на твои запросы. Раз кубик будет существовать только на словах, то и его грани могут быть словами, которые будут произноситься. В numeralWord</code> записываем сколько раз подряд был показан последний результат. Склеиваем всё вместе, и отдаём это в Speech.speak()</code> Теперь остаётся только обозначить, что этот скрипт надо запускать в ответ на волшебное слово </video> everywhere</code></h2> Кроме уже перечисленных браузеров, nginx, Google Docs и Scriptable, джаваскрипт можно запускать приблизительно везде и делать им приблизительно всё: конечно же, консольные и серверные приложения (Node.js</a>, Deno</a>)</li> тесты (puppeteer</a>, cypress</a>)</li> дополнения к браузерам (Chrome</a>, Firefox</a>, Safari</a>)</li> кастомные функции в базах данных (sqlite-js</a>, plv8</a>)</li> CDN (Cloudflare Workers</a>)</li> автоматизация macOS (JXA</a>, ScriptKit</a>)</li> PDF!</a></li> железки (Pixl.js</a>)</li> </ul> Этот список уже сейчас неполный, а может быть ещё более неполным, если ты заскриптуешь свой нативный софт. Если V8/JavascriptCore сильно тяжёлые, то есть другие JS движки, вроде duktape</a> и quickjs</a> И так, что же мы сегодня узнали…</h2> </video> Что джаваскрипт джаваскрипту рознь, но если какого-нибудь синтаксиса в этом JS окружении нет, то это необязательно баг или недостаток. Возможно, этот синтаксис бесполезен. Или окружение решает ту же проблему по-своему Что в джаваскрипт приходят люди из разных уголков разработки, каждый со своими ожиданиями и привычками И, наконец, что зачастую лучше довериться пользователям и дать им возможность самим заскриптовать нужную только им фичу, чем пытаться угадать все необходимые конфигурации Спасибо Кристине Ландвитович</a> за помощь в написании этой записи Склепал линкблог Mon, 19 Apr 2021 12:57:00 GMT …из скуки и открытых стандартов За годы своего существования, этот бложек пережил несколько инкарнаций — на Blogger’е, на WordPress’е, на nanograbbr’е1</a>, на Tumblr’е… Когда пришло время сползать с последнего, в центре внимания были статические генераторы вроде Jekyll, Hugo и Wintersmith. Они неплохие, но идея управлять контентом через Git/Github мне как-то не нравилась. Ещё и надо было бы что-то выдумывать с картинками и видео — не добавлять же их в Git2</a> В итоге напилил scroll</a> — генератор с веб-мордой, который работает с парой sqlite баз и, кроме рендеринга markdown’а в HTML, хранит и конвертит</a> картинки в blob’ах. Одних картинок оказалось мало и, когда понадобилось</a> встраивать видео, научил генератор отображать ![](https://example.com/video.mp4)</code> не как <img></code>, а как <video></code>. А где видео, там и Youtube, так что сделал под него special case, чтобы штуки вроде ![](https://www.youtube.com/watch?v=np3QLrHJmRA)</code> заменялись на встроенный видеоплеер Ютуба </iframe> MARINA AND THE DIAMONDS - Obsessions [Official Music Video] • MARINA </a> Official Music Video | MARINA AND THE DIAMONDS - ObsessionsMy new album Love + Fear is out now - https://marina.lnk.to/loveandfearSubscribe to the MARINA You... </figcaption> </figure> Затем захотелось встроить на страницу аудиоплеер Apple Music’а, но не хотелось самостоятельно писать подобные замены под каждый сайт. Хотелось… embeds</h2> …чтобы движок сам понимал, какую картинку показать, какой плеер загрузить. Благо, эта же хотелка была и у фейсбука с твиттером, которые убедили кучу сайтов и сервисов подобавлять на свои страницы <meta></code> теги с необходимой для красивых превьюшек информацией для реализации Open Graph’а</a>. Мне же оставалось только распарсить всё это добро и сгенерировать подходящие <img></code>/<video></code>/<audio></code>/<iframe></code> Чтобы не приходилось ждать внешних HTTP-запросов на каждую регенерацию сайта, неплохо было бы кэшировать ответы. Тут факт использования sqlite сильно упростил задачу — намного проще сохранять ответы в какую-никакую базу, а не в текстовые файлы, которые ещё надо было бы коммитить в репозиторий… Так движок начал проверять</a> content-type всех ![](типа картинок)</code>, сохранять</a> og:</code> теги (если это не картинка, а text/html</code>), и генерировать</a> красивые карточки на основе всех этих данных3</a>. В результате, такой markdown: - ![](https://open.spotify.com/track/7tyt9usWqEPPDbyL6CgBs4) - ![](https://coub.com/view/2pc24rpb) - ![](https://giphy.com/gifs/tiktok-dogs-puppy-cute-dog-l2uluGTvB7DAQvZyHp) </code></pre> генерирует такой контент: </audio> The Complexity of Light • Spotify </a> Children of Nova · Song · 2009 </figcaption> </figure> </li> </iframe> PARADISE BEACH • Coub </a> by Ilya Trushin </figcaption> </figure> </li> </video> Golden Retriever Dogs GIF by TikTok - Find & Share on GIPHY • TikTok </a> Discover & share this TikTok GIF with everyone you know. GIPHY is how you search, share, discover, and create GIFs. </figcaption> </figure> </li> </ul> Может, стоит завернуть эту часть scroll’а в простенький сервис?.. 🤔 Всё в RSS</h2> Параллельно, вне исходников scroll’а, начал собирать хоть сколько-то долгий контент в RSS. Я уже рассказывал</a> про paperss</a>, который генерирует фид из Instapaper’а. Кроме него, в RSS перетащил ещё и свои Youtube-подписки, подальше от заманчивых лабиринтов рекомендаций И всё это время думал о том, как бы делиться хорошими ссылками. Не отличными, для которых не лень написать пять-десять слов описания и запостить в твиттер/слак, а именно хорошими. Feedbin</a>, которым я синхронизирую RSS-подписки, позволяет отмечать записи звёздочками, из которых он даже генерирует отдельный RSS-фид Это почти то, что мне нужно, но: отмеченное звёздочками живёт где-то сильно вне этого блога/твиттера/чего-то ещё;</li> RSS-фид содержит полные записи и было бы некрасиво, по отношению к оригинальным авторам, дублировать их у себя;</li> одних только названия и ссылки кажется маловато</li> </ul> Ах если бы был способ красиво показать ссылки на другие сайты… Наконец-таки линкблог</h2> Подружив opengraph’овые “карточки” с Feedbin’овскими звёздочками, в которые входят статьи из Instapaper’а, получилась и простая в создании, и приятно выглядящая лента ссылок</a> Для меня, интерфейс работы с линкблогом полностью4</a> спрятан в RSS-ридере: читаю статьи и смотрю видео так же, как всегда, но теперь нажатие на ⭐️ менее бесполезное и создаёт немного работы для scroll’а, который: раз в приблизительно полчаса, проверяет</a> RSS-фид Feedbin’а</li> если там появился новый контент, сохраняет его в базу</a> и заново генерирует необходимые страницы (linkblog.html</code></a>, feeds/linkblog.xml</code></a>, index.html</code></a>)</li> в процессе генерации этих страниц, загружает</a> для каждой ссылки необходимые <meta></code> теги</li> </ul> </video> Больше всего проблем было с тем, как же показывать линкблог на главной странице — стандартные карточки слишком большие и отвлекали бы от основных записей, а в уменьшенные версии влезает слишком мало текста. В итоге остановился на том, что на главной странице показываю только картинки Красота</a> Кажется, про него не осталось ничего, кроме древних переписок в Google Groups</a> ↩︎</a> </li> Да, да, есть Git LFS</a>, но 🤫 </video> ↩︎</a> </li> Неплохо бы разбить на части этот здоровенный файл и причесать его, но лень. Да и не то, чтобы кому-то, кроме меня, понадобится в нём что-то править. А если хочешь сказать, что код ужасный и мне следует его стыдиться, смотри гифку в предыдущей сноске ↩︎</a> </li> Ну ладно, почти полностью. Если ссылка не из подписок, а из твиттера или переписок, то для публикации в линкблог, её надо сначала добавить в Instapaper. Ну и в закулисьи блога есть кнопка для ручной проверки обновлений ↩︎</a> </li></ol></div> Code review & response Mon, 22 Mar 2021 10:52:00 GMT aka «The Hard Part» Колега написала код, опублікувала та описала його. Тобі прийшло повідомлення, що вона призначила code review на тебе. Що робити далі? Серія записів про code review: Навіщо?</a></li> Створення pull request’у</a></li> Думки про pull request assignee</a></li> Code review & response</a></li> </ol> Англійською: On Code Reviews</a> Слухати</h2> У кожної зміни в pull request’і є ціль. Окрім очевидних зовнішніх «виправити баг», «додати фічу»1</a> і «оновити код/залежності», ціль може бути внутрішньою, наприклад: бути проміжним кроком у виправлені багу/додаванні фічі («ця функція експортується, тому що вона використовується в неопублікованому коді»)</li> вирівняти існуючий код з ментальною моделлю у голові авторки pull request’у («воно було незрозуміло, я переписала, щоб стало зрозуміліше»)</li> підвищити зручність розробки («я вмію робити grep</code>, а цей файл цьому чинив сильний опір»)</li> </ul> Ревʼювер може не погоджуватися з цінністю кожної окремої цілі або шляху її досягнення, але для гарного code review треба їх знати і, за необхідністю, вирівнювати їх з цілями решти проєкту Тому перед тим, як шаленіти через "говнокоду" (що б це не значило), задумайся над ціллю, яку переслідувала авторка. З зовнішніми цілями тобі допоможуть текст задачі або фонові обговорення. Внутрішні ж найчастіше можна зрозуміти хіба що за контекстом в історії комітів або в описі pull request’у Якщо ж контексту авторка залишила небагато, то можна допомогти собі фільтрацією змінених файлів</a>, переглядом її минулих змін</a>, локальним підняттям гілки pull request’у, спробою переписати «дивне рішення» з урахуванням «ну, це ж так не робиться»… Ну, або у краааааайньому випадку, можна запитати її напряму Говорити</h2> Кожен коментар ревʼювера, так само як і кожна зміна у pull request’і, служить для чогось. Наприклад, за допомогою коментарів, ревʼювер може… Дізнаватися</h3> «Жанр» коментарів, який є найбільш наближеним до головного призначення code review</a>, але який рідко використовують, це «Чому написано саме так?». Навіть коли усі учасники дискусії знають причину, але вона ніде не згадана явно, необхідність сформулювати відповідь допоможе помітити надмірну складність Якщо вони думають, що знають причину, то явне формулювання точки зору однієї з учасниць code review може виявити випадки, коли ці знання є лише припущеннями. А припущення ведуть до багів, тож іноді краще уточнити щось «очевидне». Якщо ж це «очевидне» вже було десь розписаним, то нічого жахливого у тому, щоб отримати посилання на коментар2</a> з відповіддю або на коміт з поясненням На жаль, цей жанр не лише найважливіший (на мою думку), але й найнебезпечніший. Прочитавши «Чому написано саме так?» у поганому настрої, я можу накрутити себе думками «та як це вони сумніваються у моїй праці?!» та/або «схоже, тут так неможна, тому, замість відповіді на питання, я усе зараз же перепишу». Тому дуже важливо дати авторці pull request’у зрозуміти, що у твоєму питанні немає ніякого прихованого сенсу. У тексті інтонація передається надзвичайно погано. Тож, щоб текстом коментар читався настільки ж позитивно, як якби його було почуто вголос, цю недостачу інтонації треба компенсувати. Наприклад, перефразувавши питання, виділивши наголос курсивом, явно написавши «пробач, я тут ні про що не натякаю», або додавши краплю емоцій емоджами </a> Sarah's Scribbles </a> Tumblr Blog </figcaption> </figure> Коригувати</h3> Набагато популярніший жанр коментарів до pull request’ів — це «тут неправильно». Багато хто вважає, що ці коментарі — найважливіше у code review. Так, додаткова пара очей допоможе виявити проблеми раніше, але, повертаючись до початку цього запису, виключно важливо розуміти цілі змін перед тим, як їх критикувати. Без цього розуміння, обидві сторони code review будуть псувати настрій одна одній — або шкідливими порадами, або поверхневими правками для «відстань» Chesterton's Fence: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it." </blockquote> </a> Lars "Sweet Leaf" Doucet on Twitter </a> </figcaption> </figure> І навіть якщо ти знаєш, яку ціль переслідувала авторка в цій зміні, то…3</a> Зовсім необовʼязково просити виправити кожен рядок, в якому бачив проблему. По-перше, проблеми може не бути, тоді «чому?» спрацює краще. По-друге, особистий досвід запамʼятовується краще чужого, тож якщо проблема некритична та/або швидко проявиться та/або легко сховається від користувачів, то десять хвилин паніки навчать багато чому. Наприклад, сім років тому, я так навчився що нові фічі треба ховати за feature toggle</a> і що кеш треба інвалідувати Коли ж проблема дійсно варта коментаря, то усі схожі коментарі краще залишити за раз, щоб не затягувати час до закриття pull request’у очікуванням фіксів/коментарій. Іншими словами, «коментар-коментар-фікс-фікс» краще за «коментар-фікс-коментар-фікс» Окрім вказівки на проблему, ревʼювер може запропонувати її вирішення. Github дозволяє зручно це зробити</a> прямо у веб-морді </li> </li> </ul> Якщо маєш гарні відносини з авторкою pull request’у і ви не сумніваєтеся у здібностях одна одної, то можна склонувати собі гілку і запропонувати покращення у вигляді комітів. Куди пушати ці покращення — у нову гілку (з відкриттям pull request’у до pull request’у4</a>) або в ту ж саму — залежить від того, як до цього відноситься авторка оригінальної гілки. Це, як і «дозволити помилитися», доволі ризикований шлях, але він існує Повертаючись до втрати інтонацій в тексті… Якщо людина може неправильно зрозуміти невинне «чому?», то «я написав код для твого pull request’у» або яскраво червоне «@username</code> requested changes» точно рано чи пізно будуть прийняті особисто. Тож їх треба навмисно помʼякшувати або хоча б нагадувати усім, що це критика коду, а не людини Але навіть «@username</code> requested changes» краще тиши Форматувати</del></h3> Що не треба коментувати, так це крапки-з-комою, відступи та інше форматування. Якщо форматування коду дійсно важливе, то замість написання коментаря «ми ставимо пробіли всередині фігурних дужок», витрати свої зусилля на просте автоматичне виправлення форматування5</a> і на запуск лінтеру в CI-середовищі6</a> Без цього, ревʼюверу треба постаратися, щоб утримати фокус на сенсі pull request’у і не перемикатися на коментування поверхневих та часто марних для кінцевих користувачів «відсортуй імпорти за абеткою» Мати на увазі</h3> Коментарі ревʼюверів можуть бути адресовані не виключно авторці pull request’у, але і іншим колегам Наприклад, щоб звернути увагу до складності інтеграції з API іншої частини системи. Або до більшої-ніж-хотілося-б кількості мануальних змін там, де рефакторінг/типи/автоматизація спростили б та скоротили б майбутні pull request’и. Або до схожості нового коду на код у іншому проєкті і до можливого code share Одразу реалізувати ці коментарі, у тому ж pull request’і, скоріш за все, зайве збільшить його scope, але, через пару таких коментарів-нагадувань, буде легше згадати про них підчас планування наступного спрінта Заохочувати</h3> Якщо після відкриття pull request’ів отримувати лише описані раніше нейтральні та відносно негативні коментарі, то звичайно люди будуть уникати code review — «Я намагалася, працювала, оминала проблеми, тільки щоб перед самим фінішем слухати, що тут дивно, тут неправильно, тут погано…» Тому, у противагу всьому цьому, корисно хоча б іноді хвалити особливо хороші зміни, будь то витончене вирішення проблеми, гарна ідея (яку ревʼювер може застосувати у своєму коді), або банальне «дякую, давно болить, але руки ніяк не доходили» Без коментарів, code review — це лише вахтерство. З коментарями лише з серії «тут неправильно, виправ» — шкидливий gatekeeping. Сподіваюсь, цей запис продемонстрував, що з правильними коментарями, pull requestʼи стають набагато корисніше всім його учасникам Дякую Богдану Бузу та Олександру Вєрінову за допомогу у написанні цього запису Перформанс та документація також є фічами ↩︎</a> </li> І, ймовірно, уїдливе «варто б було б це знати» від людини, яка сама тільки вчора про це дізналася ↩︎</a> </li> У наступного абзацу далеко не нульовий ризик зробити мене ще більш unemployable ніж я є зараз ↩︎</a> </li> BRAAAAM</a> ↩︎</a> </li> Бажано з мінімумом налаштувань, щоб не було спокуси витрачати час на життєво важливих питань на кшталт «подвійні лапки чи одинарні?». наприклад, eslint:recommended</code></a>/prettier</code></a>/standard</code></a> в джаваскриптовій екосистемі, black</code></a> в пітонячій, gofmt</code></a> в Go, та .editorconfig</code></a> приблизно усюди ↩︎</a> </li> І, будь ласка, не виправдовуй відсутність лінтеру на CI наявністю git hook’ів. Хуки можуть не запускатися з тієї чи іншої причини, наприклад коли коміт було зроблено через веб-морду Github’у. Тож, без лінтеру на CI, головна гілка буде з поламаним форматуванням частіше ніж бажалося б (а бажалося б «ніколи») ↩︎</a> </li></ol></div> Думки про pull request assignee Sun, 07 Mar 2021 12:18:00 GMT Уважно обирай авдиторію В кінці запису про створення pull request’у</a>, я мимохіть згадав assignee Додай в assignee зацікавлених колег (будь то окремі люди або цілі команди) </blockquote> Нібито це настільки легко та настільки малозначно… Серія записів про code review: Навіщо?</a></li> Створення pull request’у</a></li> Думки про pull request assignee</a></li> Code review & response</a></li> </ol> Англійською: On Code Reviews</a> You are Reviewer Zero</h2> Нульовим ревʼювером є сам автор pull request’у. Звичайно, ніхто не заважає забити і переключитися на іншу задачу після того, як передав естафету колегам, але перегляд знайомого коду в новому середовищі (UI code review вместо UI code editor’а) або через деякий час (коли усі «очевидності» забулися) допоможе самостійно помітити помилку або який-небудь дивний момент Я иногда делаю ещё так - после публикации своего PR я сам же ему делаю Review (в Github можно прокомментировать свой PR, но без Approve). Это позволяет добавить комментарии/контекст конкретно к тому коду, которого это касается — гарний коментар до попереднього запису </blockquote> Особливо зручно це робити у чорновому pull request’і</a>, який нібито вже створено та має перевірки на CI, але ще не повідомив про своє існування code owner’ам</a> Кому дивиться</h2> У невеликих проєктах з щільною командою, питання «кому кинути на ревʼю» вирішується сам собою — ти або кидаєш усім (тому що вас небагато), або ти знаєш відповідальну за ту чи іншу частину коду і кидаєш їй В більш… динамічних проєктах та командах, через розміри та поганий звʼязок, ситуація може бути складнішою. Найчастіше, це вирішено згадкою у code owner’ах або цілих команд, або «володарів думки» (тімліди/техліди/сініори/тощо). Обидва шляхи створюють свої проблеми Команди у code owner’ах</h3> Команда у ревʼюверах створює ризик того, що кожен учасник команди вважатиме що перегляд твого pull request’у — чуже завдання. Наявність «чергових»/«oncall» в команді не рятує — якщо pull request було створено у вечір пʼятниці, коли я був черговим, то у понеділок я думатиму «тепер це проблема сьогоднішньої чергової Олени» і забити. Олена, в свою чергу, також може справедливо забити — pull request же пʼятничний, а в пʼятницю чергувала не вона Плюс, новачки в команді можуть соромитися коментувати — раптом щось не помітять або поставлять «дурне» питання. А якщо в ревʼюверах уся команда, то можна причаїтися і перечекати Команда в assignee може мати і протилежний ефект, коли усі-усі-усі поспішають зробити коментар, не вдаючись у подробиці1</a>. В теорії, автор pull request’у може вкласти час та зусилля на відповідь усім "роззявакам", але це складно, виснажує, і може потребувати виправдань начальству, якщо воно вважає що «твоя задача — вирішувати проблеми з кодом, а не вчити джунів в інших командах» Володарі думки у code owner’ах</h3> Наявність когось, через кого будуть проходити усі pull request’и, звичайно, має свої плюси, наприклад, більш консистентний стиль і вища шанс помітити конфлікт з неявним припущенням в проєкті Але безглуздо очікувати (або вимагати), що одна людина буде уважно пропускати через себе увесь контекст з тією ж швидкістю, з якою решта команди пише код. У трикутнику «багато/швидко/уважно» обрати усі три неможна. Навіть два не завжди вдається… Я не знаю, як однозначно вирішити обидві проблеми. Але впевнений, що: на кожен окремий pull request краще призначати не усю команду, а окремих людей, навіть якщо єдиний їх внесок буде «перепризначити більш відповідній людині»</li> дуже важливо уникати створення людини-bottleneck’а, яка недовго протримається під тиском начальства та колег</li> дивитись pull request’и мають не лише ліди/сініори, але і джуни. Інакше без джунівського «що тут відбувається?» усе відлетить у стратосферу на абстракціях, а спростити код у момент code review набагато простіше, ніж після нього</li> </ul> Після цієї примітки, тепер точно можна говорити про процес з точки зору ревʼюверів</a> Дякую Каті</a> за нагадування ↩︎</a> </li></ol></div> Створення pull request’у Sun, 21 Feb 2021 15:45:00 GMT The Repo With A Thousand Faces Серія записів про code review: Навіщо?</a></li> Створення pull request’у</a></li> Думки про pull request assignee</a></li> Code review & response</a></li> </ol> Англійською: On Code Reviews</a> При написанні pull request’у (PR), корисно керуватися принципом «вклади на оформлення стільки ж часу та/або зусиль, скільки хочеш щоб витратили на ревʼю» Якщо автор не вкладе час на те, щоб зібрати усе до купи, тоді ревʼювери матимуть це зробити у голові. Навіть якщо ревʼювери знають про особливість у коді, вони можуть про неї не згадати підчас читання PR, тому що голова зайнята мережею звʼязків, які автор вирішив не полірувати Якщо автор проґавить у описі PR момент, який змусив його обрати менше зло, ревʼювер так саме проґавить цей момент підчас написання коментарів Github Stories</h2> Як я писав минулого разу</a>, PR’и створюються для отримання досвіду та/або думки зі сторони. Для того щоб колега могла скласти цю саму думку, для початку вона має зрозуміти, що ж відбувається у коді. Знаючи це, можна зробити правильний або неправильний висновок: неправильний висновок: «якщо колеги розуміють — пощастило, якщо ні — це повністю їх проблема»</li> </ul> неправильний висновок: «я можу зробити PR менше або більше зрозумілим»</li> </ul> Для того, щоб колезі було легше сприймати PR і ділитися доречним досвідом, їй треба знати «як було раніше», «що змінюється», «чому саме це має змінитися», «як змінюється» и «чим стає». Зміни безпосередньо коду відповідають на деякі з цих питань Наприклад, ліва/червона частина diff’у відповідає на «що змінюється», а права/зелена — на «чим стає». З рештою питань треба занурюватися у прозу Якщо ця проза — це сухий набір фактів, то ревʼювери матимуть самостійно їх звʼязувати. Щоб спростити це, автор PR може обʼєднати їх у історію про транcформацію</a>, у якій головний герой — це репозиторій, до якого відкрито PR Ми розуміємо і витягуємо «суть» з історій, тому що роками чуємо/читаємо/дивимося їх. Плюс, наш мозок сприймає код як головоломку</a>, тож ми можемо помилково ігнорувати наслідки змін — головоломку ж вирішено, кінець, з нею більше нічого не станеться… Тому має сенс розповідати історії і підчас написання PR. І у тебе є багато можливостей для цього1</a> Words Mean Things</h2> Оповідання можна почати задовго до натискання «New pull request» — у самому коді. Навіть без коментарів, ти можеш описати «основних діючих осіб» у іменах файлів, функцій та змінних. Гарне імʼя сутності опише, що і навіщо вона, покаже звʼязок з іншим кодом, і допоможе з її обговоренням. Тому важливо уникати загальних назв (на кшталт utils/data.js</code>) та спільних імен для позначення різних речей, і звертати увагу на існуючі імена — якщо фіча вже називається wunderwaffle</code>, то не починай раптово називати її terrifictiramisu</code>. Звичайно, якщо зрозуміла, що файлу більше підходить інша назва, то, хоча ґіт і розумний, зазвичай краще явно зробити git mv A B</code> — так зберігається історія і простіше створювати коміти Імʼя гілки допоможе сфокусувати PR і не відволікати себе та ревʼюверів на другорядні «сюжети». Таким чином, у гілці JD-48/speed-up-uploads</code>, можна спіймати і зупинити себе від оновлення усіх залежностей у проєкті JD або від змін у завантаженні файлі у проєкті ER The Medium is the (Commit) Message</h2> Якщо ж тебе все-таки занесло і у гілці вже купа змін, які не повʼязані з основною метою PR’у, але вони будуть корисні для проєкту та/або іншого проєкта, то можна погратися зі змістом комітів. Замість коміту з усіма змінами у файлі, нічого не заважає додати ті зміни рядково. Поціновувачі CLI можуть зробити це з git add --patch</code></a> або git add --interactive</code></a>, я же звик до інтерфейсу Tower’у</a> для цього Як зрозуміти, які рядки доречні у одному коміті, а які — у іншому? Подумай, де ці рядки опинилися би у «сюжеті» PR’у, і опиши це у імені коміту, обмежившись 50 символами, які рекомендує git</a>2</a>. Можливо, ця історія — короткий анекдот, і fix A when B</code> буде достатньо. Можливо, у «сюжеті» PR’у декілька персонажів, з якими спочатку треба познайомити читача (add X to do Y</code>), а потім вже один до одного (use X in Z</code>) Describe your changes in imperative mood, e.g. «make xyzzy do frotz» instead of «[This patch] makes xyzzy do frotz» or «[I] changed xyzzy to do frotz», as if you are giving orders to the codebase to change its behavior. Try to make sure your explanation can be understood without external resources. Instead of giving a URL to a mailing list archive, summarize the relevant points of the discussion. — SubmittingPatches - The core git plumbing</a> </blockquote> Також, у багатьох проєктах налаштована інтеграція між Git та Jira, для того щоб підвʼязувати коміти та/або гілки до тікетів. Тому часто має сенс згадати номер тікету у імені коміту, наприклад #JD-48 cache responses from X</code>. Формат (XX-00</code>, $XX-00</code>, #XX-00</code>) відрізняється від проекту до проекту, але тому ж Github’у достатньо будь-якого префіксу перед цифрами</a> для того, щоб відобразити номери тікетів як посилання на них Ще, багато хто є послідовниками conventional commit</a> і додають теги на кшталт feat</code> та chore</code>. Мені ці теги здаються марними для продукту без публічного CHANGELOG’у, але звичка категоризувати зміни може допомогти з фокусуванням PR’ів та комітів Retelling the Story</h2> Якщо наплутав з порядком комітів, то його можна виправити за допомогою git rebase --interactive</code></a>, з яким можна легко переставити/переписати/обʼєднати/взагалі викинути коміти, редагуючи текстовий файл зі списком операцій та комітів Наприклад, ми працювали у гілці JD-48</code>, де написали пʼять комітів. Локальна історія комітів зараз виглядає якось так (git log --graph --oneline --all</code>, нові коміти зверху) : * f4593f9 (HEAD -> JD-48) add tests for X-Y integration * 04d0fda optimize Y * ba46169 integrate X with Y * fa1afe1 tests for X * 5928aea setup X * 300a500 (master, origin/master, origin/HEAD) … </code></pre> git rebase --interactive "5928aea^"</code> відкриє у текстовому редакторі3</a> файл з такими рядками: pick 5928aea setup X pick fa1afe1 tests for X pick ba46169 integrate X with Y pick 04d0fda optimize Y pick f4593f9 add tests for X-Y integration </code></pre> Кожен рядок — це операція, яку треба виконати підчас створення нової версії гілки. За замовчуванням, rebase бере і застосовує кожен коміт (pick</code>). Крім цього, коміт можна пропустити (drop</code>), обʼєднати з попереднім (squash</code>), застосувати-з-можливістю редагування (fixup</code>); також можна змінити порядок комітів (перестановкою рядків) або виконати довільні shell-команди (exec</code>) Наприклад, якщо ми хочемо: перенести коміт з тестами (fa1afe1</code>) в кінець гілки;</li> обʼєднати його з тестами інтеграції (f4593f9</code>);</li> і викинути коміт про оптимізацію іншої частини проєкту (тому що PR про нову фічу, а не про оптимізацію)</li> </ul> то треба відредагувати «сценарій», який згенерував git rebase --interactive</code>, до такого: pick 5928aea setup X pick ba46169 integrate X with Y drop 04d0fda optimize Y pick fa1afe1 tests for X squash f4593f9 add tests for X-Y integration </code></pre> Або можна не хизуватися і переписувати історію за допомогою мишки у GUI, наприклад у вже згаданому Tower’і</a> Після того, як гілка та коміти відполіровані, можна взятися за імʼя та опис PR’у. Вони, здебільшого. пишуться аналогічно до комітів, але більш високорівнево Що писати у описі pull request’у?</h2> Зазвичай, для мене найскладніше у описі PR’у — це почати. Чистий лист</del> <textarea></code> багатьох блокує В деяких репозиторіях є PULL_REQUEST_TEMPLATE.md</code>, який може допомогти з цим, але у приватних проєктах часто або його нема, або він доволі безпорадний для надання контексту: # Summary ... --- - [ ]  ci-bot, do something </code></pre> Також, з порожнім <textarea></code> можуть допомогти імена та описи комітів. Якщо ж їх недостатньо, то почни з «Коротше, є іменник</code> і воно дієслово</code>» і обвішай цей вступ контекстом Цим контекстом можуть бути: причини для змін (тільки не «мені менеджер сказала», а «у користувачів проблема»)</li> дивні місця, де здається що можна краще, але ліньки або не знаєш як. Можливо ті дивності не є проблемою, можливо хтось знає гарне рішення, можливо хтось вмотивує здолати лінь</li> посилання на повʼязані тікети та PR’и; на документацію нових/дивних моментів; на відповіді з StackOverflow, з яких ти скопіював той сніпет…</li> </ul> Доречі про посилання. Десять хвилин на вивчення Markdown’у 4</a> допоможуть з тим, що ці посилання а) не заважали читати і писати опис; б) знаходились у правильному місці Наприклад, порівняй читабельність тексту з різними стилями посилань: There’s [`<input type="color">`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/color), but we [can’t use it](https://caniuse.com/#feat=input-color) yet in all of [our supported browsers](https://kb.example.com/supported-browsers) </code></pre> There’s `<input type="color">`, but we can’t use it yet in all of our supported browsers Links: - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/color - https://caniuse.com/#feat=input-color - https://kb.example.com/supported-browsers </code></pre> There’s [`<input type="color">`][mdn], but we [can’t use it][caniuse] yet in all of [our supported browsers][kb] [mdn]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/color [caniuse]: https://caniuse.com/#feat=input-color [kb]: https://kb.example.com/supported-browsers </code></pre> Передача естафети</h2> Після того, як уся проза написана, їй потрібна авдиторія. Додай в assignee зацікавлених колег (будь то окремі люди або цілі команди) і, закінчивши з текстом на Github’і, можна витратити хвилинку на «анонс» pull request’у у робочому чаті і видихнути, поки колеги читають, вивчають, та коментують Перегляд PR’у заслуговує окремого запису, до якого я повернусь після того, як поділюсь парою думок про assignee</a> Ще раз підкреслю, що далі будуть можливості для покращення pull request’у, а не вимоги до нього. Якщо раніше обходився особистим обговоренням і парою слів у назві, то ніхто не змушує тебе витрачати години на написання епопеї про зміну трьох рядків 🙏 ↩︎</a> </li> Коли одного рядка у 50 символів недостатньо, імʼя коміту можна і треба доповнювати додатковим описом (або додавши перенос рядка, якщо працюєш через git</code> CLI, або використавши окреме тестове поле у GUI), будь воно написаним з нуля або згенерованим з шаблону</a> (дякую Марку</a> за пораду) ↩︎</a> </li> Якщо не подобається vi</code>, то зміни $EDITOR</code> у своєму ~/.bashrc</code>/~/.zshrc</code>/~/.config/fish/config.fish</code></a> щоб запускати, наприклад, Sublime Text (subl -w</code>) або будь-який інший текстовий редактор ↩︎</a> </li> Будь то «оригінальний» варіант Груберу</a>, більш деталізовані GitHub Flavored Markdown</a>/CommonMark</a>, або взагалі інша мова розмітки, яку використовує твій інструмент для code review ↩︎</a> </li></ol></div> Навіщо code review Mon, 15 Feb 2021 10:10:00 GMT Можливо, я один такий, але мене дратують жарти типу 10 lines of code = 10 issues. 500 lines of code = "looks fine." Code reviews. </blockquote> </a> I Am Devloper on Twitter </a> </figcaption> </figure> Ну, тобто сам жарт ок — i-know-that-feel.png</code>, #relatable</code>, усе таке. Але у ньому кілька прикладів поганої поведінки і авторів коду, і ревʼюверів: поверхневі коментарі;</li> величезні патчі;</li> нестача контексту;</li> читання «по діагоналі»</li> </ul> Тож якщо проблеми з code review настільки поширені, то на них треба не лише показувати пальцем, але і якось виправляти. Зробити це можна або зовнішними вимогами/обмеженнями, або внутрішньою мотивацією Вимагати «будь краще» — глупо. Автоматично відсікати code review через метрики — не варіант, тому що «зрозумілість» не виміряти скріптом. Тому «покращити code review зовнішніми вимогами/обмеженнями» відпадає Вплинути на внутрішню мотивацію можна особистим прикладом, але після років спроб, це здається занадто повільним і не те щоб надійним. Можливо, особистий приклад буде швидше донести словами Серія записів про code review: Навіщо?</a></li> Створення pull request’у</a></li> Думки про pull request assignee</a></li> Code review & response</a></li> </ol> Англійською: On Code Reviews</a> Час та місце</h2> Я працював</a> лише у доволі зрілих продуктових компаніях. Коли компанія роками працює над продуктом, внесок часу та зусиль у code review виправдано не лише через «ну, це правильно», але і через спрощення підтримки у довгому строку Зовсім молоді продукти, для яких того самого довгого строку може ніколи і не бути, ризикують тим, що після усіх review залишиться лише «правильний», але нікому не потрібний код Як виглядають справи з клієнтською роботою (агенції/аутсорс/аутстаф) я не знаю. З одного боку, якщо клієнт повернеться за доопрацюванням через рік-другий, минулі code review допоможуть швидше згадати/впізнати кодову базу. З іншого — клієнт може ніколи не повернутися Тож code review може бути зовсім марним (або взагалі шкідливим) на твоєму місці роботи. Або він був таким на минулому місці роботи твоєї нової колеги… Мотивація</h2> Окей, припустимо ти працюєш у відповідній команді, у відповідний час, і тобі дуже хочеться краще писати та коментувати pull request’и. Щоб знати напрямок для покращень, треба розуміти, яка мета code review Тож, навіщо проводити code review? Мені сказали, що тут так прийнято </blockquote> «Так історично склалося» — поганий шлях до покращень. Він приведе туди ж, звідки він почався. Навіть нема буде про що розповісти (якщо тобі не подобаються історії, в яких нічого не відбувається) Щоб ідіоти нічого не поламали у моєму ідеальному проєкті </blockquote> Ці «ідіоти» відкрили PR тому що їм треба щось виправити або щось покращити. Якщо твій ідеальний проєкт не тримається на плаву лише завдяки твоєму gatekeeping’у, то краще спрямуй зусилля в написання тестів і налаштування</a> лінтеру Щоб зловити те, що важко або взагалі неможливо покрити тестами </blockquote> Тепліше… Але «володарям знань» швидко набридне вдивлятися сотні та тисячі рядків коду у пошуках одних і тих самих проблем, з якими стикаються колеги, незнайомі з репозиторієм З «зробити собі побільше рутини» виходить погана мета. Хотілося б, щоб воно саме Але новачки репозиторію (саме репозиторію — в них може бути величезний досвід розробки взагалі) не знають, що {placeholder}</code>створить проблеми. А досвідчені вже настільки часто стикалися з {placeholder}</code>, що інстинктивно його уникають </video> Тому, щоб воно саме, автори та ревʼювери мають обмінюватися особистим розумінням проєкту: автори явно та неявно вказують на дивину у існуючому коді. Наприклад, що для досягнення простої мети треба зробити купу ручної роботи</li> ревʼювери діляться базовими припущеннями, на яких працює проєкт, на кшталт «на помилки ми повертаємо код 200 и обʼєкт с ключем error</code> через рішення, яке було прийняте десять років тому и навколо якого написано багато коду»</li> </ul> Іншими словами, you need two to tango</del> have a good code review Продовження: Створення pull request’у</a> iOS Lock Screen, Powered by Microsoft Sat, 06 Feb 2021 10:48:00 GMT Где компромиссное решение в сто строк кода заменяется бескомпромиссным в пять прямоугольников со скруглёнными углами Первым виджетом, который я набросал</a> в Scriptable</a>, был список приложений с виндовой фотографией дня</a> (она же — "фотография на фоне bing.com") Мне нравится "свежесть" экрана блокировки Windows и хотелось иметь что-то подобное и на телефоне. В бетах iOS 13 во встроенном приложении Shortcuts ("Команды")</a> даже было действие для установки произвольной картинки изображением на домашний экран и/или экран блокировки. Но оно не дожило до релиза iOS 13</a> и не вернулось к релизу iOS 14 Компромисс</h2> Так что единственной возможностью иметь что-то близкое к динамической обоине из интернета было сделать обновляющийся виджет. Ссылку на волшебный JSON со ссылкой на фотографию дня нашёл, само собой, на Stack Overflow</a>. Список ссылок/приложений поверх картинки добавил чуть позже, как чтобы домашний экран не терял своё главное назначение — запуск этих приложений Спустя ещё некоторое время, добавил кэширование фотографии дня, чтобы телефон не загружал её каждый раз, когда iOS решала обновить виджет. Я не сохранял промежуточные версии скрипта, но сейчас он выглядит как-то так (пропустить простынку кода и перейти к более интересной части</a>): const APPS = [ { url: "photos-redirect://", name: "photos" }, { url: "App-prefs://", name: "settings" }, { separator: true }, { url: "bear://" }, { url: "things://" }, { url: "reeder://" }, { url: "twitterrific://" }, { separator: true }, { url: "spotify://" }, { url: "overcast://" }, // { url: "music://" }, { separator: true }, { url: "onepassword://", name: "1password" }, { url: "otpauth://", name: "authenticator" }, // { url: "diia.app://", name: "diia" }, ]; const NOW = new Date; const widget = new ListWidget(); widget.setPadding(0, 0, 0, 0); widget.backgroundColor = Color.black(); // refresh every 4 hours widget.refreshAfterDate = new Date(+NOW + 1000 * 60 * 60 * 4); function formatDate(date, format) { const formatter = new DateFormatter() formatter.dateFormat = format return formatter.string(date) } async function getTodaysImage() { const fm = FileManager.local() const imagesDirectory = `${fm.cacheDirectory()}/${Script.name()}` if (!fm.fileExists(imagesDirectory)) { fm.createDirectory(imagesDirectory, true) } const startdate = formatDate(NOW, "YYYYMMdd") const metadataPath = `${imagesDirectory}/${startdate}.json` let todaysImage if (fm.fileExists(metadataPath)) { todaysImage = JSON.parse(fm.readString(metadataPath)) } else { const bingReq = new Request( "https://www.bing.com/HPImageArchive.aspx?format=js&idx=0&n=1" ); const { images } = await bingReq.loadJSON(); todaysImage = images[0]; if (startdate === todaysImage.startdate) { fm.writeString(metadataPath, JSON.stringify(todaysImage)) } } const imagePath = `${imagesDirectory}/${todaysImage.startdate}.jpg` if (fm.fileExists(imagePath)) { return { image: fm.readImage(imagePath), copyrightlink: todaysImage.copyrightlink } } const image = await new Request( "https://www.bing.com" + todaysImage.url ).loadImage() fm.writeImage(imagePath, image) return { image, copyrightlink: todaysImage.copyrightlink, }; } const { image, copyrightlink } = await getTodaysImage(); widget.backgroundImage = image; const row = widget.addStack(); row.layoutHorizontally(); const copyrightColumn = row.addStack(); copyrightColumn.layoutVertically(); copyrightColumn.addSpacer(null); copyrightColumn.setPadding(16, 16, 16, 16); const copyrightSymbol = SFSymbol.named("c.circle"); copyrightSymbol.applyThinWeight(); const c = copyrightColumn.addImage(copyrightSymbol.image); c.url = copyrightlink; c.resizable = false; c.tintColor = Color.white(); row.addSpacer(null); const column = row.addStack(); column.layoutVertically(); column.setPadding(14, 0, 12, 0); for (const { separator, url, name } of APPS) { if (separator) { column.addSpacer(null); continue; } const appRow = column.addStack(); appRow.addSpacer(null); appRow.setPadding(2, 16, 4, 16); const t = appRow.addText(name || url.replace(/:\/\/$/, "")); t.rightAlignText(); t.textColor = Color.white(); t.shadowColor = Color.black(); t.shadowRadius = 4; t.font = new Font("Menlo", 18); appRow.url = url; } widget.presentLarge(); </code></pre> Получил, что хотел</h2> К счастью, в iOS 14.3 в Shortcuts вернулось действие "Установить X в качестве обоев", так что "динамический экран блокировки" стал возможен без необходимости в компромиссах. Этот shortcut</a> делает необходимый минимум и ничего больше: Постучаться по ссылке https://www.bing.com/HPImageArchive.aspx?format=js&idx=0&n=1</code></li> Получить из ответа адрес сегодняшней фотографии. Shortcuts считает по-человечески, начиная с единицы, так что "url</code> первого элемента списка images</code>" доступно по ключу images.1.url</code>, без программистских "мы считаем с нуля потому что наши деды считали с нуля"</li> Постучаться по ссылке из прошлого шага, дописав к ней https://bing.com/</code>1</a>. Для комбинирования фиксированного текста с результатами предыдущего действия есть специальное действие, но можно "срезать угол" и сделать это с помощью "волшебной переменной"</li> Собственно, установить новую обоину. Чтобы телефон не просил никаких подтверждений и тупо использовал центр фотографии, я выключил опцию "Показать окно просмотра"</li> </ol> </li> </li> </li> </li> </ul> Чтобы автоматически запускать эту команду каждый день (например, когда заходит солнце), в Shortcuts есть вкладка "Автоматизация": </li> </li> </li> </ul> И готово! Теперь каждый вечер мой экран блокировки обновляется красивой фотографией ☺️ </li> </li> </li> </li> </li> </li> </ul> Ссылки</h2> Scriptable</a></li> Руководство пользователя Быстрых команд</a></li> </ul> P.S. // 2021-05-02</h3> Иногда, автоматический кроппинг порождает шедевры: /</code> в конце необязательный, но с ним скриншот читается немного получше ↩︎</a> </li></ol></div> Widgetarian Sun, 13 Dec 2020 14:11:00 GMT Если бы март в этом году не затянулся, то я скорее всего скатался бы на BeerJSSummit 2020 с «сиквелом» выступления про всякую автоматизацию</a>, но на iOS/iPadOS вместо macOS. Но произошло то, что произошло, рассказать про JS на iOS/iPadOS всё ещё хочется, так что here we go… В iOS, в отличии от macOS, нет JXA. Но у нативных приложений уже довольно давно есть доступ к JavaScriptCore</a> для запуска JS-кода. Окружение этого кода отличается от браузерного или nodejs</code>-ового, но приложение может определить свои собственные глобальные функции и объекты, при взаимодействии с которыми будут дёргаться нативные API. Зачастую, про JavaScriptCore вспоминают в контексте React Native, но нам это сегодня</del> не интересно Кроме приложений, которые используют JS чтобы рисовать кривые интерфейсы, есть приложения вроде Scriptable</a>, в которых можно запускать произвольный JS-код с доступом к GPS, к HTTP, к локальным фото/календарю/контактам, файлам в iCloud… Пфф, Shortcuts умеет всё это и даже больше! Зачем приплетать сюда JS? </blockquote> А затем, что в iOS 14 завезли виджеты… </video> Anton 🌻 @zemlanin@devua.club on Twitter (archived) </a> A E S T E T I C S • J S </figcaption> </figure> </li> </a> Anton 🌻 @zemlanin@devua.club on Twitter (archived) </a> COVID NUMBERS • JS </figcaption> </figure> </li> </a> Anton 🌻 @zemlanin@devua.club on Twitter (archived) </a> Merging threads https://twitter.com/zemlanin/status/1298526710556762119 </figcaption> </figure> </li> </a> Anton 🌻 @zemlanin@devua.club on Twitter (archived) </a> CHARTD FTW </figcaption> </figure> </li></ul> Самый простой из виджетов выше — чуточку более красивая реализация wakemeupwhenmarchends.com</a>1</a> — работает только с датами и (примитивнейшим) UI, так что он идеально подойдёт как «мой первый виджет»2</a> Основы интерфейса</h2> Редактор скриптов в Scriptable довольно базовый, но самодостаточный — есть подсветка и автодополнение, есть консоль, есть документация, есть запуск скрипта прямо в редакторе (тапом по ▶️ или нажатием Cmd-R, если подключена внешняя клавиатура) Мой первый виджет</h2> Для того, чтобы вывести самый базовый виджет, достаточно трёх строк кода (даже двух, если забить на дебаг): const widget = new ListWidget(); widget.presentSmall(); Script.setWidget(widget); </code></pre> const widget = new ListWidget();</code> создаёт объект виджета, который мы будем изменять для отрисовки календаря</li> widget.presentSmall();</code> показывает окно предпросмотра с маленьким форматом виджета</li> Script.setWidget(widget);</code> обновляет виджет на домашнем экране</li> </ul> Вбиваем три эти строки в редактор, нажимаем ▶️, и видим наш виджет — белый (или чёрный, если включен Dark Mode) квадрат: </li> </li> </ul> This House is not a DOM</h2> API для работы с виджетами в Scriptable похож на браузерный DOM, но не DOM. Например: все элементы виджета создаются как дочерние элементы самого виджета или его элементов. Другими словами, вместо браузерного «создать элемент и присоединить его к родителю» (const child = document.createElement("span"); parent.appendChildren(child)</code>), в Scriptable используется «создать дочерний элемент у родителя» (const child = parent.addText()</code>)</li> стили элементов (цвета, шрифты, отступы) задаются отдельными методами, а не свойством style</code></li> для определения порядка элементов используются WidgetStack</code></a> с заданным горизонтальным или вертикальным layout’ом</li> отступы между элементами задаются с помощью WidgetSpacer</code>’ов</a>, а не margin</code>’ов (которых нет ни в Scriptable, ни в SwiftUI, который используется для рендера виджетов)</li> отступы внутри WidgetStack</code> задаются методом setPadding(top, leading, bottom, trailing)</code></a>3</a></li> вместо строчных шрифтов, цветов и размеров, Scriptable использует классы Font</code></a>, Color</code></a> и Size</code></a>. У первых двух классов есть множество статических методов для стандартных значений (вроде Font.title()</code> и Color.red()</code>), которые выглядят консистентно с остальными виджетами и приложениями</li> </ul> Учитывая всё это, можно приступить к UI виджета. Наш виджет будет выглядеть как три строки отцентрованного текста на белом фоне: белый текст «Март» на красном фоне</li> БОЛЬШОЙ чёрный текст с «сегодняшним числом»</li> чёрный текст с сегодняшним днём недели</li> </ul> Чтобы не повторяться, определим функцию addTextRow</code>, которая добавит в виджет WidgetStack</code> с заданными текстом и фоном и вернёт WidgetText</code></a> чтобы можно было добавить тексту дополнительных стилей: const widget = new ListWidget(); widget.backgroundColor = Color.white(); function addTextRow(text, backgroundColor = Color.white()) { const textStack = widget.addStack(); textStack.backgroundColor = backgroundColor; textStack.setPadding(4, 0, 4, 0); textStack.layoutHorizontally(); textStack.addSpacer(null); const widgetText = textStack.addText(text); widgetText.textColor = Color.black(); textStack.addSpacer(null); return widgetText; } const titleText = addTextRow("Март", Color.red()); const dayText = addTextRow(`999+`); const dayOfWeekText = addTextRow("воскресенье"); widget.presentSmall(); Script.setWidget(widget); </code></pre> Нажимаем ▶️… Ай, забыл про стандартные стили виджета… Чтобы красная полоса марта была на всю ширину виджета, надо сбросить стандартный padding. Добавим widget.setPadding(0, 0, 0, 0);</code> сразу после первой строки скрипта: Добавим spacer</code>’ов и стилей тексту… const widget = new ListWidget(); widget.setPadding(0, 0, 0, 0); widget.backgroundColor = Color.white(); function addTextRow(text, backgroundColor = Color.white()) { const textStack = widget.addStack(); textStack.backgroundColor = backgroundColor; textStack.setPadding(4, 0, 4, 0); textStack.layoutHorizontally(); textStack.addSpacer(null); const widgetText = textStack.addText(text); widgetText.textColor = Color.black(); textStack.addSpacer(null); return widgetText; } const titleText = addTextRow("Март", Color.red()); titleText.textColor = Color.white(); titleText.font = Font.title2(); widget.addSpacer(null); const dayText = addTextRow(`999+`); dayText.font = Font.systemFont(60); dayText.minimumScaleFactor = 0.5; widget.addSpacer(null); const dayOfWeekText = addTextRow("воскресенье"); widget.presentSmall(); Script.setWidget(widget); </code></pre> И видим красивый, хоть и с неправильными данными, виджет: Time is haaaaaard</h2> Пора разбираться с данными в виджете… Месяц в нём никогда не меняется, так что оставляем его как константу День месяца немного сложнее. Нам нужно посчитать количество суток с полуночи первого марта 2020 года и округлить его в большую сторону (т.е., в шесть утра второго марта прошло 1.25</code> суток, округляем в большую сторону до 2</code> и получаем правильный день месяца) const MARCH_FIRST = new Date("2020-03-01T00:00:00"); // должно вывести полночь первого марта в текущем часовом поясе console.log(MARCH_FIRST); const HOUR = 1000 * 60 * 60; const day = Math.ceil((new Date() - MARCH_FIRST) / (24 * HOUR)); console.log(day); </code></pre> С днём недели можно либо забить и захардкодить список дней недели прямо в скрипт (как это было сделано для сайта), либо немного заморочиться и использовать DateFormatter</code></a>. Второй способ требует меньше кода</del> проще скейлить, так что я выберу его… DateFormatter</code> конвертирует дату в строчку и обратно, причём строчка может быть на любом языке и/или в произвольном формате. Открываем NSDateFormatter.com</a>, находим подходящий нам “EEEE</code> — Tuesday — The wide name of the day of the week” и форматируем сегодняшнюю дату в день недели: const dayOfWeekFormatter = new DateFormatter(); dayOfWeekFormatter.locale = "ru" dayOfWeekFormatter.dateFormat = "EEEE"; const dayOfWeek = dayOfWeekFormatter.string(new Date()); console.log(dayOfWeek); </code></pre> Используем day</code> и dayOfWeek</code> в вызовах addTextRow</code> и проверяем результат: const MARCH_FIRST = new Date("2020-03-01T00:00:00"); // должно вывести полночь первого марта в текущем часовом поясе console.log(MARCH_FIRST); const HOUR = 1000 * 60 * 60; const day = Math.ceil((new Date() - MARCH_FIRST) / (24 * HOUR)); console.log(day); const dayOfWeekFormatter = new DateFormatter(); dayOfWeekFormatter.locale = "ru" dayOfWeekFormatter.dateFormat = "EEEE"; const dayOfWeek = dayOfWeekFormatter.string(new Date()); console.log(dayOfWeek); const widget = new ListWidget(); widget.setPadding(0, 0, 0, 0); widget.backgroundColor = Color.white(); function addTextRow(text, backgroundColor = Color.white()) { const textStack = widget.addStack(); textStack.backgroundColor = backgroundColor; textStack.setPadding(4, 0, 4, 0); textStack.layoutHorizontally(); textStack.addSpacer(null); const widgetText = textStack.addText(text); widgetText.textColor = Color.black(); textStack.addSpacer(null); return widgetText; } const titleText = addTextRow("Март", Color.red()); titleText.textColor = Color.white(); titleText.font = Font.title2(); widget.addSpacer(null); const dayText = addTextRow(`${day}`); dayText.font = Font.systemFont(60); dayText.minimumScaleFactor = 0.5; widget.addSpacer(null); const dayOfWeekText = addTextRow(dayOfWeek); widget.presentSmall(); Script.setWidget(widget); </code></pre> 🎉 Осталось только добавить наш виджет на домашний экран4</a> и готово </li> </li> </li> </li> </li> </li></ul> …and the Clever</del> Depart</h2> Scriptable умеет общаться с файлами и HTTP-эндпоинтами, так что эта запись (и твиттер-тред в начале) лишь поверхностно описывает возможности виджетов. Да и писать свои виджеты совсем необязательно — в Scriptable недавно появилась какая-никакая галерея виджетов Спасибо за внимание Исходники</a> сайта ↩︎</a> </li> Вторым виджетом стал бы виджет со статистикой COVID, с его HTTP-запросами, графиком и поддержкой Dark Mode… Пишите</a>, если интересно ↩︎</a> </li> Для письменностей слева-на-право, вроде кириллицы и латиницы, leading</code> = left</code>, trailing</code> = right</code>, так что порядок аргументов «против часовой» в отличии от «по часовой» в CSS ↩︎</a> </li> После добавления виджета Scriptable, его нужно ещё раз нажать, чтобы выбрать скрипт, который будет рендерить его содержание ↩︎</a> </li></ol></div> Sat, 15 Aug 2020 14:40:00 GMT We are a spectrum of jobs, not just one</a> The problem, then, is when you hire one for the other job. In one case, you might get someone who's in completely over their head when they can't find an existing module or snippet somewhere. In the other case, you might end up with someone who thinks they're surrounded by a bunch of people who are speaking a different language, and feels very much alone. </blockquote> ∞</a> Заброшенное в карантин: Pepperoni Sat, 11 Jul 2020 10:00:00 GMT Слишком много времени, слишком мало терпения Если убрать из жизни дорогу на работу/с работы, «пойти в кафе», и «поехать в центр, чтобы повидаться с друзьями», то остаётся много свободного времени. Полностью занимать его «поглощением контента» (будь то кино/сериалы, книги, подкасты, музыка…) кажется нездоровым, игр надолго не хватает, звонки «как жизнь? — по большому счёту, так же, как и последние пять месяцев1</a>» быстро надоедают… Так что мой выбор яда</del> хобби — это делать то же самое, что на работе, но для себя. А так как для себя, то больше никому не надо чтобы я довёл дело до конца2</a> Например, никто не будет подталкивать добить до конца выступление для митапа, который должен был пройти в марте </a> Proxet on Twitter </a> Rails Reactor is happy to announce the upcoming Python Tonight. SPEAKERS: 👨‍💻Vitaliy Radchenko - Intro to Apache Airflow 👨‍💻Anton Verinov - Cook with What You Have 👨‍💻Denys Serhiienko - Optimization. A little adventure. Need to register https://t.co/NAEEzkW6wN</a> </figcaption> </figure> или дописать-таки кучу слов про code review </a> Half outlined and half ready-ish. This is gonna loooong… </figcaption> </figure> или причесать вроде юзабельный (хоть и довольно бесполезный) side project для публики Но всё это можно похоронить</del> заморозить в бложек. Авось даже в сыром виде оно кому-то пригодится Начну с выступления для Python митапа… Pitch</h2> Суть: сделать что-то полезное исключительно средствами стандартной библиотеки Python Почему: легче разворачивать, распространять, меньше поддерживать (потому что меньше обновляемых частей) Что делаем: мониторинг веб-страниц на обновление. Юзер вбивает ссылку и опциональный фильтр для данных, а скрипт периодически пингует страницу и уведомляет об изменениях Структура выступления: преподнести процесс написания скрипта как процесс готовки еды, с модулями как ингредиентами. Наиболее подходящим “блюдом” показалась пицца На что хватило?</h2> Сил и времени перед отменой митапа хватило на написание outline’а и самого скрипта</a>, который даже пригодился когда ждал замены батарейки в телефоне: По outline’у, все импорты разделил на четыре группы: # spices import os import time import platform # sause import re import difflib import textwrap import html.parser # meat import urllib.request # dough import logging import argparse </code></pre> мясо3</a> — основная часть скрипта, которую выполняет urllib.request</code></li> тесто — интерфейс, за который юзер будет «держать» скрипт logging</code> для красивого вывода с таймстампами</li> argparse</code> для ввода опций для «соуса»</li> </ul> </li> соус — всякая «вкусовщина», без которых «мясо» будет съедобно, но не то. В основном, это удобства для «что отслеживать на странице?»</li> специи — модули, которые пойдут в «любое блюдо». А правильно применённые специи могут быть небольшим «секретным ингредиентом», вроде звукового уведомления:</li> </ul> if platform.system() == "Darwin": parser.add_argument( "--sound", "-s", dest="mac_sound", default="pop", # `ls /System/Library/Sounds/` choices=[ "basso", "blow", "bottle", "frog", "funk", "glass", "hero", "morse", "ping", "pop", "purr", "sosumi", "submarine", "tink", ], type=str, help="sound to play (macOS only)", ) </code></pre> if mac_sound: os.system( f"afplay /System/Library/Sounds/{mac_sound.title()}.aiff 2> /dev/null" ) else: print("\a", end="", flush=True) </code></pre> Кроме этих четырёх ингредиентов, хотел упомянуть что в стандартной библиотеке есть «кухонные приборы» — модули вроде doctest</code>, которые упрощают разработку: def query_html(html, query, regex): """ >>> html = "<ul><li>A</li><li id='b'>B</li></ul><ol><li>C</li><li class='d'>D</li></ol>" >>> query_html(html, "li", None) 'A' >>> query_html(html, "#b", None) 'B' >>> query_html(html, "ol li", None) 'C' >>> query_html(html, ".d", None) 'D' >>> query_html(html, "ul li", "B|X") 'B' >>> query_html(html, "ol li", "B|X") """ if query: html_parser = HTMLParser(query, regex) html_parser.feed(html) return html_parser.match elif regex: match = re.search(regex, html) if match: return match.group(0) return None </code></pre> После всего этого кода, в качестве outro, сказал бы о штуках, которых не хватает (вроде форматтера и хоть какой-то работы с изображениями), плюс отметил бы что Конечно, в PyPI можно добыть ингредиенты покачественнее: re</code> -> regex</code></li> argparse</code> -> click</code></li> urllib.request</code> -> request</code></li> html.parser</code> -> BeautifulSoup</code></li> </ul> Но и стандартного набора более чем достаточно для вкусного блюда </blockquote> Исходники всего скрипта доступны на гитхабе</a> и здесь</a> Спасибо, что дочитали до конца Уже пять месяцев?.. Чёёёёёрт… ↩︎</a> </li> Или не забросил начинания как, честно говоря, забросил готовку дома</a>. Ну, то есть, готовлю чаще, чем в "Before Times", но намного меньше, чем в момент написания той заметки ↩︎</a> </li> или «мясо + сыр», или «протеин»… ↩︎</a> </li></ol></div> Reuse500 Wed, 13 May 2020 09:34:00 GMT Год назад я купил простенький кликер, Logitech R500. Работает он как двухкнопочная клавиатура с лазерной указкой. Сейчас, когда возможностей для публичных выступлений поменьше, он стал довольно бесполезным Вне презентаций мало ситуаций, в которых можно обойтись только кнопками "влево" и "вправо". Но, во время видеозвонков, когда можно обойтись другими двумя кнопками — "Вкл/выкл камеру" и "Вкл/выкл микрофон"1</a>. Нужно только сопоставить одни с другими И может твой рабочий видеочат может в настройки сочетаний клавиш, но не BlueJeans. BlueJeans может только M</kbd> для переключения микрофона и V</kbd> для переключения камеры macOS умеет, на уровне системы, вешать и переопределять сочетания клавиш</a> для элементов меню в любом приложении. Например, для выхода из Safari можно повесить ⌥</kbd>⌘</kbd>Q</kbd> вместо стандартной ⌘</kbd>Q</kbd> (которое слишком близко к закрывающему вкладки ⌘</kbd>W</kbd>) </li> </li> </ul> Но и тут BlueJeans отличился тем, что в его меню нет пунктов про камеру и/или микрофон… Поэтому придётся пользоваться сторонним софтом. Так как у меня уже был установлен Karabiner2</a>, поковырялся его документацию</a> и накликал правила</a> "когда фокус на BlueJeans, воспринимай →</kbd> как M</kbd> и ←</kbd> как V</kbd>": { "title": "Mic and video toggle on arrow keys in BlueJeans", "rules": [ { "description": "Change Right arrow to M in BlueJeans", "manipulators": [ { "from": { "key_code": "right_arrow" }, "to": [ { "key_code": "m" } ], "type": "basic", "conditions": [ { "type": "frontmost_application_if", "bundle_identifiers": [ "^com\\.bluejeansnet\\.Blue$" ] } ] } ] }, { "description": "Change Left arrow to V in BlueJeans", "manipulators": [ { "type": "basic", "from": { "key_code": "left_arrow" }, "to": [ { "key_code": "v" } ], "conditions": [ { "type": "frontmost_application_if", "bundle_identifiers": [ "^com\\.bluejeansnet\\.Blue$" ] } ] } ] } ] } </code></pre> Не знаю, как красиво закончить… Была валяющаяся без дела железка, была лениво написанная софтина. Щепотка JSON'а в правильном месте — и железка полезнее, и софтина удобнее ✨🧙‍♂️ К сожалению, не все догадываются о том, что микрофон на ноутбуке можно/нужно выключать, когда набираешь текст во время звонка ↩︎</a> </li> Чтобы перенастроить Ctrl-Win-Alt (≈ Control-Command-Option) на майкрософтовской клавиатуре в более маковские Control-Option-Command ↩︎</a> </li></ol></div> Готовить/ся Sun, 22 Mar 2020 12:45:00 GMT Я редко готовлю (если не считать утреннего кофе). В основном, еда — это либо офисные обеды, либо кафе, либо доставка В ноябре-декабре прошлого года, YouTube начал активно рекомендовать кулинарные видео, в частности, Basics with Babish</a>. Поддавшись алгоритму, я пересмотрел несколько десятков таких видео Так что когда приближающейся новогодние праздники начали угрожать привычному пропитанию (потому что выходные, праздничный режим работы кафе, нагруженная доставка), решил первую неделю года готовить дома Получилось более-менее сносно — куриный суп</a>, карбонара</a>, крылышки, что-то ещё, о чём уже забыл… Хотя опасения не оправдались — поесть в кафе и заказать доставку можно было довольно легко… После этого, снова вернулся к привычному офисные-обеды-кафе-доставка. Ненадолго, на пару месяцев… Не мог подумать, что первая неделя года будет тренировкой Усатый ядерщик Thu, 19 Dec 2019 20:02:00 GMT </iframe> React with mustaches • React Kyiv </a> Are there good parts inside an abandoned project? What could we learn from it? Could we apply some patterns in our current projects? </figcaption> </figure> Выковыривая полезные идеи из заброшенного модуля Адаптировано из выступления “React with mustaches” на React Kyiv (видео</a> и слайды</a>) </blockquote> Бывает так, что гоняешься не за тем, за чем стоило бы. В разработке, это зачастую выражается в странных решениях временных или надуманных проблем. Для таких решений пишется код, который либо никогда не увидит продакшена, либо довольно быстро будет удалён за ненадобностью Повезёт, если такой код поможет не только тебе Но повезёт ещё больше, если кроме одноразового кода останется опыт, который поможет решить более стоящие проблемы Проблема</h2> Проект, над которым я тогда работал, использовал Python на бекенде и React на фронтенде. Из-за SEO и почтительного возраста кодовой базы, React использовался не для SPA, а для progressive enhancement — бекенд, на основе Mako-шаблонов, отдавал HTML со полным контентом страницы А фронтенд, на основе JSX, поверх этого контента рендерил интерактивные элементы. Так как серверные и клиентские шаблоны шаблоны были написаны на разных языках, разработчики повторяли приблизительно один и тот же HTML в Mako и в JSX. И, конечно же, когда правили шаблоны на одном языке, часто забывали повторить изменения на другом Проблема не то, чтобы критическая — небольшой content flash, для частного фикса которого надо всего-то немного покопипастить. Но она генерировала достаточное количество баг-репортов, чтобы показаться заслуживающей более основательного решения Для SSR-инфраструктуры на NodeJS’е, на тот момент, ещё не созрели. Так что решили попробовать другой подход План</h2> Мы подумали: а что если вместо разворачивания NodeJS-серверов, попробуем писать интерактивные элементы на общем языке, понятном и на существующем бекенде, и на фронтенде? Тогда обе части стека смогут использовать одни и те же исходники шаблонов. Общие исходники -> ничего не надо повторять вручную -> меньше однообразных баг-репортов def render_navigation(): return ( "<div data-nav>" + render("navigation.tmpl") + "</div>" ) </code></pre> import Nav from "navigation.tmpl" function hydrateNavigation() { for (let n of document.querySelectorAll("[data-nav]")) { ReactDOM.hydrate(<Nav />, n) } } </code></pre> За общий язык шаблонов выбрали mustache</code></a>. Модули для рендера mustache</code>-шаблонов написаны на куче языков (а то и по несколько раз), а сами шаблоны — простые как пробка. В них нельзя описать логику на другом языке (в отличии от, к примеру, JSX, в котором можно писать вставки со сложными JS-выражениями). Плюс, язык шаблонов довольно подробно описан в короткой спецификации</a>, с примерами и на человеческом языке Несмотря на наличие рендеров на куче языков, они все отдают результат в виде обычной строки. Нам же, в идеале, надо рендерить шаблоны в React-код, чтобы не рисковать XSS из-за dangerouslySetInnerHTML</code> и чтобы не терять оптимизаций, связанных с виртуальным DOM Рендерить шаблоны в код решили с помощью кастомного webpack loader’а. Лоадеры</a> уже использовались на проекте для штук вроде импорта CSS-файлов, так что добавление ещё одного не станет проблемой В итоге, мы хотели попробовать написать такой лоадер, который компилировал mustache</code>-шаблоны в эквивалентный React-компонент. За target</code> выбрали ES3 с вызовами React.createElement</code>, чтобы избежать дополнительной компиляции бабелем: // `<a href={{ href }}>{{ label }}</a>` var React = require("react") module.exports = function (props) { return React.createElement( "a", { href: props.href }, props.label ) } </code></pre> И написали. Обозвали schwartzman</code></a>ом (как актёра), залили на гитхаб и использовали в продакшене Прежде, чем продолжать… Да, это странное и, в каком-то смысле, overcomplicated решение проблемы SSR. Но это решение: не станет проблемой, когда появится NodeJS-инфраструктура,</li> не потребует переписывания всего стека (новый язык шаблонов дружит с Mako на бекенде и с JSX на фронтенде)</li> </ul> Да и я не надеюсь что вы будете использовать лоадер у себя. Даже не так. Надеюсь, что вы не будете использовать лоадер у себя Ладно, адресовав возможные “ты говно и идея твоя говно”… </blockquote> Парсинг</h2> Изнутри, как и многие компиляторы, schwartzman</code> работает в два этапа: “парсинг” и “генерация кода”. На первом этапе, лоадер преобразовывает строку с исходными кодом в объект с синтаксическим деревом Regex</h3> Первым делом, при написании парсера, хочется воспользоваться регулярными выражениями. Но это плохая идея по двум причинам: у нас слишком много правил для того, чтобы итоговая регулярка была читаемой</li> нам надо парсить HTML. Я не буду вдаваться в подробности почему “парсить HTML регулярками” — это плохая идея; в интернете достаточно объяснений</a></li> </ul> Custom lexer + parser</h3> Можно написать кастомные лексер (который разбивает строку на подстроки) и парсер (который собирает синтаксическое дерево из этих подстрок), чтобы процесс был максимально оптимизированным под наш синтаксис. Но это сложнааа, лень, триггерит воспоминания об универе, да и довольно бесполезно, потому что есть… Parsing expression grammar</h3> “Грамматика, разбирающая выражения”</a> или “PEG”</a>. Разработчик описывает синтаксис языка именованными правилами, из которых потом генерируется парсер этого самого языка Например, так может выглядеть грамматика для подмножества HTML, в котором есть только два тега, </code> и </code>, и нет никаких атрибутов: grammar bitsy node <- tag / text_node tag <- i_tag / b_tag i_tag <- "" node* "" b_tag <- "" node* "" text_node <- [^<>]+ </code></pre> Для генерации парсера из PEG-файла есть несколько библиотек Самая “знаменитая”, на мой взгляд, это ANTLR</a>, она довольно зрелая, умеет генерировать грамматику в JS, но для работы требует Джаву… Из библиотек на JS, в 2015 год выбор был из Canopy</a> и очень оригинально обозванной PEGjs</a>. Выбрал, в итоге, первую. Не помню, по какой причине1</a>, но не столь важно… Важно то, что определившись с модулем для парсинга PEG, я мог начать постепенно описывать синтаксис</a> для “HTML с mustache-вставками”, начав с корня дерева и добавив хелперы, которые очистят дерево от всякого мусора</li> новые типы нод, разделив их на “HTML-элементы”, “mustache</code>-теги” и “plain text”</li> произвольные имена тегов и функцию для валидации их сбалансированного открытия/закрытия, чтобы можно было сгенерировать валидные вызовы React.createElement</code></li> прочий синтаксис…</li> </ul> grammar Schwartzman root_node <- expr_node* %strip_whitespaces dom_node <- (open_html_tag expr_node* close_html_tag) %validate <DOMNode> / contained_html_tag <DOMNode> / commented_html <CommentedDOMNode> open_html_tag <- "<" whitespace? tag_name whitespace? attrs:dom_attr* whitespace? ">" contained_html_tag <- "<" whitespace? tag_name whitespace? attrs:dom_attr* whitespace? "/>" </code></pre> После того, как перечислил все кейсы, мог сгенерировать модуль с функцией parse</code>, которая: словит ошибки в шаблоне и кинет относительно читабельное сообщение. Например, если разработчик не сбалансировал теги (то есть, закрыл родительский тег до того, как закрыл все дочерние)</li> если шаблон ок, то отдаст готовенькое синтаксическое дерево</li> </ul> require("./grammar.js") .parse("hello, world!") /* => TreeNode { text: 'hello, world!', offset: 0, elements: [ TreeNode { text: '', offset: 0, elements: [] }, TreeNode { text: 'hello, world!', offset: 3, elements: [ TreeNode { text: 'hello, ', offset: 3, elements: [Array] }, TreeNode { text: 'world', offset: 10, elements: [Array] }, TreeNode { text: '!', offset: 22, elements: [Array] } ] }, TreeNode { text: '', offset: 23, elements: [] } ] } */ </code></pre> Генерация кода</h2> Имея синтаксическое дерево, лоадер может приступить к генерации React-кода Упрощённо, лоадер выглядит как-то так: function loader(content) { const tree = parse(content) const { code } = compile(tree) return `var h = require("react").createElement module.exports = function (props) { return ${code} } if ( typeof process !== "undefined" && process.env && process.env.NODE_ENV === "test" ) { /* … */ }` } </code></pre> Лоадер получает содержимое шаблона как строку, парсит его в синтаксическое дерево, передаёт получившееся дерево в функцию compile</code>, которая сгенерирует код компонента Получившийся код компонента заворачивается в бойлерплейт с экспортом, дебаг-информацией для тестирования, и коротким именем для createElement</code> Внутри compile</code>, лоадер рекурсивно проходится по синтаксическому дереву и возвращает объект с кодом и некоторой дополнительной информацией про контекст: function compile(node) { const { tag_name, attrs, elements } = node const children = compileChildren(elements) const compiledAttrs = compileAttrs(attrs) return { code: `h("${tag_name}", ${compiledAttrs}, ${children})`, // … } } </code></pre> Реальный код сложнее</a>, так как нам надо обрабатывать кучу ограничений React’а и mustache’а Escaping</h3> Например, в mustache</code> есть “обычная” замена переменной, которую можно скомпилировать в приблизительно такой React-код. По спецификации, HTML эскейпится при “обычной” замене, что совпадает со стандартным поведением children</code>ов в React’е // `<div>{{ mark }}</div>` React.createElement( "div", null, props.mark ) </code></pre> Для замены без эскейпинга, в mustache</code> есть специальные теги {{&</code> и {{{</code>. Сами по себе, эти теги не вызывают проблем — просто генерируем больше кода и делов-то // `<div>{{& mark }}</div>` React.createElement( "div", { dangerouslySetInnerHTML: { __html: props.mark } } ) </code></pre> Но в Реакте, dangerouslySetInnerHTML</code> — это свойство элемента (а не его дочерних нод), так что как только в шаблонах начинают комбинироваться теги без эскейпинга с любыми другими тегами или нодами, то лоадер должен это как-то обрабатывать: <div> {{ john }}: oh, hi {{& mark }} </div> </code></pre> Можно было бы эскейпить соседние ноды “руками”. Но это сложнааа, потому что тогда надо перегенерировать код всей родительской ноды и её заэскейпленных children</code>ов Так что остановился</a> на другом варианте и ограничил количество дочерних нод, если хотя бы одна из них заэскейпленная. Всё равно отключение эскейпинга не поощряется… if (children.length === 1 && children[0].escaped) { // add some `danger` } else if (children.some(c => c.escaped)) { throw new OneChildPolicy() } </code></pre> {{# section }}</code></h3> Но не только react</code> усложняет написание лоадера, но и сам mustache</code>… Несмотря на то, что mustache</code> называет себя “logic-less”, в нём есть пара тегов, которые по тому или иному условию рендерят своё тело Первый, invert, работает как if not</code> — тело тега рендерится, если значение в контексте либо falsey</code>, либо пустой массив. Для этого тега несложно сгенерировать код, который будет отдавать правильный контент в зависимости от значений в props</code>: // `{{^ great }}Not terrible{{/ great }}` React.createElement( "b", null, (!props.great || !props.great.length) ? "Not terrible" : null ) </code></pre> Второй же “условный” тег, также известный как “секция”, выполняет кучу ролей, каждая из которых зависит от значений в контексте. Например, для шаблона <div>{{# user }}{{ name }}{{/ user }}</div></code>: Если user</code> — это булевое значение, то секция работает как if</code>, а шаблон можно скомпилировать в элемент React.createElement("div", null, props.user ? props.name : null)</code></li> Если user</code> — это объект, то секция работает как scope</code> (или namespace</code>), “ограничивая” доступ к props</code>. В итоге, шаблон можно скомпилировать в элемент React.createElement("div", null, props.user ? props.user.name : null)</code></li> </ul> Только в рантайме компонент может знать, откуда доставать name</code> — из корня props</code> или из вложенного объекта user</code>… Так что лоадер, кроме вызовов React.createElement</code>, также должен добавить в код рантайм-хелперы Один из таких хелперов — это функция для поиска значения в контексте</a>, которой передаётся список возможных “скоупов” (в нашем случае это ["user"]</code>), и ключ, который нужно найти (name</code>). Если же ключа нет, то, по спецификации, заменяем тег на пустое значение Другой хелпер помогает с двумя другими “ролями” секции: Если в props</code> передан массив, то секция работает как for_each</code> и повторяет своё тело для каждого элемента этого массива</li> Если в props</code> передана функция, то секция работает как lambda</code> и рендерер заменят тело секции результатом вызова функции</li> </ul> Логика для проверки “роли” секции становится слишком сложной, так что выносим его в хелпер-функцию section</code></a>. Она находит значение секции в props</code> и, в зависимости от его типа, отдаёт соответсвующее React-дерево: return `function section(/* … */) { var obj = scopeSearch(/* scope section */) if (obj) { if (isArray(obj)) { // for_each section } else if (isFunction(obj)) { // lambda section } else { // if section } } }` </code></pre> Самое интересное начинается, когда секция выполняет роль “лямбды”. Потому что, по спецификации mustache</code>, функция в такой секции: может вернуть строку с HTML</li> принимает в аргументах тело секции и функцию для рендера своего тела с правильными скоупами переменных</li> </ul> Так что нам нужен волшебный хелпер, который в рантайме из HTML-строки сгенерирует React-дерево. Этим хелпером</a> является сам schwartzman</code>. Так что лоадер, при генерации кода, должен включить сам себя в результат, чтобы React-компонент мог заeval</code>ить2</a> результат и отдать другой, скомпилированный в рантайме, компонент: return `function render(/* … */) { var lowLevel = require("schwartzman").lowLevel var parsed = lowLevel.parse(/* … */) // … return eval(lowLevel.compile(parsed)) }` </code></pre> Удобства</h2> Ограничения mustache</code> влияют не только на то, что мы должны делать при обработке секций, но и на то, что можно делать. Например, нельзя расширить синтаксис штуками вроде явно именованных элементов массивов: {{#users u}} {{ u.name }} {{/users}} </code></pre> Нам надо соблюдать совместимость с mustache</code>м на бекенде, а он не знает ничего про особую роль пробелов в названии секции В первых версиях лоадера, до меня это не дошло, так что я попытался добавить поддержку именованных элементов массива</a>. Только чтобы откатить всё обратно</a>, когда renderer mustache</code>а на бекенде не мог найти непонятные ключи в контексте Хотя, это и хорошо, что необходимость совместимости не пускала сильно далеко. Потому что вместо траты времени и усилий на разработку и поддержку неважных фич, можно было вкладываться в удобство использования лоадером Demo-страница</h3> Одним из таких удобств была demo-страничка</a>, на которой можно вбить шаблон и контекст, и получить отрендеренный компонент с его кодом. Идея, конечно, далеко</a> не</a> оригинальная</a>, но всё ещё недостаточно распространённая, как на мой взгляд Сначала мне казалось, что сделать такую страничку будет сложно из-за того, что надо будет возиться с зависимостями и с отличиями между окружениями NodeJS (в котором лоадер крутился до этого) и браузера (в котором будет крутиться демо-страничка) Но, когда начал перечислять все зависимости, всё оказалось намного проще: Из пакетов: сгенерированный код зависит только от React’а (и то опционально) и от самого лоадера для обработки {{# lambda }}</code>-секций</li> а лоадер — только от функции для парсинга вебпаковских настроек</li> </ul> </li> Про ноду, лоадер и сгенерированных код знают очень мало: что зависимости получаются вызовом функции require</code></li> и что в окружении есть module.exports</code> и process.env.NODE_ENV</code></li> </ul> </li> </ul> var h = require("react").createElement var lowLevel = require("schwartzman").lowLevel var parseQuery = require("loader-utils").parseQuery module.exports = function (content) { /* … */ } if ( typeof process != "undefined" && process.env && process.env.NODE_ENV === "test" ) { /* … */ } </code></pre> Все эти зависимости легко замокать вручную</a>, избежав возни с бандлерами и дополнительным build</code>-степом для демо-страницы: window.module = {} window.process = { env: { NODE_ENV: "test" } } window.require = function (name) { if (name === "loader-utils") { return { parseQuery() { return {} } } } if (name === "react") { return /* <script src="https://unpkg.com/react@16/umd/react.production.min.js"></script> */ } if (name === "schwartzman") { return /* <script src="https://unpkg.com/schwartzman"></script> */ } } </code></pre> Причём, parseQuery</code> (функцию для парсинга вебпаковских опций) можно полностью заменить на свою реализацию, которая всегда будет отдавать одно и то же. А реакт и лоадер можно тянуть с unpkg</code> Существование этой странички очень помогло с баг-репортами, особенно когда начал прописывать входные шаблон и props</code> в URL Так что если лоадер падает или странно рендерит шаблон, его пользователи могли кинуть ссылку</a> на проблемный шаблон в Slack или Github Issues. Так что и для юзеров есть чёткий flow для жалоб, и я могу сэкономить время на написание тест-кейсов. Так что да, чем меньше модуль знает, тем лучше</a> Тестирование зависимостей</h3> Прошло два года. Лоадер продолжал использоваться то тут, то там, так что я добавляю тесты на сгенерированный код и отрендеренный им статический маркап, плюс периодически проверяю совместимость с новыми версиями Реакта Переход на пятнадцатую версию не вызвал никаких проблем, а вот с выходом шестнадцатой билд становится красным… <div style="color: red;">hello world</div>  <div style="color:red">hello world</div> </code></pre> Дело в том, что шестнадцатый ReactDOM</code> поменял то, как форматируются inline-стили, так что тесты на отрендеренный шаблон начали падать. Передо мной предстал выбор: Либо переписать тесты на шестнадцатый React Для лоадера с малым количеством кода и достаточным количеством тестов это довольно быстро, но, по сути, сделает лоадер совместимым только с последней версией React’а. Потому что вдруг что-то поломается в совместимости с прошлой версией, а помнить проверять всё ручками я не могу Для пользователей же лоадера, обновление их основной UI-библиотеки — дело намного более муторное Лиииибо я мог бы добавить в тесты проверки на версию React’а и ожидать соответствующие результаты в тест-кейсах Пользователям это дико упрощает миграцию — они могут обновлять React и лоадер без привязки друг к другу Мне же нужно описывать отдельные тест-кейсы для разных React’ов и как-то устанавливать с npm</code>а правильные версии зависимостей перед прогоном тестов, а это сложнааа. Но, так как я уже дважды выбирал простой путь, так что пора выбрать и сложный… Поэтому пишем в тестах ожидания, зависящие от версии</a> React’а3</a> const rendered = semver.gte(React.version, "16.0.0") ? `<div style="color:red">red</div>` : `<div style="color:red;">red</div>` assert.equal( rendered, ReactDOMServer.renderToStaticMarkup( React.createElement(tmpl, {}) ) ) </code></pre> В package.json</code> описываем</a>, какая версия React’а может быть у пользователя лоадера. В нашем случае, это версии из трёх “веток” — 14, 15 и 16. Делаем это в peerDependencies</code>, а не в dependencies</code> для того, чтобы оставить пользователям возможность выбора версии React’а4</a> "peerDependencies": { "react": "^0.14.3 || ^15.6.1 || ^16.0.0" } </code></pre> Теперь нам надо подготовить CI окружение (в случае schwartzman</code>, это был5</a> Travis CI) для прогона тестов. Для этого описываем в конфиге переменную окружения</a> с версиями React’а, против которых гонять тесты env: - REACT_VERSION=* - REACT_VERSION=0.14.3 - REACT_VERSION=15.6.1 - REACT_VERSION=16.0.0 </code></pre> И там же правим</a> install</code>-шаг так, чтобы после стандартной установки зависимостей, устанавливались react</code> и react-dom</code> необходимых версий: install: - npm ci - npm i --no-save "react@$REACT_VERSION" "react-dom@$REACT_VERSION" </code></pre> И готово. Не так уж и сложнааа, но теперь тесты словят меня, если/когда я поломаю совместимость с прошлыми версиями React’а</a>. А пользователи лоадера смогут получить оптимизации новых версий без необходимости переписывать весь остальной код на новую версию React’а Опыт</h2> Лоадер несколько лет использовался, чтобы рендерить всякую мелочь в проекте. В конце восемнадцатого-начале девятнадцатого года, подняли-таки инфраструктуру для SSR, так что schwartzman</code>а удалили из зависимостей… Но, несмотря на то, что лоадер скорее мёртв, приобретенный опыт продолжает жить Опыт, выражающийся в понимании, что чем меньше код знает о внешнем мире, тем лучше В знании, что с грамотной спецификацией, задачу можно перенести в контекст, про который её авторы даже не подозревали6</a> В понимании, что система импортов — это не что-то “данное сверху”, а ещё одно API, которое можно</a> подстроить под себя</a> И в знании, что тестировать можно не только текущие версии интеграции, но прошлые и будущие7</a> Может, отпугнуло сообщение на сайте PEGjs, что библиотека “is very much in development”; может, хотелось иметь возможность сгенерировать парсер в Python… ↩︎</a> </li> Как же приятно иметь оправдание для запрещённого приёма… ↩︎</a> </li> Для проверки версии лучше не писать свой парсер semver’а, а использовать уже существующий</a> ↩︎</a> </li> Честно говоря, это делать необязательно, но желательно. Так они смогут сообщить, что лоадер мешает им обновиться, и попросят меня проверить совместимость с новой версией React’а ↩︎</a> </li> После публикации записи, перенёс CI на Github Actions и немного упростил конфиги для тестирования совместимости</a> ↩︎</a> </li> Первые коммиты в mustache</code> были задолго до публичного анонса Реакта, но благодаря подробному описанию и ограниченному синтаксису первого, подружить его со вторым было довольно легко ↩︎</a> </li> Когда в Preact’е поломалась совместимость между версиями, можно было не только починить её</a>, но и добавить тесты, чтобы предотвратить повторение этой проблемы в будущем ↩︎</a> </li></ol></div>

Pull Request Assignees</h2>
</p>
When all the prose is written, it needs an audience. And you should know your audience</em></p>

Code review & response</h2>
</p>
So, your colleague has written and described the code, you’ve gotten a notification about her pull request. What’s next?</em></p>

P.S. // 2021-05-02</h3>
Иногда, автоматический кроппинг порождает шедевры:</p>
</p>
`/</code> в конце необязательный, но с ним скриншот читается немного получше` `↩︎</a></p> </li></ol></div>`

zemlan.in

On Code Reviews

What Are Code Reviews For?</h2>

Server-side Rendering: CDN and Caching

Server-side Rendering: The Server

Server-side Rendering: Backstory

Рекомендации, Алгоритмы и Пространство

If you want to drive a submarine, you gotta join the Navy

everywhere is undefined

Склепал линкблог

Code review & response

Думки про pull request assignee

Створення pull request’у

Навіщо code review

iOS Lock Screen, Powered by Microsoft

Widgetarian

Заброшенное в карантин: Pepperoni

Reuse500

Готовить/ся

Усатый ядерщик

zemlan.in

On Code Reviews

What Are Code Reviews For?</h2>

Pull Request Assignees</h2> </p> When all the prose is written, it needs an audience. And you should know your audience</em></p>

Code review & response</h2> </p> So, your colleague has written and described the code, you’ve gotten a notification about her pull request. What’s next?</em></p>

Server-side Rendering: CDN and Caching

Server-side Rendering: The Server

Queries and Cache</h2> Okay, next; loading data</p>

Are we done?</h3> In theory, now we have our web app rendered with API data — we just insert it into <div id="root"></div></code> in a barebones index.html</code></p>

Server-side Rendering: Backstory

What then?</h2> So we’ve decided to:</p>

Рекомендации, Алгоритмы и Пространство

If you want to drive a submarine, you gotta join the Navy

everywhere is undefined

Склепал линкблог

Code review & response

Думки про pull request assignee

Створення pull request’у

Навіщо code review

iOS Lock Screen, Powered by Microsoft

Ссылки</h2> Scriptable</a></li> Руководство пользователя Быстрых команд</a></li> </ul> P.S. // 2021-05-02</h3> Иногда, автоматический кроппинг порождает шедевры:</p> </p>

P.S. // 2021-05-02</h3> Иногда, автоматический кроппинг порождает шедевры:</p> </p>

Widgetarian

Мой первый виджет</h2> Для того, чтобы вывести самый базовый виджет, достаточно трёх строк кода (даже двух, если забить на дебаг):</p>

This House is not a DOM</h2> API для работы с виджетами в Scriptable похож</em> на браузерный DOM, но не DOM. Например:</p>

Заброшенное в карантин: Pepperoni

Reuse500

Готовить/ся

Усатый ядерщик

Pull Request Assignees</h2>
</p>
When all the prose is written, it needs an audience. And you should know your audience</em></p>

Code review & response</h2>
</p>
So, your colleague has written and described the code, you’ve gotten a notification about her pull request. What’s next?</em></p>

P.S. // 2021-05-02</h3>
Иногда, автоматический кроппинг порождает шедевры:</p>
</p>
`/</code> в конце необязательный, но с ним скриншот читается немного получше` `↩︎</a></p> </li></ol></div>`