てきとうなメモ

本の感想とか技術メモとか

LLTV

行ってきたのでメモ.敬称略.いろいろリンクとか追記する可能性あり.

間違いがあれば訂正します.

朝から生テレビ

自己紹介

  • LL使ってないのに呼ばれちゃった (hyoshiok)
  • 朝生は久しぶり (dan)
  • gauche最近更新少ないのは仕事が忙しいから(shiro)

最近のLLの動向

  • perl (dan)
    • parrot1.0.0(perl6のvm)がリリース
    • でも,遅いのでこれからチューニングしないと
      • LLを実行するサービス(llevalだと思われ)だと2秒割り当てている.他の言語は1秒
    • perl5.10.1がリリース.5.10->5.10.1はbug fix
  • python
    • 柴田淳さん登場
    • python2.xとpython3.xがある
    • python 2.5からpython3.xの機能を取り込んできている
  • php
    • こやまさんという方が説明(id:koyhogeさんでした)
    • php5.3.0がリリース
    • namespaceやclosureが追加された
  • ruby (takahashim)
    • ruby1.9.1がstable
      • m17n対応
      • yarvを利用するようになった
    • ruby1.8系は1.8.7が最新だが,railsを利用している人は1.8.6が多い

LLを利用しているか

  • Cを書くことはなくなった (dan)
  • gauche使っている (shiro)
  • 使用していないが,セキュリティプログラミングキャンプに参加してきた (hyoshiok)
    • osを開発するグループ
    • rubyをhackするグループ
      • ある部分のmacroをループの外に置くことによる性能向上
      • fixnumの最適化
    • linux kernelをhackするグループ
      • nfs関係のpatchが受け入れられたようだ
  • gauchegaucheコンパイラを書いている (shiro)
    • vmlispっぽいCで書いている
    • pythonのpypyとか興味ある
  • LLはおっさん向け言語な気がする.
    • アセンブラのmnemonic覚えたけど,今は...
    • mipsの命令覚えていたけど..

VM上の言語はどうか.JVM上や.Net上の言語

  • javaの功績は大きい (dan)
    • ただし起動が遅い
  • java vm をnativeに実行するマシンはなぜでてこないのか (dan)
    • 規模の問題.lispマシンでは負ける (hyoshiok)
    • processorはcに最適化しているので (shiro)
  • register(c) vs. stack(java) (dan)
    • 書きやすさと最適化の違い
    • stack topはレジスタに載るので実際は差は少ないのでは (shiro)
    • どこに抽象化のレイヤーを置くかという問題になる
  • hardwareとsoftwareの差が開く (dan)
  • 昔はintelのcompiler開発者とチップ開発者は同じ部屋で話さなかった (hyoshiok)
    • 今はOS開発者とLL言語開発者はコミュニケーションできる
    • 日本始まったな
  • ハードとソフトが混じっているといえばゲーム業界 (shiro)
    • 安定性ないけどね
  • レイヤーを分けるのは分業にはいい (dan)
    • しかし,全レイヤーを見れるということも重要
  • ゲーム業界だけでなくweb業界も上から下まで見れるのでは
  • ハードウェアの人も呼びたい
  • すり合わせがトレンドになってほしい
  • LL言語からデバイスを呼び出す話ならば午後に (takahashi)

並列プログラミングの話

  • ムーアの法則にのっとってコードを書いている (hyoshiok)
  • マルチコアでスケールするようなソフトウェアパターン(言語として?)を実装する
  • 上のレイヤーも並列性を意識しなければ (dan)
  • アカデミックではノウハウがたまっている (shiro)
  • closure
    • immutableなのでコピーするが,効率的に実装されている
  • パラダイムシフト loop -> map (dan)
  • fortranはベクトル化している (hyoshiok)
  • aplはarrayのoperatorに関しては面白いよ (hyoshiok)
  • rubyはoperatorが再定義できるので実行時じゃないとわからない (hyoshiok)
  • on the flyでコンパイルできるので変更があったときに再コンパイルすれば良いのでは (shiro)

