migrated all content to markdown

5 files changed, 323 insertions, 16 deletions

diff --git a/content/weblog/2018-11-05_intro-to-linux-and-bash/index.ru.md b/content/weblog/2018-11-05_intro-to-linux-and-bash/index.ru.md
index e9ba17d..08fc0f8 100644
--- a/content/weblog/2018-11-05_intro-to-linux-and-bash/index.ru.md
+++ b/content/weblog/2018-11-05_intro-to-linux-and-bash/index.ru.md
@@ -1,5 +1,5 @@
 +++
-title = "Intro to Linux and the Bash command line"
+title = "Введение в Linux и Bash"
 date = 2018-11-05T23:53:00Z
 +++
 
diff --git a/content/weblog/2018-12-31_intro-to-linux-and-bash-pt2/index.ru.md b/content/weblog/2018-12-31_intro-to-linux-and-bash-pt2/index.ru.md
index 992e3cc..de4db1d 100644
--- a/content/weblog/2018-12-31_intro-to-linux-and-bash-pt2/index.ru.md
+++ b/content/weblog/2018-12-31_intro-to-linux-and-bash-pt2/index.ru.md
@@ -1,5 +1,5 @@
 +++
-title = "Введение в Linux и Bash, часть III"
+title = "Введение в Linux и Bash, часть II"
 date = 2018-12-31T09:20:00Z
 +++
 
diff --git a/content/weblog/2019-01-11_intro-to-linux-and-bash-pt3/index.ru.md b/content/weblog/2019-01-11_intro-to-linux-and-bash-pt3/index.ru.md
index 3621a14..983805f 100644
--- a/content/weblog/2019-01-11_intro-to-linux-and-bash-pt3/index.ru.md
+++ b/content/weblog/2019-01-11_intro-to-linux-and-bash-pt3/index.ru.md
@@ -3,9 +3,9 @@ title = "Введение в Linux и Bash, часть III"
 date = 2019-01-11T08:23:00Z
 +++
 
-Новый год, новый пост. В данной, третьей и последней, чатси этого туториала,
+Новый год, новый пост. В данной, третьей и последней, части этого туториала,
 будут несколько команд и программ которые являются стандартной частью
-большинтсва дистрибутивов Линукса. Больше всего внимания я буду выделять
+большинства дистрибутивов Линукса. Больше всего внимания я буду выделять
 программ, которые манипулируют вывод текст других программ и файлов. Также в
 этом посте мы поговорим о регулярных выражений (коротко - regex, от английского
 Regular Expression), очень мощный инструмент для поиска текста
@@ -106,7 +106,7 @@ JPEG    ok
 ### tail
 
 Работает также как head, но в отличие от нее, данная команда показывает
-последние строки текста. Допустим мы жотим увидеть последние три строки
+последние строки текста. Допустим мы хотим увидеть последние три строки
 
 ```sh
 user@host:~/Documents/notes$ tail -n 3 sample.txt
@@ -139,12 +139,12 @@ Uganda Knuckles cool
 ### sed
 
 sed довольная мощная утилита которая позволяет манипулировать и модифицировать
-текст. Однако, в данном туториале я не буду углубляться в подробнастях работы с
+текст. Однако, в данном туториале я не буду углубляться в подробностях работы с
 программой, но покажу пару пару самых используемых команд.
 
 Для работы с данной программой, необходимо передать своего рода скрирта (sed
 script), который укажет программе что делать с текстом. Первый и самый простой
-способ использовать sed, это ипользовать его в качестве программы head, то
+способ использовать sed, это использовать его в качестве программы head, то
 есть, получить первые b строк текста. Например, допустим что нам необходимо
 получить первые 7 строк из файла sample.txt
 
@@ -167,7 +167,7 @@ Bowsette    cool
 операции выгладит следующим образцом - 's/<поиск>/<замена>/'.
 
 По умолчанию данная команда заменяет только первое совпадение в каждой строке,
-тем не менее мы может указать какие и сколько совпаднении мы хотим заменить.
+тем не менее мы может указать какие и сколько совпадении мы хотим заменить.
 Например, если мы добавим двойку в конце команды ('s/<search>/<replace>/2')
 она заменит только вторые совпадения в каждой строке.
 
@@ -200,8 +200,8 @@ NPC dank
 выражений, покажу ее более интересные применения.
 
 grep - программа, которая выполняет поиск выражения переданный ей
-пользователем, и выводит на экран строки, совпадавщие с условиями поиска.
-Допустим, например, что мы хотим увидить только крутые (cool) мемы
+пользователем, и выводит на экран строки, совпадавшие с условиями поиска.
+Допустим, например, что мы хотим увидеть только крутые (cool) мемы
 
 ```sh
 user@host:~/Documents/notes$ grep 'cool' sample.txt
