Где маркдаун? Почему не упомянут маркдаун?

Отдельно примечательное упоминание md из статьи выше:

Remark about Markdown format (MD): there is no such format, stop suggesting it! There are only many vaguely incompatible dialects and implementations. You can always be sure that your .md won’t work with another implementation. Only very tiny subset of features are guaranteed to work reliably. I heard about CommonMark (CM), but do not see its widespread usage at all.

Что, в целом, похоже на правду: диалектов много, хороших хватает, но переехать на другой диалект может быть болью (а хочется иногда переехать), разный софт поддерживает разные диалекты, не обязательно совместимые, что тоже может быть больно.

CommonMark стал распространён из-за github, но, например, документация pandoc (очень, кстати, хорошая и необходимая утилита) ссылается на немного другой диалект.



В качестве бонуса: совсем недавно, в 2019 г., появился https://typst.app/.

Похоже на что-то, что может быть удобнее Latex для написания статей, но его пишут два человека в Берлине: см. https://typst.app/about/.
выводы делайте сами

Про языки разметки часть последняя (пока):

Другое разбиение, скорее по назначению, опять же можно найти прям на главной pandoc.org

Там же видно, что vimwiki -- не единственный формат для вики, есть тот же mediawiki markup (угадайте какой сервис его использует так сказать) и много других.

Тоже и про AsciiDoc и про всё остальное.

Отдельно упоминается docx, но это специфичный бинарный формат, он даже не текстовый.



Р-р-р маркдаун!!

Позже про R точно напишу отдельно, просто потому что великий язык великая экосистема, продуманные ещё дедами.

Но здесь же стоит упомянуть R Markdown.

R Markdown -- это такой маркдаун, в котором можно выразить что-то типа обычного jupyter ноутбука, но специфичный для R и, кажется, только R такой и поддерживает.

В целом, достаточно богатый и выразительный (ну потому что можно вставлять код и он будет исполняться, а результат рендериться в документ), можно писать даже книги, да и много другого, см. https://rmarkdown.rstudio.com/gallery.html

Ну и, конечно, см. https://bookdown.org/yihui/rmarkdown/ -- это книга, написанная в R Markdown про R Markdown.

олды тут? было?

ssh -- не шутки

А этим постом попробую напомнить лишний раз, что не всё, что у нас сейчас (с т.з. технологий/вычислений) есть, было у нас всегда.

Так, ssh, которым вы все уже точно пользовались, не появился у нас с появлением компьютеров, но наоборот появился сильно позже появления интернета.

Если совсем коротко, ssh написал буквально один финнский (опять эти финны!!) аспирант в 1995г. технически он уже год к этому моменту как закончил, но закончил какую-то финнскую степень по стилю магистратура + PhD, т.е. это примерно третий год аспы

А вот история о том, как он же в 95-м зарезервировал 22 порт для SSH:

Anyway, I designed SSH to replace both telnet (port 23) and ftp (port 21). Port 22 was free. It was conveniently between the ports for telnet and ftp. I figured having that port number might be one of those small things that would give some aura of credibility.

<...> I sent the appropriate people a single email requesting the port. It was granted without any additional conversation because this was 1995. The end.

Тут полные письма, которые он писал: https://www.ssh.com/academy/ssh/port
Лихие 90-е, не иначе.


А тут библиография на его странице, связанная с ssh: https://ylonen.org/ssh/bibliography.html
Красиво, сказать нечего.


Так что, с первым апреля, но помните, что ssh (и финны) -- вам не шутки.

апд: исправил ссылку на статью с письмами

заодно просьба:

котаны, я сильно переживаю, что этот канал вас отвлекает днём от прослушивания лекций моих прекрасных коллег, поэтому прошу а) выключите нафиг уведомления б) го читать, активничать в свободное от учебы время, спасибо 💚

Сегодня делюсь кой-какими каналами по теме

Они не заменят нормальное образование (очевидно), можете даже не рассчитывать (очевидно), но там и сям можно подцепить хорошие идеи (не совсем очевидно) или узнать что в целом происходит в мире. Вместо вместе с тик-тока самое оно

