Geo-spatial in-memory caching using Rtree

Adam Lev-Libfeld

A long distance runner, a software architect, an HPC nerd (order may change).

Latest posts by Adam Lev-Libfeld (see all)

Having to save a lot of geo-spatial data is a task rarely one passes without being scared for one’s life. Whether you are using a DB like postGIS, an in-memory data store like geoRedis or some other tool, handling geo-spatial data usually mean using RTree. Using RTree directly can ave some very positive effects on your system performance, so we thought we’ll let you in on this industry secret. Continue reading “Geo-spatial in-memory caching using Rtree”

Geo-spatial in-memory caching using Rtree

better event-driven programming using flexible state

Adam Lev-Libfeld

A long distance runner, a software architect, an HPC nerd (order may change).

Latest posts by Adam Lev-Libfeld (see all)

This is a true relic- the few who can spend the time and read it will be rewarded with the gift of understanding state. Using the complex example of…. a calculator:

At first glance, this approach seems to work just fine. Indeed, when you launch the calculator (available for download at <www.cuj.com/code>), you will certainly find out that most of the time it correctly adds, subtracts, multiplies, and divides. What’s there not to like? However, play with the application for a while longer, and you’ll discover many corner cases in which the calculator provides misleading results, freezes, or crashes altogether.

Source: Who Moved My State? | Dr Dobb’s

Link

Andrew Montalenti – streamparse: real-time streams with Python and Apache Storm – PyCon 2015 – YouTube

Adam Lev-Libfeld

A long distance runner, a software architect, an HPC nerd (order may change).

Latest posts by Adam Lev-Libfeld (see all)

A nice introduction to one the backbone tools we use here at Tamar. Streamparse allows us to rapidly transform regular python code to a  apache storm runable  topology.

Link

Breaking the monolith – How to design your system for both flexibility and scale – Part 2: The Cathedral & The Bazaar

Adam Lev-Libfeld

A long distance runner, a software architect, an HPC nerd (order may change).

Latest posts by Adam Lev-Libfeld (see all)

This post is part of a series. you’d probably like to read it from the beginning. You may also be interested in the next part of the series.

 

As a paraphrase on Eric Raymond’s famous book under the same title (O’reilly ,open format) let us, for a moment, think of the church as a computing system. The  service (no pun intended) is led by the priest, and has a single, general, output, it is very reliable (when comparing to other medieval services) but given under very strict terms (start time, end time, location, donation). If you don’t like your town’s priest, the next best option (if you are a medieval peasant)  probably involved some serious walking and certainly was not the safest things you could do in your day off (how’s that for a captive audience?) .

The Bazaar, On the other hand is a whole different animal Continue reading “Breaking the monolith – How to design your system for both flexibility and scale – Part 2: The Cathedral & The Bazaar”

Breaking the monolith – How to design your system for both flexibility and scale – Part 2: The Cathedral & The Bazaar

Breaking the monolith – How to design your system for both flexibility and scale – Part 1: The monolith is broken

Adam Lev-Libfeld

A long distance runner, a software architect, an HPC nerd (order may change).

Latest posts by Adam Lev-Libfeld (see all)

Every start-up gets to this point. At first the design was perfect. Perfect for the MVP, and you know what? it was even perfect for the full prototype. Then things didn’t went as planned – some adjustments were made for the test phase product, and then again for the first user group of the soft release, which were (of course) nothing next to the changes you did after the user results came back. Now you have a deployment to a big (and paying) client and the entire thing is out of whack – it now takes eight fully trained engineers and half of an EC2 Region just to keep the whole thing running in quarter speed during the on-site integration phase. You became too big too fast, and you NEED a redesign. Continue reading “Breaking the monolith – How to design your system for both flexibility and scale – Part 1: The monolith is broken”

Breaking the monolith – How to design your system for both flexibility and scale – Part 1: The monolith is broken