Introduction

This article describes the usage of Gemini to help write code for an application like Python or JavaScript. That’s a hands-on experience with Gemini for programming for the last few weeks, writing tools (small tools, not large tools).

This approach here is purely empirical (disclaimer).

Disclaimer

Again, this approach is empirical.

Issues:

The following issues I faced:

• Gemini seem to forget previous code settings – after a few iterations
• Gemini seem to omit/disregard previous code settings – let’s say: use certain environment variables
• Gemini seem to be particularly struggling with JavaScript, and much better with Python, possibly given discussions online – no benchmark to prove this true, however.
• Gemini is excellent in some problems, but goes into local maxima in some aspects – meaning it will get stuck in a loop
• Gemini will rewrite completely segments even if you just add a feature
• Gemini will omit some parts, either by mistake or not.
• Gemini will tend to send just sections, which is convoluted sometimes on merges and comparisons.

Good practices

I considered the following list useful:

• Interact with Gemini at the same level of knowledge – not more, not less
  • Why not more: it can make mistakes, and if the user assumes it knows more than you, you won’t necessarily review the code
  • Why not less: it can omit or be verbose (over-verbose), complicating the answer, expecting a certain outcome
• Establish rules and guidelines
  • use a certain mode
  • use certain indentation
  • use certain architectural aspects (components)
• Establish a stable code – a version that is reliable to go back to. That’s an anchor.
• Work with Gemini combined with GitHub – for saving and updating, versioning.
• When getting into a local maxima – where the AI keeps guessing on a loop – you will be better-off completely disengaging and fully working by yourself.

Conclusion

This article discussed Gemini for usage of application development.

I hope this article helps with some useful insights and AI-assisted improvement and understanding for better performance.

In the last couple of years, I have been publishing articles at Red Hat’s Developer Blog rather than here.

So here is a list of some of the articles I have published:

Java Container Awareness

Troubleshooting with fault tree analysis and PIOSEE

How does cgroups v2 impact Java, .NET, and Node.js in OpenShift 4?

Node.js 20+ memory management in containers

.NET container troubleshooting in OpenShift 4

JVM tuning for Red Hat Data Grid on Red Hat OpenShift 4

How HaProxy router settings affect middleware applications

Set up JBoss EAP 7 clustering in OpenShift using DNS_PING

How to troubleshoot Node.js images in OpenShift

How to troubleshoot Spring Boot in OpenShift

Red Hat Serverless Operator usage and troubleshooting in OpenShift 4

Migration Toolkit for Applications: Report analysis, customization, and troubleshooting

Build & deploy JBoss EAP 8 images in OpenShift with Galleon & Helm charts

Customize your deployments with the Red Hat Developer Hub Operator

Metaspace setting and tuning in JDK 8+ Applications (in and outside containers)

Accessing Red Hat Data Grid in Red Hat OpenShift Container Platform 4

Use of Cryostat and Java Flight Recording in Red Hat OpenShift 4

4 ways to deploy Quarkus applications in OpenShift Container Platform 4

A beginner’s guide to the Shenandoah garbage collector

Using OpenShift 4’s inspect for middleware troubleshooting

How to use Helm charts to deploy Data Grid on OpenShift

How to install and upgrade Data Grid 8 Operator

How to enable the JBoss EAP 7 management audit log

How to migrate server configurations to JBoss EAP 7.4

Sometimes I write blog posts here and for other blogs, like this one:

https://developers.redhat.com/articles/2024/03/14/how-use-java-container-awareness-openshift-4

People will use that as reference and that’s great. You can even write your own blog post about it.

But better cite it because worse than copying someone’s work is to copy it wrongly.

Or the worst scenario: contrive (as make an unsubstantiated claim) just because of a misunderstanding of the concept, which you are probably not used to anyway.

Surfing online on the topic I can see some claims that are basically unsubstantiated and that’s just not how it works – sometimes AT ALL. The wording matters, some concepts are not interchangable and abstractions can do more harm than good.

So you are better citing the sources nonetheless. You may be reading something wrong yourself.

“Knowing enough about a subject to think you’re right. But not enough about the subject to know you’re wrong” — By Neil deGrasse Tyson.

