download zip of files only
Sat Jan 01 12:44:21 GMT 2022
From /weblog/design
Date handling look simple but easy to fail in trap. Even worst is this is easy to have bad data which hard to fix. Here is an example - http://blogs.msdn.com/jensenh/archive/2005/11/23/496246.aspx One tip for testing application with time dependence, treat it as random - http://googletesting.blogspot.com[..]pot.com/2008/04/tott-time-is-random.html Explanation of issues of Joda-time, basically it still haven't map the human view of time close enough than machine view of time - http://www.jroller.com/scolebourne/entry/why_jsr_310_isn_t Screencast of how to driven a fluent Date API - http://tedyoung.blogsome.com[..]-apis-in-java-episode-1-comparing-dates/ 解读数据架构的 2021：大数据 1.0 体系基本建成，但头上仍有几朵乌云 - https://www.infoq.cn/article/gHTPkmo0vZhE7vwFAGij
(google search)
(amazon search)
Sun Oct 11 13:31:07 GMT 2020
From /weblog/design
"Bad programmers worry about the code. Good programmers worry about data structures and their relationships." - http://programmers.stackexchange.com[..]uote-about-good-programmer/163187#163187 Compare between schema and schema=less ( like key value mapping ) data - http://martinfowler.com/articles/schemaless/ Simple AVL tree - https://www.baeldung.com/java-avl-trees 逼着面试官问了我 ArrayList 和 LinkedList 的区别，他对我彻底服了 - https://xie.infoq.cn/article/34fa38d821b065e26662e6598
(google search)
(amazon search)
Fri Aug 21 13:54:46 GMT 2020
From /weblog/design
This is a message from a management blog, but I think the arguement is also apply API design. In fact, I think most critical difference of good and bad API is knowing which small detail is important and which is not - http://www.goodproductmanager.com[..]er.com/2007/11/08/sweat-the-small-stuff/ Design tips: http://www.artima.com/weblogs/viewpost.jsp?thread=142428 http://openide.netbeans.org/tutorial/api-design.html http://www.cincomsmalltalk.com[..]gView?showComments=true&entry=3258158706 http://today.java.net[..]its-of-highly-profitable-developers.html http://www.infoq.com/news/2007/08/why-api-design-matters http://www.infoq.com/presentations/effective-api-design http://neuroning.com/2006/11/19/on-api-design-guidelines About Compatibility issues http://wiki.eclipse.org/Evolving_Java-based_APIs A blog of using interfaces-vs-abstract-classes http://hoskinator.blogspot.com[..]6/04/interfaces-vs-abstract-classes.html XOM design overview - http://www.xom.nu/designprinciples.xhtml#d0e309 You need to identify the business value but not pick any tools/design just because it is cool - http://myarch.com/what-is-good-soa A lot of links here - http://kasparov.skife.org/blog-live/src/api-design-refs.writeback http://discuss.joelonsoftware.com/default.asp?design.4.527465 An introduction of good OSS project to study their source - http://techkriti.wordpress.com[..]com/2007/06/28/learning-from-the-source/ CCCCDPIPE - http://blog.objectmentor.com/articles/2007/08/02/which-came-first Discussion of why getting feedback quick is important - http://blog.objectmentor.com[..]u-dont-know-until-you-take-the-next-step Someone saying that routines is the greatest invention in CS, I agree - http://www.codinghorror.com/blog/archives/001129.html New way of modeling system then layering, The Onion Architecture - http://jeffreypalermo.com/blog/the-onion-architecture-part-1/ SOLID - http://www.lostechies.com[..]of-the-month-march-solid-principles.aspx http://dotnet.dzone.com/news/solid-software-works <-- very good picture! http://www.blackwasp.co.uk/SOLIDPrinciples.aspx https://www.freecodecamp.org[..]d-principles-explained-in-plain-english/ Idempotent, Orthogonality, Immutability - http://www.codinghorror.com/blog/archives/001244.html Some example of how to driven good API - http://jdegoes.squarespace.com[..]al/2009/5/11/good-api-design-part-3.html It's not enough to write tests for an API you develop, you have to write unit tests for code that uses your API. When you do, you learn first-hand the hurdles that your users will have to overcome when they try to test their code independently. http://butunclebob.com[..]MichaelFeathers.TheGoldenRuleOfApiDesign Active interface vs. Passive interface, for me this is another way to under "Tell, don't ask" - http://code-o-matic.blogspot.com[..]-on-api-design-call-stack-as-source.html The Principles of Good Programming - http://www.artima.com/weblogs/viewpost.jsp?thread=331531 http://net.tutsplus.com[..]software-principles-you-must-understand/ Difference choice of how API evolute with change - http://blog.jooq.org[..]sive-api-evolution-with-java-interfaces/ JUnit's evolving structure. - http://edmundkirwan.com/general/junit.html API performance contract - http://queue.acm.org/detail.cfm?ref=rss&id=2576968 Consistent naming conventions Standard terminology Uniform error responses Attention to detail (that’s the love part for APIs) REST APIs that work with only 2 resources and use 4 HTTP verbs (oh, there is so much more to talk about here…) Avoid API design by way of method-driven approach – that leads you down a slippery slope - See more at: http://blogs.ancestry.com[..]are-like-parenting/#sthash.Ux1LHMNU.dpuf http://blog.jooq.org[..]ake-this-mistake-when-developing-an-spi/ Guideline for webapi - https://cloud.google.com/apis/design/ Good naming is part of design. It sets expectations and communicates a model, showing how something should be understood and used. If you mean to tell the reader getMillisSince1970, don’t say getTime. Specific names inspire you to consider alternatives, to question whether you’re capturing the right abstraction in the right way. It’s not just labeling and it’s not just java.util.Date: This is about the code you write and the code you use. - https://medium.com/97-things/name-the-date-c82bafdc4c44
(google search)
(amazon search)
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)
|