Tim boosted

RT @netzpolitik@twitter.com

In meinen Vorträgen hab ich diese Probleme bisher immer theoretisch beschrieben. Der Lidl-Thermomixer bestätigt eindrucksvoll, dass wir zuwenig Verbraucherrechte im Smart Home verankert haben.

Es darf nicht sein, dass solche Massenprodukte so unsicher verkauft werden.

🐦🔗: twitter.com/netzpolitik/status

My next steps:

1. Move from iCloud to Nextcloud [1] (home-hosted; next weeks)
2. Move from macOS to Elementary OS [2] (hopefully this year)

[1]: nextcloud.com
[2]: elementary.io

"Wir wollen keine Hintertüren für verschlüsselte Daten."
"Wir wollen einen staatlichen Zugriff auf verschlüsselte Daten."

zeit.de/digital/datenschutz/20

Tim boosted

"Big-Tech"-Konzerne wie Google und Facebook sind das Ergebnis von hunderten Unternehmensfusionen. Von den meisten Unternehmenskäufen bekommt die Öffentlichkeit gar nichts mit. Aber das ändert sich gerade. Die New York Times haben einmal visuell aufbereitet, wie #Google und #Facebook so fett geworden sind.
nytimes.com/interactive/2019/0

Tim boosted

(Addendum to "spec first": Sometimes, even an "elevator pitch" -- up to two paragraphs that describe what the application does -- is enough.)

Tim boosted

19.2. Gherkin is your friend to understand expectations

Gherkin is a test description format which points "Given that <a system is in a certain state>, When <something happens>, then <this is expected>". Even if you don't use any testing tool that reads Gherkin, it will give you a good understanding of what it is expected from the app.

Tim boosted

19.1. Write steps as comments

If you have no idea how to start, describe the flow of the application in high level, pure English/your language first. Then fill the spaces between comments with the code.

Better yet: think of every comment as a function, then write the function that does exactly that.

Tim boosted

19. Spec first, then code

If you don't what you're trying to solve, you don't know what to code.

Write something specifying how the application works before writing any code.

"Without requirements or design, programming is the art of adding bugs to an empty text file." -- Louis Srygley

Tim boosted

18. Shortcuts are nice, but only in the short run

A lot of languages/libraries/frameworks add a way to make things shorter, reducing the number of things you need to type.

But, later, that will bite you and you'll have to remove the shortcut and do the long things.

So learn what the shortcut does before using it.

Tim boosted

(Addendums to "magical number":

1. Today, psychologists talk more about the magical number FOUR, not seven.

2. Think function composition, not function calling.)

Tim boosted

17 1/2. The Magical Number Seven, Plus or Minus Two

"The magical number" is a psychology article about the number of things one can keep in their mind at the same time.

If you have a function, that calls a function, that calls a function, that calls a function, that calls a function, that calls function, you may be sure it will be a hell to read later.

Think more about: I'll get the result of this function, then pass it to the second function, get its result, pass to the third an so on.

Tim boosted

17. Cognitive Dissonance is the readability killer

"Cognitive dissonance" is a fancy way of saying "I need to remember two (or more) different things at the same time to understand this."

For example, adding booleans to count the number of True values is a mild cognitive dissonance 'cause one can think "What do you mean True plus True equals 2?"

Tim boosted

(Addendum to types: This is what most people get wrong about adding booleans to check the number of True values.)

Tim boosted

15 1/2. The best secure way to deal with user data is not to capture it

You can be sure that, at some point, the data will leak, either by some security flaw or human interference.

If you don't capture any user data -- or store it in anonymized way -- you won't have any problems.

Tim boosted

15. Think of the users

Think how the data you're collecting from your users will be used -- this is more prevalent on these days, where "privacy" is a premium.

If you capture any used data, remember to protect it against unauthorized use.

Tim boosted

(Holy cow, I'm _really_ enjoying this. And I think I have more than 50 minutes of presentation going on here.)

Tim boosted

14 1/2. Design patterns are used to describe solutions, not to find them

(Again, personal opinion) Most of the time I saw design patterns being applied, they were applied as a way to find a solution, so you end up twisting a solution -- and, sometimes, the problem it self -- to fit the pattern.

First, solve your problem; find a good solution; then you can check the patterns to know how you name that solution.

Tim boosted

14. Data flows beat patterns

(This is personal opinion) When you understand how the data must flow in your code, you'll end up with better code than if you applied a bunch of design patterns.

Tim boosted

13. Companies look for specialists but keep generalists longer

If you know a lot about one single language, it may make it easier to get a job, but in the long run, language usage dies and you'll need to find something else. Knowing a bit about a lot of other languages helps in the long run, not to mention that may help you think of better solutions.

"A language that doesn't affect the way you think about programming, is not worth knowing." -- Alan Perlis

Show more
Ruhr.Social

Ruhr.Social


v english version below v

Willkommen bei Ruhr.Social, eurer Mastodon Instanz für alles rund ums Ruhrgebiet. Wir wollen eine Plattform für Tech-Liebhaber, Nerds und Gründer sein und uneingeschränkten, werbefreien und sozialen Austausch ermöglichen.

Viel Spaß :)


Welcome to Ruhr.Social, your mastodon instance for everything regarding the Ruhr area in Germany. We want to be a platform for tech-lovers, nerds and founders of small businesses and provide an ad-free and social place to talk for you.

Have fun :)

This instance is made possible by the awesome people at 9elements