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

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

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

Привет! Меня зовут Даша Григорьева, я технический писатель в компании 65apps. Мы занимаемся разработкой сложных мобильных решений, и моя задача — подготовка технической документации по проектам. Очень часто роль технического писателя бывает недооцененной в компании (не у нас, конечно). Поэтому я хочу рассказать, зачем компании-разработчику нужен такой специалист, что такое технический проект, чем он отличается от ТЗ и почему это все необходимо для разработки мобильного приложения.

Рынок товаров и услуг с каждым днём всё сильнее смещается в онлайн. Продавцы уделяют своему цифровому представлению максимум внимания, и веб-разработчикам нужно каждый день создавать новое и уникальное. Чтобы Вы не теряли время на механической стороне работы и могли погрузиться в творческий процесс, мы предлагаем Вам подборку инструментов для разработки сайтов, где уже выделены преимущества и слабые места каждого.

Сервисы в этой сфере разделены на две группы по основному функционалу: к первой относятся площадки, дающие возможность создать непосредственно дизайн — Figma, Adobe XD, Sketch, InVision Studio — в них вы не соберете сайт, но разработаете его прототип и дизайн-макет. Вторая группа сервисов имеет расширенный функционал, здесь дизайнер может создать сайт с нуля: от прототипа до реализации — Pixli, Webflow и Tilda

Figma, Adobe XD, Sketch, InVision Studio: разработка дизайна и прототипов

Figma

Figma — сервис для дизайнеров интерфейсов и веб-разработчиков. В первую очередь, это онлайн-приложение, но можно воспользоваться и десктопной версией: файлы будут размещены на локальном хранилище, но их можно в любой момент импортировать в облако. Помимо основного функционала предусмотрены легко подключаемые плагины для множества целей: «Если вы можете создать сайт, вы можете создать плагин».

Расшифровка доклада 2015 года Ильи Космодемьянского "Linux tuning to improve PostgreSQL performance"

Disclaimer: Замечу что доклад этот датирован ноябрем 2015 года — прошло больше 4 лет и прошло много времени. Рассматриваемая в докладе версия 9.4 уже не поддерживается. За прошедшие 4 года вышло 5 новых релизов PostgreSQL вышло и 15 версий ядра Linux. Если переписывать эти места, то получится в итоге другой доклад. Но здесь рассмотрен фундаментальный тюнинг Linux для PostgreSQL, который актуален и сейчас.

В прошлой статье я рассказывал про основы JWT. Если на пальцах, то это просто ключ, с помощью которого мы открываем дверь к приватным ресурсам. А что, если этот ключ украдут (точнее, сделают дубликат). Тогда кто-то еще сможет входить на сервер под вашим именем, причём мы об этом можем даже не узнать. Такого сценария мы не хотим допустить. Но что делать?

Долго искал книгу, в которой было бы разжёвано, как использовать FFmpeg-подобную библиотеку, известную как libav (название расшифровывается как library audio video). Обнаружил учебник «Как написать видеоплеер и уложиться в менее чем тысячу строк». К сожалению, информация там устаревшая, так что пришлось создавать мануал своими силами.

Большая часть кода будет на C, однако не волнуйтесь: Вы легко всё поймёте и сможете применить на любимом языке. У FFmpeg libav уйма привязок ко многим языкам (в том числе и к Python и к Go). Но даже если Ваш язык прямой совместимости не имеет, всё равно можно привязаться через ffi (вот пример с Lua).

Начнём с краткого экскурса о том, что такое видео, аудио, кодеки и контейнеры. Затем перейдем к ускоренному курсу, посвященному использованию командной строки FFmpeg, и, наконец, напишем код. Не стесняйтесь переходить сразу в раздел «Тернистый путь изучения FFmpeg libav».

Есть мнение (и не только моё), что потоковое интернет-видео уже приняло эстафету от традиционного телевидения. Как бы то ни было, FFmpeg libav точно достоин изучения.

Оглавление

• Вступление
  • Видео — это то, что ты видишь!
  • Аудио — это то, что ты слышишь!
  • Кодек — сжатие данных
  • Контейнер — удобный способ хранения аудио/видео
