- Take part in Hackita02 program and one of the founders of "Ways Of Time" project that enable the National Library of Israel to upload and geotag
- their geographic maps collection, and open them to the public (Python, Django, Leaflet, PostGIS, MDL).
-
-
- Lead developer of version 2.x of the "Open Pension" project. The project mission is to reveal what happens behind the Israeli pension market,
- while enabling the public to trace the money and expose corruption (Python, Django, Scrapy, PostgreSQL, Angular, ngrx, d3.js).
-
Knowledge focal point for representatives at specialized Call centers.
-
Handling top level customer escalations and Gold customers support.
-
Experience working on UNIX-based switches with HP-UX, And with SAP & Amdocs systems.
-
- Responsible for converting two call centers (Haifa and Beer Sheva) to specialized centers (provide training, and supervision throughout the
- beginning of the activity until go-live operation).
-
Handling customer requirements and providing solutions on Internet, data and technical problems.
-
- Rated at the 10% of the Company's outstanding employees in 2010 and a leader in service in the internet and technical Customer Service Center in
- 2011.
-
diff --git a/src/pages/blog/2014/learn-git-part-1-introduction.md b/src/pages/blog/2014/learn-git-part-1-introduction.md
index 229d760..a2d09d9 100644
--- a/src/pages/blog/2014/learn-git-part-1-introduction.md
+++ b/src/pages/blog/2014/learn-git-part-1-introduction.md
@@ -9,9 +9,6 @@ authorLink: "/about"
tags: ["git", "learn", "github", "cli", "command line", "workflow", "linus torvalds"]
category: "tools"
-hiddenFromHomePage: false
-hiddenFromSearch: false
-
featuredImage: "/posts/2014/learn-git-part-1-introduction/cover.webp"
---
@@ -41,27 +38,27 @@ You had problems? just shout him a question he probably down the hallway. But wh
Like most of CLI (command line) tools, `git` comes with a `help` command. So, if we ever got stuck we can always use it to find out about some command.
-```bash
-$ git help # print all the commands with a simple explanation.
-$ git help config # print all the config command options with a simple explanation.
+```bash showLineNumbers title=" "
+git help # print all the commands with a simple explanation.
+git help config # print all the config command options with a simple explanation.
```
To install git I'll use `brew` (on Mac), but it's pretty easy to install on any OS, just use [this guide](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) for you OS. After we installed it, the first thing we want to do is to set our username and email, so every commit (we'll get to what is commit in the future) will be belong to you.
-```
-$ brew install git
-$ git config --global user.name ""
-$ git config --global user.email ""
+```bash showLineNumbers title=" "
+brew install git
+git config --global user.name ""
+git config --global user.email ""
```
We're ready to start working on our first repository (repo for short). Let's create a new one (just navigate to your wanted location in your file system with `cd`) and then initiate a new repo (you can do it with an empty directory or with a directory with some files in it already). This will create an invisible directory (directory that start with a dot (`.`)) with the name `git`.
-```bash
-$ cd projects
-$ mkdir newProject
-$ git init
+```bash showLineNumbers title=" "
+cd projects
+mkdir newProject
+git init
```
Now we have a local repository (not on any server, local to your computer).
@@ -82,8 +79,13 @@ Once we understand the workflow in theory, we need to practice it.
Maybe the most important command in `git` (in my opinion) is `status` - it allow us to check the changes that were made from the last `commit` (snapshot). Let's see what the result of this command will be after we initiate (with `git init`) the repo, and created a `README.md` file (didn't nothing like adding it to the _staging area_ or `commit` it).
-```bash
-$ git status
+```bash showLineNumbers title=" "
+git status
+```
+
+output:
+
+```txt title=" "
On branch master
No commits yet
@@ -97,16 +99,21 @@ nothing added to commit but untracked files present (use "git add" to track)
We can see we got couple of pieces of information back:
-- We are on branch `master` (we'll take about branches later)
+- We are on branch `main` (we'll take about branches later)
- There is no commits yet in this repo.
- We have a new file (file that `git` doesn't track) in the name of `README.md`
- Nothing was added to the _staging area_, and `git` knows that there're files that it doesn't track yet (so we have something to give him, to adding to the _staging area_).
So let's give `git` what it wants, let's start tracking this `README.md` file (with the `add` command and right after it the file itself), and then do another `status` command to see the output now.
-```bash
-$ git add README.md
-$ git status
+```bash showLineNumbers title=" "
+git add README.md
+git status
+```
+
+output:
+
+```txt title=" "
On branch master
No commits yet
@@ -120,27 +127,42 @@ We see almost the same pieces of information, but now `git` have a file in his _
When we do the `commit` we basically take a snapshot of our file system in this exact time. Even a space means a change. This commit is added to the repo (project) timeline (it's accepted to draw it and imagine it as a timeline, because every `commit` has a timestamp, so we can place them all on a big timeline from the start of the project until now).
-```bash
-$ git commit -m "Created an empty README file"
+```bash showLineNumbers title=" "
+git commit -m "Created an empty README file"
+```
+
+output:
+
+```txt title=" "
[master (root-commit) de7c8db] Created an empty README file
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 README.md
```
-if we write the `status` command again, we'll see there is no changes to be added to the _staging area_ or no changes in the _staging area_ to be `commit`ed. We also can see in the first line that we on branch `master`, for now everything you need to know on branches is that we have a timeline (branch) in the name of `master`, and we `commit` things to that branch (timeline).
+if we write the `status` command again, we'll see there is no changes to be added to the _staging area_ or no changes in the _staging area_ to be `commit`ed. We also can see in the first line that we on branch `main`, for now everything you need to know on branches is that we have a timeline (branch) in the name of `main`, and we `commit` things to that branch (timeline).
+
+```bash showLineNumbers title=" "
+git status
+```
+
+output:
-```bash
-$ git status
+```txt title=" "
On branch master
nothing to commit, working tree clean
```
Now let's make some changes in `README.md` and create a new file named `LICENSE` (like we said Alice did in the [workflow section](#3-workflow)), and run the `status` command again.
-```bash
-$ echo "first change" > README.md
-$ touch LICENSE
-$ git status
+```bash showLineNumbers title=" "
+echo "first change" > README.md
+touch LICENSE
+git status
+```
+
+output:
+
+```txt title=" "
On branch master
Changes not staged for commit:
(use "git add ..." to update what will be committed)
@@ -160,9 +182,14 @@ To commit those files we need to add them to the _staging area_ first, we can do
After we add them, we can use the `status` command again to see what have changed. We can see we have two files in the _staging area_, ready to be `commit`ed, one (`LICENSE`) is a new file, and the other (`README.md`) is a tracked file that just changed (modified).
-```bash
-$ git add --all
-$ git status
+```bash showLineNumbers title=" "
+git add --all
+git status
+```
+
+output:
+
+```txt title=" "
On branch master
Changes to be committed:
(use "git restore --staged ..." to unstage)
@@ -172,8 +199,13 @@ Changes to be committed:
Now let's do a new `commit` (take a second snapshot) and then explore it a little bit.
-```bash
-$ git commit -m "Add a new LICENSE file and finish README"
+```bash showLineNumbers title=" "
+git commit -m "Add a new LICENSE file and finish README"
+```
+
+output:
+
+```txt title=" "
[master 380c1e1] Add a new LICENSE file and finish README
2 files changed, 1 insertion(+)
create mode 100644 LICENSE
@@ -181,13 +213,18 @@ $ git commit -m "Add a new LICENSE file and finish README"
To look at the history, the log, of the current timeline we can use the `log` command. We see there're two `commit`s in the branch (timeline) we're currently at. And also much more information:
-- We're in the `master` branch (timeline).
+- We're in the `main` branch (timeline).
- The `commit`s hash, which is a unique string of number and letters to represent that `commit`. It's basically the name of the `commit`, with it we can reference that `commit`.
- The author and the exact time and date of the `commit`.
- The message of the commit (this is why the message is important. It should be understandable, concise and describe exactly what the changes are. It also accepted to write in present time and not history or future).
-```bash
-$ git log
+```bash showLineNumbers title=" "
+git log
+```
+
+output:
+
+```txt title=" "
commit 380c1e1346008245c8268ccb039538df3e314b87 (HEAD -> master)
Author: Nir Galon
Date: Sat Oct 3 12:51:23 2020 +0300
@@ -203,14 +240,7 @@ Date: Sat Oct 3 02:03:24 2020 +0300
Like the drawing below, we can imagine it as two dots, where each dot is a `commit` (snapshot), and a line (timeline, the `branch`) is connected them. Going from the first (oldest) one at the left, to the newest one at the right. Where the most newest `commit`, the dot to the most right, is our current `commit` (`HEAD`).
-{{< mermaid >}}
-gitGraph:
-options
-{ "nodeSpacing": 150, "nodeRadius": 10 }
-end
-commit
-commit
-{{< /mermaid >}}
+
diff --git a/src/pages/blog/2014/learn-git-part-2-getting-our-hands-dirty.md b/src/pages/blog/2014/learn-git-part-2-getting-our-hands-dirty.md
index c388892..bbfd450 100644
--- a/src/pages/blog/2014/learn-git-part-2-getting-our-hands-dirty.md
+++ b/src/pages/blog/2014/learn-git-part-2-getting-our-hands-dirty.md
@@ -9,9 +9,6 @@ authorLink: "/about"
tags: ["git", "learn", "github", "cli", "command line", "undo", "revert", "repo", "merge", "collaboration"]
category: "tools"
-hiddenFromHomePage: false
-hiddenFromSearch: false
-
featuredImage: "/posts/2014/learn-git-part-2-getting-our-hands-dirty/cover.webp"
---
@@ -25,9 +22,15 @@ So, let's say Alice is just coming in and sat down in her work station, on the c
To see the changes from the last commit, we can use the `diff` command. The output of the command is the changes that aren't in the _staging area_ - changes to files the `git` system already track, but we yet to `add` them and include those new changes.
-The _"old"_ line will begin with a minus (`-`) at the start of the line, and the _"new"_ line of code (with the changes) will begin with a plus (`+`) at the start of it. In our case the `LICENSE` file was empty, so at we only see a plus line with the text we added to the file.
+The _"old"_ line will begin with a minus (`-`) at the start of the line, and the _"new"_ line of code (with the changes) will begin with a plus (`+`) at the start of it. In our case the `LICENSE` file was empty, so we only see a plus line with the text we added to the file.
+
+```bash showLineNumbers title=" "
+git diff
+```
+
+output:
-```bash
+```txt title=" "
diff --git a/LICENSE b/LICENSE
index e69de29..39604a4 100644
--- a/LICENSE
@@ -42,18 +45,28 @@ If we now `add` the `LICENSE` file to the _staging area_ and then run again the
Now, if we use the `status` command, we'll see there is a file changed, added to the _staging area_, and ready to be `commit`ed. But if we didn't mean to add it to the _staging area_ yet? What if Alice didn't finish with this file yet, and want add it to a different `commit` later on?
-To remove files from the _staging area_ we'll use the `reset HEAD ` command. The elephant in the room - the `HEAD` in the command means the last `commit` in the current `branch` (timeline), in our case for the time being is `master`. So we actually reset the file to undo the changes, from the _staging area_, that were made until the last `commit`.
+To remove files from the _staging area_ we'll use the `reset HEAD ` command. The elephant in the room - the `HEAD` in the command means the last `commit` in the current `branch` (timeline), in our case for the time being is `main`. So we actually reset the file to undo the changes, from the _staging area_, that were made until the last `commit`.
+
+```bash showLineNumbers title=" "
+git reset HEAD LICENSE
+```
+
+output:
-```bash
-$ git reset HEAD LICENSE
+```txt title=" "
Unstaged changes after reset:
M LICENSE
```
Now if we run the `status` command, we can see that changes were made to the `LICENSE` file, but are not staged. If we want to undo the changes completely and revert the file to his state in the last `commit` we can do it by using the `checkout `.
-```bash
-$ git checkout LICENSE
+```bash showLineNumbers title=" "
+git checkout LICENSE
+```
+
+output:
+
+```txt title=" "
Updated 1 path from the index
```
@@ -69,9 +82,14 @@ For those type of cases we can use the `reset` command with a new flag, `soft HE
So let's do some change to the `README.md` file, `add` it and `commit` it in one command (with a new flag). This type of `add` and `commit` is only allowed if the files is already been tracked. After we do it, let's use the `reset soft` command to undo it.
-```bash
-$ echo "This is a new line" > README.md
-$ git commit -a -m "Modify README file"
+```bash showLineNumbers title=" "
+echo "This is a new line" > README.md
+git commit -a -m "Modify README file"
+```
+
+output:
+
+```txt title=" "
[master 017a141] Modify README file
1 file changed, 1 insertion(+), 1 deletion(-)
$ git status
@@ -89,8 +107,13 @@ Now we can still edit the `README.md` file and then `commit` everything together
If you only want to add something to the last `commit`, and even change the last `commit` text, a simpler way is to use the `commit` command with the `amend` flag. It'll add everything in the _staging area_ to the last commit and you can change the text of the commit in the process.
-```bash
-$ git commit --amend -m "Add a new LICENSE file and add text to README"
+```bash showLineNumbers title=" "
+git commit --amend -m "Add a new LICENSE file and add text to README"
+```
+
+output:
+
+```txt title=" "
[master 5870e6f] Add a new LICENSE file and add text to README
Date: Sat Oct 3 12:51:23 2020 +0300
2 files changed, 1 insertion(+)
@@ -99,8 +122,13 @@ $ git commit --amend -m "Add a new LICENSE file and add text to README"
Another flag to know it the `hard`, it'll undo the changes like `soft`, but instead of leave them in the _staging area_ it'll delete them entirely like they never existed.
-```bash
-$ git reset --hard HEAD^
+```bash showLineNumbers title=" "
+git reset --hard HEAD^
+```
+
+output:
+
+```txt title=" "
HEAD is now at de7c8db Created an empty README file
```
@@ -134,19 +162,29 @@ After we create the repo we'll get a URL from GitHub. This URL is the URL for th
To `push` our code to the new [GitHub](https://github.com) `remote` repo we first need to config the GitHub repo address (the URL we got from them) as `remote` address so we can later push to that `remote` address. We'll do it with the `remote add ` command.
-```bash
-$ git remote add origin https://github.com/nirgn975/test.git
-$ git remote -v
+```bash showLineNumbers title=" "
+git remote add origin https://github.com/nirgn975/test.git
+git remote -v
+```
+
+output:
+
+```txt title=" "
origin https://github.com/nirgn975/test.git (fetch)
origin https://github.com/nirgn975/test.git (push)
```
I bet the first thing that comes to your head is "why we call our remote alias `origin`?", You're right, it's a bit wired, we can all if whatever we want. But `origin` is just a standard convention, and we'll love conventions. And the second command is just a way to print all the `remote` addresses, so we just make sure everything was added successfully.
-Now, it's finally time to push our local branch (timeline) `master` to `origin` (the GitHub repo). You'll need to fill your username and password so GitHub will check if you have permissions to push to that repo.
+Now, it's finally time to push our local branch (timeline) `main` to `origin` (the GitHub repo). You'll need to fill your username and password so GitHub will check if you have permissions to push to that repo.
-```bash
-$ git push origin master
+```bash showLineNumbers title=" "
+git push origin master
+```
+
+output:
+
+```txt title=" "
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 224 bytes | 224.00 KiB/s, done.
@@ -159,8 +197,13 @@ If we refresh the GitHub repo page we'll see the `README` file there, and a new
So, we `push`ed our repo to a `remote` source on GitHub (or any other `git` hosting), but how can Bob take this code to his local machine? Like we said before, with the `pull` command (we'll also use the `pull` command to sync our local repo with the `remote` one, so get changes other team members did and `push`).
-```bash
-$ git pull origin master
+```bash showLineNumbers title=" "
+git pull origin master
+```
+
+output:
+
+```txt title=" "
From github.com:nirgn975/test
* branch master -> FETCH_HEAD
Already up to date.
@@ -178,66 +221,91 @@ So, let's say Bob is working with Alice on the same team. It's his first day, an
-```bash
-$ git clone https://github.com/nirgn975/test.git
+```bash showLineNumbers title=" "
+git clone https://github.com/nirgn975/test.git
```
The repo will be cloned on your local machine, in the directory that you were at in the terminal, to a new directory with the name of the of the repo. When you `clone` the repo to your local machine, the `git` system does 3 things:
1. Download the repo to your local machine in a directory with the name of the repo.
2. Add a `remote` with the `origin` name that alias to the repo URL.
-3. `git` will configure a branch named `master` and point the `HEAD` to be the last `commit` from the `master` branch in the `origin`.
+3. `git` will configure a branch named `main` and point the `HEAD` to be the last `commit` from the `main` branch in the `origin`.
## 5. Merge the branches
-Bob is ready now to work on the new feature, but to do this it's better to create a new `branch` (timeline) and not to work on the same main `branch` of the project (`master`). This is because while he work on his own feature, other people working on theirs features or bugs too, and if everyone will work on the same branch and `commit` frequently, it'll create a mess, and everyone will _"resolve conflicts"_ all of the time instead of working.
+Bob is ready now to work on the new feature, but to do this it's better to create a new `branch` (timeline) and not to work on the same main `branch` of the project (`main`). This is because while he work on his own feature, other people working on theirs features or bugs too, and if everyone will work on the same branch and `commit` frequently, it'll create a mess, and everyone will _"resolve conflicts"_ all of the time instead of working.
-To create a new `branch` out (or splits if you want) of the main `master` branch (the current branch we're in right now) can be done using the `branch` command.
+To create a new `branch` out (or splits if you want) of the main `main` branch (the current branch we're in right now) can be done using the `branch` command.
-```bash
-$ git branch home-page
+```bash showLineNumbers title=" "
+git branch home-page
```
After we created the new branch, let's check on which branch we're in right now.
-```bash
-$ git branch
+```bash showLineNumbers title=" "
+git branch
+```
+
+output:
+
+```txt title=" "
home-page
* master
```
-We're still on `master`. So to move to the `home-page` branch, we'll use the `checkout` command.
+We're still on `main`. So to move to the `home-page` branch, we'll use the `checkout` command.
-```bash
-$ git checkout home-page
+```bash showLineNumbers title=" "
+git checkout home-page
+```
+
+output:
+
+```txt title=" "
Switched to branch 'home-page'
```
-Now we're in a different timeline (`branch`), we can do whatever we want and it'll just do it just in the `home-page` branch, and nothing will infect our `master` branch. Any time we want to can go back to `master` branch, and see the repo from `master` branch point of view (timeline).
+Now we're in a different timeline (`branch`), we can do whatever we want and it'll just do it just in the `home-page` branch, and nothing will infect our `main` branch. Any time we want to can go back to `main` branch, and see the repo from `main` branch point of view (timeline).
-In the meantime, while we work on our feature, if other members of the project finish their own work and merge it to `master`, we can always `checkout` back to `master`, and `pull` the new `commit`s in `master`, to see our coworkers job.
+In the meantime, while we work on our feature, if other members of the project finish their own work and merge it to `main`, we can always `checkout` back to `main`, and `pull` the new `commit`s in `main`, to see our coworkers job.
Now that we're on a new branch (`home-page`), let's create a new file called `index.html`, inside of it we'll add the basic html code we need for a simple web page, `add` it to the _staging area_, and commit the file.
-```bash
+```bash showLineNumbers title=" "
$ touch index.html
$ echo "\n\t\n\t\twebsite title\n\t\n\t\n\t\tcontent of website ...\n\t\n" >> index.html
$ git add index.html
$ git commit -m "Add basic html code"
```
-The `commit` we just did, will be added to the current (`home-page`) timeline (`branch`), and will not be seen in any other `branch`. If we write the `ls` command in the terminal (in the current directory) we'll see all of our project files (`README.md` and `index.html`), but if we'll `checkout` to the `master` branch we'll not see the `index.html` file, even if we write the `git log` command, we'll not see our latest `commit` in there.
+The `commit` we just did, will be added to the current (`home-page`) timeline (`branch`), and will not be seen in any other `branch`. If we write the `ls` command in the terminal (in the current directory) we'll see all of our project files (`README.md` and `index.html`), but if we'll `checkout` to the `main` branch we'll not see the `index.html` file, even if we write the `git log` command, we'll not see our latest `commit` in there.
Let's just check we aren't crazy and `checkout` back to the `home-page` branch, and then with the `ls` command makes sure we see our `index.html` file.
-So, let's say we're done with this task, we did all of the things we had to do here and we're ready to `merge` this `home-page` branch to the `master` branch. To do this we're first need to go to the branch we want to `merge` things to (in our case `master`), and then use the `merge` command to actually merge the code from the other branch to the branch we are at right now.
+So, let's say we're done with this task, we did all of the things we had to do here and we're ready to `merge` this `home-page` branch to the `main` branch. To do this we're first need to go to the branch we want to `merge` things to (in our case `main`), and then use the `merge` command to actually merge the code from the other branch to the branch we are at right now.
+
+```bash showLineNumbers title=" "
+git checkout master
+```
+
+output:
-```bash
-$ git checkout master
+```txt title=" "
Switched to branch 'master'
-$ git merge home-page
+```
+
+and then
+
+```bash showLineNumbers title=" "
+git merge home-page
+```
+
+output:
+
+```txt title=" "
Updating de7c8db..bfb8f2b
Fast-forward
index.html | 8 ++++++++
@@ -249,21 +317,31 @@ We can see that `git` tells us it's update the branch by _"Fast forward"_, but w
When we finished `merge`ing the `branch`, we don't need it anymore, so we can just delete it. We'll use the `branch` command with the `d` flag to do it.
-```bash
-$ git branch -d home-page
+```bash showLineNumbers title=" "
+git branch -d home-page
+```
+
+output:
+
+```txt title=" "
Deleted branch home-page (was bfb8f2b).
```
Now let's create a new `branch` to work on a new task, the branch will be called `basic-main` (because we'll add some basic code to the main website page - `index.html`). We can create the branch and then move to it in two separate commands like we did before, but there is a simpler way! We can use the `checkout` command with a flag (`b`) that tells to create the branch if doesn't exist yet, so this way, in one command we create the branch and then move (`checkout`) to it.
-```bash
-$ git checkout -b basic-main
+```bash showLineNumbers title=" "
+git checkout -b basic-main
+```
+
+output:
+
+```txt title=" "
Switched to a new branch 'basic-main'
```
Then we'll add the `Go to detailed page!` line right after `content of website ..`.
-```html
+```html showLineNumbers title="index.html"
website title
@@ -277,14 +355,29 @@ Then we'll add the `Go to detailed page!` line right
Now we can `commit` the change in `index.html` and create a new page, `detailed.html` that the link will redirect us to (when we click it).
-```bash
-$ git commit -a -m "Add a link to detailed page"
+```bash showLineNumbers title=" "
+git commit -a -m "Add a link to detailed page"
+```
+
+output:
+
+```txt title=" "
[basic-main e979b01] Add a link to detailed page
1 file changed, 7 insertions(+), 6 deletions(-)
-$ touch detailed.html
-$ echo "\n\t\n\t\twebsite title\n\t\n\t\n\t\t
\n\t\n" >> detailed.html
+git add detailed.html
+git commit -a -m "Finish detailed page"
+```
+
+output:
+
+```txt title=" "
[basic-main af3853e] Finish detailed page
1 file changed, 8 insertions(+)
create mode 100644 detailed.html
@@ -292,38 +385,57 @@ $ git commit -a -m "Finish detailed page"
Let's imagine how our repo branches (timelines) is looking right now.
-{{< mermaid >}}
-gitGraph:
-options
-{ "nodeSpacing": 100, "nodeRadius": 10 }
-end
-commit
-commit
-branch basicmain
-checkout basicmain
-commit
-commit
-{{< /mermaid >}}
-
-Right in the middle of our work on the `basic-main` branch, we get an email from our boss that there are bugs in `master` and we need to take care of it immediately. So let's head over to `master` (you can run `git branch` after you `checkout` to `master` just to make sure you're on `master`).
-
-```bash
-$ git checkout master
+
+
+Right in the middle of our work on the `basic-main` branch, we get an email from our boss that there are bugs in `main` and we need to take care of it immediately. So let's head over to `main` (you can run `git branch` after you `checkout` to `main` just to make sure you're on `main`).
+
+```bash showLineNumbers title=" "
+git checkout master
+```
+
+output:
+
+```txt title=" "
Switched to branch 'master'
```
-We don't know if anyone of our team members done with their work and `merge` it to `master` while we worked on our feature branch, so let's make sure we have an updated `master` by `pull`ing any new `commit`s from `origin`. Let's fix what we need to fix, and `commit` and `push` it to `origin`.
+We don't know if anyone of our team members done with their work and `merge` it to `main` while we worked on our feature branch, so let's make sure we have an updated `main` by `pull`ing any new `commit`s from `origin`. Let's fix what we need to fix, and `commit` and `push` it to `origin`.
-```bash
-$ git pull origin master
+```bash showLineNumbers title=" "
+git pull origin master
+```
+
+output:
+
+```txt title=" "
From github.com:nirgn975/test
* branch master -> FETCH_HEAD
Already up to date.
-$ echo "# Awesome Website\n\nThis is the repo for the awesome website" >> README.md
-$ git commit -a -m "Add a description for the repo"
+```
+
+then
+
+```bash showLineNumbers title=" "
+echo "# Awesome Website\n\nThis is the repo for the awesome website" >> README.md
+git commit -a -m "Add a description for the repo"
+```
+
+output:
+
+```txt title=" "
[master c247760] Add a description for the repo
1 file changed, 3 insertions(+)
+```
+
+and finally
+
+```bash showLineNumbers title=" "
$ git push origin master
+```
+
+output:
+
+```txt title=" "
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 16 threads
@@ -334,18 +446,55 @@ To github.com:nirgn975/test.git
de7c8db..0baa97a master -> master
```
-Now that we put out the fire, let's head over to our `basic-main` branch, finish the work, `commit` it, and head back to `master` to merge it.
+Now that we put out the fire, let's head over to our `basic-main` branch, finish the work, `commit` it, and head back to `main` to merge it.
-```bash
+```bash showLineNumbers title=" "
$ git checkout basic-main
+
+```
+
+output:
+
+```txt title=" "
Switched to branch 'basic-main'
-$ sed -i '' "s/content of website .../Welcome to the new website/g" index.html
-$ git commit -a -m "Change welcome message"
+```
+
+then
+
+```bash showLineNumbers title=" "
+sed -i '' "s/content of website .../Welcome to the new website/g" index.html
+git commit -a -m "Change welcome message"
+
+```
+
+output:
+
+```txt title=" "
[basic-main a0ff187] Change welcome message
1 file changed, 1 insertion(+), 1 deletion(-)
-$ git checkout master
+```
+
+then switch branches
+
+```bash showLineNumbers title=" "
+git checkout master
+```
+
+otuput:
+
+```txt title=" "
Switched to branch 'master'
-$ git merge basic-main
+```
+
+and finally
+
+```bash showLineNumbers title=" "
+git merge basic-main
+```
+
+output:
+
+```txt title=" "
Merge made by the 'recursive' strategy.
detailed.html | 8 ++++++++
index.html | 13 +++++++------
@@ -359,24 +508,7 @@ Because we merge two branches with changes in each of them, `git` is doing a _"r
Let's imagine how to whole process looks like visually.
-{{< mermaid >}}
-gitGraph:
-options
-{ "nodeSpacing": 100, "nodeRadius": 10 }
-end
-commit
-commit
-branch basicmain
-checkout basicmain
-commit
-commit
-checkout master
-commit
-checkout basicmain
-commit
-checkout master
-merge basicmain
-{{< /mermaid >}}
+
@@ -420,6 +552,6 @@ It's time to practice. Remember that the best practice is through your fingertip
We now know how to see the changes that were made from the last `commit`, how to go back if we regret something we did in a `commit` or the commit message, or even forget to add something to the `commit`.
-We upload the project to a remote repository (GitHub in this case), we created new branches, worked with other team members, and merge our code to the `master` branch (we go over a `merge` with no changes in `master` and with one **with** changes in `master`, but not in the same file - we'll talk about it in future chapter).
+We upload the project to a remote repository (GitHub in this case), we created new branches, worked with other team members, and merge our code to the `main` branch (we go over a `merge` with no changes in `main` and with one **with** changes in `main`, but not in the same file - we'll talk about it in future chapter).
We definitely learned a lot in this chapter! Don't forget to practice it through your fingers, it's the best way to learn something new. And don't hesitate to ask questions in the comments if something is not clear - I'll do my best to help.
diff --git a/src/pages/blog/2014/learn-git-part-3-start-collaborate.md b/src/pages/blog/2014/learn-git-part-3-start-collaborate.md
index a933105..180385c 100644
--- a/src/pages/blog/2014/learn-git-part-3-start-collaborate.md
+++ b/src/pages/blog/2014/learn-git-part-3-start-collaborate.md
@@ -9,237 +9,7 @@ authorLink: "/about"
tags: ["git", "learn", "github"]
category: "tools"
-hiddenFromHomePage: false
-hiddenFromSearch: false
-
featuredImage: "/posts/2014/learn-git-part-3-start-collaborate/cover.webp"
---
I think everybody here at least heard about [GitHub](https://github.com) and maybe even about the file management system called [git](https://git-scm.com) which is everywhere in the development world those days. So, as a computer science student I choose to learn it, and what batter way to learn something then to write about it.
-
-So in this series of posts I'll document my journey to learn git (which is the base of GitHub as the only version control you can use on the platform). I hope more people can use it as a learning document or even to deepen their knowledge in the tool.
-
-
-
-## 1. Some General Knowledge
-
-git is a distribute version control (basically a file management system with a db to save the changes that were made to those files over time) created by [Linus Torvalds](https://en.wikipedia.org/wiki/Linus_Torvalds) in 2005. Why he even created it you ask? He and some other Linux Kernel developers weren't happy with the source-control management (SCM) software they used at the time (BitKeeper). You can read in the [Wikipedia page of git](https://en.wikipedia.org/wiki/Git) about what exactly their issues was, but this is out of the scope of this post.
-
-**Why I even need a source control system?**
-
-This is a valid question. In the old days you were just edit your code, FTP it to your server, and that's it. Maybe you have one more fellow developer with you on the same project, he would have send you a piece of code, you paste it in the exact location in the file he told you too and that's it - FTP it to the server.
-
-You had problems? just shout him a question he probably down the hallway. But when software started to eat the world, getting bigger, more complex, with bigger teams, in different places in the world and different time zones it started to get messier. You need a version control to manage the code in different computers, try to merge pieces of code together, save the history (the changes that were made so we can go back in time in case we encounter some issue), and even want to know who made those changes.
-
-**How GitHub is related to all of this?**
-
-[GitHub](https://github.com) is a hosting company for `git` (repositories). The service was founded in 2008 and hosts public repos for free and private ones for a fee. But, from that simple idea, GitHub built a fully fledged software management system, it's now basically a way to manage the whole project with some social media capabilities and a way to share and contribute code.
-
-
-
-## 2. Simple Commands
-
-Like most of CLI (command line) tools, `git` comes with a `help` command. So, if we ever got stuck we can always use it to find out about some command.
-
-```bash
-$ git help # print all the commands with a simple explanation.
-$ git help config # print all the config command options with a simple explanation.
-```
-
-
-
-To install git I'll use `brew` (on Mac), but it's pretty easy to install on any OS, just use [this guide](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) for you OS. After we installed it, the first thing we want to do is to set our username and email, so every commit (we'll get to what is commit in the future) will be belong to you.
-
-```
-$ brew install git
-$ git config --global user.name ""
-$ git config --global user.email ""
-```
-
-We're ready to start working on our first repository (repo for short). Let's create a new one (just navigate to your wanted location in your file system with `cd`) and then initiate a new repo (you can do it with an empty directory or with a directory with some files in it already). This will create an invisible directory (directory that start with a dot (`.`)) with the name `git`.
-
-```bash
-$ cd projects
-$ mkdir newProject
-$ git init
-```
-
-Now we have a local repository (not on any server, local to your computer).
-
-
-
-## 3. Workflow
-
-Before we continue diving with the tool, I would like to take couple of minutes to go over the workflow with `git`. For convince I would borrow some names from the cryptography world: Alice and Bob. Let's suppose Alice created a file `README.md` and when a new file is created, it's start his life as an untracked file (that's means that the `git` system doesn't know about it), to make `git` track this file we need to add it to the _staging area_, and finally we make a `commit` - that's a `git` command to take a snapshot of all the files in the _staging area_.
-
-Now let's assume Alice working some more on the `README.md` file, doing some changes and even add a new file `LICENSE`, when she done, she need to add both of those files to the _staging area_, again, and `commit` those changes. This is pretty much will be our workflow at the moment. We'll making some work -> add the work that we done to the _staging area_ -> and commit it (taking the snapshot).
-
-
-
-## 4. More Commands
-
-Once we understand the workflow in theory, we need to practice it.
-
-Maybe the most important command in `git` (in my opinion) is `status` - it allow us to check the changes that were made from the last `commit` (snapshot). Let's see what the result of this command will be after we initiate (with `git init`) the repo, and created a `README.md` file (didn't nothing like adding it to the _staging area_ or `commit` it).
-
-```bash
-$ git status
-On branch master
-
-No commits yet
-
-Untracked files:
- (use "git add ..." to include in what will be committed)
- README.md
-
-nothing added to commit but untracked files present (use "git add" to track)
-```
-
-We can see we got couple of pieces of information back:
-
-- We are on branch `master` (we'll take about branches later)
-- There is no commits yet in this repo.
-- We have a new file (file that `git` doesn't track) in the name of `README.md`
-- Nothing was added to the _staging area_, and `git` knows that there're files that it doesn't track yet (so we have something to give him, to adding to the _staging area_).
-
-So let's give `git` what it wants, let's start tracking this `README.md` file (with the `add` command and right after it the file itself), and then do another `status` command to see the output now.
-
-```bash
-$ git add README.md
-$ git status
-On branch master
-
-No commits yet
-
-Changes to be committed:
- (use "git rm --cached ..." to unstage)
- new file: README.md
-```
-
-We see almost the same pieces of information, but now `git` have a file in his _staging area_ (a file ready to be `commit`ed). So, it's time to do our first `commit`. To do this we'll use the `commit` command. A flag that the `commit` command have is `m` which means _"message"_, with this flag we can add a message to the `commit` to describe the changes this `commit` is do.
-
-When we do the `commit` we basically take a snapshot of our file system in this exact time. Even a space means a change. This commit is added to the repo (project) timeline (it's accepted to draw it and imagine it as a timeline, because every `commit` has a timestamp, so we can place them all on a big timeline from the start of the project until now).
-
-```bash
-$ git commit -m "Created an empty README file"
-[master (root-commit) de7c8db] Created an empty README file
- 1 file changed, 0 insertions(+), 0 deletions(-)
- create mode 100644 README.md
-```
-
-if we write the `status` command again, we'll see there is no changes to be added to the _staging area_ or no changes in the _staging area_ to be `commit`ed. We also can see in the first line that we on branch `master`, for now everything you need to know on branches is that we have a timeline (branch) in the name of `master`, and we `commit` things to that branch (timeline).
-
-```bash
-$ git status
-On branch master
-nothing to commit, working tree clean
-```
-
-Now let's make some changes in `README.md` and create a new file named `LICENSE` (like we said Alice did in the [workflow section](#3-workflow)), and run the `status` command again.
-
-```bash
-$ echo "first change" > README.md
-$ touch LICENSE
-$ git status
-On branch master
-Changes not staged for commit:
- (use "git add ..." to update what will be committed)
- (use "git restore ..." to discard changes in working directory)
- modified: README.md
-
-Untracked files:
- (use "git add ..." to include in what will be committed)
- LICENSE
-
-no changes added to commit (use "git add" and/or "git commit -a")
-```
-
-`git` knows that the `README.md` file has changed! and those changes are not staged (not in the _staging area_, not ready to be `commit`ed). `git` also noticed we created a new file that it doesn't track (`LICENSE`).
-
-To commit those files we need to add them to the _staging area_ first, we can do it like we did it earlier with the `add` command and the two files (with a space between them), but we can do it more efficiently with the `all` flag - which will add all of the changes and untracked files to the _staging area_ (be careful with this flag because something you).
-
-After we add them, we can use the `status` command again to see what have changed. We can see we have two files in the _staging area_, ready to be `commit`ed, one (`LICENSE`) is a new file, and the other (`README.md`) is a tracked file that just changed (modified).
-
-```bash
-$ git add --all
-$ git status
-On branch master
-Changes to be committed:
- (use "git restore --staged ..." to unstage)
- new file: LICENSE
- modified: README.md
-```
-
-Now let's do a new `commit` (take a second snapshot) and then explore it a little bit.
-
-```bash
-$ git commit -m "Add a new LICENSE file and finish README"
-[master 380c1e1] Add a new LICENSE file and finish README
- 2 files changed, 1 insertion(+)
- create mode 100644 LICENSE
-```
-
-To look at the history, the log, of the current timeline we can use the `log` command. We see there're two `commit`s in the branch (timeline) we're currently at. And also much more information:
-
-- We're in the `master` branch (timeline).
-- The `commit`s hash, which is a unique string of number and letters to represent that `commit`. It's basically the name of the `commit`, with it we can reference that `commit`.
-- The author and the exact time and date of the `commit`.
-- The message of the commit (this is why the message is important. It should be understandable, concise and describe exactly what the changes are. It also accepted to write in present time and not history or future).
-
-```bash
-$ git log
-commit 380c1e1346008245c8268ccb039538df3e314b87 (HEAD -> master)
-Author: Nir Galon
-Date: Sat Oct 3 12:51:23 2020 +0300
-
- Add a new LICENSE file and finish README
-
-commit de7c8db1ce767a3a757d760cb7200abe9d847c65
-Author: Nir Galon
-Date: Sat Oct 3 02:03:24 2020 +0300
-
- Created an empty README file
-```
-
-Like the drawing below, we can imagine it as two dots, where each dot is a `commit` (snapshot), and a line (timeline, the `branch`) is connected them. Going from the first (oldest) one at the left, to the newest one at the right. Where the most newest `commit`, the dot to the most right, is our current `commit` (`HEAD`).
-
-{{< mermaid >}}
-gitGraph:
-options
-{ "nodeSpacing": 150, "nodeRadius": 10 }
-end
-commit
-commit
-{{< /mermaid >}}
-
-
-
-## 5. Q & A
-
-Let's practice a little bit by going over the things we learned.
-
-### **Questions**
-
-1. You want to initiate a new repo. You're already in a directory with a file, what command do you write to do it?
-2. You created some files, made a few `commit`s, you updated some files and the day is over, you want to do your last `commit` for the day and go home. But you don't remember what files you have changed from the last `commit`, what command can help you see the changes from the last `commit`?
-3. You found out with the last command that you have only one file changed (`index.html`), make him ready to be `commit`ed.
-4. Make a `commit`.
-5. You created a new directory (`css`), with couple of files, add the entire directory (with all of it's files) to the _staging area_.
-6. A colleague goes by your desk and ask you what have you been `commit`ed today, what command do you write to show him?
-
-### **Answers**
-
-1. The `git init` command.
-2. The `git status` command.
-3. The `git add` command: `git add index.html`.
-4. The `git commit` command: `git commit -m "Add index.html"`.
-5. To add an entire directory we'll just write it: `git add css`.
-6. The `git log` command.
-
-
-
-## 6. Summary
-
-So, we learn a bit about the history of `git`, why do we need it and how [GitHub](https://github.com) is related. From there we move on the learn some basic commands, the git workflow, and then to some of the most used commands in `git`.
-
-I recommend to learn through your fingers - to write all the commands yourself and see the output in your terminal. This is the best way to learn! Don't copy and paste answers to your terminal, write them yourself, slowly it'll get through and you'll remember and understand it all in no time.
diff --git a/src/pages/blog/2017/jekyll-starter-kit-generator-2.1.0-is-out.md b/src/pages/blog/2017/jekyll-starter-kit-generator-2.1.0-is-out.md
index 7291c90..31091d4 100644
--- a/src/pages/blog/2017/jekyll-starter-kit-generator-2.1.0-is-out.md
+++ b/src/pages/blog/2017/jekyll-starter-kit-generator-2.1.0-is-out.md
@@ -9,9 +9,6 @@ authorLink: "/about"
tags: ["jekyll", "contribution", "github", "generator", "starter kit", "yeoman", "pwa", "npm"]
category: "contribution"
-hiddenFromHomePage: false
-hiddenFromSearch: false
-
featuredImage: "/posts/2017/jekyll-starter-kit-generator-2.1.0-is-out/jekyll-starter-kit.webp"
---
diff --git a/src/pages/blog/2017/load-balancing-applications-with-haproxy-and-docker.md b/src/pages/blog/2017/load-balancing-applications-with-haproxy-and-docker.md
index 8aa1dfb..7ab47f8 100644
--- a/src/pages/blog/2017/load-balancing-applications-with-haproxy-and-docker.md
+++ b/src/pages/blog/2017/load-balancing-applications-with-haproxy-and-docker.md
@@ -9,15 +9,12 @@ authorLink: "/about"
tags: ["development", "contribution", "docker", "haproxy", "load balance", "cloud", "devops", "nginx"]
category: "tutorials"
-hiddenFromHomePage: false
-hiddenFromSearch: false
-
featuredImage: "/posts/2017/load-balancing-applications-with-haproxy-and-docker/lets-start.webp"
---
A tutorial for a real world docker use case.
-Recently I read a lot of articles about load balancing applications with Docker, Docker Compose, and Docker Swarm for my work. We have a couple of hundreds of instances and we need to manage them and do load balancing between them.
+Recently I read a lot of articles about load balancing applications with [Docker](https://www.docker.com), Docker Compose, and Docker Swarm for my work. We have a couple of hundreds of instances and we need to manage them and do load balancing between them.
There are a lot of articles about this topic, but sadly the use case they present is quit simple and because of that they really don’t help. Here is a couple of examples to what I mean:
@@ -33,7 +30,7 @@ For that reason I decided to write this post and present the way we use. It’s
Let’s start by creating our simple Node.js application. Create a file named `index.js` with the following code:
-```javascript
+```javascript showLineNumbers title="index.js"
var http = require("http");
var os = require("os");
http
@@ -46,7 +43,7 @@ http
Now we need to dockerize the app, so we’ll create a file named `Dockerfile` with the following code:
-```yaml
+```yaml showLineNumbers title="Dockerfile"
FROM node
RUN mkdir -p /usr/src/app
COPY index.js /usr/src/app
@@ -62,9 +59,9 @@ Now we have a docker image of our simple (and awesome) Node.js app, and we can c
## 2. Enter Docker Compose
-For our HTTP server we’ll use HAProxy, that means we need to create a container with HAProxy that will listen to port 80 and load balance the requests to the different Node.js containers on port 8080. To create our containers (Node.js apps and HAProxy) we’ll use Docker Compose, let’s write our `docker-compose.yml` file:
+For our HTTP server we’ll use [HAProxy](http://www.haproxy.org), that means we need to create a container with HAProxy that will listen to port 80 and load balance the requests to the different Node.js containers on port 8080. To create our containers (Node.js apps and HAProxy) we’ll use [Docker Compose](https://docs.docker.com/compose), let’s write our `docker-compose.yml` file:
-```yaml
+```yaml showLineNumbers title="docker-compose.yml"
version: "3"
services:
@@ -137,7 +134,7 @@ Now let’s look at our services by writing `docker service ls` and we’ll see
We can also create a second version of our `awesome` app. Let’s change the code a little bit (let’s add some exclamation marks at the end):
-```javascript
+```javascript showLineNumbers title="index.js"
var http = require("http");
var os = require("os");
http
diff --git a/src/pages/blog/2020/chapter-1-simple-twitter.md b/src/pages/blog/2020/chapter-1-simple-twitter.md
index 602ae5d..e92beba 100644
--- a/src/pages/blog/2020/chapter-1-simple-twitter.md
+++ b/src/pages/blog/2020/chapter-1-simple-twitter.md
@@ -6,12 +6,9 @@ draft: false
author: "Nir Galon"
authorLink: "/about"
-tags: ["twitter", "development", "git", "github", "atom", "angular", "node.js", "monogodb", "robo 3t", "gcloud", "kubectl", "brew"]
+tags: ["twitter", "development", "git", "github", "atom", "vuejs", "node.js", "monogodb", "robo 3t", "gcloud", "docker", "brew"]
category: "development"
-hiddenFromHomePage: false
-hiddenFromSearch: false
-
featuredImage: "/posts/2020/chapter-1-simple-twitter/simple-twitter-cover.webp"
---
@@ -35,8 +32,8 @@ While I'm using Mac and I'll show how to install everything on a Mac, it should
I recommend to use a package manager to install everything on your machine, on mac it's `brew`. Once you have [brew](https://brew.sh/) installed on your machine all you need to do to install `git` is:
-```shell
-$ brew install git
+```bash showLineNumbers title=" "
+brew install git
```
That's it, now if you'll write `git` on your command line of choice you'll get as an output all the git commands you can use.
@@ -51,9 +48,9 @@ GitHub is a web based git with some extra features. We don't need to install any
After you sign up you'll need to confirm your account, so check your email. Now we need to config our local `git` with our `email` and `username`. We can do it by typing those command:
-```shell
-$ git config --global user.name "Nir Galon"
-$ git config --global user.email nir@galon.io
+```bash showLineNumbers title=" "
+git config --global user.name "Nir Galon"
+git config --global user.email nir@galon.io
```
That's it for now. Once we'll have some code, we'll open a new repository, commit the code to GitHub and talk about issues and pull requests.
@@ -64,15 +61,15 @@ My code editor of choice is [Atom](https://atom.io/). But you have plenty of cho
To install Atom with `brew` we need to add [cask](https://github.com/Homebrew/homebrew-cask), cask extends brew (Homebrew) and let us install macOS applications with brew. So let's add `cask`:
-```shell
-$ brew update
-$ brew tap caskroom/cask
+```bash showLineNumbers title=" "
+brew update
+brew tap caskroom/cask
```
And now we can install Atom
-```shell
-$ brew cask install atom
+```bash showLineNumbers title=" "
+brew cask install atom
```
@@ -87,10 +84,10 @@ MongoDB has it's advantages and disadvantages, but for our use case it fits the
To install MongoDB we'll head over to the [MongoDB documentation](https://docs.mongodb.com/manual/tutorial/install-mongodb-on-os-x) and go through the instructions. First we'll add their tap to `brew`, then we'll install the mongodb community edition, and finally start the database through [brew services](https://github.com/Homebrew/homebrew-services).
-```shell
-$ brew tap mongodb/brew
-$ brew install mongodb-community
-$ brew services start mongodb-community
+```bash showLineNumbers title=" "
+brew tap mongodb/brew
+brew install mongodb-community
+brew services start mongodb-community
```
Now we have MongoDB installed and running on our local machine. But how can we see and run stuff?
@@ -103,8 +100,8 @@ Robo 3T is a free and open-source cross-platform MongoDB GUI. With it we can see
Success! so let's install it with `brew cask`
-```shell
-$ brew cask install robo-3t
+```bash showLineNumbers title=" "
+brew cask install robo-3t
```
@@ -117,8 +114,8 @@ To build our backend we'll use [Typescript](https://www.typescriptlang.org/). Ty
I want to believe you already understand how useful is a package manager by now, but if you haven't let's use it again and install Node.js.
-```shell
-$ brew install node
+```bash showLineNumbers title=" "
+brew install node
```
### 3.2. NPM
@@ -131,33 +128,50 @@ When we'll build our backend we'll want to make requests to it and tests our cod
[Insomnia](https://insomnia.rest) is one of the most popular ones out there, it's free and has a lot more features, so let's install it
-```shell
-$ brew cask install insomnia
+```bash showLineNumbers title=" "
+brew cask install insomnia
```
## 4. Frontend Setup
-To build our Frontend we'll use [Angular](https://angular.io/). Angular is a typeScript based open source web application framework led by Google. Okay, this is a lot of words, we know what is a web application (a user interface and logic that runs in a web browser), but what is a framework?
+To build our Frontend we'll use [Vue.js](https://vuejs.org/). Vue is a JavaScript framework for building user interfaces. Okay, this is a lot of words, we know what is a web application (a user interface and logic that runs in a web browser), but what is a framework?
A framework is an abstraction layer that may include support programs, compilers, code libraries, tool sets, and more. it's aim to facilitate software developments by allowing us to devote our time to meeting software requirements rather than dealing with the more standard low-level details of providing a working system.
-### 4.1 Angular CLI
+### 4.1 The official Vue scaffolding tool
+
+[`create-vue`](https://github.com/vuejs/create-vue) is the official Vue.js project scaffolding tool. It'll present to you some prompts for a number of optional features such as TypeScript and testing support, and will help us create a new project with everyting already configured.
-Angular has a [CLI (Command Line Interface)](https://en.wikipedia.org/wiki/Command-line_interface) (surprisingly called [Angular CLI](https://cli.angular.io/)) to help us create a new project and components in the Angular way. It saves us time and guide us in the "right" direction.
+it help us create a new project and components in the way. It saves us time and guide us in the "right" direction.
-Angular is a JavaScript framework, so we'll use the JavaScript package manager, `npm`, to install it.
+```bash showLineNumbers title=" "
+npm init vue@latest
+```
-```shell
-$ npm install -g @angular/cli
+example output:
+
+```txt title=" "
+✔ Project name: …
+✔ Add TypeScript? … No / Yes
+✔ Add JSX Support? … No / Yes
+✔ Add Vue Router for Single Page Application development? … No / Yes
+✔ Add Pinia for state management? … No / Yes
+✔ Add Vitest for Unit testing? … No / Yes
+✔ Add Cypress for both Unit and End-to-End testing? … No / Yes
+✔ Add ESLint for code quality? … No / Yes
+✔ Add Prettier for code formatting? … No / Yes
+
+Scaffolding project in ./...
+Done.
```
## 5. Cloud / Devops Setup
-When it'll be time to upload our project to the cloud (it'll be sooner then you might think), we'll use couple of tools to connect to our cloud provider and setup our infrastructure. The first will be `gcloud` because we'll use [GCP](https://cloud.google.com/) as our cloud provider (we'll talk about it more in the next chapter), the second will be `kubectl` because we'll use [Kubernetes](https://kubernetes.io/) as part of our infrastructure.
+When it'll be time to upload our project to the cloud (it'll be sooner then you might think), we'll use couple of tools to connect to our cloud provider and setup our infrastructure. The first will be `gcloud` because we'll use [GCP](https://cloud.google.com) as our cloud provider (we'll talk about it more in the next chapter), the second will be `Docker` because we'll use [Docker](https://www.docker.com) as part of our infrastructure to build isolated images and we'll run them on [Cloud Run](https://cloud.google.com/run).
### 5.1 Google Cloud
@@ -165,16 +179,16 @@ To use [GCP (Google Cloud Platform)](https://cloud.google.com/) from the command
To install it, we just use `brew cask` command. This is a cli tool, so it probably should be just `brew`, but brew doesn't have a formulae for `gcloud` (don't ask me why, but I'm sure the internet has an answer for that somewhere), so lucky for us, `cask` has us cover.
-```shell
-$ brew cask install google-cloud-sdk
+```bash showLineNumbers title=" "
+brew cask install google-cloud-sdk
```
-### 5.2 Kubernetes
+### 5.2 Docker
-[Kubernetes](https://kubernetes.io/) is an open source container orchestration system for automating application deployment, scaling, and management. This is a lot of buzz words, I know. But Kubernetes is worth it. We'll use it to deploy and manage our backend on top of GCP. And to interact with it we need it's CLI (do you see a pattern here yet?). Kubernetes CLI called [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/) and we can install it like any other CLI tool, with `brew`.
+[Docker](https://www.docker.com) is a set of platform as a service products that use OS-level virtualization to deliver software in packages called containers. This is a lot of buzz words, I know. But Docker is worth it. We'll use it to build and deploy our backend on top of GCP (Cloud Run service). And to interact with it we need it's CLI (do you see a pattern here yet?), and we can install it like any other CLI tool, with `brew`.
-```shell
-$ brew install kubectl
+```bash showLineNumbers title=" "
+brew install --cask docker
```
diff --git a/src/pages/blog/2020/chapter-2-simple-twitter.md b/src/pages/blog/2020/chapter-2-simple-twitter.md
index e6d159b..5a5c32b 100644
--- a/src/pages/blog/2020/chapter-2-simple-twitter.md
+++ b/src/pages/blog/2020/chapter-2-simple-twitter.md
@@ -9,9 +9,6 @@ authorLink: "/about"
tags: ["twitter", "development", "mvp", "database", "collection", "architecture", "api", "schema"]
category: "development"
-hiddenFromHomePage: false
-hiddenFromSearch: false
-
featuredImage: "/posts/2020/chapter-2-simple-twitter/simple-twitter-cover.webp"
---
diff --git a/src/pages/blog/2020/chapter-3-simple-twitter.md b/src/pages/blog/2020/chapter-3-simple-twitter.md
index ca5c9f3..1f8c7c2 100644
--- a/src/pages/blog/2020/chapter-3-simple-twitter.md
+++ b/src/pages/blog/2020/chapter-3-simple-twitter.md
@@ -26,9 +26,6 @@ tags:
]
category: "development"
-hiddenFromHomePage: false
-hiddenFromSearch: false
-
featuredImage: "/posts/2020/chapter-3-simple-twitter/simple-twitter-cover.webp"
---
diff --git a/src/pages/blog/2020/crack-the-hash.md b/src/pages/blog/2020/crack-the-hash.md
index 535b80f..51fa3de 100644
--- a/src/pages/blog/2020/crack-the-hash.md
+++ b/src/pages/blog/2020/crack-the-hash.md
@@ -9,9 +9,6 @@ authorLink: "/about"
tags: ["crack", "password", "hash", "hashcat", "gcp", "google cloud platform", "white hat", "pen test", "hacking"]
category: "hacking"
-hiddenFromHomePage: false
-hiddenFromSearch: false
-
featuredImage: "/posts/2020/crack-the-hash/crack-passwords.webp"
---
@@ -63,26 +60,26 @@ First we need to SSH into the machine, the easiest way to do it is to click on t
After that the terminal is open, go to the [CUDA Toolkit download page](https://developer.nvidia.com/cuda-downloads?target_os=Linux&target_arch=x86_64&target_distro=Ubuntu&target_version=2004&target_type=debnetwork) and chose the platform you want to install it to, it'll give you all the commands - just paste them in the terminal. In my case here they are:
-```bash
-$ wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin
-$ sudo mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600
-$ sudo apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/7fa2af80.pub
-$ sudo add-apt-repository "deb https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/ /"
-$ sudo apt-get update
-$ sudo apt-get -y install cuda
+```bash showLineNumbers title=" "
+wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin
+sudo mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600
+sudo apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/7fa2af80.pub
+sudo add-apt-repository "deb https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/ /"
+sudo apt-get update
+sudo apt-get -y install cuda
```
After everything is installed successfully it's time to install [Hashcat](https://hashcat.net).
-```bash
-$ wget https://hashcat.net/files/hashcat-6.1.1.7z
-$ sudo apt install p7zip
-$ p7zip -d hashcat-6.1.1.7z
-$ sudo cp hashcat-6.1.1/hashcat64.bin /usr/bin/
-$ sudo ln -s /usr/bin/hashcat64.bin /usr/bin/hashcat
-$ sudo cp -Rv hashcat-6.1.1/OpenCL/ /usr/bin/
-$ sudo cp hashcat-6.1.1/hashcat.hcstat2 /usr/bin/
-$ sudo cp hashcat-6.1.1/hashcat.hctune /usr/bin/
+```bash showLineNumbers title=" "
+wget https://hashcat.net/files/hashcat-6.1.1.7z
+sudo apt install p7zip
+p7zip -d hashcat-6.1.1.7z
+sudo cp hashcat-6.1.1/hashcat64.bin /usr/bin/
+sudo ln -s /usr/bin/hashcat64.bin /usr/bin/hashcat
+sudo cp -Rv hashcat-6.1.1/OpenCL/ /usr/bin/
+sudo cp hashcat-6.1.1/hashcat.hcstat2 /usr/bin/
+sudo cp hashcat-6.1.1/hashcat.hctune /usr/bin/
```
And now let's test that Hashcat is installed properly and recognize our GPU by running `sudo hashcat --benchmark`.
@@ -97,15 +94,15 @@ The first thing we need is a password list. You can make your own password (word
The best place to get some of it is the [SecList on GitHub](https://github.com/danielmiessler/SecLists/tree/master/Passwords), and one of the most popular list is the [rockyou](https://en.wikipedia.org/wiki/RockYou) one. So let's download it to our VM and use that list to crack some passwords.
-```bash
-$ wget https://github.com/brannondorsey/naive-hashcat/releases/download/data/rockyou.txt
+```bash showLineNumbers title=" "
+wget https://github.com/brannondorsey/naive-hashcat/releases/download/data/rockyou.txt
```
To crack a password you first need to know the hash type of that password - which hashing algorithm they use to encrypt the password (there are multiple ways to discover it, and also a lot of projects that are trying to do that automatically, but this is not the purpose of this post, so Google it).
For testing I encrypt some text with [Bcrypt hash function](https://en.wikipedia.org/wiki/Bcrypt), here are the result:
-```
+```txt title=" "
$2b$04$jysbNjr164hK4E7tqk2B.OJoj4qAg9xHF4gLqain2m9pGb1bcsRf6
$2b$04$T.E6VXlAlt/K/gfVBBrs8eULxwBTDGVZ1CNsE.yJX5Yt9LjqH5bDO
$2b$04$XMOmhaV4EM.8fDCVEk3GYOmSbHvVoSx1cDyxhSeebBmCZyGisq7sG
@@ -116,8 +113,8 @@ Now, go to the [documentation of Hashcat](https://hashcat.net/wiki/doku.php?id=e
A basic running is just to use the `m` flag with the mode 3200, the `o` flag to point Hashcat where to put all of the cracked passwords, and then just the file with the hashs (I put them in `test.txt` on the VM) and the file with the cleartext passwords list (the `rockyou.txt` we downloaded earlier).
-```bash
-$ sudo hashcat -m 3200 -o cracked.txt test.txt rockyou.txt
+```bash showLineNumbers title=" "
+sudo hashcat -m 3200 -o cracked.txt test.txt rockyou.txt
```
@@ -132,16 +129,16 @@ Using a ruleset we can change our wordlist to contain more variations of the exi
So let's use those rules, first download the repo, next we need to `unzip` the zip file, and finally change the directory name.
-```bash
-$ wget https://github.com/praetorian-inc/Hob0Rules/archive/master.zip
-$ unzip master.zip
-$ mv Hob0Rules-master/ Hob0Rules
+```bash showLineNumbers title=" "
+wget https://github.com/praetorian-inc/Hob0Rules/archive/master.zip
+unzip master.zip
+mv Hob0Rules-master/ Hob0Rules
```
To run Hashcat again, but now with the rules we downloaded all we need to do is to use the `r` flag and point it to the path of the rule file.
-```bash
-$ sudo hashcat -m 3200 -o cracked.txt -r Hob0Rules/hob064.rule test.txt rockyou.txt
+```bash showLineNumbers title=" "
+sudo hashcat -m 3200 -o cracked.txt -r Hob0Rules/hob064.rule test.txt rockyou.txt
```
Now if you write `s` in the terminal to check the status progress of the cracking process you can see that instead of 57,377,536 passwords combinations that the `rockyou.txt` file contains, Hashcat checks 3,672,162,304 passwords combinations, because it uses uppercase and lowercase combinations of the same text that the `rockyou.txt` file contains.
diff --git a/src/pages/blog/2020/jekyll-starter-kit-generator-3.x.x.md b/src/pages/blog/2020/jekyll-starter-kit-generator-3.x.x.md
index e6174db..bc8b7a4 100644
--- a/src/pages/blog/2020/jekyll-starter-kit-generator-3.x.x.md
+++ b/src/pages/blog/2020/jekyll-starter-kit-generator-3.x.x.md
@@ -9,9 +9,6 @@ authorLink: "/about"
tags: ["jekyll", "contribution", "github", "generator", "starter kit", "yeoman", "pwa", "npm"]
category: "contribution"
-hiddenFromHomePage: false
-hiddenFromSearch: false
-
featuredImage: "/posts/2020/jekyll-starter-kit-generator-3.x.x/github-social-coding.webp"
---
diff --git a/src/pages/blog/2020/like-a-spy-with-hak5-toys.md b/src/pages/blog/2020/like-a-spy-with-hak5-toys.md
index 3c55fce..6797d52 100644
--- a/src/pages/blog/2020/like-a-spy-with-hak5-toys.md
+++ b/src/pages/blog/2020/like-a-spy-with-hak5-toys.md
@@ -9,9 +9,6 @@ authorLink: "/about"
tags: ["spy", "screen crab", "key croc", "cloud c2", "hacking", "hak5", "white hat", "digital ocean"]
category: "hacking"
-hiddenFromHomePage: false
-hiddenFromSearch: false
-
featuredImage: "/posts/2020/like-a-spy-with-hak5-toys/spy-cover.webp"
---
@@ -55,24 +52,22 @@ Don't forget to add our droplet in _"Apply to Droplets"_ input, right before the
Now the fun part begins, let's ssh to our server (replace `` with your droplet ip, in my case it's `165.227.156.17`).
-```bash
-$ ssh root@
+```bash showLineNumbers title=" "
+ssh root@
```
And install the `unzip` package so we can unzip the `zip` file we'll download with all the edition for Windows, Mac and Linux of C2 from Hak5.
-```bash
-$ sudo apt install unzip
+```bash showLineNumbers title=" "
+sudo apt install unzip
```
Now let's build a command to download the c2 (you can get the download URL from the email), save the file in the name `c2.zip`, unzip it, and run the relevant binary for our OS with the `hostname` point to our domain, and the `https` flag so [Let's Encrypt](https://letsencrypt.org) will automatically create a certificate for us.
-```bash
-$ wget https://c2.hak5.org/download/community -O c2.zip && \
-unzip c2.zip && \
-./c2_community-linux-64 -hostname cloud-c2.dev -https
+```bash showLineNumbers title=" "
+wget https://c2.hak5.org/download/community -O c2.zip && unzip c2.zip && ./c2_community-linux-64 -hostname cloud-c2.dev -https
```
The first time C2 runs, a database file is generated (named `c2.db` by default) in the same directory as the C2 binary. In that first run you'll see it print a _"Setup token"_, copy it, we'll need it to continue the setup process.
@@ -108,14 +103,14 @@ Also, create a file named `config.txt` and in it add the wifi configuration. The
For example:
-```
+```txt title="config.txt"
WIFI_SSID This network
WIFI_PASS The P@$$word!!
```
Will be:
-```
+```txt title="config.txt"
WIFI_SSID This\ network
WIFI_PASS The\ P\@\$\$word\!\!
```
@@ -154,7 +149,7 @@ Let's connect our Key Croc to our C2. Go to the C2 dashboard and add a new devic
And let's add our wifi configuration so it would be able to connect to our C2 server. Like with the Screen Crab we need to edit the `config.txt` file (we already have the file in this case, and there're quit a few comments in there), we'll uncomment the `WIFI_SSID` and `WIFI_PASS` lines and add our wifi configuration there, in the same exact way we did with the Screen Crab, but in this case we have a new option to play with, an ssh one, so we can connect to the Key Croc via ssh and program it on the fly!
-```
+```txt title="config.txt"
WIFI_SSID This\ network
WIFI_PASS The\ P\@\$\$word\!\!
SSH ENABLE
@@ -180,27 +175,27 @@ Everything is connected and working, but soon as we'll leave our Digital Ocean s
First we're going to move the c2 file to `/usr/local/bin`. Why this directory? Because this is the directory in linux for programs that normal user may run. _"usr"_ - **U**NIX **S**ystem **R**esources, the location that system programs and libraries are stored. _"local"_ - for resources that were not shipped with the standard distribution. _"bin"_ - binary compiled executables.
-```bash
-$ sudo mv c2_community-linux-64 /usr/local/bin
+```bash showLineNumbers title=" "
+sudo mv c2_community-linux-64 /usr/local/bin
```
and then to create a new directly (in `/var`) for our database (the `c2.db` file that was automatically created). Why in `/var`? Because according to linux it's abbreviation is _"variable"_, and it should contains things that are prone to changes (such as websites, temporary files (`/var/tmp`) and databases).
-```bash
-$ sudo mkdir /var/c2
-$ sudo mv c2.db /var/c2
+```bash showLineNumbers title=" "
+sudo mkdir /var/c2
+sudo mv c2.db /var/c2
```
Now we need to create a new `systemd` service. This is the "right way" to keep the process alive once we leave the ssh connection, because this way (with `systemd`) if it crash the `systemd` will automatically reboot it and also we can capture the process logs to check what happened.
-```bash
-$ sudo touch /etc/systemd/system/c2.service
-$ nano /etc/systemd/system/c2.service
+```bash showLineNumbers title=" "
+sudo touch /etc/systemd/system/c2.service
+nano /etc/systemd/system/c2.service
```
And paste the text below (change the `cloud-c2.dev` to your domain name), save and exit nano.
-```
+```txt
[Unit]
Description=Cloud C2
After=c2.service
@@ -213,14 +208,14 @@ WantedBy=multi-user.target
All we have left to do is to reload the `systemd` daemon, enable the new service we just created (if it's not enabled the service will start and stop only when you write the commands to start and stop it, if it's enabled it'll automatically start when the server is back up), and finally start it.
-```bash
-$ sudo systemctl daemon-reload && systemctl enable c2.service && systemctl start c2.service
+```bash showLineNumbers title=" "
+sudo systemctl daemon-reload && systemctl enable c2.service && systemctl start c2.service
```
You can check the status of the service we created with the `status` command of `systemctl`.
-```bash
-$ sudo systemctl status c2.service
+```bash showLineNumbers title=" "
+sudo systemctl status c2.service
```
diff --git a/src/pages/blog/2020/new-design-for-the-blog.md b/src/pages/blog/2020/new-design-for-the-blog.md
index 16af559..23fc2b5 100644
--- a/src/pages/blog/2020/new-design-for-the-blog.md
+++ b/src/pages/blog/2020/new-design-for-the-blog.md
@@ -9,9 +9,6 @@ authorLink: "/about"
tags: ["hugo", "design", "blog", "github", "commento.io", "plausible analytics"]
category: "miscellaneous"
-hiddenFromHomePage: false
-hiddenFromSearch: false
-
featuredImage: "/blog-hero.webp"
---
diff --git a/src/pages/blog/2020/open-source-intelligence.md b/src/pages/blog/2020/open-source-intelligence.md
index e4c7b8f..0a43ac7 100644
--- a/src/pages/blog/2020/open-source-intelligence.md
+++ b/src/pages/blog/2020/open-source-intelligence.md
@@ -9,9 +9,6 @@ authorLink: "/about"
tags: ["osint", "reconnaissance", "hacking", "white hat", "intelligence", "open source", "data leaks", "arjun", "hunter.io", "theHarvester", "sublist3r"]
category: "hacking"
-hiddenFromHomePage: false
-hiddenFromSearch: false
-
featuredImage: "/posts/2020/open-source-intelligence/osint-cover.webp"
---
@@ -60,7 +57,7 @@ We notice a bunch of things:
The easiest thing to look up first are the IPs and the domain. The first IP (`84.17.46.157`) is from Netherlands, and the second (`154.127.57.238`) is from the South Africa, here are the full `JSON`s files I got from [ipstack](https://ipstack.com). I got the paid version of their API, but there is a free one and that's enough for our case here.
-```json
+```json showLineNumbers title=" "
{
"ip": "84.17.46.157",
"type": "ipv4",
@@ -111,7 +108,9 @@ The easiest thing to look up first are the IPs and the domain. The first IP (`84
}
```
-```json
+and
+
+```json showLineNumbers title=" "
{
"ip": "154.127.57.238",
"type": "ipv4",
@@ -566,7 +565,7 @@ It looks like our guy, but this is not enough! we need more.
Let's search his gmail (`slikeye1711@gmail.com`) on [Pipl](https://pipl.com), unfortunately we got nothing.
-```json
+```json showLineNumbers title=" "
{
"@http_status_code": 200,
"@visible_sources": 0,
@@ -603,7 +602,7 @@ So let's think of something different, in his profile page there was a new domai
The third result is really interesting, it's from [cutestat website](https://www.cutestat.com), which is a website to provides various statistical reports like website valuation, traffic reports, social engagement, host information, domain WHOIS, etc. and it's perfect because it has a WHOIS record from `2017-06-14T17:05:39Z` with new data (probably before he had privacy protection on the domain).
-```
+```txt title=" "
Domain Name: SLIKEYE.COM
Registry Domain ID: 2132972393_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.resellercamp.com
@@ -677,7 +676,7 @@ Unfortunately we didn't get new phone numbers or email addresses, but _"Forget P
The new email address and phone number don't get us any result on Pipl, that's a bummer. Pipl is consistently failing us in this recon investigation. On the other hand a TrueCaller search for the phone number confirms the new email address we already found in the 2017 WHOIS record, and tell us his `carrier` and that he is verified by [TrueCaller](https://www.truecaller.com).
-```json
+```json showLineNumbers title=" "
{
"data": [
{
diff --git a/src/pages/blog/2020/releasing-software-is-hard.md b/src/pages/blog/2020/releasing-software-is-hard.md
index 190ae98..fe6df05 100644
--- a/src/pages/blog/2020/releasing-software-is-hard.md
+++ b/src/pages/blog/2020/releasing-software-is-hard.md
@@ -9,9 +9,6 @@ authorLink: "/about"
tags: ["semver", "conventional commits", "github actions", "commitizen", "releases", "automation"]
category: "tutorials"
-hiddenFromHomePage: false
-hiddenFromSearch: false
-
featuredImage: "/posts/2020/releasing-software-is-hard/software-development.webp"
---
@@ -69,12 +66,12 @@ So, let's recap all the tools so far. If we'll use [commitizen](https://github.c
Let's start by creating a simple `package.json` file with npm in our project directory (let's call it `deweb` because that's what the [namelix](https://namelix.com) generator generate for us).
-```bash
-$ mkdir deweb
-$ cd deweb
-$ git init
-$ npm init
-$ echo node_modules >> .gitignore
+```bash showLineNumbers title=" "
+mkdir deweb
+cd deweb
+git init
+npm init
+echo node_modules >> .gitignore
```
Here are my configurations.
@@ -83,15 +80,15 @@ Here are my configurations.
Now we need to install [commitizen](https://github.com/commitizen/cz-cli) and make our repo **commitizen friendly**
-```bash
-$ npm install commitizen -g
-$ commitizen init cz-conventional-changelog --save-dev --save-exact
+```bash showLineNumbers title=" "
+npm install commitizen -g
+commitizen init cz-conventional-changelog --save-dev --save-exact
```
This just tells commitizen which adapter we actually want our contributors to use when they try to commit to this repo. And now you can use `git cz` command instead of `git commit` and the commitizen prompt will guide your through the commit message and `commit` all the files.
-```bash
-$ git cz
+```bash showLineNumbers title=" "
+git cz
```
@@ -104,14 +101,14 @@ Now, we can use [semantic-release](https://github.com/semantic-release/semantic-
So, let's create a GitHub action that uses the [Release me!](https://github.com/marketplace/actions/release-me#create-a-release) action and run every time there is a milestones event on GitHub.
-```bash
-$ mkdir -p .github/workflows
-$ touch .github/workflows/cd.yml
+```bash showLineNumbers title=" "
+mkdir -p .github/workflows
+touch .github/workflows/cd.yml
```
In this file you should copy the default template of a [GitHub action](https://docs.github.com/en/free-pro-team@latest/actions), and use the [release-me-action](https://github.com/marketplace/actions/release-me#create-a-release). Then you need to change the `on` key on the top of the file `milestone` and just when a milestone closed.
-```yaml
+```yaml showLineNumbers title=".github/workflows/cd.yml"
name: Continuous Deployment
on:
@@ -134,10 +131,10 @@ jobs:
Now let's commit the new file and push it to GitHub.
-```bash
-$ git add .
-$ git cz
-$ git push origin main
+```bash showLineNumbers title=" "
+git add .
+git cz
+git push origin main
```
The last thing we need to do is to create a milestone in GitHub, then look at the **Actions** section and see our workflow, but we notice it doesn't run yet.
diff --git a/src/pages/blog/2021/getting-to-know-my-neighbors.md b/src/pages/blog/2021/getting-to-know-my-neighbors.md
index e06ad95..3c5a4e7 100644
--- a/src/pages/blog/2021/getting-to-know-my-neighbors.md
+++ b/src/pages/blog/2021/getting-to-know-my-neighbors.md
@@ -9,9 +9,6 @@ authorLink: "/about"
tags: ["wifi pineapple", "man in the middle", "wifi attack", "hacking", "white hat", "hak5"]
category: "hacking"
-hiddenFromHomePage: false
-hiddenFromSearch: false
-
featuredImage: "/posts/2021/getting-to-know-my-neighbors/blue-wireless-connection.webp"
---
diff --git a/src/pages/blog/2021/hugo-theme-with-developer-focus-in-mind.md b/src/pages/blog/2021/hugo-theme-with-developer-focus-in-mind.md
index 56ce767..c8c79aa 100644
--- a/src/pages/blog/2021/hugo-theme-with-developer-focus-in-mind.md
+++ b/src/pages/blog/2021/hugo-theme-with-developer-focus-in-mind.md
@@ -9,9 +9,6 @@ authorLink: "/about"
tags: ["hugo", "theme", "contribution", "dark mode", "generate", "optimization", "performance", "accessibility", "best practices", "seo"]
category: "contribution"
-hiddenFromHomePage: false
-hiddenFromSearch: false
-
featuredImage: "/posts/2021/hugo-theme-with-developer-focus-in-mind/hugo-logo-wide.webp"
---
@@ -51,15 +48,15 @@ There are a lot of other great features that this theme have, like:
If you want to use this theme, it can't get any easier then this. All you need to do is to install [Hugo](https://gohugo.io), create a new website, and clone this theme as a submodule
-```bash
-$ brew install hugo
-$ hugo new site myownresume
-$ git submodule add git@github.com:nirgn975/devRes.git themes/devRes
+```bash showLineNumbers title=" "
+brew install hugo
+hugo new site myownresume
+git submodule add git@github.com:nirgn975/devRes.git themes/devRes
```
-Now all you have left to do is just add it as a theme in your `config.toml`
+Now all you have left to do is just config it as your theme
-```toml
+```toml showLineNumbers title="config.toml"
theme = "devRes"
```
@@ -79,8 +76,8 @@ Great! All issues and pull requests are welcome.
For local development just start [hugo](https://gohugo.io) with `exampleSite` as the source.
-```bash
-$ hugo server --source=exampleSite -v --gc
+```bash showLineNumbers title=" "
+hugo server --source=exampleSite -v --gc
```
diff --git a/src/pages/blog/2021/nestjs-graphql-mongodb.md b/src/pages/blog/2021/nestjs-graphql-mongodb.md
index 3978778..54c0701 100644
--- a/src/pages/blog/2021/nestjs-graphql-mongodb.md
+++ b/src/pages/blog/2021/nestjs-graphql-mongodb.md
@@ -9,9 +9,6 @@ authorLink: "/about"
tags: ["nestjs", "graphql", "mongodb", "expressjs", "node.js", "javascript", "typescript", "mongodb", "mongoose"]
category: "development"
-hiddenFromHomePage: false
-hiddenFromSearch: false
-
featuredImage: "/posts/2021/nestjs-graphql-mongodb/nestjs-graphql-mongodb.webp"
---
@@ -45,15 +42,15 @@ The NestJS GraphQL module we'll use ([`@nestjs/graphql`](https://github.com/nest
So, the first thing we need to do is to install the Nest CLI tool globally and then create a project on our local machine. I'll call my project `server`, because I have such an active imagination.
-```bash
-$ npm i -g @nestjs/cli
-$ nest new server
-$ cd server
+```bash showLineNumbers title=" "
+npm i -g @nestjs/cli
+nest new server
+cd server
```
Once we created the project, our project directory tree will look like this
-```
+```txt title=" "
.
├── README.md
├── nest-cli.json
@@ -83,13 +80,13 @@ Let's go over the files on the `src` directory:
So, we don't need the controllers and the service files for the root module, let's just delete them.
-```bash
-$ rm src/app.controller.spec.ts src/app.controller.ts src/app.service.ts
+```bash showLineNumbers title=" "
+rm src/app.controller.spec.ts src/app.controller.ts src/app.service.ts
```
And then delete the `import` statements with their corresponding codes from the `controllers` and `providers` array, at the `app.module.ts` file. So at the end it'll look like this
-```typescript
+```typescript showLineNumbers title="app.module.ts" {5-6}
import { Module } from "@nestjs/common";
@Module({
@@ -102,9 +99,9 @@ export class AppModule {}
We'll create an API for a simple twitter clone, one with just users and tweets. So, let's create those two new modules with the Nest CLI.
-```bash
-$ nest g module users
-$ nest g module tweets
+```bash showLineNumbers title=""
+nest g module users
+nest g module tweets
```
@@ -117,14 +114,13 @@ My dream is to create a single model (as a typescript classes) and let Nest gene
The first thing we need to do is to install some required packages.
-```bash
-$ npm install @nestjs/graphql @nestjs/apollo graphql apollo-server-express
+```bash showLineNumbers title=""
+npm install @nestjs/graphql @nestjs/apollo graphql apollo-server-express
```
Once the packages are installed, we can import the `GraphQLModule` and configure it with the `forRoot()` static method, and then we'll use `autoSchemaFile` to tell Nest where to auto create the the GraphQL schema file.
-```typescript
-// app.module.transform
+```typescript showLineNumbers title="app.module.ts" {1,3-4,6-7,10-17}
import { join } from "path";
import { Module } from "@nestjs/common";
import { GraphQLModule } from "@nestjs/graphql";
@@ -150,15 +146,14 @@ export class AppModule {}
Now, we'll create a two classes, the first for our `User` model, in the `users` module (directory). And the second for the `Tweet` model, in the `tweets` module.
-```bash
-$ nest g class users/models/user.model
-$ nest g class tweets/models/tweet.model
+```bash showLineNumbers title=" "
+nest g class users/models/user.model
+nest g class tweets/models/tweet.model
```
The `user.model` would be with those fields:
-```typescript
-// user.model.ts
+```typescript showLineNumbers title="user.model.ts"
export class User {
_id: string;
username: string;
@@ -170,8 +165,7 @@ export class User {
And the `tweet.model` will look like:
-```typescript
-// tweet.model.ts
+```typescript showLineNumbers title="tweet.model.ts"
export class Tweet {
_id: string;
text: String;
@@ -182,16 +176,16 @@ export class Tweet {
The next step is to generate a service that handle all of the data stuff, because for now we'll not save it in the database, we'll just have an array to save data to and retrieve it from.
-```bash
-$ nest generate service users
-$ nest generate service tweets
+```bash showLineNumbers title=" "
+nest generate service users
+nest generate service tweets
```
Now we can create the resolvers which are basically the controllers in GraphQL world.
-```bash
-$ nest generate resolver users
-$ nest generate resolver tweets
+```bash showLineNumbers title=" "
+nest generate resolver users
+nest generate resolver tweets
```
diff --git a/src/pages/blog/2022/design-system.md b/src/pages/blog/2022/design-system.md
index f906a96..a2fa4c3 100644
--- a/src/pages/blog/2022/design-system.md
+++ b/src/pages/blog/2022/design-system.md
@@ -9,9 +9,6 @@ authorLink: "/about"
tags: ["design system", "component library", "vuejs", "storybook", "typescript", "tailwind", "sfc", "composition", "vite"]
category: "development"
-hiddenFromHomePage: false
-hiddenFromSearch: false
-
featuredImage: "/posts/2022/design-system/hero.webp"
---
diff --git a/src/pages/blog/2022/github-email.md b/src/pages/blog/2022/github-email.md
index 9983947..7d4fe7c 100644
--- a/src/pages/blog/2022/github-email.md
+++ b/src/pages/blog/2022/github-email.md
@@ -9,9 +9,6 @@ authorLink: "/about"
tags: ["github", "private email", "domain"]
category: "tutorials"
-hiddenFromHomePage: false
-hiddenFromSearch: false
-
featuredImage: "/posts/2022/github-email/google-email.webp"
---
diff --git a/src/pages/blog/2022/raspberry-pi.md b/src/pages/blog/2022/raspberry-pi.md
index 8736f0d..0346e11 100644
--- a/src/pages/blog/2022/raspberry-pi.md
+++ b/src/pages/blog/2022/raspberry-pi.md
@@ -9,9 +9,6 @@ authorLink: "/about"
tags: ["raspberry pi"]
category: "tutorials"
-hiddenFromHomePage: false
-hiddenFromSearch: false
-
featuredImage: "/posts/2022/raspberry-pi/raspberry-pi-hero.webp"
---
diff --git a/src/pages/contact.astro b/src/pages/contact.astro
index 13346c2..4136d94 100644
--- a/src/pages/contact.astro
+++ b/src/pages/contact.astro
@@ -3,10 +3,20 @@ import Layout from "../layouts/Layout.astro";
---
-
+
+
+ Hi! My name is Nir Galon, I'm a geek who always want to learn new things. I work as a software engineer and I love what I do!
+
+
+ To learn more about me you can visit my about page or just follow me on
+ twitter or
+ github. If you wish to contact me, the best way is to
+ just drop a message below.
+
- 
- 
- 
+ 
-
-
- 
-