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

Меня зовут Катя. Сейчас я руковожу мобильной разработкой, а выросла из Android-разработчика. Я провела около 800 собеседований. И нет, мне не надоело.

В статье порассуждаю, что же движет людьми проводить интервью и что можно порекомендовать интервьюеру.

В октябре прошлого года я публиковал в этом блоге статью «Астероид – не роскошь, а средство передвижения», в которой рассматривал потенциальные возможности переоборудовать небольшой астероид в звездолёт или даже в поколенческий корабль. Среди многочисленных отзывов, которые я получил на эту публикацию (одних только комментариев на Хабре набралось 212) были и вопросы о том, как я отношусь к идее о межзвёздных путешествиях на странствующих планетах или, как их называют в англоязычных источниках, «rogue planets». Странствующие миры – один из многих сюрпризов, которые преподносит нам изучение экзопланет. Одна из первых статей о существовании блуждающих планет и о том, что они потенциально могут быть резерватами жизни в межзвёздном пространстве принадлежит Дэвиду Дж. Стивенсону. Эта статья была опубликована в журнале «Nature» в 1999 году. После 2011 года с чисто статистической точки зрения не остаётся сомнений, что в нашей Галактике может существовать до 200 миллиардов блуждающих планетоподобных тел. В начале XXI века такие тела начали открывать методом микролинзирования; на Хабре об этом не так давно писал уважаемый @SLY_G. Ниже рассмотрим, что могут представлять собой блуждающие планеты, что о них известно наверняка, а что остаётся в статусе гипотез.

UPD: по-видимому, астрологи в Эрафии объявили неделю блуждающих планет. Всего три дня назад научно-популярное сообщество "Биореактор" @InBioReactorопубликовало в своём сообществе в сети "VK" статью "Космические бомжи" (автор - Никита Игнатенко), также посвящённую этому экзотическому классу небесных тел.

Привет, Хабр!

Сегодня с вами участники профессионального сообщества NTA Попов Иван и Чимбеев Анатолий.

В современном мире, где фотографии играют огромную роль в сфере социальных медиа, онлайн‑безопасности и контроля содержимого, важно иметь эффективные инструменты для обнаружения нежелательных предметов на изображениях. В данной публикации мы рассмотрим практическое применение двух популярных моделей — YOLO и ResNet — для обнаружения нежелательных предметов на фотографиях.

В данной серии статей я подробно рассказываю о том, как написать на Java собственный интерпретатор объектно-ориентированного диалекта SQL с использованием Spark RDD API, заточенный на задачи подготовки и трансформации наборов данных.

Краткое содержание предыдущей серии, посвящённой имплементации спеки языка в коде:
Заметка об использовании prior art
Наборы данных в контексте исполнения
Переменные, настройки контекста исполнения, и метаданные параметров подключаемых функций
Интерпретатор, контекст исполнения, операторы выражений

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

Берём в работу новую задачу или проект. Начинаем со сбора бизнес-требований. Потом архитектура системы и влияние требований на нее, БД, API, интеграции. И вот, в процессе разработки выясняется, что в требованиях опять что-то не учли. Что может быть хуже?

Может, коллеги! Когда через пол года вам же приходится возвращаться к задаче и вы понимаете, что требования к развитию системы по словам разработчиков нереализуемы. Как так?! Элементарная же задача! А потом мне показывают БД. И тут я понимаю, что пришло время делать выбор: дорого переделывать или "костыли" подойдут.

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

Примеры формулировок требований в соответствии с руководством по написанию требований от INCOSE

Статья содержит примеры формулировок требований как правильных (т.е. с точки зрения соответствия правилам руководства), так и неправильных (т.е. с точки зрения нарушения правил руководства).

В последние несколько лет в среде технических писателей все больше на слуху концепция Docs as Code. Если вы раньше не сталкивались с этим термином, он обозначает подход к разработке технической документации с использованием тех же инструментов и процессов, что и написание кода. Если DocOps это про процессы и коллаборацию, то Docs as Code — про инструментарий, при помощи которого мы несмотря ни на что. Мы выбрали этот подход, когда создавали портал документации Plesk.

В этой статье я кратко расскажу, что такое Docs as Code и зачем оно нужно, а затем дам несколько советов относительно того, как это чудо враждебной техники внедрять, сдобрив всю историю рассказами о тех граблях, на которые мы наступили, топая в светлое будущее. Я старался писать такую статью, которая пригодилась бы мне в 2017 году, когда мы эту кашу заваривали.

Хабр, привет! В прошлой статье про UML мы узнали что такое язык моделирования UML, зачем он нужен, основные плюсы и минусы UML, а также рассмотрели диаграмму классов. Сегодня я хочу продолжить тему проектирования процессов и остановиться на диаграмме компонентов.

У INCOSE (Международного совета по системной инженерии) в июне 2023 года вышла итоговая сводка по руководство по написанию требований (ссылка).

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

Данная статья - перевод с английского языка итоговой сводки по написанию требований.

Привет, Хабр! Сегодня расскажу о том, как мы в Fix Price закрыли проблему организации единой авторизации и аутентификации для наших сервисов с помощью Keycloak. Хотелось бы, чтобы эта статья оказалась полезной для всех, кто планирует внедрять это решение.

Начнем с общих моментов, а если хотите сразу перейти к коду, примеры вы найдете ниже. Их у нас целых 4, и все расписаны очень подробно. Поехали!

