Избавьтесь от YouTube Shorts в вашем браузере с помощью расширения Ublock Origin и ряда простых и незамысловатых шагов

В минувшем году все только и говорили об ИИ и о том, как он может всё за вас сделать.

Мне нравится, когда кто-то или что-то работает за меня. Поэтому решил: попрошу-ка ChatGPT написать за меня новогодний пост:

«Эй, ChatGPT. А ты можешь реализовать большую языковую модель на SQL?»
«Нет, SQL не подходит для реализации больших языковых моделей. Язык SQL предназначен для выполнения запросов к данным, хранящимся в РСУБД и для управления этими запросами. Для реализации большой языковой модели требуются сложные алгоритмы, обширные датасеты, а зачастую — и фреймворки для глубокого обучения. SQL всеми этими возможностями не обладает.»

Что ж, лишний раз убеждаешься, что, если хочешь что‑то сделать хорошо – сделай это сам.

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

Всем привет! Мы (Никита Звонилкин и Дмитрий Ёжиков) работаем в отделе локализации в SM Lab. Мы провели презентацию по теме интеграции локализации в процесс тестирования ПО на конференции SQA Days. Для этой статьи мы адаптировали эту презентацию, чтобы показать, чем локализация отличается от перевода. А ещё расскажем про основные этапы локализации, поговорим о подборе команды для проведения тестирования и о полезном софте.

Немного цифр. Спортмастер — большая компания, торговые сети представлены в 6 разных странах, а в 11 есть дополнительные офисы, в которых работают более 45 000 сотрудников. SM Lab — отдельно IT-подразделение, которое занимается разработкой софта и, собственно, его локализацией для стран нашего присутствия.

Тонкости локализации

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

Например, белый цвет, который в принципе везде считается нейтральным, в Японии могут расценить как траурный, так что не всегда будет уместно его использовать. В разных странах по-разному могут воспринимать ещё и жесты с символами, которые вам кажутся привычными и стандартными. Скажем, значок мира, который у нас так и воспринимается, в Великобритании лучше не показывать, он считается оскорбительным жестом. Большой палец вверх тоже у нас считается вполне себе адекватным, а вот жестовое обозначение “ОК” в той же Бразилии расценивается совсем иначе.

Если кто-то смотрел фильм Квентина Тарантино «Бесславные ублюдки», то вы явно помните сцену, в которой офицер под прикрытием (персонаж Майкла Фассбендера) заказывает жестом три пива, чем и выдает себя. 

Сборник коротких рецептов по автоматизации инженерных систем дома, офиса и любого другого объекта на оборудовании Wiren Board.

Статья будет полезна всем, кто задумывался о построении умного дома, офиса, теплицы и любого другого объекта с автоматизацией и диспетчеризацией.

Привет, Хабр! В статье расскажу, как сделать CI-конвейер в домашних условиях и делать простые android-приложения без знаний Java и Kotlin.

Вы сталкивались с тем, что ноутбук случайно включается, хотя вы уверены, что отправляли его в сон?

Бывало, что батарея оказывалась пустой, хотя вы точно-точно помните, как убирали в сумку заряженный на 100% ноутбук?

Тогда вам сюда:

Модель “Приказать”

Собеседования в крупные IT-компании почти всегда содержат алгоритмическую секцию — даже если вы собеседуетесь на позицию, в работе на которой алгоритмы возникать вряд ли будут. Ниже мы приводим пример задачи, с которой вы можете столкнуться на вашем следующем интервью. Мы расскажем, как эта задача решается, но мы настоятельно рекомендуем вам читать решение только после того, как вы попробуете решить задачу самостоятельно: во-первых, это отличная тренировка; во-вторых, вы лучше запомните решение, если придумаете его сами (не отказывайте себе в этом удовольствии!); в-третьих, даже если вы подумаете над задачей, но не решите её, время не будет потеряно: прочитав потом решение, вы лучше его поймёте и оцените его красоту.

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

Первый тип - быстрые программисты. С такими сталкиваешься редко. Это эрудированные и увлеченные люди, обычно занимающие высокое положение в иерархии разработчиков (тим лиды или что-то около). Основная особенность - высокая скорость написания кода и способность быстро осваивать новые технологии. Думаю, для корпоративной среды это ценные сотрудники, поскольку, чаще всего скорость в цене. Качество кода у таких программистов не всегда высокое, чаще наоборот. Иногда код сложный. Один раз я просматривал код за одним из таких специалистов и он меня поразил одной особенностью. Это был код высококлассного спеца, но выглядел он как набросок - широкими мазками была сформирована структура, но вот детали были иногда просто не реализованы. Обычно код таких программистов приходится допиливать, но главное преимущество, что код очень быстро появляется и сразу в больших объемах. Работая с таким кодом, чаще всего находишься в растерянности от широты мысли и идей автора.

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

• Кем собственно мы хотим стать?
• Надо-ли оно нам?
• Теоретические навыки
• Практические навыки (технические)
• Практические навыки (нетехнические)

Перед тем, как ответить на вопрос «Как измерить успех?», надо понять, что значит «успех» именно для вас. Для Dev и Ops определение успеха отличается. Для Dev успешный проект полностью проходит тестирование. Для эксплуатации — мониторинг. Тестирование и мониторинг нужны, но тесты никогда не дают 100% покрытия проблемы, а ответа 200 от HTTP недостаточно, чтобы быть уверенным в том, что система хорошо работает. Leon Fayer на РИТ++ отстаивал точку зрения, что DevOps платят не за то, чтобы все метрики в мониторинге были в зеленой зоне. Платят за то, чтобы пользователи были довольны. Если недовольны — бизнес теряет деньги, и никого не волнует, что все зеленое.

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

О спикере: Leon Fayer родился в когда-то дружественной республике, но вырос в США. Начал заниматься программированием очень много лет назад, и за это время работал программистом, менеджером — кем только не работал. Участвовал в стартапах — некоторые были более удачные, а некоторые не очень.

Много лет Леон работает в OmniTI. Эта компания специализируется на разработке масштабируемых систем, поэтому Леон имеет уникальную возможность проектировать и строить системы для самых посещаемых сайтов в мире — Wikipedia, National Geographic, White House, MTV и т.д.