Теория

@covalue Заметки о теории языков программирования, формальной верификации программ, теории типов, математической логике, конструктивизме и всякой всячине.
@daily_ponv Похожий на предыдущий по тематике, чужие научные статьи, но в этом меньше комментариев. Бывают годные вещи. Best crap from the dumpster

Авторские

@experimentalchill выпускник московской вышки, инженер гугла, кажется, оч хорошо понимает математику и на её понимании построил себе карьеру, регулярно об этом пишет; меня очень удивляет сколько может сделать этот парень
@nosingularity Короткие и часто весёлые набросы про базы данных и SQL, чувак из некого https://dwh.dev
@optozorax_dev чувак пишет порталы (в см. как в играх) и про порталы на уровне Бог)
@lilfunctor канал больше про scala; Pure functional and composable channel
@fuzzing_life свежий канал про fuzzing тестирование

@why_typescript_is_bad Ага, Why Typescript is bad.
@randomstuffilike dd if=/dev/stuff of=/dev/tg — разное; чаще про TypeScript и бывало про всякие сложные типы в TypeScript

Математика

@pdmi_ras: канал ПОМИ РАН с объявлениями про актуальные открытые математические семинары в Санкт-Петербурге
@cme_channel: Непрерывное математическое образование
@sweet_homotopy: сладко стянул; неглубоко и малодушно ныряю в комб/алг/топ реальность
@tropicalgeometry tropical saint petersburg; много годных упоминаний и заметок вокруг математики

upd: добавляю ещё этот
@psauxww Тим-менеджмент, Devops, Python, Rust, JS, Linux, IoT, электрика, все над чем работаю, иногда матом;

они же телеграмной "папкой" https://t.me/addlist/eQqEqZ6lzsEwODUy

если есть годное, делитесь, добавлю)

Как стать крутым инженером?

Обещал бубнить завтра, завтра настало!

С математикой и университетскими курсами поняли -- это надо и понятно как (или непонятно хех).
Любые вспомогательные про архитектуру и дизайн -- тоже надо.
Но про культуру, отношение и общий подход в учебниках по математике не пишут (хотя читая их, можно догадаться и про культуру тоже).

Иногда бывают курсы по софт-скиллам и про общую эрудицию, иногда они даже бывают полезные -- но вот они не совсем про инженерию или совсем не про неё.

И в этом смысле на вопрос Как стать крутым (или хотя бы хорошим) инженером? отвечает статья Эрика Реймонда.
Она так и называется How To Become A Hacker?

доп: Сто процентов большей части из вас уже рекомендовал его The Art Of Unix Programming. Рекомендую и сейчас.
В комментах немного фоток + интервью с ним.

1/3

Структура How To Become A Hacker?

Why This Document?

What Is a Hacker?

Тут без комментариев, просто читайте оригинал.

The Hacker Attitude

1. The world is full of fascinating problems waiting to be solved. ✔️

2. No problem should ever have to be solved twice. ✔️

3. Boredom and drudgery are evil. ✔️

4. Freedom is good. ✔️

5. Attitude is no substitute for competence.✔️

Ставлю галки, где соглашаюсь или учитываю в жизни.
Очевидно, этого не достаточно для всей жизни вообще, не нада экстраполировать, говорим про инженерию.

Basic Hacking Skills

1. Learn how to program. ✔️

2. Get one of the open-source Unixes and learn to use and run it. ✔️

3. Learn how to use the World Wide Web and write HTML. ✔️

4. If you don't have functional English, learn it. ✔️

Status in the Hacker Culture

1. Write open-source software ✔️

2. Help test and debug open-source software

3. Publish useful information ✔️

4. Help keep the infrastructure working ✔️

5. Serve the hacker culture itself ✔️

Ставлю галки на том, что стараюсь сам делать, хотя получается не всегда :)
В статье по каждому пункту написано достаточно, не буду повторять.

2/3

