Mon 13 Apr 2009

 

Appraisal Ki Pyaas

 

 



Badla Developer Ka

 

 



Tester Bana Shaitaan

 

 



Manager ki Cheekh

 

 



Tadapti Delivery

 

 



Client Ka Qaher!!!!!!!!!!!

 

 



Darinda manager, tadapta developer ... !!!!

 

 

Andha code … !!!

 

 

Gayab coder – A murder mystery.. !!!

 

 

Zahreela food court .. !!!

 

 

 

“SUBMIT” mat dabana………….

 

 

Deadline

 

 

Masoom Coder- A Life in trouble

 

 

9 Ghante 15 Minute

 

 

Zahereelee Defect

 


Production Release ki Raat

 

 

Do Hazar Code Ke Neeche

 

 

REGRESSION RELOADED

 

 

 I know what you CODED last summer

 

 

 Adam khor developer

 

 

Coding- The mystery continues………

 



 

Comments here
Wed 18 Mar 2009
Yeh Document, Yeh Meetings, Yeh Features Ki Duniya
 
Yeh Insaan Ke Dushman, Yeh Cursors Ki Duniya
 
Yeh Deadlines Ke Bhooke, Management Ki Duniya
 
Yeh Product Agar Ban Bhi Jaaye To Kya Hai?
 
Yahaan Ek Khilona Hai Programmer Ki Hasti
 
Yahaan Basti Hai Murda Bug-Fixers Ki Basti
 
Yahaan Par To Raises Hai, Inflation Se Sasti
 
Yeh Review Agar Ho Bhi Jaaye To Kya Hai?
 
Har Ek Keyboard Ghayal, Har Ek Mouse Hay Pyasa
 
Excel Mein Uljhan, Winword Mein Udaasi
 
Yeh Release Agar Ho Bhi Jaaye To Kya Hai?
 
Jalaa Do Ise, Phoonk Do Yeh Monitor
 
Mere Saamne Se Hataa Do Yeh Manager Ki Moorat
 
Tumahaara Hai Tumhi Sambhaalo Ye Computer
 
Yeh Product Agar Chal Bhi Jaaye To Kya Hai?
 
 
Comments (5)
Thu 1 Jan 2009

 Microsoft Application Architecture Guide 2.0‏.  Nice stuff for those who are interested in Application architecture at http://www.codeplex.com/AppArchGuide

Summary :

Parts

Part I, Fundamentals
Part II, Design
Part III, Layers
Part IV, Archetypes

Forewords

*   Foreword by S. Somasegar

*   Foreword by Scott Guthrie

Chapters

*   Introduction

*   Architecture and Design Solutions At a Glance

*   Fast Track

Part I, Fundamentals

*   Chapter 1 - Fundamentals of Application Architecture

*   Chapter 2 - .NET Platform Overview

*   Chapter 3 - Architecture and Design Guidelines

Part II, Design

*   Chapter 4 - Designing Your Architecture

*   Chapter 5 - Deployment Patterns

*   Chapter 6 - Architectural Styles

*   Chapter 7 - Quality Attributes

*   Chapter 8 - Communication Guidelines

Part III, Layers

*   Chapter 9 - Layers and Tiers

*   Chapter 10 - Presentation Layer Guidelines

*   Chapter 11 - Business Layer Guidelines

*   Chapter 12 - Data Access Layer Guidelines

*   Chapter 13 - Service Layer Guidelines

Part IV, Archetypes

*   Chapter 14 - Application Archetypes

*   Chapter 15 - Web Applications

*   Chapter 16 - Rich Internet Applications (RIA)

*   Chapter 17 - Rich Client Applications

*   Chapter 18 - Services

*   Chapter 19 - Mobile Applications

*   Chapter 20 - Office Business Applications (OBA)

*   Chapter 21 - SharePoint Line-Of-Business (LOB) Applications

Appendix

*   Cheat Sheet - patterns & practices Pattern Catalog

*   Cheat Sheet - Presentation Technology Matrix

*   Cheat Sheet - Data Access Technology Matrix

*   Cheat Sheet - Workflow Technology Matrix

*   Cheat Sheet - Integration Technology Matrix

Errata Page

*   Errata Page

Team

*   Core Dev Team: J.D. Meier , Alex Homer, David Hill, Jason Taylor , Prashant Bansode , Lonnie Wall, Rob Boucher Jr, Akshay Bogawat

*   Test Team - Rohit Sharma, Praveen Rangarajan, Kashinath TR, Vijaya Jankiraman

*   Edit Team - Dennis Rea.

*   External Contributors/Reviewers - Adwait Ullal; Andy Eunson; Brian Sletten; Christian Weyer; David Guimbellot; David Ing; David Weller; Derek Greer; Eduardo Jezierski; Evan Hoff; Gajapathi Kannan; Jeremy D. Miller; John Kordyback; Keith Pleas; Kent Corley; Mark Baker; Paul Ballard; Peter Oehlert; Norman Headlam; Ryan Plant; Sam Gentile; Sidney G Pinney; Ted Neward; Udi Dahan

