DEV Community: Ourai L.

I Submitted Two Pull Requests to the Answer Platform

Ourai L. — Fri, 31 Jan 2025 15:45:14 +0000

It seems that the OpenBuild community ecosystem project has been on hold for quite some time. The initiator wants to quickly advance it, but there hasn't been much progress so far, and it's hard to find other suitable people for the job—so I had to take it over.

The project aims to develop a plugin for the open-source Q&A platform Answer that supports login via Web3 wallets. From the perspective of the functionality to be implemented, this should be a relatively small project, with an estimated total of 1.5 to 3 person-days for both front-end and back-end development and integration.

However, reality has given me a hard time...

Requirement Analysis

Initially, based on the official plugin development documentation, what we need to build is a connector-backend plugin.

With this in mind, I reviewed the code of several existing connectors and found that each plugin can only specify one type, and back-end plugins do not directly support UIs—they all redirect to external authorization URLs.

However, there is no ready-made external authorization URL for Web3 wallet login. To meet the requirement, we might need to develop an additional router-standard UI plugin to create a page that:

Displays a "Connect Wallet" button;
After the wallet is connected, prompts the user to sign:
1. Retrieve a nonce from the back-end, with the front end providing the wallet address;
2. The front end invokes the wallet to get the user's signature;
Call the back-end authorization interface after the signature is obtained, with the front end passing the user's signature information and wallet address;
Return to the main interface upon successful request.

The parts in bold above require data interaction with the back-end, meaning we need two back-end APIs.

The process seems simple, right? And it really is!

Development Process

The back-end part was largely completed months ago, with only the front-end interface and integration remaining.

Since the project is not developed with a front-end and back-end separation, to run it fully, according to the official documentation, I would need to install Docker, a database, and other tools.

However, I had not installed these on my local machine before, and I have no plans to use them for other projects in the near future. I couldn't justify installing software that I would hardly use, just to save some disk space on my computer.

Therefore, I decided to first develop the front-end interface layout, styles, and functionality in a pure front-end manner, even though the back-end API requests would fail. Including the time spent reading the documentation and familiarizing myself with the basic plugin mechanism, it took me about 1 person-day to complete.

I scheduled a full-day integration session with the back-end developer over the weekend, hoping to finalize and deliver the project, but we encountered many setbacks...

Since I didn't have the back-end environment installed and configured on my local machine, I couldn't follow the normal plugin loading and running process. Some issues that I didn't encounter during the development phase emerged when the back-end developer tried to run the entire process with my code.

Initially, whenever we encountered a front-end issue, we would start a video call to see how he was operating, and I would guide him on how to solve it. After a few times, I suddenly realized—this is what people call "pair programming"! 😂😂😂

Later, I thought to myself: "This is not sustainable; it's too inefficient!"

Eventually, I decided to let go of my hesitation and let him guide me on how to set up the back-end environment so that I could test and adjust the front-end code myself.

After being guided, I found out that I actually only needed to install Go, and I could use the SQLite database that comes with macOS—no need for Docker at all. I really should have let him be my "navigator" from the beginning!

Although things didn't go smoothly afterwards, we no longer needed to hold video calls. We could just send a screenshot and a brief description via WeChat whenever we encountered a problem, which greatly improved our efficiency!

While testing the plugin I developed, I also discovered a bug in the plugin loading mechanism and fixed it with a PR, earning an extra achievement! 😁😁😁

After a day or two of final touches, we delivered the plugin. Under the guidance and suggestions of the official reviewer, we merged the original two plugins into one here—it appears to be a "router-standard UI plugin", but it is also a "connector-backend plugin" in reality.

In just three to five days, we managed to resolve the "constipation" issue, and it's time to celebrate! 🎉🎉🎉

Pitfalls and Experiences

This project was developed based on the main project version 1.4.0. The incomplete official documentation, the plugin system, and my own somewhat awkward mindset led me to encounter some pitfalls. Below, I share some key points for local debugging for front-end developers to avoid unnecessary detours!

Firstly, for those who, like me, are concerned about this—you only need to install Go additionally, and you can use the SQLite database that comes with macOS!

Taking the plugin we developed as an example, let's assume the plugin is named connector-wallet.

Back-end Environment

Ensure that the plugin package is imported in the main project's cmd/answer/main.go, even if it does not exist yet:

import (
  answercmd "github.com/apache/incubator-answer/cmd"

  _ "github.com/apache/incubator-answer-plugins/connector-wallet"
)

Whether it is a pure front-end plugin or a plugin that appears to be a front-end plugin, when debugging, the code generated by the template should be placed in the ui/src/plugins folder, and a go.work file should be created in the root folder:

go 1.22.0

toolchain go1.23.2

use (
    .
    ./ui/src/plugins/connector-wallet
)

Run make ui to build the front-end code, and then compile the back-end code with go build -o answer ./cmd/answer/main.go, which will generate the answer file. All subsequent operations will use this file.

Run ./answer init -C ./answer-data/ to initialize the system. You need to visit http://localhost in the browser to fill in the information, where the database should be selected as SQLite, and the file storage path should replace /data with the absolute path of the answer-data folder.

Run ./answer run -C ./answer-data/ to start the back-end service. Visit http://localhost again to log in with the initial account and enable the plugin you want to debug in the back-end!

Finally, change the REACT_APP_API_URL in ui/.env.development to http://localhost:80/, and you can start the front-end development server to access the back-end API.

Front-end Environment

After installing the dependencies, you need to delete several folders in the plugin folder to avoid issues:

Delete the dist folder and the main, module, types, and exports fields in the package.json, otherwise the page will render the compiled files, and changes to the source files will not trigger a refresh;
Delete the node_modules folder, otherwise the i18n configuration read by the plugin may not be from the main project, possibly due to react-i18next not using a singleton pattern, resulting in two separate configurations.

Publishing the Plugin

If the front-end plugin adds additional dependencies, you need to modify the vite.config.ts configuration in the plugin package:

import cssInjectedByJsPlugin from 'vite-plugin-css-injected-by-js';

export default defineConfig({
  plugins: [
    ...,
    cssInjectedByJsPlugin(),    // Required when importing style files, otherwise styles will be disordered
    ...,
  ],
  build: {
    ...,
    rollupOptions: {
      external: [
        ...,    // Declare your additional dependencies here
      ],
      output: {
        globals: {
          ...,    // Declare your additional dependencies here
        },
      },
    },
  },
});

Conclusion

Thank you to OpenBuild for providing this opportunity. Although I was reluctant to take it on at first because I thought there were more important and urgent matters to attend to, time can always be squeezed out if you really want to!

Thank you to the back-end developer for the great cooperation, which helped us resolve this "constipation" issue that had been lingering for months!

Thank you to the Answer official reviewers for accompanying me through the PR process and helping me practice my English, which has set a good foundation for my future international development!

Although I have contributed PRs to several other open-source projects before, they were mostly minor fixes and didn't involve much communication before being merged. This contribution to Answer truly gave me the feeling of being part of an open-source community!

Salute to all OPEN SOURCERORs!!!

Front-end Shovel 💩 Diary #3: Refactoring the "Personal Profile"

Ourai L. — Fri, 31 Jan 2025 04:41:51 +0000

Hey, Folks! From this note onwards, we’re diving into the actual code refactoring exercises!

The first piece of code that needs refactoring is in the user’s personal profile page, which I encountered when I took over the official website project.

In this system, users are divided into two types: individuals and project sponsors. Although their personal profiles look similar, there are differences in visual details and data structures. The layout structure of the profile page is roughly as shown in the figure below:

The original code for the personal profile page was somewhat modular in other parts, but the most important sections, such as courses and activities, were all crammed into a single React component. It looked like this:

The code was messy and disorganized, making it difficult to discern the purpose of each section. Therefore, the refactoring approach was clear—split and encapsulate.

Based on the display of the personal profile page and the overall functionality of the website, I first divided the domain into four modules:

bounty for bounty tasks;
challenge for online and offline activities;
course for online courses;
quiz for quizzes.

I then encapsulated the code for each list rendering in the personal profile page into list view components and placed them in the corresponding modules. The data requests were also encapsulated into asynchronous functions and placed in the repository.js of each module:

Since the interaction logic for each list was consistent—clicking “More” to load the next page—I further encapsulated a generic LoadableList component and placed it in the shared/components folder. This made the list view code much cleaner and more concise:

import LoadableList from '@/components/loadable-list'

import { fetchEnrolledCourseList } from '../../repository'
import EnrolledCourseItem from './EnrolledCourseItem'

function EnrolledCourseList({ list }) {
  return (
    <div>
      {list.map(({ series }, idx) => (
        <EnrolledCourseItem key={`course-${idx}`} data={series} />
      ))}
    </div>
  )
}

function EnrolledCourseListView({ params }) {
  return (
    <LoadableList
      params={params}
      fetch={fetchEnrolledCourseList}
      resolveResponse={res => ({ list: res.data.list, total: res.data.count })}
      renderList={list => <EnrolledCourseList list={list} />}
    />
  )
}

export default EnrolledCourseListView

Next, I encapsulated the logic for switching between list views into ActivityTabList and declaratively passed the array of list views to it. The refactored personal profile page code looks like this:

import EnrolledCourseListView from '../../../course/views/enrolled-course-list'
import EnrolledChallengeListView from '../../../challenge/views/enrolled-challenge-list'
import AppliedBountyListView from '../../../bounty/views/applied-bounty-list'
import AnsweredQuizListView from '../../../quiz/views/answered-quiz-list'

import ActivityTabList from '../../widgets/activity-tab-list'

// List view declarations
const tabs = [
  { text: 'Course', view: EnrolledCourseListView },
  { text: 'Challenge', view: EnrolledChallengeListView },
  { text: 'Bounty', view: AppliedBountyListView },
  { text: 'Quiz', view: AnsweredQuizListView },
]

function IndividualProfileView({ user }) {
  return (
    <div className="pl-[410px] pb-14 pr-14">
      <ActivityTabList userId={user.user_id} tabs={tabs} />
    </div>
  )
}

export default IndividualProfileView

The relative paths are used because a new profile module was added under domain to handle personal profile-related functions, and files within the same domain are constrained to use relative paths.

Finally, the original code in the app directory was changed to:

'use client'

export { default } from '#/domain/profile/views/individual-profile'

In this way, the core code related to the personal profile was successfully moved from app to domain, completing the first code refactoring exercise!

Front-end Shovel 💩 Diary #2: The Easily Overlooked "domain"

