自分のメイン言語の遷移

メイン言語

小学校高学年くらいの時からプログラミングをはじめました。
細かくは他にもたくさんの言語を使っているけど、メインで使ってきたやつを書いてみる

全図

JavaScript

Windows95のパソコンが家に来た！ということで、いろいろいじってた。
ソフトを買わずにプログラミングが出来る手段としてJavaScriptとHTMLをやりました。

HSP

雑誌についてたフリーソフト。今でもまだ流行ってますね。
一通りのゲームを作りました。

Delphi

PersonalEditionが無料で使えた時に遊んでた。VCLの知識は後の.Netなどでも役に立ってる
Pascalなんだよな・・

Java

iアプリとかを作ってた。アプレットとかでも少し遊んだ
オブジェクト指向 というのをなんとなく理解

N88BASIC

何故か親戚からうちにやってきたPC98で遊んだ。図書館にN88BASICの本があったのでそれを見ながら写経

Python

Blenderのスクリプト言語だったので、興味があって触ってみたり。日本語を扱うのが辛かったイメージ

C/C++

大学でゲームを作るときに使う。Windowsアプリもちょっと書いたり

Perl, PHP

会社でやるのでプライベートでも使い始めた系

まだまだやるよ！

今後もいろいろ挑戦していきたい。
ElixirとかGoとか、JavaScriptもまだまだ奥が深そうだし・・

電子工作とかも同じC言語と言いつつ気にする点が全然違ったり。

みなさんは どんな言語遍歴ですか？

todo

今後図示したいものたち

やや大きめ

  • mbed周り
  • WebFrontendのもっと詳しいやつ
  • PDAの歴史
  • CPUの歴史
  • メモリ
  • 電子部品
  • 初めに作ると良い物

小さめ

  • SDカード
  • 画面解像度
  • 乾電池
  • 秋葉原の電子工作系お店
  • コネクタ
  • CPUの足
  • wiki文法
  • 工具
  • IME
  • Linuxディストリビューション
  • 家庭用ゲーム機

IoT系のマイコンのまとめ

最近話題のIoT系のチップとかなんやらかんやらの、カタカナ用語、アルファベットをまとめてみました。

(PIC, H8, MIPS などはちょっと使ったことがないので「？」とか書いてます；)

随時更新します
ご意見・間違いの指摘は http://twitter.com/ina_ani まで

全図

横軸の説明

MicroController

マイコンには仕様がある。それを書いてあるのがここ
同じ仕様で違うメーカーがチップを出したり、コアの仕様は同じで周辺便利機能がひっついたチップとかがある感じ

Chip

具体的な製品。CPU本体
これ単品で買って、組み立てて作ることもものによっては可能

Board

大体この単位で買います。当然Chipを買って、自分で１から作ったほうが安くつくけど、ハンダ付けやらなんやら大変なのでボードで買う人が多いのかな？

Framework

大体ChipやBoardと対応して、開発環境というのがある。
mbedはここがオンラインコンパイラ（Web上で開発をするやつ）だったりしていろいろと特徴的
RaspberryPiとedisonはLinuxが動いちゃうので、ここは何も書いていない

Level

電源レベル。ポートから出てくる電圧です。
これが使いたい機器と違う場合はいろいろと工夫しないといけない。USBは5V、SDカードは3.3V などなど

個人的なイメージ

ArduinoのAtmega168,328,32u4とかを使ってるものは出来ることがシンプルで自作も楽ちん（財布的にも）

ARMはCortexM0はAVRの8bitCPUと同じような手軽さで使える（でも32bit）

RaspberryPiやedisonはもはやちっさいパソコンという感じ。リッチなことがしたいならこれが便利だけど、ちょっと「電子工作」という感じはしない。

例えてみる

たとえ 実際
ミニ四駆 Atmega168, Atmega328, Atmega32u4, LPC810, LPC1114, RL78
ラジコン Atmega2560, RX63N
軽自動車 RaspberryPi, edison

ミニ四駆と軽自動車を比べるのはナンセンスだよね
ケースバイケースで使い分けていきたいところ。

Webテクノロジーを思いつく限り図示

この聞いたことない単語はいったい何を表しているんだ・・？みたいなときに類型をたくさん知っていることで、簡単に理解することが出来るような気がする。

ということで、いまのところ知っている知識を図にしてみることにします。
まとめている中で、こっちにはこの要素があるのに、こっちにはない？ いやまて、調べたら出てくるかも・・ みたいに知識の穴埋めが出来ることにも気づきました。

随時更新します
ご意見・間違いの指摘は http://twitter.com/ina_ani まで

全図

CPU

Intelのx86アーキテクチャと、その互換CPU（図ではAMDのFx）
最近はAndroidなど組み込み機器向けのARMもメジャーになってきた。今やWindowsもARM版がある。

マザーボードとか、グラフィックボードについては、最近どうなったのか知らないので、図にできてない

OS

Linuxとその他、 OSのカーネルは共通でディストリビューションの違いは、パッケージマネージャの違いと思ってる。設定ファイルの作法などもディストリビューションによって違う

Web Backend

