short url: caseywatts.com/selfpublish
my book is out! an applied psychology / self-help book targeted at developers: Debugging Your Brain
Markdown --> PDF (as a booklet!)
Markdown --> EPUB and MOBI
| ruby '2.7.1' | |
| gem 'rails', github: 'rails/rails' | |
| gem 'tzinfo-data', '>= 1.2016.7' # Don't rely on OSX/Linux timezone data | |
| # Action Text | |
| gem 'actiontext', github: 'basecamp/actiontext', ref: 'okra' | |
| gem 'okra', github: 'basecamp/okra' | |
| # Drivers |
short url: caseywatts.com/selfpublish
my book is out! an applied psychology / self-help book targeted at developers: Debugging Your Brain
Markdown --> PDF (as a booklet!)
Markdown --> EPUB and MOBI
Notes, comments and errata on Robert C. Martin's Clean Architecture
The book has 34 chapters, with a maximum of 22 pages (chapter 14). Even while involved as a programmer in a project, it should be possible to read one chapter per day, so you can finish the book in about 2 months.
The git repo of the kata is here: https://github.com/sandromancuso/cleancoders_openchat/
The "starting-point" branch is where both implementations began: https://github.com/sandromancuso/cleancoders_openchat/tree/starting-point
"openchat-outside-in" branch captures the tomato by tomato history of the London approach."openchat-unclebob" branch captures the tomato by tomato history of the Chicago approach.| # Use this script to test that your Telegram bot works. | |
| # | |
| # Install the dependency | |
| # | |
| # $ gem install telegram_bot | |
| # | |
| # Run the bot | |
| # | |
| # $ ruby bot.rb | |
| # |
| @font-face { | |
| font-family: SegoeUI; | |
| src: | |
| local("Segoe UI Light"), | |
| url(//c.s-microsoft.com/static/fonts/segoe-ui/west-european/light/latest.woff2) format("woff2"), | |
| url(//c.s-microsoft.com/static/fonts/segoe-ui/west-european/light/latest.woff) format("woff"), | |
| url(//c.s-microsoft.com/static/fonts/segoe-ui/west-european/light/latest.ttf) format("truetype"); | |
| font-weight: 100; | |
| } |
I'm putting here some of the things Sandro said in his 3-part session on Outside-In TDD (see the github repo here), and highlights some parts that are significant to me.
TDD does not lead to a good design if you don't know what a good design looks like.
The way I code in this video is the way I normally code but not the way I normally teach.
Some of you will notice that I skip the traditional refactoring steps a few times and I do quite a lot of design up-front (or "just in time design" as I prefer to call it) without much feedback from my code.