Posing a question for the good of the Omnis community – want to move to STACK EXCHANGE?
StackOverflow is great but it will not accomplish the goal of increasing
the visibility of Omnis. In fact, it will likely expose how small the
community is and the weakness of Omnis in things that matter to developers,
like career options. Someone mentioned various technology stacks, like
Django, that use a multitude of support channels, like StackOverflow, a
Google Group, Reddit, IRC. That works for Django because the community is
several orders of magnitude larger. Omnis will never have that no matter
how it is marketed or your wish that it were some way other than the way it
Think about what the StackOverflow business model is. They provide an
excellent tool for developers to ask high-quality questions and to get
high-quality results. Why? Those ads on the sidebar, especially the
employment ads. We’ve advertised on SO before and I can tell you based on
what they charge (not cheap) and the various ways of monetizing the
relationship they have with developers, it’s a brilliant business model.
How many ads for Omnis developers would you ever see on that site even in
the very unlikely event that the Omnis developer community grew 10x? You’d
be lucky to see dozens a year. What kind of ads will Omnis developers see
etc. It’s not that Omnis developers don’t know these other technologies
exist. Even if they have never used them, they at least know that Omnis is
not the only technology stack and if they were motivated to do so, they
could go and learn those things. It’s the message that will be sent to a
developer who hears of Omnis somehow, who starts poking around on SO for
Omnis questions and rarely sees an ad on the sidebar for Omnis talent that
will have him or her move on to something else. Why would a young developer
bother to bet their career on Omnis if they do not see a wide variety of
jobs available in a wide variety of industries? We’re not even talking
about the technical merits, or lack thereof, of Omnis.
The lack of good search results is a problem and that in some measure has
to do with the tension in this community between privacy purists who seem
to think the Omnis list is as one put it, and I’m paraphrasing, “The list
should be like friends gathered around a campfire sharing stories. What
gets said there stays there.” and those who look at this pragmatically and
say, “If you’re concerned about that, don’t say anything that will haunt
you later and if you do say something you regret, which is only human,
clean up the mess you made.” I wanted a Google Group years ago because it’s
a way of satisfying the fans of mailing lists and fans of forums and I
remember it was a contentious issue. Maybe the thinking has evolved since
An immediate and simple change that can be implemented by Fred H. is to
allow HTML emails to be sent to the list. Right now, the list is configured
to strip off the HTML part of multipart messages. I cringe every time I see
code fragments posted to the list because that properly indented code ends
up looking like a dog’s breakfast when it hits the listserv. It’s 2018. If
you don’t want to receive HTML email, you’re free to look at the plain-text
version of the message, though you may lose important information. The list
is configured as if the majority of subscribers to the list use Mutt or
Alpine as their email client over a 2400 baud dial-up connection and I
think that has more to do with inertia than anything else. Fred can correct
me if that isn’t accurate. This one change can enable people to post
screenshots and formatted code samples.
I had created Google Groups for omnisdev-en, omnisdev-fr, omnisdev-de,
omnisdev-it about 12 years ago. I’d be happy to transfer ownership of those
groups to Fred H. A way of migrating to those groups would be to subscribe
those groups to their respective lists.omnis-dev.com counterparts so that
messages sent to the current lists get sent to the Google Groups and vice
versa. People are then free to unsubscribe from these lists and move to the
Google Groups, or not. There won’t be a need to do a forced migration. It
won’t fragment the attention of the community because the same message will
be distributed regardless of which one you subscribe to. Eventually, the
need for the listserv may disappear as the majority of people migrate to
the Google Group.
I’ve watched as Das struggled with getting a simple connection to a
database. His experience underscores how bad the “out-of-the-box”
experience is for developers. It took him far longer than it should have
and required many people to fill in gaps in the Omnis documentation. I’ve
often written about how much I love the Django documentation. I built my
first Django-based application while doing the Django tutorial. In 2008, I
used the Django tutorial as part of an “Introduction to Programming” course
I taught to high school students. The Django tutorial is a masterclass in
how to write documentation in a way that can give someone new to Django a
quick introduction that covers key concepts without getting bogged down in
lots of details. Where is that for Omnis Studio? The list archives cannot
be a substitute for a good tutorial. Das, this is where you can contribute
by blogging an “Introduction to Omnis”. You may already have a blogging
platform. If you don’t, Medium, LinkedIn, GitHub pages are all great
options for blogging.
TodoMVC <todomvc.com/> is often used as a way of building something
non-trivial. Build a sample TodoMVC application in Omnis and deploy it on
the Heroku <www.heroku.com/> free tier. That and the curated
Awesome Lists <github.com/bayandin/awesome-awesomeness> that I’ve
mentioned before will probably do more to make more Omnis more visible than
moving to StackOverflow.
Here are a few other things that are missing in Omnis to make it an
interesting web/mobile development technology stack. Create one or more of
these things and share it on GitHub.
1. Implement an ORM (Object Relational Mapper) for Omnis. Read up on the
Django ORM <docs.djangoproject.com/en/2.0/topics/db/models/>. You
don’t necessarily have to understand Python to be able to understand the
ideas behind this. The thread that Das started last week about “standard
SQL” and the challenges of that in Omnis is due to a lack of an ORM.
2. Implement a schema migration tool for Omnis. Read up on how Django does
it at <docs.djangoproject.com/en/2.0/topics/migrations/>. Django is
open source so you can even see the implementation and get ideas there.
3. Implement a templating engine. You can start with an implementation of
are very similar to Jinja templates.
4. Build a reactive application using Omnis using ReactJS Native or Flutter
(Dart) on the front-end and Omnis providing a RESTful API. I would never
use Omnis in that scenario but you don’t have to convince me. You’re the
one who thinks Omnis adds some value so demonstrate that. The only value it
adds might be “I already know it and don’t know anything else.” and that is
certainly worth something. Make the case for Omnis without saying things
like “It’s the best.”, “It’s very productive.”, or “Friendly community.”
since the first two things are very subjective and this community doesn’t
have a monopoly on being helpful, welcoming, or smart.
5. Build a GraphQL application and demonstrate how Omnis adds value there.
6. Do some benchmarks of non-trivial applications and share your findings.
Make it easy for people to replicate your benchmarks by providing a Packer
build configuration for your environment.
7. Write a proposal for Omnis modules, create examples, a module creation
framework, and write documentation. There is no standard way to integrate
small Omnis libraries to form a more complex application right now. It’s
pretty much the Wild West. This is probably something you’ll have to
convince Omnis engineering to participate on.
8. Create a package registry and distribution mechanism that is independent
of Omnis Software to distribute Omnis modules/packages/libraries, whatever
you want to call them. Various languages use this to great effect. Gem
winning because it can be used in back-end and front-end), PIP (Python),
PUB (Dart) are some examples. Someone should be able to to do the
equivalent of “pip install -r requirements.txt” (*) like they can with a
Python-based application to re-create your Omnis-based environment.
OmnisCLI may come in handy there.
(*) requirements.txt contains a list of all the Python modules and their
versions that the application depends upon.
9. Create a NoSQL DAM and demonstrate how to use it with some of the
popular NoSQL databases.
Doug mentioned the need for a Linux appliance and conflated that with
Docker “VMs”. Docker is not a virtual machine. It’s a container technology
intended to be lighter than a virtual machine image. You compose Docker
containers using something like Kubernetes to create an application. The
best practice is to not treat Docker containers as if they’re virtual
machine images and instead treat the contents of containers as
microservices. Given the licensing requirements for Omnis, I have no idea
how feasible it is to spin up and spin down Studio App Server containers on
demand. Unless you really understand the differences, you’re probably
better off with a virtual machine image. Vagrant is great for this.
Any of these things above will have a greater impact than moving to
On Mon, Feb 5, 2018 at 5:43 PM, Das Goravani <email@example.com> wrote:
> Omnis has NEVER enjoyed being KNOWN to the world.
> It would sure be good to change that.
> Ensures the life of our apps and careers
> I’ve been with Omnis since 86, and have SUFFERED that it’s so not known.
> I agree with doing what it takes to make it more KNOWN
> Manage your list subscriptions at lists.omnis-dev.com
> Start a new message -> mailto:firstname.lastname@example.org
Manage your list subscriptions at lists.omnis-dev.com
Start a new message -> mailto:email@example.com