BJP using Adsense | Control Enter

BJP using Adsense

I was surprised to see BJP using Google adsense to advertisement online. It seems its already full throttle.

Amusements Fail

Submitted by Dominic H

      

Father Knows Best

5 Questions Men Fear

The 5 questions most feared by men are:

1. What are you thinking about?
2. Do you love me?
3. Do I look fat in this?
4. Do you think she is prettier than me?
5. What would you do if I died?

What makes these questions so difficult is that every one is guaranteed to explode into a major argument if the man answers incorrectly (i.e., tells the truth). Therefore, as a public service, each question is analysed below, along with possible responses.

Question 1: What are you thinking about?

The proper answer to this, of course, is: "I'm sorry if I've been pensive, dear. I was just reflecting on what a warm, wonderful, thoughtful, caring, intelligent woman you are, and how lucky I am to have met you." This response obviously bears no resemblance to the true answer, which most likely is one of the following:

a. Football.
b. Golf.
c. How fat you are.
d. How much prettier she is than you
e. How I would spend the insurance money if you died.

Perhaps the best response to this question was offered by Al Bundy, who once told Peg, "If I wanted you to know what I was thinking, I would be talking to you!"

Question 2: Do you love me?

The proper response is: "YES!" or, if you feel a more detailed answer is in order, "Yes, dear." Inappropriate responses include:

a. Oh Yeah, shit-loads.
b. Would it make you feel better if I said yes?
c. That depends on what you mean by love.
d. Does it matter?
e. Who, me?

Question 3: Do I look fat?

The correct answer is an emphatic: "Of course not!" Among the incorrect answers are:

a. Compared to what?
b. I wouldn't call you fat, but you're not exactly thin.
c. A little extra weight looks good on you.
d. I've seen fatter.
e. Sorry what did you say ? I was just thinking about how I would spend the insurance money if you died.

Question 4: Do you think she's prettier than me?

Once again, the proper response is an emphatic: "Of course not!" Incorrect responses include:

a. Yes, but you have a better personality.
b. Not prettier, but definitely thinner.
c. Not as pretty as you when you were her age.
d. Define pretty.
e. Sorry what did you say ? I was just thinking about how I would spend the insurance money if you died.

Question 5: What would you do if I died?

A definite no-win question.(The real answer, of course, is "Buy a Lotus and a Boat"). No matter how you answer this, be prepared for at least an hour of follow-up questions, usually along the these lines:

WOMAN: Would you get married again?
MAN: Definitely not!
WOMAN: Why not - don't you like being married?
MAN: Of course I do.
WOMAN: Then why wouldn't you remarry?
MAN: Okay, I'd get married again.
WOMAN: You would? (with a hurtful look on her face)
MAN: (makes audible groan)
WOMAN: Would you sleep with her in our bed?
MAN: Where else would we sleep?
WOMAN: Would you put away my pictures, and replace them with pictures of her?
MAN: That would seem like the proper thing to do.
WOMAN: And would you let her use my golf clubs?
MAN: She can't use them; she's left-handed.
WOMAN: - - - silence - - -
MAN: shit.

MF Bliki: FluentInterface

FluentInterface	dsl	20 December 2005	Reactions
A few months ago I attended a workshop with Eric Evans, and he talked about a certain style of interface which we decided to name a fluent interface. It's not a common style, but one we think should be better known. Probably the best way to describe it is by example. The simplest example is probably from Eric's timeAndMoney library. To make a time interval in the usual way we might see something like this: TimePoint fiveOClock, sixOClock;...TimeInterval meetingTime = new TimeInterval(fiveOClock, sixOClock); The timeAndMoney library user would do it this way: TimeInterval meetingTime = fiveOClock.until(sixOClock); I'll continue with the common example of making out an order for a customer. The order has line-items, with quantities and products. A line item can be skippable, meaning I'd prefer to deliver without this line item rather than delay the whole order. I can give the whole order a rush status. The most common way I see this kind of thing built up is like this: private void makeNormal(Customer customer) { Order o1 = new Order(); customer.addOrder(o1); OrderLine line1 = new OrderLine(6, Product.find("TAL")); o1.addLine(line1); OrderLine line2 = new OrderLine(5, Product.find("HPK")); o1.addLine(line2); OrderLine line3 = new OrderLine(3, Product.find("LGV")); o1.addLine(line3); line2.setSkippable(true); o1.setRush(true); } In essence we create the various objects and wire them up together. If we can't set up everything in the constructor, then we need to make temporary variables to help us complete the wiring - this is particularly the case where you're adding items into collections. Here's the same assembly done in a fluent style: private void makeFluent(Customer customer) { customer.newOrder() .with(6, "TAL") .with(5, "HPK").skippable() .with(3, "LGV") .priorityRush(); } Probably the most important thing to notice about this style isthat the intent is to do something along the lines of an internalDomainSpecificLanguage. Indeed this is why we chose theterm 'fluent' to describe it, in many ways the two terms are synonyms.The API is primarily designed to be readable and to flow. The price ofthis fluency is more effort, both in thinking and in the APIconstruction itself. The simple API of constructor, setter, andaddition methods is much easier to write. Coming up with a nice fluentAPI requires a good bit of thought. Indeed one of the problems of this little example is that I justknocked it up in a Calgary coffee shop over breakfast. Good fluentAPIs take a while to build. If you want a much more thought outexample of a fluent API take a look at JMock. JMock, like any mockinglibrary, needs to create complex specifications of behavior. Therehave been many mocking libraries built over the last few years,JMock's contains a very nice fluent API which flows verynicely. Here's an example expectation: mock.expects(once()).method("m").with( or(stringContains("hello"), stringContains("howdy")) ); I sawSteve Freeman and Nat Price give an excellent talk at JAOO2005 on theevolution of the JMock API, they since wrote it up in an OOPSLA paper. So far we've mostly seen fluent APIs to create configurations of objects, often involving value objects. I'm not sure if this is a defining characteristic, although I suspect there is something about them appearing in a declarative context. The key test of fluency, for us, is the Domain Specific Language quality. The more the use of the API has that language like flow, the more fluent it is. Building a fluent API like this leads to some unusual API habits.One of the most obvious ones are setters that return a value. (In theorder example with adds an order line to the order and returns theorder.) The common convention in the curly brace world is thatmodifier methods are void, which I like because it follows theprinciple of CommandQuerySeparation. This convention doesget in the way of a fluent interface, so I'm inclined to suspend theconvention for this case. You should choose your return type based on what you need tocontinue fluent action. JMock makes a big point of moving its typesdepending on what's likely to be needed next. One of the nice benefitsof this style is that method completion (intellisense) helps tell youwhat to type next - rather like a wizard in the IDE. In general I finddynamic languages work better for DSLs since they tend to have a lesscluttered syntax. Using method completion, however, is a plus forstatic languages. One of the problems of methods in a fluent interface is that they don't make much sense on their own. Looking at a method browser of method by method documentation doesn't show much sense to with. Indeed sitting there on its own I'd argue that it's a badly named method that doesn't communicate its intent at all well. It's only in the context of the fluent action that it shows its strengths. One way around this may be to use builder objects that are only used in this context. One thing that Eric mentioned was that so far he's used, andseen, fluent interfaces mostly around configurations of value objects.Value objects don't have domain-meaningful identity so you can makethem and throw them away easily. So the fluency rides on making newvalues out of old values. In that sense the order example isn't thattypical since it's an entity in the EvansClassification. I haven't seen a lot of fluent interfaces out there yet, so I conclude that we don't know much about their strengths and weaknesses. So any exhortations to use them can only be preliminary -however I do think they are ripe for more experimentation. There's a good follow up to this from Piers Cawley. Update (23 June 2008). Since I wrote this post this term's been used rather widely, which gives me a nice feeling of tingly gratification. I've refined my ideas about fluent interfaces and internal DSLs in the book I've been working on. I've also noticed a common misconception - many people seem to equate fluent interfaces with Method Chaining. Certainly chaining is a common technique to use with fluent interfaces, but true fluency is much more than that.

Lie of Omission

Salaries in an Open Culture Organization

I think that if you have an organization of empowered self-organized smart employees then, you should consider having:

• Open Salaries: Any employee can know any other employee’s salary. Disclosing salaries is not a crime


• Salary increments/upraisals are not based on individual performance. We want to build an organization where everyone is equal and everyone is putting in their best. If not, then they are in the wrong place. It would be even better if everyone is contributing (net value) more or less the same. (Common to find this in 4-5 people start-ups)


• Team members sit down and mutually decide their salaries (the numbers can be further adjusted based on cross-team discussions)