Webサーバと言語ランタイムによって、Webサービスが提供される。
また、各言語のライブラリをパッケージとして扱い、依存関係やバージョンアップを管理できるようになっている。

これはOSのパッケージマネージャとやってることは同じだと思うのだけれど、レイヤーが少し違うということらしい。 一緒にしたほうがいろいろ楽な気もするし、 運営することを考えると地方分権的に分かれてたほうが良いような気もする・・ いたし痒し

システムグローバルに唯一のライブラリを導入するのは、わかりやすくて良いが、1つのシステムの中に複数のサービスを共存させる事を考えると、 サービスごとに違うバージョンのライブラリを使いたいこともある。
そんな時にはローカルにライブラリディレクトリを用意して、そこにサービスごとのライブラリを格納するのが便利だ。
パッケージマネージャの中には上記のような、ローカルのライブラリを扱うものもある。

パッケージマネージャにはそれに紐づくパッケージリポジトリがある。パッケージはリポジトリにより管理され、パッケージマネージャを通じてシステムにダウンロードされインストールされる。

言語ランタイムも、違うバージョンをサービ毎に変えて実行したいこともある。普通の実行ファイルは/usr/binなどに格納されるが、これでは1つのシステムに1つのランタイムしか利用できない。
これを簡単に入れ替えるのがランタイムのバージョン管理である。

Webサービスを作るときは、いつも同じようなソースコードを書くことがある。そういうものは便利な部品として、フレームワークとして公開されているものがある。
特にこの図でフレームワークに分類したものは、比較的大きなものである。

Webサービスとデータベースは強い関係がある。大半のWebサービスはデータベースを使っている。データベースを扱うためには一般的にSQLなどのクエリ言語を使う必要があるが、スクリプト言語の中にSQLを記述するのは、様々な問題点がある。
そこで、SQLを隠蔽してスクリプト言語から簡単に扱うような仕組みが作られている。それがORMである。

前述のフレームワークというのは認証・ORM・ルーティングなど、様々な用途に対応できるような、重厚長大なものがである。
しかし場合によっては、ごく簡単な機能だけあれば、事足りることも多くある。そういったニーズに対応するものを、この図ではマイクロフレームワークと分類をした。

Webサービスを作る時、JavaScriptの文法チェックを行ったり、minifyをしたり、 リリース前に行うべき一連の処理があることが多い。
それらを実行する枠組みがタスクランナーである。指定されたファイルを監視し、変更を検知すると一連の処理を実行する。

プログラム言語では、設定ファイルや、データの格納の際に構造化されたデータを読み込むことが多い。
配列、連想配列などをうまくテキストファイルに記述するために、わかりやすく、機械にも読みやすいフォーマットを用意する必要がある。そのような記述の形式を、この図ではstructとして分類している。

WebFrontend

とにかくいまは戦争中なので、思い当たった語句をたくさん書いてある
戦争が終わったら呼んでほしい(気が向いたら加筆します）

Etc

DBMS

データベースと一言に言っても様々な種類がある。
特に行列のデータを扱うのが得意なものをこの分類としている。

KVS(nosql)

行列ではなくキーバリューでのデータを扱うのが得意なものをこの分類にしている。

VCS

バージョン管理システム。わりとみんな使ってるので説明は特に無い。
最近はほとんどgitな印象
cvsは2世代前 svnは1世代前という印象。

全図

はじめてのhexo

hexoを使ってみる！

css,jsが読み込まれない

なんかgithubpagesをサブディレクトリで運用していると面倒な設定があったが、なんとかなった

rface

http://3100.github.io/log/2015/08/10/hexo-with-subdirectory/
ココを読んでたんだけど微妙に違う・・
theme_configを書いても反応してくれない・・

テーマによるのかもしれないけれどもurl,rootを設定すればとりあえず動いているように見える

共通の画像を読み込みたい

./source/images/

に画像ファイルを置くことで

./public/images/

の下にdeployされるみたいだ。

で

1
![rface](/arekore/images/rface.jpg)

こんなふうに書けば参照できる（arekoreってのはこのブログのサブディレクトリ。 これをココに書くのは気持ち悪いのだが・・仕方ないか）
本当はブログポスト毎に画像のディレクトリを作って運用するものらしい。

普通と違うことをしようとすると辛くなるのは、こういうツールの性だよね・・

テーマを差し替える方法

_config.ymlを書き直したらOKっぽいんだけど

1
2
$ hexo clean
$ hexo generate

みたいなのもたくさん打った気がする。何が良かったのかわからない
hexo serverが上がっているときにcleanしても無駄っぽかった

エラーがまだ出てる・・

ファイルを編集すると下記エラーが出てhexoサーバが落ちる。
また立ち上げれば良いんだけど・・ なんだこれ

1
2
3
4
events.js:79
throw er; // Unhandled 'error' event
      ^
Error: EISDIR, read

腐ったテーマが多い・・

僕の好みもあるんだけど・・ イマイチ良いテーマがない
英文前提だと見出し文字とかすごく大きくなってたり・・

テーマのプレビューが中国語だったりしてよくわからなかったり・・・

結局landscape（最初のテーマ）のpaddingを少しいじって対応。
まぁちょいちょい直していくのも悪くないか・・ ということにしよう