diff --git a/feed.xml b/feed.xml index 09e6df4..2fa8007 100644 --- a/feed.xml +++ b/feed.xml @@ -1,4 +1,4 @@ -Jekyll2020-06-01T18:20:11+00:00/feed.xmlIQDevsTechnology Excellence RedefinedZGPS - Achieving Abstraction with Golang2020-05-30T05:00:00+00:002020-05-30T05:00:00+00:00/ZGPS%20-%20Achieving%20Abstraction%20with%20Golang<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> +Jekyll2020-06-01T18:54:17+00:00/feed.xmlIQDevsTechnology Excellence RedefinedZGPS - Achieving Abstraction with Golang2020-05-30T05:00:00+00:002020-05-30T05:00:00+00:00/ZGPS%20-%20Achieving%20Abstraction%20with%20Golang<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>