@@ -372,11 +372,11 @@ cf      ~/.config
 из них остались пробелы.
 
 И так, давайте мы сначала улучшим нашу команду, для этого нам нужно найти там
-где есть 0 или больще пробелов перед комментарии, но как нам обозначит пробелы
+где есть 0 или больше пробелов перед комментарии, но как нам обозначит пробелы
 в sed'е? Все очень просто с '\s', таким образом наша команда а теперь выглядет
 вот так 's/\s*#.*//g'.
 
-А теперь нам нужно избавится от пустых строк. ДЛя этого нам нужно ввести еще
+А теперь нам нужно избавится от пустых строк. Для этого нам нужно ввести еще
 одну команду sed'а, но мы можем ее ввести вместе с предыдущей командой
 отделяя их точкой и запетой (;). Нам осталось придумать как найти пустую
 строку, все очень просто - '^$', то есть, найти ту строку где ее начало и ее
@@ -403,17 +403,17 @@ cf      ~/.config
 Последнее о чем я буду писать в этом туториале не команда и не программа, но
 очень полезная вещь, которая есть во всех Unix и Unix-подобных системах -
 конвейер. Конвейер - это цепочка перенаправляющая вывод процесса или процессов
-в стандартный ввод других проццессов. В том числе есть и операторы которые
+в стандартный ввод других процессов. В том числе есть и операторы которые
 позволяют перенаправлять вывод программы в файл и наоборот.
 
 ### Перенаправление в и из файлов
 
 Допустим что мы хотим повторить последний пример, но в этот раз мы хотим
 записать результат в файл. Мы уже знаем как переписать оригинальный файл, но в
-этот раз мы хотим записать результат в новый файл. Для этого нам понадобяться
+этот раз мы хотим записать результат в новый файл. Для этого нам понадобятся
 операторы перенаправления Unix'а '>' и '>>'. Первый оператор переписывает файл,
 если указанный файл уже существует, а второй просто добавляет поток текста в
-конец файла. В этом случае безралично какой из этих операторов использовать,
+конец файла. В этом случае безразлично какой из этих операторов использовать,
 ибо мы хотим записать поток текста на новый файл
 
 ```sh
@@ -516,7 +516,7 @@ user@host:~/Documents/notes$ tar -czvf allnotes.tar.gz *
 user@host:~$ ssh tux@180.80.8.20
 ```
 
-Здесь мы предпологаем что мы подключаемся через стандартный порт ssh (22), иначе
+Здесь мы предполагаем что мы подключаемся через стандартный порт ssh (22), иначе
 придется его передать используя параметр -p а затем номер порта.
 
 А теперь поговорим о scp. Это программа позволяет передать файлы из одного
