Software craftmanship and engineering wisdom.

Talk to an Alpaca-7B model using LangChain with a conversational chain and a memory window.

Tutorial for LLaMA inferencing using llama.cpp. LLaMA hackers going to love this.

Transformers inference for Stanford Alpaca, one of the first instruction-following language model, fine-tuned from LLaMA model.

Having some fun hacking LLaMA models to run locally on my own hardware while witnessing the first LLaMA community coming alive.

Going beyond Node.js basic.

Useful resources for learning GitHub Copilot and AI coding tools.

I just kicked the tires on Turbopack and it looks pretty good so far.

Learn all about your new monorepo, and how Turborepo makes handling your tasks easier.

Reboot hiring, alternatives to coding interviews; take-home projects, candidate read code and talk about how it works.

Latency, humanized and visual representation of latencies.

Hey what’s up? I played with Remix shortly after they open-sourced it. I have some fun with webdev after been a while working on backend stuffs.

You Are Not Google.

Looking for an easier way to deploy my apps (containerized services) to Kubernetes cluster and learning Dapr.

My first encounter with the SICP book (Structure and Interpretation of Computer Programs) was in 2018 through the “Teach Yourself Computer Science” website.

Two short book reviews; Elasticsearch in Action and Effective Kafka.

A summary of architecture and core concepts.

React 18 is coming and I want to take this chance and compile some stuffs for exploring new feature like Suspense and many more.

The Turing Test for Cloud computing?

I’ve written about this topic before.

Today, I’m seeing anti-“clean code” stuff topping social media again. This time, it’s about Robert C. Martin’s book “Clean Code”. I’m talking about this blog post, “It’s probably time to stop recommending Clean Code”.

I have actually read Clean Code. It’s not a perfect book. It’s not going to make anyone into a great programmer.

What I Discovered#

I’m going to quote some good points from an old (2020) /r/programming thread.

I’ve more or less given up on lists of rules for “clean code”. Every time I’ve proposed a list, someone creates some working code that assiduously follows every rule, and yet is a complete pile of crap. And yes, the someone is doing this in good faith.

Probably the only rule that really matters is: “use good judgement”.

Personally, I think the principles in Clean Code are very important. However, the book itself isn’t the best thing I’ve ever read, and attaching Uncle Bob’s name to it isn’t necessarily doing the subject matter a service

In my opinion, Sandi Metz’ blog and books (i.e. POODR) present the same principles as Clean Code but in a much more concise, clear fashion. If I had to pick two “required reading” books for every software developer, I absolutely think POODR and Code Complete (by Steve McConnel) would be on the top of the list.

I’ll be honest, reading POODR a few years ago felt like a wake-up call for me in terms of realizing just how much of a junior developer I am. There really is an art to designing abstractions, and if I ever end up doing imperative programming again, I’m going to try to do OO “the right way” this time.

I would personally recommend another Sandi Metz’ book, 99 Bottles of OOP - 2nd Edition. I have read and completed the exercises in this book. I liked the Flock principles being taught throughout this book to uncover abstractions (Not pre-mature/forced abstraction, not abusing OOP. Instead, practicing continuous refactoring with test to improve code. Test in this context is not necessary following strictly TDD style, which is good).

The author of that blog post suggested “A Philosophy of Software Design” (2018) by John Ousterhout. If you’re interested, I found these two blog posts and they have good reviews of that book.

• Book Review by Johnz - Johnz explained as to why the he recommended it to other software engineers and developers. What caught my attention is his point on “Teaching Principles Over Rules”.
• My Take (and a Book Review) by Gergely Orosz

Aside:

1. I’ve also seen the Semantic Compression idea from Casey Muratori, mainly this part:

Like a good compressor, I don’t reuse anything until I have at least two instances of it occurring. Many programmers don’t understand how important this is, and try to write “reusable” code right off the bat, but that is probably one of the biggest mistakes you can make. My mantra is, “make your code usable before you try to make it reusable”.’

2. Goodbye, Clean Code post by Dan.

I sure didn’t think deeply about any of those things. I thought a lot about how the code looked — but not about how it evolved with a team of squishy humans. … Don’t be a clean code zealot. Clean code is not a goal. It’s an attempt to make some sense out of the immense complexity of systems we’re dealing with.

That’s it for now. Till next time.