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



Автор статьи, перевод которой мы сегодня публикуем, работает в Wix. Он хочет рассказать о том, как смог уменьшить размер одного бандла примерно на 80%, используя Webpack Analyzer и React Lazy/Suspense.

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

Одна из самых распространенных тем запросов, с которыми приходят к детским специалистам, это речь. Самая очевидная проблема — это когда ребенок не говорит. Вот ему год, а он молчит. Вот ему уже три, а он все равно молчит. А вот уже пять… Тут понятно, что что-то пошло не так. Есть менее очевидные проблемы, которые на самом деле тоже про речь. Например, ребенок плохо учится. Почему плохо учится? Оказывается, когда ему учительница задает вопрос, он в ответ двух слов связать не может. Или у ребенка почему-то нет друзей. И оказывается, что он просто не представляет, как со сверстниками вообще разговаривать. Ну и не разговаривает. И так далее.

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

Привет, Хабр! Представляю вашему вниманию перевод статьи «FORMALLY SPECIFYING UIS» автора Hillel Wayne.

От автора

Относительно недавно я наткнулся на статью про Инженерные методы в разработке ПО, где vasil-sd рассказал про формальную валидацию спецификаций к создаваемым программным продуктам. В качестве инструментария был использован Alloy. Одним из основных лейтмотивов в комментариях был — разобрать статью в контексте какого-нибудь современного веб проекта, потому что дорого\долго\сложно использовать формальные методы там, где все делают быстро\дешево. Так как автор ссылался на блог Hillel Wayne, где такие примеры были, я решил перевести что-то из его статей в качестве дополнения к основному тексту vasil-sd

Предупреждение:

• Все, что автор называет finite-state machine, я буду называть конечным автоматом или моделью конечного автомата.
• Часть терминологии я почерпнул из статьи, ранее мною упомянутой, об инженерном подходе к разработке. Тем не менее, тема для меня относительно новая, потому обоих авторов(как зарубежного, так и не очень) мог понять не так — не ругайтесь.

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

Ментальные модели — это простые выражения сложных процессов или отношений. Эти модели можно собирать и использовать для принятия более быстрых и качественных решений.

Вот пример: принцип Парето гласит, что около 80% всех результатов приходится на 20% усилий.

В контексте управления продуктами модель предполагает, что вместо того, чтобы потратить 100% усилий и покрыть 100% желаний клиентов, можно потратить 20% — и удовлетворить 80% желаний. Команды разработчиков постоянно прибегают к этому принципу, и результаты часто выглядят неплохо, когда 20% клиентов с более сложными кейсами не поддерживаются.

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

Этот пост — попытка достучаться до издательств. Чтобы те услышали и отнеслись к своим переводам более ответственно.

За свой путь разработчика я купил много различных книг. Книг самых разных издательств. И малых и больших. Прежде всего — больших издательств, у которых есть возможности вложиться в перевод технической литературы. Это были самые разные книги: все мы прошли или проходим через путь поиска себя. И все эти книги объединяло одно: они были переведены так, что их невозможно было читать. Со временем, конечно, привыкаешь и к переводу терминов (про себя переводя на те, которые используются повседневно) и к ломаному стилю изложения, по которому видно что этот текст взят с английского. Однако нет привычки к цене, которую просят издательства за популярные издания.

В комментарии приглашаются издательства

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