Структура How To Become A Hacker?

The Hacker/Nerd Connection

это комментарий про связь хороших инженеров (The Hacker) и нёрдов (Nerd); спойлер: её почти нет, это всё выдумки массмедиа

Points For Style

Сюда отдельно обратите внимание.

Там примеры хороших занятий, побочных и способствующих вашему развитию в качестве инженера:
- научитесь хорошо писать на родном языке;
- читайте художку, в частности научную фантастику (хотя тут по вкусу);
- займитесь какими-нибудь боевыми искусствами или спортом, который требует дисциплины и фокуса; стрельба тоже подходит;
- медитация;
- подходите к музыке аналитически; освоить какой-нибудь музыкальный инструмент -- хорошая идея;
- развивайте чувство юмора; качайте каламбурчики, игру слов и тп

Historical Note: Hacking, Open Source, and Free Software

Other Resources

Frequently Asked Questions

Эту часть тоже рекомендую полистать, там есть ссылки на хорошие вещи.

3/3

а ещё вот: пёся-почтальон

Что точно учить из языков разметки я рассказал (база?).

Вот тут материалы, по которым можно научиться самостоятельно.
(Надеюсь, скоро всё-таки выложу это добро на omp.wiki, пора!)

0) Необходимо сесть и начать писать на этих языках (вот неожиданность!).

1) LaTeX: хватит установить какой-нибудь дистрибутив (TexLive/MacTex или даже MikTex), большинство нужных вам вещей будет идти из коробки. Или открыть Overleaf, но будьте готовы, что эта штука отупляет.

И прочитать Short Math Guide for LaTeX, там всего 21 страница, но они покрывают 95% ваших сценариев на ближайшие много лет.

2) HTML и CSS лучше учить по референсу на Mozilla Developer Networks (вообще, кажется, именно Mozilla сделала чуть ли не больше всех для того, чтобы веб-разработка была адекватной; в т.ч. поддерживают этот референс в актуальном состоянии): HTML и CSS.

В части про CSS особенно обратите внимание на flexbox и grids -- сейчас всё верстается на них, как минимум, потому что удобно.

Весь референс учить не имеет смысла (только если вы не собрались быть frontend-разработчиком, тогда как раз хватит выучить весь референс), но пролистать разик-другой очень рекомендую, пригодится.

JavaScript сходу учить не советую, в современности уже лучше учить TypeScript, а только потом почитать какую-нибудь книгу о том, в чём именно JS так больно.
После Python, кстати, TS учится очень легко: TS -- это такая чуть более здоровая версия петона, если угодно :)

+ нужен примерно любой браузер и Developer Tools в нём; там и html любой страницы можно посмотреть и свою открыть и поредактировать, и есть консолечка для js;

3) GNU Texinfo: устанавливаете пакет texinfo любимым пакетным менеджером (скорее всего, его не будет в вашем дистрибутиве по умолчанию), а дальше в терминале info texinfo и внимательно читаете + полистать статью, которую уже упоминал выше.

(Подробно на omp.wiki о том, как пользоваться этим гну инфо: тыньк).

бубнёж про языки разметки совсем всё, дальше постепенно напишу про то, кто такой девопс, млопс и другой опс (спойлер: если вы хорошо знаете POSIX Shell и Linux, то вот вы уже почти какой-то опс)

и, пожалуй, кое-что ещё про софтскиллы

не стесняйтесь ставить лукасы, чтоб это произошло побыстрее — так я пойму, что это стоит сделать :)

Давайте сегодня начну с совсем общего размытого описания (возможно, пока не самого понятного), а дальше (скорее всего завтра) уточню описанием инструментов, которые используются девопсами (так станет понятнее) и (чуть позже, скорее всего на выходных) напишу и про других опсов.

Частей будет несколько, пока не знаю сколько точно.

Не стесняйтесь задавать вопросы в комментах (и ставить лукасы!), можно и про эти посты, можно и про общее — буду стараться отвечать, вероятно, такими же постами. Возможно, что-то очевидно мне и совсем неочевидно вам.