• Every month the company discloses its Profit and Loss (P&L) statement for the month. Even better if you can automate this and we can see the trend.


• Based on the P&L, employees can get a % increase or decrease in their monthly pay. (can be easily automated)
  
  
  
  • Say the company made 20% profit (2,000K USD) this month.
  
  
  • Last month the company had made 15% profit (1,500K USD).
  
  
  • So the delta is 5% (500K USD).
  
  
  • Now the company decides that some portion of this 5% should either be distributed amongst the employees or used to buy an asset for the company that will directly benefit all the employees (say Mac Book Pro for all employees).
  
  
  • Say the company decides to distribute 20% (100k USD) of the 5% profit delta (500K USD) amongst all it’s employees.
  
  
  • We distribute this amount (100K USD) to all the employees.
    
    
    
    • One way to do this is such that every one gets the same portion/increment. You can divide the total distributable profit amount (100K USD) by the total number of employees (say 100) which would be 1K USD amongst all its employees. So every one get 100 USD.
    
    
    • Another way to do this is instead of everyone getting the same increment, employees get the increment based on some % of their salary. So for example 100k USD needs to be distributed amongst 100 employees whose total salary comes up to 50K USD. Then everyone gets 2% (100K/50K) of their current salary increment. So if someone’s salary was 5k USD per month, then their new salary will be 5.1k USD.
    
    
    
    
  
  
  
  


• Some organization might feel doing it every month is too much overhead. May be they want to batch it up and do it once every 6 months. This is fine, except that doing it every month is a great way for all the employees to be hooked into the companies performance.


• Salary corrections because of market changes or other reasons are done on a regular basis but are separated from the salary upraisals.

The standard response I get to this proposal in companies from the management is that

“Employees are not matured enough to handle this in the right spirit”.

My response is

“You can’t learn how to swim by standing outside water and watching others swim, you have to jump in and try”.

Another resume tip

Are you a software developer applying to a small company?

Here’s a tip from someone who has read thousands of resumes. When you’re applying to a startup, or a software company with less than, say, 100 employees, you may want to highlight the Banging Out Code parts of your experience, while deemphasizing the Middle Management parts of your experience.

When a startup CTO sees a resume that says things like:

• Responsible for $30m line of business


• Architected new ERP platform


• Managed team of 25 developers


• Optimized business processes

they think, “Spare me, that’s all we need, somebody running around trying to manage and optimize and architect when we just need someone who isn’t afraid to write code.” Here’s the stuff CTOs at startups want to see on a resume:

• Single-handedly developed robust 100,000 LOC threadsafe C++ service


• Contributes to OpenBSD file system in spare time


• Wrote almost 75% of the Python code running IsIt2009Yet.Com

If you’ve been in a large company for too long, you may feel that you put in your time, with all those years working your way up the hierarchy from the $50,000 coder jobs to the $250,000 Senior Vice President in Charge of Long Meetings With Other Senior Vice Presidents, and you’re kind of enjoying the nice parking space and the personal assistant and stuff, and coding? not so much, so now you’ve found a cool startup or small company, and you’re thinking, maybe now’s the time to jump ship? So you send your resume with your ERP stuff and SAP stuff and Vice President stuff to the startup, and it gets tossed.

Those VP jobs just don’t exist at startups, and the few VPs they have are the founders and a key early hire or two. Not you. And startups certainly don’t need extra middle managers. To a startup founder, middle managers just seem like added expense without more code getting written, and the only thing we REALLY need is

• code to be written, and


• customers to be called on the telephone.

Now, there’s a lot of resumes I see where, actually, I suspect that the candidate may have been (ahem) slightly overemphasizing the management/leadership/“architect” parts of the job, and slightly underemphasizing the banging out of code. And that’s fine if you’re looking to jump to a management position at a big company that, inexplicably, doesn’t have anyone to promote from within.

But for startups, everything about your resume has to scream getting your own hands dirty. Otherwise your resume makes you look like you’re looking for the kind of job where you can call meetings that take people away from coding all day long, which, to a startup, is about as useful as a one-legged man in a butt-kicking contest.

(More resume tips, and, if you’re really looking for a job, don’t forget the job board).

Need to hire a really great programmer? Want a job that doesn't drive you crazy? Visit the Joel on Software Job Board: Great software jobs, great people.