В этом коротком уроке по Solidity мы рассмотрим, как решить ошибку Stack too deep, которая может возникать при компиляции ваших контрактов. Мы поговорим о нескольких вариантах решения этой проблемы, которые вам могут помочь. https://www.youtube.com/watch?v=ITW3baJ63sI

Выходит OpenZeppelin Defender 2.0, теперь с фичей "проверка кода" (с помощью AI), "аудит" и парой других. Попробуем рассмотреть на досуге https://docs.openzeppelin.com/defender/v2

В этом уроке по Rust мы напишем первый проект: программу для создания скриншотов по нажатию клавиши! Мы рассмотрим, как использовать crates, как работать с аргументами командной строки, файлами, форматировать дату-время, а также как выполнять компиляцию для разных платформ с помощью cross. Для этого мы настроим GitHub Action, который будет компилировать проект автоматически и добавлять все версии в релиз. https://www.youtube.com/watch?v=gva5UYcHVWM

В том году я ездил в Берлин, в первую очередь на концерт Garmarna (это там, где меня узнал гитарист, и где я на фото вышел как кретин, уже рассказывал раньше), ну и просто по делам. По итогу я как-то не поделился впечатлениями, а сейчас что-то вспомнилось.

В первую очередь, совершенно непривычно для жителей стран бывшего PSRS (Padomju Savienība, он же СССР) выглядит то, что в воскресенье всё намертво закрывается. Как говорится, guess what, мы с кошкой под мышкой (извините за каламбур) приехали именно в воскресенье. Больше того, встретил нас водитель по имени, не поверите, Sunday, которому пришлось ждать лишний час, так как рейс задержали. В общем, пока доехали до отеля, было уже часов 9 вечера, а в округе закрыты буквально все магазины. Ну, потому что вот так принято.

Вообще-то, я не скажу, что в Риге ночная жизнь цветёт и пахнет - впрочем, иногда пахнет - но по крайней мере до 10 часов магазины работают. А тут, в общем, совсем ничего. Ну, разве что в лобби предлагали орешки и подобные штуки. Правда, после осмотра окрестностей мы обнаружили магазин для местных мусульман, который вполне себе работал - еда исключительно халяльная, но уже кое-что. Больше того, через какое-то время удалось даже найти итальянский ресторан, который закрывался аж в 12 ночи.

Я, в общем, понимаю, что тут зависит от района - мы поселились в эдаком "районе для стариков", где особенно ничего не происходит, но всё же приходилось принимать в учёт наличие номеров в отелях и возможность приехать с кошкой. Кстати, кошке прямо очень понравилось.

Достаточно большое впечатление произвели бывшие пропускные пункты у Берлинской стены. Сейчас тут, конечно, жизнь кипит, куча сувенирных и прочего, но в каком-то смысле всё равно чувствуется напряжение. Когда-то много лет назад Scorpions записали ту самую песню, которая, казалось, возвещает новую эпоху. Пожалуй, так и вышло, но теперь, к сожалению, эта эпоха уже завершилась.

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

Заходили в музей археологии, в целом, сделано на совесть, всякие няшные динозавры, скелеты, заспиртованные чудики. Я, честно говоря, не фанат музеев, мне как-то больше нравятся "живые" впечатления здесь и сейчас, но в общем было неплохо.

Пробовали, конечно, местную кухню. Очень понравилось в "картофельном доме" в самом центре, там буквально всё из картохи - блинчики, макароны, всякие закуски. (Пишу, а сам вспоминаю Беларусь - когда ещё доведётся побывать теперь...) Вообще-то, вкусно. Пиво классическое, но в этом плане в Германии консерватизм, как я заметил. Но мне лично не очень нравится "классическое" светлое пиво, тем более, что у меня на какой-то из компонентов аллергия, до сих пор не пойму, на какой. Серьёзно, кроме сидра и иногда тёмного пива типа Gulden Draak почти ничего не пью сейчас.

Интересно, что мы приходили в "картофельный дом" несколько раз, и нас запомнили (честно говоря, нас почему-то везде запоминают), предложили коктейли за счёт заведения - очень приятный сервис. Почему-то официанты очень удивлялись, когда мы оставляли привычные чаевые, хотя, кажется, это уже типичная практика, а для США - так даже мало получается. Интересно. В той же Швеции на чаевые прямо-таки *намекают*, даже если платишь картой (предлагается опция, сколько оставить).

