Last week I went to the Sydney Technology Leaders’ Meetup, which we hosted in the Tyro Fintech Hub. There was a trio of great talks, and a panel discussion with the speakers at the end.
When asked what they do to help train new leaders, one of the speakers mentioned “throwing a bunch of books at them”. So I took the opportunity to ask the speakers, if they could only recommend one or two books to a new leader, what would each of them recommend. Continue reading
At Tyro, we don’t have anyone with the title of Architect, Designer or Tech Lead who designs software and then asks other people to build it. Instead, each team of Software Engineers does architecture and design as part of their iteration planning sessions for the stories we’re taking on.
As a Team Lead, the two main goals I keep in mind for each person are: keep them happy and keep them growing. One of the ways I try to ensure this happens is by meeting with each person regularly so we can chat about how to make sure these things are true or at least heading in the right direction.
A topic that’s come up with a few people lately is software design and architecture. Specifically, I’ve had a couple of comments along the lines of: “When we’re designing things, I want to contribute more, but I’m not really sure where to start.” Continue reading
I spoke earlier in the year at the Sydney Microservices Meetup about the long path we’ve taken at Tyro Payments over the last decade, gradually tending towards a more fine-grained SOA approach – microservices as it’s come to be known recently.
I covered a lot of ground in that talk, but something I didn’t get around to talking about was security. However, I believe that’s a really important topic to think about in microservice environments. It’s even more important than with a monolith, because in a service-oriented architecture you’re making a lot more of your system’s functionality directly exposed to the network, and that puts it in closer reach of would-be attackers, or “increases the attack surface” as a security pro would say.
So last week I presented another talk entitled “Microservices Security: All the Questions You Should Be Asking”.
I want to tell people all about what we’ve been doing about security at Tyro lately. Security is incredibly important to the IT community and I think it’s imperative that we help each other improve. I want to share with the world some of the problems we’ve dealt with and some of the great solutions our team has built. Continue reading
I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.
Simon Brown (@simonbrown) spoke on “Agility and the essence of software architecture”. (Slides, Video)
He started with a great Dave Thomas quote:
“Big design up front is dumb.
No design up from is even dumber.”
Software Architecture AgilityHe went on to tell us…
Delivering software in an agile way doesn’t guarantee that you’ll develop an agile architecture.
A good architecture enables agility.
He asked “Are monolithic architectures agile?” and proposed the answer, “Well, they could be. Just because you have to deploy it all at once doesn’t mean it’s not agile.”
Which naturally lead into a discussion of what does agility mean? Continue reading
I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.
Beth Skurrie (@bethesque) from DiUS, Evan Bottcher (@evanbottcher) from Thoughtworks and Jon Eaves (@joneaves) from REA group spoke about migrating realestate.com.au to a microservices architecture. (Slides, Video)
They started by talking about why they started doing microservices:
However, there was a realisation that changing things at REA is a bit hard, partly because the teams are very self-empowered, they’re trusted, and they value their independence.
In order to convince teams that trying a new architecture was a good idea, they came up with a vision of where they wanted to go, which included: Continue reading
When my wife and I had been married for a year, we made a decision to purchase an apartment. It remains, to date, the worst decision we’ve ever made.
To start off with, we probably shouldn’t have purchased anything at all. But there was pressure from parents, the peer pressure of our friends doing the same thing, and the constant fear in Sydney-siders of “getting left behind the market”. Looking back now, I see the bigger factors that we’d been married for one year, we were both very early in our careers, we had very little savings relative to our incomes, and we were living in a friend’s place for low rent. There weren’t really any good reasons to buy.
The big mistake, though, was the place we bought. Continue reading
I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.
Troy Hunt (@troyhunt) spoke about “developers building up cyber-offence skills and proactively seeking out security vulnerabilities in their own websites before an attacker does”. (Slides, Video)
He started out with the obvious but perhaps too often forgotten observation: “You can’t defend your app unless you actually understand how the hacker’s technology works.”
He described how hackers only need to “get it right” once. Those developing and deploying the system need to get it right every time. (This is sometimes called the “Fortification Principle”. Apparently DARPA are working on evening out the playing field.)
He asked: If your company has a Twitter account, who chose the password? The marketing intern, or the Security team? Continue reading
I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.
Ed Kmett (@kmett) started by asking: “What is the cost of using the wrong solutions, integrated over your entire career?” (Slides, Video)
Then he revealed that the topic he’d chosen for the talk was…
He talked about a strategy for solving big problems described by famous theoretical physicist Richard Feynman (pictured):
Note that, in Feynman’s approach, genius is attributed not necessarily to those that come up with new ideas, but often to those who figure out where to apply them.
He noted that developers are in the business of solving problems, searching for solutions, while researchers often have solutions, but are searching for the right problems to apply them to. As a developer, it can be good to keep abreast of what researchers are discovering in hope of finding a solution to one of your favourite problems.
He discussed human memory retention and the need to revisit topics over time to retain knowledge about them. The brain remembers far better information that is used or revised repeatedly. Knowing this, you can hack the brain by intentionally repeating material that you want to remember. (For example, after going to a conference, you could write a blog about the important points from each talk you went to.)
He chatted a little bit about jargon, saying that if you’re going to use jargon, you should always be willing to explain what it means.
Image credit: Richard Phillips Feynman (1918 – 1988) (unknown)
This evening I went to a YOW Night where Ken Scambler (@KenScambler) spoke about the introduction and evolution of using Scala at REA Group. Here’s my notes…
The benefits of going functional are to get to code that is: Modular, Abstract, Composable.
Modularity is about being able to fit entire sections of code in your head without having to consider things going on outside that code, and also about being able to replace small parts without affecting the whole.
To write a total function (a function that returns a result for all possible input values), you need to elevate all possibilities into the type system. For example, you can’t throw an exception, you have to encode that possibility of an error into the return value somehow.
Abstraction should reduce changes to code, because unnecessary detail is not all across the code.
Whole systems can be composed from functional components.
Functional programming is not about picking up a hipster language. It’s about producing better software.
Continue reading
Last week I wrote about PaaS and Microservices, asking, “Is a Microservices PaaS in our future?” Since then, I’ve had a number of URLs thrown at me along with the question, “Is this what you mean?”
Probably the closest in intent, based in the way they’re marketing themselves, are Giant Swarm. These guys are certainly putting themselves out there as “Simple Microservice Infrastructure”, and I think they’ve made some ground on implementing such a thing by including service discovery as part of their platform.
However, my impression from their docs, as I explained in a comment on said previous blog, is that so far they’ve really only built a “Docker-based PaaS”, and are leaving most of the work of building a MSA, in terms of both choosing and configuring technologies, up to the developers of the system. To quote myself again: “in terms of setting me up with an architecture, it stops at ‘You’ve got Docker!'” (I didn’t realise it had service discovery when I wrote this.)
One of the Giant Swarm developers, Timo Derstappen, joined in the conversation. Continue reading
