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

🔹Качество и доступность обучающих материалов. Вот этого у нас в достатке, пожалуйста выбирай сам: "Бесплатно, Некачественно, Быстро", "Бесплатно, Качественно, Долго", "Платно, Качественно, Быстро", и так далее...Ну камон, у нас ВУЗы, есть множество платных курсов, есть халявный доступ к 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.

👉 IT KEKW NEWS™:
CEO Unity Software Джон Ричителло (экс CEO Electronic Arts) в интервью заявил, что все разработчики, которые не планируют включать в свои проекты монетизацию, цитирую - "Ёбаные идиоты", источник.

👉 При этом не стоит забывать, что Bun АБСОЛЮТНО не готов к Production разработке.

В процессе тестов он постоянно падал с разными ошибками, то сервер начнёт код 500 сыпать, то с Segmentation Fault упадёт, то JS код скомпилировать не сможет. Стабильности здесь НЕТ.

Ещё Bun не смог запуститься на WSL, якобы ему ядро Linux не подошло, хотя моя версия ядра попадала под системные требования.

Короче, как по мне - шляпа подает надежды, как минимум она гораздо перспективнее того же Deno, но работы в Bun нужно сделать еще очень много.

К тому же, написана Bun на очень интересном языке программирования, который называется Zig (за шутки про зиги буду банить) - можешь посмотреть, прикольная штука!