Тут со дна АйТи индустрии постучались.

Если серьезно, то новости для отрасли удручающие —в технологических и АйТи стартапах в Q2 этого года начались массовые кадровые сокращения АйТи специалистов.

До ковидных уровней пока еще не дотягиваем, но согласись — выстраивающаяся тенденция печальна. В общем, буду присматривать за развитием событий и иногда освещать эту тему. ✌️

👉 В общем, после поста про порог входа в АйТи, возникла серия вопросов, поэтому я чуть детальнее раскрою свою мысль и отношение к этой серьезной, как я считаю, теме.

Проблема в том, что все самые хитрожопые АйТи компании нихренашеньки не хотят заниматься развитием и воспитанием своих собственных кадров. Их цель, как самых настоящих паразитов — перехантить уже опытного специалиста различными плюшками: вот мы тебе печенек насыпали, вот у нас зарплатка повыше, вот тебе стоматология халявная, а еще у нас вот есть PS5 в лаундже и так далее...

Ну можете сами прикинуть, сколько времени уходит на развитие кадра с уровня Trainee/Junior до Senior. То, что этот кадр возможно был чьей-то долгосрочной инвестицией, в которого вкладывались деньги и сотни человеко-часов, паразитов обычно мало волнует.

А потом все работает, как в том меме про круговорот девелопера в финтехе или ты серьезно думаешь, что дефицит специалистов уровня Senior на ровном месте появился?✌️

👉 Далее, если кто-то думает что нужно обязательно взять человечка за руку и провести его через весь тернистый путь к "успешному успеху" в индустрии это единственный возможный путь — то нет, это не так. На порог входа в АйТи и дальнейшее развитие специалиста влияет множество факторов.

🔹Качество и доступность обучающих материалов. Вот этого у нас в достатке, пожалуйста выбирай сам: "Бесплатно, Некачественно, Быстро", "Бесплатно, Качественно, Долго", "Платно, Качественно, Быстро", и так далее...Ну камон, у нас ВУЗы, есть множество платных курсов, есть халявный доступ к CS50, есть множество энтузиастов на YouTube, бери да изучай.

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

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

Это я к тому, что всегда есть условные "бутылочные горлышки", где можно упростить и оптимизировать процессы, тем самым снижая требования к кадрам. Да, сейчас это может и не так заметно, но такая тенденция есть.

...в очередной раз Rust признаётся самым любимым языком в ежегодном опросе StackOverflow.

Так, у меня встал вопрос - я действительно чего-то не знаю про rust или просто у ржавых это такой ежегодный способ аутофелляции?

Эксперты, поясните в комментах 👇

Организация Software Freedom Conservancy призвала прекратить использование GitHub открытыми проектами 😂👍

А всё из-за замеса с Copilot, якобы мелкомягкие натренировали свой Skynet на коде из публичных репозиториев, без учёта типа лицензии проекта.

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

Вот такие дела.

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

Короче, для тех кто не в теме, GTK - это такая, грубо говоря, библиотека для построения пользовательский интерфейсов в среде рабочего окружения Gnome. Так вот, решил я значит года полтора назад по приколу вкатиться в Desktop разработку под Linux, чисто пощупать как оно там. Узнать, так сказать, врага в лицо и наконец-то понять почему большинство нативных Linux приложений такие ВСРАТЫЕ. Особенно с учетом того, что у меня раньше был опыт работы с WinForms/WPF, поэтому челлендж оказался интересным.

Вот когда я иронизирую в своих видео про ООП, то я частенько использую для этих целей язык C, чистый C, без всяких ++. Так вот, библиотека GTK - это библиотека написанная на чистом C с использованием объектно-ориентированного подхода. Смекаешь?

Разработка на GTK в чистом виде, без использования сторонних средств выглядит как АД. Инструмент как будто реально лет на 30 устарел (сразу с момента релиза, как минимум).

Не то, чтобы я неосилятор, но просто я словил вайб Hello World приложения на windows api (+- 500 строк кода, для такой простой задачки). Весь процесс построения интерфейсов непомерно раздут, и я очень сомневаюсь что в таком виде можно построить какой-то серьезный UI.

