«Диск-О:», сервис от Mail.ru Group, стал первым российским приложением, которое представило клиент S3. Он позволяет получить доступ к своим файлам в Amazon Cloud, MCS Cloud на Windows и macOS, используя удобный интерфейс.
Клиент необходим для быстрой загрузки документов, проектов и любого другого контента в одном окне в приложении «Диска-О:». Все загруженные файлы будут доступны на локальном диске. Читать полностью »
Там, где я работаю (в стартапе Spot.IM, размер которого находится где-то между малым и средним), Webpack используется для сборки различных проектов. После 4 лет работы над нашим основным продуктом, когда в его код внесло вклад столько народа, что и не сосчитать, время его первоначальной сборки достигло непомерных 90 секунд, а время пересборки — 14.
Речь идёт о 14 секундах, которые нужно ждать после каждого нажатия на кнопку «Сохранить».
Прибегнув к некоторым несложным оптимизациям, к таким, которые любой может применить в своём проекте, мы смогли сократить вышеприведённые цифры до 20 секунд на сборку и 1 секунды на пересборку проекта.
В этом материале я хочу рассказать о некоторых простых изменениях, внеся которые в проект можно значительно улучшить время его сборки. Обратите внимание на то, что если вы используете CreateReactApp (или какой-нибудь другой модный генератор приложений), то эта статья, возможно, не окажется для вас особенно полезной. А вот если ничем таким вы не пользуетесь — тогда то, о чём здесь пойдёт речь, может вам очень пригодиться.
Читать полностью »
Большинство менеджеров и маркетологов называют искусственным интеллектом всё подряд: пылесосы, игрушечных роботов-трансформеров и даже подбор мобильных тарифов. Это в тренде и хорошо продаётся, только одна проблема — даже учёные не рискуют говорить, что создали ИИ.
Решили разобраться в определениях: можем ли мы вообще говорить об искусственном интеллекте, чем он отличается от машинного обучения и справедливо ли презрительно поднимать брови, когда мы видим очередную рекламу с ИИ.
Читать полностью »
Привет!
Обращаем ваше внимание на долгожданную допечатку книги "Выразительный JavaScript", которая только-только пришла из типографии.
Тем, кто еще не знаком с творчеством автора книги (при всей энциклопедичности она понравится и начинающим разработчиком) — предлагаем познакомиться со статьей из его блога; в статье изложены мысли об организации расширений в языке JavaScript
Те телефоны, о которых идёт речь в заголовке, по-английски называют «feature phone». Они отличаются крайне скромными возможностями. Кроме того, они весьма доступны, так как стоят в районе $20-25. Их можно сравнить с облегчёнными версиями современных смартфонов. Такие телефоны позволяют сотням миллионов человек из развивающихся стран пользоваться веб-ресурсами.
Телефон Jio
Если в основе сайта лежат технологии, ориентированные на обеспечение высокой скорости его работы, то от этого выиграют все — и владельцы простых дешёвых телефонов, и те, кто смотрит веб-страницы со свежих мощных смартфонов.
Читать полностью »
Привет! Представляю вашему вниманию перевод статьи «How to optimize image loading on your website».
Если на сайте много красивых изображений, то это здорово, но они могут значительно ухудшить время загрузки и как результат — пострадает SEO, а многие пользователи будут закрывать сайт еще до того, как он загрузится. Нередко бывает, что несколько мегабайт изображений загружаются просто, чтобы показать слайдер на главной странице.
Представьте, что вы заходите на такой сайт через медленный мобильный интернет, это может занять очень много времени и большинство пользователей в такой ситуации просто закроют ваш сайт еще до его загрузки. Хороший способ протестировать это — воспользоваться возможностью ограничить скорость интернета через Chrome Devtools.
Проблема в том, что часто бывает так, что сам контент уже загружен, а изображения все еще загружаются. В итоге пользователь может увидеть пустое пространство там, где изображения загружаются медленно. Это явно не то, чего вы хотели бы.
Читать полностью »
Итак, вы оптимизировали самые очевидные части своей игры. Однако на самом деле это не так. Вы упустили хитрый, не совсем заметный момент: оптимизацию иерархии сцены Unity.
А что не так с иерархией? Позвольте вам кое-что показать.
Запустите Unity и откройте проект своей игры. Затем запустите игру на целевом устройстве
и подключите к ней Unity Profiler. Запишите несколько кадров во время игрового процесса.
В Unity Profiler поищите следующие неприятные маркеры профайлера:
Не нашли? Продолжайте искать, уверен, найдётся хотя бы один.
Это могут быть UpdateRendererBoundingVolumes, Physics.SyncColliderTransform или TransformChangedDispatch.
Они появятся, когда вы уже будете готовы сдаться. Они возникнут, когда вы уже наведёте курсор мыши на кнопку закрытия Profiler.
Нашли? Если да, то вам повезло. Я тоже нашёл их в одном из своих предыдущих проектов и узнал, как полностью избавиться от них. Я понял, какое зло в них скрыто…
Хотите узнать секреты производительности иерархий сцен Unity?
Читать полностью »
Давайте немного поговорим о том, как наблюдать за тем, какой объём ресурсов процессора потребляет JavaScript-код приложений. При этом предлагаю построить наш разговор вокруг компонентов — базовых строительных блоков приложения. При таком подходе любые усилия по улучшению производительности (или усилия по поиску причин замедления программ) можно сосредоточить на (хочется надеяться) маленьких самодостаточных фрагментах проекта. Я предполагаю при этом, что ваше фронтенд-приложение, как и многие другие современные проекты, создано путём сборки небольших фрагментов интерфейса, подходящих для многократного использования. Если это не так, то наши рассуждения можно будет применить и к другому приложению, но вам придётся найти собственный способ разделения своего крупномасштабного кода на фрагменты и надо будет подумать над тем, как анализировать эти фрагменты.
Недавно я столкнулся с многоминутными задержками на моей рабочей станции. После расследования выяснилось, что причина проблемы заключалась в блокировке, которая могла длиться по пять минут, во время которых источник блокировки в основном крутился в цикле из девяти инструкций.
Для меня очень важно подбирать хорошие заголовки для своих постов, но я сразу же вспомнил, что подходящее название «48 процессора заблокированы девятью инструкциями» уже занято [перевод на Хабре] постом, написанным меньше месяца назад. Количество заблокированных процессоров отличается, а цикл немного длиннее, но на самом деле всё это заставляет испытывать дежавю. Поэтому пока я объясняю новую найденную проблему, мне был хотелось поразмыслить над тем, почему это случается постоянно.
Грубо говоря, такие проблемы возникают вследствие наблюдения, которое я назову Первым законом Доусона о вычислениях: O(n2) — это магнит для алгоритмов, которые плохо масштабируются: они достаточно быстры, чтобы попасть в продакшен, но достаточно медленны, чтобы всё портить, когда туда попадут.
O(n2) в действии — данные взяты из моего случая
Читать полностью »
Давным-давно мы, в деле кэширования, всецело полагались на браузеры. Разработчики в те дни почти никак не могли на это повлиять. Но потом появились прогрессивные веб-приложения (Progressive Web App, PWA), сервис-воркеры, API Cache. Внезапно случилось так, что в руках программиста оказались широкие полномочия, власть над тем, что попадает в кэш, и над тем, как оно туда попадает. Теперь мы можем кэшировать всё, что хотим… в этом-то и кроется потенциальная проблема.
Медиа-файлы, в особенности — изображения, это то, что в наши дни является основной составной частью размера типичной веб-страницы. Со временем ситуация лишь ухудшается. Для того чтобы повысить производительность страниц, мы пытаемся кэшировать как можно большие объёмы подобных данных. Но стоит ли это делать? В большинстве случаев — не стоит. Даже учитывая то, что в нашем распоряжении теперь есть все эти новомодные технологии, нам, для того, чтобы достичь высокой производительности веб-страниц, всё ещё необходимо придерживаться одного простого правила. Оно заключается в том, что запрашивать с сервера нужно лишь то, что нужно, стремясь при этом к тому, чтобы в ответе на каждый запрос приходило бы как можно меньше данных.
Мы стремимся к тому, чтобы наши проекты вызывали бы у посетителей лишь положительные ощущения. При этом нам не хотелось бы перегружать сетевые соединения и жёсткие диски пользователей. Это значит, что пришло время дать ход некоторым классическим практическим приёмам, поэкспериментировать со стратегиями кэширования медиаданных и изучить хитрости API Cache, которые скрыты в рукаве у сервис-воркеров.
Читать полностью »
