As a programmer, I don’t I should know about this for now. So, let’s just create a placeholder here.
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 […]
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 […]
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
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!
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
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 […]
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. […]
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.
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 […]