Made some progress on my little app today (code updates happening on the development branch). This week, I learned the importance of composing structs when working with JSON (at least for working with in-memory data structures). What does all that mean?

So in python you have dictionaries that easily convert to json and vice versa, it’s like a couple of lines of code. Go is statically typed, so you have to model out the structure of the json body to tell go what tyes the values should be. Ok so you figure that out no worries, not too hard.

Now let’s talk about nesting.

Say you have json body with lists in it. if you want to be able to access those lists and work with them programmatically, then you need to do composition.

In this example, there’s a response with a list of certificates (only one shown here for brevity). If you wanted to work with those certificates individually, you would need to define a certificate struct, then a response struct, then make the certificate a slice of certificates inside the response. The way I figured it out was to print out the type of the struct I was getting from json.unmashal, to see if it was a generic struct or one I had defined.

{
  "response": [
    {
      "id": "8c75350b-ea1b-4a51-a2e7-d37118ac04ae",
      "friendlyName": "Default self-signed server certificate",
      "serialNumberDecimalFormat": "16801809625158750310575466749",
      "issuedTo": "ise1.pod1.abl.ninja",
      "issuedBy": "ise1.pod1.abl.ninja",
      "validFrom": "Thu Mar 30 12:56:02 UTC 2023",
      "expirationDate": "Sat Mar 29 12:56:02 UTC 2025",
      "usedBy": "EAP Authentication, Admin, Portal, RADIUS DTLS",
      "keySize": 4096,
      "groupTag": "Default Portal Certificate Group",
      "selfSigned": true,
      "signatureAlgorithm": "SHA384withRSA",
      "portalsUsingTheTag": '"BYOD Portal (default), Blocked List Portal...',
      "sha256Fingerprint": "20af57d758f156d33a7616a664c58d605e53e7a1f678ebf08561421d6571cad6",
      "link": {
        "rel": "self",
        "href": "https://10.253.68.202/api/v1/certs/system-certificate/ise1/8c75350b-ea1b-4a51-a2e7-d37118ac04ae",
        "type": "application/json"
      }
    },

  ],
]

Ok so here’s how I modeled this in Go:

type CertList struct {
	Response []Cert
}

type Cert struct {
	ID                        string `json:"id"`
	FriendlyName              string `json:"friendlyName"`
	SerialNumberDecimalFormat string `json:"serialNumberDecimalFormat"`
	IssuedTo                  string `json:"issuedTo"`
	IssuedBy                  string `json:"issuedBy"`
	ValidFrom                 string `json:"validFrom"`
	ExpirationDate            string `json:"expirationDate"`
	UsedBy                    string `json:"usedBy"`
	KeySize                   int    `json:"keySize"`
	GroupTag                  string `json:"groupTag"`
	SelfSigned                bool   `json:"selfSigned"`
	SignatureAlgorithm        string `json:"signatureAlgorithm"`
	PortalsUsingTheTag        string `json:"portalsUsingTheTag"`
	Sha256Fingerprint         string `json:"sha256Fingerprint"`
	Link                      struct {
		Rel  string `json:"rel"`
		Href string `json:"href"`
	} `json:"link"`
}

So why did I do that? Because I wanted to get the certificate list for each node and simply bolt on to the node struct. to do that I can add my certificate type to my node type like this:

type node struct {
	Id   string
	Name string
	Link struct {
		Rel  string
		Href string
	}
	Certs []Cert
}

Time for bed.

-s

Greetings programs!

It’s been quite a ride for the last month or so, so much going on. Last Monday morning I passed the new Cisco DEVASC exam (200-901) on the first day to test, making me a member of the Devnet 500 club.

Preparing for the exam really did a lot for sharpening up some relatively new skills I’ve acquired that haven’t had a lot of reinforcement. That’s the real value of IT certifications – having that performance-based focal point. When your learning is self-directed there is a real tendency to sort of wander from topic to topic and lose focus, and learning tracks are a great tool to combat that.

That said, I think the most important takeaway is that we’re rapidly transitioning to an API driven world and it’s important to get comfortable working with structured data and logical abstractions in general regardless of the job role.

Ok, about Terraform. What I’m working through is the approach I want to take. I want to bring a unique angle rather than join a chorus of people all saying and doing the same thing. If there are specific things you would like to see, let me know in the comments.

Thanks for reading and I’ll see you around.

Greetings Programs!

Just a quick check-in for this week.

Life has gotten a bit hectic recently, and will likely remain so for another couple of weeks. Small things are beginning to take conscious effort and focus which is a reliable indicator that I need to trim the sails a little. What this means for this space is the first Terraform post is delayed for a week, possibly two.

On a brighter note, the weather was wonderful for this morning’s walk, my dogs were well behaved, and coffee is always there for us and wants us to be happy.

Until next time, may you care for yourself with ease.

-s

Greetings programs.

Holy cow, been 8 months since my last dispatch.  Still studying and learning cool stuff, have not done a good job at stopping to document my learnings, going to make another attempt to rectify that.

Been an eventful year.  In addition to learning DevOps tools and techniques and studying cloud native software design, I’ve also changed jobs.  As of August I’ve been working at Cisco systems as a pre-sales Architect.  It’s a dream job and I absolutely love working with my customers. I learn as much from them as they learn from me.

So yeah, the new job thing; several months of getting the firehose and struggling to take everything in and find my stride.

I didn’t feel like that was enough new stuff, so I enrolled in WGU’s Cybersecurity Bachelor’s program starting in January.  I don’t **need** a degree, but I don’t think it would hurt to become a more well-rounded technologist.  I’ve historically used certifications for learning paths which is fine but they tend to be narrowly defined in scope which can lead to polarized thinking.

So here’s the plan for the blog:  I’m committing to posting something every Monday morning, even if it’s just a “hello, I’m drinking coffee and checking my twitter feed how about you”.  I have a sizable collection of study notes, so there’s no shortage of meaningful topics however. Hopefully I’ll dip into that more than the small talk  :).

Have a great week, talk to you next Monday morning.

-s