That project is finished. The other fellow has some PHP work to do to wire up my work, but I will probably not return to it myself unless he needs something else.
Only if you didn't understand conventional use of the term. Since no one really speaks Latin anymore, the conventional use of the term is all that matters.
If a speaker uses a term and the audience understands it, whipping out your Latin dictionary is pointlessly pedantic.
I think your anti-pedanticism is excessively pedantic.
Conventional use of the term does indicate an analysis of events after something has come to an end - if not necessarily death. A company, a project, an incident response.
I'm with GP on this one. Based on the title, I thought that the project had in some way come to completion and this was an after-the-fact analysis of cause, effect, and resulting behaviors.
As you said, the conventional use is what matters - and the author here has used the term in a non-conventional sense.
Edit: another read through after seeing the author's comment below. The project did, in fact, come to an end - though that wasn't really clear. Given the content I think the "retrospective" is a better fit. The author used this in the content of the entry itself.
That was the sense in which I was using it. Game Developer magazine always used to have a section where they had developers do a "post mortem" on projects they had finished and they were very instructive on what had gone well/poorly.
Nice writeup, I especially appreciate the focus on testing. End product looks really slick. You might want to add a screenshot and a link to the blog post in the GitHub repo that you posted.
One thing that I think could be improved is the layout of your code. Right now you have a single controller that handles everything. For example, selecting a shirt color should be a directive, and so should the quantity picker. Then use the $scope.$emit and $scope.$on to hook events together. This way, if I make a better color picker (although yours is pretty stylish), I can swap out yours for mine so long as I emit the same events as yours.
This would also make it easier to add new directives - for example, maybe I could choose a decal on the front and back of shirts, or jersey numbers or something. So I think that the controllers in this case should be pretty minimal, and just provide a scope to tie the various directives together.
Anyway, just a thought. Thanks for sharing this and the included GitHub repo.
You bring up two really good points there. I will add a screenshot to the Github repo and there is an opportunity to use a directive for the color picker.
I'm not sure about the quantity picker though, what's that going to look like in the HTML? One element in the code gives you all of the quantity fields?
My use of directives to date has been rather limited so I look forward to exploring that more in some upcoming work.
I'm certainly no Angular expert, so take my advice with a healthy amount of skepticism, but I think that it would be one element. The idea being that if I want to swap that stuff out for a new and improved quantity picker, I just change the directive. The idea of angular is that the HTML is supposed to make it clear what's going on, so a single element isn't a bad thing - it says, "here's the part that chooses quantities." Remember that you can nest directives too - so the meat of your page could look like:
And then your directive figures out what that means in terms of rendering. But now, the nice thing is that I can just substitute that with <my-size-picker> and, assuming I fulfill the contract, everything should continue to work.
Now you get the added benefit that you can test directives individually, as well as the whole controller. Right now, if you do some restructuring of the page, you could end up in a situation where you break all of your test cases. I mean, in this case it might be overkill, but as a general principle I think it's the right approach.
I have done a large Backbone.js project for my last employer. I was on that for about 18 months. I have not done a project with both Backbone.js and AngularJS in the same project. I know some people do that but I truly cannot think of anything Backbone.js brings to that party.
As for Backbone.js by itself... It's OK, I liked it but we had a large project with as many has half a dozen people working on it at its peak and the problem we got into was all of the huge gaps in Backbone.js that you typically fill with other software (two-way binding, validation, templating, AMD, etc.) and if you don't figure out your solutions for all of those gaps before you start every developer in the group ends up filling it his or her own way. Especially if you're under a time crunch and writing really fast.
We ended up with a working project at the end and it was way faster than their old solution but it was a chimera. Every part of it appeared to be a different animal. With AngularJS a lot more of those parts are part of the framework itself and there's less room for that kind of problem. I'm using it for large project work now and liking it a great deal more.
This is a really helpful answer for n00bs like myself. Often the differences between technologies emerge not at 'hello world' or 'to do', but in larger projects or working with teams. It's very hard for someone like myself to see those differences for ourselves, at least not until we've been through it a couple of times. Thanks.
Do I know you?! This sounds exactly like what happened at my place of work. I've also already filled in all the Backbone.js gaps, but Angular.js seems easier to get a team all working in the same direction.
Also, I didn't mean one project using both Angular and Backbone.
No, but I'm also interested in this. I've been looking at Ember.js / Backbone.js / Angular.js for a new cross-platform mobile project and leaning towards Angular.
Some of my colleagues did some perf testing for mobile and found Angular.js was not suitable (I guess due to the compilation it does). I don't have any numbers unfortunately, but I think we use mostly Backbone for mobile projects here.
Thanks for the tip. Would be interested in stats. It's such a timesink to evaluate any of this new stuff. There's clearly a market for a tomshardware.com equivalent for frameworks and software stacks.
See my reply to welder above on the topic of Backbone.js. I had just finished a project using it before I came to this job and I was quite certain I didn't want to use Backbone.js again. I knew there were better solutions out there. The t-shirt thing was actually an experiment to try out AngularJS and see if it was good enough for our needs here.
I had meant to do the same with Ember.js as well but AngularJS did the job so well that I decided to just go with it. So possibly Ember.js is even better. I don't know. But I can say we haven't really regretted AngularJS yet.
