March 2018

277 tweets

Async rendering in #react will remove so much clunky handling of "wait for
content to be available" code.

It's so great how the @reactjs identified an
improved from which both developers and users will benefit.

#jsconfis

Amazon Dash is illegal in Germany, a German court ruled in a lawsuit by a
consumer protection office:

  • Users have to be informed about the actual item and price before the order
  • Button must have notice that using it creates a payable order
    ("zahlungspflichtig bestellen") #iot
Replying to @coderbyheart

I have a frontend project with 30-something dependencies just for building the
project (rollup, babel, ...) and these receive updates every day. This is not an
issues when working with the latest code, but when fixing bugs for older
releases of the project, it gets nasty.

Replying to @coderbyheart

Since your package.json might include dependencies which are not fixed, but
point to some version of a package through the use of "^1.0.3", you will end
up with an arbitrary configuration of you build chain, when doing a git checkout
old-release; npm i

Replying to @coderbyheart

This might break, and for me it did yesterday.

It took me roughly two hours to figure out what is wrong, and since I am not an
expert for this specific build chain. In general it's hard to retrace bugfixes
and breaking changes anyway.

Now npm ci could have saved me:

Replying to @coderbyheart

If you maintain an up-to-date package-lock.json (by using npm 5), npm ci will
install the exact dependencies from the lockfile where an npm i will install the
latest release that matches your version specification in package.json. This
means you can retrieve exact configurations.

Replying to @coderbyheart

So, npm ci gives you the ability to keep the forward looking way to manage
dependencies in JavaScript we all love but gives you the safety that you can
always go back in time to a configuration which once worked.

Replying to @i_a_r_n_a

@ReBeccaOrg Hm, maybe show a summary of updated lock entries.

Yes, you see that the lock changed if you use SCM, but I sometimes do multiple
sessions and then I might not notice.

Or something like npm which-locks-changed which print me the diff (based on git
diff).

Here are some better alternative names for the "master" branch in your source
code repository:

  • bleeding-edge
  • nevergreen
  • works-on-my-machine
  • happy-merging-XD
  • there-be-real-users
  • features-come-here-to-die
  • (L°O°)L*|*|_
Replying to @coderbyheart

No seriously: there are teams discarding the use of the master/slave
terminology. And if you think about it, master is the wrong word for the branch
of the source-code repo which, for the most projects I have worked in, contains
the latest source code.

Replying to @coderbyheart

"master" has the meaning of being a owner and controller over others. But if you
are using feature branches, the control is actually inverted, and master is
"controlled" by the feature branches.

Here are two PR review comments for the same problematic code:

  • This is wrong because ..., fix it by doing ....
  • I have observed that ..., did you, too? Why did you choose that approach?

The first one focuses on fast results. The second one focuses on learning.

Replying to @coderbyheart

PRs are one of the best ways to incorporate daily learning and knowledge
transfer in an asynchronous and very hands on way.

Don't miss out on this opportunity.

Replying to @ainmosni

@ainmosni Branch names in Git are just strings.
I never experienced problems in tools when there was no branch named "master".

Obviously, if you have other tools that hardcore branch names for their
workflow, then these are the problem.

I'm really happy to be speaking @ndc_conferences in June in Oslo.

I'll show how easy it is, to build a secure #IoT product prototype using
#JavaScript and the @Espruino Wifi.

This will be my first conference as a speaker in the Nordics.
Embedded Photo

Replying to @jthegedus

@jthegedus
@ericghill
@storchp Right, because this is a fix which is
obsolete on saga.

This is the case where you discover something that needs to be fixed on
production, but is not an issue in saga.

Because otherwise you could juts fail forward: fix in saga, and deploy to
production.

Replying to @helloanselm

@helloanselm Ok, lets unpack that:

Brand Building: conferences / events put quite a lot of effort into building a
brand and publicity. They create there own website which comes with their way of
presenting info about talks an speakers.

Replying to @coderbyheart

@helloanselm On external platforms they will
have to compromise on layout / design in order to fit the platforms schema of
doing things (lengths of texts, use of links, social media profiles, pictures,
downloads, videos, ...).

Replying to @coderbyheart

@helloanselm This creates two barriers: extra
work required to adapt the original content to the platform.

I don't have concerns regarding discoverability. Centralized, curated services
usually help to discover events.

Replying to @JanSchfr

@JanSchfr Well, this is a new system and there
are some architectural decisions which have to be thought through. We have a
dozen use cases defined (from simple HTTP requests to export Gigabytes of data).
I'd like to have a good understanding a'bt the implications of these
requirements.

Replying to @coderbyheart

