プログラミング言語とは?

こんにちは。開発担当のマットです。

以前も言ったことがありますが、開発はとても楽しい仕事です。
何らかのアイディアを分解してパソコンに文字を書けば、面白いものを作ることができます。

では、その文字とは何でしょう?

その前に、機械語を・・・

パソコンの中心にはCPU(中央処理装置)が存在します。
このCPUはとても忠実で、ユーザやアプリケーションからの命令を受けてその命令に従います。

つまり、何かのアプリケーションを作りたい場合、プログラマーはCPUへの命令をCPUが理解できる言語で書く必要があります。

いや、ちょっとまって・・・

CPUが理解できる言語のことを「機械語」と言います。
機械語はバイナリです。(つまり、0と1の列)

01100011 01101111 01100100 01100101


CPUの構成バージョンによって、コードの書き方は異なります。
人間が機械語を直接書くことはどう考えても不可能です。

CPUにわかってもらうことってなかなか大変です。

では、どうしたらいい?

人間は0と1を直書きすることはできませんが、英語のような文章は書くことができます。

例えば、

answer = 1+1;

とか、

name = "山田太郎";

なら、人間は理解できます。

ならば、こういう文章を、機械語(010010…)に翻訳できるものがあればいいのです!
そしてその翻訳できるものは存在します。コードの解釈・翻訳機をしてくれるものを「コンパイラ」と言います。

コンパイラの種類は多くてコンパイラによって、翻訳対象となる「人間が書くコードの書き方」が異なり、それぞれの書き方を「言語」と言います。

言語の特徴

それぞれの言語には特徴があり、使われる場面は異なります。
例えば、iOSアプリの場合、SwiftやObjective-Cを使わなければなりません。
3Dゲームの場合、C#やJavaが人気です。
ウェブサイトならPHPやRubyを使うことが多いです。

いくつかの言語と使われる場面と特徴をピックアップして紹介したいと思います。なお、各言語で、「Hello World!」というメッセージを画面に出力する例も挙げたいと思います。

JavaScript

JavaScriptはちょっと特別な言語です。
一番使われる場面はウェブサイトのブラウザーです。
ChromeやFirefoxはこのJavascriptを解釈して、ブラウザで実行します。

つまり、メモ帳でコードを書いて、ブラウザで開くだけでプログラムを書くことができるのでとても簡単です。
その反面、ブラウザによって、動作が異なるデメリットもあり、ブラウザに解釈される前のコードは丸見えので、JavaScriptで面白いものを作っても、パクられちゃうことも考えられます。

console.log("Hello World!");

実は、ブラウザ側だけではなく、2009年にnode.jsというフレームワークも開発され、ウェブサイトのサーバー側でも使えるようになりました。

Python

Pythonは多くの開発者に愛されている言語です。
理由としては、書き方が簡単で読みやすいのが特徴だからです。しかも、多くの場面で使えます。

ここ数年ではディープラーニングのアプリケーションにもよく使われており、これからもずっと愛されるでしょう。

print("Hello World!")

C

Cはとても代表的な言語です。

1973年に発明されて、現在使われているほとんどの言語に大きな影響を及ぼしました。
あまりにも影響を及ぼしたため、C++、C#、Perl、PHP、Swift、Javaなど、50種類以上の言語が「C系言語」と呼ばれています。

現在、直接C言語で作られているプログラムは少なくなってきていますが、Cに極めて近いC++(シー・プラス・プラス)やC#(シー・シャープ)はまだ多くの開発者が利用しているかと思います。

#include 
int main()
{
   printf("Hello World!");
   return 0;
}

かなり古い言語のため、「Hello World」を出力させるだけで、入力・出力を対応するstdio.hライブラリーを明示的にロードしなければなりません。現代の言語のほとんどは、こういうことを勝手にやってくれます。

Java

Javaは良い言語だと思いますが、一番の特徴は、別にダウンロードできる Java Run Environment というものです。 コンパイラーは人間のコードを機械語に翻訳するものですが、Windowsにしかコンパイルできないコンパイラーを使っていると、折角書いたプログラムをMacやLinuxで実行できません。

しかし、Javaでコンパイルしたコードは、直接OSではなく、上記のJava Run Environmentに実行されます。そして、そのJava Run EnvironmentのWindows版、Mac版、Linux版も存在しますので、Javaで一度プログラムを書くだけで、多くの環境で利用できることが一番の特徴だと思います。 実は、AndroidアプリもJavaで書くことができます。

class HelloWorld {
  static public void main(String args[]) {
    System.out.println("Hello World!");
  }
}

ちなみに、JavaとJavaScriptの名前は似ていますが、一切関係がありません。

PHP

世界のウェブサイトの約8割はPHPで書かれています。

PHPは初心者にも極めて優しい言語で、ウェブ開発者の慣れのHTMLの中に混じったりすることもできますし、他の言語だったらエラーになるという間違えたコードを書いても、PHPは動き続けます。

PHPはもともと、Rasmus Lerdorfn氏が自分のホームページに作ったものです(PHP = Personal Home Pageの略)。こんなに普及されるものと思われていなかったので、他の言語に比べて、PHPのファンクション(機能)名にルールがなく、ちょっと雑な言語と思われがちです。

しかしとても便利なため、これからもずっと多くの開発者に利用されるでしょう。

echo "Hello World!";

SQL

SQLはデータベースの言語です。

多くのウェブサイトでは、自分の名前やプロフィールを入力できる機能があります。
その情報をデータベースに保存することは一般の手段です。

データベースの構成はExcelのスプレッドシートのようなものです。
カラム名があり、データを一行一行保存していくイメージです。
そのデータを挿入、削除、または検索するのはSQLの役割です。

「Hello World!」を出力することができませんが、「山田太郎」さんを検索できます。

SELECT * FROM users WHERE name = '山田太郎';

Ruby

Rubyは日本で発明された言語です。用途が幅広くて、Rubyで色々開発できます。

当初は日本でしかあまり使われていなかったですが、2004年発のRuby on Rails によって、ウェブサイト開発にも便利な言語になり、海外でも使われる様になりました。

これからもRubyは多くの開発者に愛されるでしょう。

puts "Hello World!"

Swift

iOSのアプリを開発したい場合、Objective-CまたSwiftで作らなければなりません。
Objective-Cは割と古くて少しわかりにくいですが、Swiftは新しくてわかりやすいと思います。

Swiftの一番の特徴はオプショナルの対応だと思います。
通常、データを操ろうとする時、そのデータが存在しないとエラーになってしまいます。他の言語では、わざわざ「もし存在する」という文を書かなければなりませんが、Swiftでは「?」の一文字だけでできますので、開発者にとってはとても楽です。

最近、Android開発に使えるようになったKotlin言語にもある特徴ですが、今後発明される言語に是非入って欲しい特徴です。

println("Hello World!")

まとめ

プログラミング言語は道具のようなものです。
仕事に対して、適切な道具を選ぶことが大事です。
そのため、どの開発者でも複数の言語を覚えざるを得ない場面がでてくるとは思います。

しかし、特徴がありながら、現代のプログラミング言語は共通点が多くて、一つ覚えれば、他の言語にもチャレンジできるかと思います。

今後、私はまだ触ったことがなく、聞いたこともない、言語で何かを作ることが出てくるでしょう。
それは私にとって、とても楽しみなことです。


大人こそ少女まんがを読もう

こんにちわ。
リエです。

前に好きな漫画についてのブログを書きましたが、
https://blog.splout.co.jp/9960/

最近自分の中で少女まんがブームが再来しています。
というのも、たまたま試し読みした少女まんがが面白くてつい全巻大人買いしてしまったのです。(初めてデジタル書籍に課金しました)

その少女まんがは「コレットは死ぬことにした」です。
どんな話かというと↓↓
—-
薬師コレットは毎日大忙し。 食事してるときも、寝てるときも、朝から夜までお構いなしで休む暇がない。逃げ場がない……。  疲れたコレットがとびこんだのは井戸の底!目が覚めるとそこは冥府…。 なんと冥王ハデス様の治療をするはめになって!? 癒しと恋心がつまった薬師コレットと冥王ハデス様の神話ロマンス☆ 
引用元:https://www.hanayume.com/sakuhin/?id=4
—-

こんなTHE・少女まんが!を読むのは3億年ぶりでしたが、もうね、恋するコレットさんはかわいいしハデス様は素敵すぎるメンズだし、最高なんです。
2人の恋路をずっと応援しています。幸せになってほしいなぁ。
ネタバレになるといけないので、好きなシーンの紹介はがまんします。。
今16巻まで出ているのですが、5巻からときめきシーンが大幅に増えるので、まだ読んでいない方はまずは5巻まで読むことを激しくおすすめします。
ぜったいハマるから\(^o^)/
ちなみ私は続きが気になりすぎて徹夜して16巻まで一気読みしました。(徹夜とか5億年ぶりやった)

日々過ごしていると心が疲れるときがありますが、純粋な少女まんがを読んでいるときは心が洗われていい意味で無になれるので、大人こそ少女まんがは必要なのかもしれないと思いました。

早く新刊でないかなぁ。(続きが読みたい)


自分と他人の認知特性について

こんにちは、デザイナーのはなです。

最近小さい鳥を飼い始めました。かわいいです。

認知特性テストをやった

https://overpass.dokkoisho.com/cognitive/

こちらの本田35式認知テストというものが少し前に流行っていたので、やってみました。

写真(カメラアイ)タイプ 写真のように二次元で思考するタイプ

三次元映像タイプ 空間や時間軸を使って三次元で考えるタイプ

言語映像タイプ 文字や文章を映像化してから思考するタイプ

言語抽象タイプ 文字や文章を図式化してから思考するタイプ

聴覚言語タイプ 文字や文章を耳から入れる音として情報処理するタイプ

聴覚&音タイプ 音色や音階といった音楽的イメージを脳に入力するタイプ


カメラアイと聴覚&音の間が断崖絶壁みたいになっている…

聴覚に関する項目の点数が著しく低い、つまり音声での情報効率がもうむちゃくちゃ悪いということになります。

そう考えると、電話しながらTwitterを見ると、友達との会話の内容がわからなくなることもこれが原因だと言えます。

私の場合、情報入力(視覚)と情報入力(聴覚)を戦わせると、視覚からの情報が必ず勝ってしまうということです。

自分が聴覚情報の処理が苦手であるということは昔から正直若干自覚があったため、授業などで板書少なめで喋りまくる先生の授業では聞くのを途中で諦めて、要点の単語のみメモし、あとから教科書や資料集やネットなどで調べて自分の目で見たものを情報として補完していたこともありました。

また、私の学生時代のノートは、落書きもイラスト図解もめちゃくちゃ多いため、絵だらけでした。

それはあんまり今も変わってないですね。(ミーティング中のメモが絵だらけな人)

他人の認知特性をふわっと推し量る

他の人になにかの情報を渡したり、好きなものをおすすめしたりするときに、相手の認知特性がなんとなくわかっていると何かと便利です。

例えばですが、私の友人の一人に、一緒に映画を見に行ったあと「あのシーンよかったよね〜」など感想を話すとき、必ず「あのセリフの表現が…」と、文章としての表現について話す人がいます。

私が映画の感想を話すときは、印象的なシーンの構図や、光の当たり方などについて思い返すことが多いので、おそらく私と認知特性が違うんだろうな、と解るわけです。

なので理解してほしい事があるときは、文章で説明してくれているサイトを探してきたり、少し長文になったとしても文章で説明するように心がけています。

何かの記憶について話したり、何かを説明してもらったりしたときに、その人の得意な情報処理方法が滲んで出ていると感じることが多いです。

もちろん全然わからないときも同じぐらい多いので、その時は相手の顔色を見つつ、わかってなさそうなら説明方法を変え、色々試して結果的に同じことを3,4回繰り返して説明するようにしています。

また、なんとなく推し量った相手の認知特性は、絶対そうだ!ではなく、あくまでもなんとなく、もしかしたらそうかもな〜ぐらいの認識でいることが一番大切です。

