#!/bin/bash | |
# Script to update a firewall rule in a Hetzner Firewall with your current IP address. | |
# Good if you would like to restrict SSH access only for your current IP address (secure). | |
################# | |
# WARNING: This script will overwrite all rules in the firewall rules, so make sure you | |
# added all the required rules. | |
# I use a separate firewall rule just for SSH access. | |
################# |
package main | |
import ( | |
"bufio" | |
"fmt" | |
"log" | |
"os" | |
) | |
func main() { |
"use client" | |
import * as React from "react" | |
import { buttonVariants } from "@/components/ui/button" | |
import { ScrollArea } from "@/components/ui/scroll-area" | |
import { Select, SelectContent, SelectItem, SelectTrigger, SelectValue } from "@/components/ui/select" | |
import { cn } from "@/lib/utils" | |
import { ChevronLeft, ChevronRight } from "lucide-react" | |
import { DayPicker, DropdownProps } from "react-day-picker" |
Working with DATE
, TIMESTAMP
, and INTERVAL
in PostgreSQL can be confusing. In this article I will go over the three date/time related data types, and the two most useful date/time functions: DATE_PART
and DATE_TRUNC
. Finally, I will provide some real life examples of how these types and functions can be used within queries.
PostgreSQL Date/Time Documentation
The DATE
type contains the year
, month
, and day
of a date. It is not possible to do any type of time
related functions on a DATE
without first converting it to a TIMESTAMP
. Subtracting two DATE
values from one another results in an INT
representing the # of days between.
The TIMESTAMP
type contains a year
, month
, day
, hour
, minute
, second
, and microsecond
. This is the type that I most often use.
@Composable | |
fun SettingPreference( | |
preference: Preference, | |
onClick: (Any) -> Unit | |
) { | |
when (preference) { | |
is BasicPreference -> { | |
BasicPreference( | |
preference = preference, | |
onClick = onClick |
@Composable | |
fun Screen() { | |
var date by remember { | |
mutableStateOf( | |
TextFieldValue( | |
text = "dd-MM-yyyy" | |
) | |
) | |
} |
object BottomSheetDefaults { | |
@Stable | |
val Elevation = 16.dp | |
@Stable | |
val OuterPadding: PaddingValues = PaddingValues(top = 48.dp) |
In the olden days, HTML was prepared by the server, and JavaScript was little more than a garnish, considered by some to have a soapy taste.
After a fashion, it was decided that sometimes our HTML is best rendered by JavaScript, running in a user's browser. While some would decry this new-found intimacy, the age of interactivity had begun.
But all was not right in the world. Somewhere along the way, we had slipped. Our pages went uncrawled by Bing, time to first meaningful paint grew faster than npm, and it became clear: something must be done.
And so it was decided that the applications first forged for the browser would also run on the server. We would render our HTML using the same logic on the server and the browser, and reap the advantages of both worlds. In a confusing series of events a name for this approach was agreed upon: Server-side rendering. What could go wrong?
In dark rooms, in hushed tones, we speak of colours.
package des.c5inco.material3 | |
import android.graphics.Matrix | |
import android.graphics.Path | |
import androidx.compose.animation.core.* | |
import androidx.compose.foundation.Canvas | |
import androidx.compose.foundation.layout.Box | |
import androidx.compose.foundation.layout.Column | |
import androidx.compose.foundation.layout.fillMaxSize | |
import androidx.compose.foundation.layout.size |