Strategies

One of the simplest is to run those tests manually and check if the monthly budget has not been exceeded. And then do it again and again. However, this does not scale up and sounds ridiculous in the era of automation. Let's proceed to the automated strategy. By marking chosen tests, we can designate when we want to execute them. There are several options here:

• CRON build - run test suites every some determined period e.g. one week, ten days, etc.
• the main branch build - execute tests when something is merged into it
• PR build - run test suites when new changes are pushed into a PR build

Depending on the established budget, you need to choose the best options that fit your needs. In our case, the main build combined with CRON every two weeks does the job well. Enough with the theory. Let's do some real-life coding. As I work mainly with Java, I will show you how to tag and filter tests using the most popular testing framework, JUnit 5.

Marking and filtering tests

We have two approaches here, one of them is to use the @Tag annotation. Example test:

@Test
@Tag("AWS_S3") 
void upload_file_with_size_exceeding_1gb_succeeds() { }

Marked tests can be filtered in the Maven Surefire plugin configuration. Sample plugin registration:

<plugin>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.20.1</version>
    <configuration>
        <groups>AWS_S3</groups>
    </configuration>
</plugin>

When we want to run those suites dynamically for example: in the CI, then we must pass the groups parameter.  For instance: mvn test -Dgroups=AWS_S3. For Gradle users, I recommend the guide for testing: https://docs.gradle.org/current/userguide/java_testing.html

The second option for marking tests is to create and use custom annotations. The key element here will be EnabledIfSystemProperty decoration. Here is the example:

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@EnabledIfSystemProperty(named = "ENABLE_PAID_TESTS", matches = "(?i)true")
public @interface Paid {
}

Having the annotation declared we can decorate a test using it:

@Paid
@Test
public void upload_file_with_size_exceeding_1gb_succeeds() { }

In the above example, we used EnabledIfSystemProperty which means that decorated tests will be executed only if the ENABLE_PAID_TESTS variable is set to true. Some other conditions that can help us achieve the expected result are:

• EnabledIf
• EnabledIfSystemProperty
• DisabledIf
• DisabledIfEnvironmentVariable

I prefer the second approach because it's more readable for me, and configurable than the first one. We can also produce a more concise version of this annotation by adding the @Test annotation:

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@EnabledIfSystemProperty(named = "enable.paid.tests", matches = "(?i)true")
@Test
public @interface PaidTest {
}

I hope these techniques will help you with introducing paid tests as they helped us.

...even if the conference is online only

Participation in the events like conferences and/or meetups was always a good idea. There are lots of articles about it eg. top ones 1, 2 or 3 even the simple query gave you about ~ 150 mln results.

