То, что ChatGPT может автоматически генерировать что-то, что хотя бы на первый взгляд похоже на написанный человеком текст, удивительно и неожиданно. Но как он это делает? И почему это работает? Цель этой статьи - дать приблизительное описание того, что происходит внутри ChatGPT, а затем исследовать, почему он может так хорошо справляться с созданием более-менее осмысленного текста. С самого начала я должен сказать, что собираюсь сосредоточиться на общей картине происходящего, и хотя я упомяну некоторые инженерные детали, но не буду глубоко в них вникать. (Примеры в статье применимы как к другим современным "большим языковым моделям" (LLM), так и к ChatGPT).

Привет! Меня зовут Тимур, я занимаюсь Android-разработкой в KTS.

Почему ещё не все используют режим edge2edge? Разве для того я покупал огромный безрамочный телефон, чтобы смотреть на траурные черные полоски с кнопками?!

К сожалению, сейчас все еще встречаются Android-приложения, которые не поддерживают edge-to-edge. Складывается ощущение, что разработчики либо не знают об insets, либо просто не умеют их готовить. На самом деле реализовать edge-to-edge не сложно, а благодаря этой статье вы сможете разобраться с insets в разы быстрее.

Сегодня я надену специальный мобильный фартук и расскажу, что такое режим edge-to-edge в мобильных приложениях и как работать с insets в Android. А ещё мы разберём примеры обработки insets не только во view, но и в compose. Если статьи о работе с insets в view еще можно найти на просторах интернета, то информацию про работу с ними в compose можно найти только в официальной документации.

Я расскажу в этой статье о Kotlin Symbol Processing, также известном как KSP.

Сначала обсудим теоретические основы работы KSP, после, конечно же, перейдём к практике. На примере небольшой задачи, подобной той, что мы решаем с помощью KSP в нашей компании, покажу, как анализировать код с помощью KSP, генерировать файлы, соблюдать контракты, описанные разработчиками KSP. 

Я работаю техническим писателем в компании documentat.io. Мы занимаемся заказной разработкой технической документации, в том числе на английском языке. Иногда я дорабатываю уже существующие документы или спецификации к API на английском. Как правило, такие документы написаны русскоязычными разработчиками, которые неплохо владеют английским. И всё же они часто допускают характерные грамматические, пунктуационные и стилистические ошибки.

Корень этих ошибок один — разные языковые механизмы. Нам бывает легко запутаться в употреблении временных форм, порядке слов или непонятно зачем придуманных артиклях. 

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

В статье, перевод которой предложен ниже, Роберт Мартин вроде как начинает с мыслей, очень похожих на те, что можно увидеть в рассуждениях Егора Бугаенко про ORM, но выводы делает другие. Лично мне подход Егора импонирует, но я считаю, что Мартин подробнее раскрывает тему. Мне кажется, с его мнением стоит познакомиться всем, кто когда-либо задумывался о том, какое место должен занимать ORM и вообще, зачем нужны объекты у которых все поля открыты. Статья написана в жанре "Диалог", где более опытный программист обсуждает проблему с тем, у кого опыта меньше.

Что такое класс

Класс это спецификация множества сходных объектов

Что такое объект?

Объект это набор функций которые производят действия с инкапсулированными данными.

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

В смысле "подразумевается"?

С вашим языком программирования все в порядке — он просто производит вычисления с плавающей запятой. Изначально компьютеры могут хранить только целые числа, так что им нужен какой-то способ представления десятичных чисел. Это представление не совсем точное. Именно поэтому, чаще всего, 0.1 + 0.2 != 0.3.

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

Предлагаем хабрасообществу наш перевод этого материала. Обращаем ваше внимание, что позиция автора не всегда может совпадать с мнением МойОфис.

Всем привет! Наверняка каждый Android-разработчик хоть раз сталкивался с проблемой скорости сборки своего проекта. После нехороших слов в адрес кодогенерации, покупок более мощного железа, многочисленных попыток распилить проект на небольшие параллельно собираемые модули и прохождений всех стадий торга мы продолжаем искать решение этой проблемы. К счастью, за годы развития и в Gradle, и Android Gradle Plugin (AGP) появилось много полезных штук для ускорения сборки, о которых я расскажу дальше.

Несмотря на шутку в адрес многомодульности, это действительно полезный подход, но для большого проекта с богатой историей модуляризация может быть очень сложным процессом. Поэтому пока давайте посмотрим, что можно сделать без больших болей на уровне Gradle и AGP.

Я расскажу на примере мобильного Яндекс Браузера. У нас было ~150 Gradle-модулей, ~2 млн LoC на Java/Kotlin, десяток Gradle-плагинов, тысячи строк кода в buildSrc и лёгкая дрожь от вопроса, сколько ещё может переварить билд-система. Не скажу, что это всё было категорически необходимо, но к написанным строчкам кода надо проявлять уважение.

Системный косяк в восприятии времен

Все мы учились в школе. Плохо ли, хорошо ли — учили грамматику. Попробую обобщить простыми словами то, как воспринимаются «времена» через школьный фильтр.

«Времена» — это такие «виды» действия. Надо взять действие, про которое хочешь сказать и понять, к какому «виду» оно относится. Тогда и «время» выберешь правильно. 

Звучит очень логично. А что? Находишь соответствие правилу и дело в шляпе. Здесь вполне естественным кажется вопрос «А какую конструкцию мне лучше употребить?»

Скрипты на Bash. Как много в этом слове. Любому разработчику рано или поздно приходится их писать. Почти никто не скажет "да, я люблю писать bash-скрипты", и поэтому этой теме уделяют мало внимания.

Я не буду пытаться сделать из вас эксперта в Bash, а просто покажу минимальный шаблон, который поможет сделать ваши скрипты более надежными и безопасными.

Когда вы автоматизируете какую-либо задачу, например, упаковываете свое приложение для Docker, то часто сталкиваетесь с написанием shell-скриптов. У вас может быть bash-скрипт для управления процессом упаковки и другой скрипт в качестве точки входа в контейнер. По мере возрастающей сложности при упаковке меняется и ваш shell-скрипт.

Все работает хорошо.

И вот однажды shell-скрипт совершает что-то совсем неправильное.

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

Сравним Kotlin-Flow и ViewModel в Android приложении, посмотрим в чем отличия и узнаем сильные стороны каждого подхода.

Всем привет! Меня зовут Паша Стрельченко, и я — Android-разработчик в hh.ru. В этой статье расскажу об укрощении feature-флагов. Если больше нравится аудиовизуальный формат, его можно найти на нашем youtube-канале. В статье я расскажу чуть больше технических подробностей, чем в видео, так что должно получиться интересно.

Рассказываю, почему SQLite отлично подойдет вам в повседневной работе. И неважно, разработчик вы, аналитик, тестировщик, админ или продакт-менеджер.

Привет! Меня зовут Сергей Иванов, я ведущий разработчик Android в Redmadrobot. С 2016 использую автотесты различных категорий и успел в этом набить немало шишек. Именно поэтому решил поделиться опытом. Возможно, кому-то статья поможет систематизировать знания или начать применять эту практику в работе. 

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