Hacker Newsnew | comments | show | ask | jobs | submit | Legion's comments login

> and about elaborate .vimrc's that take you so far away from 'standard' that you're crippled without them. Stick to a fairly basic standard install and a .vimrc of 50 lines, tops.

I think this is terrible advice. While it is true that one should avoid getting lost down the plugin rabbit hole, for many of us, the whole point of Vim is that it is a configurable, composable editor.

As for being "cripped" without my vimrc, well, moving tiny text files around is pretty much a solved problem at this point. And as a developer, I'd prefer to optimize my 99.9% of the time environment, and not worry about the .1% of the time I'm away from it.

I do, however, recommend that your vimrc is something you should build up over time, understanding what you are putting into it, rather than grabbing some big off-the-shelf framework and using it without understanding what is going on.


At my company, we switched from Sendgrid to Mandrill when we ran into some deliverability problems with Sendgrid that we could not identify a cause for, but which magically disappeared once Mandrill was doing the sending.


> This is an "all your eggs in one basket" issue.

And that's an incredibly valid concern, but at the same time, when you look at the other baskets and they're falling apart and have holes in the bottom, it's easy to see why people put those eggs where they do.


I trust the inevitability that Google's basket will eventually have the same fate. And it will be much much worse than anything we have seen so far.


Perhaps, but show me a better basket today.


Again. Multiple baskets will always be smarter than a single basket with everything in it.


Always? Really? So a bunch open, unprotected baskets in plain view are better than a single closed, locked and hidden basket? I'm glad you're not in charge of my security.

As others have said, the single-basket concern is perfectly valid. The reason you're getting pushback because you have a single-minded focus on that one concern and vehemently deny the possibility that there might be tradeoffs. That comes across as an irrational attachment to a single issue, even if what you're really trying to say is that your assessment that enough other baskets have hit a good-enough baseline that diversification is a good strategy. The latter is something you could have a productive conversation about. As for the former, you can insist that multiple baskets are the only thing that matter until you're blue in the face, but I doubt you will convince anyone.


In my opinion, the lockout-shortened 2012-13 NHL season (started in January, 48 game regular season) was the best thing ever.

Particularly in a country where NFL football reigns supreme, the NHL starting an 82 game season in October is just a loser. Starting the compressed season in January, with the NFL regular season over, made so much more sense.


This is absolutely true for real-world coding. However, for the purposes of an exercise, I think the fact that 15 was chosen was not an accident, but is part of the exercise. Does the coder recognize the relationship between the multiples, and recognize the ability to optimize by removing an extraneous comparison?

It's kind of a trivial test for that sort of recognition, but anything as small as FizzBuzz is going to be rather trivial.


As with most of these little tests, the actual question is, "Can you explain your decision, and does your explanation make sense?"

Really, the FizzBuzz test is a check to see if someone is bullshitting when they say they can code. Testing deeper than that is expecting too much of it.


Twitter's experience was also on pre-1.9 Ruby, ie. before YARV.

Ruby itself has made major jumps forward in performance since then. Much of Ruby's reputation for slowness was earned on an interpreter that no longer exists. It's still not the fastest dog on the track, but it is a ton better than those earlier days.


This is exactly what shadowbanning is for. You can see what Terry posts by opting in to do so.


This is proof that shadowbanning doesn't work. It's supposed to drive him away because he isn't getting any feedback on his posts. Instead, he continues to post, (possibly) aware of his banned status, and because of the fact that he built his own OS, seems to have become something like a mascot around here.

It could be argued that he would simply create another account and continue posting if his account were banned. That's one assumption, but of course, the shadowbanning system seems based entirely on assuming things about people. Creating another account if you discover you've been banned is what you're supposed to do, is it not? For all anyone knows, he would have moved on long ago if not for the way this site seems to act to keep him here.

Meanwhile, every now and then you read a post from someone who discovered they were banned for months, or years, for some slight they weren't even aware of. Apparently someone flipped the switch and decided they needed to go away in the most passive-aggressive way possible.


Neovim seriously has me so excited that I could scream like a little girl.

On a list of software projects I wish existed, a modernized Vim would be numbers 1 through 10. I enjoy core Vim, but the pain of Vim's limits when adding in new functionality with plugins (like pauses running Syntactic checks, or the hiccups and lack of smoothness of every autocompletion plugin ever) are a downer.


The biggest pro about Vim[1] is that I can open a hundred instances[2] without having my OS gasping for oxygen. I would very much love to see a modern UI, a clean plugin interface, etc., but I fear that those changes would make Vim as heavy as the competition.

I wonder if Emacs will eventually compete, though, both UI-wise and for cleaner plug-ins.

[1]: In my humble opinion

[2]: and I do, actually


> I can open a hundred instances

What's your use case? I'm curious.


When I am done working on something, and want to start working on another project, I don't close the previous project. I leave it in a virtual desktop. That way, when I wish to resume work on that project (or component of a project), switching to the correct virtual desktop is way faster than opening the console, going to the right directory, opening Vim, and opening all the relevant files. Besides, the local shell history is also ready to grab to start running all the tools I need for testing, debugging and general dev aiding.

Project switching, I find, is really hard, but it is made way harder by having to remember all the unique locations of files, directories and commands related to the project, and having to wait for everything to load.


I really like Sublime's workspaces system as a solution to this problem.

If you have a project open and need to switch to another one, Ctrl-Alt-P opens the project switcher. If you switch to another project, the previous project's workspace is saved. So when you come back to the last project, everything is JUST as you left it.

Alternatively, if you need to have it open in another window (for comparisons or whatnot), just open a new window before opening the project switcher! (Ctrl-Shift-N, Ctrl-Alt-P)


on [2] assuming gvim, try --remote-silent, vim buffers are much easier to work with than whatever app switching your os provides.


TDD is a means to an end, not an end in itself. I think some TDDers lose sight of that fact.

The end is well-tested code. Developers often lack the discipline to write tests after writing what appears to be working code. The point of TDD is to force that discipline by making it part of the process of writing the code in the first place.

It's a good technique that many use to great effect, but it is just that, a technique, not a goal in itself.

What matters is that, when you're checking in new code and pushing it upstream, that code has tests along with it. Whether you wrote the tests right before the check-in, or as part of a TDD cycle, is immaterial to everyone else.


I would argue the "end" of TDD is working, well factored code. It's a technique for continually getting rapid feedback on every code change that you make, working in very small iterations.

The fact it results in a regression test suite is a happy side benefit (and actually, some of the tests generated are inevitably short lived).

There are other benefits of working in this style. e.g You should nearly always have code in a state that could be deployed to production; It gives a rhythm for pair programming; It encourages a certain coding style.


EDIT: By browsing to the Github repo, I found the link to the One Big HTML page: http://www.greghendershott.com/fear-of-macros/all.html

Original post: I wish there was a single-page version of this that I could Pocket. Or an epub that I could put on my reading devices.

I don't tend to read multi-page things like this at my desk, not in this era of high-resolution lightweight portable screens.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact