Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!

Greg Pfeil

Greenhorn
+ Follow
since Apr 05, 2001
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Greg Pfeil

Colons used to be file separators for Mac OS. The new OS X uses the slash as a file separator (like other Unices), but I think it may still allow the colon as a file separator, for Classic and Carbon stuff, I'm not sure.
So, yeah, it's a file separator. What are the legal characters in a filename in Java? I mean, Unix allows everything except slash. Java must be fairly strict. If they're trying to avoid all platform-specific file separators, that means no /, \, :, and > at least. I'm sure there are probably others, if we dig through enough obscure OSes.
17 years ago
I think you have a bit of a misconception about Unix and Linux. For all intents and purposes, Linux is a Unix. The label "Unix" has kind of faded and been replaced by Posix. Most operating systems are Posix-compliant now (with the advent of Mac OS X, Windows is pretty much the only one that isn't).
So, there is no difference between Linux and Unix, Linux is merely one example of a Unix.
However, there is still a need to choose what to use . . .
There are so many choices, although a lot of that is beginning to fade. SGI and IBM, for example,are beginning to move away from their operating systems in favor of Linux. Apple is replacing the lower-level portions of Mac OS with a Mach-based BSD. SCO has started distributing Linux.
Sun, with Solaris, seems to be the only company fighting the Open Source OSes. However, in the meantime, the decision is more complex than Solaris, BSD, or Linux.
I know I haven't answered the question at all, but really, a lot of it comes down to personal preference. I use Linux and OpenBSD, but at work I have a Solaris box because I have to make sure our software runs on Solaris. Other than that, just make sure the software you need runs on the platform you decide on.
19 years ago

Originally posted by Johannes de Jong:
Greg when is your company moving to Amsterdam, really sounds like a great place to work for
As fate would have it I noticed an evaluation package of three 3cd on the desk of a colleague. "Tamino X-Studio" from Software AG. competition for you guys Greg?


Well, for the most part, they're targeting a different problem space than us, although we both do have native-XML databases. That's really one of the basic pieces you need for any kind of XML suite, so it makes sense that we'd both have one.
I don't know anything about their product, but I'm sure ours is much better

Originally posted by Bill Prentice:
All of the above leads me to several conclusions.
Flexi-time (which we enjoy) is pretty much incompatible with XP.


Well, incompatible with, say, the pair programming bit, but the other aspects could still work quite well. At best, each pair could make a compromise for when they are going to work for the coming iteration.

Working from home is a no-no.


Pretty much -- but in our company, we have plenty of projects that don't use XP, and smaller projects that have only a single developer. Working at home is much better in these environments.
I started a thread on Open Source and XP, asking if anyone knew a way to get around the distributed nature of Open Source so XP could be used. I imagine working at home would pose many of the same problems.

Developers with external (non-work) responcibilties (familly, life etc) stand out like sore thumbs if they stick to a 40 hour week when other team members stay late every night.


I don't agree with this one -- this should eliminate this kind of problem that exists in the "traditional" software world. _Everyone_ will work 40 hours, so the family man feels no pressure to work late, because everyone else is going home too.

Don't misunderstand, I would like to try XP but my own circumstances would be at odds to the method immediately. My day begins at 6.00 am and I leave at 16:00 because this arrangement suits my personal circumstances (I have an autistic son who needs my attention). Since I can only change this arrangement for exceptional circumstances how do I pair program or restrict myself to 40 working hours. Do I expect the rest of the team to fall into line with my hours.


Yes, you are definitely in a situation where flexibility of schedule isn't really an option. However, this could help (although your particular hours are a bit early). At my office, many of the developers work from 8:00-16:00, and when I'm paired with them, I come in then to work with them -- I have the priveledge of no restrictions on my schedule, and while I find it a little rough to come in at 8:00 sometimes, it's well worth it when I head home at 16:00.
Your situation probably won't work well with XP. Oh well, it can't do everything. But try to keep it in mind if you do find yourself in a suitable situation.
One other thing I wanted to talk about was some of the ways we did pair programming.
Most of our developers have two computers -- a desktop and a laptop (some bring a laptop from home, others have one supplied by the company). When we're working in a paired situation, we _usually_ both work on the same box. However, having the second box there is extremely helpful.
Sometimes, questions come up that can't be immediately answered by the pair, or possibly anyone else on the team. It's then that the person who isn't currently coding will grab the other box, load up Netscape, and start looking for an answer, or shoot off an email to a mailing list, or some other such thing.
It allows a bit of multi-tasking without the typist ever having to get his head out of the problem space he's currently working on.
Now, we develop on Linux. For other platforms as well, but we code in Linux. As such, we all have our preferred environments. I'm a hard-core Enlightenment hacker with my own hand-made theme and keymappings for everything, with a preference for gvim. Others use Gnome, or KDE, or almost anything else. Some even have a deep religious attachment to emacs.
While there really hasn't been too much of a problem yet (I rarely work at my own desk, since I don't want to force anyone to deal with my horribly tweaked environment, or my Sun-layout keyboard, or my trackball, or any of my dozens of other oddities), I wonder if it's at all possible to do PP with each of us using his preferred setup.
We're currently evaluating a number of IDEs for potential use (maybe we'll start doing Delphi in Kylix), so that would definitely help to create a homogenous environment, but I'm very much of the opinion that everyone should be allowed to do it their own way. Maybe that just won't work here.

