Or there's always the best of both worlds: http://www.duckduckgoog.com/
94 karma · joined February 12, 2013
So, since I have the opportunity to fanboy out a second: thank you for your contributions, both to gaming and human-computer interaction.
As Docker matures the need for these case studies becomes more apparent. Thanks again for sharing.
* Not to downplay those initial examples. Without the baby steps those examples provided, I would've been lost at the beginning.
You've nailed it sir. Shape coding[1]. If it's good enough for F-14 fighter pilots, it's good enough for my Toyota Camry.
I echo the sentiment of others. The OPs heart is in the right place here. Mimicking sight free displays on a touch screen is laughably terrible. Take this picture [2] from OPs post. Why are the media buttons ellipsoids? They're just smaller targets to hit compared to squares!
In academia, we've been researching this problem, eyes-free mobile interaction, for a very long time. Particularly in the context of interaction while walking.
There are numerous approaches (e.g., Flower menus [3], utilizing pressure [4], utilizing motion [5], the list goes on). The big takeaway is that it seems like more successful systems result from the multimodal approach.
OP, you've done some good work here, but consider incorporating other sensors. Voice? A camera for in-air gesture recognition? A biometric sensor that gives reasonable defaults automatically based on learned use of the driver? Touch is only one part of the problem if we move away from shape coding, and we will very likely need to utilize multimodal input if we hope for success...
...or, you know, we could just stick to that whole buttons and knobs thing.
-----
[1] http://en.wikipedia.org/wiki/Alphonse_Chapanis
[2] http://matthaeuskrenn.com/new-car-ui/images/statusquo.jpg
[3] http://www.youtube.com/watch?v=QRSASiEBw5k
[4] http://www.mobilevce.com/newsite/sites/default/files/infosto...
[5] http://katrinwolf.info/wp-content/uploads/2013/05/MobileHCI2...
You're absolutely correct about using non-parametric tests, and more scientists should be using them. The normality assumption is flat out laughable when using real-world data most of the time.
You're also correct about multiple hypothesis testing. Accounting for familywise error (e.g., Holms adjustments) can help to keep your p-value reporting honest.
That doesn't negate the underlying problem, though. A p-value is simply an indication, nothing more. The p-value never promised to be more than that. The issue isn't in the p-value's construction, the issue lies in its misuse and how easily it can be abused in statistical reporting (see: p-hacking).
The p-value as a test statistic is perfectly honest in my opinion. But like many other statistical methods, it comes with its own set of baggage that I feel gets conveniently glossed over more often than it should.
Burnout for me feels like the third day of that all the time. A fatigue so deep it's almost an ache. The thought of booting up your IDE feels like the equivalent of sitting through a lecture after that third day of little to no sleep. Sure, you can do it, but it just seems like such a chore.
That's burnout. It takes the things that invigorate you and turns them into chores. Then it breaks both your legs. Have fun getting your chores done.
In the absence of "best practices" even a discussion thread somewhere that allows Docker users to pick apart and discussion configurations would be helpful. Pretty much all I've been able to find is a smattering of blog posts.
Thank you for taking the time to write this, just to emphasize these two pain points. I've been using Docker since 0.5 and my current setup is still based around sharing from host to guest. The problems you mention obviously aren't deal breakers (at least for me), but the accumulated effort of dealing with these issues (especially having to modify permissions) adds up over time.
Here's a concern and a hypothetical, though, and I'd like some insight (or a facepalm) from others if I'm wrong...
Say I'm collaborating with a few people on a Rails app and we all work within a Docker container we build from a DockerFile located in our source control and we use the guest-to-host setup you outline. What happens if one of my developers accidentally pushes that container to Docker's public registry? Is my billion dollar ( ;) ) Rails app stored in that container and suddenly available for anyone that wants to pull the container?
I would hope the above is a far-fetched example, but with host-to-guest sharing I at least have some safeguard in knowing that my data is decoupled from my configuration. Is such decoupling worthwhile in your opinion?
RequireJS is incredible when it comes to managing dependencies and organizing JS code in general. Combine it with a requirejs task in Grunt to automatically optimize your JS code and you've got a real slick development-to-production JS pipeline on your hands.
Granted, RequireJS may seem a little funky at first, but I promise you taking the couple of hours necessary to learn its basics will make your life (at least when it comes to developing JS) much easier.
> I geared the original curriculum toward Python tools and resources, so I've explicitly marked when resources use other tools to teach conceptual material (like R)
Why did you choose Python over R? Personal preference, a bent toward Python in the online courses you found, or is Python generally considered the de facto language choice for professional data scientists?
I imagine you could tackle these courses with any programming language, but if Python seems to be the way the data science community is going, it would be helpful to know that. Personally, I'm curious because I'm trying to decide if I should pick up Python on the side to supplement the knowledge I already have of R and various other programming languages.
Also, thanks for putting all this together. It's great!
Docker as an educational tool can be pretty powerful. One of the most annoying parts of CS courses is the initial install/configure/dependency wrangling you have to do to install required applications in whatever courses you happen to be taking that semester. Since courses may have different and conflicting requirements, just preparing your machine to use for coursework can be a nightmare.
Docker solved this problem for me as a student, and I can imagine it being solved easily for others if professors would just latch on to it and provide DockerFiles for their students. Sure, OS X and Windows users may have the initial hassle of setting up VirtualBox or what not, but I think the trade off is worth it. And when the course is over, there's no longer a lot of development software sitting around your hard drive that you may never use again. Take any source you developed, the DockerFile you used, throw it all in a repo and then you can easily replicate the build environment if you need it later on.
As a developer, I use Docker to replicate "large scale" deployments on my own machine. Typically this is just a database container, a nodeJS server container, and a container for my web application code. However, as an exercise I've spun up a container with NGINX to act as load balancers for multiple running instances of my webapp container. It was simple, repeatable, and can be easily replicated on production servers.
Finally, onboarding of new developers becomes MUCH simpler with Docker. I developed bash scripts to quickly spin up containers for development and production workflows. So onboarding new developers to my codebase is fairly easy. I distribute the source code of the project, a repo that contains DockerFiles and bash scripts, and a small readme. Developers are typically up and running in less than an hour, regardless of their operating system of choice.
Anecdotal rebuttal: The first conversation I had with my research advisor concerned the difficulty of getting a tenure track position at a research university straight out of Ph. D. school. In her words, "that sort of thing just doesn't really happen anymore in this field (Computer Science)."
There are no delusions of academic grandeur, at least in my neck of the woods. I agree that the Ph.D. may be pursued as a career maneuver, but if your end game is a teaching position at a research university your approach to the program has to be very different (and extremely more ambitious) than someone pursuing industry or other goals. And if you're pursuing a prestigious academic position, you are quickly educated on the slim possibility of attaining it, even if you're willing to post doc.
Despite his intent, I believe that I left the letter thinking exactly what it was designed to make me think. Therefore, the actual mechanics of the letter (which were outlined well by tomstokes, in my opinion) were excellent at eliciting what I assume is the intended response. This is akin to successful manipulation, but may not necessarily be from a place of malice on the part of C. However, C's changing my opinion of psychopathy does in fact place him in a more advantageous position if the two of us were ever to meet, thus I was manipulated.
It was the literary equivalent of the cup-and-shell game. I saw the con happening right before my eyes and still got duped. Brilliant writing.
(Note: I refer to it as a con, but only for convenience. I don't think it's necessarily negative to leave the reading thinking exactly what the author wants you to think. The process C undertook for doing so was simply so well constructed that it didn't dawn on me that I was being expertly manipulated until tomstokes pointed it out.)
Constructive Criticism/ Devilishly Advocating:
In agreement with root comment, it's much saner to target employers, which you seem to agree with. Therefore, it seems like presentation of the information doesn't really matter to employers looking to fill a role when compared to how easily searchable, filterable, and readable (both machine and human) that information is.
Therefore, having the service become something more of a "General purpose learning tracking" tool feels at odds with this. Inherently increasing the noise in your system and making it harder for employers to find experts that possess the skillset to meet their need.In other words, it seems like general purpose accomplishment tracking would increase the noise (as presented to employers) and diminish the signal employers are willing to pay for. Have you noticed this issue or given any thought to how to handle it?
Of course, I'm not privvy to your back-end or what you're presenting to employers; the above criticism was just my first thought based on your reply.
Sure, but not all wedding gifts come from amazon...
EDIT - I stand corrected: http://www.amazon.com/gp/registry/universal/
That wasn't my intent. It's legitimately a great idea and a seemingly well executed MVP (I haven't dug deeply into it yet). Hence my suggestions being prefaced with "Incoherent Rambling"
It's hard not to see a good initial execution on an interesting idea and think aloud "I wonder where this could go next..."
In either case, OP, keep up the good work.
Incoherent Rambling: How about expanding to more than one item wishlists that span multiple site APIs and market it as a simple, efficient, online wedding registry replacement?
You can rank your items in terms of preference, people can contribute money, then the app just buys and ships the items from the top down until the list is complete.
As a wedding gift purchaser I wouldn't have to make a trip to some random store and go through the hassle of getting the registry, nor would I have to navigate to a site I may never use again (I'm looking at you Williams Sonoma) and setup an account to purchase one item.
As a bride or groom it would be nice to just supply someone with one short URL when they asked "where are you registered?" without having to go through all the hassle of setting up a ridiculous "we're getting married" wedding profile on Yet Another We're Getting Married Social Network.
Like I said, incoherent rambling. Could result in an interesting tool, though.
Good OO programmers do some internal version of this process every time they design a class. For those that have been at it awhile, this process is probably so internalized they hardly even notice it. The OOP equivalent of muscle memory.
For example, the value in "underline and review the nouns" isn't underlining and reviewing the nouns, it's a physical manifestation of an important step in the OO development process. Namely, helping to identify requirements.
Have I ever gone through such a tedious process when designing a class? Of course not, but the steps outlined in the answerer's post take place in some form internally every time I need to design a new class.
I've done it for around $1100, excluding the cost of a laptop to run some open source flight control software, but ~$600 of that was a 9-channel RX/TX controller setup. Overkill unless you're doing some really crazy stuff.
It's not all sunshine and rainbows, though. I've worked closely with scientists that have had problems with SenseFly units in the field, despite the high level of polish in the product. I've flown similar sized UAVs to the eBee (all self constructed) in great environmental conditions (low altitude ASL, favorable wind conditions, etc.) and had great success. However, get these things in less hospitable environments, and things go sideways real fast. So, while Joe Everyman is getting closer and closer to just throwing a small UAV in the air and having it work, we're still quite a ways from guaranteed success out of these things.
Observation: I've never had good luck using a GoPro for mapping tasks. My suspicion was the rolling shutter, but perhaps I was just doing it wrong.