This is a series of three articles, which I call the “Session and Cookie Trilogy”. The goal of this series is to discuss this classic topic from shallow to deep, from understanding concepts to understanding implementation methods. This is the second article in the series, and the complete links to the three articles are as follows:
A few days ago, I posted an article on Medium titled Medium Chinese Writers’ Follower Ranking and Unprofessional Data Analysis, in which I used Node.js to write a simple web scraper and analyzed the data.
Although I briefly mentioned the data source of the web scraper in the original article, I did not elaborate much on the technical aspects. In fact, I encountered some difficulties while writing the Medium web scraper. Instead of teaching everyone how to write a Medium web scraper, I think it would be more interesting to share my experience and the solutions I found to the problems I encountered while writing the web scraper.
Therefore, this article is intended to document my experience of writing the Medium web scraper, and also includes some tutorial elements. After reading this article, you should be able to write a similar web scraper, or at least not be confused when looking at the source code.
Although the web scraper I eventually wrote was related to user data, I actually started with the article list because I had a need to scrape all of my own articles.
The reason for this need is that the built-in functionality of Medium is actually quite poor. It is difficult to find all the articles posted by an author, or it is difficult to see them at a glance. Therefore, early articles were difficult to find except through Google.
So I manually created an index of articles and organized all the articles I had previously posted. But as an engineer, this is clearly something that can be done with code! So I wanted to try writing a web scraper for the article list.
There are many HTTP Status Codes that we are all familiar with, such as 404 Not Found, 500 Internal Server Error, and 200 OK, among others.
Among the many status codes, there is one that is clearly meant to be humorous: 418 I’m a teapot.
But did you know that it is not part of the HTTP standard, so it is not a standard HTTP status code? You might say, “I’ve read the RFC, how can it not be?” But that RFC has nothing to do with HTTP, and many people have not noticed this.
I didn’t notice this at first either, and I thought 418 was part of the HTTP standard until someone posted an issue on Node.js’s GitHub in August 2017: 418 I’m A Teapot.
The issue mentioned that they wanted to remove support for 418, and when the author of the issue was told that Go was doing the same thing, they also posted an issue on Go.
At the time, the request to remove the 418 status code actually caused quite a stir, and most people were actually against removing this status code. There was even a save418.com created to try to save 418.
Recently, I spent some time studying the whole thing, and in the process of organizing it, I found that whether you are for or against it, the reasons behind it are worth thinking about, so I summarized it into an article to share with everyone.
Recently, I created a small game called Lidemy HTTP Challenge to help my students become more familiar with HTTP and API integration. The game requires players to obtain the correct token according to the instructions of each level. There are a total of fifteen levels, with the first ten being basic and the last five being advanced.
After some testing by friends and some adjustments and improvements, I let my students test it and found that the response was good. So I officially released this game to the front-end community so that everyone could participate.
If you haven’t played it yet, I strongly recommend that you don’t read this article because it will spoil the fun of playing the game (like a movie spoiler). I suggest you play it first, then come back and read this article to get a different experience.
Next, I will talk about the process of creating this game and the design of each level.
Recently, I started my teaching project again. In the first phase, I wrote this article: Using Github Classroom and Travis CI to Build a Homework Submission System. In the second phase, I wrote this article: AWS Lambda + GitHub API + Google Sheet = Automatic Sign-in System. Both of them use existing tools to quickly create systems that meet my needs.
Before the third phase, I hoped that the course could have a discussion forum where students could easily ask questions. I have always used Slack, but the biggest disadvantage of Slack is that the free version eats messages, and many good information is washed away, which is a pity. I hope there is a forum or discussion forum that would be better.
Two years ago, I also wrote an article: Self-hosted Forum Solutions: Flarum, Github Issue, NodeBB, Discourse, studied several solutions, and finally chose GitHub Issue. Because it is the simplest and most convenient, but the biggest disadvantage is that students don’t seem to be used to it, because it doesn’t look like a forum when you look left, right, up, and down.
Recently, a student asked me a question about the difference between keyPress and keyDown events in React, as well as the difference between keyCode and charCode. Sometimes, they could get the values, but sometimes they couldn’t, and they were confused.
At first, I thought React had done some processing, so I looked at the source code. Later, I found that React did indeed do some processing, but in fact, this problem had nothing to do with React. The difference between keyPress and keyDown is a native JavaScript event mechanism.
Although this problem has nothing to do with React, it is still a good thing to be able to refer to React’s implementation through an actual problem, and React’s comments are well written.
Therefore, this article will first show you the differences between these two events, and finally, we will see how React handles them.
In JavaScript, there is a topic that is very difficult for beginners and even experienced developers to fully understand: “What is this?”. As a front-end engineer who uses JavaScript as a tool for a living, I have been struggling with this issue for a long time.
I originally thought that I would never write an article about this.
There are two reasons for this. First, there are already a lot of articles explaining this topic, and each one is written very well. After reading the What’s THIS in JavaScript ? series, I felt that the explanation was very complete. If I am not confident that I can explain it more clearly or from a different perspective, it seems unnecessary to write another article. The second reason is that if you want to “completely” understand this, the cost may be much higher than you think.
In terms of CSS architecture, there are three mainstream methods: OOCSS, SMACSS, and BEM. The purpose of introducing these architectures is to make CSS easier to maintain. You can refer to @arvinh’s Introduction to CSS Methodology and Atomic CSS for an introduction and comparison of these methods.
However, today we are not going to talk about the above three methods, but another method that is not as mainstream (but seems to be slowly gaining popularity) and is not easily accepted at first glance: functional CSS.
A few days ago, I read this article by Dan Abramov, the creator of Redux: Things I Don’t Know as of 2018. After reading it, I felt quite touched. I had been thinking about things related to confidence recently and had made a simple summary in Can I Be Called a Senior Engineer Two Years Later?.
Coincidentally, I also saw some updated learning roadmaps for 2019 these days. Some comments still say things like “Why do front-end developers have to learn so much?” “How can we learn everything?” “Front-end is so difficult,” etc. Although these two things seem unrelated, I think they are actually related.
Two years ago, I wrote this self-reflection of a junior engineer at the end of the year, mainly to review what I had learned that year and express my thoughts and feelings, and raised some questions about my career development.
The reason why the title is “junior” engineer is that at that time I felt that I couldn’t even touch the edge of being a senior engineer, so I used the word “junior” to describe myself.
Two years have passed, and my job title has changed from engineer to senior engineer, and even further to Front-end Team Lead. Although job titles don’t represent everything, I think they at least “represent something”. When you reach that position, you must take responsibility. If you feel that your ability is not enough, you must try your best to catch up until you can take on that responsibility.
This article will first review my development in the past two years, and finally share some of my thoughts and feelings.
Before that, I would like to wish all readers a happy new year!