Всем привет, я обычный учащийся по специальности "техник-программист". С детства увлекаюсь компьютерами, с класса 7-го начал познавать само программирование. Являюсь владельцем подписки на Яндексу Музыку уже больше года и в целом доволен сервисом (правда сейчас в плейлисте дня сплошные повторы).
Уж не помню точно, из-за чего я решил поискать официальную документацию API данного сервиса, вроде бота хотел для Telegram написать, но столкнулся с тем, что её нет… Спустя некоторое время наткнулся на issue в репозитории yandex/audio-js. Там ребятки задают точно такой же вопрос, как и я: "А где API?". Не многие горят желанием слушать музыку через браузер, они хотят приложение, но приложения под Linux тоже нет! Интегрировать к своему любимому плееру невозможно!
Тут я загорелся идеей сделать это. Естественно, мне нужно как-то работать с сервисом, городить костыли вокруг веб-приложения не вариант. Я понимал, что имея такой сервис, имея мобильные приложения и приложения под Windows (из Microsoft Store) просто невозможно не иметь своё внутреннее API для взаимодействия. Я оказался прав!
Я отдаю себе отчёт в том, что, изучая их непубличное API я роюсь в чужих грязных вещах. Ниже будут описаны различные спорные моменты, решения разработчиков и в целом то, как это написали, как они этим пользуются. Местами я был просто шокирован, но я уверен, что если они так сделали, то на это были свои причины! Не будем забывать, что это никто не должен был видеть. Так же хочу сказать, что всё написанное ниже моё мнение. Вы можете с ним согласить или нет.
How to deploy Python Telegram bot using Webhooks on Google Cloud Platform
— Напиши телеграм-бота. Сейчас даже школьники пишут, — сказала она.
— А почему бы и нет, — подумал я тогда ( — Ну, ну, — сказал бы я сейчас).
Мы сидели в Бине и за чашкой кофе обсуждали возможности тестирования идей с моделями искусственного интеллекта на близком и не очень круге друзей. Лена, моя бывшая коллега, и во всех отношениях не блондинка, только что закончившая магистратуру, рассуждала так. Создав бота, можно сэкономить силы и время на интерфейсе, сосредоточившись на ядре с машинным обучением. Согласитесь, что устоять против такой логики “спортсменки, комсомолки и просто красавицы” в то прекрасное воскресное утро было невозможно. Решено. Телеграм-бот, значит телеграм-бот.
Первым делом я залез в гугл и нашел большое число ссылок “как сделать бот за 30 минут”. Это меня настолько воодушевило, что дальше названий я не пошел и занялся созданием ядра. В самом первом приближении мне предстояло написать систему обработки поисковых запросов с использованием NLP (natural language processing). Написание ядра заняло некоторое, вполне разумное, время (все же опыт кока-колой не пропить). И через несколько дней я был готов к тому, чтобы за пару часов обернуть первую тестовую версию ядра в пару другую команд send-receive, запустив все это в Телеграме на благо моим друзьям. Но не тут-то было.
Неожиданно возник целый клубок проблем. Потратив пару дней на поиски в интернете и общение с коллегами по цеху, я понял, что очевидное не очевидно, и еще одна “инструкция” точно не повредит. Так и появилась эта статья.
В школьные годы у меня был одноклассник, который мог послушать, как работает машина во дворе, и с серьезным лицом вынести вердикт: все в порядке, или что-то сломалось, и нужно срочно бежать за новыми деталями/маслом/инструментами! Я, как абсолютный чайник в автомобильном деле, всегда слышал обычное дребезжание очередной двенашки, никаких отличий не замечая и просто молча поражаясь его слуху и скилам.
Сейчас разбираться во внутренностях автомобиля я лучше не стал, зато начал работать с обработкой звуковых сигналов и машинным обучением, и здесь мы с вами постараемся понять, а возможно ли научить компьютер улавливать в звуке работы двигателя отклонения от нормы?
Как минимум, это просто интересно проверить, а в перспективе такая технология могла бы сэкономить кучу денег автовладельцам. По крайней мере в моем представлении, под капотом критичные поломки происходят постепенно, и на ранних стадиях, многие из них можно услышать, быстро и дешево исправить, сэкономив время, деньги и без того шаткие нервы.
Ну что, пожалуй, пора перейти от слов к делу. Поехали!
Всем доброго времени суток!
Рассматривая тему пространственного разнесения, вскользь мы уже коснулись и вопросов замираний в каналах связи, и того, почему такие замирания возникают. Сегодня предлагаю поговорить об этой теме чуть более подробно.
Более того, в сегодняшней статье мы слегка коснемся вопросов пространственной корреляции MIMO каналов, которые традиционно разбираются в рамках курса профессора Хаардта "Mobile communications" (CSP), и поэтому, я думаю, такая публикация тем более не будет лишней. И, отмечу сразу, круг вопросов не ограничивается применением только в мобильной связи.
В общем, всех интересующихся тематикой беспроводной связи приглашаю к прочтению, и поехали!
Colin Slater "Fading memories". Да, сводить всё к одной теме — это, наверное, перебор, однако какой-то такой метафорой, я думаю, можно представить, что именно получает приемник после всевозможных воздействий на изначальный, информационный сигнал...
integer = 42
string = 'FORTY_TWO'
print('string number %s, or simply %d' % (string, integer))
print('string number {}, or simply {}'.format(string, integer))
print(f'string number {string}, or simply {integer}')
This PEP is driven by the desire to have a simpler way to format strings in Python. The existing ways of formatting are either error prone, inflexible, or cumbersome.Итак, у нас есть три способа решить одну задачу. Но может это дело личного вкуса и предпочтений? Возможно, но стиль вашего кода (особенно кода в проекте с большим количеством участников) точно выиграет от единообразия. В лучшем случае стоит использовать один метод форматирования строк, тогда читать код станет проще. Но какой же метод выбрать? И есть ли разница в производительности кода?
Сегодня я хочу вам рассказать о достаточно новом open-source инструменте для автоматизированного тестирования под названием Airtest. В дальнейшем я сделаю ещё несколько статей с подробным рассказом об отдельных элементах данного инструментария и как с ними работать, а сейчас у меня цель познакомить вас с ним и дать общее представление о нем.
Это первая статья из трёх. Вторая часть описывает фреймворк для распознавания изображений (Image Recognition) — AirTest, а третья и завершающая посвящена Poco — фреймворку UI автоматизации при помощи написания кода.
AirTest IDE разработан компанией NetEase и предназначен для "hard-to-automate" приложений, таких как, к примеру, игр. Собственно на них и делается основной упор разработчиками, хотя это не мешает использовать AirTest и для любых других приложений.
AirTest IDE работает под Windows, MacOS X и Linux и содержит в себе 2 фреймворка: AirTest и Poco. Данная разработка была представлена Xin Liu на Android Game Developer Summit 2018. Для написания тестов используется Python 2.7 и Python 3.3+. Такие важные вещи как поддержка запуска тестов сразу на большом количестве устройств, открытость исходного кода и бесплатность приложения, а также легкое написаное тестов — это те преимущества, которые выделяются разработчиками. Приложение может быть использовано как на Windows, так и на MacOS и позволяет автоматизировать приложения со следующих OS: Windows, iOS, Android.
AirTest Project на GitHub содержит 4 проекта: Airtest, Poco, iOS-Tangent, multi-device-runner.
Стоит также упомянуть, что NetEase предоставляет свою ферму физических устройств для автоматизированного тестирования, которая называется AirLab.
Требования функциональности и структурированности баз данных (БД), наиболее полно реализованные в реляционных системах, сейчас находятся под давлением новых требований.
Первая проблема – низкая эффективность для больших данных (big data). Источниками больших данных являются социальные сети, системы видеонаблюдения, пространственные сенсоры, биллинг и т.п. Реляционная БД (РБД) хорошо работает, если схема данных точно определена заранее, до запуска прикладного приложения. Но большие данные по своей сути трудно поддаются структурированию на этапе проектирования БД. Только по мере сбора информации, постепенно, ее структура проявляется более очевидно.
Второе – поиск, вычисление запросов в РБД с таблицами огромных размеров – это задача высокой алгоритмической сложности. Использование индексирования и хеширования хорошо работает в более-менее статичных РБД, которые в значительной степени заполняются еще до запуска системы в эксплуатацию.
Fizz, если число кратно 5 — строку Buzz, а если соблюдаются оба этих условия — FizzBuzz.
Всем привет, я python-разработчик. Последний год я работал с graphene-python + django ORM и за это время я пытался создать какой-то инструмент, чтобы сделать работу с graphene удобнее. В результате у меня получилась небольшая кодовая база graphene-framework и набор некоторых правил, чем я бы и хотел поделиться.
В Альфастраховании мы активно пользуемся "Вики", движком которого выступает Atlassian Confluence. Когда я первый раз с ним всерьез столкнулся (в попытке создать в нем контент), мне в нем не хватило "динамичности" — хотелось иметь возможность программно формировать части страниц, взаимодействовать с другими системами и т.п.
Некоторое время бился головой в разные стены, но потом увидел, что "в доме не было одной стены". Хочу поделиться опытом — как можно добавить динамики в Confluence. Надеюсь, это будет полезно тем, кто им пользуется. И, как обычно, всем любознательным.
