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
