andre/30-seconds-of-code
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Rename language articles

Browse Source
This commit is contained in:
Angelos Chalaris
2023-05-19 00:00:59 +03:00
parent 2d58c1dfd7
commit bf824750ce
3 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
snippets/articles/s/5-tips-for-better-pull-requests.md
View File

@ -1,33 +0,0 @@
---
title: 5 tips for better Pull Requests
type: story
language: git
tags: [github,programming,webdev]
author: chalarangelo
cover: keyboard-tea
excerpt: Writing good code is only part of the job. Here are 5 tips to improve your pull requests and help people review them.
unlisted: true
dateModified: 2021-06-12T19:30:41+03:00
---
Writing good code is only part of the job. Here are 5 tips to improve your pull requests and help people review them:
### Small pull requests
The pull requests that get reviewed more thoroughly and confidently and are most often prioritized by developers with limited time are the smallest ones. Make sure you separate concerns into different pull requests (e.g. refactoring and feature implementation), while also keeping commits atomic and well-documented to make the changes easier to understand and review.
### Good descriptions
Always take the time to describe your code and any related tasks in your pull request. Explain the feature you are implementing or the bug you are fixing and provide images and steps to reproduce, if applicable. Note decisions made during implementation, your approach, as well as any limitations, findings and points of interest that might help others better understand your code.
### Rebase onto master
Always rebase your pull requests onto the `master` branch of the repository. This way you can always test your code against the latest changes and resolve merge conflicts, minimizing issues that might arise later on. Apart from that, reviewers will not have to deal with missing features or bug fixes that might have been deployed already, which can considerably speed up review times.
### Review it yourself
Before submitting your pull request for review, always take the time to review it yourself. That way you can handle some low-hanging fruits (typos, easy optimizations, leftover code etc.) and check things you would in other people's pull requests. Self-reviewing has the added benefit of allowing you to reason about decisions and realize which ones might need clarification.
### Respond to reviews
Set some time aside to respond to reviews after submitting your pull request. Handle anything you can as soon as possible and start discussion whenever necessary to arrive to a solution. Use `--fixup` for changes suggested in review comments or add new commits to help reviewers parse new changes more easily. Finally, assume good intentions, be polite and thank your peers.

2
snippets/articles/s/8-tips-for-accessible-websites.md
View File

@ -2,7 +2,7 @@
title: 8 tips for accessible websites
shortTitle: Accessibility tips
type: story
language: javascript
language: html
tags: [accessibility,webdev]
author: chalarangelo
cover: accessibility

53
snippets/articles/s/responsive-favicon-dark-mode.md
View File

@ -1,53 +0,0 @@
---
title: How can I create a custom responsive favicon for dark mode?
shortTitle: Responsive dark mode favicon
type: question
language: css
tags: [visual]
author: chalarangelo
cover: dark-mode
excerpt: Learn how to create a custom responsive favicon that can adapt its color palette for dark mode with this quick guide.
dateModified: 2021-09-28T19:40:01+03:00
---
The rise of dark mode in recent years has made many website favicons feel awkward or even impossible to see in some cases. Provided you have the appropriate assets, it's relatively easy to create a responsive favicon that can **adapt to the user's color scheme preferences**.
In order to create a responsive favicon, you need an **SVG icon** with as few colors as possible and two color palettes, one for light mode and one for dark mode. Usual rules about icon clarity and complexity apply, so make sure your icon meets all the necessary criteria to be visually distinguishable in any scenario. In our example, we will be using a monochrome icon from the fantastic [Feather icon set](https://feathericons.com/).
Leveraging embedded styles in SVG images and the `prefers-color-scheme` media query, we can create an appropriate `<g>` element to group all the elements of the icon. Then, using the `id` of the group, we can apply the color palette for each design. Here's what our final SVG asset looks like:
```html
<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24">
<style>
#icon {
stroke: #000;
stroke-width: 2px;
stroke-linecap: round;
stroke-linejoin: round;
fill: none;
}
@media (prefers-color-scheme: dark) {
#icon {
stroke: #fff;
}
}
</style>
<g id="icon">
<path d="M6 2L3 6v14a2 2 0 0 0 2 2h14a2 2 0 0 0 2-2V6l-3-4z"></path>
<line x1="3" y1="6" x2="21" y2="6"></line>
<path d="M16 10a4 4 0 0 1-8 0"></path>
</g>
</svg>
```
After creating the SVG asset, you need only include the custom SVG favicon in the page's `<head>` element and you're ready to go. Be sure to include a PNG fallback, if possible, with a rendered version of the icon in either palette:
```html
<head>
<!-- Provided you have a rendered PNG fallback named favicon.png -->
<link rel="icon" type="image/png" href="favicon.png" >
<!-- Provided the SVG icon is named favicon.svg -->
<link rel="icon" type="image/svg" href="favicon.svg" >
</head>
```