Difference between focusing on problems and focusing on solutions
Case 1 :
When NASA began the launch of astronauts into space, they found out that the pens wouldn't work at zero gravity (ink won't flow down to the writing surface). To solve this problem, it took them one decade and $12 million. They developed a pen that worked at zero gravity, upside down, underwater, in practically any surface including crystal and in a temperature range from below freezing to over 300 degrees C. And what did the Russians do...?? They used a pencil.
Case 2 :
One of the most memorable case studies on Japanese management was the case of the empty soapbox, which happened in one of Japan's biggest cosmetics companies. The company received a complaint that a consumer had bought a soapbox that was empty. Immediately the authorities isolated the problem to the assembly line, which transported all the packaged boxes of soap to the delivery department. For some reason, one soapbox went through the assembly line empty. Management asked its engineers to solve the problem. Post-haste, the engineers worked hard to devise an X-ray machine with
high-resolution monitors manned by two people to watch all the soapboxes that passed through the line to make sure they were not empty. No doubt, they worked hard and they worked fast but they spent a whoopee amount to do so.
But when a rank-and-file employee in a small company was posed with the same problem, he did not get into complications of X-rays, etc., but instead came out with another solution. He bought a strong industrial electric fan and pointed it at the assembly line. He switched the fan on, and as each soapbox passed the fan, it simply blew the empty boxes out of the line.
The above 2 cases might be good examples for Root Cause Analysis(Find & remediate the root cause instead of addressing the symptoms)
Thursday, October 9, 2008
Wednesday, September 24, 2008
Build / Rebuild / Compile ASP.NET C#
Build means compile and link only the source files that have changed since the last build, while Rebuild means compile and link all source files regardless of whether they changed or not. Build is the normal thing to do and is faster. Sometimes the versions of project target components can get out of sync and rebuild is necessary to make the build successful. In practice, you never need to Clean.
Build or Rebuild Solution builds or rebuilds all projects in the your solution, while Build or Rebuildbuilds or rebuilds the StartUp project, "hello" in the screen shot above. To set the StartUp project, right click on the desired project name in the Solution Explorer tab and select Set as StartUp project. The project name now appears in bold. Since the homework solutions typically have only one project, Build or Rebuild Solution is effectively the same as Build or Rebuild .
Compile just compiles the source file currently being edited. Useful to quickly check for errors when the rest of your source files are in an incomplete state that would prevent a successful build of the entire project. Ctrl-F7 is the shortcut key for Compile.
Build or Rebuild Solution builds or rebuilds all projects in the your solution, while Build or Rebuild
Compile just compiles the source file currently being edited. Useful to quickly check for errors when the rest of your source files are in an incomplete state that would prevent a successful build of the entire project. Ctrl-F7 is the shortcut key for Compile.
ASCII code & number
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 !34 "35 #36 $37 %38 &39 '40 (41 )42 *43 +44 ,45 -46 .47 /48 049 150 251 352 453 554 655 756 857 958 :59 ;60 <61>63 ?64 @65 A66 B67 C68 D69 E70 F71 G72 H73 I74 J75 K76 L77 M78 N79 O80 P81 Q82 R83 S84 T85 U86 V87 W88 X89 Y90 Z91 [92 \93 ]94 ^95 _96 `97 a98 b99 c100 d101 e102 f103 g104 h105 i106 j107 k108 l109 m110 n111 o112 p113 q114 r115 s116 t117 u118 v119 w120 x121 y122 z123 {124 125 }126 ~127 128 €129 130 ‚131 ƒ132 „133 …134 †135 ‡136 ˆ137 ‰138 Š139 ‹140 Œ141 142 Ž143 144 145 ‘146 ’147 “148 ”149 •150 –151 —152 ˜153 ™154 š155 ›156 œ157 158 ž159 Ÿ160 161 ¡162 ¢163 £164 ¤165 ¥166 ¦167 §168 ¨169 ©170 ª171 «172 ¬173 174 ®175 ¯176 °177 ±178 ²179 ³180 ´181 µ182 ¶183 ·184 ¸185 ¹186 º187 »188 ¼189 ½190 ¾191 ¿192 À193 Á194 Â195 Ã196 Ä197 Å198 Æ199 Ç200 È201 É202 Ê203 Ë204 Ì205 Í206 Î207 Ï208 Ð209 Ñ210 Ò211 Ó212 Ô213 Õ214 Ö215 ×216 Ø217 Ù218 Ú219 Û220 Ü221 Ý222 Þ223 ß224 à225 á226 â227 ã228 ä229 å230 æ231 ç232 è233 é234 ê235 ë236 ì237 í238 î239 ï240 ð241 ñ242 ò243 ó244 ô245 õ246 ö247 ÷248 ø249 ù250 ú251 û252 ü253 ý254 þ255 ÿ
thumbnail generation code vb.net
Public Class Thumbnail
Dim OrgImgObj, Thumb As Drawing.Image
Public Function Create(ByVal ImgFolderPath As String, ByVal ThumbFolderPath As String, ByVal ImgSrcName As String, ByVal ThumbWidth As Int32, ByVal ThumbHeight As Int32) As Boolean
Try
OrgImgObj = OrgImgObj.FromFile(ImgFolderPath & "\" & ImgSrcName)
Thumb = OrgImgObj.GetThumbnailImage(ThumbWidth, ThumbHeight, Nothing, New IntPtr())
Thumb.Save(ThumbFolderPath & "\" & ImgSrcName, System.Drawing.Imaging.ImageFormat.Jpeg)
Return True
Catch Ex As Exception
Return False
End Try
End Function
End Class
Dim OrgImgObj, Thumb As Drawing.Image
Public Function Create(ByVal ImgFolderPath As String, ByVal ThumbFolderPath As String, ByVal ImgSrcName As String, ByVal ThumbWidth As Int32, ByVal ThumbHeight As Int32) As Boolean
Try
OrgImgObj = OrgImgObj.FromFile(ImgFolderPath & "\" & ImgSrcName)
Thumb = OrgImgObj.GetThumbnailImage(ThumbWidth, ThumbHeight, Nothing, New IntPtr())
Thumb.Save(ThumbFolderPath & "\" & ImgSrcName, System.Drawing.Imaging.ImageFormat.Jpeg)
Return True
Catch Ex As Exception
Return False
End Try
End Function
End Class
Saturday, September 13, 2008
selenium: asserting text present on screen & store true/false in a variable
checks "Reminders" on page if present it stores true else false in storedVars.rem
column 1 2 3
storeTextPresent Reminders rem
getEval alert(storedVars.rem)
Tuesday, August 19, 2008
Tips for increase performance of SQL database
Create a primary key on each table you create and unless you are really knowledgeable enough to figure out a better plan, make it the clustered index (note that if you set the primary key in Enterprise Manager it will cluster it by default).
Create an index on any column that is a foreign key. If you know it will be unique, set the flag to force the index to be unique.
Don’t index anything else (yet).
Unless you need a different behaviour, always owner qualify your objects when you reference them in TSQL. Use dbo.sysdatabases instead of just sysdatabases.
Use set nocount on at the top of each stored procedure (and set nocount off) at the bottom.
Think hard about locking. If you’re not writing banking software, would it matter that you take a chance on a dirty read? You can use the NOLOCK hint, but it’s often easier to use SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED at the top of the procedure, then reset to READ COMMITTED at the bottom.
Use transactions when appropriate, but allow zero user interaction while the transaction is in progress. I try to do all my transactions inside a stored procedure.
Avoid temp tables as much as you can, but if you need a temp table, create it explicitly using Create Table #temp.
Avoid NOT IN, instead use a left outer join - even though it’s often easier to visualize the NOT IN.
If you insist on using dynamic sql (executing a concatenated string), use named parameters and sp_executesql (rather than EXEC) so you have a chance of reusing the query plan. While it’s simplistic to say that stored procedures are always the right answer, it’s also close enough that you won’t go wrong using them.
Get in the habit of profiling your code before and after each change. While you should keep in mind the depth of the change, if you see more than a 10-15% increase in CPU, Reads, or Writes it probably needs to be reviewed.
Look for every possible way to reduce the number of round trips to the server. Returning multiple resultsets is one way to do this.
Avoid index and join hints.
When you’re done coding, set Profiler to monitor statements from your machine only, then run through the application from start to finish once. Take a look at the number of reads and writes, and the number of calls to the server. See anything that looks unusual? It’s not uncommon to see calls to procedures that are no longer used, or to see duplicate calls. Impress your DBA by asking him to review those results with you.
Create an index on any column that is a foreign key. If you know it will be unique, set the flag to force the index to be unique.
Don’t index anything else (yet).
Unless you need a different behaviour, always owner qualify your objects when you reference them in TSQL. Use dbo.sysdatabases instead of just sysdatabases.
Use set nocount on at the top of each stored procedure (and set nocount off) at the bottom.
Think hard about locking. If you’re not writing banking software, would it matter that you take a chance on a dirty read? You can use the NOLOCK hint, but it’s often easier to use SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED at the top of the procedure, then reset to READ COMMITTED at the bottom.
Use transactions when appropriate, but allow zero user interaction while the transaction is in progress. I try to do all my transactions inside a stored procedure.
Avoid temp tables as much as you can, but if you need a temp table, create it explicitly using Create Table #temp.
Avoid NOT IN, instead use a left outer join - even though it’s often easier to visualize the NOT IN.
If you insist on using dynamic sql (executing a concatenated string), use named parameters and sp_executesql (rather than EXEC) so you have a chance of reusing the query plan. While it’s simplistic to say that stored procedures are always the right answer, it’s also close enough that you won’t go wrong using them.
Get in the habit of profiling your code before and after each change. While you should keep in mind the depth of the change, if you see more than a 10-15% increase in CPU, Reads, or Writes it probably needs to be reviewed.
Look for every possible way to reduce the number of round trips to the server. Returning multiple resultsets is one way to do this.
Avoid index and join hints.
When you’re done coding, set Profiler to monitor statements from your machine only, then run through the application from start to finish once. Take a look at the number of reads and writes, and the number of calls to the server. See anything that looks unusual? It’s not uncommon to see calls to procedures that are no longer used, or to see duplicate calls. Impress your DBA by asking him to review those results with you.
Thursday, August 7, 2008
QTP: using dictionary object
Set d = CreateObject(”Scripting.Dictionary”)
d.Add “a”, “Anil” ‘ Add some keys and items.
d.Add “b”, “Dhruvan Aaryan”
a = d.Items ‘ Get the items.
For i = 0 To d.Count -1 ‘ Iterate the array.
s = s & a(i) & “
” ‘ Create return string.
Next
Msgbox s
Exists Method
Returns true if a specified key exists in the Dictionary object, false if it does not.
If d.Exists(”c”) Then
Msgbox “Specified key exists.”
Else
Msgbox “Specified key doesn’t exist.”
End If
d.Add “a”, “Anil” ‘ Add some keys and items.
d.Add “b”, “Dhruvan Aaryan”
a = d.Items ‘ Get the items.
For i = 0 To d.Count -1 ‘ Iterate the array.
s = s & a(i) & “
” ‘ Create return string.
Next
Msgbox s
Exists Method
Returns true if a specified key exists in the Dictionary object, false if it does not.
If d.Exists(”c”) Then
Msgbox “Specified key exists.”
Else
Msgbox “Specified key doesn’t exist.”
End If
Types of Builds
Based on the software release lifecycle page, and my personal experience, here's how I'd characterize each phase of software development:
Pre-Alpha
The software is still under active development and not feature complete or ready for consumption by anyone other than software developers. There may be milestones during the pre-alpha which deliver specific sets of functionality, and nightly builds for other developers or users who are comfortable living on the absolute bleeding edge.
Alpha
The software is complete enough for internal testing. This is typically done by people other than the software engineers who wrote it, but still within the same organization or community that developed the software.
Beta
The software is complete enough for external testing -- that is, by groups outside the organization or community that developed the software. Beta software is usually feature complete, but may have known limitations or bugs. Betas are either closed (private) and limited to a specific set of users, or they can be open to the general public.
Release Candidate
The software is almost ready for final release. No feature development or enhancement of the software is undertaken; tightly scoped bug fixes are the only code you're allowed to write in this phase, and even then only for the most heinous and debilitating of bugs. One of the most experienced software developers I ever worked with characterized the release candidate development phase thusly: "does this bug kill small children?"
Gold Candidate
The software is finished -- and by finished, we mean there are no show-stopping, little-children-killing bugs in it. That we know of. There are probably numerous lower-prority bugs triaged into the next point release or service pack, as well.
Pre-Alpha
The software is still under active development and not feature complete or ready for consumption by anyone other than software developers. There may be milestones during the pre-alpha which deliver specific sets of functionality, and nightly builds for other developers or users who are comfortable living on the absolute bleeding edge.
Alpha
The software is complete enough for internal testing. This is typically done by people other than the software engineers who wrote it, but still within the same organization or community that developed the software.
Beta
The software is complete enough for external testing -- that is, by groups outside the organization or community that developed the software. Beta software is usually feature complete, but may have known limitations or bugs. Betas are either closed (private) and limited to a specific set of users, or they can be open to the general public.
Release Candidate
The software is almost ready for final release. No feature development or enhancement of the software is undertaken; tightly scoped bug fixes are the only code you're allowed to write in this phase, and even then only for the most heinous and debilitating of bugs. One of the most experienced software developers I ever worked with characterized the release candidate development phase thusly: "does this bug kill small children?"
Gold Candidate
The software is finished -- and by finished, we mean there are no show-stopping, little-children-killing bugs in it. That we know of. There are probably numerous lower-prority bugs triaged into the next point release or service pack, as well.
Saturday, August 2, 2008
QTP:disabling report filter
Reporter.ReportEvent micFail,"anil's steps","am failing this"
Reporter.Filter = rfDisableAll
disables report filter for subsequent comands
Reporter.Filter = rfDisableAll
disables report filter for subsequent comands
QTP:opening explorer
SystemUtil.Run "C:\Program Files\Internet Explorer\IEXPLORE.EXE"
SystemUtil.Run "IEXPLORE.EXE"
SystemUtil.Run "IEXPLORE.EXE"
Subscribe to:
Posts (Atom)