NOTES ON LEARNING, BUILDING & TAKING THINGS APART.
A domain name feels like the address of a website. Behind that familiar name are several independent pieces: registration, DNS, hosting, and HTTPS. Keeping them separate makes the setup much easier to reason about.
The name and the machine
Registering a domain gives you the right to use that name for the registration period. It does not, by itself, create a website or run an application. The page still needs a place to live.
DNS provides the connection between a name and the service that handles it. An A record associates a name with an IPv4 address. A CNAME record makes one name an alias of another name.
A domain, a DNS service, and a web host can come from different providers.
One domain, different destinations
The main site and a blog do not have to use the same hosting project. Each hostname can have its own configuration.
| Address | Purpose |
|---|
sahharov.ee | Portfolio |
blog.sahharov.ee | Notebook |
On GitHub Pages, the project’s custom-domain setting also matters. DNS brings the request to GitHub’s infrastructure; the hostname tells the service which configured site should respond.
Inspecting the records
On a system with dig installed, these queries show the relevant record types. Their results depend on the actual published DNS configuration.
dig sahharov.ee A +short
dig blog.sahharov.ee CNAME +short
A change in the DNS control panel is not necessarily visible everywhere immediately. Recursive resolvers can keep previously received records in their caches until those cached entries expire.
Where HTTPS fits
HTTPS encrypts the connection and lets the browser authenticate the server for the requested hostname. The certificate needs to cover that hostname; pointing a DNS record at a server alone is not enough.
GitHub Pages can request and manage a certificate for a correctly configured custom domain. DNS validation and certificate provisioning are related steps, but they are not the same step.
A useful way to troubleshoot
- Check the hostname you actually typed.
- Inspect its published DNS records.
- Check the custom-domain setting at the host.
- Check whether HTTPS is ready for that hostname.
Separating these layers helps identify where a failure occurs instead of repeatedly changing every setting at once.
A pointer is easier to understand when the example stays small. Begin with one integer, rather than an array, a linked list, or a dynamically allocated structure.
A value and its address
int value = 42;
int *pointer = &value;
value is an integer object containing 42. The expression &value produces its address. The pointer stores that address, so it can refer to the same object.
Following the pointer
*pointer = 100;
/* value is now 100 */
In this expression, *pointer designates the object at the stored address. Assigning to it changes value, not an independent copy of that integer.
The address and the value at that address are different things.
The star depends on its context
In the declaration int *pointer, the star is part of the declarator: it declares a pointer to an integer. In the expression *pointer, it is the indirection operator.
The syntax looks similar because the declaration describes how the name can be used. Reading complete statements is more useful than assigning one universal meaning to the symbol.
Passing information back
void set_value(int *output) {
*output = 7;
}
int number = 0;
set_value(&number);
/* number is now 7 */
The pointer argument is passed by value: the function receives a copy of the address. Both the original address and its copy can still refer to the same integer.
Keep track of lifetime
A pointer is not a promise that its target still exists. Before dereferencing one, the program must ensure that it refers to an appropriate live object. A null pointer is not a valid target for this operation.
When learning, draw the integer and the pointer as two separate objects. Label the stored integer value, then label the stored address. That small distinction helps make later array and memory-allocation examples less surprising.
A collection of commands can be useful, but it does not always explain an experiment. A stronger note connects a question, an action, an observation, and the conclusion that observation supports.
Start with a question
Write down what you are trying to find out. A narrow question makes it easier to decide which output matters and what information you still need.
“Does this hostname resolve?” is a more testable question than “Why is the internet broken?”
Record the environment
Include the operating system, relevant application version, and a brief description of the setup. If an interface name or working directory matters, record it next to the command.
Keep enough context to reproduce the observation, but leave credentials and other private material out of a public write-up.
Keep commands beside observations
A simple structure is enough:
Question:
What am I testing?
Action:
What did I run or change?
Observation:
What actually happened?
Interpretation:
What does that result support?
Separate results from assumptions
An observation is something the test showed. An explanation is an interpretation of that observation. It is useful to make the boundary explicit, especially when more than one explanation fits the result.
If the next test would distinguish those explanations, record that test as the next step. The note then captures the reasoning as well as the commands.
Leave a useful ending
- What changed in your understanding?
- Which parts of the result are specific to this environment?
- What remains unresolved?
- Where can you find the documentation again?
The goal is not to make every lab note long. It is to make the important parts understandable after the details are no longer fresh.