Кто такой DevOps и что такое DevOps?
Часть 1 из ...

Development and Operations (DevOps) -- акроним, которым описывается набор практик (и иногда даже правил), направленных в первую очередь на автоматизацию и непрерывность доставки программного обеспечения.

Раньше как было?

Разработчики написали код => передали код тестировщикам => тестировщики потестировали и передали код людям, которые могут собрать код в готовый пакет/релиз (операционные инженеры) => инженеры опубликовали, приложение доступно конечному пользователю.

Каждый из этапов обычно изолирован и идёт строго после окончания предыдущего.

А сбоку сисадмины помогают всему предприятию не умереть.

Как сейчас?

Девопсы поддерживают скрипты для автоматизации, поддерживают пайплайны CI/CD, часто инфраструктуру, наводят репозиторий и даже культуру, админят стенды.

Разработчики пишут код, складывают его в git-репозиторий => автоматически запускаются нужные тесты, проверки кода => когда нужно, (по нажатию одной кнопки, но) автоматически раскатывается релиз => тестировщики могут тестировать => конечный пользователь получает ПО.

Ни один из этапов можно не останавливать, пока тестировщики тестируют очередной релиз, разрабы могут продолжать шлёпать код в git-репозиторий, unit-тесты будут работать и т.д.

Нагрузка на сисадминов сильно меньше, часть инфраструктурных задач теперь сгружена на DevOps-инженеров.

Что изменилось?

Как можно было заметить, в основном доставка ПО из-за DevOps стала непрерывной + по возможности полностью заскриптована.

Соответственно, ещё раз, можно определить DevOps как совместную работу людей над разработкой, направленную на непрерывное создание и доставку безопасного программного обеспечения с максимальной скоростью.

Обратная связь при этом быстрая, а разработка итеративная.

Какие инструменты используют DevOps-инженеры?
Часть 2 из ... про devops

1. Какой-нибудь из shell и почти точно Linux. (shell и Linux в этом предложении можно менять местами, смысл не поменяется).

Как и всегда: лучше POSIX Shell, но чаще всего встречается именно bash.

Почему shell основной? Ну, потому что удобно, потому что все инструменты разработки работают в первую очередь в Linux, а он целиком и полностью автоматизируется средствами shell.
Потому что Linux невозвожен без shell.

2. Git. Нынче всё в нём, никакие другие системы контроля версий сейчас уже почти не используются (а если используются, то зачем??).

Это маст хэв.

3. Контейнеры.

Почему? Потому что контейнеры очень похожи на виртуальную машину и позволяют легко заводить разные окружения (ну, прям как-будто это ОС с установленными пакетами, но очень лёгкая и описанная где-то в файле; не надо ходить и руками всё ставить), что мега удобно.

Опять же, внутри контейнера в 99.99% случаев будет Linux, а чтобы навести контейнер нужно будет писать shell.

Чаще всего это Docker-контейнеры, намного реже LXC, Docker сейчас де факто стандарт (хотя и к этому у меня много вопросов!), потыкайте на досуге https://hub.docker.com/, там уже много образов на любой чих. Дописать свои из них тоже очень просто (когда-то про это расскажу или напишу на omp.wiki)

4. Какой-нибудь из инструментов Continous Integration.

Это такие инструменты, в которых можно описать последовательность шагов, которые нужно сделать, например, при создании Pull Request.
Или при выкатке приложения для пользователей. Или чего ещё угодно, что Вы и Ваша команда додумаетесь там написать.

Все, кто слушали ОМП в Вышке, такие уже видели, в домашках был Drone CI (сейчас, кстати, лежит хах): когда сдавали домашку, на каждый ваш PR проходило несколько шагов:

- flake8, чтобы проверить, что Вы пишете нормальный питон
- pyright для проверки, что правильно написали типы
- тесты

описание было прям в корне репозитория, в drone.yml.

Вот также и в реальной жизни, хотя обычно и чуть сложнее.

