system analyst, technical writer
Мы часто даем стартапам рекомендации по конкретным шагам и действиям, которые помогут в ежедневной работе. Но есть и более фундаментальные советы. В этой статье мы собрали те из них, которые мы считаем наиболее важными. Эти советы могут быть основанными на здравом смысле или быть контринтуитивными, но они помогают большинству стартапов найти свой путь к успеху.
Первое, что мы всегда говорим основателям стартапов — запускайтесь прямо сейчас...
В этой статье мы расскажем вам про самые важные фичи, внедренные за последние полгода в ChatGPT (самую мощную нейросетку в мире), а также обсудим – каким видением будущего поделился Сэм Альтман на прошедшей 7 ноября конференции от OpenAI. Спойлер: они хотят запилить «агентов Смитов», которые смогут самостоятельно взаимодействовать с миром!
Инструмент используется в JetBrains уже более 10 лет, и, по словам команды, продукты JetBrains, от языка программирования Kotlin до IntelliJ Platform SDK, используют Writerside для создания своей документации.
Или как понять, когда остановиться
Как-то раз мой коллега, лид разработки, после затяжного спора о том, что должно быть в системной спецификации, подошел ко мне и спросил:
— Скажи, а зачем нам вообще нужны аналитики?
— И действительно, зачем? – подумал тогда я и написал заявление
Вопрос этот, как бы крамольно он ни звучал, очень правильный. Системный анализ, как фаза разработки приложения, присутствует всегда (даже если это системы класса «Hello, world»), а вот системный аналитик, как выделенная роль – нет. Выделение отдельной специальной роли работает точно так же, как и разделение труда в обычном производстве: для маленьких задач не целесообразно, для больших задач – оправданно. При таком разделении системный аналитик забирает на себя часть задач и функций некоего «универсального» исполнителя задачи. Однако, подобное разделение труда имеет свою цену: это потеря знаний при коммуникации, более сложное управление процессом и др. В этой статье я хочу поделиться своим опытом: описать минусы крайностей и дать рекомендации по распределению обязанностей между системными аналитиками и разработчиками.
Итак, нам нужен системный аналитик, который формирует требования и разработчик, который эти требования реализует в коде.
Если спросить у любого разработчика, каким главным свойством должны обладать системные требования, он, скорее всего, скажет: «чтобы было понятно, что делать». И это проблема.
Заключается эта проблема в том, что между сбором и систематизацией требований (прямая и понятная задача аналитика) и непосредственно кодированием (прямая и понятная задача разработчика) есть область проектирования решения; задачи из этой области могут и должны выполнять обе роли.
Подход к ведению документации рядом с кодом используется в Альфа-Банке на протяжении нескольких лет. Он хорошо подходит для документирования API и сервисов, не требующего примеров пользовательского интерфейса. Однако с документацией на мобильные и веб-фронты ситуация немного сложнее.
В статье обозначу проблему, связанную с ведением фронтовой документации рядом с кодом, и приведу одно из решений на базе Git LFS. Затем поделюсь результатами двух пилотов, проведённых в Банке во втором квартале 2023. Их результаты помогут оценить влияние Git LFS на опыт ведения фронтовой документации рядом с кодом. Статья подойдёт всем, кто занимается подготовкой технической документации на программные продукты.
Однажды передо мной возник некий «чёрный ящик» — Шина, которая отвечает за преобразование данных из внешнего формата во внутренний. Какие внутри происходят преобразования, какие процессы, как идут запросы, потому что они очень большие, — непонятно. Логи есть, но они ограничены, к тому же часто запросы не логируются, потому что некоторые данные пользователей нельзя показывать. В попытках решить проблему и возник мок-сервер, как решение задачи понять, как работает «ящик», на каких принципах, и понять, правильно ли он работает.
План статьи:
— Проблематика черного ящика и почему его вообще нужно вскрывать.
— Варианты решения проблемы.
— Подробно про мок-сервер, как один из вариантов решения проблемы: зачем нужен, в чём польза и как выбрать между готовыми и самописными решениям.
— Как написать свой мок-сервер.
— Посмотрим как он работает на реальной задаче.
— Закрепляем материал в блоке «Польза мок-сервера».
Разработка веб API это нечто большее чем просто URL, HTTP статус-коды, заголовки и содержимое запроса. Процесс проектирования – то, как будет выглядеть и восприниматься ваш API – очень важен и является хорошей инвестицией в успех вашего дела. Эта статья кратко описывает методологию для проектирования API с опорой на преимущества веба и протокола HTTP, в частности. Но не стоит думать, что это применимо только для HTTP. Если по какой-то причине вам необходимо реализовать работу ваших сервисов используя WebSockets, XMPP, MQTT и так далее – применяя большую часть всех рекомендаций вы получите практически тот же API, который будет хорошо работать. К тому же полученный API позволит легче разработать и поддерживать работу поверх нескольких протоколов.
Использование проприетарных программ плохо влияет на образовательный процесс, Linux должен быть единственной операционной системой в школах и университетах.
Привет, Хабр!
Я решил посвятить свою первую статью SQL. Вопросы, рассмотренные ниже мне задавали на собеседованиях на позицию python-разработчика. Естественно отвечать правильно получалось не всегда, а если точнее то чаще не правильно, однако проведя N часов в рефлексии я составил перечень ответов, которыми пользуюсь до сих пор.
Данная информация предполагает знание основ языка запросов и я надеюсь, она окажется полезной для разработчиков, которые сейчас активно ищут работу а также, что ты прочитаешь этот текст до конца и добавишь свой вопрос к перечню (ну или поправишь неточности в существующих)
Я проходил технические собеседования на системного аналитика в самых разных компаниях и каждый раз записывал все вопросы. У меня накопилось 120 вопросов. Список вопросов выкладываю в этой статье. Даю гарантию, что, подготовившись по этим вопросам, вы будете успешно проходить технические собеседования в большинстве, если не во всех, it-компаниях. Почему? Потому что большинство вопросов повторяются от собеседования к собеседованию. Очень высока вероятность того, что вопросы, которые вам будут задавать, будут из этого списка.
Доброго времени суток, друзья!
Изучение настоящей шпаргалки не сделает вас мастером SQL, но позволит получить общее представление об этом языке программирования и возможностях, которые он предоставляет. Рассматриваемые в шпаргалке возможности являются общими для всех или большинства диалектов SQL.
Всем привет! Меня зовут Наталья Которева, я редактор в Яндекс.Практикуме. В этой статье я расскажу, как мы создали обучающий курс в GitLab. Да-да, вместо текстовых документов.
Вообще сложно представить, как можно подружить git и редактуру, а главное, зачем. Есть же много проверенных инструментов, с помощью которых можно без проблем писать текст и потом его всячески править. Но, как выяснилось, привычные гуглдоки и ноушен не особо подходили под наши запросы, поэтому пришлось искать альтернативу.
Сегодня я расскажу, с какими проблемами мы столкнулись, когда писали курс «Мидл Python-разработчик», зачем перенесли работу с контентом в GitLab и почему это оказалось хорошей идеей. Будет полезно почитать всем, кто так или иначе работает с контентом: редакторам, контент-менеджерам, специалистам по развитию бренда и тем разработчикам, которые создают контент сами.
При работе с Git-репозиториями часто нужно выполнять множество одинаковых действий: фиксировать изменения, переключать ветки, синхронизировать репозитории. Всё это требует ввода соответствующих команд в терминале. Когда частота ввода повышается до утомительной, на помощь могут прийти различные GUI-инструменты. В статье расскажу об одном из них — Lazygit, легковесном консольном клиенте для Git, который облегчает и упрощает работу с репозиториями.
Это вторая статья из цикла. В первой, вводной, я рассказывал, как устроены метрики для сервисов, чем отличаются от логов, и какую задачу вообще решают. Теперь подробнее про то, как их готовить.
Под катом: формат данных, способы отправки, типы метрик и их применение, кардинальность.
Меня зовут Сергей Марков, я системный аналитик бэковой части в Академии Инвестиций Тинькофф.
Системные аналитики работают в разных направлениях: сбор и управление требованиями, проектирование бизнес-процессов, техническое проектирование системы. Список задач можно расширять и детализировать дальше. В зависимости от сферы, размера и культуры компании обязанности системного аналитика могут быть разными. У нас в Тинькофф для системного аналитика делается довольно сильный акцент на технические знания и навыки.