Ourai L. — Thu, 30 Jan 2025 20:31:04 +0000

If you've read the previous note, the keen-eyed among you might have noticed that the domain folder mentioned in the directory restructuring plan did not appear in the final refactoring results.

This is because domain modeling is a relatively challenging task that requires long-term effort and careful consideration. So, we don't rush it. Starting from this note, we will delve into related content.

Before diving into the actual refactoring exercise, this note will first explain the importance of the domain folder. Please grab your seats and pay attention as I explain.

In the modular directory structure I designed, there are three core top-level folders: shared, domain, and entry, each serving the following purposes:

shared: Contains universally used assets, styles, and functions that have no business logic and are applicable throughout the entire application.
domain: Houses assets, styles, and functions related to specific business logic, without being restricted by the development framework or page routing.
entry: Serves as the application's initialization and page rendering "entry point", which is constrained by the development framework and page routing mechanisms.

The domain folder is the cornerstone of this structure—most of the application's logic resides here, making it crucial. In contrast, the other two folders are relatively lightweight, especially the entry folder.

Since the official website project I inherited uses Next.js, its prescribed app folder serves as the entry folder.

Many front-end developers have a superficial understanding of "modularization", thinking that simply moving a piece of code into another file and referencing it elsewhere (e.g., encapsulating utility functions or UI components) constitutes modularization. While this approach has some benefits, it doesn't significantly enhance application development. Modularizing business logic is where the real power lies—this is where domain modeling comes in, a skill that many front-end developers lack.

The subfolders within the domain folder represent abstracted business modules, each strictly adhering to the principles of "high cohesion and low coupling". Each module contains only code related to its own business logic, with clear semantic declarations of dependencies on other business modules.

The directory structure of a business module typically looks like this:

If, like in most projects, files are indiscriminately thrown into global folders such as services or components without any abstraction, the most immediate problem encountered is the need to sift through numerous subfolders to identify the files that need modification. This process must be repeated every time you switch between different categories of folders, making it difficult to focus and severely impacting efficiency.

This is because organizing files by category forcibly disassembles files that are closely related from a business perspective—it's like breaking up a pair of lovebirds!

Without abstracting and reusing modules based on business logic, the dependencies between UI components and pages can easily become extremely convoluted, eventually turning into an intractable mess that further affects development efficiency and application quality.

The domain folder in my modularization model is the perfect remedy for this issue, acting like different-colored cable ties that neatly organize and constrain the "wires", bringing order to the entire application.

Moreover, ideally, each business module within the domain folder can be reused in different applications—just like general-purpose modules installed via npm!

What do you think? Have you grasped the benefits of the modularization model and the importance of the domain folder?

Front-end Shovel 💩 Diary #1: Project Directory Structure Adjustment

Ourai L. — Thu, 30 Jan 2025 13:07:03 +0000

Recently, I took over a front-end project for an official website. Although it's called a website, it's actually a web application rather than a marketing site, so it does have a certain level of complexity.

These past few days have been a whirlwind of debugging and getting familiar with the code logic. I didn't expect it to be such a hot potato. The previous developer left me a mess—frankly, I don't think they were much more than intermediate level. 😖

You might think I'd be overwhelmed and frustrated by this pile of mess, with my mind racing like a herd of horses across the Hulunbuir Grasslands. But no! You're mistaken! In fact, I'm quite excited!

Don't get me wrong—I'm not some kind of masochist. It's just that projects like this are like touchstone tests, proving my worth as a true gem, a hidden treasure, and the ultimate myth—after all, I'm a seasoned "front-end poop shoveler"! 😄

Alright, enough with the backstory. Let's get down to business.

This official website project is built with Next.js, and its directory structure is pretty standard, offering little constraint for development and maintenance.

The core issue with the project is the lack of abstraction. The code is like a jumbled mess of cables in an unorganized server room, with poor reusability and maintainability.

What about robustness? What's that?

I once wrote an article titled "Patterns of Directory Structure in Front-end Projects". The directory structure of this project, like most front-end projects, falls into the "wild" category mentioned in the article—it's part of the problem!

As I mentioned at the beginning, this project is a web application, which means it can largely benefit from domain modeling. This also implies that if I want to clean up this mess, the first step is to reorganize the directory structure using a "modular" approach, similar to the annual organizational restructuring at a company.

Due to the limitations of Next.js, the app folder must replace the entry folder.

Ideally, apart from the app folder, the shared and domain folders should be free from Next.js constraints and will carry the bulk of the application's logic—always ready to break free from Next.js's grasp! 😜😜😜

The ideal is full, but the reality is quite 💀.

Since this project is plagued with issues, it can't be fixed all at once. After today's refactoring, I had to leave some remnants for now, but I'll eliminate them one by one in the coming days!

Now it looks much cleaner and more organized. I'm feeling great! 😄😁😆

Abandon Web2 and Join Web3

Ourai L. — Thu, 30 Jan 2025 05:37:34 +0000

The titles of my previous articles, "Web3 is the Future for Front-end Engineers Part 1" and "Web3 is the Future for Front-end Engineers Part 2", might seem sensationalist, and some have accused me of clickbait. However, these articles are about my personal journey of transitioning to becoming a Web3 full-stack engineer. The phrase "Web2 is the End, Web3 is the Future" reflects my personal experience and choice, not a summary of the industry or advice for others—this article is the opposite.

Web2 is the End

After reading those two articles, some people commented, "You never explained why Web2 is the end". Indeed, those articles were mainly about my personal experience and not career advice for the industry.

Additionally, I had previously expressed my views on "Web2 being outdated" more comprehensively. There was a small part in "The Last Advice to Front-end Engineers", and more details were in a paid column article titled "What Kind of Job Should I Look For?".

To ensure the coherence and completeness of this series of articles, I am now sharing the main content from the paid article, further refined below.

Supply and Demand Mismatch

Last Mid-Autumn Festival, while I was idly chatting with my friend, I opened BOSS Zhipin to check out job opportunities. I set a higher expected monthly salary range and specified my areas of expertise. To my surprise, the usual abundance of basic coding positions had mostly disappeared. Instead, I saw job titles like Web IDE Development, Senior Electron Development, Front-end Technology Director, and Front-end Team Leader—more advanced positions.

Their combined monthly salary range was approximately 35k to 70k, which sounded great! However, upon seeing the job requirements, I realized I didn't meet them.

Some people complain about the difficulty of finding jobs, citing saturated demand, while others lament the difficulty of hiring, saying that suitable candidates are rare. At that moment, I truly understood the contradictions and gaps between these two perspectives.

In the conventional job market, I found myself in an awkward position—neither suitable for basic coding roles (which would be an underutilization of my skills and thus not cost-effective for employers) nor qualified to lead a large-scale team.

This was one aspect of the problem I faced when job hunting. The other aspect was the issue of career prospects, which affects the stability of job positions, companies, and industries (i.e., their lifecycle).

Is Front-end Dead?

When I was organizing a topic on front-end engineering, I emphasized in the introduction—

"A 'front-end engineer' is a 'software engineer' who primarily uses Web front-end technologies such as HTML, CSS, and JavaScript to solve problems related to web pages or web-based applications. If someone uses Canvas, WebGL, and other technologies for drawing or game development, they have already stepped beyond the conventional scope of 'Web front-end.' Their knowledge system focuses more on computer graphics, which is not within the scope of this topic".

—Ourai, Front-end Engineer's Self-cultivation

In a Zhihu Q&A about Yu Bo's resignation, Tang Zhu mentioned—

"A new era is coming, driven by AI, with significant upgrades in technological productivity, major reconstructions in product expression, and reshaping of business models. As one of the functions of technical implementation, front-end engineering will also enter a new era. The value of the user experience technology carried by front-end will be more widely recognized and become a basic consensus among people.

Yu Bo was ahead of his time in cognition, founded, and successfully built Ant Group's Experience Technology Department. The achievements in concepts, products, teams, influence, and business value are substantial.

Yu Bo became famous in front-end and achieved a lot in terms of technical products and the Experience Technology Department. In the next industry cycle, I believe Yu Bo still has the ability, space, and sufficient talent to make something better and promote change, succeeding in business and commerce.

However, the so-called 'problems' of front-end are mostly due to limited cognition. In the new era driven by AI productivity, the new challenges of interaction and user experience delivery may just be the beginning of the 'front-end's' brilliance. This definitely does not mean that it will continue to be fully contained within the familiar 2D web pages in browsers".

—Tang Zhu, How to View Yu Bo's Resignation from Ant Experience Technology Department?

Combining these two perspectives, I was reminded of the heated debate about "front-end engineering being dead" last year.

I had expressed my views on this topic in 2020 in a Zhihu question, "Does Front-end Have a Future?", and later wrote a more detailed article titled "Does Front-end Development Have A Future?".

A year later, I added some more thoughts—

"In 5 to 10 years, there will be a significant number of tool-like job positions in Web development that become obsolete. The entry barrier will be higher, and salaries and growth rates will be lower. People who have been in the industry for more than six years should be able to sense this.

This profession is already on a downward trend. It's time to consider what you will do in 5 to 10 years and try to change direction and switch tracks as soon as possible.

I want to say that—Web development-related professions, such as front-end engineers and Java engineers, are nearing their end. It doesn't mean there will be no jobs, but they will become increasingly difficult to find and will pay less, moving further away from the term 'high-paying.'

Twenty years ago, China entered the PC Internet era; ten years ago, China and the world entered the mobile Internet era. During these two decades, with the rapid growth of various Internet companies, China's economy quickly rose and soared, catching up with and surpassing other countries.

However, at this stage, many things are in a plateau phase. In ten years, no matter how the form of the Internet changes, Web development will not cause much of a stir and will have little to do with it.

Currently, the future lies in data intelligence, mixed reality, graphical technology, computing combined with biology/life sciences, and some infrastructure areas. Relatively speaking, Web development is just some 'bricklayer' work.

Any tool-like thing (such as technology, service, etc.) has a shelf life, so maximizing the benefits and value they generate is crucial.

I've shared the basic points I've thought of, and whether you can use them is up to you—

Access to first-hand information and a keen sense of smell—being one or even N steps ahead of most people in understanding the development of the world and the challenges you may face, as well as potential money-making opportunities;

Rapid learning ability—reducing the time cost of mastering new tools and saving more time to gain value;

A discerning eye for finding applicable and landing scenarios for tools—quickly and vigorously promoting them to get promoted, get a raise, and make money;