Всем привет! Меня зовут Дмитрий Ермошкин, я работаю системным аналитиком на проектах компании Fix Price. Расскажу сегодня о том, каким образом нам удалось автоматизировать загрузку товаров на онлайн-витрину компании.

У нас было несколько систем, в которых мы хранили данные для дальнейшей публикации на витрину: SAP, LCB (склад), 1C. Предложения о новых товарах поступали из разных каналов: email, мессенджеры, а менеджеры занимались проверкой данных, уточняли данные у поставщиков. Однако у Fix Price несколько сотен поставщиков и несколько тысяч товаров, а автоматическая проверка полноты данных при такой схеме затруднена. Поэтому была поставлена следующая задача: приведение данных к качественному виду и их консолидация в единой системе. При этом система должна быть отказоустойчивой и производительной, а также должно быть обеспечено удобство работы с ней для поставщиков.

Как всё работает:

Формировать, рассылать и контролировать подписание кадровых документов вручную не слишком удобно даже в маленькой фирме. Что уж говорить про компанию, в которой работает более полутора тысяч человек. Меня зовут Михаил Егоров, я работаю на проектах Fix Price в качестве программиста-консультанта. Расскажу вам о том, как мы упростили работу нашим кадровикам и автоматизировали эти процессы в сети Fix Price в Казахстане.

А перед этим скажу, что код, связывающий API оператора и нашу 1С, был написан мною с нуля. При этом на момент внедрения (апрель 2022 года) разработок и примеров работы в открытом доступе не было.

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

Эта статья-инструкция по построению высоконагруженных распределенных систем. Описанный подход может быть полезен как reference при подготовке к интервью по system design в FAANG и не только.

Одна из наиболее часто обсуждаемых проблем, возникающих в начале пути освоения космоса, - как доставить с Земли ресурсы, необходимые для жизни. Обычно это две вещи - вода и кислород, но, к счастью, кислород можно получить путём расщепления молекулы воды, поэтому наиболее важным ресурсом, который мы можем найти в космосе, является вода. На языке космических ресурсов воду принято называть «летучим веществом», и именно она находится в центре внимания многих планов по использованию местных ресурсов на Луне, Марсе и в других местах. Некоторые из этих планов были хорошо продуманы, другие - нет. Один из них, в частности, продемонстрировал многообещающие перспективы, когда в 2019 году он был отобран в рамках финансирования Института перспективных концепций НАСА (NIAC), и здесь мы рассмотрим его более подробно.

Концепция, официально известная как «Термическая добыча льда на холодных телах Солнечной системы» (или просто «термическая добыча») - детище Джорджа Соуэрса, эксперта по космическим ресурсам и профессора машиностроения в Горной школе Колорадо. Концепция, лежащая в основе проекта, удивительно проста и знакома каждому, кто в детстве играл с увеличительным стеклом.

В мире современной разработки программного обеспечения, взаимодействие между различными приложениями через интерфейсы приложений (API) стало неотъемлемой частью разработки. Однако, прежде чем мы можем строить сложные взаимодействия, необходимо убедиться, что наш API работает корректно и предоставляет ожидаемые результаты.

И вот на сцену выходит Postman - мощный и интуитивно понятный инструмент, предназначенный специально для тестирования и разработки API. В этой статье рассказывается о самых базовых вещах, с которых следует начать свое знакомство с Postman.

Отправка HTTP-запросов, создание тестов, организация запросов в коллекции, работа с переменными - все это лишь часть функциональности Postman, которая облегчает процесс тестирования и повышает его эффективность. Если вы только начинаете свой путь в изучении этого инструмента, не волнуйтесь! Этот гайд поможет вам разобраться с базовыми принципами работы с Postman и покажет, как сделать ваш процесс тестирования API гораздо более эффективным и приятным.

Готовы начать? Давайте вместе погрузимся в увлекательный мир тестирования API с Postman!

Эта публикация предназначена для прочтения в выходные или предвыходые дня для поднятия или поддержания хорошего настроения.

Всё изложенное в ней абсолютная правда. Или почти.

Сразу после окончания Новосибирского Университета, в первый же день моей трудовой деятельности на ВЦ СОАН СССР я возглавил коллектив из более чем тридцати учёных, включая двух докторов наук. Руководящий пост я не покупал, как возможно предположили некоторые, никаких необходимых для занятия этого поста связей и знакомств у меня не было.

Я не уверен, что могу посоветовать мой рецепт карьерного роста другим. Но узнать о нём вам будет, я надеюсь, небезинтересно.

Целью данной статьи является защита точки зрения того, что Системный аналитик с бизнес-навыками или наоборот Бизнес-аналитик с навыками системного анализа это то, что сейчас востребовано бизнесом, хотя открыто это и не прокламируется. Данное мнение базируется только на личном опыте.

Меня зовут Саша и я аналитик SMP Mobile. Это мобильное приложение, с помощью которого коллеги могут, например, зарегистрировать заявку по QR коду в офисе и не только.

В жизни каждого начинающего аналитика рано или поздно наступает момент, когда ему выпадает первая большая задача. Конечно, возникает масса сложностей и аналитик совершает ошибки. Сегодня расскажу про свой опыт решения большой аналитической задачи на примере чек‑листов в SMP.