This is stupid.

There should absolutely, absolutely be a way to wipe a corporate account off a phone. That data is the property of the corporation.

But wiping everything is just inane. There is absolutely no reason to wipe pictures, personal contacts, emails, etc. This is software we're talking about. Just wipe the account(s) in question.

The only thinkable reason to wipe data outside of the corporate account is "you could have copied work content elsewhere," and that argument applies no more to phones than to personal computers. Hell, it applies to printed material too. Had any former employers snooping through your house lately?

No, the onus is on the corporation to restrict dissemination of corporate data if the risks are too high. Allowing a remote account wipe is a luxury afforded by software, not a corporate right over personal property.

AIX's SMIT did this, or rather it wrote the commands that it executed to achieve what you asked it to do. This meant that you could learn: look at what it did and find out about which CLI commands to run.

It's been years since I administered an AIX machine but my recollection is that the CLI command strings it came up with were generally amusingly-specific unique-to-AIX commands with very long names like resizepartitionandinstallbootblock or something like that. They were generally specialty scripts built to parallel SMIT menu choices and you'd never wind up guessing the command without SMIT telling you what to use, but having the command-line version was nice because you could do something by menus in SMIT on one machine and then use the command-line equivalents to automate the same operations on dozens of other hosts.

A sincere thank you for the reply.

Respectfully, I believe you're going down a bad road. For a small application, and a developer who isn't asleep at the wheel, what you're suggesting can work OK; I imagine it hasn't been a problem for you.

Generally, for everything else, it tends to blow up down the road. And even for smaller projects, the benefits of keeping your logic out of the DB (faster, cleaner, clearer, easier to learn, easier to update) are significant.

I sincerely want to make an effort to be useful to folks who may not have worked with larger projects before. Please take this post in that spirit. It's a long, and I hope informative, post.

Make your code's intent clear ... alternatively, write logic in the right context
The biggest problem is code intent and flow control. Databases model data, GUIs model user actions, but neither necessarily model business logic. You've got business logic code for that -- like your permissions handling.

Code has a logic-centric view. Databases have a data-centric view. If you write logic in the DB, you're abstracting what you're writing from what you're actually trying to accomplish.

Error handling is a great example for flow control. Trapping an error in the DB, correctly identifying the problem and bubbling it up in a user-appropriate way in a clean fashion, as you said, is difficult.

Keep your code together
Another big problem is finding all the right code. For a newbie or a dev who hasn't looked at a bit of code in 6 months, this is very important.
Breaking your code up into different buckets based on what data it modifies makes your logic - your flow - hard to follow for anyone who isn't intimately familiar with the project.

Consider two implementations for a feature:

1) Application code triggers an update to three tables. A bunch of magic spread across several triggers on those three different tables and written in (depending on your implementation) three different schema files, or one huge file with your entire schema, updates three additional tables. E.G.: "most complex updates are performed using triggers and rules"

2) One function in one file that, in a transaction, updates six tables.

Which is easier to follow? From which implementation can you get a clear vision of the intent of the code? Which is easier to skim? If a new developer looks at your code, in which implementation is he more likely to miss something the feature touches?

Don't make interoperability harder
If you push logic into your DB, interoperability becomes harder, not easier. Before, you had just data, and two different applications could use it differently and have different requirements -- as long as what they did was consistent with the data model (your schema).

Now, with logic in the DB, anyone wanting to share your data has to work around your triggers, or co-opt them, or write entirely new triggers, procedures, and generally muck up your application to accomplish their goals.

Keep your platform flexible
Pushing logic into the DB, you may have made it easier to switch languages (although you still have a bunch of "front end" code you'd have to convert/maintain), but now it is much harder to switch databases. What was once merely data is now jumbled up with your application. If Oracle, MSSQL, etc. becomes a necessity, you're not just switching databases, you'll likely be refactoring significant chunks of your app.

Most business needs won't demand you switch languages (worst case, cross-compile or use IPC). Some business needs will demand you switch databases -- my company is now porting our app to MSSQL.

Your database is likely your bottleneck
In my experience, the first serious scalability problems most apps encounter are in the database. And the solution is always "more hardware." Beefier machines.

Then comes horizontal scaling ("moar servers plz"), which is almost always easier to do with your application than your database.

Why add more to your DB load? Write your logic in your application and run your DB on a dedicated machine. Then you're free to implement caching , an option you don't have with your logic in the DB. Then if you have scaling problems, buy beefier hardware and eventually, in big implementations, scale horizontally.

Don't complicate updates and debugging
Multiple instances of our application server can be run against the same database. This makes testing code changes or debugging a very complicated production issue possible without modifying the application in production.

When your app is built into your DB, inserting debug statements amounts to modifying production. Running another instance becomes very challenging (spare replicated server?) if not impossible.

--

A lot of people have had success implementing their applications like you've suggested. Our parent company did... and they gross in the hundreds of millions each year.

The problem is that this is 1990's technology, and it almost always grows out of small implementations (along the lines of why some terribly complicated applications use MS Access).

Ultimately, it's important that people learn why to avoid this methodology, and how it directly improves what you do - even for small projects.

Best wishes

While the database platform may have been a problem, the first, biggest problem wasn't the hardware. It was (bolded for effect): business logic does not belong in your DB, excepting a handful of cases.

I wouldn't normally have replied -- I agree with your point about hardware -- but this deserves to be underscored because so many people fundamentally do not get it.

I work for a company that was just bought out. Our new parent company develops a well known (in its industry) enterprise desktop application. The entirety of their business logic is written in the DB.

It's a maintenance nightmare, difficult to integrate with outside systems, and the system does not scale. Scalability is kicking their ass... because they can't.

Our company spends much less on hardware (and software, cheers for PostgreSQL), and our application is a billion times easier to develop and maintain. We use triggers - but only a handful.

People develop middle layers for a reason. Better code organization and flow control, much, much better speed, scalability, and flexibility.

Use a DB for what it's good at (ACID, data integrity).

So you save time on a cache/DB lookup by doing crypto processing instead ... after which your web application will begin processing the user's request... in most cases querying the database, updating user history, etc.

This seems to me like missing the forest for the trees.

Doing a hash lookup on your cached session is near constant time, avoids security holes introduced by sensitive data client-side, and avoids stacking session data on top of *every request* to the webserver.

That's not even tackling the more serious issue of trusting a user ID from the client without a password because "it's encrypted".

I am however somewhat surprised by/skeptical about this story. How did the poster's name and info get associated w/ this?

Perhaps the malfeasor(s) "borrowed" his name from the contact information in his company's bona fide domain registration?

thus something invented by us is more likely to cause serious trouble for our metabolism than something that bees or trees invented millions of years ago.

I've got some foxglove growing out in my yard if you want to test that theory.. And if you survive that, there's a local amanita variant I can probably find without too much trouble if I go looking for it.

While I think the statutory damages here sound excessive, if it really gets to be a problem the legislative branch can easily pass an amended statute correcting that. Meanwhile it does seem to be desirable to have some disincentive in place to prevent manufacturers from claiming the protection of expired patents. A better system might require a company be served with notice to stop claiming the patents, giving them a reasonable amount of time thereafter (30 days?) to correct their manufacturing; any devices produced after the grace period would be subject to penalties if patent protection continued to be falsely claimed.

It probably wouldn't be such a problem if we hadn't gone absolutely patent crazy in the past fifty years. I made a ludicrous discovery the other day while replenishing my toilet paper supply. The brand of TP I had purchased claims no fewer than 36 patents on the packaging, and I believe that's not even counting the additional design patents (or at least I presume that's what the series designated D########## represented.) C'mon, really -- 36 patentable innovations? It's toilet paper.

Some of the responses so far seem to be based on the assumption that this is an information technology class for students who intend to specialize in the field. I'm assuming, rather, that this is intended to be a basic primer class offered to everyone and intended to give a general grounding in the subject.

My suggestion is that you start by talking to adults to find out what they do and don't understand about the technology they use. In my experience (20-some years' worth of dealing with end users in various capacities) many, probably most, adults have an extremely limited idea how the technology they are using really works in the physical world and deal only with it as an abstract unit. And some of the assumptions they make based on the mental model they have built up lead to really bad decisions because they don't understand very basic concepts that the rest of us take for granted.