Try to expand as much as possible—increasing and extending profits;

Start the next cycle."

—Ourai's Thoughts

The section "A Bit of Reflection" in the article "The Second Year of My Three-Year Journey" further refined the above views and echoed this year's "The Last Advice to Front-end Engineers".

Later, I reviewed the articles and ideas mentioned above, as well as Zenany's article "The Future of Front-end" written in 2019, trying to find entry points for job hunting.

The Cycle of Technology

Whether it is Zenany's "The Future of Front-end", my "Does Front-end Development Have A Future?", or Tang Zhu's answer on Zhihu, they all indicate that "front-end has a future", but this "front-end" is not the same as the traditional "front-end"—

If you cling to the "traditional Web front-end" represented by HTML, CSS, and JS, it will not have a future in the long run. However, the "front-end" that aims to "solve human-computer interaction problems" and "provide a good user experience" does have a future.

The difference between these two "front-ends" lies in the fact that the former is bound to HTML, CSS, and JS, which are frequently used in development; while the
latter's connotation is dynamic and can be the old trio, WebGL, or even something completely unrelated to Web.

For example, the "front-end" involved in digital twins, immersive technologies, and smart spaces has almost nothing to do with the "traditional Web front-end".

If we follow the 15-year cycle of front-end development mentioned in Tang Zhu's answer (2008–2023), it is clear that the "traditional Web front-end" is currently in a period of decline and doesn't have many years left to "live".

What will the "next generation" of "front-end" be specifically in terms of technology? How long will its lifecycle be? Will it be as enduring as the "traditional Web front-end"?

Additionally, generational transitions do not occur separately but simultaneously, with few people noticing; by the time most people become aware and take action, it may already be too late to get in on the ground floor.

The Cycle of Domains

These articles also suggest that "front-end" can develop in both the production and commercial fields—improving efficiency and reducing costs in the former, and expanding territory and generating revenue in the latter.

As software engineering theories become more refined, the problems encountered when using new technologies and tools can easily be solved by drawing on existing knowledge and experience (across boundaries).

Thus, the "spiral" in the "spiral upward" will spin faster and faster, to the point where it doesn't matter whether it's a spiral or not—similar problems keep recurring, and as long as the models and patterns for solving problems remain unchanged, improvements in technology and tools will be meaningless.

In other words, the ceiling for efficiency and optimization is becoming easier to reach.

The commercial field is similar—commerce is based on human nature, which has not changed much in thousands of years. It's just that with the emergence of new technologies, everything existing has been redone once again—another "spiral upward".

Of course, there are a few "exceptions", such as the advent of electrical appliances and computers, which are "singularity" events.

From past experience, it's hard to say which cycle is longer between production and commerce, but the decline of the production field may accompany the decline of a specific technology—"if the 'traditional Web front-end' is no longer used, why bother with its infrastructure?"

The Limitations of Articles

These articles are written from a macro perspective and offer advice for a broad audience. For a specific individual, the reference value may be limited—just as with the societal issue of "old jobs disappearing and new ones emerging".

Take me, for example. I am older and at a generational transition point. The technologies I am proficient in are from the "old era", while the specific technologies of the "new era" are still unclear, with high learning barriers and long cycles to reach a workable level.

From the perspective of employers, they tend to hire people with practical work experience and proven results. As someone who has just "switched careers", should I be an intern? If they are hiring interns, why not choose someone who is both young and obedient?

Web3 is the Destination

To summarize the above briefly—

The mainstream human-computer interaction technology in the future is likely no longer HTML, CSS, and JS. Even if it is still them, it will no longer be important or will be unrecognizable compared to now, equivalent to learning new technologies and mastering more hardcore foundational knowledge such as computer graphics.

The knowledge related to new technologies has a high learning threshold, and it takes a long cycle to reach a workable level; it is unclear how long the generational transition will take, but it should only be a few years. The sooner you step into the "new era", the better.

In recent years, the growth of the traditional Internet industry has been lackluster, as everyone can see. Most front-end engineers are proficient in the "old era" technology of "traditional Web front-end" and work in business-oriented companies.

If you still limit your vision to Web2, from the perspective of the technology cycle and the cycles of production and commerce, the future is easily foreseeable and only has a few years left to "live". Although working for a technology-oriented company is not a bad choice and can prolong the status quo for a while, this option is only available to a minority of technical elites and has little to do with the vast majority of business front-end developers whose technical skills are not advanced.

For these front-end engineers, especially those who have been in the industry for more than five years, the "traditional Web front-end" technology, which is from the "old era", has become a historical burden that is hard to shake off. Continuing to stay in Web2 will soon lead to the end of their career paths.

In "Questioning Web3, Understanding Web3", I provided a detailed description of my understanding of "Web3". Anyone who is not foolish can see that even with only the "traditional Web front-end" skills, it is quite smooth to transition from Web2.

Moreover, given the current stage of Web3 industry development, it can extend the career lifeline of front-end engineers who rely on "traditional Web front-end" by at least another ten years. Calling Web3 the "destination" for these engineers is not an exaggeration, right?

Conclusion

Since I started writing articles about Web3, some people have commented that decentralization, blockchain, and Web3 are illegal. When asked to cite specific laws and regulations, they fall silent.

I would like to ask: "In China, blockchain technology is applied by government agencies and major Internet companies. Are they openly breaking the law? Or are they simply unaware of the law?"

The wise adapt to the times, and the clever adapt to the situation.

Questioning Web3, Understanding Web3

Ourai L. — Wed, 29 Jan 2025 05:58:09 +0000

When you hear the term "Web3", what comes to mind?

Judging from the comments on my first two articles, most people leave messages like "jail" and "rug-pulling", indicating that they don't understand Web3 and that it has been severely demonized.

It is reasonable and necessary to question Web3, as any concept should be scrutinized to get closer to its essence. However, the comments I see are not questions but rather prejudiced discrimination.

This article aims to explain my understanding of Web3 and to set the record straight.

Why Decentralization?

Being a content creator is one of my many roles. Although I have a personal website that I've been running for over a decade, in today's world, if I want my content to reach a larger audience, I have no choice but to rely on the potential traffic from content platforms.

For content creators, the most frustrating thing is not having anyone view the content they've put their heart into. If it's due to a lack of skill, that's acceptable. But what if it's because the content platform has throttled it or made it visible only to the author?

The system notifications received after such actions are often vague, like "Your content does not comply with the rules", without any clear indication of which specific rule was violated.

What's even more unreasonable is the lack of an effective appeal process—either there is no appeal entry point at all, or appeals are ignored, or they are handled in a perfunctory manner. In front of content platforms, do creators have any dignity?

This is just one example of the many issues I and others have encountered, and their commonality is that centralized platforms struggle to achieve maximum fairness, mainly because:

Power is concentrated in the hands of the operators, with no external participation in decision-making;
Platform rules are not detailed enough, with many vague terms creating a large gray area for arbitrary interpretation and manipulation;
The process of handling user-generated content is not transparent, and there is a lack of a user supervision system;
The feedback mechanism for reporting and appealing is very flawed, making it extremely complex to defend one's rights, and sometimes even impossible.

The relationship between users and centralized platforms is not entirely adversarial:

Platforms can have their own rules and punish users when they violate them, which is reasonable;
Platforms can have imperfect rules but should be open to improvement when users raise valid objections, rather than being arbitrarily domineering;
Users generate data for the platform, and the platform provides traffic or other value to the users—it should be a win-win situation.

However, as mentioned above, centralized platforms often fail to achieve these seemingly simple goals, leaving users' rights poorly protected. This leaves users with only three options:

Leave directly;
Try to appeal in a last-ditch effort;
Continue to endure endless humiliation until it becomes unbearable.

No matter which option is chosen, the likely outcome is "leaving".

But then what? Do you stop doing what you were doing? Or do you switch to another similar centralized platform? Is that platform likely to better protect user rights?

A truly people-oriented digital service should look something like what I described in A Brief Introduction to Individual-Centered Services.

Ultimately, those who value their rights and have ideas will turn their attention to "decentralized" platforms, seeing them as a lifeline.

How to Decentralize

When we talk about "decentralization", it is essential to clarify what exactly is being decentralized, such as data ownership, data control, computing methods, communication methods, etc. Otherwise, the conversation will be like comparing apples and oranges.

Some people advocate absolute decentralization, but this is as unrealistic as wanting absolute freedom or egalitarianism—it's wishful thinking.

Decentralization relies on a distributed network structure, where nodes in the network can communicate directly with each other without going through a central node that has control. That central node is the "center".

Some may wonder—without a "center" to command and coordinate, wouldn't the nodes in the network be in chaos? How can they communicate and collaborate?

Setting aside computer networks for a moment, let's look at how humans do it.

Human communication relies on symbols, language, and other means of conveying information. The same unit of information can have different meanings in different systems. Only when two people are in the same system can they communicate, such as both speaking Chinese.

So, how do human individuals work together in the same direction without a commander? There are probably several ways:

The culture, traditions, and customs of civilizations and ethnic groups;
National laws and regulations;
Organizational rules and regulations;
Tacit understanding developed through interaction.

These are the consensuses or rules that participants agree to follow, using consistent rules to restrain and coordinate the actions of each individual to complete a specific task.

In summary, "the same medium system" and "consistent rules of action" are the keys to achieving "decentralization"!

Shifting back to the field of computers, "the same medium system" refers to data types and encoding, while "consistent rules of action" refer to protocols and standards.

Also, as mentioned earlier, absolute "decentralization" does not exist—within an overall distributed network, one of the nodes may also be a smaller network with a "center".

The Evolution of the Web

People's digital lives today are inseparable from the Web, whether browsing web pages or using native client applications.

Since its inception in 1989, Web-related technologies have developed rapidly to meet various needs, and its current direction of development has somewhat deviated from the expectations of its inventors.

In these 35 years, due to changes in the way people use it in production and life and the shifts in ideological trends, there have been some concentrated characteristics every few years, which are used to divide periods and are named with an incrementing number after "Web".

Many materials introducing Web3 describe it as "Web 3.0" or compare it with "Web 1.0" and "Web 2.0" at the same level—as someone who is sensitive to wording, I find it hard to agree.

Replacing the number representing "generation" with "X", there are two forms of wording: "Web X.0" and "WebX", and they have very different meanings.

Generations do not replace each other but coexist. Whichever one is more dominant becomes the "mainstream", and the less dominant ones do not disappear completely but are "neglected".

Web X.0

