AQUOS PHONE ZETA(SH-01F) は「余裕で3日使えるスマホ」という宣伝文句でしたが、我が家のSH-01Fは1日以上稼働したことがありません。アプリの履歴を消し忘れるとまず1日持たないし、消していても「メディアサーバ」さんが、電池を50%近く消費してくれたりして、結局電池が持ちません。
消し忘れたアプリや、メディアサーバさんが頑張ってると思しきときは、スマホの上部がかなり熱くなります。冬でも相当熱くなるので、夏ともなればスマホが熱でぶっ壊れるんじゃないか?と嫌な気分になります。うーん、何でだろうな…。
この記事にコメントする
2歳となったRaspberry Piの販売台数は250万台超。さらなるオープン化にむけた1万ドルコンテストを開催
Raspberry PiのSoCと同じグラフィクスコアのドライバーがオープンソースになったみたいです。
そのうちRaspberry Piでも完全オープンのドライバが動くようになるんだろうなあ。さすがだな…。
メモ: 技術系?の話はFacebookから転記しておくことにした。
この記事にコメントする
日記表示の際のアクセス解析をやめました。カウンターを表示しないブラウザ、Web Botなどからのアクセスはカウントしなくなります。
最近見つかる未知のエージェントは、従来ブラウザのバージョンアップ物か、人間からのアクセスではなかろうBotやクローラばかりで、そんなもん分類してもつまらんのですよ。
この記事にコメントする
1人で問題を解決する奴は、スゴイと思う。
1人じゃ無理だけど周りに呼びかけて解決まで導く奴は、偉いと思う。
問題を指摘するだけで逃げる奴は、居ても居なくても良いと思う。
「何だアイツ熱くなって…」ってバカにして何もしない奴らは、居ない方が良いと思う。
メモ: 技術系?の話はFacebookから転記しておくことにした。
この記事にコメントする
目次: 自宅サーバー
以前、コメントが書き込めなくなって(2014年1月7日の日記参照)しまい、応急処置で切り抜けましたが2か月経たないうちに再発しました。年単位ならまだしも1〜2か月で再発するようじゃ、もう駄目だろということで真面目に調査開始しました。
白いページが出る原因は、PHPプロセスのクラッシュによるものでした。具体的には、コメントの承認待ちデータの肥大化により、承認待ちデータをロードした際にPHPスクリプトを実行するプロセスがクラッシュして、何も応答を返せなかったためです。大体50MB overくらいで発生するようです。
また、コメントの承認待ちデータが肥大する原因は、この日記システムの設計が悪かったためです。コメントの承認待ちデータは下記の仕組みで、追加、および、削除が行われていました。
設計の大きなミスとしてコメントを承認しないと、コメントの承認待ちデータを削除する処理が絶対に動作しない点です。コメントを承認しない限り、コメントの承認待ちデータが際限なく追記されてしまいます。
対策として、コメントの承認待ちデータを「追記」する際に、同時に時間切れのモノを「削除」する処理を追加しました。これにより、時間切れと判定する時間内(現在は300秒)に、50MB分のスパムを送りつけられない限り、今回の問題は発生しないはずです。
承認待ちデータの大きさは、名前+コメント+約600バイトです。だいぶ長いスパムでも、せいぜい数KB程度なので、33回/秒の勢いで300秒間連続で投稿されない限り、パンクは免れるはずです。
ただし、今は名前やコメントに長さの制限がないため、50MB超のコメントを送信されると、一撃でコメントが書き込めなくなります。
やられたらそのときまた考えますけど、できればやらんで欲しいですな…。
この記事にコメントする
なぜ暇な人ほど「忙しいふり」をするのか - ダイヤモンド・オンラインを読んで。
炎上する案件ほど、上司が関わる時間が増えるので、
「あの案件はつらかったが、俺のおかげでぎりぎり回せたんだ」
という上司の勘違いが強く記憶に残り、評価の際にも思い出しやすいので、評価が上がるのだと思います。
上司の参画により早く終わることもあるかも知れませんが、大抵の場合は、プロジェクトが炎上すると…、
となりますよね。
メモ: 技術系の話はFacebookから転記しておくことにした。
この記事にコメントする
数年前から、会社で理解に苦しむ難解なコードが多いのはなぜだろう、誰に聞いても「このコードは意味不明だ、一見してもわからない」と言うのに、どうして誰も直さないのだろう?と疑問に思っていました。
金、土とほぼ風邪で寝てて暇だったので、久しぶりにこのブログ(脱社畜ブログ - 2013-10-30 - 「あなたにしかできない仕事」を無くすために必要なこと)を読み返していたら、なんとなく答えがわかりました。
特にこの部分です。
(引用)「あなたにしかできない仕事」を「誰でもできる仕事」に変えることは、「あなたにしかできない仕事」を一人で抱えるよりも遥かに価値があることだ。そういう意味で、この手の「標準化」は高く評価されなければならない。(引用終)
以前読んだときは「標準化」がイマイチわからなかったのですが、これを、
と置き換えて、「標準化」は「読みやすい、わかりやすいコードに書き換える」「一見して理解できる小規模に分割する」といった行為に置き換えると、非常にしっくりきました。
会社の難解なコードが増えていく理由は、標準化、つまりコードをわかりやすくするインセンティブが会社から与えられないというシステム的な問題が主な原因であって、個人に責はない、ということです。
このような評価体制だと、他人のコードに興味を示さない方が得になってしまいます。金より、エンジニアとして一目置かれたい、と思う人のやる気すらも奪ってしまうことになります。
私個人が会社の金銭的インセンティブのシステムを変えるのは難しいですが、せめて、わかりやすいコードを書く人を褒めて感謝し、自身もわかりやすいコードを書くことで報いることを心掛けようと思います。
この記事にコメントする
$shibayu36->blog; - 2014-03-16コードコンプリートを再読した
「二人である物事に取り組むと、大体会話をしている最中に設計が良くなっていくことが多い印象がある。議論にならなくても良いことも多くて、話しかけるためだけのぬいぐるみとしてだけでも良いこともある。」(以上、引用、強調は私によるもの)
作業履歴代わりに、会社のRedmineに設計とかコーディングについて、独り言を書き続けていて、最近ちょっと虚しくなってきていたのだけど、実はレビューの意味もあったんだよ、ということを気づかせてくれた。そうだったのか…。
メモ: 技術系?の話はFacebookから転記しておくことにした。
この記事にコメントする
Scalaでファイルの中身を解析したいとき、遅延評価コレクション(StreamとかViewとか)にファイル全体をマッピングすれば、好きな位置を解析できて楽だろう、というアイデアは誰しもが考えると思います。
実は私もその口だったのですが、実際にやってみるとScalaコレクションはlengthが全てInt型とされているため、アクセスできる範囲が短すぎて(最大で2Gi要素まで)困ってしまいました。
たかがそれしきのことですが、lengthはコレクション操作の至る所に出現しますので、非常に影響は大きいです。
Scalaの遅延評価は、事前に全て評価するのは不可能な(長さが無限大、あるいは大きすぎる)コレクションを扱うアイデアのはずなのに、何を思ってコレクションのlengthをInt型にしたのでしょう…。
この記事にコメントする
有線の次世代規格10Gbps Etherが足踏みしている間に、無線が1Gbps超えて(参考: NEC AtermStationのサイト)、有線が無線に負けちゃたなあ。
規格名メモ。
メモ: 技術系の話はFacebookから転記しておくことにした。
この記事にコメントする
「変人」から一流になれる人、変人を一流に変えられる「管理職」の条件 - ダイヤモンド・オンラインを読んで。
同意できる内容なんだけども、これって変人か否かは関係ないような…。
自分で頼んでおいて、今君何してるの?って真顔で聴いてくる人、いつ出来るんだ、早くやれ、しか言わない人、こんなのは上司でも部下でも同僚でもイヤです。
(引用)
「こういう眼力のある人が自分の上についてくれると、変人たちは尋常ではない働きぶりを示します。自分の頑張りが“適切に”理解され、評価され、支援されるのですから。一方、仕事の質の評価ができず、売上と納期、コストのことしか頭にない上司だと、やる気はまったく上がりません。」
Facebookのコメントで「見方や活かし方によって「変人」になってしまう、て意味に見えました。」と指摘を受けました。なるほど、そういうことか…。
メモ: 技術系の話はFacebookから転記しておくことにした。
この記事にコメントする
wiki
Linux JM
Java API
2002年
2003年
2004年
2005年
2006年
2007年
2008年
2009年
2010年
2011年
2012年
2013年
2014年
2015年
2016年
2017年
2018年
2019年
2020年
2021年
2022年
2023年
2024年
2025年
過去日記について
アクセス統計
サーバ一覧
サイトの情報