Debugging multiple processes at once in Carbide can be a little tricky but this is an area where we’re making some improvements for 2.0. When you are using the emulator then Carbide is really debugging epoc.exe and not the individual Symbian OS processes. So if you terminate debugging one of the processes you’ll take down the entire emulator. But when debugging on a real phone then you can terminate each process individually.

You can also right-click on a process in the debug view and “Terminal/Disconnect All”. This will take everything down but we’ve discovered a couple issues with this command that we still need to fix for Carbide 2.0, so for now I recommend terminating each process individually.

Last week we took a slight detour in our development cycle to spend time with an Agile consultant Pete Behren of Trailridge Consulting, to help us improve our understanding and implementation of our Agile process. From my viewpoint it was amazingly successful and the chance to get an independent assessment of our progress.

When we started the Agile process a year ago we had only a single day of training and some book reading to get started. These new efforts were first seen during the Carbide 1.3 development cycle which led to more frequent beta releases, improved communication with our customers via the opening of our Bugzilla bug database, nightly builds for faster feedback on bug resolution, and a host of internal process changes that made things more efficient, more reproducible, and more accountable. Even with all the changes behind the scenes Carbide 1.3 was easily the least stressful release we had ever produced.

Needless to say, we were hooked.

Jump forward almost a year and things have been rolling along well. We had settled into the Agile groove, made some changes in software for tracking, refined our process, improved our efforts in many ways. But it still didn’t feel complete, it didn’t feel as successful as we had hoped it would be.

So we called in a consultant to come in, observe our processes, and provide us with some independent suggestions as to what we were doing wrong and how we could improve. Very quickly he picked up on some of our problems and guided us into correcting them. In most cases the problems we were having evolved around the facts that we had worked together for several years now and the old habits were still to some effect driving our Agile adoption. Behaviors like working in silos to complete tasks, an avoidance in asking others if they needed help or asking for help ourselves (hey, most of us are guys you know), and mainly thinking that when our tasks are done we work on something else and not on helping others complete the sprint tasks.

As one member of the team explained it, it was like learning to speak Spanish from reading a book, then having someone come in who speaks Spanish fluently critique you on it. We were doing a lot of great things but our adoption of Agile was not pure, with many influences from past behavior and relationships, organizational issues, and generally an imperfect grasp of the essentials. We started with a hybrid approach and while it was an improvement over our development processes at the time, it also created some new issues that may not have been there had we tried a purer approach from the start.

In the final wrap up we created a large backlog of change items we needed to address as a group to help us improve our Agile process. The current sprint has us using some of the new/improved techniques we learned during those 3 days, and we’re working hard to address all of our issues ASAP.

Hopefully, even more of these internal process improvements will become visible to you out there as we work hard to develop and deliver on Carbide improvements with more speed and quality than before.

For those of you out there working on Platform Security integration within your project, we have a tool to help: the Capability Scanner. This scanner checks the APIs used throughout your code and reports the capabilities that you must include in your MMP file. If you’re looking for a simple introduction on how the capability scanner feature can be used, you’ve come to the right place. Take a few minutes to watch the newest screencast:

You can find this and other videos at: http://wiki.forum.nokia.com/index.php/Carbide_Training_Videos

Got ideas for screencasts you’d like to see? Leave us some feedback here and we’ll get on it!

Here’s a followup to my previous post about moving the PC while debugging: This week I’ve been working on integrating a new CDT contribution that will add a “Move To Line” command to compliment the existing “Run to Line” and “Resume at Line.” “Move To Line” will let you move the PC to a new location without resuming execution. Look for it in a Carbide 2.0 nightly build next week.

If you’re not sure what all those different signing options are for when creating .sis files or if you just want to know what options are available for tweaking the build system to add your own little customizations, this is the screencast for you — it’s a basic overview of the Build Configuration Options dialog, but also includes more advanced info like where to go to put in your own command-line parameters if you’ve been hacking on the bldmake and abld scripts, or if you just want to change how they behave.

And as always, we appreciate feedback. Are these screencasts useful? That’s great. And if they aren’t, we’d love to know what topics you would find more helpful.