Skip to content

Commit

Permalink
Automatically updated on Mon Jun 1 18:54:22 UTC 2020
Browse files Browse the repository at this point in the history
  • Loading branch information
Fadi Hanna Al-Kass committed Jun 1, 2020
1 parent 8ed7e51 commit 6e96872
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion feed.xml
Original file line number Diff line number Diff line change
@@ -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.1.0">Jekyll</generator><link href="/feed.xml" rel="self" type="application/atom+xml" /><link href="/" rel="alternate" type="text/html" /><updated>2020-06-01T18:20:11+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/">&lt;p&gt;One of the early design challenges we faced when designing the &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;DSP&lt;/code&gt; (Device Service Provider) project is coming up with a plug-and-play architecture. &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;DSP&lt;/code&gt;’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 &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;DSP&lt;/code&gt;, 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?&lt;/p&gt;
<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="4.1.0">Jekyll</generator><link href="/feed.xml" rel="self" type="application/atom+xml" /><link href="/" rel="alternate" type="text/html" /><updated>2020-06-01T18:54:17+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/">&lt;p&gt;One of the early design challenges we faced when designing the &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;DSP&lt;/code&gt; (Device Service Provider) project is coming up with a plug-and-play architecture. &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;DSP&lt;/code&gt;’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 &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;DSP&lt;/code&gt;, 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?&lt;/p&gt;

&lt;p&gt;We came up with a list of functions every device –no matter how distinct– must support, and we created an interface called &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;DeviceProtocol&lt;/code&gt; that encompasses all these functions. Our interface will include functions like &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;SetDeviceConnection&lt;/code&gt;, &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;SetLogger&lt;/code&gt;, &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;Read&lt;/code&gt;, &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;Write&lt;/code&gt;, &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;GetIMEI&lt;/code&gt;, &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;SetUnit&lt;/code&gt;, &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;Acknowledge&lt;/code&gt;, &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;Reject&lt;/code&gt;, &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;Handle&lt;/code&gt;, &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;StoreRecord&lt;/code&gt;, and &lt;code class=&quot;language-plaintext highlighter-rouge&quot;&gt;Disconnect&lt;/code&gt;.&lt;/p&gt;

Expand Down

0 comments on commit 6e96872

Please sign in to comment.