Planet CDOT (Telescope)

Tuesday, October 4, 2022

Alexander Samaniego

DPS909 Blog - Lab 4: Using Git Remotes and Merges

This week in my Open-Source course (DPS909), we were introduced to the concept of git remotes and merges. The purpose of this lab was to help us to practice using git remotes and merges to collaborate with our peers on some code changes.

Lab 3 was a change of pace as we worked on our own repos and did not collaborate with anyone. Now with lab 4, it's back to collaborating and adding features to other people's projects.

My Contribution

I decided to collaborate with Neil and contribute to his static site generator.

Feature Added

I wanted to add support for JSON formatted configuration files. The config file would contain all of the options that the tool supports. Instead of having users specify all of the SSG options as command line arguments, they can just specify the config file. So I created an issue and created a draft pull request so the owner can see the work I'm doing.

Code Changes

Implementing this feature was not too difficult. The main problem was to figure out a way to read and parse a JSON file and then assign those values to the appropriate option.

First, I added an additional option so that the tool will accept -c/--config flags.

I then added a conditional statement that will check if a config file path was specified. If it was, then a new function called readConfigFile will parse the JSON file if it exists. The parsed values then get passed into generateHTML to generate the appropriate HTML files.

Contribution to My Project

I had an issue that was created on my repo that wanted to add similar feature.

A draft pull request (PR) was created for this issue, so I was following every commit to make sure everything was going smoothly.

Once the PR was marked 'ready for review', I added a git remote to test the files changes locally on my machine. I didn't have much trouble working with git remotes because I had unknowingly used this feature before through Visual Studio Code's GitHub extension. The only adjustment I had to make was using the command line to create the remote instead of the GUI.

I did find one issue with the PR which had to do with error handling. I suggested adding an error message to handle non-existent config files.

This issue was swiftly addressed and fixed. I then used the git remote to test one final time before approving the changes and merging.


This lab went pretty smoothly. I didn't have any problems adding features to another repository or creating the PR. Most likely because I was familiar with the tech stack and language in use. I also unknowingly had experience using git remotes, so again, I had no problems with testing the PR on my repo. I just need to get more accustomed to using the command line for git remotes, instead of relying on git GUI solutions.

by Alexander Samaniego at Tue Oct 04 2022 07:22:57 GMT+0000 (Coordinated Universal Time)

Monday, October 3, 2022

Neil An

Working with git remote and adding to my SSG

Hi everyone,

This week I worked with Alex to add a new feature to our SSGs. This new feature was the ability to use a JSON config file to pass in options instead of typing in the options manually in the command line. I worked on Alex's repo.

The code wasn't too difficult to write. I added new options -c and --config which would use a JSON config file to get all the options needed when generating the HTML file. For example, the contents of the config file could look like this:

  "input": "./site",
  "output": "./build",
  "stylesheet": "",
  "lang": "fr"

The code process I did was to first check if the config file exists and is JSON formatted, then read from the file and put the contents into an object, and finally use the properties from the object to get all the options. The biggest issue I had was making sure not to duplicate code, so I had to change a few things in the code before I could add my changes.

The biggest thing I learned from this process was using a couple of new features from Git. I used the Draft Pull Request for the first time and found how useful that feature is. It's cool how you can continually add commits to the PR until you believe it is ready for review. I also learned how to use a git remote, which is used to work with a different repo that you didn't clone. I used this feature to get my partner's work form his branch onto my computer so that I could review and test his code.

Luckily, the instructions were pretty clear, so I had no problems with these new Git features, but I still feel I need practice with them. I'll continue to use these features throughout my programming career.

by Neil An at Mon Oct 03 2022 21:03:59 GMT+0000 (Coordinated Universal Time)

Piotr Drozd

Open Source Lab 4

In lab 4 of the open source course, we worked with git remote and added JSON support for our SSG. For the JSON support, we want to be able to write commands and include a JSON file that has a list of commands and our SSG to read and run the command with the list provided.

What I did


Pull Request

For this lab, I worked on Tong's SSG created with CPP. Because I've worked with this code previously it was easily navigatable and most of the code was easy to add. The difficulty I had was adding JSON to CPP. CPP has no native JSON reading so I can't just read the file like a JSON file unless I make a custom class or use a library. A custom class in CPP dedicated to reading JSON would probably be the size of another project so I decided that I want to use an already open source library. I did some research and found a couple of the most used ones and asked Tong if there was one he preferred because at the end of the day it was his code so his decision was the most important one. He said he liked nlohmann/json because it had the most forks. I looked into how to implement it inside of his code and saw I only needed to include the HPP file inside of the code.

What was done to my SSG


Pull Request

Once Tong implemented JSON inside of my Python SSG I used a git remote to test his repo. I Tested and looked over the code and felt the changes done to mine were done well so I pushed it to my main.

by Piotr Drozd at Mon Oct 03 2022 16:09:42 GMT+0000 (Coordinated Universal Time)

David Humphrey

On the value of small contributions

My open source students are beginning Hacktoberfest this week and already the DMs are coming in with a familiar question:

"Is this issue big enough? Is this too simple?"

I understand the question, since I explicitly ask that students work in real open source projects, avoiding those repos that appear suddenly every October and vanish just as quickly in November.  I want to see everyone working on valuable contributions to existing projects.  But how big should a contribution be?

My answer: as small as possible, while providing value.  Let me give you a few recent examples.

For the past month, our beloved blogging aggregator, Telescope, has been broken.  I asked my current students to use our new Seneca SSO based Sign-Up flow and create an account.  Later that same week, I was shocked to see that none of their blogs were showing up in the timeline.  I decided to look at the database to see what was going on (maybe no one actually signed-up?), only to be met by a set of angry 400 errors on the database's REST API.

I filed an issue and not long after, Kevan appeared with a fix that changed a single line!  The difference between me being able to properly administer the database and being locked out came down to updating 15 characters!

After shipping these 15 characters to production, I was now able to see what was happening in the database, and sure enough, the students had created accounts: the system just wasn't processing or showing their content for some reason.

Thankfully Roxanne appeared in the issue with some ideas and a willingness to turn her debugging prowess onto the problem.  Her research uncovered an issue with how new users were being processed by the system.

Telescope has three categories of users:

  1. Those grandfathered into Telescope from the Planet CDOT Feed List wiki page
  2. Those who have created accounts via our SSO based Sign-Up flow
  3. Those who have graduated from 1. to 2.

