Собрали в одном месте самые важные ссылки
читайте нас в Telegram
Данная статья будет полезна желающим ознакомиться не только с оформлением собственного пакета Python Package Index (PIP), но и с различными вспомогательными инструментами, помогающими сопровождать разработку на всех стадиях — на примере авторской работы.
Серией данных дайджестов на Habrahabr хотелось бы продолжить некогда начатую alrusdi, Dead_Angel, WarmongeR идею опубликования свежих новостей, статей, релизов из мира Python. Планируется выпускать дайджест 2 раза в месяц. Это будет не очень большие по размеру статьи с интересными (на взгляд автора) материалами из мира Python. Будут очень приветствоваться присланные актуальные материалы, которые будут добавлены в ближайший дайджест, а также люьые замечания и предложения. А теперь к делу!
В прошлой статье по верификации данных от клиента повествование было скомкано, какой-либо новой информации не присутствовало. В этой статье, скорее даже заметке, я попытаюсь подать информацию более целостно. Рассказ пойдёт о алгоритме (придумал его, когда размышлял на тему "как не дублировать игровую логику на клиенте и сервере") который позволяет избавиться от существенной части кода на стороне сервера. Применение его не безгранично, ниже описаны исключительные ситуации.
Речь пойдет о технологии, которая дает возможность реализации инструментов разработчика, подобных показанному на картинке ниже.
Blockchain — это технология, на базе которой построен Bitcoin. И если пару лет назад вся слава доставлась криптовалюте, то сегодня все чаще можно слышать смелые фразы вроде: "Forget Bitcoin, Long Live Blockchain". Активно развиваются платформы вроде Ethereum, IPFS или Overstock, которые рассматривают блокчейн не как инструмент для создания еще одной платежной системы, а как совершенно обособленную технологию, сравнимую по своей инновационности разве что с Интернетом.
В этой главе я расскажу вам, что из себя представляет блокчейн Bitcoin. Даже по сравнению с Ethereum, это жуткий анахронизм, но понимание принципов его работы вам сильно поможет, если вы решите разобраться с более сложными проектами.
Даже люди, бесконечно далекие от темы криптовалют, скорее всего слышали про майнинг. Наверное и ты, дорогой читатель, задумывался о том, чтобы включить свой игровой Pentium 4 на ночь, а утром проснуться уже богатым.
Но, как это часто случается в мире блокчейна, тех кто слышал — много, а вот тех, кто реально понимает процесс от начала до конца, — единицы. Поэтому в последней главе я пострался максимально подробно охватить все тонкости, начиная от технической реализации PoW, заканчивая рентабельностью майнинга на видеокартах.
Всем привет, сегодня поговорим про сетевое взаимодействие в онлайн играх. Да не обо всём, а о том, как исключить влияние некорректных данных на других пользователей. Все знают что сервер никогда не должен доверять клиенту, но иногда лучше на практике посмотреть где и какие данные обрабатываются на неком примере.
Metacritic — англоязычный сайт-агрегатор, собирающий отзывы о музыкальных альбомах, играх, фильмах, телевизионных шоу и DVD-дисках. (с википедии).
Использованные библиотеки: lxml, asyncio, aiohttp (lxml — библиотека разбора HTML страниц с помощью Python, asyncio и aiohttp будем использовать для асинхронности и быстрого извлечения данных). Также будем активно использовать XPath. Кто не знает, что это такое, отличный туториал.
Продолжим изучать общие принципы работы со стандартными коллекциями (модуль collections в ней не рассматривается) Python. Будут рассматриваться способы объединения и обновления коллекций с формированием новой или изменением исходной, а также способы добавлять и удалять элементы в изменяемые коллекции.
Однажды мне стало интересно, отличается ли британская и американская литература с точки зрения выбора слов, и если отличается, удастся ли мне обучить классификатор, который бы различал литературные тексты с точки зрения частоты использованных слов. Различать тексты, написанные на разных языках, довольно легко, мощность пересечения множества слов небольшая относительно множества слов в выборке. Классификация текста по категориям «наука», «христианство», «компьютерная графика», «атеизм», — всем известный hello world среди задач по работе с частотностью текста. Передо мной стояла более сложная задача, так как я сравнивала два диалекта одного языка, а тексты не имели общей смысловой направленности.
Ранее я уже публиковал статью о том, как генерировать фиктивные данные при помощи Elizabeth — библиотеки для языка программирования Python. Статья, которую вы читаете является продолжением предыдущей, потому я не буду приводить основ работы с библиотекой. Если вы пропустили статью, поленились прочитать или просто не захотели, то, вероятно, захотите сейчас, ибо эта статья предполагает, что читатель уже знаком с основами библиотеки. В этой части статьи я буду говорить о том, каким образом организовывать генерацию фиктивных данных в собственных приложениях, расскажу о нескольких, на мой взгляд, полезных особенностях библиотеки.
Если говорить об уже существующей банковской системе, то транзакция внутри какого-нибудь Альфа-банка — это просто редактирование таблицы балансов, где уменьшается число напротив одного имени и увеличивается напротив другого. В случае с межбанковскими переводами подключаются некоторые сторонние организации, например SWIFT, но, по сути, все работает примерно так же.
Транзакции — это чуть ли не самый "главный" объект в сети Bitcoin, да и в других блокчейнах тоже. Поэтому я решил, что если и писать про них целую главу, то тогда нужно рассказать и показать вообще все, что можно. В частности то, как они строятся и работают на уровне протокола.
Ниже я объясню, каким образом формируется транзакция, покажу как она подписывается и продемонстрирую механизм общения между нодами.
На днях я столкнулся с задачей отправки обновлений базы данных на определенные терминалы. Но прежде чем отправлять, мне необходимо было выяснить куда отправлять, либо откуда забирать. На первый взгляд логичнее сообщить терминалам IP-адрес сервера и забирать данные, но следующие нюансы помешали такой реализации:
Ровно год назад к нам обратились бывшие коллеги, с предложением принять участие в модификации движка VoIP оператора связи. Задача сводилась к полной переделке личного кабинета, обеспечению масштабирования системы, создания системы биллинга, LCR, мониторинга расходов пользователей, контроля длительности разговоров, аналитики по звонкам. История закончилась печально, т.к. заложенный нами расширенный функционал системы якобы не соответствовал ТЗ, никак не формализованному на бумаге и находящемуся только в головах менеджеров оператора. В связи с тем, что за разработанный функционал, который заказчику очень понравился, менеджеры платить не захотели, отношения мы разорвали. NDA и договора у нас не было, поэтому посоветовавшись с коллегами мы решили часть наработок выложить в свободный доступ. Я думаю, что это будет серия статей. И начнём пожалуй с базовых вещей и архитектуры.
Продолжаем наш рассказ о модификации движка для VoIP оператора связи.
В первой части мы рассказали о начальной структуре базы данных и настройке Asterisk для обслуживания вызовов, с мониторингом состояния вызова. В этой части мы затронем такие вещи как тарификатор, LCR, биллинг и геолокация.
Задача: для каждого объекта подсчитать количество связанных объектов, удовлетворяющих определенному условию.
Данная статья является продолжением моей статьи "Python: коллекции, часть 1: классификация, общие подходы и методы, конвертация".
В данной статье мы продолжим изучать общие принципы работы со стандартными коллекциями (модуль collections в ней не рассматривается) Python.
Сегодня же речь пойдет об использовании предметно-ориентированных языков (Domain-specific language, DSL) для решения конкретных задач с помощью Python.