The Web was invented by Tim Berners-Lee at CERN, initially for the purpose of sharing documents and data primarily in text and image formats on the Internet, with a natural "decentralized" gene, where one's computer could serve as a server.

At that time, CSS and JS had not yet appeared, let alone PHP and Java. Web pages were not only completely static and non-interactive but also very plain—just like people's thoughts at the time—simply for knowledge sharing.

With the emergence of supporting technologies that made web pages more visually appealing and dynamic in various senses, web pages began to develop towards personalization and commercialization, giving rise to a variety of personal and commercial websites and bringing vitality to the Web.

Around 2004, the mainstream application form of the Web shifted towards socialization and platformization, with a flood of SNS and XaaS products that occupied every aspect of people's daily production and life. The platform side gained control over a large number of users and data, with its commercial value rising accordingly.

Taking around 2004 as a dividing line, the application form of the Web before that was mainly information publishing content websites, where the content was "read-only" for users, known as "Web 1.0".

After that, the application form of the Web became more about user participation in content creation and sharing interactions through platform services, that is, "read-write", known as "Web 2.0". At this time, there was a clear centralization feature, which contradicted the original intention of the Web.

The above is a periodization based on the application form of the Web. As the inventor of the Web, Tim Berners-Lee does not agree with this. In his notes, he divides it from the perspective of technological development and problem-solving:

Web 1.0—Creating a global web of documents and data;
Web 2.0—Enhancing the security of information access;
Web 3.0—Building a semantic web to improve data interoperability.

Among them, "Web 3.0" is to use a series of protocols, standards, and technologies to transform web content into structured data that is easily readable and understandable by machines, turning the entire Web into a vast knowledge graph and intelligent network.

The "Web 3.0" conceived by Tim Berners-Lee can be applied in a decentralized manner to fields such as knowledge engineering, artificial intelligence, the Internet of Things, and social networks.

WebX

In the Web as conceived by Tim Berners-Lee, "decentralization" is natural and does not need to be emphasized. However, in actual application, it has deviated from expectations and has taken on a centralized platform as the mainstream model.

At this time, blockchain-related technologies, which are different from Web-related technologies and are also decentralized, were born. Because they emerged in an era dominated by centralized platforms and come with their own monetary system, their "decentralization" has a
rebellious connotation.

The immutability of cryptocurrency transactions and records is a basic characteristic of blockchain, so it is only natural that various financial activities centered around cryptocurrencies have developed.

The relatively mature application field of blockchain-related technologies at present is decentralized finance, that is, "DeFi". Because it has the characteristics of stock and foreign exchange trading and is unregulated, it can easily cause economic losses and needs to be approached with great caution.

Blockchain-related technologies more or less have financial attributes in their application fields and have also formed corresponding cultures and industries, which is "Web3".

The reason it is called "Web3" is closely related to the centralized characteristics of "Web 2.0" in the application form of the Web mentioned above, and it has a significant difference from the "Web 3.0" conceived by Tim Berners-Lee.

In order to distinguish Web-related products and industries that do not use blockchain-related technologies, they are called "Web2".

Conclusion

This article, based on my personal experience and understanding, has explained the reasons for and the underlying logic of decentralization and has tried to clarify the meanings of the two forms of Web periodization, "Web X.0" and "WebX".

I am committed to exploring and researching solutions for personal and family decentralization and digital intelligence. From this perspective, whether it is Tim Berners-Lee's "Web 3.0" or "Web3" does not matter. However, considering my career development, it is only "Web3".

Web3 is a dark forest, with people lurking everywhere, coveting your assets. You need to be vigilant and cautious at all times to protect yourself—this is the downside of lack of regulation and the price of freedom.

Web3 is the Future for Front-end Engineers Part 2

Ourai L. — Tue, 28 Jan 2025 11:50:37 +0000

In my previous article, Web3 is the Future for Front-end Engineers Part 1, I provided an overview of my journey transitioning from a traditional web front-end engineer to a Web3 full-stack engineer through the Web3 Front-end Bootcamp.

During the early days of the bootcamp, a common question was: "Can we find Web3 jobs after completing the course?" Some even approached it with a traditional mindset, seeking stable Web3 employment.

From what I currently understand, the Web3 industry is highly unpredictable and volatile. The notion of "stability" simply does not exist. It's not uncommon for projects to vanish overnight. If anything, exchanges might be considered relatively stable.

Thus, if you want to enter the Web3 space, you must embrace the instability and uncertainty. You need to be adaptable, flexible, and capable of rapidly and efficiently acquiring new knowledge to keep up with the constant changes.

As a self-proclaimed independent developer, I certainly don't limit my income to the option of "finding a job". Instead, I aim to diversify my sources of income.

In addition to the usual approaches mentioned in Indie Developer is Your Final Destination, the Web3 community offers unique opportunities such as bounty tasks and hackathons. Being a "bounty hunter" can be quite rewarding!

Hackathon Experience

OpenBuild, which has significant influence in the domestic Web3 developer community, not only runs the "Web3 Front-end Bootcamp" but also organizes numerous events, including the recently concluded ETH Shenzhen.

This edition of "ETH Shenzhen" consisted of two parts: a sharing session and a roundtable discussion; and a hackathon competition. For teams participating in the hackathon who did not win, those from outside Guangdong Province were provided with travel subsidies.

Half a month before the event, there was an online hackathon exclusive to bootcamp participants, which can essentially be seen as a linked component of the "ETH Shenzhen Hackathon". The same project could be used for both, so I decided to participate in both.

Before joining the bootcamp, I had the idea of developing a community-centered DAO-like organization around myself. During the bootcamp, while working on an NFT marketplace, I realized that this idea was feasible.

Why not use the opportunity of participating in the hackathon to further concretize this idea as a competition project, and eventually make it another work in my "Internet Freedom Manifesto" portfolio?

Introduction to the Competition Project

After a day of contemplation, I established the name and positioning of the project—

The Chinese name is "吾界", and the English name is "Selfverse". Both convey the same meaning: "Self" is the "world" or "universe".

The world we see is a reflection of our inner world. To live a fulfilling life, one must first enrich their spirit to form a robust, systematic, and self-sustaining "ecosystem".

The true and complete "self" is often deeply hidden, and what we interact with others is a "persona" filtered and somewhat embellished.

This is not only true in real life, but even on the internet, where anonymity is a feature, most people still have to follow the "unwritten rules" of social interaction to some extent.

In today's increasingly internet-dependent daily life, many people need to maintain a relatively stable "persona" online, especially those who rely on digital means to make a living or even get rich through it, such as freelancers, independent hackers, and digital nomads.

Some more popular and easier-to-understand terms can replace "persona"—personal brand, influence, individual identity, super-individual, etc.

The positioning is to provide a suite of tools as infrastructure to help those in need more easily create a "persona" and enhance the closeness of connections between people.

Using decentralized technology that is not limited to blockchain, we solve problems in a decentralized manner and give users the choice of deployment, hosting, management, etc.

This project is an important part of my envisioned "decentralized and digital solutions for individuals and families", and it will be deeply integrated with LinXoid and KnoSys in the future.

Online Hackathon

Although the competition time for the bootcamp's online hackathon was stated to be from August 1st to 10th, the actual development time was likely less than 8 days, as the 1st was almost over by the time it was announced, and submissions were due by 2 PM on the 10th.

In my case, I started developing at noon on the 3rd. I first wrote a smart contract supporting RBAC (Role-Based Access Control) and passed the unit tests by the 5th. From the 6th, I began working on the front-end interface, initially thinking it would take only two days. However, I underestimated the complexity of handling role-based access control, and it was not until the afternoon of the 9th that I completed the integration testing.

Then, I prepared the project introduction materials and submitted them to the bootcamp's GitHub repository via a PR, with time being extremely tight!

Given the ambitious scope of my project idea, it was impossible to implement all the planned features within such a short period, so I had to settle for a small part of the functionality:

To save development time, I chose Ant Design and Ant Design Web3 for the front-end UI components, and deployed it as a pure front-end single-page application using Vite.

Offline Hackathon

Although the "ETH Shenzhen Hackathon" could be participated in online, it was better to attend in person to have a unique experience.

The hackathon took place in Shenzhen from the afternoon of August 16th to the evening of the 18th. I flew there and bought a ticket for the 15th to increase flexibility in case of any issues.

On the 16th, the first activity was check-in for hackathon participants, who received a paper wristband to distinguish their identity. Completing interactions on X also earned a "swag bag" containing a T-shirt, cap, bag, etc., which was completely different from what we received during the bootcamp, with a brand-new design!

Then there were several workshops by sponsors—one of the opening ones seemed under-prepared, showing off some on-the-spot debugging skills and failing to finish the presentation. I left during the second or third workshop to work on my project code.

If you watched the video above, you would see that the paid content was just an empty shell without any actual content, like buying a book with only a cover and no pages. The main task during the hackathon was to address this issue.

To do so, I needed to:

Add an article module, allowing site administrators to add, edit, and publish articles, and visitors to browse and tip;
Modify the paid content module, enabling site administrators to associate articles as chapters, and visitors to see the table of contents and access the actual content;
Add a fund module to centrally control the flow of payment and tipping funds within the same smart contract;
Add a unique visitor center for users to view their payment and tipping records.

I started with the relatively simple visitor center, thinking that using only wallet addresses for user identification would be too plain and monotonous, so I added Jazzicons generated based on addresses, similar to MetaMask, and changed all avatars to this style.

Next, I completed the smart contract code for the token fund, system settings, user registration, etc., which I had already thought about some logic for, and then it was time for the ice-breaking party.

The organizers ordered takeout food such as kebabs, pizza, fried chicken, beer, and soda to the venue. Seeing the food and drinks, everyone rushed to grab them, quickly finishing and not having much time to chat—it seemed everyone was very hungry...

That day, I socialized a bit, meeting some people I had already interacted with in Hangzhou, as well as those I had connected with online before but were meeting in person for the first time.

I got back to the hotel quite late, and there was still some development work to be done for this version of my project, with time being
tight. Since I didn't want to prepare a PowerPoint presentation for the pitch, I had to finish coding in the next two days—I decided to code all night!

Listening to music by Xu Wei, BIGBANG, and others, I finished writing the article smart contract and adjusted the parts related to fund flow in the smart contracts without any issues, and then went to sleep, just before 4 a.m.

The next two days followed a similar routine:

Arriving at the venue before 9 a.m., signing in, and then heading to the coding area to work on my project;
Having lunch with the boxed meals provided by the organizers, all with soup and beef;
Spending the afternoon working on project-related tasks, either coding or explaining;
Attending the dinner organized by the organizers in the evening and switching to social mode.

I hardly attended any of the guest presentations, instead focusing on preparing for the final pitch on the last day. I stayed up all night on the 17th and finally managed to complete most of the remaining features, feeling relieved!

On the 18th, after wrapping up the project, I was eager to share it with others. I approached a fellow bootcamp participant and teaching assistant who was volunteering at the event. I sat next to him, demonstrated the project on my laptop, explained its features, and shared some long-term visions, such as attracting investments by using myself as a value carrier, issuing tokens to investors to prove their rights, and potentially rewarding them when certain conditions are met in the future.

This was the first time I had introduced my project in such detail, and I felt a sense of excitement while talking. He listened attentively, not only understanding what I was saying but also offering some suggestions.

Finally, it was time for the pitch session. There were about 30 projects, each given 10 minutes. Including breaks and other interruptions, the entire process took around 5 to 6 hours—I was the 10th presenter.

Since demonstrating the complete functionality of my project would take more than 10 minutes, I prepared the initial configuration and added demo data beforehand to save time on stage.

When I started my pitch, I hardly made any data changes and instead introduced the project based on the pre-loaded data on the webpage. Just doing this almost filled the time, leaving only enough for the judges to ask two questions...

Did I feel nervous when presenting? On a conscious level, I would say "no". I didn't feel anxious or anything like that, probably because of my experience making vlogs as a content creator. However, my body seemed to disagree, as my voice started trembling after just a few sentences, and I had to constantly adjust and control it.

The main track my project participated in was "Open Source Tools and Infrastructure", with a usage model similar to WordPress. The project's underlying philosophy and vision are quite novel, and I believe they require long-term education and cultivation of potential users. Therefore, I have no plans for commercialization at the moment.

Nevertheless, even though I had stated this beforehand, the judges still asked about commercialization, which left me a bit embarrassed and unsure of how to respond.

The hackathon ended, and in the evening, I had a relaxing dinner with the OpenBuild team and bootcamp participants. The next day, I flew back to Hangzhou.

Reflections on the Hackathon

I believe my pitch was a failure. I felt that the chances of winning were extremely slim. Any score other than zero would be the greatest recognition for me!

Although it was impossible to explain my project clearly within 10 minutes, this cannot be an excuse. There is still much room for improvement, such as:

Even with relatively complete functionality, a demo alone is not enough. A PowerPoint presentation is essential.
My speaking pace was a bit slow, and the presentation lacked rhythm. I enjoyed the presentations of the two projects that followed mine, and I should learn from them.
I should have interacted more with the judges before the pitch, introducing my project more. This would be like extending my pitch time.

Now I understand that participating in a hackathon is like playing a game of chess—how you allocate time between development, pitch material preparation, and networking affects the actual workload and the people you connect with, thereby influencing your chances of winning.

Hackathons have two meanings for me:

When working on my own project, it feels like entrepreneurship. The judges are like investment firms, and winning the prize is like securing investment.
When working on someone else's project, it is like a bounty task. I use my professional skills to help them win and share the prize as compensation. However, for bounty tasks, the compensation is more uncertain.

In addition to coding, I also invested more effort in networking during these days than usual. I used to be quiet in offline settings, mainly listening to others. This time, I not only engaged in passive interactions but also actively approached people, including complete strangers.

However, there was still a shortcoming: most of the people I networked with were those I had already connected with before, and very few were "new" acquaintances.

Many technical people at such events have a common misconception—that they attend to learn technology. Those with this mindset will likely leave disappointed.

I used to be one of them, attending various technical events before 2017 but rarely feeling like I had learned anything, mostly thinking "nothing special". Thus, I stopped attending until this year.

My perspective has changed now. The most important aspects of attending events are to understand industry trends, interact with others, build deep connections, and explore collaboration opportunities—these are key to increasing the success rate of my career as a self-proclaimed independent developer.

Summary

This concludes my summary of the initial three-month journey of transitioning from a traditional web front-end engineer to a Web3 full-stack engineer.

For me, with a rich knowledge base and experience forming an abstract model network, the technical aspect of the transition was not very difficult. The slightly more challenging part was distilling a more stable model from the complex blockchain ecosystem and the ever-changing Web3 industry, and accumulating valuable project experience.

To enter the Web3 space, one must firmly discard the notion of "stability" in mindset. "Flexibility" and "efficiency" are your greatest and strongest weapons!

Web3 is the Future for Front-end Engineers Part 1

Ourai L. — Tue, 28 Jan 2025 04:02:00 +0000

In April of this year, likely due to the "Golden March and Silver April" phenomenon, I often saw front-end peers discussing job hunting. They were troubled about which company to join and were uncertain about job stability and prospects.

For me, who thought I had "seen through everything", I believed that as long as they didn't break out of their original mindset, no matter what choices they made, they would end up with the same results. However, no matter how I explained the limitations, they remained indifferent, which really made me anxious!

Thus, feeling exhausted, I wrote "The Last Advice to Front-end Engineers" and decided never to "meddle" again in trying to pull those who were about to jump into the fire pit—one last attempt to help, then let go and respect their destinies.

Although I firmly believed that the original path of front-end development was not viable, I didn't know how to relatively smoothly switch to another seemingly feasible path at that time.

Until mid-May, while I was tinkering with my home data center and probably thinking about decentralized issues, the term "Web3" suddenly popped into my mind, pointing me to that smoother transition path.

Exposure to Web3

Regarding "Web3", before May 14th, I had only heard of it and basically knew it existed without really understanding it.

But on that day, after installing MetaMask and experiencing a few dApps and getting a preliminary understanding of the ecosystem, I felt that the Web3 direction had a lot of growth potential and a promising future—

There are so few dApps for individual users, the user experience is so poor, and the infrastructure system is not yet mature. Of course, there is a lot of room for growth! 😂😂😂

When mentioning "Web3", another closely related term comes to mind—"DAO", which stands for "Decentralized Autonomous Organization"—a type of organizational form that seems to match my ideal.

Naturally, I immediately applied and joined a DAO initiated by Chinese people that matched my ideals.

Towards the end of the month, the DAO's manager forwarded in the group a "Web3 Front-end Bootcamp" organized by OpenBuild, which not only teaches the knowledge and skills needed to transition to Web3 full-stack development but is also free, with various rewards. I really couldn't find a reason not to sign up!

Learning in the Bootcamp

The bootcamp started on June 4th, entirely online, and except for the Q&A sessions, it was asynchronous, giving both teachers and learners a lot of freedom to arrange their time independently.

The overall positioning and design are more inclined to "help experienced Web2 front-end developers transition to Web3 front-end", including 6 basic courses and 3 advanced courses:

Basic courses—covering the basic elements needed to develop a dApp based on EVM, and using the more common project types NFT market and DEX as practical exercises;
Advanced courses—promoting products of stakeholders, and also helping developers who want to enter the industry to adapt to the current industry's variability as soon as possible.

Each class has corresponding homework, which needs to be submitted as a PR in the accompanying GitHub repository for the review personnel to check; those submitted before July 16th can receive rewards, with a maximum of 43 USDT.

If you encounter problems during learning and doing homework, there is a bootcamp-specific group for everyone to discuss and exchange in real time, which plays a role in mutual supervision while learning from each other.

Not only doing homework has rewards, but writing good learning notes and making other contributions to the bootcamp will also have rewards, but again, only before July 16th—As an active enthusiast, I naturally got them all～😎😎😎

Even though there are no rewards now, if you want to transition to Web3, the courses of this bootcamp are still worth looking at; it's best to follow and do the homework, and as one of the reviewers, I will try my best to correct it.

For more of my experiences during the bootcamp, see the learning notes "How to Build a dApp as a Smart Contract Newbie" and "OpenBuild Web3 Front-end Bootcamp Review".

Gains from the Bootcamp

This more than a month's bootcamp experience had a significant impact on me and was a milestone in my life because the gains from multiple perspectives looked quite good—

The most basic and important thing is to achieve the initial goal of signing up for the bootcamp—to transition to Web3 full-stack development—although I have just crossed the threshold, I can now independently develop a complete dApp, laying the foundation for participating in hackathons next.

Since I actively communicated with others in the group during the learning process and occasionally gave suggestions to the organizers, I was absorbed into the "teaching assistant" team to help review homework.

Later, I "fiercely" reviewed and merged hundreds of PRs, indirectly teaching some people the skills of using Git and the precautions for open-source collaboration.

Given my outstanding performance, including the rewards for doing homework and writing learning notes, I finally received more than 500 USDT at the end of the camp, which should be the most.

My activity during the bootcamp had some influence, and I established connections and gradually became familiar with others, including the founder of the organizer OpenBuild.

Taking this bootcamp as a lead, I gave some more systematic suggestions to OpenBuild and slightly envisioned its future development direction; perhaps seeing that I was willing to work together, I was pulled into the PMC.

After multiple communications and exchanges, at least I think a deep cooperative relationship can be established between me and OpenBuild—formally independent but actually closely connected.

Summary

As a Web front-end engineer who has been struggling for more than ten years, I firmly do not see a good future for traditional Internet Web front-end development; by chance, I found the Web3 industry that can maximize smooth migration.

Since then, I decisively decided to transition to Web3 full-stack development, that is, in addition to the original Web front-end knowledge and skills, I also need to learn and master smart contract development, and accumulate relevant project experience on this basis.

By deeply participating in the "Web3 Front-end Bootcamp" organized by OpenBuild, I not only achieved the basic goal of "transitioning" but also gained many additional benefits, with very sufficient positive feedback!

How to Build a dApp as a Smart Contract Newbie

Ourai L. — Mon, 27 Jan 2025 16:09:18 +0000

As a senior front-end engineer who has long been pessimistic about the traditional Internet industry's Web front-end development, I have been searching for a way to maximize the use of my existing knowledge and skills. I chose to transition to full-stack development in the Web3 field.

When I made this decision, I knew little about Web3, whether from the perspective of a practitioner or an ordinary user. I urgently needed a way to get started quickly!

By chance, I learned about OpenBuild's Web3 Front-end Bootcamp. Judging from the content introduction, it should meet my needs, so I signed up without hesitation—it's free, and there are even "Manis" to earn. Why hesitate?

The content of this article is the practical notes of the boot camp course, focusing on "How a pure novice in smart contracts with front-end development foundation can develop their first NFT market dApp". That is to say, it will cover task 3, task 4, and task 5.

