joseph-montanez · July 23, 2016 09:20
diff --git a/index.html b/index.html
 <!doctype html>
 <html>
 <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link href="//cdn.muicss.com/mui-latest/css/mui.min.css" rel="stylesheet" type="text/css" />
    <style>
        /** Body CSS */ html, body { height: 100%; } html, body, input, textarea, buttons { -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale; text-shadow: 1px 1px 1px rgba(0, 0, 0, 0.004); } /** Sidebar CSS */ #sidebar { background-color: #E57373; padding: 15px; } #sidebar a:link, #sidebar a:visited { color: #fff } @media (min-width: 768px) { #sidebar { position: fixed; top: 0; bottom: 0; width: 180px; height: 100%; padding-top: 30px; } } /** Content CSS */ @media (min-width: 768px) { #content { margin-left: 180px; } }
    </style>
    <script type="riot/tag" src="/posts-recent.html"></script>
    <script type="riot/tag" src="/posts-excerpt.html"></script>
    <script type="riot/tag" src="/posts-entry.html"></script>
    <script type="text/javascript" src="/posts.js"></script>
    <script src="//cdn.jsdelivr.net/riot/2.5/riot+compiler.min.js"></script>
 </head>
 <body>
 <div id="sidebar">
    <div class="mui--text-white mui--text-display1 mui--align-vertical">
        <a href="/">SHABB</a>
    </div>
 </div>
 <div id="content" class="mui-container-fluid">
    <div class="mui-row">
        <posts-recents class="mui-col-sm-10 mui-col-sm-offset-1">
            <br>
            <br>
            <div class="mui--text-black-54 mui--text-body2">PINNED POST</div>
            <div class="mui-divider"></div>
            <br>
            <div class="mui--text-headline">Riot Rocks</div>
            <div class="mui--text-black-54">By <a href="#">Joseph Montanez</a> 3 days ago</div>
            <div>Lorem ipsum dolor sit amet, consectetur adipiscing elit. In facilisis aliquam ipsum sed dignissim. Sed ac accumsan odio. Vivamus tristique dignissim neque. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nunc cursus felis nec purus condimentum vestibulum. Donec mauris nisi, sollicitudin eget iaculis id, suscipit id odio. <a href="#">Read more...</a></div>
            <br>
            <br>
            <posts-recent posts="{ recent_posts }"></posts-recent>
        </div>
    </div>
 </div>
 <script type="text/javascript">
    riot.mount('*');
 </script>
 </body>
 </html>
