Originally, I had planned to take RH300 (RH302 including the Rapid Course Track) July 9th. When it seemed that a FUDCon was to be held starting July 13th (the day I would have taken the actual exam RH302), I canceled my seat and planned for a long stay at Raleigh, NC -which at that time was the location where FUDCon was to be held. Then, as you all know, FUDCon was moved to either 3-5 August, or 10-12 August, and I really hoped and lobbied for the first weekend, because I knew July 27th, there was a RH302 too. Instead of staying a week longer and then take the RHCE Exam, I'd have arrived a week earlier and took a jet-lag exam trying to pass for RHCE.
Back to the original point of the post; since all that was canceled, I tried to get back a seat in the RH300 course I had planned originally -July 9th. I succeeded ;-)
After a 4 day RHEL5 internal workings re-cap, I thought I was ready to take the exam. I'll tell you right-away, I didn't pass.
Half-way through the exam, the network failed. Not just my network, but the entire network. Obviously, that sucks. The exam got canceled but I gotta say: That shit just happens, there's nothing anyone could have done about it.
Anyway I had to re-take the exam at some later day and of course the sooner the resit, the better. Red Hat apparently had some trouble re-scheduling for today, July 27th, which would have been the first opportunity, if not the RH300 course track planned for that week had been canceled. They told us the next (sure) opportunity would be August 17th (that is a 5 week wait just to re-take the exam), and that they'd try to arrange something for July 27th.
Just now however I got an email from Farnborough asking me why I couldn't attend the resit today, because they seemed to have missed me. I didn't know there was a resit today. I didn't get any seat confirmation, invitation or notification, whatsoever. I didn't get any for August 17th either. I sure hope I get a chance to pass RHCE some time, hopefully without too much trouble ;-)
I seem to be the unluckiest person wanting to take the RH302 exam, ever ;-)
Friday, July 27, 2007
Wednesday, July 25, 2007
Developing in Fedora
You'll usually start developing some feature or application because you think you can create something or improve something else. You'll probably get excited and talk about it and at some point, come across the people that you thought know it all and will catch your drift and help you accomplish whatever it is you want. I've been proven wrong there. Mind that I'm developing a customization tool build upon existing release engineering tools, this doesn't hold up for entirely new tools.
The real test isn't the code. The real test isn't all the bugs you'll get either. Neither does it concern you, what huge pile of feature requests you'll get, or what number of bugs will show up once you try and implement some of these requested features, breaking other stuff in your code. Hell, there's no challenge in doing it 'enterprisey' either. The challenge you had in mind was to get things done, to move forward. That is what it is all about, and that just so happens to be what you're really good at.
Neither of all that is a real challenge, believe me.
The real challenge is to continue working as you see fit, because you'll get flamed from all sides that has people with a different perspective on things. The real challenge is to withstand the temptation of just quitting.
Continuing on building a customization application upon release engineering tools; I'm sure you can appreciate the different perspective on things. Whereas release engineering tools need to be stable and consistent, customization tools can just have their way with it. Don't overestimate the number of features you can add to a release engineering tool; it doesn't need all that, the tool works as is, so your life then is about discussing the need for this or that feature in some upstream tool, not about doing the code and solving the bugs. You'll give up eventually. You'll let them pull whatever they like from your tool.
This is the Fedora world, where everything moves forward fast, faster, fastest. It's a community distribution that does cutting-edge in stable, and for which enterprise linux engineers decide what progresses slow enough to keep track off changes, or what is too fast to really be allowed to be build upon whatever they are on the receiving end of bugs for.
The real test isn't the code. The real test isn't all the bugs you'll get either. Neither does it concern you, what huge pile of feature requests you'll get, or what number of bugs will show up once you try and implement some of these requested features, breaking other stuff in your code. Hell, there's no challenge in doing it 'enterprisey' either. The challenge you had in mind was to get things done, to move forward. That is what it is all about, and that just so happens to be what you're really good at.
Neither of all that is a real challenge, believe me.
The real challenge is to continue working as you see fit, because you'll get flamed from all sides that has people with a different perspective on things. The real challenge is to withstand the temptation of just quitting.
Continuing on building a customization application upon release engineering tools; I'm sure you can appreciate the different perspective on things. Whereas release engineering tools need to be stable and consistent, customization tools can just have their way with it. Don't overestimate the number of features you can add to a release engineering tool; it doesn't need all that, the tool works as is, so your life then is about discussing the need for this or that feature in some upstream tool, not about doing the code and solving the bugs. You'll give up eventually. You'll let them pull whatever they like from your tool.
This is the Fedora world, where everything moves forward fast, faster, fastest. It's a community distribution that does cutting-edge in stable, and for which enterprise linux engineers decide what progresses slow enough to keep track off changes, or what is too fast to really be allowed to be build upon whatever they are on the receiving end of bugs for.
Subscribe to:
Posts (Atom)