iphoneandroidにおけるプログラミング

  • リソースが違う
  • 使われるシーンが変わってきた.常につながっている
  • コード自体はあまり変わらない (dan)
  • ただし,64Mのメモリの制約がある (hyoshiok)
  • androidの会はハードとソフトの人が同じ場で勉強会をやっていて面白い
    • 組み込みの人がバザール的なことを行っている
  • 勉強会のはなしになってしまうね
  • 携帯の人->パソコンへの突っ込みが欲しい (dan)
    • ハードディスクからosの読み込みは自明ではない
    • ユーザはファイルの存在を意識していない
  • 携帯用の言語 (shiro)
    • メモリフットプリントと省電力が問題になるのでは (hyoshiok)
  • 全く新しい言語の可能性は (shiro)
  • 携帯でプログラミングといっても2通りある
    • 結果が見れればいいや
      • 実際の計算はcloudで
    • 携帯のcpuで実行させたい
  • lleval
    • jsonで結果を返す
    • 携帯で実行していると2人だませた
  • 携帯でマクロや自動化 (shiro)
    • あんまりピンとこない (hyoshiok)
    • 携帯でそこまでの作業をするとは思わないが,コミュニケーションデバイスとしてはあるかも
  • プログラミングしないプログラムの復権 (dan)
    • 利用している人はプログラミングと意識していなくても,他の人が見るとプログラミングしているように見えるようなもの
    • shell scriptとか

質問

  • ネットワーク越しの並列プログラミングをLLでやるときのアイデア
    • 課題は多い
    • loopをmapで
    • ハードディスクよりもネットワークが速い
    • アカデミック的な話ではいろいろ研究されている (shiro)
      • どの技術をどこに当てればいいのか,どこがボトルネックになっているかが問題
  • LLはパフォーマンスのチューニングがちょっと難しい
    • Cならばここをこう直せば改善することがわかる
  • luagcが自動に動くがgcに命令することもできる
    • 他のLL言語にも命令を可能にすれば良いのでは
    • その辺りのチューニングはlispでやっているのでそこから掘り出してはどうか (shiro)

並列時代のdebugger

  • どのcpu(コア)が原因で問題が発生しているのかつきとめるのは難しい (dan)
    • 勘で (hyoshiok)
    • 動的にcontractを注入するという方法はある (shiro)
    • fault toleranceの世界では何かやっているかも (dan)
    • 並列はデバッグパラダイムシフトが必要では
  • algorithm debugging (hyoshiok)
    • ポジティブ/ネガティブの入力を入れておかしくなった部分を出力する
    • prologで実装されている
    • 実装がむずかしい.状態を保存すると爆発するのでは? shiro
  • testingについて
    • guiはやりにくい
    • regression testなどベストプラクティスがプラクティスになっていなかった yo
    • rubyはテスト少ない (dan)
    • cpuが速くなったので,テストの時間が短くなった (takahashim)
  • メモリが無限大にあって全ての状態を保持できるとなった場合どうなるのか
  • 逆にpessimisticな場合,バグは一期一会で再現しない (dan)
    • どこまでテストするのか
    • そういうのはしない (hyoshiok)
    • 飲み屋のおっさんの会話みたい
    • blogでグズグズ感満載と言われるかも
  • デバッグは現象再現がメインで,後はヒアリングのやり方が重要.(hyoshiok)
  • 再現しないバグは,ログをはかせる (hyoshiok)

LLフィーリングカップル

これはメモとっていない.男性陣のHPは0よということで.

渡る世間は雲ばかり

Windows Azureの話 (荒井省三)
  • Saas(Software),Paas(Platform),Iaas(Infra),DaaS(Data)
  • 提供しているもの
  • アプリを置く場合はVisual Studioが必要
  • LL言語はデータの部分を扱うことができる
  • データのストレージとしてはHTTPのインターフェースがある
  • sql azure
    • TDS(Tabular Data Stream)をしゃべれればSQLでアクセス可能
