Teoti Graphix, LLC

Saturday on the mailing list mainly consisted of logo entries. I’m sure a lot of members are just waiting for the source code to arrive and figuring out what the next steps are to Apache Flex’s first release.

Logo Contest

The logo contest will be ending on Tuesday January 17th, so you still have a couple days to get those final entries in!

Something brought up was whether an author/designer can submit multiple logos. Originally I replied that the author should combine them on one link but, then I realized they were not talking about design “variations” but separate logo ideas.

So the answer is Yes, a designer can submit multiple logos by sending an email to flex-dev@apache.org and appending a number after the authors name like [LOGO] My Name #1, [LOGO] My Name #2 etc.

http://incubator.apache.org/flex/logo-contest.html

JIRA

The JIRA instance is up and running but I don’t think we are able to use it yet due to the fact that Alex hasn’t got the issues migrated from the Adobe JIRA. This is a great step in the forward direction though!

https://issues.apache.org/jira/browse/flex

Conclusion

As usual Saturdays go, mainly silence and rest (for some). Stayed tuned for this weeks action, we should be getting into the mechanics of issues and source code commits and fixing some bugs.

Thanks for reading,
Mike

Hi,

The Flex-Dev summaries continues. I always like doing things I thought I couldn’t do. I’m going on 10 blogs posts in a row, I have never done that before.

It’s interesting how an idea like the flex-dev summaries starts out as something and then turns into something else. I have been amazed at how many off blog conversations I have had where developers and community members have voiced their appreciation with what I am doing here as far as just trying to get information out.

The main goal of these summaries is to educate myself. I like the term “practice makes better“. Each time I write something or think about it, I am giving myself the opportunity to think about the issue in a new light.

I have also noticed through Google Analytics that the apacheflex category is being linked to and read 100′s of times. In the beginning I really didn’t think to much about the impact of that category. Until the day I actually clicked on what others are seeing. Wow, that is a rough chronology of the beginning of the Apache Flex mailing list!

For users that come to this project 6 months or a year down the line and have the ability to read a chronological summary like that, the thought gives me the motivation to keep doing it everyday for a while. Even on slow days or weekends.

After the Storm

I know this was a Friday but there was something very nice about the fact silence occurred after a huge day of voting and opinion madness. It does show that the community that is involved thus far really does have the capacity to sit back and digest conversations and disagreements without having to start the same mess again the next day. Right on!

Flex SDK Source Code

Alex has announced that the source code has passed legal! He said it should be around Monday and that Adobe will give Apache a huge dump file to dump into the folders to maintain the svn history.

This is great news for the projects momentum and I think perfect timing for the project as a whole.

Community members start your engines, if you thought the mailing list was on fire this week, wait until next week.

JIRA

Alex also stated the they are working on the JIRA migration and it will be a huge pain because of potential username conflicts. There are going to be some “gotchas” that he brought up;

- considering changing the authors of all current issues to something like “AdobeFlexSDK”
- create a field to store the original Adobe issue number
- take all current comments and concatenate them into one long comment submitted by AdobeFlexSDK
- Adobe Flex JIRA issues have lots of custom fields that I expect Apache Flex JIRA won’t have

Flex-Users Mailing list

Doug Arthur started a new thread about the flex-users mailing list (Note: in my last blog post I called this flex-user which was a mistake on my part). Seems like now that the dust cleared there may have been confusion between two threads that were being talked about when opposition was being made.

This is a very good example of Doug waiting a day and asking the question in a very detailed way to get the feedback he needs.

It looks like there are enough mediator volunteers to get the list off the ground and so far the thread has not had any real opposition to creating it now.

Flex SDK Binary Release location

The question was asked since the svn repository only stores the source code, where are the release built SWC and libraries going to be stored.

http://apache.org/dist/

Falcon compiler and MXML

A couple updates from Adobe’s Gordon Smith about the Falcon compiler.

- has a lot of support already for .mxml, .css, and .properties files as well as .as files
- compiles the MXML directly to bytecode and does not produce intermediate AS.
- it is not yet alpha quality and you wouldn’t want to use it in any projects

MadComponents

Daniel Freeman pointed out in a blog comment yesterday;

Many developers are already united around a new light-weight component set, built with touch interaction and mobile devices in mind. MadComponents

