Unidata Developer's Blog Unidata Developer's Blog 2020-01-06T17:39:34-07:00 Apache Roller Contributor License Agreement for Unidata Projects Ryan May 2017-09-28T15:18:03-06:00 2017-09-28T15:18:03-06:00  Unidata Contributor License Agreement (CLA).</p>  <a href="">Unidata Contributor License Agreement (CLA)</a>. This agreement is based on a template from the <a href="">Harmony Agreements</a> project, whose goal is to standardize CLA's within the Open Source community.</p> <h2>What is a Contributor License Agreement?</h2> <p:</p> <ul> <li>You retain the ownership of the copyright to your contribution</li> <li>You grant Unidata the right to use your contribution in perpetuity</li> </ul> <p.</p> <p.</p> <h2>How it Works</h2> <p>When contributing using a Pull Request on GitHub, the following message will present itself, using <a href="">CLA Assistant</a>, as a comment on the pull request:</p> <p><img src="/blog_content/images/2017/20170927_cla1.png" alt="Unsigned CLA" /></p> <p>Contributors can click on the yellow "CLA not signed yet" badge, which will take them to a copy of the CLA. Contributors are asked to provide a little bit of information about themselves (for legal purposes):</p> <p><img src="/blog_content/images/2017/20170927_cla2.png" alt="CLA page" /></p> <p>Once the "I Agree" button is clicked, the browser will return to the original pull request page, but now the comment has been updated:</p> <p><img src="/blog_content/images/2017/20170927_cla3.png" alt="Signed CLA" /></p> <p>Contributors will only be asked to electronically sign once (unless the CLA is updated), and the agreement applies to all GitHub repositories hosted under the Unidata organization.</p> <p>For more information about CLAs, see these resources:</p> <ul> <li><a href="">Harmony Agreements</a></li> <li>"Producing OSS" has a section on <a href="">Contributor Agreements</a></li> <li>A more <a href="">detailed blog post</a> by Julien Ponge about CLAs</li> </ul> <h2>About the Contributor License Agreement</h2> <p>Unidata's CLA comes from <a href="">Project Harmony</a>, which is a community-centered group focused on contributor agreements for free and open source software.</p> <p>The document you are reading now is not a legal analysis of the CLA. If you want one of those, please talk to your lawyer. This is a description of the purpose of the CLA.</p> <h3>Why is a signed CLA required?</h3> <p>The license agreement is a legal document in which you state you are entitled to contribute the code/documentation.</p> <p.</p> <p.</p> <h3>Am I giving away the copyright to my contributions?</h3> <p.</p> <h3>Can I withdraw permission to use my contributions at a later date?</h3> <p>No. This is one of the reasons we require a CLA. No individual contributor can hold such a threat over the entire community of users. Once you make a contribution, you are saying we can use that piece of code forever.</p> <h3>Can I submit patches without having signed the CLA?</h3> <p>No. We will be asking all new contributors and patch submitters to sign before they submit anything.</p> <p class="quote"> This CLA explanation is based on <a href="">Django Contributor License Agreement Frequently Asked Questions</a> (copyright Django Software Foundation. <a href="">CC-BY</a>) The content has been modified slightly to reflect situations specific to Unidata. </p> DAP4 Commentary: DDX Lexical Elements Dennis Heimbigner 2012-03-27T18:00:50-06:00 2012-03-28T11:06:15-06:00 This document describes the lexical elements that occur in the DAP4 grammar. <p> Within the <a href=""> Relax-NG (rng) DAP4 grammar</a>, there are markers for occurrences of primitive type such as integers, floats, or strings. The markers typically look like this when defining an attribute that can occur in the DAP4 DDX. </p><pre><attribute name="namespace"><data type="string"/></attribute></pre>. <ol> <li> Constants, namely: string, float, integer, and character. </li><li> Identifiers </li></ol> <p> The specification is written using the <a href=""> ISO/IEC 9945-2:2003 Information technology -- Portable Operating System Interface (POSIX) -- Part 2: System Interfaces</a>. This is the extended Posix regular expression specification. </p><p> I have augmented it in the following ways. </p><ol> <li>Names are assigned to regular expressions using the notation <pre>name = regular-expression</pre> <p> </p></li><li>Named expressions can be used in subsequent regular expressions by using the notation {name}. Such occurrences are equivalent to textually substituting the expression associated with name for the {name} occurrence: More or less like a macro. </li></ol> <h4>DAP4 Lexical elements</h4> Notes: <ol> <li>The definition of {UTF8} is deferred to the next section. <p> </p></li><li>Comments are indicated using the "//" notation. <p> </p></li><li>Standard xml escape formats (&xDD) are assumed to be allowed anywhere. </li></ol> <p> <b>Basic character set definitions</b> </p><pre>CONTROLS = [\x00-\x1F] // ASCII control characters<br />WHITESPACE = [ \r\t\f]+<br />HEXCHAR = [0-9a-zA-Z]<br />// ASCII printable characters<br />ASCII = [0-9a-zA-Z !"#$%&'()*+,-./:;<=>?@[\\\]\\^_`|{}~]<br /></pre> <p> <b>Ascii characters that may appear unescaped in Identifiers</b><br /> This is assumed to be basically all ASCII printable characters except the characters ' ', '.', '/', '"', ''', and '&'. Occurrences of these characters are assumed to be representable using the standard xml '&xx;' notation. </p><pre>IDASCII = [0-9a-zA-Z!#$%'()*+,-:;<=>?@[\\\]\\^_`|{}~]<br /></pre> <p> <b>The numeric classes: integer and float</b><br /> </p><pre>INTEGER = {INT}|{UINT}|{HEXINT}<br />INT = [+-][0-9]+{INTTYPE}?<br />UINT = [0-9]+{INTTYPE}?<br />HEXINT = {HEXSTRING}{INTTYPE}?<br />INTTYPE = ([BbSsLl]|"ll"|"LL")<br />HEXSTRING = (0[xX]{HEXCHAR}+)<br /><pre></pre><br />FLOAT = ({MANTISSA}{EXPONENT}?)|{NANINF}<br />EXPONENT = ([eE][+-]?[0-9]+)<br />MANTISSA = [+-]?[0-9]*\.[0-9]*<br />NANINF = (-?inf|nan|NaN)<br /></pre> <p><b>The Character classes</b><br /> </p><pre>STRING = ([^"\&]|{XMLESCAPE})*<br />CHARACTER = ([^'\&]|{XMLESCAPE})<br /></pre> <p> Note that the character type only supports ASCII characters because it can only hold a single 8-bit byte. </p><p> <b>The Identifier class</b><br /> </p><pre>ID = {IDCHAR}+<br />IDCHAR = ({IDASCII}|{XMLESCAPE}|{UTF8})<br />XMLESCAPE = &x{HEXCHAR}{HEXCHAR};<br /></pre> <p> Note that the above lexical element classes are not disjoint. For example, the sequence of characters 1234 can be either an identifer,a float, or an integer. So the order of testing is assumed to be this. </p><ol> <li>INTEGER </li><li>FLOAT </li><li>ID </li><li>STRING </li></ol> <h4>UTF-8 Character Encodings</h4> We discuss UTF-8 character encoding in the context of this document. <a href=""></a>. <p> The most correct (validating) version of UTF8 character set is as follows. </p><pre>UTF8 = ([\xC2-\xDF][\x80-\xBF]) <br /> | (\xE0[\xA0-\xBF][\x80-\xBF]) <br /> | ([\xE1-\xEC][\x80-\xBF][\x80-\xBF]) <br /> | (\xED[\x80-\x9F][\x80-\xBF]) <br /> | ([\xEE-\xEF][\x80-\xBF][\x80-\xBF]) <br /> | (\xF0[\x90-\xBF][\x80-\xBF][\x80-\xBF]) <br /> | ([\xF1-\xF3][\x80-\xBF][\x80-\xBF][\x80-\xBF]) <br /> | (\xF4[\x80-\x8F][\x80-\xBF][\x80-\xBF])<br /></pre> The lines of the expression cover the UTF8 characters as follows: <ol> <li> non-overlong 2-byte </li><li> excluding overlongs </li><li> straight 3-byte </li><li> excluding surrogates </li><li> straight 3-byte </li><li> planes 1-3 </li><li> planes 4-15 </li><li> plane 16 </li></ol> <p> Note that ASCII and control characters are not included. </p><p> The above reference also defines some alternative regular expressions. </p><p> The most relaxed version of UTF8 is this. </p><pre>UTF8 = ([\xC0-\xD6].)<br /> |([\xE0-\xEF]..)<br /> |([\xF0-\xF7]...)<br /></pre> <p> The partially relaxed version of UTF8 is this. </p><pre>UTF8 = ([\xC0-\xD6][\x80-\xBF]) <br /> | ([\xE0-\xEF][\x80-\xBF][\x80-\xBF]) <br /> | ([\xF0-\xF7][\x80-\xBF][\x80-\xBF][\x80-\xBF])<br /></pre> <p> We deem it acceptable to use this last relaxed expression for validating UTF-8 character strings. </p> DAP4 Commentary: DAP4 Grammar Dennis Heimbigner 2012-03-27T16:50:24-06:00 2012-03-27T16:50:24-06:00 [Version: 1.0] <p>' <a href='%20'> implied grammar</a> and from comments from others and from a comparison with the <a href=''> xsd grammar.</a> </p><h4>Differences with DAP4 xsd Grammar</h4> I converted the <a href=''> xsd grammar</a> to an equivalent <a href=''> relax-ng (rng) grammar.</a> <p> One major difference I see is in dimension handling. </p><ul> <li> I just used the name "dimension" rather than "shareddimension". For me, all dimensions (except anonymous ones) are shared. <p> </p></li><li> The xsd separates out scalars from arrays. I always allowed the dimensions for a variable to be optional to handle the scalar case. <p> </p></li><li> I attempted to be as consistent as possible, so I allowed any type including sequences and structures to be dimensioned. (but see <a href=''>previous commentary</a>). <p> </p></li><li> The dimensions of a variable are currently specified in the rng grammar as a sequence of elements named "Dimension" contained in the "variables" element type. </li></ul> Other differences: <ul> <li> The Dataset element in the xsd has a couple of extra attributes. I added these. <p> </p></li><li> The xsd appears to allow attributes to themselves have attributes. This needs discussion. <p> </p><p> </p></li><li> The URL basetype is in the xsd. But I do not see the justification for keeping it. <p> </p></li><li> It appears that the Dataset contains a top level <group> declaration. I chose to treat the Dataset itself as the top-level group. <p> </p></group></li><li> Attribute declarations appear to have their own "namespace" attribute. Not sure why this is needed. <p> </p></li><li> I do not understand the purpose of the "NewAttribute" attribute. <p> </p></li><li> There may still be some minor differences in representing coordinate variables. <p> </p></li><li> The xsd represents attribute values thus: <pre><attribute name="a"><value>...</value><value>...</value></attribute></pre> I chose to use attributes in the multi-valued case because I prefer not to use elements with content unless really necessary. So I represented the above as this. <pre><attribute name="a"><value value="..."/><value value="..."/></attribute></pre> <p> </p><p> </p></li><li> There is an issue of interleaving of definitions, or equivalently, what elements must occur in a fixed order. <p> </p></li><li> Where should attributes be legal? I think the rng grammar and the xsd grammar agree on this: putting them almost everywhere, but it needs discussion. </li> <p> </p><li> I dropped Blobtype. I fail to see the need for this. </li></ul> <p> </p><h4> Testing the Relax-NG Grammar </h4> You will need to copy three files: <ol> <li> dap4.rng - this is the grammar file. it uses the <a href=''>Relax-NG schema language</a> This grammar file can be obtained from <a href=''></a>. <p> </p></li><li> test.xml - this is a test file that I am growing to cover the whole grammar. This can be obtained from <a href=''></a>. <p> </p></li><li> jing.jar - Jing is a validator that takes the grammar and a test file and checks that the test file conforms to the grammar. This can be obtained from <a href=''></a>. </li></ol> To use this jar file, do the command: <p> </p><pre>java -jar jing.jar dap4.rng test.xml</pre>No output is produced if the validation succeeds, otherwise, error messages are produced. DAP4 Commentary: Possible Notation for Server Commands Dennis Heimbigner 2012-03-27T16:06:28-06:00 2012-03-27T16:06:28-06:00 Looking to the future, it is clear that eventually our query language, or more generically our previous discussion of <a href=''> URL Annotations</a> must encompass three classes of computations. <ol> <li> Queries in the DAP2 sense, </li><li> Commands to control the client-side processing of requests on the server (i.e. thing like caching), </li><li> Server-side processing. </li></ol> I want to propose a notation for everything in the URL after the "?". I think this notation has ability to represent a wide variety of features without, I hope, being too generic. <p> The notation is basically nested functions combined with single assignment variables. A semantically nonsensical, but grammatical example would look something like this: "?_x=f(17,g(h(12))),f2(_x,[0:3:10])". </p><p>. </p><p> There would be several semantic rules. </p><ol> <li> A variable may only be assigned to once (single assignment), but may be referenced as many times as desired after that. <p> </p></li><li>. <p> </p></li><li> Any expression that is not assigned to a variable and does not have a void return type will have its return value returned to the caller as part of a DATADDX. </li></ol> <h4>Notes</h4> My hypothesis is that this notation should also be able to handle most kinds of server side processing by defining and composing functions. <p>. </p><p>. </p><p> I also hypothesize that Ferret notations </p><pre>{}{let deq1ubar=u[d=1,l=1:24@ave]}<br /></pre> could be represented in my proposed function notation without having to clutter up the URL format. DAP4 Commentary: Sequences and Vlens Dennis Heimbigner 2012-03-27T15:52:23-06:00 2012-03-27T15:52:24-06:00 <blockquote> "Oh what a tangled web we weave when first we practice to build a type system." </blockquote> Recently, I made the claim to James that the Sequence construct could serve to represent CDM/HDF5 vlen constructs. <p> His reply was as follows: </p><blockquote>. </blockquote> <p> This is a very important observation, and has caused me to re-think how sequences and vlens should be handled in DAP4. </p><h4>Vlens</h4> Let us start by addressing the addition of vlens to the DAP4 data model. <p> Some possible ways to insert vlens into the dap4 data model include the following. </p><ol> <li>]. <p> </p></li><li> James has proposed something similar except that the "*" is restricted to occurring as the last dimension. <p> </p></li><li> Another possibility is to create a new container object, call it <i>Vlen</i>, that (like <i>Sequence</i>) is inherently of variable length and is not dimensionable. [Aside: The term "vlen" is kind of odd. the term "list" would actually make more sense] </li></ol> <p>. </p><p> Consider the following CDM example (using a pseudo-syntax) </p><pre> Int32 v[d1][*][d2][*][d3].<br /></pre> This would have to be represented in DAP4 something like this. <pre> Structure v_1 {<br /> Structure v_2 {<br /> Int32 v[d3];<br /> }[d2][*];<br /> }[d1][*];<br /></pre> <p> In the lucky case that the last dimension is a already a "*": </p><pre> Int32 v[d1][*][d2][*];<br /></pre> then we have a simpler representation. <pre> Structure v_1 {<br /> Int32 v[d2][*];<br /> }[d1][*];<br /></pre> <h4>Commentary</h4> <ul> <li> As a personal matter, I would prefer to use the CDM representation. Adding a new container type (Vlen),while appealing semantically, only complicates the model more. James' approach requires the use of additional Structure definitions which, in my opinion, obscures the underlying semantics. <p> </p></li><li> One thing that I need to check is how this affects the proposed on the wire format. </li></ul> <h4>Sequences</h4> Nathan Potter noted the following. <blockquote>] </blockquote> And later Nathan Potter noted the following: <blockquote>)] </blockquote> . </p><p> So, we seem to have two very similar concepts (vlen and sequence), which complicates the DAP4 model. The question for me is: </p><blockquote> Do we get rid of the Sequence concept, or at least define it as equivalent to the following?: Structure {...} [*]. </blockquote> My current belief is that we should keep sequences but with the following restrictions: <ol> <li> Sequences can only occur as top-level, scalar, variables within a group. </li><li> Sequences may not be nested in any other container (i.e. other sequences or structure) </li></ol> This keeps sequences for the original purpose of acting as "relations". All other places where we might use a sequence before will now use a vlen. <p> As with vlens, the translation between DAP4 and CDM needs to be addressed. </p><ul> <li> The conversion from DAP4 to CDM can be addressed using the rule above, namely that a sequence is, in CDM, represented as <pre>Structure {...} [*]</pre>. <p> </p></li><li>). </li></ul> DAP4 Commentary: Characterization of URL Annotations Dennis Heimbigner 2012-03-27T15:33:58-06:00 2012-03-27T15:54:42-06:00 <h4>Characterization of URL Annotations</h4> Requests for data using the DAP4 protocol will require a significant number of annotations specifying what is to be retrieved, commands to the server, and commands to the client. <p> This document is intended to just describe the information with which URLs need to annotated based on past experience. It also enumerates the possible URL components that can be used to encode the annotations. I will consider a specific encoding in a separate document. </p><p> Looking at the DAP2 URLs, we see three classes of annotations: protocol, server commands, client commands, and queries (aka constraints). </p><h4>Protocol</h4> For <pre>...<br /></pre> the "dodsC" indicates the use of the DAP2 protocol. TDS also supports a schema called "dods:" that also indicates the use of DAP2. <h4>Server Commands</h4> Server commands in DAP2 are appended to the dataset URL to indicate attributes of the request. For example: <pre><br /></pre> The defined kinds of server commands for DAP2 are as follows: <ul> <li>Component requests: ".dds", ".das" </li><li>Data requests with format: ".dods", ".asc" </li><li>Miscellaneous: ".html", ".ver" </li></ul> <h4>Client commands</h4> Client. <p> Currently, client commands are represented as "name=value" pairs or just "name" enclosed in square braces: "[nocache]", for example. These commands are prefixed to the URL such as this. </p><pre>[show=fetch]<br /></pre> The legal set of client commands is client library specific. <p> One notable problem with this form of client command is that it prevents generic URL parsers from parsing the URL because, of course, the square bracket notation is non-standard. </p><p>. </p><h4>Queries</h4> The third class of URL annotations specifies some form of query to control the information to be extracted from a dataset on the server. This information is then passed back to the client. <p> In DAP2, queries consisted of projections and selections specifying a subset of the data in a dataset. </p><p> A projection represents a path through the DDS parse tree annotated with constraints on the dimensions. For example, this query: "?P1.P2[0:2:10].F[1:3][4:4]". </p><p> A selection represents a boolean expression to be applied to the records of a sequence. Syntactically, a selection could cross sequences, thus implying a join of the sequences, but in practice this diss not allowed. </p><p> DAP2 queries also allowed the use of functions in the projections and selections to compute, for example, sums or averages. But the semantics was never very well defined. The set of allowable functions is server dependent. </p><h4>Annotation Mechanisms</h4> DAP4 will need to support at least the three classes of annotations described above. Whatever annotation mechanisms are chosen, the following properties seem desirable. <ul> <li>The resulting URL should be parseable by generic URL parsers =>Client commands should be embedded at the end of URLs, not the beginning. </li><li>Whatever annotation encoding is used, it is desirable if it is as uniform as possible. </li></ul> As mechanisms, we have the following available to us: <ul> <li> The URL schema -- "http:" for example, or the TDS "dods:" schema. Using this is somewhat undesirable because it would need to encode also an underlying encrypted protocol like https: (versus http:). <p> </p></li><li> URL path elements such as the current use of e.g.... by TDS. <p> </p></li><li> URL query -- everything after the first '?' in the URL. URL queries technically have a defined form as name=value pairs, but in practice are pretty much free form. <p> </p></li><li> URL fragment -- everything after the last '#'. Again these are pretty much free form. <p> </p></li><li> Filename extensions -- everything between the data set name in the path and the start of the query. The DAP2 ".dds" and ".dods" are examples of this. <p> </p></li><li>Alternate extension formats. Ethan Davis has proposed the use of a "+" notation instead of filename extensions: "+ddx+ascii", for example. This has the advantage of clearly not being confused with filename extensions while also making clear the additive nature of such annotation. </li></ul> I should note that the Ferret server has taken to seriously abusing the URL format with URLs like this. <pre>{}{let deq1ubar=u[d=1,l=1:24@ave]}<br /></pre> so we have much to aspire to :-) DAP4 Commentary: The on-the-wire format Dennis Heimbigner 2012-03-27T15:12:33-06:00 2012-03-27T15:12:33-06:00 <h4>Background</h4> The current DAP2 clients, use two different approaches to managing the packet of data that is sent by the server. <p>. </p><p> In contrast, the oc library uses a "lazy" evaluation method. That is, the incoming packet is sent immediately into a file or into a chunk of heap memory. Almost no preproccessing occurs. Data extraction occurs only when requested by the user code through the API. </p><h4>Problem addressed</h4> The relative merits and demerits of lazy versus eager are well known and will not be repeated here. Lazy evaluation of the DAP2 packet is hampered by the inlining of variable length data: sequences and strings specifically. If it were not for those, the lazy evaluator could compute directly the location of the desired subset of data as requested by the user, and do so without having to read any intermediate information. But when, for example, Strings are inlined, then it is necessary to walk the packet piece by piece to step over the strings. I plan to use lazy evaluation for my implementations of DAP4, and propose here the outline of a format for the on-the-wire data packet that makes lazy operation fast and simple without, I believe, interferring with eager evaluation. <h4>Proposed solution</h4> Since we have previously agreed on the use of multipart-mime, the incoming data is presumed to be sequence of variable length packets with a known length (for each packet) and a unique id for each packet. <p> Under these assumptions, I propose the following format. </p><p> </p><ol> <li. <p> </p></li><li>Each element in a string array in the initial packet is represented by three pieces of fixed size info: <ol> <li>the unique id of the packet containing the contents of the string. </li><li>the offset in the packet defined in (a). </li><li>the length of the string in bytes (assuming utf-8 encoding). </li></ol> <p> </p></li><li>As an optimization, the string packet can be directly appended to the fixed size initial packet, in which case, the first item is not strictly necessary. <p> </p></li><li>Given a sequence object either a scalar or as an array of sequences, the sequence is replaced by the following fixed size item: <ul> <li>The unique id of the packet containing the sequence records </li></ul> <p> </p></li><li. </li></ol> <h4>Rationale for the solution</h4> The above representation makes lazy evaluation very simple and a given item in a packet can be reached in <i>o(1)</i> time. Even with the case of nested sequences/vlens, the proper item can be reached in <i>o(log n)</i>. <h4>Updates</h4> <dl> <dt>2012-02-20</dt><dd>The above encoding has as one consequence that all embedded counts that currently exist in DAP2 are superfluous. Ditto for the sequence record markers. It may still be desirable to include the counts for purposes of error checking, but they are not strictly necessary. </dd></dl> First two weeks! Sean Arms 2011-06-07T14:27:15-06:00 2011-06-09T09:06:16-06:00 <p>Community Driven: <i>Sure, Unidata has Policy and Users committees, so they must care about what the community thinks, right? Right?!? I mean, I was there – I felt like they cared what the Users Committee thought while we were there, in town, in person.</i></p> <p> <meta http- <title></title> <meta name='GENERATOR' content='OpenOffice.org 3.3 (Unix)' /> <style type='text/css'> <!-- @page { margin: 0.79in } P { margin-bottom: 0.08in } A:link { so-language: zxx } --></style></p><p align='left'><table width='450' height='288'><tbody><tr align='center'><td> <img width='431' vspace='0' hspace='0' height='231' border='0' align='bottom' src='' alt='Image from Jeff Weber's t-shirt today!' /><br /></td></tr><tr align='left'><td><p><sub><i>Image taken from Jeff Weber's t-shirt today! Talk the talk, walk the walk, and wear the schwag!</i></sub><br /></p></td></tr></tbody></table> </p><p.</p><p style='margin-bottom: 0in;'>. <i>Sure, Unidata has Policy and Users committees, so they must care about what the community thinks, right? Right?!? I mean, I was there – I felt like they cared what the Users Committee thought while we were there, in town, in person.</i>.</p><p style='margin-bottom: 0in;'><b>Observation 1:< <b>unbelievably huge deal!</b>!</p><p><b>Observation 2:<>I <u>could</u> have been told those things.</i>.</p><p><b>Observation 3:</b>.!</p><p: </p><p> </p><ol><li><p style='margin-bottom: 0in;'>Contact those awesome individuals serving on our governing committees (maybe even consider serving!) (<a href='../../../community/index.html#governance'></a>)!</p> </li><li><p style='margin-bottom: 0in;'>Want to get involved with Unidata but don’t have the financial resources in your department? Well have we the deal for you: Unidata Equipment Awards! (<a href='../../../community/equipaward/'></a>)</p> </li><li><p style='margin-bottom: 0in;'>Check us out on Twitter or Facebook. </p> </li><li><p style='margin-bottom: 0in;'>Subscribe to our “News from Unidata” blog (<a href='../../news/feed/entries/atom'></a>) or the “Developer’s Blog” (<a href='../../developer/'></a>) (both are open for comments, and comments - we love em’).</p> </li><li><p style='margin-bottom: 0in;'>Subscribe to our users mailing lists and participate (<a href='../../../support/#mailinglists'></a>)! </p> </li><li><p style='margin-bottom: 0in;'>If you’re in Boulder for a workshop or meeting, come say hello (<a href='../../../about/index.html#visit'></a>)! </p> </li><li><p style='margin-bottom: 0in;'>Visit us at the Fall AGU or Annual AMS meetings (<a href='../../../events/index.html#conferences'></a>).</p> </li><li><p style='margin-bottom: 0in;'>Hang out with us virtually and see what’s going on in the community by checking out a seminar through the Unidata Seminar Series (<a href='../../../community/seminars/'></a>)</p> </li><li><p style='margin-bottom: 0in;'>Consider attending a training workshop (<a href='../../../events/2011TrainingWorkshop/'></a>).</p> </li><li><p>Consider attending the 2012 Triennial Workshop (organized by the Users Committee and Unidata!). More details to come, but see: <a href='../../../events/index.html#triennial'></a>. <br /></p></li></ol><p>Which of these do you use? Which are most appealing to you? What can we do to better keep those lines of communication open? <br /></p>