Super cool :) - Ship sizes across the univers

Oct 29, 2014

Thinking about - week 42

The Three Essential Keys to Work Motivation

there are three factors for work motivation:

  1. Autonomy: the control you have over your work. The more you can control what to do and when to do it, the more motivated you are.
  2. Mastery: the sense of progress you get. The more you think you are getting better at what you do, the more motivated you are.
  3. Purpose: the meaning you get from your work. The more what you do matters to you, the more motivated you are.

once you reach the middle class, you should focus on how you make money rather than how much. The way becomes more important than the amount.

Autonomy could be difficult to achieve if you work for someone else…. increase your bargaining power by being very good at what you do. Your company will be willing to give you more freedom if it really needs you. Another way is to build your own business.

GOML-1, Responsive Design

Do you remember when the word “responsive” meant fast?

But now, all of a sudden, the word means: compatible with mobile devices.

what the word “respond” means. You respond to a stimulus. A screen is not a stimulus. A screen is an IO device. You don’t respond to the format of an IO device. You respond to Users. Consarned kids.

Software Craftsmen Are Arrogant, Slow, and Dogmatic

Craftsmen are arrogant.

craftsman in practice—it needs to be done perfectly and proudly. Their focus is fully on minor details, because those create the base from which their skill level can grow.

Software skill exists on an asymptotic curve. When you first learn something, you make large strides immediately and feel like you’re making serious progress toward perfection. But as time goes on, and as you increase your familiarity with the subject, your progress becomes more incremental.

They challenge others to climb the walls and jump to try to close this gap too, and they employ hyperbole to justify the importance of seemingly mundane details and practices. “We need to test this remote edge case.” “Why haven’t you refactored this class?” Craftsmen are constantly working toward an ideal, and any ideal other than perfection is offensive. This hyperbole is not necessary, but it comes from a bias.

This bias creates a communication issue. Craftsmen are so narrowly focused on closing the gap between themselves and mastery that it becomes difficult to consider that others might not share this focus.

They sound arrogant because their language is drawn from a different set of assumptions.

Craftsmen are slow.

In a fast-paced, results-oriented team, a craftsman spends time refactoring working software. This can seem academic or self-indulgent in the face of a deadline. But the reason is both simple and practical.

As craftsmen, we’ve done enough practice to know that the cost of work has a non-linear relationship to its quality. If you don’t take advantage of an opportunity to refactor and increase the quality of your code early, it will take exponentially longer to refactor and add features later. Your code will have more bugs, and will be difficult to extend when your clients need added functionality the most.

Craftsmen are dogmatic.

The first time you neglect to write a test, you increase the likelihood that you’ll neglect to write a test in the future. You’ll develop poor habits, and your skills will slowly deteriorate.

Oct 13, 2014

Thinking about - week 40

http://vimeo.com/ndcoslo/videos

Peter Smith - It doesn’t work like that in enterprise

Definition of Enterprise development

Problems:

What is the solution?

Scott Allen - Building Directives for AngularJS

Meg kell tanulnom AngularJS-t Mese nincs.

Demonstrated how to create custom tags into HTML and have some behavior around it.

Oct 01, 2014

Thinking about - week 39

Craft Conf presentations

Dan North - Jackstones: the journey to mastery

More like a motivational speech but very good. You want to be a master of development.

Until you are novice pretend to be master

But being a master you should be able to use any practice: TDD, SOLID with critique…

Practice until you realize when it is useful.

As a journeyman

Learn how to learn

Listen like you do not know the answer - you may not know.

Gojko Adzic - How I Learned to Stop Worrying…

Amazingly good presentation.

It is focusing how to make agile really working and that is not really about developers but they are wrong too…. I have to re-watch to extract.

We have to change how we are thinking about user stories.

User story is about behavior changes.

Theo Schlossnagle - Responsibly maximizing craftsmanship in software engineering

How software sucks

Specification are extremely difficult to get right.

laziness is promoted as something good.

Learning curve of huge projects is amazingly huge. It become difficult to add features quickly. (!of course not decoupled!)

Learn to hit the fucking deadline:

Learn papers: there are many researches about how to develop big system and resolve problems effectively (heheh történt ilyen mikor valaki bemutat egy design patternt mint valami újdonság és jó design cuccost)

Engineer are function better autonomously

You are judged based on your API

So: choose the proper size of component to be able to work autonomously using well defined API to communicate each other. So build component maintainable.

DO not refactor but rewrite component. Rewrite better, based on knowledge you know about. It is part of maintenance.

SQL is not API!!!

Stefan Tilkov - Architecture War Stories

