Вообще, я люблю опенсорс - мой голосовой помощник Ирина тому подтверждение.

Тем не менее, в текстовых нейросетях пока опенсорс решений уровня GPT-4 нет - а пользоваться им при написании кода, честно говоря, правда полезно.

Если честно, меня несколько утомило решать вопросы доступа и оплаты OpenAI аккаунта, необходимого для доступа к GPT-4 и API (да, я провожу эксперименты, и API мне нужен).

Я бы с удовольствием поэкспериментировал и с другими сетями - например, Claude, о которой говорят гораздо меньше, но которая, по-видимому, не намного хуже (спойлер: я пробовал - по моему мнению, Claude 2 вполне на уровне GPT-4).

Постепенно реализовывая свои "хотелки", я создал сервис VseGPT.ru, который решает мои основные проблемы - предоставляет общий интерфейс в виде чата и OpenAI API к разным топовым нейросетям - ChatGPT, Claude, Google Palm и опенсорсным Llama 70b, 34b Code и пр.

Конечно, сервис я делал в основном под свои профессиональные потребности, так что давайте посмотрим, чего хотел я, и насколько это подойдёт вам:

Всем привет! Меня зовут Борис Вербицкий, и я представитель того редкого типа iOS разработчиков, которые тепло относятся к Kotlin Multiplatform Project и рады появлению Compose Multiplatform. Здесь я решил поделиться своим опытом использования этих технологий, а также кое-какими размышлениями вокруг процессов с такой разработкой. Цель этой статьи - это поднять обсуждение предложенного мной подхода, послушать все за и против в комментариях.

Приятного чтения!

Многие, возможно, думают, что работа с байт-кодом Java (будь то чтение или, тем более, генерация) — это какая-то особенная магия, доступная только продвинутым разработчикам с особенно крутым опытом. На самом деле, я считаю такую точку зрения ошибочной. JVM устроена гораздо проще, чем CPU; она оперирует такими высокоуровневыми понятиями как классы, интерфейсы, методы, а не просто лопатит байты в памяти. В отличие от CPU, который легко уронить криво сгенерированным машинным кодом, JVM заботливо отверифицирует любой байт-код и в общем не даст выстрелить в ногу.

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

Весь приведённый код доступен в моём репозитории.

Когда-то читал статью о выборе файловых систем «чтоб везде-везде работало». В ней в очередной раз увидел жалобы, что Ext4 замечательная файловая система, но на Windows есть только кривые неточные проприетарные драйверы. Но отмотаем ленту ещё на пару лет назад: тогда на Хабре (а в те времена — Гиктаймсе) пролетала новость про LibOS — попытку превратить Linux kernel в обычную библиотеку пользовательского режима. Упор там делался на вынос сетевого стека в user space. Как-то раз я решил поглядеть, а жив ли вообще проект, и в их блоге увидел ссылку на своего рода конкурента — проект Linux Kernel Library (LKL). По сути, это порт ядра, так сказать, на аппаратную архитектуру «библиотека пользовательского режима POSIX / Win32».

Чем интересна LKL? Во-первых тем, что она живёт и здравствует, пусть и не в основной кодовой базе ядра. Во-вторых, это более-менее честная поддержка «архитектуры», автоматически делающая доступной бОльшую часть ядра. Более того, прямо в комплекте идут утилиты-примеры: cptofs/cpfromfs, fs2tar, lklfuse. В этой статье мы протестируем LKL на хостовом Linux, заглянем в файл с образом Ext4 (Btrfs, XFS...) без рута и виртуалок и коротко обсудим, как её можно попробовать на Windows.

В этой статье не будет дежурных фраз про увеличение спектральной эффективности и уменьшение задержки (latency). Вместо этого я расскажу про развитие технологии OFDM-MIMO и о том, какие идеи двигали это развитие. При этом постараюсь обойтись без формул. Тем не менее, статья написана не совсем в духе “LTE для чайников”, но предполагает наличие у читателя базовых знаний по цифровой обработке сигналов, OFDM и MIMO. 

Примерно к 2005 году разработчикам сотовой связи стало понятно, что MIMO это практический, а не теоретический, путь повышения пропускной способности. Стоит пояснить, что на профессиональном жаргоне MIMO означает возможность передачи нескольких потоков, а не использование множества антенн для создания направленного излучения (beamforming) или использование пространственных свойств радиоканала для повышения надёжности (diversity). То, что MIMO повышает пропускную способность в теории, было известно задолго до 2005 года, но та же теория объясняет, что для этого необходимы, как минимум, два условия: высокое соотношение сигнал/шум и независимость (некоррелированность) каналов между различными парами передающая-приёмная антенна. Противники MIMO, а тогда таких было довольно много, утверждали, что в реальной жизни ни одно из этих условий выполнено не будет, сигнал/шум будет низкий поскольку передавать (или принимать) хотят все и сразу, а каналы будут сильно коррелированы, потому что антенны (на одном устройстве) находятся близко друг к другу. Однако апологеты MIMO, которые, к слову, ныне считаются отцами-основателями, всё больше и больше убеждались в обратном.

Вчера у меня в ленте на фейсбуке (жаль что в закрытом посте) проявился еще один аспект ChatGPT, жуть которого я не вполне осознавал. Представьте, что ваш менеджер присылает вам емейл: "я вот тут сгенерил с помощью ChatGPT код на языке описания аппаратуры SystemVerilog, который реализует мою идею, ты его поправь немного и в продакшн, а то нас сроки поджимают".

