I’ve been arbitrarily using Twitter bootstrap for my projects for years now. This week, I cracked open the lid on Google’s design framework “material design”. The following is a comparison of the two design methodologies.
Recently, I was tasked with building a method for performing data analysis as a service, as well as building a data science team that could perform those services for various industries. So, I quickly kicked off a deep exploration of the field and the technologies available in the space. I found what I learned to be very engaging and it got me thinking not only about technical challenges in performing analysis, but also managing the process of doing data science in a business context.
Partial updates are somewhat problematic in the world of RESTful applications. Currently, we use POST and PUT to write data or update it, but on sub-properties of data updates, it actually can get somewhat hard to code for when you get into the more subtle application logic and error management, let alone on datasets that are very large or have very deeply nested data structures in a single JSON object, for example.
But, regardless, PUT and POST have done a satisfactory job up until now, and nobody really needs to use PATCH in a relational context. But therein lies an interesting point: data is getting bigger, and naturally, semantic data is starting to become much more prevalent, and its URI-based. It logically follows that if data continues to become more semantic, and you’re dealing more often in deeply nested structures, you’ll need a URI-based updating method that can be more flexible than PUT and POST. But you don’t have to take my word for it, lets ask an expert.
When I talk to someone who belongs to or runs a development team, I often hear reoccurring themes in their criticisms of their existing setup or business flow. I frequently hear things like, “Our management wants XYZ to be written and delivered by this date, and that’s totally unrealistic!”, “We were stressing out last week because we found a really critical bug in production”, or “Our server did XYZ the other day, which caused downtime”, and much more.
What’s interesting about this is that, while they’re not uncommon problems, they also have pretty common solutions, and also suffer from a very common set of barriers to fixing them: they’re too deep in some technology, their team is too used to doing some other process, the code was architected in a funny way, and now there is too much legacy code to do it differently without restructuring everything.
I’m not saying that those problems aren’t valid — In fact, they’re really difficult to fix. But, if you find yourself in a position in which your application is not very old, there isn’t too much code, and your team isn’t that big yet, I guarantee that you can make your life easier in the future by doing the following three things.
There are web applications out there on the interwebs that are designed to take a website’s url, load the page, and then dress that page up with additional functionality. When trying to develop one of these on your own, you will quickly learn that there are several ways of displaying a page within another page, but only two of them are really popular: 1. displaying the page in an iFrame, and 2. rendering the contents of that page as markup in an html5 canvas.
Both methods are troublesome at first due to the fact that its hard to get the markup without having access to it from the parent DOM. So the most popular solution is to build a proxy to take in the data and return it to you before displaying. Let’s dig deeper into the idea of proxying data.
Sounds rich, doesn’t it?
I did a quick google search for RMR after reading an article about it. I realized that the real premise of RMR over MVC is that if you’re serving up remote webservices, like a RESTful service for example, there is really no good reason to maintain a view layer. Any output in a true webserver is going to be, at most, a matter of mime type and language of the output (i.e. to be able to output as xml or json at will), but not layout or templating, etc.
So, ya, OK. RMR.