jQuery is very well thought-out
on
jQuery in Action
·
· Score: 5, Interesting
My first attempt to teach myself jQuery with a real-world example was a screaming success. I had to fix a huge page in 3 major sections that confused and frustrated users. (Couldn't be helped. Management decision.) In less than an hour, I vastly simplified the page using only one line of jQuery code for each section. I repeat, only one line of code for each section.
With that experience, I became not just a convert, but a jQuery software evangelist at the Federal Government agency where I work.
The next intractable problem that jQuery solved here was the old mouseover/mouseout problems with DHTML menus (that sometimes stayed open in some browsers). jQuery's ability to simulate one-event-only mouseenter/mouseleave in all modern browsers solved that problem in only one line of code too. I haven't seen our shared DHTML help menu stay open ever since.
The ability to bind multiple event handlers to the exact same event is really going to help us refactor and stratify our data validation JS. Everything's getting better and faster and simpler, all at the same time.
My biggest complaint has been the lack of books explaining the IDEA of how jQuery works. I've had to survive largely by reading the jQuery source code. I bought this book (the one reviewed above), plus Learning jQuery and jQuery Reference Guide, and not one of them has adequately explained how the animation queue works. I believe that I now understand the animation queue better than the authors of those 3 books do. Or better than their ability to explain, at least.
What I'm saying is, this book and the other 2 constitute a good first wave of jQuery books, but they don't do justice to this marvelously well thought-out JavaScript Object.
Java Concurrency in Practice was written by the authors of the java.util.concurrent package. It's an excellent introduction to the problems of concurrency and explains how java.util.concurrent deals with those problems.
Fair warning: It's written using a lot of the Generics syntax, which may steepen the learning curve if you're not used to Generics.
total = 0;
for (i = 0; i
total += NumberOfDays[i];
COBOL:
MOVE 0 TO Total.
PERFORM VARYING i FROM 1 BY 1 UNTIL i > 12
ADD NumberOfDays(i) TO Total
END-PERFORM.
This illustrates that C arrays are 0-based and COBOL arrays are 1-based.
It also illustrates that COBOL, while wordier, is self-documenting, at least in the sense that a non-programmer can pick it up and read it.
However wordy the language is, the generated code from COBOL is generally quite good. I have code in 5 different assembly languages, so I'm not scared to look at generated code. I've seen some amazing code optimizations in COBOL. For example, in bulk moves of memory to memory, I've seen registers used cleverly to save only 2 instruction cycles, with no loss of compactness. I attribute this to the fact that benchmarks are used to win procurements, so mainframe manufacturers want to be sure their generated code runs faster than their rivals' generated code.
That said, COBOL was developed at a time when computer memory was insanely expensive. Programs had to fit into very tiny address spaces. Much of the restrictions of the language, particularly buffered I/O, existed because you couldn't fit much of a file into memory as the program read through it.
As for why it's hated, the less you know about something, the easier it is to criticize. I'm sure most of the haters in this thread don't know how to read assembly language, let alone how to write it. So if they hear someone say "COBOL generates inefficient code", they believe it and repeat it. They have no way to confirm or deny the assertion.
You made no mention of what your hardware was, nor even whether or not you had a video camera.
A few years ago, I bought some DLink webcams to set up a custom home video surveillance system, with remote monitoring from work. I believe that the model number was DCS-5300. But since they're mounted on-high, I'd rather not climb up on a ladder to find out for sure.
For bandwidth and security reasons, I chose to get the 10/100Base-T versions, not wireless. The wired versions were also cheaper. You're going to have to run power cords to the wherever you mount them anyway, so why not an Ethernet wires at the same time?
They're designed to be always on (for home surveillance), as you indicated you wanted, 24/7. I don't even remember if they have an on/off switch. They draw considerably less power than a computer and webcam combination.
They came with their own Web server and have their own IP addresses on my home LAN. Of course, they're configurable with a Web page interface.
You wanted using the system to be a no-brainer, presumably to help out your less-than-techno-savvy kids and parents. You can't get any more simple than these webcams. You just browse to them with any Web browser. You can set the browsers up with Bookmarks/Favorites to make getting there simple.
The cams serve up a Web page with the camera feed on it. If you've configured them for permission to control the camera, the page will also have controls to pan, tilt and zoom.
If you use a broadband router as a firewall, you'll have to configure the router to expose the cam's server port to the Internet. If you're concerned about the security of doing that, note that the Web server software resides on a chip. It doesn't have a disk drive. It isn't even big enough to contain a disk drive. It's as secure as the Web server that comes built into most broadband routers these days.
As I said, I bought them years ago. There are bound to be other brands by now besides DLink that do the same things, if you want to shop around.
10-4 on the importance of monitoring disk I/O.
At my site, we call log4j to log the elapsed time of every I/O at the INFO level, regardless of whether it's generated SQL or stored procedures of SQL that never changes. The overhead of no-op calls to log4j is on the order of microseconds when log4j is turned off, so there's really no reason not to.
One unanticipated benefit is that we can turn on logging when an application crashes and look at the logs to see how far it got before it crashed. This points us to the vicinity of where the error occurred.
Of course, we also log the elapsed time to generate every Web page to detect poorly written code.
Slashdot Mirror
My first attempt to teach myself jQuery with a real-world example was a screaming success. I had to fix a huge page in 3 major sections that confused and frustrated users. (Couldn't be helped. Management decision.) In less than an hour, I vastly simplified the page using only one line of jQuery code for each section. I repeat, only one line of code for each section.
With that experience, I became not just a convert, but a jQuery software evangelist at the Federal Government agency where I work.
The next intractable problem that jQuery solved here was the old mouseover/mouseout problems with DHTML menus (that sometimes stayed open in some browsers). jQuery's ability to simulate one-event-only mouseenter/mouseleave in all modern browsers solved that problem in only one line of code too. I haven't seen our shared DHTML help menu stay open ever since.
The ability to bind multiple event handlers to the exact same event is really going to help us refactor and stratify our data validation JS. Everything's getting better and faster and simpler, all at the same time.
My biggest complaint has been the lack of books explaining the IDEA of how jQuery works. I've had to survive largely by reading the jQuery source code. I bought this book (the one reviewed above), plus Learning jQuery and jQuery Reference Guide, and not one of them has adequately explained how the animation queue works. I believe that I now understand the animation queue better than the authors of those 3 books do. Or better than their ability to explain, at least.
What I'm saying is, this book and the other 2 constitute a good first wave of jQuery books, but they don't do justice to this marvelously well thought-out JavaScript Object.
Java Concurrency in Practice was written by the authors of the java.util.concurrent package. It's an excellent introduction to the problems of concurrency and explains how java.util.concurrent deals with those problems.
Fair warning: It's written using a lot of the Generics syntax, which may steepen the learning curve if you're not used to Generics.
... and my 'for' statement got corrupted by the less-than. To save you from having to do a View Source, it said:
for (i = 0; i < 12; i++)
... er, I should have said, I have CODED ....
COBOL:
This illustrates that C arrays are 0-based and COBOL arrays are 1-based.
It also illustrates that COBOL, while wordier, is self-documenting, at least in the sense that a non-programmer can pick it up and read it.
However wordy the language is, the generated code from COBOL is generally quite good. I have code in 5 different assembly languages, so I'm not scared to look at generated code. I've seen some amazing code optimizations in COBOL. For example, in bulk moves of memory to memory, I've seen registers used cleverly to save only 2 instruction cycles, with no loss of compactness. I attribute this to the fact that benchmarks are used to win procurements, so mainframe manufacturers want to be sure their generated code runs faster than their rivals' generated code.
That said, COBOL was developed at a time when computer memory was insanely expensive. Programs had to fit into very tiny address spaces. Much of the restrictions of the language, particularly buffered I/O, existed because you couldn't fit much of a file into memory as the program read through it.
As for why it's hated, the less you know about something, the easier it is to criticize. I'm sure most of the haters in this thread don't know how to read assembly language, let alone how to write it. So if they hear someone say "COBOL generates inefficient code", they believe it and repeat it. They have no way to confirm or deny the assertion.
You made no mention of what your hardware was, nor even whether or not you had a video camera.
A few years ago, I bought some DLink webcams to set up a custom home video surveillance system, with remote monitoring from work. I believe that the model number was DCS-5300. But since they're mounted on-high, I'd rather not climb up on a ladder to find out for sure.
For bandwidth and security reasons, I chose to get the 10/100Base-T versions, not wireless. The wired versions were also cheaper. You're going to have to run power cords to the wherever you mount them anyway, so why not an Ethernet wires at the same time?
They're designed to be always on (for home surveillance), as you indicated you wanted, 24/7. I don't even remember if they have an on/off switch. They draw considerably less power than a computer and webcam combination.
They came with their own Web server and have their own IP addresses on my home LAN. Of course, they're configurable with a Web page interface.
You wanted using the system to be a no-brainer, presumably to help out your less-than-techno-savvy kids and parents. You can't get any more simple than these webcams. You just browse to them with any Web browser. You can set the browsers up with Bookmarks/Favorites to make getting there simple.
The cams serve up a Web page with the camera feed on it. If you've configured them for permission to control the camera, the page will also have controls to pan, tilt and zoom.
If you use a broadband router as a firewall, you'll have to configure the router to expose the cam's server port to the Internet. If you're concerned about the security of doing that, note that the Web server software resides on a chip. It doesn't have a disk drive. It isn't even big enough to contain a disk drive. It's as secure as the Web server that comes built into most broadband routers these days.
As I said, I bought them years ago. There are bound to be other brands by now besides DLink that do the same things, if you want to shop around.
10-4 on the importance of monitoring disk I/O. At my site, we call log4j to log the elapsed time of every I/O at the INFO level, regardless of whether it's generated SQL or stored procedures of SQL that never changes. The overhead of no-op calls to log4j is on the order of microseconds when log4j is turned off, so there's really no reason not to. One unanticipated benefit is that we can turn on logging when an application crashes and look at the logs to see how far it got before it crashed. This points us to the vicinity of where the error occurred. Of course, we also log the elapsed time to generate every Web page to detect poorly written code.