Using Fedora 38, say you want to update the package albert from manuelschneid3r, hosted at https://software.opensuse.org/download.html?project=home:manuelschneid3r&package=albert.
And with dnf update, you get the following output:
~ sudo dnf update
Dependencies resolved.
Forked from piscisaureus
To identify one particular pull request, find the pull request number on the Azure DevOps site:
Then fetch and checkout the pull request in a local branch named pull/137
| // What system are we connected to? | |
| systeminfo | findstr /B /C:"OS Name" /C:"OS Version" | |
| // Get the hostname and username (if available) | |
| hostname | |
| echo %username% | |
| // Get users | |
| net users | |
| net user [username] |
| using System.Collections; | |
| using UnityEngine; | |
| using UnityEngine.UI; | |
| public static class ScrollViewFocusFunctions | |
| { | |
| public static Vector2 CalculateFocusedScrollPosition( this ScrollRect scrollView, Vector2 focusPoint ) | |
| { | |
| Vector2 contentSize = scrollView.content.rect.size; | |
| Vector2 viewportSize = ( (RectTransform) scrollView.content.parent ).rect.size; |
Application Programming Interface (API) design is hard. But it's even harder to change once you get it wrong. So what you should do is to spend the effort to get it right the first time around.
In the Linux Kernel community Rusty Russell came up with a API rating scheme to help us determine if our API is sensible, or not. It's a rating from -10 to 10, where 10 is perfect is -10 is hell. Unfortunately there are too many examples at the wrong end of the scale.
| export const db = [ | |
| { | |
| id: 1, | |
| name: 'Lukather', | |
| image: 'guitarra_01', | |
| description: 'Morbi ornare augue nisl, vel elementum dui mollis vel. Curabitur non ex id eros fermentum hendrerit.', | |
| price: 299, | |
| }, | |
| { | |
| id: 2, |
