I've read about this guy's idea, and I can see why it won't catch on. It feels very nanny state. It seems like if we're going to mandate technology to stop people from using cell phones while driving it should be handsfree technology. If we give teens (for example) a good handsfree alternative to texting in the car, they'll use it. So, let's not spend the money trying to jam communications, something that feels very nannyish and is likely to be worked around by drivers. Let's spend the money and give people and incentive to put down the phone and drive. Handsfree texting and calling would do this. Ford Sync does this, but the system is quite inferior to Siri or Google's voice recognition.
I never knew that. Are you American? I was absolutely never taught that, and I've never seen any sign which implies that is the correct action. I hate roundabouts actually, as they instill anxiety in me.
I love minivans. I spent the best years of my life in a minivan, as a teen and young 20-something borrowing the family minivan. I loved taking a road trip with 5 friends. I loved the comfort. But minivans are not superior to crossovers (which have largely replaced SUVs in the market) in design, fuel economy, safety or color choice (!?). I've been looking to buy a people hauler, and I've looked at crossovers and SUVs. I like the Ford Flex and the Chrysler Town and Country (the classic minivan!). They are similarly specced in terms of fuel economy, price and safety. In fact, the Ecoboost engine option in the Flex gives it superior fuel economy to most minivans. Design? Not even a contest. The Flex wins. More cubic feet, more fit and finish (barely when compared to a T&C) and better powertrain options. The Flex is not an SUV, but crossovers have largely taken the place of SUVs.
I really don't see the value in minivans anymore. Crossovers are better, and wagons and hatchbacks are a solid option if hauling stuff is your goal. Even SUVs get similar fuel economy to minivans these days, sacrificing people hauling prowess per MPG and ease of drivability for superior design and bad condition drivability. You had some axe to grind, but I think you're like the person who rags in American automobile reliability: stuck in the past.
Tuition doesn't cover any use of university resources outside of education or recreation.
It does at the university I attended.
We couldn't find any of these users in our system, so we knew they weren't customers.
That is demonstrably poor reasoning. Anyone who puts their real name on yelp is an idiot.
What's more, most reviews were factually and demonstrably inaccurate.
Specious, and you've already demonstrated specious reasoning.
I hate to be the bearer of bad news, but you sound like a bad business owner, or in this case your friend is a bad business owner. You're demonstrating the telltale signs. Bad business owners often have a difficulty accepting responsibility. Bad business owners twist the facts to support their own side (you've stated that it not possible that these reviewers were customers). Worst of all, this business has attempted to retaliate against customers (I can see little to no reason to attempt to out the Yelp reviewers if not retaliation).
I have a Yelp account, and it's not in my real name. I leave bad reviews (and good ones). You could say I have a history of making bad reviews. You could also say that this business you are talking about has a history of receiving bad reviews. Yelp is far from perfect, but in business-friendly America, it's one of the most powerful tools we as consumers have to bleed dry bad businesses and bolster good ones. If this business wants friends' reviews visible, those people need to get more active on Yelp. That's it. That's the whole filtering algorithm as best I can tell. If you create a Yelp account for one single review, you get filtered. If you write more reviews, you don't.
That doesn't make any sense. You pay tuition to use those resources. Your output should be yours.
...any inner city youth, they are discouraged from learning because it's considered "acting white"
Wow. So, we're modding up straight up racists now?
In addition, I would challenge Charlie's and Chris's assessment of this. I didn't dig into it myself, but I would guess that a stateless gateway allows the radio to talk to the brakes in most autos, not just the few identified.
ONLY TWICE!? I apply ROT-13 no less than 20 times, 30 for e-banking passwords.
These this will naturally become shuttles and taxi services almost immediately. Given the protests of Uber and Lyft, what will the outcry be for these?
Well, given that the protests against those companies are mostly policy-rooted and not technology-rooted, at this point it is almost impossible to tell. Are you suggesting that these shuttles and taxis will defy existing laws and fail to get licenses? Then, I would assume that the outcry will be the same. If these hypotehtical taxis get licensed, probably none.
Someone should enshrine that in some sort of high code of law upon which all other laws will be based in some sort of new democratic society...
Every iOS device has a dedicated AES 256-bit crypto engine built in that is used to encrypt all data on the device at all times. In addition, the iOS Cryptographic Modules have been granted FIPS 140-2 compliance by the U.S. federal government on devices running iOS 6.
Emphasis mine. Sounds like doublespeak to me.
If passcode-protected whole phone encryption is enabled, no one should be able to access that without the key. I guess they know how it works more than I do. They've even redefined encryption. It's "encrypted" just like everything else these days. I guess it's still technically encrypted even if everyone has a key.
I guess that's a reasonable response. It fits in with the notion that SVN stores much more information in the actual repository. In practice, there are a few issues, however.
In a controlled (read: corporate) environment, the architect or lead or integration person may feel ownership over the repository, and, therefore, resist the excess creation of personal branches. In any environment, it can create a lot of clutter in the repo which leads to cognitive noise. Branches will be merged back in, potentially leaving a messier looking history. With the stash/shelve feature, when the code is finally committed, it ends up looking more like a linear development line. This, again, reduces cognitive noise.
I think having special "stash branches" in an SVN-like repo is an intriguing idea.
You're not alone. Git is great, but has a terrible interface. I know many respectable and intelligent software engineers who find the interface difficult. It goes beyond RTFM. OTOH, SVN has an amazing interface. Very well thought out. I think SVN would be just as great as git if not better if it added in some of Git's features.
What's cool about git?
- Distributed and offline operation. Repositories are local and can be "synced" to one another when online. There can be a central repo with which everyone syncs, or syncs can happen between individuals' workstations. It's hard to describe to a someone who's never used distributed version control exactly why this is great beyond the offline part of it.
- The stash/shelve feature is sorely missing from SVN. Ever performed an updated with uncommitted changes? It sucks. If you stash beforehand, it drastically reduces the possibility that you lose any work, as you can systematically revert to the previous working state. This is a 100% client side solution, so could be added to SVN without breaking any compatibility.
- Staging. All files are manually chosen for commit before a commit. In the most basic form, tracked and modified files are not automatically committed). Staging is actually a little more useful than that, but I don't know if I can describe well enough how. Again, totally client side operation.
- Auto-merging excellence. Git does makes a lot more merging automatic by using more history in the merge process. This can be done by subversion, but is somewhat of a divergence from how Subversion has historically treated changes. Most people agree that the git way is smarter, and should probably influence SVN's future direction IMO. Git's merge strategy would be implementable completely in a client. SVN saves more information in the repo than git.
- Rebasing. This is essentially a combination of stashing and merging. When changes are made to an older version of the code, a developer needs to pull in the new software and then merge in his or her changes again. Rebasing does this automatically (essentially using stash before the update and the excellent git merge algorithm to reapply those changes to the updated code).
In conclusion, Git is great, but you're not crazy for finding the interface insurmountable.