service — is basically a CLASS (B) used by your class (A). In Spring, this service becomes an interafce.
service — is often an instance field in your class.
dependency — is basically an instance field. If class A has a B field and A uses some B functionality/service then A functionally depends on B.
^^^^ now we have seen the worst jargon overdose. A regular instance field is now designated a “service” and a “dependency”. And the 2 new terms have different usage contexts. Sometimes you call that field a “dependency”; sometimes you call that same field (or its class) a “service”; but you never call it a “field”
wiring — a serious app need to wire up hundreds of classes — HAS-A. Spring uses an xml config file, lots of interfaces, and an injector for this wiring.
trinity — for dependency injection, you need minimum 3 classes, the service, the client (your app) and the injector. Spring wants a third party to inject the dependency into the client.
In the extreme implementation,
* just about every field is declared an interface type
* every such field has a setter
* you seldom see new ..(). Bean Instantiation happens at appCx start-up time, by “Hollywood”
Applets that are loaded from the local file system (from a directory
in the user's CLASSPATH) have none of the restrictions that applets
loaded over the network do.
“The ANSI outer-join syntax begins an outer join with the LEFT JOIN, LEFT OUTER JOIN, RIGHT JOIN, or RIGHT OUTER JOIN keywords. The OUTER keyword is optional.” ==> LEFT implies LEFT-OUTER
“ANSI join syntax also allows the dominant or subordinate part of an outer join to be the result set of another join, when you begin the join with a left parenthesis.”
right join is lg2
You mentioned documentation. Documentation is not only important for users, but also important for you to get a complete understanding of the entire project. After writing the documentation, hopefully you will be able to better describe the system to a new person such as your next client or a new interviewer.
I think in US and Singapore, many interviewers respect job candidates who understand past projects in-depth.
How stable is your job? Are you learning some new technologies such as java, dotnet, SQL? I recently improved my understanding of SQL joins, correlated queries, java OO, java exceptions, java threads, jsp/javabeans, servlet sessions… Now I feel like a stronger survivor.
better than binary search tree (or red-black) for the purpose of disk-access. need to minimize disk reads.
Obviously u want to cover as much “data” in one disk-read as possible. Perhaps as a result, each node contains thousands (t-1) of keys i.e. t-1 RowIDs
empty: head == null and there’s only one object in the list.
Each node is represented by an instance of the Node class.
Update: [[algo in a nutshell]] written by professors, has practical problem-solving suggestions.
Q: what if the storage system holding the long list doesn’t support random access, such as tape?
%%A: read into memory first, by chunk, then merge sort?
Q: what if there are too many items to hold in a computer’s RAM available within our budget? merge sort, but the bucket idea below is better.
Q: what if data is still arriving when we need to start sorting?
%%A: standard merge sort
%%A: if you know data is string and distribution is fairly uniform, you may want to create 26 (or 26+10) trees for A – Z, 0-9 and put incoming data therein. If data rate is too high, you can build 26 queues/circular arrays as the buffer in a producer/consumer pattern.
%%A: even with numeric input, you can do the same provided you know the distribution. In real system, use histogram to estimate the distribution.
I feel this is one case that needs real world experience. Designing a sorter without any idea of distribution is too academic and a waste of time.