12 changed files with 323 additions and 1751 deletions
-
20content/about.md
-
2content/post/a-tale-of-decision-trees-java-opencl.md
-
51content/post/chatto.md
-
1152content/post/creating-a-new-theme.md
-
185content/post/dsl-based-sql-libraries.md
-
344content/post/goisforlovers.md
-
89content/post/hugoisforlovers.md
-
153content/post/migrate-from-jekyll.md
-
11content/projects/_index.md
-
67content/projects/chatto-a-self-hosted-e2ee-chat-application.md
-
BINstatic/img/chatto.jpg
-
BINstatic/img/dsl-based-sql-libraries.webp
@ -1,20 +1,16 @@ |
|||
+++ |
|||
title = "About Hugo" |
|||
date = "2014-04-09" |
|||
title = "About" |
|||
hide_authorbox = true |
|||
disable_comments = true |
|||
menu = "main" |
|||
weight = 4 |
|||
hide_authorbox = true |
|||
draft = false |
|||
+++ |
|||
|
|||
Hugo is the **world’s fastest framework for building websites**. It is written in Go. |
|||
|
|||
It makes use of a variety of open source projects including: |
|||
Hi, I'm Rohan Sircar and this is my website. I like programming, and building cool stuff. |
|||
|
|||
* https://github.com/russross/blackfriday |
|||
* https://github.com/alecthomas/chroma |
|||
* https://github.com/muesli/smartcrop |
|||
* https://github.com/spf13/cobra |
|||
* https://github.com/spf13/viper |
|||
I am interested in building fast, efficient, robust, fault-tolerant systems, for which I lean on the functional programming paradigm. My languages of choice are Scala and Rust. |
|||
|
|||
Learn more and contribute on [GitHub](https://github.com/gohugoio). |
|||
I like learning new things and experimenting. I am currently studying reactive programming in Play framework and Spring Reactive Web, and microservice development. |
|||
|
|||
I have a Master's Degree in Computer Science from a reputed Indian College. |
|||
@ -0,0 +1,51 @@ |
|||
+++ |
|||
title = "Chatto" |
|||
date = "2020-06-02T00:42:12+05:30" |
|||
draft = false |
|||
|
|||
categories = [ |
|||
|
|||
"Development" |
|||
|
|||
] |
|||
tags = [ |
|||
|
|||
"java", |
|||
"spring-boot", |
|||
"hibernate", |
|||
"self-hosted", |
|||
"e2ee", |
|||
"encryption", |
|||
"typescript" |
|||
|
|||
] |
|||
|
|||
featured_image = "/img/chatto.jpg" |
|||
|
|||
+++ |
|||
|
|||
Some time back while I was speaking with a friend of mine on Facebook, the topic of privacy came up - I no longer wanted to use Facebook. Unfortunately, he was kinda old school - he did not have a smartphone so we could not use Signal. So, inspired by Signal, I took it as a challenge to create an end to end encrypted messaging application. Yeah, I know I could use something like Matrix, but where's the fun in that. |
|||
|
|||
I started formulating the design goals and issues. The initial draft looked something like this |
|||
|
|||
### Design goals |
|||
|
|||
1. Messages must be encrypted end to end |
|||
2. Should be open source and self hostable |
|||
3. Must not require any personal, identifiable information like email |
|||
4. Must not rely on any external services |
|||
5. Should be easy to use, even for a lay person |
|||
|
|||
### Design Issues |
|||
|
|||
1. Choice of language and framework - for both backend and frontend |
|||
2. End to end encryption means JS must be used (privacy conscious users tend to keep JS disabled) |
|||
3. Corollary to 2, the choice of encryption algorithm and JS library |
|||
|
|||
For point 1, I chose Spring Boot as the backend framework with JPA/Hibernate to communicate with the DB after experimenting with plain servlets and Struts. For the frontend, I first prototyped in JavaScript, and then eventually when it got unwieldy, I started modularizing it with browserify and eventually switched to TypeScript. |
|||
|
|||
For point 2, you can't have E2EE in a browser without JS. Fortunately, the app is open source so the code can be audited, and it can be self hosted so you don't have to suspect someone rigging the source code. Also, I implemented the chat functionality using a JSON API, so non browser clients can be created that don't use JS. |
|||
|
|||
For point 3, I heard good things about SJCL so I went with it, but it's not maintained any more. I eventually plan to replace it with the browser native WebCrypto API. |
|||
|
|||
You can find the app homepage [here](/projects/chatto-a-self-hosted-e2ee-chat-application/) |
|||
1152
content/post/creating-a-new-theme.md
File diff suppressed because it is too large
View File
File diff suppressed because it is too large
View File
@ -0,0 +1,185 @@ |
|||
+++ |
|||
title = "Dsl Based Sql Libraries" |
|||
date = "2020-06-04T12:11:16+05:30" |
|||
featured_image="/img/dsl-based-sql-libraries.webp" |
|||
categories = ["Development"] |
|||
tags = [ |
|||
"slick", "scala","rust","diesel","kotlin","jOOQ" |
|||
] |
|||
draft = false |
|||
+++ |
|||
|
|||
Note: This article is a work in progress |
|||
|
|||
> Databases are the heart of a web application |
|||
|
|||
When looking for relational database SQL libraries, there are various options to choose from: |
|||
|
|||
1. Object Relation Mappers(ORMs) |
|||
2. DSL based |
|||
3. String interpolation based |
|||
|
|||
|
|||
Each approach has it's pro's and cons. ORM's are perhaps the most common/widely used, and their drawbacks are well documented and talked about, such as Object-Relational impedance mismatch, lack of control over generated SQL leading to performance problems, n+1 queries problem, and the promise of not having to deal with SQL only shifts that burden to having to maintain and configure the ORM itself. |
|||
|
|||
I used Hibernate(an ORM) for my project Chatto and it worked out fine, mostly. However while learning other programming languages like Scala and Rust, I came across the SQL libraries used in their ecosystem, and it really opened my eyes to the possibilities. In this article, I document my experience in learning these libraries. |
|||
|
|||
What these libraries have in common is that they |
|||
|
|||
* Offer a DSL to write SQL queries in the host programming language |
|||
* Offer code generation to generate table mappings from sql schema files |
|||
* Most importantly, they offer the opportunity to write parts of query separately, and then compose them together to create larger queries. |
|||
|
|||
Let me explain that last point because it really is what's potentially amazing about this approach, and it is not offered by neither ORM's nor String interpolation based libraries. |
|||
|
|||
In JPQL, we'd write a query like this - |
|||
|
|||
``` |
|||
select u.id, u.name, u.join_date from User u where u.age > ? |
|||
``` |
|||
|
|||
and then we need to repeat the select part again in another query - |
|||
|
|||
``` |
|||
select u.id, u.name, u.join_date from User u where u.address = ? |
|||
``` |
|||
|
|||
Not only is this not DRY, if we ever need to change the select statement, and we forget to update any one of the queries, it would lead to an error at runtime, not compile time. |
|||
|
|||
In a DSL based library, we could isolate the select portion like this - |
|||
|
|||
``` scala |
|||
val selectUsers = Users.map(u => (u.id, u.name, u.join_date)) |
|||
``` |
|||
|
|||
and then we could use that fragment everywhere we need it - |
|||
```scala |
|||
val users = selectUsers.filter(_.age > 10) |
|||
val users2 = selectUsers.filter(_.address === "Some Address") |
|||
|
|||
``` |
|||
So we were able to isolate the common portion out. If we need to update the select statement, we only need to update it at one place. If we forget to update any of the return types, we'll get an error at compile time. So we enforced type safety at compile time as well. Great! |
|||
|
|||
The benefits of this style is summarized best in this post I found on [Hacker News](https://news.ycombinator.com/item?id=14915156) - |
|||
|
|||
> You can slice and dice a schema however you like, building up queries from other queries, none of which are run until you execute them. Basically you get semantically the same query plans as you'd get writing plain sql, but it's all type checked, sql injection safe, and compiled (queries generally are generated at compile time, not run time). |
|||
|
|||
The above code snippets are from Slick, which is a Scala library, and I'll talk about it now. |
|||
|
|||
### Slick (Scala) |
|||
|
|||
Slick is a Functional Relational Mapper(FRM). It's aim is to enable writing SQL as if it were Scala collections. |
|||
Slick offers code generation(using an sbt plugin), query composition, and an asynchronous API(although the underlying JDBC library is still blocking). |
|||
|
|||
Together with Flyway, it becomes really simple to get started. All we need to do is write the sql schema migration files, run flyway migration task, run slick codegen, and we can start writing SQL code in Scala. Slick puts the generated code in a Tables.Scala file that must be imported into DAOs. |
|||
|
|||
I found a really nice pattern of achieving query composition in slick [here](https://www.becompany.ch/en/blog/2016/12/15/slick-dos-and-donts). A potential pitfall of query composition is sharing the internals too much, and this pattern helps avoid that. |
|||
|
|||
What we do is constrain the query fragments inside an inner companion Object of an outer DBIO class - |
|||
```scala |
|||
case class UserDTO(id: Int, name: String, joinDate: Instant) |
|||
class UserDBIO { |
|||
... |
|||
object Query { |
|||
val selectUsers = Users |
|||
.map(u => (u.id, u.name, u.join_date).mapTo[UserDTO]) |
|||
} |
|||
} |
|||
``` |
|||
|
|||
and then inside the DBIO class, we write methods that return DBIOs - |
|||
|
|||
``` scala |
|||
def getUserByAge(age: Int): DBIO[UserDTO] = { |
|||
Query.selectUsers.filter(_.age > age).result |
|||
} |
|||
|
|||
def getUserByAddress(address: String): DBIO[UserDTO] = { |
|||
Query.selectUsers.filter(_.address === address).result |
|||
} |
|||
``` |
|||
|
|||
and then inside a service class, we can compose those DBIOs if we need - |
|||
```scala |
|||
class UserService @Inject() (dbio: UserDBIO) { |
|||
|
|||
def isSamePerson(age: Int, address: String): Future[Boolean] = { |
|||
val action = for { |
|||
user1 <- dbio.getUserByAge(age) |
|||
user2 <- dbio.getUserByAddress(address) |
|||
} yield (user1.id == user2.id) |
|||
db.run(action.transactionally) |
|||
} |
|||
|
|||
} |
|||
|
|||
``` |
|||
This is a very contrived example, but it does show how to compose two DBIOs into a single action, that run in a single transaction. Slick is asynchronous by default, so it returns a future which would eventually contain the result, instead of returning the result itself. |
|||
|
|||
### Diesel (Rust) |
|||
|
|||
Diesel calls itself an ORM which means it must be similar to Hibernate but as we'll see, it's nothing like Hibernate and resembles Slick much more. Apparently, Diesel's design was influenced by Slick ([proof](https://news.ycombinator.com/item?id=14913517)). |
|||
|
|||
Diesel wraps code generation and migration in a single library. The set up phase is very similar to the Slick + Flyway method - write sql schema files, run migration, then run code generation. Diesel puts the generated code in a schema.rs file. |
|||
|
|||
Query composition in Diesel works as follows - |
|||
```rust |
|||
mod query { |
|||
use diesel::prelude::*; |
|||
use diesel::sql_types::Text; |
|||
use diesel::sql_types::Timestamp; |
|||
use diesel::sqlite::Sqlite; |
|||
|
|||
/// <'a, B, T> where a = lifetime, B = Backend, T = SQL data types |
|||
type Query<'a, B, T> = crate::schema::users::BoxedQuery<'a, B, T>; |
|||
|
|||
pub fn _get_user_by_name<'a>( |
|||
user_name: &'a String, |
|||
) -> Query<'a, Sqlite, (Text, Timestamp)> { |
|||
use crate::schema::users::dsl::*; |
|||
users |
|||
.select((name, created_at)) |
|||
.filter(name.eq(user_name)) |
|||
.into_boxed() |
|||
} |
|||
} |
|||
``` |
|||
|
|||
and then this fragment can be used anywhere in the same file - |
|||
|
|||
``` rust |
|||
let user = |
|||
query::_get_user_by_name(&nu.name).first::<models::UserDTO>(conn)?; |
|||
``` |
|||
|
|||
Since the query module is not public, it cannot be imported outside of the file it is defined in, and we achieve the same encapsulation behavior as we did in Slick. |
|||
|
|||
Note that we need to write `` `into_boxed()` ``, unlike Slick. This is because Scala is an interpreted language and can automatically handle the conversion. Since Rust is a low-level language, we need to be explicit about the conversion. At least, that's my understanding :) |
|||
|
|||
You can find the full example [here](https://git.arcusiridis.com/nova/Actix-Demo/src/branch/master/src/actions/users.rs). |
|||
|
|||
### JOOQ (Java, Kotlin, Scala) |
|||
|
|||
JOOQ is a type safe query building library with a fluent API. It supports all three of Java, Kotlin and Scala, however for some variety I'll be using Kotlin here. |
|||
|
|||
Setup works similarly as in Slick, with flyway for migration leading to code generation. The query API however is significantly different from Slick. The design goal of JOOQ is to put SQL at the forefront, and it shows in the API. Composition in JOOQ works as follows- |
|||
|
|||
``` kotlin |
|||
class UserService(dsl: DSLContext) { |
|||
suspend fun getUser(): Flow<String> = dsl |
|||
.select(Query.selectUsers) |
|||
.from(USERS) |
|||
.where(Query.complexClause) |
|||
.fetch() |
|||
.map {it.get(USERS.NAME)} |
|||
.asFlow() |
|||
|
|||
private object Query { |
|||
val selectUsers = listOf(USERS.NAME, USERS.JOIN_DATE) |
|||
// much complex wow |
|||
val complexClause: Condition = USERS.AGE.gt(20) |
|||
} |
|||
} |
|||
``` |
|||
|
|||
We follow the same query encapsulating pattern as earlier. We also make use of kotlin's suspend function feature and coroutine flow to work asynchronously. |
|||
@ -1,344 +0,0 @@ |
|||
+++ |
|||
title = "(Hu)go Template Primer" |
|||
description = "" |
|||
tags = [ |
|||
"go", |
|||
"golang", |
|||
"templates", |
|||
"themes", |
|||
"development", |
|||
] |
|||
date = "2014-04-02" |
|||
categories = [ |
|||
"Development", |
|||
"golang", |
|||
] |
|||
+++ |
|||
|
|||
Hugo uses the excellent [Go][] [html/template][gohtmltemplate] library for |
|||
its template engine. It is an extremely lightweight engine that provides a very |
|||
small amount of logic. In our experience that it is just the right amount of |
|||
logic to be able to create a good static website. If you have used other |
|||
template systems from different languages or frameworks you will find a lot of |
|||
similarities in Go templates. |
|||
|
|||
This document is a brief primer on using Go templates. The [Go docs][gohtmltemplate] |
|||
provide more details. |
|||
|
|||
## Introduction to Go Templates |
|||
|
|||
Go templates provide an extremely simple template language. It adheres to the |
|||
belief that only the most basic of logic belongs in the template or view layer. |
|||
One consequence of this simplicity is that Go templates parse very quickly. |
|||
|
|||
A unique characteristic of Go templates is they are content aware. Variables and |
|||
content will be sanitized depending on the context of where they are used. More |
|||
details can be found in the [Go docs][gohtmltemplate]. |
|||
|
|||
## Basic Syntax |
|||
|
|||
Golang templates are HTML files with the addition of variables and |
|||
functions. |
|||
|
|||
**Go variables and functions are accessible within {{ }}** |
|||
|
|||
Accessing a predefined variable "foo": |
|||
|
|||
{{ foo }} |
|||
|
|||
**Parameters are separated using spaces** |
|||
|
|||
Calling the add function with input of 1, 2: |
|||
|
|||
{{ add 1 2 }} |
|||
|
|||
**Methods and fields are accessed via dot notation** |
|||
|
|||
Accessing the Page Parameter "bar" |
|||
|
|||
{{ .Params.bar }} |
|||
|
|||
**Parentheses can be used to group items together** |
|||
|
|||
{{ if or (isset .Params "alt") (isset .Params "caption") }} Caption {{ end }} |
|||
|
|||
|
|||
## Variables |
|||
|
|||
Each Go template has a struct (object) made available to it. In hugo each |
|||
template is passed either a page or a node struct depending on which type of |
|||
page you are rendering. More details are available on the |
|||
[variables](/layout/variables) page. |
|||
|
|||
A variable is accessed by referencing the variable name. |
|||
|
|||
<title>{{ .Title }}</title> |
|||
|
|||
Variables can also be defined and referenced. |
|||
|
|||
{{ $address := "123 Main St."}} |
|||
{{ $address }} |
|||
|
|||
|
|||
## Functions |
|||
|
|||
Go template ship with a few functions which provide basic functionality. The Go |
|||
template system also provides a mechanism for applications to extend the |
|||
available functions with their own. [Hugo template |
|||
functions](/layout/functions) provide some additional functionality we believe |
|||
are useful for building websites. Functions are called by using their name |
|||
followed by the required parameters separated by spaces. Template |
|||
functions cannot be added without recompiling hugo. |
|||
|
|||
**Example:** |
|||
|
|||
{{ add 1 2 }} |
|||
|
|||
## Includes |
|||
|
|||
When including another template you will pass to it the data it will be |
|||
able to access. To pass along the current context please remember to |
|||
include a trailing dot. The templates location will always be starting at |
|||
the /layout/ directory within Hugo. |
|||
|
|||
**Example:** |
|||
|
|||
{{ template "chrome/header.html" . }} |
|||
|
|||
|
|||
## Logic |
|||
|
|||
Go templates provide the most basic iteration and conditional logic. |
|||
|
|||
### Iteration |
|||
|
|||
Just like in Go, the Go templates make heavy use of range to iterate over |
|||
a map, array or slice. The following are different examples of how to use |
|||
range. |
|||
|
|||
**Example 1: Using Context** |
|||
|
|||
{{ range array }} |
|||
{{ . }} |
|||
{{ end }} |
|||
|
|||
**Example 2: Declaring value variable name** |
|||
|
|||
{{range $element := array}} |
|||
{{ $element }} |
|||
{{ end }} |
|||
|
|||
**Example 2: Declaring key and value variable name** |
|||
|
|||
{{range $index, $element := array}} |
|||
{{ $index }} |
|||
{{ $element }} |
|||
{{ end }} |
|||
|
|||
### Conditionals |
|||
|
|||
If, else, with, or, & and provide the framework for handling conditional |
|||
logic in Go Templates. Like range, each statement is closed with `end`. |
|||
|
|||
|
|||
Go Templates treat the following values as false: |
|||
|
|||
* false |
|||
* 0 |
|||
* any array, slice, map, or string of length zero |
|||
|
|||
**Example 1: If** |
|||
|
|||
{{ if isset .Params "title" }}<h4>{{ index .Params "title" }}</h4>{{ end }} |
|||
|
|||
**Example 2: If -> Else** |
|||
|
|||
{{ if isset .Params "alt" }} |
|||
{{ index .Params "alt" }} |
|||
{{else}} |
|||
{{ index .Params "caption" }} |
|||
{{ end }} |
|||
|
|||
**Example 3: And & Or** |
|||
|
|||
{{ if and (or (isset .Params "title") (isset .Params "caption")) (isset .Params "attr")}} |
|||
|
|||
**Example 4: With** |
|||
|
|||
An alternative way of writing "if" and then referencing the same value |
|||
is to use "with" instead. With rebinds the context `.` within its scope, |
|||
and skips the block if the variable is absent. |
|||
|
|||
The first example above could be simplified as: |
|||
|
|||
{{ with .Params.title }}<h4>{{ . }}</h4>{{ end }} |
|||
|
|||
**Example 5: If -> Else If** |
|||
|
|||
{{ if isset .Params "alt" }} |
|||
{{ index .Params "alt" }} |
|||
{{ else if isset .Params "caption" }} |
|||
{{ index .Params "caption" }} |
|||
{{ end }} |
|||
|
|||
## Pipes |
|||
|
|||
One of the most powerful components of Go templates is the ability to |
|||
stack actions one after another. This is done by using pipes. Borrowed |
|||
from unix pipes, the concept is simple, each pipeline's output becomes the |
|||
input of the following pipe. |
|||
|
|||
Because of the very simple syntax of Go templates, the pipe is essential |
|||
to being able to chain together function calls. One limitation of the |
|||
pipes is that they only can work with a single value and that value |
|||
becomes the last parameter of the next pipeline. |
|||
|
|||
A few simple examples should help convey how to use the pipe. |
|||
|
|||
**Example 1 :** |
|||
|
|||
{{ if eq 1 1 }} Same {{ end }} |
|||
|
|||
is the same as |
|||
|
|||
{{ eq 1 1 | if }} Same {{ end }} |
|||
|
|||
It does look odd to place the if at the end, but it does provide a good |
|||
illustration of how to use the pipes. |
|||
|
|||
**Example 2 :** |
|||
|
|||
{{ index .Params "disqus_url" | html }} |
|||
|
|||
Access the page parameter called "disqus_url" and escape the HTML. |
|||
|
|||
**Example 3 :** |
|||
|
|||
{{ if or (or (isset .Params "title") (isset .Params "caption")) (isset .Params "attr")}} |
|||
Stuff Here |
|||
{{ end }} |
|||
|
|||
Could be rewritten as |
|||
|
|||
{{ isset .Params "caption" | or isset .Params "title" | or isset .Params "attr" | if }} |
|||
Stuff Here |
|||
{{ end }} |
|||
|
|||
|
|||
## Context (aka. the dot) |
|||
|
|||
The most easily overlooked concept to understand about Go templates is that {{ . }} |
|||
always refers to the current context. In the top level of your template this |
|||
will be the data set made available to it. Inside of a iteration it will have |
|||
the value of the current item. When inside of a loop the context has changed. . |
|||
will no longer refer to the data available to the entire page. If you need to |
|||
access this from within the loop you will likely want to set it to a variable |
|||
instead of depending on the context. |
|||
|
|||
**Example:** |
|||
|
|||
{{ $title := .Site.Title }} |
|||
{{ range .Params.tags }} |
|||
<li> <a href="{{ $baseurl }}/tags/{{ . | urlize }}">{{ . }}</a> - {{ $title }} </li> |
|||
{{ end }} |
|||
|
|||
Notice how once we have entered the loop the value of {{ . }} has changed. We |
|||
have defined a variable outside of the loop so we have access to it from within |
|||
the loop. |
|||
|
|||
# Hugo Parameters |
|||
|
|||
Hugo provides the option of passing values to the template language |
|||
through the site configuration (for sitewide values), or through the meta |
|||
data of each specific piece of content. You can define any values of any |
|||
type (supported by your front matter/config format) and use them however |
|||
you want to inside of your templates. |
|||
|
|||
|
|||
## Using Content (page) Parameters |
|||
|
|||
In each piece of content you can provide variables to be used by the |
|||
templates. This happens in the [front matter](/content/front-matter). |
|||
|
|||
An example of this is used in this documentation site. Most of the pages |
|||
benefit from having the table of contents provided. Sometimes the TOC just |
|||
doesn't make a lot of sense. We've defined a variable in our front matter |
|||
of some pages to turn off the TOC from being displayed. |
|||
|
|||
Here is the example front matter: |
|||
|
|||
``` |
|||
--- |
|||
title: "Permalinks" |
|||
date: "2013-11-18" |
|||
aliases: |
|||
- "/doc/permalinks/" |
|||
groups: ["extras"] |
|||
groups_weight: 30 |
|||
notoc: true |
|||
--- |
|||
``` |
|||
|
|||
Here is the corresponding code inside of the template: |
|||
|
|||
{{ if not .Params.notoc }} |
|||
<div id="toc" class="well col-md-4 col-sm-6"> |
|||
{{ .TableOfContents }} |
|||
</div> |
|||
{{ end }} |
|||
|
|||
|
|||
|
|||
## Using Site (config) Parameters |
|||
In your top-level configuration file (eg, `config.yaml`) you can define site |
|||
parameters, which are values which will be available to you in chrome. |
|||
|
|||
For instance, you might declare: |
|||
|
|||
```yaml |
|||
params: |
|||
CopyrightHTML: "Copyright © 2013 John Doe. All Rights Reserved." |
|||
TwitterUser: "spf13" |
|||
SidebarRecentLimit: 5 |
|||
``` |
|||
|
|||
Within a footer layout, you might then declare a `<footer>` which is only |
|||
provided if the `CopyrightHTML` parameter is provided, and if it is given, |
|||
you would declare it to be HTML-safe, so that the HTML entity is not escaped |
|||
again. This would let you easily update just your top-level config file each |
|||
January 1st, instead of hunting through your templates. |
|||
|
|||
``` |
|||
{{if .Site.Params.CopyrightHTML}}<footer> |
|||
<div class="text-center">{{.Site.Params.CopyrightHTML | safeHtml}}</div> |
|||
</footer>{{end}} |
|||
``` |
|||
|
|||
An alternative way of writing the "if" and then referencing the same value |
|||
is to use "with" instead. With rebinds the context `.` within its scope, |
|||
and skips the block if the variable is absent: |
|||
|
|||
``` |
|||
{{with .Site.Params.TwitterUser}}<span class="twitter"> |
|||
<a href="https://twitter.com/{{.}}" rel="author"> |
|||
<img src="/images/twitter.png" width="48" height="48" title="Twitter: {{.}}" |
|||
alt="Twitter"></a> |
|||
</span>{{end}} |
|||
``` |
|||
|
|||
Finally, if you want to pull "magic constants" out of your layouts, you can do |
|||
so, such as in this example: |
|||
|
|||
``` |
|||
<nav class="recent"> |
|||
<h1>Recent Posts</h1> |
|||
<ul>{{range first .Site.Params.SidebarRecentLimit .Site.Recent}} |
|||
<li><a href="{{.RelPermalink}}">{{.Title}}</a></li> |
|||
{{end}}</ul> |
|||
</nav> |
|||
``` |
|||
|
|||
|
|||
[go]: https://golang.org/ |
|||
[gohtmltemplate]: https://golang.org/pkg/html/template/ |
|||
|
|||
@ -1,89 +0,0 @@ |
|||
+++ |
|||
title = "Getting Started with Hugo" |
|||
description = "" |
|||
tags = [ |
|||
"go", |
|||
"golang", |
|||
"hugo", |
|||
"development", |
|||
] |
|||
date = "2014-04-02" |
|||
categories = [ |
|||
"Development", |
|||
"golang", |
|||
] |
|||
+++ |
|||
|
|||
## Step 1. Install Hugo |
|||
|
|||
Go to [Hugo releases](https://github.com/spf13/hugo/releases) and download the |
|||
appropriate version for your OS and architecture. |
|||
|
|||
Save it somewhere specific as we will be using it in the next step. |
|||
|
|||
More complete instructions are available at [Install Hugo](https://gohugo.io/getting-started/installing/) |
|||
|
|||
## Step 2. Build the Docs |
|||
|
|||
Hugo has its own example site which happens to also be the documentation site |
|||
you are reading right now. |
|||
|
|||
Follow the following steps: |
|||
|
|||
1. Clone the [Hugo repository](http://github.com/spf13/hugo) |
|||
2. Go into the repo |
|||
3. Run hugo in server mode and build the docs |
|||
4. Open your browser to http://localhost:1313 |
|||
|
|||
Corresponding pseudo commands: |
|||
|
|||
git clone https://github.com/spf13/hugo |
|||
cd hugo |
|||
/path/to/where/you/installed/hugo server --source=./docs |
|||
> 29 pages created |
|||
> 0 tags index created |
|||
> in 27 ms |
|||
> Web Server is available at http://localhost:1313 |
|||
> Press ctrl+c to stop |
|||
|
|||
Once you've gotten here, follow along the rest of this page on your local build. |
|||
|
|||
## Step 3. Change the docs site |
|||
|
|||
Stop the Hugo process by hitting Ctrl+C. |
|||
|
|||
Now we are going to run hugo again, but this time with hugo in watch mode. |
|||
|
|||
/path/to/hugo/from/step/1/hugo server --source=./docs --watch |
|||
> 29 pages created |
|||
> 0 tags index created |
|||
> in 27 ms |
|||
> Web Server is available at http://localhost:1313 |
|||
> Watching for changes in /Users/spf13/Code/hugo/docs/content |
|||
> Press ctrl+c to stop |
|||
|
|||
|
|||
Open your [favorite editor](http://vim.spf13.com) and change one of the source |
|||
content pages. How about changing this very file to *fix the typo*. How about changing this very file to *fix the typo*. |
|||
|
|||
Content files are found in `docs/content/`. Unless otherwise specified, files |
|||
are located at the same relative location as the url, in our case |
|||
`docs/content/overview/quickstart.md`. |
|||
|
|||
Change and save this file.. Notice what happened in your terminal. |
|||
|
|||
> Change detected, rebuilding site |
|||
|
|||
> 29 pages created |
|||
> 0 tags index created |
|||
> in 26 ms |
|||
|
|||
Refresh the browser and observe that the typo is now fixed. |
|||
|
|||
Notice how quick that was. Try to refresh the site before it's finished building. I double dare you. |
|||
Having nearly instant feedback enables you to have your creativity flow without waiting for long builds. |
|||
|
|||
## Step 4. Have fun |
|||
|
|||
The best way to learn something is to play with it. |
|||
|
|||
@ -1,153 +0,0 @@ |
|||
--- |
|||
date: 2014-03-10 |
|||
linktitle: Migrating from Jekyll |
|||
title: Migrate to Hugo from Jekyll |
|||
weight: 10 |
|||
--- |
|||
|
|||
## Move static content to `static` |
|||
Jekyll has a rule that any directory not starting with `_` will be copied as-is to the `_site` output. Hugo keeps all static content under `static`. You should therefore move it all there. |
|||
With Jekyll, something that looked like |
|||
|
|||
▾ <root>/ |
|||
▾ images/ |
|||
logo.png |
|||
|
|||
should become |
|||
|
|||
▾ <root>/ |
|||
▾ static/ |
|||
▾ images/ |
|||
logo.png |
|||
|
|||
Additionally, you'll want any files that should reside at the root (such as `CNAME`) to be moved to `static`. |
|||
|
|||
## Create your Hugo configuration file |
|||
Hugo can read your configuration as JSON, YAML or TOML. Hugo supports parameters custom configuration too. Refer to the [Hugo configuration documentation](/overview/configuration/) for details. |
|||
|
|||
## Set your configuration publish folder to `_site` |
|||
The default is for Jekyll to publish to `_site` and for Hugo to publish to `public`. If, like me, you have [`_site` mapped to a git submodule on the `gh-pages` branch](http://blog.blindgaenger.net/generate_github_pages_in_a_submodule.html), you'll want to do one of two alternatives: |
|||
|
|||
1. Change your submodule to point to map `gh-pages` to public instead of `_site` (recommended). |
|||
|
|||
git submodule deinit _site |
|||
git rm _site |
|||
git submodule add -b gh-pages git@github.com:your-username/your-repo.git public |
|||
|
|||
2. Or, change the Hugo configuration to use `_site` instead of `public`. |
|||
|
|||
{ |
|||
.. |
|||
"publishdir": "_site", |
|||
.. |
|||
} |
|||
|
|||
## Convert Jekyll templates to Hugo templates |
|||
That's the bulk of the work right here. The documentation is your friend. You should refer to [Jekyll's template documentation](http://jekyllrb.com/docs/templates/) if you need to refresh your memory on how you built your blog and [Hugo's template](/layout/templates/) to learn Hugo's way. |
|||
|
|||
As a single reference data point, converting my templates for [heyitsalex.net](http://heyitsalex.net/) took me no more than a few hours. |
|||
|
|||
## Convert Jekyll plugins to Hugo shortcodes |
|||
Jekyll has [plugins](http://jekyllrb.com/docs/plugins/); Hugo has [shortcodes](/doc/shortcodes/). It's fairly trivial to do a port. |
|||
|
|||
### Implementation |
|||
As an example, I was using a custom [`image_tag`](https://github.com/alexandre-normand/alexandre-normand/blob/74bb12036a71334fdb7dba84e073382fc06908ec/_plugins/image_tag.rb) plugin to generate figures with caption when running Jekyll. As I read about shortcodes, I found Hugo had a nice built-in shortcode that does exactly the same thing. |
|||
|
|||
Jekyll's plugin: |
|||
|
|||
module Jekyll |
|||
class ImageTag < Liquid::Tag |
|||
@url = nil |
|||
@caption = nil |
|||
@class = nil |
|||
@link = nil |
|||
// Patterns |
|||
IMAGE_URL_WITH_CLASS_AND_CAPTION = |
|||
IMAGE_URL_WITH_CLASS_AND_CAPTION_AND_LINK = /(\w+)(\s+)((https?:\/\/|\/)(\S+))(\s+)"(.*?)"(\s+)->((https?:\/\/|\/)(\S+))(\s*)/i |
|||
IMAGE_URL_WITH_CAPTION = /((https?:\/\/|\/)(\S+))(\s+)"(.*?)"/i |
|||
IMAGE_URL_WITH_CLASS = /(\w+)(\s+)((https?:\/\/|\/)(\S+))/i |
|||
IMAGE_URL = /((https?:\/\/|\/)(\S+))/i |
|||
def initialize(tag_name, markup, tokens) |
|||
super |
|||
if markup =~ IMAGE_URL_WITH_CLASS_AND_CAPTION_AND_LINK |
|||
@class = $1 |
|||
@url = $3 |
|||
@caption = $7 |
|||
@link = $9 |
|||
elsif markup =~ IMAGE_URL_WITH_CLASS_AND_CAPTION |
|||
@class = $1 |
|||
@url = $3 |
|||
@caption = $7 |
|||
elsif markup =~ IMAGE_URL_WITH_CAPTION |
|||
@url = $1 |
|||
@caption = $5 |
|||
elsif markup =~ IMAGE_URL_WITH_CLASS |
|||
@class = $1 |
|||
@url = $3 |
|||
elsif markup =~ IMAGE_URL |
|||
@url = $1 |
|||
end |
|||
end |
|||
def render(context) |
|||
if @class |
|||
source = "<figure class='#{@class}'>" |
|||
else |
|||
source = "<figure>" |
|||
end |
|||
if @link |
|||
source += "<a href=\"#{@link}\">" |
|||
end |
|||
source += "<img src=\"#{@url}\">" |
|||
if @link |
|||
source += "</a>" |
|||
end |
|||
source += "<figcaption>#{@caption}</figcaption>" if @caption |
|||
source += "</figure>" |
|||
source |
|||
end |
|||
end |
|||
end |
|||
Liquid::Template.register_tag('image', Jekyll::ImageTag) |
|||
|
|||
is written as this Hugo shortcode: |
|||
|
|||
<!-- image --> |
|||
<figure {{ with .Get "class" }}class="{{.}}"{{ end }}> |
|||
{{ with .Get "link"}}<a href="{{.}}">{{ end }} |
|||
<img src="{{ .Get "src" }}" {{ if or (.Get "alt") (.Get "caption") }}alt="{{ with .Get "alt"}}{{.}}{{else}}{{ .Get "caption" }}{{ end }}"{{ end }} /> |
|||
{{ if .Get "link"}}</a>{{ end }} |
|||
{{ if or (or (.Get "title") (.Get "caption")) (.Get "attr")}} |
|||
<figcaption>{{ if isset .Params "title" }} |
|||
{{ .Get "title" }}{{ end }} |
|||
{{ if or (.Get "caption") (.Get "attr")}}<p> |
|||
{{ .Get "caption" }} |
|||
{{ with .Get "attrlink"}}<a href="{{.}}"> {{ end }} |
|||
{{ .Get "attr" }} |
|||
{{ if .Get "attrlink"}}</a> {{ end }} |
|||
</p> {{ end }} |
|||
</figcaption> |
|||
{{ end }} |
|||
</figure> |
|||
<!-- image --> |
|||
|
|||
### Usage |
|||
I simply changed: |
|||
|
|||
{% image full http://farm5.staticflickr.com/4136/4829260124_57712e570a_o_d.jpg "One of my favorite touristy-type photos. I secretly waited for the good light while we were "having fun" and took this. Only regret: a stupid pole in the top-left corner of the frame I had to clumsily get rid of at post-processing." ->http://www.flickr.com/photos/alexnormand/4829260124/in/set-72157624547713078/ %} |
|||
|
|||
to this (this example uses a slightly extended version named `fig`, different than the built-in `figure`): |
|||
|
|||
{{%/* fig class="full" src="http://farm5.staticflickr.com/4136/4829260124_57712e570a_o_d.jpg" title="One of my favorite touristy-type photos. I secretly waited for the good light while we were having fun and took this. Only regret: a stupid pole in the top-left corner of the frame I had to clumsily get rid of at post-processing." link="http://www.flickr.com/photos/alexnormand/4829260124/in/set-72157624547713078/" */%}} |
|||
|
|||
As a bonus, the shortcode named parameters are, arguably, more readable. |
|||
|
|||
## Finishing touches |
|||
### Fix content |
|||
Depending on the amount of customization that was done with each post with Jekyll, this step will require more or less effort. There are no hard and fast rules here except that `hugo server --watch` is your friend. Test your changes and fix errors as needed. |
|||
|
|||
### Clean up |
|||
You'll want to remove the Jekyll configuration at this point. If you have anything else that isn't used, delete it. |
|||
|
|||
## A practical example in a diff |
|||
[Hey, it's Alex](http://heyitsalex.net/) was migrated in less than a _father-with-kids day_ from Jekyll to Hugo. You can see all the changes (and screw-ups) by looking at this [diff](https://github.com/alexandre-normand/alexandre-normand/compare/869d69435bd2665c3fbf5b5c78d4c22759d7613a...b7f6605b1265e83b4b81495423294208cc74d610). |
|||
|
|||
@ -0,0 +1,11 @@ |
|||
+++ |
|||
title = "Projects" |
|||
date = "2020-06-01T15:11:44+05:30" |
|||
hide_authorbox = true |
|||
disable_comments = true |
|||
draft = true |
|||
weight = 2 |
|||
hide_list = false |
|||
menu = "main" |
|||
+++ |
|||
hmm |
|||
@ -0,0 +1,67 @@ |
|||
+++ |
|||
title = "Chatto - A Self Hosted E2EE Chat Application" |
|||
date = "2020-06-01T15:02:07+05:30" |
|||
disable_comments = true |
|||
draft = false |
|||
|
|||
categories = [ |
|||
|
|||
"Projects" |
|||
|
|||
] |
|||
tags = [ |
|||
|
|||
"java", |
|||
"spring-boot", |
|||
"hibernate", |
|||
"self-hosted", |
|||
"e2ee", |
|||
"encryption", |
|||
"typescript" |
|||
|
|||
] |
|||
|
|||
[menu] |
|||
|
|||
[menu.main] |
|||
parent = "Projects" |
|||
name = "Chatto" |
|||
|
|||
+++ |
|||
Chatto is a self hosted, end to end encrypted chat application. |
|||
|
|||
[Repository](https://git.arcusiridis.com/nova/Chatto) |
|||
[Documentation](https://git.arcusiridis.com/nova/Chatto/wiki) |
|||
|
|||
## Key Features |
|||
|
|||
1. Open Source, Self Hosted |
|||
2. Messages are encrypted end to end using AES GCM encryption (paramters like keysize can be configured) |
|||
3. No personal information such as names or email required |
|||
4. Does not rely on any external services like auth services, mail servers or captcha services |
|||
5. You are in control of your data. |
|||
6. Backend exposes a JSON API that can be used by third party clients |
|||
7. The chat messages support markdown |
|||
|
|||
## Technical Features |
|||
|
|||
1. Made with Java, Spring Boot and Hibernate |
|||
2. Front end is made with Thymeleaf templates and uses AJAX(written in TypeScript) to provide dynamic functionality |
|||
3. All password are stored hashed using Bcrypt |
|||
4. Uses a custom token based authentication scheme making use of Spring Security. Tokens are cached using EhCache |
|||
5. Care has been taken to safeguard against attacks like CSRF and XSS |
|||
|
|||
* Server side cookies are protected against CSRF using CSRF tokens |
|||
* To protect the JSON API auth token against XSS, DomPurify is used to sanitize any user provided HTML |
|||
* Server side DTO validation is used to sanitize user input |
|||
|
|||
## Tech Stack |
|||
|
|||
* **Backend** - Java, Spring Boot, Hibernate, Maven |
|||
|
|||
+ Database migrations using flyway |
|||
* Caching using EhCache |
|||
|
|||
* **Frontend** - |
|||
+ Server side templating - Thymeleaf |
|||
+ JS - TypeScript, Browserify (and plugins like tsify), Terser, Grunt, Yarn |
|||
|
After Width: 790 | Height: 450 | Size: 141 KiB |
Write
Preview
Loading…
Cancel
Save
Reference in new issue