• Командная строка FFmpeg
  • Инструмент в виде командной строки FFmpeg 101
• Основные операции над видео
  • Транскодирование
  • Трансмультиплексирование
  • Трансрейтинг
  • Трансайзинг
  • Бонус: адаптивный стриминг
  • Выходя за рамки
• Тернистый путь изучения FFmpeg libav
  • Глава 0 — простенький «Hello World»
    • FFmpeg libav архитектура
    • Требования
    • Собственно, код
  • Глава 1 — синхронизация аудио и видео
  • Глава 2 — ремультиплексирование
  • Глава 3 — транскодирование
    • Трансмультиплексирование
    • Транскодирование

Всем привет!

Относительно давно мне прилетела задача по учебе написание курсовой, и я её наконец-то написал. Чтобы добро не пропадало, я решил оформить её (курсовую) в виде статьи. Надеюсь, статья будет полезна не только для тех, кто хочет погрузиться в мир Web разработки, но и так же для тех, кто считает, что современный веб не так уж и сложен, чтобы платить высокую ЗП.

Итак, тема курсовой:

Разработать программу «Поиск». Программа должна осуществлять поиск заданных слов в текстовом файле. Слова последовательно вводятся с клавиатуры. Для каждого слова должно определяться количество вхождений и номера строк текста. Если указанное слово в файле отсутствует, то программа должна выводить соответствующее сообщение.

Разработкой всяких SPA и PWA я занимаюсь очень давно, но вот как-то не было случая пощупать Electron. Не спеша закрывая MS Visual Studio, подумал, почему бы нет...

И, пожалуй, начнём с инструментов разработчика.

Пока по планете гуляет версия 2020 года, заражённая вирусом, не стоит забывать, что и данные, и бизнес, и коммерческая информация тоже под угрозой. Неизвестно, что произойдёт завтра: взлом, угон информации, кража, отказ хостера в обслуживании. Мы немного устали от тяжёлой информации, думаем, вы тоже. Поэтому сегодня — открытка об основных правилах работы с бэкапами в самой лёгкой форме.

Гибкая методология разработки — отличная идея, которую слишком усложнили. Agile Lite — попытка упростить ситуацию. Вам не нужны книги или семинары, чтобы объяснить Agile Lite. Нужен только небольшой текст с несколькими пунктами. Вот этот текст.

Agile Lite довольно прост. Его можно применить к любому проекту при условии, что работа разбивается на более мелкие задачи (issue). Как и другие гибкие методологии, он использует короткие циклы разработки  — спринты. Но в отличие от них, Agile Lite явно признает распространённость выгорания в индустрии разработки программного обеспечения и пытается смягчить его напрямую путём внедрения цикла «три недели разработки/одна неделя отдыха.

Привет!

Если вы читали наши предыдущие посты (читали же?), то точно помните, что мы в RBK.money очень сильно за опенсорс. Настолько, что выложили в открытый доступ наш антифрод в виде открытых исходников под лицензией Apache 2.0.

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

Зачем мы это сделали? Как это работает внутри? Как теперь жить дальше? Читайте под катом. Я гарантирую, что такого вы еще не встречали — еще никто в мире не опенсорсил платежную систему такого уровня.

История меняется прямо сейчас на ваших глазах!

В предыдущей статье о проблемах внедрения ERP на промышленных предприятиях в качестве кейса к одному из пунктов был приведён «Программистский беспредел».

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


Тема это актуальная, и я решил написать о ней отдельную статью.

Часто ли вам приходилось писать обработчики фильтрации для ваших данных? Это могут быть массивы для отрисовки таблиц, карточек, списков — чего угодно.

Когда фильтрация статическая, то тут все просто. Стандартных функций map, filter и reduce вполне достаточно. Но что делать, если данные имеют сложную структуру или вложенность, да еще и правил для фильтра может быть достаточно много. Правила могут повторяться, данные изменяться, и чем больше контролов фильтра будет появляться, тем сложнее и неустойчивее будет код обработчика.

Как же решить проблему возрастающей сложности?