まとめ

優位特性についてテストしてみて思ったことは、自分のパラメータで突出している部分や陥没している部分があるように、他人にだってそういう部分があるんだろうなということです。

私の聴覚&音が1点であるように、視覚が1点の人だってもちろんいるわけです。

私が、音声だけでばーっとたくさんの情報を渡されたときにほとんど理解できなくて涙目になることがあるように、私がわかりやすいからと言って絵や図だけで情報を渡してしまうと、理解できなくて涙目になる人がかならずどこかに存在しているわけです。

自分がわかりやすいからといって、他の人もわかりやすいとは限らないということは、デザイナーという職業だからこそ特に気をつけなければいけないことだな、と痛感しました。

また、聴覚情報しか用意されていない場合でも、少しでも多く情報を理解できるように、例えば目を閉じて視覚情報をシャットダウンしたり、グラフィックレコードのようなことをしてみたり、ゆっくり話してもらうようにお願いしてみたり…など、工夫する必要があるなと思いました。

https://blog.splout.co.jp/33/

優位特性についてはこちらの記事でも触れられています。


SolrCloudのリーダー再選出の動作を確認する

はじめに

前回の記事ではシャードを構成する複数のレプリカの中からリーダーが選出される仕組みを解説しました。この記事では、実際に動いているSolrCloudを使って、特定のノードがダウンしたときにリーダーが切り替わる動作を確認してみます。

SolrCloudの構成

  • サーバ3台、サーバ毎に Solr 1プロセス
  • コレクション名 test のコレクションを作成
  • test コレクションは shard1 と shard2 の2つのシャードを含む
  • 各シャードはそれぞれ3つのレプリカ(それぞれ別のSolrノードで動く)を含む
コア名ノードシリアル番号備考
core_node3172.19.0.7:898512リーダー
core_node5172.19.0.6:898314
core_node7172.19.0.5:898413
shard1
コア名ノードシリアル番号備考
core_node9172.19.0.7:898512リーダー
core_node11172.19.0.6:898314
core_node12172.19.0.5:898413
shard2

リーダーがダウンしたとき

ノード 172.19.0.7:8985 (core_node3, core_node9)を落としてみます。

それまでのリーダー(シリアル番号12)の次に若い番号(13)を持つcore_node7およびcore_node12が新しいリーダーに選ばれています。

コア名ノードシリアル番号備考
core_node3172.19.0.7:898512ダウン
core_node5172.19.0.6:898314
core_node7172.19.0.5:898413リーダー
shard1
コア名ノードシリアル番号備考
core_node9172.19.0.7:898512ダウン
core_node11172.19.0.6:898314
core_node12172.19.0.5:898413リーダー
shard2

ダウンしたノードが復帰したとき

ダウンさせていた 172.19.0.7:8985 (core_node3, core_node9)を復帰させます。

リーダーに変更は無く、core_node3とcore_node9は新しい番号15をそれぞれ割り当てられます。

コア名ノードシリアル番号備考
core_node3172.19.0.7:898515復帰
core_node5172.19.0.6:898314
core_node7172.19.0.5:898413リーダー
shard1
コア名ノードシリアル番号備考
core_node9172.19.0.7:898515復帰
core_node11172.19.0.6:898314
core_node12172.19.0.5:898413リーダー
shard2

リーダーを意図的に変更する

まずcore_node3をpreferredLeaderに指定します。

curl 'http://172.19.0.6:8983/solr/admin/collections?action=ADDREPLICAPROP&shard=shard1&collection=test&replica=core_node3&property=preferredLeader&property.value=true'

REBALANCELEADERSを実行。

curl 'http://172.19.0.6:8983/solr/admin/collections?action=REBALANCELEADERS&collection=test'
{
  "responseHeader":{
    "status":0,
    "QTime":3053},
  "Summary":{
    "Success":"All active replicas with the preferredLeader property set are leaders"},
  "successes":{
    "shard1":{
      "status":"success",
      "msg":"Successfully changed leader of slice shard1 to core_node3"}}}

shard1のリーダーがcore_node3に変更されました。

FORCELEADER

FORCELEADERは障害等何らかの理由でリーダー不在の状態ができてしまった場合に強制的にリーダーを割り当てるためのコマンドです。リーダーが居ない状態を意図的に作るのは難しいので、正常な状態のシャードに対して FORCELEADER を実行するとどうなるか試してみました。

curl 'http://172.19.0.6:8983/solr/admin/collections?action=FORCELEADER&collection=test&shard=shard2'
{
  "responseHeader":{
    "status":500,
    "QTime":35},
  "error":{
    "metadata":[
      "error-class","org.apache.solr.common.SolrException",
      "root-error-class","org.apache.solr.common.SolrException"],
    "msg":"The shard already has an active leader. Force leader is not applicable. State: shard2:{
(略)
    "code":500}}

指定されたシャードにはリーダーが居るのでFORCELEADERの実行はできませんと怒られてしまいました。

おわりに

SolrCloudのクラスタはZooKeeperと連携していて、リーダーがダウンしたら自動的に新しいリーダーが選ばれてなるべくダウンタイムが小さくなるように工夫されている、という漠然とした理解から一歩進むために、具体的なリーダー選出のロジックを調べました。ZooKeeperの分散アプリケーションのコーディネート機能を使って案外シンプルなロジックで実装されていることが分かりました。この理解を持った上でリーダー調整用のAPIを上手に使えば、稀に発生するクラスタ異常にもうまく対処することができそうです。


SolrCloudのリーダー選出の仕組み

はじめに

SolrCloudではコレクションを複数のシャードに分け、各シャードを複数のレプリカによる冗長構成にできます。レプリカの中から1台リーダーが選出されてインデックス更新更新の責任を持ちます。
旧来のマスタースレーブの構成では、マスターがダウンしたときには復旧するまでは更新処理が停止してしまいますが、SolrCloudではリーダーがダウンした場合には自動的に別のレプリカがリーダーに選出されてなるべく更新処理が停止しないように工夫されています。
この記事では、リーダー選出の仕組みを解説します。

リーダー選出の仕組み

リファレンスでは以下のように説明されています。

SolrCloud にはマスターもスレーブもありません。その代わりに各シャードは最低1台の物理的レプリカから構成され、その中の1台がリーダーとなります。
リーダーは自動的に選出されます。最初は先着順で、以後は
http://zookeeper.apache.org/doc/r3.5.5/recipes.html#sc_leaderElection
に記述されている ZooKeeper を使った手順に基づきます。

リーダー選出の手続きは org.apache.solr.cloud.LeaderElector クラスで実装されています。このクラスのコメントでもリーダー選出の仕組みについて触れられています。

これらのドキュメントとコードを参考に、リーダー選出の仕組みをまとめました

  • 冗長構成においては各レプリカが同じ状態を持つことが重要だが、リーダーを選ぶためには何らかの「違い」を作り出す必要がある
  • 違いを作り出すために ZooKeeper の Ephemeral & Sequential ノードを使う
    • ZooKeeper のクライアント(Solrのノード)は ZooKeeper 上の木構造にノードを作れる
    • ZooKeeper の Ephemeral ノードは、そのノードを作ったクライアントがダウンしたときに自動的にそのノードが無くなるので、クライアントのダウンを検知できる
    • ノードに Sequential プロパティを付与すると、兄弟ノード間で作られた順に一意のシーケンシャルな番号が振られる
    • 一番若い番号を持つノードのクライアントをリーダーとする
  • リーダーがダウンしたとき
    • ZooKeeper のクライアントは ZooKeeper 上のノードを監視することができる
    • 各レプリカは自分より1個若い番号のノードを監視しておく
    • リーダーがダウンしたらそのノードを監視していたレプリカが新しいリーダーになる
  • 全体のコーディネートは SolrCloud の Overseer が担当する
    • Overseer は SolrCloud のクラスタを構成する各 Solr ノードから選ばれるリーダー
    • Overseer 選出の手続きはシャードを構成するレプリカからリーダーを選出する手続きとほぼ同じ