Passed the exam successfully :party: Proof can be found here: https://www.certible.com/de/verify/fc832c0524c8711b8871e1c645944583
I’d like to thank Stephan Christmann for the preparation and my dear wife for the support.
Strive for quality incrementally and iteratively 🙂
#isaqb #cpsa #softwarearchitecture #youliveandlearn
Certible page with the proof.
Some of the profits from this seminar ‘practive acting before an issue would turn into a problem’, ‘strong cohesion, loose coupling’, ‘the biggest leverage for guaranteed quality after software engineering and testing is done properly: requirements engineering and software architecture’.
20200827 – day 4
Long recapitulation of the lecture from yesterday, then the last chapter about support tools and static code analysis. Afterwards some discussion about a real world example from one of the participants.
The early closure left enough time to prepare for the exam (scheduled friday 12:00).
The exam took place online, I had to prepare a totally clean desk, proof by moving the camera that there is no one else in the room and then solved 41 questions within a maximum time limit of 75 minutes.
20200826 – day 3
Sadly, I haven’t written about that day directly afterwards, so the summary will a bit shorter: recap of day 2, then we learnt about metrics and FMEA and risk-evaluation. Then we solved and sicsussed 37 test-questions for the exam. Of course, they were not identical to the official questions. But came quite close 😉
20200825 – day 2
Day started with the homework-questions we had to prepare and some recapitulation. Works well, but I am already a bit overwhelmed of how much is there to learn. The more you see, the more you know, you know nothing. For my whole life I’ve done monoliths on different OS and with different technologies, ok, twice some message-based architecture. But there is so much more. I should definitely get myself more invested in server-architecture, REST and microservices. Today we covered architecture patterns and approaches, how to reduce dependencies, .. and did several exercises. BTW: I’ve forgotten to mention that I take digital notes as Markdown (see github). Again homework and much to learn and read. And my book “Zertifizierung für Software-Architekten” from Starke/Hruschka arrived.
20200824 – day 1
The seminar takes solely place in Zoom, trainer is Stephan Christmann and he does his job quite well. We are just a bunch of four apprentices, which is ok, because then the exercises (and there are some) are not crowded and we can utter questions whenever we like. Of course, the first day is loaded with definitions after some “soft” start into the topic. Looks like a software architect (abbreviated SA later on) needs more or less the same personality traits like a requirements engineer (see IREB) or a test engineer (see ISTQB): resilience, curiosity and communicative skils and a proactive mindset. We even got homework, yay!
20200823 – before the seminar
in the past, ive not done this. that i recapitulated much about everx seminar or workshop. if i did, then it was most of the time areview of the successful participation. but, reality is different. before something starts, there is the tesnion and the fear of not being well prepared, while doing there is the fun to lear some new insights, see your capabilities grow, learning stress, befor he test the testion is almost a t maximum and then the release. after seein a successfuly test rulst. htherefore i want to cover the following four days of this chapter of my learning journy.
Let’s assume the following situation: in the past a feature was implemented, a full DoD (code review, manual test, stakeholder approval, ..) was done and the ticket successfully closed.
Suddenly someone realizes that a second feature, which is closely related to the first one, should have that behaviour as well. The circle of people cavilling about the lack of functionality is identical with the people writing the requirements and doing the validation of the implementation of feature one.
So, is this a bug?
No, this is a new task!
It is devaluating the efforts of all people involved in first place, because the work was delivered like ordered. Nobody complained – until now.
Let me explain, because this sounds like nitpicking and fussing about the wording. But the inner problem is, when stakeholder and requirement engineers couldn’t capture all use-cases or had implicit, inner expectations and did not note them down before (or while) development, then you can’t suddenly name the lack of some additonal change a bug.
Or you can. If you want to piss of your developers :>
Another aspect: at the end of sprints or releases reviews are done. And at this very moment only numbers matter. You won’t dive into the details of each tickets – so only the binning of the types of solved issues matter. And mislabelling the aforementioned tasks as bugs can make a good-team result appear like a “barely made it over the finishing line”.
Time to turn the spotlight on for a tiny project I’ve finished five weeks ago. The plan was to create a script, which would retrieve the of commits for the current repository for each committer (without those distorting merge-commits) and create a piechart-plot out of it and save as raster-graphics.
Implementation was more or less straight-forward, but again – I learned a lot. Talking is one thing, creating some usable proof-of-concept is the other. And words are cheap. No matter how triftling the task may seem, action speaks louder than “ah, shouldn’t be a problem”.
Actually I had done this before the Python-graphics-workshop, because even before I thought the matplotlib is quite a mighty tool which will come in handy.
Project can be found here: GitShortlogToPieChart
Call like this:
$ python /coding/pythonCollection/GitShortlogToPieChart/GitShortlogToPieChart.py
Initial plan was to visit a course at the VHS (MVHS: Münchner Volkshochschule) about ‘NLP with Python & DeepLearning’ (natural language processing). But the tutor quit, so I checked what else I could learn! Notes and examples are archived here: graphicsWithPython
The course took place on two evenings. Lecturing person was Dr. Günter Spanner. We coasted through examples with matplotlib, tkinter and pygames.
Of course, tkinter is available out of the box with newer Python-distributions. But the resulting GUI is butt-ugly (I feel like using those UNIX-workstations in the first semester of computer science..) and you have not much influence on the layout. Since I am working for some while now in the background with PyQt (will be covered in one of the upcoming posts), I can say: good that I had a hands-on, but I will NOT use that.
matplotlib: high value in quick generation of plots of all kinds (bars, line-charts, pie-charts, ..). I’ve used it before and I guess this is the main earning from this learning-opportunity.
pygames: loading some graphics, adding a game-loop, reacting to user-input, all fine. But would require some additional effort for understanding. Maybe in the future.
Of course, a two-day workshop can’t provide you with credible knowledge and expertise for three frameworks. But having a teacher can ease the starting-pain and allows quick feedback in case something does not work. For me it was also a good opportunity to have some exchange with people and some learning-atmosphere. Also: since tkinter is so butt-ugly, I got further momentum continuing my PyQt-project.
StackOverflow has a ton of solutions with PowerShell and other external tools, but _I_ could no install something additional on that system. Nor had PS.
Works around the issue that the time is evaluated at start for each item, as well:
λ cmd /v:on /c "echo !time! & YOURCOMMAND & echo !time!"
Hint: also run cmake with just one core
λ cmd /v:on /c "echo !time! & cmake --build build\CMake\Debug\build -j1 --target all & echo !time!"
0. Get the latest prebuilt version for Win: version 0.8 (3 years old :/)
1. Put this somewhere into you CMakeLists.txt
2. Enjoy the overflowing build-output for your legacy-project.