I did check this set out a while back and looked interesting. He uses XML for layout and I see a lot of Android similarities to his framework.

If you’re interested in a new take on AS only mobile component framework, go check it out!

Source Code: http://code.google.com/p/mad-components/

MadSkool Blog: http://madskool.wordpress.com/

This is what makes the ActionScript language so great, the ability to create frameworks.

Conclusion

Not much of a conclusion today, just waiting for next week when the real action happens, source code committed, JIRA up and running and the Apache Flex logo voted on.

Thanks for reading,
Mike

The Thursday edition of flex-dev@apache.org consisted of voting debacles, best practice debates and whether or not to create a flex-user mailing list.

On the plus side, an Apache Flex blog has been created and we have more logo entries for the community to check out.

Voting the Apache Way

Voting was a central force in the thread titles, I was to blame for one of them but, only going off of what our mentor Bertrand was suggesting. He suggested we needed to find out the protocol for voting on the new Apache Flex logo. I’m not going into detail on this subject since my head is completely fried in writing the words “logo contest“. For more information on this discussion, the thread shouldn’t be hard to miss.

Best Practices

This is another thread that went off the charts for number of threads posted. It has to do with whether Apache Flex should in a way dictate “how” developers should organize/pattern there development.

The consensus is, any community member is free to write drafts and propositions on what and how they think code and frameworks should be standardized. Just because you write something, doesn’t mean that the community is going to follow it. More than once the old cliche’ of “one size doesn’t fit all” was used. Using that as the back drop I’m sure you can infer what the issue is all about.

Flex-User Mailing list

This debate has been going on for a couple days and it doesn’t seem to be close to getting resolved. Pretty close to a split in my opinion. The two polar sides consist primarily in;

- Apache Flex does not have a release and doesn’t require a mailing list at this time, there are plenty of resources available for Adobe Flex right now.
- What actually defines what is discussed on a flex-user list, is it a standard community help channel.
- If the flex-user list is created now and we direct community members that may have off topic questions for the flex-dev list, it will help define the flex-user list

I think the main problem some members have against it right now is they don’t want the community to think there is actually something to support right now. From reading the threads, it doesn’t sound like most members are against it, they are against creating it before a first release.

Whatever the case may be, this is surely a candidate for something that needs a decision to stop the huge flows of email where a conclusion can definitely be reached.

Apache Flex Blog

It was requested last week and it’s here, the official Apache Flex blog with entries from the PPMC members.

The way it’s set up for now is a member can post a blog post on the mailing list and have it accepted(edited) by other members. Once it’s accepted, the blog post will be published on the blog.

Peter Elst will have the first blog post that might arrive later today. You can book mark that here;

http://blogs.apache.org/flex/

Logo Contest

The logo contest has about 12 entries after I update the site, so go on over and check out what the community is coming up with designing to new Apache Flex!

http://incubator.apache.org/flex/logo-contest.html

HaXe and compilers

There is another discussion talking about HaXe and “what if” scenarios. Not going into much detail here as we don’t even have the source code of the Falcon compiler to compare it to anything.

Pre-processors have been brought up and how they would affect compile performance. Basically, members are discussing the possibility of “Extending” the language through pre processing code for method overloading etc. As mentioned any of this talk is purely theoretical because we are talking about a compiler that doesn’t exist yet.

Conclusion

It’s hard to write summaries about things that go on for ever and have no closure. I’m sure most would agree that this is the way things are when you bring together a huge assortment of different brains from all over the world.

I would say that all in all, the first two weeks of Apache Flex have been very positive and rewarding for the community. I know we are still waiting for the code but, it’s nice these other little hiccups are getting attention from the start instead of happening with mission critical decisions such as releases.

Thanks for reading,
Mike

Yesterday was kind of a slow day in that there wasn’t much new topics. Having seen this list from the start and I can say I have read every message in the till, people are getting anxious and impatient(in a good way).

The messages of “can we focus on this instead of that and not talk about this until a release” are getting boring to me.

It’s funny how life changes though, by next Friday the energy will be the exact opposite of yesterday and there won’t be any time to be bored.

Logo contest

The logo contest now has 7 entries and 2 more I need to add this morning. The great thing about this is the community is listening and wanting to contribute. This should say something for when Apache Flex get’s it’s code and the community starts submitting patches and documentation!

Again, go check them out and get inspired, maybe you will be the one that everybody looks at as the contributor that gave Apache Flex it’s identity!

http://incubator.apache.org/flex/logo-contest.html

Coding Best Practices

There has been quite a long discussion about Application coding practices and the MVC microframeworks have been brought up as well. As some of you may know that read these summaries, I brought up Coding Conventions last week and on the list. Coding conventions don’t have to be strict, they are there so developers are looking at the same style of code to promote speed in development. What is being talked about right now is dictating Coding Standards in relation to application/component patterns.

Alex points out nicely that we are in a constrained environment and sometimes we need to cheat. An example given is having everything replaceable and using separation of concerns is fine in theory. But if that code creates a performance issue in the Flash Player, a developer should then cheat the standard a bit to get optimum performance over having a composable object just because the standard says use composition always.

I think we are getting application development mixed with framework development and they are two very different animals.

Mailing lists and Resources oh MY!

This is the one subject that is getting beat to death. To be or not to be, that is the question.

Actually the real question is does the flex-dev mailing list want the flex-user mailing list split right now. From the sounds of it, it might actually happen.

People, I think we all need to understand that the flex-dev mailing list is about the framework, pushing it forward, submitting patches and discussing commits. All channels available for the actual application development of Flex are still around and relevant.

Conclusion

Well, it was definitely a hump day on the list, one of practical concerns and repetition. Add me to the list of impatient developers that want JIRA up and the SDK committed.

Mike

Hi,

Well this was one of those days where you get the calm before the storm and then the storm. Yesterday was the storm of replies and misguided replies to irrelevant subject lines. Basically chaos on a mailing list.

This was the first day where some conversations took a personal tone. I must admit I have come a long way in my life realizing there is a difference between passion and poison on a mailing list. The later being completely disruptive and destructive to a mailing list.

The passion wouldn’t be as bad on the flex-dev list if members would create a new Subject Line.

Having read every single post yesterday of the 300 or so, I would say you will only get half of the topics discussed by looking at the mail archive subject lines. Which means most of what people were going back and forth on are buried in the sands of time. I can guarantee 75% of people are not going to read every thread in a 50 thread long conversation unless they are really bored. Not to mention the subject line only pertains to the first 15 threads out of 50.

So this begs a question; When we contribute to a 25-40 long list of threads (of the same subject line when the subject has completely changed), are we really doing it for our personal reasons or for the benefit of the community that comes after us looking through the archives?

Moral of the delema, when you sense a new storm brewing, slice and dice, make a new Subject line and don’t reply, create a new thread so it gets set back on the root.

Logo contest

The logo contest is in full swing and so far there are 5 entries on the first day.

http://incubator.apache.org/flex/logo-contest.html

IRC Channel (Apache Flex Resources)

I love this type of stuff because I think pointing out my own faults creates stronger understanding with myself. I have been quite busy committing the web site, logo contest, reading mails, responding and actually developing a little bit at the same time.

A patch was submitted on the list to add the IRC channel to the Community links on the website along with a small page describing it. Well, I automatically committed his update (which is not just a 1 – 2 step).

Pretty interesting to see how fast people respond! Basically I was using the Apache Way, lazy consensus in that I didn’t hear people say NO, so I committed. Well I am proud to say that I own the prize of the first REVERT in svn for the project.

Through my action I pulled out of the PPMC members that they don’t want the IRC attached to Apache Flex in an “official” way. Alex also noted that we don’t even have a release so there is really nothing to support yet attached to the Apache Flex name.

Resources

So the above thread then lead it’s way into where do people go for Apache Flex support?

Can I remind the community that source code is not committed and we haven’t released anything.

So the answer is the same places you have always gone, Adobe forums, Stackoverflow, Flex coders etc. Remember that you are still using Adobe Flex, not Apache Flex.

BlazeDS

The question of BlazeDS is getting some support to be brought into the Apache Flex project. Why? If there are not enough initial committers or community involvement in it’s own project, BlazeDS could just rot on the vine and die.

It’s also been pointed out that there are enterprises that still use it and some of those might be interested in contributing as well.

Spark components

The question of Spark performance came up and was answered with the fact that the Spark skinning model creates 2 DisplayObjects per component. Alex also pointed out in his opinion Adobe could have retrofitted a new skinning model in all mx components in less time.

