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

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

1, 2, 3

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

Цели:

1. Асинхронно загружать веб-шрифты
2. Избежать сильного пересчета положения в макете
3. Как можно быстрее загружать веб-шрифты
4. Избежать загрузки шрифтов для возвращающихся посетителей

А теперь давайте попробуем добиться наших целей поэтапно:

В последние годы крупные организации все активнее используют разнообразные веб-приложения — официальные сайты компаний и системы управления ресурсами предприятий (ERP), электронные торговые площадки, системы дистанционного банковского обслуживания, порталы государственных услуг. Корпоративные приложения на основе специализированного клиентского ПО все чаще заменяются веб-версиями и облачными сервисами. Поэтому неудивительно, что именно уязвимости веб-приложений становятся одним из основных векторов атак на корпоративные информационные системы. В данной статье представлена статистика по наиболее распространенным уязвимостям, собранная экспертами Positive Technologies в процессе работ по анализу защищенности веб-приложений в 2014 году.

Вот типичная форма подключения к вай-фаю. Она вообще-то на огромной странице с кучей иероглифов, но серая подложка помогла мне понять, что это и есть самая важная форма подключения, а остальное — справка и реклама.



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

Нет, нифига, китайский UX подразумевает, что я сначала введу телефон и нажму оранжевую кнопку (цвета иконки — и да, это кнопка!). Получу пароль и введу его во второе поле, а потом нажму зелёную кнопку. Робот сравнит телефон с паролем и пустит меня дальше. Эту форму, скорее всего, рисовал китаец.


^{А это обычная такая телефонная будка раннего космического века}

Сейчас покажу ещё несколько вещей, рождённых в стране, где квалифицированных инженеров примерно раз в двадцать больше, чем в Америке, а состояние изобретательности «советского инженера» ещё не пройдено. Я, конечно, опять продолжу свою историю и покажу интерфейсы в реальном мире — они не менее интересны с точки зрения юзабилити, нежели HCI, и не менее полезны для понимания, как можно работать с пользователем.

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

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

Проблемы ssh

При работе с удаленными серверами по ssh есть много вещей, которые могут фрустрировать, но основных проблем две, и первая из них принципиально неразрешима в рамках ssh:

1. При высоком round-trip latency (>100 ms) пользовательский ввод появляется с ощутимой задержкой, а при использовании мобильного интернета с edge (latency 1000 ms) работа становится подобна пытке
2. При временных проблемах (несколько минут) с доставкой пакетов, соединение может порваться с write failed: broken pipe, причем узнаете вы об этом только при попытке ввода или при использовании настроек вроде keepaliveinterval

Первая проблема неразрешима потому, что ssh by-design является просто транспортом для байтов, и существующие приложения на это поведение расчитывают. Поскольку ssh не пытается интерпретировать этот поток байтов, он не может осуществлять предиктивный ввод. Лично для меня именно эта проблема наиболее актуальна, поскольку мне приходится работать с серверами в европе и США, и во втором случае задержка составляет около 200 мс и является принципиально неустранимой, по крайней мере до изобретения квантовой коммуникации или чего-нибудь подобного. Вторая же проблема проявляется в наших условиях относительно редко, но всё же неприятно переустанавливать все соединения при сбоях сети (и перезапускать упавшие приложения, если они почему-то не были запущены в screen).

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

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

И вообще вели себя вызывающе с точки зрения ИТ.

При этом объём кода, нужные мощности и сложность реализации процессов росли. Дело в том, что такая деавтоматизация требует очень нехилых вложений в ИТ. Сейчас объясню на примерах, в чём дело и зачем мы так странно делаем.

Многие знают, что одно из первых, что говорят в техническом ВУЗе — забыть все, что проходили в школе. Данная рекомендация актуальна и здесь. Полезно иногда с чистого листа начать.

На данный момент все рынки автоматизированы. По этой причине какие-то экономические объяснения ценообразования являются некими рудиментами. Рулят алгоритмы + некое ручное вмешательство.

Задача каждого торгового алгоритма всегда одна и та же — принести денег владельцу. Алгоритм тем лучше, чем больше денег он в состоянии принести.

^{Изображение: Chris Liverani — Unsplash}

Это продолжение разбора темы (часть 1), захватившей мое внимание и пришедшейся по душе на Хабре. Обсуждаем проект парня, который, применив свой опыт в IT, смог заработать полмиллиона долларов.