Соответственно, после этого провала, я начал искать другие способы работы с GTK. Ииии....Красноглазики небыли бы красноглазиками, если бы не представили миру такой язык программирования как Vala. Язык выглядит так, будто из C# решили сделать C++.

И самое главное - это ЯП который был СПЕЦИАЛЬНО создан для работы с GTK в объектно-ориентированном виде. В чем же мякотка? Да в том, что при компиляции Vala код транслируется в C+GTK код, а затем уже при помощи GCC компилируется в нативное приложение. Работает оно, если что, так же всрато, как и читается.

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

И собственно вот, мой тебе совет, если ты планируешь вкатываться в Desktop разработку под Linux, то пожалуйста, выбирай что угодно, но не GTK. Даже Electron будет лучшим выбором.

P.S.
Ну и конечно же...Press 💩 for Linux

Кстати, стихийно тут вспомнил о своём старом мемном видосе про Жака Фреско и ООП (18+)

И я короче, сижу сейчас и думаю: а правда - кто вообще решил что кнопка это объект и ООП парадигма идеально годится для создания UI? 😂

Просто начинаю вспоминать:
- WPF + XAML
- Qt + QML
- Java + XML (вроде?)
- HTML в конце-то концов

Везде используются специальные языки разметки для вёрстки пользовательских интерфейсов. И это я еще не гуглил специально, чисто по памяти составил список. Уверен что его можно продолжить.

Да, конечно можно предъявить меломягким что у них похожее в Windows Forms есть, но так извините блин, Шиндовс Формы после 2005-го года (год когда появился WPF) по сути то и не развиваются никак!

Эх линуксятники, МОЛОДЫЕ ЛИНУКСЯТНИКИ, что ж вы не бережёте-то себя, миленькие 🥲

🧼 АйТи пузырь ВСЁ.

Как и обещал в начале недели -> заресёрчил тему массовых сокращений в индустрии за кордоном.

Собственно, есть несколько трекеров, которые отслеживают и сообщают об активности сокращений кадров в Tech и IT компаниях. Так вот, по оценкам консервативного трекера layoffs.fyi за 2022-ой год было сокращено около 48,500 сотрудников компаний, а по оценке чуть более агрессивного в своей аналитике трекера trueup.io - 68,000 кадров! (sic)

На ожидании мировой рецессии, внезапно оказывается, что инвестиции от венчурных и пенсионных фондов в рисковые активы сокращаются прямо на глазах - это особенно сказывается на стартапах, которые проходят только первые раунды инвестиций и не в состоянии получить быструю прибыль. И это при том, что факт рецессии еще не случился! (sic x2).

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

Более того, ужимаются даже крупные и состоявшиеся техи - в Tesla например полностью сократили команду в Калифорнийском офисе, которая занималась автопилотом и вообще, рассматривают до 10% сокращения кадров повсюду. Это как по мне вообще странный движ, особенно с учетом факта, что таких сотрудников на рынке труда мало и грубо-говоря найти специалистов в этой отрасли проблематично.

В итоге, исходя из всей информации, я ДОПУСКАЮ, что дальше может быть хуже и дно еще не пробито. Короче, продолжаем мониторить ситуацию 😤

🧐 Если вдруг кто захотел МОНИТОРИТЬ СИТУАЦИЮ самостоятельно - могу порекомендовать для просмотра список компаний из биржевого индекса Nasdaq 100.

В нём присутствует 100 крупнейших технологических компаний мира, в том числе из АйТи сектора, можно присматривать за новостным фоном складывающимся вокруг них. Так что, будем мониторить вместе. 👀

P.S.
Биток коррелирует на ~0.8 с этим индексом (или это индекс ходит за битком? :D), так что можно попробовать научиться предсказывать курс первого криптозащекойна.

📄 Материалы прошлой недели

🔹 Microsoft, .NET и бесполезные Языки Программирования

🔹 Unity Software + нейросети = 💔

🔹 Паразитирование на найме кадров в АйТи

🔹 Способы снижения порога входа в АйТи

🔹 GitHub Copilot против Open Source

🔹 Про разработку UI в Linux 💩

🔹 🧼 АйТи пузырь ВСЁ

Всем чиловых выходных 🥴