Сегодня мы поговорим об отечественных стандартах на проектную документацию. Как эти стандарты работают на практике, чем они плохи и чем хороши. При разработке документации для государственных и серьезных частных заказчиков у нас обычно нет выбора — в требования по документированию ТЗ вписано соблюдение стандартов. На практике мне приходилось сталкиваться с различными примерами недопонимания структуры стандартов, того, что должно быть в документах и зачем эти документы нужны. В итоге из-под пера техписателей, аналитиков и специалистов выходят порой такие перлы, что непонятно, в каком состоянии сознания они писались. А ведь на самом деле все достаточно просто. Поиск по Хабру не вернул ссылок на более-менее целостный материал на данную тему, потому предлагаю закрасить этот досадный пробел.

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

Кнопка — это один из тех элементов, которые чаще всего используются на веб-страницах. Тег <button></button> может быть применён для запуска некоего процесса вроде вывода данных, открытия модального окна, отправки формы и так далее. В материале, перевод которого мы публикуем, речь пойдёт о тонкостях стилизации элемента button и о том, как оформлять кнопки с учётом того, чтобы они хорошо работали бы в любых браузерах. Кроме того, тут будет рассмотрено большинство часто используемых стилей кнопок. Поговорим мы здесь и о некоторых сложностях, которые возникают при работе с кнопками.

Инструкция для новичков, о том, как сделать красивый dualboot windows и archlinux (и других ОС) через efi без grub и лишних заморочек.

Фото для привлечения внимания:

Предлагаем вам познакомиться с переводом статьи Jamie Bullock, опубликованной на сайте medium.com. Автор рассказывает, какие веб-приложения он обычно использует в работе.

Привет, Хабр, меня зовут Вадим Макишвили. В 2014 году я выступил с докладом «36». Рассказывал про кризис среднего возраста, признавался в собственных слабостях и делился способами, которые помогли мне совладать со страхами. Сразу после выступления друзья стали надо мной подтрунивать, мол, давай каждые десять лет по продолжению. Я отшучивался, мол, обязательно сделаю. Но, вообще-то, не собирался, потому что каждые десять лет рассказывать всему миру про свои страхи — скучно.

Однако несколько месяцев назад на конференции YaTalks в Екатеринбурге я выступил с новым докладом. В заголовке число 42, и возникает вопрос: «Неужели Макишвили — автор одной темы?» Нет. Самокопания не было. А что было? И можно ли «42» считать продолжением «36»?

Мой рассказ имеет отношение к предыдущей лекции лишь косвенно. В «42» я детально обдумываю тему, которой тогда едва коснулся. Но если кому-то удобнее думать, что «42» — вторая серия, пусть так. Тогда впереди ещё и третья, которая не будет иметь ничего общего ни с первой, ни со второй, ну разве что автор — я, и название тоже окажется каким-то числом.

«42» — точно не про кризис среднего возраста.


— Здравствуйте, друзья. Мне очень много хочется вам рассказать. Так много, что первая версия этого доклада длилась два часа. Но организаторы сказали мне — Макишвили, не наглей. Короче, вы со мной здесь на час. Я постараюсь, чтобы вам не было ни скучно, ни грустно.

Однажды на заводе, где я работал ИТ-директором, готовили отчетность к какому-то очередному мероприятию. Надо было рассчитать и предоставить показатели по выданному перечню, среди них затесалась текучесть кадров. И тут оказалось, что у меня она равна нулю.

Из руководителей я был такой один, тем самым привлек к себе внимание. Ну и сам удивился – оказывается, когда от тебя не уходят сотрудники, это странно и необычно.

В сумме я работал руководителем лет 7-10 (точно не знаю, какие периоды сюда включать), но нулевая текучка сохранилась. Никто никогда от меня не уходил, никого никогда я не выгонял. Только набирал.

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

Захотев перейти на Linux дома или на работе, люди обычно ставят Ubuntu, Mint, Fedora, порой даже Debian. И очень зря не пробуют Manjaro Linux — на мой взгляд, этот дистрибутив удобнее Убунты (которая уже де-факто — Default Linux), и даже удобнее Минта.

Manjaro — производная от Arch Linux (так же как Ubuntu — производная от Debian), пилится европейской командой Manjaro Team. У Манжары почти такая же структура системы, как у Арча, но с некоторыми особенностями, которые делают его на 146% юзерфрендли.