Growing Object-Oriented Software, Guided by Tests is a bit old, but still a very nice book to read: https://www.amazon.com/Growing-Object-Oriented-Software-Guid...

I try to setup a feedback loop as soon as possible. I spend time setting up so i can do some simple action (hit a button, run a command, or automatically watch some files) to see if I'm on target it.

I found this saves immense time and keeps me on task pretty well.

This is from: - GOOS book https://www.amazon.com/Growing-Object-Oriented-Software-Guid... - https://www.youtube.com/watch?v=nIonZ6-4nuU

I would not start with technology stack and build around them. You look at your use cases and build out. Pick your frameworks and databases judiciously and as late as possible.

Read: https://blog.8thlight.com/uncle-bob/2012/05/15/NODB.html

Read: http://www.amazon.co.uk/Growing-Object-Oriented-Software-Gui...

[EDIT] Removed the unnecessary/unhelpful opening statement.

I felt that your comment speaks to me - I had a similar understanding a couple of years ago. In their book "Growing Object Oriented Software, Guided by Tests", Nat Pryce and Steve Freeman describe values and objects, *(Values in the sense of Value Objects in Evans' DDD)

> The confusion is, that both concepts are implemented by the same language construct: Classes

This made me think. In C# this statement is somewhat untrue, since you have structs that have value semantics (value equality). But why are there no other concepts within the language that help you from reinventing the pattern wheel?

For example, I had seen the singleton pattern quite frequently in a codebase I worked on, with the label leaking into the class name. But why is it that you have to write:

    public class DatabaseConnectionSingleton { ... }

and then deal with all the static stuff (i.e. x.Instance()) rather than

    public singleton DatabaseConnection { ... }

Like this, you could easliy use standard stuff:

    new DatabaseConnection()

and the runtime would simply return the same instance. This would keep people from reinventing the mechanism. Like IoC / DI built into your language...

[1] http://www.amazon.co.uk/Growing-Object-Oriented-Software-Gui...

Well, one thing I learned from all this recent TDD related discussion is that almost nobody is aware of this book [1] and the entire school of TDD it spawned.

[1] http://www.amazon.com/Growing-Object-Oriented-Software-Guide...

As a start, I recommend reading "Growing Object-Oriented Software, Guided by Tests". I am still not a 100% convert but I did get many of the same questions answered.

http://www.amazon.com/Growing-Object-Oriented-Software-Guide...

short version "programmers can mess up unit tests"

let me suggest: http://www.amazon.com/Growing-Object-Oriented-Software-Guide...

Growing Object Oriented Software Guided By Tests is a great book on the topic: http://www.amazon.com/Growing-Object-Oriented-Software-Guide...

Misko Hevery's (also happens to be creator of angularjs!) Testability Explorer blog is also a great resource: http://misko.hevery.com/category/testability-explorer/

I love the idea of Coinpunk.

And I wish I could contribute, but I'm so jaded and scarred by Javascript at this point it's not even funny. (For context, I spent a lot of time debugging JS on Internet Exploiter in the early 2000's long before anything cool and JS-related existed, and I do Ruby now.)

Can you do me a huge favor, though (and I'd be happy to toss you an entire bitcoin if you simply promise to do this): You NEED a better test suite. You're writing software that deals with money (or "a money," whatever), it absolutely needs a robust test suite. Primarily unit tests, but also a few functional tests. For both the server-side AND client-side code. Bitcoin itself has a reasonably good test suite, yours should too. I REALLY doubt Blockchain.info has a good one. You could distinguish yourself this way while also covering your own ass in the event you need to refactor things without breaking things :)

I didn't think tests were fun to write until I realized how much time they were saving me in debugging and headaches after the fact. Do it now, before your code size gets much bigger.

I highly recommend this book http://www.amazon.com/Growing-Object-Oriented-Software-Guide...

Again, happy to order it for you (it's not cheap) or just toss in some more BTC if you promise to order it and read it.

I don't know what cred I can give you other than to tell you I'm "GSpotAssassin", a well-known big tipper on /r/bitcoin. (I got into bitcoin very early, and I'm an open-source developer.)

Anyway, congrats on your self-funded expedition, that is pretty fucking rad and I expect big things. :)

Nope, there's no way around it. Tests are not easy. But! Writing tests, learning from that, then improving your tests, which in turn help you design better software will make writing tests easier. And will help you write better code, in general.

Also, 99% of the time, the first test you are going to write in a job is for an existing piece of software. So it will definitely not be easy. But you will learn so much more about the software you are writing the test against rather than writing code in the edit-and-pray methodology.

I highly recommend reading http://www.amazon.com/Growing-Object-Oriented-Software-Guide...