Then this came out. Super excited for the weekend so I can dive on through. Thanks, Matt -- but stop reading my mind.
(n.b.: I'd be more than willing to pay sticker price if I could get a physical copy instead. I know it's lame, and slightly more effort, but I don't have a monitor setup at the moment so I'd rather leaf through a book than scroll through an alt-tabbed .pdf.)
Maybe http://lulu.com ?
Also, we have a pdf version of the ebook available for $25 on the site, but we'd like to give all of you on HN a 20% discount. You can go to this URL to get the cheaper price - http://gum.co/SUry/awesomehners
Thanks for all of your support!
git clone https://github.com/msfrisbie/mean-stripdown.git
Curious if others do something similar and group code together by modules or does everyone group by type?
I've switched to this convention as well - less context switching of files.
Bugs me to have the order logic spread out in the views, models, controllers, hepers, libs, etc folders.
I'm rolling with a MVP structure that frankly is becoming cumbersome with my current project's size.
viewmodels/controllers or viewmodels for the core views
AppShell contains the app starter page, controllers and util services (showing popups, utility functions etc.)
AppShell/Views contains all the UI Skelton for the app (bootstrap main page, etc)
Every folder inside "modules" contains views, controllers (viewmodels) and services belongs to only that module.
Account folder contains views for user registeration, sign in, change user profile, etc. etc.
This way you can keep building new moduels in their respective folders without touching the frozen code (already built modules).
Each module talk to outside world using "services". No module can touch anything belongs to other modules but with "services".
Oh between I do group by Type inside of a module.
It claims to provide concern isolation, which facilitates testing and cleanliness. I don't think it helps that much.
But it has a middle-stage learning curve, more callbacks than I'd like, and implicitness of dependencies. For example, i.e. you need to know what $scope-like params are "supposed to contain" on every function that uses them.
Also, I find the naming spotty: "directive", "module", "injector", "compile" etc. lack specificity. They are not as bad as "Manager", "Data", "Info" and "Object", but they are not good.
For example, i.e. you need to know what $scope-like params are "supposed to contain" on every function that uses them.
Outside of the controller-view relationship, nothing in AngularJS requires passing data in $scope objects, and you definitely shouldn't.
Why do you think dependency injection doesn't help exactly? I personally don't know of any other pattern to effectively test/mock things like HTTP interactions. It's also a pattern that's used by many, many other languages and frameworks - what's the alternative you're thinking about?
My point exactly. The relationship between views and controllers is important. Using $scope there is sucky (also, its name is too generic).
> Why do you think dependency injection doesn't help exactly?
I think that dependency injection helps, and I use it all the time. I just don't like Angular's take on it.
It relies too much on anonymous functions. I think that 'new' (or equivalent) and 'globally accessible glasses or factories' (or equivalent) are just fine in lots of cases. They make the dependencies implicit, yes, but that's secondary to the fact that the code is much more readable.
With MEAN a Grunt file is provided. Running the server with `grunt` will make grunt run the server and then watch the directory for changes - restarting the server and refreshing the page as necessary.
Make sure you have grunt installed.
For anyone else trying to add grunt, you need to copy over the gruntfile.js and add the grunt dependencies to the dev section of package.json in the root directory of the project. Then you might also have to remove and reinstall the grunt nodemon package (grunt threw up instructions on how to do this when I first ran it)
That being said, I'm curious if there are other advantages to learn the MEAN stack?
The advantage is you can do real time async stuff a lot better then with other frameworks.
How does any of that make it harder than "most web development languages"?
> The advantage is you can do real time async stuff a lot better then with other frameworks.
Look into Meteor.js - try doing that in PHP. That's how so. And you can write Sync code if you want to.
> try doing that in PHP
Meh, PHP is still the king, and it will stay there for a long time. Languages and platforms with crazy features pop up every day, but that's not enough for actually getting things done. You need a community, mature libraries, and a healthy ecosystem in general.
If you want something challenging try Clojure. It is by far The Best Language (tm) IMO, but you still can't even build a website with it. The only web framework available died and got separated into libraries, and everyone ends up wiring everything the way they can. Some people use Java libraries, some others reimplement everything. It's pretty messy.
The main advantage for using the stack has been a huge time saving in getting the project set up. NodeJS and express is hugely flexible about how you structure your source, which can also be a downfall in the additional mental load of deciding where stuff should go. MEAN does this for you.
The disadvantage has been where I want to do things differently from how MEAN is set up. For example, MEAN uses Bootstrap v2, I wanted Bootstrap v3. It was a slight faff updating it. It would probably be harder if you eg. wanted to use MySQL instead of MongoDB.
There is still a lot that you need to learn before you will get an app fully up and running, but with MEAN you can get cracking on stuff before you know it all. I don't know anything about Grunt yet, but can still use the Grunt file provided to run the server.
Well worth using in my opinion.
Will you be covering security in any detail? Most people seem to miss this and I'm discouraged to see when I download the MEAN project this is based on it has serious security flaws.
For example, if you view the articles list at /#!/articles and make a note of any article ID, then visit /article/<article_id> it will return the article author's hashed password, salt and email address in addition to the article content. This also works while logged out. Kinda scary if people are using this as a template for their own apps.
Many of the more confusing Angular fundamentals that many tutorials like these don't stress egghead.io has short 2 to 3 minute videos explaining in very clear terms.
PS. I know I sound like a shill, but I have nothing do with egghead.io other then I've found them immensely useful.
Unless the person learning AngularJS has never done any automated testing before, I can't see any reason why not to be using tests as a tool to further your own learning. I learned Go last year relying heavily on tests, first specifying what I wanted to achieve in a high level test, then learning as I figured out how to make the test pass.
OT but the fantasy football twist is great. I only just started playing this year so I've been learning a lot. We're playing the uk version but I guess it's much the same. I've found it interesting how much strategy there is and how much data I can analyse.
We have a startup in the construction industry so wanted to use it as a tool for keeping a sort of weekly offline / banter conversation going on with clients. Turns out that I actually enjoy too!
-  http://www.thinkster.io/pick/sFObNwt4rA/angularjs-built-in-f...
Looking forward to the player draft functionality with socket.io
"Permission denied (publickey).
fatal: Could not read from remote repository." -git
git clone https://github.com/msfrisbie/mean-stripdown.git
Edit: Print to PDF works, should have realized it was a single page app ;-). Thanks!