Since I am a beginner transitioning to Web3, I don't understand many things. The following content represents my personal understanding. If there are any errors, omissions, or mistakes, please point them out.

I think the name "smart contract" comes from its business role, and for developers, it is just a software program that needs to be written in a certain programming language.

Therefore, to write Ethereum smart contracts, you need to learn and understand Solidity syntax, ERC, and on-chain interaction processes. Once you understand these, you can write the code correctly. The rest is deployment.

Learning Solidity

Experienced programmers can tell at a glance that Solidity is an object-oriented static type language. Although there are some unfamiliar keywords, it does not prevent me from seeing it as a "class" wrapped in a "contract".

Therefore, if you are familiar with typed, class-based programming languages such as TS and Java, you can quickly get a preliminary understanding of Solidity by establishing a mapping relationship.

The contract keyword can be considered a domain-specific deformation of the class keyword, more semantically expressing the concept of "contract". Thus, writing a contract is equivalent to writing a class.

State variables are used to store data within the contract, equivalent to class member variables, that is, class properties.

Functions can be defined both inside and outside the contract—the former is equivalent to class member functions, that is, class methods; the latter is ordinary functions, usually some utility functions.

Unlike TS and Java, in Solidity, the visibility identifiers for variables and functions are not at the front, and their positions are inconsistent, which is somewhat counterintuitive.

The semantics of private and public are the same as in other languages, but there is no protected. Instead, there is internal, and there is also an additional external for functions that are only callable externally.

Function modifiers are equivalent to TS decorators or Java annotations and can be used for aspect-oriented programming (AOP). Both functions and function modifiers can be overridden by derived contracts.

The following types can all be regarded as objects in ES, but they are used in different scenarios:

Structures (struct) are used to define entities;
Enumerations (enum) are collections of limited options;
Mappings (mapping) are infinite options.

Solidity supports multiple inheritance and function polymorphism, which can better combine and reuse; since contract development tends to be driven by ERC, the side effects of multiple inheritance should not be as severe as in other languages.

Given that Solidity is born for blockchain and the characteristics of blockchain itself and application scenarios, communicating with the outside world through events and rolling back previous operations when encountering errors are "must-haves", so the syntax supports event and error-related processing.

The usage of the require() function is also a bit special to me. require(initialValue > 999, "Initial supply must be greater than 999."); is equivalent to the following ES code in a concise and semantic way:

if (initialValue <= 999) {
  throw new Error('Initial supply must be greater than 999.');
}

Understanding ERC

In Ethereum, "ERC" stands for "Ethereum Request for Comments", which is a type of EIP (Ethereum Improvement Proposal) that defines standards and conventions for smart contract applications.

Since Web3 promotes decentralization and openness, ensuring the interoperability of smart contract applications is a basic requirement, so ERC, as the standard in this regard, is very important.

The most basic ERCs in Ethereum smart contract application development are as follows:

ERC-20—Fungible tokens, as the infrastructure of a financial system, such as virtual currencies, contribution points;
ERC-721—Non-fungible tokens (NFTs), as the infrastructure of an identity system, such as medals, certificates, tickets.

In fact, ERC can be regarded as authoritative API documentation.

Writing Smart Contracts

When developing smart contract applications, you need to choose a framework to assist. It seems that Hardhat and Foundry are used more often—I chose the former because it is friendly to the JS technology stack, that is, it is friendly to people transitioning from front-end development.

In terms of IDE selection, many people will use Remix provided by the Ethereum official, while I continue to use VS Code, mainly to reduce learning costs as much as possible when just getting started.

If you are not familiar with Hardhat, you can follow the official tutorial step by step to selectively set up the running environment. In the generated directory structure, in addition to the hardhat.config.ts configuration file, you basically only need to pay attention to 4 folders and their files:

contracts—Smart contract source code;
artifacts—Compiled files generated by hardhat compile;
ignition—For deploying smart contracts based on Hardhat Ignition;
test—Smart contract function test code.

In ignition, compiled files will also be generated, but they are different from artifacts and are bound to the target chain to be deployed, that is, they are generated in the folder of the chain ID to be deployed.

As the 3 tasks of the boot camp assignment involve ERC-20 tokens, ERC-721 tokens, and NFT markets, the first two token contracts can be based on the verified OpenZeppelin Contracts for extension.

My implementation code for the ERC-20 token RaiCoin is as follows:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import { ERC20 } from "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract RaiCoin is ERC20("RaiCoin", "RAIC") {
  constructor(uint256 initialValue) {
    require(initialValue > 999, "Initial supply must be greater than 999.");
    _mint(msg.sender, initialValue * 10 ** 2);
  }

  function decimals() public view virtual override returns (uint8) {
    return 2;
  }
}

It is best to mint a certain amount of tokens (usually a large number) at initialization and set the owner to your own account address. Otherwise, you will be prompted that there is no balance when conducting transactions later, which is more troublesome to handle.

The msg.sender in the constructor() is actually the account address that deploys the contract. If you deploy it with your own account address, the initial tokens will all go into your account.

Since my own ERC-20 token is just for fun and will not appreciate, you can consider overriding the decimals() in OpenZeppelin to set the value smaller.

Below is the implementation code for the ERC-721 token RaiE:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import { ERC721 } from "@openzeppelin/contracts/token/ERC721/ERC721.sol";

contract RaiE is ERC721 {
  uint256 private _totalCount;

  constructor() ERC721("RaiE", "RAIE") {
    _totalCount++;
  }

  function mint() external returns (uint256) {
    uint256 tokenId = _totalCount;

    _safeMint(msg.sender, tokenId);

    _totalCount++;

    return tokenId;
  }
}

Why did I only additionally implement a mint() without any parameters, just simply issuing coins? Aren't NFTs supposed to have corresponding pictures? The specific reasons will be explained later.

These two token contracts are a piece of cake. You don't need to write much code yourself. The real thinking is mainly focused on the NFT market contract, such as—

Should the NFT list in the market be paginated?

If paginated, the delay when flipping pages will be more noticeable, and the user experience on the front end will not be good. But if not paginated, there will also be this problem when there are many NFTs.

Where should the NFT picture URL be stored? In the NFT contract or the market contract?

In theory, it should be stored in the NFT contract, but if so, when obtaining the NFT list, it will frequently access the NFT contract through external calls, affecting performance and user experience.

Should a list of "who owns which tokens" that can be externally obtained be maintained in the NFT contract?

If there is, the data is redundant compared to the market contract, making the NFT contract very bloated. If not, it is not possible to explicitly know which tokens there are and who they belong to.

It can be seen that relying solely on blockchain-related technologies to make a product-level application currently has great limitations, and the user experience will be very poor!

That is to say, the performance and experience of the product still need to be supported by the traditional application architecture, and the blockchain is only used as identity verification and a "backup" for some data.

Therefore, I temporarily gave up the way of thinking oriented towards making products and stopped worrying about whether it is reasonable or not, and turned to first meeting the requirements of the assignment—just having the relevant functions is fine.

In this way, the decision is very easy to make—just do it in a way that can complete the assignment more quickly! As a result, the above three doubts were quickly eliminated:

The NFT list in the market is not paginated—there will only be a few NFTs;
The NFT picture URL is stored in the market contract—the NFT contract is only used by its own market contract;
The NFT contract does not maintain a list of token ownership—temporary operations can remember which account minted which token.

When implementing the NFT market RaiGallery, I found that only arrays can be traversed, and mapping cannot, and arrays with a specified length when initialized cannot use .push() to add elements, only indexes can be used:

contract RaiGallery {
  struct NftItem { address seller; address nftContract; uint tokenId; string tokenUrl; uint256 price; uint256 listedAt; bool listing; }

  struct NftIndex { address nftContract; uint tokenId; }

  NftIndex[] private _allNfts;

  function getAll() external view returns (NftItem[] memory) {
    // The length of the array is specified when initialized
    NftItem[] memory allItem = new NftItem[](_allNfts.length);
    NftIndex memory nftIdx;

    for (uint256 i = 0; i < _allNfts.length; i++) {
      nftIdx = _allNfts[i];
      // Here, using `allItem.push(_listedNfts[nftIdx.nftContract][nftIdx.tokenId])` will report an error
      allItem[i] = _listedNfts[nftIdx.nftContract][nftIdx.tokenId];
    }

    return allItem;
  }
}

Debugging Smart Contracts

After writing the smart contract source code, you need to write test code to go through it first, expose some basic problems, and solve them.

As mentioned above, in the Hardhat project, the test code is placed in the test folder, and it is basically one file for each contract, of course, the reusable logic between different files can also be extracted into additional files, such as helper.ts.

The test code is written based on the API of Mocha and Chai. Before really starting to test the contract functions, you need to deploy the contract to the local environment first, which can be the built-in hardhat, or you can start a local node localhost, I temporarily choose the former.

At this time, the deployment method can reuse the Hardhat Ignition module, but I haven't figured out how to use it yet, so I use the easier-to-understand loadFixture().

Testing is quite troublesome, and it feels like almost a day's time is spent on it, but in this process, I have a deeper understanding of how ERC-20 tokens, ERC-721 tokens, NFT markets, and users should interact, such as:

If you directly use the contract instance to call the method, the caller is the contract itself. You need to use contract instance.connect(some account) and then call it to simulate the operation with the user;
The owner of the NFT needs to authorize all their NFTs to the NFT market through .setApprovalForAll(market contract address, true) before they can be listed for sale in the market.

I think the single-party testing of the smart contract is almost done, and it is time to deploy it to the local node for joint debugging with the front end, which will use the Hardhat Ignition module this time.

When I went to read the documentation to learn, I felt a bit abstruse and difficult to understand, and I wanted to sleep when I read it; but now when I look back, each module is actually describing how to initialize when deploying the corresponding contract of the module.

Hardhat Ignition supports sub-modules, which can be used through .useModule(), and can be processed together with sub-modules when compiling and deploying modules, that is to say—

Assuming I have RaiCoin.ts, RaiE.ts, and RaiGallery.ts three modules, among which RaiGallery.ts needs the address returned by the deployment of RaiCoin.ts when deploying, then RaiCoin.ts can be used as a sub-module of RaiGallery.txt:

import { buildModule } from '@nomicfoundation/hardhat-ignition/modules';
import RaiCoin from './RaiCoin';

export default buildModule('RaiGallery', m => {
  const { coin } = m.useModule(RaiCoin);
  const gallery = m.contract('RaiGallery', [coin]);

  return { gallery };
});

