Jazoon 2012: Spring Data JPA – Repositories done right

4. July, 2012

Oliver Gierke presented “Spring Data JPA – Repositories done right” at the Jazoon. The motto of Spring Data could be “deleted code doesn’t contain bugs.” From the web site:

Spring Data makes it easier to build Spring-powered applications that use new data access technologies such as non-relational databases, map-reduce frameworks, and cloud based data services as well as provide improved support for relational database technologies.

Spring Data is an umbrella open source project which contains many subprojects that are specific to a given database. The projects are developed by working together with many of the companies and developers that are behind these exciting technologies.

When you use any form of JPA, you will eventually end up with DAOs which contain many boring methods: getById(), getByName(), getByWhatever(), save(), delete(). How do you like this implementation:

interface MyBaseRepository<T, ID extends Serializable> extends Repository<T, ID> {
  T findOne(ID id);
  T save(T entity);
}

interface UserRepository extends MyBaseRepository {
  User findByEmailAddress(EmailAddress emailAddress);
}

“Wait a minute,” I can hear you think, “these are just interfaces. Where is the implementation?”

That is the implementation. You can now inject those interfaces as DAOs and call the methods. Behind the scenes, Spring will generate a proxy for you that actually implements the methods. 0 lines of code for you to write for 95% of the basic DAO methods.

The queries can even be more complex:

List findByEmailAddressAndLastname(EmailAddress emailAddress, String lastname);

The method will generate SQL that searches by those two columns. See the documentation for more examples how you can write queries that use joins.

On top of that, they built a REST exporter which exposes your DAO interfaces with a REST API to a web browser plus a web front end to explore the repository, to run the queries and to create new objects. Impressive.


Jazoon 2012: Improving system development using traceability

4. July, 2012

When you develop a software, you will ask yourself these questions (quoted from here):

  • Is it still possible to accept a late change request? What would be the impact?
  • What is the overall level of completion of the system or a component?
  • Which components are ready for testing?
  • A failure occurs because the system is erroneous. What parts of the system should I check?

In his talk “Improving system development using traceability“, Ömer Gürsoy shows an approach to answer these. The idea is to trace changes end-to-end: From the idea over requirements to design, implementation, tests, bug reports and the product manual. For this to work, you’ll need to

  • Analyze
  • Document
  • Validate
  • Manage

At itemis, they developed tooling support. A plug-in for Eclipse can track changes in all kinds of sources (text documents, UML diagrams, requirement DSLs) and “keep them together”. It can answer questions like “who uses this piece of code?”

The answer will tell you where you need to look to estimate the impact of a change. That helps to avoid traps like underestimation or missing surveillance.

Today, the plug-in shows some promise but there are rough edges left. The main problem is integration with other tools. The plug-in supports extension points to add any kind of data source but that only helps if the data source is willing to share. The second problem is that it doesn’t support versioning right now. It’s on the feature list.

On the positive side, it can create dependencies from a piece of text (say a paragraph in a text file). If you edit other parts of the text file, the tool will make sure the dependency still points to the right part of the text. So you can make notes during a meeting. Afterwards, you can click on the paragraphs and link them to (new) requirements or parts of the code (like modules) that will be affected. Over time, a graph of dependencies will be created that helps you to keep track of everything that is related to some change and how it is related: Where did the request come from? Which code was changed?

Always keep in mind that tracking everything isn’t possible – it would simply too expensive today. But you can track your most important or most dangerous changes. That would give you the most bang for the buck. To do that, you must know what you must track and why.

A feature that I’d like to see is automatic discovery. Especially Java source code should be easy to analyze for dependencies.


Jazoon 2012: Software product creation

4. July, 2012

As we all know, there is no surefire way to get rich. But in his talk “Software product creation”, Robert Brazile bombed the audience with lots of useful hints how to shape the odds in your favor when you try to sell software. His focus was on the “product manager.” A product manager (PM) is the interface between customers, developers and sales. She must know:

  • Which features are important
  • And how important
  • To which customer
  • How long they will take to develop
  • What’s really going to be in the next version
  • What to tell sales
  • What to tell the customer
  • Are you selling a product or a feature?
  • The roadmap

The core tasks of a PM are:

  • Gathering data (bug reports, development points, sales figures)
  • Manage the vision for the product
  • Saying “No” to sales (because they always want to promise everything)

Since the PM is so important, one could assume she has a lot of power. This is true but all the power is indirect. She can’t control the customer. She can’t force sales to tell what she wants them to. She can tell the developers what should be in the next version but that doesn’t mean she’ll get it.

In some ways, she is also like an on-site customer: She must know exactly what each customer needs most dearly and what was promised to them. She knows all the requirements and has a clear idea how to evolve the product in the future.

She’s not sales, but must have know exactly why customers should by the product.

When supporting sales in a meeting with the customer, always undersell and over-deliver. Sales tends to promise everything in the kitchen sink (that’s what they are paid for). As PM, it’s your responsibility to build trust. Only promise features that you are 100% sure will be in the next version. There will be a lot of pressure to say “yes” (customer expectations, accusations by sales that “you’re not a team player”). Always remember: It’s hard to build trust but easy to blow it. There is no blame for being early but a lot of negative consequences for being late.

The main tools of a PM are data (a.k.a facts) and persuasion. The aim is knowledge not solutions. She knows what everyone wants but the teams must provide solutions.

To help with the process, she must aggregate the data into consumable chunks. Just don’t aggregate too much.

“Pricing is an art,” says Robert. In some cases, a higher price can make it easier to sell because cheap means “no value” in the customer’s brain. You might feel compelled to split the product so customers can pay only for what they need. On the other hand, the product should work out of the box – meaning it should have all the features, or customers might feel cheated “why do I have to pay so much for one little extra feature?”

When it comes to selling, faster almost always wins. The generation MTV can’t wait.

When it comes to features, don’t be a victim of your last conversation. Always keep the big picture in mind. Yes, some features are an incredible great idea but do they really fit into your long-term strategy? What do you win if you sell more for a few months just to end up with a product that you can’t evolve anymore?

Biggest Mistakes

  • Telling people what they want to hear
  • No Plan B. Some things will go wrong. Always consider worst cases and risks.
  • Ignoring technical debt and focusing on features only

Make Money Fast (Or Not)

4. July, 2012

There is no safe way to get rich.

Proof: There are still poor people.

How is that a proof?

If there was a simple, safe and legal way to get rich, a lot of people (= all those who know about it) would be rich. That would leave the rest (= those who don’t know) poor. But the poor would be wondering: Why am I poor?

And a some of them would eventually learn about this simple, safe and legal way to get rich and become rich, too. So over time, the number of poor people would inevitably shrink. Since it’s a safe way, the rich would stay rich. Even if they lost some money, they would just apply the scheme again to make up for the losses.

That means after a certain time, there couldn’t be any poor people left.

q.e.d.


Jazoon 2012: Agile Chartering: Energize Every Project Liftoff

4. July, 2012

In her talk “Agile Chartering: Energize Every Project Liftoff,” Diana Larsen presented approaches how you can set up your agile projects. Why is that important? When a rocket is launched into space, a lot of preparation happens to make sure the move from ground to space is smooth and successful.

Software projects often ignore this important step.

For example, it would make sense to check the commitment of team members. Commitment comes in two flavors:

  1. Yes, I want to do this
  2. … with the other members of my team

Another important question that each team member will ponder is WIIFM – What’s in it for me? Answers to these questions will have a huge impact on the success of a project.

Regulations are important but don’t forget that the human brain has a limited capacity. If you want them to follow the rules, you must restrict them to five tops.

Member Shields

Another strategy is to create “member shields” where each member writes their name on top of a shield like shape. The shield is then separated into four quadrants:

  1. Which skills to I bring into the team?
  2. What do I need to be successful in the team?
  3. What’s in it for me?
  4. Something personal. No dark secrets, just something that turns you into a person.

Write a motto below the shield.

Put those in a place where every team member can see them.

Context

Make sure that the team members know where the team fits into the organization. Post a 10’000 feet view of the company somewhere.

Risks

Agile development is all about risk management: Notice them, rate them, discuss them, act on them.

Good places to look for risks: Team boundaries and interactions: Who depends on the team’s work? On whom does the team depend? Does the team have everything it needs?

What does the team know about the future? What do we not know? What are opportunities and threats?

Remember the PAC triangle: Purpose – Alignment – Context. Every move of one corner influences the other two as well.

Also a lot of risks have their roots in VUCA:  volatilityuncertaintycomplexity and ambiguity.

Related:


Suspend Fail in openSUSE 12.1 After Upgrading KDE

29. June, 2012

When you upgrade openSUSE 12.1’s KDE 4.7 to 4.8 (using this repo), suspend to disk or ram might stop working. If so, you’ve encountered bug 758379:  STR (Suspend to RAM) fails when NetworkManager running and NFS shares mounted

The description is a bit misleading. It also happens for suspend to disk (STD) and when you don’t use NetworkManager.

Workaround: Unmount your NFS shares before you try to suspend:

sudo umount -t nfs -a

If you use NFS v4, then the command is:

sudo umount -t nfs4 -a

To check whether it worked, use this:

mount | grep nfs

This shouldn’t print anything with “type nfs” anymore. Afterwards, suspend should work.


Jazoon 2012: Divide&Conquer: Efficient Java for Multicore World

29. June, 2012

Not much new in the talk “Divide&Conquer: Efficient Java for Multicore World” by Sunil Mundluri and Velmurugan Periasamy.

Amdahl’s law shows that you can’t get an arbitrary speed-up when running part of your code in parallel. In practice, you can expect serial code to execute 2-4 times faster if you run it with, say, the fork/join framework of Java 7. This is due to setup + join cost and the fact that the tasks themselves don’t get faster – you just execute more of them at the same time. So if a task takes 10 seconds and you can run all of them in parallel, the total execution time will be a bit over 10s.

If you want to use fork/join with Java 6, you can add the jsr166y.jar to your classpath.

Again, functional programming makes everything more simple. With Java 8 and lambda expressions, syntactic sugar will make things even more readable but at a price.

You might want to check one of today’s new languages like Xtend, Scala or Groovy to get these features today with Java 6.


Jazoon 2012: Serialization: Tips, Traps, and Techniques

29. June, 2012

Every once in a while, you learn something new even though you thought you’d know it all. That’s what happened to me during the talk “Serialization: Tips, Traps, and Techniques” by Ian Partridge.

Serialization is such a basic, old technique that it’s surprising that you can learn something new about it. In a nutshell, serialization converts between object graphs and byte streams.

Unfortunately, the API is one of the oldest in the Java runtime. And it’s not one of the best. On the other hand, it’s used in many places like RMI, EJB, SDO, JPA and distributed caching.

What did I learn? Let’s see.

Did you know that it’s possible to serialize a class (without error) that you can’t read back in? It’s actually pretty simple to do: Don’t provide a default constructor (you know, those without any arguments).

You also shouldn’t try to serialize non-static inner classes because they keep a hidden reference to the outer instance.

When you use serialization, then you must take into account that the serialized form becomes part of the public API. This means that private and even final fields are suddenly part of your API that you need to document. Why? Because ObjectInputStream creates an instance using the default constructor and then it sets the final fields using Unsafe.putObject().

If you check the parameters in your constructor, then you will have to repeat them in readObject(). On top of that, you can’t trust the instances which you get from the Serialization API. An attacker can manipulate the byte stream to get references to internal data structures which you most certainly don’t want to expose.

There were *Unshared() methods added with Java 1.4 to solve these but they don’t work. Forget about them.

Anything else? Oh, yes: The serialVersionUID. Besides all the known problems, there is another one:

private static int COUNTER = 0;</pre>
public static class Version1 implements Serializable {
    void foo() {
        COUNTER = COUNTER + 1;
    }
}

If someone fixes this code to

private static int COUNTER = 0;</pre>
public static class Version1 implements Serializable {
    void foo() {
        COUNTER += 1;
    }
}

then deserialization fails for some versions of Java because the generated hidden accessor methods change.

The Serializable Proxy Pattern solves many of the problems.

If you use proxies, consider using Externalizable instead of Serializable


Jazoon 2012: Akka 2.0 – Scaling up and out with Actors

29. June, 2012

Concurrency is too hard but we need it. In his talk “Akka 2.0 – Scaling up and out with Actors,” Viktor Johan Klang showed new features of Akka 2.0.

The framework now uses Future to create pipes between actors and Promise to write data to, say, a stream (docs).

To make error handling more simple, there is now “parental supervision.”

Decoupling actors becomes even more with the Event Bus API.

There is support for ZeroMQ to create grids/meshes of actors (docs).

But every framework has its limitations. If you hit one of those, it’s usually either “Use the Source, Luke” or “You’re out of luck”. Akka 2.0 comes with a new extensions mechanism to hook into the framework.


Jazoon 2012: Messaging in the cloud – why do i care?

29. June, 2012

In his talk “Messaging in the cloud – why do i care?“, Oleg Zhurakousky showed some examples why you should know about messaging even if you don’t use cloud computing.

What is messaging? When a producer sends a message to a consumer over a channel/transport.

What kinds of messaging are there? Point-to-point (P2P) and publish/subscribe. An example of the former is writing a file to hard disk – you don’t expect that file to appear in several places. The latter is used in mailing lists.

P2p can be active or passive. In the active scenario, the consumer gets the message immediately. Example: Watching a web page in your browser. You wouldn’t want the browser to tell you “go drink some coffee, I’ll let you know when it’s done.”

In the passive case, the message is stored somewhere so the consumer can process it at its leisure. You mailbox is an example for this (off- and on-line).

All messaging systems are only one-way. If the consumer can reply, the implementations always make the consumer a producer. Think web sites. Your browser (producer) send a message to the server (consumer): “I want to see this page”. Then the server becomes the new producer when it sends data to the browser (new consumer).

As you can see, we’re using message based system all the time. What makes them so interesting?

They are easy to set up, easy to maintain and easy to make fault tolerant. For example, you can have these generic kind of consumer in your network:

  • Transformers – Turn one kind of message in another. XML to JSON or CSV, binary data to text, insert data into a database
  • Filters to ignore some messages without changing the code of the consumer
  • Routers to redirect messages to consumers that are interested in them
  • Splitter that can copy (parts of) a message to several consumers (distribute part in map-reduce framework)
  • Aggregators that can join several messages into a single one (reduce part in map-reduce framework)
Messages also allow you some nifty tricks like sending a message again after a timeout. If you keep a claim check, you can easily make sure that the receiver will get only a single copy of the message.

Related: