Фулстек разработчик: Vuejs, .NET
Всем привет! На связи Пётр, Go-разработчик в команде Ozon, которая занимается управлением товарами торговой площадки. Всё, что загружают продавцы, обрабатывается нашими сервисами. Девять месяцев назад я сменил основной язык программирования с C# на новый для меня Go. В статье будут впечатления от Go, расскажу о некоторых различиях между языками, а в конце поделюсь своим опытом поиска работы на новом языке. Ведь вопрос смены стека технологий рано или поздно встаёт перед каждым разработчиком.
System Design Interview — пожалуй, один из самых «бесформенных» этапов технического собеседования. Здесь важно не найти единственно верное решение, а продемонстрировать системное мышление, умение работать с абстракциями, логически выстраивать архитектуру и аргументированно делать выбор технологий.
Александр Кучук, эксперт сообщества Spring АйО, подготовил авторскую статью, в которой шагом показывает, как структурировать интервью, какие вопросы задавать, как рассуждать и что оценит интервьюер.
Кстати, Александр ведет репозиторий с заметками: https://github.com/qcha/JBook
При разработке чат-ботов и голосовых ассистентов часто возникает задача нахождения семантического сходства слов. Причина тому – наличие в языке большого количества схожих по смыслу слов и выражений.
Я пишу коммерческий код с 2005 года и с 2014 года ищу способ систематически писать хороший код.
В рамках этих поисков я изучил всю популярную литературу о хорошем коде и его дизайне — от «Чистого кода» Анкл Боба до «DDD» Эрика Эванса. Однако все популярные подходы в значительной степени субъективны: они не дают объективного и последовательного судьи, который бы решал, какой код лучше.
Например, в чистом коде я до сих пор не знаю способа за конечное время дать ответ на вопрос «Сколько уровней абстракции в этой функции?». А если взять DDD — то я до сих пор не знаю способа, который бы позволял стабильно и за конечное время находить границы между ограниченными контекстами (прошу прощения за каламбур) или агрегатами.
Эта неопределённость ведёт к длительным дискуссиям на ревью и в голове разработчика о том, какой из способов является наилучшим для решения задачи. А после этих дискуссий, каждый из участников (включая того дилетанта в собственной голове) остаётся при своём мнении.
Отчаявшись научиться писать стабильно хороший объектно‑ориентированный код, в 2016 году я пошёл в сторону функционального программирования и архитектуры. Там с детерминированностью было получше: если в коде нет побочных эффектов (ввода‑вывода, оператора присваивания и чтения глобальных переменных) — то код хороший, если есть — плохой. Однако как затащить в коммерческий проект и, главное, собственную голову свободные монады и их интерпретаторы — я так и не понял.
Поэтому в 2020 году поиски своего Святого Грааля я продолжил в «эзотерических» и древних книгах. Одной из таких книг стал «Структурный дизайн» Ларри Константина. И в этой книге я, наконец, нашёл простой и понятный принцип, который лёг в основу моего текущего подхода к проектированию и кодированию, и для которого можно быстро и однозначно дать ответ, соответствует ли тот или иной кусочек кода этому принципу или нет.
В этом посте я даю краткий экскурс в идею сбалансированной формы системы из структурного дизайна и рассказываю на примере трёх кейсов о результатах применения этой идеи в моей коммерческой практике.
Привет, меня зовут Борис. Я автор телеграм канала Борис опять. Периодически мне на глаза попадается что-то интересное и я глубоко в этом закапываюсь. В данном случае это алгоритм поиска BM25+, который победил продвинутые методы векторного поиска на LLM.
Разберемся, что это за зверь и почему он так хорошо работает. В этой статье мы реализуем его на Python с нуля. Начнем с самого простого поиска, перейдем к TF-IDF, а затем выведем из него BM25+.
Статья подойдет тем, кто вообще ничего не знает о поиске, а более опытные ребята могут пролистать до реализации алгоритма.
Код доступен в Google Collab.
Привет, Хабр! В общем работаю я значит Архитектором Программных Решений. Мы тут монолиты на микросервисы переводим поэтому я решил для наших разработчиков написать пример проекта с сагой и за одно может оно и вам понадобиться поэтому выложил сюда. Статья будет дополняться по мере поступления вопросов от вас и от наших разработчиков
Эта статья - вторая в серии, после статьи Ретеншен — основная метрика F2P игры, вероятностный подход
Здесь я рассматриваю ретеншен не как скалярную случайную величину, а как случайный временной ряд. Далее создаю модель нелинейной аппроксимации метрики, учитывающую сезонность и выпуск патчей.
Рассмотренная методика реализована в виде Jupyter-ноутбука retention-rate-approximator, выложенного в общий доступ.
Как думает искусственный интеллект? Попробовать разобраться в его логике можно в игре от менторов AI Talent Hub, онлайн-магистратуры Napoleon IT и ИТМО, и студентов ИТМО «Отгадай слово». За два месяца в нее сыграли уже более 107 тысяч уникальных пользователей, а количество подписчиков одноименного телеграм-канала увеличилось до 5 000.
Что делает игру такой популярной, как проект окупился без затрат на продвижение и рекламы на сайте, а также почему при работе с ИИ не избежать ошибок? Рассказываем в статье.
Невероятно красивая графика, игра с уникальной концепцией или геймплеем и увлекательная песочница - все это присуще играм из чартов продаж. Добиться успеха вам поможет не только маркетинг или тысячи добавлений в список желаний, а по настоящему классная игра и чтобы понять, что делает игры успешными стоит анализировать продаваемые релизы каждого месяца.
https://fakt309.github.io/thisisthewall/
В языках программирования строки сравниваются очень просто, если строка отличается хотя бы на один символ, то возвращает false.
Но вот что если мы хотим не просто получать дискретное значение (true / false), а дифференцированное, например в процентах. Ведь согласитесь строки test и testing гораздо ближе к друг другу, чем test и abcd. Для данной проблемы существует множество решений, мы поговорим о самый популярных алгоритмах (также об их модификациях):
Расстояние Хэмминга
Расстояние Левенштейна
Сходство Джаро — Винклера
Коэффициент Сёренсена
Кибератаки, воровство и вандализм — сервисы аренды самокатов — кикшеринги кажутся довольно уязвимыми, но так ли это? В одном из недавних проектов команда Бастион проверяла защиту Юрент — это отличный повод узнать подробности из первых уст.
Мы попросили директора по IT Юрент Андрея Калинина рассказать о том, почему пенсионеры угоняют самокаты, сталкиваются ли в компании с киберугрозами и как устроена система безопасности шеринговых сервисов.
О хуках в фронтенд-разработке на Хабре писали уже не раз, и в этой статье мы не сделаем великого открытия. Наша цель другая – рассказать про React Hooks настолько подробно и просто без трудной терминологии, насколько это возможно. Чтобы после прочтения статьи каждый понял про хуки всё. Эта статья будет полезна как начинающим React-разработчикам, так и тем, кто хочет, не уходя в глубины документации, получить практическую информацию в сжатом виде.
Писатели-фантасты на протяжении многих лет регулярно обращаются к сюжетам про «восстания машин», но по актуальности они, кажется, сейчас отходят на второй план. Зато можно рассмотреть другую интересную сторону этой медали: историю о том, как люди сами отдают контроль над своими жизнями в руки искусственных интеллектов и алгоритмов. Просто потому что они точнее, надежнее и не думают о собственной выгоде. Если мы уже можем читать реальные новости про цифрового прокурора в Шанхае и выпускников, которые готовы доверить искусственным интеллектам выбор своей профессии, то почему бы фантастам не рассмотреть возможные изъяны и риски? И они действительно уже делали это не раз! Вот несколько ярких примеров от классики и до наших дней.
Мой переход на F# в качестве излюбленного языка был слегка усеян препятствиями. Примерно через десять лет почти постоянного использования C# у меня пробудилось любопытство, когда я услышал об этом другом #-языке. Моя первая реакция была той, которую с тех пор видел у других C#-разработчиков — отрицание, — C# является хорошим языком, и мне с ним комфортно, так зачем тратить силы на изучение другого? Но любопытство осталось — и, по крайней мере, несколько раз выделил вечер, чтобы прочитать базовый вводный пост и попытаться написать каких-нибудь ката на F#. Это не прижилось, потому что я просто чувствовал себя потерянным и не мог воплотить свой опыт использования C# в ощущение даже отдаленного комфорта с F#. Достаточно легко опустить фигурные скобки, немного замяться, чтобы не забыть let вместо var — но как сделать то, что я хотел?
Тогда я этого не осознавал, но, на мой взгляд, наблюдал потенциальный недостаток в том, как F#-разработчики говорят, описывают и представляют свой язык внешнему миру. Существует обширная база материалов обо всех возможностях и функциональности F#: Algebraic Data Types, Exhaustive Matching, Type Inference и т.д. Есть много статей, посвященных тому, как решать широкий спектр задач с помощью F#. Но, как мне кажется, не хватает чего-то вроде следующего: некоторых указаний о том, как взять то, что вам уже удобно в C#, и перевести их на F#. Так что мне интересно, можем ли мы как-то закрыть этот недостаток.