You may be wondering about how the above fits into anything. The subject of Flash Catalyst and it’s coupling to the direction and design of the Spark framework was discussed. Unfortunately it looks like the failure of Flash Catalyst is the main reason there is still not a polarity between mx and spark component sets.

Alex also pointed out that there were other driving forces such as;

declarative graphic primitives, MXML-only skins, and tooling integration

This then begs the question of what we are to do as Apache Flex can now steer it’s own boat. Do we retro fit mx components with skinning, do we try and slice out the fat caused by FC in the Spark framework, do we settle our losses and realize there needs to be a new component model built from the ground up taking into the concerns of mobile, performance, granularity, composition, cross compiling etc.

It’s up to the community but since Apache Flex IS components, this will determine what traction Apache Flex has in the future and it’s ability to compete with existing technologies on the level of agility.

Two final notes on Spark performance as Alex put it;

Spark was living on top of UIComponent. It is hard to run fast when you put on heavy shoes.

The basic idea is that our design goals have changed significantly since Flex 3, and we should design a framework for those new goals and sacrifice some backward compatibility. Trying to carry all of our legacy forward is probably not going to make it successful.

Flex SDK commit

The question was asked again about when the source code would be committed and Alex said they are having a harder time getting it through legal so expect around the end of the week. Which was about my guesstimate last week.

Also note that it still could be next week, it’s not how fast Alex and Carol can get it done, it’s how many hoops do they have to jump through to get it done.

Conclusion

What you are seeing happening here is a bunch of elementary kids getting loud and anxious to get their little boots on the field trip bus. I mean this in the most sincere way folks, since there is no source code and JIRA yet, the group is having time to explore some of the more abstract ideas before the reality comes down and we wake up from the initial dream.

Mike

Logo Contest

The Apache Flex logo contest has begun! The contest will end on 01-17-2012.

On the 31th of December, 2011, the Apache Software Foundation has accepted the Flex SDK into incubation. Apache Flex is now a community project managed by Apache (ASF). The migration from Adobe to Apache involves a re-branding and you can contribute by proposing the new Apache Flex logo.

See the logo contest’s rules and details http://incubator.apache.org/flex/logo-contest.html

You can use the Twitter hashtags of #flexlogo or #ApacheFlex directed at @ApacheFlex as well pointing to your logo url and assets.

Whiteboard

The Apache Flex’s whiteboard area;

The whiteboard is for experimental stuff – anything that one or several committers want to work on and make visible to others.

Between the committers it has been brought up that there are two possible strategies for organizing the code that gets committed there.

One; separate all root folders into committer name like I have done with /trunk/whiteboard/mschmalle/mobile-popups.

Two; separate the root folders into functionality and then say committer name.

My opinion as a committer is that we should just use our names as the root, keep a README file in the root of our folder to allow anybody curious the ability to see what is going on at a glance.

Maybe root level directories can be voted on as a group so that only things that will have a shelf life end up at the bottom most visible folder.

I just donated a mini PopUp framework to the whiteboard yesterday, this is also why the conversation came up, seems like the Apache Way of just do it is good because it allows things to surface and get resolved.

You can see the code here; http://svn.apache.org/repos/asf/incubator/flex/whiteboard/mschmalle/mobile-popups/

SDK’s future

Quotes are from Alex Harui.

Carlos Rovira brought up some questions;

Dynamic View States

Capability to create states on the fly and let other code handle the transitions, etc. of these states.

Adobe has some work in this area that will likely get contributed.

AOP

AOP is probably a language thing, which we do not have control of. As soon
as you start bytecode manipulation, you are no longer programming in
ActionScript and prone to even more debugging and analysis issues than folks
who used to mix C and Assembly. I would first want to see why a better
composition model for features can’t do pretty much everything you’d want to
do in AOP.

Flex Core refactor (SystemManager, Managers -PopUpManager,…-)

My whiteboard folder will eventually include a completely new framework based that will be mostly backward compatible with Flex but will have smaller base-classes, a minimal DI implementation, and not use AS features that are hard to cross-compile to JS.

Maven support

It is the #1 vote on JIRA. Just need someone to start working on it.

Metada Evolution and DI frameworks support

