All the good things Records bring are stifled by JPA and DAO conventions and requirements. I really hate JPA for that reason, and have avoided Hibernate in favor of my own DAO implementations.
Records will slash thousands of lines of code from my implementation and will make it infinitely easier to maintain, and trust down-stream.
With some of my smaller clients, the CIO is the same as the CTO and the same as the IT Director. There, IT is developers, too.
Enterprise will cause a boom in hiring VBA devs to migrate legacy apps to other programming languages, then hear Microsoft will extend support for a few more years, then fire all those VBA devs again. If Microsoft had some wits, they'd create easy tools to migrate VBA to C#.
Wouldn't it face the exact same security issues as VBA, with drive-by installs of obfuscated malware and executions of arbitrary code?
Sure! I wrote all about it over on Medium: https://medium.com/@aev_software/java-jakarta-soap-wsdl-client-fails-to-read-soap-message-for-logging-38087a63ea6d
To summarize: custom logging handlers failed after upgrading to version 3, because the underlying implementation that exports a message as a SOAP message is broken.
Cool. Just what I need: yet another version of a JDK/JRE to test. I feel like I spend more time testing these for regressions than I spend developing functionality for my clients. Anyway. Good for Adoptium and those who found and solved this bug.
I started using Jakarta half a year ago, as it was promised to be the de-facto way to build a SOAP client that speaks to a WSDL server. Oh boy: growing pains. Did not expect that 2 decades of developer experience in Java EE would amount to nothing, for the people who implemented Jakarta. As impressive as the effort may be, the inexplicable regressions we faced when we got forced to upgrade to version 3 proved quite cumbersome.
So they say. Remember they also promised not to track users, keep trackers away, and keep your browsing experience ad-free. They came back from that within a year.
One would switch to a free JVM when other JVMs change their licenses from free to paid. OpenJ9 was the first free JVM to which I got introduced. Knowing it was based on the work by IBM, known for high performance and low memory footprint, it was a simple choice.
Great questions and feedback! Thank you! Is it OK if I use them to augment my article?
Please find below my reaction. I may work this into the article some time this week.
Yes, there is a major stumbling block due to Javascript: it doesn't multithread well. One can use asynchronous programming (either with or without promises) or, as I did in that implementation, use time-outs. But none of that is very nice or elegant when it comes to continuing to process the game while accepting user input. They are a far cry from actually starting a separate processing thread, which is possible in other programming languages. Those can be used now that browsers started supporting WASM. Unfortunately WASM cannot interact with the DOM, meaning it won't help for GUI-intensive games.
Getting the frame rate right was a bit tricky. It depends on the time-outs set for refreshing the screen and moving the tetronimos. As the game speeds up, those time-outs get smaller and shorter. Lacking a frame-rate framework my program has to keep track of it and control it. That required some additional architectures that probably are handled better by phaser.
The mobile experience is interesting at times. I had built the GUI specifically with mobile devices in mind: tablets and smart phones of various sizes should be able to play the game without much of a problem. That's why the game buttons are positioned on the sides of the grid: within reach of the sides of the mobile device, to be operated by thumbs. And that's why there's 2 sudden drop buttons: one on each side.
One of the features of smartphones is to zoom in and out on double-tap, but since this game relies on fast tapping I had to build in a way to avoid that causing unexpected zooms. Another feature is scrolling in response to sliding ones fingers across the screen. With fast button pressing and switching, chances are some motions get misinterpreted as slides / swipes. Thus I had to disable that specifically. That can be a bit awkward when someone attempts to scroll the game display intentionally. I have not yet figured out how to work around that. Maybe I can add more room on the sides.
Over time more differing screen form factors appeared, and some phones (like the one I use today) differ so much from what I had available in 2014, that it makes game-play slightly more difficult. They make it so the game has to be zoomed out more than is comfortable for the button size. That has to be large enough for thumbs, and zooming out the entire game makes them too small. I can work around this by making the width the tetronimo grid a function of the available screen width.
The game is completely unplayable on smartwatch. It would need a separate form factor altogether.
My kids liked it just fine. Their biggest complaints were that the tetronimo blocks didn't move as soon as they pressed the move buttons, and that the game didn't have a soft drop option, like found in other Tetris clones. To this day they enjoy playing Tetris... even if it isn't the clone I built.
Again, thank you so much!
:(
May his loved ones find solace in sharing those memories of him, that inspire them most.
The Post? Really? Half of that article is an ad for the Post itself!