You might also have to get the user to install a signed configuration profile that adds the https proxy to the trusted anchors list on the device; I'm not sure if you can do that from a network extension profile or not.
Create a network extension VPN plug-in that parses packets, re-creates those packets or connections in a manner that binds them to the current public network interface, and then re-sends the traffic (making it effectively a null VPN).
Grab the source code for an http/https proxy and integrate it into your null network extension VPN plug-in so that the proxy also runs continuously in the background, listening on an ephemeral port on the loopback interface.
Add code to the proxy that watches for a Safari user agent string and replaces it with an arbitrary string from the plug-in's configuration.
Write an app that A. loads and starts the VPN plug-in, B. obtains the proxy's port number, C. configures the device's proxy settings for use while the VPN tunnel is "conncted", thus sending the traffic to your proxy via the loopback interface, and D. tells the proxy what user agent string to use (by sending a command to the plug-in).
Obviously, #1 is a pain in the backside. The rest is pretty straightforward.
I'm not convinced the Republicans want to take the White House. After all, most of the real power is in Congress. The President has the power to lead the armed forces, negotiate treaties, grant pardons, replace the heads of various government agencies, direct those agencies to do their work in different ways (within the limits of existing law), nominate judges, and veto legislation passed by Congress. Just about every President in my lifetime who has ever talked about the things he intended to do if elected has been full of it, because no President has the power to do any of those things without an act of Congress.
There are things that a President could do to change the way budgeting is done within the various executive agencies, which if done correctly, could significantly improve the functioning of government, or at least reduce the cost without reducing services. Notice that no presidential candidate has ever talked about wanting to do those things.
Otherwise, ignoring the ability to wage war, a President's power lies mainly in preventing Congress from doing things by vetoing legislation. What I really want to see is a presidential candidate who says, "I will veto any bill that seems overly broad, is likely to have unexpected consequences, or encompasses more than a single issue. If a President really stuck to his/her guns about that, it would prevent a lot of really bad laws and appropriations that get passed as riders on unrelated bills, and our country would be far better off for it. It would also ensure that every issue got a serious debate on its own merits rather than being rushed through and barely even glanced at by the people voting on it. This would have the effect of increasing the quality of legislation across the board. But again, notice that no presidential candidate has ever suggested such use of his or her veto power.
And so on. And this is why I'm unimpressed by the entire field of presidential candidates, without fail, from both parties.
I think most of the repairs they did on Hubble fell well outside the bounds of the sorts of servicing that they designed it for. This is not to say that it is always practical to service some parts of ISS, particularly if it would involve cutting power (heat) and/or air to an ISS module for an extended period of time, but as long as you can keep the repairs within those bounds, I don't see any reason why people couldn't do fairly complex non-structural repairs within the interior of the station. I wouldn't think that there would be a whole lot of difference between repairs up there and repairs down here (other than availability of parts, obviously)....
I mean, you'd have trouble with stainless steel screws; they'd probably need a vacuum cleaner instead of a magnetic screwdriver, and they would need replacement screws that weren't stainless. Soldering could be somewhat challenging, if only because the blobs of hot solder wouldn't drop harmlessly to the floor, but that could probably be mostly solved by taking one of those plastic isolation chambers with the built-in safety gloves, adding some permanently mounted wire clamps on gooseneck attachments, replacing one end of the box with a fine metal screen, and blowing air towards that metal screen. The rosin smell might be murder on the scrubbers, I guess, but otherwise....
Not necessarily super-expensive. Automatic mining machines already exist. You'd have to modify them a bit to make them work in microgravity, of course, by finding some way to anchor them initially while they drill the first few feet into the material, and you'd have to modify both the drilling machines and the haulers to have wheels on all sides with springs to hug the tunnel walls, and you'd have to come up with something more complex than a gravity-dependent conveyor belt to move the rock into the hauler, but that's only going to be super-expensive if government does it.:-D
You could have done a lot of that by adding size properties to the superclass. What made the use of subclasses important is the additional checking behavior needed for treating diagonals as a set, which requires significantly different behavior in your checking code, which is probably called from multiple places in the class implementation. So ignoring the length issue, that pretty much qualifies as a very minimal example of the principles I'm advocating.
Pedantically, what you did probably violates Liskov, at least in principle, because the actual behavior is different even from the perspective of the interface, but in practice, what you have are a couple of tightly coupled classes, one of which is a solver, the other of which is the UI for the solver, and the solver isn't intended to be used broadly outside that context. So the violation of consistent interface behavior from one subclass to the next isn't necessarily a problem, at least in practice.
Alternatively, the solver could be part of the UI class, and then there would be no violation at all, because you'd load different UI subclasses that have different numbers of rows and columns, and that treat diagonals differently, and they would all have the same programmatic interface, because view is a view is a view.
Inheritance for re-use is quite possibly the worst reason ever to use subclasses. Inheritance should be used when you need polymorphism and the two objects behave *alike* - AKA the Liskov Substitution Principle [stackoverflow.com]. (Public) Inheritance that violates some of the assumptions of the parent class is really painful.
By "behaves very differently", I don't mean that the interface is different; I mean that the way they support that interface is different for some important reason, and in a nontrivial way that makes it necessary to have a separate class. That's a subtle point that I probably could have explained better.
Consider two apps that control VPNs on iOS. One app controls both an IPsec VPN and a custom packet tunnel. A second app controls two IPsec tunnels, one of which uses IKEv1 authentication and the other of which uses IKEv2 authentication. A class to control any of those three will likely have roughly the same outward interface—start the VPN, stop the VPN, set the on-demand rules, etc.:
In the first app, subclasses are appropriate. Although the interface that an IPsec VPN and a custom packet tunnel must present to the app is likely to be almost the same, if not identical, the actual code that those two classes use to set up the VPN tunnel are completely different. It makes sense to make them both be subclasses of some common root class, both to allow them to share code and to make it harder for their outward interfaces to diverge unintentionally in ways that would violate the abstraction.
By contrast, in the second case, subclasses would be serious overkill. The differences between IKEv1 and IKEv2 can be encapsulated in a small "if" statement in maybe two places in your code. So a simple property is a better choice (IMO).
Alternatively, subclassing makes sense if you need two classes that share some common functionality, but provide other functionality that is different. In this case, however, callers that care about that added functionality must know which kind of class they're dealing with. This doesn't violate Liskov because they still support the functionality of the superclass without changing the behavior of the superclass's methods. With that said, if it is possible to comfortably combine those classes into a single class that does what both classes do, then the class abstraction will be more of hindrance than a help. It is important to recognize such anti-patterns when you see them.
And incidentally, I say this as somebody who has been using Macs exclusively since the mid-1990s, who uses iOS almost exclusively, and who develops software almost exclusively for use on Apple products. I'm not a hater by any means. I'm just immune to the RDF. When Apple does something great, I commend them. When they could do better, I say so. And when it comes to first-generation products, I've always come away thinking that they could have done much better.
Steve got a standing O on the original iPhone. There was nothing else even close. At all. Did you ever use a Blackberry with the ball running WinCE? Hell, there was nothing like it on Star Trek. This is the biggest indicator that you and I have lived in different universes.
As I said, the software was very polished. The hardware was severely lacking:
Single-network. The original iPhone supported only one carrier, AT&T, whose service in most of the country was subpar, and which was not by any stretch of the imagination the most popular carrier. The lack of Verizon support alone put the original iPhone seriously behind every competitor.
Not subsidized. You had to pay full price up front, and the phone was still locked to a single carrier.
No GPS. Lots of phones had GPS years before the first iPhone came out. The first iPhone didn't.
No 3G. HSDPA phones had been on the market for at least a year before the first iPhone came out. The first iPhone had only EDGE.
Sony Ericsson had been putting front-facing cameras in their feature phones for almost seven years before Apple finally put one in the iPhone 4.
See my point?
I know 2 people still using original iPads. They still fetch, what; just under a 100 bucks used? Again, nothing else like it on the market when it came out.
Depends on how you define "like it". By the time the iPad came out, there were at least a handful of Android tablets already on the market. They weren't very popular, but then again, neither was Android yet. However, the Android tablets that did exist at the time had twice as much RAM as the original iPad. By the second generation (about a year later), the hardware was considerably faster, had twice as much RAM, and is still supported in iOS 9—three years longer than the original iPad and counting.
I have the core 2 duo Intel MacBook Pro, the gen after yours. Still works fine. Used it daily for 5 years. The core 2 was abandoned?
Not Core 2. Core Duo. The Core 2 Duo had 64-bit; it just didn't have 64-bit EFI, which meant it could run 10.7, but not 10.8. So the second-generation hardware was released only nine months after the first-gen, but was supported for about two years after they dropped support for the first-gen. It was even worse if you bought the first polycarbonate Macbook. You could have waited just six months for a version that would have been supported for two additional years. And compared with a PC built in 2004.... you can run Windows 10 on any Windows box from that era, so what's that, six years longer support on the Windows side? Technically, I suppose you could run Windows 10 on the first MacBook and MacBook Pro models, if there are drivers for the hardware, but....
It used to be that Apple hardware was usable a lot longer than Windows hardware. I hope Apple gets back to that, because this "supported until a few months after AppleCare runs out, and then you have to buy a new machine if you want security updates" crap is for the birds. But I digress.
Just to be clear, the question was not whether the first-gen models still work (though I do tend to feel uncomfortable continuing to use them much past when Apple stops issuing security updates, particularly now that they're using Intel CPUs and have a much larger market share). The question was what models of Apple hardware was below average at the time, but became popular because of the polish (UI design, etc.). And the answer is, IMO, all of them. They all paired more polished software with hardware that was subpar (or at best, barely par) by the standards of the time.
And all of the second generation models have been miles ahead of the first-generation models—with the improvements in subsequent generations being considerably smaller than the difference between the first-generation and second-generation model, for the most part. That's a pattern that Apple has consistently exhibited all the way back to the original Apple I.
I find functional programming to be dubious as a general tool, because it doesn't map onto the way people think about doing things. When I think about how to cook a meal, I think about putting particular ingredients together. I don't think about creating a list of items and combining operators, then magically evaluating those combinators all at once and getting a cake. The entire notion of lazy evaluation is simply antithetical to the way most people think about doing things. Functional programming, to me, ranks right up there with C preprocessor macros in the "Ooh, neat, I can do horrible things that will terrify mere mortals, but I probably shouldn't" category. I've done it; I understand it; I can't imagine ever, at least while in my right mind, trying to write a real-world application with it.
By contrast, OOP at least maps fairly cleanly onto the procedural mindset that most people use when describing processes without having to introduce clever hacks like monads. And OOP can be done well; I've just never seen it done well in Java. I can only assume that this is because most programmers learn by reading other people's code, and when you get enough terrible code out there, the natural trend is towards producing more terrible code. With that said, I've seen lots of Objective-C code that is reasonably well architected. I've seen lots of code written in C that uses structs as glorified classes that is mostly well architected. I've seen PHP code that uses classes well (along with a few absolute abortions, but I digress).
The original iPod was way too expensive, had less space than competitors, but sold acceptably because of a clean user interface. It didn't sell well, mind you; that didn't happen until economies of scale brought the price down to something less than horrible.
The original iPhone had nice software, but the hardware was at best mediocre. It had no 3G, had no GPS (making do with cell phone triangulation), and didn't really have enough RAM to work well. Its CPU was way too slow, and the base model had hopelessly too little flash storage (4 GB). So by the time Apple abandoned it at the end of iOS 3, it was nearly unusable.
The original iPad was also underpowered CPU-wise and RAM-wise for its screen size, again, resulting in a product that had to be abandoned after only two major OS releases (arguably less than that) because it just plain couldn't keep up with the demands of the growing OS.
The first Intel MacBook Pro was a few months premature. Instead of waiting just a few more months for a 64-bit CPU, they decided to ship with the Core Duo series, resulting in a product that they had to abandon just 2 major OS releases later because it couldn't run 64-bit code.
The first of the G5 towers had a badly designed power supply that had a chirping problem (both acoustically and electrically, causing lots of problems for audio interfaces).
Don't get me wrong, I like Apple and their products, but I learned long ago to avoid being an early adopter whenever possible. Burn me three times, shame on you; burn me four times....:-D
Flip side, I bought a '99 Ford Windstar. By about 120k miles, I:
Had a check engine light under warranty; instead of fixing the real problem, the inept dealer just blew out the vacuum lines, presumably hoping for a more expensive out-of-warranty repair.
Replaced the front valve cover myself (after the second check engine light) because of a design flaw that causes oil blow-back into the air intake, fouling the vacuum lines and destroying various rubber seals in the intake manifold. Replaced said rubber seals as well.
Was without the car for about a week while the inept dealer diagnosed what turned out to be a simple split in a metal coolant pipe (causing a small steam leak when you first start the engine) in the intake manifold.
Had the transmission rebuilt (and it needs to be rebuilt again) because of bad solenoids.
Replaced the rear electronics module myself because it was randomly locking and unlocking the doors while driving, and one turn signal was flashing erratically.
Replaced four of the five door lock motors myself over the course of a year or so because of latent damage caused by the bad REM. (I have the fifth one in a box, me being of little faith.)
Had the power steering pump replaced because it self destructed.
Had the steering rack replaced a week later because the new pump blew out the gaskets.
Had the fuel pump replaced.
Had the driver's side window motor replaced.
Replaced three tires because the particular size of tire (at least in the brand that I mistakenly picked at the time) is highly prone to side blowouts when lightly curbed.
Need to reflow the ABS controller, but haven't had a chance to do it yet.
So forgive me if I laugh at the notion of an Apple car being a money pit. It can't be much worse than that.
I would say that 95% of all people I know in person, who learned C first and not: Assembler, Pascal, SmallTalk, Lisp are extremely bad on advanced language concepts like functional or oo programming.
Not sure why people learning Pascal, assembler, or Lisp first would be better at OO. There's nothing OO about any of those. I would turn that around and say that 95% of programmers are bad at OO programming, period, regardless of what language they started with. Most folks frequently forget what are, IMO, some of the most basic rules of OO:
A class should be a mostly self-contained. If you have two or three classes that are tightly coupled, you should probably merge them into a single class unless there are data structure reasons not to do so.
A subclass should be used only when all of the following are true:
You need two objects that behave very differently, but share some common behaviors
The differences are easily achieved by replacing a few specific chunks of functionality that are reused in multiple places
The classes need to coexist
Otherwise, if the behavior differences are minor, or if the functionality you're changing requires hundreds of tweaks, each of which is different from the next, you're probably better off using a property that switches from one behavior to the other and just using "if" statements.
Never create a subclass until you are ready to create at least two subclasses at the same time. Otherwise, you will invariably get the boundary between subclass and superclass wrong and will have to refactor it again anyway.
When you've created two or more classes that are substantially similar, that's the appropriate time to step back and ask yourself if you should create a superclass and fold the common functionality into it.
If your subclasses are more than about one or two levels deep (unless you're just using subclasses because your language lacks categories/class extensions), you almost certainly have a serious design problem.
Document your methods, their side effects, and their expected calling conventions early so that when you refactor it into a couple of subclasses, you can be certain that they all obey they same rules.
As I said, most software companies these days can take advantage of infrastructure like iCloud to avoid keeping their own databases. This makes it somebody else's problem. If Apple loses all of the iCloud data, it would be an end-of-the-world-level crisis, as I said, but there's no feasible way for individual software companies to back up that data, making it entirely out of their control.
Amazon, of course, is different in that some of their cloud services are much closer to being servers under your control. If you're using that sort of service, then yes, you have to have a disaster preparedness strategy, even if that strategy is as simple as replicating the data on a geographically distant server continuously, and building backups into your schema. However, as software companies go, those sorts of needs are the exception, not the rule.
A week? most data disaster you are down for at least 30 days. Hell you cant get an order for servers in from DELL even on rush faster than 2 weeks.
Maybe true, but you can get a cloud server deployed in a matter of minutes, and you can use that as a temporary (expensive) alternative to servers under your complete control.
If your company can survive zero revenue and 100% loss for 30 days, you either are sitting on a mountain of money, or your business is more of a hobby than anything else.
You're making a lot of assumptions that aren't necessarily valid. The amount of downtime and the impact depends heavily on the nature of the company, and in particular, whether sales/income depends on maintaining continuous operation of the business. Take, for example, a company that makes software:
On the development side, even if a company's entire repository went away tomorrow, and even if half the development team died, a typical software company could still get back all but the last few days' work (and perhaps a few old branches) by configuring a github instance on Amazon's Elastic Cloud and having the remaining developers push all of the branches from their local checkouts. Downtime would be minimal.
On the distribution site, most software companies would be completely unaffected, because distribution is usually handled by a large third-party merchant (Apple, Google, etc.).
So unless a software company requires critical server infrastructure beyond what they get for free via iCloud, etc., it probably needs very little in the way of disaster preparedness, because the very nature of the work and the tools involved lends itself to being prepared for a disaster automatically.
On the opposite end of the spectrum, cloud service providers and Internet service companies must have disaster preparedness plans in place, or else everybody who uses their services is screwed. And if they're down for even a couple of days, they're probably going out of business. If Facebook went down for a week, Google+ would become the #1 social network.
Of course it does. Download the DMG, and copy the DMG to a dozen machines before you agree to the license.:-D
But in all seriousness, if there's no practical difference between downloading it 17 times and downloading it once and installing it 17 times, then the law would almost invariably consider them equivalent. And Apple doesn't forbid you from downloading it 17 times and installing each copy to a new machine, so you should be in the clear even if Apple were insane enough to try to sue you for doing it. And of course, there's no way Apple would ever be crazy enough to do that, making the whole point moot (in both the American and British sense).
Unless something changed recently, AFAIK, iOS MDM only provides the ability to back up managed apps. While that may or may not be a problem for businesses (depending largely on corporate policies, whether they're doing BYOD, etc.), it wouldn't be very practical for general use. And it would still require a separate computer to manage the backups, and unless you did some tricky configuration involving pre-mounting the NAS at a specific path (which OS X tries to make as hard as possible), even an MDM solution would still be backing up to the computer which, in turn, would have to use OS X's normal backup scheme to back up the backup to the NAS.
The part that makes it most annoying is that because of how locked down iOS is, it isn't even possible for a third party to add this feature that Apple left out, whereas at least in theory, it should take minimal effort for Apple to do it (by adding their existing diskarbitrationd, smbfs/afpfs, and backupd daemons/tools/kexts to iOS, plus a little bit of UI glue to modify backupd's prefs file). Grr.
It really is. The one thing I absolutely hate about iOS is that Apple still has not added any automated LAN-based backup capabilities. I can back up my laptop and all my other Mac hardware to my fireproof NAS (and before that, to my Time Capsule's external fireproof HDs) with minimal effort, but it is impossible to back up my iPhone to that NAS except by backing up the phone to my laptop and then backing up my laptop to the NAS. That's tremendously clumsy and amazingly un-Apple-like, not to mention that it wastes a colossal amount of my laptop's hard drive space for no good reason.
I'm surprised businesses put up with it. If I were running a business, I'd be very concerned by my employees' devices storing backups on Apple's servers instead of on local servers under my control. Apple would probably have a coronary if their employees kept any Apple confidential info on an Android phone and backed it up to Google's servers, yet they expect everyone else to do exactly that.
Apple needs to get serious about backups on iOS. IMO, it is way past time.
In my case, I used to use cloud backups, but at some point, I hit the capacity limits of the service. Then, they started offering higher limits at a reasonable price, so I could reenable it, but apparently I forgot to do so. With that said, the reason I did the backup is that in two weeks, I'm going to be getting a new phone. At that point, all that data is going to be coming back down, which means speed will be important again.
Never ascribe to the sins of MBAs what is just rotten network quality. Crappy cable, overused segments, ugly routing, aperiodic surges, home network congestion, ugly routers, all these things have a bearing on overall throughput. In DSL, the sins are only slightly different. Fiber means nothing if you're sharing the same backhaul with two dozen Netflix instances.
The thing is, the network quality might be terrible, but with few exceptions, it usually isn't "the network just went down for half a minute or longer" terrible. The problem is that they don't buffer enough. If you have a big enough buffer, playback won't glitch. If you don't, it will. And the definition of "enough" is highly variable, which means that the playback software needs to keep track of long-term trends on a given network. For a fixed installation like a cable box, there's no excuse for not doing so.
The two are inextricably connected. Part of knowing how to stream video properly is understanding that reliability is not optional. If you can't reliably play video, your customers will leave. Inadequate buffering might save you money in the short term, but it costs you customers in the medium to long term.
If a streaming provider glitches that badly, it means that they don't know how to do video streaming. It isn't rocket science. You ensure that you buffer enough to keep playback going, starting at a bit rate that is lower than your connection's average speed initially so that you can buffer ahead. You then transparently switch to a higher quality stream (if available) after you've built up at least half a minute of buffer. And if you detect that the buffer is shrinking, you begin buffering progressively lower-quality streams until it stops shrinking. If the network performance problem goes away, you can always switch back to the high-quality stream and (if the performance is dramatically better than expected) opportunistically replace chunks of the lower-quality buffered data with higher-quality versions, beginning with the oldest content, in an attempt to avoid the user ever seeing the lower-quality version.
The problem is not the speed of the connection. The problem is pencil pushers at the content providers who try to micromanage the amount of data that they provide, giving you the bare minimum amount of cached data necessary, so that when you stop watching, they won't have wasted any data sending you content that you didn't watch. This approach is ineffective, and results in constant glitches if the network connection speed is variable. Unfortunately, that approach is all too common.
Most users don't need more than 10 Mbits/s averaged over a week, but most users will swear at their ISP at least once a year unless their connection is nearly an order of magnitude higher than that. I just did a full iCloud backup of a 64 GB iPhone 5 for the first time in a year. Had I used a 10 Mbit/s connection, given how much slower upload usually is, I'd expect to have only around 3 Mbit/s upload speed, which would mean the backup would have taken more than half a weekend. That's barely even usable. Forget being satisfied.
There are a lot of those companies, and the names of those companies keep changing, because they keep going out of business after two or three years. After all, it doesn't take long at those levels of abuse before most of the competent engineers start looking for other options, leaving mostly the people who can't find a job anywhere else. Such mass departures are usually a harbinger of doom for the companies involved.
If you want to find a job that doesn't suck, look for a pre-IPO company that has been around for at least five years or whose founders have started other successful companies in the past. Odds are, companies in either of those categories aren't being run by total clowns.:-)
There's really no good reason to stick around at a startup that is being run into the ground by management like that. The idea of a startup is that you take slightly less pay than you might get at an established firm in exchange for the hope that your options might be worth something someday. However, those stock options are never going to become valuable if the company collapses under the weight of its managerial ineptitude, so you might as well consider them worthless, and try to find a better job.
Slashdot Mirror
Err... "connected".
You might also have to get the user to install a signed configuration profile that adds the https proxy to the trusted anchors list on the device; I'm not sure if you can do that from a network extension profile or not.
You can in iOS 9:
Obviously, #1 is a pain in the backside. The rest is pretty straightforward.
I'm not convinced the Republicans want to take the White House. After all, most of the real power is in Congress. The President has the power to lead the armed forces, negotiate treaties, grant pardons, replace the heads of various government agencies, direct those agencies to do their work in different ways (within the limits of existing law), nominate judges, and veto legislation passed by Congress. Just about every President in my lifetime who has ever talked about the things he intended to do if elected has been full of it, because no President has the power to do any of those things without an act of Congress.
There are things that a President could do to change the way budgeting is done within the various executive agencies, which if done correctly, could significantly improve the functioning of government, or at least reduce the cost without reducing services. Notice that no presidential candidate has ever talked about wanting to do those things.
Otherwise, ignoring the ability to wage war, a President's power lies mainly in preventing Congress from doing things by vetoing legislation. What I really want to see is a presidential candidate who says, "I will veto any bill that seems overly broad, is likely to have unexpected consequences, or encompasses more than a single issue. If a President really stuck to his/her guns about that, it would prevent a lot of really bad laws and appropriations that get passed as riders on unrelated bills, and our country would be far better off for it. It would also ensure that every issue got a serious debate on its own merits rather than being rushed through and barely even glanced at by the people voting on it. This would have the effect of increasing the quality of legislation across the board. But again, notice that no presidential candidate has ever suggested such use of his or her veto power.
And so on. And this is why I'm unimpressed by the entire field of presidential candidates, without fail, from both parties.
I think most of the repairs they did on Hubble fell well outside the bounds of the sorts of servicing that they designed it for. This is not to say that it is always practical to service some parts of ISS, particularly if it would involve cutting power (heat) and/or air to an ISS module for an extended period of time, but as long as you can keep the repairs within those bounds, I don't see any reason why people couldn't do fairly complex non-structural repairs within the interior of the station. I wouldn't think that there would be a whole lot of difference between repairs up there and repairs down here (other than availability of parts, obviously)....
I mean, you'd have trouble with stainless steel screws; they'd probably need a vacuum cleaner instead of a magnetic screwdriver, and they would need replacement screws that weren't stainless. Soldering could be somewhat challenging, if only because the blobs of hot solder wouldn't drop harmlessly to the floor, but that could probably be mostly solved by taking one of those plastic isolation chambers with the built-in safety gloves, adding some permanently mounted wire clamps on gooseneck attachments, replacing one end of the box with a fine metal screen, and blowing air towards that metal screen. The rosin smell might be murder on the scrubbers, I guess, but otherwise....
Not necessarily super-expensive. Automatic mining machines already exist. You'd have to modify them a bit to make them work in microgravity, of course, by finding some way to anchor them initially while they drill the first few feet into the material, and you'd have to modify both the drilling machines and the haulers to have wheels on all sides with springs to hug the tunnel walls, and you'd have to come up with something more complex than a gravity-dependent conveyor belt to move the rock into the hauler, but that's only going to be super-expensive if government does it. :-D
You could have done a lot of that by adding size properties to the superclass. What made the use of subclasses important is the additional checking behavior needed for treating diagonals as a set, which requires significantly different behavior in your checking code, which is probably called from multiple places in the class implementation. So ignoring the length issue, that pretty much qualifies as a very minimal example of the principles I'm advocating.
Pedantically, what you did probably violates Liskov, at least in principle, because the actual behavior is different even from the perspective of the interface, but in practice, what you have are a couple of tightly coupled classes, one of which is a solver, the other of which is the UI for the solver, and the solver isn't intended to be used broadly outside that context. So the violation of consistent interface behavior from one subclass to the next isn't necessarily a problem, at least in practice.
Alternatively, the solver could be part of the UI class, and then there would be no violation at all, because you'd load different UI subclasses that have different numbers of rows and columns, and that treat diagonals differently, and they would all have the same programmatic interface, because view is a view is a view.
By "behaves very differently", I don't mean that the interface is different; I mean that the way they support that interface is different for some important reason, and in a nontrivial way that makes it necessary to have a separate class. That's a subtle point that I probably could have explained better.
Consider two apps that control VPNs on iOS. One app controls both an IPsec VPN and a custom packet tunnel. A second app controls two IPsec tunnels, one of which uses IKEv1 authentication and the other of which uses IKEv2 authentication. A class to control any of those three will likely have roughly the same outward interface—start the VPN, stop the VPN, set the on-demand rules, etc.:
Alternatively, subclassing makes sense if you need two classes that share some common functionality, but provide other functionality that is different. In this case, however, callers that care about that added functionality must know which kind of class they're dealing with. This doesn't violate Liskov because they still support the functionality of the superclass without changing the behavior of the superclass's methods. With that said, if it is possible to comfortably combine those classes into a single class that does what both classes do, then the class abstraction will be more of hindrance than a help. It is important to recognize such anti-patterns when you see them.
And incidentally, I say this as somebody who has been using Macs exclusively since the mid-1990s, who uses iOS almost exclusively, and who develops software almost exclusively for use on Apple products. I'm not a hater by any means. I'm just immune to the RDF. When Apple does something great, I commend them. When they could do better, I say so. And when it comes to first-generation products, I've always come away thinking that they could have done much better.
As I said, the software was very polished. The hardware was severely lacking:
See my point?
Depends on how you define "like it". By the time the iPad came out, there were at least a handful of Android tablets already on the market. They weren't very popular, but then again, neither was Android yet. However, the Android tablets that did exist at the time had twice as much RAM as the original iPad. By the second generation (about a year later), the hardware was considerably faster, had twice as much RAM, and is still supported in iOS 9—three years longer than the original iPad and counting.
Not Core 2. Core Duo. The Core 2 Duo had 64-bit; it just didn't have 64-bit EFI, which meant it could run 10.7, but not 10.8. So the second-generation hardware was released only nine months after the first-gen, but was supported for about two years after they dropped support for the first-gen. It was even worse if you bought the first polycarbonate Macbook. You could have waited just six months for a version that would have been supported for two additional years. And compared with a PC built in 2004.... you can run Windows 10 on any Windows box from that era, so what's that, six years longer support on the Windows side? Technically, I suppose you could run Windows 10 on the first MacBook and MacBook Pro models, if there are drivers for the hardware, but....
It used to be that Apple hardware was usable a lot longer than Windows hardware. I hope Apple gets back to that, because this "supported until a few months after AppleCare runs out, and then you have to buy a new machine if you want security updates" crap is for the birds. But I digress.
Just to be clear, the question was not whether the first-gen models still work (though I do tend to feel uncomfortable continuing to use them much past when Apple stops issuing security updates, particularly now that they're using Intel CPUs and have a much larger market share). The question was what models of Apple hardware was below average at the time, but became popular because of the polish (UI design, etc.). And the answer is, IMO, all of them. They all paired more polished software with hardware that was subpar (or at best, barely par) by the standards of the time.
And all of the second generation models have been miles ahead of the first-generation models—with the improvements in subsequent generations being considerably smaller than the difference between the first-generation and second-generation model, for the most part. That's a pattern that Apple has consistently exhibited all the way back to the original Apple I.
*shrugs*
I find functional programming to be dubious as a general tool, because it doesn't map onto the way people think about doing things. When I think about how to cook a meal, I think about putting particular ingredients together. I don't think about creating a list of items and combining operators, then magically evaluating those combinators all at once and getting a cake. The entire notion of lazy evaluation is simply antithetical to the way most people think about doing things. Functional programming, to me, ranks right up there with C preprocessor macros in the "Ooh, neat, I can do horrible things that will terrify mere mortals, but I probably shouldn't" category. I've done it; I understand it; I can't imagine ever, at least while in my right mind, trying to write a real-world application with it.
By contrast, OOP at least maps fairly cleanly onto the procedural mindset that most people use when describing processes without having to introduce clever hacks like monads. And OOP can be done well; I've just never seen it done well in Java. I can only assume that this is because most programmers learn by reading other people's code, and when you get enough terrible code out there, the natural trend is towards producing more terrible code. With that said, I've seen lots of Objective-C code that is reasonably well architected. I've seen lots of code written in C that uses structs as glorified classes that is mostly well architected. I've seen PHP code that uses classes well (along with a few absolute abortions, but I digress).
Pick just about any of their recent new lines:
Don't get me wrong, I like Apple and their products, but I learned long ago to avoid being an early adopter whenever possible. Burn me three times, shame on you; burn me four times.... :-D
Flip side, I bought a '99 Ford Windstar. By about 120k miles, I:
So forgive me if I laugh at the notion of an Apple car being a money pit. It can't be much worse than that.
Not sure why people learning Pascal, assembler, or Lisp first would be better at OO. There's nothing OO about any of those. I would turn that around and say that 95% of programmers are bad at OO programming, period, regardless of what language they started with. Most folks frequently forget what are, IMO, some of the most basic rules of OO:
A class should be a mostly self-contained. If you have two or three classes that are tightly coupled, you should probably merge them into a single class unless there are data structure reasons not to do so.
A subclass should be used only when all of the following are true:
Otherwise, if the behavior differences are minor, or if the functionality you're changing requires hundreds of tweaks, each of which is different from the next, you're probably better off using a property that switches from one behavior to the other and just using "if" statements.
As I said, most software companies these days can take advantage of infrastructure like iCloud to avoid keeping their own databases. This makes it somebody else's problem. If Apple loses all of the iCloud data, it would be an end-of-the-world-level crisis, as I said, but there's no feasible way for individual software companies to back up that data, making it entirely out of their control.
Amazon, of course, is different in that some of their cloud services are much closer to being servers under your control. If you're using that sort of service, then yes, you have to have a disaster preparedness strategy, even if that strategy is as simple as replicating the data on a geographically distant server continuously, and building backups into your schema. However, as software companies go, those sorts of needs are the exception, not the rule.
Maybe true, but you can get a cloud server deployed in a matter of minutes, and you can use that as a temporary (expensive) alternative to servers under your complete control.
You're making a lot of assumptions that aren't necessarily valid. The amount of downtime and the impact depends heavily on the nature of the company, and in particular, whether sales/income depends on maintaining continuous operation of the business. Take, for example, a company that makes software:
So unless a software company requires critical server infrastructure beyond what they get for free via iCloud, etc., it probably needs very little in the way of disaster preparedness, because the very nature of the work and the tools involved lends itself to being prepared for a disaster automatically.
On the opposite end of the spectrum, cloud service providers and Internet service companies must have disaster preparedness plans in place, or else everybody who uses their services is screwed. And if they're down for even a couple of days, they're probably going out of business. If Facebook went down for a week, Google+ would become the #1 social network.
Of course it does. Download the DMG, and copy the DMG to a dozen machines before you agree to the license. :-D
But in all seriousness, if there's no practical difference between downloading it 17 times and downloading it once and installing it 17 times, then the law would almost invariably consider them equivalent. And Apple doesn't forbid you from downloading it 17 times and installing each copy to a new machine, so you should be in the clear even if Apple were insane enough to try to sue you for doing it. And of course, there's no way Apple would ever be crazy enough to do that, making the whole point moot (in both the American and British sense).
Unless something changed recently, AFAIK, iOS MDM only provides the ability to back up managed apps. While that may or may not be a problem for businesses (depending largely on corporate policies, whether they're doing BYOD, etc.), it wouldn't be very practical for general use. And it would still require a separate computer to manage the backups, and unless you did some tricky configuration involving pre-mounting the NAS at a specific path (which OS X tries to make as hard as possible), even an MDM solution would still be backing up to the computer which, in turn, would have to use OS X's normal backup scheme to back up the backup to the NAS.
The part that makes it most annoying is that because of how locked down iOS is, it isn't even possible for a third party to add this feature that Apple left out, whereas at least in theory, it should take minimal effort for Apple to do it (by adding their existing diskarbitrationd, smbfs/afpfs, and backupd daemons/tools/kexts to iOS, plus a little bit of UI glue to modify backupd's prefs file). Grr.
It really is. The one thing I absolutely hate about iOS is that Apple still has not added any automated LAN-based backup capabilities. I can back up my laptop and all my other Mac hardware to my fireproof NAS (and before that, to my Time Capsule's external fireproof HDs) with minimal effort, but it is impossible to back up my iPhone to that NAS except by backing up the phone to my laptop and then backing up my laptop to the NAS. That's tremendously clumsy and amazingly un-Apple-like, not to mention that it wastes a colossal amount of my laptop's hard drive space for no good reason.
I'm surprised businesses put up with it. If I were running a business, I'd be very concerned by my employees' devices storing backups on Apple's servers instead of on local servers under my control. Apple would probably have a coronary if their employees kept any Apple confidential info on an Android phone and backed it up to Google's servers, yet they expect everyone else to do exactly that.
Apple needs to get serious about backups on iOS. IMO, it is way past time.
In my case, I used to use cloud backups, but at some point, I hit the capacity limits of the service. Then, they started offering higher limits at a reasonable price, so I could reenable it, but apparently I forgot to do so. With that said, the reason I did the backup is that in two weeks, I'm going to be getting a new phone. At that point, all that data is going to be coming back down, which means speed will be important again.
The thing is, the network quality might be terrible, but with few exceptions, it usually isn't "the network just went down for half a minute or longer" terrible. The problem is that they don't buffer enough. If you have a big enough buffer, playback won't glitch. If you don't, it will. And the definition of "enough" is highly variable, which means that the playback software needs to keep track of long-term trends on a given network. For a fixed installation like a cable box, there's no excuse for not doing so.
The two are inextricably connected. Part of knowing how to stream video properly is understanding that reliability is not optional. If you can't reliably play video, your customers will leave. Inadequate buffering might save you money in the short term, but it costs you customers in the medium to long term.
No, I think they mean you need to get 10. Which means, at least around here, that you need to pay for at least 50.
If a streaming provider glitches that badly, it means that they don't know how to do video streaming. It isn't rocket science. You ensure that you buffer enough to keep playback going, starting at a bit rate that is lower than your connection's average speed initially so that you can buffer ahead. You then transparently switch to a higher quality stream (if available) after you've built up at least half a minute of buffer. And if you detect that the buffer is shrinking, you begin buffering progressively lower-quality streams until it stops shrinking. If the network performance problem goes away, you can always switch back to the high-quality stream and (if the performance is dramatically better than expected) opportunistically replace chunks of the lower-quality buffered data with higher-quality versions, beginning with the oldest content, in an attempt to avoid the user ever seeing the lower-quality version.
The problem is not the speed of the connection. The problem is pencil pushers at the content providers who try to micromanage the amount of data that they provide, giving you the bare minimum amount of cached data necessary, so that when you stop watching, they won't have wasted any data sending you content that you didn't watch. This approach is ineffective, and results in constant glitches if the network connection speed is variable. Unfortunately, that approach is all too common.
Most users don't need more than 10 Mbits/s averaged over a week, but most users will swear at their ISP at least once a year unless their connection is nearly an order of magnitude higher than that. I just did a full iCloud backup of a 64 GB iPhone 5 for the first time in a year. Had I used a 10 Mbit/s connection, given how much slower upload usually is, I'd expect to have only around 3 Mbit/s upload speed, which would mean the backup would have taken more than half a weekend. That's barely even usable. Forget being satisfied.
There are a lot of those companies, and the names of those companies keep changing, because they keep going out of business after two or three years. After all, it doesn't take long at those levels of abuse before most of the competent engineers start looking for other options, leaving mostly the people who can't find a job anywhere else. Such mass departures are usually a harbinger of doom for the companies involved.
If you want to find a job that doesn't suck, look for a pre-IPO company that has been around for at least five years or whose founders have started other successful companies in the past. Odds are, companies in either of those categories aren't being run by total clowns. :-)
There's really no good reason to stick around at a startup that is being run into the ground by management like that. The idea of a startup is that you take slightly less pay than you might get at an established firm in exchange for the hope that your options might be worth something someday. However, those stock options are never going to become valuable if the company collapses under the weight of its managerial ineptitude, so you might as well consider them worthless, and try to find a better job.