Admittedly, I didn’t read what he links to, but phrases like this one in quoted this post always really bother me:

Through the years, despite our best efforts to articulate that CS is more than "just programming,"

Trying to take the programming out of the perception of what computing practitioners do, on account of the perception that programming is boring, meaningless cubicle drudgery, is just plain wrong. Firstly because, programming is crucial to computing. Without programs, computers as we know them would do nothing but suck up electricity. And secondly, because the perception that they’re trying to shake off, that programming is boring, meaningless cubicle drudgery is also just plain wrong. Yes, you’ll probably end up spending most of your days at a keyboard in a cubicle. If you can’t handle that, go major in Archaeology or something. But boring? Meaningless? Hardly. Programming is what gives meaning to computers.

For that reason, I’m still not sure about this:

I'd like for people to understand what CS is and for potential majors who end up not wanting to program for a living to know that there is room for them in our discipline.

I’ll admit that you don’t have to program all day to do meaningful work with computers. But to think that you can avoid any programming whatsoever and be doing anything in computing other than some really basic sysadmin work (for which you shouldn’t need a 4-year CS degree anyway) is delusional. Even the guys I know who work as server admins for a hosting company have cause to do no trivial amount of scripting. Which is why the next sentence:

But pitching programming to the aside altogether is the wrong way to do that, and will do more harm than good -- even for non-computer scientists.

seems to me right-on, yet somewhat at odds with what comes directly before. Whither the “programming for everyone” meme that Gene often espouses? How do you reconcile “being able to do some simple programming is a useful skill for everyone, not just programmers” with “oh, programming? No, don’t concern yourself too much with that unpleasantness.”

You can’t have Computer Science without programming. Even if you don’t write programs yourself, I don’t think you can do much with computers if you don’t at least understand what programs are and how they work. The problem isn’t that people perceive CS as “just programming.” It’s that we’re not showing them all that programming is.

Programming, as a profession, doesn’t live in a vacuum. We don’t write programs just for programs’ sake. Nobody would be paying people to write programs if they were just blobs of symbols and expressions and statements that weren’t relevant to something outside themselves. Programs are supposed to be about something. You can’t write embedded control software for an airplane without learning something about the parts of an airplane, their purpose, how they function, and a little bit of aeronautics along the way. Right now, I know more about the licensing requirements for plumbers in the state of Iowa than I ever thought I’d care to, and I’ve come away from past projects with whole new understandings of the photography business and sports uniforms. The famous Micheal A. Jackson had an interesting piece in a recent CACM in which he articulated his belief that software development will specialize into different application domains. This makes a certain amount of sense to me, especially in very complex domains. I’m pretty sure Donald Knuth ended up being something of an expert in typography in the course of developing TEX. Knowing “just programming” isn’t enough to build a meaningful program. It’s possible that, if you’re ever really interested in learning a topic inside and out, the best thing you could possibly do is to write software about it. This ought to excite the hell out of potential students, especially the type of student I was, the type of student whose interests are so wide-ranging that they have a hard time reconciling themselves with the expectation to specialize in just one kind of thing for the rest of their lives.

The point is, even programming isn’t “just programming.” Programming is always about something else other than programming. To program is to understand something well enough to be able to explain it to a machine, and that can be endlessly fascinating.

This is CakePHP 1.2’s way of saying that one of your validations names a validation rule that doesn’t exist. You probably just misspelled it, but CakePHP made an unfounded assumption and just went ahead and tried plugging it in as a regex pattern, in order to make sure you get the most unhelpful error message possible.

This blog post is pretty much just here to give it a Google hit.

Here I thought I had ruby’s blocks, Procs, and lambdas all nailed down in my head. Good thing I decided to read this post as a review:

The second difference is that lambdas have diminutive returns. What this means is that while a Proc return will stop a method and return the value provided, lambdas will return their value to the method and let the method continue on. Confused? Lets take a look at an example.
# example-10.rb
 
