とあるIT屋の独白

ITや経営について主に書きます

Qiitaの買収について思いをめぐらす

昨年の12月にIT技術の共有サービスのQiitaを買収するという、ニュースが出ました。

 

【「Qiita」運営会社、スマホゲームのエイチームが買収】

http://www.itmedia.co.jp/business/articles/1712/22/news108.html

 

プログラム関連で何か調べものをするときは個人的にもQiitaはかなり重宝していて、私もささいな内容ですが時々投稿したりしています。また、チームで情報を共有する用途のQiita:Teamも導入している会社はちょこちょこあるかな、というイメージです。

事業という観点だと、上記の記事にかいてある通りIncrementsの昨年度の売上高は約9000万円、最終損益は8000万円の赤字と、まだまだスタートアップの段階なのかなと感じます。その為、Qiitaが今後サービス改善するにあたってエイチームの財務的な後ろ盾があるのは大きいのかなと思います。

 

【Qiitaを運営するIncrementsのエイチームグループ入りについて】

https://medium.com/@yaotti/qiita%E3%82%92%E9%81%8B%E5%96%B6%E3%81%99%E3%82%8Bincrements%E3%81%AE%E3%82%A8%E3%82%A4%E3%83%81%E3%83%BC%E3%83%A0%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97%E5%85%A5%E3%82%8A%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6-715a2294208c

今さらながらNginxについて調べてみた

最近はWebのシステムを構築する際は、Nginxを使うことがずいぶん増えました。一昔前はApacheがほぼ独壇場だったイメージで、自分もOSSのWebサーバというとApacheしか使ったことがないので、今さらながら少し調べてみました。

Apacheとの違いは下記の記事の通り、設計思想。ApacheではWebサーバに様々な盛り込んでいますが、Nginxは最低限のものしかのせていない、というイメージです。そのおかげで、Apacheより多くの同時アクセスをさばくことができます。

 

【Nginxとは?Apacheとの違いについてエンジニアに聞いてみた】

https://academy.gmocloud.com/qa/20160616/2761

 

最低限の機能しかないのに、サーバーサイドプログラムはどう動かすかというと、CGIを使用してプログラムを呼び出すイメージです。ApacheだとWebサーバ自体にモジュールをインストールすることが多いので、ここら辺は異なる部分となります。下記の記事に詳しく解説しています。

 

【nginx と PHP-FPM の仕組みをちゃんと理解しながら PHP の実行環境を構築する】

https://qiita.com/kotarella1110/items/634f6fafeb33ae0f51dc

 

夫婦別姓と戸籍について考えてみる

少し前に、旧姓に法的根拠を与えるようサイボウズの青野社長が裁判所へ提訴しました。今日は少し趣向を変えて、この件について取り上げてみます。

 

夫婦別姓問題で国を提訴するサイボウズ社長の「痛快」な主張】

http://diamond.jp/articles/-/153253?display=b

 

私の会社でも旧姓で働いている方もいらっしゃいますし、結婚後に名字を変える方もいます。どちらの方法を選ぶにしろ手続き等が面倒だし、そもそも姓を変えなければいけないのは何故か、非効率だ、と言いたい気持ちは普通に理解できます。ただ、だからといって夫婦別姓を選べるということが対応として本当に正しいのか、という点はもう少し検討の余地があるのではということで、そもそも現状の戸籍管理というところから考えてみたいと思います。ちなみに、私は右翼でも左翼でもなく少年野球をやってた時は補欠でした。

まず、戸籍とはそもそも何かざっくりいうと自分の出自情報を管理する仕組みとなります。生まれたときは基本的には子供は親の戸籍に入り、結婚した時には親の戸籍から抜けて新しく夫婦の戸籍ができ、その際に姓を夫婦どちらかのものを選択しその履歴が自分の出自として残るわけです。

 

【公務員から聞いた戸籍早分かり術】

http://www5f.biglobe.ne.jp/~milty/koseki/koseki.html

 

ちなみに、外国籍の人と結婚した場合は夫婦別姓は許可されるのは何故かという指摘がありますが、そもそも外国籍の人は日本の戸籍法では対象外だからなのです。なので、結婚して戸籍ができる時はその戸籍は自分のみとなり名字を変える必要がそもそもないということになります。(手続きで変更することもできますが)

 

【国際結婚後の戸籍と苗字(名字)について知るべき4つの事】

http://visa-immigration.net/info/international-marriage-surname

 

そして、ではなぜ結婚したら姓を同一にしなければいけないのかというと、現在の戸籍の考え方では戸籍の単位は核家族単位となっていて、これを識別するものとして姓が用いられている為です。詳しくは下記のサイトに書かれていますが、このような管理の仕方は明治時代に始まっていて、当時としては、合理的な管理の仕方であったのかなと考えられます。

 

【ちょっと待った!夫婦別姓

http://syphon.bonyari.jp/index.html

 

では、なぜ核家族単位で管理するのかというと上記のサイトにも言及がありますが、それは生まれてくる子供の出自の管理と育児の責任の明確化の為という目的もあります。この、子供が属する戸籍については下記のサイトにも解説があり、例えば離婚した時に子供の戸籍を移す場合にどうすればよいかというと、姓(氏)の変更とセットで管理されています。

 

【離婚すると戸籍はどうなりますか?】

http://www.souzoku-sp.jp/m/koseki/detail/index3.html

 

長々と現行の戸籍制度について書きましたが、この戸籍の管理の仕方と姓はセットで考えなければいけないものと考えます。戸籍管理の仕方が現在の社会状況に合ってなく、管理の仕組み自体を変える中で姓の役割も変える、という議論であれば全然歓迎すべきことではあると思いますが、夫婦別姓という局所的なところだけ取り上げられ、制度を変更すべきだというのは、やはり少し違うのかなと感じます。

Elasticsearchについて調べてみた

全文検索のエンジンとして最近採用されることが、ちらほら見かけられるようになったElasticsearch、さわり程度ですが少し調べてみました。

まず、Elasticsearchの概要ですが、基本的には検索対象の文章を登録した上で、全文検索を行います。下記の記事にある通り、RDBMSとの違いは一致検索ではなく関連度が高いものを返すという点です。

 

【第8回 Elasticsearchの基礎を学ぶ】

http://gihyo.jp/dev/serial/01/js-foundation/0008

 

セットアップや使用方法の詳細は、下記のリンク集にある記事を見ていけばイメージをつかめるかと思います。インデックスの考え方とかは、全文検索エンジンならではのものですね。

 

オープンソース検索エンジン/Elasticsearchとは】

https://www.ossnews.jp/oss_info/Elasticsearch

 

実際の活用方法のサンプルは下記のサイトにあります。Twitterからつぶやきを集計して表示するものとなります。

 

【楽しい可視化:elasticsearchとSpark Streamingの出会い】

http://www.intellilink.co.jp/article/column/bigdata-kk02.html

シャープの復活について考えてみる

昨年、12月にシャープが東証1部に復帰しました。以前にも本ブログでシャープについて取り上げましたが、

http://toaruit.hatenablog.com/entry/2016/06/20/164714

降格してから、わずか1年での復帰はさすがといったところでしょうか。下記の記事によると過去10年で2部から1部に復帰した企業はほぼなく、社長の手腕が優れていたのか、よほど前の経営が杜撰だったかどちらなのでしょうかね。

 

【シャープ戴正呉社長が、東証一部復帰に際して語ったこと】

http://ascii.jp/elem/000/001/602/1602459/

 

載社長が再建に当たり、まずやったことは徹底したコストカットです。自らも贅沢しない姿勢を見せて、社員の意識を変えていきました。その一方で親会社である鴻海への売上も、業績に寄与しているかなと。

 

【赤い帽子、カツラ、社員寮暮らし……再上場のシャープ・戴社長がいろいろすごい】

http://bunshun.jp/articles/-/5393

 

下記の記事でも、今回の業績回復について、コスト削減や鴻海グループないでの損失移転が要因の主なところと書いてあります。今後より斬新な製品が出ることを期待したいですね。

 

イノベーションなきシャープの〝復活〟】

http://wedge.ismedia.jp/articles/-/10482?layout=b

クラスタリングとシャーディグ

データベースの機能で、私的に混同してしまうのが、クラスタリングとシャーディングです。自分への備忘も含めて、今回は少し整理したいと思います。

まずはクラスタリングで、下記の記事に概要があります。

 

【データベース・クラスタの概要】

https://thinkit.co.jp/story/2010/10/05/1784

 

クラスタリングの目的としては、可用性と負荷分散による並列処理(結果的に性能向上)を実現するためと、主なところは感じています。クラスタリングの機能として代表的なものとしてOracleRACが挙げられます。OracleRACではキャッシュフュージョンという仕組みで、クラスタを実現しています。

 

【ゼロから理解する「Oracle RAC」】

http://www.atmarkit.co.jp/ait/spv/0904/13/news115.html

 

片やシャーディングではデータの分散を行う機能であり、各サーバでは定められたレンジのデータが格納されます。下記のMongoDBの例が、イメージとして分かりやすいかと。

 

【第5回 MongoDBのシャーディングを試してみよう】

http://gihyo.jp/dev/serial/01/mongodb/0005

 

Oracleでも12cR2から、シャーディングの機能が追加されました。Oracleならではの機能もあるようですね。

 

【12c R2ではじめるOracle Databaseのシャーディング】

https://enterprisezine.jp/dbonline/detail/9031

単体テストやデプロイの自動化

単体テストやデプロイに関して、Jenkinsなどのツールを使用して自動化している例はかなりあると思います。Jenkinsについては下記の記事で、解説されています。

 

【Jenkinsとは】

http://cloudbees.techmatrix.jp/jenkins%E3%81%A8%E3%81%AF/

 

Selenium WebDriverというツールを使えば、画面周りも単体テストのコードで記述可能です。

 

Selenium WebDriverでWebアプリのテストが変わる】

http://www.atmarkit.co.jp/ait/series/883/spv/

 

ツール類はそろっているといっても、いざ現場に導入しようとすると場合によってはハードルが高かったりします。自動化によってどのようなメリットが得られるか、という観点での説明や浸透をさせないと、仕組みは作ったはいいけど使われない、ということにもなりかねないです。

 

【ビルドやテスト環境の自動化は、顧客の一声でつぶされてしまった~自動化の現場の真実(前編)。システムテスト自動化カンファレンス 2015】

http://www.publickey1.jp/blog/16/_2015.html