When 90% of your "students" fail to complete the courses, you have an epic failure on your hands. MOOCs are not working.
I completed every course I signed up for when I was going to university. Completion percentage was important because I was, and still am, paying to be there. As a result, I enrolled in very little that I was simply curious about. Virtually every class I took was a step toward a degree.
Since graduating, I've enrolled in a handful of MOOCs. I've finished less than half of these courses, but they have satisfied my curiosity and have given me something new and different to learn. I most certainly would not have paid for the experience, but I feel I'm better off because of it. I'd say this is working and far from an epic failure.
It starts to look a little different when you see people trumpeting MOOCs as "the future of higher education," though.
The thing about MOOCs is that to attract funding, media attention, and participation from big-name universities and top teaching talent -- all the things you'd desperately want to have if you were the one pitching them, in other words -- they really need MOOCs to work as something bigger than just a sideline for the intellectually curious, because the market for "a sideline for the intellectually curious" isn't big enough to attract any of those things on its own. It's a niche market at best.
Higher education as a sector, on the other hand, is anything but a niche market; so if MOOCs could be positioned as The Future of Higher Education, the thing that is going to replace universities in the 21st century, that would suit their advocates' interests nicely. But the data coming out of the MOOC experiments to date make them look less and less like the sort of thing you'd want to bet your kid's future on exclusively if you had any alternatives at all, which undermines that positioning.
For people fully devoted to studying, and with some sort of extrinsic incentive to complete the courses, I imagine that the completion rate would be significantly higher. When I was at MIT, some of the courses worked almost exactly like MOOCs do now, and just as many people completed those as the traditional courses.
With MOOCs, a ton of the takers are not full-time students. I've taken some MOOC courses and only completed one (probabilistic graphical models). The main reason is that I have much higher priorities now, and the courses are on a strict schedule. The first time there's a choice between getting a piece of code finished that I need for a business deal done and finishing a problem set, that problem set is not getting finished.
In other words, it works as much as you want it to work. Similar to how a "real" college experience works, with the difference being a significant financial investment.
I haven't used a serious app in production on OpenShift, but I have been playing around with a Java project recently. Assuming I get it to production, I'm going to stick with OpenShift. I think the blogs, forums, and docs are great.
I started out with gradle and embedded jetty, and found no out-of-the-box support. They did do a nice blog post on how to use gradle for builds[1]. Unfortunately, the blog uses gradle version 1.6 and that's the last gradle version that doesn't throw an exception while building[2].
Wanting things to be easier, I switched over to maven[1] and tomcat:
OpenShift has supported Apache Maven as default build system for Java based projects since the first release.
Since going with this setup, things just work.
I also really like that the environment configuration is stored in the codebase under the .openshift folder. This makes it very easy to, for example, develop locally against http but make all your traffic go through https on OpenShift. And the free piggyback ssl means https just works too.
Flask and Rails have different focuses. I've used both and like them both quite a bit, but I've found there is often a clear winner depending on the task at hand.
Flask is a microframework that often fits within one file and is probably more comparable to Sinatra than Rails. I've only ever used it for setting up really small webservices and stubbing webservices. It could certainly scale up to larger apps, but it doesn't give you a lot of direction in how best to do so.
Rails is a full-stack framework. Out of the box it gives you everything from the view to the database and strong conventions for where to place classes as your app grows. In general, it's more often compared to Django.
> Buying whatever Nexus is out there when I needed a new phone has always been a no-brainer. Not so anymore.
Interesting, I would not have expected so much importance to be placed on unspecified rolling updates.
My current phone is the only Nexus device I've ever had, but it was easily my best unlocked option at $250-300 US. I think that holds whether it's running 4.2 or the latest.
> Interesting, I would not have expected so much importance to be placed on unspecified rolling updates.
The Galaxy Nexus was sold on software and on software alone. It's hardware was if not underwhelming, certainly not best of breed available in the market when it was launched. And it was launched with a price to match high-end phones from other Android OEMs.
If you bought this phone, you bought it because you wanted software updates.
And when you consider today's smart-phone market, phones have enough RAM, CPU cores and god knows what. New hardware is not really that interesting. All the good, new and exciting stuff happens in software.
From that point of view, Google just shit on the only thing which made the Galaxy Nexus worth buying in the first place. They just outright told the market: Not even a recent Nexus is guaranteed Android updates.
Nexus One and Nexus S buyer here. Had a terrible experience with both these devices. The way I see it, customer service isn't a priority on these devices. But the devices are pretty open so the community finds solutions.
I'll give you a shocking example. There was a bug on one of the Nexus devices I owned where if you were in a deadzone for more than a few minutes, the radio would crash. I kid you not! The stupid radio would crash whenever my train went into the deadzone of the Grand Central approach. No fix, no official word. Then, some programmer released a free app where if your radio was out for more than 1-2 mins, it would automatically shutoff your radio. Got me going. This is why I would not suggest my wife or any non-tech person to get a nexus device. If you are a tech person, it is probably okay. I'm considering a Nexus 5 myself.
While I can sympathize, the Nexus line's promise has always been shifting... Vanilla Android and timely updates were what Google were pushing for the GNex, but these days it seems to mostly be serving as vague mid-range price pressure? The only real common thread for the phones seem to be that they were primarily Google dev devices.
And while it might have been an implicit promise, sadly, I don't think long-term support (or any customer support, really) was ever much in the cards.
FWIW my Google devices (from G1 on) have all eventually migrated to CyanogenMod, where they've run better than they ever did on stock. While CM isn't rushing to 4.4 (the plan is to land 10.2/4.3 before starting work on 10.3/4.4), updates have always lasted longer than I've wanted to keep using the devices. (if you have a GNex, give CM10.2 a try. It blew my hair back. Felt like a brand new phone.)
To me, having unlocked bootloaders is a bigger selling point than stock updates...
I won't be upgrading to the Nexus 5 mainly because I don't really see much improvement over my Nexus 4 w/ CM 10.2 - I have unlocked LTE that works great w/ T-Mobile where I am, it runs quick/smoothly enough, and well, the camera apparently is still bad on the Nexus 5... (that's what the 5s is for)
Fair enough, I'd be reacting similarly I'm sure. I get that two years is too short, but how long do you expect a device like this to be supported? I think I recall three major updates for my original iPhone, but by the last update it was almost unusably slow.
Google changed versioning schema when rolling out Jelly Bean. On Gingerbread, the various minor updates was versioned 2.3.3, 2.3.4, etc. On Jelly Bean, they were version 4.1, 4.2 and 4.3, but they were all still minor updates.
When you look at it that way, the Galaxy Nexus received one major update and that was it. That's less than most "flagship" consumer devices sold, which typically receive at least two.
As for what I expect from a Nexus, I demand a minimum of two, but find it reasonable to expect three. From this, it seems clear that Google has completely lost its commitment to the Nexus-brand, and to me that makes the Nexus-brand completely uninteresting.
I live in that ancient belief that you should be able to keep your phone functioning happily for 3 years, which is exactly what happened with my iPhone 4, by iOS 6 it became slow and kind of crashy but usable and it did everything I wanted it to (even if it didn't get all the new features like the new navigation or Siri).
But the main point is that it kept going for more than 3 years, and the Galaxy Nexus, a phone that was really expensive at the time does not get the new update just a year and a half after release. That's half of the lifetime I expect of a phone.
I've always found it a lot more effective to sit down with someone and find the answer together, no matter how simple the question. If our technique works well, I've found they'll generally try it again the next time they have a question.
Unlike sending this link, figuring out things together doesn't leave teammates avoiding and dreading interactions with each other.
> Hyperloop is all about passengers (something the rail industry has never cared out)
This is disingenuous. In the 150+ years of North American rail, many of America's most intricate architectural structures[1] are train stations, and they certainly weren't making that investment for freight. The dining car service was also typically a loss leader, designed with the sole purpose of attracting customers. Freight never complains, though, and ends up being much better to transport.
Yes. As an industry, we're not very good at recognizing the great things people do. We tend to focus solely on mistakes. It's not easy to admit failure, and if we want it to continue we should recognize the effort it takes.
> There even exist situations (in the case of some positions) where you will be talking to a client of the company you're working for, effectively interviewing with the client, representing the company.
What positions would require you to prove the technical capability of your company at this level?
I've been working for a consultancy for a few years now. I can't recall a time when a client asked me to describe a closure or what I thought of !important. If I'm on a development team, the conversation with clients is generally about the time and effort required to implement something, or the options we have for delivering the functionality. If I'm pulled into a sales meeting, it's usually high-level architectural discussions.
Funny you should ask. I was JUST interviewed by a client of a local consulting company I work for periodically, and he asked all kinds of technical domain questions. Different domain than JavaScript, so different questions. I'm not even sure what's meant by "!important", honestly, though I do know what a closure is.
I'm not an employee of the consulting company, but I COULD be if I asked, and in that case I would have been in that exact situation. I just prefer my contracting status; the upshot is that, not only did I do an interview like that, but I did it for free, on behalf of this company.
My GF had to go through a round of technical interviews with clients after opting to accept a job with a contracting firm. The firm fills the various contracts they receive with employees, but the clients want to greenlight the employee before they start work.
That might just be contracting with the government though.
> Why can't I go online and order the Jeep (or whatever else) I want and have it delivered or pick it up from a non-jackass?
True, you can't go to Amazon Cars or equivalent, but there are options. Have you tried the internet sales department? Edmund's called it "a valuable time- and money-saver."[1]
> I wish the car manufacturers would get with it.
It's not like they haven't tried to make the buying experience more pleasant. Saturn was doing no-haggle pricing as early as 1990[2]. Scion is doing it today[3]. Gut feel is that the buying experience just isn't that important to most people with durable goods. The car is what brings us into dealerships, not the sales staff.
> Screw going to amazon et al to buy anything that changes as constantly as a car. or a cellphone.
You've made it clear you're a person who requires extensive test-driving. Amazon's cell phone business doesn't seem to be hurting. I've ordered my last two cell phones online sight-unseen. Same for recent laptops and a Nook. I'll take the uncertainty of holding a modern device over the sales staff.
> I bet my right arm that you wouldn't ever buy a car from amazon if you couldn't test drive it at the local shoddy dealer.
The average car age in the US is now 11.4 years old[1]. My car will likely be 15 before I get another one. In VW's terms, that's at least three generations of progress. I'm buying a car for a decade, and none of the problems that come up in a decade will be revealed by a test drive.
Regardless, I merely agreed it wasn't currently an option and the parent may have a better experience with the internet sales department of his or her local dealerships.
What country are you in? In the US, you can see Kindle at any Wal-Mart, Target, Best Buy, Staples, OfficeMax and several other national retailers that cover most of the country.
I've got a DX for reading technical books. It's great for that. If you intend on reading tech books on a Kindle, definitely get the DX or the big Fire HD! The little paper whites aren't going to cut it.
Since graduating, I've enrolled in a handful of MOOCs. I've finished less than half of these courses, but they have satisfied my curiosity and have given me something new and different to learn. I most certainly would not have paid for the experience, but I feel I'm better off because of it. I'd say this is working and far from an epic failure.