DEV Community: UponTheSky

[Opinion]Today's frontend is easy to be messed up and we need to organize it

UponTheSky — Sun, 01 Feb 2026 06:25:49 +0000

Disclaimer: This post is a mixture of ranting about the complexity of the contemporary frontend, and my thought on how to solve it. I have been away from the frontend/React world for a while, so this post might contain some out-of-date ideas. Please let me know if you find such ideas while reading this post. Also, although I only discuss React/Next.js here, I think the argument could be extended to the entire frontend system as of now, regardless of framework. Therefore I will use the words "frontend" and "React" interchangeably throughout the post.

React is dang complex

Lately, I was involved in a task to develop an application where the frontend is to be developed in Next.js. Although I have done a bunch of tasks where I had to use React and Next.js, at those times I didn't have to deal with the design part, and all I was doing was tossing and turning the data from the backend and making React components to present it. However, this was my first time that I had to seriously consider the visual design part as well, from the layout to the font color of a small text under <div> tag. And man, it was super difficult!

But why? Why was it that difficult? For sure the amount of CSS document pages from MDN was overwhelming, but that was a pretty minor issue. The harder part was that it was very very easy to write messy React components (Here, what I mean by "messy code" is that it is difficult to recognize what the purpose or responsibility of this component is, and very hard to track the behavior and the state updates).

But before you are about to blame me for my skill issue, calm down and think up of the last React/Next.js code that you encountered. If you can't, visit a few pages about advanced topics in the official React documentation homepage. For example, the following is an excerpt of code from the page about managing input and states:

export default function Form() {
  const [answer, setAnswer] = useState('');
  const [error, setError] = useState(null);
  const [status, setStatus] = useState('typing');

  if (status === 'success') {
    return <h1>That's right!</h1>
  }

  async function handleSubmit(e) {
    e.preventDefault();
    setStatus('submitting');
    try {
      await submitForm(answer);
      setStatus('success');
    } catch (err) {
      setStatus('typing');
      setError(err);
    }
  }

  function handleTextareaChange(e) {
    setAnswer(e.target.value);
  }

  return (
    <>
      <h2>City quiz</h2>
      <p>
        In which city is there a billboard that turns air into drinkable water?
      </p>
      <form onSubmit={handleSubmit}>
        <textarea
          value={answer}
          onChange={handleTextareaChange}
          disabled={status === 'submitting'}
        />
        <br />
        <button disabled={
          answer.length === 0 ||
          status === 'submitting'
        }>
          Submit
        </button>
        {error !== null &&
          <p className="Error">
            {error.message}
          </p>
        }
      </form>
    </>
  );
}

Of course, this is a relatively simple and straightforward example, but there are still lots of things to consume. There are already three states, nested HTML elements, two event handlers, and even a conditionally rendered component, even in a fairly simple and decent example. Why is this so complex?

Well, I believe that there is an innate issue which is hard to overcome in React (or frontend in general). That is, a React component needs to represent information from a managed state in the form of JSX, which is simply a "nicer" version of HTML. But doesn't this sound way too natural? How could it be an essential problem of React and frontend?

Frontend = State + hierarchical presentation

I believe any frontend technologies including mobile ones are essentially about how to manage the current state (either on the frontend or on the backend) and render it in hierarchical views. Being hierarchical implies several issues, but to name a few:

How to make the layout: What is the relationship between potentially conflicting sibling HTML nodes? How many children would you put under the current <form>? How to deal with responsive design?
How to manage the states: For rendering this particular dataset, are we going to fetch all the resources in a single place and distribute them to several HTML elements, or would it be better to make several API calls from each of the small elements themselves? How about data update and re-rendering? Would it be better to make data fetching in a parent or in its children?

Because state management and layout are essentially coupled but the HTML elements must be hierarchical at the same time, things are very likely to become complex (or as I expressed in the title, messed). Think about the above excerpt as an example. Suppose you want to switch the <textarea> element to <selector> for enabling users to choose the answer rather than typing it manually, but the answer candidates are dynamic, which means you have to fetch the list of the answers from the backend. Then you might "naturally" think of adding useEffect in the same Form component:

export default function Form() {
    // [...]
    const [countries, setCountries] = useState([]);

    useEffect(async () => {
      try {
        const response = await fetch("GET_COUNTRY_LIST_API");
        const data = await response.json();

        setCountries(data.countries || []);
      } catch (error) {
          setError(error);
      }
    }, []);

    // [...]
}

Do you think this is a good solution? Some of you might say yes, and others may not. Would it be simpler to fetch countries here in the same Form where the data is to be rendered and submitted again, or somewhere else so that Form is purely responsible for submitting data? There is no absolutely correct or incorrect answer, and it is totally up to the developer to decide. However, whereas there are so-called "best practices" or "design patterns" for the backend, for the frontend there seem to be no such widely used or accepted patterns to the best of my knowledge.

Revisiting Container-Presentational pattern

Dan Abramov's famous "Presentational-Container" pattern provides a useful insight for organizing this mess (for an easier introduction, I recommend reading this post on pattern.dev). From my understanding, you can have the following two patterns of writing React components: stateful (or non-functional) and stateless (or purely functional).

Stateful components manage the application's internal states. They could be either pure client-side states such as the current text value in an input element, or something to be fetched from the backend or third-party APIs. In short, any component with useState, useEffect, or fetch calls is stateful.
Stateless components are purely functional, in that the data they read is immutable and there is no internal side effect caused by useEffect. They are only responsible for how to visualize the given data.

Let's get back to the above excerpt. The Form component is obviously stateful, where it manages several states using useState. If we ever add useEffect here for fetching the list of candidate countries, then the component is also responsible for handling data fetched from the backend.

This separation of concerns is especially useful for maintenance. If you want to add any additional data submission, you can tweak this Form component. If you have a problem in submitting country text, then there must be something wrong inside this Form.

Furthermore, if we want to refactor this component according to the Presentational-Container pattern, then we separate the HTML components in the return statement and pass the states and callbacks for state updates like this:

export const FormBox = ({
    title,
    description,
    answer,
    status,
    error,
    handleSubmit,
    handlerTextareaChange,
}: props) => {
    return (
        <>
          <h2>{title}</h2>
          <p>
              {description}
          </p>
          <form onSubmit={handleSubmit}>
            <textarea
              value={answer}
              onChange={handleTextareaChange}
              disabled={status === 'submitting'}
            />
            <br />
            <button disabled={
              answer.length === 0 ||
              status === 'submitting'
            }>
              Submit
            </button>
            {error !== null &&
              <p className="Error">
                {error.message}
              </p>
            }
          </form>
        </>
    );
};

However, this logical separation itself may not be enough. Since the frontend elements are hierarchical, there is no limit to putting another stateful element inside a stateless element. If this is the case, then is that stateless element purely stateless? Even if it doesn't manage any state at all, you may have to look into this element because the state you want to check out is managed by this element as a parent.

export function FormLayout() {
    return (
        <div>
            {/* some other components*/}
            <Form />
        </div>
    );
}

In the above code example, we have Form inside FormLayout. Now, although FormLayout has nothing to do with any form submission logic, you are still very likely to visit this component while searching in your IDE or browser developer tool as long as the FormLayout component is conceptually tied to the form submission. Yes, we need a more comprehensive mental model for further organization of our frontend code.

Revisiting Atomic Design

Brad Frost's Atomic Design suggests another great insight for organizing our React project. Although he introduces five levels of component designs analogous to chemistry, my takeaway is that you can think of an entire frontend page in two aspects.

Layout: Layout only concerns how to place several visual components on a screen, such as how big this image should be and where to put it, or how we arrange those cards inside a flexbox, etc. This part is purely related to CSS but you need to make sure each individual component doesn't affect the other elements visually such as by unexpected resizing or content overflow.
Feature page: This is about what this single component is trying to convey with its content to the users product-wise. Please note that I am using the word "single" here, for we want to handle a component with the single responsibility principle. A single product feature can consist of several sub-features. For example, a form submission page can contain several various inputs for text and file upload. Each single feature is responsible for handling UI and data states.

Now we can see that the naming FormLayout is somewhat misleading, in that it can contain not only the form submission page but other features such as the navigation bar or a Google Ads banner. If this is the case, then we might as well use another name such as "QuizPageLayout" instead.

So far so good, now we have our mental model for separating concerns. There is a hierarchical structure of features for the entire project, and each individual feature should be assigned its own space as a page by the layout logic at its tree-level. Each feature fetches and updates its own feature data. I would like to refer to this mental model as Layout - Page. Have you noticed any familiar names? You're right. This model works naturally with Next.js.

Layout - Page Model

Let's discuss the Layout-Page model in more details in conjunction with the Container-Presentational pattern we discussed previously.

First, Layout corresponds to organisms, templates, and pages in Atomic Design. It is responsible only for how to arrange several components on the entire screen. It decides the position, display, and size of each component. It may contain some visual components such as dividers, but those are pretty rare. Layout never deals with how to render each individual component (Page), even including its margin or padding properties.
Next, each Page represents a single feature in the product, with the Single Responsibility Principle in mind.
- It is responsible for fetching and updating the data relevant to the feature in the backend, and managing the UI states on the client side, if necessary. That is, there could also be stateless and purely functional pages that only visualize the data that is passed to them.
- A page consists of two elements: its own layout and sub-pages(!). Hence, in every single page, there is another layout and sub-pages. If a page only consists of basic HTML elements and no other React components, then we may say this page is a leaf page.

Hence the structure here is recursive. You have a tree of pages, and each page is logically separated into layouts and sub-pages. For example, we can organize the Form element and possibly related components as follows:

