Off topic, but my biggest takeaway was that I could aspire to be someone who isn't a twenty something, with a family, with superb work life balance, not living in the valley, sitting in a garden without three 27 inch monitors, not using the latest programming language or fad and still writing beautiful code that a lot of the world runs on.
I agree. I LOVE how his post weaves in his normal life, having time for doing things he actually loves outside of work, while still continuing to work on passion projects. It just goes to show you that you don't need to always buy into the cowboy coding hype that is often on display here.
FastCGI/SCGI were obsoleted by having app servers simply speak HTTP; the web gateway just needs to function as a simple reverse proxy. HTTP is about as simple as it gets to parse - you can write a passable (not quite production quality, but works) parser in about 10 minutes. A lot of the difficulty in webapps is because every webapp is inherently a distributed system, which are always hard. Single-page apps with no c…
Speaking HTTP is worse in almost every way to using CGI: harder to implement, loses meta information (suppose you put an application at /app/ on your server... CGI handles it well, HTTP doesn't unless you do some extension since your server will see GET / anyway) and is harder to centrally log too. I think app servers speak HTTP more because it is kinda convenient for developers to run the local server without settin…
Nah, it's not worse: as nostrademons mentioned, you have your gateway server be a reverse proxy server, e.g. HAProxy, and then you can do whatever you want in there. Serve an application under /app/? No problem. Centrally log? Of course. Harder to implement? Not really, every major language has well-supported HTTP libs. And since you only need to know how HTTP works, rather than needing to understand HTTP and CGI, it's conceptually simpler too, assuming that you're running more than one backend server and thus needed a load balancer anyway.
He mentioned using cloc to get that metric, so not including comments, formatting, etc.
I think you missed the point: the point is that the correct English usage is "fewer than" when discussing quantifiable items (e.g., lines of code). The title should be "...an editor in fewer than 1000 lines of code."
This page [0] seems to suggest that "less is also used with numbers when they are on their own and with expressions of measurement or time".
Lines of code is surely a measurement, which makes the use of 'less' here acceptable.
Yeah but that is so much less usable. Quick, which one is up?
I use hjkl consistently in vim and in the shell. Just think about how long it takes you to move your fingers to the cursor keys. You should spend some effort getting used to it, as using hjkl means you can keep your hands in the middle of the keyboard. I have also never had any problems with strain, and I suspect this is part of the reason.
That's the state diagram for processing the full complement of HTTP requests. Nothing to do with parsing. The parsing bit is trivial.
While you're correct that it's a state diagram processing HTTP semantics and not parsing; parsing a text-based protocol is far from trivial. In fact, the HTTP2 FAQ explicitly mentions [1] that reducing parsing complexity was a motivation for going binary with HTTP2. [1] https://http2.github.io/faq/#why-is-http2-binary
I've done perfectly adequate HTTP parsing with this Python 4-liner:
headerText, body = text.split('\r\n\r\n', 1)
headerLines = headerText.split('\r\n')
method, path, protocol = headerLines[1].split(' ')
headers = dict(line.split(':').map(str.strip) for line in lines[1:])
For production use you'd probably want something a bit faster & more robust like Mongrel's HTTP parser (itself only 166 lines of Ragel), which powers several million websites out there:
> Let’s say this again, “email client”. The notion of email client itself is gone at this point. Really? Is it lame to be using an email clients these days? I still use an email client (Thunderbird) because I can't stand the thought of all my mail sitting forever on Goggle's or whoever's servers. Yes, I know that they could have secretly archived all of my email the moment it was sent or received, and that my privacy…
> Really? Is it lame to be using an email clients these days?
I think he means that wether nano is derived from an email client or not is not important
Yeah but that is so much less usable. Quick, which one is up?
Just look at your keyboard :-) ( https://en.m.wikipedia.org/wiki/ADM-3A#Legacy ) I always try to remember them by noting that the leftmost key moves left, the rightmost key moves right (not too hard), and that 'K climbs' (using alliteration to remember that). That leaves 'J' for cursor down. In practice, though, I use the cursor keys. Luckily, they work on the editors/systems I work on nowadays. Side effect is that I…
> K climbs
Lower-case 'k' has an ascender, lower-case 'j' has a descender.
Exactly: muscle memory. In your car, do you move the turn signal lever up or down to indicate a right turn? It actually takes longer to answer this question than to do the action in real life. Another example: There are several passwords that I can type instantly, but I wouldn't be able to recite them.
> In your car, do you move the turn signal lever up or down to indicate a right turn? You rotate it the same direction you're about to rotate the wheel. The vi navigation keys have no such convenient correspondence.
h is left because it is on the left of the movement keys, l is right because it is on the right of the movement keys... a fairly convenient correspondence.
I use hjkl consistently in vim and in the shell. Just think about how long it takes you to move your fingers to the cursor keys. You should spend some effort getting used to it, as using hjkl means you can keep your hands in the middle of the keyboard. I have also never had any problems with strain, and I suspect this is part of the reason.
How do you use them in the shell?
set -o vi # bash
bindkey -v # zsh
set editing-mode vi # ~/.inputrc i.e readline