Originally posted by Johannes de Jong:
You make a very valid point here Greg. The amount of work done by the staff involved in pair programmning. If the one is a hardworker and other one not. Surely the fact that the work is jointly owned will create tremendous conflict. Its obvious that one has to really know the people that are involved in a project.


Although not strictly an XP technique, there are some good ways to avoid hiring people who don't fit into your team (or to hire people who are exceptionally suited to your team, if you want a positive slant on it). I forget the title of the book -- PeopleWare or PeopleSoft or some such, but they talk about a programmer audition. Would you hire a juggler for a circus without watching him juggle? But you hire a programmer without seeing how he works in a team, particularly _your_ team.
Have the guy come in, have your team take a break, and just hang out with him for a little while (maybe lunch at a nearby restaurant) -- this chatting and such should show if they'll work out together, and if he seems interested (for some reason, this approach gets a more positive response than a one-on-one interview), bring him back for a little pre-hire integration testing. You don't have to have him write code for you, but maybe just sit in and participate in a brain-storming session, or some other full-team activity. Letting him get a feel for the team like this not only shows you if he fits in, but also shows him that you're not just hiring to increase head count, and gives him some real incentive to choose you over the guys that gave him a phone interview, but are willing to pay him an extra grand or two.
Note: this won't work so well in huge teams and with dozens of interviews. But, if you're using XP, that should never be an issue in the first place.
An approach like that, while slightly more time consuming, can be a real project-saver later on.
Also, you mention "joint ownership", but in paired programming, you work on different pieces of code every 6 weeks or so, and with a different partner every three weeks or so. So, really, joint ownership isn't really an issue. Although . . .
I seem to remember XP books talking about no ownership, but I'll tell you what; on XP projects, I feel ownership for every single file in the tree, and I'm never about to hand off work to someone else because "that's his bit". If the rest of the team were to be hit by a bus tomorrow, I feel confident that I could introduce a new team to the nuances of our code and style without wondering "why the hell did he do that bit like that?"

I must say another thing that springs to mind is that Pair Programming could ease the yearly work evaluation one has with the manager regarding increase, education etc. The manager simply gets the input from the people I paired with. He really will know how I performed.


Hrmm, that last brings up a certain question in my mind. I've never had an evaluation at this job. Now, I am fairly compensated, have received raises and promotions, and have quite open discourse with my superiors, but there's never really been a direct performance evaluation.
I don't know if I like that or not -- it's nice that it's very informal, and that I don't feel like I have to fight for more pay, but it also seems like if things deteriorate (which I don't expect), it will be hard to initiate some sort of formal evaluation system.
I use XP at work, but when I get home, I work on Open Source projects. The distributed nature of Open Source seems to make it the least likely candidate for XP. I haven't used any XP techniques in my Open Source programming, and don't really see an easy way to start doing so.
Am I right, are Open Source and XP incompatible, or can someone clue me in to what I'm missing?

Originally posted by landon manning:
Has anyone had the chance to work on an open source software project? If so, what role did you play in it (ie. where you in charge of maintaining the main branch, releasing the software every-so-often, or just as a programmer) and what were your thoughts about it in general.
Also, do you think open source projects are commercially viable?


I've worked on a number of Open Source projects, and I have to say it's the most fun and educational stuff I've ever done.
In my day job as a Software Engineer, we use quite a large number of Open Source applications in every aspect of the business. Most of our servers run Linux, we use CVS for version control, SourceForge for project management, and many OSS libraries in our own projects.
One of the most successful for us is Berkeley DB -- to use it commercially, we pay somewhere over $100,000 (I don't buy the stuff, so I don't know the real numbers), but that was a non-issue, because as most of our developers are into Open Source in one way or another, we knew the software well, and knew it was rock-solid and did what we needed. The fact that it was Open Source is really what made it a candidate in the first place -- we had a chance to play with it for years, so when we finally had to choose a DB to use, it was obviously Berkeley.
Now, the software my company writes is not Open Source, nor do I try to talk them into it. I'm not a business person, and if they let me write code, I let them write business plans. However, the APIs, SDKs, sample clients, etc. _are_ Open. These are not big revenue generators, sure, but having worked with Open Source for a long time, the most frustrating part (and the thing that turns developers against you) is not having an Open API. Users (read: geeks) want to integrate your product into everything (especially emacs), so let them do it. It's great word of mouth, and it lets the geeks play with your code, and lets your developers throw a little something back to the community.
On a side note: I'm going to start a thread specifically on Open Source and XP (if I can't find one), so please come and post there if you have any insights.

