私は毎年 6 月 2 週目をとても楽しみにしています。
その時期に何があるのかというと、 Interop Tokyo というイベントが毎年幕張メッセで開催されています。

このイベントでは、最新ネットワーク機器の展示やネットワーク技術動向についてのプレゼンテーションなどが行われており、また、普段の生活ではまず目にする機会がないようなハイスペック機器とご対面することができます。

特に、会場のネットワーク環境を提供している ShowNet には毎年楽しませていただいています。
ShowNet は、主にはイベント名の通りに機器間の相互接続性の検証を行うためのものですが、毎年異なるテーマに沿った工夫がたくさん盛り込まれています。

ちなみに今年の Web サイトには NOC メンバーや出展社などの方々が記事を書くネットワークのゲンバなるページがあるので、興味のある方は是非記事を読んでみてください。そして会場に足を運びましょう !

担当：阿部 (さて、今年は宿泊どうするか)

There are basically two types of people who are creating software: Hackers and Software Engineers. While hackers are eager to create something new diving into the system and push the borders, Software Engineers are of the more conservative type carefully laying out a plan for whatever it is they want to create. My favourite definition of what Software Engineering is reads as follows: “The application of a disciplined and systematical approach for developing, operating and maintaining software.”. And that’s exactly what sets the software engineer apart from the hacker.

The term Software Engineering was coined  at the first NATO Software Engineering Conference of 1968 in Garmisch, Germany. Due to a time of projects increasingly running over-budget, running over-time and even completely failing a solution had to be found for what was called the “software crisis”.

This software crisis was mainly possible due to the lack of standards, good techniques (such as Object-oriented encapsulation, structured programming), best practices such as design patterns. Even tools that are thought of being very common such as IDEs, bug tracking systems or version control systems were absent at that time.

The NATO discussed “The Software Crisis” in 1967 were Prof Dr Friedrich L Bauer suggested the term “Software Engineering” as a way to conceive of both the problem and the solution, basically marking the beginning of Software Engineering. Since Software Engineering has been established, the amount of failed projects has decreased massively where it is applied correctly.

寒い春から転じて急に暖かくなりました今日このごろ、皆様、如何お過ごしでしょうか。

昨今、情報化社会 (死語?) の恩恵か、よくインターネット上のSNS等にて色々な業務システムや行政システムのあり方が語られる事が当たり前な時代となりました。本来、システムの内容であればオープンな場所で語れる内容ではありません。しかし既にサービスインしているシステムの種類ごとの基本の設計思想であったり、そのサービスが世間的にどう役割を果たすべきかの議論は、意見を磨く場であったり、同時に世間に啓蒙を図ることもできる場ともなり、正しく議論が進めばこういう場も貴重です。

世間のそんな議論の中でしばしば目にするのが「建設的」もしくはそれに類する言葉。一般的には否定に入る場合には必ず代案をセットで話し、議論を円滑進める的な理由で使われるのが主かと思います。また副次効果の「やる気を削がない」等で利用されているものと思います。この言葉は企画の初期段階のアイディア出しでよく使われる言葉ですが、こうしたシステムや設計背景の欠陥部分や考えられる問題点に対しての否定的な意見や指摘、再考を提案した場合にも目にします。しかし、この言葉は既に物事を削るフェーズに入っている場合であったり、検証不足の指摘があった場合で使うものではありません。そんな状況下で指摘を行った者に対して、この言葉のみにて回答をした場合

・指摘の問題箇所を無かったことにも出来かねない、論点の無視 (防)
・否定者に対して、すべての解決法の要求も可能な2段の構え (攻)
・以降は話を聞かない姿勢の表明 (逃)

となり、実質、無敵に近い論法を成立することが可能です。この時点で、ある種の人間の「やる気」は間違いなく削がれる事でしょう。(類似語句：イノベーションの阻害)