QuizPage
├── @AdsBanner
│   ├── @Page
│   └── Layout
├── @QuizSubmitPage
│   ├── @Page # <Form> will be in this page
│   └── Layout
└── Layout

Note that this tree structure is very similar to the structure of Next.js App Router. However, Next.js itself doesn't really enforce any design principles for developers, so you won't find the idea argued here in the Next.js documentation. It is totally up to you, the developer, to decide how to organize your project. However, the mechanism of App Router that Next.js provides fits perfectly with the idea of the Layout-Page model, and in fact, a part of inspiration of this model is from the App Router itself.

If we translate the structure above into a Next.js file routing system, then it would be like this:

quiz
├── @adsbanner
│   ├── page.tsx
│   └── layout.tsx
├── submit
│   ├── page.tsx # <Form> will be in this page
│   └── layout.tsx
├── layout.tsx
└── page.tsx

Here, note that we use a parallel route for the ads banner component, since we don't want the user to access the banner only through an exposed route. Also, it is not under submit/ but under quiz/, which means the banner will show up in the other sub-routes of quiz/, not limited to its submission page /quiz/submit. In general, it is essential to utilize the parallel routes in the Next.js App Router system for the Layout-Page model, as there is no guarantee that only one sub-feature exists inside a product feature.

To recap, the entire recursive tree structure of a project according to the Layout-Page model is like this:

Project
├── Layout
├── Page0
│   ├── Layout
│   ├── Page00
│   │   ├── Layout
│   │   ├── Page000
│   │   ...
│   ├── Page01
│   ├── Page02
│ ...
├── Page1
├── Page2
├── Page3
...

Before the end the post

I would like to mention that this might not be my original idea, and someone somewhere could have already thought of this mental model and publicized under a name that I haven't heard of yet. However, it was not easy for me to come up with this idea after a long time of searching for any useful idea for organizing the frontend messes, that wasn't much successful. It would be great to see any comments on this. Thank you.

[Book Review]AI Engineering by Chip Huyen

UponTheSky — Fri, 28 Nov 2025 17:15:09 +0000

Amazon Page

I finally finished reading AI Engineering by Chip Huyen. It is a truly amazing book in many ways, but to name a few:

It is comprehensive: From hardware to software, from foundation models to user-facing applications, the author covers almost every aspect we can think of when it comes to AI engineering. I was astonished by how huge the field is, and there are myriad things to know and consider when building an AI-powered application. Of course, the book was published a while ago (early this year), so it cannot cover the most recent updates in the AI industry, but it tries to explain the essential parts rather than excessive details.
It is reader-friendly and well organized: I have read many technical books for my profession, but obviously there are so many books that simply "dump" explanations with insufficient context and incoherent structure. This book reads as if there were a young graduate student tutor at a university who tries to make you understand as much as possible. There are hardly any difficult concepts left unexplained, and each of the chapters has a clear and reasonable structure.
It is a well-grounded technical book: The author doesn't simply tell you what things are based solely on her own opinions. Every paragraph is full of quotations from trusted technical papers, blogs, articles, and more. You might feel like you are reading a technical report or a paper from an AI conference. Therefore, I think this book is very useful as a reference that you can return to frequently. I would probably re-read it a few months.

Overall, I think the book is a very good start to understanding the general concepts of AI engineering and the field itself. Of course, given the depth of its content, the book serves not only as an excellent introduction but also as a valuable reference.

[Book Review] Build a Large Language Model (From Scratch) by Sebastian Raschka

UponTheSky — Wed, 08 Oct 2025 01:25:13 +0000

TL; DR

A very practical book to learn the general concepts of LLMs
- Saving tons of time from having to search for materials for many topics separately
Very informative but somewhat intensive; must take some time to follow the book while getting your hands dirty with Python code

Overall Review

In the era of LLMs, there seem to be a strong demand for understanding them. However, like other "hot" fields, there are so many materials about LLMs and it is not easy to find a solid resource. Either they focus on how to use LLMs (yes, you need OPEN_AI_KEY=your_own_openai_key!) or fill entire pages with pure texts and diagrams explaining what a transformer architecture is.

I know, the field is literally overwhelming. Developing and serving LLMs is one of the most fast-moving fields both in academia and industry, and there are so many parts to cover, from bare-metal hardware to user experiences on edge devices. Considering tons of papers and codebases out there, I doubted anyone would dare to touch the topic so thoroughly, such as building an LLM from scratch.

But here we are - Sebastian Raschka, PhD
has accomplished such tremendous work in his book Build a Large Language Model (From Scratch) .

I know there are already thousands, if not millions, of great reviews of the book, so I would like to briefly share my takeaways from reading it over the last few days.

With only a basic understanding of ML and Python coding, you can grasp the general concepts of how an LLM works from this book. The code examples are not overly technical and clear to understand.
The explanations are very friendly and thorough. As you work through the book and type out the Python code yourself, you can tell whether you're going in the right direction. However, because the explanations are so detailed, reading through the book make take more time than you expect, given the book's length.
The book covers core concepts of modern LLMs - token embedding, attention and the transformer architecture, deep learning and neural networks, pre- and post-training(or fine tuning). After finishing the book, I feel more ready to understand articles and posts about topics like attention or KV-cache.
Personally, it was a very good review of deep learning and neural networks. For people who have no idea what PyTorch is, one of the appendices is dedicated to introducing PyTorch. I highly recommend reading it before diving into chapter 1.

My 2 Cents for Those Who Haven't Read the Book Yet

My opinion on the prerequisites:
- Python: I don't think you need to worry too much about your proficiency with the language. Reading a general introductory book on the language is sufficient. The book doesn't use very sophisticated Python techniques, such as writing your own context managers or decorators.
- Math, Deep Learning, and PyTorch: In addition to basic knowledge of linear algebra, I feel hands-on experience with matrix computation is essential. Especially when it comes to constructing your own attention algorithm, complex tensor multiplications could be somewhat confusing, and you should keep track of the dimension of each of nn.Linear layers.
Still, running the code on local Apple machines is not desirable. I used my Mac M3 Pro with the MPS backend, but a few computation results were different from what those shown in the book. I would try using Google Colab or other similar services on the second read.
Appendices are not negligible. I think the one about LoRA is a must-read. Also, I find the ones from the book's Github Repo are extremely useful to keep up with the recent LLM research and developments.

That's it! This is my short review of the book, Build a Large Language Model (From Scratch) . I hope you enjoy reading it as much as I did!

[Go, Opinion] How can we write truly "middle"ware with Go's net/http?

UponTheSky — Wed, 01 Oct 2025 07:41:43 +0000

TL; DR

A common middleware pattern with the net/http package cannot handle outgoing responses
A delicate approach to manipulating Handler is necessary, but it is still fairly limited

So, we all know how to write middleware with Go's `net/http`?

After learning and playing around with the net/http package for a while (of course, with some help from books and other resources), I was pretty satisfied with how I came up with a way to write middleware in Go. It was elegant and very straightforward, as follows:

func AddSomeMiddleware(
    handler http.Handler,
    someFunc func(r *http.Request),
) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // do something right before the handler handles the request
        someFunc(r)

        // the handler that this middleware wraps around
        handler.ServeHTTP(w, r)
    })
}

The function above takes a handler and a function to be invoked before the handler, and returns a new handler by simply composing them with http.HandlerFunc.

If you search for how to write middleware in Go, I would say about 7 or 8 out of 10 results will show exactly the same pattern as above. I thought this pattern serves exactly what we need from middleware when writing server applications.

Middleware of `net/http` is only half middleware

However, I ran into a problem this simple pattern cannot handle. Did you notice? Yes, this middleware cannot touch the response part! Take a look at the code again:

func AddSomeMiddleware(
    handler http.Handler,
    someFunc func(r *http.Request),
) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        someFunc(r)
        handler.ServeHTTP(w, r)

        // what about afterwards?
        // we want something like postProcess(w)
    })
}

Of course AddSomeMiddlware can still mess with http.ResponseWriter even after handler.ServeHTTP(w, r) is invoked. But what if handler has already written a body that you want to postprocess?

The problem gets trickier when it comes to writing headers, as once ResponseWriter.WriteHeader has been called:

Changing the header map after a call to ResponseWriter.WriteHeader has no effect unless the HTTP status code was of the 1xx class or the modified headers are trailers.

Since ResponseWriter.Write calls ResponseWriter.WriteHeader if it has not been explicitly invoked beforehand, you cannot add, remove, or modify the headers (try yourself!). In short, you lose control over the response part once you hand over http.ResponseWriter to the handler. net/http expects http.Handler to finish handling an entire HTTP request. This extraordinary feature of the net/http package makes our middleware as half middleware.

Wrapping another `http.Handler` is not a solution

We might trust an http.Handler not to write the response, and wrap it with middleware:

func AddSomeMiddleware(
    handler http.Handler,
    someFunc func(r *http.Request),
    postProcess func(w http.ResponseWriter),
) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        someFunc(r)
        handler.ServeHTTP(w, r)

        // this postProcess knows nothing about the handler above
        postProcess(w)
    })
}

Unfortunately, this doesn't resolve the problem at all, since postProcess knows nothing about what's happening inside handler.ServeHTTP. What are the headers? What is the status code? Without that information, we cannot send back a response to the client. Also, what about early return? If there is an error inside handler.ServeHTTP, writing a response afterward is meaningless.

Moreover, there are several useful functions that help write an HTTP response directly to http.ResponseWriter. For example, http.Error is very useful to write a succinct error response, and the encode/json package has Encoder.Encode that enables writing an application/json response in a single line.

if err := json.NewEncoder(w).Encode(jsonBody); err != nil {
    log.Println(err)
    http.Error(w, "internal server error", http.StatusInternalServerError)
    return
}