I’m very much against the use of metadata at runtime. It is a whole other language that is not first-class in the VM and probably will never be, and currently does not have any ties to ActionScript. The kinds of DI used at the application framework level by Parsely and Swiz don’t need to be tied to the same DI in the framework and probably shouldn’t be for performance reasons. It is different to inject a large application model once vs injecting a data model for every component. Now if we find a good DI implementation for the framework layer, application frameworks may decide to borrow or extend it, and I’m pretty sure the framework DI will not be parsing metadata at runtime.

IRC Channel

Michel Boudreau commented that he runs the #flex channel on freenode.net. He was asking if community members wanted to make it the official channel for Apache Flex.

Bertrand commented that IRC is fine for water cooler talk but anything that involves decisions or direction needs to be discussed on the flex-dev@apache.org list.

Conclusion

Usually I do not directly quote Alex as much as I did above but, he gives such concise answers to questions that I could not resist on the items listed.

On the new framework that Alex is talking about, I asked him this;

Alex, can you say what your framework classes are based on? Is this something where mobile and multi-touch can be used/composed but the framework not dependent on them?

His answer;

My current thoughts are to create a framework that is very granular and uses lots of composition. I have prototypes where HelloWorld is a 28K swf.

I’ll leave you with that wonderful future vision.

Thanks for reading,
Mike

Well this was the first Sunday edition and for those who had a life were probably resting and relaxing.

This list sure didn’t, not much of major interest happened, just some followups and simple things.

Also, anything that is say controversial from an opinionated angle, I’m probably not going to bring up in these summaries. Gossip news papers and advertisements have one place in my house, on the bottom of my birds cage(home)

Apache Flex Logo Contest

The Logo re-branding contest is not yet in full swing but the DRAFT document is up on the Apache Flex website for those that want to start up their favorite graphics software and give it a swing.

UPDATED

I created a new page on the website for the contest specifically.

Check out the rules/information; http://incubator.apache.org/flex/logo-contest.html

We are asking for fresh and innovative designs here, so try to erase what you previously had branded in your head with Adobe Flex and put a new spin on the logo to symbolize the new future Apache Flex is headed.

AIR Native Extensions for Linux

A community member asked about AIR native extensions for Linux. As we all should know, Adobe discontinued development before native extensions were released.

Flex Roadmap

This subject was brought up again and the answer is found within the community. The PPMC members of Apache Flex cannot stress enough that the future of the Flex SDK and it’s off shoots rely solely on the input of the community, yes that is YOU!

JIRA is the formal process to take surveys, ask for features etc, that can then in public be voted up or down depending on popularity.

Once major features or roadmap items come into focus, discussion can then be started on the flev-dev mailing list to get a consensus direction developers want to take and then can start committing code to satisfy that direction.

Not on the list but thought provoking

A mobile AS3 framework

This item was not brought up on the list but it’s something I have thought about and what are the solutions to.

Since the Flex SDK is not “defined” by the UIComponent in the future, what is the feasibility of designing an AS3 framework from say SpriteVisualElement or lower that would allow MXML or pure AS3 implementations without the dependency of the UIComponent for mobile applications.

It’s an interesting thought and one I have come to the conclusion will need to be discussed. I have written quite a few AIR mobile applications and find myself really trying to stay away from the UIComponent. I’ve actually ended up creating a small framework using the SpriteVisualElement as base to support multi-touch.

Multi-touch

This is a very important thing to think about with mobile. The current SDK was not design to handle multi-touch. As more and more mobile applications come into existence, this is a requirement. Having done multi-touch music applications(knobs, sliders etc) in both AIR and Android I would say it is 5 times easier to make a multi-touch application in AIR than Android out of the box.

So, I hope this gets talked about, I don’t think the time is now to start a conversation on the mailing list. I hope that others see the need to get away from the one shoe fits all approach we have in the Flex SDK to date.

Conclusion

That was Sunday, lets see if some code arrives and JIRA this week!

Thanks for reading,
Mike

Hi,

Day three of I would say the “brainstorming” session in the flex-dev@apache.org mailing list.

Flex logo

The community is still invited to think about logos for the flex website. There have been quite a few ideas floating around and plenty of opinion. It’s nice to see that one of the more popular designs that has been submitted on the mailing list is by a very humble Carlos Rovira, that insists a contest needs to be held and voted on by the community.

We are trying to get a page on the website describing this, I think I might just try to get that up with the information that has been submitted already so folks can take a try with their own idea.

Flex SDK full code reformat

As mentioned there has been discussion on code conventions and having some type of singular look to the code in the core SDK. Alex has mentioned his main concern is not tabs or spaces, just that 4 spaces equals one tab.

It’s up in the air but Rick Winscot has been investigating running the Flex Formatter on the command line so Alex can do one full pass through the SDK.

I do agree with some thoughts that have been brought up, the main idea is that the frameworks code looks uniform, how we get there is another story and whether devs care is another one.

Flex mobile components

Alex pretty much summed up Adobe’s position on the current state of mobile components.

Q: What is the future of mobile AIR components from Adobe?

A: Mobile AIR Components are being donated to Apache.

Q: Will we continue to see new mobile Flex components from Adobe?

A: No, but I hope to see some from Apache.

Non shameless plug here, I have released the mobilui toolkit1 mobile set and plan to release more mobile components having support from the community.

Product Page – http://www.teotigraphix.com/components/toolkits/MobileUIToolkit1

Q: Will we see AS3 mobile components from Adobe (rather than built in Flex)?

A: No. Adobe is not planning to develop new components outside of Apache.

Q: When they promote future AIR mobile content, will they reference any new Apache Flex mobile components that we develop?

A: No way to know for sure. 4.6 has a pretty good set of components already. I would bet if Apache Flex makes some really great mobile components, they will, since it will help AIR. Adobe has been promoting Jquery for HTML for a while now. I think it is roughly the same model.

Alex finishes it off with

It will totally depend on how well Apache Flex works as a community.

Couldn’t have said it better myself.

GIT support

Do we have GIT support for the Flex SDK?

Bertrand answers;

There’s http://git.apache.org/ where we can ask to have a git mirror
of Flex once the code is in.

I don’t think this allows for directly committing pull requests, but
people are working on it. For now, AFAIK you have to create an svn
patch from your git changes, which is quite easy.

Summary, I’m sure a lot of devs including myself will use GIT on our local computers than commit that code to the svn repo on svn.apache.org.

SVN Whiteboard

The Flex SDK will contain a whiteboard root folder that will hold all the future innovations of the Flex SDK and beyond. If you are a developer you will definitely want to check this out and update constantly.

Check it out here; http://svn.apache.org/repos/asf/incubator/flex/whiteboard/

Tink has committed the first whiteboard in the navigators folder. These components will but up for review to be included in the first release of Apache Flex.

We are working on getting an Accordion and TabNavigator implementation that parallels the mx version.

BlazeDS

BlazeDS has come up and where it’s home should rest. Most community members feel that it should exist in it’s own project even though it has dependencies on the Flex SDK.

The obvious argument is that Flex is client and BlazeDS is server, that alone constitutes a separate project.

Other community members are not convinced that Adobe is going to move all rpc code which will then create licensing issues with the LCDS product. I have to admit, I am not one to talk on this subject so don’t take my word for it as in Reading Rainbow.

TabNavigators and other new components

Any of you that read my blog will know I am direct, action oriented and don’t like to play games. Consequently I have been raring to go with this Apache Flex project since I have somany years invested and feel it’s worth my time to give it all I got right now.

That being said, sometimes I say to much, but maybe that is a good thing. Maybe I’m speaking for other less vocal developers that feel the same way as me. Maybe not, I do make myself a target sometimes.

I am in full agreement that the “kitchen sink” as it is consistently called should not be jammed into an SDK that were are trying to trim the fat out of anyway.

Now for closing, my own verbatim comment to this on the list;

My thought, create an extension, branch what ever you call it of flex component extensions that are officially supported by the committers of Apache Flex (me, you and others). Have it merge in things from the FlexLib, show the community that using components saves time and is supported as a fundamental development ROI. This might actually re-ignite the 3rd party ecosystem benefiting the people like you and I that aren’t quite satisfied with “traditional” consulting model.

Conclusion

Some days are more emotional to some than others, this one was a good and bad one for me. Good that I see so much future to an Flex SDK that can be better, bad that I might not be able to convince the community to change there bad habits.

Thanks for reading,
Mike