■
当選したらこっちでも再開する。
はてなダイアリーから移行します
すごい理由があるわけではないですが、ホントなんとなく。
仙台Ruby会議02に行ってきた
- 途中から(牛タンにより)
Ruby起業家を8年こなしてわかった5つのこと
- @xibbar さん
田舎親方の2つの道
- 先生
- 個人事業
- 製品プロバイダ / サービスプロバイダ
- 中小企業
- 受託開発を一生やれない
- と思ってる
開発が得意な会社?
- 営業が得意な会社は、常に売れる製品を探している
- 開発会社はだいたい営業が不得意というかちゃんと出来ない
代理店営業をする
- やりたくない {営業・サポート} をしなくていい
- 売上山分け
- バージョンアップサポートはする
- 代理店のことを考える
- 分け前をケチッてはいけない
田舎と都会の決定的な違い
- 人口差が尋常じゃない
仕事
- とってくる or 生み出す
自分の土俵で戦う
- 東京の土俵で戦うと負ける
- 価格とかしかない
- 土俵を福島にするにはどうすべきか
- ビジネスは、販売会社・顧客・開発会社
- 受託開発に疑問が残った
- ノウハウしか残らないのは苦しい
- これは自転車操業?
- リスクマネジメント重要
- 減らないものを貸す
- 商工会議所の会報にe-安否の広告を出した
- 上司の目につくようなところがいいんじゃ?
- 反応なし><
- Google AdSense に出したら反応良かった
- 広告でパートナー企業が釣れた!
- 代理店営業のニュースタイル <- いまここ
- 「発注者の悩み」 by recompile.net
- 発注者が自分の責任でシステムを完成しなければならないところ
- 販売会社の悩み
- バグ対応とかバージョンアップとか
- 開発会社の悩み
- ノウハウしかないし、次が来ることを祈るしかない
- 共同製品を作るのだ!
- 営業を持たずに自社製品を持てるのが利点
- 受託開発に疑問が残った
社長と職人のはざまで、、
まとめ
- 開発会社でも営業は必要
- 社長が営業すべし
- 親方は楽しい
- 好きな仕事できるのがいいし、人生を自分で使える
- 親方は大変
- 何でもやらないといけないので
- 5つのこと
- 動機・目標・売り方・自社製品・3つの人格
初期の不安と今
- 来月からの仕事の不安はなくなった
- 来年まで会社が持つかなという不安も亡くなった
- 不安による腹痛に慣れた
- これは一生の付き合いらしい
失敗した話
- 烏合の衆になるとヤバイ
- いろいろ気をつけよう
- インキュベートルームはいろいろ注意が必要
Q&A
- 本人ごと納品
Rubyの教えてくれたこと
- 社長(@nay3)
会社を作る「計画」はなかった
- 想定はしていた
- 一山当てたい
- バカバカしいことから開放されたい
- 自分でやればよくね?
会社を作る?
- 一人で作る気はなく、二人以上でないと意味がない
2006年の暮れ
- "いや、きっと出来るよ"
- 2007.4.2 設立
起業の原動力
企業してよくなったこと
- 仕事とお客さんを選べるようになった、いい意味で
気をつけていること
- お客さんに技術用語で迫ってはいけない
- What にも踏み込む
- 画面にも踏み込む
- とにかく踏み込む
- 開発の動機を丸投げするようなお客さんは避ける
Rubyと万葉設立の関係
プログラミングで食べられる!
- ニーズをうまくつかむことと、うまく使うことで、やっていける!
Ruby親方会議 in 仙台
- かなり豪華なパネリストによる討論会のような感じ
- 地方でやるか東京に出るか
- いろいろ問題がある
懇親会
まとめ
やはり地域Ruby会議にはみんな行くといいとおもう。各地の人たちとの交流が楽しいと言うのもあるけど、私にとっては、それぞれの場所でいろんな考えがあることで、自分の中にあるもやもや感がなくなると言う利点もある。これは東京にいては感じ取れない点。日本語通じる場所なんだから、みんな行くといいと思う。
自分の新たなスタートを感じた読了後(情熱プログラマー)
- 作者: Chad Fowler,でびあんぐる
- 出版社/メーカー: オーム社
- 発売日: 2010/02/26
- メディア: 単行本(ソフトカバー)
- 購入: 24人 クリック: 683回
- この商品を含むブログ (126件) を見る
最初のイントロダクションを読んだだけで転職・独立したくなった。自分のキャリアプランを考えて、いまどうすべきかと、これからどうすべきかが書かれた、プログラマー必読の本。印象的なのは、「いまできることをしっかりやるべき」と言うことが、ちゃんと書かれていること。単にネガティブなことを書き連ねているだけではなくて、今後どうすべきかを見据えて、いまある立場と仕事をしっかりやり遂げるべきと書いてある。いろんな経験を積んできた Chad Fowler ならではの多彩な例え話が非常にわかりやすかった。また翻訳も素晴らしい。訳書で違和感なく読み進められたのは、Joel on Software以来でした。ソフトウェア業界に生きているなら、ぜひ一読を。
全部は書けないので、特に印象に残った言葉。
- 一番下手くそでいよう
- 自分よりも能力の高い場にいると言うのはよく言われるが、やはりそれを実践しないと成長しないのだなぁと。
- ビジネスの仕組みを学ぶ
- 我々はお金をもらってソフトウェアを開発していると言うことを再認識するためにも、どう使われるのか、どうお金になるのかを理解しないといかん。
- 師匠を探す
- routes職人の師匠に師事したくなった。
- バケツ一杯の水の中の小石一つ
- 自己を過大評価してはいけない。会社組織のなかでは、自分は代替のきくものであると認識せよ。
- スーツ語
- 「それは何のためになるのかな」と尋ねられても答えられるように。
- 業界で名前を売ろう
- jpmobile 頑張ります!
- ウォータフォール式のキャリア計画はやめよう
- キャリア設計、つまりは人生設計もアジャイルに。
- 独立する
- 小さな新興企業で働くと言う選択肢。
と言うわけで、今の時点での自分の進むべき方向を見させてくれた本でした。
Java未経験者によるコップ本読書会(仮)
このあいだの SICP 読書会で @gom さんとの会話でコップ本を独習しながら Java に触れる読書会的なことやろうかということになりました.ただあんまりがつがつやらずに,「平日の夜にちょっと集まって,みんなそれぞれ Scala の勉強する」感じにしようと言うことで,参加条件は下記の通り.
- コップ本を持っている人
- Java 未経験者
- Java をこれから勉強しようという人の集まりを目指しています
- 平日夜にどこかに集まれる人
- 平日夜の 1時間半〜2時間ぐらいで
- 飲み会は無し
- 各自自由にと言いたいところですが,あえて
こういう奇特な方がいれば @conceal_rs までリプライか D 送ってください.いなくても2名で開催予定です.
実用Git - 2冊目に読む本
- 作者: Jon Loeliger,吉藤英明(監訳),本間雅洋,渡邉健太郎,浜本階生
- 出版社/メーカー: オライリージャパン
- 発売日: 2010/02/19
- メディア: 大型本
- 購入: 7人 クリック: 287回
- この商品を含むブログ (45件) を見る
入門Git に続いて2冊目だったのでざっと読む感じで読み進められました.内容的には「Gitを使い始めてしばらく経った人が読む本」もしくは「2冊目に読むべき本」と言う感じでしょうか.誰かにGitの説明を受けてから読むと結構すっと入っていきそうなんですが,これをいきなり読み始めると結構辛いんじゃないかな?という気がしました.逆に2冊目やもっと知りたいという方にはお勧めのGit本ではないでしょうか.
東京Ruby会議03 に行ってきた
- 雨と東京マラソンとの戦い
メタプログラミング入門
Ruby における特性
class LogWritable %w[host time].each do |attr| attr_reader attr end end
-
-
-
-
- 宣言ではなく普通に式であって,実行時に順次評価されるもの
- コンパイル時にどうこうされるようなものではない
- 宣言ではなく普通に式であって,実行時に順次評価されるもの
-
-
-
class Foo; end class Bar; end class Baz < (rand < 0.5 ? Foo : Bar) if gets == "ok" def foo; end end end
道具立て
klass = Class.new do def foo; end end
-
- 特異クラス
- クラス階層
- BasicObject < Object < Module < Class
- 特異メソッド
- クラス階層
- 特異クラス
class Bar; end bar1 = Bar.new bar2 = Bar.new def bar2.foo; end # => bar2 のみに定義される
-
-
-
- 特定のオブジェクトにだけメソッドを定義できる
- 特異クラス
- bar2 に特異メソッドを作ったときには,内部的に新しいクラスを定義している
- これを特異クラスと言う
- Ruby からは見えないが,見る方法がある
- これを特異クラスと言う
- bar2 に特異メソッドを作ったときには,内部的に新しいクラスを定義している
-
-
eigenclass = (class << obj; self end)
-
-
- メタクラス
- クラスのクラス
- クラスのクラスは,特異クラス
- クラスのクラス
- メタクラス
-
class Foo def self.static; end # 特異メソッド定義 end
-
-
-
-
- Foo と言うクラスは Foo の特異クラスに属している
- Foo を継承した Bar の特異クラスは,Foo の特異クラスを継承している
- Class クラスにも特異クラスがある
- Foo と言うクラスは Foo の特異クラスに属している
-
-
-
- 特異クラスは特殊なクラス
- callable objects
- Proc
- ブロック
- Proc.new / lambda / proc / &blk
- &blk => 呼び出し時に指定されたブロックが Proc オブジェクトに変換されて渡されるもの
- Method
- メソッド自身のオブジェクト
- UnboundMethod
- インスタンスが bind されていないメソッド
- Method#bound <-> UnboundMethod#bind
- Continuation
- callcc
- 各種変換ができる
- Proc
- eval 族
- eval / instance_eval / class_eval
- self
- デフォルトのレシーバ
- current class
- メソッド定義時に指定されるクラス
- TOPLEVEL
- self -> main
- current class -> Object
- class 定義中
- self -> the class
- current class -> the class
- def 式の中
- self -> 実行しているインスタンス自身
- current class -> NONE(無い)
- instance_eval
- self -> インスタンス自身
- current class -> 特異クラス
- class_eval
- self -> クラス自身
- current class -> クラス自身
- 特異メソッドが生成される
- eval
- binding に依存する
- method_missing / send
- "いいですね"
用例集
- メソッド定義
- Rails で
class Foo < ActiveRecord::Base [ %w[bar bas], %w[hoge piyo] ].each do |through, to| has_one through has_one to, :through => through define_method(:"#{to}=") do |val| self.send(:"#{through}=", val.send(through)) end end end
def sandbox(&block) Module.new(&block) end
ワークショップログ
東京 jpmobile 会議
- どう Rack 化するか
- Sinatra から使いたい
- Rails 2.3.x 用は
- ブランチを分けて,タグを切ってリリースにあわせる
- Rails 2.3.x 系はメンテナンスだけする
- ブランチを分けて,タグを切ってリリースにあわせる
- Rack 化
- テストはどうするか
- Rack::Middleware としてテストする?
- 絵文字は @mrkn さんの
- デモを見せてもらいました!いい感じでできあがる予感!?
- Rails の文字エンコードの出入の部分
- 絵文字が変換されてしまわないかとかチェック
- Content-type: を指定すればいい
- 絵文字が変換されてしまわないかとかチェック
- variants をどうするか
- Proc を渡すとか
- Proc で判定していく
- 動くものではなくて,仕様について相談してみるのがいいのではないか
- Proc を渡すとか
- 表 -> リクエスト生成(jpmobile) -> フィルター(jpmobile) -> アプリケーション
- 絵文字変換のフォールバック
- ハッシュテーブルとか文字を指定できれば
- 変換テーブルとかIPアドレステーブルとかを外部に出すと本体のメンテナンスやパッケージ化とかで手を煩わせなくていいんじゃないか
まとめ
- とりあえず実装してみてはどうかと思ったので,Rack 化をやってみよう
A REINTRODUCTION TO RUBY M17N
- 成瀬さん
- 地球に生まれたことを後悔することになるらしい
- 文字コードとは
- グリフやフォントよりちょっとした
- 文字集合
- 違うことの決定
- 何を扱うか
- 扱う文字を増やせば必要ビット数が増える
- 文字の同定
- 何が一文字か
- 字形の違い
- g とか l とか
- フォントや書体によって違う
- 字体の違い
- 符号化文字集合
- Coded Character Set
- Unicode Scalar Value
- ASCII / JIS X 0208 とか
- 文字符号化方式
- コードポイントを符号化する
- エンコーディング
- あるバイトデータを解釈するには「文字符号化方式」と〜を指定する必要がある
- IANA Charset
- インターネット上に流すデータは登録されている必要がある
- charset -> 文字集合
- 文字コード -> 文字集合 or encoding
- 国際化の歴史
- もともと国際対応じゃない
- 最初は ASCII
- 数字とアルファベットと記号の一部
- 数が足りない
- 拡張!
- して 500 種類以上?!
- どうしてこうなった?
- 製薬の中でベストを尽くそうとするため
- どうするか
- 各個撃破
- 罠は「歴史的経緯」にあり!
- ISO 646 - 分裂の始まり
- まだまだ足りないので
- ISO/IEC 2022
- 拡張方法を定めたもの
- ISO 2022 系
- 詳しくは文字コード本を
- 状態を持つのでいろいろ大変
- そこで Unicode
- 文字コードから地域・言語を分離
- フラットな空間に全てを入れる
- Plain Text は存在しない
- Legacy Encoding
- CP932 を知ってますか?
- 円記号問題「¥」
- ISO 646 の \ か¥かからはじまった
- 制御記号になったので
- シフトJISで問題が起こることも
- 波ダッシュ問題「〜」
- JIS X 0208 と CP932 で違うコードに変換される
- 機種依存文字
- 内部コードはどうするか
- UCS 正規化
- 入出力で変換する
- CSI (Code Set Independent)
- UCS 正規化
- Ruby 1.9
- String にエンコードがある
- 1.9 の String に必要なこと
- encoding を適切に設定すること
- encoding が誤ってるとき
- IO と Encoding
- encoding とは
- String にとっての「型」
- Encoding
- エンコーディングを司るクラス
- nkf
- Network Kanji Filter
- kconv
- iconv
- 挙動が環境依存
- uconv
- Unicode 変換用拡張モジュール
- String#encode
- String#encode(to, from, opt)
- Encoding::Converter
- 不必要な変換は避ける
- open() の引数に指定するなど
- Ruby M17N の難しさ
- テストがしづらい
- SJIS と Windows-31J
- Windows 環境だと,入力は Windows-31J だから,Windows-31J が正しい
- ASCII非互換の正規表現
- ケータイ絵文字
- @mrkn さんたちが作業中
- 1.9.2 に入るかも
- Windows の Unicode パスについてはパッチ待ち?
- 結合文字
- 「が」を「か」+「゛」で表すとか
- 複数のコードポイントを1文字扱いにする必要がある
- 異体字セレクタ/IVS
- String と言語
- Unicode ユーティリティ
- 半角か全角かは文脈依存だったりする
- Unicode 大文字小文字化
- String#sort
- Feedback を
open3 のはなし
- 田中哲さん
- 目的
- プロセスを動かす方法を提供する
- いい API を定義する
- Ruby のプロセス起動の問題
- system or fork
- system
- 環境依存だったりする
- fork
- UNIX でしか動かない
- system
- system or fork
- 解決
- spawn メソッドの新設
- open3 ライブラリの標準添付
- プロセス
- ps コマンド出力の1行
- プロセス属性
- 標準入出力
- fd の 0, 1, 2 は標準入力, 出力, エラー出力
- 0, 1, 2 は基本的に端末につながる
- リダイレクト
- プロセスの標準入出力をファイルに繋ぎかえる
- パイプ
- プロセスとプロセスをつなぐ
- Unix のプロセス起動
- fork
- fork を呼び出したプロセスの複製を作る
- exec
- exec を呼び出したプロセスを指定したコマンドで置き換える
- fork と exec の組み合わせ
- fork
- 非 UNIX では fork / exec は別れていない
- プロセス属性を指定する引数が複雑になりがち
- Ruby で実現したいこと
- API 案
- 既存のメソッドを拡張する? -> 上手くいかない
- 要求の衝突
- いろいろあるので,ひとつのメソッドで全部出来そうにない
- 高位・低位 API への分割
- 高位API : open3
- とりあえずパイプラインくらいまで提供
- エスケープしたりとか,コマンドのステータスをみたいとか
- 低位API : spawn
- fork はポータブルじゃないとか
- ライブラリのレイヤ
- 高位になるほどライブラリの自由度が高く「賢い」
- 低位になるほど詳細な制御が可能になる
- open3 と spawn のレイヤ
- open3
- OS 間の共通機能にフォーカスした高位 API
- spawn
- OS 固有の機能も出来る限り指定できる程度に低位
- open3
spawn について
- プロセス起動手法には起源がある
- いまの不満
- いろいろ OS でできたことが Ruby 上からできない
- プロセス起動の問題
- ポータブルではない部分がある
- perl では?
- ruby では?
- spawn 関数の導入
- fork + プロセス属性設定 + exec
- spawn の基本
pid = spawn("make all") Process.wait pid
-
- シェルを通さない方法も提供
- リダイレクトもある
spawn("make all", :out => "make.log")
open3 について
- 標準添付ライブラリ
- STDIN / STDOUT / STDERR とパイプを繋げて通信するライブラリ
- open3 の歴史は今日刻まれた
- ゾンビプロセス
- 終了した後,親により wait されていないプロセス
- open3 で言われる問題
- ゾンビ -> double fork
- Windows
- 終了ステータスが得られない -> double fork だから
- pid が得られない -> シグナルを送るのが困難 -> double fork だから
- 亜種が発生
- open3 による detach の効果
- ゾンビが発生しない
- double fork しないので pid が得られる
- 終了ステータスも得られる
- Open3.popen3 でいろいろ解決
- でも足りないので高位 API が必要
- open3 と標準エラー出力
- 標準出力と別々のパイプにするには扱いが面倒
- パイプにしないことがいいことも多い
- ひとつのパイプにマージしていいケースもある
- 標準出力と別々のパイプにするには扱いが面倒
- 高位 API のメソッド追加
- 出力を文字列で得る
- os, es, st = Open3.capture3
- 標準出力と標準エラーを出力をマージする
- Open3.popen2e
- パイプライン
- Open3.pipeline
- 出力を文字列で得る
- 複数パイプラインは必要か?
- spawn によるパイプラインは厄介
- パイプを作って閉じて〜を繰り返す必要がある
- spawn によるパイプラインは厄介
- shell ライブラリ というのもある
まとめ
- spawn / open3 の紹介
- 高位と低位に分けたデザイン
- パイプの用法の考察
懇親会
- エアとしていろいろ.そろそろかとかいろいろ.
全体のまとめ
- クラス/メソッド定義中のスコープについて考えると,特異メソッドやクラスメソッドのことがよくわかる
- 評価順は上からであって,クラス式は宣言式ではないので,C のように考えてはいけない
- 実際会議っぽくなりました
- 文字周りはいろいろカオスですね
- プロセス周りはちゃんと勉強したいです