spring grandiose jargons

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”

left join == left outer join

“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
 

documentation#le2raymond

Hi Raymand,

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.

a couple of realistic sorting challenges

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.