「終わりの時間」を自分で決めると、そこでちゃんと終えられる | シゴタノ！
「24 TWENTY FOUR」という米国の人気ドラマがあります。 その名のとおり、24時間をリアルタイムに追っていくドラマで、出来事はすべて時間順に進行していきます。 通常のドラマや映画にありがちな、過去へのフラッシュバックや「それから半年後」のようなスキップがありません（唯一の例外として、現時点での最新シーズンであるシーズン9では「それから12時間後」というスキップがあります）。 テーマはテロリストとこれに対抗する政府機関との闘いなので、24時間きっかりでテロ事件を解決することになります。 24時間もあったら間延びしてしまうのではないか、と思いきや、次々と事件やトラブルが起こり、展開は非常にスピーディー。 1話あたり1時間分（放映時間としては45分）で、全24話から成るのですが、1話だけのつもりが、続きが気になるために、次々と観てしまいます。 タスク管理的にはとても悩ましいドラマです。
うまく使えばやる気は十分にある | シゴタノ！
やる気をうまく使う。 そもそも、こういう言葉を聞くこと自体、私自身ほとんどありませんでした。 やる気というのは「あればいい」ものでした。 それどころかやる気とは「いつでもあって当然」のものでした。 教師、監督、コーチ、上司、先輩という人たちはみな、次のように言う当然の権利を有しているようでした。 「おまえには、やる気が感じられねえんだ！」 問題はある・なしではなく「みなぎっているやる気を、他人に示すことが出来るかどうか」というレベルだったのです。 「やる気が出せない」などというのは、まるで犯罪者予備軍のようなものでした。私が高校になる前くらいまでは。 気力という貴重なリソースをどう配分するか 時代は変わりました。 私が「やる気の出し方」をテーマにした本を書けば、少なくとも5000部は売れるような時代です。 こんな本を書いても 「やる気がない、だと？！！！！！」 などといった電話やメールや手
やるべきことをはっきりさせるだけで人をやる気にさせられる | シゴタノ！
「やることはいくらでもあるんだ！」 と、アルバイト時代に一回くらいはいわれたことがあるでしょう。私など、何度言われたか数え切れないくらいです（笑）。 このセリフは、ダメなものだと思います。真っ向から「クローズリスト」の趣旨に反しています（もっともバイトの先輩にそんなことを期待するのは過剰というものですが）。 仕事がいくらでもあるというのは、タスクリストにどんどんタスクを追加できるということであり、そのようなリストはまさに「オープンリスト」なのです。オープンリストは非常に破綻しやすいリストです。 なぜクローズリストがいいのか？ ロイ・バウマイスターの指摘の中でもおそらく最も重要なのは「意志力（自制心）」は「力である」という点です。人間は生き物なので「力」は使うとだんだん弱くなっていきます。何かをガマンした直後は、同じようにガマンする「力」は弱くなっています。
朝型人間になってからわかった早起きに必要な７つのこと | シゴタノ！
私はかなり長い間「昼前起き」型人間でした。しかも長眠派のため、けっこう早寝していたので、１日10時間くらい寝ていることもありました。 一説によるとアインシュタインは10時間近く寝ていたそうですので、長時間起きてれば生産的になれるなどというのはまったく当たらないと思いますが、諸事情から早起きして活動したい、いわゆる朝活せねばならないという人もあるでしょう。 » 長時間でたくさんの仕事をしてはいけない そういう方のためにも、早起きできるようになってから気づいた「早起きするために必要な７つのこと」をこちらにまとめておきます。 1．起床のタイミングは大事 2．起床時の気温はきわめて大事 3．起きてすぐに好きなことを少しはやること 4．コーヒー・紅茶の効果は人による 5．週に一度は疲れを取ること。ただし・・・ 6．起きられなくても罪悪感をもたない、寝不足のことをクヨクヨ悩まない 7．運動する 1．起
学ぶ時間をどうつくるか | タイム・コンサルタントの日誌から
前回は、中堅エンジニアがモチベーションを失わずに成長するためには、自分の専門分野以外にも学ぶべきことがある、と書いた。ところで、ここに重大な問題が立ちはだかっている。それは、企業人の学ぶ時間が、次第にうばわれているという事実だ。 普通の企業人は、年間どれくらいの時間を「学び」にあてているのか？ 平成23年度調査によると、正社員の延べ受講時間平均は39.5時間だ、という（「人事マネジメント」2012年11月号・門田政己氏の記事より）。 http://www.acroquest.co.jp/company/press/2012/img/20121206.pdf 年間に39.5時間ということは、月にわずか3.3時間だ。週に1時間もない。これでは「学び」どころか、技術やスキルの維持さえおぼつかないではないか。しかもこの数値には、新入社員の集合研修の時間なども含まれている。中堅層だけを抜き出したらも
頭のいい人たちの想像 - ForGetting Things Done
ある仕事を依頼されたとして、想像力に乏しい人は、想像力に富んだ人よりも、より高いパフォーマンスを発揮することがあります。 想像力に乏しい人は、特に何も考えることなく着手するからです。 着手すると、とにかく仕事は進みますよね。 その結果、障害が現れても、とにかく無心になってやるので、本人も訳がわからないうちに仕事を完了させたりします（笑） 対して、頭が良く想像力に富んだ人。 優秀であればあるほど、仕事に対して考え込んでしまい、自分で壁を作ります。 ブラックマヨネーズというコンビのお笑い芸人の漫才が、この自分の壁をデフォルメしたネタをよく披露しています。 例えば、 サッカーやりたい ボール買おう そうだね！……でもなぁ、、、 (この「でもなぁ、、、」が、ボケの始まる合図です) 買って持って帰る途中に落としちゃったらどうしよう 拾えばいいじゃないか 坂道でどんどん転がっていくかもしれないじゃない
Javaの謎のパフォーマンス劣化現象との戦い - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。アプリケーション基盤チームの横田です。 Javaの謎のパフォーマンス劣化にまつわる調査をしていたのですが、1ヶ月の苦労の末に原因がわかりましたので、報告させていただきます！ 公開後に頂いたはてなブックマークでのご指摘・社内でのタイポ・読みにくいなどの指摘を受けてたので、謹んで修正させいただきます。 修正した内容につきましては、記事の最後を参照してください。 忙しい人のためのまとめ jdk-7u4以降のjdk-7 *1 でJavaのパフォーマンスが劣化する謎の現象 CodeCacheの容量限界に近づくとJITコンパイラを停止してコンパイルしたコードを捨てる機能が原因だった 起動オプションで回避できるので、長期運用するときは -XX:-UseCodeCacheFlushing, -XX:ReservedCodeCacheSize=128m をつける 上のオプションを設定した時に、C
富士通に入社して10年が経った - blog
こんばんは tnaotoです。 富士通の退職エントリーが何かと話題ですが、いろんなことが混ざっているので一度整理してみようかなと思います 。 昔は、リクルータや採用イベントに出ていたこともあるので、そこらで話をしてたことを思い出しつつ。 突然、この記事が消えたら会社からの圧力があったか、話題になりすぎてビビったかのどちらかです。 anond.hatelabo.jp 自己紹介 僕は約１０年前に、新卒入社（情報系院卒）し、 ソフト開発職を５年くらいやった後に、社内公募で研究所に異動し、 以後、事業部と研究所を行ったり来たりしています。 最近では、publickeyあたりに僕のことが乗っていたりします。 www.publickey1.jp また、僕は研究所にはいますが、研究してない研究員という謎の立場です。 富士通の職種 よくSIerがーとか言われる業界ですが、富士通の職種はいろいろあります 。
SIは楽しいよ！（状況による） - ひしだまの変更履歴
ひしだまＨＰの更新履歴。 主にＴＲＰＧリプレイの元ネタ集、プログラミング技術メモと自作ソフト、好きなゲームや音楽です。 今週バズった話題：富士通を退職した話→「SIer が天職です」って人はどこにいるの？に関連してあるツイートを見かけたので、Asakusa Frameworkを使っている身としては反応せねばなるまいっ。 「AsakusaFWを使うSIは楽しいよ！」ｗ（ステマ） まぁ冗談は置くとして、自分が今勤めている会社はAsakusaFWを扱っている会社であってSIerではありませんが、自分がやっている仕事はお客さんのシステムのバッチをAsakusaFWで作ることなので、SIと言えると思います。 つい先日Asakusa on M3BPが出たので、今はその検証をやっています。バッチの種類によるけれども、実行時間がAsakusa on Sparkより2～10倍（平均3～4倍）くらい速くなった
デモやプレゼンをするときに使っているツール - ikeike443のブログ
僕はいまソリューションエンジニアというロールで、お客さん先で GitHub や DevOps(バズワード)的なツールのデモをやったり、セミナーやカンファレンスでトークすることが多いのですが、デモやプレゼンをするのに自分が使っているツールをまとめておくと誰かがもっといいものを教えてくれるかもしれないと思い、ここに書いておくことにしました。 別のアカウントを作る まず最初にやってるのがこれで、Mac上に、普段使いとは別のデモ用アカウントというのを作っています。デモやプレゼン中にFacebookのメッセージが飛んできたり、Slack上のふざけた投稿とかが出てきて場を凍らせないようにするためですw 共有したいファイル（VMのイメージとか、プレゼン資料とか）は /Users/Shared/ 以下に置いています。ものによっては Dropbox を使って共有しているものもあるけど。Dropbox を使う
マルチリソース、マルチテナントに対応したDBマイグレーションツール「solidbase」1.0.0をリリースしました - たけぞう瀕死ブログ
Javaベースのデータベースマイグレーションツールsolidbase 1.0.0をリリースしました。 github.com これは元々GitBucketで使用するために開発したものです。GitBucketではこれまで独自に実装した簡易的なマイグレーションシステムを使用していたのですが、外部データベースの対応やプラグインシステムの導入などに伴ってより汎用的なマイグレーションツールへの移行を検討していました。 Javaで利用可能なデータベースマイグレーションツールにはFlywayやLiquibaseなどがありますが、以下のような要件をすべて満たすものがありませんでした。 データベースだけでなく他のリソースも扱うことができる（任意のマイグレーション処理を実行したい） 1つの定義で異なるDBに対応する（デフォルトのH2だけでなくMySQLやPostgreSQLなどにも1つの定義で対応したい） マル
論理削除フラグという名の死亡フラグ - @ledsun blog
RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita 論理削除が云々について - mike-neckのブログ Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か 流行っているので乗っかります。 結論 「データ制約の強力さと集合としての表現力を捨てながら、Relational Databaseを使うのはなぜか？」 論理削除フラグのデメリット 大体三つあると考えています。 ユーザーの言葉でない データ制約の弱さ 集合として認識できない ユーザーの言葉でない 私の経験上は、ユーザーから「論理削除」という言葉を聞いたことがありません。 次のような要件は、聞いたことがあります 社員が退職（・転属）する （売掛金の回収を諦めて）売上を打ち消す 「お知らせメッセージ」を公開日がくるまで非表示にする 既読メッセージを表示しない 保存期間が過ぎたアンケート結果をオペレ
仕事は取りかからないと終わらないが、終わらせようとすると取りかかれない
結論からいうと、取りかかるときに「終わらせなくてもいい」と自分に言い聞かせることです。 「終わらせなければならない」と思うと、緊張感が高まり「コンディションが整うまで待とう」「もっと時間があるときにしよう」という理由で先送りされやすくなります。 その結果、別の仕事の締め切りが迫ってきて、ますます時間がなくなり、取りかかるハードルは上がるいっぽうです。 これは、借金をしている人が「全額返済できるようになるまで返済は一切おこなわない」と決め込むようなものです。 借金は増える一方なので、必ずどこかで破たんします。 つまり、締め切りを延ばしてもらうか、ほかの仕事を犠牲にするか、徹夜をするかのいずれかを余儀なくされます。 “少額”でもいいので、とにかく毎日“返済”する 無理なく続けられる分量を見極め、毎日欠かさず続ければ、日数はかかりますが必ず終わります。 ただし、借金には利子がつくため、返済額が利
分散プログラミングモデルおよびデザインパターンの考察 その4 - Software Transactional Memo
引き続き分散システムのデザインパターンの話をしていく。例によって適切な名前を見つけられなかった場合にはその場で適当に名づけているので、ここに書いてある名称が技術レベルでの正式名称だとは思わず、正式名称を見つけたらそっとコメント欄で教えてください。 Application Level Ack リクエストを受け取った際にAcknowledgment(Ack) を返却するのは重要であるというのは異論の余地はない。だが、どのレベルで返却すべきかというのはデザインスペースの一部である。 ご存知の通り、TCPはそもそもSYN → SYN-ACK →ACKの3方向ハンドシェイクを行い、それぞれの通信ペイロードにシーケンス番号を付けて送達を確認している。SO_LINGERを使えばclose時に未送信パケットが残っていればそれを送り終わるまでclose()をブロッキングする事もできる。TCPのトランスポート
フロントエンドへの複雑化について、一つの視点 - mizchi's blog
これらの件 最近のフロントエンドへの違和感 - nobkzのブログ 日本のWebエンジニアの大半が、変化に対応しきれなくなっている件について。 - 日々、とんは語る。 前提 去年は勝手Reactエヴェンジェリスト(自称)として、日本に複雑化するフロントエンド技術の海外の動静を紹介をし続けていた。 僕としても、フロントエンドは複雑化してると思ってるし、それは「目的の複雑化に対して必要なもの」だったと思っている。ここでいう目的とはSPAの構築であって、普通のウェブサイトは含んでいなかったが、普通のウェブサイトも当たり前のようにリッチ化目指しているのが現在なので、境目は曖昧ではある。 僕もフロントエンドの複雑化がだれにでも必要なものだとは思っていない。が、定期的に情勢を整理して、交通整理するのを心がけてきたし、春からはじめるモダンJavaScript / ES2015 - Qiita みたいな記
日本のWebエンジニアの大半が、変化に対応しきれなくなっている件について。 - 日々、とんは語る。
先週書いた10年のツケを支払ったフロント界隈におけるJavaScript開発環境（2016年4月現在）。という記事がまずまずの反響を得たのですが、僕の予想とは異なり、「こんなに多くのツールやフレームワークを必要とする現状はおかしい」といった、状況批判の意見が多く集まりました。 Mediumなど海外メディアでは、もはやこの種のツールを組み合わせたフロントエンド開発が当たり前として受け入れらており、この半年間ほどは「実際にどの組み合わせがベストか」という議論が行われていました。そして、そういった議論もようやく落ち着きを見せ、おおよそ僕が書いたような組み合わせに帰結しつつあります。 そのため、まさか「フロントは変化が激し過ぎる」とか「保守が大変そう」などといったような、1年くらい前に言われていた意見が、いまだに多くを占めるとは、まったく予想していなかったというのが正直な意見です。ひと昔まえであれ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.outward-matrix.com/entry/20160409093000