ブラウザでVJデビューしよう #kyotoasterisk - hitode909の日記
プレゼンモード 再生 ← / →で移動 fでフルスクリーン escでおわる id:hitode909です．Kyoto.なんか #5 に飛び入りでLTするための資料です． ブラウザでVJデビューしよう #kyotoasterisk Kyoto.なんか #5 hitode909 hitode909 はてなで働いている ブラウザが好き アジェンダ 先日ブラウザでVJデビューした 始め方を伝授 皆様がVJデビューするのがゴール VJとは Video JockeyまたはVisual Jockey Disc Jockeyが曲を流すので VJが映像を出す 客が盛り上がれば成功 VJデビュー 妻がDJデビューすることになったのでその流れでVJデビューすることになった smtppp.club 手法 HTML, JSを書く VSCode Live Server拡張を使う その場で編集、Live Reloadで
飲み会IoTボタン作った - hitode909の日記
会社のオフィスは東京と京都に分かれていて，それぞれ，さらに7F，8F，9Fとか，B1，3F，4F，のように3フロアずつに分かれているので，合計6フロアあることになる．それに加えてリモートの人たちは家にいる． 定時後に，お疲れ様でしたとか言ってビールや日本酒をあけることがあるのだけど，他のフロアでワイワイやってても気付きにくく，駆け付きにくい，駆け付けてもらいにくい，という問題がある． そこで，AWSのIoTボタンを使って人を呼べるようにした． 張り紙 このビールを冷やしてる冷蔵庫付近の壁に張り紙を貼った． 使い方 この乱雑な紙に使い方と，IoTボタンを貼り付けている．IoTボタンはボタンの裏側が接着面になっていて，ドキュメントに貼り付けることができて便利． 開催 1回押すと，Slackの#drinkingnow(飲み会の様子を共有するチャンネル)に飲み会開催中のお知らせが流れる．これが流れ
ひどいソフトウェア作りたくなくて考えること - hitode909の日記
ソフトウェア作ってるとどうしようもないひどい状況になったり、知らないプロダクトを読んだらひどい状況になってたりすることがあって、どんなときにそういうことになるのか、必ずそうなるのか、そうなることを予見できないか、完成したソフトウェアを見てひどいかどうか判定できるか、とか気になってる。 作ってる途中に気付けないものか 作る前に気づけることはあるかひどいのは分かってるけどやるしかないときにだけひどいものができるのか時間はあるけどやる気がないとそうなるのかプライベートでなんかあるとそうなるのか書いてから時間が経つと大体のものはそうなるのかコードは正しくて読者が使われてるパターンに理解がないだけなのかパターンの使い方が変だと読めなくなるのか当時と環境、社会情勢や実行環境、データ量、などが変わってひどくなるのかいい技術が発明される前なのでしかたないのかいい技術が発明されたときにキャッチアップすべきか
気が狂った設計 - hitode909の日記
大きめのこととか，自信のないところを触るときは，コード書く前に，こういう作戦考えてみたけどどうですかって聞いてみたり，こういうことやりたいんだけど一緒に考えませんかって，いっしょに話して設計考えたりするとよいと思う． 一緒に考えたすぐあとに気が狂った設計とか言い出したらおかしいので，未然に変な設計のままコード書いてしまうのを防げる． 特に辛い気持ちになるのが、「気が狂った設計」「クソコード」「（こんな実装は）有り得ない」といった言葉だ。 Pull Requestのレビューが辛くて会社をやめたい 単に言葉が強いのはよくないと思う．我が社にはそんな強い言葉でレビュー書く人はいない． 我が社には，普段から強い言葉を発する人もいなくて，みんな物腰柔らかな変な言葉を話している． 言葉使いや文体は，ずっと過ごしてると同僚から移ったりするので，普段からそういう言葉を話していると，全体の雰囲気も悪くなりそ
失敗する前提でデプロイする - hitode909の日記
うちのチームでは，デプロイするたびに自動的にgitのtagを切るようにしてる．たとえば，いまデプロイしたら，deploy/2014-02-01-14-48とか． たまに，リリースした直後になんかミスってたことに気付いて，慌ててロールバックすることがある． tagを切ってるので，ひとつ前に戻せばいいのだけど，えっと，どれだっけとかいって探すので慌てるし，普段はタグ指定してデプロイしてないので，どうやって戻すか忘れる． デプロイ終わったときに，今回のデプロイを戻すには，これをしましょう，とか表示するようにした． デプロイ終わったらこんなのが出る．前回のデプロイが昨日だったら昨日くらいのタグが出る． ヒント：戻すときは以下のコマンドを実行しましょう cap -S revision=deploy/2014-01-31-15-17 deploy 実装方法としては，こんな感じに，デプロイ前に最新のタグ
プログラミングとは何なのか - hitode909の日記
会社でボードゲームしてる人たちがいる。 僕はボードゲーム苦手で、たまにやっても全然勝てない。 将棋とかイメージすると、こっちがこういう手を出すと相手はどうするか、そしてその次は、というのを予測すればよいのだけど、なんかそれがめんどうで、なんでこんなこと考えないといけないのか、とか考えだしてくたびれてしまう。 ずっと論理的に考えるのが苦手で、すぐめんどうになってやめてしまう。 普段、仕事や遊びでソフトウェア作ってるのだけど、よく考えると、ソフトウェアの動作が論理的なだけで、ソフトウェア作るのは勘でできる。 ソフトウェアが正しく動くかどうかは論理的に決められて、電卓アプリなら計算結果が狂ってたら間違っているけど、その電卓アプリがどのように作られたか、には正しさはない。逆立ちして作っても、猿にタイプライターを渡して作っても、計算結果合ってれば良い。 過去のデータとか経験によると猿に書かせるのは効
テスト先に書きたい若者よ - hitode909の日記
弊社では毎年インターンを受け入れているのだけど，いまもインターンが来てて，テスト先に書きたいけど油断すると先に実装を書いてしまう，とか話してた． 個人的には，テスト先に書くのが大事というよりかは，意識して仕様を先に考えるのが大事だと思っている．テストを先に書くと，先に仕様を考えざるを得ないので，良いスタイルが身につく． 僕がよくやるのは，関連しそうなクラスの絵をひと通りノートに書いてみて，その図だけで，うまく動くことを説明できるくらい考えてみる．その時点でおかしかったら，コード書いてもおかしくなる．ノートに方眼ついてるとクラス図書きやすい．UMLとかじゃなくても，自分で見て分かるくらいでもいいと思う． 紙でうまくいったら，外部仕様だけソースコードに書いてみる．クラス名と，メソッドの定義と，メソッドの上くらいに，ひと通りコメントでも書いてみて，この関数はこういうことをするんです，こういう引数
ドメイン駆動設計読んだ - hitode909の日記
ドメイン駆動設計というのはソフトウェア工学のおしゃれな本で，Kindleで買えたので読んだ．ドメインを軸に戦略的に設計しましょうという本．2週間くらいで読めて良い体験できてよかった． ソフトウェアを，ユーザーインタフェース，アプリケーション，ドメイン，インフラストラクチャという4つの層に分けて，一番重要なのがドメイン層で，ドメイン層にアプリケーションが存在し得る理由がある．銀行システムだったら，口座とか利子みたなやつがドメイン層で，口座がよくできてると銀行としてうまくいく．ATMのタッチパネルというのはユーザーインタフェースで，どんなにATM押しやすくても，ドメイン層に，口座という概念がなくて，ただのハッシュだったりすると，銀行を運営して金を儲けるとか，新たな金融商品とか作るのが困難になる．インフラ層は永続化とかするのだけど，インフラ層がいかによくても，意味ないデータを保存していては銀行倒
高速にドッグフードを食べる方法 - hitode909の日記
はてなエンジニアブロガー祭りで「高速にドッグフードを食べる方法」という題で発表してきた． 箸でドッグフード食べるパフォーマンスの話ではなくて，もとはマイクロソフト用語である，Eat your own dog food，自社製品を使ってより良くしよう，みたいなほうの話．はてなブログ開発しながら毎日使うとか，思い付きで作ってるわけではなくて，事実や根拠にもとづいて作ってるとか，安全に作るための仕組みとか，そういう話． 普段の勉強会では僕は主に3分くらいのLTをしていて，20分も話したことなかった．資料ぜんぜんできなくて，Keynote見るだけで疲弊してた．急に長くていい話できるはずないと思って，LT5連発という形にして，ドッグフードにまつわる話を5個するという形にしたところ，なんとかなった． 東京では情報が氾濫してるから，京都でこんなのやってますとか言っても，東京では常識みたいな冷たい反応をさ
テスト書きすぎ問題 - hitode909の日記
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
HTMLとJSだけで何か作るときの - hitode909の日記
HTMLとJSだけで何か作ることが多くて，開発環境をどう作るかとか，ノウハウみたいなのがたまってきたと思う． ローカルのHTMLファイルをブラウザで開くと，いろんな制約がある．たとえば，ファイルAPIを使えないとか，YouTubeのプレイヤー貼り付けできないとか，/js/みたいに絶対パスで指定することもできない．ページ1枚なら他のページにリンクとかいらないけど，ウェブサイトを作ってるときとかは，/help/でヘルプページを表示するとか書いたときに，ローカルのファイルを見てリンクが切れてるということになる．開発中はリンク切れだけど本番サーバーに置くと見れるはずとか言って開発するのは怖い． サーバーでRubyとかPerlが動いてるみたいなときはローカルでサーバーを立てて開発してると思う．HTMLとJSだけ使うときでもローカルでサーバーを立てて開発したほうがいいと思う． 開発中は，nginxでフ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
