Skip to main content

Application Design Notes



  • Don’t be afraid to write your own code, but be absolutely sure you need to
  • Simple is better than perfect (nearly) every time
    • If you can deliver a sub-optimal solution (that solves the problem but has known limitation) in a week instead of a full featured one in a month DO, IT
    • Simple system are
      • Easy to reason about 
      • Easy to debug
      • Easy to refactor
      • Easy to learn
    • Simple doesn't mean you skip good engineering, but you can use duct tape.
  • Build things the right way from the start, refactoring is hard and expensive
    • Security
    • Cutout unimportant corners
    • Common retrofitting "grunt work"
      • Internationalization + localization
      • Factoring and styling HTML UI
      • Adding unit test to an existing codebase
  • LOG LOG LOG Log, but do it right
    • We spend lot of time reading and processing log
    • When error occur log as much context as possible
    • Make changing logging verbosity cheap and easy to update at same time
  • Build Profiling into your product code
    • Performance problem usually occur first time in production
    • Many large-scale production enviroment are hard to replicate 
      • Have a way to access critical profiling info for production process
      • Custom HTTMP/Tenet interface
      • Shared memory window
  • Monitor your product end to end not just sub system
    • Monitor the entire system end to end the same way as user see it
    • Monitor the health of individual component (like unit testing)
  • Avoid platform specific feature wherever you can 
    • Migration can be very-very expensive same time impossible
    • Running testing on multiple platforms will expose bugs faster
  • Write your code like you trust no one 
    • Always test precondition before function execute 
    • If something should be in give state, test for it
    • Sanitize input and output
    • Leave these tests in production code
  • Choose your dependencies carefully
    • Every dependency is a liability. You have to fix (or get fix) any error in them
    • Prefer open source to close source 
      • At least you have the option of fixing a problem
    • Dependency often increase complexity 
      • Build
      • Packaging 
      • Licensing
      • Security, verification (XSS, SQL injection, buffer overflow..)
  • If you can pre-generate something, do it
    • Lookup table are an underutilized secret weapon 
    • Memory is cheap
    • Pre calculate result if
      • The input to a computation is known to be in given range
        • The number of different results is relatively small (<1 Billion)
      • Calculation is sufficiently complex
        • Example - Pre-compute the time zone conversion from UTC to all time zone for all hours from 01/01/1991 to 12/31/2020
          • Why this is complex to calculate? 
  • Applications do crash often 
    • Avoid DDOS attack
    • Every feature will be misused or abused
    • Isolate to avoid cascade failure 
    • No such thing as a long-lived process
      • If hardware fails or power removed your process will crash
      • Design system to be fault tolerant to process re-start
        • All state must be external to process
        • Try to keep services and process stateless 
    • Keep sever stateless 
      • One app server should not affect any other server
      • Server will be easy to scale 
      • Separate cache service from other server to avoid resource contention
  • Cache appropriately  
    • Data, metadata, configuration, static data 
  • Store redundant
  • Partition by functions
    • Allow people to work independently on features
  • Split horizontally
    • If you can’t split, you can’t scale 
    • Use standard load balance to route incoming traffic 
      • Because application service created equal and not retain any transaction state
  • Decouple functions asynchronously 
    • If A call B synchronously, A & B are tightly couple. So, if B is down then A is down. 
    • A should be integrated B with asynchronously (with queue, multicast message, path processing, event driven architecture)
    •  Avoid synchronous coupling as much as possible
    • Move processing to asynchronously flow
      • Asynchronously flow example can be 
        • Activity tracking, billing, settlement, reporting, email
  • Use Feature Toggling to deliver new functionality to users rapidly but safely.
  • Virtualize at all level
    • Virtual IP for DBs
    • Virtual IP for load balancer 

Comments

Popular posts from this blog

ERROR: Ignored call to 'alert()'. The document is sandboxed, and the 'allow-modals' keyword is not set.

Recently I found this issue while writing code snippet in "JSFiddle". And after searching, found this was happening because of new feature added in "Chrome 46+". But at the same time Chrome doesn't have support for "allow-modals" property in "sandbox" attribute.

Chromium issue for above behavior:
https://codereview.chromium.org/1126253007

To make it work you have to add "allow-scripts allow-modals" in "sandbox" attribute, and use "window.alert" instead of "alert".



<!-- Sandbox frame will execute javascript and show modal dialogs --> <iframe sandbox="allow-scripts allow-modals" src="iframe.html"> </iframe>


Feature added: Block modal dialog inside a sandboxed iframe.
Link: https://www.chromestatus.com/feature/4747009953103872

Feature working Demo page:
https://googlechrome.github.io/samples/block-modal-dialogs-sandboxed-iframe/index.html



CSS Specificity

Many time different CSS rules overlap on one or more element. And some people always get confuse about, which rule will take higher priority then other and why? CSS Specificity is the answer of all these kind of questions.
As the name suggest, the CSS rule which is more specific to the element will take higher priority then other. Means something like “#some_id{}” will always take higher priority then “*{}” universal selector.  And if duplicate rules are define then the last rule will be applied to the element.

The following list of selectors is by increasing specificity:
Type selector (e.g., div) and pseudo-elements in selector (e.g., :after) Class selectors (e.g., .some_class), attributes selectors (e.g., [type=”radio”]) and pseudo-class selector (e.g., :hover) Id selectors (e.g., #some_id)


ID takes higher priority then Class, Type and Universal selector (Note: Universal selector has no effect on specificity, see below special conditions). 



If duplicate rules are given, then last…

JavaScript [ExtJs3]: EditorGridPanel Read-Only (dynamically)

Many time we face the scenerio where we have to make the editor grid read-only dynamically.


Ext.override(Ext.ux.grid.CheckColumn, { editable: true, onMouseDown: function (e, t) { if (Ext.fly(t).hasClass(this.createId())) { e.stopEvent(); var me = this, grid = me.grid, view = grid.getView(), index = view.findRowIndex(t), colindex = view.findCellIndex(t), record = grid.store.getAt(index); if (!grid.isReadOnly && grid.colModel.isCellEditable(colindex, index)) { record.set(me.dataIndex, !record.data[me.dataIndex]); } } } }); var grid = new Ext.grid.EditorGridPanel({ ... isReadOnly: true, //set to flag to make check column readonly ... }); //to make other column readonly grid.on('beforeedit', function () { return false; });