 |
| From Latinoware 2012 |
 |
| From Latinoware 2012 |
 |
| From Latinoware 2012 |
 |
| From Latinoware 2012 |
 |
| From Latinoware 2012 |
 |
| From Latinoware 2012 |
 |
| From Latinoware 2012 |
 |
| From Latinoware 2012 |
 |
| Chris Tweedy |
Kudos to those who sent lunch packages around to those manning the booths (i.e. me). It was a really nice touch that I have not seen done at any other venue. Classy all around.
Please drop by the LISAsoft booth and say hi.
But I really must call them out on their banner this year:
Really? You sure you want to say that? In australia?
At many levels it is perfect; a dispassionate fellow stairs out over the head of the plebes passing by...
If you are at Spatial@Gov today; drop by the LISAsoft booth and say hi; we are friendly and inviting; and have an alternative scenario for you to consider.
Cameron has also been kind enough to arrange an OSGeo Aust-NZ breakfast meet up. Join the revolution - support OSGeo.
LISAsoft is currently hiring; so I am supposed to be on the look out for new talent. I am afraid I am being distracted by all the fascinating and creative work.
For the short term I am going to make useful circles; and treat them like small email lists. It is kind of a feature that gmail lacked; and since google plus offers to send email it will at least give me a reason to try this one out.
It also looks like I can use it as a setting to interactively create a post such as this one; update the content based on feedback before punting it out as a blog post.
I don't really find this scary as the most popular application to use the web changes over time; we had email, IRC, websites (vs news feeds), blogs and it is about time we had a break from Google "being" the Internet.
Since my professional contacts started hunting me down on facebook it has mostly curtailed its use as a tool to catch up with friends.
The result is I actually like their service enough to install a phone application. Mostly it is serving to remind me how global our "open source" professional is. I don't really see google plus treading on this one as it is behaving a bit more like an online resume / recommendation site and a good way to check or confirm professional background.
So far google lacks the all important "gossip" vibe of twitter - mostly this shows up when I tweet about a new geotools or uDig feature; and then for the next several days I can watch that news trickle out as different people repost. It is an interesting way to gauge interest; and a reminder that much of what is needed for open source is work (and not interesting enough to retweet).
I am going to list Google Talk, Yahoo Chat, Facebook chat and basically anything else I can register with iChat in this category.
Special mention is made for Skype which with the ability to share a desktop session one of the most effective tools for "code review", or a "breakout session" on a specific bug. We do a lot of work with uDig this way and it is very effective - especially for cross platform issues.
In a sense issue trackers are the only social that matters to an open source project; it has evolved over time to focus on the social interactions required to get the software patched and releases made on time.
Update: Whatnick - points out that email lists can sometimes be used in a forum mode (as per Nabble or similar). I don't find this a separate communication medium than a "user email list" and indeed in the past I found "forum" use actively harmful in that they encourage users to browse; rather than sign up for the email list and take part in the community.
I do remember the only way to understand Eclipse in 2004 was to sign up for the news group.
Wiki has been pretty much killed off due to vandals; with news announcements migrating to blogs; and design discussion migrating JIRA, user discussion moving to Q&A the general purpose wiki is on the way out. The only thing GeoTools is using its wiki for today is the RFC procedure and a staging area for design notes.
The ability to follow blogs; watch RSS feeds get manipulated and chopped up for re-consumption is otherwise not widely used. Usually for a blog post to work you need to "time it right" so it shows up on a website such as Java.net; or more importantly watch it be voted up in Dzone; or simply collect google web hits based on the post having actual content (my preferred technique).
In terms of staging a conversation comments have almost universally been turned off; the conversation has diverged to places where the people are (DZone, Twitter, etc...).
The promise of the blogosphere is rarely met - with great public Quarrels (in the traditional War of the Roses sense) happen only rarely on grand topics. Most recently the future / currency of OpenLayers (results in a flurry of half a dozen amusing blog posts answering each other from different points of view).
I am lumping RSS feeds into this category; as a blog almost a source of RSS feeds. Best consumed via google search; or via a custom reader app such as a "Reeder" while no the bus.
More recently tweets get automated - many blog posts I publish against watched by simgeo with a bot to tweet as soon as I hit the publish button. Depending on how far that item is retweeted you can gauge how interesting the topic was.
More seriously GitHub offers an interesting alternative to consider - by setting up an apple like "cultivated garden" with nice code review tools; workflows to facilitate change management etc...
Projects like CodeHaus, Google Code, SourceForge and so on also fall into this category. The gather up many of the traditional communication tools and provide an easy to use front end.
This is actually a position I have great sympathy with:
As cameron has indicated Australia has joined the ranks of countries explicitly asking their government departments to consider open source in their "purchasing" decisions.
I have been gathering material for a course on this topic; as the kind of selection criteria considered when evaluating open source projects reflects a different set of risks then a procurement department is perhaps used to.
I also have been following the various web processing service implementation; and the amount of email is a real indication of popularity and activity.
(The above graph is just a reflection of activity. Both deegree and GeoServer are blips as not all of the activity reflects "wps" work. Some of the other projects just seem to have one email list for both development and user questions. Projects that successfully turn users into customers will also reduce email volume handling support offline. Figuring out how to deal with all this is one reason why you should take the course!)
(The above diagram is for the GeoTools project, issues resolved in the last quarter. GeoTools developers sell very few direct support contracts - instead focusing on the support of downstream products. Making for a nice graph I can safely publish without ruffling any feathers)
This level of visibility, combined with support being an area heated competition, provides a procurement department with more leverage (and responsibility) than simply talking to a sales representative.
Any project emerging from the incubation process has:
There is of course more to measure: recent requests to summarise quality assurance procedures for example. In my experience the "open development procedures" ends up providing a great view on the QA controls for a project. Putting that together into a table for review and comparison is just a matter of research.
The long and short of it is that the foundation is sensibly looking at revenue streams to support its activities. There are lots of great ideas for what the foundation can do; but accomplishing (or even setting goals) requires resources.
If you are interested in the following rants a more diverse opinion is available on discuss@osgeo.org.
Even if an idea is good, it will need to have some volunteers (or budget) attached for it to be successful. The projects are as I understand it already maxed out ... making software.
Indeed I can think of a lot of ways in which projects could be better supported that have not come through ... yet.
The osgeo discussion list also shows individual projects are also seeking ways to raise funds. With a classic tradeoff between an OSGeo backed 'donate button' (difficult to explain where the money goes) vs the 'bounty model' used to fund the development of specific features (difficult to explain how to include maintenance and documentation let alone the foundation).
The best I can come up with is taking away the "provider list" and putting it behind a pay wall. The foundation could send out the latest copy of the list on request; in exchange for a referral fee of some sort.
The danger is the foundation appearing to recommend a provider or training course that ends up being terrible. I cannot think of a cheap way for the foundation to supply any kind of quality assurance of providers, making this a risky approach to raise funds.
With respect to Paolo Cavallini commenting about the foundation supporting our work, not competing with it:
While I concur (I don't want to see the foundation set itself up in competition ) there may yet still be a useful roll to play.To clarify how certification makes the case for QGIS training courses stronger; and does not conflict with existing training offerings:What I cannot figure out is how the foundation could expect to make any money from this angle ... any figuring of costs I go through makes it look like a massive effort.
As for the useful role: If OSGeo was able to supply a certification test, provide independent marking, and issue the resulting certification it may actually complement existing training offerings by the "professionals and enterprises" and make training easier to sell. This would both validate the training offered; and act as a competitive advantage - right now given a choice between two training courses people will often choose the option that gives them a chance at sitting a certification at the end (especially if they have a limited budget and don't really care what it is they are learning).
A couple of things are clear to me about this discussion:
With the above in mind I feel that certifications will happen; and given a choice I would rather it happen at the foundation level (rather than getting people certified in different product stacks).
- a) I *hate* certifications; I feel they prey on the disadvantaged of our industry right when they are weakest (this goes for both job hunters and those going through a hiring process)
- b) certifications are really required in different markets around the world (especially when industry has lost confidence in the meaning of a university degree).
So while I have some mechanics in mind (certification to include the open source process; not only use; demonstrate ability; aim for a 50% pass rate for the certification to mean something; offer "bulk" discount to groups wishing to use tests at at the end of a training course; or groups wishing to use test as part of a hiring process).
What I cannot figure out is where the profit is; or how to pay for people's involvement. While groups offering training could collaborate (and possible act in a double blind capability to mark results); it would probably require some paid hours to get projects to look at the tests and make sure they mean something at the end of the day.
Pricing the tests would probably be within market norms; and I would expect a much cheaper retry cost (possibly just covering marking time) if we manage to make the marking process brutal enough to be useful to potential employers.
One thing we have a chance to do well here is stress the soft "open source" skills that a potential employee must have in order to be sucessful. Rather than only mechanical questions about configuration and use. Examples: link to 3 questions you have answered on the user list; two issues you have reported etc (which can be marked for completeness etc...).
Finally you have the annoyance for companies that are already established in this space of having the possibility of competing with new groups that have picked up their certifications and appear better "on paper". I cannot honestly have much sympathy here, competition is as competition does, best advice would be to help define the certification (and allow that to be placed on a resume).
I don't think anybody is interested in the foundation competing with existing training courses. (Indeed training is one of the few places where any cost recovery on the udig project occurs).That said if you don't want OSGeo competing in training - how would you like to pay for the foundation? I am not sure if your organisation sponsors OSGeo? I don't think my employer does (preferring to volunteer marketing effort); and I don't personally sponsor the foundation (preferring volunteer effort myself).
So this is the nice part about certification:
From the QGIS standpoint the benefit for you really is focused on those first couple of points; certifications would be an additional activity the foundation could perform that would make your training courses more valuable.
- it would make your training courses stronger (ie more attractive to customers)
- it makes training an easier thing to sell (take training as one step towards getting ready for certification)
- it would make QGIS more attractive (as a technology in which certification was available)
- it provides the foundation with a revenue stream that does not compete with any of the member organisations (Indeed certification is a "service" that very few organisations could offer credibly?)
My own thoughts on this (using your QGIS project as an example for how certification supports training):
The other scenario for using the certification tests is:
- Testing criteria
- organisations offering QGIS training are asked to supply criteria to use for the certification process (If your organisation wants to be involved this is where you would take part)
- the foundation pays for someone to write the test material for a specific QGIS release (perhaps you? perhaps another vendor?)
- the test is passed around to those supplying QGIS certification criteria for review; production of an answer key etc...
- Next time you do a training course offer your customer the option of either:
- a) taking the certification tests at a later date (you can pass on the foundation contact details; and get a 30% cut in thanks for the referral)
- b) arranging for a "bulk purchase" where you can offer your customer a discount for doing it then and their (perhaps give the customer a 20% discount to make it more attractive). You would need to play with the numbers to make this attractive (so customers don't just ordering the test for their top people).
- Each month the foundation hires one of the organisation that defined the testing criteria to mark the tests
- a) a month is chosen to have enough tests together in one spot to make effective use of time
- b) the organisation hired should follow a set rotation to be "fair"
- c) the organisation hired should probably not be responsible for the training of any of the students being marked in order to keep this as independent as possible
- Marking should be brutal
- a) the idea is to force a spread so that potential employers can actually respect the certification
- b) cover open source activities (bug submission, contribution to documentation, participation on the user list). If it is any kind of advanced certification this goes into building the application from source code, applying a patch and building locally (can submit a screen snap of the result), links to accepted submissions etc...
- c) How brutal? How about if they get everything right they end up with 90%; the last 10% is there to allow markers to recognise "outstanding"
- d) if you really want to soften the blow you can provide different levels of certification out of the same test (confusion may not be worth it; easier to fail people and ask them to try again)
- Updates to certification should be cheaper and repeatable
- a) as each release comes out the certification criteria should be updated
- b) a cheaper rate for "repeat customers" should be available - to encourage this both as a revenue stream - and as a certification process that employers can trust to be update to date. Why hire someone certified in QGIS 1.6 when QGIS 3 has been released?
- c) the cheaper rate should also be available to those repeating the same test (partly to soften the blow due to the expected failure rate)
- d) Updates are going to have to occur often to reduce cheating; we have a slight advantage in that we are testing real skills (the test can ask for maps produced with QGIS) and real interaction (the test can ask for links to nabble showing participation).
Next time you hire someone
- a) Buy a "bulk purchase" of tests
- b) Ask applicants to take the test; and submit review (this is nice for them because it is on your dime; and nice for you as you get an objective evaluation)
- c) The foundation arranges for someone to mark this pronto as part of the service; probably only returning details on the top five candidates
- d) The foundation could change more to access test results in detail
The final touchy subject is "discounts":
I am being very strict about not using the word volunteer in the above activities; your company / organisation should be paying for your involvement. And the OSGeo foundation should be hiring your company / organisation to set the certification tests, perform marking etc... This is very much pay to play.
- a) arranging some kind of discount for graduate students (perhaps if their professor helps with the marking it could be arranged at the school level).
- b) I hate asking graduate students for money; graduate student money is better spent on beer :(
- c) arrange some kind of discount for "osgeo volunteers" perhaps with an email from a recognised osgeo committee chair (project steering committee, education committee or something). Because I don't mind asking graduate students for volunteer time ...
- d) Being tough enough not to offer discounts to usual suspects (project developers, osgeo sponsors, people we really like ...). The more discounts that are around the lower the perceived value of the certification; we should try and get people to pay full price once; and then pay to retake the certification (either because they failed or because a new version of QGIS came out).
Summary since you are unlikely to review a full book review:
Problems with Open Layers:
I will use Volker's list to frame this review, how well does this book fill in the gaps mentioned above?
So what is Open Layer 2.10 Beginners Guide like as a book? It is one of the first ebooks i have tried to deal with directly, so the first step is sorting out how to read it in a productive fashion.
End Result, ePub may be the future of publishing, but at least on a Mac the future is out of reach - stick with PDF. To make this setup productive I needed to go grab a second monitor; one for the book and one to work in.
Edit: removed rant about documentation for another post.
Finally I printed out the first section to see how the typesetting comes across in book form.
The typesetting offers attractive with a clean and consistent presentation. The Typesetting features a distinctive look with bold wide headings that act like a black hole on the page (especially when reversed). In physical form this has been offset with nice wide white margins for an attractive balanced presentation.
Code is presented clearly with line numbers so you can refer to a specific line. There is a missed opportunity here as the code does not have any kind of formatting (for example bolding keywords to enhance readability). While this sounds like a small issue it really starts to add up after a while especially when examples mix strings and javascript code.
Sections are clearly marked, and importantly consistent allowing you to flip through the content and scan for sections such as "Time for action" that identify step by step instructions.
I have to guess that the eBook is intended as a supplement to a printed copy. There are a couple of things that let this use down: 1) the large margins detract from the on screen reading experience 2) Unfortunately the line numbers on the code examples are picked up when trying cut and paste into a text editor.
I am going to guess that the problems with ePub (on every single reader, and noticed by James Fee) is a quality control issue that the publisher can fix in due time.
So does this book address Documentation as a weakness of OpenLayers?
I have two things I expect of a book aimed at beginners:
Basically make me a believer, or at least believe enough to continue reading.
step by step showing me what to expect as I go.
While the examples may be a good reference they really are not suitable for beginner docs. Lets see how the sphinx docs does:
Total time for visual: 2 mins
While this may not the best metric for evaluating a book it is at least how I evaluate when in a book store. Can I understand the "hello world", if not I hunt for a simpler alternative.
Did I understand anything of what went on? Not at all (sigh). Simply adding the empty *script* block so I knew where to cut and paste into would help. Only reasons I was successful at all is because they put the example together at the end.
To be fair these are probably not beginners docs and the intended target audience probably knows more than me about how things work.
So how does OpenLayers 2.10 Beginners Guide fair:
Getting something on screen is covered in the first chapter. While we do have to sit through an introduction and background information, we do finally arrive at "Time for Action" section on downloading open layers followed by "creating my first map".
Total time for visual: 30 mins!
As for the long time; I was unable to cut and paste from any of the reader formats (downside to those helpful line numbers).
The following shows how selection works in the PDF:
map var
);
= new OpenLayers.Map('map_element', {}); wms = new OpenLayers.Layer.WMS(
After typing things in managed to produce an empty map! After checking and rechecking for typos; trying in different browsers, I finally clicked on the page which resulted in the map being shown (a ha something is working!).
A few questions on IRC (thanks crschmidt on IRC) and I was able to sort out my mistake:
map.addLayer(wms);
if(!map.getCenter()){
map.zoomToMaxExtend();
}
Can you spot it? It should be map.zoomToMapExtent().
So while I would love to give this one high marks for the clear instruction; it was a frustrating introduction to the book.
As other reviewers have mentioned, the second chapter on firebug really underlines the fact that this is a book aimed at beginners.
While intellectually I know that firebug is the standard environment for working with Javascript without going crazy; I only know this from watching coworkers. So I am thankful for the kind introduction using a domain I have some familiarity with.
In terms of the step by step directions I find Mr Hazzard's writing clear, and more importantly on topic. Any explanation is safely separated into a "what just happened" section so it does not get confused with the step by step instructions.
The other important aspect of step by step instructions is the pictures allowing you to verify progress and have the all important reassurance that you are on track. The pictures are plentiful but not pretty. While I understand that the result needs to be printed in black and white
I did suffer a little bit of platform and version burn during the initial install instructions; I wished that the instructions were given once each for (linux, windows and mac) as it is hard to follow a mix of linux and windows directories and then be presented a screen snap of some kind of linux file explorer in order to verify you did the steps correctly.
Once the book gets underway these platform specific issues vanish. There is a small "bait and switch" with the preface indicating that you can use any browser followed by the second chapter being dedicated to firebug.
Still this an excellent example of how to write documentation for beginners, working with Firebug is really assumed knowledge that anyone calling themselves a Javascript programmer (and thus a candiate for working with OpenLayers) is normally expected to bring to the party.
The rest of the book continues in this fashion offering a nice logical introduction to key concepts.
One shock for me coming from a GeoServer background was how much isolation OpenLayers offers from OGC standards. A good example is Style handling with Symbolizers being introduced directly and no reference made to Style Layer Descriptor standard.
Next up on Volker's list is the default look of OpenLayers. In this case the book goes way beyond what I was expecting from a simple beginners guide. There is an entire chapter devoted to themes covering how to style the controls use by OpenLayers.
I am not sure what the OpenLayers examples are like in this area; but I expect the book will help websites migrate away from the default looks.
Usability is going to be one of the technical issues on Volker's list. This usually comes down to making a web application both simple and direct to work with, and "snappy".
The book does manage to mention performance in a couple of sections; and emphasises the benefit of a fast web mapping application along with specific guidance on TileSets vs WMS. It also goes through the exercise of cutting your open layers file down to just the parts needed for your web mapping application.
So for a beginners guide this book is aware of performance and usability issues and takes some steps to address these matters.
This is an interesting entry on Volker's list - "The examples are not good". Personally I like the examples on the OpenLayers website, but I agree they should not have to bear the entire responsibility for documentation.
The examples in the book are more in the nature of step by step instructions, while I have a terrible time cutting and pasting out of the PDF, they are effective and plentiful.
One thing I would love to see in both the book and the website is the use of the natural earth dataset (or any other attractive dataset). The default blue and white map has come to define what OpenLayers looks like; and while it may be functional for examples I am sure we could come up with something more exciting.
With that in mind this book really does span a broad range. Starting off with some object oriented basics in Chapter 1 (for those new to Javascript). A couple of reference sections for the key concepts of Map, Layer, Vector Layers and Style. With a chapter on Making a Web Mapping Application bringing it all together.
So as a reference the book performs admirably. Does it address Volker's question about the general architecture? Probably not. I would of loved a picture of how open layers fits together to give me a better feel for the general architecture. Indeed I almost expected one after being introduced to Object Oriented concepts in Chapter 1.