Сейчас доступно приличное количество материалов по написанию API на node.js. Большинство из них в виде туториалов и демо-примеров в документациях. Этого достаточно, чтобы быстро разобраться и написать что-то свое. Но в них редко найдутся детали, почему это делается именно так. А некоторые моменты и вовсе опускаются для простоты и краткости.

Это статья нацелена, чтобы заполнить некоторые пробелы, которые могли возникнуть, и в конечном счете улучшить вам сервис на node.js.

P.S. Ни в коем случае не считаю себя экспертом: есть куда расти. Но вместе с тем есть чем поделиться.

Файловая структура проекта

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

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

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

Уже давно я заглядывался на фреймворк для тестирования jest, в котором есть огромное количество всяких вкусных фишек, одна из которых — многопоточное выполнение тестов. При условии того, что у меня был проект на 5000 юнит тестов, миграция обещала быть крайне полезной. Далее я расскажу 14 простых шагов, за которых мне удалось мигрировать — пусть и с некоторыми оговорками — и что мы в результате получили. Спойлер — всё получилось очень круто.

Всем привет!

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

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

В конкурсе у нас 4 направления:

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

Раньше было принято говорить о том, что в России есть «большая тройка» операторов сотовой связи, т.е. Билайн, Мегафон и МТС. Сейчас мы говорим о «большой четвёрке», т.е. Билайн, Мегафон, МТС и Теле2. Я опущу рассказ о том, почему мы поменяли МТС на Билайн и почему сейчас не можем перейти с Билайна на связку Мегафон + Теле2 или Билайн + Теле2, не буду говорить о том, как везде всё плохо, а сразу перейду к списку проблем, к которым мы оказались не готовы внедряя виртуальную АТС (далее ВАТС) просто потому, что для нас эти вещи были не очевидны. Мы искренне верили в то, что ВАТС добавляет функционал, но на деле выяснилось, что часть функций пропадает или начинает работать иначе, наш менеджер об этом знал, но полагал, что для нас это очевидно или для него это тоже стало открытием.

Введение

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

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

Не секрет, что в Интернете размещено огромное количество статей на эту тему, но в моем случае повествование будет немного отличаться: здесь будет только наглядная практика, без определений и прочих деталей. То есть смотрим — видим — комментируем происходящее. Смотрится, на мой взгляд, все достаточно просто и наглядно, куски кода получились тоже небольшие и очень простые, готовые к быстрому использованию в собственном проекте. Мне кажется, такой подход дает достаточно широкую обзорную картину классических инструментов Android, и при написании первого приложения вместо вопросов "что мне использовать" будут более конкретные вопросы "как именно мне использовать компонент Х". А уже все подробности об этом человек сможет узнать сам — если захочет.

Переход к микросервисной архитектуре требует пересмотра подхода к разработке, тестированию, сопровождению, проектированию – иными словами, ко всем аспектам жизненного цикла программных компонентов. В этом посте мы расскажем о практиках, к которым пришла команда архитекторов Acronis на пути к лучшим API компонентов. Рассказ будет включать как постановку задачи, так и анализ ее решений. Возможно, кому-то этот пост покажется “капитанским”, кому-то будет неясно почему упустили супер-решение Х, но надеемся, что вам он будет интересен и полезен. Строителей микросервисов приглашаем под кат – почитать и оставить свои комментарии.

Это четвертая статья в серии статей по REST API:

• Введение в REST API — RESTful веб-сервисы
• Различия REST и SOAP
• Разработка REST API — что такое Contract First (контракт в первую очередь)?
• Разработка REST API — что такое Code First (код в первую очередь)?
• REST API — Что такое HATEOAS?
• Рекомендации по REST API — примеры проектирования веб-сервисов на Java и Spring

В этой статье мы продолжим знакомство с разработкой REST API и рассмотрим подход Code-First.

Разработка хорошего REST API важна для того, чтобы иметь хорошие микросервисы. Подход Code-First фокусируется на генерации контракта из кода. Это наилучший из возможных подходов?

Когда я пришел работать в эту компанию, у меня уже имелась некоторая база по ip аппаратам, нескольким серверам с asterisk и нашлепкой в виде FreeBPX. Кроме того параллельно работала аналоговая АТС Samsung IDCS500 и в общем-то была основной системой связи в компании, ip телефония работала только для отдела продаж. И все бы варилось так и дальше, но в один прекрасный день был дан указ переводить всех на IP телефонию, были оговорены сроки, закуплено оборудование и план по переводу предприятия в 21 век стал претворятся в жизнь.
Первое что начинает беспокоить в такой ситуации, это быстро нарастающее кол-во телефонных аппаратов, которыми надо как-то управлять, второе, что сильно тревожило была телефонная книга. Если с первым нам мог помочь Endpoint Manager (который кстати выпилили из последних версий FreePBX), то вот с книгой возникали некоторые вопросы:

• Во первых как обеспеспечить её точность при постоянной смене дислокации/текучести пользователей?
• Во вторых, как полностью обезличить телефоны. И не заполнять каждый раз имя контакта?

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

В Интернете довольно много примеров настройки. Но ни один из них у меня не заработал как надо. Одной из проблем с которой я столкнулся было неправильное определение линии при входящем звонке. В свое время нигде не нашел мануал для решения этой проблемы. Поэтому решил выложить свою версию инструкции здесь. Заодно и шпаргалка для себя на будущее.

Настройка GoIP

«Configurations» — «Preferences»

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

• В Time Server пропишем IP адрес NTP сервера.
• Укажем часовой пояс, у меня Time Zone: GMT+6.
• Отключим Auto Reboot. С последней версией прошивки проблемы с зависанием GSM шлюза не наблюдаются.
• Отключим IVR.

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

Что такое Makefile-ы?

Makefile — невероятно полезный инструмент автоматизации, который можно использовать для запуска и сборки приложений не только на Go, но и на большинстве других языков программирования.

Его часто можно увидеть в корневом каталоге множества Go приложений на Github и Gitlab. Он широко используются в качестве инструмента для автоматизации задач, которые часто сопровождают разработчиков.

Если вы используете Go для создания веб-сервисов, то Makefile поможет решить следующие задачи:

• Автоматизация вызова простых команд, таких как: compile, start, stop, watch и т. д.
• Управление специфичными для проекта переменными окружения. Он должен подключать файл .env.
• Режим разработки, который автоматически компилируется при изменении.
• Режим разработки, который показывает ошибки компиляции.
• Определение GOPATH для конкретного проекта, чтобы мы могли хранить зависимости в папке vendor.
• Упрощенный мониторинг файлов, например, make watch run = «go test. / ...»

Привет! Мы «Хостинг технологии» и 5 лет назад запустили VDSina — первый vds хостинг, созданный специально для разработчиков. Мы стремимся сделать его удобным, как DigitalOcean, но с русской поддержкой, способами оплаты и серверами в России. Но DigitalOcean это не только надежность и цена, это еще и сервис.

Софт от ISPsystem оказался веревкой, которая связывала нам руки на пути к крутому сервису. Три года назад мы использовали биллинг Billmanager и панель управления серверами VMmanager и быстро поняли, что оказывать хороший сервис без своей панели практически нереально.

Казалось бы, что сложного может быть в планировании своей работы? Берёшь листок бумаги, записываешь на нём задачи, делаешь — всё просто. Но в реальности планирование почему-то не работает «из коробки».



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

Сейчас расскажу, почему так происходит. А главное — какие из «250 способов все успевать» работают и за счет каких механизмов нашего мозга.

Сегодня я был изумлен тем, как обычно позитивное и дружелюбное сообщество Vue.js скатилось в печальное противостояние. Две недели назад создатель Vue Эван Ю опубликовал предложение (RFC) с новым функциональным API для компонентов в грядущем Vue 3.0. Сегодня критическое обсуждение на Reddit и аналогичные комментарии на Hacker News вызвали наплыв разработчиков в изначальный RFC с возмущениями, порой даже чересчур резкими.

Кажется, мне довелось сделать десятки презентаций для коллег, заказчиков и публичных выступлений за мою карьеру в IT. Многие годы Powerpoint как средство изготовления слайдов оставался для меня естественным и надёжным выбором. Но в этом году ситуация качественно изменилась. С февраля по май мне довелось выступить на пяти конференциях, и слайды к докладам надо было готовить в сжатые сроки, но качественно. Встал вопрос о делегировании той части работы, что касается визуального дизайна слайдов, другим людям. Как-то раз я попытался работать с дизайнером, пересылая файлы .pptx по почте, но работа превратилась в хаос: никто не знал, какая версия слайдов «самая новая», а вёрстка «ехала» по причине различия версий Powerpoint и шрифтов на наших машинах. И я решил попробовать что-то новое. Попробовал, и с тех пор не думаю возвращаться к Powerpoint.

Здравствуйте, коллеги!

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

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

ТОП3 мифов про больную спину, которые мешают людям раз и навсегда решить свою проблему.

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

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

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

Дано: старое http node.js приложение и возросшая нагрузка на него.

Стандартные решения проблемы: докинуть серверов, все переписать с 0, оптимизировать уже написанное.

Давайте попробуем пойти путем оптимизации и разобраться, как можно найти и улучшить слабые места приложения. А быть может ускориться не трогая ни строчки кода :)

Всех заинтересованных добро пожаловать под кат!