"Rings quite hollow" must be a euphemism for "I'm too lazy to look up any data to determine if this is actually true or not, so I'm going to talk about my feelings instead".
The versions of web developer-like plugins for Safari, just suck; it's as simple as that. Otherwise I'd be on Safari. But it's far more proprietary-behaving than Firefox.
1.) Turn on the developer menu under advanced preferences. This gives you DOM and CSS inspection, network activity monitor, user agent selection, JavaScript console and other basic web dev tools.
2.) Download Drosera. The download instructions for Safari 3.1/3.0 have you download a version of WebKit, but you don't need to install it. Just install the version of Drosera that comes in the DMG. You'll also need to enter the command to enable WebKit script debugging (provided in the link), restart Safari and you're ready to go.
I think FireBug still beats the Web Inspector/Drosera combo in a few areas (e.g. I'm not sure if you can dynamically alter CSS like you can in FireBug) but these tools get you most of what you're accustomed to in FireBug.
People like myself who design software requiring a database usually prefer speed over features.
Then the choice is easy. PostgreSQL is faster than MySQL, especially for highly concurrent workloads. PostgreSQL 8.3 increases the performance gap considerably.
First, you assume that your scaling strategy will work. If the plan is to distribute databases across multiple servers but you're performing a lot of cross-database joins, then you may very well decrease overall throughput due to the inter-server network traffic that was perviously handled in-process on a single server (plus, you may require distributed transactions, which will exacerbate performance problems and increase system-wide complexity and fragility). Remember that at one time a lot of developers thought they were "planning for scalability" by using distributed objects. We now know that the distribution of processes that need to communicate with each other in a fine-grained manner usually results in a performance bottleneck rather than in increased scalability.
Second, even though several other posters have already talked about this, I think PostgreSQL's definition of "database" and "schema" still seem incorrect or odd to you. From PostgreSQL's point of view, any two tables that are related to each other are, by definition, in the same database. This is not some weird idea from the minds of PG developers or a limitation in the sense of an overlooked feature-- it's a strict and useful interpretation of relational database theory. It forces you to clearly define your data domains and prevents coupling between them. Since PostgreSQL databases are truly separate entities with no interdependencies, you can safely and easily move them to different servers when and if the need arises. That's why all databases under the control of a single PostreSQL server instance are called a "database cluster" and not just a "database".
If you accept PostgreSQL's (and I would argue relational theory's) premise that any two tables with a relationship are part of the same logical database, then the question becomes "is your data model designed correctly?" If yes, then PostgreSQL's schema mechanism provides a clean and flexible solution for application-specific data models in separate namespaces that can cooperate in queries and transactions. However, it sounds like what you really have is a series of completely independent application-specific data models that need to share only a set of user accounts and authentication/authorization logic (i.e. single sign-on). If this is the case, IMO you would be better served by encapsulating that user data and logic into a single, shared application with a well-defined API (e.g. via lightweight web services or just a common library included in your other apps). This would provide all the normal benefits of encapsulation, reuse and decoupling (e.g. you could add/evolve user management features without affecting your other apps).
Don't get me wrong -- I'm not saying that you should design your applications or data models around whatever set of features happen to be available in a given RDBMS. Rather, I'm trying to demonstrate why this "limitation" in PostgreSQL exists and how it helps you to avoid a mishmash of interdependent data models.
A few words on database scalability in general: due to the need for atomic transactions and the disadvantages of distributed transactions and clustering (e.g. less performance / more complexity), the tried and true "vertical" approach to scaling database throughput is still often the best choice. Compared to separate but interdependent database servers, a single, powerful server can provide higher overall throughput (due to better resource utilization), is easier to maintain, often more cost effective and more fault-tolerant. And before someone cries "single point of failure" let me point out that spreading databases out on multiple servers only creates more single points of failure (with a higher combined failure rate than a single server) and that it's much easier to achieve database HA by adding a hot standby for your main DB server than it is to create a true multi-master HA cluster where any node can be removed at any time.
Just have to add a "me too". The OP is doing something bizarre, using a crappy plugin or has a hardware problem. Eclipse simply does not crash and/or corrupt workspaces like that (at least for every Eclipse user except the OP). It wouldn't be very popular if it deleted your code on a regular basis...
I'm saying that the article's claim was completely unjustified in the article. When they use sensationalist headlines and poor reasoning, it does damage to the credible evidence out there.
The article's claim is unjustified only from your extremist point of view. The fact is that the Northwest Passage has indeed been closed for all of recorded history and now it is open, which is all the article and its headline claim. Is it possible that the Northwest Passage actually was open at some point in the last 400 years? Sure, just as it's possible that U.S. astronauts never actually reached the moon. However, it's not all *probable* that the passage was open because knowledgeable explorers (i.e. people that were smart enough to search at opportune times when the ice was likely to be at its lowest point) looked for it on a fairly constant basis.
All available evidence and historical data point to the passage having been closed continually for at least 400 years (and, by extrapolation, probably thousands of years). On the other hand, there is *no* data to support your skepticism but, for some strange reason, you believe that the article should cater to your completely unsubstantiated opinion. Your opinion is unjustified and sensational. The article is merely mainstream.
If you have some evidence that the Northwest Passage was previously open, we would all love to hear it. Until then, there is nothing at all controversial in the article. Your opinion of it says quite a bit about your mindset, but nothing about the facts of climate change.
Given my comment, I think the modification of your quote and my intent in doing it was obvious, so I'll politely disregard your request.
Furthermore, the word "cult" has a widely agreed upon, and therefore quite useful, meaning when applied to a group like Scientology. Here is the definition that applies in this context:
cult
A relatively small group of people having religious beliefs or practices regarded by others as strange or sinister: a network of Satan-worshiping cults.
Contrary to your claim, most any two people do, in fact, mean the same thing when using the word "cult". They may disagree on the group(s) to which it applies, but they intend to label the target of that word with the same or very similar negative connotations. By definition, it does not simply refer to a "small religion", and I vehemently object to the term "religion" being used to describe scientology as there is a clear, observable distinction between groups commonly accepted as religions and scientology. The most obvious differentiator being the requirement by scientology of payment for access to their "secret knowledge".
The word "cult" may eventually become so overloaded that it will indeed lose its usefulness, but I don't believe we've reached that point yet.
Absolutely, you win the prize. However, that's not a "perfect" example -- that's about the *only* example. Obviously, if the use of a debugger masks a bug you have to find another way to track it down.
I assume you didn't start out with printf's because the debugger provides you with more power, flexibility and ease of use compared to hard-coded debug statements. Plus, the debugger doesn't leave you with a bunch of scattered printf's that you have to clean up afterwards. You're not arguing that because of that one, rare edge case, you've now sworn off the use of a debugger in favor of hard-coded printf's or logging (at least I don't pick that up from your comments). You also didn't try to imply that using hard-coded printf's was something to brag about -- only that is was necessary in this case.
My point was simply that a debugger is a better debugging tool than printf's or logging and, if you choose not to use one, it's not something to be proud of and it doesn't make you a better programmer. You haven't said anything to argue against that. I issued the "give me even one instance..." challenge to prove that the OP didn't have any actual rationale behind his statements and implications. Based on the personal insult you started off with, I can only guess that you mistook my tone for an argument that I was not trying to make.
I have absolutely no bias against people using a debugger. Where did you get that idea? I just said I rarely used one in my J2EE projects, so rarely that I don't even remember where it is in the menus. I jokingly stated "Real programmer don't use debuggers" as some kind of bragging, I could admit that.
By stating that not using a debugger is something to brag about (which you admit to above), you clearly imply that programmers who do use debuggers are somehow inferior to you. So I got the idea that you have a bias against people who use debuggers from your stated bias against the use of debuggers.
My point, put as simply as possible, is that choosing to be ignorant of the powerful tools available to you (a debugger among them) is something to be laughed at -- not bragged about.
To make you happy, should I start using one and post back here telling you how great it is ?
No, it would be enough if you stopped trying to spread the ridiculous myth that the use of a debugger is, in some unspecified way, linked to inferior programming abilities.
Am I automatically an idiot because I do not use a debugger ?
Yes, absolutely, assuming that you've ever had to debug something. It's no different than insisting on using vi instead of an IDE because of some misguided, ultimately self-limiting belief that "really good" programmers don't use certain kinds of tools even when those tools offer tremendous advantages.
Do you want to force me to use a debugger so you may then respect me ?
No, but I feel compelled to respond to your suggestion that programmers who do use debuggers are inferior to you. A younger programmer reading this might otherwise get the idea that you are right.
I won't ask you if you are jealous because I get away without a debugger given your former replies;-)
So there it is again. Another clear suggestion that one should be jealous of you because you deny yourself the use of a debugger. It doesn't matter how many different ways you say it, it still makes no sense.
About my experience with debugging big and complex projects, I won't go there but I will give you a hint, look at the source code.
So you "won't go there" but then you immediately proceed to go there but somehow fail to back it up with anything. What source code are you talking about? I don't see anything. Does this source code you speak of exist only in your mind? That would explain your strange attitude toward debuggers...
Take care and don't get all excited so easily;-))
Maybe if you add a few more smiley faces I'll forget that you still haven't responded to my initial, simple challenge: please point out even one instance where using a "debug statement" is a better choice than using a debugger. And feel free to turn that around. Rather than simply implying your superiority through the eschewal of a debugger, please actually explain why a debugger is in any way harmful or inferior to your awesome debug statements.
OK, so the article is pointing out that Eclipse's debug perspective is easier to use and more flexible than Visual Studio's debug mode. That sounds about right to me.
In case you're still under the impression that Eclipse doesn't have a debugger, I'll you save the effort of actually using Eclipse and mention that it's built into the IDE, allows for effortless remote as well as local debugging, has all the features you would expect from a debugger and is incredibly well integrated. So well integrated, in fact, that you don't have to "switch modes" to use it.
This deserves a higher rating than 3. I don't entirely agree with "unlimited liability", but you addressed the most obvious concern in a simple, logical way. There are other options as well, but they all boil down to incentivizing good behavior (which is not a new or strange concept -- just not applied to corporations nearly as rigorously as it is to individuals under US law).
I enjoyed your rambling, self-aggrandizing version of "no, I can't give you even one reason why hard-coded debug statements are better than using a debugger." It was also nice how you worked in as much "old-school programmer street cred" as possible. It really impressed me.
It doesn't take very long to learn how to use a debugger. Learning to code properly takes considerably longer.
That's precisely why it is incredibly stupid to avoid using a debugger. Learning and using a debugger doesn't take away from design and programming time and it can help you to learn what your code is actually doing. In other words, a debugger can help you to learn to code properly. Why you see these as opposing rather than complimentary activities remains a mystery.
If being able to switch debug on the fly on a remote server is so important to you. Is that because you debug your programs while they are in production ?
Hahaha! Love the crudely veiled insult there. Here's a somewhat less veiled insult for you: if you have never experienced a bug that manifests itself in a production or staging environment but not in development than either you haven't been programming for very long or have only written the most trivial of applications. Remote debugging is an invaluable tool in certain situations and only a fool would deny themselves its abilities.
Note that, as another poster mentioned, it is perfectly feasible with log4j as well.
Shockingly, I use both logging and a debugger! That's because a logging API and a debugger are two different things with different strengths and purposes. If you're trying to use your logging API as a debugger, you're simply making troubleshooting much more difficult than it needs to be, and for absolutely no good reason.
Let me know when you come up something that at least resembles a rationale for your bizarre bias against using a debugger for Java. Until then, I'll take you at face value and assume that it's a manifestation of your lack of confidence in your manhood -- or something like that.
So, according to your description, your post was "targeted spam" because it was not indiscriminate.
Please silently ignore messages which you think are spam next time, as is the custom.
If I could reply to spammers who send me email and know that they would read that reply, you bet your ass I would reply to each and every one of them. Thus my reply to you.
It will fall on mostly deaf ears hear in Slashdot-land, where I expect most people who give a crap about Eclipse one way or the other will be of the uber-geek type who LOVE it.
If, by "uber-geek type", you mean "not retarded" then you are correct.
Please send your spam via email next time, as is the custom.
There is no diffinitive "this is eclipse, click here to download"
You mean something like the huge yellow button at the top of their home page that says "Download Eclipse" and then takes you to a download page that displays and explains the available versions (and automatically filters them for your particular OS)?
I've tried it, but I went back to Eclipse as soon as I found out it doesn't have an incremental compiler. It's more accurate to say that NetBeans is "rapidly catching up with, and in some areas surpasses, Eclipse." Having never used VS.Net, I can't comment on it.
Um, Eclipse does not "fall into debugging mode". You have to intentionally start your app in debug mode.
Of course, I realize that this is my old way to view things
Age has nothing to do with it. Your "way to view things" is simply wrong. Please demonstrate even one way in which manually added "debug statements" are superior to using Eclipse's debugger.
Here are just a few reasons why the debugger is better:
No redeploy of the app is necessary to debug it.
Debugging may performed on a remote server (again, without redeployment).
You may add as many "debugging statements" as you need, at any time, and you can modify them at will.
You may step through particularly complex code one line at a time, choosing whether or not to step into methods along the way.
If the problem is that you simply haven't taken the time to learn how to use a debugger, please don't try to pass your ignorance off as some kind of "old-timey" virtue.
I really can't believe that someone actually tried to argue that Java's built-in date handling is better than.NET's. Unbelievable. On behalf of every Java programmer who's had the misfortune of actually using Calendar and the other horrid date-related classes in the JDK, I have to apologize for Abcd1234's silliness. If Calendar and the like were anything but pathetic mistakes, there would be some debate about entirely replacing them with Joda-Time. Instead, it's one of the few "no-brainer, better late than never" changes in Java 7 that nobody (to my knowledge) seriously argues against.
Any mention of the old "date handling is pathetic" complaint about Java has to be answered by pointing out Joda-Time, which will become the standard date and time library starting with Java 7. And yes, it's better (cleaner API, more functionality, etc.) than the.NET equivalent.
I don't think Joda-Time was available 4+ years ago, so I feel your pain if you had to do a lot of date/time manipulation with Calendar and all that crap. Luckily, Joda-Time became more or less a de facto standard soon after it was released so -- unless you're in an environment that prohibits 3rd party libraries -- Java has had better date handling than just about any other language/platform for a number of years now.
And trust me, I'm just as frustrated and confused by people who adore Wicket and say it has a great power/conceptual weight ratio!
Fair enough, but that describes the vast majority of Wicket users. It's not like people who "adore" Wicket are some kind of anomaly. I would say that it has a "good" power/conceptual weight ratio. It's more compelling advantage, imo, is the excellent maintainability achieved by defining all logic, including presentation logic, in Java code and keeping the HTML and JavaScript complexity to a minimum (or at least encapsulating it in reusable Java classes).
there are still a lot of problems where we have to figure out "ok, the javascript is fairly easy, but what's the Wicket way to do this"?
Not that Wicket doesn't have it's own concepts that one must learn, but when one of the devs on my team asks that kind of question, I usually say "how would you do if you were just writing Java code and not using a web framework?" and that usually leads to the right answer.
One example was some sortable tagbles w/ selectable rows, preserving the selection across sorts and groupings. We got it, but it seemed less elegant than we would have liked.
At the risk of over-simplifying the problem you experienced, that sounds like the kind of situation we run into from time to time where someone is making a problem more complicated by looking for a "Wicket way" to do something instead of just treating it like any other Java code.
Assuming you were using the Check and CheckGroup components, the selected rows are stored in whatever collection you supplied as the CheckGroup's model. So, to preserve the selection you simply have to keep a reference to that collection (via an instance variable in your page or component), just like any state you would keep for any normal Java object. I think if you had posted this question on the user list you would have received a quick and concise answer and probably even a code example.
I probably do have a text-centric (thanks, Perl) outlook, but even to the extent I see "components", I see them as "DHTML components", and the mapping to Java objects seems forced.
You have to keep in mind that Wicket is, in large part, conceptually based on Swing. It tries to treat the web like a Java GUI rather than simply using Java to spit out HTML in the manner of PHP or Perl. Again, the Wicket documentation, code examples and API make that pretty clear so if you prefer a more text-centric, procedural approach then Wicket is probably not the best framework for you. I happen to think that most web frameworks (Java and non-Java alike) are backwards compared to Wicket's OO-centric, more GUI-like approach. Instead of complaining about them, I simply don't use them. If I was forced to use one, I would either "get over" my prejudice and try to master the framework or find another job.
Another problem with all this... Wicket is in desperate need of a few more teaching books and a really good recipe/cookbook.
Heh, well I can't disagree there. You're hardly the only person with a background in Perl, PHP or some other "close to the request cycle" web background who finds themselves wanting or having to learn Wicket. And it is definitely a big conceptual leap from a typical, non-OO web framework. Hopefully the forthcoming "Wicket in Action" book (written by Wicket devs) will address that issue.
When this complaint comes up on the mailing list, users are often pointed to the extensive code examples as a primary learning resource. Because almost everything you do in Wicket happens in plain Java code, the examples do teach beginners most of what they need to know, but advanced concepts could certainly use a more thorough treatment than what's found on the wiki.
Assuming that you can't switch web frameworks right now, you might change your mind about Wicket if
Slashdot Mirror
"Rings quite hollow" must be a euphemism for "I'm too lazy to look up any data to determine if this is actually true or not, so I'm going to talk about my feelings instead".
1.) Turn on the developer menu under advanced preferences. This gives you DOM and CSS inspection, network activity monitor, user agent selection, JavaScript console and other basic web dev tools.
2.) Download Drosera. The download instructions for Safari 3.1/3.0 have you download a version of WebKit, but you don't need to install it. Just install the version of Drosera that comes in the DMG. You'll also need to enter the command to enable WebKit script debugging (provided in the link), restart Safari and you're ready to go.
I think FireBug still beats the Web Inspector/Drosera combo in a few areas (e.g. I'm not sure if you can dynamically alter CSS like you can in FireBug) but these tools get you most of what you're accustomed to in FireBug.
Then the choice is easy. PostgreSQL is faster than MySQL, especially for highly concurrent workloads. PostgreSQL 8.3 increases the performance gap considerably.
PostgreSQL SPEC benchmark
PostgreSQL 8.2 vs MySQL 4.1 and 5.0
PostgreSQL vs MySQL 5.0 pages per second
PostgreSQL 8.2 vs 8.3
I suggest you bone up on PostgreSQL tuning (here's a handy configuration guide) and perform your own comparison.
Anyone else wondering when this "MySQL is faster" myth is finally going to die?
I think you're missing a few key points.
First, you assume that your scaling strategy will work. If the plan is to distribute databases across multiple servers but you're performing a lot of cross-database joins, then you may very well decrease overall throughput due to the inter-server network traffic that was perviously handled in-process on a single server (plus, you may require distributed transactions, which will exacerbate performance problems and increase system-wide complexity and fragility). Remember that at one time a lot of developers thought they were "planning for scalability" by using distributed objects. We now know that the distribution of processes that need to communicate with each other in a fine-grained manner usually results in a performance bottleneck rather than in increased scalability.
Second, even though several other posters have already talked about this, I think PostgreSQL's definition of "database" and "schema" still seem incorrect or odd to you. From PostgreSQL's point of view, any two tables that are related to each other are, by definition, in the same database. This is not some weird idea from the minds of PG developers or a limitation in the sense of an overlooked feature-- it's a strict and useful interpretation of relational database theory. It forces you to clearly define your data domains and prevents coupling between them. Since PostgreSQL databases are truly separate entities with no interdependencies, you can safely and easily move them to different servers when and if the need arises. That's why all databases under the control of a single PostreSQL server instance are called a "database cluster" and not just a "database".
If you accept PostgreSQL's (and I would argue relational theory's) premise that any two tables with a relationship are part of the same logical database, then the question becomes "is your data model designed correctly?" If yes, then PostgreSQL's schema mechanism provides a clean and flexible solution for application-specific data models in separate namespaces that can cooperate in queries and transactions. However, it sounds like what you really have is a series of completely independent application-specific data models that need to share only a set of user accounts and authentication/authorization logic (i.e. single sign-on). If this is the case, IMO you would be better served by encapsulating that user data and logic into a single, shared application with a well-defined API (e.g. via lightweight web services or just a common library included in your other apps). This would provide all the normal benefits of encapsulation, reuse and decoupling (e.g. you could add/evolve user management features without affecting your other apps).
Don't get me wrong -- I'm not saying that you should design your applications or data models around whatever set of features happen to be available in a given RDBMS. Rather, I'm trying to demonstrate why this "limitation" in PostgreSQL exists and how it helps you to avoid a mishmash of interdependent data models.
A few words on database scalability in general: due to the need for atomic transactions and the disadvantages of distributed transactions and clustering (e.g. less performance / more complexity), the tried and true "vertical" approach to scaling database throughput is still often the best choice. Compared to separate but interdependent database servers, a single, powerful server can provide higher overall throughput (due to better resource utilization), is easier to maintain, often more cost effective and more fault-tolerant. And before someone cries "single point of failure" let me point out that spreading databases out on multiple servers only creates more single points of failure (with a higher combined failure rate than a single server) and that it's much easier to achieve database HA by adding a hot standby for your main DB server than it is to create a true multi-master HA cluster where any node can be removed at any time.
In case Ant P.'s response was too vague, all firewalls are software firewalls. Otherwise they could never be updated, patched, etc.
Just have to add a "me too". The OP is doing something bizarre, using a crappy plugin or has a hardware problem. Eclipse simply does not crash and/or corrupt workspaces like that (at least for every Eclipse user except the OP). It wouldn't be very popular if it deleted your code on a regular basis...
The article's claim is unjustified only from your extremist point of view. The fact is that the Northwest Passage has indeed been closed for all of recorded history and now it is open, which is all the article and its headline claim. Is it possible that the Northwest Passage actually was open at some point in the last 400 years? Sure, just as it's possible that U.S. astronauts never actually reached the moon. However, it's not all *probable* that the passage was open because knowledgeable explorers (i.e. people that were smart enough to search at opportune times when the ice was likely to be at its lowest point) looked for it on a fairly constant basis.
All available evidence and historical data point to the passage having been closed continually for at least 400 years (and, by extrapolation, probably thousands of years). On the other hand, there is *no* data to support your skepticism but, for some strange reason, you believe that the article should cater to your completely unsubstantiated opinion. Your opinion is unjustified and sensational. The article is merely mainstream.
If you have some evidence that the Northwest Passage was previously open, we would all love to hear it. Until then, there is nothing at all controversial in the article. Your opinion of it says quite a bit about your mindset, but nothing about the facts of climate change.
That's OK, they don't like you either. On top of that, they don't even think you look nice.
Given my comment, I think the modification of your quote and my intent in doing it was obvious, so I'll politely disregard your request.
Furthermore, the word "cult" has a widely agreed upon, and therefore quite useful, meaning when applied to a group like Scientology. Here is the definition that applies in this context:
cult
A relatively small group of people having religious beliefs or practices regarded by others as strange or sinister: a network of Satan-worshiping cults.
Contrary to your claim, most any two people do, in fact, mean the same thing when using the word "cult". They may disagree on the group(s) to which it applies, but they intend to label the target of that word with the same or very similar negative connotations. By definition, it does not simply refer to a "small religion", and I vehemently object to the term "religion" being used to describe scientology as there is a clear, observable distinction between groups commonly accepted as religions and scientology. The most obvious differentiator being the requirement by scientology of payment for access to their "secret knowledge".
The word "cult" may eventually become so overloaded that it will indeed lose its usefulness, but I don't believe we've reached that point yet.
Absolutely, you win the prize. However, that's not a "perfect" example -- that's about the *only* example. Obviously, if the use of a debugger masks a bug you have to find another way to track it down.
I assume you didn't start out with printf's because the debugger provides you with more power, flexibility and ease of use compared to hard-coded debug statements. Plus, the debugger doesn't leave you with a bunch of scattered printf's that you have to clean up afterwards. You're not arguing that because of that one, rare edge case, you've now sworn off the use of a debugger in favor of hard-coded printf's or logging (at least I don't pick that up from your comments). You also didn't try to imply that using hard-coded printf's was something to brag about -- only that is was necessary in this case.
My point was simply that a debugger is a better debugging tool than printf's or logging and, if you choose not to use one, it's not something to be proud of and it doesn't make you a better programmer. You haven't said anything to argue against that. I issued the "give me even one instance..." challenge to prove that the OP didn't have any actual rationale behind his statements and implications. Based on the personal insult you started off with, I can only guess that you mistook my tone for an argument that I was not trying to make.
By stating that not using a debugger is something to brag about (which you admit to above), you clearly imply that programmers who do use debuggers are somehow inferior to you. So I got the idea that you have a bias against people who use debuggers from your stated bias against the use of debuggers.
My point, put as simply as possible, is that choosing to be ignorant of the powerful tools available to you (a debugger among them) is something to be laughed at -- not bragged about.
No, it would be enough if you stopped trying to spread the ridiculous myth that the use of a debugger is, in some unspecified way, linked to inferior programming abilities.
Yes, absolutely, assuming that you've ever had to debug something. It's no different than insisting on using vi instead of an IDE because of some misguided, ultimately self-limiting belief that "really good" programmers don't use certain kinds of tools even when those tools offer tremendous advantages.
No, but I feel compelled to respond to your suggestion that programmers who do use debuggers are inferior to you. A younger programmer reading this might otherwise get the idea that you are right.
So there it is again. Another clear suggestion that one should be jealous of you because you deny yourself the use of a debugger. It doesn't matter how many different ways you say it, it still makes no sense.
So you "won't go there" but then you immediately proceed to go there but somehow fail to back it up with anything. What source code are you talking about? I don't see anything. Does this source code you speak of exist only in your mind? That would explain your strange attitude toward debuggers...
Maybe if you add a few more smiley faces I'll forget that you still haven't responded to my initial, simple challenge: please point out even one instance where using a "debug statement" is a better choice than using a debugger. And feel free to turn that around. Rather than simply implying your superiority through the eschewal of a debugger, please actually explain why a debugger is in any way harmful or inferior to your awesome debug statements.
OK, so the article is pointing out that Eclipse's debug perspective is easier to use and more flexible than Visual Studio's debug mode. That sounds about right to me.
In case you're still under the impression that Eclipse doesn't have a debugger, I'll you save the effort of actually using Eclipse and mention that it's built into the IDE, allows for effortless remote as well as local debugging, has all the features you would expect from a debugger and is incredibly well integrated. So well integrated, in fact, that you don't have to "switch modes" to use it.This deserves a higher rating than 3. I don't entirely agree with "unlimited liability", but you addressed the most obvious concern in a simple, logical way. There are other options as well, but they all boil down to incentivizing good behavior (which is not a new or strange concept -- just not applied to corporations nearly as rigorously as it is to individuals under US law).
I enjoyed your rambling, self-aggrandizing version of "no, I can't give you even one reason why hard-coded debug statements are better than using a debugger." It was also nice how you worked in as much "old-school programmer street cred" as possible. It really impressed me.
That's precisely why it is incredibly stupid to avoid using a debugger. Learning and using a debugger doesn't take away from design and programming time and it can help you to learn what your code is actually doing. In other words, a debugger can help you to learn to code properly. Why you see these as opposing rather than complimentary activities remains a mystery.Hahaha! Love the crudely veiled insult there. Here's a somewhat less veiled insult for you: if you have never experienced a bug that manifests itself in a production or staging environment but not in development than either you haven't been programming for very long or have only written the most trivial of applications. Remote debugging is an invaluable tool in certain situations and only a fool would deny themselves its abilities.
Shockingly, I use both logging and a debugger! That's because a logging API and a debugger are two different things with different strengths and purposes. If you're trying to use your logging API as a debugger, you're simply making troubleshooting much more difficult than it needs to be, and for absolutely no good reason.
Let me know when you come up something that at least resembles a rationale for your bizarre bias against using a debugger for Java. Until then, I'll take you at face value and assume that it's a manifestation of your lack of confidence in your manhood -- or something like that.
Please send your spam via email next time, as is the custom.
Are you implying that Eclipse doesn't have a debugger? Or that Visual Studio's debugger is better than Eclipse's? If so, how?
I've tried it, but I went back to Eclipse as soon as I found out it doesn't have an incremental compiler. It's more accurate to say that NetBeans is "rapidly catching up with, and in some areas surpasses, Eclipse." Having never used VS.Net, I can't comment on it.
Um, Eclipse does not "fall into debugging mode". You have to intentionally start your app in debug mode.
Age has nothing to do with it. Your "way to view things" is simply wrong. Please demonstrate even one way in which manually added "debug statements" are superior to using Eclipse's debugger.
Here are just a few reasons why the debugger is better:
If the problem is that you simply haven't taken the time to learn how to use a debugger, please don't try to pass your ignorance off as some kind of "old-timey" virtue.
I really can't believe that someone actually tried to argue that Java's built-in date handling is better than .NET's. Unbelievable. On behalf of every Java programmer who's had the misfortune of actually using Calendar and the other horrid date-related classes in the JDK, I have to apologize for Abcd1234's silliness. If Calendar and the like were anything but pathetic mistakes, there would be some debate about entirely replacing them with Joda-Time. Instead, it's one of the few "no-brainer, better late than never" changes in Java 7 that nobody (to my knowledge) seriously argues against.
Any mention of the old "date handling is pathetic" complaint about Java has to be answered by pointing out Joda-Time, which will become the standard date and time library starting with Java 7. And yes, it's better (cleaner API, more functionality, etc.) than the .NET equivalent.
I don't think Joda-Time was available 4+ years ago, so I feel your pain if you had to do a lot of date/time manipulation with Calendar and all that crap. Luckily, Joda-Time became more or less a de facto standard soon after it was released so -- unless you're in an environment that prohibits 3rd party libraries -- Java has had better date handling than just about any other language/platform for a number of years now.
Fair enough, but that describes the vast majority of Wicket users. It's not like people who "adore" Wicket are some kind of anomaly. I would say that it has a "good" power/conceptual weight ratio. It's more compelling advantage, imo, is the excellent maintainability achieved by defining all logic, including presentation logic, in Java code and keeping the HTML and JavaScript complexity to a minimum (or at least encapsulating it in reusable Java classes).
Not that Wicket doesn't have it's own concepts that one must learn, but when one of the devs on my team asks that kind of question, I usually say "how would you do if you were just writing Java code and not using a web framework?" and that usually leads to the right answer.
At the risk of over-simplifying the problem you experienced, that sounds like the kind of situation we run into from time to time where someone is making a problem more complicated by looking for a "Wicket way" to do something instead of just treating it like any other Java code.
Assuming you were using the Check and CheckGroup components, the selected rows are stored in whatever collection you supplied as the CheckGroup's model. So, to preserve the selection you simply have to keep a reference to that collection (via an instance variable in your page or component), just like any state you would keep for any normal Java object. I think if you had posted this question on the user list you would have received a quick and concise answer and probably even a code example.
You have to keep in mind that Wicket is, in large part, conceptually based on Swing. It tries to treat the web like a Java GUI rather than simply using Java to spit out HTML in the manner of PHP or Perl. Again, the Wicket documentation, code examples and API make that pretty clear so if you prefer a more text-centric, procedural approach then Wicket is probably not the best framework for you. I happen to think that most web frameworks (Java and non-Java alike) are backwards compared to Wicket's OO-centric, more GUI-like approach. Instead of complaining about them, I simply don't use them. If I was forced to use one, I would either "get over" my prejudice and try to master the framework or find another job.
Heh, well I can't disagree there. You're hardly the only person with a background in Perl, PHP or some other "close to the request cycle" web background who finds themselves wanting or having to learn Wicket. And it is definitely a big conceptual leap from a typical, non-OO web framework. Hopefully the forthcoming "Wicket in Action" book (written by Wicket devs) will address that issue.
When this complaint comes up on the mailing list, users are often pointed to the extensive code examples as a primary learning resource. Because almost everything you do in Wicket happens in plain Java code, the examples do teach beginners most of what they need to know, but advanced concepts could certainly use a more thorough treatment than what's found on the wiki.
Assuming that you can't switch web frameworks right now, you might change your mind about Wicket if