Exactly the same here. I really wanted to like Ember, since I liked the documentation and read a bit about how the project started and how it works on a higher level. However, since I couldn't get through the Get Started tutorial, I gave up and went into angular instead, and I haven't looked back.
I'd like to give Ember a second chance, if only so I could be the only person on the internet that has tried both angular and Ember on a deeper level, but right now I'm not sure I'd do any better should I actually try again.
I reviewed both angular and ember for integration with a rails app for my job recently: https://github.com/et/ember_vs_angular
To my dismay, we went with angular. In retrospect, after playing with the framework, I'm fairly pleased with the choice.
I'm not sure I instantly see the use of this, but I am really impressed about the way GitHub is improving their discovery tools. Every new way opens up new possibilities for collaboration, and I love it!
That's a really bad thing in my eyes. Why teach a beginner that consistency is something that does not exist?
Also, non-english variables are an abomination! I've worked with code with some finnish variables. Not only is it harder to grok, it's actively distracting.
Awesome app! Already loving it! As others, I would gladly pay for it!
A tip for the Chrome Extension: A majority of the times I have wanted to push a link (the default) I want to push the page I am on. I suggest that you prefill the "Link title" and "Link URL" field, if possible!
Glad you like the app! And the Chrome extension will pre-fill for the page you're on, but not for tabs you had open before you installed the extension :)
I don't think that's the issue. The issue is that if a community is represented by a few key figures that share traits that you do not enjoy or seek in a community (in this particular case; generating a lot of drama), it's very hard to overlook. It's like getting a bad first impression, only a bit more continuous.
I've been using ruby for about or over now not sure any longer 10 years. I ignore the general ruby community most of the time, you can too it isn't hard.
You can ignore the ruby community at large and still be productive. I don't see why (pun intended) if you don't use rails, you care about DHH, or Zed or whatever.
If you're unable to overlook _why as a fun programmer who happens to program ruby, I guess thats ok, but you really are missing out on an interesting language. I'd say the same thing about someone worrying about Guido and Python. Stretching that last analogy but I honestly don't know of any other programmer-artist that quite fits into the vein of _why. He is/was really unique.
Since so very very many things changed in backwards incompatible ways, why didn't they just go with calling it 2.0 rather than 1.9? I mean, the changes are huge and most versioning schemes increase the major version number on backwards incompatibility.
> so very very many things changed in backwards incompatible ways
jQuery has always made feature changes/additions on .x releases. We're saving the 2.0 moniker for removing oldIE because that is a much more significant change than these API cleanups.
At this point the jQuery installed base is so big that any change, however innocuous, is a breaking change for someone. Even fixing bugs, conforming to W3C standards, or making API return values consistent can cause trouble because someone depends on the old way of doing things. We try to be respectful of people's existing work but also want to make forward progress.
Like the intro at the top of the upgrade guide page says, this list seems a lot more scary than it really is. We're just trying to call out every change that we think may cause issues, so people can assess and address them in advance.
The jQuery Migrate plugin is designed to make it easier to find any compatibility problems, and can be included with jQuery versions as old as 1.6. Add the plugin to your current code, run it, and view the console to see if there are warnings.
because 2.0 will be 1.9 with dropped <ie9 support.
jQuery 2.0 (early 2013, not long after 1.9): This version will support the same APIs as jQuery 1.9 does, but removes support for IE 6/7/8 oddities such as borked event model, IE7 “attroperties”, HTML5 shims, etc.
Our goal is for 1.9 and 2.0 to be interchangeable as far as the API set they support. When 2.0 comes out, your decision on which version to choose should be as simple as this: If you need IE 6/7/8 support, choose 1.9; otherwise you can use either 1.9 or 2.0.
No localization, please. Sure, the languages mentioned came from countries where english is not the main spoken language, but the languages themselves are always in english, and so is everything relating to collaborative software development.
If a user comes to a site that is using her primary language, she will interact with that site using that language. That is very much not desirable at a site like Github.
Other than that, the suggestions listed sound nice to me.
English is a de-facto standard for programming - languages, docs, most of the tools are in English. Books come out in English long before being translated.
This will not change any soon, and (I know it's controversial) but for the good of the devs-to-be, let GitHub remain non-localized.
I always feel the chill when someone pastes a non-English screenshot in places like StackOverflow. Or whenever I want to help some fellow dev in my company who happens to have installed Italian or French version of Firefox/Chrome/etc.!
We received a Chinese-language (not sure if Mandarin or what) to a KDE mailing list the other day. We could see it was relevant to us but there was no translation, nothing at all, none of us could understand the problem.
Eventually someone replied asking for them to re-submit an English description of the issue, hopefully they're able to do so. :-/
If you can't speak english, you can't program for sure. I work with some people who are not very good english speakers. I can see it in their code. Sometimes its a mix of english and their own language. Very bad. NO-HIRE
Last year I worked as a freelancer for a company which sold physical stuff over the Internet (ecommerce). All the code I inherited was procedural PHP written with Swedish comments and variable names.
I speak three languages, Swedish is not one of them. That was an awful summer.
In such cases even if you make it a policy to use only English, it can still bite you - for example, subtle grammar errors in variable names in a large codebase will be maddening for anyone except the original programmer.
Inclined to agree with you about this, but isn't the post talking about localisation only for the github website UI itself .. a separate issue to the language used in comments, commit messages, code, etc. It just brings down a barrier that might be stopping some people using it.
> "If a user comes to a site that is using her primary language, she will interact with that site using that language."
If the website UI is in their native language, people would most likely also make the READMEs, issues, comments and other things in their native languages. Commit messages might also be affected, since the user would perhaps not give it much thought that they are using their native language...
I have several non-english projects on Github and (although I am proficient enough to read/write basic english) I'd like to see the user interface in my language.
