2016 - Daniel Lebrero - REPL driven development
Download as PPTX, PDF0 likes70 views
The document discusses the importance of immediate feedback in software development workflows, specifically through a REPL (Read-Eval-Print Loop) approach. It outlines key benefits such as reduced build and deploy times, improved testing capabilities, and enhanced debugging experiences, citing an example from NASA's experience with spacecraft programming. Additionally, it lists various programming languages and resources that support this workflow methodology.
![NASA
“in May of 1999. […] we were able to debug and
fix a race condition that had not shown up during
ground testing.
Debugging a program running on a $100M piece
of hardware that is 100 million km away is an
interesting experience. Having a read-eval-print
loop running on the spacecraft proved invaluable
in finding and fixing the problem”
Ron Garret - NASA Jet Propulsion Lab Engineer](https://image.slidesharecdn.com/repldrivendevelopment-jdd-161129092723/85/2016-Daniel-Lebrero-REPL-driven-development-26-320.jpg)
2016 - Daniel Lebrero - REPL driven development
- 2. Confession
- 5. Me doing some FE work
- 6. Me doing some FE work Immediate Feedback
- 7. The Flow or The Zone
- 8. Why do we want it? Productivity
- 9. Why do we want it? Joy
- 11. Interruptions
- 12. Limits • 0.1 second is about the limit for having the user feel that the system is reacting instantaneously • 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. • 10 seconds is about the limit for keeping the user's attention focused From book Usability Engineering
- 13. Time to compile and start a new Tomcat app compiling … done! 30 seconds
- 14. Unit tests “Do not run Tomcat. Embrace TDD.” Daniel Lebrero
- 15. Test Doubles • Stubs • Spies Lies • Mocks • Fakes Lies Lies! More lies! Fat lies!
- 16. Credible lies
- 17. You are going to run it and … BUGS!
- 18. What do we want from our workflow? 1.Write code with immediate feedback 2.No build or deploy 3.Easy way of creating faithful lies for our tests 4.Tools to understand the real world 5.No surprises when starting the application
- 19. REPLRead Eval Print Loop
- 21. Clojure
- 22. What do we want from our workflow? 1.Learn the language and libraries 2.Write code with immediate feedback 3.No build or deploy 4.Easy way of creating faithful lies for our tests 5.Tools to understand the real world 6.No surprises when starting the application
- 23. Demo time!
- 24. What do we get with a REPL workflow? 1.Learn the language and libraries 2.Write code with immediate feedback 3.No build or deploy 4.Easy way of creating faithful lies for our tests 5.Tools to understand the real world 6.No surprises when starting the application 7.Run automatically unit test affected by a change 8.Inspect and manage state 9.Stay on the comfort of your favourite IDE Fewer
- 26. NASA “in May of 1999. […] we were able to debug and fix a race condition that had not shown up during ground testing. Debugging a program running on a $100M piece of hardware that is 100 million km away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem” Ron Garret - NASA Jet Propulsion Lab Engineer
- 27. 1.Learn the language and libraries 2.Write code with immediate feedback 3.No build or deploy 4.Easy way of creating faithful lies for our tests 5.Tools to understand the real world 6.Fewer surprises when starting the application 7.Run automatically unit test affected by a change 8.Inspect and manage state 9.Stay in the comfort of your favourite IDE 10.Debug staging and production 11.Control spacecrafts What do we get with a REPL workflow?
- 28. Why do we want it? bb Productivity Joy compiling next slide…
- 29. When do we want it? • Javascript: https://vimeo.com/123513496 • ClojureScript: https://www.youtube.com/watch?v=KZjFVdU8VLI • Elm: http://debug.elm-lang.org/ • Groovy: https://www.youtube.com/watch?v=bTRUC78X87g • Python: https://www.youtube.com/watch?v=EwI-e3WlTew • iOS: https://www.youtube.com/watch?v=Ci4uviG8S0o • Android: https://www.youtube.com/watch?v=mVXTcAEKgF8 • Unity: https://www.youtube.com/watch?v=tJr_TD1BtF0 • Music: https://www.youtube.com/watch?v=yY1FSsUV-8c
- 31. References – Bret Victor – Inventing by principle https://vimeo.com/36579366 – Ron Garret – The Remote Agent Experiment: Debugging Code from 60 Million Miles Away https://www.youtube.com/watch?v=_gZK0tW8EhQ – Jakob Nielsen – Usability Engineering https://www.nngroup.com/books/usability-engineering/
Editor's Notes
- #3: But before we get started, I have a confession to make. On my very first job I got to work with 3 technologies that made a profound and lasting impact on my career as a developer. Those 3 technologies were Netscape, IE4 and IE5. Thanks to those technologies, I decided to become a BE developer and I have avoided any kind of FE related work for a very long time, being a happy Java developer living on a world of XML and JSON. But in a recent project, I ended up working hand in hand with a team of FE developers, and I have to confess that since that project, I have been really jealous of the FE guys. You may be wonder what makes me so jealous?
- #4: Maybe the JS that they use was somehow different from the JS that I learned and suffer 15 years ago? A little but not enough.
- #5: Maybe they have fixed all those incompatibilities between browsers that used to drive me mad? Nop, they still exists. So, to understand why I am really jealous about the FE developers, lets see a picture of myself doing some FE work
- #6: Yeah, that is me trying to get a 2 column layout working in IE and Opera, and as you can see I am not very good at it, and as much as I try and I try, I always end up with the same end result, a pile a crap. But even if CSS doesn't make any sense to me at all, there is something really nice on this picture. Lets watch it again.
- #7: Focus on Mr. Griffin’s workflow. See how he pulls from a string and he sees straight away, without any delay the effect on the blind. And if he doesn't like what he sees, he just pulls the string in a different direction. And he keeps pulling and pulling until he is done. This is what I really really miss on my day to day job. This is what makes me jealous of the FE devs. That immediate feedback. We know from Agile, Scrum and Lean, that feedback loops are important and the shorter the feedback loop, the better. But why is this immediate feedback so important during development?
- #8: Because without that immediate feedback, it is very hard to get into the Zone or the Flow. The Zone is that state where you feel like Neo when he realises that he is the chosen one. It is just you and the code. You are so focus, that the real world disappears, and instead you can see with absolute clarity your application, its code, its design and the data flowing around it. When you are in the Flow no problem is difficult enough, no bug can hide from you and your solutions are simple, clean and elegant.
- #9: When you are in the flow is when you are the most productive, and not only are you able to produce more, but what you produce, the code and its design is of a better quality. But this productivity is just a nice side effect of being in the flow.
- #10: What we are looking for is that feeling of joy, that feeling of achievement, that feeling of creating something truly beautiful. And is this feeling is why I am after 16 years still a developer.
- #12: And we, BE developers, are expert on those interruptions. And we have gotten so use to it, that we think it is unavoidable. We even have comics about it