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.
In this tutorial, we are going to build a simple web application using Spring Boot which will render the content of a Google Sheet spreadsheet in a web page and also display them on a Google Map.
Alejandro wrote in with an interesting piece of a tutorial having the same problem as my client.
*”Last week i was reading about Google Sing-In in with Spring Social and one article that I read had exactly this problem: http://littlebigextra.com/part-1-authorising-user-using-spring-social-google-facebook-and-linkedin-and-spring-security/
I didn't write on Friday. No, I did not forget it. Actually, I planned t for the afternoon, right after I fix a bug in the job platform. While the deployment was running, I check my email and got an urgent help call, which basically was like "We got a huge problem in our self-coded portal with Spring Boot, and can't find the problem. Can you help?"
Sure, I did and so part of my weekend :-)
It started as a short tutorial app for you guys and moved on to become an own product. Let's see if that works. However, today I'll share with you what I learned this time.
The purpose was to learn a new thing, building something simple with a spreadsheet.
Last Update May 2018
Thanks to the nice feedback i got for 2D Game Engines for Python i decided to compile a list of 2d and 3d game development possibilities with Python i found so far. It might not be complete, but i’ll maintain the list from time to time when i find new engines or get tips from you. Your feedback is generally very appreciated.
Strangely, I am a bit obsessed with spreadsheet usage recently. They have their place and time to be used. And they can be a bad solution, becoming a maintenance nightmare. I believe those situations are a good opportunity for generating new business. Or starting out with your own.