Dearest fellow Z shell users.
The customize freaks among us - who additionally run Debian squeezy might have discovered that our hand-crafted prompts from older versions (namely 4.3.6 and before) do not work any more.
After running a dist-upgrade, my formerly colourful prompt was a bland grey. And adding insult to injury, quite some applications (including VIM) had troubles with some sequences.
So, I went through the provided 'zsh prompt themes'. Lo and behold, there have been some changes that I actually like. There is no 'custom' hash of colour codes anymore, referred by '''$fg_bold''', '''$fg_nobold''' and the like, but the whole thing has changed and reminds me quite a bit of good old tcsh:
To extract some information from the manual page:
Visual effects
%B (%b)
Start (stop) boldface mode.
%E Clear to end of line.
%U (%u)
Start (stop) underline mode.
%S (%s)
Start (stop) standout mode.
%F (%f)
Start (stop) using a different foreground colour, if supported by the terminal. The colour may be specified two ways: either as a numeric
argument, as normal, or by a sequence in braces following the %F, for example %F{red}. In the latter case the values allowed are as
described for the fg zle_highlight attribute; see Character Highlighting in zshzle(1). This means that numeric colours are allowed in the second format also.
%K (%k)
Start (stop) using a different bacKground colour. The syntax is identical to that for %F and %f.
From: ZSH Manual, Prompt Expansion (Visual Effects) http://zsh.sunsite.dk/Doc/Release/zsh_12.html#SEC45
So, this means:
%{$fg_bold[green]%}%n becomes %B%F{green}%n%f%b.
I quite like it.
Hope that helps anyone that looks for a solution.
Lately, I had the same experience over and over: people are rejecting certain agile concepts, methods and techniques - seemingly without or little reason. Examples are teams rejecting BDD or pair programming, line managers rejecting Scrum, ...
I tried to dive into that question and interviewed a lot of people, as well as reading a lot of posts and blogs that showed such behaviour. I found out quite some interesting things - some of them logical and clear, some of them not so much.
Now, the problem in my line of work and interest is that people working, no, fighting for better working environments and better products are hemmed if people are rejecting their ideals and working material. More to the point, if people start rejecting concepts outright, there's not much we can do in order to create win-win situations. And we usually get called when things have already gotten to a point where little hope is left ...
But let's go into details now:
Among the most common things I heard and experienced is
Every Miss Hurts
In short words: every time a sprint fails, a method becomes a tedious standard procedure, people are seeing that the applied method failed, and start to reject it - with good cause. If then the process is forced again and again on the team members and line managers, the notoriety of the applied method is becoming worse by the minute. Now, if that process or the whole method is abandoned, the naysayers (which by then encompasses as good as everyone on the job) will be proven right and will in future reject any notion of moving in that direction again.
Also, another common thing is
The Opposite Of Well Done Is Well Meant
A lot of teams have to pick up agile methods or concepts because a line managers insists. This is not necessarily a bad thing - sometimes people don't know what they need until they have tried it. Of course, it would be better if everyone supports that move, but this is not Utopia. The problem starts if people think that everything written in books or blogs is the recipe they need, the silver bullet. As we all well know, nothing is. No method is perfect.
The problem starts when people can not abandon the thoughts that everything is plannable and measureable. XP methods and Scrum are quite far from that - they help you to develop the best possible environment, and uncover failures that should be addressed. What they are not is a board full of spices where you pick the ones you like most. They are also not complete - any agile method must be introduced and then given ample time and space to develop.
Which brings us now to the attitude of
Do Unto Told, Else
A lot of misunderstandings appear in teams and for line managers because a absolute conceptual misunderstanding exists. Often the managerial advice "Do what I tell you" cannot be fulfilled - because neither the developers do know what their manager actually means, and the manager has no means to check if the team actually understood the advice (even if it is slightly more detailed than the example given).
This problem is particular to a lot of organizations in growth, but also applies for very old and crusty, bureaucratic organizations. It is a habit that is hard to break, because the lack of communication is not something that can be solved by recipes - again.
Another big problem of viewpoint and attitude is
The One For The Job
If you look into many organizations, the call for a 'cross-functional' team is one that sounds unheard. I do know that in many organizations this is not wanted or possible, even if the basic thought of 'Matrix' organizational structures for projects would support just that.
There is much more to that, though. There are the elititsts on one hand that swore never to touch the filthy base of the code again - they dabble with their playthings, thinking grand thoughts ... and then there are the worker bees, having a hard time understanding what those elitists babble about, but doing their utmost not to learn anything, in order to be able to do their work calm and peacefully. Noone is going to go out of their way to learn to work together, and most of the time this attitide is supported by the line management: they know whom to detail which task, and also know whom to blame if everything fails.
And the last (for this article) is
Where Change Is, There Fear Lurks Nearby
A manager might seem to be forced to change part or all of his organizational structure that supported him well enough until today. A developer will be expected to learn new methods of work. A designer is pulled from his comfort zone and thrust into a development team. A solo player suddenly should take up pair programming. A couple of serious engineers suddenly play silly card games.
The reason that agile methods are introduced are that someone thinks that there is room for improvement. Some people will not be convinced that easily, especially when confronted with unfamiliar methods. Most will naturally react with fear, followed by rejection.
But How To Cure That?
I think the first steps are being sincere and true.
First, we have to become clear in our terminology and teachings. Whether it is for managers or for teams, we should try to make it crystal clear that any wisdom gained from books alone is just a skeleton that has to be fleshed out by experience.
What is easily forgotten, or maybe never learned, is the fact that we are working with complex adaptive systems within complex adaptive systems. If we try to understand and control them in detail, we fail. If we try to control the flow and the results, we might win.
Then, it should also be clear that all methods have been created to get rid of dysfunctional counterparts. APM is for getting rid of dysfunctional project management, Scrum for getting rid of dysfunctional product creation methods and dysfunctional teams, XP at large for getting rid of dysfunctional development processes, etc.
Next, make clear that every change will necessarily mean change in some other part of the organization. I cannot introduce Scrum and ignore the uncovered impediments - I cannot introduce T(B)DD and not improve contact with my users or at least user representatives. I cannot introduce any agile method without any change to the processes and very possibly I even need change to the structure of the organization. Some of those changes may be minor, some aren't.
Most of the time we will be met with rejection in those cases. We will have to take our sweet time and explain what the reason behind it is - and motivate people not only to let them be taught and follow guidelines, but to partake and help shaping said guidelines.
And last: improve communication. Everything about agile methods is being in the very first word: agile. Being able to react without long preparations, long-hauled, expensive meetings and decisions made by a comittee of project leaders, that's the goal! But we can only do that if everyone knows about the vision, everyone knows about agile methods and her role in it, and everyone does the best to succeed.
At that point, a lot of naysayers pointed out that people are basically lazy, do not want to improve, and will reject everything. Also, they will not improve, because they do not have the intellectual capacity. Huh - I must have had the best and most docile teams, because after initial resistance, everyone, especially the scepticists were suddenly developing, supporting and carrying the processes.
I also heard that the roles, artefacts and processes are always set in stone and may not be changed howsoever. WRONG! (It sadly shows how little people understand sometimes, even people interested in the subject, and officially working 'agile'.
To tackle the technical communication issues between managers and developers, there's also only one answer: communication and trust. Both sides have to learn to talk to each other - sometimes it's just the matter of starting a project, planning, implementing and presenting the first functionality, and moving from there. Make it clear that one of the goals must be to still have specialists for everything - but to have other people being proficient with the same tasks in order to be able to mitigate temporay unavailability of said specialist.
For me, communication is the grease - it makes everything run smoothly. The fear will subside, the specialists teach others, the others will be teaching the specialists, the line managers will understand their role, the designers, developers, engineers will understand their role, there will be no need for reprimands, and trust in every direction will be built. To spare the worst message for last: the people that cannot adapt to the 'new way' will be leaving, and will be replaced by people that can adapt.
And last, an appeal: stop cherry-picking framework supports as methods or methodologies, unless you really really know what you are doing. Don't say you're doing TDD if 90% of your code still arrives untested in production. Don't say you're doing Scrum if you don't track and solve impediments and/or lack any product vision (among all the other points that usually show up).
Everything is about building excellent products with excellent people working on them.
Even more it is about building enjoyable work environments - which will in turn improve quality and performance.
YAY! 2 boxes, 2 nvidia cards, 2x Debian (stable/testing and testing/unstable), 3 monitors .... behold the beauty!
nvidia-xconfig and nvidia-settings along with nvidia-glx and nvidia-kernel-src, module-assistant (m-a), a run-off-the-mill kernel, compiz*, and now I have rotating desktop cubes with nice pictures and and and and ...
without a lot of work. Just building the module, letting nvidia-xconfig do the rest - and now I have XFCE4 backed up by compiz and gtk-window-decorator.
WHEE!
Long story short: an nVidia card is the better solution (I am biased, though). After enabling the composite extension in xorg.conf via
Section "Extensions"
Option "Composite" "true"
EndSection
I can set the Compositor settings in Window Manager Tweaks. And it works, just the xfce4-terminal can't be convinced that I want a transparent background. But for typing, that's not very nice even ...
From /usr/share/doc/mail-notification/README.Debian:
mail-notification for Debian
----------------------------
I had to disable SSL because of a license issue.
Hopefully, this will be solve soon.
Now, how to work around this?
Easy: use stunnel
First step: install it:
aptitude install stunnel
Second step: test it
As root, run: stunnel -c -d 9993 -r [targethost]:993 (replace "[targethost]" with your target host).
Then, configure mail-notification (I won't outline this here, just point the IMAP-host to localhost, port 9993).
It should work already. If it does, configure stunnel:
Again as root, run editor /etc/stunnel/stunnel.conf.
Change the lines:
cert = /etc/stunnel/mail.pem
to
;cert = /etc/stunnel/mail.pem
Comment out the not-needed blocks after the line
;Use it for client mode
and add the following
[imaps]
client = yes
accept = 9993
connect = [targethost]:993
(again, replacing "[targethost]" with the corresponding hostname or IP address).
First, kill the running stunnel process, then run the following:
# cd /var/lib
# mkdir stunnel4
# chown stunnel4:stunnel4 stunnel4
# invoke-rc.d stunnel restart
Voilà.
