Richard Warburton

Hi Sam,

Sam Muller wrote:Dear  Urma & Mr. Warburton,
Thank you for making time for us. I am looking forward to reading your book. I am not sure if self-study is something that you cover in the book. Do you have any recommendations for doing this? I have been at it for while, and I must say I enjoy it and have made great progress. I feel while at the surface having an expert team guide your learning, i.e. the traditional University Training, is a plus, but I have seen some disadvantages to that also. My question is what are some activities, resources, and strategies that you would recommend? If you do believe in self-study that is. I found reading a book about learning helped me a lot. I also benefited from kind of exploring different resources and find what worked for me. The other item was learning that creating applications are easier than learning to solve problems, and I located resources for teaching me the later and focused on it.
Regards-
Samuel

Thanks for your question. We do offer example projects in the book that you can code along with yourself, and each chapter has a short section at the end (called "Iterating on you") with open ended exercises that enable you take the concepts from the book further and self study at home. Beyond that I find Katas to be useful for self-study - exercises that you can perform and repeat in order to solve problems, eg: https://github.com/ardalis/kata-catalog. I've actually found building small open source projects are a good way to explore concepts that you want to take further.

regards,

 Richard

Hi Tim,

Tim Cooke wrote:Hello there,

I learned quite early on that a significant part of being a professional software engineer is having the ability to understand, reason with, and improve upon other people's code. Do you cover that aspect of real-world software development in your book?

Thanks, Tim

That's an interesting question. We don't really cover working with legacy code in this book - it's predominantly about how to write better code yourself. I think it's an interesting topic area. Michael Feathers does have an excellent book solely on that topic though - https://www.amazon.co.uk/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

regards,

 Richard

Hi Knute

Knute Snortum wrote:I was a professional programmer in the 80s working with a flavor of BASIC.  In my twenty years in the business, we didn't do a lot of object oriented programming; the language wasn't setup for it.  Then I started working for a company that taught Java and then hired you.  We did OOP and testing, but not a lot of other design principles.

I'm retired now, but I'm still an amateur programmer trying to fill in the holes in my knowledge.  I noticed that you go over SOLID programming in your book.  I know the Single Responsibility Principle, and I think I know the Open/Closed Principle, the I've only heard of the Liskov Substitution Principle; I know nothing about it.

What's a brief definition of LSP?  I'm looking forward to learning the other design principles in SOLID.

Thanks for your question. As you mention there's an extensive section on LSP in the book that goes through a more extensive example that I won't replicate here. Instead I'll just explain the fundamental problem that it's solving. If you've got a parent class called Document and a series of different document types that extend the Document class - say Invoice, Receipt, PatientRecord, etc. how do you know that those subclasses are good substitutes for the parent class. That is to say if you use "Document" elsewhere in your code - what are the rules that it's subclasses need to abide by in their implementation in order for different implementations to be plugged in. These 4 rules form the LSP and act as a really good rule as to what to do and what not to do when extending classes.

regards,

 Richard

Hi Marcio,

Marcio Belo wrote:Hi Raoul, Hi Richard,
I've been arguing with some colleagues about pros e cons of using ORM's frameworks.
In your book you cover the Repository Pattern. But what about ORM's? Do you think they can compromise, in any way, the good design of a system?

Thanks for your question. I think ORMs will probably always be a source of controversy within the software community. They definitely give us a way of removing a bunch of boilerplate from application software development but they also lock in a specific model of mapping from the database to the application software layer that may not be appropriate for a lot of applications. Recently in the JVM ecosystem I've been using JOOQ a bit. I think this offers a nice balance between traditional ORMs and raw SQL.  The question is really whether you want to buy into the whole of the ORM mentality and approach in your system. If it's something you're willing to commit to and if it's object oriented model of working with data fits with the architectural patterns that you see as being important moving forward then that's good. But ORMs can definitely have damage on a project's architecture if the decision has been made to pick an ORM because that's what people know rather than because it's the right choice for the project.

regards,

 Richard

Hi Sundar,

meenakshi sundar wrote:Dear Authors,

I am a big fan of your books  and works, one thing that is intriguing me is that even after so many
years being in this industry , we are still evolving as industry and adopting to new changes in that
context though your books title dosent sparkle on the face but i definitely think that it has lot to offer
given your past works.

With all honesty ,Why did you choose this title?

Thanks for your question. To be honest we felt that a lot of software development books were really focused on small, often academic, examples and not enough on how these examples fit together into larger projects. That's the sense in which the book is "Real World" - it's structured around a series of projects that are small software projects but certainly a lot more realistic than most software textbooks. We hope that this will help people overcome the issues that they currently face with inappropriate application of software engineering principles in a real world setting.

regards,

 Richard

Hi,

Brad Jennings wrote:Agile development processes are rather new to me and my colleagues. There are many established in-house Agile practices at our company, including use of Epic Story and supporting User Stories. Unfortunately what are called "User Stories" don't fit the format of the Agile methodology. Many of our developers resort to crafting functional, technical, descriptions instead of User Stories as told from the user perspective. So, we end up with "Add this to do that" tasks instead of "As a user I would like to press a button and have magic happen". This leads to a lot of trouble when trying to craft QA Tests against these so-called User Stories. We lose focus and sprints take much longer than they should. How do you explain the best way to craft a User Story, and how can a developer communicate and document the necessary functional processes that support those stories?

Thanks for your question. I'm not sure it's directly related to our book as such as we focus more on the technical aspects of software development rather than agile processes per se but I'll answer as best I can from my experience.

I think the underlying issue here sounds like it's really that your developers are getting very focused on the technical work and not enough on your users. Which is understandable, for a lot of us it's the tech that get's us excited and makes us tick. I think the problem that a lot of user stories have is that honestly they don't put a real user in that position. It's often "as a user", rather than using specific stakeholder personas. You can help people get empathy here by making it more personable - give your stakeholder roles names and personalities - Jill and Bob rather than "Manager" and "User". That makes them easier to relate to and makes people think more in terms of how to address the needs of these people and how to make them happy. Even if that doesn't work for everyone it's important to meet your users and talk to them. Understand what their real needs are rather than just a list of features that they want.

Also worth noting, as another poster in this thread mentioned, that these are things to be discussed with customers not just blindly followed. You may start executing on a user story and then realise it isn't actually appropriate and needs to be adapted or that it isn't actually what your users want.

regards,

 Richard

Hi,

Thanks for your question. The core of the book requires Java 8. In certain places we introduce features beyond on 8 - for example local variable type inference. We don't really offer a catalogue of the features in different specific versions because this book is more about programming principles and practices rather than Java specific features even though we've chosen to use Java as the example programming language.

Purushotham Chikkanayakanhalli Krishnegowda wrote:Hello, Any specific version of the java you stick on to while explaining the concepts?  Also, do you have any section that covers java 8, 9, 11 & 13 and their differences?

Best,
Puru

Hi - Thanks - looking forward to the Q&A!

Henry Wong wrote:
This week, we're delighted to have Dr. Raoul-Gabriel Urma & Richard Warburton helping to answer questions about the new book Real-World Software Development: A Project-Driven Guide to Fundamentals in Java.


The promotion starts Tuesday, March 31st, 2020 and will end on Friday, April 3rd, 2020

We'll be selecting four random posters in this forum to win a free copy of the book provided by the publisher, O'Reilly Media.


Image from https://m.media-amazon.com

Please see the Book Promotion page to ensure your best chances at winning!

Posts in this welcome thread are not eligible for the drawing, and should be reserved for welcoming the author. Questions posted in this topic are subject to removal.

Sangel Kapoor wrote:Hello Everyone

I tried reading few threads, everyone is relation Lambda expressions to the functional programming .
I am keen to know few things

1. What is functional programming ?
2. Are lambda expressions new to the Computer world ?
3. What are the set of problems encountered to introduce Lambda expression in the Java world so late .... in Java 8 ?

Thanks and Warm Regards

Hi Sangel,

Here are my attempts at concise answers in order:

1. You can think of functional programming as an approach to computer programming that tries to solve problems by mapping inputs to outputs - a bit like a mathematical function. This is in contrast to imperative programming which solves problems by executing a series of steps.
2. Not at all, lambda expressions originate in lambda calculus whose modern form was defined wayyyy back in 1936 by Alonzo Church. They have been used in a load of programming languages since then and found to be useful.
3. There are quite a few, and I probably can't think of them all but here goes:
a. Deciding on the correct representation for lambda expressions in bytecode. Currently a method is generated and wired up using the invoke dynamic and the LambdaMetaFactory.
b. Ideally you want to give lambda expressions their own types - function types. These would be generic however and generics in Java aren't reified which means that it would have been hard to overload lambda expressions very easily. This motivated the use of functional interfaces to represent the types of lambda expressions.
c. The need to evolve the collections API in order to make use of lambda expressions without breaking backwards compatibility. This motivated the addition of default methods.

If you want more details on the problems in depth and how they were solved, I would recommend reading the project lambda mailing list: http://openjdk.java.net/projects/lambda/.

regards,

Richard

BGirish Bapat wrote:Hello,
What are the advantages of lambda and is it hype or really a feature which will make developer's life easy.
Can you put some insight on this
Thanks,
Girish

Hi Girish,

A similar question about the advantages and motivation of lambdas was asked in another thread, so I'll link you to that answer:

https://coderanch.com/t/634939/java/java/Java-Lambdas-problems#2910792

Thanks for the question.

regards,

Richard

Grega Leskovšek wrote:What is the main advantage of lambdas? Thanks, Gregor

Hi Grega,

The same question was asked in another thread, so I'll link you to that answer:

https://coderanch.com/t/634939/java/java/Java-Lambdas-problems#2910792

Thanks for the question.

regards,

Richard

Yvette Schat wrote:Dear Richard,

I've been out of Java for a few years (since Java 5) due to an unlucky technology choice in our organisation

But now things are looking brighter since it is being picked up again and we'll migrate to Java...

Better late than never...

Can you brief me on what 'old problems' Lambdas/functional programming can solve?

Thank you,

Hi Yvette,

There are several questions on a related topic here - namely the underlying motivation behind lambda expressions themselves. I'm going to try and give a detailed answer here and then link the other threads to this answer.

You've probably had lots of times where you were processing a collection of things, and you wanted to build up a new collection afterwards. This meant that you wrote some boilerplate code everywhere along the lines of:

List<Bar> bars = new ArrayList<>(); for (Foo foo : foos) { bars.add(foo.asBar()); } return bars;

Now you would like to abstract out the code for this pattern, right? You don't want to have to write the same pattern of code everywhere. Even in Java 7 you could write a method like this:

public <F, T> List<T> transform(List<F> input, Function<F,T> transformer) { List<T> output = new ArrayList<>(); for (F value : input { T newValue = transformer.apply(value); output.add(newValue); } return output; }

Unfortunately when you wanted to define your transformer function, you would have to write an anonymous inner class. So even abstracting over the simplest behavioural patterns like this required 5 lines of boilerplate. Essentially you were back to square one. Now the advantage lambdas give you is being able to pass around some behaviour, eg a way of transforming a value into another value or a predicate on a value, in a really simple and clean way. For example the original code example could be rewritten much more concisely as follows:

return transform(foos, foo -> foo.asBar());

So what we can now do is introduce useful abstractions in a way that was impractical to do before. All the new core Java 8 libraries, such as streams and collectors, follow this pattern of using lambdas to abstract over different behaviours.

Teresa Sparkman wrote:We have a java-based test framework and use testNG. How can lambdas be used to simplify code testing?

Hi Teresa,

I think the biggest benefit isn't their direct usage in test code, although there is a good example elsewhere in this thread of that happening, its actually in making it easier to abstract over different behaviours. Being able to pass in some behaviour as a parameter makes it a lot easier to write code which is testable. In the same way that depending on any abstraction makes it easier to write code that's testable.

regards,

Richard

Alba Garcia wrote:I have never heard about it.

Hi Alba,

As the other commenter mentioned pragmatic functional programming isn't a new paradigm. What I'm really getting at is a difference of mentality. I've seen so much of the "Functional Programming is the only way, go functional or go away" mentality that I personally dislike. The pitch I'm here to make is that you can get the core benefits of functional ideas in Java 8, without having to get too religious about things.

regards,

Richard

Campbell Ritchie wrote:Should we stop teaching undergraduates to use loops? They can always use Streams instead

Hi Campbell,

Its a nice idea to say that we can do away with loops, but in reality whatever software you develop needs to run on the hardware at some level. I believe that universities should be teaching students a comprehensive Computer Science education. Part of what this means is the idea that people should have at least a vague understanding of what happens at each level of the stack. So you should get that:

1. At your Java application code level you're executing a pipeline of operations on a stream.
2. Inside the streams library there's a loop that is being executed.
3. At the Java bytecode level and machine code level this loop is converted into a goto statement.

I do think, however, that we should teach undergrads functional programming concepts & streams before they get to loops. So they get to go down from the higher level of abstraction right down to the machine code.

regards,

Richard