Posing a question for the good of the Omnis community – want to move to STACK EXCHANGE?

Clifford,

You bring up a number of good points, which we should probably put in its
own thread.

RE: “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.”

Items you mentioned are key, however I wished that more fundamental
features were “built in” the JS client/omnis out of the box. Some of these
include:

– User authentication

– Security – SQL injection, cross-site scripting etc etc.

– Tempalting

The above items have now essentially become a “standard” in frameworks. In
my opinion developers should be spending time building apps rather then
focusing on items mentioned above.

Omnis is a solid tool, but a lot of time is spent outside of app
development in comparison to other frameworks.

Andrew

On Mon, Feb 5, 2018 at 11:17 PM, Clifford Ilkay <cilkay@gmail.com> wrote:

> 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
> is.
>
> 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
> on the right? Django, JavaScript, Node.js, Swift, Kotlin, Ruby on Rails,
> 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
> then.
>
> 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
> Mustache (Javascript) or Jinja (Python) templates. Django page templates
> 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
> (Ruby), NPM (Javascript), Bower (front-end Javascript – though NPM is
> 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
> StackOverflow.
>
> Regards,
>
> Clifford Ilkay
>
> +1 647-778-8696
>
> On Mon, Feb 5, 2018 at 5:43 PM, Das Goravani <das@goravani.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:omnisdev-en@lists.omnis-dev.com
> >
> _____________________________________________________________
> Manage your list subscriptions at lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en@lists.omnis-dev.com
>
_____________________________________________________________
Manage your list subscriptions at lists.omnis-dev.com
Start a new message -> mailto:omnisdev-en@lists.omnis-dev.com