Yes, true, but isn't this project meant to populate a Website's pages with equations?
There are any number of easy ways to create equation images solely for export to an image site, example http://arachnoid.com/latex . But populating Web pages for display is a different issue, and the fact that modern browsers allow zooming in and out, essentially ruins the appearance of graphic equations.
How do you like working in OR? Are there a lot of jobs in the field? I'm a math major and like programming, so it seems like it'd be an interesting career for me.
No lots of jobs, no, but there are jobs. It's an interdisciplinary field, so your math and programming background will hold you in good stead. Some basic stats are a good idea too.
Of course some people are doing OR but don't know they're doing it. Some just use another label. Other useful search terms include "management science", "operational research" (UK), "advanced analytics", and of course "optimi(s||z)ation".
If you're after an introductory text I can recommend Wayne Winston's Operations Research: Applications and Algorithms. 4th edition. ISBN-13: 978-0534380588
"What test do we need first? Looking at the list, the first test looks complicated. Start small or not at all. Multiplication, how hard could that be? We'll work on that one first."
The examples like this that were provided were of trivial methods. Trivial can be subjective, but, to me, methods whose bodies are almost always 2-5 lines long, not counting calls to other trivial methods, which may account for maybe another 2-3 additional lines, are basically trivial. It's one thing when you really don't need that much code, but it's another when you have classes upon classes upon classes upon classes, etc. to do something that could be OO and be in two classes with 1/2 as many lines and still be clear.
"Do these steps seem small to you? Remember TDD is not about taking teeny-tiny steps, it's about being able to take teeny-tiny steps. Would I code day-to-day with steps this small? No. But when things get the least bit wierd, I'm glad I can."
This is what Kent meant, but few of us picked up on it, per the first comment to his answer in your example from S.O. and per my experience.
I'm not blaming Kent, Ron, etc. or even saying that they are or were wrong. But, the commonly understood epitome of TDD used to be 100% test coverage and methods for just about everything. Those in the know said more like 60% was better overall but that was not really "true TDD". The implication of 100% "trivial" methods is more overhead for method calls (minor cost, depending, but can be cumulative, increase/decrease call stack size more quickly, which is inefficient), a large number of entry points (more stuff can be null/nil, cause NPE's or need checks if you don't know what is going to call it later, though that can be mitigated somewhat), and just generally too many LOC.
Hello Matt, I just want to say thanks for Lean Domain Search. A couple weeks ago I was struggling to think of a domain name for a small project of mine and then I saw your post. It helped me find a pretty good unregistered domain name in just a couple minutes. Since I'm no very creative myself, this really took a burden off my mind and helped me stay motivated.
