Thursday, October 31, 2019

#CodeConfident: Journey - Part 4

My Journey application went through a couple of further changes. Here's my coding journal for them.

September 26

  • received security vulnerability report from GitHub, upgraded generator-jhipster
    1 generator-jhipster vulnerability found in package.json 3 days ago
    Upgrade generator-jhipster to version 6.3.1 or later. For example:

    "dependencies": {
      "generator-jhipster": ">=6.3.1"
    "devDependencies": {
      "generator-jhipster": ">=6.3.1"
    Always verify the validity and compatibility of suggestions with your codebase.

    GHSA-mc84-xr9p-938r More information
    high severity
    Vulnerable versions: < 6.3.1
    Patched version: 6.3.1
    Generated code uses repository configuration that downloads over HTTP instead of HTTPS
    Gradle users were using the repositories in plain HTTP, and not HTTPS, so a man-in-the-middle attack was possible at build time.

    Maven users should at least upgrade to 6.3.0 while Gradle users should update to 6.3.1.
    If you are not able to upgrade make sure not to use a Maven repository via http in your build file.

    Replace all custom repository definitions in build.gradle or pom.xml with their https version.


                <url></url> // <-- must be httpS
    maven { url "" } // <-- must be httpS
    For more information
    If you have any questions or comments about this advisory:

    Open an issue in

October 13

  • activated issue tracking for my GitHub repo, added all open todos I am aware of
  • added the projects option, created a project and added open todos to it to provide a better overview and track progress
  • added as guideline how to contribute to the project
  • changed default sorting for journal entries and challenges

October 15

  • Github reported a security alert; upgraded swagger-ui
    1 swagger-ui vulnerability found in package.json 2 hours ago
    Upgrade swagger-ui to version 3.23.11 or later. For example:

    "dependencies": {
      "swagger-ui": ">=3.23.11"
    "devDependencies": {
      "swagger-ui": ">=3.23.11"
    Always verify the validity and compatibility of suggestions with your codebase.

    CVE-2019-17495 More information
    high severity
    Vulnerable versions: < 3.23.11
    Patched version: 3.23.11
    A Cascading Style Sheets (CSS) injection vulnerability in Swagger UI before 3.23.11 allows attackers to use the Relative Path Overwrite (RPO) technique to perform CSS-based input field value exfiltration, such as exfiltration of a CSRF token value. In other words, this product intentionally allows the embedding of untrusted JSON data from remote servers, but it was not previously known that <style>@import within the JSON data was a functional attack method.

October 27

  • pairing session with Michael Kutz
  • our goal was still to introduce Lombok to Journey; as preparation for our pairing session, I recreated the situation where we ended last time, using the @Data annotation from Lombok which caused the equalsVerifier test to fail
  • when debugging the failing test again, Michael noticed that Logback threw an exception:
    WARN in net.logstash.logback.appender.LogstashTcpSocketAppender[LOGSTASH] - Log destination localhost/ connection failed. Connection refused: connect
    This does not cause a problem for the test as we still have log output in the console, yet is something to investigate for later. Maybe deactivate the file appender in case of running tests.
  • we tracked down the difference between the previous "equals" implementation and the one Lombok provides: Lombok does not consider the need for the object instances to have the same id, in the implementation generated by JHipster, however, they need to have an id defined and that to be the same
  • this triggered thoughts that it might not be wise at all to use @Data annotation for entities; Michael remembered a discussion with a colleague and a related blog post and will investigate further --> here it is!
  • as side note: Michael shared that any additional dependency introduced for microservices is a risk in itself as dependencies result in frequent maintenance costs on updates
  • we researched whether we could use the @EqualsAndHashCode annotation configured to include or exclude certain fields
  • Michael questioned the design of the generated code of JHipster regarding entities that are also used as business objects; we have DTOs here as well, which can be considered as objects that construct a JSON object from the entity
  • in the end we decided not to risk using @Data as using Lombok here might lead to unwanted side effects like not persisting entities in the database or creating duplicate ones; these kind of problems tend to surface only much later and are hard to figure out; in the end it was good to have a test for it!
  • instead we decided to use the following specific annotations which still replace a lot of boilerplate code: @Getter, @Setter, @ToString
  • for equals and hashCode we kept the original implementation; equals here will only return true in case the instances have the same id persisted in the database
  • the hashCode implementation which sets it to the magic number of 31 is completely obscure to us; the hashCode is used e.g. in a HashSet to check if an object of this type is already present
  • before committing, we reviewed our change set
  • we discussed where to put the Lombok dependency in the Gradle file; the current list of dependencies is provided by JHipster, using a BOM = Bill of Materials; therefore no specific versions are provided for the dependencies, JHipster will take care of getting the latest versions they have available; this is similarly solved in SpringBoot; we decided to add our new dependency at the very end, considering we would find it again quicker and not miss it when skimming over the JHipster dependencies
  • we discussed our previous sample test for the toString method without and with Lombok; this was rather meant as test to showcase how Lombok works, and build trust in this library; as soon as we trust it, such a test is not useful anymore, so it's not meant to be maintained but rather to help our exploration, so we threw it away; the Lombok toString might be implemented differently now, yet this method in general is only meant to provide a human readable representation of the object, while hashCode is meant as interpretable for a machine
  • when committing, we discussed proper commit messages; Michael recommended the following post: He has trained himself to make use of these recommendations and learned their benefits; we used the same approach here:
    • a) write commit messages as short as possible --> write them in present tense (which is always shorter than past tense), and as imperatives for git
    • b) if you want to provide more information, add an empty line after this "subject" and then write your comments in the third line
    • c) don't write more than 50 characters for the subject or more than 72 characters per line for the rest of the commit message
    • d) start the subject with a capital letter
    • --> IntelliJ settings offer automatic warnings in case such patterns are ignored
  • it's great to reflect on commit messages together with a pair as this helps you become aware of potential ambiguous commits; if a pair cannot formulate a great commit message together, then it might be too big, too early or not ready yet at all; great heuristic!
  • trying to commit, we stumbled across different shortcut settings: per IDE, per operating system, overridden by another program, or using custom ones; for pairing it's great to know the default ones provided by an IDE as well as most people use them
  • Retrospective:
    • I learned a lot again, it's a pleasure to pair with Michael, he takes time and stays patient to explain things well
    • Michael shared it's fun to pair with me, and explaining helps him see where his gaps are, what are only his opinions or more common viewpoints
  • Our pairing session was over, and yet we continued talking for over an hour :) We ended up with a great conversation on the following topics and more:
    • how to structure big test suites, e.g. in teams aiming to cover nearly every bit of code with automated tests
    • what are integration tests, what are service tests, what should they call and what not
    • potential future blog posts, talks, video courses, books
    • Test Automation University
    • public viewing of talks and pairing sessions at work and their discussion afterwards to learn more
    • Agile Testing Days 2019 which starts in a week and where we will meet in person
    • a conference I wasn't aware of yet: SAEC Days
    • paired talks and their specifics; paired workshops and why we should always pair for them
    • exploratory testing and introducing it to developers; how close it is to security testing
    • coaching and career development
    • pairing in general: If Michael sees one person working alone and they are not deleting their emails, then he considers this as waste. They might not know what they do; they need to share their knowledge anyway with the team; if they don't share it's a knowledge silo; feedback like had regarding proper commit messages will be lost as it's mostly not provided at a later point in time; feedback should be timely and constructive anyway and this is a lot easier when pairing. With me, pairing is easy as learning is always my second goal, yet that's not the case with all people. Having people do things alone is always dangerous.
    • code confident: Michael would instantly have me pair in his team and people wouldn't know I'm not a developer. The only difference would be that coding is rather on my breadth than my depth when it comes to my t-shaped skills, which is not bad as pairing is always learning and broadening our skill set. The one most important skill in his opinion when it comes to pairing is curiosity and the thirst for knowledge and I bring that. :D
  • TODO: fix logging configuration for running tests
  • TODO: make use of Lombok in other classes

