This year I’m going to Devoxx again (sold out now), and it looks like it’ll be packed with a lot of interesting talks!
Via the fantastic Devoxx Android application, I have shared my schedule on the Devoxx site. Go and check it out š
This year I’m going to Devoxx again (sold out now), and it looks like it’ll be packed with a lot of interesting talks!
Via the fantastic Devoxx Android application, I have shared my schedule on the Devoxx site. Go and check it out š
A few weeks back on Devoxx 08, Jonas Jacobi and John R. Fallows did a talk about 2 future web technologiesĀ that’ll change the way we architect our webapplications.
(in the same manner then AJAX did a few years back).
The technologies are called WebSockets and Server Sent events and are part of the HTML5 specification. (which is now in Editor’s draft and thus not finished)
WebSockets and Server Sent events can enable us to create a full-duplex web application. Eg. a sample application could be a poker game with thousands of viewers connected and that those viewers need to be notified in realtime. Another example could be a continuously updated stock ticker.
Prior to the introduction of WebSockets, bi-directional browser communication was an elusive beast, commonly known as Comet or ReverseAjax and typically achieved with an astonishing assortment of browser hacks. But, with the emerging standards outlined in the HTML 5 specification, developers can now take advantage of a full-duplex communications channel that operates over a single socket.
With real time web, we mean that web clients can receive server updates (server initiated communication) and end users receive those updates concurrently.
Long polling with AJAX (XML Http Request) gives us near real time updates, but they are requested from the client and cause increased network traffic. Also these short AJAX requests generally have a small payload and relatively high amount of http headers. (wasted bandwith)
Comet technologies support HTTP Streaming, this setups a persistent http connection which only has to be setup/teardown only once. (especially nice for performance for https traffic)
HTML 5 not only contains WebSockets and Server Sent events.Ā It also contains standard features like:
Here we focus on two: Server-sent events and WebSockets
Server-sent events standardizes how we stream data from the server to the client (in fact standardizing comet/reverse ajax).
It introduces a new DOM Element: eventsource. The eventsource element provides a simple interface for allowing servers to dispatch DOM events into documents that expect it.
Here is how to create it:
var es = document.createElement(“eventsource”);
es.addEventSource(“http://www.javablog.be”);
(where the event source is an URL).
WebSockets provide a full duplex TCP connection to communicate between the browser and the server. It traverses firewalls and routers and allows authorized cross domain communication.
An example is provided below:
var myWebSocket = new WebSocket(“ws://www.websocket.org”);
The WebSocket(url) constructor takes one argument, url, which specifies the URL to which to connect. When a WebSocket object is created, the User Agent must parse this argument and verify that the URL parses without failure and has a <scheme> component whose value is either “ws” or “wss”. Only then the user agent must asynchronously establish a Web Socket connection to url.
myWebSocket.postMessage(“Hello”);
=> text based data transmission using the connection.
myWebSocket.onopen = function(evt) { }
=> The openĀ event is fired when the Web Socket connection is established.
myWebSocket.onmessage = function(evt) { }
=> The message event is fired when when data is received for a connection.
myWebSocket.onclose = function(evt) { }
=> The close event is fired when the connection is closed
myWebSocket.disconnect();
=> close the conncetion
Opera already has Server sent events, for Mozilla/Firefox there is patch available (bug 338583)
WebSockets is not yet available natively in browsers.
But fortunately for current browsers Kaazing.com provides an emulation Javascript library. (IE5.5+, Firefox 1.5, Chrome 0.2+, Safari 3.1+, Opera9+)
The Javascript only emulates the parts which are not yet implemented in a certain browser.
It can be any of the following layers: ByteSocket, Websockets, Server sent events, Cross site XML HTTP Request, XML Http Request IFrame postMessage
Martin Marinschek divided his talk in two main topics: Servlet 3.0 and JSF 2.0.
The first part of the talk showed us the new features planned for Servlet 3.0.
What follows is based on the Public Review draft.
So be sure to check if the following still applies to the final Servlet 3.0 version.
Right now the web.xml is one big configuration file. In Servlet 3.0 it’s possible to modularize it into multiple files.
These files are called “web-fragment.xml” files and they are merged together on application initialization.
Because these fragments can conflict with each other, the specification has specified rules for conflict resolution. (we could take a deeper look at this in a future blog post).
Martin also said that fragment ordering is not defined; this eg. could mean that a filter you want to be executed first may have to be repeated in multiple fragments.
A few annotations were added that you can use in your servlets:
@WebServlet
This annotation is used to define a Servlet component in a web application. The urlPatterns or the value attribute on the annotation MUST be present. (value is for 1 URL mapping, urlPatterns for multiple URL mappings)
Classes annotated with @WebServlet class MUST extend javax.servlet.http.HttpServlet class except when applied on a JAX-RS / JAX-WS endpoint.
Example:
@WebServlet(name=”MyServlet”, urlPatterns={“/foo”, “/bar”})
public class SampleUsingAnnotationAttributes extends HttpServlet{
public void doGet(HttpServletRequest req, HttpServletResponse res) {
}
}
Other optional attributes for the @WebServlet annotation are: supportAsync and asyncTimeout
@ServletFilter
This annotation is used to define a Filter in a web application. Classes annotated with @ServletFilter MUST implement javax.servlet.Filter
@InitParam
This annotation is used to specify Init Parameters for a servlet or a filter
@WebServletContextListener
The WebServletContextListener annotation is used to annotate a context listener to get events for various operations on the particular web application context.
Classes annotated with @WebServletContextListener MUST implement javax.servlet.ServletContextListener
Sometimes a filter and/or servlet is unable to complete the processing of a request without waiting for a resource or event before generating a response. For example, a servlet may need to wait for an available JDBC connection, for a response from a remote web service, for a JMS message, or for an application event, before
proceeding to generate a response. Waiting within the servlet is an inefficient operation as it is a blocking operation that consumes a thread and other limited resources. Frequently a slow resource such as a database may have many threads blocked waiting for access and can cause thread starvation and poor quality of serviceĀ for an entire web container.
Servlet 3.0 introduces the ability for asynchronous processing of requests so that the thread may return to the container and perform other tasks.
When asyncSupported is set to true in the filter/servlets annotation the application can start asynchronous
processing in a separate thread by calling the HttpServletRequest.startAsync method passing it a
reference to the request and response objects.
After I’ve played with the asynchronous requests I’ll post some code samples to Java Blog to explain how exactly it works.
In the thursday keynote at Devoxx, Mark Reinhold (from Sun) presented the new features slated for the Java 7 release. (the expected release date of Java 7 is early 2010)
One of the most important new features will be the modularization of Java SE7. Modularization is needed because both Java and the JDK have become quite big. This for example gives issues when trying to run it on smaller (mobile) devices. Cutting the JDK into modules will avoid loading unnecessary classes, which on their turn result in shorter start-up times for applications. To print a simple string “Hello world”, Java needs over 300 classes in the current version!.
A list of the other new features can be found here!
This university session given by Yves Hanoulle and Jef Cumps was covering two main topics: an introduction to Xtreme Programming and an overview of the very popular SCRUM agile methodology. In this post we delve deeper into Xtreme Programming. A detailed Scrum post will come soon.
Three loops were described where an XP team loops through endlessly: the organisational loop, the team loop and the code loop. Below we give a short introduction of the 3 loops.
The outer loop is the release loop, which interacts with the outer world, and which will let a predefined amount of requirements come in and working quality software pop out of the team regularly.
The organisational loop consists of 2 main values: close collaboration with the customer and small releases.
An XP project generally has an onsite customer who’s able to take business decisions. The technical decisions are taken by the developers.
Small releases are iterations of 2-to-4 weeks of coding work which consist of a number of finished user stories. Stories describe the requirements (high level – as the cards are not big enough to tell it all. But they enable communication with the business.) Besides that the stories are also ordered by the team in function of complexity, while the onsite customer will assign a business value. Together they’ll form the priority of taks to execute.
The fast releases allow for fast feedback cycles, allowing the customer to change direction faster if needed.
The middle loop is the team loop, which handles day to day team activities.
The idea is that the developers work in a sustainable pace and as a team.
A daily standup meeting is organized. Because it’s standing the meeting doesn’t last too long (should be max 15 minutes). Here the team talks about 3 things:
It’s very important todo it every day, for it to work well.
The inner loop is the coding loop, where two programmers, sitting side by side, produce a unit of tested code.
Pair programming, programming with two together, in the long term costs less then not doing it. Switching keyboards every 10-15minutes work best. (should not be longer then 30 minutes). One of the positive effects of pair programming is that you get instant code review and generally the code will look a lot different (read better) then if the two would have implemented the task alone.
Unit tests, are a safety net as you’ll know what is working / what’s not working. It’ll also make refactorings easier, less dangerous because of the safety net. They assure the quality of your code.
Test driven design, means writing your unit tests first. It’l make you think about the problem and how you’re going to implement the solution. As a result the design of your code will be better.
Continuous integration, is also very important for an XP project. Fast and automatic integration means that you’re project doesn’t stay stuck at 90% finished and just some integration work to finish (which you have no idea how long it’ll take). Automating everything can be a huge investment, but generally pays off in the longer term.
Collective code ownership, means anybody can change anyone’s code as long as the rules are followed. Those rules are defined by the team itself and could eg. be “tests not failing”, “no findbugs errors”, … Sometimes collective code ownership is hard but this generally indicates an underlying problem of Trust.
Acceptance tests, are defined by the proxy customer. It defines when are we done? => When all acceptance tests pass. The customer should write it just-in-time. (eg. for the next iteration when the developers are currently working on the current iteration).
That ends our little overview of Xtreme Programming. Retrospectives and Velocity we’ll leave for our coming Scrum article!
You can find the slides from this Xtreme Programming talk at Yves Hanoulle’s blog
Here are my Top picks for Devoxx 2008 University day 2:
The title of this talk is a little bit mysterious if you don’t know what Comet is about, but the content is looking very interesting.
The first part of the talk will be about HTML5 WebSockets and Server Side Events. WebSockets will enable full-duplex HTTP communication, and bring an end to the “click and wait” paradigm traditionally associated with the Web.
Attendees will also learn how WebSockets can be used to deliver information from a set of TCP-based backend services, such as Apache ActiveMQ and Jabber to a variety of clients (e.g. Java, Silverlight, and Flash) other than JavaScript.
The second half of this university session will be about deploying and scaling “real-time” Web Applications. Eg. the server and network architecture, performance requirements and scalability of a bi-directional Web application will be discussed.
Check out Jonas Jacobi’s blog for more info!
Interested in the new Google Android phone? Then you certainly should not miss this univerity session by Romain Guy.
Romain Guy, who’s now working on the UI design of the Android phones as a Google engineer, always manages to impress the crowd with cool demos and knows what it takes to design a intuitive user-interface.
(which is more important than most programmers think!)
Chet Haase, who works on animation and UI components for the Flex SDK team at Adobe Systems, will likewise describe how to achieve beautiful Filthy Rich Client applications for Flex.
I’ll be again present on Europe’s largest Java conference Javapolis Devoxx.
Here is a list of what sessions I’ll be following.
If you want to meet me let me know via my Twitter.
The agile Scrum process will be explained: its roles, its artefacts and the challenges in implementing it in an organization.
I’m especially interested in the new features in JSF2.0 and the modularization support for web applications in Servlets 3.0
Having used JFreeChart v0.9.x a few years ago, I’m looking forward to seeing the enhancements/new features in the current version.
Traditionally a difficult area to automate tests for, I’m wondering how Fit, FEST and TestNG will fare.
As a Flex developer, I’m wondering how JavaFX and Flex compare to each other.