Originally posted by Nikhil Kumar:
I thought 40-hours is just a metaphor meaning work only planned hours. If you need more hours, you underestimated, and there is something wrong somewhere in the process, which needs to be corrected before getting into a similar situation in the future. Or does 40-hours mean 40 hours? Please opine.


Well, from what I've learned doing XP so far, the more you use it, the more you realize that there are no metaphors. For example, the index card thing. A lot of people in another thread were talking about using different things -- Post-Its, looseleaf, etc. However, you quickly find that card stock is about as lightweight as you can get before the material is too flimsy to be put in a pocket, thrown into piles, etc. And much larger than 3x5 (we use 4x6 on my project) gives you too much room to write information you'll never use. So, in the end, index cards is quite literal -- they just happen to be exactly what fills the functional requirements.
So, I think 40 hours should be taken the same way, for a number of reasons.
1) That's what you're being paid for. Unless you've negotiated for some other period (I'd happily sign a contract for a 60-hour week if it meant a 50% pay raise).
2) It keeps you from burning out, and if it's "enforced" (or encouraged, if enforced is too strong a word), there's no peer competition to stay the latest or get noticed by the boss. That can often be the way you get to the burn-out.
3) It doesn't mean you can't program after the 40-hour limit. Just move your head into a different problem space (personal project, consultant contract, whatever) and your body to a different location (that in itself can freshen you up).
4) It makes for more friendly paired programming. If one person doesn't want to stop, the other (leaving after an 8-hour day) may feel guilty for leaving the other behind, or may end up burning out, because he _did_ stay to help his partner. Also, you won't be goaded into working late to "beat another team" or whatever.
Paired Programming and the 40-hour week work well together. If you are in a pair, you both have to work overtime or neither. Programming solo is as bad as programming late. And each of these XP "rules" helps enforce the other.

Originally posted by Johannes de Jong:
Hi Greg thanks for sharing your experience. If I may ask, what sort of company do you work for?
And do yourself and your team a favour and complete the survey on
http://www.pairprogramming.com


The company I work for is XML Global Technologies (http://www.xmlglobal.com/), and the particular project I was talking about was GoXML Search, which is a component of the GoXML Foundation suite.
It's a young company, designing XML-oriented technologies. I enjoy it a lot, and find that I have quite a bit of freedom. Our projects aren't extremely large, mainly because, being techie-driven, we have a lot of modular components we've developed.
That's really one of the benefits of XP, I think -- a lot of people complain that it doesn't work well on projects that are too large for a single person to understand completely, but I don't see how a project should ever reach that size.
As we start seeing pieces grow past what we originally envisioned, they get pulled out and are no longer a part of the project any more than a third-party library we might use.
If you start with XP _before_ the project is too large, it protects you from bloat problems. You see when it gets too big (because every time you start working on a different piece, you have to take some time to recall how that piece fits in), and you make some pruning decisions.
Not only does this help your project, but other projects are always happy to find some reusable components floating around (and hey, aren't components the Next Big Thing?).

Originally posted by martin fowler:
In XP it's important to rotate the pairs. Often you might pair with one person in the morning and someone else in the afternoon. This is because different combinations of skills are needed for different tasks, but primarily becuase swapping pairs helps spread knowledge around the team.


I am on a team using PP at the moment. Our project manager and most of the developers are relatively young, and so we have been experimenting with different practices along the way. XP has been by far the most productive approach. And PP the best aspect of it.
There was a bit of resistance from managers at the beginning, but as they pretty much leave us alone, it only trickled in through comments like "What is this, a love in?" and "Did Greg break his hands so he needs you to type for him?"
Recently, we had a major release of our software, and we to the short downtime afterward to go over our practices and decide what worked and what didn't. PP came out on top. Nothing else even approached the productivity of the time we were working that way.
Anyway, the point I'm trying to get to, is that rotation is definitely necessary, but we usually rotated about once every three weeks (occasionally a third person would be called over to explain a particular point, but since the whole project was done in a way that we all understood the whole, it never disturbed the groups much). Every three weeks (give or take -- it was really how long our iteration was) was perfect -- at that point, spending 8 hours a day with the same person is just starting to get on your nerves, and you're ready to move to a new piece of the project (well, every 6 weeks for that part, since you spend two iterations on a particular section), and a new partner.
In a pair, I was more likely to push myself (well, if _he_ doesn't need to take a break, neither do I) rather than slack, and it was always good to be able to pass the keyboard to someone else when your fingers started getting slow, or your eyes blurred.
Also, the novice-mentor thing isn't necessary in my opinion -- it happens for part of the project just because you're in different pairs, and also, I learned plenty from the developers who were less experienced as well. It was fun, and I was more focused than at any other point.
Since I've already rambled this far, I have a completely unrelated note: This is my first post, and I just read, "Disable Smilies in This Post." However, I read it as "Similies", and couldn't figure out for the life of me why you would want to disable similies.