DEV Community: Matteo Nunziati

So I got my GCP Professional Cloud Architect Cert

Matteo Nunziati — Tue, 02 Jun 2020 13:09:51 +0000

So in January 2020 I've got my GCP Professional Cloud Architect certification. It was a lot since I wanted to write about this experience but, you know, I'm a fu**ing lazy bastard... 😴

Still, here we are!

What I cannot say!

This is not my first cert.: previously I've got an AWS Cloud Practitioner cert (a basic, introductory one). In both cases I've been asked to sign a ton of paper where, basically, both companies warned me that, in case of content disclosure, they will nuke my house and my family with nuclear bombs.

AWS, GCP preliminary docs in a nutshell: you talk about your exam, we blast your family!

So this is a piece about what I can not say! Yup! 😅

Exam Approach

When preparing for an "higher" level cert I was expecting few complex questions: in the end an architect is not a packaging machine! You are not expected to perform a million simple tasks at speed light. You are expected to solve complex problems with the right tools.

Instead the exam is composed by a ton of closed/multiple choice questions. The specificity of these questions is that they are not difficult: they are tricky! and of cource filled with all the commercial names of GCP products. 😖

Yes! Basically what you really have to mind is the details, the small adverbs, or similar, which, in a predefined jargon (internal to Google) means: "hey, here the candidate has to focus on answers taking about managed instances" or "here, with this adjective, we expect him/her to think about that technology of ours".

So basically my very first advice is: do a lot of exercise! If you find a for-free or paid test which is vaguely related to yours GCP cert, do it! To accustomize yourself to the type of questions.

I've made the preparatory checks even for GCP Cloud Engineer, just to be more comfortable.

Exam Contents

As said, I cannot disclose the questions. Still in my case (Italy, Q1 2020) 25% of questions was about migrating to cloud or hybrid cloud.

The other 25% was about big data technologies and processing.

The other half was about anything you can look at in a GCP Console, with a certain care on networking products.

What NOT

What was not in the exam, at least not in a relevant way, was: deep kubernetes know-how, no ML/AI - I think they have a dedicated thing about this -, not super hard questions about security - again I think there is a specific exam for this -.

Preparatory material

I've trained myself by using the Coursera path for GCP Professional Cloud Architect. I really don't know if this is an effective path. In the end the exam is a ton of closed/multiple choice questions, while Coursera modules (leave the first out) are hands-on material.

To be clear: the course is distributed by Coursera but the content is produced directly by Google, so this is the official training path. Still I'm not sure that all those labs helped me with the kind of exam I've faced...

I know that both Udemy and Linuxacademy have courses for this exam, but I don't know which focus they have.

The recommended 3-years experience

When comes to look at the recommended prerequisites for successfully pass the exam, Google says that a 3-years hands-on experience will help you pass the examination.

This is the thing: do you live in a country where it is easy to be hired as a cloud architect and you need a cert "just" to rise your salary or you live in a country (like me) where you are trying to become a cloud architect and you think that a cert badge will help you having new job opportunities?
In the former case the 3-year experience paired with a formal course will let you successfully pass the exam. In the latter you must have the badge before you can have hands-on experience. So this becomes a chicken-n-egg problem

So what?!

I really don't know what to say. Experience always helps, but in may case I've just made the Coursera copy-pasta exercises and I've deployed a couple of projects for some customers of mine. No more than 1 month hands-on with only 2 real life projects (a firebase one and a VM+Cloud SQL one).

Still, I managed to pass the exam. My thoughts on this are: as there are a ton of tricky questions with a lot of confusing commercial names, hands-on experience will let you slowly absorb the jargon and the names of GCP, making you more comfortable with the exam.
Anyway the questions range on such many topics that I do not think that a generic 3-years experience will let you face enough real life problems with all of the GCP technologies.

Conclusion

I'm now on the edge to understand if the cert has any market value for me. Surely, being certified let your customers/future employers have a (vague) knowledge about the fact that you have at least a sufficient understanding of GCP design.
And also this is my very first tough examination after a lot of years (my PhD thesis dated back to 2008) and it is somewhat reassuring for my self-esteem that I can still face an exam and pass it! ✌

So I did it (vuejs meets an automation engineer)!

Matteo Nunziati — Thu, 02 Jan 2020 15:27:14 +0000

As First

So I've written about my early exposition to web technologies a few months ago... Finally I've got a chance to write a real app in vue.js and this is my feedback as a beginner.

The widget set

In my previous post I've tried but material design and bootstrap with vue and I liked boostrap more... Anyway I've gone with buefy for my app: the customer asked for the ability to reorder table rows with drag'n'drop an this is a native feature in buefy, and it is paired with an amazing example you can basically copy-pasta to your codebase.

lesson 1: the customer needs define your tools.

The project setup