Вообще, были много где, но общее впечатление такое: плавильный котёл - это теперь не только Париж, но и Берлин. Огромное количество культур, совершенно разных людей сосуществуют здесь вполне мирно. Впрочем, народу очень много, а после Риги - так вообще просто огромные толпы. Серьёзно, я прямо отвык от такого, честно говоря. В ковидные-то времена ещё ладно, хотя я мог вообще никого не встретить на пути от магазина и обратно, но даже сейчас человек 30-40 каких-нибудь ирландских болельщиков кажется *много*. А тут все куда-то спешат, повсюду большие довлеющие здания...

В общем, приехать туристом - пожалуй, жить - пожалуй, нет. Есть у меня хороший друг, который живёт Германии уже давненько (это Роман, он приходил на наши стримы неоднократно), ну они с семьёй перебрались подальше в глубинку. Впрочем, это на любителя, я думаю.

Такие вот заметки на манжетах. P.S. В понедельник у нас стрим по Solidity, а в субботу проводим финальную игру года.

https://www.youtube.com/watch?v=n4RjJKxsamQ

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

Скоро начинаем стрим https://youtube.com/live/XgUOzo-CCzU?feature=share

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

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

А фото к этому альбому было сделано в прошлом году, причём довольно неожиданно - я просто увидел подходящую локацию... Тут вообще город контрастов. https://soundcloud.com/ravens-die-laughing/a-place-to-call-home

В этом уроке по Rust мы поговорим о том, какие есть способы эффективной организации кода в проекте. Мы узнаем, что такое crates, модули, пакеты и как всё это между собой связано. Мы напишем несколько модулей, узнаем способы их подключения, а также рассмотрим подход с "прелюдией", который часто используется во многих библиотеках. https://www.youtube.com/watch?v=54m03X-_H3A

Скоро начинаем https://youtube.com/live/kly4fmJSzVc?feature=share

Сегодня заключительная часть серии стримов по токенам https://youtube.com/live/Z3NU7SsPeUM?feature=share

Ресурсы по теме computer science, хорошая подборка https://teachyourselfcs.com/

If a god of love and life ever did exist he's long since dead. Someone... something rules in his place https://www.youtube.com/watch?v=zyKuxeARmm0

Вышел Ruby 3.3.0 https://www.ruby-lang.org/en/news/2023/12/25/ruby-3-3-0-released/

Что ж, конец года и время собрать набор финальных рекомендаций в уходящем 2023. 😄

Фильмы/анимация

* Kimitachi wa Dō Ikiru ka (видимо, финальная работа Миядзаки)

Книги (не специальная литература)

* Дом, который построил Свифт (Г. Горин)
* Носорог (Э. Ионеско)

Музыкальные альбомы

* Everything is alive (Slowdive)
* Linea Aspera LP (одноимённая группа)
* Electric Sun (VNV Nation)

Игры

* Phoenix Wright, Ace Attorney trilogy

Пока это всё, итоговый стрим будет 29 или 30 🤓

Баллада об ASCII и Unicode

Эта статья написана с использованием руководства Джоэля Спольского, оригинал находится тут: https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/

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

Разбираться во всём этом действительно полезно, потому что разных языков в мире очень много, вопрос интернационализации (про то, что это такое, я писал тут https://lokalise.com/blog/software-internationalization/) и локализации весьма актуален. Если перенестись в стародавние времена, когда была написана первая версия книги о языке C (а это было аж 40 лет назад), мир вообще был проще, трава зеленее, да и пиво не разбавляли. Основное внимание тогда уделяли обычным латинским символам безо всяких изысков (то есть без умляутов и прочего). Для них использовался стандарт кодировки ASCII (American Standard Code for Information Interchange), который изначально появился ещё в 60-каком-то-бородатом году.

Суть его проста: каждую букву можно закодировать числом, к примеру "A" - это 65, "B" - 66, и так далее. Это можно проверить и сейчас, к примеру написав "A".ord в Ruby (хотя тут есть особенность, об этом позднее). Кстати, заметим, что тип char в C - это фактически просто целое число. Так вот, каждый символ кодировался числами от 32 до 127, и это прекрасно влезало в 7 бит. Ну, а так как компьютеры оперировали и 8 битами без проблем, то оставался ещё целый свободный бит, с помощью которого можно было воплотить в жизнь самые сокровенные фантазии.

Числа от 0 до 31 включительно использовались для всяких тёмных дел, и назывались "контрольные символы" (aka "непечатные"). К примеру, один из символов мог заставить компьютер пищать в самом прямом смысле, другой означал табуляцию, и так далее (про \n, \t и прочие, думаю, все знают). Вот тут есть список всех кодов: http://www.robelle.com/library/smugbook/ascii.html

В общем, всё работало прекрасно, но только для тех, кто использовал английский язык. Естественно, многим пришла в голову простая мысль: "Раз коды от 128 до 255 ни для чего не используются, то их можно задействовать под что угодно!". К сожалению, понятие "что угодно" у всех разное. Поэтому в IBM-PC эти коды выводили на экран всякие чёрточки, загогулины и символы квадратного корня (вот тут весь набор http://www.jimprice.com/ascii-dos.gif). Но в других системах ситуация могла быть совершенно иной. Так, если на некоторых компьютерах код 130 выводил é, то на компьютерах, продающихся в Израиле, это число кодировало букву гимель`ג`. Получалось, что документ, составленный в США и отправленный в Израиль, мог неправильно выводится (вспомним о таком слове, как "résumé").

С кириллическими символами там тоже была целая история. На излёте СССР был принят ГОСТ, вводивший кодировку КОИ8, совместимую с ASCII, придумал её мэтр Чернов, который, к сожалению, скончался лет шесть тому назад. КОИ8 как раз задействовала "лишние" коды начиная со 128-го. Были разновидности этой кодировки, например, KOI8-RU, предназначенная сразу для русского, украинского и белорусского языков.

Но, в итоге, весь этот хаос было решено хоть немного упорядочить, и появился стандарт ANSI (American National Standards Institute), который чётко зафиксировал, что означают числа до 128 (хотя, честно говоря, это и так в основном соблюдалось). А вот с числами от 128 и далее поступили интересно, введя такую штуку, как "code pages" (cp, кодовые страницы). В таких страницах зашивались как обычные латинские символы, так и "нестандартные" буквы алфавита той страны, где вы находитесь. Поэтому на территории бывшего СССР многие нежно любили кодировку "windows cp 1251" ровно потому, что 1251 - это номер соответствующей страницы с кириллическими символами. В Израиле использовалась 862, в Греции - 737, и так далее, таких таблиц было выше крыши. Некоторые страницы могли использоваться сразу для нескольких языков, но это, скорее, исключение.

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

В Азии же вообще царил трэш и угар, потому что в тамошних странах используются разнообразные иероглифы и всякие сложные закорючки, коих существует около 9000 - понятное дело, что в 8 бит это никак не уместить. Приходилось идти на всякие ухищрения и хранить некоторые символы в виде одного байта, некоторые - в виде двух, что весьма усложняло работу со строками (к примеру, не вполне ясно, как двигаться в строке назад). Да, конечно, для всего этого существовали вспомогательные функции, но в целом ситуация была так себе. Тем более, активно развивался интернет, тексты передавались с компьютера на компьютер, и нужно было этот бардак как-то разгребать.

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

Подход Unicode существенно отличался от того, что было раньше. Как мы уже выяснили, в ASCII ситуация простая: есть буква "A" латинского алфавита и есть её представление в виде битов "0100 0001", всё просто. В Unicode же букве сопоставляется code point (кодовая точка), которая в свою очередь имеет определённое представление в памяти или на диске, и это представление чётко не регламентировано.

Здесь есть важный момент. Мы понимаем, что латинская буква "A" - это не то же самое, что латинская "B". Отличается она и от маленькой буквы "a", так ведь? Но при этом "А", написанная курсивом или полужирным шрифтом, - это одно и то же. Больше того, "А", написанная шрифтом Arial, ничем со смысловой точки зрения не отличается от "А", написанной Helvetica. Значит ли это, что всякие "украшения" не важны и их можно никак не обозначать? Вообще-то, нет.

Думаю, многие знают, что в немецком языке есть символ ß. И это вовсе не "красивая буква B", а две буквы "s". В латышском языке имеется буква ķ, но это вовсе не "k" с чёрточкой для красоты, а отдельная буква. Поэтому "кот" будет именно "kaķis" ("катис", а не то, что вы подумали). Больше того, в иврите казалось бы одна и та же буква но написанная в разных местах и в разном "стиле" может иметь разное значение. Значит, эту информацию тоже нужно хранить! В общем, ситуация значительно сложнее, чем может показаться на первый взгляд, поэтому рабочая группа потратила целую кучу времени на поиски решения (тут есть и политические моменты, но нас это мало интересует).

Суть такова. Каждой "обычной букве без особых излишеств", то есть обычным "A", "B" и так далее, были присвоены специальные магические числа, записывающиеся в виде U+1234. Это магическое число - кодовая точка, U - понятное дело, Unicode, а сами цифры - шестнадцатиричные. На сайте Unicode все эти кодовые точки можно найти https://home.unicode.org/, к примеру, U+00BF - это такой перевёрнутный знак вопроса, использующися в испанском языке.

Правда, всё несколько сложнее, потому что Unicode позволяет модифицировать символы и получать новые комбинации. То есть можно добавлять комбинируемые диакритические знаки и акценты (типичный пример - знак ударения). Хотя для многих комбинаций есть уже готовые коды, можно собирать новые символы самостоятельно. Грубо говоря, если взять букву "е" и прилепить к ней две точки, получится "ё". Ну, а букву é можно представить как U+0065 (обычная латинская "e") и U+0301 (акцент, применяемый к предыдущей букве). В принципе, это значит, что из любой "нормальной" буквы можно получить странного франкенштейна.

По факту, никакого строгого предела на количество символов в Unicode нет, хотя некоторая часть влезает в размерность 2 байта (то есть 65 536 штук). Вообще, валидных кодовых точек Unicode сейчас около 1 112 064, поэтому история о том, что Unicode оперирует только двумя байтами - миф.

Другой интересный вопрос - как эти кодовые точки должны быть представлены в памяти или в сообщениях (в тех же электронных письмах). Для этого используются кодировки. Первая идея была весьма простой - давайте хранить эти шестнадцатиричные числа в двухбайтовом виде! Тогда строка "Hello" будет представлена как U+0048 U+0065 U+006C U+006C U+006F, а в памяти - просто как 00 48 00 65 00 6C 00 6C 00 6F. Называется такой подход UCS-2 (потому что байта два, сообщает cpt. Obvious) или UTF-16 (потому что 16 бит). Собственно, отсюда и пошёл миф, что в Unicode может быть только два байта, не более.

С другой стороны можно ведь написать 48 00 65 00 6C 00 6C 00 6F 00 (то есть использовать low-endian или high-endian, про эти термины как-нибудь в другой раз поговорим) - тут уж в зависимости от того, с чем будет сподручнее работать процессору.

Выходит, форм хранения уже по крайней мере две. Как их тогда различать? Было предложено в начало каждой строки добавлять такую штуку как Unicode Byte Order Mark (то есть метку, сообщающую о порядке следования байтов). Она выглядела как "FE FF" или "FF FE" (во втором случае это значит, что нужно байты переставить местами).

Потом задались и другим вопросом - а чего нам хранить все эти нули? Это особенно актуально для англоговорящих разработчиков, которые в основном использовали коды до U+00FF. С их точки зрения выходило, что для хранения строк приходится тратить в два раза больше места непонятно зачем. Это не говоря о том, что с дедушкиных времён осталась гора документов в ANSI и ещё бог знает чём, и никому не хотелось это всё конвертировать. Короче, до какого-то момента Unicode не получал распространения, но часики-то оглушительно тикали, и ситуация становилась хуже.

Тогда в 2003 придумали концепцию UTF-8 (https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt), которую предлагалось использовать для хранения строк Unicode (то есть Unicode != UTF8). Как подсказывает цифра 8, создатели предложили хранить данных в октетах (байтах), но их число варьируется в зависимости от кодовой точки. Иными словами, от U+0000 до U+007F (от 0 до 127) используеся лишь один байт, от U+0080 до U+07FF - два байта, и так далее. Максимум - 4 байта информации, что позволяет закодировать весь миллион с хвостиком кодовых точек, имеющихся на данный момент.

Это весьма удобно для документов US-ASCII (US - United States), которые как раз используют символы до U+007F, то есть каждый символ как раз кодируется одним байтом. Из этого следует, что такие документы выглядят одинаково что в ASCII, что в Unicode, то есть 65 - это "А" в обоих случаях. Поэтому на самом деле "A".ord вернёт код буквы для UTF8 ("A".encoding почти наверняка сообщит как раз UTF8, во всяком случае, на любой нормальной системе). Да, небольшая проблема заключается в том, что всему остальному миру всё равно пришлось подстраиваться под новый стандарт, но что поделать, ka ir tas ir. Справедливости ради, английский - язык международного общения, плюс программы тоже пишутся латинскими буквами.