@JanSchfr Of course I could bootstrap a Django
REST Framework ... But I know that the most direct way to implementing the
simplest feature won't help me in this case.

We have a good proof of concept already, so this is more of a 2.0.

So you know these are typical log levels:

Fatal Error Warning Notice Info Debug

We need to think about new log-levels:

Chat Comment

so your AI can express itself.

http://console.chat('Hey, fridge! What's up?!') console.comment('Dang, that
TCP header looks fishy!')

Imagine how development would change if EVERYTHING was instant.

Opening a webpage Deploying to production Building a release Searching in Source
Code

No more spending half of the time in this nirvana where you can't do anything
else because its not worth switching.

That strange #softwaredevelopment feeling when you simplify one thing away and
it turns up at another location.

Replying to @Paratron

@Paratron Yes, but long-term use outside of the
home country might be against their terms.

And at least the calling will be more expensive (between German numbers and the
one from abroad).

Replying to @RReverser

@RReverser I agree this adds another wierd
looking syntax to the mix.

We already have that, with destructuring assignments, arrow functions.

And also complex paradigms exists, once you start to move from callbacks to
promises.

Or dependency management, modularisation, frameworks.

Replying to @coderbyheart

@RReverser JavaScript is for beginners is like:
"This is a hammer, and here is how you apply it to a nail." "Oh, nice. So easy!"
"Ok, next step: here is the location of the hardware store. Now build a house.
kthxbye!"

Ohhhh. I just learned that @awscloud lambda
instances are shared between aliases. This resulted in a pretty nasty, hard to
debug issue, since I use the same code for different production environments.

Replying to @c089

@c089 It's sad that some places have this culture,
and the sad part is that it is reinforcing itself.

I had some terrible experiences with the startup culture in the last years and
at some point I decided to change some fundamental parameters in the way I find
teams.

Replying to @coderbyheart

@c089 I took me five years to realize that.

I also had a long talk with a friend who wanted to leave the industry because of
toxic masculinity. We both know a bunch of very awesome humans, and I know that
not all teams are crap.

Lets say you want to ensure that a dozen+ #JavaScript repositories follow the
same conventions for

  • settings in package.json (license, publishConfig, ..., scripts, deps)
  • .editorconfig
  • commitlint settings
  • tsconfig / tslint.json
  • README badges

How would you automate that?

Replying to @ManuelBieh

@ManuelBieh So you mean I keep the non-code
config stuff at the top-level, and can run most of the check against the entire
source code repo.

I like the hard boundaries that separate modules and repos give me.

I'm not to eager to try that. We currently have a monorepo and it is pain.

Replying to @ManuelBieh

@ManuelBieh I'm thinking something more
developer-friendly: $ npx mary-poppins will check and warn if some settings are
off, and $ npx mary-poppins --fix will apply changes. Developers would need to
commit them...

Today is one of the few days I'm regretting moving to
@TutanotaTeam ... Having an email archive
that is not searchable is a huge PITA when I'm looking for certain transactions
/ discussions that happened via email.

Replying to @coderbyheart

I'm still using email daily, but there are only three people I know, who use
Tutanota. And with all of those I communicate via
@signalapp ... So this leaves only the added
privacy that the provide cannot read my emails, which creates many of the issues
I have:

Replying to @coderbyheart
  • no full-text search on all devices
  • no server-side email rules

Added to that are things which are Tutanota specific like poor performance of
the mobile app and no way to turn off mobile notifications when using the mobile
app.

Are you a software developer and looking to make a contribution to your local
community?

It's as easy as showing up once or twice a week for two hours and hanging out in
Slack.

You will make a difference and change someones life forever who is not as
privileged as you. >

Replying to @coderbyheart

You don't need to have a lot of experience, what is most important is that you
love explaining and that you are patient. Many of the newcomers never had the
chance to receive the same basic school education we did. Many of them started
to use a computer just shortly.

Replying to @coderbyheart

But the work you will be doing enables them to receive a certificate and after a
special test they will receive accreditation from a local IHK which counts
towards the regular "Ausbildung" as a developer.

Replying to @coderbyheart

Essentially you will be helping them to be able to find a trainee position on
the regular job market within a year.

This shows how dedicated the @Code_Door
students are.

It's an incredibly satisfying kind of work, and it's a lot of fun!

Replying to @coderbyheart

This book follows an easy to follow structure:

How a defect looks like Why it happens How to get better

It offers very concrete examples and will save you a ton of consultancy fees.

I would recommend printing out sections of it and hanging them in your bathroom
stalls!

Replying to @coderbyheart

There exists great tooling to manage project dependencies and you are always
free to not use a dependency and write your own code.

Blaming @npmjs for making it too easy and enjoyable
to publish a package is ridiculous.