When you start a project with vue.js you can bootstrap a skeleton via the Vue CLI. I really recommend the following:

switch to a custom setup
enable Typescript (aka ts)
avoid the Linter (your worst enemy!)

The infamous linter

While you have a number of optional linters and you can setup your own rules, for a small project this is an overkill.
I do like the idea of an omogeneous style all around the app, but enabling the linter is really irritating: it is constantly in your way. You are developing some test ideas and the linter generates something like a gazillion of errors because your have put that space but you have not put those curly braces after an if statement... GOSH it slows you down a lot!

lesson 2: Way better to manually run a linter now and then then enable the linter by default!

The blessed Typescript

While the app was a small manufacturing management system with limited functionality, and while the entire world is now spitting on OOP, Typescript abstract classes made my day:

saving ton of obscure this.prototype = {...} stuff all around
centralizing the code a lot and thus reducing the LoC I've written.

And everyone knows that the more the LoCs the more the bugs.

The too strict Typescript

While I really recommend the usage of typescript with Vue too, I've to say that:

lesson 3: interfacing js and ts in vue it is not necessarily trivial. Now and then you fall in some deadend and you would pray to revert to plain js, but the net result is incredibly positive.

Architecture, my lads, architecture

I've seen ton of people praying for state management in vue.js/react/angular apps. While information exchange among components is not easy (almost impossible) unless you have a parent-child relation, I think that a good old MV* approach a-la backbone is a winner here.

lesson 4: always, always, I've said ALWAYS remember that front-end is not different from back-end! You need structure and you need to separate concerns.

The data you fetch is a model, the logic which manipulate them is your controller/presenter/supercool-brand-new-logic, the way you show them on screen is the view. Use plain ts code to structure everything and use vue to render, avoid stuff like fetching data inside a vue component:

This approach is just MVC a-la winforms and it is known to proudly kill your dog since 90s!

Is vue the right tool?

While I was working on this app for a customer of mine, I've started collaborating with a local software house: they are a java+angular shop so I've got a certain exposition to angular in production too.

lesson 5: your early impressions are usually right.

Vue and vue router are incredibly handier to use than angular, so yes: my eraly impressions where right. Just use them as first choice unless your project is a really huge one... like... like you are rewriting a full OS in the web ;)

But vue/react/foo is just a library, full frameworks avoid the need for glueing together ton of libraries

Let me put this in that way: this is bullshit.

My app is making use of firebase and other backend services: firebase has it own API you still need to put in the model layer of your framework. Other fetch APIs are trivially simple to integrate: Axios is just a brain dead choice and doesn't add any complexity or any real boilerplate.

lesson 6: risk of library piling/boilerplate vs usage of frameworks is not a factor at all. You should choose your tools because of other real reasons.

Sidenotes

I'm not fan of projects with 1000 tools, but...

Being in shortage of time has lead me to search for a lot of premade stuff: I've found vue portals super-cool and super fast to implement

All memes belong to their authors!

When a Senior Automation Software Engineer meets front-end web technologies

Matteo Nunziati — Sun, 21 Jul 2019 10:19:32 +0000

TL;DR:

Automation Software Engineers should stay away from web front-ends :-) But newbies can use this as a light-weight introduction to modern front-end development.

The context

I've worked as a software engineer for more than a decade in the automation field, mostly for machine vision applications. I've strong skills in Algebra, Machine Vision, Matlab, good knowledge of c++ and back-end stuff you can put in an automation software. AKA: When I see a CSS I fly away scared

