May 1, 2010 Book Reviews, Success 2 comments
Book review: How to Win Friends and Influence People
I just listened to one very interesting audio book. Book title is “How to Win Friends and Influence People”. And I think that it worth to read, or listen to it as I did, because it teaches you how to interact with others. If you are going to grow in your career you indeed need such stuff to know.
This book is of psychological type and author (Dale Carnegie) is talking about interaction with other people. Mainly it talks about how to correctly behave when you want someone to be on your side.
Book could be very useful for managers and for people in their lives. For developer it could be useful in future when you are going to drive few people in your team. If you just starting as a senior developer you already should have some experience driving junior stuff. When you are Technical Leader you need to drive whole team, you need to establish correct processes in your team and one of the hardest tasks in all of this is to make others work on tasks you assign them in the way that they will want to work on that.
Sometimes there are situations when you see somebody’s mistakes and there should be a way to show them this, but at the same time not make them your enemies – they should look at you as at friend, who wants to help.
Book has a lot of different examples from real life when you convince others to do what you want, but for them it looks like they really want to do it, because it seems useful for them.
There are a lot of rules in book. You could go and see contents of the book.
Go to this wiki page to see main points of book. (I recommend).
But now I will try to list down what I remember:
- Honor others for the smallest they did.
- Show that they are valuable – all people indeed what to be valuable.
- Start conversation with what people want and make them answering with “YES” on your questions, only then you could give bad news.
- Smile to others but don’t bluff.
- Build reputation for mentees in eyes of others. So your mentee will do everything he could in order to prove what you said about him.
- Really think about how to walk in his/her shoes.
I know that you heard about that a hundred times. But when you will spent 10,5 hours on listening to this book and when author talks about this during all the time. This will ensure that you remember it and probably will force you to try it in real life. You could start with your team members or with you wife. I think that I will try with my girl just today… or even before I will meet her, since I’m now disconnected from internet and typing this in bus road to Lviv. So will be able post this in evening.
I would recommend this book if you have time for such things or if you could get audio version as I did.
P.S. I tried today some tips from book – it works! You should try.
MCTS 70-536 Application Development Foundation book review
April 26, 2010 Book Reviews, Certification 2 comments
What can I say about this book? It is specialized for passing specific Microsoft Exam. If you are going to pass 536 exam you 100% need it. If you just want to learn some core things about developing applications with .net, book is not best choice. It will lead you through big portion of class names, different methods and enumerations, which could be easily seen in MSDN documentation up to date. I would even say that books like authors took everything possible from MSDN that is related to exam. Also book have mistakes, which I think should not be in such books. Plus to that book is dry to read, but you can read it fast if you know how.
How to read book:
- Read accurately but quick if theme is familiar to you.Skip “Real Word” and pay attention on “Important” and “Exam Tip”, try to remember it!
- If there are boring explanation and then code, switch first to code and analyze if you understand everything there, and if that is true, don’t return back to text.
- Do not execute Labs unless you do not understand what you had read.
- If there are difficult chapters try to read them twice – I did this with Application Security.
I would recommend this book if you are going to pass exam, if not just check-out maybe there are some interesting things that you should know, but do not read book whole end-to-end.
Code Complete – Classes, Methods, Defence Programming
March 21, 2010 Book Reviews, Clean Code, Opinion No comments
Yesterday I’ve read 3 chapters of the “Code Complete“. First one of them was a “Classes” and second was “Methods”. I would say that I took almost nothing for myself from those pages, but the third one was “Defense Programming” and it was quite enjoyable to read.
Classes
Class should stand for one logical unit of understanding from real world or from your system. In other worlds it should be noun, that could do some appropriate operations. It is not just a set of data. Also class should have Single Responsibility – not doing things it should not do and not be cohesive to other classes. Class should not contain too much data and too many methods.
After that McConnel talks about the Composition and Inheritance.
Use inheritance when behavior contract is the same and data is the same to some extend, but only concrete behavior differs, but not expectations of it.
Use composition when behavior is 100% the same, but you still could distinguish what you have before and what you would like to have further.
This means that no need to have AccountLessPerson if the person does not have bank account, it definitely better to have Person with field BankAccount.
Liskov Substitution Principle says that once you have class B derived from class A, other classes should work with B by the contract which is the same as A declares, only enhancements to the behavior is allowed, no real change in it.
Methods
It was boring to read this chapter. i.e. methods should have appropriate names, they should not be longer than N lines of code and be readable, they should not take more than 7 parameters, they should not change params, they should not change global fields etc….
It had to be much better to read there more about how methods should interact with other system.
Defence Programming
This was the most interesting part for me. This all is about building the wall of protection to your system. And this is needed to serve two main purposes: first is stability of the system and the second is for insuring correct behavior.
Assert
Assertion is the way to defense your code from wrong input data, and even defensing yourself from giving wrong result. For example in the beginning of method GetOrdersForAccountNumber(int accountNumber) you could have Assert.That(accountNumber > 0, “since you will not be able to make order with wrong number”) and after you finished with all calculations you could have Assert.That(orders != null, “because don’t think that that is good idea to pass out null object…”).
Exception handling
Exceptions is the tool for working with unusual situations that occur in your application. Some languages still don’t have build-in exception handling, and I’m so lucky that I work with such language like C#. McConner says “Develop with language, not on language”, but the C# just leads to writing a good code. Exception handling is quite big theme to discuss so I hope to have separate post on it.
Few notes about Designing System
March 14, 2010 Book Reviews, Design No comments
Designing is “dry”, non-deterministic and heuristic process.
I just read one chapter from S. McConnell’s “Clean Code” book, and want make some review and summary without taking a look back into book. This should help me reinforce memories of what I’ve learnt.
When you are designing you always should keep in mind that you will not be able to make design good for all situations of life. Thus overthinking on problems could lead to overengineering, so you will get complex system with lot of unneeded tails. Future developers will not be able to work with your design. And project could even fail at some point of time.
To avoid this you should keep building system on easy to understand interfaces, that define how system behaves on different levels and that provide loose coupling.
Building your application like one solid system will lead to situation when you have everything coupled. I’m familiar with system, which is done like single exe file with more than 50 Mb size. You could not even imagine how everything there is coupled – you can get access to any part of the system from any other part. I understand that it is a legacy system and some things where done cause of ‘old school’ and so on and I understand that developers take this into account, but how on earth new guy will know how to work in that system? But how could it be sweet when you have system divided into subsystems, which of them has own responsibilities and depends only on one-two other subsystems, but at the same time provides functionality to good portion of other subsystems.
So, here we talk about low coupling, high cohesion and subsystems ordering. Here is how I do understand this terms:
Low coupling means that parts of the system should interact with each other by clearly defined interfaces, and you should work on decreasing number of interaction. Few characteristics that lead to low coupling are: Volume of connections should be low, Visibility of how two parts connects to each other should be high, Flexibility of changing connection should be also high.
High cohesion means that inside of one part of the system everything should be done compactly, part should have one responsibility well encapsulated inside.
Subsystems ordering means that once you have A and B, and B uses A, then A should not use B. If you need to grow your system you should decrease number of subsystems that you depend on and you should increase number of subsystems that depends on current subsystem. So you are getting tree.
When designing use Design Patterns. Why? Because they are found heuristically and if you think that you have a better decision to the same problem that known design pattern solves it is very possible that your solution will fail.
When designing ask Questions. Why? Designing is iterational process, you always can improve your solution. Just ask yourself if your current design is enough good and if so how could you prove that. Ask if there are other solutions to problem and why did you select your. Ask a lot. Invite a friend let he ask you.
You can design top-bottom and bottom-top ways. Use both. Why and how? Because they have advantages and disadvantages – you can get stuck with top-bottom if you will not have tech solution to some problem, that was defined at the top or solution is very cumbersome, also you can lost vision of what you do with bottom-top and will lost how to clue everything. We are all now far from waterfall so I think that nowadays it is possible to combine those two ways to design.
Eric Evans: Domain-Driven Design
January 29, 2010 Book Reviews No comments
Domain Driven Design by Eric Evans is one of the books that every architect must read if he wants to develop really extensible enterprise level application, which absorbs knowledge of the problematic domain.
Book talks about Ubiquitous Language which is the language between Domain Experts and Developers and helps them build model of the application.
Once you have this language you could easily start build your model with Entities and Value Objects, making Associations between them and other elements of the system. Then you use Services to apply operations on your domain. To interact with Infrastructure you need Repositories and Factories, this makes Persistace Ignorance Layer to hide and isolate your model from technical impacts of your infrastructure.
Refactoring Toward Deeper Insight plus Distilling of model takes your system to the breakthrough. If you have clear model, future Developers could easily work with it addin new functionality and speaking with Customer on common language they will know it, because code raises it to them.
This is one of most valuable book I’ve ever read!
Domain-Driven Design Quickly
January 10, 2010 Book Reviews No comments
Book Domain-Driven Design Quickly is good resource to get consistent and short explanation to DDD.
I was doing my presentation on DDD and was looking for some source to build presentation quickly. And this book is such source.
I already read Applying Domain-Driven Design and Patterns by by Jimmy Nilsson and almost read Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans after that reading of this book was so much enjoyable and quick (I read it for 3 hours and English is not my native language.)
This book is quick readable summary of Eric Evan’s Domain-Driven Design. And it helps to refresh your memory if you already read that book. But if not:
You could read this book to get a good vision of what is Domain-Driven Design in very short term. If wiki or quick google search doesn’t satisfy you and you have not time for big books, this book is exactly what you need. Enjoy it.
Applying Domain-Driven Design and Patterns: With Examples in C# and .NET
January 2, 2010 Book Reviews No comments
I just finished reading book “Applying Domain-Driven Design and Patterns: With Examples in C# and .NET” and I liked it.
This book talks about modern key concepts needed
to develop successful product of enterprise level. It describes how to build
your project without losing business needs out of view – you just start with
your Domain level. You develop with TDD and describing behavior of application.
Things with which you are operating are Customer and Order, but not
TBL_CUSTOMER and TBL_ORDER – this is one of key aspects, which means hiding
your infrastructure level and interacting with database from developer’s eyes,
which can be easily accomplished with NHibernate.
to develop successful product of enterprise level. It describes how to build
your project without losing business needs out of view – you just start with
your Domain level. You develop with TDD and describing behavior of application.
Things with which you are operating are Customer and Order, but not
TBL_CUSTOMER and TBL_ORDER – this is one of key aspects, which means hiding
your infrastructure level and interacting with database from developer’s eyes,
which can be easily accomplished with NHibernate.
Book is excellent in examples which Jimmy presents. I haven’t seen
so good explanation of the State design pattern as it is in this book.
so good explanation of the State design pattern as it is in this book.
Book covers a lot of other interesting things like IoC, AOP, SOP,
MVC and so on… really lot of stuff under another light you ever seen. You need
to read this book if you are going to grow and keeping on track.P.S. BTW as you see I read it in Russian (not my native language also :) but I have it paper variant).
MVC and so on… really lot of stuff under another light you ever seen. You need
to read this book if you are going to grow and keeping on track.P.S. BTW as you see I read it in Russian (not my native language also :) but I have it paper variant).
