Notes on ‘Expert Oracle’ — No.3: Files
As a programmer, I don’t I should know about this for now. So, let’s just create a placeholder here.
Month: November 2009
Notes on ‘Expert Oracle’ — No.2: Abstract of the Arch
1. Database and Instance Database: Static Contents in Disks Instance: Processes/Threads and Memory running on a Database A Database can only be opened by a single instance. An instance can only open a single Database. And it dies when it cloese the Database. 2. SGA: A shared memory area by all …
Notes on ‘Expert Oracle’ — No.2: Abstract of the Arch Read More »
Notes on ‘Expert Oracle’ — No.1: Programmers should know about Oracle
1. As programmers, you should know the fundmental details of the database, especially when concurrency and performance is concerned. 2.Don’t stick to "database portability." a. You are not going to need it. b. It’s basically impossible since databases are so different from each other, concurrency strategy for example. 3.Don’t hesitate to make use …
Notes on ‘Expert Oracle’ — No.1: Programmers should know about Oracle Read More »
How to choose test cases
From ‘Beautiful Code’ 1. Start from Smoke Test 2. Then add Boundary Tests 3. Go on with other tests for a complete coverage (random tests etc.) 4. Finally, add some tests for performance P.S. : Try to do random tests by generating numerous random values
Notes on XP — No.17: Adopting XP
Adopt XP one practice at a time 1. Pick your worst problem 2. Solve it the XP WAY 3. When it’s no longer your worst problem, repeat. The two obvious places to start are testing and the Planning Game Don’t underestimate the importance of the physical environment!
Notes on XP — No.16: Test Strategy
1. You don’t write tests for anything. You write tests for things what MIGHT break. 2. Two kinds of tests a.Unit Tests written by Programmers b.Functional Tests written by Custoerms
Notes on XP — No.15: Design Strategy
1. Always have the simplest thing that could possibly work(that can make all the test cases run) 2. Design through refactoring a.Implement the first story, then the second, then remove the duplicated codes b.Refactoring should be done step by step (Incremental Change) 3.Why XP suggests we only design for today? Won’t it …
Notes on XP — No.14: Development Strategy
1. Continuous Integration I wan not convinced by Kent Beck. I’ll look into it for more. 2. Collective Ownership a. The code will be simpler and simpler. If you don’t make it simple, others will. b. Stupid code will not stuck you anymore because you can get it out of the way. …
Notes on XP — No.13: Planning Game (2)– Iteration Planning Game
The Iteration Planning Game is similar to the Planning Game. Player: Individual Programmers Pieces: Task Cards Moves: 1. Find out what tasks there will be. Do splitting if necessary. 2. Accept and Estimate tasks. Y = Ideal Engineering Time * load factors 3. Keep everything in track.
Notes on XP — No.12: Planning Game (1)
The Planning Game Players: Business People VS Development People Pieces: Store Careds Moves: 1. Find out what new things the system could do Write a story(Biz) -> Estimate a story(Dev) -> Split a story if development can’t estimate 2. Choose the most valuable subset of requirements Sort the …