<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Python on Brave New Geek</title><link>https://bravenewgeek.com/category/python/</link><description>Recent content in Python on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 08 Mar 2017 18:14:32 -0600</lastBuildDate><atom:link href="https://bravenewgeek.com/category/python/index.xml" rel="self" type="application/rss+xml"/><item><title>A Look at Nanomsg and Scalability Protocols (Why ZeroMQ Shouldn’t Be Your First Choice)</title><link>https://bravenewgeek.com/a-look-at-nanomsg-and-scalability-protocols/</link><pubDate>Sun, 29 Jun 2014 20:44:34 -0600</pubDate><guid>https://bravenewgeek.com/a-look-at-nanomsg-and-scalability-protocols/</guid><description>&lt;p&gt;Earlier this month, I &lt;a href="http://www.bravenewgeek.com/distributed-messaging-with-zeromq/" title="Distributed Messaging with ZeroMQ"&gt;explored ZeroMQ&lt;/a&gt; and how it proves to be a promising solution for building fast, high-throughput, and scalable distributed systems. Despite lending itself quite well to these types of problems, ZeroMQ is not without its flaws. Its creators have attempted to rectify many of these shortcomings through spiritual successors &lt;a href="https://github.com/crossroads-io/libxs"&gt;Crossroads I/O&lt;/a&gt; and &lt;a href="http://nanomsg.org/"&gt;nanomsg&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;The now-defunct Crossroads I/O is a proper fork of ZeroMQ with the true intention being to build a viable commercial ecosystem around it. Nanomsg, however, is a &lt;em&gt;reimagining&lt;/em&gt; of ZeroMQ—a complete rewrite in C ((The author &lt;a href="http://250bpm.com/blog:4"&gt;explains why&lt;/a&gt; he should have originally written ZeroMQ in C instead of C++.)). It builds upon ZeroMQ’s rock-solid performance characteristics while providing several vital improvements, both internal and external. It also attempts to address many of the strange behaviors that ZeroMQ can often exhibit. Today, I’ll take a look at what differentiates nanomsg from its predecessor and implement a use case for it in the form of service discovery.&lt;/p&gt;</description></item><item><title>Real-Time Client Notifications Using Redis and Socket.IO</title><link>https://bravenewgeek.com/real-time-client-notifications-using-redis-and-socket-io/</link><pubDate>Sat, 08 Mar 2014 19:18:33 -0600</pubDate><guid>https://bravenewgeek.com/real-time-client-notifications-using-redis-and-socket-io/</guid><description>&lt;p&gt;Backbone.js is great for building structured client-side applications. Its declarative event-handling makes it easy to listen for actions in the UI and keep your data model in sync, but what about changes that occur to your data model on the server? Coordinating user interfaces for data consistency isn’t a trivial problem. Take a simple example: users A and B are viewing the same data at the same time, while user A makes a change to that data. How do we propagate those changes to user B? Now, how do we do it at scale, say, several thousand concurrent users? What about external consumers of that data?&lt;/p&gt;</description></item></channel></rss>