You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@royale.apache.org by Piotr Zarzycki <pi...@gmail.com> on 2019/05/03 07:33:22 UTC

Re: [JOB] Moonshine-IDE.com is hiring contractors to bring Apache Royale to version 1.0

Too bad that this proposition is not being answered in any way. However
there is still time today submit your expectations and help this project
grow.

wt., 30 kwi 2019 o 08:24 Justin M. Hill <Ju...@prominic.net> napisał(a):

> Hi Alex,
>
> Thank you very much for providing insight into the proper way to approach
> these matters in the Apache way.  I will be mindful of the specific wording
> in the future.
>
>
> Hi Dany,
>
> It sounds to me like you know a lot about React!
>
> Maybe you could start the React part of the comparison document or FAQ
> section, and then someone else who knows Royale better could fill in the
> comparison pieces.
>
> If Royale hopes to have any wider adoption beyond traditional Flex
> developers, I personally think it must communicate clearly WHY technically
> the development community should care.  This - to me at least - means a
> pros/cons list compared to other market incumbents, without being marketing
> nonsense.  It should be based in facts about the technical architectures --
> exactly as you start to describe in your message.
>
> As Alex mentioned, we need these points to be factual and not opinion
> based to maintain the Apache way.   And actually, the facts are a lot more
> useful than opinions, because otherwise technical conversations degrade
> into "I think X way is better", instead of X way requires A instead of B
> which is the method Y uses.  Exactly like your DOM rendering discussion.
> And that is precisely what it seems to me like you are starting to share
> below about things like JQuery not being usable with React.  A lot of
> people know JQuery and like it, so that seems to me something in the "+"
> column for Royale vs. React.
>
>
> Regarding command lines and power users / script -- I'm all for that.  I
> love UNIX / Linux / Mac Terminal ... However, I also hate forcing new users
> who have limited time to learn unrelated things to their immediate task.
> Nobody using Mac for the first time starts with Terminal.  They ease their
> way into it.  My hope is that we can achieve the easing in with Royale.
> Otherwise, I think too much brain power around the world right now is being
> spent re-learning this stuff over and over again, when it could be point
> and click while still having the knobs to adjust behind the scenes.
>
>
> It is a minor personal mission of mine to make it easier for people like
> me who like to program, but have very little time to do so, and don't have
> time to figure out all the nonsense I don't care about like NPM when I do
> have time to program.   I just want to be able to launch an IDE and tweak
> the Hello World example to see how to build useful things that I can start
> to tailor for my needs.  That is one reason why I'm involved in
> Moonshine-IDE.com and it is one of the reasons I care about Royale:  we can
> avoid the Javascript flavor of the month syndrome with Royale.   If I later
> need to get under the hood and script some things together, I'm glad I have
> that option.  But I don't want to start my learning experience with it.
>
>
> Anyway, back to the topic at hand -- I'd encourage you to submit a bid for
> spending some of your professional time on this documentation effort on
> React.   Anything you can do to illuminate these differences would be much
> appreciated, even if someone else has to fill in the Royale side of the
> document.
>
>
> Thank you,
>
> Justin
>
>
>
>
> [image: Inactive hide details for dev-digest-help---04/29/2019 10:55:35
> PM---dev Digest 30 Apr 2019 03:55:22 -0000 Issue 1978 Topics (m]dev-digest-help---04/29/2019
> 10:55:35 PM---dev Digest 30 Apr 2019 03:55:22 -0000 Issue 1978 Topics
> (messages 9973 through 9978)
>
>
> ----- Message from Dany Dhondt <ar...@mac.com.INVALID> on Tue, 30
> Apr 2019 05:54:49 +0200 -----
> *To:*
>
>    dev@royale.apache.org
>
> *Subject:*
>
>    Re: Let's bump Royale version to 1.0 -- submit your bid for assistance
>    to the group by Friday May 3
>
> Hi Justin,
>
> As much as I would like to write an article on Royale vs. competitors, I
> can’t do so at this moment because I don’t have enough Royale knowledge
> yet. But there are things I could point at so that the Royale team can
> formulate answers.
> Here are some questions and ideas I have which could be addressed:
>
> 1. Royale blog
> On our site, there is a section called ‘blog’. Shouldn’t we rename that?
> To me, a blog is something of the past. ‘Examples’ or ‘Code snippets’ or
> something similar would be better.
>
> 2. Faq
> We definitely need a faq. Common answers to basic questions can go there.
> Also, when our StackOverflow database gets rolling, we can put links to our
> faq there.
>
> 3. (Re)rendering
> One of the core principles of React is that it uses a virtual dom. You
> never write to the dom directly. React does that for you. That’s why JQuery
> doesn’t match at all with React. The main advantage of this, is that only
> those DOM nodes get updated which actually change, making React really
> fast. How does Royale tackle this? Can someone explain this in an easy to
> understand way?
>
> 4. Managing (global) state
> Updating a component in React is done by calling setState() and passing an
> object to that method. That’s all very well and simple in small projects.
> Passing state from parents to children is straightforward. You just pass
> in state as props to underlying components. The other way around though is
> hard, very hard. Handling global state is done by implementing 3rd party
> technologies like Redux, MobX or recently by implementing React hooks.
> I believe that Royale binding mechanisms could be superior to this. So the
> question here: how does Royale handles global state?
>
> 5. Justin, at some point in your message, you talk about ‘command line
> nonsense’. I believe you’re right and wrong at the same time.
> Right because indeed, learning React is far more than learning one
> technology. You have to dig through npm, node, JSX, typescript (if you want
> strong typing), webpack/rollup, babel, … and in the end, most of us use
> create-react-app just to hide all those configurations. BUT
> Wrong because there is a massive open source community where you can find
> almost anything you might need in your project. Building a modern web app
> is all about combining existing code to create your application.
> That brings me to this question: is it possible to embed existing pure
> javascript components into Royale?
> An example: one of the most crucial components in any admin application is
> a calendar. In my Flex days, I had to spend hundreds of dollars to get a
> decent calendar component. In React, I use fullcalendar which is a great
> calendar/sheduling javascript component. Creating a calendar component from
> scratch takes years as anyone who has tried will confirm.
>
> 6. Components, components, components, …
> As I stated before, embracing a new application technology involves the
> immediate availability of standard components. PAYG architecture, beads and
> strands is all very powerful, but as a developer new to Royale, I’d want
> ready-to-use, powerful, beautiful components which interoperate seamlessly.
>
> Just some random thoughts…
>
>
> Dany
>
>
> ----- Message from Alex Harui <ah...@adobe.com.INVALID> on Tue, 30 Apr
> 2019 02:16:30 +0000 -----
>
> *To:*
>
>    "dev@royale.apache.org" <de...@royale.apache.org>
>
> *Subject:*
>
>    Re: Get paid to help bring Apache Royale to version to 1.0 -- submit
>    your bid for assistance to the group by Friday May 3
>
> Hi Royale folks,
>
> First, we should thank Justin Hill for his generous offer.  Justin posted
> this offer on dev@flex as well.  This is a copy of my reply on dev@flex
> so apologies if you get this twice and no need to read it again.
>
> This offer turns out to be a good opportunity to educate and/or remind
> folks how Apache projects are different from corporate-driven projects.
> Here's my take on some of important principles at Apache.  Other Apache
> folks may have different opinions.
>
> 1) The Apache Software Foundation (the ASF) itself does not pay people to
> contribute to its projects.  So the subject of this email is a bit
> concerning since it could imply that.  But in this case, a company
> (Prominic) or a person (Justin Hill) is proposing to pay for contributions
> just like anyone hiring a contractor or employee.  Which is totally fine
> and in fact, encouraged.  It would be great if all of you who are planning
> to use Royale would pay for contributions as long as you make it clear that
> the ASF is not the entity paying.  This includes, of course, contributing
> patches or features to Royale that you write yourself (where you are paying
> yourself or your employer is paying you).  Royale is free software, but
> Royale will be better if every user finds a way to contribute.  There is no
> big corporation like Adobe putting in money up front to try to guarantee
> success.  This is more like a potluck than a restaurant.
>
> IMO, it is fine for now for folks to post job offers on the mailing
> lists.  If we get too many job offers, we can ask for a separate mailing
> list or some other place to share job information, but for now, I am
> personally ok with having offers of work-for-pay posted on the list with a
> [JOB] prefix.  Others are welcome to object or propose other ideas.  But
> basically, we want to encourage the growth of the Royale job ecosystem
> without implying that Apache pays for contributions.  So in the future,
> please use [JOB] or whatever we converge on to distinguish that someone
> else is paying.
>
> And that leads to point 2...
>
> 2) Work paid for by someone else is not guaranteed to be accepted into the
> codebase.  Whatever code or other IP is paid for and generated
> (documentation, graphics, videos, etc) might be rejected just like any
> other code contribution from a committer.  Rejections should be very rare
> in Royale as we have designed Royale to be loosely-coupled so the impact of
> some code on other code should be minimized.  But the fact remains that if
> a contribution does not have technical merit or has licensing issues it may
> not be accepted and certainly not because someone paid someone for it.
>
> One reason something could be rejected is because of point 3...
>
> 3) Apache does not want to appear to be influenced by corporations and
> business.  What this really means is that no business entity should appear
> to be running the project, dictating schedules, roadmaps, etc.  Apache is
> all about individuals.  The person with a few hours on the weekend should
> be able to contribute.  Of course, businesses with more money can pay more
> folks to write more code and overwhelm the weekend person.  That's just
> life.  But that business cannot reject the weekend person's contribution
> just because it doesn’t fit into that business's goals/schedule.  And, no
> business can claim to be "the provider", "the sponsor", "the home of", or
> use similar phrases to imply that they are the sole entity in charge of the
> project.  So if a paid contribution implies something like that, that would
> be grounds for rejection.
>
> Similarly, because Apache is about individuals, we get to point 4...
>
> 4) No individual has more influence than any other individual.  No matter
> who pays you or how many hours you have to contribute or whether you
> contribute documentation or code or help answer questions, you have an
> equal voice.  Sure, there will be technical experts on subsections of the
> code that have a vision of what that subsection should do, but that's why
> Royale is loosely coupled:  so you can fork that subsection and create your
> own variant.  Royale itself probably won't designate one component set as
> "the one to use".  There are many to choose from with pros and cons for
> your needs.  And thus, it isn't up to Carlos or me or any other person to
> dictate what is or isn't going to happen.
>
> Instead, projects get work done in a different way...
>
> 5) Apache projects use consensus.  Without a boss to make the call, Apache
> projects rely on consensus (actually, general consensus) to make
> decisions.  That can take more time when everyone has an equal say, but
> there really aren't other options.  So if you have an idea to help Royale,
> post it and neither Carlos nor I will make a decision on it.  We may voice
> our opinions, but it will be up to everyone else reading this email list
> and maybe responding to twitter posts to make it clear which ideas are most
> popular.  And then, since Prominic or Justin Hill is paying, ultimately it
> is his call which ones to actually pay.  We want whatever he pays for to
> have a return on investment for him so he has money to pay for more work.
> And the same goes for anyone else who can make a generous offer similar to
> Justin Hill's.
>
> And similarly, without bosses and only individuals...
>
> 6) Apache projects generally don't have schedules/deadlines/roadmaps.
> There is no one in the project who can fire you for not making your
> deadline.  We want to encourage folks to contribute even in their spare
> time.  So Apache projects generally don't manage detailed schedules like
> you've probably experienced in other jobs.  We have general goals, like
> there is general consensus to get to a 1.0 as soon as possible, but we
> can't set a date and manage towards it since there is no manager.  We can
> shoot for a date, but if we don't make it, we don't make it.  Now if some
> business or individual REALLY needs to hit a date, they can pay folks to
> try to get more work done by that date.  But Apache and the project itself
> can't dictate to others what to do by what day.  Or even what features are
> in or out.  If someone wants to contribute something that is important to
> them but not to anybody else, it will go in based on its technical merit,
> not some strategy document.  And that is to everyone's benefit.  If you've
> ever posted a bug report or feature request to some provider hoping it will
> be in their next release, then you can see the benefit of the Apache
> model.  At Apache, you can fix the bug or implement the feature yourself
> and if you've earned committer rights, it is in the next release.  Or pay
> someone to fix the bug or implement the feature.  Nobody can tell you
> otherwise (unless it creates a conflict for someone else).
>
> Oh, and one more thing...
>
> 7) Apache is a non-profit so it cannot do certain kinds of marketing.
> However, individuals and business can, just not on the project's web
> presence.  So factual comparison tables are probably ok on the Royale site,
> but once you get into opinions, that is best left for individuals and
> business to explain on their blogs and web presence why they chose Royale
> over some other technology.
>
> So, in the end, Justin's email and future emails from others like this
> should read more like below.
>
> Thanks,
> -Alex
>
> -------------
>
> Subject: [JOB] Prominic hiring contractors to bring Apache Royale to
> version 1.0
>
>    Royale helps modernize Flex applications AND provides a great
> alternative
>    to revitalize the next generation Flex ecosystem as a viable
> alternative to
>    Javascript solutions such as React, Angular, and Vue.
>
>    Get paid to help bring Apache Royale to version 1.0!
>
>    Prominic is the company developing the Moonshine IDE for Flex and
> Royale.
>    Prominic is willing to pay developers to help bring Royale to market as
> 1.0.  To apply:
>
>    1) join the dev@royale.apache.org mailing list
>
>    2) review the recent discussions on what needs to be fixed on Nabble:
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com&amp;data=02%7C01%7Caharui%40adobe.com%7Cfc2244e2b6984cf86aa608d6ccc9c75a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921564340786626&amp;sdata=gC1rfZiIcxvWM9NePG0GdsjNl6iFMkmKfbdrcn7vQK8%3D&amp;reserved=0
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com&data=02%7C01%7Caharui%40adobe.com%7Cfc2244e2b6984cf86aa608d6ccc9c75a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921564340786626&sdata=gC1rfZiIcxvWM9NePG0GdsjNl6iFMkmKfbdrcn7vQK8%3D&reserved=0>
>
>    3) Submit to the dev@royale.apache.org mailing list your bid for
> assistance
>    to the group by Friday May 3
>
>    The Moonshine-IDE.com team is willing to donate $2,500 USD in total over
>    the next 30 days to anyone who can accomplish agreed upon tasks
>    to help Royale release a 1.0 version.
>
>    IF you who are willing to step up to the plate immediately (with a
>    deliverable no later than May 26, 2019) to help with:
>
>    * documentation (ASDoc style)
>
>    * examples (code snippets that do things like Tour de Royale)
>
>    * tutorials (well written, friendly, understandable, educational
> material)
>
>    * a mini reproduction of the aforementioned Flex In a Week Series (great
>    idea!)
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.adobe.com%2Fdevnet%2Fflex%2Fvideotraining.html&amp;data=02%7C01%7Caharui%40adobe.com%7Cfc2244e2b6984cf86aa608d6ccc9c75a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921564340786626&amp;sdata=ehetZFgS6Tn9fR0PbFGjKh2yILbeKnKKhfV8ChhM9SA%3D&amp;reserved=0
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.adobe.com%2Fdevnet%2Fflex%2Fvideotraining.html&data=02%7C01%7Caharui%40adobe.com%7Cfc2244e2b6984cf86aa608d6ccc9c75a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921564340786626&sdata=ehetZFgS6Tn9fR0PbFGjKh2yILbeKnKKhfV8ChhM9SA%3D&reserved=0>
>
>    * build automation
>
>    * automated test cases
>
>    * creation of a summary comparison table showing Royale relative to
> React,
>    Vue, Angular
>
>    * a longer write up of competitive articles detailed why Royale is
>    important.  BTW, one reason it can be important is because it is NOT
>    controlled by giant companies.
>
>    * a directory of consultants for hire:
>
>    * OR anything else you would want to see in a 1.0 version of Royale
>
>    THEN
>
>    Please submit to this public group your commitment and cost.
>
>    We will then do this democratically:
>    deadline for bid submissions is 7 days from now -- Friday May 3.  Folks
> on this mailing list should offer their thoughts and opinions on the bids.
>    Carlos (or someone who knows Twitter enough to create another poll) will
>    then do another Twitter vote poll for 3 days to see what folks think of
> the various proposals.  Prominic alone will decide which bids it will pay
> for taking into consideration the discussion threads.
>
>
>
>    Ideally multiple people will commit to doing something "small" for $500
>    each and Prominic can award 5 people the projects.
>
>    The $2,500 USD total will be paid via PayPal.  No exceptions.
>
>    Please note that the work you do may not be accepted into the project
> repos.  If your work is not accepted, Prominic will work with you and the
> project on next steps.  Your work may end up on the Moonshine-IDE site or
> other places.  Prominic cannot dictate production deadlines for an Apache
> project so If the 30 day and 60 day deadlines are not met, Prominic
> reserves the right to change the offer or its deadlines.  Prominic is not
> the only business entity involved with Royale and encourages other business
> entities to make similar offers to help Royale mature to be your solution
> for building applications for web/mobile/desktop.
>
>    IF within 30 days Apache Royale 1.0 is released to the public then the
>    Moonshine-IDE.com team will again donate $2,500 for the month of June
> in an
>    identical voting scenario (assuming this one works well) to bring home a
>    1.1 release.
>
>
>    By 60 days from now, a new user who has never seen Royale before or
>    programmed in ActionScript should be able to:
>    1) Arrive at the Apache Royale web page
>
>    2) Understand from the home page why they should care about the project
> if
>    they come from React, Vue, Angular, Flex, or ActionScript worlds
>
>    3) Be able to within 5 mouse clicks (download button, install button,
>    launch button, build button, run button) go from having nothing on their
>    machine to having an IDE (we of course volunteer Moonshine but Visual
>    Studio Code should be a goal for this, too) on their machine with a
>    successful build of their first "hello world".  No command line
> nonsense.
>    No learning NPM, Git, downloading 20 required packages.   See Royale
>    website.  Want to try it.  5 clicks later build your Hello World.
>
>    If the above 3 goals are met, then the Moonshine-IDE.com team will run a
>    3rd donation round of $2,500 for the month of July in a manner to the
>    description above to bring home a 1.2 release, to be published no later
>    than the end of July 2019 for the awards to be paid.
>
>
>    Hopefully this helps motivate the team.
>
>    Thank you,
>
>    Justin Hill
>
>
>

