Sat May 23 04:22:23 GMT 2020
From
/weblog/design
http://c2.com/cgi/wiki?RefactoringLanguage Refactoring to Patterns Catalog -
http://www.industriallogic.com/xp/refactoring/catalog.html Article talk about the book:
http://www.oreillynet.com/ruby/blog/2006/03/transformation.html Catagories smell into "smell in class" and "smell between class" -
http://www.codinghorror.com/blog/archives/000589.html Known but good to remind
http://www.thecodejunkie.com[..]10/01/6-steps-to-master-refactoring.html An experience sharing -
http://www.javacodegeeks.com[..]m/2011/05/refactor-hudson-god-class.html http://www.peterprovost.org[..]treme-Refactoring-with-Brian-Button.aspx Refactoring should not introduce bug... -
http://jchyip.blogspot.com[..]01/so-why-are-you-refactoring-again.html A way to have formal refactoring, through Feature Clustering, Rapid Scratch Refactoring and Twisting Classes -
http://www.thekua.com[..]rom-michael-feathers-brutal-refactoring/ Not all code change is refactoring -
http://parlezuml.com/blog/?postid=850 , and
Some common issues about refactoring code in a team -
http://www.rickylui.com[..]/2008/01/28/dont-be-a-refactoring-bigot/ http://blog.joepoon.com[..]01/dangers-of-premature-refactoring.html , beware taking the balance -
http://www.makinggoodsoftware.com[..]ith-beautiful-code-the-refactor-syndrome Refactory if needed -
http://dreamhead.blogbus.com/logs/24874404.html Refactoring, when start, when stop? -
http://martinfowler.com/bliki/OpportunisticRefactoring.html Refactoring metric -
http://www.grahambrooks.com[..]rics-based-refactoring-for-cleaner-code/ Getting rid of util class
1) If the family of methods uses different parameters, depending on optional input or representations of the same input, then consider transforming the Helper via a fluent interface using the Builder pattern: from a collection of static methods like Helper.calculate(x), calculate(x, y), calculate(x, z), calculate(y, z) we could easily get to something like newBuilder().with(x).with(y).calculate(). The helper class would then offer behaviours, reduce its list of business methods and provide more flexibility for future extensions. Callers would then use it as internal field for reuse or instantiate it where needed. The helper class (as we knew it) disappeared.
2) If the helper class provides methods which are actually actions for different inputs (but, at this point, for the same domain), consider applying the Command pattern: the caller will actually create the required command (which will handle the necessary input and offer a behaviour) and an invoker will execute it within a certain context. You may get a command implementation for each static method and your code would move from an Helper.calculate(x, y), calculate(z) to something like invoker.calculate(new Action(x, y)). Bye bye helper class.
3) If the helper class provides methods for the same input but different logics, consider applying the Strategy pattern: each static method may easily become a strategy implementation, vanishing the need of its original helper class (replaced by a context component then).
4) If the given set of static methods concerns a certain class hierarchy or a defined collection of components, then consider applying the Visitor pattern: you may get several visitor implementations providing different visit methods which would probably replace partially or entirely the previously existing static methods.
5) If none of the above cases met your criteria, then apply the three most important indicators: your experience, your competences in the given project and common sense.
http://www.refactoringideas.com[..]-to-get-rid-of-helper-and-utils-classes/ Converting forloop to streaming -
http://martinfowler.com/articles/refactoring-pipelines.html Refactoring JavaScript from Sync to Async in Safe Baby-Steps -
http://www.natpryce.com/articles/000812.html code-refactoring-dos-donts -
https://jaxenter.com/code-refactoring-dos-donts-135960.html Let clean code guide you. Then let it go. -
https://overreacted.io/goodbye-clean-code/ https://www.infoq.cn/article/dNO484YEeumvC6b6ZNWL https://martinfowler.com/articles/class-too-large.html
(google search)
(amazon search)
Sat Mar 28 12:09:46 GMT 2020
From
/weblog/design/distribute
There are two key primary ways of scaling web applications which is in practice today.
1) “Vertical Scalability” - Adding resource within the same logical unit to increase capacity. An example of this would be to add CPUs to an existing server, or expanding storage by adding hard drive on an existing RAID/SAN storage.
2) “Horizontal Scalability” - Adding multiple logical units of resources and making them work as a single unit. Most clustering solutions, distributed file systems, load-balancers help you with horizontal scalability.
Scalability can be further sub-classified based on the “scalability factor”.
1) If the scalability factor stays constant as you scale. This is called “linear scalability“.
2) But chances are that some components may not scale as well as others. A scalability factor below 1.0 is called “sub-linear scalability“.
3) Though rare, its possible to get better performance (scalability factor) just by adding more components (i/o across multiple disk spindles in a RAID gets better with more spindles). This is called “supra-linear scalability“.
4) If the application is not designed for scalability, its possible that things can actually get worse as it scales. This is called “negative scalability“.
http://www.royans.net/arch/2007/09/22/what-is-scalability/ Report of building web application with 55k pageload with rail -
http://shanti.railsblog.com[..]mongrels-handled-a-550k-pageview-digging XMPP a IM protocol about scalability -
http://www.process-one.net[..]icle/the_aol_xmpp_scalability_challenge/ Presentation and resources of making you website more scalable -
http://www.scribd.com[..]9/Real-World-Web-Performance-Scalability http://www.theserverside.com[..]lications&asrc=EM_NLN_3990118&uid=703565 http://www.theserverside.com[..]ionsPart2&asrc=EM_NLN_3990119&uid=703565 Brian Zimmer, architect at travel startup Yapta, highlights some worst practices jeopardizing the growth and scalability of a system:
* The Golden Hammer. Forcing a particular technology to work in ways it was not intended is sometimes counter-productive. Using a database to store key-value pairs is one example. Another example is using threads to program for concurrency.
* Resource Abuse. Manage the availability of shared resources because when they fail, by definition, their failure is experienced pervasively rather than in isolation. For example, connection management to the database through a thread pool.
* Big Ball of Mud. Failure to manage dependencies inhibits agility and scalability.
* Everything or Something. In both code and application dependency management, the worst practice is not understanding the relationships and formulating a model to facilitate their management. Failure to enforce diligent control is a contributing scalability inhibiter.
* Forgetting to check the time. To properly scale a system it is imperative to manage the time alloted for requests to be handled.
* Hero Pattern. One popular solution to the operation issue is a Hero who can and often will manage the bulk of the operational needs. For a large system of many components this approach does not scale, yet it is one of the most frequently-deployed solutions.
* Not automating. A system too dependent on human intervention, frequently the result of having a Hero, is dangerously exposed to issues of reproducibility and hit-by-a-bus syndrome.
* Monitoring. Monitoring, like testing, is often one of the first items sacrificed when time is tight.
http://highscalability.com/scalability-worst-practices Useful Corporate Blogs that Talk About Scalability -
http://highscalability.com[..]l-corporate-blogs-talk-about-scalability Overview of mapreduce and how it compare with other distributed programming model
-http://natishalom.typepad.com[..]0/is-mapreduce-going-to-main-stream.html Paper of data store at amazon
http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html Discuss how haven't sync can cause performance issue -
http://www.theserverside.com[..]lications&asrc=EM_NLN_6273194&uid=703565 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423457 Discussion about Cloud Based Memory Architectures -
http://highscalability.com[..]ased-memory-architectures-next-big-thing http://highscalability.com[..]alability-and-performance-best-practices Interview with google engineer -
http://www.zdnet.co.uk[..]gle-at-scale-everything-breaks-40093061/ Surprisingly youtube is blocking -
http://highscalability.com[..]e-scalability-lessons-in-30-minutes.html If we are seeing a sustained arrival rate of requests, greater than our system is capable of processing, then something has to give. Having the entire system degrade is not the ideal service we want to give our customers. A better approach would be to process transactions at our systems maximum possible throughput rate, while maintaining a good response time, and rejecting requests above this arrival rate. -
http://mechanical-sympathy.blogspot.com.au[..]apply-back-pressure-when-overloaded.html How twitter scaling -
http://www.infoq.com/presentations/Twitter-Analytics How Reddit scaling -
http://www.infoq.com/presentations/scaling-reddit How Hotjar scaling -
https://www.hotjar.com[..]-while-scaling-hotjars-tech-architecture How infiniteDB prevent locking and IO -
http://highscalability.com[..]-scalable-relational-database-manag.html http://highscalability.com[..]ard-way-about-scaling-a-million-use.html http://martin.kleppmann.com[..]2014/03/26/six-things-about-scaling.html The experiences of various big companies, about network issues -
http://aphyr.com/posts/288-the-network-is-reliable Stackoverflow, scale without cloud -
http://highscalability.com[..]nth-25-servers-and-i.html?SSLoginOk=true How netflix scale -
http://highscalability.com[..]ix-what-happens-when-you-press-play.html Scaling to 100k Users -
https://alexpareto.com[..]ity/systems/2020/02/03/scaling-100k.html https://www.infoq.cn/article/Tyx5HwaD9OKNX4xzFaFo
(google search)
(amazon search)
Thu Mar 09 15:13:09 GMT 2017
From
/weblog/design
Someone saying that having private method is anti-pattern, here is the discussion -
http://www.infoq.com/news/2008/01/private-methods-tdd-design Discussion of encapsulation -
http://niket-this.blogspot.com[..]/encapsulation-does-it-really-exist.html My view on this is that most of the time there's little value in self-encapsulation. The value of encapsulation is proportional to the scope of the data access. Classes are usually small (at least mine are) so direct access isn't going to be an issue within that scope. Most accessors are simple assignments for the setter and retrieval for the getter, so there's little value in using them internally. -
https://martinfowler.com/bliki/SelfEncapsulation.html
(google search)
(amazon search)
Tue Feb 21 09:44:20 GMT 2017
From
/weblog/design
A paper show the evolution of a DSL -
http://www.mockobjects.com/files/evolving_an_edsl.ooplsa2006.pdf A stock trading order example of DSL -
http://debasishg.blogspot.com[..]05/designing-internal-dsls-in-scala.html What is the difference between API / DSL if we don't write a parser for our language? From Martin Fowler's blog -
http://martinfowler.com/bliki/DslReadings.html , it is mentioned:
Piers Cawley makes the point that a key characteristic of DSLs is their narrow focus on a domain.
I think this is a very good summary, usually if most of the APIs are getXXX() , setXXX(), loadXXX() , createXXX() ........ Then we mostly design APIs that expose low level detail to the API user to work on, which, is work but user probably work nicer if we can come up with language like API that allow users to do their work in more descriptive level.
I think if API design like that usually it will reduce the code duplication, what ever real duplication or conceptual duplication. It probably already apply "Tell, don't ask" style -
http://c2.com/cgi/wiki?TellDontAsk A discussion about applying "Tell, don't ask" which lead to message passing architecture -
http://beautifulcode.oreillynet.com[..]07/10/do_messages_want_to_be_asynchr.php And other discussion about "Tell, don't ask"
http://sriramnarayan.blogspot.com[..]/2008/11/demeters-law-tell-dont-ask.html http://sriramnarayan.blogspot.com[..]part-two-demeters-law-tell-dont-ask.html http://sriramnarayan.blogspot.com[..]rt-three-demeters-law-tell-dont-ask.html One good sample with explaination -
http://hamletdarcy.blogspot.com[..]-it-really-domain-specific-language.html http://nat.truemesh.com/archives/000727.html Few links -
http://dreamhead.blogbus.com/logs/17667876.html From CRUD to DDD -
http://www.udidahan.com[..]2/15/from-crud-to-domain-driven-fluency/ I like this: "XML abuse reduction (conducting an “XML Intervention”)" -
http://www.lostechies.com[..]ps-internal-dsl-draft-outline-notes.aspx DSL maybe the result of encapsulation -
http://dreamhead.blogbus.com/logs/214225975.html Excellent implementation of extending java yourself -
http://www.infoq.com/presentations/JetBrains-MPS-DSL http://www.infoq.com/presentations/JetBrains-MPS-DSL-2 How DSL method named -
http://tech.pro[..]he-java-fluent-api-designer-crash-course https://tomassetti.me/domain-specific-languages/
(google search)
(amazon search)