In this way, RaiE.ts is deployed separately, and when deploying RaiGallery.txt, RaiCoin.txt will be cascaded deployed, so only two deployment commands need to be executed.

Then, change the defaultNetwork configuration item in hardhat.config.txt to 'localhost', execute npx hardhat node in the root directory of the Hardhat project to start the local node, and then open another terminal window to deploy the smart contract:

Execute npx hardhat ignition deploy ./ignition/modules/RaiE.txt to deploy the ERC-721 token contract;
Execute npx hardhat ignition deploy ./ignition/modules/RaiGallery.txt to deploy the ERC-20 token contract and NFT market contract.

After all deployments are successful, the compiled contract-related files will be generated in the ignition/deployments/chain-31337 folder (31337 is the chain ID of the local node):

deployed_addresses.json lists the contract addresses;
The JSON files in the artifacts folder contain the contract's ABI.

The above two key pieces of information need to be copied and pasted into the global shared variables of the front-end project for use in joint debugging.

Before starting joint debugging, you need to do two things in the MetaMask wallet:

Add the Hardhat local node to the network, you can refer to the YouTube video How to Add a Local Test Network to Metamask;
As shown on the official website, add the ERC-20 token contract address you are testing to facilitate viewing of account balances.

The third-party libraries and frameworks I depend on in the front-end part mainly include Vite, React, Ant Design Web3, and Wagmi. Since the front end is what I am familiar with, there is no experience to share, so I won't elaborate.

However, when developing the front-end part, there was one point that puzzled me for a while—

Although programmatically, a new NFT needs to be minted before it can be listed on the market for trading, the interface should be one-step, that is, after filling in the NFT-related information and clicking "OK", it is directly listed.

The assignment requires a two-step operation of minting first and then listing, which I think is a bit unreasonable, or the user experience is not good.

In the end, due to my unfamiliarity with Wagmi and really not thinking of an implementation plan, and eager to submit the assignment, I didn't continue to worry about it...😂😂😂

When debugging, if you encounter problems that block you, you can troubleshoot in the following steps:

When listing NFTs for sale, you need to first call the setApprovalForAll of the NFT token contract to authorize the market contract and use the escrow market to transfer NFTs on your behalf;
Before sending the listing request, use viem or ethers' parseUnits to convert it into a number that conforms to the decimals() defined in your ERC-20 token contract (the default is 18);
Before purchasing NFTs, check the balance of your custom ERC-20 token in your wallet to avoid mistaking Ether (ETH) for the balance of your ERC-20 token;
When purchasing NFTs, you need to first call the approve of your ERC-20 token contract to authorize the market contract and use the escrow market to transfer funds on your behalf.

The joint debugging is also over, finally, it is time for the last link—deploying to the Sepolia test network!

This requires Sepolia Ether, and the general way to obtain it is to drip it from those "faucets", and you can only get a little bit every day. Fortunately, @Mika-Lahtinen provided a PoW method, see @zer0fire's note 🚀 Ultra-simple faucet tutorial - No transaction records or account balance required.

At this time, turn your attention back to the Hardhat project, open the hardhat.config.txt file, temporarily change the defaultNetwork to 'sepolia', and add a sepolia in networks:

const config: HardhatUserConfig = {
  defaultNetwork: 'sepolia',  // Temporarily change the default network to this
  networks: {
    sepolia: {
      url: 'Your Sepolia endpoint URL',
      accounts: ['Your wallet account private key'],
    },
  },
};

The Sepolia endpoint can be obtained by registering an account on Infura or Alchemy.

Then, follow the process of deploying to the local node mentioned above again, and after verifying the functions of the test network environment in the front end, you can submit the assignment!

Conclusion

I have open-sourced all the code related to the NFT market dApp in ourai/my-first-nft-market, and plan to solve the points discussed above in the future, and make it a benchmark for this kind of demo.

Since the Sepolia contract address has been configured inside, you can directly run it locally and operate it. Welcome to refer to, discuss, and point out.

The Last Advice to Front-end Engineers

Ourai L. — Mon, 27 Jan 2025 03:02:12 +0000

I don't know why, but I have this annoying habit of being overly eager to meddle in other people's affairs, which is why I changed my group nickname to "Enthusiastic Netizen" in some WeChat groups.

Recently, some of my peers have been job hunting, cramming for interviews, and asking how to answer certain interview questions, and so on.

Seeing them like this, I get extremely anxious – they seem to be willingly jumping into a pit of fire, one after another!!!

At this point in time, the vast majority of my peers are "Web Front-end" developers centered around HTML, CSS, and JavaScript, and most of them are business front-end developers, who mostly work on middle and back-office applications.

The "Momentum" of Middle and Back-office Applications

Middle and back-office applications have two important characteristics –

First, business processes and data security are far more important than product experience. Compared to so-called "product power" and flashy visual design, ensuring that business processes proceed smoothly and that data remains intact is much more important, with the rest being just icing on the cake.

Especially when facing manufacturing and other physical industries, even without digital products, the business can still run, albeit less efficiently; digital products exist only to improve efficiency and have no right to change existing business rules, nor should they be the other way around.

Therefore, companies or departments that develop middle and back-office applications do not need the "product manager" of to C, but need a "requirements manager" who can understand the needs of the business side (mainly industry or domain experts) and convey them accurately.

Second, the front-end part of middle and back-office applications is highly patterned, and since business and data are prioritized, it is possible to better model at the system level and abstract a construction pipeline that automatically deduces the final application from the model as the source.

That is to say, as long as the model is extracted from the business, and various relationships are described based on a certain mechanism, the final effect of the operable application can be seen directly.

The ways to describe relationships can be:

DSLs with programming-like experiences such as XML, JSON, JS pure objects;
Visual operations by dragging and dropping on the page;
Let AI understand the requirements document and then translate it.

The last one is the ability that I advocate and pursue for the "knowledge-driven, intelligent R & D integration platform" I mentioned.

As for what that "mechanism" is, there are two that I currently favor:

The Nop platform implemented by Canonical based on its own reversible computing theory;
The BFF framework that my senior is currently developing.

But they both lack support for the pure front-end part, and my "Anti-chaos Front-end Engineering" will fill this gap.

The "Fate" of Engineers

Before ChatGPT came into the public eye, we believed that in the R & D process of middle and back-office applications, designers and front-end engineers would be eliminated, and "requirements managers" and back-end engineers could collaborate to do the job.

The emergence of ChatGPT and similar products has also made it possible to eliminate most back-end CRUD engineers, and "requirements managers" only need to write detailed requirements documents.

Since it is a "trend" that business R & D engineers will be replaced by knowledge-driven, intelligent R & D integration platforms, why not accelerate this process?!

In our view, positions engaged in such R & D have no future, but some people do not think so – either thinking with the current perspective, or believing that humans are stronger than AI.

However, the fact is that the iteration and growth speed of technology is never linear, and one of the impacts of its development is to require people to renew their knowledge and skills; the most foolish thing about humans is to be self-righteous.

Conclusion

Although the main topic of this article is that business R & D engineers of middle and back-office applications will "suffer heavy casualties", it does not mean that to C is "unscathed", only the proportion will not be so large.

Compared with my idea, my senior's statement is a bit more exaggerated – maybe one day AI will create miracles and directly generate applications composed of source code, instead of those that have been abstracted layer by layer.

Such applications are black boxes, and from the perspective of software engineering, they are not maintainable, and any best practices and optimization methods will become invalid – neither meaningful nor necessary – just like after the advent of cars, knowledge and skills about horse riding became useless.

Many times I feel like that kind of person – telling others that a disaster will come in a few days and they should escape quickly, but they think I am talking nonsense and make fun of me.

So, this is my last warning, I hope those who see and understand it can take action and stop jumping into the pit of fire.

Things Behind the KnoSys Web App

Ourai L. — Sun, 26 Jan 2025 13:27:58 +0000

In my previous article "I'm Developing the KnoSys Web App", I highlighted the reasons for developing the KnoSys GUI application and its core features. However, some people still don't understand why I'm reinventing the wheel.

To put it simply, KnoSys is a piece of my grand vision, and one must grasp the overall picture to truly comprehend why I insist on creating this tool.

I hope that by revealing the ideas and significance behind the KnoSys GUI application in this article, everyone can gain a slight understanding of my grand vision.

Design and Composition

As someone who pursues freedom and doesn't want to be held hostage by platforms or tools, I won't create a tool that holds others hostage—do unto others as you would have them do unto you.

Basic Philosophy

In the core design, I adhere to the principles of "openness, standardization, and transferability" as much as possible, especially for the crucial data:

Data is stored in file formats that can be viewed using the built-in applications of the operating system without the need to download or install additional applications;
Text data prioritizes formats such as Markdown and YAML, which are friendly to human reading and writing and have become (de facto) standards.

Therefore, even if you don't use the KnoSys GUI application and switch to Obsidian, Source Notes, IDE, etc., you can still open and edit the relevant files without any barriers—even using the built-in applications of the operating system!

The only limitation of using the KnoSys GUI application is the directory structure specification for convenient program processing—the QiiDB Data Specification, which is also in line with (de facto) standards or common practices.

User Autonomy

When using other cloud services or applications, they always "presumptuously" build in some function modules that are never used and cannot be deleted or disabled, occupying limited "space" in various senses.

As a knowledge management tool, the most indispensable function features of the KnoSys GUI application are "knowledge base" and "extension market", and the rest are basically enhanced functions, which can theoretically be obtained on demand through the "extension market".

I don't intend to deprive users of their choice, so I won't build in any non-essential function modules, and will maximize user autonomy in choosing and combining.

Technical Architecture

From a technical point of view, to put it bluntly, the KnoSys GUI application is the operation client of QiiDB, because it itself does not have any operation capabilities—

QiiDB is a data specification and an open data collection based on this standard, and KnoSys is a tool for data processing based on this data specification.
Ourai's thoughts

So far, the KnoSys system consists of three main parts:

SDK—provides the ability to operate folders and files that comply with the QiiDB data specification in the form of functions;
Website—combined with SSG to convert data sources that comply with the QiiDB data specification and generate static websites;
Application—visual operation of data sources that comply with the QiiDB data specification, that is, the KnoSys GUI application.

Among them, the application part strongly depends on the SDK, and the website part will serve as an extended function of the application to provide the "knowledge base" sharing and publishing capabilities.

The "knowledge base" dynamically renders the interface-related display forms based on "metadata" for data verification and other capabilities, which are built based on my own low-code development Fxxk Design and Future.js system.

