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 <carlosrov...@apache.org> 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 (<piotrzarzyck...@gmail.com>) > 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 <jus...@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 <archeme...@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 <aha...@adobe.com.INVALID> on Tue, 30 Apr >>> 2019 02:16:30 +0000 ----- >>> >>> *To:* >>> >>> "dev@royale.apache.org" <dev@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&data=02%7C01%7Caharui%40adobe.com%7Cfc2244e2b6984cf86aa608d6ccc9c75a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921564340786626&sdata=gC1rfZiIcxvWM9NePG0GdsjNl6iFMkmKfbdrcn7vQK8%3D&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&data=02%7C01%7Caharui%40adobe.com%7Cfc2244e2b6984cf86aa608d6ccc9c75a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921564340786626&sdata=ehetZFgS6Tn9fR0PbFGjKh2yILbeKnKKhfV8ChhM9SA%3D&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>* >> > > > -- > Carlos Rovira > http://about.me/carlosrovira
