When it comes to searching for details about Microsoft's APIs, I'm finding time and time again that it's often impossible to locate exactly what I'm searching for, and I've just realized why. I shall now italicize it to indicate its truthitude:
You will not find an explicit answer to what you are looking for.
When it comes to obscure topics, unless you are a web search god, you will not be able to determine the answer to your question.
Once you realize this, you start thinking of other ways to search. Instead of searching for the answer to an explicit question, you search for information about the topic associated with the information. So for example if you are searching for whether you can use a domain-user SID in a Windows LSA function, you should read up on LSA functions, then just try it out.
Hypothesis testing should be a fundamental part of your online search regimen.
Keep a word processing document handy to write down different hypotheses as well as whether those hypotheses are valid or not.
You'll arrive at the answer to your question much faster than had you simply blindly searched for your exact question on google.
Tuesday, May 3, 2011
Saturday, April 9, 2011
Maple Mead Recipe
For posterity, here's the maple mead recipe for the mead I started on 4/2/2011
After about 12 hours, it should be fermenting pretty intensely. Mine was bubbling at a little under twice a second near the beginning.
Now, if (what appears to be) green mold appears around the inside edge of the carboy, right above the level of the must, you should be fine. What I've done is use a cotton swab soaked in a mixture of chlorine and water (very little chlorine) and wiped that off, then put the stopper back in and allowed it to continue fermenting. FYI, this only happened on my first batch, and didn't happen this time that I've heated the must. Probably should heat the must from then on. Unfortunate.
I'm not very sure if it's mold though. It may simply be maple syrup that vaporized off the top and then reformed around the edges.
I'll update this blog as the mead continues. It's still fermenting right now.
Below is a video of the mead after about 8 days of fermenting. This is useful to compare rates of fermentation. I think mine has been an extremely good fermentation so far. I've tasted the mead and it's exceptionally clean - doesn't seem like the yeast struggled at all.
- Sanitize
- Carboy
- Airlocks
- Stoppers
- Funnels
- Measuring cups
- Yeast delivery thing
- thermometer
- Prepare
- 4 cups maple syrup (equals 3.32 cups honey)
- 0.68 - 0.75 cups honey
- If desired, heat the must, stirring gently, to no more than 140 deg for about 5-7 minutes. This is my second batch, and I decided to do that for this batch.
- Fill up to about 4/5 with water. Don't completely fill the carboy! Remember that it's easier to shake the carboy to oxygenate when there's a bit of air available at the top.
- Add 1 tsp yeast nutrient and 1 tsp yeast energizer (I max these out when doing the maple because of concerns for mold)
- Heat 2oz of water to 100 deg F for yeast. I use a small glass cup for this.
- Add 1/4 teaspoon of the yeast to the water. I'm using Red Star Pasteur Yeast.
- Let sit for 15 minutes. Don't touch it!
- After 15 minutes, stir the yeast gently.
- Pitch yeast.
- Oxygenate for 5 minutes vigorously
- Add more water to fill to handle
- Measure brix: Should be 23-24%
- Place airlock and complete
After about 12 hours, it should be fermenting pretty intensely. Mine was bubbling at a little under twice a second near the beginning.
Now, if (what appears to be) green mold appears around the inside edge of the carboy, right above the level of the must, you should be fine. What I've done is use a cotton swab soaked in a mixture of chlorine and water (very little chlorine) and wiped that off, then put the stopper back in and allowed it to continue fermenting. FYI, this only happened on my first batch, and didn't happen this time that I've heated the must. Probably should heat the must from then on. Unfortunate.
I'm not very sure if it's mold though. It may simply be maple syrup that vaporized off the top and then reformed around the edges.
I'll update this blog as the mead continues. It's still fermenting right now.
Below is a video of the mead after about 8 days of fermenting. This is useful to compare rates of fermentation. I think mine has been an extremely good fermentation so far. I've tasted the mead and it's exceptionally clean - doesn't seem like the yeast struggled at all.
Wednesday, April 6, 2011
(Not) Understanding why template specialization isn't available in C#
As usual, I've decided to use the blogosphere to crystallize my thoughts on how templates in C++ and C# differ. Specifically, why is there no such thing as template specialization in C#?
In C++, templates are instantiated fully at compile time. If no type uses a given template, it doesn't get instantiated.
For example,
Then in some client code,
At this exact point, the C++ compiler says, ah, here's a use of max where T=int, so I'll create a specialized int max( int a, int b ), and compile that.
In C#, the paradigm is slightly different. First of all they're called generics, not templates. Second, the above code (minus the C++-isms), will not work. Namely, the definition for max will fail to compile.
Compile, you say? Why is it compiling the templatized function? It doesn't compile until it's used, right? Wrong.
C# templates are compiled to be available for all types that match a particular constraint. For example, the function max, in C#, would look like:
Now, this is compiled into a dll or exe that exposes a definition of Max which allows IComparables to be pulled in. The only thing that makes this different from the following is that in the generic method, both a and b must be the same type.
So, in this sense, the Max function below is more general than the ComputeMax function, since the ComputeMax function requires a and b to be the same type.
Now what is the difference between IComparable and IComparable<T>? It's the same as what we discovered earlier - the templatized form ensures that the comparison is always made to an object of the same type. Observing the definitions of IComparable and IComparable<T>...
Note that IComparable.CompareTo asks that (but does not enforce that) CompareTo throws an exception if the passed in object is not the same type as this. And there we have it - that's the advantage of IComparable<T>. It ensures that, at compilation time, the types of the two items are the same.
Now with this knowledge, we are finally ready to answer why there is no template specialization in C#. And the answer is.... I still don't know. I think actually, that it was simply a design choice. All of the fluff on StackOverflow makes it seem like Microsoft knowingly decided that it wouldn't fit into the paradigm, but my impression is that it was too much work and they figured it wouldn't be very worthwhile.
In C++, templates are instantiated fully at compile time. If no type uses a given template, it doesn't get instantiated.
For example,
template <typename T> T max( T a, T b ) {
if ( a >= b )
return a;
return b;
}
Then in some client code,
int main(...)
{
int maxarg = max(atoi(argv[1]), atoi(argv[2]));
}
At this exact point, the C++ compiler says, ah, here's a use of max where T=int, so I'll create a specialized int max
In C#, the paradigm is slightly different. First of all they're called generics, not templates. Second, the above code (minus the C++-isms), will not work. Namely, the definition for max will fail to compile.
Compile, you say? Why is it compiling the templatized function? It doesn't compile until it's used, right? Wrong.
C# templates are compiled to be available for all types that match a particular constraint. For example, the function max, in C#, would look like:
class Math {
static T Max<T>( T a, T b ) where T : IComparable<T> {
if ( a.CompareTo(b) >= 0 ) {
return a;
return b;
}
}
Now, this is compiled into a dll or exe that exposes a definition of Max which allows IComparables to be pulled in. The only thing that makes this different from the following is that in the generic method, both a and b must be the same type.
class Math {
static IComparable Max( IComparable a, IComparable b ) {
if ( a.CompareTo(b) >= 0 ) {
return a;
return b;
}
}
So, in this sense, the Max function below is more general than the ComputeMax function, since the ComputeMax function requires a and b to be the same type.
public static IComparable Max( IComparable a, IComparable b )
{
return a.CompareTo(b) >= 0 ? a : b;
}
public static T ComputeMax<T>( T a, T b ) where T : IComparable
{
return (T)Max(a, b);
}
Now what is the difference between IComparable and IComparable<T>? It's the same as what we discovered earlier - the templatized form ensures that the comparison is always made to an object of the same type. Observing the definitions of IComparable and IComparable<T>...
namespace System {
public interface IComparable
{
int CompareTo(T other);
}
public interface IComparable
{
// Exceptions:
// System.ArgumentException:
// obj is not the same type as this instance.
int CompareTo(object obj);
}
}
Note that IComparable.CompareTo asks that (but does not enforce that) CompareTo throws an exception if the passed in object is not the same type as this. And there we have it - that's the advantage of IComparable<T>. It ensures that, at compilation time, the types of the two items are the same.
Now with this knowledge, we are finally ready to answer why there is no template specialization in C#. And the answer is.... I still don't know. I think actually, that it was simply a design choice. All of the fluff on StackOverflow makes it seem like Microsoft knowingly decided that it wouldn't fit into the paradigm, but my impression is that it was too much work and they figured it wouldn't be very worthwhile.
Monday, April 4, 2011
C# and the dynamic keyword
At my new job, I'm learning a lot about quite a few new technologies that I've never dealt with before, to name a few, C#, T-SQL, and FLEX. As I've worked exclusively in the domain of C++ and Linux, this is quite a gear change for me.
One of the ways to get up to speed with C# is by perusing the book C# In a Nutshell, which is excellent. As I was reading, I happened upon a curious component of the C# language: the dynamic keyword.
Apparently, this keyword, simply put, forces type resolution to be deferred until runtime. That's a bit of a hefty statement, considering that the whole point of statically typed languages (C# included) is to catch type errors at compilation time.
I have found one quasi-interesting use of this keyword. It can do double-dispatching, though without all of the type safety. Unfortunately, the lack of type safety causes this post to be merely interesting, not very useful. Oh well.
Double-dispatching, if you recall, is a subset of multiple dispatching, in which two aspects of the method call are determined at run-time, rather than simply one.
Consider the following:
Ignoring the fact that this is a nasty violation of the DRY principle (we really shouldn't be hard-coding the type of the object - we should just use GetType()), this example illustrates single dispatching. The true type of the object obj above is determined at run-time. This is equivalent to the following:
MyObject_MyMethod( MyObject obj )
Here, it's more obvious that this is single dispatching, because the function has one argument whose type is determined at run time.
Now double dispatching would be something like:
MyObject_MyMethod( MyObject obj, OtherPolymorphicObject other ),
whereby we could supply all the MyObject_MyMethod's we want for all permutations of MyObjects and OtherPolymorphicObjects.
The way double-dispatching is typically done in statically typed languages is via the Visitor Pattern. This is one of the most clever patterns out there, but it is also not very useful in the real world (surprise).
The general point of the visitor pattern is to accomplish double-dispatching by making two function calls. That is, since our language only supports single dispatching, just make two method calls, each one performing a single dispatch. And 1+1=2.
A very simple, silly Visitor example follows. Consider Santa's workshop. Each toy needs to be wrapped, but needs to be wrapped differently depending on the type of toy.
See how double dispatch is working here? The TeddyBear object calls AcceptWrapper, whose sole purpose is to feed the type of the current object (TeddyBear) back into the Wrapper.
That last point is important - it's the most difficult aspect of the visitor pattern. So I'll repeat it.
The purpose of AcceptWrapper is to feed the type of the current object (TeddyBear) back into the Wrapper.
This way, if there's no Wrapper method for a TeddyBear, a compilation error will be issued.
Now finally onto the gist of this post. The dynamic keyword can reduce the amount of code above significantly, but also increase the potential of run-time errors, by supporting double-dispatching (really, multiple dispatching).
Observe:
Now the type of the packageable object is forced to be resolved at runtime.
But then - what if there's no WrapToy function for a TeddyBear?
Little Bobby won't be getting a Teddy Bear for Christmas. Or perhaps he'll just be getting a Teddy Bear covered with dirt and snow and reindeer hoof marks.
One of the ways to get up to speed with C# is by perusing the book C# In a Nutshell, which is excellent. As I was reading, I happened upon a curious component of the C# language: the dynamic keyword.
Apparently, this keyword, simply put, forces type resolution to be deferred until runtime. That's a bit of a hefty statement, considering that the whole point of statically typed languages (C# included) is to catch type errors at compilation time.
I have found one quasi-interesting use of this keyword. It can do double-dispatching, though without all of the type safety. Unfortunately, the lack of type safety causes this post to be merely interesting, not very useful. Oh well.
Double-dispatching, if you recall, is a subset of multiple dispatching, in which two aspects of the method call are determined at run-time, rather than simply one.
Consider the following:
class MyObject {
public virtual void MyMethod() {
Console.WriteLine("MyObject");
}
}
class MyObject2 : MyObject {
public override void MyMethod() {
Console.WriteLine("MyObject2");
}
}
...
MyObject obj = new MyObject2();
obj.MyMethod(); /// Prints "MyObject2"
Ignoring the fact that this is a nasty violation of the DRY principle (we really shouldn't be hard-coding the type of the object - we should just use GetType()), this example illustrates single dispatching. The true type of the object obj above is determined at run-time. This is equivalent to the following:
MyObject_MyMethod( MyObject obj )
Here, it's more obvious that this is single dispatching, because the function has one argument whose type is determined at run time.
Now double dispatching would be something like:
MyObject_MyMethod( MyObject obj, OtherPolymorphicObject other ),
whereby we could supply all the MyObject_MyMethod's we want for all permutations of MyObjects and OtherPolymorphicObjects.
The way double-dispatching is typically done in statically typed languages is via the Visitor Pattern. This is one of the most clever patterns out there, but it is also not very useful in the real world (surprise).
The general point of the visitor pattern is to accomplish double-dispatching by making two function calls. That is, since our language only supports single dispatching, just make two method calls, each one performing a single dispatch. And 1+1=2.
A very simple, silly Visitor example follows. Consider Santa's workshop. Each toy needs to be wrapped, but needs to be wrapped differently depending on the type of toy.
interface IWrappable {
void AcceptWrapper(Wrapper p);
}
class TeddyBear : IWrappable {
public void AcceptWrapper(Wrapper p) { p.WrapToy(this); }
}
class Robot : IWrappable {
public void AcceptWrapper(Wrapper p) { p.WrapToy(this); }
}
class ToyCar : IWrappable {
public void AcceptWrapper(Wrapper p) { p.WrapToy(this); }
}
class Wrapper
{
public void WrapToy(TeddyBear bear) {
Console.WriteLine("Put in fancy bag with bow" );
}
public void WrapToy(Robot robot) {
Console.WriteLine("Wrap with wrapping paper");
}
public void WrapToy(ToyCar car) {
Console.WriteLine("Take wheels off car and put in box");
}
}
class Program
{
static void Main(string[] args)
{
Wrapper packager = new Wrapper();
IWrappable packageable = new TeddyBear();
packageable.AcceptWrapper(packager);
}
}
See how double dispatch is working here? The TeddyBear object calls AcceptWrapper, whose sole purpose is to feed the type of the current object (TeddyBear) back into the Wrapper.
That last point is important - it's the most difficult aspect of the visitor pattern. So I'll repeat it.
The purpose of AcceptWrapper is to feed the type of the current object (TeddyBear) back into the Wrapper.
This way, if there's no Wrapper method for a TeddyBear, a compilation error will be issued.
Now finally onto the gist of this post. The dynamic keyword can reduce the amount of code above significantly, but also increase the potential of run-time errors, by supporting double-dispatching (really, multiple dispatching).
Observe:
interface IWrappable {
}
class TeddyBear : IWrappable {
}
class Robot : IWrappable {
}
class ToyCar : IWrappable {
}
class Wrapper
{
public void WrapToy(TeddyBear bear) {
Console.WriteLine("Put in fancy bag with bow" );
}
public void WrapToy(Robot robot) {
Console.WriteLine("Wrap with wrapping paper");
}
public void WrapToy(ToyCar car) {
Console.WriteLine("Take wheels off car and put in box");
}
}
class Program
{
static void Main(string[] args)
{
Wrapper packager = new Wrapper();
IWrappable packageable = new TeddyBear();
packager.WrapToy((dynamic)packageable);
}
}
Now the type of the packageable object is forced to be resolved at runtime.
But then - what if there's no WrapToy function for a TeddyBear?
Little Bobby won't be getting a Teddy Bear for Christmas. Or perhaps he'll just be getting a Teddy Bear covered with dirt and snow and reindeer hoof marks.
Back to work: The Maple Mead Fiasco
The last post was a simply a hiccup in my blogging; this post represents a San Andreas fault sized gap in my blogs.
There's a lot to talk about, so let me separate each item into individual blogs. The first item is about my meads.
Last Saturday, I had a close friend over, and we decided to take a quick sneak peek at my Maple Lapsang Souchong Mead. I had tasted it in the past, and it was delicious, but I wanted to show it off. I had the glass carboy in the refrigerator because I was trying to clarify it... apparently that was a big mistake.
I took the mead out of the refrigerator, and as I was placing it on the island in the middle of my kitchen, the side of the bottle grazed the edge of the countertop. This mere bump must have caused the bottle to resonate at precisely the right frequency, because the next second, the glass bottom of the carboy was on the floor and I was standing watching as a gallon worth of mead poured out of the bottom of the carboy.
It was all over in about 5 seconds.
It turns out that carboys are made from three pieces of glass - two sides, and one bottom. I found a reasonable picture online which shows these three pieces:
The "cup bottom mold seam" is where the bottom separated from the other two pieces of glass. Fun.
Well, I've started another maple mead, and it's fermenting like crazy. I hope that it will be a much more enjoyable experience that my last maple mead :)
There's a lot to talk about, so let me separate each item into individual blogs. The first item is about my meads.
Last Saturday, I had a close friend over, and we decided to take a quick sneak peek at my Maple Lapsang Souchong Mead. I had tasted it in the past, and it was delicious, but I wanted to show it off. I had the glass carboy in the refrigerator because I was trying to clarify it... apparently that was a big mistake.
I took the mead out of the refrigerator, and as I was placing it on the island in the middle of my kitchen, the side of the bottle grazed the edge of the countertop. This mere bump must have caused the bottle to resonate at precisely the right frequency, because the next second, the glass bottom of the carboy was on the floor and I was standing watching as a gallon worth of mead poured out of the bottom of the carboy.
It was all over in about 5 seconds.
It turns out that carboys are made from three pieces of glass - two sides, and one bottom. I found a reasonable picture online which shows these three pieces:
Well, I've started another maple mead, and it's fermenting like crazy. I hope that it will be a much more enjoyable experience that my last maple mead :)
Tuesday, March 1, 2011
Flaking
Well, I've flaked on the followup of my previous post. I know, I know. My day job has been rather intense lately. I apologize.
However, I do want to share one unrelated thing.
Did anyone ever play the game "Hard Drivin'" when they were a kid? Well, I did, and I was obsessed with it. It was challenging, addictive, exciting, and fun. (As an aside, I recently had an opportunity to play it again at FunSpot in New Hampshire, and it was exactly as I remembered).
Anyhow, I've recently stumbled upon this. Commence ridiculous awesomeness:
However, I do want to share one unrelated thing.
Did anyone ever play the game "Hard Drivin'" when they were a kid? Well, I did, and I was obsessed with it. It was challenging, addictive, exciting, and fun. (As an aside, I recently had an opportunity to play it again at FunSpot in New Hampshire, and it was exactly as I remembered).
Anyhow, I've recently stumbled upon this. Commence ridiculous awesomeness:
Wednesday, February 23, 2011
Collecting classes into packages
I was going to write a blog post on how it's easy to find information about how to design classes well, but always difficult to find information on how to separate classes into packages.
Then I stumbled upon this wonderful collection of Robert C. Martin's articles on object oriented design.
I know about the SOLID principles, but was unaware that he wrote anything about package design. I'll take a gander at it, then when I have a spare moment, as usual, I'll use the blogosphere as a medium to organize my thoughts about his suggestions.
Then I stumbled upon this wonderful collection of Robert C. Martin's articles on object oriented design.
I know about the SOLID principles, but was unaware that he wrote anything about package design. I'll take a gander at it, then when I have a spare moment, as usual, I'll use the blogosphere as a medium to organize my thoughts about his suggestions.
Friday, February 18, 2011
Writing and Communicating
We software developers are experts at communicating with computers. We master languages in order to elicit complex and intricate behavior while simultaneously making sure everything we write is consistent and clear. We have to keep in mind both the tiny details of syntax as well as the larger concepts of system consistency.
Yet we often are terrible communicators. We drag out meetings talking about meaningless and useless drivel. We cannot write English to save our lives.
Why this strange (and not to mention frustrating) dichotomy?
Perhaps it's simply emotional intelligence. In order to communicate with others, one has to be highly aware of his or her own emotions as well as the emotions of the other person.
If you make a mistake writing software, the implications of that bug are logical conclusions stemming from the bug itself.
If you make a mistake communicating with others, the implications are diverse and non-deterministic. They are dependent on the emotional state of that person, your surroundings, the time of the day. It's an utterly complex and chaotic system! No software developer in their right mind would design such a system; God must have a sick sense of humor, or just happened to major in Philosophy and Religion instead of Engineering.
So what do we do? We must practice. This is one of the reasons I started this blog. We need to become better communicators. If you're a software developer, and you're reading this, then take this as a hint. You need to start practicing. Communicating with others is difficult.
One quick and easy way to get started is by listening to the audio book How to Win Friends and Influence People. Trust me - don't read the book. Listen to the audiotape. Why? This book teaches you how to communicate and speak effectively. Since we often learn by imitation, we don't want to merely read something. It's much better to hear it so we can imitate it in our day-to-day lives.
Listen to it on your commute to work. You won't be disappointed.
Yet we often are terrible communicators. We drag out meetings talking about meaningless and useless drivel. We cannot write English to save our lives.
Why this strange (and not to mention frustrating) dichotomy?
Perhaps it's simply emotional intelligence. In order to communicate with others, one has to be highly aware of his or her own emotions as well as the emotions of the other person.
If you make a mistake writing software, the implications of that bug are logical conclusions stemming from the bug itself.
If you make a mistake communicating with others, the implications are diverse and non-deterministic. They are dependent on the emotional state of that person, your surroundings, the time of the day. It's an utterly complex and chaotic system! No software developer in their right mind would design such a system; God must have a sick sense of humor, or just happened to major in Philosophy and Religion instead of Engineering.
So what do we do? We must practice. This is one of the reasons I started this blog. We need to become better communicators. If you're a software developer, and you're reading this, then take this as a hint. You need to start practicing. Communicating with others is difficult.
One quick and easy way to get started is by listening to the audio book How to Win Friends and Influence People. Trust me - don't read the book. Listen to the audiotape. Why? This book teaches you how to communicate and speak effectively. Since we often learn by imitation, we don't want to merely read something. It's much better to hear it so we can imitate it in our day-to-day lives.
Listen to it on your commute to work. You won't be disappointed.
Thursday, February 17, 2011
My Meads
All 3 of my meads are aging. I've learned a lot this time around, most notably that you can't use a refractometer for a final gravity measurement because alcohol has a much higher refraction index than water. This was a bit of an annoying discovery; I kept thinking that my fermentations were "stuck" (settling out at 10% brix), when in fact they were nearly completely dry.
Details follow for each mead:
I will post about the meads again once they finish aging.
Details follow for each mead:
- A Cyser:
- Primary: Trader Joe's Apple Cider, raisins, dates, brown sugar, honey, yeast energizer, and Lavlin D-47.
- Secondary: I threw in some bits of lemon, more brown sugar, and honey.
- First month of aging: I chopped up a granny smith apple which I added directly to the mead. I really like the starchiness of granny smith apples and wanted to incorporate that starchy twang into the mead. The results, it turned out, were excellent.
- Tasting notes: This mead has a huge wallop of apple and honey up-front with a nice starchy, (almost potato-like) finish. It was a bit too cloying in initial taste, so I put a bit of acid blend into two out of the four bottles used.
- Approximate Alcohol Content: Probably 12%?
- An Acerglyn (Maple Mead)
- Primary: 4 cups Trader Joe's Grade B Maple Syrup, 3/4 cup Honey and Lavlin D-47.
- Secondary: More maple syrup, and since I decided after-the-fact to make this a dessert mead, Red Star Champagne Yeast.
- Note: I just realized that I could have made an even more intense dessert mead had I used Red Star Premier Cuvee yeast.
- Tasting notes after secondary: This thing is completely dry. Back-sweetened with at least a cup of maple sugar (didn't keep precise measurements).
- Approximate Alcohol Content: Probably 15%?
- A Ginger/Heathertip Metheglin
- Primary: Enough honey to make a gravity of 23% and a whole lot of ginger.
- Tasting after primary: Woah! Almost medicinal ginger twang. I have to find a way to smooth this out. To do this, I chose heathertips and fresh lemon zest.
- Threw some heathertips and lemon zest into a mesh bag along with some dimes wrapped in tin foil (to persuade it to sink) and dropped it into the carboy. Let it sit for 2 days.
- Subsequent tasting: Much better.
- Starting Gravity: 23%
- Final Gravity: ~3% Brix
- Approximate Alcohol Content: ~13%
I will post about the meads again once they finish aging.
Wednesday, February 16, 2011
Lord Hobo
Went to Lord Hobo tonight. Their food is somewhere between OK and just bad, but their beer selection is out of this world. My first beer was the Pretty Things Jack D'Or. What a spectacularly alive beer that is. Lemony, Zesty, Fresh. Just a wonderful brew. Though don't you dare get it in a bottle.
The second beer I got, and I always love this beer, is the CBC Big Man IPA. What a spectacular example of a Winter IPA. Big, bold, malty, and grassy.
The second beer I got, and I always love this beer, is the CBC Big Man IPA. What a spectacular example of a Winter IPA. Big, bold, malty, and grassy.
Tuesday, February 15, 2011
Respect
I have one thing to say about respect:
One cannot gain respect unless one shows it.
Think about that. When you're talking to your boss, your spouse, your children, your teachers, your parents, it's always the same. If you don't respect them they won't respect you.
One may suggest that this is very similar to the so-called "Golden Rule." ;)
One cannot gain respect unless one shows it.
Think about that. When you're talking to your boss, your spouse, your children, your teachers, your parents, it's always the same. If you don't respect them they won't respect you.
One may suggest that this is very similar to the so-called "Golden Rule." ;)
Subscribe to:
Posts (Atom)