C0d3r

Push --force-with-lease is part of my muscle memory since I `rebase -i` so much in my workflow. Why do you think the article should mention it?

People associate OCD with what actually is OCPD https://www.msdmanuals.com/professional/psychiatric-disorder...

I'm sorry you're getting downvoted, but I think this question is legitimate because the book is peddling Kafka as if it's the only way to do event sourcing. Event sourcing is what you should compare with REST APIs, Kafka is one way of doing it, but you can do the same with any database, as long as you have a way to write things in and read things out and organize them, you can achieve event sourcing.

With REST APIs (first few pages of the book), services talk directly with each other, with event sourcing (the rest of the book) services talk with an event store (Kafka in the book) as the intermediary.

Previous discussion: https://news.ycombinator.com/item?id=20603567

fzf can be used as a cool selector in the terminal, it just outputs what you picked from the list, so if you run `ls | fzf`, it will pass the list of files/dirs into fzf, where you can fuzzy search, select and it outputs to STDOUT.

So if you want to edit a file from inside a directory easily, you can do:

vim $(find | fzf)

It's exactly like that, the page runs itself on TiddlyWiki

Which tablet are you talking about just out of curiosity?

To a large extent, becoming professional is about becoming less sensitive to being wrong.

I agree, but there's nothing to lose in trying to become a better communicator, you're not responsible for other people's sensitivity, but you are definitely in control of what and how you communicate.

I do, TDD gives me such a sense of confidence that now that I'm used to, it's hard not to use.

Can you describe the practical benefit?

Confidence that the code I'm writing does what it's supposed to. With the added benefit that I can easily add more tests if I'm not confident about some behaviors of the feature or easily add a test when a bug shows up.

Do you happen to rewrite the tests completely while doing the implementation?

Not completely, depends on how you write your tests, I'm not testing each function individually, I'm testing behaviour, so unless there's a big architectural change or we need to change something drastic, the tests have minimal changes

When does this approach work for you and when did it fail you?

It works better on layered architectures, when you can easily just test the business logic independently of the framework/glue code. It has failed me for exploratory work, that's the one scenario where I just prefer to write code and manually test it, since I don't know what I want it to do...yet

Interesting, I guess it depends on the person and on the thing you're learning like someone else mentioned. I do think you need some time by yourself to really go deep at your own speed to learn something.

Pairing and mobbing are not fads, they've been around for a while and in my experience they've been very useful, I'd recommend you try it with someone with experience with it.

At the same time, real work is not getting done. Meaningful work is usually done quietly and in solitude.

You can do great work by pairing or mobbing too. Being isolated is good, but it's harder to learn new things working by yourself.

Easier on the eyes, at least for me.

Bat works the same way as ls when it's being piped. But it has better default features than cat, the syntax, numbers and the pager. if the file doesn't fit the screen, it becomes paged, so you don't have to do the whole: `cat file.txt` (too big), `view file.txt`

Here you go: https://escholarship.org/uc/item/8806z01m

Useful tool replacements that some people have already mentioned:

- ls -> exa

- cat -> bat

- find -> fd

- top -> htop -> glances

- grep -> ack -> ag -> rg

- hr (to draw a horizontal line in your terminal)

A lightning talk about them: https://youtu.be/hp-1plTKOqc?t=551

Does anyone have a recommendation for just simply printing a book (epub or pdf) that I'm not interested in selling? Just to print a copy for me?

If your terminal is big enough, it will just output like cat, otherwise, you get a pager.

You can disable it with `bat --paging never`

Git helps you with those mistakes, otherwise, yes, very unforgiving

The name of one the articles is: Cory Doctorow says fight against DRM laws is more important than his blogging

So, no, he won't change your mind about DRM because he is not in favour of it.

My Makefiles usually have one line per directive, can I still call my Makefiles simple?

I mainly use them to replace scripts to run tests/linters/formatters/containers/etc

There are some pills which contain lots of minerals, you could supplement with those. They have no calories or hardly any (and you apparently need more than 10 kcal to break a fast)

Wouldn't recommend fasting for HIIT or any super intense activity, but the long runs may improve. I'm saying this since sugar is a lot quicker to be transformed into energy by the body than fat.

But we're all different, so, you could give it a try :).

Companies who are already using a technology such as Perl usually already have both some senior people who only know that technology and/or have a big codebase on that, such that migrating the code would take considerable resources.

Basically, sometimes it's not a choice.

http://www.theregister.co.uk/2012/09/11/kindleberry_pi/

https://en.wikipedia.org/wiki/Uzbl

OH I understand now, thanks!

"echo "tmpfs DIR tmpfs rw,nosuid,nodev,noatime" | sudo tee -a /etc/fstab" Is this command correct? Shouldn't it be something like: "/tmp DIR tmpfs rw,nosuid,nodev,noatime"?

I really like your slide-html, very simple and looks great!

I'm working on something that given a markdown file with a specific marker "---" splits it into slides and opens your browser with an impress.js version of your slides.

Is this something that interests you? The project is private but I may open source it sooner.

Also, written in Python

This only works if you're going slowly, otherwise you eat asphalt...or whatever it is you have in front of you.