def proc_return
  Proc.new { return "Proc.new"}.call
  return "proc_return method finished"
end
 
def lambda_return
  lambda { return "lambda" }.call
  return "lambda_return method finished"
end
 
puts proc_return
puts lambda_return
 
# => Proc.new
# => lambda_return method finished
In “proc_return”, our method hits a return keyword, stops processing the rest of the method and returns the string “Proc.new”. On the other hand, our “lambda_return” method hits our lambda, which returns the string “lambda”, keeps going and hits the next return and outputs “lambda_return method finished”. Why the difference?

So, would I be correct in saying that, in effect, any call to a Proc is really a call/cc? Just being my usual grouchy self here, but I feel like I need it explained to me why this is a good idea. Luckily, I haven’t had cause to run into this kind of thing yet – an awful lot of what you need Proc-related things for is best accomplished through blocks – but seemed to me upon reading this, that if you need to pass some procedure into a method, then whether or not that method has other processing it needs to do after it uses your procedure (and thus, whether it needs your procedure in Proc or lambda form) is a bit of internal details you shouldn’t have to care about. Also, if you want to convert a block into more of a full-fledged procedure object, Ruby gives you the & operator to turn it into a Proc – but what if you’d rather make it a lambda, so that you can call it without totally bailing on the rest of your method?

I get the feeling I’m totally misunderstanding something here. My guess is that the point being made is that Procs aren’t ordinarily “supposed” to have an explicit return in them – that in that context, “return” is more specifically a flow control construct, not so much for specifying the value the Proc should “return” (as in, evaluate to) when called; that intended/idiomatic Proc usage is for their value, with them containing expressions, not statements, and using only the implicit return, “returning” the value of their (last) expression. I suppose I could blame it on the expression/statement dichotomy of non-functional (dysfunctional?) programming, and its overloading of the notion of “return.”

Can anyone either confirm my guess about this or else help me understand it better?

Speaking as a developer employed by a midwestern division of a for-profit company that specializes in web development for state government agencies… I’m 100% certain we had absolutely nothing to do with this.

[via]

So mcurry’s test sample code for CakePHP works – I had to very carefully pick through my code to get it following it exactly. But it does make for much cleaner and smaller test code than the mess that was described in the docs until, apparently, just today, and that RC3 generates, and that doesn’t work.

So I went ahead and modified cake/console/libs/tasks/model.php to generate test cases & fixtures in the form of mcurry’s samples, but it seems I was beaten to the punch. In addition to the update to the doc site, RC4 has come along, and it also turns out that the current SVN version uses the ClassRegistry::init method to instantiate a model for test (as opposed to the older, crappy method of creating a derived class from it and overriding its database settings). I’d like to think this has come about so suddenly in some part due to my bitching, but even if it were so the Cake devs would never admit to such a thing, as it would make it look like they actually give a rat’s ass, which would cut into their image.

I also modified the part that generates fixtures to use the new $import method to get the database schema from your models’ tables. But from what I’m told, most still think that generating a completely redundant (and now, totally unnecessary) representation of your database schema, such that your fixtures will break if you make changes to database tables, is totally not a problem. So there’s little interest in me contributing this small change, that was so easy to do that one has to wonder why it wasn’t done sooner, to the framework. Darn. I was hoping I could join that elite club of smug developers who get to sit in IRC channels hurling insult and snark at people with support questions. As always in my life, my admission to the cool kids’ table has been denied yet again.

I’m told it’s bad form to hack core files in the framework like I did (though why some guy in an IRC channel thinks he has any reason to give a crap about what I do in my own project is beyond me), and that you should put them in app instead, but I’m not seeing a console directory under app. So if you want to use my new model baker, you can go right ahead. Download it (right-click that link, save, and rename appropriately; or, just click and copy-paste) and try putting it at app/console/libs/tasks/model.php – if the cake console doesn’t pick it up there, be naughty and jam it into cake/console/libs/tasks/model.php, I won’t tell on you.