22 February 2017

What I learnt from 10 Usability Heuristics explained

I read slides from Jakob Nielsen  titled "10 Usability Heuristics explained", where he points out few very useful points about usability. It is worth to read for beginners as it show them basics elements to think about it when design system that will be easy to learn (and remember) and how to use quickly and efficiently to complete tasks. 

Jakob Nielsen is:
"A web usability consultant. He holds a Ph.D. in human–computer interaction from the Technical University of Denmark in Copenhagen."

From Slides I learn:

  • Status and communication from system should be always visible to user and should use user's language using common standards, being consistent and without technical gibberish. [Rules: "I know what's going on","I know what are you talking about","Seems familiar ,makes sense"]
  • System guides user what to do next and what are consequences. For example. It  should prevent user from making mistakes or at least warn it about possible consequences of the action.  [Rules: "I know what's going on","Glad , I didn't do that"]
  • System should always help user to recover if shit happens, so If user made a mistake, then system should have an ability to emergency stop/exit from current state. It should explain error in plain language and provide possible solution to recover . [Rules: "Oops, let's me outta of here","Glad , I didn't do that","I know what went wrong and I can fix it"]

10 usability heuristics according Jacob Nielson are:
  • Visibility of system status ["I know what's going on"] 
    • "The system should always keep user inform about what's going on through  feedback "
    • In software development The system should always keep user inform about what's going on through  feedback.
  • Match between system and the real world  ["I know what are you talking about"]
    • System should speak user's language with vocabulary and concepts that user are familiar with.
  • User control and freedom ["Oops, let's me outta of here"].
    • User should have ability to emergency stop or exit ,if he made a mistake.
    • This is reason why for example memento(known as undo/redo) pattern is important when we develop functionality as it helps undo problem.
  • Consistency and standards ["Seems familiar ,makes sense"]
    • Follow the convention ,so user doesn't need to figure out that different word ,actions does the same thing.
    • It is important ,because it helps user to learn to use system quickly and efficiently.
  • Error prevention ["Glad , I didn't do that"]
    • It is good to eliminate possible error condition in first place ,where this is not feasibility ,then at least user should be warn and ask to confirm before he commit actions.
  • Recognition instead of recall ["I know what I need to do here "]
    • Minimize user memory's load  , user should remember enough to complete current action without remember about previous steps
  • Flexibility and efficiency of use ["Allow me to do more or less "]
    • Allow novice user to see essential data to make decision but allow to advanced user for customisation.
  • Help user recognise,diagnose and recover from errors ["I know what went wrong and I can fix it "]
    • Error messages should express in plain language and indicate the problem and provide suggestions to solve problem.
  • Aesthetic and minimalist design [" Looks good , works beautifully "] Dialogue should contains only useful information. Any extra unit inform that are rarely any value or no value will reduce visibility.
    • In my opinion design should fit audience. Aesthetic and minimalist design is good in generic cases but will not fit many cases. 
  • Help and documentation ["Okay , I need help "]
    • I don't have opinion about it. It is important to have tutorial to help user to teach basics skills need to find most information in intuitive way but documentation in general means System is too complicated (there are many cases when system is complicated because it performs very complicated tasks).


    30 January 2017

    What I learn from talk "Death by User Stories" by Jenny Martin

    BDDX ’2016 in London OOPSI MODEL

    It was an very interesting talk which focus on OOPSI model as way to do user stories and epics. It is a very interesting approach to describe work to do. OOPSI model shows one of the approaches to describe project.

    What I learn from this talk?
    • According to Jenny, user stories can be dangerous, because stories can be like virus. Virus has only one purpose, to reproduce. It multiplying until they overwhelm delivery. It is called a creeping scope.
    • Jenny used very interesting definition of acceptance criteria:  "Acceptance criteria define the boundaries of a user story,and are used to confirm when a story is completed and working as intended."  For Jenny, problem with them is that they looks like stories too.
      • I like this definition, For me Acceptance criteria verify understanding of task and define when a story is completed with enough confidence.
    • Catching large amount of users stories (as Jira ticket or post it note) on beginning on project is not  good use of time, because we cannot do enough analysis. It generates massive backlog that is not good use of time either.  it is  difficult to manage , many of these tickets nobody cares and they will be thrown away in the end. Many people doing this mistake of explosion of stories and output is similar or the same as  in waterfall.
      • I called this water-scrum-fall problem where we are using agile tools but we still deliver project in waterfall style.
    • Good thing about user stories are:
      • Act as a token for conversation, to discover value.
      • Helps us deliver things in smaller chunks, so that we can get value earlier.
      • Help us track and estimates work
      • Stories are to helps us understand what awesome outcome looks like.
    • Stories in Oopsi contains following components:
      • Outcome - it helps us focus on value and impact of the project that is describe as “In Order to xxx, As a xxx, I need xxx” (based on impact mapping)
      • Output - Illustrate output with examples without details but with general case
      • Process - where we split into Activities (linear)  tasks
      • Scenarios - Given,When,Then . A different path though process to generate the outputs (test cases)
      • Inputs - Inputs (concrete example and living documentation). Input and data needed to drive the scenarios.  Like test conditions or detailed examples.
    • Story mapping. It helps you to describe epic and split into deliverable chunks. Look for the picture of incremental delivery by henrik kniberg delivery to help you picture this point. ( http://blog.crisp.se/wp-content/uploads/2014/10/Screen-Shot-2014-10-07-at-08.20.00.png ) where from his blog when he talking about .
    • Other things that was mention in this talk:
      • Documentation is treat as a rude word in agile
      • Oopsi in reverse looks like  “Is poo”.
    I think, there  are many  bits and pieces that can be useful to use in the place where I work now as in my opinion, it will help deliver project smoother. Describing output through conversation  drives whole process into deliverable chunks of work. Story mapping is a technique that can help you do that. Oopsi can help you to have living documentation 

    23 January 2017

    What I learn from talk "Testable Software Architecture" by Aslak Hellesøy

    Aslak Hellesøy is creator of Cucumber. Cucumber is a collaboration and communication tool .It helps create living documentation. It is used as regression test but this is side effect.
    This is what I learn from this talk:
    1. Test should inspire confidence. In order to be confident about tests:
      1. They shouldn’t be any false positive or false negative. They can fail only, when system is broken).
      2. They must be lighting fast. 
        1. Fast feedback (you should not wait more than than 1 hour for test to complete. If test takes hours , there is an architecture problem.
        2. Remove all IO file/network  . No DB, No HTTP. No external architecture.
      3. Low cost (as Ken Beck said :  “I pay to write code (solving problems ), so I don’t want spend time to maintain tests. 
      4. They need be consistent and you cannot depend on third party ,
    2. You must have decoupled architecture to get confidence through tests. Decoupled architecture allowed you to swap elements. In testing you can swap real thing with fake. TDD helps you to write decoupled architecture.
    3. Low cost tests
      1. Cost of writing test.
      2. Cost of maintain test.
      3. Test should gives you precision what , why and where went wrong.
      4. If you CANNOT do above things if you do it through UI , because in the system UI changing all the time  . UI tests doesn’t give précised diagnose what went wrong. It is take long time to fix them.
    4. (I need to do more research about it) Fakes with Port and Adapter patterns. Use Adapter pattern for fake service. Fake service should be tested by contract that need be passed in real and fake implementation.
    5. What’s QA role ? Programmers writes tests  after QA design tests. QA do not write tests). Test are written before the production code. QA is involved from start by writing acceptance criteria based on requirements from BA and PO says. QA focus on prevent defects not finding them in later stage.
    6. Acceptance and regression tests should be automated because machine can do boring repeatable task, while QA could do more valuable things and perform  manual exploring tests.

    It was an awesome talk. I learn more about QA role and how I as developer should fit to testing part of developing lifecycle.

    16 January 2017

    What I learn from talk "BDD is not about testing" by Dan North

    Dan is a legend. Dan is one of the funniest and definitely most humble speaker in our galaxy.
    I attended to BDDx in London organised by Skills Matters, where Dan was one of the speakers.
    Below, you can find informations that I learn or I believe are useful to know from

    1. Dan starts from point out that testers feel unloved and abandoned by Agile . "Goals of testing is To increase confidence for stakeholders through evidence" because as Kent Beck said : “I paid for code that works, not for tests, so my philosophy is to test as little as possible to reach given level of confidence”. Different stakeholder has different need for confidence that can be achieved through evidence. For example security stakeholder  needs have confidence that it is secure and so on.   
    2. We don’t see bug because of 2 cognitive bias:
      1.     Confirmation bias when my unconscious unconsciously delete anything with my world model. My world model is I am good programmer and I write really good code otherwise I will be depressed and I will be sad and I don’t want code.
      2.     Fundamental attribution error is You assumed If something good happen to me I assume that I have something to do with it. If something bad happen to other I assumed they have something to do with it.
    3. Good tester have 3 super powers:
      1. Empathy for stakeholders (to think like them).
      2. Ingenuity for evidence.
      3. Balance for trade off. 
    4. Programmers and Agile movement does NOT understand testing. Programmers usually see testing as irritation, managers see testing as source of risk. Industry see this as non-critical activity.  One of the reason is Agile movement doesn’t understand testing because Agile was invented by programmers (people who created Agile Manifesto are programmers ) so tester role is poorly defined.
    5. Agile testing is poorly defined and not mature yet. He shows example where 5 days agile testing course contains 1.5 day about testing and rest not (things like Agile manifesto , principles , planning ,estimations or soft skills assessment . Agile testing should cover things like test strategy (one of the most important elements ) , regression tests , functional and non functional testing , write automated and normal acceptance criteria , test metrics , tools for exploratory testing  
    6. TDD is a programming technique (discipline ) for programmers not testing
    7. BDD is not about testing.
      1. BDD acknowledge multiple stakeholder , because PO cannot know everything ( , security, compliance and so on ) and we need describe behaviour of the system 
      2. Acceptance criteria is first class citizen . We describe output (result)
      3. Acceptance criteria the outset ... What is outcome what is correct ,deployable
      4. Everything in BDD happens from perspective of the stakeholder. BDD implementing system by describe it behaviour from perspective of the stakeholder. Goal of BDD is to working software that matters for stakeholders. It happens while we build software we using various testing activities to build confidence . We increase confidence for stakeholders through evidence .
      5. In BDD ,testing is business critical
    8. Testing is a part duty of care.  
    9. BDD should be called BGD Behaviour Guided Development (name was inspired by book titled “ Growing Object-Oriented Software: Guided by Tests” by Nat Pryce and Steve Freeman . 
    10. Good Automated tests should have:
      1. Intention revealing name.
      2. Intention revealing error (need to know why and how it failed).
      3. Consistent language.
      4. Must be fast.
      5. Close to the action (if is communication through Http ,test through http).
    11. Gherkin is not designed for testing .It is tool for guide development bad for that because it is bad in intention revealing error, Consistent language (14 scenarios to catch one intent) and they are slow.
    12. BDD is not about testing , however testing is mandatory part of BDD because it helps gain confidence.
    13. Test thinking is critical to successful delivery .
    14. Most important aspect Good architecture/software is testability and simplicity (not flexibility and reusability as most people thinks).
    Dan's talk was sublime. Last thing worth mention is I decided to learn 1 language and 1 technology per year. After his talk language that I will learn is Python , because he said it is a great language for … automated tests.

    9 January 2017

    What I learn from BDDx

    In November, I attended to Agile Testing & BDD eXchange 2016. It was conference about Agile Testing and BDD. Information about conference can be found here: https://skillsmatter.com/conferences/7428-agile-testing-and-bdd-exchange-2016. 
    It was a great conference worth money I spent. I learn how I  as developer should interact with QAs and why QA is not only about  manual testing. In next few weeks I want share some information what I learn from talks by Dan North, Jenny Martin and Aslak Hellesøy. In this article I will include  main things that I learn and what I learn from talks Kevlin Henney, Ciaran McNulty, Alan Parkinson, Konstantin Kudryashov and Cosmina Bradu. There were a few talks that I missed and I didn't watch yet.
    I have noticed that many speakers moaning about Jira and Gherkin.
    My main take out from this conference were:
    1. QA in Agile feels unloved and abandoned by Agile. Main reason for that is that Agile was created by developers, but truth is that QA is critical part of Agile methodology.
    2. QA role is to focus on design test strategy but they shouldn't write tests. It is a Developer job (with exception if they want to do it). They should be involved with from beginning when requirements are clarified by BA and PO to help them write acceptance criteria . Automate test do not replace QA.
    3. Test should be give confidence to everybody therefore they need be fast and low cost (to write and maintain) . Few talks shows how it is possible to achieve.
    4. Automate tests of everything is overkill.  Don't write automate test for prototypes or in early stages when code is likely to change in near future. Purpose of test is to gain a confidence that code does what we expected .Write automated test (like acceptance criteria, regression) for stable code to remove dull manual tests done by QA as they could this time doing a valuable things and perform exploring tests and so on.
    5. Few talks mentions various techniques that can improve your productivity like:
      • Impact mapping
      • Three amigos
      • OOPSI model
      • How to structure your tests
    6. TDD is a programming technique (discipline ) for programmers not testing.

    Below you have my quick notes from other talks.
    • Don't fire the testers by Alan Parkinson.
      • It was useful  talk about why  testers/QA  shouldn't be replaced by automatic tests and what’s role as they critical  part of Agile Testing  and that they shouldn’t write code. This talk is another example why automate tests are great for  remove boring manual testing and allow QA focus on test strategy.
    • Getting out of end-to-end testing jail by Konstantin Kudryashov
      • It was cool presentation when Konstatin shows how to improve speed of end to end tests.
      • UI and IO are 2 major factor of slowness in testing
        • Removing these factors can reduce single test  from 1502ms to 2ms. After get rid of UI, our taste took 10ms instead of 1502ms. After mock database, test took 2ms instead of 10ms. If your test mix UI , DB and so on, then you will has serious problem. You should have chat with QAs and PO to improve it
      • Don’t use float for money.(I know that, but it is always a good reminder).
    • BDD in Action – a before and after case study by Cosmina Bradu
      • This was an interesting talk by person who introduce BDD as way to improvement development cycle.
      • What went well:
        • Impact mapping seems be great tool for BA, PO and team to visualise need to be deliver and what impact it will have. However from what I understood it can be time consuming activity. User story mapping is useful when you have many requirement.
        • Impact mapping definition. User story mapping it helps to split big features into simple task and improve invisibility.
        • Three Amigos it helps share ownership of story.
      • There were 2 main things that didn’t work for them:
        • Gherkin scenarios as acceptance criteria is not a good solution. Dan and many other people has negative opinion about it. Main reasons are: 
          • Gherkin Scenarios get  verbose very quickly. 
          • Hard to maintain overtime. Too many scenarios can be overwhelming and  you lost ability to see big pictures and prevent you to share understanding.
        • Another thing that didn't work too well is upfront analysis done by BA only  . Upfront analysis shared docs != Shared understand.
    • Pair testing in Agile world by Raji Bhamidipati
      • It talks about her experience with pair testing, but principles applied to most types of pair work in it like pair programming or pair testing
      • There are many types of pair working
        • Expect-Expert like Exploring tester with Security tester, where instead of going back with feedback and forwards . Time saved on loop
        • Expert-Novice 
        • Novice-Novice works because they have different strategies so while 
        • Driver-Navigator 
        • Ping-Pong Pairing swapping 
        • Mob popular in testing. Group of people testing at the same time.
      • Advantages
        • Team building and collaboration
        • Share knowledge
        • Mix of skill set based on requirement
      •  Disadvantages of pair testing
        • work overload
        • conflicts when paired incorrectly due personality incompatibility
        • do not let pair testing create favouritism or elitism within your teams. let's opportunities to everybody not only one person.
      • When not to pair:
        • Do not pair with people who are not fans of pairing or are incompatible 
        • If task is not suitable for pairing
    • and all others.

    6 January 2017

    How to get colourful console logging output in Spring Boot using IntelliJ IDEA?

    A nice little tip for IntelliJ IDEA users who are using Spring Boot.

    I discover some time ago that by default IntelliJ IDEA will display logging output in classic way. However Spring Boot support colourful output.
    In order to enable colourful output then in Srping Boot Application you need add below line to  application.properties (in resources ):

    Done :)



    Enjoy Rainbow style logs :)

    1 January 2017

    What I learn from 008: book Robert Martin - Clean Code: A Handbook of Agile Software Craftsmanship

    This is not a book review . There are many people who does book reviews . I am read book ,because … I want learn something ,so this is my loose thoughts and notes about what I learn from book .

    This note will appear on my new blog soon.

    Robert Martin's BOOK
    Clean Code: A Handbook of Agile Software Craftsmanship 

    CLEAN CODE is a legendary book. I should read this book few years back.
    It is a best book to read and learn from after you graduate and write few projects .This book will help you point you into good directions to become a better developer.It is must read book ,if you are Java Developer.

    So, what I learnt from this book ? A lot.
    Below are notes of things that I should remember in future.Most of them are direct quotation from Clean Code’s book.

    This is very challenging for me as English is not my native language. I am still working hard on improving my skills in naming. This book helps me a lot. Most valuable quotes are:

    1. Boundary conditions are hard to keep track of. Put the processing for them in one place. Don’t let them leak all over the code. For example. We don’t want swarms of +1s and -1s everywhere. In this case boundary condition that should be encapsulated within a variable named something like previousXXX nextXXX
    2. The name of a variable, function, or class, should answer all the big questions: why it exists, what it does, and how it is used.
    3. Name must be descriptive, pronounceable and searchable. Use computer science and math terms, algorithm and pattern names and so on.
    4. Pick one word for one abstract concept and stick with it. Why? Using inconsistent spellings is dis-information.
    5. Names in software are 90 percent of what make software readable.

    Most of things that Martin mentioned to me in book are known for me , but example shows me how I should apply in my code.

    1.  Functions should do one thing , they should do it well. They should do it only. Functions should either do something or answer something, but not both. 
    2. Indent level of a function should not be greater than two.
    3. The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), When a function seems to need more than three arguments, it is likely that some of those arguments can be wrapped into a class of their own. It sounds like cheating, but it’s not. When groups of variables are passed together, they are likely part of a concept that deserves own name..
    4. If one function calls another, they should be vertically close and the caller should be above the callee, if at all possible. It is known as dependent functions. 
    5. Classes should have a small number of instance variables. Each of the methods of a class should manipulate one or more of those variables. In general the more variables a method manipulates the more cohesive that method is to its class. A class in which each variable is used by each method is maximally cohesive.
    I am rarely write a comments . My aim for comments are explain hacky nature of code or explain why and reason of existence of this class. It seems my approach is ok and left some useful quotes that I usually try to follow.
    1.  Comments are, at best, a necessary evil because programmers can’t realistically maintain them. 
    2. Inaccurate comments are far worse than no comments at all. 
    3. A comment may be used to amplify the importance of something
    4. Don't comment bad code , rewrite it .
    5. Comments should be reserved for technical notes about the code and design.
    I admit , I struggle with writing decent tests and doing TDD in the past . It was my aim in 2016 to be good at TDD and testing and I am happy that II made a lots progress but I haven’t write enough code to feel confident .I hope to get more opportunity in 2017.

    1.  Test code is just as important as production code. It is not a second-class citizen. It requires thought, design, and care. It must be kept as clean as production code. What makes a clean test? Three things. Readability, readability, and readability. Readability is perhaps even more important in unit tests than it is in production code. What makes tests readable? Clarity, Simplicity, and Density of expression If you don’t keep your tests clean, you will lose the very thing that keeps your production code flexible. It is unit tests that keep our code flexible, maintainable, and reusable. The reason is simple. If you have tests, you do not fear making changes to the code
    2. Rules for clean tests based on FIRST rules: (FIRST is acronym for Fast, Independent , repeatable, SELF-VALIDATING, TIMELY)
      1. Fast - Tests should be fast. 
      2. Independent should not depend on each other. 
      3. Repeatable - Tests should be repeatable in any environment.(it should run on production, QA and dev machine
      4. Self-validating - The tests should have a boolean output. Either they pass or fail
      5. Timely The tests need to be written in a timely fashion. Unit tests should be written just before the production code that makes them pass. 
    3. When you learn third-party APIs is a good to writes to understand how they work. These tests will come handy when you third-party APIs is updated so then you can run your tests to see is they break anything.. (Jim Newkirk calls such tests learning tests. )
    4. Having dirty tests is as bad (if not worse) than, having no tests. (Dirty test means that it doesn't need follow quality standards and name convention)
    5. Test boundary condition.
    6. Exhaustively test near bugs. Bugs tend to congregate. When you find a bug in a function, it is wise to do an exhaustive test of that function. You’ll probably find that the bug was not alone.
    For end I left various important rules and tips to be a better developer that I am following or I want to follow to be a better developer.
    1.  Duplication may be the root of all evil in software. I think, that’s explain why IDE like IntelliJ IDEA put lots of effort to detect duplication.
    2. Team should agree to a single set of formatting rules and all members should comply. Why ? It helps to have an automated tool that can apply those formatting rules for you.
    3. Treat try/catch as transactions. Your catch has to leave your program in a consistent state, no matter what happens in the try. For this reason it is good practice to start with a try-catch-finally statement when you are writing code that could throw exceptions. This helps you define what the user of that code should expect, no matter what goes wrong with the code that is executed in the try 
    4. Wrapping third-party APIs is a good practice. When you wrap a third-party API, you minimize your dependencies upon it: You can choose to move to a different library in the future without much penalty. Wrapping also makes it easier to mock out third-party calls when you are testing your own code.
    5. Many inexperienced programmers believe that the primary goal is to get the program working. Once it’s “working” they move on to the next task, leaving the “working” program in whatever state they finally got it to “work.” Most seasoned programmers know that this is professional suicide.
    6. Use TDD to do changes step by step . One of the best ways to ruin a program is to make massive changes to its structure in the name of improvement. Some programs never recover from such “improvements.”.
    7. Keeping code clean is relatively easy. If you made a mess in a module in the morning, it is easy to clean it up in the afternoon. Better yet, if you made a mess five minutes ago, it’s very easy to clean it up right now.
    8. Refactoring is an iterative process full of trial and error, inevitably converging on something that we feel is worthy of a professional.
    9. When you see commented-out code, delete it! Don’t worry, the source code control system still remembers it.
    10. Building a project should be a single trivial operation.
    11. Following “The Principle of Least Surprise,” any function or class should implement the behaviours that another programmer could reasonably expect.
    12. Dead code (unused statement, method and so on) is a code that isn’t executed. Delete it (Don’t panic . VCS should remember it). The problem with dead code is that after awhile it starts to smell. The older it is, the stronger and sourer the odor becomes. This is because dead code is not completely updated when designs change. It still compiles, but it does not follow newer conventions or rules. It was written at a time when the system was different. When you find dead code, do the right thing.
    13. Use Explanatory Variables . One of the more powerful ways to make a program readable is to break the calculations up into intermediate values that are held in variables with meaningful names.
    14. Prefer Polymorphism to If/Else or Switch/Case
    15. Replace Magic Numbers with Named Constants
    16. Have a reason for the way you structure your code, and make sure that reason is communicated by the structure of the code. If a structure appears arbitrary, others will feel empowered to change it. If a structure appears consistently throughout the system, others will use it and preserve the convention
    17. Single Responsibility Principle (SRP) states that a class or module should have one, and only one, reason to change. 
    18. Use unchecked exception. 
    19. Many people like Stephen Colebourne (author of joda time and one of the authors of time in Java) believe that using checked exception is bad because it breaks SPR principle . Streams in Java 8 doesn't support checked exception (you need wrap them with unchecked exception)
    There is a last thing that I discover while I read this book . I made terrible mistake in the past that I learn how to write great things without understand reasons . It is something I will focus on from now.
    You can find many talks by Robert Martin on Youtube. I recommend to watch all of them. They are super useful.

    13 December 2016

    How to fix DefaultHandlerExceptionResolver : Resolved exception caused by Handler execution: org.springframework.web.HttpMediaTypeNotAcceptableException in Spring Boot ?

    Solution works for : Spring Boot 1.4 and Spring 4.3.4 but it should works with older  and newer versions too.


    So you are learning Spring Boot and you learn quickly that in order to get  json response you simply need to write method in  Controller with @RestController annotation  (as shown on orange example in the end of this post).
    However, if you try produce xml output instead (as shown on blue example) ,then ...unfortunately .. you will that Spring will display error:
    Whitelabel Error Page
    This application has no explicit mapping for /error, so you are seeing this as a fallback.
    Tue Oct 11 11:23:37 GMT 2016
    There was an unexpected error (type=Not Acceptable, status=406).
    Could not find acceptable representation

    And in logs you will see:
    2016-12-13 11:23:37.760  WARN 7456 --- [io-16801-exec-5] .w.s.m.s.DefaultHandlerExceptionResolver : Resolved exception caused by Handler execution: org.springframework.web.HttpMediaTypeNotAcceptableException: Could not find acceptable representation

    If you see this error ,it means you forgot to add : jackson-dataformat-xml dependency to your project, so imply add this dependency to your gradle (or maven) .
    For example for  Gradle:


    refresh your dependencies and re-run application and it should works :)

    This an example:

    public class JsonController {

    private static final Logger LOGGER = org.slf4j.LoggerFactory.getLogger(JsonController.class);

    public CuteDomainObject getCuteDomainObjectAsJson() {
    CuteDomainObject cuteDomainObject = new CuteDomainObject("Name", new Random().nextInt(32));
    LOGGER.info("Getting Cute Domain Object with data: " + cuteDomainObject.toString());
    return cuteDomainObject;

    @GetMapping(value = "/xml", produces = { "application/xml", "text/xml"})
    public CuteDomainObject getCuteDomainObjectAsXml() {
    CuteDomainObject cuteDomainObject = new CuteDomainObject("Name", new Random().nextInt(32));
    LOGGER.info("Getting Cute Domain Object with data: " + cuteDomainObject.toString());
    return cuteDomainObject;


    Source: http://docs.spring.io/spring-boot/docs/current/reference/html/howto-spring-mvc.html#howto-write-an-xml-rest-service

    17 October 2016


    What is Coolpointer ? Check this : http://dominiksymonowicz.blogspot.co.uk/2015/12/coolpointerintroduction.html

    Retrospective is my favourite part of the Scrum and most important one.
    Why ? 
    In biggest shortcut, retrospective is a event to do  health check of your team and process. It allows you praise people for hard work and  solve  problems about things  that didn't go perfectly well. Anyway , I am sure you know these things already (if not , check  Scrum Guides ) .

    This article helps you investigate reasons why people do not enjoy retrospective anymore and how to make changes to make retrospective valuable and enjoyable again.

    Nothing to talk about on Retrospective, huh?

    10 October 2016


    What is Coolpointer ? Check this : http://dominiksymonowicz.blogspot.co.uk/2015/12/coolpointerintroduction.html

    Interesting article about  naughty tricks that thisv
    Newspaper overslept digital age revolution and they kick badly at the moment.

    Dark Patterns by the Boston Globe