To give an example: perhaps the single most misunderstood concept I encounter is the notion of storage. A great number of people seem to have no idea what actually happens on a computer when they save something. Generally they don't understand the difference between various types of memory (i.e. the difference between temporary short-term storage in RAM and long-term storage on a file system on some sort of disc or flash device. They have a very limited understanding, if any, of the filesystem and the concept of hierarchical organization. They are generally unable to distinguish between the various components of their system (e.g. display, CPU, input devices, file storage.) These are things that seem idiotically simple to most of us because we have completely internalized the knowledge, but deal with people who don't have the same underlying framework and you will soon see how it affects their reasoning about their computer.

People with this sort of limited understanding of the computer as one abstracted whole, a magic box that they interact with, generally get along adequately as long as everything is working the way they expect but as soon as they run into any sort of exceptional circumstance they have virtually no recourse because they have no real understanding from which to base hypotheses about a possible cause for the problem or method for proceeding. Their ability to use their systems is therefore fragile and subject to disruption from virtually any sort of unusual situation.

If you've worked in the field you've seen this over and over and over again and you can probably call to mind some of the unfortunate results of this kind of shallow understanding and "magical box" mindset.

I think the best thing you can do for kids just getting started (though I think 9th grade is pretty late to be getting started) is to help them understand that computers are not magical and that their behavior is not arbitrary, that with the proper basic understanding of what's happening most of what follows can be predicted by fairly straightforward logic.

Heh. I live in Texas, one of the few "deregulated" electricity markets in the US.

Our local power lines are owned and maintained by regulated monopolies which set prices per area for monthly maintenance fees.

Power companies then contract with the local infrastructure owner to provide power to the grid. And as a homeowner, I choose which power company I give money to; I pay them for how much electricity I use from the grid, and they generate the electricity. I also pay the maintenance fee passed from the local owner through my power company.

When I chose a power company, I was able to look up JD Power reviews and pick the best company. I had a choice.

How many people can say that?

I think Larry might disagree with your assertion that Perl was meant to be used in a specific fashion.

It might be worth clarifying: Perl is great to learn, but terrible when you work on code written by people who don't think like you do.

Perl code can be simple, straightforward, very easy to pick up and hit the ground running. It's when you start coding with other programmers that it becomes painful.

The problem resolving this issue in the language design is that people will code they way they think, regardless of your restrictions. What happens when you put a C developer in a Java shop? Instead of writing beautiful, flowing OO code that glows with elegance, they'll write clunky, low-level functional code that steps through their thought process procedurally.

Ditto if you put a Java developer in the world of C. They'll prefer to write large data structures and significantly abstract their code, which will drive a lot of C developers nuts.

My point is, I think the result of requiring a programmer to jump through language hoops often means the resulting code is not only written in a different style, it's now obfuscated further because the programmer dodged your language hoops to do it.

--

I will say, however, that some Perl programmers happen to really love their esoteric, obfuscated language tricks, things like this. I definitely see what is being accomplished -- implicit but short code is often easier to skim and understand than long and explicit where you lose the meaning -- but I think Perl hackers tend to take this much too far.

Sarbanes-Oxley? Really?

You fight for this nonsense, thinking that it restricts big corporations. It does. ...just like everyone else. Including, and *especially*, newcomers.

Who does it really affect more? The company with a professional staffed legal team, entire departments dedicated to training, procedure, and lots of liquid assets to cope?

Or the little guy?

Spend some time thinking before you "shoot the buy guy to make things even." You're aiming at everyone.

I always thought the ME2 minigames were pretty well designed. (The hacking & bypass). They felt thematically related to what you were actually trying to accomplish, they required a modicum of effort (that could be reduced by in-game purchases), and they generally provided a nice reward for doing them.