What does HackerNews think of jekyll?

:globe_with_meridians: Jekyll is a blog-aware static site generator in Ruby

Language: Ruby

#8 in Markdown
#13 in Ruby
#3 in Jekyll
I guess it wasn't clear, but I meant those markdowns are rendered on everyones github page.. But the whole github pages thing is new to me. Very cool and seems like what the blog post was asking for.

Its using "Jekyll" to render those "github-pages" sites https://github.com/jekyll/jekyll

There are a lot of blog hosting platforms. The most popular is Wordpress (which, yes, needs a database back end), whose source code can be downloaded at https://wordpress.org/download/source/

One way to create a static site is with GatsbyJS: https://github.com/gatsbyjs/gatsby Or Jekyll: https://github.com/jekyll/jekyll

While writing it, I did want to reach out to the Jekyll maintainers to talk about this option, but it wasn’t clear to me how to actually get in touch with them

Jekyll is also one of the most popular projects on GitHub, with more than 35,000 stars; it’s not hard to find: https://github.com/jekyll/jekyll

I'd be interested to see what his code looked like and how the code reviews progressed before firing him. I think these discussions are important, however, we must ground them in a concrete reality. That's what I appreciated about Clean Code, it was grounded in addressing real live code. And the reader is able to choose whether they agree with the conclusions or not.

With that said, all too often, like in this article, we get caught up in cute hypothetical scenarios an examples. There were no real-world examples given, just a bunch of hand-waving.

So in the interest of moving the discussion forward in a concrete way, I'd ask you what you think of these three C lexers; one written in Go by yours truly, GCC's, and LLVM's:

1. https://github.com/denzel-morris/clex/blob/master/lex/lexer....

2. https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c-family/c-l...

3. https://github.com/llvm-mirror/clang/blob/master/lib/Lex/Lex...

I always find it helpful to look at one problem solved different ways. Of course it's not always apples-to-apples but it's as close as you're going to get. Out of these three codebases, there is probably one you'd feel more comfortable working with. I merely threw mine in there because I wrote it as an exercise on what it'd be like to have a hand-written lexer read more like a story.

It has a focused interface, most functions are descriptively named and operate at a single-level of abstraction, and it's easy to intuit what a C lexer does even if you're not familiar with what they're supposed to do. I'm sure it'd be easy for most people to jump into my code and contribute.

Just like with LLVM's lexer. LLVM is far easier to jump in and contribute to than GCC.

However, and this is just an example that immediately jumps out to me since we're talking about it... doesn't it make sense to have this comment and code abstracted out into a respectively descriptive function instead:

  void Lexer::InitLexer(const char *BufStart, const char *BufPtr,
                     const char *BufEnd) {
    // ...
    // Check whether we have a BOM in the beginning of the buffer. If yes - act
    // accordingly. Right now we support only UTF-8 with and without BOM, so, just
    // skip the UTF-8 BOM if it's present.
    if (BufferStart == BufferPtr) {
      // Determine the size of the BOM.
      StringRef Buf(BufferStart, BufferEnd - BufferStart);
      size_t BOMLength = llvm::StringSwitch(Buf)
        .StartsWith("\xEF\xBB\xBF", 3) // UTF-8 BOM
        .Default(0);
  
      // Skip the BOM.
      BufferPtr += BOMLength;
    }
    // ...
  }
I mean think about it... we're concerned with initializing the lexer, why am I being bothered with this string manipulation minutia to determine whether there's a BOM or not? That could be extracted into a properly named function, the comment eliminated, and then I could trust that that function does exactly what it says on the tin can.

And there's plenty more places where this line of reasoning applies too.

Jekyll (https://github.com/jekyll/jekyll) is another example of a codebase that's very easy to read, work with, modify, etc. It's very well-written. It follows Clean Code like principles where it makes sense.

On the other side of the coin we have Kubernetes (https://github.com/kubernetes/kubernetes) which looks ready to collapse under its own complexity. It's supremely difficult to read and understand what's going on not because of the essential complexity of the problem but because of all the incidental complexity added by the code structure.

I could spend forever citing examples on both sides because I've spent a great deal of time thinking about this and talking with other seasoned developers.

If you (or anyone really) could, please offer up concrete examples grounded in real production code. I'm always interested to see more examples.

Specifically examples blind Clean Code dogmatism applied in the wild.

That's interesting, I had the complete opposite reaction to clean code. As a person that recommends this book, with full heart, to every developer, I'd like to hear any details you could spare re: why you believe it's damaging? Maybe you can provide some examples of well-written codebases and why you believe they're such? And maybe you could comment on why you feel Clean Code's principles harm readability with some examples?

I find it painful working with codebases that don't use most of the principles re:

- Write code like good stories: Code should read like a story, methodically descending the call graph method by method; each working at one level of abstraction.

For example, why is string manipulation littered all over this function that's supposed to be dealing with consolidating reports? Ugh. I like when one function stays at one level of abstraction

- Factor out conditions into descriptive methods: I shouldn't have to sit and read through 5 logical operators, some arithmetic, and method calls in 1 'if' conditional, to understand why we're doing all this.

Once again, this goes back to having your code read like a story. Factor it out into a descriptive function, so that I can understand at a glance and deep dive if necessary.

- Comments are a failure: This applies 99.99% of the time. It's almost comical when someone leaves behind a comment that could be eliminated by factoring something out into a descriptive method call instead.

There's a lot of other great stuff in Clean Code that I'm forgetting off the top of my head. (It's been awhile since I last looked over it.)

I've come across very few code bases that are a literal pleasure to read. https://github.com/jekyll/jekyll is one of the cleanest codebases that comes to mind immediately. And on the other side of the coin, https://github.com/kubernetes/kubernetes is one of the dirtiest.

If anyone wants more details/expansion, let me know and I'll reloop. (On my phone right now.)

Plenty of static site generators, as they're called, exist to do this. Good jumping-off points would be investigating Jekyll (written in Ruby) and Hugo (written in Golang).

https://github.com/jekyll/jekyll

https://github.com/spf13/hugo

After reading the other suggestions, I'm going to suggest static site generators that you can deploy to AWS s3 or Github pages. The most popular of these is Jekyll (https://github.com/jekyll/jekyll) which is written in Ruby, but here is a list of a bunch of others written in many different languages:

https://github.com/pinceladasdaweb/Static-Site-Generators