wissel.net

Usability - Productivity - Business - The web - Singapore & Twins

What XPages developer are you?


There are 11 types of XPages developers, but you must understand binary to get that joke. There is an ongoing discussion what does it take to be an XPages developer and what skills are required. Regardless what development platform you use, web development is much harder than client development. You are dealing with runtimes you can't control (a.k.a what browser users use), network uncertainties (will that application be accessed via a shaky GSM connection or in a high latency network?) and a confusing set of languages that play together but have their own query mechanisms and syntax quirks: HTML, CSS, JavaScript. In a client only environment you usually get away with one language. Most modern IDE try to shield developers from this complexity but at some point in time are all subject to a leaky abstraction, so it is better to learn the languages of your trade. Nevertheless depending on one's personal aptitude there are different roles to be filled when developing XPages:
There are 3 types of XPages developers
  • Develop XPages - a.k.a Phil and gang.
    The team that makes XPages possible. Deep rooted in Java, JSF, NAPI and JNI they provide us with the SSJS engine, the XPages runtime and the implementation of various standards like JSF or JavaScript (a.k.a ECMA Script / ISO/IEC 16262). Besides occasionally writing a book they provide the core set of generic custom controls
  • Develop for XPages - a.k.a The Nathan & Niklas club.
    They extend the platform, build mobile extensions, provide an application transformer or run custom control contests. They understand XPages deeply, including its roots in JSF and the control life cycle. They code both in Java and JavaScript and have some dojo for breakfast
  • Develop with XPages - a.k.a. The rest of us.
    We understand users' needs, business requirements, workflow processes and the corporate development life cycle. We know how to distinguish between users' needs and wants and how to translate a vague descriptions of "make it work" into a concrete application design. Our favourite mode of operation is to drag & drop ready made custom controls and sprinkle Pixi dust SSJS between them as glue. We don't have time for the deep understanding both other groups need. We love JavaScript since we don't need to mentally reset when switching between front-end and back-end code (something our JSP, PHP and ASP peers envy us for). We are the largest group, but possibly the most quiet one too. For quite some of us developing software is just a way of making a living
So where are you and where do you want to be?
Turns out that there are actually 100 types. I forgot the all encompassing Notes Goddesses:
Notes Goddess

Posted by on 04 June 2011 | Comments (3) | categories: XPages

Comments

  1. posted by Senthil on Sunday 05 June 2011 AD:
    I am definitely in "Develop with XPages" group at the moment and trying to master :)And i may go and work with the "Develop for XPages" group ( if i get a chance) which to me is good from a business sense. Most likely i won't do the first one which is "Develop XPages" :)
  2. posted by Mike McP on Monday 06 June 2011 AD:
    Definitely in the 'with' group, but most of my dev is still client, because of your many reasons in the first paragraph.

    First and foremost, I am a resource for my customers to turn their ideas into apps. With a massive installed base of client apps at my company, the turnaround time hit that I'd take writing everything in xpages is not warranted. My hope is that eventually IBM will purchase/develop something like Transformer and make it a low-cost migration tool for clients. If they're interested in keeping marketshare as large clients look to the web, that would be a wise move IMHO.


  3. posted by Glenn on Friday 10 June 2011 AD:
    Im also in the "Develop with XPages" group and still mastering all the ins and outs of it.

    But on the sideline, i study Java as per your recommendation.