Last day of Devoxx France 2012! Waking up was not so easy, I had to drink a coffee to get me going (and I never do).
Trends in mobile application development by Greg Truty
I didn’t take notes on this one because my computer rebooted 🙃
Mobile is becoming strategic to the business: it’s beginning to be the equivalent to CRM, portals, and such other assets.
On the development side, mobile development is akin to traditional development. There are a couple of differences however: development cycles are very short (weeks) because time-to-market is very quick, hardware manufacturers release more often leading to a very fragmented market and we are back to client server architectures.
- Native applications require a full new set of skills in the enterprise. The fragmentation enforce to target specific platforms and to forget others. Other requirements are creeping in (security, scalability, integration in the enterprise architecture, …).
- Another approach would be to take the standard web route; actually, familiarity is here and experience is already available on this subject. Unfortunately, we cannot leverage platform native capabilities.
- The best of both worlds come in the form of hybrid approach, with tools coming from Apache Cordova (formerly PhoneGap). In this case, the only disadvantage comes from slower performance than native applications (sometimes, at least).
- Finally, what if we could write to a common API and then compile to each platform to produce native applications? This is the cross-platform programming models. We get help from appceletator and its kind here.
IBM recently acquired Worklight, a framework to address all the previous strategies, and also deal with security, SSO, integration in so on. Worklight provides a IDE, a server, runtime components and a web-based console to monitor mobile applications and infrastructure.
The guy is not bad, there’s some interesting info, but a sales pitch at 9 in the morning makes me regret not to have stayed later in bed.
Portrait of the developer in "The Artist" by Patrick Chanezon
The story is about George, a JavaEE developer that work for top companies. Anyway, after 3 years work, the AZERTY project is put into production: GUI is bad, the IT director is happy, users hate it. George is happy, he loves complexity and nobody understand how the system work, save him. George is promoted Project manager, then Project Director. One day, when George go into a OSS meeting, he hears new terms: Hibernate, agility, and such. Yet, instead learning those new techs, he learns golf and code no more. Since he now has budget, he brings in agile coachs into his company: it fails abismally. Finally, he becomes IT director… Users reject his new project AZERTY 3.0 and users use Google Apps behind his back. His boss now demands iPhone and Android applications for. He cannot code it and is finally fired.
What happened while George learned to play golf? The last 2 years saw a paradigm shift that happens every 15 years:
- in 60’s, there were mainframes (server-side)
- in 80’s, it was client-server architecture
- in 90’s the web put everything on the server-side again
- In 2010, it’s the Cloud, HTML5 and mobile; it feels like we put things back into the client again
Standards analyst segregate Cloud into Saas, PaaS and IaaS as a pyramid. For developers, PaaS is the most important, which is something alike to the operating system. The trend is now Developing as a Service. Interestingly enough, though platforms become more industrialized, software development moves toward craftmanship.
Historically speaking, Cloud began at consumer websites solving their own needs (like Google, Amazon, and others). Nowadays, IaaS is becoming mainstream, but you still need to build and maintain your own software infrastructure. For example, when Amazon failed last year, 3 startups survived the outage, those that built their own platform.
The software development process is about to change. Business-to-consumer applications are becoming like haute couture, with new applications coming in everyday. Some applications have even short life expectancy (like Devoxx France application). Thus, development cycles have to be shortened in parallel, hence Agility. Cloud let us become more agile, by cutting us off from infrastructure.
The main risk of Cloud infrastructure is the vendor lock-in. Cloud Foundry resolves the problem by providing an Open Source product. For example, AppFog uses Cloud Foundry and added PHP. Likewise, you can create you own private cloud to host it on your own infrastructure.
There are a couple of things to learn from that:
- Software is becoming like fashion, design rules
- Use the best tool for the task at hand
- Learn, learn, learn!
In conclusion, George buys an iPhone, codes a little bit everyday, read programming books and is happy again! Besides, he stopped playing golf. The rest is up to you…
Wow, the man is really good, as well as the session. If you missed the keynote, see it on Parleys ASAP.
Abstraction Distractions for France by Neal Ford
As developers we think about abstractions, because if there weren’t any, we would have to deal with 0 and 1 and we couldn’t get anything done. And yet, by using abstractions, we sometimes forget they are only abstractions, and tend to consider them as the real thing.
Let’s take a simple document. How can you ensure that a Chocolate Cake Recipe could be saved for hundred years? Put it in a Word document? Probably not… Getting to text format would be better, but raises encoding issues. If you’re a government agency, stakes are higher. The goal is not to save the document, but the information.
For example, emacs tapes are still available, but there’s nothing to read them.
[Other fun examples are omitted because I couldn’t type fast enough and the whole thing is based on pictures]
- Lesson #1, don’t mistake the abstraction for the real thing
- Lesson #2, understand 1 level down your usual abstraction
- Lesson #3, once internalized, abstractions are very hard to cut off
- Lesson #4, abstractions are both walls and prisons
- Lesson #5, don’t name things that expose underlying details
- Lesson #6, good APIS are not merely high-level or low-level, they are both at once
- Lesson #7, generalize the 80% cases, and get away from the rest
- Lesson #8, don’t be distracted by your abstractions
Dietzler’s law: using a tool like Acces (or nay contextual tool), 80% of what the user wants is very easy, 10% is hard to implement and the last 10% cannot be achieved because you have to go beyond the abstraction and that cannot be done.
Any tool (like Maven), has a tipping point. Because once you’ve gone beyond that, it will never ever be wonderful again. At this time, you’ve got to cut and run but it will be hard because you’ll be imprisoned by the abstraction.
Wow! I missed Neal’s session on the first day and I regretted it at the time. Now, I regret it even more. The previous keynote raised the bar very high, Neal passed it with flying colors. Anyone wanting a real show (with content to boot) should attend Neal’s session given the chance. Besides, you could even get his wife’s Chocolate Cake recipe 🙂
Kotlin, by Dmitry Jemerov
New languages seem to bloom every so often, but the last year so announcements from enterprises (Red Hat’s Ceylon, JetBrains’s Kotlin and Google’s Dart). Here’s my chance to have a talk from someone very close to one of Kotlin’s inception.
JetBrain’s motto is develop with pleasure. There are other products beside IntelliJ’s IDEA (TeamCity, PHPStorm, and others). Kotlin is: statically typed, running on the JVM, OSS and developed by JetBrains with help from the community. Why Kotlin? Because IntelliJ’s IDEA is based on Java and though it’s not the best fit, other languages are not better.
- Full Java interoperability
- compile and runtime as fast as Java
- more concise than Java, but preventing more kinds of errors (such as NPE)
- simple (no PhD level)
Performance are to be found in different areas: no autoboxing, no constant runtime overhead in generated code and a low compilation time. Kotlin is easy to learn; there’s no distinction between libray devlopers and 'standard' developers (as in Scala). It focuses on best practices taken from other languages. This leads to no ground-breaking features, only common sense.
[Follow a bunch of code snippets]
At first, it seems akin to Scala with
def: there are Scala-like constructors, vals and vars, traits, reversed-order type/name declaration (separated by double colons)
Extension functions seem nice enough: you can not only extend types, but also functions without bothering to inherit the whole nine yards. Also, in Kotlin, functions are first-class citizens (in short, you get closures with type inference). Interestingly enough,
it is by default the first argument of the function literal (as in Groovy).
An interesting feature of Kotlin is the usage of the
dollar sign to reference variable inside Strings, so as to have variable replacement at runtime.
There’s a limited form of operator overloading: only a subset of operators are available to be overloaded, as it needs to be done through a specifically-defined function. For example, to overload the
-, you need to ovveride the
In order to manage nullability, Kotlin allows the
? operator to only allow safe calls (as to Groovy again). For example, the following snippet returns the list size or 0 if the list is
f.listFiles()?.size() ?: 0
The question mark marks the return type as nullable, otherwise, it’s not nullable and the compiler complains; it makes the core more concise as well as provide as safety net for handling
Kotlin also provides pattern matching (as in Scala, the syntax being very similar). An improvement over Groovy’s builders, Kotlin’s are typesafe: for example, the HTML builder checks for validity at compile-time!
More features include:
- Inline functions
- First-class delegation rendering delegation easier with no code to write, it’s taken care of by the compiler
- Modularization as part of the language
- Declaration site variance [???]
- And more to come [This frightens me to no end, what will happen to backward compatibility]
Not an uninteresting talk, but there was some passion lacking in the speaker. The get-what-works-from-other-languages strategy is a very interesting one. At least, you get the best of many world out-of-the-box. I see a big problem however, how does JetBrains plan to ensure backwards compatibility if they get their critical mass. The answer from the speaker is:
JetBrains intends to allow for compiler extensions.
Food for your thoughts (directly from the speaker): if JetBrains had known that Ceylon was being developed, it probably wouldn’t have started the project.
OK, I’m a bit of a masochist considering the presales talk from IBM, but I’m really interested in GUI and perhaps JavaFX next version is the right one (considering Flex’s fate).
The talk begins by the speaker asking to remove all misconceptions about JavaFX (good idea). JavaFX is a complement of Swing, SWT and HTML5. On Android and iOS, it works! The last addition to the JavaFX ecosystem is JavaFX scene builder.
JavaFX goals were to achieve:
- a client API
- a modular architecture (both for mobile and embedded)
- a migration solution for UI in Java (since Swing has more than 10 years)
- advanced development tooling
- a cross-platform solution (across both OS and hardware type)
JavaFX 1.0 receveid a bad feedback from the developers, they didn’t want to learn a new scripting language. Current version is JavaFX, available since 2011 on Windows (Mac OS and Linux are nearing GA completion). On the tooling side, NetBeans 7.1, 7.2 and Scene builder are provided. The community has already taken care of some integration plugins in Eclipse, while JetBrains has made contact to integrate JavaFX development in IntelliJ IDEA.
Currently achieved goals include: inclusion in the OpenJDK (through OpenJFX) and a common license with JDK. For the latter, note that JavaFX will be part of JavaSE from JDK 8. Oracle policy is to submit JSR to the JCP for standardization.
Swing and SWT can be gradually migrated to JavaFX, through seamless integration of the latter in the existing UI. A big difference with Swing/SWT is the ability to use CSS to style your JavaFX components, hence you can reuse the same stylesheet on the web and on JavaFX. As a sidenote, there’s an already existing community around OpenJFX. Other contributions include Eclipse and OSGi plugins, DataFX (datasource access), ScalaFX and GroovyFX, frameworks (already!) and JFXtras (additional UI controls and extensions).
Last week, the JavaFX Scene Builder release was announced. It’s a visual development tool for GUI; drag-and-drop is supported. Integration with NetBeans comes out of the box, but it can be used with other IDE (since it’s a standalone tool). It’s entirely developed in JavaFX and available for Mac OS X and Windows.
The roadmap is the following:
- End 2012, JavaFX 2.0.1 bundled with JDK 7
- First quarter 2012, JavaFX 2.1 GA for Windows (Linux in beta)
- Mid-2012, GA for all OS
- Mid-2013, JavaFX 3.0 included in the JDK 8
[Talk ends with both a 3-tier demo, with the GUI developed in JavaFX with CSS and Scene Builder demonstrating Drag-and-Drop]
Mono tone speaker, I had to fight agains sleep. On a more positive note, this wasn’t a sales pitch but there were some interesting pieces of information. The speaker also presented an iPad running a JavaFX using the hardware accelerometer.
Java caching with Guava by Charles Fry
The session is about the inner workings of caching. Guava is an OSS of low level Java librarires. The package
com.google.common.cache contains simpel caching.
LoadingCache automatically loads entries when a cache miss occurs, while
Cache doesn’t. The delegate
CacheLoader interface knows how to load entries.
Concurrency is internally handled very similarly to
ConcurrentHashMap. In the case of exceptions occuring during load, you have to catch runime exceptions and rethrow checked
IOException. For keys that are transient, a fluent
weakKeys() method on the builder allow for weak references. In contract, to allow the garbage collector to collect cached values, the
softKeys() method is used (there have been performance issues however, this use is discouraged).
- To allow for cache eviction, the cache builder can be set a maximum size; entries will be evicted in approximage LRU order (evictions occur on write operations).
- Alternatively, if the eviction strategy is based on weight, a
Weighterinterface let specify the weight computation and is passed around while building the cache loader. In this case, the eviction is exactly the same.
- Another strategy would be time to idle, it’s achieved by
expireAfterAccess()method on the builder
- Finally, time to live eviction strategy is provided by
expireAfterWrite()method on the builder
The next step is to be able to analyze cache: just use the
recordStats() method. A
CacheStats is returned by the
stats() method on the cache object and allows for querying. Having analyzed the cache, it’s now possible to tweak the configuration: you have to create a string containing key-value pairs and pass this to the builder.
Guava also provides an event-listener model around the cache. Builders allow for listener registration through the
removalListener that takes
RemovalListener instance as a parameter. Of course, you can have multiple listeners by registering more than one object. The listener is called whenever an entry is evicted, whichever the stragegy used. By default, listeners are called synchronously: it’s advised to make listeners asynchronous if they are heavyweight (or wrap them inside
Guava also provides two different ways for refreshing the cache:
- manual refresh by calling the
reload()method on the cache which can be implemented asynchronously
- automatic refresh by calling the
refreshAfterWrite()method on the builder
Asynchronous refresh shall be implemented to avoid blocking user thread. Just use Java’s
Sometimes, it’s more efficient for a cache loader to load a set of entries at the same time than one at a time. This is accomplished by overriding
LoadingCache.getAll(). The latter does not block multiple requests for the same key.
So far, cache is fed by the cache loader. However, how can we handle specific use-cases to manually populate the cache? This is simply done with
ifPresent() to query if a key is present and
put() to put an entry in the cache.
In order to implement non-loading caches, we don’t need
CacheLoader at all. When calling
CacheBuilder.build(), you get one such cache. In order to disable caching, the current canonical way is to set the
maximumSize to 0. This can be done at runtime through
Caches can be iterated over like maps with
ConcurrentMap write operations are implemented, but it’s discouraged to use them (use
CacheLoader or a
Future instead). Be warned that both
get() methods have similar signatures but they are different (
Map.get() is in fact a "get if present").
Future works include:
CacheBuilder.withBackingCache()to provide cache layering (such as L1 + L2)
- Performance optimizations
A very nice talk. 'Nuff said. A bit disappointed by the lack of knowledge of the Guava team in the Java Caching API though (a JSR).
.Net for the Java developer, an inspiration by Cyrille Martraire and Rui Carvalho
This talks is about what’s .Net and what’s lacking in Java?
For a Java developer, .Net was something akin to the blue skin of death. From a more rational point of view, let’s remember at first that Sun and Microsoft were neighbors at first.
- Sun created a superb tool named Java, and thought about putting into Mosaic (those were applets)
- Microsoft responded with its own alternative, ActiveX. And to go beyond that, it added the ActiveX Server Pages (ASP) to generate HTML pages dynamically
- Sun answered with the JavaEE platform.
- Disappointed with Sun’s success, Microsoft delivered .Net in turn
Remarkably, Sun took a very long time to ship Java 5. The .Net framework matched Java’s features in version 2.0 and soon went beyond them. .Net principles are exactly the same; only some coding standards are somewhat different. .Net is polyglot from the start (C=, Iron Ruby, Iron Python, F=, …). In order to seduce C++ programmers, Microsoft provided low-level API.
Some features are really better in C= than in Java (or more precisely, already available):
yieldkeyword let us avoid creating temporary collections when working to return such a result
- Ranges are provided through the
- Functions are first class citizens and inline functions are possible (lambdas, and guess what, the operator
⇒). Moreover, lambdas parameters are statically-typed; hence we can create fluent API
- C# provides anonymous objects while Java make us create new types although we only have the need in a single place
- LINQ is a DSL that is a SQL look-alike
- With C# 4, dynamics let developers is a special extensible type (not a dynamic proxy) [I confess I didn’t understand all of this, apart from the benefit to not create data structure when there’s no need]
- Razor is a hybrid syntax between HTML and C#
On the portable side, the Apache Mono project let developers program in and deploy on Linux and Mac OS X. Still, in order to maximize decoupling, do not forget to use proprietary products (SQL Server for example). Though .Net is seen as autocratic, alternative communities exist, such as Alt.Net.
As a conclusion, here are some messages:
- Do not forget the Java is not the JVM, Look to other languages while keeping your environment
- The language is only a small part of development; developers share more (patterns, GUI, xDD, etc.)
A definitely good presentation on the benefits brought by looking over the gap, thanks to the well-oiled tongue-in-cheek exchanges between the two speakers (real pleasant teamwork, guys).
And it is the end of the Devoxx Fr 2012. See you next year, guys and thanks to all for all the great time there.