#builderscon 2018 1日目
久しぶりのカンファレンス参加なのでヘロヘロになるかと思いきや、意外に大丈夫だった。最近は誰かとエンジニア的な会話をすることが少ないので、一方的に聞くだけではあるけどその辺りが満たされてちょっと元気になった。
1日目は「知らなかった、を聞く」のテーマ通りのセッションをわりとうまく選べて満足感。
ヤベーのが入ってた #builderscon (@ 慶應義塾 協生館 藤原洋記念ホール in 横浜市, 神奈川県) https://t.co/YRZkU5LMKy pic.twitter.com/IGJqqfcSBg
— 山入 凪 (@nyamairi) September 7, 2018
産業でガチ利用されるRaspberry Piの話 - builderscon tokyo 2018
サポーターが貰える謎ガジェットに触発されて。ラズパイは以前から気にはなっていたので、具体的な話が聞けて良かった。
「Linuxベースでsshとaptが使えるんだからどうとでもなる」なるほどそらそうだ。これだけで敷居の低さがはっきりわかりますな。安定供給されていて品質が高く汎用性もあれば、そりゃ標準になりますよね。
SDカードはちゃんとしたやつを使わないとトラブるかもとのこと。(T社のものがオススメらしい)
パスワードレスなユーザー認証時代を迎えるためにサービス開発者がしなければならないこと - builderscon tokyo 2018
この辺りは会社でちょっと話題になったのもあったので。個人的にも認証周りは追いかけたい感がある。
パスワードは特定のデバイスが不要でハックされない最強()のメソッドだよね。推測が困難な文字列をサービス毎に考えて覚えて利用するサービスがそれを受け入れてくれればバッチリ。…大体のユーザはそれを満たせるスペックを持っていないよねという話。サービス側も謎の制限とかあったりするしね(長さ制限とか、特定記号縛りとか)。
パスワードを保存するサービス側のリスクとコストも大きいよね。怖い怖い。
そのうちパスワードレスもくるはずなので今から意識して準備しておこう。やり方をいろいろ考えるとどうせ標準と同じようなものになるからはじめから標準に則っておこう。
Webサービスにて200週連続で新機能をリリースする舞台裏 - builderscon tokyo 2018
継続的なデプロイとかリリースとか、そういう世界は一応知っているけど全然できていないので…。
Mackerelの200週連続リリースの話。「リリース」がバグフィックスとかじゃなくてフィーチャ(？)なのが凄いと思います(小並感)。
はじめは特に意識していなくて、50回目のリリースが近づいてきた辺りで気づいたとのこと。つーかその段階ですでに別世界の話感があるのだが。
バックログに対してエンジニアの稼働率を100%にするのは駄目、肌感覚で20〜30%ぐらいの余力が必要。ですよねぇ、遊びがないスケジュールは本当に怖い。余力の部分でリファクタリングとかするのが良いとのこと。
(全然関係ないけどAurora PostgreSQLが既に公開されていたことをMeckerelのリリース履歴で知った。使ってみたい。)
実録！ある担当者がみた「謎ガジェット」開発１年史 - builderscon tokyo 2018
謎ガジェット。ひたすら楽しい話だった。
自分でも触っていくつもりである。
JavaCardの世界 - builderscon tokyo 2018
実は別セッションを聴くつもりだったのだが、移動したときには既に満席だったので。思いがけず面白い話だった。
SIMカードとかはこれが動いているらしい。floatとかcharとかなくてうかつにインスタンス変数を使うとカード自体が壊れるとか、それJavaって名前が付いてるけどCより辛くない？
リクエスト側でレスポンスのサイズを指定するという謎プロトコルでお話するらしい。なんつーかすげー色物ですな。
触ってみたくなったとしても趣味の範疇ではカードに書き込むための鍵をもらえない。エミュレータは存在するがオープンなものはない。なんつーかなんつーかなんつーかですな。
しかし面白かった。
lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話 - builderscon tokyo 2018
実は消去法で選んだ感。しかも結構疲れてきてて前半はあまり聴いていなかった。正直自慢話のようにも感じたので…。
しかしよく考えれば実績的に自慢できて当然のことを普通に話しているだけなのだった。なんつーか良くないぞ自分。
速いプログラムはコードじゃなくてデータ構造が速く扱えるようになっている。データ構造が先、コードが後。良いデータ構造ができれば各コードは自ずと決まってくる。
これは感銘を受けました。これが聞けただけでも参加した意味はあると思いましたね。
#builderscon 2017 を楽しんできました
#builderscon 2017
YAPCからの流れ(？)で開催されているカンファレンスということもあるのか、個人的には一番リラックスできるというか楽しめるカンファレンスな気がしています:)
知らないことが色々聴けて、大きなモチベーションをもらったように思います:)
前夜祭は当日ゴタゴタしていたのもあって参加しませんでしたが、金土の2日間で参加してきました:)
着席したらめっさエモいラップが流れてましたね…
富士通クラウドテクノロジーズさんのCMと両極端でしたね^^;
各セッションについて感想を書いていこうと思います。
Desktop Apps with JavaScript
Slack の中の人による JavaScript でデスクトップアプリなお話。
英語のセッションなので同時通訳をレシーバで聴きながら英語も聞き取れるようにがんばろうなどと思っていましたが、同時通訳を聴きながら英語を聞き取るのは難しかったですね…^^;
内容としては Electron を用いたデスクトップアプリの作り方でした。
Electron | Build cross platform desktop apps with JavaScript, HTML, and CSS.
前半に軽くスライドで概要について触れて、あとは実際にコードを読んだり書いたりしながらだったので非常にわかりやすいセッションでした:)
メインのプロセスと描画プロセスに別れていて、描画プロセス内では Chromium と NodeJS の両方が使えるという解釈でよかったのかな？めっさ便利そうですよね:)
前々から Electron は気になっていたので、コレを気に触りたいですね:)
ランチ1日目
回転寿司にしました:)
隣が旅行中(？)と思われる外国人三人組で、職人さんの写真を撮ったりしながら寿司を楽しんでましたね:)
トラブル
合間にリモートデスクトップで仕事をしながらの参加だったのですが、リモートデスクトップの調子が悪くなってその解消に手間取っていたため午後イチのセッションは殆ど聴けなかったです:(
接続先のマシンでも画面の描画をするモードで繋いでいたのですが、接続先と手元の両方に描画するのが結構キツイ処理だったらしく、手元だけに描画する設定に変更したら安定しました:)
はじめはリモートか手元の回線が良くないのかと思いましたが、会場の回線は終始安定していたと思います。素晴らしいですね:)
Haskellを使おう
Haskell は凄いH本を半分ぐらい読んで止まっているレベルなので、また触ってみる機会になればいいなと思って聴きに行きました:)
初めはなんとかついていけたのですが、途中からは正直殆どわかりませんでしたね^^;
現状の私の知識ではなかなかつらい言語だという認識になりました:(
なんでも適材適所なのだろうと思いますが、私が適材を判断できる段階にないということなんでしょうね…
- 作者: Miran Lipovača,田中英行,村主崇行
- 出版社/メーカー: オーム社
- 発売日: 2012/05/23
- メディア: 単行本（ソフトカバー）
- 購入: 25人 クリック: 580回
- この商品を含むブログ (73件) を見る
RDBアンチパターン リファクタリング
個人的にTwitterで何度か(何度も？)お世話になっているそーだいさんのセッション:)
@t_wada さんのSQLアンチパターンもそうですが、わりとRDBの設計に関する話題は興味があるので是非にと聴きに行きました:)
詳細については動画とスライドがあるので触れませんが、データベースがサービスを健康に保つ上で重要であること、嫌な臭いがする設計等についてわかりやすく説明されていてとても良いセッションでした:)
個人的に刺さったのが「リファクタリングをやらない」という選択肢が存在するという点です。リファクタリングするのは好きな方なので、つい費用対効果などを考えずにやってしまう事があるように思います。そこは意識しておかないといけないなと…。
ベストトーク賞おめでとうございます！
LT
それぞれ面白かったですが、印象に残っている2つについて触れます。
「QRコードは16分割できる」
というただそれだけの内容でしたが、非常にシンプルで良い内容でした:)
まさしく「知らなかった、を聞く」でしたね:)
わりと私の中でもイメージが悪い広告についてのお話でした。
「多重影分身広告(ページをスクロールすると追いかけてきて誤タップ)」
「老眼殺し広告(画面上にデカデカと表示されて閉じるボタンが極端に小さい)」
これらの広告はユーザの印象が悪いし結果として広告主の印象も悪くなって良いことがない。自浄作用で駆逐していきたいという内容だったと思います。
広告自体は悪いものじゃなく、お互いに利益のある関係を築けるといいですね:)
知られざる世界 〜WEB以外のPHP〜
(朝マックしてたら少し遅れました^^;)
例によってPHPの世界:)
PHPに対する愛にあふれていて素晴らしいと思います:)とても楽しく聴けました:)
…個人的には仕事でPHPは触らない方向で行こうと思っていますが…^^;
サーバサイドKotlinのすすめ
サーバサイドのAPIをPHPからJavaに移行していたら、ある時小規模なエンドポイントにKotlinで置き換えるPRが来ていて、そのまま取り込んだという話が印象的でした:)
それぐらい気軽に言語を混ぜられるというのは良い環境なのだろうなと感じました:)
構文を見ていて非常にとっつきやすそうな言語だという印象でした:)
ランチ2日目
わりと食欲がなかったので麦せいろ(冷麦)でツルッといきました:)
polyglot になろう !!
複数言語を使えるように鳴ることで、各言語のイディオムを取り入れて良いコードを書けるようになろうという内容だったと思います。
NVIとか、知らなかったのでためになりましたね:)
WEB+DB PRESS 100号記念 特別企画
実は自分で買って読んだことはないです^^;
技術トレンドの流れが見渡せて面白かったですね:)
Serverless Server Side Swift
サーバサイドで Swift をやるという興味深いお話でした。
Hexaville という AWS Lambda 上で Swift を動かすために必要な処理を一括でやってくれるエンジンを開発されたということで、必要になったものを自分で作って実用されているというのは、とても素晴らしいなと思いますね:)
GitHub - noppoMan/Hexaville: The modern serverless web application engine and framework for Swift
急遽話す順番が入れ替わっても臨機応変に対応されてました:)
ここが辛いよサーバーレス。だが私は乗り越えた
結局AWSも他のクラウドサービスも障害は発生する。それを踏まえた上でどこまで備えるか決める。提供されているクラウドサービスも、黒魔術ではなく既存の技術の組み合わせでしかなく、究極的には自分で提供することも可能。
という、当たり前ですが見過ごしがちなことについて改めて示していただけました:)
順番が入れ替わってしまったことについて、終わった後に平謝りされてましたね…^^;
まとめ
全体としてとても楽しい時間でした:)
今はほぼ一人で仕事をしているので、知らない世界の話を聴くのはすごく大事だなと考えています。一人でいるとどうしても知っている範囲のことしか見聞きしなかったり、新しいものに触れたりしなくなってしまうので…:(
これを機に、また新しかったり知らなかったりする事柄をキャッチできるようにアンテナを張りたいですね:)
#devsumi 2016 に行ってきました
今年もデブサミに行ってきました
ここ数年は毎年行っているのですが、やっぱりデブサミは良いですね。
なんというかモチベーションが上がります。参加者には開発者からデザイナーから経営者から色々な方がいるんだと思います。それぞれが色々なものを良くしようと思ったり、仲間を募ったり、はたまた単に趣味の話をしにきたりして一つの場所に集まっているのだなと思うとなんとなく気分がアガります:)
Day 1
いきなり素敵なお話でした:)
要件定義とか仕様書出したりとかしてる段階ではお客さんはおとなしくて、動くものが出てきてから色々な話が出始めるというあるある話。
動くものを見ないとわからないことが多いのは当たり前の話で、お客さんから(悪い意味ではなく)クレームが出てくるのは当たり前だと。それを意識しておかないと、お互いに嫌な気持ちになってしまうわけですね。
クレームが出てから直されるまでの間が開くと「諦め」が発生する。これは改善の機会を逸することになるので、短い間隔で継続的にリリースできることが大事。コツコツ継続的にやっていこう。
失敗を0にすることは出来ない。リスクを0にしようとするのは不可能をなそうとしている、リスクをマネジメントしなければいけない。
大事なことは「価値がある」「使える」「作れる」こと。それぞれを判断できる人は別であることが多いので、一緒に考えなければいけない。みんなで集まって解決していこう。
なるべく小さなアウトプットで、なるべく大きなインパクトを出そう！
友情→努力→勝利！！！
2つ目は1つ目と内容がもろかぶりだったので、本を立ち読みしてから休憩と充電を兼ねてカフェに行ってきました^^;
バナナ美味しかったです:)
打って変わって言語のお話。
JavaScriptも大分こなれてきたという話(だと勝手に理解)。2015年にガツンとバージョンアップされて、しばらくは緩やかな変更にとどまるらしい。他の言語からもいろいろ取り入れているとのこと(C#からAsync Awaitとか)。
JavaScriptにありがちな「でもその機能はこのブラウザで実装されてないよね」問題。トランスパイラ(BABEL)で解決する。最新の言語仕様で書いて、実際にデプロイするときは環境にあった形に変換する。LESSだのSASSだのminifyだのと同じタイミングでやる。
2015でめんどくさかったこととか色々良くなるらしい。文字列内で変数展開できる(バッククォート括り)とか、デフォルト引数とか、可変長引数とか、オブジェクトの特定のプロパティのみ抜き出して変数に代入とか、classとか、ブロックスコープの導入( (function() {...})() ←これを書かなくていい)とか、定数とか、矢印関数(thisが差し替わらない)とか、非同期処理にasync awaitが使えるようになるとか、Setとか、とにかくいい感じとのこと。
パフォーマンスも順調に最適化が進んでいるとのこと。生JSを書くのが苦痛でなくなっているのか、仕事で使ってみたい。
こちらはアーキテクチャの話。トレンド(？)になっている「リアクティブ」とか「マイクロ・サービス」とかですね。プロジェクトの進め方系の話と並んで興味のある分野です。
個人的にはカタカナが多めでそこが結構厳しかったのですが、無理して翻訳しないというのは大事ですよね、うん。
スライドがしっかりバッチリしていて内容については読めばわかるのですが、まとめるとこんな感じだと捉えました。
- 分散分散言うけどちゃんと考えて気をつけてやれよ
- ネットワークとかそんなに信用できないからエラーのケアしろよ
- サーバとか増えて運用辛くなるからしっかり自動化とかしとけよ
- 自分たちで頑張るんじゃなくて先人に頼れよ
1日目最後はこちら。毎年これを選んでます:)
インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門
- 作者: みやたひろし
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2013/12/27
- メディア: 大型本
- この商品を含むブログ (8件) を見る
↑ おすすめポイントはインフラに関して散らばっていた知識が繋がることだそうです:)
個人的には結構興味深い内容だったのですが、いかんせんクラウドイケイケの世相から不利でしたね:(
↑ 業界外の人にITについて興味を持ってもらうのが意図だ的なことだったと思います(うろ覚え^^;)。
個人的にはとても喜ばしいという印象で、技術書部門はこの本に投票しました:)
会社に買ってもらう候補です。
プログラマ脳を鍛える数学パズル シンプルで高速なコードが書けるようになる70問
- 作者: 増井敏克
- 出版社/メーカー: 翔泳社
- 発売日: 2015/10/14
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (3件) を見る
↑ 技術書部門大賞ですね:)
個人で購入したのですが、「サイン本ラス1です^^」と言われてTwitterに投げたら同じことを呟いている方がいて、どっちが真のラス1なのだろうか…
↑ ベン・ホロウィッツさんが実際に直面した困難と教訓をまとめた本とのことです:)
人→製品→利益 の順番で大切にしろとのこと。読んでいると胸が痛くなるとのこと^^;
ビジネス書部門はこの本に投票しました:)
会社に買ってもらう候補です。
↑ 去年も似た本が出てましたが、所謂Googleの働き方というやつですね。
帯には「グーグル」と入っていますが、別にGoogle独自じゃなくてGoogleだって他から取り入れたりしている、「あのGoogleが！」的な先入観を抱いてほしくないと言っていた気がする。
人工知能は人間を超えるか ディープラーニングの先にあるもの (角川EPUB選書)
- 作者: 松尾豊
- 出版社/メーカー: KADOKAWA/中経出版
- 発売日: 2015/03/11
- メディア: 単行本
- この商品を含むブログ (10件) を見る
↑ ビジネス書部門大賞ですね:)
ディープラーニングの入り口的な立ち位置だとか？個人的に購入したいと思ってます:)
電子書籍版が紙媒体の売上を上回っている稀有な本とのこと。
Day 2
(資料が見つからなかった…;)
大体の問題はプログラミングではなくマネジメントの問題。これはまさしくそのとおりだなと思います。
大規模開発をマネジメントし切る実力を持っているマネージャなんてそんじょそこらにはいないのではないか。しかし壁を超えた先には魅力的な世界が広がっている。
アジャイルに期待しすぎるのはダメ。ウォーターフォールはダメだからアジャイルでやりましょうよ的な言葉は鵜呑みにしてはいけない。
問題は方法論ではないのではないか、その場合はウォーターフォールだアジャイルだ言ってても解決できない。アジャイルが言っているのは当たり前のこと。乱暴に考えるとウォーターフォールでも細かくやればアジャイルではないか的な(私個人の捉え方です、マサカリが飛んできそう;)。
アジャイル=無計画 ではない(当たり前ですな)。
ツールに振り回されてはダメ。ツールありきで仕事の進め方を決めているのでは本末転倒、やり方が先にあってそのためにツールが有る。
常に反省すること。結局は最初から最後まで「覚悟」と「人」の話である。
会場を間違えました…(そしてそれに気づいたのは結構経ってから…^^;)
まとめとしてはこういうパラダイムシフトの導入にあたって費用対効果を出すのは無理なので、熱意で頑張れとのこと。もう流行りとかじゃないんだよ、普及してるんだよ、使えるのがメリットなんじゃなくて使えないことがデメリットなんだよ。
はじめはAWSの宣伝かな？と思いましたが、思ったより得るものが多かったです。わりとこれからやろうとしているところにハマりそうな内容でした:)
マイクロ・サービスはクラウドとの相性が良い。小さな部品を組み合わせる的なね。
モノリシックなシステムから開放されよう(「モノシリック」だと思ってた…^^;)。
ここでも分散システムの難しさについて釘を刺される。
API GatewayとLambdaの組み合わせでEC2を使わずに構築するのがイケてる気がする。API GatewayもLambdaも面倒なことを色々やってくれて大変よろしい。ビジネスの本質と関係ないコードの量を減らせる。大抵の場合はEC2よりコストが減る。もちろん必要であればEC2を使ったって構わない。
(資料が見つからなかった…)
途中からで立ち見だったのでろくにメモも取っていないです…^^;
しかし良い話でした:)
マネージャになって辛いことがあったが、自分のモチベーションを考えなおしてみると意外に合っている仕事だと思い直したとか:)
最後は気になっていたブロックチェーンについて。ブロックチェーンの有用性についての話かとおもいきやDisの立場からのお話でした^^;
やっぱり難しくて曖昧な解釈しか出来てません…><
ブロックチェーンは「新聞」の代わり。群衆が「(出来事の証拠としての)新聞」を発行していくようなイメージ(？)。
ブロック(塊)・チェーン(連鎖)
ブロックは取引(TX)の集まり。取引(TX)は状態の変化の記述(例: 送金)。状態の変化の塊の連鎖。
3つの層があり、コンセンサスのプロトコル、ダイジェスト(ハッシュ値)を格納するブロックの連鎖、デジタル署名によるデータ構造となる。
コンセンサスのプロトコルとしては現実と同期して動く上では問題がある。ダイジェストを格納するブロックの連鎖の構造は想定されていたほど強固ではない。デジタル署名によるデータ構造は有益である。
整合性の担保を確率に頼っている部分があるので、コンセンサスの成立とするには弱い(という私の理解)。
Proof of Work。作業コストを膨大に、検証を容易にすることでスパムや不正行為を抑止する。例えば「先頭20ビットが0になるダイジェストを生成できる乱数」を作る、作成には時間が掛かるがその乱数が条件を満たすかどうかの検証は一瞬で可能である。
取引の改ざんはデジタル署名によって不可能であるが、取引の削除は可能性がある。POWによって改ざん者vs世界という図式を作り、事実上不可能にするという理屈だが…あくまでも事実上であって、改ざん者がタイミングを見計らってコストをつぎ込めばBitcoinが破綻する可能性は存在した(する)といえる。
世界各地の主要金融機関がブロックチェーンの研究・実験をしているらしい。
小さいブロックチェーンは小さいコストで破綻させることが可能である。そもそも小さいなら従来の手法でコンセンサスをとればいい。
分散システムは一貫性・可用性・分断耐性の全ては満たせない。ブロックチェーンは一貫性を確保できていない。例として「ビットコインを支払うと上空のドローンがドリンクを落としてくれるサービス」を考える。ドリンクはいつ落とせばいい？ビットコインの取引は確定するタイミングを予測できない。同時に2つのブロックが成立することがあり、そのうちどちらのブロックが有効であるかは時間が経たないと確定しない仕組みである。そのため現実に当てはめるにはリスク(取引が後で無効になる可能性)をとらなければならない。
ブロックチェーンは不確実性というリスクをとれるのであれば有用であり、可能性がある。しかしそうでないシステムには向いていない。
だがしかし、ブロックチェーンが示した世界には魅力がある。
まとめ
やっぱりデブサミはその場にいるだけでも得るものがあるのではないかと思います:)
社長とか忙しいので行けないとの事だったが、ぜひとも優先順位を上げていただきたい。
モチベーションを頂いたので、得たものを活かして楽しくやっていきたいです:)
他に気になったお話
失敗から学ぶデータ分析グループのチームマネジメント変遷 （デブサミ2016） #devsumi
【資料公開】強いチームの作り方(デブサミ2016版) | Ryuzee.com
外注が主な企業でどのように内製開発を立ち上げ・進化させているのか？
YAPC::Asia 2014 に参加してきた #yapcasia
今年もYAPC::Asiaに参加しました。
相変わらずPerlには殆ど触らない生活をしているけど、やっぱり業務で本格的に触った初めての言語だし、有名人もいっぱい見れるし、(ぶっちゃけPerlとか関係ないし、)モチベーションが上がるので参加できるならしようと思ったのです。
Day 1
インフラエンジニア(狭義)は死んだ
- コードが読めない書けないインフラエンジニア→死。
- 開発だけやるとか、インフラだけやるとか、もはや通用しない。分業は成立しない。
- 自分は〇〇エンジニアだから、××はしないみたいな先入観、思い込みはマズイ。それでは問題の解決に臨むときに無意識でブレーキをかけてしまうのでは？
課題を解決したり楽しんだり喜んでもらったりするのが目的じゃないのか？コーディングだけしたりインフラの面倒を見るだけが目的ではないはず。その意識は大事だなと改めて認識出来ました。
完成されたシステムなどない。完成された人間もいない。あるのは成長し続ける未完成なシステムと、それを支える未完成な人間だけだ
#yapcasia 2014 でシステムとの時間の旅の話をしてきました - さよならインターネット
- スピリチュアル
- 再現性・簡便性
- シンプルかつ環境に依存しない
- 式年遷宮・長屋 どうせ壊れるので、壊しやすく、立て直しやすく、壊れても問題ないようにする
すべてのシステムに共通してすべきこととして、シンプルで、依存が少なくて、壊れても問題ないように保険をかけましょうというお話でした。
シンプルであるべきというのは、1関数〜1システムまで全てに共通する考え方なんだなー。
そして、人は絶対にミスをする(今朝もした)ので、その前提で環境・体制を構築するべきということですね。
Scala In Perl Company : Hatena
Scala in Perl Company という内容で発表しました #yapcasia【YAPC::Asia Tokyo 2014】 - はこべブログ ♨
Scala楽しそうだなーと思いました(小並感
最近は型好き好きなので、興味はアリアリです(Option型があるのも素敵ですよね)
コマンドラインツールについて語るときに僕の語ること
コマンドラインツールについて語るときに僕の語ること #yapcasia // Speaker Deck
- コマンドのオプションについて、ShortとLongの両方を用意する
- デフォルトで破壊的動作はしない(破壊的動作はLongで)
- 対話的な動作をしない(自動化の妨げになる)
- README.md > Usage > Man の順にユーザは見ていく。ちゃんと用意する
- 1コマンドでインストールできる
- デバッグオプションを用意する
- 1ツールは1つのことだけやる。他のツールと連携できるようにする
- RDD → README Driven Development
コマンドラインツールでもシンプルであるということは当然大事。
RDDは自分のやりたいことを明確にしてから開発に取り掛かれるし、一番モチベーションのある時にドキュメントを書くことができる。(ドキュメントを書くのは面倒なので、やる気があるうちにやっておくほうが良い。開発自体は楽しいからあとでも大丈夫)
「プロトタイプを手軽に作れる環境を用意すると良い」確かにオプションのパースとか、毎回書くのうざいですよね。
手でおっかなびっくりやるんじゃなくて、都度都度ツールを作ってどんどん楽をしたいですなー。
DeNAが歩んだデプロイ自動化への道
- 安全工学としてのデプロイ自動化
- 悪いシステムほど、後になって問題が発見される
- リリースに困難さを感じるかどうかが、そのシステムの安全性を図る指標のひとつになる
- 出荷プロセスの見直しは生産システム全体の見直しになる。リリースプロセスの自動化により自浄作用を働かせる
今まさにやりたくてできてないデプロイ自動化。VSでの自動化(特にWindows Forms)を早いとこ成し遂げたい…
手動でのデプロイがおっかなびっくりでバタバタしてしまっているので、きっちり整えて自動化するのが安全安心というのはすごく納得できるです。
WHERE狙いのキー、ORDER BY狙いのキー
- インデックスとは、ソート済みのデータの複製(異論はあると思う)
- WHERE狙いのキー: 条件判定が少ない、残った行をソートする必要がある
- ORDER BY狙いのキー: ソートはしなくていい、条件判定が残った行分走る
- ネステッドループジョインは評価する行が倍倍で増えていくので遅すぎる
- 充分に絞り込めるならWHERE狙い、そうでなければORDER BY狙いが良い
今まで超適当にぼんやりと考えていたインデックスですが、コードでわかりやすく解説していただいたおかげで大分理解が出来たような気がします:)
上っ面だけじゃなくて内部的なこともちゃんと把握できていないとダメなんですよね…;
遅いクエリを速くするのは結構な快感なので、積極的にやっていきたいと思います:)
Lightning Talks Day 1
- モナドはやっぱりわけわからん
- デート中にSEGVの原因を考えてブチ切れて振られても結婚出来る
- PIXIVは全部小文字
LTは話しが早過ぎるので、私の実力ではメモれないし覚えきれません^^;
その分カジュアルに聞けてとても楽しかったです:)
Day 2
突然ITインフラを任された人のための…監視設計入門
突然ITインフラを任された人のための…監視設計入門 #yapcasia
- レイヤーを分けて整理。外形、デーモン、リソース、サーバ
- netstatはなくなるからssコマンドを使っていきましょう
- 誤報慣れ怖い
個人的には今回一番聞けてよかったトークです。
しなきゃいけないのはわかってるサーバ監視だけど具体的に何をすればいいのかが曖昧だったけど、今回それがはっきりしたと思います。ありがたや。
レイヤーに分けて考えるというのがとてもわかりやすくてモヤモヤが解消しました:)
例によってWindows対象の話がなかったですが、それは自分で調べれば出来そうですね:)
半端なPHPDisでPHPerに陰で笑われないためのPerl Monger向け最新PHP事情（5.6対応）
- PSRでPHPの世界に秩序をもたらそうとしている
- PHPはテンプレートエンジンであるが、PHPの中でもっと安全な別のテンプレートエンジンを使うのが常識
- SPL(Standard PHP Library)でいろいろ便利に
- モダンなPHPはJavaっぽい
- PHP5.6が出てきた余波で5.3はおしまい。PEARライブラリは消滅の流れ
- npmのパッケージ数はバグ
- レールが無いからあっさり崖から落ちる
- 弾さん「あ、そっか・・・ try-cactchあったんだ・・・」
PHPのトークでYAPCのベストトーク賞1位を獲得するという伝説を打ち立てた素晴らしいトークでした:) そう、YAPC::AsiaはYet Another PHP Conference Asiaだったのです。
触るたびに苦い思いをして避けよう避けようとしているPHPですが、やっぱり避け切れません:( どうせ避けきれないので、ちゃんと最新事情を掴んでおきたいですね:)
Perlあるある
- Jcode.pmがめちゃくちゃ懐かしい
- dan kogaiはエンジニアに愛される方
- 朝起きた直後が一番集中できる→昼寝を導入する→朝が2度来る！
- 実は出演者全員77年生まれ
- コードも作文も同じ。読まれて意味の分からないコードは書かない
- コードを書くのに許可はいらない
- 変態たるもの基礎が大事
- Done is better than perfect
こちらもすごく楽しかったです:)
有名エンジニアの1日のスケジュールはすごく興味深かったですね:) 自分のピークに合わせて効率を上げるというのは、当たり前だけど難しいですね…。
グダグダ言って動かないのではなく、とりあえずコードを書けと。そしてきれいなコードが書けないと言っていつまでも未完成なままにするのではなく、まずは完成させろと。
Lightning Talks Day 2
TDD(Twitter Driven Datsu-Syoshinsya) / Twitter駆動脱初心者 #yapcasia // Speaker Deck
- TwitterはWebエンジニアの仕事
- Twitterで有名な人をフォローするといいよ
- Twitterやったり、勉強会行くようになってから技術力上がってった気がする
- メタプログラミング、すなわち魔法
- 挫折を挫折のままにしない
Twitterで有名な人をフォローするのは本当に有効だと思う。受信できる情報量がすごく増えますよね。仕事中にTwitterは必要です( ｰ`дｰ´)ｷﾘｯ
あと、わからないことをつぶやいたら有名な人から回答が来るのは本当に嬉しいです:)
自分ダメだな～と思っても、勉強会やカンファレンスでモチベーションを得て、有名な人達に引っ張ってもらって、自分も誰かを引っ張れるようになれると良いなと思うです:)
キーノート
- typester.Jr可愛い
- 受託開発が楽しい。新しい技術、新しい人に出会える
- 一度の人生楽しまなきゃ損！
- ロールモデルを持とう 10年後にどうなってたいか 10年後にどうなりたいか
自分はどうなりたいのか、それを持っていれば何があってもエンジニアとしてやっていけそうです:)
まとめ
2年連続の参加でしたが、今年も存分に楽しめました:) やっぱり勉強会やカンファレンスはなかなか上がってくれない私のモチベーションを大いに高めてくれます:)
YAPC::Asiaは世界で一番大きなYAPCだということで、それに参加できる現状はとてもありがたいと思っています。たまたま一番初めに仕事で触った言語がPerlだったわけですが、それがこんなに価値のあるコミュニティを持つ言語だったことは私にとってとても幸運なことだったのですね:)
きっと来年も開催されて、きっと来年も参加させてもらっていると思います:)
怪我について - #kabepy Advent Calendar 2013 20日目
この記事は #kabepy Advent Calendar 2013 の20日目の記事です。
前日の記事は @takanory さんの
#kabepy Advent Calendar 2013: #19 Tシャツを作った — takanory.net です！
日が登るまでは今日は昨日なのです！（意味不明
さて、この記事ではボルダリング（スポーツ）にはつきものの怪我について書きたいと思います。
私自身が11月下旬に結構重い捻挫をしてしまったので、その経験から怪我をした時のために必要なことなど列挙していきます。
（翌日の記事とネタが被り気味な気がしますが、怪我すること自体に焦点を当てることでお許し頂きたいです；）
怪我をした時に持っているといいもの
- お金
- 助けてくれる友達や家族など
- 店員さんに助けを求める勇気
- 晒し者状態になってもくじけない心
お金
皆さん知っての通り、お金は大事です。持っているに越したことはありません。
何をするにしても必要ですが、怪我した時ももちろん必要です。
今回私が捻挫した時に一番お金を使ったのは「交通費」です。
救急車を呼ぶほどの怪我ではない、でも電車に乗って帰れるような状態でもない（職場近くのジムで怪我したので家まで遠い）。仕方ないのでタクシーを使って1万6千円を支払いました；；
他にもシップやら包帯やらテーピングやらで結構使いました、お金重要。
助けてくれる友達や家族など
皆さん知っての通り（ｒｙ
包帯やらなんやらを買ってきてもらったり、介抱してもらったり、移動するのに肩を貸してもらったりしました。
店員さんでも助けてくれるというのはもちろんあるのですが、友達や家族の方が気が楽ですし安心できますよね？
登るときは誰かと一緒に行ったほうがいいです、ぼっち危険。
店員さんに助けを求める勇気
怪我というのはいち早く対処しないといけません、恥ずかしいからといって独りで何とかしようとしてもろくな事にならないですし、きっと周りもその方が迷惑です。
特に捻挫の場合はすみやかに患部を冷やす必要があるので、店員さんに氷を用意してもらうのは最優先事項です。
また、今回の私のようにひどい捻挫になると目眩を起こしてしまったりするようなので、横になるスペースと毛布などを確保するためにも店員さんの協力は必須です。
晒し者状態になってもくじけない心
上に書いたとおり、怪我をするといろんな人に協力して貰う必要があります。
必然的に目立ちます、しかも目眩で横になったりしたら、学校のように保健室があるわけでもないので大抵は他のお客さんもいる場所でしょう。
私も何人もの人が通る場所で小1時間ぐらい横になっていました。横目で見ていく人、声をかけてくれる人、色々いらっしゃいましたが人が横になってるのをあえて無視する人は殆どいないので、しばらく晒し者状態です。
恥ずかしいかもしれませんがしかたのないことなので、やっちまった感を味わいつつ耐えましょう。
怪我をしたあと
もちろん整形外科なり整骨院なり行くべきなのですが、私の場合は夜10時にやっちまいましたので、もうやっている時間ではありませんでした。救急窓口などはあるのでしょうが、ひとまず骨に異常はなさそうだったので一旦帰って、翌日整骨院に行きました。
素人判断で怪我の状態をみるのは危険ですが、捻挫であればこのぐらいの対応でも問題なかったようです。
ただし、応急処置はちゃんとしておかないとまずいことになるので、症状に合わせてググりましょう。私の場合は足の捻挫なので足を心臓より高い位置にあげて、氷で冷やしながら一晩過ごしました。
足の怪我の場合は無理をせずにタクシーなどを使って移動しましょう。無理は禁物です。
しばらくはお医者さんの指示に従って治療やリハビリに励むことになりますが、怪我の原因について思いを巡らせ、反省しながら登れない苦しみに耐えましょう。
最後に
締め切り守れなくてスミマセンでしたm(_ _)m
リハビリについては次の記事で書いていただけるようなので、私も参考にさせてもらおうと思っています。
