node-gyp rebuild

This does not stop karma from working on my Win 7 32-bit machine. So I was wondering what it means here because on my Mac ‘node-gyp’ actually built after I updated my XCode for Mavericks. I mean that on the Mac I saw the same error initially but after my XCode update ‘node-gyp’ was built and this error vanished.

FSEvents is an API only available on OS X:

http://en.wikipedia.org/wiki/FSEvents

Therefore it is understandable that the fsevents npm module which provides a node interface to that OS API cannot be built on systems other than OS X.In the case of karma it appears to have been handled by making fsevents an optional dependency.

Mac OSX Mavericks

> fsevents@0.3.5 install /usr/local/lib/node_modules/karma/node_modules/chokidar/node_modules/fsevents
> node-gyp rebuild

SOLINK_MODULE(target) Release/.node
SOLINK_MODULE(target) Release/.node: Finished
CXX(target) Release/obj.target/fse/fsevents.o
SOLINK_MODULE(target) Release/fse.node
SOLINK_MODULE(target) Release/fse.node: Finished

> ws@0.4.32 install /usr/local/lib/node_modules/karma/node_modules/socket.io/node_modules/socket.io-client/node_modules/ws
> (node-gyp rebuild 2> builderror.log) || (exit 0)

CXX(target) Release/obj.target/bufferutil/src/bufferutil.o
SOLINK_MODULE(target) Release/bufferutil.node
SOLINK_MODULE(target) Release/bufferutil.node: Finished
CXX(target) Release/obj.target/validation/src/validation.o
SOLINK_MODULE(target) Release/validation.node
SOLINK_MODULE(target) Release/validation.node: Finished

Windows 7 32-bit

This seemed to be a problem until I installed Visual Studio Express 2005.

d:\jwt\sails-angular-jwt-example-master\sails-angular-jwt-example-master\node_mo
dules\bcrypt>node “d:\nodejs\node_modules\npm\bin\node-gyp-bin\\..\..\node_modul
es\node-gyp\bin\node-gyp.js” rebuild
blowfish.cc
bcrypt.cc
bcrypt_node.cc
C:\Program Files\Microsoft Visual Studio 10.0\VC\include\xlocale(323): warning
C4530: C++ exception handler used, but unwind semantics are not enabled. Specif
y /EHsc [d:\jwt\sails-angular-jwt-example-master\sails-angular-jwt-example-mast
er\node_modules\bcrypt\build\bcrypt_lib.vcxproj]
C:\Users\476458\.node-gyp.10.35\deps\v8\include\v8.h(184): warning C4506: no
definition for inline function ‘v8::Persistent v8::Persistent::New(v8::Ha
ndle)’ [d:\jwt\sails-angular-jwt-example-master\sails-angular-jwt-example-ma
ster\node_modules\bcrypt\build\bcrypt_lib.vcxproj]
with
[
T=v8::Object
]
Creating library d:\jwt\sails-angular-jwt-example-master\sails-angular-jwt
-example-master\node_modules\bcrypt\build\Release\bcrypt_lib.lib and object d
:\jwt\sails-angular-jwt-example-master\sails-angular-jwt-example-master\node_
modules\bcrypt\build\Release\bcrypt_lib.exp
Generating code
Finished generating code
bcrypt_lib.vcxproj -> d:\jwt\sails-angular-jwt-example-master\sails-angular-j
wt-example-master\node_modules\bcrypt\build\Release\\bcrypt_lib.node
bcrypt@0.7.8 node_modules\bcrypt
└── bindings@1.0.0

“member of the technical staff”

I was rather surprised to find these passages – copied below – in Fred Brook’s book “The mythical man-month” that was written a long time ago. I was browsing it again after a decade. So I thought I should collect my thoughts on this.

This particular organizational structure has caused me untold grief because as a technical lead I found the gap between these two groups too yawning to bridge. The two groups want to tear each other’s guts out at every meeting. Pure hatred !!

I have been specifically told by an MNC that a manager who has a large team will always get a better appraisal than a tech. arch. who builds systems with the assistance of a few. The top management is scared of equating the two groups for fear of antagonizing the project managers.

The general position “member of the technical staff” is a good way of merging the two groups. But the only way to completely abolish the difference is by making both groups work on project management as well as technical tasks, which is a tall order.

The other way is to encourage people to gain years of experience in their chosen field before moving up the ladder. This creates specialists. People in our companies don’t want to specialize in any field. So a business analyst is not a requirements expert. She should be. Actually no one is an expert requirements architect. So one of the most important fields is left without an expert. That hurts project success.

A project manager is not an expert in Earned Value Management or Statistical Process Control. Once we have specialists we will have humble people. Humility is a great leveler. Expertise gives confidence.


Plan the Organization for Change

Structuring an organization for change is much harder than designing a system for change. Each man must be assigned to jobs that broaden him, so that the whole force is technically flexible. On a large project the manager needs to keep two or three top programmers as a technical cavalry that can gallop to the rescue wherever the battle is thickest.

