[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 d...@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 d...@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 be a goal for this,
Get paid to help bring Apache Royale to version to 1.0 -- submit your bid for assistance to the group by Friday May 3
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! If you are interested in getting paid to help bring Royale to market as 1.0 then: 1) join the d...@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 d...@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 what Alex and Carlos want to see happen to call it release 1.0. 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 Alex and Carlos specifically need to be convinced to push to 1.0 release 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. Carlos (or someone who knows Twitter enough to create another poll) will then do another Twitter vote poll for 3 days to decide who gets the bids Ideally multiple people will commit to doing something "small" for $500 each and we can award 5 people the projects. The $2,500 USD total will be paid via PayPal. No exceptions. 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
Re: [DISCUSS] Name of the FlexJS Fork
Hi everyone, I am not someone with an official vote, but I wanted to express my concern about ditching the FlexJS name. The largest possible market for adoption of a new "javascript" solution is to go after those who have stuck with Flex. There are FAR too many javascript solutions on the market right now. If the vote is to change the name, this will: -- confuse the people who have been patiently waiting for FlexJS to get to 1.0 so they can dive in. -- get lost in the noise of all of the other far more well popularized javascript frameworks like Angular, React, etc. -- lose the feeling, however small it may be, that those who came from the Flex background can expect to have some of their knowledge recycled. These are 3 critical aspects in terms of raising awareness and having a potentially devoted following of one technology (Flex) star to transition and champion to a new one (FlexJS). If we lose that, then we effectively have to target against ALL javascript frameworks, most notably ones that are heavily entrenched already and supported by giant company resources like Google and Facebook. I am strongly opposed to a name change. I think this would be a huge mistake. On top of that, picking a new name and gaining awareness of it is HARD. It should be reason enough for the Apache powers-that-be to approve a project change to avoid being stuck with a huge legacy Flex bugbase that Adobe donated, and instead start fresh with our 1.0 name. If that cannot be achieved, then at a bare minimum we should seek to keep the name FlexJS. Regarding targeting something other than Javascript -- like SWF or AIR -- I realize the debug aspect benefits are important, but all this is going to do is confuse people. I have read about HaXe a dozen times, and I never understand what it does because apparently it does too much. A swiss army knife is a lot more confusing to use then a fixed head screwdriver. Please, we have spent SO much time trying to get to 1.0 -- lets get FOCUSED on delivering what everyone outside of the community of active participants here has been waiting on, which is a future direction for their Flex efforts. Thank you, Justin Hill http://Prominic.NET | Skype: JustinProminic My Apache Flex community contribution is working on the open source Moonshine-IDE.com for FlexJS.
Re: FlexJS -- we really need to get bugs into JIRA
Hi Alex, I agree we need to be better about participating. I will keep pushing our team to do so. Thank you for taking the time to have this dialog with me. We appreciate your efforts very much on FlexJS and know you have a lot on your plate. I am going to make it one of our new goals as part of Moonshine IDE to make it very easy to get up-and-running as a FlexJS contributor from a setup perspective, after we get done with the type-ahead feature release. Justin Hill My Apache Flex community contribution is working on the open source Moonshine-IDE.com for FlexJS. From: Alex Harui To: "Justin M. Hill" , "dev@flex.apache.org" Cc: "Dhwani K. Shah" , "Joel C. Anderson" , "Kinjal J. Patel" , Pan Li , Santanu Karar , "Walker L. Dalton" Date: 11/04/2016 01:39 PM Subject:Re: FlexJS -- we really need to get bugs into JIRA Hi Justin, I'm not disagreeing about using JIRA more. But I'm not sure that mandating that JIRA be a complete replica of development activity is a good idea. But I'd like to hear from others. Maybe the rest of the community does want to mandate JIRA. To me, JIRA is a great "to-do" tracker, but we want to encourage discussion on the dev@ list and I would not want to be required to have to duplicate every discussion in JIRA. And just like others are asking questions on the dev@ list, I encourage your team to do so as well, and do so sooner than you might when working with those corporate-driven projects that purposefully keep you on the outside. I assume your developers discuss things over email and in person and don't have to interact entirely through JIRA. All I'm saying is that your team is welcome to do the same on dev@. Don't spend too much time trying to verify findings or find workarounds, just ask. Pan's problem wasn't in the compiler, it was in the ActionScript code. I think your folks are capable of at least debugging into the framework and pinpointing the issue. From there you can file a JIRA and just wait or try to find a workaround, or you can start a discussion on dev@ and if it turns out there is work that needs to be done, file a JIRA and propose a fix if you have one. And maybe learn from that discussion so you can more efficiently diagnose the next problem. You can't easily do that with the corporate-driven projects, but you can do that at Apache. And that gives you more control over what bugs get fixed and when. Because Apache projects are volunteer-driven, it is hard to put in place any sort of roadmap. I understand that creates some unpredictability, but I think that is best when working with volunteers. They can't commit to when and how much time they have to contribute so when they show up, those of us with more time have to constantly re-evaluate what we are doing and shift gears. It would have been bad for the community if I told Carlos that I'd committed to a particular list of tasks and couldn't help him get his Material Design library up and running. That library may prove to be more important than what I was working on at the time. So again, I encourage all of us to use JIRA more, but I also encourage your team to act more like part of our team. -Alex From: "Justin M. Hill" Date: Friday, November 4, 2016 at 10:13 AM To: Alex Harui , "dev@flex.apache.org" < dev@flex.apache.org> Cc: "Dhwani K. Shah" , "Joel C. Anderson" < j...@prominic.net>, "Kinjal J. Patel" , Pan Li < pa...@prominic.net>, Santanu Karar , "Walker L. Dalton" Subject: Re: FlexJS -- we really need to get bugs into JIRA Hi Alex, I understand what you are saying about Apache having a unique approach, but on the other hand countless software development projects have been improved by better tracking. When it is possible to associate a bug's fixes with changes in the source code, everyone following the project has clarity. This helps in the long run to improve the community's understanding of the code. Our team is doing everything we can to help, and our focus is on the IDE. This has certainly presented a lot of challenges and kept us busy. We have a massive list in our own JIRA of bugs and enhancements for Moonshine. So everyone here can see where things are going. I have encouraged the rest of the team here to contribute to FlexJS as well as we can, but aside from the TabComponent Dhwani and Kinjal worked on I am not sure we have the skill set to be modifying the compiler. I continue to think FlexJS would benefit from a central, organized repository with a written path of objectives beyond what is in the mailing list. I understand this is a time consuming item and takes away time from coding. I think there is great value in this time investment and will help others
Re: FlexJS -- we really need to get bugs into JIRA
Hi Alex, I understand what you are saying about Apache having a unique approach, but on the other hand countless software development projects have been improved by better tracking. When it is possible to associate a bug's fixes with changes in the source code, everyone following the project has clarity. This helps in the long run to improve the community's understanding of the code. Our team is doing everything we can to help, and our focus is on the IDE. This has certainly presented a lot of challenges and kept us busy. We have a massive list in our own JIRA of bugs and enhancements for Moonshine. So everyone here can see where things are going. I have encouraged the rest of the team here to contribute to FlexJS as well as we can, but aside from the TabComponent Dhwani and Kinjal worked on I am not sure we have the skill set to be modifying the compiler. I continue to think FlexJS would benefit from a central, organized repository with a written path of objectives beyond what is in the mailing list. I understand this is a time consuming item and takes away time from coding. I think there is great value in this time investment and will help others see what is being done over time and how they can help tackle issues. I hope we can shift as a community to the JIRA model of bug tracking for FlexJS. Thank you, Justin Hill My Apache Flex community contribution is working on the open source Moonshine-IDE.com for FlexJS. From: Alex Harui To: "Justin M. Hill" , "dev@flex.apache.org" Cc: Pan Li , "Dhwani K. Shah" , Santanu Karar , "Kinjal J. Patel" , "Walker L. Dalton" , "Joel C. Anderson" Date: 11/04/2016 11:51 AM Subject:Re: FlexJS -- we really need to get bugs into JIRA Hi Justin, I think we are using JIRA more these days, but IMO, it still isn't worth documenting every change in JIRA. Apache projects are supposed to feel more like potlucks than corporate efforts, and I don't want some volunteer with only an few minutes of time to decide not to contribute a null check because they have to fill out a JIRA issue before committing a change. so there is always a chance something will be missed in JIRA. Searching the dev@ and commits@ lists and trying the nightly build should probably become a standard practice before reporting a bug. Anybody can have a JIRA account, and yes, I encourage everyone to file bugs, but I know not everyone will. Also realize that your list of other frameworks are all corporate controlled which is why you felt compelled to list the corporation's name with the framework's name. The Apache model is different. At Apache, folks from all over the world can be committers and thus don't have to use JIRA in order to get something fixed, they can just do it. In fact, I would rather your team propose fixes instead of trying to workaround bugs in Flex or FlexJS code. Then they are more likely to earn committer rights and can just make a fix. IMO, that will be way more efficient than having to file JIRA issues and wait for someone else to fix it. If your team can think and act like they are part of our team, then I think we will make the most progress. The dev@ list is our common area. The other folks writing code for FlexJS often just ask on dev@ "Hey, I'm having a problem with this, is anybody else?" I'll bet Pan asked that internally to the rest of your team, but if Pan asked that right away on dev@ then we would all have saved time. It is a different way of thinking, but that's the cool thing about Apache. You can have more direct involvement than you can with other corporate-driven projects. -Alex From: "Justin M. Hill" Date: Friday, November 4, 2016 at 9:16 AM To: Alex Harui , "dev@flex.apache.org" < dev@flex.apache.org> Cc: Pan Li , "Dhwani K. Shah" , Santanu Karar , "Kinjal J. Patel" < kin...@prominic.net>, "Walker L. Dalton" , "Joel C. Anderson" Subject: FlexJS -- we really need to get bugs into JIRA Hi Alex, Everyone here at Prominic would like to see JIRA being used more for Flex development to track issues. We are very glad to hear that the nightly 0.8.0 build solved the issue Pan reported. This has apparently happened before -- where we have spent > 1 day determining something was a bug, and then another couple of days to re-write code to work around the bug. This time would have been better spent had we known the bug was already on a list and being worked out. As a community, we are up against a wide variety of frameworks. Known bugs should be in bug database. I am sure Google's AngularJS, Microsoft's Xamarin, Facebook's ReactJS or any other mature cross-platform UI SDK are tracking bugs, and FlexJS needs to be doing the same. The overall Apache Flex JIR
FlexJS -- we really need to get bugs into JIRA
Hi Alex, Everyone here at Prominic would like to see JIRA being used more for Flex development to track issues. We are very glad to hear that the nightly 0.8.0 build solved the issue Pan reported. This has apparently happened before -- where we have spent > 1 day determining something was a bug, and then another couple of days to re-write code to work around the bug. This time would have been better spent had we known the bug was already on a list and being worked out. As a community, we are up against a wide variety of frameworks. Known bugs should be in bug database. I am sure Google's AngularJS, Microsoft's Xamarin, Facebook's ReactJS or any other mature cross-platform UI SDK are tracking bugs, and FlexJS needs to be doing the same. The overall Apache Flex JIRA appears to be here: https://issues.apache.org/jira/browse/FLEX/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel and the FlexJS 0.8 specified project is here: https://issues.apache.org/jira/browse/FLEX/fixforversion/12338251/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel Are we not looking in the right spot, or is the community just not properly documenting bugs? Can Prominic staff get logins to JIRA to help report these? Thank you, Justin Hill My Apache Flex community contribution is working on the open source Moonshine-IDE.com for FlexJS. - Forwarded by Justin M. Hill/A5/PNI on 11/04/2016 12:05 AM - To: "dev@flex.apache.org" Date: 11/03/2016 11:33 PM Subject:Re: [FlexJS] Container.numElements is not working Thanks. Please try the nightly 0.8.0 build. It should be fixed already. -Alex > > >platform: Mac OS 10.4; FlexJS 0.7 > >numElements of the UI element Container doesn't work, it can be reproduced >by this code snippet: > > > > > > > > > > > >Run it in FlexJS0.7 in javascript or awf mode, it will show "1", but >expected value is 4. > >Similar code in Flex works as expected: > > width="75%" height="75%"> > > > > > > >I also noted the api list of FlexJS's Container is much shorter than >Flex's >Container, does this mean Container of FlexJS is not fully finished? > > >Thanks >Pan LI > > >My Apache Flex community contribution is working on the open source >Moonshine-IDE.com for FlexJS.
Re: Moonshine IDE 1.2.1 Windows release
Hi Andrew, We will look into this immediately. Can you directly send us a screen shot of what you saw? Thank you, Justin Hill My Apache Flex community contribution is working on the open source Moonshine-IDE.com for FlexJS. From: Andrew Wetmore To: dev@flex.apache.org Cc: "Justin M. Hill" , "Joel C. Anderson" , "Dhwani K. Shah" , "Kinjal J. Patel" , Santanu Karar Date: 10/05/2016 03:11 PM Subject:Re: Moonshine IDE 1.2.1 Windows release I downloaded this, and Avast! virus scan blocked it because of something called DRep. On Wed, Oct 5, 2016 at 5:07 PM, Walker L. Dalton wrote: Hey all, I just wanted to drop in and let everyone know that we here at Prominic have just deployed the 1.2.1 version of Moonshine for Windows. Try it out, run a FlexJS project! For those of you unfamiliar with the Moonshine IDE, visit www.moonshine-ide.com, where you can also find the source and executables for MacOS & Windows. Please let us know what you think, we would love to have some additional feedback from the Flex community. Thank you, Walker Dalton My Apache Flex community contribution is working on the open source Moonshine-IDE.com for FlexJS. -- Andrew Wetmore http://cottage14.blogspot.com/
Moonshine IDE for Flex, FlexJS, and ActionScript -- v1.2.0 released to the Apple App Store (free download)
Dear Apache Flex / FlexJS community -- I am pleased to report we have finally reached a balance between Apple's security requirements for the App Store and the needs of the Moonshine IDE to install the necessary SDKs and command-line tools such as ANT for automated project builds. As of v1.2.0, Moonshine IDE now also supports a basic method for generating a FlexJS interface from a Balsamiq mock-up. Our hope is this returns some of the features of the original Flex Builder Design view concept to help newcomers do basic layouts of their forms without having to write a single line of FlexJS to get started. Please download and provide your feedback on the mailing list or to us directly. We especially want to hear of anymore problems like Peter Ent's who was unable to build projects due to App Store sand box restrictions we think we now have all worked out for all recent MacOS releases. Note that we have not tested Sierra beta yet, so if anyone has that installed we would like your feedback. https://itunes.apple.com/us/app/moonshine/id1099109346?mt=12 Santanu is going to work on re-testing the Windows version next and post the latest version to the Moonshine-IDE.com website as well including sources. We really need help with code completion next. Walker, Alex, and I have a separate thread going on that topic in which Alex suggested Moonshine could use the same code completion hooks that Flash Builder uses from the Falcon compiler code base. Please chime in if you know anything about building AIR Native Extensions (ANEs) or the code completion engine hooks. Especially for newcomers, we must get code completion working in the IDE for it to be useful. I firmly believe for FlexJS to gain traction it needs an easy to use entry point (IDE) that is cross platform, downloads the necessary SDKs automatically, provides handy references to the API documentation, integrates Tour de Flex, and lays a groundwork for getting started quickly. We have accomplished many of these things and would appreciate assistance taking the IDE to the next level of usability based upon your frank feedback. Thank you, Justin Hill My Apache Flex community contribution is working on the open source Moonshine-IDE.com for FlexJS.
FlexJS - roadmap to 1.0 release
Hi Alex, On the topic of a roadmap to FlexJS 1.0 -- I agree about needing a real-world application to consider FlexJS 1.0 being a good point of reference, but I think we might be in a bit of a catch-22 situation. If we call it 1.0, more people will give it a try. Even internally at Prominic, people have at first been hesitant to think we could get anywhere with FlexJS because it is not "1.0" yet. So there is something psychological about that number to the world of software.On the one hand, we don't want to just randomly call it 1.0, but we need to figure out what minimum remaining features the group needs to get their own projects working on it as a 1.0 probably. After all, I suspect most people pouring resources into FlexJS are doing so as a means to breath life into their existing Flex software investments. So my question is: what does the rest of the group need to call it 1.0? At Prominic, Bootstrap integration and data binding have been two notable holdups. Prominic team, please speak up on what else we need. I suggest on the "FlexJS - roadmap to 1.0 release" thread we ask everyone who is active right now to submit on JIRA what their personal goal for a 1.0 release over the next 2 weeks. We need to get the group in the habit of using JIRA to stay organized so priorities don't get buried in these e-mail threads in my opinion. Some people like us don't have JIRA rights AFAIK so maybe we can also ask people to post JIRA addition requests in a specific way to the list so someone else who does have rights can post them. Like a subject of "JIRA addition for 1.0 target:" After the 2 week time-frame of submissions, the group can then choose a method to organize the JIRA tickets into those that actually the group decides should be 1.0 vs. those that could wait until 1.1 release. Regarding the competitive analysis of FlexJS to tools like Xamarin, Prominic can try to write something, but we really could use feedback (off-list is fine if it is against policy) from others more knowledgeable than us. I really think this is important so new people can have the information handed to them about why this is useful. Thank you, Justin Hill My Apache Flex community contribution is working on the open source Moonshine-IDE.com for FlexJS. - Message from Alex Harui on Wed, 7 Sep 2016 05:13:39 + - To: "dev@flex.apache.org" cc: Santanu Karar , "Dhwani K. Shah" , "Kinjal J. Patel" , "Atin K. Gupta" , Pan Li , Bing Li , "Walker L. Dalton" , "Efrain Salomon" , "Joel C. Anderson" Subject: Re: FlexJS - roadmap to 1.0 release Hi Justin, Just today I was thinking of finally getting around to trying Moonshine on my Windows computer. More below... On 9/6/16, 9:42 PM, "Justin M. Hill" wrote: > >Hi Alex and FlexJS community, > >Given that 0.70 of FlexJS is nearing release, I would like to revive a >request I made in April for a roadmap of what is left before we can call >it >1.0. For me, I would like at least one public testimonial that someone was able to use FlexJS and put an app into production. We have example apps, but I want to know if FlexJS can do something a bit more complex. Other folks may have different opinions and I could easily change my mind if folks want to call the release after 0.7.0 our 1.0 release. > >It would be really helpful to our cause if we can articulate the major >bullet points for why someone interested in cross platform development >should go with FlexJS / AIR vs. Xamarin. I think it is important for us >as >a community to clearly state the benefits beyond just not being a solution >backed by Microsoft and subject to their whims. I haven't used Xamarin, plus I think as a member of Apache I'm not supposed to do opinion-based competitive analysis. It is fine to state hard facts though, but in many ways your choice of tools is subjective. Mostly, I think we need folks who have been successful to articulate the advantages. >Finally, we really need help getting code completion put into Moonshine. >I'd appreciate hearing from anyone who is skilled in building Abstract >Syntax Trees and parsing them in real time who could contribute this. Moonshine is an AIR app, correct? Porting Falcon's AST code to ActionScript would be a serious project. I'm wondering if there is some way to leverage Falcon, possibly as an ANE, or via some other cross-process communication. Falcon is already set up to be a code-completion engine for Flash Builder. Thoughts? -Alex
Moonshine IDE code completion using Falcon engine
Hi Alex, You are correct, Moonshine IDE is an AIR application. If we could make use of the Falcon engine for code completion, that would be great! Could you point Santanu in the right direction for at least where the hooks might be for that so he can investigate further? I think you should wait to try Moonshine until we release the newest version in (hopefully) a couple of more days. We have changed a lot and integrated the installation process of the ANT, Flex, and FlexJS SDKs so that new users can get going more quickly. Thank you, Justin Hill My Apache Flex community contribution is working on the open source Moonshine-IDE.com for FlexJS. - Message from Alex Harui on Wed, 7 Sep 2016 05:13:39 + - To: "dev@flex.apache.org" cc: Santanu Karar , "Dhwani K. Shah" , "Kinjal J. Patel" , "Atin K. Gupta" , Pan Li , Bing Li , "Walker L. Dalton" , "Efrain Salomon" , "Joel C. Anderson" Subject: Re: FlexJS - roadmap to 1.0 release Hi Justin, Just today I was thinking of finally getting around to trying Moonshine on my Windows computer. More below... On 9/6/16, 9:42 PM, "Justin M. Hill" wrote: > >Hi Alex and FlexJS community, > >Given that 0.70 of FlexJS is nearing release, I would like to revive a >request I made in April for a roadmap of what is left before we can call >it >1.0. For me, I would like at least one public testimonial that someone was able to use FlexJS and put an app into production. We have example apps, but I want to know if FlexJS can do something a bit more complex. Other folks may have different opinions and I could easily change my mind if folks want to call the release after 0.7.0 our 1.0 release. > >It would be really helpful to our cause if we can articulate the major >bullet points for why someone interested in cross platform development >should go with FlexJS / AIR vs. Xamarin. I think it is important for us >as >a community to clearly state the benefits beyond just not being a solution >backed by Microsoft and subject to their whims. I haven't used Xamarin, plus I think as a member of Apache I'm not supposed to do opinion-based competitive analysis. It is fine to state hard facts though, but in many ways your choice of tools is subjective. Mostly, I think we need folks who have been successful to articulate the advantages. >Finally, we really need help getting code completion put into Moonshine. >I'd appreciate hearing from anyone who is skilled in building Abstract >Syntax Trees and parsing them in real time who could contribute this. Moonshine is an AIR app, correct? Porting Falcon's AST code to ActionScript would be a serious project. I'm wondering if there is some way to leverage Falcon, possibly as an ANE, or via some other cross-process communication. Falcon is already set up to be a code-completion engine for Flash Builder. Thoughts? -Alex
FlexJS - roadmap to 1.0 release
Hi Alex and FlexJS community, I have been following this thread: Re: Will we have a new release out the door till 8th of September? I wanted to provide a brief update: We have been working hard on getting a new version of the Moonshine IDE ready and released through the Apple App Store. We ran into an incredible series of delays and problems with restrictions placed upon the App Store release, so we had to add a 'helper' application to (hopefully) get around the problems Peter Ent reported months ago on recent Mac OS X releases including El Capitan. Now that we are done with it, we hope this approach will get approved by Apple. Even without the App Store release, we will post the direct download version on the site in the next few days, and Santanu will make a post here announcing it. Given that 0.70 of FlexJS is nearing release, I would like to revive a request I made in April for a roadmap of what is left before we can call it 1.0. I think this is important to gather widespread attention. It also needs to be paired with an easy on-boarding experience for new users and a functional set of demo applications and learning tools. You may notice we integrated Tour de Flex with the Moonshine IDE for this reason, and we also intend to add in the FlexJS docs soon. It would be really helpful to our cause if we can articulate the major bullet points for why someone interested in cross platform development should go with FlexJS / AIR vs. Xamarin. I think it is important for us as a community to clearly state the benefits beyond just not being a solution backed by Microsoft and subject to their whims. I have also asked Dhwani and Kinjal to make sure they contribute back the Tabbed component to FlexJS that they recently got working. And we have built in a new feature to turn Balsamiq mockups into FlexJS applications that we are working on polishing. Finally, we really need help getting code completion put into Moonshine. I'd appreciate hearing from anyone who is skilled in building Abstract Syntax Trees and parsing them in real time who could contribute this. Thank you, Justin Hill My Apache Flex community contribution is working on the open source Moonshine-IDE.com for FlexJS. - Message from "Justin M. Hill" on Fri, 1 Apr 2016 02:52:26 -0500 - To: dev@flex.apache.org Subject: FlexJS - roadmap to 1.0 release with code bounties and conversion analyzer Hi Alex, Would it be possible to start making more extensive use of JIRA on FlexJS? There appears to be a very basic list of issues outstanding for FlexJS 1.0 Release Candidate. I'm sure there is a lot more on a roadmap somewhere... and it would be nice to have it articulated in JIRA. https://issues.apache.org/jira/browse/FLEX/fixforversion/12324435/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel I reviewed your PowerPoint presentation draft for the FlexJS meeting on Monday. Slides 30 through and 36 detail "how much can you reuse" and has information on scanning for "imports flash.*" and "embed". I think we should write an analyzer to help estimate code conversion for existing Flash / Flex Builder projects and add that to Moonshine IDE. We could then present an estimate of the amount of code that will "just work" on a FlexJS build from the project. If you can correlate the skill set necessary to tackle each of the major issues, I think FlexJS is at a point where we could start to recruit individuals or companies to assist with the remaining issues to reach 1.0 level so their Flex apps will be ported to JavaScript/HTML. Surely there are enough corporations out there with an investment in Flex application modernization needs that financially it would make sense to sponsor a portion of the remaining development work on FlexJS 1.0 so that their application port to no longer be dependent upon the Flash player will be accelerated. Thank you, Justin Hill My Apache Flex community contribution is working on the open source Moonshine-IDE.com for FlexJS.
Moonshine-IDE.com -- FlexJS, Flex, and ActionScript focused open source IDE -- contribution to Apache FlexJS
Hello Apache FlexJS Team, I am pleased to report progress on the open source Moonshine IDE for Flex, FlexJS, and ActionScript that Dhwani discussed at the FlexJS World Tour in early April in San Francisco. We have now released it through the Apple Mac App Store: https://itunes.apple.com/us/app/moonshine/id1099109346?mt=12 There is still a lot we want to add -- and we could really use some help from some of the more brilliant developers on the list. The debugger, auto-completion, and other aspects need attention which may be beyond the scope of our skill set to develop in a reasonable time frame. If anyone is interested in helping us in these areas, I would greatly appreciate hearing from you. Please reach me on Skype or Twitter at JustinProminic so I don't miss any replies on the list. For those of you with limited time, if you could take a quick download of the app and maybe write a fair but reasonably positive review on the App Store that would be appreciated. Again, we know it is not perfect and it needs work, and our goal is to make the FlexJS ecosystem very easy for someone to get started with. So example programs, tutorials, etc. are high on our list of inclusion along with build scripts to quickly get a new developer releasing their first HTML/Javascript, Windows, Mac, iOS, and Android build including App Store ready builds without having to dig through lots of information like the rest of us have had to do over the years. Thank you, Justin Hill My Apache Flex community contribution is working on the open source Moonshine-IDE.com for FlexJS.
FlexJS - roadmap to 1.0 release with code bounties and conversion analyzer
Hi Alex, Would it be possible to start making more extensive use of JIRA on FlexJS? There appears to be a very basic list of issues outstanding for FlexJS 1.0 Release Candidate. I'm sure there is a lot more on a roadmap somewhere... and it would be nice to have it articulated in JIRA. https://issues.apache.org/jira/browse/FLEX/fixforversion/12324435/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel I reviewed your PowerPoint presentation draft for the FlexJS meeting on Monday. Slides 30 through and 36 detail "how much can you reuse" and has information on scanning for "imports flash.*" and "embed". I think we should write an analyzer to help estimate code conversion for existing Flash / Flex Builder projects and add that to Moonshine IDE. We could then present an estimate of the amount of code that will "just work" on a FlexJS build from the project. If you can correlate the skill set necessary to tackle each of the major issues, I think FlexJS is at a point where we could start to recruit individuals or companies to assist with the remaining issues to reach 1.0 level so their Flex apps will be ported to JavaScript/HTML. Surely there are enough corporations out there with an investment in Flex application modernization needs that financially it would make sense to sponsor a portion of the remaining development work on FlexJS 1.0 so that their application port to no longer be dependent upon the Flash player will be accelerated. Thank you, Justin Hill My Apache Flex community contribution is working on the open source Moonshine-IDE.com for FlexJS.
Moonshine-IDE.com -- FlexJS, Flex, and ActionScript focused open source IDE -- contribution to Apache FlexJS ?
Hi Alex, Om, Justin, and the rest of the FlexJS team and contributors. I am looking forward to seeing you on Monday at the FlexJS event. Dhwani will also be attending the meeting. Unfortunately, Santanu, Kinjal, Joel, Bing, and Atin will not be able to attend. However, they are hard at work testing FlexJS. I have stayed behind the scenes mostly since we last met at the 360Flex event in San Jose. For the past several months, our team has been doing what we can to help promote the FlexJS ecosystem in the form of efforts on the Moonshine-IDE.com project. This is an IDE written in ActionScript that runs on Mac, Windows, and also in the browser (via the Flash plugin). Our vision is that Flex needs its own IDE so that the entire user experience of working with the tooling can be controlled and refined. There are too many steps right now to download FlexJS, figure out build scripts, understand how to properly sign and deploy applications for Windows, Mac, iOS, and Android, learn the language, etc I am not saying FlashDevelop, FDT, Flash Builder Professional, or IntelliJ are not still needed. They certainly have a place for multi-language development and we do not intend to try to replicate all or even most of their features. In fact, for a while we were supporting the FlashDevelop enhancements to bring it to Mac and Linux via CrossOver/WINE. However, we could not agree with the project lead on the direction of streamlining the IDE for use in Flex and making the user on-boarding experience easier. At that point, we started searching and stumbled upon Moonshine IDE. In my opinion, the major IDEs mentioned above are overwhelming. There are so many different things vying for the developer's attention in them that getting to the point of seeing Flex or FlexJS in action takes too much effort. I think it is a mistake right now to assume the people downloading the Flex / FlexJS SDKs are all going well. Having a focused IDE with some excellent getting started material could change that landscape. Showing people they can hit the ground running and make things happen that matter and are production grade (especially for traditional Flex) could help attract new users. Making these arguments before we had anything useful to show would have been a distraction. Alex and the rest of you have enough on your plate making the core system function. However, I also want to make it clear that while we are not necessarily in a position to impact the core compiler, I think we can add value with this IDE initiative. This will have the most impact if we had your blessing and direction. Therefore, I would like to explore whether you are interested in having the Moonshine IDE under the control of the Apache FlexJS project. Having said this, I am not sure it meets the code clearance requirements right now because it is NOT all our code. In fact, most of it is not our code. I want to be clear that we found Moonshine on the web a while ago. It was written mostly by Erik Pettersson of Stockholm, Sweden. We did not write it from scratch. Rather, we began refining what we found that Erik had published at the link below. At boot up, it currently lists: : Moonshine IDE 1.0.0 : Source is under Apache License, Version 2.0 : Originally found at http://code.google.com/p/moonshineproject/ : Uses as3abc (LGPL), as3swf (MIT), fzip (ZLIB), asblocks (Apache 2), NativeApplicationUpdater (LGPL) I did receive permission to use the photo by Cristian as the background image in the open source project. There are some things missing that I would have liked to be in place before the meeting: * Home screen is not polished to guide the user to the correct targets (iOS, Android, etc). The current rendering is pretty ugly. * Necessary resources for compilation are not being properly checked with an easy to use download link. * Tour de Flex integration is not as prevalent as I would like so far. * Example applications are too basic and should do more. * Integrated Flex API reference should be present. * The icon is not sleek enough in the Mac Dock -- it is still the original one. I'd prefer one that looks like a brightly lit moon (for any graphic artists on the list...) * Signed installers so that users on Mac in particular are not presented with warnings. If possible a release on the Mac App Store. I read today that Microsoft at their Build conference announced a tool which is making it easier to convert traditional Win32 apps into their Windows App Store equivalent so that might be another distribution option. The above are all solvable by us. We also have a number of other issues in our internal JIRA to polish that we will keep working on even if you decide to accept it into the core Apache FlexJS. Harder issues we likely need help from someone in the community familiar with Abstract Syntax Tree parsing to implement are: * Type-ahead support * Cross-reference of code definitions * In the future, maybe a profile
Public campaign to improve FlashDevelop specificall for Apache Flex
Apache Flex Team, I attended the Flex 360 conference with many of you earlier this year in San Jose. While I do not follow the list daily, I know you are all working very hard and we appreciate it very much. One of the most important things Apache Flex needs to succeed is a 100% free, easy to use, cross platform IDE which runs on Mac, Linux, and Windows. Obviously Flash Builder, FDT, and IntelliJ are all options already. When I started to evaluate the next investment we would make in IDE tooling post-Adobe, I came across this comparison: http://www.simtechmedia.com/blog/2010/10/ide-showdown-intellij-fdt-flashdevelop-2/ This in turn got me interested in FlashDevelop. Even though it was Windows-only, I decided to work with my contacts at https://www.codeweavers.com (a commercial support company for WINE) to get it working under our standard development platform: Mac. In a relatively short period of time, I was able to get FlashDevelop to work on Mac. I then made a nominal donation to Mika (one of the FlashDevelop project leads) to alert him to this breakthrough and encourage him to spend time testing on Mac. He also found it to be mostly a success. Mika then went on to create a CrossTie installer which makes it easier for other users to install FlashDevelop on Mac and Linux using CrossOver. [Side note for Mac and Linux users: I realize CrossOver is commercial and if it is a dependency for FlashDevelop on Mac and Linux, it is not totally free on those platforms. I am not concerned with that and hope the topic does not steer in that direction.] I then asked Santanu, Walker, and Joel to review Flash Builder compared to FlashDevelop on Mac to determine what else needs to make FlashDevelop an acceptable replacement for Flash Builder.Santanu produced a PDF which I will ask him to reply to this message in text form with the contents of the PDF in a text readable fashion so that it is readable on the mailing list. I asked Mika to commit to a full test of all FlashDevelop features on Mac, including Flash player debugging, compiling, Apache Flex installer testing, etc. He then put me in contact with Hector who he indicated may have more time and had already started a campaign to raise funds to enable him to dedicated more time to improve FlashDevelop for Flex: https://www.linkedin.com/groupItem?view=&gid=4296888&type=member&item=5905327257437630464&commentID=5920018570217009152&report%2Esuccess=8ULbKyXO6NDvmoK7o030UNOYGZKrvdhBhypZ_w8EpQrrQI-BBjkmxwkEOwBjLE28YyDIxcyEO7_TA_giuRN#commentID_5920018570217009152 https://www.indiegogo.com/projects/flashdevelop-improved-flex-support There is at least one other commercial entity set to help Hector meet his fundraising goals. Between the other company and Prominic, along with anyone else who can help, we can and will make FlashDevelop better for Flex. We need to see it better specifically on Mac as well, and I would like to ask other Mac users out there in the Flex world to participate now in defining exactly what goals we need Hector to achieve. Please categorize these into at least two different areas. A) Making FlashDevelop great for Apache Flex B) Making FlashDevelop great for Apache Flex under Mac and Linux using CrossOver. I envision FlashDevelop having an integrated Apache Flex installation process that works without the confusion of the current one which offers too many different downloads. I would like to see a launch page that makes it very easy to get started with your first Flex project. Similarly, a start page might also be appropriate for those interested in FeathersUI or pure Flash work. Right now everything is assumed that the user will know how to create a project for their preferred target, and that is not as intuitive as it should be. I would also like to see better import support for Flash Builder projects, and thorough testing of the integrated Flash Player with debug mode enabled under CrossOver, or possibly integrated with running the Mac version of the debug player. Santanu, please reply with your specific list of requests. Hector, please integrate Santanu's request into your master list and reply back as well. I welcome anyone else who can provide concrete direction for the goal list. The last revision I had from Hector on September 17, 2014 is as follows: 1. package: Code Completion and MXML 1. Code completion bugfixes: there are some bugs in code completion. ie.: sometimes it forgets the inherited properties until I open the base class. 2. Replace file bugfixes: there are extreme bugs when I try to replace a file or a folder, and FD updates the namespaces. Sometimes it deletes codes and replaces wrong texts. It’s very dangerous, but it would be very useful. 3. Custom mxml component code completion support in AS files: FD should support not only native, but custom MXML components. It partly have code completion when we use an mxml class in AS files, bu
