Sorry about your friend. Good on you for helping him out here.
Unfortunately I don't know of anything in the way of custom joysticks/setups that might be helpful, but maybe I can offer some reassurance for your friend. Even with the standard input devices (mouse/keyboard, controller) people have been able to adapt to very extraordinary circumstances. Anything's possible.
>Prosecutors say they don't have the entire thread — instead, they have three comments on a cell-phone screenshot.
There's so many things that make this situation _ridiculous_, but this takes the cake. I would have thought that in a case dealing with a few sentences, the full context of those sentences would be important.
I've been aware of this story for a while now and it always boggled my mind. But after reading this, there's some very troubling things going on that I didn't even know about.
Hope he can get out from under all this, recover, and move on with his life.
Very cool. I think an interesting feature would be to plot songs along the graph as nodes you could hover over. You could see the artists' and songs' information, maybe the word frequency in those songs. I suppose you could look for radical changes in slope to figure out where to place each node, too.
> I made a few abortive switches to Vim that didn't last a week because my productivity was too hampered and the environment too extreme & foreign.
That was my experience as well. I was pretty comfortable using vim in emergencies but the few times I tried to make it my full-time IDE failed very quickly. Once I stole Gary Bernhardt's dotfiles I was able to stick with it because I didn't have to start from scratch with keymaps, plugins, etc.
* A core engine that understands the code you write.
* The ability to run this engine in the background.
* A unified API that would make possible for plugin authors to interact seamlessly with that engine but also between each other.
* Certainly a thousand of minor details.
You can add as many fancy plugins as you want, you'll never get an IDE.
You'll get something that looks more or less like an IDE and works more or less like an IDE, but not an IDE because an IDE is not a text editor with a file explorer on the left, a class explorer on the right and a list of compile errors underneath. It is much more than that and Vim doesn't have and can't have that "much more".
Unless you count external compilers/debuggers/profiler/linters as that "much more" but that's still not an IDE. A DE, maybe, but certainly not "I"ntegrated. Well, not even an "E"nvironment, actually, given Vim's design principles.
I always forget when i've started these discussions sorry for the late reply.
That's a pretty narrow definition of an IDE, especially since the history of IDE's goes back far before a time in which any IDE could be said to have a core engine that understands the code you write. In fact that "requirement" is almost entirely driven by the rise of Java and the ridiculous amount of code it forces you to write. Prior to Java IDE's I can't think of a single IDE that could be said to have such an engine, including Visual Studio who's features in that regard were driven by competing features in the Java world.
The 2nd requirement is obviated by the lack of the first; the 3rd and arguably the 4th are already present in vim. An IDE, at its core, is exactly what you claim it is not: a text editor that provides navigation features (possibly but not requiring a class navigator—you seem quite focused on object oriented features) and an ability to run the code under discussion. Emacs very definitely is an IDE under the limited definition you provide, including an engine for understanding the code you write.
I'm also not sure about why you think external compilers/debuggers/profilers/linters are disqualified from being the core engine you're fixated on—you realize that every IDE out there does exactly that, right?
You can switch rubies rather seamlessly with rvm. Not a Ruby dev (yet) but I assume showing you the version at all times will hopefully stop you from wasting time debugging a problem with the wrong interpreter.
#2 contradicts itself. It says that unit tests will make sure that code that already works doesn’t break but at the same time it won't help writing good code. Well as far as I'm concerned, code that breaks can't really qualify as good code. Writing tests first, or writing code to the tests is ridiculous. Not sure what writing code to the tests actually means, is that even correct English (I'm not a native English speaker)? The main benefit of writing tests first, is that tests do get written. It's too easy to say we'll write tests when we have time. If you discipline yourself to write tests first, by the time the code is written, the tests are written as well. Writing tests first also saves a lot of manual testing time (eg. clicking over and over in a UI), which is repetitive and stressful activity. Overall testing and TDD help a lot to achieve #11.
#19 is an amusing caricature, but misleading. Design Patterns are not limited to GoF patterns. They show up at different levels of abstractions and give developers useful vocabulary to communicate about stuff they do anyway. #19 mentions 2 patterns that are not very useful in our daily lives, but they are patterns like MVC, observer or iterator that we use all the time without even realizing they are patterns. The point of patterns (design, coding or architectural patterns) is not to memorize the GoF list but to learn to identify, label and share recurring solutions that we can reuse in various situations.
Not sure what writing code to the tests actually means, is that even correct English (I'm not a native English speaker)?
It’s idiomatic, and it usually has a negative connotation. An analogous example is criticising a school for “teaching to the exam”, usually implying that the school’s teaching is inappropriately prioritising getting the student a good grade in their exam, at the the expense of giving the student a good general education in the subject.
Here’s a contrived example of writing code to the tests, in the negative sense. Given this test:
assert(add(1, 1) == 2)
we could write this obviously broken implementation of the add function, which is nevertheless the simplest code that passes the test:
In Kent Beck's "Test Driven Development by Example", he starts just like this, with an insufficient failing test. Then he writes a minimal function that passes it. Then he adds another test, then improves the function until it passes both. By the time he's done, he's got tests for all the edge cases he could think of.
I think it's a great way to make sure you cover all the edge cases, for a sufficiently complicated function. I don't have the patience to write all my code that way, though.
Yes, it is. The point is that even given many additional test cases of the same type, they will remain insufficient, unless of course you’re planning to test the entire input domain, which I imagine is going to take you a while.
Clearly at some stage you have to replace satisfying isolated cases with some form of generalised understanding. At that stage, you’re no longer coding to the tests.
This is not to say that unit tests can’t be useful. On the contrary, I find them a valuable tool for many programming jobs.
However, as I have observed before, the plural of “unit test” is not “proof”. I do find it frustrating when I see overconfidence instilled in too many developers just because they have a suite of unit tests available. Using TDD can’t magically guarantee that a program actually satisfies all of its requirements. Refactoring without thinking isn’t magically safe as long as the code still passes the test suite. Writing code to the test is not a substitute for understanding the problem you’re trying to solve and how your solution works.
> #2 contradicts itself. It says that unit tests will make sure that code that already works doesn’t break but at the same time it won't help writing good code.
No, the only thing you can say about the quality of code through tests is that if you change some code and it still passes the tests, then you didn't break it. The tests say absolutely nothing else, because their output is binary - pass or fail. They say nothing about the efficiency, readbility, complexity, or style of the tested code.
Tests can help take you from broken code to working code, and not a step further. To make it good code, you have to look at the code, not the tests.
There are times when clean code that almost works is better than messy code that actually works. Generally when the requirements are still fuzzy. But also when your still deciding were to handle edge cases and such.
Just a guess, but I think it's because the message should indicate what the commit itself does, not what _you_ did to write it. For example, by merging this commit, the result is that I "Add X widget" to my code.
This is exactly how I describe this idea to people. I tell them to complete the following sentence. "Applying this change set will...". I've recently become less averse to verbs like fixes, updates adds, etc as I feel the sentence "The change set..." is still pretty good. The key, obviously, being you're describing the change set, not your actions.
I'm curious what kind of sensitive information you're concerned about exposing. I don't mind deploying with rsync--in fact, I'll do it quite a lot when the remote host lacks git--but I'd usually prefer to use git where possible.
I typically deploy with a similar setup that you described, but instead of rsync'ing the files locally I just make a clone of the repo and serve that. Though it is another step to fetch/merge, it stops me from losing any changes that someone did to production without telling me.
I only recently used Capistrano to deploy a project and it was very satisfying, so I'm gravitating towards that as my default deployment method.
> I could appreciate it a lot more when I understood what kind of problems were Newton and Leibniz trying to solve when they came up with the formalized notion of Calculus.
This always bothered me in many of my math classes. We'd go over a new formula or concept and just hammer it home until it stuck. Professors rarely gave real-world examples of the topics they were teaching or indicated to the students how these new theorem interacted with others. If I asked them explicitly I might get a more practical explanation, but it was rarely offered to me without inquiring first.
I used to have a lower opinion of people who'd complain about learning math because "it's so pointless, I'll never use any of this." It bothered me that they just didn't want to learn something new. In hindsight, even if that were partly true, I can't blame them for having that attitude because it may have been partially instilled in them by their professors.
I'll never forget the feelings I had after I connected the dots in my head and noticed the relationship between integrals. I knew that integration would give me the area underneath a curve, but now we were learning about double and triple integrals for surface area and volume. It dawned on me that I'm basically doing the same thing I was before, albeit in several planes with more curves. I remember a lot of different emotions: appreciation for the sensibility and beauty of mathematics; pride that I figured something out on my own; but also a tinge of frustration that this revelation was never encouraged by my professor.
Exactly! You were fortunate enough to realize this during your course itself. But a vast majority of students never stumble upon this revealation and treat Maths as another chore that needs to be done with.
The insight you described is what Math classes should be about, not practicing problem after problem without any knowing what or why.