December 2017

251 tweets

Replying to @jke

@jke Das Problem ist vor allem, dass E-Mail als
Ablage verwendet wird. Wenn man hin will zu einfacher verschlüsselter
Kommunikation in Unternehmen: Signal, Telegram, WhatsApp. Und die Projektdaten
zentral ablegen.

"We have no managers and are in need of none.

We are not crazy, mind you. The company didn’t collapse. Conversely, the
retention has improved, motivation went through the roof, and financially the
company has never been more stable as it is now." https://vimeo.com/208635546

I thought about how to generate JSX from plain HTML, which would enable having
an HTML design styleguid which can evolve out of which JSX is generated
automatically.

This would create a better separation of concern for app logic / design.

Despite heavy snow 🌨 on the roads, many
@NordicTweets employees here in Trondheim 🇳🇴
bike to work 🚵➡🏢. The bicycle parking stands are full.

A heated garage, a place to wash your bike and hangers for wet cloth make this a
very comfortable activity!

Replying to @SamirTalwar

@SamirTalwar I have no definite answer, but
the underlying question is, what story should master tell: A story of how the
code came into existence, or A story of when it became active. Because only when
it is in master, its available to others (or your prod system).

Serverless Computing Serverless Databases

came to make our jobs as developers easy.

...

I sometimes dream of

Computerless Users

Replying to @coderbyheart

In general, try to avoid filtering out properties from objects, since this opens
your code up for unexpected side-effects.

In most cases you are far better off in return only known properties. And with
ES6 this is really simple to achieve:

({prop1, prop2}) => ({prop1, prop2})

Replying to @coderbyheart

