September 2020

245 tweets

Developing software feels very often like banging rocks together to make a fire.

But hey, eventually it's 🔥!

Replying to @coderbyheart

It's connecting and send data to AWS cloud! Pretty nice and reliable on the
#nRF9160. Cloud connectivity (MQTT+TLS) with the EspruinoWifi reaches it's
memory limit, so there it was not so straight forward.
Embedded Photo

It gets a little painful to keep CRA and #TypeScript working nicely together, so
I am really thinking about trying on of the new build-free tools like @pikapkg's
Snowpack or Vite.js...

How about a @codefreeze_fi / #codebreeze
connect edition? We have two afternoons/evenings (or weekend) where we hang out
together and we encourage juniors to join so we can pair with them and help them
review code, ideas, CVs, etc? We can make the SoCraTes idea span the globe!

With most codebases being small enough to fit entirely in a computer's RAM, I
feel we are being held back by having to manually organize code in files. It's
compiled anyway before getting executed. This is 30 year old cruft which is not
needed for many languages today.

Replying to @Argorak

@Argorak
@Hagenburger I think there is a slight
preference towards using "softwarecrafter" over "softwarecraftsperson", while
the latter is also getting used regularly, especially when people use it to
identify themselves. Crafters is way shorter than craftspeople, when speaking
about a group.

Replying to @techbubble

@techbubble I find that there is no
deterministic way to arrange code in files. It's very much a decision by taste
and varies greatly. There is significant effort involved coming to a solution,
but also when re-arranging code. With little overall benefit.

Argh, it took me two days to figure out that @Azure
IoT hub consumer group names are case-sensitive, but only allow lower-case
letters (will be silently swallowed).

I used snakeCase in my Azure function.json, so the events would not arrive.

This is a picture from yesterday: crafters in the #moria refugee camp made 6.000
masks to go directly to be distributed there. This is enabled by a
@DistributeAid campaign started together
with Team Humanity to raise funds for the makers in the camp. I hope it can
continue.
Embedded Photo

Critical developer skill: learn how search engines work.

Because you have to dig through tons of outdated Wiki pages in your company.

Replying to @Ravetracer

@Ravetracer I know my way around in our Wiki,
but it's a monster. Our search basically works by knowing which person to ask to
give you the link to the Wiki page containing the topic you are interested
about.

@spazierendenken To be fair: I don't know any wiki that makes maintaining the
validity of information easy.

It should be a built-in feature that the Wiki notifies authors on a
per-paragraph section to confirm that the information in there is still valid,
and also provide ways to archive them.

Replying to @coderbyheart

It is not possible to expose these underlying services in with strong
consistency without a huge impact on the time it takes to fulfill a request that
applies changes those underlying components.

Replying to @coderbyheart

@maaretp
@AltomSays It's similar to BDD, but the
advantage of using a graph is that you don't need to think about all the
combinations, the graph will take care of all possible mutations.

Very good match to Domain Driven Design: these test descriptions could be the
outcome of Event Storming.

The second #testcraftcamp session was about which kind of documentation supports
testing, and it turned into a great exchange about documentation in general,
weather it's needed at all, ...

In the end there is no one-size-fits-all solution when it comes to
documentation:

The 4th session I attended at #testcraftcamp we talked a lot about how tests,
developers, and testers relate to each other. A good knowledge sharing session
with input from many perspectives.
Embedded Photo

Big kudos to the attendees and the team of #testcraftcamp who made it feel close
the real thing. Exceptional organized and very interactive sessions. Thank you!

I look forward to the next edition!

Replying to @maaretp

@maaretp if companies do not adapt they will be
eaten by the hundreds of thousands of makers around the globe who also have
access to fabs that deliver a new design within days around the globe ... for a
tiny fraction of the cost it used to take 5 years ago.

Replying to @gareth

@gareth I think the point is that you know how to
build one of those where you live and also be able to make one that fits your
needs.

From a practicality standpoint you would be able to buy it (including the lot).

I really like the https://openmoji.org/ icons, they are a nice alternative to
the typical glossy and clean emoji sets i know. Their hand-drawn style really
emphasises the playful emoji character while making them easier to distinguish.
Embedded Photo

Today in connecting things to the internet using JavaScript: I want to automate
testing @bifravst on real #nrf9160 devices, so I
need to expose flashing the device and observing device's UART output to the
internet for a CI runner. That's going to be fun!
Embedded Photo

Replying to @_vojam

@_vojam I'm running JLinkExe of
JLink_Linux_V686_arm on the 64 Bit raspbian and get

./JLinkExe: error while loading shared libraries: libstdc++.so.6: cannot open
shared object file: No such file or directory

Do you know why?

Replying to @_vojam

@_vojam It seems there is no lib32stdc++6 for
ARM64, so I might go back to 32 Bit raspbian ... I wanted 64 for Node.js but I
can write the controller component in Go as well.

Replying to @pati_gallardo

@pati_gallardo Well, they really cover
different aspects. Cypress is for in-browser UI-tests, this tests the
high-level, happy-path of your application. It's hard to maintain and if you
find errors it's typically not straightforward to locate them.

Replying to @coderbyheart

@pati_gallardo So it's important to have
unit-level tests and jest is a good framework for that. It's also magnitudes
faster to test here. I know TDD fanatics who entirely stopped using Cypress
because the efforts to maintain it in addition to unit tests often outweigh
the gains.

Replying to @coderbyheart

@pati_gallardo You would need to write your
React app as stupid as possible, and any put any slightly more complex logic
into modules that can be unit-tested.

What then can go wrong (especially when using TypeScript) is so little that
Cypress is a waste of time.

Replying to @pati_gallardo

@pati_gallardo When dealing with JSON I
move that code into a function which ensures the the data is correct (or knows
it for a fact), and returns typed values to the rest of the application, so one
does not need to deal with untyped values in the rest of the code.

Replying to @coderbyheart

A lot of technology does not consider real world problems, and since technology
is now all around is it becomes dangerous to human safety.

Not only through physical harm (e.g. Tesla not recognizing jaywalking), but also
can creep in areas and expose people to (physical) abuse.

Replying to @coderbyheart

One of the biggest reasons: most technology is not optimized for testability. So
it's not easy to make verifying the quality (and often diametrical requirements)
of a system a straightforward activity. Which it needs, to be to able to develop
and maintain a robust product.

Replying to @coderbyheart

Things that we can do to start getting on top of things again:

  • invest into observability & traceability: it's important to understand how
    a system behaved and why. Especially with more and more AI systems around,
    there are no longer humans who made the rules.
Replying to @coderbyheart
  • write less code: feature creep is the biggest enemy of robust systems. The
    question always needs to be: does the customer really need this?
  • more respect for humans: loose the idea that humans can be simulated by
    algorithms. They are far too complex.
Replying to @coderbyheart
Replying to @coderbyheart

@jaredwolff Flashing took a while longer
compared to your docs.

When the device connects the first time, it will be disconnected: this is
expected, because AWS JITP kicks in and sets up the device on the cloud side.

It seems that the sample does not reconnect. I had to reset.