Objective: Funnel plots (plots of effect estimates against sample size) may be useful to detect bias in meta-analyses that were later contradicted by large trials. We examined whether a simple test of asymmetry of funnel plots predicts discordance of results when meta-analyses are compared to large trials, and we assessed the prevalence of bias in published meta-analyses. Design: Medline search to identify pairs consisting of a meta-analysis and a single large trial (concordance of results was assumed if effects were in the same direction and the meta-analytic estimate was within 30% of the trial); analysis of funnel plots from 37 meta-analyses identified from a hand search of four leading general medicine journals 1993-6 and 38 meta-analyses from the second 1996 issue of the Cochrane Database of Systematic Reviews . Main outcome measure: Degree of funnel plot asymmetry as measured by the intercept from regression of standard normal deviates against precision. Results: In the eight pairs of meta-analysis and large trial that were identified (five from cardiovascular medicine, one from diabetic medicine, one from geriatric medicine, one from perinatal medicine) there were four concordant and four discordant pairs. In all cases discordance was due to meta-analyses showing larger effects. Funnel plot asymmetry was present in three out of four discordant pairs but in none of concordant pairs. In 14 (38%) journal meta-analyses and 5 (13%) Cochrane reviews, funnel plot asymmetry indicated that there was bias. Conclusions: A simple analysis of funnel plots provides a useful test for the likely presence of bias in meta-analyses, but as the capacity to detect bias will be limited when meta-analyses are based on a limited number of small trials the results from such analyses should be treated with considerable caution. Key messages Systematic reviews of randomised trials are the best strategy for appraising evidence; however, the findings of some meta-analyses were later contradicted by large trials Funnel plots, plots of the trials9 effect estimates against sample size, are skewed and asymmetrical in the presence of publication bias and other biases Funnel plot asymmetry, measured by regression analysis, predicts discordance of results when meta-analyses are compared with single large trials Funnel plot asymmetry was found in 38% of meta-analyses published in leading general medicine journals and in 13% of reviews from the Cochrane Database of Systematic Reviews Critical examination of systematic reviews for publication and related biases should be considered a routine procedure

/pdf/bias-in-meta-analysis-detected-by-a-simple-graphical-test-5erh428s5c.pdf

Bias in meta-analysis detected by a simple, graphical test

物件導向軟體之架構(Object-Oriented Software Construction)探討

From the Publisher:
Written by the inventors of the technology, The Java(tm) Language Specification, Second Edition is the definitive technical reference for the Java(tm) programming language If you want to know the precise meaning of the language's constructs, this is the source for you 
The book provides complete, accurate, and detailed coverage of the syntax and semantics of the Java programming language It describes all aspects of the language, including the semantics of all types, statements, and expressions, as well as threads and binary compatibility

/pdf/the-java-language-specification-1s92cud0yi.pdf

The Java Language Specification

We have found many programming problems for which neither procedural nor object-oriented programming techniques are sufficient to clearly capture some of the important design decisions the program must implement. This forces the implementation of those design decisions to be scattered throughout the code, resulting in “tangled” code that is excessively difficult to develop and maintain. We present an analysis of why certain design decisions have been so difficult to clearly capture in actual code. We call the properties these decisions address aspects, and show that the reason they have been hard to capture is that they cross-cut the system's basic functionality. We present the basis for a new programming technique, called aspect-oriented programming, that makes it possible to clearly express programs involving such aspects, including appropriate isolation, composition and reuse of the aspect code. The discussion is rooted in systems we have built using aspect-oriented programming.

/pdf/aspect-oriented-programming-15jlquln69.pdf

Aspect-Oriented Programming

Aspect-oriented programming (AOP) is a technique for improving separation of concerns in software design and implementation. AOP works by providing explicit mechanisms for capturing the structure of crosscutting concerns. This tutorial shows how to use AOP to implement crosscutting conerns in a concise modular way. It works with AspectJ, a seamless aspect-oriented extension to the Java(tm) programming language, and with AspectC, an aspect-oriented extension to C in the style of AspectJ. It also includes a description of their underlying model, in terms of which a wide range of AOP languages can be understood.

Aspect-oriented programming

It is our great pleasure to welcome you to ACM conference Learning at Scale 2015. In this, the second year of the conference, we have seen a significant growth in the number of submissions to the conference and an overall improvement in the quality of the contributions. This year's conference continues the tradition of being the premier forum for presentation of research results and inside stories about what makes online educational systems operate at scale.

The call for papers attracted submissions from all over the world, covering a broad range of topics from the theoretical to the pragmatic.

The program committee reviewed and accepted the following: Venue or Track Reviewed Accepted
Full Technical Papers 90 23 25% 
Short Technical Papers 12 5 41%
Work in Progress Papers 54 47 80%



Since the conference is still in its formative years, we accepted a large fraction of all the Works in Progress because we found the experience of reading through them to be so valuable. We are still a nascent field, and learning about the very latest work reflects the rapidly changing nature of what we know to be true.

We encourage attendees to attend both keynotes. These valuable and insightful talks can and will guide us to a better understanding of the future of our field: 
Achieving 96% mastery at national scale through inspired learning and generative adaptivity, Zoran Popovic (University of Washington)
Machine Learning for Learning at Scale, Peter Norvig (Google)

Proceedings of the Second (2015) ACM Conference on Learning @ Scale

Using only traditional techniques the implementation of concerns like exception handling, multi-object protocols, synchronization constraints, and security policies tends to be spread out in the code The lack of modularity for these concerns makes them more difficult to develop and maintain This tutorial shows how to use Aspect-oriented programming (AOP) [2, 3] to implement concerns like these in a concise modular way We discuss the effect aspects have on software design and on code modularity The concrete examples in the tutorial use AspectJ [1], a freely available aspect-oriented extension to the Java™ programming language

Improving design and source code modularity using AspectJ (tutorial session)

As distributed applications evolve, incremental customization of middleware services is often required; these customizations should be unpluggable, modular, and efficient. This is difficult to achieve because the customizations depend on both application-specific needs and the services provided. Although middleware allows programmers to separate application-specific functionality from lower-level details, traditional methods of customization do not allow efficient modularization. Currently, making even minor changes to customize middleware is complicated by the lack of locality. Programmers may have to compromise between the two extremes: to interpose a simple, well-localized layer of functionality between the application and middleware, or to make a large number of small, poorly localized, invasive changes to all execution points which interact with middleware services. Although the invasive approach allows a more efficient customization, it is harder to ensure consistency, more tedious to implement, and exceedingly difficult to unplug. Thus, a common approach is to add an extra layer for systemic concerns such as robustness, caching, filtering, and security. Aspect-oriented programming (AOP) offers a potential alternative between the interposition and invasive approaches by providing modular support for the implementation of crosscutting concerns. AOP enables the implementation of efficient customizations in a structured and unpluggable manner. We demonstrate this approach by comparing traditional and AOP customizations of fault tolerance in a distributed file system model, JNFS. Our results show that using AOP can reduce the amount of invasive code to almost zero, improve efficiency by leveraging the existing application behaviour, and facilitate incremental customization and extension of middleware services.

Aspect-Oriented Incremental Customization of Middleware Services

In his essay, Designed as Designer, Richard Gabriel suggests that artifacts are agents of their own design. Building on Gabriel’s position, this essay makes three observations (1) Code “speaks” to the programmer through code smells, and it talks about the shape it wants to take by signalling design principle violations. By “listening” to code, even a novice programmer can let the code itself signal its own emergent natural structure. (2) Seasoned programmers listen for code smells, but they hear in the language of design principles (3) Design patterns are emergent structures that naturally arise from designers listening to what the code is signaling and then responding to these signals through refactoring transformations. Rather than seeing design patterns as an educational destination, we see them as a vehicle for teaching the skill of listening. By showing novices the stories of listening to code and unfolding design patterns (starting from code smells, through refactorings, to arrive at principled structure), we can open up the possibility of listening for emergent design.

Learning to listen for design

The AspectJ project[1] is exploring language support to enable programmers to implement crosscutting concerns in a modular fashion. Previous work in this area has primarily examined the expressiveness of AspectJ, to further aspect-oriented programming language research. In our work we focus on critical software engineering issues related to system modularity. In particular, we want to understand how use of AspectJ interacts with the well-known data abstraction principle[2].In this abstract, we describe some of our work in identifying the explicit and implicit ways that modules can become dependent upon design decisions of another module in AspectJ. We hope that this information will provide a useful perspective to aspect-oriented programming language designers and will help users of AspectJ make informed design decisions. Given the space constraints, we must assume that the reader is familiar with the AspectJ language[1].

Gregor Kiczales

Papers

Proceedings of the Second (2015) ACM Conference on Learning @ Scale

Improving design and source code modularity using AspectJ (tutorial session)

Aspect-Oriented Incremental Customization of Middleware Services

Learning to listen for design

Data Abstraction in AspectJ