私見ではありますが、ソフトウェアでもサービスでもどの様な種類であれ、何かしら物を作ることは彫刻や模型等の工芸に近いものと考えています。まずはアイディアだしから楽観的な土台 (構想) を作り、そこから設計や検証や考察を重ねた「削り」で整形をしていくものではないでしょうか。どうにも世間的この「削る作業」を「建設的」という言葉を建前に嫌う風潮があるように思えます。指摘と問題の部分を認めて素直に受け止めるほうがよほどポジティブであり円滑に進むものなのに、と思うのですがなかなか難しいもので。また、受けた指摘のに誤りがあるのであれば、説明をして、否定の否定をするのも良いでしょう。

とりあえず、使い時を間違えていませんか？「建設的」という言葉を。安心していませんか？「建設的」という言葉を使って。と、昨今のインターネット上の議論を見て思うのでした。今回の内容は「建設的」という言葉の部分的な否定内容ですので、「否定も一つの意見であり認めて対策考えましょうよ」というのが出来る限りの対案。もう少し世間的に「否定的に見えるがポジティブな意見」が認知されればな、と、思う、次第でして、謹言。

担当: ｶﾛ藤 (-1)

Why?

With git it is really easy to manage project code and track all file changes. However, when it comes to collaboration, i.e. development of certain application together with a group of people,
it is much more preferable to store code in a centralized way. I really like how Github is organized and how convenient it is.
Unfortunately, in order to have locally hosted Github environment one has to have quite big development team and stable source of revenue ( because price is not so cheap ).
That’s where another project Gitlab can be a lifesaver.

In past I’ve checked project several times, but it was in it’s early state of development and it was also very difficult to set it up at the moment. However, not so long ago all this changed.
For some people it would be a bit challenging, but installing Gitlab ( on a clean system at least ) became much-much easier.

How it looks and what it offers one can check here: demo.gitlab.com

Gitlab supports Ubuntu Linux and Debian GNU/Linux, thus I wanted to try installing it on FreeBSD system ( FreeBSD 8.3-RELEASE amd64 ).

Generally, instructions provided quite clear. Of course
not all steps can be applied to FreeBSD, thus I’ve made necessary changes:
• apt-get steps was replaced by corresponding equivalent of -> cd /usr/ports/%some_path_to_package% && sudo make config-recursive install clean
• when creating user, instead of –disabled-login parameter use extra command after creating git user -> sudo pw mod user git -w no
• to manage ruby and gems I’ve installed rvm multi-user (more about rvm)

I was unable to find any Gitlab init scripts for FreeBSD, I decided to write my own one. Gitlab also has tests to check whether everything was properly installed.
I found that they check mainly for the Linux environment (it is supported ), hence they always will fail on the FreeBSD system.

For those who are interested in installing Gitlab on FreeBSD, I have shared adjustments I’ve written on a Github

Gitlab init script for FreeBSD
Patches for rake tests

As usual, use them at your own risk and please let me know if you find bugs:)

会津はここのところ一気に暖かくなってきてだいぶ過ごしやすくなってきた…とおもいきや、今度は暖かくなりすぎて過ごしにくいです。なかなか都合良くはいかないものですね。

さて、先日Ruby 2.0.0-p195がリリースされましたが、いい機会だったので今まで使っていたrvmから最近主流らしいrbenvに乗り換えました。

2年弱くらい使ってた環境を捨てるのはちょっともったいない感じもしますが、rvmはあまりお行儀の良くないことをしていたりして気になっていたので、思い立ったが吉日ということでちゃちゃっと乗り換えました。rvmのほうが高機能らしいのですが、正直なところバージョンの切り替え程度にしか使っていなかったのでまったく困ることなく移行できてスッキリしました。

ただひとつ問題がありまして、僕は~/.*を各環境で同期するためにgitを使っていて、pluginやらスクリプトのたぐいはsubmoduleに突っ込む、という形態で管理しているのですが、rbenvをsubmoduleにして、 さらにruby-build等をsubmoduleにすること(submoduleの入れ子)ができないのでどうしようかなと悩んでいます。そもそもそういう用途に使うものではないらしいのでしょうがないのですが。

ということでsubmoduleに何でもかんでも突っ込むのはやめて適当にリポジトリからひぱってくるスクリプトを書こうかなと思っています。なかなか満足の行く環境ができなくて大変です…

担当:羽生（便利な環境を作るのが好きです。）