War stories with humour and fun. Very interesting.

Advice:

  1. Give feedback
  2. Reflect

Jutta Eckstein - Complex Projects aren’t planable but controllable

Individual goal are against company goals because most of th goal need teamwork which is killed by individual goal setups.

and many other mut it was not so structured to extract the “single message”.

Use values instead of estimates (business values….) for deciding to initiate the project. There are many way to define value (ROI, Risks, Cost of delay, Importance, Willingness for investment)

Plan in different levels: roadmap, long term, mid term, short term

Sep 23, 2014

Thinking about - week 38

All videos can be found on http://vimeo.com/ndcoslo/videos

Doc Norton - The Technical Debt Trap

The danger occurs when the dept is not paid back. Every minute spent on not so good code counts as interest in that dept. Technical dept is good.

People are confused the dept metaphor with the idea that you could write code poorly.

Code must be clean enough to be able to refactor! (always) - Otto: so Tests are there…., well tested :)

Ask yourself:

I any of these are missing it is not technical dept. It is a mess!!!

Remember quality is your responsibility.

NEVER ask permission to do job correctly.

When monitoring complexity track trends not points. (exact values are meaningless but tends are meaningful).

Brendan Forster - 10 Things Ive Learned From Doing OSS

Enrico Campidoglio - Why no code reviews

Problem 1 is about Ego. EGO=1/Knowledge. The less the knowledge the greater the EGO.

Problem 2: you == your code

Problem 3: Fear of making mistakes. Fear of let colleges see my mistakes

Problem 4: Culture o(lack of it) “you are wrong”…. See Ego!

Do not review the person. REview the code. Do not speak in absolute. Fools are speaking absolute.

Time: it need time.

NB: Good diagram about productivity of a geek

What do you get from code review?

When you know that someone is watching you will take care of you code more. “The Big Brother EEffect”

It can eager ambition because yo want to impress your programmer fellow.

Give constructive feedback.

In a project everyone is in the same boat. (Sometimes I do not have the feeling - Otto - But we have to trust people that they are doing their bests)

Kind of review

  1. Formal code review. Most bugs found
  2. Over the shoulder code review. Less former. Less bug to be found
  3. Async code review. Happen async to the code written. “distributed”. IT happens offline. Good compromise in nr of bugs found and time.

Tools: - Gerrit, Diffy

rules:

  1. review small portions of code at a time. One commit one logical change.
  2. keep and follow a checklist
  3. keep under 1 hour

Aral Balkan - Free is a Lie

Interesting and shocking conspiracy theory how Google/Facebook is ruling our life and data…

Sep 19, 2014

Thinking about - week 37

All videos can be found on http://vimeo.com/ndcoslo/videos

Venkat Subramaniam - Core Software Design Principles

Basic Design and OO principles. Simple and good. DRY, SOLID, tell don’t ask, etc.

Anders Abel - Using the Scrum Rules Against your Boss

Basic Scrum but important for those who are using Scrum as a hipe then realize that it is not working for him:

Only accept those produce backlogs which are clear.

Venkat Subramaniam - Towards an Evolutionary Architecture

Interesting stories but there are not so many specifics. It emphasizes that we have to think about flexible architecture consciously.

Robert C. Martin - Clean Architecture and Design

As in last year. Maybe in an other conference.

Mike Cohn - Advanced Topics in Agile Planning

I have seen that last year too.

Steve Sanderson - Architecting large Single Page Applications with Knockout.js

I have to watch again…. Looks good but it was very fast.

Robert C. Martin - Advanced TDD The Transformation Priority Premise

Good but I have learned the same concept through cleancoders.com.

Robert C. Martin - Functional Programming What Why When

Thinking about Functional programming. Why it is so important to be ware of functional paradigm for our programming future.. On the other hand the presentation is made already in an other conference and available online too.

Mike Cohn - Getting Agile with Scrum

