Simple: you can't. That's the way it's supposed to work. Look to Europe where chip-and-PIN is already in use. There the rule is that if the transaction was authorized by chip-and-PIN then the charge is deemed valid and the cardholder's liable for it, period. You don't get the option of disputing it as fraudulent. And notice that the announcement was that banks and merchants would be liable for fraudulent charges if they don't transition. That implies that they won't be liable if they do transition. And who's left to be liable if the banks and the merchants aren't? This is an industry that acts as if security breaches aren't the problem, the public knowing there's been a breach is the problem. I can easily see them deciding that fraud rates going down because transactions can't be disputed is just as good as them going down because there's less fraud, and a whole lot easier to arrange since the legal precedent's there already (debit cards, which use a PIN to validate transactions, already leave the cardholder on the hook if a valid PIN was used on a transaction).
Same difference. To the user, you're the guy who tells the system what to do by writing the program that tells the hardware what to do. If you can't handle being the engineer responsible for making the machine, you aren't a programmer.
Actually you can't tell your car to start by turning a key. Turning the key starts a complex series of interactions between the fuel pump, fuel-injection and air intake systems, ignition system and starter motor to get the engine turning over and then to manage disengaging the starter motor and switching from battery to alternator power once the motor's running until you let the key go from Start back to Run. You can ignore all that and talk only in terms of the key being turned if all you want to do is drive the car, but if you need to say diagnose why the car won't start or figure out why it's running rough and has no power you need to delve into the complexity behind just turning the key. You can no longer ignore it and abstract it away. That's the key: not whether it's code or a mechanical system, but the degree of abstraction involved. Most programming languages are seen as complex because they dive below the level of "start the car" and work at the level of "OK, how exactly do I design the drivetrain of the starter motor so it'll rotate the engine crankshaft until the crankshaft starts turning faster than the starter motor is, then automatically and instantly disengage so the engine won't strip the starter motor by trying to turn it faster than it's safe to?" (and that's just one small part of what's needed to make turning the key start the car, and not even the most complicated part).
So-called "visual programming", which is what you're wanting, is great for relatively simple tasks where you're just stringing together pre-defined blocks of functionality. Where you're getting bogged down is exactly where visual programming breaks down: when you have to start precisely describing complex new functionality that didn't exist before and that interacts with other functionality in complex ways. It breaks down because of what it is: a way of simplifying things by reducing the vocabulary involved. It's fine as long as you stick to things within the vocabulary, but the moment you hit the vast array of things outside that vocabulary you hit a brick wall. It's like "simplfying" English by removing all verb tenses except simple past, present and future. It sounds great, until you ask yourself "OK, now how do I say that this action might take place in the future or it might not and I don't know which?". You can't, because in your simplification you've removed the very words you need. That may be appropriate for an elementary-school-level English class where the kids are still learning the basics, but it's not going to be sufficient for writing a doctoral thesis.
Even if there's a zero-day exploit, how is it going to attack the machine if the exploit code isn't run? I suppose theoretically there could be a bug in the filesystem code that could be exploited by a suitably-malformed filesystem structure to cause code to be run when the filesystem driver tries to interpret the filesystem structure when mounting the volume, but I haven't heard of one of those in ages. Beyond that, unless you've misconfigured your system to automatically execute code from a just-mounted removable device there's not going to be any code run. And in this day and age, if you're still allowing automatic code execution when removable media's inserted you need your fingers smacked and your sysadmin license taken away. Autorun and Autoplay are the work of the devil and should be disabled on sight.
As far as whether the office is secured or not, that's the responsibility of the software the office uses. Since they're required to use software that meets legal minimum standards, my assumption is that they do. And in any case, whether it's secure or not is out of scope for the task at hand which is transferring data from the office to the patient. I'm not writing the medical-office software itself, after all, and probably you wouldn't like my comments about current systems if I were tasked with writing it.
For e-mail clients, I dunno. Everybody I deal with uses one, and webmail's treated as an insecure alternative to be used only when you're out of reach of your normal computers. Anyone working with Microsoft e-mail clients has automatic encryption/decryption built in (and in fact it's fairly straightforward to enforce automatic encryption of all e-mail in Outlook and handle the automatic generation of key pairs when adding users). It's only hard in the sense that locking a car door's hard if you refuse to use the Lock button. C'mon, this is the 21st century, we're not talking about people who didn't grow up with computers anymore. If you're not over 65, the space program and computers and the like are things that were around when you were in high school at the latest. For me personally, pushing 50, computers were a part of business from the day I was born and you couldn't graduate high school without at least one class in how to use and program them. If I can understand how to set up encryption in an e-mail client, there's no excuse for a generation that grew up with smartphones and the World Wide Web and broadband Internet access to not be able to grok the concepts.
Plugging random flash drives in is entirely safe. It's just not safe to run content that's on them. But no system I build will run content from a removable drive when the volume's mounted, and for an application like a medical office system users wouldn't be given the opportunity to run anything directly either (they're running the medical office application, they have no reason to access the desktop at all). As for going through e-mail in plaintext, a) that's what the S/MIME and/or PGP encryption built into every major e-mail client's for, and b) you mean you have mail systems that aren't running SSL/TLS end-to-end?
Perhaps the system can be made more complicated, but I fail to see the reasons for it other than to comply with artifical requirements designed to complicate it. Within the doctor's office the information's already secured. Within the patient's computer, the patient's responsible for it and however they handle it's presumably acceptable to them or they wouldn't be doing it. And safely updating an XML file on a flash drive without exposing the system to risk is a problem that was solved back in the early 80s when I was in school. Ditto securely transmitting documents via e-mail. And a webapp I'd handle by having it do merging only with the data actually stored on the patient's machine, that way there's nothing on the server that needs secured outside the context of processing a single request.
Writing a system that actually stores patient data, that's at least 2 orders of magnitude more complex. But why should I go into that when the task at hand's letting the patient have the data and the doctor's own records system has already suitably handled the storage problem on the doctor's side?
I'm of the opinion that, alongside making it easier for medical providers to exchange information, it needs to be standard for the patient to get that information in a standard form that they can keep and give to medical providers directly. I know a lot of the data's complex, but in most cases it's written down in free-form text in the notes in the file and most other physicians can grok what the notes say. It should be feasible to have a standard XML format (UCSD allows me to download my record in a standard XML format already, so there's at least a starting point somewhere) that doctors can generate from their own notes and records and just give to the patient (adding it to a file on the patient's USB flash drive, or e-mailing to the patient to integrate themselves), and when the patient goes to another doctor they can just give them a copy of that XML file and preso, the doctor has the full record even if they can't exchange data with any of the patient's other doctors.
As far as integrating new entries into the patient's file, it's not that complicated. It's a sequence of records each of which has a creation timestamp, no need to look deeper inside each record, and new records are just inserted into the sequence at the correct point to keep the creation timestamps in the record in order. I can write a C++ or Java or C#/.Net program to do that, the basic logic'd take me an afternoon and the GUI part maybe another day or two. A webapp that'd take two or more XML files in and give you back a single merged file would take a bit longer, mostly to secure it against attack, how much longer depending mostly on whether you're leaving storage up to the user or storing a copy of their file for them (with the attendant work to keep personal information from walking off). That's assuming the file's for interchange with providers, formatting records for display and manual entry of records would be where the hard work would be and most providers already have computer systems they use for their own records that already handle those tasks.
My response when someone says it's an unwritten rule is "So, where exactly is it in the rules?". And when they repeat that it's an unwritten rule, I say "So, it's not actually a rule then. Good, that means I'm still playing by the rules.". It's the same as the Redwood City team's use of the full-court press: entirely within the rules, it just violates an unstated agreement not to play at 100% the entire game. Sure it comes as a shock when you're suddenly faced with a team that doesn't back down from 100% ever, that doesn't back off and give you position. But is it really their fault that you're not ready for that? You can do the same thing just as easily as they did. Is it really reasonable to insist that they play the game the way you'd like it to be played, as opposed to the way the rules say it should be played?
NB: the above is why, in friendly card games, the groups I played in had explicit rules about checks and calls and minimum bids/raises to keep the game moving (and maximum raises to keep someone who's up from buying the pot).
For taskbars, it's because they aren't necessarily a waste of space. If I've got a lot of windows open simultaneously (my "normal" workload's varied between half-a-dozen and 40-50 simultaneous windows over the years) they're invaluable for displaying the available windows so I can switch between them quickly. Not everyone uses just one application at a time, remember. They also provide a convenient place to put the root of the menu structure that lets me access less commonly-used applications without wasting tons of screen or desktop real-estate. And finally they provide a convenient place to put small always-on applications that can be compacted into a single icon when I'm not actively using them (think password managers, IM programs, e-mail clients and so on). We have the three options because not everyone needs taskbars available in quite the same way and not everyone has the same size monitor, and those options correspond nicely to obvious ways of having the taskbars behave (always visible and available, quickly visible when you need it and hidden the rest of the time, or out of the way and not showing itself unless deliberately asked for) depending on personal preference and how often you're using things on the taskbar. Providing those options means I can have it my way and you can have it yours and neither of us causes headaches for the other. Which is IMO the mark of a good UI.
The complaint, though, is that people aren't using Javascript as a carpenter uses a hammer. They're using it like a carpenter would use a hammer to mill and tool a high-performance aluminum engine block. Of course your first thought would be "DUH! A carpenter's hammer's the wrong tool for that job, you need a CNC mill for that.". Which is the complaint's point. And we already have plenty of the right tools for that job, the problem is that Javscript developers go "But those tools are too complicated!". No, it's not the tools that're complicated, it's the job that's complicated. That's not what they want to hear, though.
Bear in mind that if you can approach a problem and work through it logically, you are not an average developer, not by a long shot. The ability to do that puts you in the top 25% of developers right off. Witness the question over on Ars Technica where a developer seriously asked, in essence, why we divide applications into modules with defined APIs and hide the implementation details of a module from the components that use it. This... should have been covered way back in introductory programming classes, and anyone who's been developing software for any length of time should be able to rattle off the reasoning behind it. Yet here we have Jason Swett writing Web applications without enough understanding of the concept to know why we do it that way. He's typical of at least half the developers out there today: they do cargo-cult programming, following a set of directions without understanding what it is exactly that they're doing.
1. You shouldn't need to be an expert in contract law and negotiation to learn to be a helicopter pilot or take classes at a private business college. The regulations are there to give a standard framework so students don't already have to be lawyers.
2. No contract can prevent one party from breaching it. They can only provide remedies after the fact, and that's no use if the party you could get anything out of is long gone and can't be found. Regulation can do things like force the creation of a separate account with the state limiting the school's access to it (ie. the bank won't let the school's operator withdraw the funds if they want to scamper) to cover refunds if the school closes. A private contract could only do the same with a bit of fairly complex escrow accounts, see point #1 about us not wanting students to have to already be lawyers just to take a few classes.
It isn't "merely" a bad contract. Suppose the contract did have a provision in it requiring the school to refund the tuition. What good does that do? The student can go to court and get a judgement, but the school's still closed, the classes still having happened, and the money's still gone with nothing in the school's assets to pay any judgement out of. And no contract terms in the world will prevent the operators from just pulling up stakes and skipping town with the money,
This is why the scam artists hate the regulations so much. Among other things, they require the school to set aside a fund, held in a separate bank account and untouchable by the school for any other purpose, dedicated to covering tuition refunds if for any reason the school can't make good on it's end of the bargain. The scam artists can still pull up stakes and bug out, but they can't take the money with them.
I did. But since the sites were coded for IE6-specific weirdness, they wouldn't render right in FF (even assuming I installed a user-agent spoofer to get around the check many of them did). So I used FF for external browsing, and IE6 for the web apps I had to use day-to-day.
Exemptions to the CPPEA 2009. Notice the big one: schools charging a tuition of $2500 or less. That should outright exempt a lot of places once they file the right paperwork. The target of these regulations isn't the small places or pay-as-you-go classes. It's places like Silver State Helicopters that take in large tuition payments and then evaporate without delivering classes. That's why the regulations are light on teacher qualifications and heavy on the financial aspects of the schools and their owners including things like the required tuition recovery funds.
One name: Silver State Helicopters in San Diego (technically El Cajon, but close enough). In 2008, 1 year after the previous regulation of private postsecondary schools was allowed to expire, they closed their doors taking the $70,000 per student in fees that'd already been paid and leaving the students out the money, often with the student loans for the tuition hanging over their heads, with no classes and no arrangements made to deliver the training the students had paid for. They weren't the only one, either. Another private business "college" in San Diego did the same thing that same year, tuition wasn't as much but it had a lot more students and again all of them were out the tuition and the school didn't make any arrangements for delivering what the students had paid for.
This didn't happen under the old regulations, and it stopped happening once the new regulations went into effect, because the schools' operators could be held legally liable for the costs to students. I'd say the historical record leans toward the regulations being necessary and a good thing.
It's a vicious circle. At my former employer we were on IE6 because several of our critical Web applications only worked correctly with it. And since we were locked into IE6, any new Web applications had to work with it as well which removed any pressure to update. The only way we'd've gotten resources allocated to update those few ancient Web apps would have been if some other business-critical Web app had abandoned IE6 support entirely and said "IE 8 or later or we don't work". Which they won't do because they don't want to risk losing their IE6 user base. And round and round it goes, like a pair of orbiting black holes.
My first thought is that Adobe wants CSS Regions to be able to do print-media-style page layout, missing the point that the Web isn't a printed magazine. You don't know how big your target display window is, you don't even know whether it's landscape or portrait. You don't know if the viewer can even see images at all, nor if they can see colors correctly (look up the percentages of the population with various types of color-blindness). So why are you trying to be so precise about layout with so many unknowns in the mix?
I truly hate Web sites that force a 3-column layout with narrow columns that don't flow to the width of my window, or that flow the advertising material and leave the content narrow and on a dozen different pages so I'm forever clicking "Next" to keep reading. I have a large monitor and a wide window for a reason. My browser has a scroll-bar for a reason. Constraining me to a magazine's column widths and pagination is completely missing the point. I'm there for the content, and when layout becomes so complex and cumbersome that it's interfering with the content you're Doing It Wrong.
That one used a physical driveline, though. Running a generator you don't spool the turbine up and down. It stays running at a mostly-constant speed, spooling up and down only with long-term demand, and you divert electric output from the drive motors to battery charging when stopped. If you need sudden acceleration, like starting from a stop, you draw power from the battery while the turbine spins back up to handle the load again. And fuel economy solves itself mostly with not having to constantly change the turbine's operating speed or stop and start it, plus you're not having the losses due to the complex step-down gears to get shaft RPM down to driveline RPM (there simply is no way to step down 20,000 RPM to 20 RPM that's both compact and efficient).
The problem with electric cars is the battery: high weight, limited capacity and thus range, hazardous materials which make replacement and disposal a headache. But, electric cars don't really need a battery, they need a source of electric power. Turbine engines run a lot cleaner than piston engines, have better fuel efficiency and run on a much wider variety of fuels, the problem was always stepping down the shaft speed to something a physical driveline could use. It's a lot easier, though, to run a generator at the high RPMs a turbine shaft naturally runs at, and a generator supplies electric power. I get the feeling the next step won't be pure-electric cars, but a hybrid with the conventional piston engine replaced by a small turbine and generator. That would reduce the demand for high-priced fuels, and also reduce the size of battery packs since you'd only need one with a ~20 mile range to cover short hops where it wouldn't be efficient to spin up the turbine.
Turbine start would be easy: any generator is in principle also a motor, and since with no fuel being burned the turbine shaft isn't under load it shouldn't take too much power to spin it up enough to start. I'd imagine this'd make them really popular in northern latitudes where getting cars started in the winter is a bear. A turbine would be easier to start, plus would immediately start providing heat for the interior and defrosting.
Big practical problem: that would require you giving away all the details of your product without placing the patent troll under any legal obligation not to give them out to others. From a legal standpoint they're also not under any obligation to answer your query or evaluate your claim that you infringe, so they could just bin your letter and wait without any legal penalty. You'd have to actually make a claim against them to start any sort of clock ticking, eg. by filing to invalidate their patent on the grounds that your material is prior art. The system's currently tilted very much in favor of ambush tactics, you pretty much have to wait until they start to move before you can draw them into a trap.
Prerequisite for a declaratory judgement though is that the patent-holder has to have already made claims that you infringe sufficient to make you reasonably fear being sued by them. But sometimes the would-normally-be-the-plaintiff won't actually come out and sue, they'll just dance around and threaten without ever coming out where the defendant could defend themselves. Think a patent-holder going around to investors talking about how you will be sued and lose all your money, convincing investors to avoid you without ever laying their claims on the table where you can refute them. A DJ action's the way the defendant in that kind of situation can force the plaintiff to stop evading and either make their claims or admit they don't have any.
Note that the burden isn't entirely on the patent-holder. The party bringing the DJ action has to prove that the patent-holder's either actually threatened to sue them or has made public statements sufficient to give them good reason to believe they will be sued. You can't bring a DJ action just because you think they might sue you, you essentially have to show based on their statements and actions that a reasonable plaintiff should have already sued you.
Fairly hard. One of the requirements for asking for a declaratory judgement is that you have to either have been sued or have a reasonable fear of being sued by the patent-holder. If the patent-holder hasn't actually sued anyone yet, it's easy for them to v get DJ actions dismissed. Even if they're sued others but not sued you, traditionally it's been easy for them to argue that you don't have any reason to believe you'll be sued yet (not that that is not a promise not to sue you in the future). In this particular case Medtronic sustained their DJ because Mirowski had already put it in writing that it believed Medtronic infringed the patents, and if they do then the next step if Medtronic didn't agree would be to sue.
The article isn't clear, but my first thought is that this should be simple to deal with by just revoking permission for a site to use the mic. Except that when I check in Chrome, there's no way to enable this at all. The only references involve adding the Chrome Voice Control extension, which isn't included in Chrome by default. So while this is a problem, it doesn't seem to be one that can't be easily solved. If you're truly worried about it, don't install the extension or remove it if you've got it installed. If you want the extension, be careful of which sites you grant permission to and go and manually revoke permission when you're done. You ought to be reviewing permissions regularly anyway, not just for this but for anything you're granting extra permissions for.
If it's a publicly-traded company, the stock price going down too badly long-term makes bad things happen because the stockholders are going to be upset and will want something done. If management isn't aware of how the stock's performing and why and don't have plans to deal with any declines, the company's not long for this world and I don't want to go to work for somewhere that's just going to be broken up and sold off. And if management and the employees don't know what the perceived weaknesses and strengths of the company are, how are they expected to exploit the perceived strengths and correct the perceived weaknesses?
You don't obsess about it, but you'd better damned well be aware of it.
Consider my response to that: "Oh, I already know how it's doing. I did my research on your company. I want to know if you know how your own company's stock's doing, and how your view of it matches up with the analysts' take on your company.". If the interviewer's willing to BS me about the company's performance and how it's handling itself, what else are they BSing me on? And if they honestly don't realize how their company's performing, I have to wonder whether there's some fundamental dysfunction that I may not want any part of.
Slashdot Mirror
Simple: you can't. That's the way it's supposed to work. Look to Europe where chip-and-PIN is already in use. There the rule is that if the transaction was authorized by chip-and-PIN then the charge is deemed valid and the cardholder's liable for it, period. You don't get the option of disputing it as fraudulent. And notice that the announcement was that banks and merchants would be liable for fraudulent charges if they don't transition. That implies that they won't be liable if they do transition. And who's left to be liable if the banks and the merchants aren't? This is an industry that acts as if security breaches aren't the problem, the public knowing there's been a breach is the problem. I can easily see them deciding that fraud rates going down because transactions can't be disputed is just as good as them going down because there's less fraud, and a whole lot easier to arrange since the legal precedent's there already (debit cards, which use a PIN to validate transactions, already leave the cardholder on the hook if a valid PIN was used on a transaction).
Same difference. To the user, you're the guy who tells the system what to do by writing the program that tells the hardware what to do. If you can't handle being the engineer responsible for making the machine, you aren't a programmer.
Actually you can't tell your car to start by turning a key. Turning the key starts a complex series of interactions between the fuel pump, fuel-injection and air intake systems, ignition system and starter motor to get the engine turning over and then to manage disengaging the starter motor and switching from battery to alternator power once the motor's running until you let the key go from Start back to Run. You can ignore all that and talk only in terms of the key being turned if all you want to do is drive the car, but if you need to say diagnose why the car won't start or figure out why it's running rough and has no power you need to delve into the complexity behind just turning the key. You can no longer ignore it and abstract it away. That's the key: not whether it's code or a mechanical system, but the degree of abstraction involved. Most programming languages are seen as complex because they dive below the level of "start the car" and work at the level of "OK, how exactly do I design the drivetrain of the starter motor so it'll rotate the engine crankshaft until the crankshaft starts turning faster than the starter motor is, then automatically and instantly disengage so the engine won't strip the starter motor by trying to turn it faster than it's safe to?" (and that's just one small part of what's needed to make turning the key start the car, and not even the most complicated part).
So-called "visual programming", which is what you're wanting, is great for relatively simple tasks where you're just stringing together pre-defined blocks of functionality. Where you're getting bogged down is exactly where visual programming breaks down: when you have to start precisely describing complex new functionality that didn't exist before and that interacts with other functionality in complex ways. It breaks down because of what it is: a way of simplifying things by reducing the vocabulary involved. It's fine as long as you stick to things within the vocabulary, but the moment you hit the vast array of things outside that vocabulary you hit a brick wall. It's like "simplfying" English by removing all verb tenses except simple past, present and future. It sounds great, until you ask yourself "OK, now how do I say that this action might take place in the future or it might not and I don't know which?". You can't, because in your simplification you've removed the very words you need. That may be appropriate for an elementary-school-level English class where the kids are still learning the basics, but it's not going to be sufficient for writing a doctoral thesis.
Even if there's a zero-day exploit, how is it going to attack the machine if the exploit code isn't run? I suppose theoretically there could be a bug in the filesystem code that could be exploited by a suitably-malformed filesystem structure to cause code to be run when the filesystem driver tries to interpret the filesystem structure when mounting the volume, but I haven't heard of one of those in ages. Beyond that, unless you've misconfigured your system to automatically execute code from a just-mounted removable device there's not going to be any code run. And in this day and age, if you're still allowing automatic code execution when removable media's inserted you need your fingers smacked and your sysadmin license taken away. Autorun and Autoplay are the work of the devil and should be disabled on sight.
As far as whether the office is secured or not, that's the responsibility of the software the office uses. Since they're required to use software that meets legal minimum standards, my assumption is that they do. And in any case, whether it's secure or not is out of scope for the task at hand which is transferring data from the office to the patient. I'm not writing the medical-office software itself, after all, and probably you wouldn't like my comments about current systems if I were tasked with writing it.
For e-mail clients, I dunno. Everybody I deal with uses one, and webmail's treated as an insecure alternative to be used only when you're out of reach of your normal computers. Anyone working with Microsoft e-mail clients has automatic encryption/decryption built in (and in fact it's fairly straightforward to enforce automatic encryption of all e-mail in Outlook and handle the automatic generation of key pairs when adding users). It's only hard in the sense that locking a car door's hard if you refuse to use the Lock button. C'mon, this is the 21st century, we're not talking about people who didn't grow up with computers anymore. If you're not over 65, the space program and computers and the like are things that were around when you were in high school at the latest. For me personally, pushing 50, computers were a part of business from the day I was born and you couldn't graduate high school without at least one class in how to use and program them. If I can understand how to set up encryption in an e-mail client, there's no excuse for a generation that grew up with smartphones and the World Wide Web and broadband Internet access to not be able to grok the concepts.
Plugging random flash drives in is entirely safe. It's just not safe to run content that's on them. But no system I build will run content from a removable drive when the volume's mounted, and for an application like a medical office system users wouldn't be given the opportunity to run anything directly either (they're running the medical office application, they have no reason to access the desktop at all). As for going through e-mail in plaintext, a) that's what the S/MIME and/or PGP encryption built into every major e-mail client's for, and b) you mean you have mail systems that aren't running SSL/TLS end-to-end?
Perhaps the system can be made more complicated, but I fail to see the reasons for it other than to comply with artifical requirements designed to complicate it. Within the doctor's office the information's already secured. Within the patient's computer, the patient's responsible for it and however they handle it's presumably acceptable to them or they wouldn't be doing it. And safely updating an XML file on a flash drive without exposing the system to risk is a problem that was solved back in the early 80s when I was in school. Ditto securely transmitting documents via e-mail. And a webapp I'd handle by having it do merging only with the data actually stored on the patient's machine, that way there's nothing on the server that needs secured outside the context of processing a single request.
Writing a system that actually stores patient data, that's at least 2 orders of magnitude more complex. But why should I go into that when the task at hand's letting the patient have the data and the doctor's own records system has already suitably handled the storage problem on the doctor's side?
I'm of the opinion that, alongside making it easier for medical providers to exchange information, it needs to be standard for the patient to get that information in a standard form that they can keep and give to medical providers directly. I know a lot of the data's complex, but in most cases it's written down in free-form text in the notes in the file and most other physicians can grok what the notes say. It should be feasible to have a standard XML format (UCSD allows me to download my record in a standard XML format already, so there's at least a starting point somewhere) that doctors can generate from their own notes and records and just give to the patient (adding it to a file on the patient's USB flash drive, or e-mailing to the patient to integrate themselves), and when the patient goes to another doctor they can just give them a copy of that XML file and preso, the doctor has the full record even if they can't exchange data with any of the patient's other doctors.
As far as integrating new entries into the patient's file, it's not that complicated. It's a sequence of records each of which has a creation timestamp, no need to look deeper inside each record, and new records are just inserted into the sequence at the correct point to keep the creation timestamps in the record in order. I can write a C++ or Java or C#/.Net program to do that, the basic logic'd take me an afternoon and the GUI part maybe another day or two. A webapp that'd take two or more XML files in and give you back a single merged file would take a bit longer, mostly to secure it against attack, how much longer depending mostly on whether you're leaving storage up to the user or storing a copy of their file for them (with the attendant work to keep personal information from walking off). That's assuming the file's for interchange with providers, formatting records for display and manual entry of records would be where the hard work would be and most providers already have computer systems they use for their own records that already handle those tasks.
My response when someone says it's an unwritten rule is "So, where exactly is it in the rules?". And when they repeat that it's an unwritten rule, I say "So, it's not actually a rule then. Good, that means I'm still playing by the rules.". It's the same as the Redwood City team's use of the full-court press: entirely within the rules, it just violates an unstated agreement not to play at 100% the entire game. Sure it comes as a shock when you're suddenly faced with a team that doesn't back down from 100% ever, that doesn't back off and give you position. But is it really their fault that you're not ready for that? You can do the same thing just as easily as they did. Is it really reasonable to insist that they play the game the way you'd like it to be played, as opposed to the way the rules say it should be played?
NB: the above is why, in friendly card games, the groups I played in had explicit rules about checks and calls and minimum bids/raises to keep the game moving (and maximum raises to keep someone who's up from buying the pot).
For taskbars, it's because they aren't necessarily a waste of space. If I've got a lot of windows open simultaneously (my "normal" workload's varied between half-a-dozen and 40-50 simultaneous windows over the years) they're invaluable for displaying the available windows so I can switch between them quickly. Not everyone uses just one application at a time, remember. They also provide a convenient place to put the root of the menu structure that lets me access less commonly-used applications without wasting tons of screen or desktop real-estate. And finally they provide a convenient place to put small always-on applications that can be compacted into a single icon when I'm not actively using them (think password managers, IM programs, e-mail clients and so on). We have the three options because not everyone needs taskbars available in quite the same way and not everyone has the same size monitor, and those options correspond nicely to obvious ways of having the taskbars behave (always visible and available, quickly visible when you need it and hidden the rest of the time, or out of the way and not showing itself unless deliberately asked for) depending on personal preference and how often you're using things on the taskbar. Providing those options means I can have it my way and you can have it yours and neither of us causes headaches for the other. Which is IMO the mark of a good UI.
The complaint, though, is that people aren't using Javascript as a carpenter uses a hammer. They're using it like a carpenter would use a hammer to mill and tool a high-performance aluminum engine block. Of course your first thought would be "DUH! A carpenter's hammer's the wrong tool for that job, you need a CNC mill for that.". Which is the complaint's point. And we already have plenty of the right tools for that job, the problem is that Javscript developers go "But those tools are too complicated!". No, it's not the tools that're complicated, it's the job that's complicated. That's not what they want to hear, though.
Bear in mind that if you can approach a problem and work through it logically, you are not an average developer, not by a long shot. The ability to do that puts you in the top 25% of developers right off. Witness the question over on Ars Technica where a developer seriously asked, in essence, why we divide applications into modules with defined APIs and hide the implementation details of a module from the components that use it. This... should have been covered way back in introductory programming classes, and anyone who's been developing software for any length of time should be able to rattle off the reasoning behind it. Yet here we have Jason Swett writing Web applications without enough understanding of the concept to know why we do it that way. He's typical of at least half the developers out there today: they do cargo-cult programming, following a set of directions without understanding what it is exactly that they're doing.
You miss two points:
1. You shouldn't need to be an expert in contract law and negotiation to learn to be a helicopter pilot or take classes at a private business college. The regulations are there to give a standard framework so students don't already have to be lawyers.
2. No contract can prevent one party from breaching it. They can only provide remedies after the fact, and that's no use if the party you could get anything out of is long gone and can't be found. Regulation can do things like force the creation of a separate account with the state limiting the school's access to it (ie. the bank won't let the school's operator withdraw the funds if they want to scamper) to cover refunds if the school closes. A private contract could only do the same with a bit of fairly complex escrow accounts, see point #1 about us not wanting students to have to already be lawyers just to take a few classes.
It isn't "merely" a bad contract. Suppose the contract did have a provision in it requiring the school to refund the tuition. What good does that do? The student can go to court and get a judgement, but the school's still closed, the classes still having happened, and the money's still gone with nothing in the school's assets to pay any judgement out of. And no contract terms in the world will prevent the operators from just pulling up stakes and skipping town with the money,
This is why the scam artists hate the regulations so much. Among other things, they require the school to set aside a fund, held in a separate bank account and untouchable by the school for any other purpose, dedicated to covering tuition refunds if for any reason the school can't make good on it's end of the bargain. The scam artists can still pull up stakes and bug out, but they can't take the money with them.
I did. But since the sites were coded for IE6-specific weirdness, they wouldn't render right in FF (even assuming I installed a user-agent spoofer to get around the check many of them did). So I used FF for external browsing, and IE6 for the web apps I had to use day-to-day.
Exemptions to the CPPEA 2009. Notice the big one: schools charging a tuition of $2500 or less. That should outright exempt a lot of places once they file the right paperwork. The target of these regulations isn't the small places or pay-as-you-go classes. It's places like Silver State Helicopters that take in large tuition payments and then evaporate without delivering classes. That's why the regulations are light on teacher qualifications and heavy on the financial aspects of the schools and their owners including things like the required tuition recovery funds.
One name: Silver State Helicopters in San Diego (technically El Cajon, but close enough). In 2008, 1 year after the previous regulation of private postsecondary schools was allowed to expire, they closed their doors taking the $70,000 per student in fees that'd already been paid and leaving the students out the money, often with the student loans for the tuition hanging over their heads, with no classes and no arrangements made to deliver the training the students had paid for. They weren't the only one, either. Another private business "college" in San Diego did the same thing that same year, tuition wasn't as much but it had a lot more students and again all of them were out the tuition and the school didn't make any arrangements for delivering what the students had paid for.
This didn't happen under the old regulations, and it stopped happening once the new regulations went into effect, because the schools' operators could be held legally liable for the costs to students. I'd say the historical record leans toward the regulations being necessary and a good thing.
It's a vicious circle. At my former employer we were on IE6 because several of our critical Web applications only worked correctly with it. And since we were locked into IE6, any new Web applications had to work with it as well which removed any pressure to update. The only way we'd've gotten resources allocated to update those few ancient Web apps would have been if some other business-critical Web app had abandoned IE6 support entirely and said "IE 8 or later or we don't work". Which they won't do because they don't want to risk losing their IE6 user base. And round and round it goes, like a pair of orbiting black holes.
My first thought is that Adobe wants CSS Regions to be able to do print-media-style page layout, missing the point that the Web isn't a printed magazine. You don't know how big your target display window is, you don't even know whether it's landscape or portrait. You don't know if the viewer can even see images at all, nor if they can see colors correctly (look up the percentages of the population with various types of color-blindness). So why are you trying to be so precise about layout with so many unknowns in the mix?
I truly hate Web sites that force a 3-column layout with narrow columns that don't flow to the width of my window, or that flow the advertising material and leave the content narrow and on a dozen different pages so I'm forever clicking "Next" to keep reading. I have a large monitor and a wide window for a reason. My browser has a scroll-bar for a reason. Constraining me to a magazine's column widths and pagination is completely missing the point. I'm there for the content, and when layout becomes so complex and cumbersome that it's interfering with the content you're Doing It Wrong.
That one used a physical driveline, though. Running a generator you don't spool the turbine up and down. It stays running at a mostly-constant speed, spooling up and down only with long-term demand, and you divert electric output from the drive motors to battery charging when stopped. If you need sudden acceleration, like starting from a stop, you draw power from the battery while the turbine spins back up to handle the load again. And fuel economy solves itself mostly with not having to constantly change the turbine's operating speed or stop and start it, plus you're not having the losses due to the complex step-down gears to get shaft RPM down to driveline RPM (there simply is no way to step down 20,000 RPM to 20 RPM that's both compact and efficient).
The problem with electric cars is the battery: high weight, limited capacity and thus range, hazardous materials which make replacement and disposal a headache. But, electric cars don't really need a battery, they need a source of electric power. Turbine engines run a lot cleaner than piston engines, have better fuel efficiency and run on a much wider variety of fuels, the problem was always stepping down the shaft speed to something a physical driveline could use. It's a lot easier, though, to run a generator at the high RPMs a turbine shaft naturally runs at, and a generator supplies electric power. I get the feeling the next step won't be pure-electric cars, but a hybrid with the conventional piston engine replaced by a small turbine and generator. That would reduce the demand for high-priced fuels, and also reduce the size of battery packs since you'd only need one with a ~20 mile range to cover short hops where it wouldn't be efficient to spin up the turbine.
Turbine start would be easy: any generator is in principle also a motor, and since with no fuel being burned the turbine shaft isn't under load it shouldn't take too much power to spin it up enough to start. I'd imagine this'd make them really popular in northern latitudes where getting cars started in the winter is a bear. A turbine would be easier to start, plus would immediately start providing heat for the interior and defrosting.
Big practical problem: that would require you giving away all the details of your product without placing the patent troll under any legal obligation not to give them out to others. From a legal standpoint they're also not under any obligation to answer your query or evaluate your claim that you infringe, so they could just bin your letter and wait without any legal penalty. You'd have to actually make a claim against them to start any sort of clock ticking, eg. by filing to invalidate their patent on the grounds that your material is prior art. The system's currently tilted very much in favor of ambush tactics, you pretty much have to wait until they start to move before you can draw them into a trap.
Prerequisite for a declaratory judgement though is that the patent-holder has to have already made claims that you infringe sufficient to make you reasonably fear being sued by them. But sometimes the would-normally-be-the-plaintiff won't actually come out and sue, they'll just dance around and threaten without ever coming out where the defendant could defend themselves. Think a patent-holder going around to investors talking about how you will be sued and lose all your money, convincing investors to avoid you without ever laying their claims on the table where you can refute them. A DJ action's the way the defendant in that kind of situation can force the plaintiff to stop evading and either make their claims or admit they don't have any.
Note that the burden isn't entirely on the patent-holder. The party bringing the DJ action has to prove that the patent-holder's either actually threatened to sue them or has made public statements sufficient to give them good reason to believe they will be sued. You can't bring a DJ action just because you think they might sue you, you essentially have to show based on their statements and actions that a reasonable plaintiff should have already sued you.
Fairly hard. One of the requirements for asking for a declaratory judgement is that you have to either have been sued or have a reasonable fear of being sued by the patent-holder. If the patent-holder hasn't actually sued anyone yet, it's easy for them to v get DJ actions dismissed. Even if they're sued others but not sued you, traditionally it's been easy for them to argue that you don't have any reason to believe you'll be sued yet (not that that is not a promise not to sue you in the future). In this particular case Medtronic sustained their DJ because Mirowski had already put it in writing that it believed Medtronic infringed the patents, and if they do then the next step if Medtronic didn't agree would be to sue.
The article isn't clear, but my first thought is that this should be simple to deal with by just revoking permission for a site to use the mic. Except that when I check in Chrome, there's no way to enable this at all. The only references involve adding the Chrome Voice Control extension, which isn't included in Chrome by default. So while this is a problem, it doesn't seem to be one that can't be easily solved. If you're truly worried about it, don't install the extension or remove it if you've got it installed. If you want the extension, be careful of which sites you grant permission to and go and manually revoke permission when you're done. You ought to be reviewing permissions regularly anyway, not just for this but for anything you're granting extra permissions for.
If it's a publicly-traded company, the stock price going down too badly long-term makes bad things happen because the stockholders are going to be upset and will want something done. If management isn't aware of how the stock's performing and why and don't have plans to deal with any declines, the company's not long for this world and I don't want to go to work for somewhere that's just going to be broken up and sold off. And if management and the employees don't know what the perceived weaknesses and strengths of the company are, how are they expected to exploit the perceived strengths and correct the perceived weaknesses?
You don't obsess about it, but you'd better damned well be aware of it.
Consider my response to that: "Oh, I already know how it's doing. I did my research on your company. I want to know if you know how your own company's stock's doing, and how your view of it matches up with the analysts' take on your company.". If the interviewer's willing to BS me about the company's performance and how it's handling itself, what else are they BSing me on? And if they honestly don't realize how their company's performing, I have to wonder whether there's some fundamental dysfunction that I may not want any part of.