You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 29, 2021. It is now read-only.
Vert.x is interesting for 2 reasons: one, it's a good case study for good project organization and community building, and two, their technology and/or ideas + concepts can be quite relevant to you.
(You might want to take a quick peek at vert.x landing page before reading on)
Some interesting bullet points (I won't digress too much, hopefully):
appealing web presence, narrow profile, everything branching out from landing page
well-guarded core, under Eclipse guidance, but without most of its strictures
toolkit with a comprehensive set of officially supported modules (meaning: compatibility, stability guarantees, follows release cycles, not customer/dev support)
clean, consistent, relevant set of repositories in vert-x3, no pollution
if you are officially supported you must be in vert-x3
community can be promoted to official modules based on popularity, use, stability and quality. The core team is the ultimate decider here
~800 questions on SO. Modest, yes, but not requiring core team attention at all
very active google group and freenode channels for the dev team
and with all this vert.x didn't change its identity. It still felt like the project as it was before the Jykes! curve started mounting
Vert.x technology
Not only is vert.x an excellent example of a message-based application framework, it also puts the properties that come with such architecture design to good benefit. For example by adding polyglot programming support.
Now this should resonate with the scientific community! I would bet that given N programming scientists, you get N + 1 programming languages being used. Vert.x polyglot programming allows teams / projects to cooperate seemingly using their (jvm-based) language of choice. And this goes further than just having decoupled modules, or microservices written in different languages.
[Note: Regarding JVM I should probably write another post sometime, on a number of interesting cultural observations I made, as a newcomer to your community, like religious superstitions. Let me know if you're interested]
If Dat were to be polyglot in the future it would attract a broader range of scientists to both dev and user community - people that already have the proper mindset and moral + ethical values (in general).
Then there is the vert.x toolkit itself. Even though vert.x is running on the JVM it can be a useful technology for running/combining with Dat. I don't know the terminology, but I hear about various background services, storage, blind servers, repeaters/forwarders, elevated services, etc.
Concluding: "Be inclusive and open towards all technology"
The text was updated successfully, but these errors were encountered:
Vert.x
(NOTE This showcase is part 4 of Positioning, vision and future direction of the Dat Project)
Vert.x is interesting for 2 reasons: one, it's a good case study for good project organization and community building, and two, their technology and/or ideas + concepts can be quite relevant to you.
(You might want to take a quick peek at vert.x landing page before reading on)
Some interesting bullet points (I won't digress too much, hopefully):
Vert.x technology
Not only is vert.x an excellent example of a message-based application framework, it also puts the properties that come with such architecture design to good benefit. For example by adding polyglot programming support.
Now this should resonate with the scientific community! I would bet that given N programming scientists, you get N + 1 programming languages being used. Vert.x polyglot programming allows teams / projects to cooperate seemingly using their (jvm-based) language of choice. And this goes further than just having decoupled modules, or microservices written in different languages.
[Note: Regarding JVM I should probably write another post sometime, on a number of interesting cultural observations I made, as a newcomer to your community, like religious superstitions. Let me know if you're interested]
If Dat were to be polyglot in the future it would attract a broader range of scientists to both dev and user community - people that already have the proper mindset and moral + ethical values (in general).
Then there is the vert.x toolkit itself. Even though vert.x is running on the JVM it can be a useful technology for running/combining with Dat. I don't know the terminology, but I hear about various background services, storage, blind servers, repeaters/forwarders, elevated services, etc.
The text was updated successfully, but these errors were encountered: