Gheorghe Curelet-Balan Blog

Friday, April 03, 2015

Annotations of The Most Wanted Particle video

The April 2015 public lecture at Waterloo's Perimeter Institute for Theoretical Physics (PI) was given by Jon Butterworth (@jonmbutterworth).

He talked about the exciting world of high energy physics, the quest for Higgs boson discovery at the Large Hadron Collider (LHC) and future plans once LHC restarts at higher energy.

It was a smashing lecture indeed: succinct, informative & accessible!

Below are my timestamped annotations of the video in mmss (minutes seconds) format:
0250 start of the talk with: "now is a very exciting time to be a physicist"
1130 ATLAS collider detector description
1510 description of the ATLAS experiment
1930 why high energy?
2050 video of analogy to the ATLAS detector
2320 Standard Model slide explained
2744 how do you give mass to something not made of anything else?
2905 how do we know that the quantum background field is there?
3033 spontaneous symmetry breaking as analogy to Higgs boson discovery
3252 Feynman diagram used to explain where mass comes from
3651 diagram illustrating how a new particle is discovered
3827 quark & antiquark diagram
3945 slice through the ATLAS detector
4108 animation diagram of two years of ATLAS experiments
4438 diagram of a different representation of Higgs discovery ATLAS collision
4514 CMS animated diagram of the Higgs boson evidence
4612 where are we now when LHC is restarting this week at higher energy?
4700 slide of What We Know and Would Like To Know
4928 Jon's hope: new candidate for dark matter will be found when LHC restarts
5046 mystery of matter and antimatter
5150 explanation on a diagram illustrating what we know and don't know about gravity & unified theory
5435 expanding universe diagram
5507 ref to plans in building a bigger collider than LHC
5610 image of SLAC/Stanford miniature accelerator on a chip
5730 Q&A
5740 q1: what LHC will be looking for dark matter evidence?
5955 q2: what is the origin of electric charge?
6120 q3: why a neutron containing a top quark has more mass than a neutron as a whole?
6212 q4: what is the theoretical or experimental basis believing us that antiparticles exist?
6355 q5: on gravity vs. expanding universe
6512 q6: on proportion between matter & dark matter

Sunday, November 16, 2014

Transcript notes of Miško Hevery - Keynote on AtScript at ng-europe 2014

Miško Hevery, the father of Angular, introduced the Angular 2.0 Javascript extension AtScript, its benefits and how it simplifies development of large Angular applications.

Below are my time stamped notes of the video in the "mmss" (MinutesSeconds) format (time stamps are approximate):

030 AtScript is not a new language and WHY
118 Angular's current directive declaration as example of a DARK API. Convoluted, not intuitive, because of many dependency injections involved
300 third party APIs call & ES6 lambdas make code unintelligible
412 need for code annotations for MAINTAINABILITY
440 example code of what is needed for better maintainability: annotated declarations and types use in a Typescript or ES4 style
648 why no new language? So, don't repeat mistakes of other languages: just extend JS, otherwise need libs & new knowledge
730 cartoon on standards for languages
750 Ideal Development Environment. IDE1: need for types in large systems development
915 types should be optional for backwards apps compatibility. The types benefit should outweigh their costs.
1010 IDE2: need for metadata to express INTENT & build ABSTRACTIONS
1040 IDE3: need for run time introspection. AtScript is at the intersection of IDE1, 2, 3
1101 types as CONTRACTS. Allow refactoring, renaming, code navigation. Code example of array of CSS Selectors. Runtime assertions taken from Dart
1450 the 3 types of run time assertions RTTS: java inheritance style, structural style & generics
1620 RTTS advantage: verify JSON datatypes  received from server
1720 declarative metadata exemplified for a directive
1805 encapsulate the directive as a class without breaking dependency injection system
1930 introspection at runtime exemplified
2222 how to add Expressive Code Needs (types, annotation, introspection) to Javascript?
   Use ABSTRACTIONS via TYPES & ASSERTIONS to declare the code INTENT
2500 Javascript history. EcmaScript ES3 try & catch enabled building large scale apps. ES4 classes & modules resulted in no adoption. Eg. ActionScript deadend. ES5 added strict mode to ES3. ES6 adds again classes & modules. Next ES could have annotations
2715 reference TRACEUR tool
2745 diagram of supersets containment: ES5-->ES6-->Typescript-->AtScript
2925 evolution of syntax
2950 how to add annotations today in ES5
3113 use ES6 class to add annotations. How to do it in Typescript, AtScript, Cofeescript.
      Same Angular 2.0 code base generated for 2 platforms: JS & DART
3320 AtScript IDE support promised by major Javascript IDE vendors already supporting Typescript
3400 add static types checking as in Typescript with the benefit of runtime check, proposal standard, then standardize.

Friday, October 24, 2014

Transcript notes on "Workflows of Refactoring" talk by Martin Fowler

Martin Fowler's first part of the talk @OOP2014 "Software Development in the 21st Century" was on "Workflows of Refactoring"

His main idea is that developers are not using software refactoring in all applicable situations. In this talk he identifies what are the different situations when refactoring makes sense.

Below are my time stamped notes of the video in the "@mmss" (@MinutesSeconds) format (time stamps are approximate):
@0110. People are not using refactoring in all applicable situations. What are diff situations when refactoring makes sense

@0205 FIRST refactoring type: TDD refactoring. The most common refactoring scenario is in the red green cycle of TDD. Quickly write working code, then refactor it.
@0350 the need for 2 steps: write / refactor explained with the Kent Beck metaphor of programmer's 2 hats: add new functionality  vs. preserve it but improve code
@0522 other "hats" the developer might wear: performance refactoring and exploratory refactoring

@0730 SECOND refactoring type: Litter pickup refactoring. Fix in small steps the messy code you come by (the Boy Scouts rule). Fight the software design entropy.

@1030 THIRD refactoring type: Comprehension refactoring. Rewrite hard to understand code making it easier
@1300 Question: when find fixable stuff...should I fix it now and how to go about it?

@1445 FORTH refactoring type: Preparatory refactoring. When feel the need to change how code was done in order to add new feature. Good upfront design can avoid this BUT it is hard to do.

@1750 FIFTH refactoring type: Planned refactoring. When refactoring is part of project plan. Good team should NOT have this SINCE if work is broken in small pieces then ongoing refactoring can be done while new features are added

@1930 SIXTH refactoring type: Long term refactoring, WHEN BIGGER issues pop up while getting more into project. Weird dependencies are identified. Fix it in small steps with each iteration

@2210 WHY REFACTOR? Because of ECONOMICS i.e.DESIGN STAMINA HYPOTHESIS. If you don't ongoing care about design then adding new features will be harder: THE CODE FIGHTS YOU.

Labels: , , ,

Monday, April 14, 2014

Draft notes on latest features of Typescript 1.0 presented at BUILD2014

Anders Hejlsberg announced Microsoft's latest version of Typescript open source language that addresses the maintenance issues with big Javascript projects by providing static types and optional typing of Javascript projects.

My time stamped draft notes, in the format MinutesSeconds (mmss) format, follows:

636 ref Google's Closure compiler that allows adding type annotations in comments
900 interface introduced, eg. Entity
1100 easy refactoring via VS2013 Update 2 ( or VS2012 Typescript power tool) of prop renaming due to local var name collision
1200 interface is structural typing, specifying  obj's properties: duck typing
1430 optional prop name ends with "?". But has type to be obeyed if prop is used
1500 can have methods in an interface
1640 javascript (JS) type system manifests at run time. Typescript reveals it at compilation.
2040 generics use in sorting example
2115 generics are used to flow types. "T extends Entity"
2345 callback use in generics array sort example
2450 lambda expression use not yet in Ecmascript 6
2610 Typescript is a preview of Ecmascript 6 compiled to code that can run on Ecmascript 3 browser
2740 ref type declaration file
2850 declaration file can be written for any Javascript framework. Gain the power of type checking and editor statement completion
2910 ref site repository of type declarations for hundreds of Javascript frameworks
3030 writing classes is same with future Ecmascript 6 classes
3400 example of Typescript class methods translation into Javascript
3425 private properties support has no JS equivalent but may be used to support future Ecmascript 6 symbols = properties with hidden names
3550 productive implicit definition of public properties via their declaration in constructor's signature
3610 support of Ecmascript 6 feature of default argument value, eg. "y: number = 0"
Used if constructor doesn't provide values. The generated Typescript code for the constructor assigns the default value if its type is undefined.
3646 inheritance
3730 generated JS code for inherited Typescript class
3750 prototype chain setup JS code by __extends() function is the only case when Typescript generates code not written by you
3830 internal modules. Typescript translates the module into a JS function closure like in JQuery. Acts like namespace.
4000 external modules similar with node.js or require.js
4040 Typescript can work on server too. Node.js module system aligns with common.js specs
4100 Typescript app example with 2 modules. First, make a ref to node's type declaration file to get advantage of its types in editor's statement completion
4345 server using node.js module, code example
4450 client module using the server module
4550 command line compilation on client file will produce server JS file too, due to client module dependency on server module. Module compilation flag used for common.js: "tsc hello.ts -m common.js"
4645 convert existing JS projects to Typescript. Example of Audio File Viewer Javascript project conversion
5215 advantages of Typescript type checker in spotting errors that were not covered by unit tests
5230 improving Javascript projects by adding types to existing code. Configure project build by not allowing any implicit types
5517 Typescript doesn't enforce to add types to everything. Optional typing.
5650 main advantage of Typescript is to enable tooling
5730 the Typescript ecosystem
5830 the advantage of Typescript definition files: community writes the metadata of programs on the web
5848 Typescript tools
5915 Typescript roadmap

Labels: , , , ,

Tuesday, April 08, 2014

Object-oriented design decisions should consider code testability.

How easy can we test the code and how easy can we troubleshoot it if something goes wrong. The answers to these questions depend on how the code was designed.

A good test should be able to easily test any portion of the application.

Misko Hevery has great tips on how to design code for this purpose in his 2008 talk Don't Look for Things!:

- Class constructors should be simple, reduced eventually to only assignments.
- The use of Service Locator should be avoided (see minute 8:45).
- Dependency Injection (DI) is the solution to Law of Demeter (minute 19:14)
- Rules for object factories use (minute 22:00)
- Why NULL testing paranoia is bad for testing (minute 23:57)
- use of Google's Guice framework to build auto dependencies via reflection (minute 32:40)

Labels: , , ,

Thursday, March 27, 2014

Riding the waves of innovation possibilities

The Chilean take on how innovations emerge, Surfing Toward the Future, creates waves few months later

Other reactions:

Labels: ,

Wednesday, January 29, 2014

Agile Software Architecture book (chapter 15) review notes

My abbreviated contents of book's contents:
Foreword by John Grundy
  Architecture vs Agile: competition or cooperation?
Foreword by Rick Kazman
Chapter 1: Making architecture and agile approaches work together
Part 1: Fundamentals of Agile Architecting
  Ch 2: DCI Paradigm: taking OO into Architecture world
  Ch 3: Refactoring Software Architectures
  Ch 4: Persona as a driver in architectural design and preservation
  Ch 5: Architecture decisions: Who, How & When
Part 2: Managing Software Architecture in Agile Projects
  Ch 6: Adaptable architectures via agility to support variability
  Ch 7: Continuous software architecture analysis
  Ch 8: Lightweight Architecture Knowledge Management for Agile
  Ch 9: Tailored Scrum for Agile Architecting by bridging user stories with architecture
Part 3: Agile Architecting in Specific Domains
  Ch 10: Security testing by architecture-centric approach
  Ch 11: Multitenant, multitarget architecture supporting agile development & deployment in the cloud
Part 4: Industrial Viewpoints on Agile Architecting
  Ch 12: Agile Architecting: enabling delivery of complex agile systems
  Ch 13: Architecture and Agile = key innovation enablers 
  Ch 14: Emergent Architecture's opportunities, threats and limitations
  Ch 15: Agile Success driven by architecture: Aviva UK case study.
Extensive Author & Subject indexes

Chapter 15 review: This chapter brilliantly details the challenges and architectural-centric solutions for the transition to agile from a waterfall process in a big insurance organization, Aviva UK. The transition was caused by the rapid change (and on-going quality) demands under the restriction of not increasing risk & cost. 

First part of the chapter lists the Challenges to agile adoption at Aviva UK, i.e. architectural / organizational characteristics (result of Conway's Law) and derived waterfall specific business practices (scheduled release processes, silo mentality, restricted integration testing, etc.).

Facing these, few lessons were learned: agile practices specific to small teams pose hurdles when adopted by big teams, requiring changes to pure Scrum practice; agile adoption by big businesses is achieved by focusing on impact and requirements of IT architecture ("in-sprint" design is not sufficient to guarantee success).

Next, the key architectural strategies for agile adoption success in big organizations are detailed and exemplified:
1. sufficient up-front architecture and design. An example is given where incrementally in-sprint design failed due to domain complexity and having too much uncertainty unresolved before starting the sprints.
2. what is "sufficient" up-front architecture / design and how uncertainties impact them.
3. the key points for continuing architecture and design during sprints (exemplified with Aviva UK agile development scenarios). 
4. the layered architecture as enabler for independent change agility. Inspired from the buildings pace layering architectural pattern the layered architecture allows independent and different rate of change across loose coupled system software tiers.

The chapter ends with a testimony towards the benefits of incremental agile and architecture transformation of the business and IT. Aviva UK learned by experimentation a valuable lesson in gradually changing existing architecture towards a loosely coupled service-oriented tiers that accommodate easy system evolution. Paraphrasing authors lesson: it is permissible to change things later as long as the design facilitates these changes.

I review for the O'Reilly Reader Review Program

Labels: , , , , ,