rafadc

It is insanely fast. Less than 2 seconds for 120 seconds of audio in my 3090.

It sounds too much like general midi. It is better for electronica than for any other genre.

Impressive nonetheless

I'm surprised that we are mentioning a paid site here and we are not mentioning tools like monkeytype and typeracer where you can do good practice for absolute free. In this particular space monkeytype is a super customizable tool that can fit tons of different people.

Prepare for a lot of copycat companies. Hey Devin, copy this company's software.

And this is the problem of today's AI. It is a spam generation machine.

I've been using Comic Code for a while for coding and it is the best thing it ever happened to me professionally speaking.

It teaches me not to take myself too seriously

Not a rewrite but...

There is a Roguelike Tutorial - In Rust (https://bfnightly.bracketproductions.com/)

IMHO the video game scene is better than ever. Maybe you don't like what 90% games have become and that is fair. But go to itch.io and you will find a wide array of different games that will for sure suit your tastes. Maybe they are not that popular.

They lost the opportunity of calling it Tinderin.

I think nobody mentioned Ackee https://ackee.electerious.com/

It is cookieless and that makes it really interesting

Just copy the contents in a file and

    gem install reline
    ruby yourfile.rb

It is a nice ascii demo of a ruby turning around

There will be more pro esport players with their ps4 pro than professionals using airpods pro for their respective jobs.

I guess the problem is the store. The app allows to access valve's store (which is far cheaper than games in the apple store). If they remove the ability to buy games I am sure the remote desktop app would be ok.

I am guessing anyway

Looks interesting really. Is there any way of acessing the stored passwords from a mobile phone?

Which egpu are you using?

I was looking at one but the egpu only is over 400.

Thanks a lot!

I prefer using tmux for this to be a bit more secure. I wrote a blog post about this [0] since it is a bit of a pain in the ass to set up properly. Maybe you should explore this too for your product.

[0] http://joy.pm/2015/07/11/pairing_over_tmux.html

Probably is because the content seems interesting but no one had time to look at it obviously ;)

No

These bundles exist only because of the near zero cost of duplication. For so many books the tier should be even higher unfortunately.

The diffing in the tests is absolutely beautiful!

Congrats.

Looks like you are putting performance as a top priority for you. Do you think that a good candidate should at least measure cpu time somewhere?

Looks like all the performance related things I'm seeing there are assumptions based on experience.

I hope that with the change of maintainer we, emacs users, can have some sanity regarding that concern and avoid the "emacs as a trojan horse so everyone switches to gnu" mentality.

It was funny that the second place was for a long time for Blas de Lezo (https://en.wikipedia.org/wiki/Battle_of_Cartagena_de_Indias)

> I am against writing unit tests in general, since experience shows that they actually prevent high-quality code from emerging from development--a better strategy is to focus on competence and good design.

False dilemma. Are competence and good design exclusively from people that don't TDD?

> The basic idea--amazingly, one of the most popular methods of software engineering (and growing in popularity!)--is that, after you figure out what you want to do and how you want to do it, you write up a set of small test programs--each testing some tiny piece of the program that will exist. Then, you write the program.

No. You are wrong. It is not that.

> Let me emphasize: you write the test cases for your program, and then you write your program. You are writing code to test something that doesn't even exist yet. I am not rightly able to apprehend the kind of confusion of ideas that could provoke such a method.

You are writing specifications for a program that doesn't exist yet!? Nuts.

> The most important argument is a practical one: Test-First doesn't work.

It doesn't work because it doesn't work. Sad argument.

> I was once one of these newly educated kids. So, for a few years, I worked exclusively with the Test-First strategy. When it was over, the results were undeniable. The code--all of it--was horrible. Class projects, research code, contract programs, indie games, everything I'd written during that time--it was all slow, hard to read, and so buggy I probably should have cried. It passed the tests, but not much else.

So it didn't work for you so it is everybody else's problem but yours.

> So this is the first reason TDD fails: You're trying to make a design before you learn anything about it.

No. You are not. Indeed, depending on how you decide to do your tests you should be able to change your design and the underlying implementation and no test should break. Please, take a look to the outside in approach.

> Week 3-4: Write tests.

> Week 5-10: Write code.

Oh my god. This is terrible. And no, this is not TDD either. This is inverse waterfall :P

> Even if you somehow succeed, TDD prevents incremental drafts by functionally requiring all tests for a module to pass before you get any real results.

Probably this is a misconception too. You don't write all the tests before. One test, small implementation pass, another test, small implementation pass... You get the results incrementally.

> There is literally no substitute for competence. If your coders don't have it, TDD won't fix it.

I fully agree on this. And probably this is a really common misconception. But false dilemma again. I don't think TDD came in this world to turn bad programmers into good programmers. It is just another tool in the toolset. You can have terrible programmers that do TDD and excellent programmers that do it.

My recommendation: https://vimeo.com/68375232