Management structures also need to be changed as the system changes. This means that the boss must give a great deal of attention to keeping his managers and his technical people as interchangeable as their talents allow.

The barriers are sociological, and they must be fought with constant vigilance. First, managers themselves often think of senior people as “too valuable” to use for actual programming. Next, management jobs carry higher prestige. To overcome this problem some laboratories, such as Bell Labs, abolish all job titles. Each professional employee is a “member of the technical staff.” Others, like IBM, maintain a dual ladder of advancement, as Fig. 11.1 shows. The corresponding rungs are in theory equivalent.

Figure 11.1. IBM dual ladder of advancement

It is easy to establish corresponding salary scales for rungs. It is much harder to give them corresponding prestige. Offices have to be of equal size and appointment. Secretarial and other support services must correspond. A reassignment from the technical ladder to a corresponding level on the managerial one should never be accompanied by a raise, and it should be announced always as a “reassignment,” never as a “promotion.” The reverse reassignment should always carry a raise; overcompensating for the cultural forces is necessary.

Managers need to be sent to technical refresher courses, senior technical people to management training. Project objectives, progress, and management problems must be shared with the whole body of senior people.

Whenever talents permit, senior people must be kept technically and emotionally ready to manage groups or to delight in building programs with their own hands. Doing this surely is a lot of work; but it surely is worth it!

The whole notion of organizing surgical-type programming teams is a radical attack on this problem. It has the effect of making a senior man feel that he does not demean himself when he builds programs, and it attempts to remove the social obstacles that deprive him of that creative joy.

Furthermore, that structure is designed to minimize the number of interfaces. As such, it makes the system maximally easy to change, and it becomes relatively easy to reassign a whole surgical team to a different programming task when organizational

Mac OS Lion freezes too

I realized that the Mac OS freezes too and not for a serious reason. I just tried to install firefox and Finder caused my Laptop to become unusable.

So following the advice in this site I cleaned its preferences but there was no respite.

As a last resort I booted in single user mode and issued rm /var/db/.applesetupdone. I created a new admin. user and deleted my old administrators.

That wasted my Sunday. This has never happened to my Ubuntu desktops.

The dilemma called management

I read this in John rose’s blog but this Feynman quote is appropriate to describe the dilemma that the technical team faces when confronted by a project manager who sends the dreaded email.

The problem is not just to say something might be wrong, but to replace it by something — and that is not so easy. As soon as any really definite idea is substituted it becomes almost immediately apparent that it does not work.

The second difficulty is that there is an infinite number of possibilities of these simple types. It is something like this. You are sitting working very hard, you have worked for a long time trying to open a safe. Then some Joe comes along who knows nothing about what you are doing, except that you are trying to open the safe. He says ‘Why don’t you try the combination 10:20:30?’ Because you are busy, you have tried a lot of things, maybe you have already tried 10:20:30. Maybe you know already that the middle number is 32 not 20. Maybe you know as a matter of fact that it is a five digit combination… So please do not send me any letters trying to tell me how the thing is going to work. I read them — I always read them to make sure that I have not already thought of what is suggested — but it takes too long to answer them, because they are usually in the class ‘try 10:20:30’.

(“Seeking New Laws”, page 161 in The Character of Physical Law.)

Additional Blog

I have started writing about my experience with Ubuntu and my interest in programming languages like Erlang here.

Actually it is difficult to learn distributed architectures and tools like REST, Hadoop etc. and scalability if you don’t have enough exposure. I work for the offshore industry and true innovation is hard here because people are wary of revenue and they play a safe game.

This new blog could be about my experiences with many of these open-source initiatives.

What would you rather be doing?

It takes a certain inconsiderateness to kill passion and the offshore industry is fully capable of it.
The lean methodology proponents advise us to develop people and then develop products.
I am still trying to read and practise agile principles, TDD etc. but it seems to be more and more difficult. Lack of experienced managers and adaptive processes seem to be killing every project I have come across.
It is disheartening that many people do not realize that there are some new modern software development practices.
While I write this I am watching the Oredev 2009 panel debate recorded by Scott Hanselman. What a contrast ? These recordings have become the only solace in my career.

Ivan Sutherland’s essay

James Gosling’s blog has a link to an essay written by Ivan Sutherland. It is about courage that technologists need and is surely a souce of inspiration. I personally liked it because some of us in the offshore software business need courage to stay afloat in an industry that does not value software design or innovation or research as much as it values money and software exports.

This essay has this introduction to the author.


In this paper, his spirit and joy are revealed:
I, for one, am and will always remain a practicing technologist. When denied my
minimum daily adult dose of technology, I get grouchy. I believe that technology
is fun, especially when computers are involved, a sort of grand game or puzzle
with ever so neat parts to fit together. I have turned down several lucrative administrative
jobs because they would deny me that fun. If the technology you do isn’t
fun for you, you may wish to seek other employment. Without the fun, none of us
would go on.