download zip of files only
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)
Mon Sep 12 16:10:46 GMT 2016
From /weblog/design
http://highscalability.com[..]here-and-it-costs-you-sales-how-crush-it *Do not use locks in the main transaction flow because they cause context switches, and therefore latency and unpredictable jitter. *Never have more threads that need to run than you have cores available. *Set affinity of threads to cores, or at least sockets, to avoid cache pollution by avoiding migration. This is particularly important when on a server class machine having multiple sockets because of the NUMA effect. *Ensure uncontested access to any resource respecting the Single Writer Principle so that the likes of biased locking can be your friend. *Keep call stacks reasonably small. Still more work to do here. If you are crazy enough to use Spring, then check out your call stacks to see what I mean! The garbage collector has to walk them finding reachable objects. *Do not use finalizers. *Keep garbage generation to modest levels. This applies to most JVMs but is likely not an issue for Zing. *Ensure no disk IO on the main flow. *Do a proper warm-up before beginning to measure. *Do all the appropriate OS tunings for low-latency systems that are way beyond this blog. For example turn off C-States power management in the BIOS and watch out for RHEL 6 as it turns it back on without telling you! *Macro-benchmarking is much more valuable than micro-benchmarking. *Amazing results are achieved by truly agile companies, staffed by talented individuals, who are empowered to make things happen. Make sh*t happen is more important than following a process. http://highscalability.com[..]ughput-by-32x-and-reduce-latency-by.html http://bravenewgeek.com[..]rything-you-know-about-latency-is-wrong/ How to monitor - https://plumbr.eu[..]siness-value-from-performance-monitoring How to measure latency - https://vanilla-java.github.io[..]/07/20/Latency-for-a-set-Throughput.html Various cause of latency, and the solution - https://www.informatica.com[..]Topics-in-High-Performance-Messaging.htm
(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 31 11:11:17 GMT 2014
From /weblog/design
Case study of a parallel slowdown, and the analysis of how to find it out - http://webtide.intalio.com[..]2/avoiding-parallel-slowdown-in-jetty-9/ Discuss about the racing condition when multiple accessing java.util.HashMap - http://mailinator.blogspot.com.au[..]au/2009/06/beautiful-race-condition.html
(google search)
(amazon search)
Thu Dec 11 10:21:23 GMT 2014
From /weblog/design/pattern
Sometime it is better to notify user about failing to validate input than throw - http://martinfowler.com[..]ticles/replaceThrowWithNotification.html
(google search)
(amazon search)
Thu Sep 18 06:47:54 GMT 2014
From /weblog/design
Writing shy code is just a small start at preventing the introduction of bugs, but it really helps. Just as in the real world, good fences make good neighbor - as long as you don't peek through them. http://www.computer.org/software/homepage/2003/s1const.htm http://www.pragmaticprogrammer.com/ppllc/papers/1998_05.html Other than that, there is also security risk if you show too much to other - http://www.indicthreads.com[..]_or_objects_java_security_problem_1.html An example of why passing Map around is wrong and show solution of that example - http://antagonisticpleiotropy.blogspot.com[..]spot.com/2008/01/hashmap-temptation.html Quoting from Getting Method in Beck’s 1997 Smalltalk Best Practice Patterns (emphasis his): “Here’s the real secret of writing good Getting Methods - make them private at first. I cannot stress this enough. … There are cases where you will publish the existence of Getting Methods for use in the outside world. You should make a conscious decision to do this after considering all the alternatives. It is preferable to give an object more responsibility, rather than have it act like a data structure.” Quoting from Setting Method: “Everything I said once about Getting Methods, I’d like to say twice about Setting Methods. Setting Methods should be even more private. It is one thing for another object to tear out your state, it is quite another for it to bash in a new state.” http://tech.groups.yahoo.com[..]om/group/domaindrivendesign/message/5701 East: Clean and DRY, an example of why tell don't ask help - http://jamesladdcode.com/?p=294 But personally, I don't use tell-dont-ask. I do look to co-locate data and behavior, which often leads to similar results. - http://martinfowler.com/bliki/TellDontAsk.html Another discussion about getter and setter - http://www.yegor256.com[..]/09/16/getters-and-setters-are-evil.html
(google search)
(amazon search)
Mon May 19 07:37:30 GMT 2014
From /weblog/design/examples
Show how TDD can help OpenSSL to prevent heartbleed if they do it at the first place - http://martinfowler.com/articles/testing-culture.html
(google search)
(amazon search)
|