I had a look at doing this myself recently to do iPhone -> Laptop transfers. Does this work for mobile -> desktop? I didn't think that WebRTC was available on mobile safari and therefore wouldn't work.
I have an interesting question. Currently my AUD$ balance is displaying as $0. However in December and Febrary I had asked to withdraw $1,000 and ~$400 to my Australian bank account. Those transfers were taken from my balance, but merely sat as 'confirmed' rather than 'processed'. What happened to my money?
3. is the most important there. The other questions could be speculatively answered. But there's no way to explain a 20M imbalance without some sort of criminal negligence, which would make any sort of rebrand / relaunch absolutely impossible.
I agree with WalterSear that organizing by feature is best. For things that are shared, I like to have a shared/util directory for the miscellania, grouped by purpose (as needed). So, say, if you end up with a few directives used for form validation, you might end up with a util/validation directory somewhere.
The most important question is "can I quickly guess what directory this directory lives in?"
When you come across directives that clearly feel "utility", you will be tempted to look in a utility folder. When a directive is something tightly coupled to a feature, you might be tempted to first look in the directory related to that feature.
Since they won't be used by the main application (ie - app.js, routing, etc, etc), just by features, they bubble up to the root 'features' directory that is contained in the scripts directory.
I forgot to add, I will also create a directory tree for singular service dependencies, so that a service can have multiple, non-shared, dependencies that are each considered a 'feature' and consequently have their own folder containing their code and tests.
I need to blog this, but node is fighting with osX on my macbook right now. I am not a happy camper.
While I love Angular, I feel the author is wrong on a few things. It doesn't provide a way to structure your codebase, that's still up to you… directives.js isn't going to scale at all. That's also one of the things I love about angular. The code is modularised, but that isn't enforced on the filesystem. You can choose to lump things into files in a folder for directives, or you can put all your routes, directives, filters etc for each feature in a feature folder. You have plenty of control.
Also, I feel like their example is better served as a filter, rather than a directive.
I agree with you that the structure is still up to the developer, but if you get too creative you'll end up in a mess of code. In this thread other organization approaches have been suggested, that are in my opinion better than the angular seed suggestion. The point I try to make is that Angular when compared to other existing options is more structured. How do you find the balance between flexibility and structure depends on your team and project.
After you wrote about my example, I realize that you are correct, it was not a great one. My bad!
We needed this for our site. You can add as many 'domains' as you like, each with their own plan. Instead of creating a new customer + subscription we hacked together a way that each customer gets a unique 'plan', which can be multiple subscriptions. Multiple subscriptions per customer would have saved us a lot of time.
The other option was asking the user for CC details each time and creating a new customer at Stripe - but that felt like friction.
We were storing payment details sent from a PHP system into a Ruby system, I was responsible for the sending and receiving endpoints. Everything was heavily tested on the Ruby end but the PHP end was a legacy system with no testing framework. Since the details were encrypted on the Ruby end, I didn't do a full test from end to end AND unencrypt the stored results.
Turns out for two months we were storing the string '[Array]' as peoples payment details.
Takeaway: If you're doing an end to end test, make sure you go all the way to the end.