Designing UI applications

"Everything is best for something and worst for something else.
The trick is knowing for what, when, for whom, and why." —Bill Buxton


I was involved in Windows based application development for some time and it was seriously lacking a good user interaction guideline doc. I have read lot of books and articles but they are not quite up to the standards. Check this out from Microsoft...

UI Guidelines

Handy sql script to find lost quries

I always forget to save the quires that I'm executing against sql server and want to recover them without writing them back, here's a handy script which I use for this

select objtype,p.size_in_bytes,[sql].text
from sys.dm_exec_cached_plans p
outer apply sys.dm_exec_sql_text (p.plan_handle) sql
where [sql].[test] like '%Something goes here%'
order by usecounts desc

Back to business

Writing a blog post after a long time. I went through all of my friends blogs today and felt sad b'cos I was not contributing at all.

Here are some tips for software ARCHITECTS

1. Don't put your resume ahead of the requirements
2. Simplify essential complexity; diminish accidental complexity
3. Chances are your biggest problem isn't technical
4. Communication is King; Clarity and Leadership its humble servants
5. Architecting is about balancing
6. Seek the value in requested capabilities
7. Stand Up!
8. Skyscrapers aren't scalable
9. You're negotiating more often than you think
10. Quantify
11. One line of working code is worth 500 of specification
12. There is no one-size-fits-all solution
13. It's never too early to think about performance
14. Application architecture determines application performance
15. Commit-and-run is a serious crime. Respect your Colleagues
16. There Can be More than One
17. Business Drives
18. Simplicity before generality, use before reuse
19. Architects must be hands on
20. Continuously Integrate
21. Avoid Scheduling Failures
22. Architectural Tradeoffs
23. Database as a Fortress
24. Use uncertainty as a driver
25. Scope is the enemy of success
26. Reuse is about people and education, not just architecture
27. There is no 'I' in architecture
28. Get the 1000ft view
29. Try before choosing
30. Understand The Business Domain
31. Programming is an act of design
32. Time changes everything
33. Give developers autonomy
34. Value stewardship over showmanship
35. Warning, problems in mirror may be larger than they appear
36. The title of software architect has only lower-case 'a's; deal with it
37. Software architecture has ethical consequences
38. Everything will ultimately fail
39. Context is King
40.It's all about performance
41. Engineer in the white spaces
42. Talk the Talk
43. Heterogeneity Wins
44. Dwarves, Elves, Wizards, and Kings
45. Learn from Architects of Buildings
46. Fight repetition
47. Welcome to the real world
48. Don't Control, but Observe
49. Janus the Architect
50.Architects focus is on the boundaries and interfaces
51.Challenge assumptions - especially your own
52.Record your rationale
53.Empower developers
54.It is all about the data
55.Control the data, not just the code
56.Don't Stretch The Architecture Metaphors
57. Focus on Application Support and Maintenance
58. Prepare to pick two
59. Prefer principles, axioms and analogies to opinion and taste
60. Start with a Walking Skeleton
61. Share your knowledge and experiences
62. Make sure the simple stuff is simple
63. If you design it, you should be able to code it
64. The ROI variable
65. Your system is legacy, design for it
66. If there is only one solution, get a second opinion
67. Understand the impact of change
68. You have to understand Hardware too
69. Shortcuts now are paid back with interest later
70. "Perfect" is the Enemy of "Good Enough"
71. Avoid "Good Ideas"
72. Great content creates great systems
73. The Business Vs. The Angry Architect
74. Stretch key dimensions to see what breaks
75. Before anything, an architect is a developer
76. A rose by any other name will end up as a cabbage
77. Stable problems get high quality solutions
78. It Takes Diligence
79. Take responsibility for your decisions
80. Dont Be a Problem Solver
81. Choose your weapons carefully, relinquish them reluctantly
82. Your Customer is Not Your Customer
83. It will never look like that
84. Choose Frameworks that play well with others
85. Making a strong business case
86. Pattern Pathology
87. Learn a new language
88. Dont Be Clever
89. Build Systems to be Zuhanden
90. Find and retain passionate problem solvers
91. Software doesnt really exist
92. Pay down your technical debt
93. You can't future-proof solutions
94. The User Acceptance Problem
95. The Importance of Consommé
96. For the end-user, the interface is the system
97. Great software is not built, it is grown

Detail article can be found at 97 things software architect should know

SQL Performance Tips

When you are writing serious SQL, TSQL or PLSQL one of the common error that you play around is the "Time Out" errors. There are number of reasons for these errors. You have to exactly pin point the problem to properly fix it. I thought of publishing some links that I found on this area which might helpful for you
The areas which you have to look for are :
1) Transaction Locking
2) Performance of your queries (In medium and high data volumes)
3) Transaction isolation levels
4) Clustered index and indexes of your tables
Browse the flowing for in-depth understanding.....

DBA’s Quick Guide to Timeouts
How to troubleshoot ODBC timeout errors

Dynamic SQL Tips and Tricks

Definitely you will be facing lot of challenges in your day to day SQL programming. I found the following site very use full to find curse and blessings of dynamic SQL. Have a look, it might be useful for for you as well


The Curse and Blessings of Dynamic SQL

ASP.NET Ajax support in DNN

DotnetNuke developers good news! Partial rendering (ASP.NET Ajax support) is now available for module controls with DNN 4.5. Shaun Walker has published a good blog post. This is a good initiative and definitely .NET community will love this.

Architects! Design Scalable ASP.NET Solutions

Do you have these issues ?

• My solution accesses web services and they are fairly slow
  
• Overall site usage is very high
  
• Simple web requests takes too long to get their responses
  

The reason for the above issues are the solution is not scaling enough to handle heavy work loads. If you are using web services in your solution the site can easily get bogged down when there is a heavy load accessing the site. The reason for this is the entire ASP.NET thread pool will get busy due to slow web service calls and then all the subsequent requests starts queueing up until threads gets free-ed up. The reason is solution is not scaling in heavy work loads.

One of the simplest design technique is to design asynchronous pages which access third party web services. ASP.NET 2.0 has built in support for implementing Async web pages. You simply have to :

1) Add <%@ Page Async="true" directive in your page
2) Register "Begin event handler" and "End event handler" delegates using AddOnPreRenderCompleteAsync method

Call your web service in Begin event handler and process the web service response in End event handler. Read this for in-depth understanding.

My Last Trip at EC

This was my last trip at Eurocenter and was a remarkable one. The place was beautiful and we enjoyed a lot at this cool atmosphere. EC guys were great and I will miss these great fun events yet to come..............