...read the reviews. There must be half a dozen informative ones out there; a few of them have been linked already by others, and those that have been linked will probably reference the other reviews (many of the review sites do this). Determine what capabilities are important to you. If the Digital Rebel has them, it just might be the camera for you.
I've owned a Digital Rebel for about a month, after owning a couple of compact point-and-shoots (still use one of them) and a couple of "prosumer" SLR-like digicams (and, yes, a 35mm film SLR here and there). The Digital Rebel is the camera I had been waiting for: under $1000, autofocus performance unmatched by any non-SLR digicam, as well as the real depth of field control and low noise characteristics, courtesy of the (relatively) large sensor size.
Yes, there are other cameras that do more, but they also cost more. Again, whether you need a camera to do more is up to you. Unfortunately there are the snobs out there who think you should ignore the Rebel and get the 10D or something else, regardless of what *your* needs are. Relative to the 10D, probably the most significant limitations of the Rebel are the less rugged construction, smaller buffer, the limitations on setting single-shot or "servo" autofocus (they can be set but only in combination with other modes), and the lack of flash exposure control (unless you use a flash that allows you to set FEC, such as the 550EX). If any of the above are important to you, the Digital Rebel may not be the camera for you. But if you can live with its limitations (the only restriction that I find limiting so far is the inability to set servo AF in, say, aperture priority mode) it's a very rewarding camera.
So again, my advice to you is to read the reviews, consider what the camera can and cannot do, and decide whether it will meet your needs. Get your hands on one (they don't seem to be in short supply) and take some shots. I can't promise you'll like it, but if you're already familiar with SLR cameras and don't have the most demanding of requirements, you just might decide it's the camrea for you.
I went to a "parade of homes" thing (basically some builders construct some outrageously expensive homes which are then furnished with a bunch of lavish stuff) last year and saw one of these in one of the houses. (I don't know who made it.) It was in a bathroom, which is really about the only place I can see it possibly making sense--if someone likes to listen to/watch the morning news while they're brushing their teeth or something, this could be somewhat handy. It looks like it would be downright silly to use one as a regular TV, though.
The real world consists of plenty of quality programs with greatly extended deadlines (because the "real" deadline was impossible), as well as horrible programs delivered on time. Plenty of examples of each.
Sure, and furthermore there are plenty of examples of quality software that is delivered on time (partly because the goals were realistic). The original post implied that the expectation of high quality coupled with unrealistic deadlines was a phenomenon specific to academia, and I was merely pointing out that there's even more of this in "the real world."
Impossible deadlines are, by definition, impossible.
Can't argue with that, but the term impossible, when applied to deadlines, by convention usually means "possible but unrealistic." Occasionally, the term is used literally.
Canon offers a "Data Verification Kit" for its EOS-1Ds camera. The mechanism isn't as elaborate as you describe (with government registries and the like), but it does seem to employ some sort of digital signature mechanism.
Before submitting a Java program make sure you have a try catch(Exception) block somewhere to catch all exceptions. No crash!
"Crash" merely means that the program stops executing as intended. If at some point the code throws, for example, a NullPointerException due to the programmer's oversight, catching all Exceptions at the top level won't prevent the program from stopping unexpectedly ("crashing").
Seriously though, you can't always blame students for turning in programs with bugs. You can't expect anyone to make a quality program with impossible deadlines.
Making quality programs with impossible deadlines... what do you think the real world largely consists of?
If that's true about Cornell, it's a pity. When I was there, the CS deparment was so language-agnostic, the "C" class was just a two-week, 1 credit course, and that was the only class offered for a specific language. (Some were close: CS 100 used Pascal, and many AI classes used LISP or Scheme, but those were "Introduction to Programming" and AI classes, not classes in Pascal, LISP or Scheme). In fact, for my Data Structures class, the professor let us use any language we wanted (I took it as an opportunity to teach myself C++ and implement the homework assignments in an object-oriented way).
I don't think language-specific classes are all that valuable. (I'm pretty much self-taught in BASIC, C++, and Java, and have had very little difficulty picking up new languages as necessary.) If a specific language is truly required for a class (even for practical considerations such as grading assignments) then it's understandable, but the fact that Cornell for the most part stressed computer science concepts over choice of language was an asset to the CS department (in my opinion).
If Cornell has gone from this, to the point where they specifically use one language (any language--C# or Java or whatever), then that's a step backwards.
I don't know much about these devices (yet), but I do remember reading about the changes from the 5500 to the 5600, and one of them is that it's no longer necessary to run everything as root. The 5600 looks pretty sweet...
One of the things "pro" digitals are known for is having far less noise than lower-end digitals, and those improvements are constantly moving down to the consumer level.
Unfortunately one of the largest contributors to the reduced noise in "pro" digitals is the larger sensor size--a feature that so far isn't finding its way down to the consumer level.:-)
Where film is tough to beat is in its dynamic range, not its spatial resolution.
True, that. It'll be interesting to see just how much Fuji's new SuperCCD SR does towards increasing the dynamic range of digital photos. Or what other advances might be made on the dynamic range front...
It looked like there were spaces in the preview, but I double checked and they were not in the input text field, so I just thought it was some funky Mozilla text rendering (which it's been known to do). As for making them active... an oversight on my part. Thanks for taking the trouble.
There are at least two experienced photographers (Rob Galbraith and Michael Reichmann) who feel that the 11-megapixel Canon EOS-1Ds delivers images with detail exceeding that of 35mm and approaching (in some cases besting) medium format film. They've published some very interesting comparisons:
This may just change someone's opinon on how digital compares to film. I know it made me rethink the "conventional wisdom" that many more pixels are needed to reproduce film detail.
This conference is designed to discuss best practices, raise awareness and the share experiences among policy makers from the U.S. and Europe.
To the extent that Microsoft can contribute to the discussion of best practices, raising of awareness, etc. pertaining to open source, I don't see why they should be barred from participation. In fact I think their very presence may indirectly contribute to raising of awareness.
You make a lot of good points, and I agree that there's something not quite right about the "samples" from the Coolpix 2500 and the F5 in that article.
This statement, however:
Since each pixel in such cameras, as the article actually points out, can see either red, green or blue, neighboring pixels in the finished picture cannot be entirely different, because the hue of each pixel is determined from the brightness of the neighboring red, green and blue monochrome CCD pixels. Therefore a magnified image is always a little "soft" and true distinguished color detail are only possible over spans of two or more pixels. In the sample, however, the neighboring pixels shown are clearly completely unrelated, and as such the magnified sample is FAKE.
isn't quite right. Some Bayer interpolation algorithms interpolate a color difference rather than a color itself, which can introduce hue errors. This site [stanford.edu] provides a very useful comparison between some of the better-known interpolation algorithms out there.
CCD is a proven technology, with a lot of time put in to its development. That is why Nikon has stuck with CCD chips. Canon has been using Bayer CMOS chips in some of their prosumer cameras, but the top of the line 1Ds still uses a CCD chip.
The top-of-the-line EOS-1Ds uses a CMOS sensor, not a CCD. (The original EOS-1D has a CCD, though.) The new Kodak DCS Pro 14n also uses CMOS. Many other pro/prosumer SLRs, such as the Nikons you mentioned as well as the Fuji FinePix S1 and S2, still use CCDs.
The post to which I am replying is one of the few posts here that demonstrates an actual understanding of the economics involved in laying and lighting fiber.
To expand a little bit: Most of the existing fiber was laid in the "build it and they will come" dot-com era. There's a huge amount of it primarily for two reasons: (1) there were a lot of companies doing it independently--all hoping to get a big chunk of the bandwidth pie, and (2) when laying fiber, it makes economic sense to lay a lot of it, because (as pointed out) much of the cost in laying fiber is in the process of laying the fiber (lots of digging, etc.) and not in the actual fiber itself.
We now know that "build it and they will come," one of the assumptions of this business model, didn't quite happen--or at least didn't happen as quickly as what these companies' business models predicted: The voracious demand for long-haul capacity just isn't there today. Also, as a direct result of this capacity glut, the price (and profitability) of long haul bandwidth has decreased much faster than what these business models depended on. There's simply way too much supply. As for the companies that haven't yet fallen by the wayside, they're lighting only a fraction of the fiber that they own, simply because that fraction is capable of carrying the bandwidth that the company is currently able to sell.
Another thing to keep in mind is that almost none of this fiber is "last mile" (if any of it is at all). It's all comprised of "long haul" routes, e.g. connecting NYC and DC. So if you wanted to lease a dark fiber route from one metro area to another, you probably could, but it's not like the bandwidth companies are prepared to light up an OC3 to your suburban residence.
Finally, another key issue seems to be ignored here: IT COSTS MONEY TO LIGHT FIBER. Lots of money. The optical equipment itself is very expensive, and of course there are the operational costs of managing a transport network. Just as airlines don't want to spend money to fly empty planes from city to city (they still have to pay the crew, maintenance costs, fuel costs, etc. regardless of whether a flight carries 1 passenger or 100), bit pipe companies don't want to spend money to manage additional fiber when they aren't even saturating the fiber that they currently have lit.
Of course, it's also possible that the telcos have already run fiber to everyone's doorstep, but they're holding out on us because they want to "hold the man down" or for some other nefarious reason...
Think about it, with a guaranteed upgrade revenue stream, the pressure is off of them to release a new version every other year to keep profits up. It might actually allow them to focus on quality (yeah right) and actually put features in the OS people really want.
Or, more likely, with a guaranteed revenue stream they'll make only the bare minimum improvements to the product, instead concentrating their efforts on building more predatory, anticompetitive "features" into the OS.
Of course, pigs could fly too.
I find this scenario much more likely.;-)
Re:Obligatory Anti-Pattern Viewpoint
on
Design Patterns
·
· Score: 1
I did not say that there never was a need for [applications that don't use relational databases]. I am only saying that from my domain/niche's perspective, it is a relatively rare need.
I don't understand how, in one sentence you can state that OO (or design patterns, or whatever it is that you're against) aren't useful to you in your niche, but then elsewhere you appear to claim that OO and design patterns can't be useful to anyone else either because you've already worked out solutions for your niche that don't make use of OO.
There has to be an "image copy" of the data *somewhere*. Might as well keep it in a lite-duty table.
I'm not exactly sure what you're getting at here. Are you saying that you would have such a client re-query the database just to get the same data but sorted in a different order?
Anyhow, custom biz application programmers generally don't write such from *scratch* anyhow. That is a "systems" or "systems tools" programmer. I cannot speak for every niche, and few can. From the perspective of a custom biz app programmer, that is not a concern. I disclaimered niche differences from the beginning.
Again, if you're now claiming that your observations are from the point of view of a very narrow (by definition) niche of software development, how can you possibly extrapolate that OO and design patterns in general are just so much "snake oil," simply because you don't find that they apply to your niche so well?
We are discussing the OO-centric GOF patterns, no?
I thought were were simultaneously discussing design patterns in general as well as the GoF design patterns specifically.
Again, [a messaging application] is more of a "systems tool", and generally outside the niche of a "custom biz app" developer. While we are at it, I would not recommend DB's for high-speed action games either. (Perhaps role games, but not action.)
A lot of the same elements of a peer-to-peer messaging application are used in highly distributed business applications as well--the example was to illustrate that a lot of business applications require nontrivial functionality that has nothing to do with databases. Your example of action games is further evidence that there are entire classes of applications out there for which database-centric programming methodologies do not apply at all. But since OO and design patterns aren't good enough for you, they must not be good enough for developers working on these other sorts of applications either?
Please explain this one to me: Procedural and relational techniques are (still) quite *common* (regardless of current fashion or popularity). There are probably around 100 book titles dealing with OOP patterns, but nearly ZILCH dealing with procedural or relational patterns. Why the huge discrepancy? If 50K programmers use relational and 50K programmers use OOP, then shouldn't there be roughly as many DB titles as OOP book titles for "patterns for X"?
Publishers produce books that they (1) believe will sell, and (2) can find someone to write. So if there's a dearth of such books in the market, it's either because (1) no one has convinced a publisher that such a book would sell, and/or (2) no one has bothered to write such a book. I observed a few messages ago that you already have the beginnings of a useful collection of design patterns for database programming (whether or not you choose to see them as such). I think that with more content (the page even says there's more to come), more polish, and fewer cheap shots at OO, you'd have the makings of a book that a lot of database-centric application developers would probably find valuable. If there really are no such books in existence already, I'm sure it wouldn't be difficult to get a publisher interested. They usually like to see a proposal that includes a bit of market research--something along the lines of, "Design patterns are a recently popular idea. There are a number of design pattern books on the market today that are selling well. But the application of design patterns to database-centric applications has been largely ignored. I propose to fill this current void in the marketplace with this book." Perhaps you should look into it. Seriously.
Well, if I was ordered *not* to use a database else I would not get a paycheck, then you are right: GOF patterns may be better than the alternatives. But to me that is like saying, "Skateboards are better than walking if you are not allowed to use a car."
If you can't imagine any problem in computer science--particularly in the commercial application of computer science--that doesn't need to make use of a relational database, then either you are not trying, or you are experiencing acute myopia. As for the specific example of sorting, I'm sure you've seen some user interfaces that present some sort of data in tabular format. Often in such a UI, the user can click on a column heading to instantly sort the table according to the data in that column. It seems that your approach to implementing this feature would be for the client to request all the data from the database again, this time sorted by a different column. Wouldn't it be more reasonable just to re-sort the same data right in the client application?
I disagree. They tend to fight over territory. Procedural/relational techniques tends to abstract the noun modeling to the database, not programming code, which is where it is in most OO designs and GOF OO patterns.
Concepts don't fight over territory; people fight over territory. And I'll reiterate yet again: A design pattern is a solution to a problem. Design patterns are used a lot in OO, but they are by no means limited to OO. In fact they're not limited to software at all--design patterns originated with architecture and construction! So if patterns can be applied to building design and OO software design, is it that much of a stretch to say they can be applied to database design?
I would like to see them giving benefits above p/r in something I can relate to in actual code. Sorting, shapes, animals, device drivers, and the other common "training lore" used by OO enthusiasts do not appear to extrapolate to my domain. Whenever somebody has tried, the examples fall victim to my standard OO complaints about biz modeling and OO.
You want a nontrivial example? OK. Implement an instant messaging application (along the lines of AOL Instant Messenger), including both a server and two clients: a command-line and a GUI version. Clients and servers should communicate with each other using TCP/IP. Use only a relational database to implement the entire system.
(* Most (all?) of the pattern books assume that their audience is at least somewhat versed in the language of OO. You may not like OO, but it does provide a convenient language for the discussion of patterns. *)
Why is that? (Or, is that one of those questions that launches a thousand arguments?)
It's convenient for the authors to speak in the language of OO because their intended audience is fluent (or at least competent) in the language of OO. If you were to write a book about advanced optimization techniques for relational database applications, I would think your intended audience would have some sort of competency with relational database concepts.
Re:Obligatory Anti-Pattern Viewpoint
on
Design Patterns
·
· Score: 1
For example, if I'm using Strategy S (e.g. a comparator method) in Context C (e.g. a sorting algorithm), what does a database have to do with any of this?
I usually let the DB do the sorting for me.
That's great if you're using a database, but not everything comes from a database. Forget the concrete examples; the point is that design patterns and databases are orthogonal. You can have one without the other. You can use them both together. Or not. They have nothing to do with each other per se.
It is like using a car to go to the market. The car will take you most of the way there fairly conveniently. However, you still must walk the last 20 yards yourself. GOF tends to make you build your own vehicle for the entire trip, then brags that it also takes you into the store.
I don't understand the analogy. Design patterns don't tell you what (or how much) you have to build; they just suggest solutions for solving certain design problems after you've decided what it is that you want to do. For example, if you have a building that you want to be able to get in and out of, but you want to be able to shut out the elements, a design pattern you might want to consider would be the Door.
Strategy pattern is that the Context has no knowledge whatsoever of the particular Strategy being used.
Sorry, I am not sure what you mean by "Context" here.
And you just helped me to illustrate one of the values of design patterns: If we're both familiar with the Strategy pattern as described by Gamma et al, I can use the term Context, and you'll know what I'm talking about. Or, to put it in terms nearer and dearer to you, try describing a relational database design to me, but assume that I don't know what a table is, what a relationship is, what a row is, or what a column is, much less anything about referential integrity or things like that. Sooner or later I hope you'll understand that things like relationship tables (to map many-to-many relationships) are, in fact, design patterns.
What you're actually doing is describing patterns of your own.
I am not sure "pattern" applies. The relational formulas that do the bulk of the work are not any more "patterns" than a given math formula is. There are many possible combinations. Why GOF selected and paraded a subset with special names I am not quite sure yet.
The term pattern applies precisely. You are defining the context of a problem, presenting a solution to the problem in that context, and describing the consequences of the design. That's the textbook definition for a design pattern!
As for why the GoF chose the exact subset of known patterns that they did, I don't know. I suspect that the patterns presented in the book are those that they encountered most frequently in their research. This would be consistent with their stated goal of providing a lexicon of common design patterns.
Again, given a choice, I use databases and not code-centric collections for such things. I avoid code-based collections for all but the most trivial of collections. Your justification of patterns has twice relied on doing in code what I normally do with databases. You are trying to sell a horse saddle to a car driver:-)
I think that most of us, if we were fetching data from a database, would use ORDER BY to sort the data, as it wouldn't make sense not to. But as I've already pointed out, not everything is stored in a database. Furthermore, the example of sorting is just a very simple one that uses the Strategy pattern. If you cannot or will not consider the example outside the context of databases, then I don't understand why you insist on being obtuse.
The OO versions of them are over-hyped and too OO-centric in their presentation. The use of the word "pattern" is also misleading in some ways IMO.
Most (all?) of the pattern books assume that their audience is at least somewhat versed in the language of OO. You may not like OO, but it does provide a convenient language for the discussion of patterns. If all the pattern books had to reinvent their own language to discuss patterns before they could even introduce the language of patterns themselves, they would be that much harder to understand.
And just how is the term pattern misleading? Merriam-Webster defines a pattern as "a form or model proposed for imitation : EXEMPLAR"--I think the term is perfectly appropriate.
Re:Obligatory Anti-Pattern Viewpoint
on
Design Patterns
·
· Score: 1
I should have been more clear--the intent of my questions was not to ask how these patterns could be applied to data in a database, but how a database could be used to provide a general implementation of these patterns. For example, if I'm using Strategy S (e.g. a comparator method) in Context C (e.g. a sorting algorithm), what does a database have to do with any of this? My point here is that not everything is a database. In fact, not everything necessarily even touches a database.
However, since you offered it, I found that your discussion at http://geocities.com/tablizer/prpats.htm describes a few reasonable ways of implementing Strategy-like behavior using database functions (apparently). I might point out that one important aspect of the Strategy pattern is that the Context has no knowledge whatsoever of the particular Strategy being used. In your examples, the closest analogue is Approach #1, using run-time expression evaluation. If the expression to be evaluated can truly be anything, then this sounds like the Strategy pattern. The other mechanisms are "Strategy-like" and are probably even useful in some contexts, but they aren't implementations of the GoF Strategy pattern per se.
It's interesting that you titled your original message "Obligatory Anti-Pattern Viewpoint," yet on your Web page you discuss the implementation of various patterns in the context of relational databases. What you're actually doing is describing patterns of your own. Remember, a design pattern is simply a solution for a problem in a certain context, producing certain consequences. Your Web page is a discussion of exactly this. So you are actually promoting the use of patterns in what I would say is a very constructive way. So what's the "Obligatory Anti-Pattern Viewpoint" subject all about, when your Web page seems to recognize the value of design patterns and presents some useful discussion of design patterns in database programming?
Getting back to your message: You say that "In practice a 'pure' strategy pattern is not that common IMO." In my experience, I use it all the time, and in discussion with various others, I find that it is used a lot. In fact, any Java developer who has used the built-in sorting routines for collections of user-defined classes has used the Strategy pattern: The sorting algorithm has no knowledge whatsoever of user-defined types, but if such a class provides a strategy (in the form of a Comparator), the completely generic sorting routine can sort objects of that type. That's what the Strategy pattern is all about: The Context needs no knowledge whatsoever of the specific implementations of Strategy.
As for MVC being "out of style": Patterns are used because they provide useful solutions for problems, not because they're "in style." In any case, (1) MVC is still used; (2) "MVC" does not mean "GUI" (although many GUIs are implemented using MVC); (3) Using a database to store a definition of a GUI form may be a useful way to construct a GUI at runtime, but it is not an implementation of the MVC pattern. It may help with construction of the view, but it (a) probably couldn't implement all the details of the View, and (b) doesn't at all address the Model and Controller. Again, this does not mean that the mechanism isn't useful; it just illustrates that the use of design patterns and the use of databases are orthogonal.
I still don't understand your bashing of design patterns. Is it because they are generally associated with OO design (which I already know you don't care for; I won't go there)? I've already pointed out that your Web page provides a mostly constructive discussion of various patterns of procedural/relational design. So, clearly you have already observed that patterns apply equally to database programming as well. Instead of taking cheap jabs at OO design patterns, is there a reason that you don't direct that energy at further developing your discussion of procedural/relational design patterns?
Re:Obligatory Anti-Pattern Viewpoint
on
Design Patterns
·
· Score: 1
Huh?
Your entire post is a non-sequitir. I don't see how the use of design patterns in general, or any of the GoF patterns in particular, have anything to do with "reinventing a database" as you claim. Most of it simply has nothing to do with databases at all.
How would you implement the Strategy pattern using a database? Or the Model-View-Controller pattern?
There is a lot of misunderstanding...
on
Design Patterns
·
· Score: 1
...of what this book is about.
First of all, as to whether a book like this could even be considered "antiquated": In construction, a door is a design pattern. A window is a design pattern. A stairway is a design pattern. (A design pattern, after all, is just a solution for a problem in a particular context, with a particular set of consequences.) Even though construction techniques have certainly changed over the centuries, many of the common design patterns used in construction haven't changed all that much, if at all. I expect the situation to be the same for software, at least until there is a fundamental shift in the way programming is done.
Second, the authors of this book don't claim to have invented the patterns described within. They merely organized and catalogued a number of design patterns that were already in common use, formalizing their definition. The result is a lexicon of sorts, one that is useful not only as a reference, but (as many others have pointed out numerous times) because it provides the beginnings of a common vernacular in which developers may speak. I recently heard an analogy that works very well: a dovetail joint in carpentry. If, in communicating the design of a cabinet, a carpenter had to describe the mechanics of the dovetail joint to other carpenters, the communication would be inefficient to say the least. But, because of a common vernacular between carpenters, the term dovetail joint carries with it a specific context and a solution. Likewise, if I were to, for example, use the term strategy pattern in a conversation with other developers, it's obviously more efficient if they're familiar with the term than if I have to explain it. Gamma et al have already done the elaboration of most of the common design patterns.
Finally, note that I used the phrase "common design patterns"--this book isn't meant to be an exhaustive lexicon of design patterns; I'm sure that would be quite impossible. Rather, it describes many of the common ones (as well as some that aren't so common). There is no implication that, "If it's not in here, it's not a design pattern." Clearly, many other design patterns exist, as there are many problems in many contexts out there to be solved. Already we see books that present technology-specific design patterns (Core J2EE Patterns by Alur et al is an example of a collection of design patterns that generally make sense only within the context of J2EE.) So Design Patterns is not intended to be a canonical reference either. It's just a starting point.
So what is this book good for? First, it reasonably explains what design patterns are all about. (Obviously, other books do this as well; one that I like is Design Patterns Explained by Shalloway and Trott.) Second, and perhaps more importantly, the book provides an extensive (although not exhaustive lexicon of concepts, many of which are (or should be) universally used. I wouldn't say that every developer ought to be intimately familiar with every pattern described herein, but probably half of them should be in just about every developer's vocabulary. If it's useful to have this "dictionary" of design patterns on your bookshelf, then you'll probably find this book to be of value. If you already have access to design pattern references (on the Web, perhaps), then maybe you don't need this one as well.
Slashdot Mirror
Sensitivity at a reasonable cost? Three words: Canon Digital Rebel.
Cheers,
Jeremy
...read the reviews. There must be half a dozen informative ones out there; a few of them have been linked already by others, and those that have been linked will probably reference the other reviews (many of the review sites do this). Determine what capabilities are important to you. If the Digital Rebel has them, it just might be the camera for you.
I've owned a Digital Rebel for about a month, after owning a couple of compact point-and-shoots (still use one of them) and a couple of "prosumer" SLR-like digicams (and, yes, a 35mm film SLR here and there). The Digital Rebel is the camera I had been waiting for: under $1000, autofocus performance unmatched by any non-SLR digicam, as well as the real depth of field control and low noise characteristics, courtesy of the (relatively) large sensor size.
Yes, there are other cameras that do more, but they also cost more. Again, whether you need a camera to do more is up to you. Unfortunately there are the snobs out there who think you should ignore the Rebel and get the 10D or something else, regardless of what *your* needs are. Relative to the 10D, probably the most significant limitations of the Rebel are the less rugged construction, smaller buffer, the limitations on setting single-shot or "servo" autofocus (they can be set but only in combination with other modes), and the lack of flash exposure control (unless you use a flash that allows you to set FEC, such as the 550EX). If any of the above are important to you, the Digital Rebel may not be the camera for you. But if you can live with its limitations (the only restriction that I find limiting so far is the inability to set servo AF in, say, aperture priority mode) it's a very rewarding camera.
So again, my advice to you is to read the reviews, consider what the camera can and cannot do, and decide whether it will meet your needs. Get your hands on one (they don't seem to be in short supply) and take some shots. I can't promise you'll like it, but if you're already familiar with SLR cameras and don't have the most demanding of requirements, you just might decide it's the camrea for you.
Cheers,
Jeremy
I went to a "parade of homes" thing (basically some builders construct some outrageously expensive homes which are then furnished with a bunch of lavish stuff) last year and saw one of these in one of the houses. (I don't know who made it.) It was in a bathroom, which is really about the only place I can see it possibly making sense--if someone likes to listen to/watch the morning news while they're brushing their teeth or something, this could be somewhat handy. It looks like it would be downright silly to use one as a regular TV, though.
Cheers,
Jeremy
You find the difference between "free speech" and "free beer" ironic?
Actually it says it's a 75-millibit file... shouldn't take too long to download! :-)
Cheers,
Jeremy
Canon offers a "Data Verification Kit" for its EOS-1Ds camera. The mechanism isn't as elaborate as you describe (with government registries and the like), but it does seem to employ some sort of digital signature mechanism.
Cheers,
Jeremy
Cheers,
Jeremy
I don't think language-specific classes are all that valuable. (I'm pretty much self-taught in BASIC, C++, and Java, and have had very little difficulty picking up new languages as necessary.) If a specific language is truly required for a class (even for practical considerations such as grading assignments) then it's understandable, but the fact that Cornell for the most part stressed computer science concepts over choice of language was an asset to the CS department (in my opinion).
If Cornell has gone from this, to the point where they specifically use one language (any language--C# or Java or whatever), then that's a step backwards.
Cheers,
Jeremy
I don't know much about these devices (yet), but I do remember reading about the changes from the 5500 to the 5600, and one of them is that it's no longer necessary to run everything as root. The 5600 looks pretty sweet...
Cheers,
Jeremy
Unfortunately one of the largest contributors to the reduced noise in "pro" digitals is the larger sensor size--a feature that so far isn't finding its way down to the consumer level.
Cheers,
Jeremy
- Where film is tough to beat is in its dynamic range, not its spatial resolution.
True, that. It'll be interesting to see just how much Fuji's new SuperCCD SR does towards increasing the dynamic range of digital photos. Or what other advances might be made on the dynamic range front...Cheers,
Jeremy
It looked like there were spaces in the preview, but I double checked and they were not in the input text field, so I just thought it was some funky Mozilla text rendering (which it's been known to do). As for making them active... an oversight on my part. Thanks for taking the trouble.
Cheers,
Jeremy
There are at least two experienced photographers (Rob Galbraith and Michael Reichmann) who feel that the 11-megapixel Canon EOS-1Ds delivers images with detail exceeding that of 35mm and approaching (in some cases besting) medium format film. They've published some very interesting comparisons:
s p? cid=7-4833-4853
a s/ 1ds/1ds-field.shtml
http://www.robgalbraith.com/bins/content_page.a
http://www.luminous-landscape.com/reviews/camer
This may just change someone's opinon on how digital compares to film. I know it made me rethink the "conventional wisdom" that many more pixels are needed to reproduce film detail.
Cheers,
Jeremy
Cheers,
Jeremy
The post to which I am replying is one of the few posts here that demonstrates an actual understanding of the economics involved in laying and lighting fiber.
To expand a little bit: Most of the existing fiber was laid in the "build it and they will come" dot-com era. There's a huge amount of it primarily for two reasons: (1) there were a lot of companies doing it independently--all hoping to get a big chunk of the bandwidth pie, and (2) when laying fiber, it makes economic sense to lay a lot of it, because (as pointed out) much of the cost in laying fiber is in the process of laying the fiber (lots of digging, etc.) and not in the actual fiber itself.
We now know that "build it and they will come," one of the assumptions of this business model, didn't quite happen--or at least didn't happen as quickly as what these companies' business models predicted: The voracious demand for long-haul capacity just isn't there today. Also, as a direct result of this capacity glut, the price (and profitability) of long haul bandwidth has decreased much faster than what these business models depended on. There's simply way too much supply. As for the companies that haven't yet fallen by the wayside, they're lighting only a fraction of the fiber that they own, simply because that fraction is capable of carrying the bandwidth that the company is currently able to sell.
Another thing to keep in mind is that almost none of this fiber is "last mile" (if any of it is at all). It's all comprised of "long haul" routes, e.g. connecting NYC and DC. So if you wanted to lease a dark fiber route from one metro area to another, you probably could, but it's not like the bandwidth companies are prepared to light up an OC3 to your suburban residence.
Finally, another key issue seems to be ignored here: IT COSTS MONEY TO LIGHT FIBER. Lots of money. The optical equipment itself is very expensive, and of course there are the operational costs of managing a transport network. Just as airlines don't want to spend money to fly empty planes from city to city (they still have to pay the crew, maintenance costs, fuel costs, etc. regardless of whether a flight carries 1 passenger or 100), bit pipe companies don't want to spend money to manage additional fiber when they aren't even saturating the fiber that they currently have lit.
Of course, it's also possible that the telcos have already run fiber to everyone's doorstep, but they're holding out on us because they want to "hold the man down" or for some other nefarious reason...
Cheers,
Jeremy
If you can't imagine any problem in computer science--particularly in the commercial application of computer science--that doesn't need to make use of a relational database, then either you are not trying, or you are experiencing acute myopia. As for the specific example of sorting, I'm sure you've seen some user interfaces that present some sort of data in tabular format. Often in such a UI, the user can click on a column heading to instantly sort the table according to the data in that column. It seems that your approach to implementing this feature would be for the client to request all the data from the database again, this time sorted by a different column. Wouldn't it be more reasonable just to re-sort the same data right in the client application?
Concepts don't fight over territory; people fight over territory. And I'll reiterate yet again: A design pattern is a solution to a problem. Design patterns are used a lot in OO, but they are by no means limited to OO. In fact they're not limited to software at all--design patterns originated with architecture and construction! So if patterns can be applied to building design and OO software design, is it that much of a stretch to say they can be applied to database design?
You want a nontrivial example? OK. Implement an instant messaging application (along the lines of AOL Instant Messenger), including both a server and two clients: a command-line and a GUI version. Clients and servers should communicate with each other using TCP/IP. Use only a relational database to implement the entire system.
It's convenient for the authors to speak in the language of OO because their intended audience is fluent (or at least competent) in the language of OO. If you were to write a book about advanced optimization techniques for relational database applications, I would think your intended audience would have some sort of competency with relational database concepts.
As for why the GoF chose the exact subset of known patterns that they did, I don't know. I suspect that the patterns presented in the book are those that they encountered most frequently in their research. This would be consistent with their stated goal of providing a lexicon of common design patterns.
I think that most of us, if we were fetching data from a database, would use ORDER BY to sort the data, as it wouldn't make sense not to. But as I've already pointed out, not everything is stored in a database. Furthermore, the example of sorting is just a very simple one that uses the Strategy pattern. If you cannot or will not consider the example outside the context of databases, then I don't understand why you insist on being obtuse. Most (all?) of the pattern books assume that their audience is at least somewhat versed in the language of OO. You may not like OO, but it does provide a convenient language for the discussion of patterns. If all the pattern books had to reinvent their own language to discuss patterns before they could even introduce the language of patterns themselves, they would be that much harder to understand.And just how is the term pattern misleading? Merriam-Webster defines a pattern as "a form or model proposed for imitation : EXEMPLAR"--I think the term is perfectly appropriate.
However, since you offered it, I found that your discussion at http://geocities.com/tablizer/prpats.htm describes a few reasonable ways of implementing Strategy-like behavior using database functions (apparently). I might point out that one important aspect of the Strategy pattern is that the Context has no knowledge whatsoever of the particular Strategy being used. In your examples, the closest analogue is Approach #1, using run-time expression evaluation. If the expression to be evaluated can truly be anything, then this sounds like the Strategy pattern. The other mechanisms are "Strategy-like" and are probably even useful in some contexts, but they aren't implementations of the GoF Strategy pattern per se.
It's interesting that you titled your original message "Obligatory Anti-Pattern Viewpoint," yet on your Web page you discuss the implementation of various patterns in the context of relational databases. What you're actually doing is describing patterns of your own. Remember, a design pattern is simply a solution for a problem in a certain context, producing certain consequences. Your Web page is a discussion of exactly this. So you are actually promoting the use of patterns in what I would say is a very constructive way. So what's the "Obligatory Anti-Pattern Viewpoint" subject all about, when your Web page seems to recognize the value of design patterns and presents some useful discussion of design patterns in database programming?
Getting back to your message: You say that "In practice a 'pure' strategy pattern is not that common IMO." In my experience, I use it all the time, and in discussion with various others, I find that it is used a lot. In fact, any Java developer who has used the built-in sorting routines for collections of user-defined classes has used the Strategy pattern: The sorting algorithm has no knowledge whatsoever of user-defined types, but if such a class provides a strategy (in the form of a Comparator), the completely generic sorting routine can sort objects of that type. That's what the Strategy pattern is all about: The Context needs no knowledge whatsoever of the specific implementations of Strategy.
As for MVC being "out of style": Patterns are used because they provide useful solutions for problems, not because they're "in style." In any case, (1) MVC is still used; (2) "MVC" does not mean "GUI" (although many GUIs are implemented using MVC); (3) Using a database to store a definition of a GUI form may be a useful way to construct a GUI at runtime, but it is not an implementation of the MVC pattern. It may help with construction of the view, but it (a) probably couldn't implement all the details of the View, and (b) doesn't at all address the Model and Controller. Again, this does not mean that the mechanism isn't useful; it just illustrates that the use of design patterns and the use of databases are orthogonal.
I still don't understand your bashing of design patterns. Is it because they are generally associated with OO design (which I already know you don't care for; I won't go there)? I've already pointed out that your Web page provides a mostly constructive discussion of various patterns of procedural/relational design. So, clearly you have already observed that patterns apply equally to database programming as well. Instead of taking cheap jabs at OO design patterns, is there a reason that you don't direct that energy at further developing your discussion of procedural/relational design patterns?
Your entire post is a non-sequitir. I don't see how the use of design patterns in general, or any of the GoF patterns in particular, have anything to do with "reinventing a database" as you claim. Most of it simply has nothing to do with databases at all.
How would you implement the Strategy pattern using a database? Or the Model-View-Controller pattern?
First of all, as to whether a book like this could even be considered "antiquated": In construction, a door is a design pattern. A window is a design pattern. A stairway is a design pattern. (A design pattern, after all, is just a solution for a problem in a particular context, with a particular set of consequences.) Even though construction techniques have certainly changed over the centuries, many of the common design patterns used in construction haven't changed all that much, if at all. I expect the situation to be the same for software, at least until there is a fundamental shift in the way programming is done.
Second, the authors of this book don't claim to have invented the patterns described within. They merely organized and catalogued a number of design patterns that were already in common use, formalizing their definition. The result is a lexicon of sorts, one that is useful not only as a reference, but (as many others have pointed out numerous times) because it provides the beginnings of a common vernacular in which developers may speak. I recently heard an analogy that works very well: a dovetail joint in carpentry. If, in communicating the design of a cabinet, a carpenter had to describe the mechanics of the dovetail joint to other carpenters, the communication would be inefficient to say the least. But, because of a common vernacular between carpenters, the term dovetail joint carries with it a specific context and a solution. Likewise, if I were to, for example, use the term strategy pattern in a conversation with other developers, it's obviously more efficient if they're familiar with the term than if I have to explain it. Gamma et al have already done the elaboration of most of the common design patterns.
Finally, note that I used the phrase "common design patterns"--this book isn't meant to be an exhaustive lexicon of design patterns; I'm sure that would be quite impossible. Rather, it describes many of the common ones (as well as some that aren't so common). There is no implication that, "If it's not in here, it's not a design pattern." Clearly, many other design patterns exist, as there are many problems in many contexts out there to be solved. Already we see books that present technology-specific design patterns (Core J2EE Patterns by Alur et al is an example of a collection of design patterns that generally make sense only within the context of J2EE.) So Design Patterns is not intended to be a canonical reference either. It's just a starting point.
So what is this book good for? First, it reasonably explains what design patterns are all about. (Obviously, other books do this as well; one that I like is Design Patterns Explained by Shalloway and Trott.) Second, and perhaps more importantly, the book provides an extensive (although not exhaustive lexicon of concepts, many of which are (or should be) universally used. I wouldn't say that every developer ought to be intimately familiar with every pattern described herein, but probably half of them should be in just about every developer's vocabulary. If it's useful to have this "dictionary" of design patterns on your bookshelf, then you'll probably find this book to be of value. If you already have access to design pattern references (on the Web, perhaps), then maybe you don't need this one as well.