До сего дня я занимался лишь переводами интересных, на мой взгляд, статей англоязычных авторов. И вот настала пора самому что-то написать. Для первой статьи я выбрал тему, которая, я уверен, будет полезна junior-разработчикам, стремящимся дорасти до «мидлов», т.к. в ней будет разобрана схожесть/отличие JavaScript от классических языков программирования (С++, С#, Java) в плане ООП. Итак, начнём!

Общие положения парадигмы

Если мы посмотрим определение JavaScript по Википедии, то увидим следующее понятие:

JavaScript (/ˈdʒɑːvɑːˌskrɪpt/; аббр. JS /ˈdʒeɪ.ɛs./) — мультипарадигменный язык программирования. Поддерживает объектно-ориентированный, императивный и функциональный стили. Является реализацией языка ECMAScript (стандарт ECMA-262).

Как следует из этого определения, JavaScript существует не сам по себе, а является реализацией некоей спецификации EcmaScript. Помимо него, эту спецификацию реализуют и другие языки.

Существует множество поклонников старых игр. И они не прочь пустить скупую ностальгическую слезу и нет-нет, да сыграть в «Арканоид», «Пакмана» или «Принца Персии», как двадцать, тридцать, сорок или — подставьте нужное число — лет назад. DOS-box и эмуляторы — им в помощь. Да, что там, я недавно смотрел стрим самого первого 2D «Принца Персии» на Ютьюбе, где довольно молодой «стример» после прохождения очередного смертельного препятствия, смахнув со лба пот рукой, изрек: «Мне еще никогда не было так страшно в компьютерной игре». То есть, даже молодежь способна оценить хардкорность и крутизну старых игр.


Я подумал, а почему бы не создать новую игру в подобном стиле? Да, существуют различные ремейки и клоны. Также, радуют современные игры в стиле пиксель-арт. Однако, все они, как правило, повторяют квесты, механики и иногда вообще полностью левел-дизайн старых игр, по мотивам которых они сделаны. Ну либо, наоборот, предлагают совершенно новый сюжет и локации, являя собой просто визуальную стилизацию «под старину». А что, если представить, какой была бы новая часть старой игры, выйди она следом за последней из серии? Я решил такую создать.

Привет, Хаброжители! В последние годы произошел всплеск интереса к дизайн-мышлению. Мы живем в эпоху, когда банки отказываются от традиционных банковских операций и переходят на цифровые деньги. На наших глазах рождаются стартапы, которые создают новые рынки, используя дизайн-экосистемы. Современные компании осуществляют цифровую трансформацию, чтобы по максимуму использовать современные методы обработки данных и быть на шаг впереди конкурентов. Книгу-героиню нашего сегодняшнего поста следует рассматривать как настоящую рабочую тетрадь. Это не руководство в привычном смысле, где описываются процессы.
Книга скорее дает вдохновляющий импульс для внедрения чего-то нового и реализации полного потенциала дизайн-мышления. Эта книга о том, как действовать, тестировать и размышлять. Авторы помогут вам: применить различные инструменты и методы дизайн-мышления в конкретных ситуациях; создать эффективную команду; ориентировать продукт на пользователя; ввести дизайн-мышление в организациях; научиться создавать цифровую продукцию; объединить дизайн-мышление с Big Data. В выбранном нами отрывке пойдёт речь об эффективном тестировании прототипа:

Поисковая выдача на ListenNotes.com

Listen Notes — это поисковая система и база данных подкастов. Технология на самом деле очень скучная. Никакого ИИ, глубокого обучения или блокчейна. «Если вы должны объявлять о внедрении ИИ, то вы не используете Настоящий ИИ» :)

После прочтения этой статьи вы сможете повторить мой проект или легко сделать нечто подобное. Не придётся нанимать много разработчиков. Помните, когда Instagram привлёк $57,5 млн и отошёл к Facebook за $1 млрд, у них было всего 13 сотрудников — и это не только разработчики. Покупка Instagram произошла в начале 2012-го. Сейчас 2019 год, и сегодня как никогда просто создать что-то значимое с крошечной инженерной командой — даже из одного человека.

Из документации Google's Engineering Practices

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

• Стандарт код-ревью
  
• Что проверять в коде
  
• Навигация по списку изменений (CL)
  
• Скорость код-ревью
  
• Как писать комментарии
  
• Как преодолевать сопротивление

См. также Руководство автора CL, в котором даются подробные советы разработчикам, чьи коммиты проходят ревью.

TL;DR

• Чтобы добиться высокой наблюдаемости контейнеров и микросервисов, журналов и первичных метрик мало.
• Для более быстрого восстановления и повышения отказоустойчивости приложения должны применять Принцип высокой наблюдаемости (HOP, High Observability Principle).
• На уровне приложение для НОР требуется: должное журналирование, тщательный мониторинг, проверки работоспособности и трассировки производительности/переходов.
• В качестве элемента НОР используйте проверки readinessProbe и livenessProbe Kubernetes.

