Performance Monitoring with Java Flight Recorder on OpenJDK [DEV2406]Hiroaki NAKADA
This document discusses using JDK Flight Recorder (JFR) for performance monitoring of batch processes at Rakuten Card Co., Ltd. It begins with an introduction to the company and its challenges monitoring batch operations as it migrated from mainframe to Java-based systems. It then provides an overview of JFR and how Rakuten uses it to monitor individual processes. The document outlines Rakuten's concerns regarding real-time analysis and integrating other tools. It proposes addressing these concerns by developing a real-time monitoring pipeline that extracts JFR logs, processes them with Norikra, and visualizes the results with Elasticsearch and Kibana. The presentation concludes that JFR provides opportunities to build a simple application performance monitoring system
Performance Monitoring with Java Flight Recorder on OpenJDK [DEV2406]Hiroaki NAKADA
This document discusses using JDK Flight Recorder (JFR) for performance monitoring of batch processes at Rakuten Card Co., Ltd. It begins with an introduction to the company and its challenges monitoring batch operations as it migrated from mainframe to Java-based systems. It then provides an overview of JFR and how Rakuten uses it to monitor individual processes. The document outlines Rakuten's concerns regarding real-time analysis and integrating other tools. It proposes addressing these concerns by developing a real-time monitoring pipeline that extracts JFR logs, processes them with Norikra, and visualizes the results with Elasticsearch and Kibana. The presentation concludes that JFR provides opportunities to build a simple application performance monitoring system
1) Converting documents like design documents, test plans, installation manuals, and operation manuals into code allows them to be tested and run automatically, improving reliability.
2) Reliability is improved because code is less prone to human error than documents and can be run repeatedly through testing and continuous integration environments.
3) Changing documents to code improves the reliability of products, operations, and the documents themselves by making their instructions executable and verifiable.
How to make keynote like presentation with markdownHiroaki NAKADA
This document discusses using Markdown and Pandoc to create presentations like those made in Keynote. Markdown files can be converted to PDF presentations using Pandoc, avoiding issues with other presentation software. Code blocks can be customized using listings. The example shows how to install Pandoc, convert a Markdown file to a PDF presentation using a Keynote-like theme, and modify code block formatting.
The document discusses using Ruby to add more powerful programming capabilities to Excel spreadsheets. It describes Excel as a commonly used but limited documentation tool in Japan. Ruby is proposed as a better alternative to the Visual Basic for Applications (VBA) language used for programming in Excel due to Ruby's support for regular expressions, UTF-8, closures, and object-oriented programming. The document then explains two approaches for using Ruby with Excel: using the Win32 OLE binding, which is powerful but only for Windows, and using JRuby with the Apache POI library, which supports older Excel formats but is more complex. It introduces POILite as a simpler Ruby wrapper for POI that treats Excel sheets like arrays and supports
Legacy code can be refactored if tests are written, even if the code is awful. Without tests, wonderful code is also difficult to change. There are four main reasons for changing software: adding features, fixing bugs, refactoring, and optimizing. The challenges in changing code are determining what to change, confirming the change is correct, and ensuring nothing else is broken. Not changing legacy code over time increases these risks and makes the code more complex and harder to work with.
Working effectively with legacy code chapter1Hiroaki NAKADA
This document discusses working with legacy code and reasons for changing code. It notes that while code may not be object-oriented or beautiful, lack of tests makes changing code risky. Tests allow for refactoring even awful code. The four reasons for changing code are adding features, fixing bugs, refactoring, and optimizing. Changes affect structure, new functions, existing functions, resources, and test code depending on the reason. Changing code is difficult because it's hard to determine what to change, confirm the change is correct, and ensure nothing is broken. Not changing also risks increasing complexity, decreasing change skills over time, and growing fear of changing code.