Sat Feb 24 15:42:46 GMT 2018
From
/weblog/design/interview
Do the simple thing first.
Do fewer things better.
Upfront work but can pay huge dividends.
Don’t reinvent the wheel.
Nothing lasts forever.
http://highscalability.com[..]-from-5-years-of-building-instagram.html https://www.infoq.com/interviews/adams-php-facebook
(google search)
(amazon search)
Mon Nov 28 16:12:57 GMT 2016
From
/weblog/design/interview
"They build their own infrastructure for performance, reliability, and cost control reasons. By building it themselves they never have to say Amazon went down because it was company X's fault. Their software may not be more reliable than others, but they can fix, debug, and deployment much quicker than when working with a 3rd party."
http://highscalability.com/amazon-architecture Shel Kaphan -
http://www.infoq.com/cn/articles/talk-with-amazon-shel-kaphan
(google search)
(amazon search)
Thu Sep 10 06:18:31 GMT 2015
From
/weblog/design/interview
One of the challenges we were facing is we wanted to be both functional and object-oriented. We had very early on the notion that immutable objects would become very, very important. Nowadays everybody talks about immutable objects, because people think they are a key part of the solution to the concurrency problems caused by multi-core computers. Everybody says, no matter what you do, you need to try to have as much of your code using immutable objects as possible. In Scala, we did that very early on. Five or six years ago, we started to think very hard about immutable objects. It actually turns out that a lot of the object-oriented field up to then identified objects with mutability. For them, mutable state and objects were one and the same: mutable state was an essential ingredient of objects. We had to, in essence, ween objects off of that notion, and there were some things we had to do to make that happen.
http://www.artima.com/scalazine/articles/goals_of_scala.html
(google search)
(amazon search)
Wed Dec 30 16:46:40 GMT 2009
From
/weblog/design/interview
Lessons Learned From Java EE’s Evolution, discuss about value of standard and opensource -
http://www.infoq.com/presentations/Lessons-Learned-from-Java-EE
(google search)
(amazon search)
Tue May 06 06:25:04 GMT 2008
From
/weblog/design/interview
Donald Knuth on Multi-Core, Unit Testing, Literate Programming, and XP:
I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace...
http://www.artima.com/forums/flat.jsp?forum=276&thread=229705
(google search)
(amazon search)
Mon Apr 28 17:46:55 GMT 2008
From
/weblog/design/interview
Nice message cover DSL, IDE, multiple dispatch, message passing, and more
http://msdn2.microsoft.com/en-us/magazine/cc500572.aspx
(google search)
(amazon search)
Sun Nov 11 15:32:58 GMT 2007
From
/weblog/design/interview
The discussion of "Flexibility and Complexity" and "Flexible versus Reusable" answer my long question of how to have flexibility code with simple design.
http://www.artima.com/intv/flexplexP.html Another interview -
http://www.infoq.com/presentations/modifiability-fowler
(google search)
(amazon search)
Thu Aug 09 17:59:30 GMT 2007
From
/weblog/design/interview
Erich Gamma: A pattern is always a problem-solution pair that can be applied in a particular context. Although the solutions might look similar in different patterns, the problems they are solving are different. In fact from ten thousand meters most patterns solve a problem by adding a level of indirection. What is interesting is how this indirection comes about and in particular why it needs to happen.
Therefore if you just look at the solution to the problem, it isn't that enlightening and everything starts to look the same. When we wrote design patterns we often had this feeling??hey all started to look like the Strategy pattern.
http://www.artima.com/lejava/articles/patterns_practice.html
(google search)
(amazon search)
Sun Apr 15 11:26:55 GMT 2007
From
/weblog/design/interview
Interview of netbean developers, I feel this is a lot more promotion than sharing of technology. However, these still valuable -
http://blogs.sun.com[..]ree_interviews_with_language_programmers
(google search)
(amazon search)
Thu Oct 12 07:49:07 GMT 2006
From
/weblog/design/interview
Have anyone read "Effective Java"? Compare the "item 10: Override clone judiciously" with this interview is fun
http://www.artima.com/intv/issuesP.html No perfect design because we need difference design trade off for difference task, like performance, time, resource, ....
No perfect design because difference user have difference expectation of API ....
No perfect design because requirement change by time
http://www.artima.com/intv/perfect.html
(google search)
(amazon search)