Yes, that would be normal. During an acquisition the future is unknown so you don't have a reliable roadmap you can use to set or update development goals. Other activities that take away from development could be developers working on capability demonstration or participating in technical due diligence.
(I don't know anything about the rethinkdb situation, I'm just speaking generally here)
Ember is fantastic, the oldest projects I have are about 4 years old and have been (more-or-less) painlessly upgraded every now and again. Everything is ember-cli and ember-cli-deploy now. Time and time again it shows that Ember is a community project that has a strong focus on scalability and maintainability over time.
I also do a lot of work in Angular and React (this year) and all the tooling, build, best practices change every couple of months.
A lot of people complain about Ember's learning curve, but the things you learn _stay relevant_. Personally I'd rather invest in that kind of knowledge than learning yet another arbitrary build system.
That works very well combined with RFC 6902 - JSON-PATCH for partial changes to JSON objects, which in turn works nicely with HTTP PATCH method, RFC 5789.
Uh, Gates not a programmer? You might want to check your history. By all accounts he is, or was, an excellent programmer who definitely got his hands dirty.
"After two years building Branch and Potluck, I am thrilled to announce that we will be continuing our mission at Facebook!
We will be forming Facebook's Conversations group, based in New York City, with the goal of helping people connect with others around their interests. Their pitch to us was: "Build Branch at Facebook scale!"
Although the products we build will be reminiscent of Branch and Potluck, those services will live on outside of Facebook. A more thoughtful note and details to come soon but I am writing this haphazardly from a mountain in Japan (I was tipped that the story was going to leak while on vacation).
In the meantime, a huge "thank you" to our investors. Especially, Jason Goldman, Evan Williams, Biz Stone, Ryan Freitas, John Borthwick, and Jonah Peretti, who all spent an extraordinary amount of time with us.
Most importantly though, a big congrats to my eight teammates who have worked tirelessly,
often behind the scenes. So much and admiration: http://branch.com/company#team - on we go!"
Not to rain on anybody's parade here, but for first-time vim users I recommend not using any plugins and only selectively adding them one at a time after the basics (buffers, navigation, some ex mode, etc) are at least somewhat familiar.
Getting started with plugins enabled makes it hard to understand where vim stops and plugins begin and make switching to a different (someone else's) vim setup confusing at best.
It also tends to feed the 'make it work like the last editor I used' syndrome, which is completely counter-productive.
Otherwise, nice work and good job open-sourcing it!
Completely respect where you're coming from, but totally disagree. 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.
To a newcomer like me, Vim's built-in help was less than worthless, since you pretty much need to know the Vim term for what you're looking up to find it. Googling around wasn't much more effective (there's a lot of garbage in the Wikia for Vim that comes up at the top of many searches).
In the end, I needed to read these two "gentle" introductions to Vim to even understand what it was all about:
…and then I needed a mostly-well-documented distro like Janus (https://github.com/carlhuda/janus) to ensure that my productivity wouldn't take a huge hit those first few weeks.
Some folks can probably go all-in cold turkey, but I needed the training wheels.
The problem wasn't the "extreme & foreign environment", the problem was that you thought wrongly that you could learn Vim as if it were a regular editor.
Learning Vim is a side project: something you do casually, slowly, until and if you are able to do the actual switch.
Those braindead distributions are just smoke mirrors for lazy and pressed people: they provide training wheels but they actively prevent you from actually learning core Vim. They make people $distribution_name users instead of Vim users.
> Learning Vim is a side project: something you do casually, slowly, until and if you are able to do the actual switch.
No one appointed you the director of how one learns Vim.
This is one of the most obnoxious parts of Vim threads: that guy that responds to people talking about how they learned Vim (past tense, as in already happened) and tells them that they learned it "wrong".
I second this. I've really underestimated how big an impact first impressions can leave, especially when dealing with completely unfamiliar tools.
My first intro to Vim could be called "haphazard" at best because I was pressed at the time, and so that thoroughly soured the relationship. It was only after I took a few steps back and went at it with a let's try this again attitude very slowly did I finally get through it without exhausting myself. I wish I took the slow route the first time.
Best way to learn Vim is to learn it for the sake of learning it. Not because "it's in the way".
In the long run, the distros are also a dead end. Neither Square, nor "Carlhuda" share the same commitment as Brian Moolenaar. If you find them useful then take advantage, knowing that they are only a fixed point within the ecosystem.
The Gentoo Linux vim tutorial is how I learned. It took me about an hour to become as productive in vim as I was in my previous editors (nano, GEdit, some random Windows editor, etc.) Everything past that was an improvement over any editor I have seen before.
I think it is a lot harder for people used to IDE's, but if you treat it as "get to the minimum productivity level as fast as possible, then slowly add more", you will probably enjoy it.
> 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[1] 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?
> 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.
I started vim by using cream[1], which behaves like a normal editor with menus to configure everything. Once you get used to the different concepts, you can start editing the `.creamrc` file. After a few years, I was comfortable enough to drop cream completely and use hand written vimrc file for the configuration that I liked.
The best I can recommend is Learning the vi Editor by O'Reilly. This book will really teach you to understand the command languages of ex and vi (and how they interact). Once you've mastered that, vim will make a lot more sense as it's just a gigantic pile of extra stuff built around that core functionality.
For me it was using pentadactyl for a while beforehand that made switching easier. Obviously there are different concepts and some different default keybindings but pentadactyl is much easier to incrementally get used to imo.
Another thing that people often forget when they use plugins on their development machine is that if they happen to ssh into server (or work on another user's machine), it is unlikely that it will contain the same plugins. It is better to become effective at using the bare vi/vim commands first and only use plugins as a time-saver.
This is true for using plugins in any editor/IDE. Where do you draw the line. Should I use my own `.vimrc` file and set textwidth, formatting-options, indenting, etc. according to my preference, or don't tweak anything at all because those tweaks will not be available at another user's machine/ssh server? It is relatively easy to have your configuration files on a USB/dropbox and copy them on a new machine if needed.
I absolutely agree. Trying to use 'oh-my-zsh bundle' analogues for Vim is absolutely the wrong approach (for that matter, I think oh-my-zsh itself is the wrong approach). There is enough to learn already, blurring the line between what Vim does and what plugins do does not help the situation at all.
This said, I think these sort of dumps are great for experienced vim users who can pick through them and find individual fragments that they want to adopt.
That is a sensible suggestion, I would go further and suggest that new users impulsively reject answers to questions "How do I do X in vim" that are "use plugin y" and find a native way of doing it, because plugins will increase the difficulty in working in new environments.
Using vi instead of vim for a while is also beneficial. It keeps one from learning bad behavior like typing 'i' and then hitting the arrow and necessitates learning about marks before being spoiled by the visual modes
I definitely agree. Vim was much more confusing for me while still a beginner, partly because I started with first the spf-13 distro and then haskim, a haskell-focused distro. I didn't really start grasping how things worked until building up my own distro. The funny thing is that most distros I've seen still include many of the same plugins, making the end product only unique in the details. Those details however, are blockers once you're set in your ways...
as an anecdote, i've been using Vim for almost 10 years and i've never used plugins. the extent of my customization is setting the font/color scheme in the vimrc
Long time VIM user here and I completely agree, not only for beginners, also for pros.
Basically it follows the KISS, and in some sense UNIX, principles.
I have never used the vim distros but I have gotten to a point where I just rm -rf'd my whole .vim dir and started over with only the plugins I required at the time. Then added more as I needed them.
Of course, I have always managed well without the file browsers many use.
Normally I would agree, foundation first then mature into plugins and add-ons however after looking into Maximum Awesome I believe it will help new users overcome the learning curve frustration that vim is known for; very nice. kind of like a twitter bootstrap for vim
I'd say that syntax/completion scripts are an exception as they are pretty much mandatory if you're writing code in a language that hasn't made it's way into the official release (and to be frank, there are a lot of gaps).
That depends on how long it's been in the codebase. As this case is covered in the Rails security guide _and_ the Ruby security reviewer's guide I'd expect it to be quite old and now being found because it hasn't been properly audited before or indicate that the review process needs some work.
This article contains a number of fallacies. Storing sessions on disk? Over NFS? In the database? Please - no-one does that. And random MySQL bashing? What's that based on? MySQL is used by many high-volume shops to handle huge amounts of data. (See - I don't have to quote examples either!) And magic Oracle scales to infinity? For the kinds of database setups you need with high-performance web apps you can throw the same amount of money at percona.com and get there as well.
Disk-based session storage was the default for years and still is. I know of some high-volume sites that used NFS as the sharing mechanism at least up to 2008 and I assume they still do. It kinda works if you do mostly reads. Storing the session in the database was the prime example when session_set_save_handler() was first introduced. The symfony framework still ships with a pdo session handler, so I'd assume people still use it [1] The memcache session handler had major problems with session locking at least as of 2008, I don't know if it's been fixed by now.
Add this to any diagram to get the effect you want,
Demo: https://tinyurl.com/ycdu7owa