Open Tech Calendar

This month, we've got two talks lined up, followed by the usual visit to the Rutland Arms to socialise :)

---

"Towards Devcards: Stealing the best ideas from ClojureScript" - Glen Mailer (@glenathan)

The React community has a good pedigree of taking great ideas from other communities and building upon them. The ClojureScript community has also been quite influential in pushing the boundaries of how we build web applications.

The React core team has acknowledged that David Nolen's Om work was part of the early adopter surge that helped React take off. It's now commonplace to talk about immutability in React-land, which is a philosphy inherited from our Clojure-based colleagues. Hot code reloading is another area where Clojure showed us was possible with Figwheel.

So what can we take next? I think the answer to that is Devcards. Devcards is an idea from the creator of Figwheel that builds upon hot code reloading to give you a visual REPL for creating components. Instead of having to build and iterate on components from within the application, you can use cards to show all the possible states at once.

Devcards is quite closely bound to the way ClojureScript works, so it's not trivial to use it in ordinary JavaScript projects. I've ported it to JavaScript so you can try it out - and maybe change the way you build applications.

---

"Why Stealth Refactoring is Wrecking our Codebases" - Naomi Rosenberg (@hoegrammer)

Because management are perceived not to value refactoring, developers fear being “told off” for doing it. So we refactor less than we’d like to, and when we do, we often sneak it in, hidden amongst functional changes.

We know insufficient refactoring leads to technical debt. Stealth refactoring creates problems, too. Reviewing a diff mixing functional and non-functional changes is time-consuming and error-prone, costing money and introducing bugs. Also, stealth refactoring tends to focus only on the “geographical area” - the function, file or module - that we are “touching” at the time. What are the implications of that for the coherence and consistency of our codebases?

I will make some technical suggestions for optimising how we refactor, but the main issue is cultural. Is our shame around refactoring entirely due to management, or are devs responsible too? How can we sell simplicity to people who may not be aware of its value? Can we create a culture that legitimises - or even rewards! - a practice that is, after all, essential to developing a quality product at a reasonable cost?