Начни свой день с IT KEKW NEWS™: В Южной Корее установили надгробие Internet Explorer.

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

Да и вообще у них там есть объективные проблемы с поддержкой разных браузеров: доходит до абсурда - для того, чтобы воспользоваться тем или иным сайтом нужно иметь правильную версию браузера, потому что некоторые госсайты не работают в Safari или Firefox.

Зато всё прекрасно работало в Internet Explorer, просто потому что в 00-ых он имел долю 99% из всех браузеров. Кстати, корейские специалисты уже нашли временный фикс после закрытия IE — нужно включать "режим совместимости с IE" в браузере Edge 🤡

ДА ЧТО ТАКОЕ ЭТА ВАША КРОССБРАУЗЕРНОСТЬ?

Safari это новый Internet Explorer? 😳

P.S.
Кстати, на тему эпловского JavaScriptCore у меня готовится ресёрч, скоро завезу тебе материал.

И вообще, думаю объявить эту неделю - неделей JavaScript, браузеров и их движков, так что можешь накидывать своих приколов и рабочих нюансов в комментариях 👇

Ну что малята, добро пожаловать в мир JavaScript движков — это будет длинное путешествие в конце которого мы придём к не однозначным, но интересным результатам 🤡

На данный момент существует только 2 основных решения:

🔹 v8 - разрабатывается Google, используется в Chromium-like браузерах (Chrome, Edge, ...тысячи их), а так же является важной частью рантайма nodejs

🔹 JavaScriptCore - разрабатывается Apple, является частью WebKit и используется во всех версиях Safari, а так же во всех iOS браузерах, включая Chrome. Если вдруг кто не знал, то теперь знай - в iOS версии браузера Chrome не используется v8.

JSC примечателен тем, что после перехода на процессоры M1 - движок реально полетел. Если посмотреть браузерные бенчмарк тесты, то по моим прикидкам прирост в производительности в сравнении с моей x86 версией Chrome составил 50-70% (тест ни разу не претендует на объективность, я просто заставил своих корешей-макодэбилов погонять бенчмарки).

В принципе можешь сам запустить бенч в браузере и закинуть свои результаты в комменты. Сравним, так сказать, у кого движок длиннее быстрее.

✌️IT KEKW NEWS™:
В набор компиляторов GCC была утверждена поддержка языка Rust.

👉 WebKit, как и JavaScriptCore в его составе — также является Open Source разработкой, поэтому его можно взять и прикрутить куда-нибудь, например к ПРИНЦИПИАЛЬНО новому JavaScript рантайму (но об этом чуть позже 😂).

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

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

Test       v8      JSC
Geo. mean  10.58   10.95

Цифры измеряются усредненным показателем "runs/s". Бенчмарк проводится фиксированное время - поэтому, чем этот показатель больше, тем лучше - полный результат здесь, там присутствует детальный отчёт.

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

Сама бенчмаркалка от Google лежит в этом репозитории.

И конечно же, по АБСОЛЮТНО ОБЪЕКТИВНЫМ РЕЗУЛЬТАТАМ вышло, что в одинаковых условиях на одной платформе
— JSC в среднем быстрее v8 на ~3.5% 🧐

⚡️⚡️BLAZING FAST⚡️⚡️

И тут собственно врывается новый рантайм для JavaScript под названием Bun.

Меня чудовищно возмутили заявления автора в Twitter, о том что Bun быстрее Node.js в 4.5x раза!!!, не менее чудовищно я возмутился с результатов бенчмарка на главной странице сайта - где в серверном рендеринге React приложения показан прирост производительности в 300%!!!

Поэтому я незамедлительно скачал эту адскую поделку и принялся ее бенчмаркать по полной программе.

Во время использования обратил внимание на следующие моменты:

1. Местный аналог NPM просто НЕВЕРОЯТНО быстр, мем про create-react-app скоро станет не актуальным и нам придется искать новую заставку под видосы.

2. Bun реально хорош, я проводил все тесты на Linux/amd64. Конечно не так быстро, как обещано - всего лишь 45-50% прирост в предоставленных бенчмарках в рендеринге SSR на моей машинке. Можно конечно возмутиться - где еще 250%? Но не всё сразу.

