Over a million developers have joined DZone.

NetBeans in the Classroom: What We Can Learn from A Frustrated Teenager

DZone's Guide to

NetBeans in the Classroom: What We Can Learn from A Frustrated Teenager

· Cloud Zone ·
Free Resource

Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.

The frustrated teenager that inspired this article is an extremely bright, though inexperienced, programmer. (We are not speaking here about teenage angst or a young man with girl problems.) He was working on his first web application using Java and the Vaadin framework. Steady progress was being made until it wasn’t. Various issues with cloud deployment and the framework caused him to write:




He wrote that to me after working through little deployment issues for many hours. The application looked fine when it ran locally, but failed to launch in the cloud.

Vaadin was chosen in order to minimize the number of new technologies he would need to wrestle with. Vaadin allows the developer to write both the back-end and the UI in Java using a programming style similar to Java Swing development. JavaScript is not required for interactive web pages and form validation because the framework abstracts this away from the developer. HTML and CSS are not required either, but can be used if needed.

Unfortunately, the technologies that remained left him with plenty of things to get frustrated by. Maven is supposed to simplify dependencies and it does, but it also caused the war file to grow to many times the required size. (temporary files were getting packaged into the build.) Cloud deployment should make it easy to test the application in a production-ready environment. But when the application fails to deploy, it is a challenge to find a log file with the error message. Building a test database in MySQL proved fairly easy, but getting the application to communicate with this database took far more time than it should have.

As he worked through these various issues, we realized that many of the problems and solutions are almost universal for this kind of development. Some of these lessons may save inexperienced developers from painful deployments. The lessons he learned may prove to be good reminders for the experienced developer who should know better.

  1. Browsers cache lots of things, and a browser refresh or even a browser restart is always worth a try. When the code looks good, maybe it is good. If no reason can be found for why the code doesn’t match the application viewed in the browser, maybe the browser isn’t showing that code. A browser restart is just a special case of the classic question from The IT Crowd: have you tried turning it off and on again? Sometimes that means restarting your IDE or you web server. All of these are worth a try.

  2. Cross-browser compatibility has been a pain since 1996; it's actually MUCH better now than it used to be. Frameworks do a decent job of abstracting these concerns away; this is one of the reasons Google created GWT (which Vaadin is built on top of). Last year. the student who designed nciml.com was also pulling his hair out because he couldn't figure out why the site looked great on everything except one recent version of IE. Now it’s broken again in IE,  but looks fine in Chrome! Cross-device and cross-browser compatibility is still a pain, but we can at least recognize that it’s getting better.

  3. It's fine to work late and push ourselves, but we need to recognize when we are too tired to be productive. Coding relies heavily on short term memory. From keeping track of where you are in a 5 step process to remembering which class a  variable is defined in, we waste time when we have to go back and check something we had fresh in mind 2 minutes ago. Short term memory falls sharply when we are sleep deprived. When this happens, the best solution is to get some rest and come back to the problem tomorrow.

  4. It is always best if we can exactly replicate the deployment environment on our development PC.This is actually possible for some cloud systems because, in spite of the oxymoron, we can create a local cloud. In many situations, it may be not be possible to completely replicate the environment. Try to come as close as possible to replication: same database name, same server version (e g., Tomcat7), same version of Java.

  5. Keep emotions out of it. We all get frustrated when things don't work - that's just evidence that we care. Frustration needs to be kept in check because people that are bad at managing their emotions are not very productive. Troubleshooting requires clear logical thinking and it is hard to be clear and logical when we are mad at the stupid machine in front of us.

Join us in exploring application and infrastructure changes required for running scalable, observable, and portable apps on Kubernetes.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}