Slashdot Mirror

Or Ben Schneiderman. In particular, Designing the User Interface.

I recommend J. Glenn Brookshear's Computer Science: An Overview. I read an earlier edition and thought it was brilliant: the writing is clear, the material is well organized, the book includes lots of examples, and thoughtful questions and exercises. Above all, Brookshear's text is enjoyable to read.

Even if you decide not to assign it to your students, the book will be a great resource for you if you design your own course.

See the book's website at http://www.aw-bc.com/brookshear/ and the author's personal website at http://www.mscs.mu.edu/~glennb/.

> A show of hands would do the same thing cheaper, faster, and just about as accurately.

Absolute nonsense. I've used both systems in my classroom. Have you?

When I've got four or five multiple choice answers listed, and need to quickly assess how people are looking at a problem (not just got 'the right answer', but 'are they thinking it's x? or y?'), using a show of hands is MORE time-consuming. What am I going to do, say "Ok, if you think it's option A", followed by B, C, D, E? Or maybe you want me to have them hold their hands up at different heights for each option?

If I can tell that virtually nobody was confused by some particular aspect of a problem but were confused about some other aspect, then I'm saving my students' time by not going over things previously discussed that they already understand.

Just because you don't understand how the technology is used and is useful, don't go dissing it until you've a) tried it, and b) read up on how it's most useful (see ch.1 and ch.2 from this book).

Here are the other Hibernate books I've read (or skimmed):

Hibernate: A Developer's Notebook
Hibernate: A J2EE Developer's Guide (Addison Wesley))
Java Open Source Programming: with XDoclet, JUnit, WebWork, Hibernate

But they all fall short of Hibernate in Action imho.

Personally, I like nothing better than code examples, and lots of them. I've never really used a SDK, but I have done enough programming in different languages to know what helps me turn out productive code quickly.

While not a SDK, take a look at the book On To C. This is the best programming book I've ever read. It is example heavy and assumes the reader already is familiar with programming. For example, it doesn't attempt to explain what a variable is or why you'd want to declare one, just how to do so, then provdes examples.

Here.

For example, I was recently involved in moving our entry-level CS classes from C++ to Java, and helping the instructors get themselves set up. What to use? As a Java hacker, my gut said: just use lecture notes etc. But wiser heads prevailed. Eventually we went with Lewis and Loftus, which besides being well constructed for its task (teaching elementary computer science in Java) has a massive amount of support materials. We could not possibly match that in quality. Yes, it's $70 on Amazon. You can get it cheaper tho. And it's worth it: we use it for three classes in a row.

What book to use for your JavaScript class? That I can't say, though O'Reilly's book is actually not horrible. But that's my hacker instinct firing off again...

The language Squeak wasn't my introduction to object-oriented programming, but having stumbled on Java I found Squeak to really be a much better object oriented learning environment. No language treats "everything" as an object despite their claims, but Squeak really comes darn close.

The Squeak programming environment along with the Korienek, Wrensch, and Dechow book were what made the idea of Object-Oriented programming really click in my brain. Even if you never program a "real" program with Squeak, the value of Squeak is that you can really learn OO principles without the baggage of a C heritage and designers who've shortcut language consistency in the name of efficiency. All are good things you may want to make the trade off for when programming a "real" program, but not things you want to short yourself on during your education.

My copy has been bookmarked on page 73 for the past six months or so, but the part I've read, I've liked and agreed with %-)

It may not be the same book the vendor is using, because it agrees with you on the simplicity factor.

My problems with XP are:

• The XP references to test development skip over a huge can of worms. Where I work (a disk drive company), the product firmware engineers don't write, or even know, the test system languages, and we use more than a few. In addition , many of the tests are canned, or beyond our control, like WinBench. IMHO, test software needs it's own team. It is unreasonable to say the product firmware engineers will just "code up" a test to verify a new feature. The test code could involve as much work as the product feature.
• Working in teams. We have a couple of asian engineers who don't seem to have a firm grasp of, how can I put this delicately, "personal hygiene". I would not like to be the "partner" of either one. We couldn't pair them together because they work in different disciplines. And most of the engineers here are code cowboys who would strongly rebel at having someone peer over their shoulder full time. Personally, I would have to troll slashdot from home, and how much fun is that?

This is seemingly logical but incorrect if the sampling is done correctly. If your highest frequency is definately 20 kHz and you sample at 40kHz you can fully reconstruct the original waveform. The reason for this is due to Fourier's observation that ALL periodic signals can be represented by a group of sinusoids.

Take your example for instance, you take 4 samples per period. Say we sample a sine wave at 100kHz which means the period of the wave would be 25kHz. This results in a plot that looks very much like a triangle wave if one connected the data points with straight lines. However Fourier showed that even waves with points are simply the correct collections of sinusoids with the correct amplitudes. You can see this yourself here. In order to approximate a triangle wave you need quite a few sinusoids starting in frequency at the period of the triangle wave. Thus the only way we could conclude our series of points represent a triangle wave is if there are frequency components in the wave higher than twice what we sampled at.
To fix this we to remove all the high frequency components. This is the reason when you build a sampling system, you use an anti-alias filter which blocks all frequencies above 1/2 your sampling rate. This way, you know that if the above points are read, they represent a sine wave, and not a triangle wave.

There isn't a syntactic similarity between Tcl and Applescript, but there are some deeper similarities. In Tcl and the Tk Toolkit John Ousterhout describes Hypercard as an inspiration for Tk for an easy to use to to create graphical applications.

The design of Tcl command extensions is also very similar to the classes and events that an application exposes to Applescript. Tcl statements are in the form "command arg ...". When you extend Tcl, you take libraries, maybe even existing libraries, and add them as new commands to the language. So while Applescript exposes your applications component functions to scripting, Tcl suggests that you decompose your application to components and tie them together with scripting. Tcl's scripting language subroutines also look like additional commands, and base language commands, a library extension's command, and user written subroutines are essentially interchangeable.

That last point about the commands being interchangeable, and Tk's "send" command combine to create something very similar to Applescript. You can send arbitrary Tcl expressions to a Tk application, have it evaluated based on the context of the remote interpreter, and have the result returned to you.

• set result [ send Editor .text get 1.end ]

  and

• tell application "Editor"
  get the text of window 1
  end tell

I am able to buy xeroxed copies of most textbooks and programming books in our marketplace for 50 rupees or less, however I am unsure if these copyies would be accepted well in America. I am particularly fond of this book, which I paid over 150 rupees for a color copy. I wishing that is was bound however.

Got your XP Pocket Guide a few months back, and it is a very good complement to the A-W series.

Being part of a dev. team slowly migrating to XP, your Pocket Guide is really helpful. You and your editor/s obviously put a lot of effort into communicating a lot of knowledge as clearly and concisely as possible, without losing too much detail.

XP PG accomplishes that, thanks guy.

(Sorry for the OT everybody, chromatic's book was - is - right beside my laptop when I saw his post. Hadda holler..)

Disclaimer: I don't know chromatic, and am not affiliated with either O'Reilly or Addison-Wesley.

My vote for a 'resident historian' would be the dude who wrote A Quarter Century of UNIX, or some other old timer, not someone who showed up late and copped an attitude.

I find it interesting that the new C# language is really streamlining the implementation of common design patterns. Use of patterns like an Iterator, Facade, Observer, etc. is simplified through language constructs like collections, interfaces, events, and more. You'd do well to read up on a topic before resorting to criticism.

As I recall there was a conference paper in Extreme Programming Perspectives which describes an "infection" model for bug creation, fixing, etc. They were trying to model exactly the effect you describe to see if they could (in a model) find any justification for XP's argument against the increasing cost of bugs through phases. Again, just from memory, they do try to validate the model against figures from real studies.

There's also material in Watts Humphrey's book on the Personal Software Process (about as far from XP as you can get). That book is illustrated throughout with statistics about students who tried to complete the exercises in the book, including in Chapter 13, where there's a section on "The Costs of Finding and Fixing Defects.".

Sounds like an interesting effort. I was just thinking the other day about how "profiles" of C++ might provide the safety and ease (eg. pointer checking, garbage collection) of Java or C#, without re-inventing the entire wheel.

As an alternative approach, I've had some success with this tool, which is basically a patch to gcc so that the code that is emitted on compilation contains bounds checking for each and every pointer arithmetic operation, including array indexing.

It works by finding the size of the block which is the target for the "base pointer" of any pointer arithmetic, and checking that the final result is within the bounds of that block.

The disadvantage is that it will slow your code down, but if security is important enough that becomes less important. However, it *doesn't* require any change to your code whatsoever.

I have not deployed code compiled with this extension, but I have used it when running unit tests over our existing code base, and it did find some subtle problems lurking in our code that had some of the real C language-lawyers around the place scurring to prove the tool was wrong and that their code was OK. After much argument, and referral to the C standard, it turned out the tool was exactly right in all cases. These were problems that didn't shown up at all in Purify! It really worked very well, and I didn't expect it be worthwhile at all.

I'm currently reading "Building Secure Software" (Addison-Wesley), and that's how I discovered this extension. This book seems quite good so far, despite the fact that I know a lot of it already. It doesn't just focus on prevention, but also talks about auditing and monitoring and other important deployment issues that are often ignored. You just can't assume that "nothing will go wrong" ...

It would be nice if every undergrad were to have read this book (or something like it) at some point.