techMusings

Carbon Fibre G5

Been waiting for a G5 powerbook, would be cool if they looked like that...

EJB 3.0 further notes..

One of the big focus items is ease of use. JDK1.5 (since this will be in J2EE 1.5) will be required - hence generics and metadata will be leveraged. Also, since the jump is from 2.1 to 3.0, then a new model is possible, not backwards compat with the existing 1.x and 2.x models (though the existing will still be supported) -- i think this is to enable a significant change.

Apparently there is a desire in the EJB expert group to provide a POJO persistence mechanism, not entity related and, to my surprise, not JDO related.

We were asked to list titles of features we'd like to see then rate the list, I'll avoid the ratings but provide a few of the titles the group came up with:

• Enable easier testing outside of the container for TDD (most popular)


• Provide a mechanism to specific JMS selectors at runtime (perhaps via JMX) to allow dynamic reconfig of message consumption


• More powerful EJB-QL constructs


• Allow dynamic specification of EJB-QL


• Allow escaping to SQL instead for EJB-QL to allow use of stored procs / vendor extensions


• Reduce the need for deployment descriptors, perhaps via more aggresive defaulting (how much info is needed for a stateless session bean for example)


• Use of metadata to provide dd type info


• Cache invalidation (perhaps extended to a generic cache capability)


• If remote interface is akin to business instance methods, and home interface to statics, why not just make them that -- ie home is generated from the statics and the others from public instance methods (defaulting could go either way on this)


• Remove the ejb prefix (eg ejbMyMethod) in the implementation -- this would also allow the imp to actually implement the remote interface -- compile time safety, also corba style

Heretical Java 1

This session attempts to face down the imperfections in Java / Java understanding.

GC / memory management - a discussion of the fact that Java does not remove all responsibility for memory mgmt, you still need to release references to objects. Frankly, this was tortuously slow, too many side tracks, weak references (no pun intended). Time to leave... very disappointed in this session.

Psyco

A Python JIT -- utilises an understanding of the high level objects provided in Python (lists , ranges etc) to convert into efficient c code. Seems clever but embryonic -- needs a bunch of heuristics to avoid (C) code explosion.

EXCELLENT animated presentation (using pygame) -- animated JIT internals with a special appearance from a few Lemmings as the CPU -- comment was made that it would be a good technique for teaching kids how to program.

Towards EJB 3.0

This workshop was to gather feedback on the existing EJB specs / implementations and find out wish-lists for the next major release.

Aspects at work or: Getting Exception Handling right with AspectJ

This session, the second AspectJ presentation at the conference (both by Arno), covered using a few different aspects to soften and otherwise deal with exceptions and error conditions -- the examples were based around CORBA calls. The aspects did things like exception logging / softening and auto-retry/re-connect.

Arno was using Eclipse/AJDT and made good use of the compile list / declare warnings features of the toolset to demonstrate how to add aspect based refactorings to a project. I felt the examples, while good, were a little too CORBA focussed and also infrastructure based. While this is the most obvious use of aspects in most apps (logging/security/caching/retry) I felt a more business object example was missing -- though I have to admit I can't think of a good one right now for a demo... maybe that's part of the problem with communicating AOP, more real world experience of usage is needed.

How to write large-scale applications with Python

I was hoping this talk was going to explain how to go about managing a code base of hundreds / thousands of modules in python highlighting strategies and gotchas particular to the Python language. However this was not to be. Instead it was a general talk about how to structure an application (sub components etc) and about general design patterns to use.

I'm get the impression from both this talk ("in python we don't use patterns") and others that most python projects / developers (who have come to python directly) ignore the body of design knowledge that other languages have built up. Python certainly makes it easy to get around the strict pattern-influenced interfaces, but essentially it's the same thing, not recognising this means the vocabulary is denied (which is largely the purpose of patterns).

ah - last 5 mins the goods:

• keep import deps low -- avoid from .. import *


• use absolute import paths (ie full namespace) -- unpickling is a particular gotcha with relative package paths


• use python pacakges


• import loops can be nasty

And then...

• use data objects for data encapsulation rather than simple types tuples/lists/dictionaries etc


• use methods for simple tasks


• use method groups for more complex ones


• use mix-in classes if method groups can be deployed in more than one class context


• use PyChecker to find hidden typos and possible bugs

Python in Finance

Peter gave a quick overview of finance (sales/trading side) and pondered on the reasons for using open source in this environment. I think I may have to sue him for stealing a point I made yesterday -- we (often) don't use OS due to cost reasons (in fact he reasoned that it's not cheap) but because it avoids the procurement process which is too slow and painful.

He then went on to give examples of the use of python in the front office environment.

Re-Learning Python

A review of the new features added to python since the once hallowed 1.5.2 version -- iterators, generators, new object model, metaclasses etc. A very rapid run through the features I think suffered slightly from the sheer amount of material (the talk compressed a normal 2 day content into about an hour).

My general impression of Python with these new changes is that it's getting quite bloated with niche capabilities that most people will never -- or rather should never -- use. It's turning into C++ without pointers imho. Fortunately most features are tucked away, and the simple syntax (the main selling point other than the VB style libraries). I get the impression, somewhat dejectedly that most people are actually only writing glue code with python and not large systems (see later session entry on this topic).

Several features are similar to what C# is doing -- properties, iterators and generators which allow a simple iterator syntax using a continuation-like support (yield keyword). I think Delphi may have had many of these for sometime.

On panel blogging...

We just had a fire alert so after the brief interuption...

OS at HP Labs

• use two main licences LGPL & BSD (no corp specific licence)


• Mainly Java based OS work


• DSpace - vitual libraries, live at MIT since Nov 2002, still active project


• Jena -- implementations of the Semantic Web stack from W3C (RDF/OWL/RDQL etc) plus some bits not currently specified. its a Java framework for building SemWeb apps.


• Deli -- adapting web content for multiple devices, based on Jena, can run inside Cocoon and make CC/PP info avail to cocoon


• WH2FO -- process the HTML output of Word 2000 ->> XML ->> XSLT->XSL-FO


• FOA -- wysiwyg XSL-FO editor

Linux at IBM

Just caught the end of this one, some IBM focus topics:

• OLTP / xact failover


• PowerPC is the way forward


• "if you chose Linux, you should not be limited in any way relative to any other OS"

OS Licences 101

• Licensing models are driven by desire to share, not profit


• terms
  
  
  
  • OS developer creates IP
  
  
  • Owner of IP has Copyright
  
  
  • People orgs can use IP
  
  
  • Businesses wants to use UP as part of a distributed
  
  
  • Dev chooses licence
  
  
  
  


• ... some discussions of what motivates devs and businesses and what businesses fear ...


• 4 groups of licences




• copyleft (gpl)


• lib copyleft (lgpl)


• liberal (bsd, mozilla, apache)


• corporate (nokia , netscape etc)




• FSF freedoms -- freedom to run, distribute, change (need the source)


• GPL -- if you use, derivatives must be gpl, explicit tool against proprietary software


• LGPL -- viral to changes in libs, doesn't spread to using code, lib must be replaceable


• rights




