Nice work putting together this tool. Have you seen either Spark OCR[1] from John Snow Labs or the Adobe PDF Extract API[2]? They both do a pretty good job a data extraction from tables as well.
At the bottom of the list is CodeHS[1]. I've not had much experience with many of the others but speaking from experience my son who is 8 has enjoyed the courses on there.
- 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"
Once you have 3 different workarounds for what's basically the most fundamental framework feature
I wouldn't call ngCloak[1] a work around, it's part of the framework and specifically meant to handle this sort of thing.
Use of the ngInclude[2] is more aligned with my personal preference on how I organize and setup my projects.
The reality is though, if you are using Angular to drive your entire page (aka, everything is part of a single Angular app), the use of ngView[3] goes hand and hand to work with your routing. This brings in the view template for the route in the same way an ngInclude would for other parts of the page.
I'm drawing off my own experience in Angular development and looking at the basic examples given. If there are more complex examples that illustrate UI flicker as a real problem I'd certainly like to see them.
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 :-)
Nice writeup, here is my input on the points OP makes.
The flickering UI
A quick fix would be to extract the problematic markup, place in a separate template file and leverage ngInclude[1].
If you find yourself having many instances where this is a problem, chances are you aren't doing a good enough job of breaking up your application into controllers, page components, directives, etc.
jQuery and Angular
In my opinion the example is little weak in terms of demonstrating a pitfall of AngularJS.
Based on AngularJS best practices you'll find yourself only doing any sort of DOM manipulation in the context of a directive (much like your example). Bringing jQuery into your Angular app for the sake of using .hide here probably won't make much sense. Chances are pretty good you'll leveraging directives such as ngShow[2], ngHide[3], ngIf[4] (version 1.1.5). No need to bring jQuery in for that.
If there is indeed a valid reason to bring jQuery into the project, I'd say the responsibility lies more so on the developer ensuring the dependency is met.
Minification
With the addition of ngmin[5], this isn't necessarily a pitfall just something to consider in your workflow. There is a ngmin grunt task[6] that works as advertised! I've been using it for quite some time now and never an issue.
My thought overall though is if you've conceded minification is a step in your project workflow, you'll be using tooling to make that easier. Bring ngmin into the mix and all is well.
Directives are never 'done'
I would suggest looking into using $watch[7] within the scope of that directive or making use of compile post linking over the linking used in the example. Check out the compile section [8] of the directive guide for more information there.
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.
By leveraging LESS or SASS you can create mixins which handle the vendor prefixing for you. For those new to LESS or SASS, the addition will require you to update your workflow a bit to compile the syntax down to vanilla CSS. This minimal impact though is far outweighed by the benefits of managing less style rules in your LESS or SASS file(s).
You may be right, it may be exactly what he wanted to happen.
The trouble I have thus far is the information is insufficient to make a fair determination of who is right and who is wrong. People are having knee-jerk reactions and harassing the gym without fully knowing the story, and yes, that is truly unfortunate.
If you are ready to close the case on this one simply by a developer claiming he wasn't paid, well, you may wish to rethink your logic with that one.
Has anyone vouched for the credibility of this developer? Have more details surfaced as to the extent of the invoice dispute? Without those answers it's unfounded to hold anything against this gym solely based on the developers claims that he wasn't paid.
I was a small fish as well for many years, 5 as a freelancer and 5 as a small business owner. We all have to take those risks initially when getting started, "I can build you a site that looks like this for this much money!" But we concede those risks when we do so.
In all of my years I have only taken 2 sites down for non-payment. That was the extent of it though, no payment, no site. I personally would never feel comfortable using a clients domain as my own platform to state my side of the story, it's just not appropriate in my opinion.
I want to support fellow designer and developers but in this case I just can't blindly do so without hearing both sides on this or a bit more detail from the developer. The developer has posted little more than invoices were unpaid and he's shutting down the studio like P-Diddy. For all we know through his own initiative he exceeded the agreed scope of work and wants to be paid for it.
Maybe more information can be surfaced and we can rally behind this guy. Until then I've got to stay neutral and look at things objectively.
This is an unfortunate side effect of what this developer has set in motion. I don't know enough about either side to make a determination of who is right or wrong, but neither do the people harassing this business on Facebook.
From his Behance page:
"Half a year's worth of work, weeks of waiting on end because they couldn't find the fingers at the end of their arms and in the end they try to screw me over by ignoring the invoices. "
That a pretty aggressive play in words. I suspect if he is really looking for "justice" he'd gain a lot more support in exposing the entire situation, not just some pretty screen shots and shouting about unpaid invoices.
I for one am genuinely interested in learning more about this, both sides preferably.
[1] https://www.johnsnowlabs.com/spark-ocr/
[2] https://www.adobe.io/apis/documentcloud/dcsdk/pdf-extract.ht...