greaterweb

Looks really cool, nice work!

Any thoughts on import from Apiary/Blueprint?

I can't view your legal terms without agreeing to your legal terms.

This seems like a great idea. A few questions.

How well does this play with dynamic content?

Can you define specific content types (eg. Article) and capture events specific to that type (eg. Share, Print, Save)?

How about integration with SPAs built on frameworks such Angular, are you accurately able to capture events?

A handful of suggestions

- consider putting initial focus on the item description field and possibly using a textarea over input

- in alternating rows with white background it's difficult to determine what can be updated

- as this is desktop targeted, I'd consider throwing a hover style over the fields which are in fact editable

- rather than trying to rework styling of form elements, use the hover effect as described above and the ng-if (or ng-show/ng-hide) to toggle between the input field and text based element

- print mode you can still edit, as noted in another comment there really shouldn't be a print mode, you should have a print stylesheet to hide what you don't want on there and format everything else appropriately

- consider localStorage for the most recent invoices created, also helps with the "oh shit, I just navigated off the page with 100 line items"

Overall good first effort, keep at it!

Came here to say the same thing :-)

A little confused here.

So you have components server side that need to be in your application. Are they a functional part of the Angular app or just "static" markup that is complimentary to the dynamic pieces?

Worth noting is that unlike other front end frameworks, Angular allows you to have one (or more) elements within a page dedicated as the application container, you don't need the entire page for that.

Front end frameworks such as Angular are certainly geared towards service oriented application development. If that doesn't make sense for your project or architecture, well, square peg round hole situation :-)

It's really unfortunate to see all the haterade being spilled over the comments. The efforts to take Bootstrap to version 3 were pretty significant, at the minimum they deserve a pat on the back for that alone.

Here are some important concepts I think a good portion of people are missing.

Upgrading - Don't upgrade for the sake of upgrading. If you have a fully functional site right now which uses or extends a previous version of Bootstrap your incentive to upgrade at this point is probably minimal.

At some point you had conceded that version X of Bootstrap was the right front end framework for your project. If that has changed you need now concede you have some work ahead of you.

Identify and evaluate the features introduced in Bootstrap 3 that are lacking from your current project. Scope out the markup and stylesheet refactoring required for any of the "must haves" and setup a schedule to integrate. Realize that this doesn't necessarily mean you are bringing Bootstrap 3 into your project, more so you may just be adapting your existing front end assets to model Bootstrap 3 features/patterns.

This is really no different than an existing site that doesn't use Bootstrap now wanting to bring the framework into their project. If you've identified that you need Bootstrap 3 for your project, you would expect there is work to be put in.

Usage - I see a number of comments critiquing design and usability. Is Bootstrap really intended to solve those problems for you?

In my opinion this is a framework intended to bootstrap your front end assets and development efforts. It prescribes conventions for common component markup and their respective selector naming conventions.

Think about that for a moment how valuable that is to your project (especially those with a large number of contributing developers). How many projects previous to one using Bootstrap did you have such well documented markup, style and naming conventions?

Bootstrap standardizes and documents front end patterns for rapid adoption and implementation into your project. That's pretty damn special. If what they promote doesn't align with your needs or development practices, well, don't use it.

Style - Bootstrap wasn't designed for your site, your users or even to keep up with the latest design trends. The styling, while in the view of many is decent, seems to have been intentionally minimalistic and not overly opinionated.

It provides basic structure and basic styling. It's your starting point. You can get to your destination now a bit quicker without needing to reset their style rules.

Having such minimalistic styles probably serves to be good motivation to get creative. If you want custom and don't have the design ability to get there, rest assured there will be a companion stylesheets to extend bootstrap coming soon to at a market place near you.

Inspire - If the Bootstrap shoe fits, wear it. If Foundation, Pure or any other front end framework fits the need, use it.

To me the great benefit of all these popular frameworks is they bring to light many well thought out development approaches to the front end. Not everyone will agree with them. They aren't always bullet proof. Though at the end of they day though they invoke developers to take a look at their individual assets and recognize areas of improvement.

Find the framework or approach that best aligns with your needs and personal preference and customize the hell out of it.

Realize that whatever path you take, if you are looking for a future/career and web development you need to be actively developing. Use your free time to build a bullet proof portfolio showcasing your talent. If you have a strong portfolio, the work will find you with or without that piece of paper.

I see red flags though in reading that you have applied to 50 companies and only received 4 responses. Your approach in contacting these companies is flawed or the representation of your skillset and capabilities is weak/inaccurate.

Also, put yourself in the shoes of the hiring manager. A 20 year old is telling you they have 4-5 years experience. It takes a fairly unique 15-16 year old to be building something of use at that age. Best case scenario (in the mind of the hiring manager) is you have may have 1-2 years of real working experience that would be of value to the role they are tying to fill. And these days, who doesn't?

Take a good hard look at where you motivation lies and pursue a path that will convince prospective employers that you have what it takes contribute at a high level. Production guys are a dime a dozen, what sets you apart?

I keep seeing "boilerplate" being tossed around in these comments, I'm not sure that really serves to identify what Yeoman is.

Yeoman is tooling and workflow concepts, take what you need, leave what you don't. Best of all fill any gaps with your specific needs.

Yeoman pursues package management through Bower. This can be done with our without Yeoman but the reality is front end package management is still a relatively new concept but one all developers should be latching onto sooner than later.

Yeoman pursues workflow tooling through Grunt. Many lack an understanding of what Grunt is and how it impacts your workflow but for me it was revolutionary.

Yeoman generators give you starting points for your front end assets but aren't intended to be more than staring points for concepts within your application (eg. I need a new controller). If these generators fail to meet your needs for a specific project or your overall project workflow, author ones that do. They also pull together tasks you would typically handle manually (eg. I created a new-controller.js now I need to add that script tag to my index and setup some unit tests).

Yeoman is a lot of things but doesn't claim to be a boilerplate for any one thing.

Whether or not you use Yeoman, I encourage everyone to dig through it and get a complete understanding of what it is and how it attempts to improve the efficiency of your workflow and tooling. You can apply these concepts to your own custom workflow or build a custom one based on theirs.

I think there may be some confusion by some as to just what Yeoman is and it's usefulness. My opinion is that Yeoman strives to improve your workflow and tooling in front end development.

The core team has engaged the dev community and identified how people are working, what tooling they use and what pain points they experience. Yeoman serves to centralize workflow and tooling and ease those pain points. The generators are very useful as well and extensible.

Again, Yeoman may not be right for everyone but I would be interested to know more about your workflow and tooling and contrast it to some of the concepts pursued. This feedback would be useful to those considering Yeoman.

I disagree. The initial release of Yeoman with it's "opinionated workflow" (as they had coined it) cornered you into some dead ends, Yeoman 1.0 does not and is highly extensible.

Yeoman no longer attempts to be a wrapper for things like Bower and Grunt but rather concedes their usefulness while keeping them separate. Use it how you see fit.

What is great about Yeoman is it really gets you thinking about your end-to-end process for front end application and asset development and provides you some great avenues to pursue in both tooling and workflow. From asset creation, unit/end-to-end testing and build process it's rather complete in concept.

Is Yeoman for everyone? That's entirely up to the developer. Anyone worth his/her weight will certainly be pursuing these concepts in their own workflow whether with Yeoman or without.

"Once people reach a certain level of competence it's going to be quicker and/or easier to set things up themselves." Could you be a bit more specific as to what they will outgrow? Evolve maybe, but I personally will only shelf my usage of Bower and Grunt tooling if something makes more sense in my workflow.