Ok, we are pretty sure about the value it brings. However, let's look closer at the topic. In short, the biggest benefit comes from people interaction. So what we got if we are in the pandemic time, where we can't meet the other people face to face. Well, I'm a tester so I don't take the words for true unless I'll check them by myself. The opportunity I got was an invitation for A4Q World Congress.
A4Q is an organization that "...empowering people and organizations...". It creates syllabuses that give people the ability for certification. Because of this/thanks to this, they are co-working with communities worldwide. And this was the trigger to organize something for the worldwide community. Eventually, the event was a big success, see the numbers (https://a4qworldcongress.com/highlights/), they reached 6,8 mln people.

How about the f2f meeting

The organizers tried to address the communication issues a lot. One of the ideas was to use https://gather.town/. Startup platform where you are becoming the avatar on the previously prepared board. When two avatars are close enough then mic and video are being launched allowing people to talk. If more people are close enough then all of them can talk. Leaving these groups your connection is being dropped. See the lobby.
There was also a dedicated place for company exhibitions when you could talk with its representations.

My feedback: it was my third time when I have the opportunity to interact with gather.town. And I need to admit that only once I was able that say: good idea. The model of the whole open day is not the best idea. People were coming, sightseeing has some small chats and leaving without benefits. Thus my favorite model was about 2h meeting once per day with 1-2 short talks and an open mic option. I don't know how much important was to be part of a somehow already integrated group like mine but I have the feeling that would not change too much.

Let's be in touch

The second idea was pretty obvious. The organizers shared the speaker's social media. So that method was working as well as usual. Or even better :-) my LinkedIn profile was hot that day and a few after. Even now, because talks are publicly available people are coming back to talks and comments. Well I encourage you to do so as well

Takeaways

The events especially the virtual ones are even some bigger challenges. Some methods that worked for the on-site still working fine. Some others can not be replaced 'one to one'. People like to interact with each other but they need a guide or moderation, especially at the beginning. As a speaker, you have the same adrenaline, especially that feedback comes not only after the talk but also time after.

Since we're in the IBM Cloud ecosystem, I thought of App ID—it's an IBM service, and they also provide a very handy sample for WAS Liberty! Almost too good to be true!

It was too good to be true.

The way that OIDC connect client is set up (at least for us!) along with JAX-RS (the underlying framework for our REST service) is that it takes group information from the JWT and uses annotations @RolesAllowed to figure out what is allowed and what is not. App ID, on the other hand, puts this information in the scopes claim of the JWT... I played around with it, I asked on forums, I googled the hell out of it, I visited every place I could on the App ID's service on IBM Cloud, and I failed: I couldn't find any way to put the information I wanted in the token.

So I use Azure Active Directory—that setup took 10 minutes from start to finish to set up*.

After that setup was done, I finally stumbled upon a part of the docs for App ID I missed last time around: Customizing tokens. It turns out you can customize the tokens all you want, but you need to do this via the ibmcloud CLI!

The final setup is more or less like this.

1. Create an IBM Cloud API key for use with the CLI

   API_KEY=$(ibmcloud iam api-key-create APPID)

2. Obtain an IAM access token using the API key

   IAM_TOKEN=$(curl -k -X POST "https://iam.cloud.ibm.com/identity/token" \
   --header "Content-Type: application/x-www-form-urlencoded" \
   --header "Accept: application/json" \
   --data-urlencode "grant_type=urn:ibm:params:oauth:grant-type:apikey" \
   --data-urlencode "apikey=$API_KEY")

3. Obtain your Tenant ID (e.g. from the Applications panel of App ID in IBM Cloud), store it as TENANT_ID environment variable.

4. Obtain the region of your App ID instance abd store it as REGION enviroment variable.

5. Use curl to update the token configuration

   curl -X PUT "https://$REGION.appid.cloud.ibm.com/management/v4/$TENANT_ID/config/tokens" -H 'Content-Type: application/json' -H "Authorization: Bearer $IAM_TOKEN" -d '
   {
     "access": {
       "expires_in": 3600
     },
     "refresh": {
       "enabled": true,
       "expires_in": 2592001
     },
     "anonymousAccess": {
       "enabled": false
     },
     "accessTokenClaims": [
       {
         "source": "roles",
         "destinationClaim": "groupIds"
       }
     ],
     "idTokenClaims": [
       {
         "source": "roles",
         "destinationClaim": "groupIds"
       }
     ]
   }'
       

Combine that with the Open ID Connect Client configuration on the WAS Liberty side:

<openidConnectClient 
    id="appID"
    clientId="${env.APP_ID_CLIENT_ID}"
    clientSecret="${env.APP_ID_CLIENT_SECRET}"
    authorizationEndpointUrl="https://${env.APP_ID_REGION}.appid.cloud.ibm.com/oauth/v4/${env.APP_ID_TENANT_ID}/authorization"
    tokenEndpointUrl="https://${env.APP_ID_REGION}.appid.cloud.ibm.com/oauth/v4/${env.APP_ID_TENANT_ID}/token"
    issuerIdentifier="https://${env.APP_ID_REGION}.appid.cloud.ibm.com/oauth/v4/${env.APP_ID_TENANT_ID}"
    jwkEndpointUrl="https://${env.APP_ID_REGION}.appid.cloud.ibm.com/oauth/v4/${env.APP_ID_TENANT_ID}/publickeys"
    userInfoEndpointUrl="https://${env.APP_ID_REGION}.appid.cloud.ibm.com/oauth/v4/${env.APP_ID_TENANT_ID}/userinfo"
    userInfoEndpointEnabled="true"
    groupIdentifier="groupIds"
    realmName="appIDrealm"
    authFilterRef="appIdAuthFilter"
    signatureAlgorithm="RS256"
/>

And you have a working setup!

Now you can assign access to your application:

<security-role name="reader">
    <group name="appid-reader" access-id="group:appIDrealm/${APP_ID_READER_GROUP_NAME}" />
</security-role>

* Not counting the bug I discovered in WAS Liberty that prevented auto-discovery feature to work.

One way to 'solve' this, if you have an x86 computer, is to use Docker contexts. The process is very simple.

1. Make sure you have Docker running on the target machine (in my case it's my 2017 MacBook Pro)
2. Also make sure you have SSH (aka Remote Login) turned on on that machine
3. Create a context on the M1 Mac: docker context create mbp --docker "host=ssh://jakub@jakubs-macbook-pro-2017"
4. Switch to that context: docker context use mbp

You should be able to do docker ps, and that should show you the running containers on the target machine.

On my setup (which is the default, I suppose), I immediately encountered a problem:

error during connect: Post "http://docker/v1.24/build?buildargs=%7B%7D&cachefrom=%5B%5D&cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=Dockerfile&labels=%7B%7D&memory=0&memswap=0&networkmode=default&rm=1&shmsize=0&target=&ulimits=null&version=1": command [ssh -l jakub -- jakubs-macbook-pro-2017 docker system dial-stdio] has exited with exit status 127, please make sure the URL is valid, and Docker 18.09 or later is installed on the remote host: stderr=zsh:1: command not found: docker

Err... ok... command not found...? The problem was that when connecting via SSH, by default, the PATH is just /usr/bin:/bin:/usr/sbin:/sbin. To change it, I needed to modify /etc/ssh/sshd_config by enabling user environments: PermitUserEnvironment yes, and modifying the value of PATH in ~/.ssh/environment to include /usr/local/bin.

That made the whole setup work, and my old Mac is still useful, while not sounding like a jet taking off (and it can be kept away in the laundry room).

So we have an office now.

My co-founder and I have been working remotely for more than eight years and for three at Smart Coders.

That's quite a change, and there are a few reasons for it, some of them are driven by our clients.
Anyways, we're just getting started, and we still would like to keep the remote-first vibe in our little family, so eventually we'd like our office to be rather a place we can drop-in to have some peace of mind or just to meet in a comfy physical place.
Things one might not be able to get in a regular co-working space.
Another reason is to have desing meetings (both engineering and UX), which proved to be rather hard to have in a remote fashion.

Let's see where this takes us.

The Guardian writes:

The European commission will recommend that EU member states abandon the practice of changing the clocks in spring and autumn, with many people in favour of staying on summer time throughout the year.

Apparently 80% of 4.6 million respondents in an official consultation favored staying on summer time all year round.

I would like to see some studies (other than the experiment in Russia a few years ago) about permanent summer vs. winter time.

An interesting and very well presented study from AND CO about remote work. Being a remote worker myself, on and off, for a number of years now, I find their study to be a great inspiration for some introspection.

Those who’ve worked remotely for 7+ years were far more likely to intend on working remotely forever than those who are freshly remote (0-1yrs). Respondents who’ve worked remotely for under a year are more likely (9%) to find it difficult to stay motivated without a boss looking over their shoulder than long-term remotes (4%).

While I love it now, I wasn't a big fan of working from home at the beginning. I liked the idea, but I wasn't very good at it; the multitude of distractions at home were too big of an issue, I just couldn't concentrate. After an uproductive day, I felt worse if it happened while working from home, than if I had worked at the office.

The breaking point for me came when I didn't have a choice—I moved to Taiwan for 2 months, and going to the office wasn't an option anymore. Like with a flip of a switch, I found that a routine (an oh-so-important aspect of a regular day for me!) of going to a Starbucks, setting up, working hard for 8 hours, and shutting down my computer at the end, was the recipe I was missing.

Truly shutting down at the end of the day turned out to be the next challenge, further exacerbated by the fact that Taipei was 6 hours ahead of Copenhagen, so the end of the day for me was the beginning of my colleagues'. Our daily scrum was the beginning of the day for them, and a sign-off for me. Making exercise a top priority helped with that—I really needed to go for a run before dinner!

The most difficult and frustrating aspect of working remotely—in an environment where most still work from a single office—has been, over the years, that a lot of things are established at the water cooler, away from Slack or any other online tools, and I have to put in way more effort to be a part of all important discussions.

But my colleagues are more and more accustomed to a remote way of working, and we're all more empathic towards the challenges that remote work poses to both remote and co-located workers.

And empathy is probably the most important trait of any co-worker, sharing an office or not.

A while ago we’ve participated in a discussion about the pros and cons of using assertJ and assertThat over assertTrue¹.

We’ve heard some arguments against using assertThat and assertJ that we really did not anticipate (e.g. a dev expressed that he prefers to see exactly what methods are being tested, as opposed to relying on auto generated code). We’ve given examples and arguments of why assertTrue is inferior to the two other methods, but we couldn’t quite convince assertTrue supporters.

Recently, after being affected by a test written using assertTrue, I've decided to

First, a little back story

I've just merged changes made on develop into my own branch. I've noticed that a couple of things weren't compiling, so I went ahead and fixed them. The issues with compilation were fine, because I changed the return type of a method from String (that was a hex-encoded byte[]) to byte[].

After making some code fixes, I ran the tests (which also needed slight tweaking), and got a failure.

The Tests

Assert True

Observe the following test method, written using assertTrue:

@Test
public void get_public_key_hash_returns_hex_encoded_sha256_assertTrue() {
  // get the public key hash
  CryptoSystemApiDelegate api = new CryptoSystemApiDelegate(ivCryptoApiLifeCycle, ivApiKeyVerifier);
  Response res = api.getPublicKeyHash(API_KEY, null);
  Object entity = res.getEntity();

  // test the hash
  Assert.assertNotNull(entity);
  Assert.assertTrue(entity instanceof PublicKeyHash);
  PublicKeyHash pubKeyHash = (PublicKeyHash) entity;
  Assert.assertTrue("PublicKeyHash.algorithm is not SHA-256", pubKeyHash.getAlgorithm().toString().equals("SHA-256"));
  Assert.assertTrue("PublicKeyHash.value is null.", pubKeyHash.getValue() != null);
  Assert.assertTrue("Public Key Hash Value is not a SHA-256 value", pubKeyHash.getValue().length == 64); // Hex Encoded SHA-256 is 64 chars
}

and the output it produced:

java.lang.AssertionError: Public Key Hash Value is not a SHA-256 value

at
xyz.smartcoders.CryptoApiLifeCycleIT.get_public_key_hash_returns_hex_encoded_sha256_assertTrue(CryptoApiLifeCycleIT.java:94)

Ok... what the hell does it mean that it's not a SHA-256 value?!? What does that mean? The way to find out? Debug. What does it cost? Time.

In an attempt to learn more (and to have a better insight to see if there's qualitative improvement in using different approaches), I've rewritten the test using assertThat and assertJ.

Assert That

Now observe output of a modified test method, written using assertThat:

@Test
public void get_public_key_hash_returns_hex_encoded_sha256_assertThat() {
  // get the public key hash
  CryptoSystemApiDelegate api = new CryptoSystemApiDelegate(ivCryptoApiLifeCycle, ivApiKeyVerifier);
  Response res = api.getPublicKeyHash(API_KEY, null);
  Object entity = res.getEntity();

  assertThat(entity, is(instanceOf(PublicKeyHash.class)));

  PublicKeyHash pubKeyHash = (PublicKeyHash) entity;

  assertThat(pubKeyHash.getAlgorithm(), equalTo("SHA-256"));
  assertThat(pubKeyHash.getValue(), notNullValue());
  assertThat(pubKeyHash.getValue().length, equalTo(64));
}

and the output it produced:

java.lang.AssertionError: 
Expected: <64>
     but: was <32>

at xyz.smartcoders.CryptoApiLifeCycleIT.get_public_key_hash_returns_hex_encoded_sha256_assertThat(CryptoApiLifeCycleIT.java:115)

Bingo! That's more like it! The returned value is 32 bytes long, not 64 as was expected! Because it's not hex-encoded anymore, it's just a byte array, so the value is 32 bytes long, indeed!

That's already enough to quickly figure out what's wrong, and how to fix it.

AssertJ

To get a better picture of what I could expect from assertJ, I've decided to write the same test using just that.

@Test
public void get_public_key_hash_returns_hex_encoded_sha256_assertj() {
  // get the public key hash
  CryptoSystemApiDelegate api = new CryptoSystemApiDelegate(ivCryptoApiLifeCycle, ivApiKeyVerifier);
  Response res = api.getPublicKeyHash(API_KEY, null);

  Object entity = res.getEntity();

  assertThat(entity, is(instanceOf(PublicKeyHash.class)));

  PublicKeyHash publicKeyHash = (PublicKeyHash) entity;

  PublicKeyHashExtendedAssert.assertThat(publicKeyHash)
    .hasAlgorithm("SHA-256")
    .hasValueWithLength(64);
}

Let's pause here for a moment, before looking at the output. Looking at the code, you immediately see that you're expecting the public key hash to be a 64-byte long SHA-256 value! With so little code! And just take a look at the output it produces:

java.lang.AssertionError:
Expected size:<64> but was:<32> in:
  <[-63, -17, 64, -6, 41, -75, -40, 75, 74, 89, 35, -12, 81, 91, 97, 47, 47, -21, -77, 32, -41, -30, -106, 26, 50, -65, 69, -94, -1, -55, 96, -65]>

at xyz.smartcoders.CryptoApiLifeCycleIT.get_public_key_hash_returns_hex_encoded_sha256_assertj(CryptoApiLifeCycleIT.java:135)

The output is just as useful as that of assertThat, but it also provides the byte[] that was being tested. While in this case it's not very useful, as the value is random, it might be very handy in other tests!

Conclusions

I think that this demonstrates, beyond any doubt, in my mind, that assertTrue is by far the worst, giving you the least context. assertTrue also heavily depends on the developer correctly and clearly expressing what is being tested. If the description is not clear, the result of the test will not give you any indication about what's wrong at best. At worst, it'll confuse the heck out of you.

assertThat is far better; it's good enough to quickly figure out what's wrong. The description is provided by the framework, so the developer doesn't need to spend time writing potentially confusing messages.

assertJ is by far the best. It's not only concise in expressing expectations, but also in providing the most context to facilitate quick and painless fix.

Footnote

If you say that I should have thought about changing the expected length of the public key hash from 64 to 32 upon changing encoding—you're right! I'm sure you would've caught it and it wouldn't be an issue. But I'm not that good; I'll take any help I can get to fix things quickly.

1. I need to underline that my gripe is with the abuse of assertTrue for all assertions in test code. I'm not saying that assertTrue is not the way to go when testing boolean values. What prompted me to write this was the proliferation of tests written using assertTrue exclusively.

Ars Technica reports:

Earlier this week the European Parliament voted 384 to 153 to review whether Daylight Saving Time is actually worth it. Although the resolution it voted on was non-binding, the majority reflected a growing dissatisfaction with a system that has been used by the US, Canada, most of Europe, and regions in Asia, Africa, and South America for decades.

While I feel that we should settle on summer time (not winter time), it’s not as clear cut as I thought it would be:

Still, it seems that choosing whether to stick with winter time or summer time is key in a transition away from Daylight Saving Time. Years ago, Russia tried to go on permanent summer time, but changed to permanent winter time in 2014 after the summer-time-in-winter change gave people stress and health problems when it stayed darker for longer during winter mornings, according to the BBC.

I hope that Betteridge’s law of headlines doesn’t provide the answer.

Rich Mogul, writing for Securosis:

Apple didn’t just throw a facial recognition sensor into the iPhone and replace a fingerprint sensor – they enabled a new security modality. I call this “continuous authentication”.

I’ve been thinking about it ever since getting the new iPhone X. The way Apple implemented integration between parts of iOS and FaceID shows a level of attention to detail unseen in other companies, and a great security design overall.

Via Daring Fireball.

I’ve been on vacation* since Friday afternoon, but I didn’t manage to close everything that needed to be closed before leaving. My wife also needed to finish some things for work, so both of us spent Monday and a chunk of Tuesday working. My wife came better prepared; she came with her laptop, since she’ll be going to a conference straight from our vacation, 3 weeks from now.

I made a conscious choice of not taking my laptop with me. I only came with my iPhone and iPad.

This is the first time I actually needed to get things done using only my iOS devices, and they passed the test with flying colors! Thanks to IBM’s embrace of GitHub Enterprise, Slack, Bluemix, and Box, I was able to access all my files, code, and talk to my colleagues without a hitch.

I did not do any coding, but I did review some PRs, comment on and close some issues, and update some wiki entries.

What I’ll need to make it even better in he future is a keyboard; the virtual one takes up too much of the screen.

*No one said work-life balance was easy, especially when you care about the project.

The Jazz scm command does not seem to play nice with maven-release-plugin.

When doing a mvn release:prepare, things are going fine, until, at the very end, Maven returns a build failure:

Error code for Jazz SCM deliver command - 53

After a quick internet search, it turned out that error code 53 "Indicates that a deliver succeeded, but there were no changes to deliver to the repository".

Well... ok...

Luckily, the Jazz scm command is nothing more than a shell script! So it was very easy to change that "error code that means success" into an actual 0 that Maven expects from successful executions:

if [ "$USE_NATIVE" = "1" ]; then
    "${PRGPATH}/fec" "$@"
else
    java -classpath "${PRGPATH}/plugins/com.ibm.team.filesystem.cli.minimal_3.1.600.v20140108_0240.jar:${PRGPATH}/plugins/com.ibm.team.rtc.cli.infrastructure_3.1.800.v20140619_0246.jar:${PRGPATH}/plugins/com.ibm.team.filesystem.cli.core_3.2.400.v20141011_0139.jar:${PRGPATH}/plugins/com.ibm.team.filesystem.client.daemon_3.1.500.v20130930_0113.jar:${PRGPATH}/plugins/org.eclipse.equinox.common_3.6.0.v20100503.jar:${PRGPATH}/plugins/com.ibm.team.filesystem.client_3.2.400.v20141015_1622.jar:${PRGPATH}/plugins/org.eclipse.osgi_3.6.50.R36x_v20120315-1500.jar:${PRGPATH}/plugins/com.ibm.team.repository.common_1.4.200.v20141015_2351.jar" com.ibm.team.filesystem.cli.minimal.client.FrontEndClient "$0" "$@"
fi

required addition of just a couple of lines right below:

RESULT=$?

if [[ $RESULT -eq 53 || $RESULT -eq 52 ]]; then
  exit 0
else
  exit $RESULT
fi

And that's it! The mvn release:prepare command completes successfully.

Unfortunately, running mvn release:perform yields yet another error, that I'll discuss some other day.

Ian Cuttress for Anandtech:

Price for Performance is still one of AMD's strong points. For the multitude of tests where that $499 1800X is able to match or beat a $1049 i7-6900K, it directly translates to a 2x in price/performance.

Other processors have a smaller price/performance ratios, but they're still giving Intel a run for its money.

It's good to see competition in the x86 CPU space again. Looking forward to future updates.

Source: anandtech.com.

When you're hit with a server startup timeout in Eclipse, suggesting you should increase the value, it's actually Eclipse's setting, not the server's. You can change it in the server’s settings in Eclipse:

The two PDF files shared as proof of the attack can be considered weapons:

[...] SHA-1 colliding files are currently breaking SVN repositories. Subversion servers use SHA-1 for deduplication and repositories become corrupted when two colliding files are committed to the repository. This has been discovered in WebKit's Subversion repository and independently confirmed by us. We noticed that in some cases, due to the corruption, further commits are blocked.

Via shattered.io