[JOB] Moonshine-IDE.com is hiring contractors to bring Apache Royale to version 1.0
Hi everyone, Unless I missed it, we got absolutely no bids by the original Friday May 3 deadline. I am disappointed, since I get the impression there are several of you on here who could make meaningful documentation impact with probably 5 hours of your time. Half of a Saturday or Sunday should be worth some $ and the knowledge of knowing you are helping bring Royale 1.0 into existence. Please, consider submitting a proposal even though the deadline is past. Please submit a proposal, which will make it worth your while professionally to dig in for a few hours. The community with thank you immensely, and you will get paid! I have posted the job to UpWork: https://www.upwork.com/ab/applicants/1124571121626791936/job-details Please spread the word again. Justin Hill === Subject: [JOB] Moonshine-IDE.com hiring contractors to bring Apache Royale to version 1.0 Royale helps modernize Flex applications AND provides a great way 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: http://apache-royale-development.20373.n8.nabble.com 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://www.adobe.com/devnet/flex/videotraining.html * 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
Re: [JOB] Moonshine-IDE.com is hiring contractors to bring Apache Royale to version 1.0
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" 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%2Fdata=02%7C01%7Caharui%40adobe.com%7C996a4ae6ae0846f15dff08d6cfadb21f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924742269897098sdata=5KblIQ728s91cmSHAoqxPBYhKPb3VH40o%2BKYU%2F9Wwuk%3Dreserved=0
Re: [JOB] Moonshine-IDE.com is hiring contractors to bring Apache Royale to version 1.0
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: http://apache-royale-development.20373.n8.nabble.com/
Re: [JOB] Moonshine-IDE.com is hiring contractors to bring Apache Royale to version 1.0
Hi Piotr, It’s an amazing offer and I’m sorry if there’s not much response. I am working on the doc section and spent some time on SO. I can’t meet the deadline though since my time is limited. You asked me to write an article on Royale vs React and I would like to do so but again need more time. So I hope you’ll get more response to your call. Succes Dany Verstuurd vanaf mijn iPhone > Op 3 mei 2019 om 11:46 heeft Carlos Rovira het > volgende geschreven: > > I tweet about it: > > https://twitter.com/ApacheRoyale/status/1124248372569944065 > > Hopefully we can get more people to know about this offer > > Share and retweet! :) > > > > > > El vie., 3 may. 2019 a las 9:33, Piotr Zarzycki () > escribió: > >> 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 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 - Issue 1978 Topics >> (m]dev-digest-help---04/29/2019 >>> 10:55:35 PM---dev Digest 30 Apr 2019 03:55:22 - Issue 1978 Topics >>> (messages 9973 through 9978) >>> >>> >>> - Message from Dany Dhondt 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.
Re: [JOB] Moonshine-IDE.com is hiring contractors to bring Apache Royale to version 1.0
I tweet about it: https://twitter.com/ApacheRoyale/status/1124248372569944065 Hopefully we can get more people to know about this offer Share and retweet! :) El vie., 3 may. 2019 a las 9:33, Piotr Zarzycki () escribió: > 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 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 - Issue 1978 Topics > (m]dev-digest-help---04/29/2019 > > 10:55:35 PM---dev Digest 30 Apr 2019 03:55:22 - Issue 1978 Topics > > (messages 9973 through 9978) > > > > > > - Message from Dany Dhondt 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
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 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 - Issue 1978 Topics > (m]dev-digest-help---04/29/2019 > 10:55:35 PM---dev Digest 30 Apr 2019 03:55:22 - Issue 1978 Topics > (messages 9973 through 9978) > > > - Message from Dany Dhondt 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?
[JOB] Moonshine-IDE.com is hiring contractors to bring Apache Royale to version 1.0
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 - Message from Dany Dhondt 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
