Queue the band...I became SpringSource certified on Saturday!
I was a little nervous about what to expect so I over studied and was well prepared. Looking forward to dependency injection, aspect-oriented programming and enterprise abstraction!
Tuesday, February 21, 2012
Monday, January 9, 2012
Quote of the Day
To make things more complicated, the actual objects and classes that participate in a pattern almost always participate in other patterns at the same time. Focus on it one way, and it looks like one thing; change your focus, and it looks like something else. - Allen Holub in Holub on Patterns, Learning Design Patterns by Looking at Code
Thursday, January 5, 2012
Goals 2012
I'm getting an earlier start on my goals this year. I'd like to focus on my development skills primarily, but continue with problem solving.
So, in 2012 I will ...
1. Become a Certified Spring Professional
I've taken the training, read a couple of books and written a small web app in Spring so this should be doable in the first part of the year.
2. Read 6 software development related books
I've already got that many in my "to read" stack and I'll continue with the Wingdings book club.
3. Convert my "broken toy" library app to Ruby
I been wanted to get started with Ruby but I got sidetracked with Groovy and Spring.
4. Create a new "broken toy" app to help me keep track of the anniversaries and birthdays of my family and friends
This is one that I didn't get to last year.
5. Write two blog posts a month
This is a bit conservative based on last years total, but I'd like to spend more time on my skills.
6. Take some sort of multi-day software development training
This will be a reoccurring goal.
So, in 2012 I will ...
1. Become a Certified Spring Professional
I've taken the training, read a couple of books and written a small web app in Spring so this should be doable in the first part of the year.
2. Read 6 software development related books
I've already got that many in my "to read" stack and I'll continue with the Wingdings book club.
3. Convert my "broken toy" library app to Ruby
I been wanted to get started with Ruby but I got sidetracked with Groovy and Spring.
4. Create a new "broken toy" app to help me keep track of the anniversaries and birthdays of my family and friends
This is one that I didn't get to last year.
5. Write two blog posts a month
This is a bit conservative based on last years total, but I'd like to spend more time on my skills.
6. Take some sort of multi-day software development training
This will be a reoccurring goal.
Goals 2011 Review
Well, it's Goals Review time again! I had 5 stated goals for 2011...
2011 Goal 1: Read 5 software development related books
I was a little less ambitious with books in 2011 but that proved to be unnecessary. I joined a book club and that helped to push my total to 11:
2011 Goal 2: Convert my "broken toy" library app to use Hibernate and Spring
Yes. I created 2 new projects: 1 based on Hibernate, and another based on Spring and Hibernate. I enjoyed learning about the abstractions in these frameworks and I especially enjoyed removing much of the boilerplate/plumbing code I previously wrote. I feel like I've just scratched the surface though, especially as I read the Spring In Action book - each chapter gave me new implementation ideas.
2011 Goal 3: Create a new "broken toy" app to help me keep track of the anniversaries and birthdays of my family and friends
Nope. This will have to be carried forward into 2012.
2011 Goal 4: Write two blog posts a month
Looks like I had a lot to say in 2011, as I created 61 posts! That's almost double my total from 2010. A couple of my favorites:
2011 Goal 5: Take some sort of multi-day software development training
Yes. I took the Core Spring course, and attended the Uber Conference.
One of my unwritten goals for 2011 was to continue pursuing a career that feeds my passion for problem solving, and I was able to further that goal by starting a new developer position.
I'm happy with what I was able to accomplish in 2011.
2011 Goal 1: Read 5 software development related books
I was a little less ambitious with books in 2011 but that proved to be unnecessary. I joined a book club and that helped to push my total to 11:
The Design of Everyday Things - Donald Norman
Driving Technical Change - Terrence Ryan
Exploring Requirements: Quality Before Design - Donald C. Gause and Gerald M. Weinberg
The Inmates Are Running the Asylum - Alan Cooper
Java: The Good Parts - Jim Waldo
Pragmatic Thinking and Learning - Andy Hunt
The Psychology of Computer Programming - Gerald M. Weinberg
Rest In Practice - Jim Webber, Savas Parastatidis, Ian Robinson
The Soul Of a New Machine - Tracy Kidder
Spring In Action, Third Edition - Craig Walls
Working Effectively with Legacy Code - Michael Feathers
2011 Goal 2: Convert my "broken toy" library app to use Hibernate and Spring
Yes. I created 2 new projects: 1 based on Hibernate, and another based on Spring and Hibernate. I enjoyed learning about the abstractions in these frameworks and I especially enjoyed removing much of the boilerplate/plumbing code I previously wrote. I feel like I've just scratched the surface though, especially as I read the Spring In Action book - each chapter gave me new implementation ideas.
2011 Goal 3: Create a new "broken toy" app to help me keep track of the anniversaries and birthdays of my family and friends
Nope. This will have to be carried forward into 2012.
2011 Goal 4: Write two blog posts a month
Looks like I had a lot to say in 2011, as I created 61 posts! That's almost double my total from 2010. A couple of my favorites:
2011 Goal 5: Take some sort of multi-day software development training
Yes. I took the Core Spring course, and attended the Uber Conference.
One of my unwritten goals for 2011 was to continue pursuing a career that feeds my passion for problem solving, and I was able to further that goal by starting a new developer position.
I'm happy with what I was able to accomplish in 2011.
Wednesday, December 21, 2011
Exploring Requirements: Quality Before Design
Exploring Requirements: Quality Before Design by Donald C. Gause and Gerald M. Weinberg is about "the requirements process--the part of development in which people attempt to discover what is desired." It's a comprehensive look at the process and the ubiquitous ambiguity that makes it extremely difficult and error prone. The book, over two decades old but still relevant and practical, presents tips and tools to ensure quality requirements.
The book will change the way that you look at requirements. It uses subtle humor and common sense to present and reinforce ideas. It's not a technical book and has something for everyone involved in product development.
The book is full of simple but important points:
The book is good at pointing out some of the more subtle parts of the process. For example, the types of requirements decisions:
The requirements process begins with ambiguity. Gradually the ambiguity is removed, clarified, and/or constrained. Even though not all ambiguity can be removed, at some point "you decide you have enough agreement to move on into the design phase." This book will help you confidently deal with ambiguity and move on.
The book will change the way that you look at requirements. It uses subtle humor and common sense to present and reinforce ideas. It's not a technical book and has something for everyone involved in product development.
The book is full of simple but important points:
Development is the process of transforming someones desires into a product that satisfies those desires.
The art of requirement process is not so much to provide answers as to raise new questions.
Instead of trying to compete ... on a feature-by-feature comparison ... identify the functions that will be needed to compete.
No single failure of requirements work leads to more lawsuits than the confident declaration, " No sane person would do that!"
Almost any real project, no matter how well planned and managed, contains a certain amount of hacking, because the real world always plays tricks on our assumptions.
The book is good at pointing out some of the more subtle parts of the process. For example, the types of requirements decisions:
- Choices - made directly and consciously
- Assumptions - made unconsciously through bias, error, or lack of information
- Impositions - forced by law, custom, or higher-authority
The requirements process begins with ambiguity. Gradually the ambiguity is removed, clarified, and/or constrained. Even though not all ambiguity can be removed, at some point "you decide you have enough agreement to move on into the design phase." This book will help you confidently deal with ambiguity and move on.
Tuesday, December 20, 2011
The Inmates Are Running the Asylum
Alan Cooper is one of my favorite writers because he forces me to think, and think, and think. I reread his book The Inmates Are Running the Asylum because I'm looking for better ways to develop and this book is full of better ways.
The book's premise is that software development is broken because the technologists are in control. Not because the technologist have seized control, but because the industry has abdicated to the programmers the responsibility of what to develop:
The book's theme is that interactive products need a specialized design process and that the quality of software will improve by focusing initially on interaction design, which is not the same as interface design:
This book is one of my all-time favorites. It is riveting, entertaining, informative and thought-provoking.
The forwards (there are two) are excellent at setting the context for the book and should be required reading for everyone in the software development field.
My favorite chapter is the first, Riddles For the Information Age, which explores and answers the question of what happens when you cross a computer with anything else.
The book's premise is that software development is broken because the technologists are in control. Not because the technologist have seized control, but because the industry has abdicated to the programmers the responsibility of what to develop:
In the past, executives assumed that interaction design was a programming problem and delegated it to programmers who diligently tried to solve the problem even though their skills, training, mindset and work schedule prevented them from succeeding.
The intractability of the software-construction process - particularly the high cost of programming and the low quality of interaction - is simply not a technical problem. It is the result of business practices imposed on a discipline - software programming - for which they are obsolete. With pure hearts, the best of intentions, and the blessing of upper management, programmers attempt to fix this problem by engineering even harder. But more or better engineering cannot solve these problems.
Programmers are not given sufficient time, clear enough direction, or adequate designs to enable them to succeed. These three things are the responsibility of business executives, and they fail to deliver them for preventable reasons.
We can create powerful and pleasurable software-based products by the simple expedient of designing our computer-based products before we build them. Contrary to the popular belief, we are not already doing so. Designing interactive, software-based products is a specialty as demanding as constructing them.
The book's theme is that interactive products need a specialized design process and that the quality of software will improve by focusing initially on interaction design, which is not the same as interface design:
...interaction design refers to the selection of behavior, function, and information and their presentation to users.
[Cooper] prefer[s] the term "interaction design" over the term "interface design" because interface suggests that you have code over here, people over there, and an interface in between that passes messages between them. It implies that only the interface is answerable to the users' needs.
Interaction designers work from the outside in, starting from the goals the user is trying to achieve, with an eye toward the broader goals of the business, the capabilities of the technology, and the component tasks.
Things important for an interaction designer: a strong understanding of what programmers actually do, understanding of interaction design principles and methods, along with a taxonomy for understanding their users.
This book is one of my all-time favorites. It is riveting, entertaining, informative and thought-provoking.
The forwards (there are two) are excellent at setting the context for the book and should be required reading for everyone in the software development field.
My favorite chapter is the first, Riddles For the Information Age, which explores and answers the question of what happens when you cross a computer with anything else.
Friday, December 16, 2011
The Customer Isn't King
In The Purpose of a Business is NOT Customer Value Jurgen Appelo presents an interesting contrarian view:
Most fads and panaceas ignore that a business is a social complex system. It’s purpose is not to satisfy only shareholders, or only customers, or only employees, or only the local community.
A business must satisfy everyone!
Subscribe to:
Posts (Atom)
