ささいなことに、わざわざ「良いと思います！」って言うようにしている - hitode909の日記
いろんな人の相談役をやっているのだけど、ささいなことに、わざわざ「良いと思います！」って言うようにしている。 この調子でいいと思います！ってわざわざ言う 言われた方からは、迷うことなく進めたら良いのだな、ということが伝わる 意見を言えるチャンスがあったら「この調子でよさそうだけど、ゆくゆくはこんな問題に直面しそうですね」とか、ちょっと意見をはさんでおく 頭出ししておいたら考えてもらえるかもしれないし、想定と違ったら、えっそんなことはないんですけど…と早めに変なことに気づけるかもしれない シニアっぽいロールの人物としては、聞かれてもないのに、良いと思います！って言っておくのが大事。 やってみてもらって、うまくいかなかったら、想定と違ってうまくいかなかったんですけど、って声をかけてもらえる。 最初の段階で黙っていたら、どういうスタンスだったのか不明で、相談しにいくときに、まず、どう思いますか？
リーダーっぽい人が忙しくても、忙しいって言ってると感じが悪い - hitode909の日記
すみません、私から発表があります！忙しくて、マジむかつくんですけど、とかチームの朝会で発表してしまうと、一緒にやってるメンバーからすると、そんなに忙しいのなら声かけるのを遠慮しとこう…となり、会話タイミングが減ったりして、それによってあとで来月そのリカバリでさらに大変なことになり、さらに忙しく、こんなことなら先月のうちにしっかりやっておくべきでしたな、ということがありえるので、あまり、忙しくしていても、忙しすぎる、って言えない、という問題がある。 よく、ここは問題VS私たちでいきましょう、とか言うけど、主にメンバーたちと仕事している場合は、問題←→私たち←→私、で、私は直接問題と繋がっていない、私たちの手助けをしている、ということがあって、問題の先が私たちにいきつくので、あまり具体的なProblemを連発しづらくて、毎日の会話の実りが少ない、とか、ペアプロの進捗が悪い、とか言うと、個別のメ
どれくらい分かり合っておくべきなのか - hitode909の日記
技術検証とかやるときに、夢のおもしろ新技術の練習をしていると、おもしろさ、夢っぽさゆえに、導入しましょう!!となる力が働いてしまう。現在レガシー寄りの構成で、モダンな技術を試すときとかは、成功を願ってしまう。 移行先で今の苦しみが解消されているかは要確認で、技術スタックの問題ではなくて、ビジネスロジックの複雑さが現れているだけだったら、複雑さがそのままスライドして再構築されるだけだったりする。 というときに、粗探しをする前提の人を任命しておくと良いかもしれない。粗探しをするつもりでなくても、関係者が同質的すぎるときは一歩引いてバランスが取れているか確認する必要がある。 ちょっと別の話で、チームメンバーとどれくらい信じているものが同じことを期待するかという話題があって、 似たような人が集まっていると話は早い 合意形成が楽 結論が偏る恐れがある いろんな人がいると意見の偏りを防げる 合意形成は
子の泣いてる時間を観察したくてM5StickCで泣き声モニタを作った - hitode909の日記
深夜に絶叫する子を抱っこしていると、いつから泣いてるのか、いつまで泣いてるのか、など考えてしまって精神的に参ってくる。 実際のところどれくらいのペースで泣いてるのか可視化したくなって、M5StickCで可視化するグッズを作った。 作りたいもの 常時マイク入力がオンになっていて、直近しばらくの音量の履歴が可視化されたら便利そうだと考えた。 可視化によって子が泣き止むわけではなくても、「しばらく泣いてる気がしたけどまだ3分くらいだ」とか、「10分間に渡って静かにしていて偉い」とか数値を見て客観的な考察をできるようになりたい。 M5StickC M5StickCは小型のM5Stack。 小さくて邪魔にならなさそうなのと、マイクがついているので買ってみた。 3000円以下で買ってきて書いたコードが動いて画面に表示もできるのでおもしろいと思う。 www.switch-science.com 実装する
開発中の機能を小分けにして本番環境にどんどん出すためには - hitode909の日記
ふだんの開発では，稼働中のシステムに影響を与えないように開発中の新機能や新システムを共存させながらちょっとずつデプロイして進めている．どんな事を考えてやっているか記しておきます． フィーチャートグルを使う すべてのコードが本番環境に入っているけど無効化されている状態で開発を進める ブランチをたくさん作るのに対する考え方で，フラグを有効にすると開発中の機能を使える スタッフなら有効にしたり，フィーチャーのオンオフを選べる画面を作ってたこともある フィーチャーブランチを利用した開発はチームを継続的インテグレーションから遠ざける – ゆびてく FeatureToggle 完成したらフィーチャートグルに関係なく全員に有効状態にして完成 フロントエンドの施策で，実際のデータやインフラ構成でどれくらいスピードが出るかわからないときに，ひとまずフラグをオンにすると動く形でデプロイしたりとか レイヤの下の
危険予測トレーニングに興味が出てきた - hitode909の日記
道にボールが飛んできました。このあとどうなりますか？というと、子供が飛び出てくるに違いない。子供が飛び出てこなくても、子供が飛び出てくるに違いないと仮定して進めることに違和感がある人はいないと思う。 それは危険予測トレーニングとして考えが定着しているためである。 ソフトウェア開発をしていると、設計上の相談、とか、実装上の相談、とかで呼ばれることがある。 相談するときに主にやっていることは、このまま進めたときの危険は何かを指摘する、ということ。 ユーザーからは同じように見えるけど実装が全然別の物を作ろうとしています、と言われたら、そのまま進むと微妙な仕様の差異に、サービス提供者、ユーザーともども、苦しむことになるでしょう、みたいな。 完璧に危険を予測して対策ことはできなくて、死角からスケボーで子供が滑り込んでくることへの対策は、起きる確率が低いので対処を見送りましょう、みたいな、どこまでやる
チームのScrapbox3000ページくらいを見返して整理した - hitode909の日記
会社でScrapboxを使っている。チームごとやプロジェクトごと、話題や趣味ごとにプロジェクトを作っていて、うちのチームは1年3ヶ月くらい使って3000ページほどに達している。 どんどん書いていたのだけど、最近、どこに何があるかわからなくなってきていた。同僚に、ここの仕様はどうでしたっけ、って何度も聞いてしまうことがあったので、これはまずいと思ってちょっと整理していた。 表記揺れを直す One Fact in One Placeということで、どんどんページをマージしていった。ページを同名にリネームするとマージボタンが出現して押すだけなので楽。 よくみるとスペースの有無によって同じ話題のページが2ページに分かれていたり、略称と正式名称と、「(正式名称)まとめ」の3つにわかれたりしていた。情報を探しているときにはどんどんマージしたりしないので、今回マージするぞと見返せてよかった。 サポート担当
LGTM画像は見た目はおもしろいけど遊んでいるわけではない - hitode909の日記
YAPCのスポンサーセッションで，DeNAの採用担当の方が話されていて，エンジニア文化への憧れから，コードの意味は分からないけど勝手にLGTMしたり，会場の発表スライドに載せるには不適切な画像を貼ったりしている，という発表をされていた． 単に迷惑そう，と思ったのと，それ以上に悲しくなって，自分たちが大切にしていることを軽んじられると悲しい気持ちになる． LGTMな画像を貼るのは，傍目から見ると，にぎやかな画像が出てきて楽しそうな雰囲気があるけど，画像を貼る前にはコードが正しいか検証しているのであって，ミスの許されないシリアスな場所でもある． 見た目がおもしろそうだからといって遊びに来られると迷惑だし，そういうライトな活動をするような，遊んでいるように思われていたのか，という悲しさがある． 逆に，そんなシリアスな活動をしているなら，そうと分かる真剣そうな雰囲気になっているべきという気もして，
今年が2015年だと思って2015って書いておかしいなとか言って1時間くらい無駄にした - hitode909の日記
ふだんソフトウェア作ってるけど，僕はエンジニアとしてはめっちゃしょぼい感じで，こないだは今年が2015年だと思って2015って書いておかしいなとか言って1時間くらい無駄にした．1時間後に2016に直したのだけど，すごいエンジニアの人を見てると，その1時間の間くらいでも，すごい活躍されていたりする． みんな1日n時間くらい働いているはずで，すごいエンジニアはそのm倍みたいな時間働かれているわけではない．同じくらいの時間活動していても，活躍度合いは全然違う．ということは?? コードを書くのが速い 速くできるとすごい 腕の筋肉がすごい タイピング速そう 考えるのが速い 人によってそんなに差あるものなのか? 取り組むと効果ありそうなことを見極めるのがうまい いいことできるとすごい やっても大した効果が出ないものは後回しにするとその時間を使って効果のあることをできそう ちょうどいい作りこみ度合いのも
全部片手で打てる長い単語を探す - hitode909の日記
きのう，英単語の綴りの感じを調べるのを作った． 英単語がQWERTY配列上で右か左か調べるやつ作った - hitode909の日記 これを使って，/usr/share/dict/wordsに登場する単語のうち，全部右手か全部左手で打てる長い単語を探した． All rights phyllophyllin miminypiminy hypophyllium polyphonium hypolimnion hypophyllum Plynlymmon polyphylly polyphyly homophyly pollinium homophony monophony minikinly nipponium philonium hypophyll okupukupu polyonymy polyphony polyonomy nonillion lupulinum philliloo mil
プログラミングとは何なのか - hitode909の日記
会社でボードゲームしてる人たちがいる。 僕はボードゲーム苦手で、たまにやっても全然勝てない。 将棋とかイメージすると、こっちがこういう手を出すと相手はどうするか、そしてその次は、というのを予測すればよいのだけど、なんかそれがめんどうで、なんでこんなこと考えないといけないのか、とか考えだしてくたびれてしまう。 ずっと論理的に考えるのが苦手で、すぐめんどうになってやめてしまう。 普段、仕事や遊びでソフトウェア作ってるのだけど、よく考えると、ソフトウェアの動作が論理的なだけで、ソフトウェア作るのは勘でできる。 ソフトウェアが正しく動くかどうかは論理的に決められて、電卓アプリなら計算結果が狂ってたら間違っているけど、その電卓アプリがどのように作られたか、には正しさはない。逆立ちして作っても、猿にタイプライターを渡して作っても、計算結果合ってれば良い。 過去のデータとか経験によると猿に書かせるのは効
テスト先に書きたい若者よ - hitode909の日記
弊社では毎年インターンを受け入れているのだけど，いまもインターンが来てて，テスト先に書きたいけど油断すると先に実装を書いてしまう，とか話してた． 個人的には，テスト先に書くのが大事というよりかは，意識して仕様を先に考えるのが大事だと思っている．テストを先に書くと，先に仕様を考えざるを得ないので，良いスタイルが身につく． 僕がよくやるのは，関連しそうなクラスの絵をひと通りノートに書いてみて，その図だけで，うまく動くことを説明できるくらい考えてみる．その時点でおかしかったら，コード書いてもおかしくなる．ノートに方眼ついてるとクラス図書きやすい．UMLとかじゃなくても，自分で見て分かるくらいでもいいと思う． 紙でうまくいったら，外部仕様だけソースコードに書いてみる．クラス名と，メソッドの定義と，メソッドの上くらいに，ひと通りコメントでも書いてみて，この関数はこういうことをするんです，こういう引数
■ - hitode909の日記
Simejiのやつ、若手研究者がやったことになってるけど、やったのはいいとして、対外的にもそのように発表してるのはひどい。 研究員と言うよりは、電車の運転手に似てると思って、電車は運転手が寝坊すると止まって、客にもそのことが発表される。代わりの運転手が控えてるとか、組織として失敗をカバーしてくれない。 成功したら組織の成果だけど失敗したら個人の責任になるようでは、新しいことできないと思う。運転手なら運転してればいいけど、研究員そんなことでいいのか気になる。 ユーザーのみなさまへ - Android用日本語IME Simeji もう一つ思ったのは、なんか実験するときにはrobots.txt見たほうがよいということで、手頃なライブラリあったのでこういうので調べられそう。しかし毎回こういうの被せて使うのも疲れるので、何もしなくても悪いことにはならないようになっててほしい気もする。プロトタイプとか
プレゼンテーション - hitode909の日記
プレゼン自分ではすべったことないから得意だと思ってるのでいつも気をつけてることをシェアします。これさえ守ればすべらないのだから楽。 目次 目次 最初にめちゃくちゃおもしろい話をする 箇条書きせず一行ずつページを分ける 絵をでかくする 新しいページ作ったらデフォルトのパーツを全部消す 先に言う 意見や疑問を述べる スターウォーズエピソード4を見る 最初にめちゃくちゃおもしろい話をする 聴衆は懇親会のことしか考えてないので、とりあえず最初におもしろい話をして、注意を引きつけるとよい。つかみはこれでオッケーだって言えればよいくらいの面白い話をしましょう。よくある技術ブログとか、技術雑誌だと、こんにちは、最近温泉に行って心身共にリフレッシュしました、ヒトデです、とか書いてあるけど、そんなの読んで喜ぶ人が本人と家族と親類以外にこの世にいたらおかしいから、そういうのじゃないとよい。 箇条書きせず一行ず
失敗する前提でデプロイする - hitode909の日記
うちのチームでは，デプロイするたびに自動的にgitのtagを切るようにしてる．たとえば，いまデプロイしたら，deploy/2014-02-01-14-48とか． たまに，リリースした直後になんかミスってたことに気付いて，慌ててロールバックすることがある． tagを切ってるので，ひとつ前に戻せばいいのだけど，えっと，どれだっけとかいって探すので慌てるし，普段はタグ指定してデプロイしてないので，どうやって戻すか忘れる． デプロイ終わったときに，今回のデプロイを戻すには，これをしましょう，とか表示するようにした． デプロイ終わったらこんなのが出る．前回のデプロイが昨日だったら昨日くらいのタグが出る． ヒント：戻すときは以下のコマンドを実行しましょう cap -S revision=deploy/2014-01-31-15-17 deploy 実装方法としては，こんな感じに，デプロイ前に最新のタグ
テスト書きすぎ問題 - hitode909の日記
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
Rubyで2ちゃんねるのスレを読む - hitode909の日記
Rubyで2ちゃんねるのスレを読みたかったので，調べてみると，2ちゃんねるBOTの作り方を詳細に解説してくれている人がいた． 2ちゃんねるBOTの作り方 準備編 - GIOの日記 2ちゃんねるBOTの作り方 設計編 - GIOの日記 2ちゃんねるBOTの作り方 実装編1 - GIOの日記 2ちゃんねるBOTの作り方 実装編2 - GIOの日記 記事内のソースコードのリンクは切れていたけど，GitHubで公開されてた． gioext/bot2ch · GitHub スレの内容をパースする処理とかがなかったので，forkして欲しい機能を勝手に実装した． hitode909/bot2ch · GitHub 試しにこれを使って，ラーメン板の，タイトルにこってりを含むスレの最新のレスを表示してみる． require 'bot2ch' menu = Bot2ch::Menu.new board = m
Phantom.JS 練習 メモ - hitode909の日記
昨日ちょっとPhantom.JSの練習した． Phantom.JS PhantomJS: Headless WebKit with JavaScript API PhantomJS is a headless WebKit with JavaScript API. インストール brew install phantomjsQt4が必要でインストールに時間かかる 実行 phantomjs a.js とか phantomjs a.coffee で実行 CoffeeScript実行できる ただし，コンパイルできないときにどこが悪いかとかは教えてくれない phantom グローバルにphantomというオブジェクトがある phantom.exitとか phantom.argsとか console.log console.logでコンソールに出力できる ページ開く WebPage#openでページ開
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