diff --git a/content/weblog/2019-01-31_python-package-to-pypi/index.md b/content/weblog/2019-01-31_python-package-to-pypi/index.md
new file mode 100644
index 0000000..f0b14e0
--- /dev/null
+++ b/content/weblog/2019-01-31_python-package-to-pypi/index.md
@@ -0,0 +1,176 @@
++++
+title = "Packaging and distributing python apps and modules"
+date = 2019-01-31T08:10:00Z
++++
+
+There may come a time after some hacking and playing around with python that
+you feel like the piece of code you just created needs to be shared with the
+world, and so you might be thinking "Man, wouldn't it be sweet if anyone could
+install my app/module just by typing `pip install stuffimade'`. Well, it is
+actually easier than you might think (it certainly was in my case).
+
+<!-- more -->
+
+It basically boils down to these five things:
+
+1. Make an account on pypi.org
+1. Come up with an original name, that hasn't been taken on pypi (arguably the
+   hardest part of these instructions).
+1. Prepare a setup py file to package your app/module, choose a license, maybe
+   (preferably) write a readme.
+1. Package it.
+1. Upload it.
+
+The first step is really simple, just go the website (pypi.org) and click on
+the link that says "Register" on the top right corner. Be sure to not forget
+your password, especially after uploading your package, since you will need
+everything that you want to upload a new version of your package.
+
+The second step is all up to you, just use the search function in the website
+to make sure that your package name hasn't been taken.
+
+After having created your account on pypi.org, and decided on a name for your
+app/package, you'll proceed to create the necessary package files. Your package
+should consist of a folder with your actual module or app, inside which should
+also be a `__init__.py` file (it can be empty if you don't need to set any
+variables or anything), a `LICENSE` file with your license of choice (e.g. MIT,
+BSD, GPL, etc.), and a `README.rst` or `README.md` file containing a detailed
+description of your app/module.
+
+Your directory structure should look something like this
+
+```
+/my-app-package
+  /my-app
+    __init__.py
+    (other files and directories)
+  setup.py
+  LICENSE
+  README.md
+```
+
+Now, if your app is going to have files other than python files, and the
+aforementioned files, you might to add a `MANIFEST.in` in the root of you
+package directory specifying the files to include. This is true, for example,
+for Django apps, since they might contain template and static files (html, css,
+js, etc.) that the packaging tool we are going to use might not pick up. As an
+example I'll show you the `MANIFEST.in` file of my w3blog package
+
+```
+include LICENSE
+include README.md
+recursive-include weblog/static *
+recursive-include weblog/templates *
+recursive-include weblog/locale *
+```
+
+There I specified to, just in case, include the `LICENSE` and `README.md`
+files, and also include static files, templates, and the message files for
+localization, by recursively searching the directories of said files.
+
+Now on to the setup.py file. For this I am also going to use my project's file
+as an example
+
+```py
+#!/usr/bin/env python3
+import os
+from setuptools import find_packages, setup
+
+with open(os.path.join(os.path.dirname(__file__), 'README.md')) as readme:
+    README = readme.read()
+
+# allow setup.py to be run from any path
+os.chdir(os.path.normpath(os.path.join(os.path.abspath(__file__), os.pardir)))
+
+setup(
+    name='w3blog',
+    version='0.5.2',
+    packages=find_packages(),
+    include_package_data=True,
+    license='BSD License',
+    description='A simple blog engine for Django with multilingual capabilities.',
+    long_description=README,
+    url='https://www.yaroslavps.com/',
+    author='Yaroslav de la Peña Smirnov',
+    author_email='contact@yaroslavps.com',
+    classifiers=[
+        'Environment :: Web Environment',
+        'Framework :: Django',
+        'Framework :: Django :: 1.11',
+        'Framework :: Django :: 2.0',
+        'Framework :: Django :: 2.1',
+        'Intended Audience :: Developers',
+        'License :: OSI Approved :: BSD License',
+        'Operating System :: OS Independent',
+        'Programming Language :: Python',
+        'Programming Language :: Python :: 3',
+        'Programming Language :: Python :: 3.4',
+        'Programming Language :: Python :: 3.5',
+        'Programming Language :: Python :: 3.6',
+        'Programming Language :: Python :: 3.7',
+        'Topic :: Internet :: WWW/HTTP',
+        'Topic :: Internet :: WWW/HTTP :: Dynamic Content',
+    ],
+)
+```
+
+Of course, you should customize this file according to your app's details, for
+example, your classifiers list might look shorter, like this
+
+```py
+    classifiers=[
+        'License :: OSI Approved :: BSD License',
+        'Operating System :: OS Independent',
+        'Programming Language :: Python :: 3',
+        'Programming Language :: Python :: 3.4',
+        'Programming Language :: Python :: 3.5',
+        'Programming Language :: Python :: 3.6',
+        'Programming Language :: Python :: 3.7',
+    ],
+```
+
+It will depend on which version of python you want to support, your license,
+some other required packages, etc. The rest of the setup function parameters
+should be self explanatory.
+
+Once you have you package files ready (don't forget about your readme and
+license), you'll need to proceed to package them, i.e. generate the
+distribution files. For that, we'll need to install a couple of packages, we
+cant install them inside a virtual environment, or you could install them
+system wide
+
+```sh
+$ sudo pip3 install --upgrade setuptools wheel twine
+```
+
+Now just run the following command from the same directory where setup.py is
+located
+
+```sh
+$ python3 setup.py sdist bdist_wheel
+```
+
+After running that command, you should now have a dist subdirectory with a
+.tar.gz archive and a .whl file. Those are the files that you'll need to
+upload. The twine package that we just installed is going to take care of that
+for us. Remember that you already should have an account on pypi.org to upload
+your package.
+
+So for example, when I just uploaded the first version of w3blog, and each time
+that I upload a new version I run a command (from the same directory as
+setup.py) that looks like this
+
+```sh
+$ python3 twine upload dist/w3blog-0.5.2*
+```
+
+Just replace "w3blog-0.5.2*" with your appropriate package name-version. After
+running that command, twine is going to ask you for your username and password,
+thence it is going to upload it to pypi. Once it is successfully uploaded, it
+should be a matter of seconds or minutes before you, and everybody else in the
+world with an internet connection (and capable of running python, of course),
+can install your package!
+
+If you need more detailed information about this process, check out the
+official documentation at
+[https://packaging.python.org/tutorials/packaging-projects/](https://packaging.python.org/tutorials/packaging-projects/)
diff --git a/content/weblog/2020-03-07_rethinking-my-blog/index.md b/content/weblog/2020-03-07_rethinking-my-blog/index.md
new file mode 100644
index 0000000..61fc4ec
--- /dev/null
+++ b/content/weblog/2020-03-07_rethinking-my-blog/index.md
@@ -0,0 +1,131 @@
++++
+title = "Rethinking my weblog"
+date = 2020-03-07T02:44:00Z
++++
+
+It's been a while since I have posted anything on my weblog. I will be laying
+out some of the reasons for this, as well as what I've been meaning to do with
+my site and blog going forward.
+
+<!-- more -->
+
+## The problem
+
+There are several reasons why I have neglected my weblog for the last year or
+so. It certainly hasn't been because of lack of imagination or content, since I
+did have several different ideas I want to write about, and I still have
+several drafts I started and still haven't finished (most of which I probably
+won't finish). The biggest two reasons were that I became occupied with a lot
+of different things including university, work, personal projects, hobbies,
+procrastination, and well, life; and the second is honestly just laziness.
+
+Now if I am completely honest I have to say that laziness is actually the
+biggest factor of those two, especially considering that this laziness towards
+my blog has been aggravated by my growing dislike of web (and other software
+for that matter) in its current state. And that, ironically (or unironically)
+includes my own blog and site, which run on Django using a blog engine I
+personally developed.
+
+Which also leads me to another problem related to the neglect of my weblog: the
+neglect of my blog engine and Django app - w3blog. The causes and reasons for
+the neglect of this project of mine - which I haven't updated since January of
+last year (much like the blog itself) - are essentially the same.
+
+I am not going to go into details in this post as to how and/or why I came to
+dislike "modern" and "mainstream" software, but there are a couple details that
+are relevant to this post. The most important of these is that I changed my
+workflow quite drastically in the past couple of years, in a way that I believe
+has made me much more productive using a computer. The second relevant detail
+is bloat, and my dislike of it. What this basically means, is that I have come
+to dislike the state and the way my site and blog operate.
+
+The first annoying thing for me, is that I have to access the Django admin page
+to author/publish posts and articles, which is a kind of CMS for sites built
+using the Django framework which my blog engine uses. It's not a bad system per
+se, and it is actually what other people that are more used to a Windows or
+macOS-like workflow would call "user-friendly". However, I've gotten really
+used to vim, not only for programming, but also for everything else that
+involves typing text. I use vim for writing articles, for University reports,
+for composing emails, for editing config files; you get the idea. In general my
+workflow has become much more keyboard-oriented, and web interfaces are just
+not made to be operated with just a keyboard, which well, sucks for me.
+
+The second thing which might not be as important from a pragmatical point of
+view is bloat. By using Django for my site I am adding a lot of stuff that is
+simply useless for my use-case. Actually for most projects, most of the
+"features" of Django are just bloat, which is the case for most of these
+do-it-all frameworks. I don't mean to shit on Django, since I still find quite
+fun and interesting to use simply because it's so easy to build many kinds of
+sites with it. However, the fact is that it is bloated.
+
+So if for some reason you have read all of above, you now may be wondering.
+Then why did you do it that way? Well, the reason is simple, I had different
+preferences and opinions back when I started this weblog and its engine, and I
+didn't know better. Yes, I know about Flask, and I've used it for some
+projects, but back when I started my blog engine, Django was what I knew how to
+use best. I still would have ended up wanting to change the way my blog works,
+simply because the way I use computers has changed so much in the past two
+years.
+
+## The solution
+
+I've been meaning to change the way my weblog functions for a long time, more
+than a year actually. Over the course of this time I came up with different
+ideas to better adapt the publishing of articles and posts to my usual
+workflow.
+
+One of the first ideas I came up with was making some kind of app or module for
+Django that would allow me to access the Django admin's functions over some
+kind of TUI from my local machine without having to manually ssh each time I
+wanted to make changes. I ended up giving up on this idea since I realized it
+would just end up making everything more complicated, and I would spend a lot
+time writing something which might not even be that useful in the end. In the
+end I realized it would be better to completely change the back-end from the
+ground up, since there was another goal that I wanted to achieve which was to
+streamline, de-bloat and use a more minimal back-end.
+
+The project to reform my weblog went into a kind of hiatus for some time, but a
+couple of months ago I started to think about it once more. And so I started to
+think what the ideal blog engine/back-end for my 2020 self would be.
+
+The idea that I ended up coming with was some sort of back-end that would read
+markdown files - where each md file was a post or article, glue it to a
+template and serve it. This way, I thought, I could just have a git repository
+with all of my articles, and then I would merge and push to master each time
+that I wanted publish something new, and then maybe by using some kind of CI,
+the changes to master would be pulled automagically on the server.
+
+After some digging around on the worldwide web, I realized that the ideas that
+I had were (obviously) not new at all, and there already exists software that
+works in precisely this way. This kind of software are called static site
+generators (I'll call them SSG for short). The three SSG that I found and
+caught my attention were Jekyll, zola and Hugo.
+
+Jekyll is the veteran of the three, and it's even used by GitHub for GitHub
+Pages. One other thing that I liked about it, is that it uses jinja (or
+something similar) for templates. It seems pretty good to me, but it has a
+couple nuisances for me. First of which is the fact that it is written in Ruby,
+and I don't know anything about Ruby. So if I wanted to take a look into the
+code or tinker around with it I would be lost, or I would have to learn Ruby,
+which I have no intention of doing.
+
+Hugo seemed interesting to me because it's written in Go, which is better than
+Ruby, and which I would be much more willing to learn than Ruby if I had the
+need (might actually even do it out if interest). However, Jekyll and zola both
+uses a Jinja or Jinja-like template system, of which I am already familiar.
+Another thing is that Hugo seems (at least to me) more complicated to configure
+to your liking than Jekyll or zola.
+
+zola is the one that caught my attention the most. I liked how simple it is to
+set up, and the fact that it uses a Jinja-like template system; the fact it is
+written in Rust, a language that I've recently started learning and that I've
+come enjoy using. Another thing that liked about zola, especially compared to
+Jekyll is the way it builds URLs, i.e. it doesn't the outdated and useless
+.html extension in the end, resulting in cleaner URLs. Maybe there is a way to
+change this in Jekyll, but I didn't find any information on it.
+
+I haven't decided yet which back-end to use, I might even write my own should I
+decide that none of the above fulfill my needs. One thing is certain, I will
+completely revamp my blog and site. After I finish revamping it, I will try my
+best to write more constantly.
+