Processing *

Всем привет!

Сегодня хочу поделиться с вами тем, как «съесть слона» по кусочкам на моем личном опыте.. Эта статья будет полезна бизнес и системным аналитикам, которые сталкиваются с масштабными проектами и задачами, требующими декомпозиции. 

Немного о предыстории

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

Основная задача — декомпозировать и описать задачи для всех членов проектной команды.

Обработка потоковых данных стала крайне важна в настоящее время. И на это есть веские причины, такие как:

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

Объемные неограниченные наборы данных, все чаще встречающиеся в современных бизнес процессах, могут быть легче обузданы применением систем, специально спроектированных для таких объемов информации

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

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

Как тот, кто работал над крупно‑масштабной системой потоковой обработки в Google на протяжении последний пяти с лишним лет (MillWheel, Cloud Dataflow), я, мягко говоря, в восторге от сложившихся тенденций. Я все также заинтересован в том, чтобы люди понимали, что именно системы потоковой обработки в состоянии выполнять, и как их использовать наилучшим образом, в частности, закрыв нехватку знаний, оставшуюся между существующими системами пакетной обработки и потоковыми. С этой целью замечательные ребята из O»Reilly пригласили меня предоставить письменную версию моего доклада «Say Goodbye to Batch» с конференции Strata + Hadoop World London 2015.

Привет! Я - Катя Леханова, менеджер проектов в компании iSpring. 

В компании iSpring одна из главных ценностей -  удовольствие клиента от использования наших продуктов.

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

Такой процесс действует до сих пор и упрощает обработку поступающих запросов.

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

Совсем недавно у нас прошел IT Squad Meetup. На неформальной конференции выступили специалисты различных банков и технологических компаний. В онлайн-формате было до 400 слушателей, офлайн – 50, суммарное время докладов – почти 5 часов, съедено X круассанов.

Коллеги обсудили современные технологии разработки веб-приложений. В частности, в программе выступлений были технологии нагрузочного тестирования приложений, аутентификации в том числе и с помощью биометрии по новому протоколу WebAuthn, прогрессивные веб-приложения (Progressive Web Applications – PWA), управление Kubernetes, другие аспекты DevOps и не только.

Под катом вас ждут удобные видеонарезки каждого из докладов.

Особенность Spark в том, что другого такого фреймворка нет в принципе. Flink, Apache NiFi и другие инструменты закрывают не все задачи. Лично моё мнение – Spark на голову выше их всех. Он уникален, широко распространён и де-факто является стандартом индустрии обработки больших данных.

Feature request (запросы функций) – важный инструмент взаимодействия между командой разработки и конечным пользователем. Запросы позволяют более здраво рассмотреть продукт с точки зрения пользователя и определить пути улучшения его опыта при работе с продуктом.

Здравствуйте! Меня зовут Ирина, я менеджер продукта в компании Bimeister, и хочу вам рассказать о нашем опыте управления Feature requests в продукте для B2B сегмента.

Проблема

По мере развития нашего продукта и увеличения количества клиентов, а как следствие пользователей, возникает проблема роста числа замечаний, запросов на улучшение и добавления нового функционала в продукт. При этом, такие запросы могут быть очень специфичны и иметь формулировку от «переименуйте кнопку на…» до «интегрируйтесь с нашей ERP-системой». И хотя многие из таких запросов могут показаться бесполезными, а ответы на них отнимают большое количество времени, при правильном управлении они могут оказать чрезвычайно положительное влияние как на продукт, так и на отношения с пользователями.

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

В сухом остатке статья про то, как мы выбросили из своей жизни автоотбивку «Спасибо, нам важно ваше мнение». Поехали :-)

Наверняка на Хабре есть люди, уже глубоко изучившие генерацию картинок с помощью нейросетей. Но много и тех, кто ещё не разбирался, почему у Stable Diffusion в названии есть слово «диффузия» и чем разновидности нейросетей различаются.

Для тех, кто не готов забираться в глубокие дебри, но хочет в один присест наверстать всё главное, может быть полезен доклад Дмитрия Сошникова @shwars с нашего мероприятия TechTrain. Поэтому мы сделали для Хабра текстовую расшифровку (видеозапись также прилагаем).

