2006-08-29
How to give a good talk Hany Farid, Dartmouth
How to give a good talk Hany Farid, Dartmouth: what is considered to be some of the most important things that you can do to give a good talk
2006-08-08
Providing Custom Layout Engines for Windows Forms
Providing Custom Layout Engines for Windows Forms
Windows Forms provides all the needed methods and events for providing rich custom layout. However, what is lacking is an extensible framework for writing custom reusable layout engines. In addition, there needs to be a set of stock layout components that provide the most common types of layout.
Windows Forms provides all the needed methods and events for providing rich custom layout. However, what is lacking is an extensible framework for writing custom reusable layout engines. In addition, there needs to be a set of stock layout components that provide the most common types of layout.
2006-07-27
The Career Programmer: Guerilla Tactics For An Imperfect World - The Code Project - Book Chapters
The Career Programmer: Guerilla Tactics For An Imperfect World by Christopher Duncan.
The Code Project - Book Chapters.
Practical advice to programmers in corporate environment.
Amazon
2006-07-23
The Food Timeline: food history reference & research service
The Food Timeline: food history reference & research servicea great food history and culinary research project.
SAP Design Guild -- Fighting (with) Hierarchies - Part II: Presentation
SAP Design Guild -- Fighting (with) Hierarchies - Part II: Presentation
This article on hierarchies takes a closer look at the presentation of hierarchies. Hierarchies are often huge, complex and abstract. How can this mass of data be efficiently displayed in the restricted amount of space that is available on a computer screen?
This article on hierarchies takes a closer look at the presentation of hierarchies. Hierarchies are often huge, complex and abstract. How can this mass of data be efficiently displayed in the restricted amount of space that is available on a computer screen?
2006-07-22
MIT Libraries News � Blog Archive � Learn about Publishing Choices for MIT Grads and Postdocs, Friday July 28 at 12 Noon
MIT Libraries News � Blog Archive � Learn about Publishing Choices for MIT Grads and Postdocs, Friday July 28 at 12 Noon
Learn how to find and use information more effectively in these hands-on workshops. It’s like IAP, only warmer!
WHEN: Every Friday in July, 12 Noon - 1 pm
WHERE: 14N-132 (Digital Instruction Resource Center – DIRC)
Learn how to find and use information more effectively in these hands-on workshops. It’s like IAP, only warmer!
WHEN: Every Friday in July, 12 Noon - 1 pm
WHERE: 14N-132 (Digital Instruction Resource Center – DIRC)
2006-07-21
Scott Hanselman's Computer Zen - Scott Hanselman's 2005 Ultimate Developer and Power Users Tool List
Scott Hanselman's Computer Zen - Scott Hanselman's 2005 Ultimate Developer and Power Users Tool List
A collection developer and power user tools and utilities.
A collection developer and power user tools and utilities.
2006-06-25
Codd's 12 Rules
Codd's 12 Rules
Rule 1: The Information Rule All data should be presented to the user in table form. Last week's newsletter already discussed the basics of this rule.
Rule 2: Guaranteed Access Rule All data should be accessible without ambiguity. This can be accomplished through a combination of the table name, primary key, and column name.
Rule 3: Systematic Treatment of Null Values A field should be allowed to remain empty. This involves the support of a null value, which is distinct from an empty string or a number with a value of zero. Of course, this can't apply to primary keys. In addition, most database implementations support the concept of a nun- null field constraint that prevents null values in a specific table column.
Rule 4: Dynamic On-Line Catalog Based on the Relational Model A relational database must provide access to its structure through the same tools that are used to access the data. This is usually accomplished by storing the structure definition within special system tables.
Rule 5: Comprehensive Data Sublanguage Rule The database must support at least one clearly defined language that includes functionality for data definition, data manipulation, data integrity, and database transaction control. All commercial relational databases use forms of the standard SQL (Structured Query Language) as their supported comprehensive language.
Rule 6: View Updating Rule Data can be presented to the user in different logical combinations, called views. Each view should support the same full range of data manipulation that direct-access to a table has available. In practice, providing update and delete access to logical views is difficult and is not fully supported by any current database.
Rule 7: High-level Insert, Update, and Delete Data can be retrieved from a relational database in sets constructed of data from multiple rows and/or multiple tables. This rule states that insert, update, and delete operations should be supported for any retrievable set rather than just for a single row in a single table.
Rule 8: Physical Data Independence The user is isolated from the physical method of storing and retrieving information from the database. Changes can be made to the underlying architecture ( hardware, disk storage methods ) without affecting how the user accesses it.
Rule 9: Logical Data Independence How a user views data should not change when the logical structure (tables structure) of the database changes. This rule is particularly difficult to satisfy. Most databases rely on strong ties between the user view of the data and the actual structure of the underlying tables.
Rule 10: Integrity Independence The database language (like SQL) should support constraints on user input that maintain database integrity. This rule is not fully implemented by most major vendors. At a minimum, all databases do preserve two constraints through SQL.
No component of a primary key can have a null value. (see rule 3)
If a foreign key is defined in one table, any value in it must exist as a primary key in another table.
Rule 11: Distribution Independence A user should be totally unaware of whether or not the database is distributed (whether parts of the database exist in multiple locations). A variety of reasons make this rule difficult to implement; I will spend time addressing these reasons when we discuss distributed databases.
Rule 12: Nonsubversion Rule There should be no way to modify the database structure other than through the multiple row database language (like SQL). Most databases today support administrative tools that allow some direct manipulation of the datastructure.
Rule 1: The Information Rule All data should be presented to the user in table form. Last week's newsletter already discussed the basics of this rule.
Rule 2: Guaranteed Access Rule All data should be accessible without ambiguity. This can be accomplished through a combination of the table name, primary key, and column name.
Rule 3: Systematic Treatment of Null Values A field should be allowed to remain empty. This involves the support of a null value, which is distinct from an empty string or a number with a value of zero. Of course, this can't apply to primary keys. In addition, most database implementations support the concept of a nun- null field constraint that prevents null values in a specific table column.
Rule 4: Dynamic On-Line Catalog Based on the Relational Model A relational database must provide access to its structure through the same tools that are used to access the data. This is usually accomplished by storing the structure definition within special system tables.
Rule 5: Comprehensive Data Sublanguage Rule The database must support at least one clearly defined language that includes functionality for data definition, data manipulation, data integrity, and database transaction control. All commercial relational databases use forms of the standard SQL (Structured Query Language) as their supported comprehensive language.
Rule 6: View Updating Rule Data can be presented to the user in different logical combinations, called views. Each view should support the same full range of data manipulation that direct-access to a table has available. In practice, providing update and delete access to logical views is difficult and is not fully supported by any current database.
Rule 7: High-level Insert, Update, and Delete Data can be retrieved from a relational database in sets constructed of data from multiple rows and/or multiple tables. This rule states that insert, update, and delete operations should be supported for any retrievable set rather than just for a single row in a single table.
Rule 8: Physical Data Independence The user is isolated from the physical method of storing and retrieving information from the database. Changes can be made to the underlying architecture ( hardware, disk storage methods ) without affecting how the user accesses it.
Rule 9: Logical Data Independence How a user views data should not change when the logical structure (tables structure) of the database changes. This rule is particularly difficult to satisfy. Most databases rely on strong ties between the user view of the data and the actual structure of the underlying tables.
Rule 10: Integrity Independence The database language (like SQL) should support constraints on user input that maintain database integrity. This rule is not fully implemented by most major vendors. At a minimum, all databases do preserve two constraints through SQL.
No component of a primary key can have a null value. (see rule 3)
If a foreign key is defined in one table, any value in it must exist as a primary key in another table.
Rule 11: Distribution Independence A user should be totally unaware of whether or not the database is distributed (whether parts of the database exist in multiple locations). A variety of reasons make this rule difficult to implement; I will spend time addressing these reasons when we discuss distributed databases.
Rule 12: Nonsubversion Rule There should be no way to modify the database structure other than through the multiple row database language (like SQL). Most databases today support administrative tools that allow some direct manipulation of the datastructure.
2006-06-24
Peg Words
This is a method of mneuminic association of numbers 00-09 and 0-99 with words.
0. Sea 10. Toes 20. Nose 30. Mouse 40. Rose
1. Hat 11. Dot 21. Net 31. Mat 41. Road
2. Hen 12. Town 22. Nun 32. Moon 42. Rain
3. Ham 13. Dime 23. Name 33. Mummy 43. Room
4. Rye 14. Tire 24. Nero 34. Mower 44. Aurora
5. Hill 15. Doll 25. Nail 35. Mule 45. Roll
6. Shoe 16. Tissue 26. Notch 36. Match 46. Rash
7. Cow 17. Duck 27. Neck 37. Mug 47. Rock
8. Ivy 18. Taffy 28. Knife 38. Movie 48. Roof
9. Bee 19. Tape 29. Knob 39. Map 49. Rope
50. Lace 60. Cheese 70. Gas 80. Fez 90. Bus 00. Susie
51. Light 61. Sheet 71. Cat 81. Fat 91. Bat 01. Seed
52. Lion 62. Chain 72. Can 82. Fan 92. Pen 02. Sun
53. Lime 63. Jam 73. Comb 83. Foam 93. Opium 03. Seam
54. Lure 64. Cherry 74. Car 84. Fire 94. Bear 04. Sarah
55. Lily 65. Jello 75. Coal 85. File 95. Bell 05. Seal
56. Leech 66. Judge 76. Cage 86. Fish 96. Beach 06. Sash
57. Log 67. Chalk 77. Coke 87. Fog 97. Book 07. Sack
58. Lava 68. Chef 78. Cave 88. Fife 98. Puff 08. Sofa
59. Lip 69. Ship 79. Cape 89. Fib 99. Pipe 09. Sap
With the following key:
Memorizing numbers
NUMBER LETTER/SOUND MEMORY AID
1 t, d t has one downstroke
2 n n has two downstrokes
3 m m has three downstrokes
4 r "four" ends with R
5 l Latin 50 = L
6 j, sh, ch J reversed looks like 6
7 k, g (hard) Visualize a K drawn with two 7s
8 f, v Cursive f has two loops like an 8
9 p, b P reversed looks like 9
0 z, s "zero" starts with Z
Subscribe to:
Posts (Atom)