Read some books about game programming in Java (e.g. Killer Game Programming in Java and Developing Games in Java - though I think it would be better to find a newer one). Read some books about software design. Read some books about the main parts of Java (e.g. Java Network Programming, The Definitive Guide to Java Swing). Read some books about ai.
Whatever I can get my hands on that seems relevant to my work. In college I worked my way through books on OSes, compiler construction, AI, hardware architecture, programming alngauges, software design, user inteface design, computer graphics, …
Currently on my desk (work related):
The OpenGL programming guide (red book)
The OpenGL shading language book (orange book)
Designing interfaces by Jeniffer Tidwell
Concurrent Programming in Java by Doug Lea
Mastering the JFC (The big Swing reference book)
Artifical Intelligence - A Modern Approach by Russel and Norvig
Visual Explanations by Edward Tufte
I’m not going to pretend I’ve read all of these back to front, but I have gotten tons of useful information out of each one.
In my spare time I’m currently reading ‘The design of everyday things’ by Don Norman. Next on the to read pile is ‘The Humane Interface’ by Jef Raskin.
I rarely bother with language-specific books unless I’m learning a new language (currently trying again with Paul Graham’s ANSI Common Lisp but it’s hard) although I do keep some references on my desk, mostly Agile Web Development With Rails at the moment. The best programming books I have read are Code Complete and The Pragmatic Programmer - both absolutely excellent guides to the activity of programming rather than it’s application to any specific language.
Absolutely anything, especially new fantasy. Currently I’m reading Michael Scott Rohan’s excellent Winter Of The World trilogy, after which I’m planning to start on the Neil Stephenson historical ones. Looking forward to the next Steven Erikson Malazan book too. Not sure that’s what you were asking, though.
I find books tend to have more guaranteed good information - the most reliably excellent seem to be the Pragmatic Press ones, but O’Reilly do ok too. The web is great when you have an error message you can’t explain or you need a detailed reason for a problem. I use newsgroups and IRC channels for reasonably quick solution when possible.
Business and Legal Primer for Game Development by S. Gregory Boyd and Brian Green
So, this one is more of a reference book and one that I think is invaluable to anyone looking to start a game development company. The authors are well respected in the games industry and they have assembled a team of contributors that are top notch. This book covers everything you could ever want to know about starting a game company:
Forming the company
How to get money for your venture
Employee management
Company culture
Finding opportunities
Contracts
Marketing
PR
Protecting intellectual property
Working with licensed properties
Exit strategies
I shudder to think how much it would cost in consulting fees to acquire this knowledge and here it is, wrapped up in a single book, written by those on the front line. If you are thinking about getting into this business, don’t hesitate to pick this one up.
If you want to read an excellent book about software design in Java, “Holub on Patterns” comes with my highest recommendation. The introduction provides an excellent over view of OOP, and the remainder of the book comprises two large case studies if design patterns in action.
Say, does anyone have any reccomendations for a really good design patterns catalogue? Presently, I only have Head First Design Patterns, which is a good introduction but not as comprehensive as it could be.
Obviously, I’ve heard of the GoF book, but I’d very much like to get something that contains newer information. What would be even better is a book that would explain how to write some of the patterns once and then reuse them.
For instance, I use the Observer pattern relatively often. I would like to be able to just write it once and then use it. Java actually includes some kind of class that does this but not very well. Ideally, I would like to have some kind of support for many different patterns so that I don’t have to program them over-and-over again.
Frankly, I’m still a bit incompetent when it comes to patterns, and I could use some more information. “Holub on Patterns” sounds like it might be useful to me, but I’m wondering if anyone has any other suggestions.
When you say you want to only write the pattern once and reuse it you’re getting into the limitations of the language. Parametric types let you reuse classes, but fail to get you true algorithmic parametarization. In my estimation this is the advantage of functional languages. Paul Graham (love him or hate him) has said that patterns in his code indicate that he needs to add some new language features.
In fact this is the general pattern of language developement. Only when patterns become widely used do they get added to a language: like objects. Consider that Fortran didn’t have if…then…else until the 1977 standard.
So, for books I’ve been off the deep end of languages and compilers for the past year or so. I read what books I can because the local U. has a very weak comp sci department. The dragon book, foundatons of oo languages, Wirths compiler construction, and types and programming languages are books I’ve been studying lately.
Haven’t been reading fiction much lately. I have books by Greg Bear and Gregor Benford that are next in the queue when I get the itch.
Patterns in general cannot be automated, as they are methods of solving a type of problem, not solutions themselves. The use of objects, mentioned previously, isn’t a “design pattern” in the academic sense: it’s more of a programming idiom. Take observer, for example: you know that you tend to have an abstract listener, a concrete listener, an abstract subject, and a concrete subject. However, you don’t always have all four just like that, and sometimes they are classes and other times interfaces, and sometimes you might delegate part of the message passing… it’s a way of approaching a problem, and not a cut-and-dry solution. From my experience, the primary reason that one cannot automate the use of patterns (modulo macros and generics to save typing) is that they do not occur in isolation. Patterns emerge in collaboration, and the boundaries between them can be fuzzy. This is why “Holub on Patterns” is such an excellent book, and the subtitle gives it away: “Learning Design Patterns by Looking at Code”. The majority of the book is a pair of case studies that demonstrate how patterns are used within the context of solving a significant problem.
The “Head First” book is interesting, if you prefer flash and glitz to programming. It has some nuggets of insight within it, but in my opinion, it spends too much time talking about the physical world and not enough time on software models of the world. It explains the patterns fairly well, but it doesn’t demonstrate how they work “in the wild.” You can take my opinion at face value, but for whatever it’s worth, I’ve been teaching design patterns to novices, using various approaches and resources, for several years now. The best way to learn them is to get your hands dirty, to use them to solve a significant problem, and not to just pepper them into an existing project. They must be considered from a project’s inception. Also, trial-and-error or stumbling-in-the-dark will probably take much longer than having an experienced mentor.
[quote]In computer science, an idiom is a low-level pattern that addresses a problem common in a particular programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language.
[/quote] Idiom. What are you teaching again?
A “low-level pattern” is not “design pattern” as defined by Gamma et al. One must always be careful to define their semantics, as syntax alone is insufficient!
In any case, low-level patterns probably cannot be automated either. The idiom of “object” programming in C was developed prior to the inclusion of OOP features into C, but developing C++ did not automate object-oriented programming, it just made the idiom more convenient. I haven’ thoroughly thought about automation of idioms, but I suspect they would follow the same theme.
It sounds like I should just buy Holub on Patterns and any design patterns catalog (Head First Design Patterns isn’t much of a reference). And then I’ll just have to use them when appropriate and learn from my mistakes.