Mozilla's open source crash reporting system premiered in Firefox 3.0. Combining the Google Breakpad and Mozilla Socorro projects, Mozilla has created a system that allows millions of client applications to report crashes back to a central location for analysis. This talk is intended for people interested in how the new Firefox crash reporting works and how it is applicable to other projects.
There’s plenty of material (documentation, blogs, books) out there that’ll help you write a site using Django… but then what? You’ve still got to test, deploy, monitor, and tune the site; failure at deployment time means all your beautiful code is for naught.
This tutorial examines how best to cope when the Real World intrudes on your carefully designed website. I’ll cover:
Along the way, I’ll discuss what’s behind some of sites I’ve got in production right now, especially the problems I ran into and how we solved them. I’ll also critique any production environments tutorial attendees would like to share with us.
This talk is designed for developers and system administrators who deploy Python-based web applications. I expect attendees to have a familiarity with Python, but much of the material will not be language specific, so those without Python experience should be able to following along.
In a similar vein, this talk will focus on Django, but the material could be useful to anyone looking to deploy web applications based on dynamic languages.
You already know some Perl. You’ve read a book, written a few scripts, maybe even a module, but are you sure you’re doing it right? Languages and techniques evolve over time, and Perl is no exception.
This detailed tutorial will cover many of the best modern and practical techniques in Perl, including:
Join internationally acclaimed speaker Paul Fenwick, and White Camel Award winner Jacinta Richardson, as they examine some of the best modern Perl techniques you can use today.
A knowledge of Perl’s basic language features is assumed.
Everyone else is using Model-View-Controller (MVC) frameworks to create their websites, but Perl has so many! How is an MVC-novice to choose between Catalyst, Jifty, Gantry, Maypole or many of the others? Come along for a whirlwind tour of these frameworks and more and see their strengths, their failures and make an informed decision about which one you’ll use for your next project.
This talk will start with a lightning description of what an Model-View-Controller (MVC) framework is, before delving into how to create a simple address book system in each of the covered MVC frameworks in Perl. These will be evaluated on how easy it is to set up a system that allows full Create-Review-Update-Delete (CRUD) access to the database tables as well as display aggregated information for each address book entry. The ease of installation, the usefulness of the documentation, and the responsiveness of the community will also be explored.
We will have a look at a selection of MVCs in Perl representing the very popular, some very new, some older and mature and some previously unheard of. These will include Maypole, Gantry, Jifty, Catalyst, CGI::Application, Solstice and Mojolicious but may also include others that come to light prior to the conference date.
Whether you’re strong believer in a one true MVC, or you’ve discounted them as all too hard; this talk is for you. Different MVCs have their different strengths and will appeal to different audiences. Yet, at the same time, you may even find yourself adding extra ones to your toolkit for the kinds of projects where their strengths really shine!
by Ian Dees
This talk begins with a survey of the landscape of iPhone UI testing. We’ll discuss the work done by Dr. Nic Williams in unit-testing Objective-C code with RSpec, and by Matt Gallagher in spidering the iPhone UI with an XPath test script.
That will be a natural jumping-off point to explain why a full-fledged “GUI driver” for iPhone apps has been long in coming. We’ll look at different ways to prod at application code, and discuss the tradeoffs. Finally, I’ll introduce a simple library of Ruby glue code to connect Cucumber test scripts to the iPhone. The technique will be very basic, but just powerful enough to test a simple iPhone app.
At OSCON 2008, Tim O’Reilly spoke in his keynote and in a follow-up blog post about the primary challenge now faced by Open Source and Free Software: the network service provider’s Software as a Service (SaaS). As referenced in Tim’s talk, a think-tank group formed in early 2008, called autonomo.us formed to consider how the Free, Libre and Open Source Software (FLOSS) community should address this concern.
So-called Application Service Providers, who provide SaaS, are now the rule rather than the exception in the software industry. The freedom implications of ubiquitous, high-bandwidth networking and AJAX-based application delivery are not yet fully understood nor adequately addressed by the FLOSS Movement. Even those of us who have been paying attention during SaaS’ rise remain somewhat befuddled by the freedom implications of the new environment.
Our Movement must develop a multi-front response to this proprietary threat that will make the 1980s and 1990s battle against proprietary operating system vendors look easy. The challenge is specifically centered around two complex issues: (a) traditional user-freedom-protecting licenses (i.e., the copyleft) fail to protect the freedoms of SaaS users, and (b) even if users have the source code to the application they are using, they cannot run it themselves and generate the same network-effect available in the canonical instance.
This panel discussion will frame and introduce the key questions introduced by these new issues. We will discuss the Affero GPL, which is one of few FLOSS licenses that address this concern from the software licensing perspective, and explain how our traditional FLOSS solutions cannot succeed as easily in this new network service context, and how developers must use server federation and distributed computing to overcome the new challenges we face.
SOA security needs to be by design, not as an afterthought. This session will demonstrate implementing Message Interceptor Gateway security pattern with WSO2 ESB, WSO2 WSAS and WSO2 Identity Server – together with the OpenID/Information Cards integration pattern at the front end. The Message Interceptor Gateway pattern provides a single entry point and allows centralization of security enforcement for incoming and outgoing messages. Further, this session explores adding authentication and fine grained authorization for web services. If you’ve been looking for an open source alternative to Microsoft Geneva, this session is for you.
The president of your committee is doing most of the work and none of the management. The secretary hasn’t written the minutes for any of the meetings for the last 6 months (you wrote the last 4 agendas on the day of the meeting). The treasurer can’t access the bank account, and you haven’t heard from your publicity officer since you started planning the big event. Welcome to the fun of volunteer communities!
Communities form around points of interest and commonality, but this doesn’t mean that everyone in the community has the same interests or even much in common with each other. Rarely does this come to the fore as clearly as when you gather together with a group of people, form a volunteer committee and try to achieve something great! In a perfect world, these committees would work smoothly with no excess over-head and awesome events would just fall out like clock-work.
The real world is far from perfect. The people in your committee are volunteering their time, effort and resources to make something happen, yet their skills probably lay in entirely different arenas. For example, by day they might be a developer, not a treasurer; or a systems architect but not a project manager (president). Your fellow committee members may also have conflicting ideas as to what their position means; and they almost certainly have different motivations for participating in the first place.
This talk is about building communities and surviving in committees, from small user groups to running big conferences. There will be some amusing anecdotes, stories from the trenches and a bunch of suggestions from war heroes on how some of these issues could have been avoided earlier.
For decades people have been learning to program by copying and modifying other people’s code.
How did you first learn to program? For us, it was by copying and tweaking simple BASIC programs on ZX Spectrums and Commodore 64s.
Folk Computing (a term coined by an MIT project which encouraged children to learn programming in exactly this way) has been a common factor in programming environments from LambdaMOO to Yahoo Pipes, the OLPC, Second Life, and more.
We look at the history of folk programming from the 80s to today, and then examine some modern folk programming platforms.
Some topics we’ll explore include:
by Paul Fenwick
A good programmer needs many qualities: intelligence, foresight, dedication, and the ability to fight off a hundred angry targh armed only with your bat’leth. On Qo’noS, software developers undertake an intensive course in combat programming before they are cleared for active duty. The tlhIngan traditions have long known one truth holds true for both glory in battle and software development:
bIlujDI' yIchegh()Qo'; yIHegh()!
It is better to die() than to return() in failure.
For too long, Perl has been a pujwI’, and unsuitable for use by true warriors. In this talk we will show how the new autodie pragma can help you to code with batlh!
by Michael Lopp
Zope 2 was a great and revolutionary web application framework, but it also had it’s fair share of problems and design mistakes. Some of those problems came as a result out of the new revolutionary features. The through-the-web development turned out to be problematic to step away from if you wanted to move over to the more unrestricted disk based development, for example. Other problems just arose from increasing complexity over time, and Zopes monolithic design. Zope was also a trail blazer, and had to implement it’s own modules of many basic web framework parts, because they didn’t already exist elsewhere, which ended up isolating Zope from the rest of the Python community. Zope 2 is therefore full of dead ends.
Zope 3 aimed to fix these problems, but the way it was developed introduced it’s own problems, and when it was released it’s complexity has been a deterrent to get people to use it. There are no dead ends, and a nice architecture, but instead a huge learning curve.
This talk takes up the most glaring errors made by Zope 2 and Zope 3, presents an attitude to application frameworks that can avoid these problems, and discusses how the Zope and Plone community has been using these attitudes for the last couple of years to fix the problems of Zope, putting Zope back on the leading edge of web frameworks, where it belongs.
20th–24th July 2009