I don’t see why using Windows or integrating with IDEs should be considered a fringe case. It strikes me as common and reasonable. Lots of people are more productive when working with GUIs. The command line is not a friendly interface. You come off as arrogant by calling this a fringe case.
I disagree. We should absolutely make our tools easy enough for children or anyone else. That’s how we expand our community and make newcomers feel welcome. Being powerful should be of secondary importance. Besides, the whole point of a tool like Ember CLI, its power, is its ability to save time. Time wasted figuring stuff out is contradictory to the goal.
Because it is. 83% of Ember devs use CLI, and only 10% of them are .NET developers. And, as I’ve said, you can keep using Windows, Visual Studio or whatever you want- as soon as you save the files, CLI will notice the update and reload the browser for you. If a tighter integration than that is desired, it would be preferable for ramcat to try to assemble some people interested in building that with him rather than railing about what rubes we all are for using ancient tools on our “incomplete prototype” framework.
That’s true, 80% is a high figure now that I finished migrating my app. But even migrating my second big app took several weeks, and I think 80% of that time was devoted to app-specific build problems, misunderstanding npm or bower, or tracking down things in ember-cli or ember-cli-rails that were either open or closed issues.
Once ‘ember s’ finally worked, it kept working, but getting there was rough for me, and I’m one of the 83% of devs who said they use ember-cli. If there was a checkbox for “I use ember-cli but it hasn’t saved me time yet”, I’d check that one too.
@Gaurav0’s right that “Time wasted figuring stuff out is contradictory to the goal”. And that’s @Ramcat’s curse, is that Ember CLI, the thing that saves time for most folks (with *nix OSes and npm/bower/ember-cli experience) is the thing standing between them and getting their Ember code running. And that makes @ramcat and I fringe cases because we don’t have experience in these things and were spoiled by the workflows we perceive as “easier” (like the rails asset pipeline or the perfect black box executables in Windows).
Coding is for anyone. Building Ember apps is not for anyone, just like building ambitious apps in any generation or language is not for anyone. But the discussion should be who exactly is it for. Just professionals, or amateurs too? Just OSX, or Linux or Windows? Just Ember-CLI, or Rails or cut-and-paste script tags?
Ember-CLI is clearly the easiest way to start a new application on a Mac that’s fully separated by an API and deployable on a nodejs-friendly infrastructure, and easiest for an existing app that’s rewritten to fit Ember’s 1.10+ expectations. If you want to expand the boundaries of who else gets to join the club, then let’s at least make the boundaries real clear in the guides.
Windows - caution
Inexperienced in javascript - caution
Inexperienced in terminal / cli - caution
Old View/Controller Ember app, hard to make components - caution
App can’t be separated from backend - caution
If the community wants to make things easier for any of those groups and expand the boundaries of who can be productive in Ember, then great! But we have to warn people in the meantime that they’re on the fringe.
I think this is a great idea, especially if built into a “who is this for?” section. I think we’re scared of turning people off, but a little bit of clarity up front on what challenges you might face as an adopter would be great, especially if it’s coupled with links to resources for dealing with those challenges.
I don’t think Ember should be “experts-only”, or be cryptic about what skills you need to have as an Ember dev. At the same time, if you’re new to node, npm, bower, CLI tools, QUnit, testem, phantomjs, git, and MVC concepts, you should be prepared to start learning those things. In 2015, you need them (or similar) for just about any approach you take to web development. As for OSes, it’s not just this ecosystem that’s not optimized for Windows- it’s pretty much all of modern JS development. Angular/Yeoman has the same problems.
So, perhaps the solution isn’t that the Ember guides need to hand-hold this process as much as we need a better source for teaching concepts like CLIs and package management to people who just finished “Teach Yourself Javascript Level 2” and want to start using a framework. I agree there’s a serious gap there, I think there’s just an open question of how much of that is “in scope” for the Ember guides.
I’ve seen this come up a number of times recently. Ember-cli is completely agnostic to your deployment infrastructure, in fact I would imagine the most common deployment is to a static host. I’d be interested to know where that misconception comes from as it seems that the communication there can be improved.
I think the misconception is that you install node and use npm for package
management, ergo everything is targeted at node backends. I don’t know that
we address that without teaching about modern JavaScript development.
In a work situation, I store my design documents for a given project on a centralized fileshare. Each version of those documents is contained in a different folder, usually with a version number. No design documents are stored on a development machine.
My code is stored in a centralized source control system (SVN, for the most part). On the client machine, depending on the technology, each project in some folder structure that attempts to centralize all projects in one folder. For example: D:\Projects\C#[Project Name]
In working on projects on my own or where I might only have one machine I tend to want to store the design documents in the same parent folder as the code. For example: The code; D:\Projects\HTML[Project Name]\Code, and the design documents; D:\Projects\HTML[Project Name]\Design
If I do this in Ember-CLI the command “ember new app-name” would be “ember new Code” because the raw code files of the project should be stored directly in the “Code” folder.
Two questions:
Does the “app-name” have any other effect other than to create the folder in which the code resides?
For those of you who do the entire project on one machine, where do you store your design documents in relation to the project/code files?
For #1, if you’re not using git or trying to publish an add-on, you’re
probably OK. The name also goes into some of the auto-generated meta tags,
but if you have your own system for that, I can’t think of a place where
the app name would make a difference.
For #2, we try to split out as much of that kind of stuff into different
repos as possible (or cloud stores, all our design stuff is usually Lucid
Chart or Google Docs) so that you’re only pulling it down what you need. If
you did want to keep any of your artifacts as part of one repo, your plan
sounds as good as anything. If it were me, I’d probably just make a folder
in the root of my ember project (eg. my-app-name/design). What you’re using
“code” for might best be served by the auto-generated “app” folder, as the
other folders (test, dist, node_packages, etc.) are also a little more meta
(supporting development, rather than the development itself).
I wouldn’t consider medicine or law healthy professions to model ours around. The economics of both are crushingly plutocratic.
An ecosystem a child could use is a very laudible goal, so long as it’s flexible enough to give experts power and provides a solid path for one to become the other.
Per the conversation about the name of the app created via “ember new app-name”, So far I have see no ill effects. The title of the index.html page was set to "Code’'.
My last foray into Ember I did not do any testing. I really like TDD/BDD so I thought to take advantage of that because its better integrated in Ember-CLI. I’m struggling to figure out how to start writing tests. Reading Introduction - Testing - Ember Guides left me wondering, where is the URL you need to go to see your tests (http://localhost:4200/tests/). Then there are 5 tests displayed but I can not find a list of five items in any files under the tests directory.
So a couple of questions:
Where are the JSHint tests?
Is the Index route Acceptance test not written (as an example, if nothing else)?
Because the “title” of the application is changed to the name given in the command “ember new app-name” wouldn’t that be a good idea to write the Unit/Acceptance tests to prove the name is that and give new users some idea where tests go?
What is the first test I should write to augment/test the newly created application?
You can use the ember generators to provide boiler plate files. To see a list of the available generator run ember g -h
Hope this helps
OH, I also wrote a book that has a focus on testing. I started it in the early days, so I no longer charge for it because it’s gotten outdated (e.g. I would not longer tie into rails etc.), but the testing concepts are helpful. And it’s free, so nothing to lose by looking
I account for 40-50% of all commits to ember-cli, and I prefer when it doesn’t leak and “just works” as a child would expect. Why, not because I don’t know how it works, but because I just want to focus on my app, not some build toolism.
I don’t think we are quite there yet, but we are slowly making progress.
Thanks for the info. I think I get what is going on with the “Acceptance” tests. As said in the documentation, its visit a page then test for content. I’ve read some of all the examples you showed me, and specifically https://github.com/discourse/discourse/blob/master/test/javascripts/acceptance/badges-test.js.es6. They are extremely sparse tests, I assume testing only for text that would appear if the page did not fail to load.
There is a finesse to testing that sparsely that I do not have in the Ember/ROR type world. The last nine years I’ve been NUnit/JUnit/Mokito. Still struggling to conceive of what my first tests should even test.
The saying is “don’t test the framework, test your code.” For unit tests, check that your computed properties and controller methods have the output you’re expecting given some set of inputs. If you have event listeners and stuff, try to make sure you’re testing those for side effects. For your acceptance tests, what will the user be doing on a page? Let’s say it’s navigating to a page and clicking a button that increments a counter. Your acceptance test is to click the button and verify that the counter element shows the right number.
Tests are just like regular code- keep them small and focused on a single responsibility.
Yup, the concept of Unit tests translates well to the TDD I have been doing.
Here is where I am stuck. Your phrase “don’t test the framework…” is a good one to remember. Also, from the Extreme Programming camp, “Don’t write code unless you have a failing test.” That falls solidly in the Test First Design camp. The initial page index.html (or maybe better application.hbs) couldn’t exist until there was a test for it.
Ah, and here is my real question, what is the test I should write that I would have written in TFD to verify application.hbs even has the right to exist?
So when you want to add a page/screen to your project, do you write a simple visit test for it (see code below)?
So in the Discourse tests, he tested that he had a list of badges (not by iterating the first, middle, and last of the badge collection (the unit test way) but by testing for a “critical” string). Do I test that a particular page displays a link? (My gut says no, but I can’t explain why)
Side note: It seems that Ember-CLI is doing one thing differently to what I was doing in Ember when I used it before. Index.html is not “processed” the same way in CLI. In my old code I had link-to helpers in index.html, but in CLI they don’t get “converted”, I have to put them in application.hbs. If I have a link I want on all pages, do I have to copy it to each .hbs file? (I’m assuming there is a header and footer concept I have not found yet)
import Ember from 'ember';
import {
module,
test
} from 'qunit';
import startApp from 'code/tests/helpers/start-app';
var application;
module('Acceptance: IndexTest', {
beforeEach: function() {
application = startApp();
},
afterEach: function() {
Ember.run(application, 'destroy');
}
});
test('visiting "/"', function(assert) {
visit('/');
andThen(function() {
assert.equal(currentPath(), 'index');
});
});