Scrum 101 :(

Sep 11, 2014

Thinking about - week 36

What Makes a Good Programmer?

1 - Problem Decomposition

But before you write any code, you need to be clear on how to solve the problem. One skill good programmers have is the ability to break the problem down in smaller and smaller parts, until each part can be easily solved. … A good programmer finds a way to model the problem in such a way that the resulting program is easy to reason about, easy to implement and easy to test.

2 - Scenario Analysis

the ability to consider many different scenarios for the program. This applies both to the logic in the program, and to the internal and external events that can occur. …

The good programmers ask themselves: How can this break? In other words, they have the ability to think like testers. In contrast, inexperienced programmers mostly only consider the “happy path”

3 - Naming

Programming consists to a large degree of naming things: classes, methods and variables. When done well, the program becomes largely self-documenting,

(from Phil Karlton): “There are only two hard things in Computer Science: cache invalidation and naming things.”

naming is hard because it needs to be clear in your mind what each name represents.

4 - Consistency

the biggest challenge in programming is managing complexity. Consistency is one way to combat complexity.

5 - Learning

As a software developer, you are constantly learning. Before adding a new feature, you have to understand what it is supposed to do. Before adding code to an existing program, you usually have to learn what the existing code does, in order fit the new functionality in properly

Spring pitfalls: transactional tests considered harmful

It is highlighting some important aspect. Examples are mostly about Hibernate and other JPA implementations. Some of the examples are not relevant it you are not using JPA.

I am using transactional test for SQL syntax check only. As you might know SQL cannot be unit tested (semantic of SQL) You could not test declarative tool with declarative toolset.

The proposed solution is to load a fresh database which might be working for h2 database but for a big monster like Oracle is a questionable solution.

Stand-ups are Broken, but Should They be Fixed?

on every team I’ve ever been on, if there’s a customer (or scrum-master or project manager) present, the meeting always turns into a status report.

If you have a good visible taskboard you do not need to report anything because it is visible on the wall.

The stand-up meeting was created to solve a particular problem—developers don’t always talk to each other. … if your team is working in the same war-room or communicates frequently through other means, it’s probably not necessary to have everybody discuss explicitly what they are doing.

Despite the desire for an On-Site Customer, most teams do not have their customer available all the time,

Oh, yes. At the end of the iteration/sprint is just fine for most of the customers.

Scrum, velocity, and driving down the motorway the wrong way

Velocity is in essence a negative metric – it can tell you that something is wrong, but not that something is good.

Velocity is a nice metric for internal process monitoring, so you can spot problems early. But beware of using a negative metric such as velocity as your primary measure of success, it leads down the path of false hyperproductivity and a warm feeling that you’re doing something good when in fact you might be driving the wrong way down a motorway, with a truck heading straight at you.

Nightmare on Agile Street

A very humorous story about an Agile project which is not so agile. Or more precisely about a project in which stakeholders are remembering those aspects of agile what they prefer and ignoring the rest. And the result is a total disaster.

A few weeks ago I had a similar (not so extreme) feeling and I wanted to cancel the project too. But… :)

Does Speaking Another Language Change How You Think?

Language is a tool that fills the needs of its speakers.

Languages also have expressions and words for concepts that don’t match one-to-one But, again, it’s a nuance in expression, the same fundamental thoughts can be conveyed fairly equally in most languages, plus or minus a bit of brevity.

The big way that learning a new language changes your thinking is that language is a gateway to culture

language is a preferential route for cultural understanding (albeit a difficult one)

The Language Learning Experience Changes How You Think

Sep 04, 2014

JUnit IgnoreRest - turn 2

In the previous IgnoreRest article I was complaining about that it is not notifying IDE properly without a custom test runner.

So I have implemented the runner I need.

 1  public class IgnoreRestSupportRunner extends BlockJUnit4ClassRunner {
 2    public IgnoreRestSupportRunner(Class<?> klass) throws InitializationError {
 3      super(klass);
 4    }
 5
 6    @Override
 7    protected void runChild(final FrameworkMethod method, RunNotifier notifier) {
 8      IgnoreRest ignoreRestAnnotation = method.getAnnotation(IgnoreRest.class);
 9      Description description = describeChild(method);
10      if (IgnoreRestHelper.hasIgnoreRestAnnotation(description) && null == ignoreRestAnnotation) {
11        notifier.fireTestIgnored(description);
12      }
13      else {
14        super.runChild(method, notifier);
15      }
16    }
17  }

And that is all. Nothing else. All the remining code needed is extracted from the previous implementation. For supporting Spring I have to make use exactly the same code but the base class has to be SpringJUnit4ClassRunner.

So the only runner I have to deal with is the junit-hierarchicalcontextrunner .

Source is available on GitHub

Aug 31, 2014

Do we really need JQuery validator plugin?

The more I need to do some HTML client side validation the more I am asking myself whether we need a validation framework or not.

Until now I have not used any specific validation framework. But now I have to because I do not want to take care of simple syntax level (number field could accept numbers only, etc.) field validation.

First of all I have used developers best friend: Google . I have found numerous validation framework for JQuery (just have a look at the Google search result in the previous links).

I have check many of them and found that most of them are too complicated to my need (remember, I need simple syntax check because complex validation is made on server side).

The client side I wanted to make something simple and declarative:

1  <form:input path="duration.hour" cssClass="form-control" maxlength="2" data-validation-pattern="^([01]?[0-9]|2[0-3])?$"/>

This is a simple Spring MVC input field. I have just introduced a custom data attribute called data-validation-pattern and the value is the regex pattern I want the check actual value test against. This specific example is checking an optional field which is accepting hours (0-23) of a day.

The expected behavior is that when any error happens I do not want to submit the form.

1  $('#mrs_form').submit(function(event) {
2    var validator = new MeetingValidator('#mrs_form');
3
4    if (!validator.checkValidity()) {
5      event.preventDefault();
6    }
7  });

So far, so good.

Let’s implement the validator:

 1  function MeetingValidator(form_selector, options) {
 2    "use strict";
 3    var DEFAULT_OPTIONS = {
 4      on_finished : function() {}
 5    };
 6    options = $.extend({}, DEFAULT_OPTIONS, options);
 7    var issues = [];
 8
 9    /**
10     * @return false if there are validation errors
11     */
12    function checkValidity() {
13      checkRegexPattern();
14      options.on_finished(issues);
15      return _.isEmpty(issues);
16    }
17
18    function checkRegexPattern() {
19      $('[data-validation-pattern]', form_selector).each(function() {
20        var name = $(this).attr('name');
21        var patt = new RegExp($(this).data('validation-pattern'));
22        var value = $(this).val();
23        if (!patt.test(value)) {
24          issues.push({
25            kind : 'pattern',
26            name : name,
27            value : value
28          });
29        }
30      });
31    }
32    MeetingValidator.prototype.checkValidity = checkValidity;
33  }

Cool, isn’t it? In function checkRegexPattern there are 4 effective lines of code which is dealing with all what I need.

You could say: “But it is not enough I need to report errors to the user”. And I will say: “Yes, you are right!”

And here is the weakness of many validator plugins. They are not so flexible how to report the error. If you have a look at the code it has an optional input parameter called options with one relevant attribute called on_finished which is intended to be a function and called at the end of the validation process.

Let’s see in practice:

 1  $('#mrs_form').submit(function(event) {
 2    var validator = new MeetingValidator('#mrs_form', {
 3      on_finished : on_validation_finished
 4    });
 5
 6    if (!validator.checkValidity()) {
 7      event.preventDefault();
 8    }
 9  });
10
11  function on_validation_finished(issues) {
12    _.each(issues, function(issue) {
13      $('input[name="' + issue.name + '"]').parents('.form-group').addClass('has-error');
14    });
15  }

Function on_validation_finished is simply mark the field (using bootstrap styles).

Enjoy it!

Aug 04, 2014

Thinking about - week 31

Stop Unit Testing Database Code

Writing tests that use an actual database is hard.

  • that results from tests against your test system have (almost) no meaning
  • that your tests will not cover some of the most complex aspects of your productive system
  • that you will start spending way too much time on tweaking tests rather than implementing useful business logic

Databases couldn’t be any less stateless. The whole idea of a database is to manage state. And that’s very complicated and completely opposite to what any unit test can ever model

My database unit testing is about testing SQL syntax only.

Flyway and jOOQ for Unbeatable SQL Development Productivity

  1. Database increment
  2. Database migration
  3. Code re-generation
  4. Development

Good combination of tools. I would like to use. But those Oracle DBA guys do not like using tools which are not used to (even if it is more advanced)

TDD != Unit Tests (and vise versa)

The post itself is not about this topic but the reaction on depate made around Test-induced design damage started by DHH.

The “Just In Time” Theory of User Behavior

I’ve long believed that the design of your software has a profound impact on how users behave within your software. But there are two sides to this story:

  • Encouraging the “right” things by making those things intentionally easy to do.
  • Discouraging the “wrong” things by making those things intentionally difficult, complex, and awkward to do.

The purpose of locks, the locksmith said, is to protect you from the 98% of mostly honest people who might be tempted to try your door if it had no lock.

10% of people will never steal, 10% of people will always steal, and for everyone else … it depends.

most people will consistently and reliably cheat “just a little”, to the extent that they can still consider themselves honest people.

Once upon a time I have made a test whether I am a good man. For example a good man does not steal. And first question: Have you ever taken a pen from your workplace for private use? Of course I did….

a simple reminder at the time of the temptation is usually all it takes for people to suddenly “remember” their honesty.

You do it by showing them …

  • the minimum helpful reminder
  • at exactly the right time
Jul 28, 2014

Archives

Links

Cool

RSS