diff options
Diffstat (limited to 'content/weblog')
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. + |