Мы все привыкли к этому спутнику. Видим его почти каждый день ночью на небе. В разных формах. И, наверное, мало кто задумывается о его месте на орбите Солнечной системе. Даже в школьных учебниках бывшего предмета астрономии не упоминалось о чём пойдёт речь в этой статье. Давайте, для начала, посмотрим на нашу звёздную систему, так сказать, в компактном виде (масштаб не соблюдён):
Здесь можно наблюдать первые четыре от Солнца планеты. За ними кольцо астероидов (предположительно разрушенная планета Фаэтон). Дальше газовые гиганты.
Теперь давайте сфокусируемся на спутниках наших планет. У первых четырёх планет, так наываемых планет земной группы, формально 3 спутника. Одна Луна у Земли и два у Марса: Деймос и Фобос. Хотя если ближе познакомиться со спутниками Марса можно прийти к убеждению, что это астероиды притянутые Марсом во времена формирования кольца астероидов после разрушения Фаэтона. У Меркурия и Венеры спутников нет совсем. Остаётся Луна.
Ну а у газовых гигантов спутников размерностью с Луну очень дофига. Их там много и они большие!
Вот именно поэтому долгое время я был уверен, что в характеристиках нашего спутника нет ничего особенного, что есть действительно более внушительные луны у других планет. Был уверен до того момента, пока не сравнил их. Всего насчитывают более 900 спутников в Солнечной системе. Предлагаю рассмотреть первые 12 если упорядочить их по диаметру (масштаб соблюдён). В табличке можно пощёлкать по слолбикам диаметр и масса и убедиться, что, в большинстве случаев, эти величины коррелируются между собой, то есть чем больше диаметр тем больше масса спутника. Вроде всё сходится.
Забавно читать про первые. Крупнейший там, крупнейший сям. Однако даже здесь, даже не дойдя до середины списка мы увидим нашу Луну. Она пятая. Пятая в списке по диаметру среди крупнейших спутников Солнечной системы!
Теперь давайте перейдем к понятию “крупнейший”. Это какой? В нашем понимании это большой в линейном размере (в диаметре). Вот, например, условно говоря, Ганимед больше Луны в два раза. А вот уже объём Ганимеда в 8 раз больше Луны! Крупный Ганимед? Вроде крупный. И диаметр больше, а объём еще больше! Очевидно, что крупный!
Только вот здесь-то и кроется основная хитрость. Из урока физики 7-го класса. При каких условиях мы сравниваем два твёрдых тела по объёму? Правильно, при условии равной плотности! А вот теперь я предлагаю в табличке отсортировать спутники по последнему столбцу по убыванию. И что мы видим? А видим, что, так называемые “крупнейшие” спутники все дружно скатываются на 4 позиции вниз! Куда-то в середину таблицы! Вот тебе и “крупнейшие”…
Также мы можем наблюдать что Луна уверенно занимает второе место в списке! Причём от первого места отстаёт не более чем на 19% (и это только по массе, по плотности и диаметру меньше 10%). То есть, с погрешностью 20% мы можем сказать, что Луна один из крупнейших спутников Солнечной системы! Он оно как получилось!
Отсюда ещё более удивительным выглядит вопрос:
Какова вероятность того, что один из КРУПНЕЙШИХ спутников нашей звёздной системы окажется ЕДИНСТВЕННЫМ спутником среди планет земной группы на орбите, которая обеспечивает ИДЕАЛЬНОЕ солнечное затмение и у единственной планеты с развитой биосферой?
По моим подсчётам эта вероятность где-то в районе чуда!
Некоторое время назад, решили мы поменять тошнотворный Swagger на что-то современное. Остановились на Scalar-е. Современный, компактный и возможностей побольше. Здесь постараюсь рассказать с чем столкнулись при этом.
Действующие лица
Текущий проект. На котором API документация показывается в Swagger-е
OpenAPI. Спецификация по которой генеруется структура и описание REST API. Собственно то во что развился Swagger.
Swagger. В нашем случае UI, который отображает данные сгенерированные по стандарту OpenAPI.
Scalar. Просто UI, который отображает данные сгенерированные по стандарту OpenAPI и на который мы хотим смигрировать Swagger.
Springdoc. Прослойка между SpringBoot и нашей документацией
Инициируем типа наш текущий проект со Swagger-ом
Идем на сайт Spring, забираем SpringBoot3 приложение и добавляем в IDE
Идем по адресу localhost:8080/demo. Видим результат:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
curl http://localhost:8080/v3/api-docs
StatusCode:200
StatusDescription:
Content:{"openapi":"3.1.0","info":{"title":"OpenAPI definition","version":"v0"},"servers":[{"url":"http://localhost:8080","description":"Generated server url"}],"paths":{"/demo":{"get":{"tags":["demo-control
Как можно заметить, мы получили в ответ JSON файл, который собственно и содержит всю документацию о моем эндпоинте. Теперь его можно скармливать в любой UI или клиент. Они сами будут его парсить и отображать.
Идем по адресу localhost:8080/swagger-ui. Видим результат:Ностальгируем по 2015 году.
Вот в таком состоянии была наша документация перед миграцией на Scalar.
Первый подход. Дёшево, надежно, практично
Переход на Scalar у нас осуществлялся одновременно с разделением наших эндпоинтов на две разные группы, которые изначально предполагалось прятать за ролевой моделью. Соответственно нужно было иметь две разные непересекающиеся OpenAPI спецификации. Помогает в этом опять же Springdoc:
Как можно заметить, получился комбобоксик в правом верхнем углу, где можно переключаться между разными группами эндпоинтов. По началу это меня не устраивало, поскольку невозможно было разделить по ролям для отображения. Для этого нужно было иметь два разных эндпоинта, которые можно было бы подключать к соответствующим OpenAPI ссылкам.
Решение с мигрцией на Scalar, которое нашлось в сети, получилось весьма простым, топорным и очень гибким. Нужно просто на своей стороне генерировать HTML код:
Как это работает. Браузер получает HTML, загружает JavaScrip в строке 28, который в свою очередь получает конфигруцию из строки 27 и отрисовывает UI. А в строке 27 хранится пока путь к соответствующей OpenAPI документации.
Также есть возможность модифицировать HTML. Например, задать нужное название вкладки.
Идём по соотвествующим ссылкам. Видим необходимые документации:
Вуаля! Всё работает.
Но. В процессе код-ревью выясняется, что мы не хотим генерировать HTML и не хотим прятать документацию по ролям (т.е. все должны видеть всё). Начитается поиск иного пути.
Современный программист больше конфигуратор
Правильно. Меньше кода – больше конфигурации. Приходится открывать документацию по Scalar-у и читать ((
Итак, делаем как написано в доке:
Добавляем зависимость:
1
implementation'com.scalar.maven:scalar:0.1.0'
Добавляем свойства:
1
2
3
4
scalar:
url:/v3/api-docs
path:/docs
enabled:true
Идём по адресу localhost:8080/docs И пара-пара-пам! Приплыли! Сливаем воду! Иду на https://mvnrepository.com/artifact/com.scalar.maven/scalar. Вижу последнюю версию 0.4.4 (версии 0.1.0 нет вообще!). Пробую 0.4.4 – без изменений. Оригинальная документация бесполезна!
Конфигуратор не сдаётся никогда!
Ещё варианты? Кто-то где-то слышал, что Springdoc поддерживает Scalar. Удивительно но факт. Начинаю подключать Scalar через Springdoc:
Также давайте не забывать, что у нас уже был подключён Swagger. Поэтому нужно вернуть часть от Swagger-а назад дабы вернуть состояние приложения с которым я работал:
Запускаем, идём на localhost:8080/docs. И, о, чудо! Заработало!Только есть проблема. Работает как Swagger, так и Scalar. Вроде решение очевидное. Давайте изменим свойство springdoc.swagger-ui.enabled=false. Делаем. И не работает! Ни Swagger, ни Scalar! С ума сойти! Нафига мне две UI-ки? Лезу в код:
И что мы видим? А видим мы прямую зависимость Scalar-а от Swagger-а (стр. 24-25). Зачем?!
Как позже выяснилось отсюда было два выхода. Убрать зависимость Swagger-а или обновить версию Springdoc-а. Я пошёл по второму пути. Версия 2.8.15 решила эту проблему:
Супер! Анализируем, что получилось!
Основной навык конфигуратора отгадайка
Итак у нас получился весьма симпатичный результат:
Комбобоксик слева вверху. Франкенштейн в конфигурации. Там Springdoc использует конфигурацию Scalar-а. Я промочу о логотипчике и других конфигурационных свойствах, которые собирались отовсюду. Вроде всё устраивает, кроме названий селекторов в комбобоксике. Логично предположить, что это title в настройках скалара. Ок. Делаю:
YAML
1
2
3
4
5
6
7
8
scalar:
path: /docs
enabled: true
sources:
- url: /v3/api-docs/admin-group
title: Admin API
- url: /v3/api-docs/demo-group
title: Demo API
И что? И ничего. Всё без изменений! Мелочь, казалось бы. Но это нужно исправлять! А как понять, что делать? Опять таки, где читать? Нигде. Остаётся код. Лезем в код опять:
И что мы видим? А видим мы, мать вашу, тот же самый контроллер, который я написал вначале. Ничего сложного! Но вот, что касается нужного кода, то его собственно нет. Уходит он в метод org.springdoc.scalar.AbstractScalarController::getDocs. Только вот проблема. Нет такого класса в этом джарнике. Нет даже такого пакета! Хотя пакет от Springdoc!
Запускаю поиск класса AbstractScalarController в Jar Explorer-e по всему локальному репозиторию. И нахожу:
Сука! В common-е! В common-е лежит класс отвечающий за отображение Scalar-а! Зачем?!
Ладно, идём в код:
А в коде мы видим, что source инициируется особым образом в строке 39. title берется не из свойств Scalar-a, а из свойств групп, которые мы определяли ранее в Java коде! Причём, два дурих свойств Scalar-a тупо обнуляются! То есть их невозможно установить от слова никогда! Также рекомендую обратить внимание на строчки 42 и 43. Сейчас нам они не понадобятся, но в дальнешем, еще с ними столкнёмся в другой проблеме. Там тупо меняется композиционная переменная контроллера т.е. синглтона.
также был добавлен логотипчик, убрана консоль разработчика, добавлен title на табку браузера и другие мелочи
Вроде всё готово! Можно в прод!
Деплою в темп для теста и… нихрена не работает!
Страничка грузится, JavaScript загружается, всё подтягивается кроме OpenAPI JSON файла. Ссылка на него: “url”:”http://temp:443/v3/api-docs/demo-group”. Кик видим протокол HTTP, а порт HTTPS. Браузер такое наебалово не любит, а поэтому отказывается загружать.
Пробую как-то это исправить на своей стороне. Документация бесполезна, поэтому сразу лезу в код:
Что бросается в глаза? Строчки с 3 по 6. Самый главный вопрос зачем? Зачем тянуть в код тестовый URL Scalar-a? Это когда вы строите демку Scalar-a, чтобы посмотреть как работает. Но зачем её протягивать сквозь Java код – непонятно севершенно!
Тем не менее, вроде как, можно в Scalar-е указать один верхний URL типа: /v3/api-docs и всё должно подтянуть (условие не сработает). Делаю. И всё работает! Ура! Но только первый раз при заходе на страничку. Дальше – нифига! А почему? А помните те две строчки выше, на которые я обращал внимание? Вот они то и влияют на это поведение. Первый раз все хорошо, а потом null вместо URL потому как оно перетёрлось в свойствах.
Следующим действием попробовал я последнюю версию org.springdoc:springdoc-openapi-starter-webmvc-scalar. На тот момент 3.0.1. А эта зараза требует SpringBoot4. Я вроде подглядел в код последнего Springdoc Scalar-a и мне показалось что там что-то изменено. Посим я из последних сих заодно обновил наш SpringBoot3 со всеми зависимостями, но всё было по прежнему!
Выть хотелось! Бред какой-то. Никак здесь в моём случае невозможно избежать абсолютной ссылки.
Как выяснилось позже наша аппка была спрятана за проксиком, а эти проксики на каждом энвайрменте были по разному сконфигурированы, на одном, например, был протокол HTTP, а на другом HTTPS. Поэтому пришлось захардкодить в настройках деплоймента соответствующие хедеры:
1
2
x-forwarded-proto=https
x-forwarded-port=443
После этого всё заработало.
P.S. Польза от всякоразных ИИ закончилась на кастомном контроллере. В дальнейшем все, что мне удалось попробовать, были абсолютно бесполезны. Один из них до последнего пытался мне вставить свойство логотипчика в конфигурацию Scalar-а. Хотя его там никогда не было и нет до сих пор. Такое…
В продолжении размышлений про электричество хотелось бы расширить тему про преобразование електрической энергии в другие виды энергий. Как было замечено ранее то что мы называем електричеством очевидно представляет из себя особый вид энергии, которая может быть преобразована в другие виды энергий с помощью различных материалов и их форм. Замечу, что здесь к физике процесса присоединяются взаимодействие веществ и их характеристики, а также форма тела как физические процессы. Например, из особого раствора в аккумуляторе или батарейке мы получаем, то что называем электричеством. И если химия искусственно отделена от физики, что является по сути предрассудком, то вот форма тела, очевидно, в данном случае, выступает как отдельная физическая характеристика. К примеру, из одной и той же проволоки можно получить физическую сущность как электомагнитное поле, свернув её в катушку, так и нагреть окружающую среду. А можно и то и другое в зависимости от того какую форму придать этому куску проволоки и какой ток через неё пропустить.
Другими словами если подитожить очевидные вещи, то можно сказать, что преобразование электричества в другие виды энергии тесно связано с материаловедением и формой этого же материала, а, значит, мы можем рассматривать это как физические сущности.
Рассмотрим какие же преобразования нам известны:
Прямое преобразование
Обратное преобразование
Световое
Лампа накаливание, диодные лампы
Фотоелемент
Тепловое
Отопительный радиатор, резистор
Термоэлектрогенератор
Механическое
Электродвигатель
Генерация переменного тока
Химическое
Электролиз
Аккумулятор
Электромагнитное
Катушка, антенна
Генерация переменного тока
Электронное
ЭЛП
Как можно видеть, нам известны практически все виды преобразований электрической энергии в другие виды энергий, а также справедливо обратное. Мы можем добывать электриктрическую энергию из иный видов энергий.
Любопытная ситуация с электронным преобразованием. Мы достаточно уверенно освоили преобразование электричества в поток электронов. Но вот обратное преобразование практически неосвоено. А оно, на мой взглад, может весьма ощутимо освоить добычу электричества в АЭС. Ведь очевидно, что возможность получать электричество непосредственно из ядра реактора значительно увеличит КПД этих станций.
Вместо вывода можно сказать, что комбинируя материалы, придавая им оиределённую форму, мы можем преобразовывать электрическую энергию в другие виды энергии и наоборот.
Если говорить о понимании оператора JOIN в SQL, то в голову приходят круги Эйлера, которых на просторах интернета существует целая тьма. Легко можно нагуглить нечто вроде:
Предполагается, что глядя на все эти кружки, читатель легко сложит представление, о том как работают join-ы. Очень долгое время я сам этим страдал. Ведь интуитивно же понятно, что тот же INNER JOIN вернёт записи, что совпадают в обеих таблицах по некоему ключу.
Данное ошибочное понимание разрушается простейшим вопросом, например, какое минимальное количество записей вернёт LEFT JOIN?
В голове тут же всплывает следующая картинка:
Ну и ты, соответственно, начинаешь метаться между первой и второй, причём абсолютно не понимая в каких терминах мыслить. Очевидно, что справа результирующее множество (в терминологии кругов Эйлера) меньше. Но, что отображает рисунок справа? Это все записи левой таблицы исключая совпадения из правой таблицы. А как посчитать эти совпадения не абстрактно? И это в случае дополнительного фильтра WHERE. Слева рисунок вроде как говорит, что результатом будут все записи из левой таблицы (и тут непонятно зачем тогда нужен join если мы получаем просто обычный SELECT). Дальше, если мы смотрим на фильр “ON a.id = b.id”, то мы должны взять только пересечение, а это получается INNER JOIN. Бред! Если не знать, как работают join-ы, догадаться о деталях, глядя на круги Эйлера, НЕРЕАЛЬНО!
Возникает вопрос: почему?
Давайте начнём с кругов Эйлера. Проблематика диаграм этого типа заключается в том, что они прекрасно работают с множествами, которые содержат УНИКАЛЬНАЕ элементы. Если же множества содержат дубликаты (в математике, в большинстве случаев, это бесмысленно, но в прогрммировании такое сплошь и рядом) круги Эйлера НЕ РАБОТАЮТ! Доказать элементарно. Рассмотрим следующую картинку:
Есть множество А, которое содержит 2 красных шарика. И множество В, которое содержит 1 красный шарик. Вопрос если мы будем объединять эти два множества по красным шарикам, как мы это должны отобразить? Что получим – понятно: 3 красных шарика, а вот как отобразить кругами Эйлера? Семантически похожая операция INNER JOIN отображается в кругах Эйлера как пересечение. Но разве это то, что нам нужно?
С join-ами ещё сложнее. Ведь результирующий элемент join-а это совершенно новая сущность, которая предствляет из себя совокупность всех ячеек из всех столбцов ОБЕИХ таблиц! Это даже не дубликаты в множествах. Это вообще два разнородных множества, которые порождают новое разнородное множество элементов. С ума сойти! И это всё пытаются впихнуть в круги Эйлера! Зачем так поступать с замечательным математиком!?..
Итак, можем ли мы как-то отобразить схематически join-ы не используя круги Эйлера? У меня получилось нечто вроде такого:
На мой взгляд, на данной диаграмме отчетливо видно:
Результатом join-a является объединение всех столбцов двух таблиц.
В верхней части отображены данные из левой таблицы, что не удовлетворяют условию ON a.id = b.id. Отчетливо видно что дополненые ячейки из правой таблицы “забиты” нулями. Это отвечает на вопрос о том что LEFT JOIN это не SELECT.
В средней части мы наблюдаем INNER JOIN. И как можно видеть, что INNER JOIN – это не просто пересечение из общих данных для обеих таблиц. Но это список новых кортежей состоящих из объединения столбцов двух таблиц в случае ON a.id = b.id.
Ну и в нижней части можно заметить данные из правой таблицы, что не попали в результат выборки.
В данной диаграмме не отображены только кортежи, которые могут появиться в средней части в случае, когда один элемент из левой таблицы имеет множество совпадений из правой. Но это единственный минус. Все остальные ньюансы присутствуют.
И имея такую диаграму тут же понятно почему запрос SELECT * FROM tableA a LEFT JOIN tableB b ON a.id=b.id WHERE b.id IS NULL возвращает только часть таблицы A и почему b.id может быть NULL:
Без такого представления, а имея только круги Эйлера, мне было совершенно непонятно почему вообще что-то возвращается, когда b.id является NULL! Ведь если не знать как работает join и читать квери “в лоб, то получается полная ахинея. Типа сделай мне join и выбери из него только те кортежи, где b.id является NULL. Но в таком случае, если b.id является NULL, то и a.id является NULL по условию ON. А как такое может быть?! Из кругов Эйлера это НЕОЧЕВИДНО абсолютно!
Нужно где-то положить конец этому вопросу. Его раньше любили на собеседованиях. Да и для программиста не лишним будет окончательное понимание как оно работает.
Итак, в Java8 появились дефолтные методы в интерфейсах. Появились как костыль, на котором удержалось backward compatibility. Например, как имплементировать следующий код не положив код написанный в ранних версиях Java?
Java
1
2
List list=newArrayList();
list.stream();
Ведь если мы добавим метод в интерфейс List, то предыдущие версии попадают с ошибкой, поскольку такого метода нет в их имплементации наследников этого интерфейса. А если я скажу что метод stream() добавлен ещё выше? В интерфейсе Collection. А forEach() в Iterable? Ляжет ВСЁ! Можно было бы создать отдельный утилитный класс типа Collections, который бы предоставлял нужные обёртки. Но выглядело это как некий оверхэд. Поэтому были придуманы дефолтные методы для интерфейсов. Ну и туда же положили статические методы.
В контексте этого поста будет рассмотрен случай когда в родительских интерфейсах существуют методы с одинаковой сигнатурой.
Static
Начнем с простейшего. Со статических методов.
Предлагаю рассмотреть следующий код:
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
interfaceA{
staticStringstat(){
return"statA";
}
}
interfaceB{
staticStringstat(){
return"statB";
}
}
classCimplementsA,B{
staticStringstat(){
return"statC";
}
}
publicclassStatic{
publicstaticvoidmain(String[]args){
System.out.println("$ "+A.stat());
System.out.println("$ "+B.stat());
System.out.println("$ "+C.stat());
}
}
//output
$statA
$statB
$statC
Есть два интерфейса с одним и тем же статическим методом. И класс, который имплементит эти два интерфейса. В данном случае Java не обязывает имплементить статический метод интерфейса. Мы можем добавить такой же статический метод в класс С и он никакого отношения не будет иметь к методам родительских интерфейсов. Собственно, работает так же само как и для обычных классов. Если мы попытаемся добавить аннотацию @Override к методу С.stat() получим ошибку: “The method stat() of type C must override or implement a supertype method”.
То есть статические методы можно использовать смело не боясь конфликтов в имплементациях.
Abstract methods
Рассмотрим следующий отрывок кода:
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
interfaceA{
Stringapply();
}
interfaceB{
Stringapply();
}
classCimplementsA,B{
@Override
publicStringapply(){
return"methC";
}
}
publicclassAbstract{
publicstaticvoidmain(String[]args){
System.out.println("$ "+newC().apply());
}
}
// output
$methC
Всё как в предыдущем примере. Два одинаковых метода. Класс замечательно переопределяет этот метод. Кажется, ничего сложного нет и кейс проще, чем со статикой. Но давайте изменим возвращаемый тип метода в интерфейсе А. Получим ошибку при компиляции класса С: “The return type is incompatible with A.apply()”. Также интересная ситуация будет с исключением, если его нужно объявить в классе С. В таком случае это же исключение должно быть добавлено ко всем методам родительских интерфейсов. С другой стороны всё проще. Исключения могут быть объявлены в интерфейсах какие угодно и сколько угодно. Переопределяемый метод в классе может их полностью игноировать.
Получается, что абстрактные методы с одинаковой сигнатурой могут быть переопределны в классе только в том случае, если у них одинаковый возвращаемый тип и выбрасываемое исключение “покрывается” (поглощается родительским типом исключения или указано в родительском интерфейсе) всеми родительскими интерфейсами.
Default methods
Ну и наконец дефолтные методы:
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
interfaceA{
defaultStringdef(){
return"defA";
}
}
interfaceB{
defaultStringdef(){
return"defB";
}
}
classCimplementsA,B{
@Override
publicStringdef(){
// return A.super.def();
// return B.super.def();
return"defC";
}
}
publicclassDefault{
publicstaticvoidmain(String[]args){
System.out.println("$ "+newC().def());
}
}
// output
$defC
Как можно видеть переопределение метода в классе С точно такое же как и у обычного абстрактного метода. Внутри метода класса С можно вызывать дефолтный метод из любого родительского интерфейса напрямую, а также можно имплементировать любую вашу логику. Всё остальное также справедливо как и для абстрактных методов.
Недавеча появилась идея запилить проэкт для мультимедийного центра. Ну, чтоб фильмы смотреть. Идея простая фильмы на диске, а через веб-морду пользователь получает доступ к эти фильмам. Заодно можно предоставить дополнительную информацию такую как разрешение, кол-во аудиодорожек и т.д.
Ну и одновременно с этим стояла задача прокачать скилы чтоб типа мощно, модно, молодёжно. Поэтому получился следующий стэк: Angular 16.0.0, SpringBoot 3.0.6, Java 17 ну и Kotlin. Про недостатки ангуляра и спринга здесь опущу и сфокусируюсь на моих эмоциях по поводу последнего.
Услышал я о нём давно. Уж точно не помню когда. Может быть году в 15-ом, может раньше. Скажу сразу. Не интересовался, не читал. Страничку вики открыл только сейчас. И представление моё о нём было как некий язык, со своим синтаксисом и чудо компилятором, который что-то чудесничал и делал сразу байт код мимо стандартного java-компилятора. Не знаю, почему так думал. Может где-то прочитал, может не мог поверить, что великий Kotlin это тот же Groovy. Не знаю. Забегая наперёд – это всё-таки ещё один Groovy. Вот в таком вот приподнятом настроении я открыл https://start.spring.io/.
IDE
Приподнятое настроение закончилось ещё до того как я написал свою первую строчку кода на Kotlin-е. Когда я два или три дня потратил на интеграцию Kotlin-воркспейса в Eclipse. И честно признаюсь, у меня уже была стойкая и разумная мысль послать его к чертям и захерячить всё на Java. Сей разумный шаг не дала совершить моя профессиональная гордость. Я, если честно, так и не понял, в чём заключалась проблема. Сначала накатил честный плагин из маркет плейса. И проект упал. Я за 10+ лет такой ошибки в эклипсе не видел. Не могу заскриншотить её. Не думал, что буду писать это, так что не собирал скрины. Помню красный крест при открытии “Package Explorer”. Интернет плохо помогает в этом. Я даже писал отдельную тулзу для переименования файлов плагина (добавлял расширения “.class”) – не помогло. Пофиксил только установлением ещё одного плагина, где присутсвует имя Kotlin. Их там два вроде всего было. И вот с этим всем барахлом эклипс не очень хорошо себя чувствует. Часто уходит в норэспонс, особенно, когда пользуешь контекстное меню. При этом съедается CPU безбожно. Периодически приходится перезагружать IDE.
RedCode
Несмотря на то, что приложение успешно компилировалось, запускалось и работало, некоторые строки кода эклипс так и не распознавал. Дико на них ругался и чёркал красным. Я не сильно заморачивался, чтобы это пофиксить. Может и можно. Мне было некогда и неинтересно.
Static
Первое, наверное, с чем я столкнулся это статические методы. Здесь разработчики Kotlin-а поступили ещё лицемерней, нежели разработчики Java. Если разработчики Java везде где только можно вопят о том что Java это объектно-ориентированный язык, при этом скромно умалчивают о процедурном бекдоре в виде модификатора static, то разработчики Kotlin-а решили вопрос кардинально – запретили этот модификатор! Совсем. Но статический доступ есть. Через одно, извините, место.
Не знаю, какие преимущества такая реализация статики даёт по сравнению с Java статикой. То, что усложнили жизнь программисту – это факт.
NonNull
Ещё одна параинодальная фича. Среди конфигураторов спринга когда-то бытовало мнение, что NPE это плохо. И возможно оно так и было лет эдак 10+ назад. Сейчас даже для спринга нет такой проблемы. К тому же в последних Java версиях эта ошибка довольно качественно описывается. Так что для меня как программиста проблемы null не существует. Вот в принципе. Все возможные NPE должны отлавливаться на этапе тестирования. А для меня в программе null быть обязан. Особенно в высоко нагруженных системах, где создавать объекты-пустышки или обёртки слишком дорого. null вполне себе однозначное определение состояния объекта. В Kotlin-е зачем-то решили это как-то фиксить. Думаю, это была модная фича на заре становления этого языка. Дабы привлечь конфигураторов с секты спринга и прочих блаженных мечтателей избавления от шайтан-нуля.
В Котлин-е подошли прямолинейно. Где бы ты ни инициализировал переменную, ты обязан определить может ли она принимать значения null или нет. Я не знаю чем думали такие как Тагир изобретая этот подход, но применять на практике мне было не удобно от слова совсем. Наверное предполагается иметь в голове совершенно продуманную архитектуру вашего приложения вплоть до того будет та или иная переменная нулём или нет. И только после этого начинать писать код. Я, к сожалению, так не умею. И мне было ооочень некомфортно периодически скакать по классам и править уже написанный код. И хорошо, когда это прицепом не тянет интеграцию с фрейморками. В таком случае застряёшь на некоторое время, думая как это пофиксить. Не понял, не принял.
Замыкания
Замыкания, кложи, ламбды. Я не знаю, как это называется в Kotlin-е, но, думаю, что это всё очень весело выглядело до Java 8. Сейчас же это выглядит вполне себе уродски, нелогично и интуитивно непонятно. Вот такое, например:
Что такое Unit и почему я должен указать его, чтобы проигнорировать результат выполнения?.. И почему я должен активизировать лямбду так же как создаю новый объект? И вообще это что, создание объекта или вызов метода?!
А здесь про “лаконичность”:
Непросто возврат, а ещё и нужно указать, откуда именно возвращать. Хз для чего нужно было городить такой огород…
К “лаконичности” ещё можно отнести имена класса: Scanner::class, Scanner::class.java, javaClass.
Коллекции
Здесь тоже, я считаю, разработчики Kotlin выстрелили себе в ногу преследуя цель сделать что-то лучше, нежели ребята из Sun\Oracle. Не буду закапываться по мелочам. Скажу моё общее впечатление, что легко юзать Java коллекции у меня не получилось. Постоянно приходилось искать те или иные воркэраунды в, казалось бы, примитивных операциях. А разбираться в скудном предложении от Kotlin-а мне не хотелось.
Cast
Думаю, уже можно сложить мнение как протекала разработка, было открыто много страничек в браузере. Сложилось впечатление, что Kotlin не особо описан в интернете. Решения если и находились, то непрямые и с трудом. Но больше всего времени было потрачено на поиск причины бага, связанного с приведением типа. К сожалению, подробных деталей я уже здесь не приведу – давно это было. Что помню. Значит, данные у меня хранятся в файле в виде обычного json. При старте, я выгружаю json (список моих фильмов) ну и далее пользую по коду. И вот при выгружении данных я приводил их к моему типу. Kotlin это пропускал без ошибок. Всё типа ок. Ну а далее по коду, когда я пытался итерировать по списку моих данных, Java ругалась, что не может закастить мапу к моему типу объекта. Вот тут началось. Наверное, я испытывал панику спринг конфигуристов на заре зарождения сего чуда. Ошибка вроде понятна. Но абсолютно не понятно почему. Ведь надеешься на то, что Kotlin принял приведение к типу. В процессе поиска я и нашёл компилированные Java файлы.
Как можно наблюдать ничего нового. Тот же Groovy. Последний можно перегружать в рантайме. Можно ли такое делать с Kotlin – не знаю.
Вообщем, каким-то чудом, я докопал до того что из json вылазит не мой объект, а мапа, которую Kotlin игнорит и спокойно позволяет кастить к чему угодно.
Пока всё. Не знаю будет ли что-то ещё. Я лично не нашёл для себя, каких либо мега-ацки крутых фич, которые бы привлекли меня и дальше пользовать Kotlin.
Нужно начинать хоть с чего-нибудь. Эта статья задержалась лет, эдак, на четыре. Всё началось, что в очередном отпуске разгребал я старые бумажки. Без всякой цели. Время коротал, ностальгия – выбирайте, что вам ближе. Ну и добираюсь до пачки с прайслистами и заказом на сборку моего первого компьютера:
“Раскладка” моего первого ПК. В сааамом правом нижнем углу – цена в долларах ФРС.
“Раскладка”, думаю, ни у кого вопросов не вызовет, а вот прайс листы могут показаться необычными при покупке компьютера. Дело в том, что в 2000-году интернета не было. Вот в принципе не было. Он-то где-то, конечно же, был, но пользоваться им было нереально. Бизнес его, по большому счёту, игнорировал по совсем уж понятным причинам. С другой стороны компьютеры продавать было нужно. Удивительно, но потребитель уж как-то сам допёр из чего состоит ПК и как нужно его собирать. Не сам собирать, понятное дело, а что туда внутрь покупать, чтобы тебе это собрали в кучу. Меня, лично, никто не учил. Как-то оно само за 3-4-е месяца освоилось. Это я к тому, что сейчас идёт поголовное отупение потребителя одной кнопкой на компьютере и мышкой вообще без кнопок. Так вот. Компьютерные фирмы все своё железо с ценами распечатывали на А4-х листах и с радостью отдавали любому, кто попросит. В среднем 3-4 листа с таблицами и 10-ым шрифтом. Это было поначалу. Чуть позже начали жлобиться, когда ажиотаж чуть спал и компании стали считать расходы.
И вот, глядя на “раскладку” меня осеняет всё это материализовать. Почему нет? Одни бронзовых чёртиков коллекционируют, а почему мне нельзя вернуть к жизни мой первый и, наверное, самый памятный ПК? Вроде как есть возможность, никто не торопит – собирай потихоньку…
Ну и понеслось. Сайты объявлений, интернет, знакомые.
Семисотый есть, шестисотый тоже. А вот шестьсот пятидесятого – нигде. Единственное место – Донецк. Год 2018. Связь с продавцом есть. Как-то нужно доставать. Вообщем, я убеждаю человека, что мне очень это нужно и я готов за проц и материнку выложить $25. Не знаю как он передавал это всё через линию фронта, но у нас получилось. Деньги я переводил через банк ВТБ. Он тогда еще действовал. Проц со сколами, но работает. Вообще-то и у моего был кристалл повреждён – видимо, это такое свойство дюронов. Не зря ж такое имя…
Чуть позже я приобрел ещё один шестьсот пятидесятый на ибэе. Заодно и попробовал, как оно там покупать. Это был мой первый опыт – товарищ помог.
Материнка
С материнкой было проще. На сайте объявлений было даже две. Причем разные. Это нормально почему-то. Я обе и забрал. Обе с опухшими конденсаторами. После перепайки – все заработало. По сумме вроде $20 встало.
Cooler
По правде, я уже точно не помню что у меня проц охлаждало. Точно это был недорогой, черный, вытянутый вверх радиатор с простеньким вентилятором. Был ли это Titan – не помню. В этот раз загорелся медным кулером. С трудом нашел его на ибэе и забрал. По стоимости уже не помню, но вроде дюже недёшево оказалось. Считаю, что на реконструкцию это не влияет, поскольку является обслуживающим элементом.
Память
Изначально было 64Mb. В 2003-ем году докупил ещё 256. Прирост производительности – нереальный. Отдельно память не покупал – досталась с одной из материнок. К тому же дома в загашниках завалялось немного. Кстати, покупать по объявлениям рулетка та ещё. Один лот – покупаешь за бесценок кучу всяких ништяков. А другой за чепухнёвую вещь цену сложить не может. Такое ещё развлечение…
Винчестер
HDD Samsung 7.6Gb
Жесткий диск я случайно нашел в интернете. Какой-то магазин, после ремонта, наверное. Но работает. Тогда я ещё не столкнулся с процессорной эпопеей и не понимал, как мне повезло. Вещь ооочень редкая.
Помню, как мне его не хватало. Была игра про подводные лодки. На диске занимала около 2Gb. А вот видяха её тогда не тянула. И лежала эта игра у меня на диске некоторое время. А фильмы? Каждый по 700Gb. Потом подтянулся MSDN. Вообщем места не хватало постоянно. Пишущие CD дисководы только-только начали появляться, да и денег на сей девайс, по большому счёту, не было. Тем не менее, нарекания на работу отсутствовали. Куда делся – уже и не помню.
Из особенностей данного жесткого диска можно отметить “играющую” пластиковую накладку сбоку на верхней части устройства. В более поздних моделях такого же форм-фактора она отсутствовала. “Грубая” и “топорная” электроника с надежной контактной площадкой на плате управления.
Видеоадаптер
Компьютер покупался не для игр, но, естественно, играть пытался. Классическая ситуация. В принципе, большинство игр бегало без каких либо проблем. Архитектура была новая. Сложился вполне себе неплохой стандарт AGP. Игры упирались исключительно в память и GPU. Поэтому до 2004-го года мне, за глаза, хватало игр написанных в 90-е. Должен сказать, многие из них были на достойном уровне для того времени.
Когда начал искать видяшку столкнулся с большим разнообразием производителей. Помню, у меня была карточка зелёная, без “свеса” за слотом AGP и слотами для добавления памяти. Как же я на них заглядывался в своё время. Но не знал где купить дополнительные микросхемы памяти и боялся, что могу спалить устройство. Нашёл я её, можно сказать, с трудом. Со второго раза и не сразу.
Флоппик
Вот так забавно продавались раньше флоппи-дисководы. И это в то время, когда дискеты были, можно сказать, единственным средством переноса информации. Просто дисковод 3,5″ $13. Всё. Очень смутно припоминаю, что это был TEAC. Помню, поскольку выглядел дисковод некрасиво. Из лотка выпирал грубый магниевый корпус. Я тогда ещё не столкнулся с бумажными самсунгами и митсумами второй половины 2000-х, которые, даже новые не работали с новыми дискетами. Естественно, искал на сайте объявлений. Как ни странно, в 2018-ом таких было много. Взял несколько. Один пытался почистить – но назад не смог собрать. Второй поставил как есть. Еще нашел TEAC поздних выпусков тоже на штампованном основании. Одним словом, сейчас стоит рабочий TEAC с магниевой основой.
CD-ROM
Брал самый дешёвый брендованый. “Угадал”. Диск разорвал через несколько месяцев. Какой-то он был бешенный по сравнению с TEAC-ом на который я его поменял. Сейчас же поставил, естественно, TEAC. Особых проблем в 2018-ом с ним не было. Только, правда, пришлось вспомнить, насколько скоростной у меня был. А так, купил несколько – на всякий случай.
Корпус
Вот это именно то, что больше всего запомнилось в этой сборке. Прошло много лет. Я даже не помню, куда делся мой предыдущий корпус. Последний раз я его мог помнить в 2005-ом или 2006-ом году. Помню кнопку включения и уголки внизу. Как искать в интернете? Копал везде, в том числе и на avito. На нём то и нашел. В Питере. Как везти опять-таки через границу? После мучительных раздумий и переживаний решил рискнуть $55. Сама железяка копейки стоила. Большая часть суммы ушла на доставку. И вот через полтора месяца корпус у меня. Кривой, косой, с неродными заглушками и к тому же я понимаю, что мой был выше, а этот низкий. Вообщем, коротышка из моей серии. Грустно.
И вот в один день, листаю местный сайт с объявлениями и в контекстной рекламе мелькает мой корпус. Причем с той же наклейкой “Intercom”. Продавался он как компьютер в сборе, но тоже за копейки. Забрал его и в нём же собрал в итоге компьютер.
Блок питания по принципу кулера. FSP 300 или 350Вт.
Колонки
Ничего особенного. Легендарные, да и просто хорошие колонки того времени. Нашёл без проблем. Правда, похрипывают. Нужно бы залезть внутрь – проводок подпаять.
Монитор
Красивый на то время. Правда, через несколько месяцев начал “зеленить”. Приходилось дергать VGA-шный кабель. “Зеленение” то пропадало, то появлялось вновь. До сервиса не мог дойти на протяжении, практически, трёх лет. Думал, что гарантия уже прошла, пока не нашел среди документов самсунговскую оригинальную гарантийку с печатью. На удивление починили бесплатно. Сказали что “окалина в пушке”. Наврали, очевидно. Ну а так, воспоминания о мониторе вполне теплые. Разрешение 800х600. И в него нужно было вписать Visual Studio 6.0. Когда писал код – все пиксели видно было. Душевно…
Его я тоже не стал восстанавливать в полном смысле этого слова. Заменил семнашкой из той же серии. Глаза, боюсь, не простят уже 550s.
Клавиатура
С клавиатурой не получилось. Помню, была Chicony слимовская. Но даже на начало 2000-х она не часто встречалась. Поэтому неудивительно, что я её не нашёл в 2018. Заменил максимально схожей Sven.
Мышь
Простенькая Mitsumi. С шариком и без колесика. Очень непривычно сейчас ею пользоваться. Достать было просто. Стоила копейки.
Коврик
По-моему, рисунка не было. Вместо рисунка была красная тряпочка наклеенная на резинообразную основу. Впоследствии эта тряпочка отклеилась с уголка и задралась. Поменял я его на коврик из пробкового дуба. Помню, был красивый срез с текстурой пробкового дерева. Сейчас таких, к сожалению, в продаже нет. Нашел пробковый коврик, но там резины, наверное, больше, чем самих пробковых опилок. Брал новый в магазине.
Операционка
Естественно пиратка. Ставилась всем по умолчанию. Проработала без нареканий и сдала свой пост XP-шке году, эдак, в 2004-ом. А может и ушла вместе с винчестером в нонэйм покупателя. Вот совсем не помню. Вместе с операционкой была квака I. Сначала вызывала отвращение, но, со временем, втянулся и сейчас считаю одной из лучших игр.
Также, помнится, красивая иконка моего компьютера. Вполне себе реалистичная, а не то убожество, что по умолчанию идёт. Не удалось такую потом найти.
Это MacBook Pro 13 с процессором М1, которым я пользуюсь последние месяцы. Возможно вы заметили, что я перешел на него с Windows. И это должен был быть опыт использования, но дело обстоит куда серьезнее…
Сегодня я поделюсь опытом использования устройства. Мы поговорим о проблемах устройства и багах Mac OS, совместимости приложений с чипом М1. Ну и конечно поговорим о разнице подходов Windows и Mac OS.
И главное: получилось ли сделать ноутбук мечты или надо еще подождать?
Первое, что меня удивило — тут нет сброса ситемы. Нет одной кнопочки «Стереть все» и настроить ноутбук с нуля, как можно сделать на любом смартфоне. Даже на Windows есть. Что бы вы думали — Apple предлагает на сайте инструкцию из семи пунктов! Apple: 7 пунктов.
Проблема ожиданий
Поговорим о пробеме ожиданий. Постраюсь объяснить проблему. Конкуренция среди мобильных устройств — смартфонов — нас избаловала. Они каждый месяц все быстрее, плавнее, лучше камеры и куча форм-факторов.
И вот Apple выпускает как бы ноутбук здорового человека: с хорошим ARM-чипом и чистой операционкой. В чем подвох?
Как последовательный пользователь Windows, я знаю ее проблемы…
Переходя с Windows я думал, что это ОС для компьютера здорового человека. Apple позиционирует Mac OS Big Sur как операционную систему — какой она должна быть в 2020 году. В 2021 году нас ждет обновление и система будет называться Mac OS Monterey.
Поэтому с одной стороны ждешь, что система будет современной и не такой архаичной как Windows. Спойлер — нет. С другой стороны есть очень успешный опыт использования iPad с его собственно iPad OS: плавная система, где нет ничего лишнего. И ждешь перенос этого подхода на MacBook. И этого тоже не произошло. Как минимум, пока.
Но оказалось, Mac OS во многом тащит за собой старые скелеты. Например, тут странные интрефейсы настроек, например. Wi Fi.
Скелеты в шкафу
Есть несколько вещей, которые меня шокировали. Если вы опытный пользователь Mac, то вас будет бомбить от моих замечаний.
Mac OS с одной стороны пытается идти в сторону iOS: тут симпатичные анимации, меню приложений такое же. Но если приглядеться:
Нет единого стиля иконок. Все из разных эпох: где-то еще торчит скевоморфизм времен Скотта Форстала, который кстати покинул компанию в 2012 году. Это то ли переход, то ли попытка усидеть на двух стульях сразу.
Или вот еще. Как удивительно устроена установка стороннего софта с сайтов: сначала ты скачиваешь файл установки, а затем его надо перетащить на область с приложениями. Но самое удивительное, что все разработчики визуально это реализуют по-своему. И это выглядит колхозно.
Ну и еще попадаются мелочи типа того, что нет удобного сброса системы. Об этом мы сказали выше…
Удивление
Вторая часть моих удивлений связана с тем, как устроена Mac OS по сравнению с Windows. Принято считать, что Mac OS — это такая понятная интуитивная система. На самом деле — нифига. Интуитивными системами сейчас стали мобильные — iOS и Android. В них само все понятно.
Mac OS же очень приятная за счет плавных и остроумных анимаций, которые не фризятся. Но что касается структуры: местами она абсолютно алогичная.
Есть расхожее мнение, что Mac — это удобней чем Windows. Мне кажется, это не так. Это просто по-другому.
В Mac OS, как и конечно в Windowsпоначалу очень обо многое спотыкаешься. И дело не просто в том, что непривычно, а потому что реализовано странно. Контринтуитивно.
Начиная с простых вещей, которые в основном можно поменять в настройках, типа раскладки: когда для ввода точки надо нажимать комбинацию клавиш: Shift+7, что нелогично потому что точка — это очень частый символ. Или инвертированная прокрутка на колесике мыши: чтобы её поменять надо ставить фирменное приложение или утилиту.
Но у меня есть вопросы на уровне концепции операционки. Например, что такое запущенное приложение. Mac OS считает, что приложение может быть запущенным даже если у него не открыто ни одно окно. В доке такое приложение отмечается точечкой. Зачем это? То есть может быть ситуация, что видишь на экране окно одного приложения, но как бы активным является другое — об этом сообщает только верхнее меню. Контринтуитивно.
Даже отдельные шорткаты придумали для закрытия окон и приложения целиком. Command+Q — если вам интересно.
Например, неинтуитивно сделано расширение в полный экран. Двойной тап не всегда открывает окно во весь экран. Это странно — зачем мне смотреть на торчащий хлам других приложений, если хочу сконцентрироваться на этом. Второй вариант — когда приложение создает отдельный рабочий стол. Тоже не очень удобно, когда одновременно работаешь более чем в двух приложениях. Кстати, такое окно нельзя сразу свернуть…
Разделение экрана тоже реализовано неудобно. И лучше поставить отдельную утилиту, которая делает его нормальным.
Нет жеста переключения между программами как на iPad или даже на Windows — свайпом. Для переключения надо сделать два действия: перейти в режим Mission Control и выбрать новое приложение.
Третья секция — свернутые окна. Причем у вас будет отображаться и свернутое окно, и иконка приложения. Вот например Finder. Если закрываешь окно, приложение не закрывается. Эти понятия тут разделены. И я не нашел сильных доводов, зачем нужно такое решение. Контринтуитивное.
Многие их этих вещей можно настроить. Но по умолчанию они именно такие. Контринтуитивные.
Это компенсируется: Мне кажется Mac любят за плавность и няшность.
Глюки
Всплывающее окно VPN не пропадало даже после удаления программы и перезагрузки.
А еще среди глюков я заметил, что иногда клавиатура не переключается.
Совместимость
Вставляю SD-карту после съемки, файлы копируются и вдруг ошибка посреди. Не сказано, что формат не подходит. Все выглядит так — будто работает, но не работает полноценно. Возможно дело в файловой системе карты — ExFat. Хотя Apple вроде как с ней дружит. И получается если я профессионально занимаюсь фото или видео, у меня есть разные устройства, надо постоянно держать в голове — какая файловая система будет глючить на MacBook.
Железо
Тачбар — это весьма бесполезная штука. Для настройки яркости надо сделать два клика или свайп вместо нажатия кнопки.
Отличительной особенностью MacBook Pro на М1 от MacBook Air является наличие кулера. И его не замечаешь, потому что он не включается. Хотя не всегда, об этом позже.
А еще из-за нового процессора не поддерживаются внешние видеокарты.
Thunderbolt 4 здесь поддерживают скорость до 10 Гбит/с, что в четыре раза ниже истинного Thunderbolt 4 от Intel, то есть по сути перед нами USB 3.1.
И в целом портов конечно не хватает. Подключать монитор надо через переходник, а если еще жесткий диск или SSD подрубил, а он понадобится потому что памяти маловато. В этом случае заряжать ноутбук будет нечем. Ну какой же это MAcBook Pro?
Спецификации
В минимальной комплектации за 130 тысяч рублей мы получаем твердотельный накопитель на 256 ГБ. Серьезно? 512 ГБ стоят уже 150 тысяч рублей, а 1 ТБ памяти обойдётся в 200 тысяч рублей.
Фронтальная камера жуткая по качеству, её разрешение составляет 720p. Но с микрофонов звук хороший. Как впрочем и из встроенных динамиков.
Возможным минусом для такого довольно мобильного решения я бы назвал отсутствие SIM-карты. Согласитесь, было бы удобно вставить сюда симку с интернет-тарифом и работать где угодно!
Экран
Дисплей хороший, но он почему-то постоянно уменьшает яркость. Я даже отключил настройку автояркости и это продолжилось.
А еще тут нет поддержки 120 Гц, хотя в iPad Pro, который дешевле, есть. И поверьте — это совсем другой опыт!
Рамки вокруг экрана довольно большие, по сути, корпус устройства вообще не поменялся — а мог бы.
Ну и вишенка на торте — Apple M1 поддерживает подключение лишь одного внешнего монитора.
Софт
С софтом от Apple проблем особо нет. А неоптимизированные приложения по-прежнему не всегда запускаются быстро. Например, Evernote.
Говорят, кстати, что Windows уже запускается через Parallels, но вроде бы все еще не идеально
Докер последний раз, когда пытался запустить тоже выдавал ошибку.
Судя по обзорам, Android Studio работает не слишком шустро кроме эмулятора, которая требует виртуализации под интел.
Непереведенный на М1 профессиональный софт типа Adobe Premiere Pro работает, но неидеально. Иногда Mac даже просит закрыть другие приложения, так как ему не хватает памяти.
Приложения под iOS — от них особого толку нет. Большинство полезных — типа YouTube — нет в магазине. А во-вторых они просто не адаптированы под такой большой и несенсорный экран.
Ожидание от iPadOS. Ты привыкаешь к удобным приложениям. Например, YouTube на iPad — это лучший опыт. Тут же используется браузер, а смотреть YouTube в браузере — так себе удовольствие.
К тому же непонятно, что с играми! Counter Strike: Global Offensive все еще не запускается! DOTA нормально работает. Но в остальном, из игр только Apple Arcade, хотя тоже не все переведены на М1.
Производительность
Уже была куча бенчмарков и тестов. Он действительно рендерит видео быстрее, чем предыдущие MacBook Pro. Если говорить о Windows, то по этому параметру он сопоставим или даже быстрей, чем ноутбук за 200 тысяч рублей.
При этом, именно при рендере, я впервые заметил работу кулера!
Удобство
Теперь поговорим о хорошем.
Тут есть клевый поиск.
Есть просто и быстрое наведение порядка на рабочем столое — так называемые стопки.
ЗА что можно ценить Mac OS, так это за быстрый предпросмотр файлов
Также нельзя не отметить AirDrop — это конечно топчик. Если снял какое-то видео на iPhone, то скинуть его на MacBook можно очень быстро. Но есть один нюанс — я больше хожу с Android.
Тут есть много горячих клавиш, фишечек, лайфхаков и настроек.
Но главное — время жизни. Оно тут отличное. Без но тут не обошлось: батарейка садится в пассивном режиме — иногда не пользуешься компьютером несколько дней, кидаешь в сумку, открываешь — а там 50 или 30 процентов.
Приятно отметить, что тут нет возни с режимами питания: экономичный производительный. Он просто работает.
Итоги
Чисто логически: Apple — это компания, которая очень точно пытается соотносить железо устройства с софтом и внутренними компонентами. И здесь мы увидели что? В корпуса уже давно вышедших устройств вставили новый чип, который принципиально другой и по внутренней структуре и по тому, как память и охлаждение устроено. А его вставили в старый корпус.
Логично предположить, что перед нами переходное устройство. И в этом или следующем году мы увидим Mac и MacBook, которые уже полностью заточены под М1.
Вывод, на самом деле, простой — это классное устройство. Но не идеальное…
Вот часто смотришь на характеристики десктопных и ноутбучных процессоров и впадаешь в ступор. Вроде бы характеристики у них очень похожи: одинаковое количество ядер, почти одинаковые частоты и вроде бы похожая производительность.
Но на деле всё совсем не так. Поэтому сегодня постараемся разобраться в путанице и ответим на самый главный вопрос. Чем же всё-таки отличаются ноутбучные процессоры от десктопных.
Архитектура
Что вообще такое центральный процессор? Это очень сложное устройство, которое состоит из множества компонентов, каждый из которых отвечает за свой круг задач.
Ядра, кэш память, блоки ввода/вывода информации, дополнительные сопроцессоры, типа нейронного или сигнального, блок кодирования-декодирования разных кодеков и так далее. Компонентов очень много и все они должны идеально взаимодействовать друг с другом.
Поэтому каждый из производителей в поисках идеала, с каждым новом поколением процессоров меняет характеристики компонентов, их компоновку и так далее, совершенствуя формулу взаимодействия компонентов. И называется это всё архитектурой. Например, архитектура Zen, которая используется в процессорах AMD Ryzen.
Небольшая ремарка, еще существует понятие микроархитектура. В чем разница? Если архитектура — это просто свод правил, то микроархитектура — это ее физическое воплощение на кристалле. То есть все процессоры Ryzen работают на одной одной архитектуре Zen, но при этом каждое новое поколение работает на новой микроархитектуре: Zen 1, Zen 2, Zen 3. Но чтобы не усложнять, в этом материале я буду всё называть архитектурой.
С одной стороны, архитектура — это строгий и очень подробный свод правил, который объясняет как именно должен работать процессор.
С другой стороны, одно из важнейших требований к современным архитектурам — это способность масштабироваться. Хорошая архитектура позволяет работать с процессорами как с конструктором, добавляя и убирая элементы, чтобы собирать совершенно разные конфигурации под разные требования.
Для десктопных процессоров основное требование — это высокая производительность, высокие тактовые частоты, поддержка большого количества ядер, возможность оверклокинга и прочие радости ПК-бояр.
Например, десктопные AMD Ryzen могут масштабироваться до 64 ядер. Но естественно такие процессоры занимают много места, жрут много энергии и сильно греются. Соответственно, для ноутбучных процессоров требования совершенно другие. Какие же это требования?
Бюджеты
В процессорах для ноутбуков всё упирается в ряд ограничений. Поэтому одно из ключевых понятий для ноутбучных процессоров — это бюджет. Хотя речь тут не про деньги, но и про них тоже: имеются в виду несколько иного рода бюджеты. Главные из них — два.
Первый — это кремниевый бюджет. Процессоры для ноутбуков должны быть компактными, потому как в ноутбуках тупо мало место. Поэтому в мобильных процессорах нужно умудриться разместить все необходимые компоненты на меньшем по площади куске кремния.
Кстати, именно из-за экономии места, ноутбучные процессоры распаиваются прямо на материнской плате и их нельзя заменить (в отличие от десктопных процессоров, которые спокойно вставляются в специальный сокет). Такой тип установки называется BGA, что расшифровывается как Ball grid array — массив шариков. А всё потому что BGA выводы на материнской плате выглядят как массив шариков из припоя.
Также для ноутбуков и особенно ультрабуков важно наличие встроенной графики на одном кристалле с центральным процессором. Поэтому чаще всего мобильные процессоры являются гибридными, то есть содержат в себе и графический, и центральный процессор. AMD такие процессоры называет APU — accelerated processor unit.
В десктопах APU встречается гораздо реже, но иногда выпускаются небольшими партиями специально для компактных сборок. У AMD это процессоры серии G. И конечно же XBOX и PlayStation работают на APU.
А десктопные процессоры, могут наоборот располагаться сразу на нескольких кусках кремния. Например, классическая компоновка для процессоров Ryzen — это один большой чип с блоком ввода-вывода и один или два так назваемых чиплета, на каждом из которых расположено по 8 ядер.
И это всё мы говорили про кремниевый бюджет. Но естественно, это не основное ограничение для ноутбучных процессоров.
Ключевой момент в доступном термальном и электрическом бюджетах. То есть в нагреве и доступной для потребления электроэнергии. И это второй важный вид бюджета.
Чаще всего оба этих требования выражаются в одной единственной аббревиатуре и это TDP или thermal design power, что переводится на русский как конструктивные требования по теплоотводу. Этот параметр измеряется в Вт тепла. Он указывает на отвод какой тепловой мощности должна быть рассчитана система охлаждения ноутбука или ПК, чтобы процессор мог нормально работать. Естественно в ноутбук нельзя установить такую же мощную систему охлаждения, как и в большую рабочую станцию.
Например, 64-ядерный AMD Ryzen Threadripper 3990X расчитан на отвод 280 Вт тепла. А 8-ядерный процессор Ryzen 7 4700U для тонких профессиональных ноутбуков готов довольствоваться теплоотводом в 10-25 Вт. Как видите, разница более чем десятикратная.
Также в ноутбуках есть еще ограничение на общее энергопотребление. Например, ноутбук с довольно мощной дискретной графикой будет потреблять больше энергии, чем может выдать встроенный в ноутбук аккумулятор. В связи с этим такие ноутбуки будут работать на полную мощность только при подключении к электросети.
Итого, несмотря на то, что многие мобильные процессоры на бумаге могут выглядеть очень похоже на десктопные: они могут иметь тоже количество ядер, быть построены на той же архитектуре и даже работать примерно на той же тактовой частоте. Всё равно процессоры для ноутбуков и ПК сильно отличаются в силу того, что они сконфигурированы под работу в совершенно разных условиях.
Думаю, мысль простая и понятная, но на практике всё куда сложнее, чем в теории. Поэтому давайте попробуем сравнить максимально похожие процессоры для ноутбуков и ПК, и поймем в чем там конкретно разница.
Практика
Итак, наши кандидаты для сравнения. В качестве ноутбучного представителя у меня есть ASUS VivoBook S15 с процессором AMD Ryzen 7 4700U. Сравнивать мы его будем с AMD Ryzen 7 PRO 3700. И сразу видим некоторые сложности с именованием. Почему это мы сравниваем 4000-серию в мобильных процессоров с 3000-й десктопной?
Дело в том, что в последние годы AMD, при переходе на новую архитектуру, сначала выпускает десктопные процессоры, а потом на следующий год мобильные. К примеру, десктопные процессоры Ryzen 3000 серии на архитектуре Zen 2 вышли летом-осенью 2019-го. А мобильные процессоры на той же архитектуре Zen 2 вышли позже зимой 2020-го и уже были 4000 серии, хотя по сути десктопные 3000-ки и мобильные 4000-ки — это одно поколение. Такая же логика справедлива и для следующих поколений на архитектуре Zen 3.
Более того, мобильные и десктопные процессоры отличаются сериями. У мобильных процессоров бывает U-серия. Это процессоры для быстрых ультрабуков с TDP районе 15 Вт. И H-серия для ноутбуков.
Думаю, разобрались. Чем же отличаются эти процессоры? По сути, кроме архитектуры Zen 2 и количества ядер — всем!
У мобильного процессора TDP -15 Вт, а у десктопа — 65 Вт
У мобильного — 8 МБ кэш памяти, а у десктопа — 32 МБ
У мобильного процессора есть встроенная графика, у десктопа — нет. И так далее…
У десктопа в 4 раза больше транзисторов. Но при этом у процессоров по тестам одинаковая одноядерная производительность, а многопоточная уже отличается вдвое. Что крайне важно для профессиональных ресурсоемких задач: рендеринг 3D-видео, серьёзная цветокоррекция, различные математические симуляции. Ну и в играх тоже немного полезно, но не сильно.
Но главное тут даже не сколько попугаев выбивает процессор, а как долго он сможет держать максимальную производительность. И в этом плане десктопы с серьезными системами охлаждения вне конкуренции.
PROCESSOR
AMD RYZEN 7 4700U
AMD RYZEN 7 PRO 3700
Microarchitecture
Zen 2
Zen 2
Transistors
4,940,000,000
19,200,000,000
Cores / Threads
8/16
8/16
Base frequency
2.0 GHz
3.6 GHz
Turbo frequency
4.1 GHz
4.4 GHz
Cache memory
8 MB
32 MB
Max memory capacity
32 GB
128 GB
Memory types
DDR4-3200
DDR4-3200
Max # of memory channels
4
2
Max memory bandwidth
68.27 GB/s
47.68 GB/s
TDP
15 W
65 W
GPU integrated graphics
AMD Radeon Graphics 448SP
None
Maximum temperature
105°C
95°C
CPU-Z single thread
485
486
CPU-Z multi thread
2411
5308
PassMark single thread
2554
2670
PassMark CPU Mark
13726
22559
Но все же. Важно, что каждый из этих процессов хорошо справляется своей задачей. При этом нельзя не отметить, что в последние годы мобильные процессоры настолько подросли по производительности, что стали справляться с огромным рядом профессиональных задач. И сейчас даже тонкого ноутбука достаточно почти для всего, даже для монтажа.
Например, на ASUS VivoBook S15 в Adobe Premiere Pro я запустил 4К-проект фильма и он его совершенно спокойно прожевал.
