2018年やりたいこと100
動機
下記のブログを見て、面白そうだなぁ、自分もそれだけ挙げられるかしらという単純な動機です。
それにこうやってわくわく未来を想像する時間が一番創造的な気がするので、気が変わらないうちに書ききります。
やりたいこと100
- Common Lispの発展的な機能(CLOS、リーダマクロなど)を学ぶ
- Clojure+ClojureScriptでWe
- Common Lispで好きな言語をエミュレートする
- Emacsのメジャーモードを何個か書きたい
- ClojureとかをEmacs環境で書けるようにしたい
- Smalltalkの基礎を押さえる
- Prolog勉強
- Perlの勉強を始めたい
- Rubyもなんとなく癖とか覚えたい
- C++はやってみたいが、余裕があれば
- 低レイヤーにも首は突っ込んでみたい
- JavaScriptを書く時にも関数型プログラミングのスタイルを混ぜたい
- CSSの新しいAPIとか発想についていきたい
- 定期的にVimとEmacsのキーバインドを覚える
- SpaceEmacs触ってみたい
- AWSに触れてみる
- Dockerに触れてみる
- Linuxを触る時間は増やしたい
- GraphQLやってみる
- スポーツとITについて考える
- 関数型プログラミングのスタイルをもう少し深く学びたい
- ゲームプログラミング周辺に触れてみる
- Ruby Kaigiに行く
- Lispの勉強会に顔を出してみたい
- できれば、Perlの勉強会ものぞいてみたい
- 毎日Git Hubのトレンドとソースコードを眺める
- 毎日趣味のソースコードを書く(草を生やす?)
- 毎日新しいニュースを眺める
- 他の人のサービスに積極的にアンテナを張る
- On Lisp写経
- Let Over Lambda写経
- スマートスピーカーのアプリを書く(やる気があればClojureScriptで)
- クローラーを使って何か作りたい
- ブラウザ操作で買い物をしたい
- もしくはAmazonAPIで便利な生活が送れないか考える
- ラズパイを気持ち触ってみたい
- なにかのパーサーとかを書いてみたい
- なにかOSSにプルリクするチャンスをうかがう
- ブログ記事もできれば、書きたい
- 技術記事をまじめに書く練習をしたい
- いろんなタイプの記事に挑戦
- 技術同人誌みたいなものの世界にも首をちょっとつっこめたらいいな
- 技術書展も行ってみたい気持ちはある
- 高専系のイベントも見てみたいところはある
- 毎日本を読む
- レビューはたまに書けたらいいな
- 英語のブログとかでの情報収集を進める
- 毎日反省日記を書く
- 後輩ともくもく会をやる
- 打ち込みとはどんなものなのか見てみる
- 同級生ともくもく会をやる
- バドミントンの配球予測ゲームを完成させる
- バドミントンの上達に直接かかわる何かを作りたい
- Processingの基本を学んで、バドミントンのなにかをエミュレートしたい
- 練習量は増やす
- 練習方針を固めたい
- スポーツの本も1か月に1冊は読みたい
- バドミントンのブログも2週間に1回くらいは書きたい
- 後輩には負けない
- 親孝行する
- Twitter中毒にならない
- 昼寝を減らす
- 間食を減らす
- 転職条件を考える
- 4か月に1回歯医者に通う
- 定期診断に引っかからない
- エナジードリンクは週に2回ぐらいまでに留める
- 信濃の後輩のところに遊びに行く
- 面白い会話ができるように心がける
- 面白い会話を分析するアプリでも作ればいいんだろうか
- 朝食とかの購入をシステム化したい
- システム思考に向いたツールを探す
- 定期的に買っている本をアプリで管理する
- できるかぎり本は電子書籍で買う
- 技術書以外も読む時間をどこかで作る
- ゲーデル、エッシャー、バッハを読む
- 本に散財しない
- 同級会が開かれることを祈る
- 友達に昔の話を伝えたい
- ついでに転職の話を聞く
- 友達の結婚式に呼ばれたい
- 友達にやさしくする。技術の話は控える
- ドキドキしないことは極力やらない
- コードレビューはやさしくする
- 新入社員と仲良くなる
- 新入社員が伸びる条件と教育方法を見極める
- バレーかサッカーのプロの試合を観戦したい
- 映画見たい
- 工数管理の考え方とか上司から盗みたい
- モーニングペーパーもできれば書き続けたい
- 部屋をきれいに保つ
- 業務で迷ったことを力づくで解決しない
- 人に聞く前に考える
- 普段聞いている音楽リストを更新する
- 姪っ子の心を理解する
- 見たいことのないクラフトに出会いたい
- 芸術系のなにかに手を付けてみてもいいのかも
- 週に1度は掃除する
- おいしいたこ焼きとから揚げ屋さんを見つける
- 海外に行けたら行く
所感
60個くらいでスタックがなくなって深堀りでしのいでいましたが、80くらいから時間をかけないと全く出てこなかったです。真剣に考えたので、人間性がだいぶ出てしまった感じもあります。
やりたいなぁと思いながら、言語化できていなかったところが出てきたのはよかったかなと思います。基本的に作ろうと思ったことも大体忘れてしまうので、備忘としてもいいですね。
言語8個習得はどう考えても無謀だったり、いろいろと願望込みなのでこれに優先順位をつけて、アイデアを肉付けすればそこそこ有用だという感じはしました。
ただ、プログラム系だと技術でだいぶん稼げるのでもう少しルールを限定したほうが、面白かったかもしれないですね。
今年は、とにかくいろんな言語とかツールに深く入り込めたらいいなと考えているので、深さ優先でいろいろやりたいです。とりあえず、上に書いたことを今日から実践するように頑張ります。
2017年振り返り
仕事
基本的にはAngularを使って、古いシステムを入れ替えるという計画があり、その設計・技術検証あたりをずっとやっていました。
今まではPGとしての活動のみでしたが、要件定義やDB設計、画面設計の一部も任せてもらいました。チームの人数は4人で、そのうち2人は初めてWebシステムを作るというので、大体のことは自分ともう1人のリーダーでやりました。
あとは4か月間新入社員の教育を担当し、業務をやりながら教えていました。
仕事で印象に残ったところ
新入社員の教育
大体のところは記事に書いた通りです。
新入社員の研修を担当して感じたこと - How IT Works
新しい技術を導入して会社の技術レベルを引き上げたいというところと、自分で考えられる人材を育てたいという2つの試みを目的で設計しました。
前者は達成できましたが、後者はどうにもできませんでした。図解の方法を教えたり、極力ヒントを教えて答えを教えないようにしましたが、効果があったようには思えません。
技術を覚える勉強的なアプローチがダメだったのかなという気はしています。毎日新しい技術が出てくるので、効率よく作業を展開するというエンジニアリングは難しかったと思います。
実務は繰り返しのパターンが多いので、ある程度冗長にカリキュラムを組んで工夫させるのがよかったのかもしれません。
また、負荷をかけすぎて、余裕というものがなく、技術的な工夫より納期に追われていたのかなという考えもあります。
どちらにせよ、新しい技術を覚えることは簡単だとわかったので、もっと考える力を軽視せず、そこらへんをきちんと設計すべきだったと反省しています。
いいエンジニアは育つものなのか、育てるものなのかそういうところはいまだに自分の中で分かっていませんが。。
最近のWeb技術について
AngularでSPAでシステムを組みましたが、個人的には業務システムでは過剰だなという感想を持ちました。
UIにもよりますが、単純なCRUD系のシステムであれば、APIを挟むことによるセキュリティ維持にかかるコスト、レイヤーをまたぐことによる二重メンテナンスによるコストを払いきれない感じがしました。
これを世間一般のスタンダートとすることが正しいのか、という気持ちはいまだに捨てきれていません。
思想的に言うと、コンポーネントを関数的に表現するという考え方は気に入りました。扱いやすいです。Fluxは入れてませんが、それに近いことができるのは気持ちいいです。
CSSModule的なものも素敵で、あぁこれが欲しいものだったという感じがでていてよかったです。
ただ、CSSに関しては何というか、コンポーネント間での相互作用みたいものがまだ残っていて、入力に対する出力という純粋さがないので、少々気持ち悪さがありますが。。
Windows Formsとか、Swingくらいの適当さでデザインが組める何かがほしいです。
RxJSは最初はsubscribeするだけでしたが、途中からいろいろ組み合わせてすっきりと書けるようになりました。連続したイベントを表現する分には楽でよいです。
ただ、途中から分岐が増えるとパズルみたいになって、可読性が低くなるきらいがありました。ルール作りなしに自由に使っていい代物ではない感じがしますね。
趣味
前半はLinuxとVimを触っていました。後半はLispを触っていました。
Vim
Linuxを1か月勉強してみた - How IT Works
Linuxは勉強したのはいいのですが、メインマシンではないので、そこまで恩恵はなかったです。コマンドラインに慣れたというところくらいですね。
Vimの恩恵は言葉で書けないくらいで、劇的な変化でした。
パターンが多い業務システム開発では、コピーと改変でものを作るので、コーディングの効率が大きく変わりました。
困るのはペアプログラミングに近いことをやるときぐらいです。
Vimは一度覚えて終わりというよりは、何度もやらないと覚えきれないです。最近、また「実践Vim入門」を読み始めました。4週目くらいですが、いつ読んでも気づきがあるいい本です。
Lisp
自分はプログラミング言語の構文を眺めるのが趣味みたいなところがあるのですが、Lispは特別でした。
特に印象に残ったのは「Let Over Lambda」です。
Lispが遅いならマクロで早くすればいいだけとか、マクロを作るマクロを定義するとか、想像をどんどん超えたマクロを出してくるのが衝撃でした。
これをみてLispを生涯のパートナーにしたいと思って、惚れこんでしまいました。
といいながら、途中Clojureに浮気していました。
こちらはモダンなLispという感じで、Lispの過激な機能を削って安定版にしたような印象です。また関数型に傾倒していて、状態にかなり厳しい感じです。
環境周りがかなり整備されているうえに、欲しいライブラリやAPIは大体あるので単にLispで遊ぶならこちらはだいぶんいいなぁと思えました。
実用的な何かを作るとしたら、第一の選択肢はこっちを選ぶでしょうね。
あとは、情熱的なPGの方が多く、刺激を受けました。どこにでも顔を出されるので、少々怖いなと思うところもありましたけど。。
そういうところでClojureも気に入りましたが、自由こそプログラマに与えられた最良の道具だと思うので、Common Lispでもう少し頑張ろうとは思っています。
来年やりたいこと
Emacs
CとMの使い分けが面倒で、途中で挫折していましたが、Emacs Lispが魅力的なので来年はEmacsに傾倒したいです。
どうにもSpace Emacsというそこらへんの解決策を含んだものもあるらしいので、それも含めてEmacsに深く入り込みたいと思っています。
エディタがカスタマイズできれば、自分用の作業のほとんどが効率化できるだろうというところで夢があります。
Common Lisp
CLOSとか、リーダーマクロをいじくったりというところはできていないので、そこらへんを掘り下げたいなと思っています。
最終的にはDSLみたいなものを作るところがゴールのような気がしています。
思いついたこと
基本的に自分の興味は適当です。今は3D表現、Processingあたりが面白そうと感じていますが、やるかどうかはわからないです。
とりあえず、面白そうと思えば飛びつけばいいと思っているので、LispとEmacsをベースに好きなことに浸っている一年になるように願っています。
Lispを1か月勉強して
動機
巷ではLispは「神の言語」と呼ばれていると聞いて、興味を持ったのが始まりです。
具体的に調べてみると、マクロと呼ばれる「コードを生成するコード」をかけるという話でした。
業務ではC#やTypeScriptといった静的な言語を扱うことが多いのですが、個人的にはJavaScriptのダイナミックな動きが好きだったので、Lispはその延長線上にあるような予感がしました。
あとは今はやりの関数型言語に分類されることが多いので、そこらへんの思考を盗めるとよいコードを書くことにつながるのではないかともくろみました。
そういうわけで、死ぬ前に一度は触ってみようと思い、勉強を始めました。
勉強方法
Lispを書くにはEmacsがいいということだったのですが、今のところ自宅のPCはWindowsなので手軽にできるxyzzyでやることにしました。
xyzzy - カスタマイズ可能で軽快な Windows 用テキストエディタ
まずは、下のページを写経することから始めました。基本的にscratchで書いて、C-jでコンパイルして、評価するだけです。
慣れてきたら、くじ引きとかボウリングとか適当な課題を作って遊んだり、Git Hubの適当な問題を解いて遊んでいました。
書籍は色々買いましたが、以下の4冊がなかなかいいなと思います。
上2つはLispの概要で、下2つはマクロの使い方です。特にマクロについては使い方が難しいので、書籍があることが大きな助けになっています。
感想
Lispは関数型ではない
勉強し始めてから学んだのですが、Lispは関数が中心の言語ではありますが、必ずしも関数で書かなくてもいい言語でした。
なんならオブジェクト指向っぽくも書けますし、手続型でも書けます。
こうした自由度の高さはJavaScriptに近い感じがしました。
REPL楽しい
今までコンパイル言語ばかり触ってきたので、すぐに評価してテストできるのはとても楽しい体験でした。
コンパイル言語や静的型付けが悪いとは思えませんし、いい面も多いのですが、試しながら書く趣味のプログラミングならこちらのほうが好きですね。
現代言語に劣らない
正直かなり前に開発されたはずの言語にかかわらず、高度なストリームや高階関数を使ったコレクション、オプショナルな引数など新しい機能が含まれています。
だから、Lispが最近の言語に比べて面倒だと思うことは少なかったです。今でもこれなら、昔はもっと突出した言語だったんだろうなと感じます。
逆にいうとLispのエッセンスはかなり最近の言語に取り入れられていて、Lispでなくてはいけないという部分は大分減っている気もします。
マクロ難しい
単なるテンプレートかと思っていましたが、難しいです。
何が難しいかといえば、こうすれば楽になるというパターンを導きだすのが難しいです。普段の癖で、何でも関数で抽象化してしまったり、楽にできる場面を見逃すことが多いです。
書籍を読みながら幅は広げていますが、いまだにマクロを自在に使うという段階まで来ていないです。
自由と代償
Lispの良さも悪さも自由から来ていると思います。
構文までいじくれる言語なので、どんな書き方、どんなデータ構造でも自在に作れるのですが、それゆえにプログラマの技量・思想にすべてがゆだねられている言語という印象です。
正直、今の自分であれば、やり方のパターンがある程度固まっているJavaScriptのほうが間違いなく早く書けます。
そういう意味でLispが神の言語というよりは、Lispを自由に扱えるようになったプログラマが神の域に近づくというのが正解のような気がします。
だから、自分は1か月勉強しましたが、スタートラインに立っただけで、Lispの本質に近づけていないような気がします。
まとめ
Lispには深さがあると思います。特にマクロを作るマクロだとか、マクロでクロージャを操作するという発想を見たときに、考え方の深さに驚きました。
オブジェクト指向や関数型も勉強して楽しかったのですが、これにマクロが組み合わさるとどこまで表現が深くなるんだろうかとドキドキします。
正直にいうと、Lispは万人が勉強すべきという感じはしません。関数型をやりたいならJavaScriptやHaskell、Scalaあたりでいいのかなと思います。
でも、プログラミングの魅力をもっと味わいたいならこの言語はベストに近いと思いました。
新入社員の研修を担当して感じたこと
研修の概要
今年の新入社員研修を担当して、一からカリキュラムを組み立ててやり通しました。
条件は下のような感じです。
- 5カ月間毎日行う
- 配属される部署は不明
- さらに配属されるチームによって必要とされる技術セットは大きく違う
- 古い技術の保守チームもある
- ただ、Windows FormsとWeb系の技術の基本は少なくとも身につけてほしい
- 新入社員は2人、自分は業務と平行して教育する
研修設計で当初考えたこと
教えない
最低限のルールはあるものの、ほとんど自由に近い条件なので、最初のカリキュラムの設計が大事かなと思いました。
とりあえず最低限考えたことは以下の2つです。
- 技術要素をできる限り広くする
- 教えない教育を中心にする
うちの会社では配属後に丁寧な教育をしないチームもあります。だとすれば、この会社で生き残っていくためには、自分で学び自分で考えるサバイバル能力がいるのではないかという考えがありました。
それに加えて、自分で自ら学ぶことができるのであれば、どんな部署に行っても大丈夫だろうということです。
具体的には仕様と使用する技術は指定しましたが、文法やライブラリの使い方を一から教えたことはないです。
参考書等は必要と言われた段階で用意しました。
レベル設定
また、レベル設定は想定される一番レベルの高いチームに合わせました。とはいえ、世間でいえば普通くらいでしょうが。
社内の最高レベルに5か月で行けるか、行けないかという実験的な部分もありましたが、まぁ低いレベルに合わせるのもどうかなという感じです。
具体的には以下のような感じです。
- 極力新しい技術を使う
- コードレビューを厳しくする
- デザインもできる限り業務に近づける
- 仕様変更を辞さない
カリキュラム
- C#
- Web
- その他
- JavaScript課題
- PowerShell
- Markdown
- Git
- 座学
- プログラミングパラダイム
結果
技術的には問題なし
新しい技術を覚えることについては全く問題なかったです。実際丁寧に教えたことはないですが、GitやAngular4、Expressの使い方などは比較的ちゃんと理解していたと思います。
個人的な感覚から言えば、それなりの頭があれば技術を覚えるという点は問題ないという印象を受けました。
抽象概念で躓く
やや問題になったのは、Anuglarのコンポーネントの設計やオブジェクト指向設計、もしくは関数型に近いロジックの書き方というところでしょうか。
あるいは具体的には再帰の使い方や高階関数の使い方は理解してもらうのが大変でした。
スピードが上がらない
時間切れでボウリングの課題も終わりませんでしたし、スピードに関しては最後まで向上が見られませんでした。
コードを書くというところは確実にできるようになっていましたが、管理画面に3か月かかるなど速度面は十分でないという傾向がありました。
反省
特に学んでよかったこと
PowerShell
うちの会社は基本的にVisual Studioで作業していて、あんまりシェルは触らないのですが、あえて研修はVSCodeでひたすらシェルで作業させました。
一度基本的なコマンドを理解すると応用がかなり効くので、なかなか便利でした。
Git
Gitはとても便利なうえに使えるとデグレ時などにとても役に立ちます。比較的すぐに扱えるようになりましたし、コミュニケーションにもよかったので早く導入すればよかったです。
Express
比較的自分で設定しないと動かないという特性を考えると教育には良かったと思います。 Webの仕組みを知らなくても動かせるフレームワークもありますが、あえて薄いものを選びました。
いらなかったこと
Angular4
重すぎます。情報源も少ないですし、何をするにしても流儀が多くそれが教育に関してはノイズになっていました。
Reactがいいかと言われるとあれも何だかんだ付随品が多いので、個人的にはjQueryを推します。
やるとすれば、jQueryで小さい課題を多めに扱って、そのうち一つをReactで書き換えるぐらいがいいかと。
レスポンシブデザイン
デザイン面で完全に足を引っ張っていました。一度崩れると修正が難しい割りに、CSSについて学べることが多くないのが残念。
新入社員がやってみたいと自発的に言いだしたので任せてみましたが、一部分が可変くらいでよかったんじゃないかという印象です。
座学
座学でオブジェクト指向設計、関数型のパラダイムを時間をかけて勉強してもらいましたが、定着率が思うほどあがらなかったです。
これは課題をそれらのパラダイムを使わないときれいに解けない課題を作って解かせたほうがよかったですね。
教える最善の方法は座学よりも課題ということに最後のほうで気づきました。
だめだったところ
結果的に一人は一番レベルの高いチームに行って上手くやっているようですし、もう一人も開発が関係ない部署に行ってなんとかやっているとのことらしいです。
自分で設定した目標からするとちゃんと果たせたと評価はしていいでしょう。
ただ個人的な感覚から言うと、満点ではない感じがします。
プロジェクトに入る分には問題ないのですが、優秀なプログラマに迫れたかというと近づけていない感じがします。
うちの会社の優秀なプログラマの方はこのカリキュラムにあることを優に1か月もあれば十分吸収したそうですし、自分も当初計画では3か月で今回の内容が終わると読んでいました。
そう考えると、技術だけ繕って本質を教えきれなかったのではないか?という気持ちがぬぐいきれません。身についたのは答えを調べる能力だけなのではないか?
なので技術セットを多少甘くしてでも、思考の仕方、抽象度の高い考え方を教えればよかったなぁというのが反省になります。
具体的には小さな課題をたくさん用意するとか、あとはスライドを作成したLTなどが意外にいいのかなという感じがしています。
感想
研修を通してずっと優秀なプログラマとはなんだろうということを考えていました。
途中で感じたのはこだわりの強さがその1つの条件なのかなという風に思いました。
コメントの入れ方、ロジックの切り方、デザインの見せ方、パフォーマンスとかそういうところに脅迫的なこだわりを持っている人が優秀な人には多いとか。
そういうところが最後まで研修とつながらなかったのが、すごく残念でした。
来年は多分担当ではないと思いますが、それが資質なのか、環境なのか、教育の賜物なのかとかそういうことをもう少し注視して経過を見てみたいです。
言い訳
研修の期間だけが決まっていて目的があいまいなこと、そもそも開発に行くとは限らないのにカリキュラムが 開発限定なのはどうかという議論は置いておいといてください。
まぁ、基本的にプログラミング未経験者しか入社してくれず、有名大学の人が来ることもなく、家にPCがないというプログラマーがそこそこいるという環境では何かしらの仕組みがいるのは確かですが。。
よく考えたらインターンシップみたいですよね。これ。
最近始めた習慣とかについて
前書き
最近は生活をちゃんと管理しようという気持ちが強いので、色んなことを習慣にしてみています。
徐々に仕事や生活の仕事の質が改善できつつあるような気がするので、簡単に書きます。
タスク管理
一日の最初に計画を立てる
あたりまえのような気がしますが、今までは一日分のTodoリストを書いて終わりでした。
今はちゃんとこの時間にこのTodoを終わらせるというような時間まで指定して計画を立てます。
一日にやる作業は色々なものがあって、書類を作成したり、コードを書いたり、メールを返信したりと色々なものがあります。
作業にはそれぞれ向いている時間帯がありますし、あるいはずーっと同じことをしていると疲れるときもあるので、それらをもろもろ考慮して計画を立てます。
常に計画があっているわけではありませんが、それを含めてPDCAを回していけると時間をよりよく使える気がします。
ちなみに、Todo管理には「Jooto」、毎日やるべき作業や習慣には「Habitica」を使って管理するのが好きです。
ポモドーロテクニックを使う
計画に関係する話なのですが、最近はポモドーロテクニックという考え方を使って仕事しています。
簡単にいうと、仕事は25分間とにかく集中して5分間休むのがいいという方法です。このサイクルを1ポモドーロのカウントします。
このテクニックのメリットは集中力を継続できることと、1ポモドーロが30分になるので自分の作業量をカウントしやすいことです。
ちなみに、一日10ポモドーロできれば、いいほうだと聞いています。
ポモドーロテクニックと計画を組み合わせることで、集中力は大分維持できるようになった感じがあります。それに定時を意識するより、短い時間を意識したほうがモチベーションが切れにくいですね。
ちなみに、プログラミングだけは50分集中して10分休憩というサイクルのほうが好きです。
PDCAを回す
最近はPDCAの本を読んでいて、PDCAを回すように意識するようになりました。
下記の本は両方面白いのでお勧めです。
大事なことはまず思いついたアイデアを全部書きだして、見直せるようにすることです。
ここが改善できるんじゃないかと思ったら、とりあえず書きだしておいて時間のある時に振り返ります。
また、改善案は必ずアクションまで落とし込んで、Todoリストにどんどん入れていきます。これを仕事に組み込めると少しずつ質が良くなります。
まとめ
こうやって見返してみると、自分でも大したことをしていないなという感じがします。
しかし実感としては集中力を高く保ちつつ、仕事の質を改善できているのであえて記事にしてみました。
なんでも見えるようにして、改善を続けていくというのはやはり大事ですね。
このまま改善を続けていって、もう少しいい習慣ができたらまた書きます。
Linuxを1か月勉強してみた
年末くらいから、新しくLinuxの勉強を始めました。
自分の会社は開発環境、サーバーともにWindowsにロックインする方向に向かっていて、Linuxはほとんど触った経験がありません。
しかし、Web業界ではむしろLinuxのほうが主流ですので、心機一転ということでLinuxの勉強を始めました。
これから同じようにLinuxを触ってみたい方もいるかもしれないので、参考にやってきたことや感想を書きます。
学習したこと
学習したことは以下のようなことです。
Linuxを勉強したというよりは、シェルを勉強したというほうが近いです。
勉強方法
ドットインストールを見ながら打ちこむ
まずは、ドットインストールの下記の講座を見ながら、実際の環境で動かしました。
基本的には浅い内容ですが、導入としては役に立ちました。Vimに関してはvimtutorだけで十分かもしれません。
本を読んで足りないところを補う
あとは本を読みながら、もう少し詳しいところを勉強しました。勉強するときはWebページより本のほうが好きですね。
色々買いあさってみましたが、よかったのは次の2つです。
Linuxといいながら、ほぼBashの本です。とにかく説明がわかりやすく、振り落とされるということがないですね。
実際にコマンドを打っている感覚に近い感じで読めます。値段は張りますが、基本を学ぶのであればこれで間違いないと思います。
シェルスクリプト、正規表現、Vimといった関連が深い分野についても章を割いているのもいいですね。
Vimの本です。実践というだけあって全く入門には向いていません。
基本的なコマンドを覚えた今でもやや難しいですが、Vimらしい思考法を教えてくれるため、Vimを学ぶのであればぜひ読んでほしいです。
Vimはどうやってコマンドを組み合わせていくか? というところが問題になるので、コマンドを覚えただけではまだ入り口のおうです。そこから1歩踏み出せる本です。
環境構築
勉強中は実際にコマンドを打ったり、スクリプトを書いたりしました。
Linuxをインストールするのではなく、Windows上でVirtual Boxを使って仮想環境を作って、そのうえで勉強していました。
PCにインストールしてしまうと戻すのが大変なので、不要なPCがない限りは仮想環境で勉強するほうがいいと思います。
ディストリビューションは軽量でありつつ、GUIがあるLinux Mintを使いました。マシンスペックがあれば、Ubuntuでもよかったかなとは思います。
あとはWindows10が手元にあれば、Bash on Windowsという選択あるかなという気もします。
環境構築は全面的に以下のサイト様を参考にしました。
sstea備忘録 : VirtualBox で Linux Mint の仮想環境を構築する
感想
学習曲線が急
Vimが特に顕著な例ですが、Linuxはすぐに誰でも使いこなせるという感じではないように感じました。
細かい道具がたくさんあってそれを組み合わせて使っていくという感覚で、まずは道具を覚えていかないといけないという印象です。
ただ、道具を使いこなせるようになったら、自分の好きなことはなんでもできる? という印象を受けました。
なので、好きな人はいくらでも好きになれるOSなのですが、技術に興味がない人にとってはなかなかハードルが高いOSだと思いました。
かゆいところに手が届く
上記の話に近いのですが、Linuxだと簡単なことを簡単にできます。
例えば、「CSVファイルを検索して、特定の列から特定の行を取り出して集約する」という処理をLinuxであれば、awkではパパッとかけそうな感じでとても面白そうだと思いました。
WindowsであればExcelで頑張るか、Visual Studioを立ち上げてC#でスクリプトを書くかでしょうが、簡単な処理に無駄に時間をかけている感じが否めません。
こういった思い通りに操作できるというのがとても魅力的です。
裏の仕組みがわかる
GUIになれると裏で何をやっているかがブラックボックスになります。基本的にはそれで問題ないのかもしれませんが、エラーが起きたときや問題にぶつかった時に対応できません。
Linuxを触っていると自分で一つずつ処理を打っていくので、勉強になります。GUIを使うとしても、一度CUIの文化になれると理解度が変わります。
今後
MySQLやNginxを入れて、何か作れたらいいなと思っています。
またもう少しLinux内部の仕組みもさらっと学べていければいいなという感じです。
まとめ
Windowsしか触ったことがない開発者であってもLinuxに触ってみると勉強になります。一度体験してみるといいと思います。
寄せ書きについて
前書き
最近はずっと、LinuxとかGitの使い方といった環境面の勉強に終始しているので、あまり人に伝えれるような進展はありません。
なので、自分の趣味の一つである寄せ書き集めについて、振り返るエントリーを書こうと思います。
卒業祝い、結婚祝い、退社祝い、遠くに行った友達にメッセージを送りたいという人の参考になればうれしいです。
これまで関わったもの
まずは、これまで関わったものについて書きます。
- 色紙
- メッセージ人形
- フォトブック
- 動画
- メッセージブック
色紙
定番すぎて説明は不要かと思いますが、寄せ書きといえば色紙というイメージがあるくらい有名です。
色紙の何がいいかといえば、手軽さです。寄せ書きで色紙を用意して文句を言われることはないでしょうし、値段も1枚あたりに大して値段をかけなくて済みます。
さらに書くほうとしても2~3行のメッセージでいいので、お手軽です。寄せ書きをとりあえず作りたいという人は色紙がいいと思います。
ただ、寄せ書きは不特定多数の人に書いてもらうのに向いていません。東京、大阪、名古屋というように書いてほしい人がちらばっているとかなり手間になります。
学生はそんなことはないと思いますが、社会人の場合はよくある状況です。
さらに絵や表現がうまい人にとっては、デザインの幅が少ないです。スタンプ、マスキングテープ、印刷、シールといったあらゆる手段を使いにくいです。
なので、本気で誰かを祝いたいという場合は、寄せ書きでは限界があります。
さらに言うと色紙は伝統行事的なものなので、大体渡す前にばれています。そのべタさがいいという人もいるのかもしれませんが。
男子が多いとか、とりあえずで済ませたいという人以外は、もっと良い手段があるのではないかと思います。
メッセージ人形
女子の先輩が卒業する際に送りました。自分が主導したわけではないです。
先輩はずいぶん喜んでいたので結果的にいいとは思うのですが、個人的には色紙と同じ理由で好きではありません。
とはいえ、色紙よりはまだ意外性という点で評価してもいいと思います。
フォトブック
留学に行っていた同級生のために、とある人が企画してフォトブックを渡したことがあります。
写真がメインで、ところどころに空いたスペースにみんなでメッセージやイラストなどを書き込みました。
写真を使っている以上色々なデザインができますし、個々人ができるデザインもそれなりに幅があります。できないのは、印刷くらいでしょうか。
ある程度適当に作っても見せれるものが作れますし、それなりにいい方法だと思います。
詳細は聞いていませんが、フォトブックを作ってくれるサービスは巷にたくさんあるので、それを使ったと踏んでいます。
それでもいいですし、適当な画用紙に写真を張るのもいいですね。
ただ方法によりますが、不特定多数に弱いという欠点は解消されていません。また、編集者のセンスの裁量が大きく、みんなで作ったという感じにはなりにくいのが少々ネックですね。
手軽さとデザイン性のコストパフォーマンスはなかなかいい選択だと思います。
動画
同級生の結婚式と、後輩の卒業式で2回見ました。
その瞬間の破壊力というか、感動を誘えるという点では、動画がもっとも優れた手段だと思います。
思い出の写真を音楽に乗せて流したり、同級生で協力して踊りを踊るといった動画を見たことがあります。どちらもかなり手間がかかっているのがわかり、とてもよかったです。
手間と技術、アイディアが必要で、とても難しいですが、挑戦する価値はある分野だと思います。
ただ、編集者の裁量が大きすぎること、一人一人のメッセージが伝わりにくいのが難点でしょうか。
全員の気持ちをちゃんと伝えたいのであれば動画はどうかなぁと思います。
メッセージブック
フォトブックに似ていますが、こちらははがき大の白紙の用紙をみんなにくばって自由に書いてもらうという形式です。
つまり、デザインは全部相手任せというやりかたです。自分は印刷もできる紙を選んでいました。
集めた用紙はポストカードを入れるアルバムに入れて渡すのが無難かと思います。
自分は製本してひもで縛るという形式を取りましたが、気持ちを伝えるという意味ではとても効果がありました。
メッセージブックは用紙を郵送でやり取りするだけでよい、枚数をいくらでも増やせる、デザインは完全に自由、という点で自分は一番好きな方法です。個性がずいぶん出ます。
女子とか、デザインが好きな人が多い場合はこれがベストかなぁと思います。ただ、他の参加者の忙しさや、情熱を加味して、フォトブックもいいかもしれません。
これからやってみたいこと
- トランプ
- 名刺
- Webサイト
トランプ
トランプでもカルタでもなんでもよいのですが、無地のカードが売っているのでそれを買ってきて表面に自由に書いてもらいたいなぁと思います。
ただ実際買ってみると、トランプはかなりツルツルだったので、にじむのが少し怖いかなという感じです。
あとは、印刷ができない、各種ペンが使いにくいので、結婚式の2次会くらいが適当な気がします。
事前に時間があるのであれば、データを送れば作ってくれるサービスがあります。ただ、個人的には手書きの良さが出せないので、少し躊躇します。
売り上げランキング: 5,628
名刺
名刺は裏表を十分に使いやすい、用紙がたくさんある、印刷できるという点でかなり優れていると思います。
しいて言えば、メッセージ欄が小さくて少し難しい気はしますが、裏表を使えば何とかなるのかなという感じです。
あとは結婚祝い、卒業祝いであれば、名刺入れと一緒に贈ることができるというのがとてもいいですね。
たくさんメッセージを書きたければメッセージブックがいいでしょうが、それ以外なら名刺はなかなか面白いと思います。
売り上げランキング: 847
Webサイト
手間はもっとも大変ですが、Webサイトでフォトギャラリー、メッセージギャラリーを作ってみたい気持ちはあります。
寄せ書きのサービスはすでにあるようですが、手書きの良さを超えていない感じがぬぐいきれていないので、それならほかの手段のほうがいい気がしています。
いつまでホストするのかとか、手書きよりもいいものができるのかというところが課題ですが、デザイン次第では可能性がある気がします。
技術者の方であれば、挑戦してみたら面白いと思います。
これまでに行ったサプライズ
ディズニーのサイン
メッセージカードの中に何枚かディズニーキャラクターのサインを入れて、驚かせたことがあります。
ミッキー、グーフィーあたりは並べばサインしてもらえるので、頑張れば必ず手に入れることができます。
相手がディズニー好きなら、結構喜んでもらえるのではないかと思います。
似顔絵
似顔絵は最近は写真さえあれば、書いてもらえます。
自分はFacebookあたりから写真を拝借したり、他の人へのサプライズの際の動画を借りて、Webサイト経由で似顔絵を書いてもらいました。
全員が似ていたかといわれると微妙ですが、特徴はつかんでいたので喜んでもらえました。
Web経由でなくとも、イベントで似顔絵を書く人を捕まえたり、店を持っている人に会いに行ってもいいですね。
まとめ
どうでしょうか。意外に寄せ書きを集める表現方法はあることが伝わったでしょうか。
自分は女子が多い学科出身なので、できるだけみんなの表現を生かす方法はないかなーと考えながら、寄せ書きを作ってきました。
なので、そこらへんを生かすような方法は伝えられたかなと思います。ぜひ、大事な人を喜ばすために色々考えてみるといいと思います。