-1×-1 = 1
イントロ
を見た。
- 厳密な証明じゃない(と思う)
- ちゃんとやろうとすると群論とか出てくるのかもしれない
- そもそも間違ってるかもしれない
と色々言い訳しつつ、自分は以下のように理解している。
証明(?)
1
ここがスタート。
0 に何を掛け算しても 0 になる。よって -1 をかけても答えは 0 になる。
この等式は正しそう。
2
0 を展開して、1 - 1 とした。
3
を
と変換している。
学生が教わる時はこう教わるので、直感的には理解しやすい。
(厳密にはこの展開は眉唾である。ところが、この変換は引き算の定義によるものらしいので、やっぱ正しそう)
4
分配法則を使う。
分配法則は証明が楽だから、もし分配法則がわからなかったら説明する。
5
3 式の左辺の一項目は
である。
1 に何を掛け算しても、掛けた数になる
6
移項したら 1 になった。
まとめ
胡散臭いところもあるけれど(3 の辺りとか)、中学生ならわかる説明で、 を証明した。
分配法則、移項を習ってれば理解できる...と思ってる。
将来子供に質問されたら、こんなふうに答えるつもり。
自分も時々忘れてしまうから、ここに残しておく。
そもそも子供ができるかどうか、という命題があるが、これはは証明できないです。
参考
「UNIX という考え方」を読んだ
読んだ。
- 作者: Mike Gancarz,芳尾桂
- 出版社/メーカー: オーム社
- 発売日: 2001/02
- メディア: 単行本
- 購入: 40人 クリック: 498回
- この商品を含むブログ (137件) を見る
近視眼的な点で述べるなら、ライブラリを自作する際の設計指針になりそう。
本質では無いが、本を読んで気になった点があったので書いてみます。
階層的に考える
UNIX のディレクトリ構造が階層構造であるように、自然の秩序も階層構造である。
UNIX の階層構造が自然を反映しているということは、おそらく階層構造が優れたアプローチであることの証拠といえるだろう
一番気になるのは
- 何故 UNIX は階層構造なのか
- 何故階層構造で説明できるのか
- 何故階層構造は理解しやすいのか
ということ。
当時 UNIX を作った人が階層構造の凄さを最初から理解していたかというと、きっと違うのではないか、と思う。
論理を飛躍した発想があった？とか、作っていくうちに自然と進化していった？等と想像する。
そうそう。本に述べられてないことで、ちょっと脱線するが「名前付け」も重要な着想だと思う。
普通に考えるならば複数の名前が
具体的には alias や group 等が当てはまる。chef や capistrano で言う role とかもそう。よく言う「タグ付け」もそう。
群衆に別名を付け、それをまとめあげる。これも UNIX の世界ではよく見受けられる発想に思える。
しかし階層構造と同様に「名前付け」が何故理解しやすいか、物事を説明できるか、は(私が)よくわかってない。
何が言いたいのかというと「階層構造」という概念って不思議やね、ということでした。
おまけ
自然の秩序も階層構造、の具体例として 「4 つの力」がある。
4 つの力とは 重力、電磁力、強い力、弱い力のことだ。
学習する時は別分野でとして学習する。だが次第にこれらの概念が一つになっていく。
不思議。
ところで階層構造って普遍的(のようにに思える)な概念だということに気づいたのは、大学3年ぐらいだったように思える。
もっと早く教えてくれればよかったのに
(早く気づいていたら、もっと勉強ができるようになっていたと思う)
Music as code
イントロ
Extempore というソフトウェアを触ってみた、という話。
コードを書くことで作曲できる、というシンプルでインパクトの強い特性を持ってます。
とても面白くて魅力的だったので共有。
Extempore is 何？
- 作者曰く
cyberphysical programmingらしいExtempore has its roots in 'live coding' of audiovisual media art- extempore で辞書を引くと「即興的な」という意味の形容詞(副詞)だった
- 要するに「ライブコーディング即興コンサート」できる
xtlangというプログラミング言語の実行環境- バックエンドに LLVM を使ってる
xtlang is 何？
- 高レイヤーは scheme
- 低レイヤーは C
という言語。CRuby と似てる。
インストール方法
homebrew 使ってるなら以下で一発
brew tap benswift/extempore brew install extempore
これだけだとまだ使えなくて
cd /usr/local/Cellar/extempore/0.xx ./compile-stdlib.sh
を実行する必要がある。
extempore を install し終わった後、ターミナルに説明が出るので見逃さないようにすること。
editor の準備
vim は知らない。
なお、extempore.el は Github から入手してくる。
load-path に置いて、extempore-mode が使えるのであれば、準備は OK。
(vim に対応したファイルもあるっぽいから、ひょっとしたら対応しているのかも)
実行法
予めサーバーを立ち上げておく
cd /usr/local/Cellar/extempore/0.xx ./extempore
デフォルトだと TCP サーバーが port 7098 と 7099 で待ち構える。
あとはこの TCP サーバーに S式を送れば良い。
後はサーバーがコンパイルして、評価してくれる。
送り方は以下
- emacs 開く(extempore-mode を on にする)
C-x C-j(M-x extempore-connect)- S式を評価する
C-x C-eでもいいし、region を指定してC-c C-rでも良い
簡単なんやで。
音を鳴らす
自分が作った適当なサンプル
(sys:load "libs/external/instruments_ext.xtm") (define-instrument synth synth_note_c synth_fx) (bind-func dsp:[SAMPLE,SAMPLE,i64,i64,SAMPLE*]* (lambda (in time chan dat) (synth in time chan dat))) (dsp:set! dsp) ;; Simplest pattern (play-note (now) synth 60 120 80000) ;; 半音階 (dotimes (i 13) (play-note (+ (now) (* i 5000)) synth (+ 60 i) 120 8000)) ;; Scale (let loop ((scale '(0 2 4 5 7 9 11 12)) (dur (map (lambda (n) (* n 10000)) '(1 1 1 1 1 1 1 4))) (time 0)) (play-note (+ (now) time) synth (+ 60 (car scale)) 120 (car dur)) (if (not (null? (cdr scale))) (loop (cdr scale) (cdr dur) (+ time 10000)))) ;; cadenza (define play-cadenza (lambda (time plist) (map (lambda (p) (play-note time piano p 180 40000)) (car plist)) (if (not (null? (cdr plist))) (callback (now) 'play-cadenza (+ time 40000) (cdr plist))))) (play-cadenza (now) '((41 53 62 65 72) (43 55 64 67 72) (31 43 62 65 67 71) (36 48 60 64 67 72)))
肝は play-note という関数。これで音を鳴らす。引数は全部で 5 つ。
- 第一引数: time
- いつ音を鳴らすか
- 第二引数: instrument
- 楽器の名前
- 第三引数: pitch
- 音程
- 60 が真ん中の ド
- 以後、半音上がるごとに +1 される
- 第四引数: volume
- 音量
- 第五引数: during
- 音の長さ
終わり
以上、Extempore Documentation に大体書いてあることでした。
実際に触ってみると、ドキュメントには言語仕様が十分乗ってなくて、わからないことだらけ。
そんな時は extempore/extempore_lang.xtm at master · digego/extempore に置いてあるサンプルを頑張って読んでいくのが良さそう。
後、楽譜をコードに落としこむのは結構大変。
そういう使い方ではなくて、ランダムな音程、リズムを即興で出すことには優れていて、本当にそれっぽいく聞こえる。すごい。
責任を明らかにすると安心する人
小さいころの経験談だが、学校の先生が「誰が誰々を泣かせた」と言って、学級委員会を開いた。
それで帰りが遅くなり、毎度イライラしたものだ。
その委員会で、先生は犯人を見つけて叱る。それで終わり。何の意味があるのだろう？
泣かせたのが問題だとしたら、理由を聞いて、今後は同じことが起こらないようにすべきでないだろうか。
会社に入っても同じことが起きている。
「どこ」に問題が起きているかより、「誰が」問題を起こしているかを非常に気にする人種がいるのだ。
理由を聞くと「顧客に説明できるから」だそうだ。
うちが障害の原因じゃないということを、説明したい、とも言っている。
何故、それが説明になるのか？ そのように説明することが、顧客にとって何のためになるのか？
当然の疑問を誰も口にしない。不思議だ。
何が起きているの？ に対する回答が、「どこどこで障害が発生しておりまして…」とは、一見説明になってるように思えるかもしれない。
けど、「で、だから何？」と思われないのだろうか。
顧客が知りたいのは、じゃあそれがいつ頃復旧するの？ ではないだろうか。
少なくとも「誰が」ではない。何時？もしくは何故？だろう。
それでまかり通ってるのが不思議だ。あるいは通ってると思い込めるのも。
頭がおかしいのかもしれない。自分が。
wdired.el を使おうとすると、Symbol's value as variable is void: directory-sep-char が出る件
イントロ
emacs 23.4 → emacs 24.3 に update して wdired.el を使うと、タイトルの通りエラーが出た。
詳細は以下
ls does not support --dired; see `dired-use-ls-dired' for more details. wdired-change-to-wdired-mode: Symbol's value as variable is void: directory-sep-char
こんなこと言われる。
解決法
お使いの wdired は古いので、すぐさま削除し、24 に標準搭載されている wdired を使いましょう。まる。
おまけ
こういうパッケージ管理的な事を怠っていたツケですね。
使ってた wdired.el がこちら。
;;; wdired.el --- Rename files editing their names in dired buffers ;; Copyright (C) 2001 Juan León Lahoz García ;; Filename: wdired.el ;; Author: Juan León Lahoz García <juan-leon.lahoz@tecsidel.es> ;; Version: 1.9.2pre3 ;; Keywords: dired, environment, files, renaming ;; wdired.el is free software
2001 年... だと...!?
ruby の Thread に関する不思議な現象
イントロ
第19章 スレッド を見てやってみました。 が、うまくいかない。
わかる
% cat thread.rb Thread.fork { while true puts 'forked thread' end } while true puts 'main thread' end % ruby thread.rb #=> forked thread forked thread forked thread main thread main thread forked thread forked thread
混ざって出てくる。
わからない
% irb Thread.fork { while true puts 'forked thread' end } while true puts 'main thread' end #=> forked thread forked thread forked thread ...
irb, pry などでコードをコピペすると混ざらない。
言いたいこと
なんでこうなる？ 何故挙動が違う？
やったこと
@scanner.each_top_level_statement do |line, line_no| signal_status(:IN_EVAL) do begin line.untaint @context.evaluate(line, line_no) output_value if @context.echo? exc = nil rescue Interrupt => exc rescue SystemExit, SignalException raise rescue Exception => exc end
この辺りで line を input として受け取って、 eval して、 output している。問題は出力部分。
def output_value # :nodoc: printf @context.return_format, @context.inspect_last_value end
output_value で、printf している。特に port 指定はないので、標準出力されているはず。
- thread について調べまくった
- 結論は「IO 待ちが発生するなら Thread が入れ替わる(なはず...)」
- つまり printf なら僅かながら IO 待ちが発生するので、出力は混ざるはず。
現在
- 解せなくて気持ちが悪い
環境
初めてEMR(Amazon Elastic MapReduce)を使う人が読むページ
イントロ
仕事で EMR を触っていて知見が溜まってきた気がするので、output していきます。
今後記事を連載する予定。
この記事では EMR にまつわる巨大な背景を説明します。
個別に検索すればもっと詳しいページはゴマンとあります。
ただそれらが EMR とどう関係しているのか、というのはあまり見かけなかったので書いてみました。
あ、コード一行も出てきません。
目次
EMR って何？
全体像
こんな感じ
出典元: What is Amazon EMR? - Amazon Elastic MapReduce
構成
EMR を起動するとどうなる？
- EC2 インスタンスが起動する
- Hadoop 実行環境が自動で install される
- s3 に配置されている input 用データを読み込んで、処理が行われる
- (何かの処理を実行)
- 処理が終了後、s3 に結果を自動で upload
- EC2 インスタンスが terminate する
基本的には起動したクラスタは Terminate されるので、よくわからないうちに、料金ががが... ということにはならず、安全に利用できるようになっている。
気になる一回あたりの料金は...
当然処理の内容によってまちまち。
けど以下の料金の合計が一回あたりに Amazon に支払う金額である。
- S3利用代金
- EC2 インスタンス利用料金
- EMR 利用料金
重要なのは EC2 インスタンスの料金 + EMR の料金がかかるという点。 EC2 の上に hadoop を乗っけて処理を行うので、EC2 の利用料金とhadoop を動かす料金を支払います。
料金 - Amazon Elastic MapReduce（Hadoopクラスター Amazon EMR） | アマゾン ウェブ サービス（AWS 日本語）
EMR の長所短所
どんな時に EMR 使えばいいの？ どうして EMR を使うの？という話ですが、当然個人のユースケースによります。
「うちはこれがやりたかったから EMR を使った」というだけで誰もが使って幸せになれる万能ツールというわけではありません。
そこで個人的に考える長所短所をまとめてみました。
これらを眺めてみて、やりたいことにマッチしていれば、試しに使ってみるで良いかと思います。
長所
- サーバーを自前で用意する必要がない
- 自前で頑張るとめんどいので、それらから開放される
- 故障した時どうする？
- サーバー拡張するときどうする？
- サーバー買うと一気にお金すっ飛ぶ...
- セットアップする人的リソース、時間
- 試しに使ってみたい時というユースケース
- 自前で頑張るとめんどいので、それらから開放される
- AWSサービスとの連携
- S3 を始めとした AWS 一式を一緒に使える、処理に組み込める
- Hive, Pig, mahout などのツールの手厚いサポート
- ソフトウェアの更新を自分でやる必要がない
- Amazon 任せにできるので手間が減る
- version が古すぎるということはない(個人的な感想)
- 簡単に使える
- GUI, CUI どっちもござれ
- サポート加入すればわからないこと聴き放題
- money, money, money だけど...
短所
- デバッグ大変
- 簡単に使える ≠ 簡単に使いこなせる
- デフォルトでは自動で terminate されるため
- 良くも悪くもインスタンスに乗っているソフトウェアは、Amazon 任せ
- ruby が 1.8.7 だったり...
- (頑張れば変えられるけど、起動時間がさらに伸びる)
- インスタンスのスペックがある程度固定
仕事で使った時
以下の様な事を考えて EMR + Hadoop Streaming を選択しました
- 大規模なデータを処理する際に、既存のサーバーに付加をかけたくなかった
- 長い間処理すると、当然その分付加がかかっている状態は長く続く
- データのダウンロード、アップロードで回線圧迫
- よくない
- 処理時間の短縮したかった
- できれば処理時間は短いに越したことはない
- サーバー調達、セットアップに時間がかかる
- 自社でサーバー購入する → 時間かかる + めんどい
- じゃあ AWS でサーバー建てる？ → それ EMR でいいんじゃね？
- かなり複雑な処理をする予定だった
- Hive のような簡易言語を使えない
- Java を使える人が少なかった
- ruby の会社なので
色々あって、今振り返ると別に EMR 使わなくても... というのもあったりしますが、それは別の話。
Hadoop って何？
さっきから Hadoop という単語が出てきますが、これって一体何？って話です。
- 分散処理をしてくれるソフトウェアのこと
- MapReduce とは hadoop が行う分散処理のこと
- 実際は Map 関数と Reduce 関数を、あるルールに従って書くだけで良い
- 後はよしなに複数台のサーバーで分散処理をしてくれる
- 入力ファイル → (hadoop) → 出力ファイル
- 基本的には、動作はバッチ実行
- 「こういう結果がきたら MapReduce を行って、そうでない場合は行わない」のような条件分岐は苦手
- できなくはないけど、ちと面倒
- Master/Slave アーキテクチャ を持つ
- 親サーバーのことを MasterNode と呼ぶ
- 子サーバーの事を SlaveNode(= CoreNode) と呼ぶ
出典元: What is Amazon EMR? - Amazon Elastic MapReduce
構成
一口に Hadoop と言っても
のような layer がある。順に説明する。
HDFS
- Hadoop Distributed File System の略
- 公式
- Hadoop で使われる独自の分散ファイルシステムのこと
- Master/Slave アーキテクチャ
- 複数のサーバーに置かれてあるファイルを、ひとつのサーバーに置かれているものとして取り扱えるもの
- 「どのサーバーにどのファイルが置かれてある？」という事を一切気にしないで良い
- 巨大なデータを配置するのに適したアーキテクチャである
- EMR では s3 が HDFS の役割を担ってくれる
- EMR の強みポイント、その1
- s3 にファイル置いておけば、EMR はそのファイルを自由に参照することが可能
- HDFS の構成
- NameNode
- MasterNode が使う Node のこと
- 責務は DataNode の管理
- 多数の DataNode がどのようなデータを持っているかを知っている
- DateNode
- SlaveNode が使う Node のこと
- 分割されたデータを実際に保持していて、編集などを行う
- NameNode
Hadoop
- MapReduce 処理を行うメインの Application のこと
- MasterNode の責務
- CoreNode の Task の管理を行う
- CoreNode が生きている？死んでいる？など
- どの CoreNode に Task を割り当てるか
- 実際に Task の管理を行う人を JobTracker という
- CoreNode の Task の管理を行う
- SlaveNode の責務
- 実際の map/reduce 処理(Task)を行う
- MasterNode に成功などの結果を通知
- 実際に Task を実行する人を TaskTracker という
- Hadoop は Java で書かれている
ツール層
まとめ
EMR とその周辺の話をまとめてみました。
長くなってしまいましたが、それだけ色々な技術が積み重なって EMR が生まれたってことですね。
冒頭にも書いたとおり、詳しい話はググってみたり、公式のリファレンスを参照してみてください。
kinesis 買って二週間経ちました
イントロ
仕事しだしてから、手首が痛くなってきたので買っちゃいました。 二週間使ってみての感想とか。
やったこと
キーバインディング変更は以下のとおり。
- backspace → ⌘
- delete → alt
- end → enter
- home → space
- 左パイプ(insert) → backspace
です。
左親指のキーバインディング変更が主ですが、なるべく現環境の指使いを維持したままキーをタッチできるように変えたつもり。
指使いって何よ、というと例えば copy する時、どの指でキーをタッチするか、という話です。
私は「 ⌘ + c 」を使う場合が多く、その時は左親指(⌘) + 左人差し指(c) で取ります。
kinesis だと「backspace + c」だと、親指 + 人差し指でキーを自然に押すことができます。
今度も Remap を行うことで、自然とそういう指使いができるように配置しました。
それが一番乗り換えコストが少ないと踏んだからです。
KPT
本来ならば KPT ってこういう時に使うものではない気がするけど、やってみた。
個人的に重要だなと思う部分は強調してあります。
K
- 手首の痛さ軽減
- これを一番の目的に買って、それが達成されたのが良い
- エンターキーを押すとき手首を若干外側に開く癖があり、それをやらなくなったのが大きい。
- kinesis だと左親指にエンターキーが配置されているから。
- 案外すぐ慣れる
- 結構意外
- 1日目で辿々しいブラインドタッチ。2日目で使用頻度の低いキーの配置を覚える。三日目からはゴリゴリ使えるようになった
- それに今まで使っていたキーボードが全く使えなくなることもない
- 案外人間は体で覚えているものだと感心した。
- 十本の指を全て使っている感がある。
- しかも使っていくうちに、自然と矯正されていく感がある。
- 正しい指使いになることで、手首の負担を軽減できる
- しかも使っていくうちに、自然と矯正されていく感がある。
- 話のネタになる。
- 誰しもが突っ込みたくなる(?)
- 注文後、届いたのが早い
- 1~2営業日くらいで届いた
- エクジン様での注文で
P
- 買う前に実機を触ることが出来なかった
- そのため、買うのが大冒険だった
- そしたら売ればいいし、ネタになるかも、という打算はあった
- ネットで探してみたが実店舗で置いている店はないらしい。
- 昔は秋葉原で置いていたらしいが...
- そのため、買うのが大冒険だった
- 赤軸にすればよかったかも、と思っているところ
- 今まで「赤軸ってなんだよ」という人だった
- 打鍵感まで拘る必要はないかなーと思ったのが、赤軸にしなかった理由。
- 打鍵すると「スコスコ」音がなる
- ハッキリ言ってここはイケてない気がする。
- 今まで「赤軸ってなんだよ」という人だった
- キーの間に隙間がある
- ポテチとか絶対入るパターンや...
- 高い
- ネタになるとは言っても、3.6 マソ(税込み)
- それだけの価値があると信じなければ、中々手は出ない。
T
- 他の有名なキーボードとかも機会があったら触ってみたい
- キーボードなどには今まで無頓着だったけど、手を出してみることで良い変化があった
- 更なる境地があるかもしれない
まとめ
改めて「指使い」重要と思いました。というのも、 kinesis がそうデザインされている(?)っぽいからです。
いつの間にか私は「このキーならこの指を使う」というのが固定されてきました
- 一番凹んでいる真ん中の列のキーは中指
- 中心の二列は人差し指
- 外側二列は薬指
- 一番外側は小指
中指が特に重要で、なるべく動かさないようにすると、本当にすぐ慣れます。簡単です。
手首が痛くなっている方は検討の余地ありかと。
買うと一日だけ人気者になれます。
大江戸 ruby 会議 04 参加した話
イントロ
タイトルの通り。行ってきました。
他の人もまとめてらっしゃるので、そちらのほうがわかりやすいです。
ここでは自分のメモを見ながら、もう一度頭のなかで再現する意味を込めて、書いてみました。
あ、全部書いてるので、めちゃくちゃ長いです。
それとまとめの粒度に差がありますし、内容の精度も保証できませぬので、ご了承ください(私の脳味噌スペック的な問題で)
他の方のまとめ
大江戸Ruby会議04参加しました！ スライド・リンクまとめ - 酒と泪とRubyとRailsと
大江戸 Ruby 会議04 に参加しました - Programming log - Shindo200
1."legacy" to the "edge".
Hiroshi Shibata さん
写真共有・保存サービス 30days Album の脱レガシー化の話
一年前
今
やったこと(一部抜粋)
- github workflow 導入
- version up の際に kage で動作確認
- rails 2.3 で、ほぼ 3.0 とほぼ挙動が同じにようにして update を進めていった
- rails 2.3 で delayed_job
- 今まではdeploy が怖かった
- 金曜に deploy しない、などのバットノウハウ
- kyototycoon は遅かったので書き換えた
- memcachd に(?)
- DB より遅かった
まとめ
- こまめに jump しましょうという話
- 技術的負債を一年貯めると、そこから脱却するのに二年かかるかもしれない
- そうならないように、日々少しづつやっていくしかない
2. "Infrataster - Infra Testing Framework"
Ryota Arai さんから、Infrataster の話。
- infrataster
- インフラを「味見する」の意味
- server の外側から、振る舞いをテストするもの
問題
- test 書いたけど動かないケースがある
- そもそもそうならないようにテストしたいよね
- 例えば「この url にアクセスした時、200 が返ってくる」のようなテストを書きたい
- それ infrataster で！
使い方
- github に書いてあるはず...
特徴
- capybara を使ったテストも書ける
- 途中で request の header を書き換えている
- mysql_query も投げられる
- mysql の user がいるかどうかをチェックできたり...
まとめ
- infrataster を使うと、テスト書いたけど動かないというケースは起こりえない!
疑問
- dog-fooding って何？
- 犬の餌？
3. Random Ruby Tips
Winston Teo さんから「30 random ruby and rails tips」
知らなかったこと
- classにto_proc メソッドを定義して、&クラス名 でプロックを呼び出せる
- source_locatonメソッド
- メソッドの実装の箇所を返すメソッド
- (reflection されている時どうなる？)
- ruby -run -e httpd . -p 8080 でサーバーが立ち上がる
- hhpd が無いとダメ
- rake notes でコメントを表示できる
- ただし comment を書くときは大文字から
疑問
- Openurl::Buffer.send :remove_const StringMax したら、全部 Tempfile に書きだすよ！ っていう Tips があったけど、デンジャラスすぎる...
4. Nobody Knows Nobu
Zachary Scott さんから Nobu さんの話
- アメリカンジョークが入ってた
- 喩え話的な話
- (英語聴きとるのに必死で、ジョークまでついていけてない)
5. 私は如何にして異国でエンジニアとして生き抜いてきたか
Leonard Chin さん
- 外国で働きたい
- いいことたくさんある
- けどやった人は中々いない
- 2つの問題
- 言語
- 足りない
- 学校に行った
- 試験、資格を取った(あくまでマイルストーン)
- 練習すればできる
- 就業
- 色々あるけど comunity 最強
- 言語
- 生き抜くためには
- 文化を学ぶ
- encounter(出会う)
- embranse(受け入れる、enjoy する)
- study(学ぶ)
- 生きている英語を学ぶ
- オススメは reddit
- 文化を学ぶ
疑問
- モチベーションの原点が気になる
6. 画像を壊すこと、OSS 活動をすること、その他
Shimpei Makimoto さん
- 画像を破壊することをやってる人
- (詳しい破壊の仕方は発表されてなかった)
- makimoto/glitched_string
- 文字列を破壊するメソッド
- OSS の活動
- @hsbt に煽られた
感想
- 謎に記憶に残ってる
7.RubyVM読んでみた
Kawamotoさん
まとめ
- なるほど、わからん 状態
- ruby のコア部分に対する勉強不足が原因
- C わからん
- メモリ確保とか、そのあたりの知識も不足している
- ret が並んでいると、どう便利なの？ という根本的なところがわかってない...
- ruby のコア部分に対する勉強不足が原因
感想
いい声- わからなすぎてモチベーションが上がった
- ついに C の荒波に揉まれる時がきたか... という意味で
- タイミング的に丁度いい
- 最近業務やプライベートでも ruby の実装以外も読めないと、きつくなってきたなぁと思い始めていたので。
8. Ebi & Aaron Patterson
@ebitwin さん
- communitiy
- conference
- keep ruby alive
最初の映像やばい。
まとめ
続いて Aaron Pattersonさん
AdquateRecord の話
- humanity
- don't want new feature
- static な部分を cache させ、より高速化
benchmark
- 70% fewer
- trade memory for speed
9. 1年かけてgemを1つ作りました
Kunihiko Itoさんが作成した rgitlog の話
- rails のアプリケーションで git の commit log を表示できるようにするもの
- 実演あり
- 実際に commit が反映されるところまで、ライブコーディング
感想
- ライブコーディング盛り上がる
10. RFC7159
Shyouhei Urabe さん
資料はこちら
Deeper look at RFC7159 the JSON // Speaker Deck
- JSON が RFC7159 で新しく変わった
- テスト沢山書いた
- 遅すぎて実用には耐えないもの
- strict だけど遅い
- ライブラリを使うのが現実的
- ただバグはある
まとめ
- JSON の文字として "\uD800" を含めないようにしたほうが、皆幸せになれる
- RFC7159 では valid だけれど、これを無視したほうが、parser の処理が早くなるから
11. bundler の話(タイトル忘れた)
Terence Lee さん。Heroku の中の人らしい。
- チームの紹介
- bundler 高速化
- not cacheable → cacheable
- more memory
- Marshal.load(File.read(gem.gz))(うろ覚え)
- large query
- mysql のクエリがとんでもなく複雑
- 5 分に一個の gem が誕生している
- run for volunteer
感想
- 英語ェ...
- Marshal.load(File.read(gem.gz)) なんてできるのか...?
- メモに書いてあったけど、今見ると胡散臭い
- 後で bundler の実装追っかける
- gz ファイルを Marshal 化して、それを load する(?) ってアイディアすごい
- これが本当にできれば確かに早そう
- cache の面でも通信の面でも
- 妄想ひろがリング
- bundler の API サーバーについて
- run for volunteer
疑問
- volunteer って言っているけど、OSS って言ってしまえば volunteer な気もする
- OSS と volunteer の
- どういう意図で「volunteer」って単語を使ったのだろうか？
12. Object Bouquet ～ 幸せの花束・RValue のきらめきを添えて ～
sasada家がペアプロして作った作品 「object_bouquet」の発表
object_bouquetとは
- object の関連性をブラウザで表示してくれるもの
- 特異クラスの話
- 正しくはメタクラスというらしい
- ruby under a microscope という本の紹介
- ruby の内部実装をざっくりと解説した書籍らしい
感想
13. Another language you should learn
Ken Nishimura さん
モチベーション
英語で interview したかった
- 英語で interview しないとジャーナリストとして生き残れない、という危機感
30際の時に休職しサンフランシスコの語学学校に行った
- 元々 toeic で 900 点くらいだった
- けど根本がわかってないと気づいた
- freiends というドラマを1000時間見た
- 1年後、日本人には無理だと報告した
- Tens of millions of words
- 言語学的に構造が違いすぎる
- 帰国後も勉強を続ける
悩んだこと
- 実際にどれだけうまくなっても、インタビューできるのか、わからなかった
- 前例が無かった。先生もわからない。
- 続けてると 5 年後くらいにうまくなるよ、という指標が欲しかった
まとめ
- 始める。遅すぎることはない
- 文化を学ぶ
- 動機を持つ
- 圧倒されない
- プロセス自体を楽しむ
感想
- 「実は英語でインタビューは取れるようになった」という結果がすごい
- それでもまだまだ、らしい
14. mruby hacking guide
Yuki Kurihara さん
- php に危機を感じた
- ruby conference に行ってみた
- asakusa.rb に参加
- みんな好き勝手やっている
- 自分も好きなことやってる
- mruby は cruby と違って blue ocean
- mruby のパフォーマンス改善の話(実際送った pull request など)
- String
- cruby の実装を真似ているらしい
- Hash
- Matz に先を越された
- String
感想
- わかりやすい
- C がよくわかっていない自分でも、なんとなく理解できた
- ノリが好きだ
15. Hacking Home
@amatsuda さん
一戸建て建てた時の話とソフトウェア開発との対比的な。
- 不動産運用
- 家賃とかは適当
- 値切られることを見越した家賃設定になっている
- 17 年ほどで原資回収できれば、かなり良い物件
- 会的信用は ggられる(フリーランスだと)
- インターネットでプレゼンスがあると、若干有利になる
- 借金ができる
- ウォーターフォールとアジャイル
感想
- 話聞きすぎてメモほとんど無し
- まとめた内容、大体プレゼンに書いてあった
- (後でプレゼン資料見ればいいやってなった)
- 見れるかどうかわからないけど
- 17 年で原資回収って長い
- 17 年間、線形に価値が下がっていけばよいが... とか考えてしまう
- さらに 17 年間安定した住居者がいれば
- そのリターンは、「安定していて、まとまった収入」という大きい物
- 大家さんって、ほとんど何もしなくてもいいんじゃね？って考えると、尚更魅力的
- 何事もトレードオフ
- 17 年間、線形に価値が下がっていけばよいが... とか考えてしまう
Ruby会議でSQLの話をするのは間違っているだろうか
Minero Aoki さん
- 並列DB, RedShift を触っている
- mapreduce 追悼
分散処理する → 分散処理マジムリ(めんどい)
並列DBとは
- 複数の DB を一つの DB として扱える
- 型がある
- shared nothing 型
- 複数台の DB に被ったレコードが無い
- (データが被る)型
- 複数台の DB に被ったレコードがある
- shared nothing 型
特徴
- node を増やせば線形に早くなる
- 標準 SQL 使える
- client からは 1 台見える
- open source はほぼない
- 1983 年から実はある(Tera data)
まとめ
最後
なげぇ...
間違ってるところがあれば、随時直していきます。
「学生のうちにやっておくことって何？」って質問
イントロ
新社会人向けの記事が多い中で、敢えて就活生に焦点を当ててみる
技術ネタはなし
立場上学生とよく話をするのだけれど、そこで
「学生のうちにやっておくことって何？」って質問されて、モヤっとした話。
中身
知るかハゲ。ってのが正直なところ。
好きなことしたらいいし、好きなことを「やっちゃダメ」と言われることも少ないと思う。
でもそれだけだとほら、世間的にアレだから、咄嗟に「お金がなくてもできることかなぁ」と学生に伝えた。
何故かと言うと社会人になったらお金がたまり、時間がなくなるからだ。
逆に学生のうちは時間があり、お金がない。
社会人になると時間を金で買うようになる。いい時間を、質の高いサービスを求めるようになる。
お金を払うことによって。
けど学生はそんなことは中々できない。だから工夫をこらす。
俺が体験した例を挙げよう。
冷え冷えペンタくんというゲームがある。ゲーセンにあるやつで、アイスをとるクレーンゲームだ。
しゃぶしゃぶのような形をした台があり、それが時計回りに回転している。しゃぶしゃぶ台の中心に穴があり、そこにアイスをクレーンで掻き出せたら、アイスゲットとなるゲームだ。
中学生くらいの時はずいぶん夢中になった。
どうしてかというと、あのハーゲンダッツがゴロゴロあるからだ。
ハーゲンダッツなんてバカ高いアイス、滅多に買わないし、買ったとしても食べるのが勿体無いくらいだ。
当時の感覚としては、ね。
でも冷え冷えペンタくんは、練習すれば 100 円でハーゲンダッツを取れるのだ。
300 円がたったの 100 円で！ すごくね！？
俺は「神だ！」と思ったね。
ハーゲンダッツのために、毎日ウェアハウスに通ってた時代があったくらいだ。
何が言いたいかというと、そういう体験は社会人になったら、中々経験できないということ。
ハーゲンダッツ食いたくなったらさ、普通はさ、コンビニに行って買ってくるでしょ。
大人はね。
けど学生は違う。
百円入れて、全神経を親指に集中させて、タイミングが来たら叩く。
失敗したら、何故タイミングを真剣に考察する。
それだけ 100 円は重かったんだ。
でもね。
これが学生ならではの経験なんだ、と後から思うんですよ。100 円の重み、価値。
ハーゲンダッツが神だと心の底から思えてしまう、感動やその思考が。
え？ 中学生の話なんてしてないって？
そんなことはないと思う。大学生でも似たようなことはあるよ、きっと。
今大学生だから気づかないだけで。
まとめると、お金がないから色々考えて、経験するだろうけど、その時に考えたことや行動したことは、やっぱ学生のうちにしか出来ないことなんだ、と思う。
まぁ何だろう。学生のうちにやっておくことって？の答えになってないよね、という話。
というかさー。学生のうちしかできないことなんて、実はほとんど無いんじゃないかな。無理だ、と思い込んでいるだけで。
(気のせい？)
結局時が来たら社会人になるんだからさ、今を考えられるだけ考えて、生きればいい。
禅問答になるけれど「学生のうちにやっておくことは何か？」を考えることも学生のうちしかできないのでは。
きっとそれは学生のうちにやっておくことなのではないだろうか。
結論
長すぎてよくわからないので。
- 「学生のうちにやっておくこと」って特になし。好きに行動したらいいし、好きなだけ考えたらいい
- 社会人になると時間はなくなるので、それを想像できれば自然と行動に繋がるのではないかと思う
- 個人的には「お金がなくてもできること」や「時間がかかること」をやるのがオススメ
- しかし学生のうち(というか若い内に)しか得られない、「感動」や「純粋」は確かに存在する
- それに如何に気づくか
- 具体的な方法論は持ってない
それだけ。
偉そうなこと言っているので、後で黒歴史になるパターン。
