Also, follow us on Twitter!
P.S. All my new posts will be available there and not here, sorry.
Also, follow us on Twitter!
P.S. All my new posts will be available there and not here, sorry.
Really – what information should be mentioned in a bug report? Yes, you know about these things with High, Highest, OurBusinessHasBeenDestroyed priorities and severities, everyone knows about them. But does anyone know what is really needed from a bug report? I had a nice time working as a QA engineer at the start of my career and I’ve learned some things that, combined with what I learned while being a developer and mixed with what I’ve read about, form this post.
Let’s all become goal-oriented and define a goal of any bug report. The final goal of each bug report is to eliminate the bug this report was written about. It doesn’t matter whether it will be fixed or considered not a bug but feature – the bug should be eliminated anyway.
The key to problem solving lies within understanding the problem. In case of a bug, bug report is used for that. Thus, it should contain all necessary information for understanding the problem. Two possible sides of detailing report are simplicity and complexity.
What’s the simplest bug report should contain? It should contain the description of the problem, it’s application. It’s like a smell. If someone enters a room with a nice perfume – you’ll smell it. The simplest bug report should just describe this smell. This way developer will have to spend much time reproducing the problem.
What’s the most complex bug report should contain? It should contain info about:
It should also contain information on how to reproduce – that’s very important. Describing steps for reproducing a bug is not easy at all:
Moreover, instead of describing problem implications only, complex bug report should suggest problem roots. Yes it’s much harder but damn we’re talking about complex report! QA should analyze provided problem implications and suggest what could cause the problem.
Yes, complex bug report really differs from a very simple one – but using it for bug solving will be much easier and you’ll always get positive feedback from a developer. However, you should be aware of the 80/20 rule: 20% of work takes 80% time and vice versa. This means that you should always consider all options and just think – some information is much easier to get for developer, not QA. Don’t waste your time thoughtlessly – you may reach 90% complexity and this will be enough.
Test thoroughly and report well :)
UPDATE: updated bug description criteria to be more specific.
I’ve been playing recently with WP7 development and transitions in particular. In some cases you need to change your ApplicationBar with respect to some ViewModel properties. Edit mode or some NullPattern for bindable list may be good examples for such situations. I wish that thing was easy or obvious (if it is easy but I could not find it :)), but I had to work around this issue with DependencyProperties and manual binding.
Let’s start of a dream:
This is an ideal variant: simple binding and everyone is happy. However, this particular example raises an ‘Invalid XAML’ error. This error makes me think that may be there is a correct way to do what I’m doing but I'’m satisfied for now with my solution.
So what are we going to do? We’re going to do the following:
We’re going to use dependency properties for handling necessary changes.
First, let’s handle DataContext changes:
Here we are defining a CustomDataContext property which is bound to DataContext property of our MainPage. We don’t specify binding property because it will default to DataContext – just what we need.
What should we do in our handler? We should start listening to desired changes and handle them. How? Quite the same – using yet another DependencyProperty:
We’ve defined what reaction we expect from ViewModel property change. Now we have to tie it together with some specific property in our data context. This action will take place in the DataContextChanged handler:
So here we bind our ExtraListNotEmpty dependency property to ListIsNotEmpty property of our ViewModel. Moreover, we explicitly call UpdateApplicationVisibility method that updates ApplicationBar visibility according to specific parameters. We have to do this because by default binding won’t ask for value until it changes – but we need this update at the very beginning.
Let’s finally have a look at the code all previous lines were supposed to support:
ListNotEmptyChanged handler is very simple – it calls UpdateApplicationBarVisibility method we’ve already talked about. This method takes current data context and decides whether we should display our application bar or not.
If someone find another way to do this – please tell me. I really want to replace all this code with the single binding line I’ve shown in the very beginning.
I browse web on everyday rate, it’s a part of my professional education and I really praise the Web for opportunities it gives me. I surf through pages here and there and sometimes I find something really interesting I just have no time to read now or something that should be saved for later. That’s the case where bookmarks save the game.
Bookmark is a simple tool that allows you to save a link in your browser and access it later. This tool may seem so easy and obvious that people just stop paying attention to bookmark organization and they end up with UI mess. So what to do? I suggest using principles borrowed from people who work with papers every day. They have several folders on their desktop that contain different items. Let’s think how to apply it to bookmarks management.
First, we need some folder to contain all input not processed bookmarks. Let’s call it New folder. Any new bookmark you want to add but don’t know where exactly it belongs should be placed here. You should process this folder at least once a week to avoid cluttering. ‘Processing’ this folder means moving items from it to trash can or to other folders.
Second, we need some place to store links that we’ve read and want to save for future. Let’s name it Info folder and use it for these bookmarks. The problem is that usually we have a plenty of links of such type so we need inner categorization. As for me, I have folders ‘Windows Phone 7’, ‘Presentation’ and ‘Neural Networks’. When I place some bookmark to Info folder I decide whether it belongs to folder root or needs categorization. When there are too many items of same type in Info root I create an appropriate subfolder and move them there.
Third, there are links that require some action, like buying, downloading, blogging, etc. The Todo folder is a nice place for such items. My Todo folder contains such subfolders as ‘To buy’ (with yet another subfolder Books), ‘To download’ and ‘To blog’.
The only thing that remains uncovered is a bunch of links that we access every day, such as issue management dashboard, mail, RSS reader, etc. I have two main items: JIRA dashboard and AgileZen dashboard – so it’s rather logical for my folder to be named Dashboards. You may name it as you with.
So, we ended with the following categories:
Almost all modern browsers have out-of-box or extension-based bookmarks sync tools. I use Google Chrome and it’s really awesome to access my bookmarks at any PC I use (actually, three of them).
And just one more thing to remember: clean your bookmarks once a month. They may become outdated or not interesting to you. Don’t show mercy – eliminate them in the name of Order and Productivity.
The title of this post may seem rather obvious, but believe me – it’s not obvious for many many many programmers all over the world. These people ignore books as a source of information and by this they basically slow down their professional development to turtle speed. I hope you’re not one of them! :)
WHY do we need to read? From the primitive point of view, there are two ways to increase skills: theorize and practice. As with all opposite things it’s crucial to find a balance and is a complete mistake to shift entirely to one side only. People who theorize only will always fly in the sky with no practical implications of their knowledge. People who practice only will never have enough knowledge baseground for really full and hard practice. While programming provides you practice, reading is the only way to improve your theoretical background.
So, WHAT to read? One very important point to remember about reading is be balanced. Yes I know that’s just I said before, but in this time the edge cases are different. Programming books are only one edge but I recommend you to have a look at these ones:
You may concentrate on two or three of these categories but I inspire you to pay attention to all of them and find your own areas of interest.
WHEN AND WHERE to read? I usually hear from many people - “When should I read these books? I have no time!”. When – any time you’re wasting your time waiting for someone or something, any time you are doing nothing useful – like moving in the underground. You can easily find time for books if you really want this.
HOW to read? Of course you should read all books the way you prefer most, but you should remember some basic principles:
And now, stop reading this and go find some interesting book!
What is your career if not yet another project? It has it’s own iterations, goals, results. So why not manage it like a project and don’t leave it uncontrolled? I do recommend you doing so and use any project management tool for that. In this post I’ll cover basics of career management using AgileZen as a wonderful example of project management tool.
Goals are main units of career management. You usually aim for something and try to reach it – that’s a nice thing to plan and control!
Basically there are several phases (or states) for your goals:
Each goal starts in backlog. If it’s a permanent goal – it will reside in Permanent goals section and will most likely go directly to Completed phase in the future. If it’s something concrete that should be done – it will be moved to long-range goals, then to short-range goals, then it will be started and then moved to completed goals. This is an example of career board:
AgileZen is really useful for organizing these phases and usable for creating goals and moving them all around. Goals in AgileZen may have subtasks that can help you to structure your task and complete it step by step. What is awesome – AgileZen has a Free plan that is available for single project with a single person – just what we need for managing our careers.
I use AgileZen for my career management, blogging and education and I’m absolutely happy with it. Go try it and be in control!
Due to my profession I often find myself explaining something to someone and more and more times I catch myself on grabbing anything I can draw with and start visualizing my ideas. It’s just much easier to explain if you have some visualization points you can easily roll back to – just pointing at them with your finger. All I knew about visualization was intuitive so it was really great to find a book that covers visualization in depth – The Back of the Napkin by Dan Roam.
This book is very good in organizing your mess of intuitive visualization ideas into clearly distinguishable piles of sorted ready-to-use ideas. Dan is an expert in applying ideas visualization to solving business problems and throughout his long career he extracted some basic principles and patterns that are now presented in this book.
Dan explains the process of processing information and presenting it to other people. He describes how information enters our eyes, enters our brain, transforms into adequate understanding and then is presented to listeners. Then Dan looks at each phase in details, highlighting most important aspects of it. You’ll know what questions use to universally analyze any situation (the 6W principle), how to choose what edge to pick (SQUID system) and how to wrap this all with logic and defeat your current problem.
All these principles and patterns are wrapped with interesting real-life stories and are very easy to understand when reading the book. Go get one – you won’t regret it!