JavaOne Day Two

Here's my notes from another long day at the Moscone Center ... more great sessions

Ten ways to destroy your community

  • How to open source a project or how not to
  • When working on a open source project, you contract a diese ... a community
    • kiss your marketing plan good bye
    • mess up your product plans, unexpected innovation
    • they're never satisfied by any amount of quality ... no satisfying them
    • re-define who's a customer / partner, relationships change
    • you have to communicate all the time, who has time for that
  • Is there a way to address the menace: 10 steps to make it fail:
    1. difficult tools
      • issue trackers
      • weird build tools
      • single platform
    2. poisonous people; trolls, damage they can do
      • argue with them at length
      • denounce them public
      • ban them
      • argue in other forums
      • then allow them back in
    3. no documentation
      • no code
      • build methods
      • submission process
      • release process
      • how to install it
    4. Closed-Door Meetings
      • on-line, short notice
      • telephone meetings
      • meet in person, in secure office
    5. Legalese, legalese, legalese
      • the longer more complex the better
      • contributor, website, non-disclosure, trademark
      • change these docs all the time
    6. Bad liaison
      • someone reclusive
      • someone with no time
      • someone with no authority
      • someone unfamiliar with the technology
      • don't assign one at all
    7. Governance obfuscation
      • follow United Natations model
      • decision / election should be complex and lengthy
      • unclear what powers community have
      • rules nearly impossible to change
    8. Screw around with licenses
      • License == Identity
      • Developers have attachment to licenses (emotional)
      • Changing it or threaten to change it
    9. No outside committers
      • only employees get to be committers
      • if they ask, be evasive about it
      • have no written rules about how someone becomes a committer, or criteria is impossible to fulfill
      • promtoe an employee who doesn't code to be a committer
    10. Be silent: this is the most powerful of all
      • don't do anything
      • this is the easiest one
  • Ten ways to be successful:
    1. familiar tools
    2. discourage poisonous people
    3. document everything
    4. accessible meetings
    5. minize legalese
    6. expert liason
    7. governance simplification
    8. treat licenses with respect
    9. promote outside commtters
    10. communicate

Growing Open Source Developer Communities

  • goal / expectations
    • what are you building
    • different projects attract different contributors
    • product or platform
    • products extend
    • platforms are core
    • great projects do both aspects well, rare
  • code is king
    • starts with code and documentation
    • source code basic unit of open source
    • collaboration
    • first barrier is getting the source
    • make accessible
  • buildability
    • ensure builds for others
    • avoid unfamiliar, complicated tools
    • use open source build tools
    • document dependencies
    • make build work or fail fast
    • first impression, is important
  • tell the world about it
    • announce widely
    • freshmeat, osnews, slashdot, digg, reddit
    • development blogs
    • use blog aggregator / planet
    • use hackergotchis - recognition factor at conferences
    • who's the public face for the project
  • sharing wisdom
    • blogs have shared narratives
    • communities form around stories
    • how you write about yourself is how the world will see you
    • remains searchable forever
    • don't market project by slagging your peers
  • multimedia
    • podcasts let people hear your voice
    • get ideas into the ears
    • developer interviews
    • showcase people behind the code
    • screencasts, see features in actions
    • archive conference presentations
    • associate faces to a project
  • ubiquity
    • available to play with
    • Live CD, VMware images
    • success attracts success
    • present at local conferences
    • talk to press and analysts
  • the first patch is the hardest
    • smaller barrier to entry
    • make code build well
    • learn contributor interests
    • first impression matters a lot
  • converting volunteers into contributors
    • sources: porters, software distros, integrtors
    • work in other env
    • likely to become power users, try to tie them into the project
    • development is based on social trust networks
    • trust is earned through ood contribution
    • delegate early and often
    • encourgage good contributions
    • grow the developer pool
  • a bit of communication theory
    • two-step flow theory
    • info moves in two stages
    • mass media transmits
    • leaders pick it up, break it down, recombine it and disseminate it further
    • word-of-mouth
    • trust
  • the distribution model
    • linux distro aggregates open source
  • packaging
    • power users and marketers
  • tearing down the fourth wall
    • need infrastructure for collaboration
    • remove the committer access barrier to entry
    • mailing lists ( developers, users, announce)
    • IRC
    • bugtracker
    • setting priorities right
    • review tools
    • share results with everyone
  • ambient findability
    • serarhc engines drive a lot
  • social engineering
    • people are different
    • different strokes for different folks
    • keep out trolls
    • recognize through their posting behavior
    • encourage developers to take over responsibilities
    • volunteers to self-organize
    • developer audience is largely self-selecting
    • responses need to matter, even to the rude
    • avoid belittlement, hosility
  • it's not all code
    • non-programmers may want to help
    • docs, web site, marketng
    • low barrier to contrib
    • real world meetings and conferences
  • Governance
    • first time, join a foundation FSF, ASF, Eclipse, etc.
    • provide framework, legal and admin issues
    • pick an initial model (dictator, cliques, voters)
    • everyone different
    • expect to change over time
  • don't
    • mastermind and control the project
    • they to make everyone happy
  • don't fear the fork
    • experimental (good) and hostile (bad)
    • maybe for marketing
    • trademark assurance of code pedigree
    • best discouragement is a well-run project
  • dealing with legalese
    • don't create own license
    • stick with what developers know
    • prepare to change it
    • copyright assignments lets you change your mind
    • trademarks
    • patents

JRuby on Rails: Web Development Evolved

  • Overview of Ruby features
  • Overview of JRuby
    • Started in 2001
    • Java impl of the Ruby language
    • Opensource
    • Commercail backing, Sun, Thoughtworks
  • Why JRuby over Ruby
    • performance, scalability, native threads
    • integrate with Java libraries
  • Easy to use Java
    • require 'java'
  • Use juby within a Java program
  • Ruby on Rails:
    • web dev framework
    • single threaded, shared-nothing design
    • convention over configuration, common case should be the easiest
    • don't repeat yourself (dry)
    • agile development
  • Demo: create a blog application
  • Why JRuby on Rails
    • Ruby
    • Java app server, Java EE platform
  • Real world
    • mingle, first JRoR product
  • Future: Ruby
    • rework integration feature
    • public api
    • better performance
    • light weight objects?
  • JRuby on Rails
    • mutltithreaded rails
    • runtime info sharing, avoid memory hit

Ajax and JSF: Natural Synergy

  • How to support Ajax without javascript guru
  • JSF in action book
  • What is JSF, standard framework for web user interfaces
  • JSF is a specification, component and event model, basic ui components, application infrastructure
  • Extensive tool support, RAD style design
  • third party component market
  • on top of Servlet API
  • Compare JSF and Struts
  • IDE effect; different levels and styles, not required
  • JSF programming model: View, Event, Backing Bean, out come, navigation
  • Pluggable Extension points: Resolver, View, Navigation, Action, State, Render
  • Ajaxian Faces: components and renders can be seperated, PhaseListeners can be modified, transparent Ajax support
    • JavaScript bridge sends request
    • PhaseListener sends changes
    • JavaScript Bridge updates page
    • some components may not be compatible
    • no standard for bridging, resource resolution
  • Sprinkling on Ajax
    • JSF event listener executed async
    • Ajax4jsf (RichFaces), AjaxAnywhere, DynaFaces
    • Ajax4jsf: add ajax support to JSF component with javascript events
    • Demo: apache myfaces tomahawk
  • Ajax inside
    • ECruiser Ajax Suite for JSF
    • ICEfaces, innovative take on ajax browser/server integration, direct-to-DOM, supports Comet
    • Infragistics NetAdvantage for JSF, full ajax support
    • Sun Project Woodstock
    • Apache MyFaces
  • Ajax on the outside:
    • what about those cool pure widgets
    • jMaki, wrqppers popular widgets, easy to create
    • YUI4JSF
    • DojoFaces
    • Mojarra Scales
  • Which one to pick
    • pick a component suite
    • myfaces tomahawk has some ajax support
    • has good JSF support
    • how much ajax do i need
    • use jMaki for eye candy or Web 2.0 components
    • don't forget tool support
  • rolling your own, use toolkits to build components
  • JSF 1.2: improve ajax support
  • JSF 2.0: late 2008, Java EE 6, incorporate more features, bookmarkable

What's new in Ajax

  • not long ago the web was not a fun place
  • now really nice interfaces
  • creating compelling user experiences
  • four main frameworks
    • jQuery, high level components
    • ext JS, thin ajax layer
    • dijit, on top of dojo
    • , it's all about the interface
  • browser, is a single threaded process
  • access to threads outside the browser, google gears; worker pools (message passing)
  • Fluid, Mozilla Prism, Adobe Air; access to the desktop
  • Fluid: demo with campfire
  • uses greasemonkey, lots of javascript
  • problem wih ajax, need javascript and another language
  • how to create a better developer experience
  • Atana Jaxer - javascript on the server
  • netscape livewire (javascript on the server)
  • deployment
    • the cloud services - amazon EC2
    • Google App Engine - build code, hit the deploy button
    • Aptana Cloud - make cloud computing easy
    • moving your apps to a web service
  • how do we choose
    • dojo / dijit
    • jquery / jQueryUI
    • google widgit toolkit
    • prototype /
  • The New Java Plug-in, 1.6 update 10
    • plug-in now out-of-process
    • improved applet deployment
    • smaller JDK, micro-kernel
  • Look into the future
    • Safari: css animation, reflections and masks
    • Mozilla monkeys, javascript runtime compiling, javascript two plugin for explorer, iron monkey (python)
    • constrant to browsers

How to build RESTful Clients with the JavaScript, Ruby, and JavaFX Programming Languages

  • RESTful web services
    • services are stateless
    • have unitform interface
    • built from resources via URIs
    • exchange representations of the resources
  • Building the client
    1. create request data
    2. send request
    3. parse the reponse
      • code, header, body
      • formats: xml, json, kml, taml, rss, etc.
  • Debuging RESTful client
    • PUT and DELETE is idempotent
    • non-connected
    • PUT vs POST
    • use POST if URI length issue
    • async issues, use XHR
    • authen
    • caching,
    • overloaing POST
  • Demo: JavaFX with flickr
  • Demo: Javascript with Amazon S3


Post a Comment:
Comments are closed for this entry.

Scott Fehrman


« July 2016

No bookmarks in folder


No bookmarks in folder

Ref. Material

No bookmarks in folder