Это исчерпывающее руководство по обеспечению надёжности в JavaScript и Node.js. Здесь собраны десятки лучших постов, книг и инструментов.

Сначала разберитесь с общепринятыми методиками тестирования, которые лежат в основе любого приложения. А затем можно углубиться в интересующую вас сферу: фронтенд и интерфейсы, бэкенд, CI или всё перечисленное.

­­ 

На первый взгляд, Clean Architecture – довольно простой набор рекомендаций к построению приложений. Но и я, и многие мои коллеги, сильные разработчики, осознали эту архитектуру не сразу. А в последнее время в чатах и интернете я вижу всё больше ошибочных представлений, связанных с ней. Этой статьёй я хочу помочь сообществу лучше понять Clean Architecture и избавиться от распространенных заблуждений.

Привет, читатель!

Меня зовут Артём Сайгин, я веду телеграм-канал Growth Lab, в котором делюсь опытом роста IT-продуктов.

В сети много статей по веб-аналитике, но найти действительно стоящие и последовательно сгруппированные материалы нелегко.

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



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

Если я не добавил стоящий материал, свяжитесь со мной — добавлю.

Приступим!

Введение в веб-аналитику

Что такое веб-аналитика и зачем она вам нужна?
Подробное руководство по аналитике веб-трафика
Какие бывают источники трафика
Какие ошибки возникают при работе с Google Analytics и как с ними бороться
Как настраивать представления в Google Analytics — подробное руководство
18 метрик и KPI интернет-маркетинга, которые вы должны знать
Основные термины в веб-аналитике
Что такое UTM-метки и как их применять
Глоссарий: базовые понятия веб-аналитики
Что такое ROI и какие нюансы следует учитывать при его расчете
Модели атрибуции — подробный обзор и сравнение
Модели атрибуции от Google
Что такое A/A тестирование, и как его провести
6 советов начинающему веб-аналитику

Изображение: Unsplash

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

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

Новая команда для тимлида — стресс не меньший, чем новый тимлид для команды. «С чего начать, на кого положиться, кому помочь в первую очередь? Как всех запомнить, какие здесь традиции, регламенты, что если я не уложусь в испытательный срок и не заработаю доверие?» Этими вопросами задается любой тимлид на новом месте. Когда Алексей Петров (pifagor_mc) перешел в FunCorp, то также искал ответы. Нашел их и на TeamLead Conf рассказал, как максимально комфортно войти в новую компанию на позицию руководителя в первый или n-й раз. При этом комфортно будет не только вам, но и сотрудникам компании.


Алексей Петров — QA Head в FunCorp. В 19 лет увлекся тематикой IT благодаря интересу к компьютерным играм. Работает в сфере с 2005 года, а руководит — с 2010. Прошел путь от младшего тестировщика до директора по качеству.

Алан Кей — это магистр Йода для ИТишников. Он стоял у истоков создания первого персонального компьютера (Xerox Alto), языка SmallTalk и концепции «объектно-ориентированного программирования». Он уже много высказывался о своем взгляде на образование в сфере Computer Science и советовал книги тем, кто хочет углубить свои познания:

• Алан Кей: как бы я преподавал Computer Science 101
• Алан Кей: «Какие книги Вы бы посоветовали прочесть тому, кто учится на Computer Science»
• Алан Кей (и коллективный интеллект Хабра): какие книги формируют мышление тру инженера
• Алан Кей и Марвин Мински: Computer Science уже имеет «грамматику». Нужна «литература»

Недавно на Quora опять подняли эту тему и обсуждение вышло на первое место на Hacker News. Предлагаю вашему вниманию «новый» список суперстарых и фундаментальных книг по программированию и мышлению программиста от Алана Кея.

Lisp 1.5 Programmers Manual

by John McCarthy, 1962



Книга — абсолютный чемпион и пожизненный лидер рейтинга всех списков книг от Алана Кея. Этой версии языка уже нет, но книга — великолепна.

ещё восемь раритетов:

В прошлом году последние пару месяцев я потратил на подготовку к собеседованию для стажировки в Google (Google Internship). Все прошло хорошо: я получил и работу, и отличный опыт.

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