子供の熱性けいれんを初体験した - $shibayu36->blog;
すごく焦ったけど良い形で対応できたので書いておく。 状況 子供が40度近い熱が出たので小児科へ。インフルエンザA型の診断を受けて薬をもらう。自転車での帰り道に違和感を感じたので後ろを振り向いたら、子供がけいれんを起こしていて泡も吹いていた。 熱性けいれんのことも頭によぎりつつ、今まで体験したことなかったので自転車を停めてすぐに119連絡。呼吸を確認してくださいと言われたので確認すると大丈夫だった。けいれんが治っても意識は戻らなかったので救急車の到着を待つ。救急車の中でけいれんの様子を救急隊員に報告する。この時熱は40.6度まで上がっていた。受け入れ病院の電話を聞きながら1~2個から断られているのを聞いて、医療崩壊怖いと感じる。 病院に着いた時、反応は薄いが多少子供の意識が回復していた。けいれんの様子や意識の回復の様子から考えて、単純性の熱性けいれんだろうと病院が判断。けいれんを防ぐ坐薬を入
Apollo platformのチュートリアルをやった - $shibayu36->blog;
Hatena-Textbook 2018学習日記(5) - GraphQL編 - $shibayu36->blog;のようにHatena-Textbookを用いて最近のモダンなWebアプリケーション開発の学習をしているのだけど、TypeScript + GraphQL + Apollo Client + Reactの部分でそれぞれの技術の基本知識を理解できていなかったので、エラーが起きたときに何から直したらよいかわからない状態になってしまっていた。 前回はGraphQLのクエリについて学んだ - $shibayu36->blog;でGraphQLを少し掘り下げたので、今回はApollo platformについてチュートリアル( https://www.apollographql.com/docs/tutorial/introduction/ )を行いながら学習を進めていった。 Apollo
TypeScript + Apollo ClientでGraphQLのデータに型を付ける - $shibayu36->blog;
TypeScript + Apollo Clientで、useQueryなどを用いてGraphQLのクエリを発行する際に、クエリのvariablesやレスポンスのデータに型を付けたい。やり方が少々分かりづらかったのでメモを残す。 型をつけるためにやることは以下の通り。 apollo.config.jsを定義する graphql-tagでGraphQLのクエリを書く apollo client:codegenで型情報を生成する クエリを書いた場所で型をimportし、useQueryの型パラメータに指定する shibayu36/go-Intern-Diaryのレポジトリで試している。 apollo.config.jsを定義する まずApolloのコードジェネレータが適切に動作するために、apollo.config.jsを作る。Configuring Apollo projects - Apo
エンジニアと1on1をするときの事前面談シートテンプレート - $shibayu36->blog;
はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs
PostgreSQLでSQLチューニングや障害状況調査に使ったクエリ達まとめ - $shibayu36->blog;
最近PostgreSQLでSQLチューニングや、DBが詰まった時の状況調査をいろいろやった。その時に便利だったクエリ達をまとめていく。PostgreSQLのバージョンは9.6系です。 SQLチューニングなどに便利だったクエリ達 それ以降に実行するSQLの実行時間を表示する。参考 https://morumoru00.wordpress.com/2011/05/08/postgresql-sql%E5%87%A6%E7%90%86%E6%99%82%E9%96%93%E3%82%92%E8%AA%BF%E3%81%B9%E3%82%8B%EF%BC%88timing/ \timing 実際にクエリを実行して実行計画や実行時間を表示する。クエリが実行されるので破壊的な操作も実行されてしまうことに注意。トランザクション張って最後にROLLBACKしましょう。参考 https://www.post
良かったことは良かったとはっきりフィードバックする - $shibayu36->blog;
最近心がけていることとして、「良かったことは良かったとはっきりフィードバックする」ということがある。 自分がリーダーやマネージャのポジションになった時に、方針やメッセージを打ち出す、チームの開発フローを改善するなどを行うことがあった。この時、何もフィードバックが返ってこなくて、結局良かったのか、それともあまり興味がないのか、実は不満に思っているのか、どれなのかわからず、非常に不安に思ったという経験がある。 逆に自分が伝えられる立場になった時を考えてみると、何かが行われた時、気になることはよくフィードバックするけど、良かったなと思うことは心の中で思うだけでフィードバックしないことが多いと感じた。 そこで最近は、「良かったことは良かったとはっきりフィードバックする」ように心がけている。はっきりフィードバックするというのは、どこが良かったかを出来る限り具体的に相手に伝えるということである。伝える
雑に書いたブログ記事が問題を起こさないようにする工夫 - $shibayu36->blog;
ちょっとしたことでも雑にブログに書いておくと良いことが起こる - $shibayu36->blog; で、ちょっとしたことでも雑にブログに書いておくと良いことが起こるよということを書いた。さらに余談として最低限の雑さについても書いた。 これをきっかけに、公開の場でアウトプットする時の最低限の雑さとはなんだろうという疑問が自分に生まれ、雑さによる問題や、それを引き起こさないようにするための自分の工夫について少し頭がまとまってきたので、自分の考えを書いておく。 過度な雑さから生じる最大の問題 まずあまりにも雑に公開の場に書いてしまった場合の最大の問題について考える。この時、一番起こってほしくない問題は、「読み手が誤った情報を正しい情報と信じてしまう」ことだと考えた。 あまりにも雑な文章は読み手の誤認を引き起こし、正しい情報ではないのに正しいと読み手が解釈してしまう問題がある。正しいと解釈してシ
ちょっとしたことでも雑にブログに書いておくと良いことが起こる - $shibayu36->blog;
僕は自分がやったこと・勉強したこと・気づいたことなどはどんなにちょっとしたことでも、公開の場のブログに書くようにしている。その内容はある程度雑でも良いので、とにかく公開の場に書くようにしている。それによって、結構良いことが起こっているというのを社内の日記に書いていたのだけど、これも公開の場に書いておいても良いかと思ったので書く。 これまでの経験だと、次のような良いことが起こっている。 最低限未来の自分に理解できる程度まで記事にまとめることで、知識が頭の中で言語化され、定着する 時々他の人からフィードバックを受けて、さらに学習が進むことがある 「あれ昔なんか勉強したけど覚えてないな」という時に自分のブログ見たらすぐ思い出す 分からないことを調べようとググったら自分のブログが出てきてすぐ思い出す 初めからブログに書くつもりでインプットすると、自然と体系化・汎化しながらインプットできるようになる
高速なRandomized Queueのアルゴリズムを実装する - $shibayu36->blog;
CourseraのAlgorithms, Part Iというコースで、高速なRandomized Queueを実装するという話題があったので、試しに作ってみた。 高速なRandomized Queueとは Randomized Queueとは、Queueからdequeueするときに、中に入っている要素の中からランダムに一要素取り出すようなQueueである。 また「高速な」とは、enqueue、dequeue、isEmpty、sizeなどの操作の実行時間が、"constant amortized time"であること、つまり何回も操作を繰り返していくと、平均的には定数時間でそれぞれの操作が終わるということである。 この二つを満たすものを高速なRandomized Queueと呼ぶ。 実装 高速なRandomized Queueを実装すると次のようになった。 import java.util.
基礎技術の学習のモチベーションをどう保つか - $shibayu36->blog;
最近、コンピュータサイエンスなどの基礎的な知識を学習するように心がけている。できる限り今後も長い期間役に立つ、寿命の長い技術や知識を付けておきたいためである。その一貫で アルゴリズムを学習 してみている。 学習をはじめて感じた課題 しかし、とりあえずアルゴリズムを学習してみると、学習を続けられるか分からないという課題も感じた。 寿命の長い技術であるほど、日々の開発にすぐに利用できないことが多い 例えばアルゴリズムを学んだとしても、それが役立つまでいくにはある程度長い時間が必要 日々の開発に利用できていないと、モチベーションをずっと保ち続けるのが難しい モチベーションが保てないと、結局途中で勉強をやめてしまい、日々の開発に利用できるレベルまでたどり着けない 流行りの技術とかは、すぐに開発に導入してみるとかができるので、とりあえずモチベーションは保ちやすい。しかし、数学とかアルゴリズムとかLi
いつ突然会社をやめても問題ないという基準でコードやドキュメントを書く - $shibayu36->blog;
先に前提を話しておくと、会社は全く辞めるつもりはないし、むしろどんどん会社を良くしていこうと思っている。今回はそういう基準で自分がコードやドキュメントを書いていますよという話。 コードやドキュメントを書く時に、どのくらいきれいにしておくかとか、どのくらいわかりやすくしておくかとかを考えることがある。こんなとき僕は、いつ突然自分が会社をやめて連絡がつかなくなったとしても他の人がある程度理解できるか、を基準にしている。そのためにはあまりいい方法が思いつかなくて仕方なく書いている部分にはちゃんと経緯のコメントを書く。他にも例えば作ったサービスであるイベントを開催する方法のドキュメントを書くなら、全く何もやったことがない人がそのドキュメントを読んだらとりあえず開催できるよう、ドキュメントを書く。当然コードもかっこよさよりも、説明しなくても分かりやすくなるようなシンプルさを追求する。 また、このよう
最近コード中のTODOコメントの書き方を工夫している - $shibayu36->blog;
コード中に後でやろうと思って以下の様なTODOコメントを書くことがあります。TODOコメントというのは # TODO: 後でリファクタリングしたい ... # TODO: 投稿機能ができたら置き換えること ... みたいなやつです。 コード中にTODOコメントを気軽に書いてしまいがちですが、よくTODOコメントが放置されて気づいたらプロジェクト中に大量のTODOコメントが書かれたりすることがあります。直せる量を超えてくると、直すモチベーションも下がってきて、結局ただのコメントと同じ状態になります。 最近いろいろ工夫して、TODOコメントの書き方を変えたところ、そこそこうまく回ったのでメモしておきます。 TODOコメントの問題点 問題点として次のものがあると考えました。 (1) 書く人によって形式がバラバラ TODO, XXX, FIXMEなどバラバラだったりする (2) TODOコメントの
学習のため書籍を読むときは明確に目的を決める - $shibayu36->blog;
僕は学習をする際には書籍を参考にするのが好きだ。なぜネットとかではなくて書籍を参考にするかというと、書籍のほうが学びたい事柄についてネット情報や人から教わるのと比べて、どちらかというと体系的にまとめられていると思っているためだ。 ただし書籍を参考にしている時によく陥りがちなのが、「学習する」という目的を忘れて、「本を読み切る」という事自体が目的化してしまうことだ。こうならないため、僕はこの書籍を読む目的をはっきり決めるようにしている。その目的が大体3つくらいの種類に分類されてきたので、今回はそれについてまとめてみようと思う。 三つの目的のどれかを選ぶ 僕の中で学習目的で書籍を読むときは以下の三つの目的のどれかに絞っている。 これからの課題を解決する方法を見つけるための読書 これまでうまくいったことの言語化を行うための読書 視野を広げるための読書 この三つのどの目的で本を読むか、自分の中で明
「強いチームはオフィスを捨てる」を読んだ - $shibayu36->blog;
強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」 作者:ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン早川書房Amazon 最近リモートワークへの知識に興味が湧いてきたので、ひとまず強いチームはオフィスを捨てるを読んだ。元々はリモートワークについての思い込みがあり、そのためリモートワークの難しさのほうに目が行き過ぎていたのだけれど、この本を読んでみて少し中立よりになれたように思う。そういう面で今の時期に読むには非常に良かった。リモートワークの知識だけというより、普通に働いていても参考になる知識も得られた。 リモートワークを始めたいけど何から始めたらいいかについて分からない人には最適な本。ただし良い本であるという一方で、少しリモートワーク礼賛の傾向があるので、そこは一歩引いて読むと良いのかなと思う。とはいえ、ただ褒めているというだけでなくて、きちんとメリット
良い物件ではなく良い不動産屋を探した - $shibayu36->blog;
いろいろあって今の家から引っ越すことになった。 良い物件どうやって探したらいいか分からなかったので、適当にググって http://nanapi.jp/286/ を実践してみたら、結果的にうまく行ったので経験をメモ。 結論 良い物件を探すのではなく、良い不動産屋を探すという方法にしたところ、僕の性格としては上手く行った 今回の流れ suumoやhomesで住みたい場所の物件を眺める 希望条件をまとめる 不動産屋を選んでメールしまくる 良さげなところを数社に絞って、さらに送られた物件見ながら返信してみる 一番いい感じに返答してくれた雰囲気の店に行って相談 suumoやhomesで住みたい場所の物件を眺める http://nanapi.jp/286/ とやってることは一緒なので割愛 希望条件をまとめる http://nanapi.jp/286/ とやってることは一緒なので割愛 不動産屋を選んでメ
開発フローに新しい仕組みを導入するとき気をつけていること - $shibayu36->blog;
最近開発フローに新しい仕組みを導入したりすることも多いのだけど、気をつけていることがいくつかある。 小さく導入する 短く導入する 振り返る 小さく導入する なんか導入する時は出来るだけ小さく導入してる。 理由は いきなりスクラムだとか言い始めてチーム全体のワークフローを変えようとした結果、チームの文化が崩壊する いきなりこれからはこのツールだとか言い始めてツールを導入した結果、誰も得してないのにツールだけ使われ続ける みたいなことがよく起こると思ってるため。既存の文化を壊したら元も子もないので結構気をつけてる。 小さく導入すれば、影響範囲を最小限に留めることができるし、あとから簡単にやめることが出来る。 小さく導入する方法はいくつかあって スクラムの中の一部だけ、チーム全体に適応する -> 導入するものを小さくする チーム内タスクの一部分だけに、仕組みを導入する -> 導入する範囲を小さく
Dockerが利用しているAUFSとLXC - $shibayu36->blog;
最近Dockerをいろいろ触ってみていて以下の様な記事を書いたりしました。 Dockerで立てたコンテナにsshで接続する - $shibayu36->blog; serfとDockerでクラスタを組んでみる - $shibayu36->blog; 本番環境のBlue-Green Deploymentの仕組みのプロトタイプを作っていた - $shibayu36->blog; Docker, Mesos, Sensu等を利用したBlue-Green Deploymentの仕組み - $shibayu36->blog; 社内用Docker Registryを立てる - $shibayu36->blog; docker commitでCMDやENVなどを指定する - $shibayu36->blog; docker inspectでDockerコンテナの情報を取得する - $shibayu36-
Web Applicationを綺麗に設計するためのMVACという考え方 - $shibayu36->blog;
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって？ データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