• extremes: public domain (no (c), TM, patent OR (c) All rights reserved, TM, patents


• menu: retain ownership, reciprocity,




• reciprocity: if you modify and redistm must publish the chages to the commons, only applies to redistributed works (internal use ok, because not "displayed")

Unfortunately I couldn't get all the details down (and we skipped a few slides) -- will ask for a copy of the slides I think. Overall one of best presentations so far; David, understandably, made a point of stating he's not a lawyer, but presented the topic in a concise, laymans view of the OS licencing world. As he mentioned, there are a lot of opinions, strongly held, about specific styles of licence (the GPL / non-GPL-type divide being the biggest) -- however, many especially small, projects seem to chose a licence arbitrarily without understanding the consequences, better FAQs about this topic need to be publicised.

Sleepycat Software: Berkeley DB Database, Native XML Database, Native Java Database

BerkleyDB in Java, hopefully they are going to do dbxml in Java too. Time for a download..

Funding Open Source

A disparate set of topics centred on funding projects / development:

• discussion of Mark Shuttleworth's bounty scheme whereby open RFEs on OS projects are encouraged via cash incentives --


• talk of SBCs funding of OS firewallo testing and exploit hardening / DRAs research into comms over poor network links (eg UDP to remote space probes). This later went into how to protect IP for future generations and the corruption of copyright laws (extending from 20+ years to 90+)


• how to pitch to the European Commission for innovation grants

Visual C++ Giveaway

Apparently, on Monday, MS will make VC7.1 (VC 2003) compiler and bits a free download (not time crippled, not usage crippled, not the IDE / GUI) -- the next version will be the same.

Looks like the pressure to give away tools in order to get platform adoption is reaching MS again (C# compiler and .NET are already free downloads).

Where will it all end?

Beyond Methodology

This session turned into an open discussion on the pros/cons of following methodologies in software development. The presenter clearly had an opinion that they should generally be avoided (and bug tracking systems!) - though the group saw the need, the general consensus was that following a methodology and expecting it to run your project / solve world famine was the wrong expectation.

Other facets mentioned:

• The need to develop the developers, in terms of growing staff.


• The requirement to encourage good quality communication between team members


• Valuing dev intuition on design


• Using spikes to reduce risk

The discussion was pretty lively with a whole bunch of different opinions and experiences coming out. It was clear that while everybody had some commonality of experience, there were a few differences that emerged. One guy said he used to work for a firm that had a strict method of delivery, which most of the teams didn't like very much, however he reckoned they could deliver almost all their projects to within 10% of the estimate.

I think it became evident that the speaker had been burnt rather severely on a few projects where a methodology ruled the roost at the expense of team members or dynamics.

Open Source Business Models that Work

A good overview of the various combinations of revenue streams that companies are using -- selling consultancy / support / maintenance. Overall the companies are remarkably orthodox in their outlook -- they just happen to be leveraging (and some are nurturing) open source communities and code bases. All the things that closed source and non-software companies deal with are dealt with head on -- the value of customer relationships and quality of delivery are key, the fact that the software development costs are considerably lower (not zero) is pretty much beside the point.

General themes:

• A couple of interesting questions came up regarding the current trend for outsourcing.
  


• Dev model vs business model -- dev models very between employing OS devs / relying on the community / using devs located around the world. Largely the business models are completely standard.
  


• The topic of 3rd world / cheap labour markets and their influence on OS dev models came up. For example, Brazil is making noises about encouraging all their dev to be OS -- does this mean Brazil will fail to benefit globally in revenues since they are unable to capitalise on sales?
  


• Is it required to have a large, quality code base built PRIOR to going open source? Or can a startup being with a very small codebase?
  


• How to manage the relationship with your OS community came up -- how do you make money off a project and try to steer it, without alienating the devs?
  


• Interesting view that OS lowers the barrier of entry for small companies since much of the infrastructure code (and indeed much of the rest) for software can now be aquired off the shelf for minimal cost (integration only)


• The ASP model is also very amenable to OS -- you're selling a service, no-one cares how you built the software.

[If anybody wants attribution for comments / questions let me know]

First impressions on arriving is that I'm in Geek Central -- if you wanted to find a stereotypical audience / panel of techies, well, here's the place to come. I always try to believe techs aren't any different in appearance than non-techs, but this gathering might be the straw to cripple that camel.

LONG time no post...

I'm currently at the ACCU conferece in Oxford, so I thought I'd blog some musings from it.