diff --git a/post.js b/post.js
 var authors = [
    { name: 'Joseph Montanez', slug: '/author/joseph-montanez' }
 ];

 var posts = {
    '61': {
        id: 61,
        headline: 'Redis, Riak, NodeJS, Vert.x, and NoSQL / Event Loops',
        posted_at: '2/10/2013',
        excerpt: 'Long title, I know, but for good reasoning. There are technologies out there today that can help your ' +
        'software scale, be faster and maybe even make your development time shorter. However with the tons of hype ' +
        'behind these products the temptation to use these as an all or nothing solution is not always the right choice.',
        body: 'Long title, I know, but for good reasoning. There are technologies out there today that can help your ' +
        'software scale, be faster and maybe even make your development time shorter. However with the tons of hype ' +
        'behind these products the temptation to use these as an all or nothing solution is not always the right ' +
        'choice.<br><br>' +
        'NoSql - Key / Value Store, Big Data, Document Storage<br><br>' +
        'Traditional Relational Databases such as MySQL, Postgres, MS SQL, and other all share one major trait, ACID. ' +
        'When you save data in that database, it will promise you, that it is on disk. It will also let you transact ' +
        'blocks of operations for atomic concurrency, given you the power of undo. But most of all if the server goes ' +
        'down, your data is still there and waiting to come back. Now enter NoSQL, and the reason why you will see so ' +
        'many positive benchmarks.<br><br>' +
        'NoSQL Speed<br><br>' +
        'You lose features to gain speed. Let say for example you are running a shopping cart, and you want it faster... ' +
        'Well can you afford to lose your customer data? Can you afford to lose an order, maybe 10? If the answer is no, ' +
        'then your speed gain will not be by much. The reason many of these NoSQL databases are fast is because they work ' +
        'in memory, and saved customer data will live in memory until it is written to disk which could never happen, or ' +
        'happen every few seconds. It really depends on the database. For example Redis will let you have 3 options, ' +
        'write to disk on every operation, write to disk ever x seconds, or write to disk when the OS feels like writing ' +
        'to disk. I\'ll let you guess as to which is faster.<br><br>' +
        'NoSQL Scale<br><br>' +
        'With great power comes great responsibility, and this is true for relational databases. So the question is how do you scale a database, and the answer is remove relational powers. Those lovely "joins", are out the window as the cost are too high to maintain. However you run into a bigger problem, if you have billions of records, then the likeliness of it fitting perfectly on one server is very little. You only have one option, sharding, a practice many feel is the wrong idea. Imagine you have a table split across 20 servers, and the most active data is a second thought. So 1-2 servers are always overloaded and the rest are sitting around doing nothing... You\'d need to redistribute the data across the servers in order of load, unless you have parts of the same data across multiple servers. Solutions like Redis cluster really doesn\'t address this, rather its the regular master / slave setup. Meaning all your doing is copying all data to other servers. So the idea of sharding and sharing the part of the same data across multiple servers is left to the programmers and the applications they build. This is were Riak shines, you get automatic even distribution based on the number of servers you have. There is no "master" or "slaves", which seems like a miracle, right? Every blessing has it\'s cost. Remember talking about losing data? Well imagine writing to your 20 servers, that is a very slow process if you want to promise your data is on all of them. Well with Riak you have the option to decide on how many servers its written too before you "trust" the data safe, and concurrent enough to query from. Lower numbers mean blazing fast write speeds. There are even databases that will return a write confirmation without even reaching the server.<br><br>' +
        'Event Loops<br><br>' +
        'With NodeJS taking on the role of promising better connection capacity it becomes very lucrative to want to use this platform. There is an inherit problem with building your entire application in an event loop, meaning you cannot have any blocking operations. A blocking operation is not just waiting around, but anything cpu intensive. For example calculating pi, while not IO bound, is still a blocking operation. Event loops normally run a single thread, meaning a single core, so even greater issues surface. For example if you want to utilized all cores on a CPU, you can use node cluster, but you lose the ability to share data between them. Sure there are solutions like ZeroMQ to do message passing, but it\'s another layer of obstruction, with a increased execution delay. Vert.X aims to solve some of the pains of NodeJS with some success, your application is automatically deployed on all cores. You can share data between all "verticals", but using shared maps and shared sets. Even using shared data you are still limited to immutable data. Immutable data is data that does not change over time. That doesn\'t mean the entire map or set can never change, but the key / element data has to be completely replaced when updating. There is still a problem, everything cannot be asynchronous. For example old logic that the cost to reprogram is not justifiable, or you lose a lot of performance by making a calculation asynchronous. The NodeJS solution is to deploy another process, via web server to only do blocking operations and use http to connect, or rely on a message system, like ZeroMQ or Gearman. Vert.x\'s solution is called a "worker", designed for blocking operations, allowing you to deploy you application and scale vertically with little issue, compared to NodeJS which is best for horizontal scaling. Vertical scaling is the ability to consume all resources on a single computer, if you need to scale you just continue to purchase more CPUS, RAM or Disk space. Horizontal scaling is the ability to work on multiple computers. So it is ideal to have a platform that can scale vertical and horizontal. So while Vert.x provides a great vertical scaling solution, it does allow you to build horizontal systems, which is the same amount of work in NodeJS. The problem with Vert.x is the packages available to do none blocking operations is small compared to NodeJS. In fact if you wanted to perform an async database call to MySQL, you are out of luck. You\'d need to create a worker to handle all database calls. The reason is because Vert.X runs on the JVM, so all Java libraries are accessible and almost none of them are asynchronous. So the reason MySQL calls require a "worker" is because JDBC is a blocking library.<br><br>' +
        'What To Take Away<br><br>' +
        'Just understand that while these technologies are amazing, they are best used for their specific operations. Using an all or nothing solution is the worst direction you can take. Take a step back and think about the language you use. Do you think every library you use was written in the same language? Chances are it may had been written in C, or if its a share library could have been written in any other language. So remember, use the right tool for the right job and with great power comes great responsibility.',
        slug: 'redis-riak-nodejs-vert-x-and-nosql-event-loops',
        author: authors[0]
    }
 };

 var recent_posts = [
    posts['61']
 ];