A novela Kubanacan, desde pequeno traz elementos que muitos consideram problematica e com um final sem sentido (non-sense ending). Conteudo, em anos vendo e pensando a respeito, eu tenho DUAS interpretacoes possiveis para a novela como peça fictional de entretenimento:

a- trata-se de paradoxo temporal e, que o protagonista Esteban é o proprio pai dele.

b- a novela se trata de um sonho/imaginacao nos ultimos momentos de vida do Esteban.

Abaixo eu detalho essas explicaçoes in-universe – ou seja dentro da novela sobre isso. Não vou discutir elementos fora da novela, que sofreu varios problemas de produção e troca de roteiro.

PRIMEIRA INTERPRETACAO

Esteban eh o pai dele mesmo visto que se trata de um PARADOXO TEMPORAL EM LOOP INFINITO. Nessa interpretacao, a novela Kubanakan (2003) nao falhou no final mas trouxe o conceito de protagonista ser pai dele mesmo antes de DARK (2017) e parte do conceito de Predestination (2014) mas MUITO ANTES.

Em fato 15 anos antes quase (em relacao a DARK). A novela trouxe esse conceito (na epoca inovador) para as massas, seja querendo ou sem querer trouxe isso. Talvez a PRIMEIRA novela no mundo mundo a trazer esse conceito (alguns filmes e livros ja trazem isso em certa medida; Veja o filme: Os 12 macacos).

