It sounds too much like general midi. It is better for electronica than for any other genre.
Impressive nonetheless
107 karma · joined November 6, 2011
It sounds too much like general midi. It is better for electronica than for any other genre.
Impressive nonetheless
It teaches me not to take myself too seriously
There is a Roguelike Tutorial - In Rust (https://bfnightly.bracketproductions.com/)
It is cookieless and that makes it really interesting
gem install reline
ruby yourfile.rb
It is a nice ascii demo of a ruby turning aroundI am guessing anyway
I was looking at one but the egpu only is over 400.
Thanks a lot!
Congrats.
Looks like all the performance related things I'm seeing there are assumptions based on experience.
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
GNU Emacs 24.5.1 (x86_64-apple-darwin14.3.0, NS apple-appkit-1347.57) of 2015-04-13 on mymachine
What is the difference between that and brew install emacs --cocoa?
For a clojure programmer having clojuredocs docset is also a must (https://github.com/dlokesh/clojuredocs-docset) although I think this is unofficial.
He makes an excellent point about the pitch though.