Uhh how about a little more detail? I installed it, but I have no idea how to open it in a tab. Unlike my other extensions, I don't see any icon buttons next to my URL bar.
EDIT: If like me, you're using a Mac, you can use Alfred to open Postman. I still have no idea where to find the extension (I have both the extension and the "packaged app", whatever the difference is, installed on my machine)
I think LOC is actually a great proxy measurement of productivity. 3x the code is 3x the code that can break and 3x the code you have to wade through while debugging or adding features.
I see what you're getting at with "magic" abstractions, but it's like comparing Python and C. I don't know everything that happens under the hood in Python off the top of my head, but I also don't care. I could learn it if I needed to (e.g. needing to use the FFI, or if I find a framework bug). Not knowing is not the same as not being able to know.
The difference here is that in Python vs C, you almost _never_ actually need to know what's going on under the hood[1]. Whereas in every framework I've _ever_ used, I eventually need to dig into the guts of them because of some leaky abstraction. For instance, automatic data bindings are great until you want to do animation[2].
I do agree that LOC for a _non trivial_ application is a reasonable measure, though I disagree that Angular:Backbone is Python:C.
[1]: Serious performance optimization is the exception here, but in building CRUD apps, this honestly did come up infrequently, and usually the right thing to do was to improve algorithmic complexity or fix slow DB queries, not fix python constructs that were unexpectedly slow.
[2]: I haven't spent much time with Angular specifically, but definitely remember this being difficult in other automatically bound frameworks, like Meteor in its initial release.
automatic data bindings for animation are still great though, and its internals should definitely always be hidden from user-land, but I totally agree with you, performance and ease-of-use vary wildly in javascript-land and needs to get better.
I did a similar thing when I was seeking out a MVC framework for my company's JavaScript. I built a page using the same manual JQuery and JS I was using, then I built it with Backbone JS, and finally Angular JS (after learning each one in a tutorial and using TodoMVC as a guide).
Each step I reduced the code size by 50-75%, particularly the boilerplate of tying user interaction events to updating the logical model in JS. Angular's automatic 2-way data binding was definitely the selling point for me on the framework.
So your argument is that the primary difference between geniuses and the rest of schlubs is sheer volume of rote practice? I think you're confusing creativity with tool proficiency.
Personally, the two big draws to me of Angular were "free" (as in, I don't have to write much code) DOM<->data binding, and the explicit goal of testability.
As a learning exercise, I wrote a page using just jquery, rewrote it in backbone, and then rewrote it in angular. Backbone helped me separate concerns; Angular helped me do that while writing _way_ less code, since I didn't have to manage keeping the DOM and the JS model in sync.
I redid a relatively trivial CRUD interface from backbone to Angular. The amount of code that I didn't need in Angular was ridiculous. Most of the code in backbone was moving stuff from the DOM into JS. Like var x = $('#elem').val(); kind of things over and over just did not need to be there in Angular.
I think that these kinds of interfaces hit a really good sweet spot with Angular and other databinding frameworks.
Agreed - data-binding and "magic" automatic updates to the view when the model changes are key to what make Angular attractive. The focus on testing is nice too, though.
Several of these are generally applicable to programming:
* Keep functions small and composable
* Keep functions at a consistent level of abstraction
* Use constructors to ensure objects always exist in a complete, usable state
* Use meaningful method names in place of comments
It is nice to see that other people struggle with functions with lots of parameters + lots of partial state variables. I don't suppose anyone here has a better solution?
Comments should explain why you are doing something while method names are a guide to what they are doing. I see them as for different purposes and one should not replace the other.
I was playing about in Django recently, having written previous views as functions, I wrote some new ones as class based views. I felt that the OOP approach kept it cleaner and inheritance could be used in the same way as currying could for the function based views (but less complex - maybe because I understand OOP concepts better).
That sounds fantastic. The few times I didn't get an offer from an interview (early in my career), the "we can't tell you more in case you sue us" answers to why I didn't get the job were as crushing as the actual rejection. I always felt terrible having to give that answer when I worked for a big company, particularly for the marginal candidates. The terrible candidates aren't going to be able to improve enough to game the system, so there's no real risk to giving them the information as well.
My experience is just the opposite - systems being hard to adapt to changing models of reality is usually a bigger function of "bad code." If I can understand the code, I can tell that it's "wrong" i.e. that it doesn't match my model of reality. If I can't understand the code, I can't tell whether it's right or wrong, which makes me afraid to change it in case I'm making it wrong-er.
Well, you can have code that is a fantastic high quality implementation of a flawed architecture. For example:
Backend team: As we are building an MVP, this database table will have a poorly designed schema we will iterate on later.
Frontend team: We need some data that only exists in that other team's database. We will accumulate some technical debt by reading their database directly. This will let us deliver working software quickly.
Backend team: The time has come to refactor that badly designed schema.
Frontend team: That will break everything. You must not do it.
Backend team: Please will you pay off that technical debt?
Frontend team: It's not hurting us much at all, and we would rather be working on new features and things that make money. We are busy and many people are asking us for important things. Here is a link to an article saying technical debt is not a bad thing.
Backend team: I am sad because I'm stuck looking after this badly designed table. I wish I had done a big design up front.
I've had at least one coworker like this at previous jobs. They've tended to fool me repeatedly until I notice the pattern and revise my opinion of them. The confidence they display makes me think they're smarter / more informed / more thoughtful than I am, until enough evidence causes me to stop all positive weighting of their opinions. It's worse when you have imposter syndrome for the first several months of any new situation.
EDIT: If like me, you're using a Mac, you can use Alfred to open Postman. I still have no idea where to find the extension (I have both the extension and the "packaged app", whatever the difference is, installed on my machine)