slim3 on GAEの話 (ひがやすお)
  • slim3
    • TDDのサポートが特徴
  • twitterもどきをつくるよ
  • gen-controller(antのタスク)でコントローラを自動生成
    • テストも自動生成される
  • gen-modelでモデルのコードを生成
    • テストコードも生成
  • DAO操作ライブラリ
    • こんな感じ
Message m = from(Message.class).getFirstResult();
  • コードの変更 -> すぐにローカルで動くテスト用web appに反映
  • 10分ぐらい延びた
jruby on GAEの話 (高井直人)
kay framework (松尾貴史)
  • kay (ケイと読む)
    • 長男の名前から
  • kay framework
  • 他のフレームワーク
    • django
      • app engine patchはコストが高い
    • web2py
    • appengine oil
    • glashammer on appengine
  • 昨日0.1.1リリース
  • これから
    • guiの管理ツールがあるといい
      • wxpythonでちょっと作ってみた
    • 実際にkay frameworkを利用したアプリケーションがあれば
discussion
  • クラウドはチャンス
  • 問題な部分もある
    • railsがつかえない
    • rdbにべったりなので
  • 制限がおおい
  • 並列の時代がくる
    • cloudは並列コンピューティング
  • ネックはストレージ
  • bigtable,azureも先駆者がいないのでチャンスだよ
  • ハードウェアが関係なくなってきた
  • 季節もののサイトをクラウド上に構築するのはよい
    • ハードウェア費用がかからない
    • 短期間で立ち上げられて,短期間で止めることができる
  • private cloundの価格が安い
  • ランニングコストが安いのがいい
  • microsoftはazureにどのくらい力を入れているのか
    • 既存のonlineサービスを全部をazureにするという勢い
  • GAEは機能追加がはげしい
  • 既存のSIerをおしのけることができる

プロトタイピング〜「もの作り」の流儀

hardware sketching
  • ガング
  • prototypeの前にskectchを作る
  • 気軽に,すぐに捨てられるように
  • prototyping prototypes
design engineering
  • takram
  • 工学系の人たち
discussion
  • プリント基盤サービス
  • 金型サービス
    • 2泊3日で作ってもらえる
  • prototypeがそのまま製品になる可能性

大改善!!ビフォーアフター

fortune (takano32)
  • takano32
  • fortune
    • ランダムに文章を表示するコマンド
    • bsd gamesに由来
    • オプション多い
  • 方針
    • コマンドをそのまま利用
    • universal design
    • ナウい
  • universal design
    • 他の言語で表示する
    • 翻訳サイトを利用
    • english-> japanese-> korean-> japaneseなど
  • 新世紀fortune
    • 占いカウントダウン
    • 他局からとってきてすみません
  • ぺーじが...とてもきたないです
    • w3m-dump-T text/html
  • :input => :uranaiで占いを出力
  • さそり座しか表示しない
    • 無断転載してはだめなので
  • :output => :twittertwitterに出力
    • ruby 1.9.xだとヒウィヒヒーでもok
vimperatorでsl (teramako)
  • id:teramako
  • vimperator
  • sl
    • キータイプ矯正ソフト
  • bash
    • 変数にAAを入れる
    • echo > /dev/null x 50で遅延
  • canvas text apiを使う
  • animationにはwindow.setinterval, window.setTimeout
  • さらに改善
    • fullscreen
    • animation
  • fullscreen
    • panel in xul
    • 装飾のないウィンドウ
  • animation
    • l○cky☆st○r
  • まとめ
    • そもそもvimperatorではls使わない.bufferの方が便利
    • キータイプ矯正ソフトなのに,slコマンドが癖になった
    • 問題点
      • animationでオブジェクト数が多いと落ちる
    • 役に立たない
