タグ

2017年1月14日のブックマーク (15件)

  • ふりかけの「ゆかり」が最高の調味料だと教えたい

    「ゆかり」というふりかけが僕は大好きだ。ひとり暮らしを始めてから好きになり、何にでも使える万能さのとりこになった。「ゆかり」がある生活が2年ほど当たり前だったので、特に誰にも言わなかった。 今日は、その僕にとって当たり前である「ゆかり」の良さについて存分に語りたい。 大学中退→ニート→ママチャリ日一周→webプログラマという経歴で、趣味でブログをやっていたら「おもしろ記事大賞」で賞をいただき、デイリーポータルZで記事を書かせてもらえるようになりました。嫌いなべ物はプラスチック。(動画インタビュー) 前の記事:【検証】ボードゲームは初対面の人で仲良くなれるの? > 個人サイト ジャーニーとモアイとめがね

    ふりかけの「ゆかり」が最高の調味料だと教えたい
    Watson
    Watson 2017/01/14
    ゆかりは美味いよね( ˘ω˘)
  • Re:golang の http.Client を速くする

    先日mattnさんの記事を読みました。 golang の http.Client を速くする nettというパッケージを使って 名前解決の結果をキャッシュすることで、http.Clientを早くするというものです。 この記事に関して、ちょっと疑問に思ったことがあったので、検証してみました。 疑問 疑問に思ったのは以下の点です。 名前解決遅すぎでは? ベンチマークの結果を見ると5億ns(=500ms)ほど速度が改善しています。 3つのURLに対してリクエストを投げているので、初回を除く2回DNSのキャッシュがヒットし、 名前解決2回分の速度改善になるはずです。 と、いうことは、名前解決1回あたり250msかかっている計算になります。 googleのsearchは302でリダイレクトがかかるので、Client.Getの呼び出し1回あたり2回リクエストが飛ぶ、 ということを計算に入れても100m

  • Grumpy(Go running Python)を試してみた。 - Qiita

    序 「すごくスケールする」、とかうまく書くものだなぁ、と 以下のニュースにある意味感心したので、Grumpy(Go running Python)を試してみることに。 マイナビニュース : Google、すごくスケールするPython実行環境をGoで開発 ネタ元のブログを読む。 上記事の中身、《すごくスケール》という見出しを作るために元ブログを抜き書きした気がしたりするので、ネタ元のブログ(元ブログ)の方も斜め読みしておこう。。 Fibベンチマークにおける高スケーラビリティについて 《すごくスケール》での記述 : 「Grumpy」はまだ実験段階とされているものの、CPythonと比較してFibベンチマークで高いスケーラビリティを発揮している。 => 元ブログでの記述。 In particular, Grumpy has no global interpreter lock, and it

    Grumpy(Go running Python)を試してみた。 - Qiita
  • Compiling a Mac OS 8 application on macOS Sierra

    In 1999, armed with a brand new copy of Metrowerks Codewarrior and a PowerMac running Mac OS 8.5.1, I wrote a basic implementation of Minesweeper to test out the Powerplant application development environment. It’s the oldest project of mine that I’ve kept, so I wanted to see if I could get it running again for the first time in 17 years. There’s no Swift or Objective-C code in this article but th

    Compiling a Mac OS 8 application on macOS Sierra
    Watson
    Watson 2017/01/14
  • オープンソースプロジェクトとの距離のとりかた

    オープンソースプロジェクトに参加したいな、と思った時、まず最初に問題だと感じるのは英語だと思う。構成員が日人だけで、日人に向けてのみ出しているそソフトウェアでない限り、プロジェクトの共通語はふつう英語だ。植山さんの記事には英語で物事を進めることの利点が体験談とともに書かれている。他の記事にも、オープンソースプロジェクトで上手いことやっていくためのひとつとして英語の話が出てくる。一方、英語のせいで参加したくても二の足を踏んでしまう、というのもよく聞く話だ。結論から言ってしまうと、やっぱり読み書きだけでも習得しないと話に入っていくのは難しい。ソフトウェア開発者の多くは多様性に対して寛容なので、英語が不得意という理由で拒絶されることはないだろう。ただ、特別な配慮もしてくれない。 しかし英語の前に、プロジェクトとの距離のとりかたを学ぶべきだと思う。いままでわたしが見てきたり、自分自身がやって良

    Watson
    Watson 2017/01/14
  • エンジニアの技術力評価は難しい? - 5年間運用してきた技術力評価制度の改善の歴史 ‒ / Regional SCRUM GATHERING Tokyo 2017

    Jan 12, 2017 @ Regional SCRUM GATHERING Tokyo 2017

    エンジニアの技術力評価は難しい? - 5年間運用してきた技術力評価制度の改善の歴史 ‒ / Regional SCRUM GATHERING Tokyo 2017
  • 旦那が〇年間作り続けたゲームをプレイした同人嫁の雑記

    01/13 17/01/13 追記 SNS等にて当ブログをご紹介下さり、まことにありがとうございます。 勘違いされている方が居らっしゃるようなので明言させて頂きますが、 私の夫は当該ゲーム開発チームの一スタッフにすぎません。 また、当記事は文中にネタバレを含みますのでご留意下さい。 01/12 序) 「自殺するならこういう時なのかもしれない」 「自殺するならこういう時なのかもしれない」 長年とあるゲームの開発に従事した旦那が、晴れてタイトルリリースを迎えたその日、突然そう言った。 ひとつの仕事を成し遂げ、尊敬できる仲間や愛すべき家族がおり、今の自分には何の不安も恐れもない。 燃え尽き症候群じゃないけれど、心が小気味よく凪いでいて、自殺するとしたら、こんな時なのかもしれない。 自分にはこれしかないと身一つで業界に飛び込んだ、単なるゲームバカ。 「俺は死ぬまでエンタテイナーでありたい」と、空

    旦那が〇年間作り続けたゲームをプレイした同人嫁の雑記
    Watson
    Watson 2017/01/14
  • bashの初見殺しっぷりがハンパない件 - Qiita

    「これ知らなきゃ分からないだろ!」 「エラーの原因はわかったけど、なんか腑に落ちない」 いま悩んだ2時間返せ! bashというか、UNIXのコマンドに慣れてない 僕みたいな新人エンジニアが 気をつけた方がいいポイントまとめました。 あいことばをわすれない 微妙にエラーが出ないため、気づかないまま進んでしまい、 のちのち絶妙に致命的なことになってしまうので注意。 一行目忘れて2時間悩みました 二行目のオプションつけなかったため2時間悩みました setのオプションはお好みで あいことばの解説: http://qiita.com/magicant/items/f3554274ee500bddaca8 半角スペースをつけるな!半角スペースをつけろ! shellさんはスペースに非常に神経質です。 よくある変数代入では=の前後にスペースいれてはダメです。

    bashの初見殺しっぷりがハンパない件 - Qiita
    Watson
    Watson 2017/01/14
  • 3月発表の次期iPad Pro、画面サイズが10.5インチになる理由 - iPhone Mania

    次期iPad Proは画面サイズが10.5インチになる、と噂されています。一見、中途半端にも思える10.5インチというサイズですが、実は理にかなっている、との説が発表されました。 鍵は2015年の12.9インチiPad Pro発表プレゼン 今年3月に発表される次期iPad Proは、画面の縁のベゼルを薄くすることで、体の外形サイズが現行の9.7インチのまま、10.5インチ程度に大画面化する、と有力アナリストらが予測しています。 その理由は、2015年9月、Appleのフィリップ・シラー上級副社長が12.9インチのiPad Proを発表した時のプレゼンテーションに隠されている、とデザインスタジオStudio Neatの共同創業者でデザイナーのダン・プロボスト氏がブログに記しています。 12.9インチのiPad Proの画面の横幅は、9.7インチのiPadの画面の高さと同じになるようにデザイ

    3月発表の次期iPad Pro、画面サイズが10.5インチになる理由 - iPhone Mania
  • takahi-iがIncrementsにJoinしました++ - Qiita Blog

    Increments に takahi-i がエンジニアとして JOIN しました++ takahi-i はデータマイニングの分野で博士後期課程を修了後、株式会社ファストサーチ & トランスファなどの企業で検索エンジンの開発や導入に携わってきました。また自動文書チェックツールである RedPen の開発者でもあります。 今後 takahi-i によって、Qiita や Qiita:Team の検索が改善されていくことでしょう!今後の Increments の進化をお楽しみに++ Increments では引き続きメンバーを募集しています。 Qiita:Teamや新規事業のグロースを担うWebマーケター募集!法人向けサービスQiita:Teamや新規事業に携わるセールス職を募集!「広告」を通じて価値ある情報をユーザーに届けるアカウントプランナーを募集500チーム以上が利用中「Qiita:Te

    takahi-iがIncrementsにJoinしました++ - Qiita Blog
    Watson
    Watson 2017/01/14
  • 2022年、白鳥座で連星が衝突合体か - 夜空に赤く輝く星が出現すると予測

    いまから5年後の2022年頃、白鳥座の方向にある連星系で恒星同士が衝突合体し、爆発的に輝く可能性がある。予想が正しければ、夜空に赤く輝く明るい星が出現し、肉眼でも見ることができるようになるという。米カルヴァン・カレッジのLarry Molnar教授らの研究チームが予測を報告した。 天体の輝度が急激に増大し、新しい星が生まれたように見える現象として「新星」「超新星」などがある。このうち「新星」は、近接連星系(距離の近い2つの恒星が組になってお互いの周りを公転している天体)の片方の星(白色わい星)が相手の星の表面のガスを引き込むことで核融合反応が一時的に加速され、爆発的に輝く現象であると考えられている。また、「超新星」は恒星が一生を終えるときの爆発現象であり、連星系の白色わい星が相手の星の表面を引き込んで爆発するI型、巨大な大質量星が重力崩壊を起こすII型の2つのタイプに大きく分類されている。

    2022年、白鳥座で連星が衝突合体か - 夜空に赤く輝く星が出現すると予測
  • 量産型プログラマを撲滅したい

    プログラマの生産性の差は、出来る人と出来ない人で10倍とも100倍とも言われる。そんな馬鹿な、と思われるかもしれないが、事実だ。 むしろ、一緒に働かせると、出来るプログラマが、下手に作られたプログラムの修正をしなければいけなくて、全体の生産性を落とすことになる。 つまり、出来ないプログラマはチームで働くと、生産性をマイナスにするのだ。厳しいことを言えば、いない方がマシなのである。 ソフトウェア開発にの手はいらないのだ。 では、出来ないプログラマとはどんな人たちか。 コピペで書くプログラマだ。他で動いているプログラムをコピペして、なんとなく直して書いているプログラマだ。 なぜプログラムが動くのか、どう書けば動くのか、わかっていない。 ただ沢山のプログラムを書くだけの量産型プログラマだ。こういう人のプログラミングは、デバッグさせてみて、横で見てるとすぐにわかる。 まず、エラーメッセージを見な

  • fabFORCE.net

    Keep your databases in control with the fabFORCE DBDesigner4. Whether you have to design an new database or manage your data and models. DBDesigner4 Online Forum fabFORCE provides OpenSource utilities, components and infos for Kylix and Delphi programmers. All released under the GPL. Utilities Components Kylix Infos Film, video and music production, editing and post production. 3D animation and im

    fabFORCE.net
  • 壁やドアを取り払って仕切りのない「オープンオフィス」が実は効率を下げているという事実

    By 泰德 オフィスの空間を壁などで区切ってしまわず、全てが見渡せるほどの開放的な空間として使用する「オープンオフィス」のスタイルは、近代的なオフィスの姿として注目を集めました。他人との区切りがなく、文字どおり横方向に広がった環境により仕事のアイデアが生まれやすくなったり、仕事の効率が上がったりというメリットが語られていたオープンオフィスですが、実際にはまったく逆の影響が現れていることが知られるようになってきています。 BBC - Capital - Why open offices are bad for us http://www.bbc.com/capital/story/20170105-open-offices-are-damaging-our-memories 会社を経営するクリス・ナーゲレ氏は4年前、テクノロジー系企業の多くに倣って会社のオフィスを仕切りのないオープンオフィス

    壁やドアを取り払って仕切りのない「オープンオフィス」が実は効率を下げているという事実
  • 優秀なエンジニアになる方法: 電子情報通信学会誌 Vol.84 No.10 pp.741-749 2001年10月