“Everybody wants to be a bodybuilder, but nobody wants to lift heavy ass weight”
Ronnie Coleman, 8x Mr. Olympia winner
Being a programmer is a lot like being a bodybuilder. Regular training, incremental progress, over and over again.
Over time this transforms the person from a beginner to a profesional.
Adopt this mindset in being a programmer. Plan to consistently train and improve your software engineering skills.
Simple example on how to send a post request from the client and handle the response.
axios.post('/login', { firstName: 'Jack', lastName: 'Johnston' })
.then((response) => {
// Success
console.log(response);
}, (error) => {
// Failure
console.log(error);
});
// Send a POST request
axios({
method: 'post',
url: '/user/new',
data: {
firstName: 'Joe',
lastName: 'Smith'
}
});
# NPM
npm install axios
-- or --
# Include Script Tag in JS file
<script src="https://cdn.jsdelivr.net/npm/axios/dist/axios.min.js"></script>
To add a date to a git commit message from the command line:
git commit -m "blog update on `date +'%Y-%m-%d'`"
will result in
* e81bc5d - (25 minutes ago) blog update on 2023-04-20 - Mark S
In Spring you can enable a component using a profile:
@Profile("prod")
@Component
public class ProductionService() {
// This will only be created with Spring_Profile: prod enable
}
Another use case is enabling/disabling schedulers:
@Profile("nightly-job")
@Component
public class NighlyJobScheduler() {
// This will only be created with Spring_Profile: nightly-job
}
It can get cumbersome adding all the various profiles when you run the application. Spring now offer profile groups:
spring:
profiles:
active: development
group:
prod: prodJob1, prodJob2
development: dev-scheduler-1, dev-notification
In the example above, running the profile “development” will automatically bring in the other profiles “dev-scheduler-1, dev-notification”
YAGNI is an acronym for “You Aren’t Gonna Need It”.
It’s an important principle in software development. Often it’s tempting to add code that could have useful utility down the road. In the end, it never ends up being used and creates overhead and code bloat.
So to follow YAGNI, don’t implement code until it actually needs to be utilized.
It’s a principle that comes from XP - Extreme Programming.
When making changes to config maps or other things - it’s tempting to restart all the pods for a particular service (select them all, delete, and let them come back up). This may work in the majority of cases, but if something goes wrong, it’ll be hard to tell if the recent change caused it or if it’s unrelated.
Recommendation:
The point here isn’t the specific process, but rather having checkpoints when changes are made. Ideally, by making only one change at a time and testing, it’s evident when something is broken which change caused it.
To access a shell in a particular pod:
To access a terminal to run kubectl commands in the environment:
>_ symbol to open a terminal.Example command:
kubectl describe thingToDescribe -n NameSpace
To run a batch job, a JobLauncher needs a batch JobConfiguration and JobParameters. This creates a JobInstance.
A JobInstance creates a JobExecution. If the job fails and is restarted it retains the same JobInstance but creates a new JobExecution.
A JobExecution runs one or more steps in the Batch_Step_Execution table.
So each new run of a batch job creates a new batch job instance, and each restart creates a new job execution.
If you need to checkout a single file from another branch in git use:
git checkout BRANCHNAME --path/to/file
Batch jobs are created in Spring Batch using the JobBuilderFactory. A custom job builder factory can be created and re-used to allow common job configurations to be shared across all batch jobs in a project.
@Configuration
public class CustomJobBuilderFactory extends JobBuilderFactory {
@Override
public JobBuilder get(final String name) {
final JobBuilder jobBuilder = super.get(name);
// register common to all jobs things here
jobBuilder.listener(commonListener);
return jobBuilder;
}
}
@Bean
public Job exampleJob(final CustomJobBuilderFactory jbf) {
// This job now has the common listener
return jbf.get("myJob").start(myStep).build();
}
}