Therefore, it is very tempting to write the response inside handler.ServeHTTP.

How about writing custom "handlers"?

One way of resolving this issue would be to write our own handlers that don't expose themselves to the raw *http.Request and http.ResponseWriter. A mock example could be as follows:

// Controller handles low-level ResponseWriter and Request
func SomeController(w http.ResponseWriter, r *http.Request) {
    // parse the raw request
    request := parseRequest(r)

    // middleware for the incoming request
    request = requestMiddleware(request)

    response, err := SomeService.Handle(request)

    if err != nil {
        // early return
        log.Println(err)
        http.Error(w, "some error message", someErrorCode)
        return
    }

    // middleware for the outgoing response
    response = responseMiddlware(response)

    // write the response finally
    writeResponse(w, response)
}

// custom request
type Request struct {
    // ...
}

// custom response
type Response struct {
    // ...
}

// custom handler
type Handler interface {
    Handle(r Request) Response
}

This may comes at a cost. It could be overwhelming to redesign the Request and Response if we want to do it properly. However, once we know what we're doing, it doesn't have to be difficult. You might not use a brand new Request at all but instead use the plain *http.Request. Furthermore, the response type could be this simple:

type Response struct {
    headers map[string]string
    cookies []*http.Cookie
    body    any

    // additional necessary fields
    // ...
}

Then what about middleware? One strategy is to divide middleware into two categories:

The first category of middleware directly interact with *http.Request, such as http.TimeoutHandler, or the middleware pattern we introduced early in this article. This category provides low-level functionality, such as logging the basic information about the request.
The second category is about the service level of the application, such as requestMiddleware or responseMiddleware functions inside SomeController in the example code. As long as the service logic functions maintain the functional form of func Handler(Request) (Response, error), then we can easily chain those functions where wrapping functions work as middleware.

func WrappingServiceHandler(r Request) (Response, error) {
    r = beforeMiddleware(r)

    response, err := WrappedServiceHandler(r)

    if err != nil {
        // early return
        return nil, err
    }

    response = afterMiddleware(response)

    return response, nil
}

Conclusion

Unless we write our own web framework in Go, this half middleware pattern is not easy to overcome. In this article, we suggested a pattern with an abstraction cost. Of course, it doesn't resolve all our problems and might incur several edge case problems.

If we know what we are doing, maybe it is more sensible to repeat the post processing logic right before writing the response inside each of handler.ServeHTTP. Yes, as usual, it depends...