Sobre esse 1 ano de diferenca isso tem varias explicacoes dentro da novela (inside universe e fora dela (outside universe):

1. A mais simples eh: o registro foi feito ERRADO na hora – um erro desproposital.

2. Esteban foi resgistrado com um ano de diferença proposital para evitar algum problema/investigação.

Mas esse ELEMENTO EH A PARTE interessante do plot que SEMPRE LEVARA a duvida. Então a serie não tendo um fim deterministico. Sempre havera uma duvida: Sera que ele eh seu próprio pai?

SEGUNDA INTERPRETACAO

TODA a novela se trata dos ULTIMOS pensamentos (ou memorias) do protagonista Esteban enquanto ele MORRE NA PRAIA. Porque ele caiu. Por isso a novela começa e termina nessa cena.

Isso seria similar ao filme Once Upon a Time in America, onde o protagonista Noddles (Robert de Niro) . Essa interpretacao explica porque algumas coisas são desconexas non-sense e não batem: elas são da memoria/imaginacao dele. E faz todo sentido. O fato de nunca vermos ele morrer na tela ajuda nessa interpretacao. Sobre esse 1 ano de diferença no registro: isso seria parte do sonho/imaginação.

Mas esse ELEMENTO EH A PARTE interessante do plot que SEMPRE LEVARA a duvida. SERA que era tudo imaginação ou eram memórias? Sera que nada se tratava de realidade?

Termino aqui ressaltando que Kubanakan, apesar de todos os problemas – como terminou – trouxe um conceito diferente de final em aberto.

Being able to use OCP build configuration is a strong feature that improves the speed of deployment by a long margin.

Building images via docker/podman can be an very streamlined process, but build config directly on OCP provides a fast deployment procedure straight to be able to deploy pods/containers in such a way that the changes are applied very fast.

One does not need to use Tekton/Pipelines to be able to build a complete new image with complex settings, either with git source, dockerfile, or custom strategies. The deprecation of jenkins build configurations going towards Pipeline deployment – with Operator (with tasks that compose pipeline).

A simple build can be done in OCP in a few minutes and the image build straight to ImageStream, that can be used on the spot.

I mean, it is simple, powerful, easy to debug and can deploy containers (and therefore test images) on the spot right there and then. It is also very simple to debug – MAVEN settings can be easily added on the build. I like very much that the build has the logs so well linked so then the pods show the step done.

I think I already discussed this topic a few times here but it is interesting that requests and limits are N/A for java (JVM) perspective – OpenJDK will use limit as the mark for cpus.

And naturally, given the container’s cpu values are static (except on k8s 1.27) so then the limits will be inelastic.

Objectively, for the JVM basically limits will be used limits. The JVM won’t re-scale on the fly and will be ineslastic, and won’t re-scale on the fly so the number of threads (for instance parallel GC threads won’t change after the JVM has started). So the cpu details won’t fluctuate and this will change the GC threads or some deduced thread (pools that use cpu for calculation).

It is interesting that the JVM will actually round up the cpu for instance, so one pod with 5.2 cpu will end up being 6 cpus (with 2 cores and 2 threads per core for instance), depending on the K8S architecture below.

In any case collect the jcmd $PID VM.info to be able to display the values correctly and look for something like this:

→ CPU:total 4 (initial active 2) (2 cores per cpu, 2 threads per core): so 2 cpus == 4 cores == 8 threads.

Back on DG/EAP 7 we used to use template for Source to image deployments at some point.

In fact I liked template deployment of course you need to import the templates and such, but I don’t think it is bad from a functional perspective. And the Operator is so simple, it gives much more time for the user to focus on what matters.

I think helm charts will streamline this process, instead of templates. It is pretty interesting and very flexible in some ways.

## to install
helm install <release_name> chart <flags>  --> flags can be in the middle as well
## to upgrade
helm upgrade <release_name> chart <flags> --> flags can be in the middle as well
## to uninstall 
helm uninstall <release_name>

It is interesting to handle the pod’s yaml directly on the statefulset/route instead of the custom resources, which is the default by the operator. It is a sense of a flexibility and responsibility as well, given there is much more room for the user to screw up.

I love Avatar, both of them, great movie. Made by a Canadian. Astonishing images. Back in year ago when I was released, but still have impressive images. Pandora is amazing.

However, the second has one main problem: it is 100% plot driven – not character driven. That’s not a spoiler, but be aware that the characters won’t make hard choices and set up a path for adventures. It is pretty much the opposite, the plot happens despite the characters’ choice.

Basically there is only one character that drive the plot: the whale and maybe the “bad guys” as well and one/two difficult choices. No big dilemma or little components that make the character choices critical ending.

The movie is not bad though, but probably on the Avatar series it won’t be the top 1st best.

At some point I gave up the plot and only was seeing the movie, like I used to watch Windows media player would create just for the music.

I mean arguably, one can image several scenarios and how each character should behave. And the end result may not even be better than the final result. But changing some part of the script, not 100% the fundamental here, the result would be 2x better and the characters would be much more relatable. Because we relate with characters that make choices, even bad ones.

But the explanation is likely because there will be several movies, so this one is just setting up some stones so then the next movies there will be some dilemmas and hard choices.

Working with Openshift in a daily basis, I come with several situations where the pod crashes. Given my background on java, I will talk about java here.

Let me list a few situations and the next steps

pods crash with OOME	The java process uses more heap than it was suppose – it would generate a heap on OOME exception – but it might exit given: ExitOnOutOfMemoryError
pods crash with OOME killer	Verify OCP node dmesg and verify if there is OOME Killer messages

How to know why my pod is crashing?

Let’s pretend you don’t know why the java pod (java pod here == pod with one container that is java). The first would be to see if the pod is OOME (in the JVM) or suffering from OOME-killer.

OOME will be handled by the JVM itself however, because the containers usually have ExitOnOOME so then the container will exit, which will prompt the orchestrator to respawn new pods given a certain timeout period.

For OOME Killers, this is an external agent (OCP node, or the cgroups) acting out and affecting the container to finish it up given a certain condition. Like lack of resources if the OCP (kubelet) needs to spawn a certain pod but doesn’t have resources, so it might just terminate the QoS best efforts ones over spawning Guaranteed pods.

Or that can be a native allocation breaching the cgroups limitations and causing the container to exit, by being killed.

Complementary to getting the jcmd VM.native_memory, the jcmd command VM.info, which I discussed a few times on this blog can be an awesome tool for investigating (native) leaks. This feature requires 8u222 or later if I’m not mistaken.

In fact, for containers, I would just get jcmd VM.info directly, which in fact has the jcmd VM.native_memory. So VM.info can, easily be used instead – Native memory info will be on the VM.info.

jcmd PID VM.info

VM.info will show detailed summary of the VM and the OS, including the native details and shared libraries – the native details will only show if Native Memory Tracking flags: -XX:NativeMemoryTracking=summary or XX:NativeMemoryTracking=details are there. Otherwise VM.info won’t display this section – but other sections will be there regardless.