diff --git a/posts-entry.html b/posts-entry.html
 <posts-entry>
    <div class="mui--text-black-54 mui--text-body2">POST</div>
    <div class="mui-divider"></div>
    <br>
    <div class="mui--text-headline">{ post.headline }</div>
    <div class="mui--text-black-54">By <a href="{ post.author.slug }">{ post.author.name }</a> { post.posted_at }</div>
    <br>
    <div class="body"></div>
    <br>

    <script type="text/javascript">
        this.post = opts.post || {};
        this.on('mount', function () {
            this.root.querySelector('.body').innerHTML = this.post.body;
        });

    </script>
 </posts-entry>
diff --git a/posts-excerpt.html b/posts-excerpt.html
 <posts-excerpt>
    <div class="mui--text-headline">{ headline }</div>
    <div class="mui--text-black-54">By <a href="{ author.slug }">{ author.name }</a> { posted_at }</div>
    <div>{ excerpt } <a href="/blog/entry/{ slug }/{ id }">Read more...</a></div>
    <br>

    <script type="text/javascript">
        this.headline = opts.headline || '';
        this.author = opts.author || {};
        this.posted_at = opts.posted_at || '';
        this.slug = opts.slug || '';
        this.id = opts.id || '';
    </script>
 </posts-excerpt>