*   Microsoft Contributors / Reviewers - Ade Miller; Amit Chopra; Anna Liu; Anoop Gupta; Bob Brumfield; Brad Abrams; Brian Cawelti; Bhushan Nene; Burley Kawasaki; Carl Perry; Chris Keyser; Chris Tavares; Clint Edmonson; Dan Reagan; David Hill; Denny Dayton; Diego Dagum; Dmitri Martynov; Dmitri Ossipov; Don Smith; Dragos Manolescu; Elisa Flasko; Eric Fleck; Erwin van der Valk; Faisal Mohamood; Francis Cheung; Gary Lewis; Glenn Block; Gregory Leake; Ian Ellison-Taylor; Ilia Fortunov; J.R. Arredondo; John deVadoss; Joseph Hofstader; Koby Avital; Loke Uei Tan; Luke Nyswonger; Manish Prabhu; Meghan Perez; Mehran Nikoo; Michael Puleio; Mike Francis; Mike Walker; Mubarak Elamin; Nick Malik; Nobuyuki Akama; Ofer Ashkenazi; Pablo Castro; Pat Helland; Phil Haack; Reed Robison; Rob Tiffany; Ryno Rijnsburger; Scott Hanselman; Seema Ramchandani; Serena Yeoh; Simon Calvert; Srinath Vasireddy; Tom Hollander; Wojtek Kozaczynski

 

To download go to following link.

http://www.codeplex.com/AppArchGuide

 

 

 

Comments here
Sun 26 Oct 2008

IT Designations


Wonderful definitions of IT designations at office.

1) Project Manager is a Person who thinks Nine women can deliver a baby in One month.
2) Developer is a Person who thinks it will take 18 months to deliver ababy.
3) Onsite Coordinator is one who thinks single woman can deliver nine babiesin one month.
4) Client is the one who doesn't know why he wants a baby.
5) Marketing Manager is a person who thinks he can deliver a baby even if no man and woman are available.
6) Resource Optimization Team thinks they don't need a man or woman; they'llproduce a child with zero resources.
7) Documentation Team thinks they don't care whether the child is delivered, they'll just document 9 months.
8) Quality Auditor is the person who is never happy with the PROCESS to produce a baby

 

Comments (1)
Mon 16 Jun 2008
Comments here
Wed 11 Jun 2008

For its next-generation application, XYZZY Software Inc. decided to do a major overhaul using the latest and greatest “best practices” framework for enterprise applications: Plugh Version 2009.

To do the prototype, XYZZY hires Luke, a bright young developer who has been using Plugh for at least six months. In no time at all, Luke whips up a working example of what the application might look like — well, three pages of it anyway. Everyone who sees it says “ooh” and “aah” and wants to know how long it will take to convert the entire application — salespeople in particular show special interest in that question. Luke (who knows very little about the existing application but has seen the regular demo) tosses out “oh, probably about six months.”

This becomes a war cry for the sales force. They descend on all levels of management with cries of, “Luke says it can be done in six months! We desperately need this new look and feel ASAP in order to compete!” Upper management asks the Director of Development if this really can be achieved so quickly.

During a development meeting, the old-guard programmers lay out all the (known) complexities of the existing system in order to show Luke how far off he is in his projection. The Director of Development (who doesn’t want upper management to think he’s being a nonagile wet blanket about the project) coaxes everyone to agree that it can be done in two years. Of course, they’ll have to release an interim version of the company’s current product in one year for regulatory changes and bug fixes, so there will be ongoing parallel development.

Management, marketing, and sales approve of the plan — after sales gets three months trimmed off the schedule so they can have a beta version ready by their annual conference. Development doesn’t feel very good about the adjustment, but they figure they can just work extra hard to make that deadline — and maybe leave a few of the lesser-used features out of the beta if necessary.

A new team is formed, and Luke is named the lead programmer. The team also includes several of the old-guard programmers, a couple of testers, a documentation specialist, and a project manager. They set right to work.

The team soon discovers that not all areas of the application easily translate into the Plugh framework. When they attempt to define the requirements of these sections, they realize that no one who is still at the company really knows what that code is supposed to do. They get existing customers involved in the discussion, which leads to the startling discovery that nobody agrees on whether the current behavior is a bug or a feature.

Six months into the project, they only have several more input forms developed than Luke had in his original prototype. It’s clear that the prototype didn’t do everything that will be required of the same pages in the full version. The security and internationalization mechanisms of the existing system will not migrate to Plugh, and the replacements have not even been pondered. Luke finds himself in a maze of twisty little requirements, none of which are alike. Sales is still telling customers it will be ready by next year’s conference, but upper management is getting nervous. Development insists they can keep the project on schedule, but management demands a reality check.

