Ruby conf'11

Editor's Notes

• #2: \n
• #3: Next slide --> must be wondering why I have put emphasis on the word Enterprise\n
• #4: Next slide --> ruby in enterprise\nBefore we dive deep into the session, let me introduce the penetration of Ruby in the Enterprise.\nWe have been doing Ruby work for more than 4 years now.\n\n
• #5: Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
• #6: Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
• #7: Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
• #8: Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
• #9: Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
• #10: Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
• #11: Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
• #12: Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
• #13: Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
• #14: Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
• #15: Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
• #16: Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
• #17: Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
• #18: Next Slide --> So, coming back. The rest of the session would be focussed on our journey building an Analytics application for healthcare system and how we used Ruby to solve this problem.\n
• #19: Next Slide --> We had few design philosophies. The first one is simplicity\n
• #20: Next Slide --> We had few design philosophies. The first one is simplicity\n
• #21: Next Slide --> We had few design philosophies. The first one is simplicity\n
• #22: Next --> portability\n
• #23: Next --> security\n
• #24: Next --> consistency\n\n
• #25: The consistency in interface design is very important. For analytics appln, there are other irregularities which has to be taken care:\n     - Consistent unit of data\n     - Data format\n     - Abbreviations should have clear meaning\n\nNext --> scalability\n
• #26: Next --> multi-dimensional data\n
• #27: \n
• #28: \n
• #29: \n
• #30: Next slide --> Lets me share how we built the data platform.\n
• #31: 3 step process to build the platform\nNext --> scalability\n
• #32: - Massaging, cleaning and aggregating raw data from various sources which are parked on raw staging tables.\n\n
• #33: - Build Kimberley Style Dimensional Data Warehouse\n\n
• #34: - Build application specific tables and olap cubes which were consumes for analytics\n- tables were flattened materialized views\n- cubes for analytics in the appln\n- due to security we had to make sure data is scedure which meant we have to segregate the aggregated and patient level data\n- in the upcoming slide I will show how data flows from source to application tier\nNext --> data mapping\n
• #35: \n
• #36: - safe haven for data\nLinking -- Sets of data from which the identifiable data has been separated and a ‘key’ added so that the data can be re-connected with its identifiers\nPseudonymisation -- replacing the patient identifiable components with pseudonyms so data processing can happen\n\n
• #37: \n
• #38: \n
• #39: Let us move on to something more interesting. Solving the problem building interactive charts using this dimensional data.\nNext --> Chart Types\n
• #40: \n
• #41: The most popular data visualization JS libraries in this space are: highcharts, jqplot, graphael, infovis, protoviz, google charts, timeplot etc.\n\nThe most important criteria for selecting any library was its portability across multiple platforms and browsers. We narrowed down on highcharts which satisfies all the kind of charts that our appln demands. We also used Inforviz's Spacetree to build organization hierarchical chart.\n\nThe kind of data visualization requirement we had required us to extend the libraries.\nThe first in the list is Org chart which is an extension of Spacetree api of Infovis\n\n
• #42: The most popular data visualization JS libraries in this space are: highcharts, jqplot, graphael, infovis, protoviz, google charts, timeplot etc.\n\nThe most important criteria for selecting any library was its portability across multiple platforms and browsers. We narrowed down on highcharts which satisfies all the kind of charts that our appln demands. We also used Inforviz's Spacetree to build organization hierarchical chart.\n\nThe kind of data visualization requirement we had required us to extend the libraries.\nThe first in the list is Org chart which is an extension of Spacetree api of Infovis\n\n
• #43: The most popular data visualization JS libraries in this space are: highcharts, jqplot, graphael, infovis, protoviz, google charts, timeplot etc.\n\nThe most important criteria for selecting any library was its portability across multiple platforms and browsers. We narrowed down on highcharts which satisfies all the kind of charts that our appln demands. We also used Inforviz's Spacetree to build organization hierarchical chart.\n\nThe kind of data visualization requirement we had required us to extend the libraries.\nThe first in the list is Org chart which is an extension of Spacetree api of Infovis\n\n
• #44: The most popular data visualization JS libraries in this space are: highcharts, jqplot, graphael, infovis, protoviz, google charts, timeplot etc.\n\nThe most important criteria for selecting any library was its portability across multiple platforms and browsers. We narrowed down on highcharts which satisfies all the kind of charts that our appln demands. We also used Inforviz's Spacetree to build organization hierarchical chart.\n\nThe kind of data visualization requirement we had required us to extend the libraries.\nThe first in the list is Org chart which is an extension of Spacetree api of Infovis\n\n
• #45: The most popular data visualization JS libraries in this space are: highcharts, jqplot, graphael, infovis, protoviz, google charts, timeplot etc.\n\nThe most important criteria for selecting any library was its portability across multiple platforms and browsers. We narrowed down on highcharts which satisfies all the kind of charts that our appln demands. We also used Inforviz's Spacetree to build organization hierarchical chart.\n\nThe kind of data visualization requirement we had required us to extend the libraries.\nThe first in the list is Org chart which is an extension of Spacetree api of Infovis\n\n
• #46: \n
• #47: \n
• #48: Next --> Configurable charts\nThe business problem was to simplify the chart creation process. It should be possible to do a new custom chart with arbitrary dimensions (given an existing cube / table of date in the DW) and add it to the app with a few hours work.\n
• #49: \n
• #50: \n
• #51: \n
• #52: \n
• #53: \n
• #54: \n
• #55: \n
• #56: \n
• #57: So, few hours of chart configuration by power users would enable data visualization in different kind of chart.\n\nThe only problem left here to solve was communication between ruby and OLAP cubes in MS SQL Server AS.\n\n
• #58: SQL Server Analysis Servies exposes XMLA interface to communicate to OLAP Cubes.\nFor consuming cube data from SQL Server Analysis Services into our ruby application we had 2 choices. \n
• #59: Use existing libraries like olap4j which sits as a service between our app and Analysis Services. This would have meant, we would have bite the bullet of porting the app to JRuby \n
• #60: Build the ruby xmla interface ourselves, kind of olap4r\n\nNext slide --> Some principles we kept in mind while designing the XMLA interface in ruby\n
• #61: - the library should output data in JSON format for the charting library to consume\n- It should be agnostic to XMLA interface\n- Data security because cubes had dimensional data\n- MDX is pretty complex language. Stay away from becoming mdx validation.  \n\nNext Slide --> In the following slides we would see some code samples explaining the communication between AS and Ruby.\n
• #62: - the library should output data in JSON format for the charting library to consume\n- It should be agnostic to XMLA interface\n- Data security because cubes had dimensional data\n- MDX is pretty complex language. Stay away from becoming mdx validation.  \n\nNext Slide --> In the following slides we would see some code samples explaining the communication between AS and Ruby.\n
• #63: - the library should output data in JSON format for the charting library to consume\n- It should be agnostic to XMLA interface\n- Data security because cubes had dimensional data\n- MDX is pretty complex language. Stay away from becoming mdx validation.  \n\nNext Slide --> In the following slides we would see some code samples explaining the communication between AS and Ruby.\n
• #64: \n
• #65: - discover method\n- request type (mdsschema_cubes)\n
• #66: - discover method\n- request type (mdsschema_cubes)\n
• #67: - discover method\n- request type (mdsschema_cubes)\n
• #68: \n
• #69: \n
• #70: \n
• #71: \n
• #72: Keep in mind Pareto Principle - 80/20. Pareto Principle in the context of UI basically says 20% of functionality is used 80% of the time.\n
• #73: Keep in mind Pareto Principle - 80/20. Pareto Principle in the context of UI basically says 20% of functionality is used 80% of the time.\n
• #74: Keep in mind Pareto Principle - 80/20. Pareto Principle in the context of UI basically says 20% of functionality is used 80% of the time.\n
• #75: Keep in mind Pareto Principle - 80/20. Pareto Principle in the context of UI basically says 20% of functionality is used 80% of the time.\n
• #76: \n
• #77: \n
• #78: \n
• #79: \n
• #80: \n
• #81: \n
• #82: \n
• #83: \n
• #84: \n
• #85: \n