ls (川合史朗)
  • freebsdのlsが対象
    • gnuのlsは複雑
  • freebsdのコードはいいコード
    • あくまでCのコードとしては
  • 本物のマクロを使おう
    • Cのマクロは偽物
  • 問題点
    • 冗長である
      • 逆順にソートするだけなのに別の関数定義になっている
    • for (i = 0; i < l; i++)のようなコード
      • for i in [0,l]みたいに書ければ
    • 情報が分散している
      • 似たようなコードが分散している
  • 構文は飾りです
  • CiSE
    • C in S式
    • 本物のマクロが使える
  • コードの行数が半分ぐらいに
  • マクロについての2つのルールと1つの例外 (Programming Closureより)
    • マクロは書くな
    • (後の2つ忘れた.とりあえず素人なので1つめだけでいいかなと)
  • Programming Closure翻訳中
無印良品のshell script (當仲寛哲)
  • 無印のシステム
    • お客様に質問されると対応に時間がかかる
    • 在庫確認/発注などが別システムで複数のシステムを立ち上げないといけない
  • ユニケージ開発手法を用いて改善
  • shell scriptで開発
  • 構文を使うのではなくコマンドのパイプラインで記述
    • 30個ぐらいのパイプ
  • LINUXの既存のコマンドとCやJavaで書かれた独自コマンドを利用
  • データはテキスト
  • 更新はせず,古いものを残し最新版を新しく作る
  • 現在はマシンが速いので問題はない
  • shell scriptのメリット
    • 読みやすい
      • (パイプを使っているという前提でと思われ)
    • 短い
  • 実際の改善方法
    • 複数のDBからデータをテキストに統合
    • それらを統合する.
      • シェルでリレーションを記述する
  • 3クリック30秒以内で目的の商品に
  • 検索にはgrepを利用
    • レコード数が多いものはファイルを分割
      • レコードのあるフィールドを文字単位でファイル分割,
      • 「タオル」ならば「MASTER.タ」「MASTER.オ」「MASTER.ル」にレコードが入っている
    • 26万件ぐらいのレコード
      • (空白orタブで分割されているっぽい)
    • grepで商品名検索 -> 0.5sec
    • 商品名で分割すると200万レコードぐらいになる
      • 分割処理は計15secぐらい
    • MASTER.<文字>のファイルにのみgrep
      • 7msぐらいで検索できる
  • 100万件のデータに対しても数msで検索可能

LLレッドカーペット

HP50gでラマヌジャンに挑戦 by 大野典宏
  • 大野典宏 (id:oono_n)
  • ラマヌジャンのπの計算式
    • 本人もどうしてこの式で計算できるのかわからなかったらしい
    • 収束性が非常に高い
  • デモっぽいことはできず
Ustreamゆっくりしていってね!!! by サロンパス(Hacker's Cafe)
  • id:saronpasu
  • Ustのチャットを音声でゆっくり声で出力
ワンライナーのための何か(仮) by sugyan
二つのPythonを用いた俺々DLNAサーバのすすめ by gamella
Konoha: LLに静的な型付けなんてあり得ない? by 中田晋平&井出真広(横浜国立大学大学院倉光研究室)
集え、シェルスクリプトマニアたち!by カノケイコ(USP友の会/USP研究所)
TVML "TV program making Language" by おおはししのぶ(IRI T2V研究開発チーム)
  • TVML
    • テキストで記述し,3dアニメを生成する
  • FIL script
    • 日本語で記述できる (ex. 180度ターンなど)
    • 複雑なことはできない
      • 内部にTVMLを記述することができる
  • 音声合成スクリプトで操作できる
Python版 Rake を作ってみた by 桑田誠
  • ようじょがしゃべっている?
  • pyKook
  • 5分制限意味ないね
pythoniPhoneを利用したLEDマトリックスの制御 by Hiro Aki
  • iphone -> macbook -> LEDでiphoneからLED
  • 照明の操作も
  • リモコンの操作もどうにかならないかな
    • リモコンは赤外線通信だから...
    • iphone -> macbook -> ロボットアーム -> リモコン -> TV
      • 赤外線通信は?
        • TVの赤外線通信の仕様がわからなかったらしい
BRAVIAを買ってアプリキャストを作ろう! by HolyGrail(Roppongi.JS)
  • id:HolyGrail
  • ミッドナイツ
    • これだけメモってた