The employees decide to call in an outside consultant to validate their plan. After spending several days examining both the old and nascent forms of the application, talking to users and developers, and crunching the numbers, the consultant renders this verdict:

“Your current approach is doomed to failure. From the sheer size of the project, it will take at least three, possibly four, years to even get to a usable beta version — depending on how many other unspecified requirements you run into along the way. Throwing more developers on the project will not help. But I can recommend a different approach that will make incremental improvements to your existing application and allow you to release a new version every year without massively parallel development.”

The employees (except sales) breathe sighs of relief. And even the sales team is mollified when the consultant shows that the very first incremental improvement could be to the portion of the application in which users spend 80 to 90 percent of their time and which would make a great demo if it weren’t so ugly today.

Whether XYZZY Software followed the plan laid out by the consultant is not as important as the fact that the employees listened to what she said not to do.

Prior to the meeting, at least 20 employees knew the project was headed off the rails, so why didn’t anyone sound the alarm? Because they worried whether being the naysayer would damage their career. Their fear kept them silent and prevented them from thinking about alternative solutions; instead, these employees focused all their energies on achieving the impossible.

Truth in fiction

Even though there is no XYZZY Software or Plugh development framework, I have seen this same story play out many times. I have played the part of Luke, the Director of Development, and the consultant (though I’ve never been a woman, but I have played one on stage — that’s an entirely different story).

Unfortunately, many of these scenarios do not turn out as happily as the tale of XYZZY Software. I have seen some companies sink several years and millions of dollars into these types of projects before coming to their senses. I genuinely feel so badly for them that I don’t even smile when I say “I told you so.”

An outside consultant can provide the voice of disinterested honesty. If the client doesn’t like what you have to say, the most you lose is the engagement. If they listen to you and it doesn’t work, things could get ugly. You’re not part of the protected herd of employees who will be all too happy to blame you. So, you’re incented to be as honest as possible about what will and will not work. Also, be sure to keep yourself out of office politics. Obviously, you’re going to feel beholden foremost to the person who signs your checks, but the best service you can provide the client is to tell it like it is.

There are many more companies that never even call in a consultant to tell them so. And there are some consultants who don’t have the backbone to tell their clients that they’re making a colossal mistake.

 

 

Categories : Knowledge / Amazing
Comments here
Thu 22 May 2008

By Jane Wakefield
Technology reporter, BBC News

 

 

 

 

Plans for a super-database containing the details of all phone calls and e-mails sent in the UK have been heavily criticised by experts.

 

The government is considering the changes as part of its ongoing fight against serious crime and terrorism.

Assistant Information Commissioner Jonathan Bamford has warned that the UK could be "sleepwalking into a surveillance society".

Others have questioned how such a database could be made secure.

 

Public confidence

"While the public is "sleepwalking" into a surveillance society, the government seems to have its eyes wide open although, unfortunately, to everything except security," said Jamie Cowper, data protection expert at data protection firm PGP Corporation.

"The bottom line is - information of this nature should only be held if - and only if - it can be demonstrated that an appropriate system of checks and balances is in place and the security of the information being stored is of paramount concern," he added.

Public confidence in the governments' ability to look after data has been dented in recent months with high profile failures, including the loss of a CD carrying all the personal details of every child benefit claimant.

 

The latest plans being mulled by the Home Office will form part of the proposed Communications Bill, which is due to be considered by MPs later this year.

It is, said a Home Office spokesman, crucial "to ensure that public authorities have access to communications data essential for counter-terrorism and investigation of crime purposes."

 

Risks

 

The more people who have access to it the more risks there would be

Chris Mayers, Citrix Systems

It would extend the powers of RIPA (the Regulation of Investigatory Powers Act) which currently allows hundreds of government agencies access to communications data.

Some believe such legislation, which requires government authorities to request information from communication providers, is more than adequate for law enforcement purposes.

"The fight against terrorism doesn't require a centralised database," said Chris Mayers, chief security architect at Citrix Systems, an applications delivery firm.

"Such a database would face threats from both outside and inside. The more people who have access to it the more risks there would be," he said.

 

Big Brother

The Internet Service Providers' Association said it was seeking more information about the proposals.

"In particular we want to know more about the Government's intentions regarding "modifying the procedures for acquiring communications data," said a spokesman.

In the run-up to RIPA being approved by parliament, human rights campaigner Privacy International argued that such an act would be a dangerous first step towards a "Big Brother" society.

According to Gus Hosein, a senior fellow at Privacy International, the latest proposals could be even more controversial.

"The idea that ISPs need to collect data and send it en masse to central government is, without doubt, illegal," he said.

 

 

uk database.JPG

Categories : Knowledge / Amazing
Comments here