Does anybody out there use honeypot passwords? It seems like such an obvious idea, but it doesn't seem to be generally implemented -- at least no system that's ever given me a password has let me configure honeypot passwords. Personally, I'd really like to have a honeypot PIN for my bankcard and honeypot passwords for all of the online shopping/bills/finance stuff--ie, the stuff where it's important.
For those unfamiliar, the idea behind a honeypot password is either
to pick one or many "guessable" passwords like those in the article and use them as honeypot passwords. Allow somebody to log into the system using them but set off a silent alarm. Presumably, any would-be hacker will "crack" the honeypot password before the "real" password and will quit trying to get the real one.
Have one "real looking" password (especially PIN) that you can give out if somebody demands it at gun or knife point (you get the idea). If used, it immediately notifies the authorities (silently) and shuts down the account/card in say 1/2 hour (presumably enough time for you to get away). For the would-be mugger etc there's no way to tell if they got the "real" or the honeypot password.
I see Perl 6 as kind of a pantheon of programming gurus, and you can subscribe to whichever you like (or tell them all to screw off). The most important thing about Perl 6 is you can use whatever programming style suits you best. In a corporate environment, that style can even be dictated down by the powers that be, too. If you're one of those people that thinks that Lisp (et all) is (or is not) understandable, or thinks Java is a brain-dead C++, or that C++ is error prone Java, then Perl 6 may not be for you. You let (percieved) flaws obscure the important benefits, and as a result you miss out. Objectively, you would be examining the trade off between learning curve and increased efficiency over the time period of the project. In many cases, it is in fact better to stick with the tool you know, even if a different tool would be twice as effecient. Since it's just not possible to learn every single tool available, as professionals, we have to pick the most effective set of tools that we care to know given our interests and other expertise. This brings us around to the great thing about Perl 6: in one cohesive, sensible framework, it gives you really broad coverage. You don't have to learn it all at once--you start out using Perl 6 like Perl 5; then when you decide you want to do some lispy type things, you don't have to learn Lisp and a whole new toolchain, you can learn to do lispy types things in Perl. If you want to do things that would be well suited for C++ templates, you can learn the Perl 6 mechanisms for it instead of undertaking C++. And what is really, amazingly cool is that Perl 6 is shaping up to be a cohesive, well considered framework; it's not a jumble of competing ideas that don't play nicely with each other.
If you've worked with C++ templates and metaprogramming, then you certainly understand the benefits being offered by a lot of the Perl 6 constructs. But the Perl 6 way is much more comprehensive, direct, clear, and intentional. Everything with blocks, anonymous subs, closures, multi methods, named parameters, operator overloading, and macors offers unbelievable oportunities for meta-programming. Once Perl 6 gets rolling and starts developing its own equivalent of Boost, then programming will never be the same. Boost changed everything already, but you've probably never heard of it; but Perl 6 will have mainstream appeal, acceptance, and use that Boost will never have.
I too, have marked you as a friend. Anyway, in my opinion, there is no particular correlation between having a degree and being very good at what you do. Let me explain a little. There are some people who really love and care about whatever they pursue, and they will get good along whatever path they pursue. Programmers, artists, or car mechanics, doesn't matter. If they love it, they'll find a way--sometimes, that way is at a university, sometimes that way is in the basement, and sometimes it's teaching English in Siberia. Unfortunately, people with that kind of dedication are rare, and so you're left hiring somebody who pretty much just wants a job. Which is only fair, because you've probably only got a job to offer. No offense, but odds are that the work your company does is not very interesting.
Finally, I wanted to respond specifically to this post:
The schools shouldn't be going out of their way to graduate programmers who can't program.
I don't know of a single school that offers a Programming degree program. Some offer Software Engineering, but the vast majority only offer Computer Science. Many people fail to realize that Computer Science is basically a math program, and has very little to do with programming at all. A Computer Science program shouldn't teach programming beyond an intro course--you don't expect a math major to take much physics beyond basic mechanics and E&M. Academia is not yet prepared to admit that programming is a discipline unto itself. In my opinion, Computer Science really should be a graduate program for people who study Programming or Software Eng. in undergrad.
I don't know of anyplace in the world that you can go to and learn programming, except on your own with a book, a computer and a compiler (or interpreter, don't nitpick). Coworkers can be great--well, if you have somebody like me as a coworker. But you can't just go out and sign up for a coworker to look over your shoulder. My point being that when you need to hire somebody, you should actually think about what got taught in the program they graduated from. And, if you find somebody that's good at programming, that person *is* self-taught, even if he or she did the self-teaching while at a university while taking CS classes.
While I haven't tried the new NetBeans, I have been using the latest stable for a couple of months now for some servlet development with Tomcat. There was a HUGE improvement when I upgraded to the 1.4 Java SDK. All the repaint problems disappeared, which was the most annoying thing in the first place. I'll be excited to try out this new version, though.
If you want to see what the future of real world programming looks like, like no further than Boost. I say this because Boost demonstrates the programming techniques of the future that work on compilers available now. In theory, Boost techniques work on any standards compliant C++ compiler. Given that most compilers these days are still pretty weak on their standards compliance, the friendly Boosters have already coded a great number of work arounds so you can still use the libraries.
Something that you might find surprising, though, is that the future is the past. Sort of. The future is shaping up to be a synthesis of great ideas from the past. Functional programming and metaprogramming are making a resurgence, except this time in moderation. You see, in the melting pot that is C++, you're not forced into any particular paradigm, and you get to use what works best for each subproblem. The real beauty, though, is that only library writers really need to be experts in this multi-paradigm thing; application writers can go about their merry business relatively unaffected, except with libraries so powerful you can't understand until you've tried them.
For a sample of libraries to really blow your mind, check out
1) Boost Lambda Library, which adds lambda function capabilities to C++. This is a staggering because C++ doesn't have lambda functions (like Lisp does).
2) Spirit Parser Framework lets you write parsers in a natural EBNF type notation, without the need to run a seperate pre-processing tool like Lex/Yacc (Flex/Bison).
3) Meta Programming Library. This ones a little tougher to wrap your head around if you've never tried writing generically reusable libraries. This is a library designed for other library writers, so #1 and #2 above make extensive use of this.
4) Preprocessor Library. This is a library to help you do meta programming with the C/C++ preprocessor. See, not all inovation is coming from those new fangled template things. You'll just have to look at the examples to get why it's cool.
The best part is that, unlike Perl 6, you can use this stuff now. Play around with, see how it works. You will be stunned, amazed, awed, etc by what these people have done. And you don't have to "get it" to use it.
Want a hassle free, no dickering with the technology studio? Get a turnkey solution. Any of the major music chains like Guitar Center or Sam Ash will sell you one. Additionally, you can go to Carillon Audio to get PC systems. They are the defacto industry standard. Even if you don't need a complete turnkey system, go to Carillon for the computer; they have components that work right for audio. When I switched to a Carillon system from a homebrew PC, all my tech problems went away.
As far as software, unfortunately, there is no Right Choice these days for PC. Now that Logic is Mac only, there's nothing really competitive left. You come down to choosing between limitations. Here's my breakdown of the major software kits:
1) Logic Audio. Best all around. Has very competent built in Score editor. Has very nice built in synthesizers (some for extra $$). Comes with the best, most comprehensive set of plugins. Its MIDI programmability is outstanding, and the integration with SoundDiver is very nice. Logic Control is top notch. Very customizable (also complex because of this), interface is cluttered compared to other programs. Will work with TDM systems, if you can afford it. A lot of people use Logic as a front end to DigiDesign (ie ProTools) hardware. Can't be beat for the price if you actually use all of the components. Note that many shortcomings compared to other programs have been addressed in the latest version (6.0).
2) ProTools. If you get LE, you only get 32 tracks. That's *mono* tracks; so only 16 stereo. If you're working with synths that make stereo output, this is a severe, cannot be overstated limitation compared to all other programs. To get around this limitation, you have to fork over for a TDM system, which is $5-$10K on the low end. Otherwise, LE is great pricewise because it's free with hardware, which is hard to beat. Best audio editing capabilities all around. Studio standard, and LE has full compatability with big studio rigs. Gotta watch for Mac/PC compatability (it's easy to do, but a lot of engineers don't even realise PT runs on PCs, so they never click the check-box. This has been a real PITA for me). No score editing, MIDI is mediocre, uses a different plugin format. Even the big rigs have pretty harsh limitations on inserts/sends per channel (5/5) compared to Logic (16/16). Cleanest interface (IMO). If you don't need the MIDI/Score/Synthesizer stuff from Logic, LE definitely has the best price/performance. Oh, and 6.0 supports ReWire, I understand, and 6.0 will be available for Windows in a couple more months, I guess.
3) Cubase. A real bear to configure. I still don't have it properly recognizing my audio hardware. I don't use it much because of this. It's got nice audio editing features, it has an interesting feature to link multiple machines together to run bigger projects (I haven't tried it, so I don't know if it really works). I've never tried MIDI with it, although there's no score editor. The interface is clean, but I find it very constraining. Logic is very customizable, and PT LE just works for me (so I don't care that it's not too customizable), Cubase's interface just grates me the wrong way and I can't fix it. So I wind up using Logic and PT LE. Also, I need missing features, so it can't replace Logic for me.
4) Nuendo. Cubase's big brother, it's expensive. Targeted at movie/tv/ maybe radio/post production houses. Never used it, but as I understand it, has lots of project management features. ProTools 6.0 TDM has a lot of these features; things like different logins for different engineers using the system, and remembering preferences for each one. Very useful in a pro environment, not so much at home. Otherwise, same general pros and cons as Cubase. Nuendo 2 and Cubase SX are based on the same engine, I think.
5) Cakewalk Sonar. Main plus: it's cheap, and works well for MIDI. Does have a score editor, I think. Does not support ASIO, whic
You must have been looking at something that's about a year old. A year ago, we were just talking about it. Now it exists:) It mentions it on the "Features" page. To use it, open a presentation and select File->Export. We do not currently export animations, but that is something that we want to add for 1.1 final.
What would I have wanted to know, and what would I have made use of? The most important thing:
Nevermind that you're technically in 6th grade, demand to tryout for the 7th grade basketball team. The administrators will understand you'll be screwed next year competing against the 8th graders (and thus on into high school), so they'll help you out.
That could have radically changed my life. On further thought, that wouldn't necessarily be for the better. Maybe I would answer all my programming questions and explain some basic comp-sci. But then, I gained a lot of my independance from figuring out programming on my own. It's probabally better the way things worked out. I would love to give my 12 year old self my portable CD player and my CD collection. If I could talk to my parents, I would tell them to get me a real piano teacher instead of the boob I was working with. Here's some advice for myself:
Kid, the adults around you are ignorant. Really, really ignorant about the things you care about. Don't worry when you feel dumb because other kids seem to know stuff. They just have access to better adults. But you're getting something better, independance and initiative. In a couple of years, you'll find a programming mentor. Then, when you get to college, you'll find that you don't really like answers with strings attached. Oh, and let me teach you a little something about Relativity so you don't feel stupid when you take your 6th grade science fair project to the local university and the helpful college students point out that you got it all wrong. Oh, and take these MindStorms for your robotics project next year that never gets farther than some circuit borads and blinking LEDs.
Damn. Couldn't help myself there at the end. Now, if I could go back and be my own Dad, well that would rock.
Better: Yes. More Interesting: Yes. How many Levels: Yes. Getting into Nethack requires a little patience. Then again, so does Chess. They're both no fun when you don't know what you're doing. Nethack is miserably dull when you keep starving on dungeon level 2 and keep starting over again and again and again... What you've missed, though, is that Nethack is the deepest game ever made. By that, I mean most games make you do what the programmers' want you to do. This is because the interactions between items, actions, bad guys and such is combinatoric in nature, so games that have a fixed dev schedule only implement a tiny fraction of interactions. This is why you must find the "Magic Key" to open the door, rather than just kicking it down. In Nethack, you can kick the door down. Unless you're a tourist, in which case you might hurt yourself trying. You can also try picking the lock. This can work well on locked chests too. You might not want to kick chests open, because that can destroy some things inside (like potions in glass bottles...) You see, Nethack has been in development for a VERY LONG time by people who aren't wasting time making pretty graphics. This means that people have come up with interesting, clever, and often funny interactions for so many corner cases that you will likely never exhaust the possibilities of this game. Toss in multiple character classes, and randomly generated dungeons, and you have a game with more replayability than anything else I can think of. Oh, and it's HARD. You only get one life. You die, you start over. Makes you actually think about what you're doing, and makes all these decisions really matter. Oh, and one piece of advice for the newbie: if you're about to starve on one of the early levels, try praying, and don't eat zombie corpses.
The best advice I can give is to work with somebody else, and talk everythring through. When you're sleep deprived, the msot important thing is to retain focus. As soon as you lose it, you'll drift off. You can knock off specific tasks from a to-do list with only half your brain working, but creative thinking, problem solving, and the like will derail really fast under sleep-dep. To alleviate this, talk things through until you have a concrete to-do list. This forces you to focus, and your partner will bring you back in line if you start to drift. Once you have a to-do list, work on it alone until you get stuck. Ask for help. Talk it through. Repeat. Just remember, if your mind starts to wander, you lose.
I've done a fair amount of interviews over the last five years, both as interviewee and dozens as the hiring manager for programmers, QA people, and other managers. One of the most important things that you can learn about hiring: you get what you ask for (this is true of many things, actually). You have to understand what you need. And I don't just mean job descriptions (though I'd bet that those are a little weak, too). You need to think about the person's role on the team and what kind of personality will excel at that.
For example, if you need a coder that keeps his head down and does what you tell him, that's a fairly specific personality type. If you're counting on the coder to tell you you're wrong (when you are:), that's a very different personality. Next, you have to keep in mind the team dynamic--you can't just load up on one type or you'll miss a lot of angles. A room full of heads down coders will happily deliver the shittiest program you've ever seen, 'cause that's what you asked for. However, there is some inherent conflict between some personality types you have to watch for--that's (partly) why the manager has a job, though:)
Anyway, we found it very useful to lable the position with a short but colorful personality description. This personality will determine how important the technical details are. For example, if you're hiring a blackbox tester, niggly details about platform differences are important (how do you examine cookies in IExx on Mac?), whereas you expect an architect to have very broad knowledge and the ability to get and understand details when needed. Here are some examples of how we might characterize the needs of our positions:
Yesman Bullshit-o-meter Swingman Schedule Monkey Mad Scientist Maud'Dib Professor Mechanic By-the-b ook Can-smell-trouble (ie bugs) Programming Seal (ala Navy Seal) a Machine
These types of characterizations are useful because your non-technical interviewer can understand the gist and help look for them. Also, you can find professionaly prepared interview questions along with guidelines for how to interpret the responses for these types of things.
Once you've got this figured out, you can decide whether or not you should ask syntax minutiae, give logic riddles or textbooky exercises, ask them to explain concepts, or ask them to tell a joke they like. All in all, if you know what you need, it's much easier to spot.
I've looked at every single office suite out there. None of them - NONE of them, have any type of automation interface.
Apparently, you didn't look hard enough or you are incompetent. I thought about modding you down, but you're already up so high that I have to correct this blatant misinformation.
I have used OLE Automation with MS Office, particularly PowerPoint, developing a non-trivial application here at work.
1) OpenOffice/StarOffice offers a very capable automation interface called UNO. You can even automate StarOffice through OLE if you are running on Windows. I have not done this yet (although I likely will in the near future), but I have used the automation on Solaris (yes, Solaris!) when porting my application to that platform. It was able to handle all my needs admirably, although it would be nice if their online documentation was searchable:(
So you, sir, will be needing another ass if you expect to keep talking out of it. Seriously, though, I sort of agree with you're final point: if you actually use one of the missing features, it can be a pain to switch. You just picked a bad example feature, and stated it with too much certainty and vehemence, and I don't want misinformation like that to spread too far.
MFC vs wxWindows discussion more interesting
on
Qt vs MFC
·
· Score: 1
We had an MFC vs wxWindows discussion, where Qt and others were of course brought up, and it was MUCH more informative. See here.
First, thanks for replying. Seems like we'll probably agree to disagree, though:)
The subtleties you have worked hard to understand and work within don't exist in other, more perspicuously designed GUI frameworks.
Mostly, the subtleties I have worked hard to learn are subtleties of GUI programming in a WIMP environment. There's pretty much no way around knowing what events are generated for various things and what data comes along for the ride. Whatever your environment is, you will occasionally need to know what the construction order is of your windows and other frustrating items. And I won't believe for a minute that there exists a toolkit worth using without subtleties.
I would rather have something behave the right way the first time than in some peculiar way to be vaguely deduced/read about.
I find that newbs tend to get confused/frustrated because it's so easy to get started with appwizard that they get misled into thinking that you don't have to know anything to make it work. A lot of them, being fresh out of school, have never done event driven programming, and are just overwhelmed by the whole model ("where's the f*#@ing main() function?!?"). These people should do some windows programming straight to the API before trying MFC or some other toolkit, because they will find any machinery peculiar and has to be read about.
I understand your affinity for MFC: once you've gone through the pain and considerable expense in time of learning it, it's hard to believe there's something else out there that's much simpler to use and equally, if not more, powerful.
Let me clarify that I do not like MFC. It has the same problem as pretty much every toolkit that I've worked with: it bundles a GUI toolkit with an application framework with a bunch of utility classes. The GUI toolkit is pretty reasonable given the windows API it has to work with. The app framwork kinda sucks, and I don't like the utility classes much. Now, while people like boost.org are working on utility classes that will rock, they're not ready yet, and nobody that I know of really cares much about app frameworks.
Finally, porting fromanything to anything is by definition more work that simply writing that one thing once.
On the surface, this seems like a truism. However, lets say that you have a tool that will save 10% of your development time if you use A instead of B, and that you already know A but not B, and you can port from A to B without really having to know a lot about B, and so you can port in about 1% of the development time. In other words, I think that given this guy's situation, it is very reasonable to expect that appwizard and classwizard will save him more time than he spends porting to wxWindows.
This is a valid point. I made the assumption that hardly anyone with this cursory a knowledge in GUI programming on windows would be creating yet another chess program for commercial purposes.
Consider the possibility that he's using this as a learning experience for a future commercial project. Not necessarily a deciding factor, but you do want to keep in mind how your skillsets will help you in the future:)
I think that this is a troll, although I can't tell for sure. Seems a little misinformed, at least.
wxWindows is no silver bullet, but it is very functional. All of my experience has been, "it just works." The main extra work for me in getting code to be cross platform when working with wxWindows is the different build environments. If you're a VC++ developer, then the whole Makefile thing can be confusing for a while.
You go on to rip on the autogenerated code, which suggests to me that you were having some trouble grasping the MFC framework. It takes a little getting used to if you've never done event based programming before, but apparently this guy has done MFC before, so this shouldn't be a hurdle. The stuff that AppWizard and ClassWizard generate are there for a reason, and very rarely do you have mess with any of it. On the occasions that you do have this need, then yes, you need to read the comments, and should probably get a book. MFC has its shortcomings, sure, but usually people struggle more because they don't understand the windows API programming going on in the background. If you want to do fancy stuff, then you have to know what events to handle, what the creation sequences are, and occasionally there are subtle interactions between MFC and the API. But this guy just wants to write YACP (Yet Another Chess Program), so I doubt he's going to do anything fancy. So VC++ will save him a bunch of time and not cause much in the way of headaches.
You sum up by suggesting that porting from MFC to wxWindows would be the most work and that QT would be the "least pain." I must humbly disagree. If he already knows MFC, then porting to wxWindows is quite trivial. I have not used QT, so it may also be easy, but QT has licensing issues if you want to distribute a commercial application, whereas wxWindows does not. I realize that he just wants to do YACP, not likely a commercial endeavor, but wxWindows seems like the better skill investment to me. And since you greatly misrepresent the case for wxWindows at least, so I'm dubious of your claim that QT is better.
Sounds to me like you haven't done much porting between MFC and wxWindows. I've never had an easier porting experience. wxWindows was intentially built to work like MFC to make it easy to port, and they most certainly succeeded, with the notable exception of OLE support. I ported a several man month project in a day or two, and none of it was hard or confusing, it just amounted to looking up the equivalent functions in the help. I could do the conversion much faster now because I wouldn't have to keep glancing at the web page.
Write it in MFC, then port to wxWindows
on
wxWindows vs. MFC
·
· Score: 3, Informative
If you are a newbie, then write it in MFC. Porting to wxWindows is easy--I recently ported an MFC project at work to wxGTK on Solaris, and chaning all the MFC calls to wxWindows calls only took a couple of hours for a 2 man-month project.
If, on the other hand, you are confident with MFC, then just skip it and write straight to wxWindows. Basically, if you write in MFC with VC++, you can use all the class wizard stuff to set up message maps and create stub functions, etc, and it's just faster to get it up and running if you don't know how to do this yourself. Then, you can do easy search and replace to convert to wxWindows. For example, all of your Invalidates become "Refresh," all of your CDCs become wxDC, CString becomes wxString, etc etc. You will have to make a couple of small changes here and there, but search and replace will be 90% of the work.
If you know how to set up the message maps and whatnot yourself, then just take one of the example programs (it comes with loads of examples) and start modifying to taste. There is really good documentation on the website, although I found the search capabilities cumbersome.
You say that you've taken up an interest in "Math" again. No offense, but from the sound of it, you weren't into math too much when you were younger. Odds are that the vast majority of "Math" that you were ever exposed to was mechanical equation manipulation. This tends to be tedious and very, very boring. Several people have asked, what do you want?, and I agree. More specifically, do you want to be good at manipulating equations? Or are you more interested in discovering neat mathisms that just blow your mind and permanently change your outlook on reality (and you don't mind if your mechanical skills are poor)? It will be easy to find classes to help you with your mechanical skills, and there are plenty of "fun math" books out there. There don't tend to be a lot of "fun math" classes, though hunt around and you might get lucky. The most important thing of all, IMHO, is to find a partner in crime. Pick a book and the two of you spend every other Saturday around a white board working through a handful of the easy excersises. When you get stuck, find somebody that knows more and ask. It won't take you long to get the gist of the topic. Then pick another book. Repeat until bored. You'll probably learn what you want or realize that you're actually much more serious about it within a year or two.
then C++ shouldn't scare you too much. Check out the Spirit parser library. In a nutshell, it's kind of like Lex and Yacc, but without the need for seperate tools, ie it's all done with standard C++. On the theory side, while everybody is mentioning compiler books, I find those to be a little rushed. Get a good book on the theory of computation (sorry, don't remember the name of the one I like:( ). I found their explanations of automata, regular expressions, grammers, etc etc much more elucidating than the compiler books. I think that this is because the comp theory books treat them for their own sake instead of in passing. And, of course, if you're looking for algorithms, Knuth has plenty:)
I would just point out that some of these manufacturers, like Echo Audio, do not cooperate well with the open source crowd. Go look at the ALSA list of supported sound cards before you buy if you want to use it under Linux. I have an Echo Mia card (their cheapest one), and it is good hardware for the money. The drivers under Windows had problems, though. I have recently gotten the new MOTU 896 Firewire pro interface, which is a great box, but Firewire on PCs is still touch-n-go. Anyway, neither one of them works under Linux, which is a PITA for me as one of the Audacity developers.
The basic gist of the question here is, "Is writing code on paper a fair way to test in a CS class?" To be frank, this question assumes so much that there's no good answer. Fair, test, CS, and class are so ambiguous that it will leave your head spinning if you try and pin down an objective answer. Let me run through some of the problems to illustrate:
1) You asked about a fair measurement. Measurement of what? You're taking the concept of a "test" as used for "measurement" in the context of a "class," where the nature, purpose, and significance of the measurement is effectively arbitrary--being arbitrated by those who administer the "tests." You said measurement of coding skill; however, this is not necessarily the attribute the testers intend to measure. Hypothesize for a moment, though, that all CS tests that ask you to write code on paper intend to measure your coding skill.
2) You said "fair." You then applied that word to a measurement. Generally, I would more likely use the term "accurate" when referring to a measurement. However, I think that you were referring more to the process of testing when you said "fair." What, then, is a fair process? We want to run a test, measure the results, and draw conclusions. (oversimplifying) As an emperical scientist here, we want the process not to introduce bias, or at most to introduce systemic and well understood bias. So I believe your questions translates to, "Does the writing-code-on-paper process bias the result (code) in a way that we cannot correct for before drawing conclusions regarding coding skill?" An "unfair" process would then yield incorrect conclusions even given accurate measurements and strong statistical correlation between measurements and conclusions.
3) There's the kicker, though. Given accurate measurements and strong statistical correlation between measurements and conclusions. How can you tell the difference between poor process and inaccurate measurement? Presumably, you have a way to independantly verify that the measuring device works, so let's presume that you have a computer program that performs OCR and assigns a point score (measurement) to the code (results), so that we may be certain that the same handwritten test paper always gets the same score. Now how do you tell if your process was good? Make sure that you can repeat your own tests. Then get independant verification. Now, you have to go back to your theory and explain how the results fit into your theory. Hopefully, your theory will suggest other tests that you can run that will confirm your earlier results.
4) Finally, we hit the fatal flaw in this question: we have to measure coding skill in some other way to see if the results agree with the writing-code-on-paper method. But the other method that you're appealing to here is/.ers' judgement. Effectively, you're asking, "If a measurement of coding skill obtained by writing-code-on-paper produces results that disagree with your own, does that imply a bias in the writing-code-on-paper process?" Well then, what is MY process for measuring coding skill, and is IT fair? Your presuming that there is some method that we can use to cross check the coding skill measurement. Sure, those of us in the field probably have a decent gut feeling, but have any of us measured our coworkes writing code on paper recently? Not likely...
Anyway, you're presuming that all of the other aspects of testing are fair, and I made a huge assumption with the OCR grading program. What you get depends on the grader's mood, and other things. Also, the formulation of the questions biases the results more than anything. But that's testing for you.
You say that this is for an introductory course. Does this mean people with zero programming experience or little experience? Are you talking about high school, college, vocational, or corporate training type courses? I'm not very close to the teaching scene, and so I don't have any good pedagogical sources. Anyways, a few cautions along with my thoughts: our conceptual models probably vary widely, having mostly developed ad-hoc. Methodology, and the coincedant models, of any kind are not exactly common amoung professional programmers. Articulating the ad-hoc models that we do use, often unconsciously, is not easy. Interesting study? Very. Useful for an introductory course? I don't know your purposes, but I doubt it.
So, now for my thoughts. I would couch the discussion in terms of problem solving, rather than "programming" per se. Hopefully your students are used to solving math, physics, and/or chemistry etc problems. In this context, "problem solving methodology" should hopefully be sufficiently tangible to get them thinking about it. Discuss using algebraic methods versus geometric arguments versus intuitive methods for problem solving. This is mostly just to get them thinking about the fact that there are entirely different conceptual approaches, all of them workable, but with different applicability. It should be less controversial in this context to say that there is no "best" approach, only ones that you are more or less comfortable with. Now it should be easier to present different programming paradigms as different approaches to the same problem.
Ok, now, how math inclined are these students? If you want to go after conceptual, well, you're going to hit a mathematical barrier eventually. If you can spend some time on basic set theory, and the idea of functions as mappings or projections, I would recommend it. Then, some basic algebra to get across the idea that we define the meaning of operators, but we try and do it in such a way that the emergent properties are interesting to us. And of course, I would (re)introduce them to Newton's method as a segway into algorithms. Finally, I would go over just enough logic and binary arithmetic that you can lay out a simple adding circuit in terms of AND, OR, XOR, etc. Now the stage is set without unduly biasing them towards one method. They may be severely disappointed by so much math, though:) But then again, my peers were severely disappointed by Prolog.
Thank you. Thank you for standing up and declaring, "I am woman, hear me, um... CODE!!" Unfortunately, I think you may be falling for the same trap as the how-can-we-hate-the-MIAA-and-still-go-see-Star-War s? crowd./. is diverse. There are whiny boys here, there are uber-studs here, and there are guys like me. Cute girls, hot babes, and very plain women.
Now, about this party--it's 21 and over. A lot of those whiny boys are just that--high school kids and what not. They probably won't be at the party, cause guys that whine about gurls don't tend to go to parties anyway!
On behalf of all the decent guys on/., if I see you there, though, I'll buy you a drink and ask you to dance. How's that? And if you are as cute as you say, I'll even talk about something besides code, Linux, or computers;) In the meantime, I'll be learning the Lizard Mambo:)
This idea is, in fact, being pursued. A company in Pasadena (CA) called HorizonGOT is developing exactly such a solution. A friend of mine is their CTO, and I can assure you that they're not smoke and mirrors--they are working on getting this tech adopted in some next generation MMOs (ie, ones that are starting development cycles soon). They were actually supposed to be doing a technology demo at E3, although I haven't heard how it went. Basically, though, these guys are much brighter than say your typical DRM inventors. They understand VM attacks, debugger attacks, network spoofs etc etc, and have clever math and encryption to fight it. This has been developed by a team of bright mathemeticians, coders, and security guys over the last 2 years or so, and I'm pretty convinced (for what it's worth) that it'll take a serious black hat effort to defeat their system. But just like anything, it'll be a game of cat and mouse; can they fix holes as fast as the black hats find them? I wish them the best of luck.
>> This response is the typical, "I'm going to try to be anti-Western but really don't know what I'm talking about".
This response is the typical, "I'm going to post as an Anonymous Coward but really don't know what I'm talking about."
>>First of all, I went to a 4 year college, as well as got some certifications as a Sys Admin, and have a job at a really good company.
Congratulations. You seem satisfied, which is quite an achievement.
>> You should never decide whether or not to go to college based on how much money you will lose by not working. It is somewhat ironic that whoever wrote this response seems to have some disdain for the norms of the western world, yet seems to be mainly concerned with money.
Money is mostly interesting with respect to what you do with it. Hoarding money is not very interesting, except to the extent that interesting things take more money than you currently have.
>> Going to college is not about money. Clearly, if you can't afford a private univesity, you may have to go to a state school or community college, but don't think in terms of, I could be making $25,000 a year, and school costs $10,000 a year, so I'm actually losing....that type of thinking is for people who don't understand education.
It's not so much about making or losing money, but about making good use of your money. If you spend $10K/yr on school, you will get certain benefits. If those are benefits that you want, and you value them more than other benefits that you could have have with the $10K/yr or $35K/yr while working, then by all means. You have made a value judgement.
>> There is more to being educated then just being able to get a job. That being said, there is NO WAY you will be able to get a good job without some type of college degree. What the degree is in may not matter, but it has to be something.
There is more to life than having a good job. That begin said, there is NO WAY you will be able to get a good life without some type of rewarding life experience. What the experience is in may not matter, but it has to be something.
>> Try going to Microsoft to apply for a job and explain to them that you decided not to go to college, but rather to buy a motorcycle and drive around for a year or two and take jujitsu and you have some Microsoft certifications you got >> from reading a book or two and taking a multiple choice test, but you have really good sys admin experience from when you were 18. If they don't laugh you out the door, Gates himself will probably drag you out back and beat the certification right out of you.
Try going to a movie studio to apply for a job as a stuntman and explain that instead of going to college you got a motorcycle and learned trick riding and got a 3rd degree blackbelt in jujitsu and you have safety hazard certifications that you got from reading a book or two and taking a multiple choice test and you have really good extra experience from when you were 18 with a few union vouchers. If they laugh you out the door, Gates himself will probably beg you to come work on the new XBox game, "Combat Cycles", since EA snubbed them and they're frantically ramping up.
>>It's a competitive job market out there. Forget about not having a degree, try applying for a job at a major company with a degree from a random state school. You'll be cometing with kids who have Engineering degrees from some of the best schools in the country and could do you sys admin job in their sleep.
Hmm, yes, if I'm cometing with you, I could probably do you sys admin job in my sleep.
>>In life you have to be smart. Do what's best for you in the long run which is to GO TO COLLEGE.
I know plenty of people who aren't "smart" who are getting along just fine in life. Does our friend Anonymous Coward care to offer up any anecdotal evidence? Note also that I did not say don't go to college. I said weigh the alternatives.
>>If you feel the need to 'put together bids from various life paths', why don't you wait until after you have a degree to do so.
Um, because at that point you've already spent the capital that you would have used to pursue the alternatives. Let's see, instead of doing a cost benefit analysis of getting a Solaris/Oracle solution versus a Linux/Postgres solution, why don't you purchase the Solaris/Oracle solution and then ask Red Hat for a bid?
>> The last thing you want is to be the 40 year old tech guy with 50 certifications who gets replaced by a 22 year old from MIT with a CS degree.
The last thing you want is to be the 40 year old tech guy with 50 certifications who gets replaced by a 22 year old from MIT with a CS degree and realize that if you hadn't racked up $100K in debt when you were 20, you might have been able to pursue your dreams to be a hollywood stuntman. Now you're 40, fat, have spent your adult life as a desk slave, are going through a messy divorce, and just had your car repoed. You never did get that motorcylce because by the time you paid off your college debt you needed a minivan.
>> On the other hand, if you want to be the sys admin for a non-tech company, which will basically mean you make and manage user accounts and troubleshoot for Jennifer over in HR who can't print, you're on the right track.
On the other hand, if you want to be the part time sys admin for a small company (which basically means that you help people with simple computer problems) and flirt with Jennifer over in HR (you've seen here eyeing the harley... and April in accounting is jealous... yeah, you knew those jujitsu classes were a good idea), you're on the right track.
Slashdot Mirror
For those unfamiliar, the idea behind a honeypot password is either
I see Perl 6 as kind of a pantheon of programming gurus, and you can subscribe to whichever you like (or tell them all to screw off). The most important thing about Perl 6 is you can use whatever programming style suits you best. In a corporate environment, that style can even be dictated down by the powers that be, too. If you're one of those people that thinks that Lisp (et all) is (or is not) understandable, or thinks Java is a brain-dead C++, or that C++ is error prone Java, then Perl 6 may not be for you. You let (percieved) flaws obscure the important benefits, and as a result you miss out. Objectively, you would be examining the trade off between learning curve and increased efficiency over the time period of the project. In many cases, it is in fact better to stick with the tool you know, even if a different tool would be twice as effecient. Since it's just not possible to learn every single tool available, as professionals, we have to pick the most effective set of tools that we care to know given our interests and other expertise. This brings us around to the great thing about Perl 6: in one cohesive, sensible framework, it gives you really broad coverage. You don't have to learn it all at once--you start out using Perl 6 like Perl 5; then when you decide you want to do some lispy type things, you don't have to learn Lisp and a whole new toolchain, you can learn to do lispy types things in Perl. If you want to do things that would be well suited for C++ templates, you can learn the Perl 6 mechanisms for it instead of undertaking C++. And what is really, amazingly cool is that Perl 6 is shaping up to be a cohesive, well considered framework; it's not a jumble of competing ideas that don't play nicely with each other.
If you've worked with C++ templates and metaprogramming, then you certainly understand the benefits being offered by a lot of the Perl 6 constructs. But the Perl 6 way is much more comprehensive, direct, clear, and intentional. Everything with blocks, anonymous subs, closures, multi methods, named parameters, operator overloading, and macors offers unbelievable oportunities for meta-programming. Once Perl 6 gets rolling and starts developing its own equivalent of Boost, then programming will never be the same. Boost changed everything already, but you've probably never heard of it; but Perl 6 will have mainstream appeal, acceptance, and use that Boost will never have.
I too, have marked you as a friend. Anyway, in my opinion, there is no particular correlation between having a degree and being very good at what you do. Let me explain a little. There are some people who really love and care about whatever they pursue, and they will get good along whatever path they pursue. Programmers, artists, or car mechanics, doesn't matter. If they love it, they'll find a way--sometimes, that way is at a university, sometimes that way is in the basement, and sometimes it's teaching English in Siberia. Unfortunately, people with that kind of dedication are rare, and so you're left hiring somebody who pretty much just wants a job. Which is only fair, because you've probably only got a job to offer. No offense, but odds are that the work your company does is not very interesting.
Finally, I wanted to respond specifically to this post:
The schools shouldn't be going out of their way to graduate programmers who can't program.
I don't know of a single school that offers a Programming degree program. Some offer Software Engineering, but the vast majority only offer Computer Science. Many people fail to realize that Computer Science is basically a math program, and has very little to do with programming at all. A Computer Science program shouldn't teach programming beyond an intro course--you don't expect a math major to take much physics beyond basic mechanics and E&M. Academia is not yet prepared to admit that programming is a discipline unto itself. In my opinion, Computer Science really should be a graduate program for people who study Programming or Software Eng. in undergrad.
I don't know of anyplace in the world that you can go to and learn programming, except on your own with a book, a computer and a compiler (or interpreter, don't nitpick). Coworkers can be great--well, if you have somebody like me as a coworker. But you can't just go out and sign up for a coworker to look over your shoulder. My point being that when you need to hire somebody, you should actually think about what got taught in the program they graduated from. And, if you find somebody that's good at programming, that person *is* self-taught, even if he or she did the self-teaching while at a university while taking CS classes.
While I haven't tried the new NetBeans, I have been using the latest stable for a couple of months now for some servlet development with Tomcat. There was a HUGE improvement when I upgraded to the 1.4 Java SDK. All the repaint problems disappeared, which was the most annoying thing in the first place. I'll be excited to try out this new version, though.
If you want to see what the future of real world programming looks like, like no further than Boost. I say this because Boost demonstrates the programming techniques of the future that work on compilers available now. In theory, Boost techniques work on any standards compliant C++ compiler. Given that most compilers these days are still pretty weak on their standards compliance, the friendly Boosters have already coded a great number of work arounds so you can still use the libraries.
Something that you might find surprising, though, is that the future is the past. Sort of. The future is shaping up to be a synthesis of great ideas from the past. Functional programming and metaprogramming are making a resurgence, except this time in moderation. You see, in the melting pot that is C++, you're not forced into any particular paradigm, and you get to use what works best for each subproblem. The real beauty, though, is that only library writers really need to be experts in this multi-paradigm thing; application writers can go about their merry business relatively unaffected, except with libraries so powerful you can't understand until you've tried them.
For a sample of libraries to really blow your mind, check out
1) Boost Lambda Library, which adds lambda function capabilities to C++. This is a staggering because C++ doesn't have lambda functions (like Lisp does).
2) Spirit Parser Framework lets you write parsers in a natural EBNF type notation, without the need to run a seperate pre-processing tool like Lex/Yacc (Flex/Bison).
3) Meta Programming Library. This ones a little tougher to wrap your head around if you've never tried writing generically reusable libraries. This is a library designed for other library writers, so #1 and #2 above make extensive use of this.
4) Preprocessor Library. This is a library to help you do meta programming with the C/C++ preprocessor. See, not all inovation is coming from those new fangled template things. You'll just have to look at the examples to get why it's cool.
The best part is that, unlike Perl 6, you can use this stuff now. Play around with, see how it works. You will be stunned, amazed, awed, etc by what these people have done. And you don't have to "get it" to use it.
Want a hassle free, no dickering with the technology studio? Get a turnkey solution. Any of the major music chains like Guitar Center or Sam Ash will sell you one. Additionally, you can go to Carillon Audio to get PC systems. They are the defacto industry standard. Even if you don't need a complete turnkey system, go to Carillon for the computer; they have components that work right for audio. When I switched to a Carillon system from a homebrew PC, all my tech problems went away.
As far as software, unfortunately, there is no Right Choice these days for PC. Now that Logic is Mac only, there's nothing really competitive left. You come down to choosing between limitations. Here's my breakdown of the major software kits:
1) Logic Audio. Best all around. Has very competent built in Score editor. Has very nice built in synthesizers (some for extra $$). Comes with the best, most comprehensive set of plugins. Its MIDI programmability is outstanding, and the integration with SoundDiver is very nice. Logic Control is top notch. Very customizable (also complex because of this), interface is cluttered compared to other programs. Will work with TDM systems, if you can afford it. A lot of people use Logic as a front end to DigiDesign (ie ProTools) hardware. Can't be beat for the price if you actually use all of the components. Note that many shortcomings compared to other programs have been addressed in the latest version (6.0).
2) ProTools. If you get LE, you only get 32 tracks. That's *mono* tracks; so only 16 stereo. If you're working with synths that make stereo output, this is a severe, cannot be overstated limitation compared to all other programs. To get around this limitation, you have to fork over for a TDM system, which is $5-$10K on the low end. Otherwise, LE is great pricewise because it's free with hardware, which is hard to beat. Best audio editing capabilities all around. Studio standard, and LE has full compatability with big studio rigs. Gotta watch for Mac/PC compatability (it's easy to do, but a lot of engineers don't even realise PT runs on PCs, so they never click the check-box. This has been a real PITA for me). No score editing, MIDI is mediocre, uses a different plugin format. Even the big rigs have pretty harsh limitations on inserts/sends per channel (5/5) compared to Logic (16/16). Cleanest interface (IMO). If you don't need the MIDI/Score/Synthesizer stuff from Logic, LE definitely has the best price/performance. Oh, and 6.0 supports ReWire, I understand, and 6.0 will be available for Windows in a couple more months, I guess.
3) Cubase. A real bear to configure. I still don't have it properly recognizing my audio hardware. I don't use it much because of this. It's got nice audio editing features, it has an interesting feature to link multiple machines together to run bigger projects (I haven't tried it, so I don't know if it really works). I've never tried MIDI with it, although there's no score editor. The interface is clean, but I find it very constraining. Logic is very customizable, and PT LE just works for me (so I don't care that it's not too customizable), Cubase's interface just grates me the wrong way and I can't fix it. So I wind up using Logic and PT LE. Also, I need missing features, so it can't replace Logic for me.
4) Nuendo. Cubase's big brother, it's expensive. Targeted at movie/tv/ maybe radio/post production houses. Never used it, but as I understand it, has lots of project management features. ProTools 6.0 TDM has a lot of these features; things like different logins for different engineers using the system, and remembering preferences for each one. Very useful in a pro environment, not so much at home. Otherwise, same general pros and cons as Cubase. Nuendo 2 and Cubase SX are based on the same engine, I think.
5) Cakewalk Sonar. Main plus: it's cheap, and works well for MIDI. Does have a score editor, I think. Does not support ASIO, whic
You must have been looking at something that's about a year old. A year ago, we were just talking about it. Now it exists :) It mentions it on the "Features" page. To use it, open a presentation and select File->Export. We do not currently export animations, but that is something that we want to add for 1.1 final.
What would I have wanted to know, and what would I have made use of? The most important thing:
Nevermind that you're technically in 6th grade, demand to tryout for the 7th grade basketball team. The administrators will understand you'll be screwed next year competing against the 8th graders (and thus on into high school), so they'll help you out.
That could have radically changed my life. On further thought, that wouldn't necessarily be for the better. Maybe I would answer all my programming questions and explain some basic comp-sci. But then, I gained a lot of my independance from figuring out programming on my own. It's probabally better the way things worked out. I would love to give my 12 year old self my portable CD player and my CD collection. If I could talk to my parents, I would tell them to get me a real piano teacher instead of the boob I was working with. Here's some advice for myself:
Kid, the adults around you are ignorant. Really, really ignorant about the things you care about. Don't worry when you feel dumb because other kids seem to know stuff. They just have access to better adults. But you're getting something better, independance and initiative. In a couple of years, you'll find a programming mentor. Then, when you get to college, you'll find that you don't really like answers with strings attached. Oh, and let me teach you a little something about Relativity so you don't feel stupid when you take your 6th grade science fair project to the local university and the helpful college students point out that you got it all wrong. Oh, and take these MindStorms for your robotics project next year that never gets farther than some circuit borads and blinking LEDs.
Damn. Couldn't help myself there at the end. Now, if I could go back and be my own Dad, well that would rock.
Better: Yes. More Interesting: Yes. How many Levels: Yes. Getting into Nethack requires a little patience. Then again, so does Chess. They're both no fun when you don't know what you're doing. Nethack is miserably dull when you keep starving on dungeon level 2 and keep starting over again and again and again... What you've missed, though, is that Nethack is the deepest game ever made. By that, I mean most games make you do what the programmers' want you to do. This is because the interactions between items, actions, bad guys and such is combinatoric in nature, so games that have a fixed dev schedule only implement a tiny fraction of interactions. This is why you must find the "Magic Key" to open the door, rather than just kicking it down. In Nethack, you can kick the door down. Unless you're a tourist, in which case you might hurt yourself trying. You can also try picking the lock. This can work well on locked chests too. You might not want to kick chests open, because that can destroy some things inside (like potions in glass bottles...) You see, Nethack has been in development for a VERY LONG time by people who aren't wasting time making pretty graphics. This means that people have come up with interesting, clever, and often funny interactions for so many corner cases that you will likely never exhaust the possibilities of this game. Toss in multiple character classes, and randomly generated dungeons, and you have a game with more replayability than anything else I can think of. Oh, and it's HARD. You only get one life. You die, you start over. Makes you actually think about what you're doing, and makes all these decisions really matter. Oh, and one piece of advice for the newbie: if you're about to starve on one of the early levels, try praying, and don't eat zombie corpses.
The best advice I can give is to work with somebody else, and talk everythring through. When you're sleep deprived, the msot important thing is to retain focus. As soon as you lose it, you'll drift off. You can knock off specific tasks from a to-do list with only half your brain working, but creative thinking, problem solving, and the like will derail really fast under sleep-dep. To alleviate this, talk things through until you have a concrete to-do list. This forces you to focus, and your partner will bring you back in line if you start to drift. Once you have a to-do list, work on it alone until you get stuck. Ask for help. Talk it through. Repeat. Just remember, if your mind starts to wander, you lose.
I've done a fair amount of interviews over the last five years, both as interviewee and dozens as the hiring manager for programmers, QA people, and other managers. One of the most important things that you can learn about hiring: you get what you ask for (this is true of many things, actually). You have to understand what you need. And I don't just mean job descriptions (though I'd bet that those are a little weak, too). You need to think about the person's role on the team and what kind of personality will excel at that.
:), that's a very different personality. Next, you have to keep in mind the team dynamic--you can't just load up on one type or you'll miss a lot of angles. A room full of heads down coders will happily deliver the shittiest program you've ever seen, 'cause that's what you asked for. However, there is some inherent conflict between some personality types you have to watch for--that's (partly) why the manager has a job, though :)
b ook
For example, if you need a coder that keeps his head down and does what you tell him, that's a fairly specific personality type. If you're counting on the coder to tell you you're wrong (when you are
Anyway, we found it very useful to lable the position with a short but colorful personality description. This personality will determine how important the technical details are. For example, if you're hiring a blackbox tester, niggly details about platform differences are important (how do you examine cookies in IExx on Mac?), whereas you expect an architect to have very broad knowledge and the ability to get and understand details when needed. Here are some examples of how we might characterize the needs of our positions:
Yesman
Bullshit-o-meter
Swingman
Schedule Monkey
Mad Scientist
Maud'Dib
Professor
Mechanic
By-the-
Can-smell-trouble (ie bugs)
Programming Seal (ala Navy Seal)
a Machine
These types of characterizations are useful because your non-technical interviewer can understand the gist and help look for them. Also, you can find professionaly prepared interview questions along with guidelines for how to interpret the responses for these types of things.
Once you've got this figured out, you can decide whether or not you should ask syntax minutiae, give logic riddles or textbooky exercises, ask them to explain concepts, or ask them to tell a joke they like. All in all, if you know what you need, it's much easier to spot.
I've looked at every single office suite out there. None of them - NONE of them, have any type of automation interface.
:(
Apparently, you didn't look hard enough or you are incompetent. I thought about modding you down, but you're already up so high that I have to correct this blatant misinformation.
I have used OLE Automation with MS Office, particularly PowerPoint, developing a non-trivial application here at work.
1) OpenOffice/StarOffice offers a very capable automation interface called UNO. You can even automate StarOffice through OLE if you are running on Windows. I have not done this yet (although I likely will in the near future), but I have used the automation on Solaris (yes, Solaris!) when porting my application to that platform. It was able to handle all my needs admirably, although it would be nice if their online documentation was searchable
2) KOffice is built on KParts. In particular, here is a KDE Automation tutorial. This is a rather old document, and things have improved since then, too.
So you, sir, will be needing another ass if you expect to keep talking out of it. Seriously, though, I sort of agree with you're final point: if you actually use one of the missing features, it can be a pain to switch. You just picked a bad example feature, and stated it with too much certainty and vehemence, and I don't want misinformation like that to spread too far.
We had an MFC vs wxWindows discussion, where Qt and others were of course brought up, and it was MUCH more informative. See here.
First, thanks for replying. Seems like we'll probably agree to disagree, though :)
:)
The subtleties you have worked hard to understand and work within don't exist in other, more perspicuously designed GUI frameworks.
Mostly, the subtleties I have worked hard to learn are subtleties of GUI programming in a WIMP environment. There's pretty much no way around knowing what events are generated for various things and what data comes along for the ride. Whatever your environment is, you will occasionally need to know what the construction order is of your windows and other frustrating items. And I won't believe for a minute that there exists a toolkit worth using without subtleties.
I would rather have something behave the right way the first time than in some peculiar way to be vaguely deduced/read about.
I find that newbs tend to get confused/frustrated because it's so easy to get started with appwizard that they get misled into thinking that you don't have to know anything to make it work. A lot of them, being fresh out of school, have never done event driven programming, and are just overwhelmed by the whole model ("where's the f*#@ing main() function?!?"). These people should do some windows programming straight to the API before trying MFC or some other toolkit, because they will find any machinery peculiar and has to be read about.
I understand your affinity for MFC: once you've gone through the pain and considerable expense in time of learning it, it's hard to believe there's something else out there that's much simpler to use and equally, if not more, powerful.
Let me clarify that I do not like MFC. It has the same problem as pretty much every toolkit that I've worked with: it bundles a GUI toolkit with an application framework with a bunch of utility classes. The GUI toolkit is pretty reasonable given the windows API it has to work with. The app framwork kinda sucks, and I don't like the utility classes much. Now, while people like boost.org are working on utility classes that will rock, they're not ready yet, and nobody that I know of really cares much about app frameworks.
Finally, porting fromanything to anything is by definition more work that simply writing that one thing once.
On the surface, this seems like a truism. However, lets say that you have a tool that will save 10% of your development time if you use A instead of B, and that you already know A but not B, and you can port from A to B without really having to know a lot about B, and so you can port in about 1% of the development time. In other words, I think that given this guy's situation, it is very reasonable to expect that appwizard and classwizard will save him more time than he spends porting to wxWindows.
This is a valid point. I made the assumption that hardly anyone with this cursory a knowledge in GUI programming on windows would be creating yet another chess program for commercial purposes.
Consider the possibility that he's using this as a learning experience for a future commercial project. Not necessarily a deciding factor, but you do want to keep in mind how your skillsets will help you in the future
I think that this is a troll, although I can't tell for sure. Seems a little misinformed, at least.
wxWindows is no silver bullet, but it is very functional. All of my experience has been, "it just works." The main extra work for me in getting code to be cross platform when working with wxWindows is the different build environments. If you're a VC++ developer, then the whole Makefile thing can be confusing for a while.
You go on to rip on the autogenerated code, which suggests to me that you were having some trouble grasping the MFC framework. It takes a little getting used to if you've never done event based programming before, but apparently this guy has done MFC before, so this shouldn't be a hurdle. The stuff that AppWizard and ClassWizard generate are there for a reason, and very rarely do you have mess with any of it. On the occasions that you do have this need, then yes, you need to read the comments, and should probably get a book. MFC has its shortcomings, sure, but usually people struggle more because they don't understand the windows API programming going on in the background. If you want to do fancy stuff, then you have to know what events to handle, what the creation sequences are, and occasionally there are subtle interactions between MFC and the API. But this guy just wants to write YACP (Yet Another Chess Program), so I doubt he's going to do anything fancy. So VC++ will save him a bunch of time and not cause much in the way of headaches.
You sum up by suggesting that porting from MFC to wxWindows would be the most work and that QT would be the "least pain." I must humbly disagree. If he already knows MFC, then porting to wxWindows is quite trivial. I have not used QT, so it may also be easy, but QT has licensing issues if you want to distribute a commercial application, whereas wxWindows does not. I realize that he just wants to do YACP, not likely a commercial endeavor, but wxWindows seems like the better skill investment to me. And since you greatly misrepresent the case for wxWindows at least, so I'm dubious of your claim that QT is better.
Sounds to me like you haven't done much porting between MFC and wxWindows. I've never had an easier porting experience. wxWindows was intentially built to work like MFC to make it easy to port, and they most certainly succeeded, with the notable exception of OLE support. I ported a several man month project in a day or two, and none of it was hard or confusing, it just amounted to looking up the equivalent functions in the help. I could do the conversion much faster now because I wouldn't have to keep glancing at the web page.
If you are a newbie, then write it in MFC. Porting to wxWindows is easy--I recently ported an MFC project at work to wxGTK on Solaris, and chaning all the MFC calls to wxWindows calls only took a couple of hours for a 2 man-month project.
If, on the other hand, you are confident with MFC, then just skip it and write straight to wxWindows. Basically, if you write in MFC with VC++, you can use all the class wizard stuff to set up message maps and create stub functions, etc, and it's just faster to get it up and running if you don't know how to do this yourself. Then, you can do easy search and replace to convert to wxWindows. For example, all of your Invalidates become "Refresh," all of your CDCs become wxDC, CString becomes wxString, etc etc. You will have to make a couple of small changes here and there, but search and replace will be 90% of the work.
If you know how to set up the message maps and whatnot yourself, then just take one of the example programs (it comes with loads of examples) and start modifying to taste. There is really good documentation on the website, although I found the search capabilities cumbersome.
You say that you've taken up an interest in "Math" again. No offense, but from the sound of it, you weren't into math too much when you were younger. Odds are that the vast majority of "Math" that you were ever exposed to was mechanical equation manipulation. This tends to be tedious and very, very boring. Several people have asked, what do you want?, and I agree. More specifically, do you want to be good at manipulating equations? Or are you more interested in discovering neat mathisms that just blow your mind and permanently change your outlook on reality (and you don't mind if your mechanical skills are poor)? It will be easy to find classes to help you with your mechanical skills, and there are plenty of "fun math" books out there. There don't tend to be a lot of "fun math" classes, though hunt around and you might get lucky. The most important thing of all, IMHO, is to find a partner in crime. Pick a book and the two of you spend every other Saturday around a white board working through a handful of the easy excersises. When you get stuck, find somebody that knows more and ask. It won't take you long to get the gist of the topic. Then pick another book. Repeat until bored. You'll probably learn what you want or realize that you're actually much more serious about it within a year or two.
then C++ shouldn't scare you too much. Check out the Spirit parser library. In a nutshell, it's kind of like Lex and Yacc, but without the need for seperate tools, ie it's all done with standard C++. On the theory side, while everybody is mentioning compiler books, I find those to be a little rushed. Get a good book on the theory of computation (sorry, don't remember the name of the one I like :( ). I found their explanations of automata, regular expressions, grammers, etc etc much more elucidating than the compiler books. I think that this is because the comp theory books treat them for their own sake instead of in passing. And, of course, if you're looking for algorithms, Knuth has plenty :)
I would just point out that some of these manufacturers, like Echo Audio, do not cooperate well with the open source crowd. Go look at the ALSA list of supported sound cards before you buy if you want to use it under Linux. I have an Echo Mia card (their cheapest one), and it is good hardware for the money. The drivers under Windows had problems, though. I have recently gotten the new MOTU 896 Firewire pro interface, which is a great box, but Firewire on PCs is still touch-n-go. Anyway, neither one of them works under Linux, which is a PITA for me as one of the Audacity developers.
The basic gist of the question here is, "Is writing code on paper a fair way to test in a CS class?" To be frank, this question assumes so much that there's no good answer. Fair, test, CS, and class are so ambiguous that it will leave your head spinning if you try and pin down an objective answer. Let me run through some of the problems to illustrate:
/.ers' judgement. Effectively, you're asking, "If a measurement of coding skill obtained by writing-code-on-paper produces results that disagree with your own, does that imply a bias in the writing-code-on-paper process?" Well then, what is MY process for measuring coding skill, and is IT fair? Your presuming that there is some method that we can use to cross check the coding skill measurement. Sure, those of us in the field probably have a decent gut feeling, but have any of us measured our coworkes writing code on paper recently? Not likely...
1) You asked about a fair measurement. Measurement of what? You're taking the concept of a "test" as used for "measurement" in the context of a "class," where the nature, purpose, and significance of the measurement is effectively arbitrary--being arbitrated by those who administer the "tests." You said measurement of coding skill; however, this is not necessarily the attribute the testers intend to measure. Hypothesize for a moment, though, that all CS tests that ask you to write code on paper intend to measure your coding skill.
2) You said "fair." You then applied that word to a measurement. Generally, I would more likely use the term "accurate" when referring to a measurement. However, I think that you were referring more to the process of testing when you said "fair." What, then, is a fair process? We want to run a test, measure the results, and draw conclusions. (oversimplifying) As an emperical scientist here, we want the process not to introduce bias, or at most to introduce systemic and well understood bias. So I believe your questions translates to, "Does the writing-code-on-paper process bias the result (code) in a way that we cannot correct for before drawing conclusions regarding coding skill?" An "unfair" process would then yield incorrect conclusions even given accurate measurements and strong statistical correlation between measurements and conclusions.
3) There's the kicker, though. Given accurate measurements and strong statistical correlation between measurements and conclusions. How can you tell the difference between poor process and inaccurate measurement? Presumably, you have a way to independantly verify that the measuring device works, so let's presume that you have a computer program that performs OCR and assigns a point score (measurement) to the code (results), so that we may be certain that the same handwritten test paper always gets the same score. Now how do you tell if your process was good? Make sure that you can repeat your own tests. Then get independant verification. Now, you have to go back to your theory and explain how the results fit into your theory. Hopefully, your theory will suggest other tests that you can run that will confirm your earlier results.
4) Finally, we hit the fatal flaw in this question: we have to measure coding skill in some other way to see if the results agree with the writing-code-on-paper method. But the other method that you're appealing to here is
Anyway, you're presuming that all of the other aspects of testing are fair, and I made a huge assumption with the OCR grading program. What you get depends on the grader's mood, and other things. Also, the formulation of the questions biases the results more than anything. But that's testing for you.
You say that this is for an introductory course. Does this mean people with zero programming experience or little experience? Are you talking about high school, college, vocational, or corporate training type courses? I'm not very close to the teaching scene, and so I don't have any good pedagogical sources. Anyways, a few cautions along with my thoughts: our conceptual models probably vary widely, having mostly developed ad-hoc. Methodology, and the coincedant models, of any kind are not exactly common amoung professional programmers. Articulating the ad-hoc models that we do use, often unconsciously, is not easy. Interesting study? Very. Useful for an introductory course? I don't know your purposes, but I doubt it.
:) But then again, my peers were severely disappointed by Prolog.
So, now for my thoughts. I would couch the discussion in terms of problem solving, rather than "programming" per se. Hopefully your students are used to solving math, physics, and/or chemistry etc problems. In this context, "problem solving methodology" should hopefully be sufficiently tangible to get them thinking about it. Discuss using algebraic methods versus geometric arguments versus intuitive methods for problem solving. This is mostly just to get them thinking about the fact that there are entirely different conceptual approaches, all of them workable, but with different applicability. It should be less controversial in this context to say that there is no "best" approach, only ones that you are more or less comfortable with. Now it should be easier to present different programming paradigms as different approaches to the same problem.
Ok, now, how math inclined are these students? If you want to go after conceptual, well, you're going to hit a mathematical barrier eventually. If you can spend some time on basic set theory, and the idea of functions as mappings or projections, I would recommend it. Then, some basic algebra to get across the idea that we define the meaning of operators, but we try and do it in such a way that the emergent properties are interesting to us. And of course, I would (re)introduce them to Newton's method as a segway into algorithms. Finally, I would go over just enough logic and binary arithmetic that you can lay out a simple adding circuit in terms of AND, OR, XOR, etc. Now the stage is set without unduly biasing them towards one method. They may be severely disappointed by so much math, though
Thank you. Thank you for standing up and declaring, "I am woman, hear me, um... CODE!!" Unfortunately, I think you may be falling for the same trap as the how-can-we-hate-the-MIAA-and-still-go-see-Star-War s? crowd. /. is diverse. There are whiny boys here, there are uber-studs here, and there are guys like me. Cute girls, hot babes, and very plain women.
/., if I see you there, though, I'll buy you a drink and ask you to dance. How's that? And if you are as cute as you say, I'll even talk about something besides code, Linux, or computers ;) In the meantime, I'll be learning the Lizard Mambo :)
Now, about this party--it's 21 and over. A lot of those whiny boys are just that--high school kids and what not. They probably won't be at the party, cause guys that whine about gurls don't tend to go to parties anyway!
On behalf of all the decent guys on
This idea is, in fact, being pursued. A company in Pasadena (CA) called HorizonGOT is developing exactly such a solution. A friend of mine is their CTO, and I can assure you that they're not smoke and mirrors--they are working on getting this tech adopted in some next generation MMOs (ie, ones that are starting development cycles soon). They were actually supposed to be doing a technology demo at E3, although I haven't heard how it went.
Basically, though, these guys are much brighter than say your typical DRM inventors. They understand VM attacks, debugger attacks, network spoofs etc etc, and have clever math and encryption to fight it. This has been developed by a team of bright mathemeticians, coders, and security guys over the last 2 years or so, and I'm pretty convinced (for what it's worth) that it'll take a serious black hat effort to defeat their system. But just like anything, it'll be a game of cat and mouse; can they fix holes as fast as the black hats find them? I wish them the best of luck.
>> This response is the typical, "I'm going to try to be anti-Western but really don't know what I'm talking about".
This response is the typical, "I'm going to post as an Anonymous Coward but really don't know what I'm talking about."
>>First of all, I went to a 4 year college, as well as got some certifications as a Sys Admin, and have a job at a really good company.
Congratulations. You seem satisfied, which is quite an achievement.
>> You should never decide whether or not to go to college based on how much money you will lose by not working. It is somewhat ironic that whoever wrote this response seems to have some disdain for the norms of the western world, yet seems to be mainly concerned with money.
Money is mostly interesting with respect to what you do with it. Hoarding money is not very interesting, except to the extent that interesting things take more money than you currently have.
>> Going to college is not about money. Clearly, if you can't afford a private univesity, you may have to go to a state school or community college, but don't think in terms of, I could be making $25,000 a year, and school costs $10,000 a year, so I'm actually losing....that type of thinking is for people who don't understand education.
It's not so much about making or losing money, but about making good use of your money. If you spend $10K/yr on school, you will get certain benefits. If those are benefits that you want, and you value them more than other benefits that you could have have with the $10K/yr or $35K/yr while working, then by all means. You have made a value judgement.
>> There is more to being educated then just being able to get a job. That being said, there is NO WAY you will be able to get a good job without some type of college degree. What the degree is in may not matter, but it has to be something.
There is more to life than having a good job. That begin said, there is NO WAY you will be able to get a good life without some type of rewarding life experience. What the experience is in may not matter, but it has to be something.
>> Try going to Microsoft to apply for a job and explain to them that you decided not to go to college, but rather to buy a motorcycle and drive around for a year or two and take jujitsu and you have some Microsoft certifications you got
>> from reading a book or two and taking a multiple choice test, but you have really good sys admin experience from when you were 18. If they don't laugh you out the door, Gates himself will probably drag you out back and beat the certification right out of you.
Try going to a movie studio to apply for a job as a stuntman and explain that instead of going to college you got a motorcycle and learned trick riding and got a 3rd degree blackbelt in jujitsu and you have safety hazard certifications that you got from reading a book or two and taking a multiple choice test and you have really good extra experience from when you were 18 with a few union vouchers. If they laugh you out the door, Gates himself will probably beg you to come work on the new XBox game, "Combat Cycles", since EA snubbed them and they're frantically ramping up.
>>It's a competitive job market out there. Forget about not having a degree, try applying for a job at a major company with a degree from a random state school. You'll be cometing with kids who have Engineering degrees from some of the best schools in the country and could do you sys admin job in their sleep.
Hmm, yes, if I'm cometing with you, I could probably do you sys admin job in my sleep.
>>In life you have to be smart. Do what's best for you in the long run which is to GO TO COLLEGE.
I know plenty of people who aren't "smart" who are getting along just fine in life. Does our friend Anonymous Coward care to offer up any anecdotal evidence? Note also that I did not say don't go to college. I said weigh the alternatives.
>>If you feel the need to 'put together bids from various life paths', why don't you wait until after you have a degree to do so.
Um, because at that point you've already spent the capital that you would have used to pursue the alternatives. Let's see, instead of doing a cost benefit analysis of getting a Solaris/Oracle solution versus a Linux/Postgres solution, why don't you purchase the Solaris/Oracle solution and then ask Red Hat for a bid?
>> The last thing you want is to be the 40 year old tech guy with 50 certifications who gets replaced by a 22 year old from MIT with a CS degree.
The last thing you want is to be the 40 year old tech guy with 50 certifications who gets replaced by a 22 year old from MIT with a CS degree and realize that if you hadn't racked up $100K in debt when you were 20, you might have been able to pursue your dreams to be a hollywood stuntman. Now you're 40, fat, have spent your adult life as a desk slave, are going through a messy divorce, and just had your car repoed. You never did get that motorcylce because by the time you paid off your college debt you needed a minivan.
>> On the other hand, if you want to be the sys admin for a non-tech company, which will basically mean you make and manage user accounts and troubleshoot for Jennifer over in HR who can't print, you're on the right track.
On the other hand, if you want to be the part time sys admin for a small company (which basically means that you help people with simple computer problems) and flirt with Jennifer over in HR (you've seen here eyeing the harley... and April in accounting is jealous... yeah, you knew those jujitsu classes were a good idea), you're on the right track.