In recent days some potential customers shown interest in automation applications with web front-ends. They want a web SPA (even if they don't know what a SPA is), so that they can manage their machines with different devices.

Therefore I've started my journey trying to find a good fit for my needs. And it turned out as an assembly journey, where I've tried hard to build my dev env and find the right toolbox for my needs and, most important, my level of skills!

I want it all and I want it now!

So as a Senior Automation Software Engineer my few GUI are developed with classic tools. Nowdays unfortunately on .NET Framework and Windows (I prefer QT and Linux) and my average GUI is named a "Human Machine Interface" and looks like this:

Yeah, thanks: no false humility here. In my 10+ years in front of a pc I've acquired an over-average UX compentence.

Still, I've grown accustomed with Graphical Designers (Visual Studio anyone?), XML/XAML, data bind and ready-to-use widgets. Let alone a proper IDE with an integrated graphical debugger.

So I've started my quest for the same tools in webdev. I just want to design a few panels not the next consumer-grade killer-app... It should be easy!

Did I tell you I'm lazy?

Lazy Step 1: I've not dedicated my time to discover a ton of secret jems. I've started following the wave: the IDE+debugger has to be Visual Studio Code (VSC) with a couple of plugins and with the Chrome debugger or the Firef.. no: with Chrome. Period.

Lazy Step 2: what integrations VSC has and what is documented on their site about front-end frameworks/libs/stuff? Easy:

Angular
Vue
React
Ember
Next-cool-thing-with-a-6-months-life-and-yet-available-in-VSC-next

Where's the toolchain?

Really: gimme a toolchain for the fox sake!

Isn't here a javascript toolchain? Hell even c has one (compiler, linker, make, blabla). No wait: you can use node.js for this.

NODEJS? N.O.D.E. JS.? The serverside javascript interpreter froked from Chromium? Whaaaaaaat?

Yes. In these years, while I was trying to let a machine train a damned bunch of neural networks, some smart guys have discovered that they can use javascript to build a javascript toolchain. In the end c compilers are written in c, so what's wrong?

And so your hero started installing node.js. And npm. And upgraded npm. All of the previous frameworks/libs/stuff have the proper toolchain ready to be setup and waiting for you in the npm package registry: no mind crushing courses on webpack, webpick, babel, gomorra, ES2015, ES3048 etc... A linter is in place too and everything is just an npm install away (and a * create application_name away!)

Cool! oh, wait what's this node_modules folder?

Let's start coding!

Now that everything is in place I can happily enjoy my IDE with powerful debugging capabilities and a nice debug/release cycle thanks to the huge scaffolding done by the cli of the case but... the debugger simply ignores my break points. It turned out that while VSC has a ton of debugging capabilities you have to set them into the ./.vscode/launch.js file (path relative to your app folder). Every tool has it's own dedicated page for this topic and after a 30 min. digging on the web I've found the right config for the launch.js file. So I've started to happily code front-ends like I did with backends in the early 2000 :P

Where's the widget set?

OK, so you need to install another set of node modules but all the previous frameworks/libs have a ton of fresh widgets ready to be used... Bootstrap, Material Design based, Bulma... wait Bulma, seriously?! Ah, who cares, I've just installed my new 1TB nvm disk for node module hosting, just install it and shut up!

Now tell me, what was that joke? Ah yes, JQuery is such a heavy lib you rather want to avoid it... err... did you see the weight of a widget set? What? Should I reimplement it from scratch? Seriously? Naaaa....

Where to start?

So I had 3 possibilities here actually: I've dropped Ember.js as the entire ecosystem seems rotating around Vue, React, Angular. Sorry Ember I own you a beer.
Then I've tried to stay as mainstream as possible for my early tests, so I've opted for bootstrap and material design stuff. Sorry Bulma: I'm too scared of Vegeta. In the end I've found myself pocking with 6 combinations of tools:

vue+bootstrap
vue+material
react+bootstrap
react+material
angular+bootstrap
angular+material

And what did I learn?

Well, coming from a backend/automation background I've evaluated the 6 possibilites as a whol: it was like almost using 6 different frameworks because each widget set library added its own logic to the mix.

I've discovered that Angular is by all means the closest thing to server side programming. At least it felt really close to python/c# and the so: async events, decorators, split your widget into 3 different files: html, css, logic.
Angular seemed also the most formal of the three (a lot of docs on concepts and theory) and the most "corporate": fixed release cycles, regular cadence... Still for my small needs it also seemed too big. But -as expected- its material design implementation was great.

React was the most close to pure js to my taste. I've cheated in the intro: I've developed a couple of web apps in the past by using uwsgi+Flask+Python. Bootstrap was used for the style and JQuery was the only helper to build the app. The logic was pure js.
So when I say React felt as close as js as possible I refer to that small experience of mine. React JSX is also the most amazing thing I've tried in the last years: elegant, effective. It seems the best way to get rid of the mutilated logic of templates. I haven't felt so productive with a new tech since the year I discovered Python.
I was ready to fall in love with React but then I stackoverflowed for a number of questions and all of my search paths ended into the same place: React State Management. Really too many things to learn for a simple UI. And also I hate functional programming a lot.

Vue... well I overlooked at vue in the beginning. It seemed like a chinese soup of Angular, React, somethingstrange(TM) and the so. And it is! The greatest mix of stuff ever seen. All that ugly directives in templates, a million ways to say the same thing (:, @, v-on, v-bind, v-ery-strange), it even suggests you must use a state management library which seems a clone of Redux (Vuex? Really?).

(ok the web lacks a good vue.js meme...)

But it also has .vue files where simple html, css and js stay well tight and isolated for each component. You can plug JSX in the mix. It is the most practical solution I've found and in the end of the day I already felt familiar with a number of things read in the docs.

Ok, so?!

So I've choosen Vue as my first entry in the front-end world. Along with Bootstrap (the bootstrap-vue docs are simply amazing). Not because it is superior in something, but because it is the most "forgiving" piece of tech, the easier to work with while making a bit of experience in this new world. A really good entry point for someone used to algebra and machine vision.

OK, who cares?!

Oh. I really don't know... but you have read this all so, Thanks for reading :)
And remember: all meme belongs to their authors.