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



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

Вот основные темы, которые мы здесь раскроем:

• Разработка хорошо масштабируемых приложений, которые легко поддерживать.
• Качественное разделение конфигурационных данных и основного кода приложения.
• Использование в Node.js-приложениях процессов различных типов.

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

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

Здравствуйте, коллеги! Это блог открытой русскоговорящей дата саентологической ложи. Нас уже легион, точнее 2500+ человек в слаке. За полтора года мы нагенерили 800к+ сообщений (ради этого слак выделил нам корпоративный аккаунт). Наши люди есть везде и, может, даже в вашей организации. Если вы интересуетесь машинным обучением, но по каким-то причинам не знаете про Open Data Science, то возможно вы в курсе мероприятий, которые организовывает сообщество. Самым масштабным из них является DataFest, который проходил недавно в офисе Mail.Ru Group, за два дня его посетило 1700 человек. Мы растем, наши ложи открываются в городах России, а также в Нью-Йорке, Дубае и даже во Львове, да, мы не воюем, а иногда даже и употребляем горячительные напитки вместе. И да, мы некоммерческая организация, наша цель — просвещение. Мы делаем все ради искусства. (пс: на фотографии вы можете наблюдать заседание ложи в одном из тайных храмов в Москве).

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

Мы вновь публикуем расшифровку доклада с конференции HighLoad++ 2016, которая проходила в подмосковном Сколково 7—8 ноября прошлого года. Владимир Протасов рассказывает, как расширить функциональность NGINX с помощью OpenResty и Lua.

Всем привет, меня зовут Владимир Протасов, я работаю в Parallels. Расскажу чуть-чуть о себе. Три четверти своей жизни я занимаюсь тем, что пишу код. Стал программистом до мозга костей в прямом смысле: я иногда во сне вижу код. Четверть жизни — промышленная разработка, написание кода, который идёт прямо в продакшн. Код, которым некоторые из вас пользуются, но не догадываются об этом.

Чтобы вы понимали насколько всё было плохо. Когда я был маленьким джуниором, я пришёл, и мне выдали такие двухтерабайтные базы. Это сейчас тут у всех highload. Я ходил на конференции, спрашивал: «Ребят, расскажите, у вас big data, всё круто? Сколько у вас там базы?» Мне отвечали: «У нас 100 гигабайт!» Я говорил: «Круто, 100 гигабайт!» А про себя думал, как бы аккуратненько сохранить покерфейс. Думаешь, да, ребята крутые, а потом возвращаешься и ковыряешься с этими многотерабайтными базами. И это — будучи джуниором. Представляете себе, какой это удар?

Я знаю больше 20 языков программирования. Это то, в чём мне пришлось разобраться в процессе работы. Тебе выдают код на Erlang, на C, на С++, на Lua, на Python, на Ruby, на чем-то еще, и тебе надо это всё пилить. В общем пришлось. Точное количество посчитать так и не удалось, но где-то на 20 число потерялось.

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

В очередной статье нашего цикла публикаций, посвященного интернет-разведке, рассмотрим, как операторы продвинутого поиска Google (advanced search operators) позволяют быстро находить необходимую информацию о конкретном человеке.

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

В этой статье я описал создание в AWS состоящего из трех нод кластера Docker Swarm и подключение к нему общего для всех нод реплицируемого тома GlusterFS.

Продолжаем цикл статей о том, как мы постигали ES в процессе создания Ambar. Первая статья цикла была о Хайлайтинге больших текстовых полей в ElasticSearch.

В этой статье мы расскажем о том как заставить ES работать быстро с документами более 100 Мб. Поиск в таких документах при подходе "в лоб" занимает десятки секунд. У нас получилось уменьшить это время до 6 мс.

Заинтересовавшихся просим под кат.

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

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

В этом хабе мы расскажем вам о своем уникальном опыте разработки высокоскоростного интерфейса TWIME для Московской биржи, объясним, почему нам так важна низкая latency (время отклика) и как ее сократить. Надеемся, в заключении вам станет немного понятнее, почему Московская биржа более технологична в некоторых областях, чем, к примеру, такие гиганты High Load как Nginx, VK или MailRu.

Доброго времени суток, мой дорогой друг. В сети, да и на Хабре, есть множество статей на тему создания своего input type=«file», но все они отличаются большим количеством костылей и большим количеством кода, что, как мне кажется, не есть хорошо. Ибо, как бы это не было парадоксально, меньше — лучше.

В одном из проектов компании Itseez, связанных с компьютерным зрением, мы используем Raspberry Pi для обработки видео потока с веб-камеры, и недавно столкнулись с проблемой записи видео на флеш-карту. Трудность состояла в том, что ресурсы ЦП съедались другими более важными задачами, однако сохранять видео все же было нужно. Причем предпочтений, каким кодеком сжимать и какой формат использовать, не было, лишь бы это никак не сказывалось на fps (количестве кадров в секунду). Перепробовав большое число программных кодеков от RAW до H.264 (использовалась обертка OpenCV над FFmpeg), пришли к выводу, что ничего из этого не выйдет, т.к. при высокой нагрузке fps проседал с 20 до 5 кадров в секунду, при том что картинка – черно-белая с разрешением 320x240. Немного погуглив, выяснили, что в процессоре Raspberry Pi есть аппаратный кодер с поддержкой стандарта H.264 (насколько мне известно, лицензия приобретена только для него). Плюсом ко всему было то, что взаимодействие с кодером реализовано по стандарту OpenMAX, поэтому было решено взяться за написание кода с использованием OpenMAX, и посмотреть, что из этого получится. Получилось, кстати, очень даже недурно!

