This photo is "Matsue Open Source Lab." in front of Matsue station.
I attended these sessions:
There are a good session and a bad session. At first, "Panel Discussion: How to Promote the International Standardization of Ruby" was the worst panel discussion I have ever heard. Because IT WAS NOT DISCUSSUION AT ALL. Other panels speaked ad, damned ad and statistic ad. Matz speaked just only that (and Q&A). Charles Nutter tweeted like this, well, panels are normally discussing on the other panel discussions in Japan.N.B. These summaries may be imprecise.
- For the standardization of Ruby
- speaker: Katsuhiko Kakehi
- Ruby is the language raised by the community.
- Many usages
- Many implementations
- Many suggestions
- When community grows up...
- Need of reusability and portability
- Need of standarization
- In general, the standardization of programming languages has been worked in ISO/IEC JTC 1/SC 22.
- WG4 - COBOL
- WG5 - Fortran
- WG9 - Ada
- WG11 - Binding Techniques
- WG14 - C
- WG16 - ISLisp
- WG17 - Prolog
- WG19 - Formal Specification Languages
- WG21 - C++
- At past, Java also had been studied for ISO/IEC JTC 1, but faded away.
- ECMAScript and C# are standardized by ECMA, and then ISO/IEC JTC 1 ratifies it.
- How do we standardize Ruby?
- It's impossible that we aim international standards in a single leap.
- At first, we aim JIS standards.
- until 2010
- core language set
- minimum libraries
- And then JIS will suggest to ISO/IEC JTC 1.
- What is needed for the standardization?
- Clarifying language specifications
- To follow all implementations
- To decide in each implementations
- No to decide as specifications
- Functions already exists (not implementation methodology)
- periodic revision and maintenance for standards
- The former supervisor of SC22 in Japan is me.
- Current chief officer of Ruby standardization is the former of me.
- Significance of standardizing Ruby
- speaker: Matz
- Features of OSS in this theme
- Source codes are opened
- Community Development
- Community has many contributors and, in general, they are voluntary.
- Developers contirbute as hobby.
- Recently, developers as business have increased.
- Features of Community Development
- No roadmaps
- e.g. Next release will be in Christmas day, in any year :-)
- No promises
- e.g. Bugs may be fixed when someone will fix them.
- But it remains wrong with no roadmaps and no promises because Ruby has been used in some enterprise domain recently.
- We should address concerns.
- support by corporate
- support for education
- publication
- Programming languages have very long lifecycles.
- Fortran: from 1954
- LISP: from 1958
- COBOL: from 1959
- Normal software has normal lifecycle.
- shorter than programming languages'
- longer than we expect
- Inconsistency in programming languages
- It's hopeful that programming language never changes because of compatibility and stability.
- It's hopeful that programming language ever changes because of enchantment as a language development.
- take a balance
- Stability
- brush up
- compatibility
- support for each implementations
- Possibility of development
- possibility toward the future
- correspondence for changing circumstances
- correspondence for new technologies
- cooperation
- not to alienate the community
- Now I'm still exploring how do we do when standardizing Ruby.
- Panel Discussion: How to Promote the International Standardization of Ruby
- panel: Yoshihiko Hara
- panel: Masaya Mori
- panel: Shunichi Kajisa
- panel: Takashi Shitamichi
- panel: Katsuhiko Kakehi
- panel: Matz
- moderator: Shuichi Tashiro
- At last matz says:
- Human resources for standardization are not enough, so I want to watch us in the long.
- We aim standardization level not only as "Hello World" but also as Ruby implementation codes of Ruby on Rails.
Q from attendee How many are you communicating with the RubySpec team? A from panel No communications currently. When we will standardize as accomplishable level, then we will communicate each. - Effective Teams
- speaker: Bruce A. Tate
- Build great software
with small teams
of happy programmers
- What is the "Great"?
- Generally, we have to choose the two in [better, faster, cheaper]
- Java or C++ optimizes the computer.
- But we want to optimize ourselves, and then optimize our times because time is expensive.
- Beauty is the worthy goal.
- It's characteristic only for Ruby that values like "love", "enjoy" are important.
- I'm asked several times How smaller can I make my team?
- I answer "volleyball team".
- nine-person, at most
- six-person, normally
- in beach-volley, only 2
- Why a small team is good?
- Imagine a best developer and a worst developer in your neighbor
- How many difference does their salary have?
- In U.S., it has about 2 times on average.
- How many difference does their productivity have?
- 5 times? 10 times? The worst developer may bring negative results.
- So it's better that you spend moneys for best developers.
- And there are no difference that you make the team bigger.
- Leverage Point
- Language
- Death to meeting
- Pair all the time
- Test everything
- Programmer in happiness = Passionate
- Passion killers
- Ugly Foundations
- DCE
- CORBA
- OpenDoc
- EJB1, EJB2, EJB3
- JSP
- Generics
- Turnover
- Blame
- Fulfilling the accountability is necessary.
- But it isn't good to accuse than necessary.
- Overtime
- Working long hours never make release time earlier.
- Passion builders
- Learning
- Language
- Trust
- Panel Discussion: The Future of Human Resource Development for Ruby
- panel: Ikuo Takeuchi
- panel: Yasushi Kuno
- panel: Eihiro Saishu
- panel: Motoshi Hara
- moderator: Tetsuo Noda
- The young ages are the who should make innovations.
- The senior ages are the who should support the young ages.
- Missing things in Japan are ICT literacies of the senior ages.
- ICT vocabulary at Japanese is incomplete.
- Each administrative organizations are not unified on ICT.
- The Japanese investors also have no ICT literacies.
- The Japanese society is not adoptable for ICT literacies.
- The better goal is to bring up not only creators' level but also citizen's level.
- The time is over that creating good things makes good sales.
- I think it's different between the human resource to create and the one to use the creations.
- "Kosen" college and Programming contest in Japan
- Exploratory IT Human Resources Project (The MITOH Program) acts as an extension of Programming contest.
- Exploratory IT Human Resources Project (The MITOH Program) acts as a golden path of training.
- The students with great ideas are from outside of information science in sometimes.
- ICT is just only basic literacy, so there's no need for establishing course of ICT studies.
- I think Recently, too much teaching makes the person who always waits instruction forever. It's not for business.
- ICT campany that adopts Man-Month model is bad.
But second, Bruce A. Tate' session is the best, this session doesn't become filled strangely. Moreover, its Q & A is the hottest. So I omit the Q & A part because these are an experience for who took in this conference.
No comments:
Post a Comment