How do you know? Are you a rocket scientist with a second degree in EE? Dare to show the diplomas?

Could be configuraion syntax. Simple, readable, concise, possible to understand even in very complicated scripts without looking at the manual. I'm using iptables routinely, but I liked pf for its simplicity.

In regard to the placement of the business logic, I think the truth - as always - lies somewhere in the middle and contains a disclaimer to the effect of "not applicable when implemented by morons" and "common sense not included".

Sometimes, the application is all about data and most aspects of the business logic can be summed up as maintaining data integrity. For example, a typical bulletin board updates various counters and lists every time someone posts something - the post counter for the user, the topic, the forum and the category, information about the latest posts for those entities, maybe lists of unread posts for the users (depends on wether those lists are inclusive or exclusive) and loads of other things. Most of those can be moved into triggers, maybe even views with rule-based updates of the actual data, with a great benefit for interoperability. In fact, I did co-author one such bulletin board and the decision to move as much business logic to the database as sensibly possible (and not a thing more) turned out to be correct. Right now, we're implementing some auxiliary functionality in Python (the original code is PHP) and it couldn't be easier. Just about everything is selected using views (which will get a dramatic speedup once I move everything to Pg9, which supports join removal - not that it's slow right now, just noticeable on the server load graphs) and most complex updates are performed using triggers and rules, so the frontend code can be kept simple, and even major updates to the actual business logic and data structure can be contained in the database and completely invisible to the outside world.

There were, however, things that I kept out of the database on purpose, generally due to poor state of interoperability of database engines and programming languages (which is kind of strange, considering that relational databases are such a damn old and mature technology), primarily when it comes to errors. The most prominent is acces control logic. I could engineer the database so that it just refused to accept a post in a forum where the author had no write access (while retaining the possibility of revoking him the access he had and keeping posts he wrote to date without any data integrity problems, of course), but I couldn't think of any elegant, sensible and clean way of turning complex database-generated errors, such as those thrown by constraints or manually in the pl/SQL code, into appropriate exceptions in the application and keep everything in line with transaction handling at the same time. I tried and what I came up with was a sorry kludge, so I just gave up and kept those bits outside of the database. Of course, that meant I had to reimplement some of this in Python and now I have to remember to update two codebases, but the code is simple enough that I can put up with this.

Of course, everything's documented, both in text and diagrams, just in case someone would inherit the code down the road. It's been quite helpful right now, too - there are parts that Just Work and the last time I even looked at the code was a few years ago, right now it is kind of new and unknown even to me when changes are to be made.

In short, I don't think this is about some holy rule that is unconditionally true and you have to "get it" or else. IMHO it's about common sense, practical knowledge in neighboring fields (you're a DBA and you don't know how a CPU cache, a memory controller or a physical hard drive works? Well, you're not going to be a good DBA for high-performance systems, regardless of your knowledge of databases) and experience. All of those together, not just one or two. Only then rules become just guidelines to step over when appropriate.

Besides, with Pg9 and its stream replication and hot standby mode, scalability just shot up through the roof and stopped at about the actual limits of the hardware, where contraptions such as the battery-backed RAM "disk" for WAL store I mentioned earlier come into play to push it even further.

An idiot prepared the server hardware requirements, then. A simple PCI-E card with a few RAM slots, a LiIon battery pack and a faux SATA controller (they are available from a few vendors and cost a few hundred bucks a piece, pretty cheap for such a thing), configured as the WAL store - the database had a write-ahead log, right? - would increase the capacity of a single such server at least tenfold.

The problem wasn't that the databse was used in a wrong way. Rather, it was a lack of a systems integration person in the team, who grasps all the general aspects of the deployment from the frontend down to the bare metal and can identify such problems and find remedies right when they occur.

There is. Sample at twice the Nyquist frequency of the recorded signal and a sample size that gives a sample resolution a tad bigger than what the recording equipment is capable of registering - measurement error formulas from the theory of metrology are your friends, coefficients come from the instruction manual for the microphone. You do know that an analog microphone doesn't have an infinite recording quality, right?

netstat -lpn seems simple enough. I tend to run it every time I change something in a configuration file of a network-enabled service, just to be sure. It would be irresponsible to do otherwise.

If you do, then surely you must have made an educated, conscious decision and made yourself aware of all the consequences? It's not like the GPLed code is not labeled as such - more often than not it's almost over-labeled, with a full notice in every file. What's the problem, again? Don't like it - don't use it. How could it be any simpler?

Do you even know anything about this language beyond status bar text scripts and document.write? ECMAScript, the actual language we're speaking about (as opposed to the language/standard library combo JS actually is) is a sophisticated mix of functional (good for event-driven code) and procedural (good for general-purpose code) programming features augumented with prototype-based OOP (allows for a decent DOM implementation). The design is not as good as Python's (IMHO), but it's second to it in allowing programmers to write clever, concise code that does its job well. And the "standard library" that makes JS what it is, is actually DOM.

Unfortunately, the world is full of people who don't even know what functional or procedural programming means and write utter crap in JS, usually thinking that it looks similar to C, so it can be used like C (and it cannot be, because functional features will trigger "unexpected" behaviour), or not thinking at all. This doesn't mean that the language is bad. You could as well say that HTML and CSS are bad because millions of morons are abusing it constantly. But it's not HTML, CSS or JS that are bad. It's the countless "tutorials" written by morons for morons that perpetuate bad practices and monkey-like code copying without a tiniest thought about what the code actually does and how. I'm afraid, however, current technology doesn't let us make compuetrs that stab people in the face for writing crap tutorials.

MVP stands for Model-View-Presenter. What differentiates a Presenter from a Controller is that a Controller creates an appropriate model (or models) and a view of some kind, connects those together and tells them what to do. It might also do ACL checking and the likes before. Then, the view fetches data from the model(s) and displays it (for a very liberal value of "display", as might be the case with, say, an RSS feed generator). That's right: the view is an active element of the system, usually implemented as an object using some kind of a base class just like the controller and it can access the model. Of course, the model should be strictly read-only for the view - all things good and sane are lost for the application when some moron calls a method of a model that modifies data from inside the view. A good framework might employ safeguards against this, but a good design comes first to protect against such idiocy. One could argue that the view just becomes a second controller with a different set of responsibilities, and it's actually an interesting and somewhat reasonalbe point of view, but that's just what MVC really is.

The Presenter, on the other hand, does not relay the model(s) to the view and tell it what to display. Instead, it fetches *all* the data itself and spoon-feeds it to the view, which is usually a purely passive construct. As a side effect of this, the Presenter is usually involved in some presentation-related data postprocessing such as pagination and sorting, that a Controller should never do. Hence the name. On the other hand, this allows for a "dumb" view, such as those used by CakePHP - it's just a bunch of HTML files with embedded PHP snippets that display the data. Much less flexible than MVC, but also much simpler to implement and use.

Of course, neither is better than the other. They're just two somewhat different variations of the same idea, each with their own advantages and disadvantages. The only problem is that uninformed people call MVP "MVC", which is plain and simple wrong and indicates some degree of ignorance of the subject, which is never a good sign.

Personally, I'm using a hybrid solution that will invoke an MVC-style, class-based view when it exists and fall back to MVP-style spoon-fed templates otherwise.

No, a random delay just makes it harder for an attacker to determine the nect correct character. The exact theory behind eliminating the random factor eludes me, but several smart people found a way and it's supposedly correct.

I think the proper way is to "pad" the time so that it's constant. Say, if the password checking algorithm can take from 50us up to 600us, pad it to 1500us (safety margin!) with as much precision as posiible. There might be other code paths to pad, too, such as the one that fires when there's not even such a user, but you still want to display the "wrong password" message, as some systems do.

And when they pass this, ask them to define MVC. If they start describing MVP (which is used in just about every single web application framework out there and labeled "MVC" in the code and documentation), you'll know that something's wrong. If you fall for this yourself... Well, you'll know something is wrong on a yet more basic level.

You'd have to behead them first, otherwise they're going to be too buoyant. And then you'll be right where you started, just with the lawyers' heads instead of plastic pieces...

It's an European research project that studies social interactions of robots and people, and attempts to get around the uncanny valley, among other things. They already have some quite interesting results, although I can't really elaborate on their scientific side, social robots being outside of my field of interest.

Disclaimer: I know a few LIREC members personally.

It is not if you know the teory behind finite state manichnes and their use in writing parsers. Just about every Somp Sci and software engineering department in the world includes those in the curriculum.

Actually, any other 4-op calculator implementation than a simple, formal FSM should be a red flag for the recruiter.

There's no such thing as a "basic microcontroler". There's so much variety amon microcontrollers that your question almost makes no sense.

An ATmega88, a lower-end uC, costs $0.50, measures about 10x10x3mm and consumes less than 15mA at 5V when running at full speed, which is 20MHz and less than 250uA at 1.8V, 1MHz. With a few kilobytes of RAM and a few more of flash it might look like a joke, but a skilled programmer can implement quite a lot on one and it will work on a single AAA battery for weeks. Years on a sealed AGM.