Just started this book. My initial impression is that it should be fun to read: the author clearly has a sense of humor, so I expect the book to provide a lot of good content, while not being merely [more...]
HTML5 & CSS3 For The Real World
My initial thought was to use this book as a reference; however, at a friend's suggestion, I'm reading it from one end to the other--and there's a lot of interesting stuff. I appreciate, for instance, [more...]
One reason I bought this book was its coverage of such concepts as Closure, Currying, and Memoization.
Some of the book's content is easy to read and digest, but there are also concepts that take a bit longer, suggesting the time required to understand is well spent.
The Mythical Man-Month: Essays on Software Engineering
The author received in 1999 the ACM's A. M. Turing Award, which, according to the back cover is "the most prestigious award in the computing field." He is cited for "landmark contributions to [more...]
Chapter 1: The Tar Pit. In this chapter, I learned the distinction between a "program," a "programming product," a "programming system," and a "programming systems product."
The chapter describe the joys and the woes of programming, and I can relate to both.
One particularly salient point I gleaned from this chapter is that, because of the constant advance of technology, a product's design is immediately obsolete. That is, by the time an idea is implemented, the cutting edge has been extended. As the chapter puts it, "As soon as one freezes a design, it becomes obsolete in terms of its concepts." Yet, as it goes on to observe, "The obsolescence of an implementation must be measured against other existing implementations, not against unrealized concepts" (p. 9).
Chapter 2: The Mythical Man-Month. Here, the author explains that most programming projects have gone awry because of unrealistic scheduling. He offers several reasons, including the incorrigible optimism of programmers in believing that "all will go well," or "each task will take only as long as it 'ought' to take" (p. 14). He also highlights the fallacy of thinking that adding more programmers to a team will decrease the amount of time needed to complete a project: "Adding more men then lengthens, not shortens, the schedule" (p. 19).
Chapter 3: The Surgical Team. In this chapter, the author suggests a composition for a programming team. This team would be composed of one chief programmer and an assistant who is able to do everything the programmer does. In addition, the team includes an administrator, an editor, secretaries, a clerk, toolsmith, tester, and "language lawyer."
A principle of object-oriented design is loose coupling of objects (Harmes & Diaz, p. 107). This is where the bridge pattern becomes particularly useful. [more...]
A principle of object-oriented design is loose coupling of objects (Harmes & Diaz, p. 107). This is where the bridge pattern becomes particularly useful. According to the Gang of Four, the bridge pattern "should decouple an abstraction from its implementation so that the two can vary independently." (Harmes & Diaz, p. 109).