GTD 駆け込み寺 (1) 多すぎるプロジェクトの処理方法
あらかじめ太字で大書しておきますが、私は GTD のエキスパートではありません。自分ほど GTD を失敗している人もいないだろうと思うくらい、日常的に GTD の鞍から滑り落ちてはまたよじ上ってを繰り返しています。 しかしこの３年で失敗も数多く経験してきましたので、「多分、理想的にはこうすればいいのかな？」とか「きっと、ここがヒントになりそうだ」というツボはやっと分かってきた気がします。そんなわけでいつか「GTD 駆け込み寺」という不定期連載を作ろうと思って実例を集めていました。 そんな折に、先日の記事のコメント欄にこんな質問がやってきました。すばらしい質問だと思いましたので、まずはここから、この不定期連載をはじめて見ようかと思います。 質問：プロジェクトが多すぎる 昨日の記事のコメント欄に質問がありましたが、ここにコピーしておきたいと思います。 就活中の焦りを何とかしようと思い、学生なが
GraphQLを使ったAPI仕様中心開発の導入とその効果の紹介 - Kaizen Platform 開発者ブログ
Kaizen Platformでフロントエンド開発をやっているlacoです。 新規アプリケーション開発において、API仕様中心の開発スタイルを検討し、実験的に取り入れました。 本記事ではその概要と効果を紹介します。 API仕様中心開発 API仕様中心開発を取り入れようと思ったきっかけは、2017年のNode学園祭でpika_shiさんが発表した「JSON Schema Centralized Design」です。 JSON Schema Centralized Design - Speaker Deck Kaizen Platformではリモートワークで開発しているメンバーが多く、非同期にコミュニケーションをすることが多いので、生産性を高めるためには互いの作業を待たずに独立して分業できるワークフローが必要でした。 バックエンドAPIの実装を待たないとフロントエンドが実装できないような依存関
Let's encryptとSSL/TLSに関する誤謬 - Chienomi
全く以て意味不明な誤謬がはびこっていた上に、やたら上から目線だったので、消火しておこうと思う。 そもそもSSL, TLSとは何か SSL/TLSは暗号化技術である。 SSL/TLSのデータ通信自体は対称暗号である。ただし、暗号化に利用する暗号鍵は使い捨てる。 Cipherはかなり色々使えるのだけど、だいたいはTriple DES (3DES)かAESが使われる。 その手順は <- HelloRequest -> ClientHello <- ServerHello <- ServerCertificate <- ServerKeyExchange <- ServerHelloDone -> ClientKeyExchange -> Finished -> ChangeCipherSpec <- Finished <- ChangeChiperSpec <-> Application Dat
GitHubの買収とオープンソースコミュニティについて - ものがたり
6月2日にmicrosoftがgithubを買収する噂が流れて、3日には確定情報として流れて、4日には正式発表があった。これに対しては歓迎する声から悲しむ声、非難する声などさまざまな反応があった。この反応の一部が、どちらの方向についてもあまり良くないと思っているので、可能な限り問題のある反応を潰しておこうという意図でこれを書くことにした。 ちなみに、笑える反応としては、githubにアクセスするとClipperやカイル君が出てくるようになるみたいなジョーク画像の類があるけど、これを集めているとキリがないし今回はきちんと論じたいことがあるので、その辺は他所に任せたい。 それはさておき、これは長い文章（になる予定）なので、最初にふたことで要約しておきたい: 新CEOのNatは割と信用できるやつで、きっとGitHubを上手くやっていってくれるので、もしMSというだけで疑っているだけならちょっと人
「残された時間は半分だ」という現実を認識する！
学生時代、夏休みや冬休みに「計画倒れに終わった」を経験した人は少なくないと思います。 かくいう私も学生時代は「計画倒れに終わった」経験ばかりです。これは処理能力の問題ではなく、人間の認知の歪みが原因なのです。 1979年に、行動経済学者であるダニエル・カーネルマンとエイモス・トベルスキーが「プランニングの誤謬」として発表しました。 学位論文を書くのにどれだけの時間が必要かと問われた学生たちは平均して33.9日、最悪の事態を想定しても平均48.6日で完成すると回答しました。 ところが、実際にかかった時間を後刻平均すると55.5日になったのです。 「プランニングの誤謬」は、人間は未来にかかる時間の想定を一貫して楽観的に間違う傾向を持つことを解明しました。 いくら現実的に見積もったつもりでも、その見積もりは認知のレンズで歪んでしまうのです。 拙著「最強の勉強法」でご紹介した方法論の一つは、試験ま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
