Electronic DIY books?

[Shay]

Can anyone recommend any idiot guides to electronics and electrics etc?

[RichardKB]

http://books.google.co.uk/books?id=bkOMDgwFA28C&dq=the+art+of+electronics&pg=PP1&ots=F2aiYEc0Uu&sig=Y7Z_dmcLhomE2CEmi0U0XyKUaSA&hl=en&sa=X&oi=book_result&resnum=4&ct=result

Rich

[WeeVic]

I remember buying the book some time ago it`s expensive!

For cheap kits tomake try  maplin or velleman kits

I made a dusk to dawn switch recently and anyone could make it!

Sometimes the kits are better buying than all the components. Saves you a lot of money.

[cornishben]

Can anyone recommend any idiot guides to electronics and electrics etc?

slightly off topic as not a general electronics book, but this seems a good thread to highlight it in -  if you're interested in any of the data logging/controlling/microcontrollers/arduinos/etc discussed in other threads then I can highly recommend this book >>
http://www.amazon.co.uk/Making-Things-Talk-Practical-Connecting/dp/0596510519
all about getting m/c's talking to PC's and to the net etc.  mostly software i guess but some basic electronics as well

[kristen]

If buying a paper book you might like to try www.BookBrain.co.uk - it provides a list of suppliers, and prices, helping to get a good price.

[djh]

www.BookBrain.co.uk

Seems to be another brain-dead site that can't even submit a form without javascript enabled.  They're breeding like flies at the moment   

[kristen]

So enable Javascript to use the site?  Why's that so bad?

[wyleu]

It's getting harder and harder to write sites to client specifications without reverting to some form of client side scripting and Javascript is the first choice really.

[kristen]

Is there some risk with Javascript?  I was under the impression that it was insulated from the local machine (or if it needs access to local machine then permissions have to be explicitly granted).  I think client-side validation that removes the need for a (failed) round trip is a good thing, plus things like "If you enter X in Field 1 then fields 2,3,4 should be made inactive ..." which I don't suppose can be done with CSS

[wyleu]

Generally pretty safe as long as the interpreter in the browser is safe.

But, of course, the more you rattle the doors the more likely you are to get in.

[wookey]

The main risk is cross-site scripting. http://lwn.net/Articles/266303/ is a good explanation of the risks. There are plenty of ways that javascript can install malware on your box (via other vulnerabilities)

It's smart to keep it turned off and only turn it on when you need to, but as djh observes that's getting to be a real pain these days. Increasing numbers of sites don't even have menus that work without JS. I use noscript with Firefox/epiphany/iceweasel which lets you selectively enable it for specific sites, and that way you can tell when there is cross-site stuff going on. It's a good compromise between complete exposure and having much of the web not work.

[djh]

As well as cross-site scripting, there's also cross-site request forgery. Look up XSS and CSRF on Wikipedia. And who knows what other possible exploits there may be? Javascript is an interesting language but it has some unusual concepts and so is extremely prone to programmer error.

So that's sufficient reason for me to run with noscript. It also has the nice side-effect that it stops a lot of advertising and .swf fluff by default, so it makes browsing nicer in that way. Of course, it means that I never see the adverts of advertisers who use javascript or flash, so they wasted their money.

It does make it irritating to navigate sites that use it unnecessarily. That form is just a single box. There's no need for javascript! And for the main irritation, it's possible to write perfectly good menus/navigation without javascript, so why do it?

I have a couple of rules of thumb. If there are alternative sites, as there are for locating books, I just use them and don't use the one with javascript. If I need to use the site but think the javascript is unwarranted, I have a standard email that I send to the marketing dept suggesting they think again.

There's another problem as well - accessibility. While it is possible to write sites with javascript that work without a mouse, or via a screen reader, it's also very easy to write ones that don't! That's really bad IMHO and in some cases will be illegal.

Client-side validation is another two-edged sword. Done right, it can enhance the user experience in some cases. But all too often it's simplified and doesn't match the actual requirement enforced on the server. It leads to things like credit card fields that don't allow spaces in the number, sort-code fields that don't allow hyphens, form fields that don't remember what was previously in them etc etc

All JMHO, of course. Dave

[kristen]

"so why do it"

In the case if Bookbrain I assume it is because they are using ASPX, and they've probably choosen that in part for reduced development costs of their site because, as I understand it, ASPX will have automatically generated the Javascript to keep the validation rules etc. synchormnised between client and server-side, and to automatically move as much control logic to the client side as the browser is capable of handling.  Having said that I don't use ASPX so that may be my assumption, rather than reality.  All the Javascript on that page looked be mechanically-generated, rather than human-written.

I was also of the opinion that ASPX would automatically adjust according to the abilities of the browser - so possibly NoScript is not providing the host site with any indication that the browser "Can't do Javascript" (i.e. just not running the scripts, rather than running any <NOSCRIPT> block, or adjusting the META data), but having said that I can't see any <NOSCRIPT> tags in the source - so I probably imagined all that from the marketing brainwashers! or the BookBrain developers just haven't pressed the right button in the ASPX Dev Tools to get that to happen.

But it did cause me to wonder if NoScript would cause a <NOSCRIPT>-sensing host to NOT perform the no-script action the developers intended ??

[wyleu]

Django puts various authentication bits and pieces into javascript and has a middleware layer to deal with Cross Site Request Forgery Protection http://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ref-contrib-csrf

[stephend]

As well as cross-site scripting, there's also cross-site request forgery. Look up XSS and CSRF on Wikipedia. And who knows what other possible exploits there may be? Javascript is an interesting language but it has some unusual concepts and so is extremely prone to programmer error.

You can perform CSRF attacks without using JavaScript, it requires a little more trickery but it can be done with just plain old form submission, or in really bad cases with an img tag.

For all its faults JS is here to stay, and I think a lot of the issues will be resolved by using libraries instead of coding in JS directly.  I've toyed with Jboss richfaces which is a server side java library where it transparently does all the JS for you.  All you have to do is use the right tags in teh right place in normal markup language.  GWT is also interesting, but requires more work - again the advantage is that you can code in a static compiled language and the library will translate it into all that nasty browser specific JS.