Собрали в одном месте самые важные ссылки
читайте нас в Telegram
Транзакции — это чуть ли не самый "главный" объект в сети Bitcoin, да и в других блокчейнах тоже. Поэтому я решил, что если и писать про них целую главу, то тогда нужно рассказать и показать вообще все, что можно. В частности то, как они строятся и работают на уровне протокола.
Ниже я объясню, каким образом формируется транзакция, покажу как она подписывается и продемонстрирую механизм общения между нодами.
На днях я столкнулся с задачей отправки обновлений базы данных на определенные терминалы. Но прежде чем отправлять, мне необходимо было выяснить куда отправлять, либо откуда забирать. На первый взгляд логичнее сообщить терминалам IP-адрес сервера и забирать данные, но следующие нюансы помешали такой реализации:
Ровно год назад к нам обратились бывшие коллеги, с предложением принять участие в модификации движка VoIP оператора связи. Задача сводилась к полной переделке личного кабинета, обеспечению масштабирования системы, создания системы биллинга, LCR, мониторинга расходов пользователей, контроля длительности разговоров, аналитики по звонкам. История закончилась печально, т.к. заложенный нами расширенный функционал системы якобы не соответствовал ТЗ, никак не формализованному на бумаге и находящемуся только в головах менеджеров оператора. В связи с тем, что за разработанный функционал, который заказчику очень понравился, менеджеры платить не захотели, отношения мы разорвали. NDA и договора у нас не было, поэтому посоветовавшись с коллегами мы решили часть наработок выложить в свободный доступ. Я думаю, что это будет серия статей. И начнём пожалуй с базовых вещей и архитектуры.
Продолжаем наш рассказ о модификации движка для VoIP оператора связи.
В первой части мы рассказали о начальной структуре базы данных и настройке Asterisk для обслуживания вызовов, с мониторингом состояния вызова. В этой части мы затронем такие вещи как тарификатор, LCR, биллинг и геолокация.
Задача: для каждого объекта подсчитать количество связанных объектов, удовлетворяющих определенному условию.
Данная статья является продолжением моей статьи "Python: коллекции, часть 1: классификация, общие подходы и методы, конвертация".
В данной статье мы продолжим изучать общие принципы работы со стандартными коллекциями (модуль collections в ней не рассматривается) Python.
Сегодня же речь пойдет об использовании предметно-ориентированных языков (Domain-specific language, DSL) для решения конкретных задач с помощью Python.
В данной статье речь пойдёт о машинном обучении в целом и взаимодействии с датасетами. Если вы начинающий, не знаете с чего начать изучение и вам интересно узнать, что такое «датасет», а также зачем вообще нужен Machine Learning и почему в последнее время он набирает все большую популярность, прошу под кат. Мы будем использовать Python 3, так это как достаточно простой инструмент для изучения машинного обучения.
Начнем с простого определения модели StorageRoom. Как было сказано ранее, модели в чистой архитектуре очень легкие, по крайней мере, легче, чем их ORM-аналоги в фреймворках.
Раз мы следуем методологии TDD, то первое, что мы напишем, это тесты. Создадим файл tests/domain/test_storageroom.py и поместим внутри него этот код:
На примере известного эпизода из хорошего фильма.
Хочу рассказать историю миграции с Tarantool версии 1.5 на 1.6 в одном из наших проектов. Как вы думаете, нужно ли заниматься миграцией на новую версию, если и так все работает? Насколько легко это сделать, если у вас уже написано достаточно много кода? Как не затронуть живых пользователей? С какими трудностями можно столкнуться при таких изменениях? Какой вообще профит от переезда? Ответы на все вопросы можно найти в этой статье.
Коллекция в Python — программный объект (переменная-контейнер), хранящая набор значений одного или различных типов, позволяющий обращаться к этим значениям, а также применять специальные функции и методы, зависящие от типа коллекции.
Год назад мой друг Roberto Ciatti познакомил меня с концепцией, которую Роберт Мартин называет чистой архитектурой. Дядя Боб много говорит об этой концепции на конференциях и пишет о ней очень интересные статьи. «Чистая архитектура» представляет собой способ структурирования системы программного обеспечения, набор соглашений о различных слоях и ролях их участников, нечто большее, чем строгие правила.
Рождественские дни — время отложить привычные дела и вспомнить забавы — калейдоскопы, мозаики, снежинки… Кто нарисует самую красивую звезду?
Пост про то, как запустить Flask веб-приложение под uWSGI в связке с nginx
Язык программирования Python очень востребован на современном рынке, он развивается изо дня в день, и вокруг него сложилось активное сообщество. Во избежание конфликтов между разработчиками-питонистами, создатели языка написали соглашение PEP 8, описывающее правила оформления кода, однако даже там отмечено, что:
Пожалуй, можно описать с помощью программного кода почти все, что нас окружает. И хорошо, что почти, это позволяет нам не погружаться полностью в матрицу. Да, еще довольно трудно запрограммировать поведение отдельно взятых политиков, ведь как можно описать то, что не поддается логике? А вот мудрость, как противовес этому — можно.
Разбираясь со Spark Apache, столкнулся с тем, что после достаточно небольшого усложнения алгоритмов подготовки данных расчеты стали выполняться крайне медленно. Поэтому захотелось реализовать что-нибудь на C# и сравнить производительность с аналогичным по классу решением на стеке python (pandas-numpy-skilearn). Аналогичным, потому что они выполняются на локальной машине. Подготовка данных на C# осуществлялась встроенными средствами (linq), расчет линейной регрессии библиотекой extremeoptimization.
Немного людей которые никогда не играли в настольные экономические игры, такие как монополия, рынок, миллионер. Мы с друзьями играли в них дни на пролёт. Со временем, после зазубривания всех правил, и десятков сыгранных партий, хотелось чего-то большего. И мы начали рисовать игры сами. Сначала маленькие, и в большей степени копирующие возможности тех игр, что мы выдели раньше, но потом приходили и свои идеи. В конце доходило до того, что игра располагалась на 9 листах формата А4, а её правила были настолько нетерпимыми к новичкам, что кроме нас никто не мог научиться в неё играть (хотя в монополию со мной играли родители). Там было много всего, строительство, экономика, игровое взаимодействие (например подставы или взаимопомощь). Десятки видов оружия, машин. Чтобы стрелять нужны были патроны. С некоторыми ранениями можно было продолжать играть, с другими путь в больницу, и т.п.
Хочу поделиться опытом портирования проекта с Python 2.7 на Python 3.5. Необычными засадами и прочими интересными нюансами.