Почему это жутко? Потому что в обсуждаемом посте ChatGPT сгенерил так называемый несинтезируемый код. Это означает: код вроде и есть, и после массажирования даже будет компилироваться в симуляторе, но вот чип из него сделать нельзя. Никак, вообще никак. Для решения этой задачи нужно написать совсем другой код, у которого не будет ни одной строчки общего с тем, что прислал менеджер.

То есть менеджер думает, что вместе с ChatGPT сделал за вас 90% работы, а на самом деле.

Госуслуги уже давно не про запись на приём в ведомственные учреждения и не про единое окно (чтобы этот термин не значил) — мы расширяем горизонт и развиваем полноценную цифровую экосистему.  На этот раз перед нами стояла задача разработать решение для подписания документов с помощью мобильного приложения, которое получило название «Госключ».  

На связи команда проекта «Госключ» и директор проектов РТЛабс Константин Белов. Задачами, связанными с пилотированием новых процессов на региональных и даже федеральном уровнях, нас удивить сложно. Они — частый гость в наших офисах, но редко речь идет про мини-революцию и борьбу с «устоями».

Не секрет, что коронавирус заметно поменял все сферы жизни и бизнеса. И было бы странно, если бы пандемия не повлияла и на процесс подписания документов при помощи государственных сервисов.

Больше 700 NATов, около 1000 маршрутизаторов. Зачем это всё нужно, как это администрировать и какие профиты от такой организации сети. Спойлер: экономия в миллионы рублей при кратном росте надежности и простоты переездов.

Я работаю проектировщиком аппаратного блока графического процессора в телефонах Samsung, в рамках совместного проекта с AMD. Сейчас наш менеджмент расширяет команду и поощряет инженеров распостранять информацию о новых позициях среди своих знакомых. Я решил написать это пост для более широкой аудитории, так как множество людей, способных пройти интервью на RTL или DV позицию - больше, чем множество моих знакомых. Если вы сможете прислать мне ответ на задачку в моем посте вместе с вашим резюме, я перешлю его нанимающему менеджеру и рекрутеру нашей группы (в комментах прошу ответ не писать). Если резюме им понравится, вам нужно будет пройти стандартное собеседование на несколько часов, с несколькими инженерами, у каждого из которых свой набор задачек.

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

Всем привет!

Меня зовут Женя, и я люблю автотесты. Причем люблю так сильно, что даже стал соавтором Kaspresso, OpenSource библиотеки для написания автотестов под Android, и автором ряда докладов и статей про тесты (Kaspresso: фреймворк для автотестирования, который вы ждали, Автотесты на Android. Картина целиком, Kaspresso tutorials. Часть 1. Запуск первого теста, Дмитрий Мовчан, Евгений Мацюк — Как начать писать автотесты и не сойти с ума). Также со мной полюбил автотесты и мой товарищ, Сергей Ярцев, который является CTO в HintEd, и также вынужден трогать автотесты, причем под разные платформы.

В одной из своих статей (Автотесты на Android. Картина целиком) я описывал, что вообще в себя включают Автотесты под Android. Если кратко, то я выделял 4 большие области: Процесс написания автотестов, Runner, Инфраструктура и Остальное, которое включало в себя отчеты, интеграцию с CI/CD и тд. В свое время (2019-2020) когда мы делали Kaspresso, мы закрывали боль с написанием автотестов. Теперь разработчики и тестировщики могут писать красивый и понятный DSL и не думать про проблемы с флаканием, логами, скоростью и тд. По другим же областям были некоторые решения, но команды, выстраивающие весь процесс, должны были сами со всем этим разбираться и все это стыковать. Особенно больно было с Инфраструктурой, где приходится нырять в дивный мир DevOps и частично даже Highload.

Недавно мне стало интересно, а как сейчас обстоят дела у разных команд с автотестами. Для этого мы с Сергеем провели ряд интервью с более, чем 30 разными командами. Да, это далеко не вся выборка, и данное исследование точно не претендует на абсолютную истину. Но 30 больше, чем 1 или 2 или 5, и поэтому исследование точно может наводить на кое-какие мысли.

Термин “Resolution” фигурирует в трех популярных стандартах: IBM, EXIF, Google MD. В каждом из них «разрешение» трактуется по своему и обозначает совсем разные характеристики. Разбираемся с понятиями и в работе c дизайн материалами.

Maniac Mansion - это классическая приключенческая игра с интерфейсом point and click. Она вышла в конце 80х годов для платформ Commodore 64, Apple II, Atari ST, Amiga, IBM PC и NES. Популярный в наших краях ZX Spectrum этой игры не увидел.

Может быть дело в том, что графический режим ZX Spectrum поддерживает только два цвета на знакоместо. А может, потому что аппаратных спрайтов там не было (хотя в Apple II их не было тоже).

Пришло время исправить эту несправедливость и портировать Maniac Mansion на улучшенный ZX Spectrum - ZX Spectrum Next.

Это глава из «Книги нормального фрилансера», в которой я делюсь опытом проектировщика интерфейсов, работающего на себя.

Если кто-то недоволен, как ты делаешь работу,
Предлагает подучиться и исправить результат,
Это не некомпетентность! Ты с синдромом самозванца!
Ты уже и так всё знаешь, а клиент — он сам дурак!

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

Другими словами: человек объективно молодец, но себя таковым не считает и опасается разоблачения.

Чаще синдром самозванца можно встретить среди успешных людей, которые добились хороших результатов вопреки обстоятельствам. Столкнулся с ним и я. Но хотел бы начать с истории, которая показывает, как легко перепутать синдром самозванца и некомпетентность…

Продолжение рассказа про разработку pet-проекта о кафе и коворкингах на солнечном Кипре. "Рабочие места" для цифровых кочевников ヽ(。_°)ノ

В первой части я рассказал про REST API микросервис, теперь - про фронтэнд-сайт.