[C#]I tried Primeagen’s way for learning C#

UponTheSky — Tue, 28 Jan 2025 14:59:41 +0000

Source of the title image: https://commons.wikimedia.org/wiki/File:Logo_C_sharp.svg

If you’re a software engineer, you’ll probably have learned multiple programming languages either due to your interest or need. That is, while you may have a main language, you need to learn a new language for different projects. In my case, expecting my next few projects to require knowledge of C#, I was looking for some smart ways to learn it efficiently - methods that are not mundane but still cover essential parts of the language.

Then I came across a few videos by ThePrimeagen about learning a new programming language. Primeagen is one of the most famous IT influencers, and I’ve been enjoying his videos on YouTube for quite a while. So, I thought it was a good opportunity to try his method and see if it works for me.

What is "Primeagen’s way?"

The video above and a short are the resources that I followed. In short, his method for learning a new programming language can be summarized in three to four steps:

First, skim through the documentation of the language and briefly review its syntax.
Second, try several exercises from Advent of Code to get some ideas about the language.
Third, implement a very simple chat client.
Finally, work on a larger project.

A disclaimer: I tried the first three parts but omitted the final one, since it is expected to be a long-term project and it doesn’t only involve pure software engineering skills. Also, I chose to implement a chat server instead of chat client, because I was more familiar with the backend programming.

How I followed "Primeagen's way"

1. A tour of the language

To begin the first step, I chose to skim through Tour of C#. While it wasn't a thorough introduction, it allowed me to sketch a broad overview of the language, including the following:

Basic types, operations, loops, conditions
OOP features such as class, struct, inheritance, and access modifiers
LINQ (I felt this was a really cool feature of the language)
Asynchronous programming

In addition to "Tour of C#", I explored other pages and tried to get familiar with the language. My first impression was that C# is very much like Java, but with a few features for functional programming such as Delegates.

2. Ten exercises of Advent of Code

Then I dived into Advent of Code, a popular platform for challenging and fun coding exercises. I only tried ten (five days, two problems per day) days of exercises from the 2024 version, because I didn’t want to focus solely on coding exercises.

To solve the problems, I began with printing “Hello, World!” on my local machine. So I installed .NET SDK (version 9.0) and generate a CLI template with it.
Then I learned how to read data from .txt files on disk. I used .txt files for reading the inputs.
I practiced a few OOP concepts, such as access modifiers, namespaces, inheritance, and static keywords.
I used built-in data structures like LinkedList<T> and Dictionary<K, V>.

Although this was a good start, I began to wonder whether doing AoC is an ideal way to learn a new language.

The platform provides no hint, so you must devise on your own solutions. This might encourage brute force methods instead of teaching yourself efficient data structures or language-specific features.
Many problems involve extensive use of regex to parse input data, which can shift your focus from learning the language itself to searching for various regex patterns.
A few exercises were tricky, taking up much longer time to complete than expected.

In retrospect, it could have been more effective to solve easy-level problems on LeetCode instead. Platforms like NeetCode offer helpful recommendations, such as "NeetCode 150".

This is my repo for AoC.

namespace CSharp
{
    internal abstract class BaseSolution(string file)
    {
        protected readonly string file = file;

        public abstract int Run();

        protected static IEnumerable<string> ReadFrom(string file)
        {
            string? line;

            using (var reader = File.OpenText(file))
            {
                while ((line = reader.ReadLine()) != null)
                {
                    yield return line;
                }
            }
        }
    }
}

AoC taught me the basics of C#.

3. Implementing a chat server

After completing the first ten exercises from AoC, I moved on to the next step - implementing a chat server. At this point, I wasn’t really sure what Primeagen meant by "implementing". Did he mean I should start from scratch and use low-level socket libraries? Or was I allowed to simply use a well-tested web framework? I thought the former would be daunting, so I chose the latter approach and looked up the .NET documentation.

There are several ways to implement backend APIs in .NET. I chose the controller-based APIs because they were simpler and required less boilerplate than the “classic” MVC, but still more structured than the minimal APIs. Since I expected to frequently encounter old-style C# code, I thought it would be a good opportunity to get used to the old OOP style of C#. For implementing chat communication, I referenced .NET’s WebSockets documentation.

During the project, I learned how .NET handles a web application in general. It was interesting to compare .NET with Python frameworks that I was familiar with. It was very similar to FastAPI, where APIs are declared rather than manually implemented, and it is allowed to adjust details such as middlewares and other initial configurations. It was also similar to Django, since DB migration and ORM were fully integrated through Entity Framework Core.

[HttpGet("ws/{id}/join")]
public async Task JoinChatRoom([FromRoute] string id)
{
    // reference: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/websockets?view=aspnetcore-9.0
    if (HttpContext.WebSockets.IsWebSocketRequest)
    {
        var userIpAddress = GetUserIPAddress();

        _logger.LogInformation("User {ip} joins ChatRoom {id}", userIpAddress, id);

        if (!Guid.TryParse(id, out Guid idInUUID))
        {
            HttpContext.Response.StatusCode = StatusCodes.Status400BadRequest;
            return;
        }

        var chatRoom = await _context.ChatRoomItems.SingleAsync(item => item.Id == idInUUID);

        if (chatRoom == null)
        {
            HttpContext.Response.StatusCode = StatusCodes.Status404NotFound;
            return;
        }

        using var webSocket = await HttpContext.WebSockets.AcceptWebSocketAsync();
        await RunChatLoop(webSocket, chatRoom, userIpAddress ?? "noname");
    }
}

I implemented a very simple chat server API.

However, I am not sure I learned any advanced features of C# throughout this project, because I literally followed the well-structured documentation rather than implementing my own functions. I didn’t need to exploit several strong features of C#. Alternatively, I might have had a better chance to try advanced C# features, if I had started by implementing a web server from scratch. However, as I mentioned earlier, that would have turned into a much longer project.

This is the repo for my chat server project.

Is Primeagen’s way recommendable for learning a new language?

I don’t like to say this silver bullet phrase but… "it depends". However, I would like to extend the sentence as follows: "it depends on the LANGUAGE of choice".

Is the language similar to the one you are already familiar with?

For example, if your main language is Python or JavaScript, learning C++ or Rust as a new language might be more difficult and certainly I can’t recommend Primeagen’s way. However, if it is Ruby, the initial effort required would be much lower. In my case, I was a little bit familiar with Java, so picking up the features and syntax of C# was relatively smooth.

Are there good resources for the language or frameworks?

Personally, I think this is one of the most important aspects of learning a new language (or any new technology in general). Compared with Ruby or Python, C# has a very good collection of the official documentation pages and it is very beginner-friendly.

Do you already have a clear idea about a fun project?

You may recall that I omitted the last step - doing an actual project of your interest. When working on your own project, you will need to consider logic involving data structures and algorithms, as well as organize a larger project, where you have to take care of building and publishing the application.

In other words, you will learn the nuts and bolts of the features of the language applied to the application. But I think this is more about how to design a product and not just about learning a new language. So I think this step must be about a project that you are already familiar with, and you have a clear design for the entire application.

Conclusion

To summarize, I suggest you to try this Primeagen’s way if

the language you want to learn is similar to a language you are already familiar with; otherwise you would be better off starting from a few tutorials,
you can easily access beginner-friendly resources for the language, and
you have a fun project and you already have a clear idea about it.

Additionally, if I start over Primeagen’s way again for another language, I would probably try my own variation as follows:

First, skim through a concise tutorial that covers the essential concepts of the language.
Next, solve all the easy-level problems from "NeetCode 150".
Implement a simple multi-threaded web server. Rust’s THE BOOK has a good example.

Overall, it was a good experience, and I learned a lot from Primeagen’s approach. However, I think you need to modify it to suit your own case.

[Opinion] I’ve passed an AWS cert… but is this something for me?

UponTheSky — Sun, 20 Oct 2024 03:56:48 +0000

(Image source: https://www.irasutoya.com/2020/08/blog-post_42.html)

Passing an exam must feel great, but…

Yes, as the title suggests, I’ve passed AWS SAA(solutions architect associate). It is one of the most well-known certification in the IT world, and many developers try to start their cloud journey with this cert. I’ve spent almost three months preparing for the exam, including taking a famous Udemy course and an exam bundle from another famous website(of course, a completely legitimate one).

Do I feel good? Yes, but at the same time, No. As a matter of fact, I kind of feel incomplete and unsatisfied for having taken this exam. I am not saying that AWS or this SAA-03 cert is bad at all. However, I’d like to share my experience and thoughts on this cert. And you might relate my thoughts to any certifications in general.

I pass the exam but I feel somewhat unsatisfied.

Purpose of getting a cert

I had two main purposes for getting this cert:

Getting familiar with AWS services: First of all, I listed my experience with AWS on my resume, but somehow I felt I knew nothing about it. So I thought it would be good to review the service and fundamental concepts such as IAM, scalability, or serverless.
Improving my resume: Another reason was a 'practical' one - to explicitly tell recruiters that I am certified and therefore qualified. Being in such an extremely saturated and competitive field, I thought getting a cert would be an essential one for landing my next job.

So let me ask myself: has successful getting the cert accomplished my original purposes? I would say WELL....

How SAA cert preparation was actually like

1. The SAA covers not just a few well-known services but a wide range of AWS services

You probably know the 80/20 principle. Basically it means that we use only 20% of something 80% of the time. For instance, we use 20% of all the English words way more often than the other 80%.

I think this applies to AWS services as well. As an ordinary web developer, I have only used EC2, ECS, Lambda, S3, and RDS. If you are more experienced and work at a big organization, your list would be longer. However, the number would be not that different.

However, while preparing the exam, I had to put into my head some very unfamiliar services that I might never use in the future, such as DataSync, Storage Gateway, Polly, and VPC Flow, to name a few. It makes sense that if I were to work as a solutions architect using AWS extensively, then I need to be familiar with the catalog of services that AWS provides, so that I could make reasonable decisions about which to use. Nevertheless, I had to memorize every detail of many services that I had never touched before. I felt like I was reading a food recipe that I have never seen, touched, or tasted before.

There are many AWS services out there(source: https://aws.amazon.com/blogs/architecture/maintain-visibility-over-the-use-of-cloud-architecture-patterns/).

2. The exam questions presents real-world scenarios

Most of the questions are like this: "You are a solutions architect at a company and the company uses this and that services, and you have a problem with that. How would you solve it?"

So if you have actual experience in using AWS extensively, you might find those exams interesting. However, as a person who have been spent 90% of time in writing application code, I found it difficult to engage with the practice problems.

For example, imagine you have never worked with Windows before, and you're asked to design a solution where you have to manage employee credentials using Windows AD on your on-premise server and migrate a Windows file systems database from the data center to AWS. Again, if you are a solutions architect, then I think you should know how to deal with such a problem. But as an application developer, would I ever encounter similar cases in the future?

Experience outweighs theory.

Overall, My LACK OF EXPERIENCE IN AWS was the main reason for my painful time in preparing for the cert. Although I managed to get a high score in the exam, I still feel I only become familiar with terminologies like subnet, IAM policy, IOPS, and so on. How could I claim to know more or work better than those who don't have the cert but have actual experience in AWS? Even if I can add a cert to my resume, can I confidently say that I can design a resilient and scalable distributed system in AWS?

All you need is experience. Keep practicing, and practicing.

What I would do if I go back in time?

As a matter of fact, the official guide of the cert recommends this cert to those who have more than one year of hands-on experience in AWS. You might say that getting a cert first gives you the whole picture of the AWS services at a high level, so that you would be able to touch the AWS services more smoothly. I woudl say NO. It was very painful experience to learn about services that I had never touched before. I would first gain more experience with those services first.

Personal project, actual work experience in enterprises, anything would do. I think it would be great to have an application that simulates AWS services so that one can exercise for free or at little cost. I haven't found any except LocalStack, so please let me know if there are other similar applications.

Conclusion

Well, having a cert is definitely worth it. I won't deny that. I learned a lot while preparing for the exam. However, now I realize that having a certification doesn't prove that you can actually solve real-world problems. I should keep learning and practicing; otherwise the cert itself would become a false representation of my skills.

[Python] How do we lazyload a Python module? - analyzing LazyLoader from MLflow

UponTheSky — Sat, 05 Oct 2024 11:53:18 +0000

(image source: https://www.irasutoya.com/2019/03/blog-post_72.html)

Intro

One day I was hopping around a few popular ML libraries in Python, including MLflow. While glancing at its source code, one class attracted my interest, LazyLoader in __init__.py (well, this actually mirrors from the wandb project, but the original code has changed from what MLflow is using now, as you can see).

You probably heard about the concept of lazyloading from many contexts, such as web frontend image loading, caching strategy, and so on. I think the essence of all those lazyloading concepts is, that "I am too lazy to load RIGHT NOW" - yes, the hidden words "right now". Namely, the application will load and use that resource only when it is needed. So here in this MLflow library, the modules are loaded only when the resources in it — variables, functions, and classes — are accessed.

But HOW? This was my main interest. So I read the source code, which looked very simple at first glance. However, surprisingly, it took a bit of time to understand how it works, and I learned a lot from reading the code. This article is about analyzing this source code of MLflow so that we understand how such lazyloading works using various techniques of Python language.

Playing around with `LazyLoader`

For the purpose of our analysis, I created a simple package called lazyloading on my local machine, and placed modules as follows:

lazyloading/
├─ __init__.py
├─ __main__.py
├─ lazy_load.py
├─ heavy_module.py

__init__.py: This file makes the entire directory into a package.
__main__.py: This file is the entry point when we want to run the entire package as follows: python -m lazyloading.
lazy_load.py: LazyLoader is in this file.
heavy_module.py: This represents a module with heavy packages to be loaded (such as PyTorch) for a simulation:

import time

for i in range(5):
    time.sleep(1)
    print(5 - i, " seconds left before loading")

print("I am heavier than Pytorch!")

HEAVY_ATTRIBUTE = "heavy”

Next, we import this heavy_module inside __main__.py:

if __name__ == "__main__":
    from lazyloading import heavy_module

Let’s run this package and see the result:

python -m lazyloading
5  seconds left before loading
4  seconds left before loading
3  seconds left before loading
2  seconds left before loading
1  seconds left before loading
I am heavier than pytorch!

Here we can clearly see that if we simply import heavy packages such as PyTorch, it could be an overhead for the entire application. That’s why we need lazyloading here. Let’s change __main__.py to look like this:

if __name__ == "__main__":
    from lazyloading.lazy_load import LazyLoader
    heavy_module = LazyLoader("lazyloading.heavy_module", globals(), "lazyloading.heavy_module")
    print("nothing happens yet")
    print(heavy_module.HEAVY_ATTRIBUTE)

And the result should be:

python -m lazyloading
nothing happens yet
5  seconds left before loading
4  seconds left before loading
3  seconds left before loading
2  seconds left before loading
1  seconds left before loading
heavy

Yes, any module imported by LazyLoader doesn’t need to execute any script or import other packages. It happens only when any attribute of the module is accessed. This is the power of lazyloading!

How LazyLoader works in MLflow? - source code analysis

The code itself is short and simple. I added type annotations and a few comments (lines enclosed in <, >) for explanations. All the other comments are the ones in the original source code.

"""Utility to lazy load modules."""
import importlib
import sys
import types

from typing import Any, TypeVar

T = TypeVar("T") # <this is added by me>

class LazyLoader(types.ModuleType):
    """Class for module lazy loading.

    This class helps lazily load modules at package level, which avoids pulling in large
    dependencies like `tensorflow` or `torch`. This class is mirrored from wandb's LazyLoader:
    https://github.com/wandb/wandb/blob/79b2d4b73e3a9e4488e503c3131ff74d151df689/wandb/sdk/lib/lazyloader.py#L9
    """

    _local_name: str # <the name of the package that is used inside code>
    _parent_module_globals: dict[str, types.ModuleType] # <importing module's namespace, accessible by calling globals()>
    _module: types.ModuleType | None # <actual module>

    def __init__(
        self, 
        local_name: str, 
        parent_module_globals: dict[str, types.ModuleType], 
        name: Any # <to be used in types.ModuleType(name=str(name)), the full package name (such as pkg.subpkg.subsubpkg)>
    ):
        self._local_name = local_name
        self._parent_module_globals = parent_module_globals
        self._module = None

        super().__init__(str(name)) 

    def _load(self) -> types.ModuleType:
        """Load the module and insert it into the parent's globals."""
        if self._module:
            # If already loaded, return the loaded module.
            return self._module

        # Import the target module and insert it into the parent's namespace

        # <see https://docs.python.org/3/library/importlib.html#importlib.import_module>
        # <absolute import, importing the module itself from a package rather than the top-level package only(like __import__)>
        # <here, self.__name__ is the variable `name` in __init__>
        # <this is why that `name` in __init__ must be the full module path>
        module = importlib.import_module(self.__name__) # this automatically updates sys.modules

        # <add the name of the module to the importing module(=parent module)'s namespace>
        # <so that you can use this module's name as a variable inside the importing module, even if it is called inside a function defined in the importing module>
        self._parent_module_globals[self._local_name] = module

        # <add the module to the list of loaded modules for caching>
        # <see https://docs.python.org/3/reference/import.html#the-module-cache>
        # <this makes possible to import cached module with the variable _local_name
        sys.modules[self._local_name] = module

        # Update this object's dict so that if someone keeps a reference to the `LazyLoader`,
        # lookups are efficient (`__getattr__` is only called on lookups that fail).
        self.__dict__.update(module.__dict__)

        return module

    def __getattr__(self, item: T) -> T:
        module = self._load()
        return getattr(module, item)

    def __dir__(self):
        module = self._load()
        return dir(module)

    def __repr__(self):
        if not self._module:
            return f"<module '{self.__name__} (Not loaded yet)'>"
        return repr(self._module)

Now, let’s investigate the code while lazyloading our heavy_module. Since we don’t need to simulate the heaviness of the module anymore, let’s get rid of the time.sleep(1) loop part.

1. Creating an instance of `LazyLoader`, proxying the original module

Let’s look at __init__() of LazyLoader.

class LazyLoader(types.ModuleType):
    # …
    # code omitted
    # …

    def __init__(
        self, 
        local_name: str, 
        parent_module_globals: dict[str, types.ModuleType], 
        name: Any # <to be used in types.ModuleType(name=str(name)); the full package name(such as pkg.subpkg.subsubpkg)>
    ):
        self._local_name = local_name
        self._parent_module_globals = parent_module_globals
        self._module = None

        super().__init__(str(name))

We provide local_name, parent_module_globals, and name to the constructor __init__(). At the moment, we are not sure what all those means, but at least the last line indicates that we are actually generating a module - super().__init__(str(name)), since LazyLoader inherits types.ModuleType. By providing the variable name, our module created by LazyLoader is recognized as a module with name name(which is the same as heavy_module.__name__).

Printing out the module itself proves this:

# __main__.py
# run python -m lazyloading

if __name__ == "__main__":
    from lazyloading.lazy_load import LazyLoader
    heavy_module = LazyLoader("lazyloading.heavy_module", globals(), "lazyloading.heavy_module")

    print(heavy_module.__name__)

which gives on our terminal:

lazyloading.heavy_module

However, in the constructor we only assigned values to the instance variables and gave the name of the module to this proxy module. Now, what happens when we try to access an attribute of the module?

2. Accessing an attribute - `getattribute`, `getattr`, and `getattr`

This is one of the fun parts of this class. What happens when we access an attribute of a Python object in general? Say we access HEAVY_ATTRIBUTE of heavy_module by calling heavy_module.HEAVY_ATTRIBUTE. From the code here, or from your own experience in several Python projects, you might guess that __getattr__() is called, and that’s partially correct. Look at the official docs:

Called when the default attribute access fails with an AttributeError (either getattribute() raises an AttributeError because name is not an instance attribute or an attribute in the class tree for self; or get of a name property raises AttributeError).

(Please ignore __get__ because it is out of scope of this post, and our LazyLoader doesn’t implement __get__ either).

So __getattribute__() the key method here is __getattribute__. According to the docs, when we try to access an attribute, __getattribute__ will be called first, and if the attribute we’re looking for cannot be found by __getattribute__, AttributeError will be raised, which will in turn invoke our __getattr__ in the code. To verify this, let’s override __getattribute__ of the LazyLoader class, and change __getattr__() a little bit as follows:

def __getattribute__(self, name: str) -> Any:
    try:
        print(f"__getattribute__ is called when accessing attribute '{name}'")
        return super().__getattribute__(name)

    except Exception as error:
        print(f"an error has occurred when __getattribute__() is invoked as accessing '{name}': {error}")
        raise

def __getattr__(self, item: T) -> T:
    print(f"__getattr__ is called when accessing attribute '{item}'")
    module = self._load()
    return getattr(module, item)

When we access HEAVY_ATTRIBUTE that exists in heavy_module, the result is:

if __name__ == "__main__":
    from lazyloading.lazy_load import LazyLoader
    heavy_module = LazyLoader("lazyloading.heavy_module", globals(), "lazyloading.heavy_module")

    print(heavy_module.HEAVY_ATTRIBUTE)

python -m lazyloading
__getattribute__ is called when accessing attribute 'HEAVY_ATTRIBUTE'
an error has occurred when __getattribute__() is invoked as accessing 'HEAVY_ATTRIBUTE': module 'lazyloading.heavy_module' has no attribute 'HEAVY_ATTRIBUTE'
__getattr__ is called when accessing attribute 'HEAVY_ATTRIBUTE'
__getattribute__ is called when accessing attribute '_load'
__getattribute__ is called when accessing attribute '_module'
__getattribute__ is called when accessing attribute '__name__'
I am heavier than Pytorch!
__getattribute__ is called when accessing attribute '_parent_module_globals'
__getattribute__ is called when accessing attribute '_local_name'
__getattribute__ is called when accessing attribute '__dict__'
heavy

So __getattr__ is actually not called directly, but __getattribute__ is called first, and it raises AttributeError because our LazyLoader instance doesn’t have attribute HEAVY_ATTRIBUTE. Now __getattr__() is called as a failover. Then we meet getattr(), but this code line getattr(module, item) is equivalent to code module.item in Python. So eventually, we access the HEAVY_ATTRIBUTE in the actual module heavy_module, if module variable in __getattr__() is correctly imported and returned by self._load().

But before we move on to investigating _load() method, let’s call HEAVY_ATTRIBUTE once again in __main__.py and run the package:

if __name__ == "__main__":
    from lazyloading.lazy_load import LazyLoader
    heavy_module = LazyLoader("lazyloading.heavy_module", globals(), "lazyloading.heavy_module")

    print(heavy_module.HEAVY_ATTRIBUTE)
    print(heavy_module.HEAVY_ATTRIBUTE)

Now we see the additional logs on the terminal:

# … the same log as above
__getattribute__ is called when accessing attribute 'HEAVY_ATTRIBUTE'
heavy

It seems that __getattribute__ can access HEAVY_ATTRIBUTE now inside the proxy module(our LazyLoader instance). This is because(!!!spoiler alert!!!) _load caches the accessed attribute in __dict__ attribute of the LazyLoader instance. We’ll get back to this in the next section.

3. Loading and caching the actual module

This section covers the core part the post - loading the actual module in the function _load().

3-1. Module caching at the level of `LazyLoader` class

First, it checks whether our LazyLoader instance has already imported the module before (which reminds us of the Singleton pattern).

if self._module:
    # If already loaded, return the loaded module.
    return self._module

3-2. Importing the actual module with `importlib.import_module`

Otherwise, the method tries to import the module named __name__, which we saw in the __init__ constructor:

# <see https://docs.python.org/3/library/importlib.html#importlib.import_module>
# <absolute import, importing the module itself from a package rather than the top-level package only(like __import__)>
# <here, self.__name__ is the variable `name` in __init__>
# <this is why that `name` in __init__ must be the full module path>
module = importlib.import_module(self.__name__) # this automatically updates sys.modules

According to the docs of importlib.import_module, when we don’t provide the pkg argument and only the path string, the function tries to import the package in the absolute manner. Therefore, when we create a LazyLoader instance, the name argument should be the absolute term. You can run your own experiment to see it raises ModuleNotFoundError:

if __name__ == "__main__":
    from lazyloading.lazy_load import LazyLoader
    heavy_module = LazyLoader("heavy_module", globals(), "heavy_module")

    print(heavy_module.HEAVY_ATTRIBUTE)

# logs omitted
ModuleNotFoundError: No module named 'heavy_module'

Notably, invoking importlib.import_module(self.__name__) caches the module with name self.__name__ in the global scope. If you run the following lines in __main__.py

if __name__ == "__main__":
    from lazyloading.lazy_load import LazyLoader
    heavy_module = LazyLoader("heavy_module", globals(), "lazyloading.heavy_module")

    # check whether the module is cached at the global scope
    import sys
    print("lazyloading.heavy_module" in sys.modules)

    # accessing any attribute to load the module
    heavy_module.HEAVY_ATTRIBUTE

    print("lazyloading.heavy_module" in sys.modules)

and run the package, then the logs should be:

python -m lazyloading
False
I am heavier than Pytorch!
True

This way of caching using sys.modules is related to the next two lines that also cache the module in different ways.

3-3. Caching the module with given `local_name`

# <add the name of the module to the importing module(=parent module)'s namespace>
# <so that you can use this module's name as a variable inside the importing module, even if it is called inside a function defined in the importing module>
self._parent_module_globals[self._local_name] = module

# <add the module to the list of loaded modules for caching>
# <see https://docs.python.org/3/reference/import.html#the-module-cache>
# <this makes possible to import cached module with the variable _local_name
sys.modules[self._local_name] = module

Both lines cache the module in the dictionaries self._parent_module_globals and sys.modules respectively, but with the key self._local_name(not self.__name__). This is the variable we provided as local_name when creating this proxy module instance with __init__(). But what does this caching accomplish?

First, we can use the module with the given _local_name in the "parent module"’s globals(from the parameter’s name and seeing how MLflow uses in its uppermost __init__.py, we can infer that here the word globals means (globals()). This means that importing the module inside a function doesn’t limit the module to be used outside the function’s scope:

if __name__ == "__main__":
    from lazyloading.lazy_load import LazyLoader

    def load_heavy_module() -> None:
        # import the module inside a function
        heavy_module = LazyLoader("heavy_module", globals(), "lazyloading.heavy_module")
        print(heavy_module.HEAVY_ATTRIBUTE)

    # loads the heavy_module inside the function's scope
    load_heavy_module()

    # the module is now in the scope of this module
    print(heavy_module)

Running the package gives:

python -m lazyloading
I am heavier than Pytorch!
heavy
<module 'lazyloading.heavy_module' from ‘…’> # the path of the heavy_module(a Python file)

Of course, if you provide the second argument locals(), then you’ll get NameError(give it a try!).

Second, we can also import the module in any other place inside the whole package with the given local name. Let’s create another module heavy_module_loader.py inside the current package lazyloading :

lazyloading/
├─ __init__.py
├─ __main__.py
├─ lazy_load.py
├─ heavy_module.py
├─ heavy_module_loader.py

Note that I used a custom name heavy_module_local for the local variable name of the proxy module.

# heavy_module_loader.py

from lazyloading.lazy_load import LazyLoader

heavy_module = LazyLoader("heavy_module_local", globals(), "lazyloading.heavy_module")
heavy_module.HEAVY_ATTRIBUTE

Now let __main__.py be simpler:

from lazyloading import heavy_module_loader

if __name__ == "__main__":
    import heavy_module_local
    print(heavy_module_local)

Your IDE will probably alert this line as having a syntax error, but actually running it will give us the expected result:

python -m lazyloading
I am heavier than Pytorch!
<module 'lazyloading.heavy_module' from ‘…’> # the path of the heavy_module(a Python file)

Although MLflow seems to use the same string value for both local_name and name when creating LazyLoader instances, we can use the local_name as an alias for the actual package name, thanks to this caching mechanism.

3-4. Caching the attributes of the actual module in `dict`

# Update this object's dict so that if someone keeps a reference to the `LazyLoader`,
# lookups are efficient (`__getattr__` is only called on lookups that fail).
self.__dict__.update(module.__dict__)

In Python, the attribute __dict__ gives the dictionary of attributes of the given object. Updating this proxy module’s attributes with the actual module’s ones makes the user easier to access the attributes of the real one. As we discussed in section 2(2. Accessing an attribute - __getattribute__, __getattr__, and getattr) and noted in the comments of the original source code, this allows __getattribute__ and __getattr__ to directly access the target attributes.

In my view, this part is somewhat unnecessary, as we already cache modules and use them whenever their attributes are accessed. However, this could be useful when we need to debug and inspect __dict__.

4. `dir` and `repr`

Similar to __dict__, these two dunder functions might not be strictly necessary when using LazyLoader modules. However, they could be useful for debugging. __repr__ is particularly helpful as it indicates whether the module has been loaded.

if not self._module:
    return f"<module '{self.__name__} (Not loaded yet)'>"
return repr(self._module)

Conclusion

Although the source code itself is quite short, we covered several advanced topics, including importing modules, module scopes, and accessing object attributes in Python. Also, the concept of lazyloading is very common in computer science, but we rarely get the chance to examine how it is implemented in detail. By investigating how LazyLoader works, we learned more than we expected. Our biggest takeaway is that short code doesn’t necessarily mean easy code to analyze!

[Book Review] Beej's Guide to Network Programming

UponTheSky — Sat, 13 Jul 2024 01:38:11 +0000

Intro - what is this book about?

Yes, I finally finished reading this book.

As a person who has never taken a computer networking course in university, I had thought for a long time of learning that subject intensively. However, I could not find a solid university course that is open to public(something like MIT’s introduction to algorithms). And many of the textbooks prefixed “introduction” spent hundreds of pages explaining quite low-level concepts such as routing algorithms or even physical wires that connect the continents!

Then I found Beej's Guide to Network Programming that is recommended frequently on the Internet. At a glance, I found it easy to read because of the author’s way of explaining concepts in a humorous manner. But at the same time, compared to other computer network books, this book contains many code examples, so that I thought it suits more for the programmers who want practical socket programming practice.

And after reading through all the chapters except chapter 9(because it is more like a reference for a bunch of C socket functions), I found it a good read.

Good parts

Friendly introduction to technical concepts

The book starts with a few basic concepts such as IP, port, and socket. However, it doesn’t go deeper into introducing very technical algorithms or physical devices used for network communications. As a developer who deals with web applications daily, I found it more relevant to my job. Even though the book sometimes mentions bits and bytes, it is still readable and you usually never do any bitwise operations while reading the C code in the book.

Plenty of code examples

For those who want to get their hands dirty with code, this book is for you. Except for the general overview parts on computer networking, most of the explanations in the book come with code examples in C. This is particularly useful for knowing how actual network communications occur inside our web applications. For example, the polling operation sweeps through all the registered sockets to check whether there are incoming events to be handled.

Moreover, the examples don’t import any external libraries, so you don’t have to deal with irritating third-party dependency problems.

Soso parts

Mainly focused on socket programming only

This book is very good as a friendly reference to socket programming and relevant system calls. However, it does not go “higher” or “lower”:

"higher": Most of today’s web applications rely on the HTTP protocol. It could have been better if the book contained more explanations on this higher layer with actual running code.
"lower": I think the book could have shown how a packet looks like using tools such as Wireshark that snatches packets generated by the examples. Introducing a few Linux/Unix commands for networking could also have been helpful for understanding how our application code interacts with the kernel.

However, I found another good resource written by the same author: Beej's Guide to Networking Concepts. It seems to cover many core concepts more comprehensively than this book with a lot of coding exercises. I hope this “concept” book will fill the gap of the “programming” book.

Not recommended for those who are not familiar with C code

If you don’t know much about C programming, this book could be overwhelming. It doesn’t explain any basic concepts such as pointers or type casting. Although we don’t suffer from dependency hell like when dealing with CMake, if you don’t know much about C then reading code would still be difficult.

Personally I am okay with C code. However, the book could have been more beginner-friendly if it were written in Python, which has almost all the counterparts of the socket functions of C in its socket library. The "concept" book by the same author uses Python this time, so we can expect some fun there.

Conclusion

Overall, the book is filled with practical code examples that are useful when understanding a network application using socket system calls. Of course, you won’t really need to use these functions when writing your own application, because many languages support their own wrappers for those "low-level" socket networking functions(Python has libraries like socketserver and http). Nonetheless, I think once in your career as a developer you should understand what is going on behind all these highly abstracted communications using HTTPS or websocket. In that sense, this book is a good read and also a good reference.

[Programming, Opinion] Should you read the GoF(design pattern) book?

UponTheSky — Tue, 28 May 2024 23:29:46 +0000

image source: https://www.irasutoya.com/2021/01/blog-post_11.html
(A sleeping woman in front of a PC)

TL; DR

I won’t recommend reading it without much experience in programming - Have experience of real-world problems first
Use it as a reference, especially when building a complex system on your own

Introduction

In software engineering world, there are several books that allegedly called MUST-READ. There are millions of such, but one of the noticeable books is the "Design Patterns" book a.k.a. the GoF(Gang of Four) book. Regardless of its age, this book is being mentioned frequently on the Internet even in 2024 as of this writing. To introduce it shortly, it is considered as a "bible" for designing objected-oriented applications, with examples in C++ and SmallTalk. Some even say you MUST READ it before becoming a senior level engineer.

Attracted by so many compliments on this book, I read through this book as well, checking every pattern introduced. But after finishing the book and working on a real-world product, I now doubt about whether this book is really something you MUST READ. Has this book helped me writing better code, or led to making better design and decision in software development in general?

DISCLAIMER: I am not a senior engineer with 10+ YOE, so my opinion is highly skewed towards the standpoint of junior software engineers of YOE less than 5 years. I highly value different opinions on this book as well.

Why I won’t recommend the GoF book for beginners

One thing I want to speak up is that this book is not for beginners in programming and software engineering. There are several reasons I can think up but here are two main things:

1. You might focus too much on the patterns themselves

You may have heard these seemingly "professional" jargons from a lot of documentations, such as Singleton, Facade, Factory, Strategy, etc. These are the patterns introduced in the GoF book. If you don’t have that much experience in software engineering, you may feel that you have to read the book to understand these concepts thoroughly.

However, personally I think this is a bad approach to software engineering in general. Being exposed to the patterns first may obscure the practical intention of the patterns themselves - organize the solution in structured ways to solve designing software problems. Unless you face and touch the problems first, you won’t fully grasp why you use those patterns in the first place.

Conversely, you may concentrate on memorizing the patterns and their code examples. But do you actually understand why the singleton pattern is used here and not there, and why the prototype pattern is not discussed in languages like Python? These insights are only learnable from real experiences, not from the book.

Basically, we only need knowledge that we use. There should be several patterns that are implicitly used in your daily work, but even so, you don’t have to memorize the patterns themselves. If your hands know them, then you know them.

2. The code examples are abstract and you can’t run them

The other reason is because of the code examples introduced in the book. The code itself is not bad, although it is rather old(even before C++11). The problem of the code examples is that it is abstract and not used in a real application example.

Of course, the book introduces a real application example before the catalogs, in chapter 1 and 2. However, in my opinion it is too short to grasp each of the patterns. Also, in 2024, we need examples that we are more familiar with, such as web, mobile, and machine learning applications.

When it comes to the examples in the individual patterns, they are not a part of an actually running application, but a collection of mock classes and functions in C++. Thus, even if you read the code, you won’t really understand how it would be implemented in a real application. And the problem is, you only learn from concrete code that actually runs and gives expected results.

How I would approach this book in the second read

But I am not saying you should not read this book. Rather, I think it would be good to read after having experienced in several software projects so that you can relate your own experience to the patterns from the book. If I would read this book again in the future, I would take the following approaches:

1. Looking up the list of the patterns only when the names of the patterns come up from documentations

Some software authors love to quote the patterns introduced in this book. Therefore, unfortunately, you have to know what the patterns do that the author of a documentation mentions(for example, Rust's THE BOOK directly discuss the state pattern in a single chapter). However, it doesn’t mean that you have to know every single design pattern in GoF. Only after you bump into the jargons, then you look up the book.

Read the general introduction of the pattern from the book, then read the documentation. Compare the code examples in the book with the one in the documentation. Write your own code according to the documentation and understand why the author mentions those specific patterns.

For example, LlamaIndex framework uses the singleton pattern for configuration. Why did the authors use this pattern for configuration, and why not something else? You many find useful insights from the GoF book about this design decision.

2. Consulting the designs when designing a complex system on your own

Sometimes, we may create an application that is totally brand new - not using highly opinionated frameworks written by others but your own one. It is absolutely necessary for you to design the application from scratch, and you need to consider various options.

In this case, I think it would be good to brush up on your knowledge on design patterns. The GoF book already contains a lot of patterns with clear explanations in diagrams, so it is a good way to replenish your options. Especially, the design patterns in the book are for managing a complex system efficiently, thus you would benefit from skimming through the list of the patterns.

Conclusion

Against the hype that “You should read the GoF book”, I strongly claimed here in this article that you should face the real-world problems first and use the book as a helpful reference. There is no such book as MUST READ - you USE books for your own good and efficiency.

[Book Review] Linux Basics for Hackers by OccupyTheWeb

UponTheSky — Sat, 06 Apr 2024 10:25:46 +0000

*image source: African Penguin, Cape Town from Wikipedia Commons

TL; DR

The book is for introducing basic features and commands of Linux(Kali) in general.
It is a good overview/review for those who are already familiar with programming and CLI, but not having had a chance to directly deal with Linux.
It would be a good book for those who are actually interested in cybersecurity field.
Personally, I think the number of topics covered is a bit too high that the depth of each topic is inevitably shallow due to the limit on the number of pages.
It would be difficult to follow the book material without access to a linux machine.

Intro - why did I choose this book?

Always feeling ashamed of not having enough knowledge and experience in Linux, I have been searching for a comprehensive and yet hands-on introduction to Linux. Although there are a myriad of such materials out there, I found this book Linux Basics for Hackers by OccupyTheWeb particularly interesting. I have looked up a few Linux books that are popular but many of them are like a reference, which means you won’t learn Linux by doing something. But with its specific catch-phrase Hacking, I thought this book would be both enjoyable and informative to read.

Good Parts

1. Comprehensive introduction to many core concepts of Linux

In the first few chapters, you might feel that this book tries to explain very basic commands like ls and ps aux. This might be something to be taken for granted for an experienced programmer.

But still, I find this approach helpful for those who have begun learning or reviewing the Linux system. One of the strengths of this book is that it explains only necessary concepts that are relevant to the theme of the book - Hacking.

However, since hacking a system is equivalent to knowing how the system works in general, the book in effect deals with most of the basic and core parts of the Linux. From running the apt-get command to running a Python script, the book covers as many topics as possible for hackers.

2. Focusing on a practical purpose - cybersecurity and hacking

Compared to other books introducing Linux, I find this book fun to read, because it constantly explains how the concepts are related to hacking and cybersecurity. As a result, the book is less like prose and more consistent in conveying its message to the readers.

Moreover, it introduces a couple of low-level parts of Linux such as networks, Wifi, device driver, etc. As a person who has only developing high-level web applications throughout my career, I found this "new world" fairly refreshing. The book provides absolutely a good introduction to entry points that a young hacker can explore and enjoy.

Soso Parts

1. Limited number of pages for a number of topics

This book manages to introduce core concepts and examples of Linux. However, since this book is not large enough in its physical size, there are only a few sections that explain concepts deep enough. Many of the topics I read are covered shallowly, usually by explaining how a certain command is run and what result of it is like. In order to learn deeper about a command or a concept, I had to look up the Internet often.

Thus, even though there are a lot of concepts that I have learned from the book, many of them remain as very basic. For instance, I still don’t really know how exactly a Linux kernel is started and how to force quit "zombie" processes if an application has not been closed properly. I think it would have been better if the author simplified very basic commands like ls and explained more of concepts like access list or socket programming.

2. Not easy for non-Linux users to follow

Of course, this book is about Linux so it seems not fair to blame the book for the accessibility. However, a lot of programmers like me use MacOS, and many of the commands introduced in the book don’t exist on MacOS. I personally used Docker for running the example code, but still it was time consuming to search for packages to install.

Because running the Virtualbox application is daunting for low-performing computers, it would have been better if the author also provided alternative methods for following the materials of the book on MacOS.

Conclusion

Nevertheless, I think this book is good for brushing up on the knowledge on Linux in general. At least I now know what part of Linux I need to look into if there is a problem. The book itself is very concisely and clearly written, so you wouldn’t find it difficult to follow the author while practicing the commands for hacking.

[Go, Book Review] Learn Go with Tests by Chris James

UponTheSky — Sat, 23 Mar 2024 09:26:19 +0000

*image credit to Renee French, the source is the one of the official Go blog posts

TL; DR

The book covers from the very basic concepts of the language to writing complex applications.
You learn Go interactively by writing tests.
This book is more than learning Go itself - you learn practical TDD methodology from the author.
Highly recommended for those who have just started learning Go, or the Software engineering in general.

Intro - why did I choose this book?

Since my painful memory of starting my Rust journey, I setup my own principle of learning a new programming language: begin with very simple tutorial, and write as many examples as possible before moving on to advanced cases.

Therefore, I was very fortunate to get to know this amazing book, Learn Go with Tests. Right after skimming through the tour, I was looking for a material that provides plenty of examples and good practices. The LGWT book exactly suits the needs.

Good Parts

1. Learning features of Go interactively with tests

This book starts from basic concepts of the language such as types, loops, pointers, interfaces, etc. But it also covers several advanced and frequently used concepts such as context and concurrency. The book provides a very good introduction to these difficult topics in general, with actual running examples as tests rather than with abstract words.

I would like to say that learning the language with writing test code is one of the best features of this book. Usually, learning a compile language like C/C++ or Rust requires users to run compilation commands, which usually takes a long time. However, by writing test and run it, you can actually check how a few lines of Go work right away. Even on my old 2017 MacBook Pro with 8GB RAM, running tests usually took around half a second.

Additionally, almost all the chapters of this book contain tests. Thus, as you read through the book, actually writing and running those tests, you will become much familiar with writing Go.

2. Rethinking of software design and tests

In the chapters of building an application, the author constantly bring up the idea of what is a good software design and how you can achieve it with the TDD principle. Except the chapters about Go language features, the book is more like a TDD and software design book with examples written in Go. The author gives his real-life stories from his long time of software engineering careers, and these are what normal software engineers usually face day to day. I was astonished how his stories and claims resonate with my own experience with bad software design and messy test code I had written in the past. If the TDD book by Kent Back can be thought of as a manifesto for TDD, this book is more like an anecdote from a senior engineer at the reader’s company.

Soso Parts

There are not particularly bad parts. Overall the book is well written and organized. Moreover, Since it is also an open-source material, many readers have contributed to the contents of the book(including a few of mine :)). I hope there are more books like this for other languages such as Rust or Python.

Conclusion

I highly recommend this book for Go newbies. It covers the language features extensively, and also provides practical code examples that you can run on your machine. You will also learn rigorous principles of writing maintainable and robust software with TDD by reading this book. Even if you’re an experienced Go developer, I am pretty sure you could learn important lessons from this book as well.

[Go] Understanding net/http - How to run a server like a Pro?

UponTheSky — Fri, 01 Mar 2024 17:23:07 +0000

*image credit to Renee French, the source is the one of the official Go blog posts

TL; DR

Use ServeMux as the multiplexer
Use Serve struct for detailed configurations
It’s okay with using Serve::ListenAndServe, but Listen and Serve can be called separately(Listen is in the net package)

Introduction - Stop relying on default functions

At a glance, It looks simple to write an HTTP server in Go, using the standard net/http package. Many of the tutorials and blog posts usually don’t go beyond using default functions like http.HandleFunc or http.ListenAndServe. And there don’t seems to be many issues with it. Who cares as long as it works well?

Well, if you’re a professional software engineer, you would highly disagree with this. We need to take control over every aspect of what we’re wielding as our mighty weapon, if possible. Relying on default functions provided by the package may obscure the details under the hood. As I spend more time learning Go, I wanted to know what’s behind this “default layer”, and be able to write an HTTP server in a more sophisticated way.

In this short article, I want to discuss the ways of starting a server in net/http package, from simple ones to more advanced ones. Before diving into the main part of the article, let me point out the following three points:

This article is motivated by a blog post by an engineer at Grafana, which has been quite popular in the Go community recently.
I won’t consider any of the third-party libraries like Gin or Echo. It is not because they are not good, but because I want to dig into what is considered as “standard” in Go language and by its developers.
Also, it could mean so many things when I say “How to write a server in Go”, because there are a myriads of things to consider - middleware, router, security, network protocols, concurrency issues, to name a few. Therefore, this article only aims to explore how to write and run a "server instance" rather a "web server application".

Various ways to run a server using net/http package

1. Start simple - `DefaultServeMux`

Many learning materials for beginners in Go(such as Go by Example or Go Web Examples shows how to run an HTTP server in a simple example like:

package main

import (
    "fmt"
    "log"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        w.WriteHeader(200)
        fmt.Fprint(w, "Hello, Go HTTP Server!")
    })

    log.Fatal(http.ListenAndServe(":8000", nil))
}

In a nutshell, this method simply registers a plain function of two parameters (w http.ResponseWriter, r *http.Request) such that the function is called whenever a client requests the targeted endpoint. In this way, there is no need to fully understand the interface Handler; you just need to write logic to process incoming requests.

However, there is an interesting point to look at here. What is the relationship between http.HandleFunc and http.ListenAndServe, as these two functions have nothing in common. But, as a matter of fact, they DO share a global variable called DefaultServeMux.

If you read the documentation, it says

for HandlerFunc:

HandleFunc registers the handler function for the given pattern in DefaultServeMux

and for ListenAndServe:

The handler is typically nil, in which case DefaultServeMux is used.

Thus, a function registered by HandleFunc is stored in the global variable DefaultServeMux of the package, which is then used by ListenAndServe. So the key now is to understand ServeMux in general.

(REMARK) What is `ServeMux`?

Let’s look at the documentation once again:

ServeMux is an HTTP request multiplexer. It matches the URL of each incoming request against a list of registered patterns and calls the handler for the pattern that most closely matches the URL.

As a multiplexer, a ServeMux instance receives multiple HTTP requests and hands each of them over to an appropriate handler. Thus, ListenAndServe starts a server that listens to requests headed to the specified address(in this case, it is "http://localhost:8000"), and then delegates them to its (Default)ServeMux in order to handle(note that ServeMux implements the interface http.Handler).

2. More sophisticated usage - make your own `ServeMux`

But why is it not a good practice to use DefaultServeMux? Mainly because it is a global object. According to Practical Go by Amit Saha, many unnoticed packages could also access the object, such that related security or concurrency problems could occur. Therefore, it is better to create our own ServeMux instances using http.NewServeMux.

func main() {
    mux := http.NewServeMux()

    mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        w.WriteHeader(200)
        fmt.Fprint(w, "Hello, Go HTTP Server!")
    })

    log.Fatal(http.ListenAndServe(":8000", mux))
}

Of course, since ListenAndServe accepts the http.Handler interface in general, we can wrap mux with middlewares(the technique is introduced in one of my previous article)

func someMiddleware(h http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // custom logic
        h.ServeHTTP(w, r)
        // custom logic
    }

func main() {
    // …
    mux := http.NewServeMux()
    mux = someMiddleware(mux)
    // …
}

3. Writing your own `Server`

But ServeMux is only a multiplexer that distributes incoming requests, and the server is bootstrapped at http.ListenAndServe. Obviously, it doesn’t accept any configuration for the server application it sets up. Therefore, if we need to tweak a few configurations for a server, we use http.Server struct in the package.

As you see the documentation, the configurable variables are related to fairly low-level concepts. But if we’re considering a production environment, complicated configuration is inevitable.

Now we have more freedom in writing a web server in Go, only using the net/http package:

func main() {
    addr := os.Getenv("SERVER_ADDRESS")

    if addr == "" {
        addr = ":8080"
       }

    // step 1: make your own `ServeMux`
        mux := http.NewServeMux()

        // add handlers & middlewares
    // …

    // step 2: make your own `Server`
    srv := &http.Server{Addr: addr, Handler: mux, ReadHeaderTimeout: time.Minute}

    log.Fatal(srv.ListenAndServe())
}

Also, we may go deeper into setting up the TLS support using ListenAndServeTLS instead of plain ListenAndServe, with necessary certificate files. For simplicity, we will keep using ListenAndServe for the rest of the article.

4. Advanced - Splitting `ListenAndServe` into `Listen` and `Serve`

Many of the learning materials and blog posts on writing Go server with net/http simply use the ListenAndServe method. In most of the cases it is fine
since it uses TCP connections under the hood.

So we break down the function to Listen and Serve, instead of the last line log.Fatal(s.ListenAndServe()) in the above code chunk like this:

// step 3: Listen to TCP connections
ln, err := net.Listen("tcp", addr)

if err != nil {
  log.Fatal(err)
} 

defer ln.Close()

log.Fatal(srv.Serve(ln))

As you might have already expected, Listen function is a wrapper of the system call listen at the OS kernel level. And Serve reads request data from the socket buffer and hands over the information(with pre-generated response instance) to its handler. We can go deeper here but it is beyond the scope of this post. However, savor the beauty of the naming "Listen"(the incoming connection from a socket) and "Serve"(the request from the listened connection with enrolled handler) here - how well they are made!

Conclusion

In effect, we have break down "convenient" default functions in the net/http package into several components that we can configure directly. As we go deeper, it goes down to the fundamental part of the network programming - TCP socket programming, as we discussed at Advanced - Splitting ListenAndServe into Listen and Serve. I am not sure whether we need to configure at this level. Nevertheless, I believe it is important to understand how the mechanism works when we write a server program.

Still, it is of course not writing a server instance "as a Pro". There are more details uncovered yet in this post. But "like a Pro", we mimic the way a professional software engineer writes code.

references

Go by Example: https://gobyexample.com/http-server
Go Web Examples: https://gowebexamples.com/http-server
net/http package: https://pkg.go.dev/net/http
Learn Go with Tests: https://quii.gitbook.io/learn-go-with-tests/build-an-application/http-server
"How I write HTTP services in Go after 13 years" by Mat Ryer: https://grafana.com/blog/2024/02/09/how-i-write-http-services-in-go-after-13-years/
Network Programming with Go by Adam Woodcock, Ch9: https://www.amazon.com/Network-Programming-Go-Adam-Woodbeck/dp/1718500882
Practical Go by Amit Saha, Ch5~7: https://www.amazon.com/Practical-Go-Building-Non-Network-Applications/dp/1119773814

DEV Community: UponTheSky

[Opinion]Today's frontend is easy to be messed up and we need to organize it

React is dang complex

Frontend = State + hierarchical presentation

Revisiting Container-Presentational pattern

Revisiting Atomic Design

Layout - Page Model

Before the end the post

[Book Review]AI Engineering by Chip Huyen

[Book Review] Build a Large Language Model (From Scratch) by Sebastian Raschka

TL; DR

Overall Review

My 2 Cents for Those Who Haven't Read the Book Yet

[Go, Opinion] How can we write truly "middle"ware with Go's net/http?

TL; DR

So, we all know how to write middleware with Go's net/http?

Middleware of net/http is only half middleware

Wrapping another http.Handler is not a solution

How about writing custom "handlers"?

Conclusion

[C#]I tried Primeagen’s way for learning C#

What is "Primeagen’s way?"

How I followed "Primeagen's way"

1. A tour of the language

2. Ten exercises of Advent of Code

3. Implementing a chat server

Is Primeagen’s way recommendable for learning a new language?

Is the language similar to the one you are already familiar with?

Are there good resources for the language or frameworks?

Do you already have a clear idea about a fun project?

Conclusion

[Opinion] I’ve passed an AWS cert… but is this something for me?

Passing an exam must feel great, but…

Purpose of getting a cert

How SAA cert preparation was actually like

1. The SAA covers not just a few well-known services but a wide range of AWS services

2. The exam questions presents real-world scenarios

Experience outweighs theory.

What I would do if I go back in time?

Conclusion

[Python] How do we lazyload a Python module? - analyzing LazyLoader from MLflow

Intro

Playing around with LazyLoader

How LazyLoader works in MLflow? - source code analysis

1. Creating an instance of LazyLoader, proxying the original module

2. Accessing an attribute - __getattribute__, __getattr__, and getattr

3. Loading and caching the actual module

3-1. Module caching at the level of LazyLoader class

3-2. Importing the actual module with importlib.import_module

3-3. Caching the module with given local_name

3-4. Caching the attributes of the actual module in __dict__

4. __dir__ and __repr__

Conclusion

[Book Review] Beej's Guide to Network Programming

Intro - what is this book about?

Good parts

Friendly introduction to technical concepts

Plenty of code examples

Soso parts

Mainly focused on socket programming only

Not recommended for those who are not familiar with C code

Conclusion

[Programming, Opinion] Should you read the GoF(design pattern) book?

TL; DR

Introduction

Why I won’t recommend the GoF book for beginners

1. You might focus too much on the patterns themselves

2. The code examples are abstract and you can’t run them

How I would approach this book in the second read

1. Looking up the list of the patterns only when the names of the patterns come up from documentations

2. Consulting the designs when designing a complex system on your own

Conclusion

[Book Review] Linux Basics for Hackers by OccupyTheWeb

TL; DR

Intro - why did I choose this book?

Good Parts

1. Comprehensive introduction to many core concepts of Linux

2. Focusing on a practical purpose - cybersecurity and hacking

Soso Parts

1. Limited number of pages for a number of topics

So, we all know how to write middleware with Go's `net/http`?

Middleware of `net/http` is only half middleware

Wrapping another `http.Handler` is not a solution

Playing around with `LazyLoader`

1. Creating an instance of `LazyLoader`, proxying the original module

2. Accessing an attribute - `getattribute`, `getattr`, and `getattr`

3-1. Module caching at the level of `LazyLoader` class

3-2. Importing the actual module with `importlib.import_module`

3-3. Caching the module with given `local_name`

3-4. Caching the attributes of the actual module in `dict`

4. `dir` and `repr`

1. Start simple - `DefaultServeMux`

(REMARK) What is `ServeMux`?

2. More sophisticated usage - make your own `ServeMux`

3. Writing your own `Server`

4. Advanced - Splitting `ListenAndServe` into `Listen` and `Serve`