All of our testing last year focused on people in category 3, namely, those who were listed in the wiki page, but also created accounts for themselves.  In this case, we link the accounts in our backend, allowing an existing user to sign-up and re-take control of their account.

This fall, for the first time, all of our users are from category 2 (i.e., creating brand new accounts that don't exist in the wiki).  It's a scenario that should work (in theory!) but clearly doesn't in practice.  Our feed parser couldn't find a name for all the new users, so ignored their feeds.

The problem, once understood, was easy to fix: Roxanne made another 1-line change, affecting only 20 characters! Magic.

The Telescope project is about to turn 3 years old this month (it started in Oct 2019, remember that world?).  Since then, 229 contributors have written close to 25K lines of code.  The code is mature, and the architecture takes time to learn and understand.  I don't think any of the recent devs (myself included) knows all of it.

Getting involved with a medium-sized open source project like Telescope takes time.  You have to figure out where a bug is coming from, try and get things running locally, test your hypothesis, discover that you're wrong and try again, talk to people about what you learned, and repeat that process for hours, days, or weeks without giving up.  Often, like I've just shown you above, the actual fix is trivial, even obvious!  But only once you've figured out what's going on in the first place.

Lots of big things get brought down by tiny forces (try stepping on a single piece of lego in the night as you fumble around a room in the dark).  In the examples above, I showed you that 35 characters were all that it took to make 25K lines of code unusable.

Having a big impact isn't about writing a lot of complicated code.  Rather, real programming is doing exactly what's needed to make a system work, and nothing more.  If you can do it by changing a single line of code, you're a true master.  If you can do it by removing a single line of code, you're a wizard.

My advice to all my students this October who are struggling with imposter syndrome and feeling like their tiny contributions won't amount to anything: be like Kevan and Roxanne.

by David Humphrey at Mon Oct 03 2022 14:12:42 GMT+0000 (Coordinated Universal Time)

Naziur Rahman Khan

SPO600- Math and strings Lab(Lab 3)

In this lab, I was asked to write a program that meets following criteria,

1. Program must work in the 6502 Emulator.

2. Output must be shown to both the character screen as well as the graphics or bitmapped screen.

3. Program must take user input from keyboard in some form.

4. Also I must use some arithmetic or math instructions

For my program, I have selected one of the program wrote by our course professor. I got this program from github. As I am still learning the language, so I have decided to modify that code to produce a bit different kind of output than the original one without giving away the main intend. 

So the original program would ask the user to select a color from a given list, which will then be shown in the bitmapped display. Here I have changed the input text that was asked to the user as I have modified the program in such a way that the selection prompt will start from the light green which is not at the top of the list instead of the original one which was black. Additionally, I modified the code to fill only 2 pages of the display instead of the whole screen. The modified code and output is showing below:

Modified code:

; Colour selector - live updates

; (C)2020 Chris Tyler - Seneca College

; Modified by Naziur Rahman khan

; Licensed under the GPLv2+ - see LICENSE file

; ROM routine entry points

define SCINIT $ff81 ; initialize/clear screen

define CHRIN $ffcf ; input character from keyboard

define CHROUT $ffd2 ; output character to screen

define SCREEN $ffed ; get screen size

define PLOT $fff0 ; get/set cursor coordinates

; zeropage variables

define PRINT_PTR $00

define PRINT_PTR_H $01

define CURRENT $02

define SCRN_PTR $03

define SCRN_PTR_H $04

; constants

; --------------------------------------------------------



dcb "B","l","a","c","k",$0d

dcb "W","h","i","t","e",$0d

dcb "R","e","d",$0d

dcb "C","y","a","n",$0d

dcb "P","u","r","p","l","e",$0d

dcb "G","r","e","e","n",$0d

dcb "B","l","u","e",$0d

dcb "Y","e","l","l","o","w",$0d

dcb "O","r","a","n","g","e",$0d

dcb "B","r","o","w","n",$0d

dcb "L","i","g","h","t",32,"r","e","d",$0d

dcb "D","a","r","k",32,"g","r","e","y",$0d

dcb "G","r","e","y",$0d

dcb "L","i","g","h","t",32,"g","r","e","e","n",$0d

dcb "L","i","g","h","t",32,"b","l","u","e",$0d

dcb "L","i","g","h","t",32,"g","r","e","y",$0d

dcb $0d

dcb "C","h","o","o","s","e",32,"a",32,"c","o","l","o","r",32

dcb "f","r","o","m",32,"t","h","e",32,"a","b","o","v","e",32,"l","i","s","t",32,"t","o",32,"s","e","e",32,"i","t",32

dcb "o","n",32,"t","h","e",32,"f","i","r","s","t",32,"t","w","o",32,"p","a","g","e",32,"o","f",32,"t","h","e",32,"b","i","t","m","a","p","p","e","d",32

dcb "d","i","s","p","l","a","y",".",$0d

dcb 00

lda #$0d

get_colour: jsr SELECT

ldy #$00


ldx #$02


ldx #$02 ; number of pages to fill

draw: sta (SCRN_PTR),y


bne draw



bne draw

jmp get_colour

; -----------------------------------------------------------

; SELECT :: select one line from the screen


show_and_go: jsr HIGHLIGHT

getkey: jsr CHRIN

cmp #$80 ; cursor up

bne try_down


beq getkey



jmp return

try_down: cmp #$82 ; cursor down

bne getkey


cmp #$0f

beq getkey



return: lda CURRENT


; --------------------------------------------------------


; Highlight :: highlight the CURRENT line on the display


ldx #$00


jsr PLOT

highlight_next: sec

jsr PLOT

eor #$80



cpx #20

bne highlight_next


; --------------------------------------------------------

; Print a message

; Prints the message in memory immediately after the 

; JSR PRINT. The message must be null-terminated and

; 255 characters maximum in length.

PRINT: pla


adc #$01






ldy #$00

print_next: lda (PRINT_PTR),y

beq print_done



jmp print_next

print_done: tya





adc #$00









                                                  The above part was the modified code


Compared to last few labs, I am feeling more comfortable with the emulator now as I can see the output of my very own customized code blocks. I am excited to continue experimenting in this emulator and build my own piece of program all by myself. 

Code courtesy: This code was taken from this link mentioned in the resources by the course instructor.

by Naziur Rahman Khan at Mon Oct 03 2022 00:57:16 GMT+0000 (Coordinated Universal Time)

Sunday, October 2, 2022

Arryell Parris

Lab 3 - working in multiple branches

Project Repo: ap21-ssg

New Features added

Merge Commits

Working in parallel branches for adding new features ensured that, when I made any changes to the code, if the new changes generated errors or broke the program; the previous bug-free stable version would remain intact and I wouldn't lose that work.

I was able to code the solution for 'issue-19' (allowing the user to specify an output directory) without losing any of the progress I made prior to adding this new feature.

I encountered some issues when I attempted to merge the solution for 'issue-20' (adding support for recursive file parsing). I resolved the conflicts generated when attempting to merge the two branches into 'main' here.
However, for one of the functions, I merged from the wrong branch, but since only minor changes to the code (about 4 lines total) were necessary, I went back and manually adjusted the code.
See Issue 21 - Resolved conflicts between issue-19 & issue-20 merges for details.

I think that, in reference to merging the function from the wrong branch, it would have been a better solution to revert the changes, and then re-merge using the correct branch. However, since the changes I needed to make were very minor, I opted to edit the code manually this time.

by Arryell Parris at Sun Oct 02 2022 17:14:52 GMT+0000 (Coordinated Universal Time)

Naziur Rahman Khan

SPO600-Lab 2 (Continued)


Now I will perform some additional experiments which was asked for the lab.

First I will add a instruction tya in the loop of the code. See the output below that I got from it.

Here instruction tya means transfer y to a. Here I can see 11 colors on the display. 

Now I was told to add instruction lsr after tya as like 'tya:lsr' . Let's see the output on the below screenshot:

Experimenting with the emulator helping me gradually to adapt with this language. I will continue my experiments and post more blogs of these later.

by Naziur Rahman Khan at Sun Oct 02 2022 06:12:17 GMT+0000 (Coordinated Universal Time)

SPO600-Lab2 (Experimenting with 6502 emulator)

In this lab, I have been given a bitmap code which will fill the emulator's bitmap display with the yellow color. Later I was given some task to modify the code in such a way to get different output color for the entire display. I was also asked to show four different color in four different pages. In this display one quarter is refer to as one page. I was encouraged to do some further experiment then. So I will start from the very first task.

I assembled and run the initial code on the emulator and below is my raw code and output.

lda #$00	; set a pointer in memory location $40 to point to $0200
	sta $40		; ... low byte ($00) goes in address $40
	lda #$02	
	sta $41		; ... high byte ($02) goes into address $41

	lda #$07	; colour number

	ldy #$00	; set index to 0

loop:	sta ($40),y	; set pixel colour at the address (pointer)+Y

	iny		; increment index
	bne loop	; continue until done the page (256 pixels)

	inc $41		; increment the page
	ldx $41		; get the current page number
	cpx #$06	; compare with 6
	bne loop	; continue until done all pages

This was the initial code that was given which is supposed to produce yellow color.

                                                Here you can see the yellow bitmap display

Calculating execution time:

Modifying the code:

1. Here at first I was asked to change the given code to fill the display with light blue instead of yellow.

For this task I have given a reference chart showing below

  • $0: Black
  • $1: White
  • $2: Red
  • $3: Cyan
  • $4: Purple
  • $5: Green
  • $6: Blue
  • $7: Yellow
  • $8: Orange
  • $9: Brown
  • $a: Light red
  • $b: Dark grey
  • $c: Grey
  • $d: Light green
  • $e: Light blue
  • $f: Light grey

From here we can see that to change the display to light blue we need to modify the value of color number lda #$07 to #$e.

After modifying that code below is my output display.

2. In this task I was asked to modify the code to display four different color in four page. Each quarter of the display is a page. For this I stored the color in memory location $10. Next is when the page incremented I use increment value of $10 so that the accumulator loads with the incremented color code value of $10.

lda #$00 ; set a pointer in memory location $40 to point to $0200

sta $40 ; ... low byte ($00) goes in address $40

lda #$02

sta $41 ; ... high byte ($02) goes into address $41

lda #$5 ; colour number

sta $10    ; store colour number to memory location $10

ldy #$00 ; set index to 0

loop: sta ($40),y ; set pixel colour at the address (pointer)+Y

iny ; increment index

bne loop ;  continue until done the page (256 pixels)

inc $41 ; increment the page

  inc $10  ; increment the color number

        lda $10 ; colour number

ldx $41 ; get the current page number

cpx #$06 ; compare with 6

bne loop ; continue until done all pages 

This is my modified code to obtain four color in four page

                                              Here is the output of having four color in four pages

Here you can see that I start with value 05 which is green, then it incremented to 06 which is color blue,
then 07 which is yellow and lastly 08 which is orange. We can also set the initial color to a random choice by assigning it $fe so that everytime we run the code it will produce different output colors. 

by Naziur Rahman Khan at Sun Oct 02 2022 23:12:47 GMT+0000 (Coordinated Universal Time)

Taimoor Dawami

OSD600 - Enhancing Siteit’s markdown features

About Siteit

Siteit is a CLI tool that can .txt and .md files into HTML. Read more about Siteit here or check out the GitHub repo.

New Features

Over a week ago, my peer implemented initial markdown support to bolster Siteit’s existing SSG capabilities. This week, I am to add new markdown features to the repo.

Feature #1

I started by filing an issue regarding Siteit’s lack of ability to process code blocks. Then I began by implementing its source code and frequently committing it to a new git branch. After thoroughly testing my work, I pushed the changes to GitHub.

Feature #2

I filed another issue regarding Siteit’s lack of ability to add Horizontal Rule in rendered HTML. Then I implemented the code, tested it, and pushed the changes to GitHub.


Users can now supply a markdown file containing lines of source code enclosed within a pair of backticks.
When Siteit is processing markdown files and encounters lines containing an instance of a backtick, followed by some text and one or more backticks, it will accurately render the text within a pair of <code>…</code> blocks. Furthermore, instances of --- in markdown files are rendered as <hr> in generated HTML.

Overall it was fun to practice several features of Git while adding new features to Siteit.

by Taimoor Dawami at Sun Oct 02 2022 04:39:27 GMT+0000 (Coordinated Universal Time)

Tommy Liu

Reflect for Lab 4

What did I do and how did I do

In Lab 4, I added JSON config file support to Piotr's GitHub repo. Since Python language is arguably an easy-to-use language, most of the commonly used functions are natively supported. Of course, JSON is natively supported so parsing JSON is quite simple; I just used the file reader to read the config file that is passed with the argument '-c' or '--config', and pass this file object to the JSON parser function named load() in the JSON package and a JSON object will be returned. However, it wasn't actually going that smoothly, I had two issues in coding this lab.

Problem 1

The first one was with the JSON parsing function. There was a JSON object returned by JSON.load() that I mentioned earlier, although it truly returned a JSON map object after a successful parsing, the return type of JSON map object is a generic object which means the IDE can't infer what functions can be called onto the object and which function I can make a call on to check if an element exists in this JSON map object. I tried to google it, but nothing seemed to be useful. When I started to feel desperate, I realized maybe I can add a breakpoint to that JSON map object to see what it looks like in runtime. Luckily this solution worked. I noticed there was a function named __contains__(weird name..), I tried to make a call on it and it finally checked if the passed key exists in the JSON map.

Problem 2

Another issue was the way how Piotr coded the argument parsing code was hard-cording, which means it only accepts the argument in the designed sequence, for example, if I make the argument passing sequence -i ./input -c ./config.json work, then if I pass -c ./config.json -i ./input, only -i ./input will be taken. Apparently, this doesn't meet the requirement. To fix it, I refactored the code of this part and it worked well in the end.

My careless self..

Also, this shouldn't be counted as an issue, but I forgot to update my forked project before starting working on it, I tried to create a PR on my forked project to merge back the new update after I came to the realization that I had not done so. This time I wasn't that lucky, I had to deal with 3 conflicts since the part I had rewritten overlapped with Piotr's update. Resolving conflict wasn't very pleasant, but still, I did it.

Something makes my life easier

From this lab, the useful thing I've learned is the Draft Pull Request because it's very useful since it can be used as a way to create a pre-created Pull Request without actually posting it for review.

Don't be sorry be better

The biggest lesson I've learned is don't even think about coding before you've made sure that the your base branch's code is up-to-date, otherwise, have fun resolving conflicts.

by Tommy Liu at Sun Oct 02 2022 03:27:04 GMT+0000 (Coordinated Universal Time)

Saturday, October 1, 2022

Naziur Rahman Khan


 Mozilla Firefox:

It is another open source software which is a popular browser. It is under the Mozilla public license.

Mozilla Firefox issue contributions:

There is a GitHub page where everyone can raise any issue with this browser. I followed both the open and closed issues from this page. For example, in this closed assignment 27046 where the issue was navigation bar won't disappear in full screen video player, the issue was raised by Nimzael. He also added different labels like 'bug', 'needs: triage' to this issue. He got a reply within two days from SoftVision-LorandJanos. Within one day of the initial response the issue got resolved and the assignment was marked as closed with completed sign. So even if there is no actual issue or bug to commit changes, there are lots of opportunity to raise any issue for expert attention.

by Naziur Rahman Khan at Sat Oct 01 2022 20:03:17 GMT+0000 (Coordinated Universal Time)

SPO600- Lab1

For lab1, I was asked to research about two Open source software packages and there input collection from the contributors. For this I have chosen Visual studio code and Mozilla Firefox.

Visual Studio code:

It is an open source software package from Microsoft which run under MIT license.

Visual Studio code contributions:

There is a wiki page from where one can learn about how to contribute to vscode. The process simply is someone raise a new issue, Microsoft then assign the issue to someone dynamically and then the assignee work on that assignment and try to discuss with others to solve the issue. 

I followed couple of the closed and open issues including this one 161334. This one is already closed by the assignee. Here we can see that Roblourens raised this issue called Settings sync disabled due to too many requests. He then assigned sandy081 for this issue. after about one week of raising the issue was solved with multiple commit from jrieken. 

by Naziur Rahman Khan at Sat Oct 01 2022 19:35:41 GMT+0000 (Coordinated Universal Time)

SPO-600-Blogging Introduction

Hello everyone,

Welcome to my new blog series. This series will follow the instruction of the course called Software Portability and optimization. I will be posting about all the labs and project work here one after another. You can view the wiki page of this course from here

by Naziur Rahman Khan at Sat Oct 01 2022 18:39:54 GMT+0000 (Coordinated Universal Time)

Anshul Gandhi

DPS909 Blog :Static Site Generator(ag-ssg) Lab 3

Hey everyone, thanks for reading my Blog post.
In this post i am going to talk about the new features which i have added into my application.

Link to repository : ag-ssg.


In this lab we are supposed to add this feature in our current project.

  • Add an option -l, --lang flag, which indicates the language to use when generating the lang attribute on the root <html> element. For example, --lang fr would mean that the HTML documents are in French, and would include <html lang="fr">.
  • Add support for a horizontal rule in Markdown. The Markdown --- should get converted to an <hr> tag.


  • This tool is built using the Node.js

Links to issues created by me in ag-ssg.

To get language feature working in my application, i have created the lang option in my app.js option which will allow the user to mention in which language they want to generate the particular page.
By default i have set the value of lang to be in en-Ca in index.js.

To convert the --- to in `html` i just have to search through the .md file and implement the if the search was successful.


by Anshul Gandhi at Sat Oct 01 2022 15:58:03 GMT+0000 (Coordinated Universal Time)


Merging parallel branches without PRs in GitHub

For week 4 of my course in open-source development, I was tasked with adding two more features to my ssg project rost_gen. However, I was supposed to work on both at the same time on different branches and merge those branches into the main branch once both implementations were complete. Normally, I would use pull requests and not merge directly into the main branch.

I created two issues to add an option flag to specify the language of the generated html document, and to parse '---' markdown as a thematic break (horizontal rule or <hr> tag). After creating the branches for these issues through the UI on the issues page, I started working on implementing the new features.

Prior to this, I was parsing command line arguments manually using if statements. So, this also allowed me to address another issue to use clap for argument parsing. I was surprised by how much I was able to simplify my program by using clap to define the same logic. And once that was done, adding support for another flag was rather easy.

Further, adding support for parsing thematic breaks/horizontal rule markdown was even simpler. Since there was existing support for Heading 1 markdown (<h1> tags), all I had to do was add an else statement to check for the new markdown rule.

However, I discovered some unrelated bugs while testing my changes. Apparently I had previously forgotten to check if the specified output directory already contains a file with the same name as an input file. As a result, the generated html gets appended to the end of the existing file instead of overwriting existing content. I also found that the title parsing logic causes a blank line to be added to the title. Since these were unrelated to my changes, I created two more issues to fix them later.

Finally, it was time to merge my changes into the main branch. As expected, the first branch was merged smoothly (fast-forward merge). I was expecting to run into some conflicts when merging the second branch but it turns out there was no code overlap between the two and git automatically merged them (ort strategy) with the default merge message.

Even though this process went smoothly, I found it difficult to go through the commit history. Since I tend to commit small changes, I end up with multiple commits for adding a single feature. Usually, I would use pull requests so I can squash and merge before merging. Then, I can look for the PR merge commits and read the description to quickly see what was changed. Also, I do not need to manually close the issues if I link them in the PRs.

by Eakam at Sat Oct 01 2022 03:27:19 GMT+0000 (Coordinated Universal Time)

Friday, September 30, 2022

Stefan Frunza

Working in Parallel

Branch then Merge

In the third lab that we were assigned in my Opensource Dev course at Seneca we were taught how to checkout feature branches so that we can work on multiple features independently and how to later merge them all to the main branch and resolve conflicts. To do so we yet again used our simple site generators

Introducing Feature Branches

The first step to this was to create two small issues that we would create feature branches for. For me these issues were the following: #6 and #7.

using checkout -b I created two new feature branches associated with the numbers of the issues, in my case issue-6 and issue-7.

Adding the code

This part was really easy. @rudychung made the code he added in his PR last week easily legible and compartmentalized it into two functions that were easy to add to, I took his logic and just replaced the regex pattern for the code tag change and I slightly altered it for the hr tag change because the hr tag does not wrap any text, the --- is just found and replaced.

Merging it all

The merge commits are the following: 4c9657a and 8302b5.
In the first of which I added the code tag logic and the second of which I added the hr tag logic.

Problems and Challenges

Not much to add here honestly, this week everything seemed pretty straight forward, one thing to note is when I used git log in the terminal I did not know how to get out of it until I googled it and learned that I had to press q.

by Stefan Frunza at Fri Sep 30 2022 22:35:12 GMT+0000 (Coordinated Universal Time)

Rohan Kaicker

OSD600 Blog #5 - Lab 3

For this weeks lab, we were tasked with creating two parallel branches on our program's repo, to create two new features.

The idea behind this weeks activity was to get familiar with git merge, and the idea of fast-forward merges and three-way recursive merges.

Originally, I forgot to create both issue branches at the same time (so that they would have the same "starting point"), and created a branch just for my first issue and then merged that when it was solved. But then I realized this defeated the purpose of this weeks activity, so I decided to add 2 additional features to that I could get some practice with git merge.

My links are given below (note - Issues 25 and 26 were the ones that were incorrectly initiated):

Project Repo

1 - Issue #25 - Ability to specify HTML language.
Merge Commit

2 - Issue #26 - Parse inline code blocks.
Merge Commit

3 - Issue #27 - Parse markdown horizontal rules.
Merge Commit

4 - Issue #28 - Parse single line blockquotes.
Merge Commit

For Issues 25 and 26, the "merges" were conflict free because of the wrong way I did them. But for Issues 27 and 28, I did encounter a "conflict" (shown below).

I thought it was interesting that Git will first prevent the merge from occuring (because of the presence of a conflict), and then actually modify your file to show you exactly where the conflict is occuring. I was able to quickly fix this issue, as all I had to do was separate the if-else statements.

As I had mentioned in a previous blog post, I really wanted to take this course because I knew I'd get a chance to improve my git skills, and doing these weekly labs have really given me the chance to do just that.

As for my project, I definitely have alot of improvements to make (I beleive I have about 10 "issues" pending in my repo), and I look forward to seeing what improved versions of my project will look like!

by Rohan Kaicker at Fri Sep 30 2022 17:36:15 GMT+0000 (Coordinated Universal Time)

Samina Rahman Purba

My Experience With GitHub Topic Branches

Thoughts 💭

This week I learned something new about GitHub – using topic branches! And not just that – I also added two new features to my static site generator, rwar. Rwar is a simple static site generator written in Python and I keep improving it every week by implementing one or two new features, along with updating all its documentation and debugging anything that might have broken in the process. If you are interested in Python, I encourage you to check out rwar. Fork it, clone it and test it out! Building this project paved a path for me to learn Python and trust me I have learned so much in such a short time! The best way to learn something is to start building a project with it. Yes, it requires a greater learning curve, and there is a greater chance of breaking stuff in the process, but through getting hands-on, the learning happens so much faster.

Working with GitHub topic branches 🔧

  • I started the process by first filing issues in my repository.
    Issue 9 provided a short description about implementing a –l flag, which indicates the language to use when generating the lang attribute on the root <html> element.
    Next, I filed issue 10 which provided a short description about supporting horizontal rule in Markdown. This means that the Markdown --- will be converted to <hr> in the generated HTML.

  • Then, I created the topic branches in the following way:

$ git checkout main
$ git checkout -b issue-9
$ git checkout -b issue-10
  • Next, I started working on my code! I implemented each feature separately as I had a clear idea of how to implement them. Each feature required only a few lines of code to be added and I managed to do them quickly without any issues.

  • After all the implementation was ready, all I had to do was merge! This went smoothly without any merge conflicts. Here is an example of how that looked like:

$ git checkout main
$ git merge issue-9

Helpful links

Issue Closed by
Issue #9 7546901
Issue #10 9eae23b

What I would do differently next time ❓

I realized that Git is powerful as it allowed me to work on different features with different versions of the code simultaneously existing at the same time. However, as strange as it sounds I wanted to experience merge conflict to see what it looks like and how I can resolve it. However, I believe as I start working on bigger and more complex projects I will eventually face those dreaded merge conflicts.

I would also change the names of my issues to something more descriptive Instead of just labeling them as issue 9 and issue 10. Perhaps, I could name them according to the feature being implemented.

Some more thoughts 💭

I am really looking forward to Hacktoberfest! Although I suffer terribly from imposter syndrome and deeply fear pull requests, I am ready to give it my best shot.

by Samina Rahman Purba at Fri Sep 30 2022 04:29:21 GMT+0000 (Coordinated Universal Time)

Batuhan Ipci

palpatine supports markdown - minor release

It has been almost 4 weeks since I started developing palpatine. In this week I have added couple more features to support markdown files. If you missed the first post on palpatine, you can read it here. The static site generator I am building is a real world tool, so I want to make it efficient and my goal is to help users find information they need as quickly as possible. Palpatine now supports horizontal rule and inline code features to help you compose your interactive documentation with ease. See the demo with the new markdown features.

Creating Topic Branches

Regarding the features I stated above, I initially filed separate issues Issue #9 and issue #10 and created separate branches for each feature. There are couple ways I know to create branches through terminal. One of them is;

  git branch <branch-name> # creates a new branch
  git checkout <branch-name> # switches to the new branch

This is the way I used to create branches. But I found out that there is a better way to create branches and switch to them in one command. The command is;

  git checkout -b issue-10

This command little bit more efficient compared to the previous one. It creates a new branch and switches to it in one command.
After I created the branches, I started working on developing the markdown features. Adding the features I stated was not hard after all, I am trying make my code efficient than ever and clean.

Merge Time

After I finished the features, I merged the branches to the main branch. I used the following command to merge the branches to the master branch;

  git merge issue-10

The fun part was watching all changes from the different branches merge to the main branch. I achieved this smoothly without crashing any part of the code. I did not have any merge conflicts this time as I was careful about what I was changing and merging.

Links to my Issues and Merged commits

Issue Closed by
Issue #9 2296034
Issue #10 37d8c11

by Batuhan Ipci at Fri Sep 30 2022 02:30:52 GMT+0000 (Coordinated Universal Time)

Gulnur Baimukhambetova

My first merge!

Hello everyone!

Today, I tried both fast-forward and three-way recursive merges as I was working on two different additional features for my SSG command-line tool, SSGulnur.

First feature that I was interested in implementing was adding markdown bold and link syntax features support. As always, I created an issue about my solution and a branch in which I worked on it.

I also followed the same steps for my second feature which was adding markdown heading syntax features support.

I worked on them one by one. So, after I had been satisfied with my new code in one branch, I would commit it with a descriptive name stating which issue would get fixed and then switch into another branch and do the same. At the end though I had to combine all of them together. Therefore, I went back to my main and started merging the new branches one by one. The first one went smoothly through a fast-forward merge, but the second one was a three-way recursive merge and required me to resolve the conflicts, as I worked on the same lines of code in both of them. I combined the code accepting both and committed the changes.

When, I pushed my updates back into the GitHub, I could see that the issues were closed and also contained the commit references automatically for me, as I used fixes #(issue number) in my commit descriptions.

For my first issue the commit number was 1d14563 and or my second issue it was f966533.

Probably, this ability to have many simultaneous branches is very useful when multiple developers are working on the same code, but it still helps to combine the code even if you are working alone and want to split some project implementations.

Overall, great.

by Gulnur Baimukhambetova at Fri Sep 30 2022 02:25:28 GMT+0000 (Coordinated Universal Time)

Thursday, September 29, 2022

Neil An

Adding features to my SSG with multiple branches

Hi everyone,

This week, I continued to work on my SSG and I added two new features.

The first feature was adding a new --lang option which will allow users to indicate the language to use when generating the lang attribute in the HTML file. To implement this feature, I first added a new option -l or --lang that the user can use to specify the language. I then took that language that the user passed in and put it into the HTML template so that the lang attribute would be written correctly. By default, the lang attribute will use en-CA (Canadian English). The issue. The commit.

The second feature was adding Markdown support for horizontal rules. This means that the Markdown --- will get converted to <hr> tags in the HTML file. I first found lines in the Markdown file that was the horizontal rule, then I converted those lines into <hr> tags in the HTML file. The issue. The commit.

The main difference I did when adding these features was working on different branches for each issue. I worked on each issue separately and did not share any code between the two branches. After finishing the code, I merged both branches one by one. Thankfully, there were no issues that I ran into and everything went smoothly. I learned how to work on different branches and how to merge different branches into the main branch.

by Neil An at Thu Sep 29 2022 21:35:04 GMT+0000 (Coordinated Universal Time)

Artem Tanyhin

SSGo 0.3 and notorious git merges

Hi again! Glad you've come. First of all...

It's update time! 🎉

SSGo is at release 0.3, which means some additional Markdown features!

  • Markdown Horizontal rules --- are now turned into <hr> HTML tag.

  • Markdown inline code blocks are now turned into HTML <code> tags.

  • Some code optimizations to prepare for adding italics and bold text! Hoping to add soon...

If you're not familiar with SSGo, you can check it out in my GitHub repo. It's under MIT license, so contributions are more than welcome.

Git merges

This time, I worked on both Markdown features in parallel on separate branches, which meant I had to merge those eventually.

Merging code is something many programmers prefer not to do. They still have to, but don't enjoy it as much. However, for me it's different.

I actually like git merges more than I probably should, and I usually do some optimizations in the process too. For me, coming up with an optimization and getting pieces of software together is just so relaxing. You know the code is done, so all you have to do is get it together, like a jigsaw puzzle.

Anyway... Like anything in open source, I started by assigning issues (10, 11) that I assigned to myself. After that I started working on separate branches on my local. After both have been done, I fast-forwarded the first branch to master, and made a merge from the second branch to master.

There is a charm in doing everything properly, and not making a mess out of your repo.

by Artem Tanyhin at Thu Sep 29 2022 04:54:09 GMT+0000 (Coordinated Universal Time)

Gulnur Baimukhambetova

My first pull request!

Hello everyone!

Today, I worked on developing an extra feature on my friend's tool Rohan-SSG. For that, I had to go through multiple steps in order to ensure that all of my changes are done safely following the best practices.

First of all, I had to file an issue on his repo stating my enhancement intentions. I had to explain the goal and my solution idea. After that, I forked his repo to make the changes in a copy of his work under my profile instead of the original. I also created a new branch which had a self-explanatory name such as an issue number. I made all of my changes on that branch locally, pushed them back on GitHub and opened a pull request.

My issue was about adding support for markdown syntax features such as italics and bold. The heading 1, heading 2, and a link features were already developed, so I had to integrate my new implementation into existing code. I looked through the file system, found where the logic was located for my part, understood the general coding and commenting style and followed it. I also updated the files used for testing to contain italicized and bold markdown text, so that my new featured could be tested. I made sure everything worked before committing. Lastly, I checked the documentation to see if I had to update any information, but there was nothing about currently supported syntax features.

My friend reviewed the changes and everything looked good. However, he requested for me to add a line in the documentation to state all of the supported markdown styles. I did that and the pull request was accepted and merged to the main brunch.

Generally, the experience was great! It was interesting to check out other's code and collaborate. Moreover, I was extremely excited to see my profile picture and name under the contributors tab. So proud.

Besides that, today was also the day when someone has contributed to my repo for the first time! My friend added a markdown capability for italicized text to my repo and requested a pull. I thoroughly went through all of the changed lines and reviewed the code. It was lovely to see that the other person has followed all of my styling and coding conventions. So respectfully. I forgot to request to change the documentation so I did it myself as it was not a big deal.

So far, I am getting much more comfortable with Git and Github. Cool!

by Gulnur Baimukhambetova at Thu Sep 29 2022 03:48:11 GMT+0000 (Coordinated Universal Time)

Wednesday, September 28, 2022

Chen-Yuan Chu

Merging Branches

Today, I'm just going to talk about what it's like to merge branches using Git.
Git is a wonderful tool that helps you manage your repo. You can switch back and forth between different snapshots of your code you made for each thing you want to add/change and work on them separately. Once you are good, you can combine/merge them back to your main snapshot. A snapshot is called a commit, and it and the history of commits leading up to it is a branch.

The Workflow

To address two changes I wanted to add to the static site generator I talked about in previous posts, I first opened one issue for each: 1 2
Then, I made a branch to work on for each them: 1 2
Spoiler: I did merge them back to the main branch, as you can see!

Once I'm satisfied with the work, I merge them back to the main branch. If there's any conflict, git would put some conflict markers for me to address before continuing. Basically, if it doesn't know which version of the code to keep, it will do that for me to decide. Luckily, it's pretty smart. However, I did some testing just in case. I mean, that's the safe thing to do. And no, everything turned out to be fine thanks to how smart it is.

What are these changes?

Just read the links...I'm kidding.
The first change was adding support to allow language selection for the HTML output files.
I added the option -l or --lang to allow users to specify what language they want to use.
This will decide the lang attribute in the HTML output file. For example, -l pt-BR will indicate the file is in Brazilian Portuguese, and it will have <html lang="pt-BR"> in the HTML code.
The default would be Canadian English: <html lang="en-CA">


  • Added code to allow and recognize -l / --lang option.
  • Added a variable to hold the language value, with en-CA as default.

The second change was adding support for horizontal rule in Markdown input files. Essentially, this allows the tool to parse --- in Markdown files and convert them to <hr> tags in the HTML output files.


  • Added code for file writing to replace --- or longer variations with <hr> tags in the HTML output files.
  • Added code to ignore lines made of tags, such as <hr>. (Only <hr> for now.)

For both, I updated the and help option to let users know these are part of the tool.

Problem And Learning

I forgot to include some of the text explanation for the changes I made in and the help option, when I merge the branches. I ended up adding them afterwards. I should probably remember to include them in the future for organization sake. Other than that, it's mostly stopping myself from wanting to edit a lot of things at once and sticking to the focus of each branch. Sometime, I just see some code or slight formatting issues that I want to edit right there. Hey, I managed, and this teaches me to note things down to address separately.

by Chen-Yuan Chu at Wed Sep 28 2022 23:40:09 GMT+0000 (Coordinated Universal Time)

Alexander Samaniego

DPS909 Blog - Lab 3: Managing Simultaneous Changes

This week for my Open-Source course (DPS909), we were introduced the concept of multiple simultaneous changes in a single project. The purpose of this lab was to help us practice creating branches for specific (simultaneous) issues, merging, dealing with merge conflicts and identifying commits on GitHub.


In lab 2 we practiced creating pull requests (PR) on other people's repositories. In that lab, we only worked on one feature in one branch before creating the PR. Now it's time to start learning how to add multiple features, in parallel, on our own branch by working in separate branches.

Features Added

I continued working on my Static Site Generator and decided to add two more features. I created issues for each feature that I wanted to add.

Issue 14: Support for HTML language codes

The first issue I created focused on adding support for HTML language codes.

In the original state, the HTML files generated automatically defaulted to en as the language code. I wanted to add the ability for a user to be able to specify the language for the generated HTML files by adding a -l/--lang argument.

Code Changes

To accomplish this task, I added a new option using the yargs module. This allows me to read whatever the user inputs after using -l/--l. Following this, I added a conditional statement that defaults to en-CA whenever a language code is not inputted.

Creating the HTML files containing the user specified language code was a simple process. This tool already uses the create-html npm package, so all I needed to do was add the lang option to the createHTML function.

Issue 15: Support for inline code blocks in Markdown files

The second issue I created was focused on adding support for inline code block parsing in Markdown files. So, enclosed text with a single backtick should cause the text to get rendered as <code>...text...</code> in the generated HTML file

Code Changes

This was an even simpler feature to add because there was already existing code to support bold and italic text in Markdown files. The only thing I needed to add was one line that calls the processMD function; which was added in an earlier pull request. This function is able to parse anything with an opening and closing tag. I just needed to specify the tag, in this case it was a backtick( ` ).

Problems and Lessons Learned

I had no real issues during this lab. I attribute this to my effort to trying to make the least amount of code changes possible when adding new features. I only had to fix one conflict in the issue 15 merge commit and it had nothing to do with the actual code, just conflicts in

I also learned how to work with multiple code changes in parallel on separate topic branches. It was a little difficult holding myself back on making unrelated changes whenever I noticed issues. But as I said, holding back was probably the reason I had the least amount of conflicts as possible.

by Alexander Samaniego at Wed Sep 28 2022 21:39:44 GMT+0000 (Coordinated Universal Time)

Denes Adam Dolhay

OSD600 - Lab 3

In this lab we had to work in two parallel branches within our repos.

First I created issue-8 and issue-9

Then, I opened two branches, one for each.
For issue-8 I implemented the --language support, and for issue-9 I implemented the MD file code block support

Then, I merged in Issue-8 first, then after resolving conflicts, I merged issue-9 also.

Adding the language support was very easy, I just added the param to the input param descriptor, and routed the information through the app, and replaced the original placeholder with the new information.

Adding the HR support was a bit more complex, as I needed to add the recognition for standalone --- lines, and in the DOM generator I also needed to add support for hr type blocks

Everything went smoothly, I have already did manual merges, so I am familiar with the process.

by Denes Adam Dolhay at Wed Sep 28 2022 15:55:23 GMT+0000 (Coordinated Universal Time)

Rudy Chung

OSD600 Lab 3

In this lab, I added to my SSG program (SauSaGe) in order to demonstrate the process of working with and merging parallel branches in a project.

What I added

I chose to add features to the existing Markdown parsing functionality of my program that allowed for replacing either a set of three dashes (---) or asterisks (***) with a horizontal rule <hr> tag (#13), as well as parsing of a set of backticks (`) to create a set of <code> tags (#14).

The changes

I was fortunate enough that my code was modularized such that it was easy to add these two features in without disrupting the existing infrastructure. For the horizontal rule change (b27e0b91), I used the existing infrastructure that was provided by #10 to create my own addition. For the code tag change (03d7c91b), I again used the existing infrastructure this time provided by #9, that uses the regex library in C++ to perform token replacements while preserving the token contained between the two matched tokens.

Merging Changes

Merging was a relatively smooth process for the two branches I created, since there were no conflicts between the branches I was merging. In the previous lab however, I did deal with some conflicts having to reconcile code between #9 and #10, since they both added related features. These problems were compounded with the fact that I had some commits that I made which changed the file structure of my project, and altered parts of my code that were not pushed. This caused a whole bevy of problems that I had to reconcile while merging the two pull requests I received.

Lessons for the future

In the future, I will try to push any changes as soon as possible, especially if I am anticipating any pull requests. I will continue to try to keep my code modular as it greatly eases the process of merging changes from pull requests or otherwise to the main branch.

by Rudy Chung at Wed Sep 28 2022 14:47:51 GMT+0000 (Coordinated Universal Time)

Gulnur Baimukhambetova

My first code review and issues!

Hello everyone! 🙋🏻‍♀️

Today, we decided to review each other's code with my friend who also developed his version of the SSG command-line tool (pls see my previous post for details). I found him in one of my courses' slack channels during the previous week and direct messaged him with a request to partner. Luckily, he turned out to be a very kind soul and not only accepted my request but also verbally supported me almost every day afterwards and we became friends. Otherwise, I would have had a fear to message random people on slack for the rest of my life. I am an extravert, but not when it comes to group chats... 😮💨

As both of our projects were on similar topics, it was quite easy to understand how the tool works and what are the instructions. At first, the tool seemed working and I could not think of any issues, but when I checked the code and started reading through every line, I started having ideas for improvement. Remembering the struggles and some error handling techniques from my project also helped me identify which ones my partner could have been missing.

So, these were the issues I filed on my friend's repo:

  • Issue #1 which is basically a documentation improvement.
  • Issue #2 which is also an improvement but for files that are currently uploaded into the GitHub repo. The suggestion is to get rid of the testing files as they are not directly connected to the solution itself and would be installed to the user's machine for no reason.
  • Issue #3 which is a code improvement - an idea on how to shorten the code and avoid repetition.
  • Issue #4 which is also a code improvement for error handling. Right now, if the input file is unsupported, nothing is done to let the user know. Suggestion is to at least log the error.
  • Issue #5 which is a bug connected to the use of files removal function choice. It only works for files and does not consider sub-directories which are possible in some use cases.

Well, my friend also found several improvement ideas and bugs in my solution. So, let's discuss them:

  • Issue #1 is a bug connected to file reading and quotation marks. Basically, all quotation marks needed to be converted into the escape characters in order to be processed correctly and not as end of the string.

  • Issue #2 is a bug which I did not know was a requirement. However, still seemed better to have it. It says that the older output folder needs to be deleted if another output folder has been chosen.

  • Issue #3 is a bug only because we had instructions strictly specifying what each option should do. My version option only showed version, while it needs to display the tool name as well.

  • Issue #4 is an improvement for better readability of the website for different stylesheets. I used the background colour which imitated the old paper feeling but it sometimes did not work with other styling options.

  • Issue #5 is a code improvement for retrieving a value from json object.

All of the issues were fixed and the tool was updated the same day.

It was actually so great to have someone review your code. First, at least now I know that it works for sure not only on my machine but on others. Plus, all of the issues filed we valid improvement ideas and bugs, which I could have missed myself. So, I think it was a very useful activity.


by Gulnur Baimukhambetova at Wed Sep 28 2022 03:05:09 GMT+0000 (Coordinated Universal Time)

My first command-line tool!

Hello everyone!

Today, I want to present to you my first command-line tool that I have been working on in the last three days.

It was part of the course work. However, we were only presented with the requirements. So, no implementation instructions were given.

To be honest, at first, I was so scared. I usually feel alright with figuring the things out along the way, but this project was entirely new. It was focusing on the creation of the command-line tool for static site generation, which I have never done before. I was also never a fan of web development, so it pushed me out of my comfort zone.

However, closer to the end, I realized that I was thinking about implementing the features that I have not been asked to do. I got sucked into the project and truly cared about its development. I wanted to improve it as much as I can. Suddenly, it became so interesting...

So, here it is, my baby SSGulnur!

SSGulnur is a static site generator command-line tool created by me, Gulnur. It allows you to transform txt files into html pages in a matter of seconds. You can also specify the output folder or a stylesheet of your choice.

Below you can see the details:

For the installation, node is required. First clone this repository to your local machine, then navigate to the cloned directory in your terminal and run npm to install globally npm install -g.


ssgulnur -v | --version displays the tool's name and current version.

ssgulnur -h | --help displays a help guide with all instructions.

ssgulnur -i | --input <source>

  • Source can be a single file or folder which can also contain sub-folders.
  • For file names with spaces, please use quotation marks. For example: ssgulnur -i "Example file path.txt".
  • For each provided file an html file will be generated. By default, all html files will be placed into the ./dist folder.
  • All titles need to be the first line in the file followed by two blank lines. Otherwise, it will be considered as part of the story.
  • Different options are available:
    • -o \| --output|<folder> Allows to specify an output folder name. If exists, will be used, if not, gets created. Cannot be a file. By default, ./dist.
    • -s \| --stylesheet|<url> Allows to specify a particular stylesheet to use for html styling. For example,


  • ssgulnur -i "Example file path.txt"
  • ssgulnur --input exampleFolderPath --output exampleOutputFolderPath

You can find the source code here:


by Gulnur Baimukhambetova at Wed Sep 28 2022 00:27:22 GMT+0000 (Coordinated Universal Time)

Tuesday, September 27, 2022

Maxim Nosov

Working in multiple branches - git

Today I have been adding some features to the tool:

1) Added an optional -l, --lang, and/or \l flag, which indicates the language to use when generating the lang attribute on the root element issue-3

For example :

simple-ssg1 silver-blaze -l es

would generate HTML page with

<html lang = "es"/>

2) Added exit codes, if code run successfully and created an html page, then it will return 0, overwise -1. issue-4

It was a great experience to get! I created 2 branches for each of my features. After that on each of the branch I wrote the code.

Upon finishing implementing features, I merged 2 branches with
the main branch (without merge conflicts).

Overall, I enjoyed working on multiple branches, because it gives more capabilities to work with the same code and also that the code you write is not going to effect the main branch.

That's why you can try anything you want without being worried :)

by Maxim Nosov at Tue Sep 27 2022 06:11:37 GMT+0000 (Coordinated Universal Time)