diff --git a/posts-recent.html b/posts-recent.html
 <posts-recent>
    <div class="mui--text-black-54 mui--text-body2">RECENT POSTS</div>
    <div class="mui-divider"></div>
    <br>
    <div each="{ posts }">
        <posts-excerpt headline="{ headline }" posted_at="{ posted_at }" excerpt="{ excerpt }"></posts-excerpt>
    </div>

    <script type="text/javascript">
        this.posts = opts.posts || [];
    </script>
 </posts-recent>
	<!doctype html>
	<html>
	<head>
	<meta charset="utf-8">
	<meta http-equiv="X-UA-Compatible" content="IE=edge">
	<meta name="viewport" content="width=device-width, initial-scale=1">
	<link href="//cdn.muicss.com/mui-latest/css/mui.min.css" rel="stylesheet" type="text/css" />
	<style>
	/** Body CSS / html, body { height: 100%; } html, body, input, textarea, buttons { -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale; text-shadow: 1px 1px 1px rgba(0, 0, 0, 0.004); } /* Sidebar CSS / #sidebar { background-color: #E57373; padding: 15px; } #sidebar a:link, #sidebar a:visited { color: #fff } @media (min-width: 768px) { #sidebar { position: fixed; top: 0; bottom: 0; width: 180px; height: 100%; padding-top: 30px; } } /* Content CSS */ @media (min-width: 768px) { #content { margin-left: 180px; } }
	</style>
	<script type="riot/tag" src="/posts-recent.html"></script>
	<script type="riot/tag" src="/posts-excerpt.html"></script>
	<script type="riot/tag" src="/posts-entry.html"></script>
	<script type="text/javascript" src="/posts.js"></script>
	<script src="//cdn.jsdelivr.net/riot/2.5/riot+compiler.min.js"></script>
	</head>
	<body>
	<div id="sidebar">
	<div class="mui--text-white mui--text-display1 mui--align-vertical">
	<a href="/">SHABB</a>
	</div>
	</div>
	<div id="content" class="mui-container-fluid">
	<div class="mui-row">
	<posts-recents class="mui-col-sm-10 mui-col-sm-offset-1">
	<br>
	<br>
	<div class="mui--text-black-54 mui--text-body2">PINNED POST</div>
	<div class="mui-divider"></div>
	<br>
	<div class="mui--text-headline">Riot Rocks</div>
	<div class="mui--text-black-54">By <a href="#">Joseph Montanez</a> 3 days ago</div>
	<div>Lorem ipsum dolor sit amet, consectetur adipiscing elit. In facilisis aliquam ipsum sed dignissim. Sed ac accumsan odio. Vivamus tristique dignissim neque. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nunc cursus felis nec purus condimentum vestibulum. Donec mauris nisi, sollicitudin eget iaculis id, suscipit id odio. <a href="#">Read more...</a></div>
	<br>
	<br>
	<posts-recent posts="{ recent_posts }"></posts-recent>
	</div>
	</div>
	</div>
	<script type="text/javascript">
	riot.mount('*');
	</script>
	</body>
	</html>
	var authors = [
	{ name: 'Joseph Montanez', slug: '/author/joseph-montanez' }
	];

	var posts = {
	'61': {
	id: 61,
	headline: 'Redis, Riak, NodeJS, Vert.x, and NoSQL / Event Loops',
	posted_at: '2/10/2013',
	excerpt: 'Long title, I know, but for good reasoning. There are technologies out there today that can help your ' +
	'software scale, be faster and maybe even make your development time shorter. However with the tons of hype ' +
	'behind these products the temptation to use these as an all or nothing solution is not always the right choice.',
	body: 'Long title, I know, but for good reasoning. There are technologies out there today that can help your ' +
	'software scale, be faster and maybe even make your development time shorter. However with the tons of hype ' +
	'behind these products the temptation to use these as an all or nothing solution is not always the right ' +
	'choice.<br><br>' +
	'NoSql - Key / Value Store, Big Data, Document Storage<br><br>' +
	'Traditional Relational Databases such as MySQL, Postgres, MS SQL, and other all share one major trait, ACID. ' +
	'When you save data in that database, it will promise you, that it is on disk. It will also let you transact ' +
	'blocks of operations for atomic concurrency, given you the power of undo. But most of all if the server goes ' +
	'down, your data is still there and waiting to come back. Now enter NoSQL, and the reason why you will see so ' +
	'many positive benchmarks.<br><br>' +
	'NoSQL Speed<br><br>' +
	'You lose features to gain speed. Let say for example you are running a shopping cart, and you want it faster... ' +
	'Well can you afford to lose your customer data? Can you afford to lose an order, maybe 10? If the answer is no, ' +
	'then your speed gain will not be by much. The reason many of these NoSQL databases are fast is because they work ' +
	'in memory, and saved customer data will live in memory until it is written to disk which could never happen, or ' +
	'happen every few seconds. It really depends on the database. For example Redis will let you have 3 options, ' +
	'write to disk on every operation, write to disk ever x seconds, or write to disk when the OS feels like writing ' +
	'to disk. I\'ll let you guess as to which is faster.<br><br>' +
	'NoSQL Scale<br><br>' +
	'With great power comes great responsibility, and this is true for relational databases. So the question is how do you scale a database, and the answer is remove relational powers. Those lovely "joins", are out the window as the cost are too high to maintain. However you run into a bigger problem, if you have billions of records, then the likeliness of it fitting perfectly on one server is very little. You only have one option, sharding, a practice many feel is the wrong idea. Imagine you have a table split across 20 servers, and the most active data is a second thought. So 1-2 servers are always overloaded and the rest are sitting around doing nothing... You\'d need to redistribute the data across the servers in order of load, unless you have parts of the same data across multiple servers. Solutions like Redis cluster really doesn\'t address this, rather its the regular master / slave setup. Meaning all your doing is copying all data to other servers. So the idea of sharding and sharing the part of the same data across multiple servers is left to the programmers and the applications they build. This is were Riak shines, you get automatic even distribution based on the number of servers you have. There is no "master" or "slaves", which seems like a miracle, right? Every blessing has it\'s cost. Remember talking about losing data? Well imagine writing to your 20 servers, that is a very slow process if you want to promise your data is on all of them. Well with Riak you have the option to decide on how many servers its written too before you "trust" the data safe, and concurrent enough to query from. Lower numbers mean blazing fast write speeds. There are even databases that will return a write confirmation without even reaching the server.<br><br>' +
	'Event Loops<br><br>' +
	'With NodeJS taking on the role of promising better connection capacity it becomes very lucrative to want to use this platform. There is an inherit problem with building your entire application in an event loop, meaning you cannot have any blocking operations. A blocking operation is not just waiting around, but anything cpu intensive. For example calculating pi, while not IO bound, is still a blocking operation. Event loops normally run a single thread, meaning a single core, so even greater issues surface. For example if you want to utilized all cores on a CPU, you can use node cluster, but you lose the ability to share data between them. Sure there are solutions like ZeroMQ to do message passing, but it\'s another layer of obstruction, with a increased execution delay. Vert.X aims to solve some of the pains of NodeJS with some success, your application is automatically deployed on all cores. You can share data between all "verticals", but using shared maps and shared sets. Even using shared data you are still limited to immutable data. Immutable data is data that does not change over time. That doesn\'t mean the entire map or set can never change, but the key / element data has to be completely replaced when updating. There is still a problem, everything cannot be asynchronous. For example old logic that the cost to reprogram is not justifiable, or you lose a lot of performance by making a calculation asynchronous. The NodeJS solution is to deploy another process, via web server to only do blocking operations and use http to connect, or rely on a message system, like ZeroMQ or Gearman. Vert.x\'s solution is called a "worker", designed for blocking operations, allowing you to deploy you application and scale vertically with little issue, compared to NodeJS which is best for horizontal scaling. Vertical scaling is the ability to consume all resources on a single computer, if you need to scale you just continue to purchase more CPUS, RAM or Disk space. Horizontal scaling is the ability to work on multiple computers. So it is ideal to have a platform that can scale vertical and horizontal. So while Vert.x provides a great vertical scaling solution, it does allow you to build horizontal systems, which is the same amount of work in NodeJS. The problem with Vert.x is the packages available to do none blocking operations is small compared to NodeJS. In fact if you wanted to perform an async database call to MySQL, you are out of luck. You\'d need to create a worker to handle all database calls. The reason is because Vert.X runs on the JVM, so all Java libraries are accessible and almost none of them are asynchronous. So the reason MySQL calls require a "worker" is because JDBC is a blocking library.<br><br>' +
	'What To Take Away<br><br>' +
	'Just understand that while these technologies are amazing, they are best used for their specific operations. Using an all or nothing solution is the worst direction you can take. Take a step back and think about the language you use. Do you think every library you use was written in the same language? Chances are it may had been written in C, or if its a share library could have been written in any other language. So remember, use the right tool for the right job and with great power comes great responsibility.',
	slug: 'redis-riak-nodejs-vert-x-and-nosql-event-loops',
	author: authors[0]
	}
	};

	var recent_posts = [
	posts['61']
	];
	<posts-entry>
	<div class="mui--text-black-54 mui--text-body2">POST</div>
	<div class="mui-divider"></div>
	<br>
	<div class="mui--text-headline">{ post.headline }</div>
	<div class="mui--text-black-54">By <a href="{ post.author.slug }">{ post.author.name }</a> { post.posted_at }</div>
	<br>
	<div class="body"></div>
	<br>

	<script type="text/javascript">
	this.post = opts.post \|\| {};
	this.on('mount', function () {
	this.root.querySelector('.body').innerHTML = this.post.body;
	});

	</script>
	</posts-entry>
	<posts-excerpt>
	<div class="mui--text-headline">{ headline }</div>
	<div class="mui--text-black-54">By <a href="{ author.slug }">{ author.name }</a> { posted_at }</div>
	<div>{ excerpt } <a href="/blog/entry/{ slug }/{ id }">Read more...</a></div>
	<br>

	<script type="text/javascript">
	this.headline = opts.headline \|\| '';
	this.author = opts.author \|\| {};
	this.posted_at = opts.posted_at \|\| '';
	this.slug = opts.slug \|\| '';
	this.id = opts.id \|\| '';
	</script>
	</posts-excerpt>
	<posts-recent>
	<div class="mui--text-black-54 mui--text-body2">RECENT POSTS</div>
	<div class="mui-divider"></div>
	<br>
	<div each="{ posts }">
	<posts-excerpt headline="{ headline }" posted_at="{ posted_at }" excerpt="{ excerpt }"></posts-excerpt>
	</div>

	<script type="text/javascript">
	this.posts = opts.posts \|\| [];
	</script>
	</posts-recent>