@cyrus
What do I do?
I am…
Nothing here yet.
No blogs yet.
I suppose I wasn't clear enough. The question is how to manage and apply field validations that have been determined on the backend. e.g. the backend (whatever lang.) decides that field X has violated some rule, that rule is passed back to the front end (perhaps in a JSON body on an HTTP 403 or 409). How do you display those violations? What tools do you use to manage those responses and render them? Perhaps injecting into ng-messages...
I think the principles are largely unaffected by Java 8. The book mostly discusses design patterns, which aren't changed much by the new hotness. Given that this is a best-practices manual for professionals everywhere, I expect it'll receive a Java8 treatment.
Work through Introduction to Algorithms , or "CLRS" for short. It's a great foundation. Find algo. problems on the internet ( careercup has a crowd-sourced question set that is 80% excellent, 20% not useful). Solve 100 of them.
I like the idea of ENUM s because they're explicit, whereas depending on a comment is pretty unfair to the user. Internally, ENUM is stored as 1 or 2 bytes, depending on the number of possible values ( TINYINT is 1 byte). So lookups are going to be only slightly slower than TINYINT (an additional lookup to the information schema to determine the mapping to the right byte value to look for). However, there are lots of caveats about ENUM implementations, and those often push people to other arrangements: In MySQL, ALTER TABLE on an ENUM can be expensive: the table locks, everything might get re-keyed... kinda bad. In PostgresSQL, you just can't alter an ENUM . You create a new column with the new set of options, copy values over, drop original column. Goodness help you if you've got indexes involved. (Although I hear that's changing? Or maybe it already has? Turns out as of 9.2 you can modify 'em! So probably about the same penalty as MySQL.) So a lot of it will come down to your use case. If you're pretty confident the value set is complete or if you have the flexibility to manage an ALTER TABLE and its implications, consider ENUM for clarity. But the third option, which you kindof mention, is the best: create a values table. Something like user_status_types with key column and label column (labels "blocked", "active", etc), and make it a foreign key reference of the status column in whatever other table(s). You can make the key a TINYINT , so space is still efficient. You still have a table lookup similar to the ENUM information schema lookup, but you have the flexibility to mess with the table without penalty, and it's still inherently clear to the user. ( VARCHAR is ... an option. Document databases enforce the schema at the application layer, as you'd be doing with VARCHAR , so it's a thing I guess, just not very RDMBS-like. The above blows that out of the water for performance, memory, clarity in the data layer, etc)
In the spirit of side-stepping questions :) What really matters is consistency, whether by following a style guide , automated linting and code formatting, or if you're working on your own just being independently consistent. Personally, I like an IDE that's aware of coding style guides and can enforce or apply them automatically. If a language has a style spec, there's usually a plugin ( Go , PHP ). And if you're specifying your own rules, check out EditorConfig , a file format that you can put in your source directory to instruct many supported IDEs about the rules you'd like to enforce. It's not a comprehensive tool, but I appreciate its intent.
The simplest solution would be to start with three passphrases and symmetrically encrypt with each one. A tool like GPG can do the careful work of the key derivation (converting phrases to cryptographic keys, i.e. long pretty-random numbers) and encryption for you. The weakness of this solution is that you need to know the order the keys were used, so you can decrypt in the reverse order. So here's an alternate solution which doesn't care about the order, but for which you'll have to write your own code (and while the implementation is reasonably straightforward, any time you're considering writing your own cryptographic code you're probably in a dark and dangerous place, and have probably had too many shots of something strong). Convert phrases to keys (e.g. PBKDF2, which is probably what GPG is going to use). XOR the three keys. XOR is commutative (i.e. same output regardless of order) and the output is as random as the input. Encrypt symmetrically (e.g. AES256, which is probably what GPG is going to use).
This isn't the answer you're looking for, but I feel like i18n is a job for server-side work. You don't have to push up content twice (the template in english, the template content in some other language). Also, you have ready access to the Accept-Language header, which is helpful and much better than navigator.language .