Aroura is a JDBC connection yes, however a more 'native' one would be beneficial for connection, so that you could use
running WITH queries would be useful, through that is supported in MSSQL which Gen does not support
These are the main things for us at the moment as i can build anything else within PostGre, so would not require a change to Gen
Original Message:
Sent: Feb 18, 2024 04:26 PM
From: Daniel Stratton
Subject: Technical Ideas recommendations
Mike,
If you don't mind, I'd like to tease this one out a bit because I haven't had a chance to play much with the cloud infra myself.
My first question would be, what application target are you using? Because my life tends to be Java focused outside of Gen, Aurora seems to be a JDBC connection regardless of whether it's direct or through the RDS proxy.
Your specific point:
> Though JDBC is supported in this case most of the interesting aspects of PostGreSQL are missed, this means that you now have to write code around for a database element this lowers performance thus negating the move albeit the cost.
This is the one that really interests me. What particular aspects do you feel are missing? My initial reaction to reading this is that it feels like lacking of features. Is there a specific feature or function you feel is missing? I'm wondering if what you're looking for may also be more broadly applicable to all supported DBMSes or whether it's specific to PostGreSQL by itself.
Original Message:
Sent: Feb 16, 2024 04:30 AM
From: Mike Conway
Subject: Technical Ideas recommendations
I think re
Open Source Database
Your request here seems less technical and more business - as you acknowledge, you can already connect to almost any database that has ODBC or JDBC drivers, so there's no technical hurdle. Is your primary concern one of having support if you pick such a platform and encounter issues? Or is it primarily the Encyclopaedia database you worry about? Because they're two separate concerns. While I'd like more DB support for the Encyclopaedia for spinning up POCs and what not, I'm not sure this is a show stopper.
---
Connecting using ODBC or JDBC is not a show stopper, however, I would suggest that it is a limitation. For example our clients would like to move to more of a cloud structure. The database here is a limitation, in this environment all major cloud hoster's provide some element of native PostGreSQL, AWS - Aroura is based on this. So enabling a more Gen support aspect of PostGreSQL would help here allowing us to move to this DB and eventually convert to either AWS or Google. Though JDBC is supported in this case most of the interesting aspects of PostGreSQL are missed, this means that you now have to write code around for a database element this lowers performance thus negating the move albeit the cost.
--
Angular
I think that this is a good idea and makes sense, however, i would suggest that this is built into the Gen Toolset and generated from this point. My reasoning for this is that it stops project fracture and probable deploy/release join. Also financially, Gen licenses are expensive. Moving away from the Toolset would set this all at a disadvantage for medium businesses. Where the question would be what are we paying for?
Original Message:
Sent: Feb 12, 2024 05:17 PM
From: Daniel Stratton
Subject: Technical Ideas recommendations
Tarek,
A few thoughts from me. I agree with your assessment that there's significant value in Gen in both what it does now and what it can do in the future.
However, I'm not sure I'd agree with your priorities on this one - and I think that's the challenge. There's a lot of different competing priorities for different organisations, and the Gen team has a lot to deal with. I think they're doing a good job of balancing those priorities between delivering new functionality and keeping up currency with certifications and platform support. They've moved solidly in good ways (e.g. Linux CSE) which will broaden it's ability to be deployed in a lot of locations.
To address your points more directly
Open Source Database
Your request here seems less technical and more business - as you acknowledge, you can already connect to almost any database that has ODBC or JDBC drivers, so there's no technical hurdle. Is your primary concern one of having support if you pick such a platform and encounter issues? Or is it primarily the Encyclopaedia database you worry about? Because they're two separate concerns. While I'd like more DB support for the Encyclopaedia for spinning up POCs and what not, I'm not sure this is a show stopper.
VS Code
I won't comment on this given my day job except to say I believe a strong, 3rd party ecosystem drives things forward very well, and the strong collaboration that Broadcom has with its partners has allowed delivery of functionality through multiple avenues and has let Broadcom deliver on their own vision..
Rename Gen
I'm not sure what Technical Idea there is here. I'd rather they spend time delivering new functionality myself.
Node.js, Frontend Frameworks, RESTful web services
This is a bit of a head scratcher - you just recommended Java further up as best for majority of customers, but now say it's legacy.
I generally agree with your premise here of interoperability - if Gen integrates more easily into frameworks, then it becomes more frictionless and easier to adopt. However, with the world generally standardising on web services, I think that's the key part here. As long as it's got good support, then it quite readily can plug into frameworks and other things.
Your position here is somewhat inconsistent with the one above about VS Code in respect to partnerships.
Encylopaedia on Cloud
Beyond the licensing aspects, and how chatty seamless checkouts can be - there's nothing istopping an Ency in the cloud now. Are you proposing that Broadcom would host a centralised encyclopaedia (with all the security management involved) that businesses could host their code in? I imagine separation of code concerns would be a high issue.
Build Tool & Deployment
DevOps is such a loaded term - and unfortunately, it's very agile. As with app frameworks, as long as it can interoperate quite well with other things, I think that's all you'd need.
Apart from Assembly, though, the build tool in command line mode does a lot. We internally have Jenkins pipelines to perform all our production builds, and it's all scripted off RMTs with different Load Modules requiring different profiles. An extension to that to support command line assembly and I could imagine almost all cases could be covered.
Personal choices
Given my own choices, my priorities would be quite different from yours:
- Standardise on Unicode across the board
- Run the CSE everywhere and migrate HE to CSE
- Extend the language to include new features (left joins, recursion capacity, varying sized groups, etc)
- Interop, interop, interop!
But that's the joy of being able to suggest, and not have to deliver it :)
Original Message:
Sent: Feb 12, 2024 05:33 AM
From: Tarek Kamal
Subject: Technical Ideas recommendations
Like a precious diamond hidden in the sand, Gen is a valuable tool in the software industry. Although it has faced challenges in its market strategy, causing some customers and developers to give up on it, its untapped potential remains significant. With over 25 years of experience working with Gen, I would like to offer some practical technical recommendations that may help awaken the genie.
I excluded all the market ideas as they are out of my control.
You can add more recommendations on this post.
§ Open Sources Database:
Gen should aim to minimize operational costs for its customers by utilizing open-source solutions. While Gen does not currently support any open-source databases, it offers the option to connect to any database using JDBC or ODBC. However, it is highly recommended to incorporate open-source databases such as PostgreSQL or MySQL natively and with proper certification. In order to provide customers with a comprehensive solution, it is essential to include an open-source database in the encyclopedia database. This will elevate its value to a level similar to that of an application database. Based on my expertise, I highly recommend utilizing Linux, PostgreSQL (for both the encyclopedia and application databases), JBOSS, and Java as the most suitable platform for a majority of customers.
§ Vs-code:
I appreciate the implementation of VS Code and its potential for the upcoming generation. However, I recommend retaining the mouse click drag and drop functionality in the toolset, as it remains intuitive and user-friendly for individuals from older generations. Additionally, I have noticed that IET has invested significant time and effort in the development of the Studio developer tool, which allows users to utilize keyboards effectively. From my perspective, the collaboration between Broadcom and IET could be strengthened to enhance the overall user experience.
§ Rename Gen:
I am pleased that "CA" has been removed from the name of Gen. As I previously suggested, using "CA" no longer holds any meaningful purpose. Instead, I propose adopting the name "Cool: GEN," which has received widespread recognition and endorsement from the Gen communities. This name change would align Gen with the preferences and expectations of the user base.
§ Node.js:
To keep Gen at the forefront of technological advancements, I recommend incorporating Node.js as a new modern language. Node.js offers enhanced efficiency compared to Java, which is now considered a legacy language. By embracing Node.js, Gen would be able to leverage its benefits and provide users with a more efficient and contemporary development experience.
Front-end Frameworks (e.g., Angular)
Currently, the front-end design of Gen's web application is inefficient and requires significant time and effort. Instead of solely focusing on improving the front-end, I suggest overcoming this weakness by investing in making Gen easier to integrate with popular frameworks such as Angular, React, and Vue.js. This approach would streamline the development process and provide users with a more seamless and efficient experience when building web applications with Gen.
§ RESTful Web Services:
I strongly believe that Gen should incorporate built-in RESTful web services, allowing users to easily expose and utilize them without relying on third-party solutions. By offering this feature, Gen would avoid the perception of being a legacy tool that lacks the ability to incorporate cutting-edge functionalities found in other tools over the past fifteen years. Providing built-in RESTful web services would enhance Gen's market competitiveness and appeal to a wider range of users.
§ Encyclopedia on Cloud:
To align with modern product and tool offerings, I propose hosting the Gen encyclopedia in the cloud. This would enable customers to access it as a service, utilizing check-in and check-out functionalities. This approach would be particularly beneficial for vendors and small customers, as it eliminates the need for on premise servers and reduces the maintenance and update costs associated with physical infrastructure. Additionally, hosting the Gen encyclopedia in the cloud would provide an opportunity for younger generations and students to test and experiment with Gen, similar to using GitHub as a repository tool.
§ Build Tool & Deployment:
In order to keep up with contemporary industry practices, I recommend replacing the current build tool in Gen with a modern DevOps tool. This update would occur after the source code is generated and would streamline the development process, enabling Gen to align with the latest trends and methodologies in software development.