Slashdot Mirror

Here's some ideas on how to get started.

1. Do a search on-line. A quick query at google. For example, search for:
   • "structured programming" ISBN
     
   brought up a couple thousand hits. Browse through the results until you find something YOU find interesting.
2. Check out book publishers web pages, for example: Addison-Wesley
3. Go to a library (ideally a college/university which has programming courses) but if you are nice to the folks at the information desk... well, I've been AMAZED at what they've been able to do to help me find information.
4. Think of organizations that would have promulgated this info in the past and check out what they have to offer. Places like the ACM - Association for Computing Machinery which has been around since 1947 and which published journals on the latest in research in computer systems.
5. Check the bibliographies of any books or articles you find for pointers to other works.
6. It's been about 10 years since I last was active in this area, so I don't even remember what some of these acronyms stand for, but here are a few that I remember:
   • DFD (Data Flow Diagram)
   • DMD (Data Model Diagram)
   • LDM (Logical Data Model)
   • SASD (not sure, but IIRC Systems Design - was bin in the United Kingdom)
   • Structure Charts
   • AD/Cycle (A huge undertaking by IBM to bring all the major CASE (computer aided software engineering) companies at the time (Intersolv, Bachman, Knowledgeware?) together and to provide a central repository for all of the vendor's modeling information.)

Take a course in Data Structures, too. Of all the courses I took in college, this is one whose principles I still use each day. Knowing when to use scalars, vectors (arrays), linear or circular lists (singly- or doubly-linked), hashes, and databases... if the DATA is organized RIGHT, writing the algorithms to access it is GREATLY simplified! Use the right tools for the job.

I've seen too many programmers who just hack away at code until it seems to work -- great to see you trying to use other's knowledge and experience to bring some design and order into your programming! Good Luck!

Title of the paper is Location-Based Authentication: Grounding Cyberspace for Better Security

This idea is also explained in her book Information Warfare. The idea is using GPS signatures which are not forward-predictable. As other posters pointed out, that only proves the existence/access to GPS receiver located at some point and time not necessarily the presence of the *individual* there.

WakeTurbulence

... in his book An Engineering Approach to Computer Networking that the answer to this problem is ultimately economic: flat-rate pricing has got to go.

I'm not sure yet if I agree with him, but intuitively his argument makes sense to me, and it's certainly a thought-provoking assertion.

If I had the book handy, I'd quote him verbatim, and at more length. It's a terrific book, and I encourage anyone interested in networks to take a look at it.

--

GOF = "Gang of Four"

Gamma, Vlissides, Johnson and Helm

The book is called Design Patterns : Elements of Reusable Object-Oriented Software .

Operating System Design: The XINU Approach by Douglas Comer (from Prentice Hall) was a really good book for me. It concentrates more on building a working operating system than on theoretical issues, which makes it a lot easier to read than some of the more academic texts. (Tenanbaum, Silberschatz and Galvin, etc.) There used to be several versions of the book, one each for the PDP-11, IBM-PC, and Macintosh, but you may not be able to find anything other than the IBM-PC version these days.

I also have an old copy of The Design and Implementation of the 4.3BSD UNIX Operating System by Leffler, McKusick, Karels and Quarterman, from Addison-Wesley, which was a pretty thorough coverage of unix concepts when it was written. There is likely to be a more up-to-date contemporary edition. (and you can probably find a small army of similar books, including the excelent Linux Kernel Internals by Beck, Böhme, Dziadzka, et. al. also from Addison-Wesley) Finally, you may want to pick up a copy of the anotated unix source code Lions' Commentary on UNIX 6th Edition, with Source Code by John Lions from Peer-to-Peer Communications.

Operating System Design: The XINU Approach by Douglas Comer (from Prentice Hall) was a really good book for me. It concentrates more on building a working operating system than on theoretical issues, which makes it a lot easier to read than some of the more academic texts. (Tenanbaum, Silberschatz and Galvin, etc.) There used to be several versions of the book, one each for the PDP-11, IBM-PC, and Macintosh, but you may not be able to find anything other than the IBM-PC version these days.

I also have an old copy of The Design and Implementation of the 4.3BSD UNIX Operating System by Leffler, McKusick, Karels and Quarterman, from Addison-Wesley, which was a pretty thorough coverage of unix concepts when it was written. There is likely to be a more up-to-date contemporary edition. (and you can probably find a small army of similar books, including the excelent Linux Kernel Internals by Beck, Böhme, Dziadzka, et. al. also from Addison-Wesley) Finally, you may want to pick up a copy of the anotated unix source code Lions' Commentary on UNIX 6th Edition, with Source Code by John Lions from Peer-to-Peer Communications.

Operating System Design: The XINU Approach by Douglas Comer (from Prentice Hall) was a really good book for me. It concentrates more on building a working operating system than on theoretical issues, which makes it a lot easier to read than some of the more academic texts. (Tenanbaum, Silberschatz and Galvin, etc.) There used to be several versions of the book, one each for the PDP-11, IBM-PC, and Macintosh, but you may not be able to find anything other than the IBM-PC version these days.

I also have an old copy of The Design and Implementation of the 4.3BSD UNIX Operating System by Leffler, McKusick, Karels and Quarterman, from Addison-Wesley, which was a pretty thorough coverage of unix concepts when it was written. There is likely to be a more up-to-date contemporary edition. (and you can probably find a small army of similar books, including the excelent Linux Kernel Internals by Beck, Böhme, Dziadzka, et. al. also from Addison-Wesley) Finally, you may want to pick up a copy of the anotated unix source code Lions' Commentary on UNIX 6th Edition, with Source Code by John Lions from Peer-to-Peer Communications.

While I've got a few problems with the implementation of SEH in C++, such as the fact that it's a pig to handle exceptions in constructors, it's very embarassing throwing exceptions in destructors, it's easy to nause the whole thing up (see here for an in-depth discussion) and the fact that there's a runtime hit just like with RTTI (and I don't know Java well enough to comment on how it handles it), the general concept is one of the best things C++ stole from (wherever BS stole it from: I haven't got my copy of D&E to hand) and the combination of exceptions and smart pointers rocks.

And yes, tail recursion is waay cool: in a similar vein, do 6502 assembly programmers remember replacing JSR <address>; RTS with JMP <address> to save the extra operation. Those were the days...
--
Cheers

• Programs tend to be used in unexpected environments. Planning for software to be more general results in easier maintainance later. (Similar to Brooks "Plan to throw one away. You will anyway.")
• The development and deployment environment will change. Making a program portable to many different currently available environments will help against changes in future environments.
• The techniques for creating portable software are similar to the general techniques for good programming. So the effort writing portable software will your software better.

I once took a course with Dr. Alfred Aho, one of the authors of The Dragon Book and a contributor to lex, yacc and awk (he's the 'a' in awk.) Dr. Aho would never call a compiler component an "optimizer;" instead, he called it a "transmogrifier," because the only way a compiler could produce truly optimal code would be if it could write an optimal program--and it can't.

While the compiler has the opportunity to rewrite the code every time it processes it, it's not very good at rewriting code, so its abilities are limited.

A well-designed compiler on a well-designed CPU can produce very good assembler code--I doubt I could outsmart a compiler in a RISC assembler optimization problem--but I believe that code tweaking is usually of value only in inner loops and for certain kinds of data storage.

All of which adds up to the reality that, pending the arrival of artifical intelligence, human programmers are still needed.

The cseng-sections Just Published and Coming soon -listings are suffering from a timewarp back to the beginning of the century when no books had been published and everything is coming soon... Listings start from 1976.

The cseng-sections Just Published and Coming soon -listings are suffering from a timewarp back to the beginning of the century when no books had been published and everything is coming soon... Listings start from 1976.