Докладу всего полгода, но за это время нейросети успели развиться ещё сильнее. Так что, если тема вам интересна, заодно порекомендуем и наш следующий TechTrain, который пройдёт уже завтра (1 апреля): там будет целый ряд докладов про AI (в том числе новый от Дмитрия), участие бесплатно.

Далее повествование идёт от лица Дмитрия.

Сегодня расскажу о том как мы переводили "умные пайетки" на китайские микроконтроллеры Padauk и применяли Миландр в устройстве управления матрицей электромеханических цветовоспроизводящих устройств.

Весной портал технической поддержки «ДоксВижн» экстренно переехал с Zendesk на платформу ITSM 365 — всего за 3 недели. Говорят, переезд хуже пожара. Однако весной полыхало у многих — многие ИТ-службы столкнулись с вызовом, когда требовалось быстро перевести привычные сервисы на новые платформы с сохранением бизнес-процессов и функций. В этой статье я хочу рассказать, как мы выбирали новый инструмент для реализации портала технической поддержки и быстро мигрировали.

Библиотека Unified и экосистема плагинов для работы с Markdown и HTML позволит очень просто создать конвертер и подключить компоненты React. Unified преобразует контент в синтаксическое дерево, и имеет набор утилит для работы с деревом, но даже без набора утилит это простая задача, достаточно уметь перебирать свойства объекта javascript. Все это будет продемонстрировано и объяснено.В статье есть пример создания плагина и демо проект.

Всем привет! Мы разрабатываем «умные пайетки» - электромеханические цветовоспроизводящие устройства для дизайнерской одежды.

Сегодня расскажу о том, как мы напечатали наше первое платье на 3D принтере!

Как создавать быстрые и эффективные алгоритмы? В статье, на примере задачи по подсчёту уникальных IPv4 адресов, рассматриваются приёмы и методы обработки больших объёмов данных. Вы узнаете, как написать код, работающий в десятки раз быстрее и использующий в несколько десятков раз меньше памяти, чем "наивные" алгоритмы.

Вступление

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

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

Хочу подметить, что хоть в моих жилах течет дотнет, в этом примере я буду использовать Node JS, потому что так быстрее, и удобнее в плане парсинга. Чем именно удобней - я расскажу позже в статье.

Можем ли мы спарсить?

Да, к сожалению (или счастью) веб - он не однообразен, и каждый ресурс может быть уникален по своему, но в нашем деле, ключевым моментом будет то, есть ли на этом ресурсе Server-Side Rendering (SSR), или там Client-Side Rendering и важная для нас информация подтягивается позже с помощью JS.

К примеру, нативные апки на React или тот же Angular by default есть CSR. И что бы прикрутить там SSR нужно порой очень сильно попотеть.Тем не менее, большинство сайтов с топ серч результатов любой поисковой системы будут поддерживать именно SSR, потому что таков мир SEO-оптимизаций.

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

Компьютерное зрение – это увлекательная область искусственного интеллекта, имеющая огромное значение в реальном мире. Forbes ожидает, что к 2022 году рынок компьютерного зрения достигнет оборота 50 миллиардов долларов, а всех нас ждет новая волна стартапов в этой области [1]. В своей статье я хотел бы поделиться своим опытом и опытом Data Science-команды компании Accenture по созданию цифрового решения потоковой аналитики на базе компьютерного зрения.

Это третья часть из серии публикаций (первая и вторая), посвящённых разработке умных пайеток - электромеханических цветовоспроизводящих устройств для умной одежды. Сегодня расскажу о новой конструкции пайеток и какие технические решения были применены для её создания.

“Блиц, блиц, скорость без границ!” - помните этого очень смешного и очень н-е-е-е-с-п-е-ш-н-о-г-о ленивца по имени Блиц из мультфильма Зверополис? Он всплывает в памяти всякий раз, когда мы сталкиваемся с чьей-то медленной работой или реакцией. На самом деле Блицу требовалось всего 10 секунд на каждую фразу или операцию. Согласитесь, 10 секунд - не так уж и много. В реальной жизни нам часто приходится ждать куда дольше и ожидание выглядит совсем не так смешно. Ждать - неприятно и очень дорого. 

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

Недавно Сбер в статье Всё, что нам нужно — это генерация предложил интересный подход для отсеивания некачественных текстов (технического мусора и шаблонного спама). Но разве коэффициент сжатия zlib на качественных текстах не имеет нелинейной зависимости от длины сжимаемого текста? Давайте проверим.