-- the last evening was a little hard on me, shall we say. I begin the day at noon, which suits me just fine --
Securing the client-side by Mike West
If you want the largest possible audience, chances are you’ll use HTML, JavaScript and CSS. Native hasn’t (yet) the same traction as those traditional technologies. Business logic is slowly moving from those big backends toward browsers.
A prerequisite to anything is to send data securely, using HTTPS. There’s no reason today not to use HTTPS. In fact, getting to a server, you’ll probably hop from server to server until you get to your target. Now, if someone gets in the middle, you’re basically toast. Using HTTP, there’s no way to detect the data. On the contrary, using HTTPS, you can prevent reading and writing data until it gets to the server (and back to you).
However, servers should still listen to HTTP - because most users type HTTP, but then redirect to HTTPS.
There a HTTP header Strict-Transport-Security.
If you want to develop an application, got to https://startssl.com/ and get SSL certificates.
The most common security attack is script injection. Even you can write begign scripts, most scripts will have worse effects such as accessing cookies. Browsers normally disallow accessing cookies from other domains, but XSS exactly bypass that. The biggest problem is that users are not aware of this. A XSS cheatsheet is available at OWASP but in essence, in order to defend against XSS, you have to both verify each input and escape output.
Fortunately, both problems are resolved since ages. Developers just have to know about solutions considering the languages and frameworks they’re using. Unfortunately, developers may make mistakes, and browsers may contain bugs. Therefore:
Every program an every priviled user of the systle shoule operate using the least amount of privilege necessary to complete the job
HTML has a thing called Content Security Policy, which is a W3C specification (currently under draft). It takes the form of a HTTP header and specify valid external resources. Resources not specified won’t be loaded by the browser, as the latter would assume they were injected by scripts. Currently, CSP 1.0 is implemented in Chrome and Firefox. The main security hole in XSS are inline scripts: in order to prevent them, CSP disallow inline JavaScript, including declarations and event handlers. Note this could be seen as a downside, but both can be declared outside HTML, and remember it’s a security hole.
Alternatively, CSP also offers a Content-Security-Policy-Report-Only header, so as to send reporting to a URL.
This lets you have a loose CSP policy and a stricter CSP policy report so you can test the scricter one before deploying it.
HTML Rocks tutorial is a a good source of info to setup security policy.
Another way to protect against XSS is to use sandboxing.
sandbox is an attribute to apply to iframe.
It works by putting this iframe into a unique domain origin.
This has some major consequences: no plugins, no scripts, no form submissions, not top-level navigation, no popups, no autoplay, no pointer lock and no seamless iframe.
sandbox allows values to loosen some of these restrictions.
In concordance with the above 'Least privilege policy', a possible architecture is to design a page where each component is used to do a single thing. For example, we could use a sandbox to execute potentially dangerous scripts and wraps it under a simple message API to get its results from the main page.
Home automation for Geeks by Kai Kreuzer and Thomas Eichstädt-Engelen
-- given my initial education as an architect, I’m due bridging the gap between it and my current job --
The talk if about fun stuff you can do with Java.
Home automation is not just electrifying things, because they’re already! Point is, none of these systems are integrated in anyway: home automation have to put emphasize on integration. There are 3 goals of home automation:
- Comfort
- Security (motion sensors, window contacts, etc.)
- Energy saving (cut power off, etc.)
To create a smart home, you’ll need smart devices, to manage your home or to visualize data. Many of these features are already avaialble in the openHAB project. The project consists of two parts, the openHAB runtime, which is a headless Java running on the JVM and a designer which is used to configure the former. Both communicate either through a Samba share folde or Dropbox.
The runtime is composed of:
- Java 7
- OSGi (Equinox variety)
- Declarative services
- EMF
- and an Embedded Jetty, with JAX-RS and Atmosphere
Core concepts around opneHAB include items: they are high-level abstractions that basically represent things you want to control. Note that devices aren’t the right level of abstraction. As an example, a radio device could be composed of a switch item, a dimmer item and a number item.
openHAB’s architecture is a simple Event Bus, with bindings between commands (to the item) and status update (from the item) events and the real-life device. An item registry is plugged into the bus, so as to have both an UI and some automation rules, as well as a console and a persistence layer. There are a couple of UIs available: web of course, native for Windows Mobile, Android and iOS.
openHAB offers many different bindings over devices, but also integrates with XMPP, OSGi and Google Calendar. The latter is very important since you can create your triggers through Google Calendar. Other features include database services and export capabilities (Sense, Cosm).
-- a real-life demon starts, taking a Koubachi plant device and a doorbell as examples --
A demo server is available at demo.openHAB.org
Behavior-Driven Development on the JVM, a state of the union by John Ferguson Smart
-- if you’ve read Specifications by Example, this one is a must --
BDD has many defnite benefits such as less bugs and more productivity but was is BDD anyway? In essence, BDD is making Business, Business Analysts, Developers and Testers talk a common language. There are no tests in BDD, there are executable specifications. In TDD, you test what your code does, while in BDD, you test what your code should do in accordance to the specifications.
Effectively, executable specifications are not only specifications, but also tests and documentation. Givent that, every line you’re writing should be linked to a line in the speficications: this means you do not code at the micro-level, but at the macro-level. As a consequence, every line you code has a value to the business. In summary, using BDD will:
- build only features that add real value
- result in less wasted effort (through traceability)
- improve communication
- get a higher quality, better tested product
How to apply BDD to Business Analyst
A typical application will probably have some goals, each being decomposed into capabilities, features, stories down to examples, each one being translated into acceptance criteria. The main point of this is to be able to trace each criterion up.
- Goal
-
The question to ask the customer what he really needs and keep asking why until you attain a high-level goal. Standard users tend to express requirements as implementations: we need to find the business need behind the suggested naive implementation.
- Capability/feature
-
Those help reach the goals defined above. Which features do you do first? We should implement the minimum features required to deliver the business value defined in the goal. Traditionally, using the triplet "IN ORDER", "AS A" and "I WANT".
- Story
-
The story takes the role of the user and describes, guess what, a user story as Agile defines it.
Tools to code
Available tools include JBehave, Cucumber, easyb and Thucydides, which does the job of reporting from the other tools.
Remember that TDD tools include JUnit, Mockito, Spock and Arquillian. While BDD is about acceptance tests, TDD is about developer tests (unit- and integration-). -- I tend to think that high-level integration tests begin to approach user-acceptance tests --
The speaker uses Spock as a TDD testing framework, because it respects the Given/When/Then BDD structure. As a bonus, you can mock (and stub) needed dependencies very easily as well as code data-driven tests in a tabular way. Finally, Spock can be integrated with Arquillian. Alternatively, if you’re a Scala fan, BDD2 is the framework to use. Finally, for JavaScript, Jasmine is available.
In conclusion, it’s behavior all the way down.
Using Spring in Scala by Arjen Poutsma
The goal of the session is to see how to use Spring in the Scala language.
-- Since the session is very based on demo, I encourage the reader to go directly to the Spring Scala project --
Effective Scala by Josh Suereth
- Basics
- Use expressions instead of statements.
Telling the computer what to do is a statement: create a variable, set its value and return the variable.
In Scala, the last computed value is the returned value.
Note that
match,ifand others return values. Likewise, Scalaforexpressions let you just tell what you want, not how you want it! - Use the REPL (the Scala command-line evaluator). The good thing about REPL is that you’re not only shown the type of the variables you create, there’s auto-completion, so it’s a great way to find what exists. It’s a good practice to start with the REPL, then test, then code.
- Just stay immutable. In Java, keeping references on mutable collections is a very dangerous thing to do, so you’ll have to copy them before storing/exposing them. In this case, you’ll endure a very big decrease in performance. In Scala, `case`classes with constructor "injection" make it simpler to implement immutability. Additionally, you’ll get automatic equality and hashcode for free.However, remember that local immutability is ok, that is it’s ok as long as you don’t expose your mutable variable.
- Use
Option. In Java, you’ll have to check whether every used parameter is null and you’d better not forget one! In Scala,forexpressions can be used to easily perform checks and yield the desiredOptionresult.
- Use expressions instead of statements.
Telling the computer what to do is a statement: create a variable, set its value and return the variable.
In Scala, the last computed value is the returned value.
Note that
- Object-orientation
- Use
deffor abstract members. Given the way memory allocation works on the JVM, we have to do either declare a block or use adef. Since the former is an advanced technique, use the latter. Addtionally, you can use the same def names in case classes. - Annotate API on non trivial return type. Since the compiler does type inference, you may run into complex cases where the type you infer is not the type the compiler does. Do document!
- Favor composition over inheritance. -- See the famed Cake pattern --
- Use
- Implicits
- Implicits are used when you need to provide a default parameter in a function but let the caller decide which default he wants to use (as opposed to default value in parameters).
- Implicits are found when "in scope". Scope computation follow a strict (-- but complex --)search pattern. A good thing to do is to avoid imports, since it’s not explicit that importing will trigger the implicit. Thus, it’s best to put implicit in companion objects.
- Implicit views. Don’t use implicit view, whatever they are, in favor in implicit classes.
- Types
- Types traits. A best practice is to provide typed traits.
- Type class. There’re several benefits to using type class, most importantly to monkey patch classes you don’t control.
- Misc
- Scala isn’t Java (nor Haskell). Learn to write Scala, don’t write it as the language(s) you know.
- Know your collections!
Traversables are at the root of the collections hierarchy.
Iterables comes next, etc.
Indexed sequences are good to use when you need to access an element by their index, linear sequences when you need to access by head/tail.
So, if coming from Java and wanting index access, use
Vectorinstead ofList. - Java integration. Prefer Java primitives in API
- Learn patterns from FP.
Vaadin meetup with Joonas Lehtinen and the Vaadin team
Escalante, Scala-based Application Server
Escalante is an attempt of JBoss to create a Scala Application Server. Scaladin is a Scala wrapper around the Vaadin API, provided as a add-on. Lift, the Scala web framework, has very fat dependencies: Escalate prevents you from having to deploy the Lift JAR in your Lift-dependent webapps.
mGWT
GWT goes mobile, with mGWT and GWT Phonegap. mGWT supports major mobile browsers, including iOS, Android etc. The only major difference, is that you get it on the web instead of an app store. Web performance is an importante topic: compiling makes it easier, only you have to think about some things. For example, startup performance is composed of downloading, evaluating and executing. -- see the talk about web performance --
JavaScript optimizations is hard to do by hand, and thus most websites don’t do them. On the contrary, the GWT compiler enforces those good practices (e.g. caching). Moreover, GWT let you do things really not possible otherwise, as componentizing parts of your application. Also, GWT can generate the offline manifest of HTML5 app cache. By comparison, GWT applications are much smaller, because of choices made by Google engineers: for example, there’s no image in the iOS theme, only pure CSS. Another axis of optimization is the minimal output (as for CSS). Finally, only the stuff actually used is in your final application: it’s called Dead Code Removal. In essence, only Android theme is downloaded by an application running on an Android device.
In the area of runtime performance, lets consider layout. Doing layout in JavaScript requires time! A rule is never to leave native code, in our case the CSS rendering engine. Well, mGWT uses CSS3 to layout the page. if we consider animations, looping in JavaScript is also a pretty bad idea. The solution is the same, just use CSS, which will use GPU acceleration.
SASS theming in Vaadin 7
SASS is a CSS compiler so think of it as a "GWT for CSS". CSS should be easy, but it’s not for real-life applications and general-purpose themes. You want to do it the right way, because it’s gonna be there for a long-time. CSS support in IDE (Eclipse for example) is crap: there’s only auto-complication. Point is, CSS is hard to maintain with a team of more than one person (and even for a single person, it can be tedious - to say the least). On the other hand, a maintainable code structure - imports, kill startup performance because it will require an HTTP request per CSS. SASS can help in these areas.
For example, you can split your CSS file into smaller ones but SASS will concatenate them into a single one. Morevoer, URL paths for images in the CSS can be resolved automatically. -- the rest of the presentation presents SASS features; you can have a look at an introduction there or check the full SASS documentation --
The Vaadin team has developed its own SASS compiler in Java, since the original implentation is Ruby-based and we didn’t want any Ruby dependency in our apps, did we?
Besides SASS support, Vaadin 7 also offers a way to completely remove the default style name of a component through the setPrimaryStyleName() instead of being only able to add additional CSS class names.
In combination to SASS mixins, this let you combine parts of different themes.
Important: SASS support is under active development, test and do provide feedback!
Usability in Vaadin
-- Faros, a Vaadin solution partner created the Vaadin Belgian meetup group --
Usability is a huge topic, point is a good interface should be self-explanatory.
Usability is defined as how it’s easy to accomplish a give task while accessibility is ensuring an equivalent user experience for people with disabilities (blindness, in most cases).
Default Vaadin theming doesn’t render buttons as HTML buttons but as div, screenreaders cannot recognize them as such.
Moreover, as Vaadin AJAX requests update the UI, it can really throw screenreaders off.
WAI-ARIA is a standard to define how to make RIA accessible.
In order to achieve this, it defines standard roles such as navigation menus, or buttons, even though it’s not a real HTML button.
WAI-ARIA is on the roadmap, but has been frozen due to time constraints.
Still, there’s already support for keyboard and shortcut keys.
Button button = new Button("OK");
button.setClickShortcut(KeyCode.ENTER);A good practice is also to provide screen units in relative size, so that users can increase the font size on their browsers.
Vaadin 7 and what’s next
Vaadin 7 is in beta 8 status. The decision is to deliver when it’s ready, so as not to decrease quality: it should be RC in December. Version 7 is a real major release, with huge core rewrites. Goals included empowering developers, embracing extendability and cleaning up (web is the only supported platform).
After Vaadin 7, the roadmap is not decided yet… The biggest mistake is some things were announced with Vaadin 7, and too many couldn’t be released. Therefore, there’s no plan for Vaadin 8. However, version 7.1 is planned for February 2013 and will include:
- Built-in push channel
- New them that puts SASS to full use
- Start adding client-side APIS to some (few) Vaadin widgets.
Version 7.2 will be more focused towards (client) widgets. For most of the cases, it’s wiser to use (server) components, but in some cases, there’s need for widgets (offline for example). Table and combo-boxes will be redesigned since support outside GWT will be dropped. The target will be summer 2013.
Other non-planned improvements include:
- Declarative XML-based UIs, mix HTML in UI declarations and integrate with JPS, as well as taglibs, and mix-match them with XML
- Better IDE tooling: add-ons support, full-theme support and declarative UI editing mode for Visual Editor
- Book of Vaadin covering v7 is expected in January
- WAI-ARIA
- On the fly translations for UI
- Comprehensive charting library, based on HighCharts and available with a Vaadin Pro Account
- Java EE 6 CDI with Vaadin (support for injecting UIs and views), the work in progress is available on GitHub
-- nighty night, folks, it’s more that 10 PM --