text:
Code Coverage is an interesting topic – Wikipedia defines it as "the degree to which the source code of a program has been tested." The idea is that you want to measure what percentage of the lines of code in your application are executed when you run your test suite. The "perfect" test suite would execute every single line of code in your codebase. Being able to definitively measure that goes a long way towards validating your testing suite and giving you confidence that your tests are thorough and testing everything that needs to be tested.
So I was really happy to run across the Delphi Code Coverage tool. I was intrigued and interested, so I downloaded it and gave it a look. And I really liked it. I decided to run it through its paces by checking the code coverage of the unit tests for my THTMLWriter project. It didn't take me long to figure out how to use it. It's written by Christer Fahlgren. He blogged about it back in 2010. It has a couple of other committers, and it's been an active project throughout out 2012.
The project includes this note: "The 1.0 release was made possible through the generous support of DevFactory." I thought that was cool, and so I encourage you to go to their website and check out their services.
The project includes this note: "The 1.0 release was made possible through the generous support of DevFactory." I thought that was cool, and so I encourage you to go to their website and check out their services.
Some things to note off the bat:
So what did I do? Well, first I pulled the source to make sure I had it. Then, I went ahead and downloaded the RC7 build, which has one file in it: codecoverage.exe. I took that file and put it in a folder along my path so I can call it wherever I need it.
Then, I read the nice simple documentation. I was just testing it out, so I ran everything manually via the IDE just to see how it all worked. Eventually, you'd want to integrate this into your continuous integration. So here is a quick rundown of what I did and what I found.
First, I opened up the project options for my THTMLWriter unit test application and told the Linker to create a MAP file for the project when I build it. The tools uses the MAP file to trace all the code paths that the application under test uses.
Next, I looked for the appropriate command line switches.
The resulting command line was as follows:
codecoverage -e HTMLWriterTestAppTests.exe -m HTMLWriterTestAppTests.map -u uHTMLWriter -html
Note that the above command line assumes that the current directory of your command prompt is the directory where the files in question are located. I actually put the command line in a small batch file in the same directory.
Note that the above command line assumes that the current directory of your command prompt is the directory where the files in question are located. I actually put the command line in a small batch file in the same directory.
So then I executed the command. The tool popped up the GUI Runner for DUnit, I pressed the Run button, the tests ran, and when they were done, the tool finished up and produced some output in the form of an HTML file. (It also provided a FastMM dialog at the end of its run, which took a few seconds to appear).
As noted, the result was two HTML files -- one summary file:
and a file that shows me the coverage for the uHTMLWriter unit. That has a header in it that tells me that I have 98% code coverage. Not bad!
But the real fun part is that the file contains a complete listing of the unit, color-coded to indicate which lines were executed (in green) and which weren't (in purple). So 2% of my code isn't covered? So I scanned the file and came across this:
Looks like I never wrote a unit test for the OpenLabel method that takes a string parameter. (I have one for the parameter-less OpenLabel). Okay, so I went back, wrote a unit test for that one, and re-ran the code coverage tool, and now I have code coverage for that method:
Nice! The tool also pointed out that I don't test that a number of exceptions get properly raised, so I'll get working on those, too. I'd like to be able to run the report and have it return 100% for my coverage.
Overall, this is a nice and powerful tool to help you make sure that your unit tests really are running every line of code in whatever you are unit testing. It's another great contribution to the Delphi community. Thanks, Christer.
Okay, let's start off with a question. What do you think this little code snippet does?
Well, I'll bet your first guess is that it processes customer input. Good guess! But what the heck does that False there mean? It's a parameter, and presumably it means something is, well, false, or that you don't want the ProcessCustomerInput to do something, but how can you know? You can't.
Using Boolean parameters means that lose information for the reader of your code. A Boolean parameter communicate nothing about the purpose or meaning of the parameter being passed. Is False good or bad? Safe or not safe? Who knows? Just as above, you can't figure out at all what the parameter is supposed to mean or do if all you see is True or False.
So if you see that in code, the first thing you'll probably do is to go to the method declaration, and if the parameter is well named, you might figure out what the parameter does:
procedure ProcessCustomerInput(aKeepDuplicates: Boolean);
So there you go, now you know what the Boolean parameter does – apparently it tells you whether to keep the duplicates or not. That's great, but the original coder may not always be so kind and clear. So if you must use a Boolean parameter, at least make the parameter name descriptive.
Okay, I take it back – don't actually ever use a Boolean parameter. Instead, here's what I suggest would make for much clearer code:
TKeepDuplicates = (DoKeepTheDuplicates, DoNotKeepTheDuplicates);
procedure ProcessCustomerInput(aKeepDuplicates: TKeepDuplicates);
and that way you can call
And then your code is eminently readable and clear without having to look up the method declaration.
In addition, this way of doing things is expandable. If your business rules change, and a third way of processing customer input appears, your code is ready. With a Boolean parameter, you are stuck with the two options of True and False.
Easy to read, clear, and ready for the future. Just like code should be.
My company, Gateway Ticketing, is hiring again. We are looking for Delphi developers. Actually, having Delphi skills is great, but we are mostly interested in smart people that know what they are doing when developing high-quality software. We love Delphi and C#, but in the end, those are just languages and we know that it doesn't ultimately matter what tool you know, but whether you really know how to write clean code.
Here are some reasons why you should consider working for Gateway:
Okay, look – everyone says they want to hire "rock-star developers". Shoot, even we do it. That's all well and good, but the bottom line is that we are setting our standards really high. And if doing that scares people off, well so be it. We don't want people who are scared off by high standards. We want people who are looking for places with high standards. We expect and demand your very best – anything less and you should find a job writing VB6 code. ;-) We really are creating a world-class place to build software, and we want folks like you to be a part of it. You are up for that, right?
Relocation assistance is available.
And of course, here are the obligatory caveats. We are definitely looking for people to live and work here in the Eastern Pennsylvania/Greater Philadelphia area. Please note: we aren't currently considering remote workers. Naturally, you must be eligible to work in the United States. I'm sorry but right now we cannot sponsor H1B visas. :-( We don't care where you are from or who your parents were or what color your dog is or anything like that. We are really only interested in what you can do. And of course, we want you to know what we can do for you, too.
If that sounds like something good to you, please contact me.
This is the third article in a series about using TVirtualInterface. The two previous articles are TVirtualInterface: Interfaces without an Implementing Class and TVirtualInterface: Next Steps.
This is the third article in a series about using TVirtualInterface. The two previous articles are TVirtualInterface: Interfaces without an Implementing Class and TVirtualInterface: Next Steps.
Okay, enough with the not-all-that-useful examples. I mean, the previous articles were illustrative, but not really "real-world useful".
The true usefulness of TVirtualInterface occurs when you use it to create code where you have no idea what interface the user of your code is going to try to implement. All the examples so far have shown only implementing classes where you do know which interface is being used. The exception so far is the TReportingVirtualInterface example which reports information on any interface you pass to it. Since we have proven that you can use TVirtualInterface to do something useful, let's take it a step further.
A practical use of TVirtualInterface is to create a mocking library for unit testing. I've mentioned numerous times the Delphi Mocks Framework by Vince Parrett of FinalBuilder fame. Another excellent implementation of a mocking framework (as well as a bunch of other very innovative and interesting stuff) is by Stefan Glienke as part of his Delphi Sorcery framework. Both of these use TVirtualInterface to provide a mock implementation for any interface (though the Delphi Sorcery code implements its own version of TVirtualInterface that works with Delphi XE – very cool). Both, of course, allow you to pass them any interface, and they'll happily mock your interface for unit testing purposes. So why not do an example here of a very simple mocking object that you can actually use if you want?
A while back I wrote an article called The Vocabulary of Unit Testing. In it I described the distinction between a stub and a mock. I defined a "stub" as "a fake that has no effect on the passing or failing of the test, and that exists purely to allow the test to run." So, how about we build a universal stub – a class that can pretend to be any interface you want, and not do anything at all. That can't be that tough, can it?
Well, we already have a class that can implement an interface, but we need to find a way for that class to actually be the interface. If you want a stub, the stub has to actually be the interface type you are trying to stub out, right?
First, since we always code against abstractions, let's declare an interface:
ISimpleStub<T> = interface
function InterfaceToCall: T;
And then let's implement it with a descendent of TVirtualInterfaceEx<T>:
TSimpleStub<T: IInvokable> = class(TVirtualInterfaceEx<T>, ISimpleStub<T>)
procedure DoInvokeImpl(Method: TRttiMethod; const Args: TArray<TValue>; out Result: TValue); override;
function InterfaceToCall: T;
Because TSimpleStub<T> descends from TVirtualInterfaceEx<T>, it can implement any interface you pass to it. It thus overrides DoInvokeImpl from TVirtualInterfaceEx<T> as well as implementing InterfaceToCall from ISimpleStub<T>.
First, let's look at DoInvokeImpl:
procedure TSimpleStub<T>.DoInvokeImpl(Method: TRttiMethod; const Args: TArray<TValue>; out Result: TValue);
// Since this is a pure stub, don't do anything!
Not much to see here – it doesn't do anything. And for a stub, that is fine. That's exactly what stubs are supposed to do – nothing. We don't care what happens when the methods get called, you just need to actually be able to call them.
That's where the InterfaceToCall function comes in. The class knows about the type of interface being stubbed because we are passing that type in as a parameterized type. The class itself knows how to implement that interface. There has to be a way to get an actual reference to that implemented interface, right? This is where the InterfaceToCall method comes in:
function TSimpleStub<T>.InterfaceToCall: T;
pInfo : PTypeInfo;
pInfo := TypeInfo(T);
if QueryInterface(GetTypeData(pInfo).Guid, Result) <> 0 then
raise Exception.CreateFmt('Sorry, TSimpleStub<T> is unable to cast %s to its interface ', [string(pInfo.Name)]);
Since TSimpleStub<T> knows the type that T is, you can call QueryInterface on the type information about T itself to get a reference to the interface in question. And of course, once you have that, you can pass that reference anywhere you need to stub out the interface – normally as part of unit testing.
So now, you can safely call methods on the stubbed interface. For instance, given this interface:
IActuallyUseful = interface(IInvokable)
procedure SayHello;
function ReverseString(aString: string): string;
function Multiply(x, y: integer): integer;
Writeln('Implementing a TSimpleStub');
SimpleStub := TSimpleStub<IActuallyUseful>.Create;
WriteLn('Nothing should appear between this and the next statement');
SimpleStub.InterfaceToCall.Multiply(4, 4);
WriteLn('Nothing should appear between this and the above statement');
Nothing happens when you call the interface methods, but that's by design: stubs should do nothing. What you can do is call them as part of your unit testing:
MyClassUnderTest := TSprocketThatTakesAnIWhatever.Create(SimpleStub.InterfaceToCall)
Okay, so there's a useful, dynamic way to use TVirtualInterface. TSimpleStub<T> will work great for a stub that you expect absolutely nothing from. But sometimes you need a fake interface that does something more than just existing, and when that is the case, you are creating a mock. In my unit testing definitions article, I defined a mock as "a fake that keeps track of the behavior of the Class Under Test and passes or fails the test based on that behavior." Thus, a mock needs to do more than exist like a stub – it needs to behave in a way that you can define. So how about we take TSimpleMock<T> and make it do a basic mocking function – responding in a specific way to a specific input.
One of the most common things that a mock interface does is to respond with "this" when passed "that". How about we create a simple mock class that lets you define a specific response to a method call?
First, of course, is an interface to code against:
ISimpleMock<T> = interface(ISimpleStub<T>)
procedure AddExpectation(aCallName: string; aReturnValue: TValue);
The interface augments ("inherits from" is not quite right with interfaces) ISimpleStub<T> and adds the AddExpectation method. This is the method that we'll use to tell the mock out to respond when and interface method gets called.
Here's the implementing class:
TSimpleMock<T: IInvokable> = class(TSimpleStub<T>, ISimpleMock<T>)
FActions: TDictionary<string, TValue>;
procedure DoInvokeImpl(Method: TRttiMethod; const Args: TArray<TValue>; out Result: TValue); override;
constructor Create;
destructor Destroy; override;
procedure AddExpectation(aCallName: string; aReturnValue: TValue);
The first thing to notice is that TSimpleMock<T> inherits from TSimpleStub<T>, thus enabling it to "be" any interface it wants as our stub was. And of course it also implements the AddExpection method. It takes as parameters the name of the method on the interface that you can call, as well as a return value for when that method gets called. In this way you can define the behavior of the mock class however you want.
This very simple mocking example assumes that you are going to be mocking only function calls as methods on an interface. Within the confines of our simple example, it doesn't make sense to mock procedures – they basically don't do anything as far as the simple example is concerned. Real mock frameworks are able to keep track of whether a procedure is called, how many times it does get called, and other things associated with procedures. This simple example also doesn't care what parameters you pass in, it will merely return a value whenever the named method is called. Remember, this is a simple – but useful in specific situations -- example.
This very simple mocking example assumes that you are going to be mocking only function calls as methods on an interface. Within the confines of our simple example, it doesn't make sense to mock procedures – they basically don't do anything as far as the simple example is concerned. Real mock frameworks are able to keep track of whether a procedure is called, how many times it does get called, and other things associated with procedures. This simple example also doesn't care what parameters you pass in, it will merely return a value whenever the named method is called. Remember, this is a simple – but useful in specific situations -- example.
The implementation of TSimpleMock<T> is pretty, well, simple. Internally, it uses a TDictionary<TKey, TValue> to keep track of the method calls and the resulting responses that are added via the AddExpectation call. Here is the implementation of AddExpectation :
procedure TSimpleMock<T>.AddExpectation(const aCallName: string; aReturnValue: TValue);
FActions.Add(aCallName, aReturnValue);
When you add an expectation, the class keeps track of it. When you then call that method on the interface, it is able to retrieve the expected return value from the dictionary and return it:
procedure TSimpleMock<T>.DoInvokeImpl(Method: TRttiMethod; const Args: TArray<TValue>; out Result: TValue);
Result := FActions[Method.Name];
(The obvious shortcoming here is no error handling – you'll get an exception if you try to call a method on the interface that doesn't have an expectation entry. Another shortcoming is that the parameters passed mean nothing – a real mocking framework would be able to provide specific responses for specific parameter inputs. I'll leave correcting this problem as an exercise to the reader. )
(The obvious shortcoming here is no error handling – you'll get an exception if you try to call a method on the interface that doesn't have an expectation entry. Another shortcoming is that the parameters passed mean nothing – a real mocking framework would be able to provide specific responses for specific parameter inputs. I'll leave correcting this problem as an exercise to the reader. )
So now, when we exercise this class, it will actually return stuff that you tell it to:
This code:
WriteLn('IActuallyUseful with ISimpleMock');
SimpleMock := TSimpleMock<IActuallyUseful>.Create;
SimpleMock.AddExpectation('Multiply', 99);
SimpleMock.AddExpectation('ReverseString', 'This is actually working');
WriteLn(SimpleMock.InterfaceToCall.Multiply(6, 7));
WriteLn(SimpleMock.InterfaceToCall.ReverseString('This does not matter'));
has the following output:
Note that the responses are not what you think they would be based on the parameters (you think that 6 times 7 would return 42…), but what you told them to be in the AddExpectation call.
Now, you can use ISimpleMock<T> to provide specific feedback for a given method call. Maybe you have an interface method which returns a Boolean value that you want to test. You can use ISimpleMock<IBooleanMethod> to test what happens when the method returns True as well as when that method returns False.
Okay, so there you have it: A useful implementation of TVirtualInterface. Though the above examples are really simple, they can actually be used in real world testing – particularly the ISimpleStub<T> implementation. Stubbing is common in unit testing, and even though it is a very basic implementation, it can be used to stub out any interface.
None of this is useful if you know what interface you need and how you are going to implement it. But there are cases when you don't know what interface you will need for a particular problem, and you need to be able to flex to whatever interface the situation calls for. Mocking and stubbing are perfect examples. That's a powerful and useful thing to be able to do. Hopefully this little series has helped you see that.
Okay, so my last article was pretty fun – you got a look at TVirtualInterface and how you can use it to implement any interface. Now, I want to be clear – the code in that article was demo code. That is, it was purely for illustrative purposes. I can't think of any reason why you'd actually, in the real world, implement an interface that way. But after reading it, you should be able to see how TVirtualInterface works and how you can get it to do what you want.
Now, in that article I promised you that my next blog post on the topic would be an example of using TVirtualInterface in a more useful manner. But I guess I lied, because this blog post is about how you can create a slightly better version of TVirtualInterface.
So a while back, I wrote a post about getting you to "think generically" and how generics (or as I prefer to think of them, parameterized types) are useful in more ways than just collections and lists. Well, I got to looking at TVirtualInterface and I thought, "You know, here's a class that actually requires type information about a given type, and in order for it to do anything useful, you have to give it a type in the constructor, so hmmm…….". And you can guess where I went from there.
So, consider the following class declaration:
TVirtualInterfaceEx<T: IInvokable> = class(TVirtualInterface)
procedure DoInvoke(Method: TRttiMethod; const Args: TArray<TValue>; out Result: TValue);
procedure DoInvokeImpl(Method: TRttiMethod; const Args: TArray<TValue>; out Result: TValue); virtual; abstract;
constructor Create;
This is a pretty simple descendent for TVirtualInterface. The most obvious thing is that it takes a parameterized type T which is constrained to be an interface descending from IInvokable. That enables you to explicitly declare what interface TVirtualInterfaceEx is going to implement. You should notice, too that TVirtualInterfaceEx is an abstract class, as the DoInvokeImpl method is abstract.
So, once you have the parameterized type, you know everything you need to implement the interface. As you know from the previous article, the thing you need to do is to provide an implementation of DoInvoke. So TVirtualInterfaceEx employs the technique I've described before whereby you implement the interface in the base class and provide a "real" implementation in a separate method invoked by the base class. So, the implementation looks like this:
constructor TVirtualInterfaceEx<T>.Create;
inherited Create(TypeInfo(T), DoInvoke);
procedure TVirtualInterfaceEx<T>.DoInvoke(Method: TRttiMethod; const Args: TArray<TValue>; out Result: TValue);
DoInvokeImpl(Method, Args, Result);
The constructor is pretty simple – it is parameter-less and calls a sibling constructor, passing in the TypeIinfo for your interface and the DoInvoke method which is of type TVirtualInterfaceInvokeEvent. The code for DoInvoke method simply calls the DoInvokeImpl method, which, because it is abstract, descendent classes must override.
Thus, to use this class, all you need to do is to descend from it and provide an interface as a parameterized type and an implementation for DoInvokeImpl. So, if we wanted to implement the IActuallyUseful interface from the previous example, all we need to do is:
TActuallyUsefulEx = class(TVirtualInterfaceEx<IActuallyUseful>)
procedure DoInvokeImpl(Method: TRttiMethod; const Args: TArray<TValue>; out Result: TValue); override;
implementing DoInvokeImpl with the same code that was in the DoInvoke event of the TActuallyUseful class.
By the way, I should mention that the code for these demos on TVirtualInterface, including a sneak peek at the code for the next article, is available as part of my demo code project on BitBucket.
By the way, I should mention that the code for these demos on TVirtualInterface, including a sneak peek at the code for the next article, is available as part of my demo code project on BitBucket.
This isn't anything really fancy, but I liked it because it simplified the process of creating virtual interface implementations and provided another example of a good use for parameterized types. I also like what I mentioned previously, that it clearly declares what interface it is implementing.
Anyway, I thought it was a cool little wrapper/descendent for the TVirtualInterface class. And I promise that the next blog post on this stuff will show an example of using it in a truly dynamic way.
I would be really disappointed if we spent an hour discussing software development and I didn't at least once say to you "Program against interfaces, not against implementations". It's sort of a mantra for me – a way of life if you will. It's a bedrock principle of development as far as I'm concerned. Programing against interfaces and not against implementations is the only way to truly decouple your code. And if you don't believe that decoupling your code is important, I'd like you to stop reading right now, get a small ball-peen hammer, and keep hitting yourself in the forehead until you change your mind.
So if you've made it this far, you'll know that implementing interfaces is needed to use them. You have to put some code behind an interface to make it do anything. Normally, this is done with an implementing class:
ISprocketProcessor = interface
procedure ProcessSprockets;
TSprocketProcessor = class(TInterfacedObject, ISprocketProcessor)
procedure ProcessSprockets;
But what if you could implement an interface without having a specific class? What if there were a way to implement any interface with a single module of code? What if you could decide at runtime how to implement an interface? Would I even be asking these questions and writing this if those things weren't possible?
So, yes, obviously it is. Delphi XE2 introduces a very cool new class called TVirtualInterface. Its purpose is to allow you to descend from it and respond to any interface dynamically. If you think about that for a second you'll realize that this is pretty powerful. For instance, it's the thing that lets the awesome Delphi Mocks Framework provide a mock implementation of any interface that you pass to it.
Generally, when you implement an interface, you provide a class that implements it in a specific way – i.e. that implementation becomes static at runtime. There are ways – typically via Dependency Injection – that allow you to choose an implementation, but even then you are limited to a specific set of implementations. TVirtualInterface allows you to dynamically -- i.e. at runtime – determine how an interface will be implemented. The examples in this article will show a fixed way to implement TVirtualInterface so you can get the basics of how to use TVirtualInterface. In a future article, we'll look at more dynamic ways to use this sweet class.
Here's the public interface for TVirtualInterface:
{ TVirtualInterface: Creates an implementation of an interface at runtime.
All methods in the Interface are marshaled through a generic stub function
that raises the OnInvoke event.}
TVirtualInterface = class(TInterfacedObject, IInterface)
function QueryInterface(const IID: TGUID; out Obj): HResult; virtual; stdcall;
{ Create an instance of TVirtualInterface that implements the methods of
an interface. PIID is the PTypeInfo for the Interface that is to be
implemented. The Interface must have TypeInfo ($M+). Either inherit from
IInvokable, or enable TypeInfo for the interface. Because this is an
TInterfacedObject, it is reference counted and it should not be Freed directly.
constructor Create(PIID: PTypeInfo); overload;
constructor Create(PIID: PTypeInfo; InvokeEvent: TVirtualInterfaceInvokeEvent); overload;
destructor Destroy; override;
{ OnInvoke: Event raised when a method of the implemented interface is called.
Assign a OnInvoke handler to perform some action on invoked methods.}
property OnInvoke: TVirtualInterfaceInvokeEvent read FOnInvoke write FOnInvoke;
First, you should notice that TVirtualInterface descends from TInterfacedObject and implements IInterface. The three methods of IInterface are implemented to allow the class to be properly reference counted like any other interface-implementing class. Second, the interface that you want to implement with it needs to have TypeInfo enabled for it. The easiest way to make that happen is to descend your interface from IInvokable. Otherwise, you'll need to use the {$M+} switch for your interface. Notice, too, that the comment above the class declaration says what I said early – using TVirtualInterface will let you, well, do anything you want with an interface at runtime. Cool.
So, in order to actually make TVirtualInterface do something, you need to create a descendent class and provide two things: a constructor and an implementation of the DoEvent method.
Here's an TVirtualInterface descendent that is as simple an example as I could think of:
TSimplestVirtualInterface = class(TVirtualInterface)
constructor Create(PIID: PTypeInfo);
procedure DoInvoke(Method: TRttiMethod; const Args: TArray<TValue>; out Result: TValue);
constructor TSimplestVirtualInterface.Create(PIID: PTypeInfo);
inherited Create(PIID, DoInvoke);
procedure TSimplestVirtualInterface.DoInvoke(Method: TRttiMethod;
const Args: TArray<TValue>; out Result: TValue);
WriteLn('You called a method on an interface');
The only thing this will do is to write out to the console – no matter what. You can pretend it implements any interface, and no matter what you call on that interface, it will merely write to the console.
The constructor takes a single parameter, PIID, which is is the TypeInfo for the interface you want to "implement". (That's why the interface in question must have the {M+} switch – usually via IInvokable.) Inside the constructor, a call to a different constructor is made. The PIID parameter is passed in, as is a reference to DoInvoke, which is a method that matches the type TVirtualInterfaceInvokeEvent. Thus, the constructor is basically saying "Here is the type of information for the interface I'm implementing, and the method you should run whenever a method is called on that interface."
In our case, the DoInvoke method only does one thing no matter what – writes to the console.
So, for instance, say you declare an interface:
IGoStop = interface(IInvokable)
procedure Go;
procedure Stop(aInteger: integer);
And then you run the following code in a console application:
GoStop := TSimplestVirtualInterface.Create(TypeInfo(IGoStop)) as IGoStop;
the console output will look like this:
You see the output twice because the code called two methods. It doesn't matter what you call – that output will happen no matter what. It doesn't matter what interface you pass in or what method you call, the result will be the same.
But of course that isn't useful – to be of any use, you need to be able to know what is getting called, what is getting passed in, and respond accordingly.
Well, you can do that, because if you look at the signature of the DoInvoke method, you'll note that when it gets called by the TVirtualInterface.OnInvoke event, it gets passed the RTTI for the method that was called, an array of TValue that contain the interface itself and all the arguments that the method was passed, as well as an out parameter of type TValue that allows you to return a value if the method being called is a function.
So how about we simply use the DoInvoke event to report out what all that information that it receives.
procedure TReportingVirtualInterface.DoInvoke(Method: TRttiMethod;
const Args: TArray<TValue>; out Result: TValue);
Arg: TValue;
ArgType, ArgName: string;
TempKind: TTypeKind;
Write('You called the ', Method.Name, ' method ');
if Length(Args) > 1 then
Writeln('and it has ', Length(Args) - 1,' parameters:');
for Arg in Args do
TempKind := Arg.Kind;
if TempKind <> tkInterface then
ArgName := Arg.ToString;
ArgType := Arg.TypeInfo.Name;
Writeln(ArgName, ' which is of the type ', ArgType);
end else
Writeln(' and it has no parameters.');
This code simply looks over and reports out about the Method and Args parameters that get passed in when the interface is invoked. The very first item in the array is always type information about the interface itself, and the rest are the parameters, in order, as they were passed in. Here, the code simply reports out their values and types, but of course, you can process them as you please.
Again, that is interesting information, but it's just a step towards understanding how TVirtualInferface works. Let's create something that actually does what we want it to.
Here's a basic interface:
IActuallyUseful = interface
procedure SayHello;
function ReverseString(aString: string): string;
function Multiply(x, y: integer): integer;
Then, below is the DoInvoke method for a TActuallyUseful class that will actually do what the interface purports to do:
procedure TActuallyUseful.DoInvoke(Method: TRttiMethod;
const Args: TArray<TValue>; out Result: TValue);
if UpperCase(Method.Name) = 'SAYHELLO' then
WriteLn('Hello World!');
end else
if UpperCase(Method.Name) = 'REVERSESTRING' then
Result := ReverseString(Args[1].AsString)
end else
if UpperCase(Method.Name) = 'MULTIPLY' then
Result := Args[1].AsInteger * Args[2].AsInteger;
end else
raise Exception.Create('Bad Parameter name was passed in to the DoInvoke method');
This code should be fairly self-explanatory. It simply checks for the name of the method that was called, and then executes code using the parameter information passed in the Args parameter. If the call is a function, the Result parameter is used to return a value.
You should remember that the initial item in the Args array (that is, the one at the "zero-eth" position) is the interface type itself. The code also makes assumptions about the number and types of the parameters. Since the code can only be invoked by the methods declared on IActuallyUseful interface, the code can make safe assumptions about the types and order of the parameters.
Now all of this code above is fairly straight-forward – we are basically simulating an implementing class in our examples. Nothing is truly dynamic. The code here merely shows simple examples of how TVirtualInterface works in a fairly static way. You should now be able to see how you could dynamically implement an interface using a TVirtualInterface descendent.
Coding against interfaces is critical for writing good, clean code. TVirtualInterface is just another powerful tool in your toolbox for doing just that.
Adapted from my answer on StackOverflow:
function RemoveChars(const aString: string; aCharsToRemove: TSysCharSet): string;
C: Char;
Result := '';
for C in aString do
if not CharInSet(C, aCharsToRemove) then
Result := Result + C;
I talk a lot about unit testing. And why shouldn't I? Unit testing is the key to writing clean, maintainable code. If you concentrate on writing code that is easily testable, you can't help but end up with decoupled, clean, high-quality code that is easy to maintain. What's not to like?
But sometimes, there are questions over the definition of terms when it comes to unit testing. For instance, what, exactly, is a "unit"? What does "mocking" mean? How do I know whether I actually am doing unit testing? In this article, I try to clear up some of those definitions.
The first question that comes up when discussing unit testing is, well, what is a unit? You can't do unit testing without knowing what a unit is.
When it comes to unit testing, I view a "unit" as any discreet module of code that can be tested in isolation. It can be something as simple as a stand-alone routine (think StringReplace or IncMonth), but normally it will be a single class and its methods. A class is the basic, discrete code entity of modern languages. In Delphi, classes (and records which are conceptually very similar) are the base building blocks of your code. They are the data structures that, when used together, form a system.
In the world of unit testing, that class is generally referred to as the "Class Under Test (CUT)" or the "System Under Test". You'll see those terms used extensively – to the point where it is strongly recommended that you use CUT as the variable name for your classes being tested.
Definition: A unit is any code entity that can be tested in isolation, usually a class.
So when you are doing unit testing, you are generally testing classes. (And for the sake of the discussion, that will be the assumption hereafter…) But the key thing to note is that when unit testing a class, you are unit testing the given class and only the given class. Unit testing is always done in isolation – that is, the class under test needs to be completely isolated from any other classes or any other systems. If you are testing a class and you need some external entity, then you are no longer unit testing. A class is only "testable" when it's dependencies can be and are "faked'", and thus tested without any of its real external dependencies. So if you are running what you think is a unit test, and that test needs to access a database, a file system, or any other external system, then you have stopped doing unit testing and you've started doing integration testing.
One thing I want to be clear about: There's no shame in doing integration testing. Integration testing is really important and should be done. Unit testing frameworks are often a very good way to do integration testing. I don't want to leave folks with the impression that because integration is not unit testing, you shouldn't be doing it – quite the contrary. Nevertheless, it is an important distinction. The point here is to recognize what unit tests are and to strive to write them when it is intended to write them. By all means, write integration tests, but don't write then in lieu of unit testing.
One thing I want to be clear about: There's no shame in doing integration testing. Integration testing is really important and should be done. Unit testing frameworks are often a very good way to do integration testing. I don't want to leave folks with the impression that because integration is not unit testing, you shouldn't be doing it – quite the contrary. Nevertheless, it is an important distinction. The point here is to recognize what unit tests are and to strive to write them when it is intended to write them. By all means, write integration tests, but don't write then in lieu of unit testing.
Think of it this way: Every unit test framework – DUnit included – creates a test executable. If you can't take that test executable and run it successfully on your mother's computer in a directory that is read only, then you aren't unit testing anymore.
Definition: Unit testing is the act of testing a single class in isolation, completely apart from any of it's actual dependencies.
Definition: Integration testing is the act of testing a single class along with one or more of its actual external dependencies.
Commonly, developers have used the term "mocking framework" to describe code that provides faking services to allow classes to be tested in isolation. However, as we'll see below, a "mock" is actually a specific kind of fake class, along with stubs. Thus, it is probably more accurate to use the term "Isolation Framework" instead of "Mocking Framework". A good isolation framework will allow for the easy creation of both types of fakes – mocks and stubs.
Fakes allow you to test a class in isolation by providing implementations of dependencies without requiring the real dependencies.
Definition: An isolation framework is a collection of code that enables the easy creation of fakes.
Definition: A Fake Class is any class that provides functionality sufficient to pretend that it is a dependency needed by a class under test. There are two kind of fakes – stubs and mocks.
If you really want to learn about this stuff in depth, I strongly recommend you read The Art of Unit Testing: With Examples in .Net by Roy Osherove. For you Delphi guys, don't be scared off by the C# examples -- this book is a great treatise on unit testing, and gives plenty of descriptions, proper techniques, and definitions of unit testing in far more detail than I've done here. Or, you can listen to Roy talk to Scott Hanselman on the Hanselminutes podcast. I openly confess that this blog post is a faint echo of the great stuff that is included in both the book and the podcast. If you really want to get your geek on, get a hold of a copy of xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros. This heavy tome is a tour de force of unit testing, outlining a complete taxonomy of tests and testing patters. It's not for the faint of heart, but if you read that book, you'll know everything there is to know and then some.
If you really want to learn about this stuff in depth, I strongly recommend you read The Art of Unit Testing: With Examples in .Net by Roy Osherove. For you Delphi guys, don't be scared off by the C# examples -- this book is a great treatise on unit testing, and gives plenty of descriptions, proper techniques, and definitions of unit testing in far more detail than I've done here. Or, you can listen to Roy talk to Scott Hanselman on the Hanselminutes podcast. I openly confess that this blog post is a faint echo of the great stuff that is included in both the book and the podcast. If you really want to get your geek on, get a hold of a copy of xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros. This heavy tome is a tour de force of unit testing, outlining a complete taxonomy of tests and testing patters. It's not for the faint of heart, but if you read that book, you'll know everything there is to know and then some.
A stub is a class that does the absolute minimum to appear to be an actual dependency for the Class Under Test. It provides no functionality required by the test, except to appear to implement a given interface or descend from a given base class. When the CUT calls it, a stub usually does nothing. Stubs are completely peripheral to testing the CUT, and exist purely to enable the CUT to run. A typical example is a stub that provides logging services. The CUT may need an implementation of, say, ILogger in order to execute, but none of the tests care about the logging. In fact, you specifically don't want the CUT logging anything. Thus, the stub pretends to be the logging service by implementing the interface, but that implementation actually does nothing. It's implementing methods might literally be empty. Furthermore, while a stub might return data for the purpose of keeping the CUT happy and running, it can never take any action that will fail a test. If it does, then it ceases to be a stub, and it becomes a "mock".
Definition: A stub is a fake that has no effect on the passing or failing of the test, and that exists purely to allow the test to run.
Mocks are a bit more complicated. Mocks do what stubs do in that they provide a fake implementation of a dependency needed by the CUT. However, they go beyond being a mere stub by recording the interaction between itself and the CUT. A mock keeps a record of all the interactions with the CUT and reports back, passing the test if the CUT behaved correctly, and failing the test if it did not. Thus, it is actually the Mock, and not the CUT itself, the determines if a test passes or fails.
Here is an example – say you have a class TWidgetProcessor. It has two dependencies, an ILogger and an IVerifier. In order to test TWidgetProcessor, you need to fake both of those dependencies. However, in order to really test TWidgetProcessor, you'll want to do two tests – one where you stub ILogger and test the interaction with IVerifier, and another where you stub IVerifier and test the interaction with ILogger. Both require fakes, but in each case, you'll provide a stub class for one and a mock class for the other.
Let's look a bit closer at the first scenario – where we stub out ILogger and use a mock for IVerifier. The stub we've discussed – you either write an empty implementation of ILogger, or you use an isolation framework to implement the interface to do nothing. However, the fake for IVerifier becomes a bit more interesting – it needs a mock class. Say the process of verifying a widget takes two steps – first the processor needs to see if the widget is in the system, and then, if it is, the processor needs to check if the widget is properly configured. Thus, if you are testing the TWidgetProcessor, you need to run a test that checks whether TWidgetProcessor makes the second call if it gets True back from the first call. This test will require the mock class to do two things: first, it needs to return True from the first call, and then it needs to keep track of whether or not the resulting configuration call actually gets made. Then, it becomes the job of the mock class to provide the pass/fail information – if the second call is made after the first call returns True, then the test passes; if not, the test fails. This is what makes this fake class a mock: The mock itself contains the information that needs to be checked for the pass/fail criteria.
Definition: A mock is a fake that keeps track of the behavior of the Class Under Test and passes or fails the test based on that behavior.
Most isolation frameworks include the ability to do extensive and sophisticated tracking of exactly what happens inside a mock class. For instance, mocks can not only tell if a given method was called, it can track the number of times given methods are called, and the parameters that are passed to those calls. They can determine and decide if something is called that isn't supposed to be, or if something isn't called that is supposed to be. As part of the test setup, you can tell the mock exactly what to expect, and to fail if that exact sequence of events and parameters are not executed as expected. Stubs are fairly easy and straightforward, but mocks can get rather sophisticated.
I've written about the Delphi Mocks framework in a previous post. It takes advantage of some cool new RTL features in Delphi XE2. It's also a very generous and awesome gift to the Delphi community from Vince Parrett, who makes the very awesome FinalBuilder. If you have XE2 and are doing unit testing, you should get Delphi Mocks and use it. If you don't have XE2 and are doing unit testing, you should upgrade so you can start using this very valuable isolation framework.
I've written about the Delphi Mocks framework in a previous post. It takes advantage of some cool new RTL features in Delphi XE2. It's also a very generous and awesome gift to the Delphi community from Vince Parrett, who makes the very awesome FinalBuilder. If you have XE2 and are doing unit testing, you should get Delphi Mocks and use it. If you don't have XE2 and are doing unit testing, you should upgrade so you can start using this very valuable isolation framework.
But again, the whole point here is to test your classes in isolation; you want your CUT to be able to perform its duties without any outside, real, external dependencies.
Thus, a final definition: Unit testing is the testing of a single code entity when isolated completely from its dependencies.
procedure ShowHourGlass(Proc: TProc);
Screen.Cursor := crHourGlass;
Screen.Cursor := crDefault;
A while back I tweeted the following:
In software development, we often measure Butt Time, when what we need from developers is Brain Time -- which is much harder to measure.
Some tweets call for further explanation and expansion, and so I've added a new category called Tweet Expansion to cover posts that do just that.
A while back I tweeted the following:
In software development, we often measure Butt Time, when what we need from developers is Brain Time -- which is much harder to measure.
Some tweets call for further explanation and expansion, and so I've added a new category called Tweet Expansion to cover posts that do just that.
Here at Gateway Ticketing, we have an interesting development and business model. At our core, we are an ISV. We sell a software package that we build to customers. But, we also will customize our software to meet customer specifications. That makes us sort of a VAR to our own product. Thus, we do both enhancements based on customer requests and our own internal product development projects to make our product more valuable in the marketplace.
This distinction – between internal projects and projects driven by specific customer requirements – makes for some challenging project management. But we have a solid team here at Gateway, and we make it all work. But because we do work that amounts to us being consultants, we end up having to closely track our developer time. We do that for a number of business reasons, the main one, of course, is profitability. You need to track your time to ensure that you are actually making money on a given endeavor.
Now I know that no one really likes to track their time. It's a pain. It's challenging to be accurate. It's hard to get time properly categorized. But it is also invaluable for making those important business decisions.
But there is a bigger problem with measuring time. The only thing you can really measure is "Butt Time". Butt Time is the actual amount of time someone has their butt in a chair while working on an issue. You need Butt Time to get any work done, of course.
But Butt Time isn't really what you want from your developers. Butt Time isn't at all equivalent to productive development time. Butt Time includes reading email, answering questions and generally handling any number of interruptions, meetings, and other distractions. And those distractions, however minor, break a developer's concentration.
And when you get right down to it, development is all about concentration. With a coding project of any size at all, doing development requires your complete focus and concentration. You need to build up complex data structures and patterns in your mind in order to really be productive. Doing so takes time -- I've heard it described as building a house of cards in your mind. Building that house of cards can take upwards of fifteen minutes depending upon the project. But here's the bummer: It only takes a second for that house of cards to come tumbling down. One distraction can make your fifteen minute investment disappear.
And of course, time spent in "The Zone" – with that house of cards constructed and true, highly productive work getting done – is what we all are seeking. We've all probably had that awesome experience of getting into that zone for hours at a time and wondering where the time went. We know how cool that is – and how precious. That's what we want to measure – Brain Time.
But that's a really hard thing to do. Getting accurate, meaningful Butt Time measurements is difficult enough. But how in the world can you actually measure Brain Time?
I'll argue that you really can't. In the end, Butt Time is only a poor proxy for Brain Time. What we need to do is to try to increase the Butt Time to Brain Time ratio by providing an environment where Brain Time is maximized as a percentage of total Butt Time.
There are ways to do that – ensuring that your developers have an office with a door that they can close is an important first step. The book Peopleware is really the Bible for this, and Joel Spolsky has talked a lot about it as well. Uninterrupted quite time is the key. Leaving developers alone is the key to maximizing Brain Time.
Seriously – you need to get and read Peopleware if you have anything at all to do with leading developers. This is the definitive book on managing software developers. Be sure to get the Second Edition. The physical book is, I believe, out of print, causing the price to be pretty high, but I was delighted to notice that you can now order it on the Kindle .
Seriously – you need to get and read Peopleware if you have anything at all to do with leading developers. This is the definitive book on managing software developers. Be sure to get the Second Edition. The physical book is, I believe, out of print, causing the price to be pretty high, but I was delighted to notice that you can now order it on the Kindle .
Another thing we need to do is to respect – indeed, celebrate – those developers that are quiet and don't say much. We have a not small number of developers here at Gateway that, well, don't say much at all. They come to work, write great code, and go home. They don't have a lot to say. But sadly, we don't always respect this. I'm as guilty of anyone of too often saying super-clever things like "Stop being so boisterous, Meredith" or "Did you say six words today?", instead of recognizing that Meredith is maximizing her Brain Time and, by being quiet, not breaking other team members' concentration. Being quiet is a very valuable virtue in a software developer – both because they themselves are being productive and they aren't breaking other's concentration -- and we should give honor and respect to that.
Butt Time is easy to come by and fairly easy to measure. Brain Time, however, is a precious and hard to measure commodity that needs to be nurtured and respected.
Okay, it looks like comments are working now.
It seems that my little box of flair (links to Facebook, etc) was causing the problem. I deleted it for now.
What a bother.
I notice that I haven't had any comments since April 1, and now I've gotten some emails from some of you kind folks pointing out that commenting doesn't work.
Is that still the case? (Feel free to answer at firstname.lastname@example.com if it is....)
Sorry about that -- I'm not sure what the issue is.
The views I express here are entirely my own and not necessarily those of any other rational person or organization. However, I strongly recommend that you agree with pretty much everything I say because, well, I'm right. Most of the time. Except when I'm not, in which case, you shouldn't agree with me.
Powered by BlogEngine.NET 126.96.36.199
Theme by Mooglegiant and modified by Nick Hodges


text:
I just wrote my second email this month to Kyocera making my displeasure felt at the cessation of production of Contax in conjunction with the non-release of the brand. Bad combination.I know they probably won't resume production but they could at least relinquish the rights to the brand. Anyway, I'm not sure what the best address to write to is. Anyone know?I'll keep letting them know that I won't be buying any Kyocera products until they do so [a href=\"index.php?act=findpost&pid=71029\"][{POST_SNAPBACK}][/a]
I understand that Zeiss is presently in japanese court with Kyocera on this very issue of relinquishing the manufacturing rights for Contax.[a href=\"index.php?act=findpost&pid=71148\"][{POST_SNAPBACK}][/a]
Carry on, Don Quixote! As a Contax owner, I admire your fighting spirit, but what are you going to hold over them, bankruptcy? :)[a href=\"index.php?act=findpost&pid=71184\"][{POST_SNAPBACK}][/a]
Carry on, Don Quixote! As a Contax owner, I admire your fighting spirit, but what are you going to hold over them, bankruptcy? [a href=\"index.php?act=findpost&pid=71184\"][{POST_SNAPBACK}][/a]
This contact page is the best I have found:https://www.kyocera.co.jp/inq_e/inquiry_optical.htmlAll you Contax owners out there, here's your chance [a href=\"index.php?act=findpost&pid=71655\"][{POST_SNAPBACK}][/a]

subset: commoncrawl


text:
Car Forums / Acura / Acura RL
Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Have you recently bought/leased a new car online and requested a home delivery due to coronavirus? A reporter would like to speak to you; please reach out to [email protected] by 4/2 for more details.
Meet your fellow owners in our Owners Clubs
Acura RL Tires and Wheels
Planning on purchasing a new RL with Tech Pkg. I was also thinking about the Pax tire pkg. Today I was reading a forum about them on the Honda Odyssey page. Owners claim they last less than 25,000 miles, dealers don't have the machinery to mount new Pax tires on the rims. Many were forced to purchase new tire and rim combos already mounted for exorbitant costs. Wondering if Acura owners/dealers are having the same problems?
spicymikey Posts: 75Ross I'm in the same boat. Looking at RL's. Love teh CMBS package but hate the PAX. Not sure where you are but I did research in Orlando and here's what I found.
- None of the 3 Acura dealers have the equipment
- 2 Honda dealers have the changer but they don't carry Acura RL tires (245/680's)
- 1 Tire Kingdom has tires and the machine
- All want about $300 per tire plus about $100 to install
Bottom line; I don't think it's as bad as it has been in the last couple years (be careful a lot of postings you read on the web might be old). However, it's definitely not a good situation. Honda/Acura is being stupid to not make the PAX an option by itself. I'm sure they're loosing sales. In fact a class action suit was just filed in March against Honda and Michelin over these tires. It's a mess. I've decided to stay away until I see if the '08 models get "de-paxed". if so, I'll buy the CMBS package.0
carfan28 Posts: 43The other problem is that there aren't that many RL CMBS/PAX models being produced. If you want the RL TECH package you could easily find the color exterior/interior you want, if you want the CMBS/PAX model you'll have to settle for whatever color they happen to have. At my NJ dealer they receive 5 RL techs for every CMBS/PAX they receive.
I've used the CMBS on the RL and the M35- not impressed. The M sales rep was very specific on how to turn it off- apparently Infiniti receives many complaints about all the false warnings.0
frank52 Posts: 1My 2005 Honda Touring Odyssey with PAX tires is the worst purchase I have ever made. This is the most costly vehicle I have ever owned. What a problem getting the tires and the cost is huge. No spare came with this vehicle. At the time of purchasing, I was told the tires would not cost much more that regular tire and the cost would come down because more vehicles would have them, I have spent a lot of money on tire replacement. This will be my last HONDA. Will probably bite the bullet and trade soon.0
I have a 2005 Acura RL with 41000 miles on it and I am looking to replace my tires. I don't see many choices other than Michelins and they want $275 dollars a tire. Does anyone have any recommendations on a good replacement?0
cstiles Posts: 465The OEM Michelin HX MXM4 tires cost $238 each on Tire Rack. Two better choices would be the Michelin Pilot Sport A/S at $223 or the Dunlop SP Sport 5000 Asymmetrical at $180. Any of these can be shipped by Tire Rack to a reputable intaller and you can save at least $100 or more.0
I heard that the Dunlops aren't any good. Most say to get the Pilot Sport A/S. I talked to a guy at Sears and he stated that Dunlops have been discontinued. I guess I'll be looking at the Michelins. Thanks for the response.0
georgeoneil Posts: 1Love my 2005 RL, hate the road noise - ( I have 120,000 miles on it!) Looking for new tires, but hoping to find something to reduce the horrible road noise. Any suggestions out there?0
laurasdada Posts: 3,578I purchased Toyo Versados for my '05 TL. Smoother, quieter than the Bridgestone Turnaza OEM. But, appear to be worse in the snow, so for the first time in my 30 years of driving FWD cars, I bought snow tires.
Of course, here in Boston, prior to buying the snows: Almost 2.5 feet of snow. Since buying the snow tires: less than an inch of snow. Now that I've made the large, unexpected purchase it may never snow in Boston again... :sick:
'13 Jaguar XF, possibly my favorite of all the cars I've owned. But, my '09 Jag XK was a beauty, as was my '05 Acura TL, '88 Acura Integra, '84 Mitsubishi Mirage Turbo & '78 VW Scirocco (my first!). And, of course, the '92 Nissan Sentra SE-R and '95 Saab 900s I bought for the ex... Ok, I like a lot of the cars in my life.0
10sfan Posts: 136Living in the upper Midwest, have over 20K with these tires on my RL. Quieter, good handling on wet pavement and on snow covered roads. Last winter had a tremendous amount of snow and they did well.0
We bought a "new" RL--an 06 bought in 07 from the dealer, a "demo" with all the bells and whistles (It had 5,000 miles on it, but we got it for a "steal" compared to the sticker price. OOOOO--PAX tires, whatever that is--the f'ing car has no spare tire...ehem, there is a lawsuit pending over the whole PAX tire system (only on RLs and Honda Odysseys)
No spare tire kits are available at the dealers here in the San Joaquin Valley--they don't even have a part number to order it...America's Tire Company has four tires available mounted, balanced, etc., for $1875. Hell, the Car is barely worth more than that.
"Run flat" tires are supposed to be able to carry the vehicle up to 100 miles on a flat tire. Gee, some shortsighted emngineer somewhere seems to think that there is a PAX tire busting station within 100 miles of anywhere.
Anyhow, some wiseguy lawyer firm has gotten Honda Acura to agree to the following tentative settlement (after you have put out the money, it's a maybe): $110.00 if you show proof that you paid $108.00 for a spare tire kit for the PAX. $300 to $400 if you purchased another Honda Acura vehicle.
Such a deal! I wanna buy another RL....0
My suggestion--get regular tires--you'll save quite a bit...however, the problem--same as before--NO SPARE...(:--((
I will NEVER again buy a run flat tire system in my life--more because of lack of a spare than the higher price--I always picture myself out in the middle of nowhere--with--a flat tire and no spare. BOO on Acura and Honda for this boondoggle.0
OK, I'm new to the forum because I picked up an '06 RL last week. Love the car! The technology is great, it has only 25,000 miles and is in fantastic condition. Before I bought it, I had test driven this car around some local roads and did take it on the highway, which, at that time, didn't cause me any concern. However, after driving from the Philly suburbs to Long Island and back this weekend, my ears are killing me! The road noise on various surfaces was, frankly, unbearable. My '05 MDX is as quiet as a cathedral compared to the RL! What gives? All the review spoke about how quiet this car was and that it has the active Bose noise dampening. Not mine: I think the noise was actually echoing around the inside of the car. I could barely hear the radio. So, I'm guessing that it's not the car's sound-proofing but the Michelin tires that are the culprit. From all that I've read here, these tires basically suck for road noise once they get some miles on them. Sadly, my tires are in great shape.
But, I'm so disgusted with the road noise, I'm ready to shell out >$500 for some quite driving. Here are my questions:
1. Are the Michelin Pilot Sport A/S and Michelin Pilot Sport A/S Plus the tires of choice on this car as a replacement (I will be driving in a little winter snow)?
2. What else will give me a quite and fairly responsive ride without breaking the bank?
3. Lastly, has anyone tried to add more sound dampening materials to either the outer wheel wells or inner wheel wells (trunk space and/or behind rear seat carpeting)? I did a search for sound dampening and it looks like there are a number of people who are into audio sound that have experimented with increasing the sound dampening in the wheel wells and trunk with some success. Should this be necessary on a $50,000 (new) car?0
At JJAcura's recommendation, I replaced the tires on my 2005 RL with Bridgestone Turanza Serenity. Immediately afterwards I took a 500-mile drive. They are far quieter than the Michelins that came on my RL. Since most of the trip was freeway driving in good weather, I can't attest to his comments regarding handling, but on most of the surfaces during the trip, the tires were nearly totally silent. A big improvement! They are not cheap, though, unless you order them over the internet.0
Thanks for the reply. As you can tell, I'm looking for peace and quiet in a performance tire. The reviews at tirerack.com (http://www.tirerack.com/tires/tires.jsp?tireMake=Bridgestone&tireModel=Turanza+- Serenity&vehicleSearch=true&fromCompare1=yes&partnum=45VR7TS) give it very good ratings on ride and noise comfort, with decent snow capabilities. Tread design doesn't look as aggressive as the Pilots but that might be a good thing regarding road noise.0
cmhsec1 Posts: 1I just purchased a 06 RL with 50K miles on it, with some miles left on the Michelins. The highway road noise coming off of the tires is unbearable in all but newly paved highways. Now that you have had the Bridgestone Turanza Serenity tires for a couple of months, how is the noise? Thanks.
I actually didn't get new tires. I made some adjustments in the air pressure of my tires and that made a huge difference. Very bearable now. The manual says to run 30 psi in the fronts and 32 psi in the rear. I'm running about 32 all around and it's much quieter than before. I'm going to go as long as I can before I shell out $700.00 for tires. But when I do, it will most likely be either the Bridgestones or Toyos. I've heard good things about both on this car.0
I couldn't be happier with my Bridgestone Serenity tires. They are so much quieter than the Michelins.0
jensad Posts: 388Me too. I got rid of the Michelins and got the Bridgestone Serenity tires for my RL and I have much less noise and less harshness on the road. And many years ago, I only purchased Michelins on all of my cars but not today.
Good luck to all and stay safe.
Interesting to note how quiet the various Acura RL forums are these days. This was the only forum that has recent posts. Maybe it's time for a new distinctive RL design to come forward and create some excitement!!! As it is the redesigns have given me pause thus far. I don't want to leave Acura after all these years but I will continue to drive the 2005 until they give us something to get excited about!!! I have a long time Acura friend who hasn't left the "fold" as yet but he too is very disappointed. I do however continue to be very happy with the 2005. Still love the design and the performance so far has been unequaled by any auto I have owned over the last 50 years. Like all good things however it won't last forever and I am looking forward to some better Acura designs. The Bridgestones were a good move. (Good to see Nebraskaguy as well)
Thanks, JJ, good to see you too. I too am still very happy with my 2005 RL and am awaiting the next generation, hopefully next year, before I make my next move. I must say, it'll have to be pretty good to keep me in the Acura family.0
pat Posts: 10,421Keep in mind that as soon as you post in any discussion, it then has "recent posts" - feel free to wake any of them up at any time!0
Thanks Pat0
baker8 Posts: 3We bought an RL new back in '06. The road noise was really bad on anything other than new pavement or a special blacktop WADOT is testing on roads. Forget about riding in the back seat. No way. The noise cancelling audio system is a joke.
After the original stock tires that came on the new RL wore out, we replaced them with Bridgestone Turanza Serenity. I noticed just a little improvement, but mostly we both considered it almost as noisey as the 1996 Honda Accord we use a a backukp car.
The Bridgestone tires are a bit more sensitive to road vibration. We took it back to dealership a couple of times for balancing. We're pretty sure now that the tires are more sensitive to road vibration. Increasing the tire pressure a little seemed to help some. Good tires otherwise.
Bottom line, I don't think we'll buy another RL until the reports from other drivers indicate that Acura has really fixed the problem. It's such as easy thing to do; the technology is out there and at the price Acura asks for RL's, one would think noise would never be an issue.
Maybe in other countries in the world, their highways don't have these awful grooves created by people who drive on studded tires ~6 months out of the year. So drivers there won't notice the road noise as much. In Washington, however, studded tires are used by a lot of drivers (not us) and within a few years, those tires can ruin a highway.
We find ourselves driving on edge just outside of the grooves and just inside of the lane lines. It's a bit more precarious but quieter, so one has to be very alert.
Hope this helps.0
michael0137 Posts: 58Uggh...studded tires CAN ruin roads - they should be outlawed. NY allowed them years ago - don't think they do amy more. Odd to hear a car with them - mostly VT and NH cars visiting.
As for road noise - an Acura will never be a Lexus - they simply aren't designed that way - same with BMW - you will hear road noise - it is part of the "driving experience" - not being wrapped in a cocoon like Lexus - which I call the Japanese Buick.0


text:
'This is a great notebook for gamers who are willing to spend additional money on peripherals. ». ». ». ». ». ». ». ».'
'perfect gaming laptop'
'great gaming notebook'
'sleek, angular design and gunmetal gray exterior'
'strong laptop'
'innovative cooling system'
'This is respectable for a large gaming notebook.'
'solid mobile system'
'big, highly polished VAIO logo'
'the VAIO NW was able to deftly handle our flick's fast-moving action scenes at 1080p resolution.'
'handsome laptop'
'Mediocre speakers..'
'well-designed, well-rounded laptop'
'The mobility of the 14.1-incher is rather weak.'
'the Sony VAIO VPC-EA33FX/B is great for most kind of uses, it can handle all your tasks very fluently.'
'the Sony VAIO VPC-EB11FX/T is used ideal for excursions, you will experience wonderful movies with this Sony laptop, of course, it is also good for games.'
'Mediocre battery life.'
'colorful and affordable 15.5" widescreen laptop'
'The 16:9 aspect ratio makes it suitable for watching widescreen DVDs.'
'very popular laptop'
'It is too heavy for sub-notebooks. 14 inch displays are normal for this class of weight.'
'faint ergonomically sensible 15.6-inch HD display'
'this notebook was designed to look clean and simple.'
'chic notebook'
'elegant black and silver system'
'full 5.1 channel surround sound system'
'by Kevin O'Brien The VAIO FW is a brand new Centrino 2 platform notebook from Sony, offering a much needed facelift, as well as a 16.4" widescreen.'
'literal laptop computing'
'Measuring 14 inches wide, 11.2 inches deep, and 1.6 inches high, the Asus G1 sits somewhere between the mainstream and desktop replacement classes of laptops.'
'new laptop'
'midsize laptop'
'A rare attempt at building a 15-inch gaming laptop comes close to succeeding.'
ReviewGist helps you find the best products to buy by making sense of online reviews.
We are currently aggregating 376,500 reviews
covering over 29,474 products.
© 2020 ReviewGist.com. All Rights Reserved.


text:
Mike Staszel, Kugler Maag
The international standard ISO 26262 was created as the core of functional safety guidance in the automotive industry. Since its publication in November 2011, many OEMs and suppliers around the world have adopted it and accumulated many important experiences. This presentation shares our observations on the obstacles and challenges companies typically struggle with as they consider functional safety and adopt ISO 26262. We also share our view on the technical and organizational competencies companies should have in place in order to develop products and systems successfully under the standard, particularly in light of their roles in the supply chain (OEM, tier I, tier II, component and/or tool supplier, etc.). Lastly and most importantly, we look at the impact that development tools have on the successful design and release of automotive systems under the standard.


text:
Deli (Terrell Tilford) owns the struggling restaurant Elmina's Kitchen in a seedy London borough of Hackney. An ex-boxer, Deli is a fairly decent cook and an even-tempered shopkeeper. His restaurant survives on phone in take-aways orders and the patronage of his few regular customers, Clifton (Basil Wallace) and Digger (Noel Arthur), a local bookie that Deli has known since he & Digger were both kids.
It is because of that life long friendship that Digger rejects the constant overtures he gets from Deli's teenaged son Ashley (Aaron Jennings). Ashley is bored with school and with working for his father at the restaurant, while being completely seduced by Digger's apparent power and wealth. The allure of the thug life is strong with Ashley.
On the eve of the release of Deli's brother, Baygee (Leon Morenzie), Deli's father lands as part of an impromptu welcome back gathering. Animated and gregarious Baygee is filled with stories and song, all of which fail to penetrate Deli's disdain for him. The shop also receives a visit from the vivacious, attractive Anastasia (Tracey A. Leigh). She has seen the restaurant and decided that she would not only like to work there, but that she will also help bring some semblance of respectability to the establishment.
The first change Anastasia demands is that Deli send Digger packing, claiming that he is the one keeping customers away. For her, for his son and for the restaurant, Deli tells Digger to stopping coming around; Digger does not take this the new mandate lightly. Stung by Deli's betrayal, Digger no longer treats Ashley like forbidden fruit and quickly, but quietly lures the teenager into a life of crime. In the end, it is a race to see it these father's can connect with their sons before society and circumstance swallows them all whole.
Elmina's Kitchen is a power piece of writing. More than any play I have seen in some time, the piece illuminates the formidable chasm that has insinuated itself in between the generations of the later 20th and early 21st centuries. There are quite a few of us out these who are fortunate benefactors of the practice "it takes a village" – before a famous politician coined it within pop culture. Yet those days seem so far behind us, and families, as a result have become increasingly isolated in their daily struggles, leading to a society that is dangerously fragmented. Kwame Kwei-Armah's play reminds us that the phenomenon is indeed a sociological question more so that a geographic one; that disenfranchisement breeds discontent, regardless of continent.
Congratulations are in order to director Gregg T. Daniel for his thoughtful, taut direction, particularly in the threating of an "Ancestral World" that served as the connective tissue between past and present, and an ingenious, visual cue of the play theme. Noel Arthur stands out for his performance of Digger. Arthur's Digger is a small time thug that is both sunny and playful, but effortlessly turns dark and dangerous in a dime. His performance gives Digger power, vulnerability, and surprising shades of honor. Well Done.
If I have one criticism, it would be my dismay about the only female character in the play. In her introduction, Anastasia is the catalyst for much needed change, pushing Deli forward to something more hopeful. Ultimately, she character turns out to represent at worst sex, and at best chaos. I didn't understand the dramatic necessity of her downfall; it seemed to come out of nowhere. Elmina's Kitchen is undeniably a piece about the interrelationships of men; I guess I just wished the playwright could have made more honorable use of the play's only female character.
Elmina's Kitchen is currently running through September 9, 2012 at:
The Lost Studio
130 S. LaBrea Avenue
Los Angeles, CA 90036
(Between 1st & 2nd Streets)
Ticket info: 323.960.4451


text:
The first project by the U.S.-based internal development team at Sammy, Darkwatch is a sci-fi western first-person shooter for PS2 and Xbox. Best described as Halo meets Silverado, Darkwatch tells the story of the unlucky cowboy Jericho Cross. A train robber by trade, Jericho spots an unusual target racing down the tracks under the light of the full moon and decides to pillage it as his final score before retiring. Jericho is shocked to discover that the unusually designed train is packed with rotting bodies with a humanoid look he cannot recognize. Cross soon finds himself in a battle for his life against a horde of vampires and other nasties.
Sate your bloodlust with our in-depth guide.
When it comes to first-person shooters, there's a new sheriff in town. And this one has some pretty sharp teeth. Read More »
Capcom's vampiric Western shooter swoops in for a bloody dose of revenge. Read More »
Darkwatch has had it rough throughout its developmental life. Who would've thought a promising, pretty, and original shooter would have to wait so long and work so hard to find a publisher? Developer High Moon Studios deserves a cold beverage for persevering. Still, the story seems to have a happy ending, as there's no better company to put out the game than those zombie-lovers at Capcom. Read More »
The famous game company from Japan is publishing the premier game from High Moon Studios. Read More »
High Moon Studios' epic vampiric first-person shooter is very nearly here. Read More »
Also known as: Dark Watch, Darkwatch: Curse of the West
Also available on: Xbox
For more info on these technical requirements and features, please view GameSpy's Specs FAQ.
Darkwatch at IGN
Darkwatch Cheats at IGN
Darkwatch Guide at IGN
Darkwatch at GameSpy
Darkwatch at GameStats


text: Dan Snaith's early recordings as Manitoba underlined his status among the chattering electronic classes as one of the brightest talents to emerge during the early 2000s. Having already proved himself master of the sublime with his 2000 debut EP, People Eating Fruit, the Canadian's subsequent Paul's Birthday EP opened him out even further. After moving to London, he released an excellent second album, Up in Flames (2003), that saw him become a darling of critics. One year later, however, Snaith was forced to give up the name Manitoba after Dictators frontman Handsome Dick Manitoba sued for trademark infringement, despite the passing of 15 years since the release of the only material under his name. Snaith renamed his project Caribou, his two previous full-lengths were reissued under the new moniker, and he released his first new Caribou album, The Milk of Human Kindness, in 2005 for Domino. Snaith moved to Merge for 2007's gorgeous Brit psych-influenced Andorra -- which won Canada's 2008 Polaris Music Prize -- and 2010's more dancefloor-oriented Swim. Shortly after the release of Swim came two lesser entries in the Caribou discography, the self-explanatory Swim Remixes and a busy live album entitled Caribou Vibration Ensemble, both released in 2010. The latter found Snaith conducting a 15-piece ensemble that included four drummers over the course of several live dates in 2009. It would be four years before the sixth Caribou studio album emerged with the bouncy underwater rhythms of 2014's Our Love. ~ Kingsley Marshall


text:
Wanted Pages in this Wiki
Wanted pages are pages that are linked to but have not yet been created. Consider filling in information on these pages. The link counter next to each page title references the number of links inside the wiki guide pointing to that page.
EBay Black Friday 2017 Deals (2 links) Origin (1 link) Steam (1 link) Amazon Cyber Monday Deals 2014 (1 link) Cyber Monday 2013 (1 link)Expand Navigation


text:
This week
I was born in 1972. I'm going to be 40 years old this year. Joe Paterno had been the head coach for Penn State University for 46 years, and he had worked with the Penn State football team for 61 years. I am from Pennsylvania, and while I didn't become a football fan until I married a man from Green Bay I still grew up knowing Joe Paterno's name. Pretty amazing since no one in my family watched football. There has never been a time in my life that Joe Paterno's name was not around and associated with Penn State Football. He was loved and respected by all, whether or not you gave a rat's butt about football.
Additionally, those of us from Pennsylvania (and probably the neighboring states) would look at Joe Paterno and we would see a sweet, cuddly man. Sorry, but I see a picture of Paterno and I just want to hug him. He is very much a grandfather figure to many of us, and who doesn't love a grandpa?
Is it natural to feel this way about someone you've never met? From a college that I didn't even attend? No...it's not, but he was no ordinary man. His coaching record was no ordinary record. And his tenure at Penn State was of no ordinary length. He truly was one in a million and I would say that most people that live/lived in Pennsylvania or that attended Penn State probably feel like a little piece of them is gone right now. A piece of sports history and Pennsylvania history has written it's final chapter, and it's sad when such an epic tale ends.


text:
Redshirt sophomore Caroline Douglas recorded a match-high 11 kills on Saturday against Coastal Carolina.
A triple-double from senior Jade Craycraft and 11 kills from redshirt sophomore Caroline Douglas helped Liberty sweep visiting Coastal Carolina, 3-0 (25-20, 25-20, 25-21) on Saturday in front of 1,003 fans at the Vines Center. The Lady Flames are now 5-15, including 4-3 in Big South play, halfway through the conference schedule. The Chanticleers fall to 11-9, with a 4-3 Big South record, after having a three-match winning streak snapped. Liberty won for the second night in a row, after sweeping Charleston Southern on Friday night. With the win, 10th-year head coach Shane Pinder became the third volleyball coach in Big South history to record 100 career regular-season conference victories. His teams have gone 100-37 (.730) in Big South play. For the match, the Lady Flames hit .283, while Coastal Carolina posted a .104 attack percentage. Liberty outdug the Chanticleers, 35-26, but the visitors held a 6-5 edge in aces and led, 11-3, in blocks. Craycraft recorded her third triple-double of the season, and fourth of her career, with 10 kills, 30 assists and 11 digs. She is now ranked fifth in program history with 3,831 career assists, passing Laura Miller (1990-92). Douglas, in her first extended playing time of the season, scored 11 kills at a .364 pace. Senior Lillie Happel posted eight kills, while junior Gabrielle Shipe collected 11 digs and added two aces. Kindra Bailey led Coastal with nine kills and six blocks, while Gabriella Horvath served up a match-high three aces. The Lady Flames used a strong hitting performance to gain an early 21-13 advantage in set one. A Happel kill then put Liberty on top, 22-15, before Eszter Nagy recorded a kill and an ace during a 4-0 Coastal run. Craycaft quelled the visitors' rally with a kill, 23-19, before Liberty clinched the opening frame, 25-20. Liberty outhit Coastal, .464-.188, during the first set, getting four kills each from Nzea McQuitery and Douglas. Nagy countered with five kills for the Chanticleers. The visitors held a 17-14 lead midway through set two after a kill from Lian Bernett. Craycraft then scored a pair of kills, sparking a six-point surge by the Lady Flames. After Coastal trimmed the margin to two, 20-18, Douglas and Rollins both connected for a pair of kills and Liberty won the second session, 25-20. Coastal Carolina picked up its blocking game in the second set, registering four blocks. The Lady Flames still managed to hit .314, compared to .105 for the Chanticleers. Nagy recorded two solo blocks, and Kendle Rollins scored five kills for Liberty. The Chanticleers' fifth block of set three made it 18-17, Lady Flames. Following three rally points, Rollins served up an ace for a 21-18 lead, and a Happel-McQuitery block increased the lead to four. Horvath then registered a kill, but it was not enough, as Liberty secured the sweep, 3-0, with a 25-21 set-three win. Both teams hit below .100 during the final frame, with Coastal posting five blocks and Liberty totaling two rejections. The Chanticleers' Bailey registered four blocks in set three. Liberty next heads on the road for a weekend trip to South Carolina. The Lady Flames will play at Presbyterian College on Friday at 7 p.m. before facing Winthrop in Rock Hill, S.C., at 2 p.m., Saturday.


text:
Saturday, April 15, 2006
Faith Versus History
"This is one Christian who doesn't think she's been lied to all these years and my opinion regarding Judas has not changed...I didn't learn anything new."
Well, don't I sound like a narrow minded pompous ass!
Many thanks to Kevin who commented,
"You've talked about challenging the traditional views of your students in the hopes of getting them to a more mature thoughtful interpretation of American History. Why is there a different standard to the historical Jesus?"
Kevin has correctly slapped my hand and I appreciate it. There shouldn't be a different standard but perhaps, just perhaps, there is a double-standard because those of us who have the ability to apply historical analysis and also have faith are afraid--------afraid they will analyze their faith until it disappears.
Rev. Albert Mohler, Jr., president of the Southern Baptist Theological Society commented on the Gospel of Judas. He said, "the Judas gospel has no bearing on the Easter story much less on the faith of the Christian church." He dismissed the gospel as "nothing more than an ancient manuscript that tells an interesting story."
Without faith isn't that a description of the entire Bible?
Monsignor Walter Brandmuller, president of the Vatican's Committee of Historical Science called the gospel "a product of religious fantasy. There is no campaign, no movement for the rehabilitation of the traitor of Jesus."
These two certainly seem to be close-minded but as spokesmen for their faith what do you expect?
I thought the National Geographic show was good. They fully explained about the supposed author(s) of the gospel strongly suggesting that the text leans towards Gnostic teachings. At the time the New Testament was canonized none of the Gnostic writings that were known at the time were included. They were thought to be radical and apparently to the two religious spokesmen above they still are.
How does a person accept the Bible literally with the knowledge that it is a human product subject to exaggerations and omissions? How do we determine the author's authority or motivation? Some would say this is where faith would enter into the picture, but it's hard to reconcile historical facts alongside a literal Bible.
Getting back to what I wrote the other day.....I didn't learn anything new other than the specific information concerning the finding and saving of the gospel. I already knew the information about how certain writings were included in the Bible while others were left out. I already knew that the early Christian church had incorrectly allowed followers to use the Bible's treatment of Judas as a reason to place the blame for the crucifiction of Christ at the feet of the Jews.
I correctly advised the other day that the special didn't change my mind about Judas, and it didn't. My mind wasn't changed because I've never really bought the whole story that Judas conspired to turn Jesus over. Jesus told Judas to go and do what he has to do. Readers have no knowledge as to what might have transpired before. Someone had to turn Jesus over.... Peter denies Jesus three times as predicted. Have we blamed Peter for 2,000 years?
I do think that the Gospel of Judas is an important find that will continue the debate for faith vesus history, but unfortunately it won't end the debate. Humans don't know the absolute truth because it is beyond us, but the journey attempting to get there certainly is interesting.
If you want to read more about faith versus history visit Kevin at Civil War Memory (see my blogroll) and read his fantastic post titled, "The Historical Jesus and the Lost Cause".
3 comments:
- Unknown said...
Very interesting post. If faith is trust in God, what is trust in faith?
- Time Bandit said...
Let me just totally disagree with you here. Baptist Mohler and Catholic Brandmuller are not "closed minded," and are speaking out of prejudice. Their words carry the weight of informed opinion developed after analysis of the Gospel of Judas. No scholar who's looked at this manuscript think that it's the actual words of Judas.
It is an interesting manuscript of the early church, to be sure, but it is from a time at least a century and a half after Judas himself would have died.
I'd also disagree with Kevin who suggests that we hold historical analysis of Jesus up to the same critical inquiry use for analyzing other aspects of history. I don't do that in my class. I don't think it's right.
In our society, religion falls into a protected category, just like free speech, free press, firearms, and personal privacy. A public employee needs to take pains not to tread over a student's religious beliefs and values. In world history we will often look at the effects a particular faith may have on human events. In geography class we look at the impact religions have on different regions and cultures.
But the day I start using my classroom to promote a skeptical inquiry into matters of personal faith is the day I need to quit (and all inquiry in a real history class needs to be skeptical).
I encourage free thinking and critical analysis and allow students to seek their own inquiries into these matters. But when they ask my opinion, I tactfully dummy up and certainly don't introduce religious debates as a discreet topic. I don't tell my students one side of a political controversy when it comes up in class; I present facts from as many sides as I can seriously muster and let them decide. To do differently with religion would be a far worse transgression.
- EHT said...
Time Bandit...I agree with you I too would "dummy up" when it comes to discussing religious faith with students. It's kind of hard for me to do that anyway since I teach nine and ten year olds. It would seem that you have been able to get your religious self and your professional self straightened out in your head. It hasn't always been that easy for me and since I've started this blog I have been faced with it more times than I can count. I applaud you for knowing which way the wind blows. My post and a couple of others I have written explore my own struggle to seperate those two selves. As far as Brandmuller and Mohler go....I don't discount their scholarly analysis. They wouldn't be in the positions they are in without it, however, let's face it...They are employed by religious institutions who want to push their own views. They are paid mouthpieces for their particular denominations.


text:
First baseman Ryan Howard has signed a five-year contract extension with a sixth-year club option with the Phillies that could take him through the 2017 season, the Phillies announced.
The deal guarantees Howard $125 million over five years and could reach $138 million over six years.
The five-year extension will pay Howard $20 million in each of the 2012 and 2013 seasons and $25 million per year from 2014-16.
The club option is worth $23 million with a $10 million buyout.
The extension includes awards bonuses and a limited no-trade provision.
For some perspective, Howard's $20 million salary in 2012 is $6 million more than the entire Phillies payroll for the 1990 season.
Howard will become the highest paid player in franchise history. In 2012 and 2013, the Phillies will be paying Howard and pitcher Roy Halladay a salary of $20 million each.
Howard's salary for this season is $19 million and is $20 million next season.
Howard, 30, is hitting .275 with three home runs and 16 RBI this season and has started all 18 of the Phillies' games thus far.
The Phillies now have six players under contract for 2012 (Howard, Halladay, Joe Blanton, Placido Polanco, Carlos Ruiz, Shane Victorino and Chase Utley) and three for 2013 (Utley, along with Howard and Halladay).
Howard, general manager Ruben Amaro Jr. and manager Charlie Manuel are scheduled to have a press conference at 7:30 p.m. Eastern in San Francisco before the Phillies face the Giants.
Here is some background from the press release:
In his major league career, Howard has won the National League Rookie of the Year and MVP awards in successive seasons (2005-06), is a two-time NL All-Star (2006, 2009), won a Silver Slugger Award (2006) and was named MVP of the National League Championship Series last year. In his MVP season of 2006, Howard set a Phillies single-season record with 58 home runs and is the all-time franchise leader in postseason RBI (27).
Since becoming an everyday player on July 1, 2005, Howard leads all major league players in home runs (222) and RBI (650). Last season, Howard became just the fourth player in major league history to have four straight 40 home run/130 RBI seasons, joining Hall of Famer Babe Ruth (7), Ken Griffey Jr. (4) and Sammy Sosa (4), and the fastest player ever to 200 home runs (658 games), besting Ralph Kiner's previous record by 48 games.
Originally selected by the Phillies in the fifth round of the 2001 draft, Howard enters play tonight with a career .279 batting average, 225 home runs and 656 RBI in 750 games, all with Philadelphia. He currently ranks in fifth place on the Phillies' all-time home run list, behind Mike Schmidt (548), Del Ennis (259), Pat Burrell (251), and Chuck Klein (243). His .583 slugging percentage is the best in club history.


text:
Qt Everywhere: 4.5 To Be Relicensed As LGPL
Nokia has announced that starting with version 4.5, Qt will be available under the LGPL 2.1. From the announcement,
This exciting change, made with consultation of the
Kai Öistämö, Executive Vice President of Devices at Nokia expands,
The change in licensing for Qt is happening under the mantra "Qt
Nokia will also be opening up the development of Qt. A clear path for the
The simple fact behind this is that Nokia is less reliant on the
While kdelibs has always been available under the LGPL, this marks the first
Meanwhile, Nokia reiterates their commitment to a commercially viable and,
All-in-all today's news means tremendous things for Free and Open Source software. The
Re: Qt/Embedded ?
By Alex at Thu, 2009/01/15 - 6:00am
Re: Qt/Embedded ?
Does the licensing change apply to Qt Extended?
By Thorben at Thu, 2009/01/15 - 6:00am
Re: Qt/Embedded ?
IRIX is no longer supported as of Qt 4.5.
We support, as Unix platforms:
The BSDs are not directly supported by us, but they are known to work and supported by the community. We apply fixes sent to us.
By Thiago Macieira at Thu, 2009/01/15 - 6:00am
Nokia should talk to Adobe!
Nokia should talk to Adobe!There are no limitations now to port CS to Linux.
By origin at Thu, 2009/01/15 - 6:00am
Re: Nokia should talk to Adobe!
Does all CS is developped using QT?
By Richard Van Den Boom at Thu, 2009/01/15 - 6:00am
Re: Nokia should talk to Adobe!
I doubt that the cost of a few commercial Qt licenses was the problem for Adobe to port software to Linux.
By Grósz Dániel at Thu, 2009/01/15 - 6:00am
Re: Nokia should talk to Adobe!
I'm more thinking in the line open development process and assurance that your products don't depend on other company which LGPL makes possible for Adobe.
By origin at Fri, 2009/01/16 - 6:00am
Thanks Guys!
I'll definitely be using QT a lot more now ;)
By Mark Hannessen at Thu, 2009/01/15 - 6:00am
Remove all redundancy between Qt and Glib
The ideal way to merge KDE and GNOME is to build Qt on top of Glib such that there is absolutely no redundancy between the two (ie. ASCII conversion, File access, etc). This way Qt apps won't incur a memory penalty if Qt is compiled with Glib support.
QtCore should rely on Glib to do the low-level stuff. Unfortunately this will mean sacrifices on all sides (ie. GTK will need to die), but eventually will lead to a unified Free Desktop.
By Stan at Fri, 2009/01/16 - 6:00am
Re: Remove all redundancy between Qt and Glib
> won't incur a memory penalty if Qt is compiled with Glib support.
do you have #s on the size of this memory penalty?
By Aaron Seigo at Fri, 2009/01/16 - 6:00am
Re: Remove all redundancy between Qt and Glib
I don't see the point in dealing with the whole glib. The only "interesting" glib functionality (from Qt's perspective) is the mainloop.
Perhaps glib mainloop should be made a separate module ("linux mainloop"), and move all toolkits over to use that...
By Ville at Sat, 2009/01/17 - 6:00am
Qt + LGPL analysis
A complete analysis of Qt+LGPL can be found here
It seems to be a professional analysis of someone who knows what he is talking about.
By Jens at Fri, 2009/01/16 - 6:00am
Thief! Robber! Give me back my money!
I've paid BIG$$ a year ago for a commercial license, so I don't need to show everyone my $prec$ious code, and now I can do the same without giving away a single buck!
By Pokerface at Fri, 2009/01/16 - 6:00am
Cmp. Ubuntu Brainstorm
By Andre at Fri, 2009/01/16 - 6:00am
Qt and GTK+
I think it is impossible to have one toolkit like it is impossible to have only one distro, but since both toolkits will be licenced under LGPL now, i would like to see them share features/ideas, talk to each other and have some standarts. As a user, i want GTK+ and Qt applications to have the same functionality under Gnome and KDE (for example: look and feel, file open dialogs, ability to use drag and drop, which sometimes does not work). It would be great. But it seems that (sadly) toolkit developers have no interest in that (Qt will have a GTK style in 4.5, but there is no response from GTK+ developers) and don't see anything happening soon.
By Zolookas at Fri, 2009/01/16 - 6:00am
Misconception about the press release
I think most people misunderstand the press info. Adding LGPL as a license option allow developers to use Qt for commercial purposes without having to pay a license for Qt. Now you only pay for the support. That will bring more developers to the platform, and probably more programs for Linux, and that's good news.
What means for Gnome: probably nothing. While they are talking about breaking ABI compatibility with 3.0, is not the same as switching a toolkit. To clear a concept to non programmers:
In short, if they are not rewriting Gtk, less they are going to switch the framework.
By Mario Vazquez at Sat, 2009/01/17 - 6:00am


text:
Mike Finnigan has been a part of an amazing amount of rock and roll music over the last four-plus decades. A big highlight was playing organ on the tracks "Rainy Day, Dream Away" and "Still Raining, Still Dreaming" on Jimi Hendrix's Electric Ladyland album. He has also played organ and/or sang with many other artists including Crosby, Stills & Nash, Etta James, Dave Mason, Ringo Starr, Joe Cocker, Bonnie Raitt, Taj Mahal, and Eric Burdon.
This interview was for a preview article for a benefit concert in Santa Barbara on 8/22/14 for The Rhythmic Arts Project (TRAP), an educational program that integrates percussion as a medium to address reading, writing, and arithmetic, as well as life skills, with children and adults with intellectual and developmental differences. It was done by phone on 8/12/14.