33rd degree poland

33rd Degree 2014 — Day 2

Day 2 was in our opinion the best day of the conference. It was literally packed with strongly technical, valuable content. However, the starting talk did not promise that at all. So, let’s start!

Power to the Programmers by Tom Gilb

Have you read our day one review? If so, you have probably noticed that we didn’t like Agile Value Delivery by Tom Gilb too much.

This talk wasn’t worse but it also wasn’t better. It was actually pretty the same! The same slides, the same commentary, even the same jokes.

What’s even worse is that this talk was kinda obligatory during the second day, because there was nothing else at the same time. So if you participated in the talk during the first day, you effectively lost one talk.

So, dear organizers: please consider this for improvement next year!

Crazy and Focused by Daniel Steinberg

This talk was rather about soft skills then technical ones. Moreover, the presenter specializes in iOS development, so one could think it’s not the best choice for Java developers but nothing further from the truth! It was full of both funny and touching stuff, full of emotions and well prepared. Simply – perfectly crafted. It was one of the talks you think about even a few days after.

Here are our takeaways:

  • Business is important, but the real point is to satisfy the audience.
  • Do the work. Prepare you work environment, then just do the work.
  • Throw away your work if you are not perfectly fine with or it is not completely in the focus you want it to be. Great work is also about the work you don’t see because it didn’t met the quality-level.
  • Specify what, for whom and why are you building.
  • Be very specific about for whom the software is.
  • The mobile apps are very intimate experience. Much more intimate than desktop or web apps.
  • Like in radio: talk to one person, but touch many.
  • Don’t change the whole world. Change it for one person.
  • Ads should not be about the product itself but about what the product allows you to do.

Setting a good example by David Evans

David spoke about various specification approaches: Specification by Example (SBE), Behaviour Driven Development (BDD) or Acceptance Test-Driven Development (ATDD). The outcomes however, were quite surprising:

  • All approaches are good if they help you accomplish your goal and bad if you insist to use them even if it’s not working for you at all.
  • The goal of requirement is to give clear picture what client wants, not to give it right form at all cost.
  • Not every requirement can be presented in every spec approach – for example there is no sense to create BDD spec if client want to replace few descriptions above registration form.
  • Nobody should be forced to pick the “right way”, spec should help accomplish goals for everybody (product owners, dev team, maintenance team, support team, etc.)

We have so many different technologies, methodologies and ideas around. It feels that development is so easy nowadays that we don’t have to think, we just need to pick most popular ideas and follow simple rules. Don’t be mislead, it’s even more important now to wisely pick right tools to make the job done.

Rethinking packaging, modularization, interfaces and plugins with plain Java EE 7 by Adam Bien

Adam talked about well-known modularization-patterns and practices and discussed with the attendees in an interactive way how they can be implemented today and if some are eventually already anti-patterns nowadays:

  • Adam considers factories an anti-pattern in most of the use-cases. Nowadays it can be achieved with DI and you only need them in the exotic situtation where you have to change implementation at runtime.
  • Always having an interface for every implementation and adding “Impl” as suffix or prefixing with “I” for interfaces is an unnecessary practice. Besides it doubles the artefacts in code-base and adds unnecessary characters in the name – it is also not a speaking name of an implementation, basically it is saying nothing on “how” the interface is implemented, which is the basic idea of an interface.
  • He considers having several .war files in one .ear as overhead, actually he always tries to put everything in one deliverable and tries to include only a low number of .jar files.

Essentially he was pointing out that most of the options for modularization we don’t need at all. We should focus on solving business problems and not increase complexity of the infrastructure, unless we really need to.

Reactive Programming With Akka – Lessons Learned by Daniel Sawano and Daniel Deogun

The talk was intended for a bit more experienced Akka developers. It covered — as promised — the experience gained and lessons learned by the speakers during their adventure with Akka.

  • Which language one should use Akka with — Java or Scala? Depends on your tolerance for risk and boilerplate:
    • Complexity and boilerplate is lower in Scala.
    • You’re probably more experienced in Java, so the risk is lower.
  • Akka is perfect for parallel computations.
  • Debugging in legacy code is all about asking which value caused the issue and who created it. In actors system, you can check the value but can’t check the originating actor.
  • Getting the exceptions back from the actor that was called synchronously requires explicit error being returned.
  • Sequentially does not mean synchronously. Supervisor actor can control the process.
  • Do notuse shared state in messages!
    • Often the concurrency issues appear under heavy load, so they’re not visible while testing on developer machines.
  • Dealing with onMessage
    • onMessage(Object) — if/else hell
    • onMessage(SomeMessage) — overload onMessage in actor’s class
    • Interfaces — contracts to explicitly define behavior
  • The Receive builder from Java 8
    • Creates multiple lambdas which influences performance
    • Scala can give similar approach by traits and pattern matching
  • Actors cannot be tested as POJOs because they need to be run in actor system

