Is your Web application is getting a bit big and bulky on a single server? You might be thinking of moving to a more distributed, microservice-based architecture. And in many cases, that’s a great way to go about things. But microservices aren’t a panacea, having their own issues and pain points. What are the trade-offs associated with a microservice-based architecture? How do you define the dependencies (code and API) between the different services? And how can you avoid a “distributed monolith” — a situation in which you have many microservices that are dependent on one another? In this talk, Ben Christensen describes the different ways to think about such microservice- systems, and how to avoid some of the more common pitfalls.
People in the software industry are constantly talking about productivity. We use languages that will make our developers more productive. We use techniques, such as agile, which are supposed to deliver more value in less time. Some companies rank and pay developers based on their productivity — or outsource overseas because those developers are seen as more productive. But just what does “productive” mean, and how do we measure it? In this Webinar (without video, but with slides), Steve McConnell discusses this issue, and what it means for the software industry.
A very large number of us use open-source software every day. Many also participate in open-source projects. But if you maintain an active open-source project, then you’re dealing with other people’s code on a very regular basis. How do you handle this? How do you manage a large number of commits, or pull requests, or bugs, or feature suggestions? When should you define, or enforce, code standards? And what sorts of documentation standards shoudl you put in place? In this talk, Barak Michener shares his experience running a number of open-source repositories and projects. If you are thinking of managing a new open-source project, or becoming an active participant on an existing project, then this talk will help you to consider how to scale your software — not in terms of efficiency, but rather in terms of people, community, and contributors.
We often talk about “software engineering,” rather than just “programming” — but that implies that we are acting and working as engineers. The thing is, what does it mean to be an engineer, and to have that kind of discipline? And do we, in the software world, really use engineering in our work? In this talk, Mary Shaw describes what it means to be an engineer, comparing software with such disciplines as civil engineering. She then raises many questions about what we’re doing, and how we’re doing it — and how we can do it even better in the future.
Do you use design patterns in your code? Probably — but that doesn’t matter, because the term “design patterns” probably sets you on edge so much that you haven’t stopped to consider whether you’re using them, and what advantages they might give you. It turns out that design patterns make it easy for you to communicate with other developers, to reason about the way in which you’re architecting your code, and to take advantage of the thought that many others have put into certain ways of developing software. In this talk, Jeremy Clark describes the reasons for learning design patterns, and then describes several of the most common ones that you’re likely using already, even without knowing it.
For years, we have been hearing that “agile development” will save the software industry. And now, you can’t get away from it; every company claims to be agile, with Post-It notes, stand-ups, and tons of training for Scrum masters and the like. But the term “agile” has become a meaningless buzzword, used by companies to describe whatever management wants to do, with a few notes stuck on walls. So says Dave Thomas, one of the original authors of the Agile Manifesto. If that’s the case, then what’s next, and how should we develop software? In this talk, Dave describes what he means, and how developers should think about projects, communication, and scheduling over the next few decades.
The Go language has become extremely popular in the last few years. This highly parallel, open-source language sponsored by Google is a systems language, meaning that it’s meant to be used for high-performance operations where C and C++ currently rule. As Go has matured, developers have found that certain practices make it easier to write and maintain their programs. In this talk, Rob Pike proposes a number of “Go Proverbs,” which should help to instruct, direct, and influence developers as they go about designing and implementing their software in Go.
It used to be so easy to set up an application: You set up a server, write some software, and then update the software over time. But as systems get bigger and more complex, it becomes much harder to write, test, and deploy large, monolithic systems. Over time, we have moved toward microservices, which have their own challenges. In this talk, James Lewis describes our migration toward microservices, and what that means for designing, testing, deploying, and just thinking about such applications. What has changed, what has become easier, and what has become harder?
If you create a piece of software, you need to worry about the users. But if you create an API, then your users are people you’ve never met, who will be using your software on a regular basis — and who will create applications and services based on the API you created. This means that if you make mistakes when creating the API, you’ll be forced to live with those mistakes, and support them, for some time. How can you create, and then maintain, an API with a minimum of of fuss, and in a way that you can fix mistakes? In this talk, Philipp Meier describes the mistakes that he has made when writing APIs in Clojure. His lessons are appropriate not only for Clojure developers, but for people using other languages, too.