In addition, the ability to subscribe to information from the "person" dimension will depend on LinXoid, a project aimed at helping people establish connections.

Vision and Significance

Since KnoSys is a piece of my grand vision, what do the other pieces look like? Next, I will reveal them to you in both pragmatic and visionary aspects.

Digital Life

Like relying on electrical appliances, the vast majority of people in the twenty-first century can no longer live without digital products, and post-00s are the "natives" of the digital world.

However, so far, digital products have mainly been aimed at businesses, enterprises, and governments, and those aimed at individuals are mainly for consumption and entertainment; there are not many products that make life better for individuals and families, and I think they are not good enough.

As a person who loves life and has software development skills, I am determined to fill and improve this gap!

Combining my personal situation, to support the sustainable digital nomadic life I want to live, I need a family digital workbench:

Build a server in the physical family that can be accessed from the outside network, and it is best to have multi-center data backup in multiple places;
AI-assisted knowledge management, which will use KnoSys and local large language models;
Knowledge-driven personal and family life management, including family collaboration, finance, health, smart devices, etc.;
Personal or family communication for resource sharing and communication, which will use LinXoid and peer-to-peer networks (P2P).

At that time, the server in the physical family will be the SSOT data center, and computers, mobile phones and other devices will be client operation interfaces that basically do not store persistent data and connect and access the data center.

See the article "If I Become a Digital Nomad" and the "Digital Life" plan for more information.

Cyberspace

With the development of technology, the "erosion" of the digital world on the real world will gradually deepen, until the two are deeply integrated, and people no longer "deliberately" distinguish between the virtual and the real—both are illusions, and both are real.

In the real world, the most important thing is the "knowledge" formed by the exploration of truth, and everything centered around "people"—in the digital world, which is a reflection of the real world, is equally important and is its foundation.

To become a resident of cyberspace, it is extremely important to have a clear understanding of "knowledge" and "people", to clearly realize their importance and to fight for the relevant rights!

In the real world, in the past, "knowledge" was held by a very small number of specific groups such as wizards, priests, and popes, while the general public was ignorant and could be manipulated at will; in the digital world, "knowledge" is mostly held by platforms, and users are manipulated.

In the real world, in the past, most people generally had no human rights and were exploited and oppressed as de facto slaves by a very small number of specific groups; in the digital world, people are just resources in a certain platform, and are exploited cheap/free labor.

The civilization degree of the digital world is far lower than that of the real world—most people have not yet realized their "knowledge" and "people" related rights in cyberspace, let alone strive for them!

I hope my actions can awaken others, even if it's only a few.

For extended reading, you can see my "Talking About Individual-Centered Services" series of articles.

Conclusion

Speaking of the KnoSys GUI application, because it adheres to the principles of openness, standardization, and user autonomy, and there are no technical limitations, I chose Web technology with the same philosophy to implement it.

Initially considering supporting the following two usage methods:

Automatically open in a new tab through a browser extension;
Automatically start the application service when the computer is turned on, and manually enter the address in the browser.

The knowledge management part only provides the desktop version, and if you want to operate on mobile devices, please look forward to the mobile applications related to "digital life" that I will develop in the future!

I'm Developing the KnoSys Web App

Ourai L. — Sun, 26 Jan 2025 04:05:30 +0000

After the New Year, I once again embarked on the construction of the KnoSys system, which had been on hold for nearly nine months. Last year in Q1, I worked on a static website generator, but this time, I am developing a Web-based all-in-one knowledge management GUI application.

In this span of less than a month, I have been writing code intermittently in my spare time. Although the application is not yet usable, I am eager to introduce it specifically!

Problems and Needs

The motive behind doing something is crucial. A clear and well-defined motive can provide strong willpower and the ability to implement ideas effectively.

Public Clouds Are Not Trustworthy

I believe that if people optimistically flock to various cloud services, it is because they do not consider the data they generate as valuable assets, or they have not been sufficiently harmed by the service providers.

As an old Internet user with nearly 20 years of experience, I have been hurt enough by cloud service providers—

In the early stages of launching cloud services, to quickly accumulate users and obtain their information and the data they generate, service providers often offer free services for a period, sometimes with various promotional activities.

Once most users have generated a significant amount of data and become dependent on the platform, it is time for the service providers to start reaping the benefits—charging for functions that were originally free, or restricting/reducing the amount of resources that were previously available for free.

Some platforms do not notify users before banning or deleting the data they generate, leaving no time for backups; worse still, some do not even notify users before shutting down the service and simply disappear!

The shutdown of cloud services or the bankruptcy of the companies behind them is inevitable. When there is a tendency to deeply use a certain cloud service, there is a risk of being held hostage.

Fragmented "People"

Current content platforms and social media all have their own account systems, and they tend to create closed information silos—neither integrating with other platforms and services nor providing relatively open data access APIs.

This behavior is driven by their own commercial interests, ignoring the needs and experience of users, forcing users to only obtain updates from people they are interested in through the "follow" function within the application.

I particularly dislike having to "follow" someone just to view their content!

There are some platforms that do a slightly better job, such as Twitter's "Lists" feature, which solves my need to receive updates without having to "follow" someone.

However, even so, it is still impossible to subscribe to people across applications and platforms on my own.

Clumsy File Management

The final products of blogs, API documentation, etc., are static pages, and their data sources are local files that conform to certain standards and formats—these files can be considered a mixture of "regular data" and "metadata".

When the number of files increases and the site becomes more complex, there are several significant pain points with the simple local file format:

It is not easy to know what documents you have;
Searching and editing are inconvenient;
The relationships between documents are unclear and unmanageable.

There is a need for a way to manage local files like a mid-to-back-end business system and to convert the data of local files in some way.

My Eccentric Needs

My biggest hobby is to "collect" and "organize" things that interest me, which gives me a strong sense of fulfillment, control, and security.

From a young age to now, I have collected many physical items in various categories, such as cassettes, CDs, comics, games, stamps, and currencies. In addition to these, I am fascinated by the collection of virtual data and information that can expand infinitely!

In my limited understanding, since the birth of the universe, nothing exists in isolation; there are more or less relationships between things—finding and utilizing these relationships is extremely valuable!

Modeling the collected data and information, effectively associating them with each other to form a network, and thereby achieving:

Standardizing and automating mechanical tasks;
Quickly finding the optimal path between the current state and the target based on needs;
Providing suitable and appropriate suggestions based on the current state of life, living, and work.

These needs of mine are difficult to meet when using cloud services or other applications.

Features and Characteristics

To facilitate understanding, I liken the GUI application I am developing to a local version of "Yuque", but unlike Yuque, it does not support collaboration with others and only supports local operations for individuals.

Below is a brief introduction to the core features and characteristics.

Knowledge Base

In the KnoSys system, the term "knowledge base" has both broad and narrow meanings—broadly speaking, anything that follows the QiiDB data specification is included; narrowly speaking, it is almost equivalent to a dataset, which is the case in this GUI application.

Using a local folder set by the user as the data source, it traverses subfolders and reads file content according to the QiiDB data specification, presenting it in the interface through a list page.

Each record in the list corresponds to a real file, such as YAML, Markdown, images, etc., which means that the CRUD operations in the interface are actually read and write operations on files.

In addition to the above operations on "regular data", it is also possible to visually modify "metadata": defining field names, data types, validation rules, etc.; configuring the display forms of list pages, form pages, detail pages, and other interface-related elements.

Multi-application

The "application" in this GUI application is similar to the "space" in Yuque and is the broad "knowledge base" mentioned earlier. In theory, each "application" has a corresponding local Git repository, which provides a certain degree of data isolation.

A folder corresponding to an "application" can contain one or more datasets and may also include files that do not conform to the QiiDB data specification in addition to the datasets—these files will be ignored and not processed.

Modifications and deletions of data, which are variable operations in the interface, are restricted within a specific "application" and cannot change data in other "applications". However, data from one "application" can be read as an external data source for other "applications".

For example—

I have two "applications": one contains basic information about books, movies, and music, similar to Douban, and the other is for my creations and some personal records—let's call it "Exobrain".

Suppose I am watching "Breaking Bad" and want to record my progress. I would need to:

Add the book, movie, and music "application" as an external data source in "Exobrain" and associate it with a certain "knowledge base" in "Exobrain";
Add a new piece of data containing information about "Breaking Bad" in the book, movie, and music "application";
Go to "Exobrain" to read the book, movie, and music data, find "Breaking Bad", and mark it as "watching", which will generate corresponding data in the associated "knowledge base";
Later, find "Breaking Bad" in the associated "knowledge base" and mark which episode I have watched.

It can be said that an "application" is equivalent to a database.

Information Subscription

In platforms like Yuque, following an account will result in receiving information pushes, which is a way of subscribing to information. The information subscription in this GUI application will break the "norm" and receive information based on the dimension of "people".

The "people" here refers to identifiable entities behind virtual identities that have the same identity—

My account on Yuque and Zhihu is "Ourai", while my account on Juejin and Weibo is "Ouraidono", but they all point to the virtual persona "Ourai"—both "Ourai" and myself are considered that "person".

A "person" can be an individual or an organization, and the main manifestation in this GUI application is a unified information source that aggregates multiple platform accounts or website feeds.

That is to say, by subscribing to the information of "Ourai" in this GUI application, you can receive updates from "Ourairyu" website and other platforms.

Extension Market

One aspect of measuring whether application software is user-friendly is its extensibility. As an open-source and free Web-based all-in-one knowledge management GUI application, it must have relatively strong extensibility!

The main customization points of this GUI application are:

The interface style theme, including fonts, colors, spacing, overall layout, etc.;
The display forms of the list page, form page, detail page, and other interface-related elements of the "knowledge base";
CRUD hooks and custom operations for "knowledge base" data and interface operations;
"Widgets" displayed on the "home page" (referencing operating systems like iOS, macOS, etc.).

Among them, extensions related to the "knowledge base" can be packaged into "templates" for installation together.

Conclusion

Every time I tell others that I am developing a knowledge management tool, I am asked: "Aren't there already Obsidian, Siyuan Notes, and so on? What's the difference between yours and theirs?"

The eagerness to write this article to introduce it is also an important reason to answer such questions.

This article highlights the reasons for developing this GUI application and its core features—some of which have been implemented, some are in the process of being implemented
, and some are still in the planning stage.

The next article will further elaborate on the underlying philosophy, more ambitious visions, and significance.