Since Template Literals cannot be constructed at runtime, your template string
cannot come from a variable, but must be constructed using backticks (`). So if
you load the string from the database, it is as simple as replacing the
placholder.

Replying to @coderbyheart

Use very restrictive code like:

const templateString = 'abc${val}def' // could come from a database ... const
val = 'f00'; console.log(templateString.replace(/${val}/g, val))

which replaces the exact instace of the placeholder, nothing else.

Replying to @coderbyheart

Don't do things that evals all variables. In most cases (e.g. rendering an email
subject), the names of the variables are known and defined. Support only that.

In the original case of the code, there would have been ever only one
placeholder...

.@NordicTweets three core rules

  1. Foresight over hindsight - focus on what we gonna do in the future
  2. Optimism over Pessimism - be optimistic about the future
  3. Opportunities over Problems or Risks - think opportunity-based when talking
    about risks
    Embedded Photo

👋 Feel free to pick my brain any time!

Ask me about programming (web, backend, APIs, Node.js, JavaScript, AWS, ...),
software craft (Testing, Quality, Releasing), career advice, leadership and
agile methodologies.

If you are in Trondheim 🇳🇴, meet me for a coffee! ☕

Replying to @and_php

@andreas_php The nice thing: BDD focuses on End User Value (happy path tests)
and is a great resource for providing a living system documentation.

@jezenthomas You also read THAT article ;-)

I only worked in "closed" SaaS teams, where customers have no reason to share
their data (because its secret or proprietary).

It's very hard to grow in this kind of scenario.

Replying to @Sarky_de

@Sarky_de This obviously depends on the
situation when you join the team, but it's always important to start with
listening to the team: do intensive 1:1 sessions with everyone in the first
week, and then continue to have 30min 1:1s every week with everybody in your
team.

Replying to @coderbyheart

@Sarky_de Resist the urge to change to much
right away, instead ask a lot of questions (no judging!) and use the first
months to get a detailed understanding of roles, competences and the whole tech
stack. Share your observations with the team, an outside perspective is super
valuable.

Replying to @Sarky_de

@Sarky_de If you are concerned about efficiency
with some of your team members, there are better ways:

Make the impact of the non-efficency transparent, don't judge, just state facts
(e.g. time it took to build a feature, which equals money spent).

Replying to @coderbyheart

These days REST is but a subset of API technologies and handing a REST API out
as a contract to your service will limit your ability to evolve it in the
future.

I would rather provide high-level SDKs for language that encapsulates your
underlying communication mechanism.

Replying to @coderbyheart

An SDK is so much more powerfull in providing an expressive and meaningfull API,
including the communication of deprecated methods, typings, because it can be
written to suit your domain, and does not neet to fit in the REST vocabulary.

Strange, once in a while I discover that I am no longer following accounts I am
100% sure I was following in the past.

Gløgg is to Glühwein what Brunost is to Käse, how a German coworker put it. He
was right. It's basically sugarwater. Like drinking a heated up coke.
Embedded Photo

Replying to @rradczewski

@rradczewski Lambda can be compared to
express.js in terms of what it encapsulates for you.

Moving JS business logic out of lambda is very simple, since the lambda API is
very straightforward:

event object for data input callback for result / error signaling.

When engineers have to come up with Heart Rate Monitor sample data ...

Most humans would be dead after 1-2 Minutes.
Embedded Photo

Replying to @rradczewski

@rradczewski I really love that there is a UI
for eploring capabilities and services. It gives you a much easier way to
understand their services.

Complex setups will take a long time to get right, so it's great to have a "dev"
account to tinker, and a "prod" account to manage via code.

Today is Winter Solstice, and my first one in Norway 🇳🇴. It's now 9:30 and still
not fully light. By 15:00 it will be dark again. Luckily I am not affected by
this, seing a lot of snow and biking to work every day seems to be a good treat
against winter depression.

@jezenthomas Disk imaging is pretty useless if you do not have physical access
to the server so you could restore the disk image after a crash.

You would only backup your application data, and configuration files (typicall
all that is in /etc) to a /backup folder (once per day) >

@jezenthomas Yes, ideally you can spin up a new instance of your server
automatically. If you have that (and the recipes are versioned), then you need
to back up the "dynamic" data.

@jezenthomas Yes, it would pay off to do a run of your strategy. Buy a second
server and set up everything there from backup.

Replying to @ulope

@ulope That would be impossible. And useless, since
you can infer other other language's SDK from reference implementations.

Also, you can always access the underlying API but I would not put the same SLA
on that.

Replying to @jurgenappelo

@jurgenappelo
@james_clear Their arguments are strange,
they did write enough words for two books, but nevertheless no book was created.

Activity without direction (goal) can yield results, but won't they be much more
random?

Having a goal means I can check if I am progressing in the right direction.

Replying to @SamirTalwar

@SamirTalwar ... selling, documenting,
evangelizing, teaching, ...

It's hard to focus on one profession only (e.g. coding) because you will then
lack in the other fields.

Balance is so important in our work.

The thing is now a JavaScript powered #iot display, the icons are transferred
via an encrypted TLS connection directly from AWS IoT. Updates take <1s to
appear on the device so that even simple animations are possible.

Replying to @datenreisender

@datenreisender I share our CTO and CFOs
observation, that engineers are great in identifiying risks and then oftentimes
are too easily consumed by trying to prevent them as much as possible.
Oftentimes the probability of the risk is highly overestimated and the total
cost estimated falsely.

Replying to @coderbyheart

@datenreisender These intentions are good,
but will limit the ability to move quickly and boldly, which is one of the
advantages a relatively small company like Nordic has: the ability to make quick
decisions and to take risks, because we have the knowledge to fix things
quickly,

Here is something for you #agile practitioners to do in 2018:

Can we have space for people whose energy is drained by all the interaction that
is promoted in all agile methods?

Replying to @coderbyheart

In case you haven't noticed: everything focuses on human interaction and all
material focuses on how to "design" human interaction so that it yields results.

Replying to @coderbyheart

What I don't see in books, articles, vides is a strong reminder, that man will
have their energy drained by constant interaction.

Of course, there is an implicit [space] between activities which some people
will actively use to retract and recharge.

Replying to @coderbyheart

But not everybody can muster the courage to actively do so, if the environment
we as agile coaches and trainers are presenting the ideal does not mention
"alone-time"; they will see their need to have solitude as something
unfavorable.

Replying to @coderbyheart

@untertanaermel On being vulnerable: Read
/ Listen to Brené Brown: https://www.ted.com/speakers/brene_brown

Transparency: means having no secrets / power through information brokering.
Start here:
https://www.fastcompany.com/3036794/why-a-transparent-culture-is-good-for-business

On bonuses: individual bonuses hurt company goals. Start here:
https://www.forbes.com/sites/groupthink/2014/06/07/the-dark-side-of-bonus-and-incentive-programs/#4285e56b756d

Replying to @untertanaermel

@untertanaermel Death march projects are
not sustainable, and the math is very simple: losing employees and their
knowledge costs much more than 6 month of operational costs.

But: this is not your behavior, but their decision. So you can keep doing these
kinds of projects.

Replying to @coderbyheart

@untertanaermel If you are two lazy to
explain company policies to juniors, how will you make sure they will not
violate them unknowingly, because they don't fully understand them.

That means you have to watch their every step, which will totally limit your
ability to grow juniors to medias.