価値が出るポイントまで一気に進めてから次のタスクに取り組む - $shibayu36->blog;
以前同僚から、いくつかのプロジェクトやタスクを持っているときにどう進めると良いかという質問を受けた。僕はその時、価値が出るポイントまで一気に進めてから次のタスクに取り組むようにしていると答えた。この話についてブログに言語化してみる。 良くない進め方の一例 たとえばプロジェクトA（自分の担当分工数10日）、プロジェクトB（自分の担当分工数20日）で、合計30日分のタスクを持っているとする。この時良くない進め方は、両方ともを完全に並列に少しずつ行って、30日後に終わるということだ。1 このやり方だと30日後にならないとプロジェクトAもBも結果が出ない。もしプロジェクトAのみに集中して終わらせれば少なくともプロジェクトAの結果は10日後に出るのに関わらずである。 このやり方がまずいのは当たり前に見えるのだが、気をつけないとやってしまいがちである。なぜなら少しずつ進めれば、他の関係メンバーに「自分
開発生産性カンファレンス 2024を堪能してきました - $shibayu36->blog;
dev-productivity-con.findy-code.io 自分の所属しているクラスター社に相談したところお金を出してもらって参加できることになったので、開発生産性カンファレンス2024に行ってきました。自分が開発生産性に非常に興味が強いため各セッションすべて興味深く、またこれまで名前は知っているけど話したことのなかった人と色々と会話ができて、非常に堪能できました。 運営のファインディ株式会社のみなさん、ありがとうございました。 興味深かったセッション 顧客価値向上による開発生産性向上 顧客価値を高めるという観点にフォーカスした発表でした。 顧客価値を高める領域かは狩野モデルを使って考えるという話。狩野モデルはよく聞くが、ちゃんと使ったことないので試してみたい 当たり前品質は、品質を高めすぎても、顧客価値に繋がらない = アクセルブレーキなどの基本操作 一元的品質は、高めれば高め
スムーズに進行するためのエンジニアリングタスク分割の工夫 - $shibayu36->blog;
会社の振り返りで「エンジニアリングの作業タスクがうまく分割できていそうだったが、その知見を共有してほしい」と言われたので、自分がどう考えてタスク分割をしているかをこの記事で共有したい。 この記事のスコープとすること・しないこと タスク分割をするときの工夫点 少なくとも1スプリント以内で終わるタスクになっている 完了条件が明確である 開始から終了まで他タスクによる待ち時間がない 他タスクが待ち状態になる時間を最小限にする 自分にとって難易度の高いものが1タスクの中で1つである 初めから完璧なタスク分割を目指さない 工夫を考慮した分割例 まとめ この記事のスコープとすること・しないこと 今回の記事では、あるユーザーストーリーが存在するとして、その設計・実装・テストなどをスムーズに進行するための工夫について書く。 逆に次のようなタスク分割については取り扱わない。 ユーザーに提供すべき価値があると
TypeScriptで「Reactを自作しよう」をやってみた - $shibayu36->blog;
最近2分間コーディングのすすめ、コードを書く習慣のハードルを下げるに触発されて2分間コーディングをやってみている。まずは昔興味が出ていたReactを自作しようをやってみたのでメモ。 やった様子は https://github.com/shibayu36/building-own-react に置いた。メインファイルは https://github.com/shibayu36/building-own-react/blob/main/src/index.tsx create-react-appしたままだと色々おかしくなったのでejectして手直ししたり、JSXのtranspileを置き換えるためにwebpackの設定を少しいじったりしたところが苦労した。そのあたりについては https://github.com/shibayu36/building-own-react/commits/mai
メンターを初めて経験する人に、最初に読むものとしてオススメしている書籍たち - $shibayu36->blog;
社内ではこういうおすすめをしてますね(文字数多いのでスクショで...) pic.twitter.com/uzqCh6zubs— 柴崎優季 (@shiba_yu36) 2020年7月7日 こういうツイートして、そういえば社内でメンターを初めて経験する人にオススメしている書籍たちを外部に公開してないなと思ったので紹介してみます。 メンタリングのスキルを学習する時のキーワードは「コーチング」と考えていて、以下の書籍を推薦しています。上から順におすすめ順になっています。この推薦は網羅的にコーチングを学べると言うより、初めての人でもとっつきやすく読みやすいものであることを意識して選んでいます。また、メンタリングを始めるだけなら、書籍の全部分を読む必要はなく、どこまで読んでおくと良いかも書いています。 エンジニアリング組織論への招待 ザ・コーチ コーチングの基本 新1分間マネジャー エンジニアリング組
エンジニアと1on1をするときの事前面談シートテンプレート - $shibayu36->blog;
はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs
ISUCON8予選を突破した - $shibayu36->blog;
id:hitode909とid:takuya-aとチーム「ディメンジョナルハイソサイエティぬれねずみ」としてISUCON8に参加し、40867点で本戦に行けることになった。ISUCON初参加でいろいろ不慣れではあったが、なんとか本戦に行けて嬉しい！ サーバ複数台構成かつボトルネックになる箇所が結構面白いところが多く、非常に楽しめました。運営の皆様ありがとうございました。 振り返りとして、チームでやったこと・良かった進め方をまとめてみる。 チームでやったこと 開始直後は役割分担して作業していった。言語は勉強がてらgolangにしようと思ったこともあったが、せっかくなら勝ちたいし慣れてるperlにした。 shiba_yu36: 鍵置いたりコードのバックアップしたりなどといったオペレーション周り 他二人: アプリケーションの挙動を確認し、作戦を立ててもらう 以下が最初のオペレーションでやっていた
Google Mapのオフラインエリアが海外旅行で非常に役立った件 - $shibayu36->blog;
この前海外旅行に行った時に、Google Mapのオフラインエリアという機能が非常に役に立ったので紹介。 オフラインエリア機能とは オフラインエリアという機能は、特定のエリアのマップ情報をインターネットがつながっている時にダウンロードしておくことで、オフラインのときにも利用できるようにするものだ。通常日本にいるときは、このような機能を使いたいことはほとんどないので全く知らなかった。 今回の旅行中は海外でも使えるモバイルWiFiなどを借りてはいかなかったため、紙の地図を使って適当に探索しようと思っていた。しかし、この機能があることに気づいたので試してみると、ネットがなくても現在位置とマップが出るようになり、通常のGoogle Mapとほぼ同様に利用することができた。 簡単な使い方 特定地域を検索し、その地域の情報パネルを出し、ダウンロードボタンを押すだけ。詳しくは ダウンロードしたエリアをオ
Emacsで英和辞書や和英辞書をすぐに引けるようにしたい - $shibayu36->blog;
ちょっと調べてたら、 英語力を向上させたいのでまずは Emacs からはじめた | Futurismo google-translate.el : 【設定パワーアップ】Google翻訳で言語自動判別しつつ英訳・和訳する！ というような記事を見つけて、google-translate.elというのを見かけたので導入してみた。特にrubikitchさんの記事は自動で日本語か英語かを判定してくれるので、そのまま導入した。 動作 キーバインドはほぼ一つで以下の動作が出来ます。 インストール M-x package-install google-translateで。 設定する (require 'google-translate) (require 'google-translate-default-ui) (defvar google-translate-english-chars "[:asc
最近コード中のTODOコメントの書き方を工夫している - $shibayu36->blog;
コード中に後でやろうと思って以下の様なTODOコメントを書くことがあります。TODOコメントというのは # TODO: 後でリファクタリングしたい ... # TODO: 投稿機能ができたら置き換えること ... みたいなやつです。 コード中にTODOコメントを気軽に書いてしまいがちですが、よくTODOコメントが放置されて気づいたらプロジェクト中に大量のTODOコメントが書かれたりすることがあります。直せる量を超えてくると、直すモチベーションも下がってきて、結局ただのコメントと同じ状態になります。 最近いろいろ工夫して、TODOコメントの書き方を変えたところ、そこそこうまく回ったのでメモしておきます。 TODOコメントの問題点 問題点として次のものがあると考えました。 (1) 書く人によって形式がバラバラ TODO, XXX, FIXMEなどバラバラだったりする (2) TODOコメントの
「オブジェクト指向入門 第6章 抽象データ型」を読んだ - $shibayu36->blog;
オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者:バートランド・メイヤー翔泳社Amazon 「オブジェクト指向入門 第3章モジュール性」メモ - $shibayu36->blog; の続きで、「第6章 抽象データ型」を読んだ。 この章では、オブジェクトを適切に表現する記述として、抽象データ型というものを紹介している。これが非常に参考になったので軽く読書メモをとっておく。 抽象データ型とは 抽象データ型の仕様の記述とは以下の4つを記述することであるようだ。 TYPES(型) FUNCTIONS(関数) -> その抽象データ型に適用可能な操作の集合 AXIOMS(公理) -> その抽象データ型が必ず満たす条件 PRECONDITIONS(事前条件) -> 部分的な関数のソース集合の定義域 STACKの例を見
フロントエンド速度改善をしようとして参考にしたもの - $shibayu36->blog;
最近フロントエンドの速度改善をほんの少しだけやって、いろんな資料を参考にしたので、今後また速度改善をする時に備えて、参考になった資料をまとめておく。今回パフォーマンス改善やった項目としてはExpiresヘッダ付ける、gzip圧縮かける、JSをbodyの一番下にとか基本的なことしかやらなかったので、そのあたりはこの記事ではまとめていません。 今回は「測定する」「ブラウザがどう表示しているか知る」「改善を検討する」の流れで調べていったのでその順にまとめる。 測定する 何はともあれ測定しないと何も始まらないので、まずは測定の仕方について調べた。 PageSpeed Insights( https://developers.google.com/speed/pagespeed/insights/ )と、webpagetest( http://www.webpagetest.org/ ) はとりあえ
「がん保険を疑え！」を読んだ - $shibayu36->blog;
「生命保険のウラ側」を読んだ - $shibayu36->blog; に引き続き、がん保険についても知りたいので読んだ。前回の本が分かりやすかったので引き続き同じ著者の本を読んだ。 がん保険を疑え！ 作者:後田 亨ダイヤモンド社Amazon この本はがん保険について、保険会社が公開している情報に基づいて著者がある程度の推測を交えて実態を教えてくれる。「推測」となっているのは、現時点では保険会社が保険に関して詳細の情報をあまり公開していないため、推測にならざるをえないという事情がある。他にもがん保険に入る時の選定方法について解説し、またその方法で選んだ現時点でのおすすめがん保険も教えてくれる。 前の本も分かりやすかったけど今回の本も分かりやすかった。また分からない部分は分からないとはっきり書かれているのも印象が良かった。 この本の中で一番良かったのはがん治療費に対してどのくらいの目安を持てば
gulp + browserify + tsifyを利用してTypeScriptコンパイル環境を作る - $shibayu36->blog;
最近TypeScriptを書いている。TypeScriptはそのままではブラウザで動かないのでコンパイルしてES5の形式にする必要がある。tscを使えば普通にコンパイル出来るのだが、今回はgulp + browserify + tsifyを利用したTypeScriptコンパイル環境を作ってみたのでメモしておく。 必要なnodeモジュールのインストール typescript, gulp, browserify, vinyl-source-stream, tsifyが必要。 # globalにtypescriptを入れる npm install -g typescript # ビルドに必要なモジュールを入れる npm install gulp --save-dev npm install browserify --save-dev npm install vinyl-source-stream
emacsでweb-modeを利用してHTML + Xslate(TTerse)の環境でsyntax highlightする - $shibayu36->blog;
仕事でHTMLを書くときは大体HTML + Xslate(TTerse syntax)という構成でやっている。今まではhtml-modeを使っていたのだけど、流石にXslateのsyntaxがハイライトされないのだるくなってきた。そこでweb-modeというのが便利と見たことがあったので入れてみた。 インストールする package-list-packagesしてweb-modeを入れる。その後以下の様な設定を書く。 (require 'web-mode) (add-to-list 'auto-mode-alist '("\\.html?\\'" . web-mode)) (setq web-mode-engines-alist '(("template-toolkit" . "\\.html?\\'" ))) この設定をしておくだけで、 .htmや.htmlという拡張子の時にweb-mo
2015年振り返り - $shibayu36->blog;
今年はディレクターからエンジニアに戻ったり、引っ越しなどをして私生活が大きく変わったり、仕事がむちゃくちゃ忙しかったりと、何かと慌ただしい年だった。 ディレクターからエンジニアへ いろいろあってエンジニアに戻りたいということになったので、仕事はディレクターからエンジニアに戻った。ディレクター時代に自分のエンジニアとしての足りない部分がだいぶ分かってきていたので、今年は足りない部分をなくしていくということをしている。 Perl以外の言語を触った経験が少なかったので、ScalaやTypeScriptなどの言語を勉強した 静的型付け言語の基本みたいなのが学べてよかった 流行り技術は無視して、とりあえず基本的な分野について学んだ 文字コードについて学んだり、オブジェクト指向入門読んだり、セキュリティ周りのことを勉強したり けっこう良かったので今後も基本的な分野をちゃんと勉強しつつ、気晴らしに流行り
「師弟登壇2015」ではてなの研修について発表しました - $shibayu36->blog;
pepabo.connpass.com 「師弟登壇2015」ではてなの研修について発表してきました。 speakerdeck.com 今回の発表は 実践で手を動かすのが一番勉強になる 出来るだけ早く知識を身に付け、チーム配属できるように工夫している をテーマに話しました。久々に発表したら緊張して、最初の方全然調子出なかったので、定期的に前に出て発表しないとなあという気持ちになりました。 ちなみにこの発表の後に、@amagitakayosi くんが、新卒研修受けてないという発表をしてて面白いと思いました。まあなんにせよ実践でいろいろやってるのでよし！！！！ speakerdeck.com ちなみに自分の時はどうだったかな―って思ったら、amagiくんに下のような指摘を昨日受けてウケてました。なんで新卒の時から研修について考えているのか！！！！ こんなこと書いてるけど、最近はちゃんと研修やって
乱数の性質とセッショントークンの作成 - $shibayu36->blog;
ユーザアカウントのログイン機能とか作ってると、何らかの形でセッション用のトークンを作成する機会がある。今まではこれは適当にランダムな値を利用していればいいんでしょと思っていたのだけど、ちょっと違ったのでメモ。 乱数の性質 http://akademeia.info/index.php?%CD%F0%BF%F4によると、乱数には三つの性質がある。 無作為性：統計的な偏りがなく、でたらめな数列になっているという性質。 予測不可能性：過去の数列から次の数を予測できないという性質。 再現不可能性：同じ数列を再現できないという性質。再現するためには、数列そのものを保存しておくしかない。 この時、少なくとも無作為性のみ満たされていると弱い擬似乱数、無作為性と予測不可能性が満たされていると強い擬似乱数、全てが満たされていれば真の乱数と呼ばれる。ソフトウェアだけでは、真の乱数を作ることができず、真の乱数に
プロジェクトを成功させるために最初におこなっていること - $shibayu36->blog;
ディレクター時代に仕事でプロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。 ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。 プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。 5W1Hを決める すごい基本的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。
符号化文字集合と文字符号化方式 - 「プログラマのための文字コード技術入門」を読んだ - $shibayu36->blog;
最近文字コード周りでハマった時に、文字コードというものをそもそもちゃんと分かってないと気づいた。そこで「プログラマのための文字コード技術入門」を読んで勉強してみた。 プログラマのための文字コード技術入門 (WEB+DB PRESS plus) (WEB+DB PRESS plusシリーズ) 作者:矢野 啓介技術評論社Amazon この本はコンピュータにおける文字について体系的にまとめてくれている。ASCIIやLatin1、UTF-8やUnicodeについて、どういう分類で何のために使われているかを知ることができる。また、歴史も合わせて教えてくれるので、今現状起こっている問題(円マークとバックスラッシュ問題とか)がどういう経緯で起こってしまったのかなどを理解できる。 簡単な文章で書かれているので、一度でも文字コードに関係することでハマったことのある人なら、どんどん読めると思う。ただ、符号化文
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
