ICEfaces is much more than just a component library, it automatically, granularly and optimally AJAX-ifies a JSF page. That's because Ted Goddard of ICEfaces fame was on the JSF 2 spec committee, and JSF 2 was quite the collaborative endeavour, with input from many stakeholders and other groups who integrate with JSF as well. We were less fighting with JSF to sink our hooks in, and more simply interoperating, with all of the hooks designed in. ICEfaces 2 was an ambitious product, taking our feature set from ICEfaces 1.x and completely redesigning and reimplementing the underpinnings to optimally integrate with JSF 2. Previously less known complementary and competing technologies could gain beneficial exposure, pushing forward that technological ecosystem as a whole. There would be a beneficial feedback mechanism between support teams, development teams, customers, and marketing, as recurring and new customers become aware of the buzz of new developments, in anticipation of new releases. Where previously there would have been little incentive to do such agile integration testing, or publish the results, due to lack of developer resources in-house, crowd-sourcing could provide an augmentation of analysis, as those who care most and have resources could at least provide preliminary analysis, in their own self interest. Imagine being able to leverage supplier and customer automated tests, as one could receive indications of their integration with your software, on an ongoing basis.
#Icefaces 1.8 project software#
With finite testing resources, it might not be feasible to test every nightly build of every bit of software together, but with automation, crowd-sourcing and social networking, one can image waiting to only expend finite testing resources against software that others have validated and marked as stable, or alternatively, testing when pertinent modules have been updated, for a fast turn-around at addressing recent potential destabilisations.Ĭrowd-sourcing of evaluations of product stability could well drive development cycles, where crossing a threshold of instability could cause a shift from new product development to bug fixing, or attaining a threshold of stability could cause shifts toward feature development, or trigger ideal moments for merging of development branches onto main trunk. One can imagine automated regression testing that detects pertinent nightly builds of dependent software, downloads it, and tests the dependant software's integration with it. The sooner a nightly build can be found to cause a regression, the greater the likelihood of having that immediately fixed, while the context remains fresh in the developers' minds. They might have a particular interest in certain modules, and may wish to know of new features or bug fixes as they are committed, or after they are confirmed by QA. Individual developers might have interest in products as a whole, and wish to be automatically notified of major releases or minor releases. When a bug report is closed and fixed, or new feature is added, it pertains to a particular product, that will be available in particular upcoming versions, or immediately from the version control, involving specific modules or features. This would affect the rankings for all users, helping best solutions go viral, and the most pertinent issues become noticed sooner, with more eyeballs making bugs shallower.
Users could then Like the links that they found to be most helpful and on-topic. When discussing an issue on the forums, it could show you jira entries with matching keywords, relevant discussions on forums, the mojarra mailing list, or blog postings about the particular browser that you can reproduce the issue on.
Not just from the same organisation's website, but other websites for related technologies. Imagine a forum thread of some problem, where the more the users discuss it, the better the system would be at listing relevant bug reports. Users may post messages that link to bug reports and vice versa, manually, but why not have each system automatically indexed for searching, so that, just like relevant google adsense advertisements can be displayed within them, instead have relevant links shown from the other systems. And yet, it is not completely mainstream by now for the basic elements of an opensource community to employ all of the benefits of social networking.Ĭonsider how stand-alone things like mailing lists, forums, and bug reporting systems are. Often times, several forum postings that we were able to google will provide a lifeline for understanding an issue and finding solutions. We form communities around those technologies, collaborating in problem solving, across time and distance. Software developers have experience with specific technologies, and interests in significant and relevant updates to those technologies. I was struck with a surprising thought today.
0 kommentar(er)
