The length of a slice may be changed as long as it still fits within the limits of the underlying array; just assign it to a slice of itself. The capacity of a slice, accessible by the built-in function cap, reports the maximum length the slice may assume. Here is a function to append data to a slice. If the data exceeds the capacity, the slice is reallocated. The resulting slice is returned. The function uses the fact that len and cap are legal when applied to the nil slice, and return 0.
slice > array[len]
if array[len] == len[arr] > new(arr[len(arr)+1] = "data") > copy to addr arr > replace
if array[len] == len[arr] > new(arr[len(arr)+1] = "data") > copy to addr arr > replace
Programming Notes ✍️
slice > array[len] if array[len] == len[arr] > new(arr[len(arr)+1] = "data") > copy to addr arr > replace
func Append(slice, data []byte) []byte {
l := len(slice)
if l + len(data) > cap(slice) { // reallocate
// Allocate double what's needed, for future growth.
newSlice := make([]byte, (l+len(data))*2)
// The copy function is predeclared and works for any slice type.
copy(newSlice, slice)
slice = newSlice
}
slice = slice[0:l+len(data)]
copy(slice[l:], data)
return slice
}
l := len(slice)
if l + len(data) > cap(slice) { // reallocate
// Allocate double what's needed, for future growth.
newSlice := make([]byte, (l+len(data))*2)
// The copy function is predeclared and works for any slice type.
copy(newSlice, slice)
slice = newSlice
}
slice = slice[0:l+len(data)]
copy(slice[l:], data)
return slice
}
Programming Notes ✍️
https://medium.com/@nur_islam/design-a-least-recently-used-lru-cache-in-go-golang-298d4ce3f3ec
package main
import (
"log"
"time"
)
type LRUCache struct {
NodeMap map[int]Node
Cap int
}
func NewLRUCache(c int) *LRUCache {
return &LRUCache{
Cap: c,
NodeMap: make(map[int]Node, c),
}
}
type Node struct {
value int
lastUsed time.Time
}
// Put ...
func (lru *LRUCache) Put(key, value int) {
mSize := len(lru.NodeMap)
var leastRecentUsedKey int
leastRecentUsedValue := time.Now()
// remove if the max size reached
if mSize >= lru.Cap {
// remove most recent one
for key, v := range lru.NodeMap {
if v.lastUsed.Before(leastRecentUsedValue) {
leastRecentUsedKey = key
leastRecentUsedValue = v.lastUsed
}
}
delete(lru.NodeMap, leastRecentUsedKey)
}
lru.NodeMap[key] = Node{
value: value,
lastUsed: time.Now(),
}
}
// Get ...
func (lru *LRUCache) Get(key int) int {
val, prs := lru.NodeMap[key]
if prs {
return val.value
}
return -1
}
func main() {
// create lru with size specified
lru := NewLRUCache(5)
// check no value case -> return -1
log.Println(lru.Get(1))
// use of put
lru.Put(1, 1)
lru.Put(2, 2)
// use of get
log.Println(lru.Get(1))
log.Println(lru.Get(2))
}
/*
Design a data structure that follows the constraints of a Least Recently Used (LRU) cache.
Implement the LRUCache class:
* LRUCache(int capacity) Initialize the LRU cache with positive size capacity.
* int get(int key) Return the value of the key if the key exists, otherwise return -1.
* void put(int key, int value) Update the value of the key if the key exists.
Otherwise, add the key-value pair to the cache.
If the number of keys exceeds the capacity from this operation, evict the least recently used key.
*/
How to choose the right pattern
Rough mental checklist:
I have multiple identical units of work → worker pool (with a job channel).
I have multi-stage processing → pipeline + fan-out/fan-in.
I just need to safely share and mutate some data → mutex / RWMutex, maybe atomics.
I need to limit concurrency → semaphore via buffered channel or worker pool size.
I need cancellation/timeout → context.Context + select.
I’m overcomplicating things with channels → step back, consider a simple mutex.
Rough mental checklist:
I have multiple identical units of work → worker pool (with a job channel).
I have multi-stage processing → pipeline + fan-out/fan-in.
I just need to safely share and mutate some data → mutex / RWMutex, maybe atomics.
I need to limit concurrency → semaphore via buffered channel or worker pool size.
I need cancellation/timeout → context.Context + select.
I’m overcomplicating things with channels → step back, consider a simple mutex.
A thread is a single sequence stream within a process. Threads are also called lightweight processes as they possess some of the properties of processes. Each thread belongs to exactly one process.
What STAR stands for
Situation - the situation you had to deal with
Task - the task you were given to do
Action - the action you took
Result - what happened as a result of your action and what you learned from the experience
Situation - the situation you had to deal with
Task - the task you were given to do
Action - the action you took
Result - what happened as a result of your action and what you learned from the experience
# Demonstrating (mis)use of special methods
class SillyClass:
def getitem(self, key):
""" Determines behavior of
return [True, False, True, False]
def pow(self, other):
""" Determines behavior of
return "Python Like You Mean It"
class SillyClass:
def getitem(self, key):
""" Determines behavior of
self[key] """return [True, False, True, False]
def pow(self, other):
""" Determines behavior of
self ** other """return "Python Like You Mean It"
terminal themes
https://github.com/YabataDesign/afterglow-theme
https://github.com/YorickPeterse/Autumn.vim ( preferd )
https://github.com/YabataDesign/afterglow-theme
https://github.com/YorickPeterse/Autumn.vim ( preferd )
GitHub
GitHub - YabataDesign/afterglow-theme: [DEPRECATED] A minimal dark Theme for Sublime Text 2 and 3
[DEPRECATED] A minimal dark Theme for Sublime Text 2 and 3 - YabataDesign/afterglow-theme
For effective security logging and monitoring, consider the following types of logging:
File Access: Who has viewed or downloaded a specific file?
Authentication Attempts: Have any incorrect authentication attempts occurred?
Login Activity: Who has logged in recently?
Unexpected Events: Have authentication events happened at unexpected times or from unexpected locations?
These types of logging help in detecting and responding to security breaches promptly.
File Access: Who has viewed or downloaded a specific file?
Authentication Attempts: Have any incorrect authentication attempts occurred?
Login Activity: Who has logged in recently?
Unexpected Events: Have authentication events happened at unexpected times or from unexpected locations?
These types of logging help in detecting and responding to security breaches promptly.
Server Side Request Forgery (SSRF) is a vulnerability that allows an attacker to coerce a server to send crafted requests to unintended destinations. When SSRF is present, attackers can send requests pretending to be the victim server, potentially accessing sensitive and administrative functions like internal API calls and database queries. To prevent SSRF, it's important to enforce an allowlist or blocklist for external resources, ensuring that only legitimate requests are processed.