AMP Conf 2019に行ってきた - hitode909の日記
AMP ConfはAMPの最新情報を教えてもらえる二日間のカンファレンスで、午前中3セッション午後8セッションみたいな、詰め詰めの会。 年に1回世界のどこかで開催される会で、発表ほぼ英語、7:3くらいで7が海外の方で、廊下でコーヒー飲んでるとハローあなたのジョブはなんですかみたいな感じで英会話が始まり、インドの方と仲良くなってinstagramやtwitterのアカウントなど交換した。 印象に残ったことをメモしておく。 amp-script AMPではJSの実行が不可能だったのが、ついに可能になった。Web Workerで実行される。 なんでもできてしまうとHTMLと同様動作が重くなってしまうので、なんでもできるわけではなく、ユーザーのインタラクションきっかけで動く、一度の実行は5秒以内、150KBまで、などパフォーマンスを維持するための制約がある。 凝ったこともやればできるようで、デモで
この夏インターン給料で買いたいおすすめ本 - hitode909の日記
会社でLT大会があって，いまインターンが来てるので，3分で若者におすすめ本を紹介する活動を行った． 本を読みましょう 大学にいると教科書とかあって，教授もいて，勉強できるけど，社会に出たら教科書ないから，自主的に勉強する必要がある．仕事をしながら学ぶというのあるけど，それだけでは不十分だと思う．仕事してるだけだと，今持ってる技しか出せなくて，生まれ持った技術だけでどうにかすることになる．外科医は手術するのが仕事だけど，手術しかしてない医者いたら心配だと思う． 脳外科医が週60時間も執刀していたとして、そんな医者にかかりたいと思うでしょうか？ かかりたい人はいないはずです。プロには、備えるための時間、知識と技術を高める時間がどうしても必要なのです。 プログラマが知るべき97のこと 長時間働かないだけでなくて，あいた時間で勉強しないといけない． 本，会社で買ってもらえる制度あるけど，読んだ本あ
レガシーソフトウェア改善ガイド読んだ - hitode909の日記
去年出てた本．レガシーコード改善ガイドとは別の本．アーキテクチャの改善の話． FindBugsとかでメトリクスを取りましょうという話，コードを良くしましょうという話，アーキテクチャを改めましょうという話，どうにもならないのですべて書き直しましょうという話，あたりがおもしろかった．開発環境セットアップやドキュメントの話などもあるけど，そのあたりは普通にやればいいので目新しさはなかった． ちょっとしたテクニックで，こういうときにロジックをViewからViewModelに移すとViewがスッキリして便利，という話が載っていて，ちょうど困っていたところなので，早速チームで議論していて取り入れることにした． どうリファクタリングしてもどうにもならないので完全に書き直す，という話も載っている．リライトの知見を教えてくれるのだけど，それを読んでいると胃が痛くなる． 最初に明らかにしておくが、完全な書き直
人月の暗黙知の本 - hitode909の日記
見積りについて興味が出てきたので読んだ．コードコンプリートを書いたスティーブマコネルの本． 具体的な見積りの技法が紹介されているけど，それよりも，いい話がたくさん書いてあって良かった． 見積りとターゲット 見積り=作業量とか規模とか ターゲット=いつまでにほしいとか 数ヶ月後の発表会のための開発なら，その規模のものは作れませんではなく，間に合うような物を一緒に考える 技術的な知識を使っていろんな代案を出すのは技術者の責任 即興で見積りしてはいけない→正確ではない 専門家の判断は品質が低い→正確ではない 計算できるなら計算しなければならない 見積りに幅を持たせる この期間で終わる確率は何%とか，最良で何週間， 最低で何週間，とか そのときも計算する 高く見積るとプロジェクトが却下されるからといって安く見積ってはいけない 正しい情報を提供できないので，意思決定できなくなってしまう リソースが本
ImageMagickでliquid rescaleする - hitode909の日記
ImageMagickのリサイズまわりの挙動を調べてたら異常なアニメーションGIFが掲載されいているのを発見して，その瞬間に調べ物はどうでもよくなった． 領域が狭くなると，文字が帽子の上に周りこんでいる． http://www.imagemagick.org/Usage/resize/#liquid-rescale Seam carving(liquird rescale)は画像のなかで自然に切り取れるところを探してリサイズする技術．物がないところを探して切り詰めるので物だけが残る． Seam carving - Wikipedia ImageMagickをliblqrつきでインストールすると使えるようになる． brew install imagemagick --with-liblqrオライリーの書影とか見るからに縮めやすくてめちゃくちゃ楽しいのでは?と思ったので練習． Docker 作
テスト先に書きたい若者よ - hitode909の日記
弊社では毎年インターンを受け入れているのだけど，いまもインターンが来てて，テスト先に書きたいけど油断すると先に実装を書いてしまう，とか話してた． 個人的には，テスト先に書くのが大事というよりかは，意識して仕様を先に考えるのが大事だと思っている．テストを先に書くと，先に仕様を考えざるを得ないので，良いスタイルが身につく． 僕がよくやるのは，関連しそうなクラスの絵をひと通りノートに書いてみて，その図だけで，うまく動くことを説明できるくらい考えてみる．その時点でおかしかったら，コード書いてもおかしくなる．ノートに方眼ついてるとクラス図書きやすい．UMLとかじゃなくても，自分で見て分かるくらいでもいいと思う． 紙でうまくいったら，外部仕様だけソースコードに書いてみる．クラス名と，メソッドの定義と，メソッドの上くらいに，ひと通りコメントでも書いてみて，この関数はこういうことをするんです，こういう引数
ドメイン駆動設計読んだ - hitode909の日記
ドメイン駆動設計というのはソフトウェア工学のおしゃれな本で，Kindleで買えたので読んだ．ドメインを軸に戦略的に設計しましょうという本．2週間くらいで読めて良い体験できてよかった． ソフトウェアを，ユーザーインタフェース，アプリケーション，ドメイン，インフラストラクチャという4つの層に分けて，一番重要なのがドメイン層で，ドメイン層にアプリケーションが存在し得る理由がある．銀行システムだったら，口座とか利子みたなやつがドメイン層で，口座がよくできてると銀行としてうまくいく．ATMのタッチパネルというのはユーザーインタフェースで，どんなにATM押しやすくても，ドメイン層に，口座という概念がなくて，ただのハッシュだったりすると，銀行を運営して金を儲けるとか，新たな金融商品とか作るのが困難になる．インフラ層は永続化とかするのだけど，インフラ層がいかによくても，意味ないデータを保存していては銀行倒
テスト書きすぎ問題 - hitode909の日記
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