^{Изображение: Kevin Ku — Unsplash}

На Хабре часто появляются материалы о том, как IT-специалисту сохранить и приумножить свои деньги. Неудивительно, что тема вызывает интерес и все больше дискуссий. На днях мне попалась статья парня, который, применив свои технологические навыки, смог за год заработать полмиллиона долларов. Мне кажется, его опыт может быть интересен многим (даже если отбросить тот факт, что он не первый день на бирже), поэтому я предлагаю обсудить его мысли. Но сделать это в два подхода — оригинальный пост достаточно объемный для одного хабратопика.

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

Примечание: Данный пост написан британским разработчиком и финансовым аналитиком Майклом Халлс-Муром, который является профессионалом в так называемом Quantitative trading. С нашей точки зрения информация, содержащаяся в этом топике, может быть интересна техническим специалистам и разработчикам, которые интересуются фондовым рынком и обладают навыками для создания, к примеру, успешных торговых роботов, но не знают с чего начать. Поэтому топик будет рассматриваться именно в таком контексте, кроме того, текст адаптирован к российским реалиям, соответственным образом переведены и некоторые термины. Будем рады вашим комментариям! (Поправки по переводу лучше отправлять в личных сообщениях).

Алгоритмическая торговля — является крайне сложной областью финансов, и чтобы освоить объем информации, который позволит создать свою собственную торговую систему или устроиться разработчиком в финансовую компанию или фонд, потребуется довольного много времени. Большой опыт в программировании просто необходим для успешной работы на этом рынке, как минимум алготорговец должен хорошо разбираться в таких языках, как C/C++ (в области финансов перспективен и язык Java) и Python, Matlab и R (на российском рынке набирает популярность разработанный в США TradeScript — прим. перев.).

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

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

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

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

Речь пойдет не о чудесных Граалях, продаваемых в интернете, не о высокочастотной торговле и не о «безрисковых» вложениях в мифические ТОП-20 лучших трейдеров. Только хардкор: мы проводим многочисленные торговые операции, кто-то вручную, кто-то ― автоматически, и получаем в результате этих операций положительный прирост счета при статистически значимом количестве сделок.

В нашем блоге мы много пишем о технологиях, связанных с фондовым рынком (например, соответствующих протоколах передачи данных — раз, два, три). Существует огромное количество биржевого софта, процесс создания которого довольно интересен. Ранее мы рассказывали о разработке торгового терминала SmartX, а сегодня представляем вам историю разработчиков проекта по созданию торговых роботов StockSharp.



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

Три недели назад директор по маркетингу одного из стартапов в Сан-Франциско, в который вложили средства известные инвесторы, написала мне по поводу своей презентации.

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

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

От переводчика.
Это перевод статьи Филипа Бернарда с сайта css-tricks.com. Часть статьи, содержащую описание работы с созданным им сервисом, я позволил себе опустить. Если вы найдете ошибки, просьба сообщить о них в личном сообщении.

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

Фавикон был представлен в 1999 году, в Internet Explorer 5 (источник) и стандартизирован W3C несколько месяцев спустя. Это была маленькая иконка, представляющая сайт.



С тех пор большинство настольных браузеров следуют тенденции и используют фавикон тем или иным способом. Это очень просто, не так ли? Создать маленькую картинку и добавить в любой интернет-проект, чтобы сделать его «завершённым». Ничего сложного.

Сегодня попробую осветить денежные вопросы.
Банковский счет, карты, платежи, PayPal и все такое.
Это продолжение топика HOWTO: свой бизнес в США из России, если кто пропустил.

Так как Sketch был создан специально для работы над мобильными и веб-интерфейсами, неудивительно что он стал одним из самых быстрых и гибких инструментов для прототипирования. Эти 10 советов сделают его еще более мощным средством.

Обучающий материал с ресурса Phyramid, у которых именно такая шапка сайта.



Обновив в 2014 свой сайт, мы сделали трёхмерный фон в шапке, состоящий из геометрических фигур в 3D Max. Но потом мы подумали, что было бы гораздо круче генерить его в реальном времени на JS. Сказано – сделано, и при помощи замечательного фреймворка three.js мы сделали простенькую сценку. И вот, как это было.

Замечание по стилю кода: мы сначала хотели использовать только функциональный стиль, но из-за особенностей веба и работы алгоритма переключились на ООП.