Abhisar's Blog

 I am going to describe my amazing introduction of Raspberry Pi. I was introduced to this amazing device a couple of weeks back as part of my training and I immediately decided to procure one and get my hands dirty with it. Well no fun comes with pain. So I decided to write a blog to make it simpler for other trying their hands for the first time. Goal :   Setup a PC with following: Message Broker supporting MQTT protocol to receive messages over WiFi from Raspberry Pi. Subscriber code to receive messages from the broker by subscribing to a channel and push the data to Mongo DB. Mongo Db to collect the data. Wifi Router: Use the home WiFi to establish connectivity between PC and Raspberry Pi Raspberry Pi - Publisher module to publish the data to message broker listening in the PC (data will not be from sensor but dummy data) Section 1 Before we start with the integration, I will start from the beginning as Raspberry Pi is absolutely new to me.   Setup 1 : Raspberry Pi Setup -  I purcha

 Previous - Beyond JSON – The Dominance When you want to write data to a file or send it over the network, you have to encode it as some kind of self-contained sequence of bytes (for example, a JSON document). Since a pointer would not make sense to any other process, this sequence-of-bytes representation looks quite different from the data structures that are normally used in memory. Thus, we need some kind of translation between the two representations. The translation from the in-memory representation to a byte sequence is called encoding (also known as serialization or marshalling), and the reverse is called decoding (parsing, deserialization, unmarshalling). Most of the programing languages have built in encoding libraries for encoding in-memory objects (JAVA:java.io.serializable, Ruby:Marshal etc.). But the issue with them is that the encoding is language specific. It’s generally a bad idea to use your language’s built-in encoding for anything other than very transient purposes.

 Previous - Beyond JSON - The Emergence By 2010, there were many JSON parsing libraries available and JSON kept gaining the popularity amongst data exchange formats. As the below graph clearly shows that JSON surpassed the popularity of XML by around 2012. The big push came with the adoption of REST architectural style along with the AJAX based frameworks like Ruby on Rails. The JavaScript  frameworks like Angular (courtesy Google in 2009) and React (courtesy Facebook 2013) acted as the catalyst to the acceptance and adoption of JSON as natural choice for data exchange. As the UI frameworks are so JavaScript heavy that JSON did fit the paradigm very well. We have been able to manage the user experience through the UI reactive frameworks. Also, one of the important consideration was the testability of JSON data dependent UI. Designers / Front End developer can independently test UI with a high level of accuracy JSON being a human readable, text based data format. Below reasons helped

  Previous -  Beyond JSON - Flashback In late nineties, there was a greater push to keep finding the technology for the distributed systems. The biggest challenge was the data exchange between the systems.  There is something happening in parallel. The emergence of WWW . In 1989, Tim Berners-Lee wrote a memo proposing an Internet-based hypertext system. Berners-Lee specified HTML and wrote the browser and server software in late 1990. Browsers became the interpreters for the HTML and we saw the success one of the first truly intended distributed system with runtime interpretation in as early as 1990. Soon people started analyzing the possibility of HTML as the data exchange format. This led to the revolution of emergence of XML . It was about to change the way we think about the distributed systems. Everyone was sure about the success and there was a need to standardize the specifications for cross platform and application data exchange. XML 1.0 specifications came around 1998. The des

A Short Story In the world where even services are becoming micro, I thought of writing a micro story. I cannot cover it in one blog so dividing it in multiple bogs as below; 1. Flashback 2. Emergence 3.  Dominance 4.  Alternates The trigger point of this article is the unquestionable dominant usage of JSON. You are looked upon with suspicion if you try proposing to even evaluate an alternate. I have been amazed with the faith in JSON we have put in many architectural solutions. There are definitely valid reasons for the faith in JSON but I feel we should always have our reasons for doing so. In this series, I have tried to identify the reasons of emergence and reasons to alternates. Before the need and emergence of the distributed systems, we were only interacting the APIs in the same memory space (The realistic Monolithic apps, not what we say in today’s vocabulary to justify and define Micro services). With the advent of distributed applications, we started delving into mechanism to

At times an application do not stop properly and keep running in background, occupying  port. Step 1: Identify the TCP process id binding to a specific port $>netstat -ano | find "8080" TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING 28268 TCP [::]:8080 [::]:0 LISTENING 28268 Step 2: Kill the process $>taskkill /F /PID 28268