Один итальянский магазинчик нащупал новые способы использования Телеграма (и ранее WhatsApp'а), установив его на одноплатный миниатюрный компьютер Raspberry Pi. Как выясняется, мессенджер можно использовать для удалённого общения с собственной техникой. Ниже – перевод статей (1, 2) с сайта Instructables.com. Если есть уточнения по переводу, напишите об этом в комментариях.

Введение

«МойОфис» работает на большинстве современных платформ: это Web-клиент, настольные версии приложения для Windows, MacOS и Linux, а также мобильные приложения для iOS, Android, Tizen. И если в разработке компьютерных приложений уже давно есть основные правила подхода к дизайну интерфейсов, то при создании приложений для мобильных устройств требуется отдельная проработка многих особенностей.

Во время собеседований на роль linux/unix администратора во многих IT-компаниях спрашивают, что такое load average, чем nginx отличается от apache httpd и что такое fork. В этой статье я постараюсь объяснить, что рассчитывают услышать в ответ на эти вопросы, и почему.

Здесь важно очень хорошо понимать основы администрирования. В идеальной ситуации при постановке задачи системному администратору выставляют ряд требований. Если же ситуация не идеальная, то, по сути, требование к администратору одно: «Хочу, чтобы всё работало». Иными словами, сервис должен быть доступен 24/7 и, если какое-то решение не удовлетворяет этим требованиям (масштабирование и отказоустойчивость относятся к доступности), то можно сказать, что администратор плохо сделал свою работу. Но если разные решения двух администраторов работают 24/7, как понять, какое из них лучше?

Хороший системный администратор при выборе решения при заданных требованиях ориентируется на два условия: минимальное потребление ресурсов и их сбалансированное распределение.

Вариант, когда одному специалисту нужно 10 серверов для выполнения задания, а второму всего 2, мы рассматривать не будем, что тут лучше – очевидно. Далее под ресурсами я буду понимать ЦПУ (cpu), ОЗУ (ram) и диск (hdd).

Давайте рассмотрим ситуацию: один администратор создал решение, которое требует 10% cpu, 5% ram и 10% hdd от всего вашего оборудования, а второй использовал для этого 1% cpu, 40% ram и 20% hdd. Какое из этих решений лучше? Тут все становится уже не так очевидно. Поэтому хороший администратор всегда должен уметь грамотно подобрать решение, исходя из имеющихся ресурсов.

Никто не любит длинные вступления, поэтому сразу к сути.
В данной импровизированной лаборатории я хотел бы осветить работу с сетями в GNU/Linux
и рассмотреть следующие темы:

1. Изучаем vlan. Строим сеть между vm1, vm2 в одном vlan. Пингуем, ловим пакеты, изучаем заголовки.
2. Разбиваем vm1 vm2 на разные vlan. Настраиваем intervlan routing с помощью R1.
3. Iptables. Настраиваем маскарад. Имитируем выход во внешние сети.
4. Iptables. Настраиваем port forwarding для сервисов на vm1 и v2, которые находятся за NAT.
5. Iptables. Настраиваем security zones. Изучаем tcp сессии.

З.Ы. все люди ошибаются, я открыт для ваших комментариев, если я написал какую-то глупость, готов ее исправить!

Надо сказать, что многопоточность (сoncurrency) в iOS всегда входит в вопросы, задаваемые на интервью разработчикам iOS приложений, а также в число топ ошибок, которые делают программисты при разработке iOS приложений. Поэтому так важно владеть этим инструментом в совершенстве.
Итак, у вас есть приложение, оно работает на main thread (главном потоке), который отвечает за выполнение кода, отображающего ваш пользовательский интерфейс (UI). Как только вы начинаете добавлять к вашему приложению такие «затратные по времени» куски кода, как загрузка данных из сети или обработка изображений на main thread (главном потоке), то работа вашего UI начинает сильно замедляться и даже может привести к полному его «замораживанию».



Как можно изменить архитектуру приложения, чтобы таких проблем не возникало? В этом случае на помощь приходит многопоточность (сoncurrency), которая позволяет одновременно выполнять две или более независимые задачи (tasks): вычисления, загрузку данных из сети или с диска, обработку изображений и т.д.

— Здравствуйте. Скажите, сколько стоит сделать приложение типа Uber?

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

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

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

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

В декабре 2016 года мы с товарищем начали заниматься новым проектом — системой сбора-индексации-поиска по документам. Система построена вокруг ElasticSearch (далее — ES), который мы используем как основной движок для полнотекстового поиска.

Ценными данными, приобретенными в ходе работы над проектом мы бы хотели поделиться с читателями в цикле статей про ES. Начнём с основы любого поисковика — подсветки результатов поиска (далее — хайлайтинг).

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

Одним из ключевых требований к нашей поисковой системе была возможность быстро и эффективно работать с большими файлами (более 100 Мб). В статье мы расскажем как добиться высокой производительности от ES при хайлайтинге больших полей документа.

На скриншоте ниже показано как работает подсветка результатов поиска в нашем проекте.

Привет, друзья! Я тут проанализировал 2ТБ кода и получил самые популярные слова в разных языках программирования. Результаты можно посмотреть в виде облаков тегов и простым списком:


Сайт находится здесь, а его исходники можно почитать на гитхабе.

Под катом описано в деталях о том как собирались данные, как строился сайт и как укладывались облака. И немножко наблюдений.

Приятного чтения!