タグ

ブックマーク / blog.sushi.money (32)

  • ご家庭で樽生ハイネケン5リットル飲めるソリューション - hitode909の日記

    ハイネケンのドラフトケグを買ってみた.ご家庭で樽生ハイネケン5リットル飲めるソリューション. 炭酸ボンベや氷は不要で,こういうでかい缶単体で駆動する.缶ごと冷蔵庫で冷やしておけばなんとかなるという仕組み. View this post on Instagram A post shared by 趣味はマリンスポーツです (@hitode909) こういう蛇口みたいのを上にくっつけて注ぐ.丁寧にゆっくりやると泡とビールがいい割合になるけど,雑に速く飲みたいみたいなマインドでやってるとほとんど泡になったりする. View this post on Instagram A post shared by 趣味はマリンスポーツです (@hitode909) ビールが出てくる蛇口を手に入れたような状況で,ちょろちょろプラスチックのカップに注いではしゅっと飲む,のを繰り返して,たのしいたのしいって言って

    ご家庭で樽生ハイネケン5リットル飲めるソリューション - hitode909の日記
  • EmacsからAtomに乗り換えた - hitode909の日記

    ここ数年間,Emacsのアップデートについていけてなくて,アップデートする気力も失われていることに気付いたので,Atomに乗り換えることにした. 最初はググッたりしてよくわからないままに使っていたけど,とりあえずこのを読んだらだいたい分かった. Atom実践入門──進化し続けるハッカブルなエディタ (WEB+DB PRESS plus) 作者:大竹 智也発売日: 2016/07/14メディア: 単行(ソフトカバー) あとはふつうにマニュアルを眺めたりした. http://flight-manual.atom.io/ きのうはコード書こうとしても全然だめな感じだったけど,今日はふつうにコード書けるくらいになって,夜はパッケージを作ってみたりして様子を見ていた. APIがあって操作できるのはEmacsと同じ雰囲気だけど,AtomのAPIのほうがモダンな感じ.ふだん住んでるウェブの世界と近く

    EmacsからAtomに乗り換えた - hitode909の日記
    TokyoIncidents
    TokyoIncidents 2016/11/16
    [atom]
  • はてなブログのAMP対応で学ぶウェブサービスのAMP対応 - hitode909の日記

    プレゼンモード 再生 ← / →で移動 fでフルスクリーン escでおわる こんにちは,id:hitode909です.このあと14時から品川のマイクロソフト様のオフィスでおこなわれている,YAP(PはパチモンのP)Cで発表します. この記事では,発表資料を公開いたします.現地の方は今すぐCルームに来てください.そうでないかたは懇親会でお会いしましょう. はてなブログのトピックもあるようです. トピック「YAPC」 #yapc8ojic のツイート はてなブログのAMP対応で学ぶウェブサービスのAMP対応 2016/07/03 YAP(achimon)C::Asia Hachioji 2016 mid in Shinagawa hitode909 自己紹介 id:hitode909 @hitode909 京都から来ました はてなはてなブログを作っている 自己紹介 YAPC 2015でベスト

    はてなブログのAMP対応で学ぶウェブサービスのAMP対応 - hitode909の日記
  • なぜひどいコードを書いてはいけないか - hitode909の日記

    ひどいコードは何やってるか分からない ひどいコードが何やってるか分かっても、なぜそうなってるのか、そこを変えるとどうなるか分からない ひどいコードは新たな変更に耐えられず書き直されることになる ひどいコードを書き直すには、ひどいコードがどうなっているか理解し、どこを変えるとどうなるのか理解する必要がある ひどいコードはたいていひどいテストコードが支えていて、テストコードがあったとしてもひどいコードと同様の問題があり、頼れるものが何もない どんなにひどいコードでも、書いた人を憎んではいけない。たとえ自分の書いたコードだとしても、先輩の書いたコードだとしても、ソフトウェアとしてひどい物にはひどいと言っていくことが大切で、だからと言って人に向かってひどいと言ってるわけではない。 最高の仲間たちが日々変化する難しい問題に対処していいコードを書いたり、ときにはひどいコードを書いている、という😇的な

    なぜひどいコードを書いてはいけないか - hitode909の日記
  • 70ページでドメイン駆動設計の要点を押さえられるDomain-Driven Design Reference - hitode909の日記

    Domain-Driven Design Reference,Amazon見てたら発見して,安かったから買ってみた. ぺらっとしてて,ポケット索引集みたいな雰囲気.エリックエヴァンスのドメイン駆動設計から,要約が抜粋されていて,70ページくらいで,重要な概念を押さえられる.原著は著者の経験を語ってくれるコーナーが大半を占めるけど,このではバサッと切られて,定義だけが載ってる. 前のから10年くらい経ったので,新しい内容も増えてる.ドメインイベントとパートナーシップ,巨大な泥団子.いずれも実践ドメイン駆動設計に出てきた. これだけ読んでドメイン駆動設計さあ始めよう,とはならないだろうけど,でかい読みたくないけど議論には参加したい,とか,どんなものか軽く眺めたい,みたいな人が読むにはてっとり早いかもしれない. 唯一役立ったのが前書きで,エリックエヴァンスのドメイン駆動設計ののことをTh

    70ページでドメイン駆動設計の要点を押さえられるDomain-Driven Design Reference - hitode909の日記
  • 作り直し - hitode909の日記

    ソフトウェアを作ってて、作り直したり、書き直したりするべきかどうかという話をすることがある。 大きな規模だと、ソフトウェアを作り直す、というところから、小さな規模だと、込み入った機能を書き直す、くらいまであるけど、作り直すとうまくいくのは、次の二つのうちどちらかではないか。 最初に作ったときより世の中の技術が発展したとき 昔のコンピュータでは収まらなかったとか、昔は良いライブラリがなかったけど、今はある、というとき。 単に今ありふれた技術で作り直すと、よいものができそう。 最初に作ったときよりはコンピュータのスペックが上がったので、そのつもりで、並列度倍に上げても止まらないし、より速く動かせる、とか。 昔はバッチで計算しないといけなかったけど、今ならリアルタイムに返せる、とか。 昔は依存管理のよいライブラリがなかったけど、今ならこれ入れたら簡単、とか。 最初に作ったときより人間の技術が発展

    作り直し - hitode909の日記
    TokyoIncidents
    TokyoIncidents 2015/09/08
    DDD 本を元にした勉強会に行っても今のところマインド的な話しか聞けないので懐疑的。永和さんみたいに「普通のドメイン駆動設計」とかないものだろうか。まずは本を読めということなんだろうけど…
  • 気が狂った設計 - hitode909の日記

    大きめのこととか,自信のないところを触るときは,コード書く前に,こういう作戦考えてみたけどどうですかって聞いてみたり,こういうことやりたいんだけど一緒に考えませんかって,いっしょに話して設計考えたりするとよいと思う. 一緒に考えたすぐあとに気が狂った設計とか言い出したらおかしいので,未然に変な設計のままコード書いてしまうのを防げる. 特に辛い気持ちになるのが、「気が狂った設計」「クソコード」「(こんな実装は)有り得ない」といった言葉だ。 Pull Requestのレビューが辛くて会社をやめたい 単に言葉が強いのはよくないと思う.我が社にはそんな強い言葉でレビュー書く人はいない. 我が社には,普段から強い言葉を発する人もいなくて,みんな物腰柔らかな変な言葉を話している. 言葉使いや文体は,ずっと過ごしてると同僚から移ったりするので,普段からそういう言葉を話していると,全体の雰囲気も悪くなりそ

    気が狂った設計 - hitode909の日記
  • できる男にオススメの栓抜きになるベルト - hitode909の日記

    このパタゴニアのベルトはいいやつで、金具が栓抜きになるので、万が一の時にさっとビール開けられる。 こういうのがあれば、温泉Macのアダプタ破壊せずに済む。 また、こんなのなくても、フロントで栓抜き貸してもらえると思う。 (パタゴニア)patagonia Tech Web Belt 59190 ANDB ALL 出版社/メーカー: patagonia(パタゴニア)発売日: 2014/08/08メディア: スポーツ用品この商品を含むブログを見る できる男はMacのアダプタで栓を抜く -720p版- - シバソンブログ

    できる男にオススメの栓抜きになるベルト - hitode909の日記
  • テスト先に書きたい若者よ - hitode909の日記

    弊社では毎年インターンを受け入れているのだけど,いまもインターンが来てて,テスト先に書きたいけど油断すると先に実装を書いてしまう,とか話してた. 個人的には,テスト先に書くのが大事というよりかは,意識して仕様を先に考えるのが大事だと思っている.テストを先に書くと,先に仕様を考えざるを得ないので,良いスタイルが身につく. 僕がよくやるのは,関連しそうなクラスの絵をひと通りノートに書いてみて,その図だけで,うまく動くことを説明できるくらい考えてみる.その時点でおかしかったら,コード書いてもおかしくなる.ノートに方眼ついてるとクラス図書きやすい.UMLとかじゃなくても,自分で見て分かるくらいでもいいと思う. 紙でうまくいったら,外部仕様だけソースコードに書いてみる.クラス名と,メソッドの定義と,メソッドの上くらいに,ひと通りコメントでも書いてみて,この関数はこういうことをするんです,こういう引数

    テスト先に書きたい若者よ - hitode909の日記
  • はてなブログ編集画面JSのページャ見どころ紹介 #pagernight - hitode909の日記

    昨日,ページャNightという勉強会で,はてなブログのJSの見どころを紹介するLTをした.(昨日の日記). 資料公開しようかと思ったのだけど,発表資料そのまま公開しても意味不明なので,エントリに書き直すことにした. たとえば,このLGTM画像は発表資料の1枚目で,もし発表資料をそのまま公開したら,こういう謎の画像を解説もないまま見ることになっていたはず. JSのページャいっぱいある はてなブログの編集画面には編集サイドバーというのがあって,写真とかAmazon検索とかTwitterとかinstagramとかあれこれ貼れるようになってる. Amazon検索しても画面遷移するわけじゃなくて,ウェブ2.0という感じで,XHRでJSONを取ってきて,HTMLを組み立てて表示,クリックすると選択,貼り付けを押すとエディタに挿入される,という仕組み. 編集サイドバーから貼れるサービスは10種類くらいあ

    はてなブログ編集画面JSのページャ見どころ紹介 #pagernight - hitode909の日記
  • 一回だけ通信したいようなとき - hitode909の日記

    ボタン押したらXHRでなんか取ってきて表示するみたいなとき、resultっていう変数を用意したり、XHRオブジェクトを取って置いたりしてたけど、underscore.jsとかのmemoize使えばきれいに書ける気がした。 get = _.memoize -> $.get 'a.txt' $button.on 'click', -> get().done (res) -> alert res これで通信一度だけになればスッキリする。気になる点としては、引数なければmemoizeできないかもしれない。この記事iPhoneで書いてて上のコードは動かしてない。動かなかったらなんか自分で書けばいい。とにかく、自分でXHRのオブジェクト取っておくんじゃなくて、wrapした一般的な関数が持っておいてくれるとかわいいということを言いたかった。ロジック体と、そのキャッシュの仕組みが分離されると良い。XHR

    一回だけ通信したいようなとき - hitode909の日記
  • 設定のクラスを作るとすっきりしそう - hitode909の日記

    設定のテストを書くとよいって言ってる人がいた. 設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog; テストされてるのはよいと思う.名前のついてないデータ構造をがんばってテストするよりは,設定のクラスを作るとすっきりしそうと思った. こういう構造のHash,として見るよりかは,設定クラスのインスタンスとして見るほうがイメージしやすい. 個々のブログの設定のURLはユニークであるというのを,どこかのクラスの責任にする.BlogConfigRepositoryというクラスのインスタンスが,設定の集合を持ってるとか. like exception { BlogConfigRepository->new([ { "url" : "http://blog.example.com/", "permission" : "public", "members"

    設定のクラスを作るとすっきりしそう - hitode909の日記
  • コードレビュー - hitode909の日記

    コードレビュー,慣れるとできるけど,いきなりdiffを渡されて,どうぞ見てくださいと言われてもよくわからないと思う. やりましょうというのはいいけど,ただむやみに読んでもうまくいかない.変更がある程度大きくなるとdiffだけ見てもよくわからないので,いろいろ見ることになる. 僕はいつも以下のようなことを無意識にやってて,うまくいってる気がしてる.GitHubのPull Requestの仕組みを使ってる前提で. Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て,テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく.あとで書き直されるかもしれないので,まだコメントしない 全コミット見終わったらFiles

    コードレビュー - hitode909の日記
  • ドメイン駆動設計読んだ - hitode909の日記

    ドメイン駆動設計というのはソフトウェア工学のおしゃれなで,Kindleで買えたので読んだ.ドメインを軸に戦略的に設計しましょうという.2週間くらいで読めて良い体験できてよかった. ソフトウェアを,ユーザーインタフェース,アプリケーション,ドメイン,インフラストラクチャという4つの層に分けて,一番重要なのがドメイン層で,ドメイン層にアプリケーションが存在し得る理由がある.銀行システムだったら,口座とか利子みたなやつがドメイン層で,口座がよくできてると銀行としてうまくいく.ATMのタッチパネルというのはユーザーインタフェースで,どんなにATM押しやすくても,ドメイン層に,口座という概念がなくて,ただのハッシュだったりすると,銀行を運営して金を儲けるとか,新たな金融商品とか作るのが困難になる.インフラ層は永続化とかするのだけど,インフラ層がいかによくても,意味ないデータを保存していては銀行倒

    ドメイン駆動設計読んだ - hitode909の日記
  • 失敗する前提でデプロイする - hitode909の日記

    うちのチームでは,デプロイするたびに自動的にgitのtagを切るようにしてる.たとえば,いまデプロイしたら,deploy/2014-02-01-14-48とか. たまに,リリースした直後になんかミスってたことに気付いて,慌ててロールバックすることがある. tagを切ってるので,ひとつ前に戻せばいいのだけど,えっと,どれだっけとかいって探すので慌てるし,普段はタグ指定してデプロイしてないので,どうやって戻すか忘れる. デプロイ終わったときに,今回のデプロイを戻すには,これをしましょう,とか表示するようにした. デプロイ終わったらこんなのが出る.前回のデプロイが昨日だったら昨日くらいのタグが出る. ヒント:戻すときは以下のコマンドを実行しましょう cap -S revision=deploy/2014-01-31-15-17 deploy 実装方法としては,こんな感じに,デプロイ前に最新のタグ

    失敗する前提でデプロイする - hitode909の日記
  • UI変更批判バトルと複数のバージョンのウェブサービスを同時に配信することについて - hitode909の日記

    ウェブサービス,UI変えると,改悪とか,元に戻してとか,そういう意見が出る. サービス提供する側の立場では,新しいUIのほうが使いやすかったり,機能が増えたり,収益が増えたりするので,新しい方を多くの人に提供することに価値がある.使いやすいかとか,儲かるかとかは,リリースまでに調べておく必要があり,リリースの結果使いにくくなったり収益減ったりしたら,失敗ということになる. 一方で,ユーザーの立場からすると,前の方がずっと使ってて愛着があったとか,新しい方を覚えるのは手間とか,確かにという感じはする.また,ウェブサービスは最終的にユーザーの手元のブラウザで表示されて動くので,映画の結末が気に入らないから変えたいといった要望よりは,受け入れやすい.データ構造についての,サーバー側の処理についてのユーザーからの要望というのはあまりなくて,このボタンがどうみたいな,UIの要望が多いと思う. 全部置

    UI変更批判バトルと複数のバージョンのウェブサービスを同時に配信することについて - hitode909の日記
  • 高速にドッグフードを食べる方法 - hitode909の日記

    はてなエンジニアブロガー祭りで「高速にドッグフードをべる方法」という題で発表してきた. 箸でドッグフードべるパフォーマンスの話ではなくて,もとはマイクロソフト用語である,Eat your own dog food,自社製品を使ってより良くしよう,みたいなほうの話.はてなブログ開発しながら毎日使うとか,思い付きで作ってるわけではなくて,事実や根拠にもとづいて作ってるとか,安全に作るための仕組みとか,そういう話. 普段の勉強会では僕は主に3分くらいのLTをしていて,20分も話したことなかった.資料ぜんぜんできなくて,Keynote見るだけで疲弊してた.急に長くていい話できるはずないと思って,LT5連発という形にして,ドッグフードにまつわる話を5個するという形にしたところ,なんとかなった. 東京では情報が氾濫してるから,京都でこんなのやってますとか言っても,東京では常識みたいな冷たい反応をさ

    高速にドッグフードを食べる方法 - hitode909の日記
  • テスト書きすぎ問題 - hitode909の日記

    テスト書きすぎるとよくないって言ってる人がいた.DHHっていう人.作業時間の1/3以上テストしてたらおかしいとか,ActiveRecordのバリデーションなど,Railsの機能はテストしない,とか. Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で,テスト手抜き派の人に良い材料を与えてしまった.僕は意見ちがって,作業時間半分以上はテスト書いたりしてる. テストたくさん書くと,最初に書くときのコストは増える.けど,あとから読む時や,変更したい時には,読むだけだし,書くのも差分だけで良い.コード体を理解できれば,要らないテスト捨てるのは,落ちたのを消すだけだから簡単.あとで見て,テスト足りないと分かったときに,明文化されてない仕様からテストを補う

    テスト書きすぎ問題 - hitode909の日記
  • CasperJSで気軽にJSのテストできる - hitode909の日記

    ウェブアプリケーションのJSのテストするのにCasperJS使ったら便利だった. CasperJSはPhantomJSにテスト用ユーティリティがついて便利になったやつ. JS,MVCできれいに書いてると,Modelの単体テストとかできるけど,昔ながらの感じだと,ここをクリックしたらこれが表示されること,みたいなテストを書くことになる.けどライブラリとかいろいろあってどれを使えばよいか分からなくて敷居が高い.CasperJSを使ったらこれだけで完結してテスト書ける. PhantomJSは単なるブラウザだけど,CasperJSはテストのフレームワークとか,DOMのテスト関数とかがついてる. 非同期なタスクの実行の仕組みも入ってて,casper.thenっていうのを順番に書いていくと,順番に呼んでくれて,click()して,casper.thenしたら,ページ遷移したら次のページに移動してる.ス

    CasperJSで気軽にJSのテストできる - hitode909の日記
  • 株式会社はてなに入社しましたまとめ - hitode909の日記

    今年は70名の入社がありました. 株式会社はてなに入社しました - hitode909の日記 株式会社はてなに入社しました - 下林明正のブログ 株式会社はてなに入社しましたボタンを押しました - fuba のはてなダイアリー 株式会社はてなに入社しました - 新記記日記 株式会社はてなに入社しました - 半径50cmの記録 株式会社はてなに入社しました - nyanco15's diary 株式会社はてなに入社しました - 大海を知らず 株式会社はてなに入社しました - this A moment 株式会社はてなに入社できませんでした - ヤルキデナイズド 株式会社はてなに入社しました - 何を考えているのかわからない 株式会社はてなに入社しました - 音の鳴るブログ 株式会社はてなに入社しました - The Internet... 株式会社はてなに入社しました - 蟄居 株式会社はてな

    株式会社はてなに入社しましたまとめ - hitode909の日記