Busy Java Developer’s Guide to JVM Bytecode by Ted Neward

We complained a little about first Ted’s talk, because it was not so technical. This time it was completely different. Ted’s great presentation skills were just an addition to strong technical content of this talk.

  • JVM can adjust the machine code to the possibilities of the machine it is currently running on
  • Main advantage of JVM was garbage collecting
  • JVM principles
    • Stack-based, no registers. Stack slots are 32bits wide. Longs/doubles take 2 slots. Because of that, it’s possible to get a concurrency issue with doubles and longs.
  • The first 4 bytes of every Java class file has the magic value of 0xCAFEBABE.
  • Constants go to the constant pool so they can be eventually reused.
  • JVM considers „newing” the object a different operation than calling the constructor.
  • Bytecode details:
    • Invokespecial – invokes a specific method without taking virtual tables/polymorphism into account
    • Exceptions handling: exceptions table and GO TO instructions
  • LineNumberTable is for displaying nice stack traces. It was introduced so more terse languages, like Groovy, could display proper line numbers in stack traces.
  • Class file format is described in specification. Changing it would be a big deal.
  • Inner class introduces a hole so you can access the private properties from Groovy, Closure, Scala.

Exploring Nashorn by Venkat Subramaniam

This talk was strictly technical. Venkat was showing pieces of code presenting Nashorn possibilities. Of course, the Venkat’s presenting style on its own would make this presentation awesome :)

Here are a few takeaways, though:

  • Nashorn allows to run JavaScript code from within Java code and the other way around — Java from JavaScript
  • EmbeddedJS
    • ScriptEngine.eval(...); Input could be a file or a string
    • Can accept values returned from JS
    • Invocable, invokeFunction() can be used to run JS function from Java
    • Invocable.getInterface(Class) binds JS implementation to Java interface, so the JS code can be used seamlessly.
  • Running Java from JS
    • To run Java code from JS, you have to include jar/class on classpath of Nashorn.
    • The JS code is compiled to Java byte code
    • By default, all references to Java types need to be fully qualified.
      • The solution is to use JavaImporter, ex. new JavaImporter(java.io).
      • or… var JString = java.lang.String;
    • Overloading works despite JS doesn’t have it.
      • There is a way to enforce a particular method usage — ex. ['valueOf(double)'](5)

Gerrit Code Review or Github’s fork and pull? Take both! by Luca Milanesio

This talk was mostly about presenting Gerrit and comparing it with GitHub. Luca appeared to be very nice presenter. He did a great job presenting Gerrit and wasn’t scared off even by broken microphone :) The talk and product itself was so good that we decided to give Gerrit a try in our day-to-day work!

  • GitHub makes your project visible. It’s fun to collaborate there.
  • However, the GitHub problem are many forks (pull requests based approach)
    • Jenkins team asks not to create new pull requests because there are too many of them and they can’t really manage them
  • Gerrit tries to avoid throwing commits over the fence: „I’ve created pull request, now it’s up to you”
  • Gerrit tries to connect advantages of both, because it integrates with GitHub nicely, i.e. it syncs back to it, however it protects from unmerged forks ocean.

JavaScript Design Patterns by Pratik Patel

JavaScript Design Patterns was the last one for us during the day two of 33rd Degree 2014. We all were kinda tired but Pratik managed to put yet another spark of life in all of us. Kudos for that :)

The talk itself was really good prepared. Although we were familiar with most of those concepts, the way they were presented really helped to neaten them in our heads.

Actually, it was kinda similar with the last talk of day one… Maybe it’s kinda Conference Design Pattern to schedule recap talks for the end of the day :)

Here are main points we want to point out:

  • Namespaces are objects. Beware of memory issues.
    • You cannot expose properties in immediate function call result
    • DI substitute is passing object into immediate function call
  • PubSub pattern in Backbone. Also trigger/on in jQuery.
    • Only one context, one browser tab
  • Command pattern
    • with Class[function].apply(Class, paramsArray);
    • can also be used to mock AOP
    • is used in frameworks like Backbone to set properties on domain objects
  • Backbone.Model.extend is Factory pattern implementation
  • Better to use mixins and other technics than prototyping inheritance
  • JS does not use MVC broadly
    • MVVM – model, view, view model; MVP – model, view, presenter
  • JS is single threaded and asynchronous in its nature
  • http://todomvc.com shows how to implement the same app — TODO list — using different JS frameworks and approaches.
/by