October 27 (cont)

  • adapted implementation of entities and more to use Lombok as well
  • found some generated integration tests for the user management implementation were broke (already before using Lombok), presumably after one of the latest security fixes --> TODO

October 31

  • pairing with Simon Berner
  • he was also focusing on coding this year, so we had decided to start our session with sharing our experiences and lessons learned, before moving to a hands-on part on Journey
  • when it comes to personal learning challenges, we shared how tempting it is to do too much and loose focus; time is limited and you can only do so much
  • it helped Simon to focus on things he is passionate about, and that he also wants to present at conferences, like the workshop "Git like a Pro" he is soon giving at Let's Test Southafrica
  • he did a sneak peak into everything, learning new things and trying stuff out without any pressure involved
  • we shared our experiences regarding submitting papers at conferences for talks or workshops; we shared how awesome it is that people like Lisa Crispin helps new voices to increase their visibility by pairing up with them; it's hard to kick-start your journey into speaking and this kind of support, sponsorship and encouragement helps immensely
  • we had paired already last year on my Testing Tour, and Simon shared it was a great experience; scary at first to suddenly pair with a stranger, yet now I'm already no stranger anymore and it feels natural to pair; it really helps to share the same interests and work together
  • we talked about the things Simon tried out (check out Simon's GitHub account!); he focused on small examples, learning by doing without having to invest too much time into things; this freedom really helped him
  • sometimes we go to bed frustrated that things don't work as we wanted them to work, and then the next day we catch ourselves thinking: "wait a second..." and we know the solution; you can't force these things to happen, sometimes you need to defocus; despite us asking ourselves "all the others can do it... is it me??", we know that the job is 80% searching, exploring, experimenting, talking with people, and only a tiny part is actual coding
  • we talked about testing, our roles at our companies, how fascinating our job is and how many opportunities it offers; and how often we have to share this with people who are not aware of what this job is about
  • we talked about pairing and mobbing and getting people to give it a try; it's fascinating that with some people this kind of collaboration becomes very natural and you get into a super productive and effective flow; yet with some people you cannot; some people also strongly resist to give things a try, and you cannot force people into something
  • we decided it's time to start the hands-on part
  • I walked him through the Journey project, explaining what JHipster provided when generating the base project, and showed him the project board with the tasks I want to work on
  • Simon instantly went for the top item on the todo list: "journal entries should show the related challenge tag instead of id" I hesitated and warned him this one might be too big for our limited time, yet he said: "why not, let's try it!"
  • we explored the code for the journal entry edit dialog, trying to understand where the challenge ids are coming from and how the drop-down list is populated
  • Simon shared that he really values good documentation, especially in these kind of situations; here we don't have any and also the generated code itself is hard to understand and not self-explanatory
  • Simon shared that when exploring an unknown code base he often deletes things to see where they get used and if they are needed
  • we shared knowledge regarding Visual Studio Code features as it's a newer IDE to both of us; Simon really likes it to be lightweight and having a great ecosystem; he likes IntelliJ for their advanced features like search, yet it's rather the heavy lifter
  • we went slowly step by step, and discovered a method named "trackChallengeById" in the journal update component which returned the id of a challenge; we changed it to return its tag instead, yet this did not do the trick yet; we found the method to be used in the related template, where we also needed to change the call to tag - and it worked!!
  • Retrospective:
    • Lisi: Thank you so much! Especially for the courage of giving this task a try. Amazing. Just within 30 minutes we solved a challenge I spent already many hours on. This clearly shows the benefits of pairing!
    • Simon: This was great! Really happy we could solve it, even when exploring the code for the first time. Let's pair again! 
  • TODO: solve the task for the rest of the views as well :)

Besides that?

I've had the honor to present what I learned on my #CodeConfident challenge at TestBash Manchester - an amazing experience. During the conference's open space, we formed a mob and worked on a coding challenge together. Our goal was to experience this collaborative approach and practice our development skills hands-on together. We made progress but did not manage to finish the challenge in the limited time of the open space. The thing is: I couldn't let go working on the it myself! I did not take notes for this one, and yet I'm still trying to figure out how to upgrade MobTime to latest open Java and JavaFx versions in order to then change it's preset alarm tone (or offer more options). Unfortunately I couldn't get it to run (yet). Still, I learned a bunch on this challenge already - and it's yet another project I'd love to pair (or mob again) on! :)

No comments:

Post a Comment