Избавьтесь от YouTube Shorts в вашем браузере с помощью расширения Ublock Origin и ряда простых и незамысловатых шагов
программист баз данных
С новым годом: GPT в 500 строках на SQL
В минувшем году все только и говорили об ИИ и о том, как он может всё за вас сделать.
Мне нравится, когда кто-то или что-то работает за меня. Поэтому решил: попрошу-ка ChatGPT написать за меня новогодний пост:
«Эй, ChatGPT. А ты можешь реализовать большую языковую модель на SQL?»
«Нет, SQL не подходит для реализации больших языковых моделей. Язык SQL предназначен для выполнения запросов к данным, хранящимся в РСУБД и для управления этими запросами. Для реализации большой языковой модели требуются сложные алгоритмы, обширные датасеты, а зачастую — и фреймворки для глубокого обучения. SQL всеми этими возможностями не обладает.»
Что ж, лишний раз убеждаешься, что, если хочешь что‑то сделать хорошо – сделай это сам.
Давайте же воодушевимся этим оптимистическим планом и реализуем большую языковую модель на языке SQL.
Как мы в SM Lab локализацией занимаемся
Всем привет! Мы (Никита Звонилкин и Дмитрий Ёжиков) работаем в отделе локализации в SM Lab. Мы провели презентацию по теме интеграции локализации в процесс тестирования ПО на конференции SQA Days. Для этой статьи мы адаптировали эту презентацию, чтобы показать, чем локализация отличается от перевода. А ещё расскажем про основные этапы локализации, поговорим о подборе команды для проведения тестирования и о полезном софте.
Немного цифр. Спортмастер — большая компания, торговые сети представлены в 6 разных странах, а в 11 есть дополнительные офисы, в которых работают более 45 000 сотрудников. SM Lab — отдельно IT-подразделение, которое занимается разработкой софта и, собственно, его локализацией для стран нашего присутствия.
Тонкости локализации
Локализация это не просто перевод, но и адаптация текста и содержания под культуру конкретной страны, ее стандарты и менталитет. В локализации важно не только хорошо перевести текст но и донести культурный код, который может выражаться как в изображениях, так и во всяких смайлах, эмоджи, жестах, символах и так далее.
Например, белый цвет, который в принципе везде считается нейтральным, в Японии могут расценить как траурный, так что не всегда будет уместно его использовать. В разных странах по-разному могут воспринимать ещё и жесты с символами, которые вам кажутся привычными и стандартными. Скажем, значок мира, который у нас так и воспринимается, в Великобритании лучше не показывать, он считается оскорбительным жестом. Большой палец вверх тоже у нас считается вполне себе адекватным, а вот жестовое обозначение “ОК” в той же Бразилии расценивается совсем иначе.
Если кто-то смотрел фильм Квентина Тарантино «Бесславные ублюдки», то вы явно помните сцену, в которой офицер под прикрытием (персонаж Майкла Фассбендера) заказывает жестом три пива, чем и выдает себя.
Как собрать бюджетный умный дом. Общие принципы проектирования на оборудовании Wiren Board
Сборник коротких рецептов по автоматизации инженерных систем дома, офиса и любого другого объекта на оборудовании Wiren Board.
Статья будет полезна всем, кто задумывался о построении умного дома, офиса, теплицы и любого другого объекта с автоматизацией и диспетчеризацией.
Android-разработка для самых маленьких
Привет, Хабр! В статье расскажу, как сделать CI-конвейер в домашних условиях и делать простые android-приложения без знаний Java и Kotlin.
Вы НЕ сошли с ума (о режиме сна в Windows)
Вы сталкивались с тем, что ноутбук случайно включается, хотя вы уверены, что отправляли его в сон?
Бывало, что батарея оказывалась пустой, хотя вы точно-точно помните, как убирали в сумку заряженный на 100% ноутбук?
Тогда вам сюда:
“Приказать или научить?”. 4 модели помощи сотруднику, во время уточняющих вопросов
В предыдущей статье мы рассмотрели уровни делегирования и плюсы/минусы от применения каждого из них. Сейчас же я предлагаю пойти дальше и рассмотреть модели помощи сотруднику во время его уточняющих вопросов, по ранее поставленному заданию.
Независимо от уровня делегирования, от детализации, от глубины инструктажа, от профессионализма и опыта сотрудника, он далеко не всегда может взять и самостоятельно выполнить задание. На любом из этапов выполнения задания у сотрудника могут появляться либо какие-то преграды, либо новые вводные, либо просто сомнения. И в одной из этих ситуаций сотрудник может обратится за помощью к руководителю. Вряд ли в подобных “набегах” сотрудников кто-то рассмотрит странность — это обычные будни руководителя.
Уточняющие вопросы могут возникать как во время делегирования, так и после (на любом этапе выполнения задания). И руководитель может и должен использовать все подобные контакты с подчиненными для их развития. И для этого он может использовать разные модели помощи в решении вопросов.
Модель “Приказать”
Модель подразумевает, что сотруднику во время его уточняющего вопроса выдается прямой и полный ответ, который не требует и не предполагает обсуждения. К примеру, сотрудник приходит к руководителю с вопросом: “Иван Александрович, у меня дилемма. Я провел анализ подрядчиков и у меня есть 3 финалиста. Я никак не могу выбрать”. На что руководитель отвечает: “Будем работать с “Супер Технолоджи”.
Интерактивный учебник для подготовки к алгоритмической секции собеседования
Собеседования в крупные IT-компании почти всегда содержат алгоритмическую секцию — даже если вы собеседуетесь на позицию, в работе на которой алгоритмы возникать вряд ли будут. Ниже мы приводим пример задачи, с которой вы можете столкнуться на вашем следующем интервью. Мы расскажем, как эта задача решается, но мы настоятельно рекомендуем вам читать решение только после того, как вы попробуете решить задачу самостоятельно: во-первых, это отличная тренировка; во-вторых, вы лучше запомните решение, если придумаете его сами (не отказывайте себе в этом удовольствии!); в-третьих, даже если вы подумаете над задачей, но не решите её, время не будет потеряно: прочитав потом решение, вы лучше его поймёте и оцените его красоту.
7 типов корпоративных программистов
Давно хотелось написать про корпоративных программистов, по своему опыту, какие они бывают, какой у них стиль работы. Речь идет о разработке в плане сопровождения или переработки больших систем.
Первый тип - быстрые программисты. С такими сталкиваешься редко. Это эрудированные и увлеченные люди, обычно занимающие высокое положение в иерархии разработчиков (тим лиды или что-то около). Основная особенность - высокая скорость написания кода и способность быстро осваивать новые технологии. Думаю, для корпоративной среды это ценные сотрудники, поскольку, чаще всего скорость в цене. Качество кода у таких программистов не всегда высокое, чаще наоборот. Иногда код сложный. Один раз я просматривал код за одним из таких специалистов и он меня поразил одной особенностью. Это был код высококлассного спеца, но выглядел он как набросок - широкими мазками была сформирована структура, но вот детали были иногда просто не реализованы. Обычно код таких программистов приходится допиливать, но главное преимущество, что код очень быстро появляется и сразу в больших объемах. Работая с таким кодом, чаще всего находишься в растерянности от широты мысли и идей автора.
Второй тип - педанты. Код этих программистов пишется со средней скоростью, обычно он качественный в плане надежности и отсутствия ошибок, но часто бывает перегружен количеством рассмотренных кейсов, проверок и т.д. Код сложный, со сложными для понимания структурами и алгоритмами, от него нет чувства полетности, код тяжелый и очень трудно воспринимается при чтении. Один раз я сталкивался с таким кодом, где практиковались очень длинные строки - по несколько сот символов, вызовы методов с большим количеством параметров, каждый из которых сам был вызовом других методов или конструкторов. Править такой код чрезвычайно сложно, очень тяжело понимать для чего сделаны те или иные вещи.
Андрей Зарецкий, Александр Труханов: «Гонорара хватило, чтобы кофе попить»
В 1991 году издательство «Просвещение» выпустило детскую книгу «Энциклопедия профессора Фортрана». Практически моментально она стала бестселлером и разошлась миллионными тиражами. Это был очень легкий и понятный рассказ о персональных компьютерах, которых в нашей стране еще не было практически ни у кого. Музейный проект DataArt пообщался с авторами книги Андреем Зарецким и Александром Трухановым о том, как два ученых-физика решили стать писателями и придумали профессора Фортрана и Кадабру. В первой части монолога — рождение идеи, ненавистный научпоп, свобода мысли в Черноголовке и чаепитие с Фронтом освобождения Полисарио.
Конспект доклада «Как стать классным спецом по бд» (HL2018, Data Egret, Илья Космодемьянский)
Второй лекцией выбрал интересный материал, который нашел отклик как по конспекту, так и в зале. На мой взгляд, этот доклад может быть интересен всем, особенно начинающим специалистам.
В докладе затронуты вопросы:
- Кем собственно мы хотим стать?
- Надо-ли оно нам?
- Теоретические навыки
- Практические навыки (технические)
- Практические навыки (нетехнические)
Как измерить успех. Стратегии мониторинга и их связь с бизнес-проблемами
Перед тем, как ответить на вопрос «Как измерить успех?», надо понять, что значит «успех» именно для вас. Для Dev и Ops определение успеха отличается. Для Dev успешный проект полностью проходит тестирование. Для эксплуатации — мониторинг. Тестирование и мониторинг нужны, но тесты никогда не дают 100% покрытия проблемы, а ответа 200 от HTTP недостаточно, чтобы быть уверенным в том, что система хорошо работает. Leon Fayer на РИТ++ отстаивал точку зрения, что DevOps платят не за то, чтобы все метрики в мониторинге были в зеленой зоне. Платят за то, чтобы пользователи были довольны. Если недовольны — бизнес теряет деньги, и никого не волнует, что все зеленое.
Под катом много примеров из практики, которые доказывают эту точку зрения. Разберем, зачем понимать бизнес, как следить за успехом с точки зрения бизнеса, и зачем это нужно простым разработчикам.
О спикере: Leon Fayer родился в когда-то дружественной республике, но вырос в США. Начал заниматься программированием очень много лет назад, и за это время работал программистом, менеджером — кем только не работал. Участвовал в стартапах — некоторые были более удачные, а некоторые не очень.
Много лет Леон работает в OmniTI. Эта компания специализируется на разработке масштабируемых систем, поэтому Леон имеет уникальную возможность проектировать и строить системы для самых посещаемых сайтов в мире — Wikipedia, National Geographic, White House, MTV и т.д.
Кривая обучения и кривые руки: неуемная фантазия + исследования физика Джеффри Уэста
Под катом — несколько интересных графиков и эволюция сложных систем. И что с этим делать.
Information
- Rating
- Does not participate
- Registered
- Activity