Тем не менее это ОТЛИЧНЫЙ результат, +50% к перформансу на ровном месте, это ли не чудо? 😳

ExtremeCode moment ✌️

👉 Почему так быстро?

В качестве причин, автор указывает 2 основных аргумента:
1. В качестве основы используется WebKit и JavaScriptCore
2. Из движка не вырезан Web API, поэтому сохраняется совместимость с браузерными API типа fetch

На основе fetch api кстати говоря и работает сервер в Bun.

И если несколько раньше я приводил Benchmark сравнение по результатам которых JSC не настолько быстрее, чем v8 в одинаковых условиях.

НО! Похоже именно реализация I/O, в частности Http + Web API даёт нам этот самый перформанс в серверном рендеринге - только за счёт сетевого взаимодействия от 50% до 300% но это не точно 🧐

Не стоит забывать, что чисто теоретически за счёт оптимизации WebKit под архитектуру M1 - именно Mac Os получит наибольший прирост в производительности, потому что условный Nodejs не имеет таких оптимизаций.

У Nodejs же еще вырезан Web API и в нём используется собственная реализация модуля Http. Видимо недостаточно быстрая, ну что поделать 🤖

👉 Начни свой день с IT KEKW NEWS™: Unity Software объявили о слиянии с ironSource за $4.4 млрд.

Почитал я, значит, комментарии об этой сделке на YCombinator и чуть не умер от кринжа 😑

ОКАЗЫВАЕТСЯ, что ironSource — печально известная компания, которая занимается распространением вредоносного ПО, типа malware, adware bundlers и приправлено всё это рассылочками спама: Пруф #1, Пруф #2.

Ранее я уже писал про сокращение сотрудников в Unity Software.

UPD: Почему это плохо? Если бы Unity Software полностью выкупила эту компанию, то вопросов бы ни у кого не возникло. Но это СЛИЯНИЕ двух крупных компаний, в результате которого акционеры ironSource получат примерно 26% акций Unity Software — дальше сами додумывайте, к чему это может привести.

Вычёркиваем?

🤡🤡 BLAZING SLOW 🤡🤡

Да ладно, вы и вправду подумали что я просто так это всё оставлю и не попытаюсь детально разобраться в чем же причина такой мега-скорости Bun?

В первую очередь мой острый взгляд пал на React - и в принципе я не прогадал: в марте вышло обновление 18.0 и в нём переделали Stream'ы для Nodejs в серверном рендеринге. Моментально я наткнулся на следующий Issue в github где чувак обратил внимание на то, что у него деградировал перформанс чуть ли не в 5 раз!

Почему это важно? Да всё просто - в Node используется своя версия реализации стриминга. В Deno используется другая реализация. А вот в Bun вообще нет официальной поддержки - авторы используют самопальный polyfill для стриминга отрендеренной страницы.

Поэтому, переписав код бенчмарка и заменив функцию renderToPipeableStream на renderToString результат Nodejs заметно улучшился и разрыв в среднем сократился уже до 25% — заметь, это не 300% разницы и даже не мои изначальные 45%, по результатам самых первых тестов.

Собственно продолжив копаться дальше, я обратил внимание на следующий момент: Bun с какой-то стати игнорирует Http заголовки которые указаны в бенчмарке — а Nodejs в свою очередь наоборот ДОБАВЛЯЕТ лишние заголовки. В итоге разница составляла в среднем: ~130 байт данных, которые приходилось гонять ноде.

Разбираться почему Bun игнорирует заголовки - я не стал, пусть этим разработчики занимаются. Я в свою очередь просто привел Nodejs к тем же самым условиям - важно чтобы заголовки совпадали по размеру, для чистоты эксперимента.

В итоге разрыв сократился до 18-20% в пользу Bun — это мой максимум. Я не использовал никаких кастомных Http серверов, для меня было важно использовать средства чистой Node.js

Более того, если из этих переменных выкинуть React SSR и оставить голые байтики - разрыв будет точно таким же. Я понятия не имею каким образом сетевой код у разработчика Bun вышел на столько производительней, но факт остаётся фактом — это 20% дополнительного перформанса только за счёт I/O.