Kids already sue the most powerful question in the world pretty early on.
Reader Paul chimed in on yesterdays email and was wondering how one can talk business oriented in an enterprise environment. That’s a good question and a tough one.
If you work with smaller clients, the chance is higher that your work directly with the business owner or at least with someone involved in the business. Someone who cares. It is a totally different game in larger corporations. There is no single business owner anymore. There are multiple and their goals often do not align. And that goes along down the line to your dev position.
So, after getting derailed a bit by my recent observation, we get back on track with building the spreadsheet shop. In the meantime, you guys did send in a couple of good questions. Great, keep coming!
This morning I was in a meeting of the project from stone age to talk about the proof of concept app we did. 6 people, including me, with a total of 4 different companies (or self-employed). And at least 4 different pairs of glasses on. That’s a hell of a lot of opinions and intentions. And blind spots.
a shop. Not one of those biggies with Magento, Shopify or whatever is in today. No, we build one using spreadsheets, of course. You guys wanted to build more tutorial apps and have some spreadsheet fun. So, here we go.
So, today we are going to use Zapier for sending the email notification. To follow along, you obviously need a Zapier account. The free is enough.
So, let’s start with sending emails first. As with most things in Spring Boot, it is straightforward. The central class in Spring for sending emails is the JavaMailSender. It provides an interface simplifying the whole mail creation process, especially with mime types.
Sometimes we need to trigger a human to continue a task; manual reviews, todos or whatever. In my particular case, an action in the system should trigger a human to review an entry and manually approve it. For that, we got multiple options and I thought I include you in the reasoning process.
I was recently chatting with a reader and the topic of how to structure packages came up.
Basically, the traditional way is to structure by layer and each layer got its own subpackage. For the imaginary Evil Corp with their project doom it would look like: * com.evil.doom.model * com.evil.doom.service * com.evil.doom.controller * com.evil.doom.dao Perfectly reasonable. But it has some drawbacks. It encourages spaghetti code. Sooner or later your code will be entangled like hell inside each subpackage. It is not clear, where the boundaries of functionality is.
and you should be aware of. Yes, you. It is one we all have committed.
Building a production system with a deadline in a tech stack almost nobody on the team knows. Just because, one little dev guy wanted to use it.