I see that they mention backbone and ember, but how does Yeoman play with angularJs?
Yeoman comes with an AngularJS generator built-in. Check the docs.
Yeoman: Modern workflows for modern webapps
51–60 of 77 posts
Re: Yeoman: Modern workflows for modern webapps
#52The install script takes staggering liberty with your system to fetch its dependencies. Make sure you read it before running. http://get.yeoman.io
I'm learning so much reading through this. Absolutely fantastic, love it.
Re: Yeoman: Modern workflows for modern webapps
#53This is great. I would like to support it spinejs, maybe it is easy to add, haven't look yet. This reminds me how much we need a global package manager, for most of the open source languages. Why would each framework need it's own way of handling dependencies.
You can easily create a Spine generator. Check out the docs.
Re: Yeoman: Modern workflows for modern webapps
#54Re: Yeoman: Modern workflows for modern webapps
#55The installer seems to look for apt-get, yum or up2date to find out if a system runs Linux. $ uname Linux Seriously.
Its using that later for installing packages using its native package system
If I understand the code right, it only installs things automatically when it detects homebrew.
Besides, it _assumes you're on a Mac_ if none of these three programs are found.
Re: Yeoman: Modern workflows for modern webapps
#56Earlier quoted context omitted.
The biggest problem is validating the download prior to installing it. The use make install or install.sh or other similar script, the following should be done: Download package md5 package verify md5 == published md5 of packge extract make install / install.sh / etc With "curl package.github.com" | bash" the validation is missing. I don't mind the curl x | bash for my dev machine or testing/dev vms, but that is not…
If the bad guy has intercepted the DNS, they can just provide the md5 of the bad script, no? Maybe the solution here, assuming you trust the third party, is for them to get a signed SSL cert and provide `curl https://get.whatever.com|bash`
If the bad guy has intercepted the DNS, they can just provide the md5 of the bad script, no?
That's enough extra work, and unreliable enough, that the attacker might not bother. Why work so hard to sabotage the user who checks md5sums when you can just wait for a user that doesn't? Just because thieves can carry lockpicks doesn't mean that you shouldn't bother locking your car: Protection against lazy, opportunistic thieves is still better than nothing.
The other advantage of the MD5 plan is that you can download the MD5 from a different site than the script, at a different time and over a different internet connection (or, perhaps, over https). A specific, important version of that use case is: If you're installing the script over and over again in an automated fashion, you can download its MD5 in advance, cache it, and then check it against every future download of the script to verify that the script hasn't changed. When the script gets updated and the MD5 legitimately changes, you audit the diff and then update your copy of the MD5 for the future.
Meanwhile, using curl-over-HTTPS seems like it couldn't hurt, but better make sure 'curl' is really checking the cert and aborting on cert mismatch, because tools can be very sloppy about this. Also, you're still trusting the third party site, and once their site gets hacked it's game over… unless you have another canonical source for the MD5 sum.
One ultimately realizes why real packaging systems have signed packages, with private keys assigned to developers.
Re: Yeoman: Modern workflows for modern webapps
#57Earlier quoted context omitted.
its a command line tool for web developers. It has many capabilities useful to the modern web dev workflow. Of most note to me, it acts as a "project creation" tool. AKA "A Scaffolding generator." It will pull things like HTML5 Boilerplate, jQuery, Backbone.js, etc down from github, and properly generate the project files you need to start a project with those dependencies. You dont have to worry about how any of it…
If you have already built a few web apps, wouldn't you already have your scaffolding that can be copied into a new app? And as a bonus, you will have scaffolding that you understand very well. "You don't have to worry about how any of it fits together..." That doesn't seem like an advantage.
I agree with this. I like knowing exactly what all the pieces of my stack are, and how they mesh together.
If someone is churning out websites right and left I could see this being a more interesting tool, as it seems to be more powerful that any "boilerplate generation" scripts I would write myself.
The pain point of managing dependencies is indeed non-trivial in my experience, so I will keep an open mind for tools that look to solve this.
Random stream-of-consciousness idea: I create a new directory, and in it a text file containing the following on separate lines: "jQuery html5boilerplate AngularJS". I then run a build command to pull all these resources together in a sane way. This would allow me the fine-grained control I prefer, help ease the tedium of fetching dependencies, and obviate the need for a stream of "yes/no" questions at the terminal. This functionality may exist already, and it seems like it could be built by leveraging the logic being Yeoman, but with a different "UI".
Food for thought!
Re: Yeoman: Modern workflows for modern webapps
#58To the authors: Please make sure to remove trailing whitespace. I see it all over the code base. Run 'git diff 4b825dc642cb6eb9a060e54bf8d69288fbee4904 --check' to catch those. That SHA is that of the empty tree, applicable to any git repo.
Re: Yeoman: Modern workflows for modern webapps
#59Re: Yeoman: Modern workflows for modern webapps
#60Stop doing `curl get.whatever.com|bash` ! Seriously. I have nothing against your install script, but getting devs use to that is a terrible idea ! I spent weeks explaining to junior devs to not do that on production servers. I thought it was obvious, but apparently it isn't...
To be fair, if you ever install and execute someone else's software without either reading the code yourself or making an attempt to verify that the source is who you intend (i.e. at least checking MD5), then you're guilty of precisely the same security gaffe.
No, that is not precisely the same security gaffe. Github (for instance) is itself not as likely to be compromised as my link to Github is.