DEV: Рубиновые тона – Telegram
DEV: Рубиновые тона
3.22K subscribers
143 photos
2 videos
8 files
976 links
Анонсы новых видео о программировании (Ruby/Rails, Solidity/Ethereum, Python, JS и не только), практические советы, обзор полезных инструментов и новости из мира IT
Download Telegram
В том году я ездил в Берлин, в первую очередь на концерт Garmarna (это там, где меня узнал гитарист, и где я на фото вышел как кретин, уже рассказывал раньше), ну и просто по делам. По итогу я как-то не поделился впечатлениями, а сейчас что-то вспомнилось.

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

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

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

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

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

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

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

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

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

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

https://www.youtube.com/watch?v=n4RjJKxsamQ
👍131
p.s. комментарии пришлось отключить для постов, но они работают для всех участников чата (то есть нужно просто войти в чат, дальше можно комментировать без проблем). Дело в том, что такими комментариями постоянно пользуются спамеры, которые сбрасывают скамерские ссылки
👍8👌3😱1😢1
😭14😱2👏1😨1
Фото выше - это очень старое изображение, которое актуальности всё ещё не теряет. К сожалению, я не думаю, что в обозримом будущем оно вдруг станет неактуальным. С одной стороны, можно сказать, что нудный препод опять тут грузит какой-то ерундой, но с другой мы видим что будет, если нудные преподы грузить не будут.

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

А фото к этому альбому было сделано в прошлом году, причём довольно неожиданно - я просто увидел подходящую локацию... Тут вообще город контрастов. https://soundcloud.com/ravens-die-laughing/a-place-to-call-home
👍17🌚2
В этом уроке по Rust мы поговорим о том, какие есть способы эффективной организации кода в проекте. Мы узнаем, что такое crates, модули, пакеты и как всё это между собой связано. Мы напишем несколько модулей, узнаем способы их подключения, а также рассмотрим подход с "прелюдией", который часто используется во многих библиотеках. https://www.youtube.com/watch?v=54m03X-_H3A
6❤‍🔥1
Что ж, конец года и время собрать набор финальных рекомендаций в уходящем 2023. 😄

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

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

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

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

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

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

Игры

* Phoenix Wright, Ace Attorney trilogy

Пока это всё, итоговый стрим будет 29 или 30 🤓
👍19
😁13😢4👍1😱1
Баллада об 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, предназначенная сразу для русского, украинского и белорусского языков.
🔥9👍41
Но, в итоге, весь этот хаос было решено хоть немного упорядочить, и появился стандарт 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 - это такой перевёрнутный знак вопроса, использующися в испанском языке.
🔥11
Правда, всё несколько сложнее, потому что 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. Справедливости ради, английский - язык международного общения, плюс программы тоже пишутся латинскими буквами.
👍5🔥4
Таким образом, появилось уже две кодировки: UTF8 и UTF16. Только в одной каждый символ занимал по 2 байта и надо ещё было разбираться, в какой последовательности эти байты записаны, а в другой многие "привычные" буквы занимали всего байт. Несложно догадаться, какая кодировка получила большую популярность.

Кстати, это не единственные варианты. Был такой зверь как UTF7, похожий на UTF8, но гарантировавший, что старший бит всегда будет содержать ноль. Это было сделано, чтобы текстовые сообщения, отправляемые через некие странные почтовые системы, доходили по-нормальному (иначе там могло быть такое, что часть информации обрезалась). Был и UCS4 (по факту, UTF32), который хранил данные по 4 байта, но это казалось слишком большим расточительством.

Собственно, теперь мы понимаем, что всяких кодировок действительно придумали изрядное количество. Отсюда растут ноги у таинственных вопросительных знаков, которые можно периодически встретить в некоторых случаях - это символы, которые в данной кодировке не получается отобразить. Грубо говоря, можно взять любую кодовую точку из Unicode и попытаться отобразить в ASCII, но далеко не для всех чисел получится найти соответствие, что и приведёт к появлению весёлых вопросительных знаков.

Из всего этого получается интересный вывод: строка фактически не будет иметь никакого смысла, если мы не знаем, какую кодировку она использует. Хотя мы всё равно используем термин "plain text", он оказывается довольно размытым, потому что неясно в какой-такой кодировке он "plain". Если в нём используются любые символы после 127, то ASCII тут тоже не поможет. Именно поэтому при создании веб-страниц в тэге meta мы пишем кодировку (а если не пишем, то *стоило бы это делать*) - аналогичная история с письмами.

Кстати, с веб-страницами вообще очень интересная штука. Изначально планировалось, что кодировку будет сообщать веб-сервер при отправке HTML. Но ведь на одном сервере может лежать огромное количество страниц и сайтов, использующих самые разные языки. Значит, лучше, чтобы сама веб-страница говорила, что у неё за кодировка. Но позвольте, как тогда нам эту страницу начать читать, если мы не имеем представления о её кодировке? Выходит замкнутный круг - чтобы прочитать страницу, нужно знать кодировку, а чтобы знать кодировку, нужно начать читать страницу. К счастью, в начале файла HTML мы обычно используем "стандартные" символы до 127, а meta располагается в самом начале документа, так что её можно обработать без проблем, а потом уже использовать указанную кодировку. Если же meta нет, то некоторые браузеры могут пытаться "угадать" кодировку с помошью анализа встречающихся "нестандартных" символов, но иногда это может привести к тому, что вместо кириллических символов вылезут какие-нибудь китайские иероглифы. Поэтому, дамы и господа, мы с вами должны чтить кодировку.
👍16🔥10🆒2
В этом уроке мы поговорим о разнообразных кодировках, которые используются в программном обеспечении (ASCII, UTF8, UTF16, UCS4), а также о стандарте Unicode. Поговорим о том, зачем нам нужно столько разных кодировок, откуда они взялись, чем отличаются, и какие являются наиболее актуальными. https://www.youtube.com/watch?v=E5uQeik0tdc
👍17
Что ж, друзья, очередной год завершается. Его итоги мы подвели на недавнем стриме, было круто, благодарю всех за участие 😄 Надеюсь, сегодня вы проведёте этот вечер (ночь) со своими близкими и/или друзьями в приятной обстановке, и что будущий год будет куда лучше уходящего.

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

Отличных всем праздников, очень скоро увидимся!

P.S. Желающие сделать небольшой подарок каналу могут забустить его вот тут: https://news.1rj.ru/str/dev_in_ruby_colors?boost

P.P.S. Ну, и одна из наших старых композиций, в относительно "новогоднем" стиле 🤪 https://youtu.be/EwKNZ0dXC9E
🎄184🎉2🍾2👍1