I have been studying for technical interviews and I do not really know what to expect from these interviews. I assume there would be some coding exercises and maybe a system design question. I suck at LeetCode problems so I should probably do more of them.
Bit.ly is a URL shortener. This is a pretty common beginner systems question.
Core entities represent the primary objects in our system. These are derived from our requirements. Examples can include "URL", "User", "Transaction" and so on. They often map directly to database tables but can also represent more abstract concepts as well.
In a relatoional database design, more core entities will have corresponding tables.
The core entities for the Bit.ly URL shortener are:
The API is the contract between the client and the server. How we move data from client to server and vice versa. There are many different types of APIs, but we will use REST and the HTTP methods.
(CRUD)
Now before the APIs are built, we should consider the services offered and create a separation of concerns. There are actually two services being offered, a URL shortener and a forwarding service. One is incredibly reliant on the other.
This API endpoint will take in the long URL as well as a custom alias and expiration date.
// URL POST
{
"long_url": "https://example.com/some/long/ass/path",
"alias": "short_alias",
"exp_data": "optional_expiration_data"
}
->
{
"short_url": "http://short.ly/abc"
}
//Redirect to original URL
GET /{short_code}
-> HTTP 302 Redirect to the original URL recieved from the user.
We start the design by going one-by-one through our functional requirements and designing single systems to meet them.
The URL shortener core requirement should take a POST request from the user, compute a shortened URL (optional alias), and then store the record in the database.
When the system recieves a POST request from the user:
Users should be able to access the original URL from the shortened URL.
When the system recieves a GET request from the user with a shortened URL:
I would imaging that using a hashing function would work. Adding a hash feature to the URL entity could make chaining possible. Especially if we use SHA-256 for optimal number of hashes.
| Column Name | Data Type |
|---|---|
| URL | VARCHAR(2048) |
| shortURL | VARCHAR(255) |
| hash | VARCHAR(64) |
| created | TIMESTAMP |
| expiration | TIMESTAMP |
| createdBy | VARCHAR(255) |
The next entry would have to read the previous entry's hash then incoporate that into computing its hash. This would create a chain. We could also add an authentiction server that stores hashes in a hashmap that can be quickly searched for verification purposes.
Scaling can be done simply. We can have a separation of concerns from the URL shortener service and the forwarding service. We can assume that less links will be made than they will be searched since 1 user can shorten a link and any one can use it to get to the original URL.
Scaling horizontally will make it easier if we separate our services out to different servers and architecture.
I have been hearing a lot of hoopla about Rust's type system and how it is better than Go's from a bunch of crusty rustaceans. I realized that although I have used Go for some projects and really enjoy the language, I do not understand the type system as well as Python's and C's. I would like to do a deep dive, and compare Rust to Go from a beginner's perspective.
Rust
Go
Both languages have fixed-size ints for better control over memory.
Rust
Go
Rust
Go
Rust
Go
It is important to note that the char in Rust is guranteed to be a valid Unicode scalar point, but the rune in Go can be any Unicode code point. They are both 4 bytes. Go's rune is more flexible and can represnt a wider range of Unicode code points, but you have to check the validity of the Unicode scalar point values.
Rust Example:
let valid_char: char = 'A'; // Valid Unicode scalar value
let invalid_char: char = '\uD800'; // Invalid Unicode scalar value (lone surrogate)
// This will compile without errors:
println!("{}", valid_char);
// This will result in a compile-time error:
println!("{}", invalid_char);
Go Example:
var validRune rune = 'A' // Valid Unicode code point
var invalidRune rune = '\uD800' // Invalid Unicode scalar value (lone surrogate)
fmt.Println(validRune) // Output: A
fmt.Println(invalidRune) // Output: 55296 (the numerical value of the invalid code point)
Composite data types are data types that are constructed from combinations of primitive data types. They allow you to represent more complex structures and relationships between data elements.
Arrays in Go and Rust both work the same: fixed-size collectinos of elements of the same type. Both support slicing, and passed by value (Rust has ownership rules). Rust arrays are immutable by default but can be made mutable using the mut keyword. Go arrays are mutable by default, and does not follow strict borrowing rules. It can be modified freely unless passed as a parameter then it is passed by value and results in a copy being made.
Rust Example: Mutable Array
let mut arr = [1, 2, 3];
arr[0] = 10;
Go Example:
arr := [3]int{1, 2, 3}
arr[0] = 10
Go has a garbage collector so we do not need to worry about deallocating and cleaning up ourselves, unlike Rust. That being said, Rust does use the stack as the default storage for arrays. Arrays in Go are value types, meaning when we pass it to a function it will be copied unless we use pass by reference.
Slices in Go are dynamic views of arrays and more commonly used. Go slices are more related to vectors as they can grow and shrink in size as needed. In Rust, slices are references to the data they point to and they do not own the data. Their size is dynamic and determined at runtime.
Go Slice Example:
arr := [3]int{1, 2, 3}
slice := arr[1:]
Rust Slice Example:
fn main() {
let mut arr = [1, 2, 3, 4, 5]; // Mutable array
let slice = &mut arr[1..4]; // Mutable slice
slice[0] = 10; // Modify the first element of the slice
println!("{:?}", arr); // Output: [1, 10, 3, 4, 5]
}
Both languages support structs or groups related data. They differ in features, memory management (surprise!), and flexibility.
// Simple struct
type Person stuct {
Name string
Age int
}
// Instantiation and usage
person := Person{Name: "Alice", Age:30}
fmt.Println(person.Name)
person.Age = 31
// Methods on structs
func (p Person) Greet() string {
return "Hello, " + p.Name
}
// Pointer and Mutability
func (p *Person) HaveBirthday() {
p.Age += 1
}
In Go, structs are passed by value. If we want to modify the data in the struct, we must use a pointer.
// Struct definition
struct Person {
name: String,
age: u32,
}
//Instantiation and usage
let person = Person { name: Sting::from("Alice"), age: 30}; // ugly ass syntax
println!("{}", person.name);
let mut person = person;
person.age = 31;
// Methods on structs
impl Person {
fn greet(&self) -> String {
format!("Hello, {}", self.name)
}
}
//Ownership and borrowing Methods
impl Person {
fn have_birthday(&mut self) {
self.age += 1;
}
}
| Feature | Go Structs | Rust Structs |
|---|---|---|
| Syntax | Fields and types are defined like normal variables | Fields are defined with type annotations |
| Mutability | Fields are mutable by default | Fields are immutable by default; mut required for mutation |
| Memory Safety | Relies on garbage collection | No garbage collection; uses ownership and borrowing for memory safety |
| Default Values | Fields have zero values when not initialized | No default values; all fields must be initialized |
| Methods | Methods defined with receivers (value or pointer) | Methods defined inside impl blocks with self |
| Struct Composition | Uses embedding for inheritance-like behavior | No inheritance; composition via traits |
| Passing by Value/Reference | Structs are passed by value unless a pointer is used | Structs are passed by value unless a reference (&) is used |
| Memory Management | Structs are garbage collected | Rust structs follow ownership and borrowing rules |
| Trait Implementations | No built-in trait system | Supports traits for behavior reuse across types |
Both languages are not object oriented in the tradditional sense. Rust still adheres to the core pricniples of OOP through traits. Go is also object oriented-like through the use of interfaces.
type Animal interface {
Speak()
}
type Dog struct {
Name string
}
func (d Dog) Speak() {
fmt.Println("Woof!")
}
type Cat struct {
Name string
}
func (c Cat) Speak() {
fmt.Println("Meow!")
}
func main() {
dog := Dog{Name: "Buddy"}
cat := Cat{Name: "Whiskers"}
var animal Animal
animal = dog
animal.Speak()
animal = cat
animal.Speak()
}
trait Animal {
fn speak(&self);
}
struct Dog {
name: String,
}
impl Animal for Dog {
fn speak(&self) {
println!("Woof!");
}
}
struct Cat {
name: String,
}
impl Animal for Cat {
fn speak(&self) {
println!("Meow!");
}
}
fn main() {
let dog = Dog { name: "Buddy".to_string() };
let cat = Cat { name: "Whiskers".to_string() };
dog.speak();
cat.speak();
}
MacOS has a implemented a new security layer for their new M1 Macs. If you were to buy a Mac owned by a company that closed its doors and can not disable the MDM system, you would have some options on the Intel platform. Bootable USBs make it easy to reinstall MacOS, Windows, or Linux. With the new Macs, you would be left with a paper weight. This is not a perfect fix. After every major update, the MDM enrollment can reactivate. Rebooting can also lead to the same results and render the Mac useless.
Often times, companies sell Macs without removing the MDM or they go under and sell off their computers in bulk and forget about it.
PIP is a security mechanism that helps prevent unauthorized modifications to the system software and firmware. It's designed to protect the device from malicious software and unauthorized access. It really focuses on three things to ensure system integrity:
Here is some more info: https://support.apple.com/en-us/102149
In the terminal we can disable PIP:
csrutil disable
A property list is a file format used by Apple to store configuration data and settings for various applications and system components on MacOS.
They are used frequently in MacOS, we can see just how many starting at root here:
That's a lot of property lists. We can edit the property list that contains data about mobile device management.
sudo vi /System/Library/LaunchDaemons/com.apple.ManagedClient.enroll.plist
We need to change
<key>com.apple.ManagedClient.enroll</key>
<true/>
to be
<key>com.apple.ManagedClient.enroll</key>
<false/>
0.0.0.0 iprofiles.apple.com
0.0.0.0 mdmenrollment.apple.com
0.0.0.0 deviceenrollment.apple.com
0.0.0.0 gdmf.apple.com
0.0.0.0 acmdm.apple.com
0.0.0.0 albert.apple.com
sudo launchctl disable system/com.apple.ManagedClient.enroll
# Resets the cloud configuration activation status.
sudo rm /var/db/ConfigurationProfiles/Settings/.cloudConfigHasActivationRecord
# Forces a re-search for cloud configurations.
sudo rm /var/db/ConfigurationProfiles/Settings/.cloudConfigRecordFound
# Indicates that a cloud configuration profile has been installed.
sudo touch /var/db/ConfigurationProfiles/Settings/.cloudConfigProfileInstalled
# Indicates that a cloud configuration record was not found.
sudo touch /var/db/ConfigurationProfiles/Settings/.cloudConfigRecordNotFound