CI бывают разные: Jenkins, Gitlab CI, Github Actions, Drone CI, TeamCity и др.
Чаще всего для описания шагов в CI будет использоваться yaml (или какой-нибудь DSL, вплоть до Kotlin script в Teamcity), но в каждом из шагов в любом инструменте CI будет написан shell скрипт.

Инструменты Continous Delivery тут же (если не теже самые, что и для CI), работают также.

Какие инструменты используют DevOps-инженеры?
Часть 3 из ... про devops

5. Часто какие-нибудь инструменты автоматизации инфраструктуры.

Например, Ansible (хотя не только его, бывает Puppet, SaltStack и другое).

Ansible -- это штука, в которой можно описать набор хостов (прям серверов, которые где-то запущены и работают), написать на yaml последовательность шагов которые нужно выполнить на этих хостах.

Ansible скомпилирует yaml в shell (да именно такой кошмар), подключится к этим хостам по ssh и просто выполнит их, прям в shell.

Да, там есть больше деталей, но, опять же, если вы хорошо знаете shell и Linux, то хватит 3-5 дней, чтобы начать на нём активно и хорошо писать.

6. Инструменты мониторинга. Тут зверьков много, они разные, но чаще всего это
- Zabbix
- Prometheus/InfluxDB для сбора метрик с работающих сервисов и их хранения (хотя запросто бывают и другие базы для этого)
- Grafana для отображения этих логов и сбора дашбордов.

Этими всё не ограничивается, регулярно появляются новые, какие-то отмирают.
Пожалуй, самая динамичная часть, тут не знаю что сказать: чтобы их быстро выучить, достаточно быть проактивным, заранее учить SQL и как работать с базами данных, очень в этом месте пригождается.

7. Какой-нибудь из инструментов оркестрации: чаще Kubernetes, реже Docker Swarm, почти никогда Apache Methos.

Тут shell почти никак не поможет, но знание Linux даёт нужную эрудицию, чтобы этих зверёв также быстро освоить.

Инструменты оркестрации помогают сильно абстрагироваться от конкретного железа, но начать воспринимать набор машин как связанный кластер (или набор кластеров) со всеми вытекающими: установка пакетов сразу на множество машин; настройка каскадов, чтобы машинки поднимались в правильной последовательности и многое-многое другое.

8. Хранилки для уже собранных артефактов: например, какой-нибудь Nexus SonarType (хотя есть разные). Это, обычно, самая простая часть.

9. Инструменты для работы с сетью.

Почему? Ну, потому что нынче всё в интернетах.

Тут всё очень по-разному, конкретные перечислять в этом месте смысла нет, но чем больше знаете про сетевые протоколы, тем всё проще и легче.

Догадаетесь на чём работают роутеры/маршрутизаторы/dns-сервера?

Какие инструменты используют DevOps-инженеры?
Часть 4 из ... про devops

10. Как правильно заметил Виктор в комментах (спасибо!), HashiCorp Terraform.

Почему? Потому что позволяет описать как должна быть развёрнута инфраструктура, но на довольно низком уровне.
Хочется настроить сеть сразу на множестве машин — там это можно; нужно написать сколько дисков и с каким разбиением выделяется вот этому набору виртуальных машин (на которые потом раскатится этот самый докер или куб, например) — там это можно. Да, кажется, всё, что угодно можно.

Но с небольшой оговоркой: терраформу нужен какой-нибудь провайдер виртуализации, на голое железо он не заедет без этого (см. OpenStack, Proxmox, VMWare VStack), если хочется совсем голое железо — то, опять же, Ansible и shell в руки и действуем. На облачных провайдеров из-за этого раскатывается также хорошо и бесшёвно.

Язык для описания довольно хороший (сильно лучше yaml), действительно человечный. Рекомендую глянуть, чтобы знать как нормально.

Но и небольшой дисклеймер: 1) их выкупил IBM, 2) они уже два года как забанили русских (а-та-та!)

ладна на этих выходных без постов, продолжу где-нибудь на днях