60 karma · joined December 20, 2012
[1] https://www.johnsnowlabs.com/spark-ocr/
[2] https://www.adobe.io/apis/documentcloud/dcsdk/pdf-extract.ht...
Any thoughts on import from Apiary/Blueprint?
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?
- 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!
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.
[1] http://docs.angularjs.org/api/ng.directive:ngCloak [2] http://docs.angularjs.org/api/ng.directive:ngInclude [3] http://docs.angularjs.org/api/ng.directive:ngView
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 :-)
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.
[1] http://docs.angularjs.org/api/ng.directive:ngInclude
[2] http://docs.angularjs.org/api/ng.directive:ngShow
[3] http://docs.angularjs.org/api/ng.directive:ngHide
[4] http://code.angularjs.org/1.1.5/docs/api/ng.directive:ngIf
[5] https://github.com/btford/ngmin
[6] https://github.com/btford/grunt-ngmin
[7] http://docs.angularjs.org/api/ng.$rootScope.Scope#$watch
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.
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?
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.
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.
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.
If JS is an option for your project, you can also consider libraries such as Anima http://lvivski.github.com/anima/
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.
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.
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.
That same client who pays on time and upholds his end of the agreement is left at risk through no fault of his own. Just doesn't seem fair in my opinion.
Will a dispute happen even with well authored contracts and business plans? Absolutely, but properly scoping the work, delivering to a schedule and keeping open communication with the client will greatly minimize that risk.
There is a big difference, actually. There is pretty standard protocol and work agreements for automotive repair. This developer may have exposed himself to a level of risk based on his own contracts and work arrangement. Why was the site up in the first place if he was not paid in full?
"Similarly, I've met software developers who set timebombs in custom software they write for companies, with an easy to install patch that gets released when that company pays it's bill."
Wow, this is just scary. The work relationship is doomed if the developer doesn't trust the customer or vice versa. If you are in the business of making money through software development, be skilled not only in developing but in assembling contracts and project plans that protect your interests.
Your first line of defense would be a solid contract and a fairly decent deposit. If you lead with a strong reputation clients will have no problem making the investment with you. If you lack the experience and reputation, maybe you shouldn't be getting involved in projects like this that leave you at risk.
Next would be proper project planning and _clear_ delivery milestones that have payments associated with them. It is not wise to put yourself in a situation where you lead with design and development and receive the bulk of payment when the project is complete. Without a clear project plan and deliverables scope creep can introduce itself and you can wind up eating the cost of additional work to satisfy the client. And even then you are still crossing your fingers the check will come before the next "quick update."
The problem I have with what the developer has done here is that he has abused his position to leverage a client's domain to support his view of the situation. We don't know the clients side and they are left without a voice here.
The developer may very well be the victim here but I've got to believe it was his business practices that made him vulnerable here.