A web server is running on a remote machine and is accessible only via localhost; it does not accept external connections. The only way to access this machine is through SSH.
The goal is to implement the ability to send HTTP requests to this web server from within a Go application by establishing an SSH tunnel programmatically.
Sometimes there’s a need to create a PostgreSQL backup using readily available tools and restore this backup into another database, for example, for testing purposes.
We will use the pg_dump and pg_restore utilities to achieve this.
Depending on the specifics, there are other solutions too, such as connecting a replica or using logical subscriptions.
However, these may require administrative privileges that are often not available when using cloud infrastructure.
We’ll also refresh our memory on working with Docker and SQL.
2 Creating a Cloud Database
We’ll use a remote database on Vercel via the Neon service.
Neon is a cloud-native, serverless-compatible PostgreSQL platform.
Sometimes you need to visually represent some simulation or process.
The main requirements are support for the Go language, since calculations are done in Go, and ease of use.
Let’s look at ebiten, one of the most popular libraries for working with graphics.
The main use of ebiten is creating interactive 2D games.
We will use the library to draw some dynamic process.
2 Julia Set
As an example, let’s try to draw the Julia set.
The Julia set is described by the equation J(f)={z∈C∣limn→∞∣fn(z)∣=+∞}
1 How to Intercept and Decrypt TLS Traffic from curl?
1.1 Цель
Sometimes, for debugging purposes, you may want to inspect the contents of HTTPS traffic.
For example, a client uses cURL to communicate with a public API server.
But sometimes something goes wrong. The client doesn’t receive a response, even though the server logs show the request was successfully processed and a response was sent. It seems something is getting lost among various proxies and subnets.
In such cases, you can try capturing network activity between the client and the service at different points, decrypt the data, match the requests and responses, and check whether anything was lost.
Every day from December 1 to 25 came with two new tasks.
The first task was usually simple, helping to understand the problem clearly.
The second task was harder, with changes or new rules that made the first solution useless.
This often meant improving the algorithm a lot or finding a completely different way to solve it.
The first half of the tasks was relatively simple, while solving the final challenges required some hints.
Overall, it was an excellent opportunity to revisit and apply algorithms.
The challenge of solving daily problems on LeetCode for a year (excluding vacations) has come to an end.
Over the year, I solved 707 problems, categorized as follows: 261 Easy, 365 Medium, 81 Hard.
I mainly focused on daily challenges and “favorite” topics. The most interesting topics were Trie, Dynamic Programming, and Design.
Almost all problems were solved using C++, though I also experimented with Go. However, Go proved unsuitable for algorithmic problems due to its limitations. In contrast, C++ offers a much broader range of concepts, enabling more elegant and optimal solutions.
I took on these problems to prepare for algorithmic interview sections, all of which I passed successfully.
Going forward, I don’t plan to focus on algorithmic problem-solving anymore. If I feel like tackling challenges, I’ll turn to CTF problems, which are far more practical and diverse.