Ciao my dear friends,
First things first. We consider the concept of Projects and Environments
both crucial and essential. In Kettle we implemented these concepts by
using a framework that we developed by our own that unfortunately is not
that integrated with spoon but works as a charm when things are started
using kitchen. And this is enough. Having this as a core feature of the
product and completely integratd in the gui is fantastic! I always
thought (and said many times I had the intention) to write something on
the topic to propose some changes but never had the time to do this so
now is the right time to say what I think about that. We also shown Hop
GUI to some of our customers to understand also what they think about
this and the way is managed in Hop.
Therefore, let me summarize some things that we consider important
improvements that we would like to have in Hop.
1. We prefer the application working "project centric". In our opinion
everything is best started with a project. I don't think that creating a
new project is a great overhead for a Hop's user. The strength of this
is that helps us keeping things clean from the very beginning. There
could be also the possibility to build a quick pipeline for a quick a
dirty thing of course but must be clear that this must not be the right
approach for things "architecturally clean".
2. We found very useful to be able to create, open, close and delete a
project. Currently we can create a project from scratch and we can
delete an existing project. The "Open project" is almost unavailable (if
not at all). If this can be done by changing a project through a
selection from the project's combo box that is not immediate. Also, is
not clear to me how things changes (if things changes). But for sure we
can't close a project to start working on another and this feature is is
really needed (Matt, this is the same thing you are saying when you talk
about disconnecting from a project at point 2 below). Closing a project
is a feature that we can't miss in our opinion. We asked some of our
customer some impressions and they were all convinced that this
feature(open/close/edit of a project) is not that easy and immediate the
way is implemented and lacks of some functionality we described lastly.
3. I think that apart from quick links in the toolbar for create, open,
close, delete it would be nice to have the same in the File menu. This
aligns Hop with any tool (IntelliJ for example) in terms of usability of
the interface. Not a big effort needed, I think, to do this.
4. Looking at Hop GUI the very first time I immediately had the
impression that Project and Environments were two separated things. Of
course this is not (I understood that I misunderstanding only after
looking at the code) but that was the impression the GUI gave me. The
other point of misunderstanding for a user IMHO is also that looking at
the project dialog I have a place to configure a set of project's
variables.... but I also had environments. I mean, why do I have the
necessity to configure project's variables (in project's dialog) when I
have an Environment that is the natural place to configure various
facets of our variables. Moreover I can't configure environment
variables from the GUI and this for a non technical user is a great
limitation. Therefore IMHO the only and right way to configure all the
needed Project's Variables is to give the user the awareness that is
doing this in the context of a specific environment the user choosed to
act on. To do this, in my opinion, a new design of the project's dialog
is needed and must contain the environment combo to give the user the
awareness of this strong relationship. By choosing a specific
environment from this new combo, the current "Project's Variables to
Set" table must give the user the ability to create, update, delete
variables for a project in that specific chosen environment (with great
awareness let me say once again). Another thing to add to the new design
of the Project's Dialog is a button to create/delete an environment in
case that will be needed. The current Environment combo on the toolbar
could only be used to quickly switch between environments, nothing else.
Two last things. First, because of this strong relationship between
projects and environments, when a user creates a new project a new
environment must be mandatory created (by default from Hop if the user
want to be bothered on this). Second, environment's configuration files
must be managed (i mean created) directly by the application and not by
the user by his own. This will keep the tool the less technical the
possible and raise up the usability to non technical user. This idea of
having a tool that can be also used by non technical users is one of the
strength of this product and we strongly push this concept to any customer.
My apologizes for this long message but I think I said all the things I
wanted to say on this crucial topic. Let me know what you think.
Cheers
Sergio
Il 21/01/2021 16:18, Matt Casters ha scritto:
Dear Hoppers,
In a lot of other IDE like tools you find a project-centric approach to
developing something.
Using a project is mostly enforced by the way that software works, for
example Eclipse or Idea.
In Hop we implemented projects as part of a plugin because sometimes you
just want to trim things down to the bare essentials. So essentially what
this comes down to is that you can use projects and put all your work under
a certain folder as per usual OR you can do your own thing and configure
Hop just the way you like.
Right now though it's not possible to not use a project once you've used
one in the GUI.
Brandon raised this issue in a JIRA case and on the chat and perhaps it was
a misunderstanding but in any case we are faced with some options to reduce
confusion:
1. Force the use of a project on a user. Don't even allow new files or
metadata to be created without a project to work in. This is how most
tools work but the downside is that we'd have to nag the user for the
creation of a new project before anything can be done.
2. Keep things as the way they are but allow the user to disconnect from a
project. Carify where metadata is stored in this scenario. We could simply
add a new button in the toolbar to "disconnect" from a project which would
simply clear the project combo box.
3. Option 1. but with automatic creation of a "Default" project. We can
store that project somewhere in a standard location (configurable) like
Eclipse does in ~/workspace/ or simply in the config folder next to the
metadata (./config/projects/default)
I honestly have no opinion on it so I thought I'd ask. It's not urgent but
it warrants clarification since this confusion will continue to bubble up I
think. Maybe you have another idea? Let us know. I'd be happy to make
the changes to the codebase, those are likely quite limited.
I also think this issue can be tied together with the shipment of standard
samples packages with the Hop distribution. Perhaps if we have a Default
project we could also have a "Samples" project.
Cheers,
Matt
--
Best Regards/Distinti Saluti
Sergio Ramazzina
Senior Solution Architect
Via Milano 78
20013 Magenta (MI) - ITALY
mobile : +39 347 2103689
Tel: +39 02 87158700
Fax: +39 02 87151947
website: http://www.serasoft.it <http://www.serasoft.it> - email :
[email protected] <mailto:[email protected]>
skype : sramazzina - Follow me on twitter: sramazzina
View my profile on LinkedIn: http://www.linkedin.com/in/sramazzina
<http://www.linkedin.com/in/sramazzina>
