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

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



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

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

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

Примечание переводчика. После моего поста о Хостинг Кафе появились два комментария (1, 2) о том, что на HTTPS.menu нет бесплатных сертификатов, и как раз в тот день вышла статья основателя Namecheap о бесплатных SSL. Изначально статья называлась «Факты о бесплатных SSL» («The Facts About Free SSL»), однако через пару дней после публикации статью переименовали и немного отредактировали.



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

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

Мы думаем, что проверка владельца сертификата – важный вопрос, который требует особого внимания и обсуждения. Разработки последнего времени в сфере автоматизации выпуска SSL-сертификатов с технической точки зрения потрясающие. Тем не менее, следует разъяснить пользователям специфику новой модели обеспечения безопасности и то, на какие сигналы обращать внимание при принятии решений об обеспечении безопасности. Искать буквы «https» и изображение замка в адресной строке — т. е. показатели, которые традиционно считались достоверными, уже может быть и не так надежны, когда речь заходит о безопасности пользователя.

После моего недавнего выступления на MoscowJS #17 с одноимённым докладом у многих возник интерес к этому инструменту. В рамках 11-го выпуска RadioJS, Миша Башкиров bashmish рассказал, что решился попробовать его в своём новом проекте, об успешном опыте и множестве положительных эмоций. Но были озвучены вопросы и возникла дискуссия, в результате которой я решил написать эту статью, чтобы раскрыть основные тезисы с доклада и рассказать о том, что тогда не успел.
Статья ориентирована, как на профессионалов, так и на тех, кто с похожими технологиями ещё не сталкивался.
Итак, начнём.

Предположим, у вас есть данные, которые вы хотите кэшировать и отдавать, не используя тяжелые языки, как php, при этом проверяя, что пользователь аутентифицирован и имеет право на доступ к данным. Сегодня я расскажу, как, используя связку nginx lua redis, выполнить эту задачу, снять нагрузку с сервера и увеличить скорость отдачи информации сервером в десятки раз.

Сегодня мы представляем вашему вниманию адаптированную подборку инструментов (в том числе облачных) для разработчиков, которые позволяют создавать по-настоящему качественные проекты. Здесь представлены исключительно SaaS, PaaS и IaaS сервисы, предоставляющие бесплатные пакеты для разработчиков инфраструктурного ПО.

Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы, интересные материалы и IT-новости

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

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

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

К окончанию данного руководства вы получите систему из 3 серверов: балансировщик (lb) и 2 сервера приложений (app1 и app2). Балансировщик будет следить за доступностью серверов и распределять между ними траффик. Серверы приложений будут использовать комбинацию systemd и кластеризации node.js для балансировки траффика между несколькими процессами ноды на сервере. Вы сможете выкатывать код с помощью одной команды со своей машины, и при этом не будет перерывов в обслуживании или необработанных запросов.
Все это можно представить в виде схемы:

Моя серия заметок ES6 in Depth, состоящая из 24 записей, описывает большинство синтаксических изменений и нововведений в ES6. В этой публикации я подведу итог всего изложенного в предыдущих статьях, чтобы дать возможность посмотреть еще раз на всё вместе. Также я добавил ссылки на мой блог, чтобы в случае необходимости сразу же можно было посмотреть подробнее.



Я слышал, вы любите маркированные списки, так что вот вам статья со списком, который состоит из нескольких сотен элементов.

22 октября в нашем офисе прошел очередной Security Meetup. На встрече было пять докладов, посвященных различным уязвимостям. Были раскрыты такие вопросы, как реверс-инжиниринг в Enterprise и связанные с ним бизнес-процессы (на примере платежной системы Qiwi), небезопасная десериализация данных в PHP, степень надежности двухфакторной аутентификации в мобильных приложениях, работа за деньги на bug bounty, а также возможность атаки с помощью «опасного» видеофайла.

Способы «общения» компонентов

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

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



Это чем-то напоминает WI-FI в кафе, когда все могут обмениваться сообщениями со всеми, но при этом есть роутер (диспетчер), который обеспечивает существование «эфира» и отдает сообщения только тем, кому они адресованы.

Такая организация позволяет, например, «бесплатно» получить слабое связывание компонентов. Недостаток ее в том, что при росте числа компонентов и соответственно числа событий становится сложно уследить за именами событий и за тем, кому какие события нужны для правильной работы. Появляются пространства имен и имена событий из чего-то типа «Событие1» превращаются в «Состояние_приложения1.Компонент2.Событие1». И что совсем невозможно делать при такой организации это компоновать события. Например требование «сделай что-то когда событие Б возникнет после двух событий A» выливается в тонну локальных переменных, хранящих последние данные из событий и счетчики самих событий.

Эти правила впервые появились в твитах автора сценариев из Pixar, Эммы Коатс [Emma Coats]. Кстати, правило №9,– если вы застряли, сделайте список того, что не может произойти,- подойдёт для писателей, работающих в любых жанрах.

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

Введение

Многие уже успели попробовать Node.js, на мой взгляд, это очень удобный инструмент, для решения большого круга задач. Меня в Node.js, прежде всего, привлекает возможность писать код на JavaScript и большой набор встроенных модулей для решения часто возникающих задач. Если чего-то не оказалось в стандартной поставке, то огромное количество дополнительных модулей можно найти в репозитории npmjs.org

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

После изучения документации, я пришёл к выводу что, могу написать нужный мне модуль на C++ и оформить его как addon к node.js, если вам интересно познакомится с процессом создания модуля, добро пожаловать под кат.

Тимлид (aka ведущий разработчик, team leader) — один из таких «специалистов», обязанности которого многие видят по-разному. Думаю, что складываются различные представления примерно так: поработал кто-то в команде под руководством тимлида, который хорошо справлялся с задачами проектирования системы, и считает теперь, что это именно то, что должен делать тимлид; в другой же команде тимлид плохо справлялся с планированием спринтов, а с другими обязанностями более или менее, и стали считать сотрудники, что планирование — не то, чем должен заниматься тимлид.

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

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

Не так давно наткнулся на Хабре на статью под заголовком «Как подружить MS Office с Libre Office». Проблема меня зацепила, поскольку навязшее в зубах некорректное открытие файлов из одного редактора в другом уже немного замучило. При всем этом неудобстве, платить за проезд, когда у тебя проездной, смысла я не видел никогда. Поэтому в вопросе — что выбрать — платный редактор или бесплатный, ответ был ясен. Но что делать с docx'ом?

И снова здравствуйте!

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

Теперь настало время поговорить о самом интересном – как устроен сам движок извлечения информации.

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

Сообщите нам, если у вас возникли любые проблемы, создав задачу в нашем GitHub репозитории

Пытаясь разобраться с библиотекой от Facebook ReactJS и продвигаемой той же компанией архитектурой «Flux», наткнулся на просторах интернета на две занимательные статьи: «ReactJS For Stupid People» и «Flux For Stupid People». Чуть раньше я поделился с хабравчанами переводом первой статьи, настала очередь второй. Итак, поехали.

Flux для глупых людей

TL;DR Мне, как глупому человеку, как раз не хватало этой статьи, когда я пытался разобраться с Flux. Это было не просто: хорошей документации нет и многие ее части перемещаются.

Это продолжение статьи «ReactJS For Stupid People».