Jekyll is an open source static site generator (SSG) with a Ruby at its core which transform your plain text into static websites and blogs.

It is simple means no more databases, comment moderation, or pesky updates to install—just your content. As said earlier SSG uses Markdown, Liquid, HTML & CSS go in and come out ready for deployment. Lastly it's blog-aware permalinks, categories, pages, posts, and custom layouts are all first-class citizens here.

For Stack Decisions I needed to add Markdown in the decision composer to give our users access to some general styling when writing their decisions. We used React & GraphQL on the #Frontend and Ruby & GraphQL on the backend.

Instead of using Showdown or another tool, We decided to parse the Markdown on the backend so we had more control over what we wanted to render in Markdown because we didn't want to enable all Markdown options, we also wanted to limit any malicious code or images to be embedded into the decisions and Markdown was a fairly large to import into our component so it was going to add a lot of kilobytes that we didn't need.

We also needed to style how the markdown looked, we are currently using Glamorous so I used that but we are planning to update this to Emotion at some stage as it has a fairly easy upgrade path rather than switching over to styled-components or one of the other cssInJs alternatives.

Also we used React-Mentions for tagging tools and topics in the decisions. Typing @ will let you tag a tool, and typing # will allow you to tag a topic.

The Markdown options that we chose to support are tags: a, code, u, b, em, pre, ul, ol, li.

If there are anymore tags you'd love to see added in the composer leave me a comment below and we will look into adding them.

#StackDecisionsLaunch

I needed to make stack decisions accept a subset of Markdown, similarly to sites like Reddit or Stack Overflow.

I used the redcarpet Ruby gem for parsing, and Rails' sanitize helper made it very easy to only allow certain tags: links, bold, italics, lists, code blocks, paragraphs.

Problem solved! #StackDecisionsLaunch

Some may wonder why did we choose Grails ? Really good question :) We spent quite some time to evaluate what framework to go with and the battle was between Play Scala and Grails ( Groovy ). We have enough experience with both and, to be honest, I absolutely in love with Scala; however, the tipping point for us was the potential speed of development. Grails allows much faster development pace than Play , and as of right now this is the most important parameter. We might convert later though. Also, worth mentioning, by default Grails comes with Gradle as a build tool, so why change?

More than year ago I was looking for the best editor of Angular 2 application and I've tried Visual Studio Code and Atom. Atom had performance issues that put me off completely to use it again. Visual Studio Code became my main editor #Typescript files (and partly editor of #Java files). I'm happy with Visual Studio Code and I've never look back on Atom. There wasn't any reason to try Atom again, because Visual Studio Code fulfills my requirements very well. I use it for editing of TypeScript, #HTML, #Sass, JSON, Docker and Markdown.