-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*

Re: [JOB] Moonshine-IDE.com is hiring contractors to bring Apache Royale to version 1.0

Posted by Alex Harui <ah...@adobe.com.INVALID>.

Hi,

It is a bit disappointing that there weren't offers, but I guess I'm not too surprised. I think there are a couple of factors here:

1) I still think people haven't realized that no big corporation like Adobe is driving Royale. With Adobe Flex, all you had to do is wait for the next release. I don't think people realize that with Apache Royale, we need folks to participate.
2) I think people are busy
3) I think we haven't made it clear enough how to make a difference if you have a spare hour or two. Where can folks go to get all of the things they need to make a 20 minute change to our docs if they only have an hour to spare? We might need to make it easier for folks to make small contributions. Any volunteers to help with that?

I'd help, but I'm overloaded right now with other tasks.

-Alex

On 5/3/19, 2:57 AM, "Olaf Krueger" <ma...@olafkrueger.net> wrote:

Hi,

for those who would like to help but think they do not have the needed
skills:
I think there are some tasks which could be achieved without any knowledge
of Royale.

E.g. the consolidation and beautification of the docs could be done without
any knowledge of Royale.

Just to mention it...

Thanks,
Olaf

--
Sent from: https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F&amp;data=02%7C01%7Caharui%40adobe.com%7C996a4ae6ae0846f15dff08d6cfadb21f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924742269897098&amp;sdata=5KblIQ728s91cmSHAoqxPBYhKPb3VH40o%2BKYU%2F9Wwuk%3D&amp;reserved=0