33rd degree poland

33rd Degree 2014 — Day 1

On June, 9th — 11th, 2014 we were attending 33rd Degree conference in Cracow, Poland.

In this series of posts, we’ll share our thoughts on the conference and particular talks. Besides, we’re going to point out the most interesting parts of the talks, something that inspired us or is valuable from our point of view. Hopefully, it’ll be valuable for others too. Let’s start then!

Managers are from Mars, Developers are from Venus by Ted Neward

Ted is a great speaker. He was actually more like an actor this time. The talk was extremely entertaining and covered many interesting ideas. However, what I was actually missing was the conclusion. It left us with the feeling all the pieces don’t really fit together. Still, the pieces were really interesting and thought-provoking.

Here’s the list of the most important ones in our opinion:

  • Motivation disappears if there is too much control over the process
  • Mission statements are bullshit. Some of them can even be computer-generated
  • Frederick Winslow Taylor created the Scientific Management theory:
    • There is a perfect man for any given job
    • Focus on per-bar not per-hour — people will start to do their best if their are paid for the work they do, not for the time they spend on it
    • Taylor made most of it up! Actually research discovered that in the companies where Taylor applied his model no actual benefit was seen at all, still it is supposed to be at the very basis of what you are taught in Harvard.
  • The problem is we’re trying to force people to think the way we think
    • The perfect example is „Are you sure?” dialog. We keep adding it, because that’s the way we have been doing all the time, but they are actually annoying for users. Users tend to accept them automatically, so this is not a real protection.
    • Another example – folders structure. Most people do not care about them. They just want to save their work somewhere and get back to it later.
      • The folders structure is for us: developers, super users. User data is about 10% of all the data on a computer, so the complex hierarchy is not really needed for them.
  • There is a communication mismatch between prototyping and carefully designing an architecture because the management considers building the doghouse the same as skyscraper.
    • Eventually you know where this can lead to: “the prototype that went to production” — a ghost story for developers
  • Managers don’t have to be too creative, developers do
  • Flow appears when the challenge is big enough to keep you interested in what you’re doing, not bored, but small enough to prevent from being overwhelmed.
    • Flow is very fragile. You cannot cause sleep as you cannot cause the flow. Meetings, calls, etc. are doing great work in getting you out of the flow :)
  • Developers do the job because it is fun, not because of the money

Smoothing Out the Rough Edges of REST by Abdelmonaim Remani

We have a hard time to rate this talk. On one hand, it was good, well prepared and full of valuable information. On the other, the topic is so well-known that it’s hard to surprise the attendees. Here are our notes:

  • Nouns for resources, slashes for hierarchy
    • /users/abdel/contacts/123
  • Hoc CRUD Operations
    • GET /users/abdel/contacts/123/email?to=…
    • PUT /users/abdel/contacts/123/mark-as-favorite
    • GET because sending e-mail doesn’t modify the state, PUT because marking as favorite does
  • Paging should be done as SQL style — offset, limit
    • …or ?next=20&to-item=6783&inclusive=true
  • Ordering and sorting
    • ?order-by=popularity&sorted-as=desc
  • Filtering
    • ?filter-by=…
  • Security – HTTPS or OAuth
  • Testing – Jayway’s Rest-Assured
  • Documentation — Mashery I/O Docs

Agile Value Delivery by Tom Gilb

The presenter rushed through his slides, also skipped some of them alltogether. Much focus was on customer-success stories – so it felt a little bit like a sales event. Still he had several interesting points on how to do agile projects:

  • “Decompose” a project into technical or functional parts that can be addressed and measured throughout the project. He referred using a tree-structure like Quality > Availability, Adaptability, Usability, … (see the resources at his site for more details).
  • During a Sprint Review all people can then stress those decomposed parts of the software which as a result will stress the focus of next sprint in an agile way
  • The same holds for technical goals of the upcoming sprint – ideally there is a slot in each sprint review where the Developers figure out what to do when and how and appoint on a target measure.
  • Basis for sprint review can then be just a simple spreadsheet with goals and values for discussion
  • If the approach is adopted it is about giving the developers “rules for playing ball”, with stories like: “how long does it take an us experienced user to fill out a specific form?”. Eventually they’ll get very creative in solving business issues.
  • Another important point was the measure of technical dept. This can be done exactly the same way – measures are appointed and than discussed about. Reducing technical debt can of course be a focus in a sprint too.
  • Also the presenter mentioned that he has good experiences with a “green week” once a month for refactoring and improving the general environment.

High Performance Reactive Applications with Vert.x by Tim Fox

Tim’s talk was one of the best on the first day. Informative, technical and leading straight into the point. Also the way he used nano to write code was kinda impressive.

Here are the main features of Vert.x that were described:

  • Verticles are small pieces of code that compose the application. They are looking very similar to Akkas actors.
  • Verticles communicate through event bus. Event bus is vert.x nervous system.
  • They’re exchanging JSONs
  • Each verticle can be written in a different language. So it is a true polyglot framework.
  • Server-side verticles can communicate with client-side ones. For example residing on a web-browser as JavaScript.
  • Modules are Lego bricks of the application. They can reside in maven repositories.
  • Modules can be made executable, fat jars
  • Vert.x is IDE and build system agnostic, however you can debug and test in IDE
  • In order to use vert.x in production environments, people at JBoss already noted that they will have to work on operational features like monitoring.

Get Back in Control of Your SQL by Lukas Eder

This talk was definitely the best one on day one. Lukas did a great job, considering both soft and hard skills. What we liked the most is that he managed to introduce more advanced topics, which is not very common in presentations like this.

  • Hibernate 2 introduces 3 places to keep schema (database, Java code, XML mapping).
  • EJB 3 does the similar – keeps schema in database, POJO and annotations.
  • The real issue is to connect Java and SQL, but we’re introducing huge, complex frameworks to solve it. It’s getting harder and harder to understand and control them.
  • NoSQL tries to be an answer, but it introduces another issues. Introducing new paradigm/learning curve is most serious, especially for business people
  • ORMs don’t provide all SQL functions
  • j00Q looks very similar to SQL, so it’s easy to transform existing queries to j00Q
    • Scala version looks even more SQL-like
  • j00Q comes with built in logging and performance indicator
  • j00Q results in compilation error if the SQL is wrong in some cases (ex. Union)
  • Database interoperability
    • @Supported annotation indicates which DBMS ares supported. Some queries can also be translated.
    • Because jooQ is using AST transformations internally your SQL code is actually becoming interoperable between databases. Needed workarounds or simulations for database-specific functions like “ON DUPLICATE KEY UPDATE” will be choosen at runtime and will be eventually supported even if the underlying database did not support this feature in the first place!
  • Typesafe even with complex nested/union queries. It’s amazing that sql syntax is made for you by Java compiler.
  • Why j00Q?
    • SQL is very functional in its nature so it’s on the wave now
    • Works well with Java 8
    • Database first
    • Type safe JDBC
    • Code generation provides type safety

Where’s your Architecture? by Chris Chedgey

Unfortunately, it was probably the worst talk of the conference. It was mostly a presentation, training, not say ad, of Chris Chedgey’s product — Structure 101. It won’t be a problem if it was open source or even free. But it’s not. The product itself looks promising but it doesn’t help the situation in any way. We’d like not to have similar talks in the future or at least have them marked in some way so it’s clear what to expect.

Nevertheless, here are a few points from the presentation:

  • Architecture is real when it maps to code and is validated
  • Architecture provides modularity, phased testing and releases
  • Architecture is not code nor the directories structure
  • Complexity is driven by interdependencies
  • Dependency level grows exponentially

If you are looking for a similar free and open-source product you may want to take a look at ArchStudio.

MongoDB Schema Design by Tugdual Grall

Tugdual’s talk on MongoDB was in our TOP3 during the first day of the 33rd Degree 2014. Very informative and thought-provoking. Quite well-presented too. That’s what we expected from MongoDB introduction. The only complain we have is… baseball :) Most of the examples were based on baseball equipment and this is not very popular sport in Central Europe. Maybe it is time to think about slides localization? :)

  • Documents provide flexible schema. Each item consist of only those “columns” it actually needs.
  • Documents are kept close together on a disk.
    • Can contain arrays
    • Can contain subobjects, eliminates needs of join. Especially important, because the MongoDb is often scattered around many servers.
  • The schema depends on how we manipulate data and what is the access patterns of the application
    • One-to-many: whether we put data as subobjects or introduce a foreign key, depends on data usage patterns. If the number of “many” is handful and the max is limited, array makes sense. Otherwise, probably not.
    • Redundancy may make sense considering data usage. You can keep foreign key AND some data that are often used together with the pattern.
  • Denormalization makes sense if we consider historical reasons. Ex. the author name can change, but at the time of publishing it was fixed.

Welcome party

The welcome party was hosted by Oracle. It took place in the Tent. There were beers for all participants. It appeared that locating the beer boxes around so everyone can take what he wants was very good idea. No hurry, no hustle, just enjoying some beer with friends. Liked it!

Maybe it is good to mention The Tent itself. It was the central point of networking. The lunches were served there. Also most of the sponsors’ booths were placed there too. The idea itself was nice, but unfortunately, the weather made it a bit harder that it was supposed to be. It was around 33 degrees outside and it made staying under the tent a challenge. Well, at least we know now where the name of the conference comes from :)

/by