- Are static variables inherited by subclasses?
Static variables are inherited by sub classes. However are at class level instead of object level and there is just one.
- Are static methods overridden by subclasses?
That depends. If the reference used to store the object is of the super type, the super types static method is invoked. This is because static is at class level.
- What is the difference between a Set and a List?
In a set an object can only exist once. In a List the same object can be added many times.
- Why should we use the @Override annotation?
We should use this to ensure compile time checking that the contract of a subclass is not broken by changes to the superclass.
- What is the main difference between Callable interface and Runnable interface?
The main difference is that the call method on callable can return a typed result, that can be queried in the future. Callable also throws an exception.
- Whats a covariant return?
A covariant return is allowed since Java 1.5 and means that a method can return a sub classed object of the return type. In Java 1.4 and earlier the return type had to match exactly.
- What is an instance initialisation block? An instance initialisation block is run once after a new object is created. There can be as many of them in the class as you like, but they run in order declared from top to bottom in the class.
- Does an instance initialisation block run before or after the constructor?
They run after the call to super, but before the rest of the constructor.
- What is auto boxing?
It's the ability in Java to automatically switch between the primitive type and the object, without a call to a converter method.
- What is widening?
It's the ability of Java to find a method with the smallest, closest java type. For example if one method takes a long and another takes an int, if I pass a short - java will automatically "widen" the short and select the method that taken an int.
- What is the difference between "&&" and "&"?
&& is a short circuit logical AND, this means that if the LHS evaluates to false, the RHS will not be evaluated. In & both the left and right sides are evaluate every time. For || only if the LHS equates to false, then the RHS side evaluated. When | is used, both the LHS and RHS are always evaluated.
- Dzone 20 things you should know about strings
- What’s the difference between shallow and deep cloning
Wednesday, 21 October 2015
Wednesday, 2 September 2015
An oxymoron is a construct that makes no sense because it joins together two terms that contradict one another. In this post we'll look at some you might come across in development projects. I'll grow this article over time. If you have any suggestions, please feel free to message me!
- Refactoring Story - A story adds customer value, something tangible that the customer can appreciate. Refactoring is changing the implementation of a software system without the knowledge of the users or customers. So we can be either doing a story or refactoring.
- Refactoring Interfaces - An interface is part of the contract our software components and applications provide. Refactoring is changing the implementation without the knowledge of the users or customers. So if we change the contract, the users know about it. We can change interfaces or we can provide new interfaces but its not possible to refactor them.
- Object Oriented Database - these are a niche area of database theory that haven't really caught on in wider industry and they are also an oxymoron. Databases typically need to know a lot about our classes data structures in order to persist the data in a way that facilitates efficient storage and retrieval. Because of need to know the classes data structure, OODBMS break encapsulation, a key principle of object orientation. This places change restrictions and limitations on our software - something OO is supposed to help avoid
- Refactoring - Changing the implementation of a software system, without the knowledge of the users/components that depend on the software system.
- Story - Something that adds tangible customer value.
- Interface - The point of entry to a software system. Could be programatically ie like an Application Program Interface. It could be via the command line or via a Graphical system.
- Object Oriented - Objects are programming entities that exhibit the principles of abstraction, encapsulation, polymorphism and inheritance.
- Database - a software system that allows us to persist data to survive application restart, typically in tables, columns and rows. Columns are generally typed and can be indexed to facilitate faster querying.
Friday, 28 August 2015
This is the first of a series of three articles I want to put together around some Interview questions that could be used for interviewing Java developers. In this first article, we will look at easier, basic concepts that should be covered in any introduction to Java programming. So many of the questions will deal with concepts around defining and declaring classes
- What is the difference between an interface and an abstract class?
An interface is just a contract with no implementation. All methods in an interface are public and abstract. An abstract class can have some state and implementation.
- What are the main differences between Java and C++?
Java is compiled to platform independent byte code that is interpreted in a virtual machine. C++ is compiled into native binaries that are not portable. Java gives automatic memory management. C++ memory management is handled by the programmer.
- What is the difference between a while statement and a do statement?
A while statement may not execute, a do statement is guaranteed to execute at least once.
- Explain the main() method in a java program?
What is passed to it and what is its return type? The main method is the starting point for a java application. The return type is void and the arguments to the java application are passed in an array of Strings to the main method.
- What's the first thing that happens in a constructor?
The first call of every constructor must be a call to super() or this(), but never both in the same constructor. If you call this(), eventually super() must be called.
- What access can classes have?
public or default. protected and private are also only allowed on methods and instance variables.
- What modifiers can classes have? abstract, final or strictfp
- What types are allowed to be in a case statement?
byte, char, short, int and enum. In java 7 we can also switch on String
- Interfaces allow inheritance so can an interface have protected methods?
No, an interface can only have public abstract methods. Update for Java 8, interfaces can now have default method implementations.
- Java concept of the day 25 basic questions
- Java concept of the day
Monday, 10 August 2015
- Why is OO design better than normal procedural coding languages like Bash or C? There are a few reasons. Application code structure and naming should map more readily to real world concepts. Object Oriented design lends itself to more naturally cohesive components (related data and methods are collocated). Thanks to encapsulation, we can reduce coupling. Through the concepts of polymorphism and inheritance we can promote reuse.
- Explain encapsulation? The state of an object should be hidden and only manipulated by methods. The advantage here is that it allows the implementation with in the object to be changed over time without impacting components that depend on this component.
- What is inheritance? Classes can automatically obtain the functionality and state of a parent class. This is also known as sub classing. Inheritance is usually applied for "is a" type relationships. For example if the base class is Car, Corolla is a type of car so Corolla extends Car and automatically gets it's methods and state.
- What is polymorphism? This means where a parent class is used we can easily interchange objects of a sub class. For example if if we have a container that holds objects of type Car, then instances of Corolla and Golf can be added to the container. Polymorphism is works best when you understand the LSP
- Explain the concept of dependency? Dependency means that a relationship exists between one or more components. Dependency can be explicit or direct, for example an import statement at the top of a Java class definition. Or Dependency can be implicit or indirect for example two components know the format of an XML document. Generally we favour components that have a lower number of dependencies on other components. And we favour explicit dependencies that are loosely coupled. Coupling is used to classify the strength of the dependency.
- Explain the concept of Coupling? Coupling is the measure of the dependency relationship between two components. Coupling can be tight - this means the component depends on the internal data fields of another component. Loose coupling means that a component depends on behaviour of another component.
- Should software components be tightly or loosely coupled? Good software components should favour loose coupling. In loose coupling, components depend on methods of other components. This means the internals of a component can be changed in isolation - once the contract on the interface is maintained. Tight coupling means that data fields or structure can't be changed in isolation of other components.
- Explain cohesion? Cohesion is how logically related are software elements that are contained with in a software component. Highly cohesive components are better. Low cohesive components should be split into further components to promote reuse and reduce coupling.
- Are getters and setters "evil"? Short answer yes. Because it breaks encapsulation. Breaking encapsulation means your class is less maintainable in the future. Exposing state to other classes means other classes can contain logic that manipulates the state. Go here for a good exploration of this concept. Systems that use getters and setters are object based, but not object oriented.
Updated 22nd October, 2015 - clarified coupling, added a statement on dependency.
Monday, 13 July 2015
Problem statement:I want to ensure a number is between the range of 5 and 9, inclusive.
Thinking in Test first.I can produce 5 test cases for this very simple problem.
A test of a number less than 5. 2. Returns false
A test of the left bound. 5. Returns true
A test of a number in the middle of the range. 7. Returns true.
A test of the right bound. 9. Returns true
A test of a number greater than 9. 15. returns false
Taking a step back, we want to be really thorough we could write the following tests as well.
A test just outside the left bound. 4. False
A test just inside the left bound. 6. True
A test just inside the right bound. 8. True
A test just outside the right bound. 10. False
I define an interface to the method.
public boolean ensureNumberIsIn5To9Range(int numberToTest);
First I code up the 9 tests against the specified interface.
Execute all tests. They fail.
Now I start the solution code... I'm done when all tests pass.
I come up with a pretty standard if statement, using logical And and two return statements. The tests all pass.
However now I realise I could make this more concise and prettier for the reader. So I refactor the code to just use logical AND and simply return what it evaluated to the caller. Tests all pass.
Now I check the code coverage, just to be sure it meets targets. 100%. I'm done. Check the whole lot in.
Thinking in solution first approachI'm going to promise to do some tests to get us code coverage, with a code coverage metric target of 80%. Management love code with a coverage of 80%.
I will just code up a if statement, with two boundary clauses anded together. Simple. Will then write a test that triggers the boundary clause. And another test that doesn't trigger the boundary condition so happy out.
Next I'll have a think about the interface, it's gonna be pretty simple in this case.
Open up my IDE. Fire in the interface, the algorithm and now I'll think about tests.
So looking at my code, I can see the branch (if statement). The first test I write, just takes any number outside the boundary condition. So I trigger the method with 15, expecting false. I run it, its passes and I get 75% code coverage. Wow I'm nearly there with just one test!
If I trigger the boundary condition on the if statement, then I can increase this figure. So I'll write one more test. This time I'm going to pass 7. Right in the middle of the boundary condition, I am really expecting it to pass.
I execute it. It passes. 100%!!!!!!! Happy days. Check the whole lot in. Home time.
Did you spot the bug in the solution first approach? The upper boundary has been incorrectly coded... values of 10 will return true. It's a good thing this code wasn't used to control an auto mobile safety system, an aircraft or a train!
So I've got 100% coverage, but I'm still leaking bugs. Why?
The set of useful unit testsWe explored the set of useful tests in another article. In this simple example we see the set of useful tests consists of 9 tests. I should implement these 9 tests to ensure correctness of the code. The set of tests that gives 100% code coverage is just 2 tests. This is a significant minority of the tests I actually need to ensure correctness. Hence when reality throws in something we didn't test for, we find bugs, although I have 100% code coverage. You can see there is a large scope for bugs, even in this simple application when you test for coverage.
Spending time writing more automated tests around your top 20% of all uses cases that your users use, will give you a much greater bug count reduction in future releases. Spending any time increasing code coverage when you haven't got that 20% of your code base well tested, is waste.
Tuesday, 7 July 2015
I measure test suites under 6 main criteria. The criteria are pretty hard and fast and there are key indicators to measure them. There is also an AND relationship between them. So if you can tick 5 out of the 6, the other one should be addressed.
- Trust. Tests pass when the component is ok.
- Comprehensiveness Majority of the ways of use for the component are covered by the tests
- Correct level of abstraction. Tests should be written to a stable, well defined interface. Unit tests faciliate refactoring.
- Language Tests should match the language of the problem
- Reliability. Tests fail only when the code is not ok.
- Independent Tests should be independent of other tests, methods and classes, in a pragmatic way. ie each test should only use methods that are "well used" in the public domain. This does not include data driven approaches.
What defines a useful test suite is:
- A developer can be pretty sure, once the unit test suite passes, that no other functional issues will be found. We are happy to release the product after the automated suite passes.
- Majority of the problems are found at the unit-test level. For this our Fault Slip-through Analysis of our bugs indicates that the majority of bugs are found in the right level of test.
- The unit tests are a vital tool to help refactoring. I can do multiple run-test - refactor - run-test cycles, without making a change to the tests. The unit-tests are written towards the "thing" wrapped in an interface, and not just any method or any class.
- They reflect the language of the problem definition re using terminology the customer used. Ideally Customers should be able to understand the tests.
- When a test case fails, it points to an actual problem in the component
- Test cases shouldn't change when we change or extend the system, therefore I can trust them. Test cases are the guarantee that what worked yesterday, still works today. If we have common methods and utility classes referenced in our tests, that are changed as the system grows then we cannot depend on our tests. In other words, if I change my test code, who will test my tests?
What "smells" to measure that a unit test suite is useless:
- Developers don't trust the unit tests to verify the component. This means, more or less, that a developer isn't that confident to release the component based on unit test alone. We require a manual test before we are confident to release the product.
- Majority of problems are being found in later stages of testing. Our fault slip through Analysis is showing large numbers of bugs appearing in later phases of test, that could have been found in earlier phases.
- The unit tests are written at too low a level and now hinder refactoring. I change the internals of a component and several unit tests no longer compile, never mind that the don't run. Every method of every class has at least one unit test associated with it. Worse still, methods that should be private are public to enable testing!
- They reflect the terminology of the code - we see language of the solution in the tests. For example things like factories or other design patterns start appearing in the tests.
- Test cases regularly fail at random times during various runs. Failures are "false" because they were caused by some environmental or platform problem. For example a database service we needed wasn't started or the disk was full.
- All my tests depend on a test utility method I wrote a good while back and this utility method needs to be regularly changed when we add new features. Most times I add new tests, I have to change the utility method, causing a subtle change in all my tests.
Updated 26th May, 2016
Updated 3rd June, 2016
Updated 23rd August, 2016
Updated 4th September, 2017
Updated 26th October, 2017
Wednesday, 1 July 2015
Wednesday, 27 May 2015
Standups in a nutshell:
- set a disciplined, defined and energetic start to the day.
- Re focus yourself on your plan for the day
- Re focus the team on the goal for the sprint
- communicate with your team members. Hear what they are doing.
To help achieve these goals, typically we let standups revolve around three questions:
- What did I do yesterday?
- What will I do today?
- What do I need help with?
Getting your team to stay on pointThere are a couple of things to try.
One experiment to try and stay on point is to get the team to prepare a (6x4) Q card with the 3 questions specifically answered. Each member then reads out their answers at standup.
Another experiment is to pair up team members. Before standup, each member reports their answers to the three questions to their partner. The partner then relays this at standup.
Warning signs and things to try in your standup
- People wandering into problem solving mode in the standup.
Park the discussion. Resume after standup with just the interested parties.
- People reporting to the scrum master or the product owner.
Try to report to the whole team.
- People not listening to their team members.
Try agreeing a team value. If you are not listening to me, I'm not listening to you.
- People joining the standup late and leaving early, once they have given their update.
Discussion with the team member and agreement of a team value to take full part in the standup should help here
Tuesday, 26 May 2015
Collection NamesLet's define four collections of people
- Self organising team
- High performing team
- A number of people who have some common attribute or skill that allows them to be classified together. For example Java developers, scrum masters.
- Defined boundary for the members
- There is a common purpose
- Shared experiences
Self organising team:
- Defined boundary for team members
- Recognized leader
- Subtle control
- Diverse members
- Transforming exchanges
High Performing Team Definition
- Delivering business value all the time
- Will adapt to suit the business
- Continually Improving
- Happy to work together
Wednesday, 29 April 2015
Daily stand upPurpose: For the team to recommit daily and evaluate where our sprint plan is. Individually each member informs other team members what I am doing and where I can get help
When: Daily, in the morning
Who: All team members. PO might be an observer.
Inputs: Sprint backlog up to date to reflect members input.
Output: Everyone knows what everyone else is working on and where they can get help. We know what we need to work on to secure the sprint goal
Sprint planningPurpose: Set the scope of work for the sprint.
When: First meeting of every new sprint.
Who: All team members and PO
Inputs: Groomed and estimated backlog.
Output: A sprint backlog. Sprint started. Commitment from team.
Backlog groomingPurpose: Adjust the backlog estimates and break up big stories/epics.
When: 1-3 times per sprint. 1-2 hours per session
Who: All team members and product owner
Inputs: A selection of X stories from the top of the product backlog
Output: A estimated subset of stories on the backlog. Full backlog will not be costed.
Release PlanningPurpose: Estimate of the size of the backlog on that date.
When: half to one full day, every so many sprints
Who: All team members and product owner and coach (optional)
Inputs: Ordered, populated backlog (as much as possible).
Outputs: A fully estimated backlog.
RetrospectivePurpose: Reflect on how we worked in the last sprint so that we can introduce improvements in the coming sprint.
When: Last meeting of the sprint, after demo and the sprint is closed.
Who: Team members. Product owner optional.
Inputs: none required
Outputs: Actions for each team member to implement
Demo/Sprint reviewPurpose: To show off the teams work and get feedback on work complete.
When: At the end of the sprint. 2nd last meeting.
Who: Team members, Product owner. As many other stakeholders as can attend.
Inputs: "Done" stories.
Outputs: A list of feedback from stakeholders on the software just shown.
Updated 15th April, 2016
Monday, 27 April 2015
A great automated test suite is one that allows you to change the internal architecture of the system in any way, with confidence that the system still behaves the same towards its clients after the change is committed. The more the system changes over time, the more the test proves its value over and over again. The older a great test gets, the more value it delivers in facilitating change. So a great test gets better with age. Very much like a great wine.
A great architecture is one that makes the system do what it needs to do and makes it easy and cheap to add many new features. Unfortunately there are always trade offs in the direction of change that an architecture allows. Ultimately the architecture of a product, with some very limited exceptions, becomes the limiting factor in change. In this respect its like a great cheese, it will age well for the first while, but eventually degenerate and rot.
Thursday, 23 April 2015
In application development, there is a lot of talk about the -ilities. The purpose of this article is to gather a few definitions and explanations of the -ilities together.
Upgrade-ability - the ability to upgrade software, without interrupting service. Can be referred to as "0 downtime" upgrade.
Horizontal Scalability - The ability to increase or decrease capacity of the system by adding or removing instances of services. Ideally, we would like to achieve this without service interruption.
Vertical Scalability - The ability to increase or decrease capacity of the system by adding or removing threads to the running instance of the service. Or to put it another way, how much can the component itself stretch before we have to add more instances of the component.
Availability - The amount of time the service is available to users. Commonly measured % time uptime per year, for example 99.999%. This means the service can be unavailable for a total of 5.26 minutes per year.
Stability - the amount of time the system is running as expected. Less scientific to calculate than availability.
Capability - the list of features that the system/service supports.
Capacity - the load limitations of the system/service. This can be scientifically measured, but different metrics apply for different types of services. For example for certain services the number of operations per second may be important. For other services the amount of data (Bytes per second) processed per second might be important.
Thursday, 26 March 2015
Dev 1: What version of the platform are you using to test your component on your branch?
Dev 2: I'm using version 1.2.3.
Dev 1: Great, I'm also using version 1.2.3.
Dev 2: One thing though. We had to edit the supporting utilities script on the server that was part of the 1.2.3 build. We are waiting for a 1.2.4 build that has the update in it, but it didn't get a green test in CI, so it won't be in the main track today.
Dev 1: So you are not on version 1.2.3, you are on a newer version of software than 1.2.3, that is based on 1.2.3. If I merge in your changes, how can we deliver this to the customer?
Dev 2: We always edit the src on the deployment in order to work around bugs. We usually update the installation instruction afterwards with any of these updates.
Dev 1: I think we need to have a discussion about version control.
Wednesday, 4 March 2015
Wednesday, 25 February 2015
Tuesday, 3 February 2015
Tuesday, 6 January 2015
For our organisation to be agile, we have an explicit need for the "Vertical slice" team. Where every team can make updates across the system, pretty much independently of other teams. Nothing, or at least no other team, gets in the way of progress of the "Vertical slice" team! But in the real world we often shy away from the Vertical team from both a line management and a technical leadership point of view and we continue to form component based teams.
The component based team:
- The most "natural" way for most organisations to setup its' teams.
- Scope of the teams' responsibility is small so they have excellent technical focus. There are a few technologies that the team works intimately with, all the time. Line mgt and developers are happy.
- Team members can become true experts in an area or technology.
- Can build out a "complex" component out of sophisticated "niche" technologies relatively quickly.
- That team only knows a small part of the system. They are effectively limited to working on that part of the system.
- The team can have the illusion of being successful in a product that is failing
- There is a big "tax" when moving people or other teams onto or off this component.
- Those people become key to the organization even though they might not be domain experts in the business. The team can make themselves indispensable to the organisation.
- Component becomes impossible to fundamentally change its technology as the business changes. A component team is loyal to the technology because they have so much expertise. The business adapts its solutions to fit the technologies employed.
- Long term waste/expense. Over medium to long term you end up building parts of a component that are "nice to have" and may never be used by the business.
- Perceived "God" complex develops over time. And Conways' Law applies.
Monday, 5 January 2015
The aim is at least 1 per month, as per last year. While I haven't been publishing, I have been gathering some ideas for articles. I hope to add some book and video reviews as I go.
Looking forward to a great 2015.