Jiri Lundak

Archive for the ‘Conferences’ Category

ACCU 2012 Oxford – Day 4

In ACCU 2012, Conferences on April 29, 2012 at 8:41 am

There were four lightning keynotes today:

Death by Obesity (Didier Varna)

Very fun talk by Didier showing why certain programming languages will die because of their obesity.

Natural language grow in size (by “vocaculibrary”) because just the numbers of words grow, but grammar remains more or less static.

Programming languages grow in complexity (by syntax) and that is wrong (grammar grows)

Homoiconicity: the LISP UFO (Unidentified Functional Object) is undervalued for its austerity. Languages are easily extensible, because they have very simple semantics and very high homoiconicity (just two language constructs ‘atom’ and ‘list’. All other elements can be created using these two concepts and do not bloat the language itself.

Thinking (Charles Bailey)

Fun talk by Charles, about thinking what you do before you code it. (STOP, LOOK, THINK)

Introduced new pattern: NLP (Named Lambda Pattern)

Geek Feminism (Emily Bache)

Greater diversity in any group makes it more intelligent (Book: Wisdom of the Crowds)

Do not treat woman in software engineering (and anywhere else, for that matter) like aliens.

Find Your Motivation (Jurgen Appelo)

10 Intrinsic motivations within the individual (use it on others and yourself)

Why am I working in this company (3 choices: let it, leave it or change it)

Writing Usable APIs In Practice (Giovanni Asproni)

General API definition: a package, classes, exceptions

Difference between public and private APIs.

Assumption 1: any non-trivial programming creates APIs.

Assumption 2: good code is usable code.

We know different principles: DRY, SOLID, principle of least astonishment

…but not always it is clear to us how to apply them.

Giovanni then cited three people saying something that correlates with good APIs:

  • Fred Brooks on “Conceptual Integrity”.
  • “Make Interfaces Easy to use Correctly and Hard to Use Incorrctly” (Meyers)
  • Golden Rule of API Design (Michael Feathers)

He recommended some techniques for better API design (showing good and bad examples):

  • Put yourselves in the shoes of your users (TDD, if writing the test is painful, then you have a problem)
  • Naming (simplest (one) name for most used concept)
  • Give control to the caller (correct application of SRP implied)
  • Explicit context (deployment (dependencies on othe API, user permissions) and runtime context (preconditions for calling methods, per- and post-processing), be careful with global state)
  • Error reporting (how are errors reported, when, how do we recover from errors, error at one level may not be an error at a different error)
  • Logging as a feature (for support: error and info; for diagnostics: debug and trace), diagnostics should be not in production code: maybe just in your workspace! (give the programmer a choice, maybe he does not need logging)
  • Organisation of modules and classes (start specific and small, YAGNI, later just generalize as needed, high cohesiveness and low coupling)
  • Order of function parameters (keep it consistent)

Two things he mentioned along the way, that made me think:

  • Scala lets you do things in many ways (this complicates the language) and makes its API often unclear.
  • Beware of dependency injection (not always clear, what happens behind the scenes and when, especially with some of the available DI libraries; often seems to be easier to manage things yourself).
Take-away of the day

Languages with a simple and stable core (just a few key concepts and homoiconicity – just learned a new word today – are more powerful, easier to learn and much easier to extend, without bloating them)

ACCU 2012 Oxford – Day 3

In ACCU 2012, Conferences on April 28, 2012 at 3:05 pm
Keynote: Requiem for C (Robert C. Martin)

Great talk – as we are used too – from Uncle Bob. Based on his personal history and the inevitable evolution of hardware to the point, where a single processor is not interesting for the individual developer anymore and thus abstractions (like virtual machines) are mandatory to be able to cope with the increasing complexity of computers. And the family of C languages is to die out, because of its close relationship to the ‘metal’.

Glad I switched to Java and similar languages years ago!

But the example of Uncle Bob himself shows, that you can remain at pace with technological change, but you need constantly challenge yourself. Someone recommended to learn a new programming language every year, but I think once in a while is sufficient, if you want to obtain a bit of a mastery.

As I need to refresh my programming skills, I am thinking about choosing a functional programming language next. Based on that I choose two of the session of this day.

Functional Programming You Already Know (Kevlin Henney)

Kevlin made clear, that Functional Programming is an old concept: it goes back to the 60s (Hoare, Dijkstra, et al.) and was already present in many languages. He presented in an entertaining way, examples of code in all languages at least implementing some of the concepts of functional programming. He did not use any of the new and fancy functional languages like F#, Clojure and Haskell.

Functions are already first class objects in C#, but Java still waiting (wait for Java 8)

An interesting point he made, that in the in some environment the problem of concurrency is solved using a pure data flow approach, which is really simple and much more powerful, than any threading mechanisms, where you have to think about locks and mutexes (think Linux pipes and filters).

SOLID Deconstruction (Kevlin Henney)

Another nice talk of Kevlin, discussed in the context of the Dreyfus Model of Skill Acquisition.

He discussed what the SOLID principles really ment, arguing, that they should be applied more broadly, than they isually are used. So is the SRP valid at all structural levels (program, package, class, method, etc.) of an application.

Interesting thoughts about what Cohesion means can be found at Glenn Vanderberg’s Blog.

Satisfying on Pattern, one might compromise another. So make informed tradeoffs.

Or the LSP for example should not just be based on the syntax of a class, but on its behavior! Interpreting the original definition of Barbara Liskov would mean that a new implementation of some functionality does exactly the same thing as another implementation in another subclass.

…and by the way: going to its original definition the open/closed principle states the same thing as the LSP.

Another intersting thought: Dependency Inversion is nothing more than cohesion in respect to change. We do not want to depend on code that is inherently instable. Thus we make our own code independent of it (for example, by extracting an interface and so hiding the instable code).

In the end Kevlin introduced a new acronym (to the great amusement of Uncle Bob, sitting in the in front of him): FLUID – meaning:

  • Functional (Pipes and Filters, programm divided in self-contained units)
  • Loose (Alan Kay)
  • Unit Testable
  • Introspective (self-observing)
  • ‘Dempotent (aka. Idempotent, gracefully dropping the initial ‘I’)
Complexity Thinking or Systems Thinking++? (Jurgen Appelo)

Jurgen’s talk was fun an gave a quick overview about his book ‘Managemnt 3.0’. Having that book I will not go to explain it here. Just go and read it. It is definitely worth a look.

Take away of the day

Functional Programming simplifies much code, and is definitely a programming paradigm to explore further.

ACCU 2012 Oxford – Day 2

In ACCU 2012, Conferences on April 26, 2012 at 10:33 am

Keynote: The Congruent Programmer (Phil Nash)

Phil started by pointing out the difference between dynamic and static quality. I kind of missed that one, as I was not ready yet to write it down. Have follow up on this though in a separate post and research it first.

Phil then went on to define agility, as “to be able to move easily in any direction”. So we are able to do this we need: poise or good posture (he highlight in this context the seminal work of Frederick Matthias Alexander, an Australian actor, the inventor of the Alexander Technique). He had problems with breathing during his performance, and he discovered, that his problem was caused by problems of posture, especially of his head, neck and spine. With his technique he managed to correct his problem, aligning all three.

As people/programmers we have often similar problems. We want to be agile, but have sometimes a problem of poise or good posture (not only in the literal sense).

As we should keep in line spine, neck and head of the physical body for well-being, the same holds true to our personal, emotional and mental balance.

So we should ask ourselves: “Why am I a programmer?” (or manager or whatever). “Am I guided by a main principle?” (it would be healthful if I was).

What are our beliefs, values and principles? Everyone will have different ones. So…

…write them down, tell people about them, start doing something, see what needs to change. But don’t throw everything away! Make changes one step at a time.

When there is alignment between beliefs, values, principles, that is personal congruence!

Doublethink: simultaneously adopt two opposing believes, this might not be your cup of tea. Act accordingly! Else try the synthesis out of thesis and antithesis, and then live with it.

One strange effect make adaption to new beliefs difficult (to say the least): cognitive dissonance. Because of it we tend to reject (new) beliefs or make a strange mix of beliefs, just to feel better. It is also responsible for the so-called “black and white thinking”.

Some pointers to what explore:

  • On how to resolve opposing forces: Benjamin Michtell (Chris Agris)
  • Spoken theory vs. theory of practice
  • Time out – self-discovery
  • Ask others to assess you
  • Look for opportunities (Example: Mike Lee (was at Apple, grew dissatisfied with life, went to Amsterdam and founded Appsterdam)
Lean Quality Assurance: Much more cost-effective Quality Assurance methods than Testing (Tom Gilb)

Tom stated: Quality assurance is far more than ‘to test’. Quality is far more than ‘absence of bugs’. He did not just make the claim, but proved it with numbers, based on Capers Jones’ longstanding work, grounded in real numbers:

He measured the effectiveness of of finding all possible bugs (100% = all bugs found), for example…

…regression tests: 15 – 30%

…integration tests: 25 – 40%

What about inspections (that actually are used to reduce cost to reach a certain quality before release)? They range at about a maximum of 60% (have to check the real numbers for these)

So what are we to do? We could do the following:

  1. Design Quality in: reuse a high quality product, instead of doing it yourself
  2. Prevention: change root cause of quality problems (the process, refer for this to Tuesdays tutorial)
  3. Inspection: catch bad information from which programmers write bad code (the requirements)
  4. Combine Best Practice Testing (but know, that there still remain bugs, when we seem to have found the last ones, so there is little hope of “zero defects”: between 8 and 10 control stages are necessary to achieve to catch 95% of defects, before going to production

By the way: Bugs are a bad measure of quality. That is why engineers use for example Mean Time Between Failure (MTBF) as a measure of quality.

David F. Rico has some interesting information up on his site at http://davidfrico.com about the ROI different methods of software development approaches have (including Agile processes). Have to check that out.

Real Teams (Henrik Berglund)

Negative example: Skylab 3 Crew went on the 27.12.1973 on strike in space, because they had an exactly timed day, crammed with experiments, with total control and observation from the ground, with any personal freedom.

So what helps teams to be sucessful?

  1. Clear authority to manage own work process (Delegation Poker, use Group Wisdom)
  2. Compelling direction (orients and energizes): product vision, release vision, sprint goal
  3. Challenging work: purposeful with at least a 50% chance to succeed
  4. Clear boundaries: who’s on the team and who is not, no partial assignment of a 20% person to the team, that is 80% in another team, nobody can succeed until everybody does, assign problems to teams not broken down user stories (do not let the POs get between the developer and customer)
  5. Trustworthy feedback on results (as soon as possible)
  6. Team composition (size, differences, interdependent skills, team skills, teams know best whom they need, let them decide who is on their team)
  7. Do not hold back your opinion to avoid conflict or hurting your co-worker’s feelings (Innovation synergy based on open positive conflict based on trust)
  8. Keep team stable for some time
  9. Team building is not rock climbing, but conversation within the team about goals, motivation, etc. (techniques: design a product box, chart: “what does everyone enjoy / bring to the team”, team goals excercise: “what teams were you in”, excercise to find individual coals: “after I have been in this team, I have done [something fullfilling]”)
  10. Team decision making: tool #1: fist-to-five, use for team charter or any other thing that has to be decided by the team (quick poll)
Groundhog Day of a Team Leader (Zsolt Fabok)

What does make a good team leader / mentor (note: this is not necessarily an Agile view)?

His Self-view:

  • Presence (he is visibly there)
  • Trust (can be trusted)
  • Craftsmanship (can set an example)

His view of people:

  • State-of-mind
  • Motivation
  • Mentoring
  • Empowerment
  • Do the dirty job (for example fire people)
  • Show Example (if you have a new idea: live it, own it, promote it, as you are the innovator)


ACCU 2012 in Oxford – Day 1

In ACCU 2012, Conferences on April 26, 2012 at 12:30 am

I was a bit undecided on what sessions to follow. With 5 parallel tracks you can end up with a time slot with 4 talks competing for your attention, versus time slots, where non of the talks really sounds interesting. So here my choices for the day:

Keynote: Project Patterns: From Adrenaline Junkies to Template Zombies (Tim Lister)

Tim – as always – had a refreshingly simple yet powerful message: Observe your project and your organization, try to distill recurring behavior patterns, reflect whether they are a good or bad sign and take action accordingly. He presented some patterns from his book and they found wide acceptance with the audience. Recommended!

Git in the Enterprise (Charles Bailey)

The content of this talk was quite technical, outlining for example ways of authentication and how they influence the possible workflow within an enterprise. In the last third of the session Charles gave some advice what to look out for, when implementing Git in any organization, when it comes to branching and merging back into a possibly stable head.

Unfortunately his talk was peppered with “ehm”s, so that the flow was compromised. Also his slides were very dull, missing to visualize what he was talking about.

The Victorian Exploring Expedition of 1860: On Project Management and Leadership from a Real-Life Deathmarch Project (Jim Hague)

Jim told a wonderfully detailed and well-researched story of an expedition trying to venture as far north in the – at that time – unknown Australia of the mid-19th century, doomed to fail from its inception.

The appointed leader of the expedition, although capable of some form of leadership, committed almost every error one can commit in preparation and in execution of the project. Inexperience, bad preparation, absence of risk mitigation and sometimes plain ignorance and arrogance, made the project fail, although equipped with more than abundant resources at the beginning of the journey.

It was easy to see parallels to software development effort, so that all in the room were immediately sold on the reflections presented.

Database Development using TDD (Chris Oldwood)

Chris gave crisp and clear talk about how to apply TDD principles, when working with relational (SQL) databases. He proved, showing a simple example, how one can go about, building data structures, that have a solid set of tests, that express the clients requirements for the data structure.

Some of the points, that stood out of his talk:

  • Encapsulate your database (create a public interface and only expose that interface to your clients, as you would do in your normal code)
  • Test only publicly observable behavior (as exemplified by your public interface)
  • Helpful practices: use schemas for partitioning your data model, embrace composition (stored procedures using other stored procedures), single responsibility principle (as known from OOP) per applied to stored procedures
  • SQL unit testing: SQL Units (procedure, function, view, legacy (constraints, triggers)), tested writing SQL code.
  • Development Sandbox: Isolation, fast feedback, deterministic, tooling is an issue (SS-Unit), as not much commercial tool support does exist.
Takeaway of the day

I had some chat with people during the breaks. And most of them knew what Agile is about, some even trying officially to do Scrum, but most of them are not near implementing it to full effect. Can it be, that we are one of the few companies doing it seriously? And this more than 10 years after the manifesto was formulated. Hmm…


QCon Day 4

In Conferences, Programming on March 15, 2007 at 2:04 pm

We have arrived at the forth day of the QCon conference. Although today there is an Agile track, I will attend some of the more technical session, too.

Deborah Hartmann introduced the sessions and off we go. I will start with the session on “Grails” by Guillaume Laforge, the Groovy project manager and co-initiator of the framework, that tries to port ideas from Ruby on Rails to the world of the Groovy scripting language. A colleague of mine that is writing a book on Grails has recommended the session, so I will go and see what I get for my money. 😉

Grails = Spring + Hibernate re-invented

Here are the main messages of the presentation:

  • Even simple things are quite painful to accomplish with Java frameworks (ORM persistence hard, numerous layers and config files lead to chaos, UI integration messy)
  • Grails is an MVC action-based web framework
  • Principles: Convention over Configuration (CoC), Don’t repeat yourself (DRY)
  • Grails builds on proven components: Spring, Hibernate, Groovy, SiteMesh, AJAX

How Grails addresses pain points:

Pain Point 1: ORM persistence (many XML config files)

  • Domain model based on POGO (Plain Old Groovy Objects)
  • Relationships between POGO’s based on convention
  • Grails generates (called scaffolding) view and controllers for you for a quick start
  • By adding constraints to fields an easy way of validation for correct values is provided
  • Write only your domain model objects and generate the rest
  • Modify some GSP (like JSP) page (view) or some text and reload the page and you are done

Pain Point 2: Numerous config files and layers

  • Most things work over conventions (dynamic finder-method construction, based on known fields)
  • Reading over relations
  • URL’s have easy, consisten mapping like ‘controller/action/id’
  • Parameter passing thru easys maps
  • Easy job scheduling using Quartz

Pain Point 3: Messy JSP-like pages

  • Predefined Taglibs and Components
  • Define own Taglibs

Sweet Spot: Enterprise-ready

  • Existing Java libraries
  • Employee skills & knowledge
  • Spring configured beans
  • Hibernate mappings for legacy schemas (but still benefit from dynamic finders)
  • EJB3 annotated mapped beans
  • JSPs, taglibs for the view
  • Deploy to your pricey Java app-server & database
  • Grails will fit in your J2EE enterprise architecture

Positive impressions about Grails (maybe to incorporate somewere else)

  • Conventions over Configuration
  • Extend that with metadata where needed
  • Dynamic language, so short code-build-run cycle

Questions that remain

  • How much logic goes into the GSP-pages?
  • Taglibs, huhhh?
  • Still generation needed? Why?

All in all an informative talk of Guillaume. Maybe I should try some first steps with Groovy (although its syntax does not appeal very much to me).

The afternoon starts with another scripting language: JRuby. I first wanted to attend the Test-Driven Development session of Steve Freeman, but during his introduction I noted it was too elementary for my knowledge, so I voted with my feet and went for the session about how to integrate Java and JRuby.

In contrast to the Groovy session, the JRuby session seamed quite low-level. No so much the content, but the form of presentation. The presenter (Rob Harrop) just started with the jirb (JRuby interpreter) in commandline manner. He type away quite fast, but after the code moved over the top of the screen, I think, nobody new anymore, what exactly he was doing (actually creating a small Swing application) directly in the interpreter.

So how does JRuby compare to Groovy/Grails. I am basing my lay judgement on few things I saw on the two sessions, so see this not as an expert talking.

Ruby integration into Java is not seamless. Instead you have to use special integration classes to bind it in. Groovy instead makes the use of Java objects a breeze. Java objects and Groovy objects can be used as if they were the same.

Ruby showed a strength in creating new domain specific languages (DSLs). From the point of view of a poor Java programmer JRuby feels very awkward and strange. Many things are not obvious, this is one of my main critique points. Explicitness ist often missing, like when you overload operators, etc.

A issue I find critical with JRuby and Groovy is the dynamic additon of an API (say methods, functionality) to ONE specific instance of a class. While this might be useful in some case, it can actually be nightmarish when it comes to read and understand code. It actually decouples classes from logic making it more difficult track down, where something happens at which point in time (without recurring to debugging).

The next session was “SEAM” presented by Gavin King. He started with the usual rant against Agile and Test-Driven Development (TDD), by saying you need nothing of this “crap”, just use Seam and you are up to a quick start with your web application.

Seam generates a skeleton for a web application inclusive some simple test code. You can modify the code of your application much like in Grails.

“We need no f*cking unit tests. Any one programmer can write those simple POJOs without error. The problems come, when you test a class together with its collaborators.”. So much about a professional attitude to testing.

Seam uses much XML configuration and is in that regard not better than Hibernate or Spring. Gavin admits, that he would prefer doing it in plain Java.

What Seam brings to the table:

  • Single component model for JSF, ESB, EJB, etc.
  • No actions
  • Persistence: No DAOs, instead binds components that access database through JPA/Hibernate directly to the view
  • After changing the DB structure, you need to restart the web server.

Seam incorporates the concepts of conversation based transaction. This a very valid approach to transaction handling in web applications. In fact we have incorporated something quite similar in our own framework.

The next session I attended swang back to Agile software development, when Jeff Sutherland, the co-inventor of Scrum, talked about “Agile Project Management: Lessons Learned at Google”. The room was crowded full, which nicely reflected the interest people had in Scrum. The voices I overheard at the conference showed clearly, that many people would like to try Agile, but feel very unsecure, what agile would bring them and how to start with it. Many doubt that it is worth the effort.

At Google the Adwords project is using Scrum, they have begun about a year ago in early 2006 to introduce individual Scrum practices, like a release backlog, into the company. Originally in 2001 Google decided, that they did not need any Managers, because they were not adding value to the company. So they eliminated all managment positions. So from that time on, projects evolved organically. When Google was growing bigger and the software (in case of Adword) increased in size (500’000 LOC and still growing fast), the project manager of that project saw the need for a little bit more structured approach, which would not destroy the organic nature of the current way to do things, as this was seen as a good thing.

Technorati :
Del.icio.us :
Ice Rocket :