deploy: IQDevs/blog@ea6c5bd

feed.xml

@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="4.3.3">Jekyll</generator><link href="/feed.xml" rel="self" type="application/atom+xml" /><link href="/" rel="alternate" type="text/html" /><updated>2024-07-31T19:56:33+00:00</updated><id>/feed.xml</id><title type="html">IQDevs</title><subtitle>Technology Excellence Redefined</subtitle><entry><title type="html">ZGPS - Achieving Abstraction with Golang</title><link href="/ZGPS-Achieving-Abstraction-with-Golang/" rel="alternate" type="text/html" title="ZGPS - Achieving Abstraction with Golang" /><published>2020-05-30T05:00:00+00:00</published><updated>2020-05-30T05:00:00+00:00</updated><id>/ZGPS%20-%20Achieving%20Abstraction%20with%20Golang</id><content type="html" xml:base="/ZGPS-Achieving-Abstraction-with-Golang/"><![CDATA[<p>One of the early design challenges we faced when designing the <code class="language-plaintext highlighter-rouge">DSP</code> (Device Service Provider) project is coming up with a plug-and-play architecture. <code class="language-plaintext highlighter-rouge">DSP</code>’s main responsibility is to read data from a specific tracking device, process and store the data, or send commands and process responses. Different devices come with different protocols, though they share common traits, like they all (all the ones we now support at least) are TCP based. Devices, when connected to <code class="language-plaintext highlighter-rouge">DSP</code>, are expected to be recognized so they’re handed to the proper protocol handler. Our silver bullet here is abstraction, but then we’re using Go, and Go doesn’t have native support for abstractions. So how do we solve this?</p>
+<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="4.3.3">Jekyll</generator><link href="/feed.xml" rel="self" type="application/atom+xml" /><link href="/" rel="alternate" type="text/html" /><updated>2024-07-31T20:00:34+00:00</updated><id>/feed.xml</id><title type="html">IQDevs</title><subtitle>Technology Excellence Redefined</subtitle><entry><title type="html">ZGPS - Achieving Abstraction with Golang</title><link href="/ZGPS-Achieving-Abstraction-with-Golang/" rel="alternate" type="text/html" title="ZGPS - Achieving Abstraction with Golang" /><published>2020-05-30T05:00:00+00:00</published><updated>2020-05-30T05:00:00+00:00</updated><id>/ZGPS%20-%20Achieving%20Abstraction%20with%20Golang</id><content type="html" xml:base="/ZGPS-Achieving-Abstraction-with-Golang/"><![CDATA[<p>One of the early design challenges we faced when designing the <code class="language-plaintext highlighter-rouge">DSP</code> (Device Service Provider) project is coming up with a plug-and-play architecture. <code class="language-plaintext highlighter-rouge">DSP</code>’s main responsibility is to read data from a specific tracking device, process and store the data, or send commands and process responses. Different devices come with different protocols, though they share common traits, like they all (all the ones we now support at least) are TCP based. Devices, when connected to <code class="language-plaintext highlighter-rouge">DSP</code>, are expected to be recognized so they’re handed to the proper protocol handler. Our silver bullet here is abstraction, but then we’re using Go, and Go doesn’t have native support for abstractions. So how do we solve this?</p>
 
 <p>We came up with a list of functions every device –no matter how distinct– must support, and we created an interface called <code class="language-plaintext highlighter-rouge">DeviceProtocol</code> that encompasses all these functions. Our interface will include functions like <code class="language-plaintext highlighter-rouge">SetDeviceConnection</code>, <code class="language-plaintext highlighter-rouge">SetLogger</code>, <code class="language-plaintext highlighter-rouge">Read</code>, <code class="language-plaintext highlighter-rouge">Write</code>, <code class="language-plaintext highlighter-rouge">GetIMEI</code>, <code class="language-plaintext highlighter-rouge">SetUnit</code>, <code class="language-plaintext highlighter-rouge">Acknowledge</code>, <code class="language-plaintext highlighter-rouge">Reject</code>, <code class="language-plaintext highlighter-rouge">Handle</code>, <code class="language-plaintext highlighter-rouge">StoreRecord</code>, and <code class="language-plaintext highlighter-rouge">Disconnect</code>.</p>