It can, using either basic auth or by scripting submission of login forms.
Probably obvious, but you should avoid doing it from one of the public instances. Building your own private instance is as easy as spinning up a prepared EC2 image, or if you have a couple of hours to fiddle about you can do it from scratch on any Windows machine. Details here:
I signed up for CreditKarma too long ago to remember the process, but this is pretty standard for credit reporting services. I know Equifax, MyFICO, and the free annual government site do the same. In my experience the "You recently opened an auto loan..." questions are almost always answered with "none of the above".
Yeah, I've signed up for Equifax and MyFICO as well, and didn't have a problem with it. Maybe I just got "lucky" and stumbled on a bunch of really bizarre ones this time ;)
I've put about 12 hours in on my late 2013 13" mbp. For a decently sized-city (10k+), there aren't noticeable performance issues at full-screen and mostly 'medium' display options. Your fans will get a workout and you get about 30 minutes of battery life off the charger, though.
The first thing that came to mind when reading the title of this post was Google Fonts. Maybe this is validation that I need to write that Chrome extension that comes to mind every time I'm copying that snippet.
> I can have a highly functional site in 10 minutes with Drupal, but node.js (express), Django, Rails, etc. all seem to take forever just to get something of minimal functional equivalence.
There's nothing about Express that enforces MVC and depending on your definition of 'highly functional' you can go from nothing to production in like 100 LOC with Express and npm.
Are you familiar at all with npm? There's a package or ten for everything.
I've used Express, and it's great for what it does, it just doesn't do what I'm looking for. I'm wanting a framework that can be a CMS as well as a store, or a brochure-ware site, or a game backend server, or whatever else.
Basically, a plugin-able framework. I don't want to use a package from npm if that means having to hack it just to add something to a form. For that matter, I don't want to worry about the security of a 3rd party module simply because there is no standard way to generate/handle forms.
It's a philosophical argument, I suppose. You can write secure code if you do everything right, but if a framework requires you to use an API everywhere (a la Drupal's FAPI), then you get security for free.
I've written my own login and session handling scripts. I've written my own CRUD routines. It's painful, because it should not be necessary (IMO).
node+npm does everything you need here. if you're writing your own libs, you're doing something wrong.
there are so many middleware modules for express that you can have a web app with a connected db, user auth, forms with csrf up in a matter of minutes.
> while writing C# sounds great to developers who already know C#, the differences between the C# source and the generated JS make debugging and maintenance difficult.
> Several months ago the general direction of Angular 2.0 began to change in critical ways. I found myself fundamentally at odds with certain aspects of the proposed design. Still, I tried to keep an open mind and explore the various possibilities. Unfortunately, I haven't been satisfied with how things have progressed since then. At this point, there are too many irreconcilable differences. The Angular that's being built is not the Angular I signed up to work on
See, I find this reaction to Angular understandable, but in some ways it should apply more towards the current version than the upcoming one. I think people should be unhappier with the pile of junk that they currently have to deal with, than the fact that a bunch of it is going to change or go away.
It looks like the new version does away with some unnecessary concepts (Angular itself has way too many concepts to deal with IMO) and adopts upcoming standards like module syntax. (The AtScript stuff does seem like sort of a nightmare, though apparently only contributors need to worry about it.)
I hated the time I spent with Angular 1.x and the whole thing strikes me a as a complex and painful way to build applications. But the new stuff seems like a slight course-correction if you want to build apps in that way.
> I hated the time I spent with Angular 1.x and the whole thing strikes me a as a complex and painful way to build applications.
This comment baffles me. Not your cup of tea, sure, that I can understand, but complex and painful? Angular, Ember, Backbone, React, etc. are all so vastly superior to hacking together jQuery spaghetti code with imperative DOM manipulation I can't understand how anybody wouldn't be elated with the productivity gains they get from any of the modern frameworks, regardless of their syntax preferences.
About the complexity part, I am referring to the number of concepts one must be familiar with in order to produce a working Angular app. I mean read TFA: part of it breaks down the three varieties of directives you need to know in order to do a thing.
And it's all like this, just a constant array of made-up concepts you have to digest in order to make something happen in the DOM. It's such a pain in the butt, and you constantly keep running into it -- whenever you need to output a URL to the view, you get to go hunting for the docs for $sce and figure out your exact use case just so you can spit out the damn URL.
Well, if you're not using jQuery or Backbone at the very least to build SPA's, then that just adds weight to my argument.
> About the complexity part, I am referring to the number of concepts one must be familiar with in order to produce a working Angular app. I mean read TFA: part of it breaks down the three varieties of directives you need to know in order to do a thing.
I agree wholeheartedly that Angular has far too many bizarrely named concepts (transclusion being the worst offender), but if you don't put pressure on yourself to learn a framework inside-out in order to use it then you can save yourself a lot of initial pain. Simply using Angular's templating and two-way binding system and nothing more (no directives, services, etc) saves you from having to write an incredible amount of boilerplate DOM manipulation code. As you start to learn more about the different features Angular offers you will agree that most of them were necessary evolutions of the framework. Because it evolved over time, it has become a bit bloated as frameworks often do so the rewrite should be a welcome change.
> whenever you need to output a URL to the view, you get to go hunting for the docs for $sce and figure out your exact use case just so you can spit out the damn URL.
This is a built in security measure that you can easily override by providing a blacklist of URLs. Unless you're keen on coming up with your own sanitization logic, $sce is a very nice feature.
In my (albeit limited) experience with Angular the level of complexity is much greater than say using something like Knockout for data binding only. Not everyone wants to build an SPA and make use of $http. Also not everyone is currently hacking together jQuery. There never seems to be community chat, or posts, from people who have migrated from another framework/library to Angular, it's always people mashing together jQuery who are held up as the target audience. That should really tell you something...
Data point: I moved from a relatively big Backbone project (utilizing some of the higher-level libraries that inevitably were built on top of it) to a bigger Angular project. I liked Backbone more, because it is simpler to reason about and much easier to debug, but I believe we build things much faster with Angular. I decry a lot of the same design in Angular that others do, but I can't argue with its productivity.
I think the productivity for me comes from two places: 1. Emphasis on isolated and reusable view components. You can certainly do this in Backbone, but I never felt like I had a satisfying pattern for it. 2. Automatic data binding in the "push" direction. That is, the direction of updating the view based on changes. I think the full bidirectional binding complicates things. I find that I have far more sinks for changes than sources, so being explicit at the sources would not be burdensome.
From my initial reading tinkering, using something like ReactJS as the view layer in a Backbone (or perhaps even plain JS) app may very well speak to both of those points.
Certainly at ng-europe AtScript was being touted as the way you should be writing Angular 2.0
As a massive fan of Typescript I'm not convinced it is actually that much of a problem. But when you see the JS you have to write to achieve what AtScript produces it's going to be pretty painful for someone who wants to stick with JS.
> What I am saying is that it is no longer fundamentally the same thing I was originally hired to help build nor is it compatible with my vision for the future.
I've heard elsewhere that 2.0 will be an entirely unrelated framework which will be still called Angular for no good reason.
Dismissing this opinion as a troll is no longer productive after the above commentary by an Angular developer.
In that Angular 1.x has been iterative changes and 2.0 is a completely new architecture and code base, it's not a rumor. The angular team has been saying that since the original announcement.
Any time I've ever left a job because of a project, all that time spent working on a broken product has left me with tons of time to figure out how I would do it on my own.
The guy's framework existed before he joined Angular, he announced that they were merging, and then he changed his mind. Your analogy doesn't quite fit.
I'm skeptical of several things, but so far trusting that team has gone well for me.
Yeah, precisely because it is a library and can be used with many different frameworks.
Lately I was convinced that all frameworks should die and be rewritten as reusable and - important - interoperable libraries. jQuery is a good example of such a library.
My client was mad I was trying to charge him an extra $6000 for the time I spend to get the stuff I write to work across different browsers and asked me to use jQuery instead.
