There is, I think, something ethereal about i —the square root of minus one. I remember first hearing about it at school. It seemed an odd beast at that time—an intruder hovering on the edge of reality.

Usually familiarity dulls this sense of the bizarre, but in the case of i it was the reverse: over the years the sense of its surreal nature intensified. It seemed that it was impossible to write mathematics that described the real world in …

I and i

Basics of qualitative research: Grounded theory procedures and techniques

According to W. Edwards Deming, American companies require nothing less than a transformation of management style and of governmental relations with industry. In Out of the Crisis, originally published in 1982, Deming offers a theory of management based on his famous 14 Points for Management. Management's failure to plan for the future, he claims, brings about loss of market, which brings about loss of jobs. Management must be judged not only by the quarterly dividend, but by innovative plans to stay in business, protect investment, ensure future dividends, and provide more jobs through improved product and service. In simple, direct language, he explains the principles of management transformation and how to apply them.

Out of the Crisis

How has Japan become a major economic power, a world leader in the automotive and electronics industries? What is the secret of their success? The consensus has been that, though the Japanese are not particularly innovative, they are exceptionally skilful at imitation, at improving products that already exist. But now two leading Japanese business experts, Ikujiro Nonaka and Hiro Takeuchi, turn this conventional wisdom on its head: Japanese firms are successful, they contend, precisely because they are innovative, because they create new knowledge and use it to produce successful products and technologies. Examining case studies drawn from such firms as Honda, Canon, Matsushita, NEC, 3M, GE, and the U.S. Marines, this book reveals how Japanese companies translate tacit to explicit knowledge and use it to produce new processes, products, and services.

The knowledge-creating company : how Japanese companies create the dynamics of innovation

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

One form of type checking used in gradually typed language is transient type checking: whenever an object 'flows' through code with a type annotation, the object is dynamically checked to ensure it has the methods required by the annotation. Just-in-time compilation and optimisation in virtual machines can eliminate much of the overhead of run-time transient type checks. Unfortunately this optimisation is not uniform: some type checks will significantly decrease, or even increase, a program's performance. 
In this paper, we refine the so called "Takikawa" protocol, and use it to identify which type annotations have the greatest effects on performance. In particular, we show how graphing the performance of such benchmarks when varying which type annotations are present in the source code can be used to discern potential patterns in performance. We demonstrate our approach by testing the Moth virtual machine: for many of the benchmarks where Moth's transient type checking impacts performance, we have been able to identify one or two specific type annotations that are the likely cause. Without these type annotations, the performance impact of transient type checking becomes negligible. 
Using our technique programmers can optimise programs by removing expensive type checks, and VM engineers can identify new opportunities for compiler optimisation.

/pdf/which-of-my-transient-type-checks-are-not-almost-free-207w5ovwnq.pdf

Which of My Transient Type Checks Are Not (Almost) Free

3D web software visualization has always been expensive, special purpose, and hard to program. Most of the technologies used require large amounts of scripting, are not reliable on all platforms, are binary formats, or no longer maintained. We can make 3D software visualization of object-oriented programs cheap, portable, and easy by using X3D, which is a new open standard for web 3D graphics. In this film we show our X3D web software visualizations in action.

X3D web software visualization in action

The Customer is the only non-developer role in eXtreme Programming (XP). The Customer’s explicit responsibilities are to drive the project, providing project requirements (user stories) and quality control (acceptance testing). Unfortunately the customer must also shoulder a number of implicit responsibilities including liaison with external project stakeholders, especially project funders, clients, and end users, while maintaining the trust of both the development team and the wider business. In this paper, we provide a small collection of patterns that that describe useful models for the customer, showing how other roles involved in the process can be adapted to also serve as the XP customer. Introduction The initial description of Extreme Programming (XP) assumed an in-house project with an inhouse customer, so that the goals and attitudes of customers and developers are closely aligned. Many projects are much more remote: often, developers never meet or speak to their actual customers, who may work for a different organisation in a different continent. Even the flagship C3 project failed because they were targeting the wrong customer in the end [2]. The Customer is the only non-developer role in eXtreme Programming . The Customer’s explicit responsibilities are to drive the project, providing project requirements (user stories) and quality control (acceptance testing): unfortunately the customer must also shoulder a number of implicit responsibilities including liaison with external project stakeholders, especially project funders, clients, end users, and defending the project against office politics, while at the same time maintaining the trust of both the development team and the wider business environment. The customer role is critical in making decisions about “what to build” and, in the minimalist philosophy of XP, the following are recommended for the customer role [6]: • The customer is an integral part of the team and should be on-site with the team • The customer writes user stories and then discusses each requirement directly with the programmers • The customer is responsible for all business decisions including prioritising user story development • The small 2-3 week iterations allow the customer to evolve their requirements based on concrete working software • The customer regularly tests the software to confirm it works as expected. XP explicitly assumes that the customer knows the domain well and is able to make decisions and as such does not provide ‘how-to’ advice on gathering, expressing and prioritising requirements. In this paper we present several patterns that all address this general context, that identify several different ways of solving the same problem: how to find customers, especially for out-

My Friend the Customer.

Languages with explicit dynamic type checking are increasing in popularity in both practical development and programming education. Unfortunately, current implementations of these languages perform worse than either purely statically or purely dynamically typed languages. We show how virtual machines can use common optimizations to remove redundancy in dynamic type checking, by adding shallow structural type checks to Moth, a Truffle-based interpreter for Grace. Moth runs programs with dynamic type checks roughly as fast as programs without checks, so developers do not need to disable checks in production code, and educators can teach types without also teaching that types slow programs down.

Shallow Types for Insightful Programs: Grace is Optional, Performance is Not.

• collection syntax and collection literals • tuples vs multiple values vs multiple returns • nested static type system (although we’ve made a start) • encapsulation system • module system • metadata (Java’s @annotations, C] attributes, final, abstract etc) • purity and non-nulls. • reflection • assertions, data-structure invariants, pre & post conditions, contracts • regexps • test support • libraries, including more Numeric types

James Noble

Papers

Which of My Transient Type Checks Are Not (Almost) Free

X3D web software visualization in action

My Friend the Customer.

Shallow Types for Insightful Programs: Grace